Re: Exceptions and dataflow analysis

chase@centerline.com (David Chase) writes:
>(*) 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.


What about optimisation in languages where random expressions can throw
exceptions of the same form as "deliberate" ones (ones caused by "throw")?
For example, Java will throw a ArrayIndexOutOfBoundsException (phew!)
at the obvious time. In theory this means that array indexes have
(or potentially have) side-effects, and therefore a program could notice
if a compiler reorders the operation with respect to another
global change (or potential one). The upshot is that to maintain
precise semantics, a compiler can't do any reordering, hoisting or CSE
in the presense of otherwise side-effect free operators which can possibly
throw exceptions.


What approach do people take with languages like this? In the language
design, I supose you could declare by fiat that exception throw sites
in a block may be reordered (and Java, at least, doesn't have any way
to return to an exception throw site, so there's no issue of more than
one exception happening out of order). Marc Brandis (in his excellent
thesis "Optimising Compilers for Structured Languages") mentions that
Oberon says that a program either has a defined global state, or
throws an exception. I presume that you can localise the region of
undefined state by catching the exception.


Otherwise, if the language insists that exceptions can only happen in
the order the source suggests they do, then I suppose the best a
compiler can do it try to statically prove certain potential exceptions
can't happen and move those about, and otherwise everything else stays
put.


Is there anything I've missed? How do people handle this?


J
--

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