Re: [PATCH], Add optional IEEE/IBM long double multilib support

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Fri, Jan 05, 2018 at 05:28:03PM +0000, Joseph Myers wrote:
> On Thu, 4 Jan 2018, Michael Meissner wrote:
> 
> > 	(CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> > 	accomidate -mabi=ieeelongdouble multilibs.
> 
> Why is that correct in the -mabi=ibmlongdouble case?

The PowerPC TFmode has always been 'special'.  It would mirror the 128-bit long
double format.  For the one port that actually used IEEE 128-bit floating
point, TFmode was IEEE.  For the the majority of ports TFmode is IBM extended
double.

So when I began this journey to add IEEE 128-bit support, I had to fit it into
this framework.

If long double is IBM extended double:
	TFmode is IBM extended double scalar
	TCmode is IBM extended double complex
	KFmode is IEEE scalar
	KCmode is IEEE complex
	IFmode is not used
	ICmode is not used

If long double is IEEE 128-bit (i.e. -mabi=ieeelongdouble):
	TFmode is IEEE scalar
	TCmode is IEEE complex
	KFmode is not used
	KCmode is not used
	IFmode is IBM extended double scalar
	ICmode is IBM extended double complex

We are just starting to look at the implications of switching the long double
type from IBM extended to IEEE.

While I would hope that eventualy GLIBC can do something with versioning so
that we avoid having to do multilibs, I suspect during initial development, we
will need multilibs just to get things right.  Then perhaps GLIBC can do
something like the original support for -mlong-double-64 and -mlong-double-128
went in.  However, since I don't work on GLIBC, I don't know how hard it is.  I
figured we would need multilibs as a crutch during initial development.

> As I understand it, TFtype is always of mode TFmode (it would certainly be 
> confusing if it sometimes had a different mode), but TFmode's format 
> depends on the selected ABI.  Where this code uses __float128, it requires 
> something that is always of IEEE binary128 format.  In the 
> -mabi=ieeelongdouble case, that's indeed TFtype, but not in the 
> -mabi=ibmlongdouble case when TFmode has ibm128 format.
> 
> In C code, _Float128 and _Complex _Float128 should always be available 
> when the binary128 format is supported, so I think the code needing that 
> format can safely use those.

Yes, in C code _Float128 _Comples works.  The trouble is compiling
libstdc++-v3.  In C++, we don't have _Float128, and __float128 _Complex does
not work for either x86 or PowerPC.  So on PowerPC the code from bits/floatn.h
is:


/* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1.  */
#if __HAVE_FLOAT128
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
/* Add a typedef for older GCC compilers which don't natively support
   _Complex _Float128.  */
typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
#  define __CFLOAT128 __cfloat128
# else
#  define __CFLOAT128 _Complex _Float128
# endif
#endif

Obviously, in a future release of GLIBC (via AT 11.0-3) we will fix that, but
it made the job of doing the initial port eaiser.

The problem is we need to get stuff into GCC so that GLIBC can start to add the
appropriate changes.


> > 	(__mulkc3): Use TFmode/TCmode for float128 scalar/complex types.
> > 	(__divkc3): Use TFmode/TCmode for float128 scalar/complex types.
> > 	* config/rs6000/extendkftf2-sw.c (__extendkftf2_sw): Likewise.
> > 	* config/rs6000/trunctfkf2-sw.c (__trunctfkf2_sw): Likewise.
> 
> And likewise here.
> 
> (My understanding is that each of the libgcc functions is meant to have a 
> particular ABI that does not depend on the format of long double - so the 
> "tf" and "tc" functions refer to ibm128 format, unconditionally, and the 
> "kf" and "kc" ones to binary128 format, unconditionally.  I have not 
> checked whether the libfuncs handling in init_float128_ibm and 
> init_float128_ieee is sufficient to achieve this in all cases.  In 
> particular, does complex arithmetic always use the correct one of "kc" and 
> "tc" depending on the long double format?  What about __builtin_powil - 
> does that properly use __powitf2 and __powikf2 as appropriate, or do you 
> have the ABI of __powitf2 depending on the multilib?)

Libgcc does not need to be multilibed.  It uses separate functions.  What does
currently need to be multilibed is libstdc++-v3 and possibly GLIBC.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797