This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Bypass math wrappers with -fno-math-errno
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