checkHandlers

[Stephen Weeks]

checkHandlers now passes all regression tests, but fails on a
self-compile.  The problem is that removeUnused5 proves that a
particular function f can not raise, and hence removes the handler
around a nontail call to f, but leaves the SetExnStack in place.  So,
checkHandlers sees that the handler is installed, but shouldn't be.
The optimization is correct.  My feeling is that the problem is that
the SSA IL is not quite expressive enough.  I propose to change the
Call transfer to

      structure Transfer:
	 sig
	    datatype handler =
	       DontCare
	     | None
	     | Some of Label.t

	    datatype t =
             ...
	     | Call of {
			return: {cont: Label.t,
				 handler: handler} option}
             ...

The idea being that at a nontail call where we have proved that the
callee can't raise, we don't care what the handler is -- this is
different than requiring the handler to be the same as the caller's
handler.  With this change, at such calls, checkHandlers won't have
any constraint to check.

This also seems better because handler insertion, whenever we get to
it, won't be constrained by such calls.

Any thoughts?  Suggestions for better names for the handler
constructors are also appreciated.

There is another problem with checkHandlers that will come up when we
get to handler insertion.  The problem is that it doesn't see the
stubs that get inserted by the backend for cont-handler pairs, or for
handlers.  It seems reasonable to me that we might want to insert
exception stack manipulations in those stubs.  Although on second
thought, maybe this isn't a problem, because we can always create
stubs in the SSA if we need.  Never mind.