[resending without the long CC list, since the mailing list doesn't like it]
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 <https://sourceware.org/glibc/wiki/ABIList#powerpc> 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 linking. 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 builds.) -- Joseph S. Myers jos...@codesourcery.com
