This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Affine] Refactor affine fusion code in pass to utilities
ClosedPublic

Authored by dcaballe on Nov 4 2020, 2:04 PM.

Details

Summary

This patch is a refactoring/clean-up step that is needed to add support for
producer-consumer fusion with multi-store producer loops and, in general,
to implement more general loop fusion strategies in Affine. It introduces
the following changes:

  • AffineLoopFusion pass now uses loop fusion utilities more broadly to compute fusion legality (canFuseLoops utility) and perform the fusion transformation (fuseLoops utility).
  • Loop fusion utilities have been extended to deal with AffineLoopFusion requirements and assumptions while preserving both loop fusion utilities and AffineLoopFusion current functionality within a unified implementation. 'FusionStrategy' has been introduced for this purpose and, in the future, it will allow us to have a single loop fusion core implementation that will produce different fusion outputs depending on the strategy used.
  • Improve separation of concerns for legality and profitability analysis: 'isFusionProfitable' no longer filters out illegal scenarios that 'canFuse' didn't detect, or the other way around. 'canFuse' now takes loop dependences into account to determine the fusion loop depth (producer-consumer fusion only).
  • As a result, maximal fusion now doesn't require any profitability analysis.
  • Slices are now computed only once and reused across the legality, profitability and fusion transformation steps (producer-consumer).
  • Refactor some utilities and remove redundant copies of them.

Despite all these changes, this patch is NFCI and should preserve the existing
functionality of both the AffineLoopFusion pass and the affine fusion utilities.

Diff Detail

Event Timeline

dcaballe created this revision.Nov 4 2020, 2:04 PM
dcaballe requested review of this revision.Nov 4 2020, 2:04 PM
dcaballe added inline comments.Nov 4 2020, 2:09 PM
mlir/lib/Transforms/LoopFusion.cpp
1179

To be reverted

bondhugula accepted this revision.Nov 9 2020, 10:04 AM

This looks like a really great cleanup! Thanks! A list of minor comments.

mlir/lib/Transforms/LoopFusion.cpp
1046–1048

Please update doc comment to capture depthSliceUnions.

1179

What does this comment mean?

1866–1868

Looks like the doc comment here was missed. While on this, add it? since the arguments have changed as well.

mlir/lib/Transforms/Utils/LoopFusionUtils.cpp
49–52

Nit: Triple /// comments here.

190–193

Nit: Triple /// comments while at this.

325

Nit: assumptions made

This revision is now accepted and ready to land.Nov 9 2020, 10:04 AM
bondhugula added inline comments.Nov 9 2020, 10:13 AM
mlir/include/mlir/Transforms/LoopFusionUtils.h
42–43

The comment isn't mentioning the per-memref behavior - this is only clear from the class code below.

46–47

They already can, right? canFuseLoops, which is exposed, can be called from anywhere outside with the strategy argument.

50–52

I think these three strategies require slightly longer comments.

dcaballe updated this revision to Diff 304961.Nov 12 2020, 1:39 PM
dcaballe marked 7 inline comments as done.

Addressing feedback. Please, let me know if there are any other comments.
Otherwise, I'll commit this in a few days.

Thanks for the review!

mlir/include/mlir/Transforms/LoopFusionUtils.h
46–47

Yes, we can call the utilities from anywhere outside with the producer-consumer and sibling strategies but we would have to make the same assumptions made in the AffineLoopFusion pass. Otherwise, it would be unexpected behavior. Once we support more generic cases in the AffineLoopFusion pass, and extend the utilities accordingly, we should be able to use any strategies without the current assumptions/restrictions imposed by the pass. I'll clarify that a bit in the comment. Thanks!

mlir/lib/Transforms/LoopFusion.cpp
1179

Sorry, I changed this for debugging purposes and I forgot to remove it. 'srcLoopNestCost' and 'dstLoopNestCost' are printed later in the function.

andydavis1 accepted this revision.Nov 18 2020, 10:54 AM

Thanks Diego. Looks great!