contification

[Stephen Weeks]

> 1. lack of a shinker that eliminates unused blocks can leave a program
> that is well formed, but the control-flow graph isn't connected, so the
> type-checker fails when it tries to compute the dominators for
> checkScopes.

It's on the todo to fix this.

> 2. I get some problems with the invariant check in the GC when compiling
> with -g.  It's a handler stack "problem".  What seems to be happening is
> that the Set* statements in the contified function aren't being changed in
> any way (I don't touch the statements at all; just rewrite transfers).  I
> can end up with a situation where the main_0 function ends up with it's
> link slot pointing to itself.  Then the loop that walks the exnStack in
> the invariant check get's stuck.  I get no runtime errors; I think, to an
> extent, this is o.k.  It just corresponds to the link slot being in an
> undefined state at a place in the execution when we won't need it.

I think this is a bug, and is a real problem with the current approach
of using SetExnStackLocal and friends.  We didn't have the problem
with HandlerPush and HandlerPop because there semantics implicitly
depended on the "current" local exception stack.  As a consequence,
they didn't need to be changed when inlining or contifying.
Unfortunately, SetExnStackLocal and friends are lower-level than
HandlerPush and HandlerPop, and must be changed when inlining or
contifying. 

I think that the right solution is to re-introduce HandlerPush and
HandlerPop, for the purposes of the paper, so that we can use the
handler info from the source program, and easily propagate it.  All
SSA optimizations just need to preserve Push and Pop, and will never
see Set and friends.

A pass after the SSA optimization pipeline will transform Push and Pop
int Set and friends (or for other strategies, will ignore the push and
pop and install the handlers however it wants), so the backend will
only ever see Set and friends.