Mark atomics as unsupported on thumbv6m

[nikic]

The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️ Warning ⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

[nagisa]

@bors r+

Recovering this support seems like it’d be fairly straightforward by adding to compiler-builtins the necessary __atomic functions that use the MSR to implement a barrier. But for now this PR reflects reality of us not having these definitions as far as I can tell.

cc @Amanieu

[bors]

📌 Commit 7514610 has been approved by nagisa

It is now in the queue for this repository.

[Amanieu]

As we require that "atomic support" does not use libatomic, we need to indicate that this target does not have native atomics.

To be precise, we require at atomics be lock-free. It is possible to have lock-free atomics backed by a library, such as when OS support is available (such as on armv5te-unknown-linux-gnueabi).

This change is likely to break a lot of existing code using atomic load/store on thumbv6m (cc @japaric). I think this change makes sense for LLVM where you want all atomic operations to be either provided by a library or implemented natively. However Rust doesn't expose libatomic operations so this concern doesn't apply.

I see 2 solutions here:

• Since LLVM doesn't handle atomic load/store any more, automatically lower those to volatile load/store in rustc.
• Do nothing, and tell people using atomic load/store to use volatile load/store instead.

[nikic]

As we require that "atomic support" does not use libatomic, we need to indicate that this target does not have native atomics.

To be precise, we require at atomics be lock-free. It is possible to have lock-free atomics backed by a library, such as when OS support is available (such as on armv5te-unknown-linux-gnueabi).

Right. Just to spell it out the relation explicitly: Lock-free atomic libcalls would use __sync style libcalls (from compiler-builtins), rather than __atomic style libcalls (from libatomic).

This change is likely to break a lot of existing code using atomic load/store on thumbv6m (cc @japaric). I think this change makes sense for LLVM where you want all atomic operations to be either provided by a library or implemented natively. However Rust doesn't expose libatomic operations so this concern doesn't apply.

I see 2 solutions here:

• Since LLVM doesn't handle atomic load/store any more, automatically lower those to volatile load/store in rustc.
• Do nothing, and tell people using atomic load/store to use volatile load/store instead.

If preserving non-CAS atomics for thumbv6m is important, we could probably add something similar to the existing singlethread target option, which would carry a requirement that code for this target must never be linked against libatomic. Lowering atomic load/store to a memory barrier + normal load/store should be fine, as long as the Rust code is never linked against C code using libatomic. I believe that's effectively the implicit assumption we have been making until now.

[thejpster]

What are we supposed to do with all this existing code that uses AtomicUxx load/stores (e.g. on the Raspberry Pi RP2040)? Will it just no longer compile?

[taiki-e]

Yes, they will fail to compile. (Can be checked by using this target specification file)

[jannic]

This would revert #51953 which I think would be wrong. Afaik atomic load and store are available, but CAS is missing, which is covered by atomic_cas: false.

[jamesmunns]

Just adding another voice to this: if this change lands in stable without a mechanism to still use atomic load/stores (even if the underlying rust impl changes), this will be a huge stable to stable regression and breaking change for thumbv6m targets.

[Amanieu]

I opened #99668 to track this.

[jamesmunns]

Thank you @Amanieu !