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

[Eli Friedman via Phabricator via llvm-commits]

efriedma updated this revision to Diff 169900.
efriedma added a comment.

Took another shot at the wording.  This should be a bit more explicit about what we're assuming, and what transforms are allowed.


Repository:
  rL LLVM

https://reviews.llvm.org/D53184

Files:
  docs/LangRef.rst


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D53184.169900.patch
Type: text/x-patch
Size: 1252 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181016/ac7ba454/attachment.bin>