Re: [tree-ssa] Gimple and tail calls

[Jan Hubicka <hubicka at ucw dot cz>]

> On Fri, Nov 07, 2003 at 11:50:40PM +0100, Jan Hubicka wrote:
> > I would like to ask for opinions on representation.  I've added an new
> > flag to CALL_EXPR (CALL_EXPR_TAILCALL) signalizing calls that can be
> > converted to tail calls and the tail recognizer updates CFG in a way we
> > do for tail calls in GCC (removing edges out of CFG, adding abnormal
> > sibcall edge to exit).
> 
> No.  CALL_EXPR_TAILCALL can only mean that there are no external
> dataflow reasons that the tail call might fail.  Conversion to
> tailcall can still fail for target-specific reasons.
> 
> I expect these to mostly due to parameter passing.  Either not
> enough stack space for the called function's parameters, or
> strange parameter overlap.  Other ABI bits can be checked earlier.

It is not problem.  The tail call expansion can wind up into usual
sequence of call and return in that case.

In the case I recognize tail calls early, I can prevent other passes
inserting code past the call.  There are not many opurtunities for doing
so, but for instance profiling would do.
I want to use tail call bit for inlining herusitics in longer run
(it would be nice to inline recursive calls in order to reduce overall
depth of recursion of given function.  Doing so on tail recursion is
useless and tail recursion before inlining can show up as chain of
sibling calls).
Another use is recoginizing of obvious abstraction wrappers and forcing
them to be always inlined.

Both can be done with the other representation that only does
CALL_EXPR_TAILCALL bit.

I can also run the pass as very last in the chain, set only
CALL_EXPR_TAILCALL, keep control flow in a way expecting that tail call
conversion does not happen and teach expanders to fix CFG the other way
around.

With this scheme I still can doo early tail cal recognizing to help
inlining and hope that optiizations won't ever mess this up.  Given the
cheapness of pass and interference with dead code removal, we likely
want to do it twice anyway.

Is this your preferred choice?
> 
> > The actual problem is that some tail calls returns return value of
> > CALL_EXPR, while other do not (either because function return NULL or
> > undefined value).
> 
> So?  Why is this a problem?
Not relaly problem, but in case I want to fold tail call sequence into
one GIMPLE, it is reason why I need to nest RETURN and CALL_EXPRs

Honza
> 
> > TO represnet this I can nest CALL_EXPR with CALL_EXPR_TAILCALL inside
> > RETURN_EXPR.  Does this sound like sane extension of GIMPLE?
> 
> No.
> 
> 
> r~