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).


David L Moore <dlmoore@molalla.net> writes:
> 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.


Depends where you put the additional edges. You don't actually have
to put an edge from every instruction that might raise a non-precise
exception; you merely need to put an edge at any place where the
effects of previous exceptions must be "visible" and any future
exceptions not yet visible. (Of course, you also need an edge from
each place a precise exception is raised.)


These edges, in effect, constitute your "rabbit-proof fence". In
general, you only need edges from the beginning and end of each
exception block, because Ada allows some latitude to the implementor
with regards to predefined exceptions. However, I believe Ada95 added
or changed some of that, so that may no longer be sufficient. I
believe it is still possible, though, to determine a set of points
where additional edges can be drawn such that legal optimizations are
permitted and illegal ones are not.


--
Bill Leonard
Concurrent Computer Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309
Bill.Leonard@mail.ccur.com
--

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