search for: atomic_foo

...d about how closely LLVM IR is tied to both C and X86 in this matter. A weak cmpxchg would go a long way to resolving 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...

Hi, I've been looking at improving atomicrmw & cmpxchg code more, particularly on architectures using the load-linked/store-conditional model. The summary is that current expansion for cmpxchg seems to happen too late for LLVM to make meaningful use of the opportunities it provides. I'd like to move it earlier and express it in terms of a first-class pair of "load linked"