[Mlir-commits] [mlir] [mlir][scf] Extend fuse producer to multi-level candidates case (PR #97803)

[llvmlistbot at llvm.org]

Yun-Fly wrote:

> But there is too much of an assumption being made that the loop structure you create is consistent with what tiling creates. In fact that assumption is already made by the implementation. 

The loop structure created in this PR is exactly what multiple level tiling creates. So it quite looks consistent with what tiling creates but different in multiple level nest loops and candidate slices for better utilization of parallelism and memory hierarchy. I will detail more our context at last.

> That is why the current `mlir::tileAndFuseProducerOfSlice` is taking the loop nest generated by `MutableArrayRef<LoopLikeOpInterface> loops` as arguments. 

Yes, I know it and that is one of reason why this PR looks easier reviewer than another patch of fusing consumer. IIRC, current `mlir::tileAndFuseProducerOfSlice` is only used in `tileConsumerAndFuseProducersUsingSCF`, where consumer is tiled by `tileUsingSCF` into single level tiling with all extract slices located in inner-most loop. So, it is good enough for this use case.

> I'd like to understand if there is a way you can keep the logic of finding loops closer to your context and then consider if we need to change the implementation of how the producer is found by walking the loop nest and extract slice source definition chain. Does that question make sense?

Our context is that some developers want to costume the way how to tile the certain op instead of directly using general but common `tileUsingSCF` API, especially for `matmul` or `convolution` on different target device. The only concern of these developers is how to improve the kernel performance by multiple level tiling, but not how subsequent fusion would be done because what kind of post ops are uncertain for them. In another word, this kind of use case decouples the tiling stage of contraction op and fusion process of surrounding ops, which brings more flexible tiling and requires robust fusion interface, saying `tileAndFuseProducerOfSlice`.




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