Re: exceptions & dataflow

David L Moore <dlmoore@ix.netcom.com>
8 Feb 1998 13:33:37 -0500

          From comp.compilers

Related articles
exceptions & dataflow djames@cs.utah.edu (David James) (1998-02-03)
Re: exceptions & dataflow acha@play.cs.ucsb.edu (Anurag Acharya) (1998-02-07)
Re: exceptions & dataflow sergey@solyanik.com (Sergey Solyanik) (1998-02-07)
Re: exceptions & dataflow jason@cygnus.com (Jason Merrill) (1998-02-08)
Re: exceptions & dataflow dlmoore@ix.netcom.com (David L Moore) (1998-02-08)
Re: exceptions & dataflow dlmoore@ix.netcom.com (David L Moore) (1998-02-09)
Re: exceptions & dataflow sergey@solyanik.com (Sergey Solyanik) (1998-02-10)
Re: exceptions & dataflow jason@cygnus.com (Jason Merrill) (1998-02-10)
Re: exceptions & dataflow mcdirmid@beaver.cs.washington.edu (1998-02-10)
Re: exceptions & dataflow jeremy@softway.com.au (1998-02-10)
Re: exceptions & dataflow jason@cygnus.com (Jason Merrill) (1998-02-12)
[6 later articles]
| List of all articles for this month |
From: David L Moore <dlmoore@ix.netcom.com>
Newsgroups: comp.compilers
Date: 8 Feb 1998 13:33:37 -0500
Organization: Netcom
References: 98-02-025 98-02-027
Keywords: dataflow, analysis, Ada

David James <djames@cs.utah.edu> 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
discussed.


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.


        try
{
change value of I
change value of J
change value of -- oops an exception flew out
}
        catch (...)


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
not I?


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


Post a followup to this message

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