<html>
<head>
<base href="http://llvm.org/bugs/" />
</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 --- - [PRE] Failure to lift loop invariant load"
href="http://llvm.org/bugs/show_bug.cgi?id=22266">22266</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[PRE] Failure to lift loop invariant load
</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>normal
</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>listmail@philipreames.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>Given this test case, our current LoopPRE does not lift the loop invariant load
from %q.
; RUN: opt -S -basicaa -gvn %s
; Function Attrs: readonly
declare void @hold(i32) #0
define i32 @test1(i1 %cnd, i32* %p, i32* dereferenceable(8) %q) {
entry:
br label %header
header: ; preds = %inner, %entry
br i1 %cnd, label %exit, label %inner
inner: ; preds = %header
%v2 = load i32* %p
%v3 = load i32* %q
%sub = sub i32 %v3, %v2
call void @hold(i32 %sub)
br label %header
exit: ; preds = %header
ret i32 0
}
attributes #0 = { readonly }
This test case is mostly chosen to highlight a weakness with our current
establishment of profitability in PRE. The LICM pass does get this case, so
the actual test case isn't interesting other than that it sometimes arises due
to pass ordering.
LoadPRE gives up when while trying to find a reasonable merge point because it
encounters a block with multiple successors (i.e. header). As this case
illustrates, that's clearly not always the best choice.
If we know that the pointer in question is dereferencable, we can relax the
profitability part of the anticipation notion. Here are a few heuristics that
*might* make sense:
- Skip over all loop exits
- Skip over any split where the other paths are 'cold enough'
- Skip over any split if the load is trivially available along that path (this
happens a lot with multiple latch loops)
Note that this is *only* legal to do for dereferencable pointers. Lifting the
load of %p without first recognizing that the condition is itself loop
invariant would be illegal. It could introduce a fault which didn't occur in
the original program.</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>