From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3E1863858D1E; Thu, 10 Nov 2022 15:13:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3E1863858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668093203; bh=phduIX7qNp65Rsw/5ZB4GfnAchpVd4XyumcM+BFDkKE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=KkQ4wYhQkJ2mHVJ/V0ib8gQi9jU4tDm8BZp3BoDZUDVtzrEwsdM5je1HywA5dW06R IEWg71UiXU1dQKu//GSUsU/wP8l5tmYtkW3bdKsgb+ZCvH65MUfWL3LbX382i+abps Tlbybk+K4jRdfuMNP53nY65A/7FVJl28f677aSko= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops Date: Thu, 10 Nov 2022 15:13:05 +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: 8.0.1 X-Bugzilla-Keywords: missed-optimization 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: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84646 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fxue at gcc dot gnu.org --- Comment #11 from Richard Biener --- So with the last patch I have we eliminate the empty loop that's created by threading but the result is still (or now "again") the imperfect result mentioned in the original description - we fail to exit the outer loop. The main thing the patches in this series did is restore the threading that did the inner loop optimization and the required cleanup. I don't think that this particular thread itself can be enhanced to cover exiting the outer loop. In particular we ask to thread across the loop exit but we know nothing about that apart from the code in the remaining iterations having no side-effect. I'm not sure which kind of pass/transform would be suited to cover this in a more general way than jump threading does. We do have loop splitting which handles this as part of splitting on a "semi-invariant" condition but that fails quite early because it's if (running) { if (other) running =3D 0; } and we don't seem to handle the conditional "semi-invariant" condition case.=