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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
And

/* Merge
     c = VEC_PERM_EXPR <a, b, VCST0>;
     d = VEC_PERM_EXPR <c, c, VCST1>;
   to             
     d = VEC_PERM_EXPR <a, b, NEW_VCST>;  */

is a bit confused about constraints, but matching modes instead of TYPE_SIZE
to make sure can_vec_perm_const_p are applicable doesn't fix it either.  I'll
note this pattern specifically uses vec_perm_indices sel1 (builder1, 1, nelts);
thus single-arg - using , 2, there _does_ fix the testcase.  I'm a bit confused
here - we don't seem to record whether we use 1 or 2 in the IL but what
we use decides on whether the target can expand or not.  Richard?

diff --git a/gcc/match.pd b/gcc/match.pd
index ad966766376..1e78d0795fd 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -11123,8 +11122,8 @@ and,
    }
    (if (tree_to_vec_perm_builder (&builder0, @4)
        && tree_to_vec_perm_builder (&builder1, @5)
-       && TYPE_SIZE (TREE_TYPE (TREE_TYPE (@0)))
-          == TYPE_SIZE (TREE_TYPE (TREE_TYPE (@1))))
+       && result_mode == TYPE_MODE (TREE_TYPE (@1))
+       && op_mode == TYPE_MODE (TREE_TYPE (@0)))
     (with
      {
        vec_perm_indices sel0 (builder0, 2, nelts);

Reply via email to