Strengthen affine scalar replacement's unused store elimination by
checking for non-aliasing memrefs for scalar replacement's "intervening
ops" check.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/MemRef/Utils/MemRefUtils.cpp | ||
---|---|---|
18 | This feels like it shares a common goal with https://mlir.llvm.org/doxygen/LocalAliasAnalysis_8cpp_source.html#l00319 and similar, is there a reason why that infra cannot be used here? | |
30 | For my own edification, is this an assumption we can make? I agree if the individual load or store is to a different address space, or the allocation itself, then this applies. But this could check between intermediate values. I don't think this exists in MLIR (at least upstream to my knowledge) but suppose there were a addrspacecast(addrspacecast(a : memref<f32,0>, 3), 0). | |
65 | It would be good to also check if they both are getglobal and come from different symbol's |
mlir/lib/Dialect/MemRef/Utils/MemRefUtils.cpp | ||
---|---|---|
18 | I should definitely explore using that far more general framework. This one is light-weight and covers more common/lower hanging cases (for eg. LocalAliasAnalysis doesn't know about global memrefs -- but we can just extend LocalAliasAnalysis). I couldn't find a single user of LocalAliasAnalysis in the codebase. Are you aware of something that I might have missed? | |
30 | There isn't an address space cast abstraction on memref's and I don't think one should be added -- it doesn't make sense, destroys higher-level abstractions, and only gets in the way of analysis and optimization. (For low-level LLVM things including pointers, I noticed addrcast ops exist.) I actually already raised the following PR putting forward such a constraint on the memref type's doc: https://reviews.llvm.org/D121270 | |
65 | Sure, good point. |
This feels like it shares a common goal with https://mlir.llvm.org/doxygen/LocalAliasAnalysis_8cpp_source.html#l00319 and similar, is there a reason why that infra cannot be used here?