On Tue, 16 Aug 2011 11:55:50 -0700, Kenneth Graunke <kenn...@whitecape.org> wrote: > On 08/15/2011 10:57 PM, Eric Anholt wrote: > > The MUL opcode does a 16bit * 32bit multiply, and we need to do the > > MACH to get the top 16bit * 32bit added in. > > > > Fixes fs-op-mult-int-*, fs-op-mult-ivec* > > Sigh. You're right, of course...this is straight out of the > documentation (aside from dropping the high 64-bits). > > Reviewed-by: Kenneth Graunke <kenn...@whitecape.org> > (assuming it's passed a full piglit run) > > To implement a first stab at your "Emit just the MUL if we know an > operand is small enough" FINISHME, we could at least check if it's an > ir_constant of integer type that fits in 16-bits. That would be easy > and at least make things like 2*x not suck. > > But now I'm a bit paranoid...are we following the other restrictions? > > - Do we generate multiplies with mixed float/integer operands? > I could see it happen, say, after some optimization pass.
Nope, we don't copy-propagate/coalesce across type changes, particularly because you can't mix float/int on snb at all. > - Do we use saturate on integers? > Doubtful, as it doesn't make much sense, but... Looks like we would! We should just disable try_emit_saturate() for integer expressions. > Also, using the accumulator always makes me paranoid, wondering exactly > when and what we're accumulating. Do MADs on integers work, given that > we currently implement MAD via MAC? We only use MAC for linterp, and have no MAD code. The risk of this patch would be instruction scheduling across the acc reg usage in the MUL, but the scheduler will see some misc. register being accessed, and treat it as a barrier.
pgpKm07lhiLwP.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
