We currently only support lazy loading for regions that
statically implement the IsolatedFromAbove trait, but that
limits the amount of operations that can be lazily loaded. This review
lifts that restriction by computing which operations have isolated
regions when numbering, allowing any operation to be lazily loaded
as long as it doesn't use values defined above.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Bytecode/Writer/IRNumbering.cpp | ||
---|---|---|
190 | Isn't this redundant with the numbering optional isIsolatedFromAbove? | |
194 | Some description of what's happening below would be useful, it's a non-trivial algorithm. | |
200 | This if the longest, can we put it at the end and check the other conditions with an early return (and reduce indentation) |
mlir/lib/Bytecode/Writer/IRNumbering.cpp | ||
---|---|---|
190 | Not exactly. isIsolatedFromAbove applies for the current op, but this flag is if the current op or any of its parents still need checking. We can only avoid checking if we know the current region and all of the parents have been resolved, otherwise we might miss checking something like: top.op { %value = ... middle.op { %value2 = ... inner.op { // Here we mark inner.op as not isolated (but not middle.op yet) use %value2 // Here inner.op is already known to be non-isolated, but middle.op is now also // discovered to be non-isolated. use %value } } } |
mlir/lib/Bytecode/Writer/IRNumbering.cpp | ||
---|---|---|
190 | Tricky... Can you add this comment in the code? Edit: Oh.. you did already! :) |
Isn't this redundant with the numbering optional isIsolatedFromAbove?
If numbering->isIsolatedFromAbove has a value, it means we already know and shouldCheckIsolation should be false.