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

llvmlistbot at llvm.org llvmlistbot at llvm.org
Sun Nov 16 13:55:40 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:

>you will get a cast error when fusedOperand's producer and consumer are not of the specified LinalgOpTy

Although I guess this was pre-existing behavior anyway with 'GenericOp', so I guess it's ok?  Even if I didn't apply the suggestion, this behavior would persist but for 'LinalgOp'. So either way I'm not sure I like this behavior.

I guess this is a more general question.  Should these functions crash when fusedOperand is incompatible or should they return a failure?

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


More information about the Mlir-commits mailing list