Introduce support for inlining into affine operations. This uses the generic
inline infrastructure and boils down to checking that, if applied, the inlining
doesn't violate the affine dimension/symbol value categorization. Given valid
IR, only the values that are valid dimensions/symbols thanks to being top-level
in their affine scope need special handling.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks mostly fine to me, but will defer approval to those more closely following the affine dialect. (In case I forgot about some specific properties of the affine operations)
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
65 | Is it still requiring ConstantOp directly and not using the more general m_Constant? | |
193 | nit: You can merge all of these isa<> together: isa<AffineForOp, AffineParallelOp, ...>(parentOp) |
Thanks for working on this, Alex! LGTM! Just some minor comments.
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
40 | remmains -> remains | |
58–59 | Maybe we could do: if (value.isa<BlockArgument>()) return legalityCheck so that a legal block argument doesn't continue? The condition below will always be false for a BlockArgument. We could even move value.isa<OpResult>() to an assert. | |
mlir/test/Dialect/Affine/inlining.mlir | ||
75 | could you also please add a test with an affine.vector_load or affine.vector_store? | |
84 | should we capture %arg0 and match it here to make sure the output is correct (similar to IV)? |
Looks great!
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
140 | The doc comment is missing documentation of wouldBeClone. |
Address review
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
144–146 | No, this is checking if we can inline into an affine control flow construct (for, if). These constructs are not affine scopes, but they are presumably in some scope already. |
remmains -> remains