<div dir="ltr">On 4 October 2013 14:24, Matt Turner <span dir="ltr"><<a href="mailto:mattst88@gmail.com" target="_blank">mattst88@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, Oct 4, 2013 at 2:19 PM, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote:<br>
> On 4 October 2013 13:51, Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>> wrote:<br>
>><br>
>> On 3 October 2013 10:59, Matt Turner <<a href="mailto:mattst88@gmail.com">mattst88@gmail.com</a>> wrote:<br>
>>><br>
>>> v2: Check fixed_hw_reg.{file,nr} instead of dst.reg.<br>
>>> v3: Store the bool emitted_addc_or_subb in the class, not static.<br>
>>> ---<br>
>>>  src/mesa/drivers/dri/i965/brw_fs.h           |   3 +<br>
>>>  src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 104<br>
>>> +++++++++++++++++++++++++++<br>
>>>  2 files changed, 107 insertions(+)<br>
>><br>
>><br>
>> Reviewed-by: Paul Berry <<a href="mailto:stereotype441@gmail.com">stereotype441@gmail.com</a>><br>
><br>
><br>
> Whoops, wait a minute.  I spoke too soon.<br>
><br>
> I'm concerned because it looks like this peephole pass is too generous.  The<br>
> following instruction stream, for example, shoud not be peephole optimized:<br>
><br>
> addc null, x, y<br>
> mov carry, acc0<br>
> mov x, z<br>
> add sum x, y<br>
><br>
> But I don't see anything in fs_visitor::try_combine_add_with_addc_subb() to<br>
> prevent this.<br>
<br>
</div>We're operating on virtual grfs at this point, so I don't think that<br>
case is possible. I.e., if there were an intervening write to x, it<br>
just would have been a different vgrf. I think Ken had this same<br>
concern at one point, although I don't think he ever said it via<br>
email.<br>
</blockquote></div><br></div><div class="gmail_extra">Sadly I don't think we can rely on that.  Since we haven't (yet) implemented SSA, there's no guarantee that different writes will use different virtual GRFs.  They will only be different virtual GRFs if they are different variables in the GLSL IR.  And the GLSL IR optimization passes (e.g. opt_copy_propagation and opt_tree_grafting) are pretty aggressive in trying to get rid of extra GLSL IR variables where possible, so even if they start off as different variables in the GLSL IR there's no guarantee that they'll still be different variables by the time we hit the back end.<br>
</div></div>