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: Thu, 21 Mar 2024 08:15:43 +0000 [thread overview] Message-ID: <bug-101523-4-O8HE25kFuz@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 #36 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Segher Boessenkool from comment #35) > (In reply to Richard Biener from comment #34) > > The change itself looks reasonable given costs, though maybe 2 -> 2 > > combinations should not trigger when the cost remains the same? In > > this case it definitely doesn't look profitable, does it? Well, > > in theory it might hide latency and the 2nd instruction can issue > > at the same time as the first. > > No, it definitely should be done. As I showed back then, it costs less than > 1% > extra compile time on *any platform* on average, and it reduced code size by > 1%-2% > everywhere. > > It also cannot get stuck, any combination is attempted only once, any > combination > that succeeds eats up a loglink. It is finite, (almost) linear in fact. So the slowness for the testcase comes from failed attempts. > Any backend is free to say certain insns shouldn't combine at all. This will > lead to reduced performance though. > > - ~ - ~ - > > Something that is the real complaint here: it seems we do not GC often > enough, > only after processing a BB (or EBB)? That adds up for artificial code like > this, sure. For memory use if you know combine doesn't have "dangling" links to GC memory you can call ggc_collect at any point you like. Or, when you create throw-away RTL, ggc_free it explicitly (yeah, that only frees the "toplevel"). > And the "param to give an upper limit to how many combination attempts are > done > (per BB)" offer is on the table still, too. I don't think it would ever be > useful (if you want your code to compile faster just write better code!), > but :-) Well, while you say the number of successful combinations is linear the number of combine attempts appearantly isn't (well, of course, if we ever combine from multi-use defs). So yeah, a param might be useful here but instead of some constant limit on the number of combine attempts per function or per BB it might make sense to instead limit it on the number of DEFs? I understand we work on the uses so it'll be a bit hard to apply this in a way to, say, combine a DEF only with the N nearest uses (but not any ones farther out), and maintaining such a count per DEF would cost. So more practical might be to limit the number of attempts to combine into an (unchanged?) insns? Basically I would hope with a hard limit in place we'd not stop after the first half of a BB leaving trivial combinations in the second half unhandled but instead somehow throttle the "expensive" cases?
next prev parent reply other threads:[~2024-03-21 8:15 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 [this message] 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 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-O8HE25kFuz@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).