[musl] [PATCH] PPC64 IEEE128 bit FP support

Post by David Edelsohn
The IBM Power9 processor adds support for IEEE 754 quad precision 128
binary floating point. The attached patch from my colleague should
enable the basic support. musl never has supported the IBM long
double floating point format. The patch only enables musl long double
support when built with and used with a toolchain that enables IEEE
128 bit FP.
Any suggestions on how to transition this support in musl?
Thanks, David
P.S. A Power9 system now is available in the GNU Compile Farm.
From de28b4d36616ed583ec247639d13bd76216fd3bf Mon Sep 17 00:00:00 2001
Date: Fri, 19 Oct 2018 10:09:49 -0300
Subject: [PATCH] powerpc64: Add support for IEEE 128-bit floating point long
double
---
INSTALL | 4 ++--
arch/powerpc64/bits/float.h | 17 +++++++++++++++++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/INSTALL b/INSTALL
index a2a142bf..00d7282d 100644
--- a/INSTALL
+++ b/INSTALL
* PowerPC64
* Both little and big endian variants are supported
- * Compiler toolchain must provide 64-bit long double, not IBM
- double-double or IEEE quad
+ * Compiler toolchain must provide 64-bit long double, or IEEE 128-bit
+ long double not IBM double-double
* Compiler toolchain must use the new (ELFv2) ABI regardless of
whether it is for little or big endian
diff --git a/arch/powerpc64/bits/float.h b/arch/powerpc64/bits/float.h
index c4a655e7..4e485512 100644
--- a/arch/powerpc64/bits/float.h
+++ b/arch/powerpc64/bits/float.h
@@ -1,3 +1,19 @@
+#if __LDBL_MANT_DIG__ == 113
+#define LDBL_TRUE_MIN 6.47517511943802511092443895822764655e-4966L
+#define LDBL_MIN 3.36210314311209350626267781732175260e-4932L
+#define LDBL_MAX 1.18973149535723176508575932662800702e+4932L
+#define LDBL_EPSILON 1.92592994438723585305597794258492732e-34L
+
+#define LDBL_MANT_DIG 113
+#define LDBL_MIN_EXP (-16381)
+#define LDBL_MAX_EXP 16384
+
+#define LDBL_DIG 33
+#define LDBL_MIN_10_EXP (-4931)
+#define LDBL_MAX_10_EXP 4932
+
+#define DECIMAL_DIG__ 36
+#else
#define FLT_EVAL_METHOD 0
#define LDBL_TRUE_MIN 4.94065645841246544177e-324L
@@ -14,3 +30,4 @@
#define LDBL_MAX_10_EXP 308
#define DECIMAL_DIG 17
+#endif
--
2.14.4

This patch can't be applied without corresponding patches to configure
and arch/powerpc64/reloc.h that define a new ldso name for the ABI.
Otherwise it produces ABI breakage.

As submitted, it also seems to be removing FLT_EVAL_METHOD in the new
ABI, but this is easily fixed.

Also, what is the calling convention for IEEE quad? Does it use
registers that are only available on certain models, so that not just
the hard-float code using it, but also the basic ABI, has a minimum
ISA level associated with it? Or is the calling convention compatible
with older models too and just needing softfloat code on them (which
libgcc presumably provides)?

Rich

Markus Wichmann

2018-10-26 04:28:29 UTC

Now you just need to look through all the maths code to find all the
places that need changing. __floatscan() comes to mind immediately. And
I don't know if any of the libm functions needs adjustment for this new
format.

Ciao,
Markus

Szabolcs Nagy

2018-10-26 13:01:20 UTC

Post by Markus Wichmann
Now you just need to look through all the maths code to find all the
places that need changing. __floatscan() comes to mind immediately. And
I don't know if any of the libm functions needs adjustment for this new
format.

generic c code in musl should work for all supported
floating-point formats, which includes ieee binary128
for long double.

only float.h needs to be set up according to the abi.

some long double math functions don't have high quality
implementations for ieee binary128 format though.

Rich Felker

2018-11-02 16:13:35 UTC

generic c code in musl should work for all supported
floating-point formats, which includes ieee binary128
for long double.
only float.h needs to be set up according to the abi.
some long double math functions don't have high quality
implementations for ieee binary128 format though.

Yes. Assuming there aren't other problems revealed by my questions
about argument passing and ISA levels, I think the only blocking issue
here is naming the ABI. I forgot to mention but that should also
involve a gcc patch that we can put in mcm and eventually upstream.

QoI issues for IEEE-quad-based [sub]archs can be improved later;
aarch64 and s390x are already affected IIRC.

Rich

David Edelsohn

2018-11-02 17:32:55 UTC

I don't believe that musl currently supports IBM double-double long
double format, only IEEE 754 64 bit double precision as long double.

IBM is working with other toolchains to support both the original
double-double and the new 128 bit quad precision through compiler
options, compiler macros, header definitions, and symbol compatibility
in libraries. musl still would not support IBM double-double format.

I don't know if it would be necessary for musl libc long double to be
selectable for backward compatibility or one can implement a "flag
day" where a musl libc release switches to only 128 bit quad precision
long double.

