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: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
