🚀 go-pugleaf

In article <6908@cbnewsh.ATT.COM>, beyer@cbnewsh.ATT.COM (jean-david.beyer) writes:
> In article <1535@cbnewsi.ATT.COM>, reha@cbnewsi.ATT.COM (reha.gur) writes:
> > In article <1804@l.cc.purdue.edu>, cik@l.cc.purdue.edu (Herman Rubin) writes:

			........................

> However, having spent some time working on optimizers that work at the
> assembly level for machines, I notice that, for the benchmarks we use,
> anyway, the result of running our C compilers, the most integer multiplies
> seem to be when dealing with the subscripts of arrays or some kinds of
> pointer dereferencing (those pointing to structures). In these cases,
> the multiply instructions are mostly multiplications by constants. These
> constants frequently have a small number of 1's. Consequently, instead of
> calling a general purpose multiply subroutine, it suffices to insert a
> special purpose inline code that multiplies by the desired constant.
> (it might even pay to do a strength reduction optimization). This can be
> much faster than the general purpose multiply subroutine, and may be faster
> than a hardware multiply instruction, depending on the design of the
> hardware multiply.

The idea that special multiplications should be inlined is nothing new.  The
Fortran compiler on the CC6500 expanded multiplication and exponentiation by
small integers.  Whether this should be done by the hardware for variable
integers with few 1's is not clear.

But multiplication is used for other purposes, and here the loss is huge.
Also, it operations are pipelined, as on many machines, the benefits from
inlining are reduced.

The costs of using a multiply subroutine are quite high compared to using
even a complicated instruction.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)