[llvm-commits] [llvm] r102384 - /llvm/trunk/docs/LangRef.html

[Jeffrey Yasskin]

Author: jyasskin
Date: Mon Apr 26 16:21:24 2010
New Revision: 102384

URL: http://llvm.org/viewvc/llvm-project?rev=102384&view=rev
Log:
Consolidate the description of volatile operations, now that some of the
intrinsics have volatile semantics in addition to the load and store
instructions.  

Modified:
    llvm/trunk/docs/LangRef.html

Modified: llvm/trunk/docs/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=102384&r1=102383&r2=102384&view=diff
==============================================================================
--- llvm/trunk/docs/LangRef.html (original)
+++ llvm/trunk/docs/LangRef.html Mon Apr 26 16:21:24 2010
@@ -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 @@
 
 </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 @@
    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 @@
    and an address at which to store it.  The type of the
    '<tt><pointer></tt>' operand must be a pointer to
    the <a href="#t_firstclass">first class</a> type of the
-   '<tt><value></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><value></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 @@
    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 @@
    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 @@
    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