Fortran and real*16 on PowerPC and moving to IEE 128-bit

[Janne Blomqvist]

On Fri, Oct 26, 2018 at 12:25 AM Michael Meissner <meissner@linux.ibm.com>
wrote:

> So with the GLIBC work progressing, it is time to start thinking about how
> we
> can move fortran's real*16 to use the IEEE 128-bit type.
>
> There are two basic methods that I know about:
>
>     1)  Wait for a distro to move, and fortran (in theory) should pick up
> all
>         of the changes for free, but that can take awhile;
>

So does this mean that distros are going to have a flag day where they drop
the old double-double format and switch to ieee? So we don't need to
consider a situation where a system supports both?


>     2)  Add support within fortran to change the name used for real*16
> support
>         functions, and provide both functions in the library (this is what
> C++
>         is doing).
>

.. and this means that we'd support both via, say, a compile-time switch,
and thus the libgfortran must support both? In this case, glibc also
provides both ABIs?


> I just recently put in a patch to the rs6000 backend that switches the
> names of
> the math built-in functions if the compiler was configured for IBM extended
> double and the user asked for IEEE 128-bit floating point, and this will
> work
> for fortran also.


Looking at the cauldron videos, there was discussion about (some?) of the
glibc IEEE f128 support being done via header magic, which would be a
problem for GFortran which calls the functions directly without parsing the
headers. So does this above patch address this issue?


> We talked about me providing a patch to switch the libquad math functions
> to
> the GLIBC f128 functions, and after I implemented it, I realized that we
> never
> call the libquad math functions in PowerPC, because of IBM extended double
> (and
> there can only be one float type of a given size, which has made implement
> the
> IEEE 128-bit support so much 'fun').
>
> If we did call libquadmath, it would have been useful to switch to GLIBC's
> f128
> math functions, since these functions are being heavily optimized.


IIRC there was some discussion here on the lists about the future of
libquadmath, now that glibc has implemented f128 support for x86.  The
problem is that we still need libquadmath for non-glibc targets, and it
remains to be seen whether glibc improvements will propagate back to
quadmath.  And also, on targets with new enough glibc, should Fortran
switch to calling the glibc functions directly, or should the libquadmath
compilation be changed to just provide aliases for the glibc functions if
available, etc.

Ugh, but anyway, that's not per se related to ppc64le.


> We (IBM) are in the process of setting up a power9 system in the compile
> farm,
> so if people wanted to start actually trying things out, they will be able
> to.
>

Good. Those Talos things seem nice and almost-decent priced, but still a
tad expensive for a hobbyist just to improve f128 support.

I wanted to start a dialog on what we see as the next steps, and how willing
> was Fortran going to be to support users that want/need to use the IEEE
> 128-bit
> type, and are willing to act as guinea pigs as we modify the libraries to
> support the switching (before a distro changes the defaults).
>

I don't think anyone would be particularly sorry to see double-double
replaced with IEEE f128, but as you mention, it's a question of time and
priorities.


> At this point, I don't know the scope of the work, and whether it is fairly
> simple and might be able to be slipped into GCC 9 or if it is more complex
> and
> needs to wait until GCC 10.
>

Indeed. I'd like to help, but my time is unfortunately quite limited, and I
don't yet know what's needed.


-- 
Janne Blomqvist