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.

      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: link
Be 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).