Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1174771 > unrolled thread

gcc feature request / RFC: extra clobbered regs

Back to article view | Back to linux.kernel

Contents

  gcc feature request / RFC: extra clobbered regs Andy Lutomirski <luto@kernel.org> - 2015-06-30 23:30 +0200
    Re: gcc feature request / RFC: extra clobbered regs Jakub Jelinek <jakub@redhat.com> - 2015-06-30 23:40 +0200
      Re: gcc feature request / RFC: extra clobbered regs "H. Peter Anvin" <hpa@zytor.com> - 2015-06-30 23:50 +0200
        Re: gcc feature request / RFC: extra clobbered regs Andy Lutomirski <luto@amacapital.net> - 2015-06-30 23:50 +0200
          Re: gcc feature request / RFC: extra clobbered regs "H. Peter Anvin" <hpa@zytor.com> - 2015-07-01 00:00 +0200
            Re: gcc feature request / RFC: extra clobbered regs Andy Lutomirski <luto@amacapital.net> - 2015-07-01 00:00 +0200
              Re: gcc feature request / RFC: extra clobbered regs "H. Peter Anvin" <hpa@zytor.com> - 2015-07-01 00:10 +0200
    Re: gcc feature request / RFC: extra clobbered regs "H. Peter Anvin" <hpa@zytor.com> - 2015-06-30 23:40 +0200

#1174771 — gcc feature request / RFC: extra clobbered regs

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.)

Thanks,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1174778

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.

	Jakub
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1174781

On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
> I'd say the most natural API for this would be to allow
> f{fixed,call-{used,saved}}-REG in target attribute.

Either that or

	__attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))

... just to be shorter.  Either way, I would consider this to be
desirable -- I have myself used this to good effect in a past life
(*cough* Transmeta *cough*) -- but not a high priority feature.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1174783

On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>> I'd say the most natural API for this would be to allow
>> f{fixed,call-{used,saved}}-REG in target attribute.
>
> Either that or
>
>         __attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
>
> ... just to be shorter.  Either way, I would consider this to be
> desirable -- I have myself used this to good effect in a past life
> (*cough* Transmeta *cough*) -- but not a high priority feature.

I think I mean the per-function equivalent of -fcall-used-reg, so
hpa's "used" suggestion would do the trick.

I guess that clobbering the frame pointer is a non-starter, but five
out of six isn't so bad.  It would be nice to error out instead of
producing "disastrous results", though, if another bad reg is chosen.
(Presumably the PIC register on PIC builds would be an example of
that.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1174790

On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>>> I'd say the most natural API for this would be to allow
>>> f{fixed,call-{used,saved}}-REG in target attribute.
>>
>> Either that or
>>
>>         __attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
>>
>> ... just to be shorter.  Either way, I would consider this to be
>> desirable -- I have myself used this to good effect in a past life
>> (*cough* Transmeta *cough*) -- but not a high priority feature.
> 
> I think I mean the per-function equivalent of -fcall-used-reg, so
> hpa's "used" suggestion would do the trick.
> 
> I guess that clobbering the frame pointer is a non-starter, but five
> out of six isn't so bad.  It would be nice to error out instead of
> producing "disastrous results", though, if another bad reg is chosen.
> (Presumably the PIC register on PIC builds would be an example of
> that.)
> 

Clobbering the frame pointer is perfectly fine, as is the PIC register.
 However, gcc might need to handle them as "fixed" rather than "clobbered".

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1174793

On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
>> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>>>> I'd say the most natural API for this would be to allow
>>>> f{fixed,call-{used,saved}}-REG in target attribute.
>>>
>>> Either that or
>>>
>>>         __attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
>>>
>>> ... just to be shorter.  Either way, I would consider this to be
>>> desirable -- I have myself used this to good effect in a past life
>>> (*cough* Transmeta *cough*) -- but not a high priority feature.
>>
>> I think I mean the per-function equivalent of -fcall-used-reg, so
>> hpa's "used" suggestion would do the trick.
>>
>> I guess that clobbering the frame pointer is a non-starter, but five
>> out of six isn't so bad.  It would be nice to error out instead of
>> producing "disastrous results", though, if another bad reg is chosen.
>> (Presumably the PIC register on PIC builds would be an example of
>> that.)
>>
>
> Clobbering the frame pointer is perfectly fine, as is the PIC register.
>  However, gcc might need to handle them as "fixed" rather than "clobbered".

Hmm.  True, I guess, although I wouldn't necessarily expect gcc to be
able to generate code to call a function like that.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1174795

On 06/30/2015 02:55 PM, Andy Lutomirski wrote:
> On Tue, Jun 30, 2015 at 2:52 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 06/30/2015 02:48 PM, Andy Lutomirski wrote:
>>> On Tue, Jun 30, 2015 at 2:41 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>>> On 06/30/2015 02:37 PM, Jakub Jelinek wrote:
>>>>> I'd say the most natural API for this would be to allow
>>>>> f{fixed,call-{used,saved}}-REG in target attribute.
>>>>
>>>> Either that or
>>>>
>>>>         __attribute__((fixed(rbp,rcx),used(rax,rbx),saved(r11)))
>>>>
>>>> ... just to be shorter.  Either way, I would consider this to be
>>>> desirable -- I have myself used this to good effect in a past life
>>>> (*cough* Transmeta *cough*) -- but not a high priority feature.
>>>
>>> I think I mean the per-function equivalent of -fcall-used-reg, so
>>> hpa's "used" suggestion would do the trick.
>>>
>>> I guess that clobbering the frame pointer is a non-starter, but five
>>> out of six isn't so bad.  It would be nice to error out instead of
>>> producing "disastrous results", though, if another bad reg is chosen.
>>> (Presumably the PIC register on PIC builds would be an example of
>>> that.)
>>>
>>
>> Clobbering the frame pointer is perfectly fine, as is the PIC register.
>>  However, gcc might need to handle them as "fixed" rather than "clobbered".
> 
> Hmm.  True, I guess, although I wouldn't necessarily expect gcc to be
> able to generate code to call a function like that.
> 

No, but you need to be able to call other functions, or you just push
the issue down one level.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1174780

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web