[Mlir-commits] [mlir] [MLIR][SCF] Add an API to fuse consumer to a producer within scf loop (PR #88712)

[llvmlistbot at llvm.org]

Yun-Fly wrote:

Thanks @Abhishek-Varma for clear example!

> It's anyway better to deal with this in future if such use case arises. :)

I see. It is really worth another PR to address this complex case.

> This was done to ensure that when we fuse the consumer the other operands should DOMINATE their use. 

If we want to extend such consumer fusion to scf loop with multiple results or uses cases in the future. It is also necessary to ensure no other op(s) between `%a` and `%user` is dominated by `%a`. In another word, we should select the FIRST user in use-chain of scf loop to invoke `fuseConsumerOfSlice`. Otherwise, the DOMINATION will be violated.

> After merging such big def-chains we need to know WHICH new candidate slice is 1:1 of the previous one. Involve multiple yielding scf.for and this already becomes too complex to handle at the moment.

Based on your latest implementation, I understand each loop of nested structure need cloned to add new inits from consumer to be fused and that is what you do now. However, I didn't see any explicit slice clone operation during `fuseConsumerOfSlice`. Or did you mean `mergeBlock` when create new scf loop [here](https://github.com/llvm/llvm-project/blob/fc7b121375231b008f90441e2b53699ea50bed66/mlir/lib/Dialect/SCF/Transforms/TileUsingInterface.cpp#L1353)? If so, It looks like not a clone, but just a movement? As for `offset` replacement related to block argument, it is a in-place modification anyway. No new slice seems created and you keep using the same `candidateSliceOp` object. If not, please correct me:) 

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