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 expect.) 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 jos...@codesourcery.com
