[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

["linkw at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |rguenth at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
With further investigation, this isn't duplicated. Now we have the function
partial_vectors_supported_p to get boolean supports_partial_vectors.

on rs6000, it's:

bool
partial_vectors_supported_p (void)
{
  return HAVE_len_load_v16qi || HAVE_len_store_v16qi;
}

#define HAVE_len_load_v16qi (TARGET_P9_VECTOR && TARGET_64BIT)
#define HAVE_len_store_v16qi (TARGET_P9_VECTOR && TARGET_64BIT)

The above optabs are supported from Power9 already.

However, we only enable it from Power10 due to known performance issue on
Power9.

      /* The lxvl/stxvl instructions don't perform well before Power10.  */
      if (TARGET_POWER10)
        SET_OPTION_IF_UNSET (&global_options, &global_options_set,
                             param_vect_partial_vector_usage, 1);
      else
        SET_OPTION_IF_UNSET (&global_options, &global_options_set,
                             param_vect_partial_vector_usage, 0);

So checking optab supports look not robust.

I had a check with the below fix, it works:

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index ba67de490bb..49d53fb3383 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -3026,7 +3026,8 @@ vect_analyze_loop (class loop *loop, vec_info_shared
*shared)
   vector_modes[0] = autodetected_vector_mode;
   mode_i = 0;

-  bool supports_partial_vectors = partial_vectors_supported_p ();
+  bool supports_partial_vectors =
+    partial_vectors_supported_p () && param_vect_partial_vector_usage != 0;
   poly_uint64 first_vinfo_vf = LOOP_VINFO_VECT_FACTOR (first_loop_vinfo);

   while (1)


But, is there some reason not use the LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P of
first_loop_vinfo? It respects param_vect_partial_vector_usage and checks
partial vector supports (LOOP_VINFO_MASKS and LOOP_VINFO_LENS) during the
analysis phase, it looks good fit for this need of supports_partial_vectors.