limit check insertion

[Stephen Weeks]

> What I had in mind was adding a new Prim.t for
> GC_limitCheck; after deciding on representations, we could insert blocks
> with Runtime {prim = GC_limitCheck, ...} transfers before every block;
> now, optimize to your heart's content, check the correctness of the final
> program, and translate into machine.

This sounds good to me.  The limitCheck is a transfer to the runtime,
so putting it at the end of a block seems OK.  Breaking up blocks at
array limit checks seems OK too -- it will encourage us to move the
limit checks forward to put the block back together.

> The other difficulty might be in efficiently handling array and intInf's.
> In particular, we need to reason about expressions, rather than just
> integers. 
...

Yeah, this is a bit messy -- we might create a little language for
expressing size in bytes computations, but I dunno ...

One other thing to keep in mind is the other hidden arithmetic in the
ArrayNoPointers and ArrayPointers macros (and somewhere in the
x86codegen).  So in the following

> L_S (n:int)
>  size = 2 * (8 + 4 * n) + 12
>  L_S1 (GC_limitCheck(size))
> L_S1 ()
>  a1 = Array_array(int) n
>  a2 = Array_array(int) n
>  t = (a1,a2)
>  t

there are some hidden 4 * n computations in the Array_array calls.
I'm not sure how much we want to expose frontier munging (or limit
checks) to SSA, or if we should try cleaning up Machine and exposing
it there.  I have a gut feeling that once we've made representation
decisions and know byte layouts that we should be in a new IL.

We might be able to clean up machine enough to handle limit checks and
allocations, but without going to the complexities of a full typed
IL.

> Also, as Steve pointed out earlier, making sure that size doesn't overflow
> on large arrays.

Computing the sizes with SSA expressions is nice here -- we can use
the overflow mechanisms that we have already.