I'm not sure I'm so comfortable with this. For one, this is the sort of thing the backend can (and should) do. Why should be be adding stuff at the NIR level to help the backend's copy propagation pass? And perhaps more importantly, why should we be adding stuff at the NIR level to workaround the lack of spilling support for doubles? I know it's more difficult to implement than normal spilling, but it just feels dirty to workaround it because some tests happen to use too many registers.
Jason, what do you think? On Tue, Apr 12, 2016 at 4:05 AM, Samuel Iglesias Gonsálvez <[email protected]> wrote: > From: Iago Toral Quiroga <[email protected]> > > This is useful when we only need to modify the high 32-bit chunk of a double. > This is a common case, because this is the part that encodes the exponent > which we manipulate in some double lowering passes. Although we can accomplish > the same by using pack_double_2x32, this new opcode is better for register > pressure, since we don't have to unpack both parts of the double and keep > the low 32-bits around until we can recombine the new exponent. > > We will use this opcode in the set_exponent() function of the double lowering > pass and with that we will fix spilling issues in some dmat4 divide > piglit tests on Intel. > --- > src/compiler/nir/nir_opcodes.py | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/src/compiler/nir/nir_opcodes.py b/src/compiler/nir/nir_opcodes.py > index 9f62e08..f92dd8d 100644 > --- a/src/compiler/nir/nir_opcodes.py > +++ b/src/compiler/nir/nir_opcodes.py > @@ -276,6 +276,20 @@ di.i2 = src0.y; > dst.x = di.u64; > """) > > +opcode("pack_double_2x32_split_y", 0, tuint64, [0, 0], [tuint64, tuint32], > "", """ > +union { > + uint64_t u64; > + struct { > + uint32_t i1; > + uint32_t i2; > + }; > +} di; > + > +di.u64 = src0; > +di.i1 = src1; > +dst = di.u64; > +""") > + > unop_horiz("unpack_double_2x32", 2, tuint32, 1, tuint64, """ > union { > uint64_t u64; > -- > 2.5.0 > > _______________________________________________ > mesa-dev mailing list > [email protected] > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
