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

[Eli Friedman via Phabricator via llvm-commits]

efriedma created this revision.
efriedma added reviewers: hfinkel, cramertj, mkazantsev.

Specifically, clarify the following:

1. Volatile load and store may access addresses that are not memory (MMIO registers, etc.).
2. Volatile load and store do not modify unrelated memory.
3. Volatile load and store do not trap.

Prompted by recent discussion of volatile on llvmdev.  I think this is enough to resolve all the issues brought up in that discussion, at least from the perspective of LangRef.

Currently, there's sort of a split in the LLVM source code about whether volatile operations are allowed to trap; this resolves that dispute in favor of not allowing them to trap.  (This is the opposite of the position I originally took, but thinking about it a bit more it makes sense for the uses we expect.)

Hal brought up the possibility on llvmdev that certain APIs like isSafeToLoadUnconditionally and FindAvailablePtrLoadStore might assume that volatile operations do in fact point to memory; I think we should just treat that as a bug, though.


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,13 @@
 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 access addresses which do not point to memory
+(for example, MMIO registers). Unlike a non-volatile load or store, these
+operations may have side-effects. However, an access to an address which
+does not point to memory must not modify any memory that is accessible by
+the module being compiled, and the compiler may assume volatile operations
+do not trap.
+
 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.169350.patch
Type: text/x-patch
Size: 889 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181012/c8a3d755/attachment.bin>