<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 1:18 PM, Sebastian Pop <span dir="ltr"><<a href="mailto:sebpop@gmail.com" target="_blank">sebpop@gmail.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"><span class="gmail-">On Tue, Aug 2, 2016 at 3:01 PM, Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>> wrote:<br>
>> Would it be possible to merge the UseOptimizer with the renamePass?<br>
> No, because phi nodes are not guaranteed complete until after renaming is<br>
> done.<br>
<br>
</span>I'm not seeing why having incomplete phis is a problem.<br></blockquote><div><br></div><div>The use optimizer and clobber walker know how to walk past phi nodes.</div><div><br></div><div>Given</div><div>store a</div><div>if (foo)</div><div>{<br>store b</div><div>}<br>load a</div><div><br></div><div>You will  initially get:<br><div>1 = memorydef(liveonentry)</div><div>store a</div><div>if (foo)</div><div>{<br>2 = memorydef(1)</div><div>store b</div><div>}<br>3 = memoryphi(1, 2)</div><div>memoryuse(3)<br>load a</div></div><div><br></div><div><br></div><div>Note that the reaching may-def for the load is 3, but it is not actually something that actually clobbers load a.</div><div><br></div><div>The use optimizer will walk the paths of the phi node, and determine that all paths do not clobber the location "a", and thus, that the correct version for the memoryuse is "1".</div><div><br></div><div>This cannot happen if not all the paths of the phi node have been filled in.</div><div><br></div><div>Ignoring datastructure issues (the renaming algorithm relies on the stack being in dominator order):</div><div>Unless the graph is acylic, , it is not possible to come up with an ordering where every phi node will have been filled in by the time you hit uses for it.</div><div><br></div><div>Thus, we do not do use optimization during renaming.</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>
> (more particularly, there is no ordering in which to do renaming that can<br>
> guarantee you don't hit incomplete phi nodes).<br>
><br>
> At one point, we had use optimization be part of renaming, but walking<br>
> incomplete phi nodes is ....<br>
> complicated and not guaranteed to get right answers.<br>
<br>
</span>I haven't thought enough about merging the rename with the UseOptimizer:<br>
it seemed to me that in renamePass you have all the data you need<br>
to decide which is the nearest def, and decide on selecting the best<br>
name to use.<br>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">This is not correct due to the above.  Normal SSA renaming algorithm relies on the fact that reaching defs are *must*defs, and not may-defs.</div><div class="gmail_extra">Thus, it does not matter whether the phi node is complete or not, because it  must be a new ssa version, so you can just push it onto the renaming stack when you see it.</div><div class="gmail_extra"><br>This is not true when they are reaching may-defs, and you must walk through the stack, or other blocks, to find the right version.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>