[all-commits] [llvm/llvm-project] 5f6d5c: [mlir][bufferize] Fix tensor copy insertion for dy...

[Matthias Springer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5f6d5ca0f80c79813ab3821dc87ae01c86146398
      https://github.com/llvm/llvm-project/commit/5f6d5ca0f80c79813ab3821dc87ae01c86146398
  Author: Matthias Springer <springerm at google.com>
  Date:   2022-12-21 (Wed, 21 Dec 2022)

  Changed paths:
    M mlir/lib/Dialect/Bufferization/IR/BufferizableOpInterface.cpp

  Log Message:
  -----------
  [mlir][bufferize] Fix tensor copy insertion for dynamic tensors

TensorCopyInsertion inserts bufferization.alloc_tensor ops in case of RaW conflicts. If such a tensor is dynamically shaped, tensor.dim ops are inserted. There is an optimization for ops such as tensor.extract_slice: A copy of the result is created instead of the operand. Afterwards, all uses of the result are updated. E.g.:

```
%0 = tensor.extract_slice ... : tensor<?xf32> to tensor<?xf32>
%1 = tensor.dim %0, %c0 : tensor<?xf32>
%2 = bufferization.alloc_tensor(%dim) : tensor<?xf32>
```

All uses of %0, except for tensor.dim and bufferization.alloc_tensor (if any), should be replaced. Before this change, the use in tensor.dim was also replaced, resulting in IR that had a dominance error.

Note: There is no test case for this fix because the bug cannot be triggered with tensor.extract_slice, which implements an interface to reify result shapes. This bug appeared in an external project with a tensor.extract_slice-like op that does not implement that interface, in which case tensor.dim ops must be created. We do not have such an op in MLIR to trigger this bug.

Differential Revision: https://reviews.llvm.org/D140471