RSSA
Matthew Fluet
fluet@CS.Cornell.EDU
Thu, 27 Dec 2001 17:30:38 -0500 (EST)
> > 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.