[Mlir-commits] [mlir] [MLIR][NFC] Adding a missing option in OneShotBufferizePass (PR #130691)

[lorenzo chelini]

chelini wrote:

> Are you using this flag together with `copyBeforeWrite = true`? If not, this will probably make your program bufferize incorrectly.
> 
> ```c++
>   /// Certain ops have aliasing OpOperand/OpResult invariants (e.g., scf.for).
>   /// If this flag is set to `false`, those invariants are no longer enforced
>   /// with buffer copies.
>   ///
>   /// Note: Deactivating this flag can lead to incorrect bufferization results
>   /// when used incorrectly. This flag is useful with
>   /// `AlwaysCopyAnalysisState` which bufferizes all writing tensor
>   /// OpOperands out-of-place.
>   bool enforceAliasingInvariants = true;
> ```
> 
> If you set `copyBeforeWrite = true`, it is not necessary to change `enforceAliasingInvariants`. This is the only place where we read the flag:
> 
> ```c++
>     if (!state.getOptions().enforceAliasingInvariants ||
>         state.getOptions().copyBeforeWrite)
>       return success();
> ```
> 
> It's been a while since I looked at this, but maybe we can remove `enforceAliasingInvariants` entirely.

I am trying to add a simple test case but I don't see any difference in the IR and the bufferization analysis state, here the simple test case:
```
func.func @loop_with_aliasing(%t: tensor<?xf32>, %idx: index, %n: index) -> tensor<?xf32> {
  %c1 = arith.constant 1 : index
  %v = arith.constant 1.0 : f32
  %0 = scf.for %i = %idx to %n step %c1 iter_args(%arg0 = %t) -> tensor<?xf32> {
    // This insert operation modifies the tensor in-place
    %1 = tensor.insert %v into %arg0[%i] : tensor<?xf32>
    scf.yield %1 : tensor<?xf32>
  }
  return %0 : tensor<?xf32>
}
```
It triggers the option but there is no IR difference. I would have expected a copy if I set it to false here.

https://github.com/llvm/llvm-project/pull/130691