<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 10:19 AM, Nuno Lopes <span dir="ltr"><<a href="mailto:nuno.lopes@ist.utl.pt" target="_blank">nuno.lopes@ist.utl.pt</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>>>> So just to be clear (mainly so i can go back to letting y'all hash this out), in value numbering:<br>
>>>> 1. I can value number all freeze operations on the same operand to the same value<br>
>>>>  *as long as*<br>
>>>> 2. I  replace all freeze values of the same operand with a single one.<br>
>>>><br>
>>>> Or am i misunderstanding?<br>
>>>> If i've got it right, the issue i see with #2 is whether i can hoist freezes or not.<br>
>>>><br>
>>>> If not, it may not be possible to cover all uses.<br>
>>>><br>
>>>> IE<br>
>>>> if (a)  {<br>
>>>>   %1 = freeze (%x)<br>
>>>> } else if (b) {<br>
>>>>   %2 = freeze (%x)<br>
>>>> } else if (c){<br>
>>>>   %3 = freeze (%x)<br>
>>>> }<br>
>>>><br>
>>>> I cannot replace these with a single freeze def without placing a freeze above the if block.<br>
>>><br>
>>> As Sanjoy said, hoisting freeze is fine, but movement is not without constraints.  For example, you cannot duplicate execution of freeze.<br>
>>> e.g. the following is wrong (assuming loop body may execute multiple times):<br>
>>><br>
>>> %x = freeze %y<br>
>>> while(...) { use %x }<br>
>>> =><br>
>>> while(...) {<br>
>>>    %x = freeze %y<br>
>>>    use %x<br>
>>> }<br>
>>><br>
>>> So Sanjoy saying that freeze can be thought as an atomic/volatile operation seems like a good intuition.<br>
>>><br>
>>><br>
>>>> *If* i need to replace them all with the same freeze def in order to be able to consider them the same value,  (...)<br>
>>><br>
>>> Right, so just to make it very clear, the following would be wrong:<br>
>>> %x = freeze %y<br>
>>> %w = freeze %y<br>
>>> use_1 %x<br>
>>> use_2 %w<br>
>>> use_3 %x<br>
>>> =><br>
>>> %x = freeze %y<br>
>>> %w = freeze %y<br>
>>> use_1 %w<br>
>>> use_2 %w<br>
>>> use_3 %x<br>
>>><br>
>>> If you replace one use of %x, all uses have to be replaced, since different freezes of the same operand *may* return different values.<br>
>>> I guess that since we are never (err, most of the times) sure of whether a value may come out of freeze, this rule needs to be applied to any value.<br>
>>> Daniel: is that fine for GVN, or would it make things too complicated?<br>
>>><br>
>> Current GVN will definitely get this wrong an d would be hard to fix because of how it eliminates (IE it may cause performance regression)<br>
><br>
> To be clear, i mean: "If you make current GVN understand freeze x has the same value everywhere, it will do the wrong thing. If you make it think freeze x has a different value everywhere, it will never eliminate anything, which is a regression"<br>
><br>
> But again, just to make sure i understand, is the following legal:<br>
> %x = freeze %y<br>
> %w = freeze %y<br>
> use_1 %x<br>
> use_2 %w<br>
> use_3 %x<br>
> =><br>
> %x = freeze %y<br>
> use_1 %x<br>
> use_2 %x<br>
> use_3 %x<br>
><br>
><br>
> (assuming use_2 is the only use of %w)<br>
<br>
</div></div>Yes, that's legal.<br>
It might not be profitable, though, since a freeze with just one use is easier to optimize.</blockquote><div>Easier is a relative term.</div><div>I expect optimally choosing  which freezes to eliminate where, etc,  reduces to a covering problem variant (or just straight ILP) :)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  But I guess that's a trade-off we need to explore later.<br>
We hope the number of freezes will be small, but in bad cases we currently see 5% of instructions being freeze.<br></blockquote><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>> We can make newgvn get it right.<br>
<br>
</span>Cool, glad to hear that, thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
Nuno<br>
<br>
</font></span></blockquote></div><br></div></div>