This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PowerPC IEEE 128-bit floating point: Two 128-bit floating point types

[resending without the long CC list, since the mailing list doesn't like 

On Fri, 30 May 2014, Michael Meissner wrote:

> I assume the way forward is to initially have a __float128 type that gives IEEE
> 128-bit support for those that need/want it, and keep long double to be the
> current format.  When all the bits and pieces are in place, we can think about
> flipping the switch.  However, there we have to think about appropriate times
> for distributions to change over.
> In terms of calling sequence, there are 2 ways to go: Either pass/return the
> IEEE 128-bit value in 2 registers (like long double is now) or treat it like a
> 128-bit vector.  The v2 ELF abi explicitly says that it is treated like a
> vector object, and I would prefer the v1 ELF on big endian server PowerPC's
> also treat it like a vector.  If we are building a compiler for a server
> target, to prevent confusion, I think it should be a requirement that you must
> have -mvsx (or at least -maltivec -mabi=altivec) to use __float128.  Or do I
> need to implement two sets of conversion functions, one if the user builds
> his/her programs with -mcpu=power5 and the other for more recent customers?
> I don't have a handle on the need for IEEE 128-bit floating point in non-server
> platforms.  I assume in these environments, if we need IEEE 128-bit, it will be
> passed as two floating point values.  Do we need this support?

Well, binary128 has all the usual advantages over the existing long double 
for anything wanting something like IEEE semantics; that's not limited to 
server.  I'm not sure why passing in two FPRs would make sense; I'd have 
thought two GPRs would be better for the non-AltiVec case, given that it's 
entirely integer operations that get carried out on the representations of 
these values.

If you have different ABIs for this type depending on AltiVec / 
non-AltiVec, *or* if support for this type depends on AltiVec / 
non-AltiVec, as soon as you have any glibc support for this type (as 
opposed to just supporting __float128 through libquadmath as on x86) 
you've bifurcated the glibc ABI into two incompatible variants: either 
with different calling conventions, or if only one case supports the type 
at all, then one with more symbols than the other.  That is, where 
<> lists "64-bit, 
hard-float, BE", you have two ABIs (and if they vary in whether support 
is present at all, you also need two sets of ABI test baselines in glibc).

Now you can't distinguish them by dynamic linker name (because both are 
compatible with old binaries), and symbol versioning won't reliably stop 
binaries / shared libraries built with one from being used with the other 
(because the same symbol versions will be present, just with different 
contents).  So I think you need something in the ELF header to indicate 
use of this type, and which ABI is being used for it, with corresponding 
binutils changes to prevent static linking of incompatible objects, and 
glibc changes to ensure incompatible objects are rejected for dynamic 

Since glibc's ABI mustn't depend on the compiler version used to build it, 
there are implications for the minimum GCC version that can build any 
glibc version with this support added: glibc must refuse to build with 
older GCC if the result would not provide one of the supported glibc ABIs.  
(If the ABIs are "not supported" and "supported with VSX / AltiVec ABI", 
as opposed to "supported using GPRs/FPRs" and "supported with VSX / 
AltiVec", then the "not supported" case could continue to be built with 
older GCC - but you'd still be increasing the minimum GCC version for LE 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]