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

llvmlistbot at llvm.org llvmlistbot at llvm.org
Sun Jul 14 23:11:24 PDT 2024


Yun-Fly wrote:

> If we have following input:
> ```
>   %0 = def_op()
>   scf.forall ... {
>     scf.if() {
>          %1 = use(%0)
>      }
>  }
> ```
> Should we fuse it too and what is the fundamental difference between fuse if and fuse for? How should we handle other ops with regions or multiple blocks under scf.execute_region? I think there should be similarities in how these fuse processes handle these cases. Perhaps we can consider these issues when we start working on scf.for.

For your example, it would not be fused at present. But it is quite an actual good points. If we want to cover all kinds of nest region ops, we should also support `scf.if` or any other ops. However, as I said above, currently this patch only focus on `scf.for` and `scf.forall`. The reason maybe involved in two aspects:
1. It seems that all tiling interface, so far, take few consideration of other type of scf ops excluding `scf.for`, like `scf.if` as you listed. It maybe better to be extended by another PR.
2. There is already some concern about how to fuse within `scf.if`(please see #95422 for more details). As described there, it needs some API refactor before further extension.

In summary, there are not only similarities but also difference in fuse process between `scf.for` and other scf ops. It may take more time to fully support them with more example inputs, but probably not in this patch I guess.

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


More information about the Mlir-commits mailing list