Changes the algorithm of LICM to support graph regions (no guarantee of topologically sorted order). Also fixes an issue where ops with recursive side effects and regions would not be hoisted if any nested ops used operands that were defined within the nested region.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/test/Transforms/loop-invariant-code-motion.mlir | ||
---|---|---|
171 | @nicolasvasilache Can you verify whether this is acceptable behaviour? |
Adds default implementations of isDefinedOutsideOfLoop and moveOutOfLoop since 99% of all implementations of these functions were identical
Can you split this as a NFC commit?
review comments
mlir/lib/Interfaces/LoopLikeInterface.cpp | ||
---|---|---|
35 | I will be submitting a patch after this one that moves moveLoopInvariantCode to TransformUtils. At the same time, I'll move this function to MLIRAnalysis (the same function exists elsewhere in the codebase and I will refactor those as well) |
mlir/test/lib/Dialect/Test/TestOps.td | ||
---|---|---|
14 | There's a test op for LinalgConvolutionOpInterface |
mlir/lib/Interfaces/LoopLikeInterface.cpp | ||
---|---|---|
68 | Probably more idiomatic to check the trait for IsTerminator. | |
90 | nit: Add a newline before the comment. | |
mlir/test/Transforms/loop-invariant-code-motion.mlir | ||
362 | Can you add a test that checks that we don't hoist from graph regions into non-graph regions? | |
366 | Do we have a test in a non-graph region where operations that can be hoisted feed into each other? Something like: %v0 = arith.addi %c0, %c0 : i32 %v1 = arith.addi %c0, %v0 : i32 to make sure that dominance still holds after hoisting? |
mlir/test/Transforms/loop-invariant-code-motion.mlir | ||
---|---|---|
362 | Is the behaviour that we want that ops don't cross between non-graph and graph regions (in either direction)? Right now, LICM can move ops from graph regions to non-graph regions but only in topological order (dominance will be preserved). Ops that form cycles won't be moved because it doesn't detect them. | |
366 | Oddly enough, I don't see one. I'll add one. |
mlir/test/Transforms/loop-invariant-code-motion.mlir | ||
---|---|---|
362 | It's more about being conservatively correct. We can hoist from a graph into a non-graph(and vice-versa), but we, for example, have to ensure that the dominance of the hoisted operations is valid. We have to be careful about the contract changes between the two regions. |
mlir/test/Transforms/loop-invariant-code-motion.mlir | ||
---|---|---|
362 | We will be okay to move ops from graph regions to non-graph regions; since LICM only considers one operation at a time, ops are moved only when all their operands are defined outside the graph region body. If the outer region is a non-graph region, the defining ops must precede the loop op. I'll add some test cases. |
This would be a useful function and can directly be added in MLIRAnalysis library?