This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [QUERY] How many platforms are using the soft-float ieee128 math
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <munroesj at us dot ibm dot com>
- Cc: "GNU C. Library" <libc-alpha at sourceware dot org>, <wschmidt at us dot ibm dot com>, <azanella at us dot ibm dot com>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Thu, 17 Oct 2013 20:51:48 +0000
- Subject: Re: [QUERY] How many platforms are using the soft-float ieee128 math
- Authentication-results: sourceware.org; auth=none
- References: <1382039184 dot 22373 dot 20 dot camel at spokane1 dot rchland dot ibm dot com>
On Thu, 17 Oct 2013, Steven Munroe wrote:
> But. we would like to understand the viability of the current soft-float
> ieee128 and libm functions. How many platforms are using it now and what
> is their experience.
It's generally in much better shape than ldbl-128ibm, simply because IEEE
754 floating-point formats have fewer pitfalls and generic code such as in
math/ is normally written to expect IEEE semantics. With soft-fp, it
interoperates with hardware exceptions and rounding modes; the normal
approach in that case would be to build soft-fp (TFmode only) in libgcc,
as is done for AArch64, for example, with an sfp-machine.h describing how
to interoperate with the hardware.
(Full soft-fp in glibc is for when you want exceptions and rounding modes
with pure software floating point, or might want them in future, as well
as the alpha/sparc cases where ABI-defined long double operations are
provided rather than the normal libgcc set - though it's possible to do
that in libgcc as well. None of those cases apply to this proposed ABI
change for powerpc64le, so libgcc is the right place for soft-fp functions
there; I'd expect soft-fp within glibc to be used only for providing sqrtl
- there isn't a sqrtl implementation in sysdeps/ieee754/ldbl-128 - and fma
if benchmarking shows the soft-fp version is faster than that in
sysdeps/ieee754/ldbl-128, which it certainly ought to be.)
Obviously you'll need a separate libm-test-ulps file.
Watch out for places (in GNU/Linux software in general, not just glibc)
that assume powerpc = IBM long double. I don't know the best way to
search for such assumptions. Hopefully most code tests LDBL_MANT_DIG ==
106 and so would have no problems with a change. But you have at least
sysdeps/powerpc/math-tests.h which defines SNAN_TESTS_TYPE_CAST in a way
that should only be relevant for IBM long double, and probably other
sysdeps files for powerpc that also embed such assumptions.
> When I look at x86_64 we see long double is still generating x87 80-bit
> float. I was disappointed to learn that -m128bit-long-double only
> effects data alignment.
Yes, the x86_64 ABI uses a separate __float128 type for binary128.
libgcc uses soft-fp to provide support for this type. GCC has libquadmath
to provide library functions for it. It would be nice to align the
support with draft TS 18661-3 (WG14 N1758), using _Float128 as the type
name and "f128" function name suffixes, and to provide the functionality
directly in glibc's libm rather than a separate libquadmath (somehow
making the ldbl-128 functions usable for both "long double, with _Float128
function names as aliases" and "_Float128, different from long double").
But there isn't generally that much interest in generic floating-point
improvements in GCC and glibc, meaning such things tend to get done when
they can be done as small pieces (e.g. individual bug fixes) rather than
more major projects (e.g. completing the Annex F support in GCC, or
implementing the various TS 18661 parts in both places).
--
Joseph S. Myers
joseph@codesourcery.com