diff options
| -rw-r--r-- | llvm/docs/LangRef.rst | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 0843bf503d0..9168648db6e 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -2181,6 +2181,24 @@ volatile operations. The optimizers *may* change the order of volatile 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. +Any volatile operation can have side effects, and any volatile operation +can read and/or modify state which is not accessible via a regular load +or store in this module. Volatile operations may use adresses 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 a given address would be legal, a volatile +operation may modify the memory at that address. A volatile operation +may not modify any other memory accessible by the module being compiled. +A volatile operation may not call any code in the current module. + +The compiler may assume execution will continue after a volatile operation, +so operations which modify memory or may have 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 |
