<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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class=""><br>
><br>
</span>Thanks for the feedback. Yes, in the current implementation we value number each instruction only once. When an expression is hoisted still the value numbers are not invalidated because one of the expressions in the child branch gets hoisted.<br></blockquote><div><br></div><div>Right. This is a very trivial form of hoisting using the dominator tree.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
So, an extension of this algorithm could be to start hoisting equivalent (scalar) expressions across non-sibling branches. </blockquote><div><br></div><div>This will not work if the branches are ever back edges or blocks with multiple predecessors in general unless all predecessors are part of the same branch of the dominator tree.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">In that case, I think, we would still value number only once,</blockquote><div>Only if the conditions above are met (that's off the top of my head, i'm pretty sure i could think of more).</div><div> </div><div><br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">if we hoist one of the expressions and delete the rest. For loads, or other expressions with side-effects, hoisting would require more complicated analysis across each edge dominated by the common dominator of the equivalent expressions, so maybe we could skip that to save compile time, I'm not very sure about this though. </blockquote><div><br></div><div>It's actually a pretty simple analysis, FWIW:<br><br></div><div>With memory-ssa, all loads have a "def" of the nearest thing above them that kills them.  So if the loads reach the same def, you can hoist them to that def. If they do not, you cannot.</div><div>You can do extra work to see if you can somehow go back past that def if you like.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Could you give an example of a case when multiple value numbering of same expression will be required, that will be helpful.<br>
<br></blockquote><div><br></div><div>Anything whose value depends on a phi node, directly or indirectly.  For multiple predecessor blocks, if you are trying to determine constant values of things and not just sameness, it will also take multiple iterations to get correct answers.</div><div><br></div><div>See, in general, the description of the RPO algorithm in <a href="https://www.cs.rice.edu/~keith/Promo/CRPC-TR95636.pdf.gz">https://www.cs.rice.edu/~keith/Promo/CRPC-TR95636.pdf.gz</a></div><div><br></div><div><br></div><div>Currently </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<a href="http://reviews.llvm.org/D18798" rel="noreferrer" target="_blank">http://reviews.llvm.org/D18798</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>