From: Jim Wilson <jimw@sifive.com>
To: Paulo Matos <pmatos@linki.tools>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: Re: RISC-V sibcall optimization with save-restore
Date: Thu, 21 Mar 2019 01:20:00 -0000 [thread overview]
Message-ID: <bfc49c0b-174c-f616-7e56-3b9b85228b31@sifive.com> (raw)
In-Reply-To: <ead0512b-ec6c-563c-480b-9c9f91d8ac87@linki.tools>
On 3/20/19 5:25 AM, Paulo Matos wrote:
> I am working on trying to get RISC-V 32 emitting sibcalls even in the
> present of `-msave-restore`, for a client concerned with generated code
> size.
This won't work unless you define a new set of restore functions. The
current ones restore the return address from the stack and return, which
is wrong if you want to do a sibcall. This is why we tail call (jump
to) the restore functions, because the actual function return is in the
restore functions. You will need a new set of restore functions that
restore regs without restoring the ra. You then probably also then need
other cascading changes to make this work.
The new set of restore functions will then increase code size a bit
offsetting the gain you get from using them. You would have to have
enough sibling calls that can use -msave-restore to make this
worthwhile. It isn't clear if this would be a win or not.
> I thought I was on the right path until I noticed that the CFG is messed
> up because of assumptions related to emission of sibcall instead of a
> libcall until the epilogue is expanded. During the pro_and_epilogue pass
> I get an emergency dump and a segfault:
> gcc/gcc/testsuite/gcc.target/riscv/save-restore-1.c:11:1: error: in
> basic block 2:
> gcc/gcc/testsuite/gcc.target/riscv/save-restore-1.c:11:1: error: flow
> control insn inside a basic block
> (jump_insn 24 23 6 2 (parallel [
> (return)
> (use (reg:SI 1 ra))
> (const_int 0 [0])
> ]) "gcc/gcc/testsuite/gcc.target/riscv/save-restore-1.c":11:1 -1
> (nil))
If you look at the epilogue code, you will see that it emits a regular
instruction which hides the call to the restore routine, and then it
emits a special fake return insn that doesn't do anything. You can just
stop emitting the special fake return insn in this case. This of course
assumes that you have a new set of restore functions that actually
return the caller, instead of the caller's parent.
One of the issues with -msave-restore is that the limited offset ranges
of calls and branches means that if you don't have a tiny program then
each save/restore call/jump is probably an auipc/lui plus the call/tail,
which limits the code size reduction you get from using it. If you can
control where the -msave-restore routines are placed in memory, then
putting them near address 0, or near the global pointer address, will
allow linker relaxation to optimize these calls/jumps to a single
instruction. This will probably help more than trying to get it to work
with sibling calls.
If you can modify the hardware, you might try adding load/store multiple
instructions and using that instead of the -msave-restore option. I
don't know if anyone has tried this yet, but it would be an interesting
experiment that might result in smaller code size.
Jim
prev parent reply other threads:[~2019-03-21 1:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-20 12:25 Paulo Matos
2019-03-21 1:20 ` Jim Wilson [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=bfc49c0b-174c-f616-7e56-3b9b85228b31@sifive.com \
--to=jimw@sifive.com \
--cc=gcc@gcc.gnu.org \
--cc=pmatos@linki.tools \
/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).