This is an archive of the discontinued LLVM Phabricator instance.

[mlir][Transforms] teach CSE about recursive memory effects
ClosedPublic

Authored by tblah on Aug 1 2023, 9:27 AM.

Details

Summary

Add support for reasoning about operations with recursive memory effects
to CSE. The recursive effects are gathered by a helper function. I
decided to allow returning duplicates from the helper function because
there's no benefit to spending the computation time to remove them in
the existing use case.

Diff Detail

Event Timeline

tblah created this revision.Aug 1 2023, 9:27 AM
Herald added a project: Restricted Project. · View Herald Transcript
tblah requested review of this revision.Aug 1 2023, 9:27 AM

lg for the sparse check changes

I guess one reason for not doing this previously would be the time taken to recursively traverse operations. But as long as an operation is not visited more than once, i guess it is OK.

mlir/lib/Transforms/CSE.cpp
207

Would an alternative implementation be to recursively perform the check during op.hasEffect if the operation has recursiveEffects?

mlir/lib/Interfaces/SideEffectInterfaces.cpp
198–200

Nit: spell the types here and above.

206–211

Nit: Braces here and above.

I guess one reason for not doing this previously would be the time taken to recursively traverse operations. But as long as an operation is not visited more than once, i guess it is OK.

Actually, the operations are going to be visited multiple times because the CSE pass will apply to every operation. So we will be computing the effects on every runOnOperation invocation, and some of the computations will be redundant. I think we need to make the effects cache "global", but does it mean we have to make the pass a module pass?

mlir/lib/Interfaces/SideEffectInterfaces.cpp
210

typo: meemory

mlir/lib/Transforms/CSE.cpp
207

Not yours, but you may consider fixing the typo: assumes -> assume

tblah added a comment.Aug 2 2023, 10:35 AM

I guess one reason for not doing this previously would be the time taken to recursively traverse operations. But as long as an operation is not visited more than once, i guess it is OK.

Actually, the operations are going to be visited multiple times because the CSE pass will apply to every operation. So we will be computing the effects on every runOnOperation invocation, and some of the computations will be redundant. I think we need to make the effects cache "global", but does it mean we have to make the pass a module pass?

Thanks for taking a look. Yes you are right that there is a lot of opportunity for caching here. The existing implementation of wouldOpBeTriviallyDeadImpl works the same way and is already called on every operation (via isOpTriviallyDead). Therefore

  1. There is even more opportunity for caching between these calls and getEffectsRecursively
  2. The big-O complexity of the pass remains of the same order as without this patch. We just do the same expensive uncached lookup twice now

Would it be okay to keep the patch scope as it is and then address performance (of all functions in SideEffectInterfaces.cpp) separately, if it turns out to be a problem for real workloads?

mlir/lib/Transforms/CSE.cpp
207

Operations with recursive effects tend not to implement the memory effect interface so nextOpMemEffects would be null (recursive memory effects is a different interface).

Anyway, I think you mean, why not fix the normal ways of getting the side effects of an operation so that they always check recursively? I decided not to do that in this patch because it would have a far broader impact on other MLIR transformations.

tblah updated this revision to Diff 546543.Aug 2 2023, 10:43 AM

Updating to fix nits. Thanks for review.

tblah marked 4 inline comments as done.Aug 2 2023, 10:43 AM

Would it be okay to keep the patch scope as it is and then address performance (of all functions in SideEffectInterfaces.cpp) separately, if it turns out to be a problem for real workloads?

It is fine by me. Please give it a couple of days for @rriddle and others to comment.

unterumarmung added inline comments.
mlir/lib/Transforms/CSE.cpp
216

Optional nit

vzakhari accepted this revision.Aug 5 2023, 9:56 AM
This revision is now accepted and ready to land.Aug 5 2023, 9:56 AM
tblah updated this revision to Diff 547715.Aug 7 2023, 4:29 AM

Fix nit

kiranchandramohan accepted this revision.Aug 8 2023, 9:13 AM

Thanks. LGTM. Please wait a day before you submit in case other reviewers have comments.

mlir/include/mlir/Interfaces/SideEffectInterfaces.h
338
mlir/lib/Transforms/CSE.cpp
206–207

Nit: I think this comment has to be expanded to say about the RecursiveMemoryEffectCase.

This revision was landed with ongoing or failed builds.Aug 10 2023, 2:40 AM
This revision was automatically updated to reflect the committed changes.