<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 16, 2017 at 2:46 AM, Mikael Holmén <span dir="ltr"><<a href="mailto:mikael.holmen@ericsson.com" target="_blank">mikael.holmen@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<span class="gmail-"><br>
<br>
On 01/13/2017 10:29 PM, Daniel Berlin wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yeah, there's a lot of things this could be.<br>
<br>
On the memdep side:<br>
Note that memdep is not actually properly updated in all cases by most<br>
passes that claim to not invalidate it (they don't invalidate dependent<br>
pointers, only pointers they directly touch).<br>
<br>
There's already a bug filed about this.<br>
</blockquote>
<br></span>
You mean<br>
 <a href="https://llvm.org/bugs/show_bug.cgi?id=27740" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bu<wbr>g.cgi?id=27740</a><br>
?</blockquote><div>Among others.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So far we've only seen<br>
missed-opt, not wrong code from this.<br>
But it should be possible to generate wrong code bugs with it (if you<br>
place the load/store in a place that invalidates the cached dependent<br>
result) , so i wonder if this is one.<br>
</blockquote>
<br></span>
Any idea what to do about it?<br>
<br></blockquote><div>It depends on where the real bug is.</div><div><br></div><div><br>You filed a reproducer that does not require running the other passes first, which means it's either just a bug in PRE, or a bug in memdep.</div><div><br></div><div>If i was a betting man, i'd bet on PRE and it's inter-iteration pre attempts.</div><div>Staring at this case for a second, my money is on the following happening.</div><div><br></div><div>1. PRE starts by asking if the value of step[i] where i == 0 is fully available in all preds</div><div>2. PHITransaddr get it as part of memdep, and inside of those preds (which are in loop 1, not loop2), using it's magical powers, gives an answer about step[i] (note, not step[0]) instead.  This answer may even be valid in the loop.  The problem  may even be related to the fact that the loops both iterate the same way (so it thinks step[i] is valid in both, even though the i's are different).</div><div>3. The answer is not valid outside of the loop, but it now thinks the value is fully available</div><div>4. It performs insertions and gives you the wrong answer.</div><div><br></div><div>If i disable all of phitransaddr's fun magic, your testcase starts working.</div><div><br></div><div>I'll be honest, i don't have the energy ATM to track down what fun safety condition it's missing here.</div><div>I'd actually rather disable the code (which is a mess) and focus on improving looploadelimination.</div><div>Maybe someone else wants to take a look at it.</div><div><br></div><div>(I'll add all this to the bug)</div><div><br></div><div>--Dan</div><div><br></div></div></div></div>