[Bug target/68275] bb-slp-38 FAILs on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2015-11-11 00:00:00 |2021-9-2
--- Comment #5 from Andrew Pinski ---
arm_evpc_neon_vtbl (struct expand_vec_perm_d *d)
{
rtx rperm[MAX_VECT_LEN], sel;
machine_mode vmode = d->vmode;
unsigned int i, nelt = d->perm.length ();
/* TODO: ARM's VTBL indexing is little-endian. In order to handle GCC's
numbering of elements for big-endian, we must reverse the order. */
if (BYTES_BIG_ENDIAN)
return false;
[Bug target/68275] bb-slp-38 FAILs on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-11-11
Component|tree-optimization |target
Version|unknown |6.0
Ever confirmed|0 |1
--- Comment #4 from Richard Biener ---
/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/testsuite/gcc.dg/vect/bb-slp-38.c:23:3:
note: Load permutation 0 0 3 3
+/home/christophe.lyon/src/GCC/sources/gcc-fsf/trunk-for-crontab/gcc/testsuite/gcc.dg/vect/bb-slp-38.c:23:3:
note: unsupported vect permute { 0 0 3 3 }
so it's a similar reason. BE vectorization being cripled but still being
effective target vect_perm.
Looks like BE supports vectorizing the permutation { 0 0 } so we get the
first half of the BB vectorized with v2si vectors. vec_perm_cost just
dispatches to arm_expand_vec_perm_const which dispatches to helpers where
most of them have sth like
/* TODO: Handle GCC's numbering of elements for big-endian. */
if (BYTES_BIG_ENDIAN)
return false;
Confirmed. Backend bug IMHO (or testsuite one in that vect_perm is too generic
to capture the half-way state armeb is in.
What's so difficult to fix your target? It looks like there is really no
interest in it given those TODOs.
