[llvm-bugs] [Bug 37334] New: Assertion `DT && "DT should be available to update LoopInfo!"' failed.

[via llvm-bugs]

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

            Bug ID: 37334
           Summary: Assertion `DT && "DT should be available to update
                    LoopInfo!"' failed.
           Product: new-bugs
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: llvm-bugs at lists.llvm.org

Reproduce with
 opt -loop-sink -break-crit-edges -branch-prob -S -o - tr15969.ll

which yields:

opt: ../lib/Transforms/Utils/BasicBlockUtils.cpp:336: void
UpdateAnalysisInformation(llvm::BasicBlock *, llvm::BasicBlock *,
ArrayRef<llvm::BasicBlock *>, llvm::DominatorTree *, llvm::LoopInfo *, bool,
bool &): Assertion `DT && "DT should be available to update LoopInfo!"' failed.
Stack dump:
0.      Program arguments: ../llvm-patch/build-all/bin/opt -loop-sink
-break-crit-edges -branch-prob -S -o - tr15969.ll 
1.      Running pass 'Function Pass Manager' on module 'tr15969.ll'.
2.      Running pass 'Break critical edges in CFG' on function '@f1'
#0 0x0000000001f68bf4 PrintStackTraceSignalHandler(void*)
(../llvm-patch/build-all/bin/opt+0x1f68bf4)
#1 0x0000000001f69366 SignalHandler(int)
(../llvm-patch/build-all/bin/opt+0x1f69366)
#2 0x00007feffab2b330 __restore_rt
(/lib/x86_64-linux-gnu/libpthread.so.0+0x10330)
#3 0x00007feff971ac37 gsignal
/build/eglibc-ripdx6/eglibc-2.19/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0
#4 0x00007feff971e028 abort
/build/eglibc-ripdx6/eglibc-2.19/stdlib/abort.c:91:0
#5 0x00007feff9713bf6 __assert_fail_base
/build/eglibc-ripdx6/eglibc-2.19/assert/assert.c:92:0
#6 0x00007feff9713ca2 (/lib/x86_64-linux-gnu/libc.so.6+0x2fca2)
#7 0x0000000001f7fb8f UpdateAnalysisInformation(llvm::BasicBlock*,
llvm::BasicBlock*, llvm::ArrayRef<llvm::BasicBlock*>, llvm::DominatorTree*,
llvm::LoopInfo*, bool, bool&) (../llvm-patch/build-all/bin/opt+0x1f7fb8f)
#8 0x0000000001f7e865 llvm::SplitBlockPredecessors(llvm::BasicBlock*,
llvm::ArrayRef<llvm::BasicBlock*>, char const*, llvm::DominatorTree*,
llvm::LoopInfo*, bool) (../llvm-patch/build-all/bin/opt+0x1f7e865)
#9 0x0000000001f8293c llvm::SplitCriticalEdge(llvm::TerminatorInst*, unsigned
int, llvm::CriticalEdgeSplittingOptions const&)
(../llvm-patch/build-all/bin/opt+0x1f8293c)
#10 0x0000000001f7e51d llvm::SplitAllCriticalEdges(llvm::Function&,
llvm::CriticalEdgeSplittingOptions const&)
(../llvm-patch/build-all/bin/opt+0x1f7e51d)
#11 0x0000000001f83cf5 (anonymous
namespace)::BreakCriticalEdges::runOnFunction(llvm::Function&)
(../llvm-patch/build-all/bin/opt+0x1f83cf5)
#12 0x0000000001a0e298 llvm::FPPassManager::runOnFunction(llvm::Function&)
(../llvm-patch/build-all/bin/opt+0x1a0e298)
#13 0x0000000001a0e4d8 llvm::FPPassManager::runOnModule(llvm::Module&)
(../llvm-patch/build-all/bin/opt+0x1a0e4d8)
#14 0x0000000001a0e9b5 llvm::legacy::PassManagerImpl::run(llvm::Module&)
(../llvm-patch/build-all/bin/opt+0x1a0e9b5)
#15 0x0000000000738b35 main (../llvm-patch/build-all/bin/opt+0x738b35)
#16 0x00007feff9705f45 __libc_start_main
/build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:321:0
#17 0x00000000007225fd _start (../llvm-patch/build-all/bin/opt+0x7225fd)


It starts crashing with commit r321653
<pre>
    [BasicBlockUtils] Check for unreachable preds before updating LI in
UpdateAnalysisInformation

    Summary:
    We are incorrectly updating the LI when loop-simplify generates
    dedicated exit blocks for a loop. The issue is that there's an implicit
    assumption that the Preds passed into UpdateAnalysisInformation are
    reachable. However, this is not true and breaks LI by incorrectly
    updating the header of a loop.

    One such case is when we generate dedicated exits when the exit block is
    a landing pad (through SplitLandingPadPredecessors). There maybe other
    cases as well, since we do not guarantee that Preds passed in are
    reachable basic blocks.

    The added test case shows how loop-simplify breaks LI for the outer loop
(and DT in turn)
    after we try to generate the LoopSimplifyForm.
</pre>
and then the assert we see nowadays was added in r321805:
<pre>
    Add assertion on DT availability during LI update in
UpdateAnalysisInformation

    This came up during discussions in llvm-commits for
    rL321653: Check for unreachable preds before updating LI in
    UpdateAnalysisInformation

    The assert provides hints to passes to require both DT and LI if we plan on
    updating LI through this function.
</pre>

Especially note the last sentence in the last commit:
<pre>
The assert provides hints to passes to require both DT and LI if we plan on
updating LI through this function.
</pre>

Looking at BreakCriticalEdges.cpp it does:
<pre>
    void getAnalysisUsage(AnalysisUsage &AU) const override {
      AU.addPreserved<DominatorTreeWrapperPass>();
      AU.addPreserved<LoopInfoWrapperPass>();

      // No loop canonicalization guarantees are broken by this pass.
      AU.addPreservedID(LoopSimplifyID);
    }
</pre>
so it says it preserves DT and LI but it doesn't require them. It seems like
the
pass tries to update DT and LI if they exist but it doesn't require them, but
since the commits above it seems like updating LI, which does
SplitBlockPredecessors, actually also requires DT?

-- 
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/20180504/282e89d8/attachment-0001.html>