Re: RFC Migrating PowerPC to IEEE 128-bit Floating Point

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

On Wed, 2015-09-30 at 21:15 +0000, Joseph Myers wrote: 
> [Jakub, see question below about your long double compatibility changes 
> from 2004-6.]
> 
> On Wed, 30 Sep 2015, Steven Munroe wrote:
> 
> > We have made good progress on this as documented here:
> > https://gcc.gnu.org/wiki/Ieee128PowerPC
> 
> I note there you refer to doing comparisons with a function __cmpkf2.  I 
> think you need at least two comparison functions (analogous to the fcmpu 
> and fcmpo instructions), that differ on whether they raise the "invalid" 
> exception for quiet NaN operands.  (LT GT LE GE RTL operations would use 
> the version that raises "invalid", other comparisons would use the version 
> that doesn't, with some ambiguity for LTGT as discussed in the thread 
> starting at 
> <https://gcc.gnu.org/ml/gcc-patches/2015-02/threads.html#00555>.  It's 
> true that the powerpc port doesn't get this right for hardware comparisons 
> at present, <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684>, but it 
> would seem a bad idea to leave the interface to the libgcc function 
> ambiguous.)
> 
We agree to add ordered and unordered form of compare for soft-float.

> > 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.
> 
> There are a couple of relevant glibc principles here:
> 
> * It's not just "for some time", unless you have a complete ABI 
> discontinuity (creating a new port with new symbol versions for everything 
> so the two ports can't load any of the same executables or shared 
> libraries) old glibc symbols need to stay supported.  

Understood. We will need to maintain all three [1) long double ==
double, 2) long double == IBM long double, 3) long double == __float128]
until there is a new (not backward compatible) ABI. 

