I submitted the original version of the patch back in August, and then I forgot
about it.
https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01600.html

Hi Mike,

On Mon, Aug 28, 2017 at 02:50:02PM -0400, Michael Meissner wrote:
> When I added the optimization for loading 32-bit values directly into the
> vector registers from memory to convert to IEEE 128-bit floating point, I
> forgot to make sure the address did not have PRE_INCREMENT, etc. addressing.

> 	* config/rs6000/rs6000.md (float_<mode>si2_hw): If register
> 	allocation hasn't been done, make sure the memory address is
> 	X-FORM (register+register).
> 	(floatuns_<mode>si2_hw2): Likewise.

Why is it okay after RA but not before?

Register allocation has fixed the address due to the 'Z' constraint, so it is
no longer an AUTOINC address.  I've fixed it so that the function
rs6000_address_for_fpconvert checks whether it is being called after register
allocation, and if so, it does nothing.

> --- gcc/config/rs6000/rs6000.md	(revision 251358)
> +++ gcc/config/rs6000/rs6000.md	(working copy)
> @@ -14505,6 +14505,9 @@ (define_insn_and_split "float_<mode>si2_
>  {
>    if (GET_CODE (operands[2]) == SCRATCH)
>      operands[2] = gen_reg_rtx (DImode);
> +
> +  if (MEM_P (operands[1]) && !reload_completed)
> +    operands[1] = rs6000_address_for_fpconvert (operands[1]);
>  })

It will need a comment here, then (other callers of
rs6000_address_for_fpconvert do not test for !reload_completed).

All of the other uses of rs6000_address_for_fpconvert are either in
define_expands or on the first splitter pass, which occurs before register
allocation.

Or maybe the predicate should be stricter in all these cases?
nonimmediate_operand allows a lot ;-)

No, then it tends to generate worse code if it is done before the first split
pass (because it no longer keeps the address together).  I've been thinking
that in general, we should replace these calls with a new predicate that before
register allocation allows normal memory addresses, but during/after RA, it
becomes more strict.  In my experience, with RELOAD that wasn't feasible, but
LRA can handle it (and RELOAD is no longer an issue).

> --- gcc/testsuite/gcc.target/powerpc/pr81959.c	(revision 0)
> +++ gcc/testsuite/gcc.target/powerpc/pr81959.c	(revision 0)
> @@ -0,0 +1,25 @@
> +/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
> +/* { dg-require-effective-target powerpc_p9vector_ok } */
> +/* { dg-options "-mpower9-vector -O2 -mfloat128" } */

powerpc*-*-*, or does that not work?

It needs 64-bit because various machine independent parts of the compiler want
to use TImode if there is arithmetic support for KFmode to copy things, and
TImode isn't supported in 32-bit.

The __float128 support is not built if the compiler is a 32-bit compiler (the
enabler for _float128 is in linux64.h)

Here is the current version of the patch.  I have done bootstraps and make
check with no regressions.  Can I check this into the trunk?

The bug shows up in GCC 7 as well.  Assuming it backports cleanly, can I check
this into GCC 7 also?

[gcc]
2017-11-30  Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR target/81959
	* config/rs6000/rs6000.c (rs6000_address_for_fpconvert): Check for
	whether we can allocate pseudos before trying to fix an address.
	* config/rs6000/rs6000.md (float_<mode>si2_hw): Make sure the
	memory address is indexed or indirect.
	(floatuns_<mode>si2_hw2): Likewise.

[gcct/testsuite]
2017-11-30  Michael Meissner  <meissner@linux.vnet.ibm.com>

	PR target/81959
	* gcc.target/powerpc/pr81959.c: New test.

-- 
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