public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-54369-4-63KcTf5IfG@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-54369-4@http.gcc.gnu.org/bugzilla/>

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54369

--- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 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


  parent reply	other threads:[~2012-08-31 14:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-24 18:17 [Bug rtl-optimization/54369] New: " chaoyingfu at gcc dot gnu.org
2012-08-29 22:43 ` [Bug rtl-optimization/54369] " ebotcazou at gcc dot gnu.org
2012-08-31  0:31 ` sje at gcc dot gnu.org
2012-08-31  0:39 ` chaoyingfu at gcc dot gnu.org
2012-08-31 14:21 ` ebotcazou at gcc dot gnu.org [this message]
2012-08-31 18:17 ` sje at gcc dot gnu.org
2012-08-31 18:56 ` ebotcazou at gcc dot gnu.org
2012-09-01  8:17 ` rdsandiford at googlemail dot com
2012-09-01  9:22 ` ebotcazou at gcc dot gnu.org
2012-09-01  9:42 ` rdsandiford at googlemail dot com
2012-09-01 15:13 ` [Bug rtl-optimization/54369] delayed-branch pass " ebotcazou at gcc dot gnu.org
2012-09-02 10:37 ` ebotcazou at gcc dot gnu.org
2012-09-02 10:38 ` ebotcazou at gcc dot gnu.org
2012-09-02 10:39 ` ebotcazou at gcc dot gnu.org
2012-09-02 10:39 ` ebotcazou at gcc dot gnu.org
2012-09-02 10:39 ` ebotcazou at gcc dot gnu.org
2012-09-02 10:48 ` ebotcazou at gcc dot gnu.org
2014-02-16 10:00 ` jackie.rosen at hushmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-54369-4-63KcTf5IfG@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).