Re: [PATCH], Add IEEE 128-bit floating point to PowerPC, patch #1

[Michael Meissner <meissner@linux.vnet.ibm.com>]

On Tue, Jun 02, 2015 at 08:14:12PM +0000, Joseph Myers wrote:
> On Tue, 2 Jun 2015, Michael Meissner wrote:
> 
> > On Tue, Jun 02, 2015 at 05:55:10PM +0000, Joseph Myers wrote:
> > > Is the use of FRACTIONAL_FLOAT_MODE to avoid iterations over 
> > > floating-point modes including these modes when they shouldn't, as 
> > > discussed previously?
> > > 
> > > If so, how do you deal (in subsequent patches?) with iterations that 
> > > *should* include these modes?  In particular, where libgcc uses 
> > > __LIBGCC_<mode>_* macros predefined with -fbuilding-libgcc in an 
> > > interation in c-cppbuiltin.c, how do you handle getting the relevant 
> > > information in libgcc to build applicable libgcc functions for these 
> > > modes?  (I'm presuming that you do want complex arithmetic to work for 
> > > both 128-bit types, for example, although you won't want them to be used 
> > > for intermediate conversions in libgcc operations on other types.)
> > 
> > I have a catch-22 situation.  We can't really do the glibc stuff until we have
> > the compiler.  Right now, I use a makefile on libgcc/config/rs6000 that copies
> > the various TF files and modifies it for KF files.
> 
> The functions I'm mainly thinking of are the libgcc2.c ones rather than 
> the soft-fp ones (powi?f2 mul?c3 div?c3).

Ok, I will look into those.

> > After we get the basic support in, we can then start tackling glibc.  It may be
> > when we get to doing the work in glibc itself, we will need to make further
> > modifications.  However, in order for the glibc people to start, I need the
> > basic support in the compiler in the tree.
> 
> It's not obvious what glibc support should look like in the absence of a 
> change to the default for long double; that would require discussion on 
> libc-alpha at an early stage to establish a consensus on the design.
> 
> libquadmath support should be easy (given working compiler / libgcc 
> support).  But if you want more than libquadmath support, there are 
> several possible forms for support in glibc proper depending on e.g. 
> whether you want to support a -m option to change long double, or using 
> the functions via the __float128 type name and separate names for the 
> functions, or both.

There already is an option to change long double, but it currently does not
work (and in fact is disabled in 64-bit environments).

I see there are many roadblocks to changing the type of long double
(i.e. making sure printf %Lg works correctly, etc.).  None of the distros want
another multilib (where long double is IEEE 128-bit).  For the scope of GCC
6.0, my assumption is long double will remain IBM extended double.

My assumption of the steps are:

1) Get the basic compiler support in.

2) Add the basic soft-float, either with my current hack or preferrably doing
   it right in glibc (I suspect we may want to temporarily do it via the hack,
   and when the glibc support is in, remove the hack).

3) Deal with all of the complexities of libgcc2 and glibc for the additional
   type.

4) Add float128 versions of the basic math libraries.  For this it will
   probably be simpler if we can force long double to be IEEE 128-bit so you
   don't have to change as much code, but you want to suppress whatever check
   there will be to prevent user code from linking against the wrong library.

5) Add support in other libraries as needed (IBM's MASS library, the new vector
   library, libquadmath, etc.).

Note, by the time of GCC 7.0, the C17/C++-17 standards may be final, and there
they have new names for IEEE 128-bit, etc.

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