Thanks, David

generic c code in musl should work for all supported
floating-point formats, which includes ieee binary128
for long double.
only float.h needs to be set up according to the abi.
some long double math functions don't have high quality
implementations for ieee binary128 format though.

Yes. Assuming there aren't other problems revealed by my questions
about argument passing and ISA levels, I think the only blocking issue
here is naming the ABI. I forgot to mention but that should also
involve a gcc patch that we can put in mcm and eventually upstream.
QoI issues for IEEE-quad-based [sub]archs can be improved later;
aarch64 and s390x are already affected IIRC.
Rich

Szabolcs Nagy

2018-11-02 17:55:16 UTC

Post by David Edelsohn
I don't know if it would be necessary for musl libc long double to be
selectable for backward compatibility or one can implement a "flag
day" where a musl libc release switches to only 128 bit quad precision
long double.

since currently long double is ieee-binary64 in musl,
if we want it to be ieee-binary128 then that's a new
abi and in musl new abi means a new dynamic linker name:
current toolchain uses /lib/ld-musl-powerpc64le.so.1, a new
toolchain would use e.g. /lib/ld-musl-powerpc64le_f128.so.1

i think even if the 64bit long double is deprecated and not
selectable in gcc anymore, we would use a new dynamic
linker name (but i think in musl we can easily keep supporting
two long double variants, the difficulty is in the gcc config
machinery and ux issues if there are no abi markers for
relocatable objects to detect abi mismatch at link time).

Post by David Edelsohn
Thanks, David

generic c code in musl should work for all supported
floating-point formats, which includes ieee binary128
for long double.
only float.h needs to be set up according to the abi.
some long double math functions don't have high quality
implementations for ieee binary128 format though.

Yes. Assuming there aren't other problems revealed by my questions
about argument passing and ISA levels, I think the only blocking issue
here is naming the ABI. I forgot to mention but that should also
involve a gcc patch that we can put in mcm and eventually upstream.
QoI issues for IEEE-quad-based [sub]archs can be improved later;
aarch64 and s390x are already affected IIRC.
Rich

David Edelsohn

2018-11-02 18:00:36 UTC

IEEE binary64 still will be available for long double.

Current musl libc has not been compatible with the ABI and with
current GLIBC because it did not implement IBM double-double format.

Musl libc can call it an ABI break, but musl libc has not been compatible.

And the new configuration in GCC, LLVM and GLIBC allow both IBM
double-double and IEEE 754 binary128 to co-exist. Changing the musl
libc dynamic linker name doesn't fix that and actually makes musl libc
even less compatible with the rest of the PPC64LE Linux Ecosystem.

Thanks, David

since currently long double is ieee-binary64 in musl,
if we want it to be ieee-binary128 then that's a new
current toolchain uses /lib/ld-musl-powerpc64le.so.1, a new
toolchain would use e.g. /lib/ld-musl-powerpc64le_f128.so.1
i think even if the 64bit long double is deprecated and not
selectable in gcc anymore, we would use a new dynamic
linker name (but i think in musl we can easily keep supporting
two long double variants, the difficulty is in the gcc config
machinery and ux issues if there are no abi markers for
relocatable objects to detect abi mismatch at link time).

Post by David Edelsohn
Thanks, David

generic c code in musl should work for all supported
floating-point formats, which includes ieee binary128
for long double.
only float.h needs to be set up according to the abi.
some long double math functions don't have high quality
implementations for ieee binary128 format though.

Yes. Assuming there aren't other problems revealed by my questions
about argument passing and ISA levels, I think the only blocking issue
here is naming the ABI. I forgot to mention but that should also
involve a gcc patch that we can put in mcm and eventually upstream.
QoI issues for IEEE-quad-based [sub]archs can be improved later;
aarch64 and s390x are already affected IIRC.
Rich

Rich Felker

2018-11-02 19:06:49 UTC

Post by David Edelsohn
IEEE binary64 still will be available for long double.
Current musl libc has not been compatible with the ABI and with
current GLIBC because it did not implement IBM double-double format.
Musl libc can call it an ABI break, but musl libc has not been compatible.

We do not implement the same ABI as glibc on all systems. On a very
few, it's mostly or entirely the same, but at least on PowerPC and
MIPS there are significant differences.

Post by David Edelsohn
And the new configuration in GCC, LLVM and GLIBC allow both IBM
double-double and IEEE 754 binary128 to co-exist. Changing the musl
libc dynamic linker name doesn't fix that and actually makes musl libc
even less compatible with the rest of the PPC64LE Linux Ecosystem.

I don't know what you mean by "allow double-double and IEEE [quad] to
co-exist". Object files/shared libraries built for one obviously
cannot be linked with the other. The way incompatible archs/ABIs
co-exist on musl is always via different ldso names and library paths;
this is regardless of arch (and even across different archs). If
there's some other way of doing it on glibc/powerpc, like having a
shared dynamic linker that selects the right-ABI libraries to load,
that's fine for glibc but unrelated to musl.

Rich

Post by David Edelsohn

Post by David Edelsohn
Thanks, David