[clang] [llvm] Don't optimize out no-op atomics in kernel mode (PR #193562)

[via llvm-commits]

eleviant wrote:

> Really, the problem here is that we're dealing with weird precedent set by MSVC. MSVC has only one way to write atomic accesses, and that way takes a pointer marked "volatile". We don't really want to force all uses of C++ `<atomic>` to use volatile accesses... I'd be worried about performance regressions. I don't really have a good answer here.

Well there may (or may not) be a reason for making them all volatile. The question is why MakeBinaryAtomicValue still emits non-volatile atomicrmw even though intrinsics do have volatile arguments? Shouldn't we check a CallExpr argument and make volatile atomicrmw if argument is also volatile?

https://github.com/llvm/llvm-project/pull/193562