[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