<ol>
<li><a href="#linkage_private">'<tt>private</tt>' Linkage</a></li>
<li><a href="#linkage_linker_private">'<tt>linker_private</tt>' Linkage</a></li>
+ <li><a href="#linkage_linker_private_weak">'<tt>linker_private_weak</tt>' Linkage</a></li>
+ <li><a href="#linkage_linker_private_weak_def_auto">'<tt>linker_private_weak_def_auto</tt>' Linkage</a></li>
<li><a href="#linkage_internal">'<tt>internal</tt>' Linkage</a></li>
<li><a href="#linkage_available_externally">'<tt>available_externally</tt>' Linkage</a></li>
<li><a href="#linkage_linkonce">'<tt>linkonce</tt>' Linkage</a></li>
<ol>
<li><a href="#t_integer">Integer Type</a></li>
<li><a href="#t_floating">Floating Point Types</a></li>
+ <li><a href="#t_x86mmx">X86mmx Type</a></li>
<li><a href="#t_void">Void Type</a></li>
<li><a href="#t_label">Label Type</a></li>
<li><a href="#t_metadata">Metadata Type</a></li>
<li><a href="#t_array">Array Type</a></li>
<li><a href="#t_struct">Structure Type</a></li>
<li><a href="#t_pstruct">Packed Structure Type</a></li>
- <li><a href="#t_union">Union Type</a></li>
<li><a href="#t_vector">Vector Type</a></li>
</ol>
</li>
<li><a href="#int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a></li>
<li><a href="#int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a></li>
<li><a href="#int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a></li>
- <li><a href="#int_readcyclecounter"><tt>llvm.readcyclecounter</tt>' Intrinsic</a></li>
+ <li><a href="#int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a></li>
</ol>
</li>
<li><a href="#int_libc">Standard C Library Intrinsics</a>
what is considered 'well formed'. For example, the following instruction is
syntactically okay, but not well formed:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%x = <a href="#i_add">add</a> i32 1, %x
</pre>
-</div>
<p>because the definition of <tt>%x</tt> does not dominate all of its uses. The
LLVM infrastructure provides a verification pass that may be used to verify
<p>The easy way:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%result = <a href="#i_mul">mul</a> i32 %X, 8
</pre>
-</div>
<p>After strength reduction:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%result = <a href="#i_shl">shl</a> i32 %X, i8 3
</pre>
-</div>
<p>And the hard way:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%0 = <a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
%1 = <a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
%result = <a href="#i_add">add</a> i32 %1, %1
</pre>
-</div>
<p>This last way of multiplying <tt>%X</tt> by 8 illustrates several important
lexical features of LLVM:</p>
forward declarations, and merges symbol table entries. Here is an example of
the "hello world" module:</p>
-<div class="doc_code">
-<pre>
-<i>; Declare the string constant as a global constant.</i>
-<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
+<pre class="doc_code">
+<i>; Declare the string constant as a global constant.</i>
+<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
-<i>; External declaration of the puts function</i>
-<a href="#functionstructure">declare</a> i32 @puts(i8 *) <i>; i32(i8 *)* </i>
+<i>; External declaration of the puts function</i>
+<a href="#functionstructure">declare</a> i32 @puts(i8*) <i>; i32 (i8*)* </i>
<i>; Definition of main function</i>
-define i32 @main() { <i>; i32()* </i>
- <i>; Convert [13 x i8]* to i8 *...</i>
- %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
+define i32 @main() { <i>; i32()* </i>
+ <i>; Convert [13 x i8]* to i8 *...</i>
+ %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8*</i>
- <i>; Call puts function to write out the string to stdout.</i>
- <a href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i>
- <a href="#i_ret">ret</a> i32 0<br>}
+ <i>; Call puts function to write out the string to stdout.</i>
+ <a href="#i_call">call</a> i32 @puts(i8* %cast210) <i>; i32</i>
+ <a href="#i_ret">ret</a> i32 0
+}
<i>; Named metadata</i>
!1 = metadata !{i32 41}
!foo = !{!1, null}
</pre>
-</div>
<p>This example is made up of a <a href="#globalvars">global variable</a> named
"<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>" function,
<dl>
<dt><tt><b><a name="linkage_private">private</a></b></tt></dt>
- <dd>Global values with private linkage are only directly accessible by objects
- in the current module. In particular, linking code into a module with an
- private global value may cause the private to be renamed as necessary to
- avoid collisions. Because the symbol is private to the module, all
- references can be updated. This doesn't show up in any symbol table in the
- object file.</dd>
+ <dd>Global values with "<tt>private</tt>" linkage are only directly accessible
+ by objects in the current module. In particular, linking code into a
+ module with an private global value may cause the private to be renamed as
+ necessary to avoid collisions. Because the symbol is private to the
+ module, all references can be updated. This doesn't show up in any symbol
+ table in the object file.</dd>
<dt><tt><b><a name="linkage_linker_private">linker_private</a></b></tt></dt>
- <dd>Similar to private, but the symbol is passed through the assembler and
- removed by the linker after evaluation. Note that (unlike private
- symbols) linker_private symbols are subject to coalescing by the linker:
- weak symbols get merged and redefinitions are rejected. However, unlike
- normal strong symbols, they are removed by the linker from the final
- linked image (executable or dynamic library).</dd>
+ <dd>Similar to <tt>private</tt>, but the symbol is passed through the
+ assembler and evaluated by the linker. Unlike normal strong symbols, they
+ are removed by the linker from the final linked image (executable or
+ dynamic library).</dd>
+
+ <dt><tt><b><a name="linkage_linker_private_weak">linker_private_weak</a></b></tt></dt>
+ <dd>Similar to "<tt>linker_private</tt>", but the symbol is weak. Note that
+ <tt>linker_private_weak</tt> symbols are subject to coalescing by the
+ linker. The symbols are removed by the linker from the final linked image
+ (executable or dynamic library).</dd>
+
+ <dt><tt><b><a name="linkage_linker_private_weak_def_auto">linker_private_weak_def_auto</a></b></tt></dt>
+ <dd>Similar to "<tt>linker_private_weak</tt>", but it's known that the address
+ of the object is not taken. For instance, functions that had an inline
+ definition, but the compiler decided not to inline it. Note,
+ unlike <tt>linker_private</tt> and <tt>linker_private_weak</tt>,
+ <tt>linker_private_weak_def_auto</tt> may have only <tt>default</tt>
+ visibility. The symbols are removed by the linker from the final linked
+ image (executable or dynamic library).</dd>
<dt><tt><b><a name="linkage_internal">internal</a></b></tt></dt>
<dd>Similar to private, but the value shows as a local symbol
<dt><tt><b><a name="linkage_weak_odr">weak_odr</a></b></tt></dt>
<dd>Some languages allow differing globals to be merged, such as two functions
with different semantics. Other languages, such as <tt>C++</tt>, ensure
- that only equivalent globals are ever merged (the "one definition rule" -
- "ODR"). Such languages can use the <tt>linkonce_odr</tt>
+ that only equivalent globals are ever merged (the "one definition rule"
+ — "ODR"). Such languages can use the <tt>linkonce_odr</tt>
and <tt>weak_odr</tt> linkage types to indicate that the global will only
be merged with equivalent globals. These linkage types are otherwise the
same as their non-<tt>odr</tt> versions.</dd>
it easier to read the IR and make the IR more condensed (particularly when
recursive types are involved). An example of a name specification is:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%mytype = type { %mytype*, i32 }
</pre>
-</div>
<p>You may give a name to any <a href="#typesystem">type</a> except
- "<a href="t_void">void</a>". Type name aliases may be used anywhere a type
+ "<a href="#t_void">void</a>". Type name aliases may be used anywhere a type
is expected with the syntax "%mytype".</p>
<p>Note that type names are aliases for the structural type that they indicate,
region of memory, and all memory objects in LLVM are accessed through
pointers.</p>
+<p>Global variables can be marked with <tt>unnamed_addr</tt> which indicates
+ that the address is not significant, only the content. Constants marked
+ like this can be merged with other constants if they have the same
+ initializer. Note that a constant with significant address <em>can</em>
+ be merged with a <tt>unnamed_addr</tt> constant, the result being a
+ constant whose address is significant.</p>
+
<p>A global variable may be declared to reside in a target-specific numbered
address space. For targets that support them, address spaces may affect how
optimizations are performed and/or what target instructions are used to
<p>For example, the following defines a global in a numbered address space with
an initializer, section, and alignment:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
@G = addrspace(5) constant float 1.0, section "foo", align 4
</pre>
-</div>
</div>
<p>LLVM function definitions consist of the "<tt>define</tt>" keyword, an
optional <a href="#linkage">linkage type</a>, an optional
<a href="#visibility">visibility style</a>, an optional
- <a href="#callingconv">calling convention</a>, a return type, an optional
+ <a href="#callingconv">calling convention</a>,
+ an optional <tt>unnamed_addr</tt> attribute, a return type, an optional
<a href="#paramattrs">parameter attribute</a> for the return type, a function
name, a (possibly empty) argument list (each with optional
<a href="#paramattrs">parameter attributes</a>), optional
<p>LLVM function declarations consist of the "<tt>declare</tt>" keyword, an
optional <a href="#linkage">linkage type</a>, an optional
<a href="#visibility">visibility style</a>, an optional
- <a href="#callingconv">calling convention</a>, a return type, an optional
+ <a href="#callingconv">calling convention</a>,
+ an optional <tt>unnamed_addr</tt> attribute, a return type, an optional
<a href="#paramattrs">parameter attribute</a> for the return type, a function
name, a possibly empty list of arguments, an optional alignment, and an
optional <a href="#gc">garbage collector name</a>.</p>
specified, the function is forced to have at least that much alignment. All
alignments must be a power of 2.</p>
+<p>If the <tt>unnamed_addr</tt> attribute is given, the address is know to not
+ be significant and two identical functions can be merged</p>.
+
<h5>Syntax:</h5>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>]
[<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>]
<ResultType> @<FunctionName> ([argument list])
[<a href="#fnattrs">fn Attrs</a>] [section "name"] [align N]
[<a href="#gc">gc</a>] { ... }
</pre>
-</div>
</div>
optional <a href="#visibility">visibility style</a>.</p>
<h5>Syntax:</h5>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
@<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
</pre>
-</div>
</div>
<div class="doc_text">
<p>Named metadata is a collection of metadata. <a href="#metadata">Metadata
- nodes</a> (but not metadata strings) and null are the only valid operands for
+ nodes</a> (but not metadata strings) are the only valid operands for
a named metadata.</p>
<h5>Syntax:</h5>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
+; Some unnamed metadata nodes, which are referenced by the named metadata.
+!0 = metadata !{metadata !"zero"}
!1 = metadata !{metadata !"one"}
-!name = !{null, !1}
+!2 = metadata !{metadata !"two"}
+; A named metadata.
+!name = !{!0, !1, !2}
</pre>
-</div>
</div>
multiple parameter attributes are needed, they are space separated. For
example:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
declare i32 @printf(i8* noalias nocapture, ...)
declare i32 @atoi(i8 zeroext)
declare signext i8 @returns_signed_char()
</pre>
-</div>
<p>Note that any attributes for the function result (<tt>nounwind</tt>,
<tt>readonly</tt>) come immediately after the argument list.</p>
registers). Use of this attribute is target-specific.</dd>
<dt><tt><b><a name="byval">byval</a></b></tt></dt>
- <dd>This indicates that the pointer parameter should really be passed by value
- to the function. The attribute implies that a hidden copy of the pointee
+ <dd><p>This indicates that the pointer parameter should really be passed by
+ value to the function. The attribute implies that a hidden copy of the
+ pointee
is made between the caller and the callee, so the callee is unable to
modify the value in the callee. This attribute is only valid on LLVM
pointer arguments. It is generally used to pass structs and arrays by
to belong to the caller not the callee (for example,
<tt><a href="#readonly">readonly</a></tt> functions should not write to
<tt>byval</tt> parameters). This is not a valid attribute for return
- values. The byval attribute also supports specifying an alignment with
- the align attribute. This has a target-specific effect on the code
- generator that usually indicates a desired alignment for the synthesized
- stack slot.</dd>
-
- <dt><tt><b>sret</b></tt></dt>
+ values.</p>
+
+ <p>The byval attribute also supports specifying an alignment with
+ the align attribute. It indicates the alignment of the stack slot to
+ form and the known alignment of the pointer specified to the call site. If
+ the alignment is not specified, then the code generator makes a
+ target-specific assumption.</p></dd>
+
+ <dt><tt><b><a name="sret">sret</a></b></tt></dt>
<dd>This indicates that the pointer parameter specifies the address of a
structure that is the return value of the function in the source program.
This pointer must be guaranteed by the caller to be valid: loads and
may only be applied to the first parameter. This is not a valid attribute
for return values. </dd>
- <dt><tt><b>noalias</b></tt></dt>
- <dd>This indicates that the pointer does not alias any global or any other
- parameter. The caller is responsible for ensuring that this is the
- case. On a function return value, <tt>noalias</tt> additionally indicates
- that the pointer does not alias any other pointers visible to the
- caller. For further details, please see the discussion of the NoAlias
- response in
- <a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias
- analysis</a>.</dd>
-
- <dt><tt><b>nocapture</b></tt></dt>
+ <dt><tt><b><a name="noalias">noalias</a></b></tt></dt>
+ <dd>This indicates that pointer values
+ <a href="#pointeraliasing"><i>based</i></a> on the argument or return
+ value do not alias pointer values which are not <i>based</i> on it,
+ ignoring certain "irrelevant" dependencies.
+ For a call to the parent function, dependencies between memory
+ references from before or after the call and from those during the call
+ are "irrelevant" to the <tt>noalias</tt> keyword for the arguments and
+ return value used in that call.
+ The caller shares the responsibility with the callee for ensuring that
+ these requirements are met.
+ For further details, please see the discussion of the NoAlias response in
+ <a href="AliasAnalysis.html#MustMayNo">alias analysis</a>.<br>
+<br>
+ Note that this definition of <tt>noalias</tt> is intentionally
+ similar to the definition of <tt>restrict</tt> in C99 for function
+ arguments, though it is slightly weaker.
+<br>
+ For function return values, C99's <tt>restrict</tt> is not meaningful,
+ while LLVM's <tt>noalias</tt> is.
+ </dd>
+
+ <dt><tt><b><a name="nocapture">nocapture</a></b></tt></dt>
<dd>This indicates that the callee does not make any copies of the pointer
that outlive the callee itself. This is not a valid attribute for return
values.</dd>
- <dt><tt><b>nest</b></tt></dt>
+ <dt><tt><b><a name="nest">nest</a></b></tt></dt>
<dd>This indicates that the pointer parameter can be excised using the
<a href="#int_trampoline">trampoline intrinsics</a>. This is not a valid
attribute for return values.</dd>
<p>Each function may specify a garbage collector name, which is simply a
string:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
define void @f() gc "name" { ... }
</pre>
-</div>
<p>The compiler declares the supported values of <i>name</i>. Specifying a
collector which will cause the compiler to alter its output in order to
<p>Function attributes are simple keywords that follow the type specified. If
multiple attributes are needed, they are space separated. For example:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
define void @f() noinline { ... }
define void @f() alwaysinline { ... }
define void @f() alwaysinline optsize { ... }
define void @f() optsize { ... }
</pre>
-</div>
<dl>
<dt><tt><b>alignstack(<<em>n</em>>)</b></tt></dt>
function into callers whenever possible, ignoring any active inlining size
threshold for this caller.</dd>
+ <dt><tt><b>hotpatch</b></tt></dt>
+ <dd>This attribute indicates that the function should be 'hotpatchable',
+ meaning the function can be patched and/or hooked even while it is
+ loaded into memory. On x86, the function prologue will be preceded
+ by six bytes of padding and will begin with a two-byte instruction.
+ Most of the functions in the Windows system DLLs in Windows XP SP2 or
+ higher were compiled in this fashion.</dd>
+
<dt><tt><b>inlinehint</b></tt></dt>
<dd>This attribute indicates that the source code contained a hint that inlining
this function is desirable (such as the "inline" keyword in C/C++). It
is just a hint; it imposes no requirements on the inliner.</dd>
+ <dt><tt><b>naked</b></tt></dt>
+ <dd>This attribute disables prologue / epilogue emission for the function.
+ This can have very system-specific consequences.</dd>
+
+ <dt><tt><b>noimplicitfloat</b></tt></dt>
+ <dd>This attributes disables implicit floating point instructions.</dd>
+
<dt><tt><b>noinline</b></tt></dt>
<dd>This attribute indicates that the inliner should never inline this
function in any situation. This attribute may not be used together with
the <tt>alwaysinline</tt> attribute.</dd>
- <dt><tt><b>optsize</b></tt></dt>
- <dd>This attribute suggests that optimization passes and code generator passes
- make choices that keep the code size of this function low, and otherwise
- do optimizations specifically to reduce code size.</dd>
+ <dt><tt><b>noredzone</b></tt></dt>
+ <dd>This attribute indicates that the code generator should not use a red
+ zone, even if the target-specific ABI normally permits it.</dd>
<dt><tt><b>noreturn</b></tt></dt>
<dd>This function attribute indicates that the function never returns
unwind or exceptional control flow. If the function does unwind, its
runtime behavior is undefined.</dd>
+ <dt><tt><b>optsize</b></tt></dt>
+ <dd>This attribute suggests that optimization passes and code generator passes
+ make choices that keep the code size of this function low, and otherwise
+ do optimizations specifically to reduce code size.</dd>
+
<dt><tt><b>readnone</b></tt></dt>
<dd>This attribute indicates that the function computes its result (or decides
to unwind an exception) based strictly on its arguments, without
function that doesn't have an <tt>sspreq</tt> attribute or which has
an <tt>ssp</tt> attribute, then the resulting function will have
an <tt>sspreq</tt> attribute.</dd>
-
- <dt><tt><b>noredzone</b></tt></dt>
- <dd>This attribute indicates that the code generator should not use a red
- zone, even if the target-specific ABI normally permits it.</dd>
-
- <dt><tt><b>noimplicitfloat</b></tt></dt>
- <dd>This attributes disables implicit floating point instructions.</dd>
-
- <dt><tt><b>naked</b></tt></dt>
- <dd>This attribute disables prologue / epilogue emission for the function.
- This can have very system-specific consequences.</dd>
</dl>
</div>
concatenated by LLVM and treated as a single unit, but may be separated in
the <tt>.ll</tt> file if desired. The syntax is very simple:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
module asm "inline asm code goes here"
module asm "more can go here"
</pre>
-</div>
<p>The strings can contain any character by escaping non-printable characters.
The escape sequence used is simply "\xx" where "xx" is the two digit hex code
data is to be laid out in memory. The syntax for the data layout is
simply:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
target datalayout = "<i>layout specification</i>"
</pre>
-</div>
<p>The <i>layout specification</i> consists of a list of specifications
separated by the minus sign character ('-'). Each specification starts with
<dt><tt>f<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the alignment for a floating point type of a given bit
- <i>size</i>. The value of <i>size</i> must be either 32 (float) or 64
- (double).</dd>
+ <i>size</i>. Only values of <i>size</i> that are supported by the target
+ will work. 32 (float) and 64 (double) are supported on all targets;
+ 80 or 128 (different flavors of long double) are also supported on some
+ targets.
<dt><tt>a<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the alignment for an aggregate type of a given bit
according to the following rules:</p>
<ul>
- <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>A pointer value is associated with the addresses associated with
+ any value it is <i>based</i> on.
<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 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 addresses
allocated by mechanisms provided by LLVM.</li>
- </ul>
+</ul>
+
+<p>A pointer value is <i>based</i> on another pointer value according
+ to the following rules:</p>
+
+<ul>
+ <li>A pointer value formed from a
+ <tt><a href="#i_getelementptr">getelementptr</a></tt> operation
+ is <i>based</i> on the first operand of the <tt>getelementptr</tt>.</li>
+ <li>The result value of a
+ <tt><a href="#i_bitcast">bitcast</a></tt> is <i>based</i> on the operand
+ of the <tt>bitcast</tt>.</li>
+ <li>A pointer value formed by an
+ <tt><a href="#i_inttoptr">inttoptr</a></tt> is <i>based</i> on all
+ pointer values that contribute (directly or indirectly) to the
+ computation of the pointer's value.</li>
+ <li>The "<i>based</i> on" relationship is transitive.</li>
+</ul>
+
+<p>Note that this definition of <i>"based"</i> is intentionally
+ similar to the definition of <i>"based"</i> in C99, though it is
+ slightly weaker.</p>
<p>LLVM IR does not associate types with memory. The result type of a
<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
+interpretation of the value. The first operand type of a
<tt><a href="#i_store">store</a></tt> similarly only indicates the size
and alignment of the store.</p>
<a href="#t_pointer">pointer</a>,
<a href="#t_vector">vector</a>,
<a href="#t_struct">structure</a>,
- <a href="#t_union">union</a>,
<a href="#t_array">array</a>,
<a href="#t_label">label</a>,
<a href="#t_metadata">metadata</a>.
<td><a href="#t_primitive">primitive</a></td>
<td><a href="#t_label">label</a>,
<a href="#t_void">void</a>,
+ <a href="#t_integer">integer</a>,
<a href="#t_floating">floating point</a>,
+ <a href="#t_x86mmx">x86mmx</a>,
<a href="#t_metadata">metadata</a>.</td>
</tr>
<tr>
<a href="#t_pointer">pointer</a>,
<a href="#t_struct">structure</a>,
<a href="#t_pstruct">packed structure</a>,
- <a href="#t_union">union</a>,
<a href="#t_vector">vector</a>,
<a href="#t_opaque">opaque</a>.
</td>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection"> <a name="t_x86mmx">X86mmx Type</a> </div>
+
+<div class="doc_text">
+
+<h5>Overview:</h5>
+<p>The x86mmx type represents a value held in an MMX register on an x86 machine. The operations allowed on it are quite limited: parameters and return values, load and store, and bitcast. User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type. There are no arrays, vectors or constants of this type.</p>
+
+<h5>Syntax:</h5>
+<pre>
+ x86mmx
+</pre>
+
+</div>
+
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_void">Void Type</a> </div>
<p>Aggregate Types are a subset of derived types that can contain multiple
member types. <a href="#t_array">Arrays</a>,
- <a href="#t_struct">structs</a>, <a href="#t_vector">vectors</a> and
- <a href="#t_union">unions</a> are aggregate types.</p>
-
-</div>
+ <a href="#t_struct">structs</a>, and <a href="#t_vector">vectors</a> are
+ aggregate types.</p>
</div>
<h5>Overview:</h5>
<p>The function type can be thought of as a function signature. It consists of
a return type and a list of formal parameter types. The return type of a
- function type is a scalar type, a void type, a struct type, or a union
- type. If the return type is a struct type then all struct elements must be
- of first class types, and the struct must have at least one element.</p>
+ function type is a first class type or a void type.</p>
<h5>Syntax:</h5>
<pre>
</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_union">Union Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>A union type describes an object with size and alignment suitable for
- an object of any one of a given set of types (also known as an "untagged"
- union). It is similar in concept and usage to a
- <a href="#t_struct">struct</a>, except that all members of the union
- have an offset of zero. The elements of a union may be any type that has a
- size. Unions must have at least one member - empty unions are not allowed.
- </p>
-
-<p>The size of the union as a whole will be the size of its largest member,
- and the alignment requirements of the union as a whole will be the largest
- alignment requirement of any member.</p>
-
-<p>Union members are accessed using '<tt><a href="#i_load">load</a></tt> and
- '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a field with
- the '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.
- Since all members are at offset zero, the getelementptr instruction does
- not affect the address, only the type of the resulting pointer.</p>
-
-<h5>Syntax:</h5>
-<pre>
- union { <type list> }
-</pre>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>union { i32, i32*, float }</tt></td>
- <td class="left">A union of three types: an <tt>i32</tt>, a pointer to
- an <tt>i32</tt>, and a <tt>float</tt>.</td>
- </tr><tr class="layout">
- <td class="left">
- <tt>union { float, i32 (i32) * }</tt></td>
- <td class="left">A union, where the first element is a <tt>float</tt> and the
- second element is a <a href="#t_pointer">pointer</a> to a
- <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
- an <tt>i32</tt>.</td>
- </tr>
-</table>
-
-</div>
-
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_pointer">Pointer Type</a> </div>
href="#t_array">array</a> of four <tt>i32</tt> values.</td>
</tr>
<tr class="layout">
- <td class="left"><tt>i32 (i32 *) *</tt></td>
+ <td class="left"><tt>i32 (i32*) *</tt></td>
<td class="left"> A <a href="#t_pointer">pointer</a> to a <a
href="#t_function">function</a> that takes an <tt>i32*</tt>, returning an
<tt>i32</tt>.</td>
< <# elements> x <elementtype> >
</pre>
-<p>The number of elements is a constant integer value; elementtype may be any
- integer or floating point type.</p>
+<p>The number of elements is a constant integer value larger than 0; elementtype
+ may be any integer or floating point type. Vectors of size zero are not
+ allowed, and pointers are not allowed as the element type.</p>
<h5>Examples:</h5>
<table class="layout">
they match the long double format on your target. All hexadecimal formats
are big-endian (sign bit at the left).</p>
+<p>There are no constants of type x86mmx.</p>
</div>
<!-- ======================================================================= -->
the number and types of elements must match those specified by the
type.</dd>
- <dt><b>Union constants</b></dt>
- <dd>Union constants are represented with notation similar to a structure with
- a single element - that is, a single typed element surrounded
- by braces (<tt>{}</tt>)). For example: "<tt>{ i32 4 }</tt>". The
- <a href="#t_union">union type</a> can be initialized with a single-element
- struct as long as the type of the struct element matches the type of
- one of the union members.</dd>
-
<dt><b>Array constants</b></dt>
<dd>Array constants are represented with notation similar to array type
definitions (a comma separated list of elements, surrounded by square
have <a href="#t_pointer">pointer</a> type. For example, the following is a
legal LLVM file:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
@X = global i32 17
@Y = global i32 42
@Z = global [2 x i32*] [ i32* @X, i32* @Y ]
</pre>
-</div>
</div>
<p>The string '<tt>undef</tt>' can be used anywhere a constant is expected, and
indicates that the user of the value may receive an unspecified bit-pattern.
- Undefined values may be of any type (other than label or void) and be used
- anywhere a constant is permitted.</p>
+ Undefined values may be of any type (other than '<tt>label</tt>'
+ or '<tt>void</tt>') and be used anywhere a constant is permitted.</p>
<p>Undefined values are useful because they indicate to the compiler that the
program is well defined no matter what value is used. This gives the
surprising) transformations that are valid (in pseudo IR):</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%A = add %X, undef
%B = sub %X, undef
%C = xor %X, undef
%B = undef
%C = undef
</pre>
-</div>
<p>This is safe because all of the output bits are affected by the undef bits.
-Any output bit can have a zero or one depending on the input bits.</p>
+ Any output bit can have a zero or one depending on the input bits.</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%A = or %X, undef
%B = and %X, undef
Safe:
%A = undef
%B = undef
</pre>
-</div>
<p>These logical operations have bits that are not always affected by the input.
-For example, if "%X" has a zero bit, then the output of the 'and' operation will
-always be a zero, no matter what the corresponding bit from the undef is. As
-such, it is unsafe to optimize or assume that the result of the and is undef.
-However, it is safe to assume that all bits of the undef could be 0, and
-optimize the and to 0. Likewise, it is safe to assume that all the bits of
-the undef operand to the or could be set, allowing the or to be folded to
--1.</p>
-
-<div class="doc_code">
-<pre>
+ For example, if <tt>%X</tt> has a zero bit, then the output of the
+ '<tt>and</tt>' operation will always be a zero for that bit, no matter what
+ the corresponding bit from the '<tt>undef</tt>' is. As such, it is unsafe to
+ optimize or assume that the result of the '<tt>and</tt>' is '<tt>undef</tt>'.
+ However, it is safe to assume that all bits of the '<tt>undef</tt>' could be
+ 0, and optimize the '<tt>and</tt>' to 0. Likewise, it is safe to assume that
+ all the bits of the '<tt>undef</tt>' operand to the '<tt>or</tt>' could be
+ set, allowing the '<tt>or</tt>' to be folded to -1.</p>
+
+<pre class="doc_code">
%A = select undef, %X, %Y
%B = select undef, 42, %Y
%C = select %X, %Y, undef
%B = undef
%C = undef
</pre>
-</div>
-<p>This set of examples show that undefined select (and conditional branch)
-conditions can go "either way" but they have to come from one of the two
-operands. In the %A example, if %X and %Y were both known to have a clear low
-bit, then %A would have to have a cleared low bit. However, in the %C example,
-the optimizer is allowed to assume that the undef operand could be the same as
-%Y, allowing the whole select to be eliminated.</p>
+<p>This set of examples shows that undefined '<tt>select</tt>' (and conditional
+ branch) conditions can go <em>either way</em>, but they have to come from one
+ of the two operands. In the <tt>%A</tt> example, if <tt>%X</tt> and
+ <tt>%Y</tt> were both known to have a clear low bit, then <tt>%A</tt> would
+ have to have a cleared low bit. However, in the <tt>%C</tt> example, the
+ optimizer is allowed to assume that the '<tt>undef</tt>' operand could be the
+ same as <tt>%Y</tt>, allowing the whole '<tt>select</tt>' to be
+ eliminated.</p>
-
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%A = xor undef, undef
%B = undef
%E = undef
%F = undef
</pre>
-</div>
-<p>This example points out that two undef operands are not necessarily the same.
-This can be surprising to people (and also matches C semantics) where they
-assume that "X^X" is always zero, even if X is undef. This isn't true for a
-number of reasons, but the short answer is that an undef "variable" can
-arbitrarily change its value over its "live range". This is true because the
-"variable" doesn't actually <em>have a live range</em>. Instead, the value is
-logically read from arbitrary registers that happen to be around when needed,
-so the value is not necessarily consistent over time. In fact, %A and %C need
-to have the same semantics or the core LLVM "replace all uses with" concept
-would not hold.</p>
+<p>This example points out that two '<tt>undef</tt>' operands are not
+ necessarily the same. This can be surprising to people (and also matches C
+ semantics) where they assume that "<tt>X^X</tt>" is always zero, even
+ if <tt>X</tt> is undefined. This isn't true for a number of reasons, but the
+ short answer is that an '<tt>undef</tt>' "variable" can arbitrarily change
+ its value over its "live range". This is true because the variable doesn't
+ actually <em>have a live range</em>. Instead, the value is logically read
+ from arbitrary registers that happen to be around when needed, so the value
+ is not necessarily consistent over time. In fact, <tt>%A</tt> and <tt>%C</tt>
+ need to have the same semantics or the core LLVM "replace all uses with"
+ concept would not hold.</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%A = fdiv undef, %X
%B = fdiv %X, undef
Safe:
%A = undef
b: unreachable
</pre>
-</div>
<p>These examples show the crucial difference between an <em>undefined
-value</em> and <em>undefined behavior</em>. An undefined value (like undef) is
-allowed to have an arbitrary bit-pattern. This means that the %A operation
-can be constant folded to undef because the undef could be an SNaN, and fdiv is
-not (currently) defined on SNaN's. However, in the second example, we can make
-a more aggressive assumption: because the undef is allowed to be an arbitrary
-value, we are allowed to assume that it could be zero. Since a divide by zero
-has <em>undefined behavior</em>, we are allowed to assume that the operation
-does not execute at all. This allows us to delete the divide and all code after
-it: since the undefined operation "can't happen", the optimizer can assume that
-it occurs in dead code.
-</p>
-
-<div class="doc_code">
-<pre>
+ value</em> and <em>undefined behavior</em>. An undefined value (like
+ '<tt>undef</tt>') is allowed to have an arbitrary bit-pattern. This means that
+ the <tt>%A</tt> operation can be constant folded to '<tt>undef</tt>', because
+ the '<tt>undef</tt>' could be an SNaN, and <tt>fdiv</tt> is not (currently)
+ defined on SNaN's. However, in the second example, we can make a more
+ aggressive assumption: because the <tt>undef</tt> is allowed to be an
+ arbitrary value, we are allowed to assume that it could be zero. Since a
+ divide by zero has <em>undefined behavior</em>, we are allowed to assume that
+ the operation does not execute at all. This allows us to delete the divide and
+ all code after it. Because the undefined operation "can't happen", the
+ optimizer can assume that it occurs in dead code.</p>
+
+<pre class="doc_code">
a: store undef -> %X
b: store %X -> undef
Safe:
a: <deleted>
b: unreachable
</pre>
-</div>
-<p>These examples reiterate the fdiv example: a store "of" an undefined value
-can be assumed to not have any effect: we can assume that the value is
-overwritten with bits that happen to match what was already there. However, a
-store "to" an undefined location could clobber arbitrary memory, therefore, it
-has undefined behavior.</p>
+<p>These examples reiterate the <tt>fdiv</tt> example: a store <em>of</em> an
+ undefined value can be assumed to not have any effect; we can assume that the
+ value is overwritten with bits that happen to match what was already there.
+ However, a store <em>to</em> an undefined location could clobber arbitrary
+ memory, therefore, it has undefined behavior.</p>
</div>
<p>Trap value behavior is defined in terms of value <i>dependence</i>:</p>
-<p>
<ul>
<li>Values other than <a href="#i_phi"><tt>phi</tt></a> nodes depend on
their operands.</li>
(including loads and stores implied by intrinsics such as
<a href="#int_memcpy"><tt>@llvm.memcpy</tt></a>.)</li>
-<!-- TODO: In the case of multiple threads, this only applies to loads and
- stores from the same thread as the store, or which are sequenced after the
- store by synchronization. -->
+<!-- TODO: In the case of multiple threads, this only applies if the store
+ "happens-before" the load or store. -->
<!-- TODO: floating-point exception state -->
<li>An instruction with externally visible side effects depends on the most
recent preceding instruction with externally visible side effects, following
- the order in the IR. (This includes volatile loads and stores.)</li>
+ the order in the IR. (This includes
+ <a href="#volatile">volatile operations</a>.)</li>
<li>An instruction <i>control-depends</i> on a
<a href="#terminators">terminator instruction</a>
<li>Dependence is transitive.</li>
</ul>
-</p>
<p>Whenever a trap value is generated, all values which depend on it evaluate
to trap. If they have side effects, the evoke their side effects as if each
<p>Here are some examples:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
entry:
%trap = sub nuw i32 0, 1 ; Results in a trap value.
%still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0.
; so this is defined (ignoring earlier
; undefined behavior in this example).
</pre>
-</div>
</div>
the address of the entry block is illegal.</p>
<p>This value only has defined behavior when used as an operand to the
- '<a href="#i_indirectbr"><tt>indirectbr</tt></a>' instruction or for comparisons
- against null. Pointer equality tests between labels addresses is undefined
- behavior - though, again, comparison against null is ok, and no label is
- equal to the null pointer. This may also be passed around as an opaque
- pointer sized value as long as the bits are not inspected. This allows
- <tt>ptrtoint</tt> and arithmetic to be performed on these values so long as
- the original value is reconstituted before the <tt>indirectbr</tt>.</p>
+ '<a href="#i_indirectbr"><tt>indirectbr</tt></a>' instruction, or for
+ comparisons against null. Pointer equality tests between labels addresses
+ results in undefined behavior — though, again, comparison against null
+ is ok, and no label is equal to the null pointer. This may be passed around
+ as an opaque pointer sized value as long as the bits are not inspected. This
+ allows <tt>ptrtoint</tt> and arithmetic to be performed on these values so
+ long as the original value is reconstituted before the <tt>indirectbr</tt>
+ instruction.</p>
-<p>Finally, some targets may provide defined semantics when
- using the value as the operand to an inline assembly, but that is target
- specific.
- </p>
+<p>Finally, some targets may provide defined semantics when using the value as
+ the operand to an inline assembly, but that is target specific.</p>
</div>
to be used as constants. Constant expressions may be of
any <a href="#t_firstclass">first class</a> type and may involve any LLVM
operation that does not have side effects (e.g. load and call are not
- supported). The following is the syntax for constant expressions:</p>
+ supported). The following is the syntax for constant expressions:</p>
<dl>
- <dt><b><tt>trunc ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>trunc (CST to TYPE)</tt></b></dt>
<dd>Truncate a constant to another type. The bit size of CST must be larger
than the bit size of TYPE. Both types must be integers.</dd>
- <dt><b><tt>zext ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>zext (CST to TYPE)</tt></b></dt>
<dd>Zero extend a constant to another type. The bit size of CST must be
- smaller or equal to the bit size of TYPE. Both types must be
- integers.</dd>
+ smaller than the bit size of TYPE. Both types must be integers.</dd>
- <dt><b><tt>sext ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>sext (CST to TYPE)</tt></b></dt>
<dd>Sign extend a constant to another type. The bit size of CST must be
- smaller or equal to the bit size of TYPE. Both types must be
- integers.</dd>
+ smaller than the bit size of TYPE. Both types must be integers.</dd>
- <dt><b><tt>fptrunc ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>fptrunc (CST to TYPE)</tt></b></dt>
<dd>Truncate a floating point constant to another floating point type. The
size of CST must be larger than the size of TYPE. Both types must be
floating point.</dd>
- <dt><b><tt>fpext ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>fpext (CST to TYPE)</tt></b></dt>
<dd>Floating point extend a constant to another type. The size of CST must be
smaller or equal to the size of TYPE. Both types must be floating
point.</dd>
- <dt><b><tt>fptoui ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>fptoui (CST to TYPE)</tt></b></dt>
<dd>Convert a floating point constant to the corresponding unsigned integer
constant. TYPE must be a scalar or vector integer type. CST must be of
scalar or vector floating point type. Both CST and TYPE must be scalars,
or vectors of the same number of elements. If the value won't fit in the
integer type, the results are undefined.</dd>
- <dt><b><tt>fptosi ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>fptosi (CST to TYPE)</tt></b></dt>
<dd>Convert a floating point constant to the corresponding signed integer
constant. TYPE must be a scalar or vector integer type. CST must be of
scalar or vector floating point type. Both CST and TYPE must be scalars,
or vectors of the same number of elements. If the value won't fit in the
integer type, the results are undefined.</dd>
- <dt><b><tt>uitofp ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>uitofp (CST to TYPE)</tt></b></dt>
<dd>Convert an unsigned integer constant to the corresponding floating point
constant. TYPE must be a scalar or vector floating point type. CST must be
of scalar or vector integer type. Both CST and TYPE must be scalars, or
vectors of the same number of elements. If the value won't fit in the
floating point type, the results are undefined.</dd>
- <dt><b><tt>sitofp ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>sitofp (CST to TYPE)</tt></b></dt>
<dd>Convert a signed integer constant to the corresponding floating point
constant. TYPE must be a scalar or vector floating point type. CST must be
of scalar or vector integer type. Both CST and TYPE must be scalars, or
vectors of the same number of elements. If the value won't fit in the
floating point type, the results are undefined.</dd>
- <dt><b><tt>ptrtoint ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>ptrtoint (CST to TYPE)</tt></b></dt>
<dd>Convert a pointer typed constant to the corresponding integer constant
<tt>TYPE</tt> must be an integer type. <tt>CST</tt> must be of pointer
type. The <tt>CST</tt> value is zero extended, truncated, or unchanged to
make it fit in <tt>TYPE</tt>.</dd>
- <dt><b><tt>inttoptr ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>inttoptr (CST to TYPE)</tt></b></dt>
<dd>Convert a integer constant to a pointer constant. TYPE must be a pointer
type. CST must be of integer type. The CST value is zero extended,
truncated, or unchanged to make it fit in a pointer size. This one is
<i>really</i> dangerous!</dd>
- <dt><b><tt>bitcast ( CST to TYPE )</tt></b></dt>
+ <dt><b><tt>bitcast (CST to TYPE)</tt></b></dt>
<dd>Convert a constant, CST, to another TYPE. The constraints of the operands
are the same as those for the <a href="#i_bitcast">bitcast
instruction</a>.</dd>
- <dt><b><tt>getelementptr ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
- <dt><b><tt>getelementptr inbounds ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
+ <dt><b><tt>getelementptr (CSTPTR, IDX0, IDX1, ...)</tt></b></dt>
+ <dt><b><tt>getelementptr inbounds (CSTPTR, IDX0, IDX1, ...)</tt></b></dt>
<dd>Perform the <a href="#i_getelementptr">getelementptr operation</a> on
constants. As with the <a href="#i_getelementptr">getelementptr</a>
instruction, the index list may have zero or more indexes, which are
required to make sense for the type of "CSTPTR".</dd>
- <dt><b><tt>select ( COND, VAL1, VAL2 )</tt></b></dt>
+ <dt><b><tt>select (COND, VAL1, VAL2)</tt></b></dt>
<dd>Perform the <a href="#i_select">select operation</a> on constants.</dd>
- <dt><b><tt>icmp COND ( VAL1, VAL2 )</tt></b></dt>
+ <dt><b><tt>icmp COND (VAL1, VAL2)</tt></b></dt>
<dd>Performs the <a href="#i_icmp">icmp operation</a> on constants.</dd>
- <dt><b><tt>fcmp COND ( VAL1, VAL2 )</tt></b></dt>
+ <dt><b><tt>fcmp COND (VAL1, VAL2)</tt></b></dt>
<dd>Performs the <a href="#i_fcmp">fcmp operation</a> on constants.</dd>
- <dt><b><tt>extractelement ( VAL, IDX )</tt></b></dt>
+ <dt><b><tt>extractelement (VAL, IDX)</tt></b></dt>
<dd>Perform the <a href="#i_extractelement">extractelement operation</a> on
constants.</dd>
- <dt><b><tt>insertelement ( VAL, ELT, IDX )</tt></b></dt>
+ <dt><b><tt>insertelement (VAL, ELT, IDX)</tt></b></dt>
<dd>Perform the <a href="#i_insertelement">insertelement operation</a> on
constants.</dd>
- <dt><b><tt>shufflevector ( VEC1, VEC2, IDXMASK )</tt></b></dt>
+ <dt><b><tt>shufflevector (VEC1, VEC2, IDXMASK)</tt></b></dt>
<dd>Perform the <a href="#i_shufflevector">shufflevector operation</a> on
constants.</dd>
- <dt><b><tt>OPCODE ( LHS, RHS )</tt></b></dt>
+ <dt><b><tt>extractvalue (VAL, IDX0, IDX1, ...)</tt></b></dt>
+ <dd>Perform the <a href="#i_extractvalue">extractvalue operation</a> on
+ constants. The index list is interpreted in a similar manner as indices in
+ a '<a href="#i_getelementptr">getelementptr</a>' operation. At least one
+ index value must be specified.</dd>
+
+ <dt><b><tt>insertvalue (VAL, ELT, IDX0, IDX1, ...)</tt></b></dt>
+ <dd>Perform the <a href="#i_insertvalue">insertvalue operation</a> on
+ constants. The index list is interpreted in a similar manner as indices in
+ a '<a href="#i_getelementptr">getelementptr</a>' operation. At least one
+ index value must be specified.</dd>
+
+ <dt><b><tt>OPCODE (LHS, RHS)</tt></b></dt>
<dd>Perform the specified operation of the LHS and RHS constants. OPCODE may
be any of the <a href="#binaryops">binary</a>
or <a href="#bitwiseops">bitwise binary</a> operations. The constraints
containing the asm needs to align its stack conservatively. An example
inline assembler expression is:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
i32 (i32) asm "bswap $0", "=r,r"
</pre>
-</div>
<p>Inline assembler expressions may <b>only</b> be used as the callee operand of
a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we
have:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
</pre>
-</div>
<p>Inline asms with side effects not visible in the constraint list must be
marked as having side effects. This is done through the use of the
'<tt>sideeffect</tt>' keyword, like so:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
call void asm sideeffect "eieio", ""()
</pre>
-</div>
<p>In some cases inline asms will contain code that will not work unless the
stack is aligned in some way, such as calls or SSE instructions on x86,
contain and should generate its usual stack alignment code in the prologue
if the '<tt>alignstack</tt>' keyword is present:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
call void asm alignstack "eieio", ""()
</pre>
-</div>
<p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come
first.</p>
<div class="doc_text">
<p>The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode
- attached to it that contains a constant integer. If present, the code
- generator will use the integer as the location cookie value when report
+ attached to it that contains a list of constant integers. If present, the
+ code generator will use the integer as the location cookie value when report
errors through the LLVMContext error reporting mechanisms. This allows a
front-end to correlate backend errors that occur with inline asm back to the
source code that produced it. For example:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b>
...
!42 = !{ i32 1234567 }
</pre>
-</div>
<p>It is up to the front-end to make sense of the magic numbers it places in the
- IR.</p>
+ IR. If the MDNode contains multiple constants, the code generator will use
+ the one that corresponds to the line of the asm that the error occurs on.</p>
</div>
example: "<tt>!foo = metadata !{!4, !3}</tt>".
<p>Metadata can be used as function arguments. Here <tt>llvm.dbg.value</tt>
- function is using two metadata arguments.
+ function is using two metadata arguments.</p>
- <div class="doc_code">
- <pre>
+ <pre class="doc_code">
call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
</pre>
- </div></p>
<p>Metadata can be attached with an instruction. Here metadata <tt>!21</tt> is
- attached with <tt>add</tt> instruction using <tt>!dbg</tt> identifier.
+ attached with <tt>add</tt> instruction using <tt>!dbg</tt> identifier.</p>
- <div class="doc_code">
- <pre>
+ <pre class="doc_code">
%indvar.next = add i64 %indvar, 1, !dbg !21
</pre>
- </div></p>
</div>
<h5>Syntax:</h5>
<pre>
- <result> = udiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = udiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = udiv exact <ty> <op1>, <op2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
<p>Division by zero leads to undefined behavior.</p>
+<p>If the <tt>exact</tt> keyword is present, the result value of the
+ <tt>udiv</tt> is a <a href="#trapvalues">trap value</a> if %op1 is not a
+ multiple of %op2 (as such, "((a udiv exact b) mul b) == a").</p>
+
+
<h5>Example:</h5>
<pre>
<result> = udiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
<p>If the <tt>exact</tt> keyword is present, the result value of the
<tt>sdiv</tt> is a <a href="#trapvalues">trap value</a> if the result would
- be rounded or if overflow would occur.</p>
+ be rounded.</p>
<h5>Example:</h5>
<pre>
<h5>Syntax:</h5>
<pre>
- <result> = shl <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = shl <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = shl nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = shl nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = shl nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
vectors, each vector element of <tt>op1</tt> is shifted by the corresponding
shift amount in <tt>op2</tt>.</p>
+<p>If the <tt>nuw</tt> keyword is present, then the shift produces a
+ <a href="#trapvalues">trap value</a> if it shifts out any non-zero bits. If
+ the <tt>nsw</tt> keywrod is present, then the shift produces a
+ <a href="#trapvalues">trap value</a> if it shifts out any bits that disagree
+ with the resultant sign bit. As such, NUW/NSW have the same semantics as
+ they would if the shift were expressed as a mul instruction with the same
+ nsw/nuw bits in (mul %op1, (shl 1, %op2)).</p>
+
<h5>Example:</h5>
<pre>
<result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i>
<h5>Syntax:</h5>
<pre>
- <result> = lshr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = lshr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = lshr exact <ty> <op1>, <op2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
vectors, each vector element of <tt>op1</tt> is shifted by the corresponding
shift amount in <tt>op2</tt>.</p>
+<p>If the <tt>exact</tt> keyword is present, the result value of the
+ <tt>lshr</tt> is a <a href="#trapvalues">trap value</a> if any of the bits
+ shifted out are non-zero.</p>
+
+
<h5>Example:</h5>
<pre>
<result> = lshr i32 4, 1 <i>; yields {i32}:result = 2</i>
<h5>Syntax:</h5>
<pre>
- <result> = ashr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = ashr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ <result> = ashr exact <ty> <op1>, <op2> <i>; yields {ty}:result</i>
</pre>
<h5>Overview:</h5>
the arguments are vectors, each vector element of <tt>op1</tt> is shifted by
the corresponding shift amount in <tt>op2</tt>.</p>
+<p>If the <tt>exact</tt> keyword is present, the result value of the
+ <tt>ashr</tt> is a <a href="#trapvalues">trap value</a> if any of the bits
+ shifted out are non-zero.</p>
+
<h5>Example:</h5>
<pre>
<result> = ashr i32 4, 1 <i>; yields {i32}:result = 2</i>
<h5>Arguments:</h5>
<p>The first operand of an '<tt>extractvalue</tt>' instruction is a value
- of <a href="#t_struct">struct</a>, <a href="#t_union">union</a> or
+ of <a href="#t_struct">struct</a> or
<a href="#t_array">array</a> type. The operands are constant indices to
specify which value to extract in a similar manner as indices in a
'<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.</p>
+ <p>The major differences to <tt>getelementptr</tt> indexing are:</p>
+ <ul>
+ <li>Since the value being indexed is not a pointer, the first index is
+ omitted and assumed to be zero.</li>
+ <li>At least one index must be specified.</li>
+ <li>Not only struct indices but also array indices must be in
+ bounds.</li>
+ </ul>
<h5>Semantics:</h5>
<p>The result is the value at the position in the aggregate specified by the
<h5>Arguments:</h5>
<p>The first operand of an '<tt>insertvalue</tt>' instruction is a value
- of <a href="#t_struct">struct</a>, <a href="#t_union">union</a> or
+ of <a href="#t_struct">struct</a> or
<a href="#t_array">array</a> type. The second operand is a first-class
value to insert. The following operands are constant indices indicating
the position at which to insert the value in a similar manner as indices in a
- '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction. The
+ '<tt><a href="#i_extractvalue">extractvalue</a></tt>' instruction. The
value to insert must have the same type as the value identified by the
indices.</p>
<h5>Syntax:</h5>
<pre>
- <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
+ <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
- volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
+ store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
+ volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
</pre>
<h5>Overview:</h5>
produce less efficient code. An alignment of 1 is always safe.</p>
<p>The optional !nontemporal metadata must reference a single metatadata
- name <index> corresponding to a metadata node with one i32 entry of
+ name <index> corresponding to a metadata node with one i32 entry of
value 1. The existence of the !nontemporal metatadata on the
instruction tells the optimizer and code generator that this load is
not expected to be reused in the cache. The code generator may
indexes a value of the type pointed to (not necessarily the value directly
pointed to, since the first index can be non-zero), etc. The first type
indexed into must be a pointer value, subsequent types can be arrays,
- vectors, structs and unions. Note that subsequent types being indexed into
+ vectors, and structs. Note that subsequent types being indexed into
can never be pointers, since that would require loading the pointer before
continuing calculation.</p>
<p>The type of each index argument depends on the type it is indexing into.
- When indexing into a (optionally packed) structure or union, only <tt>i32</tt>
+ 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, 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>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
struct RT {
char A;
int B[10][20];
return &s[1].Z.B[5][13];
}
</pre>
-</div>
<p>The LLVM code generated by the GCC frontend is:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%RT = <a href="#namedtypes">type</a> { i8 , [10 x [20 x i32]], i8 }
%ST = <a href="#namedtypes">type</a> { i32, double, %RT }
ret i32* %reg
}
</pre>
-</div>
<h5>Semantics:</h5>
<p>In the example above, the first index is indexing into the '<tt>%ST*</tt>'
<h5>Example:</h5>
<pre>
%retval = call i32 @test(i32 %argc)
- call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42) <i>; yields i32</i>
+ call i32 (i8*, ...)* @printf(i8* %msg, i32 12, i8 42) <i>; yields i32</i>
%X = tail call i32 @foo() <i>; yields i32</i>
%Y = tail call <a href="#callingconv">fastcc</a> i32 @foo() <i>; yields i32</i>
call void %foo(i8 97 signext)
instruction and the variable argument handling intrinsic functions are
used.</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
define i32 @test(i32 %X, ...) {
; Initialize variable argument processing
%ap = alloca i8*
declare void @llvm.va_copy(i8*, i8*)
declare void @llvm.va_end(i8*)
</pre>
-</div>
</div>
<h5>Syntax:</h5>
<pre>
- declare i8 *@llvm.frameaddress(i32 <level>)
+ declare i8* @llvm.frameaddress(i32 <level>)
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- declare i8 *@llvm.stacksave()
+ declare i8* @llvm.stacksave()
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- declare void @llvm.stackrestore(i8 * %ptr)
+ declare void @llvm.stackrestore(i8* %ptr)
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- declare i64 @llvm.readcyclecounter( )
+ declare i64 @llvm.readcyclecounter()
</pre>
<h5>Overview:</h5>
all bit widths however.</p>
<pre>
- declare void @llvm.memcpy.p0i8.p0i8.i32(i8 * <dest>, i8 * <src>,
+ declare void @llvm.memcpy.p0i8.p0i8.i32(i8* <dest>, i8* <src>,
i32 <len>, i32 <align>, i1 <isvolatile>)
- declare void @llvm.memcpy.p0i8.p0i8.i64(i8 * <dest>, i8 * <src>,
+ declare void @llvm.memcpy.p0i8.p0i8.i64(i8* <dest>, i8* <src>,
i64 <len>, i32 <align>, i1 <isvolatile>)
</pre>
widths however.</p>
<pre>
- declare void @llvm.memmove.p0i8.p0i8.i32(i8 * <dest>, i8 * <src>,
+ declare void @llvm.memmove.p0i8.p0i8.i32(i8* <dest>, i8* <src>,
i32 <len>, i32 <align>, i1 <isvolatile>)
- declare void @llvm.memmove.p0i8.p0i8.i64(i8 * <dest>, i8 * <src>,
+ declare void @llvm.memmove.p0i8.p0i8.i64(i8* <dest>, i8* <src>,
i64 <len>, i32 <align>, i1 <isvolatile>)
</pre>
<h5>Syntax:</h5>
<p>This is an overloaded intrinsic. You can use llvm.memset on any integer bit
- width and for different address spaces. Not all targets support all bit
- widths however.</p>
+ width and for different address spaces. However, not all targets support all
+ bit widths.</p>
<pre>
- declare void @llvm.memset.p0i8.i32(i8 * <dest>, i8 <val>,
+ declare void @llvm.memset.p0i8.i32(i8* <dest>, i8 <val>,
i32 <len>, i32 <align>, i1 <isvolatile>)
- declare void @llvm.memset.p0i8.i64(i8 * <dest>, i8 <val>,
+ declare void @llvm.memset.p0i8.i64(i8* <dest>, i8 <val>,
i64 <len>, i32 <align>, i1 <isvolatile>)
</pre>
particular byte value.</p>
<p>Note that, unlike the standard libc function, the <tt>llvm.memset</tt>
- intrinsic does not return a value, takes extra alignment/volatile arguments,
- and the destination can be in an arbitrary address space.</p>
+ intrinsic does not return a value and takes extra alignment/volatile
+ arguments. Also, the destination can be in an arbitrary address space.</p>
<h5>Arguments:</h5>
<p>The first argument is a pointer to the destination to fill, the second is the
- byte value to fill it with, the third argument is an integer argument
+ byte value with which to fill it, the third argument is an integer argument
specifying the number of bytes to fill, and the fourth argument is the known
- alignment of destination location.</p>
+ alignment of the destination location.</p>
<p>If the call to this intrinsic has an alignment value that is not 0 or 1,
then the caller guarantees that the destination pointer is aligned to that
<div class="doc_text">
<p>This intrinsic makes it possible to excise one parameter, marked with
- the <tt>nest</tt> attribute, from a function. The result is a callable
+ the <a href="#nest"><tt>nest</tt></a> attribute, from a function.
+ The result is a callable
function pointer lacking the nest parameter - the caller does not need to
provide a value for it. Instead, the value to use is stored in advance in a
"trampoline", a block of memory usually allocated on the stack, which also
pointer has signature <tt>i32 (i32, i32)*</tt>. It can be created as
follows:</p>
-<div class="doc_code">
-<pre>
+<pre class="doc_code">
%tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
%tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
- %p = call i8* @llvm.init.trampoline( i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval )
+ %p = call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval)
%fp = bitcast i8* %p to i32 (i32, i32)*
</pre>
-</div>
-<p>The call <tt>%val = call i32 %fp( i32 %x, i32 %y )</tt> is then equivalent
- to <tt>%val = call i32 %f( i8* %nval, i32 %x, i32 %y )</tt>.</p>
+<p>The call <tt>%val = call i32 %fp(i32 %x, i32 %y)</tt> is then equivalent
+ to <tt>%val = call i32 %f(i8* %nval, i32 %x, i32 %y)</tt>.</p>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
- declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device> )
+ declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)
</pre>
<h5>Overview:</h5>
store i32 4, %ptr
%result1 = load i32* %ptr <i>; yields {i32}:result1 = 4</i>
- call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
+ call void @llvm.memory.barrier(i1 false, i1 true, i1 false, i1 false)
<i>; guarantee the above finishes</i>
store i32 8, %ptr <i>; before this begins</i>
</pre>
support all bit widths however.</p>
<pre>
- declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> )
- declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> )
- declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> )
- declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> )
+ declare i8 @llvm.atomic.cmp.swap.i8.p0i8(i8* <ptr>, i8 <cmp>, i8 <val>)
+ declare i16 @llvm.atomic.cmp.swap.i16.p0i16(i16* <ptr>, i16 <cmp>, i16 <val>)
+ declare i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* <ptr>, i32 <cmp>, i32 <val>)
+ declare i64 @llvm.atomic.cmp.swap.i64.p0i64(i64* <ptr>, i64 <cmp>, i64 <val>)
</pre>
<h5>Overview:</h5>
store i32 4, %ptr
%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 4, %val1 )
+%result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 4, %val1)
<i>; yields {i32}:result1 = 4</i>
%stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 5, %val2 )
+%result2 = call i32 @llvm.atomic.cmp.swap.i32.p0i32(i32* %ptr, i32 5, %val2)
<i>; yields {i32}:result2 = 8</i>
%stored2 = icmp eq i32 %result2, 5 <i>; yields {i1}:stored2 = false</i>
integer bit width. Not all targets support all bit widths however.</p>
<pre>
- declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> )
- declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> )
- declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> )
- declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> )
+ declare i8 @llvm.atomic.swap.i8.p0i8(i8* <ptr>, i8 <val>)
+ declare i16 @llvm.atomic.swap.i16.p0i16(i16* <ptr>, i16 <val>)
+ declare i32 @llvm.atomic.swap.i32.p0i32(i32* <ptr>, i32 <val>)
+ declare i64 @llvm.atomic.swap.i64.p0i64(i64* <ptr>, i64 <val>)
</pre>
<h5>Overview:</h5>
store i32 4, %ptr
%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val1 )
+%result1 = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val1)
<i>; yields {i32}:result1 = 4</i>
%stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val2 )
+%result2 = call i32 @llvm.atomic.swap.i32.p0i32(i32* %ptr, i32 %val2)
<i>; yields {i32}:result2 = 8</i>
%stored2 = icmp eq i32 %result2, 8 <i>; yields {i1}:stored2 = true</i>
any integer bit width. Not all targets support all bit widths however.</p>
<pre>
- declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.add.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.add.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.add.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.add.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<h5>Overview:</h5>
%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
%ptr = bitcast i8* %mallocP to i32*
store i32 4, %ptr
-%result1 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 )
+%result1 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 4)
<i>; yields {i32}:result1 = 4</i>
-%result2 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 )
+%result2 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 2)
<i>; yields {i32}:result2 = 8</i>
-%result3 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 5 )
+%result3 = call i32 @llvm.atomic.load.add.i32.p0i32(i32* %ptr, i32 5)
<i>; yields {i32}:result3 = 10</i>
%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 15</i>
</pre>
support all bit widths however.</p>
<pre>
- declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.sub.i8.p0i32(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.sub.i16.p0i32(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.sub.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.sub.i64.p0i32(i64* <ptr>, i64 <delta>)
</pre>
<h5>Overview:</h5>
%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
%ptr = bitcast i8* %mallocP to i32*
store i32 8, %ptr
-%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 )
+%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 4)
<i>; yields {i32}:result1 = 8</i>
-%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 )
+%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 2)
<i>; yields {i32}:result2 = 4</i>
-%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 5 )
+%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %ptr, i32 5)
<i>; yields {i32}:result3 = 2</i>
%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = -3</i>
</pre>
widths however.</p>
<pre>
- declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.and.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.and.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.and.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.and.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<pre>
- declare i8 @llvm.atomic.load.or.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.or.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.or.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.or.i64.p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.or.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.or.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.or.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.or.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<pre>
- declare i8 @llvm.atomic.load.nand.i8.p0i32( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.nand.i16.p0i32( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.nand.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.nand.i64.p0i32( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.nand.i8.p0i32(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.nand.i16.p0i32(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.nand.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.nand.i64.p0i32(i64* <ptr>, i64 <delta>)
</pre>
<pre>
- declare i8 @llvm.atomic.load.xor.i8.p0i32( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.xor.i16.p0i32( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.xor.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.xor.i64.p0i32( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.xor.i8.p0i32(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.xor.i16.p0i32(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.xor.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.xor.i64.p0i32(i64* <ptr>, i64 <delta>)
</pre>
<h5>Overview:</h5>
%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
%ptr = bitcast i8* %mallocP to i32*
store i32 0x0F0F, %ptr
-%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF )
+%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32(i32* %ptr, i32 0xFF)
<i>; yields {i32}:result0 = 0x0F0F</i>
-%result1 = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF )
+%result1 = call i32 @llvm.atomic.load.and.i32.p0i32(i32* %ptr, i32 0xFF)
<i>; yields {i32}:result1 = 0xFFFFFFF0</i>
-%result2 = call i32 @llvm.atomic.load.or.i32.p0i32( i32* %ptr, i32 0F )
+%result2 = call i32 @llvm.atomic.load.or.i32.p0i32(i32* %ptr, i32 0F)
<i>; yields {i32}:result2 = 0xF0</i>
-%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32( i32* %ptr, i32 0F )
+%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32(i32* %ptr, i32 0F)
<i>; yields {i32}:result3 = FF</i>
%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = F0</i>
</pre>
address spaces. Not all targets support all bit widths however.</p>
<pre>
- declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.max.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.max.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.max.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.max.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<pre>
- declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.min.i64..p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.min.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.min.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.min.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.min.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<pre>
- declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.umax.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.umax.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.umax.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.umax.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<pre>
- declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* <ptr>, i64 <delta> )
+ declare i8 @llvm.atomic.load.umin.i8.p0i8(i8* <ptr>, i8 <delta>)
+ declare i16 @llvm.atomic.load.umin.i16.p0i16(i16* <ptr>, i16 <delta>)
+ declare i32 @llvm.atomic.load.umin.i32.p0i32(i32* <ptr>, i32 <delta>)
+ declare i64 @llvm.atomic.load.umin.i64.p0i64(i64* <ptr>, i64 <delta>)
</pre>
<h5>Overview:</h5>
%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
%ptr = bitcast i8* %mallocP to i32*
store i32 7, %ptr
-%result0 = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 )
+%result0 = call i32 @llvm.atomic.load.min.i32.p0i32(i32* %ptr, i32 -2)
<i>; yields {i32}:result0 = 7</i>
-%result1 = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 )
+%result1 = call i32 @llvm.atomic.load.max.i32.p0i32(i32* %ptr, i32 8)
<i>; yields {i32}:result1 = -2</i>
-%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32( i32* %ptr, i32 10 )
+%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32(i32* %ptr, i32 10)
<i>; yields {i32}:result2 = 8</i>
-%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32( i32* %ptr, i32 30 )
+%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32(i32* %ptr, i32 30)
<i>; yields {i32}:result3 = 8</i>
%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 30</i>
</pre>
<h5>Syntax:</h5>
<pre>
- declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) readonly
+ declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>)
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> )
+ declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int>)
</pre>
<h5>Overview:</h5>
any integer bit width.</p>
<pre>
- declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int> )
+ declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int>)
+ declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int>)
+ declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int>)
+ declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int>)
+ declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int>)
</pre>
<h5>Overview:</h5>
<h5>Syntax:</h5>
<pre>
- declare void @llvm.stackprotector( i8* <guard>, i8** <slot> )
+ declare void @llvm.stackprotector(i8* <guard>, i8** <slot>)
</pre>
<h5>Overview:</h5>
the <tt>AllocaInst</tt> stack slot to be before local variables on the
stack. This is to ensure that if a local variable on the stack is
overwritten, it will destroy the value of the guard. When the function exits,
- the guard on the stack is checked against the original guard. If they're
+ the guard on the stack is checked against the original guard. If they are
different, then the program aborts by calling the <tt>__stack_chk_fail()</tt>
function.</p>
<h5>Syntax:</h5>
<pre>
- declare i32 @llvm.objectsize.i32( i8* <object>, i1 <type> )
- declare i64 @llvm.objectsize.i64( i8* <object>, i1 <type> )
+ declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>)
+ declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>)
</pre>
<h5>Overview:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic is designed to provide information
- to the optimizers to discover at compile time either a) when an
- operation like memcpy will either overflow a buffer that corresponds to
- an object, or b) to determine that a runtime check for overflow isn't
- necessary. An object in this context means an allocation of a
- specific class, structure, array, or other object.</p>
+<p>The <tt>llvm.objectsize</tt> intrinsic is designed to provide information to
+ the optimizers to determine at compile time whether a) an operation (like
+ memcpy) will overflow a buffer that corresponds to an object, or b) that a
+ runtime check for overflow isn't necessary. An object in this context means
+ an allocation of a specific class, structure, array, or other object.</p>
<h5>Arguments:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments. The first
+<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments. The first
argument is a pointer to or into the <tt>object</tt>. The second argument
- is a boolean 0 or 1. This argument determines whether you want the
- maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
+ is a boolean 0 or 1. This argument determines whether you want the
+ maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
1, variables are not allowed.</p>
<h5>Semantics:</h5>
<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to either a constant
- representing the size of the object concerned or <tt>i32/i64 -1 or 0</tt>
- (depending on the <tt>type</tt> argument if the size cannot be determined
- at compile time.</p>
+ representing the size of the object concerned, or <tt>i32/i64 -1 or 0</tt>,
+ depending on the <tt>type</tt> argument, if the size cannot be determined at
+ compile time.</p>
</div>
projects / oota-llvm.git / blobdiff