Re: weird optimization in sin+cos, x86 backend

[Andrew Haley <aph at redhat dot com>]

On 02/09/2012 02:51 PM, James Courtier-Dutton wrote:
> 2012/2/9 Andrew Haley <aph@redhat.com>:
>> On 02/09/2012 01:38 PM, Tim Prince wrote:
>>> x87 built-ins should be a fair compromise between speed, code size, and
>>> accuracy, for long double, on most CPUs.  As Richard says, it's
>>> certainly possible to do better in the context of SSE, but gcc doesn't
>>> know anything about the quality of math libraries present; it doesn't
>>> even take into account whether it's glibc or something else.
>>
>> Yeah.  On x86_64 glibc, we should really get the sincos bg fixed.  And
>> it really is a bug: cos() and sin() are correctly rounded but sincos()
>> isn't.
>>
>> Andrew.
> 
> Given:
> 
> gcc -g -O0 -c -o sincos1.o sincos1.c
> gcc -static -g -o sincos1 sincos1.o -lm
> 
> ./sincos1
> sin = -8.52200849767188795e-01    (uses xmm register intructions)
> sinl = 0.46261304076460176          (uses fprem and fsin)
> sincos = 4.62613040764601746e-01 (uses fprem and fsin)
> sincosl = 0.46261304076460176       (uses fprem and fsin)
> 
> It looks to me that only sin() is evaluation correctly using xmm
> register instructions.

Yes.  To be more precise, it uses the IBM Accurate Mathematical
Library

> sinl, sincos, and sincosl all use fprem and fsin and fsincos.

That's right.

> From my analysis, fprem is causing a lot of the problems.
> Using a combination of xmm register instructions instead of fprem
> might cure our problems with fsincos.
> Alternatively, make both sin() and sinl() use xmm register intructions.

I don't think that's possible in any reasonable way: the registers
are only 64 bits wide.  It would be better to do an accurate argument
reduction on 80-bit extended reals.

Andrew.