[llvm-commits] [llvm] r103213 [2/3] - in /llvm/trunk: ./ autoconf/ docs/ docs/CommandGuide/ docs/HistoricalNotes/ docs/api/ docs/img/ docs/main/ docs/main/CommandGuide/ docs/main/HistoricalNotes/ docs/main/img/ docs/main/tutorial/ docs/mk/ docs/tutorial/
mike-m
mikem.llvm at gmail.com
Thu May 6 16:45:43 PDT 2010
Removed: llvm/trunk/docs/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/LangRef.html (original)
+++ llvm/trunk/docs/LangRef.html (removed)
@@ -1,7780 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>LLVM Assembly Language Reference Manual</title>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <meta name="author" content="Chris Lattner">
- <meta name="description"
- content="LLVM Assembly Language Reference Manual.">
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-
-<body>
-
-<div class="doc_title"> LLVM Language Reference Manual </div>
-<ol>
- <li><a href="#abstract">Abstract</a></li>
- <li><a href="#introduction">Introduction</a></li>
- <li><a href="#identifiers">Identifiers</a></li>
- <li><a href="#highlevel">High Level Structure</a>
- <ol>
- <li><a href="#modulestructure">Module Structure</a></li>
- <li><a href="#linkage">Linkage Types</a>
- <ol>
- <li><a href="#linkage_private">'<tt>private</tt>' Linkage</a></li>
- <li><a href="#linkage_linker_private">'<tt>linker_private</tt>' Linkage</a></li>
- <li><a href="#linkage_internal">'<tt>internal</tt>' Linkage</a></li>
- <li><a href="#linkage_available_externally">'<tt>available_externally</tt>' Linkage</a></li>
- <li><a href="#linkage_linkonce">'<tt>linkonce</tt>' Linkage</a></li>
- <li><a href="#linkage_common">'<tt>common</tt>' Linkage</a></li>
- <li><a href="#linkage_weak">'<tt>weak</tt>' Linkage</a></li>
- <li><a href="#linkage_appending">'<tt>appending</tt>' Linkage</a></li>
- <li><a href="#linkage_externweak">'<tt>extern_weak</tt>' Linkage</a></li>
- <li><a href="#linkage_linkonce_odr">'<tt>linkonce_odr</tt>' Linkage</a></li>
- <li><a href="#linkage_weak">'<tt>weak_odr</tt>' Linkage</a></li>
- <li><a href="#linkage_external">'<tt>externally visible</tt>' Linkage</a></li>
- <li><a href="#linkage_dllimport">'<tt>dllimport</tt>' Linkage</a></li>
- <li><a href="#linkage_dllexport">'<tt>dllexport</tt>' Linkage</a></li>
- </ol>
- </li>
- <li><a href="#callingconv">Calling Conventions</a></li>
- <li><a href="#namedtypes">Named Types</a></li>
- <li><a href="#globalvars">Global Variables</a></li>
- <li><a href="#functionstructure">Functions</a></li>
- <li><a href="#aliasstructure">Aliases</a></li>
- <li><a href="#namedmetadatastructure">Named Metadata</a></li>
- <li><a href="#paramattrs">Parameter Attributes</a></li>
- <li><a href="#fnattrs">Function Attributes</a></li>
- <li><a href="#gc">Garbage Collector Names</a></li>
- <li><a href="#moduleasm">Module-Level Inline Assembly</a></li>
- <li><a href="#datalayout">Data Layout</a></li>
- <li><a href="#pointeraliasing">Pointer Aliasing Rules</a></li>
- <li><a href="#volatile">Volatile Memory Accesses</a></li>
- </ol>
- </li>
- <li><a href="#typesystem">Type System</a>
- <ol>
- <li><a href="#t_classifications">Type Classifications</a></li>
- <li><a href="#t_primitive">Primitive Types</a>
- <ol>
- <li><a href="#t_integer">Integer Type</a></li>
- <li><a href="#t_floating">Floating Point Types</a></li>
- <li><a href="#t_void">Void Type</a></li>
- <li><a href="#t_label">Label Type</a></li>
- <li><a href="#t_metadata">Metadata Type</a></li>
- </ol>
- </li>
- <li><a href="#t_derived">Derived Types</a>
- <ol>
- <li><a href="#t_aggregate">Aggregate Types</a>
- <ol>
- <li><a href="#t_array">Array Type</a></li>
- <li><a href="#t_struct">Structure Type</a></li>
- <li><a href="#t_pstruct">Packed Structure Type</a></li>
- <li><a href="#t_union">Union Type</a></li>
- <li><a href="#t_vector">Vector Type</a></li>
- </ol>
- </li>
- <li><a href="#t_function">Function Type</a></li>
- <li><a href="#t_pointer">Pointer Type</a></li>
- <li><a href="#t_opaque">Opaque Type</a></li>
- </ol>
- </li>
- <li><a href="#t_uprefs">Type Up-references</a></li>
- </ol>
- </li>
- <li><a href="#constants">Constants</a>
- <ol>
- <li><a href="#simpleconstants">Simple Constants</a></li>
- <li><a href="#complexconstants">Complex Constants</a></li>
- <li><a href="#globalconstants">Global Variable and Function Addresses</a></li>
- <li><a href="#undefvalues">Undefined Values</a></li>
- <li><a href="#trapvalues">Trap Values</a></li>
- <li><a href="#blockaddress">Addresses of Basic Blocks</a></li>
- <li><a href="#constantexprs">Constant Expressions</a></li>
- </ol>
- </li>
- <li><a href="#othervalues">Other Values</a>
- <ol>
- <li><a href="#inlineasm">Inline Assembler Expressions</a></li>
- <li><a href="#metadata">Metadata Nodes and Metadata Strings</a></li>
- </ol>
- </li>
- <li><a href="#intrinsic_globals">Intrinsic Global Variables</a>
- <ol>
- <li><a href="#intg_used">The '<tt>llvm.used</tt>' Global Variable</a></li>
- <li><a href="#intg_compiler_used">The '<tt>llvm.compiler.used</tt>'
- Global Variable</a></li>
- <li><a href="#intg_global_ctors">The '<tt>llvm.global_ctors</tt>'
- Global Variable</a></li>
- <li><a href="#intg_global_dtors">The '<tt>llvm.global_dtors</tt>'
- Global Variable</a></li>
- </ol>
- </li>
- <li><a href="#instref">Instruction Reference</a>
- <ol>
- <li><a href="#terminators">Terminator Instructions</a>
- <ol>
- <li><a href="#i_ret">'<tt>ret</tt>' Instruction</a></li>
- <li><a href="#i_br">'<tt>br</tt>' Instruction</a></li>
- <li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li>
- <li><a href="#i_indirectbr">'<tt>indirectbr</tt>' Instruction</a></li>
- <li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li>
- <li><a href="#i_unwind">'<tt>unwind</tt>' Instruction</a></li>
- <li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#binaryops">Binary Operations</a>
- <ol>
- <li><a href="#i_add">'<tt>add</tt>' Instruction</a></li>
- <li><a href="#i_fadd">'<tt>fadd</tt>' Instruction</a></li>
- <li><a href="#i_sub">'<tt>sub</tt>' Instruction</a></li>
- <li><a href="#i_fsub">'<tt>fsub</tt>' Instruction</a></li>
- <li><a href="#i_mul">'<tt>mul</tt>' Instruction</a></li>
- <li><a href="#i_fmul">'<tt>fmul</tt>' Instruction</a></li>
- <li><a href="#i_udiv">'<tt>udiv</tt>' Instruction</a></li>
- <li><a href="#i_sdiv">'<tt>sdiv</tt>' Instruction</a></li>
- <li><a href="#i_fdiv">'<tt>fdiv</tt>' Instruction</a></li>
- <li><a href="#i_urem">'<tt>urem</tt>' Instruction</a></li>
- <li><a href="#i_srem">'<tt>srem</tt>' Instruction</a></li>
- <li><a href="#i_frem">'<tt>frem</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#bitwiseops">Bitwise Binary Operations</a>
- <ol>
- <li><a href="#i_shl">'<tt>shl</tt>' Instruction</a></li>
- <li><a href="#i_lshr">'<tt>lshr</tt>' Instruction</a></li>
- <li><a href="#i_ashr">'<tt>ashr</tt>' Instruction</a></li>
- <li><a href="#i_and">'<tt>and</tt>' Instruction</a></li>
- <li><a href="#i_or">'<tt>or</tt>' Instruction</a></li>
- <li><a href="#i_xor">'<tt>xor</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#vectorops">Vector Operations</a>
- <ol>
- <li><a href="#i_extractelement">'<tt>extractelement</tt>' Instruction</a></li>
- <li><a href="#i_insertelement">'<tt>insertelement</tt>' Instruction</a></li>
- <li><a href="#i_shufflevector">'<tt>shufflevector</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#aggregateops">Aggregate Operations</a>
- <ol>
- <li><a href="#i_extractvalue">'<tt>extractvalue</tt>' Instruction</a></li>
- <li><a href="#i_insertvalue">'<tt>insertvalue</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#memoryops">Memory Access and Addressing Operations</a>
- <ol>
- <li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li>
- <li><a href="#i_load">'<tt>load</tt>' Instruction</a></li>
- <li><a href="#i_store">'<tt>store</tt>' Instruction</a></li>
- <li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#convertops">Conversion Operations</a>
- <ol>
- <li><a href="#i_trunc">'<tt>trunc .. to</tt>' Instruction</a></li>
- <li><a href="#i_zext">'<tt>zext .. to</tt>' Instruction</a></li>
- <li><a href="#i_sext">'<tt>sext .. to</tt>' Instruction</a></li>
- <li><a href="#i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a></li>
- <li><a href="#i_fpext">'<tt>fpext .. to</tt>' Instruction</a></li>
- <li><a href="#i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a></li>
- <li><a href="#i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a></li>
- <li><a href="#i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a></li>
- <li><a href="#i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a></li>
- <li><a href="#i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a></li>
- <li><a href="#i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a></li>
- <li><a href="#i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a></li>
- </ol>
- </li>
- <li><a href="#otherops">Other Operations</a>
- <ol>
- <li><a href="#i_icmp">'<tt>icmp</tt>' Instruction</a></li>
- <li><a href="#i_fcmp">'<tt>fcmp</tt>' Instruction</a></li>
- <li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li>
- <li><a href="#i_select">'<tt>select</tt>' Instruction</a></li>
- <li><a href="#i_call">'<tt>call</tt>' Instruction</a></li>
- <li><a href="#i_va_arg">'<tt>va_arg</tt>' Instruction</a></li>
- </ol>
- </li>
- </ol>
- </li>
- <li><a href="#intrinsics">Intrinsic Functions</a>
- <ol>
- <li><a href="#int_varargs">Variable Argument Handling Intrinsics</a>
- <ol>
- <li><a href="#int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a></li>
- <li><a href="#int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a></li>
- <li><a href="#int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_gc">Accurate Garbage Collection Intrinsics</a>
- <ol>
- <li><a href="#int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a></li>
- <li><a href="#int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a></li>
- <li><a href="#int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_codegen">Code Generator Intrinsics</a>
- <ol>
- <li><a href="#int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li>
- <li><a href="#int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li>
- <li><a href="#int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a></li>
- <li><a href="#int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a></li>
- <li><a href="#int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a></li>
- <li><a href="#int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a></li>
- <li><a href="#int_readcyclecounter"><tt>llvm.readcyclecounter</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_libc">Standard C Library Intrinsics</a>
- <ol>
- <li><a href="#int_memcpy">'<tt>llvm.memcpy.*</tt>' Intrinsic</a></li>
- <li><a href="#int_memmove">'<tt>llvm.memmove.*</tt>' Intrinsic</a></li>
- <li><a href="#int_memset">'<tt>llvm.memset.*</tt>' Intrinsic</a></li>
- <li><a href="#int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a></li>
- <li><a href="#int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a></li>
- <li><a href="#int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a></li>
- <li><a href="#int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a></li>
- <li><a href="#int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_manip">Bit Manipulation Intrinsics</a>
- <ol>
- <li><a href="#int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a></li>
- <li><a href="#int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic </a></li>
- <li><a href="#int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic </a></li>
- <li><a href="#int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic </a></li>
- </ol>
- </li>
- <li><a href="#int_overflow">Arithmetic with Overflow Intrinsics</a>
- <ol>
- <li><a href="#int_sadd_overflow">'<tt>llvm.sadd.with.overflow.*</tt> Intrinsics</a></li>
- <li><a href="#int_uadd_overflow">'<tt>llvm.uadd.with.overflow.*</tt> Intrinsics</a></li>
- <li><a href="#int_ssub_overflow">'<tt>llvm.ssub.with.overflow.*</tt> Intrinsics</a></li>
- <li><a href="#int_usub_overflow">'<tt>llvm.usub.with.overflow.*</tt> Intrinsics</a></li>
- <li><a href="#int_smul_overflow">'<tt>llvm.smul.with.overflow.*</tt> Intrinsics</a></li>
- <li><a href="#int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt> Intrinsics</a></li>
- </ol>
- </li>
- <li><a href="#int_fp16">Half Precision Floating Point Intrinsics</a>
- <ol>
- <li><a href="#int_convert_to_fp16">'<tt>llvm.convert.to.fp16</tt>' Intrinsic</a></li>
- <li><a href="#int_convert_from_fp16">'<tt>llvm.convert.from.fp16</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_debugger">Debugger intrinsics</a></li>
- <li><a href="#int_eh">Exception Handling intrinsics</a></li>
- <li><a href="#int_trampoline">Trampoline Intrinsic</a>
- <ol>
- <li><a href="#int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a></li>
- </ol>
- </li>
- <li><a href="#int_atomics">Atomic intrinsics</a>
- <ol>
- <li><a href="#int_memory_barrier"><tt>llvm.memory_barrier</tt></a></li>
- <li><a href="#int_atomic_cmp_swap"><tt>llvm.atomic.cmp.swap</tt></a></li>
- <li><a href="#int_atomic_swap"><tt>llvm.atomic.swap</tt></a></li>
- <li><a href="#int_atomic_load_add"><tt>llvm.atomic.load.add</tt></a></li>
- <li><a href="#int_atomic_load_sub"><tt>llvm.atomic.load.sub</tt></a></li>
- <li><a href="#int_atomic_load_and"><tt>llvm.atomic.load.and</tt></a></li>
- <li><a href="#int_atomic_load_nand"><tt>llvm.atomic.load.nand</tt></a></li>
- <li><a href="#int_atomic_load_or"><tt>llvm.atomic.load.or</tt></a></li>
- <li><a href="#int_atomic_load_xor"><tt>llvm.atomic.load.xor</tt></a></li>
- <li><a href="#int_atomic_load_max"><tt>llvm.atomic.load.max</tt></a></li>
- <li><a href="#int_atomic_load_min"><tt>llvm.atomic.load.min</tt></a></li>
- <li><a href="#int_atomic_load_umax"><tt>llvm.atomic.load.umax</tt></a></li>
- <li><a href="#int_atomic_load_umin"><tt>llvm.atomic.load.umin</tt></a></li>
- </ol>
- </li>
- <li><a href="#int_memorymarkers">Memory Use Markers</a>
- <ol>
- <li><a href="#int_lifetime_start"><tt>llvm.lifetime.start</tt></a></li>
- <li><a href="#int_lifetime_end"><tt>llvm.lifetime.end</tt></a></li>
- <li><a href="#int_invariant_start"><tt>llvm.invariant.start</tt></a></li>
- <li><a href="#int_invariant_end"><tt>llvm.invariant.end</tt></a></li>
- </ol>
- </li>
- <li><a href="#int_general">General intrinsics</a>
- <ol>
- <li><a href="#int_var_annotation">
- '<tt>llvm.var.annotation</tt>' Intrinsic</a></li>
- <li><a href="#int_annotation">
- '<tt>llvm.annotation.*</tt>' Intrinsic</a></li>
- <li><a href="#int_trap">
- '<tt>llvm.trap</tt>' Intrinsic</a></li>
- <li><a href="#int_stackprotector">
- '<tt>llvm.stackprotector</tt>' Intrinsic</a></li>
- <li><a href="#int_objectsize">
- '<tt>llvm.objectsize</tt>' Intrinsic</a></li>
- </ol>
- </li>
- </ol>
- </li>
-</ol>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>
- and <a href="mailto:vadve at cs.uiuc.edu">Vikram Adve</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="abstract">Abstract </a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This document is a reference manual for the LLVM assembly language. LLVM is
- a Static Single Assignment (SSA) based representation that provides type
- safety, low-level operations, flexibility, and the capability of representing
- 'all' high-level languages cleanly. It is the common code representation
- used throughout all phases of the LLVM compilation strategy.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="introduction">Introduction</a> </div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM code representation is designed to be used in three different forms:
- as an in-memory compiler IR, as an on-disk bitcode representation (suitable
- for fast loading by a Just-In-Time compiler), and as a human readable
- assembly language representation. This allows LLVM to provide a powerful
- intermediate representation for efficient compiler transformations and
- analysis, while providing a natural means to debug and visualize the
- transformations. The three different forms of LLVM are all equivalent. This
- document describes the human readable representation and notation.</p>
-
-<p>The LLVM representation aims to be light-weight and low-level while being
- expressive, typed, and extensible at the same time. It aims to be a
- "universal IR" of sorts, by being at a low enough level that high-level ideas
- may be cleanly mapped to it (similar to how microprocessors are "universal
- IR's", allowing many source languages to be mapped to them). By providing
- type information, LLVM can be used as the target of optimizations: for
- example, through pointer analysis, it can be proven that a C automatic
- variable is never accessed outside of the current function, allowing it to
- be promoted to a simple SSA value instead of a memory location.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="wellformed">Well-Formedness</a> </div>
-
-<div class="doc_text">
-
-<p>It is important to note that this document describes 'well formed' LLVM
- assembly language. There is a difference between what the parser accepts and
- what is considered 'well formed'. For example, the following instruction is
- syntactically okay, but not well formed:</p>
-
-<div class="doc_code">
-<pre>
-%x = <a href="#i_add">add</a> i32 1, %x
-</pre>
-</div>
-
-<p>because the definition of <tt>%x</tt> does not dominate all of its uses. The
- LLVM infrastructure provides a verification pass that may be used to verify
- that an LLVM module is well formed. This pass is automatically run by the
- parser after parsing input assembly and by the optimizer before it outputs
- bitcode. The violations pointed out by the verifier pass indicate bugs in
- transformation passes or input to the parser.</p>
-
-</div>
-
-<!-- Describe the typesetting conventions here. -->
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="identifiers">Identifiers</a> </div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>LLVM identifiers come in two basic types: global and local. Global
- identifiers (functions, global variables) begin with the <tt>'@'</tt>
- character. Local identifiers (register names, types) begin with
- the <tt>'%'</tt> character. Additionally, there are three different formats
- for identifiers, for different purposes:</p>
-
-<ol>
- <li>Named values are represented as a string of characters with their prefix.
- For example, <tt>%foo</tt>, <tt>@DivisionByZero</tt>,
- <tt>%a.really.long.identifier</tt>. The actual regular expression used is
- '<tt>[%@][a-zA-Z$._][a-zA-Z$._0-9]*</tt>'. Identifiers which require
- other characters in their names can be surrounded with quotes. Special
- characters may be escaped using <tt>"\xx"</tt> where <tt>xx</tt> is the
- ASCII code for the character in hexadecimal. In this way, any character
- can be used in a name value, even quotes themselves.</li>
-
- <li>Unnamed values are represented as an unsigned numeric value with their
- prefix. For example, <tt>%12</tt>, <tt>@2</tt>, <tt>%44</tt>.</li>
-
- <li>Constants, which are described in a <a href="#constants">section about
- constants</a>, below.</li>
-</ol>
-
-<p>LLVM requires that values start with a prefix for two reasons: Compilers
- don't need to worry about name clashes with reserved words, and the set of
- reserved words may be expanded in the future without penalty. Additionally,
- unnamed identifiers allow a compiler to quickly come up with a temporary
- variable without having to avoid symbol table conflicts.</p>
-
-<p>Reserved words in LLVM are very similar to reserved words in other
- languages. There are keywords for different opcodes
- ('<tt><a href="#i_add">add</a></tt>',
- '<tt><a href="#i_bitcast">bitcast</a></tt>',
- '<tt><a href="#i_ret">ret</a></tt>', etc...), for primitive type names
- ('<tt><a href="#t_void">void</a></tt>',
- '<tt><a href="#t_primitive">i32</a></tt>', etc...), and others. These
- reserved words cannot conflict with variable names, because none of them
- start with a prefix character (<tt>'%'</tt> or <tt>'@'</tt>).</p>
-
-<p>Here is an example of LLVM code to multiply the integer variable
- '<tt>%X</tt>' by 8:</p>
-
-<p>The easy way:</p>
-
-<div class="doc_code">
-<pre>
-%result = <a href="#i_mul">mul</a> i32 %X, 8
-</pre>
-</div>
-
-<p>After strength reduction:</p>
-
-<div class="doc_code">
-<pre>
-%result = <a href="#i_shl">shl</a> i32 %X, i8 3
-</pre>
-</div>
-
-<p>And the hard way:</p>
-
-<div class="doc_code">
-<pre>
-%0 = <a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
-%1 = <a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
-%result = <a href="#i_add">add</a> i32 %1, %1
-</pre>
-</div>
-
-<p>This last way of multiplying <tt>%X</tt> by 8 illustrates several important
- lexical features of LLVM:</p>
-
-<ol>
- <li>Comments are delimited with a '<tt>;</tt>' and go until the end of
- line.</li>
-
- <li>Unnamed temporaries are created when the result of a computation is not
- assigned to a named value.</li>
-
- <li>Unnamed temporaries are numbered sequentially</li>
-</ol>
-
-<p>It also shows a convention that we follow in this document. When
- demonstrating instructions, we will follow an instruction with a comment that
- defines the type and name of value produced. Comments are shown in italic
- text.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="highlevel">High Level Structure</a> </div>
-<!-- *********************************************************************** -->
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="modulestructure">Module Structure</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM programs are composed of "Module"s, each of which is a translation unit
- of the input programs. Each module consists of functions, global variables,
- and symbol table entries. Modules may be combined together with the LLVM
- linker, which merges function (and global variable) definitions, resolves
- forward declarations, and merges symbol table entries. Here is an example of
- the "hello world" module:</p>
-
-<div class="doc_code">
-<pre>
-<i>; Declare the string constant as a global constant.</i>
-<a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
-
-<i>; External declaration of the puts function</i>
-<a href="#functionstructure">declare</a> i32 @puts(i8 *) <i>; i32(i8 *)* </i>
-
-<i>; Definition of main function</i>
-define i32 @main() { <i>; i32()* </i>
- <i>; Convert [13 x i8]* to i8 *...</i>
- %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
-
- <i>; Call puts function to write out the string to stdout.</i>
- <a href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i>
- <a href="#i_ret">ret</a> i32 0<br>}
-
-<i>; Named metadata</i>
-!1 = metadata !{i32 41}
-!foo = !{!1, null}
-</pre>
-</div>
-
-<p>This example is made up of a <a href="#globalvars">global variable</a> named
- "<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>" function,
- a <a href="#functionstructure">function definition</a> for
- "<tt>main</tt>" and <a href="#namedmetadatastructure">named metadata</a>
- "<tt>foo"</tt>.</p>
-
-<p>In general, a module is made up of a list of global values, where both
- functions and global variables are global values. Global values are
- represented by a pointer to a memory location (in this case, a pointer to an
- array of char, and a pointer to a function), and have one of the
- following <a href="#linkage">linkage types</a>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="linkage">Linkage Types</a>
-</div>
-
-<div class="doc_text">
-
-<p>All Global Variables and Functions have one of the following types of
- linkage:</p>
-
-<dl>
- <dt><tt><b><a name="linkage_private">private</a></b></tt></dt>
- <dd>Global values with private linkage are only directly accessible by objects
- in the current module. In particular, linking code into a module with an
- private global value may cause the private to be renamed as necessary to
- avoid collisions. Because the symbol is private to the module, all
- references can be updated. This doesn't show up in any symbol table in the
- object file.</dd>
-
- <dt><tt><b><a name="linkage_linker_private">linker_private</a></b></tt></dt>
- <dd>Similar to private, but the symbol is passed through the assembler and
- removed by the linker after evaluation. Note that (unlike private
- symbols) linker_private symbols are subject to coalescing by the linker:
- weak symbols get merged and redefinitions are rejected. However, unlike
- normal strong symbols, they are removed by the linker from the final
- linked image (executable or dynamic library).</dd>
-
- <dt><tt><b><a name="linkage_internal">internal</a></b></tt></dt>
- <dd>Similar to private, but the value shows as a local symbol
- (<tt>STB_LOCAL</tt> in the case of ELF) in the object file. This
- corresponds to the notion of the '<tt>static</tt>' keyword in C.</dd>
-
- <dt><tt><b><a name="linkage_available_externally">available_externally</a></b></tt></dt>
- <dd>Globals with "<tt>available_externally</tt>" linkage are never emitted
- into the object file corresponding to the LLVM module. They exist to
- allow inlining and other optimizations to take place given knowledge of
- the definition of the global, which is known to be somewhere outside the
- module. Globals with <tt>available_externally</tt> linkage are allowed to
- be discarded at will, and are otherwise the same as <tt>linkonce_odr</tt>.
- This linkage type is only allowed on definitions, not declarations.</dd>
-
- <dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt></dt>
- <dd>Globals with "<tt>linkonce</tt>" linkage are merged with other globals of
- the same name when linkage occurs. This can be used to implement
- some forms of inline functions, templates, or other code which must be
- generated in each translation unit that uses it, but where the body may
- be overridden with a more definitive definition later. Unreferenced
- <tt>linkonce</tt> globals are allowed to be discarded. Note that
- <tt>linkonce</tt> linkage does not actually allow the optimizer to
- inline the body of this function into callers because it doesn't know if
- this definition of the function is the definitive definition within the
- program or whether it will be overridden by a stronger definition.
- To enable inlining and other optimizations, use "<tt>linkonce_odr</tt>"
- linkage.</dd>
-
- <dt><tt><b><a name="linkage_weak">weak</a></b></tt></dt>
- <dd>"<tt>weak</tt>" linkage has the same merging semantics as
- <tt>linkonce</tt> linkage, except that unreferenced globals with
- <tt>weak</tt> linkage may not be discarded. This is used for globals that
- are declared "weak" in C source code.</dd>
-
- <dt><tt><b><a name="linkage_common">common</a></b></tt></dt>
- <dd>"<tt>common</tt>" linkage is most similar to "<tt>weak</tt>" linkage, but
- they are used for tentative definitions in C, such as "<tt>int X;</tt>" at
- global scope.
- Symbols with "<tt>common</tt>" linkage are merged in the same way as
- <tt>weak symbols</tt>, and they may not be deleted if unreferenced.
- <tt>common</tt> symbols may not have an explicit section,
- must have a zero initializer, and may not be marked '<a
- href="#globalvars"><tt>constant</tt></a>'. Functions and aliases may not
- have common linkage.</dd>
-
-
- <dt><tt><b><a name="linkage_appending">appending</a></b></tt></dt>
- <dd>"<tt>appending</tt>" linkage may only be applied to global variables of
- pointer to array type. When two global variables with appending linkage
- are linked together, the two global arrays are appended together. This is
- the LLVM, typesafe, equivalent of having the system linker append together
- "sections" with identical names when .o files are linked.</dd>
-
- <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt></dt>
- <dd>The semantics of this linkage follow the ELF object file model: the symbol
- is weak until linked, if not linked, the symbol becomes null instead of
- being an undefined reference.</dd>
-
- <dt><tt><b><a name="linkage_linkonce_odr">linkonce_odr</a></b></tt></dt>
- <dt><tt><b><a name="linkage_weak_odr">weak_odr</a></b></tt></dt>
- <dd>Some languages allow differing globals to be merged, such as two functions
- with different semantics. Other languages, such as <tt>C++</tt>, ensure
- that only equivalent globals are ever merged (the "one definition rule" -
- "ODR"). Such languages can use the <tt>linkonce_odr</tt>
- and <tt>weak_odr</tt> linkage types to indicate that the global will only
- be merged with equivalent globals. These linkage types are otherwise the
- same as their non-<tt>odr</tt> versions.</dd>
-
- <dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
- <dd>If none of the above identifiers are used, the global is externally
- visible, meaning that it participates in linkage and can be used to
- resolve external symbol references.</dd>
-</dl>
-
-<p>The next two types of linkage are targeted for Microsoft Windows platform
- only. They are designed to support importing (exporting) symbols from (to)
- DLLs (Dynamic Link Libraries).</p>
-
-<dl>
- <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt></dt>
- <dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
- or variable via a global pointer to a pointer that is set up by the DLL
- exporting the symbol. On Microsoft Windows targets, the pointer name is
- formed by combining <code>__imp_</code> and the function or variable
- name.</dd>
-
- <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt></dt>
- <dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global
- pointer to a pointer in a DLL, so that it can be referenced with the
- <tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer
- name is formed by combining <code>__imp_</code> and the function or
- variable name.</dd>
-</dl>
-
-<p>For example, since the "<tt>.LC0</tt>" variable is defined to be internal, if
- another module defined a "<tt>.LC0</tt>" variable and was linked with this
- one, one of the two would be renamed, preventing a collision. Since
- "<tt>main</tt>" and "<tt>puts</tt>" are external (i.e., lacking any linkage
- declarations), they are accessible outside of the current module.</p>
-
-<p>It is illegal for a function <i>declaration</i> to have any linkage type
- other than "externally visible", <tt>dllimport</tt>
- or <tt>extern_weak</tt>.</p>
-
-<p>Aliases can have only <tt>external</tt>, <tt>internal</tt>, <tt>weak</tt>
- or <tt>weak_odr</tt> linkages.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="callingconv">Calling Conventions</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM <a href="#functionstructure">functions</a>, <a href="#i_call">calls</a>
- and <a href="#i_invoke">invokes</a> can all have an optional calling
- convention specified for the call. The calling convention of any pair of
- dynamic caller/callee must match, or the behavior of the program is
- undefined. The following calling conventions are supported by LLVM, and more
- may be added in the future:</p>
-
-<dl>
- <dt><b>"<tt>ccc</tt>" - The C calling convention</b>:</dt>
- <dd>This calling convention (the default if no other calling convention is
- specified) matches the target C calling conventions. This calling
- convention supports varargs function calls and tolerates some mismatch in
- the declared prototype and implemented declaration of the function (as
- does normal C).</dd>
-
- <dt><b>"<tt>fastcc</tt>" - The fast calling convention</b>:</dt>
- <dd>This calling convention attempts to make calls as fast as possible
- (e.g. by passing things in registers). This calling convention allows the
- target to use whatever tricks it wants to produce fast code for the
- target, without having to conform to an externally specified ABI
- (Application Binary Interface).
- <a href="CodeGenerator.html#tailcallopt">Tail calls can only be optimized
- when this or the GHC convention is used.</a> This calling convention
- does not support varargs and requires the prototype of all callees to
- exactly match the prototype of the function definition.</dd>
-
- <dt><b>"<tt>coldcc</tt>" - The cold calling convention</b>:</dt>
- <dd>This calling convention attempts to make code in the caller as efficient
- as possible under the assumption that the call is not commonly executed.
- As such, these calls often preserve all registers so that the call does
- not break any live ranges in the caller side. This calling convention
- does not support varargs and requires the prototype of all callees to
- exactly match the prototype of the function definition.</dd>
-
- <dt><b>"<tt>cc <em>10</em></tt>" - GHC convention</b>:</dt>
- <dd>This calling convention has been implemented specifically for use by the
- <a href="http://www.haskell.org/ghc">Glasgow Haskell Compiler (GHC)</a>.
- It passes everything in registers, going to extremes to achieve this by
- disabling callee save registers. This calling convention should not be
- used lightly but only for specific situations such as an alternative to
- the <em>register pinning</em> performance technique often used when
- implementing functional programming languages.At the moment only X86
- supports this convention and it has the following limitations:
- <ul>
- <li>On <em>X86-32</em> only supports up to 4 bit type parameters. No
- floating point types are supported.</li>
- <li>On <em>X86-64</em> only supports up to 10 bit type parameters and
- 6 floating point parameters.</li>
- </ul>
- This calling convention supports
- <a href="CodeGenerator.html#tailcallopt">tail call optimization</a> but
- requires both the caller and callee are using it.
- </dd>
-
- <dt><b>"<tt>cc <<em>n</em>></tt>" - Numbered convention</b>:</dt>
- <dd>Any calling convention may be specified by number, allowing
- target-specific calling conventions to be used. Target specific calling
- conventions start at 64.</dd>
-</dl>
-
-<p>More calling conventions can be added/defined on an as-needed basis, to
- support Pascal conventions or any other well-known target-independent
- convention.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="visibility">Visibility Styles</a>
-</div>
-
-<div class="doc_text">
-
-<p>All Global Variables and Functions have one of the following visibility
- styles:</p>
-
-<dl>
- <dt><b>"<tt>default</tt>" - Default style</b>:</dt>
- <dd>On targets that use the ELF object file format, default visibility means
- that the declaration is visible to other modules and, in shared libraries,
- means that the declared entity may be overridden. On Darwin, default
- visibility means that the declaration is visible to other modules. Default
- visibility corresponds to "external linkage" in the language.</dd>
-
- <dt><b>"<tt>hidden</tt>" - Hidden style</b>:</dt>
- <dd>Two declarations of an object with hidden visibility refer to the same
- object if they are in the same shared object. Usually, hidden visibility
- indicates that the symbol will not be placed into the dynamic symbol
- table, so no other module (executable or shared library) can reference it
- directly.</dd>
-
- <dt><b>"<tt>protected</tt>" - Protected style</b>:</dt>
- <dd>On ELF, protected visibility indicates that the symbol will be placed in
- the dynamic symbol table, but that references within the defining module
- will bind to the local symbol. That is, the symbol cannot be overridden by
- another module.</dd>
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="namedtypes">Named Types</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM IR allows you to specify name aliases for certain types. This can make
- it easier to read the IR and make the IR more condensed (particularly when
- recursive types are involved). An example of a name specification is:</p>
-
-<div class="doc_code">
-<pre>
-%mytype = type { %mytype*, i32 }
-</pre>
-</div>
-
-<p>You may give a name to any <a href="#typesystem">type</a> except
- "<a href="t_void">void</a>". Type name aliases may be used anywhere a type
- is expected with the syntax "%mytype".</p>
-
-<p>Note that type names are aliases for the structural type that they indicate,
- and that you can therefore specify multiple names for the same type. This
- often leads to confusing behavior when dumping out a .ll file. Since LLVM IR
- uses structural typing, the name is not part of the type. When printing out
- LLVM IR, the printer will pick <em>one name</em> to render all types of a
- particular shape. This means that if you have code where two different
- source types end up having the same LLVM type, that the dumper will sometimes
- print the "wrong" or unexpected type. This is an important design point and
- isn't going to change.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="globalvars">Global Variables</a>
-</div>
-
-<div class="doc_text">
-
-<p>Global variables define regions of memory allocated at compilation time
- instead of run-time. Global variables may optionally be initialized, may
- have an explicit section to be placed in, and may have an optional explicit
- alignment specified. A variable may be defined as "thread_local", which
- means that it will not be shared by threads (each thread will have a
- separated copy of the variable). A variable may be defined as a global
- "constant," which indicates that the contents of the variable
- will <b>never</b> be modified (enabling better optimization, allowing the
- global data to be placed in the read-only section of an executable, etc).
- Note that variables that need runtime initialization cannot be marked
- "constant" as there is a store to the variable.</p>
-
-<p>LLVM explicitly allows <em>declarations</em> of global variables to be marked
- constant, even if the final definition of the global is not. This capability
- can be used to enable slightly better optimization of the program, but
- requires the language definition to guarantee that optimizations based on the
- 'constantness' are valid for the translation units that do not include the
- definition.</p>
-
-<p>As SSA values, global variables define pointer values that are in scope
- (i.e. they dominate) all basic blocks in the program. Global variables
- always define a pointer to their "content" type because they describe a
- region of memory, and all memory objects in LLVM are accessed through
- pointers.</p>
-
-<p>A global variable may be declared to reside in a target-specific numbered
- address space. For targets that support them, address spaces may affect how
- optimizations are performed and/or what target instructions are used to
- access the variable. The default address space is zero. The address space
- qualifier must precede any other attributes.</p>
-
-<p>LLVM allows an explicit section to be specified for globals. If the target
- supports it, it will emit globals to the section specified.</p>
-
-<p>An explicit alignment may be specified for a global, which must be a power
- of 2. If not present, or if the alignment is set to zero, the alignment of
- the global is set by the target to whatever it feels convenient. If an
- explicit alignment is specified, the global is forced to have exactly that
- alignment. Targets and optimizers are not allowed to over-align the global
- if the global has an assigned section. In this case, the extra alignment
- could be observable: for example, code could assume that the globals are
- densely packed in their section and try to iterate over them as an array,
- alignment padding would break this iteration.</p>
-
-<p>For example, the following defines a global in a numbered address space with
- an initializer, section, and alignment:</p>
-
-<div class="doc_code">
-<pre>
- at G = addrspace(5) constant float 1.0, section "foo", align 4
-</pre>
-</div>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="functionstructure">Functions</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM function definitions consist of the "<tt>define</tt>" keyword, an
- optional <a href="#linkage">linkage type</a>, an optional
- <a href="#visibility">visibility style</a>, an optional
- <a href="#callingconv">calling convention</a>, a return type, an optional
- <a href="#paramattrs">parameter attribute</a> for the return type, a function
- name, a (possibly empty) argument list (each with optional
- <a href="#paramattrs">parameter attributes</a>), optional
- <a href="#fnattrs">function attributes</a>, an optional section, an optional
- alignment, an optional <a href="#gc">garbage collector name</a>, an opening
- curly brace, a list of basic blocks, and a closing curly brace.</p>
-
-<p>LLVM function declarations consist of the "<tt>declare</tt>" keyword, an
- optional <a href="#linkage">linkage type</a>, an optional
- <a href="#visibility">visibility style</a>, an optional
- <a href="#callingconv">calling convention</a>, a return type, an optional
- <a href="#paramattrs">parameter attribute</a> for the return type, a function
- name, a possibly empty list of arguments, an optional alignment, and an
- optional <a href="#gc">garbage collector name</a>.</p>
-
-<p>A function definition contains a list of basic blocks, forming the CFG
- (Control Flow Graph) for the function. Each basic block may optionally start
- with a label (giving the basic block a symbol table entry), contains a list
- of instructions, and ends with a <a href="#terminators">terminator</a>
- instruction (such as a branch or function return).</p>
-
-<p>The first basic block in a function is special in two ways: it is immediately
- executed on entrance to the function, and it is not allowed to have
- predecessor basic blocks (i.e. there can not be any branches to the entry
- block of a function). Because the block can have no predecessors, it also
- cannot have any <a href="#i_phi">PHI nodes</a>.</p>
-
-<p>LLVM allows an explicit section to be specified for functions. If the target
- supports it, it will emit functions to the section specified.</p>
-
-<p>An explicit alignment may be specified for a function. If not present, or if
- the alignment is set to zero, the alignment of the function is set by the
- target to whatever it feels convenient. If an explicit alignment is
- specified, the function is forced to have at least that much alignment. All
- alignments must be a power of 2.</p>
-
-<h5>Syntax:</h5>
-<div class="doc_code">
-<pre>
-define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>]
- [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>]
- <ResultType> @<FunctionName> ([argument list])
- [<a href="#fnattrs">fn Attrs</a>] [section "name"] [align N]
- [<a href="#gc">gc</a>] { ... }
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="aliasstructure">Aliases</a>
-</div>
-
-<div class="doc_text">
-
-<p>Aliases act as "second name" for the aliasee value (which can be either
- function, global variable, another alias or bitcast of global value). Aliases
- may have an optional <a href="#linkage">linkage type</a>, and an
- optional <a href="#visibility">visibility style</a>.</p>
-
-<h5>Syntax:</h5>
-<div class="doc_code">
-<pre>
-@<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="namedmetadatastructure">Named Metadata</a>
-</div>
-
-<div class="doc_text">
-
-<p>Named metadata is a collection of metadata. <a href="#metadata">Metadata
- nodes</a> (but not metadata strings) and null are the only valid operands for
- a named metadata.</p>
-
-<h5>Syntax:</h5>
-<div class="doc_code">
-<pre>
-!1 = metadata !{metadata !"one"}
-!name = !{null, !1}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="paramattrs">Parameter Attributes</a></div>
-
-<div class="doc_text">
-
-<p>The return type and each parameter of a function type may have a set of
- <i>parameter attributes</i> associated with them. Parameter attributes are
- used to communicate additional information about the result or parameters of
- a function. Parameter attributes are considered to be part of the function,
- not of the function type, so functions with different parameter attributes
- can have the same function type.</p>
-
-<p>Parameter attributes are simple keywords that follow the type specified. If
- multiple parameter attributes are needed, they are space separated. For
- example:</p>
-
-<div class="doc_code">
-<pre>
-declare i32 @printf(i8* noalias nocapture, ...)
-declare i32 @atoi(i8 zeroext)
-declare signext i8 @returns_signed_char()
-</pre>
-</div>
-
-<p>Note that any attributes for the function result (<tt>nounwind</tt>,
- <tt>readonly</tt>) come immediately after the argument list.</p>
-
-<p>Currently, only the following parameter attributes are defined:</p>
-
-<dl>
- <dt><tt><b>zeroext</b></tt></dt>
- <dd>This indicates to the code generator that the parameter or return value
- should be zero-extended to a 32-bit value by the caller (for a parameter)
- or the callee (for a return value).</dd>
-
- <dt><tt><b>signext</b></tt></dt>
- <dd>This indicates to the code generator that the parameter or return value
- should be sign-extended to a 32-bit value by the caller (for a parameter)
- or the callee (for a return value).</dd>
-
- <dt><tt><b>inreg</b></tt></dt>
- <dd>This indicates that this parameter or return value should be treated in a
- special target-dependent fashion during while emitting code for a function
- call or return (usually, by putting it in a register as opposed to memory,
- though some targets use it to distinguish between two different kinds of
- registers). Use of this attribute is target-specific.</dd>
-
- <dt><tt><b><a name="byval">byval</a></b></tt></dt>
- <dd>This indicates that the pointer parameter should really be passed by value
- to the function. The attribute implies that a hidden copy of the pointee
- is made between the caller and the callee, so the callee is unable to
- modify the value in the callee. This attribute is only valid on LLVM
- pointer arguments. It is generally used to pass structs and arrays by
- value, but is also valid on pointers to scalars. The copy is considered
- to belong to the caller not the callee (for example,
- <tt><a href="#readonly">readonly</a></tt> functions should not write to
- <tt>byval</tt> parameters). This is not a valid attribute for return
- values. The byval attribute also supports specifying an alignment with
- the align attribute. This has a target-specific effect on the code
- generator that usually indicates a desired alignment for the synthesized
- stack slot.</dd>
-
- <dt><tt><b>sret</b></tt></dt>
- <dd>This indicates that the pointer parameter specifies the address of a
- structure that is the return value of the function in the source program.
- This pointer must be guaranteed by the caller to be valid: loads and
- stores to the structure may be assumed by the callee to not to trap. This
- may only be applied to the first parameter. This is not a valid attribute
- for return values. </dd>
-
- <dt><tt><b>noalias</b></tt></dt>
- <dd>This indicates that the pointer does not alias any global or any other
- parameter. The caller is responsible for ensuring that this is the
- case. On a function return value, <tt>noalias</tt> additionally indicates
- that the pointer does not alias any other pointers visible to the
- caller. For further details, please see the discussion of the NoAlias
- response in
- <a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias
- analysis</a>.</dd>
-
- <dt><tt><b>nocapture</b></tt></dt>
- <dd>This indicates that the callee does not make any copies of the pointer
- that outlive the callee itself. This is not a valid attribute for return
- values.</dd>
-
- <dt><tt><b>nest</b></tt></dt>
- <dd>This indicates that the pointer parameter can be excised using the
- <a href="#int_trampoline">trampoline intrinsics</a>. This is not a valid
- attribute for return values.</dd>
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="gc">Garbage Collector Names</a>
-</div>
-
-<div class="doc_text">
-
-<p>Each function may specify a garbage collector name, which is simply a
- string:</p>
-
-<div class="doc_code">
-<pre>
-define void @f() gc "name" { ... }
-</pre>
-</div>
-
-<p>The compiler declares the supported values of <i>name</i>. Specifying a
- collector which will cause the compiler to alter its output in order to
- support the named garbage collection algorithm.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="fnattrs">Function Attributes</a>
-</div>
-
-<div class="doc_text">
-
-<p>Function attributes are set to communicate additional information about a
- function. Function attributes are considered to be part of the function, not
- of the function type, so functions with different parameter attributes can
- have the same function type.</p>
-
-<p>Function attributes are simple keywords that follow the type specified. If
- multiple attributes are needed, they are space separated. For example:</p>
-
-<div class="doc_code">
-<pre>
-define void @f() noinline { ... }
-define void @f() alwaysinline { ... }
-define void @f() alwaysinline optsize { ... }
-define void @f() optsize { ... }
-</pre>
-</div>
-
-<dl>
- <dt><tt><b>alignstack(<<em>n</em>>)</b></tt></dt>
- <dd>This attribute indicates that, when emitting the prologue and epilogue,
- the backend should forcibly align the stack pointer. Specify the
- desired alignment, which must be a power of two, in parentheses.
-
- <dt><tt><b>alwaysinline</b></tt></dt>
- <dd>This attribute indicates that the inliner should attempt to inline this
- function into callers whenever possible, ignoring any active inlining size
- threshold for this caller.</dd>
-
- <dt><tt><b>inlinehint</b></tt></dt>
- <dd>This attribute indicates that the source code contained a hint that inlining
- this function is desirable (such as the "inline" keyword in C/C++). It
- is just a hint; it imposes no requirements on the inliner.</dd>
-
- <dt><tt><b>noinline</b></tt></dt>
- <dd>This attribute indicates that the inliner should never inline this
- function in any situation. This attribute may not be used together with
- the <tt>alwaysinline</tt> attribute.</dd>
-
- <dt><tt><b>optsize</b></tt></dt>
- <dd>This attribute suggests that optimization passes and code generator passes
- make choices that keep the code size of this function low, and otherwise
- do optimizations specifically to reduce code size.</dd>
-
- <dt><tt><b>noreturn</b></tt></dt>
- <dd>This function attribute indicates that the function never returns
- normally. This produces undefined behavior at runtime if the function
- ever does dynamically return.</dd>
-
- <dt><tt><b>nounwind</b></tt></dt>
- <dd>This function attribute indicates that the function never returns with an
- unwind or exceptional control flow. If the function does unwind, its
- runtime behavior is undefined.</dd>
-
- <dt><tt><b>readnone</b></tt></dt>
- <dd>This attribute indicates that the function computes its result (or decides
- to unwind an exception) based strictly on its arguments, without
- dereferencing any pointer arguments or otherwise accessing any mutable
- state (e.g. memory, control registers, etc) visible to caller functions.
- It does not write through any pointer arguments
- (including <tt><a href="#byval">byval</a></tt> arguments) and never
- changes any state visible to callers. This means that it cannot unwind
- exceptions by calling the <tt>C++</tt> exception throwing methods, but
- could use the <tt>unwind</tt> instruction.</dd>
-
- <dt><tt><b><a name="readonly">readonly</a></b></tt></dt>
- <dd>This attribute indicates that the function does not write through any
- pointer arguments (including <tt><a href="#byval">byval</a></tt>
- arguments) or otherwise modify any state (e.g. memory, control registers,
- etc) visible to caller functions. It may dereference pointer arguments
- and read state that may be set in the caller. A readonly function always
- returns the same value (or unwinds an exception identically) when called
- with the same set of arguments and global state. It cannot unwind an
- exception by calling the <tt>C++</tt> exception throwing methods, but may
- use the <tt>unwind</tt> instruction.</dd>
-
- <dt><tt><b><a name="ssp">ssp</a></b></tt></dt>
- <dd>This attribute indicates that the function should emit a stack smashing
- protector. It is in the form of a "canary"—a random value placed on
- the stack before the local variables that's checked upon return from the
- function to see if it has been overwritten. A heuristic is used to
- determine if a function needs stack protectors or not.<br>
-<br>
- If a function that has an <tt>ssp</tt> attribute is inlined into a
- function that doesn't have an <tt>ssp</tt> attribute, then the resulting
- function will have an <tt>ssp</tt> attribute.</dd>
-
- <dt><tt><b>sspreq</b></tt></dt>
- <dd>This attribute indicates that the function should <em>always</em> emit a
- stack smashing protector. This overrides
- the <tt><a href="#ssp">ssp</a></tt> function attribute.<br>
-<br>
- If a function that has an <tt>sspreq</tt> attribute is inlined into a
- function that doesn't have an <tt>sspreq</tt> attribute or which has
- an <tt>ssp</tt> attribute, then the resulting function will have
- an <tt>sspreq</tt> attribute.</dd>
-
- <dt><tt><b>noredzone</b></tt></dt>
- <dd>This attribute indicates that the code generator should not use a red
- zone, even if the target-specific ABI normally permits it.</dd>
-
- <dt><tt><b>noimplicitfloat</b></tt></dt>
- <dd>This attributes disables implicit floating point instructions.</dd>
-
- <dt><tt><b>naked</b></tt></dt>
- <dd>This attribute disables prologue / epilogue emission for the function.
- This can have very system-specific consequences.</dd>
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="moduleasm">Module-Level Inline Assembly</a>
-</div>
-
-<div class="doc_text">
-
-<p>Modules may contain "module-level inline asm" blocks, which corresponds to
- the GCC "file scope inline asm" blocks. These blocks are internally
- concatenated by LLVM and treated as a single unit, but may be separated in
- the <tt>.ll</tt> file if desired. The syntax is very simple:</p>
-
-<div class="doc_code">
-<pre>
-module asm "inline asm code goes here"
-module asm "more can go here"
-</pre>
-</div>
-
-<p>The strings can contain any character by escaping non-printable characters.
- The escape sequence used is simply "\xx" where "xx" is the two digit hex code
- for the number.</p>
-
-<p>The inline asm code is simply printed to the machine code .s file when
- assembly code is generated.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="datalayout">Data Layout</a>
-</div>
-
-<div class="doc_text">
-
-<p>A module may specify a target specific data layout string that specifies how
- data is to be laid out in memory. The syntax for the data layout is
- simply:</p>
-
-<div class="doc_code">
-<pre>
-target datalayout = "<i>layout specification</i>"
-</pre>
-</div>
-
-<p>The <i>layout specification</i> consists of a list of specifications
- separated by the minus sign character ('-'). Each specification starts with
- a letter and may include other information after the letter to define some
- aspect of the data layout. The specifications accepted are as follows:</p>
-
-<dl>
- <dt><tt>E</tt></dt>
- <dd>Specifies that the target lays out data in big-endian form. That is, the
- bits with the most significance have the lowest address location.</dd>
-
- <dt><tt>e</tt></dt>
- <dd>Specifies that the target lays out data in little-endian form. That is,
- the bits with the least significance have the lowest address
- location.</dd>
-
- <dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
- <i>preferred</i> alignments. All sizes are in bits. Specifying
- the <i>pref</i> alignment is optional. If omitted, the
- preceding <tt>:</tt> should be omitted too.</dd>
-
- <dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the alignment for an integer type of a given bit
- <i>size</i>. The value of <i>size</i> must be in the range [1,2^23).</dd>
-
- <dt><tt>v<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the alignment for a vector type of a given bit
- <i>size</i>.</dd>
-
- <dt><tt>f<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the alignment for a floating point type of a given bit
- <i>size</i>. The value of <i>size</i> must be either 32 (float) or 64
- (double).</dd>
-
- <dt><tt>a<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the alignment for an aggregate type of a given bit
- <i>size</i>.</dd>
-
- <dt><tt>s<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
- <dd>This specifies the alignment for a stack object of a given bit
- <i>size</i>.</dd>
-
- <dt><tt>n<i>size1</i>:<i>size2</i>:<i>size3</i>...</tt></dt>
- <dd>This specifies a set of native integer widths for the target CPU
- in bits. For example, it might contain "n32" for 32-bit PowerPC,
- "n32:64" for PowerPC 64, or "n8:16:32:64" for X86-64. Elements of
- this set are considered to support most general arithmetic
- operations efficiently.</dd>
-</dl>
-
-<p>When constructing the data layout for a given target, LLVM starts with a
- default set of specifications which are then (possibly) overridden by the
- specifications in the <tt>datalayout</tt> keyword. The default specifications
- are given in this list:</p>
-
-<ul>
- <li><tt>E</tt> - big endian</li>
- <li><tt>p:64:64:64</tt> - 64-bit pointers with 64-bit alignment</li>
- <li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li>
- <li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li>
- <li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li>
- <li><tt>i32:32:32</tt> - i32 is 32-bit aligned</li>
- <li><tt>i64:32:64</tt> - i64 has ABI alignment of 32-bits but preferred
- alignment of 64-bits</li>
- <li><tt>f32:32:32</tt> - float is 32-bit aligned</li>
- <li><tt>f64:64:64</tt> - double is 64-bit aligned</li>
- <li><tt>v64:64:64</tt> - 64-bit vector is 64-bit aligned</li>
- <li><tt>v128:128:128</tt> - 128-bit vector is 128-bit aligned</li>
- <li><tt>a0:0:1</tt> - aggregates are 8-bit aligned</li>
- <li><tt>s0:64:64</tt> - stack objects are 64-bit aligned</li>
-</ul>
-
-<p>When LLVM is determining the alignment for a given type, it uses the
- following rules:</p>
-
-<ol>
- <li>If the type sought is an exact match for one of the specifications, that
- specification is used.</li>
-
- <li>If no match is found, and the type sought is an integer type, then the
- smallest integer type that is larger than the bitwidth of the sought type
- is used. If none of the specifications are larger than the bitwidth then
- the the largest integer type is used. For example, given the default
- specifications above, the i7 type will use the alignment of i8 (next
- largest) while both i65 and i256 will use the alignment of i64 (largest
- specified).</li>
-
- <li>If no match is found, and the type sought is a vector type, then the
- largest vector type that is smaller than the sought vector type will be
- used as a fall back. This happens because <128 x double> can be
- implemented in terms of 64 <2 x double>, for example.</li>
-</ol>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="pointeraliasing">Pointer Aliasing Rules</a>
-</div>
-
-<div class="doc_text">
-
-<p>Any memory access must be done through a pointer value associated
-with an address range of the memory access, otherwise the behavior
-is undefined. Pointer values are associated with address ranges
-according to the following rules:</p>
-
-<ul>
- <li>A pointer value formed from a
- <tt><a href="#i_getelementptr">getelementptr</a></tt> instruction
- is associated with the addresses associated with the first operand
- of the <tt>getelementptr</tt>.</li>
- <li>An address of a global variable is associated with the address
- range of the variable's storage.</li>
- <li>The result value of an allocation instruction is associated with
- the address range of the allocated storage.</li>
- <li>A null pointer in the default address-space is associated with
- no address.</li>
- <li>A pointer value formed by an
- <tt><a href="#i_inttoptr">inttoptr</a></tt> is associated with all
- address ranges of all pointer values that contribute (directly or
- indirectly) to the computation of the pointer's value.</li>
- <li>The result value of a
- <tt><a href="#i_bitcast">bitcast</a></tt> is associated with all
- addresses associated with the operand of the <tt>bitcast</tt>.</li>
- <li>An integer constant other than zero or a pointer value returned
- from a function not defined within LLVM may be associated with address
- ranges allocated through mechanisms other than those provided by
- LLVM. Such ranges shall not overlap with any ranges of addresses
- allocated by mechanisms provided by LLVM.</li>
- </ul>
-
-<p>LLVM IR does not associate types with memory. The result type of a
-<tt><a href="#i_load">load</a></tt> merely indicates the size and
-alignment of the memory from which to load, as well as the
-interpretation of the value. The first operand of a
-<tt><a href="#i_store">store</a></tt> similarly only indicates the size
-and alignment of the store.</p>
-
-<p>Consequently, type-based alias analysis, aka TBAA, aka
-<tt>-fstrict-aliasing</tt>, is not applicable to general unadorned
-LLVM IR. <a href="#metadata">Metadata</a> may be used to encode
-additional information which specialized optimization passes may use
-to implement type-based alias analysis.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="volatile">Volatile Memory Accesses</a>
-</div>
-
-<div class="doc_text">
-
-<p>Certain memory accesses, such as <a href="#i_load"><tt>load</tt></a>s, <a
-href="#i_store"><tt>store</tt></a>s, and <a
-href="#int_memcpy"><tt>llvm.memcpy</tt></a>s may be marked <tt>volatile</tt>.
-The optimizers must not change the number of volatile operations or change their
-order of execution relative to other volatile operations. The optimizers
-<i>may</i> change the order of volatile operations relative to non-volatile
-operations. This is not Java's "volatile" and has no cross-thread
-synchronization behavior.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="typesystem">Type System</a> </div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM type system is one of the most important features of the
- intermediate representation. Being typed enables a number of optimizations
- to be performed on the intermediate representation directly, without having
- to do extra analyses on the side before the transformation. A strong type
- system makes it easier to read the generated code and enables novel analyses
- and transformations that are not feasible to perform on normal three address
- code representations.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="t_classifications">Type
-Classifications</a> </div>
-
-<div class="doc_text">
-
-<p>The types fall into a few useful classifications:</p>
-
-<table border="1" cellspacing="0" cellpadding="4">
- <tbody>
- <tr><th>Classification</th><th>Types</th></tr>
- <tr>
- <td><a href="#t_integer">integer</a></td>
- <td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td>
- </tr>
- <tr>
- <td><a href="#t_floating">floating point</a></td>
- <td><tt>float, double, x86_fp80, fp128, ppc_fp128</tt></td>
- </tr>
- <tr>
- <td><a name="t_firstclass">first class</a></td>
- <td><a href="#t_integer">integer</a>,
- <a href="#t_floating">floating point</a>,
- <a href="#t_pointer">pointer</a>,
- <a href="#t_vector">vector</a>,
- <a href="#t_struct">structure</a>,
- <a href="#t_union">union</a>,
- <a href="#t_array">array</a>,
- <a href="#t_label">label</a>,
- <a href="#t_metadata">metadata</a>.
- </td>
- </tr>
- <tr>
- <td><a href="#t_primitive">primitive</a></td>
- <td><a href="#t_label">label</a>,
- <a href="#t_void">void</a>,
- <a href="#t_floating">floating point</a>,
- <a href="#t_metadata">metadata</a>.</td>
- </tr>
- <tr>
- <td><a href="#t_derived">derived</a></td>
- <td><a href="#t_array">array</a>,
- <a href="#t_function">function</a>,
- <a href="#t_pointer">pointer</a>,
- <a href="#t_struct">structure</a>,
- <a href="#t_pstruct">packed structure</a>,
- <a href="#t_union">union</a>,
- <a href="#t_vector">vector</a>,
- <a href="#t_opaque">opaque</a>.
- </td>
- </tr>
- </tbody>
-</table>
-
-<p>The <a href="#t_firstclass">first class</a> types are perhaps the most
- important. Values of these types are the only ones which can be produced by
- instructions.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="t_primitive">Primitive Types</a> </div>
-
-<div class="doc_text">
-
-<p>The primitive types are the fundamental building blocks of the LLVM
- system.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_integer">Integer Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The integer type is a very simple type that simply specifies an arbitrary
- bit width for the integer type desired. Any bit width from 1 bit to
- 2<sup>23</sup>-1 (about 8 million) can be specified.</p>
-
-<h5>Syntax:</h5>
-<pre>
- iN
-</pre>
-
-<p>The number of bits the integer will occupy is specified by the <tt>N</tt>
- value.</p>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>i1</tt></td>
- <td class="left">a single-bit integer.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>i32</tt></td>
- <td class="left">a 32-bit integer.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>i1942652</tt></td>
- <td class="left">a really big integer of over 1 million bits.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_floating">Floating Point Types</a> </div>
-
-<div class="doc_text">
-
-<table>
- <tbody>
- <tr><th>Type</th><th>Description</th></tr>
- <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
- <tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
- <tr><td><tt>fp128</tt></td><td>128-bit floating point value (112-bit mantissa)</td></tr>
- <tr><td><tt>x86_fp80</tt></td><td>80-bit floating point value (X87)</td></tr>
- <tr><td><tt>ppc_fp128</tt></td><td>128-bit floating point value (two 64-bits)</td></tr>
- </tbody>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_void">Void Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The void type does not represent any value and has no size.</p>
-
-<h5>Syntax:</h5>
-<pre>
- void
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_label">Label Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The label type represents code labels.</p>
-
-<h5>Syntax:</h5>
-<pre>
- label
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_metadata">Metadata Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The metadata type represents embedded metadata. No derived types may be
- created from metadata except for <a href="#t_function">function</a>
- arguments.
-
-<h5>Syntax:</h5>
-<pre>
- metadata
-</pre>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="t_derived">Derived Types</a> </div>
-
-<div class="doc_text">
-
-<p>The real power in LLVM comes from the derived types in the system. This is
- what allows a programmer to represent arrays, functions, pointers, and other
- useful types. Each of these types contain one or more element types which
- may be a primitive type, or another derived type. For example, it is
- possible to have a two dimensional array, using an array as the element type
- of another array.</p>
-
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_aggregate">Aggregate Types</a> </div>
-
-<div class="doc_text">
-
-<p>Aggregate Types are a subset of derived types that can contain multiple
- member types. <a href="#t_array">Arrays</a>,
- <a href="#t_struct">structs</a>, <a href="#t_vector">vectors</a> and
- <a href="#t_union">unions</a> are aggregate types.</p>
-
-</div>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_array">Array Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The array type is a very simple derived type that arranges elements
- sequentially in memory. The array type requires a size (number of elements)
- and an underlying data type.</p>
-
-<h5>Syntax:</h5>
-<pre>
- [<# elements> x <elementtype>]
-</pre>
-
-<p>The number of elements is a constant integer value; <tt>elementtype</tt> may
- be any type with a size.</p>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>[40 x i32]</tt></td>
- <td class="left">Array of 40 32-bit integer values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>[41 x i32]</tt></td>
- <td class="left">Array of 41 32-bit integer values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>[4 x i8]</tt></td>
- <td class="left">Array of 4 8-bit integer values.</td>
- </tr>
-</table>
-<p>Here are some examples of multidimensional arrays:</p>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>[3 x [4 x i32]]</tt></td>
- <td class="left">3x4 array of 32-bit integer values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>[12 x [10 x float]]</tt></td>
- <td class="left">12x10 array of single precision floating point values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>[2 x [3 x [4 x i16]]]</tt></td>
- <td class="left">2x3x4 array of 16-bit integer values.</td>
- </tr>
-</table>
-
-<p>There is no restriction on indexing beyond the end of the array implied by
- a static type (though there are restrictions on indexing beyond the bounds
- of an allocated object in some cases). This means that single-dimension
- 'variable sized array' addressing can be implemented in LLVM with a zero
- length array type. An implementation of 'pascal style arrays' in LLVM could
- use the type "<tt>{ i32, [0 x float]}</tt>", for example.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_function">Function Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The function type can be thought of as a function signature. It consists of
- a return type and a list of formal parameter types. The return type of a
- function type is a scalar type, a void type, a struct type, or a union
- type. If the return type is a struct type then all struct elements must be
- of first class types, and the struct must have at least one element.</p>
-
-<h5>Syntax:</h5>
-<pre>
- <returntype> (<parameter list>)
-</pre>
-
-<p>...where '<tt><parameter list></tt>' is a comma-separated list of type
- specifiers. Optionally, the parameter list may include a type <tt>...</tt>,
- which indicates that the function takes a variable number of arguments.
- Variable argument functions can access their arguments with
- the <a href="#int_varargs">variable argument handling intrinsic</a>
- functions. '<tt><returntype></tt>' is any type except
- <a href="#t_label">label</a>.</p>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>i32 (i32)</tt></td>
- <td class="left">function taking an <tt>i32</tt>, returning an <tt>i32</tt>
- </td>
- </tr><tr class="layout">
- <td class="left"><tt>float (i16, i32 *) *
- </tt></td>
- <td class="left"><a href="#t_pointer">Pointer</a> to a function that takes
- an <tt>i16</tt> and a <a href="#t_pointer">pointer</a> to <tt>i32</tt>,
- returning <tt>float</tt>.
- </td>
- </tr><tr class="layout">
- <td class="left"><tt>i32 (i8*, ...)</tt></td>
- <td class="left">A vararg function that takes at least one
- <a href="#t_pointer">pointer</a> to <tt>i8 </tt> (char in C),
- which returns an integer. This is the signature for <tt>printf</tt> in
- LLVM.
- </td>
- </tr><tr class="layout">
- <td class="left"><tt>{i32, i32} (i32)</tt></td>
- <td class="left">A function taking an <tt>i32</tt>, returning a
- <a href="#t_struct">structure</a> containing two <tt>i32</tt> values
- </td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_struct">Structure Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The structure type is used to represent a collection of data members together
- in memory. The packing of the field types is defined to match the ABI of the
- underlying processor. The elements of a structure may be any type that has a
- size.</p>
-
-<p>Structures in memory are accessed using '<tt><a href="#i_load">load</a></tt>'
- and '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a field
- with the '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.
- Structures in registers are accessed using the
- '<tt><a href="#i_extractvalue">extractvalue</a></tt>' and
- '<tt><a href="#i_insertvalue">insertvalue</a></tt>' instructions.</p>
-<h5>Syntax:</h5>
-<pre>
- { <type list> }
-</pre>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>{ i32, i32, i32 }</tt></td>
- <td class="left">A triple of three <tt>i32</tt> values</td>
- </tr><tr class="layout">
- <td class="left"><tt>{ float, i32 (i32) * }</tt></td>
- <td class="left">A pair, where the first element is a <tt>float</tt> and the
- second element is a <a href="#t_pointer">pointer</a> to a
- <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
- an <tt>i32</tt>.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_pstruct">Packed Structure Type</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The packed structure type is used to represent a collection of data members
- together in memory. There is no padding between fields. Further, the
- alignment of a packed structure is 1 byte. The elements of a packed
- structure may be any type that has a size.</p>
-
-<p>Structures are accessed using '<tt><a href="#i_load">load</a></tt> and
- '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a field with
- the '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.</p>
-
-<h5>Syntax:</h5>
-<pre>
- < { <type list> } >
-</pre>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>< { i32, i32, i32 } ></tt></td>
- <td class="left">A triple of three <tt>i32</tt> values</td>
- </tr><tr class="layout">
- <td class="left">
-<tt>< { float, i32 (i32)* } ></tt></td>
- <td class="left">A pair, where the first element is a <tt>float</tt> and the
- second element is a <a href="#t_pointer">pointer</a> to a
- <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
- an <tt>i32</tt>.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_union">Union Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>A union type describes an object with size and alignment suitable for
- an object of any one of a given set of types (also known as an "untagged"
- union). It is similar in concept and usage to a
- <a href="#t_struct">struct</a>, except that all members of the union
- have an offset of zero. The elements of a union may be any type that has a
- size. Unions must have at least one member - empty unions are not allowed.
- </p>
-
-<p>The size of the union as a whole will be the size of its largest member,
- and the alignment requirements of the union as a whole will be the largest
- alignment requirement of any member.</p>
-
-<p>Union members are accessed using '<tt><a href="#i_load">load</a></tt> and
- '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a field with
- the '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.
- Since all members are at offset zero, the getelementptr instruction does
- not affect the address, only the type of the resulting pointer.</p>
-
-<h5>Syntax:</h5>
-<pre>
- union { <type list> }
-</pre>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>union { i32, i32*, float }</tt></td>
- <td class="left">A union of three types: an <tt>i32</tt>, a pointer to
- an <tt>i32</tt>, and a <tt>float</tt>.</td>
- </tr><tr class="layout">
- <td class="left">
- <tt>union { float, i32 (i32) * }</tt></td>
- <td class="left">A union, where the first element is a <tt>float</tt> and the
- second element is a <a href="#t_pointer">pointer</a> to a
- <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
- an <tt>i32</tt>.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_pointer">Pointer Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>The pointer type is used to specify memory locations.
- Pointers are commonly used to reference objects in memory.</p>
-
-<p>Pointer types may have an optional address space attribute defining the
- numbered address space where the pointed-to object resides. The default
- address space is number zero. The semantics of non-zero address
- spaces are target-specific.</p>
-
-<p>Note that LLVM does not permit pointers to void (<tt>void*</tt>) nor does it
- permit pointers to labels (<tt>label*</tt>). Use <tt>i8*</tt> instead.</p>
-
-<h5>Syntax:</h5>
-<pre>
- <type> *
-</pre>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>[4 x i32]*</tt></td>
- <td class="left">A <a href="#t_pointer">pointer</a> to <a
- href="#t_array">array</a> of four <tt>i32</tt> values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>i32 (i32 *) *</tt></td>
- <td class="left"> A <a href="#t_pointer">pointer</a> to a <a
- href="#t_function">function</a> that takes an <tt>i32*</tt>, returning an
- <tt>i32</tt>.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>i32 addrspace(5)*</tt></td>
- <td class="left">A <a href="#t_pointer">pointer</a> to an <tt>i32</tt> value
- that resides in address space #5.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_vector">Vector Type</a> </div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>A vector type is a simple derived type that represents a vector of elements.
- Vector types are used when multiple primitive data are operated in parallel
- using a single instruction (SIMD). A vector type requires a size (number of
- elements) and an underlying primitive data type. Vector types are considered
- <a href="#t_firstclass">first class</a>.</p>
-
-<h5>Syntax:</h5>
-<pre>
- < <# elements> x <elementtype> >
-</pre>
-
-<p>The number of elements is a constant integer value; elementtype may be any
- integer or floating point type.</p>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt><4 x i32></tt></td>
- <td class="left">Vector of 4 32-bit integer values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt><8 x float></tt></td>
- <td class="left">Vector of 8 32-bit floating-point values.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt><2 x i64></tt></td>
- <td class="left">Vector of 2 64-bit integer values.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="t_opaque">Opaque Type</a> </div>
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>Opaque types are used to represent unknown types in the system. This
- corresponds (for example) to the C notion of a forward declared structure
- type. In LLVM, opaque types can eventually be resolved to any type (not just
- a structure type).</p>
-
-<h5>Syntax:</h5>
-<pre>
- opaque
-</pre>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>opaque</tt></td>
- <td class="left">An opaque type.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="t_uprefs">Type Up-references</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Overview:</h5>
-<p>An "up reference" allows you to refer to a lexically enclosing type without
- requiring it to have a name. For instance, a structure declaration may
- contain a pointer to any of the types it is lexically a member of. Example
- of up references (with their equivalent as named type declarations)
- include:</p>
-
-<pre>
- { \2 * } %x = type { %x* }
- { \2 }* %y = type { %y }*
- \1* %z = type %z*
-</pre>
-
-<p>An up reference is needed by the asmprinter for printing out cyclic types
- when there is no declared name for a type in the cycle. Because the
- asmprinter does not want to print out an infinite type string, it needs a
- syntax to handle recursive types that have no names (all names are optional
- in llvm IR).</p>
-
-<h5>Syntax:</h5>
-<pre>
- \<level>
-</pre>
-
-<p>The level is the count of the lexical type that is being referred to.</p>
-
-<h5>Examples:</h5>
-<table class="layout">
- <tr class="layout">
- <td class="left"><tt>\1*</tt></td>
- <td class="left">Self-referential pointer.</td>
- </tr>
- <tr class="layout">
- <td class="left"><tt>{ { \3*, i8 }, i32 }</tt></td>
- <td class="left">Recursive structure where the upref refers to the out-most
- structure.</td>
- </tr>
-</table>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="constants">Constants</a> </div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>LLVM has several different basic types of constants. This section describes
- them all and their syntax.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="simpleconstants">Simple Constants</a></div>
-
-<div class="doc_text">
-
-<dl>
- <dt><b>Boolean constants</b></dt>
- <dd>The two strings '<tt>true</tt>' and '<tt>false</tt>' are both valid
- constants of the <tt><a href="#t_integer">i1</a></tt> type.</dd>
-
- <dt><b>Integer constants</b></dt>
- <dd>Standard integers (such as '4') are constants of
- the <a href="#t_integer">integer</a> type. Negative numbers may be used
- with integer types.</dd>
-
- <dt><b>Floating point constants</b></dt>
- <dd>Floating point constants use standard decimal notation (e.g. 123.421),
- exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
- notation (see below). The assembler requires the exact decimal value of a
- floating-point constant. For example, the assembler accepts 1.25 but
- rejects 1.3 because 1.3 is a repeating decimal in binary. Floating point
- constants must have a <a href="#t_floating">floating point</a> type. </dd>
-
- <dt><b>Null pointer constants</b></dt>
- <dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant
- and must be of <a href="#t_pointer">pointer type</a>.</dd>
-</dl>
-
-<p>The one non-intuitive notation for constants is the hexadecimal form of
- floating point constants. For example, the form '<tt>double
- 0x432ff973cafa8000</tt>' is equivalent to (but harder to read than)
- '<tt>double 4.5e+15</tt>'. The only time hexadecimal floating point
- constants are required (and the only time that they are generated by the
- disassembler) is when a floating point constant must be emitted but it cannot
- be represented as a decimal floating point number in a reasonable number of
- digits. For example, NaN's, infinities, and other special values are
- represented in their IEEE hexadecimal format so that assembly and disassembly
- do not cause any bits to change in the constants.</p>
-
-<p>When using the hexadecimal form, constants of types float and double are
- represented using the 16-digit form shown above (which matches the IEEE754
- representation for double); float values must, however, be exactly
- representable as IEE754 single precision. Hexadecimal format is always used
- for long double, and there are three forms of long double. The 80-bit format
- used by x86 is represented as <tt>0xK</tt> followed by 20 hexadecimal digits.
- The 128-bit format used by PowerPC (two adjacent doubles) is represented
- by <tt>0xM</tt> followed by 32 hexadecimal digits. The IEEE 128-bit format
- is represented by <tt>0xL</tt> followed by 32 hexadecimal digits; no
- currently supported target uses this format. Long doubles will only work if
- they match the long double format on your target. All hexadecimal formats
- are big-endian (sign bit at the left).</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-<a name="aggregateconstants"></a> <!-- old anchor -->
-<a name="complexconstants">Complex Constants</a>
-</div>
-
-<div class="doc_text">
-
-<p>Complex constants are a (potentially recursive) combination of simple
- constants and smaller complex constants.</p>
-
-<dl>
- <dt><b>Structure constants</b></dt>
- <dd>Structure constants are represented with notation similar to structure
- type definitions (a comma separated list of elements, surrounded by braces
- (<tt>{}</tt>)). For example: "<tt>{ i32 4, float 17.0, i32* @G }</tt>",
- where "<tt>@G</tt>" is declared as "<tt>@G = external global i32</tt>".
- Structure constants must have <a href="#t_struct">structure type</a>, and
- the number and types of elements must match those specified by the
- type.</dd>
-
- <dt><b>Union constants</b></dt>
- <dd>Union constants are represented with notation similar to a structure with
- a single element - that is, a single typed element surrounded
- by braces (<tt>{}</tt>)). For example: "<tt>{ i32 4 }</tt>". The
- <a href="#t_union">union type</a> can be initialized with a single-element
- struct as long as the type of the struct element matches the type of
- one of the union members.</dd>
-
- <dt><b>Array constants</b></dt>
- <dd>Array constants are represented with notation similar to array type
- definitions (a comma separated list of elements, surrounded by square
- brackets (<tt>[]</tt>)). For example: "<tt>[ i32 42, i32 11, i32 74
- ]</tt>". Array constants must have <a href="#t_array">array type</a>, and
- the number and types of elements must match those specified by the
- type.</dd>
-
- <dt><b>Vector constants</b></dt>
- <dd>Vector constants are represented with notation similar to vector type
- definitions (a comma separated list of elements, surrounded by
- less-than/greater-than's (<tt><></tt>)). For example: "<tt>< i32
- 42, i32 11, i32 74, i32 100 ></tt>". Vector constants must
- have <a href="#t_vector">vector type</a>, and the number and types of
- elements must match those specified by the type.</dd>
-
- <dt><b>Zero initialization</b></dt>
- <dd>The string '<tt>zeroinitializer</tt>' can be used to zero initialize a
- value to zero of <em>any</em> type, including scalar and
- <a href="#t_aggregate">aggregate</a> types.
- This is often used to avoid having to print large zero initializers
- (e.g. for large arrays) and is always exactly equivalent to using explicit
- zero initializers.</dd>
-
- <dt><b>Metadata node</b></dt>
- <dd>A metadata node is a structure-like constant with
- <a href="#t_metadata">metadata type</a>. For example: "<tt>metadata !{
- i32 0, metadata !"test" }</tt>". Unlike other constants that are meant to
- be interpreted as part of the instruction stream, metadata is a place to
- attach additional information such as debug info.</dd>
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="globalconstants">Global Variable and Function Addresses</a>
-</div>
-
-<div class="doc_text">
-
-<p>The addresses of <a href="#globalvars">global variables</a>
- and <a href="#functionstructure">functions</a> are always implicitly valid
- (link-time) constants. These constants are explicitly referenced when
- the <a href="#identifiers">identifier for the global</a> is used and always
- have <a href="#t_pointer">pointer</a> type. For example, the following is a
- legal LLVM file:</p>
-
-<div class="doc_code">
-<pre>
- at X = global i32 17
- at Y = global i32 42
- at Z = global [2 x i32*] [ i32* @X, i32* @Y ]
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="undefvalues">Undefined Values</a></div>
-<div class="doc_text">
-
-<p>The string '<tt>undef</tt>' can be used anywhere a constant is expected, and
- indicates that the user of the value may receive an unspecified bit-pattern.
- Undefined values may be of any type (other than label or void) and be used
- anywhere a constant is permitted.</p>
-
-<p>Undefined values are useful because they indicate to the compiler that the
- program is well defined no matter what value is used. This gives the
- compiler more freedom to optimize. Here are some examples of (potentially
- surprising) transformations that are valid (in pseudo IR):</p>
-
-
-<div class="doc_code">
-<pre>
- %A = add %X, undef
- %B = sub %X, undef
- %C = xor %X, undef
-Safe:
- %A = undef
- %B = undef
- %C = undef
-</pre>
-</div>
-
-<p>This is safe because all of the output bits are affected by the undef bits.
-Any output bit can have a zero or one depending on the input bits.</p>
-
-<div class="doc_code">
-<pre>
- %A = or %X, undef
- %B = and %X, undef
-Safe:
- %A = -1
- %B = 0
-Unsafe:
- %A = undef
- %B = undef
-</pre>
-</div>
-
-<p>These logical operations have bits that are not always affected by the input.
-For example, if "%X" has a zero bit, then the output of the 'and' operation will
-always be a zero, no matter what the corresponding bit from the undef is. As
-such, it is unsafe to optimize or assume that the result of the and is undef.
-However, it is safe to assume that all bits of the undef could be 0, and
-optimize the and to 0. Likewise, it is safe to assume that all the bits of
-the undef operand to the or could be set, allowing the or to be folded to
--1.</p>
-
-<div class="doc_code">
-<pre>
- %A = select undef, %X, %Y
- %B = select undef, 42, %Y
- %C = select %X, %Y, undef
-Safe:
- %A = %X (or %Y)
- %B = 42 (or %Y)
- %C = %Y
-Unsafe:
- %A = undef
- %B = undef
- %C = undef
-</pre>
-</div>
-
-<p>This set of examples show that undefined select (and conditional branch)
-conditions can go "either way" but they have to come from one of the two
-operands. In the %A example, if %X and %Y were both known to have a clear low
-bit, then %A would have to have a cleared low bit. However, in the %C example,
-the optimizer is allowed to assume that the undef operand could be the same as
-%Y, allowing the whole select to be eliminated.</p>
-
-
-<div class="doc_code">
-<pre>
- %A = xor undef, undef
-
- %B = undef
- %C = xor %B, %B
-
- %D = undef
- %E = icmp lt %D, 4
- %F = icmp gte %D, 4
-
-Safe:
- %A = undef
- %B = undef
- %C = undef
- %D = undef
- %E = undef
- %F = undef
-</pre>
-</div>
-
-<p>This example points out that two undef operands are not necessarily the same.
-This can be surprising to people (and also matches C semantics) where they
-assume that "X^X" is always zero, even if X is undef. This isn't true for a
-number of reasons, but the short answer is that an undef "variable" can
-arbitrarily change its value over its "live range". This is true because the
-"variable" doesn't actually <em>have a live range</em>. Instead, the value is
-logically read from arbitrary registers that happen to be around when needed,
-so the value is not necessarily consistent over time. In fact, %A and %C need
-to have the same semantics or the core LLVM "replace all uses with" concept
-would not hold.</p>
-
-<div class="doc_code">
-<pre>
- %A = fdiv undef, %X
- %B = fdiv %X, undef
-Safe:
- %A = undef
-b: unreachable
-</pre>
-</div>
-
-<p>These examples show the crucial difference between an <em>undefined
-value</em> and <em>undefined behavior</em>. An undefined value (like undef) is
-allowed to have an arbitrary bit-pattern. This means that the %A operation
-can be constant folded to undef because the undef could be an SNaN, and fdiv is
-not (currently) defined on SNaN's. However, in the second example, we can make
-a more aggressive assumption: because the undef is allowed to be an arbitrary
-value, we are allowed to assume that it could be zero. Since a divide by zero
-has <em>undefined behavior</em>, we are allowed to assume that the operation
-does not execute at all. This allows us to delete the divide and all code after
-it: since the undefined operation "can't happen", the optimizer can assume that
-it occurs in dead code.
-</p>
-
-<div class="doc_code">
-<pre>
-a: store undef -> %X
-b: store %X -> undef
-Safe:
-a: <deleted>
-b: unreachable
-</pre>
-</div>
-
-<p>These examples reiterate the fdiv example: a store "of" an undefined value
-can be assumed to not have any effect: we can assume that the value is
-overwritten with bits that happen to match what was already there. However, a
-store "to" an undefined location could clobber arbitrary memory, therefore, it
-has undefined behavior.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="trapvalues">Trap Values</a></div>
-<div class="doc_text">
-
-<p>Trap values are similar to <a href="#undefvalues">undef values</a>, however
- instead of representing an unspecified bit pattern, they represent the
- fact that an instruction or constant expression which cannot evoke side
- effects has nevertheless detected a condition which results in undefined
- behavior.</p>
-
-<p>There is currently no way of representing a trap value in the IR; they
- only exist when produced by operations such as
- <a href="#i_add"><tt>add</tt></a> with the <tt>nsw</tt> flag.</p>
-
-<p>Trap value behavior is defined in terms of value <i>dependence</i>:</p>
-
-<p>
-<ul>
-<li>Values other than <a href="#i_phi"><tt>phi</tt></a> nodes depend on
- their operands.</li>
-
-<li><a href="#i_phi"><tt>Phi</tt></a> nodes depend on the operand corresponding
- to their dynamic predecessor basic block.</li>
-
-<li>Function arguments depend on the corresponding actual argument values in
- the dynamic callers of their functions.</li>
-
-<li><a href="#i_call"><tt>Call</tt></a> instructions depend on the
- <a href="#i_ret"><tt>ret</tt></a> instructions that dynamically transfer
- control back to them.</li>
-
-<li><a href="#i_invoke"><tt>Invoke</tt></a> instructions depend on the
- <a href="#i_ret"><tt>ret</tt></a>, <a href="#i_unwind"><tt>unwind</tt></a>,
- or exception-throwing call instructions that dynamically transfer control
- back to them.</li>
-
-<li>Non-volatile loads and stores depend on the most recent stores to all of the
- referenced memory addresses, following the order in the IR
- (including loads and stores implied by intrinsics such as
- <a href="#int_memcpy"><tt>@llvm.memcpy</tt></a>.)</li>
-
-<!-- TODO: In the case of multiple threads, this only applies if the store
- "happens-before" the load or store. -->
-
-<!-- TODO: floating-point exception state -->
-
-<li>An instruction with externally visible side effects depends on the most
- recent preceding instruction with externally visible side effects, following
- the order in the IR. (This includes volatile loads and stores.)</li>
-
-<li>An instruction <i>control-depends</i> on a
- <a href="#terminators">terminator instruction</a>
- if the terminator instruction has multiple successors and the instruction
- is always executed when control transfers to one of the successors, and
- may not be executed when control is transfered to another.</li>
-
-<li>Dependence is transitive.</li>
-
-</ul>
-</p>
-
-<p>Whenever a trap value is generated, all values which depend on it evaluate
- to trap. If they have side effects, the evoke their side effects as if each
- operand with a trap value were undef. If they have externally-visible side
- effects, the behavior is undefined.</p>
-
-<p>Here are some examples:</p>
-
-<div class="doc_code">
-<pre>
-entry:
- %trap = sub nuw i32 0, 1 ; Results in a trap value.
- %still_trap = and i32 %trap, 0 ; Whereas (and i32 undef, 0) would return 0.
- %trap_yet_again = getelementptr i32* @h, i32 %still_trap
- store i32 0, i32* %trap_yet_again ; undefined behavior
-
- store i32 %trap, i32* @g ; Trap value conceptually stored to memory.
- %trap2 = load i32* @g ; Returns a trap value, not just undef.
-
- volatile store i32 %trap, i32* @g ; External observation; undefined behavior.
-
- %narrowaddr = bitcast i32* @g to i16*
- %wideaddr = bitcast i32* @g to i64*
- %trap3 = load 16* %narrowaddr ; Returns a trap value.
- %trap4 = load i64* %widaddr ; Returns a trap value.
-
- %cmp = icmp i32 slt %trap, 0 ; Returns a trap value.
- %br i1 %cmp, %true, %end ; Branch to either destination.
-
-true:
- volatile store i32 0, i32* @g ; This is control-dependent on %cmp, so
- ; it has undefined behavior.
- br label %end
-
-end:
- %p = phi i32 [ 0, %entry ], [ 1, %true ]
- ; Both edges into this PHI are
- ; control-dependent on %cmp, so this
- ; always results in a trap value.
-
- volatile store i32 0, i32* @g ; %end is control-equivalent to %entry
- ; so this is defined (ignoring earlier
- ; undefined behavior in this example).
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="blockaddress">Addresses of Basic
- Blocks</a></div>
-<div class="doc_text">
-
-<p><b><tt>blockaddress(@function, %block)</tt></b></p>
-
-<p>The '<tt>blockaddress</tt>' constant computes the address of the specified
- basic block in the specified function, and always has an i8* type. Taking
- the address of the entry block is illegal.</p>
-
-<p>This value only has defined behavior when used as an operand to the
- '<a href="#i_indirectbr"><tt>indirectbr</tt></a>' instruction or for comparisons
- against null. Pointer equality tests between labels addresses is undefined
- behavior - though, again, comparison against null is ok, and no label is
- equal to the null pointer. This may also be passed around as an opaque
- pointer sized value as long as the bits are not inspected. This allows
- <tt>ptrtoint</tt> and arithmetic to be performed on these values so long as
- the original value is reconstituted before the <tt>indirectbr</tt>.</p>
-
-<p>Finally, some targets may provide defined semantics when
- using the value as the operand to an inline assembly, but that is target
- specific.
- </p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="constantexprs">Constant Expressions</a>
-</div>
-
-<div class="doc_text">
-
-<p>Constant expressions are used to allow expressions involving other constants
- to be used as constants. Constant expressions may be of
- any <a href="#t_firstclass">first class</a> type and may involve any LLVM
- operation that does not have side effects (e.g. load and call are not
- supported). The following is the syntax for constant expressions:</p>
-
-<dl>
- <dt><b><tt>trunc ( CST to TYPE )</tt></b></dt>
- <dd>Truncate a constant to another type. The bit size of CST must be larger
- than the bit size of TYPE. Both types must be integers.</dd>
-
- <dt><b><tt>zext ( CST to TYPE )</tt></b></dt>
- <dd>Zero extend a constant to another type. The bit size of CST must be
- smaller or equal to the bit size of TYPE. Both types must be
- integers.</dd>
-
- <dt><b><tt>sext ( CST to TYPE )</tt></b></dt>
- <dd>Sign extend a constant to another type. The bit size of CST must be
- smaller or equal to the bit size of TYPE. Both types must be
- integers.</dd>
-
- <dt><b><tt>fptrunc ( CST to TYPE )</tt></b></dt>
- <dd>Truncate a floating point constant to another floating point type. The
- size of CST must be larger than the size of TYPE. Both types must be
- floating point.</dd>
-
- <dt><b><tt>fpext ( CST to TYPE )</tt></b></dt>
- <dd>Floating point extend a constant to another type. The size of CST must be
- smaller or equal to the size of TYPE. Both types must be floating
- point.</dd>
-
- <dt><b><tt>fptoui ( CST to TYPE )</tt></b></dt>
- <dd>Convert a floating point constant to the corresponding unsigned integer
- constant. TYPE must be a scalar or vector integer type. CST must be of
- scalar or vector floating point type. Both CST and TYPE must be scalars,
- or vectors of the same number of elements. If the value won't fit in the
- integer type, the results are undefined.</dd>
-
- <dt><b><tt>fptosi ( CST to TYPE )</tt></b></dt>
- <dd>Convert a floating point constant to the corresponding signed integer
- constant. TYPE must be a scalar or vector integer type. CST must be of
- scalar or vector floating point type. Both CST and TYPE must be scalars,
- or vectors of the same number of elements. If the value won't fit in the
- integer type, the results are undefined.</dd>
-
- <dt><b><tt>uitofp ( CST to TYPE )</tt></b></dt>
- <dd>Convert an unsigned integer constant to the corresponding floating point
- constant. TYPE must be a scalar or vector floating point type. CST must be
- of scalar or vector integer type. Both CST and TYPE must be scalars, or
- vectors of the same number of elements. If the value won't fit in the
- floating point type, the results are undefined.</dd>
-
- <dt><b><tt>sitofp ( CST to TYPE )</tt></b></dt>
- <dd>Convert a signed integer constant to the corresponding floating point
- constant. TYPE must be a scalar or vector floating point type. CST must be
- of scalar or vector integer type. Both CST and TYPE must be scalars, or
- vectors of the same number of elements. If the value won't fit in the
- floating point type, the results are undefined.</dd>
-
- <dt><b><tt>ptrtoint ( CST to TYPE )</tt></b></dt>
- <dd>Convert a pointer typed constant to the corresponding integer constant
- <tt>TYPE</tt> must be an integer type. <tt>CST</tt> must be of pointer
- type. The <tt>CST</tt> value is zero extended, truncated, or unchanged to
- make it fit in <tt>TYPE</tt>.</dd>
-
- <dt><b><tt>inttoptr ( CST to TYPE )</tt></b></dt>
- <dd>Convert a integer constant to a pointer constant. TYPE must be a pointer
- type. CST must be of integer type. The CST value is zero extended,
- truncated, or unchanged to make it fit in a pointer size. This one is
- <i>really</i> dangerous!</dd>
-
- <dt><b><tt>bitcast ( CST to TYPE )</tt></b></dt>
- <dd>Convert a constant, CST, to another TYPE. The constraints of the operands
- are the same as those for the <a href="#i_bitcast">bitcast
- instruction</a>.</dd>
-
- <dt><b><tt>getelementptr ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
- <dt><b><tt>getelementptr inbounds ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
- <dd>Perform the <a href="#i_getelementptr">getelementptr operation</a> on
- constants. As with the <a href="#i_getelementptr">getelementptr</a>
- instruction, the index list may have zero or more indexes, which are
- required to make sense for the type of "CSTPTR".</dd>
-
- <dt><b><tt>select ( COND, VAL1, VAL2 )</tt></b></dt>
- <dd>Perform the <a href="#i_select">select operation</a> on constants.</dd>
-
- <dt><b><tt>icmp COND ( VAL1, VAL2 )</tt></b></dt>
- <dd>Performs the <a href="#i_icmp">icmp operation</a> on constants.</dd>
-
- <dt><b><tt>fcmp COND ( VAL1, VAL2 )</tt></b></dt>
- <dd>Performs the <a href="#i_fcmp">fcmp operation</a> on constants.</dd>
-
- <dt><b><tt>extractelement ( VAL, IDX )</tt></b></dt>
- <dd>Perform the <a href="#i_extractelement">extractelement operation</a> on
- constants.</dd>
-
- <dt><b><tt>insertelement ( VAL, ELT, IDX )</tt></b></dt>
- <dd>Perform the <a href="#i_insertelement">insertelement operation</a> on
- constants.</dd>
-
- <dt><b><tt>shufflevector ( VEC1, VEC2, IDXMASK )</tt></b></dt>
- <dd>Perform the <a href="#i_shufflevector">shufflevector operation</a> on
- constants.</dd>
-
- <dt><b><tt>OPCODE ( LHS, RHS )</tt></b></dt>
- <dd>Perform the specified operation of the LHS and RHS constants. OPCODE may
- be any of the <a href="#binaryops">binary</a>
- or <a href="#bitwiseops">bitwise binary</a> operations. The constraints
- on operands are the same as those for the corresponding instruction
- (e.g. no bitwise operations on floating point values are allowed).</dd>
-</dl>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="othervalues">Other Values</a> </div>
-<!-- *********************************************************************** -->
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-<a name="inlineasm">Inline Assembler Expressions</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM supports inline assembler expressions (as opposed
- to <a href="#moduleasm"> Module-Level Inline Assembly</a>) through the use of
- a special value. This value represents the inline assembler as a string
- (containing the instructions to emit), a list of operand constraints (stored
- as a string), a flag that indicates whether or not the inline asm
- expression has side effects, and a flag indicating whether the function
- containing the asm needs to align its stack conservatively. An example
- inline assembler expression is:</p>
-
-<div class="doc_code">
-<pre>
-i32 (i32) asm "bswap $0", "=r,r"
-</pre>
-</div>
-
-<p>Inline assembler expressions may <b>only</b> be used as the callee operand of
- a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we
- have:</p>
-
-<div class="doc_code">
-<pre>
-%X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
-</pre>
-</div>
-
-<p>Inline asms with side effects not visible in the constraint list must be
- marked as having side effects. This is done through the use of the
- '<tt>sideeffect</tt>' keyword, like so:</p>
-
-<div class="doc_code">
-<pre>
-call void asm sideeffect "eieio", ""()
-</pre>
-</div>
-
-<p>In some cases inline asms will contain code that will not work unless the
- stack is aligned in some way, such as calls or SSE instructions on x86,
- yet will not contain code that does that alignment within the asm.
- The compiler should make conservative assumptions about what the asm might
- contain and should generate its usual stack alignment code in the prologue
- if the '<tt>alignstack</tt>' keyword is present:</p>
-
-<div class="doc_code">
-<pre>
-call void asm alignstack "eieio", ""()
-</pre>
-</div>
-
-<p>If both keywords appear the '<tt>sideeffect</tt>' keyword must come
- first.</p>
-
-<p>TODO: The format of the asm and constraints string still need to be
- documented here. Constraints on what can be done (e.g. duplication, moving,
- etc need to be documented). This is probably best done by reference to
- another document that covers inline asm from a holistic perspective.</p>
-</div>
-
-<div class="doc_subsubsection">
-<a name="inlineasm_md">Inline Asm Metadata</a>
-</div>
-
-<div class="doc_text">
-
-<p>The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode
- attached to it that contains a constant integer. If present, the code
- generator will use the integer as the location cookie value when report
- errors through the LLVMContext error reporting mechanisms. This allows a
- front-end to correlate backend errors that occur with inline asm back to the
- source code that produced it. For example:</p>
-
-<div class="doc_code">
-<pre>
-call void asm sideeffect "something bad", ""()<b>, !srcloc !42</b>
-...
-!42 = !{ i32 1234567 }
-</pre>
-</div>
-
-<p>It is up to the front-end to make sense of the magic numbers it places in the
- IR.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="metadata">Metadata Nodes and Metadata
- Strings</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM IR allows metadata to be attached to instructions in the program that
- can convey extra information about the code to the optimizers and code
- generator. One example application of metadata is source-level debug
- information. There are two metadata primitives: strings and nodes. All
- metadata has the <tt>metadata</tt> type and is identified in syntax by a
- preceding exclamation point ('<tt>!</tt>').</p>
-
-<p>A metadata string is a string surrounded by double quotes. It can contain
- any character by escaping non-printable characters with "\xx" where "xx" is
- the two digit hex code. For example: "<tt>!"test\00"</tt>".</p>
-
-<p>Metadata nodes are represented with notation similar to structure constants
- (a comma separated list of elements, surrounded by braces and preceded by an
- exclamation point). For example: "<tt>!{ metadata !"test\00", i32
- 10}</tt>". Metadata nodes can have any values as their operand.</p>
-
-<p>A <a href="#namedmetadatastructure">named metadata</a> is a collection of
- metadata nodes, which can be looked up in the module symbol table. For
- example: "<tt>!foo = metadata !{!4, !3}</tt>".
-
-<p>Metadata can be used as function arguments. Here <tt>llvm.dbg.value</tt>
- function is using two metadata arguments.
-
- <div class="doc_code">
- <pre>
- call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
- </pre>
- </div></p>
-
-<p>Metadata can be attached with an instruction. Here metadata <tt>!21</tt> is
- attached with <tt>add</tt> instruction using <tt>!dbg</tt> identifier.
-
- <div class="doc_code">
- <pre>
- %indvar.next = add i64 %indvar, 1, !dbg !21
- </pre>
- </div></p>
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="intrinsic_globals">Intrinsic Global Variables</a>
-</div>
-<!-- *********************************************************************** -->
-
-<p>LLVM has a number of "magic" global variables that contain data that affect
-code generation or other IR semantics. These are documented here. All globals
-of this sort should have a section specified as "<tt>llvm.metadata</tt>". This
-section and all globals that start with "<tt>llvm.</tt>" are reserved for use
-by LLVM.</p>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-<a name="intg_used">The '<tt>llvm.used</tt>' Global Variable</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>@llvm.used</tt> global is an array with i8* element type which has <a
-href="#linkage_appending">appending linkage</a>. This array contains a list of
-pointers to global variables and functions which may optionally have a pointer
-cast formed of bitcast or getelementptr. For example, a legal use of it is:</p>
-
-<pre>
- @X = global i8 4
- @Y = global i32 123
-
- @llvm.used = appending global [2 x i8*] [
- i8* @X,
- i8* bitcast (i32* @Y to i8*)
- ], section "llvm.metadata"
-</pre>
-
-<p>If a global variable appears in the <tt>@llvm.used</tt> list, then the
-compiler, assembler, and linker are required to treat the symbol as if there is
-a reference to the global that it cannot see. For example, if a variable has
-internal linkage and no references other than that from the <tt>@llvm.used</tt>
-list, it cannot be deleted. This is commonly used to represent references from
-inline asms and other things the compiler cannot "see", and corresponds to
-"attribute((used))" in GNU C.</p>
-
-<p>On some targets, the code generator must emit a directive to the assembler or
-object file to prevent the assembler and linker from molesting the symbol.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-<a name="intg_compiler_used">The '<tt>llvm.compiler.used</tt>' Global Variable</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>@llvm.compiler.used</tt> directive is the same as the
-<tt>@llvm.used</tt> directive, except that it only prevents the compiler from
-touching the symbol. On targets that support it, this allows an intelligent
-linker to optimize references to the symbol without being impeded as it would be
-by <tt>@llvm.used</tt>.</p>
-
-<p>This is a rare construct that should only be used in rare circumstances, and
-should not be exposed to source languages.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-<a name="intg_global_ctors">The '<tt>llvm.global_ctors</tt>' Global Variable</a>
-</div>
-
-<div class="doc_text">
-<pre>
-%0 = type { i32, void ()* }
- at llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
-</pre>
-<p>The <tt>@llvm.global_ctors</tt> array contains a list of constructor functions and associated priorities. The functions referenced by this array will be called in ascending order of priority (i.e. lowest first) when the module is loaded. The order of functions with the same priority is not defined.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
-<a name="intg_global_dtors">The '<tt>llvm.global_dtors</tt>' Global Variable</a>
-</div>
-
-<div class="doc_text">
-<pre>
-%0 = type { i32, void ()* }
- at llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
-</pre>
-
-<p>The <tt>@llvm.global_dtors</tt> array contains a list of destructor functions and associated priorities. The functions referenced by this array will be called in descending order of priority (i.e. highest first) when the module is loaded. The order of functions with the same priority is not defined.
-</p>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="instref">Instruction Reference</a> </div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM instruction set consists of several different classifications of
- instructions: <a href="#terminators">terminator
- instructions</a>, <a href="#binaryops">binary instructions</a>,
- <a href="#bitwiseops">bitwise binary instructions</a>,
- <a href="#memoryops">memory instructions</a>, and
- <a href="#otherops">other instructions</a>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="terminators">Terminator
-Instructions</a> </div>
-
-<div class="doc_text">
-
-<p>As mentioned <a href="#functionstructure">previously</a>, every basic block
- in a program ends with a "Terminator" instruction, which indicates which
- block should be executed after the current block is finished. These
- terminator instructions typically yield a '<tt>void</tt>' value: they produce
- control flow, not values (the one exception being the
- '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p>
-
-<p>There are seven different terminator instructions: the
- '<a href="#i_ret"><tt>ret</tt></a>' instruction, the
- '<a href="#i_br"><tt>br</tt></a>' instruction, the
- '<a href="#i_switch"><tt>switch</tt></a>' instruction, the
- '<a href="#i_indirectbr">'<tt>indirectbr</tt></a>' Instruction, the
- '<a href="#i_invoke"><tt>invoke</tt></a>' instruction, the
- '<a href="#i_unwind"><tt>unwind</tt></a>' instruction, and the
- '<a href="#i_unreachable"><tt>unreachable</tt></a>' instruction.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_ret">'<tt>ret</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- ret <type> <value> <i>; Return a value from a non-void function</i>
- ret void <i>; Return from void function</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>ret</tt>' instruction is used to return control flow (and optionally
- a value) from a function back to the caller.</p>
-
-<p>There are two forms of the '<tt>ret</tt>' instruction: one that returns a
- value and then causes control flow, and one that just causes control flow to
- occur.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>ret</tt>' instruction optionally accepts a single argument, the
- return value. The type of the return value must be a
- '<a href="#t_firstclass">first class</a>' type.</p>
-
-<p>A function is not <a href="#wellformed">well formed</a> if it it has a
- non-void return type and contains a '<tt>ret</tt>' instruction with no return
- value or a return value with a type that does not match its type, or if it
- has a void return type and contains a '<tt>ret</tt>' instruction with a
- return value.</p>
-
-<h5>Semantics:</h5>
-<p>When the '<tt>ret</tt>' instruction is executed, control flow returns back to
- the calling function's context. If the caller is a
- "<a href="#i_call"><tt>call</tt></a>" instruction, execution continues at the
- instruction after the call. If the caller was an
- "<a href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues at
- the beginning of the "normal" destination block. If the instruction returns
- a value, that value shall set the call or invoke instruction's return
- value.</p>
-
-<h5>Example:</h5>
-<pre>
- ret i32 5 <i>; Return an integer value of 5</i>
- ret void <i>; Return from a void function</i>
- ret { i32, i8 } { i32 4, i8 2 } <i>; Return a struct of values 4 and 2</i>
-</pre>
-
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- br i1 <cond>, label <iftrue>, label <iffalse><br> br label <dest> <i>; Unconditional branch</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>br</tt>' instruction is used to cause control flow to transfer to a
- different basic block in the current function. There are two forms of this
- instruction, corresponding to a conditional branch and an unconditional
- branch.</p>
-
-<h5>Arguments:</h5>
-<p>The conditional branch form of the '<tt>br</tt>' instruction takes a single
- '<tt>i1</tt>' value and two '<tt>label</tt>' values. The unconditional form
- of the '<tt>br</tt>' instruction takes a single '<tt>label</tt>' value as a
- target.</p>
-
-<h5>Semantics:</h5>
-<p>Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>i1</tt>'
- argument is evaluated. If the value is <tt>true</tt>, control flows to the
- '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>,
- control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p>
-
-<h5>Example:</h5>
-<pre>
-Test:
- %cond = <a href="#i_icmp">icmp</a> eq i32 %a, %b
- br i1 %cond, label %IfEqual, label %IfUnequal
-IfEqual:
- <a href="#i_ret">ret</a> i32 1
-IfUnequal:
- <a href="#i_ret">ret</a> i32 0
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_switch">'<tt>switch</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of
- several different places. It is a generalization of the '<tt>br</tt>'
- instruction, allowing a branch to occur to one of many possible
- destinations.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>switch</tt>' instruction uses three parameters: an integer
- comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination,
- and an array of pairs of comparison value constants and '<tt>label</tt>'s.
- The table is not allowed to contain duplicate constant entries.</p>
-
-<h5>Semantics:</h5>
-<p>The <tt>switch</tt> instruction specifies a table of values and
- destinations. When the '<tt>switch</tt>' instruction is executed, this table
- is searched for the given value. If the value is found, control flow is
- transferred to the corresponding destination; otherwise, control flow is
- transferred to the default destination.</p>
-
-<h5>Implementation:</h5>
-<p>Depending on properties of the target machine and the particular
- <tt>switch</tt> instruction, this instruction may be code generated in
- different ways. For example, it could be generated as a series of chained
- conditional branches or with a lookup table.</p>
-
-<h5>Example:</h5>
-<pre>
- <i>; Emulate a conditional br instruction</i>
- %Val = <a href="#i_zext">zext</a> i1 %value to i32
- switch i32 %Val, label %truedest [ i32 0, label %falsedest ]
-
- <i>; Emulate an unconditional br instruction</i>
- switch i32 0, label %dest [ ]
-
- <i>; Implement a jump table:</i>
- switch i32 %val, label %otherwise [ i32 0, label %onzero
- i32 1, label %onone
- i32 2, label %ontwo ]
-</pre>
-
-</div>
-
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_indirectbr">'<tt>indirectbr</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- indirectbr <somety>* <address>, [ label <dest1>, label <dest2>, ... ]
-</pre>
-
-<h5>Overview:</h5>
-
-<p>The '<tt>indirectbr</tt>' instruction implements an indirect branch to a label
- within the current function, whose address is specified by
- "<tt>address</tt>". Address must be derived from a <a
- href="#blockaddress">blockaddress</a> constant.</p>
-
-<h5>Arguments:</h5>
-
-<p>The '<tt>address</tt>' argument is the address of the label to jump to. The
- rest of the arguments indicate the full set of possible destinations that the
- address may point to. Blocks are allowed to occur multiple times in the
- destination list, though this isn't particularly useful.</p>
-
-<p>This destination list is required so that dataflow analysis has an accurate
- understanding of the CFG.</p>
-
-<h5>Semantics:</h5>
-
-<p>Control transfers to the block specified in the address argument. All
- possible destination blocks must be listed in the label list, otherwise this
- instruction has undefined behavior. This implies that jumps to labels
- defined in other functions have undefined behavior as well.</p>
-
-<h5>Implementation:</h5>
-
-<p>This is typically implemented with a jump through a register.</p>
-
-<h5>Example:</h5>
-<pre>
- indirectbr i8* %Addr, [ label %bb1, label %bb2, label %bb3 ]
-</pre>
-
-</div>
-
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_invoke">'<tt>invoke</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = invoke [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] <ptr to function ty> <function ptr val>(<function args>) [<a href="#fnattrs">fn attrs</a>]
- to label <normal label> unwind label <exception label>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>invoke</tt>' instruction causes control to transfer to a specified
- function, with the possibility of control flow transfer to either the
- '<tt>normal</tt>' label or the '<tt>exception</tt>' label. If the callee
- function returns with the "<tt><a href="#i_ret">ret</a></tt>" instruction,
- control flow will return to the "normal" label. If the callee (or any
- indirect callees) returns with the "<a href="#i_unwind"><tt>unwind</tt></a>"
- instruction, control is interrupted and continued at the dynamically nearest
- "exception" label.</p>
-
-<h5>Arguments:</h5>
-<p>This instruction requires several arguments:</p>
-
-<ol>
- <li>The optional "cconv" marker indicates which <a href="#callingconv">calling
- convention</a> the call should use. If none is specified, the call
- defaults to using C calling conventions.</li>
-
- <li>The optional <a href="#paramattrs">Parameter Attributes</a> list for
- return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>', and
- '<tt>inreg</tt>' attributes are valid here.</li>
-
- <li>'<tt>ptr to function ty</tt>': shall be the signature of the pointer to
- function value being invoked. In most cases, this is a direct function
- invocation, but indirect <tt>invoke</tt>s are just as possible, branching
- off an arbitrary pointer to function value.</li>
-
- <li>'<tt>function ptr val</tt>': An LLVM value containing a pointer to a
- function to be invoked. </li>
-
- <li>'<tt>function args</tt>': argument list whose types match the function
- signature argument types and parameter attributes. All arguments must be
- of <a href="#t_firstclass">first class</a> type. If the function
- signature indicates the function accepts a variable number of arguments,
- the extra arguments can be specified.</li>
-
- <li>'<tt>normal label</tt>': the label reached when the called function
- executes a '<tt><a href="#i_ret">ret</a></tt>' instruction. </li>
-
- <li>'<tt>exception label</tt>': the label reached when a callee returns with
- the <a href="#i_unwind"><tt>unwind</tt></a> instruction. </li>
-
- <li>The optional <a href="#fnattrs">function attributes</a> list. Only
- '<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and
- '<tt>readnone</tt>' attributes are valid here.</li>
-</ol>
-
-<h5>Semantics:</h5>
-<p>This instruction is designed to operate as a standard
- '<tt><a href="#i_call">call</a></tt>' instruction in most regards. The
- primary difference is that it establishes an association with a label, which
- is used by the runtime library to unwind the stack.</p>
-
-<p>This instruction is used in languages with destructors to ensure that proper
- cleanup is performed in the case of either a <tt>longjmp</tt> or a thrown
- exception. Additionally, this is important for implementation of
- '<tt>catch</tt>' clauses in high-level languages that support them.</p>
-
-<p>For the purposes of the SSA form, the definition of the value returned by the
- '<tt>invoke</tt>' instruction is deemed to occur on the edge from the current
- block to the "normal" label. If the callee unwinds then no return value is
- available.</p>
-
-<p>Note that the code generator does not yet completely support unwind, and
-that the invoke/unwind semantics are likely to change in future versions.</p>
-
-<h5>Example:</h5>
-<pre>
- %retval = invoke i32 @Test(i32 15) to label %Continue
- unwind label %TestCleanup <i>; {i32}:retval set</i>
- %retval = invoke <a href="#callingconv">coldcc</a> i32 %Testfnptr(i32 15) to label %Continue
- unwind label %TestCleanup <i>; {i32}:retval set</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_subsubsection"> <a name="i_unwind">'<tt>unwind</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- unwind
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>unwind</tt>' instruction unwinds the stack, continuing control flow
- at the first callee in the dynamic call stack which used
- an <a href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call.
- This is primarily used to implement exception handling.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>unwind</tt>' instruction causes execution of the current function to
- immediately halt. The dynamic call stack is then searched for the
- first <a href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack.
- Once found, execution continues at the "exceptional" destination block
- specified by the <tt>invoke</tt> instruction. If there is no <tt>invoke</tt>
- instruction in the dynamic call chain, undefined behavior results.</p>
-
-<p>Note that the code generator does not yet completely support unwind, and
-that the invoke/unwind semantics are likely to change in future versions.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_subsubsection"> <a name="i_unreachable">'<tt>unreachable</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- unreachable
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>unreachable</tt>' instruction has no defined semantics. This
- instruction is used to inform the optimizer that a particular portion of the
- code is not reachable. This can be used to indicate that the code after a
- no-return function cannot be reached, and other facts.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>unreachable</tt>' instruction has no defined semantics.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="binaryops">Binary Operations</a> </div>
-
-<div class="doc_text">
-
-<p>Binary operators are used to do most of the computation in a program. They
- require two operands of the same type, execute an operation on them, and
- produce a single value. The operands might represent multiple data, as is
- the case with the <a href="#t_vector">vector</a> data type. The result value
- has the same type as its operands.</p>
-
-<p>There are several different binary operators:</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_add">'<tt>add</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = add <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = add nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = add nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = add nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>add</tt>' instruction returns the sum of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>add</tt>' instruction must
- be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
- integer values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the integer sum of the two operands.</p>
-
-<p>If the sum has unsigned overflow, the result returned is the mathematical
- result modulo 2<sup>n</sup>, where n is the bit width of the result.</p>
-
-<p>Because LLVM integers use a two's complement representation, this instruction
- is appropriate for both signed and unsigned integers.</p>
-
-<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap"
- and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or
- <tt>nsw</tt> keywords are present, the result value of the <tt>add</tt>
- is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow,
- respectively, occurs.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = add i32 4, %var <i>; yields {i32}:result = 4 + %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fadd">'<tt>fadd</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fadd <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fadd</tt>' instruction returns the sum of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>fadd</tt>' instruction must be
- <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of
- floating point values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the floating point sum of the two operands.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = fadd float 4.0, %var <i>; yields {float}:result = 4.0 + %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_sub">'<tt>sub</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = sub <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = sub nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = sub nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = sub nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>sub</tt>' instruction returns the difference of its two
- operands.</p>
-
-<p>Note that the '<tt>sub</tt>' instruction is used to represent the
- '<tt>neg</tt>' instruction present in most other intermediate
- representations.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>sub</tt>' instruction must
- be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
- integer values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the integer difference of the two operands.</p>
-
-<p>If the difference has unsigned overflow, the result returned is the
- mathematical result modulo 2<sup>n</sup>, where n is the bit width of the
- result.</p>
-
-<p>Because LLVM integers use a two's complement representation, this instruction
- is appropriate for both signed and unsigned integers.</p>
-
-<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap"
- and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or
- <tt>nsw</tt> keywords are present, the result value of the <tt>sub</tt>
- is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow,
- respectively, occurs.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i>
- <result> = sub i32 0, %val <i>; yields {i32}:result = -%var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fsub">'<tt>fsub</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fsub <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fsub</tt>' instruction returns the difference of its two
- operands.</p>
-
-<p>Note that the '<tt>fsub</tt>' instruction is used to represent the
- '<tt>fneg</tt>' instruction present in most other intermediate
- representations.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>fsub</tt>' instruction must be
- <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of
- floating point values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the floating point difference of the two operands.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = fsub float 4.0, %var <i>; yields {float}:result = 4.0 - %var</i>
- <result> = fsub float -0.0, %val <i>; yields {float}:result = -%var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_mul">'<tt>mul</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = mul <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = mul nuw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = mul nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = mul nuw nsw <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>mul</tt>' instruction returns the product of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>mul</tt>' instruction must
- be <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
- integer values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the integer product of the two operands.</p>
-
-<p>If the result of the multiplication has unsigned overflow, the result
- returned is the mathematical result modulo 2<sup>n</sup>, where n is the bit
- width of the result.</p>
-
-<p>Because LLVM integers use a two's complement representation, and the result
- is the same width as the operands, this instruction returns the correct
- result for both signed and unsigned integers. If a full product
- (e.g. <tt>i32</tt>x<tt>i32</tt>-><tt>i64</tt>) is needed, the operands should
- be sign-extended or zero-extended as appropriate to the width of the full
- product.</p>
-
-<p><tt>nuw</tt> and <tt>nsw</tt> stand for "No Unsigned Wrap"
- and "No Signed Wrap", respectively. If the <tt>nuw</tt> and/or
- <tt>nsw</tt> keywords are present, the result value of the <tt>mul</tt>
- is a <a href="#trapvalues">trap value</a> if unsigned and/or signed overflow,
- respectively, occurs.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = mul i32 4, %var <i>; yields {i32}:result = 4 * %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fmul">'<tt>fmul</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fmul <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fmul</tt>' instruction returns the product of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>fmul</tt>' instruction must be
- <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of
- floating point values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the floating point product of the two operands.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = fmul float 4.0, %var <i>; yields {float}:result = 4.0 * %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_udiv">'<tt>udiv</tt>' Instruction
-</a></div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = udiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>udiv</tt>' instruction returns the quotient of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>udiv</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the unsigned integer quotient of the two operands.</p>
-
-<p>Note that unsigned integer division and signed integer division are distinct
- operations; for signed integer division, use '<tt>sdiv</tt>'.</p>
-
-<p>Division by zero leads to undefined behavior.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = udiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_sdiv">'<tt>sdiv</tt>' Instruction
-</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = sdiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
- <result> = sdiv exact <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>sdiv</tt>' instruction returns the quotient of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>sdiv</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the signed integer quotient of the two operands rounded
- towards zero.</p>
-
-<p>Note that signed integer division and unsigned integer division are distinct
- operations; for unsigned integer division, use '<tt>udiv</tt>'.</p>
-
-<p>Division by zero leads to undefined behavior. Overflow also leads to
- undefined behavior; this is a rare case, but can occur, for example, by doing
- a 32-bit division of -2147483648 by -1.</p>
-
-<p>If the <tt>exact</tt> keyword is present, the result value of the
- <tt>sdiv</tt> is a <a href="#trapvalues">trap value</a> if the result would
- be rounded or if overflow would occur.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = sdiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_fdiv">'<tt>fdiv</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fdiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fdiv</tt>' instruction returns the quotient of its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>fdiv</tt>' instruction must be
- <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of
- floating point values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is the floating point quotient of the two operands.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = fdiv float 4.0, %var <i>; yields {float}:result = 4.0 / %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_urem">'<tt>urem</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = urem <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>urem</tt>' instruction returns the remainder from the unsigned
- division of its two arguments.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>urem</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>This instruction returns the unsigned integer <i>remainder</i> of a division.
- This instruction always performs an unsigned division to get the
- remainder.</p>
-
-<p>Note that unsigned integer remainder and signed integer remainder are
- distinct operations; for signed integer remainder, use '<tt>srem</tt>'.</p>
-
-<p>Taking the remainder of a division by zero leads to undefined behavior.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = urem i32 4, %var <i>; yields {i32}:result = 4 % %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_srem">'<tt>srem</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = srem <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>srem</tt>' instruction returns the remainder from the signed
- division of its two operands. This instruction can also take
- <a href="#t_vector">vector</a> versions of the values in which case the
- elements must be integers.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>srem</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>This instruction returns the <i>remainder</i> of a division (where the result
- has the same sign as the dividend, <tt>op1</tt>), not the <i>modulo</i>
- operator (where the result has the same sign as the divisor, <tt>op2</tt>) of
- a value. For more information about the difference,
- see <a href="http://mathforum.org/dr.math/problems/anne.4.28.99.html">The
- Math Forum</a>. For a table of how this is implemented in various languages,
- please see <a href="http://en.wikipedia.org/wiki/Modulo_operation">
- Wikipedia: modulo operation</a>.</p>
-
-<p>Note that signed integer remainder and unsigned integer remainder are
- distinct operations; for unsigned integer remainder, use '<tt>urem</tt>'.</p>
-
-<p>Taking the remainder of a division by zero leads to undefined behavior.
- Overflow also leads to undefined behavior; this is a rare case, but can
- occur, for example, by taking the remainder of a 32-bit division of
- -2147483648 by -1. (The remainder doesn't actually overflow, but this rule
- lets srem be implemented using instructions that return both the result of
- the division and the remainder.)</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = srem i32 4, %var <i>; yields {i32}:result = 4 % %var</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_frem">'<tt>frem</tt>' Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = frem <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>frem</tt>' instruction returns the remainder from the division of
- its two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>frem</tt>' instruction must be
- <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a> of
- floating point values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>This instruction returns the <i>remainder</i> of a division. The remainder
- has the same sign as the dividend.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = frem float 4.0, %var <i>; yields {float}:result = 4.0 % %var</i>
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="bitwiseops">Bitwise Binary
-Operations</a> </div>
-
-<div class="doc_text">
-
-<p>Bitwise binary operators are used to do various forms of bit-twiddling in a
- program. They are generally very efficient instructions and can commonly be
- strength reduced from other instructions. They require two operands of the
- same type, execute an operation on them, and produce a single value. The
- resulting value is the same type as its operands.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_shl">'<tt>shl</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = shl <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>shl</tt>' instruction returns the first operand shifted to the left
- a specified number of bits.</p>
-
-<h5>Arguments:</h5>
-<p>Both arguments to the '<tt>shl</tt>' instruction must be the
- same <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of
- integer type. '<tt>op2</tt>' is treated as an unsigned value.</p>
-
-<h5>Semantics:</h5>
-<p>The value produced is <tt>op1</tt> * 2<sup><tt>op2</tt></sup> mod
- 2<sup>n</sup>, where <tt>n</tt> is the width of the result. If <tt>op2</tt>
- is (statically or dynamically) negative or equal to or larger than the number
- of bits in <tt>op1</tt>, the result is undefined. If the arguments are
- vectors, each vector element of <tt>op1</tt> is shifted by the corresponding
- shift amount in <tt>op2</tt>.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i>
- <result> = shl i32 4, 2 <i>; yields {i32}: 16</i>
- <result> = shl i32 1, 10 <i>; yields {i32}: 1024</i>
- <result> = shl i32 1, 32 <i>; undefined</i>
- <result> = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 2, i32 4></i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_lshr">'<tt>lshr</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = lshr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>lshr</tt>' instruction (logical shift right) returns the first
- operand shifted to the right a specified number of bits with zero fill.</p>
-
-<h5>Arguments:</h5>
-<p>Both arguments to the '<tt>lshr</tt>' instruction must be the same
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- type. '<tt>op2</tt>' is treated as an unsigned value.</p>
-
-<h5>Semantics:</h5>
-<p>This instruction always performs a logical shift right operation. The most
- significant bits of the result will be filled with zero bits after the shift.
- If <tt>op2</tt> is (statically or dynamically) equal to or larger than the
- number of bits in <tt>op1</tt>, the result is undefined. If the arguments are
- vectors, each vector element of <tt>op1</tt> is shifted by the corresponding
- shift amount in <tt>op2</tt>.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = lshr i32 4, 1 <i>; yields {i32}:result = 2</i>
- <result> = lshr i32 4, 2 <i>; yields {i32}:result = 1</i>
- <result> = lshr i8 4, 3 <i>; yields {i8}:result = 0</i>
- <result> = lshr i8 -2, 1 <i>; yields {i8}:result = 0x7FFFFFFF </i>
- <result> = lshr i32 1, 32 <i>; undefined</i>
- <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1></i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_ashr">'<tt>ashr</tt>'
-Instruction</a> </div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = ashr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>ashr</tt>' instruction (arithmetic shift right) returns the first
- operand shifted to the right a specified number of bits with sign
- extension.</p>
-
-<h5>Arguments:</h5>
-<p>Both arguments to the '<tt>ashr</tt>' instruction must be the same
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- type. '<tt>op2</tt>' is treated as an unsigned value.</p>
-
-<h5>Semantics:</h5>
-<p>This instruction always performs an arithmetic shift right operation, The
- most significant bits of the result will be filled with the sign bit
- of <tt>op1</tt>. If <tt>op2</tt> is (statically or dynamically) equal to or
- larger than the number of bits in <tt>op1</tt>, the result is undefined. If
- the arguments are vectors, each vector element of <tt>op1</tt> is shifted by
- the corresponding shift amount in <tt>op2</tt>.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = ashr i32 4, 1 <i>; yields {i32}:result = 2</i>
- <result> = ashr i32 4, 2 <i>; yields {i32}:result = 1</i>
- <result> = ashr i8 4, 3 <i>; yields {i8}:result = 0</i>
- <result> = ashr i8 -2, 1 <i>; yields {i8}:result = -1</i>
- <result> = ashr i32 1, 32 <i>; undefined</i>
- <result> = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3> <i>; yields: result=<2 x i32> < i32 -1, i32 0></i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_and">'<tt>and</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = and <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>and</tt>' instruction returns the bitwise logical and of its two
- operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>and</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The truth table used for the '<tt>and</tt>' instruction is:</p>
-
-<table border="1" cellspacing="0" cellpadding="4">
- <tbody>
- <tr>
- <td>In0</td>
- <td>In1</td>
- <td>Out</td>
- </tr>
- <tr>
- <td>0</td>
- <td>0</td>
- <td>0</td>
- </tr>
- <tr>
- <td>0</td>
- <td>1</td>
- <td>0</td>
- </tr>
- <tr>
- <td>1</td>
- <td>0</td>
- <td>0</td>
- </tr>
- <tr>
- <td>1</td>
- <td>1</td>
- <td>1</td>
- </tr>
- </tbody>
-</table>
-
-<h5>Example:</h5>
-<pre>
- <result> = and i32 4, %var <i>; yields {i32}:result = 4 & %var</i>
- <result> = and i32 15, 40 <i>; yields {i32}:result = 8</i>
- <result> = and i32 4, 8 <i>; yields {i32}:result = 0</i>
-</pre>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_or">'<tt>or</tt>' Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = or <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>or</tt>' instruction returns the bitwise logical inclusive or of its
- two operands.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>or</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The truth table used for the '<tt>or</tt>' instruction is:</p>
-
-<table border="1" cellspacing="0" cellpadding="4">
- <tbody>
- <tr>
- <td>In0</td>
- <td>In1</td>
- <td>Out</td>
- </tr>
- <tr>
- <td>0</td>
- <td>0</td>
- <td>0</td>
- </tr>
- <tr>
- <td>0</td>
- <td>1</td>
- <td>1</td>
- </tr>
- <tr>
- <td>1</td>
- <td>0</td>
- <td>1</td>
- </tr>
- <tr>
- <td>1</td>
- <td>1</td>
- <td>1</td>
- </tr>
- </tbody>
-</table>
-
-<h5>Example:</h5>
-<pre>
- <result> = or i32 4, %var <i>; yields {i32}:result = 4 | %var</i>
- <result> = or i32 15, 40 <i>; yields {i32}:result = 47</i>
- <result> = or i32 4, 8 <i>; yields {i32}:result = 12</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_xor">'<tt>xor</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = xor <ty> <op1>, <op2> <i>; yields {ty}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>xor</tt>' instruction returns the bitwise logical exclusive or of
- its two operands. The <tt>xor</tt> is used to implement the "one's
- complement" operation, which is the "~" operator in C.</p>
-
-<h5>Arguments:</h5>
-<p>The two arguments to the '<tt>xor</tt>' instruction must be
- <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
- values. Both arguments must have identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The truth table used for the '<tt>xor</tt>' instruction is:</p>
-
-<table border="1" cellspacing="0" cellpadding="4">
- <tbody>
- <tr>
- <td>In0</td>
- <td>In1</td>
- <td>Out</td>
- </tr>
- <tr>
- <td>0</td>
- <td>0</td>
- <td>0</td>
- </tr>
- <tr>
- <td>0</td>
- <td>1</td>
- <td>1</td>
- </tr>
- <tr>
- <td>1</td>
- <td>0</td>
- <td>1</td>
- </tr>
- <tr>
- <td>1</td>
- <td>1</td>
- <td>0</td>
- </tr>
- </tbody>
-</table>
-
-<h5>Example:</h5>
-<pre>
- <result> = xor i32 4, %var <i>; yields {i32}:result = 4 ^ %var</i>
- <result> = xor i32 15, 40 <i>; yields {i32}:result = 39</i>
- <result> = xor i32 4, 8 <i>; yields {i32}:result = 12</i>
- <result> = xor i32 %V, -1 <i>; yields {i32}:result = ~%V</i>
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="vectorops">Vector Operations</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM supports several instructions to represent vector operations in a
- target-independent manner. These instructions cover the element-access and
- vector-specific operations needed to process vectors effectively. While LLVM
- does directly support these vector operations, many sophisticated algorithms
- will want to use target-specific intrinsics to take full advantage of a
- specific target.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_extractelement">'<tt>extractelement</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = extractelement <n x <ty>> <val>, i32 <idx> <i>; yields <ty></i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>extractelement</tt>' instruction extracts a single scalar element
- from a vector at a specified index.</p>
-
-
-<h5>Arguments:</h5>
-<p>The first operand of an '<tt>extractelement</tt>' instruction is a value
- of <a href="#t_vector">vector</a> type. The second operand is an index
- indicating the position from which to extract the element. The index may be
- a variable.</p>
-
-<h5>Semantics:</h5>
-<p>The result is a scalar of the same type as the element type of
- <tt>val</tt>. Its value is the value at position <tt>idx</tt> of
- <tt>val</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the
- results are undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_insertelement">'<tt>insertelement</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx> <i>; yields <n x <ty>></i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>insertelement</tt>' instruction inserts a scalar element into a
- vector at a specified index.</p>
-
-<h5>Arguments:</h5>
-<p>The first operand of an '<tt>insertelement</tt>' instruction is a value
- of <a href="#t_vector">vector</a> type. The second operand is a scalar value
- whose type must equal the element type of the first operand. The third
- operand is an index indicating the position at which to insert the value.
- The index may be a variable.</p>
-
-<h5>Semantics:</h5>
-<p>The result is a vector of the same type as <tt>val</tt>. Its element values
- are those of <tt>val</tt> except at position <tt>idx</tt>, where it gets the
- value <tt>elt</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the
- results are undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_shufflevector">'<tt>shufflevector</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask> <i>; yields <m x <ty>></i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>shufflevector</tt>' instruction constructs a permutation of elements
- from two input vectors, returning a vector with the same element type as the
- input and length that is the same as the shuffle mask.</p>
-
-<h5>Arguments:</h5>
-<p>The first two operands of a '<tt>shufflevector</tt>' instruction are vectors
- with types that match each other. The third argument is a shuffle mask whose
- element type is always 'i32'. The result of the instruction is a vector
- whose length is the same as the shuffle mask and whose element type is the
- same as the element type of the first two operands.</p>
-
-<p>The shuffle mask operand is required to be a constant vector with either
- constant integer or undef values.</p>
-
-<h5>Semantics:</h5>
-<p>The elements of the two input vectors are numbered from left to right across
- both of the vectors. The shuffle mask operand specifies, for each element of
- the result vector, which element of the two input vectors the result element
- gets. The element selector may be undef (meaning "don't care") and the
- second operand may be undef if performing a shuffle from only one vector.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
- <4 x i32> <i32 0, i32 4, i32 1, i32 5> <i>; yields <4 x i32></i>
- <result> = shufflevector <4 x i32> %v1, <4 x i32> undef,
- <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle.
- <result> = shufflevector <8 x i32> %v1, <8 x i32> undef,
- <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i>
- <result> = shufflevector <4 x i32> %v1, <4 x i32> %v2,
- <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > <i>; yields <8 x i32></i>
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="aggregateops">Aggregate Operations</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM supports several instructions for working with
- <a href="#t_aggregate">aggregate</a> values.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_extractvalue">'<tt>extractvalue</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>extractvalue</tt>' instruction extracts the value of a member field
- from an <a href="#t_aggregate">aggregate</a> value.</p>
-
-<h5>Arguments:</h5>
-<p>The first operand of an '<tt>extractvalue</tt>' instruction is a value
- of <a href="#t_struct">struct</a>, <a href="#t_union">union</a> or
- <a href="#t_array">array</a> type. The operands are constant indices to
- specify which value to extract in a similar manner as indices in a
- '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.</p>
-
-<h5>Semantics:</h5>
-<p>The result is the value at the position in the aggregate specified by the
- index operands.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = extractvalue {i32, float} %agg, 0 <i>; yields i32</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_insertvalue">'<tt>insertvalue</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = insertvalue <aggregate type> <val>, <ty> <elt>, <idx> <i>; yields <aggregate type></i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>insertvalue</tt>' instruction inserts a value into a member field
- in an <a href="#t_aggregate">aggregate</a> value.</p>
-
-<h5>Arguments:</h5>
-<p>The first operand of an '<tt>insertvalue</tt>' instruction is a value
- of <a href="#t_struct">struct</a>, <a href="#t_union">union</a> or
- <a href="#t_array">array</a> type. The second operand is a first-class
- value to insert. The following operands are constant indices indicating
- the position at which to insert the value in a similar manner as indices in a
- '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction. The
- value to insert must have the same type as the value identified by the
- indices.</p>
-
-<h5>Semantics:</h5>
-<p>The result is an aggregate of the same type as <tt>val</tt>. Its value is
- that of <tt>val</tt> except that the value at the position specified by the
- indices is that of <tt>elt</tt>.</p>
-
-<h5>Example:</h5>
-<pre>
- %agg1 = insertvalue {i32, float} undef, i32 1, 0 <i>; yields {i32 1, float undef}</i>
- %agg2 = insertvalue {i32, float} %agg1, float %val, 1 <i>; yields {i32 1, float %val}</i>
-</pre>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="memoryops">Memory Access and Addressing Operations</a>
-</div>
-
-<div class="doc_text">
-
-<p>A key design point of an SSA-based representation is how it represents
- memory. In LLVM, no memory locations are in SSA form, which makes things
- very simple. This section describes how to read, write, and allocate
- memory in LLVM.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_alloca">'<tt>alloca</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>alloca</tt>' instruction allocates memory on the stack frame of the
- currently executing function, to be automatically released when this function
- returns to its caller. The object is always allocated in the generic address
- space (address space zero).</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>alloca</tt>' instruction
- allocates <tt>sizeof(<type>)*NumElements</tt> bytes of memory on the
- runtime stack, returning a pointer of the appropriate type to the program.
- If "NumElements" is specified, it is the number of elements allocated,
- otherwise "NumElements" is defaulted to be one. If a constant alignment is
- specified, the value result of the allocation is guaranteed to be aligned to
- at least that boundary. If not specified, or if zero, the target can choose
- to align the allocation on any convenient boundary compatible with the
- type.</p>
-
-<p>'<tt>type</tt>' may be any sized type.</p>
-
-<h5>Semantics:</h5>
-<p>Memory is allocated; a pointer is returned. The operation is undefined if
- there is insufficient stack space for the allocation. '<tt>alloca</tt>'d
- memory is automatically released when the function returns. The
- '<tt>alloca</tt>' instruction is commonly used to represent automatic
- variables that must have an address available. When the function returns
- (either with the <tt><a href="#i_ret">ret</a></tt>
- or <tt><a href="#i_unwind">unwind</a></tt> instructions), the memory is
- reclaimed. Allocating zero bytes is legal, but the result is undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- %ptr = alloca i32 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
- %ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_load">'<tt>load</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
- <result> = volatile load <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>]
- !<index> = !{ i32 1 }
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>load</tt>' instruction is used to read from memory.</p>
-
-<h5>Arguments:</h5>
-<p>The argument to the '<tt>load</tt>' instruction specifies the memory address
- from which to load. The pointer must point to
- a <a href="#t_firstclass">first class</a> type. If the <tt>load</tt> is
- marked as <tt>volatile</tt>, then the optimizer is not allowed to modify the
- number or order of execution of this <tt>load</tt> with other <a
- href="#volatile">volatile operations</a>.</p>
-
-<p>The optional constant <tt>align</tt> argument specifies the alignment of the
- operation (that is, the alignment of the memory address). A value of 0 or an
- omitted <tt>align</tt> argument means that the operation has the preferential
- alignment for the target. It is the responsibility of the code emitter to
- ensure that the alignment information is correct. Overestimating the
- alignment results in undefined behavior. Underestimating the alignment may
- produce less efficient code. An alignment of 1 is always safe.</p>
-
-<p>The optional <tt>!nontemporal</tt> metadata must reference a single
- metatadata name <index> corresponding to a metadata node with
- one <tt>i32</tt> entry of value 1. The existence of
- the <tt>!nontemporal</tt> metatadata on the instruction tells the optimizer
- and code generator that this load is not expected to be reused in the cache.
- The code generator may select special instructions to save cache bandwidth,
- such as the <tt>MOVNT</tt> instruction on x86.</p>
-
-<h5>Semantics:</h5>
-<p>The location of memory pointed to is loaded. If the value being loaded is of
- scalar type then the number of bytes read does not exceed the minimum number
- of bytes needed to hold all bits of the type. For example, loading an
- <tt>i24</tt> reads at most three bytes. When loading a value of a type like
- <tt>i20</tt> with a size that is not an integral number of bytes, the result
- is undefined if the value was not originally written using a store of the
- same type.</p>
-
-<h5>Examples:</h5>
-<pre>
- %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
- <a href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i>
- %val = load i32* %ptr <i>; yields {i32}:val = i32 3</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_store">'<tt>store</tt>'
-Instruction</a> </div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
- volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>][, !nontemporal !<index>] <i>; yields {void}</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>store</tt>' instruction is used to write to memory.</p>
-
-<h5>Arguments:</h5>
-<p>There are two arguments to the '<tt>store</tt>' instruction: a value to store
- and an address at which to store it. The type of the
- '<tt><pointer></tt>' operand must be a pointer to
- the <a href="#t_firstclass">first class</a> type of the
- '<tt><value></tt>' operand. If the <tt>store</tt> is marked as
- <tt>volatile</tt>, then the optimizer is not allowed to modify the number or
- order of execution of this <tt>store</tt> with other <a
- href="#volatile">volatile operations</a>.</p>
-
-<p>The optional constant "align" argument specifies the alignment of the
- operation (that is, the alignment of the memory address). A value of 0 or an
- omitted "align" argument means that the operation has the preferential
- alignment for the target. It is the responsibility of the code emitter to
- ensure that the alignment information is correct. Overestimating the
- alignment results in an undefined behavior. Underestimating the alignment may
- produce less efficient code. An alignment of 1 is always safe.</p>
-
-<p>The optional !nontemporal metadata must reference a single metatadata
- name <index> corresponding to a metadata node with one i32 entry of
- value 1. The existence of the !nontemporal metatadata on the
- instruction tells the optimizer and code generator that this load is
- not expected to be reused in the cache. The code generator may
- select special instructions to save cache bandwidth, such as the
- MOVNT instruction on x86.</p>
-
-
-<h5>Semantics:</h5>
-<p>The contents of memory are updated to contain '<tt><value></tt>' at the
- location specified by the '<tt><pointer></tt>' operand. If
- '<tt><value></tt>' is of scalar type then the number of bytes written
- does not exceed the minimum number of bytes needed to hold all bits of the
- type. For example, storing an <tt>i24</tt> writes at most three bytes. When
- writing a value of a type like <tt>i20</tt> with a size that is not an
- integral number of bytes, it is unspecified what happens to the extra bits
- that do not belong to the type, but they will typically be overwritten.</p>
-
-<h5>Example:</h5>
-<pre>
- %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
- store i32 3, i32* %ptr <i>; yields {void}</i>
- %val = <a href="#i_load">load</a> i32* %ptr <i>; yields {i32}:val = i32 3</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_getelementptr">'<tt>getelementptr</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
- <result> = getelementptr inbounds <pty>* <ptrval>{, <ty> <idx>}*
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>getelementptr</tt>' instruction is used to get the address of a
- subelement of an <a href="#t_aggregate">aggregate</a> data structure.
- It performs address calculation only and does not access memory.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is always a pointer, and forms the basis of the
- calculation. The remaining arguments are indices that indicate which of the
- elements of the aggregate object are indexed. The interpretation of each
- index is dependent on the type being indexed into. The first index always
- indexes the pointer value given as the first argument, the second index
- indexes a value of the type pointed to (not necessarily the value directly
- pointed to, since the first index can be non-zero), etc. The first type
- indexed into must be a pointer value, subsequent types can be arrays,
- vectors, structs and unions. Note that subsequent types being indexed into
- can never be pointers, since that would require loading the pointer before
- continuing calculation.</p>
-
-<p>The type of each index argument depends on the type it is indexing into.
- When indexing into a (optionally packed) structure or union, only <tt>i32</tt>
- integer <b>constants</b> are allowed. When indexing into an array, pointer
- or vector, integers of any width are allowed, and they are not required to be
- constant.</p>
-
-<p>For example, let's consider a C code fragment and how it gets compiled to
- LLVM:</p>
-
-<div class="doc_code">
-<pre>
-struct RT {
- char A;
- int B[10][20];
- char C;
-};
-struct ST {
- int X;
- double Y;
- struct RT Z;
-};
-
-int *foo(struct ST *s) {
- return &s[1].Z.B[5][13];
-}
-</pre>
-</div>
-
-<p>The LLVM code generated by the GCC frontend is:</p>
-
-<div class="doc_code">
-<pre>
-%RT = <a href="#namedtypes">type</a> { i8 , [10 x [20 x i32]], i8 }
-%ST = <a href="#namedtypes">type</a> { i32, double, %RT }
-
-define i32* @foo(%ST* %s) {
-entry:
- %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
- ret i32* %reg
-}
-</pre>
-</div>
-
-<h5>Semantics:</h5>
-<p>In the example above, the first index is indexing into the '<tt>%ST*</tt>'
- type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT
- }</tt>' type, a structure. The second index indexes into the third element
- of the structure, yielding a '<tt>%RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]],
- i8 }</tt>' type, another structure. The third index indexes into the second
- element of the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an
- array. The two dimensions of the array are subscripted into, yielding an
- '<tt>i32</tt>' type. The '<tt>getelementptr</tt>' instruction returns a
- pointer to this element, thus computing a value of '<tt>i32*</tt>' type.</p>
-
-<p>Note that it is perfectly legal to index partially through a structure,
- returning a pointer to an inner element. Because of this, the LLVM code for
- the given testcase is equivalent to:</p>
-
-<pre>
- define i32* @foo(%ST* %s) {
- %t1 = getelementptr %ST* %s, i32 1 <i>; yields %ST*:%t1</i>
- %t2 = getelementptr %ST* %t1, i32 0, i32 2 <i>; yields %RT*:%t2</i>
- %t3 = getelementptr %RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i>
- %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i>
- %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i>
- ret i32* %t5
- }
-</pre>
-
-<p>If the <tt>inbounds</tt> keyword is present, the result value of the
- <tt>getelementptr</tt> is a <a href="#trapvalues">trap value</a> if the
- base pointer is not an <i>in bounds</i> address of an allocated object,
- or if any of the addresses that would be formed by successive addition of
- the offsets implied by the indices to the base address with infinitely
- precise arithmetic are not an <i>in bounds</i> address of that allocated
- object. The <i>in bounds</i> addresses for an allocated object are all
- the addresses that point into the object, plus the address one byte past
- the end.</p>
-
-<p>If the <tt>inbounds</tt> keyword is not present, the offsets are added to
- the base address with silently-wrapping two's complement arithmetic, and
- the result value of the <tt>getelementptr</tt> may be outside the object
- pointed to by the base pointer. The result value may not necessarily be
- used to access memory though, even if it happens to point into allocated
- storage. See the <a href="#pointeraliasing">Pointer Aliasing Rules</a>
- section for more information.</p>
-
-<p>The getelementptr instruction is often confusing. For some more insight into
- how it works, see <a href="GetElementPtr.html">the getelementptr FAQ</a>.</p>
-
-<h5>Example:</h5>
-<pre>
- <i>; yields [12 x i8]*:aptr</i>
- %aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1
- <i>; yields i8*:vptr</i>
- %vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
- <i>; yields i8*:eptr</i>
- %eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
- <i>; yields i32*:iptr</i>
- %iptr = getelementptr [10 x i32]* @arr, i16 0, i16 0
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="convertops">Conversion Operations</a>
-</div>
-
-<div class="doc_text">
-
-<p>The instructions in this category are the conversion instructions (casting)
- which all take a single operand and a type. They perform various bit
- conversions on the operand.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_trunc">'<tt>trunc .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = trunc <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>trunc</tt>' instruction truncates its operand to the
- type <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>trunc</tt>' instruction takes a <tt>value</tt> to trunc, which must
- be an <a href="#t_integer">integer</a> type, and a type that specifies the
- size and type of the result, which must be
- an <a href="#t_integer">integer</a> type. The bit size of <tt>value</tt> must
- be larger than the bit size of <tt>ty2</tt>. Equal sized types are not
- allowed.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>trunc</tt>' instruction truncates the high order bits
- in <tt>value</tt> and converts the remaining bits to <tt>ty2</tt>. Since the
- source size must be larger than the destination size, <tt>trunc</tt> cannot
- be a <i>no-op cast</i>. It will always truncate bits.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = trunc i32 257 to i8 <i>; yields i8:1</i>
- %Y = trunc i32 123 to i1 <i>; yields i1:true</i>
- %Z = trunc i32 122 to i1 <i>; yields i1:false</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_zext">'<tt>zext .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = zext <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>zext</tt>' instruction zero extends its operand to type
- <tt>ty2</tt>.</p>
-
-
-<h5>Arguments:</h5>
-<p>The '<tt>zext</tt>' instruction takes a value to cast, which must be of
- <a href="#t_integer">integer</a> type, and a type to cast it to, which must
- also be of <a href="#t_integer">integer</a> type. The bit size of the
- <tt>value</tt> must be smaller than the bit size of the destination type,
- <tt>ty2</tt>.</p>
-
-<h5>Semantics:</h5>
-<p>The <tt>zext</tt> fills the high order bits of the <tt>value</tt> with zero
- bits until it reaches the size of the destination type, <tt>ty2</tt>.</p>
-
-<p>When zero extending from i1, the result will always be either 0 or 1.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = zext i32 257 to i64 <i>; yields i64:257</i>
- %Y = zext i1 true to i32 <i>; yields i32:1</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_sext">'<tt>sext .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = sext <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>sext</tt>' sign extends <tt>value</tt> to the type <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>sext</tt>' instruction takes a value to cast, which must be of
- <a href="#t_integer">integer</a> type, and a type to cast it to, which must
- also be of <a href="#t_integer">integer</a> type. The bit size of the
- <tt>value</tt> must be smaller than the bit size of the destination type,
- <tt>ty2</tt>.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>sext</tt>' instruction performs a sign extension by copying the sign
- bit (highest order bit) of the <tt>value</tt> until it reaches the bit size
- of the type <tt>ty2</tt>.</p>
-
-<p>When sign extending from i1, the extension always results in -1 or 0.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = sext i8 -1 to i16 <i>; yields i16 :65535</i>
- %Y = sext i1 true to i32 <i>; yields i32:-1</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fptrunc <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fptrunc</tt>' instruction truncates <tt>value</tt> to type
- <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>fptrunc</tt>' instruction takes a <a href="#t_floating">floating
- point</a> value to cast and a <a href="#t_floating">floating point</a> type
- to cast it to. The size of <tt>value</tt> must be larger than the size of
- <tt>ty2</tt>. This implies that <tt>fptrunc</tt> cannot be used to make a
- <i>no-op cast</i>.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>fptrunc</tt>' instruction truncates a <tt>value</tt> from a larger
- <a href="#t_floating">floating point</a> type to a smaller
- <a href="#t_floating">floating point</a> type. If the value cannot fit
- within the destination type, <tt>ty2</tt>, then the results are
- undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = fptrunc double 123.0 to float <i>; yields float:123.0</i>
- %Y = fptrunc double 1.0E+300 to float <i>; yields undefined</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fpext">'<tt>fpext .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fpext <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fpext</tt>' extends a floating point <tt>value</tt> to a larger
- floating point value.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>fpext</tt>' instruction takes a
- <a href="#t_floating">floating point</a> <tt>value</tt> to cast, and
- a <a href="#t_floating">floating point</a> type to cast it to. The source
- type must be smaller than the destination type.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>fpext</tt>' instruction extends the <tt>value</tt> from a smaller
- <a href="#t_floating">floating point</a> type to a larger
- <a href="#t_floating">floating point</a> type. The <tt>fpext</tt> cannot be
- used to make a <i>no-op cast</i> because it always changes bits. Use
- <tt>bitcast</tt> to make a <i>no-op cast</i> for a floating point cast.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = fpext float 3.1415 to double <i>; yields double:3.1415</i>
- %Y = fpext float 1.0 to float <i>; yields float:1.0 (no-op)</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fptoui <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fptoui</tt>' converts a floating point <tt>value</tt> to its
- unsigned integer equivalent of type <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>fptoui</tt>' instruction takes a value to cast, which must be a
- scalar or vector <a href="#t_floating">floating point</a> value, and a type
- to cast it to <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a>
- type. If <tt>ty</tt> is a vector floating point type, <tt>ty2</tt> must be a
- vector integer type with the same number of elements as <tt>ty</tt></p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>fptoui</tt>' instruction converts its
- <a href="#t_floating">floating point</a> operand into the nearest (rounding
- towards zero) unsigned integer value. If the value cannot fit
- in <tt>ty2</tt>, the results are undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = fptoui double 123.0 to i32 <i>; yields i32:123</i>
- %Y = fptoui float 1.0E+300 to i1 <i>; yields undefined:1</i>
- %Z = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fptosi <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fptosi</tt>' instruction converts
- <a href="#t_floating">floating point</a> <tt>value</tt> to
- type <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>fptosi</tt>' instruction takes a value to cast, which must be a
- scalar or vector <a href="#t_floating">floating point</a> value, and a type
- to cast it to <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a>
- type. If <tt>ty</tt> is a vector floating point type, <tt>ty2</tt> must be a
- vector integer type with the same number of elements as <tt>ty</tt></p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>fptosi</tt>' instruction converts its
- <a href="#t_floating">floating point</a> operand into the nearest (rounding
- towards zero) signed integer value. If the value cannot fit in <tt>ty2</tt>,
- the results are undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = fptosi double -123.0 to i32 <i>; yields i32:-123</i>
- %Y = fptosi float 1.0E-247 to i1 <i>; yields undefined:1</i>
- %Z = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = uitofp <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>uitofp</tt>' instruction regards <tt>value</tt> as an unsigned
- integer and converts that value to the <tt>ty2</tt> type.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>uitofp</tt>' instruction takes a value to cast, which must be a
- scalar or vector <a href="#t_integer">integer</a> value, and a type to cast
- it to <tt>ty2</tt>, which must be an <a href="#t_floating">floating point</a>
- type. If <tt>ty</tt> is a vector integer type, <tt>ty2</tt> must be a vector
- floating point type with the same number of elements as <tt>ty</tt></p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>uitofp</tt>' instruction interprets its operand as an unsigned
- integer quantity and converts it to the corresponding floating point
- value. If the value cannot fit in the floating point value, the results are
- undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = uitofp i32 257 to float <i>; yields float:257.0</i>
- %Y = uitofp i8 -1 to double <i>; yields double:255.0</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = sitofp <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>sitofp</tt>' instruction regards <tt>value</tt> as a signed integer
- and converts that value to the <tt>ty2</tt> type.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>sitofp</tt>' instruction takes a value to cast, which must be a
- scalar or vector <a href="#t_integer">integer</a> value, and a type to cast
- it to <tt>ty2</tt>, which must be an <a href="#t_floating">floating point</a>
- type. If <tt>ty</tt> is a vector integer type, <tt>ty2</tt> must be a vector
- floating point type with the same number of elements as <tt>ty</tt></p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>sitofp</tt>' instruction interprets its operand as a signed integer
- quantity and converts it to the corresponding floating point value. If the
- value cannot fit in the floating point value, the results are undefined.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = sitofp i32 257 to float <i>; yields float:257.0</i>
- %Y = sitofp i8 -1 to double <i>; yields double:-1.0</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = ptrtoint <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>ptrtoint</tt>' instruction converts the pointer <tt>value</tt> to
- the integer type <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which
- must be a <a href="#t_pointer">pointer</a> value, and a type to cast it to
- <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> type.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type
- <tt>ty2</tt> by interpreting the pointer value as an integer and either
- truncating or zero extending that value to the size of the integer type. If
- <tt>value</tt> is smaller than <tt>ty2</tt> then a zero extension is done. If
- <tt>value</tt> is larger than <tt>ty2</tt> then a truncation is done. If they
- are the same size, then nothing is done (<i>no-op cast</i>) other than a type
- change.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i>
- %Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = inttoptr <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>inttoptr</tt>' instruction converts an integer <tt>value</tt> to a
- pointer type, <tt>ty2</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>inttoptr</tt>' instruction takes an <a href="#t_integer">integer</a>
- value to cast, and a type to cast it to, which must be a
- <a href="#t_pointer">pointer</a> type.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>inttoptr</tt>' instruction converts <tt>value</tt> to type
- <tt>ty2</tt> by applying either a zero extension or a truncation depending on
- the size of the integer <tt>value</tt>. If <tt>value</tt> is larger than the
- size of a pointer then a truncation is done. If <tt>value</tt> is smaller
- than the size of a pointer then a zero extension is done. If they are the
- same size, nothing is done (<i>no-op cast</i>).</p>
-
-<h5>Example:</h5>
-<pre>
- %X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i>
- %Y = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
- %Z = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a>
-</div>
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = bitcast <ty> <value> to <ty2> <i>; yields ty2</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
- <tt>ty2</tt> without changing any bits.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>bitcast</tt>' instruction takes a value to cast, which must be a
- non-aggregate first class value, and a type to cast it to, which must also be
- a non-aggregate <a href="#t_firstclass">first class</a> type. The bit sizes
- of <tt>value</tt> and the destination type, <tt>ty2</tt>, must be
- identical. If the source type is a pointer, the destination type must also be
- a pointer. This instruction supports bitwise conversion of vectors to
- integers and to vectors of other types (as long as they have the same
- size).</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
- <tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with
- this conversion. The conversion is done as if the <tt>value</tt> had been
- stored to memory and read back as type <tt>ty2</tt>. Pointer types may only
- be converted to other pointer types with this instruction. To convert
- pointers to other types, use the <a href="#i_inttoptr">inttoptr</a> or
- <a href="#i_ptrtoint">ptrtoint</a> instructions first.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
- %Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i>
- %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i>
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"> <a name="otherops">Other Operations</a> </div>
-
-<div class="doc_text">
-
-<p>The instructions in this category are the "miscellaneous" instructions, which
- defy better classification.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a name="i_icmp">'<tt>icmp</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = icmp <cond> <ty> <op1>, <op2> <i>; yields {i1} or {<N x i1>}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>icmp</tt>' instruction returns a boolean value or a vector of
- boolean values based on comparison of its two integer, integer vector, or
- pointer operands.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is
- the condition code indicating the kind of comparison to perform. It is not a
- value, just a keyword. The possible condition code are:</p>
-
-<ol>
- <li><tt>eq</tt>: equal</li>
- <li><tt>ne</tt>: not equal </li>
- <li><tt>ugt</tt>: unsigned greater than</li>
- <li><tt>uge</tt>: unsigned greater or equal</li>
- <li><tt>ult</tt>: unsigned less than</li>
- <li><tt>ule</tt>: unsigned less or equal</li>
- <li><tt>sgt</tt>: signed greater than</li>
- <li><tt>sge</tt>: signed greater or equal</li>
- <li><tt>slt</tt>: signed less than</li>
- <li><tt>sle</tt>: signed less or equal</li>
-</ol>
-
-<p>The remaining two arguments must be <a href="#t_integer">integer</a> or
- <a href="#t_pointer">pointer</a> or integer <a href="#t_vector">vector</a>
- typed. They must also be identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>icmp</tt>' compares <tt>op1</tt> and <tt>op2</tt> according to the
- condition code given as <tt>cond</tt>. The comparison performed always yields
- either an <a href="#t_integer"><tt>i1</tt></a> or vector of <tt>i1</tt>
- result, as follows:</p>
-
-<ol>
- <li><tt>eq</tt>: yields <tt>true</tt> if the operands are equal,
- <tt>false</tt> otherwise. No sign interpretation is necessary or
- performed.</li>
-
- <li><tt>ne</tt>: yields <tt>true</tt> if the operands are unequal,
- <tt>false</tt> otherwise. No sign interpretation is necessary or
- performed.</li>
-
- <li><tt>ugt</tt>: interprets the operands as unsigned values and yields
- <tt>true</tt> if <tt>op1</tt> is greater than <tt>op2</tt>.</li>
-
- <li><tt>uge</tt>: interprets the operands as unsigned values and yields
- <tt>true</tt> if <tt>op1</tt> is greater than or equal
- to <tt>op2</tt>.</li>
-
- <li><tt>ult</tt>: interprets the operands as unsigned values and yields
- <tt>true</tt> if <tt>op1</tt> is less than <tt>op2</tt>.</li>
-
- <li><tt>ule</tt>: interprets the operands as unsigned values and yields
- <tt>true</tt> if <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
-
- <li><tt>sgt</tt>: interprets the operands as signed values and yields
- <tt>true</tt> if <tt>op1</tt> is greater than <tt>op2</tt>.</li>
-
- <li><tt>sge</tt>: interprets the operands as signed values and yields
- <tt>true</tt> if <tt>op1</tt> is greater than or equal
- to <tt>op2</tt>.</li>
-
- <li><tt>slt</tt>: interprets the operands as signed values and yields
- <tt>true</tt> if <tt>op1</tt> is less than <tt>op2</tt>.</li>
-
- <li><tt>sle</tt>: interprets the operands as signed values and yields
- <tt>true</tt> if <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
-</ol>
-
-<p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer
- values are compared as if they were integers.</p>
-
-<p>If the operands are integer vectors, then they are compared element by
- element. The result is an <tt>i1</tt> vector with the same number of elements
- as the values being compared. Otherwise, the result is an <tt>i1</tt>.</p>
-
-<h5>Example:</h5>
-<pre>
- <result> = icmp eq i32 4, 5 <i>; yields: result=false</i>
- <result> = icmp ne float* %X, %X <i>; yields: result=false</i>
- <result> = icmp ult i16 4, 5 <i>; yields: result=true</i>
- <result> = icmp sgt i16 4, 5 <i>; yields: result=false</i>
- <result> = icmp ule i16 -4, 5 <i>; yields: result=false</i>
- <result> = icmp sge i16 4, 5 <i>; yields: result=false</i>
-</pre>
-
-<p>Note that the code generator does not yet support vector types with
- the <tt>icmp</tt> instruction.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a name="i_fcmp">'<tt>fcmp</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = fcmp <cond> <ty> <op1>, <op2> <i>; yields {i1} or {<N x i1>}:result</i>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>fcmp</tt>' instruction returns a boolean value or vector of boolean
- values based on comparison of its operands.</p>
-
-<p>If the operands are floating point scalars, then the result type is a boolean
-(<a href="#t_integer"><tt>i1</tt></a>).</p>
-
-<p>If the operands are floating point vectors, then the result type is a vector
- of boolean with the same number of elements as the operands being
- compared.</p>
-
-<h5>Arguments:</h5>
-<p>The '<tt>fcmp</tt>' instruction takes three operands. The first operand is
- the condition code indicating the kind of comparison to perform. It is not a
- value, just a keyword. The possible condition code are:</p>
-
-<ol>
- <li><tt>false</tt>: no comparison, always returns false</li>
- <li><tt>oeq</tt>: ordered and equal</li>
- <li><tt>ogt</tt>: ordered and greater than </li>
- <li><tt>oge</tt>: ordered and greater than or equal</li>
- <li><tt>olt</tt>: ordered and less than </li>
- <li><tt>ole</tt>: ordered and less than or equal</li>
- <li><tt>one</tt>: ordered and not equal</li>
- <li><tt>ord</tt>: ordered (no nans)</li>
- <li><tt>ueq</tt>: unordered or equal</li>
- <li><tt>ugt</tt>: unordered or greater than </li>
- <li><tt>uge</tt>: unordered or greater than or equal</li>
- <li><tt>ult</tt>: unordered or less than </li>
- <li><tt>ule</tt>: unordered or less than or equal</li>
- <li><tt>une</tt>: unordered or not equal</li>
- <li><tt>uno</tt>: unordered (either nans)</li>
- <li><tt>true</tt>: no comparison, always returns true</li>
-</ol>
-
-<p><i>Ordered</i> means that neither operand is a QNAN while
- <i>unordered</i> means that either operand may be a QNAN.</p>
-
-<p>Each of <tt>val1</tt> and <tt>val2</tt> arguments must be either
- a <a href="#t_floating">floating point</a> type or
- a <a href="#t_vector">vector</a> of floating point type. They must have
- identical types.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>fcmp</tt>' instruction compares <tt>op1</tt> and <tt>op2</tt>
- according to the condition code given as <tt>cond</tt>. If the operands are
- vectors, then the vectors are compared element by element. Each comparison
- performed always yields an <a href="#t_integer">i1</a> result, as
- follows:</p>
-
-<ol>
- <li><tt>false</tt>: always yields <tt>false</tt>, regardless of operands.</li>
-
- <li><tt>oeq</tt>: yields <tt>true</tt> if both operands are not a QNAN and
- <tt>op1</tt> is equal to <tt>op2</tt>.</li>
-
- <li><tt>ogt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
- <tt>op1</tt> is greater than <tt>op2</tt>.</li>
-
- <li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and
- <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
-
- <li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
- <tt>op1</tt> is less than <tt>op2</tt>.</li>
-
- <li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and
- <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
-
- <li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and
- <tt>op1</tt> is not equal to <tt>op2</tt>.</li>
-
- <li><tt>ord</tt>: yields <tt>true</tt> if both operands are not a QNAN.</li>
-
- <li><tt>ueq</tt>: yields <tt>true</tt> if either operand is a QNAN or
- <tt>op1</tt> is equal to <tt>op2</tt>.</li>
-
- <li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or
- <tt>op1</tt> is greater than <tt>op2</tt>.</li>
-
- <li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or
- <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
-
- <li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or
- <tt>op1</tt> is less than <tt>op2</tt>.</li>
-
- <li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or
- <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
-
- <li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or
- <tt>op1</tt> is not equal to <tt>op2</tt>.</li>
-
- <li><tt>uno</tt>: yields <tt>true</tt> if either operand is a QNAN.</li>
-
- <li><tt>true</tt>: always yields <tt>true</tt>, regardless of operands.</li>
-</ol>
-
-<h5>Example:</h5>
-<pre>
- <result> = fcmp oeq float 4.0, 5.0 <i>; yields: result=false</i>
- <result> = fcmp one float 4.0, 5.0 <i>; yields: result=true</i>
- <result> = fcmp olt float 4.0, 5.0 <i>; yields: result=true</i>
- <result> = fcmp ueq double 1.0, 2.0 <i>; yields: result=false</i>
-</pre>
-
-<p>Note that the code generator does not yet support vector types with
- the <tt>fcmp</tt> instruction.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_phi">'<tt>phi</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = phi <ty> [ <val0>, <label0>], ...
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>phi</tt>' instruction is used to implement the φ node in the
- SSA graph representing the function.</p>
-
-<h5>Arguments:</h5>
-<p>The type of the incoming values is specified with the first type field. After
- this, the '<tt>phi</tt>' instruction takes a list of pairs as arguments, with
- one pair for each predecessor basic block of the current block. Only values
- of <a href="#t_firstclass">first class</a> type may be used as the value
- arguments to the PHI node. Only labels may be used as the label
- arguments.</p>
-
-<p>There must be no non-phi instructions between the start of a basic block and
- the PHI instructions: i.e. PHI instructions must be first in a basic
- block.</p>
-
-<p>For the purposes of the SSA form, the use of each incoming value is deemed to
- occur on the edge from the corresponding predecessor block to the current
- block (but after any definition of an '<tt>invoke</tt>' instruction's return
- value on the same edge).</p>
-
-<h5>Semantics:</h5>
-<p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value
- specified by the pair corresponding to the predecessor basic block that
- executed just prior to the current block.</p>
-
-<h5>Example:</h5>
-<pre>
-Loop: ; Infinite loop that counts from 0 on up...
- %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
- %nextindvar = add i32 %indvar, 1
- br label %Loop
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_select">'<tt>select</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = select <i>selty</i> <cond>, <ty> <val1>, <ty> <val2> <i>; yields ty</i>
-
- <i>selty</i> is either i1 or {<N x i1>}
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>select</tt>' instruction is used to choose one value based on a
- condition, without branching.</p>
-
-
-<h5>Arguments:</h5>
-<p>The '<tt>select</tt>' instruction requires an 'i1' value or a vector of 'i1'
- values indicating the condition, and two values of the
- same <a href="#t_firstclass">first class</a> type. If the val1/val2 are
- vectors and the condition is a scalar, then entire vectors are selected, not
- individual elements.</p>
-
-<h5>Semantics:</h5>
-<p>If the condition is an i1 and it evaluates to 1, the instruction returns the
- first value argument; otherwise, it returns the second value argument.</p>
-
-<p>If the condition is a vector of i1, then the value arguments must be vectors
- of the same size, and the selection is done element by element.</p>
-
-<h5>Example:</h5>
-<pre>
- %X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i>
-</pre>
-
-<p>Note that the code generator does not yet support conditions
- with vector type.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_call">'<tt>call</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <result> = [tail] call [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] <ty> [<fnty>*] <fnptrval>(<function args>) [<a href="#fnattrs">fn attrs</a>]
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>call</tt>' instruction represents a simple function call.</p>
-
-<h5>Arguments:</h5>
-<p>This instruction requires several arguments:</p>
-
-<ol>
- <li>The optional "tail" marker indicates that the callee function does not
- access any allocas or varargs in the caller. Note that calls may be
- marked "tail" even if they do not occur before
- a <a href="#i_ret"><tt>ret</tt></a> instruction. If the "tail" marker is
- present, the function call is eligible for tail call optimization,
- but <a href="CodeGenerator.html#tailcallopt">might not in fact be
- optimized into a jump</a>. The code generator may optimize calls marked
- "tail" with either 1) automatic <a href="CodeGenerator.html#sibcallopt">
- sibling call optimization</a> when the caller and callee have
- matching signatures, or 2) forced tail call optimization when the
- following extra requirements are met:
- <ul>
- <li>Caller and callee both have the calling
- convention <tt>fastcc</tt>.</li>
- <li>The call is in tail position (ret immediately follows call and ret
- uses value of call or is void).</li>
- <li>Option <tt>-tailcallopt</tt> is enabled,
- or <code>llvm::GuaranteedTailCallOpt</code> is <code>true</code>.</li>
- <li><a href="CodeGenerator.html#tailcallopt">Platform specific
- constraints are met.</a></li>
- </ul>
- </li>
-
- <li>The optional "cconv" marker indicates which <a href="#callingconv">calling
- convention</a> the call should use. If none is specified, the call
- defaults to using C calling conventions. The calling convention of the
- call must match the calling convention of the target function, or else the
- behavior is undefined.</li>
-
- <li>The optional <a href="#paramattrs">Parameter Attributes</a> list for
- return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>', and
- '<tt>inreg</tt>' attributes are valid here.</li>
-
- <li>'<tt>ty</tt>': the type of the call instruction itself which is also the
- type of the return value. Functions that return no value are marked
- <tt><a href="#t_void">void</a></tt>.</li>
-
- <li>'<tt>fnty</tt>': shall be the signature of the pointer to function value
- being invoked. The argument types must match the types implied by this
- signature. This type can be omitted if the function is not varargs and if
- the function type does not return a pointer to a function.</li>
-
- <li>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to
- be invoked. In most cases, this is a direct function invocation, but
- indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer
- to function value.</li>
-
- <li>'<tt>function args</tt>': argument list whose types match the function
- signature argument types and parameter attributes. All arguments must be
- of <a href="#t_firstclass">first class</a> type. If the function
- signature indicates the function accepts a variable number of arguments,
- the extra arguments can be specified.</li>
-
- <li>The optional <a href="#fnattrs">function attributes</a> list. Only
- '<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and
- '<tt>readnone</tt>' attributes are valid here.</li>
-</ol>
-
-<h5>Semantics:</h5>
-<p>The '<tt>call</tt>' instruction is used to cause control flow to transfer to
- a specified function, with its incoming arguments bound to the specified
- values. Upon a '<tt><a href="#i_ret">ret</a></tt>' instruction in the called
- function, control flow continues with the instruction after the function
- call, and the return value of the function is bound to the result
- argument.</p>
-
-<h5>Example:</h5>
-<pre>
- %retval = call i32 @test(i32 %argc)
- call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42) <i>; yields i32</i>
- %X = tail call i32 @foo() <i>; yields i32</i>
- %Y = tail call <a href="#callingconv">fastcc</a> i32 @foo() <i>; yields i32</i>
- call void %foo(i8 97 signext)
-
- %struct.A = type { i32, i8 }
- %r = call %struct.A @foo() <i>; yields { 32, i8 }</i>
- %gr = extractvalue %struct.A %r, 0 <i>; yields i32</i>
- %gr1 = extractvalue %struct.A %r, 1 <i>; yields i8</i>
- %Z = call void @foo() noreturn <i>; indicates that %foo never returns normally</i>
- %ZZ = call zeroext i32 @bar() <i>; Return value is %zero extended</i>
-</pre>
-
-<p>llvm treats calls to some functions with names and arguments that match the
-standard C99 library as being the C99 library functions, and may perform
-optimizations or generate code for them under that assumption. This is
-something we'd like to change in the future to provide better support for
-freestanding environments and non-C-based languages.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="i_va_arg">'<tt>va_arg</tt>' Instruction</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- <resultval> = va_arg <va_list*> <arglist>, <argty>
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>va_arg</tt>' instruction is used to access arguments passed through
- the "variable argument" area of a function call. It is used to implement the
- <tt>va_arg</tt> macro in C.</p>
-
-<h5>Arguments:</h5>
-<p>This instruction takes a <tt>va_list*</tt> value and the type of the
- argument. It returns a value of the specified argument type and increments
- the <tt>va_list</tt> to point to the next argument. The actual type
- of <tt>va_list</tt> is target specific.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>va_arg</tt>' instruction loads an argument of the specified type
- from the specified <tt>va_list</tt> and causes the <tt>va_list</tt> to point
- to the next argument. For more information, see the variable argument
- handling <a href="#int_varargs">Intrinsic Functions</a>.</p>
-
-<p>It is legal for this instruction to be called in a function which does not
- take a variable number of arguments, for example, the <tt>vfprintf</tt>
- function.</p>
-
-<p><tt>va_arg</tt> is an LLVM instruction instead of
- an <a href="#intrinsics">intrinsic function</a> because it takes a type as an
- argument.</p>
-
-<h5>Example:</h5>
-<p>See the <a href="#int_varargs">variable argument processing</a> section.</p>
-
-<p>Note that the code generator does not yet fully support va_arg on many
- targets. Also, it does not currently support va_arg with aggregate types on
- any target.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>LLVM supports the notion of an "intrinsic function". These functions have
- well known names and semantics and are required to follow certain
- restrictions. Overall, these intrinsics represent an extension mechanism for
- the LLVM language that does not require changing all of the transformations
- in LLVM when adding to the language (or the bitcode reader/writer, the
- parser, etc...).</p>
-
-<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This
- prefix is reserved in LLVM for intrinsic names; thus, function names may not
- begin with this prefix. Intrinsic functions must always be external
- functions: you cannot define the body of intrinsic functions. Intrinsic
- functions may only be used in call or invoke instructions: it is illegal to
- take the address of an intrinsic function. Additionally, because intrinsic
- functions are part of the LLVM language, it is required if any are added that
- they be documented here.</p>
-
-<p>Some intrinsic functions can be overloaded, i.e., the intrinsic represents a
- family of functions that perform the same operation but on different data
- types. Because LLVM can represent over 8 million different integer types,
- overloading is used commonly to allow an intrinsic function to operate on any
- integer type. One or more of the argument types or the result type can be
- overloaded to accept any integer type. Argument types may also be defined as
- exactly matching a previous argument's type or the result type. This allows
- an intrinsic function which accepts multiple arguments, but needs all of them
- to be of the same type, to only be overloaded with respect to a single
- argument or the result.</p>
-
-<p>Overloaded intrinsics will have the names of its overloaded argument types
- encoded into its function name, each preceded by a period. Only those types
- which are overloaded result in a name suffix. Arguments whose type is matched
- against another type do not. For example, the <tt>llvm.ctpop</tt> function
- can take an integer of any width and returns an integer of exactly the same
- integer width. This leads to a family of functions such as
- <tt>i8 @llvm.ctpop.i8(i8 %val)</tt> and <tt>i29 @llvm.ctpop.i29(i29
- %val)</tt>. Only one type, the return type, is overloaded, and only one type
- suffix is required. Because the argument's type is matched against the return
- type, it does not require its own name suffix.</p>
-
-<p>To learn how to add an intrinsic function, please see the
- <a href="ExtendingLLVM.html">Extending LLVM Guide</a>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_varargs">Variable Argument Handling Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>Variable argument support is defined in LLVM with
- the <a href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three
- intrinsic functions. These functions are related to the similarly named
- macros defined in the <tt><stdarg.h></tt> header file.</p>
-
-<p>All of these functions operate on arguments that use a target-specific value
- type "<tt>va_list</tt>". The LLVM assembly language reference manual does
- not define what this type is, so all transformations should be prepared to
- handle these functions regardless of the type used.</p>
-
-<p>This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a>
- instruction and the variable argument handling intrinsic functions are
- used.</p>
-
-<div class="doc_code">
-<pre>
-define i32 @test(i32 %X, ...) {
- ; Initialize variable argument processing
- %ap = alloca i8*
- %ap2 = bitcast i8** %ap to i8*
- call void @llvm.va_start(i8* %ap2)
-
- ; Read a single integer argument
- %tmp = va_arg i8** %ap, i32
-
- ; Demonstrate usage of llvm.va_copy and llvm.va_end
- %aq = alloca i8*
- %aq2 = bitcast i8** %aq to i8*
- call void @llvm.va_copy(i8* %aq2, i8* %ap2)
- call void @llvm.va_end(i8* %aq2)
-
- ; Stop processing of arguments.
- call void @llvm.va_end(i8* %ap2)
- ret i32 %tmp
-}
-
-declare void @llvm.va_start(i8*)
-declare void @llvm.va_copy(i8*, i8*)
-declare void @llvm.va_end(i8*)
-</pre>
-</div>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
-</div>
-
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void %llvm.va_start(i8* <arglist>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.va_start</tt>' intrinsic initializes <tt>*<arglist></tt>
- for subsequent use by <tt><a href="#i_va_arg">va_arg</a></tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The argument is a pointer to a <tt>va_list</tt> element to initialize.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt>
- macro available in C. In a target-dependent way, it initializes
- the <tt>va_list</tt> element to which the argument points, so that the next
- call to <tt>va_arg</tt> will produce the first variable argument passed to
- the function. Unlike the C <tt>va_start</tt> macro, this intrinsic does not
- need to know the last argument of the function as the compiler can figure
- that out.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.va_end(i8* <arglist>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></tt>,
- which has been initialized previously
- with <tt><a href="#int_va_start">llvm.va_start</a></tt>
- or <tt><a href="#i_va_copy">llvm.va_copy</a></tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The argument is a pointer to a <tt>va_list</tt> to destroy.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt>
- macro available in C. In a target-dependent way, it destroys
- the <tt>va_list</tt> element to which the argument points. Calls
- to <a href="#int_va_start"><tt>llvm.va_start</tt></a>
- and <a href="#int_va_copy"> <tt>llvm.va_copy</tt></a> must be matched exactly
- with calls to <tt>llvm.va_end</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position
- from the source argument list to the destination argument list.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is a pointer to a <tt>va_list</tt> element to initialize.
- The second argument is a pointer to a <tt>va_list</tt> element to copy
- from.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt>
- macro available in C. In a target-dependent way, it copies the
- source <tt>va_list</tt> element into the destination <tt>va_list</tt>
- element. This intrinsic is necessary because
- the <tt><a href="#int_va_start"> llvm.va_start</a></tt> intrinsic may be
- arbitrarily complex and require, for example, memory allocation.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_gc">Accurate Garbage Collection Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM support for <a href="GarbageCollection.html">Accurate Garbage
-Collection</a> (GC) requires the implementation and generation of these
-intrinsics. These intrinsics allow identification of <a href="#int_gcroot">GC
-roots on the stack</a>, as well as garbage collector implementations that
-require <a href="#int_gcread">read</a> and <a href="#int_gcwrite">write</a>
-barriers. Front-ends for type-safe garbage collected languages should generate
-these intrinsics to make use of the LLVM garbage collectors. For more details,
-see <a href="GarbageCollection.html">Accurate Garbage Collection with
-LLVM</a>.</p>
-
-<p>The garbage collection intrinsics only operate on objects in the generic
- address space (address space zero).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to
- the code generator, and allows some metadata to be associated with it.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument specifies the address of a stack object that contains the
- root pointer. The second pointer (which must be either a constant or a
- global value address) contains the meta-data to be associated with the
- root.</p>
-
-<h5>Semantics:</h5>
-<p>At runtime, a call to this intrinsic stores a null pointer into the "ptrloc"
- location. At compile-time, the code generator generates information to allow
- the runtime to find the pointer at GC safe points. The '<tt>llvm.gcroot</tt>'
- intrinsic may only be used in a function which <a href="#gc">specifies a GC
- algorithm</a>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i8* @llvm.gcread(i8* %ObjPtr, i8** %Ptr)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.gcread</tt>' intrinsic identifies reads of references from heap
- locations, allowing garbage collector implementations that require read
- barriers.</p>
-
-<h5>Arguments:</h5>
-<p>The second argument is the address to read from, which should be an address
- allocated from the garbage collector. The first object is a pointer to the
- start of the referenced object, if needed by the language runtime (otherwise
- null).</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load
- instruction, but may be replaced with substantially more complex code by the
- garbage collector runtime, as needed. The '<tt>llvm.gcread</tt>' intrinsic
- may only be used in a function which <a href="#gc">specifies a GC
- algorithm</a>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.gcwrite(i8* %P1, i8* %Obj, i8** %P2)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.gcwrite</tt>' intrinsic identifies writes of references to heap
- locations, allowing garbage collector implementations that require write
- barriers (such as generational or reference counting collectors).</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is the reference to store, the second is the start of the
- object to store it to, and the third is the address of the field of Obj to
- store to. If the runtime does not require a pointer to the object, Obj may
- be null.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store
- instruction, but may be replaced with substantially more complex code by the
- garbage collector runtime, as needed. The '<tt>llvm.gcwrite</tt>' intrinsic
- may only be used in a function which <a href="#gc">specifies a GC
- algorithm</a>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_codegen">Code Generator Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>These intrinsics are provided by LLVM to expose special features that may
- only be implemented with code generator support.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i8 *@llvm.returnaddress(i32 <level>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.returnaddress</tt>' intrinsic attempts to compute a
- target-specific value indicating the return address of the current function
- or one of its callers.</p>
-
-<h5>Arguments:</h5>
-<p>The argument to this intrinsic indicates which function to return the address
- for. Zero indicates the calling function, one indicates its caller, etc.
- The argument is <b>required</b> to be a constant integer value.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer
- indicating the return address of the specified call frame, or zero if it
- cannot be identified. The value returned by this intrinsic is likely to be
- incorrect or 0 for arguments other than zero, so it should only be used for
- debugging purposes.</p>
-
-<p>Note that calling this intrinsic does not prevent function inlining or other
- aggressive transformations, so the value returned may not be that of the
- obvious source-language caller.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i8 *@llvm.frameaddress(i32 <level>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.frameaddress</tt>' intrinsic attempts to return the
- target-specific frame pointer value for the specified stack frame.</p>
-
-<h5>Arguments:</h5>
-<p>The argument to this intrinsic indicates which function to return the frame
- pointer for. Zero indicates the calling function, one indicates its caller,
- etc. The argument is <b>required</b> to be a constant integer value.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer
- indicating the frame address of the specified call frame, or zero if it
- cannot be identified. The value returned by this intrinsic is likely to be
- incorrect or 0 for arguments other than zero, so it should only be used for
- debugging purposes.</p>
-
-<p>Note that calling this intrinsic does not prevent function inlining or other
- aggressive transformations, so the value returned may not be that of the
- obvious source-language caller.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i8 *@llvm.stacksave()
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.stacksave</tt>' intrinsic is used to remember the current state
- of the function stack, for use
- with <a href="#int_stackrestore"> <tt>llvm.stackrestore</tt></a>. This is
- useful for implementing language features like scoped automatic variable
- sized arrays in C99.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic returns a opaque pointer value that can be passed
- to <a href="#int_stackrestore"><tt>llvm.stackrestore</tt></a>. When
- an <tt>llvm.stackrestore</tt> intrinsic is executed with a value saved
- from <tt>llvm.stacksave</tt>, it effectively restores the state of the stack
- to the state it was in when the <tt>llvm.stacksave</tt> intrinsic executed.
- In practice, this pops any <a href="#i_alloca">alloca</a> blocks from the
- stack that were allocated after the <tt>llvm.stacksave</tt> was executed.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.stackrestore(i8 * %ptr)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.stackrestore</tt>' intrinsic is used to restore the state of
- the function stack to the state it was in when the
- corresponding <a href="#int_stacksave"><tt>llvm.stacksave</tt></a> intrinsic
- executed. This is useful for implementing language features like scoped
- automatic variable sized arrays in C99.</p>
-
-<h5>Semantics:</h5>
-<p>See the description
- for <a href="#int_stacksave"><tt>llvm.stacksave</tt></a>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to
- insert a prefetch instruction if supported; otherwise, it is a noop.
- Prefetches have no effect on the behavior of the program but can change its
- performance characteristics.</p>
-
-<h5>Arguments:</h5>
-<p><tt>address</tt> is the address to be prefetched, <tt>rw</tt> is the
- specifier determining if the fetch should be for a read (0) or write (1),
- and <tt>locality</tt> is a temporal locality specifier ranging from (0) - no
- locality, to (3) - extremely local keep in cache. The <tt>rw</tt>
- and <tt>locality</tt> arguments must be constant integers.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic does not modify the behavior of the program. In particular,
- prefetches cannot trap and do not produce a value. On targets that support
- this intrinsic, the prefetch can provide hints to the processor cache for
- better performance.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.pcmarker(i32 <id>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a Program
- Counter (PC) in a region of code to simulators and other tools. The method
- is target specific, but it is expected that the marker will use exported
- symbols to transmit the PC of the marker. The marker makes no guarantees
- that it will remain with any specific instruction after optimizations. It is
- possible that the presence of a marker will inhibit optimizations. The
- intended use is to be inserted after optimizations to allow correlations of
- simulation runs.</p>
-
-<h5>Arguments:</h5>
-<p><tt>id</tt> is a numerical id identifying the marker.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic does not modify the behavior of the program. Backends that do
- not support this intrinsic may ignore it.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i64 @llvm.readcyclecounter( )
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.readcyclecounter</tt>' intrinsic provides access to the cycle
- counter register (or similar low latency, high accuracy clocks) on those
- targets that support it. On X86, it should map to RDTSC. On Alpha, it
- should map to RPCC. As the backing counters overflow quickly (on the order
- of 9 seconds on alpha), this should only be used for small timings.</p>
-
-<h5>Semantics:</h5>
-<p>When directly supported, reading the cycle counter should not modify any
- memory. Implementations are allowed to either return a application specific
- value or a system wide value. On backends without support, this is lowered
- to a constant 0.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_libc">Standard C Library Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM provides intrinsics for a few important standard C library functions.
- These intrinsics allow source-language front-ends to pass information about
- the alignment of the pointer arguments to the code generator, providing
- opportunity for more efficient code generation.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.memcpy</tt> on any
- integer bit width and for different address spaces. Not all targets support
- all bit widths however.</p>
-
-<pre>
- declare void @llvm.memcpy.p0i8.p0i8.i32(i8 * <dest>, i8 * <src>,
- i32 <len>, i32 <align>, i1 <isvolatile>)
- declare void @llvm.memcpy.p0i8.p0i8.i64(i8 * <dest>, i8 * <src>,
- i64 <len>, i32 <align>, i1 <isvolatile>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the
- source location to the destination location.</p>
-
-<p>Note that, unlike the standard libc function, the <tt>llvm.memcpy.*</tt>
- intrinsics do not return a value, takes extra alignment/isvolatile arguments
- and the pointers can be in specified address spaces.</p>
-
-<h5>Arguments:</h5>
-
-<p>The first argument is a pointer to the destination, the second is a pointer
- to the source. The third argument is an integer argument specifying the
- number of bytes to copy, the fourth argument is the alignment of the
- source and destination locations, and the fifth is a boolean indicating a
- volatile access.</p>
-
-<p>If the call to this intrinsic has an alignment value that is not 0 or 1,
- then the caller guarantees that both the source and destination pointers are
- aligned to that boundary.</p>
-
-<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the
- <tt>llvm.memcpy</tt> call is a <a href="#volatile">volatile operation</a>.
- The detailed access behavior is not very cleanly specified and it is unwise
- to depend on it.</p>
-
-<h5>Semantics:</h5>
-
-<p>The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the
- source location to the destination location, which are not allowed to
- overlap. It copies "len" bytes of memory over. If the argument is known to
- be aligned to some boundary, this can be specified as the fourth argument,
- otherwise it should be set to 0 or 1.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use llvm.memmove on any integer bit
- width and for different address space. Not all targets support all bit
- widths however.</p>
-
-<pre>
- declare void @llvm.memmove.p0i8.p0i8.i32(i8 * <dest>, i8 * <src>,
- i32 <len>, i32 <align>, i1 <isvolatile>)
- declare void @llvm.memmove.p0i8.p0i8.i64(i8 * <dest>, i8 * <src>,
- i64 <len>, i32 <align>, i1 <isvolatile>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the
- source location to the destination location. It is similar to the
- '<tt>llvm.memcpy</tt>' intrinsic but allows the two memory locations to
- overlap.</p>
-
-<p>Note that, unlike the standard libc function, the <tt>llvm.memmove.*</tt>
- intrinsics do not return a value, takes extra alignment/isvolatile arguments
- and the pointers can be in specified address spaces.</p>
-
-<h5>Arguments:</h5>
-
-<p>The first argument is a pointer to the destination, the second is a pointer
- to the source. The third argument is an integer argument specifying the
- number of bytes to copy, the fourth argument is the alignment of the
- source and destination locations, and the fifth is a boolean indicating a
- volatile access.</p>
-
-<p>If the call to this intrinsic has an alignment value that is not 0 or 1,
- then the caller guarantees that the source and destination pointers are
- aligned to that boundary.</p>
-
-<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the
- <tt>llvm.memmove</tt> call is a <a href="#volatile">volatile operation</a>.
- The detailed access behavior is not very cleanly specified and it is unwise
- to depend on it.</p>
-
-<h5>Semantics:</h5>
-
-<p>The '<tt>llvm.memmove.*</tt>' intrinsics copy a block of memory from the
- source location to the destination location, which may overlap. It copies
- "len" bytes of memory over. If the argument is known to be aligned to some
- boundary, this can be specified as the fourth argument, otherwise it should
- be set to 0 or 1.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use llvm.memset on any integer bit
- width and for different address spaces. Not all targets support all bit
- widths however.</p>
-
-<pre>
- declare void @llvm.memset.p0i8.i32(i8 * <dest>, i8 <val>,
- i32 <len>, i32 <align>, i1 <isvolatile>)
- declare void @llvm.memset.p0i8.i64(i8 * <dest>, i8 <val>,
- i64 <len>, i32 <align>, i1 <isvolatile>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.memset.*</tt>' intrinsics fill a block of memory with a
- particular byte value.</p>
-
-<p>Note that, unlike the standard libc function, the <tt>llvm.memset</tt>
- intrinsic does not return a value, takes extra alignment/volatile arguments,
- and the destination can be in an arbitrary address space.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is a pointer to the destination to fill, the second is the
- byte value to fill it with, the third argument is an integer argument
- specifying the number of bytes to fill, and the fourth argument is the known
- alignment of destination location.</p>
-
-<p>If the call to this intrinsic has an alignment value that is not 0 or 1,
- then the caller guarantees that the destination pointer is aligned to that
- boundary.</p>
-
-<p>If the <tt>isvolatile</tt> parameter is <tt>true</tt>, the
- <tt>llvm.memset</tt> call is a <a href="#volatile">volatile operation</a>.
- The detailed access behavior is not very cleanly specified and it is unwise
- to depend on it.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.memset.*</tt>' intrinsics fill "len" bytes of memory starting
- at the destination location. If the argument is known to be aligned to some
- boundary, this can be specified as the fourth argument, otherwise it should
- be set to 0 or 1.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.sqrt</tt> on any
- floating point or vector of floating point type. Not all targets support all
- types however.</p>
-
-<pre>
- declare float @llvm.sqrt.f32(float %Val)
- declare double @llvm.sqrt.f64(double %Val)
- declare x86_fp80 @llvm.sqrt.f80(x86_fp80 %Val)
- declare fp128 @llvm.sqrt.f128(fp128 %Val)
- declare ppc_fp128 @llvm.sqrt.ppcf128(ppc_fp128 %Val)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.sqrt</tt>' intrinsics return the sqrt of the specified operand,
- returning the same value as the libm '<tt>sqrt</tt>' functions would.
- Unlike <tt>sqrt</tt> in libm, however, <tt>llvm.sqrt</tt> has undefined
- behavior for negative numbers other than -0.0 (which allows for better
- optimization, because there is no need to worry about errno being
- set). <tt>llvm.sqrt(-0.0)</tt> is defined to return -0.0 like IEEE sqrt.</p>
-
-<h5>Arguments:</h5>
-<p>The argument and return value are floating point numbers of the same
- type.</p>
-
-<h5>Semantics:</h5>
-<p>This function returns the sqrt of the specified operand if it is a
- nonnegative floating point number.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.powi</tt> on any
- floating point or vector of floating point type. Not all targets support all
- types however.</p>
-
-<pre>
- declare float @llvm.powi.f32(float %Val, i32 %power)
- declare double @llvm.powi.f64(double %Val, i32 %power)
- declare x86_fp80 @llvm.powi.f80(x86_fp80 %Val, i32 %power)
- declare fp128 @llvm.powi.f128(fp128 %Val, i32 %power)
- declare ppc_fp128 @llvm.powi.ppcf128(ppc_fp128 %Val, i32 %power)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.powi.*</tt>' intrinsics return the first operand raised to the
- specified (positive or negative) power. The order of evaluation of
- multiplications is not defined. When a vector of floating point type is
- used, the second argument remains a scalar integer value.</p>
-
-<h5>Arguments:</h5>
-<p>The second argument is an integer power, and the first is a value to raise to
- that power.</p>
-
-<h5>Semantics:</h5>
-<p>This function returns the first value raised to the second power with an
- unspecified sequence of rounding operations.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.sin</tt> on any
- floating point or vector of floating point type. Not all targets support all
- types however.</p>
-
-<pre>
- declare float @llvm.sin.f32(float %Val)
- declare double @llvm.sin.f64(double %Val)
- declare x86_fp80 @llvm.sin.f80(x86_fp80 %Val)
- declare fp128 @llvm.sin.f128(fp128 %Val)
- declare ppc_fp128 @llvm.sin.ppcf128(ppc_fp128 %Val)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.sin.*</tt>' intrinsics return the sine of the operand.</p>
-
-<h5>Arguments:</h5>
-<p>The argument and return value are floating point numbers of the same
- type.</p>
-
-<h5>Semantics:</h5>
-<p>This function returns the sine of the specified operand, returning the same
- values as the libm <tt>sin</tt> functions would, and handles error conditions
- in the same way.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.cos</tt> on any
- floating point or vector of floating point type. Not all targets support all
- types however.</p>
-
-<pre>
- declare float @llvm.cos.f32(float %Val)
- declare double @llvm.cos.f64(double %Val)
- declare x86_fp80 @llvm.cos.f80(x86_fp80 %Val)
- declare fp128 @llvm.cos.f128(fp128 %Val)
- declare ppc_fp128 @llvm.cos.ppcf128(ppc_fp128 %Val)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.cos.*</tt>' intrinsics return the cosine of the operand.</p>
-
-<h5>Arguments:</h5>
-<p>The argument and return value are floating point numbers of the same
- type.</p>
-
-<h5>Semantics:</h5>
-<p>This function returns the cosine of the specified operand, returning the same
- values as the libm <tt>cos</tt> functions would, and handles error conditions
- in the same way.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.pow</tt> on any
- floating point or vector of floating point type. Not all targets support all
- types however.</p>
-
-<pre>
- declare float @llvm.pow.f32(float %Val, float %Power)
- declare double @llvm.pow.f64(double %Val, double %Power)
- declare x86_fp80 @llvm.pow.f80(x86_fp80 %Val, x86_fp80 %Power)
- declare fp128 @llvm.pow.f128(fp128 %Val, fp128 %Power)
- declare ppc_fp128 @llvm.pow.ppcf128(ppc_fp128 %Val, ppc_fp128 Power)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.pow.*</tt>' intrinsics return the first operand raised to the
- specified (positive or negative) power.</p>
-
-<h5>Arguments:</h5>
-<p>The second argument is a floating point power, and the first is a value to
- raise to that power.</p>
-
-<h5>Semantics:</h5>
-<p>This function returns the first value raised to the second power, returning
- the same values as the libm <tt>pow</tt> functions would, and handles error
- conditions in the same way.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_manip">Bit Manipulation Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM provides intrinsics for a few important bit manipulation operations.
- These allow efficient code generation for some algorithms.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic function. You can use bswap on any integer
- type that is an even number of bytes (i.e. BitWidth % 16 == 0).</p>
-
-<pre>
- declare i16 @llvm.bswap.i16(i16 <id>)
- declare i32 @llvm.bswap.i32(i32 <id>)
- declare i64 @llvm.bswap.i64(i64 <id>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.bswap</tt>' family of intrinsics is used to byte swap integer
- values with an even number of bytes (positive multiple of 16 bits). These
- are useful for performing operations on data that is not in the target's
- native byte order.</p>
-
-<h5>Semantics:</h5>
-<p>The <tt>llvm.bswap.i16</tt> intrinsic returns an i16 value that has the high
- and low byte of the input i16 swapped. Similarly,
- the <tt>llvm.bswap.i32</tt> intrinsic returns an i32 value that has the four
- bytes of the input i32 swapped, so that if the input bytes are numbered 0, 1,
- 2, 3 then the returned i32 will have its bytes in 3, 2, 1, 0 order.
- The <tt>llvm.bswap.i48</tt>, <tt>llvm.bswap.i64</tt> and other intrinsics
- extend this concept to additional even-byte lengths (6 bytes, 8 bytes and
- more, respectively).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit
- width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.ctpop.i8(i8 <src>)
- declare i16 @llvm.ctpop.i16(i16 <src>)
- declare i32 @llvm.ctpop.i32(i32 <src>)
- declare i64 @llvm.ctpop.i64(i64 <src>)
- declare i256 @llvm.ctpop.i256(i256 <src>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.ctpop</tt>' family of intrinsics counts the number of bits set
- in a value.</p>
-
-<h5>Arguments:</h5>
-<p>The only argument is the value to be counted. The argument may be of any
- integer type. The return type must match the argument type.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.ctpop</tt>' intrinsic counts the 1's in a variable.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.ctlz</tt> on any
- integer bit width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.ctlz.i8 (i8 <src>)
- declare i16 @llvm.ctlz.i16(i16 <src>)
- declare i32 @llvm.ctlz.i32(i32 <src>)
- declare i64 @llvm.ctlz.i64(i64 <src>)
- declare i256 @llvm.ctlz.i256(i256 <src>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.ctlz</tt>' family of intrinsic functions counts the number of
- leading zeros in a variable.</p>
-
-<h5>Arguments:</h5>
-<p>The only argument is the value to be counted. The argument may be of any
- integer type. The return type must match the argument type.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant)
- zeros in a variable. If the src == 0 then the result is the size in bits of
- the type of src. For example, <tt>llvm.ctlz(i32 2) = 30</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.cttz</tt> on any
- integer bit width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.cttz.i8 (i8 <src>)
- declare i16 @llvm.cttz.i16(i16 <src>)
- declare i32 @llvm.cttz.i32(i32 <src>)
- declare i64 @llvm.cttz.i64(i64 <src>)
- declare i256 @llvm.cttz.i256(i256 <src>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.cttz</tt>' family of intrinsic functions counts the number of
- trailing zeros.</p>
-
-<h5>Arguments:</h5>
-<p>The only argument is the value to be counted. The argument may be of any
- integer type. The return type must match the argument type.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant)
- zeros in a variable. If the src == 0 then the result is the size in bits of
- the type of src. For example, <tt>llvm.cttz(2) = 1</tt>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_overflow">Arithmetic with Overflow Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM provides intrinsics for some arithmetic with overflow operations.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_sadd_overflow">'<tt>llvm.sadd.with.overflow.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.sadd.with.overflow</tt>
- on any integer bit width.</p>
-
-<pre>
- declare {i16, i1} @llvm.sadd.with.overflow.i16(i16 %a, i16 %b)
- declare {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
- declare {i64, i1} @llvm.sadd.with.overflow.i64(i64 %a, i64 %b)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.sadd.with.overflow</tt>' family of intrinsic functions perform
- a signed addition of the two arguments, and indicate whether an overflow
- occurred during the signed summation.</p>
-
-<h5>Arguments:</h5>
-<p>The arguments (%a and %b) and the first element of the result structure may
- be of integer types of any bit width, but they must have the same bit
- width. The second element of the result structure must be of
- type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will
- undergo signed addition.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.sadd.with.overflow</tt>' family of intrinsic functions perform
- a signed addition of the two variables. They return a structure — the
- first element of which is the signed summation, and the second element of
- which is a bit specifying if the signed summation resulted in an
- overflow.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call {i32, i1} @llvm.sadd.with.overflow.i32(i32 %a, i32 %b)
- %sum = extractvalue {i32, i1} %res, 0
- %obit = extractvalue {i32, i1} %res, 1
- br i1 %obit, label %overflow, label %normal
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_uadd_overflow">'<tt>llvm.uadd.with.overflow.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.uadd.with.overflow</tt>
- on any integer bit width.</p>
-
-<pre>
- declare {i16, i1} @llvm.uadd.with.overflow.i16(i16 %a, i16 %b)
- declare {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
- declare {i64, i1} @llvm.uadd.with.overflow.i64(i64 %a, i64 %b)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.uadd.with.overflow</tt>' family of intrinsic functions perform
- an unsigned addition of the two arguments, and indicate whether a carry
- occurred during the unsigned summation.</p>
-
-<h5>Arguments:</h5>
-<p>The arguments (%a and %b) and the first element of the result structure may
- be of integer types of any bit width, but they must have the same bit
- width. The second element of the result structure must be of
- type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will
- undergo unsigned addition.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.uadd.with.overflow</tt>' family of intrinsic functions perform
- an unsigned addition of the two arguments. They return a structure —
- the first element of which is the sum, and the second element of which is a
- bit specifying if the unsigned summation resulted in a carry.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call {i32, i1} @llvm.uadd.with.overflow.i32(i32 %a, i32 %b)
- %sum = extractvalue {i32, i1} %res, 0
- %obit = extractvalue {i32, i1} %res, 1
- br i1 %obit, label %carry, label %normal
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_ssub_overflow">'<tt>llvm.ssub.with.overflow.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.ssub.with.overflow</tt>
- on any integer bit width.</p>
-
-<pre>
- declare {i16, i1} @llvm.ssub.with.overflow.i16(i16 %a, i16 %b)
- declare {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
- declare {i64, i1} @llvm.ssub.with.overflow.i64(i64 %a, i64 %b)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.ssub.with.overflow</tt>' family of intrinsic functions perform
- a signed subtraction of the two arguments, and indicate whether an overflow
- occurred during the signed subtraction.</p>
-
-<h5>Arguments:</h5>
-<p>The arguments (%a and %b) and the first element of the result structure may
- be of integer types of any bit width, but they must have the same bit
- width. The second element of the result structure must be of
- type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will
- undergo signed subtraction.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.ssub.with.overflow</tt>' family of intrinsic functions perform
- a signed subtraction of the two arguments. They return a structure —
- the first element of which is the subtraction, and the second element of
- which is a bit specifying if the signed subtraction resulted in an
- overflow.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call {i32, i1} @llvm.ssub.with.overflow.i32(i32 %a, i32 %b)
- %sum = extractvalue {i32, i1} %res, 0
- %obit = extractvalue {i32, i1} %res, 1
- br i1 %obit, label %overflow, label %normal
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_usub_overflow">'<tt>llvm.usub.with.overflow.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.usub.with.overflow</tt>
- on any integer bit width.</p>
-
-<pre>
- declare {i16, i1} @llvm.usub.with.overflow.i16(i16 %a, i16 %b)
- declare {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
- declare {i64, i1} @llvm.usub.with.overflow.i64(i64 %a, i64 %b)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.usub.with.overflow</tt>' family of intrinsic functions perform
- an unsigned subtraction of the two arguments, and indicate whether an
- overflow occurred during the unsigned subtraction.</p>
-
-<h5>Arguments:</h5>
-<p>The arguments (%a and %b) and the first element of the result structure may
- be of integer types of any bit width, but they must have the same bit
- width. The second element of the result structure must be of
- type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will
- undergo unsigned subtraction.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.usub.with.overflow</tt>' family of intrinsic functions perform
- an unsigned subtraction of the two arguments. They return a structure —
- the first element of which is the subtraction, and the second element of
- which is a bit specifying if the unsigned subtraction resulted in an
- overflow.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call {i32, i1} @llvm.usub.with.overflow.i32(i32 %a, i32 %b)
- %sum = extractvalue {i32, i1} %res, 0
- %obit = extractvalue {i32, i1} %res, 1
- br i1 %obit, label %overflow, label %normal
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_smul_overflow">'<tt>llvm.smul.with.overflow.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.smul.with.overflow</tt>
- on any integer bit width.</p>
-
-<pre>
- declare {i16, i1} @llvm.smul.with.overflow.i16(i16 %a, i16 %b)
- declare {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
- declare {i64, i1} @llvm.smul.with.overflow.i64(i64 %a, i64 %b)
-</pre>
-
-<h5>Overview:</h5>
-
-<p>The '<tt>llvm.smul.with.overflow</tt>' family of intrinsic functions perform
- a signed multiplication of the two arguments, and indicate whether an
- overflow occurred during the signed multiplication.</p>
-
-<h5>Arguments:</h5>
-<p>The arguments (%a and %b) and the first element of the result structure may
- be of integer types of any bit width, but they must have the same bit
- width. The second element of the result structure must be of
- type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will
- undergo signed multiplication.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.smul.with.overflow</tt>' family of intrinsic functions perform
- a signed multiplication of the two arguments. They return a structure —
- the first element of which is the multiplication, and the second element of
- which is a bit specifying if the signed multiplication resulted in an
- overflow.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call {i32, i1} @llvm.smul.with.overflow.i32(i32 %a, i32 %b)
- %sum = extractvalue {i32, i1} %res, 0
- %obit = extractvalue {i32, i1} %res, 1
- br i1 %obit, label %overflow, label %normal
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_umul_overflow">'<tt>llvm.umul.with.overflow.*</tt>' Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.umul.with.overflow</tt>
- on any integer bit width.</p>
-
-<pre>
- declare {i16, i1} @llvm.umul.with.overflow.i16(i16 %a, i16 %b)
- declare {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
- declare {i64, i1} @llvm.umul.with.overflow.i64(i64 %a, i64 %b)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform
- a unsigned multiplication of the two arguments, and indicate whether an
- overflow occurred during the unsigned multiplication.</p>
-
-<h5>Arguments:</h5>
-<p>The arguments (%a and %b) and the first element of the result structure may
- be of integer types of any bit width, but they must have the same bit
- width. The second element of the result structure must be of
- type <tt>i1</tt>. <tt>%a</tt> and <tt>%b</tt> are the two values that will
- undergo unsigned multiplication.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.umul.with.overflow</tt>' family of intrinsic functions perform
- an unsigned multiplication of the two arguments. They return a structure
- — the first element of which is the multiplication, and the second
- element of which is a bit specifying if the unsigned multiplication resulted
- in an overflow.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call {i32, i1} @llvm.umul.with.overflow.i32(i32 %a, i32 %b)
- %sum = extractvalue {i32, i1} %res, 0
- %obit = extractvalue {i32, i1} %res, 1
- br i1 %obit, label %overflow, label %normal
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_fp16">Half Precision Floating Point Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>Half precision floating point is a storage-only format. This means that it is
- a dense encoding (in memory) but does not support computation in the
- format.</p>
-
-<p>This means that code must first load the half-precision floating point
- value as an i16, then convert it to float with <a
- href="#int_convert_from_fp16"><tt>llvm.convert.from.fp16</tt></a>.
- Computation can then be performed on the float value (including extending to
- double etc). To store the value back to memory, it is first converted to
- float if needed, then converted to i16 with
- <a href="#int_convert_to_fp16"><tt>llvm.convert.to.fp16</tt></a>, then
- storing as an i16 value.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_convert_to_fp16">'<tt>llvm.convert.to.fp16</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i16 @llvm.convert.to.fp16(f32 %a)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.convert.to.fp16</tt>' intrinsic function performs
- a conversion from single precision floating point format to half precision
- floating point format.</p>
-
-<h5>Arguments:</h5>
-<p>The intrinsic function contains single argument - the value to be
- converted.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.convert.to.fp16</tt>' intrinsic function performs
- a conversion from single precision floating point format to half precision
- floating point format. The return value is an <tt>i16</tt> which
- contains the converted number.</p>
-
-<h5>Examples:</h5>
-<pre>
- %res = call i16 @llvm.convert.to.fp16(f32 %a)
- store i16 %res, i16* @x, align 2
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_convert_from_fp16">'<tt>llvm.convert.from.fp16</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare f32 @llvm.convert.from.fp16(i16 %a)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.convert.from.fp16</tt>' intrinsic function performs
- a conversion from half precision floating point format to single precision
- floating point format.</p>
-
-<h5>Arguments:</h5>
-<p>The intrinsic function contains single argument - the value to be
- converted.</p>
-
-<h5>Semantics:</h5>
-<p>The '<tt>llvm.convert.from.fp16</tt>' intrinsic function performs a
- conversion from half single precision floating point format to single
- precision floating point format. The input half-float value is represented by
- an <tt>i16</tt> value.</p>
-
-<h5>Examples:</h5>
-<pre>
- %a = load i16* @x, align 2
- %res = call f32 @llvm.convert.from.fp16(i16 %a)
-</pre>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_debugger">Debugger Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt>
- prefix), are described in
- the <a href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source
- Level Debugging</a> document.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_eh">Exception Handling Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>The LLVM exception handling intrinsics (which all start with
- <tt>llvm.eh.</tt> prefix), are described in
- the <a href="ExceptionHandling.html#format_common_intrinsics">LLVM Exception
- Handling</a> document.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_trampoline">Trampoline Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<p>This intrinsic makes it possible to excise one parameter, marked with
- the <tt>nest</tt> attribute, from a function. The result is a callable
- function pointer lacking the nest parameter - the caller does not need to
- provide a value for it. Instead, the value to use is stored in advance in a
- "trampoline", a block of memory usually allocated on the stack, which also
- contains code to splice the nest value into the argument list. This is used
- to implement the GCC nested function address extension.</p>
-
-<p>For example, if the function is
- <tt>i32 f(i8* nest %c, i32 %x, i32 %y)</tt> then the resulting function
- pointer has signature <tt>i32 (i32, i32)*</tt>. It can be created as
- follows:</p>
-
-<div class="doc_code">
-<pre>
- %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
- %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
- %p = call i8* @llvm.init.trampoline( i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval )
- %fp = bitcast i8* %p to i32 (i32, i32)*
-</pre>
-</div>
-
-<p>The call <tt>%val = call i32 %fp( i32 %x, i32 %y )</tt> is then equivalent
- to <tt>%val = call i32 %f( i8* %nval, i32 %x, i32 %y )</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)
-</pre>
-
-<h5>Overview:</h5>
-<p>This fills the memory pointed to by <tt>tramp</tt> with code and returns a
- function pointer suitable for executing it.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.init.trampoline</tt> intrinsic takes three arguments, all
- pointers. The <tt>tramp</tt> argument must point to a sufficiently large and
- sufficiently aligned block of memory; this memory is written to by the
- intrinsic. Note that the size and the alignment are target-specific - LLVM
- currently provides no portable way of determining them, so a front-end that
- generates this intrinsic needs to have some target-specific knowledge.
- The <tt>func</tt> argument must hold a function bitcast to
- an <tt>i8*</tt>.</p>
-
-<h5>Semantics:</h5>
-<p>The block of memory pointed to by <tt>tramp</tt> is filled with target
- dependent code, turning it into a function. A pointer to this function is
- returned, but needs to be bitcast to an <a href="#int_trampoline">appropriate
- function pointer type</a> before being called. The new function's signature
- is the same as that of <tt>func</tt> with any arguments marked with
- the <tt>nest</tt> attribute removed. At most one such <tt>nest</tt> argument
- is allowed, and it must be of pointer type. Calling the new function is
- equivalent to calling <tt>func</tt> with the same argument list, but
- with <tt>nval</tt> used for the missing <tt>nest</tt> argument. If, after
- calling <tt>llvm.init.trampoline</tt>, the memory pointed to
- by <tt>tramp</tt> is modified, then the effect of any later call to the
- returned function pointer is undefined.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_atomics">Atomic Operations and Synchronization Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>These intrinsic functions expand the "universal IR" of LLVM to represent
- hardware constructs for atomic operations and memory synchronization. This
- provides an interface to the hardware, not an interface to the programmer. It
- is aimed at a low enough level to allow any programming models or APIs
- (Application Programming Interfaces) which need atomic behaviors to map
- cleanly onto it. It is also modeled primarily on hardware behavior. Just as
- hardware provides a "universal IR" for source languages, it also provides a
- starting point for developing a "universal" atomic operation and
- synchronization IR.</p>
-
-<p>These do <em>not</em> form an API such as high-level threading libraries,
- software transaction memory systems, atomic primitives, and intrinsic
- functions as found in BSD, GNU libc, atomic_ops, APR, and other system and
- application libraries. The hardware interface provided by LLVM should allow
- a clean implementation of all of these APIs and parallel programming models.
- No one model or paradigm should be selected above others unless the hardware
- itself ubiquitously does so.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_memory_barrier">'<tt>llvm.memory.barrier</tt>' Intrinsic</a>
-</div>
-<div class="doc_text">
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device> )
-</pre>
-
-<h5>Overview:</h5>
-<p>The <tt>llvm.memory.barrier</tt> intrinsic guarantees ordering between
- specific pairs of memory access types.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.memory.barrier</tt> intrinsic requires five boolean arguments.
- The first four arguments enables a specific barrier as listed below. The
- fifth argument specifies that the barrier applies to io or device or uncached
- memory.</p>
-
-<ul>
- <li><tt>ll</tt>: load-load barrier</li>
- <li><tt>ls</tt>: load-store barrier</li>
- <li><tt>sl</tt>: store-load barrier</li>
- <li><tt>ss</tt>: store-store barrier</li>
- <li><tt>device</tt>: barrier applies to device and uncached memory also.</li>
-</ul>
-
-<h5>Semantics:</h5>
-<p>This intrinsic causes the system to enforce some ordering constraints upon
- the loads and stores of the program. This barrier does not
- indicate <em>when</em> any events will occur, it only enforces
- an <em>order</em> in which they occur. For any of the specified pairs of load
- and store operations (f.ex. load-load, or store-load), all of the first
- operations preceding the barrier will complete before any of the second
- operations succeeding the barrier begin. Specifically the semantics for each
- pairing is as follows:</p>
-
-<ul>
- <li><tt>ll</tt>: All loads before the barrier must complete before any load
- after the barrier begins.</li>
- <li><tt>ls</tt>: All loads before the barrier must complete before any
- store after the barrier begins.</li>
- <li><tt>ss</tt>: All stores before the barrier must complete before any
- store after the barrier begins.</li>
- <li><tt>sl</tt>: All stores before the barrier must complete before any
- load after the barrier begins.</li>
-</ul>
-
-<p>These semantics are applied with a logical "and" behavior when more than one
- is enabled in a single memory barrier intrinsic.</p>
-
-<p>Backends may implement stronger barriers than those requested when they do
- not support as fine grained a barrier as requested. Some architectures do
- not need all types of barriers and on such architectures, these become
- noops.</p>
-
-<h5>Example:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%result1 = load i32* %ptr <i>; yields {i32}:result1 = 4</i>
- call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
- <i>; guarantee the above finishes</i>
- store i32 8, %ptr <i>; before this begins</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_atomic_cmp_swap">'<tt>llvm.atomic.cmp.swap.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.cmp.swap</tt> on
- any integer bit width and for different address spaces. Not all targets
- support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> )
- declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> )
- declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> )
- declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> )
-</pre>
-
-<h5>Overview:</h5>
-<p>This loads a value in memory and compares it to a given value. If they are
- equal, it stores a new value into the memory.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.atomic.cmp.swap</tt> intrinsic takes three arguments. The result
- as well as both <tt>cmp</tt> and <tt>val</tt> must be integer values with the
- same bit width. The <tt>ptr</tt> argument must be a pointer to a value of
- this integer type. While any bit width integer may be used, targets may only
- lower representations they support in hardware.</p>
-
-<h5>Semantics:</h5>
-<p>This entire intrinsic must be executed atomically. It first loads the value
- in memory pointed to by <tt>ptr</tt> and compares it with the
- value <tt>cmp</tt>. If they are equal, <tt>val</tt> is stored into the
- memory. The loaded value is yielded in all cases. This provides the
- equivalent of an atomic compare-and-swap operation within the SSA
- framework.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 4, %val1 )
- <i>; yields {i32}:result1 = 4</i>
-%stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
-
-%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 5, %val2 )
- <i>; yields {i32}:result2 = 8</i>
-%stored2 = icmp eq i32 %result2, 5 <i>; yields {i1}:stored2 = false</i>
-
-%memval2 = load i32* %ptr <i>; yields {i32}:memval2 = 8</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_atomic_swap">'<tt>llvm.atomic.swap.*</tt>' Intrinsic</a>
-</div>
-<div class="doc_text">
-<h5>Syntax:</h5>
-
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.swap</tt> on any
- integer bit width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> )
- declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> )
- declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> )
- declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> )
-</pre>
-
-<h5>Overview:</h5>
-<p>This intrinsic loads the value stored in memory at <tt>ptr</tt> and yields
- the value from memory. It then stores the value in <tt>val</tt> in the memory
- at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.atomic.swap</tt> intrinsic takes two arguments. Both
- the <tt>val</tt> argument and the result must be integers of the same bit
- width. The first argument, <tt>ptr</tt>, must be a pointer to a value of this
- integer type. The targets may only lower integer representations they
- support.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic loads the value pointed to by <tt>ptr</tt>, yields it, and
- stores <tt>val</tt> back into <tt>ptr</tt> atomically. This provides the
- equivalent of an atomic swap operation within the SSA framework.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-
-%val1 = add i32 4, 4
-%result1 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val1 )
- <i>; yields {i32}:result1 = 4</i>
-%stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
-
-%val2 = add i32 1, 1
-%result2 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val2 )
- <i>; yields {i32}:result2 = 8</i>
-
-%stored2 = icmp eq i32 %result2, 8 <i>; yields {i1}:stored2 = true</i>
-%memval2 = load i32* %ptr <i>; yields {i32}:memval2 = 2</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_atomic_load_add">'<tt>llvm.atomic.load.add.*</tt>' Intrinsic</a>
-
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.add</tt> on
- any integer bit width. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.add.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.add.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.add.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.add.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<h5>Overview:</h5>
-<p>This intrinsic adds <tt>delta</tt> to the value stored in memory
- at <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The intrinsic takes two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic does a series of operations atomically. It first loads the
- value stored at <tt>ptr</tt>. It then adds <tt>delta</tt>, stores the result
- to <tt>ptr</tt>. It yields the original value stored at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 4, %ptr
-%result1 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 )
- <i>; yields {i32}:result1 = 4</i>
-%result2 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 )
- <i>; yields {i32}:result2 = 8</i>
-%result3 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 5 )
- <i>; yields {i32}:result3 = 10</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 15</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_atomic_load_sub">'<tt>llvm.atomic.load.sub.*</tt>' Intrinsic</a>
-
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.sub</tt> on
- any integer bit width and for different address spaces. Not all targets
- support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> )
-</pre>
-
-<h5>Overview:</h5>
-<p>This intrinsic subtracts <tt>delta</tt> to the value stored in memory at
- <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>The intrinsic takes two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic does a series of operations atomically. It first loads the
- value stored at <tt>ptr</tt>. It then subtracts <tt>delta</tt>, stores the
- result to <tt>ptr</tt>. It yields the original value stored
- at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 8, %ptr
-%result1 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 )
- <i>; yields {i32}:result1 = 8</i>
-%result2 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 )
- <i>; yields {i32}:result2 = 4</i>
-%result3 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 5 )
- <i>; yields {i32}:result3 = 2</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = -3</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_atomic_load_and">'<tt>llvm.atomic.load.and.*</tt>' Intrinsic</a><br>
- <a name="int_atomic_load_nand">'<tt>llvm.atomic.load.nand.*</tt>' Intrinsic</a><br>
- <a name="int_atomic_load_or">'<tt>llvm.atomic.load.or.*</tt>' Intrinsic</a><br>
- <a name="int_atomic_load_xor">'<tt>llvm.atomic.load.xor.*</tt>' Intrinsic</a><br>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>These are overloaded intrinsics. You can
- use <tt>llvm.atomic.load_and</tt>, <tt>llvm.atomic.load_nand</tt>,
- <tt>llvm.atomic.load_or</tt>, and <tt>llvm.atomic.load_xor</tt> on any integer
- bit width and for different address spaces. Not all targets support all bit
- widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.or.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.or.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.or.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.or.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.nand.i8.p0i32( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.nand.i16.p0i32( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.nand.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.nand.i64.p0i32( i64* <ptr>, i64 <delta> )
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.xor.i8.p0i32( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.xor.i16.p0i32( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.xor.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.xor.i64.p0i32( i64* <ptr>, i64 <delta> )
-</pre>
-
-<h5>Overview:</h5>
-<p>These intrinsics bitwise the operation (and, nand, or, xor) <tt>delta</tt> to
- the value stored in memory at <tt>ptr</tt>. It yields the original value
- at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>These intrinsics take two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>These intrinsics does a series of operations atomically. They first load the
- value stored at <tt>ptr</tt>. They then do the bitwise
- operation <tt>delta</tt>, store the result to <tt>ptr</tt>. They yield the
- original value stored at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 0x0F0F, %ptr
-%result0 = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF )
- <i>; yields {i32}:result0 = 0x0F0F</i>
-%result1 = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF )
- <i>; yields {i32}:result1 = 0xFFFFFFF0</i>
-%result2 = call i32 @llvm.atomic.load.or.i32.p0i32( i32* %ptr, i32 0F )
- <i>; yields {i32}:result2 = 0xF0</i>
-%result3 = call i32 @llvm.atomic.load.xor.i32.p0i32( i32* %ptr, i32 0F )
- <i>; yields {i32}:result3 = FF</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = F0</i>
-</pre>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_atomic_load_max">'<tt>llvm.atomic.load.max.*</tt>' Intrinsic</a><br>
- <a name="int_atomic_load_min">'<tt>llvm.atomic.load.min.*</tt>' Intrinsic</a><br>
- <a name="int_atomic_load_umax">'<tt>llvm.atomic.load.umax.*</tt>' Intrinsic</a><br>
- <a name="int_atomic_load_umin">'<tt>llvm.atomic.load.umin.*</tt>' Intrinsic</a><br>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>These are overloaded intrinsics. You can use <tt>llvm.atomic.load_max</tt>,
- <tt>llvm.atomic.load_min</tt>, <tt>llvm.atomic.load_umax</tt>, and
- <tt>llvm.atomic.load_umin</tt> on any integer bit width and for different
- address spaces. Not all targets support all bit widths however.</p>
-
-<pre>
- declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.min.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.min.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<pre>
- declare i8 @llvm.atomic.load.umin.i8.p0i8( i8* <ptr>, i8 <delta> )
- declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* <ptr>, i16 <delta> )
- declare i32 @llvm.atomic.load.umin.i32.p0i32( i32* <ptr>, i32 <delta> )
- declare i64 @llvm.atomic.load.umin.i64.p0i64( i64* <ptr>, i64 <delta> )
-</pre>
-
-<h5>Overview:</h5>
-<p>These intrinsics takes the signed or unsigned minimum or maximum of
- <tt>delta</tt> and the value stored in memory at <tt>ptr</tt>. It yields the
- original value at <tt>ptr</tt>.</p>
-
-<h5>Arguments:</h5>
-<p>These intrinsics take two arguments, the first a pointer to an integer value
- and the second an integer value. The result is also an integer value. These
- integer types can have any bit width, but they must all have the same bit
- width. The targets may only lower integer representations they support.</p>
-
-<h5>Semantics:</h5>
-<p>These intrinsics does a series of operations atomically. They first load the
- value stored at <tt>ptr</tt>. They then do the signed or unsigned min or
- max <tt>delta</tt> and the value, store the result to <tt>ptr</tt>. They
- yield the original value stored at <tt>ptr</tt>.</p>
-
-<h5>Examples:</h5>
-<pre>
-%mallocP = tail call i8* @malloc(i32 ptrtoint (i32* getelementptr (i32* null, i32 1) to i32))
-%ptr = bitcast i8* %mallocP to i32*
- store i32 7, %ptr
-%result0 = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 )
- <i>; yields {i32}:result0 = 7</i>
-%result1 = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 )
- <i>; yields {i32}:result1 = -2</i>
-%result2 = call i32 @llvm.atomic.load.umin.i32.p0i32( i32* %ptr, i32 10 )
- <i>; yields {i32}:result2 = 8</i>
-%result3 = call i32 @llvm.atomic.load.umax.i32.p0i32( i32* %ptr, i32 30 )
- <i>; yields {i32}:result3 = 8</i>
-%memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 30</i>
-</pre>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_memorymarkers">Memory Use Markers</a>
-</div>
-
-<div class="doc_text">
-
-<p>This class of intrinsics exists to information about the lifetime of memory
- objects and ranges where variables are immutable.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_lifetime_start">'<tt>llvm.lifetime.start</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.lifetime.start(i64 <size>, i8* nocapture <ptr>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.lifetime.start</tt>' intrinsic specifies the start of a memory
- object's lifetime.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is a constant integer representing the size of the
- object, or -1 if it is variable sized. The second argument is a pointer to
- the object.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic indicates that before this point in the code, the value of the
- memory pointed to by <tt>ptr</tt> is dead. This means that it is known to
- never be used and has an undefined value. A load from the pointer that
- precedes this intrinsic can be replaced with
- <tt>'<a href="#undefvalues">undef</a>'</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_lifetime_end">'<tt>llvm.lifetime.end</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.lifetime.end(i64 <size>, i8* nocapture <ptr>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.lifetime.end</tt>' intrinsic specifies the end of a memory
- object's lifetime.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is a constant integer representing the size of the
- object, or -1 if it is variable sized. The second argument is a pointer to
- the object.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic indicates that after this point in the code, the value of the
- memory pointed to by <tt>ptr</tt> is dead. This means that it is known to
- never be used and has an undefined value. Any stores into the memory object
- following this intrinsic may be removed as dead.
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_invariant_start">'<tt>llvm.invariant.start</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare {}* @llvm.invariant.start(i64 <size>, i8* nocapture <ptr>) readonly
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.invariant.start</tt>' intrinsic specifies that the contents of
- a memory object will not change.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is a constant integer representing the size of the
- object, or -1 if it is variable sized. The second argument is a pointer to
- the object.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic indicates that until an <tt>llvm.invariant.end</tt> that uses
- the return value, the referenced memory location is constant and
- unchanging.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_invariant_end">'<tt>llvm.invariant.end</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.invariant.end({}* <start>, i64 <size>, i8* nocapture <ptr>)
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.invariant.end</tt>' intrinsic specifies that the contents of
- a memory object are mutable.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is the matching <tt>llvm.invariant.start</tt> intrinsic.
- The second argument is a constant integer representing the size of the
- object, or -1 if it is variable sized and the third argument is a pointer
- to the object.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic indicates that the memory is mutable again.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="int_general">General Intrinsics</a>
-</div>
-
-<div class="doc_text">
-
-<p>This class of intrinsics is designed to be generic and has no specific
- purpose.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> )
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.var.annotation</tt>' intrinsic.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is a pointer to a value, the second is a pointer to a
- global string, the third is a pointer to a global string which is the source
- file name, and the last argument is the line number.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic allows annotation of local variables with arbitrary strings.
- This can be useful for special purpose optimizations that want to look for
- these annotations. These have no other defined use, they are ignored by code
- generation and optimization.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_annotation">'<tt>llvm.annotation.*</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<p>This is an overloaded intrinsic. You can use '<tt>llvm.annotation</tt>' on
- any integer bit width.</p>
-
-<pre>
- declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int> )
- declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int> )
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.annotation</tt>' intrinsic.</p>
-
-<h5>Arguments:</h5>
-<p>The first argument is an integer value (result of some expression), the
- second is a pointer to a global string, the third is a pointer to a global
- string which is the source file name, and the last argument is the line
- number. It returns the value of the first argument.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic allows annotations to be put on arbitrary expressions with
- arbitrary strings. This can be useful for special purpose optimizations that
- want to look for these annotations. These have no other defined use, they
- are ignored by code generation and optimization.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_trap">'<tt>llvm.trap</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.trap()
-</pre>
-
-<h5>Overview:</h5>
-<p>The '<tt>llvm.trap</tt>' intrinsic.</p>
-
-<h5>Arguments:</h5>
-<p>None.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsics is lowered to the target dependent trap instruction. If the
- target does not have a trap instruction, this intrinsic will be lowered to
- the call of the <tt>abort()</tt> function.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_stackprotector">'<tt>llvm.stackprotector</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare void @llvm.stackprotector( i8* <guard>, i8** <slot> )
-</pre>
-
-<h5>Overview:</h5>
-<p>The <tt>llvm.stackprotector</tt> intrinsic takes the <tt>guard</tt> and
- stores it onto the stack at <tt>slot</tt>. The stack slot is adjusted to
- ensure that it is placed on the stack before local variables.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.stackprotector</tt> intrinsic requires two pointer
- arguments. The first argument is the value loaded from the stack
- guard <tt>@__stack_chk_guard</tt>. The second variable is an <tt>alloca</tt>
- that has enough space to hold the value of the guard.</p>
-
-<h5>Semantics:</h5>
-<p>This intrinsic causes the prologue/epilogue inserter to force the position of
- the <tt>AllocaInst</tt> stack slot to be before local variables on the
- stack. This is to ensure that if a local variable on the stack is
- overwritten, it will destroy the value of the guard. When the function exits,
- the guard on the stack is checked against the original guard. If they're
- different, then the program aborts by calling the <tt>__stack_chk_fail()</tt>
- function.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="int_objectsize">'<tt>llvm.objectsize</tt>' Intrinsic</a>
-</div>
-
-<div class="doc_text">
-
-<h5>Syntax:</h5>
-<pre>
- declare i32 @llvm.objectsize.i32( i8* <object>, i1 <type> )
- declare i64 @llvm.objectsize.i64( i8* <object>, i1 <type> )
-</pre>
-
-<h5>Overview:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic is designed to provide information
- to the optimizers to discover at compile time either a) when an
- operation like memcpy will either overflow a buffer that corresponds to
- an object, or b) to determine that a runtime check for overflow isn't
- necessary. An object in this context means an allocation of a
- specific class, structure, array, or other object.</p>
-
-<h5>Arguments:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic takes two arguments. The first
- argument is a pointer to or into the <tt>object</tt>. The second argument
- is a boolean 0 or 1. This argument determines whether you want the
- maximum (0) or minimum (1) bytes remaining. This needs to be a literal 0 or
- 1, variables are not allowed.</p>
-
-<h5>Semantics:</h5>
-<p>The <tt>llvm.objectsize</tt> intrinsic is lowered to either a constant
- representing the size of the object concerned or <tt>i32/i64 -1 or 0</tt>
- (depending on the <tt>type</tt> argument if the size cannot be determined
- at compile time.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/Lexicon.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Lexicon.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/Lexicon.html (original)
+++ llvm/trunk/docs/Lexicon.html (removed)
@@ -1,277 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <title>The LLVM Lexicon</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
- <meta name="author" content="Various">
- <meta name="description"
- content="A glossary of terms used with the LLVM project.">
-</head>
-<body>
-<div class="doc_title">The LLVM Lexicon</div>
-<p class="doc_warning">NOTE: This document is a work in progress!</p>
-<!-- *********************************************************************** -->
-<div class="doc_section">Table Of Contents</div>
-<!-- *********************************************************************** -->
-<div class="doc_text">
- <table>
- <tr><th colspan="8"><b>- <a href="#A">A</a> -</b></th></tr>
- <tr>
- <td><a href="#ADCE">ADCE</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#B">B</a> -</b></th></tr>
- <tr>
- <td><a href="#BURS">BURS</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#C">C</a> -</b></th></tr>
- <tr>
- <td><a href="#CSE">CSE</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#D">D</a> -</b></th></tr>
- <tr>
- <td><a href="#DAG">DAG</a></td>
- <td><a href="#Derived_Pointer">Derived Pointer</a></td>
- <td><a href="#DSA">DSA</a></td>
- <td><a href="#DSE">DSE</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#G">G</a> -</b></th></tr>
- <tr>
- <td><a href="#GC">GC</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#I">I</a> -</b></th></tr>
- <tr>
- <td><a href="#IPA">IPA</a></td>
- <td><a href="#IPO">IPO</a></td>
- <td><a href="#ISel">ISel</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#L">L</a> -</b></th></tr>
- <tr>
- <td><a href="#LCSSA">LCSSA</a></td>
- <td><a href="#LICM">LICM</a></td>
- <td><a href="#Load-VN">Load-VN</a></td>
- <td><a href="#LTO">LTO</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#M">M</a> -</b></th></tr>
- <tr>
- <td><a href="#MC">MC</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#O">O</a> -</b></th></tr>
- <tr>
- <td><a href="#Object_Pointer">Object Pointer</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#P">P</a> -</b></th></tr>
- <tr>
- <td><a href="#PRE">PRE</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#R">R</a> -</b></th></tr>
- <tr>
- <td><a href="#RAUW">RAUW</a></td>
- <td><a href="#Reassociation">Reassociation</a></td>
- <td><a href="#Root">Root</a></td>
- </tr>
- <tr><th colspan="8"><b>- <a href="#S">S</a> -</b></th></tr>
- <tr>
- <td><a href="#Safe_Point">Safe Point</a></td>
- <td><a href="#SCC">SCC</a></td>
- <td><a href="#SCCP">SCCP</a></td>
- <td><a href="#SDISel">SDISel</a></td>
- <td><a href="#SRoA">SRoA</a></td>
- <td><a href="#Stack_Map">Stack Map</a></td>
- </tr>
- </table>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">Definitions</div>
-<!-- *********************************************************************** -->
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="A">- A -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="ADCE"><b>ADCE</b></a></dt>
- <dd>Aggressive Dead Code Elimination</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="B">- B -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="BURS"><b>BURS</b></a></dt>
- <dd>Bottom Up Rewriting System—A method of instruction selection for
- code generation. An example is the <a
-href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="C">- C -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="CSE"><b>CSE</b></a></dt>
- <dd>Common Subexpression Elimination. An optimization that removes common
- subexpression compuation. For example <tt>(a+b)*(a+b)</tt> has two
- subexpressions that are the same: <tt>(a+b)</tt>. This optimization would
- perform the addition only once and then perform the multiply (but only if
- it's compulationally correct/safe).
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="D">- D -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="DAG"><b>DAG</b></a></dt>
- <dd>Directed Acyclic Graph</dd>
- <dt><a name="Derived_Pointer"><b>Derived Pointer</b></a></dt>
- <dd>A pointer to the interior of an object, such that a garbage collector
- is unable to use the pointer for reachability analysis. While a derived
- pointer is live, the corresponding object pointer must be kept in a root,
- otherwise the collector might free the referenced object. With copying
- collectors, derived pointers pose an additional hazard that they may be
- invalidated at any <a href="Safe_Point">safe point</a>. This term is used in
- opposition to <a href="#Object_Pointer">object pointer</a>.</dd>
- <dt><a name="DSA"><b>DSA</b></a></dt>
- <dd>Data Structure Analysis</dd>
- <dt><a name="DSE"><b>DSE</b></a></dt>
- <dd>Dead Store Elimination</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="G">- G -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="GC"><b>GC</b></a></dt>
- <dd>Garbage Collection. The practice of using reachability analysis instead
- of explicit memory management to reclaim unused memory.</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="H">- H -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="Heap"><b>Heap</b></a></dt>
- <dd>In garbage collection, the region of memory which is managed using
- reachability analysis.</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="I">- I -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="IPA"><b>IPA</b></a></dt>
- <dd>Inter-Procedural Analysis. Refers to any variety of code analysis that
- occurs between procedures, functions or compilation units (modules).</dd>
- <dt><a name="IPO"><b>IPO</b></a></dt>
- <dd>Inter-Procedural Optimization. Refers to any variety of code
- optimization that occurs between procedures, functions or compilation units
- (modules).</dd>
- <dt><a name="ISel"><b>ISel</b></a></dt>
- <dd>Instruction Selection.</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="L">- L -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="LCSSA"><b>LCSSA</b></a></dt>
- <dd>Loop-Closed Static Single Assignment Form</dd>
- <dt><a name="LICM"><b>LICM</b></a></dt>
- <dd>Loop Invariant Code Motion</dd>
- <dt><a name="Load-VN"><b>Load-VN</b></a></dt>
- <dd>Load Value Numbering</dd>
- <dt><a name="LTO"><b>LTO</b></a></dt>
- <dd>Link-Time Optimization</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="M">- M -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="MC"><b>MC</b></a></dt>
- <dd>Machine Code</dd>
- </dl>
-</div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="O">- O -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="Object_Pointer"><b>Object Pointer</b></a></dt>
- <dd>A pointer to an object such that the garbage collector is able to trace
- references contained within the object. This term is used in opposition to
- <a href="#Derived_Pointer">derived pointer</a>.</dd>
- </dl>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="P">- P -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="PRE"><b>PRE</b></a></dt>
- <dd>Partial Redundancy Elimination</dd>
- </dl>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="R">- R -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="RAUW"><b>RAUW</b></a></dt> <dd>An abbreviation for Replace
- All Uses With. The functions User::replaceUsesOfWith(),
- Value::replaceAllUsesWith(), and Constant::replaceUsesOfWithOnConstant()
- implement the replacement of one Value with another by iterating over its
- def/use chain and fixing up all of the pointers to point to the new value.
- See also <a href="ProgrammersManual.html#iterate_chains">def/use chains</a>.
- </dd>
- <dt><a name="Reassociation"><b>Reassociation</b></a></dt> <dd>Rearranging
- associative expressions to promote better redundancy elimination and other
- optimization. For example, changing (A+B-A) into (B+A-A), permitting it to
- be optimized into (B+0) then (B).</dd>
- <dt><a name="Root"><b>Root</b></a></dt> <dd>In garbage collection, a
- pointer variable lying outside of the <a href="#Heap">heap</a> from which
- the collector begins its reachability analysis. In the context of code
- generation, "root" almost always refers to a "stack root" -- a local or
- temporary variable within an executing function.</dd>
- </dl>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="S">- S -</a></div>
-<div class="doc_text">
- <dl>
- <dt><a name="Safe_Point"><b>Safe Point</b></a></dt>
- <dd>In garbage collection, it is necessary to identify <a href="#Root">stack
- roots</a> so that reachability analysis may proceed. It may be infeasible to
- provide this information for every instruction, so instead the information
- may is calculated only at designated safe points. With a copying collector,
- <a href="#Derived_Pointers">derived pointers</a> must not be retained across
- safe points and <a href="#Object_Pointers">object pointers</a> must be
- reloaded from stack roots.</dd>
- <dt><a name="SDISel"><b>SDISel</b></a></dt>
- <dd>Selection DAG Instruction Selection.</dd>
- <dt><a name="SCC"><b>SCC</b></a></dt>
- <dd>Strongly Connected Component</dd>
- <dt><a name="SCCP"><b>SCCP</b></a></dt>
- <dd>Sparse Conditional Constant Propagation</dd>
- <dt><a name="SRoA"><b>SRoA</b></a></dt>
- <dd>Scalar Replacement of Aggregates</dd>
- <dt><a name="SSA"><b>SSA</b></a></dt>
- <dd>Static Single Assignment</dd>
- <dt><a name="Stack_Map"><b>Stack Map</b></a></dt>
- <dd>In garbage collection, metadata emitted by the code generator which
- identifies <a href="#Root">roots</a> within the stack frame of an executing
- function.</dd>
- </dl>
-</div>
-<!-- *********************************************************************** -->
-<hr>
-<address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a><a
- href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a><a
- href="http://llvm.org/">The LLVM Team</a><br>
-<a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
-Last modified: $Date$
-</address>
-<!-- vim: sw=2
--->
-</body>
-</html>
Removed: llvm/trunk/docs/LinkTimeOptimization.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LinkTimeOptimization.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/LinkTimeOptimization.html (original)
+++ llvm/trunk/docs/LinkTimeOptimization.html (removed)
@@ -1,390 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>LLVM Link Time Optimization: Design and Implementation</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-
-<div class="doc_title">
- LLVM Link Time Optimization: Design and Implementation
-</div>
-
-<ul>
- <li><a href="#desc">Description</a></li>
- <li><a href="#design">Design Philosophy</a>
- <ul>
- <li><a href="#example1">Example of link time optimization</a></li>
- <li><a href="#alternative_approaches">Alternative Approaches</a></li>
- </ul></li>
- <li><a href="#multiphase">Multi-phase communication between LLVM and linker</a>
- <ul>
- <li><a href="#phase1">Phase 1 : Read LLVM Bytecode Files</a></li>
- <li><a href="#phase2">Phase 2 : Symbol Resolution</a></li>
- <li><a href="#phase3">Phase 3 : Optimize Bitcode Files</a></li>
- <li><a href="#phase4">Phase 4 : Symbol Resolution after optimization</a></li>
- </ul></li>
- <li><a href="#lto">libLTO</a>
- <ul>
- <li><a href="#lto_module_t">lto_module_t</a></li>
- <li><a href="#lto_code_gen_t">lto_code_gen_t</a></li>
- </ul>
-</ul>
-
-<div class="doc_author">
-<p>Written by Devang Patel and Nick Kledzik</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-<a name="desc">Description</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>
-LLVM features powerful intermodular optimizations which can be used at link
-time. Link Time Optimization (LTO) is another name for intermodular optimization
-when performed during the link stage. This document describes the interface
-and design between the LTO optimizer and the linker.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-<a name="design">Design Philosophy</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>
-The LLVM Link Time Optimizer provides complete transparency, while doing
-intermodular optimization, in the compiler tool chain. Its main goal is to let
-the developer take advantage of intermodular optimizations without making any
-significant changes to the developer's makefiles or build system. This is
-achieved through tight integration with the linker. In this model, the linker
-treates LLVM bitcode files like native object files and allows mixing and
-matching among them. The linker uses <a href="#lto">libLTO</a>, a shared
-object, to handle LLVM bitcode files. This tight integration between
-the linker and LLVM optimizer helps to do optimizations that are not possible
-in other models. The linker input allows the optimizer to avoid relying on
-conservative escape analysis.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="example1">Example of link time optimization</a>
-</div>
-
-<div class="doc_text">
- <p>The following example illustrates the advantages of LTO's integrated
- approach and clean interface. This example requires a system linker which
- supports LTO through the interface described in this document. Here,
- llvm-gcc transparently invokes system linker. </p>
- <ul>
- <li> Input source file <tt>a.c</tt> is compiled into LLVM bitcode form.
- <li> Input source file <tt>main.c</tt> is compiled into native object code.
- </ul>
-<pre class="doc_code">
---- a.h ---
-extern int foo1(void);
-extern void foo2(void);
-extern void foo4(void);
---- a.c ---
-#include "a.h"
-
-static signed int i = 0;
-
-void foo2(void) {
- i = -1;
-}
-
-static int foo3() {
-foo4();
-return 10;
-}
-
-int foo1(void) {
-int data = 0;
-
-if (i < 0) { data = foo3(); }
-
-data = data + 42;
-return data;
-}
-
---- main.c ---
-#include <stdio.h>
-#include "a.h"
-
-void foo4(void) {
- printf ("Hi\n");
-}
-
-int main() {
- return foo1();
-}
-
---- command lines ---
-$ llvm-gcc --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bitcode file
-$ llvm-gcc -c main.c -o main.o # <-- main.o is native object file
-$ llvm-gcc a.o main.o -o main # <-- standard link command without any modifications
-</pre>
- <p>In this example, the linker recognizes that <tt>foo2()</tt> is an
- externally visible symbol defined in LLVM bitcode file. The linker completes
- its usual symbol resolution
- pass and finds that <tt>foo2()</tt> is not used anywhere. This information
- is used by the LLVM optimizer and it removes <tt>foo2()</tt>. As soon as
- <tt>foo2()</tt> is removed, the optimizer recognizes that condition
- <tt>i < 0</tt> is always false, which means <tt>foo3()</tt> is never
- used. Hence, the optimizer removes <tt>foo3()</tt>, also. And this in turn,
- enables linker to remove <tt>foo4()</tt>. This example illustrates the
- advantage of tight integration with the linker. Here, the optimizer can not
- remove <tt>foo3()</tt> without the linker's input.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="alternative_approaches">Alternative Approaches</a>
-</div>
-
-<div class="doc_text">
- <dl>
- <dt><b>Compiler driver invokes link time optimizer separately.</b></dt>
- <dd>In this model the link time optimizer is not able to take advantage of
- information collected during the linker's normal symbol resolution phase.
- In the above example, the optimizer can not remove <tt>foo2()</tt> without
- the linker's input because it is externally visible. This in turn prohibits
- the optimizer from removing <tt>foo3()</tt>.</dd>
- <dt><b>Use separate tool to collect symbol information from all object
- files.</b></dt>
- <dd>In this model, a new, separate, tool or library replicates the linker's
- capability to collect information for link time optimization. Not only is
- this code duplication difficult to justify, but it also has several other
- disadvantages. For example, the linking semantics and the features
- provided by the linker on various platform are not unique. This means,
- this new tool needs to support all such features and platforms in one
- super tool or a separate tool per platform is required. This increases
- maintenance cost for link time optimizer significantly, which is not
- necessary. This approach also requires staying synchronized with linker
- developements on various platforms, which is not the main focus of the link
- time optimizer. Finally, this approach increases end user's build time due
- to the duplication of work done by this separate tool and the linker itself.
- </dd>
- </dl>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="multiphase">Multi-phase communication between libLTO and linker</a>
-</div>
-
-<div class="doc_text">
- <p>The linker collects information about symbol defininitions and uses in
- various link objects which is more accurate than any information collected
- by other tools during typical build cycles. The linker collects this
- information by looking at the definitions and uses of symbols in native .o
- files and using symbol visibility information. The linker also uses
- user-supplied information, such as a list of exported symbols. LLVM
- optimizer collects control flow information, data flow information and knows
- much more about program structure from the optimizer's point of view.
- Our goal is to take advantage of tight integration between the linker and
- the optimizer by sharing this information during various linking phases.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="phase1">Phase 1 : Read LLVM Bitcode Files</a>
-</div>
-
-<div class="doc_text">
- <p>The linker first reads all object files in natural order and collects
- symbol information. This includes native object files as well as LLVM bitcode
- files. To minimize the cost to the linker in the case that all .o files
- are native object files, the linker only calls <tt>lto_module_create()</tt>
- when a supplied object file is found to not be a native object file. If
- <tt>lto_module_create()</tt> returns that the file is an LLVM bitcode file,
- the linker
- then iterates over the module using <tt>lto_module_get_symbol_name()</tt> and
- <tt>lto_module_get_symbol_attribute()</tt> to get all symbols defined and
- referenced.
- This information is added to the linker's global symbol table.
-</p>
- <p>The lto* functions are all implemented in a shared object libLTO. This
- allows the LLVM LTO code to be updated independently of the linker tool.
- On platforms that support it, the shared object is lazily loaded.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="phase2">Phase 2 : Symbol Resolution</a>
-</div>
-
-<div class="doc_text">
- <p>In this stage, the linker resolves symbols using global symbol table.
- It may report undefined symbol errors, read archive members, replace
- weak symbols, etc. The linker is able to do this seamlessly even though it
- does not know the exact content of input LLVM bitcode files. If dead code
- stripping is enabled then the linker collects the list of live symbols.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="phase3">Phase 3 : Optimize Bitcode Files</a>
-</div>
-<div class="doc_text">
- <p>After symbol resolution, the linker tells the LTO shared object which
- symbols are needed by native object files. In the example above, the linker
- reports that only <tt>foo1()</tt> is used by native object files using
- <tt>lto_codegen_add_must_preserve_symbol()</tt>. Next the linker invokes
- the LLVM optimizer and code generators using <tt>lto_codegen_compile()</tt>
- which returns a native object file creating by merging the LLVM bitcode files
- and applying various optimization passes.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="phase4">Phase 4 : Symbol Resolution after optimization</a>
-</div>
-
-<div class="doc_text">
- <p>In this phase, the linker reads optimized a native object file and
- updates the internal global symbol table to reflect any changes. The linker
- also collects information about any changes in use of external symbols by
- LLVM bitcode files. In the example above, the linker notes that
- <tt>foo4()</tt> is not used any more. If dead code stripping is enabled then
- the linker refreshes the live symbol information appropriately and performs
- dead code stripping.</p>
- <p>After this phase, the linker continues linking as if it never saw LLVM
- bitcode files.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
-<a name="lto">libLTO</a>
-</div>
-
-<div class="doc_text">
- <p><tt>libLTO</tt> is a shared object that is part of the LLVM tools, and
- is intended for use by a linker. <tt>libLTO</tt> provides an abstract C
- interface to use the LLVM interprocedural optimizer without exposing details
- of LLVM's internals. The intention is to keep the interface as stable as
- possible even when the LLVM optimizer continues to evolve. It should even
- be possible for a completely different compilation technology to provide
- a different libLTO that works with their object files and the standard
- linker tool.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="lto_module_t">lto_module_t</a>
-</div>
-
-<div class="doc_text">
-
-<p>A non-native object file is handled via an <tt>lto_module_t</tt>.
-The following functions allow the linker to check if a file (on disk
-or in a memory buffer) is a file which libLTO can process:</p>
-
-<pre class="doc_code">
-lto_module_is_object_file(const char*)
-lto_module_is_object_file_for_target(const char*, const char*)
-lto_module_is_object_file_in_memory(const void*, size_t)
-lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)
-</pre>
-
-<p>If the object file can be processed by libLTO, the linker creates a
-<tt>lto_module_t</tt> by using one of</p>
-
-<pre class="doc_code">
-lto_module_create(const char*)
-lto_module_create_from_memory(const void*, size_t)
-</pre>
-
-<p>and when done, the handle is released via</p>
-
-<pre class="doc_code">
-lto_module_dispose(lto_module_t)
-</pre>
-
-<p>The linker can introspect the non-native object file by getting the number of
-symbols and getting the name and attributes of each symbol via:</p>
-
-<pre class="doc_code">
-lto_module_get_num_symbols(lto_module_t)
-lto_module_get_symbol_name(lto_module_t, unsigned int)
-lto_module_get_symbol_attribute(lto_module_t, unsigned int)
-</pre>
-
-<p>The attributes of a symbol include the alignment, visibility, and kind.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="lto_code_gen_t">lto_code_gen_t</a>
-</div>
-
-<div class="doc_text">
-
-<p>Once the linker has loaded each non-native object files into an
-<tt>lto_module_t</tt>, it can request libLTO to process them all and
-generate a native object file. This is done in a couple of steps.
-First, a code generator is created with:</p>
-
-<pre class="doc_code">lto_codegen_create()</pre>
-
-<p>Then, each non-native object file is added to the code generator with:</p>
-
-<pre class="doc_code">
-lto_codegen_add_module(lto_code_gen_t, lto_module_t)
-</pre>
-
-<p>The linker then has the option of setting some codegen options. Whether or
-not to generate DWARF debug info is set with:</p>
-
-<pre class="doc_code">lto_codegen_set_debug_model(lto_code_gen_t)</pre>
-
-<p>Which kind of position independence is set with:</p>
-
-<pre class="doc_code">lto_codegen_set_pic_model(lto_code_gen_t) </pre>
-
-<p>And each symbol that is referenced by a native object file or otherwise must
-not be optimized away is set with:</p>
-
-<pre class="doc_code">
-lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
-</pre>
-
-<p>After all these settings are done, the linker requests that a native object
-file be created from the modules with the settings using:</p>
-
-<pre class="doc_code">lto_codegen_compile(lto_code_gen_t, size*)</pre>
-
-<p>which returns a pointer to a buffer containing the generated native
-object file. The linker then parses that and links it with the rest
-of the native object files.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- Devang Patel and Nick Kledzik<br>
- <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
-
Modified: llvm/trunk/docs/Makefile
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Makefile?rev=103213&r1=103212&r2=103213&view=diff
==============================================================================
--- llvm/trunk/docs/Makefile (original)
+++ llvm/trunk/docs/Makefile Thu May 6 18:45:43 2010
@@ -7,117 +7,7 @@
#
##===----------------------------------------------------------------------===##
-LEVEL := ..
-DIRS := CommandGuide tutorial
-
-ifdef BUILD_FOR_WEBSITE
-PROJ_OBJ_DIR = .
-DOXYGEN = doxygen
-
-$(PROJ_OBJ_DIR)/doxygen.cfg: doxygen.cfg.in
- cat $< | sed \
- -e 's/@abs_top_srcdir@/../g' \
- -e 's/@DOT@/dot/g' \
- -e 's/@PACKAGE_VERSION@/mainline/' \
- -e 's/@abs_top_builddir@/../g' > $@
-endif
+LEVEL = ..
+DIRS = main api
include $(LEVEL)/Makefile.common
-
-HTML := $(wildcard $(PROJ_SRC_DIR)/*.html) \
- $(wildcard $(PROJ_SRC_DIR)/*.css)
-IMAGES := $(wildcard $(PROJ_SRC_DIR)/img/*.*)
-DOXYFILES := doxygen.cfg.in doxygen.css doxygen.footer doxygen.header \
- doxygen.intro
-EXTRA_DIST := $(HTML) $(DOXYFILES) llvm.css CommandGuide img
-
-.PHONY: install-html install-doxygen doxygen install-ocamldoc ocamldoc generated
-
-install_targets := install-html
-ifeq ($(ENABLE_DOXYGEN),1)
-install_targets += install-doxygen
-endif
-ifneq (,$(filter ocaml,$(BINDINGS_TO_BUILD)))
-install_targets += install-ocamldoc
-endif
-install-local:: $(install_targets)
-
-# Live documentation is generated for the web site using this target:
-# 'make generated BUILD_FOR_WEBSITE=1'
-generated:: doxygen ocamldoc
-
-install-html: $(PROJ_OBJ_DIR)/html.tar.gz
- $(Echo) Installing HTML documentation
- $(Verb) $(MKDIR) $(DESTDIR)$(PROJ_docsdir)/html
- $(Verb) $(MKDIR) $(DESTDIR)$(PROJ_docsdir)/html/img
- $(Verb) $(DataInstall) $(HTML) $(DESTDIR)$(PROJ_docsdir)/html
- $(Verb) $(DataInstall) $(IMAGES) $(DESTDIR)$(PROJ_docsdir)/html/img
- $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/html.tar.gz $(DESTDIR)$(PROJ_docsdir)
-
-$(PROJ_OBJ_DIR)/html.tar.gz: $(HTML)
- $(Echo) Packaging HTML documentation
- $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/html.tar
- $(Verb) cd $(PROJ_SRC_DIR) && \
- $(TAR) cf $(PROJ_OBJ_DIR)/html.tar *.html
- $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/html.tar
-
-install-doxygen: doxygen
- $(Echo) Installing doxygen documentation
- $(Verb) $(MKDIR) $(DESTDIR)$(PROJ_docsdir)/html/doxygen
- $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(DESTDIR)$(PROJ_docsdir)
- $(Verb) cd $(PROJ_OBJ_DIR)/doxygen && \
- $(FIND) . -type f -exec \
- $(DataInstall) {} $(DESTDIR)$(PROJ_docsdir)/html/doxygen \;
-
-doxygen: regendoc $(PROJ_OBJ_DIR)/doxygen.tar.gz
-
-regendoc:
- $(Echo) Building doxygen documentation
- $(Verb) if test -e $(PROJ_OBJ_DIR)/doxygen ; then \
- $(RM) -rf $(PROJ_OBJ_DIR)/doxygen ; \
- fi
- $(Verb) $(DOXYGEN) $(PROJ_OBJ_DIR)/doxygen.cfg
-
-$(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg
- $(Echo) Packaging doxygen documentation
- $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/doxygen.tar
- $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/doxygen.tar doxygen
- $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/doxygen.tar
- $(Verb) $(CP) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_OBJ_DIR)/doxygen/html/
-
-userloc: $(LLVM_SRC_ROOT)/docs/userloc.html
-
-$(LLVM_SRC_ROOT)/docs/userloc.html:
- $(Echo) Making User LOC Table
- $(Verb) cd $(LLVM_SRC_ROOT) ; ./utils/userloc.pl -details -recurse \
- -html lib include tools runtime utils examples autoconf test > docs/userloc.html
-
-install-ocamldoc: ocamldoc
- $(Echo) Installing ocamldoc documentation
- $(Verb) $(MKDIR) $(DESTDIR)$(PROJ_docsdir)/ocamldoc/html
- $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/ocamldoc.tar.gz $(DESTDIR)$(PROJ_docsdir)
- $(Verb) cd $(PROJ_OBJ_DIR)/ocamldoc && \
- $(FIND) . -type f -exec \
- $(DataInstall) {} $(DESTDIR)$(PROJ_docsdir)/ocamldoc/html \;
-
-ocamldoc: regen-ocamldoc
- $(Echo) Packaging ocamldoc documentation
- $(Verb) $(RM) -rf $(PROJ_OBJ_DIR)/ocamldoc.tar*
- $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/ocamldoc.tar ocamldoc
- $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/ocamldoc.tar
- $(Verb) $(CP) $(PROJ_OBJ_DIR)/ocamldoc.tar.gz $(PROJ_OBJ_DIR)/ocamldoc/html/
-
-regen-ocamldoc:
- $(Echo) Building ocamldoc documentation
- $(Verb) if test -e $(PROJ_OBJ_DIR)/ocamldoc ; then \
- $(RM) -rf $(PROJ_OBJ_DIR)/ocamldoc ; \
- fi
- $(Verb) $(MAKE) -C $(LEVEL)/bindings/ocaml ocamldoc
- $(Verb) $(MKDIR) $(PROJ_OBJ_DIR)/ocamldoc/html
- $(Verb) \
- $(OCAMLDOC) -d $(PROJ_OBJ_DIR)/ocamldoc/html -sort -colorize-code -html \
- `$(FIND) $(LEVEL)/bindings/ocaml -name "*.odoc" -exec echo -load '{}' ';'`
-
-uninstall-local::
- $(Echo) Uninstalling Documentation
- $(Verb) $(RM) -rf $(DESTDIR)$(PROJ_docsdir)
Removed: llvm/trunk/docs/MakefileGuide.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/MakefileGuide.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/MakefileGuide.html (original)
+++ llvm/trunk/docs/MakefileGuide.html (removed)
@@ -1,1031 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <title>LLVM Makefile Guide</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">LLVM Makefile Guide</div>
-
-<ol>
- <li><a href="#introduction">Introduction</a></li>
- <li><a href="#general">General Concepts</a>
- <ol>
- <li><a href="#projects">Projects</a></li>
- <li><a href="#varvals">Variable Values</a></li>
- <li><a href="#including">Including Makefiles</a>
- <ol>
- <li><a href="#Makefile">Makefile</a></li>
- <li><a href="#Makefile.common">Makefile.common</a></li>
- <li><a href="#Makefile.config">Makefile.config</a></li>
- <li><a href="#Makefile.rules">Makefile.rules</a></li>
- </ol>
- </li>
- <li><a href="#Comments">Comments</a></li>
- </ol>
- </li>
- <li><a href="#tutorial">Tutorial</a>
- <ol>
- <li><a href="#libraries">Libraries</a>
- <ol>
- <li><a href="#BCModules">Bitcode Modules</a></li>
- <li><a href="#LoadableModules">Loadable Modules</a></li>
- </ol>
- </li>
- <li><a href="#tools">Tools</a>
- <ol>
- <li><a href="#JIT">JIT Tools</a></li>
- </ol>
- </li>
- <li><a href="#projects">Projects</a></li>
- </ol>
- </li>
- <li><a href="#targets">Targets Supported</a>
- <ol>
- <li><a href="#all">all</a></li>
- <li><a href="#all-local">all-local</a></li>
- <li><a href="#check">check</a></li>
- <li><a href="#check-local">check-local</a></li>
- <li><a href="#clean">clean</a></li>
- <li><a href="#clean-local">clean-local</a></li>
- <li><a href="#dist">dist</a></li>
- <li><a href="#dist-check">dist-check</a></li>
- <li><a href="#dist-clean">dist-clean</a></li>
- <li><a href="#install">install</a></li>
- <li><a href="#preconditions">preconditions</a></li>
- <li><a href="#printvars">printvars</a></li>
- <li><a href="#reconfigure">reconfigure</a></li>
- <li><a href="#spotless">spotless</a></li>
- <li><a href="#tags">tags</a></li>
- <li><a href="#uninstall">uninstall</a></li>
- </ol>
- </li>
- <li><a href="#variables">Using Variables</a>
- <ol>
- <li><a href="#setvars">Control Variables</a></li>
- <li><a href="#overvars">Override Variables</a></li>
- <li><a href="#getvars">Readable Variables</a></li>
- <li><a href="#intvars">Internal Variables</a></li>
- </ol>
- </li>
-</ol>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:reid at x10sys.com">Reid Spencer</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="introduction">Introduction </a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
- <p>This document provides <em>usage</em> information about the LLVM makefile
- system. While loosely patterned after the BSD makefile system, LLVM has taken
- a departure from BSD in order to implement additional features needed by LLVM.
- Although makefile systems such as automake were attempted at one point, it
- has become clear that the features needed by LLVM and the Makefile norm are
- too great to use a more limited tool. Consequently, LLVM requires simply GNU
- Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy
- use of the features of GNU Make so the dependency on GNU Make is firm. If
- you're not familiar with <tt>make</tt>, it is recommended that you read the
- <a href="http://www.gnu.org/software/make/manual/make.html">GNU Makefile
- Manual</a>.</p>
- <p>While this document is rightly part of the
- <a href="ProgrammersManual.html">LLVM Programmer's Manual</a>, it is treated
- separately here because of the volume of content and because it is often an
- early source of bewilderment for new developers.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="general">General Concepts</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
- <p>The LLVM Makefile System is the component of LLVM that is responsible for
- building the software, testing it, generating distributions, checking those
- distributions, installing and uninstalling, etc. It consists of a several
- files throughout the source tree. These files and other general concepts are
- described in this section.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="projects">Projects</a></div>
-<div class="doc_text">
- <p>The LLVM Makefile System is quite generous. It not only builds its own
- software, but it can build yours too. Built into the system is knowledge of
- the <tt>llvm/projects</tt> directory. Any directory under <tt>projects</tt>
- that has both a <tt>configure</tt> script and a <tt>Makefile</tt> is assumed
- to be a project that uses the LLVM Makefile system. Building software that
- uses LLVM does not require the LLVM Makefile System nor even placement in the
- <tt>llvm/projects</tt> directory. However, doing so will allow your project
- to get up and running quickly by utilizing the built-in features that are used
- to compile LLVM. LLVM compiles itself using the same features of the makefile
- system as used for projects.</p>
- <p>For complete details on setting up your projects configuration, simply
- mimic the <tt>llvm/projects/sample</tt> project or for further details,
- consult the <a href="Projects.html">Projects.html</a> page.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="varvalues">Variable Values</a></div>
-<div class="doc_text">
- <p>To use the makefile system, you simply create a file named
- <tt>Makefile</tt> in your directory and declare values for certain variables.
- The variables and values that you select determine what the makefile system
- will do. These variables enable rules and processing in the makefile system
- that automatically Do The Right Thing™.
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="including">Including Makefiles</a></div>
-<div class="doc_text">
- <p>Setting variables alone is not enough. You must include into your Makefile
- additional files that provide the rules of the LLVM Makefile system. The
- various files involved are described in the sections that follow.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="Makefile">Makefile</a></div>
-<div class="doc_text">
- <p>Each directory to participate in the build needs to have a file named
- <tt>Makefile</tt>. This is the file first read by <tt>make</tt>. It has three
- sections:</p>
- <ol>
- <li><a href="#setvars">Settable Variables</a> - Required that must be set
- first.</li>
- <li><a href="#Makefile.common">include <tt>$(LEVEL)/Makefile.common</tt></a>
- - include the LLVM Makefile system.
- <li><a href="#overvars">Override Variables</a> - Override variables set by
- the LLVM Makefile system.
- </ol>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="Makefile.common">Makefile.common</a>
-</div>
-<div class="doc_text">
- <p>Every project must have a <tt>Makefile.common</tt> file at its top source
- directory. This file serves three purposes:</p>
- <ol>
- <li>It includes the project's configuration makefile to obtain values
- determined by the <tt>configure</tt> script. This is done by including the
- <a href="#Makefile.config"><tt>$(LEVEL)/Makefile.config</tt></a> file.</li>
- <li>It specifies any other (static) values that are needed throughout the
- project. Only values that are used in all or a large proportion of the
- project's directories should be placed here.</li>
- <li>It includes the standard rules for the LLVM Makefile system,
- <a href="#Makefile.rules"><tt>$(LLVM_SRC_ROOT)/Makefile.rules</tt></a>.
- This file is the "guts" of the LLVM Makefile system.</li>
- </ol>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="Makefile.config">Makefile.config</a>
-</div>
-<div class="doc_text">
- <p>Every project must have a <tt>Makefile.config</tt> at the top of its
- <em>build</em> directory. This file is <b>generated</b> by the
- <tt>configure</tt> script from the pattern provided by the
- <tt>Makefile.config.in</tt> file located at the top of the project's
- <em>source</em> directory. The contents of this file depend largely on what
- configuration items the project uses, however most projects can get what they
- need by just relying on LLVM's configuration found in
- <tt>$(LLVM_OBJ_ROOT)/Makefile.config</tt>.
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="Makefile.rules">Makefile.rules</a></div>
-<div class="doc_text">
- <p>This file, located at <tt>$(LLVM_SRC_ROOT)/Makefile.rules</tt> is the heart
- of the LLVM Makefile System. It provides all the logic, dependencies, and
- rules for building the targets supported by the system. What it does largely
- depends on the values of <tt>make</tt> <a href="#variables">variables</a> that
- have been set <em>before</em> <tt>Makefile.rules</tt> is included.
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="Comments">Comments</a></div>
-<div class="doc_text">
- <p>User Makefiles need not have comments in them unless the construction is
- unusual or it does not strictly follow the rules and patterns of the LLVM
- makefile system. Makefile comments are invoked with the pound (#) character.
- The # character and any text following it, to the end of the line, are ignored
- by <tt>make</tt>.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="tutorial">Tutorial</a></div>
-<!-- *********************************************************************** -->
-<div class="doc_text">
- <p>This section provides some examples of the different kinds of modules you
- can build with the LLVM makefile system. In general, each directory you
- provide will build a single object although that object may be composed of
- additionally compiled components.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="libraries">Libraries</a></div>
-<div class="doc_text">
- <p>Only a few variable definitions are needed to build a regular library.
- Normally, the makefile system will build all the software into a single
- <tt>libname.o</tt> (pre-linked) object. This means the library is not
- searchable and that the distinction between compilation units has been
- dissolved. Optionally, you can ask for a shared library (.so) or archive
- library (.a) built. Archive libraries are the default. For example:</p>
- <pre><tt>
- LIBRARYNAME = mylib
- SHARED_LIBRARY = 1
- ARCHIVE_LIBRARY = 1
- </tt></pre>
- <p>says to build a library named "mylib" with both a shared library
- (<tt>mylib.so</tt>) and an archive library (<tt>mylib.a</tt>) version. The
- contents of all the
- libraries produced will be the same, they are just constructed differently.
- Note that you normally do not need to specify the sources involved. The LLVM
- Makefile system will infer the source files from the contents of the source
- directory.</p>
- <p>The <tt>LOADABLE_MODULE=1</tt> directive can be used in conjunction with
- <tt>SHARED_LIBRARY=1</tt> to indicate that the resulting shared library should
- be openable with the <tt>dlopen</tt> function and searchable with the
- <tt>dlsym</tt> function (or your operating system's equivalents). While this
- isn't strictly necessary on Linux and a few other platforms, it is required
- on systems like HP-UX and Darwin. You should use <tt>LOADABLE_MODULE</tt> for
- any shared library that you intend to be loaded into an tool via the
- <tt>-load</tt> option. See the
- <a href="WritingAnLLVMPass.html#makefile">WritingAnLLVMPass.html</a> document
- for an example of why you might want to do this.
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="BCModules">Bitcode Modules</a></div>
-<div class="doc_text">
- <p>In some situations, it is desirable to build a single bitcode module from
- a variety of sources, instead of an archive, shared library, or bitcode
- library. Bitcode modules can be specified in addition to any of the other
- types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>
- variable. For example:</p>
- <pre><tt>
- LIBRARYNAME = mylib
- BYTECODE_LIBRARY = 1
- MODULE_NAME = mymod
- </tt></pre>
- <p>will build a module named <tt>mymod.bc</tt> from the sources in the
- directory. This module will be an aggregation of all the bitcode modules
- derived from the sources. The example will also build a bitcode archive
- containing a bitcode module for each compiled source file. The difference is
- subtle, but important depending on how the module or library is to be linked.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="LoadableModules">Loadable Modules</a>
-</div>
-<div class="doc_text">
- <p>In some situations, you need to create a loadable module. Loadable modules
- can be loaded into programs like <tt>opt</tt> or <tt>llc</tt> to specify
- additional passes to run or targets to support. Loadable modules are also
- useful for debugging a pass or providing a pass with another package if that
- pass can't be included in LLVM.</p>
- <p>LLVM provides complete support for building such a module. All you need to
- do is use the LOADABLE_MODULE variable in your Makefile. For example, to
- build a loadable module named <tt>MyMod</tt> that uses the LLVM libraries
- <tt>LLVMSupport.a</tt> and <tt>LLVMSystem.a</tt>, you would specify:</p>
- <pre><tt>
- LIBRARYNAME := MyMod
- LOADABLE_MODULE := 1
- LINK_COMPONENTS := support system
- </tt></pre>
- <p>Use of the <tt>LOADABLE_MODULE</tt> facility implies several things:</p>
- <ol>
- <li>There will be no "lib" prefix on the module. This differentiates it from
- a standard shared library of the same name.</li>
- <li>The <a href="#SHARED_LIBRARY">SHARED_LIBRARY</a> variable is turned
- on.</li>
- <li>The <a href="#LINK_LIBS_IN_SHARED">LINK_LIBS_IN_SHARED</a> variable
- is turned on.</li>
- </ol>
- <p>A loadable module is loaded by LLVM via the facilities of libtool's libltdl
- library which is part of <tt>lib/System</tt> implementation.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="tools">Tools</a></div>
-<div class="doc_text">
- <p>For building executable programs (tools), you must provide the name of the
- tool and the names of the libraries you wish to link with the tool. For
- example:</p>
- <pre><tt>
- TOOLNAME = mytool
- USEDLIBS = mylib
- LINK_COMPONENTS = support system
- </tt></pre>
- <p>says that we are to build a tool name <tt>mytool</tt> and that it requires
- three libraries: <tt>mylib</tt>, <tt>LLVMSupport.a</tt> and
- <tt>LLVMSystem.a</tt>.</p>
- <p>Note that two different variables are use to indicate which libraries are
- linked: <tt>USEDLIBS</tt> and <tt>LLVMLIBS</tt>. This distinction is necessary
- to support projects. <tt>LLVMLIBS</tt> refers to the LLVM libraries found in
- the LLVM object directory. <tt>USEDLIBS</tt> refers to the libraries built by
- your project. In the case of building LLVM tools, <tt>USEDLIBS</tt> and
- <tt>LLVMLIBS</tt> can be used interchangeably since the "project" is LLVM
- itself and <tt>USEDLIBS</tt> refers to the same place as <tt>LLVMLIBS</tt>.
- </p>
- <p>Also note that there are two different ways of specifying a library: with a
- <tt>.a</tt> suffix and without. Without the suffix, the entry refers to the
- re-linked (.o) file which will include <em>all</em> symbols of the library.
- This is useful, for example, to include all passes from a library of passes.
- If the <tt>.a</tt> suffix is used then the library is linked as a searchable
- library (with the <tt>-l</tt> option). In this case, only the symbols that are
- unresolved <em>at that point</em> will be resolved from the library, if they
- exist. Other (unreferenced) symbols will not be included when the <tt>.a</tt>
- syntax is used. Note that in order to use the <tt>.a</tt> suffix, the library
- in question must have been built with the <tt>ARCHIVE_LIBRARY</tt> option set.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection"><a name="JIT">JIT Tools</a></div>
-<div class="doc_text">
- <p>Many tools will want to use the JIT features of LLVM. To do this, you
- simply specify that you want an execution 'engine', and the makefiles will
- automatically link in the appropriate JIT for the host or an interpreter
- if none is available:</p>
- <pre><tt>
- TOOLNAME = my_jit_tool
- USEDLIBS = mylib
- LINK_COMPONENTS = engine
- </tt></pre>
- <p>Of course, any additional libraries may be listed as other components. To
- get a full understanding of how this changes the linker command, it is
- recommended that you:</p>
- <pre><tt>
- cd examples/Fibonacci
- make VERBOSE=1
- </tt></pre>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="targets">Targets Supported</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
- <p>This section describes each of the targets that can be built using the LLVM
- Makefile system. Any target can be invoked from any directory but not all are
- applicable to a given directory (e.g. "check", "dist" and "install" will
- always operate as if invoked from the top level directory).</p>
-
- <table style="text-align:left">
- <tr>
- <th>Target Name</th><th>Implied Targets</th><th>Target Description</th>
- </tr>
- <tr><td><a href="#all"><tt>all</tt></a></td><td></td>
- <td>Compile the software recursively. Default target.
- </td></tr>
- <tr><td><a href="#all-local"><tt>all-local</tt></a></td><td></td>
- <td>Compile the software in the local directory only.
- </td></tr>
- <tr><td><a href="#check"><tt>check</tt></a></td><td></td>
- <td>Change to the <tt>test</tt> directory in a project and run the
- test suite there.
- </td></tr>
- <tr><td><a href="#check-local"><tt>check-local</tt></a></td><td></td>
- <td>Run a local test suite. Generally this is only defined in the
- <tt>Makefile</tt> of the project's <tt>test</tt> directory.
- </td></tr>
- <tr><td><a href="#clean"><tt>clean</tt></a></td><td></td>
- <td>Remove built objects recursively.
- </td></tr>
- <tr><td><a href="#clean-local"><tt>clean-local</tt></a></td><td></td>
- <td>Remove built objects from the local directory only.
- </td></tr>
- <tr><td><a href="#dist"><tt>dist</tt></a></td><td>all</td>
- <td>Prepare a source distribution tarball.
- </td></tr>
- <tr><td><a href="#dist-check"><tt>dist-check</tt></a></td><td>all</td>
- <td>Prepare a source distribution tarball and check that it builds.
- </td></tr>
- <tr><td><a href="#dist-clean"><tt>dist-clean</tt></a></td><td>clean</td>
- <td>Clean source distribution tarball temporary files.
- </td></tr>
- <tr><td><a href="#install"><tt>install</tt></a></td><td>all</td>
- <td>Copy built objects to installation directory.
- </td></tr>
- <tr><td><a href="#preconditions"><tt>preconditions</tt></a></td><td>all</td>
- <td>Check to make sure configuration and makefiles are up to date.
- </td></tr>
- <tr><td><a href="#printvars"><tt>printvars</tt></a></td><td>all</td>
- <td>Prints variables defined by the makefile system (for debugging).
- </td></tr>
- <tr><td><a href="#tags"><tt>tags</tt></a></td><td></td>
- <td>Make C and C++ tags files for emacs and vi.
- </td></tr>
- <tr><td><a href="#uninstall"><tt>uninstall</tt></a></td><td></td>
- <td>Remove built objects from installation directory.
- </td></tr>
- </table>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="all">all (default)</a></div>
-<div class="doc_text">
- <p>When you invoke <tt>make</tt> with no arguments, you are implicitly
- instructing it to seek the "all" target (goal). This target is used for
- building the software recursively and will do different things in different
- directories. For example, in a <tt>lib</tt> directory, the "all" target will
- compile source files and generate libraries. But, in a <tt>tools</tt>
- directory, it will link libraries and generate executables.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="all-local">all-local</a></div>
-<div class="doc_text">
- <p>This target is the same as <a href="#all">all</a> but it operates only on
- the current directory instead of recursively.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="check">check</a></div>
-<div class="doc_text">
- <p>This target can be invoked from anywhere within a project's directories
- but always invokes the <a href="#check-local"><tt>check-local</tt></a> target
- in the project's <tt>test</tt> directory, if it exists and has a
- <tt>Makefile</tt>. A warning is produced otherwise. If
- <a href="#TESTSUITE"><tt>TESTSUITE</tt></a> is defined on the <tt>make</tt>
- command line, it will be passed down to the invocation of
- <tt>make check-local</tt> in the <tt>test</tt> directory. The intended usage
- for this is to assist in running specific suites of tests. If
- <tt>TESTSUITE</tt> is not set, the implementation of <tt>check-local</tt>
- should run all normal tests. It is up to the project to define what
- different values for <tt>TESTSUTE</tt> will do. See the
- <a href="TestingGuide.html">TestingGuide</a> for further details.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="check-local">check-local</a></div>
-<div class="doc_text">
- <p>This target should be implemented by the <tt>Makefile</tt> in the project's
- <tt>test</tt> directory. It is invoked by the <tt>check</tt> target elsewhere.
- Each project is free to define the actions of <tt>check-local</tt> as
- appropriate for that project. The LLVM project itself uses dejagnu to run a
- suite of feature and regresson tests. Other projects may choose to use
- dejagnu or any other testing mechanism.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="clean">clean</a></div>
-<div class="doc_text">
- <p>This target cleans the build directory, recursively removing all things
- that the Makefile builds. The cleaning rules have been made guarded so they
- shouldn't go awry (via <tt>rm -f $(UNSET_VARIABLE)/*</tt> which will attempt
- to erase the entire directory structure.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="clean-local">clean-local</a></div>
-<div class="doc_text">
- <p>This target does the same thing as <tt>clean</tt> but only for the current
- (local) directory.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="dist">dist</a></div>
-<div class="doc_text">
- <p>This target builds a distribution tarball. It first builds the entire
- project using the <tt>all</tt> target and then tars up the necessary files and
- compresses it. The generated tarball is sufficient for a casual source
- distribution, but probably not for a release (see <tt>dist-check</tt>).</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="dist-check">dist-check</a></div>
-<div class="doc_text">
- <p>This target does the same thing as the <tt>dist</tt> target but also checks
- the distribution tarball. The check is made by unpacking the tarball to a new
- directory, configuring it, building it, installing it, and then verifying that
- the installation results are correct (by comparing to the original build).
- This target can take a long time to run but should be done before a release
- goes out to make sure that the distributed tarball can actually be built into
- a working release.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="dist-clean">dist-clean</a></div>
-<div class="doc_text">
- <p>This is a special form of the <tt>clean</tt> clean target. It performs a
- normal <tt>clean</tt> but also removes things pertaining to building the
- distribution.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="install">install</a></div>
-<div class="doc_text">
- <p>This target finalizes shared objects and executables and copies all
- libraries, headers, executables and documentation to the directory given
- with the <tt>--prefix</tt> option to <tt>configure</tt>. When completed,
- the prefix directory will have everything needed to <b>use</b> LLVM. </p>
- <p>The LLVM makefiles can generate complete <b>internal</b> documentation
- for all the classes by using <tt>doxygen</tt>. By default, this feature is
- <b>not</b> enabled because it takes a long time and generates a massive
- amount of data (>100MB). If you want this feature, you must configure LLVM
- with the --enable-doxygen switch and ensure that a modern version of doxygen
- (1.3.7 or later) is available in your <tt>PATH</tt>. You can download
- doxygen from
- <a href="http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc">
- here</a>.
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="preconditions">preconditions</a></div>
-<div class="doc_text">
- <p>This utility target checks to see if the <tt>Makefile</tt> in the object
- directory is older than the <tt>Makefile</tt> in the source directory and
- copies it if so. It also reruns the <tt>configure</tt> script if that needs to
- be done and rebuilds the <tt>Makefile.config</tt> file similarly. Users may
- overload this target to ensure that sanity checks are run <em>before</em> any
- building of targets as all the targets depend on <tt>preconditions</tt>.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="printvars">printvars</a></div>
-<div class="doc_text">
- <p>This utility target just causes the LLVM makefiles to print out some of
- the makefile variables so that you can double check how things are set. </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="reconfigure">reconfigure</a></div>
-<div class="doc_text">
- <p>This utility target will force a reconfigure of LLVM or your project. It
- simply runs <tt>$(PROJ_OBJ_ROOT)/config.status --recheck</tt> to rerun the
- configuration tests and rebuild the configured files. This isn't generally
- useful as the makefiles will reconfigure themselves whenever its necessary.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="spotless">spotless</a></div>
-<div class="doc_text">
- <p>This utility target, only available when <tt>$(PROJ_OBJ_ROOT)</tt> is not
- the same as <tt>$(PROJ_SRC_ROOT)</tt>, will completely clean the
- <tt>$(PROJ_OBJ_ROOT)</tt> directory by removing its content entirely and
- reconfiguring the directory. This returns the <tt>$(PROJ_OBJ_ROOT)</tt>
- directory to a completely fresh state. All content in the directory except
- configured files and top-level makefiles will be lost.</p>
- <div class="doc_warning"><p>Use with caution.</p></div>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="tags">tags</a></div>
-<div class="doc_text">
- <p>This target will generate a <tt>TAGS</tt> file in the top-level source
- directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file
- provides an index of symbol definitions so that the editor can jump you to the
- definition quickly. </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="uninstall">uninstall</a></div>
-<div class="doc_text">
- <p>This target is the opposite of the <tt>install</tt> target. It removes the
- header, library and executable files from the installation directories. Note
- that the directories themselves are not removed because it is not guaranteed
- that LLVM is the only thing installing there (e.g. --prefix=/usr).</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="variables">Variables</a></div>
-<!-- *********************************************************************** -->
-<div class="doc_text">
- <p>Variables are used to tell the LLVM Makefile System what to do and to
- obtain information from it. Variables are also used internally by the LLVM
- Makefile System. Variable names that contain only the upper case alphabetic
- letters and underscore are intended for use by the end user. All other
- variables are internal to the LLVM Makefile System and should not be relied
- upon nor modified. The sections below describe how to use the LLVM Makefile
- variables.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="setvars">Control Variables</a></div>
-<div class="doc_text">
- <p>Variables listed in the table below should be set <em>before</em> the
- inclusion of <a href="#Makefile.common"><tt>$(LEVEL)/Makefile.common</tt></a>.
- These variables provide input to the LLVM make system that tell it what to do
- for the current directory.</p>
- <dl>
- <dt><a name="BUILD_ARCHIVE"><tt>BUILD_ARCHIVE</tt></a></dt>
- <dd>If set to any value, causes an archive (.a) library to be built.</dd>
- <dt><a name="BUILT_SOURCES"><tt>BUILT_SOURCES</tt></a></dt>
- <dd>Specifies a set of source files that are generated from other source
- files. These sources will be built before any other target processing to
- ensure they are present.</dd>
- <dt><a name="BYTECODE_LIBRARY"><tt>BYTECODE_LIBRARY</tt></a></dt>
- <dd>If set to any value, causes a bitcode library (.bc) to be built.</dd>
- <dt><a name="CONFIG_FILES"><tt>CONFIG_FILES</tt></a></dt>
- <dd>Specifies a set of configuration files to be installed.</dd>
- <dt><a name="DEBUG_SYMBOLS"><tt>DEBUG_SYMBOLS</tt></a></dt>
- <dd>If set to any value, causes the build to include debugging
- symbols even in optimized objects, libraries and executables. This
- alters the flags specified to the compilers and linkers. Debugging
- isn't fun in an optimized build, but it is possible.</dd>
- <dt><a name="DIRS"><tt>DIRS</tt></a></dt>
- <dd>Specifies a set of directories, usually children of the current
- directory, that should also be made using the same goal. These directories
- will be built serially.</dd>
- <dt><a name="DISABLE_AUTO_DEPENDENCIES"><tt>DISABLE_AUTO_DEPENDENCIES</tt></a></dt>
- <dd>If set to any value, causes the makefiles to <b>not</b> automatically
- generate dependencies when running the compiler. Use of this feature is
- discouraged and it may be removed at a later date.</dd>
- <dt><a name="ENABLE_OPTIMIZED"><tt>ENABLE_OPTIMIZED</tt></a></dt>
- <dd>If set to any value, causes the build to generate optimized objects,
- libraries and executables. This alters the flags specified to the compilers
- and linkers. Generally debugging won't be a fun experience with an optimized
- build.</dd>
- <dt><a name="ENABLE_PROFILING"><tt>ENABLE_PROFILING</tt></a></dt>
- <dd>If set to any value, causes the build to generate both optimized and
- profiled objects, libraries and executables. This alters the flags specified
- to the compilers and linkers to ensure that profile data can be collected
- from the tools built. Use the <tt>gprof</tt> tool to analyze the output from
- the profiled tools (<tt>gmon.out</tt>).</dd>
- <dt><a name="DISABLE_ASSERTIONS"><tt>DISABLE_ASSERTIONS</tt></a></dt>
- <dd>If set to any value, causes the build to disable assertions, even if
- building a release or profile build. This will exclude all assertion check
- code from the build. LLVM will execute faster, but with little help when
- things go wrong.</dd>
- <dt><a name="EXPERIMENTAL_DIRS"><tt>EXPERIMENTAL_DIRS</tt></a></dt>
- <dd>Specify a set of directories that should be built, but if they fail, it
- should not cause the build to fail. Note that this should only be used
- temporarily while code is being written.</dd>
- <dt><a name="EXPORTED_SYMBOL_FILE"><tt>EXPORTED_SYMBOL_FILE</tt></a></dt>
- <dd>Specifies the name of a single file that contains a list of the
- symbols to be exported by the linker. One symbol per line.</dd>
- <dt><a name="EXPORTED_SYMBOL_LIST"><tt>EXPORTED_SYMBOL_LIST</tt></a></dt>
- <dd>Specifies a set of symbols to be exported by the linker.</dd>
- <dt><a name="EXTRA_DIST"><tt>EXTRA_DIST</tt></a></dt>
- <dd>Specifies additional files that should be distributed with LLVM. All
- source files, all built sources, all Makefiles, and most documentation files
- will be automatically distributed. Use this variable to distribute any
- files that are not automatically distributed.</dd>
- <dt><a name="KEEP_SYMBOLS"><tt>KEEP_SYMBOLS</tt></a></dt>
- <dd>If set to any value, specifies that when linking executables the
- makefiles should retain debug symbols in the executable. Normally, symbols
- are stripped from the executable.</dd>
- <dt><a name="LEVEL"><tt>LEVEL</tt></a><small>(required)</small></dt>
- <dd>Specify the level of nesting from the top level. This variable must be
- set in each makefile as it is used to find the top level and thus the other
- makefiles.</dd>
- <dt><a name="LIBRARYNAME"><tt>LIBRARYNAME</tt></a></dt>
- <dd>Specify the name of the library to be built. (Required For
- Libraries)</dd>
- <dt><a name="LINK_COMPONENTS"><tt>LINK_COMPONENTS</tt></a></dt>
- <dd>When specified for building a tool, the value of this variable will be
- passed to the <tt>llvm-config</tt> tool to generate a link line for the
- tool. Unlike <tt>USEDLIBS</tt> and <tt>LLVMLIBS</tt>, not all libraries need
- to be specified. The <tt>llvm-config</tt> tool will figure out the library
- dependencies and add any libraries that are needed. The <tt>USEDLIBS</tt>
- variable can still be used in conjunction with <tt>LINK_COMPONENTS</tt> so
- that additional project-specific libraries can be linked with the LLVM
- libraries specified by <tt>LINK_COMPONENTS</tt></dd>
- <dt><a name="LINK_LIBS_IN_SHARED"><tt>LINK_LIBS_IN_SHARED</tt></a></dt>
- <dd>By default, shared library linking will ignore any libraries specified
- with the <a href="LLVMLIBS">LLVMLIBS</a> or <a href="USEDLIBS">USEDLIBS</a>.
- This prevents shared libs from including things that will be in the LLVM
- tool the shared library will be loaded into. However, sometimes it is useful
- to link certain libraries into your shared library and this option enables
- that feature.</dd>
- <dt><a name="LLVMLIBS"><tt>LLVMLIBS</tt></a></dt>
- <dd>Specifies the set of libraries from the LLVM $(ObjDir) that will be
- linked into the tool or library.</dd>
- <dt><a name="LOADABLE_MODULE"><tt>LOADABLE_MODULE</tt></a></dt>
- <dd>If set to any value, causes the shared library being built to also be
- a loadable module. Loadable modules can be opened with the dlopen() function
- and searched with dlsym (or the operating system's equivalent). Note that
- setting this variable without also setting <tt>SHARED_LIBRARY</tt> will have
- no effect.</dd>
- <dt><a name="MODULE_NAME"><tt>MODULE_NAME</tt></a></dt>
- <dd>Specifies the name of a bitcode module to be created. A bitcode
- module can be specified in conjunction with other kinds of library builds
- or by itself. It constructs from the sources a single linked bitcode
- file.</dd>
- <dt><a name="NO_INSTALL"><tt>NO_INSTALL</tt></a></dt>
- <dd>Specifies that the build products of the directory should not be
- installed but should be built even if the <tt>install</tt> target is given.
- This is handy for directories that build libraries or tools that are only
- used as part of the build process, such as code generators (e.g.
- <tt>tblgen</tt>).</dd>
- <dt><a name="OPTIONAL_DIRS"><tt>OPTIONAL_DIRS</tt></a></dt>
- <dd>Specify a set of directories that may be built, if they exist, but its
- not an error for them not to exist.</dd>
- <dt><a name="PARALLEL_DIRS"><tt>PARALLEL_DIRS</tt></a></dt>
- <dd>Specify a set of directories to build recursively and in parallel if
- the -j option was used with <tt>make</tt>.</dd>
- <dt><a name="SHARED_LIBRARY"><tt>SHARED_LIBRARY</tt></a></dt>
- <dd>If set to any value, causes a shared library (.so) to be built in
- addition to any other kinds of libraries. Note that this option will cause
- all source files to be built twice: once with options for position
- independent code and once without. Use it only where you really need a
- shared library.</dd>
- <dt><a name="SOURCES"><tt>SOURCES</tt><small>(optional)</small></a></dt>
- <dd>Specifies the list of source files in the current directory to be
- built. Source files of any type may be specified (programs, documentation,
- config files, etc.). If not specified, the makefile system will infer the
- set of source files from the files present in the current directory.</dd>
- <dt><a name="SUFFIXES"><tt>SUFFIXES</tt></a></dt>
- <dd>Specifies a set of filename suffixes that occur in suffix match rules.
- Only set this if your local <tt>Makefile</tt> specifies additional suffix
- match rules.</dd>
- <dt><a name="TARGET"><tt>TARGET</tt></a></dt>
- <dd>Specifies the name of the LLVM code generation target that the
- current directory builds. Setting this variable enables additional rules to
- build <tt>.inc</tt> files from <tt>.td</tt> files. </dd>
- <dt><a name="TESTSUITE"><tt>TESTSUITE</tt></a></dt>
- <dd>Specifies the directory of tests to run in <tt>llvm/test</tt>.</dd>
- <dt><a name="TOOLNAME"><tt>TOOLNAME</tt></a></dt>
- <dd>Specifies the name of the tool that the current directory should
- build.</dd>
- <dt><a name="TOOL_VERBOSE"><tt>TOOL_VERBOSE</tt></a></dt>
- <dd>Implies VERBOSE and also tells each tool invoked to be verbose. This is
- handy when you're trying to see the sub-tools invoked by each tool invoked
- by the makefile. For example, this will pass <tt>-v</tt> to the GCC
- compilers which causes it to print out the command lines it uses to invoke
- sub-tools (compiler, assembler, linker).</dd>
- <dt><a name="USEDLIBS"><tt>USEDLIBS</tt></a></dt>
- <dd>Specifies the list of project libraries that will be linked into the
- tool or library.</dd>
- <dt><a name="VERBOSE"><tt>VERBOSE</tt></a></dt>
- <dd>Tells the Makefile system to produce detailed output of what it is doing
- instead of just summary comments. This will generate a LOT of output.</dd>
- </dl>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="overvars">Override Variables</a></div>
-<div class="doc_text">
- <p>Override variables can be used to override the default
- values provided by the LLVM makefile system. These variables can be set in
- several ways:</p>
- <ul>
- <li>In the environment (e.g. setenv, export) -- not recommended.</li>
- <li>On the <tt>make</tt> command line -- recommended.</li>
- <li>On the <tt>configure</tt> command line</li>
- <li>In the Makefile (only <em>after</em> the inclusion of <a
- href="#Makefile.common"><tt>$(LEVEL)/Makefile.common</tt></a>).</li>
- </ul>
- <p>The override variables are given below:</p>
- <dl>
- <dt><a name="AR"><tt>AR</tt></a> <small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>ar</tt> tool.</dd>
- <dt><a name="PROJ_OBJ_DIR"><tt>PROJ_OBJ_DIR</tt></a></dt>
- <dd>The directory into which the products of build rules will be placed.
- This might be the same as
- <a href="#PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a> but typically is
- not.</dd>
- <dt><a name="PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a></dt>
- <dd>The directory which contains the source files to be built.</dd>
- <dt><a name="BZIP2"><tt>BZIP2</tt></a><small>(configured)</small></dt>
- <dd>The path to the <tt>bzip2</tt> tool.</dd>
- <dt><a name="CC"><tt>CC</tt></a><small>(configured)</small></dt>
- <dd>The path to the 'C' compiler.</dd>
- <dt><a name="CFLAGS"><tt>CFLAGS</tt></a></dt>
- <dd>Additional flags to be passed to the 'C' compiler.</dd>
- <dt><a name="CXX"><tt>CXX</tt></a></dt>
- <dd>Specifies the path to the C++ compiler.</dd>
- <dt><a name="CXXFLAGS"><tt>CXXFLAGS</tt></a></dt>
- <dd>Additional flags to be passed to the C++ compiler.</dd>
- <dt><a name="DATE"><tt>DATE<small>(configured)</small></tt></a></dt>
- <dd>Specifies the path to the <tt>date</tt> program or any program that can
- generate the current date and time on its standard output</dd>
- <dt><a name="DOT"><tt>DOT</tt></a><small>(configured)</small></dt>
- <dd>Specifies the path to the <tt>dot</tt> tool or <tt>false</tt> if there
- isn't one.</dd>
- <dt><a name="ECHO"><tt>ECHO</tt></a><small>(configured)</small></dt>
- <dd>Specifies the path to the <tt>echo</tt> tool for printing output.</dd>
- <dt><a name="EXEEXT"><tt>EXEEXT</tt></a><small>(configured)</small></dt>
- <dd>Provides the extension to be used on executables built by the makefiles.
- The value may be empty on platforms that do not use file extensions for
- executables (e.g. Unix).</dd>
- <dt><a name="INSTALL"><tt>INSTALL</tt></a><small>(configured)</small></dt>
- <dd>Specifies the path to the <tt>install</tt> tool.</dd>
- <dt><a name="LDFLAGS"><tt>LDFLAGS</tt></a><small>(configured)</small></dt>
- <dd>Allows users to specify additional flags to pass to the linker.</dd>
- <dt><a name="LIBS"><tt>LIBS</tt></a><small>(configured)</small></dt>
- <dd>The list of libraries that should be linked with each tool.</dd>
- <dt><a name="LIBTOOL"><tt>LIBTOOL</tt></a><small>(configured)</small></dt>
- <dd>Specifies the path to the <tt>libtool</tt> tool. This tool is renamed
- <tt>mklib</tt> by the <tt>configure</tt> script and always located in the
- <dt><a name="LLVMAS"><tt>LLVMAS</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>llvm-as</tt> tool.</dd>
- <dt><a name="LLVMCC"><tt>LLVMCC</tt></a></dt>
- <dd>Specifies the path to the LLVM capable compiler.</dd>
- <dt><a name="LLVMCXX"><tt>LLVMCXX</tt></a></dt>
- <dd>Specifies the path to the LLVM C++ capable compiler.</dd>
- <dt><a name="LLVMGCC"><tt>LLVMGCC</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the LLVM version of the GCC 'C' Compiler</dd>
- <dt><a name="LLVMGXX"><tt>LLVMGXX</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the LLVM version of the GCC C++ Compiler</dd>
- <dt><a name="LLVMLD"><tt>LLVMLD</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the LLVM bitcode linker tool</dd>
- <dt><a name="LLVM_OBJ_ROOT"><tt>LLVM_OBJ_ROOT</tt></a><small>(configured)
- </small></dt>
- <dd>Specifies the top directory into which the output of the build is
- placed.</dd>
- <dt><a name="LLVM_SRC_ROOT"><tt>LLVM_SRC_ROOT</tt></a><small>(configured)
- </small></dt>
- <dd>Specifies the top directory in which the sources are found.</dd>
- <dt><a name="LLVM_TARBALL_NAME"><tt>LLVM_TARBALL_NAME</tt></a>
- <small>(configured)</small></dt>
- <dd>Specifies the name of the distribution tarball to create. This is
- configured from the name of the project and its version number.</dd>
- <dt><a name="MKDIR"><tt>MKDIR</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>mkdir</tt> tool that creates
- directories.</dd>
- <dt><a name="ONLY_TOOLS"><tt>ONLY_TOOLS</tt></a></dt>
- <dd>If set, specifies the list of tools to build.</dd>
- <dt><a name="PLATFORMSTRIPOPTS"><tt>PLATFORMSTRIPOPTS</tt></a></dt>
- <dd>The options to provide to the linker to specify that a stripped (no
- symbols) executable should be built.</dd>
- <dt><a name="RANLIB"><tt>RANLIB</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>ranlib</tt> tool.</dd>
- <dt><a name="RM"><tt>RM</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>rm</tt> tool.</dd>
- <dt><a name="SED"><tt>SED</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>sed</tt> tool.</dd>
- <dt><a name="SHLIBEXT"><tt>SHLIBEXT</tt></a><small>(configured)</small></dt>
- <dd>Provides the filename extension to use for shared libraries.</dd>
- <dt><a name="TBLGEN"><tt>TBLGEN</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>tblgen</tt> tool.</dd>
- <dt><a name="TAR"><tt>TAR</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>tar</tt> tool.</dd>
- <dt><a name="ZIP"><tt>ZIP</tt></a><small>(defaulted)</small></dt>
- <dd>Specifies the path to the <tt>zip</tt> tool.</dd>
- </dl>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="getvars">Readable Variables</a></div>
-<div class="doc_text">
- <p>Variables listed in the table below can be used by the user's Makefile but
- should not be changed. Changing the value will generally cause the build to go
- wrong, so don't do it.</p>
- <dl>
- <dt><a name="bindir"><tt>bindir</tt></a></dt>
- <dd>The directory into which executables will ultimately be installed. This
- value is derived from the <tt>--prefix</tt> option given to
- <tt>configure</tt>.</dd>
- <dt><a name="BuildMode"><tt>BuildMode</tt></a></dt>
- <dd>The name of the type of build being performed: Debug, Release, or
- Profile</dd>
- <dt><a name="bitcode_libdir"><tt>bytecode_libdir</tt></a></dt>
- <dd>The directory into which bitcode libraries will ultimately be
- installed. This value is derived from the <tt>--prefix</tt> option given to
- <tt>configure</tt>.</dd>
- <dt><a name="ConfigureScriptFLAGS"><tt>ConfigureScriptFLAGS</tt></a></dt>
- <dd>Additional flags given to the <tt>configure</tt> script when
- reconfiguring.</dd>
- <dt><a name="DistDir"><tt>DistDir</tt></a></dt>
- <dd>The <em>current</em> directory for which a distribution copy is being
- made.</dd>
- <dt><a name="Echo"><tt>Echo</tt></a></dt>
- <dd>The LLVM Makefile System output command. This provides the
- <tt>llvm[n]</tt> prefix and starts with @ so the command itself is not
- printed by <tt>make</tt>.</dd>
- <dt><a name="EchoCmd"><tt>EchoCmd</tt></a></dt>
- <dd> Same as <a href="#Echo"><tt>Echo</tt></a> but without the leading @.
- </dd>
- <dt><a name="includedir"><tt>includedir</tt></a></dt>
- <dd>The directory into which include files will ultimately be installed.
- This value is derived from the <tt>--prefix</tt> option given to
- <tt>configure</tt>.</dd>
- <dt><a name="libdir"><tt>libdir</tt></a></dt><dd></dd>
- <dd>The directory into which native libraries will ultimately be installed.
- This value is derived from the <tt>--prefix</tt> option given to
- <tt>configure</tt>.</dd>
- <dt><a name="LibDir"><tt>LibDir</tt></a></dt>
- <dd>The configuration specific directory into which libraries are placed
- before installation.</dd>
- <dt><a name="MakefileConfig"><tt>MakefileConfig</tt></a></dt>
- <dd>Full path of the <tt>Makefile.config</tt> file.</dd>
- <dt><a name="MakefileConfigIn"><tt>MakefileConfigIn</tt></a></dt>
- <dd>Full path of the <tt>Makefile.config.in</tt> file.</dd>
- <dt><a name="ObjDir"><tt>ObjDir</tt></a></dt>
- <dd>The configuration and directory specific directory where build objects
- (compilation results) are placed.</dd>
- <dt><a name="SubDirs"><tt>SubDirs</tt></a></dt>
- <dd>The complete list of sub-directories of the current directory as
- specified by other variables.</dd>
- <dt><a name="Sources"><tt>Sources</tt></a></dt>
- <dd>The complete list of source files.</dd>
- <dt><a name="sysconfdir"><tt>sysconfdir</tt></a></dt>
- <dd>The directory into which configuration files will ultimately be
- installed. This value is derived from the <tt>--prefix</tt> option given to
- <tt>configure</tt>.</dd>
- <dt><a name="ToolDir"><tt>ToolDir</tt></a></dt>
- <dd>The configuration specific directory into which executables are placed
- before they are installed.</dd>
- <dt><a name="TopDistDir"><tt>TopDistDir</tt></a></dt>
- <dd>The top most directory into which the distribution files are copied.
- </dd>
- <dt><a name="Verb"><tt>Verb</tt></a></dt>
- <dd>Use this as the first thing on your build script lines to enable or
- disable verbose mode. It expands to either an @ (quiet mode) or nothing
- (verbose mode). </dd>
- </dl>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="intvars">Internal Variables</a></div>
-<div class="doc_text">
- <p>Variables listed below are used by the LLVM Makefile System
- and considered internal. You should not use these variables under any
- circumstances.</p>
- <p><tt>
- Archive
- AR.Flags
- BaseNameSources
- BCCompile.C
- BCCompile.CXX
- BCLinkLib
- C.Flags
- Compile.C
- CompileCommonOpts
- Compile.CXX
- ConfigStatusScript
- ConfigureScript
- CPP.Flags
- CPP.Flags
- CXX.Flags
- DependFiles
- DestArchiveLib
- DestBitcodeLib
- DestModule
- DestSharedLib
- DestTool
- DistAlways
- DistCheckDir
- DistCheckTop
- DistFiles
- DistName
- DistOther
- DistSources
- DistSubDirs
- DistTarBZ2
- DistTarGZip
- DistZip
- ExtraLibs
- FakeSources
- INCFiles
- InternalTargets
- LD.Flags
- LibName.A
- LibName.BC
- LibName.LA
- LibName.O
- LibTool.Flags
- Link
- LinkModule
- LLVMLibDir
- LLVMLibsOptions
- LLVMLibsPaths
- LLVMToolDir
- LLVMUsedLibs
- LocalTargets
- Module
- ObjectsBC
- ObjectsLO
- ObjectsO
- ObjMakefiles
- ParallelTargets
- PreConditions
- ProjLibsOptions
- ProjLibsPaths
- ProjUsedLibs
- Ranlib
- RecursiveTargets
- SrcMakefiles
- Strip
- StripWarnMsg
- TableGen
- TDFiles
- ToolBuildPath
- TopLevelTargets
- UserTargets
- </tt></p>
-</div>
-
-<!-- *********************************************************************** -->
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:rspencer at x10sys.com">Reid Spencer</a><br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-</body>
-</html>
Removed: llvm/trunk/docs/Packaging.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Packaging.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/Packaging.html (original)
+++ llvm/trunk/docs/Packaging.html (removed)
@@ -1,118 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>Advice on Packaging LLVM</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">Advice on Packaging LLVM</div>
-<ol>
- <li><a href="#overview">Overview</a></li>
- <li><a href="#compilation">Compile Flags</a></li>
- <li><a href="#cxx-features">C++ Features</a></li>
- <li><a href="#shared-library">Shared Library</a></li>
- <li><a href="#deps">Dependencies</a></li>
-</ol>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="overview">Overview</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
-
-<p>LLVM sets certain default configure options to make sure our developers don't
-break things for constrained platforms. These settings are not optimal for most
-desktop systems, and we hope that packagers (e.g., Redhat, Debian, MacPorts,
-etc.) will tweak them. This document lists settings we suggest you tweak.
-</p>
-
-<p>LLVM's API changes with each release, so users are likely to want, for
-example, both LLVM-2.6 and LLVM-2.7 installed at the same time to support apps
-developed against each.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="compilation">Compile Flags</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
-
-<p>LLVM runs much more quickly when it's optimized and assertions are removed.
-However, such a build is currently incompatible with users who build without
-defining NDEBUG, and the lack of assertions makes it hard to debug problems in
-user code. We recommend allowing users to install both optimized and debug
-versions of LLVM in parallel. The following configure flags are relevant:
-</p>
-
-<dl>
- <dt><tt>--disable-assertions</tt></dt><dd>Builds LLVM with <tt>NDEBUG</tt>
- defined. Changes the LLVM ABI. Also available by setting
- <tt>DISABLE_ASSERTIONS=0|1</tt> in <tt>make</tt>'s environment. This defaults
- to enabled regardless of the optimization setting, but it slows things
- down.</dd>
-
- <dt><tt>--enable-debug-symbols</tt></dt><dd>Builds LLVM with <tt>-g</tt>.
- Also available by setting <tt>DEBUG_SYMBOLS=0|1</tt> in <tt>make</tt>'s
- environment. This defaults to disabled when optimizing, so you should turn it
- back on to let users debug their programs.</dd>
-
- <dt><tt>--enable-optimized</tt></dt><dd>(For svn checkouts) Builds LLVM with
- <tt>-O2</tt> and, by default, turns off debug symbols. Also available by
- setting <tt>ENABLE_OPTIMIZED=0|1</tt> in <tt>make</tt>'s environment. This
- defaults to enabled when not in a checkout.</dd>
-</dl>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="cxx-features">C++ Features</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
-
-<dl>
- <dt>RTTI</dt><dd>LLVM disables RTTI by default. Add <tt>REQUIRES_RTTI=1</tt>
- to your environment while running <tt>make</tt> to re-enable it. This will
- allow users to build with RTTI enabled and still inherit from LLVM
- classes.</dd>
-</dl>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="shared-library">Shared Library</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
-
-<p>Configure with <tt>--enable-shared</tt> to build
-<tt>libLLVM-<var>major</var>.<var>minor</var>.(so|dylib)</tt> and link the tools
-against it. This saves lots of binary size at the cost of some startup time.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="deps">Dependencies</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
-
-<dl>
-<dt><tt>--enable-libffi</tt></dt><dd>Depend on <a
-href="http://sources.redhat.com/libffi/">libffi</a> to allow the LLVM
-interpreter to call external functions.</dd>
-<dt><tt>--with-oprofile</tt></dt><dd>Depend on <a
-href="http://oprofile.sourceforge.net/doc/devel/index.html">libopagent</a>
-(>=version 0.9.4) to let the LLVM JIT tell oprofile about function addresses and
-line numbers.</dd>
-</dl>
-</div>
-
-<!-- *********************************************************************** -->
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-</body>
-</html>
Removed: llvm/trunk/docs/Passes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Passes.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/Passes.html (original)
+++ llvm/trunk/docs/Passes.html (removed)
@@ -1,1770 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>LLVM's Analysis and Transform Passes</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
-</head>
-<body>
-
-<!--
-
-If Passes.html is up to date, the following "one-liner" should print
-an empty diff.
-
-egrep -e '^<tr><td><a href="#.*">-.*</a></td><td>.*</td></tr>$' \
- -e '^ <a name=".*">.*</a>$' < Passes.html >html; \
-perl >help <<'EOT' && diff -u help html; rm -f help html
-open HTML, "<Passes.html" or die "open: Passes.html: $!\n";
-while (<HTML>) {
- m:^<tr><td><a href="#(.*)">-.*</a></td><td>.*</td></tr>$: or next;
- $order{$1} = sprintf("%03d", 1 + int %order);
-}
-open HELP, "../Release/bin/opt -help|" or die "open: opt -help: $!\n";
-while (<HELP>) {
- m:^ -([^ ]+) +- (.*)$: or next;
- my $o = $order{$1};
- $o = "000" unless defined $o;
- push @x, "$o<tr><td><a href=\"#$1\">-$1</a></td><td>$2</td></tr>\n";
- push @y, "$o <a name=\"$1\">$2</a>\n";
-}
- at x = map { s/^\d\d\d//; $_ } sort @x;
- at y = map { s/^\d\d\d//; $_ } sort @y;
-print @x, @y;
-EOT
-
-This (real) one-liner can also be helpful when converting comments to HTML:
-
-perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if !$on && $_ =~ /\S/; print " </p>\n" if $on && $_ =~ /^\s*$/; print " $_\n"; $on = ($_ =~ /\S/); } print " </p>\n" if $on'
-
- -->
-
-<div class="doc_title">LLVM's Analysis and Transform Passes</div>
-
-<ol>
- <li><a href="#intro">Introduction</a></li>
- <li><a href="#analyses">Analysis Passes</a>
- <li><a href="#transforms">Transform Passes</a></li>
- <li><a href="#utilities">Utility Passes</a></li>
-</ol>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a>
- and Gordon Henriksen</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"> <a name="intro">Introduction</a> </div>
-<div class="doc_text">
- <p>This document serves as a high level summary of the optimization features
- that LLVM provides. Optimizations are implemented as Passes that traverse some
- portion of a program to either collect information or transform the program.
- The table below divides the passes that LLVM provides into three categories.
- Analysis passes compute information that other passes can use or for debugging
- or program visualization purposes. Transform passes can use (or invalidate)
- the analysis passes. Transform passes all mutate the program in some way.
- Utility passes provides some utility but don't otherwise fit categorization.
- For example passes to extract functions to bitcode or write a module to
- bitcode are neither analysis nor transform passes.
- <p>The table below provides a quick summary of each pass and links to the more
- complete pass description later in the document.</p>
-</div>
-<div class="doc_text" >
-<table>
-<tr><th colspan="2"><b>ANALYSIS PASSES</b></th></tr>
-<tr><th>Option</th><th>Name</th></tr>
-<tr><td><a href="#aa-eval">-aa-eval</a></td><td>Exhaustive Alias Analysis Precision Evaluator</td></tr>
-<tr><td><a href="#basicaa">-basicaa</a></td><td>Basic Alias Analysis (default AA impl)</td></tr>
-<tr><td><a href="#basiccg">-basiccg</a></td><td>Basic CallGraph Construction</td></tr>
-<tr><td><a href="#codegenprepare">-codegenprepare</a></td><td>Optimize for code generation</td></tr>
-<tr><td><a href="#count-aa">-count-aa</a></td><td>Count Alias Analysis Query Responses</td></tr>
-<tr><td><a href="#debug-aa">-debug-aa</a></td><td>AA use debugger</td></tr>
-<tr><td><a href="#domfrontier">-domfrontier</a></td><td>Dominance Frontier Construction</td></tr>
-<tr><td><a href="#domtree">-domtree</a></td><td>Dominator Tree Construction</td></tr>
-<tr><td><a href="#dot-callgraph">-dot-callgraph</a></td><td>Print Call Graph to 'dot' file</td></tr>
-<tr><td><a href="#dot-cfg">-dot-cfg</a></td><td>Print CFG of function to 'dot' file</td></tr>
-<tr><td><a href="#dot-cfg-only">-dot-cfg-only</a></td><td>Print CFG of function to 'dot' file (with no function bodies)</td></tr>
-<tr><td><a href="#globalsmodref-aa">-globalsmodref-aa</a></td><td>Simple mod/ref analysis for globals</td></tr>
-<tr><td><a href="#instcount">-instcount</a></td><td>Counts the various types of Instructions</td></tr>
-<tr><td><a href="#intervals">-intervals</a></td><td>Interval Partition Construction</td></tr>
-<tr><td><a href="#loops">-loops</a></td><td>Natural Loop Construction</td></tr>
-<tr><td><a href="#memdep">-memdep</a></td><td>Memory Dependence Analysis</td></tr>
-<tr><td><a href="#no-aa">-no-aa</a></td><td>No Alias Analysis (always returns 'may' alias)</td></tr>
-<tr><td><a href="#no-profile">-no-profile</a></td><td>No Profile Information</td></tr>
-<tr><td><a href="#postdomfrontier">-postdomfrontier</a></td><td>Post-Dominance Frontier Construction</td></tr>
-<tr><td><a href="#postdomtree">-postdomtree</a></td><td>Post-Dominator Tree Construction</td></tr>
-<tr><td><a href="#print-alias-sets">-print-alias-sets</a></td><td>Alias Set Printer</td></tr>
-<tr><td><a href="#print-callgraph">-print-callgraph</a></td><td>Print a call graph</td></tr>
-<tr><td><a href="#print-callgraph-sccs">-print-callgraph-sccs</a></td><td>Print SCCs of the Call Graph</td></tr>
-<tr><td><a href="#print-cfg-sccs">-print-cfg-sccs</a></td><td>Print SCCs of each function CFG</td></tr>
-<tr><td><a href="#print-externalfnconstants">-print-externalfnconstants</a></td><td>Print external fn callsites passed constants</td></tr>
-<tr><td><a href="#print-function">-print-function</a></td><td>Print function to stderr</td></tr>
-<tr><td><a href="#print-module">-print-module</a></td><td>Print module to stderr</td></tr>
-<tr><td><a href="#print-used-types">-print-used-types</a></td><td>Find Used Types</td></tr>
-<tr><td><a href="#profile-loader">-profile-loader</a></td><td>Load profile information from llvmprof.out</td></tr>
-<tr><td><a href="#scalar-evolution">-scalar-evolution</a></td><td>Scalar Evolution Analysis</td></tr>
-<tr><td><a href="#targetdata">-targetdata</a></td><td>Target Data Layout</td></tr>
-
-
-<tr><th colspan="2"><b>TRANSFORM PASSES</b></th></tr>
-<tr><th>Option</th><th>Name</th></tr>
-<tr><td><a href="#adce">-adce</a></td><td>Aggressive Dead Code Elimination</td></tr>
-<tr><td><a href="#argpromotion">-argpromotion</a></td><td>Promote 'by reference' arguments to scalars</td></tr>
-<tr><td><a href="#block-placement">-block-placement</a></td><td>Profile Guided Basic Block Placement</td></tr>
-<tr><td><a href="#break-crit-edges">-break-crit-edges</a></td><td>Break critical edges in CFG</td></tr>
-<tr><td><a href="#codegenprepare">-codegenprepare</a></td><td>Prepare a function for code generation </td></tr>
-<tr><td><a href="#constmerge">-constmerge</a></td><td>Merge Duplicate Global Constants</td></tr>
-<tr><td><a href="#constprop">-constprop</a></td><td>Simple constant propagation</td></tr>
-<tr><td><a href="#dce">-dce</a></td><td>Dead Code Elimination</td></tr>
-<tr><td><a href="#deadargelim">-deadargelim</a></td><td>Dead Argument Elimination</td></tr>
-<tr><td><a href="#deadtypeelim">-deadtypeelim</a></td><td>Dead Type Elimination</td></tr>
-<tr><td><a href="#die">-die</a></td><td>Dead Instruction Elimination</td></tr>
-<tr><td><a href="#dse">-dse</a></td><td>Dead Store Elimination</td></tr>
-<tr><td><a href="#globaldce">-globaldce</a></td><td>Dead Global Elimination</td></tr>
-<tr><td><a href="#globalopt">-globalopt</a></td><td>Global Variable Optimizer</td></tr>
-<tr><td><a href="#gvn">-gvn</a></td><td>Global Value Numbering</td></tr>
-<tr><td><a href="#indmemrem">-indmemrem</a></td><td>Indirect Malloc and Free Removal</td></tr>
-<tr><td><a href="#indvars">-indvars</a></td><td>Canonicalize Induction Variables</td></tr>
-<tr><td><a href="#inline">-inline</a></td><td>Function Integration/Inlining</td></tr>
-<tr><td><a href="#insert-block-profiling">-insert-block-profiling</a></td><td>Insert instrumentation for block profiling</td></tr>
-<tr><td><a href="#insert-edge-profiling">-insert-edge-profiling</a></td><td>Insert instrumentation for edge profiling</td></tr>
-<tr><td><a href="#insert-function-profiling">-insert-function-profiling</a></td><td>Insert instrumentation for function profiling</td></tr>
-<tr><td><a href="#insert-null-profiling-rs">-insert-null-profiling-rs</a></td><td>Measure profiling framework overhead</td></tr>
-<tr><td><a href="#insert-rs-profiling-framework">-insert-rs-profiling-framework</a></td><td>Insert random sampling instrumentation framework</td></tr>
-<tr><td><a href="#instcombine">-instcombine</a></td><td>Combine redundant instructions</td></tr>
-<tr><td><a href="#internalize">-internalize</a></td><td>Internalize Global Symbols</td></tr>
-<tr><td><a href="#ipconstprop">-ipconstprop</a></td><td>Interprocedural constant propagation</td></tr>
-<tr><td><a href="#ipsccp">-ipsccp</a></td><td>Interprocedural Sparse Conditional Constant Propagation</td></tr>
-<tr><td><a href="#jump-threading">-jump-threading</a></td><td>Thread control through conditional blocks </td></tr>
-<tr><td><a href="#lcssa">-lcssa</a></td><td>Loop-Closed SSA Form Pass</td></tr>
-<tr><td><a href="#licm">-licm</a></td><td>Loop Invariant Code Motion</td></tr>
-<tr><td><a href="#loop-deletion">-loop-deletion</a></td><td>Dead Loop Deletion Pass </td></tr>
-<tr><td><a href="#loop-extract">-loop-extract</a></td><td>Extract loops into new functions</td></tr>
-<tr><td><a href="#loop-extract-single">-loop-extract-single</a></td><td>Extract at most one loop into a new function</td></tr>
-<tr><td><a href="#loop-index-split">-loop-index-split</a></td><td>Index Split Loops</td></tr>
-<tr><td><a href="#loop-reduce">-loop-reduce</a></td><td>Loop Strength Reduction</td></tr>
-<tr><td><a href="#loop-rotate">-loop-rotate</a></td><td>Rotate Loops</td></tr>
-<tr><td><a href="#loop-unroll">-loop-unroll</a></td><td>Unroll loops</td></tr>
-<tr><td><a href="#loop-unswitch">-loop-unswitch</a></td><td>Unswitch loops</td></tr>
-<tr><td><a href="#loopsimplify">-loopsimplify</a></td><td>Canonicalize natural loops</td></tr>
-<tr><td><a href="#lowerallocs">-lowerallocs</a></td><td>Lower allocations from instructions to calls</td></tr>
-<tr><td><a href="#lowerinvoke">-lowerinvoke</a></td><td>Lower invoke and unwind, for unwindless code generators</td></tr>
-<tr><td><a href="#lowersetjmp">-lowersetjmp</a></td><td>Lower Set Jump</td></tr>
-<tr><td><a href="#lowerswitch">-lowerswitch</a></td><td>Lower SwitchInst's to branches</td></tr>
-<tr><td><a href="#mem2reg">-mem2reg</a></td><td>Promote Memory to Register</td></tr>
-<tr><td><a href="#memcpyopt">-memcpyopt</a></td><td>Optimize use of memcpy and friends</td></tr>
-<tr><td><a href="#mergereturn">-mergereturn</a></td><td>Unify function exit nodes</td></tr>
-<tr><td><a href="#prune-eh">-prune-eh</a></td><td>Remove unused exception handling info</td></tr>
-<tr><td><a href="#reassociate">-reassociate</a></td><td>Reassociate expressions</td></tr>
-<tr><td><a href="#reg2mem">-reg2mem</a></td><td>Demote all values to stack slots</td></tr>
-<tr><td><a href="#scalarrepl">-scalarrepl</a></td><td>Scalar Replacement of Aggregates</td></tr>
-<tr><td><a href="#sccp">-sccp</a></td><td>Sparse Conditional Constant Propagation</td></tr>
-<tr><td><a href="#simplify-libcalls">-simplify-libcalls</a></td><td>Simplify well-known library calls</td></tr>
-<tr><td><a href="#simplifycfg">-simplifycfg</a></td><td>Simplify the CFG</td></tr>
-<tr><td><a href="#strip">-strip</a></td><td>Strip all symbols from a module</td></tr>
-<tr><td><a href="#strip-dead-prototypes">-strip-dead-prototypes</a></td><td>Remove unused function declarations</td></tr>
-<tr><td><a href="#sretpromotion">-sretpromotion</a></td><td>Promote sret arguments</td></tr>
-<tr><td><a href="#tailcallelim">-tailcallelim</a></td><td>Tail Call Elimination</td></tr>
-<tr><td><a href="#tailduplicate">-tailduplicate</a></td><td>Tail Duplication</td></tr>
-
-
-<tr><th colspan="2"><b>UTILITY PASSES</b></th></tr>
-<tr><th>Option</th><th>Name</th></tr>
-<tr><td><a href="#deadarghaX0r">-deadarghaX0r</a></td><td>Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)</td></tr>
-<tr><td><a href="#extract-blocks">-extract-blocks</a></td><td>Extract Basic Blocks From Module (for bugpoint use)</td></tr>
-<tr><td><a href="#preverify">-preverify</a></td><td>Preliminary module verification</td></tr>
-<tr><td><a href="#verify">-verify</a></td><td>Module Verifier</td></tr>
-<tr><td><a href="#view-cfg">-view-cfg</a></td><td>View CFG of function</td></tr>
-<tr><td><a href="#view-cfg-only">-view-cfg-only</a></td><td>View CFG of function (with no function bodies)</td></tr>
-</table>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"> <a name="example">Analysis Passes</a></div>
-<div class="doc_text">
- <p>This section describes the LLVM Analysis Passes.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="aa-eval">Exhaustive Alias Analysis Precision Evaluator</a>
-</div>
-<div class="doc_text">
- <p>This is a simple N^2 alias analysis accuracy evaluator.
- Basically, for each function in the program, it simply queries to see how the
- alias analysis implementation answers alias queries between each pair of
- pointers in the function.</p>
-
- <p>This is inspired and adapted from code by: Naveen Neelakantam, Francesco
- Spadini, and Wojciech Stryjewski.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="basicaa">Basic Alias Analysis (default AA impl)</a>
-</div>
-<div class="doc_text">
- <p>
- This is the default implementation of the Alias Analysis interface
- that simply implements a few identities (two different globals cannot alias,
- etc), but otherwise does no analysis.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="basiccg">Basic CallGraph Construction</a>
-</div>
-<div class="doc_text">
- <p>Yet to be written.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="codegenprepare">Optimize for code generation</a>
-</div>
-<div class="doc_text">
- <p>
- This pass munges the code in the input function to better prepare it for
- SelectionDAG-based code generation. This works around limitations in it's
- basic-block-at-a-time approach. It should eventually be removed.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="count-aa">Count Alias Analysis Query Responses</a>
-</div>
-<div class="doc_text">
- <p>
- A pass which can be used to count how many alias queries
- are being made and how the alias analysis implementation being used responds.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="debug-aa">AA use debugger</a>
-</div>
-<div class="doc_text">
- <p>
- This simple pass checks alias analysis users to ensure that if they
- create a new value, they do not query AA without informing it of the value.
- It acts as a shim over any other AA pass you want.
- </p>
-
- <p>
- Yes keeping track of every value in the program is expensive, but this is
- a debugging pass.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="domfrontier">Dominance Frontier Construction</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is a simple dominator construction algorithm for finding forward
- dominator frontiers.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="domtree">Dominator Tree Construction</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is a simple dominator construction algorithm for finding forward
- dominators.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="dot-callgraph">Print Call Graph to 'dot' file</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints the call graph into a
- <code>.dot</code> graph. This graph can then be processed with the "dot" tool
- to convert it to postscript or some other suitable format.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="dot-cfg">Print CFG of function to 'dot' file</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints the control flow graph
- into a <code>.dot</code> graph. This graph can then be processed with the
- "dot" tool to convert it to postscript or some other suitable format.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="dot-cfg-only">Print CFG of function to 'dot' file (with no function bodies)</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints the control flow graph
- into a <code>.dot</code> graph, omitting the function bodies. This graph can
- then be processed with the "dot" tool to convert it to postscript or some
- other suitable format.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="globalsmodref-aa">Simple mod/ref analysis for globals</a>
-</div>
-<div class="doc_text">
- <p>
- This simple pass provides alias and mod/ref information for global values
- that do not have their address taken, and keeps track of whether functions
- read or write memory (are "pure"). For this simple (but very common) case,
- we can provide pretty accurate and useful information.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="instcount">Counts the various types of Instructions</a>
-</div>
-<div class="doc_text">
- <p>
- This pass collects the count of all instructions and reports them
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="intervals">Interval Partition Construction</a>
-</div>
-<div class="doc_text">
- <p>
- This analysis calculates and represents the interval partition of a function,
- or a preexisting interval partition.
- </p>
-
- <p>
- In this way, the interval partition may be used to reduce a flow graph down
- to its degenerate single node interval partition (unless it is irreducible).
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loops">Natural Loop Construction</a>
-</div>
-<div class="doc_text">
- <p>
- This analysis is used to identify natural loops and determine the loop depth
- of various nodes of the CFG. Note that the loops identified may actually be
- several natural loops that share the same header node... not just a single
- natural loop.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="memdep">Memory Dependence Analysis</a>
-</div>
-<div class="doc_text">
- <p>
- An analysis that determines, for a given memory operation, what preceding
- memory operations it depends on. It builds on alias analysis information, and
- tries to provide a lazy, caching interface to a common kind of alias
- information query.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="no-aa">No Alias Analysis (always returns 'may' alias)</a>
-</div>
-<div class="doc_text">
- <p>
- Always returns "I don't know" for alias queries. NoAA is unlike other alias
- analysis implementations, in that it does not chain to a previous analysis. As
- such it doesn't follow many of the rules that other alias analyses must.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="no-profile">No Profile Information</a>
-</div>
-<div class="doc_text">
- <p>
- The default "no profile" implementation of the abstract
- <code>ProfileInfo</code> interface.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="postdomfrontier">Post-Dominance Frontier Construction</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is a simple post-dominator construction algorithm for finding
- post-dominator frontiers.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="postdomtree">Post-Dominator Tree Construction</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is a simple post-dominator construction algorithm for finding
- post-dominators.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-alias-sets">Alias Set Printer</a>
-</div>
-<div class="doc_text">
- <p>Yet to be written.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-callgraph">Print a call graph</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints the call graph to
- standard output in a human-readable form.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-callgraph-sccs">Print SCCs of the Call Graph</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints the SCCs of the call
- graph to standard output in a human-readable form.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-cfg-sccs">Print SCCs of each function CFG</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints the SCCs of each
- function CFG to standard output in a human-readable form.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-externalfnconstants">Print external fn callsites passed constants</a>
-</div>
-<div class="doc_text">
- <p>
- This pass, only available in <code>opt</code>, prints out call sites to
- external functions that are called with constant arguments. This can be
- useful when looking for standard library functions we should constant fold
- or handle in alias analyses.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-function">Print function to stderr</a>
-</div>
-<div class="doc_text">
- <p>
- The <code>PrintFunctionPass</code> class is designed to be pipelined with
- other <code>FunctionPass</code>es, and prints out the functions of the module
- as they are processed.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-module">Print module to stderr</a>
-</div>
-<div class="doc_text">
- <p>
- This pass simply prints out the entire module when it is executed.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="print-used-types">Find Used Types</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is used to seek out all of the types in use by the program. Note
- that this analysis explicitly does not include types only used by the symbol
- table.
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="profile-loader">Load profile information from llvmprof.out</a>
-</div>
-<div class="doc_text">
- <p>
- A concrete implementation of profiling information that loads the information
- from a profile dump file.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="scalar-evolution">Scalar Evolution Analysis</a>
-</div>
-<div class="doc_text">
- <p>
- The <code>ScalarEvolution</code> analysis can be used to analyze and
- catagorize scalar expressions in loops. It specializes in recognizing general
- induction variables, representing them with the abstract and opaque
- <code>SCEV</code> class. Given this analysis, trip counts of loops and other
- important properties can be obtained.
- </p>
-
- <p>
- This analysis is primarily useful for induction variable substitution and
- strength reduction.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="targetdata">Target Data Layout</a>
-</div>
-<div class="doc_text">
- <p>Provides other passes access to information on how the size and alignment
- required by the the target ABI for various data types.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"> <a name="transform">Transform Passes</a></div>
-<div class="doc_text">
- <p>This section describes the LLVM Transform Passes.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="adce">Aggressive Dead Code Elimination</a>
-</div>
-<div class="doc_text">
- <p>ADCE aggressively tries to eliminate code. This pass is similar to
- <a href="#dce">DCE</a> but it assumes that values are dead until proven
- otherwise. This is similar to <a href="#sccp">SCCP</a>, except applied to
- the liveness of values.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="argpromotion">Promote 'by reference' arguments to scalars</a>
-</div>
-<div class="doc_text">
- <p>
- This pass promotes "by reference" arguments to be "by value" arguments. In
- practice, this means looking for internal functions that have pointer
- arguments. If it can prove, through the use of alias analysis, that an
- argument is *only* loaded, then it can pass the value into the function
- instead of the address of the value. This can cause recursive simplification
- of code and lead to the elimination of allocas (especially in C++ template
- code like the STL).
- </p>
-
- <p>
- This pass also handles aggregate arguments that are passed into a function,
- scalarizing them if the elements of the aggregate are only loaded. Note that
- it refuses to scalarize aggregates which would require passing in more than
- three operands to the function, because passing thousands of operands for a
- large array or structure is unprofitable!
- </p>
-
- <p>
- Note that this transformation could also be done for arguments that are only
- stored to (returning the value instead), but does not currently. This case
- would be best handled when and if LLVM starts supporting multiple return
- values from functions.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="block-placement">Profile Guided Basic Block Placement</a>
-</div>
-<div class="doc_text">
- <p>This pass is a very simple profile guided basic block placement algorithm.
- The idea is to put frequently executed blocks together at the start of the
- function and hopefully increase the number of fall-through conditional
- branches. If there is no profile information for a particular function, this
- pass basically orders blocks in depth-first order.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="break-crit-edges">Break critical edges in CFG</a>
-</div>
-<div class="doc_text">
- <p>
- Break all of the critical edges in the CFG by inserting a dummy basic block.
- It may be "required" by passes that cannot deal with critical edges. This
- transformation obviously invalidates the CFG, but can update forward dominator
- (set, immediate dominators, tree, and frontier) information.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="codegenprepare">Prepare a function for code generation</a>
-</div>
-<div class="doc_text">
- This pass munges the code in the input function to better prepare it for
- SelectionDAG-based code generation. This works around limitations in it's
- basic-block-at-a-time approach. It should eventually be removed.
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="constmerge">Merge Duplicate Global Constants</a>
-</div>
-<div class="doc_text">
- <p>
- Merges duplicate global constants together into a single constant that is
- shared. This is useful because some passes (ie TraceValues) insert a lot of
- string constants into the program, regardless of whether or not an existing
- string is available.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="constprop">Simple constant propagation</a>
-</div>
-<div class="doc_text">
- <p>This file implements constant propagation and merging. It looks for
- instructions involving only constant operands and replaces them with a
- constant value instead of an instruction. For example:</p>
- <blockquote><pre>add i32 1, 2</pre></blockquote>
- <p>becomes</p>
- <blockquote><pre>i32 3</pre></blockquote>
- <p>NOTE: this pass has a habit of making definitions be dead. It is a good
- idea to to run a <a href="#die">DIE</a> (Dead Instruction Elimination) pass
- sometime after running this pass.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="dce">Dead Code Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- Dead code elimination is similar to <a href="#die">dead instruction
- elimination</a>, but it rechecks instructions that were used by removed
- instructions to see if they are newly dead.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="deadargelim">Dead Argument Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- This pass deletes dead arguments from internal functions. Dead argument
- elimination removes arguments which are directly dead, as well as arguments
- only passed into function calls as dead arguments of other functions. This
- pass also deletes dead arguments in a similar way.
- </p>
-
- <p>
- This pass is often useful as a cleanup pass to run after aggressive
- interprocedural passes, which add possibly-dead arguments.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="deadtypeelim">Dead Type Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is used to cleanup the output of GCC. It eliminate names for types
- that are unused in the entire translation unit, using the <a
- href="#findusedtypes">find used types</a> pass.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="die">Dead Instruction Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- Dead instruction elimination performs a single pass over the function,
- removing instructions that are obviously dead.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="dse">Dead Store Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- A trivial dead store elimination that only considers basic-block local
- redundant stores.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="globaldce">Dead Global Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- This transform is designed to eliminate unreachable internal globals from the
- program. It uses an aggressive algorithm, searching out globals that are
- known to be alive. After it finds all of the globals which are needed, it
- deletes whatever is left over. This allows it to delete recursive chunks of
- the program which are unreachable.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="globalopt">Global Variable Optimizer</a>
-</div>
-<div class="doc_text">
- <p>
- This pass transforms simple global variables that never have their address
- taken. If obviously true, it marks read/write globals as constant, deletes
- variables only stored to, etc.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="gvn">Global Value Numbering</a>
-</div>
-<div class="doc_text">
- <p>
- This pass performs global value numbering to eliminate fully and partially
- redundant instructions. It also performs redundant load elimination.
- </p>
-</div>
-
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="indmemrem">Indirect Malloc and Free Removal</a>
-</div>
-<div class="doc_text">
- <p>
- This pass finds places where memory allocation functions may escape into
- indirect land. Some transforms are much easier (aka possible) only if free
- or malloc are not called indirectly.
- </p>
-
- <p>
- Thus find places where the address of memory functions are taken and construct
- bounce functions with direct calls of those functions.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="indvars">Canonicalize Induction Variables</a>
-</div>
-<div class="doc_text">
- <p>
- This transformation analyzes and transforms the induction variables (and
- computations derived from them) into simpler forms suitable for subsequent
- analysis and transformation.
- </p>
-
- <p>
- This transformation makes the following changes to each loop with an
- identifiable induction variable:
- </p>
-
- <ol>
- <li>All loops are transformed to have a <em>single</em> canonical
- induction variable which starts at zero and steps by one.</li>
- <li>The canonical induction variable is guaranteed to be the first PHI node
- in the loop header block.</li>
- <li>Any pointer arithmetic recurrences are raised to use array
- subscripts.</li>
- </ol>
-
- <p>
- If the trip count of a loop is computable, this pass also makes the following
- changes:
- </p>
-
- <ol>
- <li>The exit condition for the loop is canonicalized to compare the
- induction value against the exit value. This turns loops like:
- <blockquote><pre>for (i = 7; i*i < 1000; ++i)</pre></blockquote>
- into
- <blockquote><pre>for (i = 0; i != 25; ++i)</pre></blockquote></li>
- <li>Any use outside of the loop of an expression derived from the indvar
- is changed to compute the derived value outside of the loop, eliminating
- the dependence on the exit value of the induction variable. If the only
- purpose of the loop is to compute the exit value of some derived
- expression, this transformation will make the loop dead.</li>
- </ol>
-
- <p>
- This transformation should be followed by strength reduction after all of the
- desired loop transformations have been performed. Additionally, on targets
- where it is profitable, the loop could be transformed to count down to zero
- (the "do loop" optimization).
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="inline">Function Integration/Inlining</a>
-</div>
-<div class="doc_text">
- <p>
- Bottom-up inlining of functions into callees.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="insert-block-profiling">Insert instrumentation for block profiling</a>
-</div>
-<div class="doc_text">
- <p>
- This pass instruments the specified program with counters for basic block
- profiling, which counts the number of times each basic block executes. This
- is the most basic form of profiling, which can tell which blocks are hot, but
- cannot reliably detect hot paths through the CFG.
- </p>
-
- <p>
- Note that this implementation is very naïve. Control equivalent regions of
- the CFG should not require duplicate counters, but it does put duplicate
- counters in.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="insert-edge-profiling">Insert instrumentation for edge profiling</a>
-</div>
-<div class="doc_text">
- <p>
- This pass instruments the specified program with counters for edge profiling.
- Edge profiling can give a reasonable approximation of the hot paths through a
- program, and is used for a wide variety of program transformations.
- </p>
-
- <p>
- Note that this implementation is very naïve. It inserts a counter for
- <em>every</em> edge in the program, instead of using control flow information
- to prune the number of counters inserted.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="insert-function-profiling">Insert instrumentation for function profiling</a>
-</div>
-<div class="doc_text">
- <p>
- This pass instruments the specified program with counters for function
- profiling, which counts the number of times each function is called.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="insert-null-profiling-rs">Measure profiling framework overhead</a>
-</div>
-<div class="doc_text">
- <p>
- The basic profiler that does nothing. It is the default profiler and thus
- terminates <code>RSProfiler</code> chains. It is useful for measuring
- framework overhead.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="insert-rs-profiling-framework">Insert random sampling instrumentation framework</a>
-</div>
-<div class="doc_text">
- <p>
- The second stage of the random-sampling instrumentation framework, duplicates
- all instructions in a function, ignoring the profiling code, then connects the
- two versions together at the entry and at backedges. At each connection point
- a choice is made as to whether to jump to the profiled code (take a sample) or
- execute the unprofiled code.
- </p>
-
- <p>
- After this pass, it is highly recommended to run<a href="#mem2reg">mem2reg</a>
- and <a href="#adce">adce</a>. <a href="#instcombine">instcombine</a>,
- <a href="#load-vn">load-vn</a>, <a href="#gdce">gdce</a>, and
- <a href="#dse">dse</a> also are good to run afterwards.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="instcombine">Combine redundant instructions</a>
-</div>
-<div class="doc_text">
- <p>
- Combine instructions to form fewer, simple
- instructions. This pass does not modify the CFG This pass is where algebraic
- simplification happens.
- </p>
-
- <p>
- This pass combines things like:
- </p>
-
-<blockquote><pre
->%Y = add i32 %X, 1
-%Z = add i32 %Y, 1</pre></blockquote>
-
- <p>
- into:
- </p>
-
-<blockquote><pre
->%Z = add i32 %X, 2</pre></blockquote>
-
- <p>
- This is a simple worklist driven algorithm.
- </p>
-
- <p>
- This pass guarantees that the following canonicalizations are performed on
- the program:
- </p>
-
- <ul>
- <li>If a binary operator has a constant operand, it is moved to the right-
- hand side.</li>
- <li>Bitwise operators with constant operands are always grouped so that
- shifts are performed first, then <code>or</code>s, then
- <code>and</code>s, then <code>xor</code>s.</li>
- <li>Compare instructions are converted from <code><</code>,
- <code>></code>, <code>≤</code>, or <code>≥</code> to
- <code>=</code> or <code>≠</code> if possible.</li>
- <li>All <code>cmp</code> instructions on boolean values are replaced with
- logical operations.</li>
- <li><code>add <var>X</var>, <var>X</var></code> is represented as
- <code>mul <var>X</var>, 2</code> ⇒ <code>shl <var>X</var>, 1</code></li>
- <li>Multiplies with a constant power-of-two argument are transformed into
- shifts.</li>
- <li>… etc.</li>
- </ul>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="internalize">Internalize Global Symbols</a>
-</div>
-<div class="doc_text">
- <p>
- This pass loops over all of the functions in the input module, looking for a
- main function. If a main function is found, all other functions and all
- global variables with initializers are marked as internal.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="ipconstprop">Interprocedural constant propagation</a>
-</div>
-<div class="doc_text">
- <p>
- This pass implements an <em>extremely</em> simple interprocedural constant
- propagation pass. It could certainly be improved in many different ways,
- like using a worklist. This pass makes arguments dead, but does not remove
- them. The existing dead argument elimination pass should be run after this
- to clean up the mess.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="ipsccp">Interprocedural Sparse Conditional Constant Propagation</a>
-</div>
-<div class="doc_text">
- <p>
- An interprocedural variant of <a href="#sccp">Sparse Conditional Constant
- Propagation</a>.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="jump-threading">Thread control through conditional blocks</a>
-</div>
-<div class="doc_text">
- <p>
- Jump threading tries to find distinct threads of control flow running through
- a basic block. This pass looks at blocks that have multiple predecessors and
- multiple successors. If one or more of the predecessors of the block can be
- proven to always cause a jump to one of the successors, we forward the edge
- from the predecessor to the successor by duplicating the contents of this
- block.
- </p>
- <p>
- An example of when this can occur is code like this:
- </p>
-
- <pre
->if () { ...
- X = 4;
-}
-if (X < 3) {</pre>
-
- <p>
- In this case, the unconditional branch at the end of the first if can be
- revectored to the false side of the second if.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="lcssa">Loop-Closed SSA Form Pass</a>
-</div>
-<div class="doc_text">
- <p>
- This pass transforms loops by placing phi nodes at the end of the loops for
- all values that are live across the loop boundary. For example, it turns
- the left into the right code:
- </p>
-
- <pre
->for (...) for (...)
- if (c) if (c)
- X1 = ... X1 = ...
- else else
- X2 = ... X2 = ...
- X3 = phi(X1, X2) X3 = phi(X1, X2)
-... = X3 + 4 X4 = phi(X3)
- ... = X4 + 4</pre>
-
- <p>
- This is still valid LLVM; the extra phi nodes are purely redundant, and will
- be trivially eliminated by <code>InstCombine</code>. The major benefit of
- this transformation is that it makes many other loop optimizations, such as
- LoopUnswitching, simpler.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="licm">Loop Invariant Code Motion</a>
-</div>
-<div class="doc_text">
- <p>
- This pass performs loop invariant code motion, attempting to remove as much
- code from the body of a loop as possible. It does this by either hoisting
- code into the preheader block, or by sinking code to the exit blocks if it is
- safe. This pass also promotes must-aliased memory locations in the loop to
- live in registers, thus hoisting and sinking "invariant" loads and stores.
- </p>
-
- <p>
- This pass uses alias analysis for two purposes:
- </p>
-
- <ul>
- <li>Moving loop invariant loads and calls out of loops. If we can determine
- that a load or call inside of a loop never aliases anything stored to,
- we can hoist it or sink it like any other instruction.</li>
- <li>Scalar Promotion of Memory - If there is a store instruction inside of
- the loop, we try to move the store to happen AFTER the loop instead of
- inside of the loop. This can only happen if a few conditions are true:
- <ul>
- <li>The pointer stored through is loop invariant.</li>
- <li>There are no stores or loads in the loop which <em>may</em> alias
- the pointer. There are no calls in the loop which mod/ref the
- pointer.</li>
- </ul>
- If these conditions are true, we can promote the loads and stores in the
- loop of the pointer to use a temporary alloca'd variable. We then use
- the mem2reg functionality to construct the appropriate SSA form for the
- variable.</li>
- </ul>
-</div>
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-deletion">Dead Loop Deletion Pass</a>
-</div>
-<div class="doc_text">
- <p>
- This file implements the Dead Loop Deletion Pass. This pass is responsible
- for eliminating loops with non-infinite computable trip counts that have no
- side effects or volatile instructions, and do not contribute to the
- computation of the function's return value.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-extract">Extract loops into new functions</a>
-</div>
-<div class="doc_text">
- <p>
- A pass wrapper around the <code>ExtractLoop()</code> scalar transformation to
- extract each top-level loop into its own new function. If the loop is the
- <em>only</em> loop in a given function, it is not touched. This is a pass most
- useful for debugging via bugpoint.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-extract-single">Extract at most one loop into a new function</a>
-</div>
-<div class="doc_text">
- <p>
- Similar to <a href="#loop-extract">Extract loops into new functions</a>,
- this pass extracts one natural loop from the program into a function if it
- can. This is used by bugpoint.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-index-split">Index Split Loops</a>
-</div>
-<div class="doc_text">
- <p>
- This pass divides loop's iteration range by spliting loop such that each
- individual loop is executed efficiently.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-reduce">Loop Strength Reduction</a>
-</div>
-<div class="doc_text">
- <p>
- This pass performs a strength reduction on array references inside loops that
- have as one or more of their components the loop induction variable. This is
- accomplished by creating a new value to hold the initial value of the array
- access for the first iteration, and then creating a new GEP instruction in
- the loop to increment the value by the appropriate amount.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-rotate">Rotate Loops</a>
-</div>
-<div class="doc_text">
- <p>A simple loop rotation transformation.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-unroll">Unroll loops</a>
-</div>
-<div class="doc_text">
- <p>
- This pass implements a simple loop unroller. It works best when loops have
- been canonicalized by the <a href="#indvars"><tt>-indvars</tt></a> pass,
- allowing it to determine the trip counts of loops easily.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loop-unswitch">Unswitch loops</a>
-</div>
-<div class="doc_text">
- <p>
- This pass transforms loops that contain branches on loop-invariant conditions
- to have multiple loops. For example, it turns the left into the right code:
- </p>
-
- <pre
->for (...) if (lic)
- A for (...)
- if (lic) A; B; C
- B else
- C for (...)
- A; C</pre>
-
- <p>
- This can increase the size of the code exponentially (doubling it every time
- a loop is unswitched) so we only unswitch if the resultant code will be
- smaller than a threshold.
- </p>
-
- <p>
- This pass expects LICM to be run before it to hoist invariant conditions out
- of the loop, to make the unswitching opportunity obvious.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="loopsimplify">Canonicalize natural loops</a>
-</div>
-<div class="doc_text">
- <p>
- This pass performs several transformations to transform natural loops into a
- simpler form, which makes subsequent analyses and transformations simpler and
- more effective.
- </p>
-
- <p>
- Loop pre-header insertion guarantees that there is a single, non-critical
- entry edge from outside of the loop to the loop header. This simplifies a
- number of analyses and transformations, such as LICM.
- </p>
-
- <p>
- Loop exit-block insertion guarantees that all exit blocks from the loop
- (blocks which are outside of the loop that have predecessors inside of the
- loop) only have predecessors from inside of the loop (and are thus dominated
- by the loop header). This simplifies transformations such as store-sinking
- that are built into LICM.
- </p>
-
- <p>
- This pass also guarantees that loops will have exactly one backedge.
- </p>
-
- <p>
- Note that the simplifycfg pass will clean up blocks which are split out but
- end up being unnecessary, so usage of this pass should not pessimize
- generated code.
- </p>
-
- <p>
- This pass obviously modifies the CFG, but updates loop information and
- dominator information.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="lowerallocs">Lower allocations from instructions to calls</a>
-</div>
-<div class="doc_text">
- <p>
- Turn <tt>malloc</tt> and <tt>free</tt> instructions into <tt>@malloc</tt> and
- <tt>@free</tt> calls.
- </p>
-
- <p>
- This is a target-dependent tranformation because it depends on the size of
- data types and alignment constraints.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="lowerinvoke">Lower invoke and unwind, for unwindless code generators</a>
-</div>
-<div class="doc_text">
- <p>
- This transformation is designed for use by code generators which do not yet
- support stack unwinding. This pass supports two models of exception handling
- lowering, the 'cheap' support and the 'expensive' support.
- </p>
-
- <p>
- 'Cheap' exception handling support gives the program the ability to execute
- any program which does not "throw an exception", by turning 'invoke'
- instructions into calls and by turning 'unwind' instructions into calls to
- abort(). If the program does dynamically use the unwind instruction, the
- program will print a message then abort.
- </p>
-
- <p>
- 'Expensive' exception handling support gives the full exception handling
- support to the program at the cost of making the 'invoke' instruction
- really expensive. It basically inserts setjmp/longjmp calls to emulate the
- exception handling as necessary.
- </p>
-
- <p>
- Because the 'expensive' support slows down programs a lot, and EH is only
- used for a subset of the programs, it must be specifically enabled by the
- <tt>-enable-correct-eh-support</tt> option.
- </p>
-
- <p>
- Note that after this pass runs the CFG is not entirely accurate (exceptional
- control flow edges are not correct anymore) so only very simple things should
- be done after the lowerinvoke pass has run (like generation of native code).
- This should not be used as a general purpose "my LLVM-to-LLVM pass doesn't
- support the invoke instruction yet" lowering pass.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="lowersetjmp">Lower Set Jump</a>
-</div>
-<div class="doc_text">
- <p>
- Lowers <tt>setjmp</tt> and <tt>longjmp</tt> to use the LLVM invoke and unwind
- instructions as necessary.
- </p>
-
- <p>
- Lowering of <tt>longjmp</tt> is fairly trivial. We replace the call with a
- call to the LLVM library function <tt>__llvm_sjljeh_throw_longjmp()</tt>.
- This unwinds the stack for us calling all of the destructors for
- objects allocated on the stack.
- </p>
-
- <p>
- At a <tt>setjmp</tt> call, the basic block is split and the <tt>setjmp</tt>
- removed. The calls in a function that have a <tt>setjmp</tt> are converted to
- invoke where the except part checks to see if it's a <tt>longjmp</tt>
- exception and, if so, if it's handled in the function. If it is, then it gets
- the value returned by the <tt>longjmp</tt> and goes to where the basic block
- was split. <tt>invoke</tt> instructions are handled in a similar fashion with
- the original except block being executed if it isn't a <tt>longjmp</tt>
- except that is handled by that function.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="lowerswitch">Lower SwitchInst's to branches</a>
-</div>
-<div class="doc_text">
- <p>
- Rewrites <tt>switch</tt> instructions with a sequence of branches, which
- allows targets to get away with not implementing the switch instruction until
- it is convenient.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="mem2reg">Promote Memory to Register</a>
-</div>
-<div class="doc_text">
- <p>
- This file promotes memory references to be register references. It promotes
- <tt>alloca</tt> instructions which only have <tt>load</tt>s and
- <tt>store</tt>s as uses. An <tt>alloca</tt> is transformed by using dominator
- frontiers to place <tt>phi</tt> nodes, then traversing the function in
- depth-first order to rewrite <tt>load</tt>s and <tt>store</tt>s as
- appropriate. This is just the standard SSA construction algorithm to construct
- "pruned" SSA form.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="memcpyopt">Optimize use of memcpy and friend</a>
-</div>
-<div class="doc_text">
- <p>
- This pass performs various transformations related to eliminating memcpy
- calls, or transforming sets of stores into memset's.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="mergereturn">Unify function exit nodes</a>
-</div>
-<div class="doc_text">
- <p>
- Ensure that functions have at most one <tt>ret</tt> instruction in them.
- Additionally, it keeps track of which node is the new exit node of the CFG.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="prune-eh">Remove unused exception handling info</a>
-</div>
-<div class="doc_text">
- <p>
- This file implements a simple interprocedural pass which walks the call-graph,
- turning <tt>invoke</tt> instructions into <tt>call</tt> instructions if and
- only if the callee cannot throw an exception. It implements this as a
- bottom-up traversal of the call-graph.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="reassociate">Reassociate expressions</a>
-</div>
-<div class="doc_text">
- <p>
- This pass reassociates commutative expressions in an order that is designed
- to promote better constant propagation, GCSE, LICM, PRE, etc.
- </p>
-
- <p>
- For example: 4 + (<var>x</var> + 5) ⇒ <var>x</var> + (4 + 5)
- </p>
-
- <p>
- In the implementation of this algorithm, constants are assigned rank = 0,
- function arguments are rank = 1, and other values are assigned ranks
- corresponding to the reverse post order traversal of current function
- (starting at 2), which effectively gives values in deep loops higher rank
- than values not in loops.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="reg2mem">Demote all values to stack slots</a>
-</div>
-<div class="doc_text">
- <p>
- This file demotes all registers to memory references. It is intented to be
- the inverse of <a href="#mem2reg"><tt>-mem2reg</tt></a>. By converting to
- <tt>load</tt> instructions, the only values live across basic blocks are
- <tt>alloca</tt> instructions and <tt>load</tt> instructions before
- <tt>phi</tt> nodes. It is intended that this should make CFG hacking much
- easier. To make later hacking easier, the entry block is split into two, such
- that all introduced <tt>alloca</tt> instructions (and nothing else) are in the
- entry block.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="scalarrepl">Scalar Replacement of Aggregates</a>
-</div>
-<div class="doc_text">
- <p>
- The well-known scalar replacement of aggregates transformation. This
- transform breaks up <tt>alloca</tt> instructions of aggregate type (structure
- or array) into individual <tt>alloca</tt> instructions for each member if
- possible. Then, if possible, it transforms the individual <tt>alloca</tt>
- instructions into nice clean scalar SSA form.
- </p>
-
- <p>
- This combines a simple scalar replacement of aggregates algorithm with the <a
- href="#mem2reg"><tt>mem2reg</tt></a> algorithm because often interact,
- especially for C++ programs. As such, iterating between <tt>scalarrepl</tt>,
- then <a href="#mem2reg"><tt>mem2reg</tt></a> until we run out of things to
- promote works well.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="sccp">Sparse Conditional Constant Propagation</a>
-</div>
-<div class="doc_text">
- <p>
- Sparse conditional constant propagation and merging, which can be summarized
- as:
- </p>
-
- <ol>
- <li>Assumes values are constant unless proven otherwise</li>
- <li>Assumes BasicBlocks are dead unless proven otherwise</li>
- <li>Proves values to be constant, and replaces them with constants</li>
- <li>Proves conditional branches to be unconditional</li>
- </ol>
-
- <p>
- Note that this pass has a habit of making definitions be dead. It is a good
- idea to to run a DCE pass sometime after running this pass.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="simplify-libcalls">Simplify well-known library calls</a>
-</div>
-<div class="doc_text">
- <p>
- Applies a variety of small optimizations for calls to specific well-known
- function calls (e.g. runtime library functions). For example, a call
- <tt>exit(3)</tt> that occurs within the <tt>main()</tt> function can be
- transformed into simply <tt>return 3</tt>.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="simplifycfg">Simplify the CFG</a>
-</div>
-<div class="doc_text">
- <p>
- Performs dead code elimination and basic block merging. Specifically:
- </p>
-
- <ol>
- <li>Removes basic blocks with no predecessors.</li>
- <li>Merges a basic block into its predecessor if there is only one and the
- predecessor only has one successor.</li>
- <li>Eliminates PHI nodes for basic blocks with a single predecessor.</li>
- <li>Eliminates a basic block that only contains an unconditional
- branch.</li>
- </ol>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="strip">Strip all symbols from a module</a>
-</div>
-<div class="doc_text">
- <p>
- Performs code stripping. This transformation can delete:
- </p>
-
- <ol>
- <li>names for virtual registers</li>
- <li>symbols for internal globals and functions</li>
- <li>debug information</li>
- </ol>
-
- <p>
- Note that this transformation makes code much less readable, so it should
- only be used in situations where the <tt>strip</tt> utility would be used,
- such as reducing code size or making it harder to reverse engineer code.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="strip-dead-prototypes">Remove unused function declarations</a>
-</div>
-<div class="doc_text">
- <p>
- This pass loops over all of the functions in the input module, looking for
- dead declarations and removes them. Dead declarations are declarations of
- functions for which no implementation is available (i.e., declarations for
- unused library functions).
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="sretpromotion">Promote sret arguments</a>
-</div>
-<div class="doc_text">
- <p>
- This pass finds functions that return a struct (using a pointer to the struct
- as the first argument of the function, marked with the '<tt>sret</tt>' attribute) and
- replaces them with a new function that simply returns each of the elements of
- that struct (using multiple return values).
- </p>
-
- <p>
- This pass works under a number of conditions:
- </p>
-
- <ul>
- <li>The returned struct must not contain other structs</li>
- <li>The returned struct must only be used to load values from</li>
- <li>The placeholder struct passed in is the result of an <tt>alloca</tt></li>
- </ul>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="tailcallelim">Tail Call Elimination</a>
-</div>
-<div class="doc_text">
- <p>
- This file transforms calls of the current function (self recursion) followed
- by a return instruction with a branch to the entry of the function, creating
- a loop. This pass also implements the following extensions to the basic
- algorithm:
- </p>
-
- <ul>
- <li>Trivial instructions between the call and return do not prevent the
- transformation from taking place, though currently the analysis cannot
- support moving any really useful instructions (only dead ones).
- <li>This pass transforms functions that are prevented from being tail
- recursive by an associative expression to use an accumulator variable,
- thus compiling the typical naive factorial or <tt>fib</tt> implementation
- into efficient code.
- <li>TRE is performed if the function returns void, if the return
- returns the result returned by the call, or if the function returns a
- run-time constant on all exits from the function. It is possible, though
- unlikely, that the return returns something else (like constant 0), and
- can still be TRE'd. It can be TRE'd if <em>all other</em> return
- instructions in the function return the exact same value.
- <li>If it can prove that callees do not access theier caller stack frame,
- they are marked as eligible for tail call elimination (by the code
- generator).
- </ul>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="tailduplicate">Tail Duplication</a>
-</div>
-<div class="doc_text">
- <p>
- This pass performs a limited form of tail duplication, intended to simplify
- CFGs by removing some unconditional branches. This pass is necessary to
- straighten out loops created by the C front-end, but also is capable of
- making other code nicer. After this pass is run, the CFG simplify pass
- should be run to clean up the mess.
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"> <a name="transform">Utility Passes</a></div>
-<div class="doc_text">
- <p>This section describes the LLVM Utility Passes.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="deadarghaX0r">Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)</a>
-</div>
-<div class="doc_text">
- <p>
- Same as dead argument elimination, but deletes arguments to functions which
- are external. This is only for use by <a
- href="Bugpoint.html">bugpoint</a>.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="extract-blocks">Extract Basic Blocks From Module (for bugpoint use)</a>
-</div>
-<div class="doc_text">
- <p>
- This pass is used by bugpoint to extract all blocks from the module into their
- own functions.</p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="preverify">Preliminary module verification</a>
-</div>
-<div class="doc_text">
- <p>
- Ensures that the module is in the form required by the <a
- href="#verifier">Module Verifier</a> pass.
- </p>
-
- <p>
- Running the verifier runs this pass automatically, so there should be no need
- to use it directly.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="verify">Module Verifier</a>
-</div>
-<div class="doc_text">
- <p>
- Verifies an LLVM IR code. This is useful to run after an optimization which is
- undergoing testing. Note that <tt>llvm-as</tt> verifies its input before
- emitting bitcode, and also that malformed bitcode is likely to make LLVM
- crash. All language front-ends are therefore encouraged to verify their output
- before performing optimizing transformations.
- </p>
-
- <ul>
- <li>Both of a binary operator's parameters are of the same type.</li>
- <li>Verify that the indices of mem access instructions match other
- operands.</li>
- <li>Verify that arithmetic and other things are only performed on
- first-class types. Verify that shifts and logicals only happen on
- integrals f.e.</li>
- <li>All of the constants in a switch statement are of the correct type.</li>
- <li>The code is in valid SSA form.</li>
- <li>It is illegal to put a label into any other type (like a structure) or
- to return one.</li>
- <li>Only phi nodes can be self referential: <tt>%x = add i32 %x, %x</tt> is
- invalid.</li>
- <li>PHI nodes must have an entry for each predecessor, with no extras.</li>
- <li>PHI nodes must be the first thing in a basic block, all grouped
- together.</li>
- <li>PHI nodes must have at least one entry.</li>
- <li>All basic blocks should only end with terminator insts, not contain
- them.</li>
- <li>The entry node to a function must not have predecessors.</li>
- <li>All Instructions must be embedded into a basic block.</li>
- <li>Functions cannot take a void-typed parameter.</li>
- <li>Verify that a function's argument list agrees with its declared
- type.</li>
- <li>It is illegal to specify a name for a void value.</li>
- <li>It is illegal to have a internal global value with no initializer.</li>
- <li>It is illegal to have a ret instruction that returns a value that does
- not agree with the function return value type.</li>
- <li>Function call argument types match the function prototype.</li>
- <li>All other things that are tested by asserts spread about the code.</li>
- </ul>
-
- <p>
- Note that this does not provide full security verification (like Java), but
- instead just tries to ensure that code is well-formed.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="view-cfg">View CFG of function</a>
-</div>
-<div class="doc_text">
- <p>
- Displays the control flow graph using the GraphViz tool.
- </p>
-</div>
-
-<!-------------------------------------------------------------------------- -->
-<div class="doc_subsection">
- <a name="view-cfg-only">View CFG of function (with no function bodies)</a>
-</div>
-<div class="doc_text">
- <p>
- Displays the control flow graph using the GraphViz tool, but omitting function
- bodies.
- </p>
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:rspencer at x10sys.com">Reid Spencer</a><br>
- <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/ProgrammersManual.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ProgrammersManual.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/ProgrammersManual.html (original)
+++ llvm/trunk/docs/ProgrammersManual.html (removed)
@@ -1,3950 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <meta http-equiv="Content-type" content="text/html;charset=UTF-8">
- <title>LLVM Programmer's Manual</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">
- LLVM Programmer's Manual
-</div>
-
-<ol>
- <li><a href="#introduction">Introduction</a></li>
- <li><a href="#general">General Information</a>
- <ul>
- <li><a href="#stl">The C++ Standard Template Library</a></li>
-<!--
- <li>The <tt>-time-passes</tt> option</li>
- <li>How to use the LLVM Makefile system</li>
- <li>How to write a regression test</li>
-
--->
- </ul>
- </li>
- <li><a href="#apis">Important and useful LLVM APIs</a>
- <ul>
- <li><a href="#isa">The <tt>isa<></tt>, <tt>cast<></tt>
-and <tt>dyn_cast<></tt> templates</a> </li>
- <li><a href="#string_apis">Passing strings (the <tt>StringRef</tt>
-and <tt>Twine</tt> classes)</a>
- <ul>
- <li><a href="#StringRef">The <tt>StringRef</tt> class</a> </li>
- <li><a href="#Twine">The <tt>Twine</tt> class</a> </li>
- </ul>
- </li>
- <li><a href="#DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt>
-option</a>
- <ul>
- <li><a href="#DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt>
-and the <tt>-debug-only</tt> option</a> </li>
- </ul>
- </li>
- <li><a href="#Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt>
-option</a></li>
-<!--
- <li>The <tt>InstVisitor</tt> template
- <li>The general graph API
--->
- <li><a href="#ViewGraph">Viewing graphs while debugging code</a></li>
- </ul>
- </li>
- <li><a href="#datastructure">Picking the Right Data Structure for a Task</a>
- <ul>
- <li><a href="#ds_sequential">Sequential Containers (std::vector, std::list, etc)</a>
- <ul>
- <li><a href="#dss_fixedarrays">Fixed Size Arrays</a></li>
- <li><a href="#dss_heaparrays">Heap Allocated Arrays</a></li>
- <li><a href="#dss_smallvector">"llvm/ADT/SmallVector.h"</a></li>
- <li><a href="#dss_vector"><vector></a></li>
- <li><a href="#dss_deque"><deque></a></li>
- <li><a href="#dss_list"><list></a></li>
- <li><a href="#dss_ilist">llvm/ADT/ilist.h</a></li>
- <li><a href="#dss_other">Other Sequential Container Options</a></li>
- </ul></li>
- <li><a href="#ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a>
- <ul>
- <li><a href="#dss_sortedvectorset">A sorted 'vector'</a></li>
- <li><a href="#dss_smallset">"llvm/ADT/SmallSet.h"</a></li>
- <li><a href="#dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a></li>
- <li><a href="#dss_denseset">"llvm/ADT/DenseSet.h"</a></li>
- <li><a href="#dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a></li>
- <li><a href="#dss_set"><set></a></li>
- <li><a href="#dss_setvector">"llvm/ADT/SetVector.h"</a></li>
- <li><a href="#dss_uniquevector">"llvm/ADT/UniqueVector.h"</a></li>
- <li><a href="#dss_otherset">Other Set-Like ContainerOptions</a></li>
- </ul></li>
- <li><a href="#ds_map">Map-Like Containers (std::map, DenseMap, etc)</a>
- <ul>
- <li><a href="#dss_sortedvectormap">A sorted 'vector'</a></li>
- <li><a href="#dss_stringmap">"llvm/ADT/StringMap.h"</a></li>
- <li><a href="#dss_indexedmap">"llvm/ADT/IndexedMap.h"</a></li>
- <li><a href="#dss_densemap">"llvm/ADT/DenseMap.h"</a></li>
- <li><a href="#dss_valuemap">"llvm/ADT/ValueMap.h"</a></li>
- <li><a href="#dss_map"><map></a></li>
- <li><a href="#dss_othermap">Other Map-Like Container Options</a></li>
- </ul></li>
- <li><a href="#ds_string">String-like containers</a>
- <!--<ul>
- todo
- </ul>--></li>
- <li><a href="#ds_bit">BitVector-like containers</a>
- <ul>
- <li><a href="#dss_bitvector">A dense bitvector</a></li>
- <li><a href="#dss_smallbitvector">A "small" dense bitvector</a></li>
- <li><a href="#dss_sparsebitvector">A sparse bitvector</a></li>
- </ul></li>
- </ul>
- </li>
- <li><a href="#common">Helpful Hints for Common Operations</a>
- <ul>
- <li><a href="#inspection">Basic Inspection and Traversal Routines</a>
- <ul>
- <li><a href="#iterate_function">Iterating over the <tt>BasicBlock</tt>s
-in a <tt>Function</tt></a> </li>
- <li><a href="#iterate_basicblock">Iterating over the <tt>Instruction</tt>s
-in a <tt>BasicBlock</tt></a> </li>
- <li><a href="#iterate_institer">Iterating over the <tt>Instruction</tt>s
-in a <tt>Function</tt></a> </li>
- <li><a href="#iterate_convert">Turning an iterator into a
-class pointer</a> </li>
- <li><a href="#iterate_complex">Finding call sites: a more
-complex example</a> </li>
- <li><a href="#calls_and_invokes">Treating calls and invokes
-the same way</a> </li>
- <li><a href="#iterate_chains">Iterating over def-use &
-use-def chains</a> </li>
- <li><a href="#iterate_preds">Iterating over predecessors &
-successors of blocks</a></li>
- </ul>
- </li>
- <li><a href="#simplechanges">Making simple changes</a>
- <ul>
- <li><a href="#schanges_creating">Creating and inserting new
- <tt>Instruction</tt>s</a> </li>
- <li><a href="#schanges_deleting">Deleting <tt>Instruction</tt>s</a> </li>
- <li><a href="#schanges_replacing">Replacing an <tt>Instruction</tt>
-with another <tt>Value</tt></a> </li>
- <li><a href="#schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a> </li>
- </ul>
- </li>
- <li><a href="#create_types">How to Create Types</a></li>
-<!--
- <li>Working with the Control Flow Graph
- <ul>
- <li>Accessing predecessors and successors of a <tt>BasicBlock</tt>
- <li>
- <li>
- </ul>
--->
- </ul>
- </li>
-
- <li><a href="#threading">Threads and LLVM</a>
- <ul>
- <li><a href="#startmultithreaded">Entering and Exiting Multithreaded Mode
- </a></li>
- <li><a href="#shutdown">Ending execution with <tt>llvm_shutdown()</tt></a></li>
- <li><a href="#managedstatic">Lazy initialization with <tt>ManagedStatic</tt></a></li>
- <li><a href="#llvmcontext">Achieving Isolation with <tt>LLVMContext</tt></a></li>
- <li><a href="#jitthreading">Threads and the JIT</a></li>
- </ul>
- </li>
-
- <li><a href="#advanced">Advanced Topics</a>
- <ul>
- <li><a href="#TypeResolve">LLVM Type Resolution</a>
- <ul>
- <li><a href="#BuildRecType">Basic Recursive Type Construction</a></li>
- <li><a href="#refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a></li>
- <li><a href="#PATypeHolder">The PATypeHolder Class</a></li>
- <li><a href="#AbstractTypeUser">The AbstractTypeUser Class</a></li>
- </ul></li>
-
- <li><a href="#SymbolTable">The <tt>ValueSymbolTable</tt> and <tt>TypeSymbolTable</tt> classes</a></li>
- <li><a href="#UserLayout">The <tt>User</tt> and owned <tt>Use</tt> classes' memory layout</a></li>
- </ul></li>
-
- <li><a href="#coreclasses">The Core LLVM Class Hierarchy Reference</a>
- <ul>
- <li><a href="#Type">The <tt>Type</tt> class</a> </li>
- <li><a href="#Module">The <tt>Module</tt> class</a></li>
- <li><a href="#Value">The <tt>Value</tt> class</a>
- <ul>
- <li><a href="#User">The <tt>User</tt> class</a>
- <ul>
- <li><a href="#Instruction">The <tt>Instruction</tt> class</a></li>
- <li><a href="#Constant">The <tt>Constant</tt> class</a>
- <ul>
- <li><a href="#GlobalValue">The <tt>GlobalValue</tt> class</a>
- <ul>
- <li><a href="#Function">The <tt>Function</tt> class</a></li>
- <li><a href="#GlobalVariable">The <tt>GlobalVariable</tt> class</a></li>
- </ul>
- </li>
- </ul>
- </li>
- </ul>
- </li>
- <li><a href="#BasicBlock">The <tt>BasicBlock</tt> class</a></li>
- <li><a href="#Argument">The <tt>Argument</tt> class</a></li>
- </ul>
- </li>
- </ul>
- </li>
-</ol>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
- <a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a>,
- <a href="mailto:ggreif at gmail.com">Gabor Greif</a>,
- <a href="mailto:jstanley at cs.uiuc.edu">Joel Stanley</a>,
- <a href="mailto:rspencer at x10sys.com">Reid Spencer</a> and
- <a href="mailto:owen at apple.com">Owen Anderson</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="introduction">Introduction </a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This document is meant to highlight some of the important classes and
-interfaces available in the LLVM source-base. This manual is not
-intended to explain what LLVM is, how it works, and what LLVM code looks
-like. It assumes that you know the basics of LLVM and are interested
-in writing transformations or otherwise analyzing or manipulating the
-code.</p>
-
-<p>This document should get you oriented so that you can find your
-way in the continuously growing source code that makes up the LLVM
-infrastructure. Note that this manual is not intended to serve as a
-replacement for reading the source code, so if you think there should be
-a method in one of these classes to do something, but it's not listed,
-check the source. Links to the <a href="/doxygen/">doxygen</a> sources
-are provided to make this as easy as possible.</p>
-
-<p>The first section of this document describes general information that is
-useful to know when working in the LLVM infrastructure, and the second describes
-the Core LLVM classes. In the future this manual will be extended with
-information describing how to use extension libraries, such as dominator
-information, CFG traversal routines, and useful utilities like the <tt><a
-href="/doxygen/InstVisitor_8h-source.html">InstVisitor</a></tt> template.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="general">General Information</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This section contains general information that is useful if you are working
-in the LLVM source-base, but that isn't specific to any particular API.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="stl">The C++ Standard Template Library</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM makes heavy use of the C++ Standard Template Library (STL),
-perhaps much more than you are used to, or have seen before. Because of
-this, you might want to do a little background reading in the
-techniques used and capabilities of the library. There are many good
-pages that discuss the STL, and several books on the subject that you
-can get, so it will not be discussed in this document.</p>
-
-<p>Here are some useful links:</p>
-
-<ol>
-
-<li><a href="http://www.dinkumware.com/refxcpp.html">Dinkumware C++ Library
-reference</a> - an excellent reference for the STL and other parts of the
-standard C++ library.</li>
-
-<li><a href="http://www.tempest-sw.com/cpp/">C++ In a Nutshell</a> - This is an
-O'Reilly book in the making. It has a decent Standard Library
-Reference that rivals Dinkumware's, and is unfortunately no longer free since the
-book has been published.</li>
-
-<li><a href="http://www.parashift.com/c++-faq-lite/">C++ Frequently Asked
-Questions</a></li>
-
-<li><a href="http://www.sgi.com/tech/stl/">SGI's STL Programmer's Guide</a> -
-Contains a useful <a
-href="http://www.sgi.com/tech/stl/stl_introduction.html">Introduction to the
-STL</a>.</li>
-
-<li><a href="http://www.research.att.com/%7Ebs/C++.html">Bjarne Stroustrup's C++
-Page</a></li>
-
-<li><a href="http://64.78.49.204/">
-Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get
-the book).</a></li>
-
-</ol>
-
-<p>You are also encouraged to take a look at the <a
-href="CodingStandards.html">LLVM Coding Standards</a> guide which focuses on how
-to write maintainable code more than where to put your curly braces.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="stl">Other useful references</a>
-</div>
-
-<div class="doc_text">
-
-<ol>
-<li><a href="http://www.psc.edu/%7Esemke/cvs_branches.html">CVS
-Branch and Tag Primer</a></li>
-<li><a href="http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html">Using
-static and shared libraries across platforms</a></li>
-</ol>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="apis">Important and useful LLVM APIs</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Here we highlight some LLVM APIs that are generally useful and good to
-know about when writing transformations.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="isa">The <tt>isa<></tt>, <tt>cast<></tt> and
- <tt>dyn_cast<></tt> templates</a>
-</div>
-
-<div class="doc_text">
-
-<p>The LLVM source-base makes extensive use of a custom form of RTTI.
-These templates have many similarities to the C++ <tt>dynamic_cast<></tt>
-operator, but they don't have some drawbacks (primarily stemming from
-the fact that <tt>dynamic_cast<></tt> only works on classes that
-have a v-table). Because they are used so often, you must know what they
-do and how they work. All of these templates are defined in the <a
- href="/doxygen/Casting_8h-source.html"><tt>llvm/Support/Casting.h</tt></a>
-file (note that you very rarely have to include this file directly).</p>
-
-<dl>
- <dt><tt>isa<></tt>: </dt>
-
- <dd><p>The <tt>isa<></tt> operator works exactly like the Java
- "<tt>instanceof</tt>" operator. It returns true or false depending on whether
- a reference or pointer points to an instance of the specified class. This can
- be very useful for constraint checking of various sorts (example below).</p>
- </dd>
-
- <dt><tt>cast<></tt>: </dt>
-
- <dd><p>The <tt>cast<></tt> operator is a "checked cast" operation. It
- converts a pointer or reference from a base class to a derived class, causing
- an assertion failure if it is not really an instance of the right type. This
- should be used in cases where you have some information that makes you believe
- that something is of the right type. An example of the <tt>isa<></tt>
- and <tt>cast<></tt> template is:</p>
-
-<div class="doc_code">
-<pre>
-static bool isLoopInvariant(const <a href="#Value">Value</a> *V, const Loop *L) {
- if (isa<<a href="#Constant">Constant</a>>(V) || isa<<a href="#Argument">Argument</a>>(V) || isa<<a href="#GlobalValue">GlobalValue</a>>(V))
- return true;
-
- // <i>Otherwise, it must be an instruction...</i>
- return !L->contains(cast<<a href="#Instruction">Instruction</a>>(V)->getParent());
-}
-</pre>
-</div>
-
- <p>Note that you should <b>not</b> use an <tt>isa<></tt> test followed
- by a <tt>cast<></tt>, for that use the <tt>dyn_cast<></tt>
- operator.</p>
-
- </dd>
-
- <dt><tt>dyn_cast<></tt>:</dt>
-
- <dd><p>The <tt>dyn_cast<></tt> operator is a "checking cast" operation.
- It checks to see if the operand is of the specified type, and if so, returns a
- pointer to it (this operator does not work with references). If the operand is
- not of the correct type, a null pointer is returned. Thus, this works very
- much like the <tt>dynamic_cast<></tt> operator in C++, and should be
- used in the same circumstances. Typically, the <tt>dyn_cast<></tt>
- operator is used in an <tt>if</tt> statement or some other flow control
- statement like this:</p>
-
-<div class="doc_code">
-<pre>
-if (<a href="#AllocationInst">AllocationInst</a> *AI = dyn_cast<<a href="#AllocationInst">AllocationInst</a>>(Val)) {
- // <i>...</i>
-}
-</pre>
-</div>
-
- <p>This form of the <tt>if</tt> statement effectively combines together a call
- to <tt>isa<></tt> and a call to <tt>cast<></tt> into one
- statement, which is very convenient.</p>
-
- <p>Note that the <tt>dyn_cast<></tt> operator, like C++'s
- <tt>dynamic_cast<></tt> or Java's <tt>instanceof</tt> operator, can be
- abused. In particular, you should not use big chained <tt>if/then/else</tt>
- blocks to check for lots of different variants of classes. If you find
- yourself wanting to do this, it is much cleaner and more efficient to use the
- <tt>InstVisitor</tt> class to dispatch over the instruction type directly.</p>
-
- </dd>
-
- <dt><tt>cast_or_null<></tt>: </dt>
-
- <dd><p>The <tt>cast_or_null<></tt> operator works just like the
- <tt>cast<></tt> operator, except that it allows for a null pointer as an
- argument (which it then propagates). This can sometimes be useful, allowing
- you to combine several null checks into one.</p></dd>
-
- <dt><tt>dyn_cast_or_null<></tt>: </dt>
-
- <dd><p>The <tt>dyn_cast_or_null<></tt> operator works just like the
- <tt>dyn_cast<></tt> operator, except that it allows for a null pointer
- as an argument (which it then propagates). This can sometimes be useful,
- allowing you to combine several null checks into one.</p></dd>
-
-</dl>
-
-<p>These five templates can be used with any classes, whether they have a
-v-table or not. To add support for these templates, you simply need to add
-<tt>classof</tt> static methods to the class you are interested casting
-to. Describing this is currently outside the scope of this document, but there
-are lots of examples in the LLVM source base.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="string_apis">Passing strings (the <tt>StringRef</tt>
-and <tt>Twine</tt> classes)</a>
-</div>
-
-<div class="doc_text">
-
-<p>Although LLVM generally does not do much string manipulation, we do have
-several important APIs which take strings. Two important examples are the
-Value class -- which has names for instructions, functions, etc. -- and the
-StringMap class which is used extensively in LLVM and Clang.</p>
-
-<p>These are generic classes, and they need to be able to accept strings which
-may have embedded null characters. Therefore, they cannot simply take
-a <tt>const char *</tt>, and taking a <tt>const std::string&</tt> requires
-clients to perform a heap allocation which is usually unnecessary. Instead,
-many LLVM APIs use a <tt>const StringRef&</tt> or a <tt>const
-Twine&</tt> for passing strings efficiently.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="StringRef">The <tt>StringRef</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>StringRef</tt> data type represents a reference to a constant string
-(a character array and a length) and supports the common operations available
-on <tt>std:string</tt>, but does not require heap allocation.</p>
-
-<p>It can be implicitly constructed using a C style null-terminated string,
-an <tt>std::string</tt>, or explicitly with a character pointer and length.
-For example, the <tt>StringRef</tt> find function is declared as:</p>
-
-<div class="doc_code">
- iterator find(const StringRef &Key);
-</div>
-
-<p>and clients can call it using any one of:</p>
-
-<div class="doc_code">
-<pre>
- Map.find("foo"); <i>// Lookup "foo"</i>
- Map.find(std::string("bar")); <i>// Lookup "bar"</i>
- Map.find(StringRef("\0baz", 4)); <i>// Lookup "\0baz"</i>
-</pre>
-</div>
-
-<p>Similarly, APIs which need to return a string may return a <tt>StringRef</tt>
-instance, which can be used directly or converted to an <tt>std::string</tt>
-using the <tt>str</tt> member function. See
-"<tt><a href="/doxygen/classllvm_1_1StringRef_8h-source.html">llvm/ADT/StringRef.h</a></tt>"
-for more information.</p>
-
-<p>You should rarely use the <tt>StringRef</tt> class directly, because it contains
-pointers to external memory it is not generally safe to store an instance of the
-class (unless you know that the external storage will not be freed).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="Twine">The <tt>Twine</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>Twine</tt> class is an efficient way for APIs to accept concatenated
-strings. For example, a common LLVM paradigm is to name one instruction based on
-the name of another instruction with a suffix, for example:</p>
-
-<div class="doc_code">
-<pre>
- New = CmpInst::Create(<i>...</i>, SO->getName() + ".cmp");
-</pre>
-</div>
-
-<p>The <tt>Twine</tt> class is effectively a
-lightweight <a href="http://en.wikipedia.org/wiki/Rope_(computer_science)">rope</a>
-which points to temporary (stack allocated) objects. Twines can be implicitly
-constructed as the result of the plus operator applied to strings (i.e., a C
-strings, an <tt>std::string</tt>, or a <tt>StringRef</tt>). The twine delays the
-actual concatenation of strings until it is actually required, at which point
-it can be efficiently rendered directly into a character array. This avoids
-unnecessary heap allocation involved in constructing the temporary results of
-string concatenation. See
-"<tt><a href="/doxygen/classllvm_1_1Twine_8h-source.html">llvm/ADT/Twine.h</a></tt>"
-for more information.</p>
-
-<p>As with a <tt>StringRef</tt>, <tt>Twine</tt> objects point to external memory
-and should almost never be stored or mentioned directly. They are intended
-solely for use when defining a function which should be able to efficiently
-accept concatenated strings.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt> option</a>
-</div>
-
-<div class="doc_text">
-
-<p>Often when working on your pass you will put a bunch of debugging printouts
-and other code into your pass. After you get it working, you want to remove
-it, but you may need it again in the future (to work out new bugs that you run
-across).</p>
-
-<p> Naturally, because of this, you don't want to delete the debug printouts,
-but you don't want them to always be noisy. A standard compromise is to comment
-them out, allowing you to enable them if you need them in the future.</p>
-
-<p>The "<tt><a href="/doxygen/Debug_8h-source.html">llvm/Support/Debug.h</a></tt>"
-file provides a macro named <tt>DEBUG()</tt> that is a much nicer solution to
-this problem. Basically, you can put arbitrary code into the argument of the
-<tt>DEBUG</tt> macro, and it is only executed if '<tt>opt</tt>' (or any other
-tool) is run with the '<tt>-debug</tt>' command line argument:</p>
-
-<div class="doc_code">
-<pre>
-DEBUG(errs() << "I am here!\n");
-</pre>
-</div>
-
-<p>Then you can run your pass like this:</p>
-
-<div class="doc_code">
-<pre>
-$ opt < a.bc > /dev/null -mypass
-<i><no output></i>
-$ opt < a.bc > /dev/null -mypass -debug
-I am here!
-</pre>
-</div>
-
-<p>Using the <tt>DEBUG()</tt> macro instead of a home-brewed solution allows you
-to not have to create "yet another" command line option for the debug output for
-your pass. Note that <tt>DEBUG()</tt> macros are disabled for optimized builds,
-so they do not cause a performance impact at all (for the same reason, they
-should also not contain side-effects!).</p>
-
-<p>One additional nice thing about the <tt>DEBUG()</tt> macro is that you can
-enable or disable it directly in gdb. Just use "<tt>set DebugFlag=0</tt>" or
-"<tt>set DebugFlag=1</tt>" from the gdb if the program is running. If the
-program hasn't been started yet, you can always just run it with
-<tt>-debug</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> and
- the <tt>-debug-only</tt> option</a>
-</div>
-
-<div class="doc_text">
-
-<p>Sometimes you may find yourself in a situation where enabling <tt>-debug</tt>
-just turns on <b>too much</b> information (such as when working on the code
-generator). If you want to enable debug information with more fine-grained
-control, you define the <tt>DEBUG_TYPE</tt> macro and the <tt>-debug</tt> only
-option as follows:</p>
-
-<div class="doc_code">
-<pre>
-#undef DEBUG_TYPE
-DEBUG(errs() << "No debug type\n");
-#define DEBUG_TYPE "foo"
-DEBUG(errs() << "'foo' debug type\n");
-#undef DEBUG_TYPE
-#define DEBUG_TYPE "bar"
-DEBUG(errs() << "'bar' debug type\n"));
-#undef DEBUG_TYPE
-#define DEBUG_TYPE ""
-DEBUG(errs() << "No debug type (2)\n");
-</pre>
-</div>
-
-<p>Then you can run your pass like this:</p>
-
-<div class="doc_code">
-<pre>
-$ opt < a.bc > /dev/null -mypass
-<i><no output></i>
-$ opt < a.bc > /dev/null -mypass -debug
-No debug type
-'foo' debug type
-'bar' debug type
-No debug type (2)
-$ opt < a.bc > /dev/null -mypass -debug-only=foo
-'foo' debug type
-$ opt < a.bc > /dev/null -mypass -debug-only=bar
-'bar' debug type
-</pre>
-</div>
-
-<p>Of course, in practice, you should only set <tt>DEBUG_TYPE</tt> at the top of
-a file, to specify the debug type for the entire module (if you do this before
-you <tt>#include "llvm/Support/Debug.h"</tt>, you don't have to insert the ugly
-<tt>#undef</tt>'s). Also, you should use names more meaningful than "foo" and
-"bar", because there is no system in place to ensure that names do not
-conflict. If two different modules use the same string, they will all be turned
-on when the name is specified. This allows, for example, all debug information
-for instruction scheduling to be enabled with <tt>-debug-type=InstrSched</tt>,
-even if the source lives in multiple files.</p>
-
-<p>The <tt>DEBUG_WITH_TYPE</tt> macro is also available for situations where you
-would like to set <tt>DEBUG_TYPE</tt>, but only for one specific <tt>DEBUG</tt>
-statement. It takes an additional first parameter, which is the type to use. For
-example, the preceding example could be written as:</p>
-
-
-<div class="doc_code">
-<pre>
-DEBUG_WITH_TYPE("", errs() << "No debug type\n");
-DEBUG_WITH_TYPE("foo", errs() << "'foo' debug type\n");
-DEBUG_WITH_TYPE("bar", errs() << "'bar' debug type\n"));
-DEBUG_WITH_TYPE("", errs() << "No debug type (2)\n");
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt>
- option</a>
-</div>
-
-<div class="doc_text">
-
-<p>The "<tt><a
-href="/doxygen/Statistic_8h-source.html">llvm/ADT/Statistic.h</a></tt>" file
-provides a class named <tt>Statistic</tt> that is used as a unified way to
-keep track of what the LLVM compiler is doing and how effective various
-optimizations are. It is useful to see what optimizations are contributing to
-making a particular program run faster.</p>
-
-<p>Often you may run your pass on some big program, and you're interested to see
-how many times it makes a certain transformation. Although you can do this with
-hand inspection, or some ad-hoc method, this is a real pain and not very useful
-for big programs. Using the <tt>Statistic</tt> class makes it very easy to
-keep track of this information, and the calculated information is presented in a
-uniform manner with the rest of the passes being executed.</p>
-
-<p>There are many examples of <tt>Statistic</tt> uses, but the basics of using
-it are as follows:</p>
-
-<ol>
- <li><p>Define your statistic like this:</p>
-
-<div class="doc_code">
-<pre>
-#define <a href="#DEBUG_TYPE">DEBUG_TYPE</a> "mypassname" <i>// This goes before any #includes.</i>
-STATISTIC(NumXForms, "The # of times I did stuff");
-</pre>
-</div>
-
- <p>The <tt>STATISTIC</tt> macro defines a static variable, whose name is
- specified by the first argument. The pass name is taken from the DEBUG_TYPE
- macro, and the description is taken from the second argument. The variable
- defined ("NumXForms" in this case) acts like an unsigned integer.</p></li>
-
- <li><p>Whenever you make a transformation, bump the counter:</p>
-
-<div class="doc_code">
-<pre>
-++NumXForms; // <i>I did stuff!</i>
-</pre>
-</div>
-
- </li>
- </ol>
-
- <p>That's all you have to do. To get '<tt>opt</tt>' to print out the
- statistics gathered, use the '<tt>-stats</tt>' option:</p>
-
-<div class="doc_code">
-<pre>
-$ opt -stats -mypassname < program.bc > /dev/null
-<i>... statistics output ...</i>
-</pre>
-</div>
-
- <p> When running <tt>opt</tt> on a C file from the SPEC benchmark
-suite, it gives a report that looks like this:</p>
-
-<div class="doc_code">
-<pre>
- 7646 bitcodewriter - Number of normal instructions
- 725 bitcodewriter - Number of oversized instructions
- 129996 bitcodewriter - Number of bitcode bytes written
- 2817 raise - Number of insts DCEd or constprop'd
- 3213 raise - Number of cast-of-self removed
- 5046 raise - Number of expression trees converted
- 75 raise - Number of other getelementptr's formed
- 138 raise - Number of load/store peepholes
- 42 deadtypeelim - Number of unused typenames removed from symtab
- 392 funcresolve - Number of varargs functions resolved
- 27 globaldce - Number of global variables removed
- 2 adce - Number of basic blocks removed
- 134 cee - Number of branches revectored
- 49 cee - Number of setcc instruction eliminated
- 532 gcse - Number of loads removed
- 2919 gcse - Number of instructions removed
- 86 indvars - Number of canonical indvars added
- 87 indvars - Number of aux indvars removed
- 25 instcombine - Number of dead inst eliminate
- 434 instcombine - Number of insts combined
- 248 licm - Number of load insts hoisted
- 1298 licm - Number of insts hoisted to a loop pre-header
- 3 licm - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
- 75 mem2reg - Number of alloca's promoted
- 1444 cfgsimplify - Number of blocks simplified
-</pre>
-</div>
-
-<p>Obviously, with so many optimizations, having a unified framework for this
-stuff is very nice. Making your pass fit well into the framework makes it more
-maintainable and useful.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ViewGraph">Viewing graphs while debugging code</a>
-</div>
-
-<div class="doc_text">
-
-<p>Several of the important data structures in LLVM are graphs: for example
-CFGs made out of LLVM <a href="#BasicBlock">BasicBlock</a>s, CFGs made out of
-LLVM <a href="CodeGenerator.html#machinebasicblock">MachineBasicBlock</a>s, and
-<a href="CodeGenerator.html#selectiondag_intro">Instruction Selection
-DAGs</a>. In many cases, while debugging various parts of the compiler, it is
-nice to instantly visualize these graphs.</p>
-
-<p>LLVM provides several callbacks that are available in a debug build to do
-exactly that. If you call the <tt>Function::viewCFG()</tt> method, for example,
-the current LLVM tool will pop up a window containing the CFG for the function
-where each basic block is a node in the graph, and each node contains the
-instructions in the block. Similarly, there also exists
-<tt>Function::viewCFGOnly()</tt> (does not include the instructions), the
-<tt>MachineFunction::viewCFG()</tt> and <tt>MachineFunction::viewCFGOnly()</tt>,
-and the <tt>SelectionDAG::viewGraph()</tt> methods. Within GDB, for example,
-you can usually use something like <tt>call DAG.viewGraph()</tt> to pop
-up a window. Alternatively, you can sprinkle calls to these functions in your
-code in places you want to debug.</p>
-
-<p>Getting this to work requires a small amount of configuration. On Unix
-systems with X11, install the <a href="http://www.graphviz.org">graphviz</a>
-toolkit, and make sure 'dot' and 'gv' are in your path. If you are running on
-Mac OS/X, download and install the Mac OS/X <a
-href="http://www.pixelglow.com/graphviz/">Graphviz program</a>, and add
-<tt>/Applications/Graphviz.app/Contents/MacOS/</tt> (or wherever you install
-it) to your path. Once in your system and path are set up, rerun the LLVM
-configure script and rebuild LLVM to enable this functionality.</p>
-
-<p><tt>SelectionDAG</tt> has been extended to make it easier to locate
-<i>interesting</i> nodes in large complex graphs. From gdb, if you
-<tt>call DAG.setGraphColor(<i>node</i>, "<i>color</i>")</tt>, then the
-next <tt>call DAG.viewGraph()</tt> would highlight the node in the
-specified color (choices of colors can be found at <a
-href="http://www.graphviz.org/doc/info/colors.html">colors</a>.) More
-complex node attributes can be provided with <tt>call
-DAG.setGraphAttrs(<i>node</i>, "<i>attributes</i>")</tt> (choices can be
-found at <a href="http://www.graphviz.org/doc/info/attrs.html">Graph
-Attributes</a>.) If you want to restart and clear all the current graph
-attributes, then you can <tt>call DAG.clearGraphAttrs()</tt>. </p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="datastructure">Picking the Right Data Structure for a Task</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>LLVM has a plethora of data structures in the <tt>llvm/ADT/</tt> directory,
- and we commonly use STL data structures. This section describes the trade-offs
- you should consider when you pick one.</p>
-
-<p>
-The first step is a choose your own adventure: do you want a sequential
-container, a set-like container, or a map-like container? The most important
-thing when choosing a container is the algorithmic properties of how you plan to
-access the container. Based on that, you should use:</p>
-
-<ul>
-<li>a <a href="#ds_map">map-like</a> container if you need efficient look-up
- of an value based on another value. Map-like containers also support
- efficient queries for containment (whether a key is in the map). Map-like
- containers generally do not support efficient reverse mapping (values to
- keys). If you need that, use two maps. Some map-like containers also
- support efficient iteration through the keys in sorted order. Map-like
- containers are the most expensive sort, only use them if you need one of
- these capabilities.</li>
-
-<li>a <a href="#ds_set">set-like</a> container if you need to put a bunch of
- stuff into a container that automatically eliminates duplicates. Some
- set-like containers support efficient iteration through the elements in
- sorted order. Set-like containers are more expensive than sequential
- containers.
-</li>
-
-<li>a <a href="#ds_sequential">sequential</a> container provides
- the most efficient way to add elements and keeps track of the order they are
- added to the collection. They permit duplicates and support efficient
- iteration, but do not support efficient look-up based on a key.
-</li>
-
-<li>a <a href="#ds_string">string</a> container is a specialized sequential
- container or reference structure that is used for character or byte
- arrays.</li>
-
-<li>a <a href="#ds_bit">bit</a> container provides an efficient way to store and
- perform set operations on sets of numeric id's, while automatically
- eliminating duplicates. Bit containers require a maximum of 1 bit for each
- identifier you want to store.
-</li>
-</ul>
-
-<p>
-Once the proper category of container is determined, you can fine tune the
-memory use, constant factors, and cache behaviors of access by intelligently
-picking a member of the category. Note that constant factors and cache behavior
-can be a big deal. If you have a vector that usually only contains a few
-elements (but could contain many), for example, it's much better to use
-<a href="#dss_smallvector">SmallVector</a> than <a href="#dss_vector">vector</a>
-. Doing so avoids (relatively) expensive malloc/free calls, which dwarf the
-cost of adding the elements to the container. </p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ds_sequential">Sequential Containers (std::vector, std::list, etc)</a>
-</div>
-
-<div class="doc_text">
-There are a variety of sequential containers available for you, based on your
-needs. Pick the first in this section that will do what you want.
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_fixedarrays">Fixed Size Arrays</a>
-</div>
-
-<div class="doc_text">
-<p>Fixed size arrays are very simple and very fast. They are good if you know
-exactly how many elements you have, or you have a (low) upper bound on how many
-you have.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_heaparrays">Heap Allocated Arrays</a>
-</div>
-
-<div class="doc_text">
-<p>Heap allocated arrays (new[] + delete[]) are also simple. They are good if
-the number of elements is variable, if you know how many elements you will need
-before the array is allocated, and if the array is usually large (if not,
-consider a <a href="#dss_smallvector">SmallVector</a>). The cost of a heap
-allocated array is the cost of the new/delete (aka malloc/free). Also note that
-if you are allocating an array of a type with a constructor, the constructor and
-destructors will be run for every element in the array (re-sizable vectors only
-construct those elements actually used).</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_smallvector">"llvm/ADT/SmallVector.h"</a>
-</div>
-
-<div class="doc_text">
-<p><tt>SmallVector<Type, N></tt> is a simple class that looks and smells
-just like <tt>vector<Type></tt>:
-it supports efficient iteration, lays out elements in memory order (so you can
-do pointer arithmetic between elements), supports efficient push_back/pop_back
-operations, supports efficient random access to its elements, etc.</p>
-
-<p>The advantage of SmallVector is that it allocates space for
-some number of elements (N) <b>in the object itself</b>. Because of this, if
-the SmallVector is dynamically smaller than N, no malloc is performed. This can
-be a big win in cases where the malloc/free call is far more expensive than the
-code that fiddles around with the elements.</p>
-
-<p>This is good for vectors that are "usually small" (e.g. the number of
-predecessors/successors of a block is usually less than 8). On the other hand,
-this makes the size of the SmallVector itself large, so you don't want to
-allocate lots of them (doing so will waste a lot of space). As such,
-SmallVectors are most useful when on the stack.</p>
-
-<p>SmallVector also provides a nice portable and efficient replacement for
-<tt>alloca</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_vector"><vector></a>
-</div>
-
-<div class="doc_text">
-<p>
-std::vector is well loved and respected. It is useful when SmallVector isn't:
-when the size of the vector is often large (thus the small optimization will
-rarely be a benefit) or if you will be allocating many instances of the vector
-itself (which would waste space for elements that aren't in the container).
-vector is also useful when interfacing with code that expects vectors :).
-</p>
-
-<p>One worthwhile note about std::vector: avoid code like this:</p>
-
-<div class="doc_code">
-<pre>
-for ( ... ) {
- std::vector<foo> V;
- use V;
-}
-</pre>
-</div>
-
-<p>Instead, write this as:</p>
-
-<div class="doc_code">
-<pre>
-std::vector<foo> V;
-for ( ... ) {
- use V;
- V.clear();
-}
-</pre>
-</div>
-
-<p>Doing so will save (at least) one heap allocation and free per iteration of
-the loop.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_deque"><deque></a>
-</div>
-
-<div class="doc_text">
-<p>std::deque is, in some senses, a generalized version of std::vector. Like
-std::vector, it provides constant time random access and other similar
-properties, but it also provides efficient access to the front of the list. It
-does not guarantee continuity of elements within memory.</p>
-
-<p>In exchange for this extra flexibility, std::deque has significantly higher
-constant factor costs than std::vector. If possible, use std::vector or
-something cheaper.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_list"><list></a>
-</div>
-
-<div class="doc_text">
-<p>std::list is an extremely inefficient class that is rarely useful.
-It performs a heap allocation for every element inserted into it, thus having an
-extremely high constant factor, particularly for small data types. std::list
-also only supports bidirectional iteration, not random access iteration.</p>
-
-<p>In exchange for this high cost, std::list supports efficient access to both
-ends of the list (like std::deque, but unlike std::vector or SmallVector). In
-addition, the iterator invalidation characteristics of std::list are stronger
-than that of a vector class: inserting or removing an element into the list does
-not invalidate iterator or pointers to other elements in the list.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_ilist">llvm/ADT/ilist.h</a>
-</div>
-
-<div class="doc_text">
-<p><tt>ilist<T></tt> implements an 'intrusive' doubly-linked list. It is
-intrusive, because it requires the element to store and provide access to the
-prev/next pointers for the list.</p>
-
-<p><tt>ilist</tt> has the same drawbacks as <tt>std::list</tt>, and additionally
-requires an <tt>ilist_traits</tt> implementation for the element type, but it
-provides some novel characteristics. In particular, it can efficiently store
-polymorphic objects, the traits class is informed when an element is inserted or
-removed from the list, and <tt>ilist</tt>s are guaranteed to support a
-constant-time splice operation.</p>
-
-<p>These properties are exactly what we want for things like
-<tt>Instruction</tt>s and basic blocks, which is why these are implemented with
-<tt>ilist</tt>s.</p>
-
-Related classes of interest are explained in the following subsections:
- <ul>
- <li><a href="#dss_ilist_traits">ilist_traits</a></li>
- <li><a href="#dss_iplist">iplist</a></li>
- <li><a href="#dss_ilist_node">llvm/ADT/ilist_node.h</a></li>
- <li><a href="#dss_ilist_sentinel">Sentinels</a></li>
- </ul>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_ilist_traits">ilist_traits</a>
-</div>
-
-<div class="doc_text">
-<p><tt>ilist_traits<T></tt> is <tt>ilist<T></tt>'s customization
-mechanism. <tt>iplist<T></tt> (and consequently <tt>ilist<T></tt>)
-publicly derive from this traits class.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_iplist">iplist</a>
-</div>
-
-<div class="doc_text">
-<p><tt>iplist<T></tt> is <tt>ilist<T></tt>'s base and as such
-supports a slightly narrower interface. Notably, inserters from
-<tt>T&</tt> are absent.</p>
-
-<p><tt>ilist_traits<T></tt> is a public base of this class and can be
-used for a wide variety of customizations.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_ilist_node">llvm/ADT/ilist_node.h</a>
-</div>
-
-<div class="doc_text">
-<p><tt>ilist_node<T></tt> implements a the forward and backward links
-that are expected by the <tt>ilist<T></tt> (and analogous containers)
-in the default manner.</p>
-
-<p><tt>ilist_node<T></tt>s are meant to be embedded in the node type
-<tt>T</tt>, usually <tt>T</tt> publicly derives from
-<tt>ilist_node<T></tt>.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_ilist_sentinel">Sentinels</a>
-</div>
-
-<div class="doc_text">
-<p><tt>ilist</tt>s have another specialty that must be considered. To be a good
-citizen in the C++ ecosystem, it needs to support the standard container
-operations, such as <tt>begin</tt> and <tt>end</tt> iterators, etc. Also, the
-<tt>operator--</tt> must work correctly on the <tt>end</tt> iterator in the
-case of non-empty <tt>ilist</tt>s.</p>
-
-<p>The only sensible solution to this problem is to allocate a so-called
-<i>sentinel</i> along with the intrusive list, which serves as the <tt>end</tt>
-iterator, providing the back-link to the last element. However conforming to the
-C++ convention it is illegal to <tt>operator++</tt> beyond the sentinel and it
-also must not be dereferenced.</p>
-
-<p>These constraints allow for some implementation freedom to the <tt>ilist</tt>
-how to allocate and store the sentinel. The corresponding policy is dictated
-by <tt>ilist_traits<T></tt>. By default a <tt>T</tt> gets heap-allocated
-whenever the need for a sentinel arises.</p>
-
-<p>While the default policy is sufficient in most cases, it may break down when
-<tt>T</tt> does not provide a default constructor. Also, in the case of many
-instances of <tt>ilist</tt>s, the memory overhead of the associated sentinels
-is wasted. To alleviate the situation with numerous and voluminous
-<tt>T</tt>-sentinels, sometimes a trick is employed, leading to <i>ghostly
-sentinels</i>.</p>
-
-<p>Ghostly sentinels are obtained by specially-crafted <tt>ilist_traits<T></tt>
-which superpose the sentinel with the <tt>ilist</tt> instance in memory. Pointer
-arithmetic is used to obtain the sentinel, which is relative to the
-<tt>ilist</tt>'s <tt>this</tt> pointer. The <tt>ilist</tt> is augmented by an
-extra pointer, which serves as the back-link of the sentinel. This is the only
-field in the ghostly sentinel which can be legally accessed.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_other">Other Sequential Container options</a>
-</div>
-
-<div class="doc_text">
-<p>Other STL containers are available, such as std::string.</p>
-
-<p>There are also various STL adapter classes such as std::queue,
-std::priority_queue, std::stack, etc. These provide simplified access to an
-underlying container but don't affect the cost of the container itself.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a>
-</div>
-
-<div class="doc_text">
-
-<p>Set-like containers are useful when you need to canonicalize multiple values
-into a single representation. There are several different choices for how to do
-this, providing various trade-offs.</p>
-
-</div>
-
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_sortedvectorset">A sorted 'vector'</a>
-</div>
-
-<div class="doc_text">
-
-<p>If you intend to insert a lot of elements, then do a lot of queries, a
-great approach is to use a vector (or other sequential container) with
-std::sort+std::unique to remove duplicates. This approach works really well if
-your usage pattern has these two distinct phases (insert then query), and can be
-coupled with a good choice of <a href="#ds_sequential">sequential container</a>.
-</p>
-
-<p>
-This combination provides the several nice properties: the result data is
-contiguous in memory (good for cache locality), has few allocations, is easy to
-address (iterators in the final vector are just indices or pointers), and can be
-efficiently queried with a standard binary or radix search.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_smallset">"llvm/ADT/SmallSet.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>If you have a set-like data structure that is usually small and whose elements
-are reasonably small, a <tt>SmallSet<Type, N></tt> is a good choice. This set
-has space for N elements in place (thus, if the set is dynamically smaller than
-N, no malloc traffic is required) and accesses them with a simple linear search.
-When the set grows beyond 'N' elements, it allocates a more expensive representation that
-guarantees efficient access (for most types, it falls back to std::set, but for
-pointers it uses something far better, <a
-href="#dss_smallptrset">SmallPtrSet</a>).</p>
-
-<p>The magic of this class is that it handles small sets extremely efficiently,
-but gracefully handles extremely large sets without loss of efficiency. The
-drawback is that the interface is quite small: it supports insertion, queries
-and erasing, but does not support iteration.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>SmallPtrSet has all the advantages of <tt>SmallSet</tt> (and a <tt>SmallSet</tt> of pointers is
-transparently implemented with a <tt>SmallPtrSet</tt>), but also supports iterators. If
-more than 'N' insertions are performed, a single quadratically
-probed hash table is allocated and grows as needed, providing extremely
-efficient access (constant time insertion/deleting/queries with low constant
-factors) and is very stingy with malloc traffic.</p>
-
-<p>Note that, unlike <tt>std::set</tt>, the iterators of <tt>SmallPtrSet</tt> are invalidated
-whenever an insertion occurs. Also, the values visited by the iterators are not
-visited in sorted order.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_denseset">"llvm/ADT/DenseSet.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-DenseSet is a simple quadratically probed hash table. It excels at supporting
-small values: it uses a single allocation to hold all of the pairs that
-are currently inserted in the set. DenseSet is a great way to unique small
-values that are not simple pointers (use <a
-href="#dss_smallptrset">SmallPtrSet</a> for pointers). Note that DenseSet has
-the same requirements for the value type that <a
-href="#dss_densemap">DenseMap</a> has.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-FoldingSet is an aggregate class that is really good at uniquing
-expensive-to-create or polymorphic objects. It is a combination of a chained
-hash table with intrusive links (uniqued objects are required to inherit from
-FoldingSetNode) that uses <a href="#dss_smallvector">SmallVector</a> as part of
-its ID process.</p>
-
-<p>Consider a case where you want to implement a "getOrCreateFoo" method for
-a complex object (for example, a node in the code generator). The client has a
-description of *what* it wants to generate (it knows the opcode and all the
-operands), but we don't want to 'new' a node, then try inserting it into a set
-only to find out it already exists, at which point we would have to delete it
-and return the node that already exists.
-</p>
-
-<p>To support this style of client, FoldingSet perform a query with a
-FoldingSetNodeID (which wraps SmallVector) that can be used to describe the
-element that we want to query for. The query either returns the element
-matching the ID or it returns an opaque ID that indicates where insertion should
-take place. Construction of the ID usually does not require heap traffic.</p>
-
-<p>Because FoldingSet uses intrusive links, it can support polymorphic objects
-in the set (for example, you can have SDNode instances mixed with LoadSDNodes).
-Because the elements are individually allocated, pointers to the elements are
-stable: inserting or removing elements does not invalidate any pointers to other
-elements.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_set"><set></a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>std::set</tt> is a reasonable all-around set class, which is decent at
-many things but great at nothing. std::set allocates memory for each element
-inserted (thus it is very malloc intensive) and typically stores three pointers
-per element in the set (thus adding a large amount of per-element space
-overhead). It offers guaranteed log(n) performance, which is not particularly
-fast from a complexity standpoint (particularly if the elements of the set are
-expensive to compare, like strings), and has extremely high constant factors for
-lookup, insertion and removal.</p>
-
-<p>The advantages of std::set are that its iterators are stable (deleting or
-inserting an element from the set does not affect iterators or pointers to other
-elements) and that iteration over the set is guaranteed to be in sorted order.
-If the elements in the set are large, then the relative overhead of the pointers
-and malloc traffic is not a big deal, but if the elements of the set are small,
-std::set is almost never a good choice.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_setvector">"llvm/ADT/SetVector.h"</a>
-</div>
-
-<div class="doc_text">
-<p>LLVM's SetVector<Type> is an adapter class that combines your choice of
-a set-like container along with a <a href="#ds_sequential">Sequential
-Container</a>. The important property
-that this provides is efficient insertion with uniquing (duplicate elements are
-ignored) with iteration support. It implements this by inserting elements into
-both a set-like container and the sequential container, using the set-like
-container for uniquing and the sequential container for iteration.
-</p>
-
-<p>The difference between SetVector and other sets is that the order of
-iteration is guaranteed to match the order of insertion into the SetVector.
-This property is really important for things like sets of pointers. Because
-pointer values are non-deterministic (e.g. vary across runs of the program on
-different machines), iterating over the pointers in the set will
-not be in a well-defined order.</p>
-
-<p>
-The drawback of SetVector is that it requires twice as much space as a normal
-set and has the sum of constant factors from the set-like container and the
-sequential container that it uses. Use it *only* if you need to iterate over
-the elements in a deterministic order. SetVector is also expensive to delete
-elements out of (linear time), unless you use it's "pop_back" method, which is
-faster.
-</p>
-
-<p>SetVector is an adapter class that defaults to using std::vector and std::set
-for the underlying containers, so it is quite expensive. However,
-<tt>"llvm/ADT/SetVector.h"</tt> also provides a SmallSetVector class, which
-defaults to using a SmallVector and SmallSet of a specified size. If you use
-this, and if your sets are dynamically smaller than N, you will save a lot of
-heap traffic.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_uniquevector">"llvm/ADT/UniqueVector.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-UniqueVector is similar to <a href="#dss_setvector">SetVector</a>, but it
-retains a unique ID for each element inserted into the set. It internally
-contains a map and a vector, and it assigns a unique ID for each value inserted
-into the set.</p>
-
-<p>UniqueVector is very expensive: its cost is the sum of the cost of
-maintaining both the map and vector, it has high complexity, high constant
-factors, and produces a lot of malloc traffic. It should be avoided.</p>
-
-</div>
-
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_otherset">Other Set-Like Container Options</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The STL provides several other options, such as std::multiset and the various
-"hash_set" like containers (whether from C++ TR1 or from the SGI library). We
-never use hash_set and unordered_set because they are generally very expensive
-(each insertion requires a malloc) and very non-portable.
-</p>
-
-<p>std::multiset is useful if you're not interested in elimination of
-duplicates, but has all the drawbacks of std::set. A sorted vector (where you
-don't delete duplicate entries) or some other approach is almost always
-better.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ds_map">Map-Like Containers (std::map, DenseMap, etc)</a>
-</div>
-
-<div class="doc_text">
-Map-like containers are useful when you want to associate data to a key. As
-usual, there are a lot of different ways to do this. :)
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_sortedvectormap">A sorted 'vector'</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-If your usage pattern follows a strict insert-then-query approach, you can
-trivially use the same approach as <a href="#dss_sortedvectorset">sorted vectors
-for set-like containers</a>. The only difference is that your query function
-(which uses std::lower_bound to get efficient log(n) lookup) should only compare
-the key, not both the key and value. This yields the same advantages as sorted
-vectors for sets.
-</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_stringmap">"llvm/ADT/StringMap.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-Strings are commonly used as keys in maps, and they are difficult to support
-efficiently: they are variable length, inefficient to hash and compare when
-long, expensive to copy, etc. StringMap is a specialized container designed to
-cope with these issues. It supports mapping an arbitrary range of bytes to an
-arbitrary other object.</p>
-
-<p>The StringMap implementation uses a quadratically-probed hash table, where
-the buckets store a pointer to the heap allocated entries (and some other
-stuff). The entries in the map must be heap allocated because the strings are
-variable length. The string data (key) and the element object (value) are
-stored in the same allocation with the string data immediately after the element
-object. This container guarantees the "<tt>(char*)(&Value+1)</tt>" points
-to the key string for a value.</p>
-
-<p>The StringMap is very fast for several reasons: quadratic probing is very
-cache efficient for lookups, the hash value of strings in buckets is not
-recomputed when lookup up an element, StringMap rarely has to touch the
-memory for unrelated objects when looking up a value (even when hash collisions
-happen), hash table growth does not recompute the hash values for strings
-already in the table, and each pair in the map is store in a single allocation
-(the string data is stored in the same allocation as the Value of a pair).</p>
-
-<p>StringMap also provides query methods that take byte ranges, so it only ever
-copies a string if a value is inserted into the table.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_indexedmap">"llvm/ADT/IndexedMap.h"</a>
-</div>
-
-<div class="doc_text">
-<p>
-IndexedMap is a specialized container for mapping small dense integers (or
-values that can be mapped to small dense integers) to some other type. It is
-internally implemented as a vector with a mapping function that maps the keys to
-the dense integer range.
-</p>
-
-<p>
-This is useful for cases like virtual registers in the LLVM code generator: they
-have a dense mapping that is offset by a compile-time constant (the first
-virtual register ID).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_densemap">"llvm/ADT/DenseMap.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-DenseMap is a simple quadratically probed hash table. It excels at supporting
-small keys and values: it uses a single allocation to hold all of the pairs that
-are currently inserted in the map. DenseMap is a great way to map pointers to
-pointers, or map other small types to each other.
-</p>
-
-<p>
-There are several aspects of DenseMap that you should be aware of, however. The
-iterators in a densemap are invalidated whenever an insertion occurs, unlike
-map. Also, because DenseMap allocates space for a large number of key/value
-pairs (it starts with 64 by default), it will waste a lot of space if your keys
-or values are large. Finally, you must implement a partial specialization of
-DenseMapInfo for the key that you want, if it isn't already supported. This
-is required to tell DenseMap about two special marker values (which can never be
-inserted into the map) that it needs internally.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_valuemap">"llvm/ADT/ValueMap.h"</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-ValueMap is a wrapper around a <a href="#dss_densemap">DenseMap</a> mapping
-Value*s (or subclasses) to another type. When a Value is deleted or RAUW'ed,
-ValueMap will update itself so the new version of the key is mapped to the same
-value, just as if the key were a WeakVH. You can configure exactly how this
-happens, and what else happens on these two events, by passing
-a <code>Config</code> parameter to the ValueMap template.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_map"><map></a>
-</div>
-
-<div class="doc_text">
-
-<p>
-std::map has similar characteristics to <a href="#dss_set">std::set</a>: it uses
-a single allocation per pair inserted into the map, it offers log(n) lookup with
-an extremely large constant factor, imposes a space penalty of 3 pointers per
-pair in the map, etc.</p>
-
-<p>std::map is most useful when your keys or values are very large, if you need
-to iterate over the collection in sorted order, or if you need stable iterators
-into the map (i.e. they don't get invalidated if an insertion or deletion of
-another element takes place).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_othermap">Other Map-Like Container Options</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The STL provides several other options, such as std::multimap and the various
-"hash_map" like containers (whether from C++ TR1 or from the SGI library). We
-never use hash_set and unordered_set because they are generally very expensive
-(each insertion requires a malloc) and very non-portable.</p>
-
-<p>std::multimap is useful if you want to map a key to multiple values, but has
-all the drawbacks of std::map. A sorted vector or some other approach is almost
-always better.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ds_string">String-like containers</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-TODO: const char* vs stringref vs smallstring vs std::string. Describe twine,
-xref to #string_apis.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ds_bit">Bit storage containers (BitVector, SparseBitVector)</a>
-</div>
-
-<div class="doc_text">
-<p>Unlike the other containers, there are only two bit storage containers, and
-choosing when to use each is relatively straightforward.</p>
-
-<p>One additional option is
-<tt>std::vector<bool></tt>: we discourage its use for two reasons 1) the
-implementation in many common compilers (e.g. commonly available versions of
-GCC) is extremely inefficient and 2) the C++ standards committee is likely to
-deprecate this container and/or change it significantly somehow. In any case,
-please don't use it.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_bitvector">BitVector</a>
-</div>
-
-<div class="doc_text">
-<p> The BitVector container provides a dynamic size set of bits for manipulation.
-It supports individual bit setting/testing, as well as set operations. The set
-operations take time O(size of bitvector), but operations are performed one word
-at a time, instead of one bit at a time. This makes the BitVector very fast for
-set operations compared to other containers. Use the BitVector when you expect
-the number of set bits to be high (IE a dense set).
-</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_smallbitvector">SmallBitVector</a>
-</div>
-
-<div class="doc_text">
-<p> The SmallBitVector container provides the same interface as BitVector, but
-it is optimized for the case where only a small number of bits, less than
-25 or so, are needed. It also transparently supports larger bit counts, but
-slightly less efficiently than a plain BitVector, so SmallBitVector should
-only be used when larger counts are rare.
-</p>
-
-<p>
-At this time, SmallBitVector does not support set operations (and, or, xor),
-and its operator[] does not provide an assignable lvalue.
-</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="dss_sparsebitvector">SparseBitVector</a>
-</div>
-
-<div class="doc_text">
-<p> The SparseBitVector container is much like BitVector, with one major
-difference: Only the bits that are set, are stored. This makes the
-SparseBitVector much more space efficient than BitVector when the set is sparse,
-as well as making set operations O(number of set bits) instead of O(size of
-universe). The downside to the SparseBitVector is that setting and testing of random bits is O(N), and on large SparseBitVectors, this can be slower than BitVector. In our implementation, setting or testing bits in sorted order
-(either forwards or reverse) is O(1) worst case. Testing and setting bits within 128 bits (depends on size) of the current bit is also O(1). As a general statement, testing/setting bits in a SparseBitVector is O(distance away from last set bit).
-</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="common">Helpful Hints for Common Operations</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This section describes how to perform some very simple transformations of
-LLVM code. This is meant to give examples of common idioms used, showing the
-practical side of LLVM transformations. <p> Because this is a "how-to" section,
-you should also read about the main classes that you will be working with. The
-<a href="#coreclasses">Core LLVM Class Hierarchy Reference</a> contains details
-and descriptions of the main classes that you should know about.</p>
-
-</div>
-
-<!-- NOTE: this section should be heavy on example code -->
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="inspection">Basic Inspection and Traversal Routines</a>
-</div>
-
-<div class="doc_text">
-
-<p>The LLVM compiler infrastructure have many different data structures that may
-be traversed. Following the example of the C++ standard template library, the
-techniques used to traverse these various data structures are all basically the
-same. For a enumerable sequence of values, the <tt>XXXbegin()</tt> function (or
-method) returns an iterator to the start of the sequence, the <tt>XXXend()</tt>
-function returns an iterator pointing to one past the last valid element of the
-sequence, and there is some <tt>XXXiterator</tt> data type that is common
-between the two operations.</p>
-
-<p>Because the pattern for iteration is common across many different aspects of
-the program representation, the standard template library algorithms may be used
-on them, and it is easier to remember how to iterate. First we show a few common
-examples of the data structures that need to be traversed. Other data
-structures are traversed in very similar ways.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="iterate_function">Iterating over the </a><a
- href="#BasicBlock"><tt>BasicBlock</tt></a>s in a <a
- href="#Function"><tt>Function</tt></a>
-</div>
-
-<div class="doc_text">
-
-<p>It's quite common to have a <tt>Function</tt> instance that you'd like to
-transform in some way; in particular, you'd like to manipulate its
-<tt>BasicBlock</tt>s. To facilitate this, you'll need to iterate over all of
-the <tt>BasicBlock</tt>s that constitute the <tt>Function</tt>. The following is
-an example that prints the name of a <tt>BasicBlock</tt> and the number of
-<tt>Instruction</tt>s it contains:</p>
-
-<div class="doc_code">
-<pre>
-// <i>func is a pointer to a Function instance</i>
-for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i)
- // <i>Print out the name of the basic block if it has one, and then the</i>
- // <i>number of instructions that it contains</i>
- errs() << "Basic block (name=" << i->getName() << ") has "
- << i->size() << " instructions.\n";
-</pre>
-</div>
-
-<p>Note that i can be used as if it were a pointer for the purposes of
-invoking member functions of the <tt>Instruction</tt> class. This is
-because the indirection operator is overloaded for the iterator
-classes. In the above code, the expression <tt>i->size()</tt> is
-exactly equivalent to <tt>(*i).size()</tt> just like you'd expect.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="iterate_basicblock">Iterating over the </a><a
- href="#Instruction"><tt>Instruction</tt></a>s in a <a
- href="#BasicBlock"><tt>BasicBlock</tt></a>
-</div>
-
-<div class="doc_text">
-
-<p>Just like when dealing with <tt>BasicBlock</tt>s in <tt>Function</tt>s, it's
-easy to iterate over the individual instructions that make up
-<tt>BasicBlock</tt>s. Here's a code snippet that prints out each instruction in
-a <tt>BasicBlock</tt>:</p>
-
-<div class="doc_code">
-<pre>
-// <i>blk is a pointer to a BasicBlock instance</i>
-for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
- // <i>The next statement works since operator<<(ostream&,...)</i>
- // <i>is overloaded for Instruction&</i>
- errs() << *i << "\n";
-</pre>
-</div>
-
-<p>However, this isn't really the best way to print out the contents of a
-<tt>BasicBlock</tt>! Since the ostream operators are overloaded for virtually
-anything you'll care about, you could have just invoked the print routine on the
-basic block itself: <tt>errs() << *blk << "\n";</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="iterate_institer">Iterating over the </a><a
- href="#Instruction"><tt>Instruction</tt></a>s in a <a
- href="#Function"><tt>Function</tt></a>
-</div>
-
-<div class="doc_text">
-
-<p>If you're finding that you commonly iterate over a <tt>Function</tt>'s
-<tt>BasicBlock</tt>s and then that <tt>BasicBlock</tt>'s <tt>Instruction</tt>s,
-<tt>InstIterator</tt> should be used instead. You'll need to include <a
-href="/doxygen/InstIterator_8h-source.html"><tt>llvm/Support/InstIterator.h</tt></a>,
-and then instantiate <tt>InstIterator</tt>s explicitly in your code. Here's a
-small example that shows how to dump all instructions in a function to the standard error stream:<p>
-
-<div class="doc_code">
-<pre>
-#include "<a href="/doxygen/InstIterator_8h-source.html">llvm/Support/InstIterator.h</a>"
-
-// <i>F is a pointer to a Function instance</i>
-for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
- errs() << *I << "\n";
-</pre>
-</div>
-
-<p>Easy, isn't it? You can also use <tt>InstIterator</tt>s to fill a
-work list with its initial contents. For example, if you wanted to
-initialize a work list to contain all instructions in a <tt>Function</tt>
-F, all you would need to do is something like:</p>
-
-<div class="doc_code">
-<pre>
-std::set<Instruction*> worklist;
-// or better yet, SmallPtrSet<Instruction*, 64> worklist;
-
-for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
- worklist.insert(&*I);
-</pre>
-</div>
-
-<p>The STL set <tt>worklist</tt> would now contain all instructions in the
-<tt>Function</tt> pointed to by F.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="iterate_convert">Turning an iterator into a class pointer (and
- vice-versa)</a>
-</div>
-
-<div class="doc_text">
-
-<p>Sometimes, it'll be useful to grab a reference (or pointer) to a class
-instance when all you've got at hand is an iterator. Well, extracting
-a reference or a pointer from an iterator is very straight-forward.
-Assuming that <tt>i</tt> is a <tt>BasicBlock::iterator</tt> and <tt>j</tt>
-is a <tt>BasicBlock::const_iterator</tt>:</p>
-
-<div class="doc_code">
-<pre>
-Instruction& inst = *i; // <i>Grab reference to instruction reference</i>
-Instruction* pinst = &*i; // <i>Grab pointer to instruction reference</i>
-const Instruction& inst = *j;
-</pre>
-</div>
-
-<p>However, the iterators you'll be working with in the LLVM framework are
-special: they will automatically convert to a ptr-to-instance type whenever they
-need to. Instead of dereferencing the iterator and then taking the address of
-the result, you can simply assign the iterator to the proper pointer type and
-you get the dereference and address-of operation as a result of the assignment
-(behind the scenes, this is a result of overloading casting mechanisms). Thus
-the last line of the last example,</p>
-
-<div class="doc_code">
-<pre>
-Instruction *pinst = &*i;
-</pre>
-</div>
-
-<p>is semantically equivalent to</p>
-
-<div class="doc_code">
-<pre>
-Instruction *pinst = i;
-</pre>
-</div>
-
-<p>It's also possible to turn a class pointer into the corresponding iterator,
-and this is a constant time operation (very efficient). The following code
-snippet illustrates use of the conversion constructors provided by LLVM
-iterators. By using these, you can explicitly grab the iterator of something
-without actually obtaining it via iteration over some structure:</p>
-
-<div class="doc_code">
-<pre>
-void printNextInstruction(Instruction* inst) {
- BasicBlock::iterator it(inst);
- ++it; // <i>After this line, it refers to the instruction after *inst</i>
- if (it != inst->getParent()->end()) errs() << *it << "\n";
-}
-</pre>
-</div>
-
-<p>Unfortunately, these implicit conversions come at a cost; they prevent
-these iterators from conforming to standard iterator conventions, and thus
-from being usable with standard algorithms and containers. For example, they
-prevent the following code, where <tt>B</tt> is a <tt>BasicBlock</tt>,
-from compiling:</p>
-
-<div class="doc_code">
-<pre>
- llvm::SmallVector<llvm::Instruction *, 16>(B->begin(), B->end());
-</pre>
-</div>
-
-<p>Because of this, these implicit conversions may be removed some day,
-and <tt>operator*</tt> changed to return a pointer instead of a reference.</p>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="iterate_complex">Finding call sites: a slightly more complex
- example</a>
-</div>
-
-<div class="doc_text">
-
-<p>Say that you're writing a FunctionPass and would like to count all the
-locations in the entire module (that is, across every <tt>Function</tt>) where a
-certain function (i.e., some <tt>Function</tt>*) is already in scope. As you'll
-learn later, you may want to use an <tt>InstVisitor</tt> to accomplish this in a
-much more straight-forward manner, but this example will allow us to explore how
-you'd do it if you didn't have <tt>InstVisitor</tt> around. In pseudo-code, this
-is what we want to do:</p>
-
-<div class="doc_code">
-<pre>
-initialize callCounter to zero
-for each Function f in the Module
- for each BasicBlock b in f
- for each Instruction i in b
- if (i is a CallInst and calls the given function)
- increment callCounter
-</pre>
-</div>
-
-<p>And the actual code is (remember, because we're writing a
-<tt>FunctionPass</tt>, our <tt>FunctionPass</tt>-derived class simply has to
-override the <tt>runOnFunction</tt> method):</p>
-
-<div class="doc_code">
-<pre>
-Function* targetFunc = ...;
-
-class OurFunctionPass : public FunctionPass {
- public:
- OurFunctionPass(): callCounter(0) { }
-
- virtual runOnFunction(Function& F) {
- for (Function::iterator b = F.begin(), be = F.end(); b != be; ++b) {
- for (BasicBlock::iterator i = b->begin(), ie = b->end(); i != ie; ++i) {
- if (<a href="#CallInst">CallInst</a>* callInst = <a href="#isa">dyn_cast</a><<a
- href="#CallInst">CallInst</a>>(&*i)) {
- // <i>We know we've encountered a call instruction, so we</i>
- // <i>need to determine if it's a call to the</i>
- // <i>function pointed to by m_func or not.</i>
- if (callInst->getCalledFunction() == targetFunc)
- ++callCounter;
- }
- }
- }
- }
-
- private:
- unsigned callCounter;
-};
-</pre>
-</div>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="calls_and_invokes">Treating calls and invokes the same way</a>
-</div>
-
-<div class="doc_text">
-
-<p>You may have noticed that the previous example was a bit oversimplified in
-that it did not deal with call sites generated by 'invoke' instructions. In
-this, and in other situations, you may find that you want to treat
-<tt>CallInst</tt>s and <tt>InvokeInst</tt>s the same way, even though their
-most-specific common base class is <tt>Instruction</tt>, which includes lots of
-less closely-related things. For these cases, LLVM provides a handy wrapper
-class called <a
-href="http://llvm.org/doxygen/classllvm_1_1CallSite.html"><tt>CallSite</tt></a>.
-It is essentially a wrapper around an <tt>Instruction</tt> pointer, with some
-methods that provide functionality common to <tt>CallInst</tt>s and
-<tt>InvokeInst</tt>s.</p>
-
-<p>This class has "value semantics": it should be passed by value, not by
-reference and it should not be dynamically allocated or deallocated using
-<tt>operator new</tt> or <tt>operator delete</tt>. It is efficiently copyable,
-assignable and constructable, with costs equivalents to that of a bare pointer.
-If you look at its definition, it has only a single pointer member.</p>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="iterate_chains">Iterating over def-use & use-def chains</a>
-</div>
-
-<div class="doc_text">
-
-<p>Frequently, we might have an instance of the <a
-href="/doxygen/classllvm_1_1Value.html">Value Class</a> and we want to
-determine which <tt>User</tt>s use the <tt>Value</tt>. The list of all
-<tt>User</tt>s of a particular <tt>Value</tt> is called a <i>def-use</i> chain.
-For example, let's say we have a <tt>Function*</tt> named <tt>F</tt> to a
-particular function <tt>foo</tt>. Finding all of the instructions that
-<i>use</i> <tt>foo</tt> is as simple as iterating over the <i>def-use</i> chain
-of <tt>F</tt>:</p>
-
-<div class="doc_code">
-<pre>
-Function *F = ...;
-
-for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i)
- if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
- errs() << "F is used in instruction:\n";
- errs() << *Inst << "\n";
- }
-</pre>
-</div>
-
-<p>Note that dereferencing a <tt>Value::use_iterator</tt> is not a very cheap
-operation. Instead of performing <tt>*i</tt> above several times, consider
-doing it only once in the loop body and reusing its result.</p>
-
-<p>Alternatively, it's common to have an instance of the <a
-href="/doxygen/classllvm_1_1User.html">User Class</a> and need to know what
-<tt>Value</tt>s are used by it. The list of all <tt>Value</tt>s used by a
-<tt>User</tt> is known as a <i>use-def</i> chain. Instances of class
-<tt>Instruction</tt> are common <tt>User</tt>s, so we might want to iterate over
-all of the values that a particular instruction uses (that is, the operands of
-the particular <tt>Instruction</tt>):</p>
-
-<div class="doc_code">
-<pre>
-Instruction *pi = ...;
-
-for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
- Value *v = *i;
- // <i>...</i>
-}
-</pre>
-</div>
-
-<p>Declaring objects as <tt>const</tt> is an important tool of enforcing
-mutation free algorithms (such as analyses, etc.). For this purpose above
-iterators come in constant flavors as <tt>Value::const_use_iterator</tt>
-and <tt>Value::const_op_iterator</tt>. They automatically arise when
-calling <tt>use/op_begin()</tt> on <tt>const Value*</tt>s or
-<tt>const User*</tt>s respectively. Upon dereferencing, they return
-<tt>const Use*</tt>s. Otherwise the above patterns remain unchanged.</p>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="iterate_preds">Iterating over predecessors &
-successors of blocks</a>
-</div>
-
-<div class="doc_text">
-
-<p>Iterating over the predecessors and successors of a block is quite easy
-with the routines defined in <tt>"llvm/Support/CFG.h"</tt>. Just use code like
-this to iterate over all predecessors of BB:</p>
-
-<div class="doc_code">
-<pre>
-#include "llvm/Support/CFG.h"
-BasicBlock *BB = ...;
-
-for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++PI) {
- BasicBlock *Pred = *PI;
- // <i>...</i>
-}
-</pre>
-</div>
-
-<p>Similarly, to iterate over successors use
-succ_iterator/succ_begin/succ_end.</p>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="simplechanges">Making simple changes</a>
-</div>
-
-<div class="doc_text">
-
-<p>There are some primitive transformation operations present in the LLVM
-infrastructure that are worth knowing about. When performing
-transformations, it's fairly common to manipulate the contents of basic
-blocks. This section describes some of the common methods for doing so
-and gives example code.</p>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="schanges_creating">Creating and inserting new
- <tt>Instruction</tt>s</a>
-</div>
-
-<div class="doc_text">
-
-<p><i>Instantiating Instructions</i></p>
-
-<p>Creation of <tt>Instruction</tt>s is straight-forward: simply call the
-constructor for the kind of instruction to instantiate and provide the necessary
-parameters. For example, an <tt>AllocaInst</tt> only <i>requires</i> a
-(const-ptr-to) <tt>Type</tt>. Thus:</p>
-
-<div class="doc_code">
-<pre>
-AllocaInst* ai = new AllocaInst(Type::Int32Ty);
-</pre>
-</div>
-
-<p>will create an <tt>AllocaInst</tt> instance that represents the allocation of
-one integer in the current stack frame, at run time. Each <tt>Instruction</tt>
-subclass is likely to have varying default parameters which change the semantics
-of the instruction, so refer to the <a
-href="/doxygen/classllvm_1_1Instruction.html">doxygen documentation for the subclass of
-Instruction</a> that you're interested in instantiating.</p>
-
-<p><i>Naming values</i></p>
-
-<p>It is very useful to name the values of instructions when you're able to, as
-this facilitates the debugging of your transformations. If you end up looking
-at generated LLVM machine code, you definitely want to have logical names
-associated with the results of instructions! By supplying a value for the
-<tt>Name</tt> (default) parameter of the <tt>Instruction</tt> constructor, you
-associate a logical name with the result of the instruction's execution at
-run time. For example, say that I'm writing a transformation that dynamically
-allocates space for an integer on the stack, and that integer is going to be
-used as some kind of index by some other code. To accomplish this, I place an
-<tt>AllocaInst</tt> at the first point in the first <tt>BasicBlock</tt> of some
-<tt>Function</tt>, and I'm intending to use it within the same
-<tt>Function</tt>. I might do:</p>
-
-<div class="doc_code">
-<pre>
-AllocaInst* pa = new AllocaInst(Type::Int32Ty, 0, "indexLoc");
-</pre>
-</div>
-
-<p>where <tt>indexLoc</tt> is now the logical name of the instruction's
-execution value, which is a pointer to an integer on the run time stack.</p>
-
-<p><i>Inserting instructions</i></p>
-
-<p>There are essentially two ways to insert an <tt>Instruction</tt>
-into an existing sequence of instructions that form a <tt>BasicBlock</tt>:</p>
-
-<ul>
- <li>Insertion into an explicit instruction list
-
- <p>Given a <tt>BasicBlock* pb</tt>, an <tt>Instruction* pi</tt> within that
- <tt>BasicBlock</tt>, and a newly-created instruction we wish to insert
- before <tt>*pi</tt>, we do the following: </p>
-
-<div class="doc_code">
-<pre>
-BasicBlock *pb = ...;
-Instruction *pi = ...;
-Instruction *newInst = new Instruction(...);
-
-pb->getInstList().insert(pi, newInst); // <i>Inserts newInst before pi in pb</i>
-</pre>
-</div>
-
- <p>Appending to the end of a <tt>BasicBlock</tt> is so common that
- the <tt>Instruction</tt> class and <tt>Instruction</tt>-derived
- classes provide constructors which take a pointer to a
- <tt>BasicBlock</tt> to be appended to. For example code that
- looked like: </p>
-
-<div class="doc_code">
-<pre>
-BasicBlock *pb = ...;
-Instruction *newInst = new Instruction(...);
-
-pb->getInstList().push_back(newInst); // <i>Appends newInst to pb</i>
-</pre>
-</div>
-
- <p>becomes: </p>
-
-<div class="doc_code">
-<pre>
-BasicBlock *pb = ...;
-Instruction *newInst = new Instruction(..., pb);
-</pre>
-</div>
-
- <p>which is much cleaner, especially if you are creating
- long instruction streams.</p></li>
-
- <li>Insertion into an implicit instruction list
-
- <p><tt>Instruction</tt> instances that are already in <tt>BasicBlock</tt>s
- are implicitly associated with an existing instruction list: the instruction
- list of the enclosing basic block. Thus, we could have accomplished the same
- thing as the above code without being given a <tt>BasicBlock</tt> by doing:
- </p>
-
-<div class="doc_code">
-<pre>
-Instruction *pi = ...;
-Instruction *newInst = new Instruction(...);
-
-pi->getParent()->getInstList().insert(pi, newInst);
-</pre>
-</div>
-
- <p>In fact, this sequence of steps occurs so frequently that the
- <tt>Instruction</tt> class and <tt>Instruction</tt>-derived classes provide
- constructors which take (as a default parameter) a pointer to an
- <tt>Instruction</tt> which the newly-created <tt>Instruction</tt> should
- precede. That is, <tt>Instruction</tt> constructors are capable of
- inserting the newly-created instance into the <tt>BasicBlock</tt> of a
- provided instruction, immediately before that instruction. Using an
- <tt>Instruction</tt> constructor with a <tt>insertBefore</tt> (default)
- parameter, the above code becomes:</p>
-
-<div class="doc_code">
-<pre>
-Instruction* pi = ...;
-Instruction* newInst = new Instruction(..., pi);
-</pre>
-</div>
-
- <p>which is much cleaner, especially if you're creating a lot of
- instructions and adding them to <tt>BasicBlock</tt>s.</p></li>
-</ul>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a>
-</div>
-
-<div class="doc_text">
-
-<p>Deleting an instruction from an existing sequence of instructions that form a
-<a href="#BasicBlock"><tt>BasicBlock</tt></a> is very straight-forward. First,
-you must have a pointer to the instruction that you wish to delete. Second, you
-need to obtain the pointer to that instruction's basic block. You use the
-pointer to the basic block to get its list of instructions and then use the
-erase function to remove your instruction. For example:</p>
-
-<div class="doc_code">
-<pre>
-<a href="#Instruction">Instruction</a> *I = .. ;
-I->eraseFromParent();
-</pre>
-</div>
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="schanges_replacing">Replacing an <tt>Instruction</tt> with another
- <tt>Value</tt></a>
-</div>
-
-<div class="doc_text">
-
-<p><i>Replacing individual instructions</i></p>
-
-<p>Including "<a href="/doxygen/BasicBlockUtils_8h-source.html">llvm/Transforms/Utils/BasicBlockUtils.h</a>"
-permits use of two very useful replace functions: <tt>ReplaceInstWithValue</tt>
-and <tt>ReplaceInstWithInst</tt>.</p>
-
-<h4><a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a></h4>
-
-<ul>
- <li><tt>ReplaceInstWithValue</tt>
-
- <p>This function replaces all uses of a given instruction with a value,
- and then removes the original instruction. The following example
- illustrates the replacement of the result of a particular
- <tt>AllocaInst</tt> that allocates memory for a single integer with a null
- pointer to an integer.</p>
-
-<div class="doc_code">
-<pre>
-AllocaInst* instToReplace = ...;
-BasicBlock::iterator ii(instToReplace);
-
-ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
- Constant::getNullValue(PointerType::getUnqual(Type::Int32Ty)));
-</pre></div></li>
-
- <li><tt>ReplaceInstWithInst</tt>
-
- <p>This function replaces a particular instruction with another
- instruction, inserting the new instruction into the basic block at the
- location where the old instruction was, and replacing any uses of the old
- instruction with the new instruction. The following example illustrates
- the replacement of one <tt>AllocaInst</tt> with another.</p>
-
-<div class="doc_code">
-<pre>
-AllocaInst* instToReplace = ...;
-BasicBlock::iterator ii(instToReplace);
-
-ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
- new AllocaInst(Type::Int32Ty, 0, "ptrToReplacedInt"));
-</pre></div></li>
-</ul>
-
-<p><i>Replacing multiple uses of <tt>User</tt>s and <tt>Value</tt>s</i></p>
-
-<p>You can use <tt>Value::replaceAllUsesWith</tt> and
-<tt>User::replaceUsesOfWith</tt> to change more than one use at a time. See the
-doxygen documentation for the <a href="/doxygen/classllvm_1_1Value.html">Value Class</a>
-and <a href="/doxygen/classllvm_1_1User.html">User Class</a>, respectively, for more
-information.</p>
-
-<!-- Value::replaceAllUsesWith User::replaceUsesOfWith Point out:
-include/llvm/Transforms/Utils/ especially BasicBlockUtils.h with:
-ReplaceInstWithValue, ReplaceInstWithInst -->
-
-</div>
-
-<!--_______________________________________________________________________-->
-<div class="doc_subsubsection">
- <a name="schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a>
-</div>
-
-<div class="doc_text">
-
-<p>Deleting a global variable from a module is just as easy as deleting an
-Instruction. First, you must have a pointer to the global variable that you wish
- to delete. You use this pointer to erase it from its parent, the module.
- For example:</p>
-
-<div class="doc_code">
-<pre>
-<a href="#GlobalVariable">GlobalVariable</a> *GV = .. ;
-
-GV->eraseFromParent();
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="create_types">How to Create Types</a>
-</div>
-
-<div class="doc_text">
-
-<p>In generating IR, you may need some complex types. If you know these types
-statically, you can use <tt>TypeBuilder<...>::get()</tt>, defined
-in <tt>llvm/Support/TypeBuilder.h</tt>, to retrieve them. <tt>TypeBuilder</tt>
-has two forms depending on whether you're building types for cross-compilation
-or native library use. <tt>TypeBuilder<T, true></tt> requires
-that <tt>T</tt> be independent of the host environment, meaning that it's built
-out of types from
-the <a href="/doxygen/namespacellvm_1_1types.html"><tt>llvm::types</tt></a>
-namespace and pointers, functions, arrays, etc. built of
-those. <tt>TypeBuilder<T, false></tt> additionally allows native C types
-whose size may depend on the host compiler. For example,</p>
-
-<div class="doc_code">
-<pre>
-FunctionType *ft = TypeBuilder<types::i<8>(types::i<32>*), true>::get();
-</pre>
-</div>
-
-<p>is easier to read and write than the equivalent</p>
-
-<div class="doc_code">
-<pre>
-std::vector<const Type*> params;
-params.push_back(PointerType::getUnqual(Type::Int32Ty));
-FunctionType *ft = FunctionType::get(Type::Int8Ty, params, false);
-</pre>
-</div>
-
-<p>See the <a href="/doxygen/TypeBuilder_8h-source.html#l00001">class
-comment</a> for more details.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="threading">Threads and LLVM</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>
-This section describes the interaction of the LLVM APIs with multithreading,
-both on the part of client applications, and in the JIT, in the hosted
-application.
-</p>
-
-<p>
-Note that LLVM's support for multithreading is still relatively young. Up
-through version 2.5, the execution of threaded hosted applications was
-supported, but not threaded client access to the APIs. While this use case is
-now supported, clients <em>must</em> adhere to the guidelines specified below to
-ensure proper operation in multithreaded mode.
-</p>
-
-<p>
-Note that, on Unix-like platforms, LLVM requires the presence of GCC's atomic
-intrinsics in order to support threaded operation. If you need a
-multhreading-capable LLVM on a platform without a suitably modern system
-compiler, consider compiling LLVM and LLVM-GCC in single-threaded mode, and
-using the resultant compiler to build a copy of LLVM with multithreading
-support.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="startmultithreaded">Entering and Exiting Multithreaded Mode</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-In order to properly protect its internal data structures while avoiding
-excessive locking overhead in the single-threaded case, the LLVM must intialize
-certain data structures necessary to provide guards around its internals. To do
-so, the client program must invoke <tt>llvm_start_multithreaded()</tt> before
-making any concurrent LLVM API calls. To subsequently tear down these
-structures, use the <tt>llvm_stop_multithreaded()</tt> call. You can also use
-the <tt>llvm_is_multithreaded()</tt> call to check the status of multithreaded
-mode.
-</p>
-
-<p>
-Note that both of these calls must be made <em>in isolation</em>. That is to
-say that no other LLVM API calls may be executing at any time during the
-execution of <tt>llvm_start_multithreaded()</tt> or <tt>llvm_stop_multithreaded
-</tt>. It's is the client's responsibility to enforce this isolation.
-</p>
-
-<p>
-The return value of <tt>llvm_start_multithreaded()</tt> indicates the success or
-failure of the initialization. Failure typically indicates that your copy of
-LLVM was built without multithreading support, typically because GCC atomic
-intrinsics were not found in your system compiler. In this case, the LLVM API
-will not be safe for concurrent calls. However, it <em>will</em> be safe for
-hosting threaded applications in the JIT, though <a href="#jitthreading">care
-must be taken</a> to ensure that side exits and the like do not accidentally
-result in concurrent LLVM API calls.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="shutdown">Ending Execution with <tt>llvm_shutdown()</tt></a>
-</div>
-
-<div class="doc_text">
-<p>
-When you are done using the LLVM APIs, you should call <tt>llvm_shutdown()</tt>
-to deallocate memory used for internal structures. This will also invoke
-<tt>llvm_stop_multithreaded()</tt> if LLVM is operating in multithreaded mode.
-As such, <tt>llvm_shutdown()</tt> requires the same isolation guarantees as
-<tt>llvm_stop_multithreaded()</tt>.
-</p>
-
-<p>
-Note that, if you use scope-based shutdown, you can use the
-<tt>llvm_shutdown_obj</tt> class, which calls <tt>llvm_shutdown()</tt> in its
-destructor.
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="managedstatic">Lazy Initialization with <tt>ManagedStatic</tt></a>
-</div>
-
-<div class="doc_text">
-<p>
-<tt>ManagedStatic</tt> is a utility class in LLVM used to implement static
-initialization of static resources, such as the global type tables. Before the
-invocation of <tt>llvm_shutdown()</tt>, it implements a simple lazy
-initialization scheme. Once <tt>llvm_start_multithreaded()</tt> returns,
-however, it uses double-checked locking to implement thread-safe lazy
-initialization.
-</p>
-
-<p>
-Note that, because no other threads are allowed to issue LLVM API calls before
-<tt>llvm_start_multithreaded()</tt> returns, it is possible to have
-<tt>ManagedStatic</tt>s of <tt>llvm::sys::Mutex</tt>s.
-</p>
-
-<p>
-The <tt>llvm_acquire_global_lock()</tt> and <tt>llvm_release_global_lock</tt>
-APIs provide access to the global lock used to implement the double-checked
-locking for lazy initialization. These should only be used internally to LLVM,
-and only if you know what you're doing!
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="llvmcontext">Achieving Isolation with <tt>LLVMContext</tt></a>
-</div>
-
-<div class="doc_text">
-<p>
-<tt>LLVMContext</tt> is an opaque class in the LLVM API which clients can use
-to operate multiple, isolated instances of LLVM concurrently within the same
-address space. For instance, in a hypothetical compile-server, the compilation
-of an individual translation unit is conceptually independent from all the
-others, and it would be desirable to be able to compile incoming translation
-units concurrently on independent server threads. Fortunately,
-<tt>LLVMContext</tt> exists to enable just this kind of scenario!
-</p>
-
-<p>
-Conceptually, <tt>LLVMContext</tt> provides isolation. Every LLVM entity
-(<tt>Module</tt>s, <tt>Value</tt>s, <tt>Type</tt>s, <tt>Constant</tt>s, etc.)
-in LLVM's in-memory IR belongs to an <tt>LLVMContext</tt>. Entities in
-different contexts <em>cannot</em> interact with each other: <tt>Module</tt>s in
-different contexts cannot be linked together, <tt>Function</tt>s cannot be added
-to <tt>Module</tt>s in different contexts, etc. What this means is that is is
-safe to compile on multiple threads simultaneously, as long as no two threads
-operate on entities within the same context.
-</p>
-
-<p>
-In practice, very few places in the API require the explicit specification of a
-<tt>LLVMContext</tt>, other than the <tt>Type</tt> creation/lookup APIs.
-Because every <tt>Type</tt> carries a reference to its owning context, most
-other entities can determine what context they belong to by looking at their
-own <tt>Type</tt>. If you are adding new entities to LLVM IR, please try to
-maintain this interface design.
-</p>
-
-<p>
-For clients that do <em>not</em> require the benefits of isolation, LLVM
-provides a convenience API <tt>getGlobalContext()</tt>. This returns a global,
-lazily initialized <tt>LLVMContext</tt> that may be used in situations where
-isolation is not a concern.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="jitthreading">Threads and the JIT</a>
-</div>
-
-<div class="doc_text">
-<p>
-LLVM's "eager" JIT compiler is safe to use in threaded programs. Multiple
-threads can call <tt>ExecutionEngine::getPointerToFunction()</tt> or
-<tt>ExecutionEngine::runFunction()</tt> concurrently, and multiple threads can
-run code output by the JIT concurrently. The user must still ensure that only
-one thread accesses IR in a given <tt>LLVMContext</tt> while another thread
-might be modifying it. One way to do that is to always hold the JIT lock while
-accessing IR outside the JIT (the JIT <em>modifies</em> the IR by adding
-<tt>CallbackVH</tt>s). Another way is to only
-call <tt>getPointerToFunction()</tt> from the <tt>LLVMContext</tt>'s thread.
-</p>
-
-<p>When the JIT is configured to compile lazily (using
-<tt>ExecutionEngine::DisableLazyCompilation(false)</tt>), there is currently a
-<a href="http://llvm.org/bugs/show_bug.cgi?id=5184">race condition</a> in
-updating call sites after a function is lazily-jitted. It's still possible to
-use the lazy JIT in a threaded program if you ensure that only one thread at a
-time can call any particular lazy stub and that the JIT lock guards any IR
-access, but we suggest using only the eager JIT in threaded programs.
-</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="advanced">Advanced Topics</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>
-This section describes some of the advanced or obscure API's that most clients
-do not need to be aware of. These API's tend manage the inner workings of the
-LLVM system, and only need to be accessed in unusual circumstances.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="TypeResolve">LLVM Type Resolution</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The LLVM type system has a very simple goal: allow clients to compare types for
-structural equality with a simple pointer comparison (aka a shallow compare).
-This goal makes clients much simpler and faster, and is used throughout the LLVM
-system.
-</p>
-
-<p>
-Unfortunately achieving this goal is not a simple matter. In particular,
-recursive types and late resolution of opaque types makes the situation very
-difficult to handle. Fortunately, for the most part, our implementation makes
-most clients able to be completely unaware of the nasty internal details. The
-primary case where clients are exposed to the inner workings of it are when
-building a recursive type. In addition to this case, the LLVM bitcode reader,
-assembly parser, and linker also have to be aware of the inner workings of this
-system.
-</p>
-
-<p>
-For our purposes below, we need three concepts. First, an "Opaque Type" is
-exactly as defined in the <a href="LangRef.html#t_opaque">language
-reference</a>. Second an "Abstract Type" is any type which includes an
-opaque type as part of its type graph (for example "<tt>{ opaque, i32 }</tt>").
-Third, a concrete type is a type that is not an abstract type (e.g. "<tt>{ i32,
-float }</tt>").
-</p>
-
-</div>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="BuildRecType">Basic Recursive Type Construction</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-Because the most common question is "how do I build a recursive type with LLVM",
-we answer it now and explain it as we go. Here we include enough to cause this
-to be emitted to an output .ll file:
-</p>
-
-<div class="doc_code">
-<pre>
-%mylist = type { %mylist*, i32 }
-</pre>
-</div>
-
-<p>
-To build this, use the following LLVM APIs:
-</p>
-
-<div class="doc_code">
-<pre>
-// <i>Create the initial outer struct</i>
-<a href="#PATypeHolder">PATypeHolder</a> StructTy = OpaqueType::get();
-std::vector<const Type*> Elts;
-Elts.push_back(PointerType::getUnqual(StructTy));
-Elts.push_back(Type::Int32Ty);
-StructType *NewSTy = StructType::get(Elts);
-
-// <i>At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that</i>
-// <i>the struct and the opaque type are actually the same.</i>
-cast<OpaqueType>(StructTy.get())-><a href="#refineAbstractTypeTo">refineAbstractTypeTo</a>(NewSTy);
-
-// <i>NewSTy is potentially invalidated, but StructTy (a <a href="#PATypeHolder">PATypeHolder</a>) is</i>
-// <i>kept up-to-date</i>
-NewSTy = cast<StructType>(StructTy.get());
-
-// <i>Add a name for the type to the module symbol table (optional)</i>
-MyModule->addTypeName("mylist", NewSTy);
-</pre>
-</div>
-
-<p>
-This code shows the basic approach used to build recursive types: build a
-non-recursive type using 'opaque', then use type unification to close the cycle.
-The type unification step is performed by the <tt><a
-href="#refineAbstractTypeTo">refineAbstractTypeTo</a></tt> method, which is
-described next. After that, we describe the <a
-href="#PATypeHolder">PATypeHolder class</a>.
-</p>
-
-</div>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a>
-</div>
-
-<div class="doc_text">
-<p>
-The <tt>refineAbstractTypeTo</tt> method starts the type unification process.
-While this method is actually a member of the DerivedType class, it is most
-often used on OpaqueType instances. Type unification is actually a recursive
-process. After unification, types can become structurally isomorphic to
-existing types, and all duplicates are deleted (to preserve pointer equality).
-</p>
-
-<p>
-In the example above, the OpaqueType object is definitely deleted.
-Additionally, if there is an "{ \2*, i32}" type already created in the system,
-the pointer and struct type created are <b>also</b> deleted. Obviously whenever
-a type is deleted, any "Type*" pointers in the program are invalidated. As
-such, it is safest to avoid having <i>any</i> "Type*" pointers to abstract types
-live across a call to <tt>refineAbstractTypeTo</tt> (note that non-abstract
-types can never move or be deleted). To deal with this, the <a
-href="#PATypeHolder">PATypeHolder</a> class is used to maintain a stable
-reference to a possibly refined type, and the <a
-href="#AbstractTypeUser">AbstractTypeUser</a> class is used to update more
-complex datastructures.
-</p>
-
-</div>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="PATypeHolder">The PATypeHolder Class</a>
-</div>
-
-<div class="doc_text">
-<p>
-PATypeHolder is a form of a "smart pointer" for Type objects. When VMCore
-happily goes about nuking types that become isomorphic to existing types, it
-automatically updates all PATypeHolder objects to point to the new type. In the
-example above, this allows the code to maintain a pointer to the resultant
-resolved recursive type, even though the Type*'s are potentially invalidated.
-</p>
-
-<p>
-PATypeHolder is an extremely light-weight object that uses a lazy union-find
-implementation to update pointers. For example the pointer from a Value to its
-Type is maintained by PATypeHolder objects.
-</p>
-
-</div>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="AbstractTypeUser">The AbstractTypeUser Class</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-Some data structures need more to perform more complex updates when types get
-resolved. To support this, a class can derive from the AbstractTypeUser class.
-This class
-allows it to get callbacks when certain types are resolved. To register to get
-callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser
-methods can be called on a type. Note that these methods only work for <i>
- abstract</i> types. Concrete types (those that do not include any opaque
-objects) can never be refined.
-</p>
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="SymbolTable">The <tt>ValueSymbolTable</tt> and
- <tt>TypeSymbolTable</tt> classes</a>
-</div>
-
-<div class="doc_text">
-<p>The <tt><a href="http://llvm.org/doxygen/classllvm_1_1ValueSymbolTable.html">
-ValueSymbolTable</a></tt> class provides a symbol table that the <a
-href="#Function"><tt>Function</tt></a> and <a href="#Module">
-<tt>Module</tt></a> classes use for naming value definitions. The symbol table
-can provide a name for any <a href="#Value"><tt>Value</tt></a>.
-The <tt><a href="http://llvm.org/doxygen/classllvm_1_1TypeSymbolTable.html">
-TypeSymbolTable</a></tt> class is used by the <tt>Module</tt> class to store
-names for types.</p>
-
-<p>Note that the <tt>SymbolTable</tt> class should not be directly accessed
-by most clients. It should only be used when iteration over the symbol table
-names themselves are required, which is very special purpose. Note that not
-all LLVM
-<tt><a href="#Value">Value</a></tt>s have names, and those without names (i.e. they have
-an empty name) do not exist in the symbol table.
-</p>
-
-<p>These symbol tables support iteration over the values/types in the symbol
-table with <tt>begin/end/iterator</tt> and supports querying to see if a
-specific name is in the symbol table (with <tt>lookup</tt>). The
-<tt>ValueSymbolTable</tt> class exposes no public mutator methods, instead,
-simply call <tt>setName</tt> on a value, which will autoinsert it into the
-appropriate symbol table. For types, use the Module::addTypeName method to
-insert entries into the symbol table.</p>
-
-</div>
-
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="UserLayout">The <tt>User</tt> and owned <tt>Use</tt> classes' memory layout</a>
-</div>
-
-<div class="doc_text">
-<p>The <tt><a href="http://llvm.org/doxygen/classllvm_1_1User.html">
-User</a></tt> class provides a basis for expressing the ownership of <tt>User</tt>
-towards other <tt><a href="http://llvm.org/doxygen/classllvm_1_1Value.html">
-Value</a></tt>s. The <tt><a href="http://llvm.org/doxygen/classllvm_1_1Use.html">
-Use</a></tt> helper class is employed to do the bookkeeping and to facilitate <i>O(1)</i>
-addition and removal.</p>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="Use2User">Interaction and relationship between <tt>User</tt> and <tt>Use</tt> objects</a>
-</div>
-
-<div class="doc_text">
-<p>
-A subclass of <tt>User</tt> can choose between incorporating its <tt>Use</tt> objects
-or refer to them out-of-line by means of a pointer. A mixed variant
-(some <tt>Use</tt>s inline others hung off) is impractical and breaks the invariant
-that the <tt>Use</tt> objects belonging to the same <tt>User</tt> form a contiguous array.
-</p>
-</div>
-
-<p>
-We have 2 different layouts in the <tt>User</tt> (sub)classes:
-<ul>
-<li><p>Layout a)
-The <tt>Use</tt> object(s) are inside (resp. at fixed offset) of the <tt>User</tt>
-object and there are a fixed number of them.</p>
-
-<li><p>Layout b)
-The <tt>Use</tt> object(s) are referenced by a pointer to an
-array from the <tt>User</tt> object and there may be a variable
-number of them.</p>
-</ul>
-<p>
-As of v2.4 each layout still possesses a direct pointer to the
-start of the array of <tt>Use</tt>s. Though not mandatory for layout a),
-we stick to this redundancy for the sake of simplicity.
-The <tt>User</tt> object also stores the number of <tt>Use</tt> objects it
-has. (Theoretically this information can also be calculated
-given the scheme presented below.)</p>
-<p>
-Special forms of allocation operators (<tt>operator new</tt>)
-enforce the following memory layouts:</p>
-
-<ul>
-<li><p>Layout a) is modelled by prepending the <tt>User</tt> object by the <tt>Use[]</tt> array.</p>
-
-<pre>
-...---.---.---.---.-------...
- | P | P | P | P | User
-'''---'---'---'---'-------'''
-</pre>
-
-<li><p>Layout b) is modelled by pointing at the <tt>Use[]</tt> array.</p>
-<pre>
-.-------...
-| User
-'-------'''
- |
- v
- .---.---.---.---...
- | P | P | P | P |
- '---'---'---'---'''
-</pre>
-</ul>
-<i>(In the above figures '<tt>P</tt>' stands for the <tt>Use**</tt> that
- is stored in each <tt>Use</tt> object in the member <tt>Use::Prev</tt>)</i>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="Waymarking">The waymarking algorithm</a>
-</div>
-
-<div class="doc_text">
-<p>
-Since the <tt>Use</tt> objects are deprived of the direct (back)pointer to
-their <tt>User</tt> objects, there must be a fast and exact method to
-recover it. This is accomplished by the following scheme:</p>
-</div>
-
-A bit-encoding in the 2 LSBits (least significant bits) of the <tt>Use::Prev</tt> allows to find the
-start of the <tt>User</tt> object:
-<ul>
-<li><tt>00</tt> —> binary digit 0</li>
-<li><tt>01</tt> —> binary digit 1</li>
-<li><tt>10</tt> —> stop and calculate (<tt>s</tt>)</li>
-<li><tt>11</tt> —> full stop (<tt>S</tt>)</li>
-</ul>
-<p>
-Given a <tt>Use*</tt>, all we have to do is to walk till we get
-a stop and we either have a <tt>User</tt> immediately behind or
-we have to walk to the next stop picking up digits
-and calculating the offset:</p>
-<pre>
-.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.----------------
-| 1 | s | 1 | 0 | 1 | 0 | s | 1 | 1 | 0 | s | 1 | 1 | s | 1 | S | User (or User*)
-'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'----------------
- |+15 |+10 |+6 |+3 |+1
- | | | | |__>
- | | | |__________>
- | | |______________________>
- | |______________________________________>
- |__________________________________________________________>
-</pre>
-<p>
-Only the significant number of bits need to be stored between the
-stops, so that the <i>worst case is 20 memory accesses</i> when there are
-1000 <tt>Use</tt> objects associated with a <tt>User</tt>.</p>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="ReferenceImpl">Reference implementation</a>
-</div>
-
-<div class="doc_text">
-<p>
-The following literate Haskell fragment demonstrates the concept:</p>
-</div>
-
-<div class="doc_code">
-<pre>
-> import Test.QuickCheck
->
-> digits :: Int -> [Char] -> [Char]
-> digits 0 acc = '0' : acc
-> digits 1 acc = '1' : acc
-> digits n acc = digits (n `div` 2) $ digits (n `mod` 2) acc
->
-> dist :: Int -> [Char] -> [Char]
-> dist 0 [] = ['S']
-> dist 0 acc = acc
-> dist 1 acc = let r = dist 0 acc in 's' : digits (length r) r
-> dist n acc = dist (n - 1) $ dist 1 acc
->
-> takeLast n ss = reverse $ take n $ reverse ss
->
-> test = takeLast 40 $ dist 20 []
->
-</pre>
-</div>
-<p>
-Printing <test> gives: <tt>"1s100000s11010s10100s1111s1010s110s11s1S"</tt></p>
-<p>
-The reverse algorithm computes the length of the string just by examining
-a certain prefix:</p>
-
-<div class="doc_code">
-<pre>
-> pref :: [Char] -> Int
-> pref "S" = 1
-> pref ('s':'1':rest) = decode 2 1 rest
-> pref (_:rest) = 1 + pref rest
->
-> decode walk acc ('0':rest) = decode (walk + 1) (acc * 2) rest
-> decode walk acc ('1':rest) = decode (walk + 1) (acc * 2 + 1) rest
-> decode walk acc _ = walk + acc
->
-</pre>
-</div>
-<p>
-Now, as expected, printing <pref test> gives <tt>40</tt>.</p>
-<p>
-We can <i>quickCheck</i> this with following property:</p>
-
-<div class="doc_code">
-<pre>
-> testcase = dist 2000 []
-> testcaseLength = length testcase
->
-> identityProp n = n > 0 && n <= testcaseLength ==> length arr == pref arr
-> where arr = takeLast n testcase
->
-</pre>
-</div>
-<p>
-As expected <quickCheck identityProp> gives:</p>
-
-<pre>
-*Main> quickCheck identityProp
-OK, passed 100 tests.
-</pre>
-<p>
-Let's be a bit more exhaustive:</p>
-
-<div class="doc_code">
-<pre>
->
-> deepCheck p = check (defaultConfig { configMaxTest = 500 }) p
->
-</pre>
-</div>
-<p>
-And here is the result of <deepCheck identityProp>:</p>
-
-<pre>
-*Main> deepCheck identityProp
-OK, passed 500 tests.
-</pre>
-
-<!-- ______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="Tagging">Tagging considerations</a>
-</div>
-
-<p>
-To maintain the invariant that the 2 LSBits of each <tt>Use**</tt> in <tt>Use</tt>
-never change after being set up, setters of <tt>Use::Prev</tt> must re-tag the
-new <tt>Use**</tt> on every modification. Accordingly getters must strip the
-tag bits.</p>
-<p>
-For layout b) instead of the <tt>User</tt> we find a pointer (<tt>User*</tt> with LSBit set).
-Following this pointer brings us to the <tt>User</tt>. A portable trick ensures
-that the first bytes of <tt>User</tt> (if interpreted as a pointer) never has
-the LSBit set. (Portability is relying on the fact that all known compilers place the
-<tt>vptr</tt> in the first word of the instances.)</p>
-
-</div>
-
- <!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="coreclasses">The Core LLVM Class Hierarchy Reference </a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p><tt>#include "<a href="/doxygen/Type_8h-source.html">llvm/Type.h</a>"</tt>
-<br>doxygen info: <a href="/doxygen/classllvm_1_1Type.html">Type Class</a></p>
-
-<p>The Core LLVM classes are the primary means of representing the program
-being inspected or transformed. The core LLVM classes are defined in
-header files in the <tt>include/llvm/</tt> directory, and implemented in
-the <tt>lib/VMCore</tt> directory.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Type">The <tt>Type</tt> class and Derived Types</a>
-</div>
-
-<div class="doc_text">
-
- <p><tt>Type</tt> is a superclass of all type classes. Every <tt>Value</tt> has
- a <tt>Type</tt>. <tt>Type</tt> cannot be instantiated directly but only
- through its subclasses. Certain primitive types (<tt>VoidType</tt>,
- <tt>LabelType</tt>, <tt>FloatType</tt> and <tt>DoubleType</tt>) have hidden
- subclasses. They are hidden because they offer no useful functionality beyond
- what the <tt>Type</tt> class offers except to distinguish themselves from
- other subclasses of <tt>Type</tt>.</p>
- <p>All other types are subclasses of <tt>DerivedType</tt>. Types can be
- named, but this is not a requirement. There exists exactly
- one instance of a given shape at any one time. This allows type equality to
- be performed with address equality of the Type Instance. That is, given two
- <tt>Type*</tt> values, the types are identical if the pointers are identical.
- </p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_Type">Important Public Methods</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt>bool isIntegerTy() const</tt>: Returns true for any integer type.</li>
-
- <li><tt>bool isFloatingPointTy()</tt>: Return true if this is one of the five
- floating point types.</li>
-
- <li><tt>bool isAbstract()</tt>: Return true if the type is abstract (contains
- an OpaqueType anywhere in its definition).</li>
-
- <li><tt>bool isSized()</tt>: Return true if the type has known size. Things
- that don't have a size are abstract types, labels and void.</li>
-
-</ul>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="derivedtypes">Important Derived Types</a>
-</div>
-<div class="doc_text">
-<dl>
- <dt><tt>IntegerType</tt></dt>
- <dd>Subclass of DerivedType that represents integer types of any bit width.
- Any bit width between <tt>IntegerType::MIN_INT_BITS</tt> (1) and
- <tt>IntegerType::MAX_INT_BITS</tt> (~8 million) can be represented.
- <ul>
- <li><tt>static const IntegerType* get(unsigned NumBits)</tt>: get an integer
- type of a specific bit width.</li>
- <li><tt>unsigned getBitWidth() const</tt>: Get the bit width of an integer
- type.</li>
- </ul>
- </dd>
- <dt><tt>SequentialType</tt></dt>
- <dd>This is subclassed by ArrayType and PointerType
- <ul>
- <li><tt>const Type * getElementType() const</tt>: Returns the type of each
- of the elements in the sequential type. </li>
- </ul>
- </dd>
- <dt><tt>ArrayType</tt></dt>
- <dd>This is a subclass of SequentialType and defines the interface for array
- types.
- <ul>
- <li><tt>unsigned getNumElements() const</tt>: Returns the number of
- elements in the array. </li>
- </ul>
- </dd>
- <dt><tt>PointerType</tt></dt>
- <dd>Subclass of SequentialType for pointer types.</dd>
- <dt><tt>VectorType</tt></dt>
- <dd>Subclass of SequentialType for vector types. A
- vector type is similar to an ArrayType but is distinguished because it is
- a first class type whereas ArrayType is not. Vector types are used for
- vector operations and are usually small vectors of of an integer or floating
- point type.</dd>
- <dt><tt>StructType</tt></dt>
- <dd>Subclass of DerivedTypes for struct types.</dd>
- <dt><tt><a name="FunctionType">FunctionType</a></tt></dt>
- <dd>Subclass of DerivedTypes for function types.
- <ul>
- <li><tt>bool isVarArg() const</tt>: Returns true if it's a vararg
- function</li>
- <li><tt> const Type * getReturnType() const</tt>: Returns the
- return type of the function.</li>
- <li><tt>const Type * getParamType (unsigned i)</tt>: Returns
- the type of the ith parameter.</li>
- <li><tt> const unsigned getNumParams() const</tt>: Returns the
- number of formal parameters.</li>
- </ul>
- </dd>
- <dt><tt>OpaqueType</tt></dt>
- <dd>Sublcass of DerivedType for abstract types. This class
- defines no content and is used as a placeholder for some other type. Note
- that OpaqueType is used (temporarily) during type resolution for forward
- references of types. Once the referenced type is resolved, the OpaqueType
- is replaced with the actual type. OpaqueType can also be used for data
- abstraction. At link time opaque types can be resolved to actual types
- of the same name.</dd>
-</dl>
-</div>
-
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Module">The <tt>Module</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "<a
-href="/doxygen/Module_8h-source.html">llvm/Module.h</a>"</tt><br> doxygen info:
-<a href="/doxygen/classllvm_1_1Module.html">Module Class</a></p>
-
-<p>The <tt>Module</tt> class represents the top level structure present in LLVM
-programs. An LLVM module is effectively either a translation unit of the
-original program or a combination of several translation units merged by the
-linker. The <tt>Module</tt> class keeps track of a list of <a
-href="#Function"><tt>Function</tt></a>s, a list of <a
-href="#GlobalVariable"><tt>GlobalVariable</tt></a>s, and a <a
-href="#SymbolTable"><tt>SymbolTable</tt></a>. Additionally, it contains a few
-helpful member functions that try to make common operations easy.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_Module">Important Public Members of the <tt>Module</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt>Module::Module(std::string name = "")</tt></li>
-</ul>
-
-<p>Constructing a <a href="#Module">Module</a> is easy. You can optionally
-provide a name for it (probably based on the name of the translation unit).</p>
-
-<ul>
- <li><tt>Module::iterator</tt> - Typedef for function list iterator<br>
- <tt>Module::const_iterator</tt> - Typedef for const_iterator.<br>
-
- <tt>begin()</tt>, <tt>end()</tt>
- <tt>size()</tt>, <tt>empty()</tt>
-
- <p>These are forwarding methods that make it easy to access the contents of
- a <tt>Module</tt> object's <a href="#Function"><tt>Function</tt></a>
- list.</p></li>
-
- <li><tt>Module::FunctionListType &getFunctionList()</tt>
-
- <p> Returns the list of <a href="#Function"><tt>Function</tt></a>s. This is
- necessary to use when you need to update the list or perform a complex
- action that doesn't have a forwarding method.</p>
-
- <p><!-- Global Variable --></p></li>
-</ul>
-
-<hr>
-
-<ul>
- <li><tt>Module::global_iterator</tt> - Typedef for global variable list iterator<br>
-
- <tt>Module::const_global_iterator</tt> - Typedef for const_iterator.<br>
-
- <tt>global_begin()</tt>, <tt>global_end()</tt>
- <tt>global_size()</tt>, <tt>global_empty()</tt>
-
- <p> These are forwarding methods that make it easy to access the contents of
- a <tt>Module</tt> object's <a
- href="#GlobalVariable"><tt>GlobalVariable</tt></a> list.</p></li>
-
- <li><tt>Module::GlobalListType &getGlobalList()</tt>
-
- <p>Returns the list of <a
- href="#GlobalVariable"><tt>GlobalVariable</tt></a>s. This is necessary to
- use when you need to update the list or perform a complex action that
- doesn't have a forwarding method.</p>
-
- <p><!-- Symbol table stuff --> </p></li>
-</ul>
-
-<hr>
-
-<ul>
- <li><tt><a href="#SymbolTable">SymbolTable</a> *getSymbolTable()</tt>
-
- <p>Return a reference to the <a href="#SymbolTable"><tt>SymbolTable</tt></a>
- for this <tt>Module</tt>.</p>
-
- <p><!-- Convenience methods --></p></li>
-</ul>
-
-<hr>
-
-<ul>
- <li><tt><a href="#Function">Function</a> *getFunction(const std::string
- &Name, const <a href="#FunctionType">FunctionType</a> *Ty)</tt>
-
- <p>Look up the specified function in the <tt>Module</tt> <a
- href="#SymbolTable"><tt>SymbolTable</tt></a>. If it does not exist, return
- <tt>null</tt>.</p></li>
-
- <li><tt><a href="#Function">Function</a> *getOrInsertFunction(const
- std::string &Name, const <a href="#FunctionType">FunctionType</a> *T)</tt>
-
- <p>Look up the specified function in the <tt>Module</tt> <a
- href="#SymbolTable"><tt>SymbolTable</tt></a>. If it does not exist, add an
- external declaration for the function and return it.</p></li>
-
- <li><tt>std::string getTypeName(const <a href="#Type">Type</a> *Ty)</tt>
-
- <p>If there is at least one entry in the <a
- href="#SymbolTable"><tt>SymbolTable</tt></a> for the specified <a
- href="#Type"><tt>Type</tt></a>, return it. Otherwise return the empty
- string.</p></li>
-
- <li><tt>bool addTypeName(const std::string &Name, const <a
- href="#Type">Type</a> *Ty)</tt>
-
- <p>Insert an entry in the <a href="#SymbolTable"><tt>SymbolTable</tt></a>
- mapping <tt>Name</tt> to <tt>Ty</tt>. If there is already an entry for this
- name, true is returned and the <a
- href="#SymbolTable"><tt>SymbolTable</tt></a> is not modified.</p></li>
-</ul>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Value">The <tt>Value</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "<a href="/doxygen/Value_8h-source.html">llvm/Value.h</a>"</tt>
-<br>
-doxygen info: <a href="/doxygen/classllvm_1_1Value.html">Value Class</a></p>
-
-<p>The <tt>Value</tt> class is the most important class in the LLVM Source
-base. It represents a typed value that may be used (among other things) as an
-operand to an instruction. There are many different types of <tt>Value</tt>s,
-such as <a href="#Constant"><tt>Constant</tt></a>s,<a
-href="#Argument"><tt>Argument</tt></a>s. Even <a
-href="#Instruction"><tt>Instruction</tt></a>s and <a
-href="#Function"><tt>Function</tt></a>s are <tt>Value</tt>s.</p>
-
-<p>A particular <tt>Value</tt> may be used many times in the LLVM representation
-for a program. For example, an incoming argument to a function (represented
-with an instance of the <a href="#Argument">Argument</a> class) is "used" by
-every instruction in the function that references the argument. To keep track
-of this relationship, the <tt>Value</tt> class keeps a list of all of the <a
-href="#User"><tt>User</tt></a>s that is using it (the <a
-href="#User"><tt>User</tt></a> class is a base class for all nodes in the LLVM
-graph that can refer to <tt>Value</tt>s). This use list is how LLVM represents
-def-use information in the program, and is accessible through the <tt>use_</tt>*
-methods, shown below.</p>
-
-<p>Because LLVM is a typed representation, every LLVM <tt>Value</tt> is typed,
-and this <a href="#Type">Type</a> is available through the <tt>getType()</tt>
-method. In addition, all LLVM values can be named. The "name" of the
-<tt>Value</tt> is a symbolic string printed in the LLVM code:</p>
-
-<div class="doc_code">
-<pre>
-%<b>foo</b> = add i32 1, 2
-</pre>
-</div>
-
-<p><a name="nameWarning">The name of this instruction is "foo".</a> <b>NOTE</b>
-that the name of any value may be missing (an empty string), so names should
-<b>ONLY</b> be used for debugging (making the source code easier to read,
-debugging printouts), they should not be used to keep track of values or map
-between them. For this purpose, use a <tt>std::map</tt> of pointers to the
-<tt>Value</tt> itself instead.</p>
-
-<p>One important aspect of LLVM is that there is no distinction between an SSA
-variable and the operation that produces it. Because of this, any reference to
-the value produced by an instruction (or the value available as an incoming
-argument, for example) is represented as a direct pointer to the instance of
-the class that
-represents this value. Although this may take some getting used to, it
-simplifies the representation and makes it easier to manipulate.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_Value">Important Public Members of the <tt>Value</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt>Value::use_iterator</tt> - Typedef for iterator over the
-use-list<br>
- <tt>Value::const_use_iterator</tt> - Typedef for const_iterator over
-the use-list<br>
- <tt>unsigned use_size()</tt> - Returns the number of users of the
-value.<br>
- <tt>bool use_empty()</tt> - Returns true if there are no users.<br>
- <tt>use_iterator use_begin()</tt> - Get an iterator to the start of
-the use-list.<br>
- <tt>use_iterator use_end()</tt> - Get an iterator to the end of the
-use-list.<br>
- <tt><a href="#User">User</a> *use_back()</tt> - Returns the last
-element in the list.
- <p> These methods are the interface to access the def-use
-information in LLVM. As with all other iterators in LLVM, the naming
-conventions follow the conventions defined by the <a href="#stl">STL</a>.</p>
- </li>
- <li><tt><a href="#Type">Type</a> *getType() const</tt>
- <p>This method returns the Type of the Value.</p>
- </li>
- <li><tt>bool hasName() const</tt><br>
- <tt>std::string getName() const</tt><br>
- <tt>void setName(const std::string &Name)</tt>
- <p> This family of methods is used to access and assign a name to a <tt>Value</tt>,
-be aware of the <a href="#nameWarning">precaution above</a>.</p>
- </li>
- <li><tt>void replaceAllUsesWith(Value *V)</tt>
-
- <p>This method traverses the use list of a <tt>Value</tt> changing all <a
- href="#User"><tt>User</tt>s</a> of the current value to refer to
- "<tt>V</tt>" instead. For example, if you detect that an instruction always
- produces a constant value (for example through constant folding), you can
- replace all uses of the instruction with the constant like this:</p>
-
-<div class="doc_code">
-<pre>
-Inst->replaceAllUsesWith(ConstVal);
-</pre>
-</div>
-
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="User">The <tt>User</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-<tt>#include "<a href="/doxygen/User_8h-source.html">llvm/User.h</a>"</tt><br>
-doxygen info: <a href="/doxygen/classllvm_1_1User.html">User Class</a><br>
-Superclass: <a href="#Value"><tt>Value</tt></a></p>
-
-<p>The <tt>User</tt> class is the common base class of all LLVM nodes that may
-refer to <a href="#Value"><tt>Value</tt></a>s. It exposes a list of "Operands"
-that are all of the <a href="#Value"><tt>Value</tt></a>s that the User is
-referring to. The <tt>User</tt> class itself is a subclass of
-<tt>Value</tt>.</p>
-
-<p>The operands of a <tt>User</tt> point directly to the LLVM <a
-href="#Value"><tt>Value</tt></a> that it refers to. Because LLVM uses Static
-Single Assignment (SSA) form, there can only be one definition referred to,
-allowing this direct connection. This connection provides the use-def
-information in LLVM.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_User">Important Public Members of the <tt>User</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <tt>User</tt> class exposes the operand list in two ways: through
-an index access interface and through an iterator based interface.</p>
-
-<ul>
- <li><tt>Value *getOperand(unsigned i)</tt><br>
- <tt>unsigned getNumOperands()</tt>
- <p> These two methods expose the operands of the <tt>User</tt> in a
-convenient form for direct access.</p></li>
-
- <li><tt>User::op_iterator</tt> - Typedef for iterator over the operand
-list<br>
- <tt>op_iterator op_begin()</tt> - Get an iterator to the start of
-the operand list.<br>
- <tt>op_iterator op_end()</tt> - Get an iterator to the end of the
-operand list.
- <p> Together, these methods make up the iterator based interface to
-the operands of a <tt>User</tt>.</p></li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Instruction">The <tt>Instruction</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "</tt><tt><a
-href="/doxygen/Instruction_8h-source.html">llvm/Instruction.h</a>"</tt><br>
-doxygen info: <a href="/doxygen/classllvm_1_1Instruction.html">Instruction Class</a><br>
-Superclasses: <a href="#User"><tt>User</tt></a>, <a
-href="#Value"><tt>Value</tt></a></p>
-
-<p>The <tt>Instruction</tt> class is the common base class for all LLVM
-instructions. It provides only a few methods, but is a very commonly used
-class. The primary data tracked by the <tt>Instruction</tt> class itself is the
-opcode (instruction type) and the parent <a
-href="#BasicBlock"><tt>BasicBlock</tt></a> the <tt>Instruction</tt> is embedded
-into. To represent a specific type of instruction, one of many subclasses of
-<tt>Instruction</tt> are used.</p>
-
-<p> Because the <tt>Instruction</tt> class subclasses the <a
-href="#User"><tt>User</tt></a> class, its operands can be accessed in the same
-way as for other <a href="#User"><tt>User</tt></a>s (with the
-<tt>getOperand()</tt>/<tt>getNumOperands()</tt> and
-<tt>op_begin()</tt>/<tt>op_end()</tt> methods).</p> <p> An important file for
-the <tt>Instruction</tt> class is the <tt>llvm/Instruction.def</tt> file. This
-file contains some meta-data about the various different types of instructions
-in LLVM. It describes the enum values that are used as opcodes (for example
-<tt>Instruction::Add</tt> and <tt>Instruction::ICmp</tt>), as well as the
-concrete sub-classes of <tt>Instruction</tt> that implement the instruction (for
-example <tt><a href="#BinaryOperator">BinaryOperator</a></tt> and <tt><a
-href="#CmpInst">CmpInst</a></tt>). Unfortunately, the use of macros in
-this file confuses doxygen, so these enum values don't show up correctly in the
-<a href="/doxygen/classllvm_1_1Instruction.html">doxygen output</a>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="s_Instruction">Important Subclasses of the <tt>Instruction</tt>
- class</a>
-</div>
-<div class="doc_text">
- <ul>
- <li><tt><a name="BinaryOperator">BinaryOperator</a></tt>
- <p>This subclasses represents all two operand instructions whose operands
- must be the same type, except for the comparison instructions.</p></li>
- <li><tt><a name="CastInst">CastInst</a></tt>
- <p>This subclass is the parent of the 12 casting instructions. It provides
- common operations on cast instructions.</p>
- <li><tt><a name="CmpInst">CmpInst</a></tt>
- <p>This subclass respresents the two comparison instructions,
- <a href="LangRef.html#i_icmp">ICmpInst</a> (integer opreands), and
- <a href="LangRef.html#i_fcmp">FCmpInst</a> (floating point operands).</p>
- <li><tt><a name="TerminatorInst">TerminatorInst</a></tt>
- <p>This subclass is the parent of all terminator instructions (those which
- can terminate a block).</p>
- </ul>
- </div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_Instruction">Important Public Members of the <tt>Instruction</tt>
- class</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt><a href="#BasicBlock">BasicBlock</a> *getParent()</tt>
- <p>Returns the <a href="#BasicBlock"><tt>BasicBlock</tt></a> that
-this <tt>Instruction</tt> is embedded into.</p></li>
- <li><tt>bool mayWriteToMemory()</tt>
- <p>Returns true if the instruction writes to memory, i.e. it is a
- <tt>call</tt>,<tt>free</tt>,<tt>invoke</tt>, or <tt>store</tt>.</p></li>
- <li><tt>unsigned getOpcode()</tt>
- <p>Returns the opcode for the <tt>Instruction</tt>.</p></li>
- <li><tt><a href="#Instruction">Instruction</a> *clone() const</tt>
- <p>Returns another instance of the specified instruction, identical
-in all ways to the original except that the instruction has no parent
-(ie it's not embedded into a <a href="#BasicBlock"><tt>BasicBlock</tt></a>),
-and it has no name</p></li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Constant">The <tt>Constant</tt> class and subclasses</a>
-</div>
-
-<div class="doc_text">
-
-<p>Constant represents a base class for different types of constants. It
-is subclassed by ConstantInt, ConstantArray, etc. for representing
-the various types of Constants. <a href="#GlobalValue">GlobalValue</a> is also
-a subclass, which represents the address of a global variable or function.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">Important Subclasses of Constant </div>
-<div class="doc_text">
-<ul>
- <li>ConstantInt : This subclass of Constant represents an integer constant of
- any width.
- <ul>
- <li><tt>const APInt& getValue() const</tt>: Returns the underlying
- value of this constant, an APInt value.</li>
- <li><tt>int64_t getSExtValue() const</tt>: Converts the underlying APInt
- value to an int64_t via sign extension. If the value (not the bit width)
- of the APInt is too large to fit in an int64_t, an assertion will result.
- For this reason, use of this method is discouraged.</li>
- <li><tt>uint64_t getZExtValue() const</tt>: Converts the underlying APInt
- value to a uint64_t via zero extension. IF the value (not the bit width)
- of the APInt is too large to fit in a uint64_t, an assertion will result.
- For this reason, use of this method is discouraged.</li>
- <li><tt>static ConstantInt* get(const APInt& Val)</tt>: Returns the
- ConstantInt object that represents the value provided by <tt>Val</tt>.
- The type is implied as the IntegerType that corresponds to the bit width
- of <tt>Val</tt>.</li>
- <li><tt>static ConstantInt* get(const Type *Ty, uint64_t Val)</tt>:
- Returns the ConstantInt object that represents the value provided by
- <tt>Val</tt> for integer type <tt>Ty</tt>.</li>
- </ul>
- </li>
- <li>ConstantFP : This class represents a floating point constant.
- <ul>
- <li><tt>double getValue() const</tt>: Returns the underlying value of
- this constant. </li>
- </ul>
- </li>
- <li>ConstantArray : This represents a constant array.
- <ul>
- <li><tt>const std::vector<Use> &getValues() const</tt>: Returns
- a vector of component constants that makeup this array. </li>
- </ul>
- </li>
- <li>ConstantStruct : This represents a constant struct.
- <ul>
- <li><tt>const std::vector<Use> &getValues() const</tt>: Returns
- a vector of component constants that makeup this array. </li>
- </ul>
- </li>
- <li>GlobalValue : This represents either a global variable or a function. In
- either case, the value is a constant fixed address (after linking).
- </li>
-</ul>
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="GlobalValue">The <tt>GlobalValue</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "<a
-href="/doxygen/GlobalValue_8h-source.html">llvm/GlobalValue.h</a>"</tt><br>
-doxygen info: <a href="/doxygen/classllvm_1_1GlobalValue.html">GlobalValue
-Class</a><br>
-Superclasses: <a href="#Constant"><tt>Constant</tt></a>,
-<a href="#User"><tt>User</tt></a>, <a href="#Value"><tt>Value</tt></a></p>
-
-<p>Global values (<a href="#GlobalVariable"><tt>GlobalVariable</tt></a>s or <a
-href="#Function"><tt>Function</tt></a>s) are the only LLVM values that are
-visible in the bodies of all <a href="#Function"><tt>Function</tt></a>s.
-Because they are visible at global scope, they are also subject to linking with
-other globals defined in different translation units. To control the linking
-process, <tt>GlobalValue</tt>s know their linkage rules. Specifically,
-<tt>GlobalValue</tt>s know whether they have internal or external linkage, as
-defined by the <tt>LinkageTypes</tt> enumeration.</p>
-
-<p>If a <tt>GlobalValue</tt> has internal linkage (equivalent to being
-<tt>static</tt> in C), it is not visible to code outside the current translation
-unit, and does not participate in linking. If it has external linkage, it is
-visible to external code, and does participate in linking. In addition to
-linkage information, <tt>GlobalValue</tt>s keep track of which <a
-href="#Module"><tt>Module</tt></a> they are currently part of.</p>
-
-<p>Because <tt>GlobalValue</tt>s are memory objects, they are always referred to
-by their <b>address</b>. As such, the <a href="#Type"><tt>Type</tt></a> of a
-global is always a pointer to its contents. It is important to remember this
-when using the <tt>GetElementPtrInst</tt> instruction because this pointer must
-be dereferenced first. For example, if you have a <tt>GlobalVariable</tt> (a
-subclass of <tt>GlobalValue)</tt> that is an array of 24 ints, type <tt>[24 x
-i32]</tt>, then the <tt>GlobalVariable</tt> is a pointer to that array. Although
-the address of the first element of this array and the value of the
-<tt>GlobalVariable</tt> are the same, they have different types. The
-<tt>GlobalVariable</tt>'s type is <tt>[24 x i32]</tt>. The first element's type
-is <tt>i32.</tt> Because of this, accessing a global value requires you to
-dereference the pointer with <tt>GetElementPtrInst</tt> first, then its elements
-can be accessed. This is explained in the <a href="LangRef.html#globalvars">LLVM
-Language Reference Manual</a>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_GlobalValue">Important Public Members of the <tt>GlobalValue</tt>
- class</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt>bool hasInternalLinkage() const</tt><br>
- <tt>bool hasExternalLinkage() const</tt><br>
- <tt>void setInternalLinkage(bool HasInternalLinkage)</tt>
- <p> These methods manipulate the linkage characteristics of the <tt>GlobalValue</tt>.</p>
- <p> </p>
- </li>
- <li><tt><a href="#Module">Module</a> *getParent()</tt>
- <p> This returns the <a href="#Module"><tt>Module</tt></a> that the
-GlobalValue is currently embedded into.</p></li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Function">The <tt>Function</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "<a
-href="/doxygen/Function_8h-source.html">llvm/Function.h</a>"</tt><br> doxygen
-info: <a href="/doxygen/classllvm_1_1Function.html">Function Class</a><br>
-Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,
-<a href="#Constant"><tt>Constant</tt></a>,
-<a href="#User"><tt>User</tt></a>,
-<a href="#Value"><tt>Value</tt></a></p>
-
-<p>The <tt>Function</tt> class represents a single procedure in LLVM. It is
-actually one of the more complex classes in the LLVM hierarchy because it must
-keep track of a large amount of data. The <tt>Function</tt> class keeps track
-of a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, a list of formal
-<a href="#Argument"><tt>Argument</tt></a>s, and a
-<a href="#SymbolTable"><tt>SymbolTable</tt></a>.</p>
-
-<p>The list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s is the most
-commonly used part of <tt>Function</tt> objects. The list imposes an implicit
-ordering of the blocks in the function, which indicate how the code will be
-laid out by the backend. Additionally, the first <a
-href="#BasicBlock"><tt>BasicBlock</tt></a> is the implicit entry node for the
-<tt>Function</tt>. It is not legal in LLVM to explicitly branch to this initial
-block. There are no implicit exit nodes, and in fact there may be multiple exit
-nodes from a single <tt>Function</tt>. If the <a
-href="#BasicBlock"><tt>BasicBlock</tt></a> list is empty, this indicates that
-the <tt>Function</tt> is actually a function declaration: the actual body of the
-function hasn't been linked in yet.</p>
-
-<p>In addition to a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, the
-<tt>Function</tt> class also keeps track of the list of formal <a
-href="#Argument"><tt>Argument</tt></a>s that the function receives. This
-container manages the lifetime of the <a href="#Argument"><tt>Argument</tt></a>
-nodes, just like the <a href="#BasicBlock"><tt>BasicBlock</tt></a> list does for
-the <a href="#BasicBlock"><tt>BasicBlock</tt></a>s.</p>
-
-<p>The <a href="#SymbolTable"><tt>SymbolTable</tt></a> is a very rarely used
-LLVM feature that is only used when you have to look up a value by name. Aside
-from that, the <a href="#SymbolTable"><tt>SymbolTable</tt></a> is used
-internally to make sure that there are not conflicts between the names of <a
-href="#Instruction"><tt>Instruction</tt></a>s, <a
-href="#BasicBlock"><tt>BasicBlock</tt></a>s, or <a
-href="#Argument"><tt>Argument</tt></a>s in the function body.</p>
-
-<p>Note that <tt>Function</tt> is a <a href="#GlobalValue">GlobalValue</a>
-and therefore also a <a href="#Constant">Constant</a>. The value of the function
-is its address (after linking) which is guaranteed to be constant.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_Function">Important Public Members of the <tt>Function</tt>
- class</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt>Function(const </tt><tt><a href="#FunctionType">FunctionType</a>
- *Ty, LinkageTypes Linkage, const std::string &N = "", Module* Parent = 0)</tt>
-
- <p>Constructor used when you need to create new <tt>Function</tt>s to add
- the the program. The constructor must specify the type of the function to
- create and what type of linkage the function should have. The <a
- href="#FunctionType"><tt>FunctionType</tt></a> argument
- specifies the formal arguments and return value for the function. The same
- <a href="#FunctionType"><tt>FunctionType</tt></a> value can be used to
- create multiple functions. The <tt>Parent</tt> argument specifies the Module
- in which the function is defined. If this argument is provided, the function
- will automatically be inserted into that module's list of
- functions.</p></li>
-
- <li><tt>bool isDeclaration()</tt>
-
- <p>Return whether or not the <tt>Function</tt> has a body defined. If the
- function is "external", it does not have a body, and thus must be resolved
- by linking with a function defined in a different translation unit.</p></li>
-
- <li><tt>Function::iterator</tt> - Typedef for basic block list iterator<br>
- <tt>Function::const_iterator</tt> - Typedef for const_iterator.<br>
-
- <tt>begin()</tt>, <tt>end()</tt>
- <tt>size()</tt>, <tt>empty()</tt>
-
- <p>These are forwarding methods that make it easy to access the contents of
- a <tt>Function</tt> object's <a href="#BasicBlock"><tt>BasicBlock</tt></a>
- list.</p></li>
-
- <li><tt>Function::BasicBlockListType &getBasicBlockList()</tt>
-
- <p>Returns the list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s. This
- is necessary to use when you need to update the list or perform a complex
- action that doesn't have a forwarding method.</p></li>
-
- <li><tt>Function::arg_iterator</tt> - Typedef for the argument list
-iterator<br>
- <tt>Function::const_arg_iterator</tt> - Typedef for const_iterator.<br>
-
- <tt>arg_begin()</tt>, <tt>arg_end()</tt>
- <tt>arg_size()</tt>, <tt>arg_empty()</tt>
-
- <p>These are forwarding methods that make it easy to access the contents of
- a <tt>Function</tt> object's <a href="#Argument"><tt>Argument</tt></a>
- list.</p></li>
-
- <li><tt>Function::ArgumentListType &getArgumentList()</tt>
-
- <p>Returns the list of <a href="#Argument"><tt>Argument</tt></a>s. This is
- necessary to use when you need to update the list or perform a complex
- action that doesn't have a forwarding method.</p></li>
-
- <li><tt><a href="#BasicBlock">BasicBlock</a> &getEntryBlock()</tt>
-
- <p>Returns the entry <a href="#BasicBlock"><tt>BasicBlock</tt></a> for the
- function. Because the entry block for the function is always the first
- block, this returns the first block of the <tt>Function</tt>.</p></li>
-
- <li><tt><a href="#Type">Type</a> *getReturnType()</tt><br>
- <tt><a href="#FunctionType">FunctionType</a> *getFunctionType()</tt>
-
- <p>This traverses the <a href="#Type"><tt>Type</tt></a> of the
- <tt>Function</tt> and returns the return type of the function, or the <a
- href="#FunctionType"><tt>FunctionType</tt></a> of the actual
- function.</p></li>
-
- <li><tt><a href="#SymbolTable">SymbolTable</a> *getSymbolTable()</tt>
-
- <p> Return a pointer to the <a href="#SymbolTable"><tt>SymbolTable</tt></a>
- for this <tt>Function</tt>.</p></li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="GlobalVariable">The <tt>GlobalVariable</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "<a
-href="/doxygen/GlobalVariable_8h-source.html">llvm/GlobalVariable.h</a>"</tt>
-<br>
-doxygen info: <a href="/doxygen/classllvm_1_1GlobalVariable.html">GlobalVariable
- Class</a><br>
-Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,
-<a href="#Constant"><tt>Constant</tt></a>,
-<a href="#User"><tt>User</tt></a>,
-<a href="#Value"><tt>Value</tt></a></p>
-
-<p>Global variables are represented with the (surprise surprise)
-<tt>GlobalVariable</tt> class. Like functions, <tt>GlobalVariable</tt>s are also
-subclasses of <a href="#GlobalValue"><tt>GlobalValue</tt></a>, and as such are
-always referenced by their address (global values must live in memory, so their
-"name" refers to their constant address). See
-<a href="#GlobalValue"><tt>GlobalValue</tt></a> for more on this. Global
-variables may have an initial value (which must be a
-<a href="#Constant"><tt>Constant</tt></a>), and if they have an initializer,
-they may be marked as "constant" themselves (indicating that their contents
-never change at runtime).</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_GlobalVariable">Important Public Members of the
- <tt>GlobalVariable</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li><tt>GlobalVariable(const </tt><tt><a href="#Type">Type</a> *Ty, bool
- isConstant, LinkageTypes& Linkage, <a href="#Constant">Constant</a>
- *Initializer = 0, const std::string &Name = "", Module* Parent = 0)</tt>
-
- <p>Create a new global variable of the specified type. If
- <tt>isConstant</tt> is true then the global variable will be marked as
- unchanging for the program. The Linkage parameter specifies the type of
- linkage (internal, external, weak, linkonce, appending) for the variable.
- If the linkage is InternalLinkage, WeakAnyLinkage, WeakODRLinkage,
- LinkOnceAnyLinkage or LinkOnceODRLinkage, then the resultant
- global variable will have internal linkage. AppendingLinkage concatenates
- together all instances (in different translation units) of the variable
- into a single variable but is only applicable to arrays. See
- the <a href="LangRef.html#modulestructure">LLVM Language Reference</a> for
- further details on linkage types. Optionally an initializer, a name, and the
- module to put the variable into may be specified for the global variable as
- well.</p></li>
-
- <li><tt>bool isConstant() const</tt>
-
- <p>Returns true if this is a global variable that is known not to
- be modified at runtime.</p></li>
-
- <li><tt>bool hasInitializer()</tt>
-
- <p>Returns true if this <tt>GlobalVariable</tt> has an intializer.</p></li>
-
- <li><tt><a href="#Constant">Constant</a> *getInitializer()</tt>
-
- <p>Returns the initial value for a <tt>GlobalVariable</tt>. It is not legal
- to call this method if there is no initializer.</p></li>
-</ul>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="BasicBlock">The <tt>BasicBlock</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p><tt>#include "<a
-href="/doxygen/BasicBlock_8h-source.html">llvm/BasicBlock.h</a>"</tt><br>
-doxygen info: <a href="/doxygen/classllvm_1_1BasicBlock.html">BasicBlock
-Class</a><br>
-Superclass: <a href="#Value"><tt>Value</tt></a></p>
-
-<p>This class represents a single entry multiple exit section of the code,
-commonly known as a basic block by the compiler community. The
-<tt>BasicBlock</tt> class maintains a list of <a
-href="#Instruction"><tt>Instruction</tt></a>s, which form the body of the block.
-Matching the language definition, the last element of this list of instructions
-is always a terminator instruction (a subclass of the <a
-href="#TerminatorInst"><tt>TerminatorInst</tt></a> class).</p>
-
-<p>In addition to tracking the list of instructions that make up the block, the
-<tt>BasicBlock</tt> class also keeps track of the <a
-href="#Function"><tt>Function</tt></a> that it is embedded into.</p>
-
-<p>Note that <tt>BasicBlock</tt>s themselves are <a
-href="#Value"><tt>Value</tt></a>s, because they are referenced by instructions
-like branches and can go in the switch tables. <tt>BasicBlock</tt>s have type
-<tt>label</tt>.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="m_BasicBlock">Important Public Members of the <tt>BasicBlock</tt>
- class</a>
-</div>
-
-<div class="doc_text">
-<ul>
-
-<li><tt>BasicBlock(const std::string &Name = "", </tt><tt><a
- href="#Function">Function</a> *Parent = 0)</tt>
-
-<p>The <tt>BasicBlock</tt> constructor is used to create new basic blocks for
-insertion into a function. The constructor optionally takes a name for the new
-block, and a <a href="#Function"><tt>Function</tt></a> to insert it into. If
-the <tt>Parent</tt> parameter is specified, the new <tt>BasicBlock</tt> is
-automatically inserted at the end of the specified <a
-href="#Function"><tt>Function</tt></a>, if not specified, the BasicBlock must be
-manually inserted into the <a href="#Function"><tt>Function</tt></a>.</p></li>
-
-<li><tt>BasicBlock::iterator</tt> - Typedef for instruction list iterator<br>
-<tt>BasicBlock::const_iterator</tt> - Typedef for const_iterator.<br>
-<tt>begin()</tt>, <tt>end()</tt>, <tt>front()</tt>, <tt>back()</tt>,
-<tt>size()</tt>, <tt>empty()</tt>
-STL-style functions for accessing the instruction list.
-
-<p>These methods and typedefs are forwarding functions that have the same
-semantics as the standard library methods of the same names. These methods
-expose the underlying instruction list of a basic block in a way that is easy to
-manipulate. To get the full complement of container operations (including
-operations to update the list), you must use the <tt>getInstList()</tt>
-method.</p></li>
-
-<li><tt>BasicBlock::InstListType &getInstList()</tt>
-
-<p>This method is used to get access to the underlying container that actually
-holds the Instructions. This method must be used when there isn't a forwarding
-function in the <tt>BasicBlock</tt> class for the operation that you would like
-to perform. Because there are no forwarding functions for "updating"
-operations, you need to use this if you want to update the contents of a
-<tt>BasicBlock</tt>.</p></li>
-
-<li><tt><a href="#Function">Function</a> *getParent()</tt>
-
-<p> Returns a pointer to <a href="#Function"><tt>Function</tt></a> the block is
-embedded into, or a null pointer if it is homeless.</p></li>
-
-<li><tt><a href="#TerminatorInst">TerminatorInst</a> *getTerminator()</tt>
-
-<p> Returns a pointer to the terminator instruction that appears at the end of
-the <tt>BasicBlock</tt>. If there is no terminator instruction, or if the last
-instruction in the block is not a terminator, then a null pointer is
-returned.</p></li>
-
-</ul>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="Argument">The <tt>Argument</tt> class</a>
-</div>
-
-<div class="doc_text">
-
-<p>This subclass of Value defines the interface for incoming formal
-arguments to a function. A Function maintains a list of its formal
-arguments. An argument has a pointer to the parent Function.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Strict"></a>
-
- <a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a> and
- <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/Projects.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Projects.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/Projects.html (original)
+++ llvm/trunk/docs/Projects.html (removed)
@@ -1,460 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>Creating an LLVM Project</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">Creating an LLVM Project</div>
-
-<ol>
-<li><a href="#overview">Overview</a></li>
-<li><a href="#create">Create a project from the Sample Project</a></li>
-<li><a href="#source">Source tree layout</a></li>
-<li><a href="#makefiles">Writing LLVM-style Makefiles</a>
- <ol>
- <li><a href="#reqVars">Required Variables</a></li>
- <li><a href="#varsBuildDir">Variables for Building Subdirectories</a></li>
- <li><a href="#varsBuildLib">Variables for Building Libraries</a></li>
- <li><a href="#varsBuildProg">Variables for Building Programs</a></li>
- <li><a href="#miscVars">Miscellaneous Variables</a></li>
- </ol></li>
-<li><a href="#objcode">Placement of object code</a></li>
-<li><a href="#help">Further help</a></li>
-</ol>
-
-<div class="doc_author">
- <p>Written by John Criswell</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="overview">Overview</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM build system is designed to facilitate the building of third party
-projects that use LLVM header files, libraries, and tools. In order to use
-these facilities, a Makefile from a project must do the following things:</p>
-
-<ol>
- <li>Set <tt>make</tt> variables. There are several variables that a Makefile
- needs to set to use the LLVM build system:
- <ul>
- <li><tt>PROJECT_NAME</tt> - The name by which your project is known.</li>
- <li><tt>LLVM_SRC_ROOT</tt> - The root of the LLVM source tree.</li>
- <li><tt>LLVM_OBJ_ROOT</tt> - The root of the LLVM object tree.</li>
- <li><tt>PROJ_SRC_ROOT</tt> - The root of the project's source tree.</li>
- <li><tt>PROJ_OBJ_ROOT</tt> - The root of the project's object tree.</li>
- <li><tt>PROJ_INSTALL_ROOT</tt> - The root installation directory.</li>
- <li><tt>LEVEL</tt> - The relative path from the current directory to the
- project's root ($PROJ_OBJ_ROOT).</li>
- </ul></li>
- <li>Include <tt>Makefile.config</tt> from <tt>$(LLVM_OBJ_ROOT)</tt>.</li>
- <li>Include <tt>Makefile.rules</tt> from <tt>$(LLVM_SRC_ROOT)</tt>.</li>
-</ol>
-
-<p>There are two ways that you can set all of these variables:</p>
-<ol>
- <li>You can write your own Makefiles which hard-code these values.</li>
- <li>You can use the pre-made LLVM sample project. This sample project
- includes Makefiles, a configure script that can be used to configure the
- location of LLVM, and the ability to support multiple object directories
- from a single source directory.</li>
-</ol>
-
-<p>This document assumes that you will base your project on the LLVM sample
-project found in <tt>llvm/projects/sample</tt>. If you want to devise your own
-build system, studying the sample project and LLVM Makefiles will probably
-provide enough information on how to write your own Makefiles.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="create">Create a Project from the Sample Project</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>Follow these simple steps to start your project:</p>
-
-<ol>
-<li>Copy the <tt>llvm/projects/sample</tt> directory to any place of your
-choosing. You can place it anywhere you like. Rename the directory to match
-the name of your project.</li>
-
-<li>
-If you downloaded LLVM using Subversion, remove all the directories named .svn
-(and all the files therein) from your project's new source tree. This will
-keep Subversion from thinking that your project is inside
-<tt>llvm/trunk/projects/sample</tt>.</li>
-
-<li>Add your source code and Makefiles to your source tree.</li>
-
-<li>If you want your project to be configured with the <tt>configure</tt> script
-then you need to edit <tt>autoconf/configure.ac</tt> as follows:
- <ul>
- <li><b>AC_INIT</b>. Place the name of your project, its version number and
- a contact email address for your project as the arguments to this macro</li>
- <li><b>AC_CONFIG_AUX_DIR</b>. If your project isn't in the
- <tt>llvm/projects</tt> directory then you might need to adjust this so that
- it specifies a relative path to the <tt>llvm/autoconf</tt> directory.</li>
- <li><b>LLVM_CONFIG_PROJECT</b>. Just leave this alone.</li>
- <li><b>AC_CONFIG_SRCDIR</b>. Specify a path to a file name that identifies
- your project; or just leave it at <tt>Makefile.common.in</tt></li>
- <li><b>AC_CONFIG_FILES</b>. Do not change.</li>
- <li><b>AC_CONFIG_MAKEFILE</b>. Use one of these macros for each Makefile
- that your project uses. This macro arranges for your makefiles to be copied
- from the source directory, unmodified, to the build directory.</li>
- </ul>
-</li>
-
-<li>After updating <tt>autoconf/configure.ac</tt>, regenerate the
-configure script with these commands:
-
-<div class="doc_code">
-<p><tt>% cd autoconf<br>
- % ./AutoRegen.sh</tt></p>
-</div>
-
-<p>You must be using Autoconf version 2.59 or later and your aclocal version
-should be 1.9 or later.</p></li>
-
-<li>Run <tt>configure</tt> in the directory in which you want to place
-object code. Use the following options to tell your project where it
-can find LLVM:
-
- <dl>
- <dt><tt>--with-llvmsrc=<directory></tt></dt>
- <dd>Tell your project where the LLVM source tree is located.</dd>
- <dt><br><tt>--with-llvmobj=<directory></tt></dt>
- <dd>Tell your project where the LLVM object tree is located.</dd>
- <dt><br><tt>--prefix=<directory></tt></dt>
- <dd>Tell your project where it should get installed.</dd>
- </dl>
-</ol>
-
-<p>That's it! Now all you have to do is type <tt>gmake</tt> (or <tt>make</tt>
-if your on a GNU/Linux system) in the root of your object directory, and your
-project should build.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="source">Source Tree Layout</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>In order to use the LLVM build system, you will want to organize your
-source code so that it can benefit from the build system's features.
-Mainly, you want your source tree layout to look similar to the LLVM
-source tree layout. The best way to do this is to just copy the
-project tree from <tt>llvm/projects/sample</tt> and modify it to meet
-your needs, but you can certainly add to it if you want.</p>
-
-<p>Underneath your top level directory, you should have the following
-directories:</p>
-
-<dl>
- <dt><b>lib</b>
- <dd>
- This subdirectory should contain all of your library source
- code. For each library that you build, you will have one
- directory in <b>lib</b> that will contain that library's source
- code.
-
- <p>
- Libraries can be object files, archives, or dynamic libraries.
- The <b>lib</b> directory is just a convenient place for libraries
- as it places them all in a directory from which they can be linked
- later.
-
- <dt><b>include</b>
- <dd>
- This subdirectory should contain any header files that are
- global to your project. By global, we mean that they are used
- by more than one library or executable of your project.
- <p>
- By placing your header files in <b>include</b>, they will be
- found automatically by the LLVM build system. For example, if
- you have a file <b>include/jazz/note.h</b>, then your source
- files can include it simply with <b>#include "jazz/note.h"</b>.
-
- <dt><b>tools</b>
- <dd>
- This subdirectory should contain all of your source
- code for executables. For each program that you build, you
- will have one directory in <b>tools</b> that will contain that
- program's source code.
- <p>
-
- <dt><b>test</b>
- <dd>
- This subdirectory should contain tests that verify that your code
- works correctly. Automated tests are especially useful.
- <p>
- Currently, the LLVM build system provides basic support for tests.
- The LLVM system provides the following:
- <ul>
- <li>
- LLVM provides a tcl procedure that is used by Dejagnu to run
- tests. It can be found in <tt>llvm/lib/llvm-dg.exp</tt>. This
- test procedure uses RUN lines in the actual test case to determine
- how to run the test. See the <a
- href="TestingGuide.html">TestingGuide</a> for more details. You
- can easily write Makefile support similar to the Makefiles in
- <tt>llvm/test</tt> to use Dejagnu to run your project's tests.<br></li>
- <li>
- LLVM contains an optional package called <tt>llvm-test</tt>
- which provides benchmarks and programs that are known to compile with the
- LLVM GCC front ends. You can use these
- programs to test your code, gather statistics information, and
- compare it to the current LLVM performance statistics.
- <br>Currently, there is no way to hook your tests directly into the
- <tt>llvm/test</tt> testing harness. You will simply
- need to find a way to use the source provided within that directory
- on your own.
- </ul>
-</dl>
-
-<p>Typically, you will want to build your <b>lib</b> directory first followed by
-your <b>tools</b> directory.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="makefiles">Writing LLVM Style Makefiles</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The LLVM build system provides a convenient way to build libraries and
-executables. Most of your project Makefiles will only need to define a few
-variables. Below is a list of the variables one can set and what they can
-do:</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="reqVars">Required Variables</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
- <dt>LEVEL
- <dd>
- This variable is the relative path from this Makefile to the
- top directory of your project's source code. For example, if
- your source code is in <tt>/tmp/src</tt>, then the Makefile in
- <tt>/tmp/src/jump/high</tt> would set <tt>LEVEL</tt> to <tt>"../.."</tt>.
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="varsBuildDir">Variables for Building Subdirectories</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
- <dt>DIRS
- <dd>
- This is a space separated list of subdirectories that should be
- built. They will be built, one at a time, in the order
- specified.
- <p>
-
- <dt>PARALLEL_DIRS
- <dd>
- This is a list of directories that can be built in parallel.
- These will be built after the directories in DIRS have been
- built.
- <p>
-
- <dt>OPTIONAL_DIRS
- <dd>
- This is a list of directories that can be built if they exist,
- but will not cause an error if they do not exist. They are
- built serially in the order in which they are listed.
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="varsBuildLib">Variables for Building Libraries</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
- <dt>LIBRARYNAME
- <dd>
- This variable contains the base name of the library that will
- be built. For example, to build a library named
- <tt>libsample.a</tt>, LIBRARYNAME should be set to
- <tt>sample</tt>.
- <p>
-
- <dt>BUILD_ARCHIVE
- <dd>
- By default, a library is a <tt>.o</tt> file that is linked
- directly into a program. To build an archive (also known as
- a static library), set the BUILD_ARCHIVE variable.
- <p>
-
- <dt>SHARED_LIBRARY
- <dd>
- If SHARED_LIBRARY is defined in your Makefile, a shared
- (or dynamic) library will be built.
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="varsBuildProg">Variables for Building Programs</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
- <dt>TOOLNAME
- <dd>
- This variable contains the name of the program that will
- be built. For example, to build an executable named
- <tt>sample</tt>, TOOLNAME should be set to <tt>sample</tt>.
- <p>
-
- <dt>USEDLIBS
- <dd>
- This variable holds a space separated list of libraries that
- should be linked into the program. These libraries must either
- be LLVM libraries or libraries that come from your <b>lib</b>
- directory. The libraries must be specified by their base name.
- For example, to link libsample.a, you would set USEDLIBS to
- <tt>sample</tt>.
- <p>
- Note that this works only for statically linked libraries.
- <p>
-
- <dt>LIBS
- <dd>
- To link dynamic libraries, add <tt>-l<library base name></tt> to
- the LIBS variable. The LLVM build system will look in the same places
- for dynamic libraries as it does for static libraries.
- <p>
- For example, to link <tt>libsample.so</tt>, you would have the
- following line in your <tt>Makefile</tt>:
- <p>
- <tt>
- LIBS += -lsample
- </tt>
-</dl>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="miscVars">Miscellaneous Variables</a>
-</div>
-
-<div class="doc_text">
-
-<dl>
- <dt>ExtraSource
- <dd>
- This variable contains a space separated list of extra source
- files that need to be built. It is useful for including the
- output of Lex and Yacc programs.
- <p>
-
- <dt>CFLAGS
- <dt>CPPFLAGS
- <dd>
- This variable can be used to add options to the C and C++
- compiler, respectively. It is typically used to add options
- that tell the compiler the location of additional directories
- to search for header files.
- <p>
- It is highly suggested that you append to CFLAGS and CPPFLAGS as
- opposed to overwriting them. The master Makefiles may already
- have useful options in them that you may not want to overwrite.
- <p>
-</dl>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="objcode">Placement of Object Code</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The final location of built libraries and executables will depend upon
-whether you do a Debug, Release, or Profile build.</p>
-
-<dl>
- <dt>Libraries
- <dd>
- All libraries (static and dynamic) will be stored in
- <tt>PROJ_OBJ_ROOT/<type>/lib</tt>, where type is <tt>Debug</tt>,
- <tt>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or
- profiled build, respectively.<p>
-
- <dt>Executables
- <dd>All executables will be stored in
- <tt>PROJ_OBJ_ROOT/<type>/bin</tt>, where type is <tt>Debug</tt>,
- <tt>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or profiled
- build, respectively.
-</dl>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="help">Further Help</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>If you have any questions or need any help creating an LLVM project,
-the LLVM team would be more than happy to help. You can always post your
-questions to the <a
-href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developers
-Mailing List</a>.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:criswell at uiuc.edu">John Criswell</a><br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
- <br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/ReleaseNotes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ReleaseNotes.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/ReleaseNotes.html (original)
+++ llvm/trunk/docs/ReleaseNotes.html (removed)
@@ -1,1237 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <link rel="stylesheet" href="llvm.css" type="text/css">
- <title>LLVM 2.8 Release Notes</title>
-</head>
-<body>
-
-<div class="doc_title">LLVM 2.8 Release Notes</div>
-
-<img align=right src="http://llvm.org/img/DragonSmall.png"
- width="136" height="136" alt="LLVM Dragon Logo">
-
-<ol>
- <li><a href="#intro">Introduction</a></li>
- <li><a href="#subproj">Sub-project Status Update</a></li>
- <li><a href="#externalproj">External Projects Using LLVM 2.8</a></li>
- <li><a href="#whatsnew">What's New in LLVM 2.8?</a></li>
- <li><a href="GettingStarted.html">Installation Instructions</a></li>
- <li><a href="#portability">Portability and Supported Platforms</a></li>
- <li><a href="#knownproblems">Known Problems</a></li>
- <li><a href="#additionalinfo">Additional Information</a></li>
-</ol>
-
-<div class="doc_author">
- <p>Written by the <a href="http://llvm.org">LLVM Team</a></p>
-</div>
-
-<h1 style="color:red">These are in-progress notes for the upcoming LLVM 2.8
-release.<br>
-You may prefer the
-<a href="http://llvm.org/releases/2.7/docs/ReleaseNotes.html">LLVM 2.7
-Release Notes</a>.</h1>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="intro">Introduction</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This document contains the release notes for the LLVM Compiler
-Infrastructure, release 2.8. Here we describe the status of LLVM, including
-major improvements from the previous release and significant known problems.
-All LLVM releases may be downloaded from the <a
-href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
-
-<p>For more information about LLVM, including information about the latest
-release, please check out the <a href="http://llvm.org/">main LLVM
-web site</a>. If you have questions or comments, the <a
-href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developer's
-Mailing List</a> is a good place to send them.</p>
-
-<p>Note that if you are reading this file from a Subversion checkout or the
-main LLVM web page, this document applies to the <i>next</i> release, not the
-current one. To see the release notes for a specific release, please see the
-<a href="http://llvm.org/releases/">releases page</a>.</p>
-
-</div>
-
-
-<!--
-Almost dead code.
- include/llvm/Analysis/LiveValues.h => Dan
- lib/Transforms/IPO/MergeFunctions.cpp => consider for 2.8.
- llvm/Analysis/PointerTracking.h => Edwin wants this, consider for 2.8.
- ABCD, GEPSplitterPass
- MSIL backend?
- lib/Transforms/Utils/SSI.cpp -> ABCD depends on it.
--->
-
-
-<!-- Features that need text if they're finished for 2.8:
- combiner-aa?
- strong phi elim
- llvm.dbg.value: variable debug info for optimized code
- loop dependence analysis
- -->
-
- <!-- for announcement email:
- Logo web page.
- Many new papers added to /pubs/
- -->
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="subproj">Sub-project Status Update</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-<p>
-The LLVM 2.8 distribution currently consists of code from the core LLVM
-repository (which roughly includes the LLVM optimizers, code generators
-and supporting tools), the Clang repository and the llvm-gcc repository. In
-addition to this code, the LLVM Project includes other sub-projects that are in
-development. Here we include updates on these subprojects.
-</p>
-
-</div>
-
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
-</div>
-
-<div class="doc_text">
-
-<p><a href="http://clang.llvm.org/">Clang</a> is an LLVM front end for the C,
-C++, and Objective-C languages. Clang aims to provide a better user experience
-through expressive diagnostics, a high level of conformance to language
-standards, fast compilation, and low memory use. Like LLVM, Clang provides a
-modular, library-based architecture that makes it suitable for creating or
-integrating with other development tools. Clang is considered a
-production-quality compiler for C and Objective-C on x86 (32- and 64-bit).</p>
-
-<p>In the LLVM 2.7 time-frame, the Clang team has made many improvements:</p>
-
-<ul>
-
-<li>C++ Support: Clang is now capable of self-hosting! While still
-alpha-quality, Clang's C++ support has matured enough to build LLVM and Clang,
-and C++ is now enabled by default. See the <a
-href="http://clang.llvm.org/cxx_compatibility.html">Clang C++ compatibility
-page</a> for common C++ migration issues.</li>
-
-<li>Objective-C: Clang now includes experimental support for an updated
-Objective-C ABI on non-Darwin platforms. This includes support for non-fragile
-instance variables and accelerated proxies, as well as greater potential for
-future optimisations. The new ABI is used when compiling with the
--fobjc-nonfragile-abi and -fgnu-runtime options. Code compiled with these
-options may be mixed with code compiled with GCC or clang using the old GNU ABI,
-but requires the libobjc2 runtime from the GNUstep project.</li>
-
-<li>New warnings: Clang contains a number of new warnings, including
-control-flow warnings (unreachable code, missing return statements in a
-non-<code>void</code> function, etc.), sign-comparison warnings, and improved
-format-string warnings.</li>
-
-<li>CIndex API and Python bindings: Clang now includes a C API as part of the
-CIndex library. Although we may make some changes to the API in the future, it
-is intended to be stable and has been designed for use by external projects. See
-the Clang
-doxygen <a href="http://clang.llvm.org/doxygen/group__CINDEX.html">CIndex</a>
-documentation for more details. The CIndex API also includes a preliminary
-set of Python bindings.</li>
-
-<li>ARM Support: Clang now has ABI support for both the Darwin and Linux ARM
-ABIs. Coupled with many improvements to the LLVM ARM backend, Clang is now
-suitable for use as a beta quality ARM compiler.</li>
-
-</ul>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="clangsa">Clang Static Analyzer</a>
-</div>
-
-<div class="doc_text">
-
-<p>The <a href="http://clang-analyzer.llvm.org/">Clang Static Analyzer</a>
- project is an effort to use static source code analysis techniques to
- automatically find bugs in C and Objective-C programs (and hopefully <a
- href="http://clang-analyzer.llvm.org/dev_cxx.html">C++ in the
- future</a>!). The tool is very good at finding bugs that occur on specific
- paths through code, such as on error conditions.</p>
-
-<p>In the LLVM 2.7 time-frame, the analyzer core has made several major and
- minor improvements, including better support for tracking the fields of
- structures, initial support (not enabled by default yet) for doing
- interprocedural (cross-function) analysis, and new checks have been added.
-</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
-</div>
-
-<div class="doc_text">
-<p>
-The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
-a JVM and a CLI Virtual Machine (Microsoft .NET is an
-implementation of the CLI) using LLVM for static and just-in-time
-compilation.</p>
-
-<p>
-With the release of LLVM 2.7, VMKit has shifted to a great framework for writing
-virtual machines. VMKit now offers precise and efficient garbage collection with
-multi-threading support, thanks to the MMTk memory management toolkit, as well
-as just in time and ahead of time compilation with LLVM. The major changes in
-VMKit 0.27 are:</p>
-
-<ul>
-
-<li>Garbage collection: VMKit now uses the MMTk toolkit for garbage collectors.
- The first collector to be ported is the MarkSweep collector, which is precise,
- and drastically improves the performance of VMKit.</li>
-<li>Line number information in the JVM: by using the debug metadata of LLVM, the
- JVM now supports precise line number information, useful when printing a stack
- trace.</li>
-<li>Interface calls in the JVM: we implemented a variant of the Interface Method
- Table technique for interface calls in the JVM.
-</li>
-
-</ul>
-</div>
-
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="compiler-rt">compiler-rt: Compiler Runtime Library</a>
-</div>
-
-<div class="doc_text">
-<p>
-The new LLVM <a href="http://compiler-rt.llvm.org/">compiler-rt project</a>
-is a simple library that provides an implementation of the low-level
-target-specific hooks required by code generation and other runtime components.
-For example, when compiling for a 32-bit target, converting a double to a 64-bit
-unsigned integer is compiled into a runtime call to the "__fixunsdfdi"
-function. The compiler-rt library provides highly optimized implementations of
-this and other low-level routines (some are 3x faster than the equivalent
-libgcc routines).</p>
-
-<p>
-All of the code in the compiler-rt project is available under the standard LLVM
-License, a "BSD-style" license. New in LLVM 2.7: compiler_rt now
-supports ARM targets.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="dragonegg">DragonEgg: llvm-gcc ported to gcc-4.5</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://dragonegg.llvm.org/">DragonEgg</a> is a port of llvm-gcc to
-gcc-4.5. Unlike llvm-gcc, which makes many intrusive changes to the underlying
-gcc-4.2 code, dragonegg in theory does not require any gcc-4.5 modifications
-whatsoever (currently one small patch is needed). This is thanks to the new
-<a href="http://gcc.gnu.org/wiki/plugins">gcc plugin architecture</a>, which
-makes it possible to modify the behaviour of gcc at runtime by loading a plugin,
-which is nothing more than a dynamic library which conforms to the gcc plugin
-interface. DragonEgg is a gcc plugin that causes the LLVM optimizers to be run
-instead of the gcc optimizers, and the LLVM code generators instead of the gcc
-code generators, just like llvm-gcc. To use it, you add
-"-fplugin=path/dragonegg.so" to the gcc-4.5 command line, and gcc-4.5 magically
-becomes llvm-gcc-4.5!
-</p>
-
-<p>
-DragonEgg is still a work in progress. Currently C works very well, while C++,
-Ada and Fortran work fairly well. All other languages either don't work at all,
-or only work poorly. For the moment only the x86-32 and x86-64 targets are
-supported, and only on linux and darwin (darwin needs an additional gcc patch).
-</p>
-
-<p>
-DragonEgg is a new project which is seeing its first release with llvm-2.7.
-</p>
-
-</div>
-
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="mc">llvm-mc: Machine Code Toolkit</a>
-</div>
-
-<div class="doc_text">
-<p>
-The LLVM Machine Code (aka MC) sub-project of LLVM was created to solve a number
-of problems in the realm of assembly, disassembly, object file format handling,
-and a number of other related areas that CPU instruction-set level tools work
-in. It is a sub-project of LLVM which provides it with a number of advantages
-over other compilers that do not have tightly integrated assembly-level tools.
-For a gentle introduction, please see the <a
-href="http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html">Intro to the
-LLVM MC Project Blog Post</a>.
-</p>
-
-<p>2.7 includes major parts of the work required by the new MC Project. A few
- targets have been refactored to support it, and work is underway to support a
- native assembler in LLVM. This work is not complete in LLVM 2.7, but it has
- made substantially more progress on LLVM mainline.</p>
-
-<p>One minor example of what MC can do is to transcode an AT&T syntax
- X86 .s file into intel syntax. You can do this with something like:</p>
-<pre>
- llvm-mc foo.s -output-asm-variant=1 -o foo-intel.s
-</pre>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="externalproj">External Open Source Projects Using LLVM 2.7</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>An exciting aspect of LLVM is that it is used as an enabling technology for
- a lot of other language and tools projects. This section lists some of the
- projects that have already been updated to work with LLVM 2.7.</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="pure">Pure</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://pure-lang.googlecode.com/">Pure</a>
-is an algebraic/functional programming language based on term rewriting.
-Programs are collections of equations which are used to evaluate expressions in
-a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
-lexical closures, a hygienic macro system (also based on term rewriting),
-built-in list and matrix support (including list and matrix comprehensions) and
-an easy-to-use C interface. The interpreter uses LLVM as a backend to
- JIT-compile Pure programs to fast native code.</p>
-
-<p>Pure versions 0.43 and later have been tested and are known to work with
-LLVM 2.7 (and continue to work with older LLVM releases >= 2.5).</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="RoadsendPHP">Roadsend PHP</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://code.roadsend.com/rphp">Roadsend PHP</a> (rphp) is an open
-source implementation of the PHP programming
-language that uses LLVM for its optimizer, JIT and static compiler. This is a
-reimplementation of an earlier project that is now based on LLVM.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="UnladenSwallow">Unladen Swallow</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://code.google.com/p/unladen-swallow/">Unladen Swallow</a> is a
-branch of <a href="http://python.org/">Python</a> intended to be fully
-compatible and significantly faster. It uses LLVM's optimization passes and JIT
-compiler.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="tce">TTA-based Codesign Environment (TCE)</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://tce.cs.tut.fi/">TCE</a> is a toolset for designing
-application-specific processors (ASP) based on the Transport triggered
-architecture (TTA). The toolset provides a complete co-design flow from C/C++
-programs down to synthesizable VHDL and parallel program binaries. Processor
-customization points include the register files, function units, supported
-operations, and the interconnection network.</p>
-
-<p>TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target
-independent optimizations and also for parts of code generation. It generates
-new LLVM-based code generators "on the fly" for the designed TTA processors and
-loads them in to the compiler backend as runtime libraries to avoid per-target
-recompilation of larger parts of the compiler chain.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="safecode">SAFECode Compiler</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://safecode.cs.illinois.edu">SAFECode</a> is a memory safe C
-compiler built using LLVM. It takes standard, unannotated C code, analyzes the
-code to ensure that memory accesses and array indexing operations are safe, and
-instruments the code with run-time checks when safety cannot be proven
-statically.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="icedtea">IcedTea Java Virtual Machine Implementation</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://icedtea.classpath.org/wiki/Main_Page">IcedTea</a> provides a
-harness to build OpenJDK using only free software build tools and to provide
-replacements for the not-yet free parts of OpenJDK. One of the extensions that
-IcedTea provides is a new JIT compiler named <a
-href="http://icedtea.classpath.org/wiki/ZeroSharkFaq">Shark</a> which uses LLVM
-to provide native code generation without introducing processor-dependent
-code.
-</p>
-<p>Icedtea6 1.8 and later have been tested and are known to work with
-LLVM 2.7 (and continue to work with older LLVM releases >= 2.6 as well).
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="llvm-lua">LLVM-Lua</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://code.google.com/p/llvm-lua/">LLVM-Lua</a> uses LLVM
- to add JIT and static compiling support to the Lua VM. Lua
-bytecode is analyzed to remove type checks, then LLVM is used to compile the
-bytecode down to machine code.
-</p>
-<p>LLVM-Lua 1.2.0 have been tested and is known to work with LLVM 2.7.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="MacRuby">MacRuby</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://macruby.org">MacRuby</a> is an implementation of Ruby based on
-core Mac OS technologies, sponsored by Apple Inc. It uses LLVM at runtime for
-optimization passes, JIT compilation and exception handling. It also allows
-static (ahead-of-time) compilation of Ruby code straight to machine code.
-</p>
-<p>The upcoming MacRuby 0.6 release works with LLVM 2.7.
-</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="GHC">Glasgow Haskell Compiler (GHC)</a>
-</div>
-
-<div class="doc_text">
-<p>
-<a href="http://www.haskell.org/ghc/">GHC</a> is an open source,
-state-of-the-art programming suite for Haskell, a standard lazy
-functional programming language. It includes an optimizing static
-compiler generating good code for a variety of platforms, together
-with an interactive system for convenient, quick development.</p>
-
-<p>In addition to the existing C and native code generators, GHC now
-supports an <a
-href="http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM">LLVM
-code generator</a>. GHC supports LLVM 2.7.</p>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="whatsnew">What's New in LLVM 2.7?</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This release includes a huge number of bug fixes, performance tweaks and
-minor improvements. Some of the major improvements and new features are listed
-in this section.
-</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="orgchanges">LLVM Community Changes</a>
-</div>
-
-<div class="doc_text">
-
-<p>In addition to changes to the code, between LLVM 2.6 and 2.7, a number of
-organization changes have happened:
-</p>
-
-<ul>
-<li>LLVM has a new <a href="http://llvm.org/Logo.html">official logo</a>!</li>
-
-<li>Ted Kremenek and Doug Gregor have stepped forward as <a
- href="http://llvm.org/docs/DeveloperPolicy.html#owners">Code Owners</a> of the
- Clang static analyzer and the Clang frontend, respectively.</li>
-
-<li>LLVM now has an <a href="http://blog.llvm.org">official Blog</a> at
- <a href="http://blog.llvm.org">http://blog.llvm.org</a>. This is a great way
- to learn about new LLVM-related features as they are implemented. Several
- features in this release are already explained on the blog.</li>
-
-<li>The LLVM web pages are now checked into the SVN server, in the "www",
- "www-pubs" and "www-releases" SVN modules. Previously they were hidden in a
- largely inaccessible old CVS server.</li>
-
-<li><a href="http://llvm.org">llvm.org</a> is now hosted on a new (and much
- faster) server. It is still graciously hosted at the University of Illinois
- of Urbana Champaign.</li>
-</ul>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="majorfeatures">Major New Features</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM 2.7 includes several major new capabilities:</p>
-
-<ul>
-<li>2.7 includes initial support for the <a
- href="http://en.wikipedia.org/wiki/MicroBlaze">MicroBlaze</a> target.
- MicroBlaze is a soft processor core designed for Xilinx FPGAs.</li>
-
-<li>2.7 includes a new LLVM IR "extensible metadata" feature. This feature
- supports many different use cases, including allowing front-end authors to
- encode source level information into LLVM IR, which is consumed by later
- language-specific passes. This is a great way to do high-level optimizations
- like devirtualization, type-based alias analysis, etc. See the <a
- href="http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html">
- Extensible Metadata Blog Post</a> for more information.</li>
-
-<li>2.7 encodes <a href="SourceLevelDebugging.html">debug information</a>
-in a completely new way, built on extensible metadata. The new implementation
-is much more memory efficient and paves the way for improvements to optimized
-code debugging experience.</li>
-
-<li>2.7 now directly supports taking the address of a label and doing an
- indirect branch through a pointer. This is particularly useful for
- interpreter loops, and is used to implement the GCC "address of label"
- extension. For more information, see the <a
-href="http://blog.llvm.org/2010/01/address-of-label-and-indirect-branches.html">
-Address of Label and Indirect Branches in LLVM IR Blog Post</a>.
-
-<li>2.7 is the first release to start supporting APIs for assembling and
- disassembling target machine code. These APIs are useful for a variety of
- low level clients, and are surfaced in the new "enhanced disassembly" API.
- For more information see the <a
- href="http://blog.llvm.org/2010/01/x86-disassembler.html">The X86
- Disassembler Blog Post</a> for more information.</li>
-
-<li>2.7 includes major parts of the work required by the new MC Project,
- see the <a href="#mc">MC update above</a> for more information.</li>
-
-</ul>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="coreimprovements">LLVM IR and Core Improvements</a>
-</div>
-
-<div class="doc_text">
-<p>LLVM IR has several new features for better support of new targets and that
-expose new optimization opportunities:</p>
-
-<ul>
-<li>LLVM IR now supports a 16-bit "half float" data type through <a
- href="LangRef.html#int_fp16">two new intrinsics</a> and APFloat support.</li>
-<li>LLVM IR supports two new <a href="LangRef.html#fnattrs">function
- attributes</a>: inlinehint and alignstack(n). The former is a hint to the
- optimizer that a function was declared 'inline' and thus the inliner should
- weight it higher when considering inlining it. The later
- indicates to the code generator that the function diverges from the platform
- ABI on stack alignment.</li>
-<li>The new <a href="LangRef.html#int_objectsize">llvm.objectsize</a> intrinsic
- allows the optimizer to infer the sizes of memory objects in some cases.
- This intrinsic is used to implement the GCC <tt>__builtin_object_size</tt>
- extension.</li>
-<li>LLVM IR now supports marking load and store instructions with <a
- href="LangRef.html#i_load">"non-temporal" hints</a> (building on the new
- metadata feature). This hint encourages the code
- generator to generate non-temporal accesses when possible, which are useful
- for code that is carefully managing cache behavior. Currently, only the
- X86 backend provides target support for this feature.</li>
-
-<li>LLVM 2.7 has pre-alpha support for <a
- href="LangRef.html#t_union">unions in LLVM IR</a>.
- Unfortunately, this support is not really usable in 2.7, so if you're
- interested in pushing it forward, please help contribute to LLVM mainline.</li>
-
-</ul>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="optimizer">Optimizer Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<p>In addition to a large array of minor performance tweaks and bug fixes, this
-release includes a few major enhancements and additions to the optimizers:</p>
-
-<ul>
-
-<li>The inliner now merges arrays stack objects in different callees when
- inlining multiple call sites into one function. This reduces the stack size
- of the resultant function.</li>
-<li>The -basicaa alias analysis pass (which is the default) has been improved to
- be less dependent on "type safe" pointers. It can now look through bitcasts
- and other constructs more aggressively, allowing better load/store
- optimization.</li>
-<li>The load elimination optimization in the GVN Pass [<a
-href="http://blog.llvm.org/2009/12/introduction-to-load-elimination-in-gvn.html">intro
- blog post</a>] has been substantially improved to be more aggressive about
- partial redundancy elimination and do more aggressive phi translation. Please
- see the <a
- href="http://blog.llvm.org/2009/12/advanced-topics-in-redundant-load.html">
- Advanced Topics in Redundant Load Elimination with a Focus on PHI Translation
- Blog Post</a> for more details.</li>
-<li>The module <a href="LangRef.html#datalayout">target data string</a> now
- includes a notion of 'native' integer data types for the target. This
- helps mid-level optimizations avoid promoting complex sequences of
- operations to data types that are not natively supported (e.g. converting
- i32 operations to i64 on 32-bit chips).</li>
-<li>The mid-level optimizer is now conservative when operating on a module with
- no target data. Previously, it would default to SparcV9 settings, which is
- not what most people expected.</li>
-<li>Jump threading is now much more aggressive at simplifying correlated
- conditionals and threading blocks with otherwise complex logic. It has
- subsumed the old "Conditional Propagation" pass, and -condprop has been
- removed from LLVM 2.7.</li>
-<li>The -instcombine pass has been refactored from being one huge file to being
- a library of its own. Internally, it uses a customized IRBuilder to clean
- it up and simplify it.</li>
-
-<li>The optimal edge profiling pass is reliable and much more complete than in
- 2.6. It can be used with the llvm-prof tool but isn't wired up to the
- llvm-gcc and clang command line options yet.</li>
-
-<li>A new experimental alias analysis implementation, -scev-aa, has been added.
- It uses LLVM's Scalar Evolution implementation to do symbolic analysis of
- pointer offset expressions to disambiguate pointers. It can catch a few
- cases that basicaa cannot, particularly in complex loop nests.</li>
-
-<li>The default pass ordering has been tweaked for improved optimization
- effectiveness.</li>
-
-</ul>
-
-</div>
-
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="executionengine">Interpreter and JIT Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>The JIT now supports generating debug information and is compatible with
-the new GDB 7.0 (and later) interfaces for registering dynamically generated
-debug info.</li>
-
-<li>The JIT now <a href="http://llvm.org/PR5184">defaults
-to compiling eagerly</a> to avoid a race condition in the lazy JIT.
-Clients that still want the lazy JIT can switch it on by calling
-<tt>ExecutionEngine::DisableLazyCompilation(false)</tt>.</li>
-
-<li>It is now possible to create more than one JIT instance in the same process.
-These JITs can generate machine code in parallel,
-although <a href="http://llvm.org/docs/ProgrammersManual.html#jitthreading">you
-still have to obey the other threading restrictions</a>.</li>
-
-</ul>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="codegen">Target Independent Code Generator Improvements</a>
-</div>
-
-<div class="doc_text">
-
-<p>We have put a significant amount of work into the code generator
-infrastructure, which allows us to implement more aggressive algorithms and make
-it run faster:</p>
-
-<ul>
-<li>The 'llc -asm-verbose' option (which is now the default) has been enhanced
- to emit many useful comments to .s files indicating information about spill
- slots and loop nest structure. This should make it much easier to read and
- understand assembly files. This is wired up in llvm-gcc and clang to
- the <tt>-fverbose-asm</tt> option.</li>
-
-<li>New LSR with "full strength reduction" mode, which can reduce address
- register pressure in loops where address generation is important.</li>
-
-<li>A new codegen level Common Subexpression Elimination pass (MachineCSE)
- is available and enabled by default. It catches redundancies exposed by
- lowering.</li>
-<li>A new pre-register-allocation tail duplication pass is available and enabled
- by default, it can substantially improve branch prediction quality in some
- cases.</li>
-<li>A new sign and zero extension optimization pass (OptimizeExtsPass)
- is available and enabled by default. This pass can takes advantage
- architecture features like x86-64 implicit zero extension behavior and
- sub-registers.</li>
-<li>The code generator now supports a mode where it attempts to preserve the
- order of instructions in the input code. This is important for source that
- is hand scheduled and extremely sensitive to scheduling. It is compatible
- with the GCC <tt>-fno-schedule-insns</tt> option.</li>
-<li>The target-independent code generator now supports generating code with
- arbitrary numbers of result values. Returning more values than was
- previously supported is handled by returning through a hidden pointer. In
- 2.7, only the X86 and XCore targets have adopted support for this
- though.</li>
-<li>The code generator now supports generating code that follows the
- <a href="LangRef.html#callingconv">Glasgow Haskell Compiler Calling
- Convention</a> and ABI.</li>
-<li>The "<a href="CodeGenerator.html#selectiondag_select">DAG instruction
- selection</a>" phase of the code generator has been largely rewritten for
- 2.7. Previously, tblgen spit out tons of C++ code which was compiled and
- linked into the target to do the pattern matching, now it emits a much
- smaller table which is read by the target-independent code. The primary
- advantages of this approach is that the size and compile time of various
- targets is much improved. The X86 code generator shrunk by 1.5MB of code,
- for example.</li>
-<li>Almost the entire code generator has switched to emitting code through the
- MC interfaces instead of printing textually to the .s file. This led to a
- number of cleanups and speedups. In 2.7, debug an exception handling
- information does not go through MC yet.</li>
-</ul>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="x86">X86-32 and X86-64 Target Improvements</a>
-</div>
-
-<div class="doc_text">
-<p>New features of the X86 target include:
-</p>
-
-<ul>
-<li>The X86 backend now optimizes tails calls much more aggressively for
- functions that use the standard C calling convention.</li>
-<li>The X86 backend now models scalar SSE registers as subregs of the SSE vector
- registers, making the code generator more aggressive in cases where scalars
- and vector types are mixed.</li>
-
-</ul>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="ARM">ARM Target Improvements</a>
-</div>
-
-<div class="doc_text">
-<p>New features of the ARM target include:
-</p>
-
-<ul>
-
-<li>The ARM backend now generates instructions in unified assembly syntax.</li>
-
-<li>llvm-gcc now has complete support for the ARM v7 NEON instruction set. This
- support differs slightly from the GCC implementation. Please see the
- <a
-href="http://blog.llvm.org/2010/04/arm-advanced-simd-neon-intrinsics-and.html">
- ARM Advanced SIMD (NEON) Intrinsics and Types in LLVM Blog Post</a> for
- helpful information if migrating code from GCC to LLVM-GCC.</li>
-
-<li>The ARM and Thumb code generators now use register scavenging for stack
- object address materialization. This allows the use of R3 as a general
- purpose register in Thumb1 code, as it was previous reserved for use in
- stack address materialization. Secondly, sequential uses of the same
- value will now re-use the materialized constant.</li>
-
-<li>The ARM backend now has good support for ARMv4 targets and has been tested
- on StrongARM hardware. Previously, LLVM only supported ARMv4T and
- newer chips.</li>
-
-<li>Atomic builtins are now supported for ARMv6 and ARMv7 (__sync_synchronize,
- __sync_fetch_and_add, etc.).</li>
-
-</ul>
-
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="newapis">New Useful APIs</a>
-</div>
-
-<div class="doc_text">
-
-<p>This release includes a number of new APIs that are used internally, which
- may also be useful for external clients.
-</p>
-
-<ul>
-<li>The optimizer uses the new CodeMetrics class to measure the size of code.
- Various passes (like the inliner, loop unswitcher, etc) all use this to make
- more accurate estimates of the code size impact of various
- optimizations.</li>
-<li>A new <a href="http://llvm.org/doxygen/InstructionSimplify_8h-source.html">
- llvm/Analysis/InstructionSimplify.h</a> interface is available for doing
- symbolic simplification of instructions (e.g. <tt>a+0</tt> -> <tt>a</tt>)
- without requiring the instruction to exist. This centralizes a lot of
- ad-hoc symbolic manipulation code scattered in various passes.</li>
-<li>The optimizer now uses a new <a
- href="http://llvm.org/doxygen/SSAUpdater_8h-source.html">SSAUpdater</a>
- class which efficiently supports
- doing unstructured SSA update operations. This centralized a bunch of code
- scattered throughout various passes (e.g. jump threading, lcssa,
- loop rotate, etc) for doing this sort of thing. The code generator has a
- similar <a href="http://llvm.org/doxygen/MachineSSAUpdater_8h-source.html">
- MachineSSAUpdater</a> class.</li>
-<li>The <a href="http://llvm.org/doxygen/Regex_8h-source.html">
- llvm/Support/Regex.h</a> header exposes a platform independent regular
- expression API. Building on this, the <a
- href="TestingGuide.html#FileCheck">FileCheck</a> utility now supports
- regular exressions.</li>
-<li>raw_ostream now supports a circular "debug stream" accessed with "dbgs()".
- By default, this stream works the same way as "errs()", but if you pass
- <tt>-debug-buffer-size=1000</tt> to opt, the debug stream is capped to a
- fixed sized circular buffer and the output is printed at the end of the
- program's execution. This is helpful if you have a long lived compiler
- process and you're interested in seeing snapshots in time.</li>
-</ul>
-
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="otherimprovements">Other Improvements and New Features</a>
-</div>
-
-<div class="doc_text">
-<p>Other miscellaneous features include:</p>
-
-<ul>
-<li>You can now build LLVM as a big dynamic library (e.g. "libllvm2.7.so"). To
- get this, configure LLVM with the --enable-shared option.</li>
-
-<li>LLVM command line tools now overwrite their output by default. Previously,
- they would only do this with -f. This makes them more convenient to use, and
- behave more like standard unix tools.</li>
-
-<li>The opt and llc tools now autodetect whether their input is a .ll or .bc
- file, and automatically do the right thing. This means you don't need to
- explicitly use the llvm-as tool for most things.</li>
-</ul>
-
-</div>
-
-
-<!--=========================================================================-->
-<div class="doc_subsection">
-<a name="changes">Major Changes and Removed Features</a>
-</div>
-
-<div class="doc_text">
-
-<p>If you're already an LLVM user or developer with out-of-tree changes based
-on LLVM 2.6, this section lists some "gotchas" that you may run into upgrading
-from the previous release.</p>
-
-<ul>
-
-<li>
-The Andersen's alias analysis ("anders-aa") pass, the Predicate Simplifier
-("predsimplify") pass, the LoopVR pass, the GVNPRE pass, and the random sampling
-profiling ("rsprofiling") passes have all been removed. They were not being
-actively maintained and had substantial problems. If you are interested in
-these components, you are welcome to ressurect them from SVN, fix the
-correctness problems, and resubmit them to mainline.</li>
-
-<li>LLVM now defaults to building most libraries with RTTI turned off, providing
-a code size reduction. Packagers who are interested in building LLVM to support
-plugins that require RTTI information should build with "make REQUIRE_RTTI=1"
-and should read the new <a href="Packaging.html">Advice on Packaging LLVM</a>
-document.</li>
-
-<li>The LLVM interpreter now defaults to <em>not</em> using <tt>libffi</tt> even
-if you have it installed. This makes it more likely that an LLVM built on one
-system will work when copied to a similar system. To use <tt>libffi</tt>,
-configure with <tt>--enable-libffi</tt>.</li>
-
-<li>Debug information uses a completely different representation, an LLVM 2.6
-.bc file should work with LLVM 2.7, but debug info won't come forward.</li>
-
-<li>The LLVM 2.6 (and earlier) "malloc" and "free" instructions got removed,
- along with LowerAllocations pass. Now you should just use a call to the
- malloc and free functions in libc. These calls are optimized as well as
- the old instructions were.</li>
-</ul>
-
-<p>In addition, many APIs have changed in this release. Some of the major LLVM
-API changes are:</p>
-
-<ul>
-
-<li>The <tt>add</tt>, <tt>sub</tt>, and <tt>mul</tt> instructions no longer
-support floating-point operands. The <tt>fadd</tt>, <tt>fsub</tt>, and
-<tt>fmul</tt> instructions should be used for this purpose instead.</li>
-
-</ul>
-
-</div>
-
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="portability">Portability and Supported Platforms</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>LLVM is known to work on the following platforms:</p>
-
-<ul>
-<li>Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
- Linux, Fedora Core, FreeBSD and AuroraUX (and probably other unix-like
- systems).</li>
-<li>PowerPC and X86-based Mac OS X systems, running 10.4 and above in 32-bit
- and 64-bit modes.</li>
-<li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
-<li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
- support is available for native builds with Visual C++).</li>
-<li>Sun x86 and AMD64 machines running Solaris 10, OpenSolaris 0906.</li>
-<li>Alpha-based machines running Debian GNU/Linux.</li>
-</ul>
-
-<p>The core LLVM infrastructure uses GNU autoconf to adapt itself
-to the machine and operating system on which it is built. However, minor
-porting may be required to get LLVM to work on new platforms. We welcome your
-portability patches and reports of successful builds or error messages.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="knownproblems">Known Problems</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This section contains significant known problems with the LLVM system,
-listed by component. If you run into a problem, please check the <a
-href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
-there isn't already one.</p>
-
-<ul>
-<li>LLVM will not correctly compile on Solaris and/or OpenSolaris
-using the stock GCC 3.x.x series 'out the box',
-See: <a href="GettingStarted.html#brokengcc">Broken versions of GCC and other tools</a>.
-However, A <a href="http://pkg.auroraux.org/GCC">Modern GCC Build</a>
-for x86/x86-64 has been made available from the third party AuroraUX Project
-that has been meticulously tested for bootstrapping LLVM & Clang.</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="experimental">Experimental features included with this release</a>
-</div>
-
-<div class="doc_text">
-
-<p>The following components of this LLVM release are either untested, known to
-be broken or unreliable, or are in early development. These components should
-not be relied on, and bugs should not be filed against them, but they may be
-useful to some people. In particular, if you would like to work on one of these
-components, please contact us on the <a
-href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
-
-<ul>
-<li>The MSIL, Alpha, SPU, MIPS, PIC16, Blackfin, MSP430, SystemZ and MicroBlaze
- backends are experimental.</li>
-<li><tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
- supported value for this option. The MachO writer is experimental, and
- works much better in mainline SVN.</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="x86-be">Known problems with the X86 back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
- <li>The X86 backend does not yet support
- all <a href="http://llvm.org/PR879">inline assembly that uses the X86
- floating point stack</a>. It supports the 'f' and 't' constraints, but not
- 'u'.</li>
- <li>The X86 backend generates inefficient floating point code when configured
- to generate code for systems that don't have SSE2.</li>
- <li>Win64 code generation wasn't widely tested. Everything should work, but we
- expect small issues to happen. Also, llvm-gcc cannot build the mingw64
- runtime currently due to lack of support for the 'u' inline assembly
- constraint and for X87 floating point inline assembly.</li>
- <li>The X86-64 backend does not yet support the LLVM IR instruction
- <tt>va_arg</tt>. Currently, front-ends support variadic
- argument constructs on X86-64 by lowering them manually.</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ppc-be">Known problems with the PowerPC back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>The Linux PPC32/ABI support needs testing for the interpreter and static
-compilation, and lacks support for debug information.</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="arm-be">Known problems with the ARM back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
-processors, thumb programs can crash or produce wrong
-results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
-<li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
-</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="sparc-be">Known problems with the SPARC back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
- support the 64-bit SPARC ABI (-m64).</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="mips-be">Known problems with the MIPS back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li>64-bit MIPS targets are not supported yet.</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="alpha-be">Known problems with the Alpha back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-
-<li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
-appropriate nops inserted to ensure restartability.</li>
-
-</ul>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="c-be">Known problems with the C back-end</a>
-</div>
-
-<div class="doc_text">
-
-<ul>
-<li><a href="http://llvm.org/PR802">The C backend has only basic support for
- inline assembly code</a>.</li>
-<li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
- C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
- C++ code compiled with <tt>llc</tt> or native compilers.</li>
-<li>The C backend does not support all exception handling constructs.</li>
-<li>The C backend does not support arbitrary precision integers.</li>
-</ul>
-
-</div>
-
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="c-fe">Known problems with the llvm-gcc C and C++ front-end</a>
-</div>
-
-<div class="doc_text">
-
-<p>The only major language feature of GCC not supported by llvm-gcc is
- the <tt>__builtin_apply</tt> family of builtins. However, some extensions
- are only supported on some targets. For example, trampolines are only
- supported on some targets (these are used when you take the address of a
- nested function).</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="fortran-fe">Known problems with the llvm-gcc Fortran front-end</a>
-</div>
-
-<div class="doc_text">
-<ul>
-<li>Fortran support generally works, but there are still several unresolved bugs
- in <a href="http://llvm.org/bugs/">Bugzilla</a>. Please see the
- tools/gfortran component for details.</li>
-</ul>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
-</div>
-
-<div class="doc_text">
-The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
-technology, and problems should be expected.
-<ul>
-<li>The Ada front-end currently only builds on X86-32. This is mainly due
-to lack of trampoline support (pointers to nested functions) on other platforms.
-However, it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
-which does support trampolines.</li>
-<li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
-This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
-exception handling, which is used internally by the compiler.
-Workaround: configure with <tt>--disable-bootstrap</tt>.</li>
-<li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
-and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
-(c380004 also fails with gcc-4.2 mainline).
-If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
-causes the compiler to go into an infinite loop, using up all system memory.</li>
-<li>Some GCC specific Ada tests continue to crash the compiler.</li>
-<li>The <tt>-E</tt> binder option (exception backtraces)
-<a href="http://llvm.org/PR1982">does not work</a> and will result in programs
-crashing if an exception is raised. Workaround: do not use <tt>-E</tt>.</li>
-<li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
-or finish at a non-byte offset</a> in a record. Workaround: do not pack records
-or use representation clauses that result in a field of a non-discrete type
-starting or finishing in the middle of a byte.</li>
-<li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
-'main' as generated by the Ada binder to be invalid</a>.
-Workaround: hand edit the file to use pointers for <tt>argv</tt> and
-<tt>envp</tt> rather than integers.</li>
-<li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
-ignored</a>.</li>
-</ul>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="additionalinfo">Additional Information</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>A wide variety of additional information is available on the <a
-href="http://llvm.org">LLVM web page</a>, in particular in the <a
-href="http://llvm.org/docs/">documentation</a> section. The web page also
-contains versions of the API documentation which is up-to-date with the
-Subversion version of the source code.
-You can access versions of these documents specific to this release by going
-into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
-
-<p>If you have any questions or comments about LLVM, please feel free to contact
-us via the <a href="http://llvm.org/docs/#maillist"> mailing
-lists</a>.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/SourceLevelDebugging.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/SourceLevelDebugging.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/SourceLevelDebugging.html (original)
+++ llvm/trunk/docs/SourceLevelDebugging.html (removed)
@@ -1,1780 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <title>Source Level Debugging with LLVM</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">Source Level Debugging with LLVM</div>
-
-<table class="layout" style="width:100%">
- <tr class="layout">
- <td class="left">
-<ul>
- <li><a href="#introduction">Introduction</a>
- <ol>
- <li><a href="#phil">Philosophy behind LLVM debugging information</a></li>
- <li><a href="#consumers">Debug information consumers</a></li>
- <li><a href="#debugopt">Debugging optimized code</a></li>
- </ol></li>
- <li><a href="#format">Debugging information format</a>
- <ol>
- <li><a href="#debug_info_descriptors">Debug information descriptors</a>
- <ul>
- <li><a href="#format_compile_units">Compile unit descriptors</a></li>
- <li><a href="#format_files">File descriptors</a></li>
- <li><a href="#format_global_variables">Global variable descriptors</a></li>
- <li><a href="#format_subprograms">Subprogram descriptors</a></li>
- <li><a href="#format_blocks">Block descriptors</a></li>
- <li><a href="#format_basic_type">Basic type descriptors</a></li>
- <li><a href="#format_derived_type">Derived type descriptors</a></li>
- <li><a href="#format_composite_type">Composite type descriptors</a></li>
- <li><a href="#format_subrange">Subrange descriptors</a></li>
- <li><a href="#format_enumeration">Enumerator descriptors</a></li>
- <li><a href="#format_variables">Local variables</a></li>
- </ul></li>
- <li><a href="#format_common_intrinsics">Debugger intrinsic functions</a>
- <ul>
- <li><a href="#format_common_declare">llvm.dbg.declare</a></li>
- <li><a href="#format_common_value">llvm.dbg.value</a></li>
- </ul></li>
- </ol></li>
- <li><a href="#format_common_lifetime">Object lifetimes and scoping</a></li>
- <li><a href="#ccxx_frontend">C/C++ front-end specific debug information</a>
- <ol>
- <li><a href="#ccxx_compile_units">C/C++ source file information</a></li>
- <li><a href="#ccxx_global_variable">C/C++ global variable information</a></li>
- <li><a href="#ccxx_subprogram">C/C++ function information</a></li>
- <li><a href="#ccxx_basic_types">C/C++ basic types</a></li>
- <li><a href="#ccxx_derived_types">C/C++ derived types</a></li>
- <li><a href="#ccxx_composite_types">C/C++ struct/union types</a></li>
- <li><a href="#ccxx_enumeration_types">C/C++ enumeration types</a></li>
- </ol></li>
-</ul>
-</td>
-<td class="right">
-<img src="img/venusflytrap.jpg" alt="A leafy and green bug eater" width="247"
-height="369">
-</td>
-</tr></table>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>
- and <a href="mailto:jlaskey at mac.com">Jim Laskey</a></p>
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="introduction">Introduction</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>This document is the central repository for all information pertaining to
- debug information in LLVM. It describes the <a href="#format">actual format
- that the LLVM debug information</a> takes, which is useful for those
- interested in creating front-ends or dealing directly with the information.
- Further, this document provides specific examples of what debug information
- for C/C++.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="phil">Philosophy behind LLVM debugging information</a>
-</div>
-
-<div class="doc_text">
-
-<p>The idea of the LLVM debugging information is to capture how the important
- pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
- Several design aspects have shaped the solution that appears here. The
- important ones are:</p>
-
-<ul>
- <li>Debugging information should have very little impact on the rest of the
- compiler. No transformations, analyses, or code generators should need to
- be modified because of debugging information.</li>
-
- <li>LLVM optimizations should interact in <a href="#debugopt">well-defined and
- easily described ways</a> with the debugging information.</li>
-
- <li>Because LLVM is designed to support arbitrary programming languages,
- LLVM-to-LLVM tools should not need to know anything about the semantics of
- the source-level-language.</li>
-
- <li>Source-level languages are often <b>widely</b> different from one another.
- LLVM should not put any restrictions of the flavor of the source-language,
- and the debugging information should work with any language.</li>
-
- <li>With code generator support, it should be possible to use an LLVM compiler
- to compile a program to native machine code and standard debugging
- formats. This allows compatibility with traditional machine-code level
- debuggers, like GDB or DBX.</li>
-</ul>
-
-<p>The approach used by the LLVM implementation is to use a small set
- of <a href="#format_common_intrinsics">intrinsic functions</a> to define a
- mapping between LLVM program objects and the source-level objects. The
- description of the source-level program is maintained in LLVM metadata
- in an <a href="#ccxx_frontend">implementation-defined format</a>
- (the C/C++ front-end currently uses working draft 7 of
- the <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3
- standard</a>).</p>
-
-<p>When a program is being debugged, a debugger interacts with the user and
- turns the stored debug information into source-language specific information.
- As such, a debugger must be aware of the source-language, and is thus tied to
- a specific language or family of languages.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="consumers">Debug information consumers</a>
-</div>
-
-<div class="doc_text">
-
-<p>The role of debug information is to provide meta information normally
- stripped away during the compilation process. This meta information provides
- an LLVM user a relationship between generated code and the original program
- source code.</p>
-
-<p>Currently, debug information is consumed by DwarfDebug to produce dwarf
- information used by the gdb debugger. Other targets could use the same
- information to produce stabs or other debug forms.</p>
-
-<p>It would also be reasonable to use debug information to feed profiling tools
- for analysis of generated code, or, tools for reconstructing the original
- source from generated code.</p>
-
-<p>TODO - expound a bit more.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="debugopt">Debugging optimized code</a>
-</div>
-
-<div class="doc_text">
-
-<p>An extremely high priority of LLVM debugging information is to make it
- interact well with optimizations and analysis. In particular, the LLVM debug
- information provides the following guarantees:</p>
-
-<ul>
- <li>LLVM debug information <b>always provides information to accurately read
- the source-level state of the program</b>, regardless of which LLVM
- optimizations have been run, and without any modification to the
- optimizations themselves. However, some optimizations may impact the
- ability to modify the current state of the program with a debugger, such
- as setting program variables, or calling functions that have been
- deleted.</li>
-
- <li>LLVM optimizations gracefully interact with debugging information. If
- they are not aware of debug information, they are automatically disabled
- as necessary in the cases that would invalidate the debug info. This
- retains the LLVM features, making it easy to write new
- transformations.</li>
-
- <li>As desired, LLVM optimizations can be upgraded to be aware of the LLVM
- debugging information, allowing them to update the debugging information
- as they perform aggressive optimizations. This means that, with effort,
- the LLVM optimizers could optimize debug code just as well as non-debug
- code.</li>
-
- <li>LLVM debug information does not prevent many important optimizations from
- happening (for example inlining, basic block reordering/merging/cleanup,
- tail duplication, etc), further reducing the amount of the compiler that
- eventually is "aware" of debugging information.</li>
-
- <li>LLVM debug information is automatically optimized along with the rest of
- the program, using existing facilities. For example, duplicate
- information is automatically merged by the linker, and unused information
- is automatically removed.</li>
-</ul>
-
-<p>Basically, the debug information allows you to compile a program with
- "<tt>-O0 -g</tt>" and get full debug information, allowing you to arbitrarily
- modify the program as it executes from a debugger. Compiling a program with
- "<tt>-O3 -g</tt>" gives you full debug information that is always available
- and accurate for reading (e.g., you get accurate stack traces despite tail
- call elimination and inlining), but you might lose the ability to modify the
- program and call functions where were optimized out of the program, or
- inlined away completely.</p>
-
-<p><a href="TestingGuide.html#quicktestsuite">LLVM test suite</a> provides a
- framework to test optimizer's handling of debugging information. It can be
- run like this:</p>
-
-<div class="doc_code">
-<pre>
-% cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level
-% make TEST=dbgopt
-</pre>
-</div>
-
-<p>This will test impact of debugging information on optimization passes. If
- debugging information influences optimization passes then it will be reported
- as a failure. See <a href="TestingGuide.html">TestingGuide</a> for more
- information on LLVM test infrastructure and how to run various tests.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="format">Debugging information format</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>LLVM debugging information has been carefully designed to make it possible
- for the optimizer to optimize the program and debugging information without
- necessarily having to know anything about debugging information. In
- particular, the use of metadata avoids duplicated debugging information from
- the beginning, and the global dead code elimination pass automatically
- deletes debugging information for a function if it decides to delete the
- function. </p>
-
-<p>To do this, most of the debugging information (descriptors for types,
- variables, functions, source files, etc) is inserted by the language
- front-end in the form of LLVM metadata. </p>
-
-<p>Debug information is designed to be agnostic about the target debugger and
- debugging information representation (e.g. DWARF/Stabs/etc). It uses a
- generic pass to decode the information that represents variables, types,
- functions, namespaces, etc: this allows for arbitrary source-language
- semantics and type-systems to be used, as long as there is a module
- written for the target debugger to interpret the information. </p>
-
-<p>To provide basic functionality, the LLVM debugger does have to make some
- assumptions about the source-level language being debugged, though it keeps
- these to a minimum. The only common features that the LLVM debugger assumes
- exist are <a href="#format_files">source files</a>,
- and <a href="#format_global_variables">program objects</a>. These abstract
- objects are used by a debugger to form stack traces, show information about
- local variables, etc.</p>
-
-<p>This section of the documentation first describes the representation aspects
- common to any source-language. The <a href="#ccxx_frontend">next section</a>
- describes the data layout conventions used by the C and C++ front-ends.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="debug_info_descriptors">Debug information descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<p>In consideration of the complexity and volume of debug information, LLVM
- provides a specification for well formed debug descriptors. </p>
-
-<p>Consumers of LLVM debug information expect the descriptors for program
- objects to start in a canonical format, but the descriptors can include
- additional information appended at the end that is source-language
- specific. All LLVM debugging information is versioned, allowing backwards
- compatibility in the case that the core structures need to change in some
- way. Also, all debugging information objects start with a tag to indicate
- what type of object it is. The source-language is allowed to define its own
- objects, by using unreserved tag numbers. We recommend using with tags in
- the range 0x1000 through 0x2000 (there is a defined enum DW_TAG_user_base =
- 0x1000.)</p>
-
-<p>The fields of debug descriptors used internally by LLVM
- are restricted to only the simple data types <tt>i32</tt>, <tt>i1</tt>,
- <tt>float</tt>, <tt>double</tt>, <tt>mdstring</tt> and <tt>mdnode</tt>. </p>
-
-<div class="doc_code">
-<pre>
-!1 = metadata !{
- i32, ;; A tag
- ...
-}
-</pre>
-</div>
-
-<p><a name="LLVMDebugVersion">The first field of a descriptor is always an
- <tt>i32</tt> containing a tag value identifying the content of the
- descriptor. The remaining fields are specific to the descriptor. The values
- of tags are loosely bound to the tag values of DWARF information entries.
- However, that does not restrict the use of the information supplied to DWARF
- targets. To facilitate versioning of debug information, the tag is augmented
- with the current debug version (LLVMDebugVersion = 8 << 16 or 0x80000 or
- 524288.)</a></p>
-
-<p>The details of the various descriptors follow.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_compile_units">Compile unit descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!0 = metadata !{
- i32, ;; Tag = 17 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- ;; (DW_TAG_compile_unit)
- i32, ;; Unused field.
- i32, ;; DWARF language identifier (ex. DW_LANG_C89)
- metadata, ;; Source file name
- metadata, ;; Source file directory (includes trailing slash)
- metadata ;; Producer (ex. "4.0.1 LLVM (LLVM research group)")
- i1, ;; True if this is a main compile unit.
- i1, ;; True if this is optimized.
- metadata, ;; Flags
- i32 ;; Runtime version
-}
-</pre>
-</div>
-
-<p>These descriptors contain a source language ID for the file (we use the DWARF
- 3.0 ID numbers, such as <tt>DW_LANG_C89</tt>, <tt>DW_LANG_C_plus_plus</tt>,
- <tt>DW_LANG_Cobol74</tt>, etc), three strings describing the filename,
- working directory of the compiler, and an identifier string for the compiler
- that produced it.</p>
-
-<p>Compile unit descriptors provide the root context for objects declared in a
- specific compilation unit. File descriptors are defined using this context.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_files">File descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!0 = metadata !{
- i32, ;; Tag = 41 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- ;; (DW_TAG_file_type)
- metadata, ;; Source file name
- metadata, ;; Source file directory (includes trailing slash)
- metadata ;; Reference to compile unit where defined
-}
-</pre>
-</div>
-
-<p>These descriptors contain information for a file. Global variables and top
- level functions would be defined using this context.k File descriptors also
- provide context for source line correspondence. </p>
-
-<p>Each input file is encoded as a separate file descriptor in LLVM debugging
- information output. Each file descriptor would be defined using a
- compile unit. </p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_global_variables">Global variable descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!1 = metadata !{
- i32, ;; Tag = 52 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- ;; (DW_TAG_variable)
- i32, ;; Unused field.
- metadata, ;; Reference to context descriptor
- metadata, ;; Name
- metadata, ;; Display name (fully qualified C++ name)
- metadata, ;; MIPS linkage name (for C++)
- metadata, ;; Reference to file where defined
- i32, ;; Line number where defined
- metadata, ;; Reference to type descriptor
- i1, ;; True if the global is local to compile unit (static)
- i1, ;; True if the global is defined in the compile unit (not extern)
- { }* ;; Reference to the global variable
-}
-</pre>
-</div>
-
-<p>These descriptors provide debug information about globals variables. The
-provide details such as name, type and where the variable is defined.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_subprograms">Subprogram descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32, ;; Tag = 46 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- ;; (DW_TAG_subprogram)
- i32, ;; Unused field.
- metadata, ;; Reference to context descriptor
- metadata, ;; Name
- metadata, ;; Display name (fully qualified C++ name)
- metadata, ;; MIPS linkage name (for C++)
- metadata, ;; Reference to file where defined
- i32, ;; Line number where defined
- metadata, ;; Reference to type descriptor
- i1, ;; True if the global is local to compile unit (static)
- i1 ;; True if the global is defined in the compile unit (not extern)
-}
-</pre>
-</div>
-
-<p>These descriptors provide debug information about functions, methods and
- subprograms. They provide details such as name, return types and the source
- location where the subprogram is defined.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_blocks">Block descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!3 = metadata !{
- i32, ;; Tag = 13 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_lexical_block)
- metadata ;; Reference to context descriptor
-}
-</pre>
-</div>
-
-<p>These descriptors provide debug information about nested blocks within a
- subprogram. The array of member descriptors is used to define local
- variables and deeper nested blocks.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_basic_type">Basic type descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!4 = metadata !{
- i32, ;; Tag = 36 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- ;; (DW_TAG_base_type)
- metadata, ;; Reference to context (typically a compile unit)
- metadata, ;; Name (may be "" for anonymous types)
- metadata, ;; Reference to file where defined (may be NULL)
- i32, ;; Line number where defined (may be 0)
- i64, ;; Size in bits
- i64, ;; Alignment in bits
- i64, ;; Offset in bits
- i32, ;; Flags
- i32 ;; DWARF type encoding
-}
-</pre>
-</div>
-
-<p>These descriptors define primitive types used in the code. Example int, bool
- and float. The context provides the scope of the type, which is usually the
- top level. Since basic types are not usually user defined the compile unit
- and line number can be left as NULL and 0. The size, alignment and offset
- are expressed in bits and can be 64 bit values. The alignment is used to
- round the offset when embedded in a
- <a href="#format_composite_type">composite type</a> (example to keep float
- doubles on 64 bit boundaries.) The offset is the bit offset if embedded in
- a <a href="#format_composite_type">composite type</a>.</p>
-
-<p>The type encoding provides the details of the type. The values are typically
- one of the following:</p>
-
-<div class="doc_code">
-<pre>
-DW_ATE_address = 1
-DW_ATE_boolean = 2
-DW_ATE_float = 4
-DW_ATE_signed = 5
-DW_ATE_signed_char = 6
-DW_ATE_unsigned = 7
-DW_ATE_unsigned_char = 8
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_derived_type">Derived type descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!5 = metadata !{
- i32, ;; Tag (see below)
- metadata, ;; Reference to context
- metadata, ;; Name (may be "" for anonymous types)
- metadata, ;; Reference to file where defined (may be NULL)
- i32, ;; Line number where defined (may be 0)
- i32, ;; Size in bits
- i32, ;; Alignment in bits
- i32, ;; Offset in bits
- metadata ;; Reference to type derived from
-}
-</pre>
-</div>
-
-<p>These descriptors are used to define types derived from other types. The
-value of the tag varies depending on the meaning. The following are possible
-tag values:</p>
-
-<div class="doc_code">
-<pre>
-DW_TAG_formal_parameter = 5
-DW_TAG_member = 13
-DW_TAG_pointer_type = 15
-DW_TAG_reference_type = 16
-DW_TAG_typedef = 22
-DW_TAG_const_type = 38
-DW_TAG_volatile_type = 53
-DW_TAG_restrict_type = 55
-</pre>
-</div>
-
-<p><tt>DW_TAG_member</tt> is used to define a member of
- a <a href="#format_composite_type">composite type</a>
- or <a href="#format_subprograms">subprogram</a>. The type of the member is
- the <a href="#format_derived_type">derived
- type</a>. <tt>DW_TAG_formal_parameter</tt> is used to define a member which
- is a formal argument of a subprogram.</p>
-
-<p><tt>DW_TAG_typedef</tt> is used to provide a name for the derived type.</p>
-
-<p><tt>DW_TAG_pointer_type</tt>,<tt>DW_TAG_reference_type</tt>,
- <tt>DW_TAG_const_type</tt>, <tt>DW_TAG_volatile_type</tt>
- and <tt>DW_TAG_restrict_type</tt> are used to qualify
- the <a href="#format_derived_type">derived type</a>. </p>
-
-<p><a href="#format_derived_type">Derived type</a> location can be determined
- from the compile unit and line number. The size, alignment and offset are
- expressed in bits and can be 64 bit values. The alignment is used to round
- the offset when embedded in a <a href="#format_composite_type">composite
- type</a> (example to keep float doubles on 64 bit boundaries.) The offset is
- the bit offset if embedded in a <a href="#format_composite_type">composite
- type</a>.</p>
-
-<p>Note that the <tt>void *</tt> type is expressed as a
- <tt>llvm.dbg.derivedtype.type</tt> with tag of <tt>DW_TAG_pointer_type</tt>
- and <tt>NULL</tt> derived type.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_composite_type">Composite type descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!6 = metadata !{
- i32, ;; Tag (see below)
- metadata, ;; Reference to context
- metadata, ;; Name (may be "" for anonymous types)
- metadata, ;; Reference to file where defined (may be NULL)
- i32, ;; Line number where defined (may be 0)
- i64, ;; Size in bits
- i64, ;; Alignment in bits
- i64, ;; Offset in bits
- i32, ;; Flags
- metadata, ;; Reference to type derived from
- metadata, ;; Reference to array of member descriptors
- i32 ;; Runtime languages
-}
-</pre>
-</div>
-
-<p>These descriptors are used to define types that are composed of 0 or more
-elements. The value of the tag varies depending on the meaning. The following
-are possible tag values:</p>
-
-<div class="doc_code">
-<pre>
-DW_TAG_array_type = 1
-DW_TAG_enumeration_type = 4
-DW_TAG_structure_type = 19
-DW_TAG_union_type = 23
-DW_TAG_vector_type = 259
-DW_TAG_subroutine_type = 21
-DW_TAG_inheritance = 28
-</pre>
-</div>
-
-<p>The vector flag indicates that an array type is a native packed vector.</p>
-
-<p>The members of array types (tag = <tt>DW_TAG_array_type</tt>) or vector types
- (tag = <tt>DW_TAG_vector_type</tt>) are <a href="#format_subrange">subrange
- descriptors</a>, each representing the range of subscripts at that level of
- indexing.</p>
-
-<p>The members of enumeration types (tag = <tt>DW_TAG_enumeration_type</tt>) are
- <a href="#format_enumeration">enumerator descriptors</a>, each representing
- the definition of enumeration value for the set.</p>
-
-<p>The members of structure (tag = <tt>DW_TAG_structure_type</tt>) or union (tag
- = <tt>DW_TAG_union_type</tt>) types are any one of
- the <a href="#format_basic_type">basic</a>,
- <a href="#format_derived_type">derived</a>
- or <a href="#format_composite_type">composite</a> type descriptors, each
- representing a field member of the structure or union.</p>
-
-<p>For C++ classes (tag = <tt>DW_TAG_structure_type</tt>), member descriptors
- provide information about base classes, static members and member
- functions. If a member is a <a href="#format_derived_type">derived type
- descriptor</a> and has a tag of <tt>DW_TAG_inheritance</tt>, then the type
- represents a base class. If the member of is
- a <a href="#format_global_variables">global variable descriptor</a> then it
- represents a static member. And, if the member is
- a <a href="#format_subprograms">subprogram descriptor</a> then it represents
- a member function. For static members and member
- functions, <tt>getName()</tt> returns the members link or the C++ mangled
- name. <tt>getDisplayName()</tt> the simplied version of the name.</p>
-
-<p>The first member of subroutine (tag = <tt>DW_TAG_subroutine_type</tt>) type
- elements is the return type for the subroutine. The remaining elements are
- the formal arguments to the subroutine.</p>
-
-<p><a href="#format_composite_type">Composite type</a> location can be
- determined from the compile unit and line number. The size, alignment and
- offset are expressed in bits and can be 64 bit values. The alignment is used
- to round the offset when embedded in
- a <a href="#format_composite_type">composite type</a> (as an example, to keep
- float doubles on 64 bit boundaries.) The offset is the bit offset if embedded
- in a <a href="#format_composite_type">composite type</a>.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_subrange">Subrange descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-%<a href="#format_subrange">llvm.dbg.subrange.type</a> = type {
- i32, ;; Tag = 33 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subrange_type)
- i64, ;; Low value
- i64 ;; High value
-}
-</pre>
-</div>
-
-<p>These descriptors are used to define ranges of array subscripts for an array
- <a href="#format_composite_type">composite type</a>. The low value defines
- the lower bounds typically zero for C/C++. The high value is the upper
- bounds. Values are 64 bit. High - low + 1 is the size of the array. If low
- == high the array will be unbounded.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_enumeration">Enumerator descriptors</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!6 = metadata !{
- i32, ;; Tag = 40 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
- ;; (DW_TAG_enumerator)
- metadata, ;; Name
- i64 ;; Value
-}
-</pre>
-</div>
-
-<p>These descriptors are used to define members of an
- enumeration <a href="#format_composite_type">composite type</a>, it
- associates the name to the value.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_variables">Local variables</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!7 = metadata !{
- i32, ;; Tag (see below)
- metadata, ;; Context
- metadata, ;; Name
- metadata, ;; Reference to file where defined
- i32, ;; Line number where defined
- metadata ;; Type descriptor
-}
-</pre>
-</div>
-
-<p>These descriptors are used to define variables local to a sub program. The
- value of the tag depends on the usage of the variable:</p>
-
-<div class="doc_code">
-<pre>
-DW_TAG_auto_variable = 256
-DW_TAG_arg_variable = 257
-DW_TAG_return_variable = 258
-</pre>
-</div>
-
-<p>An auto variable is any variable declared in the body of the function. An
- argument variable is any variable that appears as a formal argument to the
- function. A return variable is used to track the result of a function and
- has no source correspondent.</p>
-
-<p>The context is either the subprogram or block where the variable is defined.
- Name the source variable name. Compile unit and line indicate where the
- variable was defined. Type descriptor defines the declared type of the
- variable.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="format_common_intrinsics">Debugger intrinsic functions</a>
-</div>
-
-<div class="doc_text">
-
-<p>LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to
- provide debug information at various points in generated code.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_common_declare">llvm.dbg.declare</a>
-</div>
-
-<div class="doc_text">
-<pre>
- void %<a href="#format_common_declare">llvm.dbg.declare</a>( { } *, metadata )
-</pre>
-
-<p>This intrinsic provides information about a local element (ex. variable.) The
- first argument is the alloca for the variable, cast to a <tt>{ }*</tt>. The
- second argument is
- the <tt>%<a href="#format_variables">llvm.dbg.variable</a></tt> containing
- the description of the variable. </p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="format_common_value">llvm.dbg.value</a>
-</div>
-
-<div class="doc_text">
-<pre>
- void %<a href="#format_common_value">llvm.dbg.value</a>( metadata, i64, metadata )
-</pre>
-
-<p>This intrinsic provides information when a user source variable is set to a
- new value. The first argument is the new value (wrapped as metadata). The
- second argument is the offset in the user source variable where the new value
- is written. The third argument is
- the <tt>%<a href="#format_variables">llvm.dbg.variable</a></tt> containing
- the description of the user source variable. </p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="format_common_lifetime">Object lifetimes and scoping</a>
-</div>
-
-<div class="doc_text">
-<p>In many languages, the local variables in functions can have their lifetimes
- or scopes limited to a subset of a function. In the C family of languages,
- for example, variables are only live (readable and writable) within the
- source block that they are defined in. In functional languages, values are
- only readable after they have been defined. Though this is a very obvious
- concept, it is non-trivial to model in LLVM, because it has no notion of
- scoping in this sense, and does not want to be tied to a language's scoping
- rules.</p>
-
-<p>In order to handle this, the LLVM debug format uses the metadata attached to
- llvm instructions to encode line number and scoping information. Consider
- the following C fragment, for example:</p>
-
-<div class="doc_code">
-<pre>
-1. void foo() {
-2. int X = 21;
-3. int Y = 22;
-4. {
-5. int Z = 23;
-6. Z = X;
-7. }
-8. X = Y;
-9. }
-</pre>
-</div>
-
-<p>Compiled to LLVM, this function would be represented like this:</p>
-
-<div class="doc_code">
-<pre>
-define void @foo() nounwind ssp {
-entry:
- %X = alloca i32, align 4 ; <i32*> [#uses=4]
- %Y = alloca i32, align 4 ; <i32*> [#uses=4]
- %Z = alloca i32, align 4 ; <i32*> [#uses=3]
- %0 = bitcast i32* %X to { }* ; <{ }*> [#uses=1]
- call void @llvm.dbg.declare({ }* %0, metadata !0), !dbg !7
- store i32 21, i32* %X, !dbg !8
- %1 = bitcast i32* %Y to { }* ; <{ }*> [#uses=1]
- call void @llvm.dbg.declare({ }* %1, metadata !9), !dbg !10
- store i32 22, i32* %Y, !dbg !11
- %2 = bitcast i32* %Z to { }* ; <{ }*> [#uses=1]
- call void @llvm.dbg.declare({ }* %2, metadata !12), !dbg !14
- store i32 23, i32* %Z, !dbg !15
- %tmp = load i32* %X, !dbg !16 ; <i32> [#uses=1]
- %tmp1 = load i32* %Y, !dbg !16 ; <i32> [#uses=1]
- %add = add nsw i32 %tmp, %tmp1, !dbg !16 ; <i32> [#uses=1]
- store i32 %add, i32* %Z, !dbg !16
- %tmp2 = load i32* %Y, !dbg !17 ; <i32> [#uses=1]
- store i32 %tmp2, i32* %X, !dbg !17
- ret void, !dbg !18
-}
-
-declare void @llvm.dbg.declare({ }*, metadata) nounwind readnone
-
-!0 = metadata !{i32 459008, metadata !1, metadata !"X",
- metadata !3, i32 2, metadata !6}; [ DW_TAG_auto_variable ]
-!1 = metadata !{i32 458763, metadata !2}; [DW_TAG_lexical_block ]
-!2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"foo", metadata !"foo",
- metadata !"foo", metadata !3, i32 1, metadata !4,
- i1 false, i1 true}; [DW_TAG_subprogram ]
-!3 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c",
- metadata !"/private/tmp", metadata !"clang 1.1", i1 true,
- i1 false, metadata !"", i32 0}; [DW_TAG_compile_unit ]
-!4 = metadata !{i32 458773, metadata !3, metadata !"", null, i32 0, i64 0, i64 0,
- i64 0, i32 0, null, metadata !5, i32 0}; [DW_TAG_subroutine_type ]
-!5 = metadata !{null}
-!6 = metadata !{i32 458788, metadata !3, metadata !"int", metadata !3, i32 0,
- i64 32, i64 32, i64 0, i32 0, i32 5}; [DW_TAG_base_type ]
-!7 = metadata !{i32 2, i32 7, metadata !1, null}
-!8 = metadata !{i32 2, i32 3, metadata !1, null}
-!9 = metadata !{i32 459008, metadata !1, metadata !"Y", metadata !3, i32 3,
- metadata !6}; [ DW_TAG_auto_variable ]
-!10 = metadata !{i32 3, i32 7, metadata !1, null}
-!11 = metadata !{i32 3, i32 3, metadata !1, null}
-!12 = metadata !{i32 459008, metadata !13, metadata !"Z", metadata !3, i32 5,
- metadata !6}; [ DW_TAG_auto_variable ]
-!13 = metadata !{i32 458763, metadata !1}; [DW_TAG_lexical_block ]
-!14 = metadata !{i32 5, i32 9, metadata !13, null}
-!15 = metadata !{i32 5, i32 5, metadata !13, null}
-!16 = metadata !{i32 6, i32 5, metadata !13, null}
-!17 = metadata !{i32 8, i32 3, metadata !1, null}
-!18 = metadata !{i32 9, i32 1, metadata !2, null}
-</pre>
-</div>
-
-<p>This example illustrates a few important details about LLVM debugging
- information. In particular, it shows how the <tt>llvm.dbg.declare</tt>
- intrinsic and location information, which are attached to an instruction,
- are applied together to allow a debugger to analyze the relationship between
- statements, variable definitions, and the code used to implement the
- function.</p>
-
-<div class="doc_code">
-<pre>
-call void @llvm.dbg.declare({ }* %0, metadata !0), !dbg !7
-</pre>
-</div>
-
-<p>The first intrinsic
- <tt>%<a href="#format_common_declare">llvm.dbg.declare</a></tt>
- encodes debugging information for the variable <tt>X</tt>. The metadata
- <tt>!dbg !7</tt> attached to the intrinsic provides scope information for the
- variable <tt>X</tt>.</p>
-
-<div class="doc_code">
-<pre>
-!7 = metadata !{i32 2, i32 7, metadata !1, null}
-!1 = metadata !{i32 458763, metadata !2}; [DW_TAG_lexical_block ]
-!2 = metadata !{i32 458798, i32 0, metadata !3, metadata !"foo",
- metadata !"foo", metadata !"foo", metadata !3, i32 1,
- metadata !4, i1 false, i1 true}; [DW_TAG_subprogram ]
-</pre>
-</div>
-
-<p>Here <tt>!7</tt> is metadata providing location information. It has four
- fields: line number, column number, scope, and original scope. The original
- scope represents inline location if this instruction is inlined inside a
- caller, and is null otherwise. In this example, scope is encoded by
- <tt>!1</tt>. <tt>!1</tt> represents a lexical block inside the scope
- <tt>!2</tt>, where <tt>!2</tt> is a
- <a href="#format_subprograms">subprogram descriptor</a>. This way the
- location information attached to the intrinsics indicates that the
- variable <tt>X</tt> is declared at line number 2 at a function level scope in
- function <tt>foo</tt>.</p>
-
-<p>Now lets take another example.</p>
-
-<div class="doc_code">
-<pre>
-call void @llvm.dbg.declare({ }* %2, metadata !12), !dbg !14
-</pre>
-</div>
-
-<p>The second intrinsic
- <tt>%<a href="#format_common_declare">llvm.dbg.declare</a></tt>
- encodes debugging information for variable <tt>Z</tt>. The metadata
- <tt>!dbg !14</tt> attached to the intrinsic provides scope information for
- the variable <tt>Z</tt>.</p>
-
-<div class="doc_code">
-<pre>
-!13 = metadata !{i32 458763, metadata !1}; [DW_TAG_lexical_block ]
-!14 = metadata !{i32 5, i32 9, metadata !13, null}
-</pre>
-</div>
-
-<p>Here <tt>!14</tt> indicates that <tt>Z</tt> is declared at line number 5 and
- column number 9 inside of lexical scope <tt>!13</tt>. The lexical scope
- itself resides inside of lexical scope <tt>!1</tt> described above.</p>
-
-<p>The scope information attached with each instruction provides a
- straightforward way to find instructions covered by a scope.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="ccxx_frontend">C/C++ front-end specific debug information</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>The C and C++ front-ends represent information about the program in a format
- that is effectively identical
- to <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">DWARF 3.0</a> in
- terms of information content. This allows code generators to trivially
- support native debuggers by generating standard dwarf information, and
- contains enough information for non-dwarf targets to translate it as
- needed.</p>
-
-<p>This section describes the forms used to represent C and C++ programs. Other
- languages could pattern themselves after this (which itself is tuned to
- representing programs in the same way that DWARF 3 does), or they could
- choose to provide completely different forms if they don't fit into the DWARF
- model. As support for debugging information gets added to the various LLVM
- source-language front-ends, the information used should be documented
- here.</p>
-
-<p>The following sections provide examples of various C/C++ constructs and the
- debug information that would best describe those constructs.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_compile_units">C/C++ source file information</a>
-</div>
-
-<div class="doc_text">
-
-<p>Given the source files <tt>MySource.cpp</tt> and <tt>MyHeader.h</tt> located
- in the directory <tt>/Users/mine/sources</tt>, the following code:</p>
-
-<div class="doc_code">
-<pre>
-#include "MyHeader.h"
-
-int main(int argc, char *argv[]) {
- return 0;
-}
-</pre>
-</div>
-
-<p>a C/C++ front-end would generate the following descriptors:</p>
-
-<div class="doc_code">
-<pre>
-...
-;;
-;; Define the compile unit for the main source file "/Users/mine/sources/MySource.cpp".
-;;
-!2 = metadata !{
- i32 524305, ;; Tag
- i32 0, ;; Unused
- i32 4, ;; Language Id
- metadata !"MySource.cpp",
- metadata !"/Users/mine/sources",
- metadata !"4.2.1 (Based on Apple Inc. build 5649) (LLVM build 00)",
- i1 true, ;; Main Compile Unit
- i1 false, ;; Optimized compile unit
- metadata !"", ;; Compiler flags
- i32 0} ;; Runtime version
-
-;;
-;; Define the file for the file "/Users/mine/sources/MySource.cpp".
-;;
-!1 = metadata !{
- i32 524329, ;; Tag
- metadata !"MySource.cpp",
- metadata !"/Users/mine/sources",
- metadata !3 ;; Compile unit
-}
-
-;;
-;; Define the file for the file "/Users/mine/sources/Myheader.h"
-;;
-!3 = metadata !{
- i32 524329, ;; Tag
- metadata !"Myheader.h"
- metadata !"/Users/mine/sources",
- metadata !3 ;; Compile unit
-}
-
-...
-</pre>
-</div>
-
-<p>llvm::Instruction provides easy access to metadata attached with an
-instruction. One can extract line number information encoded in LLVM IR
-using <tt>Instruction::getMetadata()</tt> and
-<tt>DILocation::getLineNumber()</tt>.
-<pre>
- if (MDNode *N = I->getMetadata("dbg")) { // Here I is an LLVM instruction
- DILocation Loc(N); // DILocation is in DebugInfo.h
- unsigned Line = Loc.getLineNumber();
- StringRef File = Loc.getFilename();
- StringRef Dir = Loc.getDirectory();
- }
-</pre>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_global_variable">C/C++ global variable information</a>
-</div>
-
-<div class="doc_text">
-
-<p>Given an integer global variable declared as follows:</p>
-
-<div class="doc_code">
-<pre>
-int MyGlobal = 100;
-</pre>
-</div>
-
-<p>a C/C++ front-end would generate the following descriptors:</p>
-
-<div class="doc_code">
-<pre>
-;;
-;; Define the global itself.
-;;
-%MyGlobal = global int 100
-...
-;;
-;; List of debug info of globals
-;;
-!llvm.dbg.gv = !{!0}
-
-;;
-;; Define the global variable descriptor. Note the reference to the global
-;; variable anchor and the global variable itself.
-;;
-!0 = metadata !{
- i32 524340, ;; Tag
- i32 0, ;; Unused
- metadata !1, ;; Context
- metadata !"MyGlobal", ;; Name
- metadata !"MyGlobal", ;; Display Name
- metadata !"MyGlobal", ;; Linkage Name
- metadata !3, ;; Compile Unit
- i32 1, ;; Line Number
- metadata !4, ;; Type
- i1 false, ;; Is a local variable
- i1 true, ;; Is this a definition
- i32* @MyGlobal ;; The global variable
-}
-
-;;
-;; Define the basic type of 32 bit signed integer. Note that since int is an
-;; intrinsic type the source file is NULL and line 0.
-;;
-!4 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"int", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in Bits
- i64 32, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 5 ;; Encoding
-}
-
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_subprogram">C/C++ function information</a>
-</div>
-
-<div class="doc_text">
-
-<p>Given a function declared as follows:</p>
-
-<div class="doc_code">
-<pre>
-int main(int argc, char *argv[]) {
- return 0;
-}
-</pre>
-</div>
-
-<p>a C/C++ front-end would generate the following descriptors:</p>
-
-<div class="doc_code">
-<pre>
-;;
-;; Define the anchor for subprograms. Note that the second field of the
-;; anchor is 46, which is the same as the tag for subprograms
-;; (46 = DW_TAG_subprogram.)
-;;
-!6 = metadata !{
- i32 524334, ;; Tag
- i32 0, ;; Unused
- metadata !1, ;; Context
- metadata !"main", ;; Name
- metadata !"main", ;; Display name
- metadata !"main", ;; Linkage name
- metadata !1, ;; File
- i32 1, ;; Line number
- metadata !4, ;; Type
- i1 false, ;; Is local
- i1 true ;; Is definition
-}
-;;
-;; Define the subprogram itself.
-;;
-define i32 @main(i32 %argc, i8** %argv) {
-...
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_basic_types">C/C++ basic types</a>
-</div>
-
-<div class="doc_text">
-
-<p>The following are the basic type descriptors for C/C++ core types:</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_type_bool">bool</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"bool", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 8, ;; Size in Bits
- i64 8, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 2 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_char">char</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"char", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 8, ;; Size in Bits
- i64 8, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 6 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_unsigned_char">unsigned char</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"unsigned char",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 8, ;; Size in Bits
- i64 8, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 8 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_short">short</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"short int",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 16, ;; Size in Bits
- i64 16, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 5 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_unsigned_short">unsigned short</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"short unsigned int",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 16, ;; Size in Bits
- i64 16, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 7 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_int">int</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"int", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in Bits
- i64 32, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 5 ;; Encoding
-}
-</pre></div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_unsigned_int">unsigned int</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"unsigned int",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in Bits
- i64 32, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 7 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_long_long">long long</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"long long int",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 64, ;; Size in Bits
- i64 64, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 5 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_unsigned_long_long">unsigned long long</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"long long unsigned int",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 64, ;; Size in Bits
- i64 64, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 7 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_float">float</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"float",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in Bits
- i64 32, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 4 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsubsection">
- <a name="ccxx_basic_double">double</a>
-</div>
-
-<div class="doc_text">
-
-<div class="doc_code">
-<pre>
-!2 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"double",;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 64, ;; Size in Bits
- i64 64, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 4 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_derived_types">C/C++ derived types</a>
-</div>
-
-<div class="doc_text">
-
-<p>Given the following as an example of C/C++ derived type:</p>
-
-<div class="doc_code">
-<pre>
-typedef const int *IntPtr;
-</pre>
-</div>
-
-<p>a C/C++ front-end would generate the following descriptors:</p>
-
-<div class="doc_code">
-<pre>
-;;
-;; Define the typedef "IntPtr".
-;;
-!2 = metadata !{
- i32 524310, ;; Tag
- metadata !1, ;; Context
- metadata !"IntPtr", ;; Name
- metadata !3, ;; File
- i32 0, ;; Line number
- i64 0, ;; Size in bits
- i64 0, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- metadata !4 ;; Derived From type
-}
-
-;;
-;; Define the pointer type.
-;;
-!4 = metadata !{
- i32 524303, ;; Tag
- metadata !1, ;; Context
- metadata !"", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 64, ;; Size in bits
- i64 64, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- metadata !5 ;; Derived From type
-}
-;;
-;; Define the const type.
-;;
-!5 = metadata !{
- i32 524326, ;; Tag
- metadata !1, ;; Context
- metadata !"", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in bits
- i64 32, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- metadata !6 ;; Derived From type
-}
-;;
-;; Define the int type.
-;;
-!6 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"int", ;; Name
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in bits
- i64 32, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- 5 ;; Encoding
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_composite_types">C/C++ struct/union types</a>
-</div>
-
-<div class="doc_text">
-
-<p>Given the following as an example of C/C++ struct type:</p>
-
-<div class="doc_code">
-<pre>
-struct Color {
- unsigned Red;
- unsigned Green;
- unsigned Blue;
-};
-</pre>
-</div>
-
-<p>a C/C++ front-end would generate the following descriptors:</p>
-
-<div class="doc_code">
-<pre>
-;;
-;; Define basic type for unsigned int.
-;;
-!5 = metadata !{
- i32 524324, ;; Tag
- metadata !1, ;; Context
- metadata !"unsigned int",
- metadata !1, ;; File
- i32 0, ;; Line number
- i64 32, ;; Size in Bits
- i64 32, ;; Align in Bits
- i64 0, ;; Offset in Bits
- i32 0, ;; Flags
- i32 7 ;; Encoding
-}
-;;
-;; Define composite type for struct Color.
-;;
-!2 = metadata !{
- i32 524307, ;; Tag
- metadata !1, ;; Context
- metadata !"Color", ;; Name
- metadata !1, ;; Compile unit
- i32 1, ;; Line number
- i64 96, ;; Size in bits
- i64 32, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- null, ;; Derived From
- metadata !3, ;; Elements
- i32 0 ;; Runtime Language
-}
-
-;;
-;; Define the Red field.
-;;
-!4 = metadata !{
- i32 524301, ;; Tag
- metadata !1, ;; Context
- metadata !"Red", ;; Name
- metadata !1, ;; File
- i32 2, ;; Line number
- i64 32, ;; Size in bits
- i64 32, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- metadata !5 ;; Derived From type
-}
-
-;;
-;; Define the Green field.
-;;
-!6 = metadata !{
- i32 524301, ;; Tag
- metadata !1, ;; Context
- metadata !"Green", ;; Name
- metadata !1, ;; File
- i32 3, ;; Line number
- i64 32, ;; Size in bits
- i64 32, ;; Align in bits
- i64 32, ;; Offset in bits
- i32 0, ;; Flags
- metadata !5 ;; Derived From type
-}
-
-;;
-;; Define the Blue field.
-;;
-!7 = metadata !{
- i32 524301, ;; Tag
- metadata !1, ;; Context
- metadata !"Blue", ;; Name
- metadata !1, ;; File
- i32 4, ;; Line number
- i64 32, ;; Size in bits
- i64 32, ;; Align in bits
- i64 64, ;; Offset in bits
- i32 0, ;; Flags
- metadata !5 ;; Derived From type
-}
-
-;;
-;; Define the array of fields used by the composite type Color.
-;;
-!3 = metadata !{metadata !4, metadata !6, metadata !7}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="ccxx_enumeration_types">C/C++ enumeration types</a>
-</div>
-
-<div class="doc_text">
-
-<p>Given the following as an example of C/C++ enumeration type:</p>
-
-<div class="doc_code">
-<pre>
-enum Trees {
- Spruce = 100,
- Oak = 200,
- Maple = 300
-};
-</pre>
-</div>
-
-<p>a C/C++ front-end would generate the following descriptors:</p>
-
-<div class="doc_code">
-<pre>
-;;
-;; Define composite type for enum Trees
-;;
-!2 = metadata !{
- i32 524292, ;; Tag
- metadata !1, ;; Context
- metadata !"Trees", ;; Name
- metadata !1, ;; File
- i32 1, ;; Line number
- i64 32, ;; Size in bits
- i64 32, ;; Align in bits
- i64 0, ;; Offset in bits
- i32 0, ;; Flags
- null, ;; Derived From type
- metadata !3, ;; Elements
- i32 0 ;; Runtime language
-}
-
-;;
-;; Define the array of enumerators used by composite type Trees.
-;;
-!3 = metadata !{metadata !4, metadata !5, metadata !6}
-
-;;
-;; Define Spruce enumerator.
-;;
-!4 = metadata !{i32 524328, metadata !"Spruce", i64 100}
-
-;;
-;; Define Oak enumerator.
-;;
-!5 = metadata !{i32 524328, metadata !"Oak", i64 200}
-
-;;
-;; Define Maple enumerator.
-;;
-!6 = metadata !{i32 524328, metadata !"Maple", i64 300}
-
-</pre>
-</div>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
- <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/SystemLibrary.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/SystemLibrary.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/SystemLibrary.html (original)
+++ llvm/trunk/docs/SystemLibrary.html (removed)
@@ -1,319 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>System Library</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">System Library</div>
-<ul>
- <li><a href="#abstract">Abstract</a></li>
- <li><a href="#requirements">Keeping LLVM Portable</a>
- <ol>
- <li><a href="#headers">Don't Include System Headers</a></li>
- <li><a href="#expose">Don't Expose System Headers</a></li>
- <li><a href="#c_headers">Allow Standard C Header Files</a></li>
- <li><a href="#cpp_headers">Allow Standard C++ Header Files</a></li>
- <li><a href="#highlev">High-Level Interface</a></li>
- <li><a href="#nofunc">No Exposed Functions</a></li>
- <li><a href="#nodata">No Exposed Data</a></li>
- <li><a href="#nodupl">No Duplicate Implementations</a></li>
- <li><a href="#nounused">No Unused Functionality</a></li>
- <li><a href="#virtuals">No Virtual Methods</a></li>
- <li><a href="#softerrors">Minimize Soft Errors</a></li>
- <li><a href="#throw_spec">No throw() Specifications</a></li>
- <li><a href="#organization">Code Organization</a></li>
- <li><a href="#semantics">Consistent Semantics</a></li>
- <li><a href="#bug">Tracking Bugzilla Bug: 351</a></li>
- </ol></li>
-</ul>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a></p>
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="abstract">Abstract</a></div>
-<div class="doc_text">
- <p>This document provides some details on LLVM's System Library, located in
- the source at <tt>lib/System</tt> and <tt>include/llvm/System</tt>. The
- library's purpose is to shield LLVM from the differences between operating
- systems for the few services LLVM needs from the operating system. Much of
- LLVM is written using portability features of standard C++. However, in a few
- areas, system dependent facilities are needed and the System Library is the
- wrapper around those system calls.</p>
- <p>By centralizing LLVM's use of operating system interfaces, we make it
- possible for the LLVM tool chain and runtime libraries to be more easily
- ported to new platforms since (theoretically) only <tt>lib/System</tt> needs
- to be ported. This library also unclutters the rest of LLVM from #ifdef use
- and special cases for specific operating systems. Such uses are replaced
- with simple calls to the interfaces provided in <tt>include/llvm/System</tt>.
- </p>
- <p>Note that the System Library is not intended to be a complete operating
- system wrapper (such as the Adaptive Communications Environment (ACE) or
- Apache Portable Runtime (APR)), but only provides the functionality necessary
- to support LLVM.
- <p>The System Library was written by Reid Spencer who formulated the
- design based on similar work originating from the eXtensible Programming
- System (XPS). Several people helped with the effort; especially,
- Jeff Cohen and Henrik Bach on the Win32 port.</p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="requirements">Keeping LLVM Portable</a>
-</div>
-<div class="doc_text">
- <p>In order to keep LLVM portable, LLVM developers should adhere to a set of
- portability rules associated with the System Library. Adherence to these rules
- should help the System Library achieve its goal of shielding LLVM from the
- variations in operating system interfaces and doing so efficiently. The
- following sections define the rules needed to fulfill this objective.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="headers">Don't Include System Headers</a>
-</div>
-<div class="doc_text">
- <p>Except in <tt>lib/System</tt>, no LLVM source code should directly
- <tt>#include</tt> a system header. Care has been taken to remove all such
- <tt>#includes</tt> from LLVM while <tt>lib/System</tt> was being
- developed. Specifically this means that header files like "unistd.h",
- "windows.h", "stdio.h", and "string.h" are forbidden to be included by LLVM
- source code outside the implementation of <tt>lib/System</tt>.</p>
- <p>To obtain system-dependent functionality, existing interfaces to the system
- found in <tt>include/llvm/System</tt> should be used. If an appropriate
- interface is not available, it should be added to <tt>include/llvm/System</tt>
- and implemented in <tt>lib/System</tt> for all supported platforms.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="expose">Don't Expose System Headers</a>
-</div>
-<div class="doc_text">
- <p>The System Library must shield LLVM from <em>all</em> system headers. To
- obtain system level functionality, LLVM source must
- <tt>#include "llvm/System/Thing.h"</tt> and nothing else. This means that
- <tt>Thing.h</tt> cannot expose any system header files. This protects LLVM
- from accidentally using system specific functionality and only allows it
- via the <tt>lib/System</tt> interface.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="c_headers">Use Standard C Headers</a></div>
-<div class="doc_text">
- <p>The <em>standard</em> C headers (the ones beginning with "c") are allowed
- to be exposed through the <tt>lib/System</tt> interface. These headers and
- the things they declare are considered to be platform agnostic. LLVM source
- files may include them directly or obtain their inclusion through
- <tt>lib/System</tt> interfaces.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="cpp_headers">Use Standard C++ Headers</a>
-</div>
-<div class="doc_text">
- <p>The <em>standard</em> C++ headers from the standard C++ library and
- standard template library may be exposed through the <tt>lib/System</tt>
- interface. These headers and the things they declare are considered to be
- platform agnostic. LLVM source files may include them or obtain their
- inclusion through lib/System interfaces.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="highlev">High Level Interface</a></div>
-<div class="doc_text">
- <p>The entry points specified in the interface of lib/System must be aimed at
- completing some reasonably high level task needed by LLVM. We do not want to
- simply wrap each operating system call. It would be preferable to wrap several
- operating system calls that are always used in conjunction with one another by
- LLVM.</p>
- <p>For example, consider what is needed to execute a program, wait for it to
- complete, and return its result code. On Unix, this involves the following
- operating system calls: <tt>getenv, fork, execve,</tt> and <tt>wait</tt>. The
- correct thing for lib/System to provide is a function, say
- <tt>ExecuteProgramAndWait</tt>, that implements the functionality completely.
- what we don't want is wrappers for the operating system calls involved.</p>
- <p>There must <em>not</em> be a one-to-one relationship between operating
- system calls and the System library's interface. Any such interface function
- will be suspicious.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nounused">No Unused Functionality</a></div>
-<div class="doc_text">
- <p>There must be no functionality specified in the interface of lib/System
- that isn't actually used by LLVM. We're not writing a general purpose
- operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM
- doesn't need much. This design goal aims to keep the lib/System interface
- small and understandable which should foster its actual use and adoption.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nodupl">No Duplicate Implementations</a>
-</div>
-<div class="doc_text">
- <p>The implementation of a function for a given platform must be written
- exactly once. This implies that it must be possible to apply a function's
- implementation to multiple operating systems if those operating systems can
- share the same implementation. This rule applies to the set of operating
- systems supported for a given class of operating system (e.g. Unix, Win32).
- </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="virtuals">No Virtual Methods</a></div>
-<div class="doc_text">
- <p>The System Library interfaces can be called quite frequently by LLVM. In
- order to make those calls as efficient as possible, we discourage the use of
- virtual methods. There is no need to use inheritance for implementation
- differences, it just adds complexity. The <tt>#include</tt> mechanism works
- just fine.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nofunc">No Exposed Functions</a></div>
-<div class="doc_text">
- <p>Any functions defined by system libraries (i.e. not defined by lib/System)
- must not be exposed through the lib/System interface, even if the header file
- for that function is not exposed. This prevents inadvertent use of system
- specific functionality.</p>
- <p>For example, the <tt>stat</tt> system call is notorious for having
- variations in the data it provides. <tt>lib/System</tt> must not declare
- <tt>stat</tt> nor allow it to be declared. Instead it should provide its own
- interface to discovering information about files and directories. Those
- interfaces may be implemented in terms of <tt>stat</tt> but that is strictly
- an implementation detail. The interface provided by the System Library must
- be implemented on all platforms (even those without <tt>stat</tt>).</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="nodata">No Exposed Data</a></div>
-<div class="doc_text">
- <p>Any data defined by system libraries (i.e. not defined by lib/System) must
- not be exposed through the lib/System interface, even if the header file for
- that function is not exposed. As with functions, this prevents inadvertent use
- of data that might not exist on all platforms.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="softerrors">Minimize Soft Errors</a></div>
-<div class="doc_text">
- <p>Operating system interfaces will generally provide error results for every
- little thing that could go wrong. In almost all cases, you can divide these
- error results into two groups: normal/good/soft and abnormal/bad/hard. That
- is, some of the errors are simply information like "file not found",
- "insufficient privileges", etc. while other errors are much harder like
- "out of space", "bad disk sector", or "system call interrupted". We'll call
- the first group "<i>soft</i>" errors and the second group "<i>hard</i>"
- errors.<p>
- <p>lib/System must always attempt to minimize soft errors.
- This is a design requirement because the
- minimization of soft errors can affect the granularity and the nature of the
- interface. In general, if you find that you're wanting to throw soft errors,
- you must review the granularity of the interface because it is likely you're
- trying to implement something that is too low level. The rule of thumb is to
- provide interface functions that <em>can't</em> fail, except when faced with
- hard errors.</p>
- <p>For a trivial example, suppose we wanted to add an "OpenFileForWriting"
- function. For many operating systems, if the file doesn't exist, attempting
- to open the file will produce an error. However, lib/System should not
- simply throw that error if it occurs because its a soft error. The problem
- is that the interface function, OpenFileForWriting is too low level. It should
- be OpenOrCreateFileForWriting. In the case of the soft "doesn't exist" error,
- this function would just create it and then open it for writing.</p>
- <p>This design principle needs to be maintained in lib/System because it
- avoids the propagation of soft error handling throughout the rest of LLVM.
- Hard errors will generally just cause a termination for an LLVM tool so don't
- be bashful about throwing them.</p>
- <p>Rules of thumb:</p>
- <ol>
- <li>Don't throw soft errors, only hard errors.</li>
- <li>If you're tempted to throw a soft error, re-think the interface.</li>
- <li>Handle internally the most common normal/good/soft error conditions
- so the rest of LLVM doesn't have to.</li>
- </ol>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="throw_spec">No throw Specifications</a>
-</div>
-<div class="doc_text">
- <p>None of the lib/System interface functions may be declared with C++
- <tt>throw()</tt> specifications on them. This requirement makes sure that the
- compiler does not insert additional exception handling code into the interface
- functions. This is a performance consideration: lib/System functions are at
- the bottom of many call chains and as such can be frequently called. We
- need them to be as efficient as possible. However, no routines in the
- system library should actually throw exceptions.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="organization">Code Organization</a></div>
-<div class="doc_text">
- <p>Implementations of the System Library interface are separated by their
- general class of operating system. Currently only Unix and Win32 classes are
- defined but more could be added for other operating system classifications.
- To distinguish which implementation to compile, the code in lib/System uses
- the LLVM_ON_UNIX and LLVM_ON_WIN32 #defines provided via configure through the
- llvm/Config/config.h file. Each source file in lib/System, after implementing
- the generic (operating system independent) functionality needs to include the
- correct implementation using a set of <tt>#if defined(LLVM_ON_XYZ)</tt>
- directives. For example, if we had lib/System/File.cpp, we'd expect to see in
- that file:</p>
- <pre><tt>
- #if defined(LLVM_ON_UNIX)
- #include "Unix/File.cpp"
- #endif
- #if defined(LLVM_ON_WIN32)
- #include "Win32/File.cpp"
- #endif
- </tt></pre>
- <p>The implementation in lib/System/Unix/File.cpp should handle all Unix
- variants. The implementation in lib/System/Win32/File.cpp should handle all
- Win32 variants. What this does is quickly differentiate the basic class of
- operating system that will provide the implementation. The specific details
- for a given platform must still be determined through the use of
- <tt>#ifdef</tt>.</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="semantics">Consistent Semantics</a></div>
-<div class="doc_text">
- <p>The implementation of a lib/System interface can vary drastically between
- platforms. That's okay as long as the end result of the interface function
- is the same. For example, a function to create a directory is pretty straight
- forward on all operating system. System V IPC on the other hand isn't even
- supported on all platforms. Instead of "supporting" System V IPC, lib/System
- should provide an interface to the basic concept of inter-process
- communications. The implementations might use System V IPC if that was
- available or named pipes, or whatever gets the job done effectively for a
- given operating system. In all cases, the interface and the implementation
- must be semantically consistent. </p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="bug">Bug 351</a></div>
-<div class="doc_text">
- <p>See <a href="http://llvm.org/PR351">bug 351</a>
- for further details on the progress of this work</p>
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:rspencer at x10sys.com">Reid Spencer</a><br>
- <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-</body>
-</html>
Removed: llvm/trunk/docs/TableGenFundamentals.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/TableGenFundamentals.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/TableGenFundamentals.html (original)
+++ llvm/trunk/docs/TableGenFundamentals.html (removed)
@@ -1,802 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>TableGen Fundamentals</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">TableGen Fundamentals</div>
-
-<div class="doc_text">
-<ul>
- <li><a href="#introduction">Introduction</a>
- <ol>
- <li><a href="#concepts">Basic concepts</a></li>
- <li><a href="#example">An example record</a></li>
- <li><a href="#running">Running TableGen</a></li>
- </ol></li>
- <li><a href="#syntax">TableGen syntax</a>
- <ol>
- <li><a href="#primitives">TableGen primitives</a>
- <ol>
- <li><a href="#comments">TableGen comments</a></li>
- <li><a href="#types">The TableGen type system</a></li>
- <li><a href="#values">TableGen values and expressions</a></li>
- </ol></li>
- <li><a href="#classesdefs">Classes and definitions</a>
- <ol>
- <li><a href="#valuedef">Value definitions</a></li>
- <li><a href="#recordlet">'let' expressions</a></li>
- <li><a href="#templateargs">Class template arguments</a></li>
- <li><a href="#multiclass">Multiclass definitions and instances</a></li>
- </ol></li>
- <li><a href="#filescope">File scope entities</a>
- <ol>
- <li><a href="#include">File inclusion</a></li>
- <li><a href="#globallet">'let' expressions</a></li>
- </ol></li>
- </ol></li>
- <li><a href="#backends">TableGen backends</a>
- <ol>
- <li><a href="#">todo</a></li>
- </ol></li>
-</ul>
-</div>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="introduction">Introduction</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>TableGen's purpose is to help a human develop and maintain records of
-domain-specific information. Because there may be a large number of these
-records, it is specifically designed to allow writing flexible descriptions and
-for common features of these records to be factored out. This reduces the
-amount of duplication in the description, reduces the chance of error, and
-makes it easier to structure domain specific information.</p>
-
-<p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
-the declarations, and hands the result off to a domain-specific "<a
-href="#backends">TableGen backend</a>" for processing. The current major user
-of TableGen is the <a href="CodeGenerator.html">LLVM code generator</a>.</p>
-
-<p>Note that if you work on TableGen much, and use emacs or vim, that you can
-find an emacs "TableGen mode" and a vim language file in the
-<tt>llvm/utils/emacs</tt> and <tt>llvm/utils/vim</tt> directories of your LLVM
-distribution, respectively.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="concepts">Basic concepts</a></div>
-
-<div class="doc_text">
-
-<p>TableGen files consist of two key parts: 'classes' and 'definitions', both
-of which are considered 'records'.</p>
-
-<p><b>TableGen records</b> have a unique name, a list of values, and a list of
-superclasses. The list of values is the main data that TableGen builds for each
-record; it is this that holds the domain specific information for the
-application. The interpretation of this data is left to a specific <a
-href="#backends">TableGen backend</a>, but the structure and format rules are
-taken care of and are fixed by TableGen.</p>
-
-<p><b>TableGen definitions</b> are the concrete form of 'records'. These
-generally do not have any undefined values, and are marked with the
-'<tt>def</tt>' keyword.</p>
-
-<p><b>TableGen classes</b> are abstract records that are used to build and
-describe other records. These 'classes' allow the end-user to build
-abstractions for either the domain they are targeting (such as "Register",
-"RegisterClass", and "Instruction" in the LLVM code generator) or for the
-implementor to help factor out common properties of records (such as "FPInst",
-which is used to represent floating point instructions in the X86 backend).
-TableGen keeps track of all of the classes that are used to build up a
-definition, so the backend can find all definitions of a particular class, such
-as "Instruction".</p>
-
-<p><b>TableGen multiclasses</b> are groups of abstract records that are
-instantiated all at once. Each instantiation can result in multiple
-TableGen definitions. If a multiclass inherits from another multiclass,
-the definitions in the sub-multiclass become part of the current
-multiclass, as if they were declared in the current multiclass.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="example">An example record</a></div>
-
-<div class="doc_text">
-
-<p>With no other arguments, TableGen parses the specified file and prints out
-all of the classes, then all of the definitions. This is a good way to see what
-the various definitions expand to fully. Running this on the <tt>X86.td</tt>
-file prints this (at the time of this writing):</p>
-
-<div class="doc_code">
-<pre>
-...
-<b>def</b> ADD32rr { <i>// Instruction X86Inst I</i>
- <b>string</b> Namespace = "X86";
- <b>dag</b> OutOperandList = (outs GR32:$dst);
- <b>dag</b> InOperandList = (ins GR32:$src1, GR32:$src2);
- <b>string</b> AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
- <b>list</b><dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
- <b>list</b><Register> Uses = [];
- <b>list</b><Register> Defs = [EFLAGS];
- <b>list</b><Predicate> Predicates = [];
- <b>int</b> CodeSize = 3;
- <b>int</b> AddedComplexity = 0;
- <b>bit</b> isReturn = 0;
- <b>bit</b> isBranch = 0;
- <b>bit</b> isIndirectBranch = 0;
- <b>bit</b> isBarrier = 0;
- <b>bit</b> isCall = 0;
- <b>bit</b> canFoldAsLoad = 0;
- <b>bit</b> mayLoad = 0;
- <b>bit</b> mayStore = 0;
- <b>bit</b> isImplicitDef = 0;
- <b>bit</b> isTwoAddress = 1;
- <b>bit</b> isConvertibleToThreeAddress = 1;
- <b>bit</b> isCommutable = 1;
- <b>bit</b> isTerminator = 0;
- <b>bit</b> isReMaterializable = 0;
- <b>bit</b> isPredicable = 0;
- <b>bit</b> hasDelaySlot = 0;
- <b>bit</b> usesCustomInserter = 0;
- <b>bit</b> hasCtrlDep = 0;
- <b>bit</b> isNotDuplicable = 0;
- <b>bit</b> hasSideEffects = 0;
- <b>bit</b> neverHasSideEffects = 0;
- InstrItinClass Itinerary = NoItinerary;
- <b>string</b> Constraints = "";
- <b>string</b> DisableEncoding = "";
- <b>bits</b><8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
- Format Form = MRMDestReg;
- <b>bits</b><6> FormBits = { 0, 0, 0, 0, 1, 1 };
- ImmType ImmT = NoImm;
- <b>bits</b><3> ImmTypeBits = { 0, 0, 0 };
- <b>bit</b> hasOpSizePrefix = 0;
- <b>bit</b> hasAdSizePrefix = 0;
- <b>bits</b><4> Prefix = { 0, 0, 0, 0 };
- <b>bit</b> hasREX_WPrefix = 0;
- FPFormat FPForm = ?;
- <b>bits</b><3> FPFormBits = { 0, 0, 0 };
-}
-...
-</pre>
-</div>
-
-<p>This definition corresponds to a 32-bit register-register add instruction in
-the X86. The string after the '<tt>def</tt>' string indicates the name of the
-record—"<tt>ADD32rr</tt>" in this case—and the comment at the end of
-the line indicates the superclasses of the definition. The body of the record
-contains all of the data that TableGen assembled for the record, indicating that
-the instruction is part of the "X86" namespace, the pattern indicating how the
-the instruction should be emitted into the assembly file, that it is a
-two-address instruction, has a particular encoding, etc. The contents and
-semantics of the information in the record is specific to the needs of the X86
-backend, and is only shown as an example.</p>
-
-<p>As you can see, a lot of information is needed for every instruction
-supported by the code generator, and specifying it all manually would be
-unmaintainable, prone to bugs, and tiring to do in the first place. Because we
-are using TableGen, all of the information was derived from the following
-definition:</p>
-
-<div class="doc_code">
-<pre>
-let Defs = [EFLAGS],
- isCommutable = 1, <i>// X = ADD Y,Z --> X = ADD Z,Y</i>
- isConvertibleToThreeAddress = 1 <b>in</b> <i>// Can transform into LEA.</i>
-def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst),
- (ins GR32:$src1, GR32:$src2),
- "add{l}\t{$src2, $dst|$dst, $src2}",
- [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
-</pre>
-</div>
-
-<p>This definition makes use of the custom class <tt>I</tt> (extended from the
-custom class <tt>X86Inst</tt>), which is defined in the X86-specific TableGen
-file, to factor out the common features that instructions of its class share. A
-key feature of TableGen is that it allows the end-user to define the
-abstractions they prefer to use when describing their information.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="running">Running TableGen</a></div>
-
-<div class="doc_text">
-
-<p>TableGen runs just like any other LLVM tool. The first (optional) argument
-specifies the file to read. If a filename is not specified, <tt>tblgen</tt>
-reads from standard input.</p>
-
-<p>To be useful, one of the <a href="#backends">TableGen backends</a> must be
-used. These backends are selectable on the command line (type '<tt>tblgen
--help</tt>' for a list). For example, to get a list of all of the definitions
-that subclass a particular type (which can be useful for building up an enum
-list of these records), use the <tt>-print-enums</tt> option:</p>
-
-<div class="doc_code">
-<pre>
-$ tblgen X86.td -print-enums -class=Register
-AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
-ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
-MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
-R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
-R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
-RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
-XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
-XMM6, XMM7, XMM8, XMM9,
-
-$ tblgen X86.td -print-enums -class=Instruction
-ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
-ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
-ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
-ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
-ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
-</pre>
-</div>
-
-<p>The default backend prints out all of the records, as described <a
-href="#example">above</a>.</p>
-
-<p>If you plan to use TableGen, you will most likely have to <a
-href="#backends">write a backend</a> that extracts the information specific to
-what you need and formats it in the appropriate way.</p>
-
-</div>
-
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="syntax">TableGen syntax</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>TableGen doesn't care about the meaning of data (that is up to the backend to
-define), but it does care about syntax, and it enforces a simple type system.
-This section describes the syntax and the constructs allowed in a TableGen file.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="primitives">TableGen primitives</a></div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection"><a name="comments">TableGen comments</a></div>
-
-<div class="doc_text">
-
-<p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
-the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="types">The TableGen type system</a>
-</div>
-
-<div class="doc_text">
-
-<p>TableGen files are strongly typed, in a simple (but complete) type-system.
-These types are used to perform automatic conversions, check for errors, and to
-help interface designers constrain the input that they allow. Every <a
-href="#valuedef">value definition</a> is required to have an associated type.
-</p>
-
-<p>TableGen supports a mixture of very low-level types (such as <tt>bit</tt>)
-and very high-level types (such as <tt>dag</tt>). This flexibility is what
-allows it to describe a wide range of information conveniently and compactly.
-The TableGen types are:</p>
-
-<dl>
-<dt><tt><b>bit</b></tt></dt>
- <dd>A 'bit' is a boolean value that can hold either 0 or 1.</dd>
-
-<dt><tt><b>int</b></tt></dt>
- <dd>The 'int' type represents a simple 32-bit integer value, such as 5.</dd>
-
-<dt><tt><b>string</b></tt></dt>
- <dd>The 'string' type represents an ordered sequence of characters of
- arbitrary length.</dd>
-
-<dt><tt><b>bits</b><n></tt></dt>
- <dd>A 'bits' type is an arbitrary, but fixed, size integer that is broken up
- into individual bits. This type is useful because it can handle some bits
- being defined while others are undefined.</dd>
-
-<dt><tt><b>list</b><ty></tt></dt>
- <dd>This type represents a list whose elements are some other type. The
- contained type is arbitrary: it can even be another list type.</dd>
-
-<dt>Class type</dt>
- <dd>Specifying a class name in a type context means that the defined value
- must be a subclass of the specified class. This is useful in conjunction with
- the <b><tt>list</tt></b> type, for example, to constrain the elements of the
- list to a common base class (e.g., a <tt><b>list</b><Register></tt> can
- only contain definitions derived from the "<tt>Register</tt>" class).</dd>
-
-<dt><tt><b>dag</b></tt></dt>
- <dd>This type represents a nestable directed graph of elements.</dd>
-
-<dt><tt><b>code</b></tt></dt>
- <dd>This represents a big hunk of text. This is lexically distinct from
- string values because it doesn't require escapeing double quotes and other
- common characters that occur in code.</dd>
-</dl>
-
-<p>To date, these types have been sufficient for describing things that
-TableGen has been used for, but it is straight-forward to extend this list if
-needed.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="values">TableGen values and expressions</a>
-</div>
-
-<div class="doc_text">
-
-<p>TableGen allows for a pretty reasonable number of different expression forms
-when building up values. These forms allow the TableGen file to be written in a
-natural syntax and flavor for the application. The current expression forms
-supported include:</p>
-
-<dl>
-<dt><tt>?</tt></dt>
- <dd>uninitialized field</dd>
-<dt><tt>0b1001011</tt></dt>
- <dd>binary integer value</dd>
-<dt><tt>07654321</tt></dt>
- <dd>octal integer value (indicated by a leading 0)</dd>
-<dt><tt>7</tt></dt>
- <dd>decimal integer value</dd>
-<dt><tt>0x7F</tt></dt>
- <dd>hexadecimal integer value</dd>
-<dt><tt>"foo"</tt></dt>
- <dd>string value</dd>
-<dt><tt>[{ ... }]</tt></dt>
- <dd>code fragment</dd>
-<dt><tt>[ X, Y, Z ]<type></tt></dt>
- <dd>list value. <type> is the type of the list
-element and is usually optional. In rare cases,
-TableGen is unable to deduce the element type in
-which case the user must specify it explicitly.</dd>
-<dt><tt>{ a, b, c }</tt></dt>
- <dd>initializer for a "bits<3>" value</dd>
-<dt><tt>value</tt></dt>
- <dd>value reference</dd>
-<dt><tt>value{17}</tt></dt>
- <dd>access to one bit of a value</dd>
-<dt><tt>value{15-17}</tt></dt>
- <dd>access to multiple bits of a value</dd>
-<dt><tt>DEF</tt></dt>
- <dd>reference to a record definition</dd>
-<dt><tt>CLASS<val list></tt></dt>
- <dd>reference to a new anonymous definition of CLASS with the specified
- template arguments.</dd>
-<dt><tt>X.Y</tt></dt>
- <dd>reference to the subfield of a value</dd>
-<dt><tt>list[4-7,17,2-3]</tt></dt>
- <dd>A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from
- it. Elements may be included multiple times.</dd>
-<dt><tt>(DEF a, b)</tt></dt>
- <dd>a dag value. The first element is required to be a record definition, the
- remaining elements in the list may be arbitrary other values, including nested
- `<tt>dag</tt>' values.</dd>
-<dt><tt>!strconcat(a, b)</tt></dt>
- <dd>A string value that is the result of concatenating the 'a' and 'b'
- strings.</dd>
-<dt><tt>!cast<type>(a)</tt></dt>
- <dd>A symbol of type <em>type</em> obtained by looking up the string 'a' in
-the symbol table. If the type of 'a' does not match <em>type</em>, TableGen
-aborts with an error. !cast<string> is a special case in that the argument must
-be an object defined by a 'def' construct.</dd>
-<dt><tt>!nameconcat<type>(a, b)</tt></dt>
- <dd>Shorthand for !cast<type>(!strconcat(a, b))</dd>
-<dt><tt>!subst(a, b, c)</tt></dt>
- <dd>If 'a' and 'b' are of string type or are symbol references, substitute
-'b' for 'a' in 'c.' This operation is analogous to $(subst) in GNU make.</dd>
-<dt><tt>!foreach(a, b, c)</tt></dt>
- <dd>For each member 'b' of dag or list 'a' apply operator 'c.' 'b' is a
-dummy variable that should be declared as a member variable of an instantiated
-class. This operation is analogous to $(foreach) in GNU make.</dd>
-<dt><tt>!car(a)</tt></dt>
- <dd>The first element of list 'a.'</dd>
-<dt><tt>!cdr(a)</tt></dt>
- <dd>The 2nd-N elements of list 'a.'</dd>
-<dt><tt>!null(a)</tt></dt>
- <dd>An integer {0,1} indicating whether list 'a' is empty.</dd>
-<dt><tt>!if(a,b,c)</tt></dt>
- <dd>'b' if the result of integer operator 'a' is nonzero, 'c' otherwise.</dd>
-<dt><tt>!eq(a,b)</tt></dt>
- <dd>Integer one if string a is equal to string b, zero otherwise. This
- only operates on string objects. Use !cast<string> to compare other
- types of objects.</dd>
-</dl>
-
-<p>Note that all of the values have rules specifying how they convert to values
-for different types. These rules allow you to assign a value like "<tt>7</tt>"
-to a "<tt>bits<4></tt>" value, for example.</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="classesdefs">Classes and definitions</a>
-</div>
-
-<div class="doc_text">
-
-<p>As mentioned in the <a href="#concepts">intro</a>, classes and definitions
-(collectively known as 'records') in TableGen are the main high-level unit of
-information that TableGen collects. Records are defined with a <tt>def</tt> or
-<tt>class</tt> keyword, the record name, and an optional list of "<a
-href="#templateargs">template arguments</a>". If the record has superclasses,
-they are specified as a comma separated list that starts with a colon character
-("<tt>:</tt>"). If <a href="#valuedef">value definitions</a> or <a
-href="#recordlet">let expressions</a> are needed for the class, they are
-enclosed in curly braces ("<tt>{}</tt>"); otherwise, the record ends with a
-semicolon.</p>
-
-<p>Here is a simple TableGen file:</p>
-
-<div class="doc_code">
-<pre>
-<b>class</b> C { <b>bit</b> V = 1; }
-<b>def</b> X : C;
-<b>def</b> Y : C {
- <b>string</b> Greeting = "hello";
-}
-</pre>
-</div>
-
-<p>This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of
-which derive from the <tt>C</tt> class. Because of this, they both get the
-<tt>V</tt> bit value. The <tt>Y</tt> definition also gets the Greeting member
-as well.</p>
-
-<p>In general, classes are useful for collecting together the commonality
-between a group of records and isolating it in a single place. Also, classes
-permit the specification of default values for their subclasses, allowing the
-subclasses to override them as they wish.</p>
-
-</div>
-
-<!---------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="valuedef">Value definitions</a>
-</div>
-
-<div class="doc_text">
-
-<p>Value definitions define named entries in records. A value must be defined
-before it can be referred to as the operand for another value definition or
-before the value is reset with a <a href="#recordlet">let expression</a>. A
-value is defined by specifying a <a href="#types">TableGen type</a> and a name.
-If an initial value is available, it may be specified after the type with an
-equal sign. Value definitions require terminating semicolons.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="recordlet">'let' expressions</a>
-</div>
-
-<div class="doc_text">
-
-<p>A record-level let expression is used to change the value of a value
-definition in a record. This is primarily useful when a superclass defines a
-value that a derived class or definition wants to override. Let expressions
-consist of the '<tt>let</tt>' keyword followed by a value name, an equal sign
-("<tt>=</tt>"), and a new value. For example, a new class could be added to the
-example above, redefining the <tt>V</tt> field for all of its subclasses:</p>
-
-<div class="doc_code">
-<pre>
-<b>class</b> D : C { let V = 0; }
-<b>def</b> Z : D;
-</pre>
-</div>
-
-<p>In this case, the <tt>Z</tt> definition will have a zero value for its "V"
-value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
-because the <tt>D</tt> class overrode its value.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="templateargs">Class template arguments</a>
-</div>
-
-<div class="doc_text">
-
-<p>TableGen permits the definition of parameterized classes as well as normal
-concrete classes. Parameterized TableGen classes specify a list of variable
-bindings (which may optionally have defaults) that are bound when used. Here is
-a simple example:</p>
-
-<div class="doc_code">
-<pre>
-<b>class</b> FPFormat<<b>bits</b><3> val> {
- <b>bits</b><3> Value = val;
-}
-<b>def</b> NotFP : FPFormat<0>;
-<b>def</b> ZeroArgFP : FPFormat<1>;
-<b>def</b> OneArgFP : FPFormat<2>;
-<b>def</b> OneArgFPRW : FPFormat<3>;
-<b>def</b> TwoArgFP : FPFormat<4>;
-<b>def</b> CompareFP : FPFormat<5>;
-<b>def</b> CondMovFP : FPFormat<6>;
-<b>def</b> SpecialFP : FPFormat<7>;
-</pre>
-</div>
-
-<p>In this case, template arguments are used as a space efficient way to specify
-a list of "enumeration values", each with a "<tt>Value</tt>" field set to the
-specified integer.</p>
-
-<p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
-useful in conjunction with template arguments. As an example:</p>
-
-<div class="doc_code">
-<pre>
-<b>class</b> ModRefVal<<b>bits</b><2> val> {
- <b>bits</b><2> Value = val;
-}
-
-<b>def</b> None : ModRefVal<0>;
-<b>def</b> Mod : ModRefVal<1>;
-<b>def</b> Ref : ModRefVal<2>;
-<b>def</b> ModRef : ModRefVal<3>;
-
-<b>class</b> Value<ModRefVal MR> {
- <i>// Decode some information into a more convenient format, while providing
- // a nice interface to the user of the "Value" class.</i>
- <b>bit</b> isMod = MR.Value{0};
- <b>bit</b> isRef = MR.Value{1};
-
- <i>// other stuff...</i>
-}
-
-<i>// Example uses</i>
-<b>def</b> bork : Value<Mod>;
-<b>def</b> zork : Value<Ref>;
-<b>def</b> hork : Value<ModRef>;
-</pre>
-</div>
-
-<p>This is obviously a contrived example, but it shows how template arguments
-can be used to decouple the interface provided to the user of the class from the
-actual internal data representation expected by the class. In this case,
-running <tt>tblgen</tt> on the example prints the following definitions:</p>
-
-<div class="doc_code">
-<pre>
-<b>def</b> bork { <i>// Value</i>
- <b>bit</b> isMod = 1;
- <b>bit</b> isRef = 0;
-}
-<b>def</b> hork { <i>// Value</i>
- <b>bit</b> isMod = 1;
- <b>bit</b> isRef = 1;
-}
-<b>def</b> zork { <i>// Value</i>
- <b>bit</b> isMod = 0;
- <b>bit</b> isRef = 1;
-}
-</pre>
-</div>
-
-<p> This shows that TableGen was able to dig into the argument and extract a
-piece of information that was requested by the designer of the "Value" class.
-For more realistic examples, please see existing users of TableGen, such as the
-X86 backend.</p>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="multiclass">Multiclass definitions and instances</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-While classes with template arguments are a good way to factor commonality
-between two instances of a definition, multiclasses allow a convenient notation
-for defining multiple definitions at once (instances of implicitly constructed
-classes). For example, consider an 3-address instruction set whose instructions
-come in two forms: "<tt>reg = reg op reg</tt>" and "<tt>reg = reg op imm</tt>"
-(e.g. SPARC). In this case, you'd like to specify in one place that this
-commonality exists, then in a separate place indicate what all the ops are.
-</p>
-
-<p>
-Here is an example TableGen fragment that shows this idea:
-</p>
-
-<div class="doc_code">
-<pre>
-<b>def</b> ops;
-<b>def</b> GPR;
-<b>def</b> Imm;
-<b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
-
-<b>multiclass</b> ri_inst<<b>int</b> opc, <b>string</b> asmstr> {
- def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
- (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
- def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
- (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
-}
-
-<i>// Instantiations of the ri_inst multiclass.</i>
-<b>defm</b> ADD : ri_inst<0b111, "add">;
-<b>defm</b> SUB : ri_inst<0b101, "sub">;
-<b>defm</b> MUL : ri_inst<0b100, "mul">;
-...
-</pre>
-</div>
-
-<p>The name of the resultant definitions has the multidef fragment names
- appended to them, so this defines <tt>ADD_rr</tt>, <tt>ADD_ri</tt>,
- <tt>SUB_rr</tt>, etc. A defm may inherit from multiple multiclasses,
- instantiating definitions from each multiclass. Using a multiclass
- this way is exactly equivalent to instantiating the classes multiple
- times yourself, e.g. by writing:</p>
-
-<div class="doc_code">
-<pre>
-<b>def</b> ops;
-<b>def</b> GPR;
-<b>def</b> Imm;
-<b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
-
-<b>class</b> rrinst<<b>int</b> opc, <b>string</b> asmstr>
- : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
- (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
-
-<b>class</b> riinst<<b>int</b> opc, <b>string</b> asmstr>
- : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
- (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
-
-<i>// Instantiations of the ri_inst multiclass.</i>
-<b>def</b> ADD_rr : rrinst<0b111, "add">;
-<b>def</b> ADD_ri : riinst<0b111, "add">;
-<b>def</b> SUB_rr : rrinst<0b101, "sub">;
-<b>def</b> SUB_ri : riinst<0b101, "sub">;
-<b>def</b> MUL_rr : rrinst<0b100, "mul">;
-<b>def</b> MUL_ri : riinst<0b100, "mul">;
-...
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="filescope">File scope entities</a>
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="include">File inclusion</a>
-</div>
-
-<div class="doc_text">
-<p>TableGen supports the '<tt>include</tt>' token, which textually substitutes
-the specified file in place of the include directive. The filename should be
-specified as a double quoted string immediately after the '<tt>include</tt>'
-keyword. Example:</p>
-
-<div class="doc_code">
-<pre>
-<b>include</b> "foo.td"
-</pre>
-</div>
-
-</div>
-
-<!-- -------------------------------------------------------------------------->
-<div class="doc_subsubsection">
- <a name="globallet">'let' expressions</a>
-</div>
-
-<div class="doc_text">
-
-<p>"Let" expressions at file scope are similar to <a href="#recordlet">"let"
-expressions within a record</a>, except they can specify a value binding for
-multiple records at a time, and may be useful in certain other cases.
-File-scope let expressions are really just another way that TableGen allows the
-end-user to factor out commonality from the records.</p>
-
-<p>File-scope "let" expressions take a comma-separated list of bindings to
-apply, and one or more records to bind the values in. Here are some
-examples:</p>
-
-<div class="doc_code">
-<pre>
-<b>let</b> isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 <b>in</b>
- <b>def</b> RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
-
-<b>let</b> isCall = 1 <b>in</b>
- <i>// All calls clobber the non-callee saved registers...</i>
- <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
- MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
- XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] <b>in</b> {
- <b>def</b> CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
- "call\t${dst:call}", []>;
- <b>def</b> CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
- "call\t{*}$dst", [(X86call GR32:$dst)]>;
- <b>def</b> CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
- "call\t{*}$dst", []>;
- }
-</pre>
-</div>
-
-<p>File-scope "let" expressions are often useful when a couple of definitions
-need to be added to several records, and the records do not otherwise need to be
-opened, as in the case with the <tt>CALL*</tt> instructions above.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="codegen">Code Generator backend info</a></div>
-<!-- *********************************************************************** -->
-
-<p>Expressions used by code generator to describe instructions and isel
-patterns:</p>
-
-<div class="doc_text">
-
-<dt><tt>(implicit a)</tt></dt>
- <dd>an implicitly defined physical register. This tells the dag instruction
- selection emitter the input pattern's extra definitions matches implicit
- physical register definitions.</dd>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section"><a name="backends">TableGen backends</a></div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>TODO: How they work, how to write one. This section should not contain
-details about any particular backend, except maybe -print-enums as an example.
-This should highlight the APIs in <tt>TableGen/Record.h</tt>.</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
- <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
Removed: llvm/trunk/docs/TestingGuide.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/TestingGuide.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/TestingGuide.html (original)
+++ llvm/trunk/docs/TestingGuide.html (removed)
@@ -1,1212 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>LLVM Testing Infrastructure Guide</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-
-<div class="doc_title">
- LLVM Testing Infrastructure Guide
-</div>
-
-<ol>
- <li><a href="#overview">Overview</a></li>
- <li><a href="#requirements">Requirements</a></li>
- <li><a href="#org">LLVM testing infrastructure organization</a>
- <ul>
- <li><a href="#dejagnu">DejaGNU tests</a></li>
- <li><a href="#testsuite">Test suite</a></li>
- </ul>
- </li>
- <li><a href="#quick">Quick start</a>
- <ul>
- <li><a href="#quickdejagnu">DejaGNU tests</a></li>
- <li><a href="#quicktestsuite">Test suite</a></li>
- </ul>
- </li>
- <li><a href="#dgstructure">DejaGNU structure</a>
- <ul>
- <li><a href="#dgcustom">Writing new DejaGNU tests</a></li>
- <li><a href="#FileCheck">The FileCheck utility</a></li>
- <li><a href="#dgvars">Variables and substitutions</a></li>
- <li><a href="#dgfeatures">Other features</a></li>
- </ul>
- </li>
- <li><a href="#testsuitestructure">Test suite structure</a></li>
- <li><a href="#testsuiterun">Running the test suite</a>
- <ul>
- <li><a href="#testsuiteexternal">Configuring External Tests</a></li>
- <li><a href="#testsuitetests">Running different tests</a></li>
- <li><a href="#testsuiteoutput">Generating test output</a></li>
- <li><a href="#testsuitecustom">Writing custom tests for llvm-test</a></li>
- </ul>
- </li>
- <li><a href="#nightly">Running the nightly tester</a></li>
-</ol>
-
-<div class="doc_author">
- <p>Written by John T. Criswell, <a
- href="http://llvm.x10sys.com/rspencer">Reid Spencer</a>, and Tanya Lattner</p>
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="overview">Overview</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
-<p>This document is the reference manual for the LLVM testing infrastructure. It documents
-the structure of the LLVM testing infrastructure, the tools needed to use it,
-and how to add and run tests.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="requirements">Requirements</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
-<p>In order to use the LLVM testing infrastructure, you will need all of the software
-required to build LLVM, plus the following:</p>
-
-<dl>
-<dt><a href="http://www.gnu.org/software/dejagnu/">DejaGNU</a></dt>
-<dd>The Feature and Regressions tests are organized and run by DejaGNU.</dd>
-<dt><a href="http://expect.nist.gov/">Expect</a></dt>
-<dd>Expect is required by DejaGNU.</dd>
-<dt><a href="http://www.tcl.tk/software/tcltk/">tcl</a></dt>
-<dd>Tcl is required by DejaGNU. </dd>
-</dl>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="org">LLVM testing infrastructure organization</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
-<p>The LLVM testing infrastructure contains two major categories of tests: code
-fragments and whole programs. Code fragments are referred to as the "DejaGNU
-tests" and are in the <tt>llvm</tt> module in subversion under the
-<tt>llvm/test</tt> directory. The whole programs tests are referred to as the
-"Test suite" and are in the <tt>test-suite</tt> module in subversion.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="dejagnu">DejaGNU tests</a></div>
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_text">
-
-<p>Code fragments are small pieces of code that test a specific
-feature of LLVM or trigger a specific bug in LLVM. They are usually
-written in LLVM assembly language, but can be written in other
-languages if the test targets a particular language front end (and the
-appropriate <tt>--with-llvmgcc</tt> options were used
-at <tt>configure</tt> time of the <tt>llvm</tt> module). These tests
-are driven by the DejaGNU testing framework, which is hidden behind a
-few simple makefiles.</p>
-
-<p>These code fragments are not complete programs. The code generated
-from them is never executed to determine correct behavior.</p>
-
-<p>These code fragment tests are located in the <tt>llvm/test</tt>
-directory.</p>
-
-<p>Typically when a bug is found in LLVM, a regression test containing
-just enough code to reproduce the problem should be written and placed
-somewhere underneath this directory. In most cases, this will be a small
-piece of LLVM assembly language code, often distilled from an actual
-application or benchmark.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="testsuite">Test suite</a></div>
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_text">
-
-<p>The test suite contains whole programs, which are pieces of
-code which can be compiled and linked into a stand-alone program that can be
-executed. These programs are generally written in high level languages such as
-C or C++, but sometimes they are written straight in LLVM assembly.</p>
-
-<p>These programs are compiled and then executed using several different
-methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation,
-etc). The output of these programs is compared to ensure that LLVM is compiling
-the program correctly.</p>
-
-<p>In addition to compiling and executing programs, whole program tests serve as
-a way of benchmarking LLVM performance, both in terms of the efficiency of the
-programs generated as well as the speed with which LLVM compiles, optimizes, and
-generates code.</p>
-
-<p>The test-suite is located in the <tt>test-suite</tt> Subversion module.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="quick">Quick start</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
- <p>The tests are located in two separate Subversion modules. The
- DejaGNU tests are in the main "llvm" module under the directory
- <tt>llvm/test</tt> (so you get these tests for free with the main llvm tree).
- The more comprehensive test suite that includes whole
-programs in C and C++ is in the <tt>test-suite</tt> module. This module should
-be checked out to the <tt>llvm/projects</tt> directory (don't use another name
-then the default "test-suite", for then the test suite will be run every time
-you run <tt>make</tt> in the main <tt>llvm</tt> directory).
-When you <tt>configure</tt> the <tt>llvm</tt> module,
-the <tt>test-suite</tt> directory will be automatically configured.
-Alternatively, you can configure the <tt>test-suite</tt> module manually.</p>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="quickdejagnu">DejaGNU tests</a></div>
-<!-- _______________________________________________________________________ -->
-<p>To run all of the simple tests in LLVM using DejaGNU, use the master Makefile
- in the <tt>llvm/test</tt> directory:</p>
-
-<div class="doc_code">
-<pre>
-% gmake -C llvm/test
-</pre>
-</div>
-
-<p>or</p>
-
-<div class="doc_code">
-<pre>
-% gmake check
-</pre>
-</div>
-
-<p>To run only a subdirectory of tests in <tt>llvm/test</tt> using DejaGNU (ie.
-Transforms), just set the TESTSUITE variable to the path of the
-subdirectory (relative to <tt>llvm/test</tt>):</p>
-
-<div class="doc_code">
-<pre>
-% gmake TESTSUITE=Transforms check
-</pre>
-</div>
-
-<p><b>Note: If you are running the tests with <tt>objdir != subdir</tt>, you
-must have run the complete testsuite before you can specify a
-subdirectory.</b></p>
-
-<p>To run only a single test, set <tt>TESTONE</tt> to its path (relative to
-<tt>llvm/test</tt>) and make the <tt>check-one</tt> target:</p>
-
-<div class="doc_code">
-<pre>
-% gmake TESTONE=Feature/basictest.ll check-one
-</pre>
-</div>
-
-<p>To run the tests with Valgrind (Memcheck by default), just append
-<tt>VG=1</tt> to the commands above, e.g.:</p>
-
-<div class="doc_code">
-<pre>
-% gmake check VG=1
-</pre>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="quicktestsuite">Test suite</a></div>
-<!-- _______________________________________________________________________ -->
-
-<p>To run the comprehensive test suite (tests that compile and execute whole
-programs), first checkout and setup the <tt>test-suite</tt> module:</p>
-
-<div class="doc_code">
-<pre>
-% cd llvm/projects
-% svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
-% cd ..
-% ./configure --with-llvmgccdir=$LLVM_GCC_DIR
-</pre>
-</div>
-
-<p>where <tt>$LLVM_GCC_DIR</tt> is the directory where
-you <em>installed</em> llvm-gcc, not it's src or obj
-dir. The <tt>--with-llvmgccdir</tt> option assumes that
-the <tt>llvm-gcc-4.2</tt> module was configured with
-<tt>--program-prefix=llvm-</tt>, and therefore that the C and C++
-compiler drivers are called <tt>llvm-gcc</tt> and <tt>llvm-g++</tt>
-respectively. If this is not the case,
-use <tt>--with-llvmgcc</tt>/<tt>--with-llvmgxx</tt> to specify each
-executable's location.</p>
-
-<p>Then, run the entire test suite by running make in the <tt>test-suite</tt>
-directory:</p>
-
-<div class="doc_code">
-<pre>
-% cd projects/test-suite
-% gmake
-</pre>
-</div>
-
-<p>Usually, running the "nightly" set of tests is a good idea, and you can also
-let it generate a report by running:</p>
-
-<div class="doc_code">
-<pre>
-% cd projects/test-suite
-% gmake TEST=nightly report report.html
-</pre>
-</div>
-
-<p>Any of the above commands can also be run in a subdirectory of
-<tt>projects/test-suite</tt> to run the specified test only on the programs in
-that subdirectory.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="dgstructure">DejaGNU structure</a></div>
-<!--=========================================================================-->
-<div class="doc_text">
- <p>The LLVM DejaGNU tests are driven by DejaGNU together with GNU Make and are
- located in the <tt>llvm/test</tt> directory.
-
- <p>This directory contains a large array of small tests
- that exercise various features of LLVM and to ensure that regressions do not
- occur. The directory is broken into several sub-directories, each focused on
- a particular area of LLVM. A few of the important ones are:</p>
-
- <ul>
- <li><tt>Analysis</tt>: checks Analysis passes.</li>
- <li><tt>Archive</tt>: checks the Archive library.</li>
- <li><tt>Assembler</tt>: checks Assembly reader/writer functionality.</li>
- <li><tt>Bitcode</tt>: checks Bitcode reader/writer functionality.</li>
- <li><tt>CodeGen</tt>: checks code generation and each target.</li>
- <li><tt>Features</tt>: checks various features of the LLVM language.</li>
- <li><tt>Linker</tt>: tests bitcode linking.</li>
- <li><tt>Transforms</tt>: tests each of the scalar, IPO, and utility
- transforms to ensure they make the right transformations.</li>
- <li><tt>Verifier</tt>: tests the IR verifier.</li>
- </ul>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="dgcustom">Writing new DejaGNU tests</a></div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_text">
- <p>The DejaGNU structure is very simple, but does require some information to
- be set. This information is gathered via <tt>configure</tt> and is written
- to a file, <tt>site.exp</tt> in <tt>llvm/test</tt>. The <tt>llvm/test</tt>
- Makefile does this work for you.</p>
-
- <p>In order for DejaGNU to work, each directory of tests must have a
- <tt>dg.exp</tt> file. DejaGNU looks for this file to determine how to run the
- tests. This file is just a Tcl script and it can do anything you want, but
- we've standardized it for the LLVM regression tests. If you're adding a
- directory of tests, just copy <tt>dg.exp</tt> from another directory to get
- running. The standard <tt>dg.exp</tt> simply loads a Tcl
- library (<tt>test/lib/llvm.exp</tt>) and calls the <tt>llvm_runtests</tt>
- function defined in that library with a list of file names to run. The names
- are obtained by using Tcl's glob command. Any directory that contains only
- directories does not need the <tt>dg.exp</tt> file.</p>
-
- <p>The <tt>llvm-runtests</tt> function lookas at each file that is passed to
- it and gathers any lines together that match "RUN:". This are the "RUN" lines
- that specify how the test is to be run. So, each test script must contain
- RUN lines if it is to do anything. If there are no RUN lines, the
- <tt>llvm-runtests</tt> function will issue an error and the test will
- fail.</p>
-
- <p>RUN lines are specified in the comments of the test program using the
- keyword <tt>RUN</tt> followed by a colon, and lastly the command (pipeline)
- to execute. Together, these lines form the "script" that
- <tt>llvm-runtests</tt> executes to run the test case. The syntax of the
- RUN lines is similar to a shell's syntax for pipelines including I/O
- redirection and variable substitution. However, even though these lines
- may <i>look</i> like a shell script, they are not. RUN lines are interpreted
- directly by the Tcl <tt>exec</tt> command. They are never executed by a
- shell. Consequently the syntax differs from normal shell script syntax in a
- few ways. You can specify as many RUN lines as needed.</p>
-
- <p>Each RUN line is executed on its own, distinct from other lines unless
- its last character is <tt>\</tt>. This continuation character causes the RUN
- line to be concatenated with the next one. In this way you can build up long
- pipelines of commands without making huge line lengths. The lines ending in
- <tt>\</tt> are concatenated until a RUN line that doesn't end in <tt>\</tt> is
- found. This concatenated set of RUN lines then constitutes one execution.
- Tcl will substitute variables and arrange for the pipeline to be executed. If
- any process in the pipeline fails, the entire line (and test case) fails too.
- </p>
-
- <p> Below is an example of legal RUN lines in a <tt>.ll</tt> file:</p>
-
-<div class="doc_code">
-<pre>
-; RUN: llvm-as < %s | llvm-dis > %t1
-; RUN: llvm-dis < %s.bc-13 > %t2
-; RUN: diff %t1 %t2
-</pre>
-</div>
-
- <p>As with a Unix shell, the RUN: lines permit pipelines and I/O redirection
- to be used. However, the usage is slightly different than for Bash. To check
- what's legal, see the documentation for the
- <a href="http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm#M2">Tcl exec</a>
- command and the
- <a href="http://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html">tutorial</a>.
- The major differences are:</p>
- <ul>
- <li>You can't do <tt>2>&1</tt>. That will cause Tcl to write to a
- file named <tt>&1</tt>. Usually this is done to get stderr to go through
- a pipe. You can do that in tcl with <tt>|&</tt> so replace this idiom:
- <tt>... 2>&1 | grep</tt> with <tt>... |& grep</tt></li>
- <li>You can only redirect to a file, not to another descriptor and not from
- a here document.</li>
- <li>tcl supports redirecting to open files with the @ syntax but you
- shouldn't use that here.</li>
- </ul>
-
- <p>There are some quoting rules that you must pay attention to when writing
- your RUN lines. In general nothing needs to be quoted. Tcl won't strip off any
- ' or " so they will get passed to the invoked program. For example:</p>
-
-<div class="doc_code">
-<pre>
-... | grep 'find this string'
-</pre>
-</div>
-
- <p>This will fail because the ' characters are passed to grep. This would
- instruction grep to look for <tt>'find</tt> in the files <tt>this</tt> and
- <tt>string'</tt>. To avoid this use curly braces to tell Tcl that it should
- treat everything enclosed as one value. So our example would become:</p>
-
-<div class="doc_code">
-<pre>
-... | grep {find this string}
-</pre>
-</div>
-
- <p>Additionally, the characters <tt>[</tt> and <tt>]</tt> are treated
- specially by Tcl. They tell Tcl to interpret the content as a command to
- execute. Since these characters are often used in regular expressions this can
- have disastrous results and cause the entire test run in a directory to fail.
- For example, a common idiom is to look for some basicblock number:</p>
-
-<div class="doc_code">
-<pre>
-... | grep bb[2-8]
-</pre>
-</div>
-
- <p>This, however, will cause Tcl to fail because its going to try to execute
- a program named "2-8". Instead, what you want is this:</p>
-
-<div class="doc_code">
-<pre>
-... | grep {bb\[2-8\]}
-</pre>
-</div>
-
- <p>Finally, if you need to pass the <tt>\</tt> character down to a program,
- then it must be doubled. This is another Tcl special character. So, suppose
- you had:
-
-<div class="doc_code">
-<pre>
-... | grep 'i32\*'
-</pre>
-</div>
-
- <p>This will fail to match what you want (a pointer to i32). First, the
- <tt>'</tt> do not get stripped off. Second, the <tt>\</tt> gets stripped off
- by Tcl so what grep sees is: <tt>'i32*'</tt>. That's not likely to match
- anything. To resolve this you must use <tt>\\</tt> and the <tt>{}</tt>, like
- this:</p>
-
-<div class="doc_code">
-<pre>
-... | grep {i32\\*}
-</pre>
-</div>
-
-<p>If your system includes GNU <tt>grep</tt>, make sure
-that <tt>GREP_OPTIONS</tt> is not set in your environment. Otherwise,
-you may get invalid results (both false positives and false
-negatives).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="FileCheck">The FileCheck utility</a></div>
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_text">
-
-<p>A powerful feature of the RUN: lines is that it allows any arbitrary commands
- to be executed as part of the test harness. While standard (portable) unix
- tools like 'grep' work fine on run lines, as you see above, there are a lot
- of caveats due to interaction with Tcl syntax, and we want to make sure the
- run lines are portable to a wide range of systems. Another major problem is
- that grep is not very good at checking to verify that the output of a tools
- contains a series of different output in a specific order. The FileCheck
- tool was designed to help with these problems.</p>
-
-<p>FileCheck (whose basic command line arguments are described in <a
- href="http://llvm.org/cmds/FileCheck.html">the FileCheck man page</a> is
- designed to read a file to check from standard input, and the set of things
- to verify from a file specified as a command line argument. A simple example
- of using FileCheck from a RUN line looks like this:</p>
-
-<div class="doc_code">
-<pre>
-; RUN: llvm-as < %s | llc -march=x86-64 | <b>FileCheck %s</b>
-</pre>
-</div>
-
-<p>This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
-llc, then pipe the output of llc into FileCheck. This means that FileCheck will
-be verifying its standard input (the llc output) against the filename argument
-specified (the original .ll file specified by "%s"). To see how this works,
-lets look at the rest of the .ll file (after the RUN line):</p>
-
-<div class="doc_code">
-<pre>
-define void @sub1(i32* %p, i32 %v) {
-entry:
-; <b>CHECK: sub1:</b>
-; <b>CHECK: subl</b>
- %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
- ret void
-}
-
-define void @inc4(i64* %p) {
-entry:
-; <b>CHECK: inc4:</b>
-; <b>CHECK: incq</b>
- %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
- ret void
-}
-</pre>
-</div>
-
-<p>Here you can see some "CHECK:" lines specified in comments. Now you can see
-how the file is piped into llvm-as, then llc, and the machine code output is
-what we are verifying. FileCheck checks the machine code output to verify that
-it matches what the "CHECK:" lines specify.</p>
-
-<p>The syntax of the CHECK: lines is very simple: they are fixed strings that
-must occur in order. FileCheck defaults to ignoring horizontal whitespace
-differences (e.g. a space is allowed to match a tab) but otherwise, the contents
-of the CHECK: line is required to match some thing in the test file exactly.</p>
-
-<p>One nice thing about FileCheck (compared to grep) is that it allows merging
-test cases together into logical groups. For example, because the test above
-is checking for the "sub1:" and "inc4:" labels, it will not match unless there
-is a "subl" in between those labels. If it existed somewhere else in the file,
-that would not count: "grep subl" matches if subl exists anywhere in the
-file.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a
-name="FileCheck-check-prefix">The FileCheck -check-prefix option</a></div>
-
-<div class="doc_text">
-
-<p>The FileCheck -check-prefix option allows multiple test configurations to be
-driven from one .ll file. This is useful in many circumstances, for example,
-testing different architectural variants with llc. Here's a simple example:</p>
-
-<div class="doc_code">
-<pre>
-; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
-; RUN: | <b>FileCheck %s -check-prefix=X32</b>
-; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
-; RUN: | <b>FileCheck %s -check-prefix=X64</b>
-
-define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
- %tmp1 = insertelement <4 x i32> %tmp, i32 %s, i32 1
- ret <4 x i32> %tmp1
-; <b>X32:</b> pinsrd_1:
-; <b>X32:</b> pinsrd $1, 4(%esp), %xmm0
-
-; <b>X64:</b> pinsrd_1:
-; <b>X64:</b> pinsrd $1, %edi, %xmm0
-}
-</pre>
-</div>
-
-<p>In this case, we're testing that we get the expected code generation with
-both 32-bit and 64-bit code generation.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a
-name="FileCheck-CHECK-NEXT">The "CHECK-NEXT:" directive</a></div>
-
-<div class="doc_text">
-
-<p>Sometimes you want to match lines and would like to verify that matches
-happen on exactly consequtive lines with no other lines in between them. In
-this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
-you specified a custom check prefix, just use "<PREFIX>-NEXT:". For
-example, something like this works as you'd expect:</p>
-
-<div class="doc_code">
-<pre>
-define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
- %tmp3 = load <2 x double>* %A, align 16
- %tmp7 = insertelement <2 x double> undef, double %B, i32 0
- %tmp9 = shufflevector <2 x double> %tmp3,
- <2 x double> %tmp7,
- <2 x i32> < i32 0, i32 2 >
- store <2 x double> %tmp9, <2 x double>* %r, align 16
- ret void
-
-; <b>CHECK:</b> t2:
-; <b>CHECK:</b> movl 8(%esp), %eax
-; <b>CHECK-NEXT:</b> movapd (%eax), %xmm0
-; <b>CHECK-NEXT:</b> movhpd 12(%esp), %xmm0
-; <b>CHECK-NEXT:</b> movl 4(%esp), %eax
-; <b>CHECK-NEXT:</b> movapd %xmm0, (%eax)
-; <b>CHECK-NEXT:</b> ret
-}
-</pre>
-</div>
-
-<p>CHECK-NEXT: directives reject the input unless there is exactly one newline
-between it an the previous directive. A CHECK-NEXT cannot be the first
-directive in a file.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a
-name="FileCheck-CHECK-NOT">The "CHECK-NOT:" directive</a></div>
-
-<div class="doc_text">
-
-<p>The CHECK-NOT: directive is used to verify that a string doesn't occur
-between two matches (or the first match and the beginning of the file). For
-example, to verify that a load is removed by a transformation, a test like this
-can be used:</p>
-
-<div class="doc_code">
-<pre>
-define i8 @coerce_offset0(i32 %V, i32* %P) {
- store i32 %V, i32* %P
-
- %P2 = bitcast i32* %P to i8*
- %P3 = getelementptr i8* %P2, i32 2
-
- %A = load i8* %P3
- ret i8 %A
-; <b>CHECK:</b> @coerce_offset0
-; <b>CHECK-NOT:</b> load
-; <b>CHECK:</b> ret i8
-}
-</pre>
-</div>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a
-name="FileCheck-Matching">FileCheck Pattern Matching Syntax</a></div>
-
-<div class="doc_text">
-
-<p>The CHECK: and CHECK-NOT: directives both take a pattern to match. For most
-uses of FileCheck, fixed string matching is perfectly sufficient. For some
-things, a more flexible form of matching is desired. To support this, FileCheck
-allows you to specify regular expressions in matching strings, surrounded by
-double braces: <b>{{yourregex}}</b>. Because we want to use fixed string
-matching for a majority of what we do, FileCheck has been designed to support
-mixing and matching fixed string matching with regular expressions. This allows
-you to write things like this:</p>
-
-<div class="doc_code">
-<pre>
-; CHECK: movhpd <b>{{[0-9]+}}</b>(%esp), <b>{{%xmm[0-7]}}</b>
-</pre>
-</div>
-
-<p>In this case, any offset from the ESP register will be allowed, and any xmm
-register will be allowed.</p>
-
-<p>Because regular expressions are enclosed with double braces, they are
-visually distinct, and you don't need to use escape characters within the double
-braces like you would in C. In the rare case that you want to match double
-braces explicitly from the input, you can use something ugly like
-<b>{{[{][{]}}</b> as your pattern.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"><a
-name="FileCheck-Variables">FileCheck Variables</a></div>
-
-<div class="doc_text">
-
-<p>It is often useful to match a pattern and then verify that it occurs again
-later in the file. For codegen tests, this can be useful to allow any register,
-but verify that that register is used consistently later. To do this, FileCheck
-allows named variables to be defined and substituted into patterns. Here is a
-simple example:</p>
-
-<div class="doc_code">
-<pre>
-; CHECK: test5:
-; CHECK: notw <b>[[REGISTER:%[a-z]+]]</b>
-; CHECK: andw {{.*}}<b>[[REGISTER]]</b>
-</pre>
-</div>
-
-<p>The first check line matches a regex (<tt>%[a-z]+</tt>) and captures it into
-the variables "REGISTER". The second line verifies that whatever is in REGISTER
-occurs later in the file after an "andw". FileCheck variable references are
-always contained in <tt>[[ ]]</tt> pairs, are named, and their names can be
-formed with the regex "<tt>[a-zA-Z][a-zA-Z0-9]*</tt>". If a colon follows the
-name, then it is a definition of the variable, if not, it is a use.</p>
-
-<p>FileCheck variables can be defined multiple times, and uses always get the
-latest value. Note that variables are all read at the start of a "CHECK" line
-and are all defined at the end. This means that if you have something like
-"<tt>CHECK: [[XYZ:.*]]x[[XYZ]]</tt>" that the check line will read the previous
-value of the XYZ variable and define a new one after the match is performed. If
-you need to do something like this you can probably take advantage of the fact
-that FileCheck is not actually line-oriented when it matches, this allows you to
-define two separate CHECK lines that match on the same line.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="dgvars">Variables and
-substitutions</a></div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_text">
- <p>With a RUN line there are a number of substitutions that are permitted. In
- general, any Tcl variable that is available in the <tt>substitute</tt>
- function (in <tt>test/lib/llvm.exp</tt>) can be substituted into a RUN line.
- To make a substitution just write the variable's name preceded by a $.
- Additionally, for compatibility reasons with previous versions of the test
- library, certain names can be accessed with an alternate syntax: a % prefix.
- These alternates are deprecated and may go away in a future version.
- </p>
- <p>Here are the available variable names. The alternate syntax is listed in
- parentheses.</p>
-
- <dl style="margin-left: 25px">
- <dt><b>$test</b> (%s)</dt>
- <dd>The full path to the test case's source. This is suitable for passing
- on the command line as the input to an llvm tool.</dd>
-
- <dt><b>$srcdir</b></dt>
- <dd>The source directory from where the "<tt>make check</tt>" was run.</dd>
-
- <dt><b>objdir</b></dt>
- <dd>The object directory that corresponds to the <tt>$srcdir</tt>.</dd>
-
- <dt><b>subdir</b></dt>
- <dd>A partial path from the <tt>test</tt> directory that contains the
- sub-directory that contains the test source being executed.</dd>
-
- <dt><b>srcroot</b></dt>
- <dd>The root directory of the LLVM src tree.</dd>
-
- <dt><b>objroot</b></dt>
- <dd>The root directory of the LLVM object tree. This could be the same
- as the srcroot.</dd>
-
- <dt><b>path</b><dt>
- <dd>The path to the directory that contains the test case source. This is
- for locating any supporting files that are not generated by the test, but
- used by the test.</dd>
-
- <dt><b>tmp</b></dt>
- <dd>The path to a temporary file name that could be used for this test case.
- The file name won't conflict with other test cases. You can append to it if
- you need multiple temporaries. This is useful as the destination of some
- redirected output.</dd>
-
- <dt><b>llvmlibsdir</b> (%llvmlibsdir)</dt>
- <dd>The directory where the LLVM libraries are located.</dd>
-
- <dt><b>target_triplet</b> (%target_triplet)</dt>
- <dd>The target triplet that corresponds to the current host machine (the one
- running the test cases). This should probably be called "host".<dd>
-
- <dt><b>llvmgcc</b> (%llvmgcc)</dt>
- <dd>The full path to the <tt>llvm-gcc</tt> executable as specified in the
- configured LLVM environment</dd>
-
- <dt><b>llvmgxx</b> (%llvmgxx)</dt>
- <dd>The full path to the <tt>llvm-gxx</tt> executable as specified in the
- configured LLVM environment</dd>
-
- <dt><b>gccpath</b></dt>
- <dd>The full path to the C compiler used to <i>build </i> LLVM. Note that
- this might not be gcc.</dd>
-
- <dt><b>gxxpath</b></dt>
- <dd>The full path to the C++ compiler used to <i>build </i> LLVM. Note that
- this might not be g++.</dd>
-
- <dt><b>compile_c</b> (%compile_c)</dt>
- <dd>The full command line used to compile LLVM C source code. This has all
- the configured -I, -D and optimization options.</dd>
-
- <dt><b>compile_cxx</b> (%compile_cxx)</dt>
- <dd>The full command used to compile LLVM C++ source code. This has
- all the configured -I, -D and optimization options.</dd>
-
- <dt><b>link</b> (%link)</dt>
- <dd>This full link command used to link LLVM executables. This has all the
- configured -I, -L and -l options.</dd>
-
- <dt><b>shlibext</b> (%shlibext)</dt>
- <dd>The suffix for the host platforms share library (dll) files. This
- includes the period as the first character.</dd>
- </dl>
- <p>To add more variables, two things need to be changed. First, add a line in
- the <tt>test/Makefile</tt> that creates the <tt>site.exp</tt> file. This will
- "set" the variable as a global in the site.exp file. Second, in the
- <tt>test/lib/llvm.exp</tt> file, in the substitute proc, add the variable name
- to the list of "global" declarations at the beginning of the proc. That's it,
- the variable can then be used in test scripts.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection"><a name="dgfeatures">Other Features</a></div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_text">
- <p>To make RUN line writing easier, there are several shell scripts located
- in the <tt>llvm/test/Scripts</tt> directory. This directory is in the PATH
- when running tests, so you can just call these scripts using their name. For
- example:</p>
- <dl>
- <dt><b>ignore</b></dt>
- <dd>This script runs its arguments and then always returns 0. This is useful
- in cases where the test needs to cause a tool to generate an error (e.g. to
- check the error output). However, any program in a pipeline that returns a
- non-zero result will cause the test to fail. This script overcomes that
- issue and nicely documents that the test case is purposefully ignoring the
- result code of the tool</dd>
-
- <dt><b>not</b></dt>
- <dd>This script runs its arguments and then inverts the result code from
- it. Zero result codes become 1. Non-zero result codes become 0. This is
- useful to invert the result of a grep. For example "not grep X" means
- succeed only if you don't find X in the input.</dd>
- </dl>
-
- <p>Sometimes it is necessary to mark a test case as "expected fail" or XFAIL.
- You can easily mark a test as XFAIL just by including <tt>XFAIL: </tt> on a
- line near the top of the file. This signals that the test case should succeed
- if the test fails. Such test cases are counted separately by DejaGnu. To
- specify an expected fail, use the XFAIL keyword in the comments of the test
- program followed by a colon and one or more regular expressions (separated by
- a comma). The regular expressions allow you to XFAIL the test conditionally by
- host platform. The regular expressions following the : are matched against the
- target triplet for the host machine. If there is a match, the test is expected
- to fail. If not, the test is expected to succeed. To XFAIL everywhere just
- specify <tt>XFAIL: *</tt>. Here is an example of an <tt>XFAIL</tt> line:</p>
-
-<div class="doc_code">
-<pre>
-; XFAIL: darwin,sun
-</pre>
-</div>
-
- <p>To make the output more useful, the <tt>llvm_runtest</tt> function wil
- scan the lines of the test case for ones that contain a pattern that matches
- PR[0-9]+. This is the syntax for specifying a PR (Problem Report) number that
- is related to the test case. The number after "PR" specifies the LLVM bugzilla
- number. When a PR number is specified, it will be used in the pass/fail
- reporting. This is useful to quickly get some context when a test fails.</p>
-
- <p>Finally, any line that contains "END." will cause the special
- interpretation of lines to terminate. This is generally done right after the
- last RUN: line. This has two side effects: (a) it prevents special
- interpretation of lines that are part of the test program, not the
- instructions to the test case, and (b) it speeds things up for really big test
- cases by avoiding interpretation of the remainder of the file.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="testsuitestructure">Test suite
-Structure</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
-<p>The <tt>test-suite</tt> module contains a number of programs that can be compiled
-with LLVM and executed. These programs are compiled using the native compiler
-and various LLVM backends. The output from the program compiled with the
-native compiler is assumed correct; the results from the other programs are
-compared to the native program output and pass if they match.</p>
-
-<p>When executing tests, it is usually a good idea to start out with a subset of
-the available tests or programs. This makes test run times smaller at first and
-later on this is useful to investigate individual test failures. To run some
-test only on a subset of programs, simply change directory to the programs you
-want tested and run <tt>gmake</tt> there. Alternatively, you can run a different
-test using the <tt>TEST</tt> variable to change what tests or run on the
-selected programs (see below for more info).</p>
-
-<p>In addition for testing correctness, the <tt>llvm-test</tt> directory also
-performs timing tests of various LLVM optimizations. It also records
-compilation times for the compilers and the JIT. This information can be
-used to compare the effectiveness of LLVM's optimizations and code
-generation.</p>
-
-<p><tt>llvm-test</tt> tests are divided into three types of tests: MultiSource,
-SingleSource, and External.</p>
-
-<ul>
-<li><tt>llvm-test/SingleSource</tt>
-<p>The SingleSource directory contains test programs that are only a single
-source file in size. These are usually small benchmark programs or small
-programs that calculate a particular value. Several such programs are grouped
-together in each directory.</p></li>
-
-<li><tt>llvm-test/MultiSource</tt>
-<p>The MultiSource directory contains subdirectories which contain entire
-programs with multiple source files. Large benchmarks and whole applications
-go here.</p></li>
-
-<li><tt>llvm-test/External</tt>
-<p>The External directory contains Makefiles for building code that is external
-to (i.e., not distributed with) LLVM. The most prominent members of this
-directory are the SPEC 95 and SPEC 2000 benchmark suites. The <tt>External</tt>
-directory does not contain these actual tests, but only the Makefiles that know
-how to properly compile these programs from somewhere else. The presence and
-location of these external programs is configured by the llvm-test
-<tt>configure</tt> script.</p></li>
-</ul>
-
-<p>Each tree is then subdivided into several categories, including applications,
-benchmarks, regression tests, code that is strange grammatically, etc. These
-organizations should be relatively self explanatory.</p>
-
-<p>Some tests are known to fail. Some are bugs that we have not fixed yet;
-others are features that we haven't added yet (or may never add). In DejaGNU,
-the result for such tests will be XFAIL (eXpected FAILure). In this way, you
-can tell the difference between an expected and unexpected failure.</p>
-
-<p>The tests in the test suite have no such feature at this time. If the
-test passes, only warnings and other miscellaneous output will be generated. If
-a test fails, a large <program> FAILED message will be displayed. This
-will help you separate benign warnings from actual test failures.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="testsuiterun">Running the test suite</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
-<p>First, all tests are executed within the LLVM object directory tree. They
-<i>are not</i> executed inside of the LLVM source tree. This is because the
-test suite creates temporary files during execution.</p>
-
-<p>To run the test suite, you need to use the following steps:</p>
-
-<ol>
- <li><tt>cd</tt> into the <tt>llvm/projects</tt> directory in your source tree.
- </li>
-
- <li><p>Check out the <tt>test-suite</tt> module with:</p>
-
-<div class="doc_code">
-<pre>
-% svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
-</pre>
-</div>
- <p>This will get the test suite into <tt>llvm/projects/test-suite</tt>.</p>
- </li>
- <li><p>Configure and build <tt>llvm</tt>.</p></li>
- <li><p>Configure and build <tt>llvm-gcc</tt>.</p></li>
- <li><p>Install <tt>llvm-gcc</tt> somewhere.</p></li>
- <li><p><em>Re-configure</em> <tt>llvm</tt> from the top level of
- each build tree (LLVM object directory tree) in which you want
- to run the test suite, just as you do before building LLVM.</p>
- <p>During the <em>re-configuration</em>, you must either: (1)
- have <tt>llvm-gcc</tt> you just built in your path, or (2)
- specify the directory where your just-built <tt>llvm-gcc</tt> is
- installed using <tt>--with-llvmgccdir=$LLVM_GCC_DIR</tt>.</p>
- <p>You must also tell the configure machinery that the test suite
- is available so it can be configured for your build tree:</p>
-<div class="doc_code">
-<pre>
-% cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure [--with-llvmgccdir=$LLVM_GCC_DIR]
-</pre>
-</div>
- <p>[Remember that <tt>$LLVM_GCC_DIR</tt> is the directory where you
- <em>installed</em> llvm-gcc, not its src or obj directory.]</p>
- </li>
-
- <li><p>You can now run the test suite from your build tree as follows:</p>
-<div class="doc_code">
-<pre>
-% cd $LLVM_OBJ_ROOT/projects/test-suite
-% make
-</pre>
-</div>
- </li>
-</ol>
-<p>Note that the second and third steps only need to be done once. After you
-have the suite checked out and configured, you don't need to do it again (unless
-the test code or configure script changes).</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection">
-<a name="testsuiteexternal">Configuring External Tests</a></div>
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_text">
-<p>In order to run the External tests in the <tt>test-suite</tt>
- module, you must specify <i>--with-externals</i>. This
- must be done during the <em>re-configuration</em> step (see above),
- and the <tt>llvm</tt> re-configuration must recognize the
- previously-built <tt>llvm-gcc</tt>. If any of these is missing or
- neglected, the External tests won't work.</p>
-<dl>
-<dt><i>--with-externals</i></dt>
-<dt><i>--with-externals=<<tt>directory</tt>></i></dt>
-</dl>
- This tells LLVM where to find any external tests. They are expected to be
- in specifically named subdirectories of <<tt>directory</tt>>.
- If <tt>directory</tt> is left unspecified,
- <tt>configure</tt> uses the default value
- <tt>/home/vadve/shared/benchmarks/speccpu2000/benchspec</tt>.
- Subdirectory names known to LLVM include:
- <dl>
- <dt>spec95</dt>
- <dt>speccpu2000</dt>
- <dt>speccpu2006</dt>
- <dt>povray31</dt>
- </dl>
- Others are added from time to time, and can be determined from
- <tt>configure</tt>.
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection">
-<a name="testsuitetests">Running different tests</a></div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_text">
-<p>In addition to the regular "whole program" tests, the <tt>test-suite</tt>
-module also provides a mechanism for compiling the programs in different ways.
-If the variable TEST is defined on the <tt>gmake</tt> command line, the test system will
-include a Makefile named <tt>TEST.<value of TEST variable>.Makefile</tt>.
-This Makefile can modify build rules to yield different results.</p>
-
-<p>For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt> to
-create the nightly test reports. To run the nightly tests, run <tt>gmake
-TEST=nightly</tt>.</p>
-
-<p>There are several TEST Makefiles available in the tree. Some of them are
-designed for internal LLVM research and will not work outside of the LLVM
-research group. They may still be valuable, however, as a guide to writing your
-own TEST Makefile for any optimization or analysis passes that you develop with
-LLVM.</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection">
-<a name="testsuiteoutput">Generating test output</a></div>
-<!-- _______________________________________________________________________ -->
-<div class="doc_text">
- <p>There are a number of ways to run the tests and generate output. The most
- simple one is simply running <tt>gmake</tt> with no arguments. This will
- compile and run all programs in the tree using a number of different methods
- and compare results. Any failures are reported in the output, but are likely
- drowned in the other output. Passes are not reported explicitely.</p>
-
- <p>Somewhat better is running <tt>gmake TEST=sometest test</tt>, which runs
- the specified test and usually adds per-program summaries to the output
- (depending on which sometest you use). For example, the <tt>nightly</tt> test
- explicitely outputs TEST-PASS or TEST-FAIL for every test after each program.
- Though these lines are still drowned in the output, it's easy to grep the
- output logs in the Output directories.</p>
-
- <p>Even better are the <tt>report</tt> and <tt>report.format</tt> targets
- (where <tt>format</tt> is one of <tt>html</tt>, <tt>csv</tt>, <tt>text</tt> or
- <tt>graphs</tt>). The exact contents of the report are dependent on which
- <tt>TEST</tt> you are running, but the text results are always shown at the
- end of the run and the results are always stored in the
- <tt>report.<type>.format</tt> file (when running with
- <tt>TEST=<type></tt>).
-
- The <tt>report</tt> also generate a file called
- <tt>report.<type>.raw.out</tt> containing the output of the entire test
- run.
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsection">
-<a name="testsuitecustom">Writing custom tests for the test suite</a></div>
-<!-- _______________________________________________________________________ -->
-
-<div class="doc_text">
-
-<p>Assuming you can run the test suite, (e.g. "<tt>gmake TEST=nightly report</tt>"
-should work), it is really easy to run optimizations or code generator
-components against every program in the tree, collecting statistics or running
-custom checks for correctness. At base, this is how the nightly tester works,
-it's just one example of a general framework.</p>
-
-<p>Lets say that you have an LLVM optimization pass, and you want to see how
-many times it triggers. First thing you should do is add an LLVM
-<a href="ProgrammersManual.html#Statistic">statistic</a> to your pass, which
-will tally counts of things you care about.</p>
-
-<p>Following this, you can set up a test and a report that collects these and
-formats them for easy viewing. This consists of two files, an
-"<tt>test-suite/TEST.XXX.Makefile</tt>" fragment (where XXX is the name of your
-test) and an "<tt>llvm-test/TEST.XXX.report</tt>" file that indicates how to
-format the output into a table. There are many example reports of various
-levels of sophistication included with the test suite, and the framework is very
-general.</p>
-
-<p>If you are interested in testing an optimization pass, check out the
-"libcalls" test as an example. It can be run like this:<p>
-
-<div class="doc_code">
-<pre>
-% cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level
-% make TEST=libcalls report
-</pre>
-</div>
-
-<p>This will do a bunch of stuff, then eventually print a table like this:</p>
-
-<div class="doc_code">
-<pre>
-Name | total | #exit |
-...
-FreeBench/analyzer/analyzer | 51 | 6 |
-FreeBench/fourinarow/fourinarow | 1 | 1 |
-FreeBench/neural/neural | 19 | 9 |
-FreeBench/pifft/pifft | 5 | 3 |
-MallocBench/cfrac/cfrac | 1 | * |
-MallocBench/espresso/espresso | 52 | 12 |
-MallocBench/gs/gs | 4 | * |
-Prolangs-C/TimberWolfMC/timberwolfmc | 302 | * |
-Prolangs-C/agrep/agrep | 33 | 12 |
-Prolangs-C/allroots/allroots | * | * |
-Prolangs-C/assembler/assembler | 47 | * |
-Prolangs-C/bison/mybison | 74 | * |
-...
-</pre>
-</div>
-
-<p>This basically is grepping the -stats output and displaying it in a table.
-You can also use the "TEST=libcalls report.html" target to get the table in HTML
-form, similarly for report.csv and report.tex.</p>
-
-<p>The source for this is in test-suite/TEST.libcalls.*. The format is pretty
-simple: the Makefile indicates how to run the test (in this case,
-"<tt>opt -simplify-libcalls -stats</tt>"), and the report contains one line for
-each column of the output. The first value is the header for the column and the
-second is the regex to grep the output of the command for. There are lots of
-example reports that can do fancy stuff.</p>
-
-</div>
-
-<!--=========================================================================-->
-<div class="doc_section"><a name="nightly">Running the nightly tester</a></div>
-<!--=========================================================================-->
-
-<div class="doc_text">
-
-<p>
-The <a href="http://llvm.org/nightlytest/">LLVM Nightly Testers</a>
-automatically check out an LLVM tree, build it, run the "nightly"
-program test (described above), run all of the DejaGNU tests,
-delete the checked out tree, and then submit the results to
-<a href="http://llvm.org/nightlytest/">http://llvm.org/nightlytest/</a>.
-After test results are submitted to
-<a href="http://llvm.org/nightlytest/">http://llvm.org/nightlytest/</a>,
-they are processed and displayed on the tests page. An email to
-<a href="http://lists.cs.uiuc.edu/pipermail/llvm-testresults/">
-llvm-testresults at cs.uiuc.edu</a> summarizing the results is also generated.
-This testing scheme is designed to ensure that programs don't break as well
-as keep track of LLVM's progress over time.</p>
-
-<p>If you'd like to set up an instance of the nightly tester to run on your
-machine, take a look at the comments at the top of the
-<tt>utils/NewNightlyTest.pl</tt> file. If you decide to set up a nightly tester
-please choose a unique nickname and invoke <tt>utils/NewNightlyTest.pl</tt>
-with the "-nickname [yournickname]" command line option.
-
-<p>You can create a shell script to encapsulate the running of the script.
-The optimized x86 Linux nightly test is run from just such a script:</p>
-
-<div class="doc_code">
-<pre>
-#!/bin/bash
-BASE=/proj/work/llvm/nightlytest
-export BUILDDIR=$BASE/build
-export WEBDIR=$BASE/testresults
-export LLVMGCCDIR=/proj/work/llvm/cfrontend/install
-export PATH=/proj/install/bin:$LLVMGCCDIR/bin:$PATH
-export LD_LIBRARY_PATH=/proj/install/lib
-cd $BASE
-cp /proj/work/llvm/llvm/utils/NewNightlyTest.pl .
-nice ./NewNightlyTest.pl -nice -release -verbose -parallel -enable-linscan \
- -nickname NightlyTester -noexternals > output.log 2>&1
-</pre>
-</div>
-
-<p>It is also possible to specify the the location your nightly test results
-are submitted. You can do this by passing the command line option
-"-submit-server [server_address]" and "-submit-script [script_on_server]" to
-<tt>utils/NewNightlyTest.pl</tt>. For example, to submit to the llvm.org
-nightly test results page, you would invoke the nightly test script with
-"-submit-server llvm.org -submit-script /nightlytest/NightlyTestAccept.cgi".
-If these options are not specified, the nightly test script sends the results
-to the llvm.org nightly test results page.</p>
-
-<p>Take a look at the <tt>NewNightlyTest.pl</tt> file to see what all of the
-flags and strings do. If you start running the nightly tests, please let us
-know. Thanks!</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- John T. Criswell, Reid Spencer, and Tanya Lattner<br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date$
-</address>
-</body>
-</html>
Removed: llvm/trunk/docs/UsingLibraries.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/UsingLibraries.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/UsingLibraries.html (original)
+++ llvm/trunk/docs/UsingLibraries.html (removed)
@@ -1,439 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <title>Using The LLVM Libraries</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-<body>
-<div class="doc_title">Using The LLVM Libraries</div>
-<ol>
- <li><a href="#abstract">Abstract</a></li>
- <li><a href="#introduction">Introduction</a></li>
- <li><a href="#descriptions">Library Descriptions</a></li>
- <li><a href="#dependencies">Library Dependencies</a></li>
- <li><a href="#rot">Linkage Rules Of Thumb</a>
- <ol>
- <li><a href="#always">Always link LLVMCore, LLVMSupport, LLVMSystem</a>
- <li><a href="#onlyone">Never link both archive and re-linked</a>
- </ol>
- </li>
-</ol>
-
-<div class="doc_author">
- <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a></p>
-</div>
-
-<p class="doc_warning">Warning: This document is out of date, please see <a href="CommandGuide/html/llvm-config.html">llvm-config</a> for more information.</p>
-
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="abstract">Abstract</a></div>
-<div class="doc_text">
- <p>Amongst other things, LLVM is a toolkit for building compilers, linkers,
- runtime executives, virtual machines, and other program execution related
- tools. In addition to the LLVM tool set, the functionality of LLVM is
- available through a set of libraries. To use LLVM as a toolkit for
- constructing tools, a developer needs to understand what is contained in the
- various libraries, what they depend on, and how to use them. Fortunately,
- there is a tool, <tt>llvm-config</tt> to aid with this. This document
- describes the contents of the libraries and how to use <tt>llvm-config</tt>
- to generate command line options.
-</p>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"> <a name="introduction">Introduction</a></div>
-<div class="doc_text">
- <p>If you're writing a compiler, virtual machine, or any other utility based
- on LLVM, you'll need to figure out which of the many libraries files you will
- need to link with to be successful. An understanding of the contents of these
- libraries will be useful in coming up with an optimal specification for the
- libraries to link with. The purpose of this document is to reduce some of
- the trial and error that the author experienced in using LLVM.</p>
- <p>LLVM produces two types of libraries: archives (ending in <tt>.a</tt>) and
- objects (ending in <tt>.o</tt>). However, both are libraries. Libraries ending
- in <tt>.o</tt> are known as re-linked libraries because they contain all the
- compilation units of the library linked together as a single <tt>.o</tt> file.
- Furthermore, several of the libraries have <em>both</em> forms of library. The
- re-linked libraries are used whenever you want to include all symbols from the
- library. The archive libraries are used whenever you want to only resolve
- outstanding symbols at that point in the link without including everything in
- the library. </p>
- <p>If you're using the LLVM Makefile system to link your tools,you will use
- the <tt>LLVMLIBS</tt> make variable.
- (see the <a href="MakefileGuide.html#LLVMLIBS">Makefile Guide</a> for
- details). This variable specifies which LLVM libraries to link into your tool
- and the order in which they will be linked. You specify re-linked libraries by
- naming the library without a suffix. You specify archive libraries by naming
- the library with a <tt>.a</tt> suffix but without the <tt>lib</tt> prefix. The
- order in which the libraries appear in the <tt>LLVMLIBS</tt> variable
- definition is the order in which they will be linked. Getting this order
- correct for your tool can sometimes be challenging.
-</div>
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="descriptions"></a>Library Descriptions</div>
-<div class="doc_text">
- <p>The table below categorizes each library
-<table style="text-align:left">
- <tr><th>Library</th><th>Forms</th><th>Description</th></tr>
- <tr><th colspan="3">Core Libraries</th></tr>
- <tr><td>LLVMArchive</td><td><tt>.a</tt></td>
- <td>LLVM archive reading and writing</td></tr>
- <tr><td>LLVMAsmParser</td><td><tt>.a</tt></td>
- <td>LLVM assembly parsing</td></tr>
- <tr><td>LLVMBCReader</td><td><tt>.a</tt></td>
- <td>LLVM bitcode reading</td></tr>
- <tr><td>LLVMBCWriter</td><td><tt>.a</tt></td>
- <td>LLVM bitcode writing</td></tr>
- <tr><td>LLVMCore</td><td><tt>.a</tt></td>
- <td>LLVM core intermediate representation</td></tr>
- <tr><td>LLVMDebugger</td><td><tt>.a</tt></td>
- <td>Source level debugging support</td></tr>
- <tr><td>LLVMLinker</td><td><tt>.a</tt></td>
- <td>Bitcode and archive linking interface</td></tr>
- <tr><td>LLVMSupport</td><td><tt>.a</tt></td>
- <td>General support utilities</td></tr>
- <tr><td>LLVMSystem</td><td><tt>.a</tt></td>
- <td>Operating system abstraction layer</td></tr>
- <tr><td>LLVMbzip2</td><td><tt>.a</tt></td>
- <td>BZip2 compression library</td></tr>
-
- <tr><th colspan="3">Analysis Libraries</th></tr>
- <tr><td>LLVMAnalysis</td><td><tt>.a</tt></td>
- <td>Various analysis passes.</td></tr>
- <tr><td>LLVMDataStructure</td><td><tt>.o</tt></td>
- <td>Data structure analysis passes.</td></tr>
- <tr><td>LLVMipa</td><td><tt>.a</tt></td>
- <td>Inter-procedural analysis passes.</td></tr>
-
- <tr><th colspan="3">Transformation Libraries</th></tr>
- <tr><td>LLVMInstrumentation</td><td><tt>.a</tt></td>
- <td>Instrumentation passes.</td></tr>
- <tr><td>LLVMipo</td><td><tt>.a</tt></td>
- <td>All inter-procedural optimization passes.</td></tr>
- <tr><td>LLVMScalarOpts</td><td><tt>.a</tt></td>
- <td>All scalar optimization passes.</td></tr>
- <tr><td>LLVMTransformUtils</td><td><tt>.a</tt></td>
- <td>Transformation utilities used by many passes.</td></tr>
-
- <tr><th colspan="3">Code Generation Libraries </th></tr>
- <tr><td>LLVMCodeGen</td><td><tt>.o</tt></td>
- <td>Native code generation infrastructure</td></tr>
- <tr><td>LLVMSelectionDAG</td><td><tt>.o</tt></td>
- <td>Aggressive instruction selector for directed acyclic graphs</td></tr>
-
- <tr><th colspan="3">Target Libraries</th></tr>
- <tr><td>LLVMAlpha</td><td><tt>.o</tt></td>
- <td>Code generation for Alpha architecture</td></tr>
- <tr><td>LLVMARM</td><td><tt>.o</tt></td>
- <td>Code generation for ARM architecture</td></tr>
- <tr><td>LLVMCBackend</td><td><tt>.o</tt></td>
- <td>'C' language code generator.</td></tr>
- <tr><td>LLVMPowerPC</td><td><tt>.o</tt></td>
- <td>Code generation for PowerPC architecture</td></tr>
- <tr><td>LLVMSparc</td><td><tt>.o</tt></td>
- <td>Code generation for Sparc architecture</td></tr>
- <tr><td>LLVMTarget</td><td><tt>.a</tt></td>
- <td>Generic code generation utilities.</td></tr>
- <tr><td>LLVMX86</td><td><tt>.o</tt></td>
- <td>Code generation for Intel x86 architecture</td></tr>
-
- <tr><th colspan="3">Runtime Libraries</th></tr>
- <tr><td>LLVMInterpreter</td><td><tt>.o</tt></td>
- <td>Bitcode Interpreter</td></tr>
- <tr><td>LLVMJIT</td><td><tt>.o</tt></td>
- <td>Bitcode JIT Compiler</td></tr>
- <tr><td>LLVMExecutionEngine</td><td><tt>.o</tt></td>
- <td>Virtual machine engine</td></tr>
-</table>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="dependencies"></a>Using llvm-config</div>
-<div class="doc_text">
- <p>The <tt>llvm-config</tt> tool is a perl script that produces on its output
- various kinds of information. For example, the source or object directories
- used to build LLVM can be accessed by passing options to <tt>llvm-config</tt>.
- For complete details on this tool, please see the
- <a href="CommandGuide/html/llvm-config.html">manual page</a>.</p>
- <p>To understand the relationships between libraries, the <tt>llvm-config</tt>
- can be very useful. If all you know is that you want certain libraries to
- be available, you can generate the complete set of libraries to link with
- using one of four options, as below:</p>
- <ol>
- <li><tt>--ldflags</tt>. This generates the command line options necessary to
- be passed to the <tt>ld</tt> tool in order to link with LLVM. Most notably,
- the <tt>-L</tt> option is provided to specify a library search directory
- that contains the LLVM libraries.</li>
- <li><tt>--libs</tt>. This generates command line options suitable for
- use with a gcc-style linker. That is, libraries are given with a -l option
- and object files are given with a full path.</li>
- <li><tt>--libnames</tt>. This generates a list of just the library file
- names. If you know the directory in which these files reside (see --ldflags)
- then you can find the libraries there.</li>
- <li><tt>--libfiles</tt>. This generates the full path names of the
- LLVM library files.</li>
- </ol>
- <p>If you wish to delve further into how <tt>llvm-config</tt> generates the
- correct order (based on library dependencies), please see the tool named
- <tt>GenLibDeps.pl</tt> in the <tt>utils</tt> source directory of LLVM.</p>
-
- <!-- =======NOTE: =========================================================-->
- <!-- === The following graphs and <dl> list are generated automatically ===-->
- <!-- === by the util named GenLibDeps.pl in the llvm/utils directory. ===-->
- <!-- === This should be updated whenever new libraries are added, ===-->
- <!-- === removed, or changed ===-->
- <!-- =======NOTE: =========================================================-->
- <h2>Dependency Relationships Of Libraries</h2>
- <p>This graph shows the dependency of archive libraries on other archive
- libraries or objects. Where a library has both archive and object forms, only
- the archive form is shown.</p>
- <img src="img/libdeps.gif" alt="Library Dependencies"/>
- <h2>Dependency Relationships Of Object Files</h2>
- <p>This graph shows the dependency of object files on archive libraries or
- other objects. Where a library has both object and archive forms, only the
- dependency to the archive form is shown.</p>
- <img src="img/objdeps.gif" alt="Object File Dependencies"/>
- <p>The following list shows the dependency relationships between libraries in
- textual form. The information is the same as shown on the graphs but arranged
- alphabetically.</p>
-<dl>
- <dt><b>libLLVMAnalysis.a</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>libLLVMArchive.a</b></dt><dd><ul>
- <li>libLLVMBCReader.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMAsmParser.a</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMBCReader.a</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMBCWriter.a</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMCodeGen.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMScalarOpts.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMTransformUtils.a</li>
- </ul></dd>
- <dt><b>libLLVMCore.a</b></dt><dd><ul>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMDebugger.a</b></dt><dd><ul>
- <li>libLLVMBCReader.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMInstrumentation.a</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMScalarOpts.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMTransformUtils.a</li>
- </ul></dd>
- <dt><b>libLLVMLinker.a</b></dt><dd><ul>
- <li>libLLVMArchive.a</li>
- <li>libLLVMBCReader.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMScalarOpts.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMTransformUtils.a</li>
- </ul></dd>
- <dt><b>libLLVMSelectionDAG.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMTransformUtils.a</li>
- </ul></dd>
- <dt><b>libLLVMSupport.a</b></dt><dd><ul>
- <li>libLLVMSystem.a</li>
- <li>libLLVMbzip2.a</li>
- </ul></dd>
- <dt><b>libLLVMSystem.a</b></dt><dd><ul>
- </ul></dd>
- <dt><b>libLLVMTarget.a</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMTransformUtils.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMipa.a</li>
- </ul></dd>
- <dt><b>libLLVMbzip2.a</b></dt><dd><ul>
- </ul></dd>
- <dt><b>libLLVMipa.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- </ul></dd>
- <dt><b>libLLVMipo.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMTransformUtils.a</li>
- <li>libLLVMipa.a</li>
- </ul></dd>
- <dt><b>libLLVMlto.a</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMBCReader.a</li>
- <li>libLLVMBCWriter.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMLinker.a</li>
- <li>libLLVMScalarOpts.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMipa.a</li>
- <li>libLLVMipo.a</li>
- </ul></dd>
- <dt><b>LLVMARM.o</b></dt><dd><ul>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSelectionDAG.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMAlpha.o</b></dt><dd><ul>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSelectionDAG.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMCBackend.o</b></dt><dd><ul>
- <li>libLLVMAnalysis.a</li>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMScalarOpts.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- <li>libLLVMTransformUtils.a</li>
- <li>libLLVMipa.a</li>
- </ul></dd>
- <dt><b>LLVMExecutionEngine.o</b></dt><dd><ul>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMInterpreter.o</b></dt><dd><ul>
- <li>LLVMExecutionEngine.o</li>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMJIT.o</b></dt><dd><ul>
- <li>LLVMExecutionEngine.o</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMPowerPC.o</b></dt><dd><ul>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSelectionDAG.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMSparc.o</b></dt><dd><ul>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSelectionDAG.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
- <dt><b>LLVMX86.o</b></dt><dd><ul>
- <li>libLLVMCodeGen.a</li>
- <li>libLLVMCore.a</li>
- <li>libLLVMSelectionDAG.a</li>
- <li>libLLVMSupport.a</li>
- <li>libLLVMSystem.a</li>
- <li>libLLVMTarget.a</li>
- </ul></dd>
-</dl>
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_section"><a name="rot">Linkage Rules Of Thumb</a></div>
-<div class="doc_text">
- <p>This section contains various "rules of thumb" about what files you
- should link into your programs.</p>
-</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="always">Always Link LLVMCore, LLVMSupport,
- and LLVMSystem</a></div>
-<div class="doc_text">
- <p>No matter what you do with LLVM, the last three entries in the value of
- your LLVMLIBS make variable should always be:
- <tt>LLVMCore LLVMSupport.a LLVMSystem.a</tt>. There are no <tt>LLVM</tt>
- programs that don't depend on these three.</p>
-</div>
-<!-- ======================================================================= -->
-<div class="doc_subsection"><a name="onlyone">Never link both archive and
- re-linked library</a></div>
-<div class="doc_text">
- <p>There is never any point to linking both the re-linked (<tt>.o</tt>) and
- the archive (<tt>.a</tt>) versions of a library. Since the re-linked version
- includes the entire library, the archive version will not resolve any symbols.
- You could even end up with link error if you place the archive version before
- the re-linked version on the linker's command line.</p>
-</div>
-<!-- ======================================================================= -->
-<hr>
-<div class="doc_footer">
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"/></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
- <a href="mailto:rspencer at x10sys.com">Reid Spencer</a>
-</address>
-<a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
-<br>Last modified: $Date$ </div>
-</body>
-</html>
-<!-- vim: sw=2 ts=2 ai
--->
Removed: llvm/trunk/docs/WritingAnLLVMBackend.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/WritingAnLLVMBackend.html?rev=103212&view=auto
==============================================================================
--- llvm/trunk/docs/WritingAnLLVMBackend.html (original)
+++ llvm/trunk/docs/WritingAnLLVMBackend.html (removed)
@@ -1,2561 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
- "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <title>Writing an LLVM Compiler Backend</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
-</head>
-
-<body>
-
-<div class="doc_title">
- Writing an LLVM Compiler Backend
-</div>
-
-<ol>
- <li><a href="#intro">Introduction</a>
- <ul>
- <li><a href="#Audience">Audience</a></li>
- <li><a href="#Prerequisite">Prerequisite Reading</a></li>
- <li><a href="#Basic">Basic Steps</a></li>
- <li><a href="#Preliminaries">Preliminaries</a></li>
- </ul>
- <li><a href="#TargetMachine">Target Machine</a></li>
- <li><a href="#TargetRegistration">Target Registration</a></li>
- <li><a href="#RegisterSet">Register Set and Register Classes</a>
- <ul>
- <li><a href="#RegisterDef">Defining a Register</a></li>
- <li><a href="#RegisterClassDef">Defining a Register Class</a></li>
- <li><a href="#implementRegister">Implement a subclass of TargetRegisterInfo</a></li>
- </ul></li>
- <li><a href="#InstructionSet">Instruction Set</a>
- <ul>
- <li><a href="#operandMapping">Instruction Operand Mapping</a></li>
- <li><a href="#implementInstr">Implement a subclass of TargetInstrInfo</a></li>
- <li><a href="#branchFolding">Branch Folding and If Conversion</a></li>
- </ul></li>
- <li><a href="#InstructionSelector">Instruction Selector</a>
- <ul>
- <li><a href="#LegalizePhase">The SelectionDAG Legalize Phase</a>
- <ul>
- <li><a href="#promote">Promote</a></li>
- <li><a href="#expand">Expand</a></li>
- <li><a href="#custom">Custom</a></li>
- <li><a href="#legal">Legal</a></li>
- </ul></li>
- <li><a href="#callingConventions">Calling Conventions</a></li>
- </ul></li>
- <li><a href="#assemblyPrinter">Assembly Printer</a></li>
- <li><a href="#subtargetSupport">Subtarget Support</a></li>
- <li><a href="#jitSupport">JIT Support</a>
- <ul>
- <li><a href="#mce">Machine Code Emitter</a></li>
- <li><a href="#targetJITInfo">Target JIT Info</a></li>
- </ul></li>
-</ol>
-
-<div class="doc_author">
- <p>Written by <a href="http://www.woo.com">Mason Woo</a> and
- <a href="http://misha.brukman.net">Misha Brukman</a></p>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="intro">Introduction</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-This document describes techniques for writing compiler backends that convert
-the LLVM Intermediate Representation (IR) to code for a specified machine or
-other languages. Code intended for a specific machine can take the form of
-either assembly code or binary code (usable for a JIT compiler).
-</p>
-
-<p>
-The backend of LLVM features a target-independent code generator that may create
-output for several types of target CPUs — including X86, PowerPC, Alpha,
-and SPARC. The backend may also be used to generate code targeted at SPUs of the
-Cell processor or GPUs to support the execution of compute kernels.
-</p>
-
-<p>
-The document focuses on existing examples found in subdirectories
-of <tt>llvm/lib/Target</tt> in a downloaded LLVM release. In particular, this
-document focuses on the example of creating a static compiler (one that emits
-text assembly) for a SPARC target, because SPARC has fairly standard
-characteristics, such as a RISC instruction set and straightforward calling
-conventions.
-</p>
-
-</div>
-
-<div class="doc_subsection">
- <a name="Audience">Audience</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The audience for this document is anyone who needs to write an LLVM backend to
-generate code for a specific hardware or software target.
-</p>
-
-</div>
-
-<div class="doc_subsection">
- <a name="Prerequisite">Prerequisite Reading</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-These essential documents must be read before reading this document:
-</p>
-
-<ul>
-<li><i><a href="http://www.llvm.org/docs/LangRef.html">LLVM Language Reference
- Manual</a></i> — a reference manual for the LLVM assembly language.</li>
-
-<li><i><a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM
- Target-Independent Code Generator</a></i> — a guide to the components
- (classes and code generation algorithms) for translating the LLVM internal
- representation into machine code for a specified target. Pay particular
- attention to the descriptions of code generation stages: Instruction
- Selection, Scheduling and Formation, SSA-based Optimization, Register
- Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations,
- and Code Emission.</li>
-
-<li><i><a href="http://www.llvm.org/docs/TableGenFundamentals.html">TableGen
- Fundamentals</a></i> —a document that describes the TableGen
- (<tt>tblgen</tt>) application that manages domain-specific information to
- support LLVM code generation. TableGen processes input from a target
- description file (<tt>.td</tt> suffix) and generates C++ code that can be
- used for code generation.</li>
-
-<li><i><a href="http://www.llvm.org/docs/WritingAnLLVMPass.html">Writing an LLVM
- Pass</a></i> — The assembly printer is a <tt>FunctionPass</tt>, as are
- several SelectionDAG processing steps.</li>
-</ul>
-
-<p>
-To follow the SPARC examples in this document, have a copy of
-<i><a href="http://www.sparc.org/standards/V8.pdf">The SPARC Architecture
-Manual, Version 8</a></i> for reference. For details about the ARM instruction
-set, refer to the <i><a href="http://infocenter.arm.com/">ARM Architecture
-Reference Manual</a></i>. For more about the GNU Assembler format
-(<tt>GAS</tt>), see
-<i><a href="http://sourceware.org/binutils/docs/as/index.html">Using As</a></i>,
-especially for the assembly printer. <i>Using As</i> contains a list of target
-machine dependent features.
-</p>
-
-</div>
-
-<div class="doc_subsection">
- <a name="Basic">Basic Steps</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-To write a compiler backend for LLVM that converts the LLVM IR to code for a
-specified target (machine or other language), follow these steps:
-</p>
-
-<ul>
-<li>Create a subclass of the TargetMachine class that describes characteristics
- of your target machine. Copy existing examples of specific TargetMachine
- class and header files; for example, start with
- <tt>SparcTargetMachine.cpp</tt> and <tt>SparcTargetMachine.h</tt>, but
- change the file names for your target. Similarly, change code that
- references "Sparc" to reference your target. </li>
-
-<li>Describe the register set of the target. Use TableGen to generate code for
- register definition, register aliases, and register classes from a
- target-specific <tt>RegisterInfo.td</tt> input file. You should also write
- additional code for a subclass of the TargetRegisterInfo class that
- represents the class register file data used for register allocation and
- also describes the interactions between registers.</li>
-
-<li>Describe the instruction set of the target. Use TableGen to generate code
- for target-specific instructions from target-specific versions of
- <tt>TargetInstrFormats.td</tt> and <tt>TargetInstrInfo.td</tt>. You should
- write additional code for a subclass of the TargetInstrInfo class to
- represent machine instructions supported by the target machine. </li>
-
-<li>Describe the selection and conversion of the LLVM IR from a Directed Acyclic
- Graph (DAG) representation of instructions to native target-specific
- instructions. Use TableGen to generate code that matches patterns and
- selects instructions based on additional information in a target-specific
- version of <tt>TargetInstrInfo.td</tt>. Write code
- for <tt>XXXISelDAGToDAG.cpp</tt>, where XXX identifies the specific target,
- to perform pattern matching and DAG-to-DAG instruction selection. Also write
- code in <tt>XXXISelLowering.cpp</tt> to replace or remove operations and
- data types that are not supported natively in a SelectionDAG. </li>
-
-<li>Write code for an assembly printer that converts LLVM IR to a GAS format for
- your target machine. You should add assembly strings to the instructions
- defined in your target-specific version of <tt>TargetInstrInfo.td</tt>. You
- should also write code for a subclass of AsmPrinter that performs the
- LLVM-to-assembly conversion and a trivial subclass of TargetAsmInfo.</li>
-
-<li>Optionally, add support for subtargets (i.e., variants with different
- capabilities). You should also write code for a subclass of the
- TargetSubtarget class, which allows you to use the <tt>-mcpu=</tt>
- and <tt>-mattr=</tt> command-line options.</li>
-
-<li>Optionally, add JIT support and create a machine code emitter (subclass of
- TargetJITInfo) that is used to emit binary code directly into memory. </li>
-</ul>
-
-<p>
-In the <tt>.cpp</tt> and <tt>.h</tt>. files, initially stub up these methods and
-then implement them later. Initially, you may not know which private members
-that the class will need and which components will need to be subclassed.
-</p>
-
-</div>
-
-<div class="doc_subsection">
- <a name="Preliminaries">Preliminaries</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-To actually create your compiler backend, you need to create and modify a few
-files. The absolute minimum is discussed here. But to actually use the LLVM
-target-independent code generator, you must perform the steps described in
-the <a href="http://www.llvm.org/docs/CodeGenerator.html">LLVM
-Target-Independent Code Generator</a> document.
-</p>
-
-<p>
-First, you should create a subdirectory under <tt>lib/Target</tt> to hold all
-the files related to your target. If your target is called "Dummy," create the
-directory <tt>lib/Target/Dummy</tt>.
-</p>
-
-<p>
-In this new
-directory, create a <tt>Makefile</tt>. It is easiest to copy a
-<tt>Makefile</tt> of another target and modify it. It should at least contain
-the <tt>LEVEL</tt>, <tt>LIBRARYNAME</tt> and <tt>TARGET</tt> variables, and then
-include <tt>$(LEVEL)/Makefile.common</tt>. The library can be
-named <tt>LLVMDummy</tt> (for example, see the MIPS target). Alternatively, you
-can split the library into <tt>LLVMDummyCodeGen</tt>
-and <tt>LLVMDummyAsmPrinter</tt>, the latter of which should be implemented in a
-subdirectory below <tt>lib/Target/Dummy</tt> (for example, see the PowerPC
-target).
-</p>
-
-<p>
-Note that these two naming schemes are hardcoded into <tt>llvm-config</tt>.
-Using any other naming scheme will confuse <tt>llvm-config</tt> and produce a
-lot of (seemingly unrelated) linker errors when linking <tt>llc</tt>.
-</p>
-
-<p>
-To make your target actually do something, you need to implement a subclass of
-<tt>TargetMachine</tt>. This implementation should typically be in the file
-<tt>lib/Target/DummyTargetMachine.cpp</tt>, but any file in
-the <tt>lib/Target</tt> directory will be built and should work. To use LLVM's
-target independent code generator, you should do what all current machine
-backends do: create a subclass of <tt>LLVMTargetMachine</tt>. (To create a
-target from scratch, create a subclass of <tt>TargetMachine</tt>.)
-</p>
-
-<p>
-To get LLVM to actually build and link your target, you need to add it to
-the <tt>TARGETS_TO_BUILD</tt> variable. To do this, you modify the configure
-script to know about your target when parsing the <tt>--enable-targets</tt>
-option. Search the configure script for <tt>TARGETS_TO_BUILD</tt>, add your
-target to the lists there (some creativity required), and then
-reconfigure. Alternatively, you can change <tt>autotools/configure.ac</tt> and
-regenerate configure by running <tt>./autoconf/AutoRegen.sh</tt>.
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="TargetMachine">Target Machine</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-<tt>LLVMTargetMachine</tt> is designed as a base class for targets implemented
-with the LLVM target-independent code generator. The <tt>LLVMTargetMachine</tt>
-class should be specialized by a concrete target class that implements the
-various virtual methods. <tt>LLVMTargetMachine</tt> is defined as a subclass of
-<tt>TargetMachine</tt> in <tt>include/llvm/Target/TargetMachine.h</tt>. The
-<tt>TargetMachine</tt> class implementation (<tt>TargetMachine.cpp</tt>) also
-processes numerous command-line options.
-</p>
-
-<p>
-To create a concrete target-specific subclass of <tt>LLVMTargetMachine</tt>,
-start by copying an existing <tt>TargetMachine</tt> class and header. You
-should name the files that you create to reflect your specific target. For
-instance, for the SPARC target, name the files <tt>SparcTargetMachine.h</tt> and
-<tt>SparcTargetMachine.cpp</tt>.
-</p>
-
-<p>
-For a target machine <tt>XXX</tt>, the implementation of
-<tt>XXXTargetMachine</tt> must have access methods to obtain objects that
-represent target components. These methods are named <tt>get*Info</tt>, and are
-intended to obtain the instruction set (<tt>getInstrInfo</tt>), register set
-(<tt>getRegisterInfo</tt>), stack frame layout (<tt>getFrameInfo</tt>), and
-similar information. <tt>XXXTargetMachine</tt> must also implement the
-<tt>getTargetData</tt> method to access an object with target-specific data
-characteristics, such as data type size and alignment requirements.
-</p>
-
-<p>
-For instance, for the SPARC target, the header file
-<tt>SparcTargetMachine.h</tt> declares prototypes for several <tt>get*Info</tt>
-and <tt>getTargetData</tt> methods that simply return a class member.
-</p>
-
-<div class="doc_code">
-<pre>
-namespace llvm {
-
-class Module;
-
-class SparcTargetMachine : public LLVMTargetMachine {
- const TargetData DataLayout; // Calculates type size & alignment
- SparcSubtarget Subtarget;
- SparcInstrInfo InstrInfo;
- TargetFrameInfo FrameInfo;
-
-protected:
- virtual const TargetAsmInfo *createTargetAsmInfo() const;
-
-public:
- SparcTargetMachine(const Module &M, const std::string &FS);
-
- virtual const SparcInstrInfo *getInstrInfo() const {return &InstrInfo; }
- virtual const TargetFrameInfo *getFrameInfo() const {return &FrameInfo; }
- virtual const TargetSubtarget *getSubtargetImpl() const{return &Subtarget; }
- virtual const TargetRegisterInfo *getRegisterInfo() const {
- return &InstrInfo.getRegisterInfo();
- }
- virtual const TargetData *getTargetData() const { return &DataLayout; }
- static unsigned getModuleMatchQuality(const Module &M);
-
- // Pass Pipeline Configuration
- virtual bool addInstSelector(PassManagerBase &PM, bool Fast);
- virtual bool addPreEmitPass(PassManagerBase &PM, bool Fast);
-};
-
-} // end namespace llvm
-</pre>
-</div>
-
-</div>
-
-
-<div class="doc_text">
-
-<ul>
-<li><tt>getInstrInfo()</tt></li>
-<li><tt>getRegisterInfo()</tt></li>
-<li><tt>getFrameInfo()</tt></li>
-<li><tt>getTargetData()</tt></li>
-<li><tt>getSubtargetImpl()</tt></li>
-</ul>
-
-<p>For some targets, you also need to support the following methods:</p>
-
-<ul>
-<li><tt>getTargetLowering()</tt></li>
-<li><tt>getJITInfo()</tt></li>
-</ul>
-
-<p>
-In addition, the <tt>XXXTargetMachine</tt> constructor should specify a
-<tt>TargetDescription</tt> string that determines the data layout for the target
-machine, including characteristics such as pointer size, alignment, and
-endianness. For example, the constructor for SparcTargetMachine contains the
-following:
-</p>
-
-<div class="doc_code">
-<pre>
-SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &FS)
- : DataLayout("E-p:32:32-f128:128:128"),
- Subtarget(M, FS), InstrInfo(Subtarget),
- FrameInfo(TargetFrameInfo::StackGrowsDown, 8, 0) {
-}
-</pre>
-</div>
-
-</div>
-
-<div class="doc_text">
-
-<p>Hyphens separate portions of the <tt>TargetDescription</tt> string.</p>
-
-<ul>
-<li>An upper-case "<tt>E</tt>" in the string indicates a big-endian target data
- model. a lower-case "<tt>e</tt>" indicates little-endian.</li>
-
-<li>"<tt>p:</tt>" is followed by pointer information: size, ABI alignment, and
- preferred alignment. If only two figures follow "<tt>p:</tt>", then the
- first value is pointer size, and the second value is both ABI and preferred
- alignment.</li>
-
-<li>Then a letter for numeric type alignment: "<tt>i</tt>", "<tt>f</tt>",
- "<tt>v</tt>", or "<tt>a</tt>" (corresponding to integer, floating point,
- vector, or aggregate). "<tt>i</tt>", "<tt>v</tt>", or "<tt>a</tt>" are
- followed by ABI alignment and preferred alignment. "<tt>f</tt>" is followed
- by three values: the first indicates the size of a long double, then ABI
- alignment, and then ABI preferred alignment.</li>
-</ul>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="TargetRegistration">Target Registration</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-You must also register your target with the <tt>TargetRegistry</tt>, which is
-what other LLVM tools use to be able to lookup and use your target at
-runtime. The <tt>TargetRegistry</tt> can be used directly, but for most targets
-there are helper templates which should take care of the work for you.</p>
-
-<p>
-All targets should declare a global <tt>Target</tt> object which is used to
-represent the target during registration. Then, in the target's TargetInfo
-library, the target should define that object and use
-the <tt>RegisterTarget</tt> template to register the target. For example, the Sparc registration code looks like this:
-</p>
-
-<div class="doc_code">
-<pre>
-Target llvm::TheSparcTarget;
-
-extern "C" void LLVMInitializeSparcTargetInfo() {
- RegisterTarget<Triple::sparc, /*HasJIT=*/false>
- X(TheSparcTarget, "sparc", "Sparc");
-}
-</pre>
-</div>
-
-<p>
-This allows the <tt>TargetRegistry</tt> to look up the target by name or by
-target triple. In addition, most targets will also register additional features
-which are available in separate libraries. These registration steps are
-separate, because some clients may wish to only link in some parts of the target
--- the JIT code generator does not require the use of the assembler printer, for
-example. Here is an example of registering the Sparc assembly printer:
-</p>
-
-<div class="doc_code">
-<pre>
-extern "C" void LLVMInitializeSparcAsmPrinter() {
- RegisterAsmPrinter<SparcAsmPrinter> X(TheSparcTarget);
-}
-</pre>
-</div>
-
-<p>
-For more information, see
-"<a href="/doxygen/TargetRegistry_8h-source.html">llvm/Target/TargetRegistry.h</a>".
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="RegisterSet">Register Set and Register Classes</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-You should describe a concrete target-specific class that represents the
-register file of a target machine. This class is called <tt>XXXRegisterInfo</tt>
-(where <tt>XXX</tt> identifies the target) and represents the class register
-file data that is used for register allocation. It also describes the
-interactions between registers.
-</p>
-
-<p>
-You also need to define register classes to categorize related registers. A
-register class should be added for groups of registers that are all treated the
-same way for some instruction. Typical examples are register classes for
-integer, floating-point, or vector registers. A register allocator allows an
-instruction to use any register in a specified register class to perform the
-instruction in a similar manner. Register classes allocate virtual registers to
-instructions from these sets, and register classes let the target-independent
-register allocator automatically choose the actual registers.
-</p>
-
-<p>
-Much of the code for registers, including register definition, register aliases,
-and register classes, is generated by TableGen from <tt>XXXRegisterInfo.td</tt>
-input files and placed in <tt>XXXGenRegisterInfo.h.inc</tt> and
-<tt>XXXGenRegisterInfo.inc</tt> output files. Some of the code in the
-implementation of <tt>XXXRegisterInfo</tt> requires hand-coding.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="RegisterDef">Defining a Register</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The <tt>XXXRegisterInfo.td</tt> file typically starts with register definitions
-for a target machine. The <tt>Register</tt> class (specified
-in <tt>Target.td</tt>) is used to define an object for each register. The
-specified string <tt>n</tt> becomes the <tt>Name</tt> of the register. The
-basic <tt>Register</tt> object does not have any subregisters and does not
-specify any aliases.
-</p>
-
-<div class="doc_code">
-<pre>
-class Register<string n> {
- string Namespace = "";
- string AsmName = n;
- string Name = n;
- int SpillSize = 0;
- int SpillAlignment = 0;
- list<Register> Aliases = [];
- list<Register> SubRegs = [];
- list<int> DwarfNumbers = [];
-}
-</pre>
-</div>
-
-<p>
-For example, in the <tt>X86RegisterInfo.td</tt> file, there are register
-definitions that utilize the Register class, such as:
-</p>
-
-<div class="doc_code">
-<pre>
-def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;
-</pre>
-</div>
-
-<p>
-This defines the register <tt>AL</tt> and assigns it values (with
-<tt>DwarfRegNum</tt>) that are used by <tt>gcc</tt>, <tt>gdb</tt>, or a debug
-information writer to identify a register. For register
-<tt>AL</tt>, <tt>DwarfRegNum</tt> takes an array of 3 values representing 3
-different modes: the first element is for X86-64, the second for exception
-handling (EH) on X86-32, and the third is generic. -1 is a special Dwarf number
-that indicates the gcc number is undefined, and -2 indicates the register number
-is invalid for this mode.
-</p>
-
-<p>
-From the previously described line in the <tt>X86RegisterInfo.td</tt> file,
-TableGen generates this code in the <tt>X86GenRegisterInfo.inc</tt> file:
-</p>
-
-<div class="doc_code">
-<pre>
-static const unsigned GR8[] = { X86::AL, ... };
-
-const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 };
-
-const TargetRegisterDesc RegisterDescriptors[] = {
- ...
-{ "AL", "AL", AL_AliasSet, Empty_SubRegsSet, Empty_SubRegsSet, AL_SuperRegsSet }, ...
-</pre>
-</div>
-
-<p>
-From the register info file, TableGen generates a <tt>TargetRegisterDesc</tt>
-object for each register. <tt>TargetRegisterDesc</tt> is defined in
-<tt>include/llvm/Target/TargetRegisterInfo.h</tt> with the following fields:
-</p>
-
-<div class="doc_code">
-<pre>
-struct TargetRegisterDesc {
- const char *AsmName; // Assembly language name for the register
- const char *Name; // Printable name for the reg (for debugging)
- const unsigned *AliasSet; // Register Alias Set
- const unsigned *SubRegs; // Sub-register set
- const unsigned *ImmSubRegs; // Immediate sub-register set
- const unsigned *SuperRegs; // Super-register set
-};</pre>
-</div>
-
-<p>
-TableGen uses the entire target description file (<tt>.td</tt>) to determine
-text names for the register (in the <tt>AsmName</tt> and <tt>Name</tt> fields of
-<tt>TargetRegisterDesc</tt>) and the relationships of other registers to the
-defined register (in the other <tt>TargetRegisterDesc</tt> fields). In this
-example, other definitions establish the registers "<tt>AX</tt>",
-"<tt>EAX</tt>", and "<tt>RAX</tt>" as aliases for one another, so TableGen
-generates a null-terminated array (<tt>AL_AliasSet</tt>) for this register alias
-set.
-</p>
-
-<p>
-The <tt>Register</tt> class is commonly used as a base class for more complex
-classes. In <tt>Target.td</tt>, the <tt>Register</tt> class is the base for the
-<tt>RegisterWithSubRegs</tt> class that is used to define registers that need to
-specify subregisters in the <tt>SubRegs</tt> list, as shown here:
-</p>
-
-<div class="doc_code">
-<pre>
-class RegisterWithSubRegs<string n,
-list<Register> subregs> : Register<n> {
- let SubRegs = subregs;
-}
-</pre>
-</div>
-
-<p>
-In <tt>SparcRegisterInfo.td</tt>, additional register classes are defined for
-SPARC: a Register subclass, SparcReg, and further subclasses: <tt>Ri</tt>,
-<tt>Rf</tt>, and <tt>Rd</tt>. SPARC registers are identified by 5-bit ID
-numbers, which is a feature common to these subclasses. Note the use of
-'<tt>let</tt>' expressions to override values that are initially defined in a
-superclass (such as <tt>SubRegs</tt> field in the <tt>Rd</tt> class).
-</p>
-
-<div class="doc_code">
-<pre>
-class SparcReg<string n> : Register<n> {
- field bits<5> Num;
- let Namespace = "SP";
-}
-// Ri - 32-bit integer registers
-class Ri<bits<5> num, string n> :
-SparcReg<n> {
- let Num = num;
-}
-// Rf - 32-bit floating-point registers
-class Rf<bits<5> num, string n> :
-SparcReg<n> {
- let Num = num;
-}
-// Rd - Slots in the FP register file for 64-bit
-floating-point values.
-class Rd<bits<5> num, string n,
-list<Register> subregs> : SparcReg<n> {
- let Num = num;
- let SubRegs = subregs;
-}
-</pre>
-</div>
-
-<p>
-In the <tt>SparcRegisterInfo.td</tt> file, there are register definitions that
-utilize these subclasses of <tt>Register</tt>, such as:
-</p>
-
-<div class="doc_code">
-<pre>
-def G0 : Ri< 0, "G0">,
-DwarfRegNum<[0]>;
-def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>;
-...
-def F0 : Rf< 0, "F0">,
-DwarfRegNum<[32]>;
-def F1 : Rf< 1, "F1">,
-DwarfRegNum<[33]>;
-...
-def D0 : Rd< 0, "F0", [F0, F1]>,
-DwarfRegNum<[32]>;
-def D1 : Rd< 2, "F2", [F2, F3]>,
-DwarfRegNum<[34]>;
-</pre>
-</div>
-
-<p>
-The last two registers shown above (<tt>D0</tt> and <tt>D1</tt>) are
-double-precision floating-point registers that are aliases for pairs of
-single-precision floating-point sub-registers. In addition to aliases, the
-sub-register and super-register relationships of the defined register are in
-fields of a register's TargetRegisterDesc.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="RegisterClassDef">Defining a Register Class</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The <tt>RegisterClass</tt> class (specified in <tt>Target.td</tt>) is used to
-define an object that represents a group of related registers and also defines
-the default allocation order of the registers. A target description file
-<tt>XXXRegisterInfo.td</tt> that uses <tt>Target.td</tt> can construct register
-classes using the following class:
-</p>
-
-<div class="doc_code">
-<pre>
-class RegisterClass<string namespace,
-list<ValueType> regTypes, int alignment,
- list<Register> regList> {
- string Namespace = namespace;
- list<ValueType> RegTypes = regTypes;
- int Size = 0; // spill size, in bits; zero lets tblgen pick the size
- int Alignment = alignment;
-
- // CopyCost is the cost of copying a value between two registers
- // default value 1 means a single instruction
- // A negative value means copying is extremely expensive or impossible
- int CopyCost = 1;
- list<Register> MemberList = regList;
-
- // for register classes that are subregisters of this class
- list<RegisterClass> SubRegClassList = [];
-
- code MethodProtos = [{}]; // to insert arbitrary code
- code MethodBodies = [{}];
-}
-</pre>
-</div>
-
-<p>To define a RegisterClass, use the following 4 arguments:</p>
-
-<ul>
-<li>The first argument of the definition is the name of the namespace.</li>
-
-<li>The second argument is a list of <tt>ValueType</tt> register type values
- that are defined in <tt>include/llvm/CodeGen/ValueTypes.td</tt>. Defined
- values include integer types (such as <tt>i16</tt>, <tt>i32</tt>,
- and <tt>i1</tt> for Boolean), floating-point types
- (<tt>f32</tt>, <tt>f64</tt>), and vector types (for example, <tt>v8i16</tt>
- for an <tt>8 x i16</tt> vector). All registers in a <tt>RegisterClass</tt>
- must have the same <tt>ValueType</tt>, but some registers may store vector
- data in different configurations. For example a register that can process a
- 128-bit vector may be able to handle 16 8-bit integer elements, 8 16-bit
- integers, 4 32-bit integers, and so on. </li>
-
-<li>The third argument of the <tt>RegisterClass</tt> definition specifies the
- alignment required of the registers when they are stored or loaded to
- memory.</li>
-
-<li>The final argument, <tt>regList</tt>, specifies which registers are in this
- class. If an <tt>allocation_order_*</tt> method is not specified,
- then <tt>regList</tt> also defines the order of allocation used by the
- register allocator.</li>
-</ul>
-
-<p>
-In <tt>SparcRegisterInfo.td</tt>, three RegisterClass objects are defined:
-<tt>FPRegs</tt>, <tt>DFPRegs</tt>, and <tt>IntRegs</tt>. For all three register
-classes, the first argument defines the namespace with the string
-'<tt>SP</tt>'. <tt>FPRegs</tt> defines a group of 32 single-precision
-floating-point registers (<tt>F0</tt> to <tt>F31</tt>); <tt>DFPRegs</tt> defines
-a group of 16 double-precision registers
-(<tt>D0-D15</tt>). For <tt>IntRegs</tt>, the <tt>MethodProtos</tt>
-and <tt>MethodBodies</tt> methods are used by TableGen to insert the specified
-code into generated output.
-</p>
-
-<div class="doc_code">
-<pre>
-def FPRegs : RegisterClass<"SP", [f32], 32,
- [F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15,
- F16, F17, F18, F19, F20, F21, F22, F23, F24, F25, F26, F27, F28, F29, F30, F31]>;
-
-def DFPRegs : RegisterClass<"SP", [f64], 64,
- [D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15]>;
-
-def IntRegs : RegisterClass<"SP", [i32], 32,
- [L0, L1, L2, L3, L4, L5, L6, L7,
- I0, I1, I2, I3, I4, I5,
- O0, O1, O2, O3, O4, O5, O7,
- G1,
- // Non-allocatable regs:
- G2, G3, G4,
- O6, // stack ptr
- I6, // frame ptr
- I7, // return address
- G0, // constant zero
- G5, G6, G7 // reserved for kernel
- ]> {
- let MethodProtos = [{
- iterator allocation_order_end(const MachineFunction &MF) const;
- }];
- let MethodBodies = [{
- IntRegsClass::iterator
- IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
- return end() - 10 // Don't allocate special registers
- -1;
- }
- }];
-}
-</pre>
-</div>
-
-<p>
-Using <tt>SparcRegisterInfo.td</tt> with TableGen generates several output files
-that are intended for inclusion in other source code that you write.
-<tt>SparcRegisterInfo.td</tt> generates <tt>SparcGenRegisterInfo.h.inc</tt>,
-which should be included in the header file for the implementation of the SPARC
-register implementation that you write (<tt>SparcRegisterInfo.h</tt>). In
-<tt>SparcGenRegisterInfo.h.inc</tt> a new structure is defined called
-<tt>SparcGenRegisterInfo</tt> that uses <tt>TargetRegisterInfo</tt> as its
-base. It also specifies types, based upon the defined register
-classes: <tt>DFPRegsClass</tt>, <tt>FPRegsClass</tt>, and <tt>IntRegsClass</tt>.
-</p>
-
-<p>
-<tt>SparcRegisterInfo.td</tt> also generates <tt>SparcGenRegisterInfo.inc</tt>,
-which is included at the bottom of <tt>SparcRegisterInfo.cpp</tt>, the SPARC
-register implementation. The code below shows only the generated integer
-registers and associated register classes. The order of registers
-in <tt>IntRegs</tt> reflects the order in the definition of <tt>IntRegs</tt> in
-the target description file. Take special note of the use
-of <tt>MethodBodies</tt> in <tt>SparcRegisterInfo.td</tt> to create code in
-<tt>SparcGenRegisterInfo.inc</tt>. <tt>MethodProtos</tt> generates similar code
-in <tt>SparcGenRegisterInfo.h.inc</tt>.
-</p>
-
-<div class="doc_code">
-<pre> // IntRegs Register Class...
- static const unsigned IntRegs[] = {
- SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5,
- SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3,
- SP::I4, SP::I5, SP::O0, SP::O1, SP::O2, SP::O3,
- SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3,
- SP::G4, SP::O6, SP::I6, SP::I7, SP::G0, SP::G5,
- SP::G6, SP::G7,
- };
-
- // IntRegsVTs Register Class Value Types...
- static const MVT::ValueType IntRegsVTs[] = {
- MVT::i32, MVT::Other
- };
-
-namespace SP { // Register class instances
- DFPRegsClass DFPRegsRegClass;
- FPRegsClass FPRegsRegClass;
- IntRegsClass IntRegsRegClass;
-...
- // IntRegs Sub-register Classess...
- static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
- NULL
- };
-...
- // IntRegs Super-register Classess...
- static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
- NULL
- };
-...
- // IntRegs Register Class sub-classes...
- static const TargetRegisterClass* const IntRegsSubclasses [] = {
- NULL
- };
-...
- // IntRegs Register Class super-classes...
- static const TargetRegisterClass* const IntRegsSuperclasses [] = {
- NULL
- };
-...
- IntRegsClass::iterator
- IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
- return end()-10 // Don't allocate special registers
- -1;
- }
-
- IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID,
- IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses,
- IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {}
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="implementRegister">Implement a subclass of</a>
- <a href="http://www.llvm.org/docs/CodeGenerator.html#targetregisterinfo">TargetRegisterInfo</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The final step is to hand code portions of <tt>XXXRegisterInfo</tt>, which
-implements the interface described in <tt>TargetRegisterInfo.h</tt>. These
-functions return <tt>0</tt>, <tt>NULL</tt>, or <tt>false</tt>, unless
-overridden. Here is a list of functions that are overridden for the SPARC
-implementation in <tt>SparcRegisterInfo.cpp</tt>:
-</p>
-
-<ul>
-<li><tt>getCalleeSavedRegs</tt> — Returns a list of callee-saved registers
- in the order of the desired callee-save stack frame offset.</li>
-
-<li><tt>getCalleeSavedRegClasses</tt> — Returns a list of preferred
- register classes with which to spill each callee saved register.</li>
-
-<li><tt>getReservedRegs</tt> — Returns a bitset indexed by physical
- register numbers, indicating if a particular register is unavailable.</li>
-
-<li><tt>hasFP</tt> — Return a Boolean indicating if a function should have
- a dedicated frame pointer register.</li>
-
-<li><tt>eliminateCallFramePseudoInstr</tt> — If call frame setup or
- destroy pseudo instructions are used, this can be called to eliminate
- them.</li>
-
-<li><tt>eliminateFrameIndex</tt> — Eliminate abstract frame indices from
- instructions that may use them.</li>
-
-<li><tt>emitPrologue</tt> — Insert prologue code into the function.</li>
-
-<li><tt>emitEpilogue</tt> — Insert epilogue code into the function.</li>
-</ul>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="InstructionSet">Instruction Set</a>
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_text">
-
-<p>
-During the early stages of code generation, the LLVM IR code is converted to a
-<tt>SelectionDAG</tt> with nodes that are instances of the <tt>SDNode</tt> class
-containing target instructions. An <tt>SDNode</tt> has an opcode, operands, type
-requirements, and operation properties. For example, is an operation
-commutative, does an operation load from memory. The various operation node
-types are described in the <tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>
-file (values of the <tt>NodeType</tt> enum in the <tt>ISD</tt> namespace).
-</p>
-
-<p>
-TableGen uses the following target description (<tt>.td</tt>) input files to
-generate much of the code for instruction definition:
-</p>
-
-<ul>
-<li><tt>Target.td</tt> — Where the <tt>Instruction</tt>, <tt>Operand</tt>,
- <tt>InstrInfo</tt>, and other fundamental classes are defined.</li>
-
-<li><tt>TargetSelectionDAG.td</tt>— Used by <tt>SelectionDAG</tt>
- instruction selection generators, contains <tt>SDTC*</tt> classes (selection
- DAG type constraint), definitions of <tt>SelectionDAG</tt> nodes (such as
- <tt>imm</tt>, <tt>cond</tt>, <tt>bb</tt>, <tt>add</tt>, <tt>fadd</tt>,
- <tt>sub</tt>), and pattern support (<tt>Pattern</tt>, <tt>Pat</tt>,
- <tt>PatFrag</tt>, <tt>PatLeaf</tt>, <tt>ComplexPattern</tt>.</li>
-
-<li><tt>XXXInstrFormats.td</tt> — Patterns for definitions of
- target-specific instructions.</li>
-
-<li><tt>XXXInstrInfo.td</tt> — Target-specific definitions of instruction
- templates, condition codes, and instructions of an instruction set. For
- architecture modifications, a different file name may be used. For example,
- for Pentium with SSE instruction, this file is <tt>X86InstrSSE.td</tt>, and
- for Pentium with MMX, this file is <tt>X86InstrMMX.td</tt>.</li>
-</ul>
-
-<p>
-There is also a target-specific <tt>XXX.td</tt> file, where <tt>XXX</tt> is the
-name of the target. The <tt>XXX.td</tt> file includes the other <tt>.td</tt>
-input files, but its contents are only directly important for subtargets.
-</p>
-
-<p>
-You should describe a concrete target-specific class <tt>XXXInstrInfo</tt> that
-represents machine instructions supported by a target machine.
-<tt>XXXInstrInfo</tt> contains an array of <tt>XXXInstrDescriptor</tt> objects,
-each of which describes one instruction. An instruction descriptor defines:</p>
-
-<ul>
-<li>Opcode mnemonic</li>
-
-<li>Number of operands</li>
-
-<li>List of implicit register definitions and uses</li>
-
-<li>Target-independent properties (such as memory access, is commutable)</li>
-
-<li>Target-specific flags </li>
-</ul>
-
-<p>
-The Instruction class (defined in <tt>Target.td</tt>) is mostly used as a base
-for more complex instruction classes.
-</p>
-
-<div class="doc_code">
-<pre>class Instruction {
- string Namespace = "";
- dag OutOperandList; // An dag containing the MI def operand list.
- dag InOperandList; // An dag containing the MI use operand list.
- string AsmString = ""; // The .s format to print the instruction with.
- list<dag> Pattern; // Set to the DAG pattern for this instruction
- list<Register> Uses = [];
- list<Register> Defs = [];
- list<Predicate> Predicates = []; // predicates turned into isel match code
- ... remainder not shown for space ...
-}
-</pre>
-</div>
-
-<p>
-A <tt>SelectionDAG</tt> node (<tt>SDNode</tt>) should contain an object
-representing a target-specific instruction that is defined
-in <tt>XXXInstrInfo.td</tt>. The instruction objects should represent
-instructions from the architecture manual of the target machine (such as the
-SPARC Architecture Manual for the SPARC target).
-</p>
-
-<p>
-A single instruction from the architecture manual is often modeled as multiple
-target instructions, depending upon its operands. For example, a manual might
-describe an add instruction that takes a register or an immediate operand. An
-LLVM target could model this with two instructions named <tt>ADDri</tt> and
-<tt>ADDrr</tt>.
-</p>
-
-<p>
-You should define a class for each instruction category and define each opcode
-as a subclass of the category with appropriate parameters such as the fixed
-binary encoding of opcodes and extended opcodes. You should map the register
-bits to the bits of the instruction in which they are encoded (for the
-JIT). Also you should specify how the instruction should be printed when the
-automatic assembly printer is used.
-</p>
-
-<p>
-As is described in the SPARC Architecture Manual, Version 8, there are three
-major 32-bit formats for instructions. Format 1 is only for the <tt>CALL</tt>
-instruction. Format 2 is for branch on condition codes and <tt>SETHI</tt> (set
-high bits of a register) instructions. Format 3 is for other instructions.
-</p>
-
-<p>
-Each of these formats has corresponding classes in <tt>SparcInstrFormat.td</tt>.
-<tt>InstSP</tt> is a base class for other instruction classes. Additional base
-classes are specified for more precise formats: for example
-in <tt>SparcInstrFormat.td</tt>, <tt>F2_1</tt> is for <tt>SETHI</tt>,
-and <tt>F2_2</tt> is for branches. There are three other base
-classes: <tt>F3_1</tt> for register/register operations, <tt>F3_2</tt> for
-register/immediate operations, and <tt>F3_3</tt> for floating-point
-operations. <tt>SparcInstrInfo.td</tt> also adds the base class Pseudo for
-synthetic SPARC instructions.
-</p>
-
-<p>
-<tt>SparcInstrInfo.td</tt> largely consists of operand and instruction
-definitions for the SPARC target. In <tt>SparcInstrInfo.td</tt>, the following
-target description file entry, <tt>LDrr</tt>, defines the Load Integer
-instruction for a Word (the <tt>LD</tt> SPARC opcode) from a memory address to a
-register. The first parameter, the value 3 (<tt>11<sub>2</sub></tt>), is the
-operation value for this category of operation. The second parameter
-(<tt>000000<sub>2</sub></tt>) is the specific operation value
-for <tt>LD</tt>/Load Word. The third parameter is the output destination, which
-is a register operand and defined in the <tt>Register</tt> target description
-file (<tt>IntRegs</tt>).
-</p>
-
-<div class="doc_code">
-<pre>def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
- "ld [$addr], $dst",
- [(set IntRegs:$dst, (load ADDRrr:$addr))]>;
-</pre>
-</div>
-
-<p>
-The fourth parameter is the input source, which uses the address
-operand <tt>MEMrr</tt> that is defined earlier in <tt>SparcInstrInfo.td</tt>:
-</p>
-
-<div class="doc_code">
-<pre>def MEMrr : Operand<i32> {
- let PrintMethod = "printMemOperand";
- let MIOperandInfo = (ops IntRegs, IntRegs);
-}
-</pre>
-</div>
-
-<p>
-The fifth parameter is a string that is used by the assembly printer and can be
-left as an empty string until the assembly printer interface is implemented. The
-sixth and final parameter is the pattern used to match the instruction during
-the SelectionDAG Select Phase described in
-(<a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM
-Target-Independent Code Generator</a>). This parameter is detailed in the next
-section, <a href="#InstructionSelector">Instruction Selector</a>.
-</p>
-
-<p>
-Instruction class definitions are not overloaded for different operand types, so
-separate versions of instructions are needed for register, memory, or immediate
-value operands. For example, to perform a Load Integer instruction for a Word
-from an immediate operand to a register, the following instruction class is
-defined:
-</p>
-
-<div class="doc_code">
-<pre>def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
- "ld [$addr], $dst",
- [(set IntRegs:$dst, (load ADDRri:$addr))]>;
-</pre>
-</div>
-
-<p>
-Writing these definitions for so many similar instructions can involve a lot of
-cut and paste. In td files, the <tt>multiclass</tt> directive enables the
-creation of templates to define several instruction classes at once (using
-the <tt>defm</tt> directive). For example in <tt>SparcInstrInfo.td</tt>, the
-<tt>multiclass</tt> pattern <tt>F3_12</tt> is defined to create 2 instruction
-classes each time <tt>F3_12</tt> is invoked:
-</p>
-
-<div class="doc_code">
-<pre>multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
- def rr : F3_1 <2, Op3Val,
- (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
- !strconcat(OpcStr, " $b, $c, $dst"),
- [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>;
- def ri : F3_2 <2, Op3Val,
- (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
- !strconcat(OpcStr, " $b, $c, $dst"),
- [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>;
-}
-</pre>
-</div>
-
-<p>
-So when the <tt>defm</tt> directive is used for the <tt>XOR</tt>
-and <tt>ADD</tt> instructions, as seen below, it creates four instruction
-objects: <tt>XORrr</tt>, <tt>XORri</tt>, <tt>ADDrr</tt>, and <tt>ADDri</tt>.
-</p>
-
-<div class="doc_code">
-<pre>
-defm XOR : F3_12<"xor", 0b000011, xor>;
-defm ADD : F3_12<"add", 0b000000, add>;
-</pre>
-</div>
-
-<p>
-<tt>SparcInstrInfo.td</tt> also includes definitions for condition codes that
-are referenced by branch instructions. The following definitions
-in <tt>SparcInstrInfo.td</tt> indicate the bit location of the SPARC condition
-code. For example, the 10<sup>th</sup> bit represents the 'greater than'
-condition for integers, and the 22<sup>nd</sup> bit represents the 'greater
-than' condition for floats.
-</p>
-
-<div class="doc_code">
-<pre>
-def ICC_NE : ICC_VAL< 9>; // Not Equal
-def ICC_E : ICC_VAL< 1>; // Equal
-def ICC_G : ICC_VAL<10>; // Greater
-...
-def FCC_U : FCC_VAL<23>; // Unordered
-def FCC_G : FCC_VAL<22>; // Greater
-def FCC_UG : FCC_VAL<21>; // Unordered or Greater
-...
-</pre>
-</div>
-
-<p>
-(Note that <tt>Sparc.h</tt> also defines enums that correspond to the same SPARC
-condition codes. Care must be taken to ensure the values in <tt>Sparc.h</tt>
-correspond to the values in <tt>SparcInstrInfo.td</tt>. I.e.,
-<tt>SPCC::ICC_NE = 9</tt>, <tt>SPCC::FCC_U = 23</tt> and so on.)
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="operandMapping">Instruction Operand Mapping</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The code generator backend maps instruction operands to fields in the
-instruction. Operands are assigned to unbound fields in the instruction in the
-order they are defined. Fields are bound when they are assigned a value. For
-example, the Sparc target defines the <tt>XNORrr</tt> instruction as
-a <tt>F3_1</tt> format instruction having three operands.
-</p>
-
-<div class="doc_code">
-<pre>
-def XNORrr : F3_1<2, 0b000111,
- (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
- "xnor $b, $c, $dst",
- [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]>;
-</pre>
-</div>
-
-<p>
-The instruction templates in <tt>SparcInstrFormats.td</tt> show the base class
-for <tt>F3_1</tt> is <tt>InstSP</tt>.
-</p>
-
-<div class="doc_code">
-<pre>
-class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
- field bits<32> Inst;
- let Namespace = "SP";
- bits<2> op;
- let Inst{31-30} = op;
- dag OutOperandList = outs;
- dag InOperandList = ins;
- let AsmString = asmstr;
- let Pattern = pattern;
-}
-</pre>
-</div>
-
-<p><tt>InstSP</tt> leaves the <tt>op</tt> field unbound.</p>
-
-<div class="doc_code">
-<pre>
-class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
- : InstSP<outs, ins, asmstr, pattern> {
- bits<5> rd;
- bits<6> op3;
- bits<5> rs1;
- let op{1} = 1; // Op = 2 or 3
- let Inst{29-25} = rd;
- let Inst{24-19} = op3;
- let Inst{18-14} = rs1;
-}
-</pre>
-</div>
-
-<p>
-<tt>F3</tt> binds the <tt>op</tt> field and defines the <tt>rd</tt>,
-<tt>op3</tt>, and <tt>rs1</tt> fields. <tt>F3</tt> format instructions will
-bind the operands <tt>rd</tt>, <tt>op3</tt>, and <tt>rs1</tt> fields.
-</p>
-
-<div class="doc_code">
-<pre>
-class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
- string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> {
- bits<8> asi = 0; // asi not currently used
- bits<5> rs2;
- let op = opVal;
- let op3 = op3val;
- let Inst{13} = 0; // i field = 0
- let Inst{12-5} = asi; // address space identifier
- let Inst{4-0} = rs2;
-}
-</pre>
-</div>
-
-<p>
-<tt>F3_1</tt> binds the <tt>op3</tt> field and defines the <tt>rs2</tt>
-fields. <tt>F3_1</tt> format instructions will bind the operands to the <tt>rd</tt>,
-<tt>rs1</tt>, and <tt>rs2</tt> fields. This results in the <tt>XNORrr</tt>
-instruction binding <tt>$dst</tt>, <tt>$b</tt>, and <tt>$c</tt> operands to
-the <tt>rd</tt>, <tt>rs1</tt>, and <tt>rs2</tt> fields respectively.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="implementInstr">Implement a subclass of </a>
- <a href="http://www.llvm.org/docs/CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The final step is to hand code portions of <tt>XXXInstrInfo</tt>, which
-implements the interface described in <tt>TargetInstrInfo.h</tt>. These
-functions return <tt>0</tt> or a Boolean or they assert, unless
-overridden. Here's a list of functions that are overridden for the SPARC
-implementation in <tt>SparcInstrInfo.cpp</tt>:
-</p>
-
-<ul>
-<li><tt>isMoveInstr</tt> — Return true if the instruction is a register to
- register move; false, otherwise.</li>
-
-<li><tt>isLoadFromStackSlot</tt> — If the specified machine instruction is
- a direct load from a stack slot, return the register number of the
- destination and the <tt>FrameIndex</tt> of the stack slot.</li>
-
-<li><tt>isStoreToStackSlot</tt> — If the specified machine instruction is
- a direct store to a stack slot, return the register number of the
- destination and the <tt>FrameIndex</tt> of the stack slot.</li>
-
-<li><tt>copyRegToReg</tt> — Copy values between a pair of registers.</li>
-
-<li><tt>storeRegToStackSlot</tt> — Store a register value to a stack
- slot.</li>
-
-<li><tt>loadRegFromStackSlot</tt> — Load a register value from a stack
- slot.</li>
-
-<li><tt>storeRegToAddr</tt> — Store a register value to memory.</li>
-
-<li><tt>loadRegFromAddr</tt> — Load a register value from memory.</li>
-
-<li><tt>foldMemoryOperand</tt> — Attempt to combine instructions of any
- load or store instruction for the specified operand(s).</li>
-</ul>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="branchFolding">Branch Folding and If Conversion</a>
-</div>
-<div class="doc_text">
-
-<p>
-Performance can be improved by combining instructions or by eliminating
-instructions that are never reached. The <tt>AnalyzeBranch</tt> method
-in <tt>XXXInstrInfo</tt> may be implemented to examine conditional instructions
-and remove unnecessary instructions. <tt>AnalyzeBranch</tt> looks at the end of
-a machine basic block (MBB) for opportunities for improvement, such as branch
-folding and if conversion. The <tt>BranchFolder</tt> and <tt>IfConverter</tt>
-machine function passes (see the source files <tt>BranchFolding.cpp</tt> and
-<tt>IfConversion.cpp</tt> in the <tt>lib/CodeGen</tt> directory) call
-<tt>AnalyzeBranch</tt> to improve the control flow graph that represents the
-instructions.
-</p>
-
-<p>
-Several implementations of <tt>AnalyzeBranch</tt> (for ARM, Alpha, and X86) can
-be examined as models for your own <tt>AnalyzeBranch</tt> implementation. Since
-SPARC does not implement a useful <tt>AnalyzeBranch</tt>, the ARM target
-implementation is shown below.
-</p>
-
-<p><tt>AnalyzeBranch</tt> returns a Boolean value and takes four parameters:</p>
-
-<ul>
-<li><tt>MachineBasicBlock &MBB</tt> — The incoming block to be
- examined.</li>
-
-<li><tt>MachineBasicBlock *&TBB</tt> — A destination block that is
- returned. For a conditional branch that evaluates to true, <tt>TBB</tt> is
- the destination.</li>
-
-<li><tt>MachineBasicBlock *&FBB</tt> — For a conditional branch that
- evaluates to false, <tt>FBB</tt> is returned as the destination.</li>
-
-<li><tt>std::vector<MachineOperand> &Cond</tt> — List of
- operands to evaluate a condition for a conditional branch.</li>
-</ul>
-
-<p>
-In the simplest case, if a block ends without a branch, then it falls through to
-the successor block. No destination blocks are specified for either <tt>TBB</tt>
-or <tt>FBB</tt>, so both parameters return <tt>NULL</tt>. The start of
-the <tt>AnalyzeBranch</tt> (see code below for the ARM target) shows the
-function parameters and the code for the simplest case.
-</p>
-
-<div class="doc_code">
-<pre>bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &MBB,
- MachineBasicBlock *&TBB, MachineBasicBlock *&FBB,
- std::vector<MachineOperand> &Cond) const
-{
- MachineBasicBlock::iterator I = MBB.end();
- if (I == MBB.begin() || !isUnpredicatedTerminator(--I))
- return false;
-</pre>
-</div>
-
-<p>
-If a block ends with a single unconditional branch instruction, then
-<tt>AnalyzeBranch</tt> (shown below) should return the destination of that
-branch in the <tt>TBB</tt> parameter.
-</p>
-
-<div class="doc_code">
-<pre>
- if (LastOpc == ARM::B || LastOpc == ARM::tB) {
- TBB = LastInst->getOperand(0).getMBB();
- return false;
- }
-</pre>
-</div>
-
-<p>
-If a block ends with two unconditional branches, then the second branch is never
-reached. In that situation, as shown below, remove the last branch instruction
-and return the penultimate branch in the <tt>TBB</tt> parameter.
-</p>
-
-<div class="doc_code">
-<pre>
- if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) &&
- (LastOpc == ARM::B || LastOpc == ARM::tB)) {
- TBB = SecondLastInst->getOperand(0).getMBB();
- I = LastInst;
- I->eraseFromParent();
- return false;
- }
-</pre>
-</div>
-
-<p>
-A block may end with a single conditional branch instruction that falls through
-to successor block if the condition evaluates to false. In that case,
-<tt>AnalyzeBranch</tt> (shown below) should return the destination of that
-conditional branch in the <tt>TBB</tt> parameter and a list of operands in
-the <tt>Cond</tt> parameter to evaluate the condition.
-</p>
-
-<div class="doc_code">
-<pre>
- if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) {
- // Block ends with fall-through condbranch.
- TBB = LastInst->getOperand(0).getMBB();
- Cond.push_back(LastInst->getOperand(1));
- Cond.push_back(LastInst->getOperand(2));
- return false;
- }
-</pre>
-</div>
-
-<p>
-If a block ends with both a conditional branch and an ensuing unconditional
-branch, then <tt>AnalyzeBranch</tt> (shown below) should return the conditional
-branch destination (assuming it corresponds to a conditional evaluation of
-'<tt>true</tt>') in the <tt>TBB</tt> parameter and the unconditional branch
-destination in the <tt>FBB</tt> (corresponding to a conditional evaluation of
-'<tt>false</tt>'). A list of operands to evaluate the condition should be
-returned in the <tt>Cond</tt> parameter.
-</p>
-
-<div class="doc_code">
-<pre>
- unsigned SecondLastOpc = SecondLastInst->getOpcode();
-
- if ((SecondLastOpc == ARM::Bcc && LastOpc == ARM::B) ||
- (SecondLastOpc == ARM::tBcc && LastOpc == ARM::tB)) {
- TBB = SecondLastInst->getOperand(0).getMBB();
- Cond.push_back(SecondLastInst->getOperand(1));
- Cond.push_back(SecondLastInst->getOperand(2));
- FBB = LastInst->getOperand(0).getMBB();
- return false;
- }
-</pre>
-</div>
-
-<p>
-For the last two cases (ending with a single conditional branch or ending with
-one conditional and one unconditional branch), the operands returned in
-the <tt>Cond</tt> parameter can be passed to methods of other instructions to
-create new branches or perform other operations. An implementation
-of <tt>AnalyzeBranch</tt> requires the helper methods <tt>RemoveBranch</tt>
-and <tt>InsertBranch</tt> to manage subsequent operations.
-</p>
-
-<p>
-<tt>AnalyzeBranch</tt> should return false indicating success in most circumstances.
-<tt>AnalyzeBranch</tt> should only return true when the method is stumped about what to
-do, for example, if a block has three terminating branches. <tt>AnalyzeBranch</tt> may
-return true if it encounters a terminator it cannot handle, such as an indirect
-branch.
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="InstructionSelector">Instruction Selector</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-LLVM uses a <tt>SelectionDAG</tt> to represent LLVM IR instructions, and nodes
-of the <tt>SelectionDAG</tt> ideally represent native target
-instructions. During code generation, instruction selection passes are performed
-to convert non-native DAG instructions into native target-specific
-instructions. The pass described in <tt>XXXISelDAGToDAG.cpp</tt> is used to
-match patterns and perform DAG-to-DAG instruction selection. Optionally, a pass
-may be defined (in <tt>XXXBranchSelector.cpp</tt>) to perform similar DAG-to-DAG
-operations for branch instructions. Later, the code in
-<tt>XXXISelLowering.cpp</tt> replaces or removes operations and data types not
-supported natively (legalizes) in a <tt>SelectionDAG</tt>.
-</p>
-
-<p>
-TableGen generates code for instruction selection using the following target
-description input files:
-</p>
-
-<ul>
-<li><tt>XXXInstrInfo.td</tt> — Contains definitions of instructions in a
- target-specific instruction set, generates <tt>XXXGenDAGISel.inc</tt>, which
- is included in <tt>XXXISelDAGToDAG.cpp</tt>.</li>
-
-<li><tt>XXXCallingConv.td</tt> — Contains the calling and return value
- conventions for the target architecture, and it generates
- <tt>XXXGenCallingConv.inc</tt>, which is included in
- <tt>XXXISelLowering.cpp</tt>.</li>
-</ul>
-
-<p>
-The implementation of an instruction selection pass must include a header that
-declares the <tt>FunctionPass</tt> class or a subclass of <tt>FunctionPass</tt>. In
-<tt>XXXTargetMachine.cpp</tt>, a Pass Manager (PM) should add each instruction
-selection pass into the queue of passes to run.
-</p>
-
-<p>
-The LLVM static compiler (<tt>llc</tt>) is an excellent tool for visualizing the
-contents of DAGs. To display the <tt>SelectionDAG</tt> before or after specific
-processing phases, use the command line options for <tt>llc</tt>, described
-at <a href="http://llvm.org/docs/CodeGenerator.html#selectiondag_process">
-SelectionDAG Instruction Selection Process</a>.
-</p>
-
-<p>
-To describe instruction selector behavior, you should add patterns for lowering
-LLVM code into a <tt>SelectionDAG</tt> as the last parameter of the instruction
-definitions in <tt>XXXInstrInfo.td</tt>. For example, in
-<tt>SparcInstrInfo.td</tt>, this entry defines a register store operation, and
-the last parameter describes a pattern with the store DAG operator.
-</p>
-
-<div class="doc_code">
-<pre>
-def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
- "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
-</pre>
-</div>
-
-<p>
-<tt>ADDRrr</tt> is a memory mode that is also defined in
-<tt>SparcInstrInfo.td</tt>:
-</p>
-
-<div class="doc_code">
-<pre>
-def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
-</pre>
-</div>
-
-<p>
-The definition of <tt>ADDRrr</tt> refers to <tt>SelectADDRrr</tt>, which is a
-function defined in an implementation of the Instructor Selector (such
-as <tt>SparcISelDAGToDAG.cpp</tt>).
-</p>
-
-<p>
-In <tt>lib/Target/TargetSelectionDAG.td</tt>, the DAG operator for store is
-defined below:
-</p>
-
-<div class="doc_code">
-<pre>
-def store : PatFrag<(ops node:$val, node:$ptr),
- (st node:$val, node:$ptr), [{
- if (StoreSDNode *ST = dyn_cast<StoreSDNode>(N))
- return !ST->isTruncatingStore() &&
- ST->getAddressingMode() == ISD::UNINDEXED;
- return false;
-}]>;
-</pre>
-</div>
-
-<p>
-<tt>XXXInstrInfo.td</tt> also generates (in <tt>XXXGenDAGISel.inc</tt>) the
-<tt>SelectCode</tt> method that is used to call the appropriate processing
-method for an instruction. In this example, <tt>SelectCode</tt>
-calls <tt>Select_ISD_STORE</tt> for the <tt>ISD::STORE</tt> opcode.
-</p>
-
-<div class="doc_code">
-<pre>
-SDNode *SelectCode(SDValue N) {
- ...
- MVT::ValueType NVT = N.getNode()->getValueType(0);
- switch (N.getOpcode()) {
- case ISD::STORE: {
- switch (NVT) {
- default:
- return Select_ISD_STORE(N);
- break;
- }
- break;
- }
- ...
-</pre>
-</div>
-
-<p>
-The pattern for <tt>STrr</tt> is matched, so elsewhere in
-<tt>XXXGenDAGISel.inc</tt>, code for <tt>STrr</tt> is created for
-<tt>Select_ISD_STORE</tt>. The <tt>Emit_22</tt> method is also generated
-in <tt>XXXGenDAGISel.inc</tt> to complete the processing of this
-instruction.
-</p>
-
-<div class="doc_code">
-<pre>
-SDNode *Select_ISD_STORE(const SDValue &N) {
- SDValue Chain = N.getOperand(0);
- if (Predicate_store(N.getNode())) {
- SDValue N1 = N.getOperand(1);
- SDValue N2 = N.getOperand(2);
- SDValue CPTmp0;
- SDValue CPTmp1;
-
- // Pattern: (st:void IntRegs:i32:$src,
- // ADDRrr:i32:$addr)<<P:Predicate_store>>
- // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)
- // Pattern complexity = 13 cost = 1 size = 0
- if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) &&
- N1.getNode()->getValueType(0) == MVT::i32 &&
- N2.getNode()->getValueType(0) == MVT::i32) {
- return Emit_22(N, SP::STrr, CPTmp0, CPTmp1);
- }
-...
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="LegalizePhase">The SelectionDAG Legalize Phase</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The Legalize phase converts a DAG to use types and operations that are natively
-supported by the target. For natively unsupported types and operations, you need
-to add code to the target-specific XXXTargetLowering implementation to convert
-unsupported types and operations to supported ones.
-</p>
-
-<p>
-In the constructor for the <tt>XXXTargetLowering</tt> class, first use the
-<tt>addRegisterClass</tt> method to specify which types are supports and which
-register classes are associated with them. The code for the register classes are
-generated by TableGen from <tt>XXXRegisterInfo.td</tt> and placed
-in <tt>XXXGenRegisterInfo.h.inc</tt>. For example, the implementation of the
-constructor for the SparcTargetLowering class (in
-<tt>SparcISelLowering.cpp</tt>) starts with the following code:
-</p>
-
-<div class="doc_code">
-<pre>
-addRegisterClass(MVT::i32, SP::IntRegsRegisterClass);
-addRegisterClass(MVT::f32, SP::FPRegsRegisterClass);
-addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass);
-</pre>
-</div>
-
-<p>
-You should examine the node types in the <tt>ISD</tt> namespace
-(<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>) and determine which
-operations the target natively supports. For operations that do <b>not</b> have
-native support, add a callback to the constructor for the XXXTargetLowering
-class, so the instruction selection process knows what to do. The TargetLowering
-class callback methods (declared in <tt>llvm/Target/TargetLowering.h</tt>) are:
-</p>
-
-<ul>
-<li><tt>setOperationAction</tt> — General operation.</li>
-
-<li><tt>setLoadExtAction</tt> — Load with extension.</li>
-
-<li><tt>setTruncStoreAction</tt> — Truncating store.</li>
-
-<li><tt>setIndexedLoadAction</tt> — Indexed load.</li>
-
-<li><tt>setIndexedStoreAction</tt> — Indexed store.</li>
-
-<li><tt>setConvertAction</tt> — Type conversion.</li>
-
-<li><tt>setCondCodeAction</tt> — Support for a given condition code.</li>
-</ul>
-
-<p>
-Note: on older releases, <tt>setLoadXAction</tt> is used instead
-of <tt>setLoadExtAction</tt>. Also, on older releases,
-<tt>setCondCodeAction</tt> may not be supported. Examine your release
-to see what methods are specifically supported.
-</p>
-
-<p>
-These callbacks are used to determine that an operation does or does not work
-with a specified type (or types). And in all cases, the third parameter is
-a <tt>LegalAction</tt> type enum value: <tt>Promote</tt>, <tt>Expand</tt>,
-<tt>Custom</tt>, or <tt>Legal</tt>. <tt>SparcISelLowering.cpp</tt>
-contains examples of all four <tt>LegalAction</tt> values.
-</p>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="promote">Promote</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-For an operation without native support for a given type, the specified type may
-be promoted to a larger type that is supported. For example, SPARC does not
-support a sign-extending load for Boolean values (<tt>i1</tt> type), so
-in <tt>SparcISelLowering.cpp</tt> the third parameter below, <tt>Promote</tt>,
-changes <tt>i1</tt> type values to a large type before loading.
-</p>
-
-<div class="doc_code">
-<pre>
-setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
-</pre>
-</div>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="expand">Expand</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-For a type without native support, a value may need to be broken down further,
-rather than promoted. For an operation without native support, a combination of
-other operations may be used to similar effect. In SPARC, the floating-point
-sine and cosine trig operations are supported by expansion to other operations,
-as indicated by the third parameter, <tt>Expand</tt>, to
-<tt>setOperationAction</tt>:
-</p>
-
-<div class="doc_code">
-<pre>
-setOperationAction(ISD::FSIN, MVT::f32, Expand);
-setOperationAction(ISD::FCOS, MVT::f32, Expand);
-</pre>
-</div>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="custom">Custom</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-For some operations, simple type promotion or operation expansion may be
-insufficient. In some cases, a special intrinsic function must be implemented.
-</p>
-
-<p>
-For example, a constant value may require special treatment, or an operation may
-require spilling and restoring registers in the stack and working with register
-allocators.
-</p>
-
-<p>
-As seen in <tt>SparcISelLowering.cpp</tt> code below, to perform a type
-conversion from a floating point value to a signed integer, first the
-<tt>setOperationAction</tt> should be called with <tt>Custom</tt> as the third
-parameter:
-</p>
-
-<div class="doc_code">
-<pre>
-setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
-</pre>
-</div>
-
-<p>
-In the <tt>LowerOperation</tt> method, for each <tt>Custom</tt> operation, a
-case statement should be added to indicate what function to call. In the
-following code, an <tt>FP_TO_SINT</tt> opcode will call
-the <tt>LowerFP_TO_SINT</tt> method:
-</p>
-
-<div class="doc_code">
-<pre>
-SDValue SparcTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) {
- switch (Op.getOpcode()) {
- case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG);
- ...
- }
-}
-</pre>
-</div>
-
-<p>
-Finally, the <tt>LowerFP_TO_SINT</tt> method is implemented, using an FP
-register to convert the floating-point value to an integer.
-</p>
-
-<div class="doc_code">
-<pre>
-static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) {
- assert(Op.getValueType() == MVT::i32);
- Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0));
- return DAG.getNode(ISD::BIT_CONVERT, MVT::i32, Op);
-}
-</pre>
-</div>
-
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- <a name="legal">Legal</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-The <tt>Legal</tt> LegalizeAction enum value simply indicates that an
-operation <b>is</b> natively supported. <tt>Legal</tt> represents the default
-condition, so it is rarely used. In <tt>SparcISelLowering.cpp</tt>, the action
-for <tt>CTPOP</tt> (an operation to count the bits set in an integer) is
-natively supported only for SPARC v9. The following code enables
-the <tt>Expand</tt> conversion technique for non-v9 SPARC implementations.
-</p>
-
-<div class="doc_code">
-<pre>
-setOperationAction(ISD::CTPOP, MVT::i32, Expand);
-...
-if (TM.getSubtarget<SparcSubtarget>().isV9())
- setOperationAction(ISD::CTPOP, MVT::i32, Legal);
- case ISD::SETULT: return SPCC::ICC_CS;
- case ISD::SETULE: return SPCC::ICC_LEU;
- case ISD::SETUGT: return SPCC::ICC_GU;
- case ISD::SETUGE: return SPCC::ICC_CC;
- }
-}
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="callingConventions">Calling Conventions</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-To support target-specific calling conventions, <tt>XXXGenCallingConv.td</tt>
-uses interfaces (such as CCIfType and CCAssignToReg) that are defined in
-<tt>lib/Target/TargetCallingConv.td</tt>. TableGen can take the target
-descriptor file <tt>XXXGenCallingConv.td</tt> and generate the header
-file <tt>XXXGenCallingConv.inc</tt>, which is typically included
-in <tt>XXXISelLowering.cpp</tt>. You can use the interfaces in
-<tt>TargetCallingConv.td</tt> to specify:
-</p>
-
-<ul>
-<li>The order of parameter allocation.</li>
-
-<li>Where parameters and return values are placed (that is, on the stack or in
- registers).</li>
-
-<li>Which registers may be used.</li>
-
-<li>Whether the caller or callee unwinds the stack.</li>
-</ul>
-
-<p>
-The following example demonstrates the use of the <tt>CCIfType</tt> and
-<tt>CCAssignToReg</tt> interfaces. If the <tt>CCIfType</tt> predicate is true
-(that is, if the current argument is of type <tt>f32</tt> or <tt>f64</tt>), then
-the action is performed. In this case, the <tt>CCAssignToReg</tt> action assigns
-the argument value to the first available register: either <tt>R0</tt>
-or <tt>R1</tt>.
-</p>
-
-<div class="doc_code">
-<pre>
-CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
-</pre>
-</div>
-
-<p>
-<tt>SparcCallingConv.td</tt> contains definitions for a target-specific
-return-value calling convention (RetCC_Sparc32) and a basic 32-bit C calling
-convention (<tt>CC_Sparc32</tt>). The definition of <tt>RetCC_Sparc32</tt>
-(shown below) indicates which registers are used for specified scalar return
-types. A single-precision float is returned to register <tt>F0</tt>, and a
-double-precision float goes to register <tt>D0</tt>. A 32-bit integer is
-returned in register <tt>I0</tt> or <tt>I1</tt>.
-</p>
-
-<div class="doc_code">
-<pre>
-def RetCC_Sparc32 : CallingConv<[
- CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
- CCIfType<[f32], CCAssignToReg<[F0]>>,
- CCIfType<[f64], CCAssignToReg<[D0]>>
-]>;
-</pre>
-</div>
-
-<p>
-The definition of <tt>CC_Sparc32</tt> in <tt>SparcCallingConv.td</tt> introduces
-<tt>CCAssignToStack</tt>, which assigns the value to a stack slot with the
-specified size and alignment. In the example below, the first parameter, 4,
-indicates the size of the slot, and the second parameter, also 4, indicates the
-stack alignment along 4-byte units. (Special cases: if size is zero, then the
-ABI size is used; if alignment is zero, then the ABI alignment is used.)
-</p>
-
-<div class="doc_code">
-<pre>
-def CC_Sparc32 : CallingConv<[
- // All arguments get passed in integer registers if there is space.
- CCIfType<[i32, f32, f64], CCAssignToReg<[I0, I1, I2, I3, I4, I5]>>,
- CCAssignToStack<4, 4>
-]>;
-</pre>
-</div>
-
-<p>
-<tt>CCDelegateTo</tt> is another commonly used interface, which tries to find a
-specified sub-calling convention, and, if a match is found, it is invoked. In
-the following example (in <tt>X86CallingConv.td</tt>), the definition of
-<tt>RetCC_X86_32_C</tt> ends with <tt>CCDelegateTo</tt>. After the current value
-is assigned to the register <tt>ST0</tt> or <tt>ST1</tt>,
-the <tt>RetCC_X86Common</tt> is invoked.
-</p>
-
-<div class="doc_code">
-<pre>
-def RetCC_X86_32_C : CallingConv<[
- CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
- CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>,
- CCDelegateTo<RetCC_X86Common>
-]>;
-</pre>
-</div>
-
-<p>
-<tt>CCIfCC</tt> is an interface that attempts to match the given name to the
-current calling convention. If the name identifies the current calling
-convention, then a specified action is invoked. In the following example (in
-<tt>X86CallingConv.td</tt>), if the <tt>Fast</tt> calling convention is in use,
-then <tt>RetCC_X86_32_Fast</tt> is invoked. If the <tt>SSECall</tt> calling
-convention is in use, then <tt>RetCC_X86_32_SSE</tt> is invoked.
-</p>
-
-<div class="doc_code">
-<pre>
-def RetCC_X86_32 : CallingConv<[
- CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
- CCIfCC<"CallingConv::X86_SSECall", CCDelegateTo<RetCC_X86_32_SSE>>,
- CCDelegateTo<RetCC_X86_32_C>
-]>;
-</pre>
-</div>
-
-<p>Other calling convention interfaces include:</p>
-
-<ul>
-<li><tt>CCIf <predicate, action></tt> — If the predicate matches,
- apply the action.</li>
-
-<li><tt>CCIfInReg <action></tt> — If the argument is marked with the
- '<tt>inreg</tt>' attribute, then apply the action.</li>
-
-<li><tt>CCIfNest <action></tt> — Inf the argument is marked with the
- '<tt>nest</tt>' attribute, then apply the action.</li>
-
-<li><tt>CCIfNotVarArg <action></tt> — If the current function does
- not take a variable number of arguments, apply the action.</li>
-
-<li><tt>CCAssignToRegWithShadow <registerList, shadowList></tt> —
- similar to <tt>CCAssignToReg</tt>, but with a shadow list of registers.</li>
-
-<li><tt>CCPassByVal <size, align></tt> — Assign value to a stack
- slot with the minimum specified size and alignment.</li>
-
-<li><tt>CCPromoteToType <type></tt> — Promote the current value to
- the specified type.</li>
-
-<li><tt>CallingConv <[actions]></tt> — Define each calling
- convention that is supported.</li>
-</ul>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="assemblyPrinter">Assembly Printer</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-During the code emission stage, the code generator may utilize an LLVM pass to
-produce assembly output. To do this, you want to implement the code for a
-printer that converts LLVM IR to a GAS-format assembly language for your target
-machine, using the following steps:
-</p>
-
-<ul>
-<li>Define all the assembly strings for your target, adding them to the
- instructions defined in the <tt>XXXInstrInfo.td</tt> file.
- (See <a href="#InstructionSet">Instruction Set</a>.) TableGen will produce
- an output file (<tt>XXXGenAsmWriter.inc</tt>) with an implementation of
- the <tt>printInstruction</tt> method for the XXXAsmPrinter class.</li>
-
-<li>Write <tt>XXXTargetAsmInfo.h</tt>, which contains the bare-bones declaration
- of the <tt>XXXTargetAsmInfo</tt> class (a subclass
- of <tt>TargetAsmInfo</tt>).</li>
-
-<li>Write <tt>XXXTargetAsmInfo.cpp</tt>, which contains target-specific values
- for <tt>TargetAsmInfo</tt> properties and sometimes new implementations for
- methods.</li>
-
-<li>Write <tt>XXXAsmPrinter.cpp</tt>, which implements the <tt>AsmPrinter</tt>
- class that performs the LLVM-to-assembly conversion.</li>
-</ul>
-
-<p>
-The code in <tt>XXXTargetAsmInfo.h</tt> is usually a trivial declaration of the
-<tt>XXXTargetAsmInfo</tt> class for use in <tt>XXXTargetAsmInfo.cpp</tt>.
-Similarly, <tt>XXXTargetAsmInfo.cpp</tt> usually has a few declarations of
-<tt>XXXTargetAsmInfo</tt> replacement values that override the default values
-in <tt>TargetAsmInfo.cpp</tt>. For example in <tt>SparcTargetAsmInfo.cpp</tt>:
-</p>
-
-<div class="doc_code">
-<pre>
-SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) {
- Data16bitsDirective = "\t.half\t";
- Data32bitsDirective = "\t.word\t";
- Data64bitsDirective = 0; // .xword is only supported by V9.
- ZeroDirective = "\t.skip\t";
- CommentString = "!";
- ConstantPoolSection = "\t.section \".rodata\",#alloc\n";
-}
-</pre>
-</div>
-
-<p>
-The X86 assembly printer implementation (<tt>X86TargetAsmInfo</tt>) is an
-example where the target specific <tt>TargetAsmInfo</tt> class uses an
-overridden methods: <tt>ExpandInlineAsm</tt>.
-</p>
-
-<p>
-A target-specific implementation of AsmPrinter is written in
-<tt>XXXAsmPrinter.cpp</tt>, which implements the <tt>AsmPrinter</tt> class that
-converts the LLVM to printable assembly. The implementation must include the
-following headers that have declarations for the <tt>AsmPrinter</tt> and
-<tt>MachineFunctionPass</tt> classes. The <tt>MachineFunctionPass</tt> is a
-subclass of <tt>FunctionPass</tt>.
-</p>
-
-<div class="doc_code">
-<pre>
-#include "llvm/CodeGen/AsmPrinter.h"
-#include "llvm/CodeGen/MachineFunctionPass.h"
-</pre>
-</div>
-
-<p>
-As a <tt>FunctionPass</tt>, <tt>AsmPrinter</tt> first
-calls <tt>doInitialization</tt> to set up the <tt>AsmPrinter</tt>. In
-<tt>SparcAsmPrinter</tt>, a <tt>Mangler</tt> object is instantiated to process
-variable names.
-</p>
-
-<p>
-In <tt>XXXAsmPrinter.cpp</tt>, the <tt>runOnMachineFunction</tt> method
-(declared in <tt>MachineFunctionPass</tt>) must be implemented
-for <tt>XXXAsmPrinter</tt>. In <tt>MachineFunctionPass</tt>,
-the <tt>runOnFunction</tt> method invokes <tt>runOnMachineFunction</tt>.
-Target-specific implementations of <tt>runOnMachineFunction</tt> differ, but
-generally do the following to process each machine function:
-</p>
-
-<ul>
-<li>Call <tt>SetupMachineFunction</tt> to perform initialization.</li>
-
-<li>Call <tt>EmitConstantPool</tt> to print out (to the output stream) constants
- which have been spilled to memory.</li>
-
-<li>Call <tt>EmitJumpTableInfo</tt> to print out jump tables used by the current
- function.</li>
-
-<li>Print out the label for the current function.</li>
-
-<li>Print out the code for the function, including basic block labels and the
- assembly for the instruction (using <tt>printInstruction</tt>)</li>
-</ul>
-
-<p>
-The <tt>XXXAsmPrinter</tt> implementation must also include the code generated
-by TableGen that is output in the <tt>XXXGenAsmWriter.inc</tt> file. The code
-in <tt>XXXGenAsmWriter.inc</tt> contains an implementation of the
-<tt>printInstruction</tt> method that may call these methods:
-</p>
-
-<ul>
-<li><tt>printOperand</tt></li>
-
-<li><tt>printMemOperand</tt></li>
-
-<li><tt>printCCOperand (for conditional statements)</tt></li>
-
-<li><tt>printDataDirective</tt></li>
-
-<li><tt>printDeclare</tt></li>
-
-<li><tt>printImplicitDef</tt></li>
-
-<li><tt>printInlineAsm</tt></li>
-</ul>
-
-<p>
-The implementations of <tt>printDeclare</tt>, <tt>printImplicitDef</tt>,
-<tt>printInlineAsm</tt>, and <tt>printLabel</tt> in <tt>AsmPrinter.cpp</tt> are
-generally adequate for printing assembly and do not need to be
-overridden.
-</p>
-
-<p>
-The <tt>printOperand</tt> method is implemented with a long switch/case
-statement for the type of operand: register, immediate, basic block, external
-symbol, global address, constant pool index, or jump table index. For an
-instruction with a memory address operand, the <tt>printMemOperand</tt> method
-should be implemented to generate the proper output. Similarly,
-<tt>printCCOperand</tt> should be used to print a conditional operand.
-</p>
-
-<p><tt>doFinalization</tt> should be overridden in <tt>XXXAsmPrinter</tt>, and
-it should be called to shut down the assembly printer. During
-<tt>doFinalization</tt>, global variables and constants are printed to
-output.
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="subtargetSupport">Subtarget Support</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-Subtarget support is used to inform the code generation process of instruction
-set variations for a given chip set. For example, the LLVM SPARC implementation
-provided covers three major versions of the SPARC microprocessor architecture:
-Version 8 (V8, which is a 32-bit architecture), Version 9 (V9, a 64-bit
-architecture), and the UltraSPARC architecture. V8 has 16 double-precision
-floating-point registers that are also usable as either 32 single-precision or 8
-quad-precision registers. V8 is also purely big-endian. V9 has 32
-double-precision floating-point registers that are also usable as 16
-quad-precision registers, but cannot be used as single-precision registers. The
-UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set
-extensions.
-</p>
-
-<p>
-If subtarget support is needed, you should implement a target-specific
-XXXSubtarget class for your architecture. This class should process the
-command-line options <tt>-mcpu=</tt> and <tt>-mattr=</tt>.
-</p>
-
-<p>
-TableGen uses definitions in the <tt>Target.td</tt> and <tt>Sparc.td</tt> files
-to generate code in <tt>SparcGenSubtarget.inc</tt>. In <tt>Target.td</tt>, shown
-below, the <tt>SubtargetFeature</tt> interface is defined. The first 4 string
-parameters of the <tt>SubtargetFeature</tt> interface are a feature name, an
-attribute set by the feature, the value of the attribute, and a description of
-the feature. (The fifth parameter is a list of features whose presence is
-implied, and its default value is an empty array.)
-</p>
-
-<div class="doc_code">
-<pre>
-class SubtargetFeature<string n, string a, string v, string d,
- list<SubtargetFeature> i = []> {
- string Name = n;
- string Attribute = a;
- string Value = v;
- string Desc = d;
- list<SubtargetFeature> Implies = i;
-}
-</pre>
-</div>
-
-<p>
-In the <tt>Sparc.td</tt> file, the SubtargetFeature is used to define the
-following features.
-</p>
-
-<div class="doc_code">
-<pre>
-def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
- "Enable SPARC-V9 instructions">;
-def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8",
- "V8DeprecatedInsts", "true",
- "Enable deprecated V8 instructions in V9 mode">;
-def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true",
- "Enable UltraSPARC Visual Instruction Set extensions">;
-</pre>
-</div>
-
-<p>
-Elsewhere in <tt>Sparc.td</tt>, the Proc class is defined and then is used to
-define particular SPARC processor subtypes that may have the previously
-described features.
-</p>
-
-<div class="doc_code">
-<pre>
-class Proc<string Name, list<SubtargetFeature> Features>
- : Processor<Name, NoItineraries, Features>;
-
-def : Proc<"generic", []>;
-def : Proc<"v8", []>;
-def : Proc<"supersparc", []>;
-def : Proc<"sparclite", []>;
-def : Proc<"f934", []>;
-def : Proc<"hypersparc", []>;
-def : Proc<"sparclite86x", []>;
-def : Proc<"sparclet", []>;
-def : Proc<"tsc701", []>;
-def : Proc<"v9", [FeatureV9]>;
-def : Proc<"ultrasparc", [FeatureV9, FeatureV8Deprecated]>;
-def : Proc<"ultrasparc3", [FeatureV9, FeatureV8Deprecated]>;
-def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;
-</pre>
-</div>
-
-<p>
-From <tt>Target.td</tt> and <tt>Sparc.td</tt> files, the resulting
-SparcGenSubtarget.inc specifies enum values to identify the features, arrays of
-constants to represent the CPU features and CPU subtypes, and the
-ParseSubtargetFeatures method that parses the features string that sets
-specified subtarget options. The generated <tt>SparcGenSubtarget.inc</tt> file
-should be included in the <tt>SparcSubtarget.cpp</tt>. The target-specific
-implementation of the XXXSubtarget method should follow this pseudocode:
-</p>
-
-<div class="doc_code">
-<pre>
-XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) {
- // Set the default features
- // Determine default and user specified characteristics of the CPU
- // Call ParseSubtargetFeatures(FS, CPU) to parse the features string
- // Perform any additional operations
-}
-</pre>
-</div>
-
-</div>
-
-<!-- *********************************************************************** -->
-<div class="doc_section">
- <a name="jitSupport">JIT Support</a>
-</div>
-<!-- *********************************************************************** -->
-
-<div class="doc_text">
-
-<p>
-The implementation of a target machine optionally includes a Just-In-Time (JIT)
-code generator that emits machine code and auxiliary structures as binary output
-that can be written directly to memory. To do this, implement JIT code
-generation by performing the following steps:
-</p>
-
-<ul>
-<li>Write an <tt>XXXCodeEmitter.cpp</tt> file that contains a machine function
- pass that transforms target-machine instructions into relocatable machine
- code.</li>
-
-<li>Write an <tt>XXXJITInfo.cpp</tt> file that implements the JIT interfaces for
- target-specific code-generation activities, such as emitting machine code
- and stubs.</li>
-
-<li>Modify <tt>XXXTargetMachine</tt> so that it provides a
- <tt>TargetJITInfo</tt> object through its <tt>getJITInfo</tt> method.</li>
-</ul>
-
-<p>
-There are several different approaches to writing the JIT support code. For
-instance, TableGen and target descriptor files may be used for creating a JIT
-code generator, but are not mandatory. For the Alpha and PowerPC target
-machines, TableGen is used to generate <tt>XXXGenCodeEmitter.inc</tt>, which
-contains the binary coding of machine instructions and the
-<tt>getBinaryCodeForInstr</tt> method to access those codes. Other JIT
-implementations do not.
-</p>
-
-<p>
-Both <tt>XXXJITInfo.cpp</tt> and <tt>XXXCodeEmitter.cpp</tt> must include the
-<tt>llvm/CodeGen/MachineCodeEmitter.h</tt> header file that defines the
-<tt>MachineCodeEmitter</tt> class containing code for several callback functions
-that write data (in bytes, words, strings, etc.) to the output stream.
-</p>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="mce">Machine Code Emitter</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-In <tt>XXXCodeEmitter.cpp</tt>, a target-specific of the <tt>Emitter</tt> class
-is implemented as a function pass (subclass
-of <tt>MachineFunctionPass</tt>). The target-specific implementation
-of <tt>runOnMachineFunction</tt> (invoked by
-<tt>runOnFunction</tt> in <tt>MachineFunctionPass</tt>) iterates through the
-<tt>MachineBasicBlock</tt> calls <tt>emitInstruction</tt> to process each
-instruction and emit binary code. <tt>emitInstruction</tt> is largely
-implemented with case statements on the instruction types defined in
-<tt>XXXInstrInfo.h</tt>. For example, in <tt>X86CodeEmitter.cpp</tt>,
-the <tt>emitInstruction</tt> method is built around the following switch/case
-statements:
-</p>
-
-<div class="doc_code">
-<pre>
-switch (Desc->TSFlags & X86::FormMask) {
-case X86II::Pseudo: // for not yet implemented instructions
- ... // or pseudo-instructions
- break;
-case X86II::RawFrm: // for instructions with a fixed opcode value
- ...
- break;
-case X86II::AddRegFrm: // for instructions that have one register operand
- ... // added to their opcode
- break;
-case X86II::MRMDestReg:// for instructions that use the Mod/RM byte
- ... // to specify a destination (register)
- break;
-case X86II::MRMDestMem:// for instructions that use the Mod/RM byte
- ... // to specify a destination (memory)
- break;
-case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte
- ... // to specify a source (register)
- break;
-case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte
- ... // to specify a source (memory)
- break;
-case X86II::MRM0r: case X86II::MRM1r: // for instructions that operate on
-case X86II::MRM2r: case X86II::MRM3r: // a REGISTER r/m operand and
-case X86II::MRM4r: case X86II::MRM5r: // use the Mod/RM byte and a field
-case X86II::MRM6r: case X86II::MRM7r: // to hold extended opcode data
- ...
- break;
-case X86II::MRM0m: case X86II::MRM1m: // for instructions that operate on
-case X86II::MRM2m: case X86II::MRM3m: // a MEMORY r/m operand and
-case X86II::MRM4m: case X86II::MRM5m: // use the Mod/RM byte and a field
-case X86II::MRM6m: case X86II::MRM7m: // to hold extended opcode data
- ...
- break;
-case X86II::MRMInitReg: // for instructions whose source and
- ... // destination are the same register
- break;
-}
-</pre>
-</div>
-
-<p>
-The implementations of these case statements often first emit the opcode and
-then get the operand(s). Then depending upon the operand, helper methods may be
-called to process the operand(s). For example, in <tt>X86CodeEmitter.cpp</tt>,
-for the <tt>X86II::AddRegFrm</tt> case, the first data emitted
-(by <tt>emitByte</tt>) is the opcode added to the register operand. Then an
-object representing the machine operand, <tt>MO1</tt>, is extracted. The helper
-methods such as <tt>isImmediate</tt>,
-<tt>isGlobalAddress</tt>, <tt>isExternalSymbol</tt>, <tt>isConstantPoolIndex</tt>, and
-<tt>isJumpTableIndex</tt> determine the operand
-type. (<tt>X86CodeEmitter.cpp</tt> also has private methods such
-as <tt>emitConstant</tt>, <tt>emitGlobalAddress</tt>,
-<tt>emitExternalSymbolAddress</tt>, <tt>emitConstPoolAddress</tt>,
-and <tt>emitJumpTableAddress</tt> that emit the data into the output stream.)
-</p>
-
-<div class="doc_code">
-<pre>
-case X86II::AddRegFrm:
- MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg()));
-
- if (CurOp != NumOps) {
- const MachineOperand &MO1 = MI.getOperand(CurOp++);
- unsigned Size = X86InstrInfo::sizeOfImm(Desc);
- if (MO1.isImmediate())
- emitConstant(MO1.getImm(), Size);
- else {
- unsigned rt = Is64BitMode ? X86::reloc_pcrel_word
- : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word);
- if (Opcode == X86::MOV64ri)
- rt = X86::reloc_absolute_dword; // FIXME: add X86II flag?
- if (MO1.isGlobalAddress()) {
- bool NeedStub = isa<Function>(MO1.getGlobal());
- bool isLazy = gvNeedsLazyPtr(MO1.getGlobal());
- emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0,
- NeedStub, isLazy);
- } else if (MO1.isExternalSymbol())
- emitExternalSymbolAddress(MO1.getSymbolName(), rt);
- else if (MO1.isConstantPoolIndex())
- emitConstPoolAddress(MO1.getIndex(), rt);
- else if (MO1.isJumpTableIndex())
- emitJumpTableAddress(MO1.getIndex(), rt);
- }
- }
- break;
-</pre>
-</div>
-
-<p>
-In the previous example, <tt>XXXCodeEmitter.cpp</tt> uses the
-variable <tt>rt</tt>, which is a RelocationType enum that may be used to
-relocate addresses (for example, a global address with a PIC base offset). The
-<tt>RelocationType</tt> enum for that target is defined in the short
-target-specific <tt>XXXRelocations.h</tt> file. The <tt>RelocationType</tt> is used by
-the <tt>relocate</tt> method defined in <tt>XXXJITInfo.cpp</tt> to rewrite
-addresses for referenced global symbols.
-</p>
-
-<p>
-For example, <tt>X86Relocations.h</tt> specifies the following relocation types
-for the X86 addresses. In all four cases, the relocated value is added to the
-value already in memory. For <tt>reloc_pcrel_word</tt>
-and <tt>reloc_picrel_word</tt>, there is an additional initial adjustment.
-</p>
-
-<div class="doc_code">
-<pre>
-enum RelocationType {
- reloc_pcrel_word = 0, // add reloc value after adjusting for the PC loc
- reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base
- reloc_absolute_word = 2, // absolute relocation; no additional adjustment
- reloc_absolute_dword = 3 // absolute relocation; no additional adjustment
-};
-</pre>
-</div>
-
-</div>
-
-<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="targetJITInfo">Target JIT Info</a>
-</div>
-
-<div class="doc_text">
-
-<p>
-<tt>XXXJITInfo.cpp</tt> implements the JIT interfaces for target-specific
-code-generation activities, such as emitting machine code and stubs. At minimum,
-a target-specific version of <tt>XXXJITInfo</tt> implements the following:
-</p>
-
-<ul>
-<li><tt>getLazyResolverFunction</tt> — Initializes the JIT, gives the
- target a function that is used for compilation.</li>
-
-<li><tt>emitFunctionStub</tt> — Returns a native function with a specified
- address for a callback function.</li>
-
-<li><tt>relocate</tt> — Changes the addresses of referenced globals, based
- on relocation types.</li>
-
-<li>Callback function that are wrappers to a function stub that is used when the
- real target is not initially known.</li>
-</ul>
-
-<p>
-<tt>getLazyResolverFunction</tt> is generally trivial to implement. It makes the
-incoming parameter as the global <tt>JITCompilerFunction</tt> and returns the
-callback function that will be used a function wrapper. For the Alpha target
-(in <tt>AlphaJITInfo.cpp</tt>), the <tt>getLazyResolverFunction</tt>
-implementation is simply:
-</p>
-
-<div class="doc_code">
-<pre>
-TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction(
- JITCompilerFn F) {
- JITCompilerFunction = F;
- return AlphaCompilationCallback;
-}
-</pre>
-</div>
-
-<p>
-For the X86 target, the <tt>getLazyResolverFunction</tt> implementation is a
-little more complication, because it returns a different callback function for
-processors with SSE instructions and XMM registers.
-</p>
-
-<p>
-The callback function initially saves and later restores the callee register
-values, incoming arguments, and frame and return address. The callback function
-needs low-level access to the registers or stack, so it is typically implemented
-with assembler.
-</p>
-
-</div>
-
-<!-- *********************************************************************** -->
-
-<hr>
-<address>
- <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
- src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
- <a href="http://validator.w3.org/check/referer"><img
- src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
-
- <a href="http://www.woo.com">Mason Woo</a> and <a href="http://misha.brukman.net">Misha Brukman</a><br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
- <br>
- Last modified: $Date$
-</address>
-
-</body>
-</html>
More information about the llvm-commits
mailing list