|Exceptions and dataflow analysis email@example.com (1995-08-04)|
|Re: Exceptions and dataflow analysis firstname.lastname@example.org (1995-08-08)|
|Re: Exceptions and dataflow analysis email@example.com (1995-08-15)|
|Re: Exceptions and dataflow analysis firstname.lastname@example.org (1995-08-19)|
|Re: Exceptions and dataflow analysis email@example.com (1995-08-20)|
|Re: Exceptions and dataflow analysis firstname.lastname@example.org (1995-08-21)|
|Re: Exceptions and dataflow analysis email@example.com (1995-08-23)|
|From:||firstname.lastname@example.org (Tucker Taft)|
|Date:||Sat, 19 Aug 1995 14:40:01 GMT|
Jeremy Fitzhardinge (email@example.com) 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.
Y := Arr;
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:
-Tucker Taft firstname.lastname@example.org
Return to the
Search the comp.compilers archives again.