search for: compare_exchang

A question has come up on how to interpret the wording of LLVM's documentation regarding the possible memory ordering for success and failure of atomic compare_exchange operations. >From the LLVM reference: "The success and failure ordering <https://llvm.org/docs/LangRef.html#ordering> arguments specify how this cmpxchg synchronizes with other atomic operations. Both ordering parameters must be at least monotonic , the ordering constraint on failu...

+Dean Michael Berris <dberris at google.com> On Wed, Jan 25, 2017 at 7:01 AM Oleg Ranevskyy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Renato, Dean, Serge, > > Just looked into the code and wanted to share some thoughts. > > This might be a compare_exchange_weak spurious failure. ARM is a weakly > ordered CPU, but I am not sure whether spurious failures are really > possible in a single threaded app. On the other hand, there is no other way > for FDRLogging_init to fail in such a way (return XRAY_LOG_UNINITIALIZED > instead of XRAY_LOG_IN...

...lving this, but it's still difficult to see a path from an IR-level "cmpxchg weak" to optimal "atomicrmw lambda" support in LL/SC backends. Given C like void atomic_foo(int *addr) { int oldval = *addr; do { newval = foo(oldval); } while (__c11_compare_exchange_weak(addr, &oldval, newval)); The cmpxchg representation would be something like: define void @atomic_foo(int *addr) { entry: %firstval = load i32* %addr br label %loop loop: %oldval = phi i32 [%firstval, %entry], [%wrongval, %loop] %newval = call...

...----------- We now expand atomic instructions to load-linked & store-conditional intrinsics just before ISel, but this expansion opens up more optimisation opportunities that LLVM *would* be able to exploit if it saw the control flow earlier. For example the return value of the C++11 and C11 compare_exchange operations is actually whether the exchange succeeded, which leads to some common idioms in Clang-produced IR. >From "if(__c11_compare_exchange_strong(...))": %loaded = cmpxchg i32* %addr, i32 %oldval, i32 %newval seq_cst seq_cst %success = icmp eq i32 %loaded, %oldval br...

...-dev at lists.llvm.org> wrote: > > Hi, > > Indeed, it seems that exactly this happens: "The weak forms (1-2) of the functions are allowed to fail spuriously, that is, act as if *this != expected even if they are equal." (from http://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange ). Because the value returned indicates that they are indeed equal. The reference doesn't say it shouldn't happen in single-threaded scenario, so I don't see a reason to investigate why this happens except curiosity... maybe the mutex is not ready, or CPU cache problem, or it translate...

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This proba...