[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