Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Introduce a recursive/more aggressive allocation elimination pass
The hardest part for running non-local optimization passes (i.e. the transformation does not rely only on one or a few neighboring expressions) is to avoid re-analyse the code. Our current IR, though easy for linear scanning, interpreting, codegen and, to a certain degree, storage, is not very easy for making random updates. Try to workaround this issue in two ways, 1. Never resize the code array when doing updates. Instead, inserting nested arrays that we'll later splice back in for code addition and use `nothing` for code deletion. This way, the array index we cached for other metadata about the code can stay valid. 2. Based on the previous approach, pre-scan the use-def info for all variables before starting the optimization and run the optimization recursively. Code changes will also update this use-def data so that it's always valid for the user. Changes that can affect the use or def of another value will re-trigger the optimization so that we can take advantage of new optimization opportunities. This optimization pass should now handle most of the control-flow insensitive optimizations. Code patterns that are handled partially by this pass but will benefit greatly from an control-flow sensitive version includes, 1. Split slots (based on control flow) This way we can completely eliminate the surprising cost due to variable name conflicts, even when one of the def-use is not type stable. (This pass currently handles the case where all the def/uses are type stable) 2. Delay allocations There are cases where the allocation escapes but only in some branches. This will be especially for error path since we cannot eliminate some `SubArray` allocation only because we want to maintain them for the bounds error. This is very stupid and we should be able to do the allocation only when we throw the error, leaving the performance critical non-error path allocation-free. 3. Reordering assignments It is in general illegal to move an assignment when the slot assigned to is not SSA. However, there are many case that is actually legal (i.e. if there's no other use or def in between) to do so. This shows up a lot in code like ``` SSA = alloc slot = SSA ``` which we currently can't optimize since the slot can't see the assignment is actually an allocation and not a generic black box. We should be able to merge this and eliminate the SSA based on control flow info. For this case, a def info that looks through SSA values can also help.
- Loading branch information