Re: crlibm elementary functions for the glibc ?

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

On Tue, 6 Feb 2007, Florent de Dinechin wrote:

> We are the maintainers of the crlibm project, which aims at developping a
> modern, correctly rounded version of the libm licenced under the LGPL.
> Project homepage is https://lipforge.ens-lyon.fr/projects/crlibm/
> 
> I feel that this project is now achieving sufficient maturity to be a
> candidate for gradual inclusion in the glibc. I would appreciate any feedback
> on this question, and probably some practical advice.

The following are just my views, I don't speak for the glibc maintainers.

First, I expect it will be necessary to follow the FSF copyright 
assignment process.  While various parts of glibc at present, including 
mathematical functions, have non-FSF copyrights, they are less likely to 
be accepted for new code; see 
<http://sourceware.org/ml/libc-alpha/2007-01/msg00026.html>.

Second, I'd like to suggest that you consider contributing the code to the 
libgcc-math <http://gcc.gnu.org/wiki/libgcc-math> project *as well as* to 
glibc.  This aims to collect implementations of mathematical functions for 
use from GCC-compiled code beyond the scope of glibc; for example, 
vectorized functions, normal functions compiled with more efficient ABIs 
(SSE argument passing on x86) and C99 functions for use by the C++ and 
Fortran runtime libraries on platforms whose non-glibc libm is missing 
those functions.  Such functions are specifically beyond the scope of what 
is considered appropriate for inclusion in glibc 
<http://sourceware.org/ml/libc-alpha/2005-07/msg00008.html>, so if you are 
interested in this then you should discuss it on gcc@gcc.gnu.org and not 
on libc-alpha.  By assigning to the FSF and using the LGPL+exception 
license used for soft-fp from the start, the code can be used in both 
places; you should aim for making it possible to have identical source 
files in both places, as that's best in terms of FSF policies.

> should first improve average
> performance at the expense of larger tables,

If doing so makes the average case performance better than the existing 
implementations, that would make a clearer case for including this code as 
a replacement for the current code.

There are trade-offs involved between speed, size and accuracy of 
mathematical functions.  glibc has to strike a middle ground for general 
users.  Other projects such as libgcc-math may collect different versions 
tuned for different trade-offs and allow the user to select them at 
compile time or link time.

The glibc bug database <http://sources.redhat.com/bugzilla/> has 57 open 
bugs in the "math" component, mostly suspended until someone comes forward 
with patches for them.  Perhaps your new implementations fix some of them?  
(Many of those bugs relate to float and long double versions of the 
functions; as I understand it, your methods could generate proven 
correctly rounded functions for float and probably but not proven 
correctly rounded versions for at least IEEE extended and quad long 
double.)

-- 
Joseph S. Myers
joseph@codesourcery.com