Re: weird optimization in sin+cos, x86 backend

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

On Thu, 9 Feb 2012, Geert Bosch wrote:

> I don't agree having such a libm is the ultimate goal. It could be
> a first step along the way, addressing correctness issues. This

Indeed, I think having it as a first step makes sense - with subsequent 
development done in that context.

> would be great progress, but does not remove the need for having
> at least versions of common elementary functions directly integrated
> with GCC.

For a few, yes, inline support (such as already exists for some functions 
on some targets) makes sense.  But for some more complicated cases it 
seems plausible that LTO information in a library might be an appropriate 
way of inlining while allowing the functions to be written directly in C.  
(Or they could be inline in a header provided with GCC, but that would 
only help for use in C and C++ code.)

> In particular, it would not address the issue of performance. For 
> that we need at least a permissive license to allow full inlining, 
> but it seems unlikely to me that we'd be able to get glibc code 
> under those conditions any time soon.

Indeed, if we can't then other sources would need using for the functions.  
But it seems worth explaining the issues to RMS - that is, that there is a 
need for permissively licensed versions of these functions in GNU, the 
question is just whether new ones are written or taken from elsewhere or 
whether glibc versions can be used for some functions.

> I'd rather start collecting suitable code in GCC now. If/when a 

Whereas I'd suggest: start collecting in a separate project and have GCC 
importing from that project from the start.

> libm project materializes, it can take our freely licensed code 
> and integrate it. I don't see why we need to wait. 

I don't think of it as waiting - I think of it as collecting the code now, 
but in an appropriate place, and written in an appropriate way (using 
types such as binary32/binary64/binary128 rather than particular names 
such as float/double/long double, recording assumptions such as whether 
the code will work on x87 with excess precision and what it needs for 
rounding modes / exceptions / subnormals support).  Aim initially for GCC 
use, but try to put things in a more generally usable form.

> I think nowadays it makes as little sense to have sqrt, sin, cos,
> exp and ln and other common simple elementary functions in an
> external library, as it would be for multiplication and division to
> be there. Often we'll want to generate these functions inline taking

I've previously suggested GNU libm (rather than glibc) as a natural master 
home for the soft-fp code that does provide multiplication and division 
for processors without them in hardware....

(Different strategies would obviously be optimal for many functions on 
soft-float targets, although I doubt there's much demand for implementing 
them since if you care much for floating-point performance you'll be using 
a processor with hardware floating point.)

-- 
Joseph S. Myers
joseph@codesourcery.com