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

[Michael Meissner]

(note, I did not include all of the Fortran maintainers on the initial To list,
but feel free to speak up as well).

Thomas, as we talked about at the Cauldron, the Power9 processors now have
direct support for IEEE 128-bit floating point. However, we already have a
long double/real*16 type on PowerPC (IBM extended double, which is a pair of
doubles), and it has been a long struggle to get the base compiler and GLIBC to
support switching the C language. At the moment, the compiler middle/back end,
C/C++ front ends are mostly done, and GLIBC is being worked on.

Jonathan Wakely and others are now working on making the libstdc++ libraries
able to support either long double type, using different function names via
name mangling for the two types.

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;

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

I realize that presumably like every other project, you have more work to do
than you have bodies doing the work, and it is a matter of setting the
priorities.

As we discussed, while the majority of the codes are probably real*4 or real*8,
there some codes that want/need to use higher precision (real*10 on Intel/AMD,
real*16 on PowerPC). I don't have a handle on how big the propulation is that
wants to use higher precision values on PowerPC systems.

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. But as I was looking at the compiler and library, I realized
there is a lot of code for the library support functions, and these need to be
addressed as well.

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. In
addition, if you use recent Advance Toolchain releases, AT will load up a
shared library compiled specifically for power9, which generates the native
instructions instead of calling through a PLT to get either software emulation
or the hardware instruction.

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.

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

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.

[Thomas Koenig]

Michael,

Post by Michael Meissner
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;
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).

The second method is doable, but touches quite a few places in the library.

One part is the generated functions (do a "ls *r16* *c16*") in
libgfortran/generated. In principle, these could be handled by a method
similar to matmulavx128 - generate different source files from m4 files
and then compile with different options.

The other part is I/O. I think libgfortran/io/write_float.def is
modular enough that you could add another float128 type there, and
of course you would also have to adapt read.c there.

On idea: Would it be possible to simply not rename the functions at all,
but rather add a new library which contains the functions in question,
and select those on linking?

Post by Michael Meissner
As we discussed, while the majority of the codes are probably real*4 or real*8,
there some codes that want/need to use higher precision (real*10 on Intel/AMD,
real*16 on PowerPC). I don't have a handle on how big the propulation is that
wants to use higher precision values on PowerPC systems.

Neither do I.

I think that not many people are using the old Intel format any more -
64 bit
architectures have taken care of that, but I could easily be wrong.

People who use 16-byte reals on Intel or AMD certainly need the
precision vs. speed - libquadmath does the job, but it it really
slow.

However, I do have one concern with this switch, and that is unformatted
data. People who save their files in the old format will find that,
upon reading, their data will be wildly different - because of the
different layout, certainly big enough to notice.

If course, people (if any) exchanging binary data between POWER8 and
Intel/AMD will already have that problem.

An automatic conversion program is impossible to write, because it will
not know the type of variable - it's just random bits of data.

What could work better is to add something to the non-standard CONVERT
specifyer on the OPEN statement, so that, for example, reading could
be done in the old format and writing in the newer one, something like
OPEN=(...,CONVERT="NATIVE+OLDFLOAT").

Post by Michael Meissner
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.

That would, of course, help.

Post by Michael Meissner
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 guess I could help a bit with testing, as long as it can be done
on Linux, and with general hints of where to look if you don't find
certain things. I won't be able to put many man-hours into this,
though.

Post by Michael Meissner
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.

I think the best way is to start working on it and to see when it is
ready. Maybe the best way would be to create a branch. The area we
are looking at is fairly static, so I would not assume many problems
merging back the changes.

Regards

Thomas

[Janne Blomqvist]

Post by Michael Meissner
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.
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?

Post by Michael Meissner
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?

Post by Michael Meissner
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?

Post by Michael Meissner
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.

Post by Michael Meissner
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

Post by Michael Meissner
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.

Post by Michael Meissner
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.

[Segher Boessenkool]

Hi Janne,

Post by Janne Blomqvist

Post by Michael Meissner
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.
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?

At some point the default long double type will change to ieee128. For
some things that is enough, and a distro that rebuilds everything will of
course "automatically" have matching libraries and binaries. But this
is not enough for some other things (what about "external" binaries and
libraries, what about external data (in files etc.)?)

Post by Janne Blomqvist

Post by Michael Meissner
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?

There is only one ABI. But yes, glibc supports both IBM extended double
("ibm128") as well as IEEE quad precision float ("ieee128").


Segher

[Bill Schmidt]

Post by Michael Meissner
 
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.

gcc135 is available. Announcement here: https://cfarm.tetaneutral.net/news/18#

Bill

[Michael Meissner]

Note, generally I assume disclaimers, but just to be clear, in this context I
am speaking with my own opinion, and not an official opinion of IBM or any
other entity like a distribution. While I work with the GLIBC folk, I also
can't speak for what they are doing.

I wanted to open up a dialog so that we can think of allowing people that need
IEEE 128-bit code can use it before a full fledged distro that has everything
by default is shipped.

Post by Janne Blomqvist

Post by Michael Meissner
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.
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?

This is up to the distros, but for the three main distros (Red Hat, Suse,
Ubuntu), I believe they do not want to go back a multilib approach where 2 or
more sets of libraries are delivered.

So either there will be a flag day (generally with a major version switch)
where the default is changed, or it will never change.

I believe GLIBC and Libstdc++ are both working adding compatibility layers so
that old code will continue to link when the default is switched. And once the
GLIBC changes are done, users will be able to compile new code with the
appropriate option (-mabi=ieeelongdouble or -mabi=ibmlongdouble) to control the
format of long double/real*16.

Post by Janne Blomqvist

Post by Michael Meissner
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?

Work is underway for GLIBC. However, this all depends on the C/C++ user using
the standard header files (math.h, stdio.h, etc.). But fortran doesn't use the
C math.h, so it will be some amount of support that will be needed.

Post by Janne Blomqvist

Post by Michael Meissner
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?

Post by Michael Meissner
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.

Yep.