This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Unroll-and-jam loops with iter_args.
ClosedPublic

Authored by ayzhuang on Sep 20 2021, 10:37 AM.

Details

Summary

Unroll-and-jam currently doesn't work when the loop being unroll-and-jammed or any of its inner loops have iter_args This patch modifies the unroll-and-jam utility to support loops with iter_args.

Diff Detail

Event Timeline

ayzhuang created this revision.Sep 20 2021, 10:37 AM
ayzhuang requested review of this revision.Sep 20 2021, 10:37 AM
ayzhuang edited the summary of this revision. (Show Details)Sep 21 2021, 2:47 PM
bondhugula requested changes to this revision.Sep 21 2021, 8:39 PM
bondhugula added inline comments.
mlir/include/mlir/Analysis/AffineAnalysis.h
43–46

Pass output arg by reference unless it can be null. https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide
If it can be null, please document that. If the goal is to just return things, I'm not sure why you need to accept a null argument and a pointer.

mlir/lib/Dialect/Affine/Transforms/LoopUnrollAndJam.cpp
79–80

This requires a code comment.

mlir/lib/Transforms/Utils/LoopUtils.cpp
1413

Please leave a space after "1." - here and above as well.

1492–1540

This method has become too long (350 lines) and should be split I think. This revision is adding a substantial amount of code to it.

This revision now requires changes to proceed.Sep 21 2021, 8:39 PM

Thanks for creating this more comprehensive revision. Comments below.

mlir/lib/Transforms/Utils/LoopUtils.cpp
1414–1426

This function can be made a static helper along isBoundDependent?

1418

This is making an assumption that the first few operands would be the control operands. Instead, please use llvm::zip(..getLowerBoundOperands(), getUpperBoundOperands()) or can you add an accessor getControlOperands()?

1538

Short code comment here.

bondhugula added inline comments.Sep 21 2021, 10:41 PM
mlir/lib/Transforms/Utils/LoopUtils.cpp
1492–1540

But please feel free to let me know if there are reasons you think it's still better this way.

ayzhuang updated this revision to Diff 374976.Sep 24 2021, 3:55 PM
ayzhuang marked 5 inline comments as done.

Address review comments to add helper functions and modify comments.

ayzhuang added inline comments.Sep 24 2021, 3:56 PM
mlir/lib/Dialect/Affine/Transforms/LoopUnrollAndJam.cpp
79–80

Removed the check.

mlir/lib/Transforms/Utils/LoopUtils.cpp
1414–1426

Added helper areInnerBoundsInvariant.

1418

Added getControlOperands()

1492–1540

I have moved some code out to the helper functions. I was thinking to move other parts like cloning the subblocks out, but it would be hard for the readers to understand this old/new concepts like oldNumResults in a standalone function.

Overall, this is looking good. Some more comments below.

mlir/include/mlir/Dialect/Affine/IR/AffineOps.td
268

Just to make it clear that it's the lower bound operands followed by the upper bounds operands, consider adding something like:

"... in that order."

mlir/lib/Transforms/Utils/LoopUtils.cpp
1384–1385

This statement isn't right. A loop does not have to be a parallel loop for its unroll-and-jam to be valid. Being a parallel loop is a sufficient condition but nowhere close to being necessary for unroll-and-jam. In fact, we need no statement here on validity - the utility just does the unroll-and-jam. It's up to the user to ensure that that is a valid transformation.

As an aside: if it's valid to make a loop an innermost loop, it's valid to unroll-and-jam that loop by any factor -- this sufficient condition is closer to a necessary and sufficient condition.

1479–1485

Code comments here will help.

1527–1534

Code comments here will help.

1555–1556

You can't use the result of getDefiningOp unchecked - it can be null. An assert is missing here since getReductionOp provides you that guarantee.

1558

Nit: -> "Replace all uses except ..."

bondhugula accepted this revision.Sep 24 2021, 5:54 PM
bondhugula added inline comments.
mlir/lib/Transforms/Utils/LoopUtils.cpp
1385

The doc comment on this utility (which exists in the header file) should be expanded to indicate the support for reductions you've added, which is great. For a publicly exposed utility, we don't have to actually duplicate the doc comment on the function definition itself.

This revision is now accepted and ready to land.Sep 24 2021, 5:54 PM
ayzhuang updated this revision to Diff 375011.Sep 24 2021, 8:34 PM
ayzhuang marked 5 inline comments as done.

Address review comments.

mlir/lib/Transforms/Utils/LoopUtils.cpp
1384–1385

Thanks. Deleted the statement.

ayzhuang updated this revision to Diff 375012.Sep 24 2021, 9:03 PM

Address code comments to add comment to header file.

bondhugula accepted this revision.Sep 25 2021, 7:24 AM
bondhugula added inline comments.
mlir/include/mlir/Transforms/LoopUtils.h
70

-> ... can be loops with iteration arguments performing supported reductions.

?

ayzhuang updated this revision to Diff 375302.Sep 27 2021, 9:28 AM

Address review comment to modify comments.

ayzhuang marked an inline comment as done.Sep 27 2021, 9:28 AM
bondhugula accepted this revision.Sep 27 2021, 10:11 AM

@bondhugula Thank you for the review. We'll merge it tomorrow if there are no more comments.

This revision was automatically updated to reflect the committed changes.