diff options
author | Matthias Springer <me@m-sp.org> | 2023-10-06 11:57:10 +0200 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-10-06 11:57:10 +0200 |
commit | 0fcaca2feaa973afa9275c0cb931775f5e3bde4c (patch) | |
tree | e456b5d3f9de97db9c56bf15428c904d766bb5bc /llvm/lib/CodeGen/MachineBasicBlock.cpp | |
parent | ff843c00ce1df5af29d5dae671086b92dcabf94b (diff) | |
download | llvm-0fcaca2feaa973afa9275c0cb931775f5e3bde4c.zip llvm-0fcaca2feaa973afa9275c0cb931775f5e3bde4c.tar.gz llvm-0fcaca2feaa973afa9275c0cb931775f5e3bde4c.tar.bz2 |
[mlir][bufferization] `MaterializeInDestinationOp`: Support memref destinations (#68074)
Extend `bufferization.materialize_in_destination` to support memref
destinations. This op can now be used to indicate that a tensor
computation should materialize in a given buffer (that may have been
allocated by another component/runtime). The op still participates in
"empty tensor elimination".
Example:
```mlir
func.func @test(%out: memref<10xf32>) {
%t = tensor.empty() : tensor<10xf32>
%c = linalg.generic ... outs(%t: tensor<10xf32>) -> tensor<10xf32>
bufferization.materialize_in_destination %c in restrict writable %out : (tensor<10xf32>, memref<10xf32>) -> ()
return
}
```
After "empty tensor elimination", the above IR can bufferize without an
allocation:
```mlir
func.func @test(%out: memref<10xf32>) {
linalg.generic ... outs(%out: memref<10xf32>)
return
}
```
This change also clarifies the meaning of the `restrict` unit attribute
on `bufferization.to_tensor` ops.
Diffstat (limited to 'llvm/lib/CodeGen/MachineBasicBlock.cpp')
0 files changed, 0 insertions, 0 deletions