Fix x86 sqrt rounding (bug 14032)

[Joseph S. Myers]

On Wed, 27 Nov 2013, Rich Felker wrote:

> Well then pending resolution of bug 16068, this would be something of
> a regression. It's also unfortunate that POSIX does not define the

As I said, various functions already set precision temporarily; it's not 
new that libm does this.

> fenv functions as AS-safe, so a conforming POSIX program *cannot* do
> what C11 recommends.

I.e., POSIX programs can't use floating point in signal handlers.  
Naturally I think we should document an intent that the fenv functions are 
AS-safe provided you restore the original environment before leaving the 
handler.

> Anyway, I think the proper next step is comparing performance. My
> intuition is that changing the control register is going to be a lot
> slower than the typical path in the first patch proposed, which
> essentially adds just an ld80 store and double store/load pair. Note
> that a benchmark should not use the testcase values (which are
> numerically rare and intentionally chosen to hit the double-rounding
> issue) unless the intent is to optimize worst-case rather than
> avergage runtime.

With inputs from 
<https://sourceware.org/ml/libc-alpha/2013-10/msg00382.html> and testing 
on a Sandy Bridge Xeon:

Unmodified glibc:
sqrt(): ITERS:1.83965e+09: TOTAL:31880.5Mcy, MAX:111.358cy, MIN:8.524cy, 57704.6 calls/Mcy

First patch (adjustment using C1 bit):
sqrt(): ITERS:1.84168e+09: TOTAL:31880.6Mcy, MAX:142.333cy, MIN:8.871cy, 57768.1 calls/Mcy

Second patch (temporarily changing precision):
sqrt(): ITERS:1.84008e+09: TOTAL:31880.4Mcy, MAX:125.583cy, MIN:8.488cy, 57718.3 calls/Mcy

I interpret this as meaning there is no significant performance difference 
between the approaches and no significant performance loss from these 
changes.

-- 
Joseph S. Myers
joseph@codesourcery.com