[PATCH] PPC64 IEEE128 bit FP support

[PATCH] PPC64 IEEE128 bit FP support

[David Edelsohn]

[-- Attachment #1: Type: text/plain, Size: 493 bytes --]

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.

[-- Attachment #2: 0001-powerpc64-Add-support-for-IEEE-128-bit-floating-poin.patch --]
[-- Type: text/x-patch, Size: 1801 bytes --]

From de28b4d36616ed583ec247639d13bd76216fd3bf Mon Sep 17 00:00:00 2001
From: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
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
@@ -76,8 +76,8 @@ and ABI combinations:
 
 * 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

Re: [PATCH] PPC64 IEEE128 bit FP support

[Rich Felker]

On Thu, Oct 25, 2018 at 03:12:51PM -0400, David Edelsohn wrote:
> 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
> From: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
> 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
> @@ -76,8 +76,8 @@ and ABI combinations:
>  
>  * 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

Re: [PATCH] PPC64 IEEE128 bit FP support

[Markus Wichmann]

On Thu, Oct 25, 2018 at 03:12:51PM -0400, David Edelsohn wrote:
> 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.


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

Re: [PATCH] PPC64 IEEE128 bit FP support

[Szabolcs Nagy]

* Markus Wichmann <nullplan@gmx.net> [2018-10-26 06:28:29 +0200]:
> 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.

Re: [PATCH] PPC64 IEEE128 bit FP support

[Rich Felker]

On Fri, Oct 26, 2018 at 03:01:20PM +0200, Szabolcs Nagy wrote:
> * Markus Wichmann <nullplan@gmx.net> [2018-10-26 06:28:29 +0200]:
> > 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.

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

Re: [PATCH] PPC64 IEEE128 bit FP support

[David Edelsohn]

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
On Fri, Nov 2, 2018 at 12:13 PM Rich Felker <dalias@libc.org> wrote:
>
> On Fri, Oct 26, 2018 at 03:01:20PM +0200, Szabolcs Nagy wrote:
> > * Markus Wichmann <nullplan@gmx.net> [2018-10-26 06:28:29 +0200]:
> > > 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.
>
> 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

Re: [PATCH] PPC64 IEEE128 bit FP support

[Szabolcs Nagy]

* David Edelsohn <dje.gcc@gmail.com> [2018-11-02 13:32:55 -0400]:
> 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).

> 
> Thanks, David
> On Fri, Nov 2, 2018 at 12:13 PM Rich Felker <dalias@libc.org> wrote:
> >
> > On Fri, Oct 26, 2018 at 03:01:20PM +0200, Szabolcs Nagy wrote:
> > > * Markus Wichmann <nullplan@gmx.net> [2018-10-26 06:28:29 +0200]:
> > > > 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.
> >
> > 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

Re: [PATCH] PPC64 IEEE128 bit FP support

[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.

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

On Fri, Nov 2, 2018 at 1:55 PM Szabolcs Nagy <nsz@port70.net> wrote:
>
> * David Edelsohn <dje.gcc@gmail.com> [2018-11-02 13:32:55 -0400]:
> > 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).
>
> >
> > Thanks, David
> > On Fri, Nov 2, 2018 at 12:13 PM Rich Felker <dalias@libc.org> wrote:
> > >
> > > On Fri, Oct 26, 2018 at 03:01:20PM +0200, Szabolcs Nagy wrote:
> > > > * Markus Wichmann <nullplan@gmx.net> [2018-10-26 06:28:29 +0200]:
> > > > > 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.
> > >
> > > 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

Re: [PATCH] PPC64 IEEE128 bit FP support

[Rich Felker]

On Fri, Nov 02, 2018 at 02:00:36PM -0400, David Edelsohn wrote:
> 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.

> 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


> On Fri, Nov 2, 2018 at 1:55 PM Szabolcs Nagy <nsz@port70.net> wrote:
> >
> > * David Edelsohn <dje.gcc@gmail.com> [2018-11-02 13:32:55 -0400]:
> > > 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).
> >
> > >
> > > Thanks, David
> > > On Fri, Nov 2, 2018 at 12:13 PM Rich Felker <dalias@libc.org> wrote:
> > > >
> > > > On Fri, Oct 26, 2018 at 03:01:20PM +0200, Szabolcs Nagy wrote:
> > > > > * Markus Wichmann <nullplan@gmx.net> [2018-10-26 06:28:29 +0200]:
> > > > > > 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.
> > > >
> > > > 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