Re: Exceptions and dataflow analysis

Jeremy Fitzhardinge (jeremy@sw.oz.au) wrote:


: 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?


This issue was a major concern during the recent revision to Ada 83
to produce Ada 95. Since the original language design, instruction
scheduling has become a much more important optimization. It was always
known that overly precise exception semantics were trouble on vector
machines, but now with so many superscalar machines, overly precise
exception semantics are a problem even on run-of-the-mill processors.


Ultimately, we had to revamp the section of the Ada standard that
dealt with the interactions of exceptions and optimizations (the
notorious clause 11.6 of the Ada manual). Two basic "relaxations"
of the semantics are provided:


    1) If a language-defined check fails, the implementation need not
          raise an exception if the result being checked was "dead" anyway.
          For example:
                    Y := Arr[100000];
                    Y := 2;
          Even though the array index is presumably out of bounds, no exception
          need be raised because the result being checked is "dead," since
          it is in a dead store to Y.


    2) If a language-defined check fails and an exception *is* raised, then
          once you get to the exception handler, it may "appear" that the
          exception was raised pretty much anywhere within the sequence of
          statements covered by the handler (there is a more precise definition
          of "pretty much anywhere" of course).


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


Even if you catch the exception, Ada 95 still does not promise that
the handler can localize the site of the raise too closely.


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


See above. If you want to see the exact wording, consult the
Ada 95 reference manual at:


    ftp://sw-eng.falls-church.va.us/public/adaic/standards/95lrm_rat/v6.0/...


-Tucker Taft stt@inmet.com
Intermetrics, Inc.
--

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