================
@@ -1805,11 +1813,253 @@ class CIRTryOpFlattening : public
mlir::OpRewritePattern<cir::TryOp> {
}
};
+static mlir::Block *getOrCreateBlockForSuspendPoint(
+ cir::FuncOp funcOp, mlir::PatternRewriter &rewriter, mlir::Location loc) {
+ mlir::Block &entryBlock = funcOp.getBody().front();
+
+ auto it = llvm::find_if(entryBlock, [](auto &op) {
+ return mlir::isa<AllocaOp>(&op) &&
+ mlir::cast<AllocaOp>(&op).getCoroutineSuspendPoint();
+ });
+
+ assert(it->hasOneUse() &&
+ "coroutine suspend point alloca must have exactly one use");
+ auto storeOp = cast<cir::StoreOp>(*it->getUses().begin()->getOwner());
+ auto suspendPoint =
cast<cir::ConstantOp>(storeOp.getValue().getDefiningOp());
+ mlir::Block *suspendBlock = suspendPoint->getBlock();
----------------
bcardosolopes wrote:
Even setting aside the agreed redesign, note this derives the destination from
the **constant's** block (`suspendPoint->getBlock()`), not the store's.
Constants are the most mobile thing in the IR (hoisted to entry, CSE-merged
across the whole function), so any other `cir.const 1` can relocate or merge
this one and silently repoint the suspend destination, which is exactly the
fragility that motivates dropping the positional beacon. If any interim version
survives, `storeOp->getBlock()` would at least be less mobile. (Also: the
stored value `1` is currently vestigial, nothing reads it, only the position
matters — so today the mechanism only uses the half that canonicalization
breaks.)
https://github.com/llvm/llvm-project/pull/203802
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
