This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: Macros using __NO_LONG_DOUBLE_MATH
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Joseph Myers'" <joseph at codesourcery dot com>
- Cc: "GNU C Library" <libc-alpha at sourceware dot org>
- Date: Mon, 8 Jun 2015 17:28:01 +0100
- Subject: RE: Macros using __NO_LONG_DOUBLE_MATH
- Authentication-results: sourceware.org; auth=none
- References: <000801d09eb7$48f0aa80$dad1ff80$ at com> <alpine dot DEB dot 2 dot 10 dot 1506041456390 dot 12011 at digraph dot polyomino dot org dot uk> <000a01d0a1e7$0f3bf7d0$2db3e770$ at com> <alpine dot DEB dot 2 dot 10 dot 1506081235330 dot 25225 at digraph dot polyomino dot org dot uk>
> Joseph Myers wrote:
> On Mon, 8 Jun 2015, Wilco Dijkstra wrote:
>
> > > I don't see how such a change would benefit using GCC built-in functions
> > > anyway. Presumably you'd do
> > >
> > > # if __GNUC_PREREQ (6, 0)
> >
> > I'm using __GNUC_PREREQ (4, 4) && !defined __SUPPORT_SNAN__ to enable
> > inlining - better to have inlining even if it isn't 100% optimal rather
> > than no inlining and having to go through the PLT to call a
> > 4-instruction function...
>
> Do you have at least microbenchmarks to confirm the existing GCC inline
> expansions are better than the glibc out-of-line calls? Such
> microbenchmarks should preferably go in glibc's benchmark suite.
I wrote a quick test, and __builtin_isinf_sign is 3.5 times faster than
__isinf if the value is not an infinity (common case). __builtin_isinf
is twice as fast as __builtin_isinf_sign if the sign might be used, even
if the value is not an infinity... Isnan etc show similar gains of ~6.5x.
So yes that shows that PLT entries remain expensive even with modern
branch predictors.
> Logically glibc should be built with -fsignaling-nans, but it's possible
> we get away without that in most cases (as in: most functions *should*
> raise "invalid" for signaling NaN operands, so an implementation of is*
> that spuriously raises that for signaling NaNs wouldn't actually cause
> problems, and we may not rely on avoiding optimizations that are invalid
> for signaling NaNs). Of course some issues could be covered up by lack of
> test coverage (and at least tests of signaling NaNs ought to be built with
> that option).
Making GLIBC support sNaN correctly is likely a lot of work - many functions
start like this: if (isinf(x) || x == 0.0)... And there seems to be no test
coverage besides test-snan.c (which I changed to build with -fsignaling-nans
so it passes with the new math.h).
Anyway I created GCC bug 66462 to fix the built-ins.
Wilco