Re: gcc feature request / RFC: extra clobbered regs

[Vladimir Makarov]

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.

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