This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gcc builtin review: isinf, insnan ...
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Julian Taylor <jtaylor dot debian at googlemail dot com>
- Cc: Wilco Dijkstra <wdijkstr at arm dot com>, libc-alpha at sourceware dot org, pinskia at gmail dot com
- Date: Wed, 27 May 2015 19:55:32 +0200
- Subject: Re: Gcc builtin review: isinf, insnan ...
- Authentication-results: sourceware.org; auth=none
- References: <A610E03AD50BFC4D95529A36D37FA55E769AD3FAC3 at GEORGE dot Emea dot Arm dot com> <000e01d0988d$686514d0$392f3e70$ at com> <5565FBB4 dot 4090205 at googlemail dot com>
On Wed, May 27, 2015 at 07:15:32PM +0200, Julian Taylor wrote:
> On 27.05.2015 16:57, Wilco Dijkstra wrote:
> > OndÅej BÃlka wrote:
> >> I raised this issue before but didn't wrote patch so I should do it now.
> >> I would be silent about glibc as it shares same flaw as gcc.
> >>
> >> Main problem that these functions try to be branchless. Which causes
> >> performance regression for most applications versus branched code.
> >
> > Being branchless is one issue indeed but the main issue they are never
> > inlined on any target as GLIBC headers explicitly disable inlining by GCC.
> >
>
>
> This is a huge problem for almost all numerical applications that don't
> care about signaling nans, so basically all.
> I had to fix too many applications having poor performance due to that
> (e.g.
> http://yarikoptic.github.io/numpy-vbench/vb_vb_ufunc.html#numpy-isnan-a-10types)
>
> I would love when glibc would somehow allow programs to use the builtin
> via the isnan function in an easy way, so not via compiler specific
> compiler flags like -fno-signaling-nan or preprocessor compiler version
> checks.
> Maybe alway direct to the builtin/fastest possible non signaling
> implementation when some GIVE_ME_FAST_BOOL_ISNAN is defined before
> including <math.h>?
>
> Also note that gcc has updated their documentation which might allow to
> now use __builtin_isinf
> (https://sourceware.org/bugzilla/show_bug.cgi?id=15367)
A simple inclusion of math.h should be enough. As now redirecting to
builtin would be slower than offering one in header which would also fix
signaling issue.
Only reason when nonconstant builtin would make sense would be if gcc
started to analyze floats to prove that operations are finite. It
doesn't do that. It keeps isinf even in simplest cases like
int
foo (double d)
{
if (d < 11) return 1;
if (d > 444) return 2;
if (isinf (d)) return 3;
return 4;
}