Re: Work in progress: "Super Sib Calls"; opinions sought

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

In message <20020909101218.GA22341@redhat.com>, Richard Henderson writes:
 >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.  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.
Also note that simply constructing arguments in the outgoing space is
not necessarily going to avoid the overlapping problems.  Consider
targets where the incoming and outgoing space is not disjoint
(as is the case when passing arguments in registers).


For memory arguments, clearly the incoming and outgoing spaces are
disjoint.  However, you've got those (*&#@$ memory copies from the
outgoing space back to the incoming space; those are bloody expensive.

As others have pointed out, the way to go is to build a dependency graph,
break the cycles and use the resulting graph to construct the arguments in
the incoming space whenever possible.  Note this can (and should) happen
within the current context of tail/sibling call optimizations.  In fact,
building a dependency graph for argument setup would be useful in other
ways (for example all the silly REG_PARM_STACK_SPACE copying that we do
when we encounter nested calls).

 >For *exactly* the reason above!  You absolutely positively *must*
 >guarantee that no stack frame addresses escape from the function.
 >We don't currently do that, and thus
 >
 >              /* ??? Overly conservative.  */
 >              || frame_offset
 >
 >simply notes that if there is no local stack frame, none of it
 >could have possibly escaped.  (My previous message was confused on
 >this issue -- I thought we did minimal scanning; apparently we do
 >nothing at all.)
We ran out of time on that contract to implement the dataflow analysis
necessary to track live memory slots, so we had to stick with the 
overly conservative "no local variables" scheme.   I don't know why
we didn't refine that to be "no locally addressable variables".

jeff