explicit arrays and limit checks

[Matthew Fluet]

> Hmmm.  One other thing that I thought of is that I changed the
> interface to GC_collect -- see the GC_collect macro in ccodegen.h.
> There are now two arguments, amount and force, instead of one.  I
> don't see any obvious problems in x86-generate-transfers wrt this, but
> I thought it was worth mentioning.

Ah, I think I see the problem.  We're overloading the meaning of
Prim.gcCollect -- if it arises from the source program (as in
MLton.GC.collect), then it is a nullary, runtime primitive, which
x86-mlton.fun translates into an invokeRuntime of GC_collect with 
amount = 0, force = TRUE.  On the other hand, it can also arise from a
limit check, with specific amount and force.

In the main cvs branch, this isn't a problem, because x86-translate
LimitCheck drops the limit check all the way down to pseudo-x86; only the 
MLton.GC.collect is passed to x86-mlton.

But, in the explict branch, this is a serious problem, because the MACHINE
IL is outputing runtime transfers with Prim.gcCollect with the arguments
we need; but x86-mlton is assuming that any GC_collect is nullary and just
filling in amount = 0, force = TRUE.  What it should really do is use
arguments if they are there, otherwise use the default.

I'll let you know how that works out; but it certainly would explain why
we were making limit checks without getting the necessary space back.