This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [QUERY] How many platforms are using the soft-float ieee128 math

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]