Re: Performance of Integer Multiplication on PIII

[Jan Hubicka <jh at suse dot cz>]

> On Sat, 3 Nov 2001, Tim Prince wrote:
> 
> > >  Form Agner Fog (http://www.agner.org/assem/) pentopt.zip
> > >
> > >                  PPlain      PMMX    PPro    PII   PIII
> > >  IMUL latency       9          9       4      4      4
> > >  IMUL throughput   1/9        1/9     1/1    1/1    1/1
> > >
> > >  That means, imul is pipelined on i686 ...
> > >
> > > > So I guess the lesson here is that on PIII integer multiplication is
> > fast
> > > > enough that doing special tricks to avoid integer multiplication will
> > hurt
> > > > performs in stead of helping it.
> > >
> > Even on the P4, code which permits full pipelining will run well with
> > imul, while the add and shift sequences are preferable in contexts where
> > that is not possible.  I haven't seen any compiler which is able to
> > distinguish those situations.
> 
> The Intel compiler seams to be able to as it gets about the same results
> as my hand coded assembly did.  It should not be two difficult to tell when

Maybe it is because the gcc's algorithm is based purely on the instruction
latencies, not the troughtput (as it is dificult to estimate the troughput of
genrated sequence in early compilation passes).

Perhaps we can aritifically lower the gcc's imul cost on Pentiums if it results
in better code, but this needs some larger scale benchmark than your testcase.

You can try to edit the config/i386/i386.c the pentiumpro_cost structure and
see what happends.

At the moment it says:

  1,					/* cost of an add instruction */
  1,					/* cost of a lea instruction */
  1,					/* variable shift costs */
  1,					/* constant shift costs */
  4,					/* cost of starting a multiply */

That is consistent with the numbers above.

BTW
probably I see the problem - gcc relies on fact that lea instruction has one
cycle, while on pentiums IMO the lea is decomposed to primitive instructions.
Perhaps all we need is to show this fact to gcc in RTX_COST.

I will prepare patch shortly.

Honza

> imul is preferable.  It would seam to me this can be done by calculating
> a dependency tree on a block of code and then see if the latency of the
> imul will prevent anything else from calculating....