This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Work in progress: "Super Sib Calls"; opinions sought
On 09-Sep-2002, Richard Henderson <rth@redhat.com> wrote:
> On Mon, Sep 09, 2002 at 07:49:22PM +1000, Andreas Bauer wrote:
> > So, what I'm trying to do is offer a more general stack re-usage for calls
> > in tail position, even if the sib call optimisation fails. That is, I'm
> > generating RTL code similar to an ordinary call for each tail call, but
> > I'm moving the args back into the incoming arg space, _after_ they're all
> > evaluated and have been mangled via the outgoing arg space.
>
> Personally, I see this as the _easy_ part.
GOOD! Let's tackle the easy parts first.
Break the task down into small parts, and when the easy
ones are done, then the hard ones will be easier...
> This could be done
> within the existing framework for sibcalls. And, IMO, if you're
> not doing this within the existing framework for sibcalls you
> are making a mistake.
In other words, the decision between whether to use an ordinary sibcall
(construct arguments in the incoming args area) and a "super sibcall"
(construct arguments in the outgoing args area and then copy them to
the incoming args area) should be made in calls.c, before constructing
the sibcall CALL_PLACEHOLDER chain. OK, that sounds reasonable.
Andreas, just to expand on the rationale for this a bit more:
the reason for delaying the choice between ordinary calls and sibling
calls is that this depends on the context (whether the call is actually
in a tail position), and in general we don't know what code will follow
when generating the call. Hence we need to generate RTL for both
kinds, and make the decision later, once we know what code follows.
However, the choice between sibling calls and "super" sibcalls depends
only on factors such as whether the arguments overlap, which can be
determined at the time the call is generated. It is therefore better
(for compilation time) to make the decision when generating the call,
avoiding the need to generate another RTL chain.
> The hard part is distinguishing
>
> void foo()
> {
> int x[100];
> // something local that uses x
> bar(); // legal to tail-call
> }
>
> void baz()
> {
> int x[100];
> global = x;
> bar(); // *not* legal to tail-call, since bar may reference x
> }
Right. I think Andreas is not trying to distinguish between these two,
but is planning to use the explicit annotation approach that I
posted some time ago. In other words, we'd distinguish between those and
void quux()
{
int x[100];
global = x;
__tailcall bar(); /* legal to tail-call;
the annotation implies that
bar is not allowed to reference x. */
}
But this can be dealt with by a separate patch.
It doesn't need to be part of Andreas' change.
> (My previous message was confused on
> this issue -- I thought we did minimal scanning; apparently we do
> nothing at all.)
Actually there *is* code in sibcall.c to do such scanning (see
uses_addressof() and sequence_uses_addressof() in sibcall.c). However,
the test for frame_size in optimize_sibling_and_tail_recursive_calls()
in sibcall.c makes this code currently redundant, I think.
I don't understand why both are needed.
> If you do not plan to address this data flow issue in some way,
> you might as well quit now.
Hey, we don't want to unnecessarily discourage volunteers, do we? ;-)
The data flow issue does need to be addressed eventually.
But I don't think it needs to be addressed right away;
improving sibcall to better handle overlapping arguments
would already be a useful improvement.
The data flow issues can be address by the explicit annotation
approach that I suggested earlier.
--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.