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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.0
                 CC|                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org
             Status|ASSIGNED                    |NEW
           Assignee|marxin at gcc dot gnu.org          |unassigned at gcc dot 
gnu.org

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, so the issue was fixed in g:74166aabeb7f22990476b1169bba031b8323ee92, which
is about a preferred vector types.

So with the following patch:

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 9e88438b3c3..1e5a05a00b0 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -17351,14 +17351,14 @@ aarch64_autovectorize_vector_modes (vector_modes
*modes, bool)

        TODO: We could support a limited form of V4QImode too, so that
        we use 32-bit vectors for 8-bit elements.  */
-    V4HImode,
+//    V4HImode,

     /* Try using 64-bit vectors for 32-bit elements and 128-bit vectors
        for 64-bit elements.

        TODO: We could similarly support limited forms of V2QImode and V2HImode
        for this case.  */
-    V2SImode
+//    V2SImode
   };

   /* Try using N-byte SVE modes only after trying N-byte Advanced SIMD mode.
@@ -23901,8 +23901,8 @@ aarch64_libgcc_floating_mode_supported_p
 #define TARGET_VECTORIZE_VEC_PERM_CONST \
   aarch64_vectorize_vec_perm_const

-#undef TARGET_VECTORIZE_RELATED_MODE
-#define TARGET_VECTORIZE_RELATED_MODE aarch64_vectorize_related_mode
+//#undef TARGET_VECTORIZE_RELATED_MODE
+//#define TARGET_VECTORIZE_RELATED_MODE aarch64_vectorize_related_mode
 #undef TARGET_VECTORIZE_GET_MASK_MODE
 #define TARGET_VECTORIZE_GET_MASK_MODE aarch64_get_mask_mode
 #undef TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE

I tracked that it was fixed with g:04b99da898a9817e72fedb4063589648b7961ac5,
which is a vectorizer related revision.

Thus it's likely dup of PR97236.

Can we backport the fixed into 8 and 9 branch?

Reply via email to