[llvm-bugs] [Bug 43720] New: [JumpThreading] Hangs when called with complex switch/state machines as generated by coroutines

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=43720

            Bug ID: 43720
           Summary: [JumpThreading] Hangs when called with complex
                    switch/state machines as generated by coroutines
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: alex.davies at iinet.net.au
                CC: llvm-bugs at lists.llvm.org

Created attachment 22690
  --> https://bugs.llvm.org/attachment.cgi?id=22690&action=edit
A dirty workaround for the bug reported

In ProcessThreadableEdges, it is possible for PredsToFactor to be empty for its
call to "ThreadEdge".

This seemingly spins the whole thing in an infinite loop, where:

  if (PredBBs.size() == 1)
    PredBB = PredBBs[0];
  else {
    LLVM_DEBUG(dbgs() << "  Factoring out " << PredBBs.size()
                      << " common predecessors.\n");
    PredBB = SplitBlockPreds(BB, PredBBs, ".thr_comm");
  }

Writes "Factors out 0 common predecessors", which seems to be a nop, leading to
the same 0-edge being threaded again, and again, and again.

Perhaps someone who knows the code better than I can see if it is _always_ an
error to pass an empty PredBBs to ThreadEdge, in which case it should be
asserted in ThreadEdge, and/or how it's possible to end up with an empty
PredBBs in the first place.

Workaround attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20191019/2c8826e8/attachment.html>