[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670

[bergner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959

--- Comment #17 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #16)
> The question I have is, there are 2 expanders which I think we also need to
> guard with similar tests.  They are vsx_load_<mode> and vsx_store_<mode>. 
> Segher, I assume we want to verify we don't have an altivec style & ~16
> address there too, correct?  Just like we do in vector.md's mov<mode>
> pattern.

Ie, adding the following hunks to the patch above:

@@ -1241,7 +1245,8 @@
   "VECTOR_MEM_VSX_P (<MODE>mode)"
 {
   /* Expand to swaps if needed, prior to swap optimization.  */
-  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR)
+  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR
+      && !altivec_indexed_or_indirect_operand(operands[1], <MODE>mode))
     {
       rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);
       DONE;
@@ -1254,7 +1259,8 @@
   "VECTOR_MEM_VSX_P (<MODE>mode)"
 {
   /* Expand to swaps if needed, prior to swap optimization.  */
-  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR)
+  if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR
+      && !altivec_indexed_or_indirect_operand(operands[0], <MODE>mode))
     {
       rs6000_emit_le_vsx_move (operands[0], operands[1], <MODE>mode);
       DONE;