long double on powerpc64

long double on powerpc64

[Bobby Bingham]

I've been working on a PPC64 port of musl lately.  I've made some good
progress, and it's time to decide what to do about the long double type.

The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
implementation to choose to use either IEEE quad, or IBM double double,
with IEEE quad being preferred.

On the compiler side, it looks like things are a bit of a mess.

Clang only supports IBM double double on PPC64, AFAICS, and therefore
won't work for us currently.

GCC support is more complicated.  It supports both 128 bit variants, as
well as supporting (and defaulting to) a 64 bit long double.  To get a
128 bit long double, you must build gcc with --with-long-double-128 or
pass -mlong-double-128, and even then you get IBM double double.  To get
IEEE quad, you must additionally pass -mlong-double-128, though there
are whispers that the default may change in gcc 7 [2].

The final piece of bad news is that gcc can't successfully build musl on
PPC64 with IEEE quad long double.  It chokes on even trivial code using
long double complex [3].  So only 64 bit long double is usable for now.

The good news is that gcc's predefined macros are sufficient to detect
which long double variant is in use.  My current thinking is that we can
support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
if we can only implement 64 bit for now.  Because it looks like the
future direction is for IEEE quad to become the default, I think that
should be the suffix-less subarch, and the 64 bit long double subarch
should have a -ld64 suffix or similar.

  1. https://members.openpowerfoundation.org/document/dl/576
  2. https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02507.html
  3. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70179

--
Bobby

Re: long double on powerpc64

[Rich Felker]

On Thu, Mar 10, 2016 at 09:16:36PM -0600, Bobby Bingham wrote:
> I've been working on a PPC64 port of musl lately.  I've made some good
> progress, and it's time to decide what to do about the long double type.
> 
> The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
> implementation to choose to use either IEEE quad, or IBM double double,
> with IEEE quad being preferred.
> 
> On the compiler side, it looks like things are a bit of a mess.
> 
> Clang only supports IBM double double on PPC64, AFAICS, and therefore
> won't work for us currently.
> 
> GCC support is more complicated.  It supports both 128 bit variants, as
> well as supporting (and defaulting to) a 64 bit long double.  To get a
> 128 bit long double, you must build gcc with --with-long-double-128 or
> pass -mlong-double-128, and even then you get IBM double double.  To get
> IEEE quad, you must additionally pass -mlong-double-128, though there
> are whispers that the default may change in gcc 7 [2].
> 
> The final piece of bad news is that gcc can't successfully build musl on
> PPC64 with IEEE quad long double.  It chokes on even trivial code using
> long double complex [3].  So only 64 bit long double is usable for now.
> 
> The good news is that gcc's predefined macros are sufficient to detect
> which long double variant is in use.  My current thinking is that we can
> support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
> if we can only implement 64 bit for now.  Because it looks like the
> future direction is for IEEE quad to become the default, I think that
> should be the suffix-less subarch, and the 64 bit long double subarch
> should have a -ld64 suffix or similar.

My leaning would be to just go with ld64 if nobody has their act
together for quad support, but let's see what people who want to use
powerpc64 think about it. The only option that's not on the table is
IBM double-double (because it's incompatible with musl's assumption of
IEEE semantics; math-savvy people in the musl community already know
this of course but I'm repeating it for the sake of possible
newcomers).

Thanks for digging up this information.

Rich

Re: long double on powerpc64

[Justin Cormack]

On 11 March 2016 at 04:17, Rich Felker <dalias@libc.org> wrote:
> On Thu, Mar 10, 2016 at 09:16:36PM -0600, Bobby Bingham wrote:
>> I've been working on a PPC64 port of musl lately.  I've made some good
>> progress, and it's time to decide what to do about the long double type.
>>
>> The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
>> implementation to choose to use either IEEE quad, or IBM double double,
>> with IEEE quad being preferred.
>>
>> On the compiler side, it looks like things are a bit of a mess.
>>
>> Clang only supports IBM double double on PPC64, AFAICS, and therefore
>> won't work for us currently.
>>
>> GCC support is more complicated.  It supports both 128 bit variants, as
>> well as supporting (and defaulting to) a 64 bit long double.  To get a
>> 128 bit long double, you must build gcc with --with-long-double-128 or
>> pass -mlong-double-128, and even then you get IBM double double.  To get
>> IEEE quad, you must additionally pass -mlong-double-128, though there
>> are whispers that the default may change in gcc 7 [2].
>>
>> The final piece of bad news is that gcc can't successfully build musl on
>> PPC64 with IEEE quad long double.  It chokes on even trivial code using
>> long double complex [3].  So only 64 bit long double is usable for now.
>>
>> The good news is that gcc's predefined macros are sufficient to detect
>> which long double variant is in use.  My current thinking is that we can
>> support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
>> if we can only implement 64 bit for now.  Because it looks like the
>> future direction is for IEEE quad to become the default, I think that
>> should be the suffix-less subarch, and the 64 bit long double subarch
>> should have a -ld64 suffix or similar.
>
> My leaning would be to just go with ld64 if nobody has their act
> together for quad support, but let's see what people who want to use
> powerpc64 think about it. The only option that's not on the table is
> IBM double-double (because it's incompatible with musl's assumption of
> IEEE semantics; math-savvy people in the musl community already know
> this of course but I'm repeating it for the sake of possible
> newcomers).

