From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 0D3093858407; Thu,  4 Aug 2022 09:17:18 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D3093858407
From: "rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106069] [12/13 Regression] wrong code with -O
 -fno-tree-forwprop -maltivec on ppc64le
Date: Thu, 04 Aug 2022 09:17:18 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rsandifo at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106069-4-gVmCFRI8EN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106069-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106069-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2022 09:17:19 -0000

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

--- Comment #29 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.o=
rg> ---
(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 regist=
er.
>=20
> I agree with everything here, except calling this "most significant".  Th=
at
> 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 =E2=80=9Cmost significant end of the vector re=
gister
if the vector register is viewed as a single integer=E2=80=9D (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.=