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 969FC385780D; Mon, 25 Jul 2022 10:24:49 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 969FC385780D
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/106187] armhf: Miscompilation at O2 level (O0 / O1 are
 working)
Date: Mon, 25 Jul 2022 10:24:49 +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: 10.4.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106187-4-sEIHvILC00@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106187-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106187-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: Mon, 25 Jul 2022 10:24:49 -0000

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

--- Comment #38 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #37)
> (In reply to rguenther@suse.de from comment #36)
>=20
> > Note that the only thing we have to do is fix points-to info, the TBAA
> > info should be correct and OK even when objects share location, so ther=
e's
> > nothing we can do at RTL expansion time.
>=20
> I haven't really studied the way the TBAA code works before, so I may have
> missed something, but we clearly end up creating two MEMs for the same
> location with non-conflicting alias sets.  So perhaps the problem is when=
 we
> assign the alias set when we create the MEM (it's taken from the original
> type, without regard to the stack slot assignment).
>=20
> What would be in the TBAA code to prevent
>=20
> struct A
> {
>   int a[4];
> };
>=20
> struct B
> {
>   float b[4];
> };
>=20
> struct A x;
> struct B y;
>=20
> f ()
> {
>  struct A m;
>  struct B n;
>   ...
>  x =3D m;   // m dead
>  n =3D y;   // n born
>  ...
> }
>=20
> from moving these two assignments past each other at the RTL level if they
> shared the same stack slot?

There's a WAR dependence between those assignments.  Write-after-read is
not allowed to use TBAA in our memory model (likewise write-after-write),
only read-after-write is.

One side-effect of this is that "redundant stores" (redundant in terms of
that the second store does not change any bits in the memory location)
are not always "redundant" with respect to the memory model.  Currently
we have to preserve those, their effect is to change the effective type
of the memory location for downstream reads.

There's a (maybe too short) documentation about our TBAA memory model
in tree-ssa.texi at the very end.=