SSA backend

[Stephen Weeks]

> Could you put those in the exceptions paper directory?  I'd just like to
> make sure I've got a good feel for exactly what we want the semantics of
> the exceptions to be.

It's #3 on my todo after (#1) getting flexrecords working properly and
(#2) testing out Ssa.Function.checkHandlers.  Would you like me to
move it to #2?

> O.k.  This makes the contification marginally more complicated if we don't
> impose the cont/handler pairing condition.  Essentially, the notion of
> place in "function returns to only one place" is not just cont's, it is
> cont/handler pairs.  I think everything in the safety conditions, analysis
> and transformations goes through if we just use cont/handler pairs
> wherever we were using conts.


> The implementation of the analysis get's a
> little harder, but not too bad.  For all the nice property list stuff, we
> need a Label.t * Label.t -> PropertyList.t function.  I guess a
> hash-table (since Label.t's are HashId's).

I'd probably go for property on conts with an alist for the exception
piece, but who knows ... linear is scary.  The interesting thing is
that we wouldn't need this if we imposed the condition -- does that
mean that this cost would be shifted somewhere else, like the
shrinker?

> The condition is there because of implementation decisions.  We need a way
> of passing roots to the GC, and we accomplish that by having the
> frameLayouts of the continuation label indicate the live roots of the
> corresponding handler.  Other implementations might not require that.  I'm
> happy with leaving less conditions on the SSA IL.

Agreed.  This reminds me though, if we go this way, we need to change
dominators back to the way it was and fix the backend liveness
computation to match that.  Namely, the variables that are live in a
continuation due to a handler should not be propagated to calls with
that continuation.  I think this can be fixed by massaging the graph
that liveness uses.