Re: Exceptions and dataflow analysis

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


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


That is the approach taken in Ada, after long, careful, and agonizing
analysis. (See Section 11.6 in either the Ada-83 or Ada-95 standard.
The details differ in important ways in these two versions, but the
underlying philosophy is the same.)


The underlying philosophy of the Ada approach is that (1) run-time checks
are intended to discover run-time errors, not to control the normal flow
of execution; and (2) a handler for the exception resulting from a
run-time error can be reasonably used to have the program terminate
gracefully, or to continue execution without the result of the failed
computation, but not to correct and resume the failed part of a
computation in a way that depends on detailed knowledge of its state.
Operations that potentially fail run-time checks but otherwise do not
affect the state of the computation can be optimized away (so that the
function


      function Product_Would_Overflow (A, B: Integer) return Boolean is
            Dead_Variable: Integer;
      begin
            Dead_Variable := A * B;
            return False;
      exception
            when Constraint_Error =>
                  return True;
      end Product_Would_Overflow;


is NOT guaranteed to work; dead-variable elimination can optimize the
function body to one containing only the statement "return False;").
Furthermore, operations involving run-time checks can be reordered,
within certain constraints, as long as the net effect is the same in
error-free executions. Thus, in a sequence of statements of the form


            ... [statements potentially failing run-time checks]
            Point_Reached := 1;
            ... [statements potentially failing run-time checks]
            Point_Reached := 2;
            ... [statements potentially failing run-time checks]
            Point_Reached := 3;
            ... [statements potentially failing run-time checks]
            Point_Reached := 4;
            ... [statements potentially failing run-time checks]
      exception
            when others =>
                  case Point_Reached is
                        ...
                  end case;


the value of Point_Reached in side the exception handler is NOT a
reliable indicator of which part of the source code contained the check
that failed. From a programmer's point of view, this means that any
variable potentially modified anywhere in a sequence of statements that
raises an exception should be viewed as having an unknown value at the
point that the exception occurs.


A programmer can assert greater control, inhibiting dead-variable
elimination or code motion, by marking variables as volatile or using the
Inspection_Point pragma of the Ada-95 Safety and Security annex.


|> (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).


No, but I presume that there's an issue of the raising of an exception
and the assignment to some global variable (such as Point_Reached)
happening out of order.


--
Norman H. Cohen ncohen@watson.ibm.com
--

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