, PowerPC IEEE 128-bit patch #4

This is another intermediate patch to get IEEE 128-bit support on the PowerPC
into the GCC compiler. This patch adds a lot of the support to allow IEEE
128-bit support in VSX registers. Note, it will need future patches that
updates rs6000.c and rs6000.md to enable the basic IEEE 128-bit support.

This patch bootstraps and has no test suite regressions on a big endian Power7
system and a little endian system. Is it ok to install?

The expected future patches are:

  #5	Finish the enablement of the basic support (rs6000.c & rs6000.md
	changes);

  #6	Add support for using different names for the 64/128-bit integer
	conversion to IBM extended double, to allow a future version to
	switch the default for what long double is. It is not expected that GCC
	6.x will make this switch, but we would like to eventually use the
	standard TF names for the library when the default change is made. If
	this isn't clear, the following names use 'tf' in them, when they use
	IBM extended double:

		__dpd_extendddtf
		__dpd_extendsdtf
		__dpd_extendtftd
		__dpd_trunctdtf
		__dpd_trunctfdd
		__dpd_trunctfsd
		__fixtfdi
		__fixtfti
		__fixunstfti
		__floattitf
		__floatuntitf
		__powitf2
		__floatditf
		__floatunditf
		__fixunstfdi

  #7	Basic patches to enable libgcc support. It is anticipated that these
	patches may be temporary changes, to allow for the glibc team to do the
	soft-float emulator changes that are shared with libgcc (but they can't
	really start until there is basic support in there).

  #8	Enable IEEE 128-bit floating point in VSX registers by default for VSX
	systems, add tests for IEEE 128-bit support and correct calling
	sequence.

  #9...	Various fixes of things I haven't yet covered (complex, libquadmath,
	etc.).

2015-07-28  Michael Meissner  <meissner@linux.vnet.ibm.com>

	* config/rs6000/vector.md (VEC_L): Add KFmode and TFmode.
	(VEC_M): Likewise.
	(VEC_N): Likewise.
	(mov<mode>, VEC_M iterator): Add support for IEEE 128-bit floating
	point in VSX registers.

	* config/rs6000/constraints.md (wb constraint): Document unused
	w<x> constraint.
	(we constraint): Likewise.
	(wo constraint): Likewise.
	(wp constraint): New constraint for IEEE 128-bit floating point in
	VSX registers.
	(wq constraint): Likewise.

	* config/rs6000/predicates.md (easy_fp_constant): Add support for
	IEEE 128-bit floating point in VSX registers.
	(easy_scalar_constant): Likewise.

	* config/rs6000/rs6000.c (rs6000_debug_reg_global): Add new
	constraints (wp, wq) for IEEE 128-bit floating point in VSX
	registers.
	(rs6000_init_hard_regno_mode_ok): Likewise.

	* config/rs6000/vsx.md (VSX_LE_128): Add support for IEEE 128-bit
	floating point in VSX registers.
	(VSX_L): Likewise.
	(VSX_M): Likewise.
	(VSX_M2): Likewise.
	(VSm): Likewise.
	(VSs): Likewise.
	(VSr): Likewise.
	(VSa): Likewise.
	(VSv): Likewise.
	(vsx_le_permute_<mode>): Add support to properly swap bytes for
	IEEE 128-bit floating point in VSX registers on little endian.
	(vsx_le_undo_permute_<mode>): Likewise.
	(vsx_le_perm_load_<mode>): Likewise.
	(vsx_le_perm_store_<mode>): Likewise.
	(splitters for IEEE 128-bit fp moves): Likewise.

	* config/rs6000/rs6000.h (enum r6000_reg_class_enum): Add wp and
	wq constraints.

	* config/rs6000/altivec.md (VM): Add support for IEEE 128-bit
	floating point in VSX registers.
	(VM2): Likewise.
	(altivec_high_bit): New insn to set just the high bit in an
	altivec register.

	* doc/md.text (Machine Constraints): Document wp and wq
	constraints on PowerPC.

