[llvm] [SCEV] Fix a hang introduced by collectForPHI (PR #158153)

Philip Reames via llvm-commits llvm-commits at lists.llvm.org
Fri Sep 12 09:58:13 PDT 2025


================
@@ -364,3 +364,29 @@ body:
 exit:
   ret void
 }
+
+define void @hang_due_to_unreachable_phi_inblock() personality ptr null {
+bb:
+  br label %bb6
+
+self-loop:                                        ; preds = %self-loop
+  %dead = invoke ptr null()
+          to label %self-loop unwind label %bb4
----------------
preames wrote:

Oh, I figured out the difference.
```
for (; Pair.first;
       Pair = SE.getPredecessorWithUniqueSuccessorForBB(Pair.first)) {
    VisitedBlocks.insert(Pair.second);
    const BranchInst *LoopEntryPredicate =
        dyn_cast<BranchInst>(Pair.first->getTerminator());
    if (!LoopEntryPredicate || LoopEntryPredicate->isUnconditional())
      continue;

    Terms.emplace_back(LoopEntryPredicate->getCondition(),
                       LoopEntryPredicate->getSuccessor(0) == Pair.second);
    NumCollectedConditions++;

    // If we are recursively collecting guards stop after 2
    // conditions to limit compile-time impact for now.
    if (Depth > 0 && NumCollectedConditions == 2)
      break;
  }
```
This the loop which is actually infintte.  The Depth on this example is 1.  As a result, if the cycle we're looping on contains a conditional branch, we hit the NumCollectedConditions guard.  Per the comment, it wasn't meant to be functional, but that explains why we hit this so rarely.  

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


More information about the llvm-commits mailing list