[PATCH] Add SPECIAL_FLOAT_MODE to enable adding IEEE 128-bit floating point to PowerPC

[Michael Meissner]

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