[all-commits] [llvm/llvm-project] 0fcaca: [mlir][bufferization] `MaterializeInDestinationOp`...

[Matthias Springer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0fcaca2feaa973afa9275c0cb931775f5e3bde4c
      https://github.com/llvm/llvm-project/commit/0fcaca2feaa973afa9275c0cb931775f5e3bde4c
  Author: Matthias Springer <me at m-sp.org>
  Date:   2023-10-06 (Fri, 06 Oct 2023)

  Changed paths:
    M mlir/include/mlir/Dialect/Bufferization/IR/BufferizationOps.td
    M mlir/lib/Dialect/Bufferization/IR/BufferizationOps.cpp
    M mlir/lib/Dialect/Linalg/Transforms/Padding.cpp
    M mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize-analysis.mlir
    M mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize-empty-tensor-elimination.mlir
    M mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize.mlir
    M mlir/test/Dialect/Bufferization/invalid.mlir
    M mlir/test/Dialect/Bufferization/ops.mlir

  Log Message:
  -----------
  [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.