[Mesa-dev] [RFC PATCH] nir: Transform 4*x into x << 2 during late optimizations.

[Kenneth Graunke]

On Monday, May 18, 2015 11:26:05 AM Matt Turner wrote:
> On Fri, May 8, 2015 at 3:36 AM, Kenneth Graunke <kenneth at whitecape.org> wrote:
> > According to Glenn, shifts on R600 have 5x the throughput as multiplies.
> >
> > Intel GPUs have strange integer multiplication restrictions - on most
> > hardware, MUL actually only does a 32-bit x 16-bit multiply.  This
> > means the arguments aren't commutative, which can limit our constant
> > propagation options.  SHL has no such restrictions.
> >
> > Shifting is probably reasonable on most people's hardware, so let's just
> > do that.
> >
> > i965 shader-db results (using NIR for VS):
> > total instructions in shared programs: 7432587 -> 7388982 (-0.59%)
> > instructions in affected programs:     1360411 -> 1316806 (-3.21%)
> > helped:                                5772
> > HURT:                                  0
> 
> Just to close the loop, I ran shader-db with this patch on top of my
> integer multiplication series, and it doesn't change any instruction
> counts on i965. (I also tried with all other power-of-two
> multiplications for shift values < 31.)
> 
> We may want to do it for other reasons though.

If we're going to do it because shifts are faster/nicer than multiplies,
then we should probably just do it for powers-of-two in general.
Unfortunately, opt_algebraic doesn't really lend itself to that without
adding some sort of "power of two" infrastructure.

I guess we could optimize things like:
a * 2^n  =>  a << n
a % 2^n  =>  a & (n-1)
a / 2^n  =>  a >> n (possibly only for unsigned? (*))
...others?

The first is a clear win on r600, and the latter are clear wins on i965,
though they may be rather rare...

We could add a custom NIR pass.  Or, we could just or just have backends
check for an immediate second operand and do this sort of stuff.  Or
optimize it themselves.  *shrug*

(*) http://lists.freedesktop.org/archives/mesa-dev/2014-April/057364.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150518/b6e64669/attachment.sig>