Create the directory and file structures to support transform ops for
the affine dialect in the future. Enable affine.unroll and affine.get_parent_for
transform operations in this first batch of check in.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/Affine/TransformOps/AffineTransformOps.td | ||
---|---|---|
55 | nit: please add a space between # and 'Return modes'. | |
59 | nit: space before 'Otherwise'. | |
mlir/include/mlir/Dialect/Affine/TransformOps/CMakeLists.txt | ||
7 | I would rename AffineNewTransformOps to something else, maybe: AffineLoopTransformOps. | |
mlir/lib/Dialect/Affine/TransformOps/AffineTransformOps.cpp | ||
16 | nit: new line before using namespace mlir? | |
65 | nullptr should not be needed. The callback is defaulted to nullptr. |
mlir/include/mlir/Dialect/Affine/TransformOps/AffineTransformOps.td | ||
---|---|---|
2 | Nit: this looks 1 character too long (or the bottom one too short, I didn't count). | |
25 | Please specify that this means the _affine_ for loop. | |
mlir/lib/Dialect/Affine/TransformOps/AffineTransformOps.cpp | ||
86 | Where is this generating the func dialect? |
All comments are addressed. Much appreciated! Please let me know if there are further comments.
mlir/include/mlir/Dialect/Affine/TransformOps/AffineTransformOps.td | ||
---|---|---|
21 | I'd strongly prefer to see this implemented on LoopLike interface (with maybe a name attribute to catch a particular op type) and have a single more general transform than duplicating this op in the affine dialect. | |
46 | I'd strongly prefer to see this implemented on LoopLike interface and have a single more general transform than duplicating this op in the affine dialect. |
mlir/include/mlir/Dialect/Affine/TransformOps/AffineTransformOps.td | ||
---|---|---|
21 | I can merge these two TransformOps into SCF/SCFTransformOps.cpp and in the respective apply methods in SCFTransformOps.cpp, make a determination (base on a newly introduced parameter), whether to handle in a SCF way or an Affine way. For instance, to invoke SCF's unroll method, or Affine's unroll method. And in the event a matched ops is surrounded by both affine and scf.for's, which parents are to be returned. Please advise if this is what you have in mind. I have two more affine TransformOps in an upcoming patch: affine.tile and affine.stripmine. Should we consolidate affine's TransformOps into SCF's going forward? Thank you! |
mlir/include/mlir/Dialect/Affine/TransformOps/AffineTransformOps.td | ||
---|---|---|
21 |
Yes, this would make sense to me and in the future we can continue extending to the Parallel flavor of ops and While loops etc as the need grows. I'll let @ftynse also chime in here.
These ones seem specific enough to affine that they make sense to be in the affine dialect. Thanks! |
mlir/include/mlir/Dialect/Affine/TransformOps/AffineTransformOps.td | ||
---|---|---|
21 | Thank you for the advice! Hopefully the patch https://reviews.llvm.org/D138980 addresses the concern. |
Nit: this looks 1 character too long (or the bottom one too short, I didn't count).