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*: "Joseph S. Myers" <joseph at codesourcery dot com>*To*: Richard Guenther <richard dot guenther at gmail dot com>*Cc*: Geert Bosch <bosch at adacore dot com>, Andrew Haley <aph at redhat dot com>, gcc at gcc dot gnu dot org*Date*: Thu, 9 Feb 2012 16:53:25 +0000 (UTC)*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 Thu, 9 Feb 2012, Richard Guenther wrote: > > Given the fact that GCC already needs to know pretty much everything > > about these functions for optimizations and constant folding, and is > > in the best situation to choose specific implementations (-ffast-math > > or not, -frounding-math or not, -ftrapping-math or not, etc), specific > > optimizations (latency/throughput/vector optimized) ?and perform > > (partial) inlining, shouldn't we have a math library directly within GCC? > > 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). My view is that we should have a "GNU libm" project whose purpose is not to install a library directly but to provide functions for use in other projects (much like gnulib, but the functions could presume that they were being built with recent GCC). In essence, there would be a range of implementations parametrized by both properties of the system ("implement this function for binary32, given binary64 as an underlying floating-point type with efficient hardware operations and efficient 64-bit integer operations") and requirements (on error handling, accuracy, speed) and libraries using GNU libm would pick the implementations they want and give them the exported names they want. (It's expected that future ISO C bindings to IEEE 754-2008 will define specific type and function names for types such as binary32 - so a function might be exported from libm with both "sinf" and "sinf32" names - and also "crsin" and "crsinf32" if correctly rounded.) See further what I said at <http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00517.html> on this. A new GNU project is different from copying files from one to another and modifying the copies (there seems to be more difficulty with that than with using a well-defined external project in another project). We did get approval for libquadmath doing such copying, however. (With GNU libm it would be cleaner - functions written in terms of a generic binary128 type that could be either __float128 or long double, not needing changes to use in two different places.) Although ideally for convenient redistribution of binaries linked with the library with GCC there would be permissive licensing, I'm not sure we should necessarily rule out an LGPL library which would generally be dynamically linked into binaries. > 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. crlibm would seem a good starting point for some functions (note that it's possible to balance speed and size - build larger tables for faster functions). The authors seemed possibly amenable to permissive licensing. New GNU projects do not necessarily need copyright assignments to the FSF and my inclination would be to make this a non-assigning project, that could use BSD code if it seems appropriate. But I'd think of such a project in any case as a large, long-term project needing an appropriate investment of effort, that probably wouldn't start with a full set of routines - it would start with a few functions, for a few types, and grow gradually while carefully tracking the properties of each implementation. Testcases from existing implementations could be used under a range of licenses. -- Joseph S. Myers joseph@codesourcery.com

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

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