Re: weird optimization in sin+cos, x86 backend

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

On Fri, 10 Feb 2012, Richard Guenther wrote:

> I don't buy the argument that inlining math routines (apart from those
> we already handle) would improve performance.  What will improve
> performance is to have separate entry points to the routines
> to skip errno handling, NaN/Inf checking or rounding mode selection
> when certain compilation flags are set.  That as well as a more
> sane calling convention for, for example sincos, or in general
> on x86_64 (have at least _some_ callee-saved XMM registers).

glibc has some extra entry points for -ffinite-math-only in 2.15.

> The issue with libm in glibc here is that Drepper absolutely does
> not want new ABIs in libm - he believes that for example vectorized
> routines do not belong there (nor the SSE calling-convention variants
> for i686 I tried to push once).

And this fits in with the general principle that glibc's libm is for 
general-purpose use (balancing speed, size, accuracy etc.) and it makes 
sense to have the extra variants in a separate library (that won't 
necessarily be loaded into every program linked with libstdc++ or with a 
computation of a square root that's not at all performance critical, for 
example); being conservative about extra interfaces in a basic system 
library does make sense.

One key difference with the -ffinite-math-only entry points is that they 
generally are just exported names for functions that already existed - the 
code was already structured to do checks for errors / exceptional values 
and then call the main function for the no-error case as needed.

-- 
Joseph S. Myers
joseph@codesourcery.com