This is the mail archive of the gcc-patches@gcc.gnu.org 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: [3.4-BIB] x86-64 sibcall fixes try III


> Hi,
> 
> On Mon, 28 Oct 2002, Jan Hubicka wrote:
> 
> > > >
> > > > IMHO it would be much nicer to name those CALL_USED_REGS and
> > > > CALL_USED_64_REGS.
> > >
> > > I would even suggest CALL_CLOBBERED... The term call-used is misleading,
> > > it only can be justified with gcc's history of having it named such since
> > > ages (and wrongly so IMO).  The term "use" doesn't indicate at all that
> > > all those registers can be changed after a call.
> > >
> > > Besides from that, I also don't exactly like the addition of more register
> > > classes.
> >
> > Any idea for good sollution without them?
> 
> Unfortunately no ;-(  You could prohibit sibcalls with too many arguments,
> but that's not necessarily a good solution ;)
We produce poor code for any sibcall to function with arguments passed
in registers.
> 
> > One I got today is to simply encode hard register for this (ie always
> > use r11). Also not perfect.
> 
> What would this affect?  Only sibcall with many arguments?  If yes, then
> this would be a better solution IMHO.
With current classes we don't generate good code for sibcalls with any
number of arguments, just because we get extra move. 
I guess this should avoid all moves and regallocate the value into r11
should not be big deal given the fact that just before sibcall there is
not much to keep in registers.

I will benchmark the cost of extra class first.
Honza
> 
> 
> Ciao,
> Michael.


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