Currently when we fold an empty loop, we assume that any loop
with iterArgs returns its iterArgs in order, which is not always
the case. It may return values defined outside of the loop or
return its iterArgs out of order. This patch adds support to
those cases.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks, Amy! I think this is a very interesting extension! Some comments
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
1667 | Probably good to return None for this case instead of crashing. | |
1697 | find_if -> find? | |
1699 | I would add an assert to make sure this is actually true, just in case we extend this folding to cases with multiple operations in the loop body. Maybe you can check that with Operation::isAncestor? | |
1703 | std::distance? | |
1714–1716 | Is there a test for this case? | |
mlir/test/Dialect/Affine/canonicalize.mlir | ||
562 | Maybe we should split these three loops into separate tests to make them easier to triage. |
Thanks for fixing this!
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
1694 | Use e = ...; i < e; ... form to prevent repeated evaluation. | |
1694–1721 | I think this implementation can be shared by both scf.for and affine.for. You can get replacements using an interface method or add a TODO for that? (Can you check if scf.for already has something that can be shared?) |
Thanks, Amy. LGTM once Uday's comments have been addressed.
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
1694–1721 | We would need to support negative steps for scf.for. |
mlir/lib/Dialect/Affine/IR/AffineOps.cpp | ||
---|---|---|
1694–1721 | I checked scf.for. There are 1) SimplifyTrivialLoops, which takes care of loops with trip count 0 or 1; 2) ForOpIterArgsFolder, which folds away iterArgs that are returned in order. The only case left that we can fold is when the trip count is a constant greater than 1 and only values defined outside of the loop are returned. We can modify SimplifyTrivialLoop to handle that at the end. I can do that in separate patch. | |
1694–1721 | The description of scf.for says that the step is required to be positive. |
@dcaballe @bondhugula Thank you for the review. I'll merge it tomorrow if there are no more comments. I have created a new review that extends SimplifyTrivialLoops for scf.for.
Probably good to return None for this case instead of crashing.
I'm curious: we can't represent affine loops with negative steps in AffineForOp in general or because they are not supported yet?