This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Reload patch for PA call rewrite.
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: law at redhat dot com
- Cc: rth at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Thu, 24 Oct 2002 17:49:09 -0400 (EDT)
- Subject: 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)