public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/101523] Huge number of combine attempts
Date: Fri, 22 Mar 2024 09:41:05 +0000	[thread overview]
Message-ID: <bug-101523-4-ikvkQwiF67@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-101523-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523

--- Comment #43 from Richard Biener <rguenth at gcc dot gnu.org> ---
The interesting bit is that there are only 12026 overall loglinks, the
number of combine attempts is way higher than that would suggest also
given the few successful combinations.  So something is odd here.

There's one interesting machinery in try_combine through added_links_insn
and added_notes_insn we can end up re-processing a large swat of insns
(even though we should need to only re-process the link target insns, not
all insns inbetween).  There might be the opportunity, for the "reprocessing",
to use a worklist instead of resetting the insn walk.

I added statistics to note the "distance" we travel there by taking
DF_INSN_LUID (ret) - DF_INSN_LUID (added_{notes,links}_insn) as that.
This shows 48 such jumps with seemingly large distances:

305 combine "restart earlier == 143" 3
305 combine "restart earlier == 254" 1
305 combine "restart earlier == 684" 1
305 combine "restart earlier == 726" 1
305 combine "restart earlier == 777" 1
305 combine "restart earlier == 1158" 1
305 combine "restart earlier == 1421" 1
305 combine "restart earlier == 2073" 1
305 combine "restart earlier == 2130" 1
...
305 combine "restart earlier == 49717" 1
305 combine "restart earlier == 49763" 1
305 combine "restart earlier == 49866" 1
305 combine "restart earlier == 50010" 1
305 combine "restart earlier == 50286" 1
305 combine "restart earlier == 50754" 1
305 combine "restart earlier == 50809" 1

killing this feature doesn't improve things to -O1 levels though so it's
more likely the fact that we also do

  rtx_insn *ret = newi2pat ? i2 : i3;

thus re-start at i2 when we altered i2.  We re-start through this 6910
times.  Always re-starting at i3 helps a lot and gets us -O1 performance
back.  From comment#1 it suggests that newi2pat might in fact be equal
to the old, so I tried to count how many times this happens with a stupid

diff --git a/gcc/combine.cc b/gcc/combine.cc
index a4479f8d836..acd176d3185 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4435,6 +4435,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
          propagate_for_debug (i2, last_combined_insn, i2dest, i2src,
                               this_basic_block);
        INSN_CODE (i2) = i2_code_number;
+       if (rtx_equal_p (PATTERN (i2), newi2pat))
+         statistics_counter_event (cfun, "equal newi2pat", 1);
        PATTERN (i2) = newi2pat;
       }
     else

and indeed this shows this to be the case 9211 times.

The following improves compile-time to 20s and 460MB memory use.  In general
the algorithmic deficiency with the "restarting" remains and a proper fix
is to use a worklist for those that you'd drain before advancing in the
instruction chain (so not have a single 'ret' insn to reprocess but add
to the worklist).

I'm not sure whether identifying a not changed "new" i2 can be done better.
I'll leave it all to Segher of course - he'll be fastest to produce something
he likes.

diff --git a/gcc/combine.cc b/gcc/combine.cc
index a4479f8d836..0c61dcedaa1 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4276,6 +4276,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx
_insn *i0,
        }
     }

+  bool newi2pat_not_new = false;
   {
     rtx i3notes, i2notes, i1notes = 0, i0notes = 0;
     struct insn_link *i3links, *i2links, *i1links = 0, *i0links = 0;
@@ -4435,6 +4436,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
          propagate_for_debug (i2, last_combined_insn, i2dest, i2src,
                               this_basic_block);
        INSN_CODE (i2) = i2_code_number;
+       if (rtx_equal_p (PATTERN (i2), newi2pat))
+         newi2pat_not_new = true;
        PATTERN (i2) = newi2pat;
       }
     else
@@ -4752,7 +4755,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
   combine_successes++;
   undo_commit ();

