public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Makarov <vmakarov@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>, Andy Lutomirski <luto@kernel.org>
Cc: gcc@gcc.gnu.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: gcc feature request / RFC: extra clobbered regs
Date: Wed, 01 Jul 2015 11:23:17 -0400	[thread overview]
Message-ID: <559405E5.7000405@redhat.com> (raw)
In-Reply-To: <20150630213736.GQ10247@tucnak.redhat.com>



On 06/30/2015 05:37 PM, Jakub Jelinek wrote:
> On Tue, Jun 30, 2015 at 02:22:33PM -0700, Andy Lutomirski wrote:
>> 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.)
> GCC already supports -ffixed-REG, -fcall-used-REG and -fcall-saved-REG
> options, which allow to tweak the calling conventions; but it is per
> translation unit right now.  It isn't clear which of these options
> you mean with the extra_clobber.
> I assume you are looking for a possibility to change this to be
> per-function, with caller with a different calling convention having to
> adjust for different ABI callee.  To some extent, recent GCC versions
> do that automatically with -fipa-ra already - if some call used registers
> are not clobbered by some call and the caller can analyze that callee,
> it can stick values in such registers across the call.
> I'd say the most natural API for this would be to allow
> f{fixed,call-{used,saved}}-REG in target attribute.
>
>
One consequence of frequent changing calling convention per function or 
register usage could be GCC slowdown.  RA calculates too many data and 
it requires a lot of time to recalculate them after something in the 
register usage convention is changed.

Another consequence would be that RA fails generate the code in some 
cases and even worse the failure might depend on version of GCC (I 
already saw PRs where RA worked for an asm in one GCC version because a 
pseudo was changed by equivalent constant and failed in another GCC 
version where it did not happen).

Other than that I don't see other complications with implementing such 
feature.


  parent reply	other threads:[~2015-07-01 15:23 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
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 [this message]
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=559405E5.7000405@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hpa@zytor.com \
    --cc=jakub@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox