This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx
- From: Alan Modra <amodra at gmail dot com>
- To: Peter Bergner <bergner at vnet dot ibm dot com>
- Cc: David Edelsohn <dje dot gcc at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Segher Boessenkool <segher at kernel dot crashing dot org>, Bill Schmidt <wschmidt at linux dot vnet dot ibm dot com>, Michael Meissner <meissner at linux dot vnet dot ibm dot com>, Aaron Sawdey <acsawdey at linux dot vnet dot ibm dot com>, Ulrich Weigand <uweigand at de dot ibm dot com>
- Date: Mon, 11 Jul 2016 16:07:11 +0930
- Subject: Re: [PATCH, rs6000] Fix PR target/71733, ICE with -mcpu=power9 -mno-vsx
- Authentication-results: sourceware.org; auth=none
- References: <ed8225d9-e937-30fd-ab80-648f557cc0ff@vnet.ibm.com> <CAGWvny=aDm5NWGiYa8c2K8dpMGK9zDZ2j_rwjsO33UUx96cCUw@mail.gmail.com> <c3778cdb-d9b2-697b-fe81-db6857bedff5@vnet.ibm.com>
On Sat, Jul 09, 2016 at 10:26:55AM -0500, Peter Bergner wrote:
> The problem occurs when we have an altivec store, which is what the original
> test case had:
>
> bergner@genoa:~/gcc/BUGS/sawdey/altivec$ cat vec_store.i
> typedef __attribute__((altivec(vector__))) __attribute__((aligned(16))) unsigned char vec_t;
> void
> foo (vec_t *dst, vec_t src)
> {
> dst[1] = src;
> }
The reason this fails is that no alternative in altivec_mov<mode>
exactly matches. Ideally reload would choose the Z,v alternative
(cost 9) and you'd get an address reload for the mem to make it match
the "Z" constraint. Instead reload chooses the Y,r alternative (cost
8) as best.
That's a bad choice. "Y" matches the r3+16 mem so no reloads needed
for the mem, however the altivec reg needs to be reloaded to gprs.
Without direct moves from altivec to gpr the reload needs to go via
mem, so you get an altivec store to stack plus gpr load from stack.
The store to stack has the same form as the original store. Oops, no
progress.
Even if direct moves were available from altivec regs to gprs, the Y,r
alternative would still be a bad choice.
I believe all the r alternatives in altivec_mov<mode> should be
disparaged with "?".
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 7dad61e..65cbd6e 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -222,7 +222,7 @@
;; Vector move instructions.
(define_insn "*altivec_mov<mode>"
- [(set (match_operand:VM2 0 "nonimmediate_operand" "=Z,v,v,*Y,*r,*r,v,v,*r")
+ [(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)
--
Alan Modra
Australia Development Lab, IBM