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] |

*From*: Geert Bosch <bosch at adacore dot com>*To*: Vincent Lefevre <vincent+gcc at vinc17 dot org>*Cc*: gcc at gcc dot gnu dot org*Date*: Tue, 14 Feb 2012 11:41:15 -0500*Subject*: Re: weird optimization in sin+cos, x86 backend*References*: <CAAMvbhGYDB717P8pux5nT-Hw3_NQq7k3HRD=vGTtb9Y+2mzpkg@mail.gmail.com> <4F33A16B.7010507@redhat.com> <CAFiYyc1c-qscpC=YrVbEJKa_D-zF88-xbw-wub+jhbRNfFW4Dw@mail.gmail.com> <4F33CC70.3040401@aol.com> <4F33CE33.4000204@redhat.com> <E2293D0E-CDD6-4126-8EF2-25C75CFCE1C4@adacore.com> <CAFiYyc2d7h5=EshA6BEr=QGeSJgCVzTCAHpN9ZS7w-zqjwqAeg@mail.gmail.com> <5CEA5397-B4FB-4E5F-B915-E67887C0D68E@adacore.com> <20120213141401.GC26414@xvii.vinc17.org> <1D6D65C6-1686-4084-B1F6-66BEBD730502@adacore.com> <20120214132254.GF26414@xvii.vinc17.org>

On Feb 14, 2012, at 08:22, Vincent Lefevre wrote: > Please do not use the term binary80, as it is confusing (and > there is a difference between this format and the formats of > the IEEE binary{k} class concerning the implicit bit). Yes, I first wrote extended precision, though that really is a general term that could denote many different formats. I'll write Intel extended precision in the future. :) > > IEEE 754 recommends correct rounding (which should not be much slower > than a function accurate to a few ulp's, in average) in the full range. > I think this should be the default. The best compromise between speed > and accuracy depends on the application, and the compiler can't guess > anyway. While I'm sympathetic to that sentiment, the big issue is that we don't have a correctly rounded math library supporting all formats and suitable for all targets. We can't default to something we don't have. Right now we don't have a library either that conforms to C99 and meets the far more relaxed accuracy criteria of OpenCL and Ada. However, the glibc math library comes very close, and we can surely fix any remaining issues there may be. So, if we can use that as base, or as "fallback" library, we suddenly achieve some minimal accuracy guarantees across a wide range of platforms. If we can get this library with GPL+exception, we can even generate optimized variants and use a static library with LTO byte code allowing for inlining etc. Then we can collect/write code that improves on this libm. -Geert

**Follow-Ups**:**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

**Re: weird optimization in sin+cos, x86 backend***From:*Joseph S. Myers

**References**:**Re: weird optimization in sin+cos, x86 backend***From:*James Courtier-Dutton

**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

**Re: weird optimization in sin+cos, x86 backend***From:*Richard Guenther

**Re: weird optimization in sin+cos, x86 backend***From:*Tim Prince

**Re: weird optimization in sin+cos, x86 backend***From:*Andrew Haley

**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Richard Guenther

**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

**Re: weird optimization in sin+cos, x86 backend***From:*Geert Bosch

**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |