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: Wed, 20 Mar 2024 11:53:16 +0000 [thread overview] Message-ID: <bug-101523-4-7CZpz6ZtuE@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 #34 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andreas Krebbel from comment #1) > This appears to be triggered by try_combine unnecessarily setting back the > position by returning the i2 insn. > > When 866 is inserted into 973 866 still needs to be kept around for other > users. So try_combine first merges the two sets into a parallel and > immediately notices that this can't be recognized. Because none of the sets > is a trivial move it is split again into two separate insns. Although the > new i2 pattern exactly matches the input i2 combine considers this to be a > new insn and triggers all the scanning log link creation and eventually > returns it what let's the combine start all over at 866. > > Due to that combine tries many of the substitutions more than 400x. > > Trying 866 -> 973: > 866: r22393:DI=r22391:DI+r22392:DI > 973: r22499:DF=r22498:DF*[r22393:DI] > REG_DEAD r22498:DF > Failed to match this instruction: > (parallel [ > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) > ]) > Failed to match this instruction: > (parallel [ > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) > ]) > Successfully matched this instruction: > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) So this is "unchanged", do we re-combine into it? > Successfully matched this instruction: > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) This one is changed. > allowing combination of insns 866 and 973 > original costs 4 + 4 = 8 > replacement costs 4 + 4 = 8 > modifying insn i2 866: r22393:DI=r22391:DI+r22392:DI > deferring rescan insn with uid = 866. > modifying insn i3 973: r22499:DF=r22498:DF*[r22391:DI+r22392:DI] > REG_DEAD r22498:DF > deferring rescan insn with uid = 973. 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.
next prev parent reply other threads:[~2024-03-20 11:53 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 ` rguenth at gcc dot gnu.org [this message] 2024-03-21 7:56 ` [Bug target/101523] " 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 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-7CZpz6ZtuE@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).