[Mesa-dev] [PATCH 2/3] i965/fs: Fix comparisions with uint negation.

Ian Romanick idr at freedesktop.org
Tue Oct 4 12:15:14 PDT 2011


On 10/04/2011 10:37 AM, Eric Anholt wrote:
> On Mon, 03 Oct 2011 16:34:28 -0700, Ian Romanick<idr at freedesktop.org>  wrote:
>> On 10/03/2011 03:41 PM, Eric Anholt wrote:
>
>>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp
>>> index 2000180..555d26d 100644
>>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>>> @@ -1347,6 +1347,19 @@ fs_visitor::register_coalesce()
>>>    	    interfered = true;
>>>    	    break;
>>>    	 }
>>> +
>>> +	 /* The accumulator result appears to get used for the
>>> +	  * conditional modifier generation.  When negating a UD
>>> +	  * value, there is a 33rd bit generated for the sign in the
>>> +	  * accumulator value, so now you can't check, for example,
>>> +	  * equality with a 32-bit value.  See piglit fs-op-neg-uint.
>>> +	  */
>>> +	 if (scan_inst->conditional_mod&&
>>> +	     inst->src[0].negate&&
>>> +	     inst->src[0].type == BRW_REGISTER_TYPE_UD) {
>>> +	    interfered = true;
>>> +	    break;
>>> +	 }
>>>          }
>>>          if (interfered) {
>>>    	 continue;
>
>>>    }
>>> +
>>> +void
>>> +fs_visitor::resolve_ud_negate(fs_reg *reg)
>>> +{
>>> +   if (reg->type != BRW_REGISTER_TYPE_UD ||
>>> +       !reg->negate)
>>> +      return;
>>> +
>>> +   fs_reg temp = fs_reg(this, glsl_type::uint_type);
>>> +   emit(BRW_OPCODE_MOV, temp, *reg);
>>> +   *reg = temp;
>>> +}
>>
>> I suspect I know the answer, but are we sure that a later optimization
>> pass won't copy propagate this extra move away?
>
> That's what the hunk in the badly-named copy-propagation pass is about
> (and the neg-uint test tested it specifically).

I seemed to recall that there was something like that, but I wanted to 
be sure.  For the series:

Ian Romanick <ian.d.romanick at intel.com>


More information about the mesa-dev mailing list