This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc 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]

[Bug math/14412] Removal of sysdeps/x86_64/fpu/s_sincos.S causes regressions


http://sourceware.org/bugzilla/show_bug.cgi?id=14412

--- Comment #29 from Siddhesh Poyarekar <siddhesh at redhat dot com> 2013-04-29 13:06:40 UTC ---
(In reply to comment #28)
> according to http://sourceware.org/bugzilla/show_bug.cgi?id=13658#c2
> fast functions can be used when source operand is in certain range.
> Slow functions should be used only outside interval.
> 
> "The FPTAN, FSIN, FCOS, and FSINCOS instructions set the C2 flag to 1 to
> indicate that the source operand is beyond the allowable range of Â2^63 and
> clear the C2 flag if the source operand is within the allowable range."
> 
> So, outside the interval [-2^63,+2^63] ("allowable range"), these instructions
> must not be used (or they can be used, but with a fallback if the C2 flag is
> set to 1). But note that the glibc implementation is more accurate, even with
> (very probably) correct rounding, so that it is better to use it anyway.

The problem is not just about range reduction.  fsincos is not always accurate
within the allowable range either.

(In reply to comment #27)
> With all that said, I still question the cause of the huge performance drop.
> The only cost of the correct sin/cos versus the incorrect one should be
> argument reduction, which should be a no-op if the argument is already in the
> range [-pi,pi] or so and cheap even a good ways outside of that range...

I considered the possibility of keeping the assembly default and then falling
into the default implementation if the exception flags indicate that the result
was not accurate enough, but that doesn't catch all cases.  In fact, the
limited internal precision of PI (66-bit mantissa) guarantees that there will
be cases where fsincos thinks it has hit the target, but it hasn't.

So until there's a way to flag inaccurate results reliably, I think the
__sincos_finite way is the best option.  There is definitely some scope to look
at the implementation of __sin and __cos functions, or even figure out some
clever way to get results faster in sincos than just calling __sin and __cos,
but that will need more work.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

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