
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 7, 2014, at 3:39 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:</div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":542" style="overflow:hidden">(2) Phi nodes "in the way".<br>(2) SSA based analysis are way simpler when they don't handle phis. They could be adapted to handle single operand phis, but we don't usually bother to check. I don't have a specific issue in mind that would impact the early loop opts.<br>

</div></blockquote><div><br></div><div>Ok, I think this would be the more serious issue if it comes up in practice. I don't have any cases where it comes up in practice for early loop opts either though.</div></div></div></div></blockquote><div><br></div><div>Agreed. Then if instcombine removes them its not an issue. Hopefully it doesn’t slow down instcombine.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;"><div id=":542" style="overflow:hidden"><br>So, what's the benefit of <span class="">LCSSA</span>? I'm told that it makes SSA update easier. I don't understand what could be easier than using an SSAUpdater utility. LoopRotate and LICM already use the updater.</div>

</blockquote><div><br></div><div><snip></div><div><br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto;">

<div id=":542" style="overflow:hidden">If <span class="">LCSSA</span> actually makes writing transformations easier, then I'm all for it. Could you point to some specific transformations that are easier with <span class="">LCSSA</span>?</div>

</blockquote></div><br>LICM. There is already a fast path in LICM that is the exact path that LCSSA guarantees exists when sinking code into the exit blocks. The only thing missing is for LICM to actually *use* LCSSA instead of just trying to patch it up if it happens to find it in the loop. I think it would dramatically simplify the entire sinking code.</div></div></blockquote><div><br></div><div>That sounds reasonable.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">A good use of SSAUpdater: re-forming SSA values *within* a loop body due to mem2reg essentially. LICM has a little mini mem2reg pass in it that uses SSAUpdater. This is a great use and I can't imagine something simpler. The fact that we have LCSSA also makes it faster by bounding the space where it has to rewrite uses (to the edge of the current loop).</div></div></blockquote><div><br></div><div>That makes sense.</div><br><blockquote type="cite"><div dir="ltr">

<div class="gmail_extra">But if we have LCSSA, we should never need SSAUpdater for updating SSA form across the loop boundary in the way LICM does. Instead we should be able to place an instruction, RAUW it, and insert a PHI node for each operand. Done.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Maybe a patch would be better to explain matters? As it happens, fixing LICM this way will also fix PR18753 and a host of other latent bugs where LICM invalidates LCSSA in some far-off loop and we crash later.</div>

</div>

</blockquote></div><div><br></div>Sounds good.<div><br></div><div>-Andy</div></body></html>