Re: [PATCH v3 3/3] arm64, compiler-context-analysis: Permit alias analysis through __READ_ONCE() with CONFIG_LTO=y

[Gary Guo]

On Tue Feb 17, 2026 at 4:32 PM GMT, Linus Torvalds wrote:
> On Tue, 17 Feb 2026 at 08:23, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> But last time I looked at it - which was admittedly a few years ago -
>> the compilers we supported didn't actually do anything reasonable here
>> (ie the built-in atomics were fundamentally worse than the ones we do
>> by hand, and even basic things like __atomic_load_n() weren't
>> actually; better than just using 'volatile'.
>>
>> Maybe that has changed. We've upgraded minimum compilers since.
>
> I  just checked a few test-cases, and I don't think anything has changed.
>
> All the trivial things where __atomic_load_n(__ATOMIC_RELAXED) *could*
> do better than just our old code using "cast pointer to volatile"
> resulted in no better code generation.

I think compilers are *very* conservative in implementing any optimization
related to atomics, to the extent that normal atomics load/stores are
effectively volatile atomic load/stores and thus the optimization you are
referring to here does not get performed.

However there is some limited optimizations being done to fences, at least I
know in LLVM multiple fences do get merged.

E.g. if you have 

    atomic_thread_fence(memory_order_acquire);
    atomic_thread_fence(memory_order_acq_rel);

the first fence is abosrbed into the second.

>
> So we're sticking to that "cast to volatile" not because it's great,
> but because it continues to be reliable and no worse than the fancy
> modern versions.
>
> But at least it's explicit in the code, not hidden away in code that
> *looks* like it just dereferences another field in a structure.

The implicit load/store is arguably the biggest design failure of C11 atomics.
However we can still typedef like atomic_t or use "cast to _Atomic". But as you
said, currently this does not really yield any benefits over "cast to volatile".

Best,
Gary