Re: weird optimization in sin+cos, x86 backend

[James Courtier-Dutton <james dot dutton at gmail dot com>]

On 10 February 2012 10:42, Andrew Haley <aph@redhat.com> wrote:
> On 02/10/2012 10:07 AM, Richard Guenther wrote:
>>
>> 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).
>
> That's a good reason why we can't do this in glibc. ÂI accept
> the point; it'll have to be GNU libm.
>
> Andrew.

I think a starting point would be at least documenting correctly the
accuracy of the current libm, because what is currently in the
documents is obviously wrong.
It certainly does not document that sin() is currently more accurate
than sinl() on x86_64 platforms, even with -O0.
I think the documentation should be along the lines of for
Function name: sin(x)
-pi/2 < x < pi/2, accuracy is +-N
pi/2 < x < large number, accuracy is +-N
large number < x < max_float, accuracy is +-N
If a performance figure could also be added, so much the better. We
could then know that implementation 1 is quicker than implementation 2
and the programmer can do the trade offs.

And have the figures repeated for various options such as -ffast-math
etc, and also repeated for different CPUs etc.

Once we have the documentation, we can then ensure, using automated
testing, that the libm actually performs as designed.