Re: exception handling and optimization papers?

Mike Stump wrote:


> The way that I think of it, EH just adds some additional edges to the
> basic block information from the control-flow analysis in a manner
> similar to goto, and it adds some values and variables to track during
> data-flow analysis to support more interesting EH specific
> optimizations. The first one is mandatory, the second isn't (unless
> you want to go on to implement the EH specific optimizations).


This works only if exceptions are precise. In a language like Ada which
permits non-precise exceptions, this is too restrictive. You lose
optimization possibilities as a result.


Unprecise exceptions are something of a mixed blessing. You don't get
all the optimization you would get with no exceptions but they still
make reasoning about programs in the presence of exceptions harder. On
the other hand, using precise exceptions and then simply failing to
raise them on arithmetic overflows, range violations, etc, is not a very
good approach either.


In addition, it does nothing to prevent throws being moved out of the
try block in which they should have occured. In C++, this is probably a
legal thing to do, (!) but a compiler that actually did it would be
pretty useless. So, you need some way of erecting a "rabbit proof fence"
around exception blocks, the rabbits, of course, being the instructions
that may raise exceptions which may be caught by the given block.
>
> throw/rethrow (whether explicit or implicit) adds an edge from the
> throw point to the first (innermost) nested catch point, or if there
> is none, out of the function, similar to return, but not the same as
> return. In particular the return value isn't live. As with a goto,
> various scopes can end on the edge and variables in those scopes die
> on the edge.


I am not sure this is quite correct. The draft standard is unclear here.
Maybe revisions have fixed the problem. The draft says that the objects
are destroyed somewhere between the raise and the start of the handler.
You need to make sure that if a destructor throws an exception it gets
handled at the correct scope. This ought to be the scope of the handler
if reasonable semantics are to be retained, but the wording of the draft
standard is unclear and does not mention the exact question at all.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.