RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2024-12-03 09:21:02 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Following discussion on llvm-dev ("proposed new rule for getelementptr"),

Browse Source 
add a new "Pointer Aliasing Rules" section.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77216 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Dan Gohman 2009-07-27 18:07:55 +00:00
parent be7b97b773
commit 556ca272fb
1 changed files with 49 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

49
docs/LangRef.html
View File

@ -48,6 +48,7 @@
<li><a href="#gc">Garbage Collector Names</a></li>
<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>
</ol>
</li>
<li><a href="#typesystem">Type System</a>
@ -1243,6 +1244,54 @@ target datalayout = "<i>layout specification</i>"
</div>
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="pointeraliasing">Pointer Aliasing Rules</a>
</div>
<div class="doc_text">
<p>Any memory access must be done though a pointer value associated
with with address range of the memory access, otherwise the behavior
is undefined. Pointer values are associated with address ranges
according to the following rules:</p>
<ul>
<li>A pointer value formed from a <tt>getelementptr</tt> instruction is
associated with the addresses associated with the first operand of
the <tt>getelementptr</tt>.</li>
<li>An addresses of a global variable is associated with the address
range of the variable's storage.</li>
<li>The result value of an allocation instruction is associated with
the address range of the allocated storage.</li>
<li>A null pointer in the default address-space is associated with
no addresses.</li>
<li>A pointer value formed by an <tt>inttoptr</tt> is associated with
all address ranges of all pointer values that contribute (directly
or indirectly) to the computation of the pointer's value.</li>
<li>The result value of a <tt>bitcast</tt> is associated with all
addresses associated with the operand of the <tt>bitcast</tt>.</li>
<li>An integer constant other than zero or a pointer value returned
from a function not defined within LLVM may be associated with address
ranges allocated through mechanisms other than those provided by
LLVM. Such ranges shall not overlap with any ranges of address
allocated by mechanisms provided by LLVM.</li>
</ul>
<p>LLVM IR does not associate types with memory. The result type of a
<tt>load</tt> merely indicates the size and alignment of the memory from
which to load, as well as the interpretation of the value. The first
operand of a <tt>store</tt> similarly only indicates the size and
alignment of the store.</p>
<p>Consequently, type-based alias analysis, aka TBAA, aka
<tt>-fstrict-aliasing</tt>, is not applicable to general unadorned
LLVM IR. <a href="#metadata">Metadata</a> may be used to encode
additional information which specialized optimization passes may use
to implement type-based alias analysis.</p>
</div>
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="typesystem">Type System</a> </div>
<!-- *********************************************************************** -->