Re: weird optimization in sin+cos, x86 backend

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

On Fri, 10 Feb 2012, Geert Bosch wrote:

> Right. I even understand where he is coming from. Adding new interfaces
> is indeed a big deal as they'll pretty much have to stay around forever.

And: even if the interface is a known, public, standard, stable interface, 
glibc may still not be the right place.

Consider the ISO 24747 special mathematical functions.  This is an 
extension to ISO C (there's a similar extension to C++ with the functions 
that were in TR1).  No doubt implementations would be useful to some 
people, though I haven't heard of any interest in implementing them for 
the GNU system, and a good implementation (care about error bounds and 
performance etc.) would be a lot of work.  (There is an implementation of 
the TR1 versions in libstdc++.  It doesn't have anything much in the way 
of error or performance bounds - it's a generic implementation without 
precomputed tables, that can involve very long loops calling other 
functions with such long loops in some cases, and I expect various 
precomputed tables would be involved in getting particularly good error 
bounds and performance - but I think simply implementing the functions at 
all involved a lot of work.)

But if you implemented the functions in libm in a fast, accurate way, then 
suddenly all the code is loaded into everything that uses shared libm, and 
hardly any such programs actually need these functions - cf. the argument 
for avoiding decimal floating-point support in shared libc or libgcc when 
hardly any typical GNU/Linux programs are using that.  As a well-defined 
set of functions a separate shared library probably makes more sense.  
And given that nothing else in glibc depends on them, there's no need for 
such a library to be part of the glibc project, which may as well keep a 
narrower focus.  (Bits of libc *do* depend on a few bits of functionality 
from libm, which get built into libc as well; some things such as rounding 
mode support and separating numbers into mantissa and exponent are 
relevant for libc functionality such as printf and strtod.)

-- 
Joseph S. Myers
joseph@codesourcery.com