6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-08-22 10:29:35 +00:00
Code Issues Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Jeffrey Yasskin 2010-04-26 21:21:24 +00:00
parent c30f6e1c89
commit 93e066d0e2
1 changed files with 37 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
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