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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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? |
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 |
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
- There is even more opportunity for caching between these calls and getEffectsRecursively
- 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. |
It is fine by me. Please give it a couple of days for @rriddle and others to comment.
mlir/lib/Transforms/CSE.cpp | ||
---|---|---|
216 | Optional nit |