diff mbox

[rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx

Message ID 20160714024410.GD1632@bubble.grove.modra.org
State New
Headers show

Commit Message

Alan Modra July 14, 2016, 2:44 a.m. UTC 
On Wed, Jul 13, 2016 at 06:46:22AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 13, 2016 at 02:57:01PM +0930, Alan Modra wrote:
> > This is what I've bootstrapped and regression tested on
> > powerpc64le-linux.  I'm using Peter's testcases from this thread
> > rather than the one in the original patch submission, because that one
> > relies on -O0 not reducing the function down to a nop.  OK to apply?
> 
> This is okay.  Does it need a backport?  Okay for 6 as well, then.

Yes, gcc-6 needs the patch too.

> We all agreed the question marks would be a good idea, but you say it
> causes some testcases to fail.  Could you investigate please?

After much head-scratching (danger of splinters) I noticed that I'd
written '*?r' in the patch rather than '?*r'.  That explained failures
like gcc.target/powerpc/ppc-vector-memset.c using gprs rather than vrs
for the memset expansion.  According to md.text, '*' says the
following char should be ignored when choosing register preferences.
(Which is a bug, since the advent of multi-char constraints, and
potentially affects us with our use of constraint strings like "?*wb".)
Anyway, what was ignored for reg allocation was the '?', not 'r'.

Also, '*Y' is a bit pointless since 'Y' isn't a register constraint.
The '*' belongs on the corresponding operand 1 'r'.

I also saw ICEs in rs6000_split_multireg_move on a number of
gcc.dg/vmx testcases, but the ICEs disappeared with the constraints
fixed.  I can't give you the exact rtl involved now since my debug
session had a connection timeout, but it was this assert:
		  gcc_assert (GET_CODE (XEXP (dst, 0)) == PLUS
			      && REG_P (basereg)
			      && REG_P (offsetreg)
			      && REGNO (basereg) != REGNO (offsetreg));
and we had an altivec MEM with an AND address for the destination of a
SET with gprs for the source.  Probably quite easily fixed by
stripping off the AND.

The following has now been bootstrapped and regression tested on
powerpc64le-linux.  OK for mainline?

	* gcc/config/rs6000/altivec.md (altivec_mov<mode>): Disparage
	gpr alternatives.  Correct '*' placement on Y,r alternative.
	Add '*' on operand 1 of r,r alternative.

Comments

Alan Modra July 14, 2016, 2:51 a.m. UTC | #1 
On Thu, Jul 14, 2016 at 12:14:10PM +0930, Alan Modra wrote:
> (Which is a bug, since the advent of multi-char constraints, and
> potentially affects us with our use of constraint strings like "?*wb".)

On looking into this, I see it is just a documentation bug.
Segher Boessenkool July 14, 2016, 1:55 p.m. UTC | #2 
On Thu, Jul 14, 2016 at 12:14:10PM +0930, Alan Modra wrote:
> The following has now been bootstrapped and regression tested on
> powerpc64le-linux.  OK for mainline?
> 
> 	* gcc/config/rs6000/altivec.md (altivec_mov<mode>): Disparage
> 	gpr alternatives.  Correct '*' placement on Y,r alternative.
> 	Add '*' on operand 1 of r,r alternative.

Okay for mainline, thank you!


Segher
diff mbox

Patch

diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index aa01ac9..9193f07 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -222,8 +222,8 @@ 
 
 ;; Vector move instructions.
 (define_insn "*altivec_mov<mode>"
-  [(set (match_operand:VM2 0 "nonimmediate_operand" "=Z,v,v,*Y,*r,*r,v,v,*r")
-	(match_operand:VM2 1 "input_operand" "v,Z,v,r,Y,r,j,W,W"))]
+  [(set (match_operand:VM2 0 "nonimmediate_operand" "=Z,v,v,?Y,?*r,?*r,v,v,?*r")
+	(match_operand:VM2 1 "input_operand" "v,Z,v,*r,Y,*r,j,W,W"))]
   "VECTOR_MEM_ALTIVEC_P (<MODE>mode)
    && (register_operand (operands[0], <MODE>mode) 
        || register_operand (operands[1], <MODE>mode))"