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))
next prev 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: linkBe 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).