[libcxx-commits] [libcxx] [libcxx] atomic min/max (PR #186694)

[via libcxx-commits]

================
@@ -259,6 +261,48 @@ __cxx_atomic_fetch_xor(__cxx_atomic_base_impl<_Tp>* __a, _Tp __pattern, memory_o
       std::addressof(__a->__a_value), __pattern, static_cast<__memory_order_underlying_t>(__order));
 }
 
+template <class _Tp>
+_LIBCPP_HIDE_FROM_ABI _Tp
+__cxx_atomic_fetch_min(__cxx_atomic_base_impl<_Tp> volatile* __a, _Tp __val, memory_order __order) _NOEXCEPT {
+  _Tp __old = __cxx_atomic_load(__a, memory_order_relaxed);
+  _Tp __new;
+  do {
+    __new = __old < __val ? __old : __val;
+  } while (!__cxx_atomic_compare_exchange_weak(__a, std::addressof(__old), __new, __order, memory_order_relaxed));
----------------
gonzalobg wrote:

> I think we should aim to use the builtin first. the c11 builtin and clang's gcc builtin already supports to generate

I am aware that clang has these builtins. The top-level comment of this PR clearly states that this PR intentionally does not use builtins, and that this will be done in a separate PR.

The CAS fallbacks are needed regardless to support compilers without builtin, as well as versions of clang with buggy implementations of these builtins, and must be tested. 

The review of this feature from point-of-view of C++ conformance, and sufficient testing, is completely orthogonal to any subsequent work to optimize the libc++ implementation of this feature, e.g., by using builtins available in compilers that support them and implement them in a bug-free way.

On discord, I was recommended to split work into independently reviewable components, to unblock dependent work as soon as possible. Lack of these C++ APIs is blocking other open libc++ work, so I've intentionally split this work into two PRs:
- This PR: C++ API and tests, unblocks other work in flight.
- Subsequent PR: correctly detect all compilers with bug free support for builtins, and enable builtins in those.

https://github.com/llvm/llvm-project/pull/186694