[PATCH] D53184: [LangRef] Clarify semantics of volatile operations.
Eli Friedman via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Oct 16 15:20:14 PDT 2018
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>
More information about the llvm-commits
mailing list