Re: [PATCH] Constant folding pow(x,y) for constant y.

[Roger Sayle <roger at www dot eyesopen dot com>]

On Mon, 31 Mar 2003, Jonathan Lennox wrote:
> Roger Sayle writes:
> > The following patch is another installment in my series of constant
> > folding optimizations for the pow(3) builtin-function.  This round
> > performs constant folding of pow(x,y) where y is a constant.
> >
> > 	* builtins.c (fold_builtin): When optimizing sqrt(exp(x)) as
> > 	exp(x/2.0) remember to fold the division if possible.
> > 	Fold sin(0.0) as 0.0, cos(0.0) as 1.0, pow(x,1.0) as x,
> > 	pow(x,-1.0) as 1.0/x, pow(x,2.0) as x*x, pow(x,-2.0) as
> > 	1.0/(x*x) and pow(x,0.5) as sqrt(x).
>
> I don't know how significant it is, but for symmetry's sake, would it be
> sensible to include pow(x, -0.5) in your list of constants to optimize, as
> 1.0/sqrt(x)?
>
> Or is the reciprocal plus the sqrt() unlikely to be a win vs. the call to
> pow()?

This was my concern.  The transformations that are performed are always
guaranteed to be a win, but reciprocal plus sqrt isn't as clear cut.
Its certainly better to convert 1.0/pow(x,y) into pow(x,-y) rather than
the other way around.

Perhaps eventually we'll parameterize the backends with the equivalent
of RTX costs for mathematical functions.  For example, this would be
needed for the general case of pow(x,y) for any integer constant value
of y, where the computation can be turned into a (potentially long)
sequence of multiplications [as is currently done by the g77 front-end].
On x86_64, for example, I wonder if the worst-case sequence of ~120
sequential floating point multiplications is really any faster than
using the x87 log/exp sequence provided by glibc.

Roger
--