> It's certainly 
> possible to replace an old port for an architecture with a new 
> incompatible ABI - ARM old-ABI was replaced by ARM EABI, with an overlap 
> of a few years where both ports were supported before old-ABI support 
> bit-rotted and then was removed.  But I don't know if that's practical for 
> powerpc64 LE (and the other ABIs are widely used on non-VSX systems).
> 
> * The ABI exported by each glibc shared library must not depend on the GCC 
> version used to compile glibc.  That is, for glibc to export __float128 
> functions, the minimum GCC version for compiling glibc on the platform in 
> question must be recent enough to support __float128.  Now, the backport 
> to older GCC suggested under item 8.2 might help there (but might be 
> otherwise risky).  But I tried and failed to obtain consensus simply to 
> increase the minimum GCC version for building glibc 2.23 from 4.6 to 4.7; 
> a 4.9 requirement, let alone a requirement for GCC 6, would seem likely to 
> be controversial for some time (although users of at least some powerpc 
> variants might be less concerned by such a version requirement; the 
> version required doesn't need to be the same on all architectures).
> 
> For reference, there are four current ABIs for powerpc glibc as listed at 
> <https://sourceware.org/glibc/wiki/ABIList#powerpc>.  I presume you are 
> not proposing to increase that number (unless you do plan a complete ABI 
> discontinuity) but to add some symbols to one or more of those existing 
> ABIs.
> 
The are not plans at this time and to the best of my knowledge.

> (It's fine for some functions to require particular instruction set 
> extensions, e.g. for the ABI for the __float128 entry points to be that 
> they require VSX support.  This is not of course an issue for 
> little-endian where VSX support is required anyway, only for big-endian if 
> any __float128 support is added there.  The build system would need to 
> ensure the right options are passed when building __float128 files, 
> without adding inappropriate VSX requirements when building other files.)
> 
Technically only VMX support is required for parameter passing which
includes PowerMAC G5/970, Freescale e6500, IBM POWER6 and later.

As you say the PPC64LE will have VMX/VSX by definition.

Modern PPC32BE and PPC64BE Hard-float systems support VMX/VSX ans can
migrate to __float128 as this work is completed.

Older POWER servers (power4 power5 power5+) without VMX/VSX are or are
going out of service and are not supported by current distros, and so
will not be compiling for or using __float128. We will maintain
versioned IBM long double (which only requires hard float) to support
existing application migrated to newer systems and distros.

The PPC32 Soft-float ABI would continue to pass by reference and could
migrate to __float128 if they choose.

> > 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.
> 
> I think any of 3.2/3.3/3.4 (handling the architecture-specific variation 
> in the mode name in some architecture-specific way) would seem reasonable.  
> 3.3 and 3.4 are probably preferable to 3.2 to avoid needing large numbers 
> of architecture-specific files checked in.
> 
> > 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.
> 
> I think it will be substantially more complex, as you're building a 
> library supporting four different types (and need to run all relevant 
> tests for both long double variants), which hasn't been supported at all 
> in glibc before.  Although the very rough outline design is clear in some 
> areas (e.g. follow TS 18661-4 for naming of functions explicitly using 
> __float128, so e.g. sinf128, and avoid adding e.g. additional printf 
> modifiers for explicit __float128 because TS 18661-4 chose a different 
> approach there), there's a substantial amount of work to develop a 
> detailed design for what the interfaces and implementation should look 
> like, and to obtain consensus on it, and a substantial amount more to 
> implement it.
> 
> 
This is complicated. I thank Uli Weigand for developing this break-down of long double usage.

Looking at what various targets use today, it seems that all platforms supported by glibc use IEEE float and double.   As to long double, the following options are in use:
(A) "long double" is 80-bit IEEE extended (no variants): i386, x86_64, ia64, m68k -- sysdeps directories: ieee754/ldbl-96
(B) "long double" is 128-bit IEEE quad (no variants): aarch64, mips64, sparc64 -- sysdeps directories: ieee754/ldbl-128
(C) "long double" is 128-bit IEEE quad (with "long double == double" variant): alpha, sparc32, s390* -- sysdeps directories: ieee754/ldbl-128, ieee754/ldbl-64-128, ieee754/ldbl-opt
(D) "long double" is IBM double-double (with "long double == double" variant): powerpc* -- sysdeps directories: ieee754/ldbl-128ibm, ieee754/ldbl-opt
(E) "long double" is double (no variants): all other platforms -- sysdeps directories: none

Dealing with one platform and ABI using ldbl-128ibm will be challenging.

But ldbl-128 supports 6? platforms directly or indirectly. So we need the think carefully, as we add __float128 support to this mix. This is complicated by requiring both function symbol and type changes.

I suggest we start by creating a new source directory (./ieee574/ldbl-f128) specifically for introducing __float128 support. This allows us to begin work without impacting to the existing platforms.

Initially this can be source/macro stubs that overlay the existing ldbl-128 implementations and modifying the function names and parameter types..

In parallel we can begin the work of preparing ldbl-128ibm to move out of the ieee-*l name space and prepare for the release where they will become of the old version of long double for the power platform.

Finally once the ldbl-f128 target is fully implemented and tested, interested platforms can migrate to ldbl-f128 or decide to merge ldbl-128 and ldbl-f128 in to a single implementation supporting both names/types.

> 
> I'd be wary of trusting that the set of functions with existing support 
> for variable long double types is in fact the complete set that need 
> fixing for such a change.  In particular, as far as I can see, none of 
> that compatibility support is present for printf-like functions in argp.h, 
> err.h and error.h.  Unless there's some reason I'm missing why no 
> compatibility support was needed for those functions in the original 
> 2004-6 changes (Jakub?), there's an ABI bug there that we can't now do 
> anything about for the original transition (because old and new binaries 
> use the same symbol versions for those functions, with old binaries 
> expecting long double = double and new binaries expecting distinct long 
> double), but that we can avoid for a future transition.  I don't know if 
> any other affected functions are missing such compatibility support.
> 
Ok we will investigate this. I don't seeing what the issues are with argp.h and err.h but looks like the error() and error_at_line() format strings could be a problem.
> 
> 
> On point 5.2 (uses of long double in double functions): the correct fix is 
> to remove that use, along with the multiple-precision code that can make 
> the functions very slow, after doing sufficient error analysis of the 
> initial code in the functions to verify that by itself it yields results 
> with better than 1ulp accuracy, and so well within glibc's accuracy goals.  
> That will mean that long double performance has no effect on performance 
> of double libm functions.

I only found one example of this (./sysdeps/ieee754/dbl-64/slowpow.c) and that usage was wrapped in a conditional (#ifdef USE_LONG_DOUBLE_FOR_MP).

We will lokk at this.

> 
> 
> On point 8.1, I don't think fma should be added to libgcc.  If you want to 
> use the soft-fp version in glibc instead of the default ldbl-128 version, 
> that's easy to do (and should be much faster).
> 
We will handle this as we work the port.
> 
> Note that much of the glibc work could be done in the context of 
> supporting explicit __float128 functions for x86_64 - all GCC versions 
> supported for building glibc already support __float128, and differences 
> between __float128 and TS 18661-4 _Float128 should be easy to work around 
> when building with older GCC even if proper GCC _Float128 support would be 
> a preferred stating point (it allows you e.g. to write _Complex _Float128, 
> which isn't possible with __float128).  That wouldn't include anything 
> related to changing the type of long double, and would still have a large 
> amount of work on design, obtaining consensus and implementation, but 
> would allow a large proportion of the work to go in even before the 
> minimum GCC version for building powerpc glibc is increased and so 
> __float128 support can be added for powerpc glibc.
> 
A I suggested about, creating ./ieee754/ldbl-f128 would be the simplest
and safest way to start this effort.

Yes we will have to address _Float128 but we have to include dealing
with the existing __float128 support as part of the solution.

This is a complex dance that has to be choreographed. Everyone is
invited to participate.