<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 - miscompile with opt -passes='function(loop-flatten)'"
href="https://bugs.llvm.org/show_bug.cgi?id=51980">51980</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>miscompile with opt -passes='function(loop-flatten)'
</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>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>Loop Optimizer
</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>Created <span class=""><a href="attachment.cgi?id=25296" name="attach_25296" title="bbi-60764.ll reproducer">attachment 25296</a> <a href="attachment.cgi?id=25296&action=edit" title="bbi-60764.ll reproducer">[details]</a></span>
bbi-60764.ll reproducer
llvm commit: 902ec6142a6f6
Reproduce with
opt -passes='function(loop-flatten)' -S -o - bbi-60764.ll
The input has two nested loops, the outer for i [0, 3] and the inner for j [0,
15] and loop-flatten flattens it to one loop iterating for i' in [0, 63] which
looks ok.
In the inner loop there is a load from v[16*i+j] but after flattening as far as
I can see it loads from v[16*i'] so it quickly goes out-of-bounds of v and read
random data instead.
So in the result there is
entry:
%flatten.tripcount = mul i32 16, 4
br label %for.cond1.preheader
for.cond1.preheader: ; preds = %for.cond.cleanup3,
%entry
%indvar2 = phi i32 [ %indvar.next3, %for.cond.cleanup3 ], [ 0, %entry ]
%i.013 = phi i16 [ 0, %entry ], [ %inc7, %for.cond.cleanup3 ]
%sum.012 = phi i16 [ 0, %entry ], [ %add5.lcssa, %for.cond.cleanup3 ]
%0 = mul nsw i32 %indvar2, 16
[...]
for.body4: ; preds =
%for.cond1.preheader
%indvar = phi i32 [ 0, %for.cond1.preheader ]
%2 = add nuw nsw i32 %indvar, %0
%3 = trunc i32 %2 to i16
%arrayidx = getelementptr inbounds [64 x i16], [64 x i16]* @v, i16 0, i16 %3
%4 = load i16, i16* %arrayidx, align 1
This starts happening with 6a076fa9539:
[LoopFlatten] Make the analysis more robust after IV widening
LoopFlatten wasn't triggering on this motivating case after IV widening:
void foo(int *A, int N, int M) {
for (int i = 0; i < N; ++i)
for (int j = 0; j < M; ++j)
f(A[i*M+j]);
}
The reason was that the old induction phi nodes were getting in the way.
These
narrow and dead induction phis are not always trivially dead, and having
both
the narrow and wide IVs confused the analysis and caused it to bail. This
adds
some extra bookkeeping for these old phis, so we can filter them out when
checks on phi nodes are performed. Other clean up passes will get rid of
these
old phis and increment instructions.
As this was one of the motivating examples from the beginning, it was
surprising this wasn't triggering from C/C++ code. It looks like the IR and
CFG
is just slightly different.
Differential Revision: <a href="https://reviews.llvm.org/D109309">https://reviews.llvm.org/D109309</a>
Note that before this patch, the above reproducer hit an error about a broken
PHI, so there was certainly something strange going on then too.</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>