<atomic>: Consider using __atomic_load_n/__atomic_store_n for Clang

[StephanTLavavej]

In llvm/llvm-project#62103 (comment) , @efriedma-quic asked us to consider an alternative to the ARM64 __load_acquire/__stlr intrinsics we've started using for MSVC (see #3399 and #3651):

If possible, I'd strongly prefer if you could change the MS STL to use __atomic_load_n/__atomic_store_n. It's not clear to me what the semantics of the target-specific intrinsics are supposed to be, and LLVM optimizations already know how to optimize the existing atomic intrinsics.

(ldapr is part of armv8.3, so I assume MSVC won't generate it unless you pass flags that indicate the target supports it.)

On the one hand, this would mean maintaining dedicated codepaths for Clang. On the other hand, getting compilers to do our work for us is awesome.

[StephanTLavavej]

@barcharcraz says "not now / not yet" for using such intrinsics for Clang, as they would need to match MSVC's atomics ABI, and we need to fully understand any ABI compatibility issues that could arise from use of the Clang intrinsics. We don't want to break ABI by accident. It would be possible to accept such changes if any ABI impact were thoroughly reviewed (as it was when we changed to the __load_acquire/__stlr intrinsics). For example, if __atomic_load_n/__atomic_store_n use a locktable, that is inherently forever super not compatible with what we've been doing in the STL.

[bharsaklemukesh975]

Can I work on this?

[efriedma-quic]

In clang 16 and newer, clang builtins should be compatible with the sequences MSVC emits, at least for sizes 1/2/4/8. (We did recently fix an ABI issue; see https://reviews.llvm.org/D141748 .)

[StephanTLavavej]

@bharsaklemukesh975 - go ahead, AFAIK nobody else is.

[bharsaklemukesh975]

Thanks, @StephanTLavavej ! Can you please also suggest steps to fix this issue, this is my first issue, Thanks!

[StephanTLavavej]

Ah, this is a pretty advanced issue, involving compiler intrinsics. I definitely wouldn't have labeled it as "good first issue". Most of our issues aren't simple to resolve, or they would have been done already.