-  rtx_insn *ret = newi2pat ? i2 : i3;
+  rtx_insn *ret = newi2pat && !newi2pat_not_new ? i2 : i3;
   if (added_links_insn && DF_INSN_LUID (added_links_insn) < DF_INSN_LUID
(ret))
     ret = added_links_insn;
   if (added_notes_insn && DF_INSN_LUID (added_notes_insn) < DF_INSN_LUID
(ret))

  parent reply	other threads:[~2024-03-22  9:41 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20  9:35 [Bug rtl-optimization/101523] New: " krebbel at gcc dot gnu.org
2021-07-20  9:41 ` [Bug rtl-optimization/101523] " krebbel at gcc dot gnu.org
2021-07-20  9:42 ` krebbel at gcc dot gnu.org
2021-07-20 21:27 ` segher at gcc dot gnu.org
2024-02-24  5:45 ` krebbel at gcc dot gnu.org
2024-02-25 10:53 ` segher at gcc dot gnu.org
2024-02-25 15:06 ` segher at gcc dot gnu.org
2024-03-02 18:43 ` sarah.kriesch at opensuse dot org
2024-03-02 21:04 ` sjames at gcc dot gnu.org
2024-03-03 19:32 ` segher at gcc dot gnu.org
2024-03-04  8:18 ` krebbel at gcc dot gnu.org
2024-03-04 16:31 ` segher at gcc dot gnu.org
2024-03-04 16:49 ` sarah.kriesch at opensuse dot org
2024-03-04 21:26 ` segher at gcc dot gnu.org
2024-03-05  7:31 ` krebbel at gcc dot gnu.org
2024-03-05 10:36 ` sarah.kriesch at opensuse dot org
2024-03-06 22:49 ` segher at gcc dot gnu.org
2024-03-06 22:53 ` segher at gcc dot gnu.org
2024-03-06 23:15 ` pinskia at gcc dot gnu.org
2024-03-07  9:26 ` krebbel at gcc dot gnu.org
2024-03-07  9:28 ` krebbel at gcc dot gnu.org
2024-03-07  9:34 ` krebbel at gcc dot gnu.org
2024-03-07 15:51 ` krebbel at gcc dot gnu.org
2024-03-07 15:52 ` krebbel at gcc dot gnu.org
2024-03-07 16:11 ` segher at gcc dot gnu.org
2024-03-07 16:19 ` segher at gcc dot gnu.org
2024-03-07 16:53 ` pinskia at gcc dot gnu.org
2024-03-07 16:57 ` pinskia at gcc dot gnu.org
2024-03-07 18:15 ` segher at gcc dot gnu.org
2024-03-07 19:42 ` segher at gcc dot gnu.org
2024-03-07 19:45 ` jakub at gcc dot gnu.org
2024-03-07 20:10 ` segher at gcc dot gnu.org
2024-03-07 20:17 ` krebbel at gcc dot gnu.org
2024-03-07 20:53 ` krebbel at gcc dot gnu.org
2024-03-20 11:53 ` [Bug target/101523] " rguenth at gcc dot gnu.org
2024-03-21  7:56 ` segher at gcc dot gnu.org
2024-03-21  8:15 ` rguenth at gcc dot gnu.org
2024-03-21  8:27 ` rguenth at gcc dot gnu.org
2024-03-21 12:57 ` segher at gcc dot gnu.org
2024-03-21 12:58 ` segher at gcc dot gnu.org
2024-03-21 13:15 ` rguenth at gcc dot gnu.org
2024-03-21 13:22 ` rguenth at gcc dot gnu.org
2024-03-22  8:07 ` rguenth at gcc dot gnu.org
2024-03-22  9:41 ` rguenth at gcc dot gnu.org [this message]
2024-03-22  9:42 ` sjames at gcc dot gnu.org
2024-03-22  9:42 ` sjames at gcc dot gnu.org
2024-03-22  9:52 ` rguenth at gcc dot gnu.org
2024-03-22 12:17 ` rguenth at gcc dot gnu.org
2024-03-22 12:38 ` rguenth at gcc dot gnu.org
2024-03-27 14:35 ` sarah.kriesch at opensuse dot org
2024-03-27 16:10 ` [Bug rtl-optimization/101523] " cvs-commit at gcc dot gnu.org
2024-03-27 16:53 ` segher at gcc dot gnu.org
2024-03-27 16:55 ` segher at gcc dot gnu.org
2024-04-03 10:58 ` rguenth at gcc dot gnu.org
2024-04-05 11:48 ` segher at gcc dot gnu.org
2024-04-05 12:20 ` rguenth at gcc dot gnu.org
2024-04-10  6:02 ` rguenth at gcc dot gnu.org
2024-04-10 15:51 ` segher at gcc dot gnu.org
2024-04-10 15:57 ` jakub at gcc dot gnu.org
2024-04-10 17:03 ` rguenth at gcc dot gnu.org
2024-04-10 17:45 ` sarah.kriesch at opensuse dot org
2024-05-04  6:00 ` segher at gcc dot gnu.org
2024-05-04 13:14 ` sarah.kriesch at opensuse dot org
2024-05-04 17:30 ` segher at gcc dot gnu.org
2024-05-06  9:21 ` rguenther at suse dot de
2024-05-06  9:40 ` segher at kernel dot crashing.org
2024-05-06  9:42 ` segher at gcc dot gnu.org
2024-05-06  9:46 ` rguenth at gcc dot gnu.org

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-101523-4-ikvkQwiF67@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).