yet another limit check bug

[Matthew Fluet]

> > But, this just seems to highlight the orthogonality of limit check for
> > allocation and limit checks for threads.
> 
> I don't see any advantage to separating them, given that we want to
> combine the common case where a signal limit check is immediately
> followed by a heap limit check into a single test.

I'm not suggesting that we go to the complete separation extreme.  I was
just noting that the reason for putting a limit check in a block comes
from either signal check or heap check.  I think that signal checks should
be laid down first and be considered a partial solution (i.e., tells
places where there should be limit checks, but not how much heap to ask
for) to the heap checks.  Of course, there are all sorts of ways you could
define the optimality of the resulting solution.  If there is already a
limit check in a (non-allocating) loop for signals, should I just hoist a
heap check into the loop?  What if it's more than LIMIT_SLOP (which
requires computing an address, instead of just a comparison)?