On Wed, May 06, 2015 at 03:27:48PM +0000, Joseph Myers wrote:
> 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.
I was curious, and instrumented GET_MODE_WIDENING_MODE for FP (both scalar and
vector) types, and found it was called in the following spots compiling normal
code that is vectorizable (not IEEE 128-bit):
expr.c:03690 DF
expr.c:03690 SF
compress_float_constant
optabs.c:00353 TF
find_widening_optab_handler_and_mode
optabs.c:01658 TF
expand_binop
/* Look for a wider mode of the same class for which we think we
can open-code the operation. Check for a widening multiply at the
wider mode as well. */
optabs.c:02203 TF
expand_binop
/* Look for a wider mode of the same class for which it appears we can do
the operation. */
optabs.c:03156 TF
expand_unop
/* It can't be done in this mode. Can we open-code it in a wider mode? */
optabs.c:03319 TF
expand_unop
/* It can't be done in this mode. Can we do it in a wider mode? */
optabs.c:05245 TF
expand_fix
/* We first try to find a pair of modes, one real and one integer, at
least as wide as FROM and TO, respectively, in which we can open-code
this conversion. If the integer mode is wider than the mode of TO,
we can do the conversion either signed or unsigned. */
optabs.c:05308 TF
expand_fix
/* unsigned conversion if no hardware support */
reginfo.c:00664 DF
reginfo.c:00664 SF
reginfo.c:00664 TF
choose_hard_reg_mode
/* We first look for the largest integer mode that can be validly
held in REGNO. If none, we look for the largest floating-point mode.
If we still didn't find a valid mode, try CCmode. */
reginfo.c:00673 V2DF
reginfo.c:00673 V2SF
reginfo.c:00673 V2TF
reginfo.c:00673 V4DF
reginfo.c:00673 V4SF
reginfo.c:00673 V8SF
choose_hard_reg_mode
/* look for vector float if we can't find float. */
stor-layout.c:00347 DC
stor-layout.c:00347 DF
stor-layout.c:00347 SC
stor-layout.c:00347 SF
mode_for_size
stor-layout.c:00541 V2SF
stor-layout.c:00541 V4SF
mode_for_vector
> (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.
--
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
