From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 08CB7385840A; Mon, 14 Feb 2022 09:32:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08CB7385840A From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104515] [11/12 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse. Date: Mon, 14 Feb 2022 09:32:04 +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: 11.0 X-Bugzilla-Keywords: missed-optimization, 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: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on everconfirmed priority component short_desc cc bug_status target_milestone 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: Mon, 14 Feb 2022 09:32:05 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104515 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed| |2022-02-14 Ever confirmed|0 |1 Priority|P3 |P2 Component|rtl-optimization |tree-optimization Summary|trivially-destructible |[11/12 Regression] |destructors interfere with |trivially-destructible |loop optimization - maybe |destructors interfere with |related to lifetime-dse. |loop optimization - maybe | |related to lifetime-dse. CC| |jakub at gcc dot gnu.org, | |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.3 --- Comment #1 from Richard Biener --- Confirmed. The issue is that store motion of v_7(D)->end cannot be perform= ed on [local count: 955630225]: # i_13 =3D PHI _1 =3D v_7(D)->end; _2 =3D _1 + 18446744073709551612; v_7(D)->end =3D _2; MEM[(T *)_1 + -4B] =3D{v} {CLOBBER}; // <- inserted by -flifetime-dse i_10 =3D i_13 + 1; if (n_6(D) > i_10) goto ; [89.00%] else goto ; [11.00%] [local count: 850510901]: goto ; [100.00%] With GCC 10 we didn't have this particular CLOBBER and at least in GCC 10 t= he first testcase was properly optimized. Note there's a dependence on the value of v_7(D)->end for the clobber so the clobber itself cannot be moved out of the loop. So the only option here would be to drop it if it enables store-motion. We remove all *ssaname_N =3D{v} {CLOBBER} stmts during the fold-all-builtins pass but that's very late, in particular _after_ the last CDDCE. I suspect that instead of NEXT_PASS (pass_dse); NEXT_PASS (pass_cd_dce, true /* update_address_taken_p */); /* After late CD DCE we rewrite no longer addressed locals into SSA form if possible. */ NEXT_PASS (pass_forwprop); NEXT_PASS (pass_phiopt, false /* early_p */); NEXT_PASS (pass_fold_builtins); we might consider doing FAB (or the CLOBBER removal part) after the last DSE (or simply direct that last DSE pass do that, with some pass specific flag). Note that's still too late since we need store-motion here. Doing the *ssaname_N =3D{v} {CLOBBER} clobber removal after the _first_ DSE after IPA inlining would be another option. Likewise of course removing it as part of SM as said above. I can see how easy it is to do from store-motion.=