This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: Gcc builtin review: isinf, insnan ...
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: Ondřej Bílka <neleai at seznam dot cz>, <libc-alpha at sourceware dot org>, <pinskia at gmail dot com>
- Date: Fri, 29 May 2015 20:24:27 +0000
- 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> <alpine dot DEB dot 2 dot 10 dot 1505281736460 dot 16930 at digraph dot polyomino dot org dot uk> <20150529115936 dot GA22184 at domone> <alpine dot DEB dot 2 dot 10 dot 1505291322320 dot 18021 at digraph dot polyomino dot org dot uk> <001101d09a3d$4d456360$e7d02a20$ at com>
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