This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: generic fabs implementation
- From: "Wilco Dijkstra" <wdijkstr at arm dot com>
- To: "'Joseph Myers'" <joseph at codesourcery dot com>
- Cc: "Szabolcs Nagy" <Szabolcs dot Nagy at arm dot com>, <libc-alpha at sourceware dot org>
- Date: Tue, 19 May 2015 15:00:20 +0100
- Subject: RE: generic fabs implementation
- Authentication-results: sourceware.org; auth=none
- References: <000101d07776$0c9c4ac0$25d4e040$ at com> <5555D5F7 dot 2020203 at arm dot com> <000101d09152$07bb5e10$17321a30$ at com> <alpine dot DEB dot 2 dot 10 dot 1505181647240 dot 20209 at digraph dot polyomino dot org dot uk>
> Joseph Myers wrote:
> On Mon, 18 May 2015, Wilco Dijkstra wrote:
>
> > Given GLIBC can now rely on a modern GCC for its build, can we avoid
> > this and actually use the builtins rather than having each target
> > override the generic implementation with an inline assembler version?
> >
> > double
> > __fabs (double x)
> > {
> > - u_int32_t high;
> > - GET_HIGH_WORD (high, x);
> > - SET_HIGH_WORD (x, high & 0x7fffffff);
> > - return x;
> > + return __builtin_fabs (x);
> > }
> >
> > GCC will always inline __builtin_fabs, with -O0, -Os and -fno-builtin.
>
> I believe doing this is safe (in that a proper inline expansion will be
> generated, by bit-fiddling if needed) *except for the ldbl-128ibm version
> of fabsl* (where fabs isn't simply a matter of clearing one bit, and GCC
> doesn't know how to do it correctly inline for soft-float / e500 - see GCC
> bug 29253 and the corresponding -fno-builtin-fabsl in
> sysdeps/powerpc/nofpu/Makefile).
OK, so I'll only do float and double. It seems 128-bit is usually emulated
so the current implementation is already optimal.
> However, there might be cases where GCC generates calls to an
> absolute-value instruction that fails to clear the sign bit of a NaN, or
> predates IEEE 754-2008 and raises "invalid" for a signaling NaN. At least
> the former would be a clear GCC bug (on MIPS, for example, GCC makes sure
> to avoid abs instructions unless -mabs=2008 or -ffinite-math-only, for
> that reason), but it's something to watch out for.
If GCC implements fabs incorrectly then any code that uses fabs (including
libm which calls fabs in many places) would fail today. So the above patch
cannot introduce any new failures. I'll send out my patch at later date.
Wilco