This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: crlibm elementary functions for the glibc ?
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Florent de Dinechin <Florent dot de dot Dinechin at ens-lyon dot fr>
- Cc: libc-alpha at sourceware dot org, Christoph Quirin Lauter <christoph dot lauter at ens-lyon dot fr>
- Date: Fri, 9 Feb 2007 20:04:53 +0000 (UTC)
- Subject: Re: crlibm elementary functions for the glibc ?
- References: <45C897FD.6020009@ens-lyon.fr>
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