Re: RFC: SPARC tail calls using the new infrastructure

[Jeffrey A Law <law at cygnus dot com>]

  In message <20000321103500.L525@mff.cuni.cz>you write:
  > Hi!
  > 
  > On SPARC (and I assume on all machines with register windows) when doing a
  > tail call we have to put arguments into the INCOMING registers as opposed t
  > o
  > normal calls where they are in OUTGOING registers, because the tail call
  > must unroll the register window first.
  > I wonder what is the best place to do this.
optimize_sibling_and_tail_recursive_calls is certainly the wrong place to
do this.  In fact, part of the point of moving all the argument handling for
tail call optimization to the tree level was to avoid this kind of problem.

The existing code should already be putting arguments into the incoming
registers on the sparc.  If it isn't, you should find out why.

  > optimize_sibling_and_tail_recursive_calls, I'm now testing another solution
  > where I'd like to add SIBCALL argument to INIT_CUMULATIVE_ARGS and let the
  > backend do it itself, but the latter does not work yet.
No, this is not the right approach.  Again, the code should work as-is, you
need to figure out why it does not.

  > I'll probably try to test this some more and finish tail calls for leaf
  > functions.
  > BTW: Is somebody looking into removing the if (frame_offset) goto failure;
  > line? I could try to update the relevant pieces from my tail call patch
  > (that was the about half of the generic code in it in fact).
Please do not try to use your old patch -- it was an extremely poor
implementation.

The way to do this is to look at it as a dataflow/life analysis problem.  You
need to determine if any stack slots are live across the potential tail
call.  Define what makes a stack slot live and what kills a stack slot, then
run generic life analysis dataflow equations and you'll get the info you
need in a *much* cleaner way.

jeff