[Mlir-commits] [mlir] [mlir][affine] Avoid fusion when the sibling loop has result usage (PR #216564)

Uday Bondhugula llvmlistbot at llvm.org
Sun Sep 13 00:28:44 PDT 2026


================
@@ -113,11 +114,14 @@ canFuseLoops(AffineForOp srcForOp, AffineForOp dstForOp, unsigned dstLoopDepth,
 
 /// Fuses 'srcForOp' into 'dstForOp' with destination loop block insertion
 /// point and source slice loop bounds specified in 'srcSlice'.
-/// `isInnermostSiblingInsertionFusion` enables cleanup of `srcForOp that is a
+/// `isInnermostSiblingInsertionFusion` enables cleanup of `srcForOp` that is a
 /// single-iteration reduction loop being sibling-fused into a 'dstForOp'.
+/// If provided, `mapper` records the mapping from the source loop IR to the
+/// cloned loop IR.
 void fuseLoops(AffineForOp srcForOp, AffineForOp dstForOp,
                const ComputationSliceState &srcSlice,
-               bool isInnermostSiblingInsertionFusion = false);
+               bool isInnermostSiblingInsertionFusion = false,
+               IRMapping *mapper = nullptr);
----------------
bondhugula wrote:

This isn't the right content for this PR. Looks like the commits have more than what the title and summary says. Please keep this PR change restricted to the PR title. Any additional support can be reviewed separately. You shouldn't actually need to pass the IRMapper this way. Existing producer-consumer fusion doesn't support fusion in the presence of yield results as well AFAIR - since affine fusion deal with memref-based dependences and SSA dependences in and across loops that don't have cross-loop data flow (iter-args) - such dependences are captured via memory.

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


More information about the Mlir-commits mailing list