This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PowerPC IEEE 128-bit floating point: Internal GCC types

Currently within the GCC rs6000 backend, the type TFmode is the default 128-bit
floating point type.  Depending on TARGET_IEEEQUAD (the internal name for the
-mabi=ieeelongdouble option), this gets mapped into either the IEEE 128-bit
format or the IBM extended double format.  In theory, any place that checks for
TFmode should also check for TARGET_IEEEQUAD to determine which type of
floating point format is used.  Most places do do the check, but I have to
assume that a few places might not do it properly.

One question for GCC folk is did we want to simplify this, and make TFmode
always be IEEE 128-bit, and add another floating type for the IBM extended
double format.  This will involve fixing up both the compiler and libgcc.  I
tried to do this in one set of changes, and the compiler itself was fairly
straight forward.  However, it broke libgcc, due to the use of the mode
attribute to get to TFmode instead of using long double.  While this too can be
fixed (as well as uses in glibc), I wonder users in general use the mode
attribute declaration and explicitly use TFmode, and assuming they will get the
IBM extended double support.  For now, I think it is better to not change
TFmode, and just invent a new mode for IEEE 128-bit support.

I've looked at code that add two new modes, such as JFmode for explicitly IBM
extended double and KFmode mode for the IEEE 128-bit support, and TFmode would
be the same as either JFmode or KFmode.  These changes were getting a little
complex, so I've also looked at using a single mode for IEEE 128-bit (JFmode),
and leaving most of the TFmode support alone.

Do people have a preference for names?  I think using XFmode may cause
confusion with x86

One issue is the current mode setup is when you create new floating point
types, the widening system kicks in and the compiler will generate all sorts of
widening from one 128-bit floating point format to another (because internally
the precision for IBM extended double is less than the precision of IEEE
128-bit, due to the size of the mantisas).  Ideally we need a different way to
create an alternate floating point mode than FRACITION_FLOAT_MODE that does no
automatic widening.  If there is a way under the current system, I am not aware
of it.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]