From: Andrew Trick <atrick@apple.com>
Date: Thu, 31 Jan 2013 00:49:39 +0000 (+0000)
Subject: LangRef: Add a Rationale for volatile rules.
X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=946317d07be338f25b554ab543308490a276b835;p=oota-llvm.git

LangRef: Add a Rationale for volatile rules.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174007 91177308-0d34-0410-b5e6-96231b3b80d8
---

diff --git a/docs/LangRef.rst b/docs/LangRef.rst
index ec34a31cd4c..0bcbe44bd4a 100644
--- a/docs/LangRef.rst
+++ b/docs/LangRef.rst
@@ -1085,6 +1085,16 @@ llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are
 flagged volatile. Likewise, the backend should never split or merge
 target-legal volatile load/store instructions.
 
+.. admonition:: Rationale
+
+ Platforms may rely on volatile loads and stores of natively supported
+ data width to be executed as single instruction. For example, in C
+ this holds for an l-value of volatile primitive type with native
+ hardware support, but not necessarily for aggregate types. The
+ frontend upholds these expectations, which are intentionally
+ unspecified in the IR. The rules above ensure that IR transformation
+ do not violate the frontend's contract with the language.
+
 .. _memmodel:
 
 Memory Model for Concurrent Operations