[PATCH] D53184: [LangRef] Clarify semantics of volatile operations.

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

llvmdev thread is titled "Volatile and Inserted Loads/Stores on MMIO​".

> Accesses to device-mapped memory can trap, what is the reason for the compiler to assume that they can't?

If we don't restrict the effects of a volatile load/store, we have to assume it could, at worst, modify any memory that isn't local to the function and unwind the stack, like a call to an unknown function. That would block optimizations around volatile accesses.  That's not what LLVM implements, and it's not what other compilers implement.

> Can we then also expand this part of the reference to clarify that optimizers must not change the number of volatile *or* nonvolatile operations to memory which is only accessed via volatile operations

This is implied by "a volatile load or store may access addresses which do not point to memory", but sure, I can expand that to state it explicitly.


Repository:
  rL LLVM

https://reviews.llvm.org/D53184