* long double on powerpc64 @ 2016-03-11 3:16 Bobby Bingham 2016-03-11 4:17 ` Rich Felker 0 siblings, 1 reply; 7+ messages in thread From: Bobby Bingham @ 2016-03-11 3:16 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: long double on powerpc64 2016-03-11 3:16 long double on powerpc64 Bobby Bingham @ 2016-03-11 4:17 ` Rich Felker 2016-03-11 11:19 ` Justin Cormack 0 siblings, 1 reply; 7+ messages in thread From: Rich Felker @ 2016-03-11 4:17 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: long double on powerpc64 2016-03-11 4:17 ` Rich Felker @ 2016-03-11 11:19 ` Justin Cormack 2016-03-11 13:04 ` Szabolcs Nagy 0 siblings, 1 reply; 7+ messages in thread From: Justin Cormack @ 2016-03-11 11:19 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: long double on powerpc64 2016-03-11 11:19 ` Justin Cormack @ 2016-03-11 13:04 ` Szabolcs Nagy 2016-03-11 15:55 ` Rich Felker 2016-03-14 20:13 ` Bobby Bingham 0 siblings, 2 replies; 7+ messages in thread From: Szabolcs Nagy @ 2016-03-11 13:04 UTC (permalink / raw) To: musl * 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: long double on powerpc64 2016-03-11 13:04 ` Szabolcs Nagy @ 2016-03-11 15:55 ` Rich Felker 2016-03-11 16:38 ` Szabolcs Nagy 2016-03-14 20:13 ` Bobby Bingham 1 sibling, 1 reply; 7+ messages in thread From: Rich Felker @ 2016-03-11 15:55 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: long double on powerpc64 2016-03-11 15:55 ` Rich Felker @ 2016-03-11 16:38 ` Szabolcs Nagy 0 siblings, 0 replies; 7+ messages in thread From: Szabolcs Nagy @ 2016-03-11 16:38 UTC (permalink / raw) To: musl * 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) ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: long double on powerpc64 2016-03-11 13:04 ` Szabolcs Nagy 2016-03-11 15:55 ` Rich Felker @ 2016-03-14 20:13 ` Bobby Bingham 1 sibling, 0 replies; 7+ messages in thread From: Bobby Bingham @ 2016-03-14 20:13 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-03-14 20:13 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-03-11 3:16 long double on powerpc64 Bobby Bingham 2016-03-11 4:17 ` Rich Felker 2016-03-11 11:19 ` Justin Cormack 2016-03-11 13:04 ` Szabolcs Nagy 2016-03-11 15:55 ` Rich Felker 2016-03-11 16:38 ` Szabolcs Nagy 2016-03-14 20:13 ` Bobby Bingham
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).