From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B820F3858D39; Thu, 3 Mar 2022 18:04:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B820F3858D39 From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104754] gcc.dg/pr102892-1.c FAILs Date: Thu, 03 Mar 2022 18:04:08 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: missed-optimization, testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh 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: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status everconfirmed cf_reconfirmed_on cc 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 18:04:09 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104754 Aldy Hernandez changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed| |2022-03-03 CC| |amacleod at redhat dot com --- Comment #1 from Aldy Hernandez --- Confirmed on a cross to m68k-unknown-linux-gnu. Interestingly this may actually be a regression against GCC11, at least on = this target (and possibly the others mentioned though I haven't checked). The test verifies that there are no calls to foo(). On m68k the gate to fo= o() flows through here (threadfull2 dump right before vrp2): [local count: 715863673]: # ivtmp.9_23 =3D PHI bar (); _2 =3D (void *) ivtmp.9_23; _1 =3D MEM[(long int *)_2]; ivtmp.9_24 =3D ivtmp.9_23 + 4; if (_1 =3D=3D 1) goto ; [20.24%] else goto ; [79.76%] [local count: 144890806]: foo (); ivtmp.9_24 has been set previously in BB9 to: ivtmp.9_7 =3D (unsigned int) &b; VRP2 can't seem to do anything with the above sequence, since it can't figu= re out what _1 is. I suppose it could, since there is enough information to to get at "b" at -O3. On x86, where the test passes, we have the following before vrp2: [local count: 477266310]: # c_4 =3D PHI bar (); _15 =3D (sizetype) c_4; _17 =3D MEM[(long int *)&b + _15 * 8]; if (_17 =3D=3D 1) goto ; [20.24%] else goto ; [79.76%] [local count: 96598701]: foo (); c_29 =3D c_4 + 1; goto ; [100.00%] which vrp2 can happily optimize to: [local count: 477266310]: bar (); _17 =3D 0; if (_17 =3D=3D 1) goto ; [20.24%] else goto ; [79.76%] ... ... [local count: 96598701]: foo (); goto ; [100.00%] Thus leading to foo's demise by ccp4. I haven't dug deep, but this is likely due to the pointer equivalence track= ing we use in evrp/VRP2 not being able to see that this is all funny talk for b= []: ivtmp.9_7 =3D (unsigned int) &b; ... ... # ivtmp.9_23 =3D PHI _2 =3D (void *) ivtmp.9_23; _1 =3D MEM[(long int *)_2]; if (_1 =3D=3D 1) We have plans for a proper pointer range class for GCC13, though I wonder whether we'll be able to handle the above gymnastics. FWIW, the above transformation seems to be ivopts at play. Whereas on x86 we go from: [local count: 715863673]: # c_19 =3D PHI bar (); _1 =3D b[c_19][0]; if (_1 =3D=3D 1) to: [local count: 715863673]: # c_19 =3D PHI bar (); _23 =3D (sizetype) c_19; _1 =3D MEM[(long int *)&b + _23 * 8]; if (_1 =3D=3D 1) goto ; [20.24%] on m68k we transform the sequence to: [local count: 715863673]: # ivtmp.9_23 =3D PHI bar (); _2 =3D (void *) ivtmp.9_23; _1 =3D MEM[(long int *)_2]; ivtmp.9_24 =3D ivtmp.9_23 + 4; if (_1 =3D=3D 1) Perhaps someone with more target-foo can opine.=