This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Gcc builtin review: isinf, insnan ...
- From: Julian Taylor <jtaylor dot debian at googlemail dot com>
- To: Wilco Dijkstra <wdijkstr at arm dot com>, 'Ondřej Bílka' <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org, pinskia at gmail dot com
- Date: Wed, 27 May 2015 19:15: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>
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)