NVPTX: atomic load / store instructions with orderings other than Relaxed lead to an LLVM error for target CPUs below `sm_70`

[kulst]

Compiling this code (Godbolt)

#![no_std]
use core::sync::atomic::{AtomicU32, Ordering};

#[panic_handler]
fn panic_handler(_: &core::panic::PanicInfo<'_>) -> ! {
    loop {}
}

static COUNTER: AtomicU32 = AtomicU32::new(0);

#[unsafe(no_mangle)]
fn atomic_load_acquire() -> u32 {
    COUNTER.load(Ordering::Acquire)
}

#[unsafe(no_mangle)]
fn atomic_store_release(val : u32) {
    COUNTER.store(val, Ordering::Release)
}

results in the following LLVM error for target CPUs below sm_70:
rustc-LLVM ERROR: PTX does not support "atomic" for orderings different than"NotAtomic" or "Monotonic" for sm_60 or older, but order is: "acquire".

Atomic ordering support was added with sm_70 and ptx60. Therefore, it is expected that these instructions can not be produced by LLVM.

However, this is somewhat similar to e.g. Release or AcqRelease orderings for atomic loads in general, where we panic instead of producing an LLVM error.
So I would assume, we should also panic in the above case and not produce an LLVM error.

[workingjubilee]

I don't think we should panic or LLVM error. I think we should just pull the atomic types from NVPTX in the absence of sufficient features and perhaps raise the expectations for the supported tuple.

[kulst]

@rustbot label: +O-NVPTX

[RalfJung]

I don't think we should panic or LLVM error. I think we should just pull the atomic types from NVPTX in the absence of sufficient features and perhaps raise the expectations for the supported tuple.

Yeah, Rust pretty much requires all orderings as a baseline, and targets should not advertise supporting atomics if they don't support all orderings. If that's for some reason problematic, we need to have a more fundamental discussion about introducing more fine-grained variants of target_has_atomic.

[kulst]

For NVPTX, I think we need such a fine-grained variant of target_has_atomic.
In general, atomics on NVPTX are a bit messy since LLVM only partially implements them for this target, and they also require specific target features.
Until we have something like that in place, I am in favor of dropping support for atomics completely for it. What is your opinion @kjetilkjeka ?

For reference: I created a Zulip discussion about this topic.