[PATCH] D15592: [LICM] Make store promotion work in the face of unordered atomics

[JF Bastien via llvm-commits]

jfb added a comment.

Hans pointed out another issue worth adding a test for: you can't remove all atomic accesses from loops which aren't proven to terminate (or otherwise have I/O, volatile, synchronization):

  [intro.multithread] 24:
  The implementation may assume that any thread will eventually do one of 
  the following:
  — terminate,
  — make a call to a library I/O function,
  — access or modify a volatile object, or
  — perform a synchronization operation or an atomic operation.
  [ Note: This is intended to allow compiler transformations such as 
  removal of empty loops, even when
  termination cannot be proven. —end note ]

Regardless of what the standard says, it's desirable to keep atomic stores inside infinite loops, though IIUC that would be OK for "unordered" (a.k.a. Java) atomics, but not "monotonic" (C++ relaxed)? It all boils down to what LLVM's memory model is compared to C++'s, and I'm not clear on this (at the minimum it should be as strict as the language it's honoring).

He also points at this article <http://dl.acm.org/citation.cfm?doid=1988915.1988922> which he believes would be more profitable profitable to implement (in separate patches). The problem in the past was that LLVM didn't have enough alias information to make this work in common cases, but offers to put us in contact with the author off-list.


http://reviews.llvm.org/D15592