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<h1>LLVM Language Reference Manual</h1> 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> 24 <ol> 25 <li><a href="#linkage_private">'<tt>private</tt>' Linkage</a></li> 26 <li><a href="#linkage_linker_private">'<tt>linker_private</tt>' Linkage</a></li> 27 <li><a href="#linkage_linker_private_weak">'<tt>linker_private_weak</tt>' Linkage</a></li> 28 <li><a href="#linkage_linker_private_weak_def_auto">'<tt>linker_private_weak_def_auto</tt>' Linkage</a></li> 29 <li><a href="#linkage_internal">'<tt>internal</tt>' Linkage</a></li> 30 <li><a href="#linkage_available_externally">'<tt>available_externally</tt>' Linkage</a></li> 31 <li><a href="#linkage_linkonce">'<tt>linkonce</tt>' Linkage</a></li> 32 <li><a href="#linkage_common">'<tt>common</tt>' Linkage</a></li> 33 <li><a href="#linkage_weak">'<tt>weak</tt>' Linkage</a></li> 34 <li><a href="#linkage_appending">'<tt>appending</tt>' Linkage</a></li> 35 <li><a href="#linkage_externweak">'<tt>extern_weak</tt>' Linkage</a></li> 36 <li><a href="#linkage_linkonce_odr">'<tt>linkonce_odr</tt>' Linkage</a></li> 37 <li><a href="#linkage_weak">'<tt>weak_odr</tt>' Linkage</a></li> 38 <li><a href="#linkage_external">'<tt>external</tt>' Linkage</a></li> 39 <li><a href="#linkage_dllimport">'<tt>dllimport</tt>' Linkage</a></li> 40 <li><a href="#linkage_dllexport">'<tt>dllexport</tt>' Linkage</a></li> 41 </ol> 42 </li> 43 <li><a href="#callingconv">Calling Conventions</a></li> 44 <li><a href="#namedtypes">Named Types</a></li> 45 <li><a href="#globalvars">Global Variables</a></li> 46 <li><a href="#functionstructure">Functions</a></li> 47 <li><a href="#aliasstructure">Aliases</a></li> 48 <li><a href="#namedmetadatastructure">Named Metadata</a></li> 49 <li><a href="#paramattrs">Parameter Attributes</a></li> 50 <li><a href="#fnattrs">Function Attributes</a></li> 51 <li><a href="#gc">Garbage Collector Names</a></li> 52 <li><a href="#moduleasm">Module-Level Inline Assembly</a></li> 53 <li><a href="#datalayout">Data Layout</a></li> 54 <li><a href="#pointeraliasing">Pointer Aliasing Rules</a></li> 55 <li><a href="#volatile">Volatile Memory Accesses</a></li> 56 <li><a href="#memmodel">Memory Model for Concurrent Operations</a></li> 57 <li><a href="#ordering">Atomic Memory Ordering Constraints</a></li> 58 </ol> 59 </li> 60 <li><a href="#typesystem">Type System</a> 61 <ol> 62 <li><a href="#t_classifications">Type Classifications</a></li> 63 <li><a href="#t_primitive">Primitive Types</a> 64 <ol> 65 <li><a href="#t_integer">Integer Type</a></li> 66 <li><a href="#t_floating">Floating Point Types</a></li> 67 <li><a href="#t_x86mmx">X86mmx Type</a></li> 68 <li><a href="#t_void">Void Type</a></li> 69 <li><a href="#t_label">Label Type</a></li> 70 <li><a href="#t_metadata">Metadata Type</a></li> 71 </ol> 72 </li> 73 <li><a href="#t_derived">Derived Types</a> 74 <ol> 75 <li><a href="#t_aggregate">Aggregate Types</a> 76 <ol> 77 <li><a href="#t_array">Array Type</a></li> 78 <li><a href="#t_struct">Structure Type</a></li> 79 <li><a href="#t_opaque">Opaque Structure Types</a></li> 80 <li><a href="#t_vector">Vector Type</a></li> 81 </ol> 82 </li> 83 <li><a href="#t_function">Function Type</a></li> 84 <li><a href="#t_pointer">Pointer Type</a></li> 85 </ol> 86 </li> 87 </ol> 88 </li> 89 <li><a href="#constants">Constants</a> 90 <ol> 91 <li><a href="#simpleconstants">Simple Constants</a></li> 92 <li><a href="#complexconstants">Complex Constants</a></li> 93 <li><a href="#globalconstants">Global Variable and Function Addresses</a></li> 94 <li><a href="#undefvalues">Undefined Values</a></li> 95 <li><a href="#poisonvalues">Poison Values</a></li> 96 <li><a href="#blockaddress">Addresses of Basic Blocks</a></li> 97 <li><a href="#constantexprs">Constant Expressions</a></li> 98 </ol> 99 </li> 100 <li><a href="#othervalues">Other Values</a> 101 <ol> 102 <li><a href="#inlineasm">Inline Assembler Expressions</a></li> 103 <li><a href="#metadata">Metadata Nodes and Metadata Strings</a> 104 <ol> 105 <li><a href="#tbaa">'<tt>tbaa</tt>' Metadata</a></li> 106 <li><a href="#fpmath">'<tt>fpmath</tt>' Metadata</a></li> 107 <li><a href="#range">'<tt>range</tt>' Metadata</a></li> 108 </ol> 109 </li> 110 </ol> 111 </li> 112 <li><a href="#module_flags">Module Flags Metadata</a> 113 <ol> 114 <li><a href="#objc_gc_flags">Objective-C Garbage Collection Module Flags Metadata</a></li> 115 </ol> 116 </li> 117 <li><a href="#intrinsic_globals">Intrinsic Global Variables</a> 118 <ol> 119 <li><a href="#intg_used">The '<tt>llvm.used</tt>' Global Variable</a></li> 120 <li><a href="#intg_compiler_used">The '<tt>llvm.compiler.used</tt>' 121 Global Variable</a></li> 122 <li><a href="#intg_global_ctors">The '<tt>llvm.global_ctors</tt>' 123 Global Variable</a></li> 124 <li><a href="#intg_global_dtors">The '<tt>llvm.global_dtors</tt>' 125 Global Variable</a></li> 126 </ol> 127 </li> 128 <li><a href="#instref">Instruction Reference</a> 129 <ol> 130 <li><a href="#terminators">Terminator Instructions</a> 131 <ol> 132 <li><a href="#i_ret">'<tt>ret</tt>' Instruction</a></li> 133 <li><a href="#i_br">'<tt>br</tt>' Instruction</a></li> 134 <li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li> 135 <li><a href="#i_indirectbr">'<tt>indirectbr</tt>' Instruction</a></li> 136 <li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li> 137 <li><a href="#i_resume">'<tt>resume</tt>' Instruction</a></li> 138 <li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li> 139 </ol> 140 </li> 141 <li><a href="#binaryops">Binary Operations</a> 142 <ol> 143 <li><a href="#i_add">'<tt>add</tt>' Instruction</a></li> 144 <li><a href="#i_fadd">'<tt>fadd</tt>' Instruction</a></li> 145 <li><a href="#i_sub">'<tt>sub</tt>' Instruction</a></li> 146 <li><a href="#i_fsub">'<tt>fsub</tt>' Instruction</a></li> 147 <li><a href="#i_mul">'<tt>mul</tt>' Instruction</a></li> 148 <li><a href="#i_fmul">'<tt>fmul</tt>' Instruction</a></li> 149 <li><a href="#i_udiv">'<tt>udiv</tt>' Instruction</a></li> 150 <li><a href="#i_sdiv">'<tt>sdiv</tt>' Instruction</a></li> 151 <li><a href="#i_fdiv">'<tt>fdiv</tt>' Instruction</a></li> 152 <li><a href="#i_urem">'<tt>urem</tt>' Instruction</a></li> 153 <li><a href="#i_srem">'<tt>srem</tt>' Instruction</a></li> 154 <li><a href="#i_frem">'<tt>frem</tt>' Instruction</a></li> 155 </ol> 156 </li> 157 <li><a href="#bitwiseops">Bitwise Binary Operations</a> 158 <ol> 159 <li><a href="#i_shl">'<tt>shl</tt>' Instruction</a></li> 160 <li><a href="#i_lshr">'<tt>lshr</tt>' Instruction</a></li> 161 <li><a href="#i_ashr">'<tt>ashr</tt>' Instruction</a></li> 162 <li><a href="#i_and">'<tt>and</tt>' Instruction</a></li> 163 <li><a href="#i_or">'<tt>or</tt>' Instruction</a></li> 164 <li><a href="#i_xor">'<tt>xor</tt>' Instruction</a></li> 165 </ol> 166 </li> 167 <li><a href="#vectorops">Vector Operations</a> 168 <ol> 169 <li><a href="#i_extractelement">'<tt>extractelement</tt>' Instruction</a></li> 170 <li><a href="#i_insertelement">'<tt>insertelement</tt>' Instruction</a></li> 171 <li><a href="#i_shufflevector">'<tt>shufflevector</tt>' Instruction</a></li> 172 </ol> 173 </li> 174 <li><a href="#aggregateops">Aggregate Operations</a> 175 <ol> 176 <li><a href="#i_extractvalue">'<tt>extractvalue</tt>' Instruction</a></li> 177 <li><a href="#i_insertvalue">'<tt>insertvalue</tt>' Instruction</a></li> 178 </ol> 179 </li> 180 <li><a href="#memoryops">Memory Access and Addressing Operations</a> 181 <ol> 182 <li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li> 183 <li><a href="#i_load">'<tt>load</tt>' Instruction</a></li> 184 <li><a href="#i_store">'<tt>store</tt>' Instruction</a></li> 185 <li><a href="#i_fence">'<tt>fence</tt>' Instruction</a></li> 186 <li><a href="#i_cmpxchg">'<tt>cmpxchg</tt>' Instruction</a></li> 187 <li><a href="#i_atomicrmw">'<tt>atomicrmw</tt>' Instruction</a></li> 188 <li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li> 189 </ol> 190 </li> 191 <li><a href="#convertops">Conversion Operations</a> 192 <ol> 193 <li><a href="#i_trunc">'<tt>trunc .. to</tt>' Instruction</a></li> 194 <li><a href="#i_zext">'<tt>zext .. to</tt>' Instruction</a></li> 195 <li><a href="#i_sext">'<tt>sext .. to</tt>' Instruction</a></li> 196 <li><a href="#i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a></li> 197 <li><a href="#i_fpext">'<tt>fpext .. to</tt>' Instruction</a></li> 198 <li><a href="#i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a></li> 199 <li><a href="#i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a></li> 200 <li><a href="#i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a></li> 201 <li><a href="#i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a></li> 202 <li><a href="#i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a></li> 203 <li><a href="#i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a></li> 204 <li><a href="#i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a></li> 205 </ol> 206 </li> 207 <li><a href="#otherops">Other Operations</a> 208 <ol> 209 <li><a href="#i_icmp">'<tt>icmp</tt>' Instruction</a></li> 210 <li><a href="#i_fcmp">'<tt>fcmp</tt>' Instruction</a></li> 211 <li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li> 212 <li><a href="#i_select">'<tt>select</tt>' Instruction</a></li> 213 <li><a href="#i_call">'<tt>call</tt>' Instruction</a></li> 214 <li><a href="#i_va_arg">'<tt>va_arg</tt>' Instruction</a></li> 215 <li><a href="#i_landingpad">'<tt>landingpad</tt>' Instruction</a></li> 216 </ol> 217 </li> 218 </ol> 219 </li> 220 <li><a href="#intrinsics">Intrinsic Functions</a> 221 <ol> 222 <li><a href="#int_varargs">Variable Argument Handling Intrinsics</a> 223 <ol> 224 <li><a href="#int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a></li> 225 <li><a href="#int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a></li> 226 <li><a href="#int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li> 227 </ol> 228 </li> 229 <li><a href="#int_gc">Accurate Garbage Collection Intrinsics</a> 230 <ol> 231 <li><a href="#int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a></li> 232 <li><a href="#int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a></li> 233 <li><a href="#int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a></li> 234 </ol> 235 </li> 236 <li><a href="#int_codegen">Code Generator Intrinsics</a> 237 <ol> 238 <li><a href="#int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li> 239 <li><a href="#int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li> 240 <li><a href="#int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a></li> 241 <li><a href="#int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a></li> 242 <li><a href="#int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a></li> 243 <li><a href="#int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a></li> 244 <li><a href="#int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a></li> 245 </ol> 246 </li> 247 <li><a href="#int_libc">Standard C Library Intrinsics</a> 248 <ol> 249 <li><a href="#int_memcpy">'<tt>llvm.memcpy.*</tt>' Intrinsic</a></li> 250 <li><a href="#int_memmove">'<tt>llvm.memmove.*</tt>' Intrinsic</a></li> 251 <li><a href="#int_memset">'<tt>llvm.memset.*</tt>' Intrinsic</a></li> 252 <li><a href="#int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a></li> 253 <li><a href="#int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a></li> 254 <li><a href="#int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a></li> 255 <li><a href="#int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a></li> 256 <li><a href="#int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a></li> 257 <li><a href="#int_exp">'<tt>llvm.exp.*</tt>' Intrinsic</a></li> 258 <li><a href="#int_log">'<tt>llvm.log.*</tt>' Intrinsic</a></li> 259 <li><a href="#int_fma">'<tt>llvm.fma.*</tt>' Intrinsic</a></li> 260 </ol> 261 </li> 262 <li><a href="#int_manip">Bit Manipulation Intrinsics</a> 263 <ol> 264 <li><a href="#int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a></li> 265 <li><a href="#int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic </a></li> 266 <li><a href="#int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic </a></li> 267 <li><a href="#int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic </a></li> 268 </ol> 269 </li> 270 <li><a href="#int_overflow">Arithmetic with Overflow Intrinsics</a> 271 <ol> 272 <li><a href="#int_sadd_overflow">'<tt>llvm.sadd.with.overflow.*</tt> Intrinsics</a></li> 273 <li><a href="#int_uadd_overflow">'<tt>llvm.uadd.with.overflow.*</tt> Intrinsics</a></li> 274 <li><a href="#int_ssub_overflow">'<tt>llvm.ssub.with.overflow.*</tt> Intrinsics</a></li> 275 <li><a href="#int_usub_overflow">'<tt>llvm.usub.with.overflow.*</tt> Intrinsics</a></li> 276 <li><a href="#int_smul_overflow">'<tt>llvm.smul.with.overflow.*</tt> Intrinsics</a></li> 277 <li><a href="#int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt> Intrinsics</a></li> 278 </ol> 279 </li> 280 <li><a href="#int_fp16">Half Precision Floating Point Intrinsics</a> 281 <ol> 282 <li><a href="#int_convert_to_fp16">'<tt>llvm.convert.to.fp16</tt>' Intrinsic</a></li> 283 <li><a href="#int_convert_from_fp16">'<tt>llvm.convert.from.fp16</tt>' Intrinsic</a></li> 284 </ol> 285 </li> 286 <li><a href="#int_debugger">Debugger intrinsics</a></li> 287 <li><a href="#int_eh">Exception Handling intrinsics</a></li> 288 <li><a href="#int_trampoline">Trampoline Intrinsics</a> 289 <ol> 290 <li><a href="#int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a></li> 291 <li><a href="#int_at">'<tt>llvm.adjust.trampoline</tt>' Intrinsic</a></li> 292 </ol> 293 </li> 294 <li><a href="#int_memorymarkers">Memory Use Markers</a> 295 <ol> 296 <li><a href="#int_lifetime_start">'<tt>llvm.lifetime.start</tt>' Intrinsic</a></li> 297 <li><a href="#int_lifetime_end">'<tt>llvm.lifetime.end</tt>' Intrinsic</a></li> 298 <li><a href="#int_invariant_start">'<tt>llvm.invariant.start</tt>' Intrinsic</a></li> 299 <li><a href="#int_invariant_end">'<tt>llvm.invariant.end</tt>' Intrinsic</a></li> 300 </ol> 301 </li> 302 <li><a href="#int_general">General intrinsics</a> 303 <ol> 304 <li><a href="#int_var_annotation"> 305 '<tt>llvm.var.annotation</tt>' Intrinsic</a></li> 306 <li><a href="#int_annotation"> 307 '<tt>llvm.annotation.*</tt>' Intrinsic</a></li> 308 <li><a href="#int_trap"> 309 '<tt>llvm.trap</tt>' Intrinsic</a></li> 310 <li><a href="#int_stackprotector"> 311 '<tt>llvm.stackprotector</tt>' Intrinsic</a></li> 312 <li><a href="#int_objectsize"> 313 '<tt>llvm.objectsize</tt>' Intrinsic</a></li> 314 <li><a href="#int_expect"> 315 '<tt>llvm.expect</tt>' Intrinsic</a></li> 316 </ol> 317 </li> 318 </ol> 319 </li> 320</ol> 321 322<div class="doc_author"> 323 <p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> 324 and <a href="mailto:vadve@cs.uiuc.edu">Vikram Adve</a></p> 325</div> 326 327<!-- *********************************************************************** --> 328<h2><a name="abstract">Abstract</a></h2> 329<!-- *********************************************************************** --> 330 331<div> 332 333<p>This document is a reference manual for the LLVM assembly language. LLVM is 334 a Static Single Assignment (SSA) based representation that provides type 335 safety, low-level operations, flexibility, and the capability of representing 336 'all' high-level languages cleanly. It is the common code representation 337 used throughout all phases of the LLVM compilation strategy.</p> 338 339</div> 340 341<!-- *********************************************************************** --> 342<h2><a name="introduction">Introduction</a></h2> 343<!-- *********************************************************************** --> 344 345<div> 346 347<p>The LLVM code representation is designed to be used in three different forms: 348 as an in-memory compiler IR, as an on-disk bitcode representation (suitable 349 for fast loading by a Just-In-Time compiler), and as a human readable 350 assembly language representation. This allows LLVM to provide a powerful 351 intermediate representation for efficient compiler transformations and 352 analysis, while providing a natural means to debug and visualize the 353 transformations. The three different forms of LLVM are all equivalent. This 354 document describes the human readable representation and notation.</p> 355 356<p>The LLVM representation aims to be light-weight and low-level while being 357 expressive, typed, and extensible at the same time. It aims to be a 358 "universal IR" of sorts, by being at a low enough level that high-level ideas 359 may be cleanly mapped to it (similar to how microprocessors are "universal 360 IR's", allowing many source languages to be mapped to them). By providing 361 type information, LLVM can be used as the target of optimizations: for 362 example, through pointer analysis, it can be proven that a C automatic 363 variable is never accessed outside of the current function, allowing it to 364 be promoted to a simple SSA value instead of a memory location.</p> 365 366<!-- _______________________________________________________________________ --> 367<h4> 368 <a name="wellformed">Well-Formedness</a> 369</h4> 370 371<div> 372 373<p>It is important to note that this document describes 'well formed' LLVM 374 assembly language. There is a difference between what the parser accepts and 375 what is considered 'well formed'. For example, the following instruction is 376 syntactically okay, but not well formed:</p> 377 378<pre class="doc_code"> 379%x = <a href="#i_add">add</a> i32 1, %x 380</pre> 381 382<p>because the definition of <tt>%x</tt> does not dominate all of its uses. The 383 LLVM infrastructure provides a verification pass that may be used to verify 384 that an LLVM module is well formed. This pass is automatically run by the 385 parser after parsing input assembly and by the optimizer before it outputs 386 bitcode. The violations pointed out by the verifier pass indicate bugs in 387 transformation passes or input to the parser.</p> 388 389</div> 390 391</div> 392 393<!-- Describe the typesetting conventions here. --> 394 395<!-- *********************************************************************** --> 396<h2><a name="identifiers">Identifiers</a></h2> 397<!-- *********************************************************************** --> 398 399<div> 400 401<p>LLVM identifiers come in two basic types: global and local. Global 402 identifiers (functions, global variables) begin with the <tt>'@'</tt> 403 character. Local identifiers (register names, types) begin with 404 the <tt>'%'</tt> character. Additionally, there are three different formats 405 for identifiers, for different purposes:</p> 406 407<ol> 408 <li>Named values are represented as a string of characters with their prefix. 409 For example, <tt>%foo</tt>, <tt>@DivisionByZero</tt>, 410 <tt>%a.really.long.identifier</tt>. The actual regular expression used is 411 '<tt>[%@][a-zA-Z$._][a-zA-Z$._0-9]*</tt>'. Identifiers which require 412 other characters in their names can be surrounded with quotes. Special 413 characters may be escaped using <tt>"\xx"</tt> where <tt>xx</tt> is the 414 ASCII code for the character in hexadecimal. In this way, any character 415 can be used in a name value, even quotes themselves.</li> 416 417 <li>Unnamed values are represented as an unsigned numeric value with their 418 prefix. For example, <tt>%12</tt>, <tt>@2</tt>, <tt>%44</tt>.</li> 419 420 <li>Constants, which are described in a <a href="#constants">section about 421 constants</a>, below.</li> 422</ol> 423 424<p>LLVM requires that values start with a prefix for two reasons: Compilers 425 don't need to worry about name clashes with reserved words, and the set of 426 reserved words may be expanded in the future without penalty. Additionally, 427 unnamed identifiers allow a compiler to quickly come up with a temporary 428 variable without having to avoid symbol table conflicts.</p> 429 430<p>Reserved words in LLVM are very similar to reserved words in other 431 languages. There are keywords for different opcodes 432 ('<tt><a href="#i_add">add</a></tt>', 433 '<tt><a href="#i_bitcast">bitcast</a></tt>', 434 '<tt><a href="#i_ret">ret</a></tt>', etc...), for primitive type names 435 ('<tt><a href="#t_void">void</a></tt>', 436 '<tt><a href="#t_primitive">i32</a></tt>', etc...), and others. These 437 reserved words cannot conflict with variable names, because none of them 438 start with a prefix character (<tt>'%'</tt> or <tt>'@'</tt>).</p> 439 440<p>Here is an example of LLVM code to multiply the integer variable 441 '<tt>%X</tt>' by 8:</p> 442 443<p>The easy way:</p> 444 445<pre class="doc_code"> 446%result = <a href="#i_mul">mul</a> i32 %X, 8 447</pre> 448 449<p>After strength reduction:</p> 450 451<pre class="doc_code"> 452%result = <a href="#i_shl">shl</a> i32 %X, i8 3 453</pre> 454 455<p>And the hard way:</p> 456 457<pre class="doc_code"> 458%0 = <a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i> 459%1 = <a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i> 460%result = <a href="#i_add">add</a> i32 %1, %1 461</pre> 462 463<p>This last way of multiplying <tt>%X</tt> by 8 illustrates several important 464 lexical features of LLVM:</p> 465 466<ol> 467 <li>Comments are delimited with a '<tt>;</tt>' and go until the end of 468 line.</li> 469 470 <li>Unnamed temporaries are created when the result of a computation is not 471 assigned to a named value.</li> 472 473 <li>Unnamed temporaries are numbered sequentially</li> 474</ol> 475 476<p>It also shows a convention that we follow in this document. When 477 demonstrating instructions, we will follow an instruction with a comment that 478 defines the type and name of value produced. Comments are shown in italic 479 text.</p> 480 481</div> 482 483<!-- *********************************************************************** --> 484<h2><a name="highlevel">High Level Structure</a></h2> 485<!-- *********************************************************************** --> 486<div> 487<!-- ======================================================================= --> 488<h3> 489 <a name="modulestructure">Module Structure</a> 490</h3> 491 492<div> 493 494<p>LLVM programs are composed of <tt>Module</tt>s, each of which is a 495 translation unit of the input programs. Each module consists of functions, 496 global variables, and symbol table entries. Modules may be combined together 497 with the LLVM linker, which merges function (and global variable) 498 definitions, resolves forward declarations, and merges symbol table 499 entries. Here is an example of the "hello world" module:</p> 500 501<pre class="doc_code"> 502<i>; Declare the string constant as a global constant.</i> 503<a href="#identifiers">@.str</a> = <a href="#linkage_private">private</a> <a href="#globalvars">unnamed_addr</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" 504 505<i>; External declaration of the puts function</i> 506<a href="#functionstructure">declare</a> i32 @puts(i8* <a href="#nocapture">nocapture</a>) <a href="#fnattrs">nounwind</a> 507 508<i>; Definition of main function</i> 509define i32 @main() { <i>; i32()* </i> 510 <i>; Convert [13 x i8]* to i8 *...</i> 511 %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.str, i64 0, i64 0 512 513 <i>; Call puts function to write out the string to stdout.</i> 514 <a href="#i_call">call</a> i32 @puts(i8* %cast210) 515 <a href="#i_ret">ret</a> i32 0 516} 517 518<i>; Named metadata</i> 519!1 = metadata !{i32 42} 520!foo = !{!1, null} 521</pre> 522 523<p>This example is made up of a <a href="#globalvars">global variable</a> named 524 "<tt>.str</tt>", an external declaration of the "<tt>puts</tt>" function, 525 a <a href="#functionstructure">function definition</a> for 526 "<tt>main</tt>" and <a href="#namedmetadatastructure">named metadata</a> 527 "<tt>foo</tt>".</p> 528 529<p>In general, a module is made up of a list of global values (where both 530 functions and global variables are global values). Global values are 531 represented by a pointer to a memory location (in this case, a pointer to an 532 array of char, and a pointer to a function), and have one of the 533 following <a href="#linkage">linkage types</a>.</p> 534 535</div> 536 537<!-- ======================================================================= --> 538<h3> 539 <a name="linkage">Linkage Types</a> 540</h3> 541 542<div> 543 544<p>All Global Variables and Functions have one of the following types of 545 linkage:</p> 546 547<dl> 548 <dt><tt><b><a name="linkage_private">private</a></b></tt></dt> 549 <dd>Global values with "<tt>private</tt>" linkage are only directly accessible 550 by objects in the current module. In particular, linking code into a 551 module with an private global value may cause the private to be renamed as 552 necessary to avoid collisions. Because the symbol is private to the 553 module, all references can be updated. This doesn't show up in any symbol 554 table in the object file.</dd> 555 556 <dt><tt><b><a name="linkage_linker_private">linker_private</a></b></tt></dt> 557 <dd>Similar to <tt>private</tt>, but the symbol is passed through the 558 assembler and evaluated by the linker. Unlike normal strong symbols, they 559 are removed by the linker from the final linked image (executable or 560 dynamic library).</dd> 561 562 <dt><tt><b><a name="linkage_linker_private_weak">linker_private_weak</a></b></tt></dt> 563 <dd>Similar to "<tt>linker_private</tt>", but the symbol is weak. Note that 564 <tt>linker_private_weak</tt> symbols are subject to coalescing by the 565 linker. The symbols are removed by the linker from the final linked image 566 (executable or dynamic library).</dd> 567 568 <dt><tt><b><a name="linkage_linker_private_weak_def_auto">linker_private_weak_def_auto</a></b></tt></dt> 569 <dd>Similar to "<tt>linker_private_weak</tt>", but it's known that the address 570 of the object is not taken. For instance, functions that had an inline 571 definition, but the compiler decided not to inline it. Note, 572 unlike <tt>linker_private</tt> and <tt>linker_private_weak</tt>, 573 <tt>linker_private_weak_def_auto</tt> may have only <tt>default</tt> 574 visibility. The symbols are removed by the linker from the final linked 575 image (executable or dynamic library).</dd> 576 577 <dt><tt><b><a name="linkage_internal">internal</a></b></tt></dt> 578 <dd>Similar to private, but the value shows as a local symbol 579 (<tt>STB_LOCAL</tt> in the case of ELF) in the object file. This 580 corresponds to the notion of the '<tt>static</tt>' keyword in C.</dd> 581 582 <dt><tt><b><a name="linkage_available_externally">available_externally</a></b></tt></dt> 583 <dd>Globals with "<tt>available_externally</tt>" linkage are never emitted 584 into the object file corresponding to the LLVM module. They exist to 585 allow inlining and other optimizations to take place given knowledge of 586 the definition of the global, which is known to be somewhere outside the 587 module. Globals with <tt>available_externally</tt> linkage are allowed to 588 be discarded at will, and are otherwise the same as <tt>linkonce_odr</tt>. 589 This linkage type is only allowed on definitions, not declarations.</dd> 590 591 <dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt></dt> 592 <dd>Globals with "<tt>linkonce</tt>" linkage are merged with other globals of 593 the same name when linkage occurs. This can be used to implement 594 some forms of inline functions, templates, or other code which must be 595 generated in each translation unit that uses it, but where the body may 596 be overridden with a more definitive definition later. Unreferenced 597 <tt>linkonce</tt> globals are allowed to be discarded. Note that 598 <tt>linkonce</tt> linkage does not actually allow the optimizer to 599 inline the body of this function into callers because it doesn't know if 600 this definition of the function is the definitive definition within the 601 program or whether it will be overridden by a stronger definition. 602 To enable inlining and other optimizations, use "<tt>linkonce_odr</tt>" 603 linkage.</dd> 604 605 <dt><tt><b><a name="linkage_weak">weak</a></b></tt></dt> 606 <dd>"<tt>weak</tt>" linkage has the same merging semantics as 607 <tt>linkonce</tt> linkage, except that unreferenced globals with 608 <tt>weak</tt> linkage may not be discarded. This is used for globals that 609 are declared "weak" in C source code.</dd> 610 611 <dt><tt><b><a name="linkage_common">common</a></b></tt></dt> 612 <dd>"<tt>common</tt>" linkage is most similar to "<tt>weak</tt>" linkage, but 613 they are used for tentative definitions in C, such as "<tt>int X;</tt>" at 614 global scope. 615 Symbols with "<tt>common</tt>" linkage are merged in the same way as 616 <tt>weak symbols</tt>, and they may not be deleted if unreferenced. 617 <tt>common</tt> symbols may not have an explicit section, 618 must have a zero initializer, and may not be marked '<a 619 href="#globalvars"><tt>constant</tt></a>'. Functions and aliases may not 620 have common linkage.</dd> 621 622 623 <dt><tt><b><a name="linkage_appending">appending</a></b></tt></dt> 624 <dd>"<tt>appending</tt>" linkage may only be applied to global variables of 625 pointer to array type. When two global variables with appending linkage 626 are linked together, the two global arrays are appended together. This is 627 the LLVM, typesafe, equivalent of having the system linker append together 628 "sections" with identical names when .o files are linked.</dd> 629 630 <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt></dt> 631 <dd>The semantics of this linkage follow the ELF object file model: the symbol 632 is weak until linked, if not linked, the symbol becomes null instead of 633 being an undefined reference.</dd> 634 635 <dt><tt><b><a name="linkage_linkonce_odr">linkonce_odr</a></b></tt></dt> 636 <dt><tt><b><a name="linkage_weak_odr">weak_odr</a></b></tt></dt> 637 <dd>Some languages allow differing globals to be merged, such as two functions 638 with different semantics. Other languages, such as <tt>C++</tt>, ensure 639 that only equivalent globals are ever merged (the "one definition rule" 640 — "ODR"). Such languages can use the <tt>linkonce_odr</tt> 641 and <tt>weak_odr</tt> linkage types to indicate that the global will only 642 be merged with equivalent globals. These linkage types are otherwise the 643 same as their non-<tt>odr</tt> versions.</dd> 644 645 <dt><tt><b><a name="linkage_external">external</a></b></tt></dt> 646 <dd>If none of the above identifiers are used, the global is externally 647 visible, meaning that it participates in linkage and can be used to 648 resolve external symbol references.</dd> 649</dl> 650 651<p>The next two types of linkage are targeted for Microsoft Windows platform 652 only. They are designed to support importing (exporting) symbols from (to) 653 DLLs (Dynamic Link Libraries).</p> 654 655<dl> 656 <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt></dt> 657 <dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function 658 or variable via a global pointer to a pointer that is set up by the DLL 659 exporting the symbol. On Microsoft Windows targets, the pointer name is 660 formed by combining <code>__imp_</code> and the function or variable 661 name.</dd> 662 663 <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt></dt> 664 <dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global 665 pointer to a pointer in a DLL, so that it can be referenced with the 666 <tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer 667 name is formed by combining <code>__imp_</code> and the function or 668 variable name.</dd> 669</dl> 670 671<p>For example, since the "<tt>.LC0</tt>" variable is defined to be internal, if 672 another module defined a "<tt>.LC0</tt>" variable and was linked with this 673 one, one of the two would be renamed, preventing a collision. Since 674 "<tt>main</tt>" and "<tt>puts</tt>" are external (i.e., lacking any linkage 675 declarations), they are accessible outside of the current module.</p> 676 677<p>It is illegal for a function <i>declaration</i> to have any linkage type 678 other than <tt>external</tt>, <tt>dllimport</tt> 679 or <tt>extern_weak</tt>.</p> 680 681<p>Aliases can have only <tt>external</tt>, <tt>internal</tt>, <tt>weak</tt> 682 or <tt>weak_odr</tt> linkages.</p> 683 684</div> 685 686<!-- ======================================================================= --> 687<h3> 688 <a name="callingconv">Calling Conventions</a> 689</h3> 690 691<div> 692 693<p>LLVM <a href="#functionstructure">functions</a>, <a href="#i_call">calls</a> 694 and <a href="#i_invoke">invokes</a> can all have an optional calling 695 convention specified for the call. The calling convention of any pair of 696 dynamic caller/callee must match, or the behavior of the program is 697 undefined. The following calling conventions are supported by LLVM, and more 698 may be added in the future:</p> 699 700<dl> 701 <dt><b>"<tt>ccc</tt>" - The C calling convention</b>:</dt> 702 <dd>This calling convention (the default if no other calling convention is 703 specified) matches the target C calling conventions. This calling 704 convention supports varargs function calls and tolerates some mismatch in 705 the declared prototype and implemented declaration of the function (as 706 does normal C).</dd> 707 708 <dt><b>"<tt>fastcc</tt>" - The fast calling convention</b>:</dt> 709 <dd>This calling convention attempts to make calls as fast as possible 710 (e.g. by passing things in registers). This calling convention allows the 711 target to use whatever tricks it wants to produce fast code for the 712 target, without having to conform to an externally specified ABI 713 (Application Binary Interface). 714 <a href="CodeGenerator.html#tailcallopt">Tail calls can only be optimized 715 when this or the GHC convention is used.</a> This calling convention 716 does not support varargs and requires the prototype of all callees to 717 exactly match the prototype of the function definition.</dd> 718 719 <dt><b>"<tt>coldcc</tt>" - The cold calling convention</b>:</dt> 720 <dd>This calling convention attempts to make code in the caller as efficient 721 as possible under the assumption that the call is not commonly executed. 722 As such, these calls often preserve all registers so that the call does 723 not break any live ranges in the caller side. This calling convention 724 does not support varargs and requires the prototype of all callees to 725 exactly match the prototype of the function definition.</dd> 726 727 <dt><b>"<tt>cc <em>10</em></tt>" - GHC convention</b>:</dt> 728 <dd>This calling convention has been implemented specifically for use by the 729 <a href="http://www.haskell.org/ghc">Glasgow Haskell Compiler (GHC)</a>. 730 It passes everything in registers, going to extremes to achieve this by 731 disabling callee save registers. This calling convention should not be 732 used lightly but only for specific situations such as an alternative to 733 the <em>register pinning</em> performance technique often used when 734 implementing functional programming languages.At the moment only X86 735 supports this convention and it has the following limitations: 736 <ul> 737 <li>On <em>X86-32</em> only supports up to 4 bit type parameters. No 738 floating point types are supported.</li> 739 <li>On <em>X86-64</em> only supports up to 10 bit type parameters and 740 6 floating point parameters.</li> 741 </ul> 742 This calling convention supports 743 <a href="CodeGenerator.html#tailcallopt">tail call optimization</a> but 744 requires both the caller and callee are using it. 745 </dd> 746 747 <dt><b>"<tt>cc <<em>n</em>></tt>" - Numbered convention</b>:</dt> 748 <dd>Any calling convention may be specified by number, allowing 749 target-specific calling conventions to be used. Target specific calling 750 conventions start at 64.</dd> 751</dl> 752 753<p>More calling conventions can be added/defined on an as-needed basis, to 754 support Pascal conventions or any other well-known target-independent 755 convention.</p> 756 757</div> 758 759<!-- ======================================================================= --> 760<h3> 761 <a name="visibility">Visibility Styles</a> 762</h3> 763 764<div> 765 766<p>All Global Variables and Functions have one of the following visibility 767 styles:</p> 768 769<dl> 770 <dt><b>"<tt>default</tt>" - Default style</b>:</dt> 771 <dd>On targets that use the ELF object file format, default visibility means 772 that the declaration is visible to other modules and, in shared libraries, 773 means that the declared entity may be overridden. On Darwin, default 774 visibility means that the declaration is visible to other modules. Default 775 visibility corresponds to "external linkage" in the language.</dd> 776 777 <dt><b>"<tt>hidden</tt>" - Hidden style</b>:</dt> 778 <dd>Two declarations of an object with hidden visibility refer to the same 779 object if they are in the same shared object. Usually, hidden visibility 780 indicates that the symbol will not be placed into the dynamic symbol 781 table, so no other module (executable or shared library) can reference it 782 directly.</dd> 783 784 <dt><b>"<tt>protected</tt>" - Protected style</b>:</dt> 785 <dd>On ELF, protected visibility indicates that the symbol will be placed in 786 the dynamic symbol table, but that references within the defining module 787 will bind to the local symbol. That is, the symbol cannot be overridden by 788 another module.</dd> 789</dl> 790 791</div> 792 793<!-- ======================================================================= --> 794<h3> 795 <a name="namedtypes">Named Types</a> 796</h3> 797 798<div> 799 800<p>LLVM IR allows you to specify name aliases for certain types. This can make 801 it easier to read the IR and make the IR more condensed (particularly when 802 recursive types are involved). An example of a name specification is:</p> 803 804<pre class="doc_code"> 805%mytype = type { %mytype*, i32 } 806</pre> 807 808<p>You may give a name to any <a href="#typesystem">type</a> except 809 "<a href="#t_void">void</a>". Type name aliases may be used anywhere a type 810 is expected with the syntax "%mytype".</p> 811 812<p>Note that type names are aliases for the structural type that they indicate, 813 and that you can therefore specify multiple names for the same type. This 814 often leads to confusing behavior when dumping out a .ll file. Since LLVM IR 815 uses structural typing, the name is not part of the type. When printing out 816 LLVM IR, the printer will pick <em>one name</em> to render all types of a 817 particular shape. This means that if you have code where two different 818 source types end up having the same LLVM type, that the dumper will sometimes 819 print the "wrong" or unexpected type. This is an important design point and 820 isn't going to change.</p> 821 822</div> 823 824<!-- ======================================================================= --> 825<h3> 826 <a name="globalvars">Global Variables</a> 827</h3> 828 829<div> 830 831<p>Global variables define regions of memory allocated at compilation time 832 instead of run-time. Global variables may optionally be initialized, may 833 have an explicit section to be placed in, and may have an optional explicit 834 alignment specified. A variable may be defined as "thread_local", which 835 means that it will not be shared by threads (each thread will have a 836 separated copy of the variable). A variable may be defined as a global 837 "constant," which indicates that the contents of the variable 838 will <b>never</b> be modified (enabling better optimization, allowing the 839 global data to be placed in the read-only section of an executable, etc). 840 Note that variables that need runtime initialization cannot be marked 841 "constant" as there is a store to the variable.</p> 842 843<p>LLVM explicitly allows <em>declarations</em> of global variables to be marked 844 constant, even if the final definition of the global is not. This capability 845 can be used to enable slightly better optimization of the program, but 846 requires the language definition to guarantee that optimizations based on the 847 'constantness' are valid for the translation units that do not include the 848 definition.</p> 849 850<p>As SSA values, global variables define pointer values that are in scope 851 (i.e. they dominate) all basic blocks in the program. Global variables 852 always define a pointer to their "content" type because they describe a 853 region of memory, and all memory objects in LLVM are accessed through 854 pointers.</p> 855 856<p>Global variables can be marked with <tt>unnamed_addr</tt> which indicates 857 that the address is not significant, only the content. Constants marked 858 like this can be merged with other constants if they have the same 859 initializer. Note that a constant with significant address <em>can</em> 860 be merged with a <tt>unnamed_addr</tt> constant, the result being a 861 constant whose address is significant.</p> 862 863<p>A global variable may be declared to reside in a target-specific numbered 864 address space. For targets that support them, address spaces may affect how 865 optimizations are performed and/or what target instructions are used to 866 access the variable. The default address space is zero. The address space 867 qualifier must precede any other attributes.</p> 868 869<p>LLVM allows an explicit section to be specified for globals. If the target 870 supports it, it will emit globals to the section specified.</p> 871 872<p>An explicit alignment may be specified for a global, which must be a power 873 of 2. If not present, or if the alignment is set to zero, the alignment of 874 the global is set by the target to whatever it feels convenient. If an 875 explicit alignment is specified, the global is forced to have exactly that 876 alignment. Targets and optimizers are not allowed to over-align the global 877 if the global has an assigned section. In this case, the extra alignment 878 could be observable: for example, code could assume that the globals are 879 densely packed in their section and try to iterate over them as an array, 880 alignment padding would break this iteration.</p> 881 882<p>For example, the following defines a global in a numbered address space with 883 an initializer, section, and alignment:</p> 884 885<pre class="doc_code"> 886@G = addrspace(5) constant float 1.0, section "foo", align 4 887</pre> 888 889</div> 890 891 892<!-- ======================================================================= --> 893<h3> 894 <a name="functionstructure">Functions</a> 895</h3> 896 897<div> 898 899<p>LLVM function definitions consist of the "<tt>define</tt>" keyword, an 900 optional <a href="#linkage">linkage type</a>, an optional 901 <a href="#visibility">visibility style</a>, an optional 902 <a href="#callingconv">calling convention</a>, 903 an optional <tt>unnamed_addr</tt> attribute, a return type, an optional 904 <a href="#paramattrs">parameter attribute</a> for the return type, a function 905 name, a (possibly empty) argument list (each with optional 906 <a href="#paramattrs">parameter attributes</a>), optional 907 <a href="#fnattrs">function attributes</a>, an optional section, an optional 908 alignment, an optional <a href="#gc">garbage collector name</a>, an opening 909 curly brace, a list of basic blocks, and a closing curly brace.</p> 910 911<p>LLVM function declarations consist of the "<tt>declare</tt>" keyword, an 912 optional <a href="#linkage">linkage type</a>, an optional 913 <a href="#visibility">visibility style</a>, an optional 914 <a href="#callingconv">calling convention</a>, 915 an optional <tt>unnamed_addr</tt> attribute, a return type, an optional 916 <a href="#paramattrs">parameter attribute</a> for the return type, a function 917 name, a possibly empty list of arguments, an optional alignment, and an 918 optional <a href="#gc">garbage collector name</a>.</p> 919 920<p>A function definition contains a list of basic blocks, forming the CFG 921 (Control Flow Graph) for the function. Each basic block may optionally start 922 with a label (giving the basic block a symbol table entry), contains a list 923 of instructions, and ends with a <a href="#terminators">terminator</a> 924 instruction (such as a branch or function return).</p> 925 926<p>The first basic block in a function is special in two ways: it is immediately 927 executed on entrance to the function, and it is not allowed to have 928 predecessor basic blocks (i.e. there can not be any branches to the entry 929 block of a function). Because the block can have no predecessors, it also 930 cannot have any <a href="#i_phi">PHI nodes</a>.</p> 931 932<p>LLVM allows an explicit section to be specified for functions. If the target 933 supports it, it will emit functions to the section specified.</p> 934 935<p>An explicit alignment may be specified for a function. If not present, or if 936 the alignment is set to zero, the alignment of the function is set by the 937 target to whatever it feels convenient. If an explicit alignment is 938 specified, the function is forced to have at least that much alignment. All 939 alignments must be a power of 2.</p> 940 941<p>If the <tt>unnamed_addr</tt> attribute is given, the address is know to not 942 be significant and two identical functions can be merged.</p> 943 944<h5>Syntax:</h5> 945<pre class="doc_code"> 946define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>] 947 [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] 948 <ResultType> @<FunctionName> ([argument list]) 949 [<a href="#fnattrs">fn Attrs</a>] [section "name"] [align N] 950 [<a href="#gc">gc</a>] { ... } 951</pre> 952 953</div> 954 955<!-- ======================================================================= --> 956<h3> 957 <a name="aliasstructure">Aliases</a> 958</h3> 959 960<div> 961 962<p>Aliases act as "second name" for the aliasee value (which can be either 963 function, global variable, another alias or bitcast of global value). Aliases 964 may have an optional <a href="#linkage">linkage type</a>, and an 965 optional <a href="#visibility">visibility style</a>.</p> 966 967<h5>Syntax:</h5> 968<pre class="doc_code"> 969@<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee> 970</pre> 971 972</div> 973 974<!-- ======================================================================= --> 975<h3> 976 <a name="namedmetadatastructure">Named Metadata</a> 977</h3> 978 979<div> 980 981<p>Named metadata is a collection of metadata. <a href="#metadata">Metadata 982 nodes</a> (but not metadata strings) are the only valid operands for 983 a named metadata.</p> 984 985<h5>Syntax:</h5> 986<pre class="doc_code"> 987; Some unnamed metadata nodes, which are referenced by the named metadata. 988!0 = metadata !{metadata !"zero"} 989!1 = metadata !{metadata !"one"} 990!2 = metadata !{metadata !"two"} 991; A named metadata. 992!name = !{!0, !1, !2} 993</pre> 994 995</div> 996 997<!-- ======================================================================= --> 998<h3> 999 <a name="paramattrs">Parameter Attributes</a> 1000</h3> 1001 1002<div> 1003 1004<p>The return type and each parameter of a function type may have a set of 1005 <i>parameter attributes</i> associated with them. Parameter attributes are 1006 used to communicate additional information about the result or parameters of 1007 a function. Parameter attributes are considered to be part of the function, 1008 not of the function type, so functions with different parameter attributes 1009 can have the same function type.</p> 1010 1011<p>Parameter attributes are simple keywords that follow the type specified. If 1012 multiple parameter attributes are needed, they are space separated. For 1013 example:</p> 1014 1015<pre class="doc_code"> 1016declare i32 @printf(i8* noalias nocapture, ...) 1017declare i32 @atoi(i8 zeroext) 1018declare signext i8 @returns_signed_char() 1019</pre> 1020 1021<p>Note that any attributes for the function result (<tt>nounwind</tt>, 1022 <tt>readonly</tt>) come immediately after the argument list.</p> 1023 1024<p>Currently, only the following parameter attributes are defined:</p> 1025 1026<dl> 1027 <dt><tt><b>zeroext</b></tt></dt> 1028 <dd>This indicates to the code generator that the parameter or return value 1029 should be zero-extended to the extent required by the target's ABI (which 1030 is usually 32-bits, but is 8-bits for a i1 on x86-64) by the caller (for a 1031 parameter) or the callee (for a return value).</dd> 1032 1033 <dt><tt><b>signext</b></tt></dt> 1034 <dd>This indicates to the code generator that the parameter or return value 1035 should be sign-extended to the extent required by the target's ABI (which 1036 is usually 32-bits) by the caller (for a parameter) or the callee (for a 1037 return value).</dd> 1038 1039 <dt><tt><b>inreg</b></tt></dt> 1040 <dd>This indicates that this parameter or return value should be treated in a 1041 special target-dependent fashion during while emitting code for a function 1042 call or return (usually, by putting it in a register as opposed to memory, 1043 though some targets use it to distinguish between two different kinds of 1044 registers). Use of this attribute is target-specific.</dd> 1045 1046 <dt><tt><b><a name="byval">byval</a></b></tt></dt> 1047 <dd><p>This indicates that the pointer parameter should really be passed by 1048 value to the function. The attribute implies that a hidden copy of the 1049 pointee 1050 is made between the caller and the callee, so the callee is unable to 1051 modify the value in the callee. This attribute is only valid on LLVM 1052 pointer arguments. It is generally used to pass structs and arrays by 1053 value, but is also valid on pointers to scalars. The copy is considered 1054 to belong to the caller not the callee (for example, 1055 <tt><a href="#readonly">readonly</a></tt> functions should not write to 1056 <tt>byval</tt> parameters). This is not a valid attribute for return 1057 values.</p> 1058 1059 <p>The byval attribute also supports specifying an alignment with 1060 the align attribute. It indicates the alignment of the stack slot to 1061 form and the known alignment of the pointer specified to the call site. If 1062 the alignment is not specified, then the code generator makes a 1063 target-specific assumption.</p></dd> 1064 1065 <dt><tt><b><a name="sret">sret</a></b></tt></dt> 1066 <dd>This indicates that the pointer parameter specifies the address of a 1067 structure that is the return value of the function in the source program. 1068 This pointer must be guaranteed by the caller to be valid: loads and 1069 stores to the structure may be assumed by the callee to not to trap. This 1070 may only be applied to the first parameter. This is not a valid attribute 1071 for return values. </dd> 1072 1073 <dt><tt><b><a name="noalias">noalias</a></b></tt></dt> 1074 <dd>This indicates that pointer values 1075 <a href="#pointeraliasing"><i>based</i></a> on the argument or return 1076 value do not alias pointer values which are not <i>based</i> on it, 1077 ignoring certain "irrelevant" dependencies. 1078 For a call to the parent function, dependencies between memory 1079 references from before or after the call and from those during the call 1080 are "irrelevant" to the <tt>noalias</tt> keyword for the arguments and 1081 return value used in that call. 1082 The caller shares the responsibility with the callee for ensuring that 1083 these requirements are met. 1084 For further details, please see the discussion of the NoAlias response in 1085 <a href="AliasAnalysis.html#MustMayNo">alias analysis</a>.<br> 1086<br> 1087 Note that this definition of <tt>noalias</tt> is intentionally 1088 similar to the definition of <tt>restrict</tt> in C99 for function 1089 arguments, though it is slightly weaker. 1090<br> 1091 For function return values, C99's <tt>restrict</tt> is not meaningful, 1092 while LLVM's <tt>noalias</tt> is. 1093 </dd> 1094 1095 <dt><tt><b><a name="nocapture">nocapture</a></b></tt></dt> 1096 <dd>This indicates that the callee does not make any copies of the pointer 1097 that outlive the callee itself. This is not a valid attribute for return 1098 values.</dd> 1099 1100 <dt><tt><b><a name="nest">nest</a></b></tt></dt> 1101 <dd>This indicates that the pointer parameter can be excised using the 1102 <a href="#int_trampoline">trampoline intrinsics</a>. This is not a valid 1103 attribute for return values.</dd> 1104</dl> 1105 1106</div> 1107 1108<!-- ======================================================================= --> 1109<h3> 1110 <a name="gc">Garbage Collector Names</a> 1111</h3> 1112 1113<div> 1114 1115<p>Each function may specify a garbage collector name, which is simply a 1116 string:</p> 1117 1118<pre class="doc_code"> 1119define void @f() gc "name" { ... } 1120</pre> 1121 1122<p>The compiler declares the supported values of <i>name</i>. Specifying a 1123 collector which will cause the compiler to alter its output in order to 1124 support the named garbage collection algorithm.</p> 1125 1126</div> 1127 1128<!-- ======================================================================= --> 1129<h3> 1130 <a name="fnattrs">Function Attributes</a> 1131</h3> 1132 1133<div> 1134 1135<p>Function attributes are set to communicate additional information about a 1136 function. Function attributes are considered to be part of the function, not 1137 of the function type, so functions with different parameter attributes can 1138 have the same function type.</p> 1139 1140<p>Function attributes are simple keywords that follow the type specified. If 1141 multiple attributes are needed, they are space separated. For example:</p> 1142 1143<pre class="doc_code"> 1144define void @f() noinline { ... } 1145define void @f() alwaysinline { ... } 1146define void @f() alwaysinline optsize { ... } 1147define void @f() optsize { ... } 1148</pre> 1149 1150<dl> 1151 <dt><tt><b>address_safety</b></tt></dt> 1152 <dd>This attribute indicates that the address safety analysis 1153 is enabled for this function. </dd> 1154 1155 <dt><tt><b>alignstack(<<em>n</em>>)</b></tt></dt> 1156 <dd>This attribute indicates that, when emitting the prologue and epilogue, 1157 the backend should forcibly align the stack pointer. Specify the 1158 desired alignment, which must be a power of two, in parentheses. 1159 1160 <dt><tt><b>alwaysinline</b></tt></dt> 1161 <dd>This attribute indicates that the inliner should attempt to inline this 1162 function into callers whenever possible, ignoring any active inlining size 1163 threshold for this caller.</dd> 1164 1165 <dt><tt><b>nonlazybind</b></tt></dt> 1166 <dd>This attribute suppresses lazy symbol binding for the function. This 1167 may make calls to the function faster, at the cost of extra program 1168 startup time if the function is not called during program startup.</dd> 1169 1170 <dt><tt><b>inlinehint</b></tt></dt> 1171 <dd>This attribute indicates that the source code contained a hint that inlining 1172 this function is desirable (such as the "inline" keyword in C/C++). It 1173 is just a hint; it imposes no requirements on the inliner.</dd> 1174 1175 <dt><tt><b>naked</b></tt></dt> 1176 <dd>This attribute disables prologue / epilogue emission for the function. 1177 This can have very system-specific consequences.</dd> 1178 1179 <dt><tt><b>noimplicitfloat</b></tt></dt> 1180 <dd>This attributes disables implicit floating point instructions.</dd> 1181 1182 <dt><tt><b>noinline</b></tt></dt> 1183 <dd>This attribute indicates that the inliner should never inline this 1184 function in any situation. This attribute may not be used together with 1185 the <tt>alwaysinline</tt> attribute.</dd> 1186 1187 <dt><tt><b>noredzone</b></tt></dt> 1188 <dd>This attribute indicates that the code generator should not use a red 1189 zone, even if the target-specific ABI normally permits it.</dd> 1190 1191 <dt><tt><b>noreturn</b></tt></dt> 1192 <dd>This function attribute indicates that the function never returns 1193 normally. This produces undefined behavior at runtime if the function 1194 ever does dynamically return.</dd> 1195 1196 <dt><tt><b>nounwind</b></tt></dt> 1197 <dd>This function attribute indicates that the function never returns with an 1198 unwind or exceptional control flow. If the function does unwind, its 1199 runtime behavior is undefined.</dd> 1200 1201 <dt><tt><b>optsize</b></tt></dt> 1202 <dd>This attribute suggests that optimization passes and code generator passes 1203 make choices that keep the code size of this function low, and otherwise 1204 do optimizations specifically to reduce code size.</dd> 1205 1206 <dt><tt><b>readnone</b></tt></dt> 1207 <dd>This attribute indicates that the function computes its result (or decides 1208 to unwind an exception) based strictly on its arguments, without 1209 dereferencing any pointer arguments or otherwise accessing any mutable 1210 state (e.g. memory, control registers, etc) visible to caller functions. 1211 It does not write through any pointer arguments 1212 (including <tt><a href="#byval">byval</a></tt> arguments) and never 1213 changes any state visible to callers. This means that it cannot unwind 1214 exceptions by calling the <tt>C++</tt> exception throwing methods.</dd> 1215 1216 <dt><tt><b><a name="readonly">readonly</a></b></tt></dt> 1217 <dd>This attribute indicates that the function does not write through any 1218 pointer arguments (including <tt><a href="#byval">byval</a></tt> 1219 arguments) or otherwise modify any state (e.g. memory, control registers, 1220 etc) visible to caller functions. It may dereference pointer arguments 1221 and read state that may be set in the caller. A readonly function always 1222 returns the same value (or unwinds an exception identically) when called 1223 with the same set of arguments and global state. It cannot unwind an 1224 exception by calling the <tt>C++</tt> exception throwing methods.</dd> 1225 1226 <dt><tt><b><a name="returns_twice">returns_twice</a></b></tt></dt> 1227 <dd>This attribute indicates that this function can return twice. The 1228 C <code>setjmp</code> is an example of such a function. The compiler 1229 disables some optimizations (like tail calls) in the caller of these 1230 functions.</dd> 1231 1232 <dt><tt><b><a name="ssp">ssp</a></b></tt></dt> 1233 <dd>This attribute indicates that the function should emit a stack smashing 1234 protector. It is in the form of a "canary"—a random value placed on 1235 the stack before the local variables that's checked upon return from the 1236 function to see if it has been overwritten. A heuristic is used to 1237 determine if a function needs stack protectors or not.<br> 1238<br> 1239 If a function that has an <tt>ssp</tt> attribute is inlined into a 1240 function that doesn't have an <tt>ssp</tt> attribute, then the resulting 1241 function will have an <tt>ssp</tt> attribute.</dd> 1242 1243 <dt><tt><b>sspreq</b></tt></dt> 1244 <dd>This attribute indicates that the function should <em>always</em> emit a 1245 stack smashing protector. This overrides 1246 the <tt><a href="#ssp">ssp</a></tt> function attribute.<br> 1247<br> 1248 If a function that has an <tt>sspreq</tt> attribute is inlined into a 1249 function that doesn't have an <tt>sspreq</tt> attribute or which has 1250 an <tt>ssp</tt> attribute, then the resulting function will have 1251 an <tt>sspreq</tt> attribute.</dd> 1252 1253 <dt><tt><b><a name="uwtable">uwtable</a></b></tt></dt> 1254 <dd>This attribute indicates that the ABI being targeted requires that 1255 an unwind table entry be produce for this function even if we can 1256 show that no exceptions passes by it. This is normally the case for 1257 the ELF x86-64 abi, but it can be disabled for some compilation 1258 units.</dd> 1259</dl> 1260 1261</div> 1262 1263<!-- ======================================================================= --> 1264<h3> 1265 <a name="moduleasm">Module-Level Inline Assembly</a> 1266</h3> 1267 1268<div> 1269 1270<p>Modules may contain "module-level inline asm" blocks, which corresponds to 1271 the GCC "file scope inline asm" blocks. These blocks are internally 1272 concatenated by LLVM and treated as a single unit, but may be separated in 1273 the <tt>.ll</tt> file if desired. The syntax is very simple:</p> 1274 1275<pre class="doc_code"> 1276module asm "inline asm code goes here" 1277module asm "more can go here" 1278</pre> 1279 1280<p>The strings can contain any character by escaping non-printable characters. 1281 The escape sequence used is simply "\xx" where "xx" is the two digit hex code 1282 for the number.</p> 1283 1284<p>The inline asm code is simply printed to the machine code .s file when 1285 assembly code is generated.</p> 1286 1287</div> 1288 1289<!-- ======================================================================= --> 1290<h3> 1291 <a name="datalayout">Data Layout</a> 1292</h3> 1293 1294<div> 1295 1296<p>A module may specify a target specific data layout string that specifies how 1297 data is to be laid out in memory. The syntax for the data layout is 1298 simply:</p> 1299 1300<pre class="doc_code"> 1301target datalayout = "<i>layout specification</i>" 1302</pre> 1303 1304<p>The <i>layout specification</i> consists of a list of specifications 1305 separated by the minus sign character ('-'). Each specification starts with 1306 a letter and may include other information after the letter to define some 1307 aspect of the data layout. The specifications accepted are as follows:</p> 1308 1309<dl> 1310 <dt><tt>E</tt></dt> 1311 <dd>Specifies that the target lays out data in big-endian form. That is, the 1312 bits with the most significance have the lowest address location.</dd> 1313 1314 <dt><tt>e</tt></dt> 1315 <dd>Specifies that the target lays out data in little-endian form. That is, 1316 the bits with the least significance have the lowest address 1317 location.</dd> 1318 1319 <dt><tt>S<i>size</i></tt></dt> 1320 <dd>Specifies the natural alignment of the stack in bits. Alignment promotion 1321 of stack variables is limited to the natural stack alignment to avoid 1322 dynamic stack realignment. The stack alignment must be a multiple of 1323 8-bits. If omitted, the natural stack alignment defaults to "unspecified", 1324 which does not prevent any alignment promotions.</dd> 1325 1326 <dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> 1327 <dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and 1328 <i>preferred</i> alignments. All sizes are in bits. Specifying 1329 the <i>pref</i> alignment is optional. If omitted, the 1330 preceding <tt>:</tt> should be omitted too.</dd> 1331 1332 <dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> 1333 <dd>This specifies the alignment for an integer type of a given bit 1334 <i>size</i>. The value of <i>size</i> must be in the range [1,2^23).</dd> 1335 1336 <dt><tt>v<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> 1337 <dd>This specifies the alignment for a vector type of a given bit 1338 <i>size</i>.</dd> 1339 1340 <dt><tt>f<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> 1341 <dd>This specifies the alignment for a floating point type of a given bit 1342 <i>size</i>. Only values of <i>size</i> that are supported by the target 1343 will work. 32 (float) and 64 (double) are supported on all targets; 1344 80 or 128 (different flavors of long double) are also supported on some 1345 targets. 1346 1347 <dt><tt>a<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> 1348 <dd>This specifies the alignment for an aggregate type of a given bit 1349 <i>size</i>.</dd> 1350 1351 <dt><tt>s<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt> 1352 <dd>This specifies the alignment for a stack object of a given bit 1353 <i>size</i>.</dd> 1354 1355 <dt><tt>n<i>size1</i>:<i>size2</i>:<i>size3</i>...</tt></dt> 1356 <dd>This specifies a set of native integer widths for the target CPU 1357 in bits. For example, it might contain "n32" for 32-bit PowerPC, 1358 "n32:64" for PowerPC 64, or "n8:16:32:64" for X86-64. Elements of 1359 this set are considered to support most general arithmetic 1360 operations efficiently.</dd> 1361</dl> 1362 1363<p>When constructing the data layout for a given target, LLVM starts with a 1364 default set of specifications which are then (possibly) overridden by the 1365 specifications in the <tt>datalayout</tt> keyword. The default specifications 1366 are given in this list:</p> 1367 1368<ul> 1369 <li><tt>E</tt> - big endian</li> 1370 <li><tt>p:64:64:64</tt> - 64-bit pointers with 64-bit alignment</li> 1371 <li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li> 1372 <li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li> 1373 <li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li> 1374 <li><tt>i32:32:32</tt> - i32 is 32-bit aligned</li> 1375 <li><tt>i64:32:64</tt> - i64 has ABI alignment of 32-bits but preferred 1376 alignment of 64-bits</li> 1377 <li><tt>f32:32:32</tt> - float is 32-bit aligned</li> 1378 <li><tt>f64:64:64</tt> - double is 64-bit aligned</li> 1379 <li><tt>v64:64:64</tt> - 64-bit vector is 64-bit aligned</li> 1380 <li><tt>v128:128:128</tt> - 128-bit vector is 128-bit aligned</li> 1381 <li><tt>a0:0:1</tt> - aggregates are 8-bit aligned</li> 1382 <li><tt>s0:64:64</tt> - stack objects are 64-bit aligned</li> 1383</ul> 1384 1385<p>When LLVM is determining the alignment for a given type, it uses the 1386 following rules:</p> 1387 1388<ol> 1389 <li>If the type sought is an exact match for one of the specifications, that 1390 specification is used.</li> 1391 1392 <li>If no match is found, and the type sought is an integer type, then the 1393 smallest integer type that is larger than the bitwidth of the sought type 1394 is used. If none of the specifications are larger than the bitwidth then 1395 the the largest integer type is used. For example, given the default 1396 specifications above, the i7 type will use the alignment of i8 (next 1397 largest) while both i65 and i256 will use the alignment of i64 (largest 1398 specified).</li> 1399 1400 <li>If no match is found, and the type sought is a vector type, then the 1401 largest vector type that is smaller than the sought vector type will be 1402 used as a fall back. This happens because <128 x double> can be 1403 implemented in terms of 64 <2 x double>, for example.</li> 1404</ol> 1405 1406<p>The function of the data layout string may not be what you expect. Notably, 1407 this is not a specification from the frontend of what alignment the code 1408 generator should use.</p> 1409 1410<p>Instead, if specified, the target data layout is required to match what the 1411 ultimate <em>code generator</em> expects. This string is used by the 1412 mid-level optimizers to 1413 improve code, and this only works if it matches what the ultimate code 1414 generator uses. If you would like to generate IR that does not embed this 1415 target-specific detail into the IR, then you don't have to specify the 1416 string. This will disable some optimizations that require precise layout 1417 information, but this also prevents those optimizations from introducing 1418 target specificity into the IR.</p> 1419 1420 1421 1422</div> 1423 1424<!-- ======================================================================= --> 1425<h3> 1426 <a name="pointeraliasing">Pointer Aliasing Rules</a> 1427</h3> 1428 1429<div> 1430 1431<p>Any memory access must be done through a pointer value associated 1432with an address range of the memory access, otherwise the behavior 1433is undefined. Pointer values are associated with address ranges 1434according to the following rules:</p> 1435 1436<ul> 1437 <li>A pointer value is associated with the addresses associated with 1438 any value it is <i>based</i> on. 1439 <li>An address of a global variable is associated with the address 1440 range of the variable's storage.</li> 1441 <li>The result value of an allocation instruction is associated with 1442 the address range of the allocated storage.</li> 1443 <li>A null pointer in the default address-space is associated with 1444 no address.</li> 1445 <li>An integer constant other than zero or a pointer value returned 1446 from a function not defined within LLVM may be associated with address 1447 ranges allocated through mechanisms other than those provided by 1448 LLVM. Such ranges shall not overlap with any ranges of addresses 1449 allocated by mechanisms provided by LLVM.</li> 1450</ul> 1451 1452<p>A pointer value is <i>based</i> on another pointer value according 1453 to the following rules:</p> 1454 1455<ul> 1456 <li>A pointer value formed from a 1457 <tt><a href="#i_getelementptr">getelementptr</a></tt> operation 1458 is <i>based</i> on the first operand of the <tt>getelementptr</tt>.</li> 1459 <li>The result value of a 1460 <tt><a href="#i_bitcast">bitcast</a></tt> is <i>based</i> on the operand 1461 of the <tt>bitcast</tt>.</li> 1462 <li>A pointer value formed by an 1463 <tt><a href="#i_inttoptr">inttoptr</a></tt> is <i>based</i> on all 1464 pointer values that contribute (directly or indirectly) to the 1465 computation of the pointer's value.</li> 1466 <li>The "<i>based</i> on" relationship is transitive.</li> 1467</ul> 1468 1469<p>Note that this definition of <i>"based"</i> is intentionally 1470 similar to the definition of <i>"based"</i> in C99, though it is 1471 slightly weaker.</p> 1472 1473<p>LLVM IR does not associate types with memory. The result type of a 1474<tt><a href="#i_load">load</a></tt> merely indicates the size and 1475alignment of the memory from which to load, as well as the 1476interpretation of the value. The first operand type of a 1477<tt><a href="#i_store">store</a></tt> similarly only indicates the size 1478and alignment of the store.</p> 1479 1480<p>Consequently, type-based alias analysis, aka TBAA, aka 1481<tt>-fstrict-aliasing</tt>, is not applicable to general unadorned 1482LLVM IR. <a href="#metadata">Metadata</a> may be used to encode 1483additional information which specialized optimization passes may use 1484to implement type-based alias analysis.</p> 1485 1486</div> 1487 1488<!-- ======================================================================= --> 1489<h3> 1490 <a name="volatile">Volatile Memory Accesses</a> 1491</h3> 1492 1493<div> 1494 1495<p>Certain memory accesses, such as <a href="#i_load"><tt>load</tt></a>s, <a 1496href="#i_store"><tt>store</tt></a>s, and <a 1497href="#int_memcpy"><tt>llvm.memcpy</tt></a>s may be marked <tt>volatile</tt>. 1498The optimizers must not change the number of volatile operations or change their 1499order of execution relative to other volatile operations. The optimizers 1500<i>may</i> change the order of volatile operations relative to non-volatile 1501operations. This is not Java's "volatile" and has no cross-thread 1502synchronization behavior.</p> 1503 1504</div> 1505 1506<!-- ======================================================================= --> 1507<h3> 1508 <a name="memmodel">Memory Model for Concurrent Operations</a> 1509</h3> 1510 1511<div> 1512 1513<p>The LLVM IR does not define any way to start parallel threads of execution 1514or to register signal handlers. Nonetheless, there are platform-specific 1515ways to create them, and we define LLVM IR's behavior in their presence. This 1516model is inspired by the C++0x memory model.</p> 1517 1518<p>For a more informal introduction to this model, see the 1519<a href="Atomics.html">LLVM Atomic Instructions and Concurrency Guide</a>. 1520 1521<p>We define a <i>happens-before</i> partial order as the least partial order 1522that</p> 1523<ul> 1524 <li>Is a superset of single-thread program order, and</li> 1525 <li>When a <i>synchronizes-with</i> <tt>b</tt>, includes an edge from 1526 <tt>a</tt> to <tt>b</tt>. <i>Synchronizes-with</i> pairs are introduced 1527 by platform-specific techniques, like pthread locks, thread 1528 creation, thread joining, etc., and by atomic instructions. 1529 (See also <a href="#ordering">Atomic Memory Ordering Constraints</a>). 1530 </li> 1531</ul> 1532 1533<p>Note that program order does not introduce <i>happens-before</i> edges 1534between a thread and signals executing inside that thread.</p> 1535 1536<p>Every (defined) read operation (load instructions, memcpy, atomic 1537loads/read-modify-writes, etc.) <var>R</var> reads a series of bytes written by 1538(defined) write operations (store instructions, atomic 1539stores/read-modify-writes, memcpy, etc.). For the purposes of this section, 1540initialized globals are considered to have a write of the initializer which is 1541atomic and happens before any other read or write of the memory in question. 1542For each byte of a read <var>R</var>, <var>R<sub>byte</sub></var> may see 1543any write to the same byte, except:</p> 1544 1545<ul> 1546 <li>If <var>write<sub>1</sub></var> happens before 1547 <var>write<sub>2</sub></var>, and <var>write<sub>2</sub></var> happens 1548 before <var>R<sub>byte</sub></var>, then <var>R<sub>byte</sub></var> 1549 does not see <var>write<sub>1</sub></var>. 1550 <li>If <var>R<sub>byte</sub></var> happens before 1551 <var>write<sub>3</sub></var>, then <var>R<sub>byte</sub></var> does not 1552 see <var>write<sub>3</sub></var>. 1553</ul> 1554 1555<p>Given that definition, <var>R<sub>byte</sub></var> is defined as follows: 1556<ul> 1557 <li>If <var>R</var> is volatile, the result is target-dependent. (Volatile 1558 is supposed to give guarantees which can support 1559 <code>sig_atomic_t</code> in C/C++, and may be used for accesses to 1560 addresses which do not behave like normal memory. It does not generally 1561 provide cross-thread synchronization.) 1562 <li>Otherwise, if there is no write to the same byte that happens before 1563 <var>R<sub>byte</sub></var>, <var>R<sub>byte</sub></var> returns 1564 <tt>undef</tt> for that byte. 1565 <li>Otherwise, if <var>R<sub>byte</sub></var> may see exactly one write, 1566 <var>R<sub>byte</sub></var> returns the value written by that 1567 write.</li> 1568 <li>Otherwise, if <var>R</var> is atomic, and all the writes 1569 <var>R<sub>byte</sub></var> may see are atomic, it chooses one of the 1570 values written. See the <a href="#ordering">Atomic Memory Ordering 1571 Constraints</a> section for additional constraints on how the choice 1572 is made. 1573 <li>Otherwise <var>R<sub>byte</sub></var> returns <tt>undef</tt>.</li> 1574</ul> 1575 1576<p><var>R</var> returns the value composed of the series of bytes it read. 1577This implies that some bytes within the value may be <tt>undef</tt> 1578<b>without</b> the entire value being <tt>undef</tt>. Note that this only 1579defines the semantics of the operation; it doesn't mean that targets will 1580emit more than one instruction to read the series of bytes.</p> 1581 1582<p>Note that in cases where none of the atomic intrinsics are used, this model 1583places only one restriction on IR transformations on top of what is required 1584for single-threaded execution: introducing a store to a byte which might not 1585otherwise be stored is not allowed in general. (Specifically, in the case 1586where another thread might write to and read from an address, introducing a 1587store can change a load that may see exactly one write into a load that may 1588see multiple writes.)</p> 1589 1590<!-- FIXME: This model assumes all targets where concurrency is relevant have 1591a byte-size store which doesn't affect adjacent bytes. As far as I can tell, 1592none of the backends currently in the tree fall into this category; however, 1593there might be targets which care. If there are, we want a paragraph 1594like the following: 1595 1596Targets may specify that stores narrower than a certain width are not 1597available; on such a target, for the purposes of this model, treat any 1598non-atomic write with an alignment or width less than the minimum width 1599as if it writes to the relevant surrounding bytes. 1600--> 1601 1602</div> 1603 1604<!-- ======================================================================= --> 1605<h3> 1606 <a name="ordering">Atomic Memory Ordering Constraints</a> 1607</h3> 1608 1609<div> 1610 1611<p>Atomic instructions (<a href="#i_cmpxchg"><code>cmpxchg</code></a>, 1612<a href="#i_atomicrmw"><code>atomicrmw</code></a>, 1613<a href="#i_fence"><code>fence</code></a>, 1614<a href="#i_load"><code>atomic load</code></a>, and 1615<a href="#i_store"><code>atomic store</code></a>) take an ordering parameter 1616that determines which other atomic instructions on the same address they 1617<i>synchronize with</i>. These semantics are borrowed from Java and C++0x, 1618but are somewhat more colloquial. If these descriptions aren't precise enough, 1619check those specs (see spec references in the 1620<a href="Atomics.html#introduction">atomics guide</a>). 1621<a href="#i_fence"><code>fence</code></a> instructions 1622treat these orderings somewhat differently since they don't take an address. 1623See that instruction's documentation for details.</p> 1624 1625<p>For a simpler introduction to the ordering constraints, see the 1626<a href="Atomics.html">LLVM Atomic Instructions and Concurrency Guide</a>.</p> 1627 1628<dl> 1629<dt><code>unordered</code></dt> 1630<dd>The set of values that can be read is governed by the happens-before 1631partial order. A value cannot be read unless some operation wrote it. 1632This is intended to provide a guarantee strong enough to model Java's 1633non-volatile shared variables. This ordering cannot be specified for 1634read-modify-write operations; it is not strong enough to make them atomic 1635in any interesting way.</dd> 1636<dt><code>monotonic</code></dt> 1637<dd>In addition to the guarantees of <code>unordered</code>, there is a single 1638total order for modifications by <code>monotonic</code> operations on each 1639address. All modification orders must be compatible with the happens-before 1640order. There is no guarantee that the modification orders can be combined to 1641a global total order for the whole program (and this often will not be 1642possible). The read in an atomic read-modify-write operation 1643(<a href="#i_cmpxchg"><code>cmpxchg</code></a> and 1644<a href="#i_atomicrmw"><code>atomicrmw</code></a>) 1645reads the value in the modification order immediately before the value it 1646writes. If one atomic read happens before another atomic read of the same 1647address, the later read must see the same value or a later value in the 1648address's modification order. This disallows reordering of 1649<code>monotonic</code> (or stronger) operations on the same address. If an 1650address is written <code>monotonic</code>ally by one thread, and other threads 1651<code>monotonic</code>ally read that address repeatedly, the other threads must 1652eventually see the write. This corresponds to the C++0x/C1x 1653<code>memory_order_relaxed</code>.</dd> 1654<dt><code>acquire</code></dt> 1655<dd>In addition to the guarantees of <code>monotonic</code>, 1656a <i>synchronizes-with</i> edge may be formed with a <code>release</code> 1657operation. This is intended to model C++'s <code>memory_order_acquire</code>.</dd> 1658<dt><code>release</code></dt> 1659<dd>In addition to the guarantees of <code>monotonic</code>, if this operation 1660writes a value which is subsequently read by an <code>acquire</code> operation, 1661it <i>synchronizes-with</i> that operation. (This isn't a complete 1662description; see the C++0x definition of a release sequence.) This corresponds 1663to the C++0x/C1x <code>memory_order_release</code>.</dd> 1664<dt><code>acq_rel</code> (acquire+release)</dt><dd>Acts as both an 1665<code>acquire</code> and <code>release</code> operation on its address. 1666This corresponds to the C++0x/C1x <code>memory_order_acq_rel</code>.</dd> 1667<dt><code>seq_cst</code> (sequentially consistent)</dt><dd> 1668<dd>In addition to the guarantees of <code>acq_rel</code> 1669(<code>acquire</code> for an operation which only reads, <code>release</code> 1670for an operation which only writes), there is a global total order on all 1671sequentially-consistent operations on all addresses, which is consistent with 1672the <i>happens-before</i> partial order and with the modification orders of 1673all the affected addresses. Each sequentially-consistent read sees the last 1674preceding write to the same address in this global order. This corresponds 1675to the C++0x/C1x <code>memory_order_seq_cst</code> and Java volatile.</dd> 1676</dl> 1677 1678<p id="singlethread">If an atomic operation is marked <code>singlethread</code>, 1679it only <i>synchronizes with</i> or participates in modification and seq_cst 1680total orderings with other operations running in the same thread (for example, 1681in signal handlers).</p> 1682 1683</div> 1684 1685</div> 1686 1687<!-- *********************************************************************** --> 1688<h2><a name="typesystem">Type System</a></h2> 1689<!-- *********************************************************************** --> 1690 1691<div> 1692 1693<p>The LLVM type system is one of the most important features of the 1694 intermediate representation. Being typed enables a number of optimizations 1695 to be performed on the intermediate representation directly, without having 1696 to do extra analyses on the side before the transformation. A strong type 1697 system makes it easier to read the generated code and enables novel analyses 1698 and transformations that are not feasible to perform on normal three address 1699 code representations.</p> 1700 1701<!-- ======================================================================= --> 1702<h3> 1703 <a name="t_classifications">Type Classifications</a> 1704</h3> 1705 1706<div> 1707 1708<p>The types fall into a few useful classifications:</p> 1709 1710<table border="1" cellspacing="0" cellpadding="4"> 1711 <tbody> 1712 <tr><th>Classification</th><th>Types</th></tr> 1713 <tr> 1714 <td><a href="#t_integer">integer</a></td> 1715 <td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td> 1716 </tr> 1717 <tr> 1718 <td><a href="#t_floating">floating point</a></td> 1719 <td><tt>half, float, double, x86_fp80, fp128, ppc_fp128</tt></td> 1720 </tr> 1721 <tr> 1722 <td><a name="t_firstclass">first class</a></td> 1723 <td><a href="#t_integer">integer</a>, 1724 <a href="#t_floating">floating point</a>, 1725 <a href="#t_pointer">pointer</a>, 1726 <a href="#t_vector">vector</a>, 1727 <a href="#t_struct">structure</a>, 1728 <a href="#t_array">array</a>, 1729 <a href="#t_label">label</a>, 1730 <a href="#t_metadata">metadata</a>. 1731 </td> 1732 </tr> 1733 <tr> 1734 <td><a href="#t_primitive">primitive</a></td> 1735 <td><a href="#t_label">label</a>, 1736 <a href="#t_void">void</a>, 1737 <a href="#t_integer">integer</a>, 1738 <a href="#t_floating">floating point</a>, 1739 <a href="#t_x86mmx">x86mmx</a>, 1740 <a href="#t_metadata">metadata</a>.</td> 1741 </tr> 1742 <tr> 1743 <td><a href="#t_derived">derived</a></td> 1744 <td><a href="#t_array">array</a>, 1745 <a href="#t_function">function</a>, 1746 <a href="#t_pointer">pointer</a>, 1747 <a href="#t_struct">structure</a>, 1748 <a href="#t_vector">vector</a>, 1749 <a href="#t_opaque">opaque</a>. 1750 </td> 1751 </tr> 1752 </tbody> 1753</table> 1754 1755<p>The <a href="#t_firstclass">first class</a> types are perhaps the most 1756 important. Values of these types are the only ones which can be produced by 1757 instructions.</p> 1758 1759</div> 1760 1761<!-- ======================================================================= --> 1762<h3> 1763 <a name="t_primitive">Primitive Types</a> 1764</h3> 1765 1766<div> 1767 1768<p>The primitive types are the fundamental building blocks of the LLVM 1769 system.</p> 1770 1771<!-- _______________________________________________________________________ --> 1772<h4> 1773 <a name="t_integer">Integer Type</a> 1774</h4> 1775 1776<div> 1777 1778<h5>Overview:</h5> 1779<p>The integer type is a very simple type that simply specifies an arbitrary 1780 bit width for the integer type desired. Any bit width from 1 bit to 1781 2<sup>23</sup>-1 (about 8 million) can be specified.</p> 1782 1783<h5>Syntax:</h5> 1784<pre> 1785 iN 1786</pre> 1787 1788<p>The number of bits the integer will occupy is specified by the <tt>N</tt> 1789 value.</p> 1790 1791<h5>Examples:</h5> 1792<table class="layout"> 1793 <tr class="layout"> 1794 <td class="left"><tt>i1</tt></td> 1795 <td class="left">a single-bit integer.</td> 1796 </tr> 1797 <tr class="layout"> 1798 <td class="left"><tt>i32</tt></td> 1799 <td class="left">a 32-bit integer.</td> 1800 </tr> 1801 <tr class="layout"> 1802 <td class="left"><tt>i1942652</tt></td> 1803 <td class="left">a really big integer of over 1 million bits.</td> 1804 </tr> 1805</table> 1806 1807</div> 1808 1809<!-- _______________________________________________________________________ --> 1810<h4> 1811 <a name="t_floating">Floating Point Types</a> 1812</h4> 1813 1814<div> 1815 1816<table> 1817 <tbody> 1818 <tr><th>Type</th><th>Description</th></tr> 1819 <tr><td><tt>half</tt></td><td>16-bit floating point value</td></tr> 1820 <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr> 1821 <tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr> 1822 <tr><td><tt>fp128</tt></td><td>128-bit floating point value (112-bit mantissa)</td></tr> 1823 <tr><td><tt>x86_fp80</tt></td><td>80-bit floating point value (X87)</td></tr> 1824 <tr><td><tt>ppc_fp128</tt></td><td>128-bit floating point value (two 64-bits)</td></tr> 1825 </tbody> 1826</table> 1827 1828</div> 1829 1830<!-- _______________________________________________________________________ --> 1831<h4> 1832 <a name="t_x86mmx">X86mmx Type</a> 1833</h4> 1834 1835<div> 1836 1837<h5>Overview:</h5> 1838<p>The x86mmx type represents a value held in an MMX register on an x86 machine. The operations allowed on it are quite limited: parameters and return values, load and store, and bitcast. User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type. There are no arrays, vectors or constants of this type.</p> 1839 1840<h5>Syntax:</h5> 1841<pre> 1842 x86mmx 1843</pre> 1844 1845</div> 1846 1847<!-- _______________________________________________________________________ --> 1848<h4> 1849 <a name="t_void">Void Type</a> 1850</h4> 1851 1852<div> 1853 1854<h5>Overview:</h5> 1855<p>The void type does not represent any value and has no size.</p> 1856 1857<h5>Syntax:</h5> 1858<pre> 1859 void 1860</pre> 1861 1862</div> 1863 1864<!-- _______________________________________________________________________ --> 1865<h4> 1866 <a name="t_label">Label Type</a> 1867</h4> 1868 1869<div> 1870 1871<h5>Overview:</h5> 1872<p>The label type represents code labels.</p> 1873 1874<h5>Syntax:</h5> 1875<pre> 1876 label 1877</pre> 1878 1879</div> 1880 1881<!-- _______________________________________________________________________ --> 1882<h4> 1883 <a name="t_metadata">Metadata Type</a> 1884</h4> 1885 1886<div> 1887 1888<h5>Overview:</h5> 1889<p>The metadata type represents embedded metadata. No derived types may be 1890 created from metadata except for <a href="#t_function">function</a> 1891 arguments. 1892 1893<h5>Syntax:</h5> 1894<pre> 1895 metadata 1896</pre> 1897 1898</div> 1899 1900</div> 1901 1902<!-- ======================================================================= --> 1903<h3> 1904 <a name="t_derived">Derived Types</a> 1905</h3> 1906 1907<div> 1908 1909<p>The real power in LLVM comes from the derived types in the system. This is 1910 what allows a programmer to represent arrays, functions, pointers, and other 1911 useful types. Each of these types contain one or more element types which 1912 may be a primitive type, or another derived type. For example, it is 1913 possible to have a two dimensional array, using an array as the element type 1914 of another array.</p> 1915 1916<!-- _______________________________________________________________________ --> 1917<h4> 1918 <a name="t_aggregate">Aggregate Types</a> 1919</h4> 1920 1921<div> 1922 1923<p>Aggregate Types are a subset of derived types that can contain multiple 1924 member types. <a href="#t_array">Arrays</a> and 1925 <a href="#t_struct">structs</a> are aggregate types. 1926 <a href="#t_vector">Vectors</a> are not considered to be aggregate types.</p> 1927 1928</div> 1929 1930<!-- _______________________________________________________________________ --> 1931<h4> 1932 <a name="t_array">Array Type</a> 1933</h4> 1934 1935<div> 1936 1937<h5>Overview:</h5> 1938<p>The array type is a very simple derived type that arranges elements 1939 sequentially in memory. The array type requires a size (number of elements) 1940 and an underlying data type.</p> 1941 1942<h5>Syntax:</h5> 1943<pre> 1944 [<# elements> x <elementtype>] 1945</pre> 1946 1947<p>The number of elements is a constant integer value; <tt>elementtype</tt> may 1948 be any type with a size.</p> 1949 1950<h5>Examples:</h5> 1951<table class="layout"> 1952 <tr class="layout"> 1953 <td class="left"><tt>[40 x i32]</tt></td> 1954 <td class="left">Array of 40 32-bit integer values.</td> 1955 </tr> 1956 <tr class="layout"> 1957 <td class="left"><tt>[41 x i32]</tt></td> 1958 <td class="left">Array of 41 32-bit integer values.</td> 1959 </tr> 1960 <tr class="layout"> 1961 <td class="left"><tt>[4 x i8]</tt></td> 1962 <td class="left">Array of 4 8-bit integer values.</td> 1963 </tr> 1964</table> 1965<p>Here are some examples of multidimensional arrays:</p> 1966<table class="layout"> 1967 <tr class="layout"> 1968 <td class="left"><tt>[3 x [4 x i32]]</tt></td> 1969 <td class="left">3x4 array of 32-bit integer values.</td> 1970 </tr> 1971 <tr class="layout"> 1972 <td class="left"><tt>[12 x [10 x float]]</tt></td> 1973 <td class="left">12x10 array of single precision floating point values.</td> 1974 </tr> 1975 <tr class="layout"> 1976 <td class="left"><tt>[2 x [3 x [4 x i16]]]</tt></td> 1977 <td class="left">2x3x4 array of 16-bit integer values.</td> 1978 </tr> 1979</table> 1980 1981<p>There is no restriction on indexing beyond the end of the array implied by 1982 a static type (though there are restrictions on indexing beyond the bounds 1983 of an allocated object in some cases). This means that single-dimension 1984 'variable sized array' addressing can be implemented in LLVM with a zero 1985 length array type. An implementation of 'pascal style arrays' in LLVM could 1986 use the type "<tt>{ i32, [0 x float]}</tt>", for example.</p> 1987 1988</div> 1989 1990<!-- _______________________________________________________________________ --> 1991<h4> 1992 <a name="t_function">Function Type</a> 1993</h4> 1994 1995<div> 1996 1997<h5>Overview:</h5> 1998<p>The function type can be thought of as a function signature. It consists of 1999 a return type and a list of formal parameter types. The return type of a 2000 function type is a first class type or a void type.</p> 2001 2002<h5>Syntax:</h5> 2003<pre> 2004 <returntype> (<parameter list>) 2005</pre> 2006 2007<p>...where '<tt><parameter list></tt>' is a comma-separated list of type 2008 specifiers. Optionally, the parameter list may include a type <tt>...</tt>, 2009 which indicates that the function takes a variable number of arguments. 2010 Variable argument functions can access their arguments with 2011 the <a href="#int_varargs">variable argument handling intrinsic</a> 2012 functions. '<tt><returntype></tt>' is any type except 2013 <a href="#t_label">label</a>.</p> 2014 2015<h5>Examples:</h5> 2016<table class="layout"> 2017 <tr class="layout"> 2018 <td class="left"><tt>i32 (i32)</tt></td> 2019 <td class="left">function taking an <tt>i32</tt>, returning an <tt>i32</tt> 2020 </td> 2021 </tr><tr class="layout"> 2022 <td class="left"><tt>float (i16, i32 *) * 2023 </tt></td> 2024 <td class="left"><a href="#t_pointer">Pointer</a> to a function that takes 2025 an <tt>i16</tt> and a <a href="#t_pointer">pointer</a> to <tt>i32</tt>, 2026 returning <tt>float</tt>. 2027 </td> 2028 </tr><tr class="layout"> 2029 <td class="left"><tt>i32 (i8*, ...)</tt></td> 2030 <td class="left">A vararg function that takes at least one 2031 <a href="#t_pointer">pointer</a> to <tt>i8 </tt> (char in C), 2032 which returns an integer. This is the signature for <tt>printf</tt> in 2033 LLVM. 2034 </td> 2035 </tr><tr class="layout"> 2036 <td class="left"><tt>{i32, i32} (i32)</tt></td> 2037 <td class="left">A function taking an <tt>i32</tt>, returning a 2038 <a href="#t_struct">structure</a> containing two <tt>i32</tt> values 2039 </td> 2040 </tr> 2041</table> 2042 2043</div> 2044 2045<!-- _______________________________________________________________________ --> 2046<h4> 2047 <a name="t_struct">Structure Type</a> 2048</h4> 2049 2050<div> 2051 2052<h5>Overview:</h5> 2053<p>The structure type is used to represent a collection of data members together 2054 in memory. The elements of a structure may be any type that has a size.</p> 2055 2056<p>Structures in memory are accessed using '<tt><a href="#i_load">load</a></tt>' 2057 and '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a field 2058 with the '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction. 2059 Structures in registers are accessed using the 2060 '<tt><a href="#i_extractvalue">extractvalue</a></tt>' and 2061 '<tt><a href="#i_insertvalue">insertvalue</a></tt>' instructions.</p> 2062 2063<p>Structures may optionally be "packed" structures, which indicate that the 2064 alignment of the struct is one byte, and that there is no padding between 2065 the elements. In non-packed structs, padding between field types is inserted 2066 as defined by the TargetData string in the module, which is required to match 2067 what the underlying code generator expects.</p> 2068 2069<p>Structures can either be "literal" or "identified". A literal structure is 2070 defined inline with other types (e.g. <tt>{i32, i32}*</tt>) whereas identified 2071 types are always defined at the top level with a name. Literal types are 2072 uniqued by their contents and can never be recursive or opaque since there is 2073 no way to write one. Identified types can be recursive, can be opaqued, and are 2074 never uniqued. 2075</p> 2076 2077<h5>Syntax:</h5> 2078<pre> 2079 %T1 = type { <type list> } <i>; Identified normal struct type</i> 2080 %T2 = type <{ <type list> }> <i>; Identified packed struct type</i> 2081</pre> 2082 2083<h5>Examples:</h5> 2084<table class="layout"> 2085 <tr class="layout"> 2086 <td class="left"><tt>{ i32, i32, i32 }</tt></td> 2087 <td class="left">A triple of three <tt>i32</tt> values</td> 2088 </tr> 2089 <tr class="layout"> 2090 <td class="left"><tt>{ float, i32 (i32) * }</tt></td> 2091 <td class="left">A pair, where the first element is a <tt>float</tt> and the 2092 second element is a <a href="#t_pointer">pointer</a> to a 2093 <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning 2094 an <tt>i32</tt>.</td> 2095 </tr> 2096 <tr class="layout"> 2097 <td class="left"><tt><{ i8, i32 }></tt></td> 2098 <td class="left">A packed struct known to be 5 bytes in size.</td> 2099 </tr> 2100</table> 2101 2102</div> 2103 2104<!-- _______________________________________________________________________ --> 2105<h4> 2106 <a name="t_opaque">Opaque Structure Types</a> 2107</h4> 2108 2109<div> 2110 2111<h5>Overview:</h5> 2112<p>Opaque structure types are used to represent named structure types that do 2113 not have a body specified. This corresponds (for example) to the C notion of 2114 a forward declared structure.</p> 2115 2116<h5>Syntax:</h5> 2117<pre> 2118 %X = type opaque 2119 %52 = type opaque 2120</pre> 2121 2122<h5>Examples:</h5> 2123<table class="layout"> 2124 <tr class="layout"> 2125 <td class="left"><tt>opaque</tt></td> 2126 <td class="left">An opaque type.</td> 2127 </tr> 2128</table> 2129 2130</div> 2131 2132 2133 2134<!-- _______________________________________________________________________ --> 2135<h4> 2136 <a name="t_pointer">Pointer Type</a> 2137</h4> 2138 2139<div> 2140 2141<h5>Overview:</h5> 2142<p>The pointer type is used to specify memory locations. 2143 Pointers are commonly used to reference objects in memory.</p> 2144 2145<p>Pointer types may have an optional address space attribute defining the 2146 numbered address space where the pointed-to object resides. The default 2147 address space is number zero. The semantics of non-zero address 2148 spaces are target-specific.</p> 2149 2150<p>Note that LLVM does not permit pointers to void (<tt>void*</tt>) nor does it 2151 permit pointers to labels (<tt>label*</tt>). Use <tt>i8*</tt> instead.</p> 2152 2153<h5>Syntax:</h5> 2154<pre> 2155 <type> * 2156</pre> 2157 2158<h5>Examples:</h5> 2159<table class="layout"> 2160 <tr class="layout"> 2161 <td class="left"><tt>[4 x i32]*</tt></td> 2162 <td class="left">A <a href="#t_pointer">pointer</a> to <a 2163 href="#t_array">array</a> of four <tt>i32</tt> values.</td> 2164 </tr> 2165 <tr class="layout"> 2166 <td class="left"><tt>i32 (i32*) *</tt></td> 2167 <td class="left"> A <a href="#t_pointer">pointer</a> to a <a 2168 href="#t_function">function</a> that takes an <tt>i32*</tt>, returning an 2169 <tt>i32</tt>.</td> 2170 </tr> 2171 <tr class="layout"> 2172 <td class="left"><tt>i32 addrspace(5)*</tt></td> 2173 <td class="left">A <a href="#t_pointer">pointer</a> to an <tt>i32</tt> value 2174 that resides in address space #5.</td> 2175 </tr> 2176</table> 2177 2178</div> 2179 2180<!-- _______________________________________________________________________ --> 2181<h4> 2182 <a name="t_vector">Vector Type</a> 2183</h4> 2184 2185<div> 2186 2187<h5>Overview:</h5> 2188<p>A vector type is a simple derived type that represents a vector of elements. 2189 Vector types are used when multiple primitive data are operated in parallel 2190 using a single instruction (SIMD). A vector type requires a size (number of 2191 elements) and an underlying primitive data type. Vector types are considered 2192 <a href="#t_firstclass">first class</a>.</p> 2193 2194<h5>Syntax:</h5> 2195<pre> 2196 < <# elements> x <elementtype> > 2197</pre> 2198 2199<p>The number of elements is a constant integer value larger than 0; elementtype 2200 may be any integer or floating point type, or a pointer to these types. 2201 Vectors of size zero are not allowed. </p> 2202 2203<h5>Examples:</h5> 2204<table class="layout"> 2205 <tr class="layout"> 2206 <td class="left"><tt><4 x i32></tt></td> 2207 <td class="left">Vector of 4 32-bit integer values.</td> 2208 </tr> 2209 <tr class="layout"> 2210 <td class="left"><tt><8 x float></tt></td> 2211 <td class="left">Vector of 8 32-bit floating-point values.</td> 2212 </tr> 2213 <tr class="layout"> 2214 <td class="left"><tt><2 x i64></tt></td> 2215 <td class="left">Vector of 2 64-bit integer values.</td> 2216 </tr> 2217 <tr class="layout"> 2218 <td class="left"><tt><4 x i64*></tt></td> 2219 <td class="left">Vector of 4 pointers to 64-bit integer values.</td> 2220 </tr> 2221</table> 2222 2223</div> 2224 2225</div> 2226 2227</div> 2228 2229<!-- *********************************************************************** --> 2230<h2><a name="constants">Constants</a></h2> 2231<!-- *********************************************************************** --> 2232 2233<div> 2234 2235<p>LLVM has several different basic types of constants. This section describes 2236 them all and their syntax.</p> 2237 2238<!-- ======================================================================= --> 2239<h3> 2240 <a name="simpleconstants">Simple Constants</a> 2241</h3> 2242 2243<div> 2244 2245<dl> 2246 <dt><b>Boolean constants</b></dt> 2247 <dd>The two strings '<tt>true</tt>' and '<tt>false</tt>' are both valid 2248 constants of the <tt><a href="#t_integer">i1</a></tt> type.</dd> 2249 2250 <dt><b>Integer constants</b></dt> 2251 <dd>Standard integers (such as '4') are constants of 2252 the <a href="#t_integer">integer</a> type. Negative numbers may be used 2253 with integer types.</dd> 2254 2255 <dt><b>Floating point constants</b></dt> 2256 <dd>Floating point constants use standard decimal notation (e.g. 123.421), 2257 exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal 2258 notation (see below). The assembler requires the exact decimal value of a 2259 floating-point constant. For example, the assembler accepts 1.25 but 2260 rejects 1.3 because 1.3 is a repeating decimal in binary. Floating point 2261 constants must have a <a href="#t_floating">floating point</a> type. </dd> 2262 2263 <dt><b>Null pointer constants</b></dt> 2264 <dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant 2265 and must be of <a href="#t_pointer">pointer type</a>.</dd> 2266</dl> 2267 2268<p>The one non-intuitive notation for constants is the hexadecimal form of 2269 floating point constants. For example, the form '<tt>double 2270 0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) 2271 '<tt>double 4.5e+15</tt>'. The only time hexadecimal floating point 2272 constants are required (and the only time that they are generated by the 2273 disassembler) is when a floating point constant must be emitted but it cannot 2274 be represented as a decimal floating point number in a reasonable number of 2275 digits. For example, NaN's, infinities, and other special values are 2276 represented in their IEEE hexadecimal format so that assembly and disassembly 2277 do not cause any bits to change in the constants.</p> 2278 2279<p>When using the hexadecimal form, constants of types half, float, and double are 2280 represented using the 16-digit form shown above (which matches the IEEE754 2281 representation for double); half and float values must, however, be exactly 2282 representable as IEE754 half and single precision, respectively. 2283 Hexadecimal format is always used 2284 for long double, and there are three forms of long double. The 80-bit format 2285 used by x86 is represented as <tt>0xK</tt> followed by 20 hexadecimal digits. 2286 The 128-bit format used by PowerPC (two adjacent doubles) is represented 2287 by <tt>0xM</tt> followed by 32 hexadecimal digits. The IEEE 128-bit format 2288 is represented by <tt>0xL</tt> followed by 32 hexadecimal digits; no 2289 currently supported target uses this format. Long doubles will only work if 2290 they match the long double format on your target. All hexadecimal formats 2291 are big-endian (sign bit at the left).</p> 2292 2293<p>There are no constants of type x86mmx.</p> 2294</div> 2295 2296<!-- ======================================================================= --> 2297<h3> 2298<a name="aggregateconstants"></a> <!-- old anchor --> 2299<a name="complexconstants">Complex Constants</a> 2300</h3> 2301 2302<div> 2303 2304<p>Complex constants are a (potentially recursive) combination of simple 2305 constants and smaller complex constants.</p> 2306 2307<dl> 2308 <dt><b>Structure constants</b></dt> 2309 <dd>Structure constants are represented with notation similar to structure 2310 type definitions (a comma separated list of elements, surrounded by braces 2311 (<tt>{}</tt>)). For example: "<tt>{ i32 4, float 17.0, i32* @G }</tt>", 2312 where "<tt>@G</tt>" is declared as "<tt>@G = external global i32</tt>". 2313 Structure constants must have <a href="#t_struct">structure type</a>, and 2314 the number and types of elements must match those specified by the 2315 type.</dd> 2316 2317 <dt><b>Array constants</b></dt> 2318 <dd>Array constants are represented with notation similar to array type 2319 definitions (a comma separated list of elements, surrounded by square 2320 brackets (<tt>[]</tt>)). For example: "<tt>[ i32 42, i32 11, i32 74 2321 ]</tt>". Array constants must have <a href="#t_array">array type</a>, and 2322 the number and types of elements must match those specified by the 2323 type.</dd> 2324 2325 <dt><b>Vector constants</b></dt> 2326 <dd>Vector constants are represented with notation similar to vector type 2327 definitions (a comma separated list of elements, surrounded by 2328 less-than/greater-than's (<tt><></tt>)). For example: "<tt>< i32 2329 42, i32 11, i32 74, i32 100 ></tt>". Vector constants must 2330 have <a href="#t_vector">vector type</a>, and the number and types of 2331 elements must match those specified by the type.</dd> 2332 2333 <dt><b>Zero initialization</b></dt> 2334 <dd>The string '<tt>zeroinitializer</tt>' can be used to zero initialize a 2335 value to zero of <em>any</em> type, including scalar and 2336 <a href="#t_aggregate">aggregate</a> types. 2337 This is often used to avoid having to print large zero initializers 2338 (e.g. for large arrays) and is always exactly equivalent to using explicit 2339 zero initializers.</dd> 2340 2341 <dt><b>Metadata node</b></dt> 2342 <dd>A metadata node is a structure-like constant with 2343 <a href="#t_metadata">metadata type</a>. For example: "<tt>metadata !{ 2344 i32 0, metadata !"test" }</tt>". Unlike other constants that are meant to 2345 be interpreted as part of the instruction stream, metadata is a place to 2346 attach additional information such as debug info.</dd> 2347</dl> 2348 2349</div> 2350 2351<!-- ======================================================================= --> 2352<h3> 2353 <a name="globalconstants">Global Variable and Function Addresses</a> 2354</h3> 2355 2356<div> 2357 2358<p>The addresses of <a href="#globalvars">global variables</a> 2359 and <a href="#functionstructure">functions</a> are always implicitly valid 2360 (link-time) constants. These constants are explicitly referenced when 2361 the <a href="#identifiers">identifier for the global</a> is used and always 2362 have <a href="#t_pointer">pointer</a> type. For example, the following is a 2363 legal LLVM file:</p> 2364 2365<pre class="doc_code"> 2366@X = global i32 17 2367@Y = global i32 42 2368@Z = global [2 x i32*] [ i32* @X, i32* @Y ] 2369</pre> 2370 2371</div> 2372 2373<!-- ======================================================================= --> 2374<h3> 2375 <a name="undefvalues">Undefined Values</a> 2376</h3> 2377 2378<div> 2379 2380<p>The string '<tt>undef</tt>' can be used anywhere a constant is expected, and 2381 indicates that the user of the value may receive an unspecified bit-pattern. 2382 Undefined values may be of any type (other than '<tt>label</tt>' 2383 or '<tt>void</tt>') and be used anywhere a constant is permitted.</p> 2384 2385<p>Undefined values are useful because they indicate to the compiler that the 2386 program is well defined no matter what value is used. This gives the 2387 compiler more freedom to optimize. Here are some examples of (potentially 2388 surprising) transformations that are valid (in pseudo IR):</p> 2389 2390 2391<pre class="doc_code"> 2392 %A = add %X, undef 2393 %B = sub %X, undef 2394 %C = xor %X, undef 2395Safe: 2396 %A = undef 2397 %B = undef 2398 %C = undef 2399</pre> 2400 2401<p>This is safe because all of the output bits are affected by the undef bits. 2402 Any output bit can have a zero or one depending on the input bits.</p> 2403 2404<pre class="doc_code"> 2405 %A = or %X, undef 2406 %B = and %X, undef 2407Safe: 2408 %A = -1 2409 %B = 0 2410Unsafe: 2411 %A = undef 2412 %B = undef 2413</pre> 2414 2415<p>These logical operations have bits that are not always affected by the input. 2416 For example, if <tt>%X</tt> has a zero bit, then the output of the 2417 '<tt>and</tt>' operation will always be a zero for that bit, no matter what 2418 the corresponding bit from the '<tt>undef</tt>' is. As such, it is unsafe to 2419 optimize or assume that the result of the '<tt>and</tt>' is '<tt>undef</tt>'. 2420 However, it is safe to assume that all bits of the '<tt>undef</tt>' could be 2421 0, and optimize the '<tt>and</tt>' to 0. Likewise, it is safe to assume that 2422 all the bits of the '<tt>undef</tt>' operand to the '<tt>or</tt>' could be 2423 set, allowing the '<tt>or</tt>' to be folded to -1.</p> 2424 2425<pre class="doc_code"> 2426 %A = select undef, %X, %Y 2427 %B = select undef, 42, %Y 2428 %C = select %X, %Y, undef 2429Safe: 2430 %A = %X (or %Y) 2431 %B = 42 (or %Y) 2432 %C = %Y 2433Unsafe: 2434 %A = undef 2435 %B = undef 2436 %C = undef 2437</pre> 2438 2439<p>This set of examples shows that undefined '<tt>select</tt>' (and conditional 2440 branch) conditions can go <em>either way</em>, but they have to come from one 2441 of the two operands. In the <tt>%A</tt> example, if <tt>%X</tt> and 2442 <tt>%Y</tt> were both known to have a clear low bit, then <tt>%A</tt> would 2443 have to have a cleared low bit. However, in the <tt>%C</tt> example, the 2444 optimizer is allowed to assume that the '<tt>undef</tt>' operand could be the 2445 same as <tt>%Y</tt>, allowing the whole '<tt>select</tt>' to be 2446 eliminated.</p> 2447 2448<pre class="doc_code"> 2449 %A = xor undef, undef 2450 2451 %B = undef 2452 %C = xor %B, %B 2453 2454 %D = undef 2455 %E = icmp lt %D, 4 2456 %F = icmp gte %D, 4 2457 2458Safe: 2459 %A = undef 2460 %B = undef 2461 %C = undef 2462 %D = undef 2463 %E = undef 2464 %F = undef 2465</pre> 2466 2467<p>This example points out that two '<tt>undef</tt>' operands are not 2468 necessarily the same. This can be surprising to people (and also matches C 2469 semantics) where they assume that "<tt>X^X</tt>" is always zero, even 2470 if <tt>X</tt> is undefined. This isn't true for a number of reasons, but the 2471 short answer is that an '<tt>undef</tt>' "variable" can arbitrarily change 2472 its value over its "live range". This is true because the variable doesn't 2473 actually <em>have a live range</em>. Instead, the value is logically read 2474 from arbitrary registers that happen to be around when needed, so the value 2475 is not necessarily consistent over time. In fact, <tt>%A</tt> and <tt>%C</tt> 2476 need to have the same semantics or the core LLVM "replace all uses with" 2477 concept would not hold.</p> 2478 2479<pre class="doc_code"> 2480 %A = fdiv undef, %X 2481 %B = fdiv %X, undef 2482Safe: 2483 %A = undef 2484b: unreachable 2485</pre> 2486 2487<p>These examples show the crucial difference between an <em>undefined 2488 value</em> and <em>undefined behavior</em>. An undefined value (like 2489 '<tt>undef</tt>') is allowed to have an arbitrary bit-pattern. This means that 2490 the <tt>%A</tt> operation can be constant folded to '<tt>undef</tt>', because 2491 the '<tt>undef</tt>' could be an SNaN, and <tt>fdiv</tt> is not (currently) 2492 defined on SNaN's. However, in the second example, we can make a more 2493 aggressive assumption: because the <tt>undef</tt> is allowed to be an 2494 arbitrary value, we are allowed to assume that it could be zero. Since a 2495 divide by zero has <em>undefined behavior</em>, we are allowed to assume that 2496 the operation does not execute at all. This allows us to delete the divide and 2497 all code after it. Because the undefined operation "can't happen", the 2498 optimizer can assume that it occurs in dead code.</p> 2499 2500<pre class="doc_code"> 2501a: store undef -> %X 2502b: store %X -> undef 2503Safe: 2504a: <deleted> 2505b: unreachable 2506</pre> 2507 2508<p>These examples reiterate the <tt>fdiv</tt> example: a store <em>of</em> an 2509 undefined value can be assumed to not have any effect; we can assume that the 2510 value is overwritten with bits that happen to match what was already there. 2511 However, a store <em>to</em> an undefined location could clobber arbitrary 2512 memory, therefore, it has undefined behavior.</p> 2513 2514</div> 2515 2516<!-- ======================================================================= --> 2517<h3> 2518 <a name="poisonvalues">Poison Values</a> 2519</h3> 2520 2521<div> 2522 2523<p>Poison values are similar to <a href="#undefvalues">undef values</a>, however 2524 they also represent the fact that an instruction or constant expression which 2525 cannot evoke side effects has nevertheless detected a condition which results 2526 in undefined behavior.</p> 2527 2528<p>There is currently no way of representing a poison value in the IR; they 2529 only exist when produced by operations such as 2530 <a href="#i_add"><tt>add</tt></a> with the <tt>nsw</tt> flag.</p> 2531 2532<p>Poison value behavior is defined in terms of value <i>dependence</i>:</p> 2533 2534<ul> 2535<li>Values other than <a href="#i_phi"><tt>phi</tt></a> nodes depend on 2536 their operands.</li> 2537 2538<li><a href="#i_phi"><tt>Phi</tt></a> nodes depend on the operand corresponding 2539 to their dynamic predecessor basic block.</li> 2540 2541<li>Function arguments depend on the corresponding actual argument values in 2542 the dynamic callers of their functions.</li> 2543 2544<li><a href="#i_call"><tt>Call</tt></a> instructions depend on the 2545 <a href="#i_ret"><tt>ret</tt></a> instructions that dynamically transfer 2546 control back to them.</li> 2547 2548<li><a href="#i_invoke"><tt>Invoke</tt></a> instructions depend on the 2549 <a href="#i_ret"><tt>ret</tt></a>, <a href="#i_resume"><tt>resume</tt></a>, 2550 or exception-throwing call instructions that dynamically transfer control 2551 back to them.</li> 2552 2553<li>Non-volatile loads and stores depend on the most recent stores to all of the 2554 referenced memory addresses, following the order in the IR 2555 (including loads and stores implied by intrinsics such as 2556 <a href="#int_memcpy"><tt>@llvm.memcpy</tt></a>.)</li> 2557 2558<!-- TODO: In the case of multiple threads, this only applies if the store 2559 "happens-before" the load or store. --> 2560 2561<!-- TODO: floating-point exception state --> 2562 2563<li>An instruction with externally visible side effects depends on the most 2564 recent preceding instruction with externally visible side effects, following 2565 the order in the IR. (This includes 2566 <a href="#volatile">volatile operations</a>.)</li> 2567 2568<li>An instruction <i>control-depends</i> on a 2569 <a href="#terminators">terminator instruction</a> 2570 if the terminator instruction has multiple successors and the instruction 2571 is always executed when control transfers to one of the successors, and 2572 may not be executed when control is transferred to another.</li> 2573 2574<li>Additionally, an instruction also <i>control-depends</i> on a terminator 2575 instruction if the set of instructions it otherwise depends on would be 2576 different if the terminator had transferred control to a different 2577 successor.</li> 2578 2579<li>Dependence is transitive.</li> 2580 2581</ul> 2582 2583<p>Poison Values have the same behavior as <a href="#undefvalues">undef values</a>, 2584 with the additional affect that any instruction which has a <i>dependence</i> 2585 on a poison value has undefined behavior.</p> 2586 2587<p>Here are some examples:</p> 2588 2589<pre class="doc_code"> 2590entry: 2591 %poison = sub nuw i32 0, 1 ; Results in a poison value. 2592 %still_poison = and i32 %poison, 0 ; 0, but also poison. 2593 %poison_yet_again = getelementptr i32* @h, i32 %still_poison 2594 store i32 0, i32* %poison_yet_again ; memory at @h[0] is poisoned 2595 2596 store i32 %poison, i32* @g ; Poison value stored to memory. 2597 %poison2 = load i32* @g ; Poison value loaded back from memory. 2598 2599 store volatile i32 %poison, i32* @g ; External observation; undefined behavior. 2600 2601 %narrowaddr = bitcast i32* @g to i16* 2602 %wideaddr = bitcast i32* @g to i64* 2603 %poison3 = load i16* %narrowaddr ; Returns a poison value. 2604 %poison4 = load i64* %wideaddr ; Returns a poison value. 2605 2606 %cmp = icmp slt i32 %poison, 0 ; Returns a poison value. 2607 br i1 %cmp, label %true, label %end ; Branch to either destination. 2608 2609true: 2610 store volatile i32 0, i32* @g ; This is control-dependent on %cmp, so 2611 ; it has undefined behavior. 2612 br label %end 2613 2614end: 2615 %p = phi i32 [ 0, %entry ], [ 1, %true ] 2616 ; Both edges into this PHI are 2617 ; control-dependent on %cmp, so this 2618 ; always results in a poison value. 2619 2620 store volatile i32 0, i32* @g ; This would depend on the store in %true 2621 ; if %cmp is true, or the store in %entry 2622 ; otherwise, so this is undefined behavior. 2623 2624 br i1 %cmp, label %second_true, label %second_end 2625 ; The same branch again, but this time the 2626 ; true block doesn't have side effects. 2627 2628second_true: 2629 ; No side effects! 2630 ret void 2631 2632second_end: 2633 store volatile i32 0, i32* @g ; This time, the instruction always depends 2634 ; on the store in %end. Also, it is 2635 ; control-equivalent to %end, so this is 2636 ; well-defined (ignoring earlier undefined 2637 ; behavior in this example). 2638</pre> 2639 2640</div> 2641 2642<!-- ======================================================================= --> 2643<h3> 2644 <a name="blockaddress">Addresses of Basic Blocks</a> 2645</h3> 2646 2647<div> 2648 2649<p><b><tt>blockaddress(@function, %block)</tt></b></p> 2650 2651<p>The '<tt>blockaddress</tt>' constant computes the address of the specified 2652 basic block in the specified function, and always has an i8* type. Taking 2653 the address of the entry block is illegal.</p> 2654 2655<p>This value only has defined behavior when used as an operand to the 2656 '<a href="#i_indirectbr"><tt>indirectbr</tt></a>' instruction, or for 2657 comparisons against null. Pointer equality tests between labels addresses 2658 results in undefined behavior — though, again, comparison against null 2659 is ok, and no label is equal to the null pointer. This may be passed around 2660 as an opaque pointer sized value as long as the bits are not inspected. This 2661 allows <tt>ptrtoint</tt> and arithmetic to be performed on these values so 2662 long as the original value is reconstituted before the <tt>indirectbr</tt> 2663 instruction.</p> 2664 2665<p>Finally, some targets may provide defined semantics when using the value as 2666 the operand to an inline assembly, but that is target specific.</p> 2667 2668</div> 2669 2670 2671<!-- ======================================================================= --> 2672<h3> 2673 <a name="constantexprs">Constant Expressions</a> 2674</h3> 2675 2676<div> 2677 2678<p>Constant expressions are used to allow expressions involving other constants 2679 to be used as constants. Constant expressions may be of 2680 any <a href="#t_firstclass">first class</a> type and may involve any LLVM 2681 operation that does not have side effects (e.g. load and call are not 2682 supported). The following is the syntax for constant expressions:</p> 2683 2684<dl> 2685 <dt><b><tt>trunc (CST to TYPE)</tt></b></dt> 2686 <dd>Truncate a constant to another type. The bit size of CST must be larger 2687 than the bit size of TYPE. Both types must be integers.</dd> 2688 2689 <dt><b><tt>zext (CST to TYPE)</tt></b></dt> 2690 <dd>Zero extend a constant to another type. The bit size of CST must be 2691 smaller than the bit size of TYPE. Both types must be integers.</dd> 2692 2693 <dt><b><tt>sext (CST to TYPE)</tt></b></dt> 2694 <dd>Sign extend a constant to another type. The bit size of CST must be 2695 smaller than the bit size of TYPE. Both types must be integers.</dd> 2696 2697 <dt><b><tt>fptrunc (CST to TYPE)</tt></b></dt> 2698 <dd>Truncate a floating point constant to another floating point type. The 2699 size of CST must be larger than the size of TYPE. Both types must be 2700 floating point.</dd> 2701 2702 <dt><b><tt>fpext (CST to TYPE)</tt></b></dt> 2703 <dd>Floating point extend a constant to another type. The size of CST must be 2704 smaller or equal to the size of TYPE. Both types must be floating 2705 point.</dd> 2706 2707 <dt><b><tt>fptoui (CST to TYPE)</tt></b></dt> 2708 <dd>Convert a floating point constant to the corresponding unsigned integer 2709 constant. TYPE must be a scalar or vector integer type. CST must be of 2710 scalar or vector floating point type. Both CST and TYPE must be scalars, 2711 or vectors of the same number of elements. If the value won't fit in the 2712 integer type, the results are undefined.</dd> 2713 2714 <dt><b><tt>fptosi (CST to TYPE)</tt></b></dt> 2715 <dd>Convert a floating point constant to the corresponding signed integer 2716 constant. TYPE must be a scalar or vector integer type. CST must be of 2717 scalar or vector floating point type. Both CST and TYPE must be scalars, 2718 or vectors of the same number of elements. If the value won't fit in the 2719 integer type, the results are undefined.</dd> 2720 2721 <dt><b><tt>uitofp (CST to TYPE)</tt></b></dt> 2722 <dd>Convert an unsigned integer constant to the corresponding floating point 2723 constant. TYPE must be a scalar or vector floating point type. CST must be 2724 of scalar or vector integer type. Both CST and TYPE must be scalars, or 2725 vectors of the same number of elements. If the value won't fit in the 2726 floating point type, the results are undefined.</dd> 2727 2728 <dt><b><tt>sitofp (CST to TYPE)</tt></b></dt> 2729 <dd>Convert a signed integer constant to the corresponding floating point 2730 constant. TYPE must be a scalar or vector floating point type. CST must be 2731 of scalar or vector integer type. Both CST and TYPE must be scalars, or 2732 vectors of the same number of elements. If the value won't fit in the 2733 floating point type, the results are undefined.</dd> 2734 2735 <dt><b><tt>ptrtoint (CST to TYPE)</tt></b></dt> 2736 <dd>Convert a pointer typed constant to the corresponding integer constant 2737 <tt>TYPE</tt> must be an integer type. <tt>CST</tt> must be of pointer 2738 type. The <tt>CST</tt> value is zero extended, truncated, or unchanged to 2739 make it fit in <tt>TYPE</tt>.</dd> 2740 2741 <dt><b><tt>inttoptr (CST to TYPE)</tt></b></dt> 2742 <dd>Convert a integer constant to a pointer constant. TYPE must be a pointer 2743 type. CST must be of integer type. The CST value is zero extended, 2744 truncated, or unchanged to make it fit in a pointer size. This one is 2745 <i>really</i> dangerous!</dd> 2746 2747 <dt><b><tt>bitcast (CST to TYPE)</tt></b></dt> 2748 <dd>Convert a constant, CST, to another TYPE. The constraints of the operands 2749 are the same as those for the <a href="#i_bitcast">bitcast 2750 instruction</a>.</dd> 2751 2752 <dt><b><tt>getelementptr (CSTPTR, IDX0, IDX1, ...)</tt></b></dt> 2753 <dt><b><tt>getelementptr inbounds (CSTPTR, IDX0, IDX1, ...)</tt></b></dt> 2754 <dd>Perform the <a href="#i_getelementptr">getelementptr operation</a> on 2755 constants. As with the <a href="#i_getelementptr">getelementptr</a> 2756 instruction, the index list may have zero or more indexes, which are 2757 required to make sense for the type of "CSTPTR".</dd> 2758 2759 <dt><b><tt>select (COND, VAL1, VAL2)</tt></b></dt> 2760 <dd>Perform the <a href="#i_select">select operation</a> on constants.</dd> 2761 2762 <dt><b><tt>icmp COND (VAL1, VAL2)</tt></b></dt> 2763 <dd>Performs the <a href="#i_icmp">icmp operation</a> on constants.</dd> 2764 2765 <dt><b><tt>fcmp COND (VAL1, VAL2)</tt></b></dt> 2766 <dd>Performs the <a href="#i_fcmp">fcmp operation</a> on constants.</dd> 2767 2768 <dt><b><tt>extractelement (VAL, IDX)</tt></b></dt> 2769 <dd>Perform the <a href="#i_extractelement">extractelement operation</a> on 2770 constants.</dd> 2771 2772 <dt><b><tt>insertelement (VAL, ELT, IDX)</tt></b></dt> 2773 <dd>Perform the <a href="#i_insertelement">insertelement operation</a> on 2774 constants.</dd> 2775 2776 <dt><b><tt>shufflevector (VEC1, VEC2, IDXMASK)</tt></b></dt> 2777 <dd>Perform the <a href="#i_shufflevector">shufflevector operation</a> on 2778 constants.</dd> 2779 2780 <dt><b><tt>extractvalue (VAL, IDX0, IDX1, ...)</tt></b></dt> 2781 <dd>Perform the <a href="#i_extractvalue">extractvalue operation</a> on 2782 constants. The index list is interpreted in a similar manner as indices in 2783 a '<a href="#i_getelementptr">getelementptr</a>' operation. At least one 2784 index value must be specified.</dd> 2785 2786 <dt><b><tt>insertvalue (VAL, ELT, IDX0, IDX1, ...)</tt></b></dt> 2787 <dd>Perform the <a href="#i_insertvalue">insertvalue operation</a> on 2788 constants. The index list is interpreted in a similar manner as indices in 2789 a '<a href="#i_getelementptr">getelementptr</a>' operation. At least one 2790 index value must be specified.</dd> 2791 2792 <dt><b><tt>OPCODE (LHS, RHS)</tt></b></dt> 2793 <dd>Perform the specified operation of the LHS and RHS constants. OPCODE may 2794 be any of the <a href="#binaryops">binary</a> 2795 or <a href="#bitwiseops">bitwise binary</a> operations. The constraints 2796 on operands are the same as those for the corresponding instruction 2797 (e.g. no bitwise operations on floating point values are allowed).</dd> 2798</dl> 2799 2800</div> 2801 2802</div> 2803 2804<!-- *********************************************************************** --> 2805<h2><a name="othervalues">Other Values</a></h2> 2806<!-- *********************************************************************** --> 2807<div> 2808<!-- ======================================================================= --> 2809<h3> 2810<a name="inlineasm">Inline Assembler Expressions</a> 2811</h3> 2812 2813<div> 2814 2815<p>LLVM supports inline assembler expressions (as opposed 2816 to <a href="#moduleasm">Module-Level Inline Assembly</a>) through the use of 2817 a special value. This value represents the inline assembler as a string 2818 (containing the instructions to emit), a list of operand constraints (stored 2819 as a string), a flag that indicates whether or not the inline asm 2820 expression has side effects, and a flag indicating whether the function 2821 containing the asm needs to align its stack conservatively. An example 2822 inline assembler expression is:</p> 2823 2824<pre class="doc_code"> 2825i32 (i32) asm "bswap $0", "=r,r" 2826</pre> 2827 2828<p>Inline assembler expressions may <b>only</b> be used as the callee operand of 2829 a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we 2830 have:</p> 2831 2832<pre class="doc_code"> 2833%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y) 2834</pre> 2835 2836<p>Inline asms with side effects not visible in the constraint list must be 2837 marked as having side effects. This is done through the use of the 2838 '<tt>sideeffect</tt>' keyword, like so:</p> 2839 2840<pre class="doc_code"> 2841call void asm sideeffect "eieio", ""() 2842</pre> 2843 2844<p>In some cases inline asms will contain code that will not work unless the 2845 stack is aligned in some way, such as calls or SSE instructions on x86, 2846 yet will not contain code that does that alignment within the asm. 2847 The compiler should make conservative assumptions about what the asm might 2848 contain and should generate its usual stack alignment code in the prologue 2849 if the '<tt>alignstack</tt>' keyword is present:</p> 2850 2851<pre class="doc_code"> 2852call void asm alignstack "eieio", ""() 2853</pre> 2854 2855<p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come 2856 first.</p> 2857 2858<!-- 2859<p>TODO: The format of the asm and constraints string still need to be 2860 documented here. Constraints on what can be done (e.g. duplication, moving, 2861 etc need to be documented). This is probably best done by reference to 2862 another document that covers inline asm from a holistic perspective.</p> 2863 --> 2864 2865<!-- _______________________________________________________________________ --> 2866<h4> 2867 <a name="inlineasm_md">Inline Asm Metadata</a> 2868</h4> 2869 2870<div> 2871 2872<p>The call instructions that wrap inline asm nodes may have a 2873 "<tt>!srcloc</tt>" MDNode attached to it that contains a list of constant 2874 integers. If present, the code generator will use the integer as the 2875 location cookie value when report errors through the <tt>LLVMContext</tt> 2876 error reporting mechanisms. This allows a front-end to correlate backend 2877 errors that occur with inline asm back to the source code that produced it. 2878 For example:</p> 2879 2880<pre class="doc_code"> 2881call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b> 2882... 2883!42 = !{ i32 1234567 } 2884</pre> 2885 2886<p>It is up to the front-end to make sense of the magic numbers it places in the 2887 IR. If the MDNode contains multiple constants, the code generator will use 2888 the one that corresponds to the line of the asm that the error occurs on.</p> 2889 2890</div> 2891 2892</div> 2893 2894<!-- ======================================================================= --> 2895<h3> 2896 <a name="metadata">Metadata Nodes and Metadata Strings</a> 2897</h3> 2898 2899<div> 2900 2901<p>LLVM IR allows metadata to be attached to instructions in the program that 2902 can convey extra information about the code to the optimizers and code 2903 generator. One example application of metadata is source-level debug 2904 information. There are two metadata primitives: strings and nodes. All 2905 metadata has the <tt>metadata</tt> type and is identified in syntax by a 2906 preceding exclamation point ('<tt>!</tt>').</p> 2907 2908<p>A metadata string is a string surrounded by double quotes. It can contain 2909 any character by escaping non-printable characters with "<tt>\xx</tt>" where 2910 "<tt>xx</tt>" is the two digit hex code. For example: 2911 "<tt>!"test\00"</tt>".</p> 2912 2913<p>Metadata nodes are represented with notation similar to structure constants 2914 (a comma separated list of elements, surrounded by braces and preceded by an 2915 exclamation point). Metadata nodes can have any values as their operand. For 2916 example:</p> 2917 2918<div class="doc_code"> 2919<pre> 2920!{ metadata !"test\00", i32 10} 2921</pre> 2922</div> 2923 2924<p>A <a href="#namedmetadatastructure">named metadata</a> is a collection of 2925 metadata nodes, which can be looked up in the module symbol table. For 2926 example:</p> 2927 2928<div class="doc_code"> 2929<pre> 2930!foo = metadata !{!4, !3} 2931</pre> 2932</div> 2933 2934<p>Metadata can be used as function arguments. Here <tt>llvm.dbg.value</tt> 2935 function is using two metadata arguments:</p> 2936 2937<div class="doc_code"> 2938<pre> 2939call void @llvm.dbg.value(metadata !24, i64 0, metadata !25) 2940</pre> 2941</div> 2942 2943<p>Metadata can be attached with an instruction. Here metadata <tt>!21</tt> is 2944 attached to the <tt>add</tt> instruction using the <tt>!dbg</tt> 2945 identifier:</p> 2946 2947<div class="doc_code"> 2948<pre> 2949%indvar.next = add i64 %indvar, 1, !dbg !21 2950</pre> 2951</div> 2952 2953<p>More information about specific metadata nodes recognized by the optimizers 2954 and code generator is found below.</p> 2955 2956<!-- _______________________________________________________________________ --> 2957<h4> 2958 <a name="tbaa">'<tt>tbaa</tt>' Metadata</a> 2959</h4> 2960 2961<div> 2962 2963<p>In LLVM IR, memory does not have types, so LLVM's own type system is not 2964 suitable for doing TBAA. Instead, metadata is added to the IR to describe 2965 a type system of a higher level language. This can be used to implement 2966 typical C/C++ TBAA, but it can also be used to implement custom alias 2967 analysis behavior for other languages.</p> 2968 2969<p>The current metadata format is very simple. TBAA metadata nodes have up to 2970 three fields, e.g.:</p> 2971 2972<div class="doc_code"> 2973<pre> 2974!0 = metadata !{ metadata !"an example type tree" } 2975!1 = metadata !{ metadata !"int", metadata !0 } 2976!2 = metadata !{ metadata !"float", metadata !0 } 2977!3 = metadata !{ metadata !"const float", metadata !2, i64 1 } 2978</pre> 2979</div> 2980 2981<p>The first field is an identity field. It can be any value, usually 2982 a metadata string, which uniquely identifies the type. The most important 2983 name in the tree is the name of the root node. Two trees with 2984 different root node names are entirely disjoint, even if they 2985 have leaves with common names.</p> 2986 2987<p>The second field identifies the type's parent node in the tree, or 2988 is null or omitted for a root node. A type is considered to alias 2989 all of its descendants and all of its ancestors in the tree. Also, 2990 a type is considered to alias all types in other trees, so that 2991 bitcode produced from multiple front-ends is handled conservatively.</p> 2992 2993<p>If the third field is present, it's an integer which if equal to 1 2994 indicates that the type is "constant" (meaning 2995 <tt>pointsToConstantMemory</tt> should return true; see 2996 <a href="AliasAnalysis.html#OtherItfs">other useful 2997 <tt>AliasAnalysis</tt> methods</a>).</p> 2998 2999</div> 3000 3001<!-- _______________________________________________________________________ --> 3002<h4> 3003 <a name="fpmath">'<tt>fpmath</tt>' Metadata</a> 3004</h4> 3005 3006<div> 3007 3008<p><tt>fpmath</tt> metadata may be attached to any instruction of floating point 3009 type. It can be used to express the maximum acceptable error in the result of 3010 that instruction, in ULPs, thus potentially allowing the compiler to use a 3011 more efficient but less accurate method of computing it. ULP is defined as 3012 follows:</p> 3013 3014<blockquote> 3015 3016<p>If <tt>x</tt> is a real number that lies between two finite consecutive 3017 floating-point numbers <tt>a</tt> and <tt>b</tt>, without being equal to one 3018 of them, then <tt>ulp(x) = |b - a|</tt>, otherwise <tt>ulp(x)</tt> is the 3019 distance between the two non-equal finite floating-point numbers nearest 3020 <tt>x</tt>. Moreover, <tt>ulp(NaN)</tt> is <tt>NaN</tt>.</p> 3021 3022</blockquote> 3023 3024<p>The metadata node shall consist of a single positive floating point number 3025 representing the maximum relative error, for example:</p> 3026 3027<div class="doc_code"> 3028<pre> 3029!0 = metadata !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs 3030</pre> 3031</div> 3032 3033</div> 3034 3035<!-- _______________________________________________________________________ --> 3036<h4> 3037 <a name="range">'<tt>range</tt>' Metadata</a> 3038</h4> 3039 3040<div> 3041<p><tt>range</tt> metadata may be attached only to loads of integer types. It 3042 expresses the possible ranges the loaded value is in. The ranges are 3043 represented with a flattened list of integers. The loaded value is known to 3044 be in the union of the ranges defined by each consecutive pair. Each pair 3045 has the following properties:</p> 3046<ul> 3047 <li>The type must match the type loaded by the instruction.</li> 3048 <li>The pair <tt>a,b</tt> represents the range <tt>[a,b)</tt>.</li> 3049 <li>Both <tt>a</tt> and <tt>b</tt> are constants.</li> 3050 <li>The range is allowed to wrap.</li> 3051 <li>The range should not represent the full or empty set. That is, 3052 <tt>a!=b</tt>. </li> 3053</ul> 3054 3055<p>Examples:</p> 3056<div class="doc_code"> 3057<pre> 3058 %a = load i8* %x, align 1, !range !0 ; Can only be 0 or 1 3059 %b = load i8* %y, align 1, !range !1 ; Can only be 255 (-1), 0 or 1 3060 %c = load i8* %z, align 1, !range !2 ; Can only be 0, 1, 3, 4 or 5 3061... 3062!0 = metadata !{ i8 0, i8 2 } 3063!1 = metadata !{ i8 255, i8 2 } 3064!2 = metadata !{ i8 0, i8 2, i8 3, i8 6 } 3065</pre> 3066</div> 3067</div> 3068</div> 3069 3070</div> 3071 3072<!-- *********************************************************************** --> 3073<h2> 3074 <a name="module_flags">Module Flags Metadata</a> 3075</h2> 3076<!-- *********************************************************************** --> 3077 3078<div> 3079 3080<p>Information about the module as a whole is difficult to convey to LLVM's 3081 subsystems. The LLVM IR isn't sufficient to transmit this 3082 information. The <tt>llvm.module.flags</tt> named metadata exists in order to 3083 facilitate this. These flags are in the form of key / value pairs — 3084 much like a dictionary — making it easy for any subsystem who cares 3085 about a flag to look it up.</p> 3086 3087<p>The <tt>llvm.module.flags</tt> metadata contains a list of metadata 3088 triplets. Each triplet has the following form:</p> 3089 3090<ul> 3091 <li>The first element is a <i>behavior</i> flag, which specifies the behavior 3092 when two (or more) modules are merged together, and it encounters two (or 3093 more) metadata with the same ID. The supported behaviors are described 3094 below.</li> 3095 3096 <li>The second element is a metadata string that is a unique ID for the 3097 metadata. How each ID is interpreted is documented below.</li> 3098 3099 <li>The third element is the value of the flag.</li> 3100</ul> 3101 3102<p>When two (or more) modules are merged together, the resulting 3103 <tt>llvm.module.flags</tt> metadata is the union of the 3104 modules' <tt>llvm.module.flags</tt> metadata. The only exception being a flag 3105 with the <i>Override</i> behavior, which may override another flag's value 3106 (see below).</p> 3107 3108<p>The following behaviors are supported:</p> 3109 3110<table border="1" cellspacing="0" cellpadding="4"> 3111 <tbody> 3112 <tr> 3113 <th>Value</th> 3114 <th>Behavior</th> 3115 </tr> 3116 <tr> 3117 <td>1</td> 3118 <td align="left"> 3119 <dl> 3120 <dt><b>Error</b></dt> 3121 <dd>Emits an error if two values disagree. It is an error to have an ID 3122 with both an Error and a Warning behavior.</dd> 3123 </dl> 3124 </td> 3125 </tr> 3126 <tr> 3127 <td>2</td> 3128 <td align="left"> 3129 <dl> 3130 <dt><b>Warning</b></dt> 3131 <dd>Emits a warning if two values disagree.</dd> 3132 </dl> 3133 </td> 3134 </tr> 3135 <tr> 3136 <td>3</td> 3137 <td align="left"> 3138 <dl> 3139 <dt><b>Require</b></dt> 3140 <dd>Emits an error when the specified value is not present or doesn't 3141 have the specified value. It is an error for two (or more) 3142 <tt>llvm.module.flags</tt> with the same ID to have the Require 3143 behavior but different values. There may be multiple Require flags 3144 per ID.</dd> 3145 </dl> 3146 </td> 3147 </tr> 3148 <tr> 3149 <td>4</td> 3150 <td align="left"> 3151 <dl> 3152 <dt><b>Override</b></dt> 3153 <dd>Uses the specified value if the two values disagree. It is an 3154 error for two (or more) <tt>llvm.module.flags</tt> with the same 3155 ID to have the Override behavior but different values.</dd> 3156 </dl> 3157 </td> 3158 </tr> 3159 </tbody> 3160</table> 3161 3162<p>An example of module flags:</p> 3163 3164<pre class="doc_code"> 3165!0 = metadata !{ i32 1, metadata !"foo", i32 1 } 3166!1 = metadata !{ i32 4, metadata !"bar", i32 37 } 3167!2 = metadata !{ i32 2, metadata !"qux", i32 42 } 3168!3 = metadata !{ i32 3, metadata !"qux", 3169 metadata !{ 3170 metadata !"foo", i32 1 3171 } 3172} 3173!llvm.module.flags = !{ !0, !1, !2, !3 } 3174</pre> 3175 3176<ul> 3177 <li><p>Metadata <tt>!0</tt> has the ID <tt>!"foo"</tt> and the value '1'. The 3178 behavior if two or more <tt>!"foo"</tt> flags are seen is to emit an 3179 error if their values are not equal.</p></li> 3180 3181 <li><p>Metadata <tt>!1</tt> has the ID <tt>!"bar"</tt> and the value '37'. The 3182 behavior if two or more <tt>!"bar"</tt> flags are seen is to use the 3183 value '37' if their values are not equal.</p></li> 3184 3185 <li><p>Metadata <tt>!2</tt> has the ID <tt>!"qux"</tt> and the value '42'. The 3186 behavior if two or more <tt>!"qux"</tt> flags are seen is to emit a 3187 warning if their values are not equal.</p></li> 3188 3189 <li><p>Metadata <tt>!3</tt> has the ID <tt>!"qux"</tt> and the value:</p> 3190 3191<pre class="doc_code"> 3192metadata !{ metadata !"foo", i32 1 } 3193</pre> 3194 3195 <p>The behavior is to emit an error if the <tt>llvm.module.flags</tt> does 3196 not contain a flag with the ID <tt>!"foo"</tt> that has the value 3197 '1'. If two or more <tt>!"qux"</tt> flags exist, then they must have 3198 the same value or an error will be issued.</p></li> 3199</ul> 3200 3201 3202<!-- ======================================================================= --> 3203<h3> 3204<a name="objc_gc_flags">Objective-C Garbage Collection Module Flags Metadata</a> 3205</h3> 3206 3207<div> 3208 3209<p>On the Mach-O platform, Objective-C stores metadata about garbage collection 3210 in a special section called "image info". The metadata consists of a version 3211 number and a bitmask specifying what types of garbage collection are 3212 supported (if any) by the file. If two or more modules are linked together 3213 their garbage collection metadata needs to be merged rather than appended 3214 together.</p> 3215 3216<p>The Objective-C garbage collection module flags metadata consists of the 3217 following key-value pairs:</p> 3218 3219<table border="1" cellspacing="0" cellpadding="4"> 3220 <col width="30%"> 3221 <tbody> 3222 <tr> 3223 <th>Key</th> 3224 <th>Value</th> 3225 </tr> 3226 <tr> 3227 <td><tt>Objective-C Version</tt></td> 3228 <td align="left"><b>[Required]</b> — The Objective-C ABI 3229 version. Valid values are 1 and 2.</td> 3230 </tr> 3231 <tr> 3232 <td><tt>Objective-C Image Info Version</tt></td> 3233 <td align="left"><b>[Required]</b> — The version of the image info 3234 section. Currently always 0.</td> 3235 </tr> 3236 <tr> 3237 <td><tt>Objective-C Image Info Section</tt></td> 3238 <td align="left"><b>[Required]</b> — The section to place the 3239 metadata. Valid values are <tt>"__OBJC, __image_info, regular"</tt> for 3240 Objective-C ABI version 1, and <tt>"__DATA,__objc_imageinfo, regular, 3241 no_dead_strip"</tt> for Objective-C ABI version 2.</td> 3242 </tr> 3243 <tr> 3244 <td><tt>Objective-C Garbage Collection</tt></td> 3245 <td align="left"><b>[Required]</b> — Specifies whether garbage 3246 collection is supported or not. Valid values are 0, for no garbage 3247 collection, and 2, for garbage collection supported.</td> 3248 </tr> 3249 <tr> 3250 <td><tt>Objective-C GC Only</tt></td> 3251 <td align="left"><b>[Optional]</b> — Specifies that only garbage 3252 collection is supported. If present, its value must be 6. This flag 3253 requires that the <tt>Objective-C Garbage Collection</tt> flag have the 3254 value 2.</td> 3255 </tr> 3256 </tbody> 3257</table> 3258 3259<p>Some important flag interactions:</p> 3260 3261<ul> 3262 <li>If a module with <tt>Objective-C Garbage Collection</tt> set to 0 is 3263 merged with a module with <tt>Objective-C Garbage Collection</tt> set to 3264 2, then the resulting module has the <tt>Objective-C Garbage 3265 Collection</tt> flag set to 0.</li> 3266 3267 <li>A module with <tt>Objective-C Garbage Collection</tt> set to 0 cannot be 3268 merged with a module with <tt>Objective-C GC Only</tt> set to 6.</li> 3269</ul> 3270 3271</div> 3272 3273</div> 3274 3275<!-- *********************************************************************** --> 3276<h2> 3277 <a name="intrinsic_globals">Intrinsic Global Variables</a> 3278</h2> 3279<!-- *********************************************************************** --> 3280<div> 3281<p>LLVM has a number of "magic" global variables that contain data that affect 3282code generation or other IR semantics. These are documented here. All globals 3283of this sort should have a section specified as "<tt>llvm.metadata</tt>". This 3284section and all globals that start with "<tt>llvm.</tt>" are reserved for use 3285by LLVM.</p> 3286 3287<!-- ======================================================================= --> 3288<h3> 3289<a name="intg_used">The '<tt>llvm.used</tt>' Global Variable</a> 3290</h3> 3291 3292<div> 3293 3294<p>The <tt>@llvm.used</tt> global is an array with i8* element type which has <a 3295href="#linkage_appending">appending linkage</a>. This array contains a list of 3296pointers to global variables and functions which may optionally have a pointer 3297cast formed of bitcast or getelementptr. For example, a legal use of it is:</p> 3298 3299<div class="doc_code"> 3300<pre> 3301@X = global i8 4 3302@Y = global i32 123 3303 3304@llvm.used = appending global [2 x i8*] [ 3305 i8* @X, 3306 i8* bitcast (i32* @Y to i8*) 3307], section "llvm.metadata" 3308</pre> 3309</div> 3310 3311<p>If a global variable appears in the <tt>@llvm.used</tt> list, then the 3312 compiler, assembler, and linker are required to treat the symbol as if there 3313 is a reference to the global that it cannot see. For example, if a variable 3314 has internal linkage and no references other than that from 3315 the <tt>@llvm.used</tt> list, it cannot be deleted. This is commonly used to 3316 represent references from inline asms and other things the compiler cannot 3317 "see", and corresponds to "<tt>attribute((used))</tt>" in GNU C.</p> 3318 3319<p>On some targets, the code generator must emit a directive to the assembler or 3320 object file to prevent the assembler and linker from molesting the 3321 symbol.</p> 3322 3323</div> 3324 3325<!-- ======================================================================= --> 3326<h3> 3327 <a name="intg_compiler_used"> 3328 The '<tt>llvm.compiler.used</tt>' Global Variable 3329 </a> 3330</h3> 3331 3332<div> 3333 3334<p>The <tt>@llvm.compiler.used</tt> directive is the same as the 3335 <tt>@llvm.used</tt> directive, except that it only prevents the compiler from 3336 touching the symbol. On targets that support it, this allows an intelligent 3337 linker to optimize references to the symbol without being impeded as it would 3338 be by <tt>@llvm.used</tt>.</p> 3339 3340<p>This is a rare construct that should only be used in rare circumstances, and 3341 should not be exposed to source languages.</p> 3342 3343</div> 3344 3345<!-- ======================================================================= --> 3346<h3> 3347<a name="intg_global_ctors">The '<tt>llvm.global_ctors</tt>' Global Variable</a> 3348</h3> 3349 3350<div> 3351 3352<div class="doc_code"> 3353<pre> 3354%0 = type { i32, void ()* } 3355@llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }] 3356</pre> 3357</div> 3358 3359<p>The <tt>@llvm.global_ctors</tt> array contains a list of constructor 3360 functions and associated priorities. The functions referenced by this array 3361 will be called in ascending order of priority (i.e. lowest first) when the 3362 module is loaded. The order of functions with the same priority is not 3363 defined.</p> 3364 3365</div> 3366 3367<!-- ======================================================================= --> 3368<h3> 3369<a name="intg_global_dtors">The '<tt>llvm.global_dtors</tt>' Global Variable</a> 3370</h3> 3371 3372<div> 3373 3374<div class="doc_code"> 3375<pre> 3376%0 = type { i32, void ()* } 3377@llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }] 3378</pre> 3379</div> 3380 3381<p>The <tt>@llvm.global_dtors</tt> array contains a list of destructor functions 3382 and associated priorities. The functions referenced by this array will be 3383 called in descending order of priority (i.e. highest first) when the module 3384 is loaded. The order of functions with the same priority is not defined.</p> 3385 3386</div> 3387 3388</div> 3389 3390<!-- *********************************************************************** --> 3391<h2><a name="instref">Instruction Reference</a></h2> 3392<!-- *********************************************************************** --> 3393 3394<div> 3395 3396<p>The LLVM instruction set consists of several different classifications of 3397 instructions: <a href="#terminators">terminator 3398 instructions</a>, <a href="#binaryops">binary instructions</a>, 3399 <a href="#bitwiseops">bitwise binary instructions</a>, 3400 <a href="#memoryops">memory instructions</a>, and 3401 <a href="#otherops">other instructions</a>.</p> 3402 3403<!-- ======================================================================= --> 3404<h3> 3405 <a name="terminators">Terminator Instructions</a> 3406</h3> 3407 3408<div> 3409 3410<p>As mentioned <a href="#functionstructure">previously</a>, every basic block 3411 in a program ends with a "Terminator" instruction, which indicates which 3412 block should be executed after the current block is finished. These 3413 terminator instructions typically yield a '<tt>void</tt>' value: they produce 3414 control flow, not values (the one exception being the 3415 '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p> 3416 3417<p>The terminator instructions are: 3418 '<a href="#i_ret"><tt>ret</tt></a>', 3419 '<a href="#i_br"><tt>br</tt></a>', 3420 '<a href="#i_switch"><tt>switch</tt></a>', 3421 '<a href="#i_indirectbr"><tt>indirectbr</tt></a>', 3422 '<a href="#i_invoke"><tt>invoke</tt></a>', 3423 '<a href="#i_resume"><tt>resume</tt></a>', and 3424 '<a href="#i_unreachable"><tt>unreachable</tt></a>'.</p> 3425 3426<!-- _______________________________________________________________________ --> 3427<h4> 3428 <a name="i_ret">'<tt>ret</tt>' Instruction</a> 3429</h4> 3430 3431<div> 3432 3433<h5>Syntax:</h5> 3434<pre> 3435 ret <type> <value> <i>; Return a value from a non-void function</i> 3436 ret void <i>; Return from void function</i> 3437</pre> 3438 3439<h5>Overview:</h5> 3440<p>The '<tt>ret</tt>' instruction is used to return control flow (and optionally 3441 a value) from a function back to the caller.</p> 3442 3443<p>There are two forms of the '<tt>ret</tt>' instruction: one that returns a 3444 value and then causes control flow, and one that just causes control flow to 3445 occur.</p> 3446 3447<h5>Arguments:</h5> 3448<p>The '<tt>ret</tt>' instruction optionally accepts a single argument, the 3449 return value. The type of the return value must be a 3450 '<a href="#t_firstclass">first class</a>' type.</p> 3451 3452<p>A function is not <a href="#wellformed">well formed</a> if it it has a 3453 non-void return type and contains a '<tt>ret</tt>' instruction with no return 3454 value or a return value with a type that does not match its type, or if it 3455 has a void return type and contains a '<tt>ret</tt>' instruction with a 3456 return value.</p> 3457 3458<h5>Semantics:</h5> 3459<p>When the '<tt>ret</tt>' instruction is executed, control flow returns back to 3460 the calling function's context. If the caller is a 3461 "<a href="#i_call"><tt>call</tt></a>" instruction, execution continues at the 3462 instruction after the call. If the caller was an 3463 "<a href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues at 3464 the beginning of the "normal" destination block. If the instruction returns 3465 a value, that value shall set the call or invoke instruction's return 3466 value.</p> 3467 3468<h5>Example:</h5> 3469<pre> 3470 ret i32 5 <i>; Return an integer value of 5</i> 3471 ret void <i>; Return from a void function</i> 3472 ret { i32, i8 } { i32 4, i8 2 } <i>; Return a struct of values 4 and 2</i> 3473</pre> 3474 3475</div> 3476<!-- _______________________________________________________________________ --> 3477<h4> 3478 <a name="i_br">'<tt>br</tt>' Instruction</a> 3479</h4> 3480 3481<div> 3482 3483<h5>Syntax:</h5> 3484<pre> 3485 br i1 <cond>, label <iftrue>, label <iffalse> 3486 br label <dest> <i>; Unconditional branch</i> 3487</pre> 3488 3489<h5>Overview:</h5> 3490<p>The '<tt>br</tt>' instruction is used to cause control flow to transfer to a 3491 different basic block in the current function. There are two forms of this 3492 instruction, corresponding to a conditional branch and an unconditional 3493 branch.</p> 3494 3495<h5>Arguments:</h5> 3496<p>The conditional branch form of the '<tt>br</tt>' instruction takes a single 3497 '<tt>i1</tt>' value and two '<tt>label</tt>' values. The unconditional form 3498 of the '<tt>br</tt>' instruction takes a single '<tt>label</tt>' value as a 3499 target.</p> 3500 3501<h5>Semantics:</h5> 3502<p>Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>i1</tt>' 3503 argument is evaluated. If the value is <tt>true</tt>, control flows to the 3504 '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>, 3505 control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p> 3506 3507<h5>Example:</h5> 3508<pre> 3509Test: 3510 %cond = <a href="#i_icmp">icmp</a> eq i32 %a, %b 3511 br i1 %cond, label %IfEqual, label %IfUnequal 3512IfEqual: 3513 <a href="#i_ret">ret</a> i32 1 3514IfUnequal: 3515 <a href="#i_ret">ret</a> i32 0 3516</pre> 3517 3518</div> 3519 3520<!-- _______________________________________________________________________ --> 3521<h4> 3522 <a name="i_switch">'<tt>switch</tt>' Instruction</a> 3523</h4> 3524 3525<div> 3526 3527<h5>Syntax:</h5> 3528<pre> 3529 switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ] 3530</pre> 3531 3532<h5>Overview:</h5> 3533<p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of 3534 several different places. It is a generalization of the '<tt>br</tt>' 3535 instruction, allowing a branch to occur to one of many possible 3536 destinations.</p> 3537 3538<h5>Arguments:</h5> 3539<p>The '<tt>switch</tt>' instruction uses three parameters: an integer 3540 comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination, 3541 and an array of pairs of comparison value constants and '<tt>label</tt>'s. 3542 The table is not allowed to contain duplicate constant entries.</p> 3543 3544<h5>Semantics:</h5> 3545<p>The <tt>switch</tt> instruction specifies a table of values and 3546 destinations. When the '<tt>switch</tt>' instruction is executed, this table 3547 is searched for the given value. If the value is found, control flow is 3548 transferred to the corresponding destination; otherwise, control flow is 3549 transferred to the default destination.</p> 3550 3551<h5>Implementation:</h5> 3552<p>Depending on properties of the target machine and the particular 3553 <tt>switch</tt> instruction, this instruction may be code generated in 3554 different ways. For example, it could be generated as a series of chained 3555 conditional branches or with a lookup table.</p> 3556 3557<h5>Example:</h5> 3558<pre> 3559 <i>; Emulate a conditional br instruction</i> 3560 %Val = <a href="#i_zext">zext</a> i1 %value to i32 3561 switch i32 %Val, label %truedest [ i32 0, label %falsedest ] 3562 3563 <i>; Emulate an unconditional br instruction</i> 3564 switch i32 0, label %dest [ ] 3565 3566 <i>; Implement a jump table:</i> 3567 switch i32 %val, label %otherwise [ i32 0, label %onzero 3568 i32 1, label %onone 3569 i32 2, label %ontwo ] 3570</pre> 3571 3572</div> 3573 3574 3575<!-- _______________________________________________________________________ --> 3576<h4> 3577 <a name="i_indirectbr">'<tt>indirectbr</tt>' Instruction</a> 3578</h4> 3579 3580<div> 3581 3582<h5>Syntax:</h5> 3583<pre> 3584 indirectbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ] 3585</pre> 3586 3587<h5>Overview:</h5> 3588 3589<p>The '<tt>indirectbr</tt>' instruction implements an indirect branch to a label 3590 within the current function, whose address is specified by 3591 "<tt>address</tt>". Address must be derived from a <a 3592 href="#blockaddress">blockaddress</a> constant.</p> 3593 3594<h5>Arguments:</h5> 3595 3596<p>The '<tt>address</tt>' argument is the address of the label to jump to. The 3597 rest of the arguments indicate the full set of possible destinations that the 3598 address may point to. Blocks are allowed to occur multiple times in the 3599 destination list, though this isn't particularly useful.</p> 3600 3601<p>This destination list is required so that dataflow analysis has an accurate 3602 understanding of the CFG.</p> 3603 3604<h5>Semantics:</h5> 3605 3606<p>Control transfers to the block specified in the address argument. All 3607 possible destination blocks must be listed in the label list, otherwise this 3608 instruction has undefined behavior. This implies that jumps to labels 3609 defined in other functions have undefined behavior as well.</p> 3610 3611<h5>Implementation:</h5> 3612 3613<p>This is typically implemented with a jump through a register.</p> 3614 3615<h5>Example:</h5> 3616<pre> 3617 indirectbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ] 3618</pre> 3619 3620</div> 3621 3622 3623<!-- _______________________________________________________________________ --> 3624<h4> 3625 <a name="i_invoke">'<tt>invoke</tt>' Instruction</a> 3626</h4> 3627 3628<div> 3629 3630<h5>Syntax:</h5> 3631<pre> 3632 <result> = invoke [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] <ptr to function ty> <function ptr val>(<function args>) [<a href="#fnattrs">fn attrs</a>] 3633 to label <normal label> unwind label <exception label> 3634</pre> 3635 3636<h5>Overview:</h5> 3637<p>The '<tt>invoke</tt>' instruction causes control to transfer to a specified 3638 function, with the possibility of control flow transfer to either the 3639 '<tt>normal</tt>' label or the '<tt>exception</tt>' label. If the callee 3640 function returns with the "<tt><a href="#i_ret">ret</a></tt>" instruction, 3641 control flow will return to the "normal" label. If the callee (or any 3642 indirect callees) returns via the "<a href="#i_resume"><tt>resume</tt></a>" 3643 instruction or other exception handling mechanism, control is interrupted and 3644 continued at the dynamically nearest "exception" label.</p> 3645 3646<p>The '<tt>exception</tt>' label is a 3647 <i><a href="ExceptionHandling.html#overview">landing pad</a></i> for the 3648 exception. As such, '<tt>exception</tt>' label is required to have the 3649 "<a href="#i_landingpad"><tt>landingpad</tt></a>" instruction, which contains 3650 the information about the behavior of the program after unwinding 3651 happens, as its first non-PHI instruction. The restrictions on the 3652 "<tt>landingpad</tt>" instruction's tightly couples it to the 3653 "<tt>invoke</tt>" instruction, so that the important information contained 3654 within the "<tt>landingpad</tt>" instruction can't be lost through normal 3655 code motion.</p> 3656 3657<h5>Arguments:</h5> 3658<p>This instruction requires several arguments:</p> 3659 3660<ol> 3661 <li>The optional "cconv" marker indicates which <a href="#callingconv">calling 3662 convention</a> the call should use. If none is specified, the call 3663 defaults to using C calling conventions.</li> 3664 3665 <li>The optional <a href="#paramattrs">Parameter Attributes</a> list for 3666 return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>', and 3667 '<tt>inreg</tt>' attributes are valid here.</li> 3668 3669 <li>'<tt>ptr to function ty</tt>': shall be the signature of the pointer to 3670 function value being invoked. In most cases, this is a direct function 3671 invocation, but indirect <tt>invoke</tt>s are just as possible, branching 3672 off an arbitrary pointer to function value.</li> 3673 3674 <li>'<tt>function ptr val</tt>': An LLVM value containing a pointer to a 3675 function to be invoked. </li> 3676 3677 <li>'<tt>function args</tt>': argument list whose types match the function 3678 signature argument types and parameter attributes. All arguments must be 3679 of <a href="#t_firstclass">first class</a> type. If the function 3680 signature indicates the function accepts a variable number of arguments, 3681 the extra arguments can be specified.</li> 3682 3683 <li>'<tt>normal label</tt>': the label reached when the called function 3684 executes a '<tt><a href="#i_ret">ret</a></tt>' instruction. </li> 3685 3686 <li>'<tt>exception label</tt>': the label reached when a callee returns via 3687 the <a href="#i_resume"><tt>resume</tt></a> instruction or other exception 3688 handling mechanism.</li> 3689 3690 <li>The optional <a href="#fnattrs">function attributes</a> list. Only 3691 '<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and 3692 '<tt>readnone</tt>' attributes are valid here.</li> 3693</ol> 3694 3695<h5>Semantics:</h5> 3696<p>This instruction is designed to operate as a standard 3697 '<tt><a href="#i_call">call</a></tt>' instruction in most regards. The 3698 primary difference is that it establishes an association with a label, which 3699 is used by the runtime library to unwind the stack.</p> 3700 3701<p>This instruction is used in languages with destructors to ensure that proper 3702 cleanup is performed in the case of either a <tt>longjmp</tt> or a thrown 3703 exception. Additionally, this is important for implementation of 3704 '<tt>catch</tt>' clauses in high-level languages that support them.</p> 3705 3706<p>For the purposes of the SSA form, the definition of the value returned by the 3707 '<tt>invoke</tt>' instruction is deemed to occur on the edge from the current 3708 block to the "normal" label. If the callee unwinds then no return value is 3709 available.</p> 3710 3711<h5>Example:</h5> 3712<pre> 3713 %retval = invoke i32 @Test(i32 15) to label %Continue 3714 unwind label %TestCleanup <i>; {i32}:retval set</i> 3715 %retval = invoke <a href="#callingconv">coldcc</a> i32 %Testfnptr(i32 15) to label %Continue 3716 unwind label %TestCleanup <i>; {i32}:retval set</i> 3717</pre> 3718 3719</div> 3720 3721 <!-- _______________________________________________________________________ --> 3722 3723<h4> 3724 <a name="i_resume">'<tt>resume</tt>' Instruction</a> 3725</h4> 3726 3727<div> 3728 3729<h5>Syntax:</h5> 3730<pre> 3731 resume <type> <value> 3732</pre> 3733 3734<h5>Overview:</h5> 3735<p>The '<tt>resume</tt>' instruction is a terminator instruction that has no 3736 successors.</p> 3737 3738<h5>Arguments:</h5> 3739<p>The '<tt>resume</tt>' instruction requires one argument, which must have the 3740 same type as the result of any '<tt>landingpad</tt>' instruction in the same 3741 function.</p> 3742 3743<h5>Semantics:</h5> 3744<p>The '<tt>resume</tt>' instruction resumes propagation of an existing 3745 (in-flight) exception whose unwinding was interrupted with 3746 a <a href="#i_landingpad"><tt>landingpad</tt></a> instruction.</p> 3747 3748<h5>Example:</h5> 3749<pre> 3750 resume { i8*, i32 } %exn 3751</pre> 3752 3753</div> 3754 3755<!-- _______________________________________________________________________ --> 3756 3757<h4> 3758 <a name="i_unreachable">'<tt>unreachable</tt>' Instruction</a> 3759</h4> 3760 3761<div> 3762 3763<h5>Syntax:</h5> 3764<pre> 3765 unreachable 3766</pre> 3767 3768<h5>Overview:</h5> 3769<p>The '<tt>unreachable</tt>' instruction has no defined semantics. This 3770 instruction is used to inform the optimizer that a particular portion of the 3771 code is not reachable. This can be used to indicate that the code after a 3772 no-return function cannot be reached, and other facts.</p> 3773 3774<h5>Semantics:</h5> 3775<p>The '<tt>unreachable</tt>' instruction has no defined semantics.</p> 3776 3777</div> 3778 3779</div> 3780 3781<!-- ======================================================================= --> 3782<h3> 3783 <a name="binaryops">Binary Operations</a> 3784</h3> 3785 3786<div> 3787 3788<p>Binary operators are used to do most of the computation in a program. They 3789 require two operands of the same type, execute an operation on them, and 3790 produce a single value. The operands might represent multiple data, as is 3791 the case with the <a href="#t_vector">vector</a> data type. The result value 3792 has the same type as its operands.</p> 3793 3794<p>There are several different binary operators:</p> 3795 3796<!-- _______________________________________________________________________ --> 3797<h4> 3798 <a name="i_add">'<tt>add</tt>' Instruction</a> 3799</h4> 3800 3801<div> 3802 3803<h5>Syntax:</h5> 3804<pre> 3805 <result> = add <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3806 <result> = add nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3807 <result> = add nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3808 <result> = add nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3809</pre> 3810 3811<h5>Overview:</h5> 3812<p>The '<tt>add</tt>' instruction returns the sum of its two operands.</p> 3813 3814<h5>Arguments:</h5> 3815<p>The two arguments to the '<tt>add</tt>' instruction must 3816 be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of 3817 integer values. Both arguments must have identical types.</p> 3818 3819<h5>Semantics:</h5> 3820<p>The value produced is the integer sum of the two operands.</p> 3821 3822<p>If the sum has unsigned overflow, the result returned is the mathematical 3823 result modulo 2<sup>n</sup>, where n is the bit width of the result.</p> 3824 3825<p>Because LLVM integers use a two's complement representation, this instruction 3826 is appropriate for both signed and unsigned integers.</p> 3827 3828<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap" 3829 and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or 3830 <tt>nsw</tt> keywords are present, the result value of the <tt>add</tt> 3831 is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow, 3832 respectively, occurs.</p> 3833 3834<h5>Example:</h5> 3835<pre> 3836 <result> = add i32 4, %var <i>; yields {i32}:result = 4 + %var</i> 3837</pre> 3838 3839</div> 3840 3841<!-- _______________________________________________________________________ --> 3842<h4> 3843 <a name="i_fadd">'<tt>fadd</tt>' Instruction</a> 3844</h4> 3845 3846<div> 3847 3848<h5>Syntax:</h5> 3849<pre> 3850 <result> = fadd <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3851</pre> 3852 3853<h5>Overview:</h5> 3854<p>The '<tt>fadd</tt>' instruction returns the sum of its two operands.</p> 3855 3856<h5>Arguments:</h5> 3857<p>The two arguments to the '<tt>fadd</tt>' instruction must be 3858 <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of 3859 floating point values. Both arguments must have identical types.</p> 3860 3861<h5>Semantics:</h5> 3862<p>The value produced is the floating point sum of the two operands.</p> 3863 3864<h5>Example:</h5> 3865<pre> 3866 <result> = fadd float 4.0, %var <i>; yields {float}:result = 4.0 + %var</i> 3867</pre> 3868 3869</div> 3870 3871<!-- _______________________________________________________________________ --> 3872<h4> 3873 <a name="i_sub">'<tt>sub</tt>' Instruction</a> 3874</h4> 3875 3876<div> 3877 3878<h5>Syntax:</h5> 3879<pre> 3880 <result> = sub <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3881 <result> = sub nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3882 <result> = sub nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3883 <result> = sub nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3884</pre> 3885 3886<h5>Overview:</h5> 3887<p>The '<tt>sub</tt>' instruction returns the difference of its two 3888 operands.</p> 3889 3890<p>Note that the '<tt>sub</tt>' instruction is used to represent the 3891 '<tt>neg</tt>' instruction present in most other intermediate 3892 representations.</p> 3893 3894<h5>Arguments:</h5> 3895<p>The two arguments to the '<tt>sub</tt>' instruction must 3896 be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of 3897 integer values. Both arguments must have identical types.</p> 3898 3899<h5>Semantics:</h5> 3900<p>The value produced is the integer difference of the two operands.</p> 3901 3902<p>If the difference has unsigned overflow, the result returned is the 3903 mathematical result modulo 2<sup>n</sup>, where n is the bit width of the 3904 result.</p> 3905 3906<p>Because LLVM integers use a two's complement representation, this instruction 3907 is appropriate for both signed and unsigned integers.</p> 3908 3909<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap" 3910 and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or 3911 <tt>nsw</tt> keywords are present, the result value of the <tt>sub</tt> 3912 is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow, 3913 respectively, occurs.</p> 3914 3915<h5>Example:</h5> 3916<pre> 3917 <result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i> 3918 <result> = sub i32 0, %val <i>; yields {i32}:result = -%var</i> 3919</pre> 3920 3921</div> 3922 3923<!-- _______________________________________________________________________ --> 3924<h4> 3925 <a name="i_fsub">'<tt>fsub</tt>' Instruction</a> 3926</h4> 3927 3928<div> 3929 3930<h5>Syntax:</h5> 3931<pre> 3932 <result> = fsub <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3933</pre> 3934 3935<h5>Overview:</h5> 3936<p>The '<tt>fsub</tt>' instruction returns the difference of its two 3937 operands.</p> 3938 3939<p>Note that the '<tt>fsub</tt>' instruction is used to represent the 3940 '<tt>fneg</tt>' instruction present in most other intermediate 3941 representations.</p> 3942 3943<h5>Arguments:</h5> 3944<p>The two arguments to the '<tt>fsub</tt>' instruction must be 3945 <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of 3946 floating point values. Both arguments must have identical types.</p> 3947 3948<h5>Semantics:</h5> 3949<p>The value produced is the floating point difference of the two operands.</p> 3950 3951<h5>Example:</h5> 3952<pre> 3953 <result> = fsub float 4.0, %var <i>; yields {float}:result = 4.0 - %var</i> 3954 <result> = fsub float -0.0, %val <i>; yields {float}:result = -%var</i> 3955</pre> 3956 3957</div> 3958 3959<!-- _______________________________________________________________________ --> 3960<h4> 3961 <a name="i_mul">'<tt>mul</tt>' Instruction</a> 3962</h4> 3963 3964<div> 3965 3966<h5>Syntax:</h5> 3967<pre> 3968 <result> = mul <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3969 <result> = mul nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3970 <result> = mul nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3971 <result> = mul nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 3972</pre> 3973 3974<h5>Overview:</h5> 3975<p>The '<tt>mul</tt>' instruction returns the product of its two operands.</p> 3976 3977<h5>Arguments:</h5> 3978<p>The two arguments to the '<tt>mul</tt>' instruction must 3979 be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of 3980 integer values. Both arguments must have identical types.</p> 3981 3982<h5>Semantics:</h5> 3983<p>The value produced is the integer product of the two operands.</p> 3984 3985<p>If the result of the multiplication has unsigned overflow, the result 3986 returned is the mathematical result modulo 2<sup>n</sup>, where n is the bit 3987 width of the result.</p> 3988 3989<p>Because LLVM integers use a two's complement representation, and the result 3990 is the same width as the operands, this instruction returns the correct 3991 result for both signed and unsigned integers. If a full product 3992 (e.g. <tt>i32</tt>x<tt>i32</tt>-><tt>i64</tt>) is needed, the operands should 3993 be sign-extended or zero-extended as appropriate to the width of the full 3994 product.</p> 3995 3996<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap" 3997 and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or 3998 <tt>nsw</tt> keywords are present, the result value of the <tt>mul</tt> 3999 is a <a href="#poisonvalues">poison value</a> if unsigned and/or signed overflow, 4000 respectively, occurs.</p> 4001 4002<h5>Example:</h5> 4003<pre> 4004 <result> = mul i32 4, %var <i>; yields {i32}:result = 4 * %var</i> 4005</pre> 4006 4007</div> 4008 4009<!-- _______________________________________________________________________ --> 4010<h4> 4011 <a name="i_fmul">'<tt>fmul</tt>' Instruction</a> 4012</h4> 4013 4014<div> 4015 4016<h5>Syntax:</h5> 4017<pre> 4018 <result> = fmul <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4019</pre> 4020 4021<h5>Overview:</h5> 4022<p>The '<tt>fmul</tt>' instruction returns the product of its two operands.</p> 4023 4024<h5>Arguments:</h5> 4025<p>The two arguments to the '<tt>fmul</tt>' instruction must be 4026 <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of 4027 floating point values. Both arguments must have identical types.</p> 4028 4029<h5>Semantics:</h5> 4030<p>The value produced is the floating point product of the two operands.</p> 4031 4032<h5>Example:</h5> 4033<pre> 4034 <result> = fmul float 4.0, %var <i>; yields {float}:result = 4.0 * %var</i> 4035</pre> 4036 4037</div> 4038 4039<!-- _______________________________________________________________________ --> 4040<h4> 4041 <a name="i_udiv">'<tt>udiv</tt>' Instruction</a> 4042</h4> 4043 4044<div> 4045 4046<h5>Syntax:</h5> 4047<pre> 4048 <result> = udiv <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4049 <result> = udiv exact <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4050</pre> 4051 4052<h5>Overview:</h5> 4053<p>The '<tt>udiv</tt>' instruction returns the quotient of its two operands.</p> 4054 4055<h5>Arguments:</h5> 4056<p>The two arguments to the '<tt>udiv</tt>' instruction must be 4057 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4058 values. Both arguments must have identical types.</p> 4059 4060<h5>Semantics:</h5> 4061<p>The value produced is the unsigned integer quotient of the two operands.</p> 4062 4063<p>Note that unsigned integer division and signed integer division are distinct 4064 operations; for signed integer division, use '<tt>sdiv</tt>'.</p> 4065 4066<p>Division by zero leads to undefined behavior.</p> 4067 4068<p>If the <tt>exact</tt> keyword is present, the result value of the 4069 <tt>udiv</tt> is a <a href="#poisonvalues">poison value</a> if %op1 is not a 4070 multiple of %op2 (as such, "((a udiv exact b) mul b) == a").</p> 4071 4072 4073<h5>Example:</h5> 4074<pre> 4075 <result> = udiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i> 4076</pre> 4077 4078</div> 4079 4080<!-- _______________________________________________________________________ --> 4081<h4> 4082 <a name="i_sdiv">'<tt>sdiv</tt>' Instruction</a> 4083</h4> 4084 4085<div> 4086 4087<h5>Syntax:</h5> 4088<pre> 4089 <result> = sdiv <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4090 <result> = sdiv exact <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4091</pre> 4092 4093<h5>Overview:</h5> 4094<p>The '<tt>sdiv</tt>' instruction returns the quotient of its two operands.</p> 4095 4096<h5>Arguments:</h5> 4097<p>The two arguments to the '<tt>sdiv</tt>' instruction must be 4098 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4099 values. Both arguments must have identical types.</p> 4100 4101<h5>Semantics:</h5> 4102<p>The value produced is the signed integer quotient of the two operands rounded 4103 towards zero.</p> 4104 4105<p>Note that signed integer division and unsigned integer division are distinct 4106 operations; for unsigned integer division, use '<tt>udiv</tt>'.</p> 4107 4108<p>Division by zero leads to undefined behavior. Overflow also leads to 4109 undefined behavior; this is a rare case, but can occur, for example, by doing 4110 a 32-bit division of -2147483648 by -1.</p> 4111 4112<p>If the <tt>exact</tt> keyword is present, the result value of the 4113 <tt>sdiv</tt> is a <a href="#poisonvalues">poison value</a> if the result would 4114 be rounded.</p> 4115 4116<h5>Example:</h5> 4117<pre> 4118 <result> = sdiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i> 4119</pre> 4120 4121</div> 4122 4123<!-- _______________________________________________________________________ --> 4124<h4> 4125 <a name="i_fdiv">'<tt>fdiv</tt>' Instruction</a> 4126</h4> 4127 4128<div> 4129 4130<h5>Syntax:</h5> 4131<pre> 4132 <result> = fdiv <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4133</pre> 4134 4135<h5>Overview:</h5> 4136<p>The '<tt>fdiv</tt>' instruction returns the quotient of its two operands.</p> 4137 4138<h5>Arguments:</h5> 4139<p>The two arguments to the '<tt>fdiv</tt>' instruction must be 4140 <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of 4141 floating point values. Both arguments must have identical types.</p> 4142 4143<h5>Semantics:</h5> 4144<p>The value produced is the floating point quotient of the two operands.</p> 4145 4146<h5>Example:</h5> 4147<pre> 4148 <result> = fdiv float 4.0, %var <i>; yields {float}:result = 4.0 / %var</i> 4149</pre> 4150 4151</div> 4152 4153<!-- _______________________________________________________________________ --> 4154<h4> 4155 <a name="i_urem">'<tt>urem</tt>' Instruction</a> 4156</h4> 4157 4158<div> 4159 4160<h5>Syntax:</h5> 4161<pre> 4162 <result> = urem <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4163</pre> 4164 4165<h5>Overview:</h5> 4166<p>The '<tt>urem</tt>' instruction returns the remainder from the unsigned 4167 division of its two arguments.</p> 4168 4169<h5>Arguments:</h5> 4170<p>The two arguments to the '<tt>urem</tt>' instruction must be 4171 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4172 values. Both arguments must have identical types.</p> 4173 4174<h5>Semantics:</h5> 4175<p>This instruction returns the unsigned integer <i>remainder</i> of a division. 4176 This instruction always performs an unsigned division to get the 4177 remainder.</p> 4178 4179<p>Note that unsigned integer remainder and signed integer remainder are 4180 distinct operations; for signed integer remainder, use '<tt>srem</tt>'.</p> 4181 4182<p>Taking the remainder of a division by zero leads to undefined behavior.</p> 4183 4184<h5>Example:</h5> 4185<pre> 4186 <result> = urem i32 4, %var <i>; yields {i32}:result = 4 % %var</i> 4187</pre> 4188 4189</div> 4190 4191<!-- _______________________________________________________________________ --> 4192<h4> 4193 <a name="i_srem">'<tt>srem</tt>' Instruction</a> 4194</h4> 4195 4196<div> 4197 4198<h5>Syntax:</h5> 4199<pre> 4200 <result> = srem <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4201</pre> 4202 4203<h5>Overview:</h5> 4204<p>The '<tt>srem</tt>' instruction returns the remainder from the signed 4205 division of its two operands. This instruction can also take 4206 <a href="#t_vector">vector</a> versions of the values in which case the 4207 elements must be integers.</p> 4208 4209<h5>Arguments:</h5> 4210<p>The two arguments to the '<tt>srem</tt>' instruction must be 4211 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4212 values. Both arguments must have identical types.</p> 4213 4214<h5>Semantics:</h5> 4215<p>This instruction returns the <i>remainder</i> of a division (where the result 4216 is either zero or has the same sign as the dividend, <tt>op1</tt>), not the 4217 <i>modulo</i> operator (where the result is either zero or has the same sign 4218 as the divisor, <tt>op2</tt>) of a value. 4219 For more information about the difference, 4220 see <a href="http://mathforum.org/dr.math/problems/anne.4.28.99.html">The 4221 Math Forum</a>. For a table of how this is implemented in various languages, 4222 please see <a href="http://en.wikipedia.org/wiki/Modulo_operation"> 4223 Wikipedia: modulo operation</a>.</p> 4224 4225<p>Note that signed integer remainder and unsigned integer remainder are 4226 distinct operations; for unsigned integer remainder, use '<tt>urem</tt>'.</p> 4227 4228<p>Taking the remainder of a division by zero leads to undefined behavior. 4229 Overflow also leads to undefined behavior; this is a rare case, but can 4230 occur, for example, by taking the remainder of a 32-bit division of 4231 -2147483648 by -1. (The remainder doesn't actually overflow, but this rule 4232 lets srem be implemented using instructions that return both the result of 4233 the division and the remainder.)</p> 4234 4235<h5>Example:</h5> 4236<pre> 4237 <result> = srem i32 4, %var <i>; yields {i32}:result = 4 % %var</i> 4238</pre> 4239 4240</div> 4241 4242<!-- _______________________________________________________________________ --> 4243<h4> 4244 <a name="i_frem">'<tt>frem</tt>' Instruction</a> 4245</h4> 4246 4247<div> 4248 4249<h5>Syntax:</h5> 4250<pre> 4251 <result> = frem <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4252</pre> 4253 4254<h5>Overview:</h5> 4255<p>The '<tt>frem</tt>' instruction returns the remainder from the division of 4256 its two operands.</p> 4257 4258<h5>Arguments:</h5> 4259<p>The two arguments to the '<tt>frem</tt>' instruction must be 4260 <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of 4261 floating point values. Both arguments must have identical types.</p> 4262 4263<h5>Semantics:</h5> 4264<p>This instruction returns the <i>remainder</i> of a division. The remainder 4265 has the same sign as the dividend.</p> 4266 4267<h5>Example:</h5> 4268<pre> 4269 <result> = frem float 4.0, %var <i>; yields {float}:result = 4.0 % %var</i> 4270</pre> 4271 4272</div> 4273 4274</div> 4275 4276<!-- ======================================================================= --> 4277<h3> 4278 <a name="bitwiseops">Bitwise Binary Operations</a> 4279</h3> 4280 4281<div> 4282 4283<p>Bitwise binary operators are used to do various forms of bit-twiddling in a 4284 program. They are generally very efficient instructions and can commonly be 4285 strength reduced from other instructions. They require two operands of the 4286 same type, execute an operation on them, and produce a single value. The 4287 resulting value is the same type as its operands.</p> 4288 4289<!-- _______________________________________________________________________ --> 4290<h4> 4291 <a name="i_shl">'<tt>shl</tt>' Instruction</a> 4292</h4> 4293 4294<div> 4295 4296<h5>Syntax:</h5> 4297<pre> 4298 <result> = shl <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4299 <result> = shl nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4300 <result> = shl nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4301 <result> = shl nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4302</pre> 4303 4304<h5>Overview:</h5> 4305<p>The '<tt>shl</tt>' instruction returns the first operand shifted to the left 4306 a specified number of bits.</p> 4307 4308<h5>Arguments:</h5> 4309<p>Both arguments to the '<tt>shl</tt>' instruction must be the 4310 same <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of 4311 integer type. '<tt>op2</tt>' is treated as an unsigned value.</p> 4312 4313<h5>Semantics:</h5> 4314<p>The value produced is <tt>op1</tt> * 2<sup><tt>op2</tt></sup> mod 4315 2<sup>n</sup>, where <tt>n</tt> is the width of the result. If <tt>op2</tt> 4316 is (statically or dynamically) negative or equal to or larger than the number 4317 of bits in <tt>op1</tt>, the result is undefined. If the arguments are 4318 vectors, each vector element of <tt>op1</tt> is shifted by the corresponding 4319 shift amount in <tt>op2</tt>.</p> 4320 4321<p>If the <tt>nuw</tt> keyword is present, then the shift produces a 4322 <a href="#poisonvalues">poison value</a> if it shifts out any non-zero bits. If 4323 the <tt>nsw</tt> keyword is present, then the shift produces a 4324 <a href="#poisonvalues">poison value</a> if it shifts out any bits that disagree 4325 with the resultant sign bit. As such, NUW/NSW have the same semantics as 4326 they would if the shift were expressed as a mul instruction with the same 4327 nsw/nuw bits in (mul %op1, (shl 1, %op2)).</p> 4328 4329<h5>Example:</h5> 4330<pre> 4331 <result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i> 4332 <result> = shl i32 4, 2 <i>; yields {i32}: 16</i> 4333 <result> = shl i32 1, 10 <i>; yields {i32}: 1024</i> 4334 <result> = shl i32 1, 32 <i>; undefined</i> 4335 <result> = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 2, i32 4></i> 4336</pre> 4337 4338</div> 4339 4340<!-- _______________________________________________________________________ --> 4341<h4> 4342 <a name="i_lshr">'<tt>lshr</tt>' Instruction</a> 4343</h4> 4344 4345<div> 4346 4347<h5>Syntax:</h5> 4348<pre> 4349 <result> = lshr <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4350 <result> = lshr exact <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4351</pre> 4352 4353<h5>Overview:</h5> 4354<p>The '<tt>lshr</tt>' instruction (logical shift right) returns the first 4355 operand shifted to the right a specified number of bits with zero fill.</p> 4356 4357<h5>Arguments:</h5> 4358<p>Both arguments to the '<tt>lshr</tt>' instruction must be the same 4359 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4360 type. '<tt>op2</tt>' is treated as an unsigned value.</p> 4361 4362<h5>Semantics:</h5> 4363<p>This instruction always performs a logical shift right operation. The most 4364 significant bits of the result will be filled with zero bits after the shift. 4365 If <tt>op2</tt> is (statically or dynamically) equal to or larger than the 4366 number of bits in <tt>op1</tt>, the result is undefined. If the arguments are 4367 vectors, each vector element of <tt>op1</tt> is shifted by the corresponding 4368 shift amount in <tt>op2</tt>.</p> 4369 4370<p>If the <tt>exact</tt> keyword is present, the result value of the 4371 <tt>lshr</tt> is a <a href="#poisonvalues">poison value</a> if any of the bits 4372 shifted out are non-zero.</p> 4373 4374 4375<h5>Example:</h5> 4376<pre> 4377 <result> = lshr i32 4, 1 <i>; yields {i32}:result = 2</i> 4378 <result> = lshr i32 4, 2 <i>; yields {i32}:result = 1</i> 4379 <result> = lshr i8 4, 3 <i>; yields {i8}:result = 0</i> 4380 <result> = lshr i8 -2, 1 <i>; yields {i8}:result = 0x7FFFFFFF </i> 4381 <result> = lshr i32 1, 32 <i>; undefined</i> 4382 <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1></i> 4383</pre> 4384 4385</div> 4386 4387<!-- _______________________________________________________________________ --> 4388<h4> 4389 <a name="i_ashr">'<tt>ashr</tt>' Instruction</a> 4390</h4> 4391 4392<div> 4393 4394<h5>Syntax:</h5> 4395<pre> 4396 <result> = ashr <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4397 <result> = ashr exact <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4398</pre> 4399 4400<h5>Overview:</h5> 4401<p>The '<tt>ashr</tt>' instruction (arithmetic shift right) returns the first 4402 operand shifted to the right a specified number of bits with sign 4403 extension.</p> 4404 4405<h5>Arguments:</h5> 4406<p>Both arguments to the '<tt>ashr</tt>' instruction must be the same 4407 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4408 type. '<tt>op2</tt>' is treated as an unsigned value.</p> 4409 4410<h5>Semantics:</h5> 4411<p>This instruction always performs an arithmetic shift right operation, The 4412 most significant bits of the result will be filled with the sign bit 4413 of <tt>op1</tt>. If <tt>op2</tt> is (statically or dynamically) equal to or 4414 larger than the number of bits in <tt>op1</tt>, the result is undefined. If 4415 the arguments are vectors, each vector element of <tt>op1</tt> is shifted by 4416 the corresponding shift amount in <tt>op2</tt>.</p> 4417 4418<p>If the <tt>exact</tt> keyword is present, the result value of the 4419 <tt>ashr</tt> is a <a href="#poisonvalues">poison value</a> if any of the bits 4420 shifted out are non-zero.</p> 4421 4422<h5>Example:</h5> 4423<pre> 4424 <result> = ashr i32 4, 1 <i>; yields {i32}:result = 2</i> 4425 <result> = ashr i32 4, 2 <i>; yields {i32}:result = 1</i> 4426 <result> = ashr i8 4, 3 <i>; yields {i8}:result = 0</i> 4427 <result> = ashr i8 -2, 1 <i>; yields {i8}:result = -1</i> 4428 <result> = ashr i32 1, 32 <i>; undefined</i> 4429 <result> = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3> <i>; yields: result=<2 x i32> < i32 -1, i32 0></i> 4430</pre> 4431 4432</div> 4433 4434<!-- _______________________________________________________________________ --> 4435<h4> 4436 <a name="i_and">'<tt>and</tt>' Instruction</a> 4437</h4> 4438 4439<div> 4440 4441<h5>Syntax:</h5> 4442<pre> 4443 <result> = and <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4444</pre> 4445 4446<h5>Overview:</h5> 4447<p>The '<tt>and</tt>' instruction returns the bitwise logical and of its two 4448 operands.</p> 4449 4450<h5>Arguments:</h5> 4451<p>The two arguments to the '<tt>and</tt>' instruction must be 4452 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4453 values. Both arguments must have identical types.</p> 4454 4455<h5>Semantics:</h5> 4456<p>The truth table used for the '<tt>and</tt>' instruction is:</p> 4457 4458<table border="1" cellspacing="0" cellpadding="4"> 4459 <tbody> 4460 <tr> 4461 <th>In0</th> 4462 <th>In1</th> 4463 <th>Out</th> 4464 </tr> 4465 <tr> 4466 <td>0</td> 4467 <td>0</td> 4468 <td>0</td> 4469 </tr> 4470 <tr> 4471 <td>0</td> 4472 <td>1</td> 4473 <td>0</td> 4474 </tr> 4475 <tr> 4476 <td>1</td> 4477 <td>0</td> 4478 <td>0</td> 4479 </tr> 4480 <tr> 4481 <td>1</td> 4482 <td>1</td> 4483 <td>1</td> 4484 </tr> 4485 </tbody> 4486</table> 4487 4488<h5>Example:</h5> 4489<pre> 4490 <result> = and i32 4, %var <i>; yields {i32}:result = 4 & %var</i> 4491 <result> = and i32 15, 40 <i>; yields {i32}:result = 8</i> 4492 <result> = and i32 4, 8 <i>; yields {i32}:result = 0</i> 4493</pre> 4494</div> 4495<!-- _______________________________________________________________________ --> 4496<h4> 4497 <a name="i_or">'<tt>or</tt>' Instruction</a> 4498</h4> 4499 4500<div> 4501 4502<h5>Syntax:</h5> 4503<pre> 4504 <result> = or <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4505</pre> 4506 4507<h5>Overview:</h5> 4508<p>The '<tt>or</tt>' instruction returns the bitwise logical inclusive or of its 4509 two operands.</p> 4510 4511<h5>Arguments:</h5> 4512<p>The two arguments to the '<tt>or</tt>' instruction must be 4513 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4514 values. Both arguments must have identical types.</p> 4515 4516<h5>Semantics:</h5> 4517<p>The truth table used for the '<tt>or</tt>' instruction is:</p> 4518 4519<table border="1" cellspacing="0" cellpadding="4"> 4520 <tbody> 4521 <tr> 4522 <th>In0</th> 4523 <th>In1</th> 4524 <th>Out</th> 4525 </tr> 4526 <tr> 4527 <td>0</td> 4528 <td>0</td> 4529 <td>0</td> 4530 </tr> 4531 <tr> 4532 <td>0</td> 4533 <td>1</td> 4534 <td>1</td> 4535 </tr> 4536 <tr> 4537 <td>1</td> 4538 <td>0</td> 4539 <td>1</td> 4540 </tr> 4541 <tr> 4542 <td>1</td> 4543 <td>1</td> 4544 <td>1</td> 4545 </tr> 4546 </tbody> 4547</table> 4548 4549<h5>Example:</h5> 4550<pre> 4551 <result> = or i32 4, %var <i>; yields {i32}:result = 4 | %var</i> 4552 <result> = or i32 15, 40 <i>; yields {i32}:result = 47</i> 4553 <result> = or i32 4, 8 <i>; yields {i32}:result = 12</i> 4554</pre> 4555 4556</div> 4557 4558<!-- _______________________________________________________________________ --> 4559<h4> 4560 <a name="i_xor">'<tt>xor</tt>' Instruction</a> 4561</h4> 4562 4563<div> 4564 4565<h5>Syntax:</h5> 4566<pre> 4567 <result> = xor <ty> <op1>, <op2> <i>; yields {ty}:result</i> 4568</pre> 4569 4570<h5>Overview:</h5> 4571<p>The '<tt>xor</tt>' instruction returns the bitwise logical exclusive or of 4572 its two operands. The <tt>xor</tt> is used to implement the "one's 4573 complement" operation, which is the "~" operator in C.</p> 4574 4575<h5>Arguments:</h5> 4576<p>The two arguments to the '<tt>xor</tt>' instruction must be 4577 <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer 4578 values. Both arguments must have identical types.</p> 4579 4580<h5>Semantics:</h5> 4581<p>The truth table used for the '<tt>xor</tt>' instruction is:</p> 4582 4583<table border="1" cellspacing="0" cellpadding="4"> 4584 <tbody> 4585 <tr> 4586 <th>In0</th> 4587 <th>In1</th> 4588 <th>Out</th> 4589 </tr> 4590 <tr> 4591 <td>0</td> 4592 <td>0</td> 4593 <td>0</td> 4594 </tr> 4595 <tr> 4596 <td>0</td> 4597 <td>1</td> 4598 <td>1</td> 4599 </tr> 4600 <tr> 4601 <td>1</td> 4602 <td>0</td> 4603 <td>1</td> 4604 </tr> 4605 <tr> 4606 <td>1</td> 4607 <td>1</td> 4608 <td>0</td> 4609 </tr> 4610 </tbody> 4611</table> 4612 4613<h5>Example:</h5> 4614<pre> 4615 <result> = xor i32 4, %var <i>; yields {i32}:result = 4 ^ %var</i> 4616 <result> = xor i32 15, 40 <i>; yields {i32}:result = 39</i> 4617 <result> = xor i32 4, 8 <i>; yields {i32}:result = 12</i> 4618 <result> = xor i32 %V, -1 <i>; yields {i32}:result = ~%V</i> 4619</pre> 4620 4621</div> 4622 4623</div> 4624 4625<!-- ======================================================================= --> 4626<h3> 4627 <a name="vectorops">Vector Operations</a> 4628</h3> 4629 4630<div> 4631 4632<p>LLVM supports several instructions to represent vector operations in a 4633 target-independent manner. These instructions cover the element-access and 4634 vector-specific operations needed to process vectors effectively. While LLVM 4635 does directly support these vector operations, many sophisticated algorithms 4636 will want to use target-specific intrinsics to take full advantage of a 4637 specific target.</p> 4638 4639<!-- _______________________________________________________________________ --> 4640<h4> 4641 <a name="i_extractelement">'<tt>extractelement</tt>' Instruction</a> 4642</h4> 4643 4644<div> 4645 4646<h5>Syntax:</h5> 4647<pre> 4648 <result> = extractelement <n x <ty>> <val>, i32 <idx> <i>; yields <ty></i> 4649</pre> 4650 4651<h5>Overview:</h5> 4652<p>The '<tt>extractelement</tt>' instruction extracts a single scalar element 4653 from a vector at a specified index.</p> 4654 4655 4656<h5>Arguments:</h5> 4657<p>The first operand of an '<tt>extractelement</tt>' instruction is a value 4658 of <a href="#t_vector">vector</a> type. The second operand is an index 4659 indicating the position from which to extract the element. The index may be 4660 a variable.</p> 4661 4662<h5>Semantics:</h5> 4663<p>The result is a scalar of the same type as the element type of 4664 <tt>val</tt>. Its value is the value at position <tt>idx</tt> of 4665 <tt>val</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the 4666 results are undefined.</p> 4667 4668<h5>Example:</h5> 4669<pre> 4670 <result> = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i> 4671</pre> 4672 4673</div> 4674 4675<!-- _______________________________________________________________________ --> 4676<h4> 4677 <a name="i_insertelement">'<tt>insertelement</tt>' Instruction</a> 4678</h4> 4679 4680<div> 4681 4682<h5>Syntax:</h5> 4683<pre> 4684 <result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx> <i>; yields <n x <ty>></i> 4685</pre> 4686 4687<h5>Overview:</h5> 4688<p>The '<tt>insertelement</tt>' instruction inserts a scalar element into a 4689 vector at a specified index.</p> 4690 4691<h5>Arguments:</h5> 4692<p>The first operand of an '<tt>insertelement</tt>' instruction is a value 4693 of <a href="#t_vector">vector</a> type. The second operand is a scalar value 4694 whose type must equal the element type of the first operand. The third 4695 operand is an index indicating the position at which to insert the value. 4696 The index may be a variable.</p> 4697 4698<h5>Semantics:</h5> 4699<p>The result is a vector of the same type as <tt>val</tt>. Its element values 4700 are those of <tt>val</tt> except at position <tt>idx</tt>, where it gets the 4701 value <tt>elt</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the 4702 results are undefined.</p> 4703 4704<h5>Example:</h5> 4705<pre> 4706 <result> = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i> 4707</pre> 4708 4709</div> 4710 4711<!-- _______________________________________________________________________ --> 4712<h4> 4713 <a name="i_shufflevector">'<tt>shufflevector</tt>' Instruction</a> 4714</h4> 4715 4716<div> 4717 4718<h5>Syntax:</h5> 4719<pre> 4720 <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask> <i>; yields <m x <ty>></i> 4721</pre> 4722 4723<h5>Overview:</h5> 4724<p>The '<tt>shufflevector</tt>' instruction constructs a permutation of elements 4725 from two input vectors, returning a vector with the same element type as the 4726 input and length that is the same as the shuffle mask.</p> 4727 4728<h5>Arguments:</h5> 4729<p>The first two operands of a '<tt>shufflevector</tt>' instruction are vectors 4730 with types that match each other. The third argument is a shuffle mask whose 4731 element type is always 'i32'. The result of the instruction is a vector 4732 whose length is the same as the shuffle mask and whose element type is the 4733 same as the element type of the first two operands.</p> 4734 4735<p>The shuffle mask operand is required to be a constant vector with either 4736 constant integer or undef values.</p> 4737 4738<h5>Semantics:</h5> 4739<p>The elements of the two input vectors are numbered from left to right across 4740 both of the vectors. The shuffle mask operand specifies, for each element of 4741 the result vector, which element of the two input vectors the result element 4742 gets. The element selector may be undef (meaning "don't care") and the 4743 second operand may be undef if performing a shuffle from only one vector.</p> 4744 4745<h5>Example:</h5> 4746<pre> 4747 <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, 4748 <4 x i32> <i32 0, i32 4, i32 1, i32 5> <i>; yields <4 x i32></i> 4749 <result> = shufflevector <4 x i32> %v1, <4 x i32> undef, 4750 <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle. 4751 <result> = shufflevector <8 x i32> %v1, <8 x i32> undef, 4752 <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> 4753 <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2, 4754 <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > <i>; yields <8 x i32></i> 4755</pre> 4756 4757</div> 4758 4759</div> 4760 4761<!-- ======================================================================= --> 4762<h3> 4763 <a name="aggregateops">Aggregate Operations</a> 4764</h3> 4765 4766<div> 4767 4768<p>LLVM supports several instructions for working with 4769 <a href="#t_aggregate">aggregate</a> values.</p> 4770 4771<!-- _______________________________________________________________________ --> 4772<h4> 4773 <a name="i_extractvalue">'<tt>extractvalue</tt>' Instruction</a> 4774</h4> 4775 4776<div> 4777 4778<h5>Syntax:</h5> 4779<pre> 4780 <result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}* 4781</pre> 4782 4783<h5>Overview:</h5> 4784<p>The '<tt>extractvalue</tt>' instruction extracts the value of a member field 4785 from an <a href="#t_aggregate">aggregate</a> value.</p> 4786 4787<h5>Arguments:</h5> 4788<p>The first operand of an '<tt>extractvalue</tt>' instruction is a value 4789 of <a href="#t_struct">struct</a> or 4790 <a href="#t_array">array</a> type. The operands are constant indices to 4791 specify which value to extract in a similar manner as indices in a 4792 '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.</p> 4793 <p>The major differences to <tt>getelementptr</tt> indexing are:</p> 4794 <ul> 4795 <li>Since the value being indexed is not a pointer, the first index is 4796 omitted and assumed to be zero.</li> 4797 <li>At least one index must be specified.</li> 4798 <li>Not only struct indices but also array indices must be in 4799 bounds.</li> 4800 </ul> 4801 4802<h5>Semantics:</h5> 4803<p>The result is the value at the position in the aggregate specified by the 4804 index operands.</p> 4805 4806<h5>Example:</h5> 4807<pre> 4808 <result> = extractvalue {i32, float} %agg, 0 <i>; yields i32</i> 4809</pre> 4810 4811</div> 4812 4813<!-- _______________________________________________________________________ --> 4814<h4> 4815 <a name="i_insertvalue">'<tt>insertvalue</tt>' Instruction</a> 4816</h4> 4817 4818<div> 4819 4820<h5>Syntax:</h5> 4821<pre> 4822 <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx>{, <idx>}* <i>; yields <aggregate type></i> 4823</pre> 4824 4825<h5>Overview:</h5> 4826<p>The '<tt>insertvalue</tt>' instruction inserts a value into a member field 4827 in an <a href="#t_aggregate">aggregate</a> value.</p> 4828 4829<h5>Arguments:</h5> 4830<p>The first operand of an '<tt>insertvalue</tt>' instruction is a value 4831 of <a href="#t_struct">struct</a> or 4832 <a href="#t_array">array</a> type. The second operand is a first-class 4833 value to insert. The following operands are constant indices indicating 4834 the position at which to insert the value in a similar manner as indices in a 4835 '<tt><a href="#i_extractvalue">extractvalue</a></tt>' instruction. The 4836 value to insert must have the same type as the value identified by the 4837 indices.</p> 4838 4839<h5>Semantics:</h5> 4840<p>The result is an aggregate of the same type as <tt>val</tt>. Its value is 4841 that of <tt>val</tt> except that the value at the position specified by the 4842 indices is that of <tt>elt</tt>.</p> 4843 4844<h5>Example:</h5> 4845<pre> 4846 %agg1 = insertvalue {i32, float} undef, i32 1, 0 <i>; yields {i32 1, float undef}</i> 4847 %agg2 = insertvalue {i32, float} %agg1, float %val, 1 <i>; yields {i32 1, float %val}</i> 4848 %agg3 = insertvalue {i32, {float}} %agg1, float %val, 1, 0 <i>; yields {i32 1, float %val}</i> 4849</pre> 4850 4851</div> 4852 4853</div> 4854 4855<!-- ======================================================================= --> 4856<h3> 4857 <a name="memoryops">Memory Access and Addressing Operations</a> 4858</h3> 4859 4860<div> 4861 4862<p>A key design point of an SSA-based representation is how it represents 4863 memory. In LLVM, no memory locations are in SSA form, which makes things 4864 very simple. This section describes how to read, write, and allocate 4865 memory in LLVM.</p> 4866 4867<!-- _______________________________________________________________________ --> 4868<h4> 4869 <a name="i_alloca">'<tt>alloca</tt>' Instruction</a> 4870</h4> 4871 4872<div> 4873 4874<h5>Syntax:</h5> 4875<pre> 4876 <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] <i>; yields {type*}:result</i> 4877</pre> 4878 4879<h5>Overview:</h5> 4880<p>The '<tt>alloca</tt>' instruction allocates memory on the stack frame of the 4881 currently executing function, to be automatically released when this function 4882 returns to its caller. The object is always allocated in the generic address 4883 space (address space zero).</p> 4884 4885<h5>Arguments:</h5> 4886<p>The '<tt>alloca</tt>' instruction 4887 allocates <tt>sizeof(<type>)*NumElements</tt> bytes of memory on the 4888 runtime stack, returning a pointer of the appropriate type to the program. 4889 If "NumElements" is specified, it is the number of elements allocated, 4890 otherwise "NumElements" is defaulted to be one. If a constant alignment is 4891 specified, the value result of the allocation is guaranteed to be aligned to 4892 at least that boundary. If not specified, or if zero, the target can choose 4893 to align the allocation on any convenient boundary compatible with the 4894 type.</p> 4895 4896<p>'<tt>type</tt>' may be any sized type.</p> 4897 4898<h5>Semantics:</h5> 4899<p>Memory is allocated; a pointer is returned. The operation is undefined if 4900 there is insufficient stack space for the allocation. '<tt>alloca</tt>'d 4901 memory is automatically released when the function returns. The 4902 '<tt>alloca</tt>' instruction is commonly used to represent automatic 4903 variables that must have an address available. When the function returns 4904 (either with the <tt><a href="#i_ret">ret</a></tt> 4905 or <tt><a href="#i_resume">resume</a></tt> instructions), the memory is 4906 reclaimed. Allocating zero bytes is legal, but the result is undefined. 4907 The order in which memory is allocated (ie., which way the stack grows) is 4908 not specified.</p> 4909 4910<p> 4911 4912<h5>Example:</h5> 4913<pre> 4914 %ptr = alloca i32 <i>; yields {i32*}:ptr</i> 4915 %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i> 4916 %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i> 4917 %ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i> 4918</pre> 4919 4920</div> 4921 4922<!-- _______________________________________________________________________ --> 4923<h4> 4924 <a name="i_load">'<tt>load</tt>' Instruction</a> 4925</h4> 4926 4927<div> 4928 4929<h5>Syntax:</h5> 4930<pre> 4931 <result> = load [volatile] <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>][, !invariant.load !<index>] 4932 <result> = load atomic [volatile] <ty>* <pointer> [singlethread] <ordering>, align <alignment> 4933 !<index> = !{ i32 1 } 4934</pre> 4935 4936<h5>Overview:</h5> 4937<p>The '<tt>load</tt>' instruction is used to read from memory.</p> 4938 4939<h5>Arguments:</h5> 4940<p>The argument to the '<tt>load</tt>' instruction specifies the memory address 4941 from which to load. The pointer must point to 4942 a <a href="#t_firstclass">first class</a> type. If the <tt>load</tt> is 4943 marked as <tt>volatile</tt>, then the optimizer is not allowed to modify the 4944 number or order of execution of this <tt>load</tt> with other <a 4945 href="#volatile">volatile operations</a>.</p> 4946 4947<p>If the <code>load</code> is marked as <code>atomic</code>, it takes an extra 4948 <a href="#ordering">ordering</a> and optional <code>singlethread</code> 4949 argument. The <code>release</code> and <code>acq_rel</code> orderings are 4950 not valid on <code>load</code> instructions. Atomic loads produce <a 4951 href="#memorymodel">defined</a> results when they may see multiple atomic 4952 stores. The type of the pointee must be an integer type whose bit width 4953 is a power of two greater than or equal to eight and less than or equal 4954 to a target-specific size limit. <code>align</code> must be explicitly 4955 specified on atomic loads, and the load has undefined behavior if the 4956 alignment is not set to a value which is at least the size in bytes of 4957 the pointee. <code>!nontemporal</code> does not have any defined semantics 4958 for atomic loads.</p> 4959 4960<p>The optional constant <tt>align</tt> argument specifies the alignment of the 4961 operation (that is, the alignment of the memory address). A value of 0 or an 4962 omitted <tt>align</tt> argument means that the operation has the preferential 4963 alignment for the target. It is the responsibility of the code emitter to 4964 ensure that the alignment information is correct. Overestimating the 4965 alignment results in undefined behavior. Underestimating the alignment may 4966 produce less efficient code. An alignment of 1 is always safe.</p> 4967 4968<p>The optional <tt>!nontemporal</tt> metadata must reference a single 4969 metatadata name <index> corresponding to a metadata node with 4970 one <tt>i32</tt> entry of value 1. The existence of 4971 the <tt>!nontemporal</tt> metatadata on the instruction tells the optimizer 4972 and code generator that this load is not expected to be reused in the cache. 4973 The code generator may select special instructions to save cache bandwidth, 4974 such as the <tt>MOVNT</tt> instruction on x86.</p> 4975 4976<p>The optional <tt>!invariant.load</tt> metadata must reference a single 4977 metatadata name <index> corresponding to a metadata node with no 4978 entries. The existence of the <tt>!invariant.load</tt> metatadata on the 4979 instruction tells the optimizer and code generator that this load address 4980 points to memory which does not change value during program execution. 4981 The optimizer may then move this load around, for example, by hoisting it 4982 out of loops using loop invariant code motion.</p> 4983 4984<h5>Semantics:</h5> 4985<p>The location of memory pointed to is loaded. If the value being loaded is of 4986 scalar type then the number of bytes read does not exceed the minimum number 4987 of bytes needed to hold all bits of the type. For example, loading an 4988 <tt>i24</tt> reads at most three bytes. When loading a value of a type like 4989 <tt>i20</tt> with a size that is not an integral number of bytes, the result 4990 is undefined if the value was not originally written using a store of the 4991 same type.</p> 4992 4993<h5>Examples:</h5> 4994<pre> 4995 %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i> 4996 <a href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i> 4997 %val = load i32* %ptr <i>; yields {i32}:val = i32 3</i> 4998</pre> 4999 5000</div> 5001 5002<!-- _______________________________________________________________________ --> 5003<h4> 5004 <a name="i_store">'<tt>store</tt>' Instruction</a> 5005</h4> 5006 5007<div> 5008 5009<h5>Syntax:</h5> 5010<pre> 5011 store [volatile] <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i> 5012 store atomic [volatile] <ty> <value>, <ty>* <pointer> [singlethread] <ordering>, align <alignment> <i>; yields {void}</i> 5013</pre> 5014 5015<h5>Overview:</h5> 5016<p>The '<tt>store</tt>' instruction is used to write to memory.</p> 5017 5018<h5>Arguments:</h5> 5019<p>There are two arguments to the '<tt>store</tt>' instruction: a value to store 5020 and an address at which to store it. The type of the 5021 '<tt><pointer></tt>' operand must be a pointer to 5022 the <a href="#t_firstclass">first class</a> type of the 5023 '<tt><value></tt>' operand. If the <tt>store</tt> is marked as 5024 <tt>volatile</tt>, then the optimizer is not allowed to modify the number or 5025 order of execution of this <tt>store</tt> with other <a 5026 href="#volatile">volatile operations</a>.</p> 5027 5028<p>If the <code>store</code> is marked as <code>atomic</code>, it takes an extra 5029 <a href="#ordering">ordering</a> and optional <code>singlethread</code> 5030 argument. The <code>acquire</code> and <code>acq_rel</code> orderings aren't 5031 valid on <code>store</code> instructions. Atomic loads produce <a 5032 href="#memorymodel">defined</a> results when they may see multiple atomic 5033 stores. The type of the pointee must be an integer type whose bit width 5034 is a power of two greater than or equal to eight and less than or equal 5035 to a target-specific size limit. <code>align</code> must be explicitly 5036 specified on atomic stores, and the store has undefined behavior if the 5037 alignment is not set to a value which is at least the size in bytes of 5038 the pointee. <code>!nontemporal</code> does not have any defined semantics 5039 for atomic stores.</p> 5040 5041<p>The optional constant "align" argument specifies the alignment of the 5042 operation (that is, the alignment of the memory address). A value of 0 or an 5043 omitted "align" argument means that the operation has the preferential 5044 alignment for the target. It is the responsibility of the code emitter to 5045 ensure that the alignment information is correct. Overestimating the 5046 alignment results in an undefined behavior. Underestimating the alignment may 5047 produce less efficient code. An alignment of 1 is always safe.</p> 5048 5049<p>The optional !nontemporal metadata must reference a single metatadata 5050 name <index> corresponding to a metadata node with one i32 entry of 5051 value 1. The existence of the !nontemporal metatadata on the 5052 instruction tells the optimizer and code generator that this load is 5053 not expected to be reused in the cache. The code generator may 5054 select special instructions to save cache bandwidth, such as the 5055 MOVNT instruction on x86.</p> 5056 5057 5058<h5>Semantics:</h5> 5059<p>The contents of memory are updated to contain '<tt><value></tt>' at the 5060 location specified by the '<tt><pointer></tt>' operand. If 5061 '<tt><value></tt>' is of scalar type then the number of bytes written 5062 does not exceed the minimum number of bytes needed to hold all bits of the 5063 type. For example, storing an <tt>i24</tt> writes at most three bytes. When 5064 writing a value of a type like <tt>i20</tt> with a size that is not an 5065 integral number of bytes, it is unspecified what happens to the extra bits 5066 that do not belong to the type, but they will typically be overwritten.</p> 5067 5068<h5>Example:</h5> 5069<pre> 5070 %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i> 5071 store i32 3, i32* %ptr <i>; yields {void}</i> 5072 %val = <a href="#i_load">load</a> i32* %ptr <i>; yields {i32}:val = i32 3</i> 5073</pre> 5074 5075</div> 5076 5077<!-- _______________________________________________________________________ --> 5078<h4> 5079<a name="i_fence">'<tt>fence</tt>' Instruction</a> 5080</h4> 5081 5082<div> 5083 5084<h5>Syntax:</h5> 5085<pre> 5086 fence [singlethread] <ordering> <i>; yields {void}</i> 5087</pre> 5088 5089<h5>Overview:</h5> 5090<p>The '<tt>fence</tt>' instruction is used to introduce happens-before edges 5091between operations.</p> 5092 5093<h5>Arguments:</h5> <p>'<code>fence</code>' instructions take an <a 5094href="#ordering">ordering</a> argument which defines what 5095<i>synchronizes-with</i> edges they add. They can only be given 5096<code>acquire</code>, <code>release</code>, <code>acq_rel</code>, and 5097<code>seq_cst</code> orderings.</p> 5098 5099<h5>Semantics:</h5> 5100<p>A fence <var>A</var> which has (at least) <code>release</code> ordering 5101semantics <i>synchronizes with</i> a fence <var>B</var> with (at least) 5102<code>acquire</code> ordering semantics if and only if there exist atomic 5103operations <var>X</var> and <var>Y</var>, both operating on some atomic object 5104<var>M</var>, such that <var>A</var> is sequenced before <var>X</var>, 5105<var>X</var> modifies <var>M</var> (either directly or through some side effect 5106of a sequence headed by <var>X</var>), <var>Y</var> is sequenced before 5107<var>B</var>, and <var>Y</var> observes <var>M</var>. This provides a 5108<i>happens-before</i> dependency between <var>A</var> and <var>B</var>. Rather 5109than an explicit <code>fence</code>, one (but not both) of the atomic operations 5110<var>X</var> or <var>Y</var> might provide a <code>release</code> or 5111<code>acquire</code> (resp.) ordering constraint and still 5112<i>synchronize-with</i> the explicit <code>fence</code> and establish the 5113<i>happens-before</i> edge.</p> 5114 5115<p>A <code>fence</code> which has <code>seq_cst</code> ordering, in addition to 5116having both <code>acquire</code> and <code>release</code> semantics specified 5117above, participates in the global program order of other <code>seq_cst</code> 5118operations and/or fences.</p> 5119 5120<p>The optional "<a href="#singlethread"><code>singlethread</code></a>" argument 5121specifies that the fence only synchronizes with other fences in the same 5122thread. (This is useful for interacting with signal handlers.)</p> 5123 5124<h5>Example:</h5> 5125<pre> 5126 fence acquire <i>; yields {void}</i> 5127 fence singlethread seq_cst <i>; yields {void}</i> 5128</pre> 5129 5130</div> 5131 5132<!-- _______________________________________________________________________ --> 5133<h4> 5134<a name="i_cmpxchg">'<tt>cmpxchg</tt>' Instruction</a> 5135</h4> 5136 5137<div> 5138 5139<h5>Syntax:</h5> 5140<pre> 5141 cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <ordering> <i>; yields {ty}</i> 5142</pre> 5143 5144<h5>Overview:</h5> 5145<p>The '<tt>cmpxchg</tt>' instruction is used to atomically modify memory. 5146It loads a value in memory and compares it to a given value. If they are 5147equal, it stores a new value into the memory.</p> 5148 5149<h5>Arguments:</h5> 5150<p>There are three arguments to the '<code>cmpxchg</code>' instruction: an 5151address to operate on, a value to compare to the value currently be at that 5152address, and a new value to place at that address if the compared values are 5153equal. The type of '<var><cmp></var>' must be an integer type whose 5154bit width is a power of two greater than or equal to eight and less than 5155or equal to a target-specific size limit. '<var><cmp></var>' and 5156'<var><new></var>' must have the same type, and the type of 5157'<var><pointer></var>' must be a pointer to that type. If the 5158<code>cmpxchg</code> is marked as <code>volatile</code>, then the 5159optimizer is not allowed to modify the number or order of execution 5160of this <code>cmpxchg</code> with other <a href="#volatile">volatile 5161operations</a>.</p> 5162 5163<!-- FIXME: Extend allowed types. --> 5164 5165<p>The <a href="#ordering"><var>ordering</var></a> argument specifies how this 5166<code>cmpxchg</code> synchronizes with other atomic operations.</p> 5167 5168<p>The optional "<code>singlethread</code>" argument declares that the 5169<code>cmpxchg</code> is only atomic with respect to code (usually signal 5170handlers) running in the same thread as the <code>cmpxchg</code>. Otherwise the 5171cmpxchg is atomic with respect to all other code in the system.</p> 5172 5173<p>The pointer passed into cmpxchg must have alignment greater than or equal to 5174the size in memory of the operand. 5175 5176<h5>Semantics:</h5> 5177<p>The contents of memory at the location specified by the 5178'<tt><pointer></tt>' operand is read and compared to 5179'<tt><cmp></tt>'; if the read value is the equal, 5180'<tt><new></tt>' is written. The original value at the location 5181is returned. 5182 5183<p>A successful <code>cmpxchg</code> is a read-modify-write instruction for the 5184purpose of identifying <a href="#release_sequence">release sequences</a>. A 5185failed <code>cmpxchg</code> is equivalent to an atomic load with an ordering 5186parameter determined by dropping any <code>release</code> part of the 5187<code>cmpxchg</code>'s ordering.</p> 5188 5189<!-- 5190FIXME: Is compare_exchange_weak() necessary? (Consider after we've done 5191optimization work on ARM.) 5192 5193FIXME: Is a weaker ordering constraint on failure helpful in practice? 5194--> 5195 5196<h5>Example:</h5> 5197<pre> 5198entry: 5199 %orig = atomic <a href="#i_load">load</a> i32* %ptr unordered <i>; yields {i32}</i> 5200 <a href="#i_br">br</a> label %loop 5201 5202loop: 5203 %cmp = <a href="#i_phi">phi</a> i32 [ %orig, %entry ], [%old, %loop] 5204 %squared = <a href="#i_mul">mul</a> i32 %cmp, %cmp 5205 %old = cmpxchg i32* %ptr, i32 %cmp, i32 %squared <i>; yields {i32}</i> 5206 %success = <a href="#i_icmp">icmp</a> eq i32 %cmp, %old 5207 <a href="#i_br">br</a> i1 %success, label %done, label %loop 5208 5209done: 5210 ... 5211</pre> 5212 5213</div> 5214 5215<!-- _______________________________________________________________________ --> 5216<h4> 5217<a name="i_atomicrmw">'<tt>atomicrmw</tt>' Instruction</a> 5218</h4> 5219 5220<div> 5221 5222<h5>Syntax:</h5> 5223<pre> 5224 atomicrmw [volatile] <operation> <ty>* <pointer>, <ty> <value> [singlethread] <ordering> <i>; yields {ty}</i> 5225</pre> 5226 5227<h5>Overview:</h5> 5228<p>The '<tt>atomicrmw</tt>' instruction is used to atomically modify memory.</p> 5229 5230<h5>Arguments:</h5> 5231<p>There are three arguments to the '<code>atomicrmw</code>' instruction: an 5232operation to apply, an address whose value to modify, an argument to the 5233operation. The operation must be one of the following keywords:</p> 5234<ul> 5235 <li>xchg</li> 5236 <li>add</li> 5237 <li>sub</li> 5238 <li>and</li> 5239 <li>nand</li> 5240 <li>or</li> 5241 <li>xor</li> 5242 <li>max</li> 5243 <li>min</li> 5244 <li>umax</li> 5245 <li>umin</li> 5246</ul> 5247 5248<p>The type of '<var><value></var>' must be an integer type whose 5249bit width is a power of two greater than or equal to eight and less than 5250or equal to a target-specific size limit. The type of the 5251'<code><pointer></code>' operand must be a pointer to that type. 5252If the <code>atomicrmw</code> is marked as <code>volatile</code>, then the 5253optimizer is not allowed to modify the number or order of execution of this 5254<code>atomicrmw</code> with other <a href="#volatile">volatile 5255 operations</a>.</p> 5256 5257<!-- FIXME: Extend allowed types. --> 5258 5259<h5>Semantics:</h5> 5260<p>The contents of memory at the location specified by the 5261'<tt><pointer></tt>' operand are atomically read, modified, and written 5262back. The original value at the location is returned. The modification is 5263specified by the <var>operation</var> argument:</p> 5264 5265<ul> 5266 <li>xchg: <code>*ptr = val</code></li> 5267 <li>add: <code>*ptr = *ptr + val</code></li> 5268 <li>sub: <code>*ptr = *ptr - val</code></li> 5269 <li>and: <code>*ptr = *ptr & val</code></li> 5270 <li>nand: <code>*ptr = ~(*ptr & val)</code></li> 5271 <li>or: <code>*ptr = *ptr | val</code></li> 5272 <li>xor: <code>*ptr = *ptr ^ val</code></li> 5273 <li>max: <code>*ptr = *ptr > val ? *ptr : val</code> (using a signed comparison)</li> 5274 <li>min: <code>*ptr = *ptr < val ? *ptr : val</code> (using a signed comparison)</li> 5275 <li>umax: <code>*ptr = *ptr > val ? *ptr : val</code> (using an unsigned comparison)</li> 5276 <li>umin: <code>*ptr = *ptr < val ? *ptr : val</code> (using an unsigned comparison)</li> 5277</ul> 5278 5279<h5>Example:</h5> 5280<pre> 5281 %old = atomicrmw add i32* %ptr, i32 1 acquire <i>; yields {i32}</i> 5282</pre> 5283 5284</div> 5285 5286<!-- _______________________________________________________________________ --> 5287<h4> 5288 <a name="i_getelementptr">'<tt>getelementptr</tt>' Instruction</a> 5289</h4> 5290 5291<div> 5292 5293<h5>Syntax:</h5> 5294<pre> 5295 <result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}* 5296 <result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}* 5297 <result> = getelementptr <ptr vector> ptrval, <vector index type> idx 5298</pre> 5299 5300<h5>Overview:</h5> 5301<p>The '<tt>getelementptr</tt>' instruction is used to get the address of a 5302 subelement of an <a href="#t_aggregate">aggregate</a> data structure. 5303 It performs address calculation only and does not access memory.</p> 5304 5305<h5>Arguments:</h5> 5306<p>The first argument is always a pointer or a vector of pointers, 5307 and forms the basis of the 5308 calculation. The remaining arguments are indices that indicate which of the 5309 elements of the aggregate object are indexed. The interpretation of each 5310 index is dependent on the type being indexed into. The first index always 5311 indexes the pointer value given as the first argument, the second index 5312 indexes a value of the type pointed to (not necessarily the value directly 5313 pointed to, since the first index can be non-zero), etc. The first type 5314 indexed into must be a pointer value, subsequent types can be arrays, 5315 vectors, and structs. Note that subsequent types being indexed into 5316 can never be pointers, since that would require loading the pointer before 5317 continuing calculation.</p> 5318 5319<p>The type of each index argument depends on the type it is indexing into. 5320 When indexing into a (optionally packed) structure, only <tt>i32</tt> 5321 integer <b>constants</b> are allowed. When indexing into an array, pointer 5322 or vector, integers of any width are allowed, and they are not required to be 5323 constant. These integers are treated as signed values where relevant.</p> 5324 5325<p>For example, let's consider a C code fragment and how it gets compiled to 5326 LLVM:</p> 5327 5328<pre class="doc_code"> 5329struct RT { 5330 char A; 5331 int B[10][20]; 5332 char C; 5333}; 5334struct ST { 5335 int X; 5336 double Y; 5337 struct RT Z; 5338}; 5339 5340int *foo(struct ST *s) { 5341 return &s[1].Z.B[5][13]; 5342} 5343</pre> 5344 5345<p>The LLVM code generated by Clang is:</p> 5346 5347<pre class="doc_code"> 5348%struct.RT = <a href="#namedtypes">type</a> { i8, [10 x [20 x i32]], i8 } 5349%struct.ST = <a href="#namedtypes">type</a> { i32, double, %struct.RT } 5350 5351define i32* @foo(%struct.ST* %s) nounwind uwtable readnone optsize ssp { 5352entry: 5353 %arrayidx = getelementptr inbounds %struct.ST* %s, i64 1, i32 2, i32 1, i64 5, i64 13 5354 ret i32* %arrayidx 5355} 5356</pre> 5357 5358<h5>Semantics:</h5> 5359<p>In the example above, the first index is indexing into the 5360 '<tt>%struct.ST*</tt>' type, which is a pointer, yielding a 5361 '<tt>%struct.ST</tt>' = '<tt>{ i32, double, %struct.RT }</tt>' type, a 5362 structure. The second index indexes into the third element of the structure, 5363 yielding a '<tt>%struct.RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]], i8 }</tt>' 5364 type, another structure. The third index indexes into the second element of 5365 the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an array. The 5366 two dimensions of the array are subscripted into, yielding an '<tt>i32</tt>' 5367 type. The '<tt>getelementptr</tt>' instruction returns a pointer to this 5368 element, thus computing a value of '<tt>i32*</tt>' type.</p> 5369 5370<p>Note that it is perfectly legal to index partially through a structure, 5371 returning a pointer to an inner element. Because of this, the LLVM code for 5372 the given testcase is equivalent to:</p> 5373 5374<pre class="doc_code"> 5375define i32* @foo(%struct.ST* %s) { 5376 %t1 = getelementptr %struct.ST* %s, i32 1 <i>; yields %struct.ST*:%t1</i> 5377 %t2 = getelementptr %struct.ST* %t1, i32 0, i32 2 <i>; yields %struct.RT*:%t2</i> 5378 %t3 = getelementptr %struct.RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i> 5379 %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i> 5380 %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i> 5381 ret i32* %t5 5382} 5383</pre> 5384 5385<p>If the <tt>inbounds</tt> keyword is present, the result value of the 5386 <tt>getelementptr</tt> is a <a href="#poisonvalues">poison value</a> if the 5387 base pointer is not an <i>in bounds</i> address of an allocated object, 5388 or if any of the addresses that would be formed by successive addition of 5389 the offsets implied by the indices to the base address with infinitely 5390 precise signed arithmetic are not an <i>in bounds</i> address of that 5391 allocated object. The <i>in bounds</i> addresses for an allocated object 5392 are all the addresses that point into the object, plus the address one 5393 byte past the end. 5394 In cases where the base is a vector of pointers the <tt>inbounds</tt> keyword 5395 applies to each of the computations element-wise. </p> 5396 5397<p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to 5398 the base address with silently-wrapping two's complement arithmetic. If the 5399 offsets have a different width from the pointer, they are sign-extended or 5400 truncated to the width of the pointer. The result value of the 5401 <tt>getelementptr</tt> may be outside the object pointed to by the base 5402 pointer. The result value may not necessarily be used to access memory 5403 though, even if it happens to point into allocated storage. See the 5404 <a href="#pointeraliasing">Pointer Aliasing Rules</a> section for more 5405 information.</p> 5406 5407<p>The getelementptr instruction is often confusing. For some more insight into 5408 how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p> 5409 5410<h5>Example:</h5> 5411<pre> 5412 <i>; yields [12 x i8]*:aptr</i> 5413 %aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1 5414 <i>; yields i8*:vptr</i> 5415 %vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1 5416 <i>; yields i8*:eptr</i> 5417 %eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1 5418 <i>; yields i32*:iptr</i> 5419 %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0 5420</pre> 5421 5422<p>In cases where the pointer argument is a vector of pointers, only a 5423 single index may be used, and the number of vector elements has to be 5424 the same. For example: </p> 5425<pre class="doc_code"> 5426 %A = getelementptr <4 x i8*> %ptrs, <4 x i64> %offsets, 5427</pre> 5428 5429</div> 5430 5431</div> 5432 5433<!-- ======================================================================= --> 5434<h3> 5435 <a name="convertops">Conversion Operations</a> 5436</h3> 5437 5438<div> 5439 5440<p>The instructions in this category are the conversion instructions (casting) 5441 which all take a single operand and a type. They perform various bit 5442 conversions on the operand.</p> 5443 5444<!-- _______________________________________________________________________ --> 5445<h4> 5446 <a name="i_trunc">'<tt>trunc .. to</tt>' Instruction</a> 5447</h4> 5448 5449<div> 5450 5451<h5>Syntax:</h5> 5452<pre> 5453 <result> = trunc <ty> <value> to <ty2> <i>; yields ty2</i> 5454</pre> 5455 5456<h5>Overview:</h5> 5457<p>The '<tt>trunc</tt>' instruction truncates its operand to the 5458 type <tt>ty2</tt>.</p> 5459 5460<h5>Arguments:</h5> 5461<p>The '<tt>trunc</tt>' instruction takes a value to trunc, and a type to trunc it to. 5462 Both types must be of <a href="#t_integer">integer</a> types, or vectors 5463 of the same number of integers. 5464 The bit size of the <tt>value</tt> must be larger than 5465 the bit size of the destination type, <tt>ty2</tt>. 5466 Equal sized types are not allowed.</p> 5467 5468<h5>Semantics:</h5> 5469<p>The '<tt>trunc</tt>' instruction truncates the high order bits 5470 in <tt>value</tt> and converts the remaining bits to <tt>ty2</tt>. Since the 5471 source size must be larger than the destination size, <tt>trunc</tt> cannot 5472 be a <i>no-op cast</i>. It will always truncate bits.</p> 5473 5474<h5>Example:</h5> 5475<pre> 5476 %X = trunc i32 257 to i8 <i>; yields i8:1</i> 5477 %Y = trunc i32 123 to i1 <i>; yields i1:true</i> 5478 %Z = trunc i32 122 to i1 <i>; yields i1:false</i> 5479 %W = trunc <2 x i16> <i16 8, i16 7> to <2 x i8> <i>; yields <i8 8, i8 7></i> 5480</pre> 5481 5482</div> 5483 5484<!-- _______________________________________________________________________ --> 5485<h4> 5486 <a name="i_zext">'<tt>zext .. to</tt>' Instruction</a> 5487</h4> 5488 5489<div> 5490 5491<h5>Syntax:</h5> 5492<pre> 5493 <result> = zext <ty> <value> to <ty2> <i>; yields ty2</i> 5494</pre> 5495 5496<h5>Overview:</h5> 5497<p>The '<tt>zext</tt>' instruction zero extends its operand to type 5498 <tt>ty2</tt>.</p> 5499 5500 5501<h5>Arguments:</h5> 5502<p>The '<tt>zext</tt>' instruction takes a value to cast, and a type to cast it to. 5503 Both types must be of <a href="#t_integer">integer</a> types, or vectors 5504 of the same number of integers. 5505 The bit size of the <tt>value</tt> must be smaller than 5506 the bit size of the destination type, 5507 <tt>ty2</tt>.</p> 5508 5509<h5>Semantics:</h5> 5510<p>The <tt>zext</tt> fills the high order bits of the <tt>value</tt> with zero 5511 bits until it reaches the size of the destination type, <tt>ty2</tt>.</p> 5512 5513<p>When zero extending from i1, the result will always be either 0 or 1.</p> 5514 5515<h5>Example:</h5> 5516<pre> 5517 %X = zext i32 257 to i64 <i>; yields i64:257</i> 5518 %Y = zext i1 true to i32 <i>; yields i32:1</i> 5519 %Z = zext <2 x i16> <i16 8, i16 7> to <2 x i32> <i>; yields <i32 8, i32 7></i> 5520</pre> 5521 5522</div> 5523 5524<!-- _______________________________________________________________________ --> 5525<h4> 5526 <a name="i_sext">'<tt>sext .. to</tt>' Instruction</a> 5527</h4> 5528 5529<div> 5530 5531<h5>Syntax:</h5> 5532<pre> 5533 <result> = sext <ty> <value> to <ty2> <i>; yields ty2</i> 5534</pre> 5535 5536<h5>Overview:</h5> 5537<p>The '<tt>sext</tt>' sign extends <tt>value</tt> to the type <tt>ty2</tt>.</p> 5538 5539<h5>Arguments:</h5> 5540<p>The '<tt>sext</tt>' instruction takes a value to cast, and a type to cast it to. 5541 Both types must be of <a href="#t_integer">integer</a> types, or vectors 5542 of the same number of integers. 5543 The bit size of the <tt>value</tt> must be smaller than 5544 the bit size of the destination type, 5545 <tt>ty2</tt>.</p> 5546 5547<h5>Semantics:</h5> 5548<p>The '<tt>sext</tt>' instruction performs a sign extension by copying the sign 5549 bit (highest order bit) of the <tt>value</tt> until it reaches the bit size 5550 of the type <tt>ty2</tt>.</p> 5551 5552<p>When sign extending from i1, the extension always results in -1 or 0.</p> 5553 5554<h5>Example:</h5> 5555<pre> 5556 %X = sext i8 -1 to i16 <i>; yields i16 :65535</i> 5557 %Y = sext i1 true to i32 <i>; yields i32:-1</i> 5558 %Z = sext <2 x i16> <i16 8, i16 7> to <2 x i32> <i>; yields <i32 8, i32 7></i> 5559</pre> 5560 5561</div> 5562 5563<!-- _______________________________________________________________________ --> 5564<h4> 5565 <a name="i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a> 5566</h4> 5567 5568<div> 5569 5570<h5>Syntax:</h5> 5571<pre> 5572 <result> = fptrunc <ty> <value> to <ty2> <i>; yields ty2</i> 5573</pre> 5574 5575<h5>Overview:</h5> 5576<p>The '<tt>fptrunc</tt>' instruction truncates <tt>value</tt> to type 5577 <tt>ty2</tt>.</p> 5578 5579<h5>Arguments:</h5> 5580<p>The '<tt>fptrunc</tt>' instruction takes a <a href="#t_floating">floating 5581 point</a> value to cast and a <a href="#t_floating">floating point</a> type 5582 to cast it to. The size of <tt>value</tt> must be larger than the size of 5583 <tt>ty2</tt>. This implies that <tt>fptrunc</tt> cannot be used to make a 5584 <i>no-op cast</i>.</p> 5585 5586<h5>Semantics:</h5> 5587<p>The '<tt>fptrunc</tt>' instruction truncates a <tt>value</tt> from a larger 5588 <a href="#t_floating">floating point</a> type to a smaller 5589 <a href="#t_floating">floating point</a> type. If the value cannot fit 5590 within the destination type, <tt>ty2</tt>, then the results are 5591 undefined.</p> 5592 5593<h5>Example:</h5> 5594<pre> 5595 %X = fptrunc double 123.0 to float <i>; yields float:123.0</i> 5596 %Y = fptrunc double 1.0E+300 to float <i>; yields undefined</i> 5597</pre> 5598 5599</div> 5600 5601<!-- _______________________________________________________________________ --> 5602<h4> 5603 <a name="i_fpext">'<tt>fpext .. to</tt>' Instruction</a> 5604</h4> 5605 5606<div> 5607 5608<h5>Syntax:</h5> 5609<pre> 5610 <result> = fpext <ty> <value> to <ty2> <i>; yields ty2</i> 5611</pre> 5612 5613<h5>Overview:</h5> 5614<p>The '<tt>fpext</tt>' extends a floating point <tt>value</tt> to a larger 5615 floating point value.</p> 5616 5617<h5>Arguments:</h5> 5618<p>The '<tt>fpext</tt>' instruction takes a 5619 <a href="#t_floating">floating point</a> <tt>value</tt> to cast, and 5620 a <a href="#t_floating">floating point</a> type to cast it to. The source 5621 type must be smaller than the destination type.</p> 5622 5623<h5>Semantics:</h5> 5624<p>The '<tt>fpext</tt>' instruction extends the <tt>value</tt> from a smaller 5625 <a href="#t_floating">floating point</a> type to a larger 5626 <a href="#t_floating">floating point</a> type. The <tt>fpext</tt> cannot be 5627 used to make a <i>no-op cast</i> because it always changes bits. Use 5628 <tt>bitcast</tt> to make a <i>no-op cast</i> for a floating point cast.</p> 5629 5630<h5>Example:</h5> 5631<pre> 5632 %X = fpext float 3.125 to double <i>; yields double:3.125000e+00</i> 5633 %Y = fpext double %X to fp128 <i>; yields fp128:0xL00000000000000004000900000000000</i> 5634</pre> 5635 5636</div> 5637 5638<!-- _______________________________________________________________________ --> 5639<h4> 5640 <a name="i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a> 5641</h4> 5642 5643<div> 5644 5645<h5>Syntax:</h5> 5646<pre> 5647 <result> = fptoui <ty> <value> to <ty2> <i>; yields ty2</i> 5648</pre> 5649 5650<h5>Overview:</h5> 5651<p>The '<tt>fptoui</tt>' converts a floating point <tt>value</tt> to its 5652 unsigned integer equivalent of type <tt>ty2</tt>.</p> 5653 5654<h5>Arguments:</h5> 5655<p>The '<tt>fptoui</tt>' instruction takes a value to cast, which must be a 5656 scalar or vector <a href="#t_floating">floating point</a> value, and a type 5657 to cast it to <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> 5658 type. If <tt>ty</tt> is a vector floating point type, <tt>ty2</tt> must be a 5659 vector integer type with the same number of elements as <tt>ty</tt></p> 5660 5661<h5>Semantics:</h5> 5662<p>The '<tt>fptoui</tt>' instruction converts its 5663 <a href="#t_floating">floating point</a> operand into the nearest (rounding 5664 towards zero) unsigned integer value. If the value cannot fit 5665 in <tt>ty2</tt>, the results are undefined.</p> 5666 5667<h5>Example:</h5> 5668<pre> 5669 %X = fptoui double 123.0 to i32 <i>; yields i32:123</i> 5670 %Y = fptoui float 1.0E+300 to i1 <i>; yields undefined:1</i> 5671 %Z = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i> 5672</pre> 5673 5674</div> 5675 5676<!-- _______________________________________________________________________ --> 5677<h4> 5678 <a name="i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a> 5679</h4> 5680 5681<div> 5682 5683<h5>Syntax:</h5> 5684<pre> 5685 <result> = fptosi <ty> <value> to <ty2> <i>; yields ty2</i> 5686</pre> 5687 5688<h5>Overview:</h5> 5689<p>The '<tt>fptosi</tt>' instruction converts 5690 <a href="#t_floating">floating point</a> <tt>value</tt> to 5691 type <tt>ty2</tt>.</p> 5692 5693<h5>Arguments:</h5> 5694<p>The '<tt>fptosi</tt>' instruction takes a value to cast, which must be a 5695 scalar or vector <a href="#t_floating">floating point</a> value, and a type 5696 to cast it to <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> 5697 type. If <tt>ty</tt> is a vector floating point type, <tt>ty2</tt> must be a 5698 vector integer type with the same number of elements as <tt>ty</tt></p> 5699 5700<h5>Semantics:</h5> 5701<p>The '<tt>fptosi</tt>' instruction converts its 5702 <a href="#t_floating">floating point</a> operand into the nearest (rounding 5703 towards zero) signed integer value. If the value cannot fit in <tt>ty2</tt>, 5704 the results are undefined.</p> 5705 5706<h5>Example:</h5> 5707<pre> 5708 %X = fptosi double -123.0 to i32 <i>; yields i32:-123</i> 5709 %Y = fptosi float 1.0E-247 to i1 <i>; yields undefined:1</i> 5710 %Z = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i> 5711</pre> 5712 5713</div> 5714 5715<!-- _______________________________________________________________________ --> 5716<h4> 5717 <a name="i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a> 5718</h4> 5719 5720<div> 5721 5722<h5>Syntax:</h5> 5723<pre> 5724 <result> = uitofp <ty> <value> to <ty2> <i>; yields ty2</i> 5725</pre> 5726 5727<h5>Overview:</h5> 5728<p>The '<tt>uitofp</tt>' instruction regards <tt>value</tt> as an unsigned 5729 integer and converts that value to the <tt>ty2</tt> type.</p> 5730 5731<h5>Arguments:</h5> 5732<p>The '<tt>uitofp</tt>' instruction takes a value to cast, which must be a 5733 scalar or vector <a href="#t_integer">integer</a> value, and a type to cast 5734 it to <tt>ty2</tt>, which must be an <a href="#t_floating">floating point</a> 5735 type. If <tt>ty</tt> is a vector integer type, <tt>ty2</tt> must be a vector 5736 floating point type with the same number of elements as <tt>ty</tt></p> 5737 5738<h5>Semantics:</h5> 5739<p>The '<tt>uitofp</tt>' instruction interprets its operand as an unsigned 5740 integer quantity and converts it to the corresponding floating point 5741 value. If the value cannot fit in the floating point value, the results are 5742 undefined.</p> 5743 5744<h5>Example:</h5> 5745<pre> 5746 %X = uitofp i32 257 to float <i>; yields float:257.0</i> 5747 %Y = uitofp i8 -1 to double <i>; yields double:255.0</i> 5748</pre> 5749 5750</div> 5751 5752<!-- _______________________________________________________________________ --> 5753<h4> 5754 <a name="i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a> 5755</h4> 5756 5757<div> 5758 5759<h5>Syntax:</h5> 5760<pre> 5761 <result> = sitofp <ty> <value> to <ty2> <i>; yields ty2</i> 5762</pre> 5763 5764<h5>Overview:</h5> 5765<p>The '<tt>sitofp</tt>' instruction regards <tt>value</tt> as a signed integer 5766 and converts that value to the <tt>ty2</tt> type.</p> 5767 5768<h5>Arguments:</h5> 5769<p>The '<tt>sitofp</tt>' instruction takes a value to cast, which must be a 5770 scalar or vector <a href="#t_integer">integer</a> value, and a type to cast 5771 it to <tt>ty2</tt>, which must be an <a href="#t_floating">floating point</a> 5772 type. If <tt>ty</tt> is a vector integer type, <tt>ty2</tt> must be a vector 5773 floating point type with the same number of elements as <tt>ty</tt></p> 5774 5775<h5>Semantics:</h5> 5776<p>The '<tt>sitofp</tt>' instruction interprets its operand as a signed integer 5777 quantity and converts it to the corresponding floating point value. If the 5778 value cannot fit in the floating point value, the results are undefined.</p> 5779 5780<h5>Example:</h5> 5781<pre> 5782 %X = sitofp i32 257 to float <i>; yields float:257.0</i> 5783 %Y = sitofp i8 -1 to double <i>; yields double:-1.0</i> 5784</pre> 5785 5786</div> 5787 5788<!-- _______________________________________________________________________ --> 5789<h4> 5790 <a name="i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a> 5791</h4> 5792 5793<div> 5794 5795<h5>Syntax:</h5> 5796<pre> 5797 <result> = ptrtoint <ty> <value> to <ty2> <i>; yields ty2</i> 5798</pre> 5799 5800<h5>Overview:</h5> 5801<p>The '<tt>ptrtoint</tt>' instruction converts the pointer or a vector of 5802 pointers <tt>value</tt> to 5803 the integer (or vector of integers) type <tt>ty2</tt>.</p> 5804 5805<h5>Arguments:</h5> 5806<p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which 5807 must be a a value of type <a href="#t_pointer">pointer</a> or a vector of 5808 pointers, and a type to cast it to 5809 <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> or a vector 5810 of integers type.</p> 5811 5812<h5>Semantics:</h5> 5813<p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type 5814 <tt>ty2</tt> by interpreting the pointer value as an integer and either 5815 truncating or zero extending that value to the size of the integer type. If 5816 <tt>value</tt> is smaller than <tt>ty2</tt> then a zero extension is done. If 5817 <tt>value</tt> is larger than <tt>ty2</tt> then a truncation is done. If they 5818 are the same size, then nothing is done (<i>no-op cast</i>) other than a type 5819 change.</p> 5820 5821<h5>Example:</h5> 5822<pre> 5823 %X = ptrtoint i32* %P to i8 <i>; yields truncation on 32-bit architecture</i> 5824 %Y = ptrtoint i32* %P to i64 <i>; yields zero extension on 32-bit architecture</i> 5825 %Z = ptrtoint <4 x i32*> %P to <4 x i64><i>; yields vector zero extension for a vector of addresses on 32-bit architecture</i> 5826</pre> 5827 5828</div> 5829 5830<!-- _______________________________________________________________________ --> 5831<h4> 5832 <a name="i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a> 5833</h4> 5834 5835<div> 5836 5837<h5>Syntax:</h5> 5838<pre> 5839 <result> = inttoptr <ty> <value> to <ty2> <i>; yields ty2</i> 5840</pre> 5841 5842<h5>Overview:</h5> 5843<p>The '<tt>inttoptr</tt>' instruction converts an integer <tt>value</tt> to a 5844 pointer type, <tt>ty2</tt>.</p> 5845 5846<h5>Arguments:</h5> 5847<p>The '<tt>inttoptr</tt>' instruction takes an <a href="#t_integer">integer</a> 5848 value to cast, and a type to cast it to, which must be a 5849 <a href="#t_pointer">pointer</a> type.</p> 5850 5851<h5>Semantics:</h5> 5852<p>The '<tt>inttoptr</tt>' instruction converts <tt>value</tt> to type 5853 <tt>ty2</tt> by applying either a zero extension or a truncation depending on 5854 the size of the integer <tt>value</tt>. If <tt>value</tt> is larger than the 5855 size of a pointer then a truncation is done. If <tt>value</tt> is smaller 5856 than the size of a pointer then a zero extension is done. If they are the 5857 same size, nothing is done (<i>no-op cast</i>).</p> 5858 5859<h5>Example:</h5> 5860<pre> 5861 %X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i> 5862 %Y = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i> 5863 %Z = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i> 5864 %Z = inttoptr <4 x i32> %G to <4 x i8*><i>; yields truncation of vector G to four pointers</i> 5865</pre> 5866 5867</div> 5868 5869<!-- _______________________________________________________________________ --> 5870<h4> 5871 <a name="i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a> 5872</h4> 5873 5874<div> 5875 5876<h5>Syntax:</h5> 5877<pre> 5878 <result> = bitcast <ty> <value> to <ty2> <i>; yields ty2</i> 5879</pre> 5880 5881<h5>Overview:</h5> 5882<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type 5883 <tt>ty2</tt> without changing any bits.</p> 5884 5885<h5>Arguments:</h5> 5886<p>The '<tt>bitcast</tt>' instruction takes a value to cast, which must be a 5887 non-aggregate first class value, and a type to cast it to, which must also be 5888 a non-aggregate <a href="#t_firstclass">first class</a> type. The bit sizes 5889 of <tt>value</tt> and the destination type, <tt>ty2</tt>, must be 5890 identical. If the source type is a pointer, the destination type must also be 5891 a pointer. This instruction supports bitwise conversion of vectors to 5892 integers and to vectors of other types (as long as they have the same 5893 size).</p> 5894 5895<h5>Semantics:</h5> 5896<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type 5897 <tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with 5898 this conversion. The conversion is done as if the <tt>value</tt> had been 5899 stored to memory and read back as type <tt>ty2</tt>. 5900 Pointer (or vector of pointers) types may only be converted to other pointer 5901 (or vector of pointers) types with this instruction. To convert 5902 pointers to other types, use the <a href="#i_inttoptr">inttoptr</a> or 5903 <a href="#i_ptrtoint">ptrtoint</a> instructions first.</p> 5904 5905<h5>Example:</h5> 5906<pre> 5907 %X = bitcast i8 255 to i8 <i>; yields i8 :-1</i> 5908 %Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i> 5909 %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i> 5910 %Z = bitcast <2 x i32*> %V to <2 x i64*> <i>; yields <2 x i64*></i> 5911</pre> 5912 5913</div> 5914 5915</div> 5916 5917<!-- ======================================================================= --> 5918<h3> 5919 <a name="otherops">Other Operations</a> 5920</h3> 5921 5922<div> 5923 5924<p>The instructions in this category are the "miscellaneous" instructions, which 5925 defy better classification.</p> 5926 5927<!-- _______________________________________________________________________ --> 5928<h4> 5929 <a name="i_icmp">'<tt>icmp</tt>' Instruction</a> 5930</h4> 5931 5932<div> 5933 5934<h5>Syntax:</h5> 5935<pre> 5936 <result> = icmp <cond> <ty> <op1>, <op2> <i>; yields {i1} or {<N x i1>}:result</i> 5937</pre> 5938 5939<h5>Overview:</h5> 5940<p>The '<tt>icmp</tt>' instruction returns a boolean value or a vector of 5941 boolean values based on comparison of its two integer, integer vector, 5942 pointer, or pointer vector operands.</p> 5943 5944<h5>Arguments:</h5> 5945<p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is 5946 the condition code indicating the kind of comparison to perform. It is not a 5947 value, just a keyword. The possible condition code are:</p> 5948 5949<ol> 5950 <li><tt>eq</tt>: equal</li> 5951 <li><tt>ne</tt>: not equal </li> 5952 <li><tt>ugt</tt>: unsigned greater than</li> 5953 <li><tt>uge</tt>: unsigned greater or equal</li> 5954 <li><tt>ult</tt>: unsigned less than</li> 5955 <li><tt>ule</tt>: unsigned less or equal</li> 5956 <li><tt>sgt</tt>: signed greater than</li> 5957 <li><tt>sge</tt>: signed greater or equal</li> 5958 <li><tt>slt</tt>: signed less than</li> 5959 <li><tt>sle</tt>: signed less or equal</li> 5960</ol> 5961 5962<p>The remaining two arguments must be <a href="#t_integer">integer</a> or 5963 <a href="#t_pointer">pointer</a> or integer <a href="#t_vector">vector</a> 5964 typed. They must also be identical types.</p> 5965 5966<h5>Semantics:</h5> 5967<p>The '<tt>icmp</tt>' compares <tt>op1</tt> and <tt>op2</tt> according to the 5968 condition code given as <tt>cond</tt>. The comparison performed always yields 5969 either an <a href="#t_integer"><tt>i1</tt></a> or vector of <tt>i1</tt> 5970 result, as follows:</p> 5971 5972<ol> 5973 <li><tt>eq</tt>: yields <tt>true</tt> if the operands are equal, 5974 <tt>false</tt> otherwise. No sign interpretation is necessary or 5975 performed.</li> 5976 5977 <li><tt>ne</tt>: yields <tt>true</tt> if the operands are unequal, 5978 <tt>false</tt> otherwise. No sign interpretation is necessary or 5979 performed.</li> 5980 5981 <li><tt>ugt</tt>: interprets the operands as unsigned values and yields 5982 <tt>true</tt> if <tt>op1</tt> is greater than <tt>op2</tt>.</li> 5983 5984 <li><tt>uge</tt>: interprets the operands as unsigned values and yields 5985 <tt>true</tt> if <tt>op1</tt> is greater than or equal 5986 to <tt>op2</tt>.</li> 5987 5988 <li><tt>ult</tt>: interprets the operands as unsigned values and yields 5989 <tt>true</tt> if <tt>op1</tt> is less than <tt>op2</tt>.</li> 5990 5991 <li><tt>ule</tt>: interprets the operands as unsigned values and yields 5992 <tt>true</tt> if <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li> 5993 5994 <li><tt>sgt</tt>: interprets the operands as signed values and yields 5995 <tt>true</tt> if <tt>op1</tt> is greater than <tt>op2</tt>.</li> 5996 5997 <li><tt>sge</tt>: interprets the operands as signed values and yields 5998 <tt>true</tt> if <tt>op1</tt> is greater than or equal 5999 to <tt>op2</tt>.</li> 6000 6001 <li><tt>slt</tt>: interprets the operands as signed values and yields 6002 <tt>true</tt> if <tt>op1</tt> is less than <tt>op2</tt>.</li> 6003 6004 <li><tt>sle</tt>: interprets the operands as signed values and yields 6005 <tt>true</tt> if <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li> 6006</ol> 6007 6008<p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer 6009 values are compared as if they were integers.</p> 6010 6011<p>If the operands are integer vectors, then they are compared element by 6012 element. The result is an <tt>i1</tt> vector with the same number of elements 6013 as the values being compared. Otherwise, the result is an <tt>i1</tt>.</p> 6014 6015<h5>Example:</h5> 6016<pre> 6017 <result> = icmp eq i32 4, 5 <i>; yields: result=false</i> 6018 <result> = icmp ne float* %X, %X <i>; yields: result=false</i> 6019 <result> = icmp ult i16 4, 5 <i>; yields: result=true</i> 6020 <result> = icmp sgt i16 4, 5 <i>; yields: result=false</i> 6021 <result> = icmp ule i16 -4, 5 <i>; yields: result=false</i> 6022 <result> = icmp sge i16 4, 5 <i>; yields: result=false</i> 6023</pre> 6024 6025<p>Note that the code generator does not yet support vector types with 6026 the <tt>icmp</tt> instruction.</p> 6027 6028</div> 6029 6030<!-- _______________________________________________________________________ --> 6031<h4> 6032 <a name="i_fcmp">'<tt>fcmp</tt>' Instruction</a> 6033</h4> 6034 6035<div> 6036 6037<h5>Syntax:</h5> 6038<pre> 6039 <result> = fcmp <cond> <ty> <op1>, <op2> <i>; yields {i1} or {<N x i1>}:result</i> 6040</pre> 6041 6042<h5>Overview:</h5> 6043<p>The '<tt>fcmp</tt>' instruction returns a boolean value or vector of boolean 6044 values based on comparison of its operands.</p> 6045 6046<p>If the operands are floating point scalars, then the result type is a boolean 6047(<a href="#t_integer"><tt>i1</tt></a>).</p> 6048 6049<p>If the operands are floating point vectors, then the result type is a vector 6050 of boolean with the same number of elements as the operands being 6051 compared.</p> 6052 6053<h5>Arguments:</h5> 6054<p>The '<tt>fcmp</tt>' instruction takes three operands. The first operand is 6055 the condition code indicating the kind of comparison to perform. It is not a 6056 value, just a keyword. The possible condition code are:</p> 6057 6058<ol> 6059 <li><tt>false</tt>: no comparison, always returns false</li> 6060 <li><tt>oeq</tt>: ordered and equal</li> 6061 <li><tt>ogt</tt>: ordered and greater than </li> 6062 <li><tt>oge</tt>: ordered and greater than or equal</li> 6063 <li><tt>olt</tt>: ordered and less than </li> 6064 <li><tt>ole</tt>: ordered and less than or equal</li> 6065 <li><tt>one</tt>: ordered and not equal</li> 6066 <li><tt>ord</tt>: ordered (no nans)</li> 6067 <li><tt>ueq</tt>: unordered or equal</li> 6068 <li><tt>ugt</tt>: unordered or greater than </li> 6069 <li><tt>uge</tt>: unordered or greater than or equal</li> 6070 <li><tt>ult</tt>: unordered or less than </li> 6071 <li><tt>ule</tt>: unordered or less than or equal</li> 6072 <li><tt>une</tt>: unordered or not equal</li> 6073 <li><tt>uno</tt>: unordered (either nans)</li> 6074 <li><tt>true</tt>: no comparison, always returns true</li> 6075</ol> 6076 6077<p><i>Ordered</i> means that neither operand is a QNAN while 6078 <i>unordered</i> means that either operand may be a QNAN.</p> 6079 6080<p>Each of <tt>val1</tt> and <tt>val2</tt> arguments must be either 6081 a <a href="#t_floating">floating point</a> type or 6082 a <a href="#t_vector">vector</a> of floating point type. They must have 6083 identical types.</p> 6084 6085<h5>Semantics:</h5> 6086<p>The '<tt>fcmp</tt>' instruction compares <tt>op1</tt> and <tt>op2</tt> 6087 according to the condition code given as <tt>cond</tt>. If the operands are 6088 vectors, then the vectors are compared element by element. Each comparison 6089 performed always yields an <a href="#t_integer">i1</a> result, as 6090 follows:</p> 6091 6092<ol> 6093 <li><tt>false</tt>: always yields <tt>false</tt>, regardless of operands.</li> 6094 6095 <li><tt>oeq</tt>: yields <tt>true</tt> if both operands are not a QNAN and 6096 <tt>op1</tt> is equal to <tt>op2</tt>.</li> 6097 6098 <li><tt>ogt</tt>: yields <tt>true</tt> if both operands are not a QNAN and 6099 <tt>op1</tt> is greater than <tt>op2</tt>.</li> 6100 6101 <li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and 6102 <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li> 6103 6104 <li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and 6105 <tt>op1</tt> is less than <tt>op2</tt>.</li> 6106 6107 <li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and 6108 <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li> 6109 6110 <li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and 6111 <tt>op1</tt> is not equal to <tt>op2</tt>.</li> 6112 6113 <li><tt>ord</tt>: yields <tt>true</tt> if both operands are not a QNAN.</li> 6114 6115 <li><tt>ueq</tt>: yields <tt>true</tt> if either operand is a QNAN or 6116 <tt>op1</tt> is equal to <tt>op2</tt>.</li> 6117 6118 <li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or 6119 <tt>op1</tt> is greater than <tt>op2</tt>.</li> 6120 6121 <li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or 6122 <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li> 6123 6124 <li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or 6125 <tt>op1</tt> is less than <tt>op2</tt>.</li> 6126 6127 <li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or 6128 <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li> 6129 6130 <li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or 6131 <tt>op1</tt> is not equal to <tt>op2</tt>.</li> 6132 6133 <li><tt>uno</tt>: yields <tt>true</tt> if either operand is a QNAN.</li> 6134 6135 <li><tt>true</tt>: always yields <tt>true</tt>, regardless of operands.</li> 6136</ol> 6137 6138<h5>Example:</h5> 6139<pre> 6140 <result> = fcmp oeq float 4.0, 5.0 <i>; yields: result=false</i> 6141 <result> = fcmp one float 4.0, 5.0 <i>; yields: result=true</i> 6142 <result> = fcmp olt float 4.0, 5.0 <i>; yields: result=true</i> 6143 <result> = fcmp ueq double 1.0, 2.0 <i>; yields: result=false</i> 6144</pre> 6145 6146<p>Note that the code generator does not yet support vector types with 6147 the <tt>fcmp</tt> instruction.</p> 6148 6149</div> 6150 6151<!-- _______________________________________________________________________ --> 6152<h4> 6153 <a name="i_phi">'<tt>phi</tt>' Instruction</a> 6154</h4> 6155 6156<div> 6157 6158<h5>Syntax:</h5> 6159<pre> 6160 <result> = phi <ty> [ <val0>, <label0>], ... 6161</pre> 6162 6163<h5>Overview:</h5> 6164<p>The '<tt>phi</tt>' instruction is used to implement the φ node in the 6165 SSA graph representing the function.</p> 6166 6167<h5>Arguments:</h5> 6168<p>The type of the incoming values is specified with the first type field. After 6169 this, the '<tt>phi</tt>' instruction takes a list of pairs as arguments, with 6170 one pair for each predecessor basic block of the current block. Only values 6171 of <a href="#t_firstclass">first class</a> type may be used as the value 6172 arguments to the PHI node. Only labels may be used as the label 6173 arguments.</p> 6174 6175<p>There must be no non-phi instructions between the start of a basic block and 6176 the PHI instructions: i.e. PHI instructions must be first in a basic 6177 block.</p> 6178 6179<p>For the purposes of the SSA form, the use of each incoming value is deemed to 6180 occur on the edge from the corresponding predecessor block to the current 6181 block (but after any definition of an '<tt>invoke</tt>' instruction's return 6182 value on the same edge).</p> 6183 6184<h5>Semantics:</h5> 6185<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value 6186 specified by the pair corresponding to the predecessor basic block that 6187 executed just prior to the current block.</p> 6188 6189<h5>Example:</h5> 6190<pre> 6191Loop: ; Infinite loop that counts from 0 on up... 6192 %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ] 6193 %nextindvar = add i32 %indvar, 1 6194 br label %Loop 6195</pre> 6196 6197</div> 6198 6199<!-- _______________________________________________________________________ --> 6200<h4> 6201 <a name="i_select">'<tt>select</tt>' Instruction</a> 6202</h4> 6203 6204<div> 6205 6206<h5>Syntax:</h5> 6207<pre> 6208 <result> = select <i>selty</i> <cond>, <ty> <val1>, <ty> <val2> <i>; yields ty</i> 6209 6210 <i>selty</i> is either i1 or {<N x i1>} 6211</pre> 6212 6213<h5>Overview:</h5> 6214<p>The '<tt>select</tt>' instruction is used to choose one value based on a 6215 condition, without branching.</p> 6216 6217 6218<h5>Arguments:</h5> 6219<p>The '<tt>select</tt>' instruction requires an 'i1' value or a vector of 'i1' 6220 values indicating the condition, and two values of the 6221 same <a href="#t_firstclass">first class</a> type. If the val1/val2 are 6222 vectors and the condition is a scalar, then entire vectors are selected, not 6223 individual elements.</p> 6224 6225<h5>Semantics:</h5> 6226<p>If the condition is an i1 and it evaluates to 1, the instruction returns the 6227 first value argument; otherwise, it returns the second value argument.</p> 6228 6229<p>If the condition is a vector of i1, then the value arguments must be vectors 6230 of the same size, and the selection is done element by element.</p> 6231 6232<h5>Example:</h5> 6233<pre> 6234 %X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i> 6235</pre> 6236 6237</div> 6238 6239<!-- _______________________________________________________________________ --> 6240<h4> 6241 <a name="i_call">'<tt>call</tt>' Instruction</a> 6242</h4> 6243 6244<div> 6245 6246<h5>Syntax:</h5> 6247<pre> 6248 <result> = [tail] call [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] <ty> [<fnty>*] <fnptrval>(<function args>) [<a href="#fnattrs">fn attrs</a>] 6249</pre> 6250 6251<h5>Overview:</h5> 6252<p>The '<tt>call</tt>' instruction represents a simple function call.</p> 6253 6254<h5>Arguments:</h5> 6255<p>This instruction requires several arguments:</p> 6256 6257<ol> 6258 <li>The optional "tail" marker indicates that the callee function does not 6259 access any allocas or varargs in the caller. Note that calls may be 6260 marked "tail" even if they do not occur before 6261 a <a href="#i_ret"><tt>ret</tt></a> instruction. If the "tail" marker is 6262 present, the function call is eligible for tail call optimization, 6263 but <a href="CodeGenerator.html#tailcallopt">might not in fact be 6264 optimized into a jump</a>. The code generator may optimize calls marked 6265 "tail" with either 1) automatic <a href="CodeGenerator.html#sibcallopt"> 6266 sibling call optimization</a> when the caller and callee have 6267 matching signatures, or 2) forced tail call optimization when the 6268 following extra requirements are met: 6269 <ul> 6270 <li>Caller and callee both have the calling 6271 convention <tt>fastcc</tt>.</li> 6272 <li>The call is in tail position (ret immediately follows call and ret 6273 uses value of call or is void).</li> 6274 <li>Option <tt>-tailcallopt</tt> is enabled, 6275 or <code>llvm::GuaranteedTailCallOpt</code> is <code>true</code>.</li> 6276 <li><a href="CodeGenerator.html#tailcallopt">Platform specific 6277 constraints are met.</a></li> 6278 </ul> 6279 </li> 6280 6281 <li>The optional "cconv" marker indicates which <a href="#callingconv">calling 6282 convention</a> the call should use. If none is specified, the call 6283 defaults to using C calling conventions. The calling convention of the 6284 call must match the calling convention of the target function, or else the 6285 behavior is undefined.</li> 6286 6287 <li>The optional <a href="#paramattrs">Parameter Attributes</a> list for 6288 return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>', and 6289 '<tt>inreg</tt>' attributes are valid here.</li> 6290 6291 <li>'<tt>ty</tt>': the type of the call instruction itself which is also the 6292 type of the return value. Functions that return no value are marked 6293 <tt><a href="#t_void">void</a></tt>.</li> 6294 6295 <li>'<tt>fnty</tt>': shall be the signature of the pointer to function value 6296 being invoked. The argument types must match the types implied by this 6297 signature. This type can be omitted if the function is not varargs and if 6298 the function type does not return a pointer to a function.</li> 6299 6300 <li>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to 6301 be invoked. In most cases, this is a direct function invocation, but 6302 indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer 6303 to function value.</li> 6304 6305 <li>'<tt>function args</tt>': argument list whose types match the function 6306 signature argument types and parameter attributes. All arguments must be 6307 of <a href="#t_firstclass">first class</a> type. If the function 6308 signature indicates the function accepts a variable number of arguments, 6309 the extra arguments can be specified.</li> 6310 6311 <li>The optional <a href="#fnattrs">function attributes</a> list. Only 6312 '<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and 6313 '<tt>readnone</tt>' attributes are valid here.</li> 6314</ol> 6315 6316<h5>Semantics:</h5> 6317<p>The '<tt>call</tt>' instruction is used to cause control flow to transfer to 6318 a specified function, with its incoming arguments bound to the specified 6319 values. Upon a '<tt><a href="#i_ret">ret</a></tt>' instruction in the called 6320 function, control flow continues with the instruction after the function 6321 call, and the return value of the function is bound to the result 6322 argument.</p> 6323 6324<h5>Example:</h5> 6325<pre> 6326 %retval = call i32 @test(i32 %argc) 6327 call i32 (i8*, ...)* @printf(i8* %msg, i32 12, i8 42) <i>; yields i32</i> 6328 %X = tail call i32 @foo() <i>; yields i32</i> 6329 %Y = tail call <a href="#callingconv">fastcc</a> i32 @foo() <i>; yields i32</i> 6330 call void %foo(i8 97 signext) 6331 6332 %struct.A = type { i32, i8 } 6333 %r = call %struct.A @foo() <i>; yields { 32, i8 }</i> 6334 %gr = extractvalue %struct.A %r, 0 <i>; yields i32</i> 6335 %gr1 = extractvalue %struct.A %r, 1 <i>; yields i8</i> 6336 %Z = call void @foo() noreturn <i>; indicates that %foo never returns normally</i> 6337 %ZZ = call zeroext i32 @bar() <i>; Return value is %zero extended</i> 6338</pre> 6339 6340<p>llvm treats calls to some functions with names and arguments that match the 6341standard C99 library as being the C99 library functions, and may perform 6342optimizations or generate code for them under that assumption. This is 6343something we'd like to change in the future to provide better support for 6344freestanding environments and non-C-based languages.</p> 6345 6346</div> 6347 6348<!-- _______________________________________________________________________ --> 6349<h4> 6350 <a name="i_va_arg">'<tt>va_arg</tt>' Instruction</a> 6351</h4> 6352 6353<div> 6354 6355<h5>Syntax:</h5> 6356<pre> 6357 <resultval> = va_arg <va_list*> <arglist>, <argty> 6358</pre> 6359 6360<h5>Overview:</h5> 6361<p>The '<tt>va_arg</tt>' instruction is used to access arguments passed through 6362 the "variable argument" area of a function call. It is used to implement the 6363 <tt>va_arg</tt> macro in C.</p> 6364 6365<h5>Arguments:</h5> 6366<p>This instruction takes a <tt>va_list*</tt> value and the type of the 6367 argument. It returns a value of the specified argument type and increments 6368 the <tt>va_list</tt> to point to the next argument. The actual type 6369 of <tt>va_list</tt> is target specific.</p> 6370 6371<h5>Semantics:</h5> 6372<p>The '<tt>va_arg</tt>' instruction loads an argument of the specified type 6373 from the specified <tt>va_list</tt> and causes the <tt>va_list</tt> to point 6374 to the next argument. For more information, see the variable argument 6375 handling <a href="#int_varargs">Intrinsic Functions</a>.</p> 6376 6377<p>It is legal for this instruction to be called in a function which does not 6378 take a variable number of arguments, for example, the <tt>vfprintf</tt> 6379 function.</p> 6380 6381<p><tt>va_arg</tt> is an LLVM instruction instead of 6382 an <a href="#intrinsics">intrinsic function</a> because it takes a type as an 6383 argument.</p> 6384 6385<h5>Example:</h5> 6386<p>See the <a href="#int_varargs">variable argument processing</a> section.</p> 6387 6388<p>Note that the code generator does not yet fully support va_arg on many 6389 targets. Also, it does not currently support va_arg with aggregate types on 6390 any target.</p> 6391 6392</div> 6393 6394<!-- _______________________________________________________________________ --> 6395<h4> 6396 <a name="i_landingpad">'<tt>landingpad</tt>' Instruction</a> 6397</h4> 6398 6399<div> 6400 6401<h5>Syntax:</h5> 6402<pre> 6403 <resultval> = landingpad <resultty> personality <type> <pers_fn> <clause>+ 6404 <resultval> = landingpad <resultty> personality <type> <pers_fn> cleanup <clause>* 6405 6406 <clause> := catch <type> <value> 6407 <clause> := filter <array constant type> <array constant> 6408</pre> 6409 6410<h5>Overview:</h5> 6411<p>The '<tt>landingpad</tt>' instruction is used by 6412 <a href="ExceptionHandling.html#overview">LLVM's exception handling 6413 system</a> to specify that a basic block is a landing pad — one where 6414 the exception lands, and corresponds to the code found in the 6415 <i><tt>catch</tt></i> portion of a <i><tt>try/catch</tt></i> sequence. It 6416 defines values supplied by the personality function (<tt>pers_fn</tt>) upon 6417 re-entry to the function. The <tt>resultval</tt> has the 6418 type <tt>resultty</tt>.</p> 6419 6420<h5>Arguments:</h5> 6421<p>This instruction takes a <tt>pers_fn</tt> value. This is the personality 6422 function associated with the unwinding mechanism. The optional 6423 <tt>cleanup</tt> flag indicates that the landing pad block is a cleanup.</p> 6424 6425<p>A <tt>clause</tt> begins with the clause type — <tt>catch</tt> 6426 or <tt>filter</tt> — and contains the global variable representing the 6427 "type" that may be caught or filtered respectively. Unlike the 6428 <tt>catch</tt> clause, the <tt>filter</tt> clause takes an array constant as 6429 its argument. Use "<tt>[0 x i8**] undef</tt>" for a filter which cannot 6430 throw. The '<tt>landingpad</tt>' instruction must contain <em>at least</em> 6431 one <tt>clause</tt> or the <tt>cleanup</tt> flag.</p> 6432 6433<h5>Semantics:</h5> 6434<p>The '<tt>landingpad</tt>' instruction defines the values which are set by the 6435 personality function (<tt>pers_fn</tt>) upon re-entry to the function, and 6436 therefore the "result type" of the <tt>landingpad</tt> instruction. As with 6437 calling conventions, how the personality function results are represented in 6438 LLVM IR is target specific.</p> 6439 6440<p>The clauses are applied in order from top to bottom. If two 6441 <tt>landingpad</tt> instructions are merged together through inlining, the 6442 clauses from the calling function are appended to the list of clauses. 6443 When the call stack is being unwound due to an exception being thrown, the 6444 exception is compared against each <tt>clause</tt> in turn. If it doesn't 6445 match any of the clauses, and the <tt>cleanup</tt> flag is not set, then 6446 unwinding continues further up the call stack.</p> 6447 6448<p>The <tt>landingpad</tt> instruction has several restrictions:</p> 6449 6450<ul> 6451 <li>A landing pad block is a basic block which is the unwind destination of an 6452 '<tt>invoke</tt>' instruction.</li> 6453 <li>A landing pad block must have a '<tt>landingpad</tt>' instruction as its 6454 first non-PHI instruction.</li> 6455 <li>There can be only one '<tt>landingpad</tt>' instruction within the landing 6456 pad block.</li> 6457 <li>A basic block that is not a landing pad block may not include a 6458 '<tt>landingpad</tt>' instruction.</li> 6459 <li>All '<tt>landingpad</tt>' instructions in a function must have the same 6460 personality function.</li> 6461</ul> 6462 6463<h5>Example:</h5> 6464<pre> 6465 ;; A landing pad which can catch an integer. 6466 %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 6467 catch i8** @_ZTIi 6468 ;; A landing pad that is a cleanup. 6469 %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 6470 cleanup 6471 ;; A landing pad which can catch an integer and can only throw a double. 6472 %res = landingpad { i8*, i32 } personality i32 (...)* @__gxx_personality_v0 6473 catch i8** @_ZTIi 6474 filter [1 x i8**] [@_ZTId] 6475</pre> 6476 6477</div> 6478 6479</div> 6480 6481</div> 6482 6483<!-- *********************************************************************** --> 6484<h2><a name="intrinsics">Intrinsic Functions</a></h2> 6485<!-- *********************************************************************** --> 6486 6487<div> 6488 6489<p>LLVM supports the notion of an "intrinsic function". These functions have 6490 well known names and semantics and are required to follow certain 6491 restrictions. Overall, these intrinsics represent an extension mechanism for 6492 the LLVM language that does not require changing all of the transformations 6493 in LLVM when adding to the language (or the bitcode reader/writer, the 6494 parser, etc...).</p> 6495 6496<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This 6497 prefix is reserved in LLVM for intrinsic names; thus, function names may not 6498 begin with this prefix. Intrinsic functions must always be external 6499 functions: you cannot define the body of intrinsic functions. Intrinsic 6500 functions may only be used in call or invoke instructions: it is illegal to 6501 take the address of an intrinsic function. Additionally, because intrinsic 6502 functions are part of the LLVM language, it is required if any are added that 6503 they be documented here.</p> 6504 6505<p>Some intrinsic functions can be overloaded, i.e., the intrinsic represents a 6506 family of functions that perform the same operation but on different data 6507 types. Because LLVM can represent over 8 million different integer types, 6508 overloading is used commonly to allow an intrinsic function to operate on any 6509 integer type. One or more of the argument types or the result type can be 6510 overloaded to accept any integer type. Argument types may also be defined as 6511 exactly matching a previous argument's type or the result type. This allows 6512 an intrinsic function which accepts multiple arguments, but needs all of them 6513 to be of the same type, to only be overloaded with respect to a single 6514 argument or the result.</p> 6515 6516<p>Overloaded intrinsics will have the names of its overloaded argument types 6517 encoded into its function name, each preceded by a period. Only those types 6518 which are overloaded result in a name suffix. Arguments whose type is matched 6519 against another type do not. For example, the <tt>llvm.ctpop</tt> function 6520 can take an integer of any width and returns an integer of exactly the same 6521 integer width. This leads to a family of functions such as 6522 <tt>i8 @llvm.ctpop.i8(i8 %val)</tt> and <tt>i29 @llvm.ctpop.i29(i29 6523 %val)</tt>. Only one type, the return type, is overloaded, and only one type 6524 suffix is required. Because the argument's type is matched against the return 6525 type, it does not require its own name suffix.</p> 6526 6527<p>To learn how to add an intrinsic function, please see the 6528 <a href="ExtendingLLVM.html">Extending LLVM Guide</a>.</p> 6529 6530<!-- ======================================================================= --> 6531<h3> 6532 <a name="int_varargs">Variable Argument Handling Intrinsics</a> 6533</h3> 6534 6535<div> 6536 6537<p>Variable argument support is defined in LLVM with 6538 the <a href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three 6539 intrinsic functions. These functions are related to the similarly named 6540 macros defined in the <tt><stdarg.h></tt> header file.</p> 6541 6542<p>All of these functions operate on arguments that use a target-specific value 6543 type "<tt>va_list</tt>". The LLVM assembly language reference manual does 6544 not define what this type is, so all transformations should be prepared to 6545 handle these functions regardless of the type used.</p> 6546 6547<p>This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a> 6548 instruction and the variable argument handling intrinsic functions are 6549 used.</p> 6550 6551<pre class="doc_code"> 6552define i32 @test(i32 %X, ...) { 6553 ; Initialize variable argument processing 6554 %ap = alloca i8* 6555 %ap2 = bitcast i8** %ap to i8* 6556 call void @llvm.va_start(i8* %ap2) 6557 6558 ; Read a single integer argument 6559 %tmp = va_arg i8** %ap, i32 6560 6561 ; Demonstrate usage of llvm.va_copy and llvm.va_end 6562 %aq = alloca i8* 6563 %aq2 = bitcast i8** %aq to i8* 6564 call void @llvm.va_copy(i8* %aq2, i8* %ap2) 6565 call void @llvm.va_end(i8* %aq2) 6566 6567 ; Stop processing of arguments. 6568 call void @llvm.va_end(i8* %ap2) 6569 ret i32 %tmp 6570} 6571 6572declare void @llvm.va_start(i8*) 6573declare void @llvm.va_copy(i8*, i8*) 6574declare void @llvm.va_end(i8*) 6575</pre> 6576 6577<!-- _______________________________________________________________________ --> 6578<h4> 6579 <a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a> 6580</h4> 6581 6582 6583<div> 6584 6585<h5>Syntax:</h5> 6586<pre> 6587 declare void %llvm.va_start(i8* <arglist>) 6588</pre> 6589 6590<h5>Overview:</h5> 6591<p>The '<tt>llvm.va_start</tt>' intrinsic initializes <tt>*<arglist></tt> 6592 for subsequent use by <tt><a href="#i_va_arg">va_arg</a></tt>.</p> 6593 6594<h5>Arguments:</h5> 6595<p>The argument is a pointer to a <tt>va_list</tt> element to initialize.</p> 6596 6597<h5>Semantics:</h5> 6598<p>The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt> 6599 macro available in C. In a target-dependent way, it initializes 6600 the <tt>va_list</tt> element to which the argument points, so that the next 6601 call to <tt>va_arg</tt> will produce the first variable argument passed to 6602 the function. Unlike the C <tt>va_start</tt> macro, this intrinsic does not 6603 need to know the last argument of the function as the compiler can figure 6604 that out.</p> 6605 6606</div> 6607 6608<!-- _______________________________________________________________________ --> 6609<h4> 6610 <a name="int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a> 6611</h4> 6612 6613<div> 6614 6615<h5>Syntax:</h5> 6616<pre> 6617 declare void @llvm.va_end(i8* <arglist>) 6618</pre> 6619 6620<h5>Overview:</h5> 6621<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></tt>, 6622 which has been initialized previously 6623 with <tt><a href="#int_va_start">llvm.va_start</a></tt> 6624 or <tt><a href="#i_va_copy">llvm.va_copy</a></tt>.</p> 6625 6626<h5>Arguments:</h5> 6627<p>The argument is a pointer to a <tt>va_list</tt> to destroy.</p> 6628 6629<h5>Semantics:</h5> 6630<p>The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt> 6631 macro available in C. In a target-dependent way, it destroys 6632 the <tt>va_list</tt> element to which the argument points. Calls 6633 to <a href="#int_va_start"><tt>llvm.va_start</tt></a> 6634 and <a href="#int_va_copy"> <tt>llvm.va_copy</tt></a> must be matched exactly 6635 with calls to <tt>llvm.va_end</tt>.</p> 6636 6637</div> 6638 6639<!-- _______________________________________________________________________ --> 6640<h4> 6641 <a name="int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a> 6642</h4> 6643 6644<div> 6645 6646<h5>Syntax:</h5> 6647<pre> 6648 declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>) 6649</pre> 6650 6651<h5>Overview:</h5> 6652<p>The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position 6653 from the source argument list to the destination argument list.</p> 6654 6655<h5>Arguments:</h5> 6656<p>The first argument is a pointer to a <tt>va_list</tt> element to initialize. 6657 The second argument is a pointer to a <tt>va_list</tt> element to copy 6658 from.</p> 6659 6660<h5>Semantics:</h5> 6661<p>The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt> 6662 macro available in C. In a target-dependent way, it copies the 6663 source <tt>va_list</tt> element into the destination <tt>va_list</tt> 6664 element. This intrinsic is necessary because 6665 the <tt><a href="#int_va_start"> llvm.va_start</a></tt> intrinsic may be 6666 arbitrarily complex and require, for example, memory allocation.</p> 6667 6668</div> 6669 6670</div> 6671 6672<!-- ======================================================================= --> 6673<h3> 6674 <a name="int_gc">Accurate Garbage Collection Intrinsics</a> 6675</h3> 6676 6677<div> 6678 6679<p>LLVM support for <a href="GarbageCollection.html">Accurate Garbage 6680Collection</a> (GC) requires the implementation and generation of these 6681intrinsics. These intrinsics allow identification of <a href="#int_gcroot">GC 6682roots on the stack</a>, as well as garbage collector implementations that 6683require <a href="#int_gcread">read</a> and <a href="#int_gcwrite">write</a> 6684barriers. Front-ends for type-safe garbage collected languages should generate 6685these intrinsics to make use of the LLVM garbage collectors. For more details, 6686see <a href="GarbageCollection.html">Accurate Garbage Collection with 6687LLVM</a>.</p> 6688 6689<p>The garbage collection intrinsics only operate on objects in the generic 6690 address space (address space zero).</p> 6691 6692<!-- _______________________________________________________________________ --> 6693<h4> 6694 <a name="int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a> 6695</h4> 6696 6697<div> 6698 6699<h5>Syntax:</h5> 6700<pre> 6701 declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) 6702</pre> 6703 6704<h5>Overview:</h5> 6705<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to 6706 the code generator, and allows some metadata to be associated with it.</p> 6707 6708<h5>Arguments:</h5> 6709<p>The first argument specifies the address of a stack object that contains the 6710 root pointer. The second pointer (which must be either a constant or a 6711 global value address) contains the meta-data to be associated with the 6712 root.</p> 6713 6714<h5>Semantics:</h5> 6715<p>At runtime, a call to this intrinsic stores a null pointer into the "ptrloc" 6716 location. At compile-time, the code generator generates information to allow 6717 the runtime to find the pointer at GC safe points. The '<tt>llvm.gcroot</tt>' 6718 intrinsic may only be used in a function which <a href="#gc">specifies a GC 6719 algorithm</a>.</p> 6720 6721</div> 6722 6723<!-- _______________________________________________________________________ --> 6724<h4> 6725 <a name="int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a> 6726</h4> 6727 6728<div> 6729 6730<h5>Syntax:</h5> 6731<pre> 6732 declare i8* @llvm.gcread(i8* %ObjPtr, i8** %Ptr) 6733</pre> 6734 6735<h5>Overview:</h5> 6736<p>The '<tt>llvm.gcread</tt>' intrinsic identifies reads of references from heap 6737 locations, allowing garbage collector implementations that require read 6738 barriers.</p> 6739 6740<h5>Arguments:</h5> 6741<p>The second argument is the address to read from, which should be an address 6742 allocated from the garbage collector. The first object is a pointer to the 6743 start of the referenced object, if needed by the language runtime (otherwise 6744 null).</p> 6745 6746<h5>Semantics:</h5> 6747<p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load 6748 instruction, but may be replaced with substantially more complex code by the 6749 garbage collector runtime, as needed. The '<tt>llvm.gcread</tt>' intrinsic 6750 may only be used in a function which <a href="#gc">specifies a GC 6751 algorithm</a>.</p> 6752 6753</div> 6754 6755<!-- _______________________________________________________________________ --> 6756<h4> 6757 <a name="int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a> 6758</h4> 6759 6760<div> 6761 6762<h5>Syntax:</h5> 6763<pre> 6764 declare void @llvm.gcwrite(i8* %P1, i8* %Obj, i8** %P2) 6765</pre> 6766 6767<h5>Overview:</h5> 6768<p>The '<tt>llvm.gcwrite</tt>' intrinsic identifies writes of references to heap 6769 locations, allowing garbage collector implementations that require write 6770 barriers (such as generational or reference counting collectors).</p> 6771 6772<h5>Arguments:</h5> 6773<p>The first argument is the reference to store, the second is the start of the 6774 object to store it to, and the third is the address of the field of Obj to 6775 store to. If the runtime does not require a pointer to the object, Obj may 6776 be null.</p> 6777 6778<h5>Semantics:</h5> 6779<p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store 6780 instruction, but may be replaced with substantially more complex code by the 6781 garbage collector runtime, as needed. The '<tt>llvm.gcwrite</tt>' intrinsic 6782 may only be used in a function which <a href="#gc">specifies a GC 6783 algorithm</a>.</p> 6784 6785</div> 6786 6787</div> 6788 6789<!-- ======================================================================= --> 6790<h3> 6791 <a name="int_codegen">Code Generator Intrinsics</a> 6792</h3> 6793 6794<div> 6795 6796<p>These intrinsics are provided by LLVM to expose special features that may 6797 only be implemented with code generator support.</p> 6798 6799<!-- _______________________________________________________________________ --> 6800<h4> 6801 <a name="int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a> 6802</h4> 6803 6804<div> 6805 6806<h5>Syntax:</h5> 6807<pre> 6808 declare i8 *@llvm.returnaddress(i32 <level>) 6809</pre> 6810 6811<h5>Overview:</h5> 6812<p>The '<tt>llvm.returnaddress</tt>' intrinsic attempts to compute a 6813 target-specific value indicating the return address of the current function 6814 or one of its callers.</p> 6815 6816<h5>Arguments:</h5> 6817<p>The argument to this intrinsic indicates which function to return the address 6818 for. Zero indicates the calling function, one indicates its caller, etc. 6819 The argument is <b>required</b> to be a constant integer value.</p> 6820 6821<h5>Semantics:</h5> 6822<p>The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer 6823 indicating the return address of the specified call frame, or zero if it 6824 cannot be identified. The value returned by this intrinsic is likely to be 6825 incorrect or 0 for arguments other than zero, so it should only be used for 6826 debugging purposes.</p> 6827 6828<p>Note that calling this intrinsic does not prevent function inlining or other 6829 aggressive transformations, so the value returned may not be that of the 6830 obvious source-language caller.</p> 6831 6832</div> 6833 6834<!-- _______________________________________________________________________ --> 6835<h4> 6836 <a name="int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a> 6837</h4> 6838 6839<div> 6840 6841<h5>Syntax:</h5> 6842<pre> 6843 declare i8* @llvm.frameaddress(i32 <level>) 6844</pre> 6845 6846<h5>Overview:</h5> 6847<p>The '<tt>llvm.frameaddress</tt>' intrinsic attempts to return the 6848 target-specific frame pointer value for the specified stack frame.</p> 6849 6850<h5>Arguments:</h5> 6851<p>The argument to this intrinsic indicates which function to return the frame 6852 pointer for. Zero indicates the calling function, one indicates its caller, 6853 etc. The argument is <b>required</b> to be a constant integer value.</p> 6854 6855<h5>Semantics:</h5> 6856<p>The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer 6857 indicating the frame address of the specified call frame, or zero if it 6858 cannot be identified. The value returned by this intrinsic is likely to be 6859 incorrect or 0 for arguments other than zero, so it should only be used for 6860 debugging purposes.</p> 6861 6862<p>Note that calling this intrinsic does not prevent function inlining or other 6863 aggressive transformations, so the value returned may not be that of the 6864 obvious source-language caller.</p> 6865 6866</div> 6867 6868<!-- _______________________________________________________________________ --> 6869<h4> 6870 <a name="int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a> 6871</h4> 6872 6873<div> 6874 6875<h5>Syntax:</h5> 6876<pre> 6877 declare i8* @llvm.stacksave() 6878</pre> 6879 6880<h5>Overview:</h5> 6881<p>The '<tt>llvm.stacksave</tt>' intrinsic is used to remember the current state 6882 of the function stack, for use 6883 with <a href="#int_stackrestore"> <tt>llvm.stackrestore</tt></a>. This is 6884 useful for implementing language features like scoped automatic variable 6885 sized arrays in C99.</p> 6886 6887<h5>Semantics:</h5> 6888<p>This intrinsic returns a opaque pointer value that can be passed 6889 to <a href="#int_stackrestore"><tt>llvm.stackrestore</tt></a>. When 6890 an <tt>llvm.stackrestore</tt> intrinsic is executed with a value saved 6891 from <tt>llvm.stacksave</tt>, it effectively restores the state of the stack 6892 to the state it was in when the <tt>llvm.stacksave</tt> intrinsic executed. 6893 In practice, this pops any <a href="#i_alloca">alloca</a> blocks from the 6894 stack that were allocated after the <tt>llvm.stacksave</tt> was executed.</p> 6895 6896</div> 6897 6898<!-- _______________________________________________________________________ --> 6899<h4> 6900 <a name="int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a> 6901</h4> 6902 6903<div> 6904 6905<h5>Syntax:</h5> 6906<pre> 6907 declare void @llvm.stackrestore(i8* %ptr) 6908</pre> 6909 6910<h5>Overview:</h5> 6911<p>The '<tt>llvm.stackrestore</tt>' intrinsic is used to restore the state of 6912 the function stack to the state it was in when the 6913 corresponding <a href="#int_stacksave"><tt>llvm.stacksave</tt></a> intrinsic 6914 executed. This is useful for implementing language features like scoped 6915 automatic variable sized arrays in C99.</p> 6916 6917<h5>Semantics:</h5> 6918<p>See the description 6919 for <a href="#int_stacksave"><tt>llvm.stacksave</tt></a>.</p> 6920 6921</div> 6922 6923<!-- _______________________________________________________________________ --> 6924<h4> 6925 <a name="int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a> 6926</h4> 6927 6928<div> 6929 6930<h5>Syntax:</h5> 6931<pre> 6932 declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) 6933</pre> 6934 6935<h5>Overview:</h5> 6936<p>The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to 6937 insert a prefetch instruction if supported; otherwise, it is a noop. 6938 Prefetches have no effect on the behavior of the program but can change its 6939 performance characteristics.</p> 6940 6941<h5>Arguments:</h5> 6942<p><tt>address</tt> is the address to be prefetched, <tt>rw</tt> is the 6943 specifier determining if the fetch should be for a read (0) or write (1), 6944 and <tt>locality</tt> is a temporal locality specifier ranging from (0) - no 6945 locality, to (3) - extremely local keep in cache. The <tt>cache type</tt> 6946 specifies whether the prefetch is performed on the data (1) or instruction (0) 6947 cache. The <tt>rw</tt>, <tt>locality</tt> and <tt>cache type</tt> arguments 6948 must be constant integers.</p> 6949 6950<h5>Semantics:</h5> 6951<p>This intrinsic does not modify the behavior of the program. In particular, 6952 prefetches cannot trap and do not produce a value. On targets that support 6953 this intrinsic, the prefetch can provide hints to the processor cache for 6954 better performance.</p> 6955 6956</div> 6957 6958<!-- _______________________________________________________________________ --> 6959<h4> 6960 <a name="int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a> 6961</h4> 6962 6963<div> 6964 6965<h5>Syntax:</h5> 6966<pre> 6967 declare void @llvm.pcmarker(i32 <id>) 6968</pre> 6969 6970<h5>Overview:</h5> 6971<p>The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a Program 6972 Counter (PC) in a region of code to simulators and other tools. The method 6973 is target specific, but it is expected that the marker will use exported 6974 symbols to transmit the PC of the marker. The marker makes no guarantees 6975 that it will remain with any specific instruction after optimizations. It is 6976 possible that the presence of a marker will inhibit optimizations. The 6977 intended use is to be inserted after optimizations to allow correlations of 6978 simulation runs.</p> 6979 6980<h5>Arguments:</h5> 6981<p><tt>id</tt> is a numerical id identifying the marker.</p> 6982 6983<h5>Semantics:</h5> 6984<p>This intrinsic does not modify the behavior of the program. Backends that do 6985 not support this intrinsic may ignore it.</p> 6986 6987</div> 6988 6989<!-- _______________________________________________________________________ --> 6990<h4> 6991 <a name="int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a> 6992</h4> 6993 6994<div> 6995 6996<h5>Syntax:</h5> 6997<pre> 6998 declare i64 @llvm.readcyclecounter() 6999</pre> 7000 7001<h5>Overview:</h5> 7002<p>The '<tt>llvm.readcyclecounter</tt>' intrinsic provides access to the cycle 7003 counter register (or similar low latency, high accuracy clocks) on those 7004 targets that support it. On X86, it should map to RDTSC. On Alpha, it 7005 should map to RPCC. As the backing counters overflow quickly (on the order 7006 of 9 seconds on alpha), this should only be used for small timings.</p> 7007 7008<h5>Semantics:</h5> 7009<p>When directly supported, reading the cycle counter should not modify any 7010 memory. Implementations are allowed to either return a application specific 7011 value or a system wide value. On backends without support, this is lowered 7012 to a constant 0.</p> 7013 7014</div> 7015 7016</div> 7017 7018<!-- ======================================================================= --> 7019<h3> 7020 <a name="int_libc">Standard C Library Intrinsics</a> 7021</h3> 7022 7023<div> 7024 7025<p>LLVM provides intrinsics for a few important standard C library functions. 7026 These intrinsics allow source-language front-ends to pass information about 7027 the alignment of the pointer arguments to the code generator, providing 7028 opportunity for more efficient code generation.</p> 7029 7030<!-- _______________________________________________________________________ --> 7031<h4> 7032 <a name="int_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a> 7033</h4> 7034 7035<div> 7036 7037<h5>Syntax:</h5> 7038<p>This is an overloaded intrinsic. You can use <tt>llvm.memcpy</tt> on any 7039 integer bit width and for different address spaces. Not all targets support 7040 all bit widths however.</p> 7041 7042<pre> 7043 declare void @llvm.memcpy.p0i8.p0i8.i32(i8* <dest>, i8* <src>, 7044 i32 <len>, i32 <align>, i1 <isvolatile>) 7045 declare void @llvm.memcpy.p0i8.p0i8.i64(i8* <dest>, i8* <src>, 7046 i64 <len>, i32 <align>, i1 <isvolatile>) 7047</pre> 7048 7049<h5>Overview:</h5> 7050<p>The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the 7051 source location to the destination location.</p> 7052 7053<p>Note that, unlike the standard libc function, the <tt>llvm.memcpy.*</tt> 7054 intrinsics do not return a value, takes extra alignment/isvolatile arguments 7055 and the pointers can be in specified address spaces.</p> 7056 7057<h5>Arguments:</h5> 7058 7059<p>The first argument is a pointer to the destination, the second is a pointer 7060 to the source. The third argument is an integer argument specifying the 7061 number of bytes to copy, the fourth argument is the alignment of the 7062 source and destination locations, and the fifth is a boolean indicating a 7063 volatile access.</p> 7064 7065<p>If the call to this intrinsic has an alignment value that is not 0 or 1, 7066 then the caller guarantees that both the source and destination pointers are 7067 aligned to that boundary.</p> 7068 7069<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the 7070 <tt>llvm.memcpy</tt> call is a <a href="#volatile">volatile operation</a>. 7071 The detailed access behavior is not very cleanly specified and it is unwise 7072 to depend on it.</p> 7073 7074<h5>Semantics:</h5> 7075 7076<p>The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the 7077 source location to the destination location, which are not allowed to 7078 overlap. It copies "len" bytes of memory over. If the argument is known to 7079 be aligned to some boundary, this can be specified as the fourth argument, 7080 otherwise it should be set to 0 or 1.</p> 7081 7082</div> 7083 7084<!-- _______________________________________________________________________ --> 7085<h4> 7086 <a name="int_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a> 7087</h4> 7088 7089<div> 7090 7091<h5>Syntax:</h5> 7092<p>This is an overloaded intrinsic. You can use llvm.memmove on any integer bit 7093 width and for different address space. Not all targets support all bit 7094 widths however.</p> 7095 7096<pre> 7097 declare void @llvm.memmove.p0i8.p0i8.i32(i8* <dest>, i8* <src>, 7098 i32 <len>, i32 <align>, i1 <isvolatile>) 7099 declare void @llvm.memmove.p0i8.p0i8.i64(i8* <dest>, i8* <src>, 7100 i64 <len>, i32 <align>, i1 <isvolatile>) 7101</pre> 7102 7103<h5>Overview:</h5> 7104<p>The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the 7105 source location to the destination location. It is similar to the 7106 '<tt>llvm.memcpy</tt>' intrinsic but allows the two memory locations to 7107 overlap.</p> 7108 7109<p>Note that, unlike the standard libc function, the <tt>llvm.memmove.*</tt> 7110 intrinsics do not return a value, takes extra alignment/isvolatile arguments 7111 and the pointers can be in specified address spaces.</p> 7112 7113<h5>Arguments:</h5> 7114 7115<p>The first argument is a pointer to the destination, the second is a pointer 7116 to the source. The third argument is an integer argument specifying the 7117 number of bytes to copy, the fourth argument is the alignment of the 7118 source and destination locations, and the fifth is a boolean indicating a 7119 volatile access.</p> 7120 7121<p>If the call to this intrinsic has an alignment value that is not 0 or 1, 7122 then the caller guarantees that the source and destination pointers are 7123 aligned to that boundary.</p> 7124 7125<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the 7126 <tt>llvm.memmove</tt> call is a <a href="#volatile">volatile operation</a>. 7127 The detailed access behavior is not very cleanly specified and it is unwise 7128 to depend on it.</p> 7129 7130<h5>Semantics:</h5> 7131 7132<p>The '<tt>llvm.memmove.*</tt>' intrinsics copy a block of memory from the 7133 source location to the destination location, which may overlap. It copies 7134 "len" bytes of memory over. If the argument is known to be aligned to some 7135 boundary, this can be specified as the fourth argument, otherwise it should 7136 be set to 0 or 1.</p> 7137 7138</div> 7139 7140<!-- _______________________________________________________________________ --> 7141<h4> 7142 <a name="int_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a> 7143</h4> 7144 7145<div> 7146 7147<h5>Syntax:</h5> 7148<p>This is an overloaded intrinsic. You can use llvm.memset on any integer bit 7149 width and for different address spaces. However, not all targets support all 7150 bit widths.</p> 7151 7152<pre> 7153 declare void @llvm.memset.p0i8.i32(i8* <dest>, i8 <val>, 7154 i32 <len>, i32 <align>, i1 <isvolatile>) 7155 declare void @llvm.memset.p0i8.i64(i8* <dest>, i8 <val>, 7156 i64 <len>, i32 <align>, i1 <isvolatile>) 7157</pre> 7158 7159<h5>Overview:</h5> 7160<p>The '<tt>llvm.memset.*</tt>' intrinsics fill a block of memory with a 7161 particular byte value.</p> 7162 7163<p>Note that, unlike the standard libc function, the <tt>llvm.memset</tt> 7164 intrinsic does not return a value and takes extra alignment/volatile 7165 arguments. Also, the destination can be in an arbitrary address space.</p> 7166 7167<h5>Arguments:</h5> 7168<p>The first argument is a pointer to the destination to fill, the second is the 7169 byte value with which to fill it, the third argument is an integer argument 7170 specifying the number of bytes to fill, and the fourth argument is the known 7171 alignment of the destination location.</p> 7172 7173<p>If the call to this intrinsic has an alignment value that is not 0 or 1, 7174 then the caller guarantees that the destination pointer is aligned to that 7175 boundary.</p> 7176 7177<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the 7178 <tt>llvm.memset</tt> call is a <a href="#volatile">volatile operation</a>. 7179 The detailed access behavior is not very cleanly specified and it is unwise 7180 to depend on it.</p> 7181 7182<h5>Semantics:</h5> 7183<p>The '<tt>llvm.memset.*</tt>' intrinsics fill "len" bytes of memory starting 7184 at the destination location. If the argument is known to be aligned to some 7185 boundary, this can be specified as the fourth argument, otherwise it should 7186 be set to 0 or 1.</p> 7187 7188</div> 7189 7190<!-- _______________________________________________________________________ --> 7191<h4> 7192 <a name="int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a> 7193</h4> 7194 7195<div> 7196 7197<h5>Syntax:</h5> 7198<p>This is an overloaded intrinsic. You can use <tt>llvm.sqrt</tt> on any 7199 floating point or vector of floating point type. Not all targets support all 7200 types however.</p> 7201 7202<pre> 7203 declare float @llvm.sqrt.f32(float %Val) 7204 declare double @llvm.sqrt.f64(double %Val) 7205 declare x86_fp80 @llvm.sqrt.f80(x86_fp80 %Val) 7206 declare fp128 @llvm.sqrt.f128(fp128 %Val) 7207 declare ppc_fp128 @llvm.sqrt.ppcf128(ppc_fp128 %Val) 7208</pre> 7209 7210<h5>Overview:</h5> 7211<p>The '<tt>llvm.sqrt</tt>' intrinsics return the sqrt of the specified operand, 7212 returning the same value as the libm '<tt>sqrt</tt>' functions would. 7213 Unlike <tt>sqrt</tt> in libm, however, <tt>llvm.sqrt</tt> has undefined 7214 behavior for negative numbers other than -0.0 (which allows for better 7215 optimization, because there is no need to worry about errno being 7216 set). <tt>llvm.sqrt(-0.0)</tt> is defined to return -0.0 like IEEE sqrt.</p> 7217 7218<h5>Arguments:</h5> 7219<p>The argument and return value are floating point numbers of the same 7220 type.</p> 7221 7222<h5>Semantics:</h5> 7223<p>This function returns the sqrt of the specified operand if it is a 7224 nonnegative floating point number.</p> 7225 7226</div> 7227 7228<!-- _______________________________________________________________________ --> 7229<h4> 7230 <a name="int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a> 7231</h4> 7232 7233<div> 7234 7235<h5>Syntax:</h5> 7236<p>This is an overloaded intrinsic. You can use <tt>llvm.powi</tt> on any 7237 floating point or vector of floating point type. Not all targets support all 7238 types however.</p> 7239 7240<pre> 7241 declare float @llvm.powi.f32(float %Val, i32 %power) 7242 declare double @llvm.powi.f64(double %Val, i32 %power) 7243 declare x86_fp80 @llvm.powi.f80(x86_fp80 %Val, i32 %power) 7244 declare fp128 @llvm.powi.f128(fp128 %Val, i32 %power) 7245 declare ppc_fp128 @llvm.powi.ppcf128(ppc_fp128 %Val, i32 %power) 7246</pre> 7247 7248<h5>Overview:</h5> 7249<p>The '<tt>llvm.powi.*</tt>' intrinsics return the first operand raised to the 7250 specified (positive or negative) power. The order of evaluation of 7251 multiplications is not defined. When a vector of floating point type is 7252 used, the second argument remains a scalar integer value.</p> 7253 7254<h5>Arguments:</h5> 7255<p>The second argument is an integer power, and the first is a value to raise to 7256 that power.</p> 7257 7258<h5>Semantics:</h5> 7259<p>This function returns the first value raised to the second power with an 7260 unspecified sequence of rounding operations.</p> 7261 7262</div> 7263 7264<!-- _______________________________________________________________________ --> 7265<h4> 7266 <a name="int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a> 7267</h4> 7268 7269<div> 7270 7271<h5>Syntax:</h5> 7272<p>This is an overloaded intrinsic. You can use <tt>llvm.sin</tt> on any 7273 floating point or vector of floating point type. Not all targets support all 7274 types however.</p> 7275 7276<pre> 7277 declare float @llvm.sin.f32(float %Val) 7278 declare double @llvm.sin.f64(double %Val) 7279 declare x86_fp80 @llvm.sin.f80(x86_fp80 %Val) 7280 declare fp128 @llvm.sin.f128(fp128 %Val) 7281 declare ppc_fp128 @llvm.sin.ppcf128(ppc_fp128 %Val) 7282</pre> 7283 7284<h5>Overview:</h5> 7285<p>The '<tt>llvm.sin.*</tt>' intrinsics return the sine of the operand.</p> 7286 7287<h5>Arguments:</h5> 7288<p>The argument and return value are floating point numbers of the same 7289 type.</p> 7290 7291<h5>Semantics:</h5> 7292<p>This function returns the sine of the specified operand, returning the same 7293 values as the libm <tt>sin</tt> functions would, and handles error conditions 7294 in the same way.</p> 7295 7296</div> 7297 7298<!-- _______________________________________________________________________ --> 7299<h4> 7300 <a name="int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a> 7301</h4> 7302 7303<div> 7304 7305<h5>Syntax:</h5> 7306<p>This is an overloaded intrinsic. You can use <tt>llvm.cos</tt> on any 7307 floating point or vector of floating point type. Not all targets support all 7308 types however.</p> 7309 7310<pre> 7311 declare float @llvm.cos.f32(float %Val) 7312 declare double @llvm.cos.f64(double %Val) 7313 declare x86_fp80 @llvm.cos.f80(x86_fp80 %Val) 7314 declare fp128 @llvm.cos.f128(fp128 %Val) 7315 declare ppc_fp128 @llvm.cos.ppcf128(ppc_fp128 %Val) 7316</pre> 7317 7318<h5>Overview:</h5> 7319<p>The '<tt>llvm.cos.*</tt>' intrinsics return the cosine of the operand.</p> 7320 7321<h5>Arguments:</h5> 7322<p>The argument and return value are floating point numbers of the same 7323 type.</p> 7324 7325<h5>Semantics:</h5> 7326<p>This function returns the cosine of the specified operand, returning the same 7327 values as the libm <tt>cos</tt> functions would, and handles error conditions 7328 in the same way.</p> 7329 7330</div> 7331 7332<!-- _______________________________________________________________________ --> 7333<h4> 7334 <a name="int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a> 7335</h4> 7336 7337<div> 7338 7339<h5>Syntax:</h5> 7340<p>This is an overloaded intrinsic. You can use <tt>llvm.pow</tt> on any 7341 floating point or vector of floating point type. Not all targets support all 7342 types however.</p> 7343 7344<pre> 7345 declare float @llvm.pow.f32(float %Val, float %Power) 7346 declare double @llvm.pow.f64(double %Val, double %Power) 7347 declare x86_fp80 @llvm.pow.f80(x86_fp80 %Val, x86_fp80 %Power) 7348 declare fp128 @llvm.pow.f128(fp128 %Val, fp128 %Power) 7349 declare ppc_fp128 @llvm.pow.ppcf128(ppc_fp128 %Val, ppc_fp128 Power) 7350</pre> 7351 7352<h5>Overview:</h5> 7353<p>The '<tt>llvm.pow.*</tt>' intrinsics return the first operand raised to the 7354 specified (positive or negative) power.</p> 7355 7356<h5>Arguments:</h5> 7357<p>The second argument is a floating point power, and the first is a value to 7358 raise to that power.</p> 7359 7360<h5>Semantics:</h5> 7361<p>This function returns the first value raised to the second power, returning 7362 the same values as the libm <tt>pow</tt> functions would, and handles error 7363 conditions in the same way.</p> 7364 7365</div> 7366 7367<!-- _______________________________________________________________________ --> 7368<h4> 7369 <a name="int_exp">'<tt>llvm.exp.*</tt>' Intrinsic</a> 7370</h4> 7371 7372<div> 7373 7374<h5>Syntax:</h5> 7375<p>This is an overloaded intrinsic. You can use <tt>llvm.exp</tt> on any 7376 floating point or vector of floating point type. Not all targets support all 7377 types however.</p> 7378 7379<pre> 7380 declare float @llvm.exp.f32(float %Val) 7381 declare double @llvm.exp.f64(double %Val) 7382 declare x86_fp80 @llvm.exp.f80(x86_fp80 %Val) 7383 declare fp128 @llvm.exp.f128(fp128 %Val) 7384 declare ppc_fp128 @llvm.exp.ppcf128(ppc_fp128 %Val) 7385</pre> 7386 7387<h5>Overview:</h5> 7388<p>The '<tt>llvm.exp.*</tt>' intrinsics perform the exp function.</p> 7389 7390<h5>Arguments:</h5> 7391<p>The argument and return value are floating point numbers of the same 7392 type.</p> 7393 7394<h5>Semantics:</h5> 7395<p>This function returns the same values as the libm <tt>exp</tt> functions 7396 would, and handles error conditions in the same way.</p> 7397 7398</div> 7399 7400<!-- _______________________________________________________________________ --> 7401<h4> 7402 <a name="int_log">'<tt>llvm.log.*</tt>' Intrinsic</a> 7403</h4> 7404 7405<div> 7406 7407<h5>Syntax:</h5> 7408<p>This is an overloaded intrinsic. You can use <tt>llvm.log</tt> on any 7409 floating point or vector of floating point type. Not all targets support all 7410 types however.</p> 7411 7412<pre> 7413 declare float @llvm.log.f32(float %Val) 7414 declare double @llvm.log.f64(double %Val) 7415 declare x86_fp80 @llvm.log.f80(x86_fp80 %Val) 7416 declare fp128 @llvm.log.f128(fp128 %Val) 7417 declare ppc_fp128 @llvm.log.ppcf128(ppc_fp128 %Val) 7418</pre> 7419 7420<h5>Overview:</h5> 7421<p>The '<tt>llvm.log.*</tt>' intrinsics perform the log function.</p> 7422 7423<h5>Arguments:</h5> 7424<p>The argument and return value are floating point numbers of the same 7425 type.</p> 7426 7427<h5>Semantics:</h5> 7428<p>This function returns the same values as the libm <tt>log</tt> functions 7429 would, and handles error conditions in the same way.</p> 7430 7431</div> 7432 7433<!-- _______________________________________________________________________ --> 7434<h4> 7435 <a name="int_fma">'<tt>llvm.fma.*</tt>' Intrinsic</a> 7436</h4> 7437 7438<div> 7439 7440<h5>Syntax:</h5> 7441<p>This is an overloaded intrinsic. You can use <tt>llvm.fma</tt> on any 7442 floating point or vector of floating point type. Not all targets support all 7443 types however.</p> 7444 7445<pre> 7446 declare float @llvm.fma.f32(float %a, float %b, float %c) 7447 declare double @llvm.fma.f64(double %a, double %b, double %c) 7448 declare x86_fp80 @llvm.fma.f80(x86_fp80 %a, x86_fp80 %b, x86_fp80 %c) 7449 declare fp128 @llvm.fma.f128(fp128 %a, fp128 %b, fp128 %c) 7450 declare ppc_fp128 @llvm.fma.ppcf128(ppc_fp128 %a, ppc_fp128 %b, ppc_fp128 %c) 7451</pre> 7452 7453<h5>Overview:</h5> 7454<p>The '<tt>llvm.fma.*</tt>' intrinsics perform the fused multiply-add 7455 operation.</p> 7456 7457<h5>Arguments:</h5> 7458<p>The argument and return value are floating point numbers of the same 7459 type.</p> 7460 7461<h5>Semantics:</h5> 7462<p>This function returns the same values as the libm <tt>fma</tt> functions 7463 would.</p> 7464 7465</div> 7466 7467</div> 7468 7469<!-- ======================================================================= --> 7470<h3> 7471 <a name="int_manip">Bit Manipulation Intrinsics</a> 7472</h3> 7473 7474<div> 7475 7476<p>LLVM provides intrinsics for a few important bit manipulation operations. 7477 These allow efficient code generation for some algorithms.</p> 7478 7479<!-- _______________________________________________________________________ --> 7480<h4> 7481 <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a> 7482</h4> 7483 7484<div> 7485 7486<h5>Syntax:</h5> 7487<p>This is an overloaded intrinsic function. You can use bswap on any integer 7488 type that is an even number of bytes (i.e. BitWidth % 16 == 0).</p> 7489 7490<pre> 7491 declare i16 @llvm.bswap.i16(i16 <id>) 7492 declare i32 @llvm.bswap.i32(i32 <id>) 7493 declare i64 @llvm.bswap.i64(i64 <id>) 7494</pre> 7495 7496<h5>Overview:</h5> 7497<p>The '<tt>llvm.bswap</tt>' family of intrinsics is used to byte swap integer 7498 values with an even number of bytes (positive multiple of 16 bits). These 7499 are useful for performing operations on data that is not in the target's 7500 native byte order.</p> 7501 7502<h5>Semantics:</h5> 7503<p>The <tt>llvm.bswap.i16</tt> intrinsic returns an i16 value that has the high 7504 and low byte of the input i16 swapped. Similarly, 7505 the <tt>llvm.bswap.i32</tt> intrinsic returns an i32 value that has the four 7506 bytes of the input i32 swapped, so that if the input bytes are numbered 0, 1, 7507 2, 3 then the returned i32 will have its bytes in 3, 2, 1, 0 order. 7508 The <tt>llvm.bswap.i48</tt>, <tt>llvm.bswap.i64</tt> and other intrinsics 7509 extend this concept to additional even-byte lengths (6 bytes, 8 bytes and 7510 more, respectively).</p> 7511 7512</div> 7513 7514<!-- _______________________________________________________________________ --> 7515<h4> 7516 <a name="int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic</a> 7517</h4> 7518 7519<div> 7520 7521<h5>Syntax:</h5> 7522<p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit 7523 width, or on any vector with integer elements. Not all targets support all 7524 bit widths or vector types, however.</p> 7525 7526<pre> 7527 declare i8 @llvm.ctpop.i8(i8 <src>) 7528 declare i16 @llvm.ctpop.i16(i16 <src>) 7529 declare i32 @llvm.ctpop.i32(i32 <src>) 7530 declare i64 @llvm.ctpop.i64(i64 <src>) 7531 declare i256 @llvm.ctpop.i256(i256 <src>) 7532 declare <2 x i32> @llvm.ctpop.v2i32(<2 x i32> <src>) 7533</pre> 7534 7535<h5>Overview:</h5> 7536<p>The '<tt>llvm.ctpop</tt>' family of intrinsics counts the number of bits set 7537 in a value.</p> 7538 7539<h5>Arguments:</h5> 7540<p>The only argument is the value to be counted. The argument may be of any 7541 integer type, or a vector with integer elements. 7542 The return type must match the argument type.</p> 7543 7544<h5>Semantics:</h5> 7545<p>The '<tt>llvm.ctpop</tt>' intrinsic counts the 1's in a variable, or within each 7546 element of a vector.</p> 7547 7548</div> 7549 7550<!-- _______________________________________________________________________ --> 7551<h4> 7552 <a name="int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic</a> 7553</h4> 7554 7555<div> 7556 7557<h5>Syntax:</h5> 7558<p>This is an overloaded intrinsic. You can use <tt>llvm.ctlz</tt> on any 7559 integer bit width, or any vector whose elements are integers. Not all 7560 targets support all bit widths or vector types, however.</p> 7561 7562<pre> 7563 declare i8 @llvm.ctlz.i8 (i8 <src>, i1 <is_zero_undef>) 7564 declare i16 @llvm.ctlz.i16 (i16 <src>, i1 <is_zero_undef>) 7565 declare i32 @llvm.ctlz.i32 (i32 <src>, i1 <is_zero_undef>) 7566 declare i64 @llvm.ctlz.i64 (i64 <src>, i1 <is_zero_undef>) 7567 declare i256 @llvm.ctlz.i256(i256 <src>, i1 <is_zero_undef>) 7568 declase <2 x i32> @llvm.ctlz.v2i32(<2 x i32> <src>, i1 <is_zero_undef>) 7569</pre> 7570 7571<h5>Overview:</h5> 7572<p>The '<tt>llvm.ctlz</tt>' family of intrinsic functions counts the number of 7573 leading zeros in a variable.</p> 7574 7575<h5>Arguments:</h5> 7576<p>The first argument is the value to be counted. This argument may be of any 7577 integer type, or a vectory with integer element type. The return type 7578 must match the first argument type.</p> 7579 7580<p>The second argument must be a constant and is a flag to indicate whether the 7581 intrinsic should ensure that a zero as the first argument produces a defined 7582 result. Historically some architectures did not provide a defined result for 7583 zero values as efficiently, and many algorithms are now predicated on 7584 avoiding zero-value inputs.</p> 7585 7586<h5>Semantics:</h5> 7587<p>The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant) 7588 zeros in a variable, or within each element of the vector. 7589 If <tt>src == 0</tt> then the result is the size in bits of the type of 7590 <tt>src</tt> if <tt>is_zero_undef == 0</tt> and <tt>undef</tt> otherwise. 7591 For example, <tt>llvm.ctlz(i32 2) = 30</tt>.</p> 7592 7593</div> 7594 7595<!-- _______________________________________________________________________ --> 7596<h4> 7597 <a name="int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic</a> 7598</h4> 7599 7600<div> 7601 7602<h5>Syntax:</h5> 7603<p>This is an overloaded intrinsic. You can use <tt>llvm.cttz</tt> on any 7604 integer bit width, or any vector of integer elements. Not all targets 7605 support all bit widths or vector types, however.</p> 7606 7607<pre> 7608 declare i8 @llvm.cttz.i8 (i8 <src>, i1 <is_zero_undef>) 7609 declare i16 @llvm.cttz.i16 (i16 <src>, i1 <is_zero_undef>) 7610 declare i32 @llvm.cttz.i32 (i32 <src>, i1 <is_zero_undef>) 7611 declare i64 @llvm.cttz.i64 (i64 <src>, i1 <is_zero_undef>) 7612 declare i256 @llvm.cttz.i256(i256 <src>, i1 <is_zero_undef>) 7613 declase <2 x i32> @llvm.cttz.v2i32(<2 x i32> <src>, i1 <is_zero_undef>) 7614</pre> 7615 7616<h5>Overview:</h5> 7617<p>The '<tt>llvm.cttz</tt>' family of intrinsic functions counts the number of 7618 trailing zeros.</p> 7619 7620<h5>Arguments:</h5> 7621<p>The first argument is the value to be counted. This argument may be of any 7622 integer type, or a vectory with integer element type. The return type 7623 must match the first argument type.</p> 7624 7625<p>The second argument must be a constant and is a flag to indicate whether the 7626 intrinsic should ensure that a zero as the first argument produces a defined 7627 result. Historically some architectures did not provide a defined result for 7628 zero values as efficiently, and many algorithms are now predicated on 7629 avoiding zero-value inputs.</p> 7630 7631<h5>Semantics:</h5> 7632<p>The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant) 7633 zeros in a variable, or within each element of a vector. 7634 If <tt>src == 0</tt> then the result is the size in bits of the type of 7635 <tt>src</tt> if <tt>is_zero_undef == 0</tt> and <tt>undef</tt> otherwise. 7636 For example, <tt>llvm.cttz(2) = 1</tt>.</p> 7637 7638</div> 7639 7640</div> 7641 7642<!-- ======================================================================= --> 7643<h3> 7644 <a name="int_overflow">Arithmetic with Overflow Intrinsics</a> 7645</h3> 7646 7647<div> 7648 7649<p>LLVM provides intrinsics for some arithmetic with overflow operations.</p> 7650 7651<!-- _______________________________________________________________________ --> 7652<h4> 7653 <a name="int_sadd_overflow"> 7654 '<tt>llvm.sadd.with.overflow.*</tt>' Intrinsics 7655 </a> 7656</h4> 7657 7658<div> 7659 7660<h5>Syntax:</h5> 7661<p>This is an overloaded intrinsic. You can use <tt>llvm.sadd.with.overflow</tt> 7662 on any integer bit width.</p> 7663 7664<pre> 7665 declare {i16, i1} @llvm.sadd.with.overflow.i16(i16 %a, i16 %b) 7666 declare {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) 7667 declare {i64, i1} @llvm.sadd.with.overflow.i64(i64 %a, i64 %b) 7668</pre> 7669 7670<h5>Overview:</h5> 7671<p>The '<tt>llvm.sadd.with.overflow</tt>' family of intrinsic functions perform 7672 a signed addition of the two arguments, and indicate whether an overflow 7673 occurred during the signed summation.</p> 7674 7675<h5>Arguments:</h5> 7676<p>The arguments (%a and %b) and the first element of the result structure may 7677 be of integer types of any bit width, but they must have the same bit 7678 width. The second element of the result structure must be of 7679 type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will 7680 undergo signed addition.</p> 7681 7682<h5>Semantics:</h5> 7683<p>The '<tt>llvm.sadd.with.overflow</tt>' family of intrinsic functions perform 7684 a signed addition of the two variables. They return a structure — the 7685 first element of which is the signed summation, and the second element of 7686 which is a bit specifying if the signed summation resulted in an 7687 overflow.</p> 7688 7689<h5>Examples:</h5> 7690<pre> 7691 %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b) 7692 %sum = extractvalue {i32, i1} %res, 0 7693 %obit = extractvalue {i32, i1} %res, 1 7694 br i1 %obit, label %overflow, label %normal 7695</pre> 7696 7697</div> 7698 7699<!-- _______________________________________________________________________ --> 7700<h4> 7701 <a name="int_uadd_overflow"> 7702 '<tt>llvm.uadd.with.overflow.*</tt>' Intrinsics 7703 </a> 7704</h4> 7705 7706<div> 7707 7708<h5>Syntax:</h5> 7709<p>This is an overloaded intrinsic. You can use <tt>llvm.uadd.with.overflow</tt> 7710 on any integer bit width.</p> 7711 7712<pre> 7713 declare {i16, i1} @llvm.uadd.with.overflow.i16(i16 %a, i16 %b) 7714 declare {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b) 7715 declare {i64, i1} @llvm.uadd.with.overflow.i64(i64 %a, i64 %b) 7716</pre> 7717 7718<h5>Overview:</h5> 7719<p>The '<tt>llvm.uadd.with.overflow</tt>' family of intrinsic functions perform 7720 an unsigned addition of the two arguments, and indicate whether a carry 7721 occurred during the unsigned summation.</p> 7722 7723<h5>Arguments:</h5> 7724<p>The arguments (%a and %b) and the first element of the result structure may 7725 be of integer types of any bit width, but they must have the same bit 7726 width. The second element of the result structure must be of 7727 type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will 7728 undergo unsigned addition.</p> 7729 7730<h5>Semantics:</h5> 7731<p>The '<tt>llvm.uadd.with.overflow</tt>' family of intrinsic functions perform 7732 an unsigned addition of the two arguments. They return a structure — 7733 the first element of which is the sum, and the second element of which is a 7734 bit specifying if the unsigned summation resulted in a carry.</p> 7735 7736<h5>Examples:</h5> 7737<pre> 7738 %res = call {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b) 7739 %sum = extractvalue {i32, i1} %res, 0 7740 %obit = extractvalue {i32, i1} %res, 1 7741 br i1 %obit, label %carry, label %normal 7742</pre> 7743 7744</div> 7745 7746<!-- _______________________________________________________________________ --> 7747<h4> 7748 <a name="int_ssub_overflow"> 7749 '<tt>llvm.ssub.with.overflow.*</tt>' Intrinsics 7750 </a> 7751</h4> 7752 7753<div> 7754 7755<h5>Syntax:</h5> 7756<p>This is an overloaded intrinsic. You can use <tt>llvm.ssub.with.overflow</tt> 7757 on any integer bit width.</p> 7758 7759<pre> 7760 declare {i16, i1} @llvm.ssub.with.overflow.i16(i16 %a, i16 %b) 7761 declare {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b) 7762 declare {i64, i1} @llvm.ssub.with.overflow.i64(i64 %a, i64 %b) 7763</pre> 7764 7765<h5>Overview:</h5> 7766<p>The '<tt>llvm.ssub.with.overflow</tt>' family of intrinsic functions perform 7767 a signed subtraction of the two arguments, and indicate whether an overflow 7768 occurred during the signed subtraction.</p> 7769 7770<h5>Arguments:</h5> 7771<p>The arguments (%a and %b) and the first element of the result structure may 7772 be of integer types of any bit width, but they must have the same bit 7773 width. The second element of the result structure must be of 7774 type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will 7775 undergo signed subtraction.</p> 7776 7777<h5>Semantics:</h5> 7778<p>The '<tt>llvm.ssub.with.overflow</tt>' family of intrinsic functions perform 7779 a signed subtraction of the two arguments. They return a structure — 7780 the first element of which is the subtraction, and the second element of 7781 which is a bit specifying if the signed subtraction resulted in an 7782 overflow.</p> 7783 7784<h5>Examples:</h5> 7785<pre> 7786 %res = call {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b) 7787 %sum = extractvalue {i32, i1} %res, 0 7788 %obit = extractvalue {i32, i1} %res, 1 7789 br i1 %obit, label %overflow, label %normal 7790</pre> 7791 7792</div> 7793 7794<!-- _______________________________________________________________________ --> 7795<h4> 7796 <a name="int_usub_overflow"> 7797 '<tt>llvm.usub.with.overflow.*</tt>' Intrinsics 7798 </a> 7799</h4> 7800 7801<div> 7802 7803<h5>Syntax:</h5> 7804<p>This is an overloaded intrinsic. You can use <tt>llvm.usub.with.overflow</tt> 7805 on any integer bit width.</p> 7806 7807<pre> 7808 declare {i16, i1} @llvm.usub.with.overflow.i16(i16 %a, i16 %b) 7809 declare {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b) 7810 declare {i64, i1} @llvm.usub.with.overflow.i64(i64 %a, i64 %b) 7811</pre> 7812 7813<h5>Overview:</h5> 7814<p>The '<tt>llvm.usub.with.overflow</tt>' family of intrinsic functions perform 7815 an unsigned subtraction of the two arguments, and indicate whether an 7816 overflow occurred during the unsigned subtraction.</p> 7817 7818<h5>Arguments:</h5> 7819<p>The arguments (%a and %b) and the first element of the result structure may 7820 be of integer types of any bit width, but they must have the same bit 7821 width. The second element of the result structure must be of 7822 type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will 7823 undergo unsigned subtraction.</p> 7824 7825<h5>Semantics:</h5> 7826<p>The '<tt>llvm.usub.with.overflow</tt>' family of intrinsic functions perform 7827 an unsigned subtraction of the two arguments. They return a structure — 7828 the first element of which is the subtraction, and the second element of 7829 which is a bit specifying if the unsigned subtraction resulted in an 7830 overflow.</p> 7831 7832<h5>Examples:</h5> 7833<pre> 7834 %res = call {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b) 7835 %sum = extractvalue {i32, i1} %res, 0 7836 %obit = extractvalue {i32, i1} %res, 1 7837 br i1 %obit, label %overflow, label %normal 7838</pre> 7839 7840</div> 7841 7842<!-- _______________________________________________________________________ --> 7843<h4> 7844 <a name="int_smul_overflow"> 7845 '<tt>llvm.smul.with.overflow.*</tt>' Intrinsics 7846 </a> 7847</h4> 7848 7849<div> 7850 7851<h5>Syntax:</h5> 7852<p>This is an overloaded intrinsic. You can use <tt>llvm.smul.with.overflow</tt> 7853 on any integer bit width.</p> 7854 7855<pre> 7856 declare {i16, i1} @llvm.smul.with.overflow.i16(i16 %a, i16 %b) 7857 declare {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b) 7858 declare {i64, i1} @llvm.smul.with.overflow.i64(i64 %a, i64 %b) 7859</pre> 7860 7861<h5>Overview:</h5> 7862 7863<p>The '<tt>llvm.smul.with.overflow</tt>' family of intrinsic functions perform 7864 a signed multiplication of the two arguments, and indicate whether an 7865 overflow occurred during the signed multiplication.</p> 7866 7867<h5>Arguments:</h5> 7868<p>The arguments (%a and %b) and the first element of the result structure may 7869 be of integer types of any bit width, but they must have the same bit 7870 width. The second element of the result structure must be of 7871 type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will 7872 undergo signed multiplication.</p> 7873 7874<h5>Semantics:</h5> 7875<p>The '<tt>llvm.smul.with.overflow</tt>' family of intrinsic functions perform 7876 a signed multiplication of the two arguments. They return a structure — 7877 the first element of which is the multiplication, and the second element of 7878 which is a bit specifying if the signed multiplication resulted in an 7879 overflow.</p> 7880 7881<h5>Examples:</h5> 7882<pre> 7883 %res = call {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b) 7884 %sum = extractvalue {i32, i1} %res, 0 7885 %obit = extractvalue {i32, i1} %res, 1 7886 br i1 %obit, label %overflow, label %normal 7887</pre> 7888 7889</div> 7890 7891<!-- _______________________________________________________________________ --> 7892<h4> 7893 <a name="int_umul_overflow"> 7894 '<tt>llvm.umul.with.overflow.*</tt>' Intrinsics 7895 </a> 7896</h4> 7897 7898<div> 7899 7900<h5>Syntax:</h5> 7901<p>This is an overloaded intrinsic. You can use <tt>llvm.umul.with.overflow</tt> 7902 on any integer bit width.</p> 7903 7904<pre> 7905 declare {i16, i1} @llvm.umul.with.overflow.i16(i16 %a, i16 %b) 7906 declare {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b) 7907 declare {i64, i1} @llvm.umul.with.overflow.i64(i64 %a, i64 %b) 7908</pre> 7909 7910<h5>Overview:</h5> 7911<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform 7912 a unsigned multiplication of the two arguments, and indicate whether an 7913 overflow occurred during the unsigned multiplication.</p> 7914 7915<h5>Arguments:</h5> 7916<p>The arguments (%a and %b) and the first element of the result structure may 7917 be of integer types of any bit width, but they must have the same bit 7918 width. The second element of the result structure must be of 7919 type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will 7920 undergo unsigned multiplication.</p> 7921 7922<h5>Semantics:</h5> 7923<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform 7924 an unsigned multiplication of the two arguments. They return a structure 7925 — the first element of which is the multiplication, and the second 7926 element of which is a bit specifying if the unsigned multiplication resulted 7927 in an overflow.</p> 7928 7929<h5>Examples:</h5> 7930<pre> 7931 %res = call {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b) 7932 %sum = extractvalue {i32, i1} %res, 0 7933 %obit = extractvalue {i32, i1} %res, 1 7934 br i1 %obit, label %overflow, label %normal 7935</pre> 7936 7937</div> 7938 7939</div> 7940 7941<!-- ======================================================================= --> 7942<h3> 7943 <a name="int_fp16">Half Precision Floating Point Intrinsics</a> 7944</h3> 7945 7946<div> 7947 7948<p>Half precision floating point is a storage-only format. This means that it is 7949 a dense encoding (in memory) but does not support computation in the 7950 format.</p> 7951 7952<p>This means that code must first load the half-precision floating point 7953 value as an i16, then convert it to float with <a 7954 href="#int_convert_from_fp16"><tt>llvm.convert.from.fp16</tt></a>. 7955 Computation can then be performed on the float value (including extending to 7956 double etc). To store the value back to memory, it is first converted to 7957 float if needed, then converted to i16 with 7958 <a href="#int_convert_to_fp16"><tt>llvm.convert.to.fp16</tt></a>, then 7959 storing as an i16 value.</p> 7960 7961<!-- _______________________________________________________________________ --> 7962<h4> 7963 <a name="int_convert_to_fp16"> 7964 '<tt>llvm.convert.to.fp16</tt>' Intrinsic 7965 </a> 7966</h4> 7967 7968<div> 7969 7970<h5>Syntax:</h5> 7971<pre> 7972 declare i16 @llvm.convert.to.fp16(f32 %a) 7973</pre> 7974 7975<h5>Overview:</h5> 7976<p>The '<tt>llvm.convert.to.fp16</tt>' intrinsic function performs 7977 a conversion from single precision floating point format to half precision 7978 floating point format.</p> 7979 7980<h5>Arguments:</h5> 7981<p>The intrinsic function contains single argument - the value to be 7982 converted.</p> 7983 7984<h5>Semantics:</h5> 7985<p>The '<tt>llvm.convert.to.fp16</tt>' intrinsic function performs 7986 a conversion from single precision floating point format to half precision 7987 floating point format. The return value is an <tt>i16</tt> which 7988 contains the converted number.</p> 7989 7990<h5>Examples:</h5> 7991<pre> 7992 %res = call i16 @llvm.convert.to.fp16(f32 %a) 7993 store i16 %res, i16* @x, align 2 7994</pre> 7995 7996</div> 7997 7998<!-- _______________________________________________________________________ --> 7999<h4> 8000 <a name="int_convert_from_fp16"> 8001 '<tt>llvm.convert.from.fp16</tt>' Intrinsic 8002 </a> 8003</h4> 8004 8005<div> 8006 8007<h5>Syntax:</h5> 8008<pre> 8009 declare f32 @llvm.convert.from.fp16(i16 %a) 8010</pre> 8011 8012<h5>Overview:</h5> 8013<p>The '<tt>llvm.convert.from.fp16</tt>' intrinsic function performs 8014 a conversion from half precision floating point format to single precision 8015 floating point format.</p> 8016 8017<h5>Arguments:</h5> 8018<p>The intrinsic function contains single argument - the value to be 8019 converted.</p> 8020 8021<h5>Semantics:</h5> 8022<p>The '<tt>llvm.convert.from.fp16</tt>' intrinsic function performs a 8023 conversion from half single precision floating point format to single 8024 precision floating point format. The input half-float value is represented by 8025 an <tt>i16</tt> value.</p> 8026 8027<h5>Examples:</h5> 8028<pre> 8029 %a = load i16* @x, align 2 8030 %res = call f32 @llvm.convert.from.fp16(i16 %a) 8031</pre> 8032 8033</div> 8034 8035</div> 8036 8037<!-- ======================================================================= --> 8038<h3> 8039 <a name="int_debugger">Debugger Intrinsics</a> 8040</h3> 8041 8042<div> 8043 8044<p>The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> 8045 prefix), are described in 8046 the <a href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source 8047 Level Debugging</a> document.</p> 8048 8049</div> 8050 8051<!-- ======================================================================= --> 8052<h3> 8053 <a name="int_eh">Exception Handling Intrinsics</a> 8054</h3> 8055 8056<div> 8057 8058<p>The LLVM exception handling intrinsics (which all start with 8059 <tt>llvm.eh.</tt> prefix), are described in 8060 the <a href="ExceptionHandling.html#format_common_intrinsics">LLVM Exception 8061 Handling</a> document.</p> 8062 8063</div> 8064 8065<!-- ======================================================================= --> 8066<h3> 8067 <a name="int_trampoline">Trampoline Intrinsics</a> 8068</h3> 8069 8070<div> 8071 8072<p>These intrinsics make it possible to excise one parameter, marked with 8073 the <a href="#nest"><tt>nest</tt></a> attribute, from a function. 8074 The result is a callable 8075 function pointer lacking the nest parameter - the caller does not need to 8076 provide a value for it. Instead, the value to use is stored in advance in a 8077 "trampoline", a block of memory usually allocated on the stack, which also 8078 contains code to splice the nest value into the argument list. This is used 8079 to implement the GCC nested function address extension.</p> 8080 8081<p>For example, if the function is 8082 <tt>i32 f(i8* nest %c, i32 %x, i32 %y)</tt> then the resulting function 8083 pointer has signature <tt>i32 (i32, i32)*</tt>. It can be created as 8084 follows:</p> 8085 8086<pre class="doc_code"> 8087 %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86 8088 %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0 8089 call i8* @llvm.init.trampoline(i8* %tramp1, i8* bitcast (i32 (i8*, i32, i32)* @f to i8*), i8* %nval) 8090 %p = call i8* @llvm.adjust.trampoline(i8* %tramp1) 8091 %fp = bitcast i8* %p to i32 (i32, i32)* 8092</pre> 8093 8094<p>The call <tt>%val = call i32 %fp(i32 %x, i32 %y)</tt> is then equivalent 8095 to <tt>%val = call i32 %f(i8* %nval, i32 %x, i32 %y)</tt>.</p> 8096 8097<!-- _______________________________________________________________________ --> 8098<h4> 8099 <a name="int_it"> 8100 '<tt>llvm.init.trampoline</tt>' Intrinsic 8101 </a> 8102</h4> 8103 8104<div> 8105 8106<h5>Syntax:</h5> 8107<pre> 8108 declare void @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>) 8109</pre> 8110 8111<h5>Overview:</h5> 8112<p>This fills the memory pointed to by <tt>tramp</tt> with executable code, 8113 turning it into a trampoline.</p> 8114 8115<h5>Arguments:</h5> 8116<p>The <tt>llvm.init.trampoline</tt> intrinsic takes three arguments, all 8117 pointers. The <tt>tramp</tt> argument must point to a sufficiently large and 8118 sufficiently aligned block of memory; this memory is written to by the 8119 intrinsic. Note that the size and the alignment are target-specific - LLVM 8120 currently provides no portable way of determining them, so a front-end that 8121 generates this intrinsic needs to have some target-specific knowledge. 8122 The <tt>func</tt> argument must hold a function bitcast to 8123 an <tt>i8*</tt>.</p> 8124 8125<h5>Semantics:</h5> 8126<p>The block of memory pointed to by <tt>tramp</tt> is filled with target 8127 dependent code, turning it into a function. Then <tt>tramp</tt> needs to be 8128 passed to <a href="#int_at">llvm.adjust.trampoline</a> to get a pointer 8129 which can be <a href="#int_trampoline">bitcast (to a new function) and 8130 called</a>. The new function's signature is the same as that of 8131 <tt>func</tt> with any arguments marked with the <tt>nest</tt> attribute 8132 removed. At most one such <tt>nest</tt> argument is allowed, and it must be of 8133 pointer type. Calling the new function is equivalent to calling <tt>func</tt> 8134 with the same argument list, but with <tt>nval</tt> used for the missing 8135 <tt>nest</tt> argument. If, after calling <tt>llvm.init.trampoline</tt>, the 8136 memory pointed to by <tt>tramp</tt> is modified, then the effect of any later call 8137 to the returned function pointer is undefined.</p> 8138</div> 8139 8140<!-- _______________________________________________________________________ --> 8141<h4> 8142 <a name="int_at"> 8143 '<tt>llvm.adjust.trampoline</tt>' Intrinsic 8144 </a> 8145</h4> 8146 8147<div> 8148 8149<h5>Syntax:</h5> 8150<pre> 8151 declare i8* @llvm.adjust.trampoline(i8* <tramp>) 8152</pre> 8153 8154<h5>Overview:</h5> 8155<p>This performs any required machine-specific adjustment to the address of a 8156 trampoline (passed as <tt>tramp</tt>).</p> 8157 8158<h5>Arguments:</h5> 8159<p><tt>tramp</tt> must point to a block of memory which already has trampoline code 8160 filled in by a previous call to <a href="#int_it"><tt>llvm.init.trampoline</tt> 8161 </a>.</p> 8162 8163<h5>Semantics:</h5> 8164<p>On some architectures the address of the code to be executed needs to be 8165 different to the address where the trampoline is actually stored. This 8166 intrinsic returns the executable address corresponding to <tt>tramp</tt> 8167 after performing the required machine specific adjustments. 8168 The pointer returned can then be <a href="#int_trampoline"> bitcast and 8169 executed</a>. 8170</p> 8171 8172</div> 8173 8174</div> 8175 8176<!-- ======================================================================= --> 8177<h3> 8178 <a name="int_memorymarkers">Memory Use Markers</a> 8179</h3> 8180 8181<div> 8182 8183<p>This class of intrinsics exists to information about the lifetime of memory 8184 objects and ranges where variables are immutable.</p> 8185 8186<!-- _______________________________________________________________________ --> 8187<h4> 8188 <a name="int_lifetime_start">'<tt>llvm.lifetime.start</tt>' Intrinsic</a> 8189</h4> 8190 8191<div> 8192 8193<h5>Syntax:</h5> 8194<pre> 8195 declare void @llvm.lifetime.start(i64 <size>, i8* nocapture <ptr>) 8196</pre> 8197 8198<h5>Overview:</h5> 8199<p>The '<tt>llvm.lifetime.start</tt>' intrinsic specifies the start of a memory 8200 object's lifetime.</p> 8201 8202<h5>Arguments:</h5> 8203<p>The first argument is a constant integer representing the size of the 8204 object, or -1 if it is variable sized. The second argument is a pointer to 8205 the object.</p> 8206 8207<h5>Semantics:</h5> 8208<p>This intrinsic indicates that before this point in the code, the value of the 8209 memory pointed to by <tt>ptr</tt> is dead. This means that it is known to 8210 never be used and has an undefined value. A load from the pointer that 8211 precedes this intrinsic can be replaced with 8212 <tt>'<a href="#undefvalues">undef</a>'</tt>.</p> 8213 8214</div> 8215 8216<!-- _______________________________________________________________________ --> 8217<h4> 8218 <a name="int_lifetime_end">'<tt>llvm.lifetime.end</tt>' Intrinsic</a> 8219</h4> 8220 8221<div> 8222 8223<h5>Syntax:</h5> 8224<pre> 8225 declare void @llvm.lifetime.end(i64 <size>, i8* nocapture <ptr>) 8226</pre> 8227 8228<h5>Overview:</h5> 8229<p>The '<tt>llvm.lifetime.end</tt>' intrinsic specifies the end of a memory 8230 object's lifetime.</p> 8231 8232<h5>Arguments:</h5> 8233<p>The first argument is a constant integer representing the size of the 8234 object, or -1 if it is variable sized. The second argument is a pointer to 8235 the object.</p> 8236 8237<h5>Semantics:</h5> 8238<p>This intrinsic indicates that after this point in the code, the value of the 8239 memory pointed to by <tt>ptr</tt> is dead. This means that it is known to 8240 never be used and has an undefined value. Any stores into the memory object 8241 following this intrinsic may be removed as dead. 8242 8243</div> 8244 8245<!-- _______________________________________________________________________ --> 8246<h4> 8247 <a name="int_invariant_start">'<tt>llvm.invariant.start</tt>' Intrinsic</a> 8248</h4> 8249 8250<div> 8251 8252<h5>Syntax:</h5> 8253<pre> 8254 declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) 8255</pre> 8256 8257<h5>Overview:</h5> 8258<p>The '<tt>llvm.invariant.start</tt>' intrinsic specifies that the contents of 8259 a memory object will not change.</p> 8260 8261<h5>Arguments:</h5> 8262<p>The first argument is a constant integer representing the size of the 8263 object, or -1 if it is variable sized. The second argument is a pointer to 8264 the object.</p> 8265 8266<h5>Semantics:</h5> 8267<p>This intrinsic indicates that until an <tt>llvm.invariant.end</tt> that uses 8268 the return value, the referenced memory location is constant and 8269 unchanging.</p> 8270 8271</div> 8272 8273<!-- _______________________________________________________________________ --> 8274<h4> 8275 <a name="int_invariant_end">'<tt>llvm.invariant.end</tt>' Intrinsic</a> 8276</h4> 8277 8278<div> 8279 8280<h5>Syntax:</h5> 8281<pre> 8282 declare void @llvm.invariant.end({}* <start>, i64 <size>, i8* nocapture <ptr>) 8283</pre> 8284 8285<h5>Overview:</h5> 8286<p>The '<tt>llvm.invariant.end</tt>' intrinsic specifies that the contents of 8287 a memory object are mutable.</p> 8288 8289<h5>Arguments:</h5> 8290<p>The first argument is the matching <tt>llvm.invariant.start</tt> intrinsic. 8291 The second argument is a constant integer representing the size of the 8292 object, or -1 if it is variable sized and the third argument is a pointer 8293 to the object.</p> 8294 8295<h5>Semantics:</h5> 8296<p>This intrinsic indicates that the memory is mutable again.</p> 8297 8298</div> 8299 8300</div> 8301 8302<!-- ======================================================================= --> 8303<h3> 8304 <a name="int_general">General Intrinsics</a> 8305</h3> 8306 8307<div> 8308 8309<p>This class of intrinsics is designed to be generic and has no specific 8310 purpose.</p> 8311 8312<!-- _______________________________________________________________________ --> 8313<h4> 8314 <a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a> 8315</h4> 8316 8317<div> 8318 8319<h5>Syntax:</h5> 8320<pre> 8321 declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int>) 8322</pre> 8323 8324<h5>Overview:</h5> 8325<p>The '<tt>llvm.var.annotation</tt>' intrinsic.</p> 8326 8327<h5>Arguments:</h5> 8328<p>The first argument is a pointer to a value, the second is a pointer to a 8329 global string, the third is a pointer to a global string which is the source 8330 file name, and the last argument is the line number.</p> 8331 8332<h5>Semantics:</h5> 8333<p>This intrinsic allows annotation of local variables with arbitrary strings. 8334 This can be useful for special purpose optimizations that want to look for 8335 these annotations. These have no other defined use; they are ignored by code 8336 generation and optimization.</p> 8337 8338</div> 8339 8340<!-- _______________________________________________________________________ --> 8341<h4> 8342 <a name="int_annotation">'<tt>llvm.annotation.*</tt>' Intrinsic</a> 8343</h4> 8344 8345<div> 8346 8347<h5>Syntax:</h5> 8348<p>This is an overloaded intrinsic. You can use '<tt>llvm.annotation</tt>' on 8349 any integer bit width.</p> 8350 8351<pre> 8352 declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int>) 8353 declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int>) 8354 declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int>) 8355 declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int>) 8356 declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int>) 8357</pre> 8358 8359<h5>Overview:</h5> 8360<p>The '<tt>llvm.annotation</tt>' intrinsic.</p> 8361 8362<h5>Arguments:</h5> 8363<p>The first argument is an integer value (result of some expression), the 8364 second is a pointer to a global string, the third is a pointer to a global 8365 string which is the source file name, and the last argument is the line 8366 number. It returns the value of the first argument.</p> 8367 8368<h5>Semantics:</h5> 8369<p>This intrinsic allows annotations to be put on arbitrary expressions with 8370 arbitrary strings. This can be useful for special purpose optimizations that 8371 want to look for these annotations. These have no other defined use; they 8372 are ignored by code generation and optimization.</p> 8373 8374</div> 8375 8376<!-- _______________________________________________________________________ --> 8377<h4> 8378 <a name="int_trap">'<tt>llvm.trap</tt>' Intrinsic</a> 8379</h4> 8380 8381<div> 8382 8383<h5>Syntax:</h5> 8384<pre> 8385 declare void @llvm.trap() 8386</pre> 8387 8388<h5>Overview:</h5> 8389<p>The '<tt>llvm.trap</tt>' intrinsic.</p> 8390 8391<h5>Arguments:</h5> 8392<p>None.</p> 8393 8394<h5>Semantics:</h5> 8395<p>This intrinsics is lowered to the target dependent trap instruction. If the 8396 target does not have a trap instruction, this intrinsic will be lowered to 8397 the call of the <tt>abort()</tt> function.</p> 8398 8399</div> 8400 8401<!-- _______________________________________________________________________ --> 8402<h4> 8403 <a name="int_stackprotector">'<tt>llvm.stackprotector</tt>' Intrinsic</a> 8404</h4> 8405 8406<div> 8407 8408<h5>Syntax:</h5> 8409<pre> 8410 declare void @llvm.stackprotector(i8* <guard>, i8** <slot>) 8411</pre> 8412 8413<h5>Overview:</h5> 8414<p>The <tt>llvm.stackprotector</tt> intrinsic takes the <tt>guard</tt> and 8415 stores it onto the stack at <tt>slot</tt>. The stack slot is adjusted to 8416 ensure that it is placed on the stack before local variables.</p> 8417 8418<h5>Arguments:</h5> 8419<p>The <tt>llvm.stackprotector</tt> intrinsic requires two pointer 8420 arguments. The first argument is the value loaded from the stack 8421 guard <tt>@__stack_chk_guard</tt>. The second variable is an <tt>alloca</tt> 8422 that has enough space to hold the value of the guard.</p> 8423 8424<h5>Semantics:</h5> 8425<p>This intrinsic causes the prologue/epilogue inserter to force the position of 8426 the <tt>AllocaInst</tt> stack slot to be before local variables on the 8427 stack. This is to ensure that if a local variable on the stack is 8428 overwritten, it will destroy the value of the guard. When the function exits, 8429 the guard on the stack is checked against the original guard. If they are 8430 different, then the program aborts by calling the <tt>__stack_chk_fail()</tt> 8431 function.</p> 8432 8433</div> 8434 8435<!-- _______________________________________________________________________ --> 8436<h4> 8437 <a name="int_objectsize">'<tt>llvm.objectsize</tt>' Intrinsic</a> 8438</h4> 8439 8440<div> 8441 8442<h5>Syntax:</h5> 8443<pre> 8444 declare i32 @llvm.objectsize.i32(i8* <object>, i1 <type>) 8445 declare i64 @llvm.objectsize.i64(i8* <object>, i1 <type>) 8446</pre> 8447 8448<h5>Overview:</h5> 8449<p>The <tt>llvm.objectsize</tt> intrinsic is designed to provide information to 8450 the optimizers to determine at compile time whether a) an operation (like 8451 memcpy) will overflow a buffer that corresponds to an object, or b) that a 8452 runtime check for overflow isn't necessary. An object in this context means 8453 an allocation of a specific class, structure, array, or other object.</p> 8454 8455<h5>Arguments:</h5> 8456<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments. The first 8457 argument is a pointer to or into the <tt>object</tt>. The second argument 8458 is a boolean 0 or 1. This argument determines whether you want the 8459 maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or 8460 1, variables are not allowed.</p> 8461 8462<h5>Semantics:</h5> 8463<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to either a constant 8464 representing the size of the object concerned, or <tt>i32/i64 -1 or 0</tt>, 8465 depending on the <tt>type</tt> argument, if the size cannot be determined at 8466 compile time.</p> 8467 8468</div> 8469<!-- _______________________________________________________________________ --> 8470<h4> 8471 <a name="int_expect">'<tt>llvm.expect</tt>' Intrinsic</a> 8472</h4> 8473 8474<div> 8475 8476<h5>Syntax:</h5> 8477<pre> 8478 declare i32 @llvm.expect.i32(i32 <val>, i32 <expected_val>) 8479 declare i64 @llvm.expect.i64(i64 <val>, i64 <expected_val>) 8480</pre> 8481 8482<h5>Overview:</h5> 8483<p>The <tt>llvm.expect</tt> intrinsic provides information about expected (the 8484 most probable) value of <tt>val</tt>, which can be used by optimizers.</p> 8485 8486<h5>Arguments:</h5> 8487<p>The <tt>llvm.expect</tt> intrinsic takes two arguments. The first 8488 argument is a value. The second argument is an expected value, this needs to 8489 be a constant value, variables are not allowed.</p> 8490 8491<h5>Semantics:</h5> 8492<p>This intrinsic is lowered to the <tt>val</tt>.</p> 8493</div> 8494 8495</div> 8496 8497</div> 8498<!-- *********************************************************************** --> 8499<hr> 8500<address> 8501 <a href="http://jigsaw.w3.org/css-validator/check/referer"><img 8502 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a> 8503 <a href="http://validator.w3.org/check/referer"><img 8504 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a> 8505 8506 <a href="mailto:sabre@nondot.org">Chris Lattner</a><br> 8507 <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br> 8508 Last modified: $Date$ 8509</address> 8510 8511</body> 8512</html> 8513