On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> +;; Return constant 0x80000000000000000000000000000000 in an Altivec register.
> +
> +(define_expand "altivec_high_bit"
> +  [(set (match_dup 1)
> +	(vec_duplicate:V16QI (const_int 7)))
> +   (set (match_dup 2)
> +	(ashift:V16QI (match_dup 1)
> +		      (match_dup 1)))
> +   (set (match_dup 3)
> +	(match_dup 4))
> +   (set (match_operand:V16QI 0 "register_operand" "")
> +	(unspec:V16QI [(match_dup 2)
> +		       (match_dup 3)
> +		       (const_int 15)] UNSPEC_VSLDOI))]
> +  "TARGET_ALTIVEC"
> +{
> +  if (can_create_pseudo_p ())
> +    {
> +      operands[1] = gen_reg_rtx (V16QImode);
> +      operands[2] = gen_reg_rtx (V16QImode);
> +      operands[3] = gen_reg_rtx (V16QImode);
> +    }
> +  else
> +    operands[1] = operands[2] = operands[3] = operands[0];

This won't work (in the pattern you write to op 3 before reading from op 2).
Do you ever call this expander late, anyway?


Segher

On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > +;; Return constant 0x80000000000000000000000000000000 in an Altivec register.
> > +
> > +(define_expand "altivec_high_bit"
> > +  [(set (match_dup 1)
> > +	(vec_duplicate:V16QI (const_int 7)))
> > +   (set (match_dup 2)
> > +	(ashift:V16QI (match_dup 1)
> > +		      (match_dup 1)))
> > +   (set (match_dup 3)
> > +	(match_dup 4))
> > +   (set (match_operand:V16QI 0 "register_operand" "")
> > +	(unspec:V16QI [(match_dup 2)
> > +		       (match_dup 3)
> > +		       (const_int 15)] UNSPEC_VSLDOI))]
> > +  "TARGET_ALTIVEC"
> > +{
> > +  if (can_create_pseudo_p ())
> > +    {
> > +      operands[1] = gen_reg_rtx (V16QImode);
> > +      operands[2] = gen_reg_rtx (V16QImode);
> > +      operands[3] = gen_reg_rtx (V16QImode);
> > +    }
> > +  else
> > +    operands[1] = operands[2] = operands[3] = operands[0];
> 
> This won't work (in the pattern you write to op 3 before reading from op 2).
> Do you ever call this expander late, anyway?

I'm not sure I follow you.  Without the patch lines the insns are as follows (I
put in blank lines to separate the insns):

(define_expand "altivec_high_bit"
  [(set (match_dup 1)
	(vec_duplicate:V16QI (const_int 7)))

   (set (match_dup 2)
	(ashift:V16QI (match_dup 1)
		      (match_dup 1)))

   (set (match_dup 3)
	(match_dup 4))

   (set (match_operand:V16QI 0 "register_operand" "")
	(unspec:V16QI [(match_dup 2)
		       (match_dup 3)
		       (const_int 15)] UNSPEC_VSLDOI))]
  "TARGET_ALTIVEC"
{
  if (can_create_pseudo_p ())
    {
      operands[1] = gen_reg_rtx (V16QImode);
      operands[2] = gen_reg_rtx (V16QImode);
      operands[3] = gen_reg_rtx (V16QImode);
    }
  else
    operands[1] = operands[2] = operands[3] = operands[0];

  operands[4] = CONST0_RTX (V16QImode);
})

The first insn sets operands[1] to be 0x07070707070707070707070707070707LL.

The second insn sets operands[2] to be operands[1] << operands[1], i.e.
0x80808080808080808080808080808080LL.

The third insn sets operands[3] to be 0.

The fourth does a double vector shift left 15 bytes, filing in 0's in the
bottom bits, which leaves the following in the register:
0x80000000000000000000000000000000LL

This is negative -0.0 in IEEE 128-bit, which is used to flip the sign bit.

The code is used for negate and absolute value (which is done during rtl
expansion). Here is the negate use case.

(define_insn_and_split "ieee_128bit_vsx_neg<mode>2"
  [(set (match_operand:TFIFKF 0 "register_operand" "=wa")
	(neg:TFIFKF (match_operand:TFIFKF 1 "register_operand" "wa")))
   (clobber (match_scratch:V16QI 2 "=v"))]
  "TARGET_FLOAT128 && FLOAT128_IEEE_P (<MODE>mode)"
  "#"
  ""
  [(parallel [(set (match_dup 0)
		   (neg:TFIFKF (match_dup 1)))
	      (use (match_dup 2))])]
{
  if (GET_CODE (operands[2]) == SCRATCH)
    operands[2] = gen_reg_rtx (V16QImode);

  operands[3] = gen_reg_rtx (V16QImode);
  emit_insn (gen_altivec_high_bit (operands[2]));
}
  [(set_attr "length" "8")
   (set_attr "type" "vecsimple")])

(define_insn "*ieee_128bit_vsx_neg<mode>2_internal"
  [(set (match_operand:TFIFKF 0 "register_operand" "=wa")
	(neg:TFIFKF (match_operand:TFIFKF 1 "register_operand" "wa")))
   (use (match_operand:V16QI 2 "register_operand" "=v"))]
  "TARGET_FLOAT128"
  "xxlxor %x0,%x1,%x2"
  [(set_attr "length" "4")
   (set_attr "type" "vecsimple")])

On Wed, Jul 29, 2015 at 06:38:45PM -0400, Michael Meissner wrote:
> On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> > On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > > +;; Return constant 0x80000000000000000000000000000000 in an Altivec register.
> > > +
> > > +(define_expand "altivec_high_bit"
> > > +  [(set (match_dup 1)
> > > +	(vec_duplicate:V16QI (const_int 7)))
> > > +   (set (match_dup 2)
> > > +	(ashift:V16QI (match_dup 1)
> > > +		      (match_dup 1)))
> > > +   (set (match_dup 3)
> > > +	(match_dup 4))
> > > +   (set (match_operand:V16QI 0 "register_operand" "")
> > > +	(unspec:V16QI [(match_dup 2)
> > > +		       (match_dup 3)
> > > +		       (const_int 15)] UNSPEC_VSLDOI))]
> > > +  "TARGET_ALTIVEC"
> > > +{
> > > +  if (can_create_pseudo_p ())
> > > +    {
> > > +      operands[1] = gen_reg_rtx (V16QImode);
> > > +      operands[2] = gen_reg_rtx (V16QImode);
> > > +      operands[3] = gen_reg_rtx (V16QImode);
> > > +    }
> > > +  else
> > > +    operands[1] = operands[2] = operands[3] = operands[0];
> > 
> > This won't work (in the pattern you write to op 3 before reading from op 2).
> > Do you ever call this expander late, anyway?
> 
> I'm not sure I follow you.

I'm sorry, I meant that very last line I quoted, the !can_create_pseudo_p ()
one.  If that is executed operands[2] will be the same reg as operands[3],
and things fall apart.


Segher

On Wed, Jul 29, 2015 at 05:46:42PM -0500, Segher Boessenkool wrote:
> On Wed, Jul 29, 2015 at 06:38:45PM -0400, Michael Meissner wrote:
> > On Wed, Jul 29, 2015 at 04:59:23PM -0500, Segher Boessenkool wrote:
> > > On Wed, Jul 29, 2015 at 04:04:28PM -0400, Michael Meissner wrote:
> > > > +;; Return constant 0x80000000000000000000000000000000 in an Altivec register.
> > > > +
> > > > +(define_expand "altivec_high_bit"
> > > > +  [(set (match_dup 1)
> > > > +	(vec_duplicate:V16QI (const_int 7)))
> > > > +   (set (match_dup 2)
> > > > +	(ashift:V16QI (match_dup 1)
> > > > +		      (match_dup 1)))
> > > > +   (set (match_dup 3)
> > > > +	(match_dup 4))
> > > > +   (set (match_operand:V16QI 0 "register_operand" "")
> > > > +	(unspec:V16QI [(match_dup 2)
> > > > +		       (match_dup 3)
> > > > +		       (const_int 15)] UNSPEC_VSLDOI))]
> > > > +  "TARGET_ALTIVEC"
> > > > +{
> > > > +  if (can_create_pseudo_p ())
> > > > +    {
> > > > +      operands[1] = gen_reg_rtx (V16QImode);
> > > > +      operands[2] = gen_reg_rtx (V16QImode);
> > > > +      operands[3] = gen_reg_rtx (V16QImode);
> > > > +    }
> > > > +  else
> > > > +    operands[1] = operands[2] = operands[3] = operands[0];
> > > 
> > > This won't work (in the pattern you write to op 3 before reading from op 2).
> > > Do you ever call this expander late, anyway?
> > 
> > I'm not sure I follow you.
> 
> I'm sorry, I meant that very last line I quoted, the !can_create_pseudo_p ()
> one.  If that is executed operands[2] will be the same reg as operands[3],
> and things fall apart.

Yes, you are right. I'll put an abort in there if we can't allocate
pseudos. But since it is called during RTL expansion of abskf2, negkf2, etc. we
won't run into it.  Thanks.

On Wed, 29 Jul 2015, Michael Meissner wrote:

>   #6	Add support for using different names for the 64/128-bit integer
> 	conversion to IBM extended double, to allow a future version to
> 	switch the default for what long double is. It is not expected that GCC
> 	6.x will make this switch, but we would like to eventually use the
> 	standard TF names for the library when the default change is made. If
> 	this isn't clear, the following names use 'tf' in them, when they use
> 	IBM extended double:

That would be for a completely separate ABI, incompatible with all 
existing objects both static and shared, since the existing ABI defines 
these names to have their existing meanings?

On Fri, Jul 31, 2015 at 12:43:20AM +0000, Joseph Myers wrote:
> On Wed, 29 Jul 2015, Michael Meissner wrote:
> 
> >   #6	Add support for using different names for the 64/128-bit integer
> > 	conversion to IBM extended double, to allow a future version to
> > 	switch the default for what long double is. It is not expected that GCC
> > 	6.x will make this switch, but we would like to eventually use the
> > 	standard TF names for the library when the default change is made. If
> > 	this isn't clear, the following names use 'tf' in them, when they use
> > 	IBM extended double:
> 
> That would be for a completely separate ABI, incompatible with all 
> existing objects both static and shared, since the existing ABI defines 
> these names to have their existing meanings?

The OpenPower 1.1 ABI for little endian PowerPC 64-bit does not mention the
names at all.  This ABI leaves it open whether long double is IBM extended
double or IEEE 128-bit floating point. One of the goals of these patches is
someday in the future change the default.

A lot of work, particularly in the library space needs to be done to change the
default. Until we can make the switch, users that want IEEE 128-bit support
will need to use __float128.

The intention of theese changes (currently unwritten) is to change the existing
problematical names that use TF in their name to be something else, and provide
via a weak reference an alias for the old name. So if for example, we change
the default in GCC 7.0, code compiled by GCC 6.0 would work because it uses say
__gcc_ltoq to call convert a 64-bit integer to IBM extended double instead of
__floatditf. Older code that refers to __floatditf would still work fine.

Then sometime later (such as GCC 8.0) we could make __floatditf be a weak
reference to __floatdikt.

If you have any ideas of how to do this seemlessly, please let me know.  Steve
Monroe and David Edelsohn requested that I explore that some date in the
future, we will be able to use the standard names.

I tend to be skeptical that we can do it without running into some
incompatibility, and I feel that we just have to live with the existing TF
names, and not use TF for IEEE 128-bit.

Currently, I'm using KF for the IEEE 128-bit functions, even if long double is
mapped to IEEE 128-bit instead of long double.

Another wrinkle is the 32-bit RTEMS port actually uses IEEE 128-bit floating
point with the standard names, because they never used the IBM extended
double.

On Mon, 3 Aug 2015, Michael Meissner wrote:

> The intention of theese changes (currently unwritten) is to change the existing
> problematical names that use TF in their name to be something else, and provide
> via a weak reference an alias for the old name. So if for example, we change
> the default in GCC 7.0, code compiled by GCC 6.0 would work because it uses say
> __gcc_ltoq to call convert a 64-bit integer to IBM extended double instead of
> __floatditf. Older code that refers to __floatditf would still work fine.

But as those names are in the implementation namespace and aren't 
user-visible, I don't see the point in such a change (other than as part 
of a complete new incompatible ABI which gets its own copies of libgcc, 
libstdc++, libc, libm and other affected libraries).  Of course it *can* 
be done via symbol versioning to keep working with existing binaries / 
shared libraries using the existing symbols from libgcc, but the libgcc 
build system doesn't make that sort of target-specific symbol versioning 
particularly convenient.  And as usual with symbol versioning, you'd break 
compatibility with existing static libraries / .o files.

There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar.  Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6 have been
applied.

Patch #5 adds the following:
 * Support for the reload handlers that will be enabled in patch #7.
 * Adds IFmode/KFmode to other iterators as appropriate.
 * Adds the basic negate, absolute value, and negative absolute value support.
 * Adds the insns for the 128-bit pack/unpack routines.

Patch #6 adds the following:
 * Adds support for comparisons.
 * Updates the cannot change mode support.

Patch #7 finishes up the initial basic support.
 * It defines macros for IEEE 128-bit floating point users.
 * It defines the basic move support.
 * It sets up the calling sequence.
 * It registers the __float128 and __ibm128 keywords.
 * It sets up the various handler functions.
 * It adds 'q' and 'Q' as the suffix for IEEE 128-bit floating point.
 * It adds target attribute/pragma support for the IEEE 128-bit options.
 * It treats IEEE 128-bit in VSX register modes as vector.
 * It uses a unique mangling for IEEE 128-bit in VSX registers.
 * It moves vector modes tieable above scalar floating point.
 * It adds a simple minded test to make sure IEEE args are passed as vectors.

Things to be done:
 * Work with GDB to add debug support.
 * Work with GLIBC to add basic software emulation support.
 * Work with GLIBC on other IEEE 128-bit support.
 * Look into Complex support.
 * Look into libquadmath support.
 * Enable -mfloat128-software if -mvsx.
 * Add more tests.
 * Fix bugs that show up if -mabi=ieeelongdouble is used.

Each patch bootstraps without error and has no regressions. Are they ok to
install in the trunk?

This is patch #6:

2015-08-13  Michael Meissner  <meissner@linux.vnet.ibm.com>

	* config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
	Add declaration.

	* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
	comment.
	(rs6000_cannot_change_mode_class): Add support for IEEE 128-bit
	floating point in VSX registers.
	(rs6000_output_move_128bit): Always print out the set insn if we
	can't generate an appropriate 128-bit move.
	(rs6000_generate_compare): Add support for IEEE 128-bit floating
	point in VSX registers comparisons.
	(rs6000_expand_float128_convert): Likewise.

	* config/rs6000/rs6000.md (extenddftf2): Add support for IEEE
	128-bit floating point in VSX registers.
	(extenddftf2_internal): Likewise.
	(trunctfdf2): Likewise.
	(trunctfdf2_internal2): Likewise.
	(fix_trunc_helper): Likewise.
	(fix_trunctfdi2"): Likewise.
	(floatditf2): Likewise.
	(floatuns<mode>tf2): Likewise.
	(extend<FLOAT128_SFDFTF:mode><IFKF:mode>2): Likewise.
	(trunc<IFKF:mode><FLOAT128_SFDFTF:mode>2): Likewise.
	(fix_trunc<IFKF:mode><SDI:mode>2): Likewise.
	(fixuns_trunc<IFKF:mode><SDI:mode>2): Likewise.
	(float<SDI:mode><IFKF:mode>2): Likewise.
	(floatuns<SDI:mode><IFKF:mode>2): Likewise.

On Fri, Aug 14, 2015 at 11:47 AM, Michael Meissner
<meissner@linux.vnet.ibm.com> wrote:

> This is patch #6:
>
> 2015-08-13  Michael Meissner  <meissner@linux.vnet.ibm.com>
>
>         * config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
>         Add declaration.
>
>         * config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
>         comment.
>         (rs6000_cannot_change_mode_class): Add support for IEEE 128-bit
>         floating point in VSX registers.
>         (rs6000_output_move_128bit): Always print out the set insn if we
>         can't generate an appropriate 128-bit move.
>         (rs6000_generate_compare): Add support for IEEE 128-bit floating
>         point in VSX registers comparisons.
>         (rs6000_expand_float128_convert): Likewise.
>
>         * config/rs6000/rs6000.md (extenddftf2): Add support for IEEE
>         128-bit floating point in VSX registers.
>         (extenddftf2_internal): Likewise.
>         (trunctfdf2): Likewise.
>         (trunctfdf2_internal2): Likewise.
>         (fix_trunc_helper): Likewise.
>         (fix_trunctfdi2"): Likewise.
>         (floatditf2): Likewise.
>         (floatuns<mode>tf2): Likewise.
>         (extend<FLOAT128_SFDFTF:mode><IFKF:mode>2): Likewise.
>         (trunc<IFKF:mode><FLOAT128_SFDFTF:mode>2): Likewise.
>         (fix_trunc<IFKF:mode><SDI:mode>2): Likewise.
>         (fixuns_trunc<IFKF:mode><SDI:mode>2): Likewise.
>         (float<SDI:mode><IFKF:mode>2): Likewise.
>         (floatuns<SDI:mode><IFKF:mode>2): Likewise.

This patch is okay.

Thanks, David