limit checks

[Matthew Fluet]

> > What's not clear is if working on decreasing the dynamic counts is
> > worth the effort.  It's tough to measure the run-time cost of limit
> > checks, which I would guess is almost zero.  
> 
> > But maybe we need to make
> > an attempt.  Also, the interplay with other optimizations, like
> > register allocation, argues that keeping the static count small is
> > good because fewer variables will be live across limit checks, and
> > will hence be free to live in pseudo-regs.
> 
> On the other hand, I did look at benchmarks with
> -native-live-stack {false,true} -limit-check-per-block {false,true}
> and, again, there was almost no runtime difference between the different
> limit-check insertions.

A quick look at barnes-hut (where we saw a decent speed up with limit
check coalescing) shows only two blocks that do allocation, both outside
loops.  They can be hoisted to coincide with the stack check at function
entry.  So, statically, we didn't gain much (3 lcs in the function down to
1 lc).  Dynamically, we would win as well, but just because we were forced
to do the stack lc.  But, where I really think we won was in reducing the
number of variables live across lcs.  But, that becomes even harder to
quantify, and it would be even harder to try to minimize the number of
variables live across limit checks.