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*: Vincent Lefevre <vincent+gcc at vinc17 dot org>*Cc*: gcc at gcc dot gnu dot org*Date*: Mon, 13 Feb 2012 14:18:03 +0000 (UTC)*Subject*: Re: weird optimization in sin+cos, x86 backend*References*: <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> <4F33EB11.3040603@redhat.com> <Pine.LNX.4.64.1202091656260.25409@wotan.suse.de> <4F33ECEE.2060600@redhat.com> <CAFiYyc2yXGrQp_4Dmty+B2BMDkdLzi5PBZpY8km98MAH7DG9sQ@mail.gmail.com> <4F33EDEC.7050303@redhat.com> <20120213131114.GA26414@xvii.vinc17.org>

On Mon, 13 Feb 2012, Vincent Lefevre wrote: > Also note that CRlibm supports the 4 rounding modes, while the > IBM Accurate Mathematical Library currently used in glibc behaves > erratically (e.g. can even crash) on directed rounding modes. FWIW the proposed ISO C bindings to IEEE 754-2008 (still at an early draft stage) include static rounding directions set by an FENV_ROUND pragma as well as dynamic rounding directions. Assuming the processor only has one set of rounding modes so arithmetic in a static mode requires the compiler to insert code to save and restore the rounding mode, the rule is that function calls to functions in math.h and a few other headers are affected by the static mode but other calls are affected by the dynamic mode so the rounding mode would need restoring for the other calls. You then have the cases: * Dynamic rounding mode in effect: user calls a function such as sin, which should handle the mode it is called with (maybe checking what that mode is, then setting the mode to round-to-nearest for most of the internal calculations). * Static mode in effect: can call sin with the dynamic mode set to that static mode, but may be better for the compiler to select a function for the right mode and call it directly if it knows what the functions for each mode are called. Of course right now it would make sense for the problematic functions from the IBM Accurate Mathematical Library to be changed to set round-to-nearest internally if they can't handle other modes, to make things less bad until a better solution can be in place.... -- Joseph S. Myers joseph@codesourcery.com

**References**:**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:*Andrew Haley

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

**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:*Andrew Haley

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