https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #23 from Kewen Lin <linkw at gcc dot gnu.org> ---
> Ideally we would avoid semantic difference of RTL depending on the target.
> If that's not avoidable there should be target macros/hooks that specify
> the desired semantics.
Not sure, IMHO it seems it doesn't depend on the target but on endianness
(BYTES_BIG_ENDIAN)? Segher and Mike may have more insights on this.
> I assume the semantic difference is in
> vec_concat behavior but that's just documented as
>
> @findex vec_concat
> @item (vec_concat:@var{m} @var{x1} @var{x2})
> Describes a vector concat operation. The result is a concatenation of the
> vectors or scalars @var{x1} and @var{x2}; its length is the sum of the
> lengths of the two inputs.
>
> which is a bit unspecific. To me it implies that
> vec_select of a single lane N of the concat result can be distributed
> to the operands of the vec_concat in the obvious way (if N >=
> GET_MODE_NUNITS (x1) subtract GET_MODE_NUNITS and use x2)
Yeah, the documentation isn't clear, neither for vec_select. I guess vec_select
also matters here, the indexes for vec_select would have the LE ordering like
subreg byte offset on LE?
