public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "palmer at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/114809] [RISC-V RVV] Counting elements might be simpler Date: Mon, 22 Apr 2024 20:24:46 +0000 [thread overview] Message-ID: <bug-114809-4-DrvY5HcXwS@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114809-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114809 palmer at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Keywords| |missed-optimization Ever confirmed|0 |1 CC| |palmer at gcc dot gnu.org Last reconfirmed| |2024-04-22 --- Comment #1 from palmer at gcc dot gnu.org --- Thanks. Sounds like there's really two issues here: a missed peephole and a more complex set of micro-architectural tradeoffs. The peephole seems like a pretty straight-forward missed optimization, if you've got a smaller reproducer it's probably worth filing another bug for it. We're right at the end of the GCC-14 release process and ended up with some last-minute breakages so stuff is pretty chaotic right now, having the bug will make it easier to avoid forgetting about this. The reduction looks way more complicated to me. Just thinking a bit as I'm watching the regressions run, I think there's a few options for generating the code here: * Do we accumulate into a vector and then reduce, or reduce and then accumulate? * Do we reduce via a sum-reduction or a popcnt? * Do we reconfigure to a wider type or handle the overflow? I think this will depend on the cost model for the hardware: we're essentially trading off operations of one flavor of op for another, and that's going to depend on how these ops perform. Your suggestion is essentially a reconfiguration vs reduction trade-off, which is probably going to be implementation-specific. Do you have a system that this code performs poorly on? If there's something concrete to target and we're not generating good code that's pretty actionable, otherwise I think this one is going to be hard to reason about for a bit.
next prev parent reply other threads:[~2024-04-22 20:24 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-04-22 17:10 [Bug target/114809] New: " wojciech_mula at poczta dot onet.pl 2024-04-22 20:24 ` palmer at gcc dot gnu.org [this message] 2024-04-22 21:11 ` [Bug target/114809] " andrew at sifive dot com 2024-04-22 21:59 ` pinskia at gcc dot gnu.org 2024-04-22 22:23 ` juzhe.zhong at rivai dot ai
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-114809-4-DrvY5HcXwS@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).