This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: weird optimization in sin+cos, x86 backend
On 3 February 2012 21:48, Vincent Lefevre <vincent+gcc@vinc17.org> wrote:
> On 2012-02-03 17:44:21 +0100, Michael Matz wrote:
>> Hi,
>>
>> On Fri, 3 Feb 2012, Vincent Lefevre wrote:
>>
>> > > > For the glibc, I've finally reported a bug here:
>> > > >
>> > > > Â http://sourceware.org/bugzilla/show_bug.cgi?id=13658
>> > >
>> > > That is about 1.0e22, not the obscene 4.47460300787e+182 of the
>> > > original poster.
>> >
>> > But 1.0e22 cannot be handled correctly.
>>
>> I'm not sure what you're getting at. ÂYes, 1e22 isn't handled correctly,
>> but this thread was about 4.47460300787e+182 until you changed topics.
>
> No, the topic is: "weird optimization in sin+cos, x86 backend".
> But actually, as said by Richard Guenther, the bug is not the
> optimization, but the behavior of the sincos function. What I'm
> saying is that this wrong behavior can also be seen on 1.0e22
> (at least with the glibc, and any implementation that uses the
> fsincos x86 instruction).
>
>> > > If you want to have precise numbers use an arbitrary precision math
>> > > library.
>> >
>> > This is double precision. An arbitrary precision math library (even
>> > though I develop one) shouldn't be needed.
>>
>> But the reduction step needs much more precision than it currently uses to
>> handle inputs as large as 4e182 correctly.
>
> No, the range reduction can cleverly be done using the working
> precision (such as with Payne and Hanek's algorithm).
>
From what I can see, on x86_64, the hardware fsin(x) is more accurate
than the hardware fsincos(x).
As you gradually increase the size of X from 0 to 10e22, fsincos(x)
diverges from the correct accurate value quicker than fsin(x) does.
So, from this I would say that using fsincos instead of fsin is not a
good idea, at least on x86_64 platforms.
So, I suggest that:
1) sin() uses fsin
2) cos() uses fcos
3) sincos() uses fsincos (might be a contentious point?)
4) If a program is using sin(x) close to cos(x), do not optimize it to
a sincos()