|exceptions & dataflow firstname.lastname@example.org (David James) (1998-02-03)|
|Re: exceptions & dataflow email@example.com (Anurag Acharya) (1998-02-07)|
|Re: exceptions & dataflow firstname.lastname@example.org (Sergey Solyanik) (1998-02-07)|
|Re: exceptions & dataflow email@example.com (Jason Merrill) (1998-02-08)|
|Re: exceptions & dataflow firstname.lastname@example.org (David L Moore) (1998-02-08)|
|Re: exceptions & dataflow email@example.com (David L Moore) (1998-02-09)|
|Re: exceptions & dataflow firstname.lastname@example.org (Sergey Solyanik) (1998-02-10)|
|Re: exceptions & dataflow email@example.com (Jason Merrill) (1998-02-10)|
|Re: exceptions & dataflow firstname.lastname@example.org (1998-02-10)|
|Re: exceptions & dataflow email@example.com (1998-02-10)|
|Re: exceptions & dataflow firstname.lastname@example.org (Jason Merrill) (1998-02-12)|
|[6 later articles]|
|From:||David L Moore <email@example.com>|
|Date:||8 Feb 1998 13:33:37 -0500|
|Keywords:||dataflow, analysis, Ada|
David James <firstname.lastname@example.org> wrote...
> > We are looking for references about doing data flow analysis in the
> > presence of exceptions.
Sergey Solyanik wrote:
> It does not look like there is much. Steve Muchnik's book seems to
> suggests that widely used approach is to turn optimization off for
> functions with exception handling. It is probably not a way to go for
> Java compilers/JITs, though.
> If you are working on Java-like language, one possible approach is to
> terminate basic blocks at each function call or instruction that can
> throw exceptions. Create conditional edges from these basic blocks to
> every catch block. If there are no finallies in the code, any kind of
> analysis should apply unmodified to the resulting graph.
One of the problems is that most languages don't really address the
issue of optimizing code in the presence of exceptions. Ada is an
exception to this rule; optimization of exceptions is explicitly
There needs to be some leniency in the semantics of a language when an
exception occurs, otherwise optimization is greatly inhibited.
For example, if I have a sequence of statements like.
change value of I
change value of J
change value of -- oops an exception flew out
Then must I and J have been updated when the exception occurs? What
about when the handler is completed? Is it OK for J to be updated and
If the answer is that they must be updated, you can never push a store
down after an instruction that may cause an exception.
So, you need to be able to handle exception handlers in a special way
(assuming that the language gives you this freedom) in order to not
inhibit optimization in the case where no exception occurs. This is
normally the case you are interested in optimizing since exceptions
should be infrequent.
Putting an extra edge in for every possible exception will not do
this; you will end up with an over-constrained flow graph and a slow
Return to the
Search the comp.compilers archives again.