This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add MemRef filter to affine data copy optimization
ClosedPublic

Authored by dcaballe on Feb 10 2020, 9:57 AM.

Details

Summary

This patch extends affine data copy optimization utility with an
optional memref filter argument. When the memref filter is used, data
copy optimization will only generate copies for such a memref.

Note: this patch is just porting the memref filter feature from Uday's
'hop' branch: https://github.com/bondhugula/llvm-project/tree/hop.

Diff Detail

Event Timeline

dcaballe created this revision.Feb 10 2020, 9:57 AM
bondhugula accepted this revision.Feb 10 2020, 8:21 PM

This looks great to me! Just a few minor comments.

mlir/include/mlir/Transforms/LoopUtils.h
18

I think we shouldn't need this.

174–175

Doc comment update needed for filter memref.

mlir/test/lib/Transforms/TestAffineDataCopy.cpp
10

-> "utility functions and options".

This revision is now accepted and ready to land.Feb 10 2020, 8:21 PM
mehdi_amini added inline comments.Feb 10 2020, 8:56 PM
mlir/include/mlir/Transforms/LoopUtils.h
228

Seems like a private implementation for the one below, do we need to expose it publicly?
The API is leaking the fact that this is recursion helper...

mlir/lib/Transforms/Utils/LoopUtils.cpp
1797–1798

DenseMap is a surprising choice to me for a container that will be filled with monotonic indices starting at zero...
Can this be just a SmallVectorImpl<SmallVector<AffineForOp, 2>> ?

I think you just need to add this:

if (currLoopDepth >= depthToLoops.size()) depthToLoops.resize(currLoopDepth);

at the beginning of the function and change nothing else.

mlir/test/lib/Transforms/TestAffineDataCopy.cpp
30

Just a nit: can you use a pass option. Not that it matters much for a test pass but it'll display more consistently for mlir-opt --help

rriddle added inline comments.Feb 10 2020, 10:32 PM
mlir/lib/Transforms/Utils/LoopUtils.cpp
1639–1640

You can just do filterMemRef != loadOp.getMemRef()

1644–1646

Same here.

1804

Drop trivial braces.

dcaballe updated this revision to Diff 244029.Feb 11 2020, 4:18 PM
dcaballe marked 12 inline comments as done.
  • Address feedback

Thanks for the feedback!

mlir/include/mlir/Transforms/LoopUtils.h
174–175

Thanks Uday! I had added doc to the cpp file. I'll bring both docs into sync.

228

Good point! Thanks!

mlir/lib/Transforms/Utils/LoopUtils.cpp
1639–1640

We need the hasValue part. Otherwise, the condition would be true when filterMemRef has no value. I removed the getValue call, though :) Thanks!

1797–1798

I forgot to ask the same question to @andydavis1! I thought that maybe there was a use case that I wasn't taking into account. Even if we wanted to update the container after a loop transformation, we would be adding or removing loop levels to/from the back. ?

Another comment about the current implementation is that it adds an extra "empty" level. When we process the innermost loop and we do:

auto &loopsAtDepth = depthToLoops[currLoopDepth];

we create a new level that won't contain any loop.

I'll take care of both things if it makes sense to you.

if (currLoopDepth >= depthToLoops.size()) depthToLoops.resize(currLoopDepth);

Not sure I follow. Wouldn't this condition be always false and cause a realloc every time we add a new level?

mehdi_amini added inline comments.Feb 11 2020, 11:03 PM
mlir/lib/Transforms/Utils/LoopUtils.cpp
1797–1798

Not sure I follow. Wouldn't this condition be always false and cause a realloc every time we add a new level?

If this is a private helper yes you can skip the check.
If it is a public function you would resize by truncating if the depth was smaller than the vector size.

dcaballe updated this revision to Diff 244235.Feb 12 2020, 11:29 AM

Rebasing on top of latest mlir-opt and TestLoopFusion changes.
If no more comments, I'll address 'gatherLoops' concerns in a
separate commit and keep this as a simple rafactoring of that
utility.

bondhugula accepted this revision.Feb 13 2020, 9:29 PM

Rebasing on top of latest mlir-opt and TestLoopFusion changes.
If no more comments, I'll address 'gatherLoops' concerns in a
separate commit and keep this as a simple rafactoring of that
utility.

Yes, gatherLoops can be addressed separately; if better, you could keep gatherLoops private (and duplicated), and it could be addressed when made public. Either way is fine for me.

This revision was automatically updated to reflect the committed changes.