<title>LLVM Assembly Language Reference Manual</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="author" content="Chris Lattner">
- <meta name="description"
+ <meta name="description"
content="LLVM Assembly Language Reference Manual.">
<link rel="stylesheet" href="llvm.css" type="text/css">
</head>
<li><a href="#globalvars">Global Variables</a></li>
<li><a href="#functionstructure">Functions</a></li>
<li><a href="#aliasstructure">Aliases</a></li>
+ <li><a href="#namedmetadatastructure">Named Metadata</a></li>
<li><a href="#paramattrs">Parameter Attributes</a></li>
<li><a href="#fnattrs">Function Attributes</a></li>
<li><a href="#gc">Garbage Collector Names</a></li>
<li><a href="#typesystem">Type System</a>
<ol>
<li><a href="#t_classifications">Type Classifications</a></li>
- <li><a href="#t_primitive">Primitive Types</a>
+ <li><a href="#t_primitive">Primitive Types</a>
<ol>
<li><a href="#t_integer">Integer Type</a></li>
<li><a href="#t_floating">Floating Point Types</a></li>
<li><a href="#undefvalues">Undefined Values</a></li>
<li><a href="#blockaddress">Addresses of Basic Blocks</a></li>
<li><a href="#constantexprs">Constant Expressions</a></li>
- <li><a href="#metadata">Embedded Metadata</a></li>
</ol>
</li>
<li><a href="#othervalues">Other Values</a>
<ol>
<li><a href="#inlineasm">Inline Assembler Expressions</a></li>
+ <li><a href="#metadata">Metadata Nodes and Metadata Strings</a></li>
</ol>
</li>
<li><a href="#intrinsic_globals">Intrinsic Global Variables</a>
<li><a href="#i_ret">'<tt>ret</tt>' Instruction</a></li>
<li><a href="#i_br">'<tt>br</tt>' Instruction</a></li>
<li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li>
- <li><a href="#i_indbr">'<tt>indbr</tt>' Instruction</a></li>
+ <li><a href="#i_indirectbr">'<tt>indirectbr</tt>' Instruction</a></li>
<li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li>
<li><a href="#i_unwind">'<tt>unwind</tt>' Instruction</a></li>
<li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li>
'<tt>llvm.trap</tt>' Intrinsic</a></li>
<li><a href="#int_stackprotector">
'<tt>llvm.stackprotector</tt>' Intrinsic</a></li>
+ <li><a href="#int_objectsize">
+ '<tt>llvm.objectsize</tt>' Intrinsic</a></li>
</ol>
</li>
</ol>
IR's", allowing many source languages to be mapped to them). By providing
type information, LLVM can be used as the target of optimizations: for
example, through pointer analysis, it can be proven that a C automatic
- variable is never accessed outside of the current function... allowing it to
+ variable is never accessed outside of the current function, allowing it to
be promoted to a simple SSA value instead of a memory location.</p>
</div>
</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 that an LLVM module is well formed. This pass is automatically run
- by the parser after parsing input assembly and by the optimizer before it
- outputs bitcode. The violations pointed out by the verifier pass indicate
- bugs in transformation passes or input to the parser.</p>
+<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
+ that an LLVM module is well formed. This pass is automatically run by the
+ parser after parsing input assembly and by the optimizer before it outputs
+ bitcode. The violations pointed out by the verifier pass indicate bugs in
+ transformation passes or input to the parser.</p>
</div>
<div class="doc_code">
<pre>
-<a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
-<a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
+%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>
<li>Unnamed temporaries are numbered sequentially</li>
</ol>
-<p>...and it also shows a convention that we follow in this document. When
+<p>It also shows a convention that we follow in this document. When
demonstrating instructions, we will follow an instruction with a comment that
defines the type and name of value produced. Comments are shown in italic
text.</p>
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>
+<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>
+<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<br>}<br>
+<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, and
+ "<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>" function,
a <a href="#functionstructure">function definition</a> for
- "<tt>main</tt>".</p>
+ "<tt>main</tt>" and <a href="#namedmetadatastructure">named metadata</a>
+ "<tt>foo"</tt>.</p>
<p>In general, a module is made up of a list of global values, where both
functions and global variables are global values. Global values are
linkage:</p>
<dl>
- <dt><tt><b><a name="linkage_private">private</a></b></tt>: </dt>
+ <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
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>
+ <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:
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_internal">internal</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_internal">internal</a></b></tt></dt>
<dd>Similar to private, but the value shows as a local symbol
(<tt>STB_LOCAL</tt> in the case of ELF) in the object file. This
corresponds to the notion of the '<tt>static</tt>' keyword in C.</dd>
- <dt><tt><b><a name="linkage_available_externally">available_externally</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_available_externally">available_externally</a></b></tt></dt>
<dd>Globals with "<tt>available_externally</tt>" linkage are never emitted
into the object file corresponding to the LLVM module. They exist to
allow inlining and other optimizations to take place given knowledge of
be discarded at will, and are otherwise the same as <tt>linkonce_odr</tt>.
This linkage type is only allowed on definitions, not declarations.</dd>
- <dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt></dt>
<dd>Globals with "<tt>linkonce</tt>" linkage are merged with other globals of
- the same name when linkage occurs. This is typically used to implement
- inline functions, templates, or other code which must be generated in each
- 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>
+ the same name when linkage occurs. This can be used to implement
+ some forms of inline functions, templates, or other code which must be
+ generated in each translation unit that uses it, but where the body may
+ be overridden with a more definitive definition later. Unreferenced
+ <tt>linkonce</tt> globals are allowed to be discarded. Note that
+ <tt>linkonce</tt> linkage does not actually allow the optimizer to
+ inline the body of this function into callers because it doesn't know if
+ this definition of the function is the definitive definition within the
+ program or whether it will be overridden by a stronger definition.
+ To enable inlining and other optimizations, use "<tt>linkonce_odr</tt>"
+ linkage.</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>
+ <dt><tt><b><a name="linkage_common">common</a></b></tt></dt>
<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
+ 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_appending">appending</a></b></tt>: </dt>
+ <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
pointer to array type. When two global variables with appending linkage
are linked together, the two global arrays are appended together. This is
the LLVM, typesafe, equivalent of having the system linker append together
"sections" with identical names when .o files are linked.</dd>
- <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt></dt>
<dd>The semantics of this linkage follow the ELF object file model: the symbol
is weak until linked, if not linked, the symbol becomes null instead of
being an undefined reference.</dd>
- <dt><tt><b><a name="linkage_linkonce_odr">linkonce_odr</a></b></tt>: </dt>
- <dt><tt><b><a name="linkage_weak_odr">weak_odr</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_linkonce_odr">linkonce_odr</a></b></tt></dt>
+ <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" -
DLLs (Dynamic Link Libraries).</p>
<dl>
- <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt></dt>
<dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
or variable via a global pointer to a pointer that is set up by the DLL
exporting the symbol. On Microsoft Windows targets, the pointer name is
formed by combining <code>__imp_</code> and the function or variable
name.</dd>
- <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt>: </dt>
+ <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt></dt>
<dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global
pointer to a pointer in a DLL, so that it can be referenced with the
<tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer
(e.g. by passing things in registers). This calling convention allows the
target to use whatever tricks it wants to produce fast code for the
target, without having to conform to an externally specified ABI
- (Application Binary Interface). Implementations of this convention should
- allow arbitrary <a href="CodeGenerator.html#tailcallopt">tail call
- optimization</a> to be supported. This calling convention does not
+ (Application Binary Interface).
+ <a href="CodeGenerator.html#tailcallopt">Tail calls can only be optimized
+ when this convention is used.</a> This calling convention does not
support varargs and requires the prototype of all callees to exactly match
the prototype of the function definition.</dd>
<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="#visibility">visibility style</a>, an optional
<a href="#callingconv">calling convention</a>, 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
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="namedmetadatastructure">Named Metadata</a>
+</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
+ a named metadata.</p>
+
+<h5>Syntax:</h5>
+<div class="doc_code">
+<pre>
+!1 = metadata !{metadata !"one"}
+!name = !{null, !1}
+</pre>
+</div>
+
+</div>
+
<!-- ======================================================================= -->
<div class="doc_subsection"><a name="paramattrs">Parameter Attributes</a></div>
<p>Currently, only the following parameter attributes are defined:</p>
<dl>
- <dt><tt>zeroext</tt></dt>
+ <dt><tt><b>zeroext</b></tt></dt>
<dd>This indicates to the code generator that the parameter or return value
should be zero-extended to a 32-bit value by the caller (for a parameter)
or the callee (for a return value).</dd>
- <dt><tt>signext</tt></dt>
+ <dt><tt><b>signext</b></tt></dt>
<dd>This indicates to the code generator that the parameter or return value
should be sign-extended to a 32-bit value by the caller (for a parameter)
or the callee (for a return value).</dd>
- <dt><tt>inreg</tt></dt>
+ <dt><tt><b>inreg</b></tt></dt>
<dd>This indicates that this parameter or return value should be treated in a
special target-dependent fashion during while emitting code for a function
call or return (usually, by putting it in a register as opposed to memory,
though some targets use it to distinguish between two different kinds of
registers). Use of this attribute is target-specific.</dd>
- <dt><tt><a name="byval">byval</a></tt></dt>
+ <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
is made between the caller and the callee, so the callee is unable to
generator that usually indicates a desired alignment for the synthesized
stack slot.</dd>
- <dt><tt>sret</tt></dt>
+ <dt><tt><b>sret</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>noalias</tt></dt>
+ <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
<a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias
analysis</a>.</dd>
- <dt><tt>nocapture</tt></dt>
+ <dt><tt><b>nocapture</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>nest</tt></dt>
+ <dt><tt><b>nest</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>
<div class="doc_code">
<pre>
-define void @f() gc "name" { ...
+define void @f() gc "name" { ... }
</pre>
</div>
define void @f() noinline { ... }
define void @f() alwaysinline { ... }
define void @f() alwaysinline optsize { ... }
-define void @f() optsize
+define void @f() optsize { ... }
</pre>
</div>
<dl>
- <dt><tt>alwaysinline</tt></dt>
+ <dt><tt><b>alwaysinline</b></tt></dt>
<dd>This attribute indicates that the inliner should attempt to inline this
function into callers whenever possible, ignoring any active inlining size
threshold for this caller.</dd>
- <dt><tt>inlinehint</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>noinline</tt></dt>
+ <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>optsize</tt></dt>
+ <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>noreturn</tt></dt>
+ <dt><tt><b>noreturn</b></tt></dt>
<dd>This function attribute indicates that the function never returns
normally. This produces undefined behavior at runtime if the function
ever does dynamically return.</dd>
- <dt><tt>nounwind</tt></dt>
+ <dt><tt><b>nounwind</b></tt></dt>
<dd>This function attribute indicates that the function never returns with an
unwind or exceptional control flow. If the function does unwind, its
runtime behavior is undefined.</dd>
- <dt><tt>readnone</tt></dt>
+ <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
dereferencing any pointer arguments or otherwise accessing any mutable
exceptions by calling the <tt>C++</tt> exception throwing methods, but
could use the <tt>unwind</tt> instruction.</dd>
- <dt><tt><a name="readonly">readonly</a></tt></dt>
+ <dt><tt><b><a name="readonly">readonly</a></b></tt></dt>
<dd>This attribute indicates that the function does not write through any
pointer arguments (including <tt><a href="#byval">byval</a></tt>
arguments) or otherwise modify any state (e.g. memory, control registers,
exception by calling the <tt>C++</tt> exception throwing methods, but may
use the <tt>unwind</tt> instruction.</dd>
- <dt><tt><a name="ssp">ssp</a></tt></dt>
+ <dt><tt><b><a name="ssp">ssp</a></b></tt></dt>
<dd>This attribute indicates that the function should emit a stack smashing
protector. It is in the form of a "canary"—a random value placed on
the stack before the local variables that's checked upon return from the
function that doesn't have an <tt>ssp</tt> attribute, then the resulting
function will have an <tt>ssp</tt> attribute.</dd>
- <dt><tt>sspreq</tt></dt>
+ <dt><tt><b>sspreq</b></tt></dt>
<dd>This attribute indicates that the function should <em>always</em> emit a
stack smashing protector. This overrides
the <tt><a href="#ssp">ssp</a></tt> function attribute.<br>
an <tt>ssp</tt> attribute, then the resulting function will have
an <tt>sspreq</tt> attribute.</dd>
- <dt><tt>noredzone</tt></dt>
+ <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>noimplicitfloat</tt></dt>
+ <dt><tt><b>noimplicitfloat</b></tt></dt>
<dd>This attributes disables implicit floating point instructions.</dd>
- <dt><tt>naked</tt></dt>
+ <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>
location.</dd>
<dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
+ <dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
<i>preferred</i> alignments. All sizes are in bits. Specifying
the <i>pref</i> alignment is optional. If omitted, the
preceding <tt>:</tt> should be omitted too.</dd>
<i>size</i>. The value of <i>size</i> must be in the range [1,2^23).</dd>
<dt><tt>v<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the alignment for a vector type of a given bit
+ <dd>This specifies the alignment for a vector type of a given bit
<i>size</i>.</dd>
<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
+ <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>
<dt><tt>s<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
<dd>This specifies the alignment for a stack object of a given bit
<i>size</i>.</dd>
+
+ <dt><tt>n<i>size1</i>:<i>size2</i>:<i>size3</i>...</tt></dt>
+ <dd>This specifies a set of native integer widths for the target CPU
+ in bits. For example, it might contain "n32" for 32-bit PowerPC,
+ "n32:64" for PowerPC 64, or "n8:16:32:64" for X86-64. Elements of
+ this set are considered to support most general arithmetic
+ operations efficiently.</dd>
</dl>
<p>When constructing the data layout for a given target, LLVM starts with a
</tr>
</table>
-<p>Note that the code generator does not yet support large integer types to be
- used as function return types. The specific limit on how large a return type
- the code generator can currently handle is target-dependent; currently it's
- often 64 bits for 32-bit targets and 128 bits for 64-bit targets.</p>
-
</div>
<!-- _______________________________________________________________________ -->
</tr>
</table>
-<p>Note that 'variable sized arrays' can be implemented in LLVM with a zero
- length array. Normally, accesses past the end of an array are undefined in
- LLVM (e.g. it is illegal to access the 5th element of a 3 element array). As
- a special case, however, zero length arrays are recognized to be variable
- length. This allows implementation of 'pascal style arrays' with the LLVM
- type "<tt>{ i32, [0 x float]}</tt>", for example.</p>
-
-<p>Note that the code generator does not yet support large aggregate types to be
- used as function return types. The specific limit on how large an aggregate
- return type the code generator can currently handle is target-dependent, and
- also dependent on the aggregate element types.</p>
+<p>There is no restriction on indexing beyond the end of the array implied by
+ a static type (though there are restrictions on indexing beyond the bounds
+ of an allocated object in some cases). This means that single-dimension
+ 'variable sized array' addressing can be implemented in LLVM with a zero
+ length array type. An implementation of 'pascal style arrays' in LLVM could
+ use the type "<tt>{ i32, [0 x float]}</tt>", for example.</p>
</div>
</tr><tr class="layout">
<td class="left"><tt>float (i16 signext, i32 *) *
</tt></td>
- <td class="left"><a href="#t_pointer">Pointer</a> to a function that takes
- an <tt>i16</tt> that should be sign extended and a
- <a href="#t_pointer">pointer</a> to <tt>i32</tt>, returning
+ <td class="left"><a href="#t_pointer">Pointer</a> to a function that takes
+ an <tt>i16</tt> that should be sign extended and a
+ <a href="#t_pointer">pointer</a> to <tt>i32</tt>, returning
<tt>float</tt>.
</td>
</tr><tr class="layout">
<td class="left"><tt>i32 (i8*, ...)</tt></td>
- <td class="left">A vararg function that takes at least one
- <a href="#t_pointer">pointer</a> to <tt>i8 </tt> (char in C),
- which returns an integer. This is the signature for <tt>printf</tt> in
+ <td class="left">A vararg function that takes at least one
+ <a href="#t_pointer">pointer</a> to <tt>i8 </tt> (char in C),
+ which returns an integer. This is the signature for <tt>printf</tt> in
LLVM.
</td>
</tr><tr class="layout">
underlying processor. The elements of a structure may be any type that has a
size.</p>
-<p>Structures 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.</p>
-
+<p>Structures in memory 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.
+ Structures in registers are accessed using the
+ '<tt><a href="#i_extractvalue">extractvalue</a></tt>' and
+ '<tt><a href="#i_insertvalue">insertvalue</a></tt>' instructions.</p>
<h5>Syntax:</h5>
<pre>
{ <type list> }
</tr>
</table>
-<p>Note that the code generator does not yet support large aggregate types to be
- used as function return types. The specific limit on how large an aggregate
- return type the code generator can currently handle is target-dependent, and
- also dependent on the aggregate element types.</p>
-
</div>
<!-- _______________________________________________________________________ -->
<p>A vector type is a simple derived type that represents a vector of elements.
Vector types are used when multiple primitive data are operated in parallel
using a single instruction (SIMD). A vector type requires a size (number of
- elements) and an underlying primitive data type. Vectors must have a power
- of two length (1, 2, 4, 8, 16 ...). Vector types are considered
+ elements) and an underlying primitive data type. Vector types are considered
<a href="#t_firstclass">first class</a>.</p>
<h5>Syntax:</h5>
</tr>
</table>
-<p>Note that the code generator does not yet support large vector types to be
- used as function return types. The specific limit on how large a vector
- return type codegen can currently handle is target-dependent; currently it's
- often a few times longer than a hardware vector register.</p>
-
</div>
<!-- _______________________________________________________________________ -->
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
+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">
<div class="doc_code">
<pre>
%A = xor undef, undef
-
+
%B = undef
%C = xor %B, %B
it: since the undefined operation "can't happen", the optimizer can assume that
it occurs in dead code.
</p>
-
+
<div class="doc_code">
<pre>
a: store undef -> %X
</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
+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><b><tt>blockaddress(@function, %block)</tt></b></p>
<p>The '<tt>blockaddress</tt>' constant computes the address of the specified
- basic block in the specified function, and always has an i8* type.</p>
-
-
+ basic block in the specified function, and always has an i8* type. Taking
+ 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_indbr"><tt>indbr</tt></a>' instruction or for comparisons
+ '<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 reconsistituted before the <tt>indbr</tt>.</p>
-
+ the original value is reconstituted before the <tt>indirectbr</tt>.</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.
</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="metadata">Embedded Metadata</a>
-</div>
-
-<div class="doc_text">
-
-<p>Embedded metadata provides a way to attach arbitrary data to the instruction
- stream without affecting the behaviour of the program. There are two
- metadata primitives, strings and nodes. All metadata has the
- <tt>metadata</tt> type and is identified in syntax by a preceding exclamation
- point ('<tt>!</tt>').</p>
-
-<p>A metadata string is a string surrounded by double quotes. It can contain
- any character by escaping non-printable characters with "\xx" where "xx" is
- the two digit hex code. For example: "<tt>!"test\00"</tt>".</p>
-
-<p>Metadata nodes are represented with notation similar to structure constants
- (a comma separated list of elements, surrounded by braces and preceded by an
- exclamation point). For example: "<tt>!{ metadata !"test\00", i32
- 10}</tt>".</p>
-
-<p>A metadata node will attempt to track changes to the values it holds. In the
- event that a value is deleted, it will be replaced with a typeless
- "<tt>null</tt>", such as "<tt>metadata !{null, i32 10}</tt>".</p>
-
-<p>Optimizations may rely on metadata to provide additional information about
- the program that isn't available in the instructions, or that isn't easily
- computable. Similarly, the code generator may expect a certain metadata
- format to be used to express debugging information.</p>
-
-</div>
-
<!-- *********************************************************************** -->
<div class="doc_section"> <a name="othervalues">Other Values</a> </div>
<!-- *********************************************************************** -->
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection"><a name="metadata">Metadata Nodes and Metadata
+ Strings</a>
+</div>
+
+<div class="doc_text">
+
+<p>LLVM IR allows metadata to be attached to instructions in the program that
+ can convey extra information about the code to the optimizers and code
+ generator. One example application of metadata is source-level debug
+ information. There are two metadata primitives: strings and nodes. All
+ metadata has the <tt>metadata</tt> type and is identified in syntax by a
+ preceding exclamation point ('<tt>!</tt>').</p>
+
+<p>A metadata string is a string surrounded by double quotes. It can contain
+ any character by escaping non-printable characters with "\xx" where "xx" is
+ the two digit hex code. For example: "<tt>!"test\00"</tt>".</p>
+
+<p>Metadata nodes are represented with notation similar to structure constants
+ (a comma separated list of elements, surrounded by braces and preceded by an
+ exclamation point). For example: "<tt>!{ metadata !"test\00", i32
+ 10}</tt>". Metadata nodes can have any values as their operand.</p>
+
+<p>A <a href="#namedmetadatastructure">named metadata</a> is a collection of
+ metadata nodes, which can be looked up in the module symbol table. For
+ example: "<tt>!foo = metadata !{!4, !3}</tt>".
+
+</div>
+
<!-- *********************************************************************** -->
<div class="doc_section">
'<a href="#i_ret"><tt>ret</tt></a>' instruction, the
'<a href="#i_br"><tt>br</tt></a>' instruction, the
'<a href="#i_switch"><tt>switch</tt></a>' instruction, the
- '<a href="#i_indbr">'<tt>indbr</tt>' Instruction, the
+ '<a href="#i_indirectbr">'<tt>indirectbr</tt></a>' Instruction, the
'<a href="#i_invoke"><tt>invoke</tt></a>' instruction, the
'<a href="#i_unwind"><tt>unwind</tt></a>' instruction, and the
'<a href="#i_unreachable"><tt>unreachable</tt></a>' instruction.</p>
ret { i32, i8 } { i32 4, i8 2 } <i>; Return a struct of values 4 and 2</i>
</pre>
-<p>Note that the code generator does not yet fully support large
- return values. The specific sizes that are currently supported are
- dependent on the target. For integers, on 32-bit targets the limit
- is often 64 bits, and on 64-bit targets the limit is often 128 bits.
- For aggregate types, the current limits are dependent on the element
- types; for example targets are often limited to 2 total integer
- elements and 2 total floating-point elements.</p>
-
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="i_indbr">'<tt>indbr</tt>' Instruction</a>
+ <a name="i_indirectbr">'<tt>indirectbr</tt>' Instruction</a>
</div>
<div class="doc_text">
<h5>Syntax:</h5>
<pre>
- indbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ]
+ indirectbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ]
</pre>
<h5>Overview:</h5>
-<p>The '<tt>indbr</tt>' instruction implements an indirect branch to a label
+<p>The '<tt>indirectbr</tt>' instruction implements an indirect branch to a label
within the current function, whose address is specified by
"<tt>address</tt>". Address must be derived from a <a
href="#blockaddress">blockaddress</a> constant.</p>
rest of the arguments indicate the full set of possible destinations that the
address may point to. Blocks are allowed to occur multiple times in the
destination list, though this isn't particularly useful.</p>
-
+
<p>This destination list is required so that dataflow analysis has an accurate
understanding of the CFG.</p>
<h5>Example:</h5>
<pre>
- indbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ]
+ indirectbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ]
</pre>
</div>
block to the "normal" label. If the callee unwinds then no return value is
available.</p>
+<p>Note that the code generator does not yet completely support unwind, and
+that the invoke/unwind semantics are likely to change in future versions.</p>
+
<h5>Example:</h5>
<pre>
%retval = invoke i32 @Test(i32 15) to label %Continue
specified by the <tt>invoke</tt> instruction. If there is no <tt>invoke</tt>
instruction in the dynamic call chain, undefined behavior results.</p>
+<p>Note that the code generator does not yet completely support unwind, and
+that the invoke/unwind semantics are likely to change in future versions.</p>
+
</div>
<!-- _______________________________________________________________________ -->
<p>The two arguments to the '<tt>mul</tt>' instruction must
be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
integer values. Both arguments must have identical types.</p>
-
+
<h5>Semantics:</h5>
<p>The value produced is the integer product of the two operands.</p>
<p>The '<tt>udiv</tt>' instruction returns the quotient of its two operands.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>udiv</tt>' instruction must be
+<p>The two arguments to the '<tt>udiv</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
<p>The '<tt>sdiv</tt>' instruction returns the quotient of its two operands.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>sdiv</tt>' instruction must be
+<p>The two arguments to the '<tt>sdiv</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
division of its two arguments.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>urem</tt>' instruction must be
+<p>The two arguments to the '<tt>urem</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
elements must be integers.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>srem</tt>' instruction must be
+<p>The two arguments to the '<tt>srem</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
<p>Both arguments to the '<tt>shl</tt>' instruction must be the
same <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
integer type. '<tt>op2</tt>' is treated as an unsigned value.</p>
-
+
<h5>Semantics:</h5>
<p>The value produced is <tt>op1</tt> * 2<sup><tt>op2</tt></sup> mod
2<sup>n</sup>, where <tt>n</tt> is the width of the result. If <tt>op2</tt>
operand shifted to the right a specified number of bits with zero fill.</p>
<h5>Arguments:</h5>
-<p>Both arguments to the '<tt>lshr</tt>' instruction must be the same
+<p>Both arguments to the '<tt>lshr</tt>' instruction must be the same
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
type. '<tt>op2</tt>' is treated as an unsigned value.</p>
extension.</p>
<h5>Arguments:</h5>
-<p>Both arguments to the '<tt>ashr</tt>' instruction must be the same
+<p>Both arguments to the '<tt>ashr</tt>' instruction must be the same
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
type. '<tt>op2</tt>' is treated as an unsigned value.</p>
operands.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>and</tt>' instruction must be
+<p>The two arguments to the '<tt>and</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
two operands.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>or</tt>' instruction must be
+<p>The two arguments to the '<tt>or</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
complement" operation, which is the "~" operator in C.</p>
<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>xor</tt>' instruction must be
+<p>The two arguments to the '<tt>xor</tt>' instruction must be
<a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
values. Both arguments must have identical types.</p>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<div class="doc_subsection">
<a name="vectorops">Vector Operations</a>
</div>
<h5>Example:</h5>
<pre>
- %result = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i>
+ <result> = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i>
</pre>
</div>
<h5>Example:</h5>
<pre>
- %result = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i>
+ <result> = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i>
</pre>
</div>
<h5>Example:</h5>
<pre>
- %result = shufflevector <4 x i32> %v1, <4 x i32> %v2,
+ <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
<4 x i32> <i32 0, i32 4, i32 1, i32 5> <i>; yields <4 x i32></i>
- %result = shufflevector <4 x i32> %v1, <4 x i32> undef,
+ <result> = shufflevector <4 x i32> %v1, <4 x i32> undef,
<4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle.
- %result = shufflevector <8 x i32> %v1, <8 x i32> undef,
+ <result> = shufflevector <8 x i32> %v1, <8 x i32> undef,
<4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i>
- %result = shufflevector <4 x i32> %v1, <4 x i32> %v2,
+ <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
<8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > <i>; yields <8 x i32></i>
</pre>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<div class="doc_subsection">
<a name="aggregateops">Aggregate Operations</a>
</div>
<h5>Example:</h5>
<pre>
- %result = extractvalue {i32, float} %agg, 0 <i>; yields i32</i>
+ <result> = extractvalue {i32, float} %agg, 0 <i>; yields i32</i>
</pre>
</div>
<h5>Syntax:</h5>
<pre>
- <result> = insertvalue <aggregate type> <val>, <ty> <val>, <idx> <i>; yields <n x <ty>></i>
+ <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx> <i>; yields <aggregate type></i>
</pre>
<h5>Overview:</h5>
<h5>Example:</h5>
<pre>
- %result = insertvalue {i32, float} %agg, i32 1, 0 <i>; yields {i32, float}</i>
+ %agg1 = insertvalue {i32, float} undef, i32 1, 0 <i>; yields {i32 1, float undef}</i>
+ %agg2 = insertvalue {i32, float} %agg1, float %val, 1 <i>; yields {i32 1, float %val}</i>
</pre>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<div class="doc_subsection">
<a name="memoryops">Memory Access and Addressing Operations</a>
</div>
<pre>
%X = trunc i32 257 to i8 <i>; yields i8:1</i>
%Y = trunc i32 123 to i1 <i>; yields i1:true</i>
- %Y = trunc i32 122 to i1 <i>; yields i1:false</i>
+ %Z = trunc i32 122 to i1 <i>; yields i1:false</i>
</pre>
</div>
</pre>
<h5>Overview:</h5>
-<p>The '<tt>zext</tt>' instruction zero extends its operand to type
+<p>The '<tt>zext</tt>' instruction zero extends its operand to type
<tt>ty2</tt>.</p>
<h5>Arguments:</h5>
-<p>The '<tt>zext</tt>' instruction takes a value to cast, which must be of
+<p>The '<tt>zext</tt>' instruction takes a value to cast, which must be of
<a href="#t_integer">integer</a> type, and a type to cast it to, which must
also be of <a href="#t_integer">integer</a> type. The bit size of the
- <tt>value</tt> must be smaller than the bit size of the destination type,
+ <tt>value</tt> must be smaller than the bit size of the destination type,
<tt>ty2</tt>.</p>
<h5>Semantics:</h5>
<p>The '<tt>sext</tt>' sign extends <tt>value</tt> to the type <tt>ty2</tt>.</p>
<h5>Arguments:</h5>
-<p>The '<tt>sext</tt>' instruction takes a value to cast, which must be of
+<p>The '<tt>sext</tt>' instruction takes a value to cast, which must be of
<a href="#t_integer">integer</a> type, and a type to cast it to, which must
also be of <a href="#t_integer">integer</a> type. The bit size of the
- <tt>value</tt> must be smaller than the bit size of the destination type,
+ <tt>value</tt> must be smaller than the bit size of the destination type,
<tt>ty2</tt>.</p>
<h5>Semantics:</h5>
<p>The '<tt>fptrunc</tt>' instruction takes a <a href="#t_floating">floating
point</a> value to cast and a <a href="#t_floating">floating point</a> type
to cast it to. The size of <tt>value</tt> must be larger than the size of
- <tt>ty2</tt>. This implies that <tt>fptrunc</tt> cannot be used to make a
+ <tt>ty2</tt>. This implies that <tt>fptrunc</tt> cannot be used to make a
<i>no-op cast</i>.</p>
<h5>Semantics:</h5>
<p>The '<tt>fptrunc</tt>' instruction truncates a <tt>value</tt> from a larger
- <a href="#t_floating">floating point</a> type to a smaller
+ <a href="#t_floating">floating point</a> type to a smaller
<a href="#t_floating">floating point</a> type. If the value cannot fit
within the destination type, <tt>ty2</tt>, then the results are
undefined.</p>
floating point value.</p>
<h5>Arguments:</h5>
-<p>The '<tt>fpext</tt>' instruction takes a
+<p>The '<tt>fpext</tt>' instruction takes a
<a href="#t_floating">floating point</a> <tt>value</tt> to cast, and
a <a href="#t_floating">floating point</a> type to cast it to. The source
type must be smaller than the destination type.</p>
vector integer type with the same number of elements as <tt>ty</tt></p>
<h5>Semantics:</h5>
-<p>The '<tt>fptoui</tt>' instruction converts its
+<p>The '<tt>fptoui</tt>' instruction converts its
<a href="#t_floating">floating point</a> operand into the nearest (rounding
towards zero) unsigned integer value. If the value cannot fit
in <tt>ty2</tt>, the results are undefined.</p>
<pre>
%X = fptoui double 123.0 to i32 <i>; yields i32:123</i>
%Y = fptoui float 1.0E+300 to i1 <i>; yields undefined:1</i>
- %X = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i>
+ %Z = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i>
</pre>
</div>
</pre>
<h5>Overview:</h5>
-<p>The '<tt>fptosi</tt>' instruction converts
+<p>The '<tt>fptosi</tt>' instruction converts
<a href="#t_floating">floating point</a> <tt>value</tt> to
type <tt>ty2</tt>.</p>
vector integer type with the same number of elements as <tt>ty</tt></p>
<h5>Semantics:</h5>
-<p>The '<tt>fptosi</tt>' instruction converts its
+<p>The '<tt>fptosi</tt>' instruction converts its
<a href="#t_floating">floating point</a> operand into the nearest (rounding
towards zero) signed integer value. If the value cannot fit in <tt>ty2</tt>,
the results are undefined.</p>
<pre>
%X = fptosi double -123.0 to i32 <i>; yields i32:-123</i>
%Y = fptosi float 1.0E-247 to i1 <i>; yields undefined:1</i>
- %X = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i>
+ %Z = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i>
</pre>
</div>
<h5>Example:</h5>
<pre>
%X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i>
- %X = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
- %Y = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
+ %Y = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
+ %Z = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
</pre>
</div>
<pre>
%X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
%Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i>
- %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i>
+ %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i>
</pre>
</div>
result, as follows:</p>
<ol>
- <li><tt>eq</tt>: yields <tt>true</tt> if the operands are equal,
+ <li><tt>eq</tt>: yields <tt>true</tt> if the operands are equal,
<tt>false</tt> otherwise. No sign interpretation is necessary or
performed.</li>
- <li><tt>ne</tt>: yields <tt>true</tt> if the operands are unequal,
+ <li><tt>ne</tt>: yields <tt>true</tt> if the operands are unequal,
<tt>false</tt> otherwise. No sign interpretation is necessary or
performed.</li>
<ol>
<li><tt>false</tt>: always yields <tt>false</tt>, regardless of operands.</li>
- <li><tt>oeq</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <li><tt>oeq</tt>: yields <tt>true</tt> if both operands are not a QNAN and
<tt>op1</tt> is equal to <tt>op2</tt>.</li>
<li><tt>ogt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
<tt>op1</tt> is greather than <tt>op2</tt>.</li>
- <li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and
<tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
- <li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
<tt>op1</tt> is less than <tt>op2</tt>.</li>
- <li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and
<tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
- <li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and
<tt>op1</tt> is not equal to <tt>op2</tt>.</li>
<li><tt>ord</tt>: yields <tt>true</tt> if both operands are not a QNAN.</li>
- <li><tt>ueq</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <li><tt>ueq</tt>: yields <tt>true</tt> if either operand is a QNAN or
<tt>op1</tt> is equal to <tt>op2</tt>.</li>
- <li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or
<tt>op1</tt> is greater than <tt>op2</tt>.</li>
- <li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or
<tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
- <li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or
<tt>op1</tt> is less than <tt>op2</tt>.</li>
- <li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or
<tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
- <li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or
<tt>op1</tt> is not equal to <tt>op2</tt>.</li>
<li><tt>uno</tt>: yields <tt>true</tt> if either operand is a QNAN.</li>
<p>This instruction requires several arguments:</p>
<ol>
- <li>The optional "tail" marker indicates whether the callee function accesses
- any allocas or varargs in the caller. If the "tail" marker is present,
- the function call is eligible for tail call optimization. Note that calls
- may be marked "tail" even if they do not occur before
- a <a href="#i_ret"><tt>ret</tt></a> instruction.</li>
+ <li>The optional "tail" marker indicates that the callee function does not
+ access any allocas or varargs in the caller. Note that calls may be
+ marked "tail" even if they do not occur before
+ a <a href="#i_ret"><tt>ret</tt></a> instruction. If the "tail" marker is
+ present, the function call is eligible for tail call optimization,
+ but <a href="CodeGenerator.html#tailcallopt">might not in fact be
+ optimized into a jump</a>. As of this writing, the extra requirements for
+ a call to actually be optimized are:
+ <ul>
+ <li>Caller and callee both have the calling
+ convention <tt>fastcc</tt>.</li>
+ <li>The call is in tail position (ret immediately follows call and ret
+ uses value of call or is void).</li>
+ <li>Option <tt>-tailcallopt</tt> is enabled,
+ or <code>llvm::PerformTailCallOpt</code> is <code>true</code>.</li>
+ <li><a href="CodeGenerator.html#tailcallopt">Platform specific
+ constraints are met.</a></li>
+ </ul>
+ </li>
<li>The optional "cconv" marker indicates which <a href="#callingconv">calling
convention</a> the call should use. If none is specified, the call
- defaults to using C calling conventions.</li>
+ defaults to using C calling conventions. The calling convention of the
+ call must match the calling convention of the target function, or else the
+ behavior is undefined.</li>
<li>The optional <a href="#paramattrs">Parameter Attributes</a> list for
return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>', and
suffix is required. Because the argument's type is matched against the return
type, it does not require its own name suffix.</p>
-<p>To learn how to add an intrinsic function, please see the
+<p>To learn how to add an intrinsic function, please see the
<a href="ExtendingLLVM.html">Extending LLVM Guide</a>.</p>
</div>
<ul>
<li><tt>ll</tt>: All loads before the barrier must complete before any load
after the barrier begins.</li>
- <li><tt>ls</tt>: All loads before the barrier must complete before any
+ <li><tt>ls</tt>: All loads before the barrier must complete before any
store after the barrier begins.</li>
- <li><tt>ss</tt>: All stores before the barrier must complete before any
+ <li><tt>ss</tt>: All stores before the barrier must complete before any
store after the barrier begins.</li>
- <li><tt>sl</tt>: All stores before the barrier must complete before any
+ <li><tt>sl</tt>: All stores before the barrier must complete before any
load after the barrier begins.</li>
</ul>
</pre>
<h5>Overview:</h5>
-<p>This intrinsic subtracts <tt>delta</tt> to the value stored in memory at
+<p>This intrinsic subtracts <tt>delta</tt> to the value stored in memory at
<tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.</p>
<h5>Arguments:</h5>
</pre>
<h5>Overview:</h5>
-<p>These intrinsics takes the signed or unsigned minimum or maximum of
+<p>These intrinsics takes the signed or unsigned minimum or maximum of
<tt>delta</tt> and the value stored in memory at <tt>ptr</tt>. It yields the
original value at <tt>ptr</tt>.</p>
</div>
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="int_objectsize">'<tt>llvm.objectsize</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ 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>
+
+<h5>Arguments:</h5>
+<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
+ 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>
+
+</div>
+
<!-- *********************************************************************** -->
<hr>
<address>