public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org>
To: gcc-cvs@gcc.gnu.org
Subject: [gcc r12-7194] df: Don't set bbs dirty because of debug insn moves [PR104459]
Date: Fri, 11 Feb 2022 10:24:13 +0000 (GMT)	[thread overview]
Message-ID: <20220211102413.A8A5B3858C20@sourceware.org> (raw)

https://gcc.gnu.org/g:18c8086d65f3d539e065ea7c97e3de6f3bbdf684

commit r12-7194-g18c8086d65f3d539e065ea7c97e3de6f3bbdf684
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Feb 11 11:21:24 2022 +0100

    df: Don't set bbs dirty because of debug insn moves [PR104459]
    
    As mentioned in the PR, we get -fcompare-debug failure, which is caused by
    cfg_layout_merge_blocks successfully merging two bbs where both bbs
    contained just CODE_LABEL, NOTE_INSN_BASIC_BLOCK and in the -g case both
    some debug insns at the end.  cfg_layout_merge_blocks calls
    update_bb_for_insn_chain which for the post-label insns in the second block
    (except for BARRIERs) calls df_insn_change_bb.  This function changes
    the bb of the insns and for notes just punts, but for other insns calls
    df_set_bb_dirty.  Now the problem is that because there were only debug
    insns and notes in the second block, df_set_bb_dirty is called on both
    only in the -g case and not with -g0.  df_set_bb_dirty these days
    sets both the BB_MODIFIED flag and marks the bb as dirty, and the former
    is what 6 spots in cfgcleanup.cc use in code-generation decisions,
    in this case
              may_thread |= (target->flags & BB_MODIFIED) != 0;
    in particular.  So, with -g may_thread is true while with -g0 it is not
    and we diverge from that point onwards.
    I've thought about introducing df_set_bb_dirty_nondebug that wouldn't
    set BB_MODIFIED but would mark the bb dirty, but then I went through
    history and found changes like:
    https://gcc.gnu.org/legacy-ml/gcc-patches/2010-10/msg00059.html
    so I've also tried just not calling df_set_bb_dirty for debug insns
    at all and it passed x86_64-linux and i686-linux
    --enable-checking=yes,rtl,extra,df bootstraps/regtests, so perhaps
    that works too.
    Now that I look at it again, if we don't need those from %d to %d messages
    for debug insns in the dump files, another way to fix it would be just to
    change the very first line in the hunk from
      if (!INSN_P (insn))
    to
      if (!DEBUG_INSN_P (insn))
    Though, df_set_bb_dirty_nondebug which will do everything but
    set bb->flags |= BB_MODIFIED is yet another option I can test.
    Perhaps even that PR42889 was solely about those 6 decisions in cfgcleanup
    (at that point it used df_get_bb_dirty) and not about actually the
    recomputation of some of the problems causing different code generations.
    
    2022-02-11  Jakub Jelinek  <jakub@redhat.com>
    
            PR rtl-optimization/104459
            * df-scan.cc (df_insn_change_bb): Don't call df_set_bb_dirty when
            moving DEBUG_INSNs between bbs.
    
            * gcc.dg/pr104459.c: New test.

Diff:
---
 gcc/df-scan.cc                  |  6 ++++--
 gcc/testsuite/gcc.dg/pr104459.c | 38 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/gcc/df-scan.cc b/gcc/df-scan.cc
index 5df70e95751..9b2375d561b 100644
--- a/gcc/df-scan.cc
+++ b/gcc/df-scan.cc
@@ -1769,13 +1769,15 @@ df_insn_change_bb (rtx_insn *insn, basic_block new_bb)
   if (!INSN_P (insn))
     return;
 
-  df_set_bb_dirty (new_bb);
+  if (!DEBUG_INSN_P (insn))
+    df_set_bb_dirty (new_bb);
   if (old_bb)
     {
       if (dump_file)
 	fprintf (dump_file, "  from %d to %d\n",
 		 old_bb->index, new_bb->index);
-      df_set_bb_dirty (old_bb);
+      if (!DEBUG_INSN_P (insn))
+	df_set_bb_dirty (old_bb);
     }
   else
     if (dump_file)
diff --git a/gcc/testsuite/gcc.dg/pr104459.c b/gcc/testsuite/gcc.dg/pr104459.c
new file mode 100644
index 00000000000..de8a643d9e2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr104459.c
@@ -0,0 +1,38 @@
+/* PR rtl-optimization/104459 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -funswitch-loops -fno-tree-dce -fcompare-debug -w" } */
+
+void
+foo (int x, int y)
+{
+  unsigned int a;
+
+  for (;;)
+    {
+      short int *p = (short int *) &x;
+      unsigned int q = 0;
+
+      a /= 2;
+      if (a)
+	{
+	  q -= y;
+	  while (q)
+	    ;
+	}
+
+      if (x)
+	{
+	  for (q = 0; q != 1; q += 2)
+	    {
+	      unsigned int n;
+
+	      n = *p ? 0 : q;
+	      y += n < 1;
+
+	      n = a || *p;
+	      if (n % x == 0)
+		y /= x;
+	    }
+	}
+    }
+}


                 reply	other threads:[~2022-02-11 10:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20220211102413.A8A5B3858C20@sourceware.org \
    --to=jakub@gcc.gnu.org \
    --cc=gcc-cvs@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).