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: Reload patch for PA call rewrite.


>  >My concern about sibcalls was more basic.  We can't share frames
>  >between the sibcall callee and caller.  So, the overhead for a sibcall
>  >and regular call are essentially the same.
> That certainly lesses the potential benefits of sibcalls.  If you can't
> share frames, then how can sibcalls work at all?

That's a good question.  Currently, sibcall_epilogue just calls
hppa_expand_epilogue.  This causes all registers to be restored
and the stack adjusted.  Then, the sibcall is made and a new set
of registers are saved.  This is identical to what happens in
a regular call.  So, there is no benefit as far as I can see.

Ia64 seems to do pretty much the same as we do.

In the case of recursive tail calls, we do share the same frame
so there is a clear benefit.  That's the main benefit in using
a fixed arg pointer as opposed to one that's not fixed.

I did see a small but consistent improvement in the running time
of genattrtab with sibcalls enabled.  I don't know where this arises
but I doubt it is from any saving in the call sequence itself.
There are small differences in how the delay slot is used.  For
regular calls, we use a branch and link, and for sibcalls, we just
branch.  That's the sum of the differences as I see it.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


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