SSA backend

[Stephen Weeks]

> Musings... the condition I have in mind is actually even more subtle.  For
> example, I could imagine transforming the code to the following
...
> This satisfies the cont/handler pair condition, but results in the
> same scoping or liveness problem.  

Yep.  I think the right conclusion is that we want to go with the more
precise dominator and liveness info, and keep them in sync.

> Here's a thought.  Is it possible to compute the backend liveness
> information the same way as we compute the SSA liveness information --
> i.e., do the edge from caller to handler and continuation, not edges from
> caller to continuation to handler. 

Yep.  That's what I was referring to when I said "massaging the graph
that liveness uses".

> Now, both continuation and handler have a set of live variables.  Is
> it as simple as unioning these two sets (which should all be
> refering to stack locations) and using that as the frame layout for
> a stub that just transfers control to the real continuation label?
...
> The only difference is we need a stub for each cont/handler pair,
> rather than for each cont.

I think this is right.  We (at least I) were conflating an occurrence
of C_2 as a continuation and as a jump target.  I like thinking of

  C_2(exit_0(...)) handle H_2

as saying create a *new* continuation that returns to C_2 and handles
with H_2.  I would like to figure out some way to use the liveness
algorithm in live.fun to avoid doing the union, though.

Matthew, if you want to start on this, feel free.  I'm going to be
busy with the flexrecord and checkhandler stuff for a while longer.