Re: Using crlibm as the default math library in GCC sources

["Joseph S. Myers" <joseph@codesourcery.com>]

On Wed, 14 Nov 2007, Vincent Lefevre wrote:

> On 2007-11-12 21:29:44 -0500, Geert Bosch wrote:
> > On Nov 12, 2007, at 12:37, Michael Matz wrote:
> >> * only double is implemented, hence long double and float are missing at
> >>  least, at least the long double would need some implementation work,
> >>  as you can't simply enlarge the mantissa and hope all your results are
> >>  still correct
> > Initially, float could simply use double and cast the result.
> > For double->float the results will remain correctly rounded.
> 
> Yes, very probably, but this needs to be proven for each supported
> function, due to the double rounding problem (this may take some time
> for functions like pow).

As I understand the mention of moving towards automatically generating 
functions, crlibm might eventually be able to provide functions for float 
that do most computations in double but use double double for the hard 
cases (like functions for double presently use double double for most 
cases and triple double for hard cases), through automatic generation 
given the type used for function inputs/outputs (float in this case) and 
the types available for intermediate computations (double in this case) as 
well as information on worst cases for rounding?

> > For x86, the use of -mfpmath=sse addresses most, if not all, issues
> > related to excess precision for float and double.
> 
> But not all x86 processors support SSE2. However, I suppose you can
> have crlibm support for some architectures only.

It also seems to me that automatic generation might help address the x86 
issues as well, by providing both SSE2 versions (IEEE double as 
intermediate type) and x87 versions (using long double in all intermediate 
computations to avoid excess precision issues).

> and consistent. For instance, sin(x)*sin(x) + cos(x)*cos(x) will
> always be very close to 1, as mathematically expected.

FWIW, Nick Maclaren once told me that many applications don't care about 
accurate argument reduction for large arguments to sin and cos (for many 
purposes the answer just need be within a few ulp of the correct answer 
for an argument within a few ulp of the given argument - which would allow 
any answer between -1 and 1 for sin and cos of large values), but may 
still expect that sin^2 + cos^2 is very close to 1.

-- 
Joseph S. Myers
joseph@codesourcery.com