Re: exceptions & dataflow

"Sergey Solyanik" <>
7 Feb 1998 13:55:01 -0500

          From comp.compilers

Related articles
exceptions & dataflow (David James) (1998-02-03)
Re: exceptions & dataflow (Anurag Acharya) (1998-02-07)
Re: exceptions & dataflow (Sergey Solyanik) (1998-02-07)
Re: exceptions & dataflow (Jason Merrill) (1998-02-08)
Re: exceptions & dataflow (David L Moore) (1998-02-08)
Re: exceptions & dataflow (David L Moore) (1998-02-09)
Re: exceptions & dataflow (Sergey Solyanik) (1998-02-10)
Re: exceptions & dataflow (Jason Merrill) (1998-02-10)
Re: exceptions & dataflow (1998-02-10)
[8 later articles]
| List of all articles for this month |

From: "Sergey Solyanik" <>
Newsgroups: comp.compilers
Date: 7 Feb 1998 13:55:01 -0500
Organization: Bentley Systems, Inc
References: 98-02-025
Keywords: analysis, dataflow

David James <> wrote...
> We are looking for references about doing data flow analysis in the
> presence of exceptions. (ie: ways to handle the basic blocks of the
> control flow analysis with exceptions, and how this affects the data
> flow analysis.) If anyone knows of papers/research in this area,
> could you please direct us to it?

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.

Finallies do seem to complicate things significantly. For normal block
exiting I cannot come up with anything better than duplicating the
code when its practical, and spilling everything when it's not. One
will apparently have to spill everything before any call site as well.

Good thing about finally, though, is that it is either entered through
normal try block exit (i. e. explicit jsr before jump out), but your
either exit a function or transfer to catch block (which was
anticipated by fake edges inserted above). So just spilling before
each call and separating non-unrolled finallies from flow analysis
seems to be enough.

In Java, hardware exceptions can ony happen in very controlled manner
(e. g. to test for null). If your language contains pointers, things
are much worse and you'd have to break basic block with essentially
any pointer dereference when you cannot prove that location exists.

I must confess that I am yet to implement this approach so it is possible
for it to be sheer idiocy. I was, although not very seriously, looking for
papers on exception optimizations and thinking about it at leisure for
a few months, but did not hit much of an existing art :-).

So if you find any reasonable work, please let me know.

Regards --

Sergey Solyanik
Bentley Systems, Inc.


Post a followup to this message

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