[Mlir-commits] [mlir] [mlir][scf] Extend consumer fuse to nested loop structure (PR #94190)

[llvmlistbot at llvm.org]

Yun-Fly wrote:

> Thanks for iterating on this patch. Before I look into the details further, I would like to understand some background: Is this patch intended to fuse nest region ops? Why does it only seem to handle scf.for from the code?

As title described, this patch intends to fuse consumer within nest loop structure w/(or w/o) multiple candidates, including both `scf.for` and `scf.forall` , where multiple candidates represents multiple candidate `sliceOps` existing under different level loop for fusing consumer.

Thus, nest loop structure including two cases:
1. nest loop structure w/o multiple candidates(a.k.a. perfectly nest loops), saying:
```
scf.for() {
  scf.for() {
    scf.for() {
       tensor.insert_slice
    }
  }
}
```
This PR enhance current `tileAndFuseConsumerOfSlice`(renamed to `tileAndFuseConsumerOfSliceImpl` in this patch) API to support above scenario.

2. nest loop structure w/ multiple candidates, including:
```
scf.for() {
  scf.for() {
      tensor.insert_slice
  }
  tensor.insert_slice
}
```
or
```
scf.forall() {
  scf.for() {
      tensor.insert_slice
  }
  scf.forall.in_parallel {
     tensor.parallel_insert_slice 
  }
}
```
or
```
scf.forall() {
  scf.forall() {
    scf.forall.in_parallel {
      tensor.parallel_insert_slice 
    }
  }
  scf.forall.in_parallel {
     tensor.parallel_insert_slice 
  }
}
```
This PR deals with this scenario by iteratively applying `tileAndFuseConsumerOfSliceImpl`.

> Why does it only seem to handle scf.for from the code?

As you can see above, nest `scf.forall` must contain multiple candidates. Then it belongs to second type of solution without additional changes like perfectly nest `scf.for` but just iterative application of existing API as other reviewers suggested in early [thread](https://github.com/llvm/llvm-project/pull/94190#issuecomment-2153001202).

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