On Mon, 03 Oct 2011 16:34:28 -0700, Ian Romanick <i...@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).
pgpCX65Wa1cMV.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
