On 1/15/21 5:46 PM, Zebediah Figura (she/her) wrote:
On 1/15/21 10:34 AM, Alexandre Julliard wrote:
Zebediah Figura z.figura12@gmail.com writes:
Signed-off-by: Zebediah Figura z.figura12@gmail.com
v2: avoid 16-bit __atomic_compare_exchange_n()
include/winnt.h | 53 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+)
How are these better than the __sync ones in practice?
I think the only real benefit is atomic exchange; it allows the compiler to maybe yield better code for x86 than our inline assembly (although it surely would never make a difference in practice), and presumably better code for other platforms than a compare-and-swap loop.
The actual practical benefit is probably negligible, but I figured we might as well use a proper compiler intrinsic for atomic swap if there was one available.
__sync GCC builtins are supposedly legacy, but I believe they may also imply a slightly stronger memory model than __atomic.
For instance, notice the additional "dmb ish" on ARM64 for __sync, and the use of "ldaxr" instead of "ldxr" for __atomic here:
https://gcc.godbolt.org/z/vq5Gzv
(Note it may also depend on the compiler, Clang generates the same code with "ldaxr" and no "dmb ish", so either GCC implementation is sub-optimal, or they have different semantics for their builtins).
On X86 of course this won't change anything, because the CPU model is already implying an even stronger model.