This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: weird optimization in sin+cos, x86 backend


On 2/9/2012 5:55 AM, Richard Guenther wrote:
On Thu, Feb 9, 2012 at 11:35 AM, Andrew Haley<aph@redhat.com> wrote:
On 02/09/2012 10:20 AM, James Courtier-Dutton wrote:
 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.

That's true iff you're using the hardware builtins, which we're not on GNU/Linux unless you're using -ffast-math. If you're using -ffast-math, the fsincos optimization is appropriate anyway because you want fast. If you're not using -ffast-math it's still appropriate, because we're using an accurate libm.

The point of course is that glibc happily uses fsin/fsincos (which isn't even fast compared to a decent implementation using SSE math).


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.



-- Tim Prince


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]