This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc feature request / RFC: extra clobbered regs

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]