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

[Philip Reames via llvm-commits]

JF,

I'm going to respond to your points in more detail at a future point, 
but I did want to quickly say that I do not feel it's appropriate to 
keep adding tests for every possible combination of ordered atomics 
optimizations under the sun.  I've gone along so far because the amount 
of work has been less than that required to argue the case, but given 
I'm working on supporting only the unordered variety, I really don't see 
how the ordered ones are relevant beyond a couple of simple tests to 
make sure I don't accidentally include ordered where only unordered was 
intended.

Philip

On 12/17/2015 02:02 PM, JF Bastien wrote:
> 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
>
>
>