<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Assertion `DT && "DT should be available to update LoopInfo!"' failed."
href="https://bugs.llvm.org/show_bug.cgi?id=37334">37334</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Assertion `DT && "DT should be available to update LoopInfo!"' failed.
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mikael.holmen@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>