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

[Joseph Myers <joseph at codesourcery dot com>]

[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.)

> 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.  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.

(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.)

> 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.

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.

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.

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).

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.

-- 
Joseph S. Myers
joseph@codesourcery.com