Re: Exceptions and dataflow analysis

turnidge@cs.wisc.edu (Todd Turnidge) writes:


> I am looking for information concerning dataflow analysis for
> programming languages with exception handling. I am interested in how
> it is dealt with in existing compilers


In the case of synchronous exceptions (like C++), exceptions (*) are
only seen as arising at call sites. This means that you can model
them as simply extra edges in your control flow graph, and merrily
dataflow along just like you always did. It helps, from a
profitability point of view, to not hoist expressions (+) out of an
exception handler into unexceptional code, but it is legal to do so.
One trick that is useful is to encode these transfers of control
carefully -- in particular, it should be possible for every portion
of your optimizer to manipulate them as a first-class transfer of
control (meaning, for instance, that the optimizer should be able to
change an exceptional transfer of control to label L1 into an
exceptional transfer of control to label L2). It is also the case
that (if you use a sorted PC-range table encoding of your handlers,
like all right-thinking people should) you'll need to defer table
generation until all block reordering is done, so that it will still
be sorted.


This doesn't simplify a multi-language back-end as much as you'd
like, because there is still Fortran and the good old assigned go-to,
which thwarts most efforts at redirecting the target of a branch.


(*) In this discussion, "exception" is what you get when you say
"throw foo", not what you get when you say "max_float*max_float" or
"1/0" or "* (int *) -1".


(+) In this discussion, "expression" is used in the mathematical or
optimizer- writer sense, and not in the vile, disgusting, impure, C++
or C sense. "Expressions" have no side-effects.


The current (SC3.0, SC3.0.1) C++ compilers from Sun (SunPro) treat
exceptions in the way that I describe above.


> and what has been written about it in the literature.


I'm not sure if anything much has been written about it. PC-range
tables are an old trick, but I haven't seen much about optimizing
into exception handlers. I think that Ada exceptions are
asynchornous, which automatically puts the optimizer into a pretty
conservative frame of mind. There was a paper in the 1988 (Atlanta)
PLDI that talked about this a little bit. I wrote a two-part article
for JCLT (bug the moderator) that I wrote in late 1994 that attempts
to at least point out all the problems.


speaking for myself,


David Chase
--

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