diff options
| author | Dan Gohman <djg@cray.com> | 2007-07-18 16:29:46 +0000 |
|---|---|---|
| committer | Dan Gohman <djg@cray.com> | 2007-07-18 16:29:46 +0000 |
| commit | f17a25c88b892d30c2b41ba7ecdfbdfb2b4be9cc (patch) | |
| tree | ebb79ea1ee5e3bc1fdf38541a811a8b804f0679a /docs/LangRef.html | |
| download | external_llvm-f17a25c88b892d30c2b41ba7ecdfbdfb2b4be9cc.zip external_llvm-f17a25c88b892d30c2b41ba7ecdfbdfb2b4be9cc.tar.gz external_llvm-f17a25c88b892d30c2b41ba7ecdfbdfb2b4be9cc.tar.bz2 | |
It's not necessary to do rounding for alloca operations when the requested
alignment is equal to the stack alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@40004 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/LangRef.html')
| -rw-r--r-- | docs/LangRef.html | 4882 |
1 files changed, 4882 insertions, 0 deletions
diff --git a/docs/LangRef.html b/docs/LangRef.html new file mode 100644 index 0000000..a57f242 --- /dev/null +++ b/docs/LangRef.html @@ -0,0 +1,4882 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" + "http://www.w3.org/TR/html4/strict.dtd"> +<html> +<head> + <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" + content="LLVM Assembly Language Reference Manual."> + <link rel="stylesheet" href="llvm.css" type="text/css"> +</head> + +<body> + +<div class="doc_title"> LLVM Language Reference Manual </div> +<ol> + <li><a href="#abstract">Abstract</a></li> + <li><a href="#introduction">Introduction</a></li> + <li><a href="#identifiers">Identifiers</a></li> + <li><a href="#highlevel">High Level Structure</a> + <ol> + <li><a href="#modulestructure">Module Structure</a></li> + <li><a href="#linkage">Linkage Types</a></li> + <li><a href="#callingconv">Calling Conventions</a></li> + <li><a href="#globalvars">Global Variables</a></li> + <li><a href="#functionstructure">Functions</a></li> + <li><a href="#aliasstructure">Aliases</a> + <li><a href="#paramattrs">Parameter Attributes</a></li> + <li><a href="#moduleasm">Module-Level Inline Assembly</a></li> + <li><a href="#datalayout">Data Layout</a></li> + </ol> + </li> + <li><a href="#typesystem">Type System</a> + <ol> + <li><a href="#t_primitive">Primitive Types</a> + <ol> + <li><a href="#t_classifications">Type Classifications</a></li> + </ol> + </li> + <li><a href="#t_derived">Derived Types</a> + <ol> + <li><a href="#t_array">Array Type</a></li> + <li><a href="#t_function">Function Type</a></li> + <li><a href="#t_pointer">Pointer 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_vector">Vector Type</a></li> + <li><a href="#t_opaque">Opaque Type</a></li> + </ol> + </li> + </ol> + </li> + <li><a href="#constants">Constants</a> + <ol> + <li><a href="#simpleconstants">Simple Constants</a> + <li><a href="#aggregateconstants">Aggregate Constants</a> + <li><a href="#globalconstants">Global Variable and Function Addresses</a> + <li><a href="#undefvalues">Undefined Values</a> + <li><a href="#constantexprs">Constant Expressions</a> + </ol> + </li> + <li><a href="#othervalues">Other Values</a> + <ol> + <li><a href="#inlineasm">Inline Assembler Expressions</a> + </ol> + </li> + <li><a href="#instref">Instruction Reference</a> + <ol> + <li><a href="#terminators">Terminator Instructions</a> + <ol> + <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_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> + </ol> + </li> + <li><a href="#binaryops">Binary Operations</a> + <ol> + <li><a href="#i_add">'<tt>add</tt>' Instruction</a></li> + <li><a href="#i_sub">'<tt>sub</tt>' Instruction</a></li> + <li><a href="#i_mul">'<tt>mul</tt>' Instruction</a></li> + <li><a href="#i_udiv">'<tt>udiv</tt>' Instruction</a></li> + <li><a href="#i_sdiv">'<tt>sdiv</tt>' Instruction</a></li> + <li><a href="#i_fdiv">'<tt>fdiv</tt>' Instruction</a></li> + <li><a href="#i_urem">'<tt>urem</tt>' Instruction</a></li> + <li><a href="#i_srem">'<tt>srem</tt>' Instruction</a></li> + <li><a href="#i_frem">'<tt>frem</tt>' Instruction</a></li> + </ol> + </li> + <li><a href="#bitwiseops">Bitwise Binary Operations</a> + <ol> + <li><a href="#i_shl">'<tt>shl</tt>' Instruction</a></li> + <li><a href="#i_lshr">'<tt>lshr</tt>' Instruction</a></li> + <li><a href="#i_ashr">'<tt>ashr</tt>' Instruction</a></li> + <li><a href="#i_and">'<tt>and</tt>' Instruction</a></li> + <li><a href="#i_or">'<tt>or</tt>' Instruction</a></li> + <li><a href="#i_xor">'<tt>xor</tt>' Instruction</a></li> + </ol> + </li> + <li><a href="#vectorops">Vector Operations</a> + <ol> + <li><a href="#i_extractelement">'<tt>extractelement</tt>' Instruction</a></li> + <li><a href="#i_insertelement">'<tt>insertelement</tt>' Instruction</a></li> + <li><a href="#i_shufflevector">'<tt>shufflevector</tt>' Instruction</a></li> + </ol> + </li> + <li><a href="#memoryops">Memory Access and Addressing Operations</a> + <ol> + <li><a href="#i_malloc">'<tt>malloc</tt>' Instruction</a></li> + <li><a href="#i_free">'<tt>free</tt>' Instruction</a></li> + <li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li> + <li><a href="#i_load">'<tt>load</tt>' Instruction</a></li> + <li><a href="#i_store">'<tt>store</tt>' Instruction</a></li> + <li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li> + </ol> + </li> + <li><a href="#convertops">Conversion Operations</a> + <ol> + <li><a href="#i_trunc">'<tt>trunc .. to</tt>' Instruction</a></li> + <li><a href="#i_zext">'<tt>zext .. to</tt>' Instruction</a></li> + <li><a href="#i_sext">'<tt>sext .. to</tt>' Instruction</a></li> + <li><a href="#i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a></li> + <li><a href="#i_fpext">'<tt>fpext .. to</tt>' Instruction</a></li> + <li><a href="#i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a></li> + <li><a href="#i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a></li> + <li><a href="#i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a></li> + <li><a href="#i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a></li> + <li><a href="#i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a></li> + <li><a href="#i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a></li> + <li><a href="#i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a></li> + </ol> + <li><a href="#otherops">Other Operations</a> + <ol> + <li><a href="#i_icmp">'<tt>icmp</tt>' Instruction</a></li> + <li><a href="#i_fcmp">'<tt>fcmp</tt>' Instruction</a></li> + <li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li> + <li><a href="#i_select">'<tt>select</tt>' Instruction</a></li> + <li><a href="#i_call">'<tt>call</tt>' Instruction</a></li> + <li><a href="#i_va_arg">'<tt>va_arg</tt>' Instruction</a></li> + </ol> + </li> + </ol> + </li> + <li><a href="#intrinsics">Intrinsic Functions</a> + <ol> + <li><a href="#int_varargs">Variable Argument Handling Intrinsics</a> + <ol> + <li><a href="#int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a></li> + <li><a href="#int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a></li> + <li><a href="#int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li> + </ol> + </li> + <li><a href="#int_gc">Accurate Garbage Collection Intrinsics</a> + <ol> + <li><a href="#int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a></li> + <li><a href="#int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a></li> + <li><a href="#int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a></li> + </ol> + </li> + <li><a href="#int_codegen">Code Generator Intrinsics</a> + <ol> + <li><a href="#int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li> + <li><a href="#int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li> + <li><a href="#int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a></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> + </ol> + </li> + <li><a href="#int_libc">Standard C Library Intrinsics</a> + <ol> + <li><a href="#int_memcpy">'<tt>llvm.memcpy.*</tt>' Intrinsic</a></li> + <li><a href="#int_memmove">'<tt>llvm.memmove.*</tt>' Intrinsic</a></li> + <li><a href="#int_memset">'<tt>llvm.memset.*</tt>' Intrinsic</a></li> + <li><a href="#int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a></li> + <li><a href="#int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a></li> + </ol> + </li> + <li><a href="#int_manip">Bit Manipulation Intrinsics</a> + <ol> + <li><a href="#int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a></li> + <li><a href="#int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic </a></li> + <li><a href="#int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic </a></li> + <li><a href="#int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic </a></li> + <li><a href="#int_part_select">'<tt>llvm.part.select.*</tt>' Intrinsic </a></li> + <li><a href="#int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic </a></li> + </ol> + </li> + <li><a href="#int_debugger">Debugger intrinsics</a></li> + <li><a href="#int_eh">Exception Handling intrinsics</a></li> + <li><a href="#int_general">General intrinsics</a></li> + <ol> + <li><a href="#int_var_annotation">'<tt>llvm.var.annotation</tt>' + Intrinsic</a></li> + </ol> + </li> + </ol> + </li> +</ol> + +<div class="doc_author"> + <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> + and <a href="mailto:vadve@cs.uiuc.edu">Vikram Adve</a></p> +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="abstract">Abstract </a></div> +<!-- *********************************************************************** --> + +<div class="doc_text"> +<p>This document is a reference manual for the LLVM assembly language. +LLVM is an SSA based representation that provides type safety, +low-level operations, flexibility, and the capability of representing +'all' high-level languages cleanly. It is the common code +representation used throughout all phases of the LLVM compilation +strategy.</p> +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="introduction">Introduction</a> </div> +<!-- *********************************************************************** --> + +<div class="doc_text"> + +<p>The LLVM code representation is designed to be used in three +different forms: as an in-memory compiler IR, as an on-disk bitcode +representation (suitable for fast loading by a Just-In-Time compiler), +and as a human readable assembly language representation. This allows +LLVM to provide a powerful intermediate representation for efficient +compiler transformations and analysis, while providing a natural means +to debug and visualize the transformations. The three different forms +of LLVM are all equivalent. This document describes the human readable +representation and notation.</p> + +<p>The LLVM representation aims to be light-weight and low-level +while being expressive, typed, and extensible at the same time. It +aims to be a "universal IR" of sorts, by being at a low enough level +that high-level ideas may be cleanly mapped to it (similar to how +microprocessors are "universal 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 be promoted to a simple SSA +value instead of a memory location.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="wellformed">Well-Formedness</a> </div> + +<div class="doc_text"> + +<p>It is important to note that this document describes 'well formed' +LLVM assembly language. There is a difference between what the parser +accepts and what is considered 'well formed'. For example, the +following instruction is syntactically okay, but not well formed:</p> + +<div class="doc_code"> +<pre> +%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 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> + +<!-- Describe the typesetting conventions here. --> </div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="identifiers">Identifiers</a> </div> +<!-- *********************************************************************** --> + +<div class="doc_text"> + +<p>LLVM uses three different forms of identifiers, for different +purposes:</p> + +<ol> + <li>Named values are represented as a string of characters with a '%' prefix. + For example, %foo, %DivisionByZero, %a.really.long.identifier. The actual + regular expression used is '<tt>%[a-zA-Z$._][a-zA-Z$._0-9]*</tt>'. + Identifiers which require other characters in their names can be surrounded + with quotes. In this way, anything except a <tt>"</tt> character can be used + in a name.</li> + + <li>Unnamed values are represented as an unsigned numeric value with a '%' + prefix. For example, %12, %2, %44.</li> + + <li>Constants, which are described in a <a href="#constants">section about + constants</a>, below.</li> +</ol> + +<p>LLVM requires that values start with a '%' sign for two reasons: Compilers +don't need to worry about name clashes with reserved words, and the set of +reserved words may be expanded in the future without penalty. Additionally, +unnamed identifiers allow a compiler to quickly come up with a temporary +variable without having to avoid symbol table conflicts.</p> + +<p>Reserved words in LLVM are very similar to reserved words in other +languages. There are keywords for different opcodes +('<tt><a href="#i_add">add</a></tt>', + '<tt><a href="#i_bitcast">bitcast</a></tt>', + '<tt><a href="#i_ret">ret</a></tt>', etc...), for primitive type names ('<tt><a +href="#t_void">void</a></tt>', '<tt><a href="#t_primitive">i32</a></tt>', etc...), +and others. These reserved words cannot conflict with variable names, because +none of them start with a '%' character.</p> + +<p>Here is an example of LLVM code to multiply the integer variable +'<tt>%X</tt>' by 8:</p> + +<p>The easy way:</p> + +<div class="doc_code"> +<pre> +%result = <a href="#i_mul">mul</a> i32 %X, 8 +</pre> +</div> + +<p>After strength reduction:</p> + +<div class="doc_code"> +<pre> +%result = <a href="#i_shl">shl</a> i32 %X, i8 3 +</pre> +</div> + +<p>And the hard way:</p> + +<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> +%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> + +<ol> + + <li>Comments are delimited with a '<tt>;</tt>' and go until the end of + line.</li> + + <li>Unnamed temporaries are created when the result of a computation is not + assigned to a named value.</li> + + <li>Unnamed temporaries are numbered sequentially</li> + +</ol> + +<p>...and 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> + +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="highlevel">High Level Structure</a> </div> +<!-- *********************************************************************** --> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="modulestructure">Module Structure</a> +</div> + +<div class="doc_text"> + +<p>LLVM programs are composed of "Module"s, each of which is a +translation unit of the input programs. Each module consists of +functions, global variables, and symbol table entries. Modules may be +combined together with the LLVM linker, which merges function (and +global variable) definitions, resolves 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> + +<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 [13x 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>}<br> +</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 a <a href="#functionstructure">function definition</a> +for "<tt>main</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 +represented by a pointer to a memory location (in this case, a pointer to an +array of char, and a pointer to a function), and have one of the following <a +href="#linkage">linkage types</a>.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="linkage">Linkage Types</a> +</div> + +<div class="doc_text"> + +<p> +All Global Variables and Functions have one of the following types of linkage: +</p> + +<dl> + + <dt><tt><b><a name="linkage_internal">internal</a></b></tt> </dt> + + <dd>Global values with internal linkage are only directly accessible by + objects in the current module. In particular, linking code into a module with + an internal global value may cause the internal to be renamed as necessary to + avoid collisions. Because the symbol is internal to the module, all + references can be updated. This corresponds to the notion of the + '<tt>static</tt>' keyword in C. + </dd> + + <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> + + <dd>"<tt>weak</tt>" linkage is exactly the same as <tt>linkonce</tt> linkage, + except that unreferenced <tt>weak</tt> globals may not be discarded. This is + used for globals that may be emitted in multiple translation units, but that + are not guaranteed to be emitted into every translation unit that uses them. + One example of this are common globals in C, such as "<tt>int X;</tt>" at + global scope. + </dd> + + <dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt> + + <dd>"<tt>appending</tt>" linkage may only be applied to global variables of + 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> + <dd>The semantics of this linkage follow the ELF 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_external">externally visible</a></b></tt>:</dt> + + <dd>If none of the above identifiers are used, the global is externally + visible, meaning that it participates in linkage and can be used to resolve + external symbol references. + </dd> +</dl> + + <p> + The next two types of linkage are targeted for Microsoft Windows platform + only. They are designed to support importing (exporting) symbols from (to) + DLLs. + </p> + + <dl> + <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> + + <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 + name is formed by combining <code>_imp__</code> and the function or variable + name. + </dd> + +</dl> + +<p><a name="linkage_external"></a>For example, since the "<tt>.LC0</tt>" +variable is defined to be internal, if another module defined a "<tt>.LC0</tt>" +variable and was linked with this one, one of the two would be renamed, +preventing a collision. Since "<tt>main</tt>" and "<tt>puts</tt>" are +external (i.e., lacking any linkage declarations), they are accessible +outside of the current module.</p> +<p>It is illegal for a function <i>declaration</i> +to have any linkage type other than "externally visible", <tt>dllimport</tt>, +or <tt>extern_weak</tt>.</p> +<p>Aliases can have only <tt>external</tt>, <tt>internal</tt> and <tt>weak</tt> +linkages. +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="callingconv">Calling Conventions</a> +</div> + +<div class="doc_text"> + +<p>LLVM <a href="#functionstructure">functions</a>, <a href="#i_call">calls</a> +and <a href="#i_invoke">invokes</a> can all have an optional calling convention +specified for the call. The calling convention of any pair of dynamic +caller/callee must match, or the behavior of the program is undefined. The +following calling conventions are supported by LLVM, and more may be added in +the future:</p> + +<dl> + <dt><b>"<tt>ccc</tt>" - The C calling convention</b>:</dt> + + <dd>This calling convention (the default if no other calling convention is + specified) matches the target C calling conventions. This calling convention + supports varargs function calls and tolerates some mismatch in the declared + prototype and implemented declaration of the function (as does normal C). + </dd> + + <dt><b>"<tt>fastcc</tt>" - The fast calling convention</b>:</dt> + + <dd>This calling convention attempts to make calls as fast as possible + (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. Implementations of + this convention should allow arbitrary tail call optimization to be supported. + This calling convention does not support varargs and requires the prototype of + all callees to exactly match the prototype of the function definition. + </dd> + + <dt><b>"<tt>coldcc</tt>" - The cold calling convention</b>:</dt> + + <dd>This calling convention attempts to make code in the caller as efficient + as possible under the assumption that the call is not commonly executed. As + such, these calls often preserve all registers so that the call does not break + any live ranges in the caller side. This calling convention does not support + varargs and requires the prototype of all callees to exactly match the + prototype of the function definition. + </dd> + + <dt><b>"<tt>cc <<em>n</em>></tt>" - Numbered convention</b>:</dt> + + <dd>Any calling convention may be specified by number, allowing + target-specific calling conventions to be used. Target specific calling + conventions start at 64. + </dd> +</dl> + +<p>More calling conventions can be added/defined on an as-needed basis, to +support pascal conventions or any other well-known target-independent +convention.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="visibility">Visibility Styles</a> +</div> + +<div class="doc_text"> + +<p> +All Global Variables and Functions have one of the following visibility styles: +</p> + +<dl> + <dt><b>"<tt>default</tt>" - Default style</b>:</dt> + + <dd>On ELF, default visibility means that the declaration is visible to other + modules and, in shared libraries, means that the declared entity may be + overridden. On Darwin, default visibility means that the declaration is + visible to other modules. Default visibility corresponds to "external + linkage" in the language. + </dd> + + <dt><b>"<tt>hidden</tt>" - Hidden style</b>:</dt> + + <dd>Two declarations of an object with hidden visibility refer to the same + object if they are in the same shared object. Usually, hidden visibility + indicates that the symbol will not be placed into the dynamic symbol table, + so no other module (executable or shared library) can reference it + directly. + </dd> + + <dt><b>"<tt>protected</tt>" - Protected style</b>:</dt> + + <dd>On ELF, protected visibility indicates that the symbol will be placed in + the dynamic symbol table, but that references within the defining module will + bind to the local symbol. That is, the symbol cannot be overridden by another + module. + </dd> +</dl> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="globalvars">Global Variables</a> +</div> + +<div class="doc_text"> + +<p>Global variables define regions of memory allocated at compilation time +instead of run-time. Global variables may optionally be initialized, may have +an explicit section to be placed in, and may have an optional explicit alignment +specified. A variable may be defined as "thread_local", which means that it +will not be shared by threads (each thread will have a separated copy of the +variable). A variable may be defined as a global "constant," which indicates +that the contents of the variable will <b>never</b> be modified (enabling better +optimization, allowing the global data to be placed in the read-only section of +an executable, etc). Note that variables that need runtime initialization +cannot be marked "constant" as there is a store to the variable.</p> + +<p> +LLVM explicitly allows <em>declarations</em> of global variables to be marked +constant, even if the final definition of the global is not. This capability +can be used to enable slightly better optimization of the program, but requires +the language definition to guarantee that optimizations based on the +'constantness' are valid for the translation units that do not include the +definition. +</p> + +<p>As SSA values, global variables define pointer values that are in +scope (i.e. they dominate) all basic blocks in the program. Global +variables always define a pointer to their "content" type because they +describe a region of memory, and all memory objects in LLVM are +accessed through pointers.</p> + +<p>LLVM allows an explicit section to be specified for globals. If the target +supports it, it will emit globals to the section specified.</p> + +<p>An explicit alignment may be specified for a global. If not present, or if +the alignment is set to zero, the alignment of the global is set by the target +to whatever it feels convenient. If an explicit alignment is specified, the +global is forced to have at least that much alignment. All alignments must be +a power of 2.</p> + +<p>For example, the following defines a global with an initializer, section, + and alignment:</p> + +<div class="doc_code"> +<pre> +@G = constant float 1.0, section "foo", align 4 +</pre> +</div> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="functionstructure">Functions</a> +</div> + +<div class="doc_text"> + +<p>LLVM function definitions consist of the "<tt>define</tt>" keyord, +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="#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>), an optional section, an +optional alignment, an opening curly brace, a list of basic blocks, and a +closing curly brace. + +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="#paramattrs">parameter attribute</a> for the return type, a function +name, a possibly empty list of arguments, and an optional alignment.</p> + +<p>A function definition contains a list of basic blocks, forming the CFG for +the function. Each basic block may optionally start with a label (giving the +basic block a symbol table entry), contains a list of instructions, and ends +with a <a href="#terminators">terminator</a> instruction (such as a branch or +function return).</p> + +<p>The first basic block in a function is special in two ways: it is immediately +executed on entrance to the function, and it is not allowed to have predecessor +basic blocks (i.e. there can not be any branches to the entry block of a +function). Because the block can have no predecessors, it also cannot have any +<a href="#i_phi">PHI nodes</a>.</p> + +<p>LLVM allows an explicit section to be specified for functions. If the target +supports it, it will emit functions to the section specified.</p> + +<p>An explicit alignment may be specified for a function. If not present, or if +the alignment is set to zero, the alignment of the function is set by the target +to whatever it feels convenient. If an explicit alignment is specified, the +function is forced to have at least that much alignment. All alignments must be +a power of 2.</p> + +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="aliasstructure">Aliases</a> +</div> +<div class="doc_text"> + <p>Aliases act as "second name" for the aliasee value (which can be either + function or global variable or bitcast of global value). Aliases may have an + optional <a href="#linkage">linkage type</a>, and an + optional <a href="#visibility">visibility style</a>.</p> + + <h5>Syntax:</h5> + +<div class="doc_code"> +<pre> +@<Name> = [Linkage] [Visibility] alias <AliaseeTy> @<Aliasee> +</pre> +</div> + +</div> + + + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="paramattrs">Parameter Attributes</a></div> +<div class="doc_text"> + <p>The return type and each parameter of a function type may have a set of + <i>parameter attributes</i> associated with them. Parameter attributes are + used to communicate additional information about the result or parameters of + a function. Parameter attributes are considered to be part of the function + type so two functions types that differ only by the parameter attributes + are different function types.</p> + + <p>Parameter attributes are simple keywords that follow the type specified. If + multiple parameter attributes are needed, they are space separated. For + example:</p> + +<div class="doc_code"> +<pre> +%someFunc = i16 (i8 sext %someParam) zext +%someFunc = i16 (i8 zext %someParam) zext +</pre> +</div> + + <p>Note that the two function types above are unique because the parameter has + a different attribute (sext in the first one, zext in the second). Also note + that the attribute for the function result (zext) comes immediately after the + argument list.</p> + + <p>Currently, only the following parameter attributes are defined:</p> + <dl> + <dt><tt>zext</tt></dt> + <dd>This indicates that the parameter should be zero extended just before + a call to this function.</dd> + <dt><tt>sext</tt></dt> + <dd>This indicates that the parameter should be sign extended just before + a call to this function.</dd> + <dt><tt>inreg</tt></dt> + <dd>This indicates that the parameter should be placed in register (if + possible) during assembling function call. Support for this attribute is + target-specific</dd> + <dt><tt>sret</tt></dt> + <dd>This indicates that the parameter specifies the address of a structure + that is the return value of the function in the source program.</dd> + <dt><tt>noalias</tt></dt> + <dd>This indicates that the parameter not alias any other object or any + other "noalias" objects during the function call. + <dt><tt>noreturn</tt></dt> + <dd>This function attribute indicates that the function never returns. This + indicates to LLVM that every call to this function should be treated as if + an <tt>unreachable</tt> instruction immediately followed the call.</dd> + <dt><tt>nounwind</tt></dt> + <dd>This function attribute indicates that the function type does not use + the unwind instruction and does not allow stack unwinding to propagate + through it.</dd> + </dl> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="moduleasm">Module-Level Inline Assembly</a> +</div> + +<div class="doc_text"> +<p> +Modules may contain "module-level inline asm" blocks, which corresponds to the +GCC "file scope inline asm" blocks. These blocks are internally concatenated by +LLVM and treated as a single unit, but may be separated in the .ll file if +desired. The syntax is very simple: +</p> + +<div class="doc_code"> +<pre> +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 + for the number. +</p> + +<p> + The inline asm code is simply printed to the machine code .s file when + assembly code is generated. +</p> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="datalayout">Data Layout</a> +</div> + +<div class="doc_text"> +<p>A module may specify a target specific data layout string that specifies how +data is to be laid out in memory. The syntax for the data layout is simply:</p> +<pre> target datalayout = "<i>layout specification</i>"</pre> +<p>The <i>layout specification</i> consists of a list of specifications +separated by the minus sign character ('-'). Each specification starts with a +letter and may include other information after the letter to define some +aspect of the data layout. The specifications accepted are as follows: </p> +<dl> + <dt><tt>E</tt></dt> + <dd>Specifies that the target lays out data in big-endian form. That is, the + bits with the most significance have the lowest address location.</dd> + <dt><tt>e</tt></dt> + <dd>Specifies that hte target lays out data in little-endian form. That is, + the bits with the least significance have the lowest address 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 + <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> + <dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> + <dd>This specifies the alignment for an integer type of a given bit + <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 + <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 + <i>size</i>. The value of <i>size</i> must be either 32 (float) or 64 + (double).</dd> + <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 + <i>size</i>.</dd> +</dl> +<p>When constructing the data layout for a given target, LLVM starts with a +default set of specifications which are then (possibly) overriden by the +specifications in the <tt>datalayout</tt> keyword. The default specifications +are given in this list:</p> +<ul> + <li><tt>E</tt> - big endian</li> + <li><tt>p:32:64:64</tt> - 32-bit pointers with 64-bit alignment</li> + <li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li> + <li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li> + <li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li> + <li><tt>i32:32:32</tt> - i32 is 32-bit aligned</li> + <li><tt>i64:32:64</tt> - i64 has abi alignment of 32-bits but preferred + alignment of 64-bits</li> + <li><tt>f32:32:32</tt> - float is 32-bit aligned</li> + <li><tt>f64:64:64</tt> - double is 64-bit aligned</li> + <li><tt>v64:64:64</tt> - 64-bit vector is 64-bit aligned</li> + <li><tt>v128:128:128</tt> - 128-bit vector is 128-bit aligned</li> + <li><tt>a0:0:1</tt> - aggregates are 8-bit aligned</li> +</ul> +<p>When llvm is determining the alignment for a given type, it uses the +following rules: +<ol> + <li>If the type sought is an exact match for one of the specifications, that + specification is used.</li> + <li>If no match is found, and the type sought is an integer type, then the + smallest integer type that is larger than the bitwidth of the sought type is + used. If none of the specifications are larger than the bitwidth then the the + largest integer type is used. For example, given the default specifications + above, the i7 type will use the alignment of i8 (next largest) while both + i65 and i256 will use the alignment of i64 (largest specified).</li> + <li>If no match is found, and the type sought is a vector type, then the + largest vector type that is smaller than the sought vector type will be used + as a fall back. This happens because <128 x double> can be implemented in + terms of 64 <2 x double>, for example.</li> +</ol> +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="typesystem">Type System</a> </div> +<!-- *********************************************************************** --> + +<div class="doc_text"> + +<p>The LLVM type system is one of the most important features of the +intermediate representation. Being typed enables a number of +optimizations to be performed on the IR directly, without having to do +extra analyses on the side before the transformation. A strong type +system makes it easier to read the generated code and enables novel +analyses and transformations that are not feasible to perform on normal +three address code representations.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="t_primitive">Primitive Types</a> </div> +<div class="doc_text"> +<p>The primitive types are the fundamental building blocks of the LLVM +system. The current set of primitive types is as follows:</p> + +<table class="layout"> + <tr class="layout"> + <td class="left"> + <table> + <tbody> + <tr><th>Type</th><th>Description</th></tr> + <tr><td><tt><a name="t_void">void</a></tt></td><td>No value</td></tr> + <tr><td><tt>label</tt></td><td>Branch destination</td></tr> + </tbody> + </table> + </td> + <td class="right"> + <table> + <tbody> + <tr><th>Type</th><th>Description</th></tr> + <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr> + <tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr> + </tbody> + </table> + </td> + </tr> +</table> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_classifications">Type +Classifications</a> </div> +<div class="doc_text"> +<p>These different primitive types fall into a few useful +classifications:</p> + +<table border="1" cellspacing="0" cellpadding="4"> + <tbody> + <tr><th>Classification</th><th>Types</th></tr> + <tr> + <td><a name="t_integer">integer</a></td> + <td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td> + </tr> + <tr> + <td><a name="t_floating">floating point</a></td> + <td><tt>float, double</tt></td> + </tr> + <tr> + <td><a name="t_firstclass">first class</a></td> + <td><tt>i1, ..., float, double, <br/> + <a href="#t_pointer">pointer</a>,<a href="#t_vector">vector</a></tt> + </td> + </tr> + </tbody> +</table> + +<p>The <a href="#t_firstclass">first class</a> types are perhaps the +most important. Values of these types are the only ones which can be +produced by instructions, passed as arguments, or used as operands to +instructions. This means that all structures and arrays must be +manipulated either by pointer or by component.</p> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="t_derived">Derived Types</a> </div> + +<div class="doc_text"> + +<p>The real power in LLVM comes from the derived types in the system. +This is what allows a programmer to represent arrays, functions, +pointers, and other useful types. Note that these derived types may be +recursive: For example, it is possible to have a two dimensional array.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_integer">Integer Type</a> </div> + +<div class="doc_text"> + +<h5>Overview:</h5> +<p>The integer type is a very simple derived type that simply specifies an +arbitrary bit width for the integer type desired. Any bit width from 1 bit to +2^23-1 (about 8 million) can be specified.</p> + +<h5>Syntax:</h5> + +<pre> + iN +</pre> + +<p>The number of bits the integer will occupy is specified by the <tt>N</tt> +value.</p> + +<h5>Examples:</h5> +<table class="layout"> + <tr class="layout"> + <td class="left"> + <tt>i1</tt><br/> + <tt>i4</tt><br/> + <tt>i8</tt><br/> + <tt>i16</tt><br/> + <tt>i32</tt><br/> + <tt>i42</tt><br/> + <tt>i64</tt><br/> + <tt>i1942652</tt><br/> + </td> + <td class="left"> + A boolean integer of 1 bit<br/> + A nibble sized integer of 4 bits.<br/> + A byte sized integer of 8 bits.<br/> + A half word sized integer of 16 bits.<br/> + A word sized integer of 32 bits.<br/> + An integer whose bit width is the answer. <br/> + A double word sized integer of 64 bits.<br/> + A really big integer of over 1 million bits.<br/> + </td> + </tr> +</table> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_array">Array Type</a> </div> + +<div class="doc_text"> + +<h5>Overview:</h5> + +<p>The array type is a very simple derived type that arranges elements +sequentially in memory. The array type requires a size (number of +elements) and an underlying data type.</p> + +<h5>Syntax:</h5> + +<pre> + [<# elements> x <elementtype>] +</pre> + +<p>The number of elements is a constant integer value; elementtype may +be any type with a size.</p> + +<h5>Examples:</h5> +<table class="layout"> + <tr class="layout"> + <td class="left"> + <tt>[40 x i32 ]</tt><br/> + <tt>[41 x i32 ]</tt><br/> + <tt>[40 x i8]</tt><br/> + </td> + <td class="left"> + Array of 40 32-bit integer values.<br/> + Array of 41 32-bit integer values.<br/> + Array of 40 8-bit integer values.<br/> + </td> + </tr> +</table> +<p>Here are some examples of multidimensional arrays:</p> +<table class="layout"> + <tr class="layout"> + <td class="left"> + <tt>[3 x [4 x i32]]</tt><br/> + <tt>[12 x [10 x float]]</tt><br/> + <tt>[2 x [3 x [4 x i16]]]</tt><br/> + </td> + <td class="left"> + 3x4 array of 32-bit integer values.<br/> + 12x10 array of single precision floating point values.<br/> + 2x3x4 array of 16-bit integer values.<br/> + </td> + </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 "{ i32, [0 x float]}", for example.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_function">Function Type</a> </div> +<div class="doc_text"> +<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. +Function types are usually used to build virtual function tables +(which are structures of pointers to functions), for indirect function +calls, and when defining a function.</p> +<p> +The return type of a function type cannot be an aggregate type. +</p> +<h5>Syntax:</h5> +<pre> <returntype> (<parameter list>)<br></pre> +<p>...where '<tt><parameter list></tt>' is a comma-separated list of type +specifiers. Optionally, the parameter list may include a type <tt>...</tt>, +which indicates that the function takes a variable number of arguments. +Variable argument functions can access their arguments with the <a + href="#int_varargs">variable argument handling intrinsic</a> functions.</p> +<h5>Examples:</h5> +<table class="layout"> + <tr class="layout"> + <td class="left"><tt>i32 (i32)</tt></td> + <td class="left">function taking an <tt>i32</tt>, returning an <tt>i32</tt> + </td> + </tr><tr class="layout"> + <td class="left"><tt>float (i16 sext, 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 + <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 + LLVM. + </td> + </tr> +</table> + +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_struct">Structure Type</a> </div> +<div class="doc_text"> +<h5>Overview:</h5> +<p>The structure type is used to represent a collection of data members +together in memory. The packing of the field types is defined to match +the ABI of the 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> +<h5>Syntax:</h5> +<pre> { <type list> }<br></pre> +<h5>Examples:</h5> +<table class="layout"> + <tr class="layout"> + <td class="left"><tt>{ i32, i32, i32 }</tt></td> + <td class="left">A triple of three <tt>i32</tt> values</td> + </tr><tr class="layout"> + <td class="left"><tt>{ float, i32 (i32) * }</tt></td> + <td class="left">A pair, 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_pstruct">Packed Structure Type</a> +</div> +<div class="doc_text"> +<h5>Overview:</h5> +<p>The packed structure type is used to represent a collection of data members +together in memory. There is no padding between fields. Further, the alignment +of a packed structure is 1 byte. The elements of a packed 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> +<h5>Syntax:</h5> +<pre> < { <type list> } > <br></pre> +<h5>Examples:</h5> +<table class="layout"> + <tr class="layout"> + <td class="left"><tt>< { i32, i32, i32 } ></tt></td> + <td class="left">A triple of three <tt>i32</tt> values</td> + </tr><tr class="layout"> + <td class="left"><tt>< { float, i32 (i32) * } ></tt></td> + <td class="left">A pair, 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> +<div class="doc_text"> +<h5>Overview:</h5> +<p>As in many languages, the pointer type represents a pointer or +reference to another object, which must live in memory.</p> +<h5>Syntax:</h5> +<pre> <type> *<br></pre> +<h5>Examples:</h5> +<table class="layout"> + <tr class="layout"> + <td class="left"> + <tt>[4x i32]*</tt><br/> + <tt>i32 (i32 *) *</tt><br/> + </td> + <td class="left"> + A <a href="#t_pointer">pointer</a> to <a href="#t_array">array</a> of + four <tt>i32</tt> values<br/> + 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>.<br/> + </td> + </tr> +</table> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_vector">Vector Type</a> </div> +<div class="doc_text"> + +<h5>Overview:</h5> + +<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 <a href="#t_firstclass">first class</a>.</p> + +<h5>Syntax:</h5> + +<pre> + < <# elements> x <elementtype> > +</pre> + +<p>The number of elements is a constant integer value; elementtype may +be any integer or floating point type.</p> + +<h5>Examples:</h5> + +<table class="layout"> + <tr class="layout"> + <td class="left"> + <tt><4 x i32></tt><br/> + <tt><8 x float></tt><br/> + <tt><2 x i64></tt><br/> + </td> + <td class="left"> + Vector of 4 32-bit integer values.<br/> + Vector of 8 floating-point values.<br/> + Vector of 2 64-bit integer values.<br/> + </td> + </tr> +</table> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="t_opaque">Opaque Type</a> </div> +<div class="doc_text"> + +<h5>Overview:</h5> + +<p>Opaque types are used to represent unknown types in the system. This +corresponds (for example) to the C notion of a foward declared structure type. +In LLVM, opaque types can eventually be resolved to any type (not just a +structure type).</p> + +<h5>Syntax:</h5> + +<pre> + opaque +</pre> + +<h5>Examples:</h5> + +<table class="layout"> + <tr class="layout"> + <td class="left"> + <tt>opaque</tt> + </td> + <td class="left"> + An opaque type.<br/> + </td> + </tr> +</table> +</div> + + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="constants">Constants</a> </div> +<!-- *********************************************************************** --> + +<div class="doc_text"> + +<p>LLVM has several different basic types of constants. This section describes +them all and their syntax.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="simpleconstants">Simple Constants</a></div> + +<div class="doc_text"> + +<dl> + <dt><b>Boolean constants</b></dt> + + <dd>The two strings '<tt>true</tt>' and '<tt>false</tt>' are both valid + constants of the <tt><a href="#t_primitive">i1</a></tt> type. + </dd> + + <dt><b>Integer constants</b></dt> + + <dd>Standard integers (such as '4') are constants of the <a + href="#t_integer">integer</a> type. Negative numbers may be used with + integer types. + </dd> + + <dt><b>Floating point constants</b></dt> + + <dd>Floating point constants use standard decimal notation (e.g. 123.421), + exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal + notation (see below). Floating point constants must have a <a + href="#t_floating">floating point</a> type. </dd> + + <dt><b>Null pointer constants</b></dt> + + <dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant + and must be of <a href="#t_pointer">pointer type</a>.</dd> + +</dl> + +<p>The one non-intuitive notation for constants is the optional hexadecimal form +of floating point constants. For example, the form '<tt>double +0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) '<tt>double +4.5e+15</tt>'. The only time hexadecimal floating point constants are required +(and the only time that they are generated by the disassembler) is when a +floating point constant must be emitted but it cannot be represented as a +decimal floating point number. For example, NaN's, infinities, and other +special values are represented in their IEEE hexadecimal format so that +assembly and disassembly do not cause any bits to change in the constants.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="aggregateconstants">Aggregate Constants</a> +</div> + +<div class="doc_text"> +<p>Aggregate constants arise from aggregation of simple constants +and smaller aggregate constants.</p> + +<dl> + <dt><b>Structure constants</b></dt> + + <dd>Structure constants are represented with notation similar to structure + type definitions (a comma separated list of elements, surrounded by braces + (<tt>{}</tt>)). For example: "<tt>{ i32 4, float 17.0, i32* %G }</tt>", + where "<tt>%G</tt>" is declared as "<tt>@G = external global i32</tt>". Structure constants + must have <a href="#t_struct">structure type</a>, and the number and + types of elements must match those specified by the type. + </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 brackets + (<tt>[]</tt>)). For example: "<tt>[ i32 42, i32 11, i32 74 ]</tt>". Array + constants must have <a href="#t_array">array type</a>, and the number and + types of elements must match those specified by the type. + </dd> + + <dt><b>Vector constants</b></dt> + + <dd>Vector constants are represented with notation similar to vector type + definitions (a comma separated list of elements, surrounded by + less-than/greater-than's (<tt><></tt>)). For example: "<tt>< i32 42, + i32 11, i32 74, i32 100 ></tt>". Vector constants must have <a + href="#t_vector">vector type</a>, and the number and types of elements must + match those specified by the type. + </dd> + + <dt><b>Zero initialization</b></dt> + + <dd>The string '<tt>zeroinitializer</tt>' can be used to zero initialize a + value to zero of <em>any</em> type, including scalar and aggregate types. + This is often used to avoid having to print large zero initializers (e.g. for + large arrays) and is always exactly equivalent to using explicit zero + initializers. + </dd> +</dl> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="globalconstants">Global Variable and Function Addresses</a> +</div> + +<div class="doc_text"> + +<p>The addresses of <a href="#globalvars">global variables</a> and <a +href="#functionstructure">functions</a> are always implicitly valid (link-time) +constants. These constants are explicitly referenced when the <a +href="#identifiers">identifier for the global</a> is used and always have <a +href="#t_pointer">pointer</a> type. For example, the following is a legal LLVM +file:</p> + +<div class="doc_code"> +<pre> +@X = global i32 17 +@Y = global i32 42 +@Z = global [2 x i32*] [ i32* @X, i32* @Y ] +</pre> +</div> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="undefvalues">Undefined Values</a></div> +<div class="doc_text"> + <p>The string '<tt>undef</tt>' is recognized as a type-less constant that has + no specific value. Undefined values may be of any type and be used anywhere + a constant is permitted.</p> + + <p>Undefined values indicate to the compiler that the program is well defined + no matter what value is used, giving the compiler more freedom to optimize. + </p> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"><a name="constantexprs">Constant Expressions</a> +</div> + +<div class="doc_text"> + +<p>Constant expressions are used to allow expressions involving other constants +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> + +<dl> + <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> + <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> + + <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> + + <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> + <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>fp2uint ( CST to TYPE )</tt></b></dt> + <dd>Convert a floating point constant to the corresponding unsigned integer + constant. TYPE must be an integer type. CST must be floating point. 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> + <dd>Convert a floating point constant to the corresponding signed integer + constant. TYPE must be an integer type. CST must be floating point. 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> + <dd>Convert an unsigned integer constant to the corresponding floating point + constant. TYPE must be floating point. CST must be of integer type. 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> + <dd>Convert a signed integer constant to the corresponding floating point + constant. TYPE must be floating point. CST must be of integer type. 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> + <dd>Convert a pointer typed constant to the corresponding integer constant + TYPE must be an integer type. CST must be of pointer type. The CST value is + zero extended, truncated, or unchanged to make it fit in TYPE.</dd> + + <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> + <dd>Convert a constant, CST, to another TYPE. The size of CST and TYPE must be + identical (same number of bits). The conversion is done as if the CST value + was stored to memory and read back as TYPE. In other words, no bits change + with this operator, just the type. This can be used for conversion of + vector types to any other type, as long as they have the same bit width. For + pointers it is only valid to cast to another pointer type. + </dd> + + <dt><b><tt>getelementptr ( 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> + + <dd>Perform the <a href="#i_select">select operation</a> on + constants.</dd> + + <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> + <dd>Performs the <a href="#i_fcmp">fcmp operation</a> on constants.</dd> + + <dt><b><tt>extractelement ( VAL, IDX )</tt></b></dt> + + <dd>Perform the <a href="#i_extractelement">extractelement + operation</a> on constants. + + <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> + + <dd>Perform the <a href="#i_shufflevector">shufflevector + operation</a> on constants.</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 on operands are the same as those for + the corresponding instruction (e.g. no bitwise operations on floating point + values are allowed).</dd> +</dl> +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="othervalues">Other Values</a> </div> +<!-- *********************************************************************** --> + +<!-- ======================================================================= --> +<div class="doc_subsection"> +<a name="inlineasm">Inline Assembler Expressions</a> +</div> + +<div class="doc_text"> + +<p> +LLVM supports inline assembler expressions (as opposed to <a href="#moduleasm"> +Module-Level Inline Assembly</a>) through the use of a special value. This +value represents the inline assembler as a string (containing the instructions +to emit), a list of operand constraints (stored as a string), and a flag that +indicates whether or not the inline asm expression has side effects. An example +inline assembler expression is: +</p> + +<div class="doc_code"> +<pre> +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> +%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> +call void asm sideeffect "eieio", ""() +</pre> +</div> + +<p>TODO: The format of the asm and constraints string still need to be +documented here. Constraints on what can be done (e.g. duplication, moving, etc +need to be documented). +</p> + +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="instref">Instruction Reference</a> </div> +<!-- *********************************************************************** --> + +<div class="doc_text"> + +<p>The LLVM instruction set consists of several different +classifications of instructions: <a href="#terminators">terminator +instructions</a>, <a href="#binaryops">binary instructions</a>, +<a href="#bitwiseops">bitwise binary instructions</a>, <a + href="#memoryops">memory instructions</a>, and <a href="#otherops">other +instructions</a>.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="terminators">Terminator +Instructions</a> </div> + +<div class="doc_text"> + +<p>As mentioned <a href="#functionstructure">previously</a>, every +basic block in a program ends with a "Terminator" instruction, which +indicates which block should be executed after the current block is +finished. These terminator instructions typically yield a '<tt>void</tt>' +value: they produce control flow, not values (the one exception being +the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p> +<p>There are six different terminator instructions: the '<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_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> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_ret">'<tt>ret</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> ret <type> <value> <i>; Return a value from a non-void function</i> + ret void <i>; Return from void function</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>ret</tt>' instruction is used to return control flow (and a +value) from a function back to the caller.</p> +<p>There are two forms of the '<tt>ret</tt>' instruction: one that +returns a value and then causes control flow, and one that just causes +control flow to occur.</p> +<h5>Arguments:</h5> +<p>The '<tt>ret</tt>' instruction may return any '<a + href="#t_firstclass">first class</a>' type. Notice that a function is +not <a href="#wellformed">well formed</a> if there exists a '<tt>ret</tt>' +instruction inside of the function that returns a value that does not +match the return type of the function.</p> +<h5>Semantics:</h5> +<p>When the '<tt>ret</tt>' instruction is executed, control flow +returns back to the calling function's context. If the caller is a "<a + href="#i_call"><tt>call</tt></a>" instruction, execution continues at +the instruction after the call. If the caller was an "<a + href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues +at the beginning of the "normal" destination block. If the instruction +returns a value, that value shall set the call or invoke instruction's +return value.</p> +<h5>Example:</h5> +<pre> ret i32 5 <i>; Return an integer value of 5</i> + ret void <i>; Return from a void function</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> br i1 <cond>, label <iftrue>, label <iffalse><br> br label <dest> <i>; Unconditional branch</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>br</tt>' instruction is used to cause control flow to +transfer to a different basic block in the current function. There are +two forms of this instruction, corresponding to a conditional branch +and an unconditional branch.</p> +<h5>Arguments:</h5> +<p>The conditional branch form of the '<tt>br</tt>' instruction takes a +single '<tt>i1</tt>' value and two '<tt>label</tt>' values. The +unconditional form of the '<tt>br</tt>' instruction takes a single +'<tt>label</tt>' value as a target.</p> +<h5>Semantics:</h5> +<p>Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>i1</tt>' +argument is evaluated. If the value is <tt>true</tt>, control flows +to the '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>, +control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p> +<h5>Example:</h5> +<pre>Test:<br> %cond = <a href="#i_icmp">icmp</a> eq, i32 %a, %b<br> br i1 %cond, label %IfEqual, label %IfUnequal<br>IfEqual:<br> <a + href="#i_ret">ret</a> i32 1<br>IfUnequal:<br> <a href="#i_ret">ret</a> i32 0<br></pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_switch">'<tt>switch</tt>' Instruction</a> +</div> + +<div class="doc_text"> +<h5>Syntax:</h5> + +<pre> + switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ] +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of +several different places. It is a generalization of the '<tt>br</tt>' +instruction, allowing a branch to occur to one of many possible +destinations.</p> + + +<h5>Arguments:</h5> + +<p>The '<tt>switch</tt>' instruction uses three parameters: an integer +comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination, and +an array of pairs of comparison value constants and '<tt>label</tt>'s. The +table is not allowed to contain duplicate constant entries.</p> + +<h5>Semantics:</h5> + +<p>The <tt>switch</tt> instruction specifies a table of values and +destinations. When the '<tt>switch</tt>' instruction is executed, this +table is searched for the given value. If the value is found, control flow is +transfered to the corresponding destination; otherwise, control flow is +transfered to the default destination.</p> + +<h5>Implementation:</h5> + +<p>Depending on properties of the target machine and the particular +<tt>switch</tt> instruction, this instruction may be code generated in different +ways. For example, it could be generated as a series of chained conditional +branches or with a lookup table.</p> + +<h5>Example:</h5> + +<pre> + <i>; Emulate a conditional br instruction</i> + %Val = <a href="#i_zext">zext</a> i1 %value to i32 + switch i32 %Val, label %truedest [i32 0, label %falsedest ] + + <i>; Emulate an unconditional br instruction</i> + switch i32 0, label %dest [ ] + + <i>; Implement a jump table:</i> + switch i32 %val, label %otherwise [ i32 0, label %onzero + i32 1, label %onone + i32 2, label %ontwo ] +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_invoke">'<tt>invoke</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = invoke [<a href="#callingconv">cconv</a>] <ptr to function ty> %<function ptr val>(<function args>) + to label <normal label> unwind label <exception label> +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>invoke</tt>' instruction causes control to transfer to a specified +function, with the possibility of control flow transfer to either the +'<tt>normal</tt>' label or the +'<tt>exception</tt>' label. If the callee function returns with the +"<tt><a href="#i_ret">ret</a></tt>" instruction, control flow will return to the +"normal" label. If the callee (or any indirect callees) returns with the "<a +href="#i_unwind"><tt>unwind</tt></a>" instruction, control is interrupted and +continued at the dynamically nearest "exception" label.</p> + +<h5>Arguments:</h5> + +<p>This instruction requires several arguments:</p> + +<ol> + <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> + <li>'<tt>ptr to function ty</tt>': shall be the signature of the pointer to + function value being invoked. In most cases, this is a direct function + invocation, but indirect <tt>invoke</tt>s are just as possible, branching off + an arbitrary pointer to function value. + </li> + + <li>'<tt>function ptr val</tt>': An LLVM value containing a pointer to a + function to be invoked. </li> + + <li>'<tt>function args</tt>': argument list whose types match the function + signature argument types. If the function signature indicates the function + accepts a variable number of arguments, the extra arguments can be + specified. </li> + + <li>'<tt>normal label</tt>': the label reached when the called function + executes a '<tt><a href="#i_ret">ret</a></tt>' instruction. </li> + + <li>'<tt>exception label</tt>': the label reached when a callee returns with + the <a href="#i_unwind"><tt>unwind</tt></a> instruction. </li> + +</ol> + +<h5>Semantics:</h5> + +<p>This instruction is designed to operate as a standard '<tt><a +href="#i_call">call</a></tt>' instruction in most regards. The primary +difference is that it establishes an association with a label, which is used by +the runtime library to unwind the stack.</p> + +<p>This instruction is used in languages with destructors to ensure that proper +cleanup is performed in the case of either a <tt>longjmp</tt> or a thrown +exception. Additionally, this is important for implementation of +'<tt>catch</tt>' clauses in high-level languages that support them.</p> + +<h5>Example:</h5> +<pre> + %retval = invoke i32 %Test(i32 15) to label %Continue + unwind label %TestCleanup <i>; {i32}:retval set</i> + %retval = invoke <a href="#callingconv">coldcc</a> i32 %Test(i32 15) to label %Continue + unwind label %TestCleanup <i>; {i32}:retval set</i> +</pre> +</div> + + +<!-- _______________________________________________________________________ --> + +<div class="doc_subsubsection"> <a name="i_unwind">'<tt>unwind</tt>' +Instruction</a> </div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + unwind +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>unwind</tt>' instruction unwinds the stack, continuing control flow +at the first callee in the dynamic call stack which used an <a +href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call. This is +primarily used to implement exception handling.</p> + +<h5>Semantics:</h5> + +<p>The '<tt>unwind</tt>' intrinsic causes execution of the current function to +immediately halt. The dynamic call stack is then searched for the first <a +href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack. Once found, +execution continues at the "exceptional" destination block specified by the +<tt>invoke</tt> instruction. If there is no <tt>invoke</tt> instruction in the +dynamic call chain, undefined behavior results.</p> +</div> + +<!-- _______________________________________________________________________ --> + +<div class="doc_subsubsection"> <a name="i_unreachable">'<tt>unreachable</tt>' +Instruction</a> </div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + unreachable +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>unreachable</tt>' instruction has no defined semantics. This +instruction is used to inform the optimizer that a particular portion of the +code is not reachable. This can be used to indicate that the code after a +no-return function cannot be reached, and other facts.</p> + +<h5>Semantics:</h5> + +<p>The '<tt>unreachable</tt>' instruction has no defined semantics.</p> +</div> + + + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="binaryops">Binary Operations</a> </div> +<div class="doc_text"> +<p>Binary operators are used to do most of the computation in a +program. They require two operands, execute an operation on them, and +produce a single value. The operands might represent +multiple data, as is the case with the <a href="#t_vector">vector</a> data type. +The result value of a binary operator is not +necessarily the same type as its operands.</p> +<p>There are several different binary operators:</p> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_add">'<tt>add</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = add <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>add</tt>' instruction returns the sum of its two operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>add</tt>' instruction must be either <a + href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> values. + This instruction can also take <a href="#t_vector">vector</a> versions of the values. +Both arguments must have identical types.</p> +<h5>Semantics:</h5> +<p>The value produced is the integer or floating point sum of the two +operands.</p> +<h5>Example:</h5> +<pre> <result> = add i32 4, %var <i>; yields {i32}:result = 4 + %var</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_sub">'<tt>sub</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = sub <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>sub</tt>' instruction returns the difference of its two +operands.</p> +<p>Note that the '<tt>sub</tt>' instruction is used to represent the '<tt>neg</tt>' +instruction present in most other intermediate representations.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>sub</tt>' instruction must be either <a + href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> +values. +This instruction can also take <a href="#t_vector">vector</a> versions of the values. +Both arguments must have identical types.</p> +<h5>Semantics:</h5> +<p>The value produced is the integer or floating point difference of +the two operands.</p> +<h5>Example:</h5> +<pre> + <result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i> + <result> = sub i32 0, %val <i>; yields {i32}:result = -%var</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_mul">'<tt>mul</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = mul <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>mul</tt>' instruction returns the product of its two +operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>mul</tt>' instruction must be either <a + href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> +values. +This instruction can also take <a href="#t_vector">vector</a> versions of the values. +Both arguments must have identical types.</p> +<h5>Semantics:</h5> +<p>The value produced is the integer or floating point product of the +two operands.</p> +<p>Because the operands are the same width, the result of an integer +multiplication is the same whether the operands should be deemed unsigned or +signed.</p> +<h5>Example:</h5> +<pre> <result> = mul i32 4, %var <i>; yields {i32}:result = 4 * %var</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_udiv">'<tt>udiv</tt>' Instruction +</a></div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = udiv <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<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 +<a href="#t_integer">integer</a> values. Both arguments must have identical +types. This instruction can also take <a href="#t_vector">vector</a> versions +of the values in which case the elements must be integers.</p> +<h5>Semantics:</h5> +<p>The value produced is the unsigned integer quotient of the two operands. This +instruction always performs an unsigned division operation, regardless of +whether the arguments are unsigned or not.</p> +<h5>Example:</h5> +<pre> <result> = udiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_sdiv">'<tt>sdiv</tt>' Instruction +</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = sdiv <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<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 +<a href="#t_integer">integer</a> values. Both arguments must have identical +types. This instruction can also take <a href="#t_vector">vector</a> versions +of the values in which case the elements must be integers.</p> +<h5>Semantics:</h5> +<p>The value produced is the signed integer quotient of the two operands. This +instruction always performs a signed division operation, regardless of whether +the arguments are signed or not.</p> +<h5>Example:</h5> +<pre> <result> = sdiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_fdiv">'<tt>fdiv</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = fdiv <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>fdiv</tt>' instruction returns the quotient of its two +operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>fdiv</tt>' instruction must be +<a href="#t_floating">floating point</a> values. Both arguments must have +identical types. This instruction can also take <a href="#t_vector">vector</a> +versions of floating point values.</p> +<h5>Semantics:</h5> +<p>The value produced is the floating point quotient of the two operands.</p> +<h5>Example:</h5> +<pre> <result> = fdiv float 4.0, %var <i>; yields {float}:result = 4.0 / %var</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_urem">'<tt>urem</tt>' Instruction</a> +</div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = urem <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>urem</tt>' instruction returns the remainder from the +unsigned division of its two arguments.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>urem</tt>' instruction must be +<a href="#t_integer">integer</a> values. Both arguments must have identical +types.</p> +<h5>Semantics:</h5> +<p>This instruction returns the unsigned integer <i>remainder</i> of a division. +This instruction always performs an unsigned division to get the remainder, +regardless of whether the arguments are unsigned or not.</p> +<h5>Example:</h5> +<pre> <result> = urem i32 4, %var <i>; yields {i32}:result = 4 % %var</i> +</pre> + +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_srem">'<tt>srem</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = srem <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>srem</tt>' instruction returns the remainder from the +signed division of its two operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>srem</tt>' instruction must be +<a href="#t_integer">integer</a> values. Both arguments must have identical +types.</p> +<h5>Semantics:</h5> +<p>This instruction returns the <i>remainder</i> of a division (where the result +has the same sign as the dividend, <tt>var1</tt>), not the <i>modulo</i> +operator (where the result has the same sign as the divisor, <tt>var2</tt>) of +a value. For more information about the difference, see <a + href="http://mathforum.org/dr.math/problems/anne.4.28.99.html">The +Math Forum</a>. For a table of how this is implemented in various languages, +please see <a href="http://en.wikipedia.org/wiki/Modulo_operation"> +Wikipedia: modulo operation</a>.</p> +<h5>Example:</h5> +<pre> <result> = srem i32 4, %var <i>; yields {i32}:result = 4 % %var</i> +</pre> + +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_frem">'<tt>frem</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = frem <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>frem</tt>' instruction returns the remainder from the +division of its two operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>frem</tt>' instruction must be +<a href="#t_floating">floating point</a> values. Both arguments must have +identical types.</p> +<h5>Semantics:</h5> +<p>This instruction returns the <i>remainder</i> of a division.</p> +<h5>Example:</h5> +<pre> <result> = frem float 4.0, %var <i>; yields {float}:result = 4.0 % %var</i> +</pre> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="bitwiseops">Bitwise Binary +Operations</a> </div> +<div class="doc_text"> +<p>Bitwise binary operators are used to do various forms of +bit-twiddling in a program. They are generally very efficient +instructions and can commonly be strength reduced from other +instructions. They require two operands, execute an operation on them, +and produce a single value. The resulting value of the bitwise binary +operators is always the same type as its first operand.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_shl">'<tt>shl</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = shl <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>shl</tt>' instruction returns the first operand shifted to +the left a specified number of bits.</p> +<h5>Arguments:</h5> +<p>Both arguments to the '<tt>shl</tt>' instruction must be the same <a + href="#t_integer">integer</a> type.</p> +<h5>Semantics:</h5> +<p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>.</p> +<h5>Example:</h5><pre> + <result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i> + <result> = shl i32 4, 2 <i>; yields {i32}: 16</i> + <result> = shl i32 1, 10 <i>; yields {i32}: 1024</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_lshr">'<tt>lshr</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = lshr <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>lshr</tt>' instruction (logical shift right) returns the first +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 +<a href="#t_integer">integer</a> type.</p> + +<h5>Semantics:</h5> +<p>This instruction always performs a logical shift right operation. The most +significant bits of the result will be filled with zero bits after the +shift.</p> + +<h5>Example:</h5> +<pre> + <result> = lshr i32 4, 1 <i>; yields {i32}:result = 2</i> + <result> = lshr i32 4, 2 <i>; yields {i32}:result = 1</i> + <result> = lshr i8 4, 3 <i>; yields {i8}:result = 0</i> + <result> = lshr i8 -2, 1 <i>; yields {i8}:result = 0x7FFFFFFF </i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_ashr">'<tt>ashr</tt>' +Instruction</a> </div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> <result> = ashr <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>ashr</tt>' instruction (arithmetic shift right) returns the first +operand shifted to the right a specified number of bits with sign extension.</p> + +<h5>Arguments:</h5> +<p>Both arguments to the '<tt>ashr</tt>' instruction must be the same +<a href="#t_integer">integer</a> type.</p> + +<h5>Semantics:</h5> +<p>This instruction always performs an arithmetic shift right operation, +The most significant bits of the result will be filled with the sign bit +of <tt>var1</tt>.</p> + +<h5>Example:</h5> +<pre> + <result> = ashr i32 4, 1 <i>; yields {i32}:result = 2</i> + <result> = ashr i32 4, 2 <i>; yields {i32}:result = 1</i> + <result> = ashr i8 4, 3 <i>; yields {i8}:result = 0</i> + <result> = ashr i8 -2, 1 <i>; yields {i8}:result = -1</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_and">'<tt>and</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = and <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>and</tt>' instruction returns the bitwise logical and of +its two operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>and</tt>' instruction must be <a + href="#t_integer">integer</a> values. Both arguments must have +identical types.</p> +<h5>Semantics:</h5> +<p>The truth table used for the '<tt>and</tt>' instruction is:</p> +<p> </p> +<div style="align: center"> +<table border="1" cellspacing="0" cellpadding="4"> + <tbody> + <tr> + <td>In0</td> + <td>In1</td> + <td>Out</td> + </tr> + <tr> + <td>0</td> + <td>0</td> + <td>0</td> + </tr> + <tr> + <td>0</td> + <td>1</td> + <td>0</td> + </tr> + <tr> + <td>1</td> + <td>0</td> + <td>0</td> + </tr> + <tr> + <td>1</td> + <td>1</td> + <td>1</td> + </tr> + </tbody> +</table> +</div> +<h5>Example:</h5> +<pre> <result> = and i32 4, %var <i>; yields {i32}:result = 4 & %var</i> + <result> = and i32 15, 40 <i>; yields {i32}:result = 8</i> + <result> = and i32 4, 8 <i>; yields {i32}:result = 0</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_or">'<tt>or</tt>' Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = or <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>or</tt>' instruction returns the bitwise logical inclusive +or of its two operands.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>or</tt>' instruction must be <a + href="#t_integer">integer</a> values. Both arguments must have +identical types.</p> +<h5>Semantics:</h5> +<p>The truth table used for the '<tt>or</tt>' instruction is:</p> +<p> </p> +<div style="align: center"> +<table border="1" cellspacing="0" cellpadding="4"> + <tbody> + <tr> + <td>In0</td> + <td>In1</td> + <td>Out</td> + </tr> + <tr> + <td>0</td> + <td>0</td> + <td>0</td> + </tr> + <tr> + <td>0</td> + <td>1</td> + <td>1</td> + </tr> + <tr> + <td>1</td> + <td>0</td> + <td>1</td> + </tr> + <tr> + <td>1</td> + <td>1</td> + <td>1</td> + </tr> + </tbody> +</table> +</div> +<h5>Example:</h5> +<pre> <result> = or i32 4, %var <i>; yields {i32}:result = 4 | %var</i> + <result> = or i32 15, 40 <i>; yields {i32}:result = 47</i> + <result> = or i32 4, 8 <i>; yields {i32}:result = 12</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_xor">'<tt>xor</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = xor <ty> <var1>, <var2> <i>; yields {ty}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>xor</tt>' instruction returns the bitwise logical exclusive +or of its two operands. The <tt>xor</tt> is used to implement the +"one's complement" operation, which is the "~" operator in C.</p> +<h5>Arguments:</h5> +<p>The two arguments to the '<tt>xor</tt>' instruction must be <a + href="#t_integer">integer</a> values. Both arguments must have +identical types.</p> +<h5>Semantics:</h5> +<p>The truth table used for the '<tt>xor</tt>' instruction is:</p> +<p> </p> +<div style="align: center"> +<table border="1" cellspacing="0" cellpadding="4"> + <tbody> + <tr> + <td>In0</td> + <td>In1</td> + <td>Out</td> + </tr> + <tr> + <td>0</td> + <td>0</td> + <td>0</td> + </tr> + <tr> + <td>0</td> + <td>1</td> + <td>1</td> + </tr> + <tr> + <td>1</td> + <td>0</td> + <td>1</td> + </tr> + <tr> + <td>1</td> + <td>1</td> + <td>0</td> + </tr> + </tbody> +</table> +</div> +<p> </p> +<h5>Example:</h5> +<pre> <result> = xor i32 4, %var <i>; yields {i32}:result = 4 ^ %var</i> + <result> = xor i32 15, 40 <i>; yields {i32}:result = 39</i> + <result> = xor i32 4, 8 <i>; yields {i32}:result = 12</i> + <result> = xor i32 %V, -1 <i>; yields {i32}:result = ~%V</i> +</pre> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="vectorops">Vector Operations</a> +</div> + +<div class="doc_text"> + +<p>LLVM supports several instructions to represent vector operations in a +target-independent manner. These instructions cover the element-access and +vector-specific operations needed to process vectors effectively. While LLVM +does directly support these vector operations, many sophisticated algorithms +will want to use target-specific intrinsics to take full advantage of a specific +target.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_extractelement">'<tt>extractelement</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = extractelement <n x <ty>> <val>, i32 <idx> <i>; yields <ty></i> +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>extractelement</tt>' instruction extracts a single scalar +element from a vector at a specified index. +</p> + + +<h5>Arguments:</h5> + +<p> +The first operand of an '<tt>extractelement</tt>' instruction is a +value of <a href="#t_vector">vector</a> type. The second operand is +an index indicating the position from which to extract the element. +The index may be a variable.</p> + +<h5>Semantics:</h5> + +<p> +The result is a scalar of the same type as the element type of +<tt>val</tt>. Its value is the value at position <tt>idx</tt> of +<tt>val</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the +results are undefined. +</p> + +<h5>Example:</h5> + +<pre> + %result = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i> +</pre> +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_insertelement">'<tt>insertelement</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx> <i>; yields <n x <ty>></i> +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>insertelement</tt>' instruction inserts a scalar +element into a vector at a specified index. +</p> + + +<h5>Arguments:</h5> + +<p> +The first operand of an '<tt>insertelement</tt>' instruction is a +value of <a href="#t_vector">vector</a> type. The second operand is a +scalar value whose type must equal the element type of the first +operand. The third operand is an index indicating the position at +which to insert the value. The index may be a variable.</p> + +<h5>Semantics:</h5> + +<p> +The result is a vector of the same type as <tt>val</tt>. Its +element values are those of <tt>val</tt> except at position +<tt>idx</tt>, where it gets the value <tt>elt</tt>. If <tt>idx</tt> +exceeds the length of <tt>val</tt>, the results are undefined. +</p> + +<h5>Example:</h5> + +<pre> + %result = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_shufflevector">'<tt>shufflevector</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> <i>; yields <n x <ty>></i> +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>shufflevector</tt>' instruction constructs a permutation of elements +from two input vectors, returning a vector of the same type. +</p> + +<h5>Arguments:</h5> + +<p> +The first two operands of a '<tt>shufflevector</tt>' instruction are vectors +with types that match each other and types that match the result of the +instruction. The third argument is a shuffle mask, which has the same number +of elements as the other vector type, but whose element type is always 'i32'. +</p> + +<p> +The shuffle mask operand is required to be a constant vector with either +constant integer or undef values. +</p> + +<h5>Semantics:</h5> + +<p> +The elements of the two input vectors are numbered from left to right across +both of the vectors. The shuffle mask operand specifies, for each element of +the result vector, which element of the two input registers the result element +gets. The element selector may be undef (meaning "don't care") and the second +operand may be undef if performing a shuffle from only one vector. +</p> + +<h5>Example:</h5> + +<pre> + %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, + <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle. +</pre> +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="memoryops">Memory Access and Addressing Operations</a> +</div> + +<div class="doc_text"> + +<p>A key design point of an SSA-based representation is how it +represents memory. In LLVM, no memory locations are in SSA form, which +makes things very simple. This section describes how to read, write, +allocate, and free memory in LLVM.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_malloc">'<tt>malloc</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = malloc <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i> +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>malloc</tt>' instruction allocates memory from the system +heap and returns a pointer to it.</p> + +<h5>Arguments:</h5> + +<p>The '<tt>malloc</tt>' instruction allocates +<tt>sizeof(<type>)*NumElements</tt> +bytes of memory from the operating system and returns a pointer of the +appropriate type to the program. If "NumElements" is specified, it is the +number of elements allocated. If an alignment is specified, the value result +of the allocation is guaranteed to be aligned to at least that boundary. If +not specified, or if zero, the target can choose to align the allocation on any +convenient boundary.</p> + +<p>'<tt>type</tt>' must be a sized type.</p> + +<h5>Semantics:</h5> + +<p>Memory is allocated using the system "<tt>malloc</tt>" function, and +a pointer is returned.</p> + +<h5>Example:</h5> + +<pre> + %array = malloc [4 x i8 ] <i>; yields {[%4 x i8]*}:array</i> + + %size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i> + %array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i> + %array2 = malloc [12 x i8], i32 %size <i>; yields {[12 x i8]*}:array2</i> + %array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i> + %array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_free">'<tt>free</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + free <type> <value> <i>; yields {void}</i> +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>free</tt>' instruction returns memory back to the unused +memory heap to be reallocated in the future.</p> + +<h5>Arguments:</h5> + +<p>'<tt>value</tt>' shall be a pointer value that points to a value +that was allocated with the '<tt><a href="#i_malloc">malloc</a></tt>' +instruction.</p> + +<h5>Semantics:</h5> + +<p>Access to the memory pointed to by the pointer is no longer defined +after this instruction executes.</p> + +<h5>Example:</h5> + +<pre> + %array = <a href="#i_malloc">malloc</a> [4 x i8] <i>; yields {[4 x i8]*}:array</i> + free [4 x i8]* %array +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_alloca">'<tt>alloca</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i> +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>alloca</tt>' instruction allocates memory on the stack frame of the +currently executing function, to be automatically released when this function +returns to its caller.</p> + +<h5>Arguments:</h5> + +<p>The '<tt>alloca</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt> +bytes of memory on the runtime stack, returning a pointer of the +appropriate type to the program. If "NumElements" is specified, it is the +number of elements allocated. If an alignment is specified, the value result +of the allocation is guaranteed to be aligned to at least that boundary. If +not specified, or if zero, the target can choose to align the allocation on any +convenient boundary.</p> + +<p>'<tt>type</tt>' may be any sized type.</p> + +<h5>Semantics:</h5> + +<p>Memory is allocated; a pointer is returned. '<tt>alloca</tt>'d +memory is automatically released when the function returns. The '<tt>alloca</tt>' +instruction is commonly used to represent automatic variables that must +have an address available. When the function returns (either with the <tt><a + href="#i_ret">ret</a></tt> or <tt><a href="#i_unwind">unwind</a></tt> +instructions), the memory is reclaimed.</p> + +<h5>Example:</h5> + +<pre> + %ptr = alloca i32 <i>; yields {i32*}:ptr</i> + %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i> + %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i> + %ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_load">'<tt>load</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = load <ty>* <pointer>[, align <alignment>]<br> <result> = volatile load <ty>* <pointer>[, align <alignment>]<br></pre> +<h5>Overview:</h5> +<p>The '<tt>load</tt>' instruction is used to read from memory.</p> +<h5>Arguments:</h5> +<p>The argument to the '<tt>load</tt>' instruction specifies the memory +address from which to load. The pointer must point to a <a + href="#t_firstclass">first class</a> type. If the <tt>load</tt> is +marked as <tt>volatile</tt>, then the optimizer is not allowed to modify +the number or order of execution of this <tt>load</tt> with other +volatile <tt>load</tt> and <tt><a href="#i_store">store</a></tt> +instructions. </p> +<h5>Semantics:</h5> +<p>The location of memory pointed to is loaded.</p> +<h5>Examples:</h5> +<pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i> + <a + href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i> + %val = load i32* %ptr <i>; yields {i32}:val = i32 3</i> +</pre> +</div> +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_store">'<tt>store</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> store <ty> <value>, <ty>* <pointer>[, align <alignment>] <i>; yields {void}</i> + volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>] <i>; yields {void}</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>store</tt>' instruction is used to write to memory.</p> +<h5>Arguments:</h5> +<p>There are two arguments to the '<tt>store</tt>' instruction: a value +to store and an address at which to store it. The type of the '<tt><pointer></tt>' +operand must be a pointer to the type of the '<tt><value></tt>' +operand. If the <tt>store</tt> is marked as <tt>volatile</tt>, then the +optimizer is not allowed to modify the number or order of execution of +this <tt>store</tt> with other volatile <tt>load</tt> and <tt><a + href="#i_store">store</a></tt> instructions.</p> +<h5>Semantics:</h5> +<p>The contents of memory are updated to contain '<tt><value></tt>' +at the location specified by the '<tt><pointer></tt>' operand.</p> +<h5>Example:</h5> +<pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i> + <a + href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i> + %val = load i32* %ptr <i>; yields {i32}:val = i32 3</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_getelementptr">'<tt>getelementptr</tt>' Instruction</a> +</div> + +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> + <result> = getelementptr <ty>* <ptrval>{, <ty> <idx>}* +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>getelementptr</tt>' instruction is used to get the address of a +subelement of an aggregate data structure.</p> + +<h5>Arguments:</h5> + +<p>This instruction takes a list of integer operands that indicate what +elements of the aggregate object to index to. The actual types of the arguments +provided depend on the type of the first pointer argument. The +'<tt>getelementptr</tt>' instruction is used to index down through the type +levels of a structure or to a specific index in an array. When indexing into a +structure, only <tt>i32</tt> integer constants are allowed. When indexing +into an array or pointer, only integers of 32 or 64 bits are allowed, and will +be sign extended to 64-bit values.</p> + +<p>For example, let's consider a C code fragment and how it gets +compiled to LLVM:</p> + +<div class="doc_code"> +<pre> +struct RT { + char A; + int B[10][20]; + char C; +}; +struct ST { + int X; + double Y; + struct RT Z; +}; + +int *foo(struct ST *s) { + 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> +%RT = type { i8 , [10 x [20 x i32]], i8 } +%ST = type { i32, double, %RT } + +define i32* %foo(%ST* %s) { +entry: + %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13 + ret i32* %reg +} +</pre> +</div> + +<h5>Semantics:</h5> + +<p>The index types specified for the '<tt>getelementptr</tt>' instruction depend +on the pointer type that is being indexed into. <a href="#t_pointer">Pointer</a> +and <a href="#t_array">array</a> types can use a 32-bit or 64-bit +<a href="#t_integer">integer</a> type but the value will always be sign extended +to 64-bits. <a href="#t_struct">Structure</a> types require <tt>i32</tt> +<b>constants</b>.</p> + +<p>In the example above, the first index is indexing into the '<tt>%ST*</tt>' +type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT +}</tt>' type, a structure. The second index indexes into the third element of +the structure, yielding a '<tt>%RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]], +i8 }</tt>' type, another structure. The third index indexes into the second +element of the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an +array. The two dimensions of the array are subscripted into, yielding an +'<tt>i32</tt>' type. The '<tt>getelementptr</tt>' instruction returns a pointer +to this element, thus computing a value of '<tt>i32*</tt>' type.</p> + +<p>Note that it is perfectly legal to index partially through a +structure, returning a pointer to an inner element. Because of this, +the LLVM code for the given testcase is equivalent to:</p> + +<pre> + define i32* %foo(%ST* %s) { + %t1 = getelementptr %ST* %s, i32 1 <i>; yields %ST*:%t1</i> + %t2 = getelementptr %ST* %t1, i32 0, i32 2 <i>; yields %RT*:%t2</i> + %t3 = getelementptr %RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i> + %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i> + %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i> + ret i32* %t5 + } +</pre> + +<p>Note that it is undefined to access an array out of bounds: array and +pointer indexes must always be within the defined bounds of the array type. +The one exception for this rules is zero length arrays. These arrays are +defined to be accessible as variable length arrays, which requires access +beyond the zero'th element.</p> + +<p>The getelementptr instruction is often confusing. For some more insight +into how it works, see <a href="GetElementPtr.html">the getelementptr +FAQ</a>.</p> + +<h5>Example:</h5> + +<pre> + <i>; yields [12 x i8]*:aptr</i> + %aptr = getelementptr {i32, [12 x i8]}* %sptr, i64 0, i32 1 +</pre> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="convertops">Conversion Operations</a> +</div> +<div class="doc_text"> +<p>The instructions in this category are the conversion instructions (casting) +which all take a single operand and a type. They perform various bit conversions +on the operand.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_trunc">'<tt>trunc .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = trunc <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p> +The '<tt>trunc</tt>' instruction truncates its operand to the type <tt>ty2</tt>. +</p> + +<h5>Arguments:</h5> +<p> +The '<tt>trunc</tt>' instruction takes a <tt>value</tt> to trunc, which must +be an <a href="#t_integer">integer</a> type, and a type that specifies the size +and type of the result, which must be an <a href="#t_integer">integer</a> +type. The bit size of <tt>value</tt> must be larger than the bit size of +<tt>ty2</tt>. Equal sized types are not allowed.</p> + +<h5>Semantics:</h5> +<p> +The '<tt>trunc</tt>' instruction truncates the high order bits in <tt>value</tt> +and converts the remaining bits to <tt>ty2</tt>. Since the source size must be +larger than the destination size, <tt>trunc</tt> cannot be a <i>no-op cast</i>. +It will always truncate bits.</p> + +<h5>Example:</h5> +<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> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_zext">'<tt>zext .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = zext <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<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 +<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>ty2</tt>.</p> + +<h5>Semantics:</h5> +<p>The <tt>zext</tt> fills the high order bits of the <tt>value</tt> with zero +bits until it reaches the size of the destination type, <tt>ty2</tt>.</p> + +<p>When zero extending from i1, the result will always be either 0 or 1.</p> + +<h5>Example:</h5> +<pre> + %X = zext i32 257 to i64 <i>; yields i64:257</i> + %Y = zext i1 true to i32 <i>; yields i32:1</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_sext">'<tt>sext .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = sext <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</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 +<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>ty2</tt>.</p> + +<h5>Semantics:</h5> +<p> +The '<tt>sext</tt>' instruction performs a sign extension by copying the sign +bit (highest order bit) of the <tt>value</tt> until it reaches the bit size of +the type <tt>ty2</tt>.</p> + +<p>When sign extending from i1, the extension always results in -1 or 0.</p> + +<h5>Example:</h5> +<pre> + %X = sext i8 -1 to i16 <i>; yields i16 :65535</i> + %Y = sext i1 true to i32 <i>; yields i32:-1</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = fptrunc <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>fptrunc</tt>' instruction truncates <tt>value</tt> to type +<tt>ty2</tt>.</p> + + +<h5>Arguments:</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 +<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. If the value cannot fit within +the destination type, <tt>ty2</tt>, then the results are undefined.</p> + +<h5>Example:</h5> +<pre> + %X = fptrunc double 123.0 to float <i>; yields float:123.0</i> + %Y = fptrunc double 1.0E+300 to float <i>; yields undefined</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_fpext">'<tt>fpext .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = fpext <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>fpext</tt>' extends a floating point <tt>value</tt> to a larger +floating point value.</p> + +<h5>Arguments:</h5> +<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> + +<h5>Semantics:</h5> +<p>The '<tt>fpext</tt>' instruction extends the <tt>value</tt> from a smaller +<a href="#t_floating">floating point</a> type to a larger +<a href="#t_floating">floating point</a> type. The <tt>fpext</tt> cannot be +used to make a <i>no-op cast</i> because it always changes bits. Use +<tt>bitcast</tt> to make a <i>no-op cast</i> for a floating point cast.</p> + +<h5>Example:</h5> +<pre> + %X = fpext float 3.1415 to double <i>; yields double:3.1415</i> + %Y = fpext float 1.0 to float <i>; yields float:1.0 (no-op)</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = fp2uint <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>fp2uint</tt>' converts a floating point <tt>value</tt> to its +unsigned integer equivalent of type <tt>ty2</tt>. +</p> + +<h5>Arguments:</h5> +<p>The '<tt>fp2uint</tt>' instruction takes a value to cast, which must be a +<a href="#t_floating">floating point</a> value, and a type to cast it to, which +must be an <a href="#t_integer">integer</a> type.</p> + +<h5>Semantics:</h5> +<p> The '<tt>fp2uint</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> + +<p>When converting to i1, the conversion is done as a comparison against +zero. If the <tt>value</tt> was zero, the i1 result will be <tt>false</tt>. +If the <tt>value</tt> was non-zero, the i1 result will be <tt>true</tt>.</p> + +<h5>Example:</h5> +<pre> + %X = fp2uint double 123.0 to i32 <i>; yields i32:123</i> + %Y = fp2uint float 1.0E+300 to i1 <i>; yields i1:true</i> + %X = fp2uint float 1.04E+17 to i8 <i>; yields undefined:1</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = fptosi <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>fptosi</tt>' instruction converts +<a href="#t_floating">floating point</a> <tt>value</tt> to type <tt>ty2</tt>. +</p> + + +<h5>Arguments:</h5> +<p> The '<tt>fptosi</tt>' instruction takes a value to cast, which must be a +<a href="#t_floating">floating point</a> value, and a type to cast it to, which +must also be an <a href="#t_integer">integer</a> type.</p> + +<h5>Semantics:</h5> +<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> + +<p>When converting to i1, the conversion is done as a comparison against +zero. If the <tt>value</tt> was zero, the i1 result will be <tt>false</tt>. +If the <tt>value</tt> was non-zero, the i1 result will be <tt>true</tt>.</p> + +<h5>Example:</h5> +<pre> + %X = fptosi double -123.0 to i32 <i>; yields i32:-123</i> + %Y = fptosi float 1.0E-247 to i1 <i>; yields i1:true</i> + %X = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = uitofp <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>uitofp</tt>' instruction regards <tt>value</tt> as an unsigned +integer and converts that value to the <tt>ty2</tt> type.</p> + + +<h5>Arguments:</h5> +<p>The '<tt>uitofp</tt>' instruction takes a value to cast, which must be an +<a href="#t_integer">integer</a> value, and a type to cast it to, which must +be a <a href="#t_floating">floating point</a> type.</p> + +<h5>Semantics:</h5> +<p>The '<tt>uitofp</tt>' instruction interprets its operand as an unsigned +integer quantity and converts it to the corresponding floating point value. If +the value cannot fit in the floating point value, the results are undefined.</p> + + +<h5>Example:</h5> +<pre> + %X = uitofp i32 257 to float <i>; yields float:257.0</i> + %Y = uitofp i8 -1 to double <i>; yields double:255.0</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = sitofp <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>sitofp</tt>' instruction regards <tt>value</tt> as a signed +integer and converts that value to the <tt>ty2</tt> type.</p> + +<h5>Arguments:</h5> +<p>The '<tt>sitofp</tt>' instruction takes a value to cast, which must be an +<a href="#t_integer">integer</a> value, and a type to cast it to, which must be +a <a href="#t_floating">floating point</a> type.</p> + +<h5>Semantics:</h5> +<p>The '<tt>sitofp</tt>' instruction interprets its operand as a signed +integer quantity and converts it to the corresponding floating point value. If +the value cannot fit in the floating point value, the results are undefined.</p> + +<h5>Example:</h5> +<pre> + %X = sitofp i32 257 to float <i>; yields float:257.0</i> + %Y = sitofp i8 -1 to double <i>; yields double:-1.0</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = ptrtoint <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>ptrtoint</tt>' instruction converts the pointer <tt>value</tt> to +the integer type <tt>ty2</tt>.</p> + +<h5>Arguments:</h5> +<p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which +must be a <a href="#t_pointer">pointer</a> value, and a type to cast it to +<tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> type. + +<h5>Semantics:</h5> +<p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type +<tt>ty2</tt> by interpreting the pointer value as an integer and either +truncating or zero extending that value to the size of the integer type. If +<tt>value</tt> is smaller than <tt>ty2</tt> then a zero extension is done. If +<tt>value</tt> is larger than <tt>ty2</tt> then a truncation is done. If they +are the same size, then nothing is done (<i>no-op cast</i>) other than a type +change.</p> + +<h5>Example:</h5> +<pre> + %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i> + %Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = inttoptr <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>inttoptr</tt>' instruction converts an integer <tt>value</tt> to +a pointer type, <tt>ty2</tt>.</p> + +<h5>Arguments:</h5> +<p>The '<tt>inttoptr</tt>' instruction takes an <a href="#t_integer">integer</a> +value to cast, and a type to cast it to, which must be a +<a href="#t_pointer">pointer</a> type. + +<h5>Semantics:</h5> +<p>The '<tt>inttoptr</tt>' instruction converts <tt>value</tt> to type +<tt>ty2</tt> by applying either a zero extension or a truncation depending on +the size of the integer <tt>value</tt>. If <tt>value</tt> is larger than the +size of a pointer then a truncation is done. If <tt>value</tt> is smaller than +the size of a pointer then a zero extension is done. If they are the same size, +nothing is done (<i>no-op cast</i>).</p> + +<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> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a> +</div> +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = bitcast <ty> <value> to <ty2> <i>; yields ty2</i> +</pre> + +<h5>Overview:</h5> +<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type +<tt>ty2</tt> without changing any bits.</p> + +<h5>Arguments:</h5> +<p>The '<tt>bitcast</tt>' instruction takes a value to cast, which must be +a first class value, and a type to cast it to, which must also be a <a + href="#t_firstclass">first class</a> type. The bit sizes of <tt>value</tt> +and the destination type, <tt>ty2</tt>, must be identical. If the source +type is a pointer, the destination type must also be a pointer.</p> + +<h5>Semantics:</h5> +<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type +<tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with +this conversion. The conversion is done as if the <tt>value</tt> had been +stored to memory and read back as type <tt>ty2</tt>. Pointer types may only be +converted to other pointer types with this instruction. To convert pointers to +other types, use the <a href="#i_inttoptr">inttoptr</a> or +<a href="#i_ptrtoint">ptrtoint</a> instructions first.</p> + +<h5>Example:</h5> +<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 <2xint> %V to i64; <i>; yields i64: %V</i> +</pre> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> <a name="otherops">Other Operations</a> </div> +<div class="doc_text"> +<p>The instructions in this category are the "miscellaneous" +instructions, which defy better classification.</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="i_icmp">'<tt>icmp</tt>' Instruction</a> +</div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = icmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>icmp</tt>' instruction returns a boolean value based on comparison +of its two integer operands.</p> +<h5>Arguments:</h5> +<p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is +the condition code indicating the kind of comparison to perform. It is not +a value, just a keyword. The possible condition code are: +<ol> + <li><tt>eq</tt>: equal</li> + <li><tt>ne</tt>: not equal </li> + <li><tt>ugt</tt>: unsigned greater than</li> + <li><tt>uge</tt>: unsigned greater or equal</li> + <li><tt>ult</tt>: unsigned less than</li> + <li><tt>ule</tt>: unsigned less or equal</li> + <li><tt>sgt</tt>: signed greater than</li> + <li><tt>sge</tt>: signed greater or equal</li> + <li><tt>slt</tt>: signed less than</li> + <li><tt>sle</tt>: signed less or equal</li> +</ol> +<p>The remaining two arguments must be <a href="#t_integer">integer</a> or +<a href="#t_pointer">pointer</a> typed. They must also be identical types.</p> +<h5>Semantics:</h5> +<p>The '<tt>icmp</tt>' compares <tt>var1</tt> and <tt>var2</tt> according to +the condition code given as <tt>cond</tt>. The comparison performed always +yields a <a href="#t_primitive">i1</a> result, as follows: +<ol> + <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, + <tt>false</tt> otherwise. No sign interpretation is necessary or performed. + <li><tt>ugt</tt>: interprets the operands as unsigned values and yields + <tt>true</tt> if <tt>var1</tt> is greater than <tt>var2</tt>.</li> + <li><tt>uge</tt>: interprets the operands as unsigned values and yields + <tt>true</tt> if <tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li> + <li><tt>ult</tt>: interprets the operands as unsigned values and yields + <tt>true</tt> if <tt>var1</tt> is less than <tt>var2</tt>.</li> + <li><tt>ule</tt>: interprets the operands as unsigned values and yields + <tt>true</tt> if <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li> + <li><tt>sgt</tt>: interprets the operands as signed values and yields + <tt>true</tt> if <tt>var1</tt> is greater than <tt>var2</tt>.</li> + <li><tt>sge</tt>: interprets the operands as signed values and yields + <tt>true</tt> if <tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li> + <li><tt>slt</tt>: interprets the operands as signed values and yields + <tt>true</tt> if <tt>var1</tt> is less than <tt>var2</tt>.</li> + <li><tt>sle</tt>: interprets the operands as signed values and yields + <tt>true</tt> if <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li> +</ol> +<p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer +values are compared as if they were integers.</p> + +<h5>Example:</h5> +<pre> <result> = icmp eq i32 4, 5 <i>; yields: result=false</i> + <result> = icmp ne float* %X, %X <i>; yields: result=false</i> + <result> = icmp ult i16 4, 5 <i>; yields: result=true</i> + <result> = icmp sgt i16 4, 5 <i>; yields: result=false</i> + <result> = icmp ule i16 -4, 5 <i>; yields: result=false</i> + <result> = icmp sge i16 4, 5 <i>; yields: result=false</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"><a name="i_fcmp">'<tt>fcmp</tt>' Instruction</a> +</div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = fcmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result</i> +</pre> +<h5>Overview:</h5> +<p>The '<tt>fcmp</tt>' instruction returns a boolean value based on comparison +of its floating point operands.</p> +<h5>Arguments:</h5> +<p>The '<tt>fcmp</tt>' instruction takes three operands. The first operand is +the condition code indicating the kind of comparison to perform. It is not +a value, just a keyword. The possible condition code are: +<ol> + <li><tt>false</tt>: no comparison, always returns false</li> + <li><tt>oeq</tt>: ordered and equal</li> + <li><tt>ogt</tt>: ordered and greater than </li> + <li><tt>oge</tt>: ordered and greater than or equal</li> + <li><tt>olt</tt>: ordered and less than </li> + <li><tt>ole</tt>: ordered and less than or equal</li> + <li><tt>one</tt>: ordered and not equal</li> + <li><tt>ord</tt>: ordered (no nans)</li> + <li><tt>ueq</tt>: unordered or equal</li> + <li><tt>ugt</tt>: unordered or greater than </li> + <li><tt>uge</tt>: unordered or greater than or equal</li> + <li><tt>ult</tt>: unordered or less than </li> + <li><tt>ule</tt>: unordered or less than or equal</li> + <li><tt>une</tt>: unordered or not equal</li> + <li><tt>uno</tt>: unordered (either nans)</li> + <li><tt>true</tt>: no comparison, always returns true</li> +</ol> +<p><i>Ordered</i> means that neither operand is a QNAN while +<i>unordered</i> means that either operand may be a QNAN.</p> +<p>The <tt>val1</tt> and <tt>val2</tt> arguments must be +<a href="#t_floating">floating point</a> typed. They must have identical +types.</p> +<h5>Semantics:</h5> +<p>The '<tt>fcmp</tt>' compares <tt>var1</tt> and <tt>var2</tt> according to +the condition code given as <tt>cond</tt>. The comparison performed always +yields a <a href="#t_primitive">i1</a> result, as follows: +<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 + <tt>var1</tt> is equal to <tt>var2</tt>.</li> + <li><tt>ogt</tt>: yields <tt>true</tt> if both operands are not a QNAN and + <tt>var1</tt> is greather than <tt>var2</tt>.</li> + <li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and + <tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li> + <li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and + <tt>var1</tt> is less than <tt>var2</tt>.</li> + <li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and + <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li> + <li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and + <tt>var1</tt> is not equal to <tt>var2</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 + <tt>var1</tt> is equal to <tt>var2</tt>.</li> + <li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or + <tt>var1</tt> is greater than <tt>var2</tt>.</li> + <li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or + <tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li> + <li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or + <tt>var1</tt> is less than <tt>var2</tt>.</li> + <li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or + <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li> + <li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or + <tt>var1</tt> is not equal to <tt>var2</tt>.</li> + <li><tt>uno</tt>: yields <tt>true</tt> if either operand is a QNAN.</li> + <li><tt>true</tt>: always yields <tt>true</tt>, regardless of operands.</li> +</ol> + +<h5>Example:</h5> +<pre> <result> = fcmp oeq float 4.0, 5.0 <i>; yields: result=false</i> + <result> = icmp one float 4.0, 5.0 <i>; yields: result=true</i> + <result> = icmp olt float 4.0, 5.0 <i>; yields: result=true</i> + <result> = icmp ueq double 1.0, 2.0 <i>; yields: result=false</i> +</pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> <a name="i_phi">'<tt>phi</tt>' +Instruction</a> </div> +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> <result> = phi <ty> [ <val0>, <label0>], ...<br></pre> +<h5>Overview:</h5> +<p>The '<tt>phi</tt>' instruction is used to implement the φ node in +the SSA graph representing the function.</p> +<h5>Arguments:</h5> +<p>The type of the incoming values is specified with the first type +field. After this, the '<tt>phi</tt>' instruction takes a list of pairs +as arguments, with one pair for each predecessor basic block of the +current block. Only values of <a href="#t_firstclass">first class</a> +type may be used as the value arguments to the PHI node. Only labels +may be used as the label arguments.</p> +<p>There must be no non-phi instructions between the start of a basic +block and the PHI instructions: i.e. PHI instructions must be first in +a basic block.</p> +<h5>Semantics:</h5> +<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value +specified by the pair corresponding to the predecessor basic block that executed +just prior to the current block.</p> +<h5>Example:</h5> +<pre>Loop: ; Infinite loop that counts from 0 on up...<br> %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]<br> %nextindvar = add i32 %indvar, 1<br> br label %Loop<br></pre> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_select">'<tt>select</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <result> = select i1 <cond>, <ty> <val1>, <ty> <val2> <i>; yields ty</i> +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>select</tt>' instruction is used to choose one value based on a +condition, without branching. +</p> + + +<h5>Arguments:</h5> + +<p> +The '<tt>select</tt>' instruction requires a boolean value indicating the condition, and two values of the same <a href="#t_firstclass">first class</a> type. +</p> + +<h5>Semantics:</h5> + +<p> +If the boolean condition evaluates to true, the instruction returns the first +value argument; otherwise, it returns the second value argument. +</p> + +<h5>Example:</h5> + +<pre> + %X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i> +</pre> +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_call">'<tt>call</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + <result> = [tail] call [<a href="#callingconv">cconv</a>] <ty>* <fnptrval>(<param list>) +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>call</tt>' instruction represents a simple function call.</p> + +<h5>Arguments:</h5> + +<p>This instruction requires several arguments:</p> + +<ol> + <li> + <p>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> + <p>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> + <li> + <p>'<tt>ty</tt>': shall be the signature of the pointer to function value + being invoked. The argument types must match the types implied by this + signature. This type can be omitted if the function is not varargs and + if the function type does not return a pointer to a function.</p> + </li> + <li> + <p>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to + be invoked. In most cases, this is a direct function invocation, but + indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer + to function value.</p> + </li> + <li> + <p>'<tt>function args</tt>': argument list whose types match the + function signature argument types. All arguments must be of + <a href="#t_firstclass">first class</a> type. If the function signature + indicates the function accepts a variable number of arguments, the extra + arguments can be specified.</p> + </li> +</ol> + +<h5>Semantics:</h5> + +<p>The '<tt>call</tt>' instruction is used to cause control flow to +transfer to a specified function, with its incoming arguments bound to +the specified values. Upon a '<tt><a href="#i_ret">ret</a></tt>' +instruction in the called function, control flow continues with the +instruction after the function call, and the return value of the +function is bound to the result argument. This is a simpler case of +the <a href="#i_invoke">invoke</a> instruction.</p> + +<h5>Example:</h5> + +<pre> + %retval = call i32 %test(i32 %argc) + call i32(i8 *, ...) *%printf(i8 * %msg, i32 12, i8 42); + %X = tail call i32 %foo() + %Y = tail call <a href="#callingconv">fastcc</a> i32 %foo() +</pre> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="i_va_arg">'<tt>va_arg</tt>' Instruction</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + <resultval> = va_arg <va_list*> <arglist>, <argty> +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>va_arg</tt>' instruction is used to access arguments passed through +the "variable argument" area of a function call. It is used to implement the +<tt>va_arg</tt> macro in C.</p> + +<h5>Arguments:</h5> + +<p>This instruction takes a <tt>va_list*</tt> value and the type of +the argument. It returns a value of the specified argument type and +increments the <tt>va_list</tt> to point to the next argument. The +actual type of <tt>va_list</tt> is target specific.</p> + +<h5>Semantics:</h5> + +<p>The '<tt>va_arg</tt>' instruction loads an argument of the specified +type from the specified <tt>va_list</tt> and causes the +<tt>va_list</tt> to point to the next argument. For more information, +see the variable argument handling <a href="#int_varargs">Intrinsic +Functions</a>.</p> + +<p>It is legal for this instruction to be called in a function which does not +take a variable number of arguments, for example, the <tt>vfprintf</tt> +function.</p> + +<p><tt>va_arg</tt> is an LLVM instruction instead of an <a +href="#intrinsics">intrinsic function</a> because it takes a type as an +argument.</p> + +<h5>Example:</h5> + +<p>See the <a href="#int_varargs">variable argument processing</a> section.</p> + +</div> + +<!-- *********************************************************************** --> +<div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div> +<!-- *********************************************************************** --> + +<div class="doc_text"> + +<p>LLVM supports the notion of an "intrinsic function". These functions have +well known names and semantics and are required to follow certain restrictions. +Overall, these intrinsics represent an extension mechanism for the LLVM +language that does not require changing all of the transformations in LLVM when +adding to the language (or the bitcode reader/writer, the parser, etc...).</p> + +<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This +prefix is reserved in LLVM for intrinsic names; thus, function names may not +begin with this prefix. Intrinsic functions must always be external functions: +you cannot define the body of intrinsic functions. Intrinsic functions may +only be used in call or invoke instructions: it is illegal to take the address +of an intrinsic function. Additionally, because intrinsic functions are part +of the LLVM language, it is required if any are added that they be documented +here.</p> + +<p>Some intrinsic functions can be overloaded, i.e., the intrinsic represents +a family of functions that perform the same operation but on different data +types. This is most frequent with the integer types. Since LLVM can represent +over 8 million different integer types, there is a way to declare an intrinsic +that can be overloaded based on its arguments. Such an intrinsic will have the +names of its argument types encoded into its function name, each +preceded by a period. For example, the <tt>llvm.ctpop</tt> function can take an +integer of any width. This leads to a family of functions such as +<tt>i32 @llvm.ctpop.i8(i8 %val)</tt> and <tt>i32 @llvm.ctpop.i29(i29 %val)</tt>. +</p> + + +<p>To learn how to add an intrinsic function, please see the +<a href="ExtendingLLVM.html">Extending LLVM Guide</a>. +</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_varargs">Variable Argument Handling Intrinsics</a> +</div> + +<div class="doc_text"> + +<p>Variable argument support is defined in LLVM with the <a + href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three +intrinsic functions. These functions are related to the similarly +named macros defined in the <tt><stdarg.h></tt> header file.</p> + +<p>All of these functions operate on arguments that use a +target-specific value type "<tt>va_list</tt>". The LLVM assembly +language reference manual does not define what this type is, so all +transformations should be prepared to handle these functions regardless of +the type used.</p> + +<p>This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a> +instruction and the variable argument handling intrinsic functions are +used.</p> + +<div class="doc_code"> +<pre> +define i32 @test(i32 %X, ...) { + ; Initialize variable argument processing + %ap = alloca i8* + %ap2 = bitcast i8** %ap to i8* + call void @llvm.va_start(i8* %ap2) + + ; Read a single integer argument + %tmp = va_arg i8** %ap, i32 + + ; Demonstrate usage of llvm.va_copy and llvm.va_end + %aq = alloca i8* + %aq2 = bitcast i8** %aq to i8* + call void @llvm.va_copy(i8* %aq2, i8* %ap2) + call void @llvm.va_end(i8* %aq2) + + ; Stop processing of arguments. + call void @llvm.va_end(i8* %ap2) + ret i32 %tmp +} + +declare void @llvm.va_start(i8*) +declare void @llvm.va_copy(i8*, i8*) +declare void @llvm.va_end(i8*) +</pre> +</div> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a> +</div> + + +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> declare void %llvm.va_start(i8* <arglist>)<br></pre> +<h5>Overview:</h5> +<P>The '<tt>llvm.va_start</tt>' intrinsic initializes +<tt>*<arglist></tt> for subsequent use by <tt><a +href="#i_va_arg">va_arg</a></tt>.</p> + +<h5>Arguments:</h5> + +<P>The argument is a pointer to a <tt>va_list</tt> element to initialize.</p> + +<h5>Semantics:</h5> + +<P>The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt> +macro available in C. In a target-dependent way, it initializes the +<tt>va_list</tt> element to which the argument points, so that the next call to +<tt>va_arg</tt> will produce the first variable argument passed to the function. +Unlike the C <tt>va_start</tt> macro, this intrinsic does not need to know the +last argument of the function as the compiler can figure that out.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> +<h5>Syntax:</h5> +<pre> declare void @llvm.va_end(i8* <arglist>)<br></pre> +<h5>Overview:</h5> + +<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></tt>, +which has been initialized previously with <tt><a href="#int_va_start">llvm.va_start</a></tt> +or <tt><a href="#i_va_copy">llvm.va_copy</a></tt>.</p> + +<h5>Arguments:</h5> + +<p>The argument is a pointer to a <tt>va_list</tt> to destroy.</p> + +<h5>Semantics:</h5> + +<p>The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt> +macro available in C. In a target-dependent way, it destroys the +<tt>va_list</tt> element to which the argument points. Calls to <a +href="#int_va_start"><tt>llvm.va_start</tt></a> and <a href="#int_va_copy"> +<tt>llvm.va_copy</tt></a> must be matched exactly with calls to +<tt>llvm.va_end</tt>.</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>) +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position +from the source argument list to the destination argument list.</p> + +<h5>Arguments:</h5> + +<p>The first argument is a pointer to a <tt>va_list</tt> element to initialize. +The second argument is a pointer to a <tt>va_list</tt> element to copy from.</p> + + +<h5>Semantics:</h5> + +<p>The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt> +macro available in C. In a target-dependent way, it copies the source +<tt>va_list</tt> element into the destination <tt>va_list</tt> element. This +intrinsic is necessary because the <tt><a href="#int_va_start"> +llvm.va_start</a></tt> intrinsic may be arbitrarily complex and require, for +example, memory allocation.</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_gc">Accurate Garbage Collection Intrinsics</a> +</div> + +<div class="doc_text"> + +<p> +LLVM support for <a href="GarbageCollection.html">Accurate Garbage +Collection</a> requires the implementation and generation of these intrinsics. +These intrinsics allow identification of <a href="#int_gcroot">GC roots on the +stack</a>, as well as garbage collector implementations that require <a +href="#int_gcread">read</a> and <a href="#int_gcwrite">write</a> barriers. +Front-ends for type-safe garbage collected languages should generate these +intrinsics to make use of the LLVM garbage collectors. For more details, see <a +href="GarbageCollection.html">Accurate Garbage Collection with LLVM</a>. +</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + declare void @llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata) +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to +the code generator, and allows some metadata to be associated with it.</p> + +<h5>Arguments:</h5> + +<p>The first argument specifies the address of a stack object that contains the +root pointer. The second pointer (which must be either a constant or a global +value address) contains the meta-data to be associated with the root.</p> + +<h5>Semantics:</h5> + +<p>At runtime, a call to this intrinsics stores a null pointer into the "ptrloc" +location. At compile-time, the code generator generates information to allow +the runtime to find the pointer at GC safe points. +</p> + +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + declare i8 * @llvm.gcread(i8 * %ObjPtr, i8 ** %Ptr) +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>llvm.gcread</tt>' intrinsic identifies reads of references from heap +locations, allowing garbage collector implementations that require read +barriers.</p> + +<h5>Arguments:</h5> + +<p>The second argument is the address to read from, which should be an address +allocated from the garbage collector. The first object is a pointer to the +start of the referenced object, if needed by the language runtime (otherwise +null).</p> + +<h5>Semantics:</h5> + +<p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load +instruction, but may be replaced with substantially more complex code by the +garbage collector runtime, as needed.</p> + +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> + +<pre> + declare void @llvm.gcwrite(i8 * %P1, i8 * %Obj, i8 ** %P2) +</pre> + +<h5>Overview:</h5> + +<p>The '<tt>llvm.gcwrite</tt>' intrinsic identifies writes of references to heap +locations, allowing garbage collector implementations that require write +barriers (such as generational or reference counting collectors).</p> + +<h5>Arguments:</h5> + +<p>The first argument is the reference to store, the second is the start of the +object to store it to, and the third is the address of the field of Obj to +store to. If the runtime does not require a pointer to the object, Obj may be +null.</p> + +<h5>Semantics:</h5> + +<p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store +instruction, but may be replaced with substantially more complex code by the +garbage collector runtime, as needed.</p> + +</div> + + + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_codegen">Code Generator Intrinsics</a> +</div> + +<div class="doc_text"> +<p> +These intrinsics are provided by LLVM to expose special features that may only +be implemented with code generator support. +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare i8 *@llvm.returnaddress(i32 <level>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.returnaddress</tt>' intrinsic attempts to compute a +target-specific value indicating the return address of the current function +or one of its callers. +</p> + +<h5>Arguments:</h5> + +<p> +The argument to this intrinsic indicates which function to return the address +for. Zero indicates the calling function, one indicates its caller, etc. The +argument is <b>required</b> to be a constant integer value. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer indicating +the return address of the specified call frame, or zero if it cannot be +identified. The value returned by this intrinsic is likely to be incorrect or 0 +for arguments other than zero, so it should only be used for debugging purposes. +</p> + +<p> +Note that calling this intrinsic does not prevent function inlining or other +aggressive transformations, so the value returned may not be that of the obvious +source-language caller. +</p> +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare i8 *@llvm.frameaddress(i32 <level>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.frameaddress</tt>' intrinsic attempts to return the +target-specific frame pointer value for the specified stack frame. +</p> + +<h5>Arguments:</h5> + +<p> +The argument to this intrinsic indicates which function to return the frame +pointer for. Zero indicates the calling function, one indicates its caller, +etc. The argument is <b>required</b> to be a constant integer value. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer indicating +the frame address of the specified call frame, or zero if it cannot be +identified. The value returned by this intrinsic is likely to be incorrect or 0 +for arguments other than zero, so it should only be used for debugging purposes. +</p> + +<p> +Note that calling this intrinsic does not prevent function inlining or other +aggressive transformations, so the value returned may not be that of the obvious +source-language caller. +</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare i8 *@llvm.stacksave() +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.stacksave</tt>' intrinsic is used to remember the current state of +the function stack, for use with <a href="#int_stackrestore"> +<tt>llvm.stackrestore</tt></a>. This is useful for implementing language +features like scoped automatic variable sized arrays in C99. +</p> + +<h5>Semantics:</h5> + +<p> +This intrinsic returns a opaque pointer value that can be passed to <a +href="#int_stackrestore"><tt>llvm.stackrestore</tt></a>. When an +<tt>llvm.stackrestore</tt> intrinsic is executed with a value saved from +<tt>llvm.stacksave</tt>, it effectively restores the state of the stack to the +state it was in when the <tt>llvm.stacksave</tt> intrinsic executed. In +practice, this pops any <a href="#i_alloca">alloca</a> blocks from the stack +that were allocated after the <tt>llvm.stacksave</tt> was executed. +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.stackrestore(i8 * %ptr) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.stackrestore</tt>' intrinsic is used to restore the state of +the function stack to the state it was in when the corresponding <a +href="#int_stacksave"><tt>llvm.stacksave</tt></a> intrinsic executed. This is +useful for implementing language features like scoped automatic variable sized +arrays in C99. +</p> + +<h5>Semantics:</h5> + +<p> +See the description for <a href="#int_stacksave"><tt>llvm.stacksave</tt></a>. +</p> + +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.prefetch(i8 * <address>, + i32 <rw>, i32 <locality>) +</pre> + +<h5>Overview:</h5> + + +<p> +The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to insert +a prefetch instruction if supported; otherwise, it is a noop. Prefetches have +no +effect on the behavior of the program but can change its performance +characteristics. +</p> + +<h5>Arguments:</h5> + +<p> +<tt>address</tt> is the address to be prefetched, <tt>rw</tt> is the specifier +determining if the fetch should be for a read (0) or write (1), and +<tt>locality</tt> is a temporal locality specifier ranging from (0) - no +locality, to (3) - extremely local keep in cache. The <tt>rw</tt> and +<tt>locality</tt> arguments must be constant integers. +</p> + +<h5>Semantics:</h5> + +<p> +This intrinsic does not modify the behavior of the program. In particular, +prefetches cannot trap and do not produce a value. On targets that support this +intrinsic, the prefetch can provide hints to the processor cache for better +performance. +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.pcmarker( i32 <id> ) +</pre> + +<h5>Overview:</h5> + + +<p> +The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a Program Counter +(PC) in a region of +code to simulators and other tools. The method is target specific, but it is +expected that the marker will use exported symbols to transmit the PC of the marker. +The marker makes no guarantees that it will remain with any specific instruction +after optimizations. It is possible that the presence of a marker will inhibit +optimizations. The intended use is to be inserted after optimizations to allow +correlations of simulation runs. +</p> + +<h5>Arguments:</h5> + +<p> +<tt>id</tt> is a numerical id identifying the marker. +</p> + +<h5>Semantics:</h5> + +<p> +This intrinsic does not modify the behavior of the program. Backends that do not +support this intrinisic may ignore it. +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare i64 @llvm.readcyclecounter( ) +</pre> + +<h5>Overview:</h5> + + +<p> +The '<tt>llvm.readcyclecounter</tt>' intrinsic provides access to the cycle +counter register (or similar low latency, high accuracy clocks) on those targets +that support it. On X86, it should map to RDTSC. On Alpha, it should map to RPCC. +As the backing counters overflow quickly (on the order of 9 seconds on alpha), this +should only be used for small timings. +</p> + +<h5>Semantics:</h5> + +<p> +When directly supported, reading the cycle counter should not modify any memory. +Implementations are allowed to either return a application specific value or a +system wide value. On backends without support, this is lowered to a constant 0. +</p> + +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_libc">Standard C Library Intrinsics</a> +</div> + +<div class="doc_text"> +<p> +LLVM provides intrinsics for a few important standard C library functions. +These intrinsics allow source-language front-ends to pass information about the +alignment of the pointer arguments to the code generator, providing opportunity +for more efficient code generation. +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>, + i32 <len>, i32 <align>) + declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>, + i64 <len>, i32 <align>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the source +location to the destination location. +</p> + +<p> +Note that, unlike the standard libc function, the <tt>llvm.memcpy.*</tt> +intrinsics do not return a value, and takes an extra alignment argument. +</p> + +<h5>Arguments:</h5> + +<p> +The first argument is a pointer to the destination, the second is a pointer to +the source. The third argument is an integer argument +specifying the number of bytes to copy, and the fourth argument is the alignment +of the source and destination locations. +</p> + +<p> +If the call to this intrinisic has an alignment value that is not 0 or 1, then +the caller guarantees that both the source and destination pointers are aligned +to that boundary. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the source +location to the destination location, which are not allowed to overlap. It +copies "len" bytes of memory over. If the argument is known to be aligned to +some boundary, this can be specified as the fourth argument, otherwise it should +be set to 0 or 1. +</p> +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>, + i32 <len>, i32 <align>) + declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>, + i64 <len>, i32 <align>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the source +location to the destination location. It is similar to the +'<tt>llvm.memcmp</tt>' intrinsic but allows the two memory locations to overlap. +</p> + +<p> +Note that, unlike the standard libc function, the <tt>llvm.memmove.*</tt> +intrinsics do not return a value, and takes an extra alignment argument. +</p> + +<h5>Arguments:</h5> + +<p> +The first argument is a pointer to the destination, the second is a pointer to +the source. The third argument is an integer argument +specifying the number of bytes to copy, and the fourth argument is the alignment +of the source and destination locations. +</p> + +<p> +If the call to this intrinisic has an alignment value that is not 0 or 1, then +the caller guarantees that the source and destination pointers are aligned to +that boundary. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.memmove.*</tt>' intrinsics copy a block of memory from the source +location to the destination location, which may overlap. It +copies "len" bytes of memory over. If the argument is known to be aligned to +some boundary, this can be specified as the fourth argument, otherwise it should +be set to 0 or 1. +</p> +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.memset.i32(i8 * <dest>, i8 <val>, + i32 <len>, i32 <align>) + declare void @llvm.memset.i64(i8 * <dest>, i8 <val>, + i64 <len>, i32 <align>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.memset.*</tt>' intrinsics fill a block of memory with a particular +byte value. +</p> + +<p> +Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic +does not return a value, and takes an extra alignment argument. +</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 specifying the number of bytes to fill, and the fourth argument is the +known alignment of destination location. +</p> + +<p> +If the call to this intrinisic has an alignment value that is not 0 or 1, then +the caller guarantees that the destination pointer is aligned to that boundary. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.memset.*</tt>' intrinsics fill "len" bytes of memory starting at +the +destination location. If the argument is known to be aligned to some boundary, +this can be specified as the fourth argument, otherwise it should be set to 0 or +1. +</p> +</div> + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare float @llvm.sqrt.f32(float %Val) + declare double @llvm.sqrt.f64(double %Val) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.sqrt</tt>' intrinsics return the sqrt of the specified operand, +returning the same value as the libm '<tt>sqrt</tt>' function would. Unlike +<tt>sqrt</tt> in libm, however, <tt>llvm.sqrt</tt> has undefined behavior for +negative numbers (which allows for better optimization). +</p> + +<h5>Arguments:</h5> + +<p> +The argument and return value are floating point numbers of the same type. +</p> + +<h5>Semantics:</h5> + +<p> +This function returns the sqrt of the specified operand if it is a nonnegative +floating point number. +</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare float @llvm.powi.f32(float %Val, i32 %power) + declare double @llvm.powi.f64(double %Val, i32 %power) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.powi.*</tt>' intrinsics return the first operand raised to the +specified (positive or negative) power. The order of evaluation of +multiplications is not defined. +</p> + +<h5>Arguments:</h5> + +<p> +The second argument is an integer power, and the first is a value to raise to +that power. +</p> + +<h5>Semantics:</h5> + +<p> +This function returns the first value raised to the second power with an +unspecified sequence of rounding operations.</p> +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_manip">Bit Manipulation Intrinsics</a> +</div> + +<div class="doc_text"> +<p> +LLVM provides intrinsics for a few important bit manipulation operations. +These allow efficient code generation for some algorithms. +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<p>This is an overloaded intrinsic function. You can use bswap on any integer +type that is an even number of bytes (i.e. BitWidth % 16 == 0). Note the suffix +that includes the type for the result and the operand. +<pre> + declare i16 @llvm.bswap.i16.i16(i16 <id>) + declare i32 @llvm.bswap.i32.i32(i32 <id>) + declare i64 @llvm.bswap.i64.i64(i64 <id>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.bswap</tt>' family of intrinsics is used to byte swap integer +values with an even number of bytes (positive multiple of 16 bits). These are +useful for performing operations on data that is not in the target's native +byte order. +</p> + +<h5>Semantics:</h5> + +<p> +The <tt>llvm.bswap.16.i16</tt> intrinsic returns an i16 value that has the high +and low byte of the input i16 swapped. Similarly, the <tt>llvm.bswap.i32</tt> +intrinsic returns an i32 value that has the four bytes of the input i32 +swapped, so that if the input bytes are numbered 0, 1, 2, 3 then the returned +i32 will have its bytes in 3, 2, 1, 0 order. The <tt>llvm.bswap.i48.i48</tt>, +<tt>llvm.bswap.i64.i64</tt> and other intrinsics extend this concept to +additional even-byte lengths (6 bytes, 8 bytes and more, respectively). +</p> + +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit +width. Not all targets support all bit widths however. +<pre> + declare i32 @llvm.ctpop.i8 (i8 <src>) + declare i32 @llvm.ctpop.i16(i16 <src>) + declare i32 @llvm.ctpop.i32(i32 <src>) + declare i32 @llvm.ctpop.i64(i64 <src>) + declare i32 @llvm.ctpop.i256(i256 <src>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.ctpop</tt>' family of intrinsics counts the number of bits set in a +value. +</p> + +<h5>Arguments:</h5> + +<p> +The only argument is the value to be counted. The argument may be of any +integer type. The return type must match the argument type. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.ctpop</tt>' intrinsic counts the 1's in a variable. +</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<p>This is an overloaded intrinsic. You can use <tt>llvm.ctlz</tt> on any +integer bit width. Not all targets support all bit widths however. +<pre> + declare i32 @llvm.ctlz.i8 (i8 <src>) + declare i32 @llvm.ctlz.i16(i16 <src>) + declare i32 @llvm.ctlz.i32(i32 <src>) + declare i32 @llvm.ctlz.i64(i64 <src>) + declare i32 @llvm.ctlz.i256(i256 <src>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.ctlz</tt>' family of intrinsic functions counts the number of +leading zeros in a variable. +</p> + +<h5>Arguments:</h5> + +<p> +The only argument is the value to be counted. The argument may be of any +integer type. The return type must match the argument type. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant) zeros +in a variable. If the src == 0 then the result is the size in bits of the type +of src. For example, <tt>llvm.ctlz(i32 2) = 30</tt>. +</p> +</div> + + + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<p>This is an overloaded intrinsic. You can use <tt>llvm.cttz</tt> on any +integer bit width. Not all targets support all bit widths however. +<pre> + declare i32 @llvm.cttz.i8 (i8 <src>) + declare i32 @llvm.cttz.i16(i16 <src>) + declare i32 @llvm.cttz.i32(i32 <src>) + declare i32 @llvm.cttz.i64(i64 <src>) + declare i32 @llvm.cttz.i256(i256 <src>) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.cttz</tt>' family of intrinsic functions counts the number of +trailing zeros. +</p> + +<h5>Arguments:</h5> + +<p> +The only argument is the value to be counted. The argument may be of any +integer type. The return type must match the argument type. +</p> + +<h5>Semantics:</h5> + +<p> +The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant) zeros +in a variable. If the src == 0 then the result is the size in bits of the type +of src. For example, <tt>llvm.cttz(2) = 1</tt>. +</p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_part_select">'<tt>llvm.part.select.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<p>This is an overloaded intrinsic. You can use <tt>llvm.part.select</tt> +on any integer bit width. +<pre> + declare i17 @llvm.part.select.i17.i17 (i17 %val, i32 %loBit, i32 %hiBit) + declare i29 @llvm.part.select.i29.i29 (i29 %val, i32 %loBit, i32 %hiBit) +</pre> + +<h5>Overview:</h5> +<p>The '<tt>llvm.part.select</tt>' family of intrinsic functions selects a +range of bits from an integer value and returns them in the same bit width as +the original value.</p> + +<h5>Arguments:</h5> +<p>The first argument, <tt>%val</tt> and the result may be integer types of +any bit width but they must have the same bit width. The second and third +arguments must be <tt>i32</tt> type since they specify only a bit index.</p> + +<h5>Semantics:</h5> +<p>The operation of the '<tt>llvm.part.select</tt>' intrinsic has two modes +of operation: forwards and reverse. If <tt>%loBit</tt> is greater than +<tt>%hiBits</tt> then the intrinsic operates in reverse mode. Otherwise it +operates in forward mode.</p> +<p>In forward mode, this intrinsic is the equivalent of shifting <tt>%val</tt> +right by <tt>%loBit</tt> bits and then ANDing it with a mask with +only the <tt>%hiBit - %loBit</tt> bits set, as follows:</p> +<ol> + <li>The <tt>%val</tt> is shifted right (LSHR) by the number of bits specified + by <tt>%loBits</tt>. This normalizes the value to the low order bits.</li> + <li>The <tt>%loBits</tt> value is subtracted from the <tt>%hiBits</tt> value + to determine the number of bits to retain.</li> + <li>A mask of the retained bits is created by shifting a -1 value.</li> + <li>The mask is ANDed with <tt>%val</tt> to produce the result. +</ol> +<p>In reverse mode, a similar computation is made except that the bits are +returned in the reverse order. So, for example, if <tt>X</tt> has the value +<tt>i16 0x0ACF (101011001111)</tt> and we apply +<tt>part.select(i16 X, 8, 3)</tt> to it, we get back the value +<tt>i16 0x0026 (000000100110)</tt>.</p> +</div> + +<div class="doc_subsubsection"> + <a name="int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<p>This is an overloaded intrinsic. You can use <tt>llvm.part.set</tt> +on any integer bit width. +<pre> + declare i17 @llvm.part.set.i17.i17.i9 (i17 %val, i9 %repl, i32 %lo, i32 %hi) + declare i29 @llvm.part.set.i29.i29.i9 (i29 %val, i9 %repl, i32 %lo, i32 %hi) +</pre> + +<h5>Overview:</h5> +<p>The '<tt>llvm.part.set</tt>' family of intrinsic functions replaces a range +of bits in an integer value with another integer value. It returns the integer +with the replaced bits.</p> + +<h5>Arguments:</h5> +<p>The first argument, <tt>%val</tt> and the result may be integer types of +any bit width but they must have the same bit width. <tt>%val</tt> is the value +whose bits will be replaced. The second argument, <tt>%repl</tt> may be an +integer of any bit width. The third and fourth arguments must be <tt>i32</tt> +type since they specify only a bit index.</p> + +<h5>Semantics:</h5> +<p>The operation of the '<tt>llvm.part.set</tt>' intrinsic has two modes +of operation: forwards and reverse. If <tt>%lo</tt> is greater than +<tt>%hi</tt> then the intrinsic operates in reverse mode. Otherwise it +operates in forward mode.</p> +<p>For both modes, the <tt>%repl</tt> value is prepared for use by either +truncating it down to the size of the replacement area or zero extending it +up to that size.</p> +<p>In forward mode, the bits between <tt>%lo</tt> and <tt>%hi</tt> (inclusive) +are replaced with corresponding bits from <tt>%repl</tt>. That is the 0th bit +in <tt>%repl</tt> replaces the <tt>%lo</tt>th bit in <tt>%val</tt> and etc. up +to the <tt>%hi</tt>th bit. +<p>In reverse mode, a similar computation is made except that the bits are +reversed. That is, the <tt>0</tt>th bit in <tt>%repl</tt> replaces the +<tt>%hi</tt> bit in <tt>%val</tt> and etc. down to the <tt>%lo</tt>th bit. +<h5>Examples:</h5> +<pre> + llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F + llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F + llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F + llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7 + llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07 +</pre> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_debugger">Debugger Intrinsics</a> +</div> + +<div class="doc_text"> +<p> +The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix), +are described in the <a +href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source Level +Debugging</a> document. +</p> +</div> + + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_eh">Exception Handling Intrinsics</a> +</div> + +<div class="doc_text"> +<p> The LLVM exception handling intrinsics (which all start with +<tt>llvm.eh.</tt> prefix), are described in the <a +href="ExceptionHandling.html#format_common_intrinsics">LLVM Exception +Handling</a> document. </p> +</div> + +<!-- ======================================================================= --> +<div class="doc_subsection"> + <a name="int_general">General Intrinsics</a> +</div> + +<div class="doc_text"> +<p> This class of intrinsics is designed to be generic and has +no specific purpose. </p> +</div> + +<!-- _______________________________________________________________________ --> +<div class="doc_subsubsection"> + <a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a> +</div> + +<div class="doc_text"> + +<h5>Syntax:</h5> +<pre> + declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> ) +</pre> + +<h5>Overview:</h5> + +<p> +The '<tt>llvm.var.annotation</tt>' intrinsic +</p> + +<h5>Arguments:</h5> + +<p> +The first argument is a pointer to a value, the second is a pointer to a +global string, the third is a pointer to a global string which is the source +file name, and the last argument is the line number. +</p> + +<h5>Semantics:</h5> + +<p> +This intrinsic allows annotation of local variables with arbitrary strings. +This can be useful for special purpose optimizations that want to look for these + annotations. These have no other defined use, they are ignored by code + generation and optimization. +</div> + + +<!-- *********************************************************************** --> +<hr> +<address> + <a href="http://jigsaw.w3.org/css-validator/check/referer"><img + src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a> + <a href="http://validator.w3.org/check/referer"><img + src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a> + + <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> + <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br> + Last modified: $Date$ +</address> +</body> +</html> |