Re: Gcc builtin review: isinf, insnan ...

[OndÅej BÃlka <neleai at seznam dot cz>]

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;
}