RSSA

[Matthew Fluet]

> > I'm fighting the CCall / CReturn distinction more than I'd like to.  In
> 
> stored.  Could you explain in more detail the problems?

After some further reflection, it's not that big a deal.  It must means
splitting up my C-calling convention code into two places.  What I was
initially worried about was the interaction with carrying values in
registers across blocks, which is implemented at transfers and entries.
But, while in a C-call, %esp shouldn't be mucked with, nor the return
register (%eax or %st(0)).  In practice, this isn't a problem, because we
always fall through to the CReturn (which is the unique way of reaching
CReturn) so we don't actually set up anything.  But, there are
combinations of compile time options that will screw it up -- in
particular -native-live-transfer true -native-optimize 0, which will try
to pass things in registers but when generating transfers, will always use
jumps and never fall through.

The solution that I've mostly got working is to copy the returned value to
a global static location, transfer to the CReturn, and then copy the 
value to it's final destination.  Consider it an extended C-calling
convention where values are returned in static memory locations rather
than registers.  In practice, the register allocator won't bother moving
the return value into the global location, because it goes dead in a
couple of instructions.

There is also the C-calling convention which requires the caller to pop
the c-stack of callee arguments.  Technically, this seems like a CReturn
type of operation, but we don't know the number and/or size of the
arguments there.  It seems really messy to pass an args list to each
CReturn.  It's not a big deal; the pop is trivial (i.e., won't touch
any registers besides %esp) and can be done before transfering to the
CReturn.