https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #30 from Richard Earnshaw <rearnsha at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #29) > (In reply to Segher Boessenkool from comment #28) > > (In reply to rsand...@gcc.gnu.org from comment #25) > > > - On big-endian targets, vector loads and stores are assumed to put the > > > first memory element at the most significant end of the vector register. > > > > I agree with everything here, except calling this "most significant". That > > just makes no sense for vectors. It is element 0, but that is not more > > significant than any other element :-) Vectors aren't integers. > Ah, yeah, I should have said “most significant end of the vector register > if the vector register is viewed as a single integer” (which is an important > difference). The point here was that: > > (a) by default, TI subregs of V4SI registers are assumed to be nops > (and vice versa) > > (b) consequently, TImode loads are assumed to perform the same operation > as V4SI loads > > So endianness assumptions for single integers carry over to like-sized > vector modes. On big-endian, the first element of the V4SI is assumed > to line up with the top 32 bits of a 128-bit integer. > > Although it's possible to force subregs not to be nops (via > targetm.can_change_mode_class), that only really affects changes > to specific hard register classes. The generic rules still apply > to the layout of pseudos. It's not just about when the vector is viewed as an integer. There's also the case when a vector of NxM is viewed as N/2xM*2 or vice versa, or even for other powers of two. We've tended to call the lane ordering 'little-endian' if the lower numbered lane is in the least significant bits of a wider element size, and 'big-endian' if it's in the most significant bits.
