Overflow exception

[Stephen Weeks]

> > * Setup the handler if there are nontail calls or raising primapps in the scope
> >   of the handler.
> > * Figure out someway to get the direct jump information to the raising primapps
> >   so that they can generate the direct jump of the generic convention as
> >   appropriate.
> 
> I think the second suggestion is the better way to go.  What is the
> "granularity" of the handlers?  I'm fairly sure that in any block you
> either use the generic mechanism or do a direct jump. 

Unfortunately, no.  Handler pushes and pops can occur within blocks.

> So, giving each
> machine-output.sig block an additional Label.t option could be the
> "hint" for whether to jump directly to the handler or to use the generic
> mechanism.  I wouldn't put the global overflow label there when there
> direct jump handler; although we're only proposing this for overflow
> exceptions, in the future we could consider migrating division by zero
> exceptions there as well, which would need a different global label for
> the generic raise.

Actually, my current thinking is to add a new Statement.t to MachineOutput.
Something like

  datatype intCheck = Add | Sub | Mul
  datatype Statement.t = ... | IntCheck of {oper: intCheck, 
					    dst: Operand.t (* option? *),
					    arg1: Operand.t,
					    arg2: Operand.t,
					    overflow: Label.t}


The idea is an IntCheck performs the operation, and if there is an overflow,
does a nearjump to the overflow label (which will do the appropriate local jump
or generic raise).  That way, the backends don't need to know anything about the
exception convention, and we can do different things at different places if we
need.

If this looks reasonable, lemme know, and I'll start on it.