[PATCH PING]: PR middle-end/30447 handle builtin csin [take 2]

["Kaveh R. GHAZI" <ghazi at caip dot rutgers dot edu>]

On Wed, 24 Jan 2007, Kaveh R. GHAZI wrote:

> This is my second attempt to provide compile-time evaluation of complex
> math functions, in this case csin.  To address the concerns from the
> previous version, I did two things.
>
> First I increased the precision to one bit higher than twice that
> requested by the target as suggested by Brad here:
> http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01697.html
>
> Second to address the concerns raised by Joseph about accuracy, I only do
> the transformation when -funsafe-math-optimizations is set.  There is
> precedent for this in many builtins including cabs, which when given a
> constant arg uses a naive sqrt(r*r+i*i) evaluated with GCC's real.c
> routines.  (I plan to upgrade cabs, but that's another matter.)  Note
> we're using the same MPFR algorithm that the fortran frontend already uses
> for compile-time evaluation of csin.  My understanding is that the C
> standard requires at most 1 ULP for conformance, while 0.5 is the goal for
> "perfect" results.  While it's possible with this implementation that
> some inputs exceed 0.5 ULP, by requiring the unsafe flag, the user has
> decided on that trade-off.
>
> The long term plan would be to create a common (and last bit accurate)
> implementation and house it in MPFR or MPC as suggested in the previous
> thread.  But that's not being actively worked on by anyone connected to
> MPFR (yet).  In the mean time, we can get this in place and switch to
> exact routines as they become available on a function-by-function basis.
>
> Tested on sparc-sun-solaris2.10, okay for mainline?


PING.

Hi - I never received any feedback on my latest revision of the csin
folding with constant args:
http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02000.html

As noted in this posting from long ago:
http://gcc.gnu.org/ml/gcc-patches/2003-06/msg00486.html

We already optimizing cabs(z) -> sqrt(z.r*z.r+z.i*z.i), and we do this for
variable parameters too, not just constants.  This means we're not using
real.c's extra precision, but instead the target FP precision and libc
sqrt routine.  So there's four places where rounding errors could be
introduced into cabs.

My implementation for csin is more accurate on two counts.  First it uses
double the target precision plus one, second it only does one mult after
getting the "perfect" values from MPFR.  So at most one place in my code
where rounding errors occur, and according to MPFR it generates perfectly
rounded mult results too.

Also the posting above again references that we need only strive for 1ulp
error, not 0.5 like required for sqrt.  Given this and the fact that I've
guarded the folding with -funsafe-math-optimizations, I'd like to know if
there's any reason my implementation is not correct (not why it isn't
perfect.)

I would claim that the "unsafe" flag is unnecessary, but I'm willing to
compromise if that helps us get past the lack of accuracy claims.  I'd
like to finish the other complex functions before too long.

Thoughts?

Patch okay for mainline?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu