Currently attempting a 64-bit long double transition to get rid of the messy IBM double-double format used on most distros and unify the representation across targets. Musl has been using it all along, now trying glibc.
I don't want to go with the 128-bit IEEE754 format as that requires VSX and would mean a different one on ppc64le and the rest (and also, when not targeting POWER9, it means basically reverting to soft-float).
What kind of performance loss are we looking at though on POWER9 vs. 128-bit IEEE754?
If you mean performance loss with 64-bit ldbl vs 128-bit IEEE754, 64-bit should be faster, because Void is compiled for POWER8 like other distros and therefore can't use POWER9 isns (other than in glibc math functions, which can be chosen at runtime). The actual difference, don't know, I haven't benchmarked it (and won't, as that would mean compiling a set of packages for that).
I kind of don't want to use the 128-bit stuff for long double type in principle, as the hard VSX requirement is there either way (gcc will not compile it without -mcpu set to at least power7) and I'd kind of like the little endian and big endian targets differ mostly in just endianness and baseline -mcpu setting.
I never liked the long double type anyway, as the guarantees you get with it are zero (it's only required to be at least as big/precise as double and that's it). So going with a 64-bit baseline that's covered well in hardware everywhere seems like the sane choice (plus musl won't be adopting 128bit IEEE754 as it would require introduction of a new subarch because musl doesn't version symbols - so that would make glibc little endian the *only* outlier).
People who want 128-bit IEEE754 floating point can easily use the __float128 type in gcc. That is a much better option as it has guaranteed properties (similarly, it works on modern x86 with at least 128-bit wide SIMD as well). People who want the IBM 128bit floating point can also use the __ibm128 type in gcc in a similar manner.
Adopting 64-bit long double in glibc is actually pretty easy right now - because it used to use it in the past (before IBM made them change the default to the silly 128-bit double-double). Therefore, all the compatibility symbols as well as redirects for when you use -mlong-double-64 are set up in glibc, and all it takes is recompiling libraries and programs that use 128-bit IBM long double. You can easily tell which do - they will be tagged like
Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double in the ELF attributes. This tag is only introduced when long doubles are used in the binary and it was compiled with those set to 128-bit IBM format.
So, I just went and checked every package containing ELF files for the tag, and compiled a list. It's a relatively small number, only about 330 packages out of 8000+. The rest of them can be left alone.