This is the mail archive of the
mailing list for the glibc project.
Re: Fix x86 sqrt rounding (bug 14032)
- From: Richard Henderson <rth at twiddle dot net>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Thu, 28 Nov 2013 14:08:42 +1300
- Subject: Re: Fix x86 sqrt rounding (bug 14032)
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311271803540 dot 7837 at digraph dot polyomino dot org dot uk> <52966555 dot 20603 at twiddle dot net> <20131127232338 dot GP24286 at brightrain dot aerifal dot cx>
On 11/28/2013 12:23 PM, Rich Felker wrote:
>> Surely this is much more complex than simply setting the rounding precision to
>> double before using fsqrt.
> Setting the rounding precision is likely to be much slower, and has
> issues with signals (signal handlers could be invoked with wrong
> rounding precision, resulting in completely wrong results).
I thought signal handlers always have this problem; if the user expects
to be able to use any floating point from a signal handler one must always set
a complete floating point environment. E.g. the program could be in the middle
of an integer conversion and have set round-to-zero.
As for slowness, I believe that all pentium4 and later support quick changes
between two different control values, if those values only differ in bits 8-12
(precision, rounding, infinity).
I guess we ought to be able to benchmark the two different schemes...