RSSA

[Matthew Fluet]

> > What is the intuitive distinction between Operand.t and Var.t?  There just
> > seem to be a number of places where you require Var.t that would seem to
> > work equally well with Operand.t.
> 
> Arbitrary for now -- it's just what I needed.  I can see all uses of
> Var.t (except binding occurrences) in statements and transfers being
> replaced by Operand.t.

O.k.  It might make things a little more uniform, but unless we were to do
any serious optimizations, I suspect that a direct translation from SSA
will leave most of them as Var.t's anyways.

> > > 	     | LimitCheck of {kind: LimitCheck.t,
> > > 			      return: Label.t}
> > 
> > I know the LimitCheck.t kind is encoding a lot, but it might be simpler to
> > make the limit check a Runtim transfer with appropriate argument
> > encodings.
> 
> I don't see how to do this except to push the sum type inside the
> runtime variant, like
> 
> 	datatype Runtime.t = 
>             LimitCheck of LimitCheck.t
>           | PrimApp of {prim: Prim.t, args: Var.t vector}
> 
> 
> 	     | Runtime of {call: Runtime.t,
> 			   return: Label.t (* Must be nullary. *)
> 			  }
> 
> This doesn't seem like a win to me.  Did you have something else in
> mind?  Changing the Prim type?  That seems bad to me.

No, I was thinking something a little less explicit.  More like the way in
which stack checks are really passed to th GC at a GC_gc call; i.e., one
of the arguments is set to true.  Likewise, for array vs non-array limit
checks, we still just pass a number to GC_gc as the bytes needed.  But, I
agree that this makes reasoning and checking limit-checks a little more
difficult.  I guess my initial objection was that the RSSA IL seemed a
little too geared for limit checks, but that's what it's there for.