<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:atrick@apple.com" title="Andrew Trick <atrick@apple.com>"> <span class="fn">Andrew Trick</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Indvars miscompile due to an incorrect max backedge taken count from SCEV."
href="http://llvm.org/bugs/show_bug.cgi?id=19799">bug 19799</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>FIXED
</td>
</tr>
<tr>
<td style="text-align:right;">Assignee</td>
<td>unassignedclangbugs@nondot.org
</td>
<td>atrick@apple.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Indvars miscompile due to an incorrect max backedge taken count from SCEV."
href="http://llvm.org/bugs/show_bug.cgi?id=19799#c9">Comment # 9</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - Indvars miscompile due to an incorrect max backedge taken count from SCEV."
href="http://llvm.org/bugs/show_bug.cgi?id=19799">bug 19799</a>
from <span class="vcard"><a class="email" href="mailto:atrick@apple.com" title="Andrew Trick <atrick@apple.com>"> <span class="fn">Andrew Trick</span></a>
</span></b>
<pre>Fixed in r209358.
Author: Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>>
Date: Wed May 21 17:23:48 2014
Fix a bug in SCEV's backedge taken count computation from my prior fix in
Jan.
This has to do with the trip count computation for loops with multiple
exits, which is quite subtle. Most passes just ask for a single trip
count number, so we must be conservative assuming any exit could be
taken. Normally, we rely on the "exact" trip count, which was
correctly given as "unknown". However, SCEV also gives a "max"
back-edge taken count. The loops max BE taken count is conservatively
a maximum over the max of each exit's non-exiting iterations
count. Note that some exit tests can be skipped so the max loop
back-edge taken count can actually exceed the max non-exiting
iterations for some exits. However, when we know the loop *latch*
cannot be skipped, we can directly use its max taken count
disregarding other exits. I previously took the minimum here without
checking whether the other exit could be skipped. The correct, and
simpler thing to do here is just to directly use the loop latch's max
non-exiting iterations as the loops max back-edge count.
In the problematic test case, the first loop exit had a max of zero
non-exiting iterations, but could be skipped. The loop latch was known
not to be skipped but had max of one non-exiting iteration. We
incorrectly claimed the loop back-edge could be taken zero times, when
it is actually taken one time.
Fixes Loop %for.body.i: <multiple exits> Unpredictable backedge-taken
count.
Loop %for.body.i: max backedge-taken count is 1.</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>