<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 --- - [EarlyCSE, Missed Opt] Don't need to advance generation number unless mayalias"
href="http://llvm.org/bugs/show_bug.cgi?id=20805">20805</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[EarlyCSE, Missed Opt] Don't need to advance generation number unless mayalias
</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>Created <span class=""><a href="attachment.cgi?id=12955" name="attach_12955" title="Failing test case for missed optimization 1">attachment 12955</a> <a href="attachment.cgi?id=12955&action=edit" title="Failing test case for missed optimization 1">[details]</a></span>
Failing test case for missed optimization 1
In EarlyCSE, we currently advance the generation number when we encounter a
store. If the store we encounter does not alias any of the loads encountered
since the previous store (i.e. in the current generation), then we can continue
to forward their values across the store. As a result, we can avoid advancing
the generation number in this case.
I've attached a test case which illustrates a profitable case. To actually
implement this, we'd probably want to bound the number of locations considered
when deciding to advance the generation number.
Note that <a class="bz_bug_link
bz_status_NEW "
title="NEW --- - [EarlyCSE, Missed Opt] Prefer to remove later store where possible"
href="show_bug.cgi?id=20804">http://llvm.org/bugs/show_bug.cgi?id=20804</a> relies on similiar logic
to remove the store itself in some cases. They may be worth implementing
together.
As a further optimization, we may be able to advance some of the loads from the
previous generation into the next, even if we do need to advance the generation
number. Any load which is provably noalias with the store location should be
safe to add to the new generation.
I haven't attached a test case for this one, but it should be easily to derive
from the previous one.</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>