https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
But all GIMPLE operates on "GIMPLE lane order" so this is a defect in how the
backend handles those tree codes at expansion time?
You'll find no mention of BYTES_BIG_ENDIAN in the vectorizer (ok, you find
exactly one - but other UNPACK_LO/HI uses in other places).
>From looking at tree-vect-generic.c VEC_UNPACK_{,FIX_TRUNC,FLOAT}_{LO,HI}_EXPR
are subject to this while supportable_widening_operation adds some more
LO,HI but also one EVEN,ODD case.
(Ab-)using BYTES_BIG_ENDIAN is also a bit odd, if we insist on preserving
this endian dependency on GIMPLE it should be a VECTOR_LANES_BIG_ENDIAN
or so. But it doesn't seem to be consistently implemented.
The patch looks "obvious" if the semantics are dependent on BYTES_BIG_ENDIAN
but I see that nowhere documented and it's contrary to my expectation of
GIMPLE semantics (GIMPLE semantics assumes memory order).
