[all-commits] [llvm/llvm-project] 25bc68: [mlir][linalg][bufferize] Always bufferize in-plac...

[Matthias Springer via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 25bc684603b1aa000b92aba2e4d4fd0bf524eb02
      https://github.com/llvm/llvm-project/commit/25bc684603b1aa000b92aba2e4d4fd0bf524eb02
  Author: Matthias Springer <springerm at google.com>
  Date:   2022-02-24 (Thu, 24 Feb 2022)

  Changed paths:
    M mlir/include/mlir/Dialect/Bufferization/IR/BufferizableOpInterface.h
    M mlir/include/mlir/Dialect/Linalg/Passes.td
    M mlir/lib/Dialect/Linalg/Transforms/BufferizableOpInterfaceImpl.cpp
    M mlir/lib/Dialect/Linalg/Transforms/ComprehensiveBufferizePass.cpp
    A mlir/test/Dialect/Linalg/comprehensive-module-bufferize-aliasing-in.mlir
    A mlir/test/Dialect/Linalg/comprehensive-module-bufferize-analysis-aliasing-in.mlir
    M mlir/test/Dialect/Linalg/comprehensive-module-bufferize-analysis.mlir
    M mlir/test/Dialect/Linalg/comprehensive-module-bufferize.mlir

  Log Message:
  -----------
  [mlir][linalg][bufferize] Always bufferize in-place with "out" operands by default

In D115022, we introduced an optimization where OpResults of a `linalg.generic` may bufferize in-place with an "in" OpOperand if the corresponding "out" OpOperand is not used in the computation.

This optimization can lead to unexpected behavior if the newly chosen OpOperand is in the same alias set as another OpOperand (that is used in the computation). In that case, the newly chosen OpOperand must bufferize out-of-place. This can be confusing to users, as always choosing the "out" OpOperand (regardless of whether it is used) would be expected when having the notion of "destination-passing style" in mind.

With this change, we go back to always bufferizing in-place with "out" OpOperands by default, but letting users override the behavior with a bufferization option.

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