TableGen Fundamentals

section · descriptive

i8* %llvm.eh.exception()
@@ -417,7 +415,7 @@
   llvm.eh.selector
 
 
-
+
 
    i32 %llvm.eh.selector(i8*, i8*, ...)
@@ -449,7 +447,7 @@
   llvm.eh.typeid.for
 
 
-
+
 
    i32 %llvm.eh.typeid.for(i8*)
@@ -467,7 +465,7 @@
   llvm.eh.sjlj.setjmp
 
 
-
+
 
    i32 %llvm.eh.sjlj.setjmp(i8*)
@@ -496,7 +494,7 @@
   llvm.eh.sjlj.longjmp
 
 
-
+
 
    void %llvm.eh.sjlj.setjmp(i8*)
@@ -516,7 +514,7 @@
   llvm.eh.sjlj.lsda
 
 
-
+
 
    i8* %llvm.eh.sjlj.lsda()
@@ -535,7 +533,7 @@
   llvm.eh.sjlj.callsite
 
 
-
+
 
    void %llvm.eh.sjlj.callsite(i32)
@@ -553,7 +551,7 @@
   llvm.eh.sjlj.dispatchsetup
 
 
-
+
 
    void %llvm.eh.sjlj.dispatchsetup(i32)
@@ -565,24 +563,24 @@
 
 
 
+
+
 
 
   Asm Table Formats
 
 
-
+
 
 There are two tables that are used by the exception handling runtime to
    determine which actions should take place when an exception is thrown.
 
-
-
 
 
   Exception Handling Frame
 
 
-
+
 
 An exception handling frame eh_frame is very similar to the unwind
    frame used by dwarf debug info.  The frame contains all the information
@@ -600,7 +598,7 @@
   Exception Tables
 
 
-

+
 
 An exception table contains information about what actions to take when an
    exception is thrown in a particular part of a function's code.  There is one
@@ -611,12 +609,14 @@
 
 
 
+
+
 
 
   ToDo
 
 
-
+

diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html
index 7f77bb77921..b720911df0a 100644
--- a/docs/ExtendingLLVM.html
+++ b/docs/ExtendingLLVM.html
@@ -36,7 +36,7 @@
 
 
 
-
+
 
 During the course of using LLVM, you may wish to customize it for your
 research project or for experimentation. At this point, you may realize that
@@ -73,7 +73,7 @@ effort by doing so.
 
 
 
-
+
 
 Adding a new intrinsic function to LLVM is much easier than adding a new
 instruction.  Almost all extensions to LLVM should start as an intrinsic
@@ -135,7 +135,7 @@ support for it.  Generally you must do the following steps:
 
 
 
-
+
 
 As with intrinsics, adding a new SelectionDAG node to LLVM is much easier
 than adding a new instruction.  New nodes are often added to help represent
@@ -225,7 +225,7 @@ complicated behavior in a single node (rotate).
 
 
 
-
+
 
 WARNING: adding instructions changes the bitcode
 format, and it will take some effort to maintain compatibility with
@@ -282,20 +282,18 @@ to understand this new instruction.
 
 
 
-
+
 
 WARNING: adding new types changes the bitcode
 format, and will break compatibility with currently-existing LLVM
 installations. Only add new types if it is absolutely necessary.
 
-
-
 
 
   Adding a fundamental type
 
 
-
+
 
 
 
@@ -321,7 +319,7 @@ installations. Only add new types if it is absolutely necessary.
   Adding a derived type
 
 
-
+
 
 
 llvm/include/llvm/Type.h:
