[jmm-dev] thin-air summary

David Holmes david.holmes at oracle.com
Mon Feb 17 20:14:12 PST 2014


Hi Peter,

On 18/02/2014 2:45 AM, Peter Sewell wrote:
> Dear all,
>
> Mark Batty and I have written a short note trying to summarise the
> thin-air problem as crisply as we can:
>
> http://www.cl.cam.ac.uk/~pes20/cpp/notes42.html
>
> Comments welcome, of course.   We've also been thinking here about
> possible approaches; hopefully we'll have another note about that in a
> few days.

I'm a lay-person when it comes to the formalities of all this but given:

4 Example LB+ctrl+data+ctrl-double (language must allow)

r1 = x;        // reads 42
if (r1 == 42)
   y = r1;
---------------------------
r2 = y;        // reads 42
if (r2 == 42)
   x = 42;
else
   x = 42;

the compiler optimization would elide the conditional and simply do the 
store, so this then reduces to:

r1 = x;        // reads 42
if (r1 == 42)
   y = r1;
---------------------------
r2 = y;        // reads 42
x = 42;

which, as stated, now matches "3 Example LB+ctrl+data+po". But in that 
case I don't understand how you can say that for "5 Example 
LB+ctrl+data+ctrl-single" "the candidate execution that we want to 
forbid here is identical to the execution of the previous example that 
we have to allow" - as 5 has a conditional and 4 no longer does, hence 
they are no longer the same ?

Further/similarly, it would seem based on these examples (and I realize 
that there may well be other examples that show otherwise) that the 
straw-man of prohibiting the (rf+dep) cycle would hold if you first 
reduced the code to its "minimal" form ie once 4 is reduced to 3 there 
is no cycle.

Of course I may have just shifted the problem into one of being able to 
define what a "minimal" form is. :)

David
-----

> Peter
>


More information about the jmm-dev mailing list