From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9D58D3858C2A; Mon, 23 Oct 2023 09:48:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D58D3858C2A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1698054531; bh=Ha1RyWP+0fdBfsskPYsePFhuhgU7CMSFObCq/cpF4xo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MxlwUKx/q0x/8wgGvo5Ogy4LEtQuFrTBPkJXzynupDRt1zlMwz69AcBYhDiKfdYco AEYdS4xxCzIjYALzoZmyimem/3sJrmVrd71lIpw67dRuTNsbVkwuwHufp+v0rEScx2 5OHfKXzZwLQFOrH8pLCzKjLW6zlgb3P0nOdwKESk= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3 Date: Mon, 23 Oct 2023 09:48:47 +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: 13.2.0 X-Bugzilla-Keywords: needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D111591 --- Comment #27 from Richard Biener --- (In reply to Kewen Lin from comment #26) > (In reply to Richard Biener from comment #25) > > (In reply to Kewen Lin from comment #24) [...] > > Ah, probably the alias-set is determined from the unmangled ref ... > >=20 > > > Aggressively further hacking with attrs.alias =3D > > > 0 can make it pass. Can we make an new alias set for each partition? = then > > > all involved decls in the same partition is aliased. For a particular > > > involved decl, it's aliased to the previous ones and the new ones in = its own > > > partitions. > >=20 > > hmm, no - this won't work. In fact even attrs.alias =3D 0 will probably > > not work reliably since we can coalesce variables that escape and thus > > the above will only alter accesses via the original decls but not any > > accesses done via pointers. So indeed any alias-set mangling is pointl= ess > > here. > >=20 > > Consider > >=20 > > { > > A x; > > int * volatile p =3D &x; > > *p =3D 1; > > .. =3D *p; > > } > > { > > B y; > > float * volatile q =3D &y; > > *q =3D 1; > > .. =3D *q; > > } > >=20 > > if we coalesce x and y then we are not rewriting any accesses > > but obviously the accesses still need to conflict - but the > > indirect accesses will have their original non-conflicting alias-set > > and thus the scheduler would be free to move the store to *q across > > the load from *p (the "trick" would be to make an incentive to do so > > of course). >=20 > Thanks for the clarification! Is it possible to update the alias set for = the > indirect accesses as well? since we know the address is originally taken > from one coalesced decl (also update its propagated ones). I suppose we could record a bitmap of all decls participating in any coalescing, check whether a MEM could possibly refer to any of them via the points-to API and then force alias-set zero for those. We could also try to do sophisticated analysis to make assigning a new alias-set for each coalesce group work, merging groups when there's indirect accesses that could alias a member of more than a single group. Note that the other bugs linked perform wrong coalescings (for things which have overlapping life time) while this one performs coalescing wrong (not properly adjusting accesses so they later conflict).=