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

[Geert Bosch <bosch at adacore dot com>]

On Nov 12, 2007, at 12:37, Michael Matz wrote:
> At the time we discussed and evaluated a bundled libm I've looked at
> several ones.  I rules out crlibm relatively quickly for these  
> reasons:
>
> * 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.
Proving correct rounding involves a lot of testing of problematic
intervals. I'm not sure the work has been done for long double,
or even whether it is feasible to do with the current state of
the art.

> * many C99 functions are missing: a{sin,cos}h, frexp, ldexp, modf,  
> error
>  and gamma, remainder functions, I stoped looking somewhen
>  many only partially or slowly implemented: pow, exp2
Most of these can be easily implemented based on the other primitives.
True, the property of correctly rounded results will be lost, but
that does not throw away the usefulness of having the other functions
be correctly rounded.
> * relies on a IEEE-754 compatible processor, so it a) needs to have
>  floating point at all and b) even has to use correct precision,  
> e.g. a
>  problem for x86.  That means that either crlibm doesn't work  
> correctly
>  when the processor's precision is reset by the user program (e.g.  
> to use
>  extended precision), or it has to save/set/restore the state on
>  entry/exit of all it's routines
For x86, the use of -mfpmath=sse addresses most, if not all, issues
related to excess precision for float and double. Even if GCC has
its own math library, users should still be able to specify linking
with the systems native math library. As -frounding

The big advantage of having a libm with GCC is that, instead of
only being able to rely on the lowest common denominator for
accuracy of math functions, you'll be able to rely on the same
precision on all targets. This is a huge benefit, especially on
less popular operatings systems and embedded systems, which
often have crappy math libraries.

In case of the correctly rounded functions, it is incredibly useful
to know that all answers are both deterministic and as accurate as
possible.

In particular, it won't matter whether sin (x) will be computed
at compile time or at run time, the answer will be exactly the same.
As the GCC default is -fno-rounding-math, the use of crlibm
would be consistent with that.
> * slow: it's much faster than other correctly rounded libraries, but
>  nevertheless also much slower then more mundane implementations of  
> libm
Do you have any numbers or approximations of how slow?

I think that in practice you'd probably have a number of
implementations for the more popular functions, especially
sin/cos, atan, log/exp. For reasonably good accuracy
of the trigonometric functions (relative error less than
2 epsilon over entire domain), high-precision argument
reduction is necessary. However, for many applications this
is not an issue, and much more simplistic argument reduction
can be used.

Apart from fast and accurate implementations, there would
also be vectorized implementations and possibly implementations
that would be optimized for software floating point.
> I would advise against going the crlibm route.  Sorry.  It's very  
> nice for
> the things it's designed to do (provable and correctly rounded) but  
> is not
> a replacement for a general libm.
>
> I think the best way would be to use FreeBSDs libm, which is  
> maintained
> fairly well, implements all functions and is reasonably fast.  I heard
> rumors about other options (like Sony+IBMs SPU libm, which  
> supposedly also
> is written in C + intrinsics, but it never materialized in the wild).

It seems a mistake to view any libm bundled with GCC as a
full replacement of a system libm. For each function, there
lots of different implementations can be best:
  - most accurate
  - highest throughput while being accurate
  - highest throughput at reduced accuracy
  - shortest latency
  - best support for IEEE exceptions, rounding modes, etc
  - runs on widest range of hardware (portable, many precisions)
  - fastest with software floating-point

It would be great for GCC to at least offer a mode in which the user
can know that the math library gives the most accurate results possible.
In the Ada run time library, we've had to re-implement a lot of
the math functions because *some* system had poor accuracy in parts
of the domain.

Inadequate accuracy leads to failed tests, bug reports
and potentially even failure of deployed systems.
Performance sensitive users typically care about performance
of just a handful of functions (typically sin/cos/sqrt/atan)
and only in a small part of the domain.

We already optimize for those with -ffast-math and our
__builtin functions on at least x86. Having a basis that
is as accurate as possible and then the option to override
those with faster functions for highest performance where
appropriate would seem to give us the best of both worlds.

  -Geert