This is an archive of the discontinued LLVM Phabricator instance.

[mlir][linalg] Convert tensor.generate to destination style
ClosedPublic

Authored by springerm on Jan 20 2023, 5:50 AM.

Details

Summary

This can be a pre-processing for bufferization and allows for more efficient lowerings without an alloc.

Diff Detail

Event Timeline

springerm created this revision.Jan 20 2023, 5:50 AM
springerm requested review of this revision.Jan 20 2023, 5:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 20 2023, 5:50 AM
mravishankar requested changes to this revision.Jan 20 2023, 11:28 AM

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?

This revision now requires changes to proceed.Jan 20 2023, 11:28 AM

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.

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.

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.

springerm updated this revision to Diff 491290.Jan 23 2023, 3:50 AM

address comments

This is adding a dependency from Linalg to Tensor.... Doesnt that lead to circular dependency.

It's was adding a dependency from TensorTransforms (not Tensor); now LinalgTransforms (not Linalg). So either one if fine.

Moved everything to Linalg.

springerm retitled this revision from [mlir][tensor] Convert tensor.generate to destination style to [mlir][linalg] Convert tensor.generate to destination style.Jan 23 2023, 3:55 AM
mravishankar accepted this revision.Jan 23 2023, 12:24 PM
This revision is now accepted and ready to land.Jan 23 2023, 12:24 PM