Currently, buffer deallocation considers arith.select to be
non-aliasing, which results in deallocs being inserted incorrectly. Since
arith.select doesn't implement any useful interfaces, this change just handles
it explicitly. Eventually this should probably be fixed properly, if this pass
is going to be used long term.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Analysis/BufferViewFlowAnalysis.cpp | ||
---|---|---|
124 | Maybe put a TODO that we need an interface here to avoid listing ops. (And adding dialect dependencies to Analysis.) | |
utils/bazel/llvm-project-overlay/mlir/BUILD.bazel | ||
5881 | This is a bit unfortunate. But I don't see a good alternative without adding a new interface. CMake file also needs updating. |
I find it very strange that arith.select supports memref in the first place. Are there other operations in the arith dialect that do this?
I think this is because arith.select used to be std.select and there was no better place to put it. (Maybe the scf dialect would be an alternative.)
mlir/lib/Analysis/BufferViewFlowAnalysis.cpp | ||
---|---|---|
124 | What is the timeline for fixing this? We should not be adding dialect dependencies to Analysis. Is this going to be fixed soon? Otherwise, please revert. |
mlir/lib/Analysis/BufferViewFlowAnalysis.cpp | ||
---|---|---|
124 | Ah, thank you for pinging this. I'd be happy to fix this soon, but there should probably be a little bit of discussion on how to do it first. I don't see any existing interface that quite fits here. It might be possible to generalize BranchOpInterface, but to me it doesn't seem like it's going to work well. We could add a new interface to ControlFlowInterfaces (strawman proposal: ValueBranchOpInterface), but that doesn't seem like a perfect match either. Or we could create a new interface elsewhere (but as far as I can tell, it would be a singleton for now, whatever it would end up being. Maybe something specifically around memory aliasing). Input or better ideas welcome. |
mlir/lib/Analysis/BufferViewFlowAnalysis.cpp | ||
---|---|---|
124 | I'd say let's move the entire BufferViewFlowAnalysis to the BufferizationTransforms. We only use it for bufferization, so it would make sense to have it there. And we can have a dependency on the Arith dialect there. Step 2, we can add a new interface that is somewhat similar to BufferizableOpInterface::getAliasingOpResult, but operating on buffers. E.g., we could call it BufferAliasingOpInterface. Step 3, no longer use RegionBranchOpInterface etc. in BufferViewFlowAnalysis (which is used incorrectly at the moment), but only use BufferAliasingOpInterface. To that end, we have to implement this interface on a few other ops: scf.for, scf.while, scf.execute_region, memref.subview, maybe a few more. The list of ops that must implement this interface is actually quite small. Also, the default case in the analysis (if an op does not implement the interface) should be "assume that operand and result" are aliasing. Unknown ops are currently treated as "no aliasing", which is incorrect. |
mlir/lib/Analysis/BufferViewFlowAnalysis.cpp | ||
---|---|---|
124 | OK, I like that solution. https://reviews.llvm.org/D132928 should do step 1 and resolve the immediate issue here. Thanks! |
Maybe put a TODO that we need an interface here to avoid listing ops. (And adding dialect dependencies to Analysis.)