From: Jeff Law <jeffreyalaw@gmail.com>
To: Andrew Waterman <andrew@sifive.com>, Jeff Law <jlaw@ventanamicro.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [committed] [PR target/93062] RISC-V: Handle long conditional branches for RISC-V
Date: Tue, 10 Oct 2023 21:26:20 -0600 [thread overview]
Message-ID: <006feb32-ab7f-4733-a308-35dbe4077854@gmail.com> (raw)
In-Reply-To: <CA++6G0CQ=fRQV0CSt-o8F_sSL_26rxfmyaGXHmpuSh7XZ31yLw@mail.gmail.com>
On 10/10/23 18:24, Andrew Waterman wrote:
> I remembered another concern since we discussed this patch privately.
> Using ra for long calls results in a sequence that will corrupt the
> return-address stack.
Yup. We've actually got data on that internally, it's not showing up in
a significant way in practice.
I know nothing
> about the complexity of register scavenging, but it would be nice to
> opportunistically use a scratch register (other than t0), falling back
> to ra only when necessary.
The nice thing about making $ra fixed is some can add a register
scavenging approach, then fall back to $ra if they're unable to find a
register to reuse.
>
> Tangentially, I noticed the patch uses `jump label, ra' for far
> branches but uses `call label' for far jumps. These corrupt the RAS
> in opposite ways (the former pops the RAS and the latter pushes it.
> Any reason for using a different sequence in one than the other?
I'd noticed it as well -- that's the way it was in the patch that was
already in Ventana's tree ;-) My plan was to address that separately
after dropping in enough infrastructure to allow me to force everything
to be far branches for testing purposes.
jeff
next prev parent reply other threads:[~2023-10-11 3:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-10 22:11 Jeff Law
2023-10-11 0:24 ` Andrew Waterman
2023-10-11 3:26 ` Jeff Law [this message]
2023-10-11 12:55 ` Andrew Waterman
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=006feb32-ab7f-4733-a308-35dbe4077854@gmail.com \
--to=jeffreyalaw@gmail.com \
--cc=andrew@sifive.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jlaw@ventanamicro.com \
/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).