SSA IL

[Stephen Weeks]

> 1. in the CPS version, we don't selectively include Dec.Bind's depending
> on the VarInfo.t of the var; seems that the only thing affected by the
> VarInfo.t's are globals -- maybe that's correct; unused Dec.Bind's are
> dead code, and eliminated by shrinks; but globals aren't eliminated by
> shrink.

Right.  remove-unused is the combination of three previous separate passes:

	remove-unused-globals
	remove-unused-functions
	remove-unused-constructors

> 2. when should I visit a handler?  At a setHandler or at a use of a
> handler at a non-tail call?  I think the latter; the use of a handler at a
> non-tail call should be dominated by a setHandler of the handler; but we
> can always setHandlers that aren't ever used; something (shrinker?) should
> delete setHandler's for labels that don't have any corresponding non-tail
> calls.

Right.  The following are only there as "annotations" that are checked by the
backend (in SSA.Function.checkHandlers, which I'm currently debugging).

	     | SetExnStackLocal
	     | SetExnStackSlot
	     | SetHandler of Label.t
	     | SetSlotExnStack

The new exceptions implementation that I envision (in the draft that I'm gonna
type in RSN) states at only and each nontail call what the handler is.  It is
then the responsibility of a pass that runs after all SSA optimizations have
completed to compute an "annotation" by inserting the statements above into
basic blocks such that what is stated at the nontail calls is actually
implemented.  There are the usual safety conditions, blah blah.  I'll get to it
soon.

The reason that these 4 statements are in the IL is that I want to be able to
compare lots of different strategies for inserting them.  One strategy is the
old one that we've used for years based on the source program (HandlerPush and
HandlerPop).  And the only way that I can see to do that is to leave them in the
IL and propagate them through all the optimizations.  Anyways, almost all
optimizations should treat them as side effecting statements that should be
preserved.  The only exception is raise-to-jump and the shrinker.  (I just
realized that another part of raise-to-jump is still valid.  Namely, the part
that eliminates handlers that it can prove do not contain a raise in their
dynamic extent.)