<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 8:41 AM, James Molloy <span dir="ltr"><<a href="mailto:James.Molloy@arm.com" target="_blank">James.Molloy@arm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Thanks for the quick reply; this is a very helpful and constructive discussion :)<br></blockquote><div><br></div><div>Happy to help :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The oversimplification and repetition below is for my own understanding and so that I can better understand your replies, as you know this subject far better than I.<br>
<span class=""><br>
A: store 1<br>
B: store 2<br>
C: store 3<br>
</span>D:<br>
<br>
I understand that in a classical sinking algorithm we'd want to walk backwards:<br>
  1) Sink 'store 3' from C to D<br>
  2) Sink 'store 2' from B to D<br>
  3) Sink 'store 1' from A to D<br>
<br>
A key to this working is that each instruction, when considered, was sunk as far as it could be. If we had added the restriction that an instruction could only be sunk to its immediate successor block, that algorithm would have taken three iterations to reach a fixpoint.<br></blockquote><div>Yes</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
GVNSink can (at the moment at least) only sink instructions from a block into its immediate successor. This is what allows it to model accurately enough how many PHIs it is going to create and whether sinking is actually worthwhile (and how much sinking)</blockquote><div><br></div><div>How much is the former, and how much is the later?</div><div><br></div><div>The number of phis you can create is calculable ahead of time in O(N) time for all operands, and related the availability of values</div><div>(in particular, you will create a phi for any value with two different leaders at a join point you must pass to sink it. If you calculate this properly, and in topo order of expressions, such that you process operands before things that use them, you can calculate the number of phis you would insert in O(N) time overall)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">. I don't believe it would be able to handle all the cases it currently does if it didn't have this restriction (but would be able to handle other cases that it currently can't, so I see that very much as an enhancement I'd like to add later).<br></blockquote><div><br></div><div>I actually don't buy this, fwiw.</div><div>It's entirely possible to calculate all the hypothetical insertion points ahead of time, and figure out which make sense from a cost perspective.</div><div>There are sinking (and PRE) algorithms that do this.<br>You could do exactly the same cases you do now.</div><div><br></div><div><br></div><div>Now, whether you want that complexity is a different question :)</div><div><br></div></div></div></div>