From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 95F563858408; Wed, 5 Jul 2023 10:57:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 95F563858408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1688554656; bh=9TmBk5/XLlm8IQ1wHUWUkiMd0hRAWhwL3HDXXD3WotE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lNjDsVZdi1/ua/Bx9FscFimPptrMLFXolLwdtHooOSBiik9iVQY2jQN+uLFjEAAAi S6NdLUmFMPol38/JHfZopC04AWdL9FEb2SoHaatPnc9aAC10d608ue459OS2VFhM7k QsAuOmDRNlTkAjYNxMYstVWHGuVX5BFbijLxEHwg= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/110515] [12/13/14 Regression] llvm-15.0.7 possibly invalid code on -O3 Date: Wed, 05 Jul 2023 10:57:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: alias, needs-bisection, wrong-code 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: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on bug_status everconfirmed assigned_to 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=3D110515 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2023-07-05 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot = gnu.org --- Comment #8 from Richard Biener --- (In reply to Sergei Trofimovich from comment #7) > (In reply to Richard Biener from comment #6) > > Turning off PRE also allows it to pass but I guess it's the same as wit= h SRA. > > -fno-strict-aliasing also helps, -fno-ipa-modref doesn't. I suspect > > bisection > > isn't going to help much, but maybe it points to a small set of changes= on > > the testcase itself. >=20 > Bisect landed on the r12-4790-g4b3a325f07aceb : >=20 > $ git bisect bad > 4b3a325f07acebf47e82de227ce1d5ba62f5bcae is the first bad commit > commit 4b3a325f07acebf47e82de227ce1d5ba62f5bcae > Author: Aldy Hernandez > Date: Thu Oct 28 15:35:21 2021 +0200 >=20 > Remove VRP threader passes in exchange for better threading pre-VRP. After this commit the bug still appears with -fdisable-tree-threadfull1 -fdisable-tree-threadfull2 and before the commit it appears with -fdisable-tree-vrp-thread1 -fdisable-tree-vrp-thread2 so it seems removing the threading passes after VRP exposes the issue. Looking at the source and the IL of grow() I think the issue is that loop invariant motion hoists _134 and _104 in _31 =3D Visited.Small; if (_31 !=3D 0) goto ; [50.00%] else goto ; [50.00%] [local count: 621159684]: _145 =3D MEM[(struct LargeRep *)&Visited + 8B].Slots; _34 =3D MEM[(struct LargeRep *)&Visited + 8B].Capacity; if (_34 !=3D 0) goto ; [0.00%] else goto ; [0.00%] [local count: 955630290]: # _134 =3D PHI <_34(4), 2(3)> # _104 =3D PHI <_145(4), &Visited.u.i(3)> [local count: 8933211531]: out of the inner first loop which I think is OK even though it makes the _145 and _34 reads unconditional. Then PRE hoists those further, but correctly identifying Visited.Small =3D 0; _94 =3D operator new [] (1024); Visited.u.o.Slots =3D _94; Visited.u.o.Capacity =3D 128; as where they change. Interestingly I can disable (almost) all passes after tree PRE and still get the failure. One change PRE does is - _18 =3D MEM[(struct V *)&Visited + 8B].v; - if (_18 !=3D 790526) - goto ; [66.00%] + _196 =3D (long unsigned int) prephitmp_173; + if (prephitmp_173 !=3D 790526B) + goto ; [66.00%] where it replaces the read with _94 (or EmptyKey as from entry). That's phishy. It's the !=3D EmptyKey check in grow when copying inline slots into temporary storage. So on 4b3a325f07acebf47e82de227ce1d5ba62f5bcae^ (one before the bisected rev.) it fails with g++ t.C -O2 -fdisable-tree-vrp-thread1 -fdump-tree-pre-details -fdump-tree-= all -fno-tree-tail-merge -fno-tree-vectorize -fno-tree-loop-optimize -fdisable-tree-sink1 -fdisable-tree-dse3 -fdisable-tree-dce4 -fdisable-tree-fre5 -fdisable-tree-dom3 -fdisable-tree-thread3 -fdisable-tree-thread4 -fdisable-tree-vrp2 -fdisable-tree-vrp-thread2 -fdisable-tree-dse5 -fdisable-tree-cddce3 -fdisable-tree-sink2 -fdisable-tree-store-merging -fdisable-tree-dce7 -fdisable-tree-modref2 -fdisable-tree-local-pure-const2 -fdisable-tree-split-paths -fdisable-tree-= ccp4 -fdisable-tree-slsr -fdisable-tree-reassoc2 -fdisable-tree-switchlower1 -fdisable-tree-forwprop4 -fdisable-tree-phiopt4 -fno-gcse -fno-dse -fno-gcse-after-reload -fdbg-cnt=3Dtreepre_insert:1-3:16-21:24-24 -fno-tree-partial-pre So it goes that the above load is CSEd to the LIM inserted load plus a conversion from pointer to unsigned long: Value numbering stmt =3D _145 =3D MEM[(struct LargeRep *)&Visited + 8B].Slo= ts; Setting value number of _145 to _145 (changed) ... Value numbering stmt =3D _18 =3D MEM[(struct V *)&Visited + 8B].v; Inserting name _47 for expression (long unsigned int) _145 Setting value number of _18 to _47 (changed) we seem to disregard TBAA when CSEing two loads without an intervening possibly aliasing stores. But this then causes PRE (well, that's a long-long-standing issue...) to record the later load to EXP_GEN as exp_gen[25] :=3D { {component_ref,mem_ref<8B>,addr_expr<&Visited>}@.MEM_129 (0084), _18 (0031) } so to PRE it appears that we do _18 =3D (long unsigned int) MEM[(struct LargeRep *)&Visited + 8B].Slots; and thus the wrong ref is used for disambiguation which means we disambiguate against TheSlot_172->v =3D Item$f_20; which eventually stores to that slot. *sigh*=