Gcc builtin review: isinf, insnan ...

[Joseph Myers]

On Fri, 29 May 2015, Wilco Dijkstra wrote:

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

GCC bug report number?  I don't think this is an assumption that FP 
calculations are faster; it seems a simple inconsistency between tree 
folding (prefers expanding to a comparison when no signed zeroes) and RTL 
expansion (prefers bit manipulation whenever a read-only sign bit is 
available, which it always is for all currently-supported floating-point 
formats).

> 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.

Well, if you want a -ffast-math version of signbit (commented to be 
working around a particular, preferably fixed, GCC bug, with __GNUC_PREREQ 
conditionals) - if that's considered sufficiently important - at least it 
ought to be architecture-independent (maybe one bits/ header per 
floating-point format) rather than duplicated per-architecture.

-- 
Joseph S. Myers
joseph@codesourcery.com