[libc] Add intrinsic for thread fence to the atomic support

[jhuber6]

Summary

This function mimics the std::atomic_thread_fence function from
<atomic>. This has no uses in source currently, but this will be used by
the proposed RPC client for the GPU mode support. There is varying
support for direct memory ordering for the GPU atomics on shared memory
resources. So the implementation will use relaxed atomics and explicit
memory fences.

Some additional work may need to be done to map this to NVPTX system
level fences.

[lntue]

libc/src/__support/CPP/atomic.h

97

Do we need a guard to check if the builtin __atomic_thread_fence is available?

[jhuber6]

libc/src/__support/CPP/atomic.h

97

We use all the other intrinsics above, so as long as it supports the same built-ins that GNU does it should be provided.
Also, should this function be noexcept or always_inline?

[sivachandra]

libc/src/__support/CPP/atomic.h

97

I am not really worried about the guard check because there is no alternative being proposed. But, this function should at the least use LIBC_INLINE. noexcept is optional as we build the libc with -fno-exceptions anyway.

[jhuber6]

inline -> LIBC_INLINE

I think libstdc++ uses always_inline

[sivachandra]

In D145608#4180187, @jhuber6 wrote:

I think libstdc++ uses always_inline

We follow this in libc: https://libc.llvm.org/dev/code_style.html#inline-functions-defined-in-header-files

libc/src/__support/CPP/atomic.h

T fetch_sub(T decrement, MemoryOrder mem_ord = MemoryOrder::SEQ_CST) {
     return __atomic_fetch_sub(&val, decrement, int(mem_ord));
   }
 
   // Set the value without using an atomic operation. This is useful
   // in initializing atomic values without a constructor.
   void set(T rhs) { val = rhs; }
 };
 
+// Issue a thread fence with the given memory ordering.
+LIBC_INLINE void atomic_thread_fence(MemoryOrder mem_ord) {
+  __atomic_thread_fence(int(mem_ord));
+}
+
 } // namespace cpp
 } // namespace __llvm_libc
 
 #endif // LLVM_LIBC_SRC_SUPPORT_CPP_ATOMIC_H