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