@@ -373,6 +371,8 @@ void calcTypeName(const Type *Ty,
 
 
 
+
+
 
 
 
diff --git a/docs/GCCFEBuildInstrs.html b/docs/GCCFEBuildInstrs.html
index f3c94594977..6eb409b79c2 100644
--- a/docs/GCCFEBuildInstrs.html
+++ b/docs/GCCFEBuildInstrs.html
@@ -27,7 +27,7 @@
 Building llvm-gcc from Source
 
 
-
+
 
 This section describes how to acquire and build llvm-gcc 4.2, which is based
 on the GCC 4.2.1 front-end.  Supported languages are Ada, C, C++, Fortran,
@@ -70,7 +70,7 @@ svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk dst-directory
 
Building the Ada front-end
 
 
-
+
 Building with support for Ada amounts to following the directions in the
 top-level README.LLVM file, adding ",ada" to EXTRALANGS, for example:
 EXTRALANGS=,ada
@@ -236,7 +236,7 @@ make install
 Building the Fortran front-end
 
 
-
+
 To build with support for Fortran, follow the directions in the top-level
 README.LLVM file, adding ",fortran" to EXTRALANGS, for example:
 
@@ -250,7 +250,7 @@ EXTRALANGS=,fortran
 License Information
 
 
-
+
 
 The LLVM GCC frontend is licensed to you under the GNU General Public License
 and the GNU Lesser General Public License.  Please see the files COPYING and
diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html
index aa83a2d6d83..761e1d08caf 100644
--- a/docs/GarbageCollection.html
+++ b/docs/GarbageCollection.html
@@ -84,7 +84,7 @@
 
 
 
-

+
 
 Garbage collection is a widely used technique that frees the programmer from
 having to know the lifetimes of heap objects, making software easier to produce
@@ -124,14 +124,12 @@ techniques dominates any low-level losses.
 This document describes the mechanisms and interfaces provided by LLVM to
 support accurate garbage collection.
 
-
-
 
 
   Goals and non-goals
 
 
-
+
 
 LLVM's intermediate representation provides garbage
 collection intrinsics that offer support for a broad class of
@@ -198,13 +196,15 @@ compiler matures.
 
 
 
+
+
 
 
   Getting started
 
 
 
-
+
 
 Using a GC with LLVM implies many things, for example:
 
@@ -246,14 +246,12 @@ compiler matures.
 includes a highly portable, built-in ShadowStack code generator. It is compiled
 into llc and works even with the interpreter and C backends.
 
-
-
 
 
   In your compiler
 
 
-
+
 
 To turn the shadow stack on for your functions, first call:
 
@@ -280,7 +278,7 @@ switching to a more advanced GC.
   In your runtime
 
 
-
+
 
 The shadow stack doesn't imply a memory allocation algorithm. A semispace
 collector or building atop malloc are great places to start, and can
@@ -347,7 +345,7 @@ void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) {
   About the shadow stack
 
 
-

+
 
 Unlike many GC algorithms which rely on a cooperative code generator to
 compile stack maps, this algorithm carefully maintains a linked list of stack
@@ -372,13 +370,15 @@ in order to improve performance.
 
 
 
+
+
 
 
   IR features
 
 
 
-
+
 
 This section describes the garbage collection facilities provided by the
 LLVM intermediate representation. The exact behavior
@@ -390,8 +390,6 @@ intended to be a complete interface to any garbage collector. A program will
 need to interface with the GC library using the facilities provided by that
 program.
 
-
-
 
 
   Specifying GC code generation: gc "..."
@@ -401,7 +399,7 @@ program.
   define ty @name(...) gc "name" { ...
 
 
-
+
 
 The gc function attribute is used to specify the desired GC style
 to the compiler. Its programmatic equivalent is the setGC method of
@@ -426,7 +424,7 @@ programs that use different garbage collection algorithms (or none at all).
   void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
 
 
-
+
 
 The llvm.gcroot intrinsic is used to inform LLVM that a stack
 variable references an object on the heap and is to be tracked for garbage
@@ -498,7 +496,7 @@ CodeBlock:
   Reading and writing references in the heap
 
 
-

+
 
 Some collectors need to be informed when the mutator (the program that needs
 garbage collection) either reads a pointer from or writes a pointer to a field
@@ -534,8 +532,6 @@ require the corresponding barrier. Such a GC plugin will replace the intrinsic
 calls with the corresponding load or store instruction if they
 are used.
 
-
-
 
 
   Write barrier: llvm.gcwrite
@@ -545,7 +541,7 @@ are used.
 void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived)
 
 
-
+
 
 For write barriers, LLVM provides the llvm.gcwrite intrinsic
 function. It has exactly the same semantics as a non-volatile store to
@@ -567,7 +563,7 @@ implement reference counting.
 i8* @llvm.gcread(i8* %object, i8** %derived)

 
 
-
+
 
 For read barriers, LLVM provides the llvm.gcread intrinsic function.
 It has exactly the same semantics as a non-volatile load from the
@@ -580,13 +576,17 @@ writes.
 
 
 
+
+
+
+
 
 
   Implementing a collector plugin
 
 
 
-
+
 
 User code specifies which GC code generation to use with the gc
 function attribute or, equivalently, with the setGC method of
@@ -666,14 +666,12 @@ $ llvm-as < sample.ll | llc -load=MyGC.so
 It is also possible to statically link the collector plugin into tools, such
 as a language-specific compiler front-end.
 
-
-
 
 
   Overview of available features
 
 
-
+
 
 GCStrategy provides a range of features through which a plugin
 may do useful work. Some of these are callbacks, some are algorithms that can
@@ -962,7 +960,7 @@ interest.
   Computing stack maps
 
 
-
+
 
 LLVM automatically computes a stack map. One of the most important features
 of a GCStrategy is to compile this information into the executable in
@@ -1018,7 +1016,7 @@ for collector plugins which implement reference counting or a shadow stack.
   Initializing roots to null: InitRoots
 
 
-
+
 
 MyGC::MyGC() {
@@ -1044,7 +1042,7 @@ this feature should be used by all GC plugins. It is enabled by default.
     CustomReadBarriers, and CustomWriteBarriers
 
 
-
+
 
 For GCs which use barriers or unusual treatment of stack roots, these
 flags allow the collector to perform arbitrary transformations of the LLVM
@@ -1133,7 +1131,7 @@ bool MyGC::performCustomLowering(Function &F) {
   Generating safe points: NeededSafePoints
 
 
-

+
 
 LLVM can compute four kinds of safe points:
 
@@ -1197,7 +1195,7 @@ safe point (because only the topmost function has been patched).
   Emitting assembly code: GCMetadataPrinter
 
 
-
+
 
 LLVM allows a plugin to print arbitrary assembly code before and after the
 rest of a module's assembly code. At the end of the module, the GC can compile
@@ -1341,6 +1339,7 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
 
 
 
+
 
 
 
@@ -1348,7 +1347,7 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
 
 
 
-
+
 
 [Appel89] Runtime Tags Aren't Necessary. Andrew
 W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.
diff --git a/docs/GetElementPtr.html b/docs/GetElementPtr.html
index d1c5b6c5367..2c32a9ea7cc 100644
--- a/docs/GetElementPtr.html
+++ b/docs/GetElementPtr.html
@@ -61,7 +61,7 @@
 Introduction
 
 
- 
+
   This document seeks to dispel the mystery and confusion surrounding LLVM's
   GetElementPtr (GEP) instruction.
   Questions about the wily GEP instruction are
@@ -74,19 +74,18 @@
 
 
Address Computation
 
-
+
   When people are first confronted with the GEP instruction, they tend to
   relate it to known concepts from other programming paradigms, most notably C
   array indexing and field selection. GEP closely resembles C array indexing
   and field selection, however it's is a little different and this leads to
   the following questions.
-
 
 
 
   What is the first index of the GEP instruction?
 
-
+
   Quick answer: The index stepping through the first operand. 
   The confusion with the first index usually arises from thinking about 
   the GetElementPtr instruction as if it was a C index operator. They aren't the
@@ -209,7 +208,7 @@ idx3 = (char*) &MyVar + 8
   Why is the extra 0 index required?
 
 
-

+
   Quick answer: there are no superfluous indices.
   This question arises most often when the GEP instruction is applied to a
   global variable which is always a pointer type. For example, consider
@@ -250,7 +249,7 @@ idx3 = (char*) &MyVar + 8
 

   What is dereferenced by GEP?
 
-
+
   Quick answer: nothing. 
   The GetElementPtr instruction dereferences nothing. That is, it doesn't
   access memory in any way. That's what the Load and Store instructions are for.
@@ -305,7 +304,7 @@ idx3 = (char*) &MyVar + 8
 

   Why don't GEP x,0,0,1 and GEP x,1 alias?
 
-
+
   Quick Answer: They compute different address locations.
   If you look at the first indices in these GEP
   instructions you find that they are different (0 and 1), therefore the address
@@ -334,7 +333,7 @@ idx3 = (char*) &MyVar + 8
 

   Why do GEP x,1,0,0 and GEP x,1 alias?
 
-
+
   Quick Answer: They compute the same address location.
   These two GEP instructions will compute the same address because indexing
   through the 0th element does not change the address. However, it does change
@@ -358,7 +357,7 @@ idx3 = (char*) &MyVar + 8
 

   Can GEP index into vector elements?
 
-
+
   This hasn't always been forcefully disallowed, though it's not recommended.
      It leads to awkward special cases in the optimizers, and fundamental
      inconsistency in the IR. In the future, it will probably be outright
@@ -371,7 +370,7 @@ idx3 = (char*) &MyVar + 8
 

   What effect do address spaces have on GEPs?
 
-
+
    None, except that the address space qualifier on the first operand pointer
       type always matches the address space qualifier on the result type.
 
@@ -384,7 +383,7 @@ idx3 = (char*) &MyVar + 8
     How is GEP different from ptrtoint, arithmetic, and inttoptr?
   
 
-
+
   It's very similar; there are only subtle differences.
 
   With ptrtoint, you have to pick an integer type. One approach is to pick i64;
@@ -416,7 +415,7 @@ idx3 = (char*) &MyVar + 8
     How do I do this?
   
 
-

+
   You don't. The integer computation implied by a GEP is target-independent.
      Typically what you'll need to do is make your backend pattern-match
      expressions trees involving ADD, MUL, etc., which are what GEP is lowered
@@ -437,7 +436,7 @@ idx3 = (char*) &MyVar + 8
 

   How does VLA addressing work with GEPs?
 
-
+
   GEPs don't natively support VLAs. LLVM's type system is entirely static,
      and GEP address computations are guided by an LLVM type.
 
@@ -453,16 +452,18 @@ idx3 = (char*) &MyVar + 8
      VLA and non-VLA indexing in the same manner.
 
 
+
+
 
 Rules
 
-
+
 
 
 
   What happens if an array index is out of bounds?
 
-
+
   There are two senses in which an array index can be out of bounds.
 
   First, there's the array type which comes from the (static) type of
@@ -504,7 +505,7 @@ idx3 = (char*) &MyVar + 8
 

   Can array indices be negative?
 
-
+
   Yes. This is basically a special case of array indices being out
      of bounds.
 
@@ -514,7 +515,7 @@ idx3 = (char*) &MyVar + 8
 
   Can I compare two values computed with GEPs?
 
-
+
   Yes. If both addresses are within the same allocated object, or 
      one-past-the-end, you'll get the comparison result you expect. If either
      is outside of it, integer arithmetic wrapping may occur, so the
@@ -529,7 +530,7 @@ idx3 = (char*) &MyVar + 8
     the underlying object?
   
 
-

+
   Yes. There are no restrictions on bitcasting a pointer value to an arbitrary
      pointer type. The types in a GEP serve only to define the parameters for the
      underlying integer computation. They need not correspond with the actual
@@ -548,7 +549,7 @@ idx3 = (char*) &MyVar + 8
     Can I cast an object's address to integer and add it to null?
   
 
-

+
   You can compute an address that way, but if you use GEP to do the add,
      you can't use that pointer to actually access the object, unless the
      object is managed outside of LLVM.
@@ -574,7 +575,7 @@ idx3 = (char*) &MyVar + 8
     that value to one address to compute the other address?
   
 
-
+
   As with arithmetic on null, You can use GEP to compute an address that
      way, but you can't use that pointer to actually access the object if you
      do, unless the object is managed outside of LLVM.
@@ -588,7 +589,7 @@ idx3 = (char*) &MyVar + 8
 
   Can I do type-based alias analysis on LLVM IR?
 
-
+
   You can't do type-based alias analysis using LLVM's built-in type system,
      because LLVM has no restrictions on mixing types in addressing, loads or
      stores.
@@ -605,7 +606,7 @@ idx3 = (char*) &MyVar + 8
 
   What happens if a GEP computation overflows?
 
-
+
    If the GEP lacks the inbounds keyword, the value is the result
       from evaluating the implied two's complement integer computation. However,
       since there's no guarantee of where an object will be allocated in the
@@ -637,7 +638,7 @@ idx3 = (char*) &MyVar + 8
     How can I tell if my front-end is following the rules?
   
 
-

+
    There is currently no checker for the getelementptr rules. Currently,
       the only way to do this is to manually check each place in your front-end
       where GetElementPtr operators are created.
@@ -650,16 +651,18 @@ idx3 = (char*) &MyVar + 8
 
 
 
+
+
 
 Rationale
 
-
+
 
 
 
   Why is GEP designed this way?
 
-
+
    The design of GEP has the following goals, in rough unofficial
       order of priority:
    
@@ -681,7 +684,7 @@ idx3 = (char*) &MyVar + 8
 
   Why do struct member indices always use i32?
 
-
+
   The specific type i32 is probably just a historical artifact, however it's
      wide enough for all practical purposes, so there's been no need to change it.
      It doesn't necessarily imply i32 address arithmetic; it's just an identifier
@@ -696,7 +699,7 @@ idx3 = (char*) &MyVar + 8
 

   What's an uglygep?
 
-
+
   Some LLVM optimizers operate on GEPs by internally lowering them into
      more primitive integer expressions, which allows them to be combined
      with other integer expressions and/or split into multiple separate
@@ -713,11 +716,13 @@ idx3 = (char*) &MyVar + 8
 
 
 
+
+
 
 Summary
 
 
-
+
   In summary, here's some things to always remember about the GetElementPtr
   instruction:
   
diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html
index 2bca7ae643a..7360893520f 100644
--- a/docs/GettingStarted.html
+++ b/docs/GettingStarted.html
@@ -75,7 +75,7 @@
 
 
 
-
+
 
 Welcome to LLVM! In order to get started, you first need to know some
 basic information.
@@ -107,7 +107,7 @@ and performance.
 
 
 
-
+
 
 Here's the short story for getting up and running quickly with LLVM:
 
@@ -196,20 +196,18 @@ Layout to learn about the layout of the source code tree.
 
 
 
-
+
 
 Before you begin to use the LLVM system, review the requirements given below.
 This may save you some trouble by knowing ahead of time what hardware and
 software you will need.
 
-
-
 
 
   Hardware
 
 
-
+
 
 LLVM is known to work on the following platforms:
 
@@ -373,7 +371,7 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.
 
   Software
 
-
+
   Compiling LLVM requires that you have several software packages 
   installed. The table below lists those required packages. The Package column
   is the usual name for the software package that LLVM depends on. The Version
@@ -514,7 +512,7 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.
   Broken versions of GCC and other tools
 
 
-
+
 
 LLVM is very demanding of the host C++ compiler, and as such tends to expose
 bugs in the compiler.  In particular, several versions of GCC crash when trying
@@ -607,7 +605,7 @@ upgrading to a newer version of Gold.
 
 
 
-
+
 
 
 
@@ -615,7 +613,7 @@ upgrading to a newer version of Gold.
 
 
 
-
+
 
 The remainder of this guide is meant to get you up and running with
 LLVM and to give you some basic information about the LLVM environment.
@@ -625,14 +623,13 @@ href="#layout">general layout of the the LLVM source tree, a simple example using the LLVM tool chain, and links to find more information about LLVM or to get
 help via e-mail.
-
 
 
 
   Terminology and Notation
 
 
-
+
 
 Throughout this manual, the following names are used to denote paths
 specific to the local system and working environment.  These are not
@@ -669,7 +666,7 @@ All these paths are absolute:

   Setting Up Your Environment
 
 
-
+
 
 
 In order to compile and use LLVM, you may need to set some environment
@@ -692,7 +689,7 @@ variables.
   Unpacking the LLVM Archives
 
 
-

+
 
 
 If you have the LLVM distribution, you will need to unpack it before you
@@ -726,7 +723,7 @@ compressed with the gzip program.
   Checkout LLVM from Subversion
 
 
-

+
 
 If you have access to our Subversion repository, you can get a fresh copy of
 the entire source code.  All you need to do is check it out from Subversion as
@@ -797,7 +794,7 @@ instructions to successfully get and build the LLVM GCC front-end.
   GIT mirror
 
 
-
+
 
 GIT mirrors are available for a number of LLVM subprojects. These mirrors
   sync automatically with each Subversion commit and contain all necessary
@@ -816,7 +813,7 @@ instructions to successfully get and build the LLVM GCC front-end.
   Install the GCC Front End
 
 
-
+
 
 Before configuring and compiling the LLVM suite (or if you want to use just the LLVM
 GCC front end) you can optionally extract the front end from the binary distribution.
@@ -886,7 +883,7 @@ please let us know how you would like to see things improved by dropping us a no
   Local LLVM Configuration
 
 
-

+
 
   Once checked out from the Subversion repository, the LLVM suite source 
   code must be
@@ -1008,7 +1005,7 @@ script to configure the build system:
   Compiling the LLVM Suite Source Code
 
 
-
+
 
 Once you have configured LLVM, you can build it.  There are three types of
 builds:
@@ -1142,7 +1139,7 @@ that directory that is out of date.
   Cross-Compiling LLVM
 
 
-
+
   It is possible to cross-compile LLVM itself. That is, you can create LLVM
   executables and libraries to be hosted on a platform different from the
   platform where they are build (a Canadian Cross build). To configure a
@@ -1160,7 +1157,7 @@ that directory that is out of date.
   The Location of LLVM Object Files
 
 
-
+
 
 The LLVM build system is capable of sharing a single LLVM source tree among
 several LLVM builds.  Hence, it is possible to build LLVM for several different
@@ -1220,7 +1217,7 @@ named after the build type:
   Optional Configuration Items
 
 
-
+
 
 
 If you're running on a Linux system that supports the "
 
+

+
 
 
   Program Layout
 
 
 
-
+
 
 One useful source of information about the LLVM source base is the LLVM doxygen documentation available at http://llvm.org/doxygen/.
 The following is a brief introduction to code layout:
 
-
-
 
 
   llvm/examples
 
 
-
+
   This directory contains some simple examples of how to use the LLVM IR and
   JIT.
 
@@ -1281,7 +1278,7 @@ The following is a brief introduction to code layout:
   llvm/include
 
 
-
+
 
 This directory contains public header files exported from the LLVM
 library. The three main subdirectories of this directory are:
@@ -1312,7 +1309,7 @@ library. The three main subdirectories of this directory are:
   llvm/lib
 
 
-
+
 
 This directory contains most of the source files of the LLVM system. In LLVM,
 almost all code exists in libraries, making it very easy to share code among the
@@ -1381,7 +1378,7 @@ different tools.
   llvm/projects
 
 
-
+
   This directory contains projects that are not strictly part of LLVM but are
   shipped with LLVM. This is also the directory where you should create your own
   LLVM-based projects. See llvm/projects/sample for an example of how
@@ -1393,7 +1390,7 @@ different tools.
   llvm/runtime
 
 
-
+
 
 This directory contains libraries which are compiled into LLVM bitcode and
 used when linking programs with the GCC front end.  Most of these libraries are
@@ -1410,7 +1407,7 @@ end to compile.
   llvm/test
 
 
-
+
   This directory contains feature and regression tests and other basic sanity
   checks on the LLVM infrastructure. These are intended to run quickly and cover
   a lot of territory without being exhaustive.
@@ -1421,7 +1418,7 @@ end to compile.
   test-suite
 
 
-
+
   This is not a directory in the normal llvm module; it is a separate
   Subversion
   module that must be checked out (usually to projects/test-suite). 
@@ -1440,7 +1437,7 @@ end to compile.
   llvm/tools
 
 
-
+
 
 The tools directory contains the executables built out of the
 libraries above, which form the main part of the user interface.  You can
@@ -1528,7 +1525,7 @@ information is in the Command Guide.
   llvm/utils
 
 
-
+
 
 This directory contains utilities for working with LLVM source code, and some
 of the utilities are actually required as part of the build process because they
@@ -1589,13 +1586,15 @@ are code generators for parts of LLVM infrastructure.
 
 
 
+
+
 
 
   An Example Using the LLVM Tool Chain
 
 
 
-
+
 This section gives an example of using LLVM.  llvm-gcc3 is now obsolete,
 so we only include instructions for llvm-gcc4.
 
@@ -1606,14 +1605,13 @@ create bitcode by default: gcc4 produces native code. As the example belo
 the '--emit-llvm' flag is needed to produce LLVM bitcode output. For makefiles and
 configure scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode
 output.
-
 
 
 
   Example with llvm-gcc4
 
 
-
+
 
 
   First, create a simple C file, name it 'hello.c':
@@ -1694,6 +1692,7 @@ int main() {
 
 
 
+
 
 
 
@@ -1701,7 +1700,7 @@ int main() {
 
 
 
-
+
 
 If you are having problems building or using LLVM, or if you have any other
 general questions about LLVM, please consult the Frequently
@@ -1715,7 +1714,7 @@ Asked Questions page.
 
 
 
-
+
 
 This document is just an introduction on how to use LLVM to do
 some simple things... there are many more interesting and complicated things
diff --git a/docs/GettingStartedVS.html b/docs/GettingStartedVS.html
index 469b5376afb..d6bf1b66839 100644
--- a/docs/GettingStartedVS.html
+++ b/docs/GettingStartedVS.html
@@ -36,7 +36,7 @@
 
 
 
-

+
 
   Welcome to LLVM on Windows! This document only covers LLVM on Windows using
   Visual Studio, not mingw or cygwin. In order to get started, you first need to
@@ -75,20 +75,18 @@
 
 
 
-

+
 
   Before you begin to use the LLVM system, review the requirements given
   below.  This may save you some trouble by knowing ahead of time what hardware
   and software you will need.
 
-
-
 
 
   Hardware
 
 
-
+
 
   Any system that can adequately run Visual Studio .NET 2005 SP1 is fine.
   The LLVM source tree and object files, libraries and executables will consume
@@ -98,7 +96,7 @@
 
 
 
Software
-
+
 
   You will need Visual Studio .NET 2005 SP1 or higher.  The VS2005 SP1
   beta and the normal VS2005 still have bugs that are not completely
@@ -118,13 +116,15 @@
 
 
 
+
+
 
 
   Getting Started
 
 
 
-
+
 
 Here's the short story for getting up and running quickly with LLVM:
 
@@ -234,7 +234,7 @@
 
 
 
-
+
 
 
   First, create a simple C file, name it 'hello.c':
@@ -324,7 +324,7 @@ int main() {
 
 
 
-
+
 
 If you are having problems building or using LLVM, or if you have any other
 general questions about LLVM, please consult the Frequently
@@ -338,7 +338,7 @@ Asked Questions page.
 
 
 
-
+
 
 This document is just an introduction to how to use LLVM to do
 some simple things... there are many more interesting and complicated things
diff --git a/docs/GoldPlugin.html b/docs/GoldPlugin.html
index 7ba11866278..e25c4575192 100644
--- a/docs/GoldPlugin.html
+++ b/docs/GoldPlugin.html
@@ -23,7 +23,7 @@
 
 
Introduction
 
-
+
   Building with link time optimization requires cooperation from the
 system linker. LTO support on Linux systems requires that you use
 the gold linker which supports
@@ -40,7 +40,7 @@ The same plugin can also be used by other tools such as ar and
 
 
How to build it
 
-
+
   You need to have gold with plugin support and build the LLVMgold
 plugin. Check whether you have gold running /usr/bin/ld -v. It will
 report “GNU gold” or else “GNU ld” if not. If you have
@@ -74,7 +74,7 @@ placed.
 
 
Usage
 
-
+
   The linker takes a -plugin option that points to the path of
   the plugin .so file. To find out what link command gcc
   would run in a given situation, run gcc -v [...] and look
@@ -95,14 +95,13 @@ placed.
   own gold, be sure to install the ar and nm-new you built to
   /usr/bin.
   

-
 
 
 
   Example of link time optimization
 
 
-
+
   The following example shows a worked example of the gold plugin mixing
   LLVM bitcode and native code.
 
@@ -149,6 +148,8 @@ $ llvm-gcc -use-gold-plugin a.a b.o -o main # <-- link with LLVMgold plugin
   example gold does not currently eliminate foo4.
 
 
+
+
 
 
   
@@ -156,7 +157,7 @@ $ llvm-gcc -use-gold-plugin a.a b.o -o main # <-- link with LLVMgold plugin
   
 
 
-
+
   Once your system ld, ar and nm all support LLVM
   bitcode, everything is in place for an easy to use LTO build of autotooled
   projects:
@@ -195,7 +196,7 @@ export CFLAGS="-O4"
 
 Licensing
 
-
+
   Gold is licensed under the GPLv3. LLVMgold uses the interface file
 plugin-api.h from gold which means that the resulting LLVMgold.so
 binary is also GPLv3. This can still be used to link non-GPLv3 programs just
diff --git a/docs/HowToReleaseLLVM.html b/docs/HowToReleaseLLVM.html
index 59e78646300..8a7d7f4b881 100644
--- a/docs/HowToReleaseLLVM.html
+++ b/docs/HowToReleaseLLVM.html
@@ -26,7 +26,7 @@
 
Introduction
 
 
-
+
 
 This document contains information about successfully releasing LLVM —
    including subprojects: e.g., llvm-gcc and clang — to
@@ -38,7 +38,7 @@
 
 
Release Timeline
 
-
+
 
 LLVM is released on a time based schedule — roughly every 6 months. We
    do not normally have dot releases because of the nature of LLVM's incremental
@@ -79,7 +79,7 @@
 
Release Process
 
 
-
+
 
 
   Release Administrative Tasks
@@ -119,12 +119,10 @@
   
 
 
-
-
 
 Release Administrative Tasks
 
-
+
 
 This section describes a few administrative tasks that need to be done for
    the release process to begin. Specifically, it involves:
@@ -135,12 +133,10 @@
   
Tagging release candidates for the release team to begin testing
 

 
-

-
 
 Create Release Branch
 
-
+
 
 Branch the Subversion trunk using the following procedure:
 
@@ -200,7 +196,7 @@ $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-
 
 Update LLVM Version
 
-
+
 
 After creating the LLVM release branch, update the release branches'
    autoconf and configure.ac versions from 'X.Ysvn'
@@ -216,7 +212,7 @@ $ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-
 
 
Build the LLVM Release Candidates
 
-
+
 
 Create release candidates for llvm, llvm-gcc,
    clang, and the LLVM test-suite by tagging the branch with
@@ -268,10 +264,12 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
 
+
+
 
 Building the Release
 
-
+
 
 The builds of llvm, llvm-gcc, and clang
    must be free of errors and warnings in Debug, Release+Asserts, and
@@ -287,12 +285,10 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
   ReleaseENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1
 
 
-
-
 
 Build LLVM
 
-
+
 
 Build Debug, Release+Asserts, and Release versions
    of llvm on all supported platforms. Directions to build
@@ -304,7 +300,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Build the LLVM GCC Binary Distribution
 
-
+
 
 Creating the llvm-gcc binary distribution (Release/Optimized)
    requires performing the following steps for each supported platform:
@@ -331,7 +327,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 Build Clang Binary Distribution
 
-
+
 
 Creating the clang binary distribution
    (Debug/Release+Asserts/Release) requires performing the following steps for
@@ -352,7 +348,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Target Specific Build Details
 
-
+
 
 The table below specifies which compilers are used for each Arch/OS
    combination when qualifying the build of llvm, llvm-gcc,
@@ -371,10 +367,12 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
 
+
+
 
 Building the Release
 
-
+
 
 A release is qualified when it has no regressions from the previous release
    (or baseline). Regressions are related to correctness first and performance
@@ -390,12 +388,10 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
    criteria, but these are the criteria which we found to be most important and
    which must be satisfied before a release can go out
 
-
-
 
 Qualify LLVM
 
-
+
 
 LLVM is qualified when it has a clean test run without a front-end. And it
    has no regressions when using either llvm-gcc or clang with
@@ -406,7 +402,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Qualify LLVM-GCC
 
-
+
 
 LLVM-GCC is qualified when front-end specific tests in the
    llvm regression test suite all pass and there are no regressions in
@@ -419,7 +415,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Qualify Clang
 
-
+
 
 Clang is qualified when front-end specific tests in the 
    llvm dejagnu test suite all pass, clang's own test suite passes
@@ -430,7 +426,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Specific Target Qualification Details
 
-
+
 
 
@@ -444,9 +440,11 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
 
+
+
 Community Testing
-
+
 
 Once all testing has been completed and appropriate bugs filed, the release
    candidate tarballs are put on the website and the LLVM community is
@@ -484,7 +482,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Release Patch Rules
 
-
+
 
 Below are the rules regarding patching the release branch:
 
@@ -508,19 +506,16 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 Release Final Tasks
 
-
+
 
 The final stages of the release process involves tagging the "final" release
    branch, updating documentation that refers to the release, and updating the
    demo page.
 
-
-
-
 
 Update Documentation
 
-
+
 
 Review the documentation and ensure that it is up to date. The "Release
    Notes" must be updated to reflect new features, bug fixes, new known issues,
@@ -534,7 +529,7 @@ $ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.g
 
 
Tag the LLVM Final Release
 
-
+
 
 Tag the final release sources using the following procedure:
 
@@ -556,20 +551,20 @@ $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
 
 
 
+
+
 
 Update the LLVM Demo Page
 
-
+
 
 The LLVM demo page must be updated to use the new release. This consists of
    using the new llvm-gcc binary and building LLVM.
 
-
-
 
 Update the LLVM Website
 
-
+
 
 The website must be updated before the release announcement is sent out. Here
    is what to do:
@@ -605,12 +600,16 @@ $ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
 
 Announce the Release
 
-
+
 
 Have Chris send out the release announcement when everything is finished.
 
 
 
+
+
+
+
 
 
 
diff --git a/docs/HowToSubmitABug.html b/docs/HowToSubmitABug.html
index ca34384621b..0af273f4031 100644
--- a/docs/HowToSubmitABug.html
+++ b/docs/HowToSubmitABug.html
@@ -42,7 +42,7 @@
 
 
 
-
+
 
 If you're working with LLVM and run into a bug, we definitely want to know
 about it.  This document describes what you can do to increase the odds of
@@ -81,7 +81,7 @@ information:
 
 
 
-
+
 
 More often than not, bugs in the compiler cause it to crash—often due
 to an assertion failure of some sort. The most important
@@ -109,14 +109,12 @@ with the following extra command line options:
 
 
 
-
-
 
 
   Front-end bugs
 
 
-
+
 
 If the problem is in the front-end, you should re-run the same
 llvm-gcc command that resulted in the crash, but add the
@@ -141,7 +139,7 @@ has instructions on the best way to use delta.
   Compile-time optimization bugs
 
 
-
+
 
 If you find that a bug crashes in the optimizer, compile your test-case to a
 .bc file by passing "-emit-llvm -O0 -c -o foo.bc".
@@ -175,7 +173,7 @@ that bugpoint emits.  If something goes wrong with bugpoint, please submit the
   Code generator bugs
 
 
-

+
 
 If you find a bug that crashes llvm-gcc in the code generator, compile your
 source file to a .bc file by passing "-emit-llvm -c -o foo.bc"
@@ -207,13 +205,15 @@ that bugpoint emits.  If something goes wrong with bugpoint, please submit the
 
 
 
+
+
 
 
   Miscompilations
 
 
 
-
+
 
 If llvm-gcc successfully produces an executable, but that executable doesn't
 run right, this is either a bug in the code or a bug in the
@@ -246,7 +246,7 @@ error.
 
 
 
-
+
 
 Similarly to debugging incorrect compilation by mis-behaving passes, you can
 debug incorrect code generation by either LLC or the JIT, using
diff --git a/docs/LangRef.html b/docs/LangRef.html
index 69e0a75951f..381fed5c6d3 100644
--- a/docs/LangRef.html
+++ b/docs/LangRef.html
@@ -324,7 +324,7 @@
 
Abstract
 
 
-
+
 
 This document is a reference manual for the LLVM assembly language. LLVM is
    a Static Single Assignment (SSA) based representation that provides type
@@ -338,7 +338,7 @@
 
Introduction
 
 
-
+
 
 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
@@ -359,14 +359,12 @@
    variable is never accessed outside of the current function, allowing it to
    be promoted to a simple SSA value instead of a memory location.
 
-
-
 
 
   Well-Formedness
 
 
-
+
 
 It is important to note that this document describes 'well formed' LLVM
    assembly language.  There is a difference between what the parser accepts and
@@ -386,13 +384,15 @@
 
 
 
+
+
 
 
 
 Identifiers
 
 
-
+
 
 LLVM identifiers come in two basic types: global and local. Global
    identifiers (functions, global variables) begin with the '@'
@@ -479,13 +479,13 @@
 
 
High Level Structure
 
-
+
 
 
   Module Structure
 
 
-
+
 
 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,
@@ -535,7 +535,7 @@ define i32 @main() {   ; i32()*  
   Linkage Types
 
 
-

+
 
 All Global Variables and Functions have one of the following types of
    linkage:
@@ -684,7 +684,7 @@ define i32 @main() {   ; i32()*  
   Calling Conventions
 
 
-
+
 
 LLVM functions, calls
    and invokes can all have an optional calling
@@ -757,7 +757,7 @@ define i32 @main() {   ; i32()*  
   Visibility Styles
 
 
-

+
 
 All Global Variables and Functions have one of the following visibility
    styles:
@@ -791,7 +791,7 @@ define i32 @main() {   ; i32()*  
   Named Types
 
 
-
+
 
 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
@@ -822,7 +822,7 @@ define i32 @main() {   ; i32()*  
   Global Variables
 
 
-

+
 
 Global variables define regions of memory allocated at compilation time
    instead of run-time.  Global variables may optionally be initialized, may
@@ -890,7 +890,7 @@ define i32 @main() {   ; i32()*  
   Functions
 
 
-

+
 
 LLVM function definitions consist of the "define" keyword, an
    optional linkage type, an optional
@@ -953,7 +953,7 @@ define [linkage] [visibility]
   Aliases
 
 
-

+
 
 Aliases act as "second name" for the aliasee value (which can be either
    function, global variable, another alias or bitcast of global value). Aliases
@@ -972,7 +972,7 @@ define [linkage] [visibility]
   Named Metadata
 
 
-

+
 
 Named metadata is a collection of metadata. Metadata
    nodes (but not metadata strings) are the only valid operands for
@@ -995,7 +995,7 @@ define [linkage] [visibility]
   Parameter Attributes
 
 
-

+
 
 The return type and each parameter of a function type may have a set of
    parameter attributes associated with them. Parameter attributes are
@@ -1106,7 +1106,7 @@ declare signext i8 @returns_signed_char()
   Garbage Collector Names
 
 
-

+
 
 Each function may specify a garbage collector name, which is simply a
    string:
@@ -1126,7 +1126,7 @@ define void @f() gc "name" { ... }
   Function Attributes
 
 
-
+
 
 Function attributes are set to communicate additional information about a
    function. Function attributes are considered to be part of the function, not
@@ -1249,7 +1249,7 @@ define void @f() optsize { ... }
   Module-Level Inline Assembly
 
 
-

+
 
 Modules may contain "module-level inline asm" blocks, which corresponds to
    the GCC "file scope inline asm" blocks.  These blocks are internally
@@ -1275,7 +1275,7 @@ module asm "more can go here"
   Data Layout
 
 
-

+
 
 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
@@ -1387,7 +1387,7 @@ target datalayout = "layout specification"
   Pointer Aliasing Rules
 
 
-

+
 
 Any memory access must be done through a pointer value associated
 with an address range of the memory access, otherwise the behavior
@@ -1451,7 +1451,7 @@ to implement type-based alias analysis.
   Volatile Memory Accesses
 
 
-
+
 
 Certain memory accesses, such as loads, stores, and 
 
 

 
+

+
 
 Type System
 
 
-
+
 
 The LLVM type system is one of the most important features of the
    intermediate representation.  Being typed enables a number of optimizations
@@ -1478,14 +1480,12 @@ synchronization behavior.
    and transformations that are not feasible to perform on normal three address
    code representations.
 
-
-
 
 
   Type Classifications
 
 
-
+
 
 The types fall into a few useful classifications:
 
@@ -1546,19 +1546,17 @@ synchronization behavior.
   Primitive Types
 
 
-
+
 
 The primitive types are the fundamental building blocks of the LLVM
    system.
 
-
-
 
 
   Integer Type
 
 
-
+
 
 Overview:
 The integer type is a very simple type that simply specifies an arbitrary
@@ -1596,7 +1594,7 @@ synchronization behavior.
   Floating Point Types
 
 
-
+
 
 

   Architecture OS llvm-gcc baseline clang baseline tests

 
@@ -1616,7 +1614,7 @@ synchronization behavior.
X86mmx Type
 
-
+
 
 Overview:
 The x86mmx type represents a value held in an MMX register on an x86 machine.  The operations allowed on it are quite limited:  parameters and return values, load and store, and bitcast.  User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type.  There are no arrays, vectors or constants of this type.
@@ -1633,7 +1631,7 @@ synchronization behavior.
   Void Type
 
 
-
+
 
 Overview:
 The void type does not represent any value and has no size.
@@ -1650,7 +1648,7 @@ synchronization behavior.
   Label Type
 
 
-
+
 
 Overview:
 The label type represents code labels.
@@ -1667,7 +1665,7 @@ synchronization behavior.
   Metadata Type
 
 
-
+
 
 Overview:
 The metadata type represents embedded metadata. No derived types may be
@@ -1681,13 +1679,14 @@ synchronization behavior.
 
 
 
+
 
 
 
   Derived Types
 
 
-
+
 
 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
@@ -1697,14 +1696,12 @@ synchronization behavior.
    of another array.
 
    
-
-
 
 
   Aggregate Types
 
 
-
+
 
 Aggregate Types are a subset of derived types that can contain multiple
   member types. Arrays,
@@ -1718,7 +1715,7 @@ synchronization behavior.
   Array Type
 
 
-
+
 
 Overview:
 The array type is a very simple derived type that arranges elements
@@ -1778,7 +1775,7 @@ synchronization behavior.
   Function Type
 
 
-
+
 
 Overview:
 The function type can be thought of as a function signature.  It consists of
@@ -1833,7 +1830,7 @@ synchronization behavior.
   Structure Type
 
 
-
+
 
 Overview:
 The structure type is used to represent a collection of data members together
@@ -1873,7 +1870,7 @@ synchronization behavior.
   Packed Structure Type
 
 
-
+
 
 Overview:
 The packed structure type is used to represent a collection of data members
@@ -1912,7 +1909,7 @@ synchronization behavior.
   Pointer Type
 
 
-
+
 
 Overview:
 The pointer type is used to specify memory locations.
@@ -1958,7 +1955,7 @@ synchronization behavior.
   Vector Type
 
 
-
+
 
 Overview:
 A vector type is a simple derived type that represents a vector of elements.
@@ -1999,7 +1996,7 @@ synchronization behavior.
   Opaque Type
 
 
-
+
 
 Overview:
 Opaque types are used to represent unknown types in the system.  This
@@ -2022,12 +2019,14 @@ synchronization behavior.
 
 
 
+
+
 
 
   Type Up-references
 
 
-
+
 
 Overview:
 An "up reference" allows you to refer to a lexically enclosing type without
@@ -2070,23 +2069,23 @@ synchronization behavior.
 
 
 
+
+
 
 Constants
 
 
-
+
 
 LLVM has several different basic types of constants.  This section describes
    them all and their syntax.
 
-
-
 
 
   Simple Constants
 
 
-
+
 
 
   Boolean constants
@@ -2144,7 +2143,7 @@ synchronization behavior.
 Complex Constants
 
 
-
+
 
 Complex constants are a (potentially recursive) combination of simple
    constants and smaller complex constants.
@@ -2198,7 +2197,7 @@ synchronization behavior.
   Global Variable and Function Addresses
 
 
-
+
 
 The addresses of global variables
    and functions are always implicitly valid
@@ -2220,7 +2219,7 @@ synchronization behavior.
   Undefined Values
 
 
-
+
 
 The string 'undef' can be used anywhere a constant is expected, and
    indicates that the user of the value may receive an unspecified bit-pattern.
@@ -2363,7 +2362,7 @@ b: unreachable
   Trap Values
 
 
-

+
 
 Trap values are similar to undef values, however
    instead of representing an unspecified bit pattern, they represent the
@@ -2491,7 +2490,7 @@ second_end:
   Addresses of Basic Blocks
 
 
-

+
 
 blockaddress(@function, %block)
 
@@ -2520,7 +2519,7 @@ second_end:
   Constant Expressions
 
 
-
+
 
 Constant expressions are used to allow expressions involving other constants
    to be used as constants.  Constant expressions may be of
@@ -2646,16 +2645,18 @@ second_end:
 
 
 
+
+
 
 Other Values
 
-
+
 
 
 Inline Assembler Expressions
 
 
-
+
 
 LLVM supports inline assembler expressions (as opposed
    to  Module-Level Inline Assembly) through the use of
@@ -2704,13 +2705,12 @@ call void asm alignstack "eieio", ""()
    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.
-
 
 
 Inline Asm Metadata
 
 
-
+
 
 The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode
    attached to it that contains a list of constant integers.  If present, the
@@ -2731,12 +2731,14 @@ call void asm sideeffect "something bad", ""(), !srcloc !42
 
 
 
+
+
 
 
   Metadata Nodes and Metadata Strings
 
 
-
+
 
 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
@@ -2778,13 +2780,14 @@ call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
 
 
 
+
 
 
 
   Intrinsic Global Variables
 
 
-
+
 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 "llvm.metadata".  This
@@ -2796,7 +2799,7 @@ by LLVM.
 The 'llvm.used' Global Variable
 
 
-
+
 
 The @llvm.used global is an array with i8* element type which has appending linkage.  This array contains a list of
@@ -2833,7 +2836,7 @@ object file to prevent the assembler and linker from molesting the symbol.
   
 
 
-
+
 
 The @llvm.compiler.used directive is the same as the
 @llvm.used directive, except that it only prevents the compiler from
@@ -2851,7 +2854,7 @@ should not be exposed to source languages.
 The 'llvm.global_ctors' Global Variable
 
 
-
+
  %0 = type { i32, void ()* }
 @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
@@ -2866,7 +2869,7 @@ should not be exposed to source languages.
 The 'llvm.global_dtors' Global Variable
 
 
-
+
  %0 = type { i32, void ()* }
 @llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
@@ -2877,12 +2880,13 @@ should not be exposed to source languages.
 
 
 
+
 
 
 Instruction Reference
 
 
-
+
 
 The LLVM instruction set consists of several different classifications of
    instructions: terminator
@@ -2891,14 +2895,12 @@ should not be exposed to source languages.

    memory instructions, and
    other instructions.
 
-
-
 
 
   Terminator Instructions
 
 
-
+
 
 As mentioned previously, every basic block
    in a program ends with a "Terminator" instruction, which indicates which
@@ -2916,14 +2918,12 @@ should not be exposed to source languages.
    'unwind' instruction, and the
    'unreachable' instruction.
 
-
-
 
 
   'ret' Instruction
 
 
-
+
 
 Syntax:
 @@ -2973,7 +2973,7 @@ should not be exposed to source languages.
   'br' Instruction
 
 
-
+
 
 Syntax:
 @@ -3016,7 +3016,7 @@ IfUnequal:
    'switch' Instruction
 
 
-
+
 
 Syntax:
 @@ -3071,7 +3071,7 @@ IfUnequal:
    'indirectbr' Instruction
 
 
-
+
 
 Syntax:
 @@ -3119,7 +3119,7 @@ IfUnequal:
   'invoke' Instruction
 
 
-
+
 
 Syntax:
 @@ -3209,7 +3209,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'unwind' Instruction
 
 
-
+
 
 Syntax:
 @@ -3241,7 +3241,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'unreachable' Instruction
 
 
-
+
 
 Syntax:
 @@ -3259,12 +3259,14 @@ that the invoke/unwind semantics are likely to change in future versions.
 
 
 
+
+
 
 
   Binary Operations
 
 
-
+
 
 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
@@ -3274,14 +3276,12 @@ that the invoke/unwind semantics are likely to change in future versions.
 
 There are several different binary operators:
 
-
-
 
 
   'add' Instruction
 
 
-
+
 
 Syntax:
 @@ -3326,7 +3326,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'fadd' Instruction
 
 
-
+
 
 Syntax:
 @@ -3356,7 +3356,7 @@ that the invoke/unwind semantics are likely to change in future versions.
    'sub' Instruction
 
 
-
+
 
 Syntax:
 @@ -3408,7 +3408,7 @@ that the invoke/unwind semantics are likely to change in future versions.
    'fsub' Instruction
 
 
-
+
 
 Syntax:
 @@ -3444,7 +3444,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'mul' Instruction
 
 
-
+
 
 Syntax:
 @@ -3494,7 +3494,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'fmul' Instruction
 
 
-
+
 
 Syntax:
 @@ -3524,7 +3524,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'udiv' Instruction
 
 
-
+
 
 Syntax:
 @@ -3565,7 +3565,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'sdiv' Instruction
 
 
-
+
 
 Syntax:
 @@ -3608,7 +3608,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'fdiv' Instruction
 
 
-
+
 
 Syntax:
 @@ -3638,7 +3638,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'urem' Instruction
 
 
-
+
 
 Syntax:
 @@ -3676,7 +3676,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'srem' Instruction
 
 
-
+
 
 Syntax:
 @@ -3727,7 +3727,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'frem' Instruction
 
 
-
+
 
 Syntax:
 @@ -3754,12 +3754,14 @@ that the invoke/unwind semantics are likely to change in future versions.
 
 
 
+
+
 
 
   Bitwise Binary Operations
 
 
-
+
 
 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
@@ -3767,14 +3769,12 @@ that the invoke/unwind semantics are likely to change in future versions.
    same type, execute an operation on them, and produce a single value.  The
    resulting value is the same type as its operands.
 
-
-
 
 
   'shl' Instruction
 
 
-
+
 
 Syntax:
 @@ -3825,7 +3825,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'lshr' Instruction
 
 
-
+
 
 Syntax:
 @@ -3872,7 +3872,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'ashr' Instruction
 
 
-
+
 
 Syntax:
 @@ -3919,7 +3919,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'and' Instruction
 
 
-
+
 
 Syntax:
 @@ -3980,7 +3980,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'or' Instruction
 
 
-
+
 
 Syntax:
 @@ -4043,7 +4043,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'xor' Instruction
 
 
-
+
 
 Syntax:
 @@ -4103,12 +4103,14 @@ that the invoke/unwind semantics are likely to change in future versions.
 
 
 
+
+
 
 
   Vector Operations
 
 
-
+
 
 LLVM supports several instructions to represent vector operations in a
    target-independent manner.  These instructions cover the element-access and
@@ -4117,14 +4119,12 @@ that the invoke/unwind semantics are likely to change in future versions.
    will want to use target-specific intrinsics to take full advantage of a
    specific target.
 
-
-
 
 
    'extractelement' Instruction
 
 
-
+
 
 Syntax:
 @@ -4160,7 +4160,7 @@ that the invoke/unwind semantics are likely to change in future versions.
    'insertelement' Instruction
 
 
-
+
 
 Syntax:
 @@ -4196,7 +4196,7 @@ that the invoke/unwind semantics are likely to change in future versions.
    'shufflevector' Instruction
 
 
-
+
 
 Syntax:
 @@ -4239,24 +4239,24 @@ that the invoke/unwind semantics are likely to change in future versions.
 
 
 
+
+
 
 
   Aggregate Operations
 
 
-
+
 
 LLVM supports several instructions for working with
   aggregate values.
 
-
-
 
 
    'extractvalue' Instruction
 
 
-
+
 
 Syntax:
 @@ -4298,7 +4298,7 @@ that the invoke/unwind semantics are likely to change in future versions.
    'insertvalue' Instruction
 
 
-
+
 
 Syntax:
 @@ -4332,27 +4332,26 @@ that the invoke/unwind semantics are likely to change in future versions.
 
 
 
+
 
 
 
   Memory Access and Addressing Operations
 
 
-
+
 
 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.
 
-
-
 
 
   'alloca' Instruction
 
 
-
+
 
 Syntax:
 @@ -4403,7 +4402,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'load' Instruction
 
 
-
+
 
 Syntax:
 @@ -4462,7 +4461,7 @@ that the invoke/unwind semantics are likely to change in future versions.
   'store' Instruction
 
 
-
+
 
 Syntax:
 @@ -4524,7 +4523,7 @@ that the invoke/unwind semantics are likely to change in future versions.
    'getelementptr' Instruction
 
 
-
+
 
 Syntax:
 @@ -4650,25 +4649,25 @@ entry:
 
 
 
+
+
 
 
   Conversion Operations
 
 
-
+
 
 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.
 
-
-
 
 
    'trunc .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4708,7 +4707,7 @@ entry:
    'zext .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4748,7 +4747,7 @@ entry:
    'sext .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4787,7 +4786,7 @@ entry:
    'fptrunc .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4825,7 +4824,7 @@ entry:
    'fpext .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4862,7 +4861,7 @@ entry:
    'fptoui .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4900,7 +4899,7 @@ entry:
    'fptosi .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4939,7 +4938,7 @@ entry:
    'uitofp .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -4976,7 +4975,7 @@ entry:
    'sitofp .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -5012,7 +5011,7 @@ entry:
    'ptrtoint .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -5050,7 +5049,7 @@ entry:
    'inttoptr .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -5088,7 +5087,7 @@ entry:
    'bitcast .. to' Instruction
 
 
-
+
 
 Syntax:
 @@ -5127,24 +5126,24 @@ entry:
 
 
 
+
+
 
 
   Other Operations
 
 
-
+
 
 The instructions in this category are the "miscellaneous" instructions, which
    defy better classification.
 
-
-
 
 
   'icmp' Instruction
 
 
-
+
 
 Syntax:
 @@ -5247,7 +5246,7 @@ entry:
   'fcmp' Instruction
 
 
-
+
 
 Syntax:
 @@ -5368,7 +5367,7 @@ entry:
   'phi' Instruction
 
 
-
+
 
 Syntax:
 @@ -5416,7 +5415,7 @@ Loop:       ; Infinite loop that counts from 0 on up...
    'select' Instruction
 
 
-
+
 
 Syntax:
 @@ -5459,7 +5458,7 @@ Loop:       ; Infinite loop that counts from 0 on up...
   'call' Instruction
 
 
-
+
 
 Syntax:
 @@ -5568,7 +5567,7 @@ freestanding environments and non-C-based languages.
   'va_arg' Instruction
 
 
-
+
 
 Syntax:
 @@ -5609,11 +5608,15 @@ freestanding environments and non-C-based languages.
 
 
 
+
+
+
+
 
 Intrinsic Functions
 
 
-
+
 
 LLVM supports the notion of an "intrinsic function".  These functions have
    well known names and semantics and are required to follow certain
@@ -5656,14 +5659,12 @@ freestanding environments and non-C-based languages.
 To learn how to add an intrinsic function, please see the
    Extending LLVM Guide.
 
-
-
 
 
   Variable Argument Handling Intrinsics
 
 
-
+
 
 Variable argument support is defined in LLVM with
    the va_arg instruction and these three
@@ -5705,15 +5706,13 @@ declare void @llvm.va_copy(i8*, i8*)
 declare void @llvm.va_end(i8*)
 
 
-
-
 
 
   'llvm.va_start' Intrinsic
 
 
 
-
+
 
 Syntax:
 @@ -5743,7 +5742,7 @@ declare void @llvm.va_end(i8*)
  'llvm.va_end' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -5774,7 +5773,7 @@ declare void @llvm.va_end(i8*)
   'llvm.va_copy' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -5800,12 +5799,14 @@ declare void @llvm.va_end(i8*)
 
 
 
+
+
 
 
   Accurate Garbage Collection Intrinsics
 
 
-
+
 
 LLVM support for Accurate Garbage
 Collection (GC) requires the implementation and generation of these
@@ -5820,14 +5821,12 @@ LLVM.
 The garbage collection intrinsics only operate on objects in the generic
    address space (address space zero).
 
-
-
 
 
   'llvm.gcroot' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -5858,7 +5857,7 @@ LLVM.
   'llvm.gcread' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -5890,7 +5889,7 @@ LLVM.
   'llvm.gcwrite' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -5917,24 +5916,24 @@ LLVM.
 
 
 
+
+
 
 
   Code Generator Intrinsics
 
 
-
+
 
 These intrinsics are provided by LLVM to expose special features that may
    only be implemented with code generator support.
 
-
-
 
 
   'llvm.returnaddress' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -5969,7 +5968,7 @@ LLVM.
   'llvm.frameaddress' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -6003,7 +6002,7 @@ LLVM.
   'llvm.stacksave' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -6033,7 +6032,7 @@ LLVM.
   'llvm.stackrestore' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -6058,7 +6057,7 @@ LLVM.
   'llvm.prefetch' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -6091,7 +6090,7 @@ LLVM.
   'llvm.pcmarker' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -6122,7 +6121,7 @@ LLVM.
   'llvm.readcyclecounter' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -6144,26 +6143,26 @@ LLVM.
 
 
 
+
+
 
 
   Standard C Library Intrinsics
 
 
-
+
 
 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.
 
-
-
 
 
   'llvm.memcpy' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.memcpy on any
@@ -6217,7 +6216,7 @@ LLVM.
   'llvm.memmove' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.memmove on any integer bit
@@ -6273,7 +6272,7 @@ LLVM.
   'llvm.memset.*' Intrinsics
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.memset on any integer bit
@@ -6323,7 +6322,7 @@ LLVM.
   'llvm.sqrt.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.sqrt on any
@@ -6361,7 +6360,7 @@ LLVM.
   'llvm.powi.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.powi on any
@@ -6397,7 +6396,7 @@ LLVM.
   'llvm.sin.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.sin on any
@@ -6431,7 +6430,7 @@ LLVM.
   'llvm.cos.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.cos on any
@@ -6465,7 +6464,7 @@ LLVM.
   'llvm.pow.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.pow on any
@@ -6495,24 +6494,24 @@ LLVM.
 
 
 
+
+
 
 
   Bit Manipulation Intrinsics
 
 
-
+
 
 LLVM provides intrinsics for a few important bit manipulation operations.
    These allow efficient code generation for some algorithms.
 
-
-
 
 
   'llvm.bswap.*' Intrinsics
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic function. You can use bswap on any integer
@@ -6547,7 +6546,7 @@ LLVM.
   'llvm.ctpop.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit
@@ -6579,7 +6578,7 @@ LLVM.
   'llvm.ctlz.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.ctlz on any
@@ -6613,7 +6612,7 @@ LLVM.
   'llvm.cttz.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.cttz on any
@@ -6642,17 +6641,17 @@ LLVM.
 
 
 
+
+
 
 
   Arithmetic with Overflow Intrinsics
 
 
-
+
 
 LLVM provides intrinsics for some arithmetic with overflow operations.
 
-
-
 
 
   
@@ -6660,7 +6659,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.sadd.with.overflow
@@ -6708,7 +6707,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.uadd.with.overflow
@@ -6755,7 +6754,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.ssub.with.overflow
@@ -6803,7 +6802,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.usub.with.overflow
@@ -6851,7 +6850,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.smul.with.overflow
@@ -6900,7 +6899,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.umul.with.overflow
@@ -6941,12 +6940,14 @@ LLVM.
 
 
 
+
+
 
 
   Half Precision Floating Point Intrinsics
 
 
-
+
 
 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
@@ -6960,7 +6961,6 @@ LLVM.
    float if needed, then converted to i16 with
    llvm.convert.to.fp16, then
    storing as an i16 value.
-
 
 
 
@@ -6969,7 +6969,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 @@ -7006,7 +7006,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 @@ -7036,12 +7036,14 @@ LLVM.
 
 
 
+
+
 
 
   Debugger Intrinsics
 
 
-
+
 
 The LLVM debugger intrinsics (which all start with llvm.dbg.
    prefix), are described in
@@ -7055,7 +7057,7 @@ LLVM.
   Exception Handling Intrinsics
 
 
-
+
 
 The LLVM exception handling intrinsics (which all start with
    llvm.eh. prefix), are described in
@@ -7069,7 +7071,7 @@ LLVM.
   Trampoline Intrinsic
 
 
-
+
 
 This intrinsic makes it possible to excise one parameter, marked with
    the nest attribute, from a function.
@@ -7095,8 +7097,6 @@ LLVM.
 The call %val = call i32 %fp(i32 %x, i32 %y) is then equivalent
    to %val = call i32 %f(i8* %nval, i32 %x, i32 %y).
 
-
-
 
 
   
@@ -7104,7 +7104,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 @@ -7141,12 +7141,14 @@ LLVM.
 
 
 
+
+
 
 
   Atomic Operations and Synchronization Intrinsics
 
 
-
+
 
 These intrinsic functions expand the "universal IR" of LLVM to represent
    hardware constructs for atomic operations and memory synchronization.  This
@@ -7166,14 +7168,12 @@ LLVM.
    No one model or paradigm should be selected above others unless the hardware
    itself ubiquitously does so.
 
-
-
 
 
   'llvm.memory.barrier' Intrinsic
 
 
-
+
 Syntax:
    declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)
@@ -7245,7 +7245,7 @@ LLVM.
   'llvm.atomic.cmp.swap.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on
@@ -7305,7 +7305,7 @@ LLVM.
   'llvm.atomic.swap.*' Intrinsic
 
 
-
+
 Syntax:
 
 This is an overloaded intrinsic. You can use llvm.atomic.swap on any
@@ -7362,7 +7362,7 @@ LLVM.
   'llvm.atomic.load.add.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.atomic.load.add on
@@ -7411,7 +7411,7 @@ LLVM.
   'llvm.atomic.load.sub.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use llvm.atomic.load.sub on
@@ -7476,7 +7476,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 These are overloaded intrinsics. You can
@@ -7567,7 +7567,7 @@ LLVM.
   
 
 
-
+
 
 Syntax:
 These are overloaded intrinsics. You can use llvm.atomic.load_max,
@@ -7638,25 +7638,24 @@ LLVM.
 
 
 
+
 
 
 
   Memory Use Markers
 
 
-
+
 
 This class of intrinsics exists to information about the lifetime of memory
    objects and ranges where variables are immutable.
 
-
-
 
 
   'llvm.lifetime.start' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7686,7 +7685,7 @@ LLVM.
   'llvm.lifetime.end' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7715,7 +7714,7 @@ LLVM.
   'llvm.invariant.start' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7743,7 +7742,7 @@ LLVM.
   'llvm.invariant.end' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7765,24 +7764,24 @@ LLVM.
 
 
 
+
+
 
 
   General Intrinsics
 
 
-
+
 
 This class of intrinsics is designed to be generic and has no specific
    purpose.
 
-
-
 
 
   'llvm.var.annotation' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7810,7 +7809,7 @@ LLVM.
   'llvm.annotation.*' Intrinsic
 
 
-
+
 
 Syntax:
 This is an overloaded intrinsic. You can use 'llvm.annotation' on
@@ -7846,7 +7845,7 @@ LLVM.
   'llvm.trap' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7871,7 +7870,7 @@ LLVM.
   'llvm.stackprotector' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7905,7 +7904,7 @@ LLVM.
   'llvm.objectsize' Intrinsic
 
 
-
+
 
 Syntax:
 @@ -7935,6 +7934,10 @@ LLVM.
 
 
 
+
+
+
+
 
 
 
diff --git a/docs/Lexicon.html b/docs/Lexicon.html
index 458da8013ed..b1c2638e682 100644
--- a/docs/Lexicon.html
+++ b/docs/Lexicon.html
@@ -14,7 +14,7 @@
 
 Table Of Contents
 
-
+
   

   
   
 
@@ -85,9 +85,10 @@
 Definitions
+
 
 - A -
-
+
   
     ADCE
     Aggressive Dead Code Elimination
@@ -95,7 +96,7 @@
 
 
 - B -
-
+
   
     BURS
     Bottom Up Rewriting System—A method of instruction selection for
@@ -105,7 +106,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - C -
-
+
   
     CSE
     Common Subexpression Elimination. An optimization that removes common
@@ -117,7 +118,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - D -
-
+
   
     DAG
     Directed Acyclic Graph
@@ -137,7 +138,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - G -
-
+
   
     GC
     Garbage Collection. The practice of using reachability analysis instead
@@ -146,7 +147,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - H -
-
+
   
     Heap
     In garbage collection, the region of memory which is managed using
@@ -155,7 +156,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - I -
-
+
   
     IPA
     Inter-Procedural Analysis. Refers to any variety of code analysis that
@@ -170,7 +171,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - L -
-
+
   
     LCSSA
     Loop-Closed Static Single Assignment Form
@@ -184,7 +185,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - M -
-
+
   
     MC
     Machine Code
@@ -192,7 +193,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - O -
-
+
   
     Object Pointer
     A pointer to an object such that the garbage collector is able to trace
@@ -203,7 +204,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - P -
-
+
   
     PRE
     Partial Redundancy Elimination
@@ -212,7 +213,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - R -
-
+
   
   	RAUW
 An abbreviation for Replace
   	All Uses With. The functions User::replaceUsesOfWith(), 
@@ -235,7 +236,7 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
 
 
 - S -
-
+
   
     Safe Point
     In garbage collection, it is necessary to identify stack
@@ -261,6 +262,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
     function.
   
 
+
+
 
 
  
 
 
-
+
 
 LLVM features powerful intermodular optimizations which can be used at link 
 time.  Link Time Optimization (LTO) is another name for intermodular optimization 
@@ -55,7 +55,7 @@ and design between the LTO optimizer and the linker.
 
 
 
-
+
 
 The LLVM Link Time Optimizer provides complete transparency, while doing 
 intermodular optimization, in the compiler tool chain. Its main goal is to let 
@@ -69,14 +69,13 @@ 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.
 
-
 
 
 
   Example of link time optimization
 
 
-
+
   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,
@@ -149,7 +148,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   Alternative Approaches
 
 
-

+
   
     Compiler driver invokes link time optimizer separately.
     In this model the link time optimizer is not able to take advantage of 
@@ -175,12 +174,14 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   
 
 
+
+
 
 
   Multi-phase communication between libLTO and linker
 
 
-
+
   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 
@@ -192,14 +193,13 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   Our goal is to take advantage of tight integration between the linker and 
   the optimizer by sharing this information during various linking phases.
 
-
 
 
 
   Phase 1 : Read LLVM Bitcode Files
 
 
-
+
   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
@@ -223,7 +223,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   Phase 2 : Symbol Resolution
 
 
-

+
   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 
@@ -236,7 +236,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
 

   Phase 3 : Optimize Bitcode Files
 
-
+
   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 foo1() is used by native object files using 
@@ -252,7 +252,7 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   Phase 4 : Symbol Resolution after optimization
 
 
-

+
   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 
@@ -264,12 +264,14 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   bitcode files.
 
 
+
+
 
 
 libLTO
 
 
-
+
   libLTO is a shared object that is part of the LLVM tools, and 
   is intended for use by a linker. libLTO provides an abstract C 
   interface to use the LLVM interprocedural optimizer without exposing details 
@@ -278,14 +280,13 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
   be possible for a completely different compilation technology to provide
   a different libLTO that works with their object files and the standard
   linker tool.
-
 
 
 
   lto_module_t
 
 
-
+
 
 A non-native object file is handled via an lto_module_t.  
 The following functions allow the linker to check if a file (on disk
@@ -329,7 +330,7 @@ lto_module_get_symbol_attribute(lto_module_t, unsigned int)
   lto_code_gen_t
 
 
-

+
 
 Once the linker has loaded each non-native object files into an
 lto_module_t, it can request libLTO to process them all and
@@ -371,6 +372,8 @@ of the native object files.
 
 
 
+
+
 
 
 
diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html
index a85314ab282..ee0115d209c 100644
--- a/docs/MakefileGuide.html
+++ b/docs/MakefileGuide.html
@@ -80,7 +80,7 @@
 Introduction
 
 
-
+
   This document provides usage 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.
@@ -102,17 +102,16 @@
 
General Concepts
 
 
-
+
   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.
-
 
 
 Projects
-
+
   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 llvm/projects directory. Any directory under projects
@@ -130,7 +129,7 @@
 
 
 
Variable Values
-
+
   To use the makefile system, you simply create a file named 
   Makefile in your directory and declare values for certain variables. 
   The variables and values that you select determine what the makefile system
@@ -140,15 +139,14 @@
 
 
 
Including Makefiles
-
+
   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.
-
 
 
 Makefile
-
+
   Each directory to participate in the build needs to have a file named
   Makefile. This is the file first read by make. It has three
   sections:
@@ -164,7 +162,7 @@
 
 
 Makefile.common
-
+
   Every project must have a Makefile.common file at its top source 
   directory. This file serves three purposes:
   
@@ -182,7 +180,7 @@
 
 
 Makefile.config
-
+
   Every project must have a Makefile.config at the top of its
   build directory. This file is generated by the
   configure script from the pattern provided by the
@@ -195,7 +193,7 @@
 
 
 
Makefile.rules
-
+
   This file, located at $(LLVM_SRC_ROOT)/Makefile.rules 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
@@ -203,9 +201,11 @@
   have been set before Makefile.rules is included.
 
 
+
+
 
 Comments
-
+
   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.
@@ -213,19 +213,20 @@
   by make.
 
 
+
+
 
 Tutorial
 
-
+
   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.
-
 
 
 Libraries
-
+
   Only a few variable definitions are needed to build a regular library.
   Normally, the makefile system will build all the software into a single
   libname.o (pre-linked) object. This means the library is not
@@ -254,11 +255,10 @@
   -load option. See the 
   WritingAnLLVMPass.html document
   for an example of why you might want to do this.
-
 
 
 Bitcode Modules
-
+
   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
@@ -281,7 +281,7 @@
 

   Loadable Modules
 
-
+
   In some situations, you need to create a loadable module. Loadable modules
   can be loaded into programs like opt or llc to specify
   additional passes to run or targets to support.  Loadable modules are also
@@ -309,9 +309,11 @@
   library which is part of lib/System implementation.
 
 
+
+
 
 Tools
-
+
   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:
@@ -342,11 +344,10 @@
   syntax is used. Note that in order to use the .a suffix, the library
   in question must have been built with the ARCHIVE_LIBRARY option set.
   
-
 
 
 JIT Tools
-
+
   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
@@ -365,11 +366,15 @@
   
 
 
+
+
+
+
 
 Targets Supported
 
 
-
+
   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
@@ -424,11 +429,10 @@
       

     - A -
     
 
 Remove built objects from installation directory.
     
   
-
 
 
 all (default)
-
+
   When you invoke make 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 
@@ -439,14 +443,14 @@
 
 
 
all-local
-
+
   This target is the same as all but it operates only on
   the current directory instead of recursively.
 
 
 
 check
-
+
   This target can be invoked from anywhere within a project's directories
   but always invokes the check-local target 
   in the project's test directory, if it exists and has a 
@@ -463,7 +467,7 @@
 
 
 
check-local
-
+
   This target should be implemented by the Makefile in the project's
   test directory. It is invoked by the check target elsewhere.
   Each project is free to define the actions of check-local as 
@@ -474,7 +478,7 @@
 
 
 
clean
-
+
   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 rm -f $(UNSET_VARIABLE)/* which will attempt
@@ -483,14 +487,14 @@
 
 
 
clean-local
-
+
   This target does the same thing as clean but only for the current
   (local) directory.
 
 
 
 dist
-
+
   This target builds a distribution tarball. It first builds the entire
   project using the all target and then tars up the necessary files and
   compresses it. The generated tarball is sufficient for a casual source 
@@ -499,7 +503,7 @@
 
 
 
dist-check
-
+
   This target does the same thing as the dist 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
@@ -511,7 +515,7 @@
 
 
 
dist-clean
-
+
   This is a special form of the clean clean target. It performs a
   normal clean but also removes things pertaining to building the
   distribution.
@@ -519,7 +523,7 @@
 
 
 install
-
+
   This target finalizes shared objects and executables and copies all
   libraries, headers, executables and documentation to the directory given 
   with the --prefix option to configure.  When completed, 
@@ -537,7 +541,7 @@
 
 
 
preconditions
-
+
   This utility target checks to see if the Makefile in the object
   directory is older than the Makefile in the source directory and
   copies it if so. It also reruns the configure script if that needs to
@@ -548,14 +552,14 @@
 
 
 
printvars
-
+
   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. 
 
 
 
 reconfigure
-
+
   This utility target will force a reconfigure of LLVM or your project. It 
   simply runs $(PROJ_OBJ_ROOT)/config.status --recheck to rerun the
   configuration tests and rebuild the configured files. This isn't generally
@@ -565,7 +569,7 @@
 
 
 
spotless
-
+
   This utility target, only available when $(PROJ_OBJ_ROOT) is not 
   the same as $(PROJ_SRC_ROOT), will completely clean the
   $(PROJ_OBJ_ROOT) directory by removing its content entirely and 
@@ -577,7 +581,7 @@
 
 
 
tags
-
+
   This target will generate a TAGS 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
@@ -586,17 +590,19 @@
 
 
 
uninstall
-
+
   This target is the opposite of the install 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).
 
 
+
+
 
 Variables
 
-
+
   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
@@ -604,11 +610,10 @@
   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.
-
 
 
 Control Variables
-
+
   Variables listed in the table below should be set before the 
   inclusion of $(LEVEL)/Makefile.common.
   These variables provide input to the LLVM make system that tell it what to do 
@@ -761,7 +766,7 @@
 
 
 
Override Variables
-
+
   Override variables can be used to override the default
   values provided by the LLVM makefile system. These variables can be set in 
   several ways:
@@ -867,7 +872,7 @@
 
 
 Readable Variables
-
+
   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.
@@ -938,7 +943,7 @@
 
 
 Internal Variables
-
+
   Variables listed below are used by the LLVM Makefile System 
   and considered internal. You should not use these variables under any
   circumstances.
@@ -1016,6 +1021,8 @@
   
 
 
+
+
 
 
 
diff --git a/docs/Packaging.html b/docs/Packaging.html
index 86d6ca1ef03..7261cc2ac0f 100644
--- a/docs/Packaging.html
+++ b/docs/Packaging.html
@@ -19,7 +19,7 @@
 
 Overview
 
-
+
 
 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
@@ -36,7 +36,7 @@ developed against each.
 
 
Compile Flags
 
-
+
 
 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
@@ -67,7 +67,7 @@ versions of LLVM in parallel.  The following configure flags are relevant:
 
 
C++ Features
 
-
+
 
 
   RTTI
LLVM disables RTTI by default.  Add REQUIRES_RTTI=1
@@ -80,7 +80,7 @@ versions of LLVM in parallel.  The following configure flags are relevant:
 
 Shared Library
 
-
+
 
 Configure with --enable-shared to build
 libLLVM-major.minor.(so|dylib) and link the tools
@@ -91,7 +91,7 @@ against it.  This saves lots of binary size at the cost of some startup time.
 
 
Dependencies
 
-
+
 
 
 --enable-libffi
Depend on )) { s:^ *///? ?::; print "  \n" if !
 
 
 Introduction
-
+
   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.
@@ -69,8 +69,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
   bitcode are neither analysis nor transform passes.
   
The table below provides a quick summary of each pass and links to the more
   complete pass description later in the document.
-
-
+
 
@@ -201,19 +200,19 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

 ANALYSIS PASSES
 Option Name
-view-postdom View postdominance tree of function
 -view-postdom-only View postdominance tree of function (with no function bodies)
 
+
 
 
 
 Analysis Passes
-
+
   This section describes the LLVM Analysis Passes.
-
 
 
 
   -aa-eval: Exhaustive Alias Analysis Precision Evaluator
 
-
+
   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
@@ -227,7 +226,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -basicaa: Basic Alias Analysis (stateless AA impl)
 
-
+
   
   This is the default implementation of the Alias Analysis interface
   that simply implements a few identities (two different globals cannot alias,
@@ -239,7 +238,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -basiccg: Basic CallGraph Construction
 
-
+
   Yet to be written.
 
 
@@ -247,7 +246,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -count-aa: Count Alias Analysis Query Responses
 
-
+
   
   A pass which can be used to count how many alias queries
   are being made and how the alias analysis implementation being used responds.
@@ -258,7 +257,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -debug-aa: AA use debugger
 
-
+
   
   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.
@@ -275,7 +274,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -domfrontier: Dominance Frontier Construction
 
-
+
   
   This pass is a simple dominator construction algorithm for finding forward
   dominator frontiers.
@@ -286,7 +285,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -domtree: Dominator Tree Construction
 
-
+
   
   This pass is a simple dominator construction algorithm for finding forward
   dominators.
@@ -297,7 +296,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-callgraph: Print Call Graph to 'dot' file
 
-
+
   
   This pass, only available in opt, prints the call graph into a
   .dot graph.  This graph can then be processed with the "dot" tool
@@ -309,7 +308,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-cfg: Print CFG of function to 'dot' file
 
-
+
   
   This pass, only available in opt, prints the control flow graph
   into a .dot graph.  This graph can then be processed with the
@@ -321,7 +320,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-cfg-only: Print CFG of function to 'dot' file (with no function bodies)
 
-
+
   
   This pass, only available in opt, prints the control flow graph
   into a .dot graph, omitting the function bodies.  This graph can
@@ -334,7 +333,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-dom: Print dominance tree of function to 'dot' file
 
-
+
   
   This pass, only available in opt, prints the dominator tree
   into a .dot graph.  This graph can then be processed with the
@@ -346,7 +345,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-dom-only: Print dominance tree of function to 'dot' file (with no function bodies)
 
-
+
   
   This pass, only available in opt, prints the dominator tree
   into a .dot graph, omitting the function bodies.  This graph can
@@ -359,7 +358,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-postdom: Print postdominance tree of function to 'dot' file
 
-
+
   
   This pass, only available in opt, prints the post dominator tree
   into a .dot graph.  This graph can then be processed with the
@@ -371,7 +370,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dot-postdom-only: Print postdominance tree of function to 'dot' file (with no function bodies)
 
-
+
   
   This pass, only available in opt, prints the post dominator tree
   into a .dot graph, omitting the function bodies.  This graph can
@@ -384,7 +383,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -globalsmodref-aa: Simple mod/ref analysis for globals
 
-
+
   
   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
@@ -397,7 +396,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -instcount: Counts the various types of Instructions
 
-
+
   
   This pass collects the count of all instructions and reports them
   
@@ -407,7 +406,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -intervals: Interval Partition Construction
 
-
+
   
   This analysis calculates and represents the interval partition of a function,
   or a preexisting interval partition.
@@ -423,7 +422,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -iv-users: Induction Variable Users
 
-
+
   Bookkeeping for "interesting" users of expressions computed from 
   induction variables.
 
@@ -432,7 +431,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -lazy-value-info: Lazy Value Information Analysis
 
-
+
   Interface for lazy computation of value constraint information.
 
 
@@ -440,7 +439,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -lda: Loop Dependence Analysis
 
-
+
   Loop dependence analysis framework, which is used to detect dependences in
   memory accesses in loops.
 
@@ -449,7 +448,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -libcall-aa: LibCall Alias Analysis
 
-
+
   LibCall Alias Analysis.
 
 
@@ -457,7 +456,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -lint: Statically lint-checks LLVM IR
 
-
+
   This pass statically checks for common and easily-identified constructs
   which produce undefined or likely unintended behavior in LLVM IR.
  
@@ -488,7 +487,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -loops: Natural Loop Information
 
-
+
   
   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
@@ -501,7 +500,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -memdep: Memory Dependence Analysis
 
-
+
   
   An analysis that determines, for a given memory operation, what preceding 
   memory operations it depends on.  It builds on alias analysis information, and 
@@ -514,7 +513,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -module-debuginfo: Decodes module-level debug info
 
-
+
   This pass decodes the debug info metadata in a module and prints in a
  (sufficiently-prepared-) human-readable form.
 
@@ -527,7 +526,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -no-aa: No Alias Analysis (always returns 'may' alias)
 
-
+
   
   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
@@ -539,7 +538,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -no-profile: No Profile Information
 
-
+
   
   The default "no profile" implementation of the abstract
   ProfileInfo interface.
@@ -550,7 +549,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -postdomfrontier: Post-Dominance Frontier Construction
 
-
+
   
   This pass is a simple post-dominator construction algorithm for finding
   post-dominator frontiers.
@@ -561,7 +560,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -postdomtree: Post-Dominator Tree Construction
 
-
+
   
   This pass is a simple post-dominator construction algorithm for finding
   post-dominators.
@@ -572,7 +571,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -print-alias-sets: Alias Set Printer
 
-
+
   Yet to be written.
 
 
@@ -580,7 +579,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -print-callgraph: Print a call graph
 
-
+
   
   This pass, only available in opt, prints the call graph to
   standard error in a human-readable form.
@@ -591,7 +590,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -print-callgraph-sccs: Print SCCs of the Call Graph
 
-
+
   
   This pass, only available in opt, prints the SCCs of the call
   graph to standard error in a human-readable form.
@@ -602,7 +601,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -print-cfg-sccs: Print SCCs of each function CFG
 
-
+
   
   This pass, only available in opt, prints the SCCs of each
   function CFG to standard error in a human-readable form.
@@ -613,7 +612,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -print-dbginfo: Print debug info in human readable form
 
-
+
   Pass that prints instructions, and associated debug info:
   
   
@@ -627,7 +626,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -print-dom-info: Dominator Info Printer
 
-
+
   Dominator Info Printer.
 
 
@@ -635,7 +634,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -print-externalfnconstants: Print external fn callsites passed constants
 
-
+
   
   This pass, only available in opt, prints out call sites to
   external functions that are called with constant arguments.  This can be
@@ -648,7 +647,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -print-function: Print function to stderr
 
-
+
   
   The PrintFunctionPass class is designed to be pipelined with
   other FunctionPasses, and prints out the functions of the module
@@ -660,7 +659,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -print-module: Print module to stderr
 
-
+
   
   This pass simply prints out the entire module when it is executed.
   
@@ -670,7 +669,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -print-used-types: Find Used Types
 
-
+
   
   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
@@ -681,7 +680,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -profile-estimator: Estimate profiling information
 
-
+
   Profiling information that estimates the profiling information 
   in a very crude and unimaginative way.
   
@@ -691,7 +690,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -profile-loader: Load profile information from llvmprof.out
 
-
+
   
   A concrete implementation of profiling information that loads the information
   from a profile dump file.
@@ -702,13 +701,13 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -profile-verifier: Verify profiling information
 
-
+
   Pass that checks profiling information for plausibility.
 
 
   -regions: Detect single entry single exit regions
 
-
+
   
   The RegionInfo pass detects single entry single exit regions in a
   function, where a region is defined as any subgraph that is connected to the
@@ -721,7 +720,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -scalar-evolution: Scalar Evolution Analysis
 
-
+
   
   The ScalarEvolution analysis can be used to analyze and
   catagorize scalar expressions in loops.  It specializes in recognizing general
@@ -740,7 +739,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -scev-aa: ScalarEvolution-based Alias Analysis
 
-
+
   Simple alias analysis implemented in terms of ScalarEvolution queries.
  
   This differs from traditional loop dependence analysis in that it tests
@@ -756,22 +755,23 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -targetdata: Target Data Layout
 
-
+
   Provides other passes access to information on how the size and alignment
   required by the the target ABI for various data types.
 
 
+
+
 
 Transform Passes
-
+
   This section describes the LLVM Transform Passes.
-
 
 
 
   -adce: Aggressive Dead Code Elimination
 
-
+
   ADCE aggressively tries to eliminate code. This pass is similar to
   DCE but it assumes that values are dead until proven 
   otherwise. This is similar to SCCP, except applied to 
@@ -782,7 +782,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -always-inline: Inliner for always_inline functions
 
-
+
   A custom inliner that handles only functions that are marked as 
   "always inline".
 
@@ -791,7 +791,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -argpromotion: Promote 'by reference' arguments to scalars
 
-
+
   
   This pass promotes "by reference" arguments to be "by value" arguments.  In
   practice, this means looking for internal functions that have pointer
@@ -822,7 +822,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -block-placement: Profile Guided Basic Block Placement
 
-
+
   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
@@ -834,7 +834,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -break-crit-edges: Break critical edges in CFG
 
-
+
   
   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
@@ -847,7 +847,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -codegenprepare: Optimize for code generation
 
-
+
   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.
@@ -857,7 +857,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -constmerge: Merge Duplicate Global Constants
 
-
+
   
   Merges duplicate global constants together into a single constant that is
   shared.  This is useful because some passes (ie TraceValues) insert a lot of
@@ -870,7 +870,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -constprop: Simple constant propagation
 
-
+
   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:
@@ -886,7 +886,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -dce: Dead Code Elimination
 
-
+
   
   Dead code elimination is similar to dead instruction
   elimination, but it rechecks instructions that were used by removed
@@ -898,7 +898,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -deadargelim: Dead Argument Elimination
 
-
+
   
   This pass deletes dead arguments from internal functions.  Dead argument
   elimination removes arguments which are directly dead, as well as arguments
@@ -916,7 +916,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -deadtypeelim: Dead Type Elimination
 
-
+
   
   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 )) { s:^ *///? ?::; print "  
\n" if !
 

   -die: Dead Instruction Elimination
 
-
+
   
   Dead instruction elimination performs a single pass over the function,
   removing instructions that are obviously dead.
@@ -939,7 +939,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -dse: Dead Store Elimination
 
-
+
   
   A trivial dead store elimination that only considers basic-block local
   redundant stores.
@@ -950,7 +950,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -functionattrs: Deduce function attributes
 
-
+
   A simple interprocedural pass which walks the call-graph, looking for 
   functions which do not access or only read non-local memory, and marking them 
   readnone/readonly.  In addition, it marks function arguments (of pointer type) 
@@ -965,7 +965,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -globaldce: Dead Global Elimination
 
-
+
   
   This transform is designed to eliminate unreachable internal globals from the
   program.  It uses an aggressive algorithm, searching out globals that are
@@ -979,7 +979,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -globalopt: Global Variable Optimizer
 
-
+
   
   This pass transforms simple global variables that never have their address
   taken.  If obviously true, it marks read/write globals as constant, deletes
@@ -991,7 +991,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -gvn: Global Value Numbering
 
-
+
   
   This pass performs global value numbering to eliminate fully and partially
   redundant instructions.  It also performs redundant load elimination.
@@ -1002,7 +1002,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -indvars: Canonicalize Induction Variables
 
-
+
   
   This transformation analyzes and transforms the induction variables (and
   computations derived from them) into simpler forms suitable for subsequent
@@ -1053,7 +1053,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -inline: Function Integration/Inlining
 
-
+
   
   Bottom-up inlining of functions into callees.
   
@@ -1063,7 +1063,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  \n" if !
 

   -insert-edge-profiling: Insert instrumentation for edge profiling
 
-
+
   
   This pass instruments the specified program with counters for edge profiling.
   Edge profiling can give a reasonable approximation of the hot paths through a
@@ -1081,7 +1081,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -insert-optimal-edge-profiling: Insert optimal instrumentation for edge profiling
 
-
+
   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.
@@ -1092,7 +1092,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -instcombine: Combine redundant instructions
 
-
+
   
   Combine instructions to form fewer, simple
   instructions.  This pass does not modify the CFG This pass is where algebraic
@@ -1146,7 +1146,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -internalize: Internalize Global Symbols
 
-
+
   
   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
@@ -1158,7 +1158,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -ipconstprop: Interprocedural constant propagation
 
-
+
   
   This pass implements an extremely simple interprocedural constant
   propagation pass.  It could certainly be improved in many different ways,
@@ -1172,7 +1172,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -ipsccp: Interprocedural Sparse Conditional Constant Propagation
 
-
+
   
   An interprocedural variant of Sparse Conditional Constant 
   Propagation.
@@ -1183,7 +1183,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "  
\n" if !
 

   -jump-threading: Jump Threading
 
-
+
   
   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
@@ -1212,7 +1212,7 @@ if (X < 3) {

 
   -lcssa: Loop-Closed SSA Form Pass
 
-
+
   
   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
@@ -1241,7 +1241,7 @@ if (X < 3) {

 
   -licm: Loop Invariant Code Motion
 
-
+
   
   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
@@ -1278,7 +1278,7 @@ if (X < 3) {

 
   -loop-deletion: Delete dead loops
 
-
+
   
   This file implements the Dead Loop Deletion Pass.  This pass is responsible
   for eliminating loops with non-infinite computable trip counts that have no
@@ -1291,7 +1291,7 @@ if (X < 3) {

 
   -loop-extract: Extract loops into new functions
 
-
+
   
   A pass wrapper around the ExtractLoop() scalar transformation to 
   extract each top-level loop into its own new function. If the loop is the
@@ -1304,7 +1304,7 @@ if (X < 3) {

 
   -loop-extract-single: Extract at most one loop into a new function
 
-
+
   
   Similar to Extract loops into new functions,
   this pass extracts one natural loop from the program into a function if it
@@ -1316,7 +1316,7 @@ if (X < 3) {

 
   -loop-reduce: Loop Strength Reduction
 
-
+
   
   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
@@ -1330,7 +1330,7 @@ if (X < 3) {

ANALYSIS PASSES
Option	Name
-view-postdom	View postdominance tree of function
-view-postdom-only	View postdominance tree of function (with no function bodies)

Section Example

Subsection Example

@@ -761,7 +760,7 @@ ret

@@ -911,20 +908,18 @@ printer, and the type generated by the assembly parser and disassembler.

@@ -1888,7 +1884,7 @@ to implement an assembler for your target.

Instruction Parsing

Mnemonic Aliases

Instruction Aliases

Instruction Matching

@@ -2045,20 +2036,18 @@ subtarget specific.

Is Generally Reliable

Assembly Parser

Disassembler

Inline Asm

JIT Support

.o File Writing

Tail Calls

File Headers

Class overviews

Method information

@@ -467,13 +486,14 @@ which case struct is allowed.

@@ -809,6 +830,7 @@ locality.

@@ -817,7 +839,7 @@ locality.

@@ -1201,6 +1224,8 @@ it's better to use a literal '\n'.

@@ -1463,7 +1490,7 @@ namespace just because it was declared there.

@@ -807,21 +806,19 @@ OPTIONS:

IBM - Official manuals and docs

Other documents, collections, notes

AMD - Official manuals and docs

Intel - Official manuals and docs

Other x86-specific information

@@ -467,13 +486,14 @@ which case `struct` is allowed.

@@ -1201,6 +1224,8 @@ it's better to use a literal `'\n'`.