[Bug target/68275] bb-slp-38 FAILs on armeb

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.