| Issue |
91518
|
| Summary |
[mlir][bufferization] OneShotBufferize broken when using `defaultMemorySpaceFn`
|
| Labels |
mlir
|
| Assignees |
|
| Reporter |
christopherbate
|
A change from February allowed callers of OneShotBufferize to set the default memory space from the TensorType of a value. See PR here: https://github.com/llvm/llvm-project/pull/78484. According to the PR, this is used to allow implementing a mapping from tensor encoding attribute to memref memory space.
This change is a nice feature, however it is quite broken outside of limited use. In particular, it doesn't play nicely with `bufferization.alloc_tensor|materialize_in_destination|to_tensor|to_memref` and produces unexpected/wrong results.
I will post a range of example IR where using this feature produces unexpected/non-sense results when running `one-shot-bufferize`, but the crux of the issue is that there is limited support with dealing situations like the following:
1. `bufferization.materialize_in_destination` where the encoding on the source and destination tensors map to different memory spaces
2. `bufferization.alloc_tensor` expects the `copy` and `result` types to match, but this is at odds with using the tensor type encoding to set the memory space. It can also fail if the tensor type encoding and the `memory_space` attribute on the op are different.
I took a shot at fixing this and believe that I have corrected all issues satisfactory (TODO: link PR).
However, the change is quite extensive since it requires that we update the `bufferization.to_tensor|to_memref` operations to explicitly list out the types of operands and results in their assembly formats. This is because `bufferization.to_tensor` can not be used correctly in its current form where it derives its result type from the memref type when the tensor encoding is used for memory space. Currently, bufferization drops the encoding attribute, producing unexpected results later on. The same is true for `to_memref` as it will currently drop the memory space attribute.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
