Unexpected code generation for volatile atomic RMW operations

[keinflue]

The C++ test case

#include<atomic>

void f(volatile std::atomic<int>& x) {
    x.fetch_add(0, std::memory_order_relaxed);
}

on Clang 18.1.0 x86-64 with -O1 produces

f(std::atomic<int> volatile&):
        mfence
        mov     eax, dword ptr [rdi]
        ret

as does the equivalent C program.

This is surprising, because only a load instead of a RMW operation is emitted. fetch_add is always a RMW operation on the abstract machine, even if the stored value is the same as the one loaded, and the expectation would be that volatile preserves this semantic.

This may or may not be a conformance issue. The standards seem to be unclear about the interpretation of "access" with regards to volatile-qualified RMW operations.

See discussion at https://stackoverflow.com/questions/78776735/semantics-of-volatile-stdatomict and https://stackoverflow.com/questions/78777076/semantics-of-volatile-atomic.

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: None (keinflue)

The C++ test case

#include<atomic>

void f(volatile std::atomic<int>& x) {
    x.fetch_add(0, std::memory_order_relaxed);
}

on Clang 18.1.0 x86-64 with -O1 produces

f(std::atomic<int> volatile&):
        mfence
        mov     eax, dword ptr [rdi]
        ret

as does the equivalent C program.

This is surprising, because only a load instead of a RMW operation is emitted. fetch_add is always a RMW operation on the abstract machine, even if the stored value is the same as the one loaded, and the expectation would be that volatile preserves this semantic.

This may or may not be a conformance issue. The standards seem to be unclear about the interpretation of "access" with regards to volatile-qualified RMW operations.

See discussion at https://stackoverflow.com/questions/78776735/semantics-of-volatile-stdatomict and https://stackoverflow.com/questions/78777076/semantics-of-volatile-atomic.