limit check insertion

[Stephen Weeks]

> Well, I see tons of limit checks for 0 bytes in the resulting code; so
> that seems a little wasteful.
> 
> I'm also not convinced that what's checked in solves the vliw problem.  I
> can still trace around that loop and not encounter a non-zero limit check.

Recall that a limit check with bytes = 0 really means a check for LIMIT_SLOP
bytes (currently LIMIT_SLOP = 512).  With -limit-check-per-block true, I would
expect that most limit checks would have bytes = 0.  So, I think vliw is OK.

> In a single-threaded world, yes.
> In a multi-threaded world, we could make this work by keeping a
> "bytesNeeded" field in GC_thread which would be set when the thread is
> suspended.  When restarting a thread, the loop needs to use the
> bytesNeeded. 

I like this idea.  Then, because the looping code is shared, we don't even have
to worry about treating single- and multi-threaded programs differently with
regard to the limit check loop.


As to the code size blowup, my conjecture is that part of it is due to the bad
interaction with limit checks and register allocation.  That is, with
-limit-check-per-blcok true, every block is marked as a possible place to insert
limit checks.  Hence, the register allocator will move everything that is live
across a basic block into a stack slot.

Anyways, I'm going to start on debugging simple.  Matthew, can you look at
prodcons and mutex?

Once we get those, I'll fix the limit check insertion to only mark blocks that
do allocation as possible limit check points (easy), and have a look at the
performance numbers again.