This can be a pre-processing for bufferization and allows for more efficient lowerings without an alloc.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The pattern itself looks fine, but I think this has a dependency issue. There is already a Tensor -> Linalg dependence. This is adding a Linalg -> Tensor dependence.... That could be problematic... is there a way to do this as part of bufferization or something, or move these patterns to Linalg?
Note it is a dependency from TensorTransforms -> Linalg and we already have it without this change. The implementation is actually largely copied from Tensor/Transforms/BufferizableOpInterfaceImpl.cpp. I'm still on the fence on whether we should completely delete the tensor.generate bufferization and make ConvertToDestinationStyle a mandatory pre-processing to bufferize tensor.generate. It does solve a few issues such as "inferring the correct memory space". Whether the pattern lives in LinalgTransforms or TensorTransforms does not really matter in the end, but it conceptually fits into TensorTransforms as all bufferization-related transforms/interface impls are currently in the dialect of the respective ops.
In general, I found it better to do less work in bufferization and do more in pre/post processing passes. EmptyTensorElimination, BufferDeallocation and BufferHoisting are three examples. ConvertToDestinationPassingStyle is another one that is introduced with this revision. Otherwise, One-Shot Bufferize becomes really large and complicated.
This is adding a dependency from Linalg to Tensor.... Doesnt that lead to circular dependency. Would be good to see we dont break the layering check in bazel.... Maybe specific Tensor:IR -> Linalg:IR -> Tensor:Transforms -> Linalg:Transforms doesnt create a circular dependency, but thats strange layering. I am just saying maybe move this to Linalg since you are generating Linalg op.s
I'm still on the fence on whether we should completely delete the tensor.generate bufferization and make ConvertToDestinationStyle a mandatory pre-processing to bufferize tensor.generate. It does solve a few issues such as "inferring the correct memory space". Whether the pattern lives in LinalgTransforms or TensorTransforms does not really matter in the end, but it conceptually fits into TensorTransforms as all bufferization-related transforms/interface impls are currently in the dialect of the respective ops.
In general, I found it better to do less work in bufferization and do more in pre/post processing passes. EmptyTensorElimination, BufferDeallocation and BufferHoisting are three examples. ConvertToDestinationPassingStyle is another one that is introduced with this revision. Otherwise, One-Shot Bufferize becomes really large and complicated.
I totally agree with this. Doing pre-processing this way is definitely better. I am just thinking of dialect dependency.
It's was adding a dependency from TensorTransforms (not Tensor); now LinalgTransforms (not Linalg). So either one if fine.