[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069

--- Comment #30 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to rsandifo@gcc.gnu.org from comment #29)
> (In reply to Segher Boessenkool from comment #28)
> > (In reply to rsandifo@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.