From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27242 invoked by alias); 31 Aug 2012 14:21:12 -0000 Received: (qmail 27233 invoked by uid 22791); 31 Aug 2012 14:21:10 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 31 Aug 2012 14:20:58 +0000 From: "ebotcazou at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions Date: Fri, 31 Aug 2012 14:21:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ebotcazou at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-08/txt/msg02071.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369 --- Comment #4 from Eric Botcazou 2012-08-31 14:20:03 UTC --- > I think I see where delete_related_insns is going wrong. We call it > with a JUMP instruction that we want to remove because we are just > jumping to the next instruction (a label) which we would get to anyway > without the jump, then after delete_related_insns removes the jump it > checks the label it was jumping to, and if it finds no uses it calls > delete_related_insns with that label. When delete_related_insns > is called with a label, it assumes it can remove all the code after > that label as unreachable. Only if there is a barrier just before the label though; now this barrier should have been removed one level earlier. The root cause of the problem is that MIPS runs its own version of the dbr pass and doesn't make sure that barriers are correctly placed for it, unlike other targets like SPARC. So the fix is: Index: config/mips/mips.c =================================================================== --- config/mips/mips.c (revision 184886) +++ config/mips/mips.c (working copy) @@ -15083,7 +15083,10 @@ mips_reorg (void) } if (optimize > 0 && flag_delayed_branch) - dbr_schedule (get_insns ()); + { + cleanup_barriers (); + dbr_schedule (get_insns ()); + } mips_reorg_process_insns (); if (!TARGET_MIPS16 && TARGET_EXPLICIT_RELOCS