[Mlir-commits] [mlir] [mlir][linalg] Extend `FuseElementwiseOps` pattern to work with named ops (PR #144922)

llvmlistbot at llvm.org llvmlistbot at llvm.org
Mon Nov 10 07:14:50 PST 2025


================
@@ -554,23 +554,42 @@ FailureOr<DropUnitDimsResult> dropUnitDims(RewriterBase &rewriter,
                                            GenericOp genericOp,
                                            const ControlDropUnitDims &options);
 
-/// Fuse two `linalg.generic` operations that have a producer-consumer
+/// Base implementation for fusion of two linalg operations.
+/// Fuse two linalg operations that have a producer-consumer
 /// relationship captured through `fusedOperand`. The method expects
 /// that `areElementwiseOpsFusable` returns true for the given `fusedOperand`.
+/// The resulting fused operation is always a `linalg.generic`.
+/// TODO: Support fusing to named ops when possible.  For many cases,
+/// `linalg.generic` is the only op that is capable of representing the fused
+/// operation. An example exception is fusing two `linalg.map` ops.  The fused
+/// result can also be represented by `linalg.map`.
 struct ElementwiseOpFusionResult {
   Operation *fusedOp;
   llvm::DenseMap<Value, Value> replacements;
 };
+template <typename LinagOpTy>
 FailureOr<ElementwiseOpFusionResult>
-fuseElementwiseOps(RewriterBase &rewriter, OpOperand *fusedOperand);
+fuseElementwiseLinalgOpsImpl(RewriterBase &rewriter, OpOperand *fusedOperand);
+
+/// Specialization of `fuseElementwiseLinalgOpsImpl` for a producer-consumer of
+/// `fusedOperand` that are any `LinalgOp`.
+FailureOr<ElementwiseOpFusionResult>
+fuseElementwiseLinalgOps(RewriterBase &rewriter, OpOperand *fusedOperand);
+
+/// Specialization `fuseElementwiseLinalgOpsImpl` restricted to
----------------
srcarroll wrote:

do you have a real reason to keep the original name?  I have two reasons not to keep it
1. In the context of now having two functions that do almost the exact same thing, `fuseElementwiseOps` isn't descriptive enough to indicate what is special about this version
2. It forces downstream users to recognize that there has been a change, so they can decide for themselves which one they want to use.

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


More information about the Mlir-commits mailing list