This is the mail archive of the
`libc-alpha@sourceware.org`
mailing list for the glibc 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*: OndÅej BÃlka <neleai at seznam dot cz>*To*: Joseph Myers <joseph at codesourcery dot com>*Cc*: andrew dot n dot senkevich at gmail dot com, libc-alpha at sourceware dot org*Date*: Wed, 12 Aug 2015 19:25:31 +0200*Subject*: Re: [RFC] Use simpler math functions when user selects -ffast-math*Authentication-results*: sourceware.org; auth=none*References*: <20150811223007 dot GA21338 at domone> <alpine dot DEB dot 2 dot 10 dot 1508121636330 dot 20932 at digraph dot polyomino dot org dot uk>

On Wed, Aug 12, 2015 at 04:45:55PM +0000, Joseph Myers wrote: > On Wed, 12 Aug 2015, OndÅej BÃlka wrote: > > > Hi Andrew, > > > > When I checked isfinite performance I noticed that for most math > > functions wrapper is unnecessary when -ffinite-math-only is set from > > -ffast-math as they evaluate to constant. > > It's already the case that -ffinite-math-only causes __*_finite versions > of many libm functions to be used, so bypassing the wrappers. Or do you > mean something other than the math/w_*.c wrappers? > Ah, when I read code I didn't notice these. I got this when thinking how to eliminate wrappers. I got idea that we could inline wrapper and teach gcc dataflow to compute float upper and lower bounds. Currently it couldn't simplify if (0.0 < x && x < 1.0 && __finite (x)) That would allow add macro to test with builtin_constant_p if function arguments imply finite result and call function_finite if so. > > Adding new symbols would allow to fix bug that due accuracy math > > functions need to be very slow on some inputs. As with -ffast-math you > > don't have to worry much about accuracy we could finally fix these bugs. > > As far as I know, we have consensus on the documented accuracy goals for > libm functions, which do *not* require pow, exp, log, sin, cos, tan, asin, > acos, atan or atan2 to be correctly rounded. Thus, various dbl-64 > performance issues (bugs 5781, 13932, 17211, at least) could probably be > addressed by removing the very slow multiple-precision cases and allowing > non-correctly-rounded results for some inputs. > > *But* simply removing the multiple-precision cases isn't appropriate > without justification that it is safe. That is, each removal needs to > include an error analysis of the existing non-multiple-precision code that > shows why, even if you remove the multiple-precision case, the errors > still won't be too big for any inputs. The error analysis might be fairly > simple, but it does need to be there. > So first we should document accuracy of these functions, which could also allow to simplify vector ones when they use same algorithm.

**References**:**[RFC] Use simpler math functions when user selects -ffast-math***From:*OndÅej BÃlka

**Re: [RFC] Use simpler math functions when user selects -ffast-math***From:*Joseph Myers

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

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