translation unit that uses it. Unreferenced <tt>linkonce</tt> globals are
allowed to be discarded.</dd>
+ <dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt>
+ <dd>"<tt>weak</tt>" linkage has the same merging semantics as
+ <tt>linkonce</tt> linkage, except that unreferenced globals with
+ <tt>weak</tt> linkage may not be discarded. This is used for globals that
+ are declared "weak" in C source code.</dd>
+
<dt><tt><b><a name="linkage_common">common</a></b></tt>: </dt>
- <dd>"<tt>common</tt>" linkage is exactly the same as <tt>linkonce</tt>
- linkage, except that unreferenced <tt>common</tt> globals may not be
- discarded. This is used for globals that may be emitted in multiple
- translation units, but that are not guaranteed to be emitted into every
- translation unit that uses them. One example of this is tentative
- definitions in C, such as "<tt>int X;</tt>" at global scope.</dd>
+ <dd>"<tt>common</tt>" linkage is most similar to "<tt>weak</tt>" linkage, but
+ they are used for tentative definitions in C, such as "<tt>int X;</tt>" at
+ global scope.
+ Symbols with "<tt>common</tt>" linkage are merged in the same way as
+ <tt>weak symbols</tt>, and they may not be deleted if unreferenced.
+ <tt>common</tt> symbols may not have an explicit section,
+ must have a zero initializer, and may not be marked '<a
+ href="#globalvars"><tt>constant</tt></a>'. Functions and aliases may not
+ have common linkage.</dd>
- <dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt>
- <dd>"<tt>weak</tt>" linkage is the same as <tt>common</tt> linkage, except
- that some targets may choose to emit different assembly sequences for them
- for target-dependent reasons. This is used for globals that are declared
- "weak" in C source code.</dd>
<dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt>
<dd>"<tt>appending</tt>" linkage may only be applied to global variables of
<div class="doc_text">
-<p>Any memory access must be done though a pointer value associated
+<p>Any memory access must be done through a pointer value associated
with an 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
+ <li>A pointer value formed from a
+ <tt><a href="#i_getelementptr">getelementptr</a></tt> instruction
+ is associated with the addresses associated with the first operand
+ of the <tt>getelementptr</tt>.</li>
+ <li>An address 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
+ no address.</li>
+ <li>A pointer value formed by an
+ <tt><a href="#i_inttoptr">inttoptr</a></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><a href="#i_bitcast">bitcast</a></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
+ LLVM. Such ranges shall not overlap with any ranges of addresses
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>
+<tt><a href="#i_load">load</a></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><a href="#i_store">store</a></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
<h5>Arguments:</h5>
<p>The first argument is always a pointer, and forms the basis of the
- calculation. The remaining arguments are indices, that indicate which of the
+ calculation. The remaining arguments are indices that indicate which of the
elements of the aggregate object are indexed. The interpretation of each
index is dependent on the type being indexed into. The first index always
indexes the pointer value given as the first argument, the second index
calculation.</p>
<p>The type of each index argument depends on the type it is indexing into.
- When indexing into a (packed) structure, only <tt>i32</tt> integer
+ When indexing into a (optionally packed) structure, only <tt>i32</tt> integer
<b>constants</b> are allowed. When indexing into an array, pointer or
- vector, integers of any width are allowed (also non-constants).</p>
+ vector, integers of any width are allowed, and they are not required to be
+ constant.</p>
<p>For example, let's consider a C code fragment and how it gets compiled to
LLVM:</p>
</pre>
<p>If the <tt>inbounds</tt> keyword is present, the result value of the
- <tt>getelementptr</tt> is undefined if the base pointer is not pointing
- into an allocated object, or if any of the addresses formed by successive
- addition of the offsets implied by the indices to the base address is
- outside of the allocated object into which the base pointer points.</p>
+ <tt>getelementptr</tt> is undefined if the base pointer is not an
+ <i>in bounds</i> address of an allocated object, or if any of the addresses
+ that would be formed by successive addition of the offsets implied by the
+ indices to the base address with infinitely precise arithmetic are not an
+ <i>in bounds</i> address of that allocated object.
+ The <i>in bounds</i> addresses for an allocated object are all the addresses
+ that point into the object, plus the address one byte past the end.</p>
<p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to
the base address with silently-wrapping two's complement arithmetic, and
projects / oota-llvm.git / blobdiff