Bypass math wrappers with -fno-math-errno

  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.

OK for commit?

ChangeLog:
2017-11-08  Wilco Dijkstra  <wdijkstr@arm.com>

	* math/math.h (math_errhandling): Bypass errno wrappers if
	__NO_MATH_ERRNO__ is defined, unless HAS_FINITE_MATH_FUNCTIONS is defined.
	* sysdeps/x86/fpu/bits/mathinline.h (HAS_FINITE_MATH_FUNCTIONS): Define.
--
  

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 -ffinite-math-only 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 -ffinite-math-only 
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 -fno-math-errno and so rely on _finite meaning only 
no-math-errno.

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 finite-math.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 -ffinite-math-only 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 -ffinite-math-only 
> 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 -fno-math-errno and so rely on _finite meaning only 
> no-math-errno.

Yes that is a good point.

Wilco