[all-commits] [llvm/llvm-project] 1b99f3: [mlir][bufferize] Treat certain aliasing-only uses...

[Matthias Springer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1b99f3a224afcab4a08f3b5b32ece63aa22cae0c
      https://github.com/llvm/llvm-project/commit/1b99f3a224afcab4a08f3b5b32ece63aa22cae0c
  Author: Matthias Springer <springerm at google.com>
  Date:   2022-10-14 (Fri, 14 Oct 2022)

  Changed paths:
    M mlir/include/mlir/Dialect/Bufferization/Transforms/OneShotAnalysis.h
    M mlir/include/mlir/Dialect/Bufferization/Transforms/Passes.td
    M mlir/lib/Dialect/Bufferization/Transforms/Bufferize.cpp
    M mlir/lib/Dialect/Bufferization/Transforms/OneShotAnalysis.cpp
    M mlir/test/Dialect/Bufferization/Transforms/one-shot-bufferize.mlir

  Log Message:
  -----------
  [mlir][bufferize] Treat certain aliasing-only uses like memory reads

This fixes an issue in One-Shot Bufferize that could lead to missing buffer copies in the future. This bug can currently not be triggered because of the order in which ops are analyzed (always bottom-to-top). However, if we consider different traversal orders for the analysis in the future, this bug can cause subtle issues that are difficult to debug.

Example:
```
%0 = ...
%1 = tensor.insert ... into %0
%2 = tensor.extract_slice %0
tensor.extract %2[...]
```

In case of a top-to-bottom analysis of the above IR, the `tensor.insert` is analyzed before the `tensor.extract_slice`. In that case, the `tensor.insert` will bufferize in-place because %2 is not yet known to become an alias of %0 (and therefore causing a conflict).

With this change, the `tensor.insert` will bufferize out-of-place, regardless of the traversal order.

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