<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 9, 2015 at 5:53 PM Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10351-23185951&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=2lRPfAZVulAX8N3FKgbKqF0SpdaTZ6FC8Alrysj54cA&s=s1SpDH9Ini6RvDnl05NLtctBwwViuRsodGfFsipGeqA&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10351#185951</a>, @dberlin wrote:<br>
<br>
> No, they aren't, and it will in fact, often get the wrong location for this.<br>
><br>
> But given how GVN works, and the expectation that it has that<br>
>  phitransaddr will insert instructions for it,<br>
>  this is pretty much the best you can do (unless you want to do nothing).<br>
><br>
> This is because PHITransAddr does not have any clue in the world about<br>
>  what computation it is really going to eventually replace, and GVN<br>
>  can't tell it, because GVN doesn't know either.<br>
><br>
> (Basically, GVN is asking phi translate "here's a load, translate all<br>
>  of it's parts". PHI Translate doesn't just do phi translation, it will<br>
>  in fact, go off looking to see if something might have the same<br>
>  operands as the result, etc).<br>
<br>
<br>
Right... But why is this wrong?</blockquote><div><br></div><div>Wrong is a strong term. There are no right answers here unless you do piece-by-piece insertion of the original computation.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Suppose GVN replaces a Load L in the basic block BB_3,<br>
and the address computation for L involves values V1 from BB_1 (with location Loc_1) and V2 from BB_2 (with location Loc_2).<br></blockquote><div> </div><div>This is the simple "depth 1" case i mentioned will work.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PHITransAddr basically just re-creates the address computation in some predecessor of BB_3.</blockquote><div><br></div><div>basically is the part that is right.</div><div>But what it *inserts* is not always  1:1 equivalent with the original set of expressions that generate the address computation.</div><div><br></div><div>If it was just doing "create original address computation piece by piece", it would always be correct to associate them with the equivalent values.</div><div>But as you can see, it does simplification, rearrangement, and equivalent expression finding.</div><div><br></div><div>This means the input inst might not always be the best choice of location, as the computation it has inserted might not be doing the part input inst did at all. The only guarantee you get is that the end result produces the same value. Not that it does it the same way in the same pieces in the same order.</div><div><br></div><div>(It may also cause debug locations that seriously jump around when it reuses existing expressions willy-nilly). </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Shouldn't instructions re-computing V1 and V2 be associated with the same locations Loc_1 and Loc_2 as the original values?<br></blockquote><div><br></div><div>Yes. </div><div>But the relationship of the input Inst computation  to what it *inserts* is not 1 to 1</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> It will be "mostly" right for "depth 1" phi translation, however.<br>
<br>
<br>
<br>
<br>
<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D10351&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=2lRPfAZVulAX8N3FKgbKqF0SpdaTZ6FC8Alrysj54cA&s=rSp9QwawjtxytJWA9TBSJn5Lpvuyc2QADJPQDee8hCo&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/D10351</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_settings_panel_emailpreferences_&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=2lRPfAZVulAX8N3FKgbKqF0SpdaTZ6FC8Alrysj54cA&s=hDV5EXjiYRNU7EzPa9m4mTRINSvrlj0dTWokmOYPi-o&e=" rel="noreferrer" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</blockquote></div></div>