maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

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

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

llvm-svn: 102384
This commit is contained in:
Jeffrey Yasskin 2010-04-26 21:21:24 +00:00
parent 65654df92c
commit 5d284ae8a0
1 changed files with 37 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
llvm/docs/LangRef.html
View File

@ -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