This is an archive of the discontinued LLVM Phabricator instance.

[mlir][NFC] Fix 'gatherLoops' utility
ClosedPublic

Authored by dcaballe on Feb 14 2020, 5:14 PM.

Details

Summary

It replaces DenseMap output with a SmallVector and it
removes empty loop levels from the output.

Diff Detail

Event Timeline

dcaballe created this revision.Feb 14 2020, 5:14 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 14 2020, 5:14 PM
mehdi_amini accepted this revision.Feb 14 2020, 9:11 PM
mehdi_amini added inline comments.
mlir/lib/Transforms/Utils/LoopUtils.cpp
1808

Why is this pop_back() needed now? Or do you just view this as an "optimization"?

This revision is now accepted and ready to land.Feb 14 2020, 9:11 PM
dcaballe marked an inline comment as done.Feb 18 2020, 8:53 AM

Thanks!

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

This is not to keep an empty level around in the output. For example, let's say we have two nested loops in a function. The algorithm would proceed as follows:

  • Visit function body, add level 0 to output, add the outer loop to level 0.
  • Visit the outer loop body, add level 1 to output, add the inner loop to level 1.
  • Visit inner loop body, add level 2 to output, no loops are added to level 2.
  • Remove level 2 since it's empty.

I'm now thinking that I could move this removal to the public 'gatherLoops' function so that it's only executed once since the empty level will always be one and the last one in the output vector, no matter how many or the structure of the loop nests visited.

dcaballe updated this revision to Diff 245183.Feb 18 2020, 9:05 AM

Move empty level removal to public function so that it's executed only once.

andydavis1 accepted this revision.Feb 18 2020, 12:43 PM
andydavis1 added inline comments.
mlir/test/lib/Transforms/TestAffineDataCopy.cpp
46

Typically we don't see SmallVector<SmallVector. These patterns are typically std::vector<SmallVector.

dcaballe marked an inline comment as done.Feb 18 2020, 3:29 PM
dcaballe added inline comments.
mlir/test/lib/Transforms/TestAffineDataCopy.cpp
46

Thanks Andy! I'll change that before committing. For my understanding, I'm not sure I follow the rationale. Isn't this one of the ideal cases for SmallVector? I.e., the object to be contained has a "large" memory footprint (a SmallVector with two op elements, in this case) and we want to avoid allocating unnecessary slots?

This revision was automatically updated to reflect the committed changes.