https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127962
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so the original two permutations are supported with -march=z14 but
the expectred permute
_12 = VEC_PERM_EXPR <_1, _2, { 2, 7, 5, 0 }>;
as well. Which is because we are excluding variable permutes I guess:
/* If the new VEC_PERM_EXPR can't be handled but both
original VEC_PERM_EXPRs can, punt.
If one or both of the original VEC_PERM_EXPRs can't be
handled and the new one can't be either, don't increase
number of VEC_PERM_EXPRs that can't be handled. */
if (can_vec_perm_const_p (perm_mode, op2_mode, new_sel, false)
|| (single_use (@0)
? (!can_vec_perm_const_p (inner_mode, op2_mode, sel4, true)
|| !can_vec_perm_const_p (result_mode, vc_mode, sel5, true))
: !can_vec_perm_const_p (result_mode, vc_mode, sel5, true)))
new_vcst = vec_perm_indices_to_tree (TREE_TYPE (@5), new_sel);
so for the existing permutes we are allowing variable permutes but we
require a constant permute for the result which is for costing reasons.
It seems that we'd want to allow the transform to a variable permute when
there was a variable permute. Which complicates (and duplicates) the query
a bit. I suppose the can_vec_perm_const_p API should be enhanced to
communicate whether a variable permute is required.
I'll think about it.
