https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68275
Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> --- /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.