Index: docs/LangRef.rst =================================================================== --- docs/LangRef.rst +++ docs/LangRef.rst @@ -2181,6 +2181,21 @@ operations relative to non-volatile operations. This is not Java's "volatile" and has no cross-thread synchronization behavior. +A volatile load or store may have additional target-specific semantics; +it may have side-effects, and it may access addresses which do not point +to memory (like MMIO registers). This means the compiler may not use a +volatile operation to prove a non-volatile access to that address has +defined behavior. + +The allowed side-effects for volatile accesses are limited. If a +non-volatile store to the pointer value would be legal, a volatile +operation may modify that memory. A volatile operation may not modify +any other memory accessible by the module being compiled. + +The compiler may assume execution will continue after a volatile operation, +so operations with side-effects or undefined behavior can be hoisted past +a volatile operation. + IR-level volatile loads and stores cannot safely be optimized into llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are flagged volatile. Likewise, the backend should never split or merge