public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106585] RISC-V: Mis-optimized code gen for zbs Date: Fri, 28 Apr 2023 22:46:59 +0000 [thread overview] Message-ID: <bug-106585-4-WAzNMqeXb2@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-106585-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585 --- Comment #11 from Jeffrey A. Law <law at gcc dot gnu.org> --- Coming back to this. WRT extension elimination. I've been pondering if we want a late pass to do a bit of this that can't be handled by REE. So let's take the case of a Zbs instruction operating on a variable bit in RV64. I think we can probably agree that in the absence of additional information we can't do those kind of bit manipulations because we could potentially change bit 31 and have the result escape as a parameter to a function call, return value or get used in a compare type instruction. So to make use of the Zbs instructions that manipulate a variable bit we could could emit a suitable sign extension after each such operation. That, of course, has the potential to be expensive. But if we chase down the uses we can probably eliminate a lot of these extensions. Essentially we need to know if the extension reaches a comparison, one of the ABI escape points or a real 64bit operation. If not, then the extension is unnecessary and can be dropped. Ideally we'd find that a significant number of extensions could be dropped. We're not actively working on this, but it is something rattling around in the empty space between my ears.
prev parent reply other threads:[~2023-04-28 22:47 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-11 15:36 [Bug target/106585] New: " kito at gcc dot gnu.org 2022-08-11 15:45 ` [Bug target/106585] " pinskia at gcc dot gnu.org 2022-08-11 15:46 ` pinskia at gcc dot gnu.org 2022-08-11 15:52 ` pinskia at gcc dot gnu.org 2022-08-11 15:54 ` pinskia at gcc dot gnu.org 2022-08-11 16:10 ` kito at gcc dot gnu.org 2022-08-11 16:23 ` kito at gcc dot gnu.org 2022-08-11 16:27 ` pinskia at gcc dot gnu.org 2022-12-07 22:45 ` law at gcc dot gnu.org 2022-12-08 5:02 ` palmer at gcc dot gnu.org 2022-12-08 6:25 ` Andrew Waterman 2022-12-08 6:25 ` andrew at sifive dot com 2022-12-08 16:16 ` palmer at gcc dot gnu.org 2023-04-28 22:46 ` law at gcc dot gnu.org [this message]
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-106585-4-WAzNMqeXb2@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).