https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117173
Bug ID: 117173
Summary: can_vec_perm_const_p does not consider costs
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rdapp at gcc dot gnu.org
CC: law at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
I only noticed this on riscv but it's actually a target-independent issue.
In match.pd:10927 we have the following pattern
/* Merge
c = VEC_PERM_EXPR <a, b, VCST0>;
d = VEC_PERM_EXPR <c, c, VCST1>;
to
d = VEC_PERM_EXPR <a, b, NEW_VCST>; */
which merges a permutation of a permutation into a single one.
It correctly checks that the newly built permutation is supported by the target
via can_vec_perm_const_p.
On riscv we have a generic fallback for permutations that is more costly than
simpler permutations which, of course, returns true when asked whether a
certain permutation is supported. I understand that's the way most targets
handle it.
The match pattern above causes a (GCC 15) regression in x264 because we replace
two simple permutations (both have a single source vector) with a complex one
that is more expensive.
We statically know, roughly, how expensive a certain permutation constant is
and in this case our costing would indicate that it's not profitable to merge
the permutations.
Would it be acceptable to add a cost parameter to can_vec_perm_const_p?
I realize the original intent was for this function to only return true if the
requested permutation is directly supported (as in by a single instruction) but
IMHO that's not how it is actually used nowadays.
