Consolidate the description of volatile operations, now that some of the

intrinsics have volatile semantics in addition to the load and store
instructions.  


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

1 files changed, 37 insertions, 14 deletions

diff --git a/docs/LangRef.html b/docs/LangRef.html
index c1788ada2b..fb3420785e 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -50,6 +50,7 @@
       <li><a href="#moduleasm">Module-Level Inline Assembly</a></li>
       <li><a href="#datalayout">Data Layout</a></li>
       <li><a href="#pointeraliasing">Pointer Aliasing Rules</a></li>
+      <li><a href="#volatile">Volatile Memory Accesses</a></li>
     </ol>
   </li>
   <li><a href="#typesystem">Type System</a>
@@ -1394,6 +1395,24 @@ to implement type-based alias analysis.</p>
 
 </div>
 
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+  <a name="volatile">Volatile Memory Accesses</a>
+</div>
+
+<div class="doc_text">
+
+<p>Certain memory accesses, such as <a href="#i_load"><tt>load</tt></a>s, <a
+href="#i_store"><tt>store</tt></a>s, and <a
+href="#int_memcpy"><tt>llvm.memcpy</tt></a>s may be marked <tt>volatile</tt>.
+The optimizers must not change the number of volatile operations or change their
+order of execution relative to other volatile operations.  The optimizers
+<i>may</i> change the order of volatile operations relative to non-volatile
+operations.  This is not Java's "volatile" and has no cross-thread
+synchronization behavior.</p>
+
+</div>
+
 <!-- *********************************************************************** -->
 <div class="doc_section"> <a name="typesystem">Type System</a> </div>
 <!-- *********************************************************************** -->
@@ -4199,9 +4218,8 @@ Instruction</a> </div>
    from which to load.  The pointer must point to
    a <a href="#t_firstclass">first class</a> type.  If the <tt>load</tt> is
    marked as <tt>volatile</tt>, then the optimizer is not allowed to modify the
-   number or order of execution of this <tt>load</tt> with other
-   volatile <tt>load</tt> and <tt><a href="#i_store">store</a></tt>
-   instructions.</p>
+   number or order of execution of this <tt>load</tt> with other <a
+   href="#volatile">volatile operations</a>.</p>
 
 <p>The optional constant <tt>align</tt> argument specifies the alignment of the
    operation (that is, the alignment of the memory address). A value of 0 or an
@@ -4257,11 +4275,10 @@ Instruction</a> </div>
    and an address at which to store it.  The type of the
    '<tt>&lt;pointer&gt;</tt>' operand must be a pointer to
    the <a href="#t_firstclass">first class</a> type of the
-   '<tt>&lt;value&gt;</tt>' operand. If the <tt>store</tt> is marked
-   as <tt>volatile</tt>, then the optimizer is not allowed to modify the number
-   or order of execution of this <tt>store</tt> with other
-   volatile <tt>load</tt> and <tt><a href="#i_store">store</a></tt>
-   instructions.</p>
+   '<tt>&lt;value&gt;</tt>' operand. If the <tt>store</tt> is marked as
+   <tt>volatile</tt>, then the optimizer is not allowed to modify the number or
+   order of execution of this <tt>store</tt> with other <a
+   href="#volatile">volatile operations</a>.</p>
 
 <p>The optional constant "align" argument specifies the alignment of the
    operation (that is, the alignment of the memory address). A value of 0 or an
@@ -5962,8 +5979,10 @@ LLVM</a>.</p>
    then the caller guarantees that both the source and destination pointers are
    aligned to that boundary.</p>
 
-<p>Volatile accesses should not be deleted if dead, but the access behavior is
-   not very cleanly specified and it is unwise to depend on it.</p>
+<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the
+   <tt>llvm.memcpy</tt> call is a <a href="#volatile">volatile operation</a>.
+   The detailed access behavior is not very cleanly specified and it is unwise
+   to depend on it.</p>
 
 <h5>Semantics:</h5>
 
@@ -6016,8 +6035,10 @@ LLVM</a>.</p>
    then the caller guarantees that the source and destination pointers are
    aligned to that boundary.</p>
 
-<p>Volatile accesses should not be deleted if dead, but the access behavior is
-   not very cleanly specified and it is unwise to depend on it.</p>
+<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the
+   <tt>llvm.memmove</tt> call is a <a href="#volatile">volatile operation</a>.
+   The detailed access behavior is not very cleanly specified and it is unwise
+   to depend on it.</p>
 
 <h5>Semantics:</h5>
 
@@ -6066,8 +6087,10 @@ LLVM</a>.</p>
    then the caller guarantees that the destination pointer is aligned to that
    boundary.</p>
 
-<p>Volatile accesses should not be deleted if dead, but the access behavior is
-   not very cleanly specified and it is unwise to depend on it.</p>
+<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the
+   <tt>llvm.memset</tt> call is a <a href="#volatile">volatile operation</a>.
+   The detailed access behavior is not very cleanly specified and it is unwise
+   to depend on it.</p>
 
 <h5>Semantics:</h5>
 <p>The '<tt>llvm.memset.*</tt>' intrinsics fill "len" bytes of memory starting