Blame - docs/LangRef.html - fp2-dev/platform/external/llvm

blob: a57f2426059d3a19f9dc23c9e56deaa3b5ae7dc2 [file] [log] [blame]

Dan Gohman	f17a25c	2007-07-18 16:29:46 +0000	[diff] [blame^]	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
				2	"http://www.w3.org/TR/html4/strict.dtd">
				3	<html>
				4	<head>
				5	<title>LLVM Assembly Language Reference Manual</title>
				6	<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
				7	<meta name="author" content="Chris Lattner">
				8	<meta name="description"
				9	content="LLVM Assembly Language Reference Manual.">
				10	<link rel="stylesheet" href="llvm.css" type="text/css">
				11	</head>
				12
				13	<body>
				14
				15	<div class="doc_title"> LLVM Language Reference Manual </div>
				16	<ol>
				17	<li><a href="#abstract">Abstract</a></li>
				18	<li><a href="#introduction">Introduction</a></li>
				19	<li><a href="#identifiers">Identifiers</a></li>
				20	<li><a href="#highlevel">High Level Structure</a>
				21	<ol>
				22	<li><a href="#modulestructure">Module Structure</a></li>
				23	<li><a href="#linkage">Linkage Types</a></li>
				24	<li><a href="#callingconv">Calling Conventions</a></li>
				25	<li><a href="#globalvars">Global Variables</a></li>
				26	<li><a href="#functionstructure">Functions</a></li>
				27	<li><a href="#aliasstructure">Aliases</a>
				28	<li><a href="#paramattrs">Parameter Attributes</a></li>
				29	<li><a href="#moduleasm">Module-Level Inline Assembly</a></li>
				30	<li><a href="#datalayout">Data Layout</a></li>
				31	</ol>
				32	</li>
				33	<li><a href="#typesystem">Type System</a>
				34	<ol>
				35	<li><a href="#t_primitive">Primitive Types</a>
				36	<ol>
				37	<li><a href="#t_classifications">Type Classifications</a></li>
				38	</ol>
				39	</li>
				40	<li><a href="#t_derived">Derived Types</a>
				41	<ol>
				42	<li><a href="#t_array">Array Type</a></li>
				43	<li><a href="#t_function">Function Type</a></li>
				44	<li><a href="#t_pointer">Pointer Type</a></li>
				45	<li><a href="#t_struct">Structure Type</a></li>
				46	<li><a href="#t_pstruct">Packed Structure Type</a></li>
				47	<li><a href="#t_vector">Vector Type</a></li>
				48	<li><a href="#t_opaque">Opaque Type</a></li>
				49	</ol>
				50	</li>
				51	</ol>
				52	</li>
				53	<li><a href="#constants">Constants</a>
				54	<ol>
				55	<li><a href="#simpleconstants">Simple Constants</a>
				56	<li><a href="#aggregateconstants">Aggregate Constants</a>
				57	<li><a href="#globalconstants">Global Variable and Function Addresses</a>
				58	<li><a href="#undefvalues">Undefined Values</a>
				59	<li><a href="#constantexprs">Constant Expressions</a>
				60	</ol>
				61	</li>
				62	<li><a href="#othervalues">Other Values</a>
				63	<ol>
				64	<li><a href="#inlineasm">Inline Assembler Expressions</a>
				65	</ol>
				66	</li>
				67	<li><a href="#instref">Instruction Reference</a>
				68	<ol>
				69	<li><a href="#terminators">Terminator Instructions</a>
				70	<ol>
				71	<li><a href="#i_ret">'<tt>ret</tt>' Instruction</a></li>
				72	<li><a href="#i_br">'<tt>br</tt>' Instruction</a></li>
				73	<li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li>
				74	<li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li>
				75	<li><a href="#i_unwind">'<tt>unwind</tt>' Instruction</a></li>
				76	<li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li>
				77	</ol>
				78	</li>
				79	<li><a href="#binaryops">Binary Operations</a>
				80	<ol>
				81	<li><a href="#i_add">'<tt>add</tt>' Instruction</a></li>
				82	<li><a href="#i_sub">'<tt>sub</tt>' Instruction</a></li>
				83	<li><a href="#i_mul">'<tt>mul</tt>' Instruction</a></li>
				84	<li><a href="#i_udiv">'<tt>udiv</tt>' Instruction</a></li>
				85	<li><a href="#i_sdiv">'<tt>sdiv</tt>' Instruction</a></li>
				86	<li><a href="#i_fdiv">'<tt>fdiv</tt>' Instruction</a></li>
				87	<li><a href="#i_urem">'<tt>urem</tt>' Instruction</a></li>
				88	<li><a href="#i_srem">'<tt>srem</tt>' Instruction</a></li>
				89	<li><a href="#i_frem">'<tt>frem</tt>' Instruction</a></li>
				90	</ol>
				91	</li>
				92	<li><a href="#bitwiseops">Bitwise Binary Operations</a>
				93	<ol>
				94	<li><a href="#i_shl">'<tt>shl</tt>' Instruction</a></li>
				95	<li><a href="#i_lshr">'<tt>lshr</tt>' Instruction</a></li>
				96	<li><a href="#i_ashr">'<tt>ashr</tt>' Instruction</a></li>
				97	<li><a href="#i_and">'<tt>and</tt>' Instruction</a></li>
				98	<li><a href="#i_or">'<tt>or</tt>' Instruction</a></li>
				99	<li><a href="#i_xor">'<tt>xor</tt>' Instruction</a></li>
				100	</ol>
				101	</li>
				102	<li><a href="#vectorops">Vector Operations</a>
				103	<ol>
				104	<li><a href="#i_extractelement">'<tt>extractelement</tt>' Instruction</a></li>
				105	<li><a href="#i_insertelement">'<tt>insertelement</tt>' Instruction</a></li>
				106	<li><a href="#i_shufflevector">'<tt>shufflevector</tt>' Instruction</a></li>
				107	</ol>
				108	</li>
				109	<li><a href="#memoryops">Memory Access and Addressing Operations</a>
				110	<ol>
				111	<li><a href="#i_malloc">'<tt>malloc</tt>' Instruction</a></li>
				112	<li><a href="#i_free">'<tt>free</tt>' Instruction</a></li>
				113	<li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li>
				114	<li><a href="#i_load">'<tt>load</tt>' Instruction</a></li>
				115	<li><a href="#i_store">'<tt>store</tt>' Instruction</a></li>
				116	<li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li>
				117	</ol>
				118	</li>
				119	<li><a href="#convertops">Conversion Operations</a>
				120	<ol>
				121	<li><a href="#i_trunc">'<tt>trunc .. to</tt>' Instruction</a></li>
				122	<li><a href="#i_zext">'<tt>zext .. to</tt>' Instruction</a></li>
				123	<li><a href="#i_sext">'<tt>sext .. to</tt>' Instruction</a></li>
				124	<li><a href="#i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a></li>
				125	<li><a href="#i_fpext">'<tt>fpext .. to</tt>' Instruction</a></li>
				126	<li><a href="#i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a></li>
				127	<li><a href="#i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a></li>
				128	<li><a href="#i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a></li>
				129	<li><a href="#i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a></li>
				130	<li><a href="#i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a></li>
				131	<li><a href="#i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a></li>
				132	<li><a href="#i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a></li>
				133	</ol>
				134	<li><a href="#otherops">Other Operations</a>
				135	<ol>
				136	<li><a href="#i_icmp">'<tt>icmp</tt>' Instruction</a></li>
				137	<li><a href="#i_fcmp">'<tt>fcmp</tt>' Instruction</a></li>
				138	<li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li>
				139	<li><a href="#i_select">'<tt>select</tt>' Instruction</a></li>
				140	<li><a href="#i_call">'<tt>call</tt>' Instruction</a></li>
				141	<li><a href="#i_va_arg">'<tt>va_arg</tt>' Instruction</a></li>
				142	</ol>
				143	</li>
				144	</ol>
				145	</li>
				146	<li><a href="#intrinsics">Intrinsic Functions</a>
				147	<ol>
				148	<li><a href="#int_varargs">Variable Argument Handling Intrinsics</a>
				149	<ol>
				150	<li><a href="#int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a></li>
				151	<li><a href="#int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a></li>
				152	<li><a href="#int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li>
				153	</ol>
				154	</li>
				155	<li><a href="#int_gc">Accurate Garbage Collection Intrinsics</a>
				156	<ol>
				157	<li><a href="#int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a></li>
				158	<li><a href="#int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a></li>
				159	<li><a href="#int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a></li>
				160	</ol>
				161	</li>
				162	<li><a href="#int_codegen">Code Generator Intrinsics</a>
				163	<ol>
				164	<li><a href="#int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li>
				165	<li><a href="#int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li>
				166	<li><a href="#int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a></li>
				167	<li><a href="#int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a></li>
				168	<li><a href="#int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a></li>
				169	<li><a href="#int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a></li>
				170	<li><a href="#int_readcyclecounter"><tt>llvm.readcyclecounter</tt>' Intrinsic</a></li>
				171	</ol>
				172	</li>
				173	<li><a href="#int_libc">Standard C Library Intrinsics</a>
				174	<ol>
				175	<li><a href="#int_memcpy">'<tt>llvm.memcpy.*</tt>' Intrinsic</a></li>
				176	<li><a href="#int_memmove">'<tt>llvm.memmove.*</tt>' Intrinsic</a></li>
				177	<li><a href="#int_memset">'<tt>llvm.memset.*</tt>' Intrinsic</a></li>
				178	<li><a href="#int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a></li>
				179	<li><a href="#int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a></li>
				180	</ol>
				181	</li>
				182	<li><a href="#int_manip">Bit Manipulation Intrinsics</a>
				183	<ol>
				184	<li><a href="#int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a></li>
				185	<li><a href="#int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic </a></li>
				186	<li><a href="#int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic </a></li>
				187	<li><a href="#int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic </a></li>
				188	<li><a href="#int_part_select">'<tt>llvm.part.select.*</tt>' Intrinsic </a></li>
				189	<li><a href="#int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic </a></li>
				190	</ol>
				191	</li>
				192	<li><a href="#int_debugger">Debugger intrinsics</a></li>
				193	<li><a href="#int_eh">Exception Handling intrinsics</a></li>
				194	<li><a href="#int_general">General intrinsics</a></li>
				195	<ol>
				196	<li><a href="#int_var_annotation">'<tt>llvm.var.annotation</tt>'
				197	Intrinsic</a></li>
				198	</ol>
				199	</li>
				200	</ol>
				201	</li>
				202	</ol>
				203
				204	<div class="doc_author">
				205	<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a>
				206	and <a href="mailto:vadve@cs.uiuc.edu">Vikram Adve</a></p>
				207	</div>
				208
				209	<!-- *********************************************************************** -->
				210	<div class="doc_section"> <a name="abstract">Abstract </a></div>
				211	<!-- *********************************************************************** -->
				212
				213	<div class="doc_text">
				214	<p>This document is a reference manual for the LLVM assembly language.
				215	LLVM is an SSA based representation that provides type safety,
				216	low-level operations, flexibility, and the capability of representing
				217	'all' high-level languages cleanly. It is the common code
				218	representation used throughout all phases of the LLVM compilation
				219	strategy.</p>
				220	</div>
				221
				222	<!-- *********************************************************************** -->
				223	<div class="doc_section"> <a name="introduction">Introduction</a> </div>
				224	<!-- *********************************************************************** -->
				225
				226	<div class="doc_text">
				227
				228	<p>The LLVM code representation is designed to be used in three
				229	different forms: as an in-memory compiler IR, as an on-disk bitcode
				230	representation (suitable for fast loading by a Just-In-Time compiler),
				231	and as a human readable assembly language representation. This allows
				232	LLVM to provide a powerful intermediate representation for efficient
				233	compiler transformations and analysis, while providing a natural means
				234	to debug and visualize the transformations. The three different forms
				235	of LLVM are all equivalent. This document describes the human readable
				236	representation and notation.</p>
				237
				238	<p>The LLVM representation aims to be light-weight and low-level
				239	while being expressive, typed, and extensible at the same time. It
				240	aims to be a "universal IR" of sorts, by being at a low enough level
				241	that high-level ideas may be cleanly mapped to it (similar to how
				242	microprocessors are "universal IR's", allowing many source languages to
				243	be mapped to them). By providing type information, LLVM can be used as
				244	the target of optimizations: for example, through pointer analysis, it
				245	can be proven that a C automatic variable is never accessed outside of
				246	the current function... allowing it to be promoted to a simple SSA
				247	value instead of a memory location.</p>
				248
				249	</div>
				250
				251	<!-- _______________________________________________________________________ -->
				252	<div class="doc_subsubsection"> <a name="wellformed">Well-Formedness</a> </div>
				253
				254	<div class="doc_text">
				255
				256	<p>It is important to note that this document describes 'well formed'
				257	LLVM assembly language. There is a difference between what the parser
				258	accepts and what is considered 'well formed'. For example, the
				259	following instruction is syntactically okay, but not well formed:</p>
				260
				261	<div class="doc_code">
				262	<pre>
				263	%x = <a href="#i_add">add</a> i32 1, %x
				264	</pre>
				265	</div>
				266
				267	<p>...because the definition of <tt>%x</tt> does not dominate all of
				268	its uses. The LLVM infrastructure provides a verification pass that may
				269	be used to verify that an LLVM module is well formed. This pass is
				270	automatically run by the parser after parsing input assembly and by
				271	the optimizer before it outputs bitcode. The violations pointed out
				272	by the verifier pass indicate bugs in transformation passes or input to
				273	the parser.</p>
				274	</div>
				275
				276	<!-- Describe the typesetting conventions here. --> </div>
				277
				278	<!-- *********************************************************************** -->
				279	<div class="doc_section"> <a name="identifiers">Identifiers</a> </div>
				280	<!-- *********************************************************************** -->
				281
				282	<div class="doc_text">
				283
				284	<p>LLVM uses three different forms of identifiers, for different
				285	purposes:</p>
				286
				287	<ol>
				288	<li>Named values are represented as a string of characters with a '%' prefix.
				289	For example, %foo, %DivisionByZero, %a.really.long.identifier. The actual
				290	regular expression used is '<tt>%[a-zA-Z$._][a-zA-Z$._0-9]*</tt>'.
				291	Identifiers which require other characters in their names can be surrounded
				292	with quotes. In this way, anything except a <tt>"</tt> character can be used
				293	in a name.</li>
				294
				295	<li>Unnamed values are represented as an unsigned numeric value with a '%'
				296	prefix. For example, %12, %2, %44.</li>
				297
				298	<li>Constants, which are described in a <a href="#constants">section about
				299	constants</a>, below.</li>
				300	</ol>
				301
				302	<p>LLVM requires that values start with a '%' sign for two reasons: Compilers
				303	don't need to worry about name clashes with reserved words, and the set of
				304	reserved words may be expanded in the future without penalty. Additionally,
				305	unnamed identifiers allow a compiler to quickly come up with a temporary
				306	variable without having to avoid symbol table conflicts.</p>
				307
				308	<p>Reserved words in LLVM are very similar to reserved words in other
				309	languages. There are keywords for different opcodes
				310	('<tt><a href="#i_add">add</a></tt>',
				311	'<tt><a href="#i_bitcast">bitcast</a></tt>',
				312	'<tt><a href="#i_ret">ret</a></tt>', etc...), for primitive type names ('<tt><a
				313	href="#t_void">void</a></tt>', '<tt><a href="#t_primitive">i32</a></tt>', etc...),
				314	and others. These reserved words cannot conflict with variable names, because
				315	none of them start with a '%' character.</p>
				316
				317	<p>Here is an example of LLVM code to multiply the integer variable
				318	'<tt>%X</tt>' by 8:</p>
				319
				320	<p>The easy way:</p>
				321
				322	<div class="doc_code">
				323	<pre>
				324	%result = <a href="#i_mul">mul</a> i32 %X, 8
				325	</pre>
				326	</div>
				327
				328	<p>After strength reduction:</p>
				329
				330	<div class="doc_code">
				331	<pre>
				332	%result = <a href="#i_shl">shl</a> i32 %X, i8 3
				333	</pre>
				334	</div>
				335
				336	<p>And the hard way:</p>
				337
				338	<div class="doc_code">
				339	<pre>
				340	<a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
				341	<a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
				342	%result = <a href="#i_add">add</a> i32 %1, %1
				343	</pre>
				344	</div>
				345
				346	<p>This last way of multiplying <tt>%X</tt> by 8 illustrates several
				347	important lexical features of LLVM:</p>
				348
				349	<ol>
				350
				351	<li>Comments are delimited with a '<tt>;</tt>' and go until the end of
				352	line.</li>
				353
				354	<li>Unnamed temporaries are created when the result of a computation is not
				355	assigned to a named value.</li>
				356
				357	<li>Unnamed temporaries are numbered sequentially</li>
				358
				359	</ol>
				360
				361	<p>...and it also shows a convention that we follow in this document. When
				362	demonstrating instructions, we will follow an instruction with a comment that
				363	defines the type and name of value produced. Comments are shown in italic
				364	text.</p>
				365
				366	</div>
				367
				368	<!-- *********************************************************************** -->
				369	<div class="doc_section"> <a name="highlevel">High Level Structure</a> </div>
				370	<!-- *********************************************************************** -->
				371
				372	<!-- ======================================================================= -->
				373	<div class="doc_subsection"> <a name="modulestructure">Module Structure</a>
				374	</div>
				375
				376	<div class="doc_text">
				377
				378	<p>LLVM programs are composed of "Module"s, each of which is a
				379	translation unit of the input programs. Each module consists of
				380	functions, global variables, and symbol table entries. Modules may be
				381	combined together with the LLVM linker, which merges function (and
				382	global variable) definitions, resolves forward declarations, and merges
				383	symbol table entries. Here is an example of the "hello world" module:</p>
				384
				385	<div class="doc_code">
				386	<pre><i>; Declare the string constant as a global constant...</i>
				387	<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a
				388	href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
				389
				390	<i>; External declaration of the puts function</i>
				391	<a href="#functionstructure">declare</a> i32 @puts(i8 ) <i>; i32(i8 )* </i>
				392
				393	<i>; Definition of main function</i>
				394	define i32 @main() { <i>; i32()* </i>
				395	<i>; Convert [13x i8 ]* to i8 *...</i>
				396	%cast210 = <a
				397	href="#i_getelementptr">getelementptr</a> [13 x i8 ]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
				398
				399	<i>; Call puts function to write out the string to stdout...</i>
				400	<a
				401	href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i>
				402	<a
				403	href="#i_ret">ret</a> i32 0<br>}<br>
				404	</pre>
				405	</div>
				406
				407	<p>This example is made up of a <a href="#globalvars">global variable</a>
				408	named "<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>"
				409	function, and a <a href="#functionstructure">function definition</a>
				410	for "<tt>main</tt>".</p>
				411
				412	<p>In general, a module is made up of a list of global values,
				413	where both functions and global variables are global values. Global values are
				414	represented by a pointer to a memory location (in this case, a pointer to an
				415	array of char, and a pointer to a function), and have one of the following <a
				416	href="#linkage">linkage types</a>.</p>
				417
				418	</div>
				419
				420	<!-- ======================================================================= -->
				421	<div class="doc_subsection">
				422	<a name="linkage">Linkage Types</a>
				423	</div>
				424
				425	<div class="doc_text">
				426
				427	<p>
				428	All Global Variables and Functions have one of the following types of linkage:
				429	</p>
				430
				431	<dl>
				432
				433	<dt><tt><b><a name="linkage_internal">internal</a></b></tt> </dt>
				434
				435	<dd>Global values with internal linkage are only directly accessible by
				436	objects in the current module. In particular, linking code into a module with
				437	an internal global value may cause the internal to be renamed as necessary to
				438	avoid collisions. Because the symbol is internal to the module, all
				439	references can be updated. This corresponds to the notion of the
				440	'<tt>static</tt>' keyword in C.
				441	</dd>
				442
				443	<dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt>: </dt>
				444
				445	<dd>Globals with "<tt>linkonce</tt>" linkage are merged with other globals of
				446	the same name when linkage occurs. This is typically used to implement
				447	inline functions, templates, or other code which must be generated in each
				448	translation unit that uses it. Unreferenced <tt>linkonce</tt> globals are
				449	allowed to be discarded.
				450	</dd>
				451
				452	<dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt>
				453
				454	<dd>"<tt>weak</tt>" linkage is exactly the same as <tt>linkonce</tt> linkage,
				455	except that unreferenced <tt>weak</tt> globals may not be discarded. This is
				456	used for globals that may be emitted in multiple translation units, but that
				457	are not guaranteed to be emitted into every translation unit that uses them.
				458	One example of this are common globals in C, such as "<tt>int X;</tt>" at
				459	global scope.
				460	</dd>
				461
				462	<dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt>
				463
				464	<dd>"<tt>appending</tt>" linkage may only be applied to global variables of
				465	pointer to array type. When two global variables with appending linkage are
				466	linked together, the two global arrays are appended together. This is the
				467	LLVM, typesafe, equivalent of having the system linker append together
				468	"sections" with identical names when .o files are linked.
				469	</dd>
				470
				471	<dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
				472	<dd>The semantics of this linkage follow the ELF model: the symbol is weak
				473	until linked, if not linked, the symbol becomes null instead of being an
				474	undefined reference.
				475	</dd>
				476
				477	<dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
				478
				479	<dd>If none of the above identifiers are used, the global is externally
				480	visible, meaning that it participates in linkage and can be used to resolve
				481	external symbol references.
				482	</dd>
				483	</dl>
				484
				485	<p>
				486	The next two types of linkage are targeted for Microsoft Windows platform
				487	only. They are designed to support importing (exporting) symbols from (to)
				488	DLLs.
				489	</p>
				490
				491	<dl>
				492	<dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt>: </dt>
				493
				494	<dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
				495	or variable via a global pointer to a pointer that is set up by the DLL
				496	exporting the symbol. On Microsoft Windows targets, the pointer name is
				497	formed by combining <code>_imp__</code> and the function or variable name.
				498	</dd>
				499
				500	<dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt>: </dt>
				501
				502	<dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global
				503	pointer to a pointer in a DLL, so that it can be referenced with the
				504	<tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer
				505	name is formed by combining <code>_imp__</code> and the function or variable
				506	name.
				507	</dd>
				508
				509	</dl>
				510
				511	<p><a name="linkage_external"></a>For example, since the "<tt>.LC0</tt>"
				512	variable is defined to be internal, if another module defined a "<tt>.LC0</tt>"
				513	variable and was linked with this one, one of the two would be renamed,
				514	preventing a collision. Since "<tt>main</tt>" and "<tt>puts</tt>" are
				515	external (i.e., lacking any linkage declarations), they are accessible
				516	outside of the current module.</p>
				517	<p>It is illegal for a function <i>declaration</i>
				518	to have any linkage type other than "externally visible", <tt>dllimport</tt>,
				519	or <tt>extern_weak</tt>.</p>
				520	<p>Aliases can have only <tt>external</tt>, <tt>internal</tt> and <tt>weak</tt>
				521	linkages.
				522	</div>
				523
				524	<!-- ======================================================================= -->
				525	<div class="doc_subsection">
				526	<a name="callingconv">Calling Conventions</a>
				527	</div>
				528
				529	<div class="doc_text">
				530
				531	<p>LLVM <a href="#functionstructure">functions</a>, <a href="#i_call">calls</a>
				532	and <a href="#i_invoke">invokes</a> can all have an optional calling convention
				533	specified for the call. The calling convention of any pair of dynamic
				534	caller/callee must match, or the behavior of the program is undefined. The
				535	following calling conventions are supported by LLVM, and more may be added in
				536	the future:</p>
				537
				538	<dl>
				539	<dt><b>"<tt>ccc</tt>" - The C calling convention</b>:</dt>
				540
				541	<dd>This calling convention (the default if no other calling convention is
				542	specified) matches the target C calling conventions. This calling convention
				543	supports varargs function calls and tolerates some mismatch in the declared
				544	prototype and implemented declaration of the function (as does normal C).
				545	</dd>
				546
				547	<dt><b>"<tt>fastcc</tt>" - The fast calling convention</b>:</dt>
				548
				549	<dd>This calling convention attempts to make calls as fast as possible
				550	(e.g. by passing things in registers). This calling convention allows the
				551	target to use whatever tricks it wants to produce fast code for the target,
				552	without having to conform to an externally specified ABI. Implementations of
				553	this convention should allow arbitrary tail call optimization to be supported.
				554	This calling convention does not support varargs and requires the prototype of
				555	all callees to exactly match the prototype of the function definition.
				556	</dd>
				557
				558	<dt><b>"<tt>coldcc</tt>" - The cold calling convention</b>:</dt>
				559
				560	<dd>This calling convention attempts to make code in the caller as efficient
				561	as possible under the assumption that the call is not commonly executed. As
				562	such, these calls often preserve all registers so that the call does not break
				563	any live ranges in the caller side. This calling convention does not support
				564	varargs and requires the prototype of all callees to exactly match the
				565	prototype of the function definition.
				566	</dd>
				567
				568	<dt><b>"<tt>cc <<em>n</em>></tt>" - Numbered convention</b>:</dt>
				569
				570	<dd>Any calling convention may be specified by number, allowing
				571	target-specific calling conventions to be used. Target specific calling
				572	conventions start at 64.
				573	</dd>
				574	</dl>
				575
				576	<p>More calling conventions can be added/defined on an as-needed basis, to
				577	support pascal conventions or any other well-known target-independent
				578	convention.</p>
				579
				580	</div>
				581
				582	<!-- ======================================================================= -->
				583	<div class="doc_subsection">
				584	<a name="visibility">Visibility Styles</a>
				585	</div>
				586
				587	<div class="doc_text">
				588
				589	<p>
				590	All Global Variables and Functions have one of the following visibility styles:
				591	</p>
				592
				593	<dl>
				594	<dt><b>"<tt>default</tt>" - Default style</b>:</dt>
				595
				596	<dd>On ELF, default visibility means that the declaration is visible to other
				597	modules and, in shared libraries, means that the declared entity may be
				598	overridden. On Darwin, default visibility means that the declaration is
				599	visible to other modules. Default visibility corresponds to "external
				600	linkage" in the language.
				601	</dd>
				602
				603	<dt><b>"<tt>hidden</tt>" - Hidden style</b>:</dt>
				604
				605	<dd>Two declarations of an object with hidden visibility refer to the same
				606	object if they are in the same shared object. Usually, hidden visibility
				607	indicates that the symbol will not be placed into the dynamic symbol table,
				608	so no other module (executable or shared library) can reference it
				609	directly.
				610	</dd>
				611
				612	<dt><b>"<tt>protected</tt>" - Protected style</b>:</dt>
				613
				614	<dd>On ELF, protected visibility indicates that the symbol will be placed in
				615	the dynamic symbol table, but that references within the defining module will
				616	bind to the local symbol. That is, the symbol cannot be overridden by another
				617	module.
				618	</dd>
				619	</dl>
				620
				621	</div>
				622
				623	<!-- ======================================================================= -->
				624	<div class="doc_subsection">
				625	<a name="globalvars">Global Variables</a>
				626	</div>
				627
				628	<div class="doc_text">
				629
				630	<p>Global variables define regions of memory allocated at compilation time
				631	instead of run-time. Global variables may optionally be initialized, may have
				632	an explicit section to be placed in, and may have an optional explicit alignment
				633	specified. A variable may be defined as "thread_local", which means that it
				634	will not be shared by threads (each thread will have a separated copy of the
				635	variable). A variable may be defined as a global "constant," which indicates
				636	that the contents of the variable will <b>never</b> be modified (enabling better
				637	optimization, allowing the global data to be placed in the read-only section of
				638	an executable, etc). Note that variables that need runtime initialization
				639	cannot be marked "constant" as there is a store to the variable.</p>
				640
				641	<p>
				642	LLVM explicitly allows <em>declarations</em> of global variables to be marked
				643	constant, even if the final definition of the global is not. This capability
				644	can be used to enable slightly better optimization of the program, but requires
				645	the language definition to guarantee that optimizations based on the
				646	'constantness' are valid for the translation units that do not include the
				647	definition.
				648	</p>
				649
				650	<p>As SSA values, global variables define pointer values that are in
				651	scope (i.e. they dominate) all basic blocks in the program. Global
				652	variables always define a pointer to their "content" type because they
				653	describe a region of memory, and all memory objects in LLVM are
				654	accessed through pointers.</p>
				655
				656	<p>LLVM allows an explicit section to be specified for globals. If the target
				657	supports it, it will emit globals to the section specified.</p>
				658
				659	<p>An explicit alignment may be specified for a global. If not present, or if
				660	the alignment is set to zero, the alignment of the global is set by the target
				661	to whatever it feels convenient. If an explicit alignment is specified, the
				662	global is forced to have at least that much alignment. All alignments must be
				663	a power of 2.</p>
				664
				665	<p>For example, the following defines a global with an initializer, section,
				666	and alignment:</p>
				667
				668	<div class="doc_code">
				669	<pre>
				670	@G = constant float 1.0, section "foo", align 4
				671	</pre>
				672	</div>
				673
				674	</div>
				675
				676
				677	<!-- ======================================================================= -->
				678	<div class="doc_subsection">
				679	<a name="functionstructure">Functions</a>
				680	</div>
				681
				682	<div class="doc_text">
				683
				684	<p>LLVM function definitions consist of the "<tt>define</tt>" keyord,
				685	an optional <a href="#linkage">linkage type</a>, an optional
				686	<a href="#visibility">visibility style</a>, an optional
				687	<a href="#callingconv">calling convention</a>, a return type, an optional
				688	<a href="#paramattrs">parameter attribute</a> for the return type, a function
				689	name, a (possibly empty) argument list (each with optional
				690	<a href="#paramattrs">parameter attributes</a>), an optional section, an
				691	optional alignment, an opening curly brace, a list of basic blocks, and a
				692	closing curly brace.
				693
				694	LLVM function declarations consist of the "<tt>declare</tt>" keyword, an
				695	optional <a href="#linkage">linkage type</a>, an optional
				696	<a href="#visibility">visibility style</a>, an optional
				697	<a href="#callingconv">calling convention</a>, a return type, an optional
				698	<a href="#paramattrs">parameter attribute</a> for the return type, a function
				699	name, a possibly empty list of arguments, and an optional alignment.</p>
				700
				701	<p>A function definition contains a list of basic blocks, forming the CFG for
				702	the function. Each basic block may optionally start with a label (giving the
				703	basic block a symbol table entry), contains a list of instructions, and ends
				704	with a <a href="#terminators">terminator</a> instruction (such as a branch or
				705	function return).</p>
				706
				707	<p>The first basic block in a function is special in two ways: it is immediately
				708	executed on entrance to the function, and it is not allowed to have predecessor
				709	basic blocks (i.e. there can not be any branches to the entry block of a
				710	function). Because the block can have no predecessors, it also cannot have any
				711	<a href="#i_phi">PHI nodes</a>.</p>
				712
				713	<p>LLVM allows an explicit section to be specified for functions. If the target
				714	supports it, it will emit functions to the section specified.</p>
				715
				716	<p>An explicit alignment may be specified for a function. If not present, or if
				717	the alignment is set to zero, the alignment of the function is set by the target
				718	to whatever it feels convenient. If an explicit alignment is specified, the
				719	function is forced to have at least that much alignment. All alignments must be
				720	a power of 2.</p>
				721
				722	</div>
				723
				724
				725	<!-- ======================================================================= -->
				726	<div class="doc_subsection">
				727	<a name="aliasstructure">Aliases</a>
				728	</div>
				729	<div class="doc_text">
				730	<p>Aliases act as "second name" for the aliasee value (which can be either
				731	function or global variable or bitcast of global value). Aliases may have an
				732	optional <a href="#linkage">linkage type</a>, and an
				733	optional <a href="#visibility">visibility style</a>.</p>
				734
				735	<h5>Syntax:</h5>
				736
				737	<div class="doc_code">
				738	<pre>
				739	@<Name> = [Linkage] [Visibility] alias <AliaseeTy> @<Aliasee>
				740	</pre>
				741	</div>
				742
				743	</div>
				744
				745
				746
				747	<!-- ======================================================================= -->
				748	<div class="doc_subsection"><a name="paramattrs">Parameter Attributes</a></div>
				749	<div class="doc_text">
				750	<p>The return type and each parameter of a function type may have a set of
				751	<i>parameter attributes</i> associated with them. Parameter attributes are
				752	used to communicate additional information about the result or parameters of
				753	a function. Parameter attributes are considered to be part of the function
				754	type so two functions types that differ only by the parameter attributes
				755	are different function types.</p>
				756
				757	<p>Parameter attributes are simple keywords that follow the type specified. If
				758	multiple parameter attributes are needed, they are space separated. For
				759	example:</p>
				760
				761	<div class="doc_code">
				762	<pre>
				763	%someFunc = i16 (i8 sext %someParam) zext
				764	%someFunc = i16 (i8 zext %someParam) zext
				765	</pre>
				766	</div>
				767
				768	<p>Note that the two function types above are unique because the parameter has
				769	a different attribute (sext in the first one, zext in the second). Also note
				770	that the attribute for the function result (zext) comes immediately after the
				771	argument list.</p>
				772
				773	<p>Currently, only the following parameter attributes are defined:</p>
				774	<dl>
				775	<dt><tt>zext</tt></dt>
				776	<dd>This indicates that the parameter should be zero extended just before
				777	a call to this function.</dd>
				778	<dt><tt>sext</tt></dt>
				779	<dd>This indicates that the parameter should be sign extended just before
				780	a call to this function.</dd>
				781	<dt><tt>inreg</tt></dt>
				782	<dd>This indicates that the parameter should be placed in register (if
				783	possible) during assembling function call. Support for this attribute is
				784	target-specific</dd>
				785	<dt><tt>sret</tt></dt>
				786	<dd>This indicates that the parameter specifies the address of a structure
				787	that is the return value of the function in the source program.</dd>
				788	<dt><tt>noalias</tt></dt>
				789	<dd>This indicates that the parameter not alias any other object or any
				790	other "noalias" objects during the function call.
				791	<dt><tt>noreturn</tt></dt>
				792	<dd>This function attribute indicates that the function never returns. This
				793	indicates to LLVM that every call to this function should be treated as if
				794	an <tt>unreachable</tt> instruction immediately followed the call.</dd>
				795	<dt><tt>nounwind</tt></dt>
				796	<dd>This function attribute indicates that the function type does not use
				797	the unwind instruction and does not allow stack unwinding to propagate
				798	through it.</dd>
				799	</dl>
				800
				801	</div>
				802
				803	<!-- ======================================================================= -->
				804	<div class="doc_subsection">
				805	<a name="moduleasm">Module-Level Inline Assembly</a>
				806	</div>
				807
				808	<div class="doc_text">
				809	<p>
				810	Modules may contain "module-level inline asm" blocks, which corresponds to the
				811	GCC "file scope inline asm" blocks. These blocks are internally concatenated by
				812	LLVM and treated as a single unit, but may be separated in the .ll file if
				813	desired. The syntax is very simple:
				814	</p>
				815
				816	<div class="doc_code">
				817	<pre>
				818	module asm "inline asm code goes here"
				819	module asm "more can go here"
				820	</pre>
				821	</div>
				822
				823	<p>The strings can contain any character by escaping non-printable characters.
				824	The escape sequence used is simply "\xx" where "xx" is the two digit hex code
				825	for the number.
				826	</p>
				827
				828	<p>
				829	The inline asm code is simply printed to the machine code .s file when
				830	assembly code is generated.
				831	</p>
				832	</div>
				833
				834	<!-- ======================================================================= -->
				835	<div class="doc_subsection">
				836	<a name="datalayout">Data Layout</a>
				837	</div>
				838
				839	<div class="doc_text">
				840	<p>A module may specify a target specific data layout string that specifies how
				841	data is to be laid out in memory. The syntax for the data layout is simply:</p>
				842	<pre> target datalayout = "<i>layout specification</i>"</pre>
				843	<p>The <i>layout specification</i> consists of a list of specifications
				844	separated by the minus sign character ('-'). Each specification starts with a
				845	letter and may include other information after the letter to define some
				846	aspect of the data layout. The specifications accepted are as follows: </p>
				847	<dl>
				848	<dt><tt>E</tt></dt>
				849	<dd>Specifies that the target lays out data in big-endian form. That is, the
				850	bits with the most significance have the lowest address location.</dd>
				851	<dt><tt>e</tt></dt>
				852	<dd>Specifies that hte target lays out data in little-endian form. That is,
				853	the bits with the least significance have the lowest address location.</dd>
				854	<dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
				855	<dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
				856	<i>preferred</i> alignments. All sizes are in bits. Specifying the <i>pref</i>
				857	alignment is optional. If omitted, the preceding <tt>:</tt> should be omitted
				858	too.</dd>
				859	<dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
				860	<dd>This specifies the alignment for an integer type of a given bit
				861	<i>size</i>. The value of <i>size</i> must be in the range [1,2^23).</dd>
				862	<dt><tt>v<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
				863	<dd>This specifies the alignment for a vector type of a given bit
				864	<i>size</i>.</dd>
				865	<dt><tt>f<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
				866	<dd>This specifies the alignment for a floating point type of a given bit
				867	<i>size</i>. The value of <i>size</i> must be either 32 (float) or 64
				868	(double).</dd>
				869	<dt><tt>a<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
				870	<dd>This specifies the alignment for an aggregate type of a given bit
				871	<i>size</i>.</dd>
				872	</dl>
				873	<p>When constructing the data layout for a given target, LLVM starts with a
				874	default set of specifications which are then (possibly) overriden by the
				875	specifications in the <tt>datalayout</tt> keyword. The default specifications
				876	are given in this list:</p>
				877	<ul>
				878	<li><tt>E</tt> - big endian</li>
				879	<li><tt>p:32:64:64</tt> - 32-bit pointers with 64-bit alignment</li>
				880	<li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li>
				881	<li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li>
				882	<li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li>
				883	<li><tt>i32:32:32</tt> - i32 is 32-bit aligned</li>
				884	<li><tt>i64:32:64</tt> - i64 has abi alignment of 32-bits but preferred
				885	alignment of 64-bits</li>
				886	<li><tt>f32:32:32</tt> - float is 32-bit aligned</li>
				887	<li><tt>f64:64:64</tt> - double is 64-bit aligned</li>
				888	<li><tt>v64:64:64</tt> - 64-bit vector is 64-bit aligned</li>
				889	<li><tt>v128:128:128</tt> - 128-bit vector is 128-bit aligned</li>
				890	<li><tt>a0:0:1</tt> - aggregates are 8-bit aligned</li>
				891	</ul>
				892	<p>When llvm is determining the alignment for a given type, it uses the
				893	following rules:
				894	<ol>
				895	<li>If the type sought is an exact match for one of the specifications, that
				896	specification is used.</li>
				897	<li>If no match is found, and the type sought is an integer type, then the
				898	smallest integer type that is larger than the bitwidth of the sought type is
				899	used. If none of the specifications are larger than the bitwidth then the the
				900	largest integer type is used. For example, given the default specifications
				901	above, the i7 type will use the alignment of i8 (next largest) while both
				902	i65 and i256 will use the alignment of i64 (largest specified).</li>
				903	<li>If no match is found, and the type sought is a vector type, then the
				904	largest vector type that is smaller than the sought vector type will be used
				905	as a fall back. This happens because <128 x double> can be implemented in
				906	terms of 64 <2 x double>, for example.</li>
				907	</ol>
				908	</div>
				909
				910	<!-- *********************************************************************** -->
				911	<div class="doc_section"> <a name="typesystem">Type System</a> </div>
				912	<!-- *********************************************************************** -->
				913
				914	<div class="doc_text">
				915
				916	<p>The LLVM type system is one of the most important features of the
				917	intermediate representation. Being typed enables a number of
				918	optimizations to be performed on the IR directly, without having to do
				919	extra analyses on the side before the transformation. A strong type
				920	system makes it easier to read the generated code and enables novel
				921	analyses and transformations that are not feasible to perform on normal
				922	three address code representations.</p>
				923
				924	</div>
				925
				926	<!-- ======================================================================= -->
				927	<div class="doc_subsection"> <a name="t_primitive">Primitive Types</a> </div>
				928	<div class="doc_text">
				929	<p>The primitive types are the fundamental building blocks of the LLVM
				930	system. The current set of primitive types is as follows:</p>
				931
				932	<table class="layout">
				933	<tr class="layout">
				934	<td class="left">
				935	<table>
				936	<tbody>
				937	<tr><th>Type</th><th>Description</th></tr>
				938	<tr><td><tt><a name="t_void">void</a></tt></td><td>No value</td></tr>
				939	<tr><td><tt>label</tt></td><td>Branch destination</td></tr>
				940	</tbody>
				941	</table>
				942	</td>
				943	<td class="right">
				944	<table>
				945	<tbody>
				946	<tr><th>Type</th><th>Description</th></tr>
				947	<tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
				948	<tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
				949	</tbody>
				950	</table>
				951	</td>
				952	</tr>
				953	</table>
				954	</div>
				955
				956	<!-- _______________________________________________________________________ -->
				957	<div class="doc_subsubsection"> <a name="t_classifications">Type
				958	Classifications</a> </div>
				959	<div class="doc_text">
				960	<p>These different primitive types fall into a few useful
				961	classifications:</p>
				962
				963	<table border="1" cellspacing="0" cellpadding="4">
				964	<tbody>
				965	<tr><th>Classification</th><th>Types</th></tr>
				966	<tr>
				967	<td><a name="t_integer">integer</a></td>
				968	<td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td>
				969	</tr>
				970	<tr>
				971	<td><a name="t_floating">floating point</a></td>
				972	<td><tt>float, double</tt></td>
				973	</tr>
				974	<tr>
				975	<td><a name="t_firstclass">first class</a></td>
				976	<td><tt>i1, ..., float, double, <br/>
				977	<a href="#t_pointer">pointer</a>,<a href="#t_vector">vector</a></tt>
				978	</td>
				979	</tr>
				980	</tbody>
				981	</table>
				982
				983	<p>The <a href="#t_firstclass">first class</a> types are perhaps the
				984	most important. Values of these types are the only ones which can be
				985	produced by instructions, passed as arguments, or used as operands to
				986	instructions. This means that all structures and arrays must be
				987	manipulated either by pointer or by component.</p>
				988	</div>
				989
				990	<!-- ======================================================================= -->
				991	<div class="doc_subsection"> <a name="t_derived">Derived Types</a> </div>
				992
				993	<div class="doc_text">
				994
				995	<p>The real power in LLVM comes from the derived types in the system.
				996	This is what allows a programmer to represent arrays, functions,
				997	pointers, and other useful types. Note that these derived types may be
				998	recursive: For example, it is possible to have a two dimensional array.</p>
				999
				1000	</div>
				1001
				1002	<!-- _______________________________________________________________________ -->
				1003	<div class="doc_subsubsection"> <a name="t_integer">Integer Type</a> </div>
				1004
				1005	<div class="doc_text">
				1006
				1007	<h5>Overview:</h5>
				1008	<p>The integer type is a very simple derived type that simply specifies an
				1009	arbitrary bit width for the integer type desired. Any bit width from 1 bit to
				1010	2^23-1 (about 8 million) can be specified.</p>
				1011
				1012	<h5>Syntax:</h5>
				1013
				1014	<pre>
				1015	iN
				1016	</pre>
				1017
				1018	<p>The number of bits the integer will occupy is specified by the <tt>N</tt>
				1019	value.</p>
				1020
				1021	<h5>Examples:</h5>
				1022	<table class="layout">
				1023	<tr class="layout">
				1024	<td class="left">
				1025	<tt>i1</tt><br/>
				1026	<tt>i4</tt><br/>
				1027	<tt>i8</tt><br/>
				1028	<tt>i16</tt><br/>
				1029	<tt>i32</tt><br/>
				1030	<tt>i42</tt><br/>
				1031	<tt>i64</tt><br/>
				1032	<tt>i1942652</tt><br/>
				1033	</td>
				1034	<td class="left">
				1035	A boolean integer of 1 bit<br/>
				1036	A nibble sized integer of 4 bits.<br/>
				1037	A byte sized integer of 8 bits.<br/>
				1038	A half word sized integer of 16 bits.<br/>
				1039	A word sized integer of 32 bits.<br/>
				1040	An integer whose bit width is the answer. <br/>
				1041	A double word sized integer of 64 bits.<br/>
				1042	A really big integer of over 1 million bits.<br/>
				1043	</td>
				1044	</tr>
				1045	</table>
				1046	</div>
				1047
				1048	<!-- _______________________________________________________________________ -->
				1049	<div class="doc_subsubsection"> <a name="t_array">Array Type</a> </div>
				1050
				1051	<div class="doc_text">
				1052
				1053	<h5>Overview:</h5>
				1054
				1055	<p>The array type is a very simple derived type that arranges elements
				1056	sequentially in memory. The array type requires a size (number of
				1057	elements) and an underlying data type.</p>
				1058
				1059	<h5>Syntax:</h5>
				1060
				1061	<pre>
				1062	[<# elements> x <elementtype>]
				1063	</pre>
				1064
				1065	<p>The number of elements is a constant integer value; elementtype may
				1066	be any type with a size.</p>
				1067
				1068	<h5>Examples:</h5>
				1069	<table class="layout">
				1070	<tr class="layout">
				1071	<td class="left">
				1072	<tt>[40 x i32 ]</tt><br/>
				1073	<tt>[41 x i32 ]</tt><br/>
				1074	<tt>[40 x i8]</tt><br/>
				1075	</td>
				1076	<td class="left">
				1077	Array of 40 32-bit integer values.<br/>
				1078	Array of 41 32-bit integer values.<br/>
				1079	Array of 40 8-bit integer values.<br/>
				1080	</td>
				1081	</tr>
				1082	</table>
				1083	<p>Here are some examples of multidimensional arrays:</p>
				1084	<table class="layout">
				1085	<tr class="layout">
				1086	<td class="left">
				1087	<tt>[3 x [4 x i32]]</tt><br/>
				1088	<tt>[12 x [10 x float]]</tt><br/>
				1089	<tt>[2 x [3 x [4 x i16]]]</tt><br/>
				1090	</td>
				1091	<td class="left">
				1092	3x4 array of 32-bit integer values.<br/>
				1093	12x10 array of single precision floating point values.<br/>
				1094	2x3x4 array of 16-bit integer values.<br/>
				1095	</td>
				1096	</tr>
				1097	</table>
				1098
				1099	<p>Note that 'variable sized arrays' can be implemented in LLVM with a zero
				1100	length array. Normally, accesses past the end of an array are undefined in
				1101	LLVM (e.g. it is illegal to access the 5th element of a 3 element array).
				1102	As a special case, however, zero length arrays are recognized to be variable
				1103	length. This allows implementation of 'pascal style arrays' with the LLVM
				1104	type "{ i32, [0 x float]}", for example.</p>
				1105
				1106	</div>
				1107
				1108	<!-- _______________________________________________________________________ -->
				1109	<div class="doc_subsubsection"> <a name="t_function">Function Type</a> </div>
				1110	<div class="doc_text">
				1111	<h5>Overview:</h5>
				1112	<p>The function type can be thought of as a function signature. It
				1113	consists of a return type and a list of formal parameter types.
				1114	Function types are usually used to build virtual function tables
				1115	(which are structures of pointers to functions), for indirect function
				1116	calls, and when defining a function.</p>
				1117	<p>
				1118	The return type of a function type cannot be an aggregate type.
				1119	</p>
				1120	<h5>Syntax:</h5>
				1121	<pre> <returntype> (<parameter list>)<br></pre>
				1122	<p>...where '<tt><parameter list></tt>' is a comma-separated list of type
				1123	specifiers. Optionally, the parameter list may include a type <tt>...</tt>,
				1124	which indicates that the function takes a variable number of arguments.
				1125	Variable argument functions can access their arguments with the <a
				1126	href="#int_varargs">variable argument handling intrinsic</a> functions.</p>
				1127	<h5>Examples:</h5>
				1128	<table class="layout">
				1129	<tr class="layout">
				1130	<td class="left"><tt>i32 (i32)</tt></td>
				1131	<td class="left">function taking an <tt>i32</tt>, returning an <tt>i32</tt>
				1132	</td>
				1133	</tr><tr class="layout">
				1134	<td class="left"><tt>float (i16 sext, i32 )
				1135	</tt></td>
				1136	<td class="left"><a href="#t_pointer">Pointer</a> to a function that takes
				1137	an <tt>i16</tt> that should be sign extended and a
				1138	<a href="#t_pointer">pointer</a> to <tt>i32</tt>, returning
				1139	<tt>float</tt>.
				1140	</td>
				1141	</tr><tr class="layout">
				1142	<td class="left"><tt>i32 (i8*, ...)</tt></td>
				1143	<td class="left">A vararg function that takes at least one
				1144	<a href="#t_pointer">pointer</a> to <tt>i8 </tt> (char in C),
				1145	which returns an integer. This is the signature for <tt>printf</tt> in
				1146	LLVM.
				1147	</td>
				1148	</tr>
				1149	</table>
				1150
				1151	</div>
				1152	<!-- _______________________________________________________________________ -->
				1153	<div class="doc_subsubsection"> <a name="t_struct">Structure Type</a> </div>
				1154	<div class="doc_text">
				1155	<h5>Overview:</h5>
				1156	<p>The structure type is used to represent a collection of data members
				1157	together in memory. The packing of the field types is defined to match
				1158	the ABI of the underlying processor. The elements of a structure may
				1159	be any type that has a size.</p>
				1160	<p>Structures are accessed using '<tt><a href="#i_load">load</a></tt>
				1161	and '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a
				1162	field with the '<tt><a href="#i_getelementptr">getelementptr</a></tt>'
				1163	instruction.</p>
				1164	<h5>Syntax:</h5>
				1165	<pre> { <type list> }<br></pre>
				1166	<h5>Examples:</h5>
				1167	<table class="layout">
				1168	<tr class="layout">
				1169	<td class="left"><tt>{ i32, i32, i32 }</tt></td>
				1170	<td class="left">A triple of three <tt>i32</tt> values</td>
				1171	</tr><tr class="layout">
				1172	<td class="left"><tt>{ float, i32 (i32) * }</tt></td>
				1173	<td class="left">A pair, where the first element is a <tt>float</tt> and the
				1174	second element is a <a href="#t_pointer">pointer</a> to a
				1175	<a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
				1176	an <tt>i32</tt>.</td>
				1177	</tr>
				1178	</table>
				1179	</div>
				1180
				1181	<!-- _______________________________________________________________________ -->
				1182	<div class="doc_subsubsection"> <a name="t_pstruct">Packed Structure Type</a>
				1183	</div>
				1184	<div class="doc_text">
				1185	<h5>Overview:</h5>
				1186	<p>The packed structure type is used to represent a collection of data members
				1187	together in memory. There is no padding between fields. Further, the alignment
				1188	of a packed structure is 1 byte. The elements of a packed structure may
				1189	be any type that has a size.</p>
				1190	<p>Structures are accessed using '<tt><a href="#i_load">load</a></tt>
				1191	and '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a
				1192	field with the '<tt><a href="#i_getelementptr">getelementptr</a></tt>'
				1193	instruction.</p>
				1194	<h5>Syntax:</h5>
				1195	<pre> < { <type list> } > <br></pre>
				1196	<h5>Examples:</h5>
				1197	<table class="layout">
				1198	<tr class="layout">
				1199	<td class="left"><tt>< { i32, i32, i32 } ></tt></td>
				1200	<td class="left">A triple of three <tt>i32</tt> values</td>
				1201	</tr><tr class="layout">
				1202	<td class="left"><tt>< { float, i32 (i32) * } ></tt></td>
				1203	<td class="left">A pair, where the first element is a <tt>float</tt> and the
				1204	second element is a <a href="#t_pointer">pointer</a> to a
				1205	<a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
				1206	an <tt>i32</tt>.</td>
				1207	</tr>
				1208	</table>
				1209	</div>
				1210
				1211	<!-- _______________________________________________________________________ -->
				1212	<div class="doc_subsubsection"> <a name="t_pointer">Pointer Type</a> </div>
				1213	<div class="doc_text">
				1214	<h5>Overview:</h5>
				1215	<p>As in many languages, the pointer type represents a pointer or
				1216	reference to another object, which must live in memory.</p>
				1217	<h5>Syntax:</h5>
				1218	<pre> <type> *<br></pre>
				1219	<h5>Examples:</h5>
				1220	<table class="layout">
				1221	<tr class="layout">
				1222	<td class="left">
				1223	<tt>[4x i32]*</tt><br/>
				1224	<tt>i32 (i32 ) </tt><br/>
				1225	</td>
				1226	<td class="left">
				1227	A <a href="#t_pointer">pointer</a> to <a href="#t_array">array</a> of
				1228	four <tt>i32</tt> values<br/>
				1229	A <a href="#t_pointer">pointer</a> to a <a
				1230	href="#t_function">function</a> that takes an <tt>i32*</tt>, returning an
				1231	<tt>i32</tt>.<br/>
				1232	</td>
				1233	</tr>
				1234	</table>
				1235	</div>
				1236
				1237	<!-- _______________________________________________________________________ -->
				1238	<div class="doc_subsubsection"> <a name="t_vector">Vector Type</a> </div>
				1239	<div class="doc_text">
				1240
				1241	<h5>Overview:</h5>
				1242
				1243	<p>A vector type is a simple derived type that represents a vector
				1244	of elements. Vector types are used when multiple primitive data
				1245	are operated in parallel using a single instruction (SIMD).
				1246	A vector type requires a size (number of
				1247	elements) and an underlying primitive data type. Vectors must have a power
				1248	of two length (1, 2, 4, 8, 16 ...). Vector types are
				1249	considered <a href="#t_firstclass">first class</a>.</p>
				1250
				1251	<h5>Syntax:</h5>
				1252
				1253	<pre>
				1254	< <# elements> x <elementtype> >
				1255	</pre>
				1256
				1257	<p>The number of elements is a constant integer value; elementtype may
				1258	be any integer or floating point type.</p>
				1259
				1260	<h5>Examples:</h5>
				1261
				1262	<table class="layout">
				1263	<tr class="layout">
				1264	<td class="left">
				1265	<tt><4 x i32></tt><br/>
				1266	<tt><8 x float></tt><br/>
				1267	<tt><2 x i64></tt><br/>
				1268	</td>
				1269	<td class="left">
				1270	Vector of 4 32-bit integer values.<br/>
				1271	Vector of 8 floating-point values.<br/>
				1272	Vector of 2 64-bit integer values.<br/>
				1273	</td>
				1274	</tr>
				1275	</table>
				1276	</div>
				1277
				1278	<!-- _______________________________________________________________________ -->
				1279	<div class="doc_subsubsection"> <a name="t_opaque">Opaque Type</a> </div>
				1280	<div class="doc_text">
				1281
				1282	<h5>Overview:</h5>
				1283
				1284	<p>Opaque types are used to represent unknown types in the system. This
				1285	corresponds (for example) to the C notion of a foward declared structure type.
				1286	In LLVM, opaque types can eventually be resolved to any type (not just a
				1287	structure type).</p>
				1288
				1289	<h5>Syntax:</h5>
				1290
				1291	<pre>
				1292	opaque
				1293	</pre>
				1294
				1295	<h5>Examples:</h5>
				1296
				1297	<table class="layout">
				1298	<tr class="layout">
				1299	<td class="left">
				1300	<tt>opaque</tt>
				1301	</td>
				1302	<td class="left">
				1303	An opaque type.<br/>
				1304	</td>
				1305	</tr>
				1306	</table>
				1307	</div>
				1308
				1309
				1310	<!-- *********************************************************************** -->
				1311	<div class="doc_section"> <a name="constants">Constants</a> </div>
				1312	<!-- *********************************************************************** -->
				1313
				1314	<div class="doc_text">
				1315
				1316	<p>LLVM has several different basic types of constants. This section describes
				1317	them all and their syntax.</p>
				1318
				1319	</div>
				1320
				1321	<!-- ======================================================================= -->
				1322	<div class="doc_subsection"><a name="simpleconstants">Simple Constants</a></div>
				1323
				1324	<div class="doc_text">
				1325
				1326	<dl>
				1327	<dt><b>Boolean constants</b></dt>
				1328
				1329	<dd>The two strings '<tt>true</tt>' and '<tt>false</tt>' are both valid
				1330	constants of the <tt><a href="#t_primitive">i1</a></tt> type.
				1331	</dd>
				1332
				1333	<dt><b>Integer constants</b></dt>
				1334
				1335	<dd>Standard integers (such as '4') are constants of the <a
				1336	href="#t_integer">integer</a> type. Negative numbers may be used with
				1337	integer types.
				1338	</dd>
				1339
				1340	<dt><b>Floating point constants</b></dt>
				1341
				1342	<dd>Floating point constants use standard decimal notation (e.g. 123.421),
				1343	exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
				1344	notation (see below). Floating point constants must have a <a
				1345	href="#t_floating">floating point</a> type. </dd>
				1346
				1347	<dt><b>Null pointer constants</b></dt>
				1348
				1349	<dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant
				1350	and must be of <a href="#t_pointer">pointer type</a>.</dd>
				1351
				1352	</dl>
				1353
				1354	<p>The one non-intuitive notation for constants is the optional hexadecimal form
				1355	of floating point constants. For example, the form '<tt>double
				1356	0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) '<tt>double
				1357	4.5e+15</tt>'. The only time hexadecimal floating point constants are required
				1358	(and the only time that they are generated by the disassembler) is when a
				1359	floating point constant must be emitted but it cannot be represented as a
				1360	decimal floating point number. For example, NaN's, infinities, and other
				1361	special values are represented in their IEEE hexadecimal format so that
				1362	assembly and disassembly do not cause any bits to change in the constants.</p>
				1363
				1364	</div>
				1365
				1366	<!-- ======================================================================= -->
				1367	<div class="doc_subsection"><a name="aggregateconstants">Aggregate Constants</a>
				1368	</div>
				1369
				1370	<div class="doc_text">
				1371	<p>Aggregate constants arise from aggregation of simple constants
				1372	and smaller aggregate constants.</p>
				1373
				1374	<dl>
				1375	<dt><b>Structure constants</b></dt>
				1376
				1377	<dd>Structure constants are represented with notation similar to structure
				1378	type definitions (a comma separated list of elements, surrounded by braces
				1379	(<tt>{}</tt>)). For example: "<tt>{ i32 4, float 17.0, i32* %G }</tt>",
				1380	where "<tt>%G</tt>" is declared as "<tt>@G = external global i32</tt>". Structure constants
				1381	must have <a href="#t_struct">structure type</a>, and the number and
				1382	types of elements must match those specified by the type.
				1383	</dd>
				1384
				1385	<dt><b>Array constants</b></dt>
				1386
				1387	<dd>Array constants are represented with notation similar to array type
				1388	definitions (a comma separated list of elements, surrounded by square brackets
				1389	(<tt>[]</tt>)). For example: "<tt>[ i32 42, i32 11, i32 74 ]</tt>". Array
				1390	constants must have <a href="#t_array">array type</a>, and the number and
				1391	types of elements must match those specified by the type.
				1392	</dd>
				1393
				1394	<dt><b>Vector constants</b></dt>
				1395
				1396	<dd>Vector constants are represented with notation similar to vector type
				1397	definitions (a comma separated list of elements, surrounded by
				1398	less-than/greater-than's (<tt><></tt>)). For example: "<tt>< i32 42,
				1399	i32 11, i32 74, i32 100 ></tt>". Vector constants must have <a
				1400	href="#t_vector">vector type</a>, and the number and types of elements must
				1401	match those specified by the type.
				1402	</dd>
				1403
				1404	<dt><b>Zero initialization</b></dt>
				1405
				1406	<dd>The string '<tt>zeroinitializer</tt>' can be used to zero initialize a
				1407	value to zero of <em>any</em> type, including scalar and aggregate types.
				1408	This is often used to avoid having to print large zero initializers (e.g. for
				1409	large arrays) and is always exactly equivalent to using explicit zero
				1410	initializers.
				1411	</dd>
				1412	</dl>
				1413
				1414	</div>
				1415
				1416	<!-- ======================================================================= -->
				1417	<div class="doc_subsection">
				1418	<a name="globalconstants">Global Variable and Function Addresses</a>
				1419	</div>
				1420
				1421	<div class="doc_text">
				1422
				1423	<p>The addresses of <a href="#globalvars">global variables</a> and <a
				1424	href="#functionstructure">functions</a> are always implicitly valid (link-time)
				1425	constants. These constants are explicitly referenced when the <a
				1426	href="#identifiers">identifier for the global</a> is used and always have <a
				1427	href="#t_pointer">pointer</a> type. For example, the following is a legal LLVM
				1428	file:</p>
				1429
				1430	<div class="doc_code">
				1431	<pre>
				1432	@X = global i32 17
				1433	@Y = global i32 42
				1434	@Z = global [2 x i32] [ i32 @X, i32* @Y ]
				1435	</pre>
				1436	</div>
				1437
				1438	</div>
				1439
				1440	<!-- ======================================================================= -->
				1441	<div class="doc_subsection"><a name="undefvalues">Undefined Values</a></div>
				1442	<div class="doc_text">
				1443	<p>The string '<tt>undef</tt>' is recognized as a type-less constant that has
				1444	no specific value. Undefined values may be of any type and be used anywhere
				1445	a constant is permitted.</p>
				1446
				1447	<p>Undefined values indicate to the compiler that the program is well defined
				1448	no matter what value is used, giving the compiler more freedom to optimize.
				1449	</p>
				1450	</div>
				1451
				1452	<!-- ======================================================================= -->
				1453	<div class="doc_subsection"><a name="constantexprs">Constant Expressions</a>
				1454	</div>
				1455
				1456	<div class="doc_text">
				1457
				1458	<p>Constant expressions are used to allow expressions involving other constants
				1459	to be used as constants. Constant expressions may be of any <a
				1460	href="#t_firstclass">first class</a> type and may involve any LLVM operation
				1461	that does not have side effects (e.g. load and call are not supported). The
				1462	following is the syntax for constant expressions:</p>
				1463
				1464	<dl>
				1465	<dt><b><tt>trunc ( CST to TYPE )</tt></b></dt>
				1466	<dd>Truncate a constant to another type. The bit size of CST must be larger
				1467	than the bit size of TYPE. Both types must be integers.</dd>
				1468
				1469	<dt><b><tt>zext ( CST to TYPE )</tt></b></dt>
				1470	<dd>Zero extend a constant to another type. The bit size of CST must be
				1471	smaller or equal to the bit size of TYPE. Both types must be integers.</dd>
				1472
				1473	<dt><b><tt>sext ( CST to TYPE )</tt></b></dt>
				1474	<dd>Sign extend a constant to another type. The bit size of CST must be
				1475	smaller or equal to the bit size of TYPE. Both types must be integers.</dd>
				1476
				1477	<dt><b><tt>fptrunc ( CST to TYPE )</tt></b></dt>
				1478	<dd>Truncate a floating point constant to another floating point type. The
				1479	size of CST must be larger than the size of TYPE. Both types must be
				1480	floating point.</dd>
				1481
				1482	<dt><b><tt>fpext ( CST to TYPE )</tt></b></dt>
				1483	<dd>Floating point extend a constant to another type. The size of CST must be
				1484	smaller or equal to the size of TYPE. Both types must be floating point.</dd>
				1485
				1486	<dt><b><tt>fp2uint ( CST to TYPE )</tt></b></dt>
				1487	<dd>Convert a floating point constant to the corresponding unsigned integer
				1488	constant. TYPE must be an integer type. CST must be floating point. If the
				1489	value won't fit in the integer type, the results are undefined.</dd>
				1490
				1491	<dt><b><tt>fptosi ( CST to TYPE )</tt></b></dt>
				1492	<dd>Convert a floating point constant to the corresponding signed integer
				1493	constant. TYPE must be an integer type. CST must be floating point. If the
				1494	value won't fit in the integer type, the results are undefined.</dd>
				1495
				1496	<dt><b><tt>uitofp ( CST to TYPE )</tt></b></dt>
				1497	<dd>Convert an unsigned integer constant to the corresponding floating point
				1498	constant. TYPE must be floating point. CST must be of integer type. If the
				1499	value won't fit in the floating point type, the results are undefined.</dd>
				1500
				1501	<dt><b><tt>sitofp ( CST to TYPE )</tt></b></dt>
				1502	<dd>Convert a signed integer constant to the corresponding floating point
				1503	constant. TYPE must be floating point. CST must be of integer type. If the
				1504	value won't fit in the floating point type, the results are undefined.</dd>
				1505
				1506	<dt><b><tt>ptrtoint ( CST to TYPE )</tt></b></dt>
				1507	<dd>Convert a pointer typed constant to the corresponding integer constant
				1508	TYPE must be an integer type. CST must be of pointer type. The CST value is
				1509	zero extended, truncated, or unchanged to make it fit in TYPE.</dd>
				1510
				1511	<dt><b><tt>inttoptr ( CST to TYPE )</tt></b></dt>
				1512	<dd>Convert a integer constant to a pointer constant. TYPE must be a
				1513	pointer type. CST must be of integer type. The CST value is zero extended,
				1514	truncated, or unchanged to make it fit in a pointer size. This one is
				1515	<i>really</i> dangerous!</dd>
				1516
				1517	<dt><b><tt>bitcast ( CST to TYPE )</tt></b></dt>
				1518	<dd>Convert a constant, CST, to another TYPE. The size of CST and TYPE must be
				1519	identical (same number of bits). The conversion is done as if the CST value
				1520	was stored to memory and read back as TYPE. In other words, no bits change
				1521	with this operator, just the type. This can be used for conversion of
				1522	vector types to any other type, as long as they have the same bit width. For
				1523	pointers it is only valid to cast to another pointer type.
				1524	</dd>
				1525
				1526	<dt><b><tt>getelementptr ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
				1527
				1528	<dd>Perform the <a href="#i_getelementptr">getelementptr operation</a> on
				1529	constants. As with the <a href="#i_getelementptr">getelementptr</a>
				1530	instruction, the index list may have zero or more indexes, which are required
				1531	to make sense for the type of "CSTPTR".</dd>
				1532
				1533	<dt><b><tt>select ( COND, VAL1, VAL2 )</tt></b></dt>
				1534
				1535	<dd>Perform the <a href="#i_select">select operation</a> on
				1536	constants.</dd>
				1537
				1538	<dt><b><tt>icmp COND ( VAL1, VAL2 )</tt></b></dt>
				1539	<dd>Performs the <a href="#i_icmp">icmp operation</a> on constants.</dd>
				1540
				1541	<dt><b><tt>fcmp COND ( VAL1, VAL2 )</tt></b></dt>
				1542	<dd>Performs the <a href="#i_fcmp">fcmp operation</a> on constants.</dd>
				1543
				1544	<dt><b><tt>extractelement ( VAL, IDX )</tt></b></dt>
				1545
				1546	<dd>Perform the <a href="#i_extractelement">extractelement
				1547	operation</a> on constants.
				1548
				1549	<dt><b><tt>insertelement ( VAL, ELT, IDX )</tt></b></dt>
				1550
				1551	<dd>Perform the <a href="#i_insertelement">insertelement
				1552	operation</a> on constants.</dd>
				1553
				1554
				1555	<dt><b><tt>shufflevector ( VEC1, VEC2, IDXMASK )</tt></b></dt>
				1556
				1557	<dd>Perform the <a href="#i_shufflevector">shufflevector
				1558	operation</a> on constants.</dd>
				1559
				1560	<dt><b><tt>OPCODE ( LHS, RHS )</tt></b></dt>
				1561
				1562	<dd>Perform the specified operation of the LHS and RHS constants. OPCODE may
				1563	be any of the <a href="#binaryops">binary</a> or <a href="#bitwiseops">bitwise
				1564	binary</a> operations. The constraints on operands are the same as those for
				1565	the corresponding instruction (e.g. no bitwise operations on floating point
				1566	values are allowed).</dd>
				1567	</dl>
				1568	</div>
				1569
				1570	<!-- *********************************************************************** -->
				1571	<div class="doc_section"> <a name="othervalues">Other Values</a> </div>
				1572	<!-- *********************************************************************** -->
				1573
				1574	<!-- ======================================================================= -->
				1575	<div class="doc_subsection">
				1576	<a name="inlineasm">Inline Assembler Expressions</a>
				1577	</div>
				1578
				1579	<div class="doc_text">
				1580
				1581	<p>
				1582	LLVM supports inline assembler expressions (as opposed to <a href="#moduleasm">
				1583	Module-Level Inline Assembly</a>) through the use of a special value. This
				1584	value represents the inline assembler as a string (containing the instructions
				1585	to emit), a list of operand constraints (stored as a string), and a flag that
				1586	indicates whether or not the inline asm expression has side effects. An example
				1587	inline assembler expression is:
				1588	</p>
				1589
				1590	<div class="doc_code">
				1591	<pre>
				1592	i32 (i32) asm "bswap $0", "=r,r"
				1593	</pre>
				1594	</div>
				1595
				1596	<p>
				1597	Inline assembler expressions may <b>only</b> be used as the callee operand of
				1598	a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we have:
				1599	</p>
				1600
				1601	<div class="doc_code">
				1602	<pre>
				1603	%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
				1604	</pre>
				1605	</div>
				1606
				1607	<p>
				1608	Inline asms with side effects not visible in the constraint list must be marked
				1609	as having side effects. This is done through the use of the
				1610	'<tt>sideeffect</tt>' keyword, like so:
				1611	</p>
				1612
				1613	<div class="doc_code">
				1614	<pre>
				1615	call void asm sideeffect "eieio", ""()
				1616	</pre>
				1617	</div>
				1618
				1619	<p>TODO: The format of the asm and constraints string still need to be
				1620	documented here. Constraints on what can be done (e.g. duplication, moving, etc
				1621	need to be documented).
				1622	</p>
				1623
				1624	</div>
				1625
				1626	<!-- *********************************************************************** -->
				1627	<div class="doc_section"> <a name="instref">Instruction Reference</a> </div>
				1628	<!-- *********************************************************************** -->
				1629
				1630	<div class="doc_text">
				1631
				1632	<p>The LLVM instruction set consists of several different
				1633	classifications of instructions: <a href="#terminators">terminator
				1634	instructions</a>, <a href="#binaryops">binary instructions</a>,
				1635	<a href="#bitwiseops">bitwise binary instructions</a>, <a
				1636	href="#memoryops">memory instructions</a>, and <a href="#otherops">other
				1637	instructions</a>.</p>
				1638
				1639	</div>
				1640
				1641	<!-- ======================================================================= -->
				1642	<div class="doc_subsection"> <a name="terminators">Terminator
				1643	Instructions</a> </div>
				1644
				1645	<div class="doc_text">
				1646
				1647	<p>As mentioned <a href="#functionstructure">previously</a>, every
				1648	basic block in a program ends with a "Terminator" instruction, which
				1649	indicates which block should be executed after the current block is
				1650	finished. These terminator instructions typically yield a '<tt>void</tt>'
				1651	value: they produce control flow, not values (the one exception being
				1652	the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p>
				1653	<p>There are six different terminator instructions: the '<a
				1654	href="#i_ret"><tt>ret</tt></a>' instruction, the '<a href="#i_br"><tt>br</tt></a>'
				1655	instruction, the '<a href="#i_switch"><tt>switch</tt></a>' instruction,
				1656	the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction, the '<a
				1657	href="#i_unwind"><tt>unwind</tt></a>' instruction, and the '<a
				1658	href="#i_unreachable"><tt>unreachable</tt></a>' instruction.</p>
				1659
				1660	</div>
				1661
				1662	<!-- _______________________________________________________________________ -->
				1663	<div class="doc_subsubsection"> <a name="i_ret">'<tt>ret</tt>'
				1664	Instruction</a> </div>
				1665	<div class="doc_text">
				1666	<h5>Syntax:</h5>
				1667	<pre> ret <type> <value> <i>; Return a value from a non-void function</i>
				1668	ret void <i>; Return from void function</i>
				1669	</pre>
				1670	<h5>Overview:</h5>
				1671	<p>The '<tt>ret</tt>' instruction is used to return control flow (and a
				1672	value) from a function back to the caller.</p>
				1673	<p>There are two forms of the '<tt>ret</tt>' instruction: one that
				1674	returns a value and then causes control flow, and one that just causes
				1675	control flow to occur.</p>
				1676	<h5>Arguments:</h5>
				1677	<p>The '<tt>ret</tt>' instruction may return any '<a
				1678	href="#t_firstclass">first class</a>' type. Notice that a function is
				1679	not <a href="#wellformed">well formed</a> if there exists a '<tt>ret</tt>'
				1680	instruction inside of the function that returns a value that does not
				1681	match the return type of the function.</p>
				1682	<h5>Semantics:</h5>
				1683	<p>When the '<tt>ret</tt>' instruction is executed, control flow
				1684	returns back to the calling function's context. If the caller is a "<a
				1685	href="#i_call"><tt>call</tt></a>" instruction, execution continues at
				1686	the instruction after the call. If the caller was an "<a
				1687	href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues
				1688	at the beginning of the "normal" destination block. If the instruction
				1689	returns a value, that value shall set the call or invoke instruction's
				1690	return value.</p>
				1691	<h5>Example:</h5>
				1692	<pre> ret i32 5 <i>; Return an integer value of 5</i>
				1693	ret void <i>; Return from a void function</i>
				1694	</pre>
				1695	</div>
				1696	<!-- _______________________________________________________________________ -->
				1697	<div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
				1698	<div class="doc_text">
				1699	<h5>Syntax:</h5>
				1700	<pre> br i1 <cond>, label <iftrue>, label <iffalse><br> br label <dest> <i>; Unconditional branch</i>
				1701	</pre>
				1702	<h5>Overview:</h5>
				1703	<p>The '<tt>br</tt>' instruction is used to cause control flow to
				1704	transfer to a different basic block in the current function. There are
				1705	two forms of this instruction, corresponding to a conditional branch
				1706	and an unconditional branch.</p>
				1707	<h5>Arguments:</h5>
				1708	<p>The conditional branch form of the '<tt>br</tt>' instruction takes a
				1709	single '<tt>i1</tt>' value and two '<tt>label</tt>' values. The
				1710	unconditional form of the '<tt>br</tt>' instruction takes a single
				1711	'<tt>label</tt>' value as a target.</p>
				1712	<h5>Semantics:</h5>
				1713	<p>Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>i1</tt>'
				1714	argument is evaluated. If the value is <tt>true</tt>, control flows
				1715	to the '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>,
				1716	control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p>
				1717	<h5>Example:</h5>
				1718	<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
				1719	href="#i_ret">ret</a> i32 1<br>IfUnequal:<br> <a href="#i_ret">ret</a> i32 0<br></pre>
				1720	</div>
				1721	<!-- _______________________________________________________________________ -->
				1722	<div class="doc_subsubsection">
				1723	<a name="i_switch">'<tt>switch</tt>' Instruction</a>
				1724	</div>
				1725
				1726	<div class="doc_text">
				1727	<h5>Syntax:</h5>
				1728
				1729	<pre>
				1730	switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
				1731	</pre>
				1732
				1733	<h5>Overview:</h5>
				1734
				1735	<p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of
				1736	several different places. It is a generalization of the '<tt>br</tt>'
				1737	instruction, allowing a branch to occur to one of many possible
				1738	destinations.</p>
				1739
				1740
				1741	<h5>Arguments:</h5>
				1742
				1743	<p>The '<tt>switch</tt>' instruction uses three parameters: an integer
				1744	comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination, and
				1745	an array of pairs of comparison value constants and '<tt>label</tt>'s. The
				1746	table is not allowed to contain duplicate constant entries.</p>
				1747
				1748	<h5>Semantics:</h5>
				1749
				1750	<p>The <tt>switch</tt> instruction specifies a table of values and
				1751	destinations. When the '<tt>switch</tt>' instruction is executed, this
				1752	table is searched for the given value. If the value is found, control flow is
				1753	transfered to the corresponding destination; otherwise, control flow is
				1754	transfered to the default destination.</p>
				1755
				1756	<h5>Implementation:</h5>
				1757
				1758	<p>Depending on properties of the target machine and the particular
				1759	<tt>switch</tt> instruction, this instruction may be code generated in different
				1760	ways. For example, it could be generated as a series of chained conditional
				1761	branches or with a lookup table.</p>
				1762
				1763	<h5>Example:</h5>
				1764
				1765	<pre>
				1766	<i>; Emulate a conditional br instruction</i>
				1767	%Val = <a href="#i_zext">zext</a> i1 %value to i32
				1768	switch i32 %Val, label %truedest [i32 0, label %falsedest ]
				1769
				1770	<i>; Emulate an unconditional br instruction</i>
				1771	switch i32 0, label %dest [ ]
				1772
				1773	<i>; Implement a jump table:</i>
				1774	switch i32 %val, label %otherwise [ i32 0, label %onzero
				1775	i32 1, label %onone
				1776	i32 2, label %ontwo ]
				1777	</pre>
				1778	</div>
				1779
				1780	<!-- _______________________________________________________________________ -->
				1781	<div class="doc_subsubsection">
				1782	<a name="i_invoke">'<tt>invoke</tt>' Instruction</a>
				1783	</div>
				1784
				1785	<div class="doc_text">
				1786
				1787	<h5>Syntax:</h5>
				1788
				1789	<pre>
				1790	<result> = invoke [<a href="#callingconv">cconv</a>] <ptr to function ty> %<function ptr val>(<function args>)
				1791	to label <normal label> unwind label <exception label>
				1792	</pre>
				1793
				1794	<h5>Overview:</h5>
				1795
				1796	<p>The '<tt>invoke</tt>' instruction causes control to transfer to a specified
				1797	function, with the possibility of control flow transfer to either the
				1798	'<tt>normal</tt>' label or the
				1799	'<tt>exception</tt>' label. If the callee function returns with the
				1800	"<tt><a href="#i_ret">ret</a></tt>" instruction, control flow will return to the
				1801	"normal" label. If the callee (or any indirect callees) returns with the "<a
				1802	href="#i_unwind"><tt>unwind</tt></a>" instruction, control is interrupted and
				1803	continued at the dynamically nearest "exception" label.</p>
				1804
				1805	<h5>Arguments:</h5>
				1806
				1807	<p>This instruction requires several arguments:</p>
				1808
				1809	<ol>
				1810	<li>
				1811	The optional "cconv" marker indicates which <a href="#callingconv">calling
				1812	convention</a> the call should use. If none is specified, the call defaults
				1813	to using C calling conventions.
				1814	</li>
				1815	<li>'<tt>ptr to function ty</tt>': shall be the signature of the pointer to
				1816	function value being invoked. In most cases, this is a direct function
				1817	invocation, but indirect <tt>invoke</tt>s are just as possible, branching off
				1818	an arbitrary pointer to function value.
				1819	</li>
				1820
				1821	<li>'<tt>function ptr val</tt>': An LLVM value containing a pointer to a
				1822	function to be invoked. </li>
				1823
				1824	<li>'<tt>function args</tt>': argument list whose types match the function
				1825	signature argument types. If the function signature indicates the function
				1826	accepts a variable number of arguments, the extra arguments can be
				1827	specified. </li>
				1828
				1829	<li>'<tt>normal label</tt>': the label reached when the called function
				1830	executes a '<tt><a href="#i_ret">ret</a></tt>' instruction. </li>
				1831
				1832	<li>'<tt>exception label</tt>': the label reached when a callee returns with
				1833	the <a href="#i_unwind"><tt>unwind</tt></a> instruction. </li>
				1834
				1835	</ol>
				1836
				1837	<h5>Semantics:</h5>
				1838
				1839	<p>This instruction is designed to operate as a standard '<tt><a
				1840	href="#i_call">call</a></tt>' instruction in most regards. The primary
				1841	difference is that it establishes an association with a label, which is used by
				1842	the runtime library to unwind the stack.</p>
				1843
				1844	<p>This instruction is used in languages with destructors to ensure that proper
				1845	cleanup is performed in the case of either a <tt>longjmp</tt> or a thrown
				1846	exception. Additionally, this is important for implementation of
				1847	'<tt>catch</tt>' clauses in high-level languages that support them.</p>
				1848
				1849	<h5>Example:</h5>
				1850	<pre>
				1851	%retval = invoke i32 %Test(i32 15) to label %Continue
				1852	unwind label %TestCleanup <i>; {i32}:retval set</i>
				1853	%retval = invoke <a href="#callingconv">coldcc</a> i32 %Test(i32 15) to label %Continue
				1854	unwind label %TestCleanup <i>; {i32}:retval set</i>
				1855	</pre>
				1856	</div>
				1857
				1858
				1859	<!-- _______________________________________________________________________ -->
				1860
				1861	<div class="doc_subsubsection"> <a name="i_unwind">'<tt>unwind</tt>'
				1862	Instruction</a> </div>
				1863
				1864	<div class="doc_text">
				1865
				1866	<h5>Syntax:</h5>
				1867	<pre>
				1868	unwind
				1869	</pre>
				1870
				1871	<h5>Overview:</h5>
				1872
				1873	<p>The '<tt>unwind</tt>' instruction unwinds the stack, continuing control flow
				1874	at the first callee in the dynamic call stack which used an <a
				1875	href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call. This is
				1876	primarily used to implement exception handling.</p>
				1877
				1878	<h5>Semantics:</h5>
				1879
				1880	<p>The '<tt>unwind</tt>' intrinsic causes execution of the current function to
				1881	immediately halt. The dynamic call stack is then searched for the first <a
				1882	href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack. Once found,
				1883	execution continues at the "exceptional" destination block specified by the
				1884	<tt>invoke</tt> instruction. If there is no <tt>invoke</tt> instruction in the
				1885	dynamic call chain, undefined behavior results.</p>
				1886	</div>
				1887
				1888	<!-- _______________________________________________________________________ -->
				1889
				1890	<div class="doc_subsubsection"> <a name="i_unreachable">'<tt>unreachable</tt>'
				1891	Instruction</a> </div>
				1892
				1893	<div class="doc_text">
				1894
				1895	<h5>Syntax:</h5>
				1896	<pre>
				1897	unreachable
				1898	</pre>
				1899
				1900	<h5>Overview:</h5>
				1901
				1902	<p>The '<tt>unreachable</tt>' instruction has no defined semantics. This
				1903	instruction is used to inform the optimizer that a particular portion of the
				1904	code is not reachable. This can be used to indicate that the code after a
				1905	no-return function cannot be reached, and other facts.</p>
				1906
				1907	<h5>Semantics:</h5>
				1908
				1909	<p>The '<tt>unreachable</tt>' instruction has no defined semantics.</p>
				1910	</div>
				1911
				1912
				1913
				1914	<!-- ======================================================================= -->
				1915	<div class="doc_subsection"> <a name="binaryops">Binary Operations</a> </div>
				1916	<div class="doc_text">
				1917	<p>Binary operators are used to do most of the computation in a
				1918	program. They require two operands, execute an operation on them, and
				1919	produce a single value. The operands might represent
				1920	multiple data, as is the case with the <a href="#t_vector">vector</a> data type.
				1921	The result value of a binary operator is not
				1922	necessarily the same type as its operands.</p>
				1923	<p>There are several different binary operators:</p>
				1924	</div>
				1925	<!-- _______________________________________________________________________ -->
				1926	<div class="doc_subsubsection"> <a name="i_add">'<tt>add</tt>'
				1927	Instruction</a> </div>
				1928	<div class="doc_text">
				1929	<h5>Syntax:</h5>
				1930	<pre> <result> = add <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				1931	</pre>
				1932	<h5>Overview:</h5>
				1933	<p>The '<tt>add</tt>' instruction returns the sum of its two operands.</p>
				1934	<h5>Arguments:</h5>
				1935	<p>The two arguments to the '<tt>add</tt>' instruction must be either <a
				1936	href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> values.
				1937	This instruction can also take <a href="#t_vector">vector</a> versions of the values.
				1938	Both arguments must have identical types.</p>
				1939	<h5>Semantics:</h5>
				1940	<p>The value produced is the integer or floating point sum of the two
				1941	operands.</p>
				1942	<h5>Example:</h5>
				1943	<pre> <result> = add i32 4, %var <i>; yields {i32}:result = 4 + %var</i>
				1944	</pre>
				1945	</div>
				1946	<!-- _______________________________________________________________________ -->
				1947	<div class="doc_subsubsection"> <a name="i_sub">'<tt>sub</tt>'
				1948	Instruction</a> </div>
				1949	<div class="doc_text">
				1950	<h5>Syntax:</h5>
				1951	<pre> <result> = sub <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				1952	</pre>
				1953	<h5>Overview:</h5>
				1954	<p>The '<tt>sub</tt>' instruction returns the difference of its two
				1955	operands.</p>
				1956	<p>Note that the '<tt>sub</tt>' instruction is used to represent the '<tt>neg</tt>'
				1957	instruction present in most other intermediate representations.</p>
				1958	<h5>Arguments:</h5>
				1959	<p>The two arguments to the '<tt>sub</tt>' instruction must be either <a
				1960	href="#t_integer">integer</a> or <a href="#t_floating">floating point</a>
				1961	values.
				1962	This instruction can also take <a href="#t_vector">vector</a> versions of the values.
				1963	Both arguments must have identical types.</p>
				1964	<h5>Semantics:</h5>
				1965	<p>The value produced is the integer or floating point difference of
				1966	the two operands.</p>
				1967	<h5>Example:</h5>
				1968	<pre>
				1969	<result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i>
				1970	<result> = sub i32 0, %val <i>; yields {i32}:result = -%var</i>
				1971	</pre>
				1972	</div>
				1973	<!-- _______________________________________________________________________ -->
				1974	<div class="doc_subsubsection"> <a name="i_mul">'<tt>mul</tt>'
				1975	Instruction</a> </div>
				1976	<div class="doc_text">
				1977	<h5>Syntax:</h5>
				1978	<pre> <result> = mul <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				1979	</pre>
				1980	<h5>Overview:</h5>
				1981	<p>The '<tt>mul</tt>' instruction returns the product of its two
				1982	operands.</p>
				1983	<h5>Arguments:</h5>
				1984	<p>The two arguments to the '<tt>mul</tt>' instruction must be either <a
				1985	href="#t_integer">integer</a> or <a href="#t_floating">floating point</a>
				1986	values.
				1987	This instruction can also take <a href="#t_vector">vector</a> versions of the values.
				1988	Both arguments must have identical types.</p>
				1989	<h5>Semantics:</h5>
				1990	<p>The value produced is the integer or floating point product of the
				1991	two operands.</p>
				1992	<p>Because the operands are the same width, the result of an integer
				1993	multiplication is the same whether the operands should be deemed unsigned or
				1994	signed.</p>
				1995	<h5>Example:</h5>
				1996	<pre> <result> = mul i32 4, %var <i>; yields {i32}:result = 4 * %var</i>
				1997	</pre>
				1998	</div>
				1999	<!-- _______________________________________________________________________ -->
				2000	<div class="doc_subsubsection"> <a name="i_udiv">'<tt>udiv</tt>' Instruction
				2001	</a></div>
				2002	<div class="doc_text">
				2003	<h5>Syntax:</h5>
				2004	<pre> <result> = udiv <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2005	</pre>
				2006	<h5>Overview:</h5>
				2007	<p>The '<tt>udiv</tt>' instruction returns the quotient of its two
				2008	operands.</p>
				2009	<h5>Arguments:</h5>
				2010	<p>The two arguments to the '<tt>udiv</tt>' instruction must be
				2011	<a href="#t_integer">integer</a> values. Both arguments must have identical
				2012	types. This instruction can also take <a href="#t_vector">vector</a> versions
				2013	of the values in which case the elements must be integers.</p>
				2014	<h5>Semantics:</h5>
				2015	<p>The value produced is the unsigned integer quotient of the two operands. This
				2016	instruction always performs an unsigned division operation, regardless of
				2017	whether the arguments are unsigned or not.</p>
				2018	<h5>Example:</h5>
				2019	<pre> <result> = udiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
				2020	</pre>
				2021	</div>
				2022	<!-- _______________________________________________________________________ -->
				2023	<div class="doc_subsubsection"> <a name="i_sdiv">'<tt>sdiv</tt>' Instruction
				2024	</a> </div>
				2025	<div class="doc_text">
				2026	<h5>Syntax:</h5>
				2027	<pre> <result> = sdiv <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2028	</pre>
				2029	<h5>Overview:</h5>
				2030	<p>The '<tt>sdiv</tt>' instruction returns the quotient of its two
				2031	operands.</p>
				2032	<h5>Arguments:</h5>
				2033	<p>The two arguments to the '<tt>sdiv</tt>' instruction must be
				2034	<a href="#t_integer">integer</a> values. Both arguments must have identical
				2035	types. This instruction can also take <a href="#t_vector">vector</a> versions
				2036	of the values in which case the elements must be integers.</p>
				2037	<h5>Semantics:</h5>
				2038	<p>The value produced is the signed integer quotient of the two operands. This
				2039	instruction always performs a signed division operation, regardless of whether
				2040	the arguments are signed or not.</p>
				2041	<h5>Example:</h5>
				2042	<pre> <result> = sdiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
				2043	</pre>
				2044	</div>
				2045	<!-- _______________________________________________________________________ -->
				2046	<div class="doc_subsubsection"> <a name="i_fdiv">'<tt>fdiv</tt>'
				2047	Instruction</a> </div>
				2048	<div class="doc_text">
				2049	<h5>Syntax:</h5>
				2050	<pre> <result> = fdiv <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2051	</pre>
				2052	<h5>Overview:</h5>
				2053	<p>The '<tt>fdiv</tt>' instruction returns the quotient of its two
				2054	operands.</p>
				2055	<h5>Arguments:</h5>
				2056	<p>The two arguments to the '<tt>fdiv</tt>' instruction must be
				2057	<a href="#t_floating">floating point</a> values. Both arguments must have
				2058	identical types. This instruction can also take <a href="#t_vector">vector</a>
				2059	versions of floating point values.</p>
				2060	<h5>Semantics:</h5>
				2061	<p>The value produced is the floating point quotient of the two operands.</p>
				2062	<h5>Example:</h5>
				2063	<pre> <result> = fdiv float 4.0, %var <i>; yields {float}:result = 4.0 / %var</i>
				2064	</pre>
				2065	</div>
				2066	<!-- _______________________________________________________________________ -->
				2067	<div class="doc_subsubsection"> <a name="i_urem">'<tt>urem</tt>' Instruction</a>
				2068	</div>
				2069	<div class="doc_text">
				2070	<h5>Syntax:</h5>
				2071	<pre> <result> = urem <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2072	</pre>
				2073	<h5>Overview:</h5>
				2074	<p>The '<tt>urem</tt>' instruction returns the remainder from the
				2075	unsigned division of its two arguments.</p>
				2076	<h5>Arguments:</h5>
				2077	<p>The two arguments to the '<tt>urem</tt>' instruction must be
				2078	<a href="#t_integer">integer</a> values. Both arguments must have identical
				2079	types.</p>
				2080	<h5>Semantics:</h5>
				2081	<p>This instruction returns the unsigned integer <i>remainder</i> of a division.
				2082	This instruction always performs an unsigned division to get the remainder,
				2083	regardless of whether the arguments are unsigned or not.</p>
				2084	<h5>Example:</h5>
				2085	<pre> <result> = urem i32 4, %var <i>; yields {i32}:result = 4 % %var</i>
				2086	</pre>
				2087
				2088	</div>
				2089	<!-- _______________________________________________________________________ -->
				2090	<div class="doc_subsubsection"> <a name="i_srem">'<tt>srem</tt>'
				2091	Instruction</a> </div>
				2092	<div class="doc_text">
				2093	<h5>Syntax:</h5>
				2094	<pre> <result> = srem <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2095	</pre>
				2096	<h5>Overview:</h5>
				2097	<p>The '<tt>srem</tt>' instruction returns the remainder from the
				2098	signed division of its two operands.</p>
				2099	<h5>Arguments:</h5>
				2100	<p>The two arguments to the '<tt>srem</tt>' instruction must be
				2101	<a href="#t_integer">integer</a> values. Both arguments must have identical
				2102	types.</p>
				2103	<h5>Semantics:</h5>
				2104	<p>This instruction returns the <i>remainder</i> of a division (where the result
				2105	has the same sign as the dividend, <tt>var1</tt>), not the <i>modulo</i>
				2106	operator (where the result has the same sign as the divisor, <tt>var2</tt>) of
				2107	a value. For more information about the difference, see <a
				2108	href="http://mathforum.org/dr.math/problems/anne.4.28.99.html">The
				2109	Math Forum</a>. For a table of how this is implemented in various languages,
				2110	please see <a href="http://en.wikipedia.org/wiki/Modulo_operation">
				2111	Wikipedia: modulo operation</a>.</p>
				2112	<h5>Example:</h5>
				2113	<pre> <result> = srem i32 4, %var <i>; yields {i32}:result = 4 % %var</i>
				2114	</pre>
				2115
				2116	</div>
				2117	<!-- _______________________________________________________________________ -->
				2118	<div class="doc_subsubsection"> <a name="i_frem">'<tt>frem</tt>'
				2119	Instruction</a> </div>
				2120	<div class="doc_text">
				2121	<h5>Syntax:</h5>
				2122	<pre> <result> = frem <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2123	</pre>
				2124	<h5>Overview:</h5>
				2125	<p>The '<tt>frem</tt>' instruction returns the remainder from the
				2126	division of its two operands.</p>
				2127	<h5>Arguments:</h5>
				2128	<p>The two arguments to the '<tt>frem</tt>' instruction must be
				2129	<a href="#t_floating">floating point</a> values. Both arguments must have
				2130	identical types.</p>
				2131	<h5>Semantics:</h5>
				2132	<p>This instruction returns the <i>remainder</i> of a division.</p>
				2133	<h5>Example:</h5>
				2134	<pre> <result> = frem float 4.0, %var <i>; yields {float}:result = 4.0 % %var</i>
				2135	</pre>
				2136	</div>
				2137
				2138	<!-- ======================================================================= -->
				2139	<div class="doc_subsection"> <a name="bitwiseops">Bitwise Binary
				2140	Operations</a> </div>
				2141	<div class="doc_text">
				2142	<p>Bitwise binary operators are used to do various forms of
				2143	bit-twiddling in a program. They are generally very efficient
				2144	instructions and can commonly be strength reduced from other
				2145	instructions. They require two operands, execute an operation on them,
				2146	and produce a single value. The resulting value of the bitwise binary
				2147	operators is always the same type as its first operand.</p>
				2148	</div>
				2149
				2150	<!-- _______________________________________________________________________ -->
				2151	<div class="doc_subsubsection"> <a name="i_shl">'<tt>shl</tt>'
				2152	Instruction</a> </div>
				2153	<div class="doc_text">
				2154	<h5>Syntax:</h5>
				2155	<pre> <result> = shl <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2156	</pre>
				2157	<h5>Overview:</h5>
				2158	<p>The '<tt>shl</tt>' instruction returns the first operand shifted to
				2159	the left a specified number of bits.</p>
				2160	<h5>Arguments:</h5>
				2161	<p>Both arguments to the '<tt>shl</tt>' instruction must be the same <a
				2162	href="#t_integer">integer</a> type.</p>
				2163	<h5>Semantics:</h5>
				2164	<p>The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>.</p>
				2165	<h5>Example:</h5><pre>
				2166	<result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i>
				2167	<result> = shl i32 4, 2 <i>; yields {i32}: 16</i>
				2168	<result> = shl i32 1, 10 <i>; yields {i32}: 1024</i>
				2169	</pre>
				2170	</div>
				2171	<!-- _______________________________________________________________________ -->
				2172	<div class="doc_subsubsection"> <a name="i_lshr">'<tt>lshr</tt>'
				2173	Instruction</a> </div>
				2174	<div class="doc_text">
				2175	<h5>Syntax:</h5>
				2176	<pre> <result> = lshr <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2177	</pre>
				2178
				2179	<h5>Overview:</h5>
				2180	<p>The '<tt>lshr</tt>' instruction (logical shift right) returns the first
				2181	operand shifted to the right a specified number of bits with zero fill.</p>
				2182
				2183	<h5>Arguments:</h5>
				2184	<p>Both arguments to the '<tt>lshr</tt>' instruction must be the same
				2185	<a href="#t_integer">integer</a> type.</p>
				2186
				2187	<h5>Semantics:</h5>
				2188	<p>This instruction always performs a logical shift right operation. The most
				2189	significant bits of the result will be filled with zero bits after the
				2190	shift.</p>
				2191
				2192	<h5>Example:</h5>
				2193	<pre>
				2194	<result> = lshr i32 4, 1 <i>; yields {i32}:result = 2</i>
				2195	<result> = lshr i32 4, 2 <i>; yields {i32}:result = 1</i>
				2196	<result> = lshr i8 4, 3 <i>; yields {i8}:result = 0</i>
				2197	<result> = lshr i8 -2, 1 <i>; yields {i8}:result = 0x7FFFFFFF </i>
				2198	</pre>
				2199	</div>
				2200
				2201	<!-- _______________________________________________________________________ -->
				2202	<div class="doc_subsubsection"> <a name="i_ashr">'<tt>ashr</tt>'
				2203	Instruction</a> </div>
				2204	<div class="doc_text">
				2205
				2206	<h5>Syntax:</h5>
				2207	<pre> <result> = ashr <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2208	</pre>
				2209
				2210	<h5>Overview:</h5>
				2211	<p>The '<tt>ashr</tt>' instruction (arithmetic shift right) returns the first
				2212	operand shifted to the right a specified number of bits with sign extension.</p>
				2213
				2214	<h5>Arguments:</h5>
				2215	<p>Both arguments to the '<tt>ashr</tt>' instruction must be the same
				2216	<a href="#t_integer">integer</a> type.</p>
				2217
				2218	<h5>Semantics:</h5>
				2219	<p>This instruction always performs an arithmetic shift right operation,
				2220	The most significant bits of the result will be filled with the sign bit
				2221	of <tt>var1</tt>.</p>
				2222
				2223	<h5>Example:</h5>
				2224	<pre>
				2225	<result> = ashr i32 4, 1 <i>; yields {i32}:result = 2</i>
				2226	<result> = ashr i32 4, 2 <i>; yields {i32}:result = 1</i>
				2227	<result> = ashr i8 4, 3 <i>; yields {i8}:result = 0</i>
				2228	<result> = ashr i8 -2, 1 <i>; yields {i8}:result = -1</i>
				2229	</pre>
				2230	</div>
				2231
				2232	<!-- _______________________________________________________________________ -->
				2233	<div class="doc_subsubsection"> <a name="i_and">'<tt>and</tt>'
				2234	Instruction</a> </div>
				2235	<div class="doc_text">
				2236	<h5>Syntax:</h5>
				2237	<pre> <result> = and <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2238	</pre>
				2239	<h5>Overview:</h5>
				2240	<p>The '<tt>and</tt>' instruction returns the bitwise logical and of
				2241	its two operands.</p>
				2242	<h5>Arguments:</h5>
				2243	<p>The two arguments to the '<tt>and</tt>' instruction must be <a
				2244	href="#t_integer">integer</a> values. Both arguments must have
				2245	identical types.</p>
				2246	<h5>Semantics:</h5>
				2247	<p>The truth table used for the '<tt>and</tt>' instruction is:</p>
				2248	<p> </p>
				2249	<div style="align: center">
				2250	<table border="1" cellspacing="0" cellpadding="4">
				2251	<tbody>
				2252	<tr>
				2253	<td>In0</td>
				2254	<td>In1</td>
				2255	<td>Out</td>
				2256	</tr>
				2257	<tr>
				2258	<td>0</td>
				2259	<td>0</td>
				2260	<td>0</td>
				2261	</tr>
				2262	<tr>
				2263	<td>0</td>
				2264	<td>1</td>
				2265	<td>0</td>
				2266	</tr>
				2267	<tr>
				2268	<td>1</td>
				2269	<td>0</td>
				2270	<td>0</td>
				2271	</tr>
				2272	<tr>
				2273	<td>1</td>
				2274	<td>1</td>
				2275	<td>1</td>
				2276	</tr>
				2277	</tbody>
				2278	</table>
				2279	</div>
				2280	<h5>Example:</h5>
				2281	<pre> <result> = and i32 4, %var <i>; yields {i32}:result = 4 & %var</i>
				2282	<result> = and i32 15, 40 <i>; yields {i32}:result = 8</i>
				2283	<result> = and i32 4, 8 <i>; yields {i32}:result = 0</i>
				2284	</pre>
				2285	</div>
				2286	<!-- _______________________________________________________________________ -->
				2287	<div class="doc_subsubsection"> <a name="i_or">'<tt>or</tt>' Instruction</a> </div>
				2288	<div class="doc_text">
				2289	<h5>Syntax:</h5>
				2290	<pre> <result> = or <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2291	</pre>
				2292	<h5>Overview:</h5>
				2293	<p>The '<tt>or</tt>' instruction returns the bitwise logical inclusive
				2294	or of its two operands.</p>
				2295	<h5>Arguments:</h5>
				2296	<p>The two arguments to the '<tt>or</tt>' instruction must be <a
				2297	href="#t_integer">integer</a> values. Both arguments must have
				2298	identical types.</p>
				2299	<h5>Semantics:</h5>
				2300	<p>The truth table used for the '<tt>or</tt>' instruction is:</p>
				2301	<p> </p>
				2302	<div style="align: center">
				2303	<table border="1" cellspacing="0" cellpadding="4">
				2304	<tbody>
				2305	<tr>
				2306	<td>In0</td>
				2307	<td>In1</td>
				2308	<td>Out</td>
				2309	</tr>
				2310	<tr>
				2311	<td>0</td>
				2312	<td>0</td>
				2313	<td>0</td>
				2314	</tr>
				2315	<tr>
				2316	<td>0</td>
				2317	<td>1</td>
				2318	<td>1</td>
				2319	</tr>
				2320	<tr>
				2321	<td>1</td>
				2322	<td>0</td>
				2323	<td>1</td>
				2324	</tr>
				2325	<tr>
				2326	<td>1</td>
				2327	<td>1</td>
				2328	<td>1</td>
				2329	</tr>
				2330	</tbody>
				2331	</table>
				2332	</div>
				2333	<h5>Example:</h5>
				2334	<pre> <result> = or i32 4, %var <i>; yields {i32}:result = 4 \| %var</i>
				2335	<result> = or i32 15, 40 <i>; yields {i32}:result = 47</i>
				2336	<result> = or i32 4, 8 <i>; yields {i32}:result = 12</i>
				2337	</pre>
				2338	</div>
				2339	<!-- _______________________________________________________________________ -->
				2340	<div class="doc_subsubsection"> <a name="i_xor">'<tt>xor</tt>'
				2341	Instruction</a> </div>
				2342	<div class="doc_text">
				2343	<h5>Syntax:</h5>
				2344	<pre> <result> = xor <ty> <var1>, <var2> <i>; yields {ty}:result</i>
				2345	</pre>
				2346	<h5>Overview:</h5>
				2347	<p>The '<tt>xor</tt>' instruction returns the bitwise logical exclusive
				2348	or of its two operands. The <tt>xor</tt> is used to implement the
				2349	"one's complement" operation, which is the "~" operator in C.</p>
				2350	<h5>Arguments:</h5>
				2351	<p>The two arguments to the '<tt>xor</tt>' instruction must be <a
				2352	href="#t_integer">integer</a> values. Both arguments must have
				2353	identical types.</p>
				2354	<h5>Semantics:</h5>
				2355	<p>The truth table used for the '<tt>xor</tt>' instruction is:</p>
				2356	<p> </p>
				2357	<div style="align: center">
				2358	<table border="1" cellspacing="0" cellpadding="4">
				2359	<tbody>
				2360	<tr>
				2361	<td>In0</td>
				2362	<td>In1</td>
				2363	<td>Out</td>
				2364	</tr>
				2365	<tr>
				2366	<td>0</td>
				2367	<td>0</td>
				2368	<td>0</td>
				2369	</tr>
				2370	<tr>
				2371	<td>0</td>
				2372	<td>1</td>
				2373	<td>1</td>
				2374	</tr>
				2375	<tr>
				2376	<td>1</td>
				2377	<td>0</td>
				2378	<td>1</td>
				2379	</tr>
				2380	<tr>
				2381	<td>1</td>
				2382	<td>1</td>
				2383	<td>0</td>
				2384	</tr>
				2385	</tbody>
				2386	</table>
				2387	</div>
				2388	<p> </p>
				2389	<h5>Example:</h5>
				2390	<pre> <result> = xor i32 4, %var <i>; yields {i32}:result = 4 ^ %var</i>
				2391	<result> = xor i32 15, 40 <i>; yields {i32}:result = 39</i>
				2392	<result> = xor i32 4, 8 <i>; yields {i32}:result = 12</i>
				2393	<result> = xor i32 %V, -1 <i>; yields {i32}:result = ~%V</i>
				2394	</pre>
				2395	</div>
				2396
				2397	<!-- ======================================================================= -->
				2398	<div class="doc_subsection">
				2399	<a name="vectorops">Vector Operations</a>
				2400	</div>
				2401
				2402	<div class="doc_text">
				2403
				2404	<p>LLVM supports several instructions to represent vector operations in a
				2405	target-independent manner. These instructions cover the element-access and
				2406	vector-specific operations needed to process vectors effectively. While LLVM
				2407	does directly support these vector operations, many sophisticated algorithms
				2408	will want to use target-specific intrinsics to take full advantage of a specific
				2409	target.</p>
				2410
				2411	</div>
				2412
				2413	<!-- _______________________________________________________________________ -->
				2414	<div class="doc_subsubsection">
				2415	<a name="i_extractelement">'<tt>extractelement</tt>' Instruction</a>
				2416	</div>
				2417
				2418	<div class="doc_text">
				2419
				2420	<h5>Syntax:</h5>
				2421
				2422	<pre>
				2423	<result> = extractelement <n x <ty>> <val>, i32 <idx> <i>; yields <ty></i>
				2424	</pre>
				2425
				2426	<h5>Overview:</h5>
				2427
				2428	<p>
				2429	The '<tt>extractelement</tt>' instruction extracts a single scalar
				2430	element from a vector at a specified index.
				2431	</p>
				2432
				2433
				2434	<h5>Arguments:</h5>
				2435
				2436	<p>
				2437	The first operand of an '<tt>extractelement</tt>' instruction is a
				2438	value of <a href="#t_vector">vector</a> type. The second operand is
				2439	an index indicating the position from which to extract the element.
				2440	The index may be a variable.</p>
				2441
				2442	<h5>Semantics:</h5>
				2443
				2444	<p>
				2445	The result is a scalar of the same type as the element type of
				2446	<tt>val</tt>. Its value is the value at position <tt>idx</tt> of
				2447	<tt>val</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the
				2448	results are undefined.
				2449	</p>
				2450
				2451	<h5>Example:</h5>
				2452
				2453	<pre>
				2454	%result = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i>
				2455	</pre>
				2456	</div>
				2457
				2458
				2459	<!-- _______________________________________________________________________ -->
				2460	<div class="doc_subsubsection">
				2461	<a name="i_insertelement">'<tt>insertelement</tt>' Instruction</a>
				2462	</div>
				2463
				2464	<div class="doc_text">
				2465
				2466	<h5>Syntax:</h5>
				2467
				2468	<pre>
				2469	<result> = insertelement <n x <ty>> <val>, <ty> <elt&gt, i32 <idx> <i>; yields <n x <ty>></i>
				2470	</pre>
				2471
				2472	<h5>Overview:</h5>
				2473
				2474	<p>
				2475	The '<tt>insertelement</tt>' instruction inserts a scalar
				2476	element into a vector at a specified index.
				2477	</p>
				2478
				2479
				2480	<h5>Arguments:</h5>
				2481
				2482	<p>
				2483	The first operand of an '<tt>insertelement</tt>' instruction is a
				2484	value of <a href="#t_vector">vector</a> type. The second operand is a
				2485	scalar value whose type must equal the element type of the first
				2486	operand. The third operand is an index indicating the position at
				2487	which to insert the value. The index may be a variable.</p>
				2488
				2489	<h5>Semantics:</h5>
				2490
				2491	<p>
				2492	The result is a vector of the same type as <tt>val</tt>. Its
				2493	element values are those of <tt>val</tt> except at position
				2494	<tt>idx</tt>, where it gets the value <tt>elt</tt>. If <tt>idx</tt>
				2495	exceeds the length of <tt>val</tt>, the results are undefined.
				2496	</p>
				2497
				2498	<h5>Example:</h5>
				2499
				2500	<pre>
				2501	%result = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i>
				2502	</pre>
				2503	</div>
				2504
				2505	<!-- _______________________________________________________________________ -->
				2506	<div class="doc_subsubsection">
				2507	<a name="i_shufflevector">'<tt>shufflevector</tt>' Instruction</a>
				2508	</div>
				2509
				2510	<div class="doc_text">
				2511
				2512	<h5>Syntax:</h5>
				2513
				2514	<pre>
				2515	<result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <n x i32> <mask> <i>; yields <n x <ty>></i>
				2516	</pre>
				2517
				2518	<h5>Overview:</h5>
				2519
				2520	<p>
				2521	The '<tt>shufflevector</tt>' instruction constructs a permutation of elements
				2522	from two input vectors, returning a vector of the same type.
				2523	</p>
				2524
				2525	<h5>Arguments:</h5>
				2526
				2527	<p>
				2528	The first two operands of a '<tt>shufflevector</tt>' instruction are vectors
				2529	with types that match each other and types that match the result of the
				2530	instruction. The third argument is a shuffle mask, which has the same number
				2531	of elements as the other vector type, but whose element type is always 'i32'.
				2532	</p>
				2533
				2534	<p>
				2535	The shuffle mask operand is required to be a constant vector with either
				2536	constant integer or undef values.
				2537	</p>
				2538
				2539	<h5>Semantics:</h5>
				2540
				2541	<p>
				2542	The elements of the two input vectors are numbered from left to right across
				2543	both of the vectors. The shuffle mask operand specifies, for each element of
				2544	the result vector, which element of the two input registers the result element
				2545	gets. The element selector may be undef (meaning "don't care") and the second
				2546	operand may be undef if performing a shuffle from only one vector.
				2547	</p>
				2548
				2549	<h5>Example:</h5>
				2550
				2551	<pre>
				2552	%result = shufflevector <4 x i32> %v1, <4 x i32> %v2,
				2553	<4 x i32> <i32 0, i32 4, i32 1, i32 5> <i>; yields <4 x i32></i>
				2554	%result = shufflevector <4 x i32> %v1, <4 x i32> undef,
				2555	<4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle.
				2556	</pre>
				2557	</div>
				2558
				2559
				2560	<!-- ======================================================================= -->
				2561	<div class="doc_subsection">
				2562	<a name="memoryops">Memory Access and Addressing Operations</a>
				2563	</div>
				2564
				2565	<div class="doc_text">
				2566
				2567	<p>A key design point of an SSA-based representation is how it
				2568	represents memory. In LLVM, no memory locations are in SSA form, which
				2569	makes things very simple. This section describes how to read, write,
				2570	allocate, and free memory in LLVM.</p>
				2571
				2572	</div>
				2573
				2574	<!-- _______________________________________________________________________ -->
				2575	<div class="doc_subsubsection">
				2576	<a name="i_malloc">'<tt>malloc</tt>' Instruction</a>
				2577	</div>
				2578
				2579	<div class="doc_text">
				2580
				2581	<h5>Syntax:</h5>
				2582
				2583	<pre>
				2584	<result> = malloc <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
				2585	</pre>
				2586
				2587	<h5>Overview:</h5>
				2588
				2589	<p>The '<tt>malloc</tt>' instruction allocates memory from the system
				2590	heap and returns a pointer to it.</p>
				2591
				2592	<h5>Arguments:</h5>
				2593
				2594	<p>The '<tt>malloc</tt>' instruction allocates
				2595	<tt>sizeof(<type>)*NumElements</tt>
				2596	bytes of memory from the operating system and returns a pointer of the
				2597	appropriate type to the program. If "NumElements" is specified, it is the
				2598	number of elements allocated. If an alignment is specified, the value result
				2599	of the allocation is guaranteed to be aligned to at least that boundary. If
				2600	not specified, or if zero, the target can choose to align the allocation on any
				2601	convenient boundary.</p>
				2602
				2603	<p>'<tt>type</tt>' must be a sized type.</p>
				2604
				2605	<h5>Semantics:</h5>
				2606
				2607	<p>Memory is allocated using the system "<tt>malloc</tt>" function, and
				2608	a pointer is returned.</p>
				2609
				2610	<h5>Example:</h5>
				2611
				2612	<pre>
				2613	%array = malloc [4 x i8 ] <i>; yields {[%4 x i8]*}:array</i>
				2614
				2615	%size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i>
				2616	%array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i>
				2617	%array2 = malloc [12 x i8], i32 %size <i>; yields {[12 x i8]*}:array2</i>
				2618	%array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i>
				2619	%array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i>
				2620	</pre>
				2621	</div>
				2622
				2623	<!-- _______________________________________________________________________ -->
				2624	<div class="doc_subsubsection">
				2625	<a name="i_free">'<tt>free</tt>' Instruction</a>
				2626	</div>
				2627
				2628	<div class="doc_text">
				2629
				2630	<h5>Syntax:</h5>
				2631
				2632	<pre>
				2633	free <type> <value> <i>; yields {void}</i>
				2634	</pre>
				2635
				2636	<h5>Overview:</h5>
				2637
				2638	<p>The '<tt>free</tt>' instruction returns memory back to the unused
				2639	memory heap to be reallocated in the future.</p>
				2640
				2641	<h5>Arguments:</h5>
				2642
				2643	<p>'<tt>value</tt>' shall be a pointer value that points to a value
				2644	that was allocated with the '<tt><a href="#i_malloc">malloc</a></tt>'
				2645	instruction.</p>
				2646
				2647	<h5>Semantics:</h5>
				2648
				2649	<p>Access to the memory pointed to by the pointer is no longer defined
				2650	after this instruction executes.</p>
				2651
				2652	<h5>Example:</h5>
				2653
				2654	<pre>
				2655	%array = <a href="#i_malloc">malloc</a> [4 x i8] <i>; yields {[4 x i8]*}:array</i>
				2656	free [4 x i8]* %array
				2657	</pre>
				2658	</div>
				2659
				2660	<!-- _______________________________________________________________________ -->
				2661	<div class="doc_subsubsection">
				2662	<a name="i_alloca">'<tt>alloca</tt>' Instruction</a>
				2663	</div>
				2664
				2665	<div class="doc_text">
				2666
				2667	<h5>Syntax:</h5>
				2668
				2669	<pre>
				2670	<result> = alloca <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
				2671	</pre>
				2672
				2673	<h5>Overview:</h5>
				2674
				2675	<p>The '<tt>alloca</tt>' instruction allocates memory on the stack frame of the
				2676	currently executing function, to be automatically released when this function
				2677	returns to its caller.</p>
				2678
				2679	<h5>Arguments:</h5>
				2680
				2681	<p>The '<tt>alloca</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt>
				2682	bytes of memory on the runtime stack, returning a pointer of the
				2683	appropriate type to the program. If "NumElements" is specified, it is the
				2684	number of elements allocated. If an alignment is specified, the value result
				2685	of the allocation is guaranteed to be aligned to at least that boundary. If
				2686	not specified, or if zero, the target can choose to align the allocation on any
				2687	convenient boundary.</p>
				2688
				2689	<p>'<tt>type</tt>' may be any sized type.</p>
				2690
				2691	<h5>Semantics:</h5>
				2692
				2693	<p>Memory is allocated; a pointer is returned. '<tt>alloca</tt>'d
				2694	memory is automatically released when the function returns. The '<tt>alloca</tt>'
				2695	instruction is commonly used to represent automatic variables that must
				2696	have an address available. When the function returns (either with the <tt><a
				2697	href="#i_ret">ret</a></tt> or <tt><a href="#i_unwind">unwind</a></tt>
				2698	instructions), the memory is reclaimed.</p>
				2699
				2700	<h5>Example:</h5>
				2701
				2702	<pre>
				2703	%ptr = alloca i32 <i>; yields {i32*}:ptr</i>
				2704	%ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
				2705	%ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
				2706	%ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i>
				2707	</pre>
				2708	</div>
				2709
				2710	<!-- _______________________________________________________________________ -->
				2711	<div class="doc_subsubsection"> <a name="i_load">'<tt>load</tt>'
				2712	Instruction</a> </div>
				2713	<div class="doc_text">
				2714	<h5>Syntax:</h5>
				2715	<pre> <result> = load <ty>* <pointer>[, align <alignment>]<br> <result> = volatile load <ty>* <pointer>[, align <alignment>]<br></pre>
				2716	<h5>Overview:</h5>
				2717	<p>The '<tt>load</tt>' instruction is used to read from memory.</p>
				2718	<h5>Arguments:</h5>
				2719	<p>The argument to the '<tt>load</tt>' instruction specifies the memory
				2720	address from which to load. The pointer must point to a <a
				2721	href="#t_firstclass">first class</a> type. If the <tt>load</tt> is
				2722	marked as <tt>volatile</tt>, then the optimizer is not allowed to modify
				2723	the number or order of execution of this <tt>load</tt> with other
				2724	volatile <tt>load</tt> and <tt><a href="#i_store">store</a></tt>
				2725	instructions. </p>
				2726	<h5>Semantics:</h5>
				2727	<p>The location of memory pointed to is loaded.</p>
				2728	<h5>Examples:</h5>
				2729	<pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
				2730	<a
				2731	href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i>
				2732	%val = load i32* %ptr <i>; yields {i32}:val = i32 3</i>
				2733	</pre>
				2734	</div>
				2735	<!-- _______________________________________________________________________ -->
				2736	<div class="doc_subsubsection"> <a name="i_store">'<tt>store</tt>'
				2737	Instruction</a> </div>
				2738	<div class="doc_text">
				2739	<h5>Syntax:</h5>
				2740	<pre> store <ty> <value>, <ty>* <pointer>[, align <alignment>] <i>; yields {void}</i>
				2741	volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>] <i>; yields {void}</i>
				2742	</pre>
				2743	<h5>Overview:</h5>
				2744	<p>The '<tt>store</tt>' instruction is used to write to memory.</p>
				2745	<h5>Arguments:</h5>
				2746	<p>There are two arguments to the '<tt>store</tt>' instruction: a value
				2747	to store and an address at which to store it. The type of the '<tt><pointer></tt>'
				2748	operand must be a pointer to the type of the '<tt><value></tt>'
				2749	operand. If the <tt>store</tt> is marked as <tt>volatile</tt>, then the
				2750	optimizer is not allowed to modify the number or order of execution of
				2751	this <tt>store</tt> with other volatile <tt>load</tt> and <tt><a
				2752	href="#i_store">store</a></tt> instructions.</p>
				2753	<h5>Semantics:</h5>
				2754	<p>The contents of memory are updated to contain '<tt><value></tt>'
				2755	at the location specified by the '<tt><pointer></tt>' operand.</p>
				2756	<h5>Example:</h5>
				2757	<pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
				2758	<a
				2759	href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i>
				2760	%val = load i32* %ptr <i>; yields {i32}:val = i32 3</i>
				2761	</pre>
				2762	</div>
				2763
				2764	<!-- _______________________________________________________________________ -->
				2765	<div class="doc_subsubsection">
				2766	<a name="i_getelementptr">'<tt>getelementptr</tt>' Instruction</a>
				2767	</div>
				2768
				2769	<div class="doc_text">
				2770	<h5>Syntax:</h5>
				2771	<pre>
				2772	<result> = getelementptr <ty>* <ptrval>{, <ty> <idx>}*
				2773	</pre>
				2774
				2775	<h5>Overview:</h5>
				2776
				2777	<p>
				2778	The '<tt>getelementptr</tt>' instruction is used to get the address of a
				2779	subelement of an aggregate data structure.</p>
				2780
				2781	<h5>Arguments:</h5>
				2782
				2783	<p>This instruction takes a list of integer operands that indicate what
				2784	elements of the aggregate object to index to. The actual types of the arguments
				2785	provided depend on the type of the first pointer argument. The
				2786	'<tt>getelementptr</tt>' instruction is used to index down through the type
				2787	levels of a structure or to a specific index in an array. When indexing into a
				2788	structure, only <tt>i32</tt> integer constants are allowed. When indexing
				2789	into an array or pointer, only integers of 32 or 64 bits are allowed, and will
				2790	be sign extended to 64-bit values.</p>
				2791
				2792	<p>For example, let's consider a C code fragment and how it gets
				2793	compiled to LLVM:</p>
				2794
				2795	<div class="doc_code">
				2796	<pre>
				2797	struct RT {
				2798	char A;
				2799	int B[10][20];
				2800	char C;
				2801	};
				2802	struct ST {
				2803	int X;
				2804	double Y;
				2805	struct RT Z;
				2806	};
				2807
				2808	int foo(struct ST s) {
				2809	return &s[1].Z.B[5][13];
				2810	}
				2811	</pre>
				2812	</div>
				2813
				2814	<p>The LLVM code generated by the GCC frontend is:</p>
				2815
				2816	<div class="doc_code">
				2817	<pre>
				2818	%RT = type { i8 , [10 x [20 x i32]], i8 }
				2819	%ST = type { i32, double, %RT }
				2820
				2821	define i32* %foo(%ST* %s) {
				2822	entry:
				2823	%reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
				2824	ret i32* %reg
				2825	}
				2826	</pre>
				2827	</div>
				2828
				2829	<h5>Semantics:</h5>
				2830
				2831	<p>The index types specified for the '<tt>getelementptr</tt>' instruction depend
				2832	on the pointer type that is being indexed into. <a href="#t_pointer">Pointer</a>
				2833	and <a href="#t_array">array</a> types can use a 32-bit or 64-bit
				2834	<a href="#t_integer">integer</a> type but the value will always be sign extended
				2835	to 64-bits. <a href="#t_struct">Structure</a> types require <tt>i32</tt>
				2836	<b>constants</b>.</p>
				2837
				2838	<p>In the example above, the first index is indexing into the '<tt>%ST*</tt>'
				2839	type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT
				2840	}</tt>' type, a structure. The second index indexes into the third element of
				2841	the structure, yielding a '<tt>%RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]],
				2842	i8 }</tt>' type, another structure. The third index indexes into the second
				2843	element of the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an
				2844	array. The two dimensions of the array are subscripted into, yielding an
				2845	'<tt>i32</tt>' type. The '<tt>getelementptr</tt>' instruction returns a pointer
				2846	to this element, thus computing a value of '<tt>i32*</tt>' type.</p>
				2847
				2848	<p>Note that it is perfectly legal to index partially through a
				2849	structure, returning a pointer to an inner element. Because of this,
				2850	the LLVM code for the given testcase is equivalent to:</p>
				2851
				2852	<pre>
				2853	define i32* %foo(%ST* %s) {
				2854	%t1 = getelementptr %ST* %s, i32 1 <i>; yields %ST*:%t1</i>
				2855	%t2 = getelementptr %ST* %t1, i32 0, i32 2 <i>; yields %RT*:%t2</i>
				2856	%t3 = getelementptr %RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i>
				2857	%t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i>
				2858	%t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i>
				2859	ret i32* %t5
				2860	}
				2861	</pre>
				2862
				2863	<p>Note that it is undefined to access an array out of bounds: array and
				2864	pointer indexes must always be within the defined bounds of the array type.
				2865	The one exception for this rules is zero length arrays. These arrays are
				2866	defined to be accessible as variable length arrays, which requires access
				2867	beyond the zero'th element.</p>
				2868
				2869	<p>The getelementptr instruction is often confusing. For some more insight
				2870	into how it works, see <a href="GetElementPtr.html">the getelementptr
				2871	FAQ</a>.</p>
				2872
				2873	<h5>Example:</h5>
				2874
				2875	<pre>
				2876	<i>; yields [12 x i8]*:aptr</i>
				2877	%aptr = getelementptr {i32, [12 x i8]}* %sptr, i64 0, i32 1
				2878	</pre>
				2879	</div>
				2880
				2881	<!-- ======================================================================= -->
				2882	<div class="doc_subsection"> <a name="convertops">Conversion Operations</a>
				2883	</div>
				2884	<div class="doc_text">
				2885	<p>The instructions in this category are the conversion instructions (casting)
				2886	which all take a single operand and a type. They perform various bit conversions
				2887	on the operand.</p>
				2888	</div>
				2889
				2890	<!-- _______________________________________________________________________ -->
				2891	<div class="doc_subsubsection">
				2892	<a name="i_trunc">'<tt>trunc .. to</tt>' Instruction</a>
				2893	</div>
				2894	<div class="doc_text">
				2895
				2896	<h5>Syntax:</h5>
				2897	<pre>
				2898	<result> = trunc <ty> <value> to <ty2> <i>; yields ty2</i>
				2899	</pre>
				2900
				2901	<h5>Overview:</h5>
				2902	<p>
				2903	The '<tt>trunc</tt>' instruction truncates its operand to the type <tt>ty2</tt>.
				2904	</p>
				2905
				2906	<h5>Arguments:</h5>
				2907	<p>
				2908	The '<tt>trunc</tt>' instruction takes a <tt>value</tt> to trunc, which must
				2909	be an <a href="#t_integer">integer</a> type, and a type that specifies the size
				2910	and type of the result, which must be an <a href="#t_integer">integer</a>
				2911	type. The bit size of <tt>value</tt> must be larger than the bit size of
				2912	<tt>ty2</tt>. Equal sized types are not allowed.</p>
				2913
				2914	<h5>Semantics:</h5>
				2915	<p>
				2916	The '<tt>trunc</tt>' instruction truncates the high order bits in <tt>value</tt>
				2917	and converts the remaining bits to <tt>ty2</tt>. Since the source size must be
				2918	larger than the destination size, <tt>trunc</tt> cannot be a <i>no-op cast</i>.
				2919	It will always truncate bits.</p>
				2920
				2921	<h5>Example:</h5>
				2922	<pre>
				2923	%X = trunc i32 257 to i8 <i>; yields i8:1</i>
				2924	%Y = trunc i32 123 to i1 <i>; yields i1:true</i>
				2925	%Y = trunc i32 122 to i1 <i>; yields i1:false</i>
				2926	</pre>
				2927	</div>
				2928
				2929	<!-- _______________________________________________________________________ -->
				2930	<div class="doc_subsubsection">
				2931	<a name="i_zext">'<tt>zext .. to</tt>' Instruction</a>
				2932	</div>
				2933	<div class="doc_text">
				2934
				2935	<h5>Syntax:</h5>
				2936	<pre>
				2937	<result> = zext <ty> <value> to <ty2> <i>; yields ty2</i>
				2938	</pre>
				2939
				2940	<h5>Overview:</h5>
				2941	<p>The '<tt>zext</tt>' instruction zero extends its operand to type
				2942	<tt>ty2</tt>.</p>
				2943
				2944
				2945	<h5>Arguments:</h5>
				2946	<p>The '<tt>zext</tt>' instruction takes a value to cast, which must be of
				2947	<a href="#t_integer">integer</a> type, and a type to cast it to, which must
				2948	also be of <a href="#t_integer">integer</a> type. The bit size of the
				2949	<tt>value</tt> must be smaller than the bit size of the destination type,
				2950	<tt>ty2</tt>.</p>
				2951
				2952	<h5>Semantics:</h5>
				2953	<p>The <tt>zext</tt> fills the high order bits of the <tt>value</tt> with zero
				2954	bits until it reaches the size of the destination type, <tt>ty2</tt>.</p>
				2955
				2956	<p>When zero extending from i1, the result will always be either 0 or 1.</p>
				2957
				2958	<h5>Example:</h5>
				2959	<pre>
				2960	%X = zext i32 257 to i64 <i>; yields i64:257</i>
				2961	%Y = zext i1 true to i32 <i>; yields i32:1</i>
				2962	</pre>
				2963	</div>
				2964
				2965	<!-- _______________________________________________________________________ -->
				2966	<div class="doc_subsubsection">
				2967	<a name="i_sext">'<tt>sext .. to</tt>' Instruction</a>
				2968	</div>
				2969	<div class="doc_text">
				2970
				2971	<h5>Syntax:</h5>
				2972	<pre>
				2973	<result> = sext <ty> <value> to <ty2> <i>; yields ty2</i>
				2974	</pre>
				2975
				2976	<h5>Overview:</h5>
				2977	<p>The '<tt>sext</tt>' sign extends <tt>value</tt> to the type <tt>ty2</tt>.</p>
				2978
				2979	<h5>Arguments:</h5>
				2980	<p>
				2981	The '<tt>sext</tt>' instruction takes a value to cast, which must be of
				2982	<a href="#t_integer">integer</a> type, and a type to cast it to, which must
				2983	also be of <a href="#t_integer">integer</a> type. The bit size of the
				2984	<tt>value</tt> must be smaller than the bit size of the destination type,
				2985	<tt>ty2</tt>.</p>
				2986
				2987	<h5>Semantics:</h5>
				2988	<p>
				2989	The '<tt>sext</tt>' instruction performs a sign extension by copying the sign
				2990	bit (highest order bit) of the <tt>value</tt> until it reaches the bit size of
				2991	the type <tt>ty2</tt>.</p>
				2992
				2993	<p>When sign extending from i1, the extension always results in -1 or 0.</p>
				2994
				2995	<h5>Example:</h5>
				2996	<pre>
				2997	%X = sext i8 -1 to i16 <i>; yields i16 :65535</i>
				2998	%Y = sext i1 true to i32 <i>; yields i32:-1</i>
				2999	</pre>
				3000	</div>
				3001
				3002	<!-- _______________________________________________________________________ -->
				3003	<div class="doc_subsubsection">
				3004	<a name="i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a>
				3005	</div>
				3006
				3007	<div class="doc_text">
				3008
				3009	<h5>Syntax:</h5>
				3010
				3011	<pre>
				3012	<result> = fptrunc <ty> <value> to <ty2> <i>; yields ty2</i>
				3013	</pre>
				3014
				3015	<h5>Overview:</h5>
				3016	<p>The '<tt>fptrunc</tt>' instruction truncates <tt>value</tt> to type
				3017	<tt>ty2</tt>.</p>
				3018
				3019
				3020	<h5>Arguments:</h5>
				3021	<p>The '<tt>fptrunc</tt>' instruction takes a <a href="#t_floating">floating
				3022	point</a> value to cast and a <a href="#t_floating">floating point</a> type to
				3023	cast it to. The size of <tt>value</tt> must be larger than the size of
				3024	<tt>ty2</tt>. This implies that <tt>fptrunc</tt> cannot be used to make a
				3025	<i>no-op cast</i>.</p>
				3026
				3027	<h5>Semantics:</h5>
				3028	<p> The '<tt>fptrunc</tt>' instruction truncates a <tt>value</tt> from a larger
				3029	<a href="#t_floating">floating point</a> type to a smaller
				3030	<a href="#t_floating">floating point</a> type. If the value cannot fit within
				3031	the destination type, <tt>ty2</tt>, then the results are undefined.</p>
				3032
				3033	<h5>Example:</h5>
				3034	<pre>
				3035	%X = fptrunc double 123.0 to float <i>; yields float:123.0</i>
				3036	%Y = fptrunc double 1.0E+300 to float <i>; yields undefined</i>
				3037	</pre>
				3038	</div>
				3039
				3040	<!-- _______________________________________________________________________ -->
				3041	<div class="doc_subsubsection">
				3042	<a name="i_fpext">'<tt>fpext .. to</tt>' Instruction</a>
				3043	</div>
				3044	<div class="doc_text">
				3045
				3046	<h5>Syntax:</h5>
				3047	<pre>
				3048	<result> = fpext <ty> <value> to <ty2> <i>; yields ty2</i>
				3049	</pre>
				3050
				3051	<h5>Overview:</h5>
				3052	<p>The '<tt>fpext</tt>' extends a floating point <tt>value</tt> to a larger
				3053	floating point value.</p>
				3054
				3055	<h5>Arguments:</h5>
				3056	<p>The '<tt>fpext</tt>' instruction takes a
				3057	<a href="#t_floating">floating point</a> <tt>value</tt> to cast,
				3058	and a <a href="#t_floating">floating point</a> type to cast it to. The source
				3059	type must be smaller than the destination type.</p>
				3060
				3061	<h5>Semantics:</h5>
				3062	<p>The '<tt>fpext</tt>' instruction extends the <tt>value</tt> from a smaller
				3063	<a href="#t_floating">floating point</a> type to a larger
				3064	<a href="#t_floating">floating point</a> type. The <tt>fpext</tt> cannot be
				3065	used to make a <i>no-op cast</i> because it always changes bits. Use
				3066	<tt>bitcast</tt> to make a <i>no-op cast</i> for a floating point cast.</p>
				3067
				3068	<h5>Example:</h5>
				3069	<pre>
				3070	%X = fpext float 3.1415 to double <i>; yields double:3.1415</i>
				3071	%Y = fpext float 1.0 to float <i>; yields float:1.0 (no-op)</i>
				3072	</pre>
				3073	</div>
				3074
				3075	<!-- _______________________________________________________________________ -->
				3076	<div class="doc_subsubsection">
				3077	<a name="i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a>
				3078	</div>
				3079	<div class="doc_text">
				3080
				3081	<h5>Syntax:</h5>
				3082	<pre>
				3083	<result> = fp2uint <ty> <value> to <ty2> <i>; yields ty2</i>
				3084	</pre>
				3085
				3086	<h5>Overview:</h5>
				3087	<p>The '<tt>fp2uint</tt>' converts a floating point <tt>value</tt> to its
				3088	unsigned integer equivalent of type <tt>ty2</tt>.
				3089	</p>
				3090
				3091	<h5>Arguments:</h5>
				3092	<p>The '<tt>fp2uint</tt>' instruction takes a value to cast, which must be a
				3093	<a href="#t_floating">floating point</a> value, and a type to cast it to, which
				3094	must be an <a href="#t_integer">integer</a> type.</p>
				3095
				3096	<h5>Semantics:</h5>
				3097	<p> The '<tt>fp2uint</tt>' instruction converts its
				3098	<a href="#t_floating">floating point</a> operand into the nearest (rounding
				3099	towards zero) unsigned integer value. If the value cannot fit in <tt>ty2</tt>,
				3100	the results are undefined.</p>
				3101
				3102	<p>When converting to i1, the conversion is done as a comparison against
				3103	zero. If the <tt>value</tt> was zero, the i1 result will be <tt>false</tt>.
				3104	If the <tt>value</tt> was non-zero, the i1 result will be <tt>true</tt>.</p>
				3105
				3106	<h5>Example:</h5>
				3107	<pre>
				3108	%X = fp2uint double 123.0 to i32 <i>; yields i32:123</i>
				3109	%Y = fp2uint float 1.0E+300 to i1 <i>; yields i1:true</i>
				3110	%X = fp2uint float 1.04E+17 to i8 <i>; yields undefined:1</i>
				3111	</pre>
				3112	</div>
				3113
				3114	<!-- _______________________________________________________________________ -->
				3115	<div class="doc_subsubsection">
				3116	<a name="i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a>
				3117	</div>
				3118	<div class="doc_text">
				3119
				3120	<h5>Syntax:</h5>
				3121	<pre>
				3122	<result> = fptosi <ty> <value> to <ty2> <i>; yields ty2</i>
				3123	</pre>
				3124
				3125	<h5>Overview:</h5>
				3126	<p>The '<tt>fptosi</tt>' instruction converts
				3127	<a href="#t_floating">floating point</a> <tt>value</tt> to type <tt>ty2</tt>.
				3128	</p>
				3129
				3130
				3131	<h5>Arguments:</h5>
				3132	<p> The '<tt>fptosi</tt>' instruction takes a value to cast, which must be a
				3133	<a href="#t_floating">floating point</a> value, and a type to cast it to, which
				3134	must also be an <a href="#t_integer">integer</a> type.</p>
				3135
				3136	<h5>Semantics:</h5>
				3137	<p>The '<tt>fptosi</tt>' instruction converts its
				3138	<a href="#t_floating">floating point</a> operand into the nearest (rounding
				3139	towards zero) signed integer value. If the value cannot fit in <tt>ty2</tt>,
				3140	the results are undefined.</p>
				3141
				3142	<p>When converting to i1, the conversion is done as a comparison against
				3143	zero. If the <tt>value</tt> was zero, the i1 result will be <tt>false</tt>.
				3144	If the <tt>value</tt> was non-zero, the i1 result will be <tt>true</tt>.</p>
				3145
				3146	<h5>Example:</h5>
				3147	<pre>
				3148	%X = fptosi double -123.0 to i32 <i>; yields i32:-123</i>
				3149	%Y = fptosi float 1.0E-247 to i1 <i>; yields i1:true</i>
				3150	%X = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i>
				3151	</pre>
				3152	</div>
				3153
				3154	<!-- _______________________________________________________________________ -->
				3155	<div class="doc_subsubsection">
				3156	<a name="i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a>
				3157	</div>
				3158	<div class="doc_text">
				3159
				3160	<h5>Syntax:</h5>
				3161	<pre>
				3162	<result> = uitofp <ty> <value> to <ty2> <i>; yields ty2</i>
				3163	</pre>
				3164
				3165	<h5>Overview:</h5>
				3166	<p>The '<tt>uitofp</tt>' instruction regards <tt>value</tt> as an unsigned
				3167	integer and converts that value to the <tt>ty2</tt> type.</p>
				3168
				3169
				3170	<h5>Arguments:</h5>
				3171	<p>The '<tt>uitofp</tt>' instruction takes a value to cast, which must be an
				3172	<a href="#t_integer">integer</a> value, and a type to cast it to, which must
				3173	be a <a href="#t_floating">floating point</a> type.</p>
				3174
				3175	<h5>Semantics:</h5>
				3176	<p>The '<tt>uitofp</tt>' instruction interprets its operand as an unsigned
				3177	integer quantity and converts it to the corresponding floating point value. If
				3178	the value cannot fit in the floating point value, the results are undefined.</p>
				3179
				3180
				3181	<h5>Example:</h5>
				3182	<pre>
				3183	%X = uitofp i32 257 to float <i>; yields float:257.0</i>
				3184	%Y = uitofp i8 -1 to double <i>; yields double:255.0</i>
				3185	</pre>
				3186	</div>
				3187
				3188	<!-- _______________________________________________________________________ -->
				3189	<div class="doc_subsubsection">
				3190	<a name="i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a>
				3191	</div>
				3192	<div class="doc_text">
				3193
				3194	<h5>Syntax:</h5>
				3195	<pre>
				3196	<result> = sitofp <ty> <value> to <ty2> <i>; yields ty2</i>
				3197	</pre>
				3198
				3199	<h5>Overview:</h5>
				3200	<p>The '<tt>sitofp</tt>' instruction regards <tt>value</tt> as a signed
				3201	integer and converts that value to the <tt>ty2</tt> type.</p>
				3202
				3203	<h5>Arguments:</h5>
				3204	<p>The '<tt>sitofp</tt>' instruction takes a value to cast, which must be an
				3205	<a href="#t_integer">integer</a> value, and a type to cast it to, which must be
				3206	a <a href="#t_floating">floating point</a> type.</p>
				3207
				3208	<h5>Semantics:</h5>
				3209	<p>The '<tt>sitofp</tt>' instruction interprets its operand as a signed
				3210	integer quantity and converts it to the corresponding floating point value. If
				3211	the value cannot fit in the floating point value, the results are undefined.</p>
				3212
				3213	<h5>Example:</h5>
				3214	<pre>
				3215	%X = sitofp i32 257 to float <i>; yields float:257.0</i>
				3216	%Y = sitofp i8 -1 to double <i>; yields double:-1.0</i>
				3217	</pre>
				3218	</div>
				3219
				3220	<!-- _______________________________________________________________________ -->
				3221	<div class="doc_subsubsection">
				3222	<a name="i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a>
				3223	</div>
				3224	<div class="doc_text">
				3225
				3226	<h5>Syntax:</h5>
				3227	<pre>
				3228	<result> = ptrtoint <ty> <value> to <ty2> <i>; yields ty2</i>
				3229	</pre>
				3230
				3231	<h5>Overview:</h5>
				3232	<p>The '<tt>ptrtoint</tt>' instruction converts the pointer <tt>value</tt> to
				3233	the integer type <tt>ty2</tt>.</p>
				3234
				3235	<h5>Arguments:</h5>
				3236	<p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which
				3237	must be a <a href="#t_pointer">pointer</a> value, and a type to cast it to
				3238	<tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> type.
				3239
				3240	<h5>Semantics:</h5>
				3241	<p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type
				3242	<tt>ty2</tt> by interpreting the pointer value as an integer and either
				3243	truncating or zero extending that value to the size of the integer type. If
				3244	<tt>value</tt> is smaller than <tt>ty2</tt> then a zero extension is done. If
				3245	<tt>value</tt> is larger than <tt>ty2</tt> then a truncation is done. If they
				3246	are the same size, then nothing is done (<i>no-op cast</i>) other than a type
				3247	change.</p>
				3248
				3249	<h5>Example:</h5>
				3250	<pre>
				3251	%X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i>
				3252	%Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i>
				3253	</pre>
				3254	</div>
				3255
				3256	<!-- _______________________________________________________________________ -->
				3257	<div class="doc_subsubsection">
				3258	<a name="i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a>
				3259	</div>
				3260	<div class="doc_text">
				3261
				3262	<h5>Syntax:</h5>
				3263	<pre>
				3264	<result> = inttoptr <ty> <value> to <ty2> <i>; yields ty2</i>
				3265	</pre>
				3266
				3267	<h5>Overview:</h5>
				3268	<p>The '<tt>inttoptr</tt>' instruction converts an integer <tt>value</tt> to
				3269	a pointer type, <tt>ty2</tt>.</p>
				3270
				3271	<h5>Arguments:</h5>
				3272	<p>The '<tt>inttoptr</tt>' instruction takes an <a href="#t_integer">integer</a>
				3273	value to cast, and a type to cast it to, which must be a
				3274	<a href="#t_pointer">pointer</a> type.
				3275
				3276	<h5>Semantics:</h5>
				3277	<p>The '<tt>inttoptr</tt>' instruction converts <tt>value</tt> to type
				3278	<tt>ty2</tt> by applying either a zero extension or a truncation depending on
				3279	the size of the integer <tt>value</tt>. If <tt>value</tt> is larger than the
				3280	size of a pointer then a truncation is done. If <tt>value</tt> is smaller than
				3281	the size of a pointer then a zero extension is done. If they are the same size,
				3282	nothing is done (<i>no-op cast</i>).</p>
				3283
				3284	<h5>Example:</h5>
				3285	<pre>
				3286	%X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i>
				3287	%X = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
				3288	%Y = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
				3289	</pre>
				3290	</div>
				3291
				3292	<!-- _______________________________________________________________________ -->
				3293	<div class="doc_subsubsection">
				3294	<a name="i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a>
				3295	</div>
				3296	<div class="doc_text">
				3297
				3298	<h5>Syntax:</h5>
				3299	<pre>
				3300	<result> = bitcast <ty> <value> to <ty2> <i>; yields ty2</i>
				3301	</pre>
				3302
				3303	<h5>Overview:</h5>
				3304	<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
				3305	<tt>ty2</tt> without changing any bits.</p>
				3306
				3307	<h5>Arguments:</h5>
				3308	<p>The '<tt>bitcast</tt>' instruction takes a value to cast, which must be
				3309	a first class value, and a type to cast it to, which must also be a <a
				3310	href="#t_firstclass">first class</a> type. The bit sizes of <tt>value</tt>
				3311	and the destination type, <tt>ty2</tt>, must be identical. If the source
				3312	type is a pointer, the destination type must also be a pointer.</p>
				3313
				3314	<h5>Semantics:</h5>
				3315	<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
				3316	<tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with
				3317	this conversion. The conversion is done as if the <tt>value</tt> had been
				3318	stored to memory and read back as type <tt>ty2</tt>. Pointer types may only be
				3319	converted to other pointer types with this instruction. To convert pointers to
				3320	other types, use the <a href="#i_inttoptr">inttoptr</a> or
				3321	<a href="#i_ptrtoint">ptrtoint</a> instructions first.</p>
				3322
				3323	<h5>Example:</h5>
				3324	<pre>
				3325	%X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
				3326	%Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i>
				3327	%Z = bitcast <2xint> %V to i64; <i>; yields i64: %V</i>
				3328	</pre>
				3329	</div>
				3330
				3331	<!-- ======================================================================= -->
				3332	<div class="doc_subsection"> <a name="otherops">Other Operations</a> </div>
				3333	<div class="doc_text">
				3334	<p>The instructions in this category are the "miscellaneous"
				3335	instructions, which defy better classification.</p>
				3336	</div>
				3337
				3338	<!-- _______________________________________________________________________ -->
				3339	<div class="doc_subsubsection"><a name="i_icmp">'<tt>icmp</tt>' Instruction</a>
				3340	</div>
				3341	<div class="doc_text">
				3342	<h5>Syntax:</h5>
				3343	<pre> <result> = icmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result</i>
				3344	</pre>
				3345	<h5>Overview:</h5>
				3346	<p>The '<tt>icmp</tt>' instruction returns a boolean value based on comparison
				3347	of its two integer operands.</p>
				3348	<h5>Arguments:</h5>
				3349	<p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is
				3350	the condition code indicating the kind of comparison to perform. It is not
				3351	a value, just a keyword. The possible condition code are:
				3352	<ol>
				3353	<li><tt>eq</tt>: equal</li>
				3354	<li><tt>ne</tt>: not equal </li>
				3355	<li><tt>ugt</tt>: unsigned greater than</li>
				3356	<li><tt>uge</tt>: unsigned greater or equal</li>
				3357	<li><tt>ult</tt>: unsigned less than</li>
				3358	<li><tt>ule</tt>: unsigned less or equal</li>
				3359	<li><tt>sgt</tt>: signed greater than</li>
				3360	<li><tt>sge</tt>: signed greater or equal</li>
				3361	<li><tt>slt</tt>: signed less than</li>
				3362	<li><tt>sle</tt>: signed less or equal</li>
				3363	</ol>
				3364	<p>The remaining two arguments must be <a href="#t_integer">integer</a> or
				3365	<a href="#t_pointer">pointer</a> typed. They must also be identical types.</p>
				3366	<h5>Semantics:</h5>
				3367	<p>The '<tt>icmp</tt>' compares <tt>var1</tt> and <tt>var2</tt> according to
				3368	the condition code given as <tt>cond</tt>. The comparison performed always
				3369	yields a <a href="#t_primitive">i1</a> result, as follows:
				3370	<ol>
				3371	<li><tt>eq</tt>: yields <tt>true</tt> if the operands are equal,
				3372	<tt>false</tt> otherwise. No sign interpretation is necessary or performed.
				3373	</li>
				3374	<li><tt>ne</tt>: yields <tt>true</tt> if the operands are unequal,
				3375	<tt>false</tt> otherwise. No sign interpretation is necessary or performed.
				3376	<li><tt>ugt</tt>: interprets the operands as unsigned values and yields
				3377	<tt>true</tt> if <tt>var1</tt> is greater than <tt>var2</tt>.</li>
				3378	<li><tt>uge</tt>: interprets the operands as unsigned values and yields
				3379	<tt>true</tt> if <tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li>
				3380	<li><tt>ult</tt>: interprets the operands as unsigned values and yields
				3381	<tt>true</tt> if <tt>var1</tt> is less than <tt>var2</tt>.</li>
				3382	<li><tt>ule</tt>: interprets the operands as unsigned values and yields
				3383	<tt>true</tt> if <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li>
				3384	<li><tt>sgt</tt>: interprets the operands as signed values and yields
				3385	<tt>true</tt> if <tt>var1</tt> is greater than <tt>var2</tt>.</li>
				3386	<li><tt>sge</tt>: interprets the operands as signed values and yields
				3387	<tt>true</tt> if <tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li>
				3388	<li><tt>slt</tt>: interprets the operands as signed values and yields
				3389	<tt>true</tt> if <tt>var1</tt> is less than <tt>var2</tt>.</li>
				3390	<li><tt>sle</tt>: interprets the operands as signed values and yields
				3391	<tt>true</tt> if <tt>var1</tt> is less than or equal to <tt>var2</tt>.</li>
				3392	</ol>
				3393	<p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer
				3394	values are compared as if they were integers.</p>
				3395
				3396	<h5>Example:</h5>
				3397	<pre> <result> = icmp eq i32 4, 5 <i>; yields: result=false</i>
				3398	<result> = icmp ne float* %X, %X <i>; yields: result=false</i>
				3399	<result> = icmp ult i16 4, 5 <i>; yields: result=true</i>
				3400	<result> = icmp sgt i16 4, 5 <i>; yields: result=false</i>
				3401	<result> = icmp ule i16 -4, 5 <i>; yields: result=false</i>
				3402	<result> = icmp sge i16 4, 5 <i>; yields: result=false</i>
				3403	</pre>
				3404	</div>
				3405
				3406	<!-- _______________________________________________________________________ -->
				3407	<div class="doc_subsubsection"><a name="i_fcmp">'<tt>fcmp</tt>' Instruction</a>
				3408	</div>
				3409	<div class="doc_text">
				3410	<h5>Syntax:</h5>
				3411	<pre> <result> = fcmp <cond> <ty> <var1>, <var2> <i>; yields {i1}:result</i>
				3412	</pre>
				3413	<h5>Overview:</h5>
				3414	<p>The '<tt>fcmp</tt>' instruction returns a boolean value based on comparison
				3415	of its floating point operands.</p>
				3416	<h5>Arguments:</h5>
				3417	<p>The '<tt>fcmp</tt>' instruction takes three operands. The first operand is
				3418	the condition code indicating the kind of comparison to perform. It is not
				3419	a value, just a keyword. The possible condition code are:
				3420	<ol>
				3421	<li><tt>false</tt>: no comparison, always returns false</li>
				3422	<li><tt>oeq</tt>: ordered and equal</li>
				3423	<li><tt>ogt</tt>: ordered and greater than </li>
				3424	<li><tt>oge</tt>: ordered and greater than or equal</li>
				3425	<li><tt>olt</tt>: ordered and less than </li>
				3426	<li><tt>ole</tt>: ordered and less than or equal</li>
				3427	<li><tt>one</tt>: ordered and not equal</li>
				3428	<li><tt>ord</tt>: ordered (no nans)</li>
				3429	<li><tt>ueq</tt>: unordered or equal</li>
				3430	<li><tt>ugt</tt>: unordered or greater than </li>
				3431	<li><tt>uge</tt>: unordered or greater than or equal</li>
				3432	<li><tt>ult</tt>: unordered or less than </li>
				3433	<li><tt>ule</tt>: unordered or less than or equal</li>
				3434	<li><tt>une</tt>: unordered or not equal</li>
				3435	<li><tt>uno</tt>: unordered (either nans)</li>
				3436	<li><tt>true</tt>: no comparison, always returns true</li>
				3437	</ol>
				3438	<p><i>Ordered</i> means that neither operand is a QNAN while
				3439	<i>unordered</i> means that either operand may be a QNAN.</p>
				3440	<p>The <tt>val1</tt> and <tt>val2</tt> arguments must be
				3441	<a href="#t_floating">floating point</a> typed. They must have identical
				3442	types.</p>
				3443	<h5>Semantics:</h5>
				3444	<p>The '<tt>fcmp</tt>' compares <tt>var1</tt> and <tt>var2</tt> according to
				3445	the condition code given as <tt>cond</tt>. The comparison performed always
				3446	yields a <a href="#t_primitive">i1</a> result, as follows:
				3447	<ol>
				3448	<li><tt>false</tt>: always yields <tt>false</tt>, regardless of operands.</li>
				3449	<li><tt>oeq</tt>: yields <tt>true</tt> if both operands are not a QNAN and
				3450	<tt>var1</tt> is equal to <tt>var2</tt>.</li>
				3451	<li><tt>ogt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
				3452	<tt>var1</tt> is greather than <tt>var2</tt>.</li>
				3453	<li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and
				3454	<tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li>
				3455	<li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
				3456	<tt>var1</tt> is less than <tt>var2</tt>.</li>
				3457	<li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and
				3458	<tt>var1</tt> is less than or equal to <tt>var2</tt>.</li>
				3459	<li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and
				3460	<tt>var1</tt> is not equal to <tt>var2</tt>.</li>
				3461	<li><tt>ord</tt>: yields <tt>true</tt> if both operands are not a QNAN.</li>
				3462	<li><tt>ueq</tt>: yields <tt>true</tt> if either operand is a QNAN or
				3463	<tt>var1</tt> is equal to <tt>var2</tt>.</li>
				3464	<li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or
				3465	<tt>var1</tt> is greater than <tt>var2</tt>.</li>
				3466	<li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or
				3467	<tt>var1</tt> is greater than or equal to <tt>var2</tt>.</li>
				3468	<li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or
				3469	<tt>var1</tt> is less than <tt>var2</tt>.</li>
				3470	<li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or
				3471	<tt>var1</tt> is less than or equal to <tt>var2</tt>.</li>
				3472	<li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or
				3473	<tt>var1</tt> is not equal to <tt>var2</tt>.</li>
				3474	<li><tt>uno</tt>: yields <tt>true</tt> if either operand is a QNAN.</li>
				3475	<li><tt>true</tt>: always yields <tt>true</tt>, regardless of operands.</li>
				3476	</ol>
				3477
				3478	<h5>Example:</h5>
				3479	<pre> <result> = fcmp oeq float 4.0, 5.0 <i>; yields: result=false</i>
				3480	<result> = icmp one float 4.0, 5.0 <i>; yields: result=true</i>
				3481	<result> = icmp olt float 4.0, 5.0 <i>; yields: result=true</i>
				3482	<result> = icmp ueq double 1.0, 2.0 <i>; yields: result=false</i>
				3483	</pre>
				3484	</div>
				3485
				3486	<!-- _______________________________________________________________________ -->
				3487	<div class="doc_subsubsection"> <a name="i_phi">'<tt>phi</tt>'
				3488	Instruction</a> </div>
				3489	<div class="doc_text">
				3490	<h5>Syntax:</h5>
				3491	<pre> <result> = phi <ty> [ <val0>, <label0>], ...<br></pre>
				3492	<h5>Overview:</h5>
				3493	<p>The '<tt>phi</tt>' instruction is used to implement the φ node in
				3494	the SSA graph representing the function.</p>
				3495	<h5>Arguments:</h5>
				3496	<p>The type of the incoming values is specified with the first type
				3497	field. After this, the '<tt>phi</tt>' instruction takes a list of pairs
				3498	as arguments, with one pair for each predecessor basic block of the
				3499	current block. Only values of <a href="#t_firstclass">first class</a>
				3500	type may be used as the value arguments to the PHI node. Only labels
				3501	may be used as the label arguments.</p>
				3502	<p>There must be no non-phi instructions between the start of a basic
				3503	block and the PHI instructions: i.e. PHI instructions must be first in
				3504	a basic block.</p>
				3505	<h5>Semantics:</h5>
				3506	<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value
				3507	specified by the pair corresponding to the predecessor basic block that executed
				3508	just prior to the current block.</p>
				3509	<h5>Example:</h5>
				3510	<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>
				3511	</div>
				3512
				3513	<!-- _______________________________________________________________________ -->
				3514	<div class="doc_subsubsection">
				3515	<a name="i_select">'<tt>select</tt>' Instruction</a>
				3516	</div>
				3517
				3518	<div class="doc_text">
				3519
				3520	<h5>Syntax:</h5>
				3521
				3522	<pre>
				3523	<result> = select i1 <cond>, <ty> <val1>, <ty> <val2> <i>; yields ty</i>
				3524	</pre>
				3525
				3526	<h5>Overview:</h5>
				3527
				3528	<p>
				3529	The '<tt>select</tt>' instruction is used to choose one value based on a
				3530	condition, without branching.
				3531	</p>
				3532
				3533
				3534	<h5>Arguments:</h5>
				3535
				3536	<p>
				3537	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.
				3538	</p>
				3539
				3540	<h5>Semantics:</h5>
				3541
				3542	<p>
				3543	If the boolean condition evaluates to true, the instruction returns the first
				3544	value argument; otherwise, it returns the second value argument.
				3545	</p>
				3546
				3547	<h5>Example:</h5>
				3548
				3549	<pre>
				3550	%X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i>
				3551	</pre>
				3552	</div>
				3553
				3554
				3555	<!-- _______________________________________________________________________ -->
				3556	<div class="doc_subsubsection">
				3557	<a name="i_call">'<tt>call</tt>' Instruction</a>
				3558	</div>
				3559
				3560	<div class="doc_text">
				3561
				3562	<h5>Syntax:</h5>
				3563	<pre>
				3564	<result> = [tail] call [<a href="#callingconv">cconv</a>] <ty>* <fnptrval>(<param list>)
				3565	</pre>
				3566
				3567	<h5>Overview:</h5>
				3568
				3569	<p>The '<tt>call</tt>' instruction represents a simple function call.</p>
				3570
				3571	<h5>Arguments:</h5>
				3572
				3573	<p>This instruction requires several arguments:</p>
				3574
				3575	<ol>
				3576	<li>
				3577	<p>The optional "tail" marker indicates whether the callee function accesses
				3578	any allocas or varargs in the caller. If the "tail" marker is present, the
				3579	function call is eligible for tail call optimization. Note that calls may
				3580	be marked "tail" even if they do not occur before a <a
				3581	href="#i_ret"><tt>ret</tt></a> instruction.
				3582	</li>
				3583	<li>
				3584	<p>The optional "cconv" marker indicates which <a href="#callingconv">calling
				3585	convention</a> the call should use. If none is specified, the call defaults
				3586	to using C calling conventions.
				3587	</li>
				3588	<li>
				3589	<p>'<tt>ty</tt>': shall be the signature of the pointer to function value
				3590	being invoked. The argument types must match the types implied by this
				3591	signature. This type can be omitted if the function is not varargs and
				3592	if the function type does not return a pointer to a function.</p>
				3593	</li>
				3594	<li>
				3595	<p>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to
				3596	be invoked. In most cases, this is a direct function invocation, but
				3597	indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer
				3598	to function value.</p>
				3599	</li>
				3600	<li>
				3601	<p>'<tt>function args</tt>': argument list whose types match the
				3602	function signature argument types. All arguments must be of
				3603	<a href="#t_firstclass">first class</a> type. If the function signature
				3604	indicates the function accepts a variable number of arguments, the extra
				3605	arguments can be specified.</p>
				3606	</li>
				3607	</ol>
				3608
				3609	<h5>Semantics:</h5>
				3610
				3611	<p>The '<tt>call</tt>' instruction is used to cause control flow to
				3612	transfer to a specified function, with its incoming arguments bound to
				3613	the specified values. Upon a '<tt><a href="#i_ret">ret</a></tt>'
				3614	instruction in the called function, control flow continues with the
				3615	instruction after the function call, and the return value of the
				3616	function is bound to the result argument. This is a simpler case of
				3617	the <a href="#i_invoke">invoke</a> instruction.</p>
				3618
				3619	<h5>Example:</h5>
				3620
				3621	<pre>
				3622	%retval = call i32 %test(i32 %argc)
				3623	call i32(i8 , ...) %printf(i8 * %msg, i32 12, i8 42);
				3624	%X = tail call i32 %foo()
				3625	%Y = tail call <a href="#callingconv">fastcc</a> i32 %foo()
				3626	</pre>
				3627
				3628	</div>
				3629
				3630	<!-- _______________________________________________________________________ -->
				3631	<div class="doc_subsubsection">
				3632	<a name="i_va_arg">'<tt>va_arg</tt>' Instruction</a>
				3633	</div>
				3634
				3635	<div class="doc_text">
				3636
				3637	<h5>Syntax:</h5>
				3638
				3639	<pre>
				3640	<resultval> = va_arg <va_list*> <arglist>, <argty>
				3641	</pre>
				3642
				3643	<h5>Overview:</h5>
				3644
				3645	<p>The '<tt>va_arg</tt>' instruction is used to access arguments passed through
				3646	the "variable argument" area of a function call. It is used to implement the
				3647	<tt>va_arg</tt> macro in C.</p>
				3648
				3649	<h5>Arguments:</h5>
				3650
				3651	<p>This instruction takes a <tt>va_list*</tt> value and the type of
				3652	the argument. It returns a value of the specified argument type and
				3653	increments the <tt>va_list</tt> to point to the next argument. The
				3654	actual type of <tt>va_list</tt> is target specific.</p>
				3655
				3656	<h5>Semantics:</h5>
				3657
				3658	<p>The '<tt>va_arg</tt>' instruction loads an argument of the specified
				3659	type from the specified <tt>va_list</tt> and causes the
				3660	<tt>va_list</tt> to point to the next argument. For more information,
				3661	see the variable argument handling <a href="#int_varargs">Intrinsic
				3662	Functions</a>.</p>
				3663
				3664	<p>It is legal for this instruction to be called in a function which does not
				3665	take a variable number of arguments, for example, the <tt>vfprintf</tt>
				3666	function.</p>
				3667
				3668	<p><tt>va_arg</tt> is an LLVM instruction instead of an <a
				3669	href="#intrinsics">intrinsic function</a> because it takes a type as an
				3670	argument.</p>
				3671
				3672	<h5>Example:</h5>
				3673
				3674	<p>See the <a href="#int_varargs">variable argument processing</a> section.</p>
				3675
				3676	</div>
				3677
				3678	<!-- *********************************************************************** -->
				3679	<div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div>
				3680	<!-- *********************************************************************** -->
				3681
				3682	<div class="doc_text">
				3683
				3684	<p>LLVM supports the notion of an "intrinsic function". These functions have
				3685	well known names and semantics and are required to follow certain restrictions.
				3686	Overall, these intrinsics represent an extension mechanism for the LLVM
				3687	language that does not require changing all of the transformations in LLVM when
				3688	adding to the language (or the bitcode reader/writer, the parser, etc...).</p>
				3689
				3690	<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This
				3691	prefix is reserved in LLVM for intrinsic names; thus, function names may not
				3692	begin with this prefix. Intrinsic functions must always be external functions:
				3693	you cannot define the body of intrinsic functions. Intrinsic functions may
				3694	only be used in call or invoke instructions: it is illegal to take the address
				3695	of an intrinsic function. Additionally, because intrinsic functions are part
				3696	of the LLVM language, it is required if any are added that they be documented
				3697	here.</p>
				3698
				3699	<p>Some intrinsic functions can be overloaded, i.e., the intrinsic represents
				3700	a family of functions that perform the same operation but on different data
				3701	types. This is most frequent with the integer types. Since LLVM can represent
				3702	over 8 million different integer types, there is a way to declare an intrinsic
				3703	that can be overloaded based on its arguments. Such an intrinsic will have the
				3704	names of its argument types encoded into its function name, each
				3705	preceded by a period. For example, the <tt>llvm.ctpop</tt> function can take an
				3706	integer of any width. This leads to a family of functions such as
				3707	<tt>i32 @llvm.ctpop.i8(i8 %val)</tt> and <tt>i32 @llvm.ctpop.i29(i29 %val)</tt>.
				3708	</p>
				3709
				3710
				3711	<p>To learn how to add an intrinsic function, please see the
				3712	<a href="ExtendingLLVM.html">Extending LLVM Guide</a>.
				3713	</p>
				3714
				3715	</div>
				3716
				3717	<!-- ======================================================================= -->
				3718	<div class="doc_subsection">
				3719	<a name="int_varargs">Variable Argument Handling Intrinsics</a>
				3720	</div>
				3721
				3722	<div class="doc_text">
				3723
				3724	<p>Variable argument support is defined in LLVM with the <a
				3725	href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three
				3726	intrinsic functions. These functions are related to the similarly
				3727	named macros defined in the <tt><stdarg.h></tt> header file.</p>
				3728
				3729	<p>All of these functions operate on arguments that use a
				3730	target-specific value type "<tt>va_list</tt>". The LLVM assembly
				3731	language reference manual does not define what this type is, so all
				3732	transformations should be prepared to handle these functions regardless of
				3733	the type used.</p>
				3734
				3735	<p>This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a>
				3736	instruction and the variable argument handling intrinsic functions are
				3737	used.</p>
				3738
				3739	<div class="doc_code">
				3740	<pre>
				3741	define i32 @test(i32 %X, ...) {
				3742	; Initialize variable argument processing
				3743	%ap = alloca i8*
				3744	%ap2 = bitcast i8** %ap to i8*
				3745	call void @llvm.va_start(i8* %ap2)
				3746
				3747	; Read a single integer argument
				3748	%tmp = va_arg i8** %ap, i32
				3749
				3750	; Demonstrate usage of llvm.va_copy and llvm.va_end
				3751	%aq = alloca i8*
				3752	%aq2 = bitcast i8** %aq to i8*
				3753	call void @llvm.va_copy(i8* %aq2, i8* %ap2)
				3754	call void @llvm.va_end(i8* %aq2)
				3755
				3756	; Stop processing of arguments.
				3757	call void @llvm.va_end(i8* %ap2)
				3758	ret i32 %tmp
				3759	}
				3760
				3761	declare void @llvm.va_start(i8*)
				3762	declare void @llvm.va_copy(i8, i8)
				3763	declare void @llvm.va_end(i8*)
				3764	</pre>
				3765	</div>
				3766
				3767	</div>
				3768
				3769	<!-- _______________________________________________________________________ -->
				3770	<div class="doc_subsubsection">
				3771	<a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
				3772	</div>
				3773
				3774
				3775	<div class="doc_text">
				3776	<h5>Syntax:</h5>
				3777	<pre> declare void %llvm.va_start(i8* <arglist>)<br></pre>
				3778	<h5>Overview:</h5>
				3779	<P>The '<tt>llvm.va_start</tt>' intrinsic initializes
				3780	<tt>*<arglist></tt> for subsequent use by <tt><a
				3781	href="#i_va_arg">va_arg</a></tt>.</p>
				3782
				3783	<h5>Arguments:</h5>
				3784
				3785	<P>The argument is a pointer to a <tt>va_list</tt> element to initialize.</p>
				3786
				3787	<h5>Semantics:</h5>
				3788
				3789	<P>The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt>
				3790	macro available in C. In a target-dependent way, it initializes the
				3791	<tt>va_list</tt> element to which the argument points, so that the next call to
				3792	<tt>va_arg</tt> will produce the first variable argument passed to the function.
				3793	Unlike the C <tt>va_start</tt> macro, this intrinsic does not need to know the
				3794	last argument of the function as the compiler can figure that out.</p>
				3795
				3796	</div>
				3797
				3798	<!-- _______________________________________________________________________ -->
				3799	<div class="doc_subsubsection">
				3800	<a name="int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a>
				3801	</div>
				3802
				3803	<div class="doc_text">
				3804	<h5>Syntax:</h5>
				3805	<pre> declare void @llvm.va_end(i8* <arglist>)<br></pre>
				3806	<h5>Overview:</h5>
				3807
				3808	<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></tt>,
				3809	which has been initialized previously with <tt><a href="#int_va_start">llvm.va_start</a></tt>
				3810	or <tt><a href="#i_va_copy">llvm.va_copy</a></tt>.</p>
				3811
				3812	<h5>Arguments:</h5>
				3813
				3814	<p>The argument is a pointer to a <tt>va_list</tt> to destroy.</p>
				3815
				3816	<h5>Semantics:</h5>
				3817
				3818	<p>The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt>
				3819	macro available in C. In a target-dependent way, it destroys the
				3820	<tt>va_list</tt> element to which the argument points. Calls to <a
				3821	href="#int_va_start"><tt>llvm.va_start</tt></a> and <a href="#int_va_copy">
				3822	<tt>llvm.va_copy</tt></a> must be matched exactly with calls to
				3823	<tt>llvm.va_end</tt>.</p>
				3824
				3825	</div>
				3826
				3827	<!-- _______________________________________________________________________ -->
				3828	<div class="doc_subsubsection">
				3829	<a name="int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a>
				3830	</div>
				3831
				3832	<div class="doc_text">
				3833
				3834	<h5>Syntax:</h5>
				3835
				3836	<pre>
				3837	declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>)
				3838	</pre>
				3839
				3840	<h5>Overview:</h5>
				3841
				3842	<p>The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position
				3843	from the source argument list to the destination argument list.</p>
				3844
				3845	<h5>Arguments:</h5>
				3846
				3847	<p>The first argument is a pointer to a <tt>va_list</tt> element to initialize.
				3848	The second argument is a pointer to a <tt>va_list</tt> element to copy from.</p>
				3849
				3850
				3851	<h5>Semantics:</h5>
				3852
				3853	<p>The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt>
				3854	macro available in C. In a target-dependent way, it copies the source
				3855	<tt>va_list</tt> element into the destination <tt>va_list</tt> element. This
				3856	intrinsic is necessary because the <tt><a href="#int_va_start">
				3857	llvm.va_start</a></tt> intrinsic may be arbitrarily complex and require, for
				3858	example, memory allocation.</p>
				3859
				3860	</div>
				3861
				3862	<!-- ======================================================================= -->
				3863	<div class="doc_subsection">
				3864	<a name="int_gc">Accurate Garbage Collection Intrinsics</a>
				3865	</div>
				3866
				3867	<div class="doc_text">
				3868
				3869	<p>
				3870	LLVM support for <a href="GarbageCollection.html">Accurate Garbage
				3871	Collection</a> requires the implementation and generation of these intrinsics.
				3872	These intrinsics allow identification of <a href="#int_gcroot">GC roots on the
				3873	stack</a>, as well as garbage collector implementations that require <a
				3874	href="#int_gcread">read</a> and <a href="#int_gcwrite">write</a> barriers.
				3875	Front-ends for type-safe garbage collected languages should generate these
				3876	intrinsics to make use of the LLVM garbage collectors. For more details, see <a
				3877	href="GarbageCollection.html">Accurate Garbage Collection with LLVM</a>.
				3878	</p>
				3879	</div>
				3880
				3881	<!-- _______________________________________________________________________ -->
				3882	<div class="doc_subsubsection">
				3883	<a name="int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a>
				3884	</div>
				3885
				3886	<div class="doc_text">
				3887
				3888	<h5>Syntax:</h5>
				3889
				3890	<pre>
				3891	declare void @llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata)
				3892	</pre>
				3893
				3894	<h5>Overview:</h5>
				3895
				3896	<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to
				3897	the code generator, and allows some metadata to be associated with it.</p>
				3898
				3899	<h5>Arguments:</h5>
				3900
				3901	<p>The first argument specifies the address of a stack object that contains the
				3902	root pointer. The second pointer (which must be either a constant or a global
				3903	value address) contains the meta-data to be associated with the root.</p>
				3904
				3905	<h5>Semantics:</h5>
				3906
				3907	<p>At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"
				3908	location. At compile-time, the code generator generates information to allow
				3909	the runtime to find the pointer at GC safe points.
				3910	</p>
				3911
				3912	</div>
				3913
				3914
				3915	<!-- _______________________________________________________________________ -->
				3916	<div class="doc_subsubsection">
				3917	<a name="int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a>
				3918	</div>
				3919
				3920	<div class="doc_text">
				3921
				3922	<h5>Syntax:</h5>
				3923
				3924	<pre>
				3925	declare i8 * @llvm.gcread(i8 * %ObjPtr, i8 ** %Ptr)
				3926	</pre>
				3927
				3928	<h5>Overview:</h5>
				3929
				3930	<p>The '<tt>llvm.gcread</tt>' intrinsic identifies reads of references from heap
				3931	locations, allowing garbage collector implementations that require read
				3932	barriers.</p>
				3933
				3934	<h5>Arguments:</h5>
				3935
				3936	<p>The second argument is the address to read from, which should be an address
				3937	allocated from the garbage collector. The first object is a pointer to the
				3938	start of the referenced object, if needed by the language runtime (otherwise
				3939	null).</p>
				3940
				3941	<h5>Semantics:</h5>
				3942
				3943	<p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load
				3944	instruction, but may be replaced with substantially more complex code by the
				3945	garbage collector runtime, as needed.</p>
				3946
				3947	</div>
				3948
				3949
				3950	<!-- _______________________________________________________________________ -->
				3951	<div class="doc_subsubsection">
				3952	<a name="int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a>
				3953	</div>
				3954
				3955	<div class="doc_text">
				3956
				3957	<h5>Syntax:</h5>
				3958
				3959	<pre>
				3960	declare void @llvm.gcwrite(i8 * %P1, i8 * %Obj, i8 ** %P2)
				3961	</pre>
				3962
				3963	<h5>Overview:</h5>
				3964
				3965	<p>The '<tt>llvm.gcwrite</tt>' intrinsic identifies writes of references to heap
				3966	locations, allowing garbage collector implementations that require write
				3967	barriers (such as generational or reference counting collectors).</p>
				3968
				3969	<h5>Arguments:</h5>
				3970
				3971	<p>The first argument is the reference to store, the second is the start of the
				3972	object to store it to, and the third is the address of the field of Obj to
				3973	store to. If the runtime does not require a pointer to the object, Obj may be
				3974	null.</p>
				3975
				3976	<h5>Semantics:</h5>
				3977
				3978	<p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store
				3979	instruction, but may be replaced with substantially more complex code by the
				3980	garbage collector runtime, as needed.</p>
				3981
				3982	</div>
				3983
				3984
				3985
				3986	<!-- ======================================================================= -->
				3987	<div class="doc_subsection">
				3988	<a name="int_codegen">Code Generator Intrinsics</a>
				3989	</div>
				3990
				3991	<div class="doc_text">
				3992	<p>
				3993	These intrinsics are provided by LLVM to expose special features that may only
				3994	be implemented with code generator support.
				3995	</p>
				3996
				3997	</div>
				3998
				3999	<!-- _______________________________________________________________________ -->
				4000	<div class="doc_subsubsection">
				4001	<a name="int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a>
				4002	</div>
				4003
				4004	<div class="doc_text">
				4005
				4006	<h5>Syntax:</h5>
				4007	<pre>
				4008	declare i8 *@llvm.returnaddress(i32 <level>)
				4009	</pre>
				4010
				4011	<h5>Overview:</h5>
				4012
				4013	<p>
				4014	The '<tt>llvm.returnaddress</tt>' intrinsic attempts to compute a
				4015	target-specific value indicating the return address of the current function
				4016	or one of its callers.
				4017	</p>
				4018
				4019	<h5>Arguments:</h5>
				4020
				4021	<p>
				4022	The argument to this intrinsic indicates which function to return the address
				4023	for. Zero indicates the calling function, one indicates its caller, etc. The
				4024	argument is <b>required</b> to be a constant integer value.
				4025	</p>
				4026
				4027	<h5>Semantics:</h5>
				4028
				4029	<p>
				4030	The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer indicating
				4031	the return address of the specified call frame, or zero if it cannot be
				4032	identified. The value returned by this intrinsic is likely to be incorrect or 0
				4033	for arguments other than zero, so it should only be used for debugging purposes.
				4034	</p>
				4035
				4036	<p>
				4037	Note that calling this intrinsic does not prevent function inlining or other
				4038	aggressive transformations, so the value returned may not be that of the obvious
				4039	source-language caller.
				4040	</p>
				4041	</div>
				4042
				4043
				4044	<!-- _______________________________________________________________________ -->
				4045	<div class="doc_subsubsection">
				4046	<a name="int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a>
				4047	</div>
				4048
				4049	<div class="doc_text">
				4050
				4051	<h5>Syntax:</h5>
				4052	<pre>
				4053	declare i8 *@llvm.frameaddress(i32 <level>)
				4054	</pre>
				4055
				4056	<h5>Overview:</h5>
				4057
				4058	<p>
				4059	The '<tt>llvm.frameaddress</tt>' intrinsic attempts to return the
				4060	target-specific frame pointer value for the specified stack frame.
				4061	</p>
				4062
				4063	<h5>Arguments:</h5>
				4064
				4065	<p>
				4066	The argument to this intrinsic indicates which function to return the frame
				4067	pointer for. Zero indicates the calling function, one indicates its caller,
				4068	etc. The argument is <b>required</b> to be a constant integer value.
				4069	</p>
				4070
				4071	<h5>Semantics:</h5>
				4072
				4073	<p>
				4074	The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer indicating
				4075	the frame address of the specified call frame, or zero if it cannot be
				4076	identified. The value returned by this intrinsic is likely to be incorrect or 0
				4077	for arguments other than zero, so it should only be used for debugging purposes.
				4078	</p>
				4079
				4080	<p>
				4081	Note that calling this intrinsic does not prevent function inlining or other
				4082	aggressive transformations, so the value returned may not be that of the obvious
				4083	source-language caller.
				4084	</p>
				4085	</div>
				4086
				4087	<!-- _______________________________________________________________________ -->
				4088	<div class="doc_subsubsection">
				4089	<a name="int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a>
				4090	</div>
				4091
				4092	<div class="doc_text">
				4093
				4094	<h5>Syntax:</h5>
				4095	<pre>
				4096	declare i8 *@llvm.stacksave()
				4097	</pre>
				4098
				4099	<h5>Overview:</h5>
				4100
				4101	<p>
				4102	The '<tt>llvm.stacksave</tt>' intrinsic is used to remember the current state of
				4103	the function stack, for use with <a href="#int_stackrestore">
				4104	<tt>llvm.stackrestore</tt></a>. This is useful for implementing language
				4105	features like scoped automatic variable sized arrays in C99.
				4106	</p>
				4107
				4108	<h5>Semantics:</h5>
				4109
				4110	<p>
				4111	This intrinsic returns a opaque pointer value that can be passed to <a
				4112	href="#int_stackrestore"><tt>llvm.stackrestore</tt></a>. When an
				4113	<tt>llvm.stackrestore</tt> intrinsic is executed with a value saved from
				4114	<tt>llvm.stacksave</tt>, it effectively restores the state of the stack to the
				4115	state it was in when the <tt>llvm.stacksave</tt> intrinsic executed. In
				4116	practice, this pops any <a href="#i_alloca">alloca</a> blocks from the stack
				4117	that were allocated after the <tt>llvm.stacksave</tt> was executed.
				4118	</p>
				4119
				4120	</div>
				4121
				4122	<!-- _______________________________________________________________________ -->
				4123	<div class="doc_subsubsection">
				4124	<a name="int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a>
				4125	</div>
				4126
				4127	<div class="doc_text">
				4128
				4129	<h5>Syntax:</h5>
				4130	<pre>
				4131	declare void @llvm.stackrestore(i8 * %ptr)
				4132	</pre>
				4133
				4134	<h5>Overview:</h5>
				4135
				4136	<p>
				4137	The '<tt>llvm.stackrestore</tt>' intrinsic is used to restore the state of
				4138	the function stack to the state it was in when the corresponding <a
				4139	href="#int_stacksave"><tt>llvm.stacksave</tt></a> intrinsic executed. This is
				4140	useful for implementing language features like scoped automatic variable sized
				4141	arrays in C99.
				4142	</p>
				4143
				4144	<h5>Semantics:</h5>
				4145
				4146	<p>
				4147	See the description for <a href="#int_stacksave"><tt>llvm.stacksave</tt></a>.
				4148	</p>
				4149
				4150	</div>
				4151
				4152
				4153	<!-- _______________________________________________________________________ -->
				4154	<div class="doc_subsubsection">
				4155	<a name="int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a>
				4156	</div>
				4157
				4158	<div class="doc_text">
				4159
				4160	<h5>Syntax:</h5>
				4161	<pre>
				4162	declare void @llvm.prefetch(i8 * <address>,
				4163	i32 <rw>, i32 <locality>)
				4164	</pre>
				4165
				4166	<h5>Overview:</h5>
				4167
				4168
				4169	<p>
				4170	The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to insert
				4171	a prefetch instruction if supported; otherwise, it is a noop. Prefetches have
				4172	no
				4173	effect on the behavior of the program but can change its performance
				4174	characteristics.
				4175	</p>
				4176
				4177	<h5>Arguments:</h5>
				4178
				4179	<p>
				4180	<tt>address</tt> is the address to be prefetched, <tt>rw</tt> is the specifier
				4181	determining if the fetch should be for a read (0) or write (1), and
				4182	<tt>locality</tt> is a temporal locality specifier ranging from (0) - no
				4183	locality, to (3) - extremely local keep in cache. The <tt>rw</tt> and
				4184	<tt>locality</tt> arguments must be constant integers.
				4185	</p>
				4186
				4187	<h5>Semantics:</h5>
				4188
				4189	<p>
				4190	This intrinsic does not modify the behavior of the program. In particular,
				4191	prefetches cannot trap and do not produce a value. On targets that support this
				4192	intrinsic, the prefetch can provide hints to the processor cache for better
				4193	performance.
				4194	</p>
				4195
				4196	</div>
				4197
				4198	<!-- _______________________________________________________________________ -->
				4199	<div class="doc_subsubsection">
				4200	<a name="int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a>
				4201	</div>
				4202
				4203	<div class="doc_text">
				4204
				4205	<h5>Syntax:</h5>
				4206	<pre>
				4207	declare void @llvm.pcmarker( i32 <id> )
				4208	</pre>
				4209
				4210	<h5>Overview:</h5>
				4211
				4212
				4213	<p>
				4214	The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a Program Counter
				4215	(PC) in a region of
				4216	code to simulators and other tools. The method is target specific, but it is
				4217	expected that the marker will use exported symbols to transmit the PC of the marker.
				4218	The marker makes no guarantees that it will remain with any specific instruction
				4219	after optimizations. It is possible that the presence of a marker will inhibit
				4220	optimizations. The intended use is to be inserted after optimizations to allow
				4221	correlations of simulation runs.
				4222	</p>
				4223
				4224	<h5>Arguments:</h5>
				4225
				4226	<p>
				4227	<tt>id</tt> is a numerical id identifying the marker.
				4228	</p>
				4229
				4230	<h5>Semantics:</h5>
				4231
				4232	<p>
				4233	This intrinsic does not modify the behavior of the program. Backends that do not
				4234	support this intrinisic may ignore it.
				4235	</p>
				4236
				4237	</div>
				4238
				4239	<!-- _______________________________________________________________________ -->
				4240	<div class="doc_subsubsection">
				4241	<a name="int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a>
				4242	</div>
				4243
				4244	<div class="doc_text">
				4245
				4246	<h5>Syntax:</h5>
				4247	<pre>
				4248	declare i64 @llvm.readcyclecounter( )
				4249	</pre>
				4250
				4251	<h5>Overview:</h5>
				4252
				4253
				4254	<p>
				4255	The '<tt>llvm.readcyclecounter</tt>' intrinsic provides access to the cycle
				4256	counter register (or similar low latency, high accuracy clocks) on those targets
				4257	that support it. On X86, it should map to RDTSC. On Alpha, it should map to RPCC.
				4258	As the backing counters overflow quickly (on the order of 9 seconds on alpha), this
				4259	should only be used for small timings.
				4260	</p>
				4261
				4262	<h5>Semantics:</h5>
				4263
				4264	<p>
				4265	When directly supported, reading the cycle counter should not modify any memory.
				4266	Implementations are allowed to either return a application specific value or a
				4267	system wide value. On backends without support, this is lowered to a constant 0.
				4268	</p>
				4269
				4270	</div>
				4271
				4272	<!-- ======================================================================= -->
				4273	<div class="doc_subsection">
				4274	<a name="int_libc">Standard C Library Intrinsics</a>
				4275	</div>
				4276
				4277	<div class="doc_text">
				4278	<p>
				4279	LLVM provides intrinsics for a few important standard C library functions.
				4280	These intrinsics allow source-language front-ends to pass information about the
				4281	alignment of the pointer arguments to the code generator, providing opportunity
				4282	for more efficient code generation.
				4283	</p>
				4284
				4285	</div>
				4286
				4287	<!-- _______________________________________________________________________ -->
				4288	<div class="doc_subsubsection">
				4289	<a name="int_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
				4290	</div>
				4291
				4292	<div class="doc_text">
				4293
				4294	<h5>Syntax:</h5>
				4295	<pre>
				4296	declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>,
				4297	i32 <len>, i32 <align>)
				4298	declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>,
				4299	i64 <len>, i32 <align>)
				4300	</pre>
				4301
				4302	<h5>Overview:</h5>
				4303
				4304	<p>
				4305	The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the source
				4306	location to the destination location.
				4307	</p>
				4308
				4309	<p>
				4310	Note that, unlike the standard libc function, the <tt>llvm.memcpy.*</tt>
				4311	intrinsics do not return a value, and takes an extra alignment argument.
				4312	</p>
				4313
				4314	<h5>Arguments:</h5>
				4315
				4316	<p>
				4317	The first argument is a pointer to the destination, the second is a pointer to
				4318	the source. The third argument is an integer argument
				4319	specifying the number of bytes to copy, and the fourth argument is the alignment
				4320	of the source and destination locations.
				4321	</p>
				4322
				4323	<p>
				4324	If the call to this intrinisic has an alignment value that is not 0 or 1, then
				4325	the caller guarantees that both the source and destination pointers are aligned
				4326	to that boundary.
				4327	</p>
				4328
				4329	<h5>Semantics:</h5>
				4330
				4331	<p>
				4332	The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the source
				4333	location to the destination location, which are not allowed to overlap. It
				4334	copies "len" bytes of memory over. If the argument is known to be aligned to
				4335	some boundary, this can be specified as the fourth argument, otherwise it should
				4336	be set to 0 or 1.
				4337	</p>
				4338	</div>
				4339
				4340
				4341	<!-- _______________________________________________________________________ -->
				4342	<div class="doc_subsubsection">
				4343	<a name="int_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
				4344	</div>
				4345
				4346	<div class="doc_text">
				4347
				4348	<h5>Syntax:</h5>
				4349	<pre>
				4350	declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>,
				4351	i32 <len>, i32 <align>)
				4352	declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>,
				4353	i64 <len>, i32 <align>)
				4354	</pre>
				4355
				4356	<h5>Overview:</h5>
				4357
				4358	<p>
				4359	The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the source
				4360	location to the destination location. It is similar to the
				4361	'<tt>llvm.memcmp</tt>' intrinsic but allows the two memory locations to overlap.
				4362	</p>
				4363
				4364	<p>
				4365	Note that, unlike the standard libc function, the <tt>llvm.memmove.*</tt>
				4366	intrinsics do not return a value, and takes an extra alignment argument.
				4367	</p>
				4368
				4369	<h5>Arguments:</h5>
				4370
				4371	<p>
				4372	The first argument is a pointer to the destination, the second is a pointer to
				4373	the source. The third argument is an integer argument
				4374	specifying the number of bytes to copy, and the fourth argument is the alignment
				4375	of the source and destination locations.
				4376	</p>
				4377
				4378	<p>
				4379	If the call to this intrinisic has an alignment value that is not 0 or 1, then
				4380	the caller guarantees that the source and destination pointers are aligned to
				4381	that boundary.
				4382	</p>
				4383
				4384	<h5>Semantics:</h5>
				4385
				4386	<p>
				4387	The '<tt>llvm.memmove.*</tt>' intrinsics copy a block of memory from the source
				4388	location to the destination location, which may overlap. It
				4389	copies "len" bytes of memory over. If the argument is known to be aligned to
				4390	some boundary, this can be specified as the fourth argument, otherwise it should
				4391	be set to 0 or 1.
				4392	</p>
				4393	</div>
				4394
				4395
				4396	<!-- _______________________________________________________________________ -->
				4397	<div class="doc_subsubsection">
				4398	<a name="int_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a>
				4399	</div>
				4400
				4401	<div class="doc_text">
				4402
				4403	<h5>Syntax:</h5>
				4404	<pre>
				4405	declare void @llvm.memset.i32(i8 * <dest>, i8 <val>,
				4406	i32 <len>, i32 <align>)
				4407	declare void @llvm.memset.i64(i8 * <dest>, i8 <val>,
				4408	i64 <len>, i32 <align>)
				4409	</pre>
				4410
				4411	<h5>Overview:</h5>
				4412
				4413	<p>
				4414	The '<tt>llvm.memset.*</tt>' intrinsics fill a block of memory with a particular
				4415	byte value.
				4416	</p>
				4417
				4418	<p>
				4419	Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic
				4420	does not return a value, and takes an extra alignment argument.
				4421	</p>
				4422
				4423	<h5>Arguments:</h5>
				4424
				4425	<p>
				4426	The first argument is a pointer to the destination to fill, the second is the
				4427	byte value to fill it with, the third argument is an integer
				4428	argument specifying the number of bytes to fill, and the fourth argument is the
				4429	known alignment of destination location.
				4430	</p>
				4431
				4432	<p>
				4433	If the call to this intrinisic has an alignment value that is not 0 or 1, then
				4434	the caller guarantees that the destination pointer is aligned to that boundary.
				4435	</p>
				4436
				4437	<h5>Semantics:</h5>
				4438
				4439	<p>
				4440	The '<tt>llvm.memset.*</tt>' intrinsics fill "len" bytes of memory starting at
				4441	the
				4442	destination location. If the argument is known to be aligned to some boundary,
				4443	this can be specified as the fourth argument, otherwise it should be set to 0 or
				4444	1.
				4445	</p>
				4446	</div>
				4447
				4448
				4449	<!-- _______________________________________________________________________ -->
				4450	<div class="doc_subsubsection">
				4451	<a name="int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a>
				4452	</div>
				4453
				4454	<div class="doc_text">
				4455
				4456	<h5>Syntax:</h5>
				4457	<pre>
				4458	declare float @llvm.sqrt.f32(float %Val)
				4459	declare double @llvm.sqrt.f64(double %Val)
				4460	</pre>
				4461
				4462	<h5>Overview:</h5>
				4463
				4464	<p>
				4465	The '<tt>llvm.sqrt</tt>' intrinsics return the sqrt of the specified operand,
				4466	returning the same value as the libm '<tt>sqrt</tt>' function would. Unlike
				4467	<tt>sqrt</tt> in libm, however, <tt>llvm.sqrt</tt> has undefined behavior for
				4468	negative numbers (which allows for better optimization).
				4469	</p>
				4470
				4471	<h5>Arguments:</h5>
				4472
				4473	<p>
				4474	The argument and return value are floating point numbers of the same type.
				4475	</p>
				4476
				4477	<h5>Semantics:</h5>
				4478
				4479	<p>
				4480	This function returns the sqrt of the specified operand if it is a nonnegative
				4481	floating point number.
				4482	</p>
				4483	</div>
				4484
				4485	<!-- _______________________________________________________________________ -->
				4486	<div class="doc_subsubsection">
				4487	<a name="int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a>
				4488	</div>
				4489
				4490	<div class="doc_text">
				4491
				4492	<h5>Syntax:</h5>
				4493	<pre>
				4494	declare float @llvm.powi.f32(float %Val, i32 %power)
				4495	declare double @llvm.powi.f64(double %Val, i32 %power)
				4496	</pre>
				4497
				4498	<h5>Overview:</h5>
				4499
				4500	<p>
				4501	The '<tt>llvm.powi.*</tt>' intrinsics return the first operand raised to the
				4502	specified (positive or negative) power. The order of evaluation of
				4503	multiplications is not defined.
				4504	</p>
				4505
				4506	<h5>Arguments:</h5>
				4507
				4508	<p>
				4509	The second argument is an integer power, and the first is a value to raise to
				4510	that power.
				4511	</p>
				4512
				4513	<h5>Semantics:</h5>
				4514
				4515	<p>
				4516	This function returns the first value raised to the second power with an
				4517	unspecified sequence of rounding operations.</p>
				4518	</div>
				4519
				4520
				4521	<!-- ======================================================================= -->
				4522	<div class="doc_subsection">
				4523	<a name="int_manip">Bit Manipulation Intrinsics</a>
				4524	</div>
				4525
				4526	<div class="doc_text">
				4527	<p>
				4528	LLVM provides intrinsics for a few important bit manipulation operations.
				4529	These allow efficient code generation for some algorithms.
				4530	</p>
				4531
				4532	</div>
				4533
				4534	<!-- _______________________________________________________________________ -->
				4535	<div class="doc_subsubsection">
				4536	<a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a>
				4537	</div>
				4538
				4539	<div class="doc_text">
				4540
				4541	<h5>Syntax:</h5>
				4542	<p>This is an overloaded intrinsic function. You can use bswap on any integer
				4543	type that is an even number of bytes (i.e. BitWidth % 16 == 0). Note the suffix
				4544	that includes the type for the result and the operand.
				4545	<pre>
				4546	declare i16 @llvm.bswap.i16.i16(i16 <id>)
				4547	declare i32 @llvm.bswap.i32.i32(i32 <id>)
				4548	declare i64 @llvm.bswap.i64.i64(i64 <id>)
				4549	</pre>
				4550
				4551	<h5>Overview:</h5>
				4552
				4553	<p>
				4554	The '<tt>llvm.bswap</tt>' family of intrinsics is used to byte swap integer
				4555	values with an even number of bytes (positive multiple of 16 bits). These are
				4556	useful for performing operations on data that is not in the target's native
				4557	byte order.
				4558	</p>
				4559
				4560	<h5>Semantics:</h5>
				4561
				4562	<p>
				4563	The <tt>llvm.bswap.16.i16</tt> intrinsic returns an i16 value that has the high
				4564	and low byte of the input i16 swapped. Similarly, the <tt>llvm.bswap.i32</tt>
				4565	intrinsic returns an i32 value that has the four bytes of the input i32
				4566	swapped, so that if the input bytes are numbered 0, 1, 2, 3 then the returned
				4567	i32 will have its bytes in 3, 2, 1, 0 order. The <tt>llvm.bswap.i48.i48</tt>,
				4568	<tt>llvm.bswap.i64.i64</tt> and other intrinsics extend this concept to
				4569	additional even-byte lengths (6 bytes, 8 bytes and more, respectively).
				4570	</p>
				4571
				4572	</div>
				4573
				4574	<!-- _______________________________________________________________________ -->
				4575	<div class="doc_subsubsection">
				4576	<a name="int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic</a>
				4577	</div>
				4578
				4579	<div class="doc_text">
				4580
				4581	<h5>Syntax:</h5>
				4582	<p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit
				4583	width. Not all targets support all bit widths however.
				4584	<pre>
				4585	declare i32 @llvm.ctpop.i8 (i8 <src>)
				4586	declare i32 @llvm.ctpop.i16(i16 <src>)
				4587	declare i32 @llvm.ctpop.i32(i32 <src>)
				4588	declare i32 @llvm.ctpop.i64(i64 <src>)
				4589	declare i32 @llvm.ctpop.i256(i256 <src>)
				4590	</pre>
				4591
				4592	<h5>Overview:</h5>
				4593
				4594	<p>
				4595	The '<tt>llvm.ctpop</tt>' family of intrinsics counts the number of bits set in a
				4596	value.
				4597	</p>
				4598
				4599	<h5>Arguments:</h5>
				4600
				4601	<p>
				4602	The only argument is the value to be counted. The argument may be of any
				4603	integer type. The return type must match the argument type.
				4604	</p>
				4605
				4606	<h5>Semantics:</h5>
				4607
				4608	<p>
				4609	The '<tt>llvm.ctpop</tt>' intrinsic counts the 1's in a variable.
				4610	</p>
				4611	</div>
				4612
				4613	<!-- _______________________________________________________________________ -->
				4614	<div class="doc_subsubsection">
				4615	<a name="int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic</a>
				4616	</div>
				4617
				4618	<div class="doc_text">
				4619
				4620	<h5>Syntax:</h5>
				4621	<p>This is an overloaded intrinsic. You can use <tt>llvm.ctlz</tt> on any
				4622	integer bit width. Not all targets support all bit widths however.
				4623	<pre>
				4624	declare i32 @llvm.ctlz.i8 (i8 <src>)
				4625	declare i32 @llvm.ctlz.i16(i16 <src>)
				4626	declare i32 @llvm.ctlz.i32(i32 <src>)
				4627	declare i32 @llvm.ctlz.i64(i64 <src>)
				4628	declare i32 @llvm.ctlz.i256(i256 <src>)
				4629	</pre>
				4630
				4631	<h5>Overview:</h5>
				4632
				4633	<p>
				4634	The '<tt>llvm.ctlz</tt>' family of intrinsic functions counts the number of
				4635	leading zeros in a variable.
				4636	</p>
				4637
				4638	<h5>Arguments:</h5>
				4639
				4640	<p>
				4641	The only argument is the value to be counted. The argument may be of any
				4642	integer type. The return type must match the argument type.
				4643	</p>
				4644
				4645	<h5>Semantics:</h5>
				4646
				4647	<p>
				4648	The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant) zeros
				4649	in a variable. If the src == 0 then the result is the size in bits of the type
				4650	of src. For example, <tt>llvm.ctlz(i32 2) = 30</tt>.
				4651	</p>
				4652	</div>
				4653
				4654
				4655
				4656	<!-- _______________________________________________________________________ -->
				4657	<div class="doc_subsubsection">
				4658	<a name="int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic</a>
				4659	</div>
				4660
				4661	<div class="doc_text">
				4662
				4663	<h5>Syntax:</h5>
				4664	<p>This is an overloaded intrinsic. You can use <tt>llvm.cttz</tt> on any
				4665	integer bit width. Not all targets support all bit widths however.
				4666	<pre>
				4667	declare i32 @llvm.cttz.i8 (i8 <src>)
				4668	declare i32 @llvm.cttz.i16(i16 <src>)
				4669	declare i32 @llvm.cttz.i32(i32 <src>)
				4670	declare i32 @llvm.cttz.i64(i64 <src>)
				4671	declare i32 @llvm.cttz.i256(i256 <src>)
				4672	</pre>
				4673
				4674	<h5>Overview:</h5>
				4675
				4676	<p>
				4677	The '<tt>llvm.cttz</tt>' family of intrinsic functions counts the number of
				4678	trailing zeros.
				4679	</p>
				4680
				4681	<h5>Arguments:</h5>
				4682
				4683	<p>
				4684	The only argument is the value to be counted. The argument may be of any
				4685	integer type. The return type must match the argument type.
				4686	</p>
				4687
				4688	<h5>Semantics:</h5>
				4689
				4690	<p>
				4691	The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant) zeros
				4692	in a variable. If the src == 0 then the result is the size in bits of the type
				4693	of src. For example, <tt>llvm.cttz(2) = 1</tt>.
				4694	</p>
				4695	</div>
				4696
				4697	<!-- _______________________________________________________________________ -->
				4698	<div class="doc_subsubsection">
				4699	<a name="int_part_select">'<tt>llvm.part.select.*</tt>' Intrinsic</a>
				4700	</div>
				4701
				4702	<div class="doc_text">
				4703
				4704	<h5>Syntax:</h5>
				4705	<p>This is an overloaded intrinsic. You can use <tt>llvm.part.select</tt>
				4706	on any integer bit width.
				4707	<pre>
				4708	declare i17 @llvm.part.select.i17.i17 (i17 %val, i32 %loBit, i32 %hiBit)
				4709	declare i29 @llvm.part.select.i29.i29 (i29 %val, i32 %loBit, i32 %hiBit)
				4710	</pre>
				4711
				4712	<h5>Overview:</h5>
				4713	<p>The '<tt>llvm.part.select</tt>' family of intrinsic functions selects a
				4714	range of bits from an integer value and returns them in the same bit width as
				4715	the original value.</p>
				4716
				4717	<h5>Arguments:</h5>
				4718	<p>The first argument, <tt>%val</tt> and the result may be integer types of
				4719	any bit width but they must have the same bit width. The second and third
				4720	arguments must be <tt>i32</tt> type since they specify only a bit index.</p>
				4721
				4722	<h5>Semantics:</h5>
				4723	<p>The operation of the '<tt>llvm.part.select</tt>' intrinsic has two modes
				4724	of operation: forwards and reverse. If <tt>%loBit</tt> is greater than
				4725	<tt>%hiBits</tt> then the intrinsic operates in reverse mode. Otherwise it
				4726	operates in forward mode.</p>
				4727	<p>In forward mode, this intrinsic is the equivalent of shifting <tt>%val</tt>
				4728	right by <tt>%loBit</tt> bits and then ANDing it with a mask with
				4729	only the <tt>%hiBit - %loBit</tt> bits set, as follows:</p>
				4730	<ol>
				4731	<li>The <tt>%val</tt> is shifted right (LSHR) by the number of bits specified
				4732	by <tt>%loBits</tt>. This normalizes the value to the low order bits.</li>
				4733	<li>The <tt>%loBits</tt> value is subtracted from the <tt>%hiBits</tt> value
				4734	to determine the number of bits to retain.</li>
				4735	<li>A mask of the retained bits is created by shifting a -1 value.</li>
				4736	<li>The mask is ANDed with <tt>%val</tt> to produce the result.
				4737	</ol>
				4738	<p>In reverse mode, a similar computation is made except that the bits are
				4739	returned in the reverse order. So, for example, if <tt>X</tt> has the value
				4740	<tt>i16 0x0ACF (101011001111)</tt> and we apply
				4741	<tt>part.select(i16 X, 8, 3)</tt> to it, we get back the value
				4742	<tt>i16 0x0026 (000000100110)</tt>.</p>
				4743	</div>
				4744
				4745	<div class="doc_subsubsection">
				4746	<a name="int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic</a>
				4747	</div>
				4748
				4749	<div class="doc_text">
				4750
				4751	<h5>Syntax:</h5>
				4752	<p>This is an overloaded intrinsic. You can use <tt>llvm.part.set</tt>
				4753	on any integer bit width.
				4754	<pre>
				4755	declare i17 @llvm.part.set.i17.i17.i9 (i17 %val, i9 %repl, i32 %lo, i32 %hi)
				4756	declare i29 @llvm.part.set.i29.i29.i9 (i29 %val, i9 %repl, i32 %lo, i32 %hi)
				4757	</pre>
				4758
				4759	<h5>Overview:</h5>
				4760	<p>The '<tt>llvm.part.set</tt>' family of intrinsic functions replaces a range
				4761	of bits in an integer value with another integer value. It returns the integer
				4762	with the replaced bits.</p>
				4763
				4764	<h5>Arguments:</h5>
				4765	<p>The first argument, <tt>%val</tt> and the result may be integer types of
				4766	any bit width but they must have the same bit width. <tt>%val</tt> is the value
				4767	whose bits will be replaced. The second argument, <tt>%repl</tt> may be an
				4768	integer of any bit width. The third and fourth arguments must be <tt>i32</tt>
				4769	type since they specify only a bit index.</p>
				4770
				4771	<h5>Semantics:</h5>
				4772	<p>The operation of the '<tt>llvm.part.set</tt>' intrinsic has two modes
				4773	of operation: forwards and reverse. If <tt>%lo</tt> is greater than
				4774	<tt>%hi</tt> then the intrinsic operates in reverse mode. Otherwise it
				4775	operates in forward mode.</p>
				4776	<p>For both modes, the <tt>%repl</tt> value is prepared for use by either
				4777	truncating it down to the size of the replacement area or zero extending it
				4778	up to that size.</p>
				4779	<p>In forward mode, the bits between <tt>%lo</tt> and <tt>%hi</tt> (inclusive)
				4780	are replaced with corresponding bits from <tt>%repl</tt>. That is the 0th bit
				4781	in <tt>%repl</tt> replaces the <tt>%lo</tt>th bit in <tt>%val</tt> and etc. up
				4782	to the <tt>%hi</tt>th bit.
				4783	<p>In reverse mode, a similar computation is made except that the bits are
				4784	reversed. That is, the <tt>0</tt>th bit in <tt>%repl</tt> replaces the
				4785	<tt>%hi</tt> bit in <tt>%val</tt> and etc. down to the <tt>%lo</tt>th bit.
				4786	<h5>Examples:</h5>
				4787	<pre>
				4788	llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
				4789	llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
				4790	llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F
				4791	llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
				4792	llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
				4793	</pre>
				4794	</div>
				4795
				4796	<!-- ======================================================================= -->
				4797	<div class="doc_subsection">
				4798	<a name="int_debugger">Debugger Intrinsics</a>
				4799	</div>
				4800
				4801	<div class="doc_text">
				4802	<p>
				4803	The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix),
				4804	are described in the <a
				4805	href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source Level
				4806	Debugging</a> document.
				4807	</p>
				4808	</div>
				4809
				4810
				4811	<!-- ======================================================================= -->
				4812	<div class="doc_subsection">
				4813	<a name="int_eh">Exception Handling Intrinsics</a>
				4814	</div>
				4815
				4816	<div class="doc_text">
				4817	<p> The LLVM exception handling intrinsics (which all start with
				4818	<tt>llvm.eh.</tt> prefix), are described in the <a
				4819	href="ExceptionHandling.html#format_common_intrinsics">LLVM Exception
				4820	Handling</a> document. </p>
				4821	</div>
				4822
				4823	<!-- ======================================================================= -->
				4824	<div class="doc_subsection">
				4825	<a name="int_general">General Intrinsics</a>
				4826	</div>
				4827
				4828	<div class="doc_text">
				4829	<p> This class of intrinsics is designed to be generic and has
				4830	no specific purpose. </p>
				4831	</div>
				4832
				4833	<!-- _______________________________________________________________________ -->
				4834	<div class="doc_subsubsection">
				4835	<a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a>
				4836	</div>
				4837
				4838	<div class="doc_text">
				4839
				4840	<h5>Syntax:</h5>
				4841	<pre>
				4842	declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> )
				4843	</pre>
				4844
				4845	<h5>Overview:</h5>
				4846
				4847	<p>
				4848	The '<tt>llvm.var.annotation</tt>' intrinsic
				4849	</p>
				4850
				4851	<h5>Arguments:</h5>
				4852
				4853	<p>
				4854	The first argument is a pointer to a value, the second is a pointer to a
				4855	global string, the third is a pointer to a global string which is the source
				4856	file name, and the last argument is the line number.
				4857	</p>
				4858
				4859	<h5>Semantics:</h5>
				4860
				4861	<p>
				4862	This intrinsic allows annotation of local variables with arbitrary strings.
				4863	This can be useful for special purpose optimizations that want to look for these
				4864	annotations. These have no other defined use, they are ignored by code
				4865	generation and optimization.
				4866	</div>
				4867
				4868
				4869	<!-- *********************************************************************** -->
				4870	<hr>
				4871	<address>
				4872	<a href="http://jigsaw.w3.org/css-validator/check/referer"><img
				4873	src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
				4874	<a href="http://validator.w3.org/check/referer"><img
				4875	src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
				4876
				4877	<a href="mailto:sabre@nondot.org">Chris Lattner</a><br>
				4878	<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
				4879	Last modified: $Date$
				4880	</address>
				4881	</body>
				4882	</html>