[Mlir-commits] [mlir] [mlir][linalg] Extend `FuseElementwiseOps` pattern to work with named ops (PR #144922)
llvmlistbot at llvm.org
llvmlistbot at llvm.org
Wed Nov 5 07:21:39 PST 2025
srcarroll wrote:
>This is a new functionality that is combining two transformation "generalization" and "fusion"
@MaheshRavishankar Not really. It's still only fusion. In the current state, the result of fusion is always a `linalg.generic`. A lot of times it has to be because the fused result doesn't have a named operation, e.g. fusing `linalg.elementwise` and `linalg.matmul` has to be a `linalg.generic`. In other cases, the fused result can be a named op, e.g. `linalg.map` + `linalg.map` -> `linalg.map` (note that fusing two `linalg.elementwise`s wouldn't work this way because this op only allows one operation in the payload, so it too would have to fuse to `linalg.generic`). I would argue that the former case happens more often the the latter case. So getting `linalg.generic`, for the most part, is just part of fusion, not that we are explicitly generalizing named ops in order to do fusion. In fact, before these changes a user would HAVE to generalize named ops before fusion in order to opt in to fusing ops that aren't already `linalg.generic`.
@renato and I have already discussed the desire to keep named ops as long as possible. I am in firm agreement with this. See [here](https://github.com/llvm/llvm-project/pull/144922#discussion_r2158495067) for discussion. We also agreed that this can be done incrementally (see [here](https://github.com/llvm/llvm-project/pull/144922#issuecomment-2990578488)), but others welcome to join this conversation and express their thoughts on it.
https://github.com/llvm/llvm-project/pull/144922
More information about the Mlir-commits
mailing list