[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