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/113847] [14 Regression] 10% slowdown of 462.libquantum on AMD Ryzen 7700X and Ryzen 7900X Date: Mon, 12 Feb 2024 14:41:33 +0000 [thread overview] Message-ID: <bug-113847-4-W0mOQ5fasp@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113847-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113847 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hubicka at gcc dot gnu.org --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- Hmm, the important one is actually MEM[ptr + CST] vs MEM[ptr].component. But those are not semantically equivalent, even when the same TBAA type is in effect. _31 = MEM <int> [(struct quantum_reg *)reg_3(D)]; _33 = MEM <int> [(struct quantum_reg *)reg_3(D) + 8B]; _34 = MEM <struct quantum_reg_node *> [(struct quantum_reg *)reg_3(D) + 16B]; _35 = MEM <int *> [(struct quantum_reg *)reg_3(D) + 24B]; out = quantum_state_collapse.isra (pos_1(D), result_22, _31, _32, _33, _34, _35); [return slot optimization] this is from inlined quantum_state_collapse where IPA SRA is eventually applied producing the above. That we do produce those might hint at that we can't really assume the dynamic type quantum_reg is at offset 8 but that was the original intent. What we are left with is the special-case where typeof (MEM[ptr + CST]) == typeof (alias-pointed-to-type) (with CST == 0). For any other case what we know is only that the access MEM[ptr + CST] is to somewhere inside an object of dynamic type quantum_reg? I'm not sure that's not less than we make use of in the alias-oracle, esp. aliasing_component_refs_walk and friends? We might be fine in practice for "bare" MEM_REFs like the above, but if we ever fold only part of the access path into the constant offset funny things may happen? So I think IPA SRA does wrong here (and maybe GCC in other places as well), possibly only pessimizing and possibly creating latent wrong-code. Note quantum_state_collapse has reg$size_62 = reg.size; reg$node_75 = reg.node; ... pre-IPA. Honza, any opinion?
next prev parent reply other threads:[~2024-02-12 14:41 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-02-09 9:24 [Bug target/113847] New: " fkastl at suse dot cz 2024-02-09 11:13 ` [Bug target/113847] " rguenth at gcc dot gnu.org 2024-02-10 17:04 ` fkastl at suse dot cz 2024-02-12 9:45 ` rguenth at gcc dot gnu.org 2024-02-12 13:18 ` rguenth at gcc dot gnu.org 2024-02-12 14:41 ` rguenth at gcc dot gnu.org [this message] 2024-02-12 14:43 ` rguenth at gcc dot gnu.org 2024-02-12 15:30 ` jamborm at gcc dot gnu.org 2024-03-07 20:40 ` law at gcc dot gnu.org 2024-05-07 7:45 ` [Bug target/113847] [14/15 " 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-113847-4-W0mOQ5fasp@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).