[Mlir-commits] [mlir] [SCF][Transform] Add support for scf.for in LoopFuseSibling op (PR #81495)
Rolf Morel
llvmlistbot at llvm.org
Mon Mar 25 04:48:10 PDT 2024
================
@@ -970,3 +970,69 @@ scf::ForallOp mlir::fuseIndependentSiblingForallLoops(scf::ForallOp target,
return fusedLoop;
}
+
+scf::ForOp mlir::fuseIndependentSiblingForLoops(scf::ForOp target,
+ scf::ForOp source,
+ RewriterBase &rewriter) {
+ // Create fused init_args.
+ auto targetInitArgs = target.getInitArgs();
+ auto sourceInitArgs = source.getInitArgs();
+ SmallVector<Value> fusedInitArgs;
+ fusedInitArgs.reserve(targetInitArgs.size() + sourceInitArgs.size());
+ fusedInitArgs.append(sourceInitArgs.begin(), sourceInitArgs.end());
+ fusedInitArgs.append(targetInitArgs.begin(), targetInitArgs.end());
+
+ // Create a new scf::for op after the source loop.
+ rewriter.setInsertionPointAfter(source);
+ scf::ForOp fusedLoop = rewriter.create<scf::ForOp>(
+ source.getLoc(), source.getLowerBound(), source.getUpperBound(),
+ source.getStep(), fusedInitArgs);
----------------
rolfmorel wrote:
You are right, this is still the case. Have now added the guard `if (yieldResults.size())` right before creating the `scf.yield`. (When `yieldResults` is empty neither loop had `iter_args` so the newly created loop will already have its terminator.)
Have added a test as well.
https://github.com/llvm/llvm-project/pull/81495
More information about the Mlir-commits
mailing list