[llvm-dev] atomic ops are optimized with incorrect semantics .

[David Chisnall via llvm-dev]

Hi,

It looks as if there are at least two kinds of at least borderline 
undefined behaviour here, which makes it difficult to evaluate this test 
case.

1. The atomic operation is in an infinite loop.
2. The address is a cast from a provenance-free integer.

That said, I don't believe that this optimisation is taking advantage of 
either of those.  The atomic compare and exchange is relaxed and so does 
not establish a happens before edge with anything (including itself) and 
there is no guarantee under the C++11 memory model that there is any 
ordering of the loads and stores between threads.  Given that the load 
here is unused, a compare and exchange reduces to a store.  If it were 
sequentially consistent, for example, then this transform would not be 
valid and, indeed, LLVM does not perform the transformation in this case.

David

On 10/02/2020 13:05, Umesh Kalappa via llvm-dev wrote:
> Hi All,
> 
> With the "https://gcc.godbolt.org/z/yBYTrd"  case .
> 
> the atomic is converted to non atomic ops  for x86 like
> 
> from
> xchg dword ptr [100], eax
> to
> mov dword ptr [100], 1
> 
> the pass is responsible for this tranformation was instCombine 
> i.e InstCombiner::visitAtomicRMWInst
> 
> which converts the IR like
>   %0 = atomicrmw xchg i32* inttoptr (i64 100 to i32*), i32 1 monotonic
> to
>   store atomic i32 1, i32* inttoptr (i64 100 to i32*) monotonic, align 4
> 
> which is valid for relax(monotonic) and release ordering as per the code 
> out there.
> 
> we think that,its the inst lowering issue, where the atomic store was 
> lowered to non-atomic store here.
> 
> to work around we changed our case to strong ordering .
> 
> and we are debugging the case with x86 and the same goes with an arm too.
> 
> Any suggestions or thoughts on the transformation? , will be helpful to 
> proceed further.
> 
> FYI, the problem persists with LLVM-9, not with the LLVM-8.
> 
> Thank you
> ~Umesh
> 
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>