Skip to content

[CoroSplit] Always erase lifetime intrinsics for spilled allocas #142551

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jun 3, 2025

Conversation

NewSigma
Copy link
Contributor

@NewSigma NewSigma commented Jun 3, 2025

If the control flow between lifetime.start and lifetime.end is too complex, it is acceptable to give up the optimization opportunity and collect the alloca to the frame. However, storing to the frame will lengthen the lifetime of the alloca, and the sanitizer will complain. I propose we always erase lifetime intrinsics of spilled allocas.

Fix #124612

@llvmbot
Copy link
Member

llvmbot commented Jun 3, 2025

@llvm/pr-subscribers-coroutines

Author: Weibo He (NewSigma)

Changes

If the control flow between lifetime.start and lifetime.end is too complex, it is acceptable to give up the optimization opportunity and collect the alloca to the frame. However, storing to the frame will lengthen the lifetime of the alloca, and the sanitizer will complain. I propose we always erase lifetime intrinsics of spilled allocas.

Fix #124612


Full diff: https://github.com/llvm/llvm-project/pull/142551.diff

1 Files Affected:

  • (modified) llvm/lib/Transforms/Coroutines/CoroFrame.cpp (+14-11)
diff --git a/llvm/lib/Transforms/Coroutines/CoroFrame.cpp b/llvm/lib/Transforms/Coroutines/CoroFrame.cpp
index 2f5f1089067bf..fdfddcc3425e9 100644
--- a/llvm/lib/Transforms/Coroutines/CoroFrame.cpp
+++ b/llvm/lib/Transforms/Coroutines/CoroFrame.cpp
@@ -1212,14 +1212,26 @@ static void insertSpills(const FrameDataInfo &FrameData, coro::Shape &Shape) {
   Builder.SetInsertPoint(Shape.AllocaSpillBlock,
                          Shape.AllocaSpillBlock->begin());
   SmallVector<Instruction *, 4> UsersToUpdate;
+  SmallVector<Instruction *, 4> Lifetimes;
   for (const auto &A : FrameData.Allocas) {
     AllocaInst *Alloca = A.Alloca;
     UsersToUpdate.clear();
+    Lifetimes.clear();
     for (User *U : Alloca->users()) {
       auto *I = cast<Instruction>(U);
-      if (DT.dominates(Shape.CoroBegin, I))
+      if (I->isLifetimeStartOrEnd())
+        Lifetimes.push_back(I);
+      else if (DT.dominates(Shape.CoroBegin, I))
         UsersToUpdate.push_back(I);
     }
+
+    // If it is hard to analyze, we will give up and put allocas to frame,
+    // even if they never cross suspend points.
+    // Lifetime intrinsics referring to alloca may fail guard storing to frame.
+    // Lifetime intrinsics referring to frames may block further optimizations.
+    for (auto *I : Lifetimes)
+      I->eraseFromParent();
+
     if (UsersToUpdate.empty())
       continue;
     auto *G = GetFramePointer(Alloca);
@@ -1233,17 +1245,8 @@ static void insertSpills(const FrameDataInfo &FrameData, coro::Shape &Shape) {
     for (auto *DVR : DbgVariableRecords)
       DVR->replaceVariableLocationOp(Alloca, G);
 
-    for (Instruction *I : UsersToUpdate) {
-      // It is meaningless to retain the lifetime intrinsics refer for the
-      // member of coroutine frames and the meaningless lifetime intrinsics
-      // are possible to block further optimizations.
-      if (I->isLifetimeStartOrEnd()) {
-        I->eraseFromParent();
-        continue;
-      }
-
+    for (Instruction *I : UsersToUpdate)
       I->replaceUsesOfWith(Alloca, G);
-    }
   }
   Builder.SetInsertPoint(&*Shape.getInsertPtAfterFramePtr());
   for (const auto &A : FrameData.Allocas) {

@llvmbot
Copy link
Member

llvmbot commented Jun 3, 2025

@llvm/pr-subscribers-llvm-transforms

Author: Weibo He (NewSigma)

Changes

If the control flow between lifetime.start and lifetime.end is too complex, it is acceptable to give up the optimization opportunity and collect the alloca to the frame. However, storing to the frame will lengthen the lifetime of the alloca, and the sanitizer will complain. I propose we always erase lifetime intrinsics of spilled allocas.

Fix #124612


Full diff: https://github.com/llvm/llvm-project/pull/142551.diff

1 Files Affected:

  • (modified) llvm/lib/Transforms/Coroutines/CoroFrame.cpp (+14-11)
diff --git a/llvm/lib/Transforms/Coroutines/CoroFrame.cpp b/llvm/lib/Transforms/Coroutines/CoroFrame.cpp
index 2f5f1089067bf..fdfddcc3425e9 100644
--- a/llvm/lib/Transforms/Coroutines/CoroFrame.cpp
+++ b/llvm/lib/Transforms/Coroutines/CoroFrame.cpp
@@ -1212,14 +1212,26 @@ static void insertSpills(const FrameDataInfo &FrameData, coro::Shape &Shape) {
   Builder.SetInsertPoint(Shape.AllocaSpillBlock,
                          Shape.AllocaSpillBlock->begin());
   SmallVector<Instruction *, 4> UsersToUpdate;
+  SmallVector<Instruction *, 4> Lifetimes;
   for (const auto &A : FrameData.Allocas) {
     AllocaInst *Alloca = A.Alloca;
     UsersToUpdate.clear();
+    Lifetimes.clear();
     for (User *U : Alloca->users()) {
       auto *I = cast<Instruction>(U);
-      if (DT.dominates(Shape.CoroBegin, I))
+      if (I->isLifetimeStartOrEnd())
+        Lifetimes.push_back(I);
+      else if (DT.dominates(Shape.CoroBegin, I))
         UsersToUpdate.push_back(I);
     }
+
+    // If it is hard to analyze, we will give up and put allocas to frame,
+    // even if they never cross suspend points.
+    // Lifetime intrinsics referring to alloca may fail guard storing to frame.
+    // Lifetime intrinsics referring to frames may block further optimizations.
+    for (auto *I : Lifetimes)
+      I->eraseFromParent();
+
     if (UsersToUpdate.empty())
       continue;
     auto *G = GetFramePointer(Alloca);
@@ -1233,17 +1245,8 @@ static void insertSpills(const FrameDataInfo &FrameData, coro::Shape &Shape) {
     for (auto *DVR : DbgVariableRecords)
       DVR->replaceVariableLocationOp(Alloca, G);
 
-    for (Instruction *I : UsersToUpdate) {
-      // It is meaningless to retain the lifetime intrinsics refer for the
-      // member of coroutine frames and the meaningless lifetime intrinsics
-      // are possible to block further optimizations.
-      if (I->isLifetimeStartOrEnd()) {
-        I->eraseFromParent();
-        continue;
-      }
-
+    for (Instruction *I : UsersToUpdate)
       I->replaceUsesOfWith(Alloca, G);
-    }
   }
   Builder.SetInsertPoint(&*Shape.getInsertPtAfterFramePtr());
   for (const auto &A : FrameData.Allocas) {

Copy link
Member

@ChuanqiXu9 ChuanqiXu9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ChuanqiXu9 ChuanqiXu9 merged commit 038dc2c into llvm:main Jun 3, 2025
11 checks passed
@NewSigma NewSigma deleted the erase-spilled-lifetimes branch June 3, 2025 11:50
rorth pushed a commit to rorth/llvm-project that referenced this pull request Jun 11, 2025
…m#142551)

If the control flow between `lifetime.start` and `lifetime.end` is too
complex, it is acceptable to give up the optimization opportunity and
collect the alloca to the frame. However, storing to the frame will
lengthen the lifetime of the alloca, and the sanitizer will complain. I
propose we always erase lifetime intrinsics of spilled allocas.

Fix llvm#124612

---------

Co-authored-by: Chuanqi Xu <[email protected]>
DhruvSrivastavaX pushed a commit to DhruvSrivastavaX/lldb-for-aix that referenced this pull request Jun 12, 2025
…m#142551)

If the control flow between `lifetime.start` and `lifetime.end` is too
complex, it is acceptable to give up the optimization opportunity and
collect the alloca to the frame. However, storing to the frame will
lengthen the lifetime of the alloca, and the sanitizer will complain. I
propose we always erase lifetime intrinsics of spilled allocas.

Fix llvm#124612

---------

Co-authored-by: Chuanqi Xu <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

C++20 coroutine with stateful allocator results in ASAN stack-use-after-scope starting with clang 19
3 participants