SSA backend

[Matthew Fluet]

> > Do we really need a condition that says that any use of a label as a cont
> > in a non-tail call must always be paired with the same handler?  
> 
> I don't think that we do.  In fact, I'm pretty sure that the
> conditions that I have written down in my notes for the forthcoming
> exceptions paper will happily accept your transformed program,
> precisely because the use of Bug imposes no constraints.

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.

> > I was actually thinking about this on the way up this morning in
> > relation to the contification pass.  If we contify a function at a
> > continuation, under SSA we need to know the handler to rewrite
> > Raise's -- which must mean that there is only one handler.
> 
> Yes.

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).

> > If this makes sense, then I would have remove-unused.new.fun rewrite the
> > above to:
> > 
> >    L_3 ()
> >      x_10: unit = Stdio_print (global_215)
> >      L_1022a (exit_0 (global_0, env_0)) handle L_1023
> >    L_166 ()
> >      L_1022b (exit_0 (global_12, x_21)) handle L_91   
> >    L_1023 (x_1614: exn)
> >      L_2 ()
> >    L_1022a () = L_1022 ()
> >    L_1022b () = L_1022 ()
> >    L_1022 ()
> >      Bug
> >    L_91 (x_43: exn)
> >      SetHandler L_0
> >      case x_43 of
> >        Fail_0 => L_116 | SysErr_0 => L_101 | _ => L_100
> > 
> > Note, this means that the shrinker needs to be aware of that CPS IL
> > condition, because it can't change occurences of L_1022a to L_1022.
> 
> Yeah, and that sounds like a bad idea to me.  If this is a condition
> that we need just in the backend, then we shouldn't constrain the rest
> of the optimizer, we should introduce extra wrapper labels when we
> need them.

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.