An interesting question.
> The current JMM spec implies that x=1 must not be observed
> if the loop doesn't terminate (it has implied this
> for a long time; this isn't a recent change). And almost
> everyone in the discussion is absolutely convinced that this is
> the right answer.
I am not a JMM expert, but I side with the majority.
In fact, it seems clear that x=1 should not be observed prior to the
loop
even if the loop _does_ terminate (because the loop may be a
synchronization). But you guys know this better than I do.
> However, there is some question as to whether or not
> there might be any compilers that would violate this.
In principle, there might be a compiler that violates this
restriction. If
several conditions are met, what you suggested is a legal
transformation:
Condition 1: As far as I can tell, in any code that's
guaranteed to
run only in a single-threaded environment (which some compiler may
assume),
moving x:=1 prior to the loop is semantically harmless.
AND
Condition 2: This "code motion" is semantics preserving only if
the
compiler can prove that x:=1 doesn't raise an exception, such a page
fault;
because otherwise the optimized program may raise an exception when the
original program wouldn't. If the compiler cannot prove this, it may
be
able to delay such an exception to the original point of x:=1 (various
VLIW
processors proposed such instructions.)
To put Cliff's example into this context, his very nice example assumes
multiple threads.
> Does anyone know if any compiler analysis or transformation
> might make this transformation? For example, if an analysis
> assumed "the only way to exit this loop is to take this
> branch, so this branch must be taken in all executions",
> then it might allow such a transformation.
I can think of one optimization that may perform this powerful code
motion:
Region Scheduling by Gupta and Soffa. The "region" here is a program
dependence graph region; the regions before and after the loop are
control
equivalent, there are no data dependences, and so x:=1 may be
movable. Not
sure though, if the move across loops.
On an "inverse" theme, if you are concerned about moving x:=1 from
before
the to after the loop, then partial dead code elimination is an
optimization
that may perform this code motion, which may also be illegal in a
multithreaded environment.
I don't know (personally) of any compiler that implements either of
these
two transformations so I don't know whether and how they ensure
correctness
for multi-threaded code.
To conclude, I don't know of any compiler that does what you asked
about but
I wouldn't be surprised if there was one.
--Ras
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:08 EDT