<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 - SimpleLoopUnswitch not informing pass manager when child loops are deleted during nontrivial unswitch"
href="https://bugs.llvm.org/show_bug.cgi?id=51754">51754</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>SimpleLoopUnswitch not informing pass manager when child loops are deleted during nontrivial unswitch
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</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>Scalar Optimizations
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bjorn.a.pettersson@ericsson.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Problems were observed downstream when running tests using "opt
-enable-new-pm=1 -O3 -S -extra-vectorizer-passes=1 -enable-loop-distribute".
For a specific input the compiler sometimes just crashed, sometimes we hit an
assertion, etc. Although this was very non-deterministic and it only failed
occasionally.
A somewhat reduced test case included 2 functions "foo" and "bar". And some
debugging indicated the following scenario:
1) When running loop-distribute on "foo" LoopAccessAnalysis was calculated for
some loops in that functions. Those analyses were cached in the
LoopAnalysisManager associated with a LoopAnalysisManagerFunctionProxy based on
a Loop*.
2) Later when running SimpleLoopUnswitch a loop "a" was transformed, and as
part of that a child loop "b" was removed/replaced. The Loop object for "b" was
destroyed (still being allocated by the BumpPtrAllocator, and without removing
the analyses cached on the corresponding Loop*).
3) Here something triggeres a reset of the BumpPtrAllocator used for allocating
Loop objects (maybe throwing away loop analyses at the end of the loop pass
manager).
4) When running loop-distribution later, for "bar", first a Loop object was
created for a loop "c". And then LoopAccessAnalysis were requested. Depending
on if the Loop object for "c" happened to use the same address as the stale
analysis for loop "b" we sometimes ended up fetching the LoopAccessAnalysis
result for "b" instead of recalculating the analysis for "c".</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>