RSSA

[Matthew Fluet]

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