RSSA LimitCheck transfer

[Matthew Fluet]

> I'm not too sure that the LimitCheck transfer has the right
> arguments.  Here's what it is now.
> 
> 	     | LimitCheck of {kind: LimitCheck.t,
> 			      return: Label.t} (* return must be nullary and of
> 						* Cont kind.
> 						*)
> 
> Is this return for the success or failure case?  
> Maybe LimitCheck
> should have two return labels, like arith, dependending on whether the
> check succeeds or fails, and both of the labels should be Normal kind?

What do you mean by fail?  If we enter the runtime to do a GC, we'll just
die there with an out of memory message.

> Then, the fail branch could express the Runtime transfer that calls
> the GC.  

I should read ahead. ;)

> This would mean duplicating the LimitCheck.t in both the
> LimitCheck and Runtime transfer.  At that point, maybe it makes sense
> to make the limit check computation explicit, frontier, array, stack,
> and all?  This would completely eliminate the LimitCheck transfer,
> expressing it as Ariths and Runtimes.  A bit harder to check of
> course, but if we're ever gonna have typed assembly, we're going to
> have to figure it out.

Maybe.  But that means exposing the existence of frontier and limit in the
Machine IL.  If you want to move object allocation all the way back there,
fine by me, but it sounds messy.

> Also, I'm not sure what the right kind of label to use for a Runtime
> return?  Should it be a CReturn or a Cont?  I guess a Cont because
> that has the liveness info.  

Actually, it should be a new Runtime return kind.  Look at x86.Entry for
each of the block kinds I want to express.  (We can't use a Cont kind
because x86-translate won't know whether to translate it into a
x86.Entry.Cont or x86.Entry.Runtime.) This wasn't a problem in the old
world because only the codegen introduced runtime transfers.

In answer to the first question, I think that the return kind of a limit
check should also be Runtime.  Or maybe it should be Jump and it should
have another label to be used for the return from the potential call to
GC_gc.  

Ah.. o.k.  It has to be Jump and it needs to have another label for the
internal runtime transfer.  Here's why: the way things should work is that
Runtime transfers are the only things that can transfer control to Runtime
entries; likewise CCall transfers are the only things that can transfer
control to CReturn entries.  When we implement a limit check, we introduce
a number of "normal"/intra-procedural transfers -- corresponding to the
frontier and stack check.  If we don't need to invoke the GC, then we do a
normal control transfer to the return of the LimitCheck.


My brain is fried for the day; hopefully the above makes some sense, but I
might revise it again tomorrow.