public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tnfchris at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/109072] [12/13 Regression] SLP costs for vec duplicate too high since g:4963079769c99c4073adfd799885410ad484cbbe Date: Thu, 09 Mar 2023 15:04:48 +0000 [thread overview] Message-ID: <bug-109072-4-f2LiRIdwYJ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109072-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109072 --- Comment #4 from Tamar Christina <tnfchris at gcc dot gnu.org> --- (In reply to rsandifo@gcc.gnu.org from comment #3) > (In reply to Tamar Christina from comment #2) > > I thought the SLP algorithm was bottom up and stores were > > already sinks? > Yeah, they are. But the point is that we're vectorising > the stores in isolation, with no knowledge of what happens > later. The reason the code here is particularly bad is > that the array is later loaded into a vector. But the > vectoriser doesn't know that. > Ah right, you meant use the loads as the seeds. yeah makes sense. > > Ah, guess there are two problems. > > > > 1. how did we end up with such poor scalar code, at least 5 instructions are > > unneeded (separate issue) > > 2. The costing of the above, I guess I'm still slightly confused how we got > > to that cost > The patch that introduce the regression uses an on-the-side costing > scheme for store sequences. If it thinks that the scalar code is > better, it manipulates the vector body cost so that the body is twice > as expensive as the scalar body. The prologue cost (1 for the > scalar_to_vec) is then added on top. Ah, that makes sense. > > If it's costing purely on latency than the two are equivalent no? if you > > take throughput into account the first would win, but the difference in > > costs is still a lot higher then I would have expected. > > > > In this case: > > > > node 0x4f45480 1 times scalar_to_vec costs 4 in prologue > > > > seems quite high, but I guess it doesn't know that there's no regfile > > transfer? > Which -mcpu/-mtune are you using? For generic it's 1 rather than 4 > (so that the vector cost is 9 rather than 12, although still > higher than the scalar cost). I was using neoverse-v1 which looks like matches neoverse-n2 in cost of 4, but neoverse-n1 has 6. that really seems excessive..
next prev parent reply other threads:[~2023-03-09 15:04 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-08 22:32 [Bug target/109072] New: " tnfchris at gcc dot gnu.org 2023-03-09 10:19 ` [Bug target/109072] " rguenth at gcc dot gnu.org 2023-03-09 14:13 ` rsandifo at gcc dot gnu.org 2023-03-09 14:30 ` tnfchris at gcc dot gnu.org 2023-03-09 14:46 ` rsandifo at gcc dot gnu.org 2023-03-09 15:04 ` tnfchris at gcc dot gnu.org [this message] 2023-03-09 16:22 ` rsandifo at gcc dot gnu.org 2023-03-09 17:35 ` rsandifo at gcc dot gnu.org 2023-03-10 7:40 ` rguenth at gcc dot gnu.org 2023-03-10 8:50 ` rsandifo at gcc dot gnu.org 2023-03-15 14:29 ` rguenth at gcc dot gnu.org 2023-03-28 11:35 ` cvs-commit at gcc dot gnu.org 2023-03-28 12:59 ` [Bug target/109072] [12 " rsandifo at gcc dot gnu.org 2023-04-03 8:58 ` cvs-commit at gcc dot gnu.org 2023-04-03 9:03 ` rsandifo 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-109072-4-f2LiRIdwYJ@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).