[libcxx] Switch __cxx_contention_t to int32_t on 32 bit AIX

[mstorsjo]

Summary

I guess this is an ABI break for the 32 bit AIX configuration, but I'm
not sure if that one is meant to be ABI stable yet or not.

Previously, this used int32_t for this type on linux, but int64_t
on all other platforms. This was added in D68480 /
54fa9ecd3088508b05b0c5b5cb52da8a3c188655, but I don't really see
any discussion around this detail there.

Switching this to 32 bit on 32 bit AIX silences these libcxx build
warnings:

In file included from /scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/libcxx/src/atomic.cpp:12:
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1005:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
           ^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:948:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_load(const_cast<__ptr_type>(&__a->__a_value), static_cast<__memory_order_underlying_t>(__order));
           ^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1000:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_fetch_add(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
           ^
/scratch/powerllvm/cpap8006/llvm-project/libcxx-ci/build/aix/include/c++/v1/atomic:1022:12: warning: large atomic operation may incur significant performance penalty; the access size (8 bytes) exceeds the max lock-free size (4  bytes) [-Watomic-alignment]
    return __c11_atomic_fetch_sub(&__a->__a_value, __delta, static_cast<__memory_order_underlying_t>(__order));
           ^
4 warnings generated.

[daltenty]

LGTM, we haven't shipped any of the C++17 and up interfaces on AIX yet, so this seem fine to me.

[mstorsjo]

@ simt can you fill in the reasoning and implications around the different types used for _cxx_contention_t here?

[mstorsjo]

New try, cc @__simt__

[mstorsjo]

@ldionne Would you happen to know what the implications and tradeoffs involved in __cxx_contention_t are, and why so far linux used int32_t while everything else used int64_t, and whether it is reasonable to switch 32 bit AIX to int32_t?

[ldionne]

In D124519#3497376, @mstorsjo wrote:

@ldionne Would you happen to know what the implications and tradeoffs involved in __cxx_contention_t are, and why so far linux used int32_t while everything else used int64_t, and whether it is reasonable to switch 32 bit AIX to int32_t?

Olivier tells me that the contention type should be the platform's ideal Futex type. On Linux that is 32 bits (regardless of 32/64 bit pointer size), but for other platforms it would make sense to make it pointer-sized. If this is fine with @daltenty , I think this is good to go.

libcxx/include/atomic

struct __cxx_atomic_impl : public _Base {
     static_assert(is_trivially_copyable<_Tp>::value,
       "std::atomic<T> requires that 'T' be a trivially copyable type");
 
   _LIBCPP_INLINE_VISIBILITY __cxx_atomic_impl() _NOEXCEPT = default;
   _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR explicit __cxx_atomic_impl(_Tp value) _NOEXCEPT
     : _Base(value) {}
 };
 
-#ifdef __linux__
+#if defined(__linux__) || (defined(_AIX) && !defined(__64BIT__))
     using __cxx_contention_t = int32_t;
 #else
     using __cxx_contention_t = int64_t;
-#endif //__linux__
+#endif // __linux__ || (_AIX && !__64BIT__)
 
 using __cxx_atomic_contention_t = __cxx_atomic_impl<__cxx_contention_t>;
 
 #if defined(_LIBCPP_HAS_NO_THREADS)
 #   define _LIBCPP_HAS_NO_PLATFORM_WAIT
 #endif
 
 // TODO: