limit check insertion

[Matthew Fluet]

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

More than the onese that I pulled out and put into the size calculation?
An array of n integers should require 8 + 4 * n bytes (length word +
header word + array elements), right?

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

There is that.

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

Cleaning up machine would probably be a good idea.  Limit checks and
machine, though, have this strange chicken/egg problem.  We need to know
where we might insert limit checks to do stack vs. pseudo-reg allocation.
But, it would be nice to have coalesced limit checks before doing
allocation, to avoid spilling variables to stack locations.