This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on valid transformations for cbrt
- From: Roger Sayle <roger at eyesopen dot com>
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 7 Mar 2004 07:00:50 -0700 (MST)
- Subject: Re: Question on valid transformations for cbrt
On Sat, 6 Mar 2004, Kaveh R. Ghazi wrote:
> I'm in the process of writing some transformations for builtin cbrt.
> However it occurs to me that certain combinations might be invalid
> when converting to pow, because pow doesn't like negative values with
> non-integral powers. E.g.:
>
> cbrt(sqrt(x)) -> pow(x, 1/6)
>
> can be considered "safe" with -ffast-math IMO because if x was
> negative the original sqrt would have choked anyway. However here:
>
> cbrt(pow(x,y)) -> pow(x,y/3)
>
> if x is negative and y is say 5, the first form would succeed but the
> second would get an error EDOM because 5/3 is non-integral. So I
> don't think the latter is a valid transformation even with
> -ffast-math.
>
> (Perhaps the latter is okay if x passes tree_expr_nonnegative_p, but
> that might not be worth it.)
>
> Thoughts?
I think you're right, and we can't in general simplify cbrt(pow(x,y))
even with -ffast-math. I've had to give some thought to GCC's existing
sqrt(pow(x,y)) to see whether we need to disable that. However I've
conviced myself that its safe with -ffast-math. If x is negative,
y must be an integer to satisfy pow, and then must be an even integer
to satisfy sqrt. Hence our existing transform is safe.
The problem with cbrt, unlike sqrt, is that its is more expressive than
pow. i.e. cbrt(-29.7) = -3.1 but pow(-29.7,1.0/3.0) => EDOM. Hence
we can't normalize cbrt(x) as pow(x,1.0/3.0), but we can safely go the
other way pow(x,1.0/3.0) => cbrt(x).
Roger
--