[llvm] [coro][CoroSplit] Use `llvm.lifetime.end` to compute putting objects on the frame vs the stack (PR #90265)

Chuanqi Xu via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 29 22:58:44 PDT 2024


================
@@ -1614,6 +1621,24 @@ struct AllocaUseVisitor : PtrUseVisitor<AllocaUseVisitor> {
       // suspend point between lifetime markers. This should also cover the
       // case of a single lifetime.start intrinsic in a loop with suspend point.
       if (PI.isEscaped()) {
+        // If there is no explicit lifetime.end, then assume the address can
+        // cross suspension points.
+        if (LifetimeEndBBs.empty())
+          return true;
+
+        // If there is a path from a lifetime.start to a suspend without a
+        // corresponding lifetime.end, then the alloca's lifetime persists
+        // beyond that suspension point and the alloca must go on the frame.
+        for (AnyCoroSuspendInst *SuspendInst : CoroShape.CoroSuspends) {
+          SmallVector<BasicBlock *> LifetimeStartsBB;
+          for (IntrinsicInst *II : LifetimeStarts)
+            LifetimeStartsBB.push_back(II->getParent());
+          if (isPotentiallyReachableFromMany(LifetimeStartsBB,
----------------
ChuanqiXu9 wrote:

Got it. Then in another perspective, if `Checker` checks whether there is a path from block A to blockB touching suspending blocks, can we create a similar checker (or refactor the existing one) to check if there is a path from blockA (the block of the a lifeitme.start) to blockB (any suspending blocks) touching ending blocks (the blocks containing corresponding lifetime.end)? Then if there is such a path, we need to put the alloca to the frame. Otherwise we can put it on the stack. It looks like it can solve the two problems you raised.

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


More information about the llvm-commits mailing list