SSA

[Matthew Fluet]

> OK.  What you wrote mostly made sense.  I'll try to explain in my own
> words to see if I understand.  Stubs have different sizes, therefore
> the return values will be at different stack positions depending on
> which stub was used.  

Correct.

> Therefore, except for stubs of one particular
> height (the smallest?), there will have to be a shuffle to get the
> return values into the cont formals.  

Correct.  You are only burnt when there are handlers with live data that
isn't live down the continuation.

The current framework should be fine; as long as ParallelMove doesn't do a
shuffle when it doesn't need to, then we just keep stubs as they are with
a different calculation for where the return values are found.

(Side issue: you also need to be concerned about stack alignment; a
function can drop all of it's return values so that the last value
finishes at the word below stack top, but we still might have to suffle by
a word if we needed to align mod 8.  Again, we can pay some stack space to
ensure that the continuation arguments are aligned so that the frame size
is the right alignment.)

> We could pay some stack space to
> make stubs have the same size and avoid this shuffle.

I think so.  But, this is complicated -- i.e., ensure that we allocate the
continuations args "above" all of it's handler's live data.


Mind you, I don't this is going to hurt in practice.  The problem in mllex
all arose from the fact that removeUnused figured out that exit_0 can't
ever terminate normally, so it gives them all a continuation that goes to
Bug.  So, there is not shuffle because we can't ever get to that
continuation.

Now, if you want to be more aggressive with reducing code duplication,
then maybe this becomes more of an issue.