From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F11633858D28; Tue, 23 Nov 2021 23:18:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F11633858D28 From: "law at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/103388] [12 Regression] missed optimization for dead code elimination at -O3 (vs. -O2) Date: Tue, 23 Nov 2021 23:18:11 +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: X-Bugzilla-Severity: normal X-Bugzilla-Who: law at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: law at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 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: Tue, 23 Nov 2021 23:18:12 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103388 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.= org --- Comment #3 from Jeffrey A. Law --- So to fix this right we'd need to duplicate some of the logic in tree-ssa-threadupdate.c. Conceptually for block B where one or more predecessors thread to target T, you make a single copy B', and redirect *a= ll* the relevant predecessors to B'. In addition to allowing more aggressive threading, it would also reduce codesize since currently we'll end up with multiple copies of B'. We have optimizers that are supposed to clean that up, but I've never seen them do a particularly good job. This isn't likely to land in gcc-12. An interim approach might be to go ahead and register the thread and only reject it for size later if we're going to end up with multiple copies. Af= ter all this is a cost analysis question and we don't know until all the paths = are registered if it's profitable or not. Anyway, it should probably be assigned to me. Not sure if I'll get to the interim approach or not for gcc-12. I'll have to poke around a bit.=