v01dXYZ
commented
3 days ago It seems the infinite loop is there (BranchFolding.cpp)
bool MadeChangeThisIteration = true;
while (MadeChangeThisIteration) {
MadeChangeThisIteration = TailMergeBlocks(MF);
// No need to clean up if tail merging does not change anything after the
// block placement.
if (!AfterBlockPlacement || MadeChangeThisIteration)
MadeChangeThisIteration |= OptimizeBranches(MF);
if (EnableHoistCommonCode)
MadeChangeThisIteration |= HoistCommonCode(MF);
MadeChange |= MadeChangeThisIteration;
}The part in OptimizeBlock that will always change the MachineFunction:
// Okay, there is no really great place to put this block. If, however,
// the block before this one would be a fall-through if this block were
// removed, move this block to the end of the function. There is no real
// advantage in "falling through" to an EH block, so we don't want to
// perform this transformation for that case.
//
// Also, Windows EH introduced the possibility of an arbitrary number of
// successors to a given block. The analyzeBranch call does not consider
// exception handling and so we can get in a state where a block
// containing a call is followed by multiple EH blocks that would be
// rotated infinitely at the end of the function if the transformation
// below were performed for EH "FallThrough" blocks. Therefore, even if
// that appears not to be happening anymore, we should assume that it is
// possible and not remove the "!FallThrough()->isEHPad" condition below.
MachineBasicBlock *PrevTBB = nullptr, *PrevFBB = nullptr;
SmallVector<MachineOperand, 4> PrevCond;
if (FallThrough != MF.end() &&
!FallThrough->isEHPad() &&
!TII->analyzeBranch(PrevBB, PrevTBB, PrevFBB, PrevCond, true) &&
PrevBB.isSuccessor(&*FallThrough)) {
MBB->moveAfter(&MF.back());
MadeChange = true;
return MadeChange;
}No need for three blocks the problem appears with two too:
define void @test() {
start:
br label %bb1
bb1:
callbr void asm "", "!i,!i"()
to label %bb1 [label %bb2, label %bb3]
bb2:
br label %bb1
bb3:
br label %bb1
}The infinite loop keeps swapping the two blocks.
llc hangs on this reduced example:
Example backtrace:
in which number 6 is the function that never returns. (I don't have a more recent version on hand locally, but trunk does time out as well on https://godbolt.org/z/xn1PGhbdG)
Reduced from the original Rust code: https://rust.godbolt.org/z/snGq3raxc