https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
So we end up dropping into rs6000_emit_le_vsx_store from gen_movv4si via:
if (!BYTES_BIG_ENDIAN
&& VECTOR_MEM_VSX_P (<MODE>mode)
&& !TARGET_P9_VECTOR
&& !gpr_or_gpr_p (operands[0], operands[1])
&& (memory_operand (operands[0], <MODE>mode)
^ memory_operand (operands[1], <MODE>mode)))
{
rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);
DONE;
}
This is catching the case (during expand) where we have non LE friendly
loads/stores and we need to emit permutes with them. In the case where we are
ICEing, we actually have a LE friendly Altivec mem:
Breakpoint 9, rs6000_emit_le_vsx_store (dest=0x3fffb580c888,
source=0x3fffb580ea90, mode=E_V4SImode)
at
/home/bergner/gcc/gcc-fsf-mainline-pr84264/gcc/config/rs6000/rs6000.c:10357
10357 {
(gdb) pr2 dest source
(mem/c:V4SI (and:DI (plus:DI (reg:DI 141)
(reg:DI 140))
(const_int -16 [0xfffffffffffffff0])) [1 args+0 S16 A128])
(reg:V4SI 142)
In this case, we can just emit the store normally and don't need to drop into
rs6000_emit_le_vsx_move at all. Guarding the code above to ensure we don't
have an Altivec mem via altivec_indexed_or_indirect_operand() fixes the ICE:
Index: vector.md
===================================================================
--- vector.md (revision 258115)
+++ vector.md (working copy)
@@ -136,8 +136,10 @@ (define_expand "mov<mode>"
&& VECTOR_MEM_VSX_P (<MODE>mode)
&& !TARGET_P9_VECTOR
&& !gpr_or_gpr_p (operands[0], operands[1])
- && (memory_operand (operands[0], <MODE>mode)
- ^ memory_operand (operands[1], <MODE>mode)))
+ && ((memory_operand (operands[0], <MODE>mode)
+ && !altivec_indexed_or_indirect_operand(operands[0], <MODE>mode))
+ ^ (memory_operand (operands[1], <MODE>mode)
+ && !altivec_indexed_or_indirect_operand(operands[1],
<MODE>mode))))
{
rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);
DONE;