I think it would be a mistake to only support ld64, I think Bobby's approach
of two architectures is probably better, and maybe look to retire ld64
eventually.

Justin

Re: long double on powerpc64

[Szabolcs Nagy]

* Justin Cormack <justin@specialbusservice.com> [2016-03-11 11:19:22 +0000]:
> On 11 March 2016 at 04:17, Rich Felker <dalias@libc.org> wrote:
> > On Thu, Mar 10, 2016 at 09:16:36PM -0600, Bobby Bingham wrote:
> >> I've been working on a PPC64 port of musl lately.  I've made some good
> >> progress, and it's time to decide what to do about the long double type.
> >>
> >> The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
> >> implementation to choose to use either IEEE quad, or IBM double double,
> >> with IEEE quad being preferred.
> >>
> >> On the compiler side, it looks like things are a bit of a mess.
> >>
> >> Clang only supports IBM double double on PPC64, AFAICS, and therefore
> >> won't work for us currently.
> >>
> >> GCC support is more complicated.  It supports both 128 bit variants, as
> >> well as supporting (and defaulting to) a 64 bit long double.  To get a
> >> 128 bit long double, you must build gcc with --with-long-double-128 or
> >> pass -mlong-double-128, and even then you get IBM double double.  To get
> >> IEEE quad, you must additionally pass -mlong-double-128, though there
> >> are whispers that the default may change in gcc 7 [2].
> >>
> >> The final piece of bad news is that gcc can't successfully build musl on
> >> PPC64 with IEEE quad long double.  It chokes on even trivial code using
> >> long double complex [3].  So only 64 bit long double is usable for now.
> >>
> >> The good news is that gcc's predefined macros are sufficient to detect
> >> which long double variant is in use.  My current thinking is that we can
> >> support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
> >> if we can only implement 64 bit for now.  Because it looks like the
> >> future direction is for IEEE quad to become the default, I think that
> >> should be the suffix-less subarch, and the 64 bit long double subarch
> >> should have a -ld64 suffix or similar.
> >
> > My leaning would be to just go with ld64 if nobody has their act
> > together for quad support, but let's see what people who want to use
> > powerpc64 think about it. The only option that's not on the table is
> > IBM double-double (because it's incompatible with musl's assumption of
> > IEEE semantics; math-savvy people in the musl community already know
> > this of course but I'm repeating it for the sake of possible
> > newcomers).
> 
> I think it would be a mistake to only support ld64, I think Bobby's approach
> of two architectures is probably better, and maybe look to retire ld64
> eventually.
> 

if long double is 64bit then the 128bit hw floats cannot be used
with musl, because we don't want library support for __float128.

note that the glibc position is that for __float128 support the
minimum required gcc version has to change to gcc-7 because it is
abi and libc needs complex support (which will not be in gcc-6 yet).
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02222.html
https://sourceware.org/ml/libc-alpha/2016-03/msg00193.html

the problem with -ld64 suffix is that gcc-6 already has hardcoded
dynamic linker names (i don't think we can change that now, before
the gcc-6 release).

so i'd leave the dynlinker name as is, use 64bit ld for now and
rediscuss the issue when ieee128 long double works in gcc-7

Re: long double on powerpc64

[Rich Felker]

On Fri, Mar 11, 2016 at 02:04:35PM +0100, Szabolcs Nagy wrote:
> * Justin Cormack <justin@specialbusservice.com> [2016-03-11 11:19:22 +0000]:
> > On 11 March 2016 at 04:17, Rich Felker <dalias@libc.org> wrote:
> > > On Thu, Mar 10, 2016 at 09:16:36PM -0600, Bobby Bingham wrote:
> > >> I've been working on a PPC64 port of musl lately.  I've made some good
> > >> progress, and it's time to decide what to do about the long double type.
> > >>
> > >> The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
> > >> implementation to choose to use either IEEE quad, or IBM double double,
> > >> with IEEE quad being preferred.
> > >>
> > >> On the compiler side, it looks like things are a bit of a mess.
> > >>
> > >> Clang only supports IBM double double on PPC64, AFAICS, and therefore
> > >> won't work for us currently.
> > >>
> > >> GCC support is more complicated.  It supports both 128 bit variants, as
> > >> well as supporting (and defaulting to) a 64 bit long double.  To get a
> > >> 128 bit long double, you must build gcc with --with-long-double-128 or
> > >> pass -mlong-double-128, and even then you get IBM double double.  To get
> > >> IEEE quad, you must additionally pass -mlong-double-128, though there
> > >> are whispers that the default may change in gcc 7 [2].
> > >>
> > >> The final piece of bad news is that gcc can't successfully build musl on
> > >> PPC64 with IEEE quad long double.  It chokes on even trivial code using
> > >> long double complex [3].  So only 64 bit long double is usable for now.
> > >>
> > >> The good news is that gcc's predefined macros are sufficient to detect
> > >> which long double variant is in use.  My current thinking is that we can
> > >> support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
> > >> if we can only implement 64 bit for now.  Because it looks like the
> > >> future direction is for IEEE quad to become the default, I think that
> > >> should be the suffix-less subarch, and the 64 bit long double subarch
> > >> should have a -ld64 suffix or similar.
> > >
> > > My leaning would be to just go with ld64 if nobody has their act
> > > together for quad support, but let's see what people who want to use
> > > powerpc64 think about it. The only option that's not on the table is
> > > IBM double-double (because it's incompatible with musl's assumption of
> > > IEEE semantics; math-savvy people in the musl community already know
> > > this of course but I'm repeating it for the sake of possible
> > > newcomers).
> > 
> > I think it would be a mistake to only support ld64, I think Bobby's approach
> > of two architectures is probably better, and maybe look to retire ld64
> > eventually.
> 
> if long double is 64bit then the 128bit hw floats cannot be used
> with musl, because we don't want library support for __float128.

I don't follow. Are you saying we would not want quad if it requires
soft float? I think the idea here is that the baseline binaries that
work on all models would need to use soft float operations for long
double, but higher -march could use the hardware directly in the
future (and the soft support should correctly use the fenv from
hardware). That's the same as the situation for aarch64, no?

> note that the glibc position is that for __float128 support the
> minimum required gcc version has to change to gcc-7 because it is
> abi and libc needs complex support (which will not be in gcc-6 yet).
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02222.html
> https://sourceware.org/ml/libc-alpha/2016-03/msg00193.html

Support for __float128 is separate from support for targets where long
double is IEEE quad, I think. The former is not interesting IMO.

> the problem with -ld64 suffix is that gcc-6 already has hardcoded
> dynamic linker names (i don't think we can change that now, before
> the gcc-6 release).
> 
> so i'd leave the dynlinker name as is, use 64bit ld for now and
> rediscuss the issue when ieee128 long double works in gcc-7

Any idea why IEEE quad support requires bleeding-edge gcc for some
targets when mips64 had it way back in gcc 4.2 or earlier?

Rich

Re: long double on powerpc64

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2016-03-11 10:55:30 -0500]:

> On Fri, Mar 11, 2016 at 02:04:35PM +0100, Szabolcs Nagy wrote:
> > * Justin Cormack <justin@specialbusservice.com> [2016-03-11 11:19:22 +0000]:
> > > On 11 March 2016 at 04:17, Rich Felker <dalias@libc.org> wrote:
> > > > On Thu, Mar 10, 2016 at 09:16:36PM -0600, Bobby Bingham wrote:
> > > >> I've been working on a PPC64 port of musl lately.  I've made some good
> > > >> progress, and it's time to decide what to do about the long double type.
> > > >>
> > > >> The PPC64 ELFv2 ABI [1] calls for a 128 bit long double.  It allows an
> > > >> implementation to choose to use either IEEE quad, or IBM double double,
> > > >> with IEEE quad being preferred.
> > > >>
> > > >> On the compiler side, it looks like things are a bit of a mess.
> > > >>
> > > >> Clang only supports IBM double double on PPC64, AFAICS, and therefore
> > > >> won't work for us currently.
> > > >>
> > > >> GCC support is more complicated.  It supports both 128 bit variants, as
> > > >> well as supporting (and defaulting to) a 64 bit long double.  To get a
> > > >> 128 bit long double, you must build gcc with --with-long-double-128 or
> > > >> pass -mlong-double-128, and even then you get IBM double double.  To get
> > > >> IEEE quad, you must additionally pass -mlong-double-128, though there
> > > >> are whispers that the default may change in gcc 7 [2].
> > > >>
> > > >> The final piece of bad news is that gcc can't successfully build musl on
> > > >> PPC64 with IEEE quad long double.  It chokes on even trivial code using
> > > >> long double complex [3].  So only 64 bit long double is usable for now.
> > > >>
> > > >> The good news is that gcc's predefined macros are sufficient to detect
> > > >> which long double variant is in use.  My current thinking is that we can
> > > >> support both 64 bit long and IEEE quad as two powerpc64 subarchs, even
> > > >> if we can only implement 64 bit for now.  Because it looks like the
> > > >> future direction is for IEEE quad to become the default, I think that
> > > >> should be the suffix-less subarch, and the 64 bit long double subarch
> > > >> should have a -ld64 suffix or similar.
> > > >
> > > > My leaning would be to just go with ld64 if nobody has their act
> > > > together for quad support, but let's see what people who want to use
> > > > powerpc64 think about it. The only option that's not on the table is
> > > > IBM double-double (because it's incompatible with musl's assumption of
> > > > IEEE semantics; math-savvy people in the musl community already know
> > > > this of course but I'm repeating it for the sake of possible
> > > > newcomers).
> > > 
> > > I think it would be a mistake to only support ld64, I think Bobby's approach
> > > of two architectures is probably better, and maybe look to retire ld64
> > > eventually.
> > 
> > if long double is 64bit then the 128bit hw floats cannot be used
> > with musl, because we don't want library support for __float128.
> 
> I don't follow. Are you saying we would not want quad if it requires
> soft float? I think the idea here is that the baseline binaries that

gcc-6 supports a __float128 type on powerpc64
this is hard float with isa 3.0 (power9) and soft-float earlier.

there is discussion to support __float128 in glibc, but i assumed
we would not want it (needs new math library functions for this
type, header changes e.g. tgmath.h etc)

> work on all models would need to use soft float operations for long
> double, but higher -march could use the hardware directly in the
> future (and the soft support should correctly use the fenv from
> hardware). That's the same as the situation for aarch64, no?
> 

aarch64 has 128bit registers architecturally, but no 128bit
arithmetic instructions.

> > note that the glibc position is that for __float128 support the
> > minimum required gcc version has to change to gcc-7 because it is
> > abi and libc needs complex support (which will not be in gcc-6 yet).
> > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02222.html
> > https://sourceware.org/ml/libc-alpha/2016-03/msg00193.html
> 
> Support for __float128 is separate from support for targets where long
> double is IEEE quad, I think. The former is not interesting IMO.
> 

yes.

however whitout __float128 and with 64bit long double musl
cannot use the fancy 128bit hw float instructions
(this was my point above).

> > the problem with -ld64 suffix is that gcc-6 already has hardcoded
> > dynamic linker names (i don't think we can change that now, before
> > the gcc-6 release).
> > 
> > so i'd leave the dynlinker name as is, use 64bit ld for now and
> > rediscuss the issue when ieee128 long double works in gcc-7
> 
> Any idea why IEEE quad support requires bleeding-edge gcc for some
> targets when mips64 had it way back in gcc 4.2 or earlier?
> 

it was not supported on powerpc64, because they used different
long double and untangling that mess is apparently non-trivial.

(they had to introduce new modes
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00229.html
and do lot of changes in gcc/config/rs6000/ to make this
work, powerpc also has decimal float stuff and converting
those to ieee128 does not work yet)

Re: long double on powerpc64

[Bobby Bingham]

On Fri, Mar 11, 2016 at 02:04:35PM +0100, Szabolcs Nagy wrote:
> if long double is 64bit then the 128bit hw floats cannot be used
> with musl, because we don't want library support for __float128.
> 
> note that the glibc position is that for __float128 support the
> minimum required gcc version has to change to gcc-7 because it is
> abi and libc needs complex support (which will not be in gcc-6 yet).
> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02222.html
> https://sourceware.org/ml/libc-alpha/2016-03/msg00193.html
> 
> the problem with -ld64 suffix is that gcc-6 already has hardcoded
> dynamic linker names (i don't think we can change that now, before
> the gcc-6 release).
> 
> so i'd leave the dynlinker name as is, use 64bit ld for now and
> rediscuss the issue when ieee128 long double works in gcc-7

I'd forgotten about GCC needing to know the dynlinker name.  I agree
with your suggestions here.