[llvm-dev] atomic ops are optimized with incorrect semantics . (original) (raw)

David Chisnall via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 10 06:06:38 PST 2020

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

More information about the llvm-dev mailing list