RFC Migrating PowerPC to IEEE 128-bit Floating Point

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

Several of you have expressed concern with the limits of the current IBM
long double format and have asked when the PowerPC platform could make
the transition to IEEE 128 standard format and rounding support.

At first we were reluctant to give up the hardware advantage of the
double double implementation. But with progress in VSX architecture in
P8 and future processors, I think we can address IEEE 128-bit with
reasonable performance.

But first we need to start with a soft-fp implementation as the first
step to enable GCC for __float128 (IEEE 128-bit format) and then address
VSX optimization as a parallel effort.

We have made good progress on this as documented here:
https://gcc.gnu.org/wiki/Ieee128PowerPC

As the next steps we need to address updates to the master soft-fp
project and then how to migrate GLIBC (libm and printf/scanf)) long
double from IBM long double to __float128.

Of course we need to continue support of existing applications that
currently use IBM long double while we enable __float128. And we will
need to maintain backward compatibility (via versioned symbols) for some
time.

This will require some management of the symbol set in  soft-fp and
eventually symbol versioning of long double functions in libm to allow
existing IBM long double and  new __float128 applications to coexist.

The first issue of the symbol naming for soft-fp implementation for
__float128 for PowerPC64. IBM long double currently used TFmode and the
runtime functions use the "tf" suffix (__floatditf for example).

For the powerpc64 target in GCC we planning to add __float128 as KFmode
and implies use the "kf" suffix in the runtime (__floatdikf for
example). This leaves the current long double runtime functions in place
while we introduce the __float128. This implies come macro and build
trickery to allow soft-fp builds for both TFmode and KFmode to coexist. 

Mike offers some suggestions in his Wiki above (section 3). We would
appreciate feed back on what you would prefer.

It would be good to resolve any such logistics in the soft-fp master
source in time for GCC stage 3.

Then we can engage the GLIBC community on staging and migration of long
double support within libm and libc. I suspect this will of the same
complexity as the original migration from long double == double and will
take while to resolve.

Thanks