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>
Cc: 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>,
	"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 13:35:16 -0400	[thread overview]
Message-ID: <559424D4.6010908@redhat.com> (raw)
In-Reply-To: <20150701153133.GY10247@tucnak.redhat.com>



On 07/01/2015 11:31 AM, Jakub Jelinek wrote:
> On Wed, Jul 01, 2015 at 11:23:17AM -0400, Vladimir Makarov wrote:
>>>> (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.
> That is true.  i?86/x86_64 is a switchable target, so at least for the case
> of info computed for the callee with non-standard calling convention such
> info can be computed just once when the function with such a target
> attribute would be seen first.
Yes, more clever way could be used.  We can can calculate the info for 
specific calling convention, save it and reuse it for the function with 
the same attributes.  The compilation speed will be ok even with the 
current implementation if there are few calling convention changes.
>    But for the caller side, I agree not
> everything can be precomputed, if we can't use e.g. regsets saved in the
> callee; as a single function can call different functions with different
> ABIs.  But to some extent we have that already with -fipa-ra, don't we?
>
>
Yes, for -fipa-ra if we saw the function, we know what registers it 
actually clobbers.  If we did not processed it yet, we use the worst 
case scenario (clobbering all clobbered registers according to calling 
convention).

Actually it raise a question for me.  If we describe that a function 
clobbers more than calling convention and then use it as a value 
(assigning a variable or passing as an argument) and loosing a track of 
it and than call it.  How can RA know what the call clobbers actually.  
So for the function with the attributes we should prohibit use it as a 
value or make the attributes as a part of the function type, or at least 
say it is unsafe.  So now I see this as a *bigger problem* with this 
extension.  Although I guess it already exists as we have description of 
different ABI as an extension.


  reply	other threads:[~2015-07-01 17:35 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
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 [this message]
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=559424D4.6010908@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