yet another limit check bug

[Matthew Fluet]

> I decided to try out the new contification on what used to be a
> problematic example, like:
> 
> It did the right thing, and contified f and g within main.

Woo-hoo!

> Unfortunately, this also brings out another bug regarding the loop
> limit checks required for signal handling (even with the
> -limit-check-per-block true).  Loop limit checks are currently
> inserted at nodes that have an incoming edge from a node that they
> dominate.  Unfortunately, in the control-flow graph for the above
> program, there is no such node in the f-g loop.  We probably need to
> do something using loopForests to ensure that all the loop headers get
> a loop limit check.

And you're in luck!  I recently extended the loopForest stuff to return an
isHeader predicate that can be used to check if a node was marked as the
header of any loop.

But, this just seems to highlight the orthogonality of limit check for
allocation and limit checks for threads.