Message ID  HE1PR0801MB205886FEFE1BC4014C192EDF83560@HE1PR0801MB2058.eurprd08.prod.outlook.com 

State  New 
Headers  show 
Series 

Related  show 
On Wed, 8 Nov 2017, Wilco Dijkstra wrote: > Several math functions have wrappers which handle errno. They are > bypassed if __FINITE_MATH_ONLY__ is set. Given the wrappers impose > a significant overhead, bypassing them is worthwhile (and it is best > to remove them completely in the future). > > Since the only purpose of the wrappers is to set errno, we can bypass > them if __NO_MATH_ERRNO__ is set as well. There are a few target specific > functions which define finite variants of math functions and those do not > set exceptions. In those cases it would be incorrect to bypass the wrapper > unless __FINITE_MATH_ONLY__ is set. To support this add a define that > allows targets to disable this. It's currently set for x86 and x86_64 > due to defining several x87 math functions which only support finite math. I think this sort of ABI change needs a much more detailed analysis and proposal seeking consensus before any patch is proposed based on the results of such discussion. That is, in exactly what circumstances are _finite functions different beyond just not using wrappers? And, in what circumstances would an implementation that genuinely relies on ffinitemathonly be more efficient than one that just avoids wrappers (and in such circumstances, should be add such an implementation or consider it out of scope)? Because this is an ABI change that can only be made, but not reversed: if we make such a change and then wish to add a genuinely ffinitemathonly function version in future, it needs to use a different name such as _really_finite so that it isn't used by any binaries that were built with 2.27 with fnomatherrno and so rely on _finite meaning only nomatherrno. HAS_FINITE_MATH_FUNCTIONS is in the user namespace and so inappropriate for installed headers. bits/mathinline.h is included only for __USE_EXTERN_INLINES and so cannot be used for defining macros tested in code that is not conditional on __USE_EXTERN_INLINES.
Joseph Myers wrote: > On Wed, 8 Nov 2017, Wilco Dijkstra wrote: > > > Several math functions have wrappers which handle errno. They are > > bypassed if __FINITE_MATH_ONLY__ is set. Given the wrappers impose > > a significant overhead, bypassing them is worthwhile (and it is best > > to remove them completely in the future). > > > > Since the only purpose of the wrappers is to set errno, we can bypass > > them if __NO_MATH_ERRNO__ is set as well. There are a few target specific > > functions which define finite variants of math functions and those do not > > set exceptions. In those cases it would be incorrect to bypass the wrapper > > unless __FINITE_MATH_ONLY__ is set. To support this add a define that > > allows targets to disable this. It's currently set for x86 and x86_64 > > due to defining several x87 math functions which only support finite math. > > I think this sort of ABI change needs a much more detailed analysis and > proposal seeking consensus before any patch is proposed based on the > results of such discussion. Sure  I just wanted to propose something concrete. The alternative would be to remove the wrappers like we've done for a few functions so far, but that is a fair amount of work (although I guess we could remove the finitemath.h header once the commonly used functions had their wrappers merged). > That is, in exactly what circumstances are _finite functions different > beyond just not using wrappers? And, in what circumstances would an > implementation that genuinely relies on ffinitemathonly be more > efficient than one that just avoids wrappers (and in such circumstances, > should be add such an implementation or consider it out of scope)? My feeling is that bypassing/removing the wrappers gives the most benefit. You always need to check some special cases, and checks for infinity/NaN can often be merged with those. Adding fast math variants with a larger ULP error would definitely be more useful than finite math variants. > Because this is an ABI change that can only be made, but not reversed: if > we make such a change and then wish to add a genuinely ffinitemathonly > function version in future, it needs to use a different name such as > _really_finite so that it isn't used by any binaries that were built with > 2.27 with fnomatherrno and so rely on _finite meaning only > nomatherrno. Yes that is a good point. Wilco
diff git a/math/math.h b/math/math.h index d46c26533eff01dfbcee8f59d022febdbdb8d769..26a985728ec86fa4302455a98bf3326afc901b37 100644  a/math/math.h +++ b/math/math.h @@ 709,8 +709,9 @@ iszero (__T __val) #endif /* Define special entry points to use when the compiler got told to  only expect finite results. */ #if defined __FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0 + only expect finite results or errno is not used. */ +#if (defined __FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0) \ +  (defined __NO_MATH_ERRNO__ && !defined HAS_FINITE_MATH_FUNCTIONS) /* Include bits/mathfinite.h for double. */ # define _Mdouble_ double diff git a/sysdeps/x86/fpu/bits/mathinline.h b/sysdeps/x86/fpu/bits/mathinline.h index cf29751a2781d11cd835b2e8213443b52d84f10f..973a3603240a37459baf49f341c5c294377c3bf7 100644  a/sysdeps/x86/fpu/bits/mathinline.h +++ b/sysdeps/x86/fpu/bits/mathinline.h @@ 20,6 +20,10 @@ # error "Never use <bits/mathinline.h> directly; include <math.h> instead." #endif +/* Some math functions have finite variants which do not support exceptions, + so we may use the finite variant only with __FINITE_MATH_ONLY__. */ +#define HAS_FINITE_MATH_FUNCTIONS 1 + #ifndef __extern_always_inline # define __MATH_INLINE __inline #else