csky targets' atomic RMW is not lock-free and may cause data races between load/store and it

In csky, LLVM always generates libcalls (https://github.com/llvm/llvm-project/commit/ec2de7490813a7593dad59f210c7ec41f1a29002), and atomic implementations are provided by libatomic.

https://github.com/rust-lang/rust/blob/c7224e3c954ce54853364c950608c1f0ed47ea85/compiler/rustc_target/src/spec/csky_unknown_linux_gnuabiv2.rs#L15

However, as mentioned in https://github.com/rust-lang/rust/pull/115577#issuecomment-1732597305, the atomic RMW implementation provided in libatomic.a is not lock-free.

And it violates what the standard library is intended to guarantee.

https://doc.rust-lang.org/nightly/std/sync/atomic/index.html#portability

All atomic types in this module are guaranteed to be lock-free if they’re available. This means they don’t internally acquire a global mutex.

Also, mixing lock-free load/store and non-lock-free RMW can cause data races.

To fix this, we would need to do one of the following:

• Fix libatomic to make the RMW implementation lock-free.
• Fix LLVM to generate atomic instructions instead of libcalls.

It is not impossible to fix this on our end, but it is not very realistic as it would require writing a lot of inline assembly.

cc @Dirreke (mentioned because you are target maintainer)

@rustbot label +A-atomic +I-unsound

Start with compiler/rustc_target/src/spec/csky_unknown_linux_gnuabiv2.rs and the standard library atomic portability documentation, then review the linked LLVM commit and Rust PR #115577. Investigate whether libatomic or LLVM owns the non-lock-free RMW behavior; done means csky atomic RMW operations satisfy the lock-free guarantee without races with load/store operations.