https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andreas Krebbel from comment #3)
> tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits
> VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN.
>
> What is the expectation wrt the meaning of hi/lo in RTL standard names? I
> couldn't find it clearly documented for this either. Well, for things like
> 'smulm3_highpart' we say it is about the 'most significant half' but I don't
> see anything for the vector hi/lo.
It would be nice to clarify this indeed. Like for ppc64le with "big-endian"
vector ops the only chance is to have the target emulate litte-endian
vector ops given the 1:1 match on BYTES_BIG_ENDIAN.
Note in supportable_widening_operation we also swap
case VEC_WIDEN_MULT_EVEN_EXPR:
/* Support the recursion induced just above. */
c1 = VEC_WIDEN_MULT_EVEN_EXPR;
c2 = VEC_WIDEN_MULT_ODD_EXPR;
break;
and I wonder if we can build a wrong-code testcase from that (unless even/odd
interpretation also depends on BYTES_BIG_ENDIAN). s390 does seem to implement
those at least.
