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: [PATCH] Add SPECIAL_FLOAT_MODE to enable adding IEEE 128-bit floating point to PowerPC

On Tue, 5 May 2015, Michael Meissner wrote:

> The problem is the PowerPC will have 2 128-bit floating point types, one using
> the IBM double-double format (a pair of doubles to give the user more mantissa
> bits, but no greater exponent range), and IEEE 128-bit floating point.  I don't
> want DFmode to automatically convert to KFmode (IEEE 128-bit floating point),
> but to TFmode (IBM double-double).

But actually it shouldn't automatically convert to either, except maybe 
for very limited cases such as loading constants for a wider mode that can 
be represented in a narrower mode.  It shouldn't automatically convert to 
TFmode because that's non-IEEE and anything done with such an automatic 
conversion is unlikely to have correct semantics for double; it shouldn't 
automatically convert to KFmode because that's a software type and 
converting automatically to it won't be that efficient.

(Cf libgcc2.c's AVOID_FP_TYPE_CONVERSION - where as far as I can tell, 
removing the __powerpc__ special case would achieve the semantics I 

What in the compiler is actually doing such conversions automatically, and 
what simply needs to iterate over all the types?  I think we need a better 
understanding of each place that's affected by these changes to work out 
what's actually correct.  If something adds conversions from DFmode to 
non-IEEE TFmode at present, where the original program did not contain 
such conversions, that's a bug in the existing code (except for very 
limited cases such as constants), even in the absence of KFmode.

(If something is about e.g. eliminating a widening followed by a narrowing 
- never implicitly adding a widening but possibly removing one - then that 
would be correct for either (DFmode, TFmode) or (DFmode, KFmode).  But 
you'd still have the issue that neither TFmode nor KFmode is a widening of 
the other - each can represent values the other cannot.)

If "wider" means "can represent all values of the other mode", both TFmode 
and KFmode are wider than DFmode.  If it means "is suitable to use as an 
intermediate mode for operations involving the other mode" (the libgcc 
case), neither is wider than DFmode.  If it means "can efficiently load 
constants of the other mode", TFmode is wider than DFmode but KFmode may 
not be.  In any case, neither of TFmode and KFmode is wider than the 
other.  Unless all the code uses a single one of these meanings, you need 
to distinguish which meaning is used in each place in the code.

Joseph S. Myers

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