[PATCH] D14996: [WinEH] Avoid infinite loop in BranchFolding for multiple single block funclets

Joseph Tremoulet via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 1 21:58:15 PST 2015


JosephTremoulet added a comment.

Thanks for the explanation.  I buy your argument that the code as you have it is correct, modulo some minor (non-blocking) qualms about the possibility of other pseudo-op terminators that have the same qualities we're seeing with cleanupret but aren't EH-related.

However, this also gets me wondering whether the optimization really ought to be firing in this situation in the first place.  The comment mentions that we're looking for situations where "the block before this one would be a fall-through if this block were removed", but then the check for that is just that there is a flow edge with an analyzable terminator from the previous block to the later block, and I think what you're saying is that with these nonterminating EH cases it turns out that even when you make those blocks adjacent, the edge can't become fallthrough.  So maybe it would be simpler and lose no optimization opportunities if we just reject cases where the later block is an EH Funclet entry, since those can never be fallen into?


================
Comment at: lib/CodeGen/BranchFolding.cpp:1563
@@ -1562,2 +1562,3 @@
           !TII->AnalyzeBranch(PrevBB, PrevTBB, PrevFBB, PrevCond, true) &&
           PrevBB.isSuccessor(&*FallThrough)) {
+        MachineFunction::iterator InsertAfter = MF.back().getIterator();
----------------
i.e. maybe we just want to add ` && !FallThrough->isEHFuncletEntry()` to this condition?  (or if there's some predicate like `canBeFallenInto(&*FallThrough)` that could be used, all the better)


Repository:
  rL LLVM

http://reviews.llvm.org/D14996





More information about the llvm-commits mailing list