RSSA
Matthew Fluet
fluet@CS.Cornell.EDU
Sat, 22 Dec 2001 12:58:43 -0500 (EST)
> I started to work on translating SSA to RSSA and found a few problems
> with my last proposal. Here's the latest. Hopefully, I'll finish the
> SSA -> RSSA translation tomorrow.
It looks alright.
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.
> | Offset of {base: Var.t,
> bytes: int}
> | OffsetScale of {base: Var.t,
> index: Var.t,
> scale: int}
If you look at MemLoc.t in x86.fun, you can see where I wrap these two
together into one operand. I don't know if it is worth doing here.
> Array of {dst: Var.t,
> numBytesNonPointers: int,
> numElts: Var.t,
> numPointers: int}
I'd still like to shoot for some future point where Array's aren' as
privileged.
> | Object of {dst: Var.t,
> numPointers: int,
> numWordsNonPointers: int,
> stores: {offset: int, (* bytes *)
> value: Operand.t} vector}
Why do we need numPointers and numWordsNonPointes here? I know we
eventually need them for the header word, but why not just put a Word.t
here?
> | 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.