RFR(M): 8080289: Intermediate writes in a loop not eliminated by optimizer

[Aleksey Shipilev]

On 06/23/2015 11:57 AM, Roland Westrelin wrote:
>>> If I read the code correctly when
>>> support_IRIW_for_not_multiple_copy_atomic_cpu is true we don’t add a
>>> membar after a volatile store so folding a store with previous ones
>>> would not be a correct optimization because it could remove volatile
>>> stores. This said the current code in StoreNode::Ideal() that folds
>>> back to back stores has the effect or reordering stores on different
>>> slices. So isn’t there a bug already?
>>
>> Let's back up a bit.
>>
>> Short story. Given the program:
>>
>> volatile int y;
>> int x;
>>
>> x = 1;
>> y = 1; // volatile store
>> x = 2;
>> y = 2; // volatile store
>>
>> This transformation is correct:
>>
>> x = 1;
>> x = 2;
>> y = 2; // volatile store
> 
> What about
> 
> volatile int y;
> volatile int x;
> 
> y=1
> x=1
> y=2
> 
> transformed to:
> 
> x=1
> y=2
> 
> ?

I think this is not allowed, since operations over "x" get tied up in
the synchronization order. Here is the simplest counter-example:

   volatile int y;
   volatile int x;
--------------------------
  y = 1;   |  r1 = x;
  x = 1;   |  r2 = y;
  y = 2;   |

  (1, 0) -- forbidden, violates SO-PO consistency (seeing x=1 implies
seeing y=1 in program order before it)

   volatile int y;
   volatile int x;
--------------------------
   ...     |  r1 = x;
  x = 1;   |  r2 = y;
  y = 2;   |

 (1, 0) -- allowed by transformed program, oops.

(These cases are what jcstress sequential consistency tests are about)


Thanks,
-Aleksey


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150623/949cdbc0/signature.asc>