From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@kernel.org>,
gcc@gcc.gnu.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: gcc feature request / RFC: extra clobbered regs
Date: Tue, 30 Jun 2015 14:32:23 -0700 [thread overview]
Message-ID: <55930AE7.5090309@zytor.com> (raw)
In-Reply-To: <CALCETrX6j9vBZR7RirXf8usz1Y4f-1TnVaYTVg0_PgQCeWZnRg@mail.gmail.com>
On 06/30/2015 02:22 PM, Andy Lutomirski wrote:
> Hi all-
>
> I'm working on a massive set of cleanups to Linux's syscall handling.
> We currently have a nasty optimization in which we don't save rbx,
> rbp, r12, r13, r14, and r15 on x86_64 before calling C functions.
> This works, but it makes the code a huge mess. I'd rather save all
> regs in asm and then call C code.
>
> Unfortunately, this will add five cycles (on SNB) to one of the
> hottest paths in the kernel. To counteract it, I have a gcc feature
> request that might not be all that crazy. When writing C functions
> intended to be called from asm, what if we could do:
>
> __attribute__((extra_clobber("rbx", "rbp", "r12", "r13", "r14",
> "r15"))) void func(void);
>
> This will save enough pushes and pops that it could easily give us our
> five cycles back and then some. It's also easy to be compatible with
> old GCC versions -- we could just omit the attribute, since preserving
> a register is always safe.
>
> Thoughts? Is this totally crazy? Is it easy to implement?
>
> (I'm not necessarily suggesting that we do this for the syscall bodies
> themselves. I want to do it for the entry and exit helpers, so we'd
> still lose the five cycles in the full fast-path case, but we'd do
> better in the slower paths, and the slower paths are becoming
> increasingly important in real workloads.)
>
Some gcc targets have done this in the past. There are command-line
options to do that, but using attributes you have to handle cross-ABI
compilation.
However, I don't see this being done in the upstream gcc.
Keep in mind the runway that we'll need, though.
-hpa
next prev parent reply other threads:[~2015-06-30 21:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 21:22 gcc feature request / RFC: extra clobbered regs Andy Lutomirski
2015-06-30 21:32 ` H. Peter Anvin [this message]
2015-06-30 21:37 ` Jakub Jelinek
2015-06-30 21:41 ` H. Peter Anvin
2015-06-30 21:48 ` Andy Lutomirski
2015-06-30 21:52 ` H. Peter Anvin
2015-06-30 21:55 ` Andy Lutomirski
2015-06-30 22:02 ` H. Peter Anvin
2015-07-01 4:20 ` Jeff Law
2015-07-01 15:23 ` Vladimir Makarov
2015-07-01 15:27 ` Andy Lutomirski
2015-07-01 17:57 ` Vladimir Makarov
2015-07-01 15:31 ` Jakub Jelinek
2015-07-01 17:35 ` Vladimir Makarov
2015-07-01 17:38 ` Andy Lutomirski
2015-07-01 17:43 ` Jakub Jelinek
2015-07-01 18:12 ` Vladimir Makarov
2015-07-01 20:09 ` Andy Lutomirski
2015-07-02 6:16 ` H. Peter Anvin
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=55930AE7.5090309@zytor.com \
--to=hpa@zytor.com \
--cc=gcc@gcc.gnu.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.