[PATCH] D112400: [clang][compiler-rt][atomics] Add `__c11_atomic_fetch_nand` builtin and support `__atomic_fetch_nand` libcall

[Kai Luo via Phabricator via llvm-commits]

lkail added a comment.

> The GCC builtins paint the ABI into a corner.  They accept non-`_Atomic`-qualified types (the C11 spec guarantees only that these operations work on `_Atomic` types).  The goal of the original C++ specification was to allow implementations to use atomic operations for register-sized chunks and fall back to an implementation with an inline lock for larger types, so `std::atomic<T>` would either have a single field of `T` or a `std::atomic_flag` field and a `T` field, depending on the size of `T`.  The goal of the C11 import was to allow `_Atomic(T)` to be ABI-compatible with `std::atomic<T>`.  Implementing this requires that `_Atomic(T)` be allowed to have a different representation to `T`.  GCC messed this up and defined builtins that took a `T*`, not an `_Atomic(T*)`, which forced all GCC-compatible ABIs to have the same representation for `T` and `_Atomic(T)`.  This, in turn, meant that the atomics support library couldn't use inline locks, and had to maintain a pool of locks to use for different types.  This, in turn, means that `_Atomic(T)` silently fails in surprising ways in shared memory, some of the time, depending on the target CPU.  This is a horrible mess and I would like to ensure that we always provide builtins that allow target ABIs to do the right thing, even if Linux and *BSD are trapped in a broken ABI by GCC and legacy compatibility.

Good to know, thanks for your detailed explanation!


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112400/new/

https://reviews.llvm.org/D112400