LinalgOp results usually bufferize inplace with output args. With this change, they may buffer inplace with input args if the value of the output arg is not used in the computation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/Linalg/ComprehensiveBufferize/LinalgInterfaceImpl.cpp | ||
---|---|---|
158 | you'll also need to check for equal indexing maps until we have some region dependence analysis. To be safe and conservative, you should also check that isProjectedPermutation is true, although you should not be able to create an op where the output is not a projected permutation in the first place with the current verifier. | |
158 | Note: O(i, j) = A(i, j) + B(j) --> bufferizes inplace to: A(i, j) += B(j) --> this is fine but: O(i, j) += A(i, j) + B(j). --> bufferizes inplace to: A(i, j) += previous value of O(i, j) + B(j) --> illegal to write A(i, j) = F(A(i, j), B(j)) --> this is wrong A simple "violated" range dependence analysis would have caught this case (and more complex future cases). |
mlir/lib/Dialect/Linalg/ComprehensiveBufferize/LinalgInterfaceImpl.cpp | ||
---|---|---|
158 | Actually its better to check that the indexing maps of the input operand and the result are identical and that they are projected permutations, but overall this logic looks good to me. It will catch a lot of common cases and make things better bufferize in place. | |
162 | I think this method is general enough to be moved into the interface. I dont see why this logic would not hold for any operation. |
address comments
mlir/lib/Dialect/Linalg/ComprehensiveBufferize/LinalgInterfaceImpl.cpp | ||
---|---|---|
162 | I can't tell which line you originally commented on since I uploaded a new revision. Which one was it? |
There is still an issue here. I have to avoid the case where two different OpResult alias with the same OpOperand. Checking...
you'll also need to check for equal indexing maps until we have some region dependence analysis.
To be safe and conservative, you should also check that isProjectedPermutation is true, although you should not be able to create an op where the output is not a projected permutation in the first place with the current verifier.