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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Michael Meissner-7
(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.

--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: [hidden email], phone: +1 (978) 899-4797

Reply | Threaded
Open this post in threaded view
|

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

Thomas Koenig-6
Michael,

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

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?


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

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

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

> 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
Reply | Threaded
Open this post in threaded view
|

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

Janne Blomqvist-3
In reply to this post by Michael Meissner-7
On Fri, Oct 26, 2018 at 12:25 AM Michael Meissner <[hidden email]>
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
Reply | Threaded
Open this post in threaded view
|

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

Segher Boessenkool
Hi Janne,

On Sat, Oct 27, 2018 at 10:52:26PM +0300, Janne Blomqvist wrote:

> On Fri, Oct 26, 2018 at 12:25 AM Michael Meissner <[hidden email]>
> 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?

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

> >     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
Reply | Threaded
Open this post in threaded view
|

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

Bill Schmidt-3
In reply to this post by Janne Blomqvist-3
On 10/27/18 2:52 PM, Janne Blomqvist wrote:

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


Reply | Threaded
Open this post in threaded view
|

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

Michael Meissner-7
In reply to this post by Janne Blomqvist-3
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.

On Sat, Oct 27, 2018 at 10:52:26PM +0300, Janne Blomqvist wrote:

> On Fri, Oct 26, 2018 at 12:25 AM Michael Meissner <[hidden email]>
> 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?

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.

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

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

Yep.

--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: [hidden email], phone: +1 (978) 899-4797