[Mlir-commits] [mlir] [mlir][linalg] Flag to guard MoveInitOperandsToInput in LinalgFoldUnitExtendDimsPass (PR #157941)

[llvmlistbot at llvm.org]

sdalvi-quic wrote:

> > Thank you for raising the concern. For the input IR, we're initializing the outs(output) outside the linalg.generic op before using it, to ensure value correctness is maintained. I hope this aligns with what you were referring to in your comment.
> 
> Of course, I understand thats how it works for your full program, but from an operations perspective, there is no guarantee that it will maintain/use the value of `outs`. It basically then conflates the "meaning" of `outs`. It will make the `outs` always read the output, while it might be useful for analysis to say for an operation with all `parallel` iterator types, only the `ins` are read. At the very least, its not the best practice.

I see.
 
I checked few mlir tests where I noticed that we do read from 'outs'. Example [mlir/test/Dialect/Linalg/transform-tile-reduction.mlir](https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/Linalg/transform-tile-reduction.mlir) test, the generated IR reads from the 'outs' operand inside a linalg.generic with parallel iterators.

I see another test which does the same [mlir/test/Dialect/Linalg/transform-op-specialize.mlir](https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/Linalg/transform-op-specialize.mlir).

Please let me know if I am missing something - otherwise can we proceed with the merge as it is NFC?


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