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*: Richard Guenther <richard dot guenther at gmail dot com>*Cc*: Andrew Haley <aph at redhat dot com>, gcc at gcc dot gnu dot org*Date*: Thu, 9 Feb 2012 12:36:01 -0500*Subject*: Re: weird optimization in sin+cos, x86 backend*References*: <CADn89gRRwQ5uPGCDMGZo28ofnAQsvU5PURKxPuvOPF1+ZbvO8g@mail.gmail.com> <CAFiYyc1oLgmP-bs2eyvW134SEzLONUxpcgiXMS4XnmamrUZ-9Q@mail.gmail.com> <Pine.LNX.4.64.1202031535030.25409@wotan.suse.de> <4F2BF9B6.20903@adacore.com> <20120203152858.GC5312@xvii.vinc17.org> <Pine.LNX.4.64.1202031647020.25409@wotan.suse.de> <20120203162402.GE5312@xvii.vinc17.org> <Pine.LNX.4.64.1202031738430.25409@wotan.suse.de> <20120203214853.GG5312@xvii.vinc17.org> <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>

On Feb 9, 2012, at 10:28, Richard Guenther wrote: > Yes, definitely! OTOH last time I added the toplevel libgcc-math directory > and populated it with sources from glibc RMS objected violently and I had > to remove it again. So we at least need to find a different source of > math routines to start with (with proper licensing terms). Right, I new there had been issues like this with the glibc stuff. While I'm open to trying to deal with RMS on this, we indeed might want to go a different route. So much for free software. > > I'd definitely like to see this library also to host vectorized routines and > provide a myriad of entry-points. Exactly. In particular, I'd expect to see dozens of variations of some important performance-sensitive functions like sin and cos, while others will just have one reasonably accurate machine-independent reference implementation. > So - do you have an idea what routines we can start off with to get > a full C99 set of routines for float, double and long double? The last > time I was exploring the idea again I was looking at the BSD libm. I would think fdlibm might be a good starting point for double. I don't know of any appropriately licensed library that provides good functions for all types. Maybe the answer is to provide an infrastructure to start adding functions, falling back on libm where needed. We'll need to think about how to accommodate multiple versions with varying accuracy and speed and how to select from these. I think it would make sense to have a check list of properties, and use configure-based tests to categorize implementations. These tests would be added as we go along. Criteria: [ ] Conforms to C99 for exceptional values (accepting/producing NaNs, infinities) [ ] Handles non-standard rounding modes, trapping math, errno, etc. [ ] Meets certain relative error bounds, copy from Ada Annex G numerical requirements (typically between 2 eps and 4 eps for much of range) [ ] Guaranteed error less than 1 ulp over all arguments, typical max. error close to 0.5 ulp. [ ] Correctly rounded for all arguments While I think it would be great if there were a suitable GNU libm project that we could directly use, this seems to only make sense if this could be based on the current glibc math library. As far as I understand, it is unlikely that we can make this happen in the near future. However, even if that were possible, I think it is necessary for us to be able to inline math functions directly in user programs, without those programs having to be released under the GPL. It just isn't possible to get best-in-class performance by calling external functions. We need to be able to inline all code and fully optimize it using all our existing and future optimizers. -Geert

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

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

**References**:**weird optimization in sin+cos, x86 backend***From:*Konstantin Vladimirov

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

**Re: weird optimization in sin+cos, x86 backend***From:*Michael Matz

**Re: weird optimization in sin+cos, x86 backend***From:*Robert Dewar

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

**Re: weird optimization in sin+cos, x86 backend***From:*Michael Matz

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

**Re: weird optimization in sin+cos, x86 backend***From:*Michael Matz

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

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

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

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