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*: James Courtier-Dutton <james dot dutton at gmail dot com>*To*: gcc at gcc dot gnu dot org*Date*: Sat, 18 Feb 2012 14:38:01 +0000*Subject*: Re: weird optimization in sin+cos, x86 backend*Authentication-results*: mr.google.com; spf=pass (google.com: domain of james.dutton@gmail.com designates 10.229.69.33 as permitted sender) smtp.mail=james.dutton@gmail.com; dkim=pass header.i=james.dutton@gmail.com*References*: <CADn89gRRwQ5uPGCDMGZo28ofnAQsvU5PURKxPuvOPF1+ZbvO8g@mail.gmail.com> <4F34F4B3.6020102@redhat.com> <CAAMvbhE79bX5HSmdmMDj6qzEezNYDxwij05Wrn2d6juiLT0r2A@mail.gmail.com> <13705919.FRyksWSSBh@vmx> <4F3556DD.80604@redhat.com> <20120213152443.GE26414@xvii.vinc17.org>

On 13 February 2012 15:24, Vincent Lefevre <vincent+gcc@vinc17.org> wrote: > On 2012-02-10 17:41:49 +0000, Andrew Haley wrote: >> On 02/10/2012 05:31 PM, PaweÅ Sikora wrote: >> > it would be also nice to see functions for reducing argument range in public api. >> > finally the end-user can use e.g. sin(reduce(x)) to get the best precision >> > with some declared cpu overhead. >> >> Hmm. ÂI'm not sure this is such a terrific idea: each function has its >> own argument reduction (e.g. to [0, pi/4], [0, pi/8] or even [0, some >> weird constant that looks arbitrary but just happens to be exactly >> representable in binary]). ÂYou really don't want double rounding, >> which is what would happen with sin(reduce(x)). > > I agree. Also, range reduction may also be completely different. > The general scheme is: > > 1. Reduce the argument x (for periodic function, it is an additive > Â reduction, but for some other functions, it can be a multiplicative > Â reduction). > > 2. Compute some alternate function(s) on the reduced argument. > Â For the first range reduction of periodic functions, it is the > Â same function, but in other cases, this may be other functions. > > 3. Reconstruct the final value. Nothing to do for the first range > Â reduction of periodic functions, but again, this is not always > Â the case. > Would it be useful to have some lib functions: remainder_2pi(x, &remainder) /* returns remainder of x / 2Pi */ remainder_pi2(x, &remainder, "ient) /* returns remainder of x / (Pi/2) with a quotient returned so you can tell where in the range [0 , 2Pi] it would fall. */ remainder_pi4(x, &remainder, "ient) /* returns remainder of x / (Pi/4), with a quotient returned. The reason for these special pi remainder functions is do with PI being need to many 100s of decimal places in order to create an accurate result so remainder(x, y) with y being set to double float PI would not be accurate enough. Kind Regards James

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

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

**Re: weird optimization in sin+cos, x86 backend***From:*PaweÅ Sikora

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