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

["Wilco Dijkstra" <wdijkstr at arm dot com>]

> Joseph Myers wrote:
> On Fri, 29 May 2015, Ondřej Bílka wrote:
> 
> > On Thu, May 28, 2015 at 05:49:05PM +0000, Joseph Myers wrote:
> > > On Wed, 27 May 2015, Wilco Dijkstra wrote:
> > >
> > > It's not obvious that integer arithmetic is optimal in all cases (if the
> > > implementation is otherwise correct given the compiler options passed).
> > > For example, if the argument is in a floating-point register and an
> > > integer implementation would involve the (architecture-specific) costs of
> > > moving it to an integer register - obviously something that can only be
> > > decided quite late in code generation.
> > >
> > Naturally one should check which implementation is best. Could you send
> > link to numeric application and how to measure it that was mentioned
> > before?
> 
> I have no idea which is best - all I assert here is that it's not obvious
> that "should not be used until they are fixed to use integer arithmetic"
> is true (any patch to use the GCC built-in functions should come with
> benchmark data as well as information on correctness).  It may well be the
> case that changing the GCC built-in functions to use integer arithmetic is
> unconditionally beneficial; such a change obviously needs benchmark data
> (in a way that changing for correctness with -fsignaling-nans only
> wouldn't).

Note another issue is that GCC tends to use FP arithmetic with -ffast-math
for FP related built-ins (even when it uses integer arithmetic with -O2/-O3), 
presumably on the assumption that FP calculations are faster. This is not true
on most CPUs but it spectacularly backfires when using software floating point...

int test(double x)
{
  return __builtin_signbit (x);
}

-O3 -mfloat-abi=soft:
        and     r0, r1, #-2147483648
        bx      lr

-Ofast -mfloat-abi=soft:
        push    {r3, lr}
        movs    r2, #0
        movs    r3, #0
        bl      __aeabi_dcmplt
        adds    r0, r0, #0
        it      ne
        movne   r0, #1
        pop     {r3, pc}

So these built-ins "should not be used until they are fixed to use integer 
arithmetic" :-)

> All other things being equal, use of type-generic built-in functions has
> the advantage that the macro expansion text only contains the argument
> text once - generally a good idea when macro calls may be nested inside
> arguments to other macros.

Agreed, I'd much prefer the GCC builtins doing the right thing. However what 
to do when they don't? Assuming we agree to just support inline functions in 
headers from GCC4.0 onwards, given the built-ins in GCC are not good enough, 
we still need explicit optimized implementations for all of signbit, isinf etc
even if they were fixed in GCC6.

Wilco