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

[Eli Friedman via Phabricator via llvm-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL351772: [LangRef] Clarify semantics of volatile operations. (authored by efriedma, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D53184?vs=181940&id=182838#toc

Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D53184/new/

https://reviews.llvm.org/D53184

Files:
  llvm/trunk/docs/LangRef.rst


Index: llvm/trunk/docs/LangRef.rst
===================================================================
--- llvm/trunk/docs/LangRef.rst
+++ llvm/trunk/docs/LangRef.rst
@@ -2181,6 +2181,24 @@
 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D53184.182838.patch
Type: text/x-patch
Size: 1531 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190122/1ef09082/attachment.bin>