[llvm-commits] CVS: llvm-www/releases/2.5/docs/AliasAnalysis.html BitCodeFormat.html Bugpoint.html CFEBuildInstrs.html CMake.html CodeGenerator.html CodingStandards.html CommandLine.html CompilerDriver.html CompilerDriverTutorial.html CompilerWriterInfo.html DeveloperPolicy.html ExceptionHandling.html ExtendingLLVM.html FAQ.html GCCFEBuildInstrs.html GarbageCollection.html GetElementPtr.html GettingStarted.html GettingStartedVS.html HowToReleaseLLVM.html HowToSubmitABug.html LangRef.html Lexicon.html LinkTimeOptimization.html Makefile MakefileGuide.html Passes.html ProgrammersManual.html Projects.html ReleaseNotes.html SourceLevelDebugging.html SystemLibrary.html TableGenFundamentals.html TestingGuide.html UsingLibraries.html WritingAnLLVMBackend.html WritingAnLLVMPass.html doxygen.cfg doxygen.cfg.in doxygen.css doxygen.footer doxygen.header doxygen.intro index.html llvm.css
Tanya Lattner
tonic at nondot.org
Mon Mar 2 21:19:10 PST 2009
Changes in directory llvm-www/releases/2.5/docs:
AliasAnalysis.html added (r1.1)
BitCodeFormat.html added (r1.1)
Bugpoint.html added (r1.1)
CFEBuildInstrs.html added (r1.1)
CMake.html added (r1.1)
CodeGenerator.html added (r1.1)
CodingStandards.html added (r1.1)
CommandLine.html added (r1.1)
CompilerDriver.html added (r1.1)
CompilerDriverTutorial.html added (r1.1)
CompilerWriterInfo.html added (r1.1)
DeveloperPolicy.html added (r1.1)
ExceptionHandling.html added (r1.1)
ExtendingLLVM.html added (r1.1)
FAQ.html added (r1.1)
GCCFEBuildInstrs.html added (r1.1)
GarbageCollection.html added (r1.1)
GetElementPtr.html added (r1.1)
GettingStarted.html added (r1.1)
GettingStartedVS.html added (r1.1)
HowToReleaseLLVM.html added (r1.1)
HowToSubmitABug.html added (r1.1)
LangRef.html added (r1.1)
Lexicon.html added (r1.1)
LinkTimeOptimization.html added (r1.1)
Makefile added (r1.1)
MakefileGuide.html added (r1.1)
Passes.html added (r1.1)
ProgrammersManual.html added (r1.1)
Projects.html added (r1.1)
ReleaseNotes.html added (r1.1)
SourceLevelDebugging.html added (r1.1)
SystemLibrary.html added (r1.1)
TableGenFundamentals.html added (r1.1)
TestingGuide.html added (r1.1)
UsingLibraries.html added (r1.1)
WritingAnLLVMBackend.html added (r1.1)
WritingAnLLVMPass.html added (r1.1)
doxygen.cfg added (r1.1)
doxygen.cfg.in added (r1.1)
doxygen.css added (r1.1)
doxygen.footer added (r1.1)
doxygen.header added (r1.1)
doxygen.intro added (r1.1)
index.html added (r1.1)
llvm.css added (r1.1)
---
Log message:
Adding 2.5 release.
---
Diffs of the changes: (+42554 -0)
AliasAnalysis.html | 988 ++++++
BitCodeFormat.html | 689 ++++
Bugpoint.html | 239 +
CFEBuildInstrs.html | 29
CMake.html | 360 ++
CodeGenerator.html | 2063 +++++++++++++
CodingStandards.html | 810 +++++
CommandLine.html | 1995 +++++++++++++
CompilerDriver.html | 619 ++++
CompilerDriverTutorial.html | 120
CompilerWriterInfo.html | 263 +
DeveloperPolicy.html | 573 +++
ExceptionHandling.html | 479 +++
ExtendingLLVM.html | 391 ++
FAQ.html | 725 ++++
GCCFEBuildInstrs.html | 269 +
GarbageCollection.html | 1446 +++++++++
GetElementPtr.html | 370 ++
GettingStarted.html | 1634 ++++++++++
GettingStartedVS.html | 406 ++
HowToReleaseLLVM.html | 600 ++++
HowToSubmitABug.html | 355 ++
LangRef.html | 6551 ++++++++++++++++++++++++++++++++++++++++++++
Lexicon.html | 263 +
LinkTimeOptimization.html | 390 ++
Makefile | 125
MakefileGuide.html | 1033 ++++++
Passes.html | 1970 +++++++++++++
ProgrammersManual.html | 3426 +++++++++++++++++++++++
Projects.html | 460 +++
ReleaseNotes.html | 964 ++++++
SourceLevelDebugging.html | 1812 ++++++++++++
SystemLibrary.html | 344 ++
TableGenFundamentals.html | 753 +++++
TestingGuide.html | 963 ++++++
UsingLibraries.html | 449 +++
WritingAnLLVMBackend.html | 2162 ++++++++++++++
WritingAnLLVMPass.html | 1828 ++++++++++++
doxygen.cfg | 1419 +++++++++
doxygen.cfg.in | 1419 +++++++++
doxygen.css | 378 ++
doxygen.footer | 13
doxygen.header | 9
doxygen.intro | 18
index.html | 282 +
llvm.css | 100
46 files changed, 42554 insertions(+)
Index: llvm-www/releases/2.5/docs/AliasAnalysis.html
diff -c /dev/null llvm-www/releases/2.5/docs/AliasAnalysis.html:1.1
*** /dev/null Mon Mar 2 23:17:47 2009
--- llvm-www/releases/2.5/docs/AliasAnalysis.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,988 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM Alias Analysis Infrastructure</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ LLVM Alias Analysis Infrastructure
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+
+ <li><a href="#overview"><tt>AliasAnalysis</tt> Class Overview</a>
+ <ul>
+ <li><a href="#pointers">Representation of Pointers</a></li>
+ <li><a href="#alias">The <tt>alias</tt> method</a></li>
+ <li><a href="#ModRefInfo">The <tt>getModRefInfo</tt> methods</a></li>
+ <li><a href="#OtherItfs">Other useful <tt>AliasAnalysis</tt> methods</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a>
+ <ul>
+ <li><a href="#passsubclasses">Different Pass styles</a></li>
+ <li><a href="#requiredcalls">Required initialization calls</a></li>
+ <li><a href="#interfaces">Interfaces which may be specified</a></li>
+ <li><a href="#chaining"><tt>AliasAnalysis</tt> chaining behavior</a></li>
+ <li><a href="#updating">Updating analysis results for transformations</a></li>
+ <li><a href="#implefficiency">Efficiency Issues</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#using">Using alias analysis results</a>
+ <ul>
+ <li><a href="#loadvn">Using the <tt>-load-vn</tt> Pass</a></li>
+ <li><a href="#ast">Using the <tt>AliasSetTracker</tt> class</a></li>
+ <li><a href="#direct">Using the <tt>AliasAnalysis</tt> interface directly</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#exist">Existing alias analysis implementations and clients</a>
+ <ul>
+ <li><a href="#impls">Available <tt>AliasAnalysis</tt> implementations</a></li>
+ <li><a href="#aliasanalysis-xforms">Alias analysis driven transformations</a></li>
+ <li><a href="#aliasanalysis-debug">Clients for debugging and evaluation of
+ implementations</a></li>
+ </ul>
+ </li>
+ <li><a href="#memdep">Memory Dependence Analysis</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt
+ to determine whether or not two pointers ever can point to the same object in
+ memory. There are many different algorithms for alias analysis and many
+ different ways of classifying them: flow-sensitive vs flow-insensitive,
+ context-sensitive vs context-insensitive, field-sensitive vs field-insensitive,
+ unification-based vs subset-based, etc. Traditionally, alias analyses respond
+ to a query with a <a href="#MustMayNo">Must, May, or No</a> alias response,
+ indicating that two pointers always point to the same object, might point to the
+ same object, or are known to never point to the same object.</p>
+
+ <p>The LLVM <a
+ href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
+ class is the primary interface used by clients and implementations of alias
+ analyses in the LLVM system. This class is the common interface between clients
+ of alias analysis information and the implementations providing it, and is
+ designed to support a wide range of implementations and clients (but currently
+ all clients are assumed to be flow-insensitive). In addition to simple alias
+ analysis information, this class exposes Mod/Ref information from those
+ implementations which can provide it, allowing for powerful analyses and
+ transformations to work well together.</p>
+
+ <p>This document contains information necessary to successfully implement this
+ interface, use it, and to test both sides. It also explains some of the finer
+ points about what exactly results mean. If you feel that something is unclear
+ or should be added, please <a href="mailto:sabre at nondot.org">let me
+ know</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="overview"><tt>AliasAnalysis</tt> Class Overview</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The <a
+ href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
+ class defines the interface that the various alias analysis implementations
+ should support. This class exports two important enums: <tt>AliasResult</tt>
+ and <tt>ModRefResult</tt> which represent the result of an alias query or a
+ mod/ref query, respectively.</p>
+
+ <p>The <tt>AliasAnalysis</tt> interface exposes information about memory,
+ represented in several different ways. In particular, memory objects are
+ represented as a starting address and size, and function calls are represented
+ as the actual <tt>call</tt> or <tt>invoke</tt> instructions that performs the
+ call. The <tt>AliasAnalysis</tt> interface also exposes some helper methods
+ which allow you to get mod/ref information for arbitrary instructions.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="pointers">Representation of Pointers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Most importantly, the <tt>AliasAnalysis</tt> class provides several methods
+ which are used to query whether or not two memory objects alias, whether
+ function calls can modify or read a memory object, etc. For all of these
+ queries, memory objects are represented as a pair of their starting address (a
+ symbolic LLVM <tt>Value*</tt>) and a static size.</p>
+
+ <p>Representing memory objects as a starting address and a size is critically
+ important for correct Alias Analyses. For example, consider this (silly, but
+ possible) C code:</p>
+
+ <div class="doc_code">
+ <pre>
+ int i;
+ char C[2];
+ char A[10];
+ /* ... */
+ for (i = 0; i != 10; ++i) {
+ C[0] = A[i]; /* One byte store */
+ C[1] = A[9-i]; /* One byte store */
+ }
+ </pre>
+ </div>
+
+ <p>In this case, the <tt>basicaa</tt> pass will disambiguate the stores to
+ <tt>C[0]</tt> and <tt>C[1]</tt> because they are accesses to two distinct
+ locations one byte apart, and the accesses are each one byte. In this case, the
+ LICM pass can use store motion to remove the stores from the loop. In
+ constrast, the following code:</p>
+
+ <div class="doc_code">
+ <pre>
+ int i;
+ char C[2];
+ char A[10];
+ /* ... */
+ for (i = 0; i != 10; ++i) {
+ ((short*)C)[0] = A[i]; /* Two byte store! */
+ C[1] = A[9-i]; /* One byte store */
+ }
+ </pre>
+ </div>
+
+ <p>In this case, the two stores to C do alias each other, because the access to
+ the <tt>&C[0]</tt> element is a two byte access. If size information wasn't
+ available in the query, even the first case would have to conservatively assume
+ that the accesses alias.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="alias">The <tt>alias</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+ The <tt>alias</tt> method is the primary interface used to determine whether or
+ not two memory objects alias each other. It takes two memory objects as input
+ and returns MustAlias, MayAlias, or NoAlias as appropriate.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="MustMayNo">Must, May, and No Alias Responses</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The NoAlias response is used when the two pointers refer to distinct objects,
+ regardless of whether the pointers compare equal. For example, freed pointers
+ don't alias any pointers that were allocated afterwards. As a degenerate case,
+ pointers returned by malloc(0) have no bytes for an object, and are considered
+ NoAlias even when malloc returns the same pointer. The same rule applies to
+ NULL pointers.</p>
+
+ <p>The MayAlias response is used whenever the two pointers might refer to the
+ same object. If the two memory objects overlap, but do not start at the same
+ location, return MayAlias.</p>
+
+ <p>The MustAlias response may only be returned if the two memory objects are
+ guaranteed to always start at exactly the same location. A MustAlias response
+ implies that the pointers compare equal.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ModRefInfo">The <tt>getModRefInfo</tt> methods</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>getModRefInfo</tt> methods return information about whether the
+ execution of an instruction can read or modify a memory location. Mod/Ref
+ information is always conservative: if an instruction <b>might</b> read or write
+ a location, ModRef is returned.</p>
+
+ <p>The <tt>AliasAnalysis</tt> class also provides a <tt>getModRefInfo</tt>
+ method for testing dependencies between function calls. This method takes two
+ call sites (CS1 & CS2), returns NoModRef if the two calls refer to disjoint
+ memory locations, Ref if CS1 reads memory written by CS2, Mod if CS1 writes to
+ memory read or written by CS2, or ModRef if CS1 might read or write memory
+ accessed by CS2. Note that this relation is not commutative. Clients that use
+ this method should be predicated on the <tt>hasNoModRefInfoForCalls()</tt>
+ method, which indicates whether or not an analysis can provide mod/ref
+ information for function call pairs (most can not). If this predicate is false,
+ the client shouldn't waste analysis time querying the <tt>getModRefInfo</tt>
+ method many times.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="OtherItfs">Other useful <tt>AliasAnalysis</tt> methods</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ Several other tidbits of information are often collected by various alias
+ analysis implementations and can be put to good use by various clients.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ The <tt>getMustAliases</tt> method
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>getMustAliases</tt> method returns all values that are known to
+ always must alias a pointer. This information can be provided in some cases for
+ important objects like the null pointer and global values. Knowing that a
+ pointer always points to a particular function allows indirect calls to be
+ turned into direct calls, for example.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ The <tt>pointsToConstantMemory</tt> method
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>pointsToConstantMemory</tt> method returns true if and only if the
+ analysis can prove that the pointer only points to unchanging memory locations
+ (functions, constant global variables, and the null pointer). This information
+ can be used to refine mod/ref information: it is impossible for an unchanging
+ memory location to be modified.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="simplemodref">The <tt>doesNotAccessMemory</tt> and
+ <tt>onlyReadsMemory</tt> methods</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>These methods are used to provide very simple mod/ref information for
+ function calls. The <tt>doesNotAccessMemory</tt> method returns true for a
+ function if the analysis can prove that the function never reads or writes to
+ memory, or if the function only reads from constant memory. Functions with this
+ property are side-effect free and only depend on their input arguments, allowing
+ them to be eliminated if they form common subexpressions or be hoisted out of
+ loops. Many common functions behave this way (e.g., <tt>sin</tt> and
+ <tt>cos</tt>) but many others do not (e.g., <tt>acos</tt>, which modifies the
+ <tt>errno</tt> variable).</p>
+
+ <p>The <tt>onlyReadsMemory</tt> method returns true for a function if analysis
+ can prove that (at most) the function only reads from non-volatile memory.
+ Functions with this property are side-effect free, only depending on their input
+ arguments and the state of memory when they are called. This property allows
+ calls to these functions to be eliminated and moved around, as long as there is
+ no store instruction that changes the contents of memory. Note that all
+ functions that satisfy the <tt>doesNotAccessMemory</tt> method also satisfies
+ <tt>onlyReadsMemory</tt>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Writing a new alias analysis implementation for LLVM is quite
+ straight-forward. There are already several implementations that you can use
+ for examples, and the following information should help fill in any details.
+ For a examples, take a look at the <a href="#impls">various alias analysis
+ implementations</a> included with LLVM.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="passsubclasses">Different Pass styles</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The first step to determining what type of <a
+ href="WritingAnLLVMPass.html">LLVM pass</a> you need to use for your Alias
+ Analysis. As is the case with most other analyses and transformations, the
+ answer should be fairly obvious from what type of problem you are trying to
+ solve:</p>
+
+ <ol>
+ <li>If you require interprocedural analysis, it should be a
+ <tt>Pass</tt>.</li>
+ <li>If you are a function-local analysis, subclass <tt>FunctionPass</tt>.</li>
+ <li>If you don't need to look at the program at all, subclass
+ <tt>ImmutablePass</tt>.</li>
+ </ol>
+
+ <p>In addition to the pass that you subclass, you should also inherit from the
+ <tt>AliasAnalysis</tt> interface, of course, and use the
+ <tt>RegisterAnalysisGroup</tt> template to register as an implementation of
+ <tt>AliasAnalysis</tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="requiredcalls">Required initialization calls</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Your subclass of <tt>AliasAnalysis</tt> is required to invoke two methods on
+ the <tt>AliasAnalysis</tt> base class: <tt>getAnalysisUsage</tt> and
+ <tt>InitializeAliasAnalysis</tt>. In particular, your implementation of
+ <tt>getAnalysisUsage</tt> should explicitly call into the
+ <tt>AliasAnalysis::getAnalysisUsage</tt> method in addition to doing any
+ declaring any pass dependencies your pass has. Thus you should have something
+ like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ void getAnalysisUsage(AnalysisUsage &AU) const {
+ AliasAnalysis::getAnalysisUsage(AU);
+ <i>// declare your dependencies here.</i>
+ }
+ </pre>
+ </div>
+
+ <p>Additionally, your must invoke the <tt>InitializeAliasAnalysis</tt> method
+ from your analysis run method (<tt>run</tt> for a <tt>Pass</tt>,
+ <tt>runOnFunction</tt> for a <tt>FunctionPass</tt>, or <tt>InitializePass</tt>
+ for an <tt>ImmutablePass</tt>). For example (as part of a <tt>Pass</tt>):</p>
+
+ <div class="doc_code">
+ <pre>
+ bool run(Module &M) {
+ InitializeAliasAnalysis(this);
+ <i>// Perform analysis here...</i>
+ return false;
+ }
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="interfaces">Interfaces which may be specified</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>All of the <a
+ href="/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
+ virtual methods default to providing <a href="#chaining">chaining</a> to another
+ alias analysis implementation, which ends up returning conservatively correct
+ information (returning "May" Alias and "Mod/Ref" for alias and mod/ref queries
+ respectively). Depending on the capabilities of the analysis you are
+ implementing, you just override the interfaces you can improve.</p>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="chaining"><tt>AliasAnalysis</tt> chaining behavior</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>With only two special exceptions (the <tt><a
+ href="#basic-aa">basicaa</a></tt> and <a href="#no-aa"><tt>no-aa</tt></a>
+ passes) every alias analysis pass chains to another alias analysis
+ implementation (for example, the user can specify "<tt>-basicaa -ds-aa
+ -anders-aa -licm</tt>" to get the maximum benefit from the three alias
+ analyses). The alias analysis class automatically takes care of most of this
+ for methods that you don't override. For methods that you do override, in code
+ paths that return a conservative MayAlias or Mod/Ref result, simply return
+ whatever the superclass computes. For example:</p>
+
+ <div class="doc_code">
+ <pre>
+ AliasAnalysis::AliasResult alias(const Value *V1, unsigned V1Size,
+ const Value *V2, unsigned V2Size) {
+ if (...)
+ return NoAlias;
+ ...
+
+ <i>// Couldn't determine a must or no-alias result.</i>
+ return AliasAnalysis::alias(V1, V1Size, V2, V2Size);
+ }
+ </pre>
+ </div>
+
+ <p>In addition to analysis queries, you must make sure to unconditionally pass
+ LLVM <a href="#updating">update notification</a> methods to the superclass as
+ well if you override them, which allows all alias analyses in a change to be
+ updated.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="updating">Updating analysis results for transformations</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Alias analysis information is initially computed for a static snapshot of the
+ program, but clients will use this information to make transformations to the
+ code. All but the most trivial forms of alias analysis will need to have their
+ analysis results updated to reflect the changes made by these transformations.
+ </p>
+
+ <p>
+ The <tt>AliasAnalysis</tt> interface exposes two methods which are used to
+ communicate program changes from the clients to the analysis implementations.
+ Various alias analysis implementations should use these methods to ensure that
+ their internal data structures are kept up-to-date as the program changes (for
+ example, when an instruction is deleted), and clients of alias analysis must be
+ sure to call these interfaces appropriately.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">The <tt>deleteValue</tt> method</div>
+
+ <div class="doc_text">
+ The <tt>deleteValue</tt> method is called by transformations when they remove an
+ instruction or any other value from the program (including values that do not
+ use pointers). Typically alias analyses keep data structures that have entries
+ for each value in the program. When this method is called, they should remove
+ any entries for the specified value, if they exist.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">The <tt>copyValue</tt> method</div>
+
+ <div class="doc_text">
+ The <tt>copyValue</tt> method is used when a new value is introduced into the
+ program. There is no way to introduce a value into the program that did not
+ exist before (this doesn't make sense for a safe compiler transformation), so
+ this is the only way to introduce a new value. This method indicates that the
+ new value has exactly the same properties as the value being copied.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">The <tt>replaceWithNewValue</tt> method</div>
+
+ <div class="doc_text">
+ This method is a simple helper method that is provided to make clients easier to
+ use. It is implemented by copying the old analysis information to the new
+ value, then deleting the old value. This method cannot be overridden by alias
+ analysis implementations.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="implefficiency">Efficiency Issues</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>From the LLVM perspective, the only thing you need to do to provide an
+ efficient alias analysis is to make sure that alias analysis <b>queries</b> are
+ serviced quickly. The actual calculation of the alias analysis results (the
+ "run" method) is only performed once, but many (perhaps duplicate) queries may
+ be performed. Because of this, try to move as much computation to the run
+ method as possible (within reason).</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="using">Using alias analysis results</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>There are several different ways to use alias analysis results. In order of
+ preference, these are...</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="loadvn">Using the <tt>-load-vn</tt> Pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>load-vn</tt> pass uses alias analysis to provide value numbering
+ information for <tt>load</tt> instructions and pointer values. If your analysis
+ or transformation can be modeled in a form that uses value numbering
+ information, you don't have to do anything special to handle load instructions:
+ just use the <tt>load-vn</tt> pass, which uses alias analysis.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ast">Using the <tt>AliasSetTracker</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Many transformations need information about alias <b>sets</b> that are active
+ in some scope, rather than information about pairwise aliasing. The <tt><a
+ href="/doxygen/classllvm_1_1AliasSetTracker.html">AliasSetTracker</a></tt> class
+ is used to efficiently build these Alias Sets from the pairwise alias analysis
+ information provided by the <tt>AliasAnalysis</tt> interface.</p>
+
+ <p>First you initialize the AliasSetTracker by using the "<tt>add</tt>" methods
+ to add information about various potentially aliasing instructions in the scope
+ you are interested in. Once all of the alias sets are completed, your pass
+ should simply iterate through the constructed alias sets, using the
+ <tt>AliasSetTracker</tt> <tt>begin()</tt>/<tt>end()</tt> methods.</p>
+
+ <p>The <tt>AliasSet</tt>s formed by the <tt>AliasSetTracker</tt> are guaranteed
+ to be disjoint, calculate mod/ref information and volatility for the set, and
+ keep track of whether or not all of the pointers in the set are Must aliases.
+ The AliasSetTracker also makes sure that sets are properly folded due to call
+ instructions, and can provide a list of pointers in each set.</p>
+
+ <p>As an example user of this, the <a href="/doxygen/structLICM.html">Loop
+ Invariant Code Motion</a> pass uses <tt>AliasSetTracker</tt>s to calculate alias
+ sets for each loop nest. If an <tt>AliasSet</tt> in a loop is not modified,
+ then all load instructions from that set may be hoisted out of the loop. If any
+ alias sets are stored to <b>and</b> are must alias sets, then the stores may be
+ sunk to outside of the loop, promoting the memory location to a register for the
+ duration of the loop nest. Both of these transformations only apply if the
+ pointer argument is loop-invariant.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ The AliasSetTracker implementation
+ </div>
+
+ <div class="doc_text">
+
+ <p>The AliasSetTracker class is implemented to be as efficient as possible. It
+ uses the union-find algorithm to efficiently merge AliasSets when a pointer is
+ inserted into the AliasSetTracker that aliases multiple sets. The primary data
+ structure is a hash table mapping pointers to the AliasSet they are in.</p>
+
+ <p>The AliasSetTracker class must maintain a list of all of the LLVM Value*'s
+ that are in each AliasSet. Since the hash table already has entries for each
+ LLVM Value* of interest, the AliasesSets thread the linked list through these
+ hash-table nodes to avoid having to allocate memory unnecessarily, and to make
+ merging alias sets extremely efficient (the linked list merge is constant time).
+ </p>
+
+ <p>You shouldn't need to understand these details if you are just a client of
+ the AliasSetTracker, but if you look at the code, hopefully this brief
+ description will help make sense of why things are designed the way they
+ are.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="direct">Using the <tt>AliasAnalysis</tt> interface directly</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If neither of these utility class are what your pass needs, you should use
+ the interfaces exposed by the <tt>AliasAnalysis</tt> class directly. Try to use
+ the higher-level methods when possible (e.g., use mod/ref information instead of
+ the <a href="#alias"><tt>alias</tt></a> method directly if possible) to get the
+ best precision and efficiency.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="exist">Existing alias analysis implementations and clients</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>If you're going to be working with the LLVM alias analysis infrastructure,
+ you should know what clients and implementations of alias analysis are
+ available. In particular, if you are implementing an alias analysis, you should
+ be aware of the <a href="#aliasanalysis-debug">the clients</a> that are useful
+ for monitoring and evaluating different implementations.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="impls">Available <tt>AliasAnalysis</tt> implementations</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>This section lists the various implementations of the <tt>AliasAnalysis</tt>
+ interface. With the exception of the <a href="#no-aa"><tt>-no-aa</tt></a> and
+ <a href="#basic-aa"><tt>-basicaa</tt></a> implementations, all of these <a
+ href="#chaining">chain</a> to other alias analysis implementations.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="no-aa">The <tt>-no-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-no-aa</tt> pass is just like what it sounds: an alias analysis that
+ never returns any useful information. This pass can be useful if you think that
+ alias analysis is doing something wrong and are trying to narrow down a
+ problem.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="basic-aa">The <tt>-basicaa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-basicaa</tt> pass is the default LLVM alias analysis. It is an
+ aggressive local analysis that "knows" many important facts:</p>
+
+ <ul>
+ <li>Distinct globals, stack allocations, and heap allocations can never
+ alias.</li>
+ <li>Globals, stack allocations, and heap allocations never alias the null
+ pointer.</li>
+ <li>Different fields of a structure do not alias.</li>
+ <li>Indexes into arrays with statically differing subscripts cannot alias.</li>
+ <li>Many common standard C library functions <a
+ href="#simplemodref">never access memory or only read memory</a>.</li>
+ <li>Pointers that obviously point to constant globals
+ "<tt>pointToConstantMemory</tt>".</li>
+ <li>Function calls can not modify or references stack allocations if they never
+ escape from the function that allocates them (a common case for automatic
+ arrays).</li>
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="globalsmodref">The <tt>-globalsmodref-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>This pass implements a simple context-sensitive mod/ref and alias analysis
+ for internal global variables that don't "have their address taken". If a
+ global does not have its address taken, the pass knows that no pointers alias
+ the global. This pass also keeps track of functions that it knows never access
+ memory or never read memory. This allows certain optimizations (e.g. GCSE) to
+ eliminate call instructions entirely.
+ </p>
+
+ <p>The real power of this pass is that it provides context-sensitive mod/ref
+ information for call instructions. This allows the optimizer to know that
+ calls to a function do not clobber or read the value of the global, allowing
+ loads and stores to be eliminated.</p>
+
+ <p>Note that this pass is somewhat limited in its scope (only support
+ non-address taken globals), but is very quick analysis.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="anders-aa">The <tt>-anders-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-anders-aa</tt> pass implements the well-known "Andersen's algorithm"
+ for interprocedural alias analysis. This algorithm is a subset-based,
+ flow-insensitive, context-insensitive, and field-insensitive alias analysis that
+ is widely believed to be fairly precise. Unfortunately, this algorithm is also
+ O(N<sup>3</sup>). The LLVM implementation currently does not implement any of
+ the refinements (such as "online cycle elimination" or "offline variable
+ substitution") to improve its efficiency, so it can be quite slow in common
+ cases.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="steens-aa">The <tt>-steens-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-steens-aa</tt> pass implements a variation on the well-known
+ "Steensgaard's algorithm" for interprocedural alias analysis. Steensgaard's
+ algorithm is a unification-based, flow-insensitive, context-insensitive, and
+ field-insensitive alias analysis that is also very scalable (effectively linear
+ time).</p>
+
+ <p>The LLVM <tt>-steens-aa</tt> pass implements a "speculatively
+ field-<b>sensitive</b>" version of Steensgaard's algorithm using the Data
+ Structure Analysis framework. This gives it substantially more precision than
+ the standard algorithm while maintaining excellent analysis scalability.</p>
+
+ <p>Note that <tt>-steens-aa</tt> is available in the optional "poolalloc"
+ module, it is not part of the LLVM core.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ds-aa">The <tt>-ds-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-ds-aa</tt> pass implements the full Data Structure Analysis
+ algorithm. Data Structure Analysis is a modular unification-based,
+ flow-insensitive, context-<b>sensitive</b>, and speculatively
+ field-<b>sensitive</b> alias analysis that is also quite scalable, usually at
+ O(n*log(n)).</p>
+
+ <p>This algorithm is capable of responding to a full variety of alias analysis
+ queries, and can provide context-sensitive mod/ref information as well. The
+ only major facility not implemented so far is support for must-alias
+ information.</p>
+
+ <p>Note that <tt>-ds-aa</tt> is available in the optional "poolalloc"
+ module, it is not part of the LLVM core.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="aliasanalysis-xforms">Alias analysis driven transformations</a>
+ </div>
+
+ <div class="doc_text">
+ LLVM includes several alias-analysis driven transformations which can be used
+ with any of the implementations above.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="adce">The <tt>-adce</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-adce</tt> pass, which implements Aggressive Dead Code Elimination
+ uses the <tt>AliasAnalysis</tt> interface to delete calls to functions that do
+ not have side-effects and are not used.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="licm">The <tt>-licm</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-licm</tt> pass implements various Loop Invariant Code Motion related
+ transformations. It uses the <tt>AliasAnalysis</tt> interface for several
+ different transformations:</p>
+
+ <ul>
+ <li>It uses mod/ref information to hoist or sink load instructions out of loops
+ if there are no instructions in the loop that modifies the memory loaded.</li>
+
+ <li>It uses mod/ref information to hoist function calls out of loops that do not
+ write to memory and are loop-invariant.</li>
+
+ <li>If uses alias information to promote memory objects that are loaded and
+ stored to in loops to live in a register instead. It can do this if there are
+ no may aliases to the loaded/stored memory location.</li>
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="argpromotion">The <tt>-argpromotion</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The <tt>-argpromotion</tt> pass promotes by-reference arguments to be passed in
+ by-value instead. In particular, if pointer arguments are only loaded from it
+ passes in the value loaded instead of the address to the function. This pass
+ uses alias information to make sure that the value loaded from the argument
+ pointer is not modified between the entry of the function and any load of the
+ pointer.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="gcseloadvn">The <tt>-load-vn</tt> & <tt>-gcse</tt> passes</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-load-vn</tt> pass uses alias analysis to "<a href="#loadvn">value
+ number</a>" loads and pointers values, which is used by the GCSE pass to
+ eliminate instructions. The <tt>-load-vn</tt> pass relies on alias information
+ and must-alias information. This combination of passes can make the following
+ transformations:</p>
+
+ <ul>
+ <li>Redundant load instructions are eliminated.</li>
+ <li>Load instructions that follow a store to the same location are replaced with
+ the stored value ("store forwarding").</li>
+ <li>Pointers values (e.g. formal arguments) that must-alias simpler expressions
+ (e.g. global variables or the null pointer) are replaced. Note that this
+ implements transformations like "virtual method resolution", turning indirect
+ calls into direct calls.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="aliasanalysis-debug">Clients for debugging and evaluation of
+ implementations</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>These passes are useful for evaluating the various alias analysis
+ implementations. You can use them with commands like '<tt>opt -anders-aa -ds-aa
+ -aa-eval foo.bc -disable-output -stats</tt>'.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="print-alias-sets">The <tt>-print-alias-sets</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-print-alias-sets</tt> pass is exposed as part of the
+ <tt>opt</tt> tool to print out the Alias Sets formed by the <a
+ href="#ast"><tt>AliasSetTracker</tt></a> class. This is useful if you're using
+ the <tt>AliasSetTracker</tt> class. To use it, use something like:</p>
+
+ <div class="doc_code">
+ <pre>
+ % opt -ds-aa -print-alias-sets -disable-output
+ </pre>
+ </div>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="count-aa">The <tt>-count-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-count-aa</tt> pass is useful to see how many queries a particular
+ pass is making and what responses are returned by the alias analysis. As an
+ example,</p>
+
+ <div class="doc_code">
+ <pre>
+ % opt -basicaa -count-aa -ds-aa -count-aa -licm
+ </pre>
+ </div>
+
+ <p>will print out how many queries (and what responses are returned) by the
+ <tt>-licm</tt> pass (of the <tt>-ds-aa</tt> pass) and how many queries are made
+ of the <tt>-basicaa</tt> pass by the <tt>-ds-aa</tt> pass. This can be useful
+ when debugging a transformation or an alias analysis implementation.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="aa-eval">The <tt>-aa-eval</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>-aa-eval</tt> pass simply iterates through all pairs of pointers in a
+ function and asks an alias analysis whether or not the pointers alias. This
+ gives an indication of the precision of the alias analysis. Statistics are
+ printed indicating the percent of no/may/must aliases found (a more precise
+ algorithm will have a lower number of may aliases).</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="memdep">Memory Dependence Analysis</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>If you're just looking to be a client of alias analysis information, consider
+ using the Memory Dependence Analysis interface instead. MemDep is a lazy,
+ caching layer on top of alias analysis that is able to answer the question of
+ what preceding memory operations a given instruction depends on, either at an
+ intra- or inter-block level. Because of its laziness and caching
+ policy, using MemDep can be a significant performance win over accessing alias
+ analysis directly.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/BitCodeFormat.html
diff -c /dev/null llvm-www/releases/2.5/docs/BitCodeFormat.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/BitCodeFormat.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,689 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>LLVM Bitcode File Format</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+ <div class="doc_title"> LLVM Bitcode File Format </div>
+ <ol>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#overview">Overview</a></li>
+ <li><a href="#bitstream">Bitstream Format</a>
+ <ol>
+ <li><a href="#magic">Magic Numbers</a></li>
+ <li><a href="#primitives">Primitives</a></li>
+ <li><a href="#abbrevid">Abbreviation IDs</a></li>
+ <li><a href="#blocks">Blocks</a></li>
+ <li><a href="#datarecord">Data Records</a></li>
+ <li><a href="#abbreviations">Abbreviations</a></li>
+ <li><a href="#stdblocks">Standard Blocks</a></li>
+ </ol>
+ </li>
+ <li><a href="#wrapper">Bitcode Wrapper Format</a>
+ </li>
+ <li><a href="#llvmir">LLVM IR Encoding</a>
+ <ol>
+ <li><a href="#basics">Basics</a></li>
+ </ol>
+ </li>
+ </ol>
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>
+ and <a href="http://www.reverberate.org">Joshua Haberman</a>.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="abstract">Abstract</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document describes the LLVM bitstream file format and the encoding of
+ the LLVM IR into it.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="overview">Overview</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>
+ What is commonly known as the LLVM bitcode file format (also, sometimes
+ anachronistically known as bytecode) is actually two things: a <a
+ href="#bitstream">bitstream container format</a>
+ and an <a href="#llvmir">encoding of LLVM IR</a> into the container format.</p>
+
+ <p>
+ The bitstream format is an abstract encoding of structured data, very
+ similar to XML in some ways. Like XML, bitstream files contain tags, and nested
+ structures, and you can parse the file without having to understand the tags.
+ Unlike XML, the bitstream format is a binary encoding, and unlike XML it
+ provides a mechanism for the file to self-describe "abbreviations", which are
+ effectively size optimizations for the content.</p>
+
+ <p>LLVM IR files may be optionally embedded into a <a
+ href="#wrapper">wrapper</a> structure that makes it easy to embed extra data
+ along with LLVM IR files.</p>
+
+ <p>This document first describes the LLVM bitstream format, describes the
+ wrapper format, then describes the record structure used by LLVM IR files.
+ </p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="bitstream">Bitstream Format</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>
+ The bitstream format is literally a stream of bits, with a very simple
+ structure. This structure consists of the following concepts:
+ </p>
+
+ <ul>
+ <li>A "<a href="#magic">magic number</a>" that identifies the contents of
+ the stream.</li>
+ <li>Encoding <a href="#primitives">primitives</a> like variable bit-rate
+ integers.</li>
+ <li><a href="#blocks">Blocks</a>, which define nested content.</li>
+ <li><a href="#datarecord">Data Records</a>, which describe entities within the
+ file.</li>
+ <li>Abbreviations, which specify compression optimizations for the file.</li>
+ </ul>
+
+ <p>Note that the <a
+ href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a> tool can be
+ used to dump and inspect arbitrary bitstreams, which is very useful for
+ understanding the encoding.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="magic">Magic Numbers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The first two bytes of a bitcode file are 'BC' (0x42, 0x43).
+ The second two bytes are an application-specific magic number. Generic
+ bitcode tools can look at only the first two bytes to verify the file is
+ bitcode, while application-specific programs will want to look at all four.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="primitives">Primitives</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ A bitstream literally consists of a stream of bits, which are read in order
+ starting with the least significant bit of each byte. The stream is made up of a
+ number of primitive values that encode a stream of unsigned integer values.
+ These
+ integers are are encoded in two ways: either as <a href="#fixedwidth">Fixed
+ Width Integers</a> or as <a href="#variablewidth">Variable Width
+ Integers</a>.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="fixedwidth">Fixed Width Integers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Fixed-width integer values have their low bits emitted directly to the file.
+ For example, a 3-bit integer value encodes 1 as 001. Fixed width integers
+ are used when there are a well-known number of options for a field. For
+ example, boolean values are usually encoded with a 1-bit wide integer.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="variablewidth">Variable Width
+ Integers</a></div>
+
+ <div class="doc_text">
+
+ <p>Variable-width integer (VBR) values encode values of arbitrary size,
+ optimizing for the case where the values are small. Given a 4-bit VBR field,
+ any 3-bit value (0 through 7) is encoded directly, with the high bit set to
+ zero. Values larger than N-1 bits emit their bits in a series of N-1 bit
+ chunks, where all but the last set the high bit.</p>
+
+ <p>For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a
+ vbr4 value. The first set of four bits indicates the value 3 (011) with a
+ continuation piece (indicated by a high bit of 1). The next word indicates a
+ value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value
+ 27.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="char6">6-bit characters</a></div>
+
+ <div class="doc_text">
+
+ <p>6-bit characters encode common characters into a fixed 6-bit field. They
+ represent the following characters with the following 6-bit values:</p>
+
+ <ul>
+ <li>'a' .. 'z' - 0 .. 25</li>
+ <li>'A' .. 'Z' - 26 .. 51</li>
+ <li>'0' .. '9' - 52 .. 61</li>
+ <li>'.' - 62</li>
+ <li>'_' - 63</li>
+ </ul>
+
+ <p>This encoding is only suitable for encoding characters and strings that
+ consist only of the above characters. It is completely incapable of encoding
+ characters not in the set.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="wordalign">Word Alignment</a></div>
+
+ <div class="doc_text">
+
+ <p>Occasionally, it is useful to emit zero bits until the bitstream is a
+ multiple of 32 bits. This ensures that the bit position in the stream can be
+ represented as a multiple of 32-bit words.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="abbrevid">Abbreviation IDs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ A bitstream is a sequential series of <a href="#blocks">Blocks</a> and
+ <a href="#datarecord">Data Records</a>. Both of these start with an
+ abbreviation ID encoded as a fixed-bitwidth field. The width is specified by
+ the current block, as described below. The value of the abbreviation ID
+ specifies either a builtin ID (which have special meanings, defined below) or
+ one of the abbreviation IDs defined by the stream itself.
+ </p>
+
+ <p>
+ The set of builtin abbrev IDs is:
+ </p>
+
+ <ul>
+ <li>0 - <a href="#END_BLOCK">END_BLOCK</a> - This abbrev ID marks the end of the
+ current block.</li>
+ <li>1 - <a href="#ENTER_SUBBLOCK">ENTER_SUBBLOCK</a> - This abbrev ID marks the
+ beginning of a new block.</li>
+ <li>2 - <a href="#DEFINE_ABBREV">DEFINE_ABBREV</a> - This defines a new
+ abbreviation.</li>
+ <li>3 - <a href="#UNABBREV_RECORD">UNABBREV_RECORD</a> - This ID specifies the
+ definition of an unabbreviated record.</li>
+ </ul>
+
+ <p>Abbreviation IDs 4 and above are defined by the stream itself, and specify
+ an <a href="#abbrev_records">abbreviated record encoding</a>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="blocks">Blocks</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ Blocks in a bitstream denote nested regions of the stream, and are identified by
+ a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
+ function bodies). Block IDs 0-7 are reserved for <a href="#stdblocks">standard blocks</a>
+ whose meaning is defined by Bitcode; block IDs 8 and greater are
+ application specific. Nested blocks capture the hierachical structure of the data
+ encoded in it, and various properties are associated with blocks as the file is
+ parsed. Block definitions allow the reader to efficiently skip blocks
+ in constant time if the reader wants a summary of blocks, or if it wants to
+ efficiently skip data they do not understand. The LLVM IR reader uses this
+ mechanism to skip function bodies, lazily reading them on demand.
+ </p>
+
+ <p>
+ When reading and encoding the stream, several properties are maintained for the
+ block. In particular, each block maintains:
+ </p>
+
+ <ol>
+ <li>A current abbrev id width. This value starts at 2, and is set every time a
+ block record is entered. The block entry specifies the abbrev id width for
+ the body of the block.</li>
+
+ <li>A set of abbreviations. Abbreviations may be defined within a block, in
+ which case they are only defined in that block (neither subblocks nor
+ enclosing blocks see the abbreviation). Abbreviations can also be defined
+ inside a <a href="#BLOCKINFO">BLOCKINFO</a> block, in which case they are
+ defined in all blocks that match the ID that the BLOCKINFO block is describing.
+ </li>
+ </ol>
+
+ <p>As sub blocks are entered, these properties are saved and the new sub-block
+ has its own set of abbreviations, and its own abbrev id width. When a sub-block
+ is popped, the saved values are restored.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="ENTER_SUBBLOCK">ENTER_SUBBLOCK
+ Encoding</a></div>
+
+ <div class="doc_text">
+
+ <p><tt>[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>,
+ <align32bits>, blocklen<sub>32</sub>]</tt></p>
+
+ <p>
+ The ENTER_SUBBLOCK abbreviation ID specifies the start of a new block record.
+ The <tt>blockid</tt> value is encoded as a 8-bit VBR identifier, and indicates
+ the type of block being entered (which can be a <a href="#stdblocks">standard
+ block</a> or an application-specific block). The
+ <tt>newabbrevlen</tt> value is a 4-bit VBR which specifies the
+ abbrev id width for the sub-block. The <tt>blocklen</tt> is a 32-bit aligned
+ value that specifies the size of the subblock, in 32-bit words. This value
+ allows the reader to skip over the entire block in one jump.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="END_BLOCK">END_BLOCK
+ Encoding</a></div>
+
+ <div class="doc_text">
+
+ <p><tt>[END_BLOCK, <align32bits>]</tt></p>
+
+ <p>
+ The END_BLOCK abbreviation ID specifies the end of the current block record.
+ Its end is aligned to 32-bits to ensure that the size of the block is an even
+ multiple of 32-bits.</p>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="datarecord">Data Records</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Data records consist of a record code and a number of (up to) 64-bit integer
+ values. The interpretation of the code and values is application specific and
+ there are multiple different ways to encode a record (with an unabbrev record
+ or with an abbreviation). In the LLVM IR format, for example, there is a record
+ which encodes the target triple of a module. The code is MODULE_CODE_TRIPLE,
+ and the values of the record are the ascii codes for the characters in the
+ string.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="UNABBREV_RECORD">UNABBREV_RECORD
+ Encoding</a></div>
+
+ <div class="doc_text">
+
+ <p><tt>[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>,
+ op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]</tt></p>
+
+ <p>An UNABBREV_RECORD provides a default fallback encoding, which is both
+ completely general and also extremely inefficient. It can describe an arbitrary
+ record, by emitting the code and operands as vbrs.</p>
+
+ <p>For example, emitting an LLVM IR target triple as an unabbreviated record
+ requires emitting the UNABBREV_RECORD abbrevid, a vbr6 for the
+ MODULE_CODE_TRIPLE code, a vbr6 for the length of the string (which is equal to
+ the number of operands), and a vbr6 for each character. Since there are no
+ letters with value less than 32, each letter would need to be emitted as at
+ least a two-part VBR, which means that each letter would require at least 12
+ bits. This is not an efficient encoding, but it is fully general.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="abbrev_records">Abbreviated Record
+ Encoding</a></div>
+
+ <div class="doc_text">
+
+ <p><tt>[<abbrevid>, fields...]</tt></p>
+
+ <p>An abbreviated record is a abbreviation id followed by a set of fields that
+ are encoded according to the <a href="#abbreviations">abbreviation
+ definition</a>. This allows records to be encoded significantly more densely
+ than records encoded with the <a href="#UNABBREV_RECORD">UNABBREV_RECORD</a>
+ type, and allows the abbreviation types to be specified in the stream itself,
+ which allows the files to be completely self describing. The actual encoding
+ of abbreviations is defined below.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="abbreviations">Abbreviations</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Abbreviations are an important form of compression for bitstreams. The idea is
+ to specify a dense encoding for a class of records once, then use that encoding
+ to emit many records. It takes space to emit the encoding into the file, but
+ the space is recouped (hopefully plus some) when the records that use it are
+ emitted.
+ </p>
+
+ <p>
+ Abbreviations can be determined dynamically per client, per file. Since the
+ abbreviations are stored in the bitstream itself, different streams of the same
+ format can contain different sets of abbreviations if the specific stream does
+ not need it. As a concrete example, LLVM IR files usually emit an abbreviation
+ for binary operators. If a specific LLVM module contained no or few binary
+ operators, the abbreviation does not need to be emitted.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="DEFINE_ABBREV">DEFINE_ABBREV
+ Encoding</a></div>
+
+ <div class="doc_text">
+
+ <p><tt>[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1,
+ ...]</tt></p>
+
+ <p>A DEFINE_ABBREV record adds an abbreviation to the list of currently
+ defined abbreviations in the scope of this block. This definition only
+ exists inside this immediate block -- it is not visible in subblocks or
+ enclosing blocks.
+ Abbreviations are implicitly assigned IDs
+ sequentially starting from 4 (the first application-defined abbreviation ID).
+ Any abbreviations defined in a BLOCKINFO record receive IDs first, in order,
+ followed by any abbreviations defined within the block itself.
+ Abbreviated data records reference this ID to indicate what abbreviation
+ they are invoking.</p>
+
+ <p>An abbreviation definition consists of the DEFINE_ABBREV abbrevid followed
+ by a VBR that specifies the number of abbrev operands, then the abbrev
+ operands themselves. Abbreviation operands come in three forms. They all start
+ with a single bit that indicates whether the abbrev operand is a literal operand
+ (when the bit is 1) or an encoding operand (when the bit is 0).</p>
+
+ <ol>
+ <li>Literal operands - <tt>[1<sub>1</sub>, litvalue<sub>vbr8</sub>]</tt> -
+ Literal operands specify that the value in the result
+ is always a single specific value. This specific value is emitted as a vbr8
+ after the bit indicating that it is a literal operand.</li>
+ <li>Encoding info without data - <tt>[0<sub>1</sub>, encoding<sub>3</sub>]</tt>
+ - Operand encodings that do not have extra data are just emitted as their code.
+ </li>
+ <li>Encoding info with data - <tt>[0<sub>1</sub>, encoding<sub>3</sub>,
+ value<sub>vbr5</sub>]</tt> - Operand encodings that do have extra data are
+ emitted as their code, followed by the extra data.
+ </li>
+ </ol>
+
+ <p>The possible operand encodings are:</p>
+
+ <ul>
+ <li>1 - Fixed - The field should be emitted as a <a
+ href="#fixedwidth">fixed-width value</a>, whose width
+ is specified by the operand's extra data.</li>
+ <li>2 - VBR - The field should be emitted as a <a
+ href="#variablewidth">variable-width value</a>, whose width
+ is specified by the operand's extra data.</li>
+ <li>3 - Array - This field is an array of values. The array operand has no
+ extra data, but expects another operand to follow it which indicates the
+ element type of the array. When reading an array in an abbreviated record,
+ the first integer is a vbr6 that indicates the array length, followed by
+ the encoded elements of the array. An array may only occur as the last
+ operand of an abbreviation (except for the one final operand that gives
+ the array's type).</li>
+ <li>4 - Char6 - This field should be emitted as a <a href="#char6">char6-encoded
+ value</a>. This operand type takes no extra data.</li>
+ </ul>
+
+ <p>For example, target triples in LLVM modules are encoded as a record of the
+ form <tt>[TRIPLE, 'a', 'b', 'c', 'd']</tt>. Consider if the bitstream emitted
+ the following abbrev entry:</p>
+
+ <ul>
+ <li><tt>[0, Fixed, 4]</tt></li>
+ <li><tt>[0, Array]</tt></li>
+ <li><tt>[0, Char6]</tt></li>
+ </ul>
+
+ <p>When emitting a record with this abbreviation, the above entry would be
+ emitted as:</p>
+
+ <p><tt>[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>,
+ 0<sub>6</sub>, 1<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]</tt></p>
+
+ <p>These values are:</p>
+
+ <ol>
+ <li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
+ <li>The second value, 2, is the code for TRIPLE in LLVM IR files.</li>
+ <li>The third value, 4, is the length of the array.</li>
+ <li>The rest of the values are the char6 encoded values for "abcd".</li>
+ </ol>
+
+ <p>With this abbreviation, the triple is emitted with only 37 bits (assuming a
+ abbrev id width of 3). Without the abbreviation, significantly more space would
+ be required to emit the target triple. Also, since the TRIPLE value is not
+ emitted as a literal in the abbreviation, the abbreviation can also be used for
+ any other string value.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="stdblocks">Standard Blocks</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ In addition to the basic block structure and record encodings, the bitstream
+ also defines specific builtin block types. These block types specify how the
+ stream is to be decoded or other metadata. In the future, new standard blocks
+ may be added. Block IDs 0-7 are reserved for standard blocks.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="BLOCKINFO">#0 - BLOCKINFO
+ Block</a></div>
+
+ <div class="doc_text">
+
+ <p>The BLOCKINFO block allows the description of metadata for other blocks. The
+ currently specified records are:</p>
+
+ <ul>
+ <li><tt>[SETBID (#1), blockid]</tt></li>
+ <li><tt>[DEFINE_ABBREV, ...]</tt></li>
+ </ul>
+
+ <p>
+ The SETBID record indicates which block ID is being described. SETBID
+ records can occur multiple times throughout the block to change which
+ block ID is being described. There must be a SETBID record prior to
+ any other records.
+ </p>
+
+ <p>
+ Standard DEFINE_ABBREV records can occur inside BLOCKINFO blocks, but unlike
+ their occurrence in normal blocks, the abbreviation is defined for blocks
+ matching the block ID we are describing, <i>not</i> the BLOCKINFO block itself.
+ The abbreviations defined in BLOCKINFO blocks receive abbreviation ids
+ as described in <a href="#DEFINE_ABBREV">DEFINE_ABBREV</a>.
+ </p>
+
+ <p>
+ Note that although the data in BLOCKINFO blocks is described as "metadata," the
+ abbreviations they contain are essential for parsing records from the
+ corresponding blocks. It is not safe to skip them.
+ </p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="wrapper">Bitcode Wrapper Format</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper
+ structure. This structure contains a simple header that indicates the offset
+ and size of the embedded BC file. This allows additional information to be
+ stored alongside the BC file. The structure of this file header is:
+ </p>
+
+ <p>
+ <pre>
+ [Magic<sub>32</sub>,
+ Version<sub>32</sub>,
+ Offset<sub>32</sub>,
+ Size<sub>32</sub>,
+ CPUType<sub>32</sub>]
+ </pre></p>
+
+ <p>Each of the fields are 32-bit fields stored in little endian form (as with
+ the rest of the bitcode file fields). The Magic number is always
+ <tt>0x0B17C0DE</tt> and the version is currently always <tt>0</tt>. The Offset
+ field is the offset in bytes to the start of the bitcode stream in the file, and
+ the Size field is a size in bytes of the stream. CPUType is a target-specific
+ value that can be used to encode the CPU of the target.
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="llvmir">LLVM IR Encoding</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM IR is encoded into a bitstream by defining blocks and records. It uses
+ blocks for things like constant pools, functions, symbol tables, etc. It uses
+ records for things like instructions, global variable descriptors, type
+ descriptions, etc. This document does not describe the set of abbreviations
+ that the writer uses, as these are fully self-described in the file, and the
+ reader is not allowed to build in any knowledge of this.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="basics">Basics</a>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="ir_magic">LLVM IR Magic Number</a></div>
+
+ <div class="doc_text">
+
+ <p>
+ The magic number for LLVM IR files is:
+ </p>
+
+ <p><tt>[0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]</tt></p>
+
+ <p>When combined with the bitcode magic number and viewed as bytes, this is "BC 0xC0DE".</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="ir_signed_vbr">Signed VBRs</a></div>
+
+ <div class="doc_text">
+
+ <p>
+ <a href="#variablewidth">Variable Width Integers</a> are an efficient way to
+ encode arbitrary sized unsigned values, but is an extremely inefficient way to
+ encode signed values (as signed values are otherwise treated as maximally large
+ unsigned values).</p>
+
+ <p>As such, signed vbr values of a specific width are emitted as follows:</p>
+
+ <ul>
+ <li>Positive values are emitted as vbrs of the specified width, but with their
+ value shifted left by one.</li>
+ <li>Negative values are emitted as vbrs of the specified width, but the negated
+ value is shifted left by one, and the low bit is set.</li>
+ </ul>
+
+ <p>With this encoding, small positive and small negative values can both be
+ emitted efficiently.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="ir_blocks">LLVM IR Blocks</a></div>
+
+ <div class="doc_text">
+
+ <p>
+ LLVM IR is defined with the following blocks:
+ </p>
+
+ <ul>
+ <li>8 - MODULE_BLOCK - This is the top-level block that contains the
+ entire module, and describes a variety of per-module information.</li>
+ <li>9 - PARAMATTR_BLOCK - This enumerates the parameter attributes.</li>
+ <li>10 - TYPE_BLOCK - This describes all of the types in the module.</li>
+ <li>11 - CONSTANTS_BLOCK - This describes constants for a module or
+ function.</li>
+ <li>12 - FUNCTION_BLOCK - This describes a function body.</li>
+ <li>13 - TYPE_SYMTAB_BLOCK - This describes the type symbol table.</li>
+ <li>14 - VALUE_SYMTAB_BLOCK - This describes a value symbol table.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="MODULE_BLOCK">MODULE_BLOCK Contents</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ </p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/Bugpoint.html
diff -c /dev/null llvm-www/releases/2.5/docs/Bugpoint.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/Bugpoint.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,239 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM bugpoint tool: design and usage</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <div class="doc_title">
+ LLVM bugpoint tool: design and usage
+ </div>
+
+ <ul>
+ <li><a href="#desc">Description</a></li>
+ <li><a href="#design">Design Philosophy</a>
+ <ul>
+ <li><a href="#autoselect">Automatic Debugger Selection</a></li>
+ <li><a href="#crashdebug">Crash debugger</a></li>
+ <li><a href="#codegendebug">Code generator debugger</a></li>
+ <li><a href="#miscompilationdebug">Miscompilation debugger</a></li>
+ </ul></li>
+ <li><a href="#advice">Advice for using <tt>bugpoint</tt></a></li>
+ </ul>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="desc">Description</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><tt>bugpoint</tt> narrows down the source of problems in LLVM tools and
+ passes. It can be used to debug three types of failures: optimizer crashes,
+ miscompilations by optimizers, or bad native code generation (including problems
+ in the static and JIT compilers). It aims to reduce large test cases to small,
+ useful ones. For example, if <tt>opt</tt> crashes while optimizing a
+ file, it will identify the optimization (or combination of optimizations) that
+ causes the crash, and reduce the file down to a small example which triggers the
+ crash.</p>
+
+ <p>For detailed case scenarios, such as debugging <tt>opt</tt>,
+ <tt>llvm-ld</tt>, or one of the LLVM code generators, see <a
+ href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="design">Design Philosophy</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><tt>bugpoint</tt> is designed to be a useful tool without requiring any
+ hooks into the LLVM infrastructure at all. It works with any and all LLVM
+ passes and code generators, and does not need to "know" how they work. Because
+ of this, it may appear to do stupid things or miss obvious
+ simplifications. <tt>bugpoint</tt> is also designed to trade off programmer
+ time for computer time in the compiler-debugging process; consequently, it may
+ take a long period of (unattended) time to reduce a test case, but we feel it
+ is still worth it. Note that <tt>bugpoint</tt> is generally very quick unless
+ debugging a miscompilation where each test of the program (which requires
+ executing it) takes a long time.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="autoselect">Automatic Debugger Selection</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file specified on
+ the command line and links them together into a single module, called the test
+ program. If any LLVM passes are specified on the command line, it runs these
+ passes on the test program. If any of the passes crash, or if they produce
+ malformed output (which causes the verifier to abort), <tt>bugpoint</tt> starts
+ the <a href="#crashdebug">crash debugger</a>.</p>
+
+ <p>Otherwise, if the <tt>-output</tt> option was not specified,
+ <tt>bugpoint</tt> runs the test program with the C backend (which is assumed to
+ generate good code) to generate a reference output. Once <tt>bugpoint</tt> has
+ a reference output for the test program, it tries executing it with the
+ selected code generator. If the selected code generator crashes,
+ <tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a> on the
+ code generator. Otherwise, if the resulting output differs from the reference
+ output, it assumes the difference resulted from a code generator failure, and
+ starts the <a href="#codegendebug">code generator debugger</a>.</p>
+
+ <p>Finally, if the output of the selected code generator matches the reference
+ output, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
+ have been applied to it. If its output differs from the reference output, it
+ assumes the difference resulted from a failure in one of the LLVM passes, and
+ enters the <a href="#miscompilationdebug">miscompilation debugger</a>.
+ Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="crashdebug">Crash debugger</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard
+ as it can to reduce the list of passes (for optimizer crashes) and the size of
+ the test program. First, <tt>bugpoint</tt> figures out which combination of
+ optimizer passes triggers the bug. This is useful when debugging a problem
+ exposed by <tt>opt</tt>, for example, because it runs over 38 passes.</p>
+
+ <p>Next, <tt>bugpoint</tt> tries removing functions from the test program, to
+ reduce its size. Usually it is able to reduce a test program to a single
+ function, when debugging intraprocedural optimizations. Once the number of
+ functions has been reduced, it attempts to delete various edges in the control
+ flow graph, to reduce the size of the function as much as possible. Finally,
+ <tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
+ not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
+ passes crash, give you a bitcode file, and give you instructions on how to
+ reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="codegendebug">Code generator debugger</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The code generator debugger attempts to narrow down the amount of code that
+ is being miscompiled by the selected code generator. To do this, it takes the
+ test program and partitions it into two pieces: one piece which it compiles
+ with the C backend (into a shared object), and one piece which it runs with
+ either the JIT or the static LLC compiler. It uses several techniques to
+ reduce the amount of code pushed through the LLVM code generator, to reduce the
+ potential scope of the problem. After it is finished, it emits two bitcode
+ files (called "test" [to be compiled with the code generator] and "safe" [to be
+ compiled with the C backend], respectively), and instructions for reproducing
+ the problem. The code generator debugger assumes that the C backend produces
+ good code.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="miscompilationdebug">Miscompilation debugger</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The miscompilation debugger works similarly to the code generator debugger.
+ It works by splitting the test program into two pieces, running the
+ optimizations specified on one piece, linking the two pieces back together, and
+ then executing the result. It attempts to narrow down the list of passes to
+ the one (or few) which are causing the miscompilation, then reduce the portion
+ of the test program which is being miscompiled. The miscompilation debugger
+ assumes that the selected code generator is working properly.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="advice">Advice for using bugpoint</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <tt>bugpoint</tt> can be a remarkably useful tool, but it sometimes works in
+ non-obvious ways. Here are some hints and tips:<p>
+
+ <ol>
+ <li>In the code generator and miscompilation debuggers, <tt>bugpoint</tt> only
+ works with programs that have deterministic output. Thus, if the program
+ outputs <tt>argv[0]</tt>, the date, time, or any other "random" data,
+ <tt>bugpoint</tt> may misinterpret differences in these data, when output,
+ as the result of a miscompilation. Programs should be temporarily modified
+ to disable outputs that are likely to vary from run to run.
+
+ <li>In the code generator and miscompilation debuggers, debugging will go
+ faster if you manually modify the program or its inputs to reduce the
+ runtime, but still exhibit the problem.
+
+ <li><tt>bugpoint</tt> is extremely useful when working on a new optimization:
+ it helps track down regressions quickly. To avoid having to relink
+ <tt>bugpoint</tt> every time you change your optimization however, have
+ <tt>bugpoint</tt> dynamically load your optimization with the
+ <tt>-load</tt> option.
+
+ <li><p><tt>bugpoint</tt> can generate a lot of output and run for a long period
+ of time. It is often useful to capture the output of the program to file.
+ For example, in the C shell, you can run:</p>
+
+ <div class="doc_code">
+ <p><tt>bugpoint ... |& tee bugpoint.log</tt></p>
+ </div>
+
+ <p>to get a copy of <tt>bugpoint</tt>'s output in the file
+ <tt>bugpoint.log</tt>, as well as on your terminal.</p>
+
+ <li><tt>bugpoint</tt> cannot debug problems with the LLVM linker. If
+ <tt>bugpoint</tt> crashes before you see its "All input ok" message,
+ you might try <tt>llvm-link -v</tt> on the same set of input files. If
+ that also crashes, you may be experiencing a linker bug.
+
+ <li><tt>bugpoint</tt> is useful for proactively finding bugs in LLVM.
+ Invoking <tt>bugpoint</tt> with the <tt>-find-bugs</tt> option will cause
+ the list of specified optimizations to be randomized and applied to the
+ program. This process will repeat until a bug is found or the user
+ kills <tt>bugpoint</tt>.
+
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CFEBuildInstrs.html
diff -c /dev/null llvm-www/releases/2.5/docs/CFEBuildInstrs.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CFEBuildInstrs.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,29 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <link rel="stylesheet" href="llvm.css" type="text/css" media="screen">
+ <title>Building the LLVM C/C++ Front-End</title>
+ <meta HTTP-EQUIV="REFRESH" CONTENT="3; URL=GCCFEBuildInstrs.html">
+ </head>
+ <body>
+ <div class="doc_title">
+ This page has moved <a href="GCCFEBuildInstrs.html">here</A>.
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CMake.html
diff -c /dev/null llvm-www/releases/2.5/docs/CMake.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CMake.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,360 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Building LLVM with CMake</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <div class="doc_title">
+ Building LLVM with CMake
+ </div>
+
+ <ul>
+ <li><a href="#intro">Introduction</a></li>
+ <li><a href="#quickstart">Quick start</a></li>
+ <li><a href="#usage">Basic CMake usage</a>
+ <li><a href="#options">Options and variables</a>
+ <ul>
+ <li><a href="#freccmake">Frequently-used CMake variables</a></li>
+ <li><a href="#llvmvars">LLVM-specific variables</a></li>
+ </ul></li>
+ <li><a href="#testing">Executing the test suite</a>
+ <li><a href="#cross">Cross compiling</a>
+ <li><a href="#embedding">Embedding LLVM in your project</a>
+ <li><a href="#specifics">Compiler/Platform specific topics</a>
+ <ul>
+ <li><a href="#msvc">Microsoft Visual C++</a></li>
+ </ul></li>
+ </ul>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:ofv at wanadoo.es">Oscar Fuentes</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="intro">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><a href="http://www.cmake.org/">CMake</a> is a cross-platform
+ build-generator tool. CMake does not build the project, it generates
+ the files needed by your build tool (GNU make, Visual Studio, etc) for
+ building LLVM.</p>
+
+ <p>If you are really anxious about getting a functional LLVM build,
+ go to the <a href="#quickstart">Quick start</a> section. If you
+ are a CMake novice, start on <a href="#usage">Basic CMake
+ usage</a> and then go back to the <a href="#quickstart">Quick
+ start</a> once you know what you are
+ doing. The <a href="#options">Options and variables</a> section
+ is a reference for customizing your build. If you already have
+ experience with CMake, this is the recommended starting point.
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="quickstart">Quick start</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p> We use here the command-line, non-interactive CMake interface </p>
+
+ <ol>
+
+ <li><p><a href=http://www.cmake.org/cmake/resources/software.html>Download</a>
+ and install CMake. Version 2.6.2 is the minimum required.</p>
+
+ <li><p>Open a shell. Your development tools must be reachable from this
+ shell through the PATH environment variable.</p>
+
+ <li><p>Create a directory for containing the build. It is not
+ supported to build LLVM on the source directory. cd to this
+ directory:</p>
+ <div class="doc_code">
+ <p><tt>mkdir mybuilddir</tt></p>
+ <p><tt>cd mybuilddir</tt></p>
+ </div>
+
+ <li><p>Execute this command on the shell
+ replacing <i>path/to/llvm/source/root</i> with the path to the
+ root of your LLVM source tree:</p>
+ <div class="doc_code">
+ <p><tt>cmake path/to/llvm/source/root</tt></p>
+ </div>
+
+ <p>CMake will detect your development environment, perform a
+ series of test and generate the files required for building
+ LLVM. CMake will use default values for all build
+ parameters. See the <a href="#options">Options and variables</a>
+ section for fine-tuning your build</p>
+
+ <p>This can fail if CMake can't detect your toolset, or if it
+ thinks that the environment is not sane enough. On this case
+ make sure that the toolset that you intend to use is the only
+ one reachable from the shell and that the shell itself is the
+ correct one for you development environment. CMake will refuse
+ to build MinGW makefiles if you have a POSIX shell reachable
+ through the PATH environment variable, for instance. You can
+ force CMake to use a given build tool, see
+ the <a href="#usage">Usage</a> section.</p>
+
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="usage">Basic CMake usage</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section explains basic aspects of CMake, mostly for
+ explaining those options which you may need on your day-to-day
+ usage.</p>
+
+ <p>CMake comes with extensive documentation in the form of html
+ files and on the cmake executable itself. Execute <i>cmake
+ --help</i> for further help options.</p>
+
+ <p>CMake requires to know for which build tool it shall generate
+ files (GNU make, Visual Studio, Xcode, etc). If not specified on
+ the command line, it tries to guess it based on you
+ environment. Once identified the build tool, CMake uses the
+ corresponding <i>Generator</i> for creating files for your build
+ tool. You can explicitly specify the generator with the command
+ line option <i>-G "Name of the generator"</i>. For knowing the
+ available generators on your platform, execute</p>
+
+ <div class="doc_code">
+ <p><tt>cmake --help</tt></p>
+ </div>
+
+ <p>This will list the generator's names at the end of the help
+ text. Generator's names are case-sensitive. Example:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -G "Visual Studio 8 2005" path/to/llvm/source/root</tt></p>
+ </div>
+
+ <p>For a given development platform there can be more than one
+ adequate generator. If you use Visual Studio "NMake Makefiles"
+ is a generator you can use for building with NMake. By default,
+ CMake chooses the more specific generator supported by your
+ development environment. If you want an alternative generator,
+ you must tell this to CMake with the <i>-G</i> option.</p>
+
+ <p>TODO: explain variables and cache. Move explanation here from
+ #options section.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="options">Options and variables</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Variables customize how the build will be generated. Options are
+ boolean variables, with possible values ON/OFF. Options and
+ variables are defined on the CMake command line like this:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -DVARIABLE=value path/to/llvm/source</tt></p>
+ </div>
+
+ <p>You can set a variable after the initial CMake invocation for
+ changing its value. You can also undefine a variable:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -UVARIABLE path/to/llvm/source</tt></p>
+ </div>
+
+ <p>Variables are stored on the CMake cache. This is a file
+ named <it>CMakeCache.txt</it> on the root of the build
+ directory. Do not hand-edit it.</p>
+
+ <p>Variables are listed here appending its type after a colon. It is
+ correct to write the variable and the type on the CMake command
+ line:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -DVARIABLE:TYPE=value path/to/llvm/source</tt></p>
+ </div>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="freccmake">Frequently-used CMake variables</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Here are listed some of the CMake variables that are used often,
+ along with a brief explanation and LLVM-specific notes. For full
+ documentation, check the CMake docs or execute <i>cmake
+ --help-variable VARIABLE_NAME</i>.</p>
+
+ <dl>
+ <dt><b>CMAKE_BUILD_TYPE</b>:STRING</dt>
+
+ <dd>Sets the build type for <i>make</i> based generators. Possible
+ values are Release, Debug, RelWithDebInfo and MiniSizeRel. On
+ systems like Visual Studio the user sets the build type with the IDE
+ settings.</dd>
+
+ <dt><b>CMAKE_INSTALL_PREFIX</b>:PATH</dt>
+ <dd>Path where LLVM will be installed if "make install" is invoked
+ or the "INSTALL" target is built.</dd>
+
+ <dt><b>CMAKE_C_FLAGS</b>:STRING</dt>
+ <dd>Extra flags to use when compiling C source files.</dd>
+
+ <dt><b>CMAKE_CXX_FLAGS</b>:STRING</dt>
+ <dd>Extra flags to use when compiling C++ source files.</dd>
+
+ <dt><b>BUILD_SHARED_LIBS</b>:BOOL</dt>
+ <dd>Flag indicating is shared libraries will be built. Its default
+ value is OFF. Shared libraries are not supported on Windows and
+ not recommended in the other OSes.</dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="llvmvars">LLVM-specific variables</a>
+ </div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt><b>LLVM_TARGETS_TO_BUILD</b>:STRING</dt>
+ <dd>Semicolon-separated list of targets to build, or <i>all</i> for
+ building all targets. Case-sensitive. For Visual C++ defaults
+ to <i>X86</i>. On the other cases defaults to <i>all</i>. Example:
+ <i>-DLLVM_TARGETS_TO_BUILD="X86;PowerPC;Alpha"</i>.</dd>
+
+ <dt><b>LLVM_ENABLE_THREADS</b>:BOOL</dt>
+ <dd>Build with threads support, if available. Defaults to ON.</dd>
+
+ <dt><b>LLVM_ENABLE_PIC</b>:BOOL</dt>
+ <dd>Add the <i>-fPIC</i> flag to the compiler command-line, if the
+ compiler supports this flag. Some systems, like Windows, does not
+ need this flag. Defaults to OFF.</dd>
+
+ <dt><b>LLVM_BUILD_32_BITS</b>:BOOL</dt>
+ <dd>Build 32-bits executables and libraries on 64-bits systems. This
+ option is available only on some 64-bits unix systems. Defaults to
+ OFF.</dd>
+
+ <dt><b>LLVM_PLO_FLAGS</b>:STRING</dt>
+ <dd>Extra flags for creating partially linked objects. Visual C++
+ does not use this.</dd>
+
+ <dt><b>LLVM_TABLEGEN</b>:STRING</dt>
+ <dd>Full path to a native TableGen executable (usually
+ named <i>tblgen</i>). This is intented for cross-compiling: if the
+ user sets this variable, no native TableGen will be created.</dd>
+ </dl>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="testing">Executing the test suite</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM testing is not supported on Visual Studio.</p>
+
+ <p>TODO</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="cross">Cross compiling</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>TODO</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="embedding">Embedding LLVM in your project</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>TODO</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="specifics">Compiler/Platform specific topics</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Notes for specific compilers and/or platforms.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="msvc">Microsoft Visual C++</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>For linking the JIT into your executable, add</p>
+
+ <div class="doc_code">
+ <p><tt>/INCLUDE:_X86TargetMachineModule</tt></p>
+ </div>
+
+ <p>to your linker options. This is required for adding the relevant
+ LLVM object code to the executable. Not doing this will result on
+ some methods returning NULL (<i>ExecutionEngine::create</i>, for
+ instance).</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:ofv at wanadoo.es">Oscar Fuentes</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CodeGenerator.html
diff -c /dev/null llvm-www/releases/2.5/docs/CodeGenerator.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CodeGenerator.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,2063 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8">
+ <title>The LLVM Target-Independent Code Generator</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ The LLVM Target-Independent Code Generator
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a>
+ <ul>
+ <li><a href="#required">Required components in the code generator</a></li>
+ <li><a href="#high-level-design">The high-level design of the code
+ generator</a></li>
+ <li><a href="#tablegen">Using TableGen for target description</a></li>
+ </ul>
+ </li>
+ <li><a href="#targetdesc">Target description classes</a>
+ <ul>
+ <li><a href="#targetmachine">The <tt>TargetMachine</tt> class</a></li>
+ <li><a href="#targetdata">The <tt>TargetData</tt> class</a></li>
+ <li><a href="#targetlowering">The <tt>TargetLowering</tt> class</a></li>
+ <li><a href="#targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a></li>
+ <li><a href="#targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a></li>
+ <li><a href="#targetframeinfo">The <tt>TargetFrameInfo</tt> class</a></li>
+ <li><a href="#targetsubtarget">The <tt>TargetSubtarget</tt> class</a></li>
+ <li><a href="#targetjitinfo">The <tt>TargetJITInfo</tt> class</a></li>
+ </ul>
+ </li>
+ <li><a href="#codegendesc">Machine code description classes</a>
+ <ul>
+ <li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
+ <li><a href="#machinebasicblock">The <tt>MachineBasicBlock</tt>
+ class</a></li>
+ <li><a href="#machinefunction">The <tt>MachineFunction</tt> class</a></li>
+ </ul>
+ </li>
+ <li><a href="#codegenalgs">Target-independent code generation algorithms</a>
+ <ul>
+ <li><a href="#instselect">Instruction Selection</a>
+ <ul>
+ <li><a href="#selectiondag_intro">Introduction to SelectionDAGs</a></li>
+ <li><a href="#selectiondag_process">SelectionDAG Code Generation
+ Process</a></li>
+ <li><a href="#selectiondag_build">Initial SelectionDAG
+ Construction</a></li>
+ <li><a href="#selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a></li>
+ <li><a href="#selectiondag_legalize">SelectionDAG Legalize Phase</a></li>
+ <li><a href="#selectiondag_optimize">SelectionDAG Optimization
+ Phase: the DAG Combiner</a></li>
+ <li><a href="#selectiondag_select">SelectionDAG Select Phase</a></li>
+ <li><a href="#selectiondag_sched">SelectionDAG Scheduling and Formation
+ Phase</a></li>
+ <li><a href="#selectiondag_future">Future directions for the
+ SelectionDAG</a></li>
+ </ul></li>
+ <li><a href="#liveintervals">Live Intervals</a>
+ <ul>
+ <li><a href="#livevariable_analysis">Live Variable Analysis</a></li>
+ <li><a href="#liveintervals_analysis">Live Intervals Analysis</a></li>
+ </ul></li>
+ <li><a href="#regalloc">Register Allocation</a>
+ <ul>
+ <li><a href="#regAlloc_represent">How registers are represented in
+ LLVM</a></li>
+ <li><a href="#regAlloc_howTo">Mapping virtual registers to physical
+ registers</a></li>
+ <li><a href="#regAlloc_twoAddr">Handling two address instructions</a></li>
+ <li><a href="#regAlloc_ssaDecon">The SSA deconstruction phase</a></li>
+ <li><a href="#regAlloc_fold">Instruction folding</a></li>
+ <li><a href="#regAlloc_builtIn">Built in register allocators</a></li>
+ </ul></li>
+ <li><a href="#codeemit">Code Emission</a>
+ <ul>
+ <li><a href="#codeemit_asm">Generating Assembly Code</a></li>
+ <li><a href="#codeemit_bin">Generating Binary Machine Code</a></li>
+ </ul></li>
+ </ul>
+ </li>
+ <li><a href="#targetimpls">Target-specific Implementation Notes</a>
+ <ul>
+ <li><a href="#tailcallopt">Tail call optimization</a></li>
+ <li><a href="#x86">The X86 backend</a></li>
+ <li><a href="#ppc">The PowerPC backend</a>
+ <ul>
+ <li><a href="#ppc_abi">LLVM PowerPC ABI</a></li>
+ <li><a href="#ppc_frame">Frame Layout</a></li>
+ <li><a href="#ppc_prolog">Prolog/Epilog</a></li>
+ <li><a href="#ppc_dynamic">Dynamic Allocation</a></li>
+ </ul></li>
+ </ul></li>
+
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
+ <a href="mailto:isanbard at gmail.com">Bill Wendling</a>,
+ <a href="mailto:pronesto at gmail.com">Fernando Magno Quintao
+ Pereira</a> and
+ <a href="mailto:jlaskey at mac.com">Jim Laskey</a></p>
+ </div>
+
+ <div class="doc_warning">
+ <p>Warning: This is a work in progress.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM target-independent code generator is a framework that provides a
+ suite of reusable components for translating the LLVM internal representation to
+ the machine code for a specified target—either in assembly form (suitable
+ for a static compiler) or in binary machine code format (usable for a JIT
+ compiler). The LLVM target-independent code generator consists of five main
+ components:</p>
+
+ <ol>
+ <li><a href="#targetdesc">Abstract target description</a> interfaces which
+ capture important properties about various aspects of the machine, independently
+ of how they will be used. These interfaces are defined in
+ <tt>include/llvm/Target/</tt>.</li>
+
+ <li>Classes used to represent the <a href="#codegendesc">machine code</a> being
+ generated for a target. These classes are intended to be abstract enough to
+ represent the machine code for <i>any</i> target machine. These classes are
+ defined in <tt>include/llvm/CodeGen/</tt>.</li>
+
+ <li><a href="#codegenalgs">Target-independent algorithms</a> used to implement
+ various phases of native code generation (register allocation, scheduling, stack
+ frame representation, etc). This code lives in <tt>lib/CodeGen/</tt>.</li>
+
+ <li><a href="#targetimpls">Implementations of the abstract target description
+ interfaces</a> for particular targets. These machine descriptions make use of
+ the components provided by LLVM, and can optionally provide custom
+ target-specific passes, to build complete code generators for a specific target.
+ Target descriptions live in <tt>lib/Target/</tt>.</li>
+
+ <li><a href="#jit">The target-independent JIT components</a>. The LLVM JIT is
+ completely target independent (it uses the <tt>TargetJITInfo</tt> structure to
+ interface for target-specific issues. The code for the target-independent
+ JIT lives in <tt>lib/ExecutionEngine/JIT</tt>.</li>
+
+ </ol>
+
+ <p>
+ Depending on which part of the code generator you are interested in working on,
+ different pieces of this will be useful to you. In any case, you should be
+ familiar with the <a href="#targetdesc">target description</a> and <a
+ href="#codegendesc">machine code representation</a> classes. If you want to add
+ a backend for a new target, you will need to <a href="#targetimpls">implement the
+ target description</a> classes for your new target and understand the <a
+ href="LangRef.html">LLVM code representation</a>. If you are interested in
+ implementing a new <a href="#codegenalgs">code generation algorithm</a>, it
+ should only depend on the target-description and machine code representation
+ classes, ensuring that it is portable.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="required">Required components in the code generator</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The two pieces of the LLVM code generator are the high-level interface to the
+ code generator and the set of reusable components that can be used to build
+ target-specific backends. The two most important interfaces (<a
+ href="#targetmachine"><tt>TargetMachine</tt></a> and <a
+ href="#targetdata"><tt>TargetData</tt></a>) are the only ones that are
+ required to be defined for a backend to fit into the LLVM system, but the others
+ must be defined if the reusable code generator components are going to be
+ used.</p>
+
+ <p>This design has two important implications. The first is that LLVM can
+ support completely non-traditional code generation targets. For example, the C
+ backend does not require register allocation, instruction selection, or any of
+ the other standard components provided by the system. As such, it only
+ implements these two interfaces, and does its own thing. Another example of a
+ code generator like this is a (purely hypothetical) backend that converts LLVM
+ to the GCC RTL form and uses GCC to emit machine code for a target.</p>
+
+ <p>This design also implies that it is possible to design and
+ implement radically different code generators in the LLVM system that do not
+ make use of any of the built-in components. Doing so is not recommended at all,
+ but could be required for radically different targets that do not fit into the
+ LLVM machine description model: FPGAs for example.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="high-level-design">The high-level design of the code generator</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The LLVM target-independent code generator is designed to support efficient and
+ quality code generation for standard register-based microprocessors. Code
+ generation in this model is divided into the following stages:</p>
+
+ <ol>
+ <li><b><a href="#instselect">Instruction Selection</a></b> - This phase
+ determines an efficient way to express the input LLVM code in the target
+ instruction set.
+ This stage produces the initial code for the program in the target instruction
+ set, then makes use of virtual registers in SSA form and physical registers that
+ represent any required register assignments due to target constraints or calling
+ conventions. This step turns the LLVM code into a DAG of target
+ instructions.</li>
+
+ <li><b><a href="#selectiondag_sched">Scheduling and Formation</a></b> - This
+ phase takes the DAG of target instructions produced by the instruction selection
+ phase, determines an ordering of the instructions, then emits the instructions
+ as <tt><a href="#machineinstr">MachineInstr</a></tt>s with that ordering. Note
+ that we describe this in the <a href="#instselect">instruction selection
+ section</a> because it operates on a <a
+ href="#selectiondag_intro">SelectionDAG</a>.
+ </li>
+
+ <li><b><a href="#ssamco">SSA-based Machine Code Optimizations</a></b> - This
+ optional stage consists of a series of machine-code optimizations that
+ operate on the SSA-form produced by the instruction selector. Optimizations
+ like modulo-scheduling or peephole optimization work here.
+ </li>
+
+ <li><b><a href="#regalloc">Register Allocation</a></b> - The
+ target code is transformed from an infinite virtual register file in SSA form
+ to the concrete register file used by the target. This phase introduces spill
+ code and eliminates all virtual register references from the program.</li>
+
+ <li><b><a href="#proepicode">Prolog/Epilog Code Insertion</a></b> - Once the
+ machine code has been generated for the function and the amount of stack space
+ required is known (used for LLVM alloca's and spill slots), the prolog and
+ epilog code for the function can be inserted and "abstract stack location
+ references" can be eliminated. This stage is responsible for implementing
+ optimizations like frame-pointer elimination and stack packing.</li>
+
+ <li><b><a href="#latemco">Late Machine Code Optimizations</a></b> - Optimizations
+ that operate on "final" machine code can go here, such as spill code scheduling
+ and peephole optimizations.</li>
+
+ <li><b><a href="#codeemit">Code Emission</a></b> - The final stage actually
+ puts out the code for the current function, either in the target assembler
+ format or in machine code.</li>
+
+ </ol>
+
+ <p>The code generator is based on the assumption that the instruction selector
+ will use an optimal pattern matching selector to create high-quality sequences of
+ native instructions. Alternative code generator designs based on pattern
+ expansion and aggressive iterative peephole optimization are much slower. This
+ design permits efficient compilation (important for JIT environments) and
+ aggressive optimization (used when generating code offline) by allowing
+ components of varying levels of sophistication to be used for any step of
+ compilation.</p>
+
+ <p>In addition to these stages, target implementations can insert arbitrary
+ target-specific passes into the flow. For example, the X86 target uses a
+ special pass to handle the 80x87 floating point stack architecture. Other
+ targets with unusual requirements can be supported with custom passes as
+ needed.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="tablegen">Using TableGen for target description</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The target description classes require a detailed description of the target
+ architecture. These target descriptions often have a large amount of common
+ information (e.g., an <tt>add</tt> instruction is almost identical to a
+ <tt>sub</tt> instruction).
+ In order to allow the maximum amount of commonality to be factored out, the LLVM
+ code generator uses the <a href="TableGenFundamentals.html">TableGen</a> tool to
+ describe big chunks of the target machine, which allows the use of
+ domain-specific and target-specific abstractions to reduce the amount of
+ repetition.</p>
+
+ <p>As LLVM continues to be developed and refined, we plan to move more and more
+ of the target description to the <tt>.td</tt> form. Doing so gives us a
+ number of advantages. The most important is that it makes it easier to port
+ LLVM because it reduces the amount of C++ code that has to be written, and the
+ surface area of the code generator that needs to be understood before someone
+ can get something working. Second, it makes it easier to change things. In
+ particular, if tables and other things are all emitted by <tt>tblgen</tt>, we
+ only need a change in one place (<tt>tblgen</tt>) to update all of the targets
+ to a new interface.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="targetdesc">Target description classes</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM target description classes (located in the
+ <tt>include/llvm/Target</tt> directory) provide an abstract description of the
+ target machine independent of any particular client. These classes are
+ designed to capture the <i>abstract</i> properties of the target (such as the
+ instructions and registers it has), and do not incorporate any particular pieces
+ of code generation algorithms.</p>
+
+ <p>All of the target description classes (except the <tt><a
+ href="#targetdata">TargetData</a></tt> class) are designed to be subclassed by
+ the concrete target implementation, and have virtual methods implemented. To
+ get to these implementations, the <tt><a
+ href="#targetmachine">TargetMachine</a></tt> class provides accessors that
+ should be implemented by the target.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetmachine">The <tt>TargetMachine</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>TargetMachine</tt> class provides virtual methods that are used to
+ access the target-specific implementations of the various target description
+ classes via the <tt>get*Info</tt> methods (<tt>getInstrInfo</tt>,
+ <tt>getRegisterInfo</tt>, <tt>getFrameInfo</tt>, etc.). This class is
+ designed to be specialized by
+ a concrete target implementation (e.g., <tt>X86TargetMachine</tt>) which
+ implements the various virtual methods. The only required target description
+ class is the <a href="#targetdata"><tt>TargetData</tt></a> class, but if the
+ code generator components are to be used, the other interfaces should be
+ implemented as well.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetdata">The <tt>TargetData</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>TargetData</tt> class is the only required target description class,
+ and it is the only class that is not extensible (you cannot derived a new
+ class from it). <tt>TargetData</tt> specifies information about how the target
+ lays out memory for structures, the alignment requirements for various data
+ types, the size of pointers in the target, and whether the target is
+ little-endian or big-endian.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetlowering">The <tt>TargetLowering</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>TargetLowering</tt> class is used by SelectionDAG based instruction
+ selectors primarily to describe how LLVM code should be lowered to SelectionDAG
+ operations. Among other things, this class indicates:</p>
+
+ <ul>
+ <li>an initial register class to use for various <tt>ValueType</tt>s</li>
+ <li>which operations are natively supported by the target machine</li>
+ <li>the return type of <tt>setcc</tt> operations</li>
+ <li>the type to use for shift amounts</li>
+ <li>various high-level characteristics, like whether it is profitable to turn
+ division by a constant into a multiplication sequence</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>TargetRegisterInfo</tt> class is used to describe the register
+ file of the target and any interactions between the registers.</p>
+
+ <p>Registers in the code generator are represented in the code generator by
+ unsigned integers. Physical registers (those that actually exist in the target
+ description) are unique small numbers, and virtual registers are generally
+ large. Note that register #0 is reserved as a flag value.</p>
+
+ <p>Each register in the processor description has an associated
+ <tt>TargetRegisterDesc</tt> entry, which provides a textual name for the
+ register (used for assembly output and debugging dumps) and a set of aliases
+ (used to indicate whether one register overlaps with another).
+ </p>
+
+ <p>In addition to the per-register description, the <tt>TargetRegisterInfo</tt>
+ class exposes a set of processor specific register classes (instances of the
+ <tt>TargetRegisterClass</tt> class). Each register class contains sets of
+ registers that have the same properties (for example, they are all 32-bit
+ integer registers). Each SSA virtual register created by the instruction
+ selector has an associated register class. When the register allocator runs, it
+ replaces virtual registers with a physical register in the set.</p>
+
+ <p>
+ The target-specific implementations of these classes is auto-generated from a <a
+ href="TableGenFundamentals.html">TableGen</a> description of the register file.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The <tt>TargetInstrInfo</tt> class is used to describe the machine
+ instructions supported by the target. It is essentially an array of
+ <tt>TargetInstrDescriptor</tt> objects, each of which describes one
+ instruction the target supports. Descriptors define things like the mnemonic
+ for the opcode, the number of operands, the list of implicit register uses
+ and defs, whether the instruction has certain target-independent properties
+ (accesses memory, is commutable, etc), and holds any target-specific
+ flags.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetframeinfo">The <tt>TargetFrameInfo</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The <tt>TargetFrameInfo</tt> class is used to provide information about the
+ stack frame layout of the target. It holds the direction of stack growth,
+ the known stack alignment on entry to each function, and the offset to the
+ local area. The offset to the local area is the offset from the stack
+ pointer on function entry to the first location where function data (local
+ variables, spill locations) can be stored.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetsubtarget">The <tt>TargetSubtarget</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The <tt>TargetSubtarget</tt> class is used to provide information about the
+ specific chip set being targeted. A sub-target informs code generation of
+ which instructions are supported, instruction latencies and instruction
+ execution itinerary; i.e., which processing units are used, in what order, and
+ for how long.</p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetjitinfo">The <tt>TargetJITInfo</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The <tt>TargetJITInfo</tt> class exposes an abstract interface used by the
+ Just-In-Time code generator to perform target-specific activities, such as
+ emitting stubs. If a <tt>TargetMachine</tt> supports JIT code generation, it
+ should provide one of these objects through the <tt>getJITInfo</tt>
+ method.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="codegendesc">Machine code description classes</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>At the high-level, LLVM code is translated to a machine specific
+ representation formed out of
+ <a href="#machinefunction"><tt>MachineFunction</tt></a>,
+ <a href="#machinebasicblock"><tt>MachineBasicBlock</tt></a>, and <a
+ href="#machineinstr"><tt>MachineInstr</tt></a> instances
+ (defined in <tt>include/llvm/CodeGen</tt>). This representation is completely
+ target agnostic, representing instructions in their most abstract form: an
+ opcode and a series of operands. This representation is designed to support
+ both an SSA representation for machine code, as well as a register allocated,
+ non-SSA form.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="machineinstr">The <tt>MachineInstr</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Target machine instructions are represented as instances of the
+ <tt>MachineInstr</tt> class. This class is an extremely abstract way of
+ representing machine instructions. In particular, it only keeps track of
+ an opcode number and a set of operands.</p>
+
+ <p>The opcode number is a simple unsigned integer that only has meaning to a
+ specific backend. All of the instructions for a target should be defined in
+ the <tt>*InstrInfo.td</tt> file for the target. The opcode enum values
+ are auto-generated from this description. The <tt>MachineInstr</tt> class does
+ not have any information about how to interpret the instruction (i.e., what the
+ semantics of the instruction are); for that you must refer to the
+ <tt><a href="#targetinstrinfo">TargetInstrInfo</a></tt> class.</p>
+
+ <p>The operands of a machine instruction can be of several different types:
+ a register reference, a constant integer, a basic block reference, etc. In
+ addition, a machine operand should be marked as a def or a use of the value
+ (though only registers are allowed to be defs).</p>
+
+ <p>By convention, the LLVM code generator orders instruction operands so that
+ all register definitions come before the register uses, even on architectures
+ that are normally printed in other orders. For example, the SPARC add
+ instruction: "<tt>add %i1, %i2, %i3</tt>" adds the "%i1", and "%i2" registers
+ and stores the result into the "%i3" register. In the LLVM code generator,
+ the operands should be stored as "<tt>%i3, %i1, %i2</tt>": with the destination
+ first.</p>
+
+ <p>Keeping destination (definition) operands at the beginning of the operand
+ list has several advantages. In particular, the debugging printer will print
+ the instruction like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ %r3 = add %i1, %i2
+ </pre>
+ </div>
+
+ <p>Also if the first operand is a def, it is easier to <a
+ href="#buildmi">create instructions</a> whose only def is the first
+ operand.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="buildmi">Using the <tt>MachineInstrBuilder.h</tt> functions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Machine instructions are created by using the <tt>BuildMI</tt> functions,
+ located in the <tt>include/llvm/CodeGen/MachineInstrBuilder.h</tt> file. The
+ <tt>BuildMI</tt> functions make it easy to build arbitrary machine
+ instructions. Usage of the <tt>BuildMI</tt> functions look like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
+ // instruction. The '1' specifies how many operands will be added.
+ MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
+
+ // Create the same instr, but insert it at the end of a basic block.
+ MachineBasicBlock &MBB = ...
+ BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
+
+ // Create the same instr, but insert it before a specified iterator point.
+ MachineBasicBlock::iterator MBBI = ...
+ BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
+
+ // Create a 'cmp Reg, 0' instruction, no destination reg.
+ MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
+ // Create an 'sahf' instruction which takes no operands and stores nothing.
+ MI = BuildMI(X86::SAHF, 0);
+
+ // Create a self looping branch instruction.
+ BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
+ </pre>
+ </div>
+
+ <p>The key thing to remember with the <tt>BuildMI</tt> functions is that you
+ have to specify the number of operands that the machine instruction will take.
+ This allows for efficient memory allocation. You also need to specify if
+ operands default to be uses of values, not definitions. If you need to add a
+ definition operand (other than the optional destination register), you must
+ explicitly mark it as such:</p>
+
+ <div class="doc_code">
+ <pre>
+ MI.addReg(Reg, MachineOperand::Def);
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="fixedregs">Fixed (preassigned) registers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>One important issue that the code generator needs to be aware of is the
+ presence of fixed registers. In particular, there are often places in the
+ instruction stream where the register allocator <em>must</em> arrange for a
+ particular value to be in a particular register. This can occur due to
+ limitations of the instruction set (e.g., the X86 can only do a 32-bit divide
+ with the <tt>EAX</tt>/<tt>EDX</tt> registers), or external factors like calling
+ conventions. In any case, the instruction selector should emit code that
+ copies a virtual register into or out of a physical register when needed.</p>
+
+ <p>For example, consider this simple LLVM example:</p>
+
+ <div class="doc_code">
+ <pre>
+ define i32 @test(i32 %X, i32 %Y) {
+ %Z = udiv i32 %X, %Y
+ ret i32 %Z
+ }
+ </pre>
+ </div>
+
+ <p>The X86 instruction selector produces this machine code for the <tt>div</tt>
+ and <tt>ret</tt> (use
+ "<tt>llc X.bc -march=x86 -print-machineinstrs</tt>" to get this):</p>
+
+ <div class="doc_code">
+ <pre>
+ ;; Start of div
+ %EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
+ %reg1027 = sar %reg1024, 31
+ %EDX = mov %reg1027 ;; Sign extend X into EDX
+ idiv %reg1025 ;; Divide by Y (in reg1025)
+ %reg1026 = mov %EAX ;; Read the result (Z) out of EAX
+
+ ;; Start of ret
+ %EAX = mov %reg1026 ;; 32-bit return value goes in EAX
+ ret
+ </pre>
+ </div>
+
+ <p>By the end of code generation, the register allocator has coalesced
+ the registers and deleted the resultant identity moves producing the
+ following code:</p>
+
+ <div class="doc_code">
+ <pre>
+ ;; X is in EAX, Y is in ECX
+ mov %EAX, %EDX
+ sar %EDX, 31
+ idiv %ECX
+ ret
+ </pre>
+ </div>
+
+ <p>This approach is extremely general (if it can handle the X86 architecture,
+ it can handle anything!) and allows all of the target specific
+ knowledge about the instruction stream to be isolated in the instruction
+ selector. Note that physical registers should have a short lifetime for good
+ code generation, and all physical registers are assumed dead on entry to and
+ exit from basic blocks (before register allocation). Thus, if you need a value
+ to be live across basic block boundaries, it <em>must</em> live in a virtual
+ register.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ssa">Machine code in SSA form</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>MachineInstr</tt>'s are initially selected in SSA-form, and
+ are maintained in SSA-form until register allocation happens. For the most
+ part, this is trivially simple since LLVM is already in SSA form; LLVM PHI nodes
+ become machine code PHI nodes, and virtual registers are only allowed to have a
+ single definition.</p>
+
+ <p>After register allocation, machine code is no longer in SSA-form because there
+ are no virtual registers left in the code.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="machinebasicblock">The <tt>MachineBasicBlock</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>MachineBasicBlock</tt> class contains a list of machine instructions
+ (<tt><a href="#machineinstr">MachineInstr</a></tt> instances). It roughly
+ corresponds to the LLVM code input to the instruction selector, but there can be
+ a one-to-many mapping (i.e. one LLVM basic block can map to multiple machine
+ basic blocks). The <tt>MachineBasicBlock</tt> class has a
+ "<tt>getBasicBlock</tt>" method, which returns the LLVM basic block that it
+ comes from.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="machinefunction">The <tt>MachineFunction</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>MachineFunction</tt> class contains a list of machine basic blocks
+ (<tt><a href="#machinebasicblock">MachineBasicBlock</a></tt> instances). It
+ corresponds one-to-one with the LLVM function input to the instruction selector.
+ In addition to a list of basic blocks, the <tt>MachineFunction</tt> contains a
+ a <tt>MachineConstantPool</tt>, a <tt>MachineFrameInfo</tt>, a
+ <tt>MachineFunctionInfo</tt>, and a <tt>MachineRegisterInfo</tt>. See
+ <tt>include/llvm/CodeGen/MachineFunction.h</tt> for more information.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="codegenalgs">Target-independent code generation algorithms</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section documents the phases described in the <a
+ href="#high-level-design">high-level design of the code generator</a>. It
+ explains how they work and some of the rationale behind their design.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="instselect">Instruction Selection</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Instruction Selection is the process of translating LLVM code presented to the
+ code generator into target-specific machine instructions. There are several
+ well-known ways to do this in the literature. LLVM uses a SelectionDAG based
+ instruction selector.
+ </p>
+
+ <p>Portions of the DAG instruction selector are generated from the target
+ description (<tt>*.td</tt>) files. Our goal is for the entire instruction
+ selector to be generated from these <tt>.td</tt> files, though currently
+ there are still things that require custom C++ code.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_intro">Introduction to SelectionDAGs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The SelectionDAG provides an abstraction for code representation in a way
+ that is amenable to instruction selection using automatic techniques
+ (e.g. dynamic-programming based optimal pattern matching selectors). It is also
+ well-suited to other phases of code generation; in particular,
+ instruction scheduling (SelectionDAG's are very close to scheduling DAGs
+ post-selection). Additionally, the SelectionDAG provides a host representation
+ where a large variety of very-low-level (but target-independent)
+ <a href="#selectiondag_optimize">optimizations</a> may be
+ performed; ones which require extensive information about the instructions
+ efficiently supported by the target.</p>
+
+ <p>The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
+ <tt>SDNode</tt> class. The primary payload of the <tt>SDNode</tt> is its
+ operation code (Opcode) that indicates what operation the node performs and
+ the operands to the operation.
+ The various operation node types are described at the top of the
+ <tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt> file.</p>
+
+ <p>Although most operations define a single value, each node in the graph may
+ define multiple values. For example, a combined div/rem operation will define
+ both the dividend and the remainder. Many other situations require multiple
+ values as well. Each node also has some number of operands, which are edges
+ to the node defining the used value. Because nodes may define multiple values,
+ edges are represented by instances of the <tt>SDValue</tt> class, which is
+ a <tt><SDNode, unsigned></tt> pair, indicating the node and result
+ value being used, respectively. Each value produced by an <tt>SDNode</tt> has
+ an associated <tt>MVT</tt> (Machine Value Type) indicating what the type of the
+ value is.</p>
+
+ <p>SelectionDAGs contain two different kinds of values: those that represent
+ data flow and those that represent control flow dependencies. Data values are
+ simple edges with an integer or floating point value type. Control edges are
+ represented as "chain" edges which are of type <tt>MVT::Other</tt>. These edges
+ provide an ordering between nodes that have side effects (such as
+ loads, stores, calls, returns, etc). All nodes that have side effects should
+ take a token chain as input and produce a new one as output. By convention,
+ token chain inputs are always operand #0, and chain results are always the last
+ value produced by an operation.</p>
+
+ <p>A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
+ always a marker node with an Opcode of <tt>ISD::EntryToken</tt>. The Root node
+ is the final side-effecting node in the token chain. For example, in a single
+ basic block function it would be the return node.</p>
+
+ <p>One important concept for SelectionDAGs is the notion of a "legal" vs.
+ "illegal" DAG. A legal DAG for a target is one that only uses supported
+ operations and supported types. On a 32-bit PowerPC, for example, a DAG with
+ a value of type i1, i8, i16, or i64 would be illegal, as would a DAG that uses a
+ SREM or UREM operation. The
+ <a href="#selectinodag_legalize_types">legalize types</a> and
+ <a href="#selectiondag_legalize">legalize operations</a> phases are
+ responsible for turning an illegal DAG into a legal DAG.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_process">SelectionDAG Instruction Selection Process</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>SelectionDAG-based instruction selection consists of the following steps:</p>
+
+ <ol>
+ <li><a href="#selectiondag_build">Build initial DAG</a> - This stage
+ performs a simple translation from the input LLVM code to an illegal
+ SelectionDAG.</li>
+ <li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> - This stage
+ performs simple optimizations on the SelectionDAG to simplify it, and
+ recognize meta instructions (like rotates and <tt>div</tt>/<tt>rem</tt>
+ pairs) for targets that support these meta operations. This makes the
+ resultant code more efficient and the <a href="#selectiondag_select">select
+ instructions from DAG</a> phase (below) simpler.</li>
+ <li><a href="#selectiondag_legalize_types">Legalize SelectionDAG Types</a> - This
+ stage transforms SelectionDAG nodes to eliminate any types that are
+ unsupported on the target.</li>
+ <li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> - The
+ SelectionDAG optimizer is run to clean up redundancies exposed
+ by type legalization.</li>
+ <li><a href="#selectiondag_legalize">Legalize SelectionDAG Types</a> - This
+ stage transforms SelectionDAG nodes to eliminate any types that are
+ unsupported on the target.</li>
+ <li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> - The
+ SelectionDAG optimizer is run to eliminate inefficiencies introduced
+ by operation legalization.</li>
+ <li><a href="#selectiondag_select">Select instructions from DAG</a> - Finally,
+ the target instruction selector matches the DAG operations to target
+ instructions. This process translates the target-independent input DAG into
+ another DAG of target instructions.</li>
+ <li><a href="#selectiondag_sched">SelectionDAG Scheduling and Formation</a>
+ - The last phase assigns a linear order to the instructions in the
+ target-instruction DAG and emits them into the MachineFunction being
+ compiled. This step uses traditional prepass scheduling techniques.</li>
+ </ol>
+
+ <p>After all of these steps are complete, the SelectionDAG is destroyed and the
+ rest of the code generation passes are run.</p>
+
+ <p>One great way to visualize what is going on here is to take advantage of a
+ few LLC command line options. The following options pop up a window displaying
+ the SelectionDAG at specific times (if you only get errors printed to the console
+ while using this, you probably
+ <a href="ProgrammersManual.html#ViewGraph">need to configure your system</a> to
+ add support for it).</p>
+
+ <ul>
+ <li><tt>-view-dag-combine1-dags</tt> displays the DAG after being built, before
+ the first optimization pass.</li>
+ <li><tt>-view-legalize-dags</tt> displays the DAG before Legalization.</li>
+ <li><tt>-view-dag-combine2-dags</tt> displays the DAG before the second
+ optimization pass.</li>
+ <li><tt>-view-isel-dags</tt> displays the DAG before the Select phase.</li>
+ <li><tt>-view-sched-dags</tt> displays the DAG before Scheduling.</li>
+ </ul>
+
+ <p>The <tt>-view-sunit-dags</tt> displays the Scheduler's dependency graph.
+ This graph is based on the final SelectionDAG, with nodes that must be
+ scheduled together bundled into a single scheduling-unit node, and with
+ immediate operands and other nodes that aren't relevant for scheduling
+ omitted.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_build">Initial SelectionDAG Construction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The initial SelectionDAG is naïvely peephole expanded from the LLVM
+ input by the <tt>SelectionDAGLowering</tt> class in the
+ <tt>lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp</tt> file. The intent of this
+ pass is to expose as much low-level, target-specific details to the SelectionDAG
+ as possible. This pass is mostly hard-coded (e.g. an LLVM <tt>add</tt> turns
+ into an <tt>SDNode add</tt> while a <tt>getelementptr</tt> is expanded into the
+ obvious arithmetic). This pass requires target-specific hooks to lower calls,
+ returns, varargs, etc. For these features, the
+ <tt><a href="#targetlowering">TargetLowering</a></tt> interface is used.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The Legalize phase is in charge of converting a DAG to only use the types
+ that are natively supported by the target.</p>
+
+ <p>There are two main ways of converting values of unsupported scalar types
+ to values of supported types: converting small types to
+ larger types ("promoting"), and breaking up large integer types
+ into smaller ones ("expanding"). For example, a target might require
+ that all f32 values are promoted to f64 and that all i1/i8/i16 values
+ are promoted to i32. The same target might require that all i64 values
+ be expanded into pairs of i32 values. These changes can insert sign and
+ zero extensions as needed to make sure that the final code has the same
+ behavior as the input.</p>
+
+ <p>There are two main ways of converting values of unsupported vector types
+ to value of supported types: splitting vector types, multiple times if
+ necessary, until a legal type is found, and extending vector types by
+ adding elements to the end to round them out to legal types ("widening").
+ If a vector gets split all the way down to single-element parts with
+ no supported vector type being found, the elements are converted to
+ scalars ("scalarizing").</p>
+
+ <p>A target implementation tells the legalizer which types are supported
+ (and which register class to use for them) by calling the
+ <tt>addRegisterClass</tt> method in its TargetLowering constructor.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_legalize">SelectionDAG Legalize Phase</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The Legalize phase is in charge of converting a DAG to only use the
+ operations that are natively supported by the target.</p>
+
+ <p>Targets often have weird constraints, such as not supporting every
+ operation on every supported datatype (e.g. X86 does not support byte
+ conditional moves and PowerPC does not support sign-extending loads from
+ a 16-bit memory location). Legalize takes care of this by open-coding
+ another sequence of operations to emulate the operation ("expansion"), by
+ promoting one type to a larger type that supports the operation
+ ("promotion"), or by using a target-specific hook to implement the
+ legalization ("custom").</p>
+
+ <p>A target implementation tells the legalizer which operations are not
+ supported (and which of the above three actions to take) by calling the
+ <tt>setOperationAction</tt> method in its <tt>TargetLowering</tt>
+ constructor.</p>
+
+ <p>Prior to the existence of the Legalize passes, we required that every target
+ <a href="#selectiondag_optimize">selector</a> supported and handled every
+ operator and type even if they are not natively supported. The introduction of
+ the Legalize phases allows all of the canonicalization patterns to be shared
+ across targets, and makes it very easy to optimize the canonicalized code
+ because it is still in the form of a DAG.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_optimize">SelectionDAG Optimization Phase: the DAG
+ Combiner</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The SelectionDAG optimization phase is run multiple times for code generation,
+ immediately after the DAG is built and once after each legalization. The first
+ run of the pass allows the initial code to be cleaned up (e.g. performing
+ optimizations that depend on knowing that the operators have restricted type
+ inputs). Subsequent runs of the pass clean up the messy code generated by the
+ Legalize passes, which allows Legalize to be very simple (it can focus on making
+ code legal instead of focusing on generating <em>good</em> and legal code).</p>
+
+ <p>One important class of optimizations performed is optimizing inserted sign
+ and zero extension instructions. We currently use ad-hoc techniques, but could
+ move to more rigorous techniques in the future. Here are some good papers on
+ the subject:</p>
+
+ <p>
+ "<a href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening
+ integer arithmetic</a>"<br>
+ Kevin Redwine and Norman Ramsey<br>
+ International Conference on Compiler Construction (CC) 2004
+ </p>
+
+
+ <p>
+ "<a href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective
+ sign extension elimination</a>"<br>
+ Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani<br>
+ Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
+ and Implementation.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_select">SelectionDAG Select Phase</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The Select phase is the bulk of the target-specific code for instruction
+ selection. This phase takes a legal SelectionDAG as input, pattern matches the
+ instructions supported by the target to this DAG, and produces a new DAG of
+ target code. For example, consider the following LLVM fragment:</p>
+
+ <div class="doc_code">
+ <pre>
+ %t1 = add float %W, %X
+ %t2 = mul float %t1, %Y
+ %t3 = add float %t2, %Z
+ </pre>
+ </div>
+
+ <p>This LLVM code corresponds to a SelectionDAG that looks basically like
+ this:</p>
+
+ <div class="doc_code">
+ <pre>
+ (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
+ </pre>
+ </div>
+
+ <p>If a target supports floating point multiply-and-add (FMA) operations, one
+ of the adds can be merged with the multiply. On the PowerPC, for example, the
+ output of the instruction selector might look like this DAG:</p>
+
+ <div class="doc_code">
+ <pre>
+ (FMADDS (FADDS W, X), Y, Z)
+ </pre>
+ </div>
+
+ <p>The <tt>FMADDS</tt> instruction is a ternary instruction that multiplies its
+ first two operands and adds the third (as single-precision floating-point
+ numbers). The <tt>FADDS</tt> instruction is a simple binary single-precision
+ add instruction. To perform this pattern match, the PowerPC backend includes
+ the following instruction definitions:</p>
+
+ <div class="doc_code">
+ <pre>
+ def FMADDS : AForm_1<59, 29,
+ (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
+ "fmadds $FRT, $FRA, $FRC, $FRB",
+ [<b>(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
+ F4RC:$FRB))</b>]>;
+ def FADDS : AForm_2<59, 21,
+ (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
+ "fadds $FRT, $FRA, $FRB",
+ [<b>(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))</b>]>;
+ </pre>
+ </div>
+
+ <p>The portion of the instruction definition in bold indicates the pattern used
+ to match the instruction. The DAG operators (like <tt>fmul</tt>/<tt>fadd</tt>)
+ are defined in the <tt>lib/Target/TargetSelectionDAG.td</tt> file.
+ "<tt>F4RC</tt>" is the register class of the input and result values.</p>
+
+ <p>The TableGen DAG instruction selector generator reads the instruction
+ patterns in the <tt>.td</tt> file and automatically builds parts of the pattern
+ matching code for your target. It has the following strengths:</p>
+
+ <ul>
+ <li>At compiler-compiler time, it analyzes your instruction patterns and tells
+ you if your patterns make sense or not.</li>
+ <li>It can handle arbitrary constraints on operands for the pattern match. In
+ particular, it is straight-forward to say things like "match any immediate
+ that is a 13-bit sign-extended value". For examples, see the
+ <tt>immSExt16</tt> and related <tt>tblgen</tt> classes in the PowerPC
+ backend.</li>
+ <li>It knows several important identities for the patterns defined. For
+ example, it knows that addition is commutative, so it allows the
+ <tt>FMADDS</tt> pattern above to match "<tt>(fadd X, (fmul Y, Z))</tt>" as
+ well as "<tt>(fadd (fmul X, Y), Z)</tt>", without the target author having
+ to specially handle this case.</li>
+ <li>It has a full-featured type-inferencing system. In particular, you should
+ rarely have to explicitly tell the system what type parts of your patterns
+ are. In the <tt>FMADDS</tt> case above, we didn't have to tell
+ <tt>tblgen</tt> that all of the nodes in the pattern are of type 'f32'. It
+ was able to infer and propagate this knowledge from the fact that
+ <tt>F4RC</tt> has type 'f32'.</li>
+ <li>Targets can define their own (and rely on built-in) "pattern fragments".
+ Pattern fragments are chunks of reusable patterns that get inlined into your
+ patterns during compiler-compiler time. For example, the integer
+ "<tt>(not x)</tt>" operation is actually defined as a pattern fragment that
+ expands as "<tt>(xor x, -1)</tt>", since the SelectionDAG does not have a
+ native '<tt>not</tt>' operation. Targets can define their own short-hand
+ fragments as they see fit. See the definition of '<tt>not</tt>' and
+ '<tt>ineg</tt>' for examples.</li>
+ <li>In addition to instructions, targets can specify arbitrary patterns that
+ map to one or more instructions using the 'Pat' class. For example,
+ the PowerPC has no way to load an arbitrary integer immediate into a
+ register in one instruction. To tell tblgen how to do this, it defines:
+ <br>
+ <br>
+ <div class="doc_code">
+ <pre>
+ // Arbitrary immediate support. Implement in terms of LIS/ORI.
+ def : Pat<(i32 imm:$imm),
+ (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
+ </pre>
+ </div>
+ <br>
+ If none of the single-instruction patterns for loading an immediate into a
+ register match, this will be used. This rule says "match an arbitrary i32
+ immediate, turning it into an <tt>ORI</tt> ('or a 16-bit immediate') and an
+ <tt>LIS</tt> ('load 16-bit immediate, where the immediate is shifted to the
+ left 16 bits') instruction". To make this work, the
+ <tt>LO16</tt>/<tt>HI16</tt> node transformations are used to manipulate the
+ input immediate (in this case, take the high or low 16-bits of the
+ immediate).</li>
+ <li>While the system does automate a lot, it still allows you to write custom
+ C++ code to match special cases if there is something that is hard to
+ express.</li>
+ </ul>
+
+ <p>While it has many strengths, the system currently has some limitations,
+ primarily because it is a work in progress and is not yet finished:</p>
+
+ <ul>
+ <li>Overall, there is no way to define or match SelectionDAG nodes that define
+ multiple values (e.g. <tt>ADD_PARTS</tt>, <tt>LOAD</tt>, <tt>CALL</tt>,
+ etc). This is the biggest reason that you currently still <em>have to</em>
+ write custom C++ code for your instruction selector.</li>
+ <li>There is no great way to support matching complex addressing modes yet. In
+ the future, we will extend pattern fragments to allow them to define
+ multiple values (e.g. the four operands of the <a href="#x86_memory">X86
+ addressing mode</a>, which are currently matched with custom C++ code).
+ In addition, we'll extend fragments so that a
+ fragment can match multiple different patterns.</li>
+ <li>We don't automatically infer flags like isStore/isLoad yet.</li>
+ <li>We don't automatically generate the set of supported registers and
+ operations for the <a href="#selectiondag_legalize">Legalizer</a> yet.</li>
+ <li>We don't have a way of tying in custom legalized nodes yet.</li>
+ </ul>
+
+ <p>Despite these limitations, the instruction selector generator is still quite
+ useful for most of the binary and logical operations in typical instruction
+ sets. If you run into any problems or can't figure out how to do something,
+ please let Chris know!</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_sched">SelectionDAG Scheduling and Formation Phase</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The scheduling phase takes the DAG of target instructions from the selection
+ phase and assigns an order. The scheduler can pick an order depending on
+ various constraints of the machines (i.e. order for minimal register pressure or
+ try to cover instruction latencies). Once an order is established, the DAG is
+ converted to a list of <tt><a href="#machineinstr">MachineInstr</a></tt>s and
+ the SelectionDAG is destroyed.</p>
+
+ <p>Note that this phase is logically separate from the instruction selection
+ phase, but is tied to it closely in the code because it operates on
+ SelectionDAGs.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="selectiondag_future">Future directions for the SelectionDAG</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ol>
+ <li>Optional function-at-a-time selection.</li>
+ <li>Auto-generate entire selector from <tt>.td</tt> file.</li>
+ </ol>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ssamco">SSA-based Machine Code Optimizations</a>
+ </div>
+ <div class="doc_text"><p>To Be Written</p></div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="liveintervals">Live Intervals</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Live Intervals are the ranges (intervals) where a variable is <i>live</i>.
+ They are used by some <a href="#regalloc">register allocator</a> passes to
+ determine if two or more virtual registers which require the same physical
+ register are live at the same point in the program (i.e., they conflict). When
+ this situation occurs, one virtual register must be <i>spilled</i>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="livevariable_analysis">Live Variable Analysis</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The first step in determining the live intervals of variables is to
+ calculate the set of registers that are immediately dead after the
+ instruction (i.e., the instruction calculates the value, but it is
+ never used) and the set of registers that are used by the instruction,
+ but are never used after the instruction (i.e., they are killed). Live
+ variable information is computed for each <i>virtual</i> register and
+ <i>register allocatable</i> physical register in the function. This
+ is done in a very efficient manner because it uses SSA to sparsely
+ compute lifetime information for virtual registers (which are in SSA
+ form) and only has to track physical registers within a block. Before
+ register allocation, LLVM can assume that physical registers are only
+ live within a single basic block. This allows it to do a single,
+ local analysis to resolve physical register lifetimes within each
+ basic block. If a physical register is not register allocatable (e.g.,
+ a stack pointer or condition codes), it is not tracked.</p>
+
+ <p>Physical registers may be live in to or out of a function. Live in values
+ are typically arguments in registers. Live out values are typically return
+ values in registers. Live in values are marked as such, and are given a dummy
+ "defining" instruction during live intervals analysis. If the last basic block
+ of a function is a <tt>return</tt>, then it's marked as using all live out
+ values in the function.</p>
+
+ <p><tt>PHI</tt> nodes need to be handled specially, because the calculation
+ of the live variable information from a depth first traversal of the CFG of
+ the function won't guarantee that a virtual register used by the <tt>PHI</tt>
+ node is defined before it's used. When a <tt>PHI</tt> node is encountered, only
+ the definition is handled, because the uses will be handled in other basic
+ blocks.</p>
+
+ <p>For each <tt>PHI</tt> node of the current basic block, we simulate an
+ assignment at the end of the current basic block and traverse the successor
+ basic blocks. If a successor basic block has a <tt>PHI</tt> node and one of
+ the <tt>PHI</tt> node's operands is coming from the current basic block,
+ then the variable is marked as <i>alive</i> within the current basic block
+ and all of its predecessor basic blocks, until the basic block with the
+ defining instruction is encountered.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="liveintervals_analysis">Live Intervals Analysis</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>We now have the information available to perform the live intervals analysis
+ and build the live intervals themselves. We start off by numbering the basic
+ blocks and machine instructions. We then handle the "live-in" values. These
+ are in physical registers, so the physical register is assumed to be killed by
+ the end of the basic block. Live intervals for virtual registers are computed
+ for some ordering of the machine instructions <tt>[1, N]</tt>. A live interval
+ is an interval <tt>[i, j)</tt>, where <tt>1 <= i <= j < N</tt>, for which a
+ variable is live.</p>
+
+ <p><i><b>More to come...</b></i></p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="regalloc">Register Allocation</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <i>Register Allocation problem</i> consists in mapping a program
+ <i>P<sub>v</sub></i>, that can use an unbounded number of virtual
+ registers, to a program <i>P<sub>p</sub></i> that contains a finite
+ (possibly small) number of physical registers. Each target architecture has
+ a different number of physical registers. If the number of physical
+ registers is not enough to accommodate all the virtual registers, some of
+ them will have to be mapped into memory. These virtuals are called
+ <i>spilled virtuals</i>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_subsubsection">
+ <a name="regAlloc_represent">How registers are represented in LLVM</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In LLVM, physical registers are denoted by integer numbers that
+ normally range from 1 to 1023. To see how this numbering is defined
+ for a particular architecture, you can read the
+ <tt>GenRegisterNames.inc</tt> file for that architecture. For
+ instance, by inspecting
+ <tt>lib/Target/X86/X86GenRegisterNames.inc</tt> we see that the 32-bit
+ register <tt>EAX</tt> is denoted by 15, and the MMX register
+ <tt>MM0</tt> is mapped to 48.</p>
+
+ <p>Some architectures contain registers that share the same physical
+ location. A notable example is the X86 platform. For instance, in the
+ X86 architecture, the registers <tt>EAX</tt>, <tt>AX</tt> and
+ <tt>AL</tt> share the first eight bits. These physical registers are
+ marked as <i>aliased</i> in LLVM. Given a particular architecture, you
+ can check which registers are aliased by inspecting its
+ <tt>RegisterInfo.td</tt> file. Moreover, the method
+ <tt>TargetRegisterInfo::getAliasSet(p_reg)</tt> returns an array containing
+ all the physical registers aliased to the register <tt>p_reg</tt>.</p>
+
+ <p>Physical registers, in LLVM, are grouped in <i>Register Classes</i>.
+ Elements in the same register class are functionally equivalent, and can
+ be interchangeably used. Each virtual register can only be mapped to
+ physical registers of a particular class. For instance, in the X86
+ architecture, some virtuals can only be allocated to 8 bit registers.
+ A register class is described by <tt>TargetRegisterClass</tt> objects.
+ To discover if a virtual register is compatible with a given physical,
+ this code can be used:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ bool RegMapping_Fer::compatible_class(MachineFunction &mf,
+ unsigned v_reg,
+ unsigned p_reg) {
+ assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
+ "Target register must be physical");
+ const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
+ return trc->contains(p_reg);
+ }
+ </pre>
+ </div>
+
+ <p>Sometimes, mostly for debugging purposes, it is useful to change
+ the number of physical registers available in the target
+ architecture. This must be done statically, inside the
+ <tt>TargetRegsterInfo.td</tt> file. Just <tt>grep</tt> for
+ <tt>RegisterClass</tt>, the last parameter of which is a list of
+ registers. Just commenting some out is one simple way to avoid them
+ being used. A more polite way is to explicitly exclude some registers
+ from the <i>allocation order</i>. See the definition of the
+ <tt>GR</tt> register class in
+ <tt>lib/Target/IA64/IA64RegisterInfo.td</tt> for an example of this
+ (e.g., <tt>numReservedRegs</tt> registers are hidden.)</p>
+
+ <p>Virtual registers are also denoted by integer numbers. Contrary to
+ physical registers, different virtual registers never share the same
+ number. The smallest virtual register is normally assigned the number
+ 1024. This may change, so, in order to know which is the first virtual
+ register, you should access
+ <tt>TargetRegisterInfo::FirstVirtualRegister</tt>. Any register whose
+ number is greater than or equal to
+ <tt>TargetRegisterInfo::FirstVirtualRegister</tt> is considered a virtual
+ register. Whereas physical registers are statically defined in a
+ <tt>TargetRegisterInfo.td</tt> file and cannot be created by the
+ application developer, that is not the case with virtual registers.
+ In order to create new virtual registers, use the method
+ <tt>MachineRegisterInfo::createVirtualRegister()</tt>. This method will return a
+ virtual register with the highest code.
+ </p>
+
+ <p>Before register allocation, the operands of an instruction are
+ mostly virtual registers, although physical registers may also be
+ used. In order to check if a given machine operand is a register, use
+ the boolean function <tt>MachineOperand::isRegister()</tt>. To obtain
+ the integer code of a register, use
+ <tt>MachineOperand::getReg()</tt>. An instruction may define or use a
+ register. For instance, <tt>ADD reg:1026 := reg:1025 reg:1024</tt>
+ defines the registers 1024, and uses registers 1025 and 1026. Given a
+ register operand, the method <tt>MachineOperand::isUse()</tt> informs
+ if that register is being used by the instruction. The method
+ <tt>MachineOperand::isDef()</tt> informs if that registers is being
+ defined.</p>
+
+ <p>We will call physical registers present in the LLVM bitcode before
+ register allocation <i>pre-colored registers</i>. Pre-colored
+ registers are used in many different situations, for instance, to pass
+ parameters of functions calls, and to store results of particular
+ instructions. There are two types of pre-colored registers: the ones
+ <i>implicitly</i> defined, and those <i>explicitly</i>
+ defined. Explicitly defined registers are normal operands, and can be
+ accessed with <tt>MachineInstr::getOperand(int)::getReg()</tt>. In
+ order to check which registers are implicitly defined by an
+ instruction, use the
+ <tt>TargetInstrInfo::get(opcode)::ImplicitDefs</tt>, where
+ <tt>opcode</tt> is the opcode of the target instruction. One important
+ difference between explicit and implicit physical registers is that
+ the latter are defined statically for each instruction, whereas the
+ former may vary depending on the program being compiled. For example,
+ an instruction that represents a function call will always implicitly
+ define or use the same set of physical registers. To read the
+ registers implicitly used by an instruction, use
+ <tt>TargetInstrInfo::get(opcode)::ImplicitUses</tt>. Pre-colored
+ registers impose constraints on any register allocation algorithm. The
+ register allocator must make sure that none of them is been
+ overwritten by the values of virtual registers while still alive.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_subsubsection">
+ <a name="regAlloc_howTo">Mapping virtual registers to physical registers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>There are two ways to map virtual registers to physical registers (or to
+ memory slots). The first way, that we will call <i>direct mapping</i>,
+ is based on the use of methods of the classes <tt>TargetRegisterInfo</tt>,
+ and <tt>MachineOperand</tt>. The second way, that we will call
+ <i>indirect mapping</i>, relies on the <tt>VirtRegMap</tt> class in
+ order to insert loads and stores sending and getting values to and from
+ memory.</p>
+
+ <p>The direct mapping provides more flexibility to the developer of
+ the register allocator; however, it is more error prone, and demands
+ more implementation work. Basically, the programmer will have to
+ specify where load and store instructions should be inserted in the
+ target function being compiled in order to get and store values in
+ memory. To assign a physical register to a virtual register present in
+ a given operand, use <tt>MachineOperand::setReg(p_reg)</tt>. To insert
+ a store instruction, use
+ <tt>TargetRegisterInfo::storeRegToStackSlot(...)</tt>, and to insert a load
+ instruction, use <tt>TargetRegisterInfo::loadRegFromStackSlot</tt>.</p>
+
+ <p>The indirect mapping shields the application developer from the
+ complexities of inserting load and store instructions. In order to map
+ a virtual register to a physical one, use
+ <tt>VirtRegMap::assignVirt2Phys(vreg, preg)</tt>. In order to map a
+ certain virtual register to memory, use
+ <tt>VirtRegMap::assignVirt2StackSlot(vreg)</tt>. This method will
+ return the stack slot where <tt>vreg</tt>'s value will be located. If
+ it is necessary to map another virtual register to the same stack
+ slot, use <tt>VirtRegMap::assignVirt2StackSlot(vreg,
+ stack_location)</tt>. One important point to consider when using the
+ indirect mapping, is that even if a virtual register is mapped to
+ memory, it still needs to be mapped to a physical register. This
+ physical register is the location where the virtual register is
+ supposed to be found before being stored or after being reloaded.</p>
+
+ <p>If the indirect strategy is used, after all the virtual registers
+ have been mapped to physical registers or stack slots, it is necessary
+ to use a spiller object to place load and store instructions in the
+ code. Every virtual that has been mapped to a stack slot will be
+ stored to memory after been defined and will be loaded before being
+ used. The implementation of the spiller tries to recycle load/store
+ instructions, avoiding unnecessary instructions. For an example of how
+ to invoke the spiller, see
+ <tt>RegAllocLinearScan::runOnMachineFunction</tt> in
+ <tt>lib/CodeGen/RegAllocLinearScan.cpp</tt>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="regAlloc_twoAddr">Handling two address instructions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>With very rare exceptions (e.g., function calls), the LLVM machine
+ code instructions are three address instructions. That is, each
+ instruction is expected to define at most one register, and to use at
+ most two registers. However, some architectures use two address
+ instructions. In this case, the defined register is also one of the
+ used register. For instance, an instruction such as <tt>ADD %EAX,
+ %EBX</tt>, in X86 is actually equivalent to <tt>%EAX = %EAX +
+ %EBX</tt>.</p>
+
+ <p>In order to produce correct code, LLVM must convert three address
+ instructions that represent two address instructions into true two
+ address instructions. LLVM provides the pass
+ <tt>TwoAddressInstructionPass</tt> for this specific purpose. It must
+ be run before register allocation takes place. After its execution,
+ the resulting code may no longer be in SSA form. This happens, for
+ instance, in situations where an instruction such as <tt>%a = ADD %b
+ %c</tt> is converted to two instructions such as:</p>
+
+ <div class="doc_code">
+ <pre>
+ %a = MOVE %b
+ %a = ADD %a %c
+ </pre>
+ </div>
+
+ <p>Notice that, internally, the second instruction is represented as
+ <tt>ADD %a[def/use] %c</tt>. I.e., the register operand <tt>%a</tt> is
+ both used and defined by the instruction.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="regAlloc_ssaDecon">The SSA deconstruction phase</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>An important transformation that happens during register allocation is called
+ the <i>SSA Deconstruction Phase</i>. The SSA form simplifies many
+ analyses that are performed on the control flow graph of
+ programs. However, traditional instruction sets do not implement
+ PHI instructions. Thus, in order to generate executable code, compilers
+ must replace PHI instructions with other instructions that preserve their
+ semantics.</p>
+
+ <p>There are many ways in which PHI instructions can safely be removed
+ from the target code. The most traditional PHI deconstruction
+ algorithm replaces PHI instructions with copy instructions. That is
+ the strategy adopted by LLVM. The SSA deconstruction algorithm is
+ implemented in <tt>lib/CodeGen/PHIElimination.cpp</tt>. In order to
+ invoke this pass, the identifier <tt>PHIEliminationID</tt> must be
+ marked as required in the code of the register allocator.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="regAlloc_fold">Instruction folding</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><i>Instruction folding</i> is an optimization performed during
+ register allocation that removes unnecessary copy instructions. For
+ instance, a sequence of instructions such as:</p>
+
+ <div class="doc_code">
+ <pre>
+ %EBX = LOAD %mem_address
+ %EAX = COPY %EBX
+ </pre>
+ </div>
+
+ <p>can be safely substituted by the single instruction:</p>
+
+ <div class="doc_code">
+ <pre>
+ %EAX = LOAD %mem_address
+ </pre>
+ </div>
+
+ <p>Instructions can be folded with the
+ <tt>TargetRegisterInfo::foldMemoryOperand(...)</tt> method. Care must be
+ taken when folding instructions; a folded instruction can be quite
+ different from the original instruction. See
+ <tt>LiveIntervals::addIntervalsForSpills</tt> in
+ <tt>lib/CodeGen/LiveIntervalAnalysis.cpp</tt> for an example of its use.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_subsubsection">
+ <a name="regAlloc_builtIn">Built in register allocators</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The LLVM infrastructure provides the application developer with
+ three different register allocators:</p>
+
+ <ul>
+ <li><i>Simple</i> - This is a very simple implementation that does
+ not keep values in registers across instructions. This register
+ allocator immediately spills every value right after it is
+ computed, and reloads all used operands from memory to temporary
+ registers before each instruction.</li>
+ <li><i>Local</i> - This register allocator is an improvement on the
+ <i>Simple</i> implementation. It allocates registers on a basic
+ block level, attempting to keep values in registers and reusing
+ registers as appropriate.</li>
+ <li><i>Linear Scan</i> - <i>The default allocator</i>. This is the
+ well-know linear scan register allocator. Whereas the
+ <i>Simple</i> and <i>Local</i> algorithms use a direct mapping
+ implementation technique, the <i>Linear Scan</i> implementation
+ uses a spiller in order to place load and stores.</li>
+ </ul>
+
+ <p>The type of register allocator used in <tt>llc</tt> can be chosen with the
+ command line option <tt>-regalloc=...</tt>:</p>
+
+ <div class="doc_code">
+ <pre>
+ $ llc -f -regalloc=simple file.bc -o sp.s;
+ $ llc -f -regalloc=local file.bc -o lc.s;
+ $ llc -f -regalloc=linearscan file.bc -o ln.s;
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="proepicode">Prolog/Epilog Code Insertion</a>
+ </div>
+ <div class="doc_text"><p>To Be Written</p></div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="latemco">Late Machine Code Optimizations</a>
+ </div>
+ <div class="doc_text"><p>To Be Written</p></div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="codeemit">Code Emission</a>
+ </div>
+ <div class="doc_text"><p>To Be Written</p></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="codeemit_asm">Generating Assembly Code</a>
+ </div>
+ <div class="doc_text"><p>To Be Written</p></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="codeemit_bin">Generating Binary Machine Code</a>
+ </div>
+
+ <div class="doc_text">
+ <p>For the JIT or <tt>.o</tt> file writer</p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="targetimpls">Target-specific Implementation Notes</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section of the document explains features or design decisions that
+ are specific to the code generator for a particular target.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="tailcallopt">Tail call optimization</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if:
+ <ul>
+ <li>Caller and callee have the calling convention <tt>fastcc</tt>.</li>
+ <li>The call is a tail call - in tail position (ret immediately follows call and ret uses value of call or is void).</li>
+ <li>Option <tt>-tailcallopt</tt> is enabled.</li>
+ <li>Platform specific constraints are met.</li>
+ </ul>
+ </p>
+
+ <p>x86/x86-64 constraints:
+ <ul>
+ <li>No variable argument lists are used.</li>
+ <li>On x86-64 when generating GOT/PIC code only module-local calls (visibility = hidden or protected) are supported.</li>
+ </ul>
+ </p>
+ <p>PowerPC constraints:
+ <ul>
+ <li>No variable argument lists are used.</li>
+ <li>No byval parameters are used.</li>
+ <li>On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected) are supported.</li>
+ </ul>
+ </p>
+ <p>Example:</p>
+ <p>Call as <tt>llc -tailcallopt test.ll</tt>.
+ <div class="doc_code">
+ <pre>
+ declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
+
+ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
+ %l1 = add i32 %in1, %in2
+ %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
+ ret i32 %tmp
+ }</pre>
+ </div>
+ </p>
+ <p>Implications of <tt>-tailcallopt</tt>:</p>
+ <p>To support tail call optimization in situations where the callee has more arguments than the caller a 'callee pops arguments' convention is used. This currently causes each <tt>fastcc</tt> call that is not tail call optimized (because one or more of above constraints are not met) to be followed by a readjustment of the stack. So performance might be worse in such cases.</p>
+ <p>On x86 and x86-64 one register is reserved for indirect tail calls (e.g via a function pointer). So there is one less register for integer argument passing. For x86 this means 2 registers (if <tt>inreg</tt> parameter attribute is used) and for x86-64 this means 5 register are used.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="x86">The X86 backend</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The X86 code generator lives in the <tt>lib/Target/X86</tt> directory. This
+ code generator is capable of targeting a variety of x86-32 and x86-64
+ processors, and includes support for ISA extensions such as MMX and SSE.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="x86_tt">X86 Target Triples supported</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The following are the known target triples that are supported by the X86
+ backend. This is not an exhaustive list, and it would be useful to add those
+ that people test.</p>
+
+ <ul>
+ <li><b>i686-pc-linux-gnu</b> - Linux</li>
+ <li><b>i386-unknown-freebsd5.3</b> - FreeBSD 5.3</li>
+ <li><b>i686-pc-cygwin</b> - Cygwin on Win32</li>
+ <li><b>i686-pc-mingw32</b> - MingW on Win32</li>
+ <li><b>i386-pc-mingw32msvc</b> - MingW crosscompiler on Linux</li>
+ <li><b>i686-apple-darwin*</b> - Apple Darwin on X86</li>
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="x86_cc">X86 Calling Conventions supported</a>
+ </div>
+
+
+ <div class="doc_text">
+
+ <p>The following target-specific calling conventions are known to backend:</p>
+
+ <ul>
+ <li><b>x86_StdCall</b> - stdcall calling convention seen on Microsoft Windows
+ platform (CC ID = 64).</li>
+ <li><b>x86_FastCall</b> - fastcall calling convention seen on Microsoft Windows
+ platform (CC ID = 65).</li>
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="x86_memory">Representing X86 addressing modes in MachineInstrs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The x86 has a very flexible way of accessing memory. It is capable of
+ forming memory addresses of the following expression directly in integer
+ instructions (which use ModR/M addressing):</p>
+
+ <div class="doc_code">
+ <pre>
+ Base + [1,2,4,8] * IndexReg + Disp32
+ </pre>
+ </div>
+
+ <p>In order to represent this, LLVM tracks no less than 4 operands for each
+ memory operand of this form. This means that the "load" form of '<tt>mov</tt>'
+ has the following <tt>MachineOperand</tt>s in this order:</p>
+
+ <pre>
+ Index: 0 | 1 2 3 4
+ Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement
+ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm
+ </pre>
+
+ <p>Stores, and all other instructions, treat the four memory operands in the
+ same way and in the same order.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="x86_memory">X86 address spaces supported</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>x86 has the ability to perform loads and stores to different address spaces
+ via the x86 segment registers. A segment override prefix byte on an instruction
+ causes the instruction's memory access to go to the specified segment. LLVM
+ address space 0 is the default address space, which includes the stack, and
+ any unqualified memory accesses in a program. Address spaces 1-255 are
+ currently reserved for user-defined code. The GS-segment is represented by
+ address space 256. Other x86 segments have yet to be allocated address space
+ numbers.
+
+ <p>Some operating systems use the GS-segment to implement TLS, so care should be
+ taken when reading and writing to address space 256 on these platforms.
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="x86_names">Instruction naming</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>An instruction name consists of the base name, a default operand size, and a
+ a character per operand with an optional special size. For example:</p>
+
+ <p>
+ <tt>ADD8rr</tt> -> add, 8-bit register, 8-bit register<br>
+ <tt>IMUL16rmi</tt> -> imul, 16-bit register, 16-bit memory, 16-bit immediate<br>
+ <tt>IMUL16rmi8</tt> -> imul, 16-bit register, 16-bit memory, 8-bit immediate<br>
+ <tt>MOVSX32rm16</tt> -> movsx, 32-bit register, 16-bit memory
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ppc">The PowerPC backend</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The PowerPC code generator lives in the lib/Target/PowerPC directory. The
+ code generation is retargetable to several variations or <i>subtargets</i> of
+ the PowerPC ISA; including ppc32, ppc64 and altivec.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ppc_abi">LLVM PowerPC ABI</a>
+ </div>
+
+ <div class="doc_text">
+ <p>LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC
+ relative (PIC) or static addressing for accessing global values, so no TOC (r2)
+ is used. Second, r31 is used as a frame pointer to allow dynamic growth of a
+ stack frame. LLVM takes advantage of having no TOC to provide space to save
+ the frame pointer in the PowerPC linkage area of the caller frame. Other
+ details of PowerPC ABI can be found at <a href=
+ "http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html"
+ >PowerPC ABI.</a> Note: This link describes the 32 bit ABI. The
+ 64 bit ABI is similar except space for GPRs are 8 bytes wide (not 4) and r13 is
+ reserved for system use.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ppc_frame">Frame Layout</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The size of a PowerPC frame is usually fixed for the duration of a
+ function’s invocation. Since the frame is fixed size, all references into
+ the frame can be accessed via fixed offsets from the stack pointer. The
+ exception to this is when dynamic alloca or variable sized arrays are present,
+ then a base pointer (r31) is used as a proxy for the stack pointer and stack
+ pointer is free to grow or shrink. A base pointer is also used if llvm-gcc is
+ not passed the -fomit-frame-pointer flag. The stack pointer is always aligned to
+ 16 bytes, so that space allocated for altivec vectors will be properly
+ aligned.</p>
+ <p>An invocation frame is laid out as follows (low memory at top);</p>
+ </div>
+
+ <div class="doc_text">
+ <table class="layout">
+ <tr>
+ <td>Linkage<br><br></td>
+ </tr>
+ <tr>
+ <td>Parameter area<br><br></td>
+ </tr>
+ <tr>
+ <td>Dynamic area<br><br></td>
+ </tr>
+ <tr>
+ <td>Locals area<br><br></td>
+ </tr>
+ <tr>
+ <td>Saved registers area<br><br></td>
+ </tr>
+ <tr style="border-style: none hidden none hidden;">
+ <td><br></td>
+ </tr>
+ <tr>
+ <td>Previous Frame<br><br></td>
+ </tr>
+ </table>
+ </div>
+
+ <div class="doc_text">
+ <p>The <i>linkage</i> area is used by a callee to save special registers prior
+ to allocating its own frame. Only three entries are relevant to LLVM. The
+ first entry is the previous stack pointer (sp), aka link. This allows probing
+ tools like gdb or exception handlers to quickly scan the frames in the stack. A
+ function epilog can also use the link to pop the frame from the stack. The
+ third entry in the linkage area is used to save the return address from the lr
+ register. Finally, as mentioned above, the last entry is used to save the
+ previous frame pointer (r31.) The entries in the linkage area are the size of a
+ GPR, thus the linkage area is 24 bytes long in 32 bit mode and 48 bytes in 64
+ bit mode.</p>
+ </div>
+
+ <div class="doc_text">
+ <p>32 bit linkage area</p>
+ <table class="layout">
+ <tr>
+ <td>0</td>
+ <td>Saved SP (r1)</td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>Saved CR</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>Saved LR</td>
+ </tr>
+ <tr>
+ <td>12</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>16</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>20</td>
+ <td>Saved FP (r31)</td>
+ </tr>
+ </table>
+ </div>
+
+ <div class="doc_text">
+ <p>64 bit linkage area</p>
+ <table class="layout">
+ <tr>
+ <td>0</td>
+ <td>Saved SP (r1)</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>Saved CR</td>
+ </tr>
+ <tr>
+ <td>16</td>
+ <td>Saved LR</td>
+ </tr>
+ <tr>
+ <td>24</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>32</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>40</td>
+ <td>Saved FP (r31)</td>
+ </tr>
+ </table>
+ </div>
+
+ <div class="doc_text">
+ <p>The <i>parameter area</i> is used to store arguments being passed to a callee
+ function. Following the PowerPC ABI, the first few arguments are actually
+ passed in registers, with the space in the parameter area unused. However, if
+ there are not enough registers or the callee is a thunk or vararg function,
+ these register arguments can be spilled into the parameter area. Thus, the
+ parameter area must be large enough to store all the parameters for the largest
+ call sequence made by the caller. The size must also be minimally large enough
+ to spill registers r3-r10. This allows callees blind to the call signature,
+ such as thunks and vararg functions, enough space to cache the argument
+ registers. Therefore, the parameter area is minimally 32 bytes (64 bytes in 64
+ bit mode.) Also note that since the parameter area is a fixed offset from the
+ top of the frame, that a callee can access its spilt arguments using fixed
+ offsets from the stack pointer (or base pointer.)</p>
+ </div>
+
+ <div class="doc_text">
+ <p>Combining the information about the linkage, parameter areas and alignment. A
+ stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit
+ mode.</p>
+ </div>
+
+ <div class="doc_text">
+ <p>The <i>dynamic area</i> starts out as size zero. If a function uses dynamic
+ alloca then space is added to the stack, the linkage and parameter areas are
+ shifted to top of stack, and the new space is available immediately below the
+ linkage and parameter areas. The cost of shifting the linkage and parameter
+ areas is minor since only the link value needs to be copied. The link value can
+ be easily fetched by adding the original frame size to the base pointer. Note
+ that allocations in the dynamic space need to observe 16 byte alignment.</p>
+ </div>
+
+ <div class="doc_text">
+ <p>The <i>locals area</i> is where the llvm compiler reserves space for local
+ variables.</p>
+ </div>
+
+ <div class="doc_text">
+ <p>The <i>saved registers area</i> is where the llvm compiler spills callee saved
+ registers on entry to the callee.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ppc_prolog">Prolog/Epilog</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The llvm prolog and epilog are the same as described in the PowerPC ABI, with
+ the following exceptions. Callee saved registers are spilled after the frame is
+ created. This allows the llvm epilog/prolog support to be common with other
+ targets. The base pointer callee saved register r31 is saved in the TOC slot of
+ linkage area. This simplifies allocation of space for the base pointer and
+ makes it convenient to locate programatically and during debugging.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ppc_dynamic">Dynamic Allocation</a>
+ </div>
+
+ <div class="doc_text">
+ <p></p>
+ </div>
+
+ <div class="doc_text">
+ <p><i>TODO - More to come.</i></p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CodingStandards.html
diff -c /dev/null llvm-www/releases/2.5/docs/CodingStandards.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CodingStandards.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,810 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <title>LLVM Coding Standards</title>
+ </head>
+ <body>
+
+ <div class="doc_title">
+ LLVM Coding Standards
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#mechanicalissues">Mechanical Source Issues</a>
+ <ol>
+ <li><a href="#sourceformating">Source Code Formatting</a>
+ <ol>
+ <li><a href="#scf_commenting">Commenting</a></li>
+ <li><a href="#scf_commentformat">Comment Formatting</a></li>
+ <li><a href="#scf_includes"><tt>#include</tt> Style</a></li>
+ <li><a href="#scf_codewidth">Source Code Width</a></li>
+ <li><a href="#scf_spacestabs">Use Spaces Instead of Tabs</a></li>
+ <li><a href="#scf_indentation">Indent Code Consistently</a></li>
+ </ol></li>
+ <li><a href="#compilerissues">Compiler Issues</a>
+ <ol>
+ <li><a href="#ci_warningerrors">Treat Compiler Warnings Like
+ Errors</a></li>
+ <li><a href="#ci_portable_code">Write Portable Code</a></li>
+ <li><a href="#ci_class_struct">Use of class/struct Keywords</a></li>
+ </ol></li>
+ </ol></li>
+ <li><a href="#styleissues">Style Issues</a>
+ <ol>
+ <li><a href="#macro">The High Level Issues</a>
+ <ol>
+ <li><a href="#hl_module">A Public Header File <b>is</b> a
+ Module</a></li>
+ <li><a href="#hl_dontinclude">#include as Little as Possible</a></li>
+ <li><a href="#hl_privateheaders">Keep "internal" Headers
+ Private</a></li>
+ <li><a href="#ll_iostream"><tt>#include <iostream></tt> is
+ <em>forbidden</em></a></li>
+ </ol></li>
+ <li><a href="#micro">The Low Level Issues</a>
+ <ol>
+ <li><a href="#ll_assert">Assert Liberally</a></li>
+ <li><a href="#ll_ns_std">Do not use 'using namespace std'</a></li>
+ <li><a href="#ll_virtual_anch">Provide a virtual method anchor for
+ classes in headers</a></li>
+ <li><a href="#ll_preincrement">Prefer Preincrement</a></li>
+ <li><a href="#ll_avoidendl">Avoid <tt>std::endl</tt></a></li>
+ </ol></li>
+ </ol></li>
+ <li><a href="#seealso">See Also</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and
+ <a href="mailto:void at nondot.org">Bill Wendling</a></p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document attempts to describe a few coding standards that are being used
+ in the LLVM source tree. Although no coding standards should be regarded as
+ absolute requirements to be followed in all instances, coding standards can be
+ useful.</p>
+
+ <p>This document intentionally does not prescribe fixed standards for religious
+ issues such as brace placement and space usage. For issues like this, follow
+ the golden rule:</p>
+
+ <blockquote>
+
+ <p><b><a name="goldenrule">If you are adding a significant body of source to a
+ project, feel free to use whatever style you are most comfortable with. If you
+ are extending, enhancing, or bug fixing already implemented code, use the style
+ that is already being used so that the source is uniform and easy to
+ follow.</a></b></p>
+
+ </blockquote>
+
+ <p>The ultimate goal of these guidelines is the increase readability and
+ maintainability of our common source base. If you have suggestions for topics to
+ be included, please mail them to <a
+ href="mailto:sabre at nondot.org">Chris</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="mechanicalissues">Mechanical Source Issues</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="sourceformating">Source Code Formatting</a>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="scf_commenting">Commenting</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Comments are one critical part of readability and maintainability. Everyone
+ knows they should comment, so should you. Although we all should probably
+ comment our code more than we do, there are a few very critical places that
+ documentation is very useful:</p>
+
+ <b>File Headers</b>
+
+ <p>Every source file should have a header on it that describes the basic
+ purpose of the file. If a file does not have a header, it should not be
+ checked into Subversion. Most source trees will probably have a standard
+ file header format. The standard format for the LLVM source tree looks like
+ this:</p>
+
+ <div class="doc_code">
+ <pre>
+ //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
+ //
+ // The LLVM Compiler Infrastructure
+ //
+ // This file is distributed under the University of Illinois Open Source
+ // License. See LICENSE.TXT for details.
+ //
+ //===----------------------------------------------------------------------===//
+ //
+ // This file contains the declaration of the Instruction class, which is the
+ // base class for all of the VM instructions.
+ //
+ //===----------------------------------------------------------------------===//
+ </pre>
+ </div>
+
+ <p>A few things to note about this particular format: The "<tt>-*- C++
+ -*-</tt>" string on the first line is there to tell Emacs that the source file
+ is a C++ file, not a C file (Emacs assumes .h files are C files by default).
+ Note that this tag is not necessary in .cpp files. The name of the file is also
+ on the first line, along with a very short description of the purpose of the
+ file. This is important when printing out code and flipping though lots of
+ pages.</p>
+
+ <p>The next section in the file is a concise note that defines the license
+ that the file is released under. This makes it perfectly clear what terms the
+ source code can be distributed under and should not be modified in any way.</p>
+
+ <p>The main body of the description does not have to be very long in most cases.
+ Here it's only two lines. If an algorithm is being implemented or something
+ tricky is going on, a reference to the paper where it is published should be
+ included, as well as any notes or "gotchas" in the code to watch out for.</p>
+
+ <b>Class overviews</b>
+
+ <p>Classes are one fundamental part of a good object oriented design. As such,
+ a class definition should have a comment block that explains what the class is
+ used for... if it's not obvious. If it's so completely obvious your grandma
+ could figure it out, it's probably safe to leave it out. Naming classes
+ something sane goes a long ways towards avoiding writing documentation.</p>
+
+
+ <b>Method information</b>
+
+ <p>Methods defined in a class (as well as any global functions) should also be
+ documented properly. A quick note about what it does any a description of the
+ borderline behaviour is all that is necessary here (unless something
+ particularly tricky or insideous is going on). The hope is that people can
+ figure out how to use your interfaces without reading the code itself... that is
+ the goal metric.</p>
+
+ <p>Good things to talk about here are what happens when something unexpected
+ happens: does the method return null? Abort? Format your hard disk?</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="scf_commentformat">Comment Formatting</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In general, prefer C++ style (<tt>//</tt>) comments. They take less space,
+ require less typing, don't have nesting problems, etc. There are a few cases
+ when it is useful to use C style (<tt>/* */</tt>) comments however:</p>
+
+ <ol>
+ <li>When writing a C code: Obviously if you are writing C code, use C style
+ comments.</li>
+ <li>When writing a header file that may be <tt>#include</tt>d by a C source
+ file.</li>
+ <li>When writing a source file that is used by a tool that only accepts C
+ style comments.</li>
+ </ol>
+
+ <p>To comment out a large block of code, use <tt>#if 0</tt> and <tt>#endif</tt>.
+ These nest properly and are better behaved in general than C style comments.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="scf_includes"><tt>#include</tt> Style</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Immediately after the <a href="#scf_commenting">header file comment</a> (and
+ include guards if working on a header file), the <a
+ href="#hl_dontinclude">minimal</a> list of <tt>#include</tt>s required by the
+ file should be listed. We prefer these <tt>#include</tt>s to be listed in this
+ order:</p>
+
+ <ol>
+ <li><a href="#mmheader">Main Module header</a></li>
+ <li><a href="#hl_privateheaders">Local/Private Headers</a></li>
+ <li><tt>llvm/*</tt></li>
+ <li><tt>llvm/Analysis/*</tt></li>
+ <li><tt>llvm/Assembly/*</tt></li>
+ <li><tt>llvm/Bytecode/*</tt></li>
+ <li><tt>llvm/CodeGen/*</tt></li>
+ <li>...</li>
+ <li><tt>Support/*</tt></li>
+ <li><tt>Config/*</tt></li>
+ <li>System <tt>#includes</tt></li>
+ </ol>
+
+ <p>... and each category should be sorted by name.</p>
+
+ <p><a name="mmheader">The "Main Module Header"</a> file applies to .cpp file
+ which implement an interface defined by a .h file. This <tt>#include</tt>
+ should always be included <b>first</b> regardless of where it lives on the file
+ system. By including a header file first in the .cpp files that implement the
+ interfaces, we ensure that the header does not have any hidden dependencies
+ which are not explicitly #included in the header, but should be. It is also a
+ form of documentation in the .cpp file to indicate where the interfaces it
+ implements are defined.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="scf_codewidth">Source Code Width</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Write your code to fit within 80 columns of text. This helps those of us who
+ like to print out code and look at your code in an xterm without resizing
+ it.</p>
+
+ <p>The longer answer is that there must be some limit to the width of the code
+ in order to reasonably allow developers to have multiple files side-by-side in
+ windows on a modest display. If you are going to pick a width limit, it is
+ somewhat arbitrary but you might as well pick something standard. Going with
+ 90 columns (for example) instead of 80 columns wouldn't add any significant
+ value and would be detrimental to printing out code. Also many other projects
+ have standardized on 80 columns, so some people have already configured their
+ editors for it (vs something else, like 90 columns).</p>
+
+ <p>This is one of many contentious issues in coding standards, but is not up
+ for debate.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="scf_spacestabs">Use Spaces Instead of Tabs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In all cases, prefer spaces to tabs in source files. People have different
+ prefered indentation levels, and different styles of indentation that they
+ like... this is fine. What isn't is that different editors/viewers expand tabs
+ out to different tab stops. This can cause your code to look completely
+ unreadable, and it is not worth dealing with.</p>
+
+ <p>As always, follow the <a href="#goldenrule">Golden Rule</a> above: follow the
+ style of existing code if your are modifying and extending it. If you like four
+ spaces of indentation, <b>DO NOT</b> do that in the middle of a chunk of code
+ with two spaces of indentation. Also, do not reindent a whole source file: it
+ makes for incredible diffs that are absolutely worthless.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="scf_indentation">Indent Code Consistently</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Okay, your first year of programming you were told that indentation is
+ important. If you didn't believe and internalize this then, now is the time.
+ Just do it.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="compilerissues">Compiler Issues</a>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ci_warningerrors">Treat Compiler Warnings Like Errors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If your code has compiler warnings in it, something is wrong: you aren't
+ casting values correctly, your have "questionable" constructs in your code, or
+ you are doing something legitimately wrong. Compiler warnings can cover up
+ legitimate errors in output and make dealing with a translation unit
+ difficult.</p>
+
+ <p>It is not possible to prevent all warnings from all compilers, nor is it
+ desirable. Instead, pick a standard compiler (like <tt>gcc</tt>) that provides
+ a good thorough set of warnings, and stick to them. At least in the case of
+ <tt>gcc</tt>, it is possible to work around any spurious errors by changing the
+ syntax of the code slightly. For example, an warning that annoys me occurs when
+ I write code like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ if (V = getValue()) {
+ ...
+ }
+ </pre>
+ </div>
+
+ <p><tt>gcc</tt> will warn me that I probably want to use the <tt>==</tt>
+ operator, and that I probably mistyped it. In most cases, I haven't, and I
+ really don't want the spurious errors. To fix this particular problem, I
+ rewrite the code like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ if ((V = getValue())) {
+ ...
+ }
+ </pre>
+ </div>
+
+ <p>...which shuts <tt>gcc</tt> up. Any <tt>gcc</tt> warning that annoys you can
+ be fixed by massaging the code appropriately.</p>
+
+ <p>These are the <tt>gcc</tt> warnings that I prefer to enable: <tt>-Wall
+ -Winline -W -Wwrite-strings -Wno-unused</tt></p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ci_portable_code">Write Portable Code</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In almost all cases, it is possible and within reason to write completely
+ portable code. If there are cases where it isn't possible to write portable
+ code, isolate it behind a well defined (and well documented) interface.</p>
+
+ <p>In practice, this means that you shouldn't assume much about the host
+ compiler, including its support for "high tech" features like partial
+ specialization of templates. In fact, Visual C++ 6 could be an important target
+ for our work in the future, and we don't want to have to rewrite all of our code
+ to support it.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ci_class_struct">Use of <tt>class</tt> and <tt>struct</tt> Keywords</a>
+ </div>
+ <div class="doc_text">
+
+ <p>In C++, the <tt>class</tt> and <tt>struct</tt> keywords can be used almost
+ interchangeably. The only difference is when they are used to declare a class:
+ <tt>class</tt> makes all members private by default while <tt>struct</tt> makes
+ all members public by default.</p>
+
+ <p>Unfortunately, not all compilers follow the rules and some will generate
+ different symbols based on whether <tt>class</tt> or <tt>struct</tt> was used to
+ declare the symbol. This can lead to problems at link time.</p>
+
+ <p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless
+ <b>all</b> members are public, in which case <tt>struct</tt> is allowed.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="styleissues">Style Issues</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="macro">The High Level Issues</a>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="hl_module">A Public Header File <b>is</b> a Module</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>C++ doesn't do too well in the modularity department. There is no real
+ encapsulation or data hiding (unless you use expensive protocol classes), but it
+ is what we have to work with. When you write a public header file (in the LLVM
+ source tree, they live in the top level "include" directory), you are defining a
+ module of functionality.</p>
+
+ <p>Ideally, modules should be completely independent of each other, and their
+ header files should only include the absolute minimum number of headers
+ possible. A module is not just a class, a function, or a namespace: <a
+ href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm">it's a collection
+ of these</a> that defines an interface. This interface may be several
+ functions, classes or data structures, but the important issue is how they work
+ together.</p>
+
+ <p>In general, a module should be implemented with one or more <tt>.cpp</tt>
+ files. Each of these <tt>.cpp</tt> files should include the header that defines
+ their interface first. This ensure that all of the dependences of the module
+ header have been properly added to the module header itself, and are not
+ implicit. System headers should be included after user headers for a
+ translation unit.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="hl_dontinclude"><tt>#include</tt> as Little as Possible</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include</tt> hurts compile time performance. Don't do it unless you
+ have to, especially in header files.</p>
+
+ <p>But wait, sometimes you need to have the definition of a class to use it, or
+ to inherit from it. In these cases go ahead and <tt>#include</tt> that header
+ file. Be aware however that there are many cases where you don't need to have
+ the full definition of a class. If you are using a pointer or reference to a
+ class, you don't need the header file. If you are simply returning a class
+ instance from a prototyped function or method, you don't need it. In fact, for
+ most cases, you simply don't need the definition of a class... and not
+ <tt>#include</tt>'ing speeds up compilation.</p>
+
+ <p>It is easy to try to go too overboard on this recommendation, however. You
+ <b>must</b> include all of the header files that you are using -- you can
+ include them either directly
+ or indirectly (through another header file). To make sure that you don't
+ accidently forget to include a header file in your module header, make sure to
+ include your module header <b>first</b> in the implementation file (as mentioned
+ above). This way there won't be any hidden dependencies that you'll find out
+ about later...</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="hl_privateheaders">Keep "internal" Headers Private</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Many modules have a complex implementation that causes them to use more than
+ one implementation (<tt>.cpp</tt>) file. It is often tempting to put the
+ internal communication interface (helper classes, extra functions, etc) in the
+ public module header file. Don't do this.</p>
+
+ <p>If you really need to do something like this, put a private header file in
+ the same directory as the source files, and include it locally. This ensures
+ that your private interface remains private and undisturbed by outsiders.</p>
+
+ <p>Note however, that it's okay to put extra implementation methods a public
+ class itself... just make them private (or protected), and all is well.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ll_iostream"><tt>#include <iostream></tt> is forbidden</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The use of <tt>#include <iostream></tt> in library files is
+ hereby <b><em>forbidden</em></b>. The primary reason for doing this is to
+ support clients using LLVM libraries as part of larger systems. In particular,
+ we statically link LLVM into some dynamic libraries. Even if LLVM isn't used,
+ the static c'tors are run whenever an application start up that uses the dynamic
+ library. There are two problems with this:</p>
+
+ <ol>
+ <li>The time to run the static c'tors impacts startup time of
+ applications—a critical time for GUI apps.</li>
+ <li>The static c'tors cause the app to pull many extra pages of memory off the
+ disk: both the code for the static c'tors in each <tt>.o</tt> file and the
+ small amount of data that gets touched. In addition, touched/dirty pages
+ put more pressure on the VM system on low-memory machines.</li>
+ </ol>
+
+ <p>Note that using the other stream headers (<tt><sstream></tt> for
+ example) is allowed normally, it is just <tt><iostream></tt> that is
+ causing problems.</p>
+
+ <table>
+ <tbody>
+ <tr>
+ <th>Old Way</th>
+ <th>New Way</th>
+ </tr>
+ <tr>
+ <td align="left"><pre>#include <iostream></pre></td>
+ <td align="left"><pre>#include "llvm/Support/Streams.h"</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>DEBUG(std::cerr << ...);
+ DEBUG(dump(std::cerr));</pre></td>
+ <td align="left"><pre>DOUT << ...;
+ DEBUG(dump(DOUT));</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>std::cerr << "Hello world\n";</pre></td>
+ <td align="left"><pre>llvm::cerr << "Hello world\n";</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>std::cout << "Hello world\n";</pre></td>
+ <td align="left"><pre>llvm::cout << "Hello world\n";</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>std::cin >> Var;</pre></td>
+ <td align="left"><pre>llvm::cin >> Var;</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>std::ostream</pre></td>
+ <td align="left"><pre>llvm::OStream</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>std::istream</pre></td>
+ <td align="left"><pre>llvm::IStream</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>std::stringstream</pre></td>
+ <td align="left"><pre>llvm::StringStream</pre></td>
+ </tr>
+ <tr>
+ <td align="left"><pre>void print(std::ostream &Out);
+ // ...
+ print(std::cerr);</pre></td>
+ <td align="left"><tt>void print(llvm::OStream Out);<sup><a href="#sn_1">1</a></sup><br>
+ // ...<br>
+ print(llvm::cerr);</tt>
+ </td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p><b>Notes:</b></p>
+
+ <div class="doc_notes">
+ <ol>
+ <li><a name="sn_1"><tt>llvm::OStream</tt></a> is a light-weight class so it
+ should never be passed by reference. This is important because in some
+ configurations, <tt>DOUT</tt> is an rvalue.</li>
+ </ol>
+ </div>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="micro">The Low Level Issues</a>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ll_assert">Assert Liberally</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Use the "<tt>assert</tt>" function to its fullest. Check all of your
+ preconditions and assumptions, you never know when a bug (not neccesarily even
+ yours) might be caught early by an assertion, which reduces debugging time
+ dramatically. The "<tt><cassert></tt>" header file is probably already
+ included by the header files you are using, so it doesn't cost anything to use
+ it.</p>
+
+ <p>To further assist with debugging, make sure to put some kind of error message
+ in the assertion statement (which is printed if the assertion is tripped). This
+ helps the poor debugging make sense of why an assertion is being made and
+ enforced, and hopefully what to do about it. Here is one complete example:</p>
+
+ <div class="doc_code">
+ <pre>
+ inline Value *getOperand(unsigned i) {
+ assert(i < Operands.size() && "getOperand() out of range!");
+ return Operands[i];
+ }
+ </pre>
+ </div>
+
+ <p>Here are some examples:</p>
+
+ <div class="doc_code">
+ <pre>
+ assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+
+ assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
+
+ assert(idx < getNumSuccessors() && "Successor # out of range!");
+
+ assert(V1.getType() == V2.getType() && "Constant types must be identical!");
+
+ assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+ </pre>
+ </div>
+
+ <p>You get the idea...</p>
+
+ <p>Please be aware when adding assert statements that not all compilers are aware of
+ the semantics of the assert. In some places, asserts are used to indicate a piece of
+ code that should not be reached. These are typically of the form:</p>
+
+ <div class="doc_code">
+ <pre>
+ assert(0 && "Some helpful error message");
+ </pre>
+ </div>
+
+ <p>When used in a function that returns a value, they should be followed with a return
+ statement and a comment indicating that this line is never reached. This will prevent
+ a compiler which is unable to deduce that the assert statement never returns from
+ generating a warning.</p>
+
+ <div class="doc_code">
+ <pre>
+ assert(0 && "Some helpful error message");
+ // Not reached
+ return 0;
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ll_ns_std">Do not use '<tt>using namespace std</tt>'</a>
+ </div>
+
+ <div class="doc_text">
+ <p>In LLVM, we prefer to explicitly prefix all identifiers from the standard
+ namespace with an "<tt>std::</tt>" prefix, rather than rely on
+ "<tt>using namespace std;</tt>".</p>
+
+ <p> In header files, adding a '<tt>using namespace XXX</tt>' directive pollutes
+ the namespace of any source file that <tt>#include</tt>s the header. This is
+ clearly a bad thing.</p>
+
+ <p>In implementation files (e.g. .cpp files), the rule is more of a stylistic
+ rule, but is still important. Basically, using explicit namespace prefixes
+ makes the code <b>clearer</b>, because it is immediately obvious what facilities
+ are being used and where they are coming from, and <b>more portable</b>, because
+ namespace clashes cannot occur between LLVM code and other namespaces. The
+ portability rule is important because different standard library implementations
+ expose different symbols (potentially ones they shouldn't), and future revisions
+ to the C++ standard will add more symbols to the <tt>std</tt> namespace. As
+ such, we never use '<tt>using namespace std;</tt>' in LLVM.</p>
+
+ <p>The exception to the general rule (i.e. it's not an exception for
+ the <tt>std</tt> namespace) is for implementation files. For example, all of
+ the code in the LLVM project implements code that lives in the 'llvm' namespace.
+ As such, it is ok, and actually clearer, for the .cpp files to have a '<tt>using
+ namespace llvm</tt>' directive at their top, after the <tt>#include</tt>s. The
+ general form of this rule is that any .cpp file that implements code in any
+ namespace may use that namespace (and its parents'), but should not use any
+ others.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ll_virtual_anch">Provide a virtual method anchor for classes
+ in headers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If a class is defined in a header file and has a v-table (either it has
+ virtual methods or it derives from classes with virtual methods), it must
+ always have at least one out-of-line virtual method in the class. Without
+ this, the compiler will copy the vtable and RTTI into every <tt>.o</tt> file
+ that <tt>#include</tt>s the header, bloating <tt>.o</tt> file sizes and
+ increasing link times.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ll_preincrement">Prefer Preincrement</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Hard fast rule: Preincrement (<tt>++X</tt>) may be no slower than
+ postincrement (<tt>X++</tt>) and could very well be a lot faster than it. Use
+ preincrementation whenever possible.</p>
+
+ <p>The semantics of postincrement include making a copy of the value being
+ incremented, returning it, and then preincrementing the "work value". For
+ primitive types, this isn't a big deal... but for iterators, it can be a huge
+ issue (for example, some iterators contains stack and set objects in them...
+ copying an iterator could invoke the copy ctor's of these as well). In general,
+ get in the habit of always using preincrement, and you won't have a problem.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ll_avoidendl">Avoid <tt>std::endl</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>std::endl</tt> modifier, when used with iostreams outputs a newline
+ to the output stream specified. In addition to doing this, however, it also
+ flushes the output stream. In other words, these are equivalent:</p>
+
+ <div class="doc_code">
+ <pre>
+ std::cout << std::endl;
+ std::cout << '\n' << std::flush;
+ </pre>
+ </div>
+
+ <p>Most of the time, you probably have no reason to flush the output stream, so
+ it's better to use a literal <tt>'\n'</tt>.</p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="seealso">See Also</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>A lot of these comments and recommendations have been culled for other
+ sources. Two particularly important books for our work are:</p>
+
+ <ol>
+
+ <li><a href="http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective
+ C++</a> by Scott Meyers. Also
+ interesting and useful are "More Effective C++" and "Effective STL" by the same
+ author.</li>
+
+ <li>Large-Scale C++ Software Design by John Lakos</li>
+
+ </ol>
+
+ <p>If you get some free time, and you haven't read them: do so, you might learn
+ something.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CommandLine.html
diff -c /dev/null llvm-www/releases/2.5/docs/CommandLine.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CommandLine.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1995 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>CommandLine 2.0 Library Manual</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ CommandLine 2.0 Library Manual
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+
+ <li><a href="#quickstart">Quick Start Guide</a>
+ <ol>
+ <li><a href="#bool">Boolean Arguments</a></li>
+ <li><a href="#alias">Argument Aliases</a></li>
+ <li><a href="#onealternative">Selecting an alternative from a
+ set of possibilities</a></li>
+ <li><a href="#namedalternatives">Named alternatives</a></li>
+ <li><a href="#list">Parsing a list of options</a></li>
+ <li><a href="#bits">Collecting options as a set of flags</a></li>
+ <li><a href="#description">Adding freeform text to help output</a></li>
+ </ol></li>
+
+ <li><a href="#referenceguide">Reference Guide</a>
+ <ol>
+ <li><a href="#positional">Positional Arguments</a>
+ <ul>
+ <li><a href="#--">Specifying positional options with hyphens</a></li>
+ <li><a href="#getPosition">Determining absolute position with
+ getPosition</a></li>
+ <li><a href="#cl::ConsumeAfter">The <tt>cl::ConsumeAfter</tt>
+ modifier</a></li>
+ </ul></li>
+
+ <li><a href="#storage">Internal vs External Storage</a></li>
+
+ <li><a href="#attributes">Option Attributes</a></li>
+
+ <li><a href="#modifiers">Option Modifiers</a>
+ <ul>
+ <li><a href="#hiding">Hiding an option from <tt>--help</tt>
+ output</a></li>
+ <li><a href="#numoccurrences">Controlling the number of occurrences
+ required and allowed</a></li>
+ <li><a href="#valrequired">Controlling whether or not a value must be
+ specified</a></li>
+ <li><a href="#formatting">Controlling other formatting options</a></li>
+ <li><a href="#misc">Miscellaneous option modifiers</a></li>
+ <li><a href="#response">Response files</a></li>
+ </ul></li>
+
+ <li><a href="#toplevel">Top-Level Classes and Functions</a>
+ <ul>
+ <li><a href="#cl::ParseCommandLineOptions">The
+ <tt>cl::ParseCommandLineOptions</tt> function</a></li>
+ <li><a href="#cl::ParseEnvironmentOptions">The
+ <tt>cl::ParseEnvironmentOptions</tt> function</a></li>
+ <li><a href="#cl::SetVersionPrinter">The <tt>cl::SetVersionPrinter</tt>
+ function</a></li>
+ <li><a href="#cl::opt">The <tt>cl::opt</tt> class</a></li>
+ <li><a href="#cl::list">The <tt>cl::list</tt> class</a></li>
+ <li><a href="#cl::bits">The <tt>cl::bits</tt> class</a></li>
+ <li><a href="#cl::alias">The <tt>cl::alias</tt> class</a></li>
+ <li><a href="#cl::extrahelp">The <tt>cl::extrahelp</tt> class</a></li>
+ </ul></li>
+
+ <li><a href="#builtinparsers">Builtin parsers</a>
+ <ul>
+ <li><a href="#genericparser">The Generic <tt>parser<t></tt>
+ parser</a></li>
+ <li><a href="#boolparser">The <tt>parser<bool></tt>
+ specialization</a></li>
+ <li><a href="#boolOrDefaultparser">The <tt>parser<boolOrDefault></tt>
+ specialization</a></li>
+ <li><a href="#stringparser">The <tt>parser<string></tt>
+ specialization</a></li>
+ <li><a href="#intparser">The <tt>parser<int></tt>
+ specialization</a></li>
+ <li><a href="#doubleparser">The <tt>parser<double></tt> and
+ <tt>parser<float></tt> specializations</a></li>
+ </ul></li>
+ </ol></li>
+ <li><a href="#extensionguide">Extension Guide</a>
+ <ol>
+ <li><a href="#customparser">Writing a custom parser</a></li>
+ <li><a href="#explotingexternal">Exploiting external storage</a></li>
+ <li><a href="#dynamicopts">Dynamically adding command line
+ options</a></li>
+ </ol></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document describes the CommandLine argument processing library. It will
+ show you how to use it, and what it can do. The CommandLine library uses a
+ declarative approach to specifying the command line options that your program
+ takes. By default, these options declarations implicitly hold the value parsed
+ for the option declared (of course this <a href="#storage">can be
+ changed</a>).</p>
+
+ <p>Although there are a <b>lot</b> of command line argument parsing libraries
+ out there in many different languages, none of them fit well with what I needed.
+ By looking at the features and problems of other libraries, I designed the
+ CommandLine library to have the following features:</p>
+
+ <ol>
+ <li>Speed: The CommandLine library is very quick and uses little resources. The
+ parsing time of the library is directly proportional to the number of arguments
+ parsed, not the the number of options recognized. Additionally, command line
+ argument values are captured transparently into user defined global variables,
+ which can be accessed like any other variable (and with the same
+ performance).</li>
+
+ <li>Type Safe: As a user of CommandLine, you don't have to worry about
+ remembering the type of arguments that you want (is it an int? a string? a
+ bool? an enum?) and keep casting it around. Not only does this help prevent
+ error prone constructs, it also leads to dramatically cleaner source code.</li>
+
+ <li>No subclasses required: To use CommandLine, you instantiate variables that
+ correspond to the arguments that you would like to capture, you don't subclass a
+ parser. This means that you don't have to write <b>any</b> boilerplate
+ code.</li>
+
+ <li>Globally accessible: Libraries can specify command line arguments that are
+ automatically enabled in any tool that links to the library. This is possible
+ because the application doesn't have to keep a list of arguments to pass to
+ the parser. This also makes supporting <a href="#dynamicopts">dynamically
+ loaded options</a> trivial.</li>
+
+ <li>Cleaner: CommandLine supports enum and other types directly, meaning that
+ there is less error and more security built into the library. You don't have to
+ worry about whether your integral command line argument accidentally got
+ assigned a value that is not valid for your enum type.</li>
+
+ <li>Powerful: The CommandLine library supports many different types of
+ arguments, from simple <a href="#boolparser">boolean flags</a> to <a
+ href="#cl::opt">scalars arguments</a> (<a href="#stringparser">strings</a>, <a
+ href="#intparser">integers</a>, <a href="#genericparser">enums</a>, <a
+ href="#doubleparser">doubles</a>), to <a href="#cl::list">lists of
+ arguments</a>. This is possible because CommandLine is...</li>
+
+ <li>Extensible: It is very simple to add a new argument type to CommandLine.
+ Simply specify the parser that you want to use with the command line option when
+ you declare it. <a href="#customparser">Custom parsers</a> are no problem.</li>
+
+ <li>Labor Saving: The CommandLine library cuts down on the amount of grunt work
+ that you, the user, have to do. For example, it automatically provides a
+ <tt>--help</tt> option that shows the available command line options for your
+ tool. Additionally, it does most of the basic correctness checking for
+ you.</li>
+
+ <li>Capable: The CommandLine library can handle lots of different forms of
+ options often found in real programs. For example, <a
+ href="#positional">positional</a> arguments, <tt>ls</tt> style <a
+ href="#cl::Grouping">grouping</a> options (to allow processing '<tt>ls
+ -lad</tt>' naturally), <tt>ld</tt> style <a href="#cl::Prefix">prefix</a>
+ options (to parse '<tt>-lmalloc -L/usr/lib</tt>'), and <a
+ href="#cl::ConsumeAfter">interpreter style options</a>.</li>
+
+ </ol>
+
+ <p>This document will hopefully let you jump in and start using CommandLine in
+ your utility quickly and painlessly. Additionally it should be a simple
+ reference manual to figure out how stuff works. If it is failing in some area
+ (or you want an extension to the library), nag the author, <a
+ href="mailto:sabre at nondot.org">Chris Lattner</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="quickstart">Quick Start Guide</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section of the manual runs through a simple CommandLine'ification of a
+ basic compiler tool. This is intended to show you how to jump into using the
+ CommandLine library in your own program, and show you some of the cool things it
+ can do.</p>
+
+ <p>To start out, you need to include the CommandLine header file into your
+ program:</p>
+
+ <div class="doc_code"><pre>
+ #include "llvm/Support/CommandLine.h"
+ </pre></div>
+
+ <p>Additionally, you need to add this as the first line of your main
+ program:</p>
+
+ <div class="doc_code"><pre>
+ int main(int argc, char **argv) {
+ <a href="#cl::ParseCommandLineOptions">cl::ParseCommandLineOptions</a>(argc, argv);
+ ...
+ }
+ </pre></div>
+
+ <p>... which actually parses the arguments and fills in the variable
+ declarations.</p>
+
+ <p>Now that you are ready to support command line arguments, we need to tell the
+ system which ones we want, and what type of arguments they are. The CommandLine
+ library uses a declarative syntax to model command line arguments with the
+ global variable declarations that capture the parsed values. This means that
+ for every command line option that you would like to support, there should be a
+ global variable declaration to capture the result. For example, in a compiler,
+ we would like to support the Unix-standard '<tt>-o <filename></tt>' option
+ to specify where to put the output. With the CommandLine library, this is
+ represented like this:</p>
+
+ <a name="value_desc_example"></a>
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><string> OutputFilename("<i>o</i>", <a href="#cl::desc">cl::desc</a>("<i>Specify output filename</i>"), <a href="#cl::value_desc">cl::value_desc</a>("<i>filename</i>"));
+ </pre></div>
+
+ <p>This declares a global variable "<tt>OutputFilename</tt>" that is used to
+ capture the result of the "<tt>o</tt>" argument (first parameter). We specify
+ that this is a simple scalar option by using the "<tt><a
+ href="#cl::opt">cl::opt</a></tt>" template (as opposed to the <a
+ href="#list">"<tt>cl::list</tt> template</a>), and tell the CommandLine library
+ that the data type that we are parsing is a string.</p>
+
+ <p>The second and third parameters (which are optional) are used to specify what
+ to output for the "<tt>--help</tt>" option. In this case, we get a line that
+ looks like this:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: compiler [options]
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ <b>-o <filename> - Specify output filename</b>
+ </pre></div>
+
+ <p>Because we specified that the command line option should parse using the
+ <tt>string</tt> data type, the variable declared is automatically usable as a
+ real string in all contexts that a normal C++ string object may be used. For
+ example:</p>
+
+ <div class="doc_code"><pre>
+ ...
+ std::ofstream Output(OutputFilename.c_str());
+ if (Output.good()) ...
+ ...
+ </pre></div>
+
+ <p>There are many different options that you can use to customize the command
+ line option handling library, but the above example shows the general interface
+ to these options. The options can be specified in any order, and are specified
+ with helper functions like <a href="#cl::desc"><tt>cl::desc(...)</tt></a>, so
+ there are no positional dependencies to remember. The available options are
+ discussed in detail in the <a href="#referenceguide">Reference Guide</a>.</p>
+
+ <p>Continuing the example, we would like to have our compiler take an input
+ filename as well as an output filename, but we do not want the input filename to
+ be specified with a hyphen (ie, not <tt>-filename.c</tt>). To support this
+ style of argument, the CommandLine library allows for <a
+ href="#positional">positional</a> arguments to be specified for the program.
+ These positional arguments are filled with command line parameters that are not
+ in option form. We use this feature like this:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><string> InputFilename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i><input file></i>"), <a href="#cl::init">cl::init</a>("<i>-</i>"));
+ </pre></div>
+
+ <p>This declaration indicates that the first positional argument should be
+ treated as the input filename. Here we use the <tt><a
+ href="#cl::init">cl::init</a></tt> option to specify an initial value for the
+ command line option, which is used if the option is not specified (if you do not
+ specify a <tt><a href="#cl::init">cl::init</a></tt> modifier for an option, then
+ the default constructor for the data type is used to initialize the value).
+ Command line options default to being optional, so if we would like to require
+ that the user always specify an input filename, we would add the <tt><a
+ href="#cl::Required">cl::Required</a></tt> flag, and we could eliminate the
+ <tt><a href="#cl::init">cl::init</a></tt> modifier, like this:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><string> InputFilename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i><input file></i>"), <b><a href="#cl::Required">cl::Required</a></b>);
+ </pre></div>
+
+ <p>Again, the CommandLine library does not require the options to be specified
+ in any particular order, so the above declaration is equivalent to:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><string> InputFilename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::Required">cl::Required</a>, <a href="#cl::desc">cl::desc</a>("<i><input file></i>"));
+ </pre></div>
+
+ <p>By simply adding the <tt><a href="#cl::Required">cl::Required</a></tt> flag,
+ the CommandLine library will automatically issue an error if the argument is not
+ specified, which shifts all of the command line option verification code out of
+ your application into the library. This is just one example of how using flags
+ can alter the default behaviour of the library, on a per-option basis. By
+ adding one of the declarations above, the <tt>--help</tt> option synopsis is now
+ extended to:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: compiler [options] <b><input file></b>
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ -o <filename> - Specify output filename
+ </pre></div>
+
+ <p>... indicating that an input filename is expected.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="bool">Boolean Arguments</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In addition to input and output filenames, we would like the compiler example
+ to support three boolean flags: "<tt>-f</tt>" to force overwriting of the output
+ file, "<tt>--quiet</tt>" to enable quiet mode, and "<tt>-q</tt>" for backwards
+ compatibility with some of our users. We can support these by declaring options
+ of boolean type like this:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><bool> Force ("<i>f</i>", <a href="#cl::desc">cl::desc</a>("<i>Overwrite output files</i>"));
+ <a href="#cl::opt">cl::opt</a><bool> Quiet ("<i>quiet</i>", <a href="#cl::desc">cl::desc</a>("<i>Don't print informational messages</i>"));
+ <a href="#cl::opt">cl::opt</a><bool> Quiet2("<i>q</i>", <a href="#cl::desc">cl::desc</a>("<i>Don't print informational messages</i>"), <a href="#cl::Hidden">cl::Hidden</a>);
+ </pre></div>
+
+ <p>This does what you would expect: it declares three boolean variables
+ ("<tt>Force</tt>", "<tt>Quiet</tt>", and "<tt>Quiet2</tt>") to recognize these
+ options. Note that the "<tt>-q</tt>" option is specified with the "<a
+ href="#cl::Hidden"><tt>cl::Hidden</tt></a>" flag. This modifier prevents it
+ from being shown by the standard "<tt>--help</tt>" output (note that it is still
+ shown in the "<tt>--help-hidden</tt>" output).</p>
+
+ <p>The CommandLine library uses a <a href="#builtinparsers">different parser</a>
+ for different data types. For example, in the string case, the argument passed
+ to the option is copied literally into the content of the string variable... we
+ obviously cannot do that in the boolean case, however, so we must use a smarter
+ parser. In the case of the boolean parser, it allows no options (in which case
+ it assigns the value of true to the variable), or it allows the values
+ "<tt>true</tt>" or "<tt>false</tt>" to be specified, allowing any of the
+ following inputs:</p>
+
+ <div class="doc_code"><pre>
+ compiler -f # No value, 'Force' == true
+ compiler -f=true # Value specified, 'Force' == true
+ compiler -f=TRUE # Value specified, 'Force' == true
+ compiler -f=FALSE # Value specified, 'Force' == false
+ </pre></div>
+
+ <p>... you get the idea. The <a href="#boolparser">bool parser</a> just turns
+ the string values into boolean values, and rejects things like '<tt>compiler
+ -f=foo</tt>'. Similarly, the <a href="#doubleparser">float</a>, <a
+ href="#doubleparser">double</a>, and <a href="#intparser">int</a> parsers work
+ like you would expect, using the '<tt>strtol</tt>' and '<tt>strtod</tt>' C
+ library calls to parse the string value into the specified data type.</p>
+
+ <p>With the declarations above, "<tt>compiler --help</tt>" emits this:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: compiler [options] <input file>
+
+ OPTIONS:
+ <b>-f - Overwrite output files</b>
+ -o - Override output filename
+ <b>-quiet - Don't print informational messages</b>
+ -help - display available options (--help-hidden for more)
+ </pre></div>
+
+ <p>and "<tt>compiler --help-hidden</tt>" prints this:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: compiler [options] <input file>
+
+ OPTIONS:
+ -f - Overwrite output files
+ -o - Override output filename
+ <b>-q - Don't print informational messages</b>
+ -quiet - Don't print informational messages
+ -help - display available options (--help-hidden for more)
+ </pre></div>
+
+ <p>This brief example has shown you how to use the '<tt><a
+ href="#cl::opt">cl::opt</a></tt>' class to parse simple scalar command line
+ arguments. In addition to simple scalar arguments, the CommandLine library also
+ provides primitives to support CommandLine option <a href="#alias">aliases</a>,
+ and <a href="#list">lists</a> of options.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="alias">Argument Aliases</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>So far, the example works well, except for the fact that we need to check the
+ quiet condition like this now:</p>
+
+ <div class="doc_code"><pre>
+ ...
+ if (!Quiet && !Quiet2) printInformationalMessage(...);
+ ...
+ </pre></div>
+
+ <p>... which is a real pain! Instead of defining two values for the same
+ condition, we can use the "<tt><a href="#cl::alias">cl::alias</a></tt>" class to make the "<tt>-q</tt>"
+ option an <b>alias</b> for the "<tt>-quiet</tt>" option, instead of providing
+ a value itself:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><bool> Force ("<i>f</i>", <a href="#cl::desc">cl::desc</a>("<i>Overwrite output files</i>"));
+ <a href="#cl::opt">cl::opt</a><bool> Quiet ("<i>quiet</i>", <a href="#cl::desc">cl::desc</a>("<i>Don't print informational messages</i>"));
+ <a href="#cl::alias">cl::alias</a> QuietA("<i>q</i>", <a href="#cl::desc">cl::desc</a>("<i>Alias for -quiet</i>"), <a href="#cl::aliasopt">cl::aliasopt</a>(Quiet));
+ </pre></div>
+
+ <p>The third line (which is the only one we modified from above) defines a
+ "<tt>-q</tt>" alias that updates the "<tt>Quiet</tt>" variable (as specified by
+ the <tt><a href="#cl::aliasopt">cl::aliasopt</a></tt> modifier) whenever it is
+ specified. Because aliases do not hold state, the only thing the program has to
+ query is the <tt>Quiet</tt> variable now. Another nice feature of aliases is
+ that they automatically hide themselves from the <tt>-help</tt> output
+ (although, again, they are still visible in the <tt>--help-hidden
+ output</tt>).</p>
+
+ <p>Now the application code can simply use:</p>
+
+ <div class="doc_code"><pre>
+ ...
+ if (!Quiet) printInformationalMessage(...);
+ ...
+ </pre></div>
+
+ <p>... which is much nicer! The "<tt><a href="#cl::alias">cl::alias</a></tt>"
+ can be used to specify an alternative name for any variable type, and has many
+ uses.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="onealternative">Selecting an alternative from a set of
+ possibilities</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>So far we have seen how the CommandLine library handles builtin types like
+ <tt>std::string</tt>, <tt>bool</tt> and <tt>int</tt>, but how does it handle
+ things it doesn't know about, like enums or '<tt>int*</tt>'s?</p>
+
+ <p>The answer is that it uses a table-driven generic parser (unless you specify
+ your own parser, as described in the <a href="#extensionguide">Extension
+ Guide</a>). This parser maps literal strings to whatever type is required, and
+ requires you to tell it what this mapping should be.</p>
+
+ <p>Let's say that we would like to add four optimization levels to our
+ optimizer, using the standard flags "<tt>-g</tt>", "<tt>-O0</tt>",
+ "<tt>-O1</tt>", and "<tt>-O2</tt>". We could easily implement this with boolean
+ options like above, but there are several problems with this strategy:</p>
+
+ <ol>
+ <li>A user could specify more than one of the options at a time, for example,
+ "<tt>compiler -O3 -O2</tt>". The CommandLine library would not be able to
+ catch this erroneous input for us.</li>
+
+ <li>We would have to test 4 different variables to see which ones are set.</li>
+
+ <li>This doesn't map to the numeric levels that we want... so we cannot easily
+ see if some level >= "<tt>-O1</tt>" is enabled.</li>
+
+ </ol>
+
+ <p>To cope with these problems, we can use an enum value, and have the
+ CommandLine library fill it in with the appropriate level directly, which is
+ used like this:</p>
+
+ <div class="doc_code"><pre>
+ enum OptLevel {
+ g, O1, O2, O3
+ };
+
+ <a href="#cl::opt">cl::opt</a><OptLevel> OptimizationLevel(<a href="#cl::desc">cl::desc</a>("<i>Choose optimization level:</i>"),
+ <a href="#cl::values">cl::values</a>(
+ clEnumVal(g , "<i>No optimizations, enable debugging</i>"),
+ clEnumVal(O1, "<i>Enable trivial optimizations</i>"),
+ clEnumVal(O2, "<i>Enable default optimizations</i>"),
+ clEnumVal(O3, "<i>Enable expensive optimizations</i>"),
+ clEnumValEnd));
+
+ ...
+ if (OptimizationLevel >= O2) doPartialRedundancyElimination(...);
+ ...
+ </pre></div>
+
+ <p>This declaration defines a variable "<tt>OptimizationLevel</tt>" of the
+ "<tt>OptLevel</tt>" enum type. This variable can be assigned any of the values
+ that are listed in the declaration (Note that the declaration list must be
+ terminated with the "<tt>clEnumValEnd</tt>" argument!). The CommandLine
+ library enforces
+ that the user can only specify one of the options, and it ensure that only valid
+ enum values can be specified. The "<tt>clEnumVal</tt>" macros ensure that the
+ command line arguments matched the enum values. With this option added, our
+ help output now is:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: compiler [options] <input file>
+
+ OPTIONS:
+ <b>Choose optimization level:
+ -g - No optimizations, enable debugging
+ -O1 - Enable trivial optimizations
+ -O2 - Enable default optimizations
+ -O3 - Enable expensive optimizations</b>
+ -f - Overwrite output files
+ -help - display available options (--help-hidden for more)
+ -o <filename> - Specify output filename
+ -quiet - Don't print informational messages
+ </pre></div>
+
+ <p>In this case, it is sort of awkward that flag names correspond directly to
+ enum names, because we probably don't want a enum definition named "<tt>g</tt>"
+ in our program. Because of this, we can alternatively write this example like
+ this:</p>
+
+ <div class="doc_code"><pre>
+ enum OptLevel {
+ Debug, O1, O2, O3
+ };
+
+ <a href="#cl::opt">cl::opt</a><OptLevel> OptimizationLevel(<a href="#cl::desc">cl::desc</a>("<i>Choose optimization level:</i>"),
+ <a href="#cl::values">cl::values</a>(
+ clEnumValN(Debug, "g", "<i>No optimizations, enable debugging</i>"),
+ clEnumVal(O1 , "<i>Enable trivial optimizations</i>"),
+ clEnumVal(O2 , "<i>Enable default optimizations</i>"),
+ clEnumVal(O3 , "<i>Enable expensive optimizations</i>"),
+ clEnumValEnd));
+
+ ...
+ if (OptimizationLevel == Debug) outputDebugInfo(...);
+ ...
+ </pre></div>
+
+ <p>By using the "<tt>clEnumValN</tt>" macro instead of "<tt>clEnumVal</tt>", we
+ can directly specify the name that the flag should get. In general a direct
+ mapping is nice, but sometimes you can't or don't want to preserve the mapping,
+ which is when you would use it.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="namedalternatives">Named Alternatives</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Another useful argument form is a named alternative style. We shall use this
+ style in our compiler to specify different debug levels that can be used.
+ Instead of each debug level being its own switch, we want to support the
+ following options, of which only one can be specified at a time:
+ "<tt>--debug-level=none</tt>", "<tt>--debug-level=quick</tt>",
+ "<tt>--debug-level=detailed</tt>". To do this, we use the exact same format as
+ our optimization level flags, but we also specify an option name. For this
+ case, the code looks like this:</p>
+
+ <div class="doc_code"><pre>
+ enum DebugLev {
+ nodebuginfo, quick, detailed
+ };
+
+ // Enable Debug Options to be specified on the command line
+ <a href="#cl::opt">cl::opt</a><DebugLev> DebugLevel("<i>debug_level</i>", <a href="#cl::desc">cl::desc</a>("<i>Set the debugging level:</i>"),
+ <a href="#cl::values">cl::values</a>(
+ clEnumValN(nodebuginfo, "none", "<i>disable debug information</i>"),
+ clEnumVal(quick, "<i>enable quick debug information</i>"),
+ clEnumVal(detailed, "<i>enable detailed debug information</i>"),
+ clEnumValEnd));
+ </pre></div>
+
+ <p>This definition defines an enumerated command line variable of type "<tt>enum
+ DebugLev</tt>", which works exactly the same way as before. The difference here
+ is just the interface exposed to the user of your program and the help output by
+ the "<tt>--help</tt>" option:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: compiler [options] <input file>
+
+ OPTIONS:
+ Choose optimization level:
+ -g - No optimizations, enable debugging
+ -O1 - Enable trivial optimizations
+ -O2 - Enable default optimizations
+ -O3 - Enable expensive optimizations
+ <b>-debug_level - Set the debugging level:
+ =none - disable debug information
+ =quick - enable quick debug information
+ =detailed - enable detailed debug information</b>
+ -f - Overwrite output files
+ -help - display available options (--help-hidden for more)
+ -o <filename> - Specify output filename
+ -quiet - Don't print informational messages
+ </pre></div>
+
+ <p>Again, the only structural difference between the debug level declaration and
+ the optimization level declaration is that the debug level declaration includes
+ an option name (<tt>"debug_level"</tt>), which automatically changes how the
+ library processes the argument. The CommandLine library supports both forms so
+ that you can choose the form most appropriate for your application.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="list">Parsing a list of options</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Now that we have the standard run-of-the-mill argument types out of the way,
+ lets get a little wild and crazy. Lets say that we want our optimizer to accept
+ a <b>list</b> of optimizations to perform, allowing duplicates. For example, we
+ might want to run: "<tt>compiler -dce -constprop -inline -dce -strip</tt>". In
+ this case, the order of the arguments and the number of appearances is very
+ important. This is what the "<tt><a href="#cl::list">cl::list</a></tt>"
+ template is for. First, start by defining an enum of the optimizations that you
+ would like to perform:</p>
+
+ <div class="doc_code"><pre>
+ enum Opts {
+ // 'inline' is a C++ keyword, so name it 'inlining'
+ dce, constprop, inlining, strip
+ };
+ </pre></div>
+
+ <p>Then define your "<tt><a href="#cl::list">cl::list</a></tt>" variable:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::list">cl::list</a><Opts> OptimizationList(<a href="#cl::desc">cl::desc</a>("<i>Available Optimizations:</i>"),
+ <a href="#cl::values">cl::values</a>(
+ clEnumVal(dce , "<i>Dead Code Elimination</i>"),
+ clEnumVal(constprop , "<i>Constant Propagation</i>"),
+ clEnumValN(inlining, "<i>inline</i>", "<i>Procedure Integration</i>"),
+ clEnumVal(strip , "<i>Strip Symbols</i>"),
+ clEnumValEnd));
+ </pre></div>
+
+ <p>This defines a variable that is conceptually of the type
+ "<tt>std::vector<enum Opts></tt>". Thus, you can access it with standard
+ vector methods:</p>
+
+ <div class="doc_code"><pre>
+ for (unsigned i = 0; i != OptimizationList.size(); ++i)
+ switch (OptimizationList[i])
+ ...
+ </pre></div>
+
+ <p>... to iterate through the list of options specified.</p>
+
+ <p>Note that the "<tt><a href="#cl::list">cl::list</a></tt>" template is
+ completely general and may be used with any data types or other arguments that
+ you can use with the "<tt><a href="#cl::opt">cl::opt</a></tt>" template. One
+ especially useful way to use a list is to capture all of the positional
+ arguments together if there may be more than one specified. In the case of a
+ linker, for example, the linker takes several '<tt>.o</tt>' files, and needs to
+ capture them into a list. This is naturally specified as:</p>
+
+ <div class="doc_code"><pre>
+ ...
+ <a href="#cl::list">cl::list</a><std::string> InputFilenames(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<Input files>"), <a href="#cl::OneOrMore">cl::OneOrMore</a>);
+ ...
+ </pre></div>
+
+ <p>This variable works just like a "<tt>vector<string></tt>" object. As
+ such, accessing the list is simple, just like above. In this example, we used
+ the <tt><a href="#cl::OneOrMore">cl::OneOrMore</a></tt> modifier to inform the
+ CommandLine library that it is an error if the user does not specify any
+ <tt>.o</tt> files on our command line. Again, this just reduces the amount of
+ checking we have to do.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="bits">Collecting options as a set of flags</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Instead of collecting sets of options in a list, it is also possible to
+ gather information for enum values in a <b>bit vector</b>. The represention used by
+ the <a href="#bits"><tt>cl::bits</tt></a> class is an <tt>unsigned</tt>
+ integer. An enum value is represented by a 0/1 in the enum's ordinal value bit
+ position. 1 indicating that the enum was specified, 0 otherwise. As each
+ specified value is parsed, the resulting enum's bit is set in the option's bit
+ vector:</p>
+
+ <div class="doc_code"><pre>
+ <i>bits</i> |= 1 << (unsigned)<i>enum</i>;
+ </pre></div>
+
+ <p>Options that are specified multiple times are redundant. Any instances after
+ the first are discarded.</p>
+
+ <p>Reworking the above list example, we could replace <a href="#list">
+ <tt>cl::list</tt></a> with <a href="#bits"><tt>cl::bits</tt></a>:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::bits">cl::bits</a><Opts> OptimizationBits(<a href="#cl::desc">cl::desc</a>("<i>Available Optimizations:</i>"),
+ <a href="#cl::values">cl::values</a>(
+ clEnumVal(dce , "<i>Dead Code Elimination</i>"),
+ clEnumVal(constprop , "<i>Constant Propagation</i>"),
+ clEnumValN(inlining, "<i>inline</i>", "<i>Procedure Integration</i>"),
+ clEnumVal(strip , "<i>Strip Symbols</i>"),
+ clEnumValEnd));
+ </pre></div>
+
+ <p>To test to see if <tt>constprop</tt> was specified, we can use the
+ <tt>cl:bits::isSet</tt> function:</p>
+
+ <div class="doc_code"><pre>
+ if (OptimizationBits.isSet(constprop)) {
+ ...
+ }
+ </pre></div>
+
+ <p>It's also possible to get the raw bit vector using the
+ <tt>cl::bits::getBits</tt> function:</p>
+
+ <div class="doc_code"><pre>
+ unsigned bits = OptimizationBits.getBits();
+ </pre></div>
+
+ <p>Finally, if external storage is used, then the location specified must be of
+ <b>type</b> <tt>unsigned</tt>. In all other ways a <a
+ href="#bits"><tt>cl::bits</tt></a> option is equivalent to a <a
+ href="#list"> <tt>cl::list</tt></a> option.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="description">Adding freeform text to help output</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>As our program grows and becomes more mature, we may decide to put summary
+ information about what it does into the help output. The help output is styled
+ to look similar to a Unix <tt>man</tt> page, providing concise information about
+ a program. Unix <tt>man</tt> pages, however often have a description about what
+ the program does. To add this to your CommandLine program, simply pass a third
+ argument to the <a
+ href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>
+ call in main. This additional argument is then printed as the overview
+ information for your program, allowing you to include any additional information
+ that you want. For example:</p>
+
+ <div class="doc_code"><pre>
+ int main(int argc, char **argv) {
+ <a href="#cl::ParseCommandLineOptions">cl::ParseCommandLineOptions</a>(argc, argv, " CommandLine compiler example\n\n"
+ " This program blah blah blah...\n");
+ ...
+ }
+ </pre></div>
+
+ <p>would yield the help output:</p>
+
+ <div class="doc_code"><pre>
+ <b>OVERVIEW: CommandLine compiler example
+
+ This program blah blah blah...</b>
+
+ USAGE: compiler [options] <input file>
+
+ OPTIONS:
+ ...
+ -help - display available options (--help-hidden for more)
+ -o <filename> - Specify output filename
+ </pre></div>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="referenceguide">Reference Guide</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Now that you know the basics of how to use the CommandLine library, this
+ section will give you the detailed information you need to tune how command line
+ options work, as well as information on more "advanced" command line option
+ processing capabilities.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="positional">Positional Arguments</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Positional arguments are those arguments that are not named, and are not
+ specified with a hyphen. Positional arguments should be used when an option is
+ specified by its position alone. For example, the standard Unix <tt>grep</tt>
+ tool takes a regular expression argument, and an optional filename to search
+ through (which defaults to standard input if a filename is not specified).
+ Using the CommandLine library, this would be specified as:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><string> Regex (<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i><regular expression></i>"), <a href="#cl::Required">cl::Required</a>);
+ <a href="#cl::opt">cl::opt</a><string> Filename(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i><input file></i>"), <a href="#cl::init">cl::init</a>("<i>-</i>"));
+ </pre></div>
+
+ <p>Given these two option declarations, the <tt>--help</tt> output for our grep
+ replacement would look like this:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: spiffygrep [options] <b><regular expression> <input file></b>
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ </pre></div>
+
+ <p>... and the resultant program could be used just like the standard
+ <tt>grep</tt> tool.</p>
+
+ <p>Positional arguments are sorted by their order of construction. This means
+ that command line options will be ordered according to how they are listed in a
+ .cpp file, but will not have an ordering defined if the positional arguments
+ are defined in multiple .cpp files. The fix for this problem is simply to
+ define all of your positional arguments in one .cpp file.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="--">Specifying positional options with hyphens</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Sometimes you may want to specify a value to your positional argument that
+ starts with a hyphen (for example, searching for '<tt>-foo</tt>' in a file). At
+ first, you will have trouble doing this, because it will try to find an argument
+ named '<tt>-foo</tt>', and will fail (and single quotes will not save you).
+ Note that the system <tt>grep</tt> has the same problem:</p>
+
+ <div class="doc_code"><pre>
+ $ spiffygrep '-foo' test.txt
+ Unknown command line argument '-foo'. Try: spiffygrep --help'
+
+ $ grep '-foo' test.txt
+ grep: illegal option -- f
+ grep: illegal option -- o
+ grep: illegal option -- o
+ Usage: grep -hblcnsviw pattern file . . .
+ </pre></div>
+
+ <p>The solution for this problem is the same for both your tool and the system
+ version: use the '<tt>--</tt>' marker. When the user specifies '<tt>--</tt>' on
+ the command line, it is telling the program that all options after the
+ '<tt>--</tt>' should be treated as positional arguments, not options. Thus, we
+ can use it like this:</p>
+
+ <div class="doc_code"><pre>
+ $ spiffygrep -- -foo test.txt
+ ...output...
+ </pre></div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="getPosition">Determining absolute position with getPosition()</a>
+ </div>
+ <div class="doc_text">
+ <p>Sometimes an option can affect or modify the meaning of another option. For
+ example, consider <tt>gcc</tt>'s <tt>-x LANG</tt> option. This tells
+ <tt>gcc</tt> to ignore the suffix of subsequent positional arguments and force
+ the file to be interpreted as if it contained source code in language
+ <tt>LANG</tt>. In order to handle this properly, you need to know the
+ absolute position of each argument, especially those in lists, so their
+ interaction(s) can be applied correctly. This is also useful for options like
+ <tt>-llibname</tt> which is actually a positional argument that starts with
+ a dash.</p>
+ <p>So, generally, the problem is that you have two <tt>cl::list</tt> variables
+ that interact in some way. To ensure the correct interaction, you can use the
+ <tt>cl::list::getPosition(optnum)</tt> method. This method returns the
+ absolute position (as found on the command line) of the <tt>optnum</tt>
+ item in the <tt>cl::list</tt>.</p>
+ <p>The idiom for usage is like this:</p>
+
+ <div class="doc_code"><pre>
+ static cl::list<std::string> Files(cl::Positional, cl::OneOrMore);
+ static cl::list<std::string> Libraries("l", cl::ZeroOrMore);
+
+ int main(int argc, char**argv) {
+ // ...
+ std::vector<std::string>::iterator fileIt = Files.begin();
+ std::vector<std::string>::iterator libIt = Libraries.begin();
+ unsigned libPos = 0, filePos = 0;
+ while ( 1 ) {
+ if ( libIt != Libraries.end() )
+ libPos = Libraries.getPosition( libIt - Libraries.begin() );
+ else
+ libPos = 0;
+ if ( fileIt != Files.end() )
+ filePos = Files.getPosition( fileIt - Files.begin() );
+ else
+ filePos = 0;
+
+ if ( filePos != 0 && (libPos == 0 || filePos < libPos) ) {
+ // Source File Is next
+ ++fileIt;
+ }
+ else if ( libPos != 0 && (filePos == 0 || libPos < filePos) ) {
+ // Library is next
+ ++libIt;
+ }
+ else
+ break; // we're done with the list
+ }
+ }</pre></div>
+
+ <p>Note that, for compatibility reasons, the <tt>cl::opt</tt> also supports an
+ <tt>unsigned getPosition()</tt> option that will provide the absolute position
+ of that option. You can apply the same approach as above with a
+ <tt>cl::opt</tt> and a <tt>cl::list</tt> option as you can with two lists.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::ConsumeAfter">The <tt>cl::ConsumeAfter</tt> modifier</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::ConsumeAfter</tt> <a href="#formatting">formatting option</a> is
+ used to construct programs that use "interpreter style" option processing. With
+ this style of option processing, all arguments specified after the last
+ positional argument are treated as special interpreter arguments that are not
+ interpreted by the command line argument.</p>
+
+ <p>As a concrete example, lets say we are developing a replacement for the
+ standard Unix Bourne shell (<tt>/bin/sh</tt>). To run <tt>/bin/sh</tt>, first
+ you specify options to the shell itself (like <tt>-x</tt> which turns on trace
+ output), then you specify the name of the script to run, then you specify
+ arguments to the script. These arguments to the script are parsed by the Bourne
+ shell command line option processor, but are not interpreted as options to the
+ shell itself. Using the CommandLine library, we would specify this as:</p>
+
+ <div class="doc_code"><pre>
+ <a href="#cl::opt">cl::opt</a><string> Script(<a href="#cl::Positional">cl::Positional</a>, <a href="#cl::desc">cl::desc</a>("<i><input script></i>"), <a href="#cl::init">cl::init</a>("-"));
+ <a href="#cl::list">cl::list</a><string> Argv(<a href="#cl::ConsumeAfter">cl::ConsumeAfter</a>, <a href="#cl::desc">cl::desc</a>("<i><program arguments>...</i>"));
+ <a href="#cl::opt">cl::opt</a><bool> Trace("<i>x</i>", <a href="#cl::desc">cl::desc</a>("<i>Enable trace output</i>"));
+ </pre></div>
+
+ <p>which automatically provides the help output:</p>
+
+ <div class="doc_code"><pre>
+ USAGE: spiffysh [options] <b><input script> <program arguments>...</b>
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ <b>-x - Enable trace output</b>
+ </pre></div>
+
+ <p>At runtime, if we run our new shell replacement as `<tt>spiffysh -x test.sh
+ -a -x -y bar</tt>', the <tt>Trace</tt> variable will be set to true, the
+ <tt>Script</tt> variable will be set to "<tt>test.sh</tt>", and the
+ <tt>Argv</tt> list will contain <tt>["-a", "-x", "-y", "bar"]</tt>, because they
+ were specified after the last positional argument (which is the script
+ name).</p>
+
+ <p>There are several limitations to when <tt>cl::ConsumeAfter</tt> options can
+ be specified. For example, only one <tt>cl::ConsumeAfter</tt> can be specified
+ per program, there must be at least one <a href="#positional">positional
+ argument</a> specified, there must not be any <a href="#cl::list">cl::list</a>
+ positional arguments, and the <tt>cl::ConsumeAfter</tt> option should be a <a
+ href="#cl::list">cl::list</a> option.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="storage">Internal vs External Storage</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>By default, all command line options automatically hold the value that they
+ parse from the command line. This is very convenient in the common case,
+ especially when combined with the ability to define command line options in the
+ files that use them. This is called the internal storage model.</p>
+
+ <p>Sometimes, however, it is nice to separate the command line option processing
+ code from the storage of the value parsed. For example, lets say that we have a
+ '<tt>-debug</tt>' option that we would like to use to enable debug information
+ across the entire body of our program. In this case, the boolean value
+ controlling the debug code should be globally accessable (in a header file, for
+ example) yet the command line option processing code should not be exposed to
+ all of these clients (requiring lots of .cpp files to #include
+ <tt>CommandLine.h</tt>).</p>
+
+ <p>To do this, set up your .h file with your option, like this for example:</p>
+
+ <div class="doc_code">
+ <pre>
+ <i>// DebugFlag.h - Get access to the '-debug' command line option
+ //
+
+ // DebugFlag - This boolean is set to true if the '-debug' command line option
+ // is specified. This should probably not be referenced directly, instead, use
+ // the DEBUG macro below.
+ //</i>
+ extern bool DebugFlag;
+
+ <i>// DEBUG macro - This macro should be used by code to emit debug information.
+ // In the '-debug' option is specified on the command line, and if this is a
+ // debug build, then the code specified as the option to the macro will be
+ // executed. Otherwise it will not be.</i>
+ <span class="doc_hilite">#ifdef NDEBUG
+ #define DEBUG(X)
+ #else
+ #define DEBUG(X)</span> do { if (DebugFlag) { X; } } while (0)
+ <span class="doc_hilite">#endif</span>
+ </pre>
+ </div>
+
+ <p>This allows clients to blissfully use the <tt>DEBUG()</tt> macro, or the
+ <tt>DebugFlag</tt> explicitly if they want to. Now we just need to be able to
+ set the <tt>DebugFlag</tt> boolean when the option is set. To do this, we pass
+ an additional argument to our command line argument processor, and we specify
+ where to fill in with the <a href="#cl::location">cl::location</a>
+ attribute:</p>
+
+ <div class="doc_code">
+ <pre>
+ bool DebugFlag; <i>// the actual value</i>
+ static <a href="#cl::opt">cl::opt</a><bool, true> <i>// The parser</i>
+ Debug("<i>debug</i>", <a href="#cl::desc">cl::desc</a>("<i>Enable debug output</i>"), <a href="#cl::Hidden">cl::Hidden</a>, <a href="#cl::location">cl::location</a>(DebugFlag));
+ </pre>
+ </div>
+
+ <p>In the above example, we specify "<tt>true</tt>" as the second argument to
+ the <tt><a href="#cl::opt">cl::opt</a></tt> template, indicating that the
+ template should not maintain a copy of the value itself. In addition to this,
+ we specify the <tt><a href="#cl::location">cl::location</a></tt> attribute, so
+ that <tt>DebugFlag</tt> is automatically set.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="attributes">Option Attributes</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>This section describes the basic attributes that you can specify on
+ options.</p>
+
+ <ul>
+
+ <li>The option name attribute (which is required for all options, except <a
+ href="#positional">positional options</a>) specifies what the option name is.
+ This option is specified in simple double quotes:
+
+ <pre>
+ <a href="#cl::opt">cl::opt</a><<b>bool</b>> Quiet("<i>quiet</i>");
+ </pre>
+
+ </li>
+
+ <li><a name="cl::desc">The <b><tt>cl::desc</tt></b></a> attribute specifies a
+ description for the option to be shown in the <tt>--help</tt> output for the
+ program.</li>
+
+ <li><a name="cl::value_desc">The <b><tt>cl::value_desc</tt></b></a> attribute
+ specifies a string that can be used to fine tune the <tt>--help</tt> output for
+ a command line option. Look <a href="#value_desc_example">here</a> for an
+ example.</li>
+
+ <li><a name="cl::init">The <b><tt>cl::init</tt></b></a> attribute specifies an
+ inital value for a <a href="#cl::opt">scalar</a> option. If this attribute is
+ not specified then the command line option value defaults to the value created
+ by the default constructor for the type. <b>Warning</b>: If you specify both
+ <b><tt>cl::init</tt></b> and <b><tt>cl::location</tt></b> for an option,
+ you must specify <b><tt>cl::location</tt></b> first, so that when the
+ command-line parser sees <b><tt>cl::init</tt></b>, it knows where to put the
+ initial value. (You will get an error at runtime if you don't put them in
+ the right order.)</li>
+
+ <li><a name="cl::location">The <b><tt>cl::location</tt></b></a> attribute where to
+ store the value for a parsed command line option if using external storage. See
+ the section on <a href="#storage">Internal vs External Storage</a> for more
+ information.</li>
+
+ <li><a name="cl::aliasopt">The <b><tt>cl::aliasopt</tt></b></a> attribute
+ specifies which option a <tt><a href="#cl::alias">cl::alias</a></tt> option is
+ an alias for.</li>
+
+ <li><a name="cl::values">The <b><tt>cl::values</tt></b></a> attribute specifies
+ the string-to-value mapping to be used by the generic parser. It takes a
+ <b>clEnumValEnd terminated</b> list of (option, value, description) triplets
+ that
+ specify the option name, the value mapped to, and the description shown in the
+ <tt>--help</tt> for the tool. Because the generic parser is used most
+ frequently with enum values, two macros are often useful:
+
+ <ol>
+
+ <li><a name="clEnumVal">The <b><tt>clEnumVal</tt></b></a> macro is used as a
+ nice simple way to specify a triplet for an enum. This macro automatically
+ makes the option name be the same as the enum name. The first option to the
+ macro is the enum, the second is the description for the command line
+ option.</li>
+
+ <li><a name="clEnumValN">The <b><tt>clEnumValN</tt></b></a> macro is used to
+ specify macro options where the option name doesn't equal the enum name. For
+ this macro, the first argument is the enum value, the second is the flag name,
+ and the second is the description.</li>
+
+ <li><a name="cl::multi_val">The <b><tt>cl::multi_val</tt></b></a>
+ attribute specifies that this option takes has multiple values
+ (example: <tt>-sectalign segname sectname sectvalue</tt>). This
+ attribute takes one unsigned argument - the number of values for the
+ option. This attribute is valid only on <tt>cl::list</tt> options (and
+ will fail with compile error if you try to use it with other option
+ types). It is allowed to use all of the usual modifiers on
+ multi-valued options (besides <tt>cl::ValueDisallowed</tt>,
+ obviously).</li>
+
+
+ </ol>
+
+ You will get a compile time error if you try to use cl::values with a parser
+ that does not support it.</li>
+
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="modifiers">Option Modifiers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Option modifiers are the flags and expressions that you pass into the
+ constructors for <tt><a href="#cl::opt">cl::opt</a></tt> and <tt><a
+ href="#cl::list">cl::list</a></tt>. These modifiers give you the ability to
+ tweak how options are parsed and how <tt>--help</tt> output is generated to fit
+ your application well.</p>
+
+ <p>These options fall into five main catagories:</p>
+
+ <ol>
+ <li><a href="#hiding">Hiding an option from <tt>--help</tt> output</a></li>
+ <li><a href="#numoccurrences">Controlling the number of occurrences
+ required and allowed</a></li>
+ <li><a href="#valrequired">Controlling whether or not a value must be
+ specified</a></li>
+ <li><a href="#formatting">Controlling other formatting options</a></li>
+ <li><a href="#misc">Miscellaneous option modifiers</a></li>
+ </ol>
+
+ <p>It is not possible to specify two options from the same catagory (you'll get
+ a runtime error) to a single option, except for options in the miscellaneous
+ catagory. The CommandLine library specifies defaults for all of these settings
+ that are the most useful in practice and the most common, which mean that you
+ usually shouldn't have to worry about these.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="hiding">Hiding an option from <tt>--help</tt> output</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::NotHidden</tt>, <tt>cl::Hidden</tt>, and
+ <tt>cl::ReallyHidden</tt> modifiers are used to control whether or not an option
+ appears in the <tt>--help</tt> and <tt>--help-hidden</tt> output for the
+ compiled program:</p>
+
+ <ul>
+
+ <li><a name="cl::NotHidden">The <b><tt>cl::NotHidden</tt></b></a> modifier
+ (which is the default for <tt><a href="#cl::opt">cl::opt</a></tt> and <tt><a
+ href="#cl::list">cl::list</a></tt> options) indicates the option is to appear
+ in both help listings.</li>
+
+ <li><a name="cl::Hidden">The <b><tt>cl::Hidden</tt></b></a> modifier (which is the
+ default for <tt><a href="#cl::alias">cl::alias</a></tt> options) indicates that
+ the option should not appear in the <tt>--help</tt> output, but should appear in
+ the <tt>--help-hidden</tt> output.</li>
+
+ <li><a name="cl::ReallyHidden">The <b><tt>cl::ReallyHidden</tt></b></a> modifier
+ indicates that the option should not appear in any help output.</li>
+
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="numoccurrences">Controlling the number of occurrences required and
+ allowed</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>This group of options is used to control how many time an option is allowed
+ (or required) to be specified on the command line of your program. Specifying a
+ value for this setting allows the CommandLine library to do error checking for
+ you.</p>
+
+ <p>The allowed values for this option group are:</p>
+
+ <ul>
+
+ <li><a name="cl::Optional">The <b><tt>cl::Optional</tt></b></a> modifier (which
+ is the default for the <tt><a href="#cl::opt">cl::opt</a></tt> and <tt><a
+ href="#cl::alias">cl::alias</a></tt> classes) indicates that your program will
+ allow either zero or one occurrence of the option to be specified.</li>
+
+ <li><a name="cl::ZeroOrMore">The <b><tt>cl::ZeroOrMore</tt></b></a> modifier
+ (which is the default for the <tt><a href="#cl::list">cl::list</a></tt> class)
+ indicates that your program will allow the option to be specified zero or more
+ times.</li>
+
+ <li><a name="cl::Required">The <b><tt>cl::Required</tt></b></a> modifier
+ indicates that the specified option must be specified exactly one time.</li>
+
+ <li><a name="cl::OneOrMore">The <b><tt>cl::OneOrMore</tt></b></a> modifier
+ indicates that the option must be specified at least one time.</li>
+
+ <li>The <b><tt>cl::ConsumeAfter</tt></b> modifier is described in the <a
+ href="#positional">Positional arguments section</a>.</li>
+
+ </ul>
+
+ <p>If an option is not specified, then the value of the option is equal to the
+ value specified by the <tt><a href="#cl::init">cl::init</a></tt> attribute. If
+ the <tt><a href="#cl::init">cl::init</a></tt> attribute is not specified, the
+ option value is initialized with the default constructor for the data type.</p>
+
+ <p>If an option is specified multiple times for an option of the <tt><a
+ href="#cl::opt">cl::opt</a></tt> class, only the last value will be
+ retained.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="valrequired">Controlling whether or not a value must be specified</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>This group of options is used to control whether or not the option allows a
+ value to be present. In the case of the CommandLine library, a value is either
+ specified with an equal sign (e.g. '<tt>-index-depth=17</tt>') or as a trailing
+ string (e.g. '<tt>-o a.out</tt>').</p>
+
+ <p>The allowed values for this option group are:</p>
+
+ <ul>
+
+ <li><a name="cl::ValueOptional">The <b><tt>cl::ValueOptional</tt></b></a> modifier
+ (which is the default for <tt>bool</tt> typed options) specifies that it is
+ acceptable to have a value, or not. A boolean argument can be enabled just by
+ appearing on the command line, or it can have an explicit '<tt>-foo=true</tt>'.
+ If an option is specified with this mode, it is illegal for the value to be
+ provided without the equal sign. Therefore '<tt>-foo true</tt>' is illegal. To
+ get this behavior, you must use the <a
+ href="#cl::ValueRequired">cl::ValueRequired</a> modifier.</li>
+
+ <li><a name="cl::ValueRequired">The <b><tt>cl::ValueRequired</tt></b></a> modifier
+ (which is the default for all other types except for <a
+ href="#onealternative">unnamed alternatives using the generic parser</a>)
+ specifies that a value must be provided. This mode informs the command line
+ library that if an option is not provides with an equal sign, that the next
+ argument provided must be the value. This allows things like '<tt>-o
+ a.out</tt>' to work.</li>
+
+ <li><a name="cl::ValueDisallowed">The <b><tt>cl::ValueDisallowed</tt></b></a>
+ modifier (which is the default for <a href="#onealternative">unnamed
+ alternatives using the generic parser</a>) indicates that it is a runtime error
+ for the user to specify a value. This can be provided to disallow users from
+ providing options to boolean options (like '<tt>-foo=true</tt>').</li>
+
+ </ul>
+
+ <p>In general, the default values for this option group work just like you would
+ want them to. As mentioned above, you can specify the <a
+ href="#cl::ValueDisallowed">cl::ValueDisallowed</a> modifier to a boolean
+ argument to restrict your command line parser. These options are mostly useful
+ when <a href="#extensionguide">extending the library</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="formatting">Controlling other formatting options</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The formatting option group is used to specify that the command line option
+ has special abilities and is otherwise different from other command line
+ arguments. As usual, you can only specify one of these arguments at most.</p>
+
+ <ul>
+
+ <li><a name="cl::NormalFormatting">The <b><tt>cl::NormalFormatting</tt></b></a>
+ modifier (which is the default all options) specifies that this option is
+ "normal".</li>
+
+ <li><a name="cl::Positional">The <b><tt>cl::Positional</tt></b></a> modifier
+ specifies that this is a positional argument that does not have a command line
+ option associated with it. See the <a href="#positional">Positional
+ Arguments</a> section for more information.</li>
+
+ <li>The <b><a href="#cl::ConsumeAfter"><tt>cl::ConsumeAfter</tt></a></b> modifier
+ specifies that this option is used to capture "interpreter style" arguments. See <a href="#cl::ConsumeAfter">this section for more information</a>.</li>
+
+ <li><a name="cl::Prefix">The <b><tt>cl::Prefix</tt></b></a> modifier specifies
+ that this option prefixes its value. With 'Prefix' options, the equal sign does
+ not separate the value from the option name specified. Instead, the value is
+ everything after the prefix, including any equal sign if present. This is useful
+ for processing odd arguments like <tt>-lmalloc</tt> and <tt>-L/usr/lib</tt> in a
+ linker tool or <tt>-DNAME=value</tt> in a compiler tool. Here, the
+ '<tt>l</tt>', '<tt>D</tt>' and '<tt>L</tt>' options are normal string (or list)
+ options, that have the <b><tt><a href="#cl::Prefix">cl::Prefix</a></tt></b>
+ modifier added to allow the CommandLine library to recognize them. Note that
+ <b><tt><a href="#cl::Prefix">cl::Prefix</a></tt></b> options must not have the
+ <b><tt><a href="#cl::ValueDisallowed">cl::ValueDisallowed</a></tt></b> modifier
+ specified.</li>
+
+ <li><a name="cl::Grouping">The <b><tt>cl::Grouping</tt></b></a> modifier is used
+ to implement Unix-style tools (like <tt>ls</tt>) that have lots of single letter
+ arguments, but only require a single dash. For example, the '<tt>ls -labF</tt>'
+ command actually enables four different options, all of which are single
+ letters. Note that <b><tt><a href="#cl::Grouping">cl::Grouping</a></tt></b>
+ options cannot have values.</li>
+
+ </ul>
+
+ <p>The CommandLine library does not restrict how you use the <b><tt><a
+ href="#cl::Prefix">cl::Prefix</a></tt></b> or <b><tt><a
+ href="#cl::Grouping">cl::Grouping</a></tt></b> modifiers, but it is possible to
+ specify ambiguous argument settings. Thus, it is possible to have multiple
+ letter options that are prefix or grouping options, and they will still work as
+ designed.</p>
+
+ <p>To do this, the CommandLine library uses a greedy algorithm to parse the
+ input option into (potentially multiple) prefix and grouping options. The
+ strategy basically looks like this:</p>
+
+ <div class="doc_code"><tt>parse(string OrigInput) {</tt>
+
+ <ol>
+ <li><tt>string input = OrigInput;</tt>
+ <li><tt>if (isOption(input)) return getOption(input).parse();</tt> <i>// Normal option</i>
+ <li><tt>while (!isOption(input) && !input.empty()) input.pop_back();</tt> <i>// Remove the last letter</i>
+ <li><tt>if (input.empty()) return error();</tt> <i>// No matching option</i>
+ <li><tt>if (getOption(input).isPrefix())<br>
+ return getOption(input).parse(input);</tt>
+ <li><tt>while (!input.empty()) { <i>// Must be grouping options</i><br>
+ getOption(input).parse();<br>
+ OrigInput.erase(OrigInput.begin(), OrigInput.begin()+input.length());<br>
+ input = OrigInput;<br>
+ while (!isOption(input) && !input.empty()) input.pop_back();<br>
+ }</tt>
+ <li><tt>if (!OrigInput.empty()) error();</tt></li>
+ </ol>
+
+ <p><tt>}</tt></p>
+ </div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="misc">Miscellaneous option modifiers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The miscellaneous option modifiers are the only flags where you can specify
+ more than one flag from the set: they are not mutually exclusive. These flags
+ specify boolean properties that modify the option.</p>
+
+ <ul>
+
+ <li><a name="cl::CommaSeparated">The <b><tt>cl::CommaSeparated</tt></b></a> modifier
+ indicates that any commas specified for an option's value should be used to
+ split the value up into multiple values for the option. For example, these two
+ options are equivalent when <tt>cl::CommaSeparated</tt> is specified:
+ "<tt>-foo=a -foo=b -foo=c</tt>" and "<tt>-foo=a,b,c</tt>". This option only
+ makes sense to be used in a case where the option is allowed to accept one or
+ more values (i.e. it is a <a href="#cl::list">cl::list</a> option).</li>
+
+ <li><a name="cl::PositionalEatsArgs">The
+ <b><tt>cl::PositionalEatsArgs</tt></b></a> modifier (which only applies to
+ positional arguments, and only makes sense for lists) indicates that positional
+ argument should consume any strings after it (including strings that start with
+ a "-") up until another recognized positional argument. For example, if you
+ have two "eating" positional arguments, "<tt>pos1</tt>" and "<tt>pos2</tt>", the
+ string "<tt>-pos1 -foo -bar baz -pos2 -bork</tt>" would cause the "<tt>-foo -bar
+ -baz</tt>" strings to be applied to the "<tt>-pos1</tt>" option and the
+ "<tt>-bork</tt>" string to be applied to the "<tt>-pos2</tt>" option.</li>
+
+ <li><a name="cl::Sink">The <b><tt>cl::Sink</tt></b></a> modifier is
+ used to handle unknown options. If there is at least one option with
+ <b><tt>cl::Sink</tt></b></a> modifier specified, the parser passes
+ unrecognized option strings to it as values instead of signaling an
+ error. As with <b><tt>cl::CommaSeparated</tt></b></a>, this modifier
+ only makes sense with a <a href="#cl::list">cl::list</a> option.</li>
+
+ <li><a name="cl::AllowInverse">The <b><tt>cl::AllowInverse</tt></b></a>
+ modifier can be used on options that have the form <tt>-fopt</tt> to
+ automatically create a corresponding
+ <tt>-fno-opt</tt> option. The <tt>f</tt> can be any single
+ character, and the <tt>opt</tt> can be any one or more characters.
+ The value of the created option is the logical complement of the value
+ that would have been used if the base form of the option was used.
+ This modifier only makes sense with an option that uses
+ a <a href="#boolparser">bool parser</a>.</li>
+
+
+ </ul>
+
+ <p>So far, these are the only three miscellaneous option modifiers.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="response">Response files</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Some systems, such as certain variants of Microsoft Windows and
+ some older Unices have a relatively low limit on command-line
+ length. It is therefore customary to use the so-called 'response
+ files' to circumvent this restriction. These files are mentioned on
+ the command-line (using the "@file") syntax. The program reads these
+ files and inserts the contents into argv, thereby working around the
+ command-line length limits. Response files are enabled by an optional
+ fourth argument to
+ <a href="#cl::ParseEnvironmentOptions"><tt>cl::ParseEnvironmentOptions</tt></a>
+ and
+ <a href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>.
+ </p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="toplevel">Top-Level Classes and Functions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Despite all of the built-in flexibility, the CommandLine option library
+ really only consists of one function (<a
+ href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>)
+ and three main classes: <a href="#cl::opt"><tt>cl::opt</tt></a>, <a
+ href="#cl::list"><tt>cl::list</tt></a>, and <a
+ href="#cl::alias"><tt>cl::alias</tt></a>. This section describes these three
+ classes in detail.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::ParseCommandLineOptions">The <tt>cl::ParseCommandLineOptions</tt>
+ function</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::ParseCommandLineOptions</tt> function is designed to be called
+ directly from <tt>main</tt>, and is used to fill in the values of all of the
+ command line option variables once <tt>argc</tt> and <tt>argv</tt> are
+ available.</p>
+
+ <p>The <tt>cl::ParseCommandLineOptions</tt> function requires two parameters
+ (<tt>argc</tt> and <tt>argv</tt>), but may also take an optional third parameter
+ which holds <a href="#description">additional extra text</a> to emit when the
+ <tt>--help</tt> option is invoked, and a fourth boolean parameter that enables
+ <a href="#response">response files</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::ParseEnvironmentOptions">The <tt>cl::ParseEnvironmentOptions</tt>
+ function</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::ParseEnvironmentOptions</tt> function has mostly the same effects
+ as <a
+ href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>,
+ except that it is designed to take values for options from an environment
+ variable, for those cases in which reading the command line is not convenient or
+ desired. It fills in the values of all the command line option variables just
+ like <a
+ href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>
+ does.</p>
+
+ <p>It takes four parameters: the name of the program (since <tt>argv</tt> may
+ not be available, it can't just look in <tt>argv[0]</tt>), the name of the
+ environment variable to examine, the optional
+ <a href="#description">additional extra text</a> to emit when the
+ <tt>--help</tt> option is invoked, and the boolean
+ switch that controls whether <a href="#response">reponse files</a>
+ should be read.</p>
+
+ <p><tt>cl::ParseEnvironmentOptions</tt> will break the environment
+ variable's value up into words and then process them using
+ <a href="#cl::ParseCommandLineOptions"><tt>cl::ParseCommandLineOptions</tt></a>.
+ <b>Note:</b> Currently <tt>cl::ParseEnvironmentOptions</tt> does not support
+ quoting, so an environment variable containing <tt>-option "foo bar"</tt> will
+ be parsed as three words, <tt>-option</tt>, <tt>"foo</tt>, and <tt>bar"</tt>,
+ which is different from what you would get from the shell with the same
+ input.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::SetVersionPrinter">The <tt>cl::SetVersionPrinter</tt>
+ function</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::SetVersionPrinter</tt> function is designed to be called
+ directly from <tt>main</tt> and <i>before</i>
+ <tt>cl::ParseCommandLineOptions</tt>. Its use is optional. It simply arranges
+ for a function to be called in response to the <tt>--version</tt> option instead
+ of having the <tt>CommandLine</tt> library print out the usual version string
+ for LLVM. This is useful for programs that are not part of LLVM but wish to use
+ the <tt>CommandLine</tt> facilities. Such programs should just define a small
+ function that takes no arguments and returns <tt>void</tt> and that prints out
+ whatever version information is appropriate for the program. Pass the address
+ of that function to <tt>cl::SetVersionPrinter</tt> to arrange for it to be
+ called when the <tt>--version</tt> option is given by the user.</p>
+
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::opt">The <tt>cl::opt</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::opt</tt> class is the class used to represent scalar command line
+ options, and is the one used most of the time. It is a templated class which
+ can take up to three arguments (all except for the first have default values
+ though):</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> cl {
+ <b>template</b> <<b>class</b> DataType, <b>bool</b> ExternalStorage = <b>false</b>,
+ <b>class</b> ParserClass = parser<DataType> >
+ <b>class</b> opt;
+ }
+ </pre></div>
+
+ <p>The first template argument specifies what underlying data type the command
+ line argument is, and is used to select a default parser implementation. The
+ second template argument is used to specify whether the option should contain
+ the storage for the option (the default) or whether external storage should be
+ used to contain the value parsed for the option (see <a href="#storage">Internal
+ vs External Storage</a> for more information).</p>
+
+ <p>The third template argument specifies which parser to use. The default value
+ selects an instantiation of the <tt>parser</tt> class based on the underlying
+ data type of the option. In general, this default works well for most
+ applications, so this option is only used when using a <a
+ href="#customparser">custom parser</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::list">The <tt>cl::list</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::list</tt> class is the class used to represent a list of command
+ line options. It too is a templated class which can take up to three
+ arguments:</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> cl {
+ <b>template</b> <<b>class</b> DataType, <b>class</b> Storage = <b>bool</b>,
+ <b>class</b> ParserClass = parser<DataType> >
+ <b>class</b> list;
+ }
+ </pre></div>
+
+ <p>This class works the exact same as the <a
+ href="#cl::opt"><tt>cl::opt</tt></a> class, except that the second argument is
+ the <b>type</b> of the external storage, not a boolean value. For this class,
+ the marker type '<tt>bool</tt>' is used to indicate that internal storage should
+ be used.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::bits">The <tt>cl::bits</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::bits</tt> class is the class used to represent a list of command
+ line options in the form of a bit vector. It is also a templated class which
+ can take up to three arguments:</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> cl {
+ <b>template</b> <<b>class</b> DataType, <b>class</b> Storage = <b>bool</b>,
+ <b>class</b> ParserClass = parser<DataType> >
+ <b>class</b> bits;
+ }
+ </pre></div>
+
+ <p>This class works the exact same as the <a
+ href="#cl::opt"><tt>cl::lists</tt></a> class, except that the second argument
+ must be of <b>type</b> <tt>unsigned</tt> if external storage is used.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::alias">The <tt>cl::alias</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::alias</tt> class is a nontemplated class that is used to form
+ aliases for other arguments.</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> cl {
+ <b>class</b> alias;
+ }
+ </pre></div>
+
+ <p>The <a href="#cl::aliasopt"><tt>cl::aliasopt</tt></a> attribute should be
+ used to specify which option this is an alias for. Alias arguments default to
+ being <a href="#cl::Hidden">Hidden</a>, and use the aliased options parser to do
+ the conversion from string to data.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="cl::extrahelp">The <tt>cl::extrahelp</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>cl::extrahelp</tt> class is a nontemplated class that allows extra
+ help text to be printed out for the <tt>--help</tt> option.</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> cl {
+ <b>struct</b> extrahelp;
+ }
+ </pre></div>
+
+ <p>To use the extrahelp, simply construct one with a <tt>const char*</tt>
+ parameter to the constructor. The text passed to the constructor will be printed
+ at the bottom of the help message, verbatim. Note that multiple
+ <tt>cl::extrahelp</tt> <b>can</b> be used, but this practice is discouraged. If
+ your tool needs to print additional help information, put all that help into a
+ single <tt>cl::extrahelp</tt> instance.</p>
+ <p>For example:</p>
+ <div class="doc_code"><pre>
+ cl::extrahelp("\nADDITIONAL HELP:\n\n This is the extra help\n");
+ </pre></div>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="builtinparsers">Builtin parsers</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Parsers control how the string value taken from the command line is
+ translated into a typed value, suitable for use in a C++ program. By default,
+ the CommandLine library uses an instance of <tt>parser<type></tt> if the
+ command line option specifies that it uses values of type '<tt>type</tt>'.
+ Because of this, custom option processing is specified with specializations of
+ the '<tt>parser</tt>' class.</p>
+
+ <p>The CommandLine library provides the following builtin parser
+ specializations, which are sufficient for most applications. It can, however,
+ also be extended to work with new data types and new ways of interpreting the
+ same data. See the <a href="#customparser">Writing a Custom Parser</a> for more
+ details on this type of library extension.</p>
+
+ <ul>
+
+ <li><a name="genericparser">The <b>generic <tt>parser<t></tt> parser</b></a>
+ can be used to map strings values to any data type, through the use of the <a
+ href="#cl::values">cl::values</a> property, which specifies the mapping
+ information. The most common use of this parser is for parsing enum values,
+ which allows you to use the CommandLine library for all of the error checking to
+ make sure that only valid enum values are specified (as opposed to accepting
+ arbitrary strings). Despite this, however, the generic parser class can be used
+ for any data type.</li>
+
+ <li><a name="boolparser">The <b><tt>parser<bool></tt> specialization</b></a>
+ is used to convert boolean strings to a boolean value. Currently accepted
+ strings are "<tt>true</tt>", "<tt>TRUE</tt>", "<tt>True</tt>", "<tt>1</tt>",
+ "<tt>false</tt>", "<tt>FALSE</tt>", "<tt>False</tt>", and "<tt>0</tt>". The
+ <b><tt>cl::AllowInverse</tt></b> modifier can be used on an option of the form
+ <tt>-fopt</tt> that uses the <tt>parser<bool></tt> specialization
+ to create a corresponding option with the form <tt>-fno-opt</tt>. See
+ <a href="#cl::AllowInverse"><tt>cl::AllowInverse</tt></a> for details.</li>
+
+ <li><a name="boolOrDefaultparser">The <b><tt>parser<boolOrDefault></tt>
+ specialization</b></a> is used for cases where the value is boolean,
+ but we also need to know whether the option was specified at all. boolOrDefault
+ is an enum with 3 values, BOU_UNSET, BOU_TRUE and BOU_FALSE. This parser accepts
+ the same strings as <b><tt>parser<bool></tt></b>.</li>
+
+ <li><a name="stringparser">The <b><tt>parser<string></tt>
+ specialization</b></a> simply stores the parsed string into the string value
+ specified. No conversion or modification of the data is performed.</li>
+
+ <li><a name="intparser">The <b><tt>parser<int></tt> specialization</b></a>
+ uses the C <tt>strtol</tt> function to parse the string input. As such, it will
+ accept a decimal number (with an optional '+' or '-' prefix) which must start
+ with a non-zero digit. It accepts octal numbers, which are identified with a
+ '<tt>0</tt>' prefix digit, and hexadecimal numbers with a prefix of
+ '<tt>0x</tt>' or '<tt>0X</tt>'.</li>
+
+ <li><a name="doubleparser">The <b><tt>parser<double></tt></b></a> and
+ <b><tt>parser<float></tt> specializations</b> use the standard C
+ <tt>strtod</tt> function to convert floating point strings into floating point
+ values. As such, a broad range of string formats is supported, including
+ exponential notation (ex: <tt>1.7e15</tt>) and properly supports locales.
+ </li>
+
+ </ul>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="extensionguide">Extension Guide</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Although the CommandLine library has a lot of functionality built into it
+ already (as discussed previously), one of its true strengths lie in its
+ extensibility. This section discusses how the CommandLine library works under
+ the covers and illustrates how to do some simple, common, extensions.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="customparser">Writing a custom parser</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>One of the simplest and most common extensions is the use of a custom parser.
+ As <a href="#builtinparsers">discussed previously</a>, parsers are the portion
+ of the CommandLine library that turns string input from the user into a
+ particular parsed data type, validating the input in the process.</p>
+
+ <p>There are two ways to use a new parser:</p>
+
+ <ol>
+
+ <li>
+
+ <p>Specialize the <a href="#genericparser"><tt>cl::parser</tt></a> template for
+ your custom data type.<p>
+
+ <p>This approach has the advantage that users of your custom data type will
+ automatically use your custom parser whenever they define an option with a value
+ type of your data type. The disadvantage of this approach is that it doesn't
+ work if your fundamental data type is something that is already supported.</p>
+
+ </li>
+
+ <li>
+
+ <p>Write an independent class, using it explicitly from options that need
+ it.</p>
+
+ <p>This approach works well in situations where you would line to parse an
+ option using special syntax for a not-very-special data-type. The drawback of
+ this approach is that users of your parser have to be aware that they are using
+ your parser instead of the builtin ones.</p>
+
+ </li>
+
+ </ol>
+
+ <p>To guide the discussion, we will discuss a custom parser that accepts file
+ sizes, specified with an optional unit after the numeric size. For example, we
+ would like to parse "102kb", "41M", "1G" into the appropriate integer value. In
+ this case, the underlying data type we want to parse into is
+ '<tt>unsigned</tt>'. We choose approach #2 above because we don't want to make
+ this the default for all <tt>unsigned</tt> options.</p>
+
+ <p>To start out, we declare our new <tt>FileSizeParser</tt> class:</p>
+
+ <div class="doc_code"><pre>
+ <b>struct</b> FileSizeParser : <b>public</b> cl::basic_parser<<b>unsigned</b>> {
+ <i>// parse - Return true on error.</i>
+ <b>bool</b> parse(cl::Option &O, <b>const char</b> *ArgName, <b>const</b> std::string &ArgValue,
+ <b>unsigned</b> &Val);
+ };
+ </pre></div>
+
+ <p>Our new class inherits from the <tt>cl::basic_parser</tt> template class to
+ fill in the default, boiler plate code for us. We give it the data type that
+ we parse into, the last argument to the <tt>parse</tt> method, so that clients of
+ our custom parser know what object type to pass in to the parse method. (Here we
+ declare that we parse into '<tt>unsigned</tt>' variables.)</p>
+
+ <p>For most purposes, the only method that must be implemented in a custom
+ parser is the <tt>parse</tt> method. The <tt>parse</tt> method is called
+ whenever the option is invoked, passing in the option itself, the option name,
+ the string to parse, and a reference to a return value. If the string to parse
+ is not well-formed, the parser should output an error message and return true.
+ Otherwise it should return false and set '<tt>Val</tt>' to the parsed value. In
+ our example, we implement <tt>parse</tt> as:</p>
+
+ <div class="doc_code"><pre>
+ <b>bool</b> FileSizeParser::parse(cl::Option &O, <b>const char</b> *ArgName,
+ <b>const</b> std::string &Arg, <b>unsigned</b> &Val) {
+ <b>const char</b> *ArgStart = Arg.c_str();
+ <b>char</b> *End;
+
+ <i>// Parse integer part, leaving 'End' pointing to the first non-integer char</i>
+ Val = (unsigned)strtol(ArgStart, &End, 0);
+
+ <b>while</b> (1) {
+ <b>switch</b> (*End++) {
+ <b>case</b> 0: <b>return</b> false; <i>// No error</i>
+ <b>case</b> 'i': <i>// Ignore the 'i' in KiB if people use that</i>
+ <b>case</b> 'b': <b>case</b> 'B': <i>// Ignore B suffix</i>
+ <b>break</b>;
+
+ <b>case</b> 'g': <b>case</b> 'G': Val *= 1024*1024*1024; <b>break</b>;
+ <b>case</b> 'm': <b>case</b> 'M': Val *= 1024*1024; <b>break</b>;
+ <b>case</b> 'k': <b>case</b> 'K': Val *= 1024; <b>break</b>;
+
+ default:
+ <i>// Print an error message if unrecognized character!</i>
+ <b>return</b> O.error(": '" + Arg + "' value invalid for file size argument!");
+ }
+ }
+ }
+ </pre></div>
+
+ <p>This function implements a very simple parser for the kinds of strings we are
+ interested in. Although it has some holes (it allows "<tt>123KKK</tt>" for
+ example), it is good enough for this example. Note that we use the option
+ itself to print out the error message (the <tt>error</tt> method always returns
+ true) in order to get a nice error message (shown below). Now that we have our
+ parser class, we can use it like this:</p>
+
+ <div class="doc_code"><pre>
+ <b>static</b> <a href="#cl::opt">cl::opt</a><<b>unsigned</b>, <b>false</b>, FileSizeParser>
+ MFS(<i>"max-file-size"</i>, <a href="#cl::desc">cl::desc</a>(<i>"Maximum file size to accept"</i>),
+ <a href="#cl::value_desc">cl::value_desc</a>("<i>size</i>"));
+ </pre></div>
+
+ <p>Which adds this to the output of our program:</p>
+
+ <div class="doc_code"><pre>
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ ...
+ <b>-max-file-size=<size> - Maximum file size to accept</b>
+ </pre></div>
+
+ <p>And we can test that our parse works correctly now (the test program just
+ prints out the max-file-size argument value):</p>
+
+ <div class="doc_code"><pre>
+ $ ./test
+ MFS: 0
+ $ ./test -max-file-size=123MB
+ MFS: 128974848
+ $ ./test -max-file-size=3G
+ MFS: 3221225472
+ $ ./test -max-file-size=dog
+ -max-file-size option: 'dog' value invalid for file size argument!
+ </pre></div>
+
+ <p>It looks like it works. The error message that we get is nice and helpful,
+ and we seem to accept reasonable file sizes. This wraps up the "custom parser"
+ tutorial.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="explotingexternal">Exploiting external storage</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Several of the LLVM libraries define static <tt>cl::opt</tt> instances that
+ will automatically be included in any program that links with that library.
+ This is a feature. However, sometimes it is necessary to know the value of the
+ command line option outside of the library. In these cases the library does or
+ should provide an external storage location that is accessible to users of the
+ library. Examples of this include the <tt>llvm::DebugFlag</tt> exported by the
+ <tt>lib/Support/Debug.cpp</tt> file and the <tt>llvm::TimePassesIsEnabled</tt>
+ flag exported by the <tt>lib/VMCore/Pass.cpp</tt> file.</p>
+
+ <p>TODO: complete this section</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="dynamicopts">Dynamically adding command line options</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>TODO: fill in this section</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CompilerDriver.html
diff -c /dev/null llvm-www/releases/2.5/docs/CompilerDriver.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CompilerDriver.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,619 ----
+ <?xml version="1.0" encoding="utf-8" ?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <meta name="generator" content="Docutils 0.4.1: http://docutils.sourceforge.net/" />
+ <title>Customizing LLVMC: Reference Manual</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css" />
+ </head>
+ <body>
+ <div class="document" id="customizing-llvmc-reference-manual">
+ <h1 class="title">Customizing LLVMC: Reference Manual</h1>
+ <!-- This file was automatically generated by rst2html.
+ Please do not edit directly!
+ The ReST source lives in the directory 'tools/llvmc/doc'. -->
+ <div class="contents topic">
+ <p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+ <ul class="simple">
+ <li><a class="reference" href="#introduction" id="id4" name="id4">Introduction</a></li>
+ <li><a class="reference" href="#compiling-with-llvmc" id="id5" name="id5">Compiling with LLVMC</a></li>
+ <li><a class="reference" href="#predefined-options" id="id6" name="id6">Predefined options</a></li>
+ <li><a class="reference" href="#compiling-llvmc-plugins" id="id7" name="id7">Compiling LLVMC plugins</a></li>
+ <li><a class="reference" href="#customizing-llvmc-the-compilation-graph" id="id8" name="id8">Customizing LLVMC: the compilation graph</a></li>
+ <li><a class="reference" href="#describing-options" id="id9" name="id9">Describing options</a><ul>
+ <li><a class="reference" href="#external-options" id="id10" name="id10">External options</a></li>
+ </ul>
+ </li>
+ <li><a class="reference" href="#conditional-evaluation" id="id11" name="id11">Conditional evaluation</a></li>
+ <li><a class="reference" href="#writing-a-tool-description" id="id12" name="id12">Writing a tool description</a><ul>
+ <li><a class="reference" href="#actions" id="id13" name="id13">Actions</a></li>
+ </ul>
+ </li>
+ <li><a class="reference" href="#language-map" id="id14" name="id14">Language map</a></li>
+ <li><a class="reference" href="#more-advanced-topics" id="id15" name="id15">More advanced topics</a><ul>
+ <li><a class="reference" href="#hooks-and-environment-variables" id="id16" name="id16">Hooks and environment variables</a></li>
+ <li><a class="reference" href="#how-plugins-are-loaded" id="id17" name="id17">How plugins are loaded</a></li>
+ <li><a class="reference" href="#debugging" id="id18" name="id18">Debugging</a></li>
+ </ul>
+ </li>
+ </ul>
+ </div>
+ <div class="doc_author">
+ <p>Written by <a href="mailto:foldr at codedgers.com">Mikhail Glushenkov</a></p>
+ </div><div class="section">
+ <h1><a class="toc-backref" href="#id4" id="introduction" name="introduction">Introduction</a></h1>
+ <p>LLVMC is a generic compiler driver, designed to be customizable and
+ extensible. It plays the same role for LLVM as the <tt class="docutils literal"><span class="pre">gcc</span></tt> program
+ does for GCC - LLVMC's job is essentially to transform a set of input
+ files into a set of targets depending on configuration rules and user
+ options. What makes LLVMC different is that these transformation rules
+ are completely customizable - in fact, LLVMC knows nothing about the
+ specifics of transformation (even the command-line options are mostly
+ not hard-coded) and regards the transformation structure as an
+ abstract graph. The structure of this graph is completely determined
+ by plugins, which can be either statically or dynamically linked. This
+ makes it possible to easily adapt LLVMC for other purposes - for
+ example, as a build tool for game resources.</p>
+ <p>Because LLVMC employs <a class="reference" href="http://llvm.cs.uiuc.edu/docs/TableGenFundamentals.html">TableGen</a> as its configuration language, you
+ need to be familiar with it to customize LLVMC.</p>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id5" id="compiling-with-llvmc" name="compiling-with-llvmc">Compiling with LLVMC</a></h1>
+ <p>LLVMC tries hard to be as compatible with <tt class="docutils literal"><span class="pre">gcc</span></tt> as possible,
+ although there are some small differences. Most of the time, however,
+ you shouldn't be able to notice them:</p>
+ <pre class="literal-block">
+ $ # This works as expected:
+ $ llvmc -O3 -Wall hello.cpp
+ $ ./a.out
+ hello
+ </pre>
+ <p>One nice feature of LLVMC is that one doesn't have to distinguish
+ between different compilers for different languages (think <tt class="docutils literal"><span class="pre">g++</span></tt> and
+ <tt class="docutils literal"><span class="pre">gcc</span></tt>) - the right toolchain is chosen automatically based on input
+ language names (which are, in turn, determined from file
+ extensions). If you want to force files ending with ".c" to compile as
+ C++, use the <tt class="docutils literal"><span class="pre">-x</span></tt> option, just like you would do it with <tt class="docutils literal"><span class="pre">gcc</span></tt>:</p>
+ <pre class="literal-block">
+ $ # hello.c is really a C++ file
+ $ llvmc -x c++ hello.c
+ $ ./a.out
+ hello
+ </pre>
+ <p>On the other hand, when using LLVMC as a linker to combine several C++
+ object files you should provide the <tt class="docutils literal"><span class="pre">--linker</span></tt> option since it's
+ impossible for LLVMC to choose the right linker in that case:</p>
+ <pre class="literal-block">
+ $ llvmc -c hello.cpp
+ $ llvmc hello.o
+ [A lot of link-time errors skipped]
+ $ llvmc --linker=c++ hello.o
+ $ ./a.out
+ hello
+ </pre>
+ <p>By default, LLVMC uses <tt class="docutils literal"><span class="pre">llvm-gcc</span></tt> to compile the source code. It is
+ also possible to choose the work-in-progress <tt class="docutils literal"><span class="pre">clang</span></tt> compiler with
+ the <tt class="docutils literal"><span class="pre">-clang</span></tt> option.</p>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id6" id="predefined-options" name="predefined-options">Predefined options</a></h1>
+ <p>LLVMC has some built-in options that can't be overridden in the
+ configuration libraries:</p>
+ <ul class="simple">
+ <li><tt class="docutils literal"><span class="pre">-o</span> <span class="pre">FILE</span></tt> - Output file name.</li>
+ <li><tt class="docutils literal"><span class="pre">-x</span> <span class="pre">LANGUAGE</span></tt> - Specify the language of the following input files
+ until the next -x option.</li>
+ <li><tt class="docutils literal"><span class="pre">-load</span> <span class="pre">PLUGIN_NAME</span></tt> - Load the specified plugin DLL. Example:
+ <tt class="docutils literal"><span class="pre">-load</span> <span class="pre">$LLVM_DIR/Release/lib/LLVMCSimple.so</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">-v</span></tt> - Enable verbose mode, i.e. print out all executed commands.</li>
+ <li><tt class="docutils literal"><span class="pre">--check-graph</span></tt> - Check the compilation for common errors like
+ mismatched output/input language names, multiple default edges and
+ cycles. Hidden option, useful for debugging.</li>
+ <li><tt class="docutils literal"><span class="pre">--view-graph</span></tt> - Show a graphical representation of the compilation
+ graph. Requires that you have <tt class="docutils literal"><span class="pre">dot</span></tt> and <tt class="docutils literal"><span class="pre">gv</span></tt> programs
+ installed. Hidden option, useful for debugging.</li>
+ <li><tt class="docutils literal"><span class="pre">--write-graph</span></tt> - Write a <tt class="docutils literal"><span class="pre">compilation-graph.dot</span></tt> file in the
+ current directory with the compilation graph description in the
+ Graphviz format. Hidden option, useful for debugging.</li>
+ <li><tt class="docutils literal"><span class="pre">--save-temps</span></tt> - Write temporary files to the current directory
+ and do not delete them on exit. Hidden option, useful for debugging.</li>
+ <li><tt class="docutils literal"><span class="pre">--help</span></tt>, <tt class="docutils literal"><span class="pre">--help-hidden</span></tt>, <tt class="docutils literal"><span class="pre">--version</span></tt> - These options have
+ their standard meaning.</li>
+ </ul>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id7" id="compiling-llvmc-plugins" name="compiling-llvmc-plugins">Compiling LLVMC plugins</a></h1>
+ <p>It's easiest to start working on your own LLVMC plugin by copying the
+ skeleton project which lives under <tt class="docutils literal"><span class="pre">$LLVMC_DIR/plugins/Simple</span></tt>:</p>
+ <pre class="literal-block">
+ $ cd $LLVMC_DIR/plugins
+ $ cp -r Simple MyPlugin
+ $ cd MyPlugin
+ $ ls
+ Makefile PluginMain.cpp Simple.td
+ </pre>
+ <p>As you can see, our basic plugin consists of only two files (not
+ counting the build script). <tt class="docutils literal"><span class="pre">Simple.td</span></tt> contains TableGen
+ description of the compilation graph; its format is documented in the
+ following sections. <tt class="docutils literal"><span class="pre">PluginMain.cpp</span></tt> is just a helper file used to
+ compile the auto-generated C++ code produced from TableGen source. It
+ can also contain hook definitions (see <a class="reference" href="#hooks">below</a>).</p>
+ <p>The first thing that you should do is to change the <tt class="docutils literal"><span class="pre">LLVMC_PLUGIN</span></tt>
+ variable in the <tt class="docutils literal"><span class="pre">Makefile</span></tt> to avoid conflicts (since this variable
+ is used to name the resulting library):</p>
+ <pre class="literal-block">
+ LLVMC_PLUGIN=MyPlugin
+ </pre>
+ <p>It is also a good idea to rename <tt class="docutils literal"><span class="pre">Simple.td</span></tt> to something less
+ generic:</p>
+ <pre class="literal-block">
+ $ mv Simple.td MyPlugin.td
+ </pre>
+ <p>Note that the plugin source directory must be placed under
+ <tt class="docutils literal"><span class="pre">$LLVMC_DIR/plugins</span></tt> to make use of the existing build
+ infrastructure. To build a version of the LLVMC executable called
+ <tt class="docutils literal"><span class="pre">mydriver</span></tt> with your plugin compiled in, use the following command:</p>
+ <pre class="literal-block">
+ $ cd $LLVMC_DIR
+ $ make BUILTIN_PLUGINS=MyPlugin DRIVER_NAME=mydriver
+ </pre>
+ <p>To build your plugin as a dynamic library, just <tt class="docutils literal"><span class="pre">cd</span></tt> to its source
+ directory and run <tt class="docutils literal"><span class="pre">make</span></tt>. The resulting file will be called
+ <tt class="docutils literal"><span class="pre">LLVMC$(LLVMC_PLUGIN).$(DLL_EXTENSION)</span></tt> (in our case,
+ <tt class="docutils literal"><span class="pre">LLVMCMyPlugin.so</span></tt>). This library can be then loaded in with the
+ <tt class="docutils literal"><span class="pre">-load</span></tt> option. Example:</p>
+ <pre class="literal-block">
+ $ cd $LLVMC_DIR/plugins/Simple
+ $ make
+ $ llvmc -load $LLVM_DIR/Release/lib/LLVMCSimple.so
+ </pre>
+ <p>Sometimes, you will want a 'bare-bones' version of LLVMC that has no
+ built-in plugins. It can be compiled with the following command:</p>
+ <pre class="literal-block">
+ $ cd $LLVMC_DIR
+ $ make BUILTIN_PLUGINS=""
+ </pre>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id8" id="customizing-llvmc-the-compilation-graph" name="customizing-llvmc-the-compilation-graph">Customizing LLVMC: the compilation graph</a></h1>
+ <p>Each TableGen configuration file should include the common
+ definitions:</p>
+ <pre class="literal-block">
+ include "llvm/CompilerDriver/Common.td"
+ </pre>
+ <p>Internally, LLVMC stores information about possible source
+ transformations in form of a graph. Nodes in this graph represent
+ tools, and edges between two nodes represent a transformation path. A
+ special "root" node is used to mark entry points for the
+ transformations. LLVMC also assigns a weight to each edge (more on
+ this later) to choose between several alternative edges.</p>
+ <p>The definition of the compilation graph (see file
+ <tt class="docutils literal"><span class="pre">plugins/Base/Base.td</span></tt> for an example) is just a list of edges:</p>
+ <pre class="literal-block">
+ def CompilationGraph : CompilationGraph<[
+ Edge<"root", "llvm_gcc_c">,
+ Edge<"root", "llvm_gcc_assembler">,
+ ...
+
+ Edge<"llvm_gcc_c", "llc">,
+ Edge<"llvm_gcc_cpp", "llc">,
+ ...
+
+ OptionalEdge<"llvm_gcc_c", "opt", (case (switch_on "opt"),
+ (inc_weight))>,
+ OptionalEdge<"llvm_gcc_cpp", "opt", (case (switch_on "opt"),
+ (inc_weight))>,
+ ...
+
+ OptionalEdge<"llvm_gcc_assembler", "llvm_gcc_cpp_linker",
+ (case (input_languages_contain "c++"), (inc_weight),
+ (or (parameter_equals "linker", "g++"),
+ (parameter_equals "linker", "c++")), (inc_weight))>,
+ ...
+
+ ]>;
+ </pre>
+ <p>As you can see, the edges can be either default or optional, where
+ optional edges are differentiated by an additional <tt class="docutils literal"><span class="pre">case</span></tt> expression
+ used to calculate the weight of this edge. Notice also that we refer
+ to tools via their names (as strings). This makes it possible to add
+ edges to an existing compilation graph in plugins without having to
+ know about all tool definitions used in the graph.</p>
+ <p>The default edges are assigned a weight of 1, and optional edges get a
+ weight of 0 + 2*N where N is the number of tests that evaluated to
+ true in the <tt class="docutils literal"><span class="pre">case</span></tt> expression. It is also possible to provide an
+ integer parameter to <tt class="docutils literal"><span class="pre">inc_weight</span></tt> and <tt class="docutils literal"><span class="pre">dec_weight</span></tt> - in this case,
+ the weight is increased (or decreased) by the provided value instead
+ of the default 2. It is also possible to change the default weight of
+ an optional edge by using the <tt class="docutils literal"><span class="pre">default</span></tt> clause of the <tt class="docutils literal"><span class="pre">case</span></tt>
+ construct.</p>
+ <p>When passing an input file through the graph, LLVMC picks the edge
+ with the maximum weight. To avoid ambiguity, there should be only one
+ default edge between two nodes (with the exception of the root node,
+ which gets a special treatment - there you are allowed to specify one
+ default edge <em>per language</em>).</p>
+ <p>When multiple plugins are loaded, their compilation graphs are merged
+ together. Since multiple edges that have the same end nodes are not
+ allowed (i.e. the graph is not a multigraph), an edge defined in
+ several plugins will be replaced by the definition from the plugin
+ that was loaded last. Plugin load order can be controlled by using the
+ plugin priority feature described above.</p>
+ <p>To get a visual representation of the compilation graph (useful for
+ debugging), run <tt class="docutils literal"><span class="pre">llvmc</span> <span class="pre">--view-graph</span></tt>. You will need <tt class="docutils literal"><span class="pre">dot</span></tt> and
+ <tt class="docutils literal"><span class="pre">gsview</span></tt> installed for this to work properly.</p>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id9" id="describing-options" name="describing-options">Describing options</a></h1>
+ <p>Command-line options that the plugin supports are defined by using an
+ <tt class="docutils literal"><span class="pre">OptionList</span></tt>:</p>
+ <pre class="literal-block">
+ def Options : OptionList<[
+ (switch_option "E", (help "Help string")),
+ (alias_option "quiet", "q")
+ ...
+ ]>;
+ </pre>
+ <p>As you can see, the option list is just a list of DAGs, where each DAG
+ is an option description consisting of the option name and some
+ properties. A plugin can define more than one option list (they are
+ all merged together in the end), which can be handy if one wants to
+ separate option groups syntactically.</p>
+ <ul>
+ <li><p class="first">Possible option types:</p>
+ <blockquote>
+ <ul class="simple">
+ <li><tt class="docutils literal"><span class="pre">switch_option</span></tt> - a simple boolean switch without arguments, for example
+ <tt class="docutils literal"><span class="pre">-O2</span></tt> or <tt class="docutils literal"><span class="pre">-time</span></tt>. At most one occurrence is allowed.</li>
+ <li><tt class="docutils literal"><span class="pre">parameter_option</span></tt> - option that takes one argument, for example
+ <tt class="docutils literal"><span class="pre">-std=c99</span></tt>. It is also allowed to use spaces instead of the equality
+ sign: <tt class="docutils literal"><span class="pre">-std</span> <span class="pre">c99</span></tt>. At most one occurrence is allowed.</li>
+ <li><tt class="docutils literal"><span class="pre">parameter_list_option</span></tt> - same as the above, but more than one option
+ occurence is allowed.</li>
+ <li><tt class="docutils literal"><span class="pre">prefix_option</span></tt> - same as the parameter_option, but the option name and
+ argument do not have to be separated. Example: <tt class="docutils literal"><span class="pre">-ofile</span></tt>. This can be also
+ specified as <tt class="docutils literal"><span class="pre">-o</span> <span class="pre">file</span></tt>; however, <tt class="docutils literal"><span class="pre">-o=file</span></tt> will be parsed incorrectly
+ (<tt class="docutils literal"><span class="pre">=file</span></tt> will be interpreted as option value). At most one occurrence is
+ allowed.</li>
+ <li><tt class="docutils literal"><span class="pre">prefix_list_option</span></tt> - same as the above, but more than one occurence of
+ the option is allowed; example: <tt class="docutils literal"><span class="pre">-lm</span> <span class="pre">-lpthread</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">alias_option</span></tt> - a special option type for creating aliases. Unlike other
+ option types, aliases are not allowed to have any properties besides the
+ aliased option name. Usage example: <tt class="docutils literal"><span class="pre">(alias_option</span> <span class="pre">"preprocess",</span> <span class="pre">"E")</span></tt></li>
+ </ul>
+ </blockquote>
+ </li>
+ <li><p class="first">Possible option properties:</p>
+ <blockquote>
+ <ul class="simple">
+ <li><tt class="docutils literal"><span class="pre">help</span></tt> - help string associated with this option. Used for <tt class="docutils literal"><span class="pre">--help</span></tt>
+ output.</li>
+ <li><tt class="docutils literal"><span class="pre">required</span></tt> - this option must be specified exactly once (or, in case of
+ the list options without the <tt class="docutils literal"><span class="pre">multi_val</span></tt> property, at least
+ once). Incompatible with <tt class="docutils literal"><span class="pre">zero_or_one</span></tt> and <tt class="docutils literal"><span class="pre">one_or_more</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">one_or_more</span></tt> - the option must be specified at least one time. Useful
+ only for list options in conjunction with <tt class="docutils literal"><span class="pre">multi_val</span></tt>; for ordinary lists
+ it is synonymous with <tt class="docutils literal"><span class="pre">required</span></tt>. Incompatible with <tt class="docutils literal"><span class="pre">required</span></tt> and
+ <tt class="docutils literal"><span class="pre">zero_or_one</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">zero_or_one</span></tt> - the option can be specified zero or one times. Useful
+ only for list options in conjunction with <tt class="docutils literal"><span class="pre">multi_val</span></tt>. Incompatible with
+ <tt class="docutils literal"><span class="pre">required</span></tt> and <tt class="docutils literal"><span class="pre">one_or_more</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">hidden</span></tt> - the description of this option will not appear in
+ the <tt class="docutils literal"><span class="pre">--help</span></tt> output (but will appear in the <tt class="docutils literal"><span class="pre">--help-hidden</span></tt>
+ output).</li>
+ <li><tt class="docutils literal"><span class="pre">really_hidden</span></tt> - the option will not be mentioned in any help
+ output.</li>
+ <li><tt class="docutils literal"><span class="pre">multi_val</span> <span class="pre">n</span></tt> - this option takes <em>n</em> arguments (can be useful in some
+ special cases). Usage example: <tt class="docutils literal"><span class="pre">(parameter_list_option</span> <span class="pre">"foo",</span> <span class="pre">(multi_val</span>
+ <span class="pre">3))</span></tt>. Only list options can have this attribute; you can, however, use
+ the <tt class="docutils literal"><span class="pre">one_or_more</span></tt> and <tt class="docutils literal"><span class="pre">zero_or_one</span></tt> properties.</li>
+ <li><tt class="docutils literal"><span class="pre">extern</span></tt> - this option is defined in some other plugin, see below.</li>
+ </ul>
+ </blockquote>
+ </li>
+ </ul>
+ <div class="section">
+ <h2><a class="toc-backref" href="#id10" id="external-options" name="external-options">External options</a></h2>
+ <p>Sometimes, when linking several plugins together, one plugin needs to
+ access options defined in some other plugin. Because of the way
+ options are implemented, such options must be marked as
+ <tt class="docutils literal"><span class="pre">extern</span></tt>. This is what the <tt class="docutils literal"><span class="pre">extern</span></tt> option property is
+ for. Example:</p>
+ <pre class="literal-block">
+ ...
+ (switch_option "E", (extern))
+ ...
+ </pre>
+ <p>See also the section on plugin <a class="reference" href="#priorities">priorities</a>.</p>
+ </div>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id11" id="conditional-evaluation" name="conditional-evaluation"><span id="case"></span>Conditional evaluation</a></h1>
+ <p>The 'case' construct is the main means by which programmability is
+ achieved in LLVMC. It can be used to calculate edge weights, program
+ actions and modify the shell commands to be executed. The 'case'
+ expression is designed after the similarly-named construct in
+ functional languages and takes the form <tt class="docutils literal"><span class="pre">(case</span> <span class="pre">(test_1),</span> <span class="pre">statement_1,</span>
+ <span class="pre">(test_2),</span> <span class="pre">statement_2,</span> <span class="pre">...</span> <span class="pre">(test_N),</span> <span class="pre">statement_N)</span></tt>. The statements
+ are evaluated only if the corresponding tests evaluate to true.</p>
+ <p>Examples:</p>
+ <pre class="literal-block">
+ // Edge weight calculation
+
+ // Increases edge weight by 5 if "-A" is provided on the
+ // command-line, and by 5 more if "-B" is also provided.
+ (case
+ (switch_on "A"), (inc_weight 5),
+ (switch_on "B"), (inc_weight 5))
+
+
+ // Tool command line specification
+
+ // Evaluates to "cmdline1" if the option "-A" is provided on the
+ // command line; to "cmdline2" if "-B" is provided;
+ // otherwise to "cmdline3".
+
+ (case
+ (switch_on "A"), "cmdline1",
+ (switch_on "B"), "cmdline2",
+ (default), "cmdline3")
+ </pre>
+ <p>Note the slight difference in 'case' expression handling in contexts
+ of edge weights and command line specification - in the second example
+ the value of the <tt class="docutils literal"><span class="pre">"B"</span></tt> switch is never checked when switch <tt class="docutils literal"><span class="pre">"A"</span></tt> is
+ enabled, and the whole expression always evaluates to <tt class="docutils literal"><span class="pre">"cmdline1"</span></tt> in
+ that case.</p>
+ <p>Case expressions can also be nested, i.e. the following is legal:</p>
+ <pre class="literal-block">
+ (case (switch_on "E"), (case (switch_on "o"), ..., (default), ...)
+ (default), ...)
+ </pre>
+ <p>You should, however, try to avoid doing that because it hurts
+ readability. It is usually better to split tool descriptions and/or
+ use TableGen inheritance instead.</p>
+ <ul class="simple">
+ <li>Possible tests are:<ul>
+ <li><tt class="docutils literal"><span class="pre">switch_on</span></tt> - Returns true if a given command-line switch is
+ provided by the user. Example: <tt class="docutils literal"><span class="pre">(switch_on</span> <span class="pre">"opt")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">parameter_equals</span></tt> - Returns true if a command-line parameter equals
+ a given value.
+ Example: <tt class="docutils literal"><span class="pre">(parameter_equals</span> <span class="pre">"W",</span> <span class="pre">"all")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">element_in_list</span></tt> - Returns true if a command-line parameter
+ list contains a given value.
+ Example: <tt class="docutils literal"><span class="pre">(parameter_in_list</span> <span class="pre">"l",</span> <span class="pre">"pthread")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">input_languages_contain</span></tt> - Returns true if a given language
+ belongs to the current input language set.
+ Example: <tt class="docutils literal"><span class="pre">(input_languages_contain</span> <span class="pre">"c++")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">in_language</span></tt> - Evaluates to true if the input file language
+ equals to the argument. At the moment works only with <tt class="docutils literal"><span class="pre">cmd_line</span></tt>
+ and <tt class="docutils literal"><span class="pre">actions</span></tt> (on non-join nodes).
+ Example: <tt class="docutils literal"><span class="pre">(in_language</span> <span class="pre">"c++")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">not_empty</span></tt> - Returns true if a given option (which should be
+ either a parameter or a parameter list) is set by the
+ user.
+ Example: <tt class="docutils literal"><span class="pre">(not_empty</span> <span class="pre">"o")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">empty</span></tt> - The opposite of <tt class="docutils literal"><span class="pre">not_empty</span></tt>. Equivalent to <tt class="docutils literal"><span class="pre">(not</span> <span class="pre">(not_empty</span>
+ <span class="pre">X))</span></tt>. Provided for convenience.</li>
+ <li><tt class="docutils literal"><span class="pre">default</span></tt> - Always evaluates to true. Should always be the last
+ test in the <tt class="docutils literal"><span class="pre">case</span></tt> expression.</li>
+ <li><tt class="docutils literal"><span class="pre">and</span></tt> - A standard logical combinator that returns true iff all
+ of its arguments return true. Used like this: <tt class="docutils literal"><span class="pre">(and</span> <span class="pre">(test1),</span>
+ <span class="pre">(test2),</span> <span class="pre">...</span> <span class="pre">(testN))</span></tt>. Nesting of <tt class="docutils literal"><span class="pre">and</span></tt> and <tt class="docutils literal"><span class="pre">or</span></tt> is allowed,
+ but not encouraged.</li>
+ <li><tt class="docutils literal"><span class="pre">or</span></tt> - Another logical combinator that returns true only if any
+ one of its arguments returns true. Example: <tt class="docutils literal"><span class="pre">(or</span> <span class="pre">(test1),</span>
+ <span class="pre">(test2),</span> <span class="pre">...</span> <span class="pre">(testN))</span></tt>.</li>
+ </ul>
+ </li>
+ </ul>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id12" id="writing-a-tool-description" name="writing-a-tool-description">Writing a tool description</a></h1>
+ <p>As was said earlier, nodes in the compilation graph represent tools,
+ which are described separately. A tool definition looks like this
+ (taken from the <tt class="docutils literal"><span class="pre">include/llvm/CompilerDriver/Tools.td</span></tt> file):</p>
+ <pre class="literal-block">
+ def llvm_gcc_cpp : Tool<[
+ (in_language "c++"),
+ (out_language "llvm-assembler"),
+ (output_suffix "bc"),
+ (cmd_line "llvm-g++ -c $INFILE -o $OUTFILE -emit-llvm"),
+ (sink)
+ ]>;
+ </pre>
+ <p>This defines a new tool called <tt class="docutils literal"><span class="pre">llvm_gcc_cpp</span></tt>, which is an alias for
+ <tt class="docutils literal"><span class="pre">llvm-g++</span></tt>. As you can see, a tool definition is just a list of
+ properties; most of them should be self-explanatory. The <tt class="docutils literal"><span class="pre">sink</span></tt>
+ property means that this tool should be passed all command-line
+ options that aren't mentioned in the option list.</p>
+ <p>The complete list of all currently implemented tool properties follows.</p>
+ <ul class="simple">
+ <li>Possible tool properties:<ul>
+ <li><tt class="docutils literal"><span class="pre">in_language</span></tt> - input language name. Can be either a string or a
+ list, in case the tool supports multiple input languages.</li>
+ <li><tt class="docutils literal"><span class="pre">out_language</span></tt> - output language name. Tools are not allowed to
+ have multiple output languages.</li>
+ <li><tt class="docutils literal"><span class="pre">output_suffix</span></tt> - output file suffix. Can also be changed
+ dynamically, see documentation on actions.</li>
+ <li><tt class="docutils literal"><span class="pre">cmd_line</span></tt> - the actual command used to run the tool. You can
+ use <tt class="docutils literal"><span class="pre">$INFILE</span></tt> and <tt class="docutils literal"><span class="pre">$OUTFILE</span></tt> variables, output redirection
+ with <tt class="docutils literal"><span class="pre">></span></tt>, hook invocations (<tt class="docutils literal"><span class="pre">$CALL</span></tt>), environment variables
+ (via <tt class="docutils literal"><span class="pre">$ENV</span></tt>) and the <tt class="docutils literal"><span class="pre">case</span></tt> construct.</li>
+ <li><tt class="docutils literal"><span class="pre">join</span></tt> - this tool is a "join node" in the graph, i.e. it gets a
+ list of input files and joins them together. Used for linkers.</li>
+ <li><tt class="docutils literal"><span class="pre">sink</span></tt> - all command-line options that are not handled by other
+ tools are passed to this tool.</li>
+ <li><tt class="docutils literal"><span class="pre">actions</span></tt> - A single big <tt class="docutils literal"><span class="pre">case</span></tt> expression that specifies how
+ this tool reacts on command-line options (described in more detail
+ below).</li>
+ </ul>
+ </li>
+ </ul>
+ <div class="section">
+ <h2><a class="toc-backref" href="#id13" id="actions" name="actions">Actions</a></h2>
+ <p>A tool often needs to react to command-line options, and this is
+ precisely what the <tt class="docutils literal"><span class="pre">actions</span></tt> property is for. The next example
+ illustrates this feature:</p>
+ <pre class="literal-block">
+ def llvm_gcc_linker : Tool<[
+ (in_language "object-code"),
+ (out_language "executable"),
+ (output_suffix "out"),
+ (cmd_line "llvm-gcc $INFILE -o $OUTFILE"),
+ (join),
+ (actions (case (not_empty "L"), (forward "L"),
+ (not_empty "l"), (forward "l"),
+ (not_empty "dummy"),
+ [(append_cmd "-dummy1"), (append_cmd "-dummy2")])
+ ]>;
+ </pre>
+ <p>The <tt class="docutils literal"><span class="pre">actions</span></tt> tool property is implemented on top of the omnipresent
+ <tt class="docutils literal"><span class="pre">case</span></tt> expression. It associates one or more different <em>actions</em>
+ with given conditions - in the example, the actions are <tt class="docutils literal"><span class="pre">forward</span></tt>,
+ which forwards a given option unchanged, and <tt class="docutils literal"><span class="pre">append_cmd</span></tt>, which
+ appends a given string to the tool execution command. Multiple actions
+ can be associated with a single condition by using a list of actions
+ (used in the example to append some dummy options). The same <tt class="docutils literal"><span class="pre">case</span></tt>
+ construct can also be used in the <tt class="docutils literal"><span class="pre">cmd_line</span></tt> property to modify the
+ tool command line.</p>
+ <p>The "join" property used in the example means that this tool behaves
+ like a linker.</p>
+ <p>The list of all possible actions follows.</p>
+ <ul>
+ <li><p class="first">Possible actions:</p>
+ <blockquote>
+ <ul class="simple">
+ <li><tt class="docutils literal"><span class="pre">append_cmd</span></tt> - append a string to the tool invocation
+ command.
+ Example: <tt class="docutils literal"><span class="pre">(case</span> <span class="pre">(switch_on</span> <span class="pre">"pthread"),</span> <span class="pre">(append_cmd</span>
+ <span class="pre">"-lpthread"))</span></tt></li>
+ <li><tt class="docutils literal"><span class="pre">error`</span> <span class="pre">-</span> <span class="pre">exit</span> <span class="pre">with</span> <span class="pre">error.</span>
+ <span class="pre">Example:</span> <span class="pre">``(error</span> <span class="pre">"Mixing</span> <span class="pre">-c</span> <span class="pre">and</span> <span class="pre">-S</span> <span class="pre">is</span> <span class="pre">not</span> <span class="pre">allowed!")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">forward</span></tt> - forward an option unchanged.
+ Example: <tt class="docutils literal"><span class="pre">(forward</span> <span class="pre">"Wall")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">forward_as</span></tt> - Change the name of an option, but forward the
+ argument unchanged.
+ Example: <tt class="docutils literal"><span class="pre">(forward_as</span> <span class="pre">"O0"</span> <span class="pre">"--disable-optimization")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">output_suffix</span></tt> - modify the output suffix of this
+ tool.
+ Example: <tt class="docutils literal"><span class="pre">(output_suffix</span> <span class="pre">"i")</span></tt>.</li>
+ <li><tt class="docutils literal"><span class="pre">stop_compilation</span></tt> - stop compilation after this tool processes
+ its input. Used without arguments.</li>
+ <li><tt class="docutils literal"><span class="pre">unpack_values</span></tt> - used for for splitting and forwarding
+ comma-separated lists of options, e.g. <tt class="docutils literal"><span class="pre">-Wa,-foo=bar,-baz</span></tt> is
+ converted to <tt class="docutils literal"><span class="pre">-foo=bar</span> <span class="pre">-baz</span></tt> and appended to the tool invocation
+ command.
+ Example: <tt class="docutils literal"><span class="pre">(unpack_values</span> <span class="pre">"Wa,")</span></tt>.</li>
+ </ul>
+ </blockquote>
+ </li>
+ </ul>
+ </div>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id14" id="language-map" name="language-map">Language map</a></h1>
+ <p>If you are adding support for a new language to LLVMC, you'll need to
+ modify the language map, which defines mappings from file extensions
+ to language names. It is used to choose the proper toolchain(s) for a
+ given input file set. Language map definition looks like this:</p>
+ <pre class="literal-block">
+ def LanguageMap : LanguageMap<
+ [LangToSuffixes<"c++", ["cc", "cp", "cxx", "cpp", "CPP", "c++", "C"]>,
+ LangToSuffixes<"c", ["c"]>,
+ ...
+ ]>;
+ </pre>
+ <p>For example, without those definitions the following command wouldn't work:</p>
+ <pre class="literal-block">
+ $ llvmc hello.cpp
+ llvmc: Unknown suffix: cpp
+ </pre>
+ <p>The language map entries should be added only for tools that are
+ linked with the root node. Since tools are not allowed to have
+ multiple output languages, for nodes "inside" the graph the input and
+ output languages should match. This is enforced at compile-time.</p>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id15" id="more-advanced-topics" name="more-advanced-topics">More advanced topics</a></h1>
+ <div class="section">
+ <h2><a class="toc-backref" href="#id16" id="hooks-and-environment-variables" name="hooks-and-environment-variables"><span id="hooks"></span>Hooks and environment variables</a></h2>
+ <p>Normally, LLVMC executes programs from the system <tt class="docutils literal"><span class="pre">PATH</span></tt>. Sometimes,
+ this is not sufficient: for example, we may want to specify tool paths
+ or names in the configuration file. This can be easily achieved via
+ the hooks mechanism. To write your own hooks, just add their
+ definitions to the <tt class="docutils literal"><span class="pre">PluginMain.cpp</span></tt> or drop a <tt class="docutils literal"><span class="pre">.cpp</span></tt> file into the
+ your plugin directory. Hooks should live in the <tt class="docutils literal"><span class="pre">hooks</span></tt> namespace
+ and have the signature <tt class="docutils literal"><span class="pre">std::string</span> <span class="pre">hooks::MyHookName</span> <span class="pre">([const</span> <span class="pre">char*</span>
+ <span class="pre">Arg0</span> <span class="pre">[</span> <span class="pre">const</span> <span class="pre">char*</span> <span class="pre">Arg2</span> <span class="pre">[,</span> <span class="pre">...]]])</span></tt>. They can be used from the
+ <tt class="docutils literal"><span class="pre">cmd_line</span></tt> tool property:</p>
+ <pre class="literal-block">
+ (cmd_line "$CALL(MyHook)/path/to/file -o $CALL(AnotherHook)")
+ </pre>
+ <p>To pass arguments to hooks, use the following syntax:</p>
+ <pre class="literal-block">
+ (cmd_line "$CALL(MyHook, 'Arg1', 'Arg2', 'Arg # 3')/path/to/file -o1 -o2")
+ </pre>
+ <p>It is also possible to use environment variables in the same manner:</p>
+ <pre class="literal-block">
+ (cmd_line "$ENV(VAR1)/path/to/file -o $ENV(VAR2)")
+ </pre>
+ <p>To change the command line string based on user-provided options use
+ the <tt class="docutils literal"><span class="pre">case</span></tt> expression (documented <a class="reference" href="#case">above</a>):</p>
+ <pre class="literal-block">
+ (cmd_line
+ (case
+ (switch_on "E"),
+ "llvm-g++ -E -x c $INFILE -o $OUTFILE",
+ (default),
+ "llvm-g++ -c -x c $INFILE -o $OUTFILE -emit-llvm"))
+ </pre>
+ </div>
+ <div class="section">
+ <h2><a class="toc-backref" href="#id17" id="how-plugins-are-loaded" name="how-plugins-are-loaded"><span id="priorities"></span>How plugins are loaded</a></h2>
+ <p>It is possible for LLVMC plugins to depend on each other. For example,
+ one can create edges between nodes defined in some other plugin. To
+ make this work, however, that plugin should be loaded first. To
+ achieve this, the concept of plugin priority was introduced. By
+ default, every plugin has priority zero; to specify the priority
+ explicitly, put the following line in your plugin's TableGen file:</p>
+ <pre class="literal-block">
+ def Priority : PluginPriority<$PRIORITY_VALUE>;
+ # Where PRIORITY_VALUE is some integer > 0
+ </pre>
+ <p>Plugins are loaded in order of their (increasing) priority, starting
+ with 0. Therefore, the plugin with the highest priority value will be
+ loaded last.</p>
+ </div>
+ <div class="section">
+ <h2><a class="toc-backref" href="#id18" id="debugging" name="debugging">Debugging</a></h2>
+ <p>When writing LLVMC plugins, it can be useful to get a visual view of
+ the resulting compilation graph. This can be achieved via the command
+ line option <tt class="docutils literal"><span class="pre">--view-graph</span></tt>. This command assumes that <a class="reference" href="http://www.graphviz.org/">Graphviz</a> and
+ <a class="reference" href="http://pages.cs.wisc.edu/~ghost/">Ghostview</a> are installed. There is also a <tt class="docutils literal"><span class="pre">--dump-graph</span></tt> option that
+ creates a Graphviz source file (<tt class="docutils literal"><span class="pre">compilation-graph.dot</span></tt>) in the
+ current directory.</p>
+ <p>Another useful <tt class="docutils literal"><span class="pre">llvmc</span></tt> option is <tt class="docutils literal"><span class="pre">--check-graph</span></tt>. It checks the
+ compilation graph for common errors like mismatched output/input
+ language names, multiple default edges and cycles. These checks can't
+ be performed at compile-time because the plugins can load code
+ dynamically. When invoked with <tt class="docutils literal"><span class="pre">--check-graph</span></tt>, <tt class="docutils literal"><span class="pre">llvmc</span></tt> doesn't
+ perform any compilation tasks and returns the number of encountered
+ errors as its status code.</p>
+ <hr />
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer">
+ <img src="http://jigsaw.w3.org/css-validator/images/vcss-blue"
+ alt="Valid CSS" /></a>
+ <a href="http://validator.w3.org/check?uri=referer">
+ <img src="http://www.w3.org/Icons/valid-xhtml10-blue"
+ alt="Valid XHTML 1.0 Transitional"/></a>
+
+ <a href="mailto:foldr at codedgers.com">Mikhail Glushenkov</a><br />
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br />
+
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address></div>
+ </div>
+ </div>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CompilerDriverTutorial.html
diff -c /dev/null llvm-www/releases/2.5/docs/CompilerDriverTutorial.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CompilerDriverTutorial.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,120 ----
+ <?xml version="1.0" encoding="utf-8" ?>
+ <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <meta name="generator" content="Docutils 0.4.1: http://docutils.sourceforge.net/" />
+ <title>Tutorial - Using LLVMC</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css" />
+ </head>
+ <body>
+ <div class="document" id="tutorial-using-llvmc">
+ <h1 class="title">Tutorial - Using LLVMC</h1>
+ <!-- This file was automatically generated by rst2html.
+ Please do not edit directly!
+ The ReST source lives in the directory 'tools/llvmc/doc'. -->
+ <div class="contents topic">
+ <p class="topic-title first"><a id="contents" name="contents">Contents</a></p>
+ <ul class="simple">
+ <li><a class="reference" href="#introduction" id="id1" name="id1">Introduction</a></li>
+ <li><a class="reference" href="#compiling-with-llvmc" id="id2" name="id2">Compiling with LLVMC</a></li>
+ <li><a class="reference" href="#using-llvmc-to-generate-toolchain-drivers" id="id3" name="id3">Using LLVMC to generate toolchain drivers</a></li>
+ </ul>
+ </div>
+ <div class="doc_author">
+ <p>Written by <a href="mailto:foldr at codedgers.com">Mikhail Glushenkov</a></p>
+ </div><div class="section">
+ <h1><a class="toc-backref" href="#id1" id="introduction" name="introduction">Introduction</a></h1>
+ <p>LLVMC is a generic compiler driver, which plays the same role for LLVM
+ as the <tt class="docutils literal"><span class="pre">gcc</span></tt> program does for GCC - the difference being that LLVMC
+ is designed to be more adaptable and easier to customize. Most of
+ LLVMC functionality is implemented via plugins, which can be loaded
+ dynamically or compiled in. This tutorial describes the basic usage
+ and configuration of LLVMC.</p>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id2" id="compiling-with-llvmc" name="compiling-with-llvmc">Compiling with LLVMC</a></h1>
+ <p>In general, LLVMC tries to be command-line compatible with <tt class="docutils literal"><span class="pre">gcc</span></tt> as
+ much as possible, so most of the familiar options work:</p>
+ <pre class="literal-block">
+ $ llvmc -O3 -Wall hello.cpp
+ $ ./a.out
+ hello
+ </pre>
+ <p>This will invoke <tt class="docutils literal"><span class="pre">llvm-g++</span></tt> under the hood (you can see which
+ commands are executed by using the <tt class="docutils literal"><span class="pre">-v</span></tt> option). For further help on
+ command-line LLVMC usage, refer to the <tt class="docutils literal"><span class="pre">llvmc</span> <span class="pre">--help</span></tt> output.</p>
+ </div>
+ <div class="section">
+ <h1><a class="toc-backref" href="#id3" id="using-llvmc-to-generate-toolchain-drivers" name="using-llvmc-to-generate-toolchain-drivers">Using LLVMC to generate toolchain drivers</a></h1>
+ <p>LLVMC plugins are written mostly using <a class="reference" href="http://llvm.cs.uiuc.edu/docs/TableGenFundamentals.html">TableGen</a>, so you need to
+ be familiar with it to get anything done.</p>
+ <p>Start by compiling <tt class="docutils literal"><span class="pre">plugins/Simple/Simple.td</span></tt>, which is a primitive
+ wrapper for <tt class="docutils literal"><span class="pre">gcc</span></tt>:</p>
+ <pre class="literal-block">
+ $ cd $LLVM_DIR/tools/llvmc
+ $ make DRIVER_NAME=mygcc BUILTIN_PLUGINS=Simple
+ $ cat > hello.c
+ [...]
+ $ mygcc hello.c
+ $ ./hello.out
+ Hello
+ </pre>
+ <p>Here we link our plugin with the LLVMC core statically to form an
+ executable file called <tt class="docutils literal"><span class="pre">mygcc</span></tt>. It is also possible to build our
+ plugin as a standalone dynamic library; this is described in the
+ reference manual.</p>
+ <p>Contents of the file <tt class="docutils literal"><span class="pre">Simple.td</span></tt> look like this:</p>
+ <pre class="literal-block">
+ // Include common definitions
+ include "llvm/CompilerDriver/Common.td"
+
+ // Tool descriptions
+ def gcc : Tool<
+ [(in_language "c"),
+ (out_language "executable"),
+ (output_suffix "out"),
+ (cmd_line "gcc $INFILE -o $OUTFILE"),
+ (sink)
+ ]>;
+
+ // Language map
+ def LanguageMap : LanguageMap<[LangToSuffixes<"c", ["c"]>]>;
+
+ // Compilation graph
+ def CompilationGraph : CompilationGraph<[Edge<"root", "gcc">]>;
+ </pre>
+ <p>As you can see, this file consists of three parts: tool descriptions,
+ language map, and the compilation graph definition.</p>
+ <p>At the heart of LLVMC is the idea of a compilation graph: vertices in
+ this graph are tools, and edges represent a transformation path
+ between two tools (for example, assembly source produced by the
+ compiler can be transformed into executable code by an assembler). The
+ compilation graph is basically a list of edges; a special node named
+ <tt class="docutils literal"><span class="pre">root</span></tt> is used to mark graph entry points.</p>
+ <p>Tool descriptions are represented as property lists: most properties
+ in the example above should be self-explanatory; the <tt class="docutils literal"><span class="pre">sink</span></tt> property
+ means that all options lacking an explicit description should be
+ forwarded to this tool.</p>
+ <p>The <tt class="docutils literal"><span class="pre">LanguageMap</span></tt> associates a language name with a list of suffixes
+ and is used for deciding which toolchain corresponds to a given input
+ file.</p>
+ <p>To learn more about LLVMC customization, refer to the reference
+ manual and plugin source code in the <tt class="docutils literal"><span class="pre">plugins</span></tt> directory.</p>
+ <hr />
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer">
+ <img src="http://jigsaw.w3.org/css-validator/images/vcss-blue"
+ alt="Valid CSS" /></a>
+ <a href="http://validator.w3.org/check?uri=referer">
+ <img src="http://www.w3.org/Icons/valid-xhtml10-blue"
+ alt="Valid XHTML 1.0 Transitional"/></a>
+
+ <a href="mailto:foldr at codedgers.com">Mikhail Glushenkov</a><br />
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br />
+
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address></div>
+ </div>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/CompilerWriterInfo.html
diff -c /dev/null llvm-www/releases/2.5/docs/CompilerWriterInfo.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/CompilerWriterInfo.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,263 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>Architecture/platform information for compiler writers</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <body>
+
+ <div class="doc_title">
+ Architecture/platform information for compiler writers
+ </div>
+
+ <div class="doc_warning">
+ <p>Note: This document is a work-in-progress. Additions and clarifications
+ are welcome.</p>
+ </div>
+
+ <ol>
+ <li><a href="#hw">Hardware</a>
+ <ol>
+ <li><a href="#alpha">Alpha</a></li>
+ <li><a href="#arm">ARM</a></li>
+ <li><a href="#ia64">Itanium</a></li>
+ <li><a href="#mips">MIPS</a></li>
+ <li><a href="#ppc">PowerPC</a></li>
+ <li><a href="#sparc">SPARC</a></li>
+ <li><a href="#x86">X86</a></li>
+ <li><a href="#other">Other lists</a></li>
+ </ol></li>
+ <li><a href="#abi">Application Binary Interface (ABI)</a>
+ <ol>
+ <li><a href="#linux">Linux</a></li>
+ <li><a href="#osx">OS X</a></li>
+ </ol></li>
+ <li><a href="#misc">Miscellaneous resources</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Compiled by <a href="http://misha.brukman.net">Misha Brukman</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="hw">Hardware</a></div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="alpha">Alpha</a></div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a
+ href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-library.html">Alpha manuals</a>
+ </li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="arm">ARM</a></div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a href="http://www.arm.com/documentation/">ARM documentation</a>
+ (<a href="http://www.arm.com/documentation/ARMProcessor_Cores/">Processor
+ Cores</a>)</li>
+ <li><a href="http://www.arm.com/products/DevTools/ABI.html">ABI</a></li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="ia64">Itanium (ia64)</a></div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a
+ href="http://developer.intel.com/design/itanium2/documentation.htm">Itanium documentation</a>
+ </li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="mips">MIPS</a></div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a
+ href="http://mips.com/content/Documentation/MIPSDocumentation/ProcessorArchitecture/doclibrary">MIPS
+ Processor Architecture</a></li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="ppc">PowerPC</a></div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">IBM - Official manuals and docs</div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><a
+ href="http://www-106.ibm.com/developerworks/eserver/articles/archguide.html">PowerPC
+ Architecture Book</a>
+ <ul>
+ <li>Book I: <a
+ href="http://www-106.ibm.com/developerworks/eserver/pdfs/archpub1.pdf">PowerPC
+ User Instruction Set Architecture</a></li>
+ <li>Book II: <a
+ href="http://www-106.ibm.com/developerworks/eserver/pdfs/archpub2.pdf">PowerPC
+ Virtual Environment Architecture</a></li>
+ <li>Book III: <a
+ href="http://www-106.ibm.com/developerworks/eserver/pdfs/archpub3.pdf">PowerPC
+ Operating Environment Architecture</a></li>
+ </ul></li>
+ <li><a
+ href="http://www-3.ibm.com/chips/techlib/techlib.nsf/techdocs/852569B20050FF7785256996007558C6">PowerPC
+ Compiler Writer's Guide</a></li>
+ <li><A
+ href="http://www-3.ibm.com/chips/techlib/techlib.nsf/products/PowerPC">PowerPC
+ Processor Manuals</a></li>
+ <li><a
+ href="http://www-106.ibm.com/developerworks/linux/library/l-powarch/">Intro to
+ PowerPC architecture</a></li>
+ <li><a href="http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixassem/alangref/alangreftfrm.htm">IBM AIX/5L for POWER Assembly reference</a></li>
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">Other documents, collections, notes</div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><a href="http://penguinppc.org/dev/#library">PowerPC ABI documents</a></li>
+ <li><a href="http://gcc.gnu.org/ml/gcc-patches/2003-09/msg00997.html">PowerPC64
+ alignment of long doubles (from GCC)</a></li>
+ <li><a href="http://sources.redhat.com/ml/binutils/2002-04/msg00573.html">Long
+ branch stubs for powerpc64-linux (from binutils)</a></li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="sparc">SPARC</a></div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><a href="http://www.sparc.org/resource.htm">SPARC resources</a></li>
+ <li><a href="http://www.sparc.org/standards.html">SPARC standards</a></li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="x86">X86</a></div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">AMD - Official manuals and docs</div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a
+ href="http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.html">AMD processor manuals</a></li>
+ <li><a href="http://www.x86-64.org/documentation">X86-64 ABI</a></li>
+ </ul>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">Intel - Official manuals and docs</div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a
+ href="http://developer.intel.com/design/pentium4/manuals/index_new.htm">IA-32
+ manuals</a></li>
+ <li><a
+ href="http://www.intel.com/design/itanium/documentation.htm?iid=ipp_srvr_proc_itanium2+techdocs">Intel
+ Itanium documentation</a></li>
+ </ul>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">Other x86-specific information</div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a href="http://www.agner.org/assem/calling_conventions.pdf">Calling
+ conventions for different C++ compilers and operating systems</a></li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="other">Other relevant lists</a></div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><a href="http://gcc.gnu.org/readings.html">GCC reading list</a></li>
+ </ul>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="abi">ABI</a></div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="linux">Linux</a></div>
+
+ <div class="doc_text">
+ <ol>
+ <li><a href="http://www.linuxbase.org/spec/ELF/ppc64/">PowerPC 64-bit ELF ABI
+ Supplement</a></li>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="osx">OS X</a></div>
+
+ <div class="doc_text">
+ <ol>
+ <li><a
+ href="http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html">Mach-O
+ Runtime Architecture</a></li>
+ <li><a href="http://www.unsanity.org/archives/000044.php">Notes on Mach-O
+ ABI</a></li>
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="misc">Miscellaneous resources</a></div>
+ <!-- *********************************************************************** -->
+
+ <ul>
+ <li><a
+ href="http://www.nondot.org/sabre/os/articles/ExecutableFileFormats/">Executable
+ File Format library</a></li>
+ <li><a href="http://gcc.gnu.org/projects/prefetch.html">GCC prefetch project</a>
+ page has a good survey of the prefetching capabilities of a variety of modern
+ processors.</li>
+ </ul>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://misha.brukman.net">Misha Brukman</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/DeveloperPolicy.html
diff -c /dev/null llvm-www/releases/2.5/docs/DeveloperPolicy.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/DeveloperPolicy.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,573 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM Developer Policy</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">LLVM Developer Policy</div>
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#policies">Developer Policies</a>
+ <ol>
+ <li><a href="#informed">Stay Informed</a></li>
+ <li><a href="#patches">Making a Patch</a></li>
+ <li><a href="#reviews">Code Reviews</a></li>
+ <li><a href="#owners">Code Owners</a></li>
+ <li><a href="#testcases">Test Cases</a></li>
+ <li><a href="#quality">Quality</a></li>
+ <li><a href="#commitaccess">Obtaining Commit Access</a></li>
+ <li><a href="#newwork">Making a Major Change</a></li>
+ <li><a href="#incremental">Incremental Development</a></li>
+ <li><a href="#attribution">Attribution of Changes</a></li>
+ </ol></li>
+ <li><a href="#clp">Copyright, License, and Patents</a>
+ <ol>
+ <li><a href="#copyright">Copyright</a></li>
+ <li><a href="#license">License</a></li>
+ <li><a href="#patents">Patents</a></li>
+ <li><a href="#devagree">Developer Agreements</a></li>
+ </ol></li>
+ </ol>
+ <div class="doc_author">Written by the LLVM Oversight Team</div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="introduction">Introduction</a></div>
+ <!--=========================================================================-->
+ <div class="doc_text">
+ <p>This document contains the LLVM Developer Policy which defines the
+ project's policy towards developers and their contributions. The intent of
+ this policy is to eliminate mis-communication, rework, and confusion that
+ might arise from the distributed nature of LLVM's development. By stating
+ the policy in clear terms, we hope each developer can know ahead of time
+ what to expect when making LLVM contributions.</p>
+ <p>This policy is also designed to accomplish the following objectives:</p>
+ <ol>
+ <li>Attract both users and developers to the LLVM project.</li>
+ <li>Make life as simple and easy for contributors as possible.</li>
+ <li>Keep the top of Subversion trees as stable as possible.</li>
+ </ol>
+
+ <p>This policy is aimed at frequent contributors to LLVM. People interested in
+ contributing one-off patches can do so in an informal way by sending them to
+ the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
+ llvm-commits mailing list</a> and engaging another developer to see it through
+ the process.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="policies">Developer Policies</a></div>
+ <!--=========================================================================-->
+ <div class="doc_text">
+ <p>This section contains policies that pertain to frequent LLVM
+ developers. We always welcome <a href="#patches">one-off patches</a> from
+ people who do not routinely contribute to LLVM, but we expect more from
+ frequent contributors to keep the system as efficient as possible for
+ everyone.
+ Frequent LLVM contributors are expected to meet the following requirements in
+ order for LLVM to maintain a high standard of quality.<p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="informed">Stay Informed</a> </div>
+ <div class="doc_text">
+ <p>Developers should stay informed by reading at least the
+ <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a>
+ email list. If you are doing anything more than just casual work on LLVM,
+ it is suggested that you also subscribe to the
+ <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">llvm-commits</a>
+ list and pay attention to changes being made by others.</p>
+ <p>We recommend that active developers register an email account with
+ <a href="http://llvm.org/bugs/">LLVM Bugzilla</a> and preferably subscribe to
+ the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs">llvm-bugs</a>
+ email list to keep track of bugs and enhancements occurring in LLVM.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="patches">Making a Patch</a></div>
+
+ <div class="doc_text">
+
+ <p>When making a patch for review, the goal is to make it as easy for the
+ reviewer to read it as possible. As such, we recommend that you:</p>
+ <ol>
+ <li>Make your patch against the Subversion trunk, not a branch, and not an
+ old version of LLVM. This makes it easy to apply the patch.</li>
+
+ <li>Similarly, patches should be submitted soon after they are generated.
+ Old patches may not apply correctly if the underlying code changes between
+ the time the patch was created and the time it is applied.</li>
+
+ <li>Patches should be made with this command:
+ <div class="doc_code"><pre>svn diff -x -u</pre></div>
+ or with the utility <tt>utils/mkpatch</tt>, which makes it easy to read the
+ diff.</li>
+
+ <li>Patches should not include differences in generated code such as the
+ code generated by <tt>autoconf</tt> or <tt>tblgen</tt>. The
+ <tt>utils/mkpatch</tt> utility takes care of this for you.</li>
+ </ol>
+
+ <p>When sending a patch to a mailing list, it is a good idea to send it as an
+ <em>attachment</em> to the message, not embedded into the text of the
+ message. This ensures that your mailer will not mangle the patch when it
+ sends it (e.g. by making whitespace changes or by wrapping lines).</p>
+
+ <p><em>For Thunderbird users:</em> Before submitting a patch, please open
+ <em>Preferences → Advanced → General → Config Editor</em>,
+ find the key <tt>mail.content_disposition_type</tt>, and set its value to
+ <tt>1</tt>. Without this setting, Thunderbird sends your attachment using
+ <tt>Content-Disposition: inline</tt> rather than <tt>Content-Disposition:
+ attachment</tt>. Apple Mail gamely displays such a file inline, making it
+ difficult to work with for reviewers using that program.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="reviews">Code Reviews</a></div>
+ <div class="doc_text">
+ <p>LLVM has a code review policy. Code review is one way to increase the
+ quality of software. We generally follow these policies:</p>
+ <ol>
+ <li>All developers are required to have significant changes reviewed
+ before they are committed to the repository.</li>
+ <li>Code reviews are conducted by email, usually on the llvm-commits
+ list.</li>
+ <li>Code can be reviewed either before it is committed or after. We expect
+ major changes to be reviewed before being committed, but smaller
+ changes (or changes where the developer owns the component) can be
+ reviewed after commit.</li>
+ <li>The developer responsible for a code change is also responsible for
+ making all necessary review-related changes.</li>
+ <li>Code review can be an iterative process, which continues until the patch
+ is ready to be committed.</li>
+ </ol>
+
+ <p>Developers should participate in code reviews as both reviewers and
+ reviewees. If someone is kind enough to review your code, you should
+ return the favor for someone else. Note that anyone is welcome to review
+ and give feedback on a patch, but only people with Subversion write access
+ can approve it.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="owners">Code Owners</a></div>
+ <div class="doc_text">
+
+ <p>The LLVM Project relies on two features of its process to maintain rapid
+ development in addition to the high quality of its source base: the
+ combination of code review plus post-commit review for trusted maintainers.
+ Having both is a great way for the project to take advantage of the fact
+ that most people do the right thing most of the time, and only commit
+ patches without pre-commit review when they are confident they are
+ right.</p>
+
+ <p>The trick to this is that the project has to guarantee that all patches
+ that are committed are reviewed after they go in: you don't want everyone
+ to assume someone else will review it, allowing the patch to go unreviewed.
+ To solve this problem, we have a notion of an 'owner' for a piece of the
+ code. The sole responsibility of a code owner is to ensure that a commit
+ to their area of the code is appropriately reviewed, either by themself or
+ by someone else. The current code owners are:</p>
+
+ <ol>
+ <li><b>Anton Korobeynikov</b>: Exception handling, debug information, and
+ Windows codegen.</li>
+ <li><b>Duncan Sands</b>: llvm-gcc 4.2.</li>
+ <li><b>Evan Cheng</b>: Code generator and all targets.</li>
+ <li><b>Chris Lattner</b>: Everything else.</li>
+ </ol>
+
+ <p>Note that code ownership is completely different than reviewers: anyone can
+ review a piece of code, and we welcome code review from anyone who is
+ interested. Code owners are the "last line of defense" to guarantee that
+ all patches that are committed are actually reviewed.</p>
+
+ <p>Being a code owner is a somewhat unglamorous position, but it is incredibly
+ important for the ongoing success of the project. Because people get busy,
+ interests change, and unexpected things happen, code ownership is purely
+ opt-in, and anyone can choose to resign their "title" at any time. For now,
+ we do not have an official policy on how one gets elected to be a code
+ owner.
+ </p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="testcases">Test Cases</a></div>
+ <div class="doc_text">
+ <p>Developers are required to create test cases for any bugs fixed and any new
+ features added. Some tips for getting your testcase approved:</p>
+ <ol>
+ <li>All feature and regression test cases are added to the
+ <tt>llvm/test</tt> directory. The appropriate sub-directory should be
+ selected (see the <a href="TestingGuide.html">Testing Guide</a> for
+ details).</li>
+ <li>Test cases should be written in
+ <a href="LangRef.html">LLVM assembly language</a> unless the
+ feature or regression being tested requires another language (e.g. the
+ bug being fixed or feature being implemented is in the llvm-gcc C++
+ front-end, in which case it must be written in C++).</li>
+ <li>Test cases, especially for regressions, should be reduced as much as
+ possible, by <a href="Bugpoint.html">bugpoint</a> or
+ manually. It is unacceptable
+ to place an entire failing program into <tt>llvm/test</tt> as this creates
+ a <i>time-to-test</i> burden on all developers. Please keep them short.</li>
+ </ol>
+
+ <p>Note that llvm/test is designed for regression and small feature tests
+ only. More extensive test cases (e.g., entire applications, benchmarks,
+ etc) should be added to the <tt>llvm-test</tt> test suite. The llvm-test
+ suite is for coverage (correctness, performance, etc) testing, not feature
+ or regression testing.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="quality">Quality</a></div>
+ <div class="doc_text">
+ <p>The minimum quality standards that any change must satisfy before being
+ committed to the main development branch are:</p>
+ <ol>
+ <li>Code must adhere to the
+ <a href="CodingStandards.html">LLVM Coding Standards</a>.</li>
+ <li>Code must compile cleanly (no errors, no warnings) on at least one
+ platform.</li>
+ <li>Bug fixes and new features should <a href="#testcases">include a
+ testcase</a> so we know if the fix/feature ever regresses in the
+ future.</li>
+ <li>Code must pass the dejagnu (<tt>llvm/test</tt>) test suite.</li>
+ <li>The code must not cause regressions on a reasonable subset of llvm-test,
+ where "reasonable" depends on the contributor's judgement and the scope
+ of the change (more invasive changes require more testing). A reasonable
+ subset might be something like
+ "<tt>llvm-test/MultiSource/Benchmarks</tt>".</li>
+ </ol>
+ <p>Additionally, the committer is responsible for addressing any problems
+ found in the future that the change is responsible for. For example:</p>
+ <ul>
+ <li>The code should compile cleanly on all supported platforms.</li>
+ <li>The changes should not cause any correctness regressions in the
+ <tt>llvm-test</tt> suite and must not cause any major performance
+ regressions.</li>
+ <li>The change set should not cause performance or correctness regressions
+ for the LLVM tools.</li>
+ <li>The changes should not cause performance or correctness regressions in
+ code compiled by LLVM on all applicable targets.</li>
+ <li>You are expected to address any <a href="http://llvm.org/bugs/">bugzilla
+ bugs</a> that result from your change.</li>
+ </ul>
+
+ <p>We prefer for this to be handled before submission but understand that it
+ isn't possible to test all of this for every submission. Our nightly
+ testing
+ infrastructure normally finds these problems. A good rule of thumb is to
+ check the nightly testers for regressions the day after your change.</p>
+
+ <p>Commits that violate these quality standards (e.g. are very broken) may
+ be reverted. This is necessary when the change blocks other developers from
+ making progress. The developer is welcome to re-commit the change after
+ the problem has been fixed.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="commitaccess">Obtaining Commit Access</a></div>
+ <div class="doc_text">
+
+ <p>
+ We grant commit access to contributors with a track record of submitting high
+ quality patches. If you would like commit access, please send an email to
+ <a href="mailto:sabre at nondot.org">Chris</a> with the following information:</p>
+
+ <ol>
+ <li>The user name you want to commit with, e.g. "sabre".</li>
+ <li>The full name and email address you want message to llvm-commits to come
+ from, e.g. "Chris Lattner <sabre at nondot.org>".</li>
+ <li>A "password hash" of the password you want to use, e.g. "2ACR96qjUqsyM".
+ Note that you don't ever tell us what your password is, you just give it
+ to us in an encrypted form. To get this, run "htpasswd" (a utility that
+ comes with apache) in crypt mode (often enabled with "-d"), or find a web
+ page that will do it for you.</li>
+ </ol>
+
+ <p>Once you've been granted commit access, you should be able to check out an
+ LLVM tree with an SVN URL of "https://username@llvm.org/..." instead of the
+ normal anonymous URL of "http://llvm.org/...". The first time you commit
+ you'll have to type in your password. Note that you may get a warning from
+ SVN about an untrusted key, you can ignore this. To verify that your commit
+ access works, please do a test commit (e.g. change a comment or add a blank
+ line). Your first commit to a repository may require the autogenerated email
+ to be approved by a mailing list. This is normal, and will be done when
+ the mailing list owner has time.</p>
+
+ <p>If you have recently been granted commit access, these policies apply:</p>
+
+ <ol>
+ <li>You are granted <i>commit-after-approval</i> to all parts of LLVM.
+ To get approval, submit a <a href="#patches">patch</a> to
+ <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">
+ llvm-commits</a>. When approved you may commit it yourself.</li>
+ <li>You are allowed to commit patches without approval which you think are
+ obvious. This is clearly a subjective decision — we simply expect you
+ to use good judgement. Examples include: fixing build breakage, reverting
+ obviously broken patches, documentation/comment changes, any other minor
+ changes.</li>
+ <li>You are allowed to commit patches without approval to those portions
+ of LLVM that you have contributed or maintain (i.e., have been assigned
+ responsibility for), with the proviso that such commits must not break the
+ build. This is a "trust but verify" policy and commits of this nature are
+ reviewed after they are committed.</li>
+ <li>Multiple violations of these policies or a single egregious violation
+ may cause commit access to be revoked.</li>
+ </ol>
+
+ <p>In any case, your changes are still subject to <a href="#reviews">code
+ review</a> (either before or after they are committed, depending on the nature
+ of the change). You are encouraged to review other peoples' patches as well,
+ but you aren't required to.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="newwork">Making a Major Change</a></div>
+ <div class="doc_text">
+ <p>When a developer begins a major new project with the aim of contributing
+ it back to LLVM, s/he should inform the community with an email to
+ the <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">llvmdev</a>
+ email list, to the extent possible. The reason for this is to:
+ <ol>
+ <li>keep the community informed about future changes to LLVM, </li>
+ <li>avoid duplication of effort by preventing multiple parties working on
+ the same thing and not knowing about it, and</li>
+ <li>ensure that any technical issues around the proposed work are
+ discussed and resolved before any significant work is done.</li>
+ </ol>
+
+ <p>The design of LLVM is carefully controlled to ensure that all the pieces
+ fit together well and are as consistent as possible. If you plan to make a
+ major change to the way LLVM works or want to add a major new extension, it
+ is a good idea to get consensus with the development
+ community before you start working on it.</p>
+
+ <p>Once the design of the new feature is finalized, the work itself should be
+ done as a series of <a href="#incremental">incremental changes</a>, not as
+ a long-term development branch.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"> <a name="incremental">Incremental Development</a>
+ </div>
+ <div class="doc_text">
+ <p>In the LLVM project, we do all significant changes as a series of
+ incremental patches. We have a strong dislike for huge changes or
+ long-term development branches. Long-term development branches have a
+ number of drawbacks:</p>
+
+ <ol>
+ <li>Branches must have mainline merged into them periodically. If the branch
+ development and mainline development occur in the same pieces of code,
+ resolving merge conflicts can take a lot of time.</li>
+ <li>Other people in the community tend to ignore work on branches.</li>
+ <li>Huge changes (produced when a branch is merged back onto mainline) are
+ extremely difficult to <a href="#reviews">code review</a>.</li>
+ <li>Branches are not routinely tested by our nightly tester
+ infrastructure.</li>
+ <li>Changes developed as monolithic large changes often don't work until the
+ entire set of changes is done. Breaking it down into a set of smaller
+ changes increases the odds that any of the work will be committed to the
+ main repository.</li>
+ </ol>
+
+ <p>
+ To address these problems, LLVM uses an incremental development style and we
+ require contributors to follow this practice when making a large/invasive
+ change. Some tips:</p>
+
+ <ul>
+ <li>Large/invasive changes usually have a number of secondary changes that
+ are required before the big change can be made (e.g. API cleanup, etc).
+ These sorts of changes can often be done before the major change is done,
+ independently of that work.</li>
+ <li>The remaining inter-related work should be decomposed into unrelated
+ sets of changes if possible. Once this is done, define the first increment
+ and get consensus on what the end goal of the change is.</li>
+
+ <li>Each change in the set can be stand alone (e.g. to fix a bug), or part
+ of a planned series of changes that works towards the development goal.</li>
+
+ <li>Each change should be kept as small as possible. This simplifies your
+ work (into a logical progression), simplifies code review and reduces the
+ chance that you will get negative feedback on the change. Small increments
+ also facilitate the maintenance of a high quality code base.</li>
+
+ <li>Often, an independent precursor to a big change is to add a new API and
+ slowly migrate clients to use the new API. Each change to use the new
+ API is often "obvious" and can be committed without review. Once the
+ new API is in place and used, it is much easier to replace the
+ underlying implementation of the API. This implementation change is
+ logically separate from the API change.</li>
+ </ul>
+
+ <p>If you are interested in making a large change, and this scares you, please
+ make sure to first <a href="#newwork">discuss the change/gather
+ consensus</a> then ask about the best way to go about making
+ the change.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="attribution">Attribution of
+ Changes</a></div>
+ <div class="doc_text">
+ <p>We believe in correct attribution of contributions to
+ their contributors. However, we do not want the source code to be littered
+ with random attributions "this code written by J Random Guy" (this is noisy
+ and distracting). In practice, the revision control system keeps a perfect
+ history of who changed what, and the CREDITS.txt file describes higher-level
+ contributions. If you commit a patch for someone else, please say "patch
+ contributed by J Random Guy!" in the commit message.</p>
+
+ <p>Overall, please do not add contributor names to the source code.</p>
+ </div>
+
+
+
+ <!--=========================================================================-->
+ <div class="doc_section">
+ <a name="clp">Copyright, License, and Patents</a>
+ </div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+ <p>This section addresses the issues of copyright, license and patents for
+ the LLVM project.
+ Currently, the University of Illinois is the LLVM copyright holder and the
+ terms of its license to LLVM users and developers is the
+ <a href="http://www.opensource.org/licenses/UoI-NCSA.php">University of
+ Illinois/NCSA Open Source License</a>.</p>
+
+ <div class="doc_notes">
+ <p style="text-align:center;font-weight:bold">NOTE: This section
+ deals with legal matters but does not provide legal advice. We are not
+ lawyers, please seek legal counsel from an attorney.</p>
+ </div>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="copyright">Copyright</a></div>
+ <div class="doc_text">
+ <p>
+ <p>For consistency and ease of management, the project requires the
+ copyright for all LLVM software to be held by a single copyright holder:
+ the University of Illinois (UIUC).</p>
+
+ <p>
+ Although UIUC may eventually reassign the copyright of the software to another
+ entity (e.g. a dedicated non-profit "LLVM Organization")
+ the intent for the project is to always have a single entity hold the
+ copyrights to LLVM at any given time.</p>
+
+ <p>We believe that having a single copyright
+ holder is in the best interests of all developers and users as it greatly
+ reduces the managerial burden for any kind of administrative or technical
+ decisions about LLVM. The goal of the LLVM project is to always keep the code
+ open and <a href="#license">licensed under a very liberal license</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="license">License</a></div>
+ <div class="doc_text">
+ <p>We intend to keep LLVM perpetually open source
+ and to use a liberal open source license. The current license is the
+ <a href="http://www.opensource.org/licenses/UoI-NCSA.php">
+ University of Illinois/NCSA Open Source License</a>, which boils
+ down to this:</p>
+ <ul>
+ <li>You can freely distribute LLVM.</li>
+ <li>You must retain the copyright notice if you redistribute LLVM.</li>
+ <li>Binaries derived from LLVM must reproduce the copyright notice (e.g.
+ in an included readme file).</li>
+ <li>You can't use our names to promote your LLVM derived products.</li>
+ <li>There's no warranty on LLVM at all.</li>
+ </ul>
+
+ <p>We believe this fosters the widest adoption of LLVM because it <b>allows
+ commercial products to be derived from LLVM</b> with few restrictions and
+ without a requirement for making any derived works also open source (i.e.
+ LLVM's license is not a "copyleft" license like the GPL). We suggest that you
+ read the <a href="http://www.opensource.org/licenses/UoI-NCSA.php">License</a>
+ if further clarification is needed.</p>
+
+ <p>Note that the LLVM Project does distribute llvm-gcc, <b>which is GPL.</b>
+ This means that anything "linked" into llvm-gcc must itself be compatible
+ with the GPL, and must be releasable under the terms of the GPL. This implies
+ that <b>any code linked into llvm-gcc and distributed to others may be subject
+ to the viral aspects of the GPL</b> (for example, a proprietary code generator
+ linked into llvm-gcc must be made available under the GPL). This is not a
+ problem for code already distributed under a more liberal license (like the
+ UIUC license), and does not affect code generated by llvm-gcc. It may be a
+ problem if you intend to base commercial development on llvm-gcc without
+ redistributing your source code.</p>
+
+ <p>We have no plans to change the license of LLVM. If you have questions
+ or comments about the license, please contact the <a
+ href="mailto:llvm-oversight at cs.uiuc.edu">LLVM Oversight Group</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="patents">Patents</a></div>
+ <div class="doc_text">
+
+ <p>To the best of our knowledge, LLVM does not infringe on any patents (we have
+ actually removed code from LLVM in the past that was found to infringe).
+ Having code in LLVM that infringes on patents would violate an important
+ goal of the project by making it hard or impossible to reuse the code for
+ arbitrary purposes (including commercial use).</p>
+
+ <p>When contributing code, we expect contributors to notify us of any potential
+ for patent-related trouble with their changes. If you or your employer
+ own the rights to a
+ patent and would like to contribute code to LLVM that relies on it, we
+ require that
+ the copyright owner sign an agreement that allows any other user of LLVM to
+ freely use your patent. Please contact the <a
+ href="mailto:llvm-oversight at cs.uiuc.edu">oversight group</a> for more
+ details.</p>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="devagree">Developer Agreements</a></div>
+ <div class="doc_text">
+ <p>With regards to the LLVM copyright and licensing, developers agree to
+ assign their copyrights to UIUC for any contribution made so that
+ the entire software base can be managed by a single copyright holder. This
+ implies that any contributions can be licensed under the license that the
+ project uses.</p>
+
+ <p>When contributing code, you also affirm that you are legally entitled to
+ grant this copyright, personally or on behalf of your employer. If the code
+ belongs to some other entity, please raise this issue with the oversight
+ group before the code is committed.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+ Written by the
+ <a href="mailto:llvm-oversight at cs.uiuc.edu">LLVM Oversight Group</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/ExceptionHandling.html
diff -c /dev/null llvm-www/releases/2.5/docs/ExceptionHandling.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/ExceptionHandling.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,479 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Exception Handling in LLVM</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">Exception Handling in LLVM</div>
+
+ <table class="layout" style="width:100%">
+ <tr class="layout">
+ <td class="left">
+ <ul>
+ <li><a href="#introduction">Introduction</a>
+ <ol>
+ <li><a href="#itanium">Itanium ABI Zero-cost Exception Handling</a></li>
+ <li><a href="#overview">Overview</a></li>
+ </ol></li>
+ <li><a href="#codegen">LLVM Code Generation</a>
+ <ol>
+ <li><a href="#throw">Throw</a></li>
+ <li><a href="#try_catch">Try/Catch</a></li>
+ <li><a href="#cleanups">Cleanups</a></li>
+ <li><a href="#throw_filters">Throw Filters</a></li>
+ <li><a href="#restrictions">Restrictions</a></li>
+ </ol></li>
+ <li><a href="#format_common_intrinsics">Exception Handling Intrinsics</a>
+ <ol>
+ <li><a href="#llvm_eh_exception"><tt>llvm.eh.exception</tt></a></li>
+ <li><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a></li>
+ <li><a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a></li>
+ </ol></li>
+ <li><a href="#asm">Asm Table Formats</a>
+ <ol>
+ <li><a href="#unwind_tables">Exception Handling Frame</a></li>
+ <li><a href="#exception_tables">Exception Tables</a></li>
+ </ol></li>
+ <li><a href="#todo">ToDo</a></li>
+ </ul>
+ </td>
+ </tr></table>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:jlaskey at mac.com">Jim Laskey</a></p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="introduction">Introduction</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document is the central repository for all information pertaining to
+ exception handling in LLVM. It describes the format that LLVM exception
+ handling information takes, which is useful for those interested in creating
+ front-ends or dealing directly with the information. Further, this document
+ provides specific examples of what exception handling information is used for
+ C/C++.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="itanium">Itanium ABI Zero-cost Exception Handling</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Exception handling for most programming languages is designed to recover from
+ conditions that rarely occur during general use of an application. To that end,
+ exception handling should not interfere with the main flow of an
+ application's algorithm by performing checkpointing tasks such as saving
+ the current pc or register state.</p>
+
+ <p>The Itanium ABI Exception Handling Specification defines a methodology for
+ providing outlying data in the form of exception tables without inlining
+ speculative exception handling code in the flow of an application's main
+ algorithm. Thus, the specification is said to add "zero-cost" to the normal
+ execution of an application.</p>
+
+ <p>A more complete description of the Itanium ABI exception handling runtime
+ support of can be found at <a
+ href="http://www.codesourcery.com/cxx-abi/abi-eh.html">Itanium C++ ABI:
+ Exception Handling.</a> A description of the exception frame format can be found
+ at <a href="http://refspecs.freestandards.org/LSB_3.0.0/LSB-Core-generic/LSB-
+ Core-generic/ehframechpt.html">Exception Frames</a>, with details of the Dwarf
+ specification at <a href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3
+ Standard.</a> A description for the C++ exception table formats can be found at
+ <a href="http://www.codesourcery.com/cxx-abi/exceptions.pdf">Exception Handling
+ Tables.</a></p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="overview">Overview</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>When an exception is thrown in llvm code, the runtime does a best effort to
+ find a handler suited to process the circumstance.</p>
+
+ <p>The runtime first attempts to find an <i>exception frame</i> corresponding to
+ the function where the exception was thrown. If the programming language (ex.
+ C++) supports exception handling, the exception frame contains a reference to an
+ exception table describing how to process the exception. If the language (ex.
+ C) does not support exception handling or if the exception needs to be forwarded
+ to a prior activation, the exception frame contains information about how to
+ unwind the current activation and restore the state of the prior activation.
+ This process is repeated until the exception is handled. If the exception is
+ not handled and no activations remain, then the application is terminated with
+ an appropriate error message.</p>
+
+ <p>Since different programming languages have different behaviors when handling
+ exceptions, the exception handling ABI provides a mechanism for supplying
+ <i>personalities.</i> An exception handling personality is defined by way of a
+ <i>personality function</i> (ex. for C++ <tt>__gxx_personality_v0</tt>) which
+ receives the context of the exception, an <i>exception structure</i> containing
+ the exception object type and value, and a reference to the exception table for
+ the current function. The personality function for the current compile unit is
+ specified in a <i>common exception frame</i>.</p>
+
+ <p>The organization of an exception table is language dependent. For C++, an
+ exception table is organized as a series of code ranges defining what to do if
+ an exception occurs in that range. Typically, the information associated with a
+ range defines which types of exception objects (using C++ <i>type info</i>) that
+ are handled in that range, and an associated action that should take place.
+ Actions typically pass control to a <i>landing pad</i>.</p>
+
+ <p>A landing pad corresponds to the code found in the catch portion of a
+ try/catch sequence. When execution resumes at a landing pad, it receives the
+ exception structure and a selector corresponding to the <i>type</i> of exception
+ thrown. The selector is then used to determine which catch should actually
+ process the exception.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section">
+ <a name="codegen">LLVM Code Generation</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>At the time of this writing, only C++ exception handling support is available
+ in LLVM. So the remainder of this document will be somewhat C++-centric.</p>
+
+ <p>From the C++ developers perspective, exceptions are defined in terms of the
+ <tt>throw</tt> and <tt>try/catch</tt> statements. In this section we will
+ describe the implementation of llvm exception handling in terms of C++
+ examples.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="throw">Throw</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Languages that support exception handling typically provide a <tt>throw</tt>
+ operation to initiate the exception process. Internally, a throw operation
+ breaks down into two steps. First, a request is made to allocate exception
+ space for an exception structure. This structure needs to survive beyond the
+ current activation. This structure will contain the type and value of the
+ object being thrown. Second, a call is made to the runtime to raise the
+ exception, passing the exception structure as an argument.</p>
+
+ <p>In C++, the allocation of the exception structure is done by the
+ <tt>__cxa_allocate_exception</tt> runtime function. The exception raising is
+ handled by <tt>__cxa_throw</tt>. The type of the exception is represented using
+ a C++ RTTI type info structure.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="try_catch">Try/Catch</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>A call within the scope of a try statement can potentially raise an exception.
+ In those circumstances, the LLVM C++ front-end replaces the call with an
+ <tt>invoke</tt> instruction. Unlike a call, the invoke has two potential
+ continuation points; where to continue when the call succeeds as per normal, and
+ where to continue if the call raises an exception, either by a throw or the
+ unwinding of a throw.</p>
+
+ <p>The term used to define a the place where an invoke continues after an
+ exception is called a <i>landing pad</i>. LLVM landing pads are conceptually
+ alternative function entry points where a exception structure reference and a type
+ info index are passed in as arguments. The landing pad saves the exception
+ structure reference and then proceeds to select the catch block that corresponds
+ to the type info of the exception object.</p>
+
+ <p>Two llvm intrinsic functions are used convey information about the landing
+ pad to the back end.</p>
+
+ <p><a href="#llvm_eh_exception"><tt>llvm.eh.exception</tt></a> takes no
+ arguments and returns a pointer to the exception structure. This only returns a
+ sensible value if called after an invoke has branched to a landing pad. Due to
+ codegen limitations, it must currently be called in the landing pad itself.</p>
+
+ <p><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> takes a minimum of
+ three arguments. The first argument is the reference to the exception
+ structure. The second argument is a reference to the personality function to be
+ used for this try catch sequence. Each of the remaining arguments is either a
+ reference to the type info for a catch statement,
+ a <a href="#throw_filters">filter</a> expression,
+ or the number zero representing a <a href="#cleanups">cleanup</a>.
+ The exception is tested against the arguments sequentially from first to last.
+ The result of the <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> is a
+ positive number if the exception matched a type info, a negative number if it matched
+ a filter, and zero if it matched a cleanup. If nothing is matched, the behaviour of
+ the program is <a href="#restrictions">undefined</a>.
+ This only returns a sensible value if called after an invoke has branched to a
+ landing pad. Due to codegen limitations, it must currently be called in the
+ landing pad itself.
+ If a type info matched then the selector value is the index of the type info in
+ the exception table, which can be obtained using the
+ <a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic.</p>
+
+ <p>Once the landing pad has the type info selector, the code branches to the
+ code for the first catch. The catch then checks the value of the type info
+ selector against the index of type info for that catch. Since the type info
+ index is not known until all the type info have been gathered in the backend,
+ the catch code will call the <a
+ href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic to
+ determine the index for a given type info. If the catch fails to match the
+ selector then control is passed on to the next catch. Note: Since the landing
+ pad will not be used if there is no match in the list of type info on the call
+ to <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>, then neither the
+ last catch nor <i>catch all</i> need to perform the the check against the
+ selector.</p>
+
+ <p>Finally, the entry and exit of catch code is bracketed with calls to
+ <tt>__cxa_begin_catch</tt> and <tt>__cxa_end_catch</tt>.
+ <tt>__cxa_begin_catch</tt> takes a exception structure reference as an argument
+ and returns the value of the exception object. <tt>__cxa_end_catch</tt>
+ takes a exception structure reference as an argument. This function clears the
+ exception from the exception space. Note: a rethrow from within the catch may
+ replace this call with a <tt>__cxa_rethrow</tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="cleanups">Cleanups</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>To handle destructors and cleanups in try code, control may not run directly
+ from a landing pad to the first catch. Control may actually flow from the
+ landing pad to clean up code and then to the first catch. Since the required
+ clean up for each invoke in a try may be different (ex., intervening
+ constructor), there may be several landing pads for a given try. If cleanups
+ need to be run, the number zero should be passed as the last
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> argument.
+ However for C++ a <tt>null i8*</tt> <a href="#restrictions">must</a> be passed
+ instead.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="throw_filters">Throw Filters</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>C++ allows the specification of which exception types can be thrown from
+ a function. To represent this a top level landing pad may exist to filter out
+ invalid types. To express this in LLVM code the landing pad will call <a
+ href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>. The arguments are a
+ reference to the exception structure, a reference to the personality function,
+ the length of the filter expression (the number of type infos plus one),
+ followed by the type infos themselves.
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> will return a negative
+ value if the exception does not match any of the type infos. If no match is
+ found then a call to <tt>__cxa_call_unexpected</tt> should be made, otherwise
+ <tt>_Unwind_Resume</tt>. Each of these functions requires a reference to the
+ exception structure. Note that the most general form of an
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> call can contain
+ any number of type infos, filter expressions and cleanups (though having more
+ than one cleanup is pointless). The LLVM C++ front-end can generate such
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> calls due to inlining
+ creating nested exception handling scopes.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="restrictions">Restrictions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The semantics of the invoke instruction require that any exception that
+ unwinds through an invoke call should result in a branch to the invoke's unwind
+ label. However such a branch will only happen if the
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> matches.
+ Thus in order to ensure correct operation, the front-end must only generate
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> calls that are
+ guaranteed to always match whatever exception unwinds through the invoke.
+ For most languages it is enough to pass zero, indicating the presence of
+ a <a href="#cleanups">cleanup</a>, as the last
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> argument.
+ However for C++ this is not sufficient, because the C++ personality function
+ will terminate the program if it detects that unwinding the exception only
+ results in matches with cleanups. For C++ a <tt>null i8*</tt> should
+ be passed as the last
+ <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> argument instead.
+ This is interpreted as a catch-all by the C++ personality function, and will
+ always match.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section">
+ <a name="format_common_intrinsics">Exception Handling Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM uses several intrinsic functions (name prefixed with "llvm.eh") to
+ provide exception handling information at various points in generated code.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="llvm_eh_exception">llvm.eh.exception</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ i8* %<a href="#llvm_eh_exception">llvm.eh.exception</a>( )
+ </pre>
+
+ <p>This intrinsic returns a pointer to the exception structure.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="llvm_eh_selector">llvm.eh.selector</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ i32 %<a href="#llvm_eh_selector">llvm.eh.selector.i32</a>(i8*, i8*, i8*, ...)
+ i64 %<a href="#llvm_eh_selector">llvm.eh.selector.i64</a>(i8*, i8*, i8*, ...)
+ </pre>
+
+ <p>This intrinsic is used to compare the exception with the given type infos,
+ filters and cleanups.</p>
+
+ <p><a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> takes a minimum of
+ three arguments. The first argument is the reference to the exception
+ structure. The second argument is a reference to the personality function to be
+ used for this try catch sequence. Each of the remaining arguments is either a
+ reference to the type info for a catch statement,
+ a <a href="#throw_filters">filter</a> expression,
+ or the number zero representing a <a href="#cleanups">cleanup</a>.
+ The exception is tested against the arguments sequentially from first to last.
+ The result of the <a href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a> is a
+ positive number if the exception matched a type info, a negative number if it matched
+ a filter, and zero if it matched a cleanup. If nothing is matched, the behaviour of
+ the program is <a href="#restrictions">undefined</a>.
+ If a type info matched then the selector value is the index of the type info in
+ the exception table, which can be obtained using the
+ <a href="#llvm_eh_typeid_for"><tt>llvm.eh.typeid.for</tt></a> intrinsic.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="llvm_eh_typeid_for">llvm.eh.typeid.for</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ i32 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for.i32</a>(i8*)
+ i64 %<a href="#llvm_eh_typeid_for">llvm.eh.typeid.for.i64</a>(i8*)
+ </pre>
+
+ <p>This intrinsic returns the type info index in the exception table of the
+ current function. This value can be used to compare against the result of <a
+ href="#llvm_eh_selector"><tt>llvm.eh.selector</tt></a>. The single argument is
+ a reference to a type info.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section">
+ <a name="asm">Asm Table Formats</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>There are two tables that are used by the exception handling runtime to
+ determine which actions should take place when an exception is thrown.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="unwind_tables">Exception Handling Frame</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>An exception handling frame <tt>eh_frame</tt> is very similar to the unwind
+ frame used by dwarf debug info. The frame contains all the information
+ necessary to tear down the current frame and restore the state of the prior
+ frame. There is an exception handling frame for each function in a compile
+ unit, plus a common exception handling frame that defines information common to
+ all functions in the unit.</p>
+
+ <p>Todo - Table details here.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="exception_tables">Exception Tables</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>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 exception table per function except leaf routines and functions that have
+ only calls to non-throwing functions will not need an exception table.</p>
+
+ <p>Todo - Table details here.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section">
+ <a name="todo">ToDo</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ol>
+
+ <li><p>Testing/Testing/Testing.</p></li>
+
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/ExtendingLLVM.html
diff -c /dev/null llvm-www/releases/2.5/docs/ExtendingLLVM.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/ExtendingLLVM.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,391 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Extending LLVM: Adding instructions, intrinsics, types, etc.</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <body>
+
+ <div class="doc_title">
+ Extending LLVM: Adding instructions, intrinsics, types, etc.
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction and Warning</a></li>
+ <li><a href="#intrinsic">Adding a new intrinsic function</a></li>
+ <li><a href="#instruction">Adding a new instruction</a></li>
+ <li><a href="#sdnode">Adding a new SelectionDAG node</a></li>
+ <li><a href="#type">Adding a new type</a>
+ <ol>
+ <li><a href="#fund_type">Adding a new fundamental type</a></li>
+ <li><a href="#derived_type">Adding a new derived type</a></li>
+ </ol></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="http://misha.brukman.net">Misha Brukman</a>,
+ Brad Jones, Nate Begeman,
+ and <a href="http://nondot.org/sabre">Chris Lattner</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction and Warning</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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
+ you need to add something to LLVM, whether it be a new fundamental type, a new
+ intrinsic function, or a whole new instruction.</p>
+
+ <p>When you come to this realization, stop and think. Do you really need to
+ extend LLVM? Is it a new fundamental capability that LLVM does not support at
+ its current incarnation or can it be synthesized from already pre-existing LLVM
+ elements? If you are not sure, ask on the <a
+ href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM-dev</a> list. The
+ reason is that extending LLVM will get involved as you need to update all the
+ different passes that you intend to use with your extension, and there are
+ <em>many</em> LLVM analyses and transformations, so it may be quite a bit of
+ work.</p>
+
+ <p>Adding an <a href="#intrinsic">intrinsic function</a> is far easier than
+ adding an instruction, and is transparent to optimization passes. If your added
+ functionality can be expressed as a
+ function call, an intrinsic function is the method of choice for LLVM
+ extension.</p>
+
+ <p>Before you invest a significant amount of effort into a non-trivial
+ extension, <span class="doc_warning">ask on the list</span> if what you are
+ looking to do can be done with already-existing infrastructure, or if maybe
+ someone else is already working on it. You will save yourself a lot of time and
+ effort by doing so.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="intrinsic">Adding a new intrinsic function</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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
+ function and then be turned into an instruction if warranted.</p>
+
+ <ol>
+ <li><tt>llvm/docs/LangRef.html</tt>:
+ Document the intrinsic. Decide whether it is code generator specific and
+ what the restrictions are. Talk to other people about it so that you are
+ sure it's a good idea.</li>
+
+ <li><tt>llvm/include/llvm/Intrinsics*.td</tt>:
+ Add an entry for your intrinsic. Describe its memory access characteristics
+ for optimization (this controls whether it will be DCE'd, CSE'd, etc). Note
+ that any intrinsic using the <tt>llvm_int_ty</tt> type for an argument will
+ be deemed by <tt>tblgen</tt> as overloaded and the corresponding suffix
+ will be required on the intrinsic's name.</li>
+
+ <li><tt>llvm/lib/Analysis/ConstantFolding.cpp</tt>: If it is possible to
+ constant fold your intrinsic, add support to it in the
+ <tt>canConstantFoldCallTo</tt> and <tt>ConstantFoldCall</tt> functions.</li>
+
+ <li><tt>llvm/test/Regression/*</tt>: Add test cases for your test cases to the
+ test suite</li>
+ </ol>
+
+ <p>Once the intrinsic has been added to the system, you must add code generator
+ support for it. Generally you must do the following steps:</p>
+
+ <dl>
+ <dt>Add support to the C backend in <tt>lib/Target/CBackend/</tt></dt>
+
+ <dd>Depending on the intrinsic, there are a few ways to implement this. For
+ most intrinsics, it makes sense to add code to lower your intrinsic in
+ <tt>LowerIntrinsicCall</tt> in <tt>lib/CodeGen/IntrinsicLowering.cpp</tt>.
+ Second, if it makes sense to lower the intrinsic to an expanded sequence of
+ C code in all cases, just emit the expansion in <tt>visitCallInst</tt> in
+ <tt>Writer.cpp</tt>. If the intrinsic has some way to express it with GCC
+ (or any other compiler) extensions, it can be conditionally supported based
+ on the compiler compiling the CBE output (see <tt>llvm.prefetch</tt> for an
+ example). Third, if the intrinsic really has no way to be lowered, just
+ have the code generator emit code that prints an error message and calls
+ abort if executed.</dd>
+
+ <dt>Add support to the .td file for the target(s) of your choice in
+ <tt>lib/Target/*/*.td</tt>.</dt>
+
+ <dd>This is usually a matter of adding a pattern to the .td file that matches
+ the intrinsic, though it may obviously require adding the instructions you
+ want to generate as well. There are lots of examples in the PowerPC and X86
+ backend to follow.</dd>
+ </dl>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="sdnode">Adding a new SelectionDAG node</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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
+ instructions common to many targets. These nodes often map to an LLVM
+ instruction (add, sub) or intrinsic (byteswap, population count). In other
+ cases, new nodes have been added to allow many targets to perform a common task
+ (converting between floating point and integer representation) or capture more
+ complicated behavior in a single node (rotate).</p>
+
+ <ol>
+ <li><tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>:
+ Add an enum value for the new SelectionDAG node.</li>
+ <li><tt>lib/CodeGen/SelectionDAG/SelectionDAG.cpp</tt>:
+ Add code to print the node to <tt>getOperationName</tt>. If your new node
+ can be evaluated at compile time when given constant arguments (such as an
+ add of a constant with another constant), find the <tt>getNode</tt> method
+ that takes the appropriate number of arguments, and add a case for your node
+ to the switch statement that performs constant folding for nodes that take
+ the same number of arguments as your new node.</li>
+ <li><tt>lib/CodeGen/SelectionDAG/LegalizeDAG.cpp</tt>:
+ Add code to <a href="CodeGenerator.html#selectiondag_legalize">legalize,
+ promote, and expand</a> the node as necessary. At a minimum, you will need
+ to add a case statement for your node in <tt>LegalizeOp</tt> which calls
+ LegalizeOp on the node's operands, and returns a new node if any of the
+ operands changed as a result of being legalized. It is likely that not all
+ targets supported by the SelectionDAG framework will natively support the
+ new node. In this case, you must also add code in your node's case
+ statement in <tt>LegalizeOp</tt> to Expand your node into simpler, legal
+ operations. The case for <tt>ISD::UREM</tt> for expanding a remainder into
+ a divide, multiply, and a subtract is a good example.</li>
+ <li><tt>lib/CodeGen/SelectionDAG/LegalizeDAG.cpp</tt>:
+ If targets may support the new node being added only at certain sizes, you
+ will also need to add code to your node's case statement in
+ <tt>LegalizeOp</tt> to Promote your node's operands to a larger size, and
+ perform the correct operation. You will also need to add code to
+ <tt>PromoteOp</tt> to do this as well. For a good example, see
+ <tt>ISD::BSWAP</tt>,
+ which promotes its operand to a wider size, performs the byteswap, and then
+ shifts the correct bytes right to emulate the narrower byteswap in the
+ wider type.</li>
+ <li><tt>lib/CodeGen/SelectionDAG/LegalizeDAG.cpp</tt>:
+ Add a case for your node in <tt>ExpandOp</tt> to teach the legalizer how to
+ perform the action represented by the new node on a value that has been
+ split into high and low halves. This case will be used to support your
+ node with a 64 bit operand on a 32 bit target.</li>
+ <li><tt>lib/CodeGen/SelectionDAG/DAGCombiner.cpp</tt>:
+ If your node can be combined with itself, or other existing nodes in a
+ peephole-like fashion, add a visit function for it, and call that function
+ from <tt></tt>. There are several good examples for simple combines you
+ can do; <tt>visitFABS</tt> and <tt>visitSRL</tt> are good starting places.
+ </li>
+ <li><tt>lib/Target/PowerPC/PPCISelLowering.cpp</tt>:
+ Each target has an implementation of the <tt>TargetLowering</tt> class,
+ usually in its own file (although some targets include it in the same
+ file as the DAGToDAGISel). The default behavior for a target is to
+ assume that your new node is legal for all types that are legal for
+ that target. If this target does not natively support your node, then
+ tell the target to either Promote it (if it is supported at a larger
+ type) or Expand it. This will cause the code you wrote in
+ <tt>LegalizeOp</tt> above to decompose your new node into other legal
+ nodes for this target.</li>
+ <li><tt>lib/Target/TargetSelectionDAG.td</tt>:
+ Most current targets supported by LLVM generate code using the DAGToDAG
+ method, where SelectionDAG nodes are pattern matched to target-specific
+ nodes, which represent individual instructions. In order for the targets
+ to match an instruction to your new node, you must add a def for that node
+ to the list in this file, with the appropriate type constraints. Look at
+ <tt>add</tt>, <tt>bswap</tt>, and <tt>fadd</tt> for examples.</li>
+ <li><tt>lib/Target/PowerPC/PPCInstrInfo.td</tt>:
+ Each target has a tablegen file that describes the target's instruction
+ set. For targets that use the DAGToDAG instruction selection framework,
+ add a pattern for your new node that uses one or more target nodes.
+ Documentation for this is a bit sparse right now, but there are several
+ decent examples. See the patterns for <tt>rotl</tt> in
+ <tt>PPCInstrInfo.td</tt>.</li>
+ <li>TODO: document complex patterns.</li>
+ <li><tt>llvm/test/Regression/CodeGen/*</tt>: Add test cases for your new node
+ to the test suite. <tt>llvm/test/Regression/CodeGen/X86/bswap.ll</tt> is
+ a good example.</li>
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="instruction">Adding a new instruction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><span class="doc_warning">WARNING: adding instructions changes the bitcode
+ format, and it will take some effort to maintain compatibility with
+ the previous version.</span> Only add an instruction if it is absolutely
+ necessary.</p>
+
+ <ol>
+
+ <li><tt>llvm/include/llvm/Instruction.def</tt>:
+ add a number for your instruction and an enum name</li>
+
+ <li><tt>llvm/include/llvm/Instructions.h</tt>:
+ add a definition for the class that will represent your instruction</li>
+
+ <li><tt>llvm/include/llvm/Support/InstVisitor.h</tt>:
+ add a prototype for a visitor to your new instruction type</li>
+
+ <li><tt>llvm/lib/AsmParser/Lexer.l</tt>:
+ add a new token to parse your instruction from assembly text file</li>
+
+ <li><tt>llvm/lib/AsmParser/llvmAsmParser.y</tt>:
+ add the grammar on how your instruction can be read and what it will
+ construct as a result</li>
+
+ <li><tt>llvm/lib/Bitcode/Reader/Reader.cpp</tt>:
+ add a case for your instruction and how it will be parsed from bitcode</li>
+
+ <li><tt>llvm/lib/VMCore/Instruction.cpp</tt>:
+ add a case for how your instruction will be printed out to assembly</li>
+
+ <li><tt>llvm/lib/VMCore/Instructions.cpp</tt>:
+ implement the class you defined in
+ <tt>llvm/include/llvm/Instructions.h</tt></li>
+
+ <li>Test your instruction</li>
+
+ <li><tt>llvm/lib/Target/*</tt>:
+ Add support for your instruction to code generators, or add a lowering
+ pass.</li>
+
+ <li><tt>llvm/test/Regression/*</tt>: add your test cases to the test suite.</li>
+
+ </ol>
+
+ <p>Also, you need to implement (or modify) any analyses or passes that you want
+ to understand this new instruction.</p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="type">Adding a new type</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><span class="doc_warning">WARNING: adding new types changes the bitcode
+ format, and will break compatibility with currently-existing LLVM
+ installations.</span> Only add new types if it is absolutely necessary.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="fund_type">Adding a fundamental type</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ol>
+
+ <li><tt>llvm/include/llvm/Type.h</tt>:
+ add enum for the new type; add static <tt>Type*</tt> for this type</li>
+
+ <li><tt>llvm/lib/VMCore/Type.cpp</tt>:
+ add mapping from <tt>TypeID</tt> => <tt>Type*</tt>;
+ initialize the static <tt>Type*</tt></li>
+
+ <li><tt>llvm/lib/AsmReader/Lexer.l</tt>:
+ add ability to parse in the type from text assembly</li>
+
+ <li><tt>llvm/lib/AsmReader/llvmAsmParser.y</tt>:
+ add a token for that type</li>
+
+ </ol>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="derived_type">Adding a derived type</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ol>
+ <li><tt>llvm/include/llvm/Type.h</tt>:
+ add enum for the new type; add a forward declaration of the type
+ also</li>
+
+ <li><tt>llvm/include/llvm/DerivedTypes.h</tt>:
+ add new class to represent new class in the hierarchy; add forward
+ declaration to the TypeMap value type</li>
+
+ <li><tt>llvm/lib/VMCore/Type.cpp</tt>:
+ add support for derived type to:
+ <div class="doc_code">
+ <pre>
+ std::string getTypeDescription(const Type &Ty,
+ std::vector<const Type*> &TypeStack)
+ bool TypesEqual(const Type *Ty, const Type *Ty2,
+ std::map<const Type*, const Type*> & EqTypes)
+ </pre>
+ </div>
+ add necessary member functions for type, and factory methods</li>
+
+ <li><tt>llvm/lib/AsmReader/Lexer.l</tt>:
+ add ability to parse in the type from text assembly</li>
+
+ <li><tt>llvm/lib/BitCode/Writer/Writer.cpp</tt>:
+ modify <tt>void BitcodeWriter::outputType(const Type *T)</tt> to serialize
+ your type</li>
+
+ <li><tt>llvm/lib/BitCode/Reader/Reader.cpp</tt>:
+ modify <tt>const Type *BitcodeReader::ParseType()</tt> to read your data
+ type</li>
+
+ <li><tt>llvm/lib/VMCore/AsmWriter.cpp</tt>:
+ modify
+ <div class="doc_code">
+ <pre>
+ void calcTypeName(const Type *Ty,
+ std::vector<const Type*> &TypeStack,
+ std::map<const Type*,std::string> &TypeNames,
+ std::string & Result)
+ </pre>
+ </div>
+ to output the new derived type
+ </li>
+
+
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/FAQ.html
diff -c /dev/null llvm-www/releases/2.5/docs/FAQ.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/FAQ.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,725 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM: Frequently Asked Questions</title>
+ <style type="text/css">
+ @import url("llvm.css");
+ .question { font-weight: bold }
+ .answer { margin-left: 2em }
+ </style>
+ </head>
+ <body>
+
+ <div class="doc_title">
+ LLVM: Frequently Asked Questions
+ </div>
+
+ <ol>
+ <li><a href="#license">License</a>
+ <ol>
+ <li>Why are the LLVM source code and the front-end distributed under different
+ licenses?</li>
+ <li>Does the University of Illinois Open Source License really qualify as an
+ "open source" license?</li>
+ <li>Can I modify LLVM source code and redistribute the modified source?</li>
+ <li>Can I modify LLVM source code and redistribute binaries or other tools
+ based on it, without redistributing the source?</li>
+ </ol></li>
+
+ <li><a href="#source">Source code</a>
+ <ol>
+ <li>In what language is LLVM written?</li>
+ <li>How portable is the LLVM source code?</li>
+ </ol></li>
+
+ <li><a href="#build">Build Problems</a>
+ <ol>
+ <li>When I run configure, it finds the wrong C compiler.</li>
+ <li>The <tt>configure</tt> script finds the right C compiler, but it uses the
+ LLVM linker from a previous build. What do I do?</li>
+ <li>When creating a dynamic library, I get a strange GLIBC error.</li>
+ <li>I've updated my source tree from Subversion, and now my build is trying
+ to use a file/directory that doesn't exist.</li>
+ <li>I've modified a Makefile in my source tree, but my build tree keeps using
+ the old version. What do I do?</li>
+ <li>I've upgraded to a new version of LLVM, and I get strange build
+ errors.</li>
+ <li>I've built LLVM and am testing it, but the tests freeze.</li>
+ <li>Why do test results differ when I perform different types of builds?</li>
+ <li>Compiling LLVM with GCC 3.3.2 fails, what should I do?</li>
+ <li>When I use the test suite, all of the C Backend tests fail. What is
+ wrong?</li>
+ <li>After Subversion update, rebuilding gives the error "No rule to make
+ target".</li>
+ <li><a href="#llvmc">The <tt>llvmc</tt> program gives me errors/doesn't
+ work.</a></li>
+ </ol></li>
+
+ <li><a href="#felangs">Source Languages</a>
+ <ol>
+ <li><a href="#langs">What source languages are supported?</a></li>
+ <li><a href="#langirgen">I'd like to write a self-hosting LLVM compiler. How
+ should I interface with the LLVM middle-end optimizers and back-end code
+ generators?</a></li>
+ <li><a href="#langhlsupp">What support is there for higher level source
+ language constructs for building a compiler?</a></li>
+ <li><a href="GetElementPtr.html">I don't understand the GetElementPtr
+ instruction. Help!</a></li>
+ </ol>
+
+ <li><a href="#cfe">Using the GCC Front End</a>
+ <ol>
+ <li>
+ When I compile software that uses a configure script, the configure script
+ thinks my system has all of the header files and libraries it is testing
+ for. How do I get configure to work correctly?
+ </li>
+
+ <li>
+ When I compile code using the LLVM GCC front end, it complains that it
+ cannot find libcrtend.a.
+ </li>
+
+ <li>
+ How can I disable all optimizations when compiling code using the LLVM GCC front end?
+ </li>
+
+ <li><a href="#translatecxx">Can I use LLVM to convert C++ code to C code?</a></li>
+
+ </ol>
+ </li>
+
+ <li><a href="#cfe_code">Questions about code generated by the GCC front-end</a>
+ <ol>
+ <li><a href="#iosinit">What is this <tt>llvm.global_ctors</tt> and
+ <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I
+ #include <iostream>?</a></li>
+ <li><a href="#codedce">Where did all of my code go??</a></li>
+ <li><a href="#undef">What is this "<tt>undef</tt>" thing that shows up in my code?</a></li>
+ </ol>
+ </li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="http://llvm.org">The LLVM Team</a></p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="license">License</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="question">
+ <p>Why are the LLVM source code and the front-end distributed under different
+ licenses?</p>
+ </div>
+
+ <div class="answer">
+ <p>The C/C++ front-ends are based on GCC and must be distributed under the GPL.
+ Our aim is to distribute LLVM source code under a <em>much less restrictive</em>
+ license, in particular one that does not compel users who distribute tools based
+ on modifying the source to redistribute the modified source code as well.</p>
+ </div>
+
+ <div class="question">
+ <p>Does the University of Illinois Open Source License really qualify as an
+ "open source" license?</p>
+ </div>
+
+ <div class="answer">
+ <p>Yes, the license is <a
+ href="http://www.opensource.org/licenses/UoI-NCSA.php">certified</a> by the Open
+ Source Initiative (OSI).</p>
+ </div>
+
+ <div class="question">
+ <p>Can I modify LLVM source code and redistribute the modified source?</p>
+ </div>
+
+ <div class="answer">
+ <p>Yes. The modified source distribution must retain the copyright notice and
+ follow the three bulletted conditions listed in the <a
+ href="http://llvm.org/svn/llvm-project/llvm/trunk/LICENSE.TXT">LLVM license</a>.</p>
+ </div>
+
+ <div class="question">
+ <p>Can I modify LLVM source code and redistribute binaries or other tools based
+ on it, without redistributing the source?</p>
+ </div>
+
+ <div class="answer">
+ <p>Yes, this is why we distribute LLVM under a less restrictive license than
+ GPL, as explained in the first question above.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="source">Source Code</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="question">
+ <p>In what language is LLVM written?</p>
+ </div>
+
+ <div class="answer">
+ <p>All of the LLVM tools and libraries are written in C++ with extensive use of
+ the STL.</p>
+ </div>
+
+ <div class="question">
+ <p>How portable is the LLVM source code?</p>
+ </div>
+
+ <div class="answer">
+ <p>The LLVM source code should be portable to most modern UNIX-like operating
+ systems. Most of the code is written in standard C++ with operating system
+ services abstracted to a support library. The tools required to build and test
+ LLVM have been ported to a plethora of platforms.</p>
+
+ <p>Some porting problems may exist in the following areas:</p>
+
+ <ul>
+ <li>The GCC front end code is not as portable as the LLVM suite, so it may not
+ compile as well on unsupported platforms.</li>
+
+ <li>The LLVM build system relies heavily on UNIX shell tools, like the Bourne
+ Shell and sed. Porting to systems without these tools (MacOS 9, Plan 9)
+ will require more effort.</li>
+ </ul>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="build">Build Problems</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="question">
+ <p>When I run configure, it finds the wrong C compiler.</p>
+ </div>
+
+ <div class="answer">
+
+ <p>The <tt>configure</tt> script attempts to locate first <tt>gcc</tt> and then
+ <tt>cc</tt>, unless it finds compiler paths set in <tt>CC</tt> and <tt>CXX</tt>
+ for the C and C++ compiler, respectively.</p>
+
+ <p>If <tt>configure</tt> finds the wrong compiler, either adjust your
+ <tt>PATH</tt> environment variable or set <tt>CC</tt> and <tt>CXX</tt>
+ explicitly.</p>
+
+ </div>
+
+ <div class="question">
+ <p>The <tt>configure</tt> script finds the right C compiler, but it uses the
+ LLVM linker from a previous build. What do I do?</p>
+ </div>
+
+ <div class="answer">
+ <p>The <tt>configure</tt> script uses the <tt>PATH</tt> to find executables, so
+ if it's grabbing the wrong linker/assembler/etc, there are two ways to fix
+ it:</p>
+
+ <ol>
+ <li><p>Adjust your <tt>PATH</tt> environment variable so that the correct
+ program appears first in the <tt>PATH</tt>. This may work, but may not be
+ convenient when you want them <i>first</i> in your path for other
+ work.</p></li>
+
+ <li><p>Run <tt>configure</tt> with an alternative <tt>PATH</tt> that is
+ correct. In a Borne compatible shell, the syntax would be:</p>
+
+ <pre class="doc_code">
+ % PATH=[the path without the bad program] ./configure ...
+ </pre>
+
+ <p>This is still somewhat inconvenient, but it allows <tt>configure</tt>
+ to do its work without having to adjust your <tt>PATH</tt>
+ permanently.</p></li>
+ </ol>
+
+ </div>
+
+ <div class="question">
+ <p>When creating a dynamic library, I get a strange GLIBC error.</p>
+ </div>
+
+ <div class="answer">
+ <p>Under some operating systems (i.e. Linux), libtool does not work correctly if
+ GCC was compiled with the --disable-shared option. To work around this, install
+ your own version of GCC that has shared libraries enabled by default.</p>
+ </div>
+
+ <div class="question">
+ <p>I've updated my source tree from Subversion, and now my build is trying to
+ use a file/directory that doesn't exist.</p>
+ </div>
+
+ <div class="answer">
+ <p>You need to re-run configure in your object directory. When new Makefiles
+ are added to the source tree, they have to be copied over to the object tree in
+ order to be used by the build.</p>
+ </div>
+
+ <div class="question">
+ <p>I've modified a Makefile in my source tree, but my build tree keeps using the
+ old version. What do I do?</p>
+ </div>
+
+ <div class="answer">
+ <p>If the Makefile already exists in your object tree, you
+ can just run the following command in the top level directory of your object
+ tree:</p>
+
+ <pre class="doc_code">
+ % ./config.status <relative path to Makefile>
+ </pre>
+
+ <p>If the Makefile is new, you will have to modify the configure script to copy
+ it over.</p>
+
+ </div>
+
+ <div class="question">
+ <p>I've upgraded to a new version of LLVM, and I get strange build errors.</p>
+ </div>
+
+ <div class="answer">
+
+ <p>Sometimes, changes to the LLVM source code alters how the build system works.
+ Changes in libtool, autoconf, or header file dependencies are especially prone
+ to this sort of problem.</p>
+
+ <p>The best thing to try is to remove the old files and re-build. In most
+ cases, this takes care of the problem. To do this, just type <tt>make
+ clean</tt> and then <tt>make</tt> in the directory that fails to build.</p>
+
+ </div>
+
+ <div class="question">
+ <p>I've built LLVM and am testing it, but the tests freeze.</p>
+ </div>
+
+ <div class="answer">
+
+ <p>This is most likely occurring because you built a profile or release
+ (optimized) build of LLVM and have not specified the same information on the
+ <tt>gmake</tt> command line.</p>
+
+ <p>For example, if you built LLVM with the command:</p>
+
+ <pre class="doc_code">
+ % gmake ENABLE_PROFILING=1
+ </pre>
+
+ <p>...then you must run the tests with the following commands:</p>
+
+ <pre class="doc_code">
+ % cd llvm/test
+ % gmake ENABLE_PROFILING=1
+ </pre>
+
+ </div>
+
+ <div class="question">
+ <p>Why do test results differ when I perform different types of builds?</p>
+ </div>
+
+ <div class="answer">
+
+ <p>The LLVM test suite is dependent upon several features of the LLVM tools and
+ libraries.</p>
+
+ <p>First, the debugging assertions in code are not enabled in optimized or
+ profiling builds. Hence, tests that used to fail may pass.</p>
+
+ <p>Second, some tests may rely upon debugging options or behavior that is only
+ available in the debug build. These tests will fail in an optimized or profile
+ build.</p>
+
+ </div>
+
+ <div class="question">
+ <p>Compiling LLVM with GCC 3.3.2 fails, what should I do?</p>
+ </div>
+
+ <div class="answer">
+ <p>This is <a href="http://gcc.gnu.org/PR?13392">a bug in GCC</a>, and
+ affects projects other than LLVM. Try upgrading or downgrading your GCC.</p>
+ </div>
+
+ <div class="question">
+ <p>After Subversion update, rebuilding gives the error "No rule to make
+ target".</p>
+ </div>
+
+ <div class="answer">
+ <p>If the error is of the form:</p>
+
+ <pre class="doc_code">
+ gmake[2]: *** No rule to make target `/path/to/somefile', needed by
+ `/path/to/another/file.d'.<br>
+ Stop.
+ </pre>
+
+ <p>This may occur anytime files are moved within the Subversion repository or
+ removed entirely. In this case, the best solution is to erase all
+ <tt>.d</tt> files, which list dependencies for source files, and rebuild:</p>
+
+ <pre class="doc_code">
+ % cd $LLVM_OBJ_DIR
+ % rm -f `find . -name \*\.d`
+ % gmake
+ </pre>
+
+ <p>In other cases, it may be necessary to run <tt>make clean</tt> before
+ rebuilding.</p>
+ </div>
+
+ <div class="question"><p><a name="llvmc">
+ The <tt>llvmc</tt> program gives me errors/doesn't work.</a></p>
+ </div>
+
+ <div class="answer">
+ <p><tt>llvmc</tt> is experimental and isn't really supported. We suggest
+ using <tt>llvm-gcc</tt> instead.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="felangs">Source Languages</a></div>
+
+ <div class="question"><p>
+ <a name="langs">What source languages are supported?</a></p>
+ </div>
+ <div class="answer">
+ <p>LLVM currently has full support for C and C++ source languages. These are
+ available through a special version of GCC that LLVM calls the
+ <a href="#cfe">C Front End</a></p>
+ <p>There is an incomplete version of a Java front end available in the
+ <tt>java</tt> module. There is no documentation on this yet so
+ you'll need to download the code, compile it, and try it.</p>
+ <p>The PyPy developers are working on integrating LLVM into the PyPy backend
+ so that PyPy language can translate to LLVM.</p>
+ </div>
+
+ <div class="question"><p><a name="langirgen">
+ I'd like to write a self-hosting LLVM compiler. How should I interface with
+ the LLVM middle-end optimizers and back-end code generators?
+ </a></p></div>
+ <div class="answer">
+ <p>Your compiler front-end will communicate with LLVM by creating a module in
+ the LLVM intermediate representation (IR) format. Assuming you want to
+ write your language's compiler in the language itself (rather than C++),
+ there are 3 major ways to tackle generating LLVM IR from a front-end:</p>
+ <ul>
+ <li>
+ <strong>Call into the LLVM libraries code using your language's FFI
+ (foreign function interface).</strong>
+ <ul>
+ <li><em>for:</em> best tracks changes to the LLVM IR, .ll syntax,
+ and .bc format</li>
+ <li><em>for:</em> enables running LLVM optimization passes without a
+ emit/parse overhead</li>
+ <li><em>for:</em> adapts well to a JIT context</li>
+ <li><em>against:</em> lots of ugly glue code to write</li>
+ </ul>
+ </li>
+ <li>
+ <strong>Emit LLVM assembly from your compiler's native language.</strong>
+ <ul>
+ <li><em>for:</em> very straightforward to get started</li>
+ <li><em>against:</em> the .ll parser is slower than the bitcode reader
+ when interfacing to the middle end</li>
+ <li><em>against:</em> you'll have to re-engineer the LLVM IR object
+ model and asm writer in your language</li>
+ <li><em>against:</em> it may be harder to track changes to the IR</li>
+ </ul>
+ </li>
+ <li>
+ <strong>Emit LLVM bitcode from your compiler's native language.</strong>
+ <ul>
+ <li><em>for:</em> can use the more-efficient bitcode reader when
+ interfacing to the middle end</li>
+ <li><em>against:</em> you'll have to re-engineer the LLVM IR object
+ model and bitcode writer in your language</li>
+ <li><em>against:</em> it may be harder to track changes to the IR</li>
+ </ul>
+ </li>
+ </ul>
+ <p>If you go with the first option, the C bindings in include/llvm-c should
+ help a lot, since most languages have strong support for interfacing with
+ C. The most common hurdle with calling C from managed code is interfacing
+ with the garbage collector. The C interface was designed to require very
+ little memory management, and so is straightforward in this regard.</p>
+ </div>
+
+ <div class="question"><p><a name="langhlsupp">
+ What support is there for a higher level source language constructs for
+ building a compiler?</a></p>
+ </div>
+ <div class="answer">
+ <p>Currently, there isn't much. LLVM supports an intermediate representation
+ which is useful for code representation but will not support the high level
+ (abstract syntax tree) representation needed by most compilers. There are no
+ facilities for lexical nor semantic analysis. There is, however, a <i>mostly
+ implemented</i> configuration-driven
+ <a href="CompilerDriver.html">compiler driver</a> which simplifies the task
+ of running optimizations, linking, and executable generation.</p>
+ </div>
+
+ <div class="question"><p><a name="getelementptr">
+ I don't understand the GetElementPtr instruction. Help!</a></p>
+ </div>
+ <div class="answer">
+ <p>See <a href="GetElementPtr.html">The Often Misunderstood GEP
+ Instruction</a>.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="cfe">Using the GCC Front End</a>
+ </div>
+
+ <div class="question">
+ <p>
+ When I compile software that uses a configure script, the configure script
+ thinks my system has all of the header files and libraries it is testing for.
+ How do I get configure to work correctly?
+ </p>
+ </div>
+
+ <div class="answer">
+ <p>
+ The configure script is getting things wrong because the LLVM linker allows
+ symbols to be undefined at link time (so that they can be resolved during JIT
+ or translation to the C back end). That is why configure thinks your system
+ "has everything."
+ </p>
+ <p>
+ To work around this, perform the following steps:
+ </p>
+ <ol>
+ <li>Make sure the CC and CXX environment variables contains the full path to
+ the LLVM GCC front end.</li>
+
+ <li>Make sure that the regular C compiler is first in your PATH. </li>
+
+ <li>Add the string "-Wl,-native" to your CFLAGS environment variable.</li>
+ </ol>
+
+ <p>
+ This will allow the <tt>llvm-ld</tt> linker to create a native code executable
+ instead of shell script that runs the JIT. Creating native code requires
+ standard linkage, which in turn will allow the configure script to find out if
+ code is not linking on your system because the feature isn't available on your
+ system.</p>
+ </div>
+
+ <div class="question">
+ <p>
+ When I compile code using the LLVM GCC front end, it complains that it cannot
+ find libcrtend.a.
+ </p>
+ </div>
+
+ <div class="answer">
+ <p>
+ The only way this can happen is if you haven't installed the runtime library. To
+ correct this, do:</p>
+
+ <pre class="doc_code">
+ % cd llvm/runtime
+ % make clean ; make install-bytecode
+ </pre>
+ </div>
+
+ <div class="question">
+ <p>
+ How can I disable all optimizations when compiling code using the LLVM GCC front end?
+ </p>
+ </div>
+
+ <div class="answer">
+ <p>
+ Passing "-Wa,-disable-opt -Wl,-disable-opt" will disable *all* cleanup and
+ optimizations done at the llvm level, leaving you with the truly horrible
+ code that you desire.
+ </p>
+ </div>
+
+
+ <div class="question">
+ <p>
+ <a name="translatecxx">Can I use LLVM to convert C++ code to C code?</a>
+ </p>
+ </div>
+
+ <div class="answer">
+ <p>Yes, you can use LLVM to convert code from any language LLVM supports to C.
+ Note that the generated C code will be very low level (all loops are lowered
+ to gotos, etc) and not very pretty (comments are stripped, original source
+ formatting is totally lost, variables are renamed, expressions are regrouped),
+ so this may not be what you're looking for. Also, there are several
+ limitations noted below.<p>
+
+ <p>Use commands like this:</p>
+
+ <ol>
+ <li><p>Compile your program as normal with llvm-g++:</p>
+
+ <pre class="doc_code">
+ % llvm-g++ x.cpp -o program
+ </pre>
+
+ <p>or:</p>
+
+ <pre class="doc_code">
+ % llvm-g++ a.cpp -c
+ % llvm-g++ b.cpp -c
+ % llvm-g++ a.o b.o -o program
+ </pre>
+
+ <p>With llvm-gcc3, this will generate program and program.bc. The .bc
+ file is the LLVM version of the program all linked together.</p></li>
+
+ <li><p>Convert the LLVM code to C code, using the LLC tool with the C
+ backend:</p>
+
+ <pre class="doc_code">
+ % llc -march=c program.bc -o program.c
+ </pre></li>
+
+ <li><p>Finally, compile the C file:</p>
+
+ <pre class="doc_code">
+ % cc x.c
+ </pre></li>
+
+ </ol>
+
+ <p>Using LLVM does not eliminate the need for C++ library support.
+ If you use the llvm-g++ front-end, the generated code will depend on
+ g++'s C++ support libraries in the same way that code generated from
+ g++ would. If you use another C++ front-end, the generated code will
+ depend on whatever library that front-end would normally require.</p>
+
+ <p>If you are working on a platform that does not provide any C++
+ libraries, you may be able to manually compile libstdc++ to LLVM
+ bitcode, statically link it into your program, then use the commands above to
+ convert the whole result into C code. Alternatively, you might compile the
+ libraries and your application into two different chunks of C code and link
+ them.</p>
+
+ <p>Note that, by default, the C back end does not support exception handling. If
+ you want/need it for a certain program, you can enable it by passing
+ "-enable-correct-eh-support" to the llc program. The resultant code will use
+ setjmp/longjmp to implement exception support that is relatively slow, and
+ not C++-ABI-conforming on most platforms, but otherwise correct.</p>
+
+ <p>Also, there are a number of other limitations of the C backend that
+ cause it to produce code that does not fully conform to the C++ ABI on
+ most platforms. Some of the C++ programs in LLVM's test suite are known
+ to fail when compiled with the C back end because of ABI incompatiblities
+ with standard C++ libraries.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="cfe_code">Questions about code generated by the GCC front-end</a>
+ </div>
+
+ <div class="question">
+ <a name="iosinit"></a>
+ <p> What is this <tt>llvm.global_ctors</tt> and
+ <tt>_GLOBAL__I__tmp_webcompile...</tt> stuff that happens when I #include
+ <iostream>?</p>
+ </div>
+
+ <div class="answer">
+
+ <p>If you #include the <iostream> header into a C++ translation unit, the
+ file will probably use the <tt>std::cin</tt>/<tt>std::cout</tt>/... global
+ objects. However, C++ does not guarantee an order of initialization between
+ static objects in different translation units, so if a static ctor/dtor in your
+ .cpp file used <tt>std::cout</tt>, for example, the object would not necessarily
+ be automatically initialized before your use.</p>
+
+ <p>To make <tt>std::cout</tt> and friends work correctly in these scenarios, the
+ STL that we use declares a static object that gets created in every translation
+ unit that includes <tt><iostream></tt>. This object has a static
+ constructor and destructor that initializes and destroys the global iostream
+ objects before they could possibly be used in the file. The code that you see
+ in the .ll file corresponds to the constructor and destructor registration code.
+ </p>
+
+ <p>If you would like to make it easier to <b>understand</b> the LLVM code
+ generated by the compiler in the demo page, consider using <tt>printf()</tt>
+ instead of <tt>iostream</tt>s to print values.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+
+ <div class="question"><p>
+ <a name="codedce"></a>
+ Where did all of my code go??
+ </p></div>
+
+ <div class="answer">
+ <p>
+ If you are using the LLVM demo page, you may often wonder what happened to all
+ of the code that you typed in. Remember that the demo script is running the
+ code through the LLVM optimizers, so if your code doesn't actually do anything
+ useful, it might all be deleted.
+ </p>
+
+ <p>
+ To prevent this, make sure that the code is actually needed. For example, if
+ you are computing some expression, return the value from the function instead of
+ leaving it in a local variable. If you really want to constrain the optimizer,
+ you can read from and assign to <tt>volatile</tt> global variables.
+ </p>
+ </div>
+
+ <!--=========================================================================-->
+
+ <div class="question"><p>
+ <a name="undef"></a>
+ <p>What is this "<tt>undef</tt>" thing that shows up in my code?
+ </p></div>
+
+ <div class="answer">
+ <p>
+ <a href="LangRef.html#undef"><tt>undef</tt></a> is the LLVM way of representing
+ a value that is not defined. You can get these if you do not initialize a
+ variable before you use it. For example, the C function:</p>
+
+ <pre class="doc_code">
+ int X() { int i; return i; }
+ </pre>
+
+ <p>Is compiled to "<tt>ret i32 undef</tt>" because "<tt>i</tt>" never has
+ a value specified for it.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/GCCFEBuildInstrs.html
diff -c /dev/null llvm-www/releases/2.5/docs/GCCFEBuildInstrs.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/GCCFEBuildInstrs.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,269 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <link rel="stylesheet" href="llvm.css" type="text/css" media="screen">
+ <title>Building the LLVM GCC Front-End</title>
+ </head>
+ <body>
+
+ <div class="doc_title">
+ Building the LLVM GCC Front-End
+ </div>
+
+ <ol>
+ <li><a href="#instructions">Building llvm-gcc from Source</a></li>
+ <li><a href="#ada">Building the Ada front-end</a></li>
+ <li><a href="#fortran">Building the Fortran front-end</a></li>
+ <li><a href="#license">License Information</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by the LLVM Team</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <h1><a name="instructions">Building llvm-gcc from Source</a></h1>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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,
+ Objective-C and Objective-C++. Note that the instructions for building these
+ front-ends are completely different (and much easier!) than those for building
+ llvm-gcc3 in the past.</p>
+
+ <ol>
+ <li><p>Retrieve the appropriate llvm-gcc-4.2-<i>version</i>.source.tar.gz
+ archive from the <a href="http://llvm.org/releases/">LLVM web
+ site</a>.</p>
+
+ <p>It is also possible to download the sources of the llvm-gcc front end
+ from a read-only mirror using subversion. To check out the 4.2 code
+ for first time use:</p>
+
+ <div class="doc_code">
+ <pre>
+ svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk <i>dst-directory</i>
+ </pre>
+ </div>
+
+ <p>After that, the code can be be updated in the destination directory
+ using:</p>
+
+ <div class="doc_code">
+ <pre>svn update</pre>
+ </div>
+
+ <p>The mirror is brought up to date every evening.</p></li>
+
+ <li>Follow the directions in the top-level <tt>README.LLVM</tt> file for
+ up-to-date instructions on how to build llvm-gcc. See below for building
+ with support for Ada or Fortran.
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <h1><a name="ada">Building the Ada front-end</a></h1>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>Building with support for Ada amounts to following the directions in the
+ top-level <tt>README.LLVM</tt> file, adding ",ada" to EXTRALANGS, for example:
+ <tt>EXTRALANGS=,ada</tt></p>
+
+ <p>There are some complications however:</p>
+
+ <ol>
+ <li><p>The only platform for which the Ada front-end is known to build is
+ 32 bit intel x86 running linux. It is unlikely to build for other
+ systems without some work.</p></li>
+ <li><p>The build requires having a compiler that supports Ada, C and C++.
+ The Ada front-end is written in Ada so an Ada compiler is needed to
+ build it. Compilers known to work with the
+ <a href="http://llvm.org/releases/download.html">LLVM 2.4 release</a>
+ are <a href="http://gcc.gnu.org/releases.html">gcc-4.2</a> and the
+ 2005, 2006 and 2007 versions of the
+ <a href="http://libre.adacore.com/">GNAT GPL Edition</a>.
+ The LLVM parts of llvm-gcc are written in C++ so a C++ compiler is
+ needed to build them. The rest of gcc is written in C.
+ Some linux distributions provide a version of gcc that supports all
+ three languages (the Ada part often comes as an add-on package to
+ the rest of gcc). Otherwise it is possible to combine two versions
+ of gcc, one that supports Ada and C (such as the
+ <a href="http://libre.adacore.com/">2007 GNAT GPL Edition</a>)
+ and another which supports C++, see below.</p></li>
+ <li><p>Because the Ada front-end is experimental, it is wise to build the
+ compiler with checking enabled. This causes it to run much slower, but
+ helps catch mistakes in the compiler (please report any problems using
+ <a href="http://llvm.org/bugs">LLVM bugzilla</a>).</p></li>
+ </ol>
+
+ <p>Supposing appropriate compilers are available, llvm-gcc with Ada support can
+ be built on an x86-32 linux box using the following recipe:</p>
+
+ <ol>
+ <li><p>Download the <a href="http://llvm.org/releases/download.html">LLVM source</a>
+ and unpack it:</p>
+
+ <pre class="doc_code">
+ wget http://llvm.org/releases/2.4/llvm-2.4.tar.gz
+ tar xzf llvm-2.4.tar.gz
+ mv llvm-2.4 llvm
+ </pre>
+
+ <p>or <a href="GettingStarted.html#checkout">check out the
+ latest version from subversion</a>:</p>
+
+ <pre class="doc_code">svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm</pre>
+
+ </li>
+
+ <li><p>Download the
+ <a href="http://llvm.org/releases/download.html">llvm-gcc-4.2 source</a>
+ and unpack it:</p>
+
+ <pre class="doc_code">
+ wget http://llvm.org/releases/2.4/llvm-gcc-4.2-2.4.source.tar.gz
+ tar xzf llvm-gcc-4.2-2.4.source.tar.gz
+ mv llvm-gcc4.2-2.4.source llvm-gcc-4.2
+ </pre>
+
+ <p>or <a href="GettingStarted.html#checkout">check out the
+ latest version from subversion</a>:</p>
+
+ <pre class="doc_code">
+ svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk llvm-gcc-4.2
+ </pre>
+ </li>
+
+ <li><p>Make a build directory <tt>llvm-objects</tt> for llvm and make it the
+ current directory:</p>
+
+ <pre class="doc_code">
+ mkdir llvm-objects
+ cd llvm-objects
+ </pre>
+ </li>
+
+ <li><p>Configure LLVM (here it is configured to install into <tt>/usr/local</tt>):</p>
+
+ <pre class="doc_code">
+ ../llvm/configure --prefix=<b>/usr/local</b>
+ </pre>
+
+ <p>If you have a multi-compiler setup and the C++ compiler is not the
+ default, then you can configure like this:</p>
+
+ <pre class="doc_code">
+ CXX=<b>PATH_TO_C++_COMPILER</b> ../llvm/configure --prefix=<b>/usr/local</b>
+ </pre>
+ </li>
+
+ <li><p>Build LLVM with checking enabled (use <tt>ENABLE_OPTIMIZED=1</tt> to
+ build without checking):</p>
+
+ <pre class="doc_code">
+ make ENABLE_OPTIMIZED=0
+ </pre>
+ </li>
+
+ <li><p>Install LLVM (optional):</p>
+
+ <pre class="doc_code">
+ make ENABLE_OPTIMIZED=0 install
+ </pre>
+ </li>
+
+ <li><p>Make a build directory <tt>llvm-gcc-4.2-objects</tt> for llvm-gcc and make it the
+ current directory:</p>
+
+ <pre class="doc_code">
+ cd ..
+ mkdir llvm-gcc-4.2-objects
+ cd llvm-gcc-4.2-objects
+ </pre>
+ </li>
+
+ <li><p>Configure llvm-gcc (here it is configured to install into <tt>/usr/local</tt>).
+ The <tt>--enable-checking</tt> flag turns on sanity checks inside the compiler.
+ If you omit it then LLVM should be built with <tt>make ENABLE_OPTIMIZED=1</tt>.
+ Additional languages can be appended to the <tt>--enable-languages</tt> switch,
+ for example <tt>--enable-languages=ada,c,c++</tt>.</p>
+
+ <pre class="doc_code">
+ ../llvm-gcc-4.2/configure --prefix=<b>/usr/local</b> --enable-languages=ada,c \
+ --enable-checking --enable-llvm=$PWD/../llvm-objects \
+ --disable-bootstrap --disable-multilib
+ </pre>
+
+ <p>If you have a multi-compiler setup, then you can configure like this:</p>
+
+ <pre class="doc_code">
+ export CC=<b>PATH_TO_C_AND_ADA_COMPILER</b>
+ export CXX=<b>PATH_TO_C++_COMPILER</b>
+ ../llvm-gcc-4.2/configure --prefix=<b>/usr/local</b> --enable-languages=ada,c \
+ --enable-checking --enable-llvm=$PWD/../llvm-objects \
+ --disable-bootstrap --disable-multilib
+ </pre>
+ </li>
+
+ <li><p>Build and install the compiler:</p>
+
+ <pre class="doc_code">
+ make
+ make install
+ </pre>
+ </li>
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <h1><a name="fortran">Building the Fortran front-end</a></h1>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>To build with support for Fortran, follow the directions in the top-level
+ <tt>README.LLVM</tt> file, adding ",fortran" to EXTRALANGS, for example:</p>
+
+ <pre class="doc_code">
+ EXTRALANGS=,fortran
+ </pre>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <h1><a name="license">License Information</a></h1>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ 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
+ COPYING.LIB for more details.
+ </p>
+
+ <p>
+ More information is <a href="FAQ.html#license">available in the FAQ</a>.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/GarbageCollection.html
diff -c /dev/null llvm-www/releases/2.5/docs/GarbageCollection.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/GarbageCollection.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1446 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" Content="text/html; charset=UTF-8" >
+ <title>Accurate Garbage Collection with LLVM</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <style type="text/css">
+ .rowhead { text-align: left; background: inherit; }
+ .indent { padding-left: 1em; }
+ .optl { color: #BFBFBF; }
+ </style>
+ </head>
+ <body>
+
+ <div class="doc_title">
+ Accurate Garbage Collection with LLVM
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a>
+ <ul>
+ <li><a href="#feature">GC features provided and algorithms
+ supported</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#usage">Using the collectors</a>
+ <ul>
+ <li><a href="#shadow-stack">ShadowStack -
+ A highly portable collector</a></li>
+ <li><a href="#semispace">SemiSpace -
+ A simple copying collector runtime</a></li>
+ <li><a href="#ocaml">Ocaml -
+ An Objective Caml-compatible collector</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#core">Core support</a>
+ <ul>
+ <li><a href="#gcattr">Specifying GC code generation:
+ <tt>gc "..."</tt></a></li>
+ <li><a href="#gcroot">Identifying GC roots on the stack:
+ <tt>llvm.gcroot</tt></a></li>
+ <li><a href="#barriers">Reading and writing references in the heap</a>
+ <ul>
+ <li><a href="#gcwrite">Write barrier: <tt>llvm.gcwrite</tt></a></li>
+ <li><a href="#gcread">Read barrier: <tt>llvm.gcread</tt></a></li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+
+ <li><a href="#runtime">Recommended runtime interface</a>
+ <ul>
+ <li><a href="#initialize">Garbage collector startup and
+ initialization</a></li>
+ <li><a href="#allocate">Allocating memory from the GC</a></li>
+ <li><a href="#explicit">Explicit invocation of the garbage
+ collector</a></li>
+ <li><a href="#traceroots">Tracing GC pointers from the program
+ stack</a></li>
+ <li><a href="#staticroots">Tracing GC pointers from static roots</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#plugin">Implementing a collector plugin</a>
+ <ul>
+ <li><a href="#collector-algos">Overview of available features</a></li>
+ <li><a href="#stack-map">Computing stack maps</a></li>
+ <li><a href="#init-roots">Initializing roots to null:
+ <tt>InitRoots</tt></a></li>
+ <li><a href="#custom">Custom lowering of intrinsics: <tt>CustomRoots</tt>,
+ <tt>CustomReadBarriers</tt>, and <tt>CustomWriteBarriers</tt></a></li>
+ <li><a href="#safe-points">Generating safe points:
+ <tt>NeededSafePoints</tt></a></li>
+ <li><a href="#assembly">Emitting assembly code:
+ <tt>GCMetadataPrinter</tt></a></li>
+ </ul>
+ </li>
+
+ <li><a href="#runtime-impl">Implementing a collector runtime</a>
+ <ul>
+ <li><a href="#gcdescriptors">Tracing GC pointers from heap
+ objects</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#references">References</a></li>
+
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and
+ Gordon Henriksen</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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
+ and maintain. Many programming languages rely on garbage collection for
+ automatic memory management. There are two primary forms of garbage collection:
+ conservative and accurate.</p>
+
+ <p>Conservative garbage collection often does not require any special support
+ from either the language or the compiler: it can handle non-type-safe
+ programming languages (such as C/C++) and does not require any special
+ information from the compiler. The
+ <a href="http://www.hpl.hp.com/personal/Hans_Boehm/gc/">Boehm collector</a> is
+ an example of a state-of-the-art conservative collector.</p>
+
+ <p>Accurate garbage collection requires the ability to identify all pointers in
+ the program at run-time (which requires that the source-language be type-safe in
+ most cases). Identifying pointers at run-time requires compiler support to
+ locate all places that hold live pointer variables at run-time, including the
+ <a href="#gcroot">processor stack and registers</a>.</p>
+
+ <p>Conservative garbage collection is attractive because it does not require any
+ special compiler support, but it does have problems. In particular, because the
+ conservative garbage collector cannot <i>know</i> that a particular word in the
+ machine is a pointer, it cannot move live objects in the heap (preventing the
+ use of compacting and generational GC algorithms) and it can occasionally suffer
+ from memory leaks due to integer values that happen to point to objects in the
+ program. In addition, some aggressive compiler transformations can break
+ conservative garbage collectors (though these seem rare in practice).</p>
+
+ <p>Accurate garbage collectors do not suffer from any of these problems, but
+ they can suffer from degraded scalar optimization of the program. In particular,
+ because the runtime must be able to identify and update all pointers active in
+ the program, some optimizations are less effective. In practice, however, the
+ locality and performance benefits of using aggressive garbage allocation
+ techniques dominates any low-level losses.</p>
+
+ <p>This document describes the mechanisms and interfaces provided by LLVM to
+ support accurate garbage collection.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="feature">GC features provided and algorithms supported</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM's intermediate representation provides <a href="#intrinsics">garbage
+ collection intrinsics</a> that offer support for a broad class of
+ collector models. For instance, the intrinsics permit:</p>
+
+ <ul>
+ <li>semi-space collectors</li>
+ <li>mark-sweep collectors</li>
+ <li>generational collectors</li>
+ <li>reference counting</li>
+ <li>incremental collectors</li>
+ <li>concurrent collectors</li>
+ <li>cooperative collectors</li>
+ </ul>
+
+ <p>We hope that the primitive support built into the LLVM IR is sufficient to
+ support a broad class of garbage collected languages including Scheme, ML, Java,
+ C#, Perl, Python, Lua, Ruby, other scripting languages, and more.</p>
+
+ <p>However, LLVM does not itself implement a garbage collector. This is because
+ collectors are tightly coupled to object models, and LLVM is agnostic to object
+ models. Since LLVM is agnostic to object models, it would be inappropriate for
+ LLVM to dictate any particular collector. Instead, LLVM provides a framework for
+ garbage collector implementations in two manners:</p>
+
+ <ul>
+ <li><b>At compile time</b> with <a href="#plugin">collector plugins</a> for
+ the compiler. Collector plugins have ready access to important garbage
+ collector algorithms. Leveraging these tools, it is straightforward to
+ emit type-accurate stack maps for your runtime in as little as ~100 lines of
+ C++ code.</li>
+
+ <li><b>At runtime</b> with <a href="#runtime">suggested runtime
+ interfaces</a>, which allow front-end compilers to support a range of
+ collection runtimes.</li>
+ </ul>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="usage">Using the collectors</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>In general, using a collector implies:</p>
+
+ <ul>
+ <li>Emitting compatible code, including initialization in the main
+ program if necessary.</li>
+ <li>Loading a compiler plugin if the collector is not statically linked with
+ your compiler. For <tt>llc</tt>, use the <tt>-load</tt> option.</li>
+ <li>Selecting the collection algorithm by applying the <tt>gc "..."</tt>
+ attribute to your garbage collected functions, or equivalently with
+ the <tt>setGC</tt> method.</li>
+ <li>Linking your final executable with the garbage collector runtime.</li>
+ </ul>
+
+ <p>This table summarizes the available runtimes.</p>
+
+ <table>
+ <tr>
+ <th>Collector</th>
+ <th><tt>gc</tt> attribute</th>
+ <th>Linkage</th>
+ <th><tt>gcroot</tt></th>
+ <th><tt>gcread</tt></th>
+ <th><tt>gcwrite</tt></th>
+ </tr>
+ <tr valign="baseline">
+ <td><a href="#semispace">SemiSpace</a></td>
+ <td><tt>gc "shadow-stack"</tt></td>
+ <td>TODO FIXME</td>
+ <td>required</td>
+ <td>optional</td>
+ <td>optional</td>
+ </tr>
+ <tr valign="baseline">
+ <td><a href="#ocaml">Ocaml</a></td>
+ <td><tt>gc "ocaml"</tt></td>
+ <td><i>provided by ocamlopt</i></td>
+ <td>required</td>
+ <td>optional</td>
+ <td>optional</td>
+ </tr>
+ </table>
+
+ <p>The sections for <a href="#intrinsics">Collection intrinsics</a> and
+ <a href="#runtime">Recommended runtime interface</a> detail the interfaces that
+ collectors may require user programs to utilize.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="shadow-stack">ShadowStack - A highly portable collector</a>
+ </div>
+
+ <div class="doc_code"><tt>
+ Collector *llvm::createShadowStackCollector();
+ </tt></div>
+
+ <div class="doc_text">
+
+ <p>The ShadowStack backend is invoked with the <tt>gc "shadow-stack"</tt>
+ function attribute.
+ Unlike many collectors which rely on a cooperative code generator to generate
+ stack maps, this algorithm carefully maintains a linked list of stack root
+ descriptors [<a href="#henderson02">Henderson2002</a>]. This so-called "shadow
+ stack" mirrors the machine stack. Maintaining this data structure is slower
+ than using stack maps, but has a significant portability advantage because it
+ requires no special support from the target code generator.</p>
+
+ <p>The ShadowStack collector does not use read or write barriers, so the user
+ program may use <tt>load</tt> and <tt>store</tt> instead of <tt>llvm.gcread</tt>
+ and <tt>llvm.gcwrite</tt>.</p>
+
+ <p>ShadowStack is a code generator plugin only. It must be paired with a
+ compatible runtime.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="semispace">SemiSpace - A simple copying collector runtime</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The SemiSpace runtime implements the <a href="runtime">suggested
+ runtime interface</a> and is compatible with the ShadowStack backend.</p>
+
+ <p>SemiSpace is a very simple copying collector. When it starts up, it
+ allocates two blocks of memory for the heap. It uses a simple bump-pointer
+ allocator to allocate memory from the first block until it runs out of space.
+ When it runs out of space, it traces through all of the roots of the program,
+ copying blocks to the other half of the memory space.</p>
+
+ <p>This runtime is highly experimental and has not been used in a real project.
+ Enhancements would be welcomed.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ocaml">Ocaml - An Objective Caml-compatible collector</a>
+ </div>
+
+ <div class="doc_code"><tt>
+ Collector *llvm::createOcamlCollector();
+ </tt></div>
+
+ <div class="doc_text">
+
+ <p>The ocaml backend is invoked with the <tt>gc "ocaml"</tt> function attribute.
+ It supports the
+ <a href="http://caml.inria.fr/">Objective Caml</a> language runtime by emitting
+ a type-accurate stack map in the form of an ocaml 3.10.0-compatible frametable.
+ The linkage requirements are satisfied automatically by the <tt>ocamlopt</tt>
+ compiler when linking an executable.</p>
+
+ <p>The ocaml collector does not use read or write barriers, so the user program
+ may use <tt>load</tt> and <tt>store</tt> instead of <tt>llvm.gcread</tt> and
+ <tt>llvm.gcwrite</tt>.</p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="core">Core support</a><a name="intrinsics"></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section describes the garbage collection facilities provided by the
+ <a href="LangRef.html">LLVM intermediate representation</a>.</p>
+
+ <p>These facilities are limited to those strictly necessary for compilation.
+ They are not intended to be a complete interface to any garbage collector.
+ Notably, heap allocation is not among the supplied primitives. A user program
+ will also need to interface with the runtime, using either the
+ <a href="#runtime">suggested runtime interface</a> or another interface
+ specified by the runtime.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="gcattr">Specifying GC code generation: <tt>gc "..."</tt></a>
+ </div>
+
+ <div class="doc_code"><tt>
+ define <i>ty</i> @<i>name</i>(...) <u>gc "<i>collector</i>"</u> { ...
+ </tt></div>
+
+ <div class="doc_text">
+
+ <p>The <tt>gc</tt> function attribute is used to specify the desired collector
+ algorithm to the compiler. It is equivalent to specifying the collector name
+ programmatically using the <tt>setGC</tt> method of <tt>Function</tt>.</p>
+
+ <p>Specifying the collector on a per-function basis allows LLVM to link together
+ programs that use different garbage collection algorithms.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="gcroot">Identifying GC roots on the stack: <tt>llvm.gcroot</tt></a>
+ </div>
+
+ <div class="doc_code"><tt>
+ void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
+ </tt></div>
+
+ <div class="doc_text">
+
+ <p>The <tt>llvm.gcroot</tt> intrinsic is used to inform LLVM of a pointer
+ variable on the stack. The first argument <b>must</b> be a value referring to an alloca instruction
+ or a bitcast of an alloca. The second contains a pointer to metadata that
+ should be associated with the pointer, and <b>must</b> be a constant or global
+ value address. If your target collector uses tags, use a null pointer for
+ metadata.</p>
+
+ <p>Consider the following fragment of Java code:</p>
+
+ <pre>
+ {
+ Object X; // A null-initialized reference to an object
+ ...
+ }
+ </pre>
+
+ <p>This block (which may be located in the middle of a function or in a loop
+ nest), could be compiled to this LLVM code:</p>
+
+ <pre>
+ Entry:
+ ;; In the entry block for the function, allocate the
+ ;; stack space for X, which is an LLVM pointer.
+ %X = alloca %Object*
+
+ ;; Tell LLVM that the stack space is a stack root.
+ ;; Java has type-tags on objects, so we pass null as metadata.
+ %tmp = bitcast %Object** %X to i8**
+ call void @llvm.gcroot(i8** %X, i8* null)
+ ...
+
+ ;; "CodeBlock" is the block corresponding to the start
+ ;; of the scope above.
+ CodeBlock:
+ ;; Java null-initializes pointers.
+ store %Object* null, %Object** %X
+
+ ...
+
+ ;; As the pointer goes out of scope, store a null value into
+ ;; it, to indicate that the value is no longer live.
+ store %Object* null, %Object** %X
+ ...
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="barriers">Reading and writing references in the heap</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>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
+ of a heap object. The code fragments inserted at these points are called
+ <em>read barriers</em> and <em>write barriers</em>, respectively. The amount of
+ code that needs to be executed is usually quite small and not on the critical
+ path of any computation, so the overall performance impact of the barrier is
+ tolerable.</p>
+
+ <p>Barriers often require access to the <em>object pointer</em> rather than the
+ <em>derived pointer</em> (which is a pointer to the field within the
+ object). Accordingly, these intrinsics take both pointers as separate arguments
+ for completeness. In this snippet, <tt>%object</tt> is the object pointer, and
+ <tt>%derived</tt> is the derived pointer:</p>
+
+ <blockquote><pre>
+ ;; An array type.
+ %class.Array = type { %class.Object, i32, [0 x %class.Object*] }
+ ...
+
+ ;; Load the object pointer from a gcroot.
+ %object = load %class.Array** %object_addr
+
+ ;; Compute the derived pointer.
+ %derived = getelementptr %object, i32 0, i32 2, i32 %n</pre></blockquote>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="gcwrite">Write barrier: <tt>llvm.gcwrite</tt></a>
+ </div>
+
+ <div class="doc_code"><tt>
+ void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived)
+ </tt></div>
+
+ <div class="doc_text">
+
+ <p>For write barriers, LLVM provides the <tt>llvm.gcwrite</tt> intrinsic
+ function. It has exactly the same semantics as a non-volatile <tt>store</tt> to
+ the derived pointer (the third argument).</p>
+
+ <p>Many important algorithms require write barriers, including generational
+ and concurrent collectors. Additionally, write barriers could be used to
+ implement reference counting.</p>
+
+ <p>The use of this intrinsic is optional if the target collector does use
+ write barriers. If so, the collector will replace it with the corresponding
+ <tt>store</tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="gcread">Read barrier: <tt>llvm.gcread</tt></a>
+ </div>
+
+ <div class="doc_code"><tt>
+ i8* @llvm.gcread(i8* %object, i8** %derived)<br>
+ </tt></div>
+
+ <div class="doc_text">
+
+ <p>For read barriers, LLVM provides the <tt>llvm.gcread</tt> intrinsic function.
+ It has exactly the same semantics as a non-volatile <tt>load</tt> from the
+ derived pointer (the second argument).</p>
+
+ <p>Read barriers are needed by fewer algorithms than write barriers, and may
+ have a greater performance impact since pointer reads are more frequent than
+ writes.</p>
+
+ <p>As with <tt>llvm.gcwrite</tt>, a target collector might not require the use
+ of this intrinsic.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="runtime">Recommended runtime interface</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM specifies the following recommended runtime interface to the garbage
+ collection at runtime. A program should use these interfaces to accomplish the
+ tasks not supported by the intrinsics.</p>
+
+ <p>Unlike the intrinsics, which are integral to LLVM's code generator, there is
+ nothing unique about these interfaces; a front-end compiler and runtime are free
+ to agree to a different specification.</p>
+
+ <p class="doc_warning">Note: This interface is a work in progress.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="initialize">Garbage collector startup and initialization</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><tt>
+ void llvm_gc_initialize(unsigned InitialHeapSize);
+ </tt></div>
+
+ <p>
+ The <tt>llvm_gc_initialize</tt> function should be called once before any other
+ garbage collection functions are called. This gives the garbage collector the
+ chance to initialize itself and allocate the heap. The initial heap size to
+ allocate should be specified as an argument.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="allocate">Allocating memory from the GC</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><tt>
+ void *llvm_gc_allocate(unsigned Size);
+ </tt></div>
+
+ <p>The <tt>llvm_gc_allocate</tt> function is a global function defined by the
+ garbage collector implementation to allocate memory. It returns a
+ zeroed-out block of memory of the specified size, sufficiently aligned to store
+ any object.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="explicit">Explicit invocation of the garbage collector</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><tt>
+ void llvm_gc_collect();
+ </tt></div>
+
+ <p>
+ The <tt>llvm_gc_collect</tt> function is exported by the garbage collector
+ implementations to provide a full collection, even when the heap is not
+ exhausted. This can be used by end-user code as a hint, and may be ignored by
+ the garbage collector.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="traceroots">Tracing GC pointers from the program stack</a>
+ </div>
+
+ <div class="doc_text">
+ <div class="doc_code"><tt>
+ void llvm_cg_walk_gcroots(void (*FP)(void **Root, void *Meta));
+ </tt></div>
+
+ <p>
+ The <tt>llvm_cg_walk_gcroots</tt> function is a function provided by the code
+ generator that iterates through all of the GC roots on the stack, calling the
+ specified function pointer with each record. For each GC root, the address of
+ the pointer and the meta-data (from the <a
+ href="#gcroot"><tt>llvm.gcroot</tt></a> intrinsic) are provided.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="staticroots">Tracing GC pointers from static roots</a>
+ </div>
+
+ <div class="doc_text">
+ TODO
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="plugin">Implementing a collector plugin</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>User code specifies which GC code generation to use with the <tt>gc</tt>
+ function attribute or, equivalently, with the <tt>setGC</tt> method of
+ <tt>Function</tt>.</p>
+
+ <p>To implement a GC plugin, it is necessary to subclass
+ <tt>llvm::GCStrategy</tt>, which can be accomplished in a few lines of
+ boilerplate code. LLVM's infrastructure provides access to several important
+ algorithms. For an uncontroversial collector, all that remains may be to emit
+ the assembly code for the collector's unique stack map data structure, which
+ might be accomplished in as few as 100 LOC.</p>
+
+ <p>This is not the appropriate place to implement a garbage collected heap or a
+ garbage collector itself. That code should exist in the language's runtime
+ library. The compiler plugin is responsible for generating code which is
+ compatible with that runtime library.</p>
+
+ <p>To subclass <tt>llvm::GCStrategy</tt> and register it with the compiler:</p>
+
+ <blockquote><pre>// lib/MyGC/MyGC.cpp - Example LLVM GC plugin
+
+ #include "llvm/CodeGen/GCStrategy.h"
+ #include "llvm/CodeGen/GCMetadata.h"
+ #include "llvm/Support/Compiler.h"
+
+ using namespace llvm;
+
+ namespace {
+ class VISIBILITY_HIDDEN MyGC : public GCStrategy {
+ public:
+ MyGC() {}
+ };
+
+ GCRegistry::Add<MyGC>
+ X("mygc", "My bespoke garbage collector.");
+ }</pre></blockquote>
+
+ <p>Using the LLVM makefiles (like the <a
+ href="http://llvm.org/viewvc/llvm-project/llvm/trunk/projects/sample/">sample
+ project</a>), this can be built into a plugin using a simple makefile:</p>
+
+ <blockquote><pre
+ ># lib/MyGC/Makefile
+
+ LEVEL := ../..
+ LIBRARYNAME = <var>MyGC</var>
+ LOADABLE_MODULE = 1
+
+ include $(LEVEL)/Makefile.common</pre></blockquote>
+
+ <p>Once the plugin is compiled, code using it may be compiled using <tt>llc
+ -load=<var>MyGC.so</var></tt> (though <var>MyGC.so</var> may have some other
+ platform-specific extension):</p>
+
+ <blockquote><pre
+ >$ cat sample.ll
+ define void @f() gc "mygc" {
+ entry:
+ ret void
+ }
+ $ llvm-as < sample.ll | llc -load=MyGC.so</pre></blockquote>
+
+ <p>It is also possible to statically link the collector plugin into tools, such
+ as a language-specific compiler front-end.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="collector-algos">Overview of available features</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The boilerplate collector above does nothing. More specifically:</p>
+
+ <ul>
+ <li><tt>llvm.gcread</tt> calls are replaced with the corresponding
+ <tt>load</tt> instruction.</li>
+ <li><tt>llvm.gcwrite</tt> calls are replaced with the corresponding
+ <tt>store</tt> instruction.</li>
+ <li>No stack map is emitted, and no safe points are added.</li>
+ </ul>
+
+ <p><tt>Collector</tt> provides a range of features through which a plugin
+ collector may do useful work. This matrix summarizes the supported (and planned)
+ features and correlates them with the collection techniques which typically
+ require them.</p>
+
+ <table>
+ <tr>
+ <th>Algorithm</th>
+ <th>Done</th>
+ <th>shadow stack</th>
+ <th>refcount</th>
+ <th>mark-sweep</th>
+ <th>copying</th>
+ <th>incremental</th>
+ <th>threaded</th>
+ <th>concurrent</th>
+ </tr>
+ <tr>
+ <th class="rowhead"><a href="#stack-map">stack map</a></th>
+ <td>✔</td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr>
+ <th class="rowhead"><a href="#init-roots">initialize roots</a></th>
+ <td>✔</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead">derived pointers</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td>✘*</td>
+ <td>✘*</td>
+ </tr>
+ <tr>
+ <th class="rowhead"><em><a href="#custom">custom lowering</a></em></th>
+ <td>✔</td>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ </tr>
+ <tr>
+ <th class="rowhead indent">gcroot</th>
+ <td>✔</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ </tr>
+ <tr>
+ <th class="rowhead indent">gcwrite</th>
+ <td>✔</td>
+ <td></td>
+ <td>✘</td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td></td>
+ <td>✘</td>
+ </tr>
+ <tr>
+ <th class="rowhead indent">gcread</th>
+ <td>✔</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ </tr>
+ <tr>
+ <th class="rowhead"><em><a href="#safe-points">safe points</a></em></th>
+ <td></td>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ </tr>
+ <tr>
+ <th class="rowhead indent">in calls</th>
+ <td>✔</td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr>
+ <th class="rowhead indent">before calls</th>
+ <td>✔</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead indent">for loops</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr>
+ <th class="rowhead indent">before escape</th>
+ <td>✔</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead">emit code at safe points</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr>
+ <th class="rowhead"><em>output</em></th>
+ <td></td>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ <th></th>
+ </tr>
+ <tr>
+ <th class="rowhead indent"><a href="#assembly">assembly</a></th>
+ <td>✔</td>
+ <td></td>
+ <td></td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ <td>✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead indent">JIT</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead indent">obj</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead">live analysis</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ </tr>
+ <tr class="doc_warning">
+ <th class="rowhead">register map</th>
+ <td>NO</td>
+ <td></td>
+ <td></td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ <td class="optl">✘</td>
+ </tr>
+ <tr>
+ <td colspan="10">
+ <div><span class="doc_warning">*</span> Derived pointers only pose a
+ hazard to copying collectors.</div>
+ <div><span class="optl">✘</span> in gray denotes a feature which
+ could be utilized if available.</div>
+ </td>
+ </tr>
+ </table>
+
+ <p>To be clear, the collection techniques above are defined as:</p>
+
+ <dl>
+ <dt>Shadow Stack</dt>
+ <dd>The mutator carefully maintains a linked list of stack root
+ descriptors.</dd>
+ <dt>Reference Counting</dt>
+ <dd>The mutator maintains a reference count for each object and frees an
+ object when its count falls to zero.</dd>
+ <dt>Mark-Sweep</dt>
+ <dd>When the heap is exhausted, the collector marks reachable objects starting
+ from the roots, then deallocates unreachable objects in a sweep
+ phase.</dd>
+ <dt>Copying</dt>
+ <dd>As reachability analysis proceeds, the collector copies objects from one
+ heap area to another, compacting them in the process. Copying collectors
+ enable highly efficient "bump pointer" allocation and can improve locality
+ of reference.</dd>
+ <dt>Incremental</dt>
+ <dd>(Including generational collectors.) Incremental collectors generally have
+ all the properties of a copying collector (regardless of whether the
+ mature heap is compacting), but bring the added complexity of requiring
+ write barriers.</dd>
+ <dt>Threaded</dt>
+ <dd>Denotes a multithreaded mutator; the collector must still stop the mutator
+ ("stop the world") before beginning reachability analysis. Stopping a
+ multithreaded mutator is a complicated problem. It generally requires
+ highly platform specific code in the runtime, and the production of
+ carefully designed machine code at safe points.</dd>
+ <dt>Concurrent</dt>
+ <dd>In this technique, the mutator and the collector run concurrently, with
+ the goal of eliminating pause times. In a <em>cooperative</em> collector,
+ the mutator further aids with collection should a pause occur, allowing
+ collection to take advantage of multiprocessor hosts. The "stop the world"
+ problem of threaded collectors is generally still present to a limited
+ extent. Sophisticated marking algorithms are necessary. Read barriers may
+ be necessary.</dd>
+ </dl>
+
+ <p>As the matrix indicates, LLVM's garbage collection infrastructure is already
+ suitable for a wide variety of collectors, but does not currently extend to
+ multithreaded programs. This will be added in the future as there is
+ interest.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="stack-map">Computing stack maps</a>
+ </div>
+
+ <div class="doc_text">
+
+ <blockquote><pre
+ >for (iterator I = begin(), E = end(); I != E; ++I) {
+ GCFunctionInfo *FI = *I;
+ unsigned FrameSize = FI->getFrameSize();
+ size_t RootCount = FI->roots_size();
+
+ for (GCFunctionInfo::roots_iterator RI = FI->roots_begin(),
+ RE = FI->roots_end();
+ RI != RE; ++RI) {
+ int RootNum = RI->Num;
+ int RootStackOffset = RI->StackOffset;
+ Constant *RootMetadata = RI->Metadata;
+ }
+ }</pre></blockquote>
+
+ <p>LLVM automatically computes a stack map. All a <tt>GCStrategy</tt> needs to do
+ is access it using <tt>GCFunctionMetadata::roots_begin()</tt> and
+ -<tt>end()</tt>. If the <tt>llvm.gcroot</tt> intrinsic is eliminated before code
+ generation by a custom lowering pass, LLVM's stack map will be empty.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="init-roots">Initializing roots to null: <tt>InitRoots</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <blockquote><pre
+ >MyGC::MyGC() {
+ InitRoots = true;
+ }</pre></blockquote>
+
+ <p>When set, LLVM will automatically initialize each root to <tt>null</tt> upon
+ entry to the function. This prevents the GC's sweep phase from visiting
+ uninitialized pointers, which will almost certainly cause it to crash. This
+ initialization occurs before custom lowering, so the two may be used
+ together.</p>
+
+ <p>Since LLVM does not yet compute liveness information, there is no means of
+ distinguishing an uninitialized stack root from an initialized one. Therefore,
+ this feature should be used by all GC plugins. It is enabled by default.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="custom">Custom lowering of intrinsics: <tt>CustomRoots</tt>,
+ <tt>CustomReadBarriers</tt>, and <tt>CustomWriteBarriers</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>For GCs which use barriers or unusual treatment of stack roots, these
+ flags allow the collector to perform arbitrary transformations of the LLVM
+ IR:</p>
+
+ <blockquote><pre
+ >class MyGC : public GCStrategy {
+ public:
+ MyGC() {
+ CustomRoots = true;
+ CustomReadBarriers = true;
+ CustomWriteBarriers = true;
+ }
+
+ virtual bool initializeCustomLowering(Module &M);
+ virtual bool performCustomLowering(Function &F);
+ };</pre></blockquote>
+
+ <p>If any of these flags are set, then LLVM suppresses its default lowering for
+ the corresponding intrinsics and instead calls
+ <tt>performCustomLowering</tt>.</p>
+
+ <p>LLVM's default action for each intrinsic is as follows:</p>
+
+ <ul>
+ <li><tt>llvm.gcroot</tt>: Pass through to the code generator to generate a
+ stack map.</li>
+ <li><tt>llvm.gcread</tt>: Substitute a <tt>load</tt> instruction.</li>
+ <li><tt>llvm.gcwrite</tt>: Substitute a <tt>store</tt> instruction.</li>
+ </ul>
+
+ <p>If <tt>CustomReadBarriers</tt> or <tt>CustomWriteBarriers</tt> are specified,
+ then <tt>performCustomLowering</tt> <strong>must</strong> eliminate the
+ corresponding barriers.</p>
+
+ <p><tt>performCustomLowering</tt> must comply with the same restrictions as <a
+ href="WritingAnLLVMPass.html#runOnFunction"><tt
+ >FunctionPass::runOnFunction</tt></a>.
+ Likewise, <tt>initializeCustomLowering</tt> has the same semantics as <a
+ href="WritingAnLLVMPass.html#doInitialization_mod"><tt
+ >Pass::doInitialization(Module&)</tt></a>.</p>
+
+ <p>The following can be used as a template:</p>
+
+ <blockquote><pre
+ >#include "llvm/Module.h"
+ #include "llvm/IntrinsicInst.h"
+
+ bool MyGC::initializeCustomLowering(Module &M) {
+ return false;
+ }
+
+ bool MyGC::performCustomLowering(Function &F) {
+ bool MadeChange = false;
+
+ for (Function::iterator BB = F.begin(), E = F.end(); BB != E; ++BB)
+ for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; )
+ if (IntrinsicInst *CI = dyn_cast<IntrinsicInst>(II++))
+ if (Function *F = CI->getCalledFunction())
+ switch (F->getIntrinsicID()) {
+ case Intrinsic::gcwrite:
+ // Handle llvm.gcwrite.
+ CI->eraseFromParent();
+ MadeChange = true;
+ break;
+ case Intrinsic::gcread:
+ // Handle llvm.gcread.
+ CI->eraseFromParent();
+ MadeChange = true;
+ break;
+ case Intrinsic::gcroot:
+ // Handle llvm.gcroot.
+ CI->eraseFromParent();
+ MadeChange = true;
+ break;
+ }
+
+ return MadeChange;
+ }</pre></blockquote>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="safe-points">Generating safe points: <tt>NeededSafePoints</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM can compute four kinds of safe points:</p>
+
+ <blockquote><pre
+ >namespace GC {
+ /// PointKind - The type of a collector-safe point.
+ ///
+ enum PointKind {
+ Loop, //< Instr is a loop (backwards branch).
+ Return, //< Instr is a return instruction.
+ PreCall, //< Instr is a call instruction.
+ PostCall //< Instr is the return address of a call.
+ };
+ }</pre></blockquote>
+
+ <p>A collector can request any combination of the four by setting the
+ <tt>NeededSafePoints</tt> mask:</p>
+
+ <blockquote><pre
+ >MyGC::MyGC() {
+ NeededSafePoints = 1 << GC::Loop
+ | 1 << GC::Return
+ | 1 << GC::PreCall
+ | 1 << GC::PostCall;
+ }</pre></blockquote>
+
+ <p>It can then use the following routines to access safe points.</p>
+
+ <blockquote><pre
+ >for (iterator I = begin(), E = end(); I != E; ++I) {
+ GCFunctionInfo *MD = *I;
+ size_t PointCount = MD->size();
+
+ for (GCFunctionInfo::iterator PI = MD->begin(),
+ PE = MD->end(); PI != PE; ++PI) {
+ GC::PointKind PointKind = PI->Kind;
+ unsigned PointNum = PI->Num;
+ }
+ }
+ </pre></blockquote>
+
+ <p>Almost every collector requires <tt>PostCall</tt> safe points, since these
+ correspond to the moments when the function is suspended during a call to a
+ subroutine.</p>
+
+ <p>Threaded programs generally require <tt>Loop</tt> safe points to guarantee
+ that the application will reach a safe point within a bounded amount of time,
+ even if it is executing a long-running loop which contains no function
+ calls.</p>
+
+ <p>Threaded collectors may also require <tt>Return</tt> and <tt>PreCall</tt>
+ safe points to implement "stop the world" techniques using self-modifying code,
+ where it is important that the program not exit the function without reaching a
+ safe point (because only the topmost function has been patched).</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="assembly">Emitting assembly code: <tt>GCMetadataPrinter</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM allows a GC 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 print stack
+ maps built by the code generator. (At the beginning, this information is not
+ yet computed.)</p>
+
+ <p>Since AsmWriter and CodeGen are separate components of LLVM, a separate
+ abstract base class and registry is provided for printing assembly code, the
+ <tt>GCMetadaPrinter</tt> and <tt>GCMetadaPrinterRegistry</tt>. The AsmWriter
+ will look for such a subclass if the <tt>GCStrategy</tt> sets
+ <tt>UsesMetadata</tt>:</p>
+
+ <blockquote><pre
+ >MyGC::MyGC() {
+ UsesMetadata = true;
+ }</pre></blockquote>
+
+ <p>Note that LLVM does not currently have analogous APIs to support code
+ generation in the JIT, nor using the object writers.</p>
+
+ <blockquote><pre
+ >// lib/MyGC/MyGCPrinter.cpp - Example LLVM GC printer
+
+ #include "llvm/CodeGen/GCMetadataPrinter.h"
+ #include "llvm/Support/Compiler.h"
+
+ using namespace llvm;
+
+ namespace {
+ class VISIBILITY_HIDDEN MyGCPrinter : public GCMetadataPrinter {
+ public:
+ virtual void beginAssembly(std::ostream &OS, AsmPrinter &AP,
+ const TargetAsmInfo &TAI);
+
+ virtual void finishAssembly(std::ostream &OS, AsmPrinter &AP,
+ const TargetAsmInfo &TAI);
+ };
+
+ GCMetadataPrinterRegistry::Add<MyGCPrinter>
+ X("mygc", "My bespoke garbage collector.");
+ }</pre></blockquote>
+
+ <p>The collector should use <tt>AsmPrinter</tt> and <tt>TargetAsmInfo</tt> to
+ print portable assembly code to the <tt>std::ostream</tt>. The collector itself
+ contains the stack map for the entire module, and may access the
+ <tt>GCFunctionInfo</tt> using its own <tt>begin()</tt> and <tt>end()</tt>
+ methods. Here's a realistic example:</p>
+
+ <blockquote><pre
+ >#include "llvm/CodeGen/AsmPrinter.h"
+ #include "llvm/Function.h"
+ #include "llvm/Target/TargetMachine.h"
+ #include "llvm/Target/TargetData.h"
+ #include "llvm/Target/TargetAsmInfo.h"
+
+ void MyGCPrinter::beginAssembly(std::ostream &OS, AsmPrinter &AP,
+ const TargetAsmInfo &TAI) {
+ // Nothing to do.
+ }
+
+ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
+ const TargetAsmInfo &TAI) {
+ // Set up for emitting addresses.
+ const char *AddressDirective;
+ int AddressAlignLog;
+ if (AP.TM.getTargetData()->getPointerSize() == sizeof(int32_t)) {
+ AddressDirective = TAI.getData32bitsDirective();
+ AddressAlignLog = 2;
+ } else {
+ AddressDirective = TAI.getData64bitsDirective();
+ AddressAlignLog = 3;
+ }
+
+ // Put this in the data section.
+ AP.SwitchToDataSection(TAI.getDataSection());
+
+ // For each function...
+ for (iterator FI = begin(), FE = end(); FI != FE; ++FI) {
+ GCFunctionInfo &MD = **FI;
+
+ // Emit this data structure:
+ //
+ // struct {
+ // int32_t PointCount;
+ // struct {
+ // void *SafePointAddress;
+ // int32_t LiveCount;
+ // int32_t LiveOffsets[LiveCount];
+ // } Points[PointCount];
+ // } __gcmap_<FUNCTIONNAME>;
+
+ // Align to address width.
+ AP.EmitAlignment(AddressAlignLog);
+
+ // Emit the symbol by which the stack map can be found.
+ std::string Symbol;
+ Symbol += TAI.getGlobalPrefix();
+ Symbol += "__gcmap_";
+ Symbol += MD.getFunction().getName();
+ if (const char *GlobalDirective = TAI.getGlobalDirective())
+ OS << GlobalDirective << Symbol << "\n";
+ OS << TAI.getGlobalPrefix() << Symbol << ":\n";
+
+ // Emit PointCount.
+ AP.EmitInt32(MD.size());
+ AP.EOL("safe point count");
+
+ // And each safe point...
+ for (GCFunctionInfo::iterator PI = MD.begin(),
+ PE = MD.end(); PI != PE; ++PI) {
+ // Align to address width.
+ AP.EmitAlignment(AddressAlignLog);
+
+ // Emit the address of the safe point.
+ OS << AddressDirective
+ << TAI.getPrivateGlobalPrefix() << "label" << PI->Num;
+ AP.EOL("safe point address");
+
+ // Emit the stack frame size.
+ AP.EmitInt32(MD.getFrameSize());
+ AP.EOL("stack frame size");
+
+ // Emit the number of live roots in the function.
+ AP.EmitInt32(MD.live_size(PI));
+ AP.EOL("live root count");
+
+ // And for each live root...
+ for (GCFunctionInfo::live_iterator LI = MD.live_begin(PI),
+ LE = MD.live_end(PI);
+ LI != LE; ++LI) {
+ // Print its offset within the stack frame.
+ AP.EmitInt32(LI->StackOffset);
+ AP.EOL("stack offset");
+ }
+ }
+ }
+ }
+ </pre></blockquote>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="runtime-impl">Implementing a collector runtime</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Implementing a garbage collector for LLVM is fairly straightforward. The
+ LLVM garbage collectors are provided in a form that makes them easy to link into
+ the language-specific runtime that a language front-end would use. They require
+ functionality from the language-specific runtime to get information about <a
+ href="#gcdescriptors">where pointers are located in heap objects</a>.</p>
+
+ <p>The implementation must include the
+ <a href="#allocate"><tt>llvm_gc_allocate</tt></a> and
+ <a href="#explicit"><tt>llvm_gc_collect</tt></a> functions. To do this, it will
+ probably have to <a href="#traceroots">trace through the roots
+ from the stack</a> and understand the <a href="#gcdescriptors">GC descriptors
+ for heap objects</a>. Luckily, there are some <a href="#usage">example
+ implementations</a> available.
+ </p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="gcdescriptors">Tracing GC pointers from heap objects</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The three most common ways to keep track of where pointers live in heap objects
+ are (listed in order of space overhead required):</p>
+
+ <ol>
+ <li>In languages with polymorphic objects, pointers from an object header are
+ usually used to identify the GC pointers in the heap object. This is common for
+ object-oriented languages like Self, Smalltalk, Java, or C#.</li>
+
+ <li>If heap objects are not polymorphic, often the "shape" of the heap can be
+ determined from the roots of the heap or from some other meta-data [<a
+ href="#appel89">Appel89</a>, <a href="#goldberg91">Goldberg91</a>, <a
+ href="#tolmach94">Tolmach94</a>]. In this case, the garbage collector can
+ propagate the information around from meta data stored with the roots. This
+ often eliminates the need to have a header on objects in the heap. This is
+ common in the ML family.</li>
+
+ <li>If all heap objects have pointers in the same locations, or pointers can be
+ distinguished just by looking at them (e.g., the low order bit is clear), no
+ book-keeping is needed at all. This is common for Lisp-like languages.</li>
+ </ol>
+
+ <p>The LLVM garbage collectors are capable of supporting all of these styles of
+ language, including ones that mix various implementations. To do this, it
+ allows the source-language to associate meta-data with the <a
+ href="#gcroot">stack roots</a>, and the heap tracing routines can propagate the
+ information. In addition, LLVM allows the front-end to extract GC information
+ in any form from a specific object pointer (this supports situations #1 and #3).
+ </p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="references">References</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><a name="appel89">[Appel89]</a> Runtime Tags Aren't Necessary. Andrew
+ W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.</p>
+
+ <p><a name="goldberg91">[Goldberg91]</a> Tag-free garbage collection for
+ strongly typed programming languages. Benjamin Goldberg. ACM SIGPLAN
+ PLDI'91.</p>
+
+ <p><a name="tolmach94">[Tolmach94]</a> Tag-free garbage collection using
+ explicit type parameters. Andrew Tolmach. Proceedings of the 1994 ACM
+ conference on LISP and functional programming.</p>
+
+ <p><a name="henderson02">[Henderson2002]</a> <a
+ href="http://citeseer.ist.psu.edu/henderson02accurate.html">
+ Accurate Garbage Collection in an Uncooperative Environment</a>.
+ Fergus Henderson. International Symposium on Memory Management 2002.</p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/GetElementPtr.html
diff -c /dev/null llvm-www/releases/2.5/docs/GetElementPtr.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/GetElementPtr.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,370 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>The Often Misunderstood GEP Instruction</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <style type="text/css">
+ TABLE { text-align: left; border: 1px solid black; border-collapse: collapse; margin: 0 0 0 0; }
+ </style>
+ </head>
+ <body>
+
+ <div class="doc_title">
+ The Often Misunderstood GEP Instruction
+ </div>
+
+ <ol>
+ <li><a href="#intro">Introduction</a></li>
+ <li><a href="#questions">The Questions</a>
+ <ol>
+ <li><a href="#extra_index">Why is the extra 0 index required?</a></li>
+ <li><a href="#deref">What is dereferenced by GEP?</a></li>
+ <li><a href="#firstptr">Why can you index through the first pointer but not
+ subsequent ones?</a></li>
+ <li><a href="#lead0">Why don't GEP x,0,0,1 and GEP x,1 alias? </a></li>
+ <li><a href="#trail0">Why do GEP x,1,0,0 and GEP x,1 alias? </a></li>
+ </ol></li>
+ <li><a href="#summary">Summary</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by: <a href="mailto:rspencer at reidspencer.com">Reid Spencer</a>.</p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="intro"><b>Introduction</b></a></div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>This document seeks to dispel the mystery and confusion surrounding LLVM's
+ GetElementPtr (GEP) instruction. Questions about the wiley GEP instruction are
+ probably the most frequently occuring questions once a developer gets down to
+ coding with LLVM. Here we lay out the sources of confusion and show that the
+ GEP instruction is really quite simple.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="questions"><b>The Questions</b></a></div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>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. However, GEP is a little different and
+ this leads to the following questions; all of which are answered in the
+ following sections.</p>
+ <ol>
+ <li><a href="#firstptr">What is the first index of the GEP instruction?</a>
+ </li>
+ <li><a href="#extra_index">Why is the extra 0 index required?</a></li>
+ <li><a href="#deref">What is dereferenced by GEP?</a></li>
+ <li><a href="#lead0">Why don't GEP x,0,0,1 and GEP x,1 alias? </a></li>
+ <li><a href="#trail0">Why do GEP x,1,0,0 and GEP x,1 alias? </a></li>
+ </ol>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_subsection">
+ <a name="firstptr"><b>What is the first index of the GEP instruction?</b></a>
+ </div>
+ <div class="doc_text">
+ <p>Quick answer: The index stepping through the first operand.</p>
+ <p>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
+ same. For example, when we write, in "C":</p>
+
+ <div class="doc_code">
+ <pre>
+ AType *Foo;
+ ...
+ X = &Foo->F;
+ </pre>
+ </div>
+
+ <p>it is natural to think that there is only one index, the selection of the
+ field <tt>F</tt>. However, in this example, <tt>Foo</tt> is a pointer. That
+ pointer must be indexed explicitly in LLVM. C, on the other hand, indexs
+ through it transparently. To arrive at the same address location as the C
+ code, you would provide the GEP instruction with two index operands. The
+ first operand indexes through the pointer; the second operand indexes the
+ field <tt>F</tt> of the structure, just as if you wrote:</p>
+
+ <div class="doc_code">
+ <pre>
+ X = &Foo[0].F;
+ </pre>
+ </div>
+
+ <p>Sometimes this question gets rephrased as:</p>
+ <blockquote><p><i>Why is it okay to index through the first pointer, but
+ subsequent pointers won't be dereferenced?</i></p></blockquote>
+ <p>The answer is simply because memory does not have to be accessed to
+ perform the computation. The first operand to the GEP instruction must be a
+ value of a pointer type. The value of the pointer is provided directly to
+ the GEP instruction as an operand without any need for accessing memory. It
+ must, therefore be indexed and requires an index operand. Consider this
+ example:</p>
+
+ <div class="doc_code">
+ <pre>
+ struct munger_struct {
+ int f1;
+ int f2;
+ };
+ void munge(struct munger_struct *P) {
+ P[0].f1 = P[1].f1 + P[2].f2;
+ }
+ ...
+ munger_struct Array[3];
+ ...
+ munge(Array);
+ </pre>
+ </div>
+
+ <p>In this "C" example, the front end compiler (llvm-gcc) will generate three
+ GEP instructions for the three indices through "P" in the assignment
+ statement. The function argument <tt>P</tt> will be the first operand of each
+ of these GEP instructions. The second operand indexes through that pointer.
+ The third operand will be the field offset into the
+ <tt>struct munger_struct</tt> type, for either the <tt>f1</tt> or
+ <tt>f2</tt> field. So, in LLVM assembly the <tt>munge</tt> function looks
+ like:</p>
+
+ <div class="doc_code">
+ <pre>
+ void %munge(%struct.munger_struct* %P) {
+ entry:
+ %tmp = getelementptr %struct.munger_struct* %P, i32 1, i32 0
+ %tmp = load i32* %tmp
+ %tmp6 = getelementptr %struct.munger_struct* %P, i32 2, i32 1
+ %tmp7 = load i32* %tmp6
+ %tmp8 = add i32 %tmp7, %tmp
+ %tmp9 = getelementptr %struct.munger_struct* %P, i32 0, i32 0
+ store i32 %tmp8, i32* %tmp9
+ ret void
+ }
+ </pre>
+ </div>
+
+ <p>In each case the first operand is the pointer through which the GEP
+ instruction starts. The same is true whether the first operand is an
+ argument, allocated memory, or a global variable. </p>
+ <p>To make this clear, let's consider a more obtuse example:</p>
+
+ <div class="doc_code">
+ <pre>
+ %MyVar = unintialized global i32
+ ...
+ %idx1 = getelementptr i32* %MyVar, i64 0
+ %idx2 = getelementptr i32* %MyVar, i64 1
+ %idx3 = getelementptr i32* %MyVar, i64 2
+ </pre>
+ </div>
+
+ <p>These GEP instructions are simply making address computations from the
+ base address of <tt>MyVar</tt>. They compute, as follows (using C syntax):
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ idx1 = (char*) &MyVar + 0
+ idx2 = (char*) &MyVar + 4
+ idx3 = (char*) &MyVar + 8
+ </pre>
+ </div>
+
+ <p>Since the type <tt>i32</tt> is known to be four bytes long, the indices
+ 0, 1 and 2 translate into memory offsets of 0, 4, and 8, respectively. No
+ memory is accessed to make these computations because the address of
+ <tt>%MyVar</tt> is passed directly to the GEP instructions.</p>
+ <p>The obtuse part of this example is in the cases of <tt>%idx2</tt> and
+ <tt>%idx3</tt>. They result in the computation of addresses that point to
+ memory past the end of the <tt>%MyVar</tt> global, which is only one
+ <tt>i32</tt> long, not three <tt>i32</tt>s long. While this is legal in LLVM,
+ it is inadvisable because any load or store with the pointer that results
+ from these GEP instructions would produce undefined results.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_subsection">
+ <a name="extra_index"><b>Why is the extra 0 index required?</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>Quick answer: there are no superfluous indices.</p>
+ <p>This question arises most often when the GEP instruction is applied to a
+ global variable which is always a pointer type. For example, consider
+ this:</p>
+
+ <div class="doc_code">
+ <pre>
+ %MyStruct = uninitialized global { float*, i32 }
+ ...
+ %idx = getelementptr { float*, i32 }* %MyStruct, i64 0, i32 1
+ </pre>
+ </div>
+
+ <p>The GEP above yields an <tt>i32*</tt> by indexing the <tt>i32</tt> typed
+ field of the structure <tt>%MyStruct</tt>. When people first look at it, they
+ wonder why the <tt>i64 0</tt> index is needed. However, a closer inspection
+ of how globals and GEPs work reveals the need. Becoming aware of the following
+ facts will dispell the confusion:</p>
+ <ol>
+ <li>The type of <tt>%MyStruct</tt> is <i>not</i> <tt>{ float*, i32 }</tt>
+ but rather <tt>{ float*, i32 }*</tt>. That is, <tt>%MyStruct</tt> is a
+ pointer to a structure containing a pointer to a <tt>float</tt> and an
+ <tt>i32</tt>.</li>
+ <li>Point #1 is evidenced by noticing the type of the first operand of
+ the GEP instruction (<tt>%MyStruct</tt>) which is
+ <tt>{ float*, i32 }*</tt>.</li>
+ <li>The first index, <tt>i64 0</tt> is required to step over the global
+ variable <tt>%MyStruct</tt>. Since the first argument to the GEP
+ instruction must always be a value of pointer type, the first index
+ steps through that pointer. A value of 0 means 0 elements offset from that
+ pointer.</li>
+ <li>The second index, <tt>i32 1</tt> selects the second field of the
+ structure (the <tt>i32</tt>). </li>
+ </ol>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_subsection">
+ <a name="deref"><b>What is dereferenced by GEP?</b></a>
+ </div>
+ <div class="doc_text">
+ <p>Quick answer: nothing.</p>
+ <p>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.
+ GEP is only involved in the computation of addresses. For example, consider
+ this:</p>
+
+ <div class="doc_code">
+ <pre>
+ %MyVar = uninitialized global { [40 x i32 ]* }
+ ...
+ %idx = getelementptr { [40 x i32]* }* %MyVar, i64 0, i32 0, i64 0, i64 17
+ </pre>
+ </div>
+
+ <p>In this example, we have a global variable, <tt>%MyVar</tt> that is a
+ pointer to a structure containing a pointer to an array of 40 ints. The
+ GEP instruction seems to be accessing the 18th integer of the structure's
+ array of ints. However, this is actually an illegal GEP instruction. It
+ won't compile. The reason is that the pointer in the structure <i>must</i>
+ be dereferenced in order to index into the array of 40 ints. Since the
+ GEP instruction never accesses memory, it is illegal.</p>
+ <p>In order to access the 18th integer in the array, you would need to do the
+ following:</p>
+
+ <div class="doc_code">
+ <pre>
+ %idx = getelementptr { [40 x i32]* }* %, i64 0, i32 0
+ %arr = load [40 x i32]** %idx
+ %idx = getelementptr [40 x i32]* %arr, i64 0, i64 17
+ </pre>
+ </div>
+
+ <p>In this case, we have to load the pointer in the structure with a load
+ instruction before we can index into the array. If the example was changed
+ to:</p>
+
+ <div class="doc_code">
+ <pre>
+ %MyVar = uninitialized global { [40 x i32 ] }
+ ...
+ %idx = getelementptr { [40 x i32] }*, i64 0, i32 0, i64 17
+ </pre>
+ </div>
+
+ <p>then everything works fine. In this case, the structure does not contain a
+ pointer and the GEP instruction can index through the global variable,
+ into the first field of the structure and access the 18th <tt>i32</tt> in the
+ array there.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_subsection">
+ <a name="lead0"><b>Why don't GEP x,0,0,1 and GEP x,1 alias?</b></a>
+ </div>
+ <div class="doc_text">
+ <p>Quick Answer: They compute different address locations.</p>
+ <p>If you look at the first indices in these GEP
+ instructions you find that they are different (0 and 1), therefore the address
+ computation diverges with that index. Consider this example:</p>
+
+ <div class="doc_code">
+ <pre>
+ %MyVar = global { [10 x i32 ] }
+ %idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 0, i32 0, i64 1
+ %idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1
+ </pre>
+ </div>
+
+ <p>In this example, <tt>idx1</tt> computes the address of the second integer
+ in the array that is in the structure in %MyVar, that is <tt>MyVar+4</tt>. The
+ type of <tt>idx1</tt> is <tt>i32*</tt>. However, <tt>idx2</tt> computes the
+ address of <i>the next</i> structure after <tt>%MyVar</tt>. The type of
+ <tt>idx2</tt> is <tt>{ [10 x i32] }*</tt> and its value is equivalent
+ to <tt>MyVar + 40</tt> because it indexes past the ten 4-byte integers
+ in <tt>MyVar</tt>. Obviously, in such a situation, the pointers don't
+ alias.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_subsection">
+ <a name="trail0"><b>Why do GEP x,1,0,0 and GEP x,1 alias?</b></a>
+ </div>
+ <div class="doc_text">
+ <p>Quick Answer: They compute the same address location.</p>
+ <p>These two GEP instructions will compute the same address because indexing
+ through the 0th element does not change the address. However, it does change
+ the type. Consider this example:</p>
+
+ <div class="doc_code">
+ <pre>
+ %MyVar = global { [10 x i32 ] }
+ %idx1 = getlementptr { [10 x i32 ] }* %MyVar, i64 1, i32 0, i64 0
+ %idx2 = getlementptr { [10 x i32 ] }* %MyVar, i64 1
+ </pre>
+ </div>
+
+ <p>In this example, the value of <tt>%idx1</tt> is <tt>%MyVar+40</tt> and
+ its type is <tt>i32*</tt>. The value of <tt>%idx2</tt> is also
+ <tt>MyVar+40</tt> but its type is <tt>{ [10 x i32] }*</tt>.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="summary"><b>Summary</b></a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>In summary, here's some things to always remember about the GetElementPtr
+ instruction:</p>
+ <ol>
+ <li>The GEP instruction never accesses memory, it only provides pointer
+ computations.</li>
+ <li>The first operand to the GEP instruction is always a pointer and it must
+ be indexed.</li>
+ <li>There are no superfluous indices for the GEP instruction.</li>
+ <li>Trailing zero indices are superfluous for pointer aliasing, but not for
+ the types of the pointers.</li>
+ <li>Leading zero indices are not superfluous for pointer aliasing nor the
+ types of the pointers.</li>
+ </ol>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br/>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/GettingStarted.html
diff -c /dev/null llvm-www/releases/2.5/docs/GettingStarted.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/GettingStarted.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1634 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>Getting Started with LLVM System</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ Getting Started with the LLVM System
+ </div>
+
+ <ul>
+ <li><a href="#overview">Overview</a>
+ <li><a href="#quickstart">Getting Started Quickly (A Summary)</a>
+ <li><a href="#requirements">Requirements</a>
+ <ol>
+ <li><a href="#hardware">Hardware</a></li>
+ <li><a href="#software">Software</a></li>
+ <li><a href="#brokengcc">Broken versions of GCC and other tools</a></li>
+ </ol></li>
+
+ <li><a href="#starting">Getting Started with LLVM</a>
+ <ol>
+ <li><a href="#terminology">Terminology and Notation</a></li>
+ <li><a href="#environment">Setting Up Your Environment</a></li>
+ <li><a href="#unpack">Unpacking the LLVM Archives</a></li>
+ <li><a href="#checkout">Checkout LLVM from Subversion</a></li>
+ <li><a href="#installcf">Install the GCC Front End</a></li>
+ <li><a href="#config">Local LLVM Configuration</a></li>
+ <li><a href="#compile">Compiling the LLVM Suite Source Code</a></li>
+ <li><a href="#cross-compile">Cross-Compiling LLVM</a></li>
+ <li><a href="#objfiles">The Location of LLVM Object Files</a></li>
+ <li><a href="#optionalconfig">Optional Configuration Items</a></li>
+ </ol></li>
+
+ <li><a href="#layout">Program layout</a>
+ <ol>
+ <li><a href="#examples"><tt>llvm/examples</tt></a></li>
+ <li><a href="#include"><tt>llvm/include</tt></a></li>
+ <li><a href="#lib"><tt>llvm/lib</tt></a></li>
+ <li><a href="#projects"><tt>llvm/projects</tt></a></li>
+ <li><a href="#runtime"><tt>llvm/runtime</tt></a></li>
+ <li><a href="#test"><tt>llvm/test</tt></a></li>
+ <li><a href="#llvmtest"><tt>llvm-test</tt></a></li>
+ <li><a href="#tools"><tt>llvm/tools</tt></a></li>
+ <li><a href="#utils"><tt>llvm/utils</tt></a></li>
+ <li><a href="#win32"><tt>llvm/win32</tt></a></li>
+ </ol></li>
+
+ <li><a href="#tutorial">An Example Using the LLVM Tool Chain</a>
+ <ol>
+ <li><a href="#tutorial4">Example with llvm-gcc4</a></li>
+ </ol>
+ <li><a href="#problems">Common Problems</a>
+ <li><a href="#links">Links</a>
+ </ul>
+
+ <div class="doc_author">
+ <p>Written by:
+ <a href="mailto:criswell at uiuc.edu">John Criswell</a>,
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
+ <a href="http://misha.brukman.net">Misha Brukman</a>,
+ <a href="http://www.cs.uiuc.edu/~vadve">Vikram Adve</a>, and
+ <a href="mailto:gshi1 at uiuc.edu">Guochun Shi</a>.
+ </p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="overview"><b>Overview</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Welcome to LLVM! In order to get started, you first need to know some
+ basic information.</p>
+
+ <p>First, LLVM comes in two pieces. The first piece is the LLVM suite. This
+ contains all of the tools, libraries, and header files needed to use the low
+ level virtual machine. It contains an assembler, disassembler, bitcode
+ analyzer and bitcode optimizer. It also contains a test suite that can be
+ used to test the LLVM tools and the GCC front end.</p>
+
+ <p>The second piece is the GCC front end. This component provides a version of
+ GCC that compiles C and C++ code into LLVM bitcode. Currently, the GCC front
+ end uses the GCC parser to convert code to LLVM. Once
+ compiled into LLVM bitcode, a program can be manipulated with the LLVM tools
+ from the LLVM suite.</p>
+
+ <p>
+ There is a third, optional piece called llvm-test. It is a suite of programs
+ with a testing harness that can be used to further test LLVM's functionality
+ and performance.
+ </p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="quickstart"><b>Getting Started Quickly (A Summary)</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Here's the short story for getting up and running quickly with LLVM:</p>
+
+ <ol>
+ <li>Read the documentation.</li>
+ <li>Read the documentation.</li>
+ <li>Remember that you were warned twice about reading the documentation.</li>
+ <li>Install the llvm-gcc-4.2 front end if you intend to compile C or C++:
+ <ol>
+ <li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt></li>
+ <li><tt>gunzip --stdout llvm-gcc-4.2-<i>version</i>-<i>platform</i>.tar.gz | tar -xvf -</tt>
+ </li>
+ <li>Note: If the binary extension is ".bz" use bunzip2 instead of gunzip.</li>
+ <li>Add llvm-gcc's "bin" directory to your PATH variable.</li>
+ </ol></li>
+
+ <li>Get the LLVM Source Code
+ <ul>
+ <li>With the distributed files (or use <a href="#checkout">SVN</a>):
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+ <li><tt>gunzip --stdout llvm-<i>version</i>.tar.gz | tar -xvf -</tt>
+ </ol></li>
+
+ </ul></li>
+
+ <li><b>[Optional]</b> Get the Test Suite Source Code
+ <ul>
+ <li>With the distributed files (or use <a href="#checkout">SVN</a>):
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+ <li><tt>cd llvm/projects</tt>
+ <li><tt>gunzip --stdout llvm-test-<i>version</i>.tar.gz | tar -xvf -</tt>
+ </ol></li>
+
+ </ul></li>
+
+
+ <li>Configure the LLVM Build Environment
+ <ol>
+ <li><tt>cd <i>where-you-want-to-build-llvm</i></tt></li>
+ <li><tt><i>/path/to/llvm/</i>configure [options]</tt><br>
+ Some common options:
+
+ <ul>
+ <li><tt>--prefix=<i>directory</i></tt>
+ <p>Specify for <i>directory</i> the full pathname of where you
+ want the LLVM tools and libraries to be installed (default
+ <tt>/usr/local</tt>).</p></li>
+ <li><tt>--with-llvmgccdir=<i>directory</i></tt>
+ <p>Optionally, specify for <i>directory</i> the full pathname of the
+ C/C++ front end installation to use with this LLVM configuration. If
+ not specified, the PATH will be searched.</p></li>
+ <li><tt>--enable-spec2000=<i>directory</i></tt>
+ <p>Enable the SPEC2000 benchmarks for testing. The SPEC2000
+ benchmarks should be available in
+ <tt><i>directory</i></tt>.</p></li>
+ </ul>
+ </ol></li>
+
+ <li>Build the LLVM Suite:
+ <ol>
+ <li><tt>gmake -k |& tee gnumake.out
+ # this is csh or tcsh syntax</tt></li>
+ <li>If you get an "internal compiler error (ICE)" or test failures, see
+ <a href="#brokengcc">below</a>.</li>
+ </ol>
+
+ </ol>
+
+ <p>Consult the <a href="#starting">Getting Started with LLVM</a> section for
+ detailed information on configuring and compiling LLVM. See <a
+ href="#environment">Setting Up Your Environment</a> for tips that simplify
+ working with the GCC front end and LLVM tools. Go to <a href="#layout">Program
+ Layout</a> to learn about the layout of the source code tree.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="requirements"><b>Requirements</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="hardware"><b>Hardware</b></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM is known to work on the following platforms:</p>
+
+ <table cellpadding="3" summary="Known LLVM platforms">
+ <tr>
+ <th>OS</th>
+ <th>Arch</th>
+ <th>Compilers</th>
+ </tr>
+ <tr>
+ <td>Linux</td>
+ <td>x86<sup><a href="#pf_1">1</a></sup></td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>Solaris</td>
+ <td>V9 (Ultrasparc)</td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>FreeBSD</td>
+ <td>x86<sup><a href="#pf_1">1</a></sup></td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>MacOS X<sup><a href="#pf_2">2</a></sup></td>
+ <td>PowerPC</td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>MacOS X<sup><a href="#pf_2">2</a>,<a href="#pf_9">9</a></sup></td>
+ <td>x86</td>
+ <td>GCC</td>
+
+ </tr>
+ <tr>
+ <td>Cygwin/Win32</td>
+ <td>x86<sup><a href="#pf_1">1</a>,<a href="#pf_8">8</a></sup></td>
+ <td>GCC 3.4.X, binutils 2.15</td>
+ </tr>
+ <tr>
+ <td>MinGW/Win32</td>
+ <td>x86<sup><a href="#pf_1">1</a>,<a href="#pf_6">6</a>,<a href="#pf_8">8</a></sup></td>
+ <td>GCC 3.4.X, binutils 2.15</td>
+ </tr>
+ <tr>
+ <td>Linux</td>
+ <td>amd64</td>
+ <td>GCC</td>
+ </tr>
+ </table>
+
+ <p>LLVM has partial support for the following platforms:</p>
+
+ <table summary="LLVM partial platform support">
+ <tr>
+ <th>OS</th>
+ <th>Arch</th>
+ <th>Compilers</th>
+ </tr>
+ <tr>
+ <td>Windows</td>
+ <td>x86<sup><a href="#pf_1">1</a></sup></td>
+ <td>Visual Studio 2005 SP1 or higher<sup><a href="#pf_4">4</a>,<a href="#pf_5">5</a></sup></td>
+ <tr>
+ <td>AIX<sup><a href="#pf_3">3</a>,<a href="#pf_4">4</a></sup></td>
+ <td>PowerPC</td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>Linux<sup><a href="#pf_3">3</a>,<a href="#pf_5">5</a></sup></td>
+ <td>PowerPC</td>
+ <td>GCC</td>
+ </tr>
+
+ <tr>
+ <td>Linux<sup><a href="#pf_7">7</a></sup></td>
+ <td>Alpha</td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>Linux<sup><a href="#pf_7">7</a></sup></td>
+ <td>Itanium (IA-64)</td>
+ <td>GCC</td>
+ </tr>
+ <tr>
+ <td>HP-UX<sup><a href="#pf_7">7</a></sup></td>
+ <td>Itanium (IA-64)</td>
+ <td>HP aCC</td>
+ </tr>
+ </table>
+
+ <p><b>Notes:</b></p>
+
+ <div class="doc_notes">
+ <ol>
+ <li><a name="pf_1">Code generation supported for Pentium processors and
+ up</a></li>
+ <li><a name="pf_2">Code generation supported for 32-bit ABI only</a></li>
+ <li><a name="pf_3">No native code generation</a></li>
+ <li><a name="pf_4">Build is not complete: one or more tools do not link or function</a></li>
+ <li><a name="pf_5">The GCC-based C/C++ frontend does not build</a></li>
+ <li><a name="pf_6">The port is done using the MSYS shell.</a></li>
+ <li><a name="pf_7">Native code generation exists but is not complete.</a></li>
+ <li><a name="pf_8">Binutils</a> up to post-2.17 has bug in bfd/cofflink.c
+ preventing LLVM from building correctly. Several workarounds have been
+ introduced into LLVM build system, but the bug can occur anytime in the
+ future. We highly recommend that you rebuild your current binutils with the
+ patch from <a href="http://sourceware.org/bugzilla/show_bug.cgi?id=2659">
+ Binutils bugzilla</a>, if it wasn't already applied.</li>
+ <li><a name="pf_9">XCode 2.5 and gcc 4.0.1</a> (Apple Build 5370) will trip
+ internal LLVM assert messages when compiled for Release at optimization
+ levels greater than 0 (i.e., <i>"-O1"</i> and higher).
+ Add <i>OPTIMIZE_OPTION="-O0"</i> to the build command line
+ if compiling for LLVM Release or bootstrapping the LLVM toolchain.</li>
+ </ol>
+ </div>
+
+ <p>Note that you will need about 1-3 GB of space for a full LLVM build in Debug
+ mode, depending on the system (it is so large because of all the debugging
+ information and the fact that the libraries are statically linked into multiple
+ tools). If you do not need many of the tools and you are space-conscious,
+ you can disable them individually in <tt>llvm/tools/Makefile</tt>. The Release
+ build requires considerably less space.</p>
+
+ <p>The LLVM suite <i>may</i> compile on other platforms, but it is not
+ guaranteed to do so. If compilation is successful, the LLVM utilities should be
+ able to assemble, disassemble, analyze, and optimize LLVM bitcode. Code
+ generation should work as well, although the generated native code may not work
+ on your platform.</p>
+
+ <p>The GCC front end is not very portable at the moment. If you want to get it
+ to work on another platform, you can download a copy of the source and <a
+ href="GCCFEBuildInstrs.html">try to compile it</a> on your platform.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="software"><b>Software</b></a></div>
+ <div class="doc_text">
+ <p>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
+ column provides "known to work" versions of the package. The Notes column
+ describes how LLVM uses the package and provides other details.</p>
+ <table summary="Packages required to compile LLVM">
+ <tr><th>Package</th><th>Version</th><th>Notes</th></tr>
+
+ <tr>
+ <td><a href="http://savannah.gnu.org/projects/make">GNU Make</a></td>
+ <td>3.79, 3.79.1</td>
+ <td>Makefile/build processor</td>
+ </tr>
+
+ <tr>
+ <td><a href="http://gcc.gnu.org">GCC</a></td>
+ <td>3.4.2</td>
+ <td>C/C++ compiler<sup><a href="#sf1">1</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://www.gnu.org/software/texinfo">TeXinfo</a></td>
+ <td>4.5</td>
+ <td>For building the CFE</td>
+ </tr>
+
+ <tr>
+ <td><a href="http://subversion.tigris.org/project_packages.html">SVN</a></td>
+ <td>≥1.3</td>
+ <td>Subversion access to LLVM<sup><a href="#sf2">2</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://savannah.gnu.org/projects/dejagnu">DejaGnu</a></td>
+ <td>1.4.2</td>
+ <td>Automated test suite<sup><a href="#sf3">3</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://www.tcl.tk/software/tcltk/">tcl</a></td>
+ <td>8.3, 8.4</td>
+ <td>Automated test suite<sup><a href="#sf3">3</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://expect.nist.gov/">expect</a></td>
+ <td>5.38.0</td>
+ <td>Automated test suite<sup><a href="#sf3">3</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://www.perl.com/download.csp">perl</a></td>
+ <td>≥5.6.0</td>
+ <td>Nightly tester, utilities</td>
+ </tr>
+
+ <tr>
+ <td><a href="http://savannah.gnu.org/projects/m4">GNU M4</a>
+ <td>1.4</td>
+ <td>Macro processor for configuration<sup><a href="#sf4">4</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://www.gnu.org/software/autoconf">GNU Autoconf</a></td>
+ <td>2.59</td>
+ <td>Configuration script builder<sup><a href="#sf4">4</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://www.gnu.org/software/automake">GNU Automake</a></td>
+ <td>1.9.2</td>
+ <td>aclocal macro generator<sup><a href="#sf4">4</a></sup></td>
+ </tr>
+
+ <tr>
+ <td><a href="http://savannah.gnu.org/projects/libtool">libtool</a></td>
+ <td>1.5.10</td>
+ <td>Shared library manager<sup><a href="#sf4">4</a></sup></td>
+ </tr>
+
+ </table>
+
+ <p><b>Notes:</b></p>
+ <div class="doc_notes">
+ <ol>
+ <li><a name="sf1">Only the C and C++ languages are needed so there's no
+ need to build the other languages for LLVM's purposes.</a> See
+ <a href="#brokengcc">below</a> for specific version info.</li>
+ <li><a name="sf2">You only need Subversion if you intend to build from the
+ latest LLVM sources. If you're working from a release distribution, you
+ don't need Subversion.</a></li>
+ <li><a name="sf3">Only needed if you want to run the automated test
+ suite in the <tt>llvm/test</tt> directory.</a></li>
+ <li><a name="sf4">If you want to make changes to the configure scripts,
+ you will need GNU autoconf (2.59), and consequently, GNU M4 (version 1.4
+ or higher). You will also need automake (1.9.2). We only use aclocal
+ from that package.</a></li>
+ </ol>
+ </div>
+
+ <p>Additionally, your compilation host is expected to have the usual
+ plethora of Unix utilities. Specifically:</p>
+ <ul>
+ <li><b>ar</b> - archive library builder</li>
+ <li><b>bzip2*</b> - bzip2 command for distribution generation</li>
+ <li><b>bunzip2*</b> - bunzip2 command for distribution checking</li>
+ <li><b>chmod</b> - change permissions on a file</li>
+ <li><b>cat</b> - output concatenation utility</li>
+ <li><b>cp</b> - copy files</li>
+ <li><b>date</b> - print the current date/time </li>
+ <li><b>echo</b> - print to standard output</li>
+ <li><b>egrep</b> - extended regular expression search utility</li>
+ <li><b>find</b> - find files/dirs in a file system</li>
+ <li><b>grep</b> - regular expression search utility</li>
+ <li><b>gzip*</b> - gzip command for distribution generation</li>
+ <li><b>gunzip*</b> - gunzip command for distribution checking</li>
+ <li><b>install</b> - install directories/files </li>
+ <li><b>mkdir</b> - create a directory</li>
+ <li><b>mv</b> - move (rename) files</li>
+ <li><b>ranlib</b> - symbol table builder for archive libraries</li>
+ <li><b>rm</b> - remove (delete) files and directories</li>
+ <li><b>sed</b> - stream editor for transforming output</li>
+ <li><b>sh</b> - Bourne shell for make build scripts</li>
+ <li><b>tar</b> - tape archive for distribution generation</li>
+ <li><b>test</b> - test things in file system</li>
+ <li><b>unzip*</b> - unzip command for distribution checking</li>
+ <li><b>zip*</b> - zip command for distribution generation</li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="brokengcc">Broken versions of GCC and other tools</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>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
+ to compile LLVM. We routinely use GCC 3.3.3, 3.4.0, and Apple 4.0.1
+ successfully with them (however, see important notes below). Other versions
+ of GCC will probably work as well. GCC versions listed
+ here are known to not work. If you are using one of these versions, please try
+ to upgrade your GCC to something more recent. If you run into a problem with a
+ version of GCC not listed here, please <a href="mailto:llvmdev at cs.uiuc.edu">let
+ us know</a>. Please use the "<tt>gcc -v</tt>" command to find out which version
+ of GCC you are using.
+ </p>
+
+ <p><b>GCC versions prior to 3.0</b>: GCC 2.96.x and before had several
+ problems in the STL that effectively prevent it from compiling LLVM.
+ </p>
+
+ <p><b>GCC 3.2.2 and 3.2.3</b>: These versions of GCC fails to compile LLVM with
+ a bogus template error. This was fixed in later GCCs.</p>
+
+ <p><b>GCC 3.3.2</b>: This version of GCC suffered from a <a
+ href="http://gcc.gnu.org/PR13392">serious bug</a> which causes it to crash in
+ the "<tt>convert_from_eh_region_ranges_1</tt>" GCC function.</p>
+
+ <p><b>Cygwin GCC 3.3.3</b>: The version of GCC 3.3.3 commonly shipped with
+ Cygwin does not work. Please <a href="GCCFEBuildInstrs.html#cygwin">upgrade
+ to a newer version</a> if possible.</p>
+ <p><b>SuSE GCC 3.3.3</b>: The version of GCC 3.3.3 shipped with SuSE 9.1 (and
+ possibly others) does not compile LLVM correctly (it appears that exception
+ handling is broken in some cases). Please download the FSF 3.3.3 or upgrade
+ to a newer version of GCC.</p>
+ <p><b>GCC 3.4.0 on linux/x86 (32-bit)</b>: GCC miscompiles portions of the
+ code generator, causing an infinite loop in the llvm-gcc build when built
+ with optimizations enabled (i.e. a release build).</p>
+ <p><b>GCC 3.4.2 on linux/x86 (32-bit)</b>: GCC miscompiles portions of the
+ code generator at -O3, as with 3.4.0. However gcc 3.4.2 (unlike 3.4.0)
+ correctly compiles LLVM at -O2. A work around is to build release LLVM
+ builds with "make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2 ..."</p>
+ <p><b>GCC 3.4.x on X86-64/amd64</b>: GCC <a href="http://llvm.org/PR1056">
+ miscompiles portions of LLVM</a>.</p>
+ <p><b>GCC 3.4.4 (CodeSourcery ARM 2005q3-2)</b>: this compiler miscompiles LLVM
+ when building with optimizations enabled. It appears to work with
+ "<tt>make ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O1</tt>" or build a debug
+ build.</p>
+ <p><b>IA-64 GCC 4.0.0</b>: The IA-64 version of GCC 4.0.0 is known to
+ miscompile LLVM.</p>
+ <p><b>Apple Xcode 2.3</b>: GCC crashes when compiling LLVM at -O3 (which is the
+ default with ENABLE_OPTIMIZED=1. To work around this, build with
+ "ENABLE_OPTIMIZED=1 OPTIMIZE_OPTION=-O2".</p>
+ <p><b>GCC 4.1.1</b>: GCC fails to build LLVM with template concept check errors
+ compiling some files. At the time of this writing, GCC mainline (4.2)
+ did not share the problem.</p>
+ <p><b>GCC 4.1.1 on X86-64/amd64</b>: GCC <a href="http://llvm.org/PR1063">
+ miscompiles portions of LLVM</a> when compiling llvm itself into 64-bit
+ code. LLVM will appear to mostly work but will be buggy, e.g. failing
+ portions of its testsuite.</p>
+ <p><b>GCC 4.1.2 on OpenSUSE</b>: Seg faults during libstdc++ build and on x86_64
+ platforms compiling md5.c gets a mangled constant.</p>
+ <p><b>GCC 4.1.2 (20061115 (prerelease) (Debian 4.1.1-21)) on Debian</b>: Appears
+ to miscompile parts of LLVM 2.4. One symptom is ValueSymbolTable complaining
+ about symbols remaining in the table on destruction.</p>
+ <p><b>GCC 4.1.2 20071124 (Red Hat 4.1.2-42)</b>: Suffers from the same symptoms
+ as the previous one. It appears to work with ENABLE_OPTIMIZED=0 (the default).</p>
+
+ <p><b>GNU ld 2.16.X</b>. Some 2.16.X versions of the ld linker will produce very
+ long warning messages complaining that some ".gnu.linkonce.t.*" symbol was
+ defined in a discarded section. You can safely ignore these messages as they are
+ erroneous and the linkage is correct. These messages disappear using ld
+ 2.17.</p>
+
+ <p><b>GNU binutils 2.17</b>: Binutils 2.17 contains <a
+ href="http://sourceware.org/bugzilla/show_bug.cgi?id=3111">a bug</a> which
+ causes huge link times (minutes instead of seconds) when building LLVM. We
+ recommend upgrading to a newer version (2.17.50.0.4 or later).</p>
+
+ </div>
+
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="starting"><b>Getting Started with LLVM</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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.</p>
+
+ <p>The later sections of this guide describe the <a
+ href="#layout">general layout</a> of the the LLVM source tree, a <a
+ href="#tutorial">simple example</a> using the LLVM tool chain, and <a
+ href="#links">links</a> to find more information about LLVM or to get
+ help via e-mail.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="terminology">Terminology and Notation</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Throughout this manual, the following names are used to denote paths
+ specific to the local system and working environment. <i>These are not
+ environment variables you need to set but just strings used in the rest
+ of this document below</i>. In any of the examples below, simply replace
+ each of these names with the appropriate pathname on your local system.
+ All these paths are absolute:</p>
+
+ <dl>
+ <dt>SRC_ROOT
+ <dd>
+ This is the top level directory of the LLVM source tree.
+ <br><br>
+
+ <dt>OBJ_ROOT
+ <dd>
+ This is the top level directory of the LLVM object tree (i.e. the
+ tree where object files and compiled programs will be placed. It
+ can be the same as SRC_ROOT).
+ <br><br>
+
+ <dt>LLVMGCCDIR
+ <dd>
+ This is where the LLVM GCC Front End is installed.
+ <p>
+ For the pre-built GCC front end binaries, the LLVMGCCDIR is
+ <tt>llvm-gcc/<i>platform</i>/llvm-gcc</tt>.
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="environment">Setting Up Your Environment</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ In order to compile and use LLVM, you may need to set some environment
+ variables.
+
+ <dl>
+ <dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt>/path/to/your/bitcode/libs</tt></dt>
+ <dd>[Optional] This environment variable helps LLVM linking tools find the
+ locations of your bitcode libraries. It is provided only as a
+ convenience since you can specify the paths using the -L options of the
+ tools and the C/C++ front-end will automatically use the bitcode files
+ installed in its
+ <tt>lib</tt> directory.</dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="unpack">Unpacking the LLVM Archives</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ If you have the LLVM distribution, you will need to unpack it before you
+ can begin to compile it. LLVM is distributed as a set of two files: the LLVM
+ suite and the LLVM GCC front end compiled for your platform. There is an
+ additional test suite that is optional. Each file is a TAR archive that is
+ compressed with the gzip program.
+ </p>
+
+ <p>The files are as follows, with <em>x.y</em> marking the version number:
+ <dl>
+ <dt><tt>llvm-x.y.tar.gz</tt></dt>
+ <dd>Source release for the LLVM libraries and tools.<br></dd>
+
+ <dt><tt>llvm-test-x.y.tar.gz</tt></dt>
+ <dd>Source release for the LLVM test suite.</dd>
+
+ <dt><tt>llvm-gcc-4.2-x.y.source.tar.gz</tt></dt>
+ <dd>Source release of the llvm-gcc-4.2 front end. See README.LLVM in the root
+ directory for build instructions.<br></dd>
+
+ <dt><tt>llvm-gcc-4.2-x.y-platform.tar.gz</tt></dt>
+ <dd>Binary release of the llvm-gcc-4.2 front end for a specific platform.<br></dd>
+
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="checkout">Checkout LLVM from Subversion</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>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 Subvresion as
+ follows:</p>
+
+ <ul>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
+ <li>Read-Only: <tt>svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm</tt></li>
+ <li>Read-Write:<tt>svn co https://user@llvm.org/svn/llvm-project/llvm/trunk
+ llvm</tt></li>
+ </ul>
+
+
+ <p>This will create an '<tt>llvm</tt>' directory in the current
+ directory and fully populate it with the LLVM source code, Makefiles,
+ test directories, and local copies of documentation files.</p>
+
+ <p>If you want to get a specific release (as opposed to the most recent
+ revision), you can checkout it from the '<tt>tags</tt>' directory (instead of
+ '<tt>trunk</tt>'). The following releases are located in the following
+ subdirectories of the '<tt>tags</tt>' directory:</p>
+
+ <ul>
+ <li>Release 2.4: <b>RELEASE_24</b></li>
+ <li>Release 2.3: <b>RELEASE_23</b></li>
+ <li>Release 2.2: <b>RELEASE_22</b></li>
+ <li>Release 2.1: <b>RELEASE_21</b></li>
+ <li>Release 2.0: <b>RELEASE_20</b></li>
+ <li>Release 1.9: <b>RELEASE_19</b></li>
+ <li>Release 1.8: <b>RELEASE_18</b></li>
+ <li>Release 1.7: <b>RELEASE_17</b></li>
+ <li>Release 1.6: <b>RELEASE_16</b></li>
+ <li>Release 1.5: <b>RELEASE_15</b></li>
+ <li>Release 1.4: <b>RELEASE_14</b></li>
+ <li>Release 1.3: <b>RELEASE_13</b></li>
+ <li>Release 1.2: <b>RELEASE_12</b></li>
+ <li>Release 1.1: <b>RELEASE_11</b></li>
+ <li>Release 1.0: <b>RELEASE_1</b></li>
+ </ul>
+
+ <p>If you would like to get the LLVM test suite (a separate package as of 1.4),
+ you get it from the Subversion repository:</p>
+
+ <div class="doc_code">
+ <pre>
+ % cd llvm/projects
+ % svn co http://llvm.org/svn/llvm-project/test-suite/trunk llvm-test
+ </pre>
+ </div>
+
+ <p>By placing it in the <tt>llvm/projects</tt>, it will be automatically
+ configured by the LLVM configure script as well as automatically updated when
+ you run <tt>svn update</tt>.</p>
+
+ <p>If you would like to get the GCC front end source code, you can also get it
+ and build it yourself. Please follow <a href="GCCFEBuildInstrs.html">these
+ instructions</a> to successfully get and build the LLVM GCC front-end.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="installcf">Install the GCC Front End</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Before configuring and compiling the LLVM suite, you can optionally extract the
+ LLVM GCC front end from the binary distribution. It is used for running the
+ llvm-test testsuite and for compiling C/C++ programs. Note that you can optionally
+ <a href="GCCFEBuildInstrs.html">build llvm-gcc yourself</a> after building the
+ main LLVM repository.</p>
+
+ <p>To install the GCC front end, do the following:</p>
+
+ <ol>
+ <li><tt>cd <i>where-you-want-the-front-end-to-live</i></tt></li>
+ <li><tt>gunzip --stdout llvm-gcc-4.2-<i>version</i>-<i>platform</i>.tar.gz | tar -xvf
+ -</tt></li>
+ </ol>
+
+ <p>Once the binary is uncompressed, you should add a symlink for llvm-gcc and
+ llvm-g++ to some directory in your path. When you configure LLVM, it will
+ automatically detect llvm-gcc's presence (if it is in your path) enabling its
+ use in llvm-test. Note that you can always build or install llvm-gcc at any
+ pointer after building the main LLVM repository: just reconfigure llvm and
+ llvm-test will pick it up.
+ </p>
+
+ <p>The binary versions of the GCC front end may not suit all of your needs. For
+ example, the binary distribution may include an old version of a system header
+ file, not "fix" a header file that needs to be fixed for GCC, or it may be
+ linked with libraries not available on your system.</p>
+
+ <p>In cases like these, you may want to try <a
+ href="GCCFEBuildInstrs.html">building the GCC front end from source.</a> This is
+ much easier now than it was in the past.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="config">Local LLVM Configuration</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Once checked out from the Subversion repository, the LLVM suite source
+ code must be
+ configured via the <tt>configure</tt> script. This script sets variables in the
+ various <tt>*.in</tt> files, most notably <tt>llvm/Makefile.config</tt> and
+ <tt>llvm/include/Config/config.h</tt>. It also populates <i>OBJ_ROOT</i> with
+ the Makefiles needed to begin building LLVM.</p>
+
+ <p>The following environment variables are used by the <tt>configure</tt>
+ script to configure the build system:</p>
+
+ <table summary="LLVM configure script environment variables">
+ <tr><th>Variable</th><th>Purpose</th></tr>
+ <tr>
+ <td>CC</td>
+ <td>Tells <tt>configure</tt> which C compiler to use. By default,
+ <tt>configure</tt> will look for the first GCC C compiler in
+ <tt>PATH</tt>. Use this variable to override
+ <tt>configure</tt>'s default behavior.</td>
+ </tr>
+ <tr>
+ <td>CXX</td>
+ <td>Tells <tt>configure</tt> which C++ compiler to use. By default,
+ <tt>configure</tt> will look for the first GCC C++ compiler in
+ <tt>PATH</tt>. Use this variable to override
+ <tt>configure</tt>'s default behavior.</td>
+ </tr>
+ </table>
+
+ <p>The following options can be used to set or enable LLVM specific options:</p>
+
+ <dl>
+ <dt><i>--with-llvmgccdir</i></dt>
+ <dd>Path to the LLVM C/C++ FrontEnd to be used with this LLVM configuration.
+ The value of this option should specify the full pathname of the C/C++ Front
+ End to be used. If this option is not provided, the PATH will be searched for
+ a program named <i>llvm-gcc</i> and the C/C++ FrontEnd install directory will
+ be inferred from the path found. If the option is not given, and no llvm-gcc
+ can be found in the path then a warning will be produced by
+ <tt>configure</tt> indicating this situation. LLVM may still be built with
+ the <tt>tools-only</tt> target but attempting to build the runtime libraries
+ will fail as these libraries require llvm-gcc and llvm-g++. See
+ <a href="#installcf">Install the GCC Front End</a> for details on installing
+ the C/C++ Front End. See
+ <a href="GCCFEBuildInstrs.html">Bootstrapping the LLVM C/C++ Front-End</a>
+ for details on building the C/C++ Front End.</dd>
+ <dt><i>--with-tclinclude</i></dt>
+ <dd>Path to the tcl include directory under which <tt>tclsh</tt> can be
+ found. Use this if you have multiple tcl installations on your machine and you
+ want to use a specific one (8.x) for LLVM. LLVM only uses tcl for running the
+ dejagnu based test suite in <tt>llvm/test</tt>. If you don't specify this
+ option, the LLVM configure script will search for the tcl 8.4 and 8.3
+ releases.
+ <br><br>
+ </dd>
+ <dt><i>--enable-optimized</i></dt>
+ <dd>
+ Enables optimized compilation by default (debugging symbols are removed
+ and GCC optimization flags are enabled). The default is to use an
+ unoptimized build (also known as a debug build).
+ <br><br>
+ </dd>
+ <dt><i>--enable-debug-runtime</i></dt>
+ <dd>
+ Enables debug symbols in the runtime libraries. The default is to strip
+ debug symbols from the runtime libraries.
+ </dd>
+ <dt><i>--enable-jit</i></dt>
+ <dd>
+ Compile the Just In Time (JIT) compiler functionality. This is not
+ available
+ on all platforms. The default is dependent on platform, so it is best
+ to explicitly enable it if you want it.
+ <br><br>
+ </dd>
+ <dt><i>--enable-targets=</i><tt>target-option</tt></dt>
+ <dd>Controls which targets will be built and linked into llc. The default
+ value for <tt>target_options</tt> is "all" which builds and links all
+ available targets. The value "host-only" can be specified to build only a
+ native compiler (no cross-compiler targets available). The "native" target is
+ selected as the target of the build host. You can also specify a comma
+ separated list of target names that you want available in llc. The target
+ names use all lower case. The current set of targets is: <br>
+ <tt>alpha, ia64, powerpc, skeleton, sparc, x86</tt>.
+ <br><br></dd>
+ <dt><i>--enable-doxygen</i></dt>
+ <dd>Look for the doxygen program and enable construction of doxygen based
+ documentation from the source code. This is disabled by default because
+ generating the documentation can take a long time and producess 100s of
+ megabytes of output.</dd>
+ <dt><i>--with-udis86</i></dt>
+ <dd>LLVM can use external disassembler library for various purposes (now it's
+ used only for examining code produced by JIT). This option will enable usage
+ of <a href="http://udis86.sourceforge.net/">udis86</a> x86 (both 32 and 64
+ bits) disassembler library.</dd>
+ </dl>
+
+ <p>To configure LLVM, follow these steps:</p>
+
+ <ol>
+ <li><p>Change directory into the object root directory:</p>
+
+ <div class="doc_code"><pre>% cd <i>OBJ_ROOT</i></pre></div></li>
+
+ <li><p>Run the <tt>configure</tt> script located in the LLVM source
+ tree:</p>
+
+ <div class="doc_code">
+ <pre>% <i>SRC_ROOT</i>/configure --prefix=/install/path [other options]</pre>
+ </div></li>
+ </ol>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="compile">Compiling the LLVM Suite Source Code</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Once you have configured LLVM, you can build it. There are three types of
+ builds:</p>
+
+ <dl>
+ <dt>Debug Builds
+ <dd>
+ These builds are the default when one types <tt>gmake</tt> (unless the
+ <tt>--enable-optimized</tt> option was used during configuration). The
+ build system will compile the tools and libraries with debugging
+ information.
+ <br><br>
+
+ <dt>Release (Optimized) Builds
+ <dd>
+ These builds are enabled with the <tt>--enable-optimized</tt> option to
+ <tt>configure</tt> or by specifying <tt>ENABLE_OPTIMIZED=1</tt> on the
+ <tt>gmake</tt> command line. For these builds, the build system will
+ compile the tools and libraries with GCC optimizations enabled and strip
+ debugging information from the libraries and executables it generates.
+ <br><br>
+
+ <dt>Profile Builds
+ <dd>
+ These builds are for use with profiling. They compile profiling
+ information into the code for use with programs like <tt>gprof</tt>.
+ Profile builds must be started by specifying <tt>ENABLE_PROFILING=1</tt>
+ on the <tt>gmake</tt> command line.
+ </dl>
+
+ <p>Once you have LLVM configured, you can build it by entering the
+ <i>OBJ_ROOT</i> directory and issuing the following command:</p>
+
+ <div class="doc_code"><pre>% gmake</pre></div>
+
+ <p>If the build fails, please <a href="#brokengcc">check here</a> to see if you
+ are using a version of GCC that is known not to compile LLVM.</p>
+
+ <p>
+ If you have multiple processors in your machine, you may wish to use some of
+ the parallel build options provided by GNU Make. For example, you could use the
+ command:</p>
+
+ <div class="doc_code"><pre>% gmake -j2</pre></div>
+
+ <p>There are several special targets which are useful when working with the LLVM
+ source code:</p>
+
+ <dl>
+ <dt><tt>gmake clean</tt>
+ <dd>
+ Removes all files generated by the build. This includes object files,
+ generated C/C++ files, libraries, and executables.
+ <br><br>
+
+ <dt><tt>gmake dist-clean</tt>
+ <dd>
+ Removes everything that <tt>gmake clean</tt> does, but also removes files
+ generated by <tt>configure</tt>. It attempts to return the source tree to the
+ original state in which it was shipped.
+ <br><br>
+
+ <dt><tt>gmake install</tt>
+ <dd>
+ Installs LLVM header files, libraries, tools, and documentation in a
+ hierarchy
+ under $PREFIX, specified with <tt>./configure --prefix=[dir]</tt>, which
+ defaults to <tt>/usr/local</tt>.
+ <br><br>
+
+ <dt><tt>gmake -C runtime install-bytecode</tt>
+ <dd>
+ Assuming you built LLVM into $OBJDIR, when this command is run, it will
+ install bitcode libraries into the GCC front end's bitcode library
+ directory. If you need to update your bitcode libraries,
+ this is the target to use once you've built them.
+ <br><br>
+ </dl>
+
+ <p>Please see the <a href="MakefileGuide.html">Makefile Guide</a> for further
+ details on these <tt>make</tt> targets and descriptions of other targets
+ available.</p>
+
+ <p>It is also possible to override default values from <tt>configure</tt> by
+ declaring variables on the command line. The following are some examples:</p>
+
+ <dl>
+ <dt><tt>gmake ENABLE_OPTIMIZED=1</tt>
+ <dd>
+ Perform a Release (Optimized) build.
+ <br><br>
+
+ <dt><tt>gmake ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1</tt>
+ <dd>
+ Perform a Release (Optimized) build without assertions enabled.
+ <br><br>
+
+ <dt><tt>gmake ENABLE_PROFILING=1</tt>
+ <dd>
+ Perform a Profiling build.
+ <br><br>
+
+ <dt><tt>gmake VERBOSE=1</tt>
+ <dd>
+ Print what <tt>gmake</tt> is doing on standard output.
+ <br><br>
+
+ <dt><tt>gmake TOOL_VERBOSE=1</tt></dt>
+ <dd>Ask each tool invoked by the makefiles to print out what it is doing on
+ the standard output. This also implies <tt>VERBOSE=1</tt>.
+ <br><br></dd>
+ </dl>
+
+ <p>Every directory in the LLVM object tree includes a <tt>Makefile</tt> to build
+ it and any subdirectories that it contains. Entering any directory inside the
+ LLVM object tree and typing <tt>gmake</tt> should rebuild anything in or below
+ that directory that is out of date.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="cross-compile">Cross-Compiling LLVM</a>
+ </div>
+
+ <div class="doc_text">
+ <p>It is possible to cross-compile LLVM. That is, you can create LLVM
+ executables and libraries for a platform different than the one one which you
+ are compiling. To do this, a few additional steps are
+ required. <sup><a href="#ccn_1">1</a></sup> To cross-compile LLVM, use
+ these instructions:</p>
+ <ol>
+ <li>Configure and build LLVM as a native compiler. You will need
+ just <tt>TableGen</tt> from that build.
+ <ul>
+ <li>If you have <tt>$LLVM_OBJ_ROOT=$LLVM_SRC_ROOT</tt> just execute
+ <tt>make -C utils/TableGen</tt> after configuring.</li>
+ <li>Otherwise you will need to monitor building process and terminate
+ it just after <tt>TableGen</tt> was built.</li>
+ </ul>
+ </li>
+ <li>Copy the TableGen binary to somewhere safe (out of your build tree).
+ </li>
+ <li>Configure LLVM to build with a cross-compiler. To do this, supply the
+ configure script with <tt>--build</tt> and <tt>--host</tt> options that
+ are different. The values of these options must be legal target triples
+ that your GCC compiler supports.</li>
+ <li>Put the saved <tt>TableGen</tt> executable into the
+ into <tt>$LLVM_OBJ_ROOT/{BUILD_TYPE}/bin</tt> directory (e.g. into
+ <tt>.../Release/bin</tt> for a Release build).</li>
+ <li>Build LLVM as usual.</li>
+ </ol>
+ <p>The result of such a build will produce executables that are not executable
+ on your build host (--build option) but can be executed on your compile host
+ (--host option).</p>
+ <p><b>Notes:</b></p>
+ <div class="doc_notes">
+ <ol>
+ <li><a name="ccn_1">Cross-compiling</a> was tested only with Linux as
+ build platform and Windows as host using mingw32 cross-compiler. Other
+ combinations have not been tested.</li>
+ </ol>
+ </div>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="objfiles">The Location of LLVM Object Files</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>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
+ platforms or configurations using the same source tree.</p>
+
+ <p>This is accomplished in the typical autoconf manner:</p>
+
+ <ul>
+ <li><p>Change directory to where the LLVM object files should live:</p>
+
+ <div class="doc_code"><pre>% cd <i>OBJ_ROOT</i></pre></div></li>
+
+ <li><p>Run the <tt>configure</tt> script found in the LLVM source
+ directory:</p>
+
+ <div class="doc_code"><pre>% <i>SRC_ROOT</i>/configure</pre></div></li>
+ </ul>
+
+ <p>The LLVM build will place files underneath <i>OBJ_ROOT</i> in directories
+ named after the build type:</p>
+
+ <dl>
+ <dt>Debug Builds
+ <dd>
+ <dl>
+ <dt>Tools
+ <dd><tt><i>OBJ_ROOT</i>/Debug/bin</tt>
+ <dt>Libraries
+ <dd><tt><i>OBJ_ROOT</i>/Debug/lib</tt>
+ </dl>
+ <br><br>
+
+ <dt>Release Builds
+ <dd>
+ <dl>
+ <dt>Tools
+ <dd><tt><i>OBJ_ROOT</i>/Release/bin</tt>
+ <dt>Libraries
+ <dd><tt><i>OBJ_ROOT</i>/Release/lib</tt>
+ </dl>
+ <br><br>
+
+ <dt>Profile Builds
+ <dd>
+ <dl>
+ <dt>Tools
+ <dd><tt><i>OBJ_ROOT</i>/Profile/bin</tt>
+ <dt>Libraries
+ <dd><tt><i>OBJ_ROOT</i>/Profile/lib</tt>
+ </dl>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="optionalconfig">Optional Configuration Items</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ If you're running on a Linux system that supports the "<a
+ href="http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html">binfmt_misc</a>"
+ module, and you have root access on the system, you can set your system up to
+ execute LLVM bitcode files directly. To do this, use commands like this (the
+ first command may not be required if you are already using the module):</p>
+
+ <div class="doc_code">
+ <pre>
+ $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
+ $ echo ':llvm:M::llvm::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
+ $ chmod u+x hello.bc (if needed)
+ $ ./hello.bc
+ </pre>
+ </div>
+
+ <p>
+ This allows you to execute LLVM bitcode files directly. Thanks to Jack
+ Cummings for pointing this out!
+ </p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="layout"><b>Program Layout</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>One useful source of information about the LLVM source base is the LLVM <a
+ href="http://www.doxygen.org">doxygen</a> documentation available at <tt><a
+ href="http://llvm.org/doxygen/">http://llvm.org/doxygen/</a></tt>.
+ The following is a brief introduction to code layout:</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="examples"><tt>llvm/examples</tt></a></div>
+ <div class="doc_text">
+ <p>This directory contains some simple examples of how to use the LLVM IR and
+ JIT.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="include"><tt>llvm/include</tt></a></div>
+ <div class="doc_text">
+
+ <p>This directory contains public header files exported from the LLVM
+ library. The three main subdirectories of this directory are:</p>
+
+ <dl>
+ <dt><tt><b>llvm/include/llvm</b></tt></dt>
+ <dd>This directory contains all of the LLVM specific header files. This
+ directory also has subdirectories for different portions of LLVM:
+ <tt>Analysis</tt>, <tt>CodeGen</tt>, <tt>Target</tt>, <tt>Transforms</tt>,
+ etc...</dd>
+
+ <dt><tt><b>llvm/include/llvm/Support</b></tt></dt>
+ <dd>This directory contains generic support libraries that are provided with
+ LLVM but not necessarily specific to LLVM. For example, some C++ STL utilities
+ and a Command Line option processing library store their header files here.
+ </dd>
+
+ <dt><tt><b>llvm/include/llvm/Config</b></tt></dt>
+ <dd>This directory contains header files configured by the <tt>configure</tt>
+ script. They wrap "standard" UNIX and C header files. Source code can
+ include these header files which automatically take care of the conditional
+ #includes that the <tt>configure</tt> script generates.</dd>
+ </dl>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="lib"><tt>llvm/lib</tt></a></div>
+ <div class="doc_text">
+
+ <p>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
+ different <a href="#tools">tools</a>.</p>
+
+ <dl>
+ <dt><tt><b>llvm/lib/VMCore/</b></tt></dt>
+ <dd> This directory holds the core LLVM source files that implement core
+ classes like Instruction and BasicBlock.</dd>
+
+ <dt><tt><b>llvm/lib/AsmParser/</b></tt></dt>
+ <dd>This directory holds the source code for the LLVM assembly language parser
+ library.</dd>
+
+ <dt><tt><b>llvm/lib/BitCode/</b></tt></dt>
+ <dd>This directory holds code for reading and write LLVM bitcode.</dd>
+
+ <dt><tt><b>llvm/lib/Analysis/</b></tt><dd>This directory contains a variety of
+ different program analyses, such as Dominator Information, Call Graphs,
+ Induction Variables, Interval Identification, Natural Loop Identification,
+ etc.</dd>
+
+ <dt><tt><b>llvm/lib/Transforms/</b></tt></dt>
+ <dd> This directory contains the source code for the LLVM to LLVM program
+ transformations, such as Aggressive Dead Code Elimination, Sparse Conditional
+ Constant Propagation, Inlining, Loop Invariant Code Motion, Dead Global
+ Elimination, and many others.</dd>
+
+ <dt><tt><b>llvm/lib/Target/</b></tt></dt>
+ <dd> This directory contains files that describe various target architectures
+ for code generation. For example, the <tt>llvm/lib/Target/X86</tt>
+ directory holds the X86 machine description while
+ <tt>llvm/lib/Target/CBackend</tt> implements the LLVM-to-C converter.</dd>
+
+ <dt><tt><b>llvm/lib/CodeGen/</b></tt></dt>
+ <dd> This directory contains the major parts of the code generator: Instruction
+ Selector, Instruction Scheduling, and Register Allocation.</dd>
+
+ <dt><tt><b>llvm/lib/Debugger/</b></tt></dt>
+ <dd> This directory contains the source level debugger library that makes
+ it possible to instrument LLVM programs so that a debugger could identify
+ source code locations at which the program is executing.</dd>
+
+ <dt><tt><b>llvm/lib/ExecutionEngine/</b></tt></dt>
+ <dd> This directory contains libraries for executing LLVM bitcode directly
+ at runtime in both interpreted and JIT compiled fashions.</dd>
+
+ <dt><tt><b>llvm/lib/Support/</b></tt></dt>
+ <dd> This directory contains the source code that corresponds to the header
+ files located in <tt>llvm/include/Support/</tt>.</dd>
+
+ <dt><tt><b>llvm/lib/System/</b></tt></dt>
+ <dd>This directory contains the operating system abstraction layer that
+ shields LLVM from platform-specific coding.</dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="projects"><tt>llvm/projects</tt></a></div>
+ <div class="doc_text">
+ <p>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 <tt>llvm/projects/sample</tt> for an example of how
+ to set up your own project.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="runtime"><tt>llvm/runtime</tt></a></div>
+ <div class="doc_text">
+
+ <p>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
+ skeleton versions of real libraries; for example, libc is a stripped down
+ version of glibc.</p>
+
+ <p>Unlike the rest of the LLVM suite, this directory needs the LLVM GCC front
+ end to compile.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="test"><tt>llvm/test</tt></a></div>
+ <div class="doc_text">
+ <p>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.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="llvmtest"><tt>test-suite</tt></a></div>
+ <div class="doc_text">
+ <p>This is not a directory in the normal llvm module; it is a separate
+ Subversion
+ module that must be checked out (usually to <tt>projects/test-suite</tt>).
+ This
+ module contains a comprehensive correctness, performance, and benchmarking
+ test
+ suite for LLVM. It is a separate Subversion module because not every LLVM
+ user is
+ interested in downloading or building such a comprehensive test suite. For
+ further details on this test suite, please see the
+ <a href="TestingGuide.html">Testing Guide</a> document.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="tools"><tt>llvm/tools</tt></a></div>
+ <div class="doc_text">
+
+ <p>The <b>tools</b> directory contains the executables built out of the
+ libraries above, which form the main part of the user interface. You can
+ always get help for a tool by typing <tt>tool_name --help</tt>. The
+ following is a brief introduction to the most important tools. More detailed
+ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
+
+ <dl>
+
+ <dt><tt><b>bugpoint</b></tt></dt>
+ <dd><tt>bugpoint</tt> is used to debug
+ optimization passes or code generation backends by narrowing down the
+ given test case to the minimum number of passes and/or instructions that
+ still cause a problem, whether it is a crash or miscompilation. See <a
+ href="HowToSubmitABug.html">HowToSubmitABug.html</a> for more information
+ on using <tt>bugpoint</tt>.</dd>
+
+ <dt><tt><b>llvmc</b></tt></dt>
+ <dd>The LLVM Compiler Driver. This program can
+ be configured to utilize both LLVM and non-LLVM compilation tools to enable
+ pre-processing, translation, optimization, assembly, and linking of programs
+ all from one command line. <tt>llvmc</tt> also takes care of processing the
+ dependent libraries found in bitcode. This reduces the need to get the
+ traditional <tt>-l<name></tt> options right on the command line. Please
+ note that this tool, while functional, is still experimental and not feature
+ complete.</dd>
+
+ <dt><tt><b>llvm-ar</b></tt></dt>
+ <dd>The archiver produces an archive containing
+ the given LLVM bitcode files, optionally with an index for faster
+ lookup.</dd>
+
+ <dt><tt><b>llvm-as</b></tt></dt>
+ <dd>The assembler transforms the human readable LLVM assembly to LLVM
+ bitcode.</dd>
+
+ <dt><tt><b>llvm-dis</b></tt></dt>
+ <dd>The disassembler transforms the LLVM bitcode to human readable
+ LLVM assembly.</dd>
+
+ <dt><tt><b>llvm-ld</b></tt></dt>
+ <dd><tt>llvm-ld</tt> is a general purpose and extensible linker for LLVM.
+ This is the linker invoked by <tt>llvmc</tt>. It performsn standard link time
+ optimizations and allows optimization modules to be loaded and run so that
+ language specific optimizations can be applied at link time.</dd>
+
+ <dt><tt><b>llvm-link</b></tt></dt>
+ <dd><tt>llvm-link</tt>, not surprisingly, links multiple LLVM modules into
+ a single program.</dd>
+
+ <dt><tt><b>lli</b></tt></dt>
+ <dd><tt>lli</tt> is the LLVM interpreter, which
+ can directly execute LLVM bitcode (although very slowly...). For architectures
+ that support it (currently x86, Sparc, and PowerPC), by default, <tt>lli</tt>
+ will function as a Just-In-Time compiler (if the functionality was compiled
+ in), and will execute the code <i>much</i> faster than the interpreter.</dd>
+
+ <dt><tt><b>llc</b></tt></dt>
+ <dd> <tt>llc</tt> is the LLVM backend compiler, which
+ translates LLVM bitcode to a native code assembly file or to C code (with
+ the -march=c option).</dd>
+
+ <dt><tt><b>llvm-gcc</b></tt></dt>
+ <dd><tt>llvm-gcc</tt> is a GCC-based C frontend that has been retargeted to
+ use LLVM as its backend instead of GCC's RTL backend. It can also emit LLVM
+ bitcode or assembly (with the <tt>-emit-llvm</tt> option) instead of the
+ usual machine code output. It works just like any other GCC compiler,
+ taking the typical <tt>-c, -S, -E, -o</tt> options that are typically used.
+ Additionally, the the source code for <tt>llvm-gcc</tt> is available as a
+ separate Subversion module.</dd>
+
+ <dt><tt><b>opt</b></tt></dt>
+ <dd><tt>opt</tt> reads LLVM bitcode, applies a series of LLVM to LLVM
+ transformations (which are specified on the command line), and then outputs
+ the resultant bitcode. The '<tt>opt --help</tt>' command is a good way to
+ get a list of the program transformations available in LLVM.<br>
+ <dd><tt>opt</tt> can also be used to run a specific analysis on an input
+ LLVM bitcode file and print out the results. It is primarily useful for
+ debugging analyses, or familiarizing yourself with what an analysis does.</dd>
+ </dl>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="utils"><tt>llvm/utils</tt></a></div>
+ <div class="doc_text">
+
+ <p>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
+ are code generators for parts of LLVM infrastructure.</p>
+
+ <dl>
+ <dt><tt><b>codegen-diff</b></tt> <dd><tt>codegen-diff</tt> is a script
+ that finds differences between code that LLC generates and code that LLI
+ generates. This is a useful tool if you are debugging one of them,
+ assuming that the other generates correct output. For the full user
+ manual, run <tt>`perldoc codegen-diff'</tt>.<br><br>
+
+ <dt><tt><b>emacs/</b></tt> <dd>The <tt>emacs</tt> directory contains
+ syntax-highlighting files which will work with Emacs and XEmacs editors,
+ providing syntax highlighting support for LLVM assembly files and TableGen
+ description files. For information on how to use the syntax files, consult
+ the <tt>README</tt> file in that directory.<br><br>
+
+ <dt><tt><b>getsrcs.sh</b></tt> <dd>The <tt>getsrcs.sh</tt> script finds
+ and outputs all non-generated source files, which is useful if one wishes
+ to do a lot of development across directories and does not want to
+ individually find each file. One way to use it is to run, for example:
+ <tt>xemacs `utils/getsources.sh`</tt> from the top of your LLVM source
+ tree.<br><br>
+
+ <dt><tt><b>llvmgrep</b></tt></dt>
+ <dd>This little tool performs an "egrep -H -n" on each source file in LLVM and
+ passes to it a regular expression provided on <tt>llvmgrep</tt>'s command
+ line. This is a very efficient way of searching the source base for a
+ particular regular expression.</dd>
+
+ <dt><tt><b>makellvm</b></tt> <dd>The <tt>makellvm</tt> script compiles all
+ files in the current directory and then compiles and links the tool that
+ is the first argument. For example, assuming you are in the directory
+ <tt>llvm/lib/Target/Sparc</tt>, if <tt>makellvm</tt> is in your path,
+ simply running <tt>makellvm llc</tt> will make a build of the current
+ directory, switch to directory <tt>llvm/tools/llc</tt> and build it,
+ causing a re-linking of LLC.<br><br>
+
+ <dt><tt><b>NewNightlyTest.pl</b></tt> and
+ <tt><b>NightlyTestTemplate.html</b></tt> <dd>These files are used in a
+ cron script to generate nightly status reports of the functionality of
+ tools, and the results can be seen by following the appropriate link on
+ the <a href="http://llvm.org/">LLVM homepage</a>.<br><br>
+
+ <dt><tt><b>TableGen/</b></tt> <dd>The <tt>TableGen</tt> directory contains
+ the tool used to generate register descriptions, instruction set
+ descriptions, and even assemblers from common TableGen description
+ files.<br><br>
+
+ <dt><tt><b>vim/</b></tt> <dd>The <tt>vim</tt> directory contains
+ syntax-highlighting files which will work with the VIM editor, providing
+ syntax highlighting support for LLVM assembly files and TableGen
+ description files. For information on how to use the syntax files, consult
+ the <tt>README</tt> file in that directory.<br><br>
+
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="win32"><tt>llvm/win32</tt></a></div>
+ <div class="doc_text">
+ <p>This directory contains build scripts and project files for use with
+ Visual C++. This allows developers on Windows to build LLVM without the need
+ for Cygwin. The contents of this directory should be considered experimental
+ at this time.
+ </p>
+ </div>
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="tutorial">An Example Using the LLVM Tool Chain</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>This section gives an example of using LLVM. llvm-gcc3 is now obsolete,
+ so we only include instructiosn for llvm-gcc4.
+ </p>
+
+ <p><b>Note:</b> The <i>gcc4</i> frontend's invocation is <b><i>considerably different</i></b>
+ from the previous <i>gcc3</i> frontend. In particular, the <i>gcc4</i> frontend <b><i>does not</i></b>
+ create bitcode by default: <i>gcc4</i> produces native code. As the example below illustrates,
+ the '--emit-llvm' flag is needed to produce LLVM bitcode output. For <i>makefiles</i> and
+ <i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode
+ output.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="tutorial4">Example with llvm-gcc4</a></div>
+
+ <div class="doc_text">
+
+ <ol>
+ <li><p>First, create a simple C file, name it 'hello.c':</p>
+
+ <div class="doc_code">
+ <pre>
+ #include <stdio.h>
+
+ int main() {
+ printf("hello world\n");
+ return 0;
+ }
+ </pre></div></li>
+
+ <li><p>Next, compile the C file into a native executable:</p>
+
+ <div class="doc_code"><pre>% llvm-gcc hello.c -o hello</pre></div>
+
+ <p>Note that llvm-gcc works just like GCC by default. The standard -S and
+ -c arguments work as usual (producing a native .s or .o file,
+ respectively).</p></li>
+
+ <li><p>Next, compile the C file into a LLVM bitcode file:</p>
+
+ <div class="doc_code">
+ <pre>% llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc</pre></div>
+
+ <p>The -emit-llvm option can be used with the -S or -c options to emit an
+ LLVM ".ll" or ".bc" file (respectively) for the code. This allows you
+ to use the <a href="CommandGuide/index.html">standard LLVM tools</a> on
+ the bitcode file.</p>
+
+ <p>Unlike llvm-gcc3, llvm-gcc4 correctly responds to -O[0123] arguments.
+ </p></li>
+
+ <li><p>Run the program in both forms. To run the program, use:</p>
+
+ <div class="doc_code"><pre>% ./hello</pre></div>
+
+ <p>and</p>
+
+ <div class="doc_code"><pre>% lli hello.bc</pre></div>
+
+ <p>The second examples shows how to invoke the LLVM JIT, <a
+ href="CommandGuide/html/lli.html">lli</a>.</p></li>
+
+ <li><p>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
+ code:</p>
+
+ <div class="doc_code">
+ <pre>llvm-dis < hello.bc | less</pre>
+ </div></li>
+
+ <li><p>Compile the program to native assembly using the LLC code
+ generator:</p>
+
+ <div class="doc_code"><pre>% llc hello.bc -o hello.s</pre></div></li>
+
+ <li><p>Assemble the native assembly language file into a program:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>Solaris:</b> % /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native
+
+ <b>Others:</b> % gcc hello.s -o hello.native
+ </pre>
+ </div></li>
+
+ <li><p>Execute the native code program:</p>
+
+ <div class="doc_code"><pre>% ./hello.native</pre></div>
+
+ <p>Note that using llvm-gcc to compile directly to native code (i.e. when
+ the -emit-llvm option is not present) does steps 6/7/8 for you.</p>
+ </li>
+
+ </ol>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="problems">Common Problems</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>If you are having problems building or using LLVM, or if you have any other
+ general questions about LLVM, please consult the <a href="FAQ.html">Frequently
+ Asked Questions</a> page.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="links">Links</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document is just an <b>introduction</b> on how to use LLVM to do
+ some simple things... there are many more interesting and complicated things
+ that you can do that aren't documented here (but we'll gladly accept a patch
+ if you want to write something up!). For more information about LLVM, check
+ out:</p>
+
+ <ul>
+ <li><a href="http://llvm.org/">LLVM homepage</a></li>
+ <li><a href="http://llvm.org/doxygen/">LLVM doxygen tree</a></li>
+ <li><a href="http://llvm.org/docs/Projects.html">Starting a Project
+ that Uses LLVM</a></li>
+ </ul>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.x10sys.com/rspencer/">Reid Spencer</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/GettingStartedVS.html
diff -c /dev/null llvm-www/releases/2.5/docs/GettingStartedVS.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/GettingStartedVS.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,406 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>Getting Started with LLVM System for Microsoft Visual Studio</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ Getting Started with the LLVM System using Microsoft Visual Studio
+ </div>
+
+ <ul>
+ <li><a href="#overview">Overview</a>
+ <li><a href="#quickstart">Getting Started Quickly (A Summary)</a>
+ <li><a href="#requirements">Requirements</a>
+ <ol>
+ <li><a href="#hardware">Hardware</a>
+ <li><a href="#software">Software</a>
+ </ol></li>
+
+ <li><a href="#starting">Getting Started with LLVM</a>
+ <ol>
+ <li><a href="#terminology">Terminology and Notation</a>
+ <li><a href="#objfiles">The Location of LLVM Object Files</a>
+ </ol></li>
+
+ <li><a href="#tutorial">An Example Using the LLVM Tool Chain</a>
+ <li><a href="#problems">Common Problems</a>
+ <li><a href="#links">Links</a>
+ </ul>
+
+ <div class="doc_author">
+ <p>Written by:
+ <a href="mailto:jeffc at jolt-lang.org">Jeff Cohen</a>
+ </p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="overview"><b>Overview</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The Visual Studio port at this time is experimental. It is suitable for
+ use only if you are writing your own compiler front end or otherwise have a
+ need to dynamically generate machine code. The JIT and interpreter are
+ functional, but it is currently not possible to generate assembly code which
+ is then assembled into an executable. You can indirectly create executables
+ by using the C back end.</p>
+
+ <p>To emphasize, there is no C/C++ front end currently available.
+ <tt>llvm-gcc</tt> is based on GCC, which cannot be bootstrapped using VC++.
+ Eventually there should be a <tt>llvm-gcc</tt> based on Cygwin or MinGW that
+ is usable. There is also the option of generating bitcode files on Unix and
+ copying them over to Windows. But be aware the odds of linking C++ code
+ compiled with <tt>llvm-gcc</tt> with code compiled with VC++ is essentially
+ zero.</p>
+
+ <p>The LLVM test suite cannot be run on the Visual Studio port at this
+ time.</p>
+
+ <p>Most of the tools build and work. <tt>bugpoint</tt> does build, but does
+ not work. The other tools 'should' work, but have not been fully tested.</p>
+
+ <p>Additional information about the LLVM directory structure and tool chain
+ can be found on the main <a href="GettingStarted.html">Getting Started</a>
+ page.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="quickstart"><b>Getting Started Quickly (A Summary)</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Here's the short story for getting up and running quickly with LLVM:</p>
+
+ <ol>
+ <li>Read the documentation.</li>
+ <li>Seriously, read the documentation.</li>
+ <li>Remember that you were warned twice about reading the documentation.</li>
+
+ <li>Get the Source Code
+ <ul>
+ <li>With the distributed files:
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+ <li><tt>gunzip --stdout llvm-<i>version</i>.tar.gz | tar -xvf -</tt>
+ <i> or use WinZip</i>
+ <li><tt>cd llvm</tt></li>
+ </ol></li>
+
+ <li>With anonymous Subversion access:
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt></li>
+ <li><tt>svn co http://llvm.org/svn/llvm-project/llvm-top/trunk llvm-top
+ </tt></li>
+ <li><tt>make checkout MODULE=llvm</tt>
+ <li><tt>cd llvm</tt></li>
+ </ol></li>
+ </ul></li>
+
+ <li> Use <a href="http://www.cmake.org/">CMake</a> to generate up-to-date
+ project files:
+ <ul><li>This step is currently optional as LLVM does still come with a
+ normal Visual Studio solution file, but it is not always kept up-to-date
+ and will soon be deprecated in favor of the multi-platform generator
+ CMake.</li>
+ <li>If CMake is installed then the most simple way is to just start the
+ CMake GUI, select the directory where you have LLVM extracted to, and
+ the default options should all be fine. The one option you may really
+ want to change, regardless of anything else, might be the
+ CMAKE_INSTALL_PREFIX setting to select a directory to INSTALL to once
+ compiling is complete.</li>
+ <li>If you use CMake to generate the Visual Studio solution and project
+ files, then the Solution will have a few extra options compared to the
+ current included one. The projects may still be built individually, but
+ to build them all do not just select all of them in batch build (as some
+ are meant as configuration projects), but rather select and build just
+ the ALL_BUILD project to build everything, or the INSTALL project, which
+ first builds the ALL_BUILD project, then installs the LLVM headers, libs,
+ and other useful things to the directory set by the CMAKE_INSTALL_PREFIX
+ setting when you first configured CMake.</li>
+ </ul>
+ </li>
+
+ <li>Start Visual Studio
+ <ul>
+ <li>If you did not use CMake, then simply double click on the solution
+ file <tt>llvm/win32/llvm.sln</tt>.</li>
+ <li>If you used CMake, then the directory you created the project files,
+ the root directory will have an <tt>llvm.sln</tt> file, just
+ double-click on that to open Visual Studio.</li>
+ </ol></li>
+
+ <li>Build the LLVM Suite:
+ <ol>
+ <li>Simply build the solution.</li>
+ <li>The Fibonacci project is a sample program that uses the JIT. Modify
+ the project's debugging properties to provide a numeric command line
+ argument. The program will print the corresponding fibonacci value.</li>
+ </ol></li>
+
+ </ol>
+
+ <p>It is strongly encouraged that you get the latest version from Subversion as
+ changes are continually making the VS support better.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="requirements"><b>Requirements</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="hardware"><b>Hardware</b></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>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
+ approximately 3GB.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="software"><b>Software</b></a></div>
+ <div class="doc_text">
+
+ <p>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
+ compatible. VS2003 would work except (at last check) it has a bug with
+ friend classes that you can work-around with some minor code rewriting
+ (and please submit a patch if you do). Earlier versions of Visual Studio
+ do not support the C++ standard well enough and will not work.</p>
+
+ <p>You will also need the <a href="http://www.cmake.org/">CMake</a> build
+ system since it generates the project files you will use to build with.</p>
+
+ <p>
+ Do not install the LLVM directory tree into a path containing spaces (e.g.
+ C:\Documents and Settings\...) as the configure step will fail.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="starting"><b>Getting Started with LLVM</b></a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The remainder of this guide is meant to get you up and running with
+ LLVM using Visual Studio and to give you some basic information about the LLVM
+ environment.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="terminology">Terminology and Notation</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Throughout this manual, the following names are used to denote paths
+ specific to the local system and working environment. <i>These are not
+ environment variables you need to set but just strings used in the rest
+ of this document below</i>. In any of the examples below, simply replace
+ each of these names with the appropriate pathname on your local system.
+ All these paths are absolute:</p>
+
+ <dl>
+ <dt>SRC_ROOT</dt>
+ <dd><p>This is the top level directory of the LLVM source tree.</p></dd>
+
+ <dt>OBJ_ROOT</dt>
+ <dd><p>This is the top level directory of the LLVM object tree (i.e. the
+ tree where object files and compiled programs will be placed. It is
+ fixed at SRC_ROOT/win32).</p></dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="objfiles">The Location of LLVM Object Files</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The object files are placed under <tt>OBJ_ROOT/Debug</tt> for debug builds
+ and <tt>OBJ_ROOT/Release</tt> for release (optimized) builds. These include
+ both executables and libararies that your application can link against.</p>
+
+ <p>The files that <tt>configure</tt> would create when building on Unix are
+ created by the <tt>Configure</tt> project and placed in
+ <tt>OBJ_ROOT/llvm</tt>. You application must have OBJ_ROOT in its include
+ search path just before <tt>SRC_ROOT/include</tt>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="tutorial">An Example Using the LLVM Tool Chain</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <ol>
+ <li><p>First, create a simple C file, name it 'hello.c':</p>
+
+ <div class="doc_code">
+ <pre>
+ #include <stdio.h>
+ int main() {
+ printf("hello world\n");
+ return 0;
+ }
+ </pre></div></li>
+
+ <li><p>Next, compile the C file into a LLVM bitcode file:</p>
+
+ <div class="doc_code">
+ <pre>
+ % llvm-gcc -c hello.c -emit-llvm -o hello.bc
+ </pre>
+ </div>
+
+ <p>This will create the result file <tt>hello.bc</tt> which is the LLVM
+ bitcode that corresponds the the compiled program and the library
+ facilities that it required. You can execute this file directly using
+ <tt>lli</tt> tool, compile it to native assembly with the <tt>llc</tt>,
+ optimize or analyze it further with the <tt>opt</tt> tool, etc.</p>
+
+ <p><b>Note: while you cannot do this step on Windows, you can do it on a
+ Unix system and transfer <tt>hello.bc</tt> to Windows. Important:
+ transfer as a binary file!</b></p></li>
+
+ <li><p>Run the program using the just-in-time compiler:</p>
+
+ <div class="doc_code">
+ <pre>
+ % lli hello.bc
+ </pre>
+ </div>
+
+ <p>Note: this will only work for trivial C programs. Non-trivial programs
+ (and any C++ program) will have dependencies on the GCC runtime that
+ won't be satisfied by the Microsoft runtime libraries.</p></li>
+
+ <li><p>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
+ code:</p>
+
+ <div class="doc_code">
+ <pre>
+ % llvm-dis < hello.bc | more
+ </pre>
+ </div></li>
+
+ <li><p>Compile the program to C using the LLC code generator:</p>
+
+ <div class="doc_code">
+ <pre>
+ % llc -march=c hello.bc
+ </pre>
+ </div></li>
+
+ <li><p>Compile to binary using Microsoft C:</p>
+
+ <div class="doc_code">
+ <pre>
+ % cl hello.cbe.c
+ </pre>
+ </div>
+
+ <p>Note: this will only work for trivial C programs. Non-trivial programs
+ (and any C++ program) will have dependencies on the GCC runtime that
+ won't be satisfied by the Microsoft runtime libraries.</p></li>
+
+ <li><p>Execute the native code program:</p>
+
+ <div class="doc_code">
+ <pre>
+ % hello.cbe.exe
+ </pre>
+ </div></li>
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="problems">Common Problems</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>If you are having problems building or using LLVM, or if you have any other
+ general questions about LLVM, please consult the <a href="FAQ.html">Frequently
+ Asked Questions</a> page.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="links">Links</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document is just an <b>introduction</b> to how to use LLVM to do
+ some simple things... there are many more interesting and complicated things
+ that you can do that aren't documented here (but we'll gladly accept a patch
+ if you want to write something up!). For more information about LLVM, check
+ out:</p>
+
+ <ul>
+ <li><a href="http://llvm.org/">LLVM homepage</a></li>
+ <li><a href="http://llvm.org/doxygen/">LLVM doxygen tree</a></li>
+ <li><a href="http://llvm.org/docs/Projects.html">Starting a Project
+ that Uses LLVM</a></li>
+ </ul>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:jeffc at jolt-lang.org">Jeff Cohen</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/HowToReleaseLLVM.html
diff -c /dev/null llvm-www/releases/2.5/docs/HowToReleaseLLVM.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/HowToReleaseLLVM.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,600 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>How To Release LLVM To The Public</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">How To Release LLVM To The Public</div>
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#introduction">Release Timeline</a></li>
+ <li><a href="#process">Release Process</a></li>
+ <li><a href="#dist_targets">Distribution Targets</a></li>
+ </ol>
+ <div class="doc_author">
+ <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a>,
+ <a href="mailto:criswell at cs.uiuc.edu">John Criswell</a>,
+ <a href="mailto:tonic at nondot.org">Tanya Lattner</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="introduction">Introduction</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ This document collects information about successfully releasing LLVM to the
+ public. It is the release manager's guide to ensuring that a high quality
+ build of LLVM is released.
+ </p>
+
+ <p>
+ The following is the basic criteria for releasing LLVM:
+ </p>
+
+ <ol>
+ <li>Successful configure and build.</li>
+ <li>Clean 'make check'.</li>
+ <li>No regressions in the testsuite from the previous release. This may
+ include performance regressions for major benchmarks.</li>
+ </ol>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="process">Release Timeline</a></div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ The release manager should attempt to have a release every 3-4 months because LLVM
+ does time based releases (instead of feature based). The release schedule should
+ be roughly as follows:
+ <ol>
+ <li>Set code freeze and branch creation date for 3 months after last release
+ date. Announce release schedule to the LLVM community and update the website.</li>
+ <li>Create release branch and begin release process. </li>
+ <li>Send out pre-release for first round of testing. Testing will last 7-10 days.
+ During the first round of testing, regressions should be found and fixed. Patches
+ are merged from mainline to the release branch.</li>
+ <li>Generate and send out second pre-release. Bugs found during this time will
+ not be fixed unless absolutely critical. Bugs introduce by patches merged in
+ will be fixed and if so, a 3rd round of testing is needed.</li>
+ <li>The release notes should be updated during the first and second round of
+ pre-release testing.</li>
+ <li>Finally, release!</li>
+ </ol>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="process">Release Process</a></div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="overview">Process Overview</a></div>
+ <div class="doc_text">
+ <ol>
+ <li><a href="#branch">Create Release Branch</a></li>
+ <li><a href="#verchanges">Update LLVM Version </a></li>
+ <li><a href="#dist">Build the LLVM Source Distributions</a></li>
+ <li><a href="#build">Build LLVM</a></li>
+ <li><a href="#llvmgccbin">Build the LLVM GCC Binary Distribution</a></li>
+ <li><a href="#rpm">Build RPM Packages (optional)</a></li>
+ <li><a href="#check">Run 'make check'</a></li>
+ <li><a href="#test">Run LLVM Test Suite</a></li>
+ <li><a href="#prerelease">Pre-Release Testing</a></li>
+ <li><a href="#tag">Tag the LLVM Release Branch</a></li>
+ <li><a href="#updocs">Update Documentation</a></li>
+ <li><a href="#updemo">Update the LLVM Demo Page</a></li>
+ <li><a href="#webupdates">Update the LLVM Website</a></li>
+ <li><a href="#announce">Announce the Release</a></li>
+
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="branch">Create Release Branch</a></div>
+ <div class="doc_text">
+ <p>Branch the Subversion HEAD using the following procedure:</p>
+ <ol>
+ <li>
+ <p>Verify that the current Subversion HEAD is in decent shape by examining nightly
+ tester results.</p></li>
+ <li>
+ <p>Request all developers to refrain from committing. Offenders get commit
+ rights taken away (temporarily).</p></li>
+ <li>
+ <p> Create the release branch for <tt>llvm</tt>, <tt>llvm-gcc4.2</tt>, and
+ the <tt>test-suite</tt>. The branch name will be <tt>release_XX</tt>,
+ where <tt>XX</tt> is the major and minor release numbers. These branches can
+ be created without checking out anything from subversion.
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
+ https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XX</i>
+ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \
+ https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XX</i>
+ svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
+ https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XX</i>
+ </pre>
+ </div>
+
+ <li>
+ <p>Advise developers they can work on Subversion HEAD again.</p></li>
+
+ <li>
+ <p>The Release Manager should switch to the release branch (as all changes
+ to the release will now be done in the branch). The easiest way to do this
+ is to grab another working copy using the following commands:</p>
+
+ <div class="doc_code">
+ <pre>
+ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XX</i>
+ svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XX</i>
+ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XX</i>
+ </pre>
+ </div></li>
+
+ </div>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="verchanges">Update LLVM Version</a></div>
+ <div class="doc_text">
+ <p>
+ After creating the LLVM release branch, update the release branches'
+ autoconf/configure.ac version from X.Xsvn to just X.X. Update it on mainline
+ as well to be the next version (X.X+1svn). Regenerated the configure script
+ for both. This must be done for both llvm and the test-suite.
+ </p>
+ <p>In addition, the version number of all the Bugzilla components must be
+ updated for the next release.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="dist">Build the LLVM Source Distributions</a></div>
+ <div class="doc_text">
+ <p>
+ Create source distributions for LLVM, LLVM GCC, and the LLVM Test Suite by
+ exporting the source from Subversion and archiving it. This can be done with
+ the following commands:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ svn export https://llvm.org/svn/llvm-project/llvm/branches/release_<i>XX</i> llvm-X.X
+ svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_<i>XX</i> llvm-gcc4.2-X.X.source
+ svn export https://llvm.org/svn/llvm-project/test-suite/branches/release_<i>XX</i> llvm-test-X.X
+ tar -cvf - llvm-X.X | gzip > llvm-X.X.tar.gz
+ tar -cvf - llvm-test-X.X | gzip > llvm-test-X.X.tar.gz
+ tar -cvf - llvm-gcc4.2-X.X.source | gzip > llvm-gcc-4.2-X.X.source.tar.gz
+ </pre>
+ </div>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="build">Build LLVM</a></div>
+ <div class="doc_text">
+ <p>
+ Build both debug and release (optimized) versions of LLVM on all
+ platforms. Ensure the build is warning and error free on each platform.
+ Note that when building the LLVM GCC Binary, use a release build of LLVM.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="llvmgccbin">Build the LLVM GCC Binary Distribution</a></div>
+ <div class="doc_text">
+ <p>
+ Creating the LLVM GCC binary distribution (release/optimized) requires
+ performing the following steps for each supported platform:
+ </p>
+
+ <ol>
+ <li>
+ Build the LLVM GCC front-end by following the directions in the README.LLVM
+ file. Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and
+ minor release numbers.
+ </li>
+
+ <li>
+ Copy the installation directory to a directory named for the specific target.
+ For example on Red Hat Enterprise Linux, the directory would be named
+ <tt>llvm-gcc4.0-2.1-x86-linux-RHEL4</tt>. Archive and compress the new directory.
+ </li>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="check">Run 'make check'</a></div>
+ <div class="doc_text">
+ <p>
+ Using the newly built llvm-gcc and llvm, reconfigure llvm to locate llvm-gcc.
+ Run <tt>make check</tt> and ensure there are no unexpected failures. If there
+ are, resolve the failures or file a bug. If there is a fix commited to mainline,
+ merge back into the release branch, and restart testing by
+ <a href="#build">re-building LLVM</a> and <a href="#build">llvm-gcc</a>. If no
+ fix will be made, XFAIL the test and commit back to the release branch.
+ </p>
+
+ <p>
+ Ensure that '<tt>make check</tt>' passes on all platforms for all targets. The
+ test suite must complete with "0 unexpected failures" before sending out the
+ pre-releases for testing.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="test">LLVM Test Suite</a></div>
+ <div class="doc_text">
+ <p>
+ Run the <tt>llvm-test</tt> suite and ensure there are no unacceptable
+ failures. Unacceptable failures are regression from the previous release
+ and (optionally) major performance regressions from the previous release.
+ If a regression is found a bug is filled, but the pre-releases may still go
+ out.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="rpm">Building RPM packages (optional)</a></div>
+ <div class="doc_text">
+ <p>
+ You can, optionally, create source and binary RPM packages for LLVM. These may
+ make it easier to get LLVM into a distribution. This can be done with the
+ following commands:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ make dist # Build the distribution source tarball
+ make dist-check # Check that the source tarball can build itself.
+ cp llvm-M.m.tar.gz /usr/src/redhat/SOURCES # Required by rpmbuild
+ make srpm # for source rpm
+ make rpm # for binary rpm
+ </pre>
+ </div>
+
+ <p>
+ First, use <tt>make dist</tt> to simply build the distribution. Any failures
+ need to be corrected (on the branch). Once <tt>make dist</tt> can be
+ successful, do <tt>make dist-check</tt>. This target will do the same thing as
+ the 'dist' target but also test that distribution to make sure it can build
+ itself and runs <tt>make check</tt> as well. This ensures that needed files
+ are not missing and that the src tarball can be successfully unpacked, built,
+ installed, and cleaned. Once you have a reliable tarball, you need to copy it
+ to the <tt>/usr/src/redhat/SOURCES</tt> directory which is a requirement of
+ the rpmbuild tool. The last two <tt>make</tt> invocations just run rpmbuild to
+ build either a source (<tt>srpm</tt>) or binary (<tt>rpm</tt>) RPM package.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="prerelease">Pre-Release Testing</a></div>
+ <div class="doc_text">
+ <p>
+ Once all testing has been completed and appropriate bugs filed, the pre-release
+ tar balls may be put on the website and the LLVM community is notified. Ask that
+ all LLVM developers test the release in 2 ways:</p>
+ <ol>
+ <li>Download llvm-X.X, llvm-test-X.X, and the appropriate llvm-gcc4 binary.
+ Run "make check" and the full llvm-test suite (make TEST=nightly report).<li>
+ <li>Download llvm-X.X, llvm-test-X.X, and the llvm-gcc4 source. Compile
+ everything. Run "make check" and the full llvm-test suite (make TEST=nightly
+ report).</li>
+ </ol>
+ <p>Ask LLVM developers to submit the report and make check results to the list.
+ Verify that there are no regressions from the previous release. For
+ unsupported targets, verify that make check at least is clean.</p>
+
+ <p>The first round of pre-release testing will be the longest. During this time,
+ all regressions must be fixed before the second pre-release is created (repeat
+ steps 4-8).</p>
+
+ <p>If this is the second round of testing, this is only to ensure the bug fixes
+ previously merged in have not created new major problems. This is not the time
+ to solve additional and unrelated bugs. If no patches are merged in, the release
+ is determined to be ready and the release manager may move onto the next step.</p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="tag">Tag the Release Branch</a></div>
+ <div class="doc_text">
+ <p>Tag the release branch using the following procedure:</p>
+ <div class="doc_code">
+ <pre>
+ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XX \
+ https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_<i>XX</i>
+ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX \
+ https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_<i>XX</i>
+ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
+ https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_<i>XX</i>
+ </pre>
+ </div>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="updocs">Update Documentation</a></div>
+ <div class="doc_text">
+ <p>
+ Review the documentation and ensure that it is up to date. The Release Notes
+ must be updated to reflect bug fixes, new known issues, and changes in the
+ list of supported platforms. The Getting Started Guide should be updated to
+ reflect the new release version number tag avaiable from Subversion and
+ changes in basic system requirements. Merge both changes from mainline into
+ the release branch.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="updemo">Update the LLVM Demo Page</a></div>
+ <div class="doc_text">
+ <p>
+ The LLVM demo page must be updated to use the new release. This consists of
+ using the llvm-gcc binary and building LLVM. Update the website demo page
+ configuration to use the new release.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="webupdates">Update the LLVM Website</a></div>
+ <div class="doc_text">
+ <p>
+ The website must be updated before the release announcement is sent out. Here is
+ what to do:</p>
+ <ol>
+ <li> Check out the <tt>website</tt> module from CVS. </li>
+ <li> Create a new subdirectory X.X in the releases directory. </li>
+ <li> Commit the <tt>llvm</tt>, <tt>test-suite</tt>, <tt>llvm-gcc</tt> source,
+ and <tt>llvm-gcc</tt> binaries in this new directory. </li>
+ <li> Copy and commit the <tt>llvm/docs</tt> and <tt>LICENSE.txt</tt>
+ files into this new directory. The docs should be built with BUILD_FOR_WEBSITE=1.</li>
+ <li> Commit the index.html to the release/X.X directory to redirect (use from previous
+ release. </li>
+ <li> Update the <tt>releases/download.html</tt> file with the new release. </li>
+ <li>Update the <tt>releases/index.html</tt> with the new release and link to
+ release documentation.</li>
+ <li> Finally, update the main page (<tt>index.html</tt> and sidebar) to
+ point to the new release and release announcement. Make sure this all gets
+ commited back into Subversion.</li>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="announce">Announce the Release</a></div>
+ <div class="doc_text">
+ <p>Have Chris send out the release announcement when everything is finished.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="dist_targets">Distribution Targets</a></div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">Overview</div>
+ <div class="doc_text">
+ <p>
+ The first thing you need to understand is that there are multiple make targets
+ to support this feature. Here's an overview, we'll delve into the details
+ later.
+ </p>
+
+ <ul>
+ <li><b>distdir</b> - builds the distribution directory from which the
+ distribution will be packaged</li>
+ <li><b>dist</b> - builds each of the distribution tarballs (tar.gz,
+ tar.bzip2, .zip). These can be built individually as well, with separate
+ targets.</li>
+ <li><b>dist-check</b> - this is identical to <tt>dist</tt> but includes a
+ check on the distribution that ensures the tarball can: unpack
+ successfully, compile correctly, pass '<tt>make check</tt>', and pass
+ '<tt>make clean</tt>'.</li>
+ <li><b>dist-clean</b>- this just does a normal clean but also cleans up the
+ stuff generated by the other three <tt>dist</tt> targets (above).</li>
+ </ul>
+
+ <p>
+ Okay, that's the basic functionality. When making a release, we want to ensure
+ that the tree you build the distribution from passes
+ <tt>dist-check</tt>. Beyond fixing the usual bugs, there is generally one
+ impediment to making the release in this fashion: missing files. The
+ <tt>dist-check</tt> process guards against that possibility. It will either
+ fail and that failure will indicate what's missing, or it will succeed meaning
+ that it has proved that the tarballs can actually succeed in building LLVM
+ correctly and that it passes <tt>make check</tt>.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+
+ <div class="doc_subsection">distdir</div>
+ <div class="doc_text">
+ <p>
+ This target builds the distribution directory which is the directory from
+ which the tarballs are generated. The distribution directory has the same
+ name as the release, e.g. LLVM-1.7). This target goes through the following
+ process:
+ </p>
+
+ <ol>
+ <li>First, if there was an old distribution directory (for the current
+ release), it is removed in its entirety and you see <tt>Removing old
+ LLVM-1.7</tt></li>
+ <li>Second, it issues a <tt>make all ENABLE_OPTIMIZED=3D1</tt> to ensure
+ that the everything in your tree can be built in release mode. Often
+ times there are discrepancies in building between debug and release
+ modes so it enforces release mode first. If that fails, the
+ <tt>distdir</tt> target fails too. This is preceded by the message
+ <tt>Making 'all' to verify build</tt>.</li>
+ <li>Next, it traverses your source tree and copies it to a new directory
+ that has the name of the release (<tt>LLVM-M.m</tt> in our current
+ case). This is the directory that will get tar'd. It contains all the
+ software that needs to be in the distribution. During the copying
+ process, it omits generated files, SVN directories, and any other
+ "cruft" that's in your build tree. This is done to eliminate the
+ possibility of huge distribution tarballs that include useless or
+ irrelevant stuff in them. This is the trickiest part of making the
+ distribution. Done manually you will either include stuff that
+ shouldn't be in the distribution or exclude stuff that should. This
+ step is preceded by the message <tt>Building Distribution Directory
+ LLVM-1.7</tt></li>
+ <li>The distribution directory is then traversed and all <tt>CVS</tt> or
+ <tt>.svn</tt> directories are removed. You see: <tt>Eliminating CVS/.svn
+ directories from distribution</tt></li>
+ <li>The recursive <tt>dist-hook</tt> target is executed. This gives each
+ directory a chance to modify the distribution in some way (more on this
+ below).</li>
+ <li>The distribution directory is traversed and the correct file
+ permissions and modes are set based on the type of file.</li>
+ </ol>
+
+ <p>
+ To control the process of making the distribution directory correctly, each
+ Makefile can utilize two features:
+ </p>
+
+ <ol>
+ <li><b><tt>EXTRA_DIST</tt></B> - this make variable specifies which files
+ it should distribute. By default, all source files are automatically
+ included for distribution as well as certain <tt>well known</tt> files
+ (see DistAlways variable in Makefile.rules for details). Each Makefile
+ specifies, via the <tt>EXTRA_DIST</tt> variable, which additional files
+ need to be distributed. Only those files that are needed to build LLVM
+ should be added to <tt>EXTRA_DIST</tt>. <tt>EXTRA_DIST</tt> contains a
+ list of file or directory names that should be distributed. For example,
+ the top level Makefile contains <tt>EXTRA_DIST := test llvm.spec
+ include</tt>. This means that in addition to regular things that are
+ distributed at the top level (<tt>CREDITS.txt, LICENSE.txt</tt>, etc.)
+ the distribution should contain the entire <tt>test</tt> and
+ <tt>include</tt> directories as well as the <tt>llvm.spec</tt> file.</li>
+ <li><b><tt>dist-hook</tt></B> - this make target can be used to alter the
+ content of the distribution directory. For example, in the top level
+ Makefile there is some logic to eliminate files in the <tt>include</tt>
+ subtree that are generated by the configure script. These should not be
+ distributed. Similarly, any <tt>dist-hook</tt> target found in any
+ directory can add or remove or modify things just before it gets
+ packaged. Any transformation is permitted. Generally, not much is
+ needed.</li>
+ </ol>
+
+ <p>
+ You will see various messages if things go wrong:
+ </p>
+
+ <ol>
+ <li>During the copying process, any files that are missing will be flagged
+ with: <tt>===== WARNING: Distribution Source 'dir/file' Not Found!</tt>
+ These must be corrected by either adding the file or removing it from
+ <tt>EXTRA_DIST</tt>.</li>
+ <li>If you build the distribution with <tt>VERBOSE=1</tt>, then you might
+ also see: <tt>Skipping non-existent 'dir/file'</tt> in certain cases
+ where it's okay to skip the file.</li>
+ <li>The target can fail if any of the things it does fail. Error messages
+ should indicate what went wrong.</li>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">dist</div>
+ <div class="doc_text">
+ <p>
+ This target does exactly what <tt>distdir</tt> target does, but also includes
+ assembling the tarballs. There are actually four related targets here:
+ </p>
+
+ <ul>
+ <li><b><tt>dist-gzip</tt></b>: package the gzipped distribution tar
+ file. The distribution directory is packaged into a single file ending
+ in <tt>.tar.gz</tt> which is gzip compressed.</li>
+ <li><b><tt>dist-bzip2</tt></b>: package the bzip2 distribution tar file.
+ The distribution directory is packaged into a single file ending in
+ <tt>.tar.bzip2</tt> which is bzip2 compressed.</li>
+ <li><b><tt>dist-zip</tt></b>: package the zip distribution file. The
+ distribution directory is packaged into a single file ending in
+ <tt>.zip</tt> which is zip compressed.</li>
+ <li><b><tt>dist</tt></b>: does all three, dist-gzip, dist-bzip2,
+ dist-zip</li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">dist-check</div>
+ <div class="doc_text">
+ <p>
+ This target checks the distribution. The basic idea is that it unpacks the
+ distribution tarball and ensures that it can build. It takes the following
+ actions:
+ </p>
+
+ <ol>
+ <li>It depends on the <tt>dist-gzip</tt> target which, if it hasn't already
+ been built, builds the gzip tar bundle (see dist and distdir
+ above).</li>
+ <li>removes any pre-existing <tt>_distcheckdir</tt> at the top level.</li>
+ <li>creates a new <tt>_distcheckdir</tt> directory at the top level.</li>
+ <li>creates a <tt>build</tt> subdirectory and an <tt>install</tt>
+ subdirectory under <tt>_distcheckdir</tt>.</li>
+ <li>unzips and untars the release tarball into <tt>_distcheckdir</tt>,
+ creating <tt>LLVM-1.7</tt> directory (from the tarball).</li>
+ <li>in the build subdirectory, it configures with appropriate options to
+ build from the unpacked source tarball into the <tt>build</tt> directory
+ with installation in the <tt>install</tt> directory.</li>
+ <li>runs <tt>make all</tt></li>
+ <li>runs <tt>make </tt><tt>check</tt></li>
+ <li>runs <tt>make install</tt></li>
+ <li>runs <tt>make uninstall</tt></li>
+ <li>runs <tt>make dist</tt></li>
+ <li>runs <tt>make clean</tt></li>
+ <li>runs <tt>make dist-clean</tt></li>
+ </ol>
+
+ <p>
+ If it can pass all that, the distribution will be deemed distribution worth y
+ and you will see:
+ </p>
+
+ <pre>===== LLVM-1.7.tar.gz Ready For Distribution =====</pre>
+
+ <p>
+ This means the tarball should then be tested on other platforms and have the
+ nightly test run against it. If those all pass, THEN it is ready for
+ distribution.
+ </p>
+
+ <p>
+ A note about disk space: using <tt>dist-check</tt> will easily triple the
+ amount of disk space your build tree is using. You might want to check
+ available space before you begin.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">dist-clean</div>
+ <div class="doc_text">
+ <p>
+ In addition to doing a normal <tt>clean</tt>, this target will clean up the
+ files and directories created by the distribution targets. In particular the
+ distribution directory (<tt>LLVM-X.X</tt>), check directory
+ (<tt>_distcheckdir</tt>), and the various tarballs will be removed. You do
+ this after the release has shipped and you no longer need this stuff in your
+ build tree.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/HowToSubmitABug.html
diff -c /dev/null llvm-www/releases/2.5/docs/HowToSubmitABug.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/HowToSubmitABug.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,355 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>How to submit an LLVM bug report</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ How to submit an LLVM bug report
+ </div>
+
+ <table class="layout" style="width: 90%" >
+ <tr class="layout">
+ <td class="left">
+ <ol>
+ <li><a href="#introduction">Introduction - Got bugs?</a></li>
+ <li><a href="#crashers">Crashing Bugs</a>
+ <ul>
+ <li><a href="#front-end">Front-end bugs</a>
+ <li><a href="#ct_optimizer">Compile-time optimization bugs</a>
+ <li><a href="#ct_codegen">Code generator bugs</a>
+ </ul></li>
+ <li><a href="#miscompilations">Miscompilations</a></li>
+ <li><a href="#codegen">Incorrect code generation (JIT and LLC)</a></li>
+ </ol>
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and
+ <a href="http://misha.brukman.net">Misha Brukman</a></p>
+ </div>
+ </td>
+ <td class="right">
+ <img src="img/Debugging.gif" alt="Debugging" width="444" height="314">
+ </td>
+ </tr>
+ </table>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction - Got bugs?</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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
+ getting it fixed quickly.</p>
+
+ <p>Basically you have to do two things at a minimum. First, decide whether the
+ bug <a href="#crashers">crashes the compiler</a> (or an LLVM pass), or if the
+ compiler is <a href="#miscompilations">miscompiling</a> the program (i.e., the
+ compiler successfully produces an executable, but it doesn't run right). Based
+ on
+ what type of bug it is, follow the instructions in the linked section to narrow
+ down the bug so that the person who fixes it will be able to find the problem
+ more easily.</p>
+
+ <p>Once you have a reduced test-case, go to <a
+ href="http://llvm.org/bugs/enter_bug.cgi">the LLVM Bug Tracking
+ System</a> and fill out the form with the necessary details (note that you don't
+ need to pick a catagory, just use the "new-bugs" catagory if you're not sure).
+ The bug description should contain the following
+ information:</p>
+
+ <ul>
+ <li>All information necessary to reproduce the problem.</li>
+ <li>The reduced test-case that triggers the bug.</li>
+ <li>The location where you obtained LLVM (if not from our Subversion
+ repository).</li>
+ </ul>
+
+ <p>Thanks for helping us make LLVM better!</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="crashers">Crashing Bugs</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>More often than not, bugs in the compiler cause it to crash—often due
+ to an assertion failure of some sort. The most important
+ piece of the puzzle is to figure out if it is crashing in the GCC front-end
+ or if it is one of the LLVM libraries (e.g. the optimizer or code generator)
+ that has problems.</p>
+
+ <p>To figure out which component is crashing (the front-end,
+ optimizer or code generator), run the
+ <tt><b>llvm-gcc</b></tt> command line as you were when the crash occurred, but
+ with the following extra command line options:</p>
+
+ <ul>
+ <li><tt><b>-O0 -emit-llvm</b></tt>: If <tt>llvm-gcc</tt> still crashes when
+ passed these options (which disable the optimizer and code generator), then
+ the crash is in the front-end. Jump ahead to the section on <a
+ href="#front-end">front-end bugs</a>.</li>
+
+ <li><tt><b>-emit-llvm</b></tt>: If <tt>llvm-gcc</tt> crashes with this option
+ (which disables the code generator), you found an optimizer bug. Jump ahead
+ to <a href="#ct_optimizer"> compile-time optimization bugs</a>.</li>
+
+ <li>Otherwise, you have a code generator crash. Jump ahead to <a
+ href="#ct_codegen">code generator bugs</a>.</li>
+
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="front-end">Front-end bugs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If the problem is in the front-end, you should re-run the same
+ <tt>llvm-gcc</tt> command that resulted in the crash, but add the
+ <tt>-save-temps</tt> option. The compiler will crash again, but it will leave
+ behind a <tt><i>foo</i>.i</tt> file (containing preprocessed C source code) and
+ possibly <tt><i>foo</i>.s</tt> for each
+ compiled <tt><i>foo</i>.c</tt> file. Send us the <tt><i>foo</i>.i</tt> file,
+ along with the options you passed to llvm-gcc, and a brief description of the
+ error it caused.</p>
+
+ <p>The <a href="http://delta.tigris.org/">delta</a> tool helps to reduce the
+ preprocessed file down to the smallest amount of code that still replicates the
+ problem. You're encouraged to use delta to reduce the code to make the
+ developers' lives easier. <a
+ href="http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction">This website</a>
+ has instructions on the best way to use delta.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ct_optimizer">Compile-time optimization bugs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If you find that a bug crashes in the optimizer, compile your test-case to a
+ <tt>.bc</tt> file by passing "<tt><b>-emit-llvm -O0 -c -o foo.bc</b></tt>".
+ Then run:</p>
+
+ <div class="doc_code">
+ <p><tt><b>opt</b> -std-compile-opts -debug-pass=Arguments foo.bc
+ -disable-output</tt></p>
+ </div>
+
+ <p>This command should do two things: it should print out a list of passes, and
+ then it should crash in the same was as llvm-gcc. If it doesn't crash, please
+ follow the instructions for a <a href="#front-end">front-end bug</a>.</p>
+
+ <p>If this does crash, then you should be able to debug this with the following
+ bugpoint command:</p>
+
+ <div class="doc_code">
+ <p><tt><b>bugpoint</b> foo.bc <list of passes printed by
+ <b>opt</b>></tt></p>
+ </div>
+
+ <p>Please run this, then file a bug with the instructions and reduced .bc files
+ that bugpoint emits. If something goes wrong with bugpoint, please submit the
+ "foo.bc" file and the list of passes printed by <b>opt</b>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ct_codegen">Code generator bugs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If you find a bug that crashes llvm-gcc in the code generator, compile your
+ source file to a .bc file by passing "<tt><b>-emit-llvm -c -o foo.bc</b></tt>"
+ to llvm-gcc (in addition to the options you already pass). Once your have
+ foo.bc, one of the following commands should fail:</p>
+
+ <ol>
+ <li><tt><b>llc</b> foo.bc -f</tt></li>
+ <li><tt><b>llc</b> foo.bc -f -relocation-model=pic</tt></li>
+ <li><tt><b>llc</b> foo.bc -f -relocation-model=static</tt></li>
+ <li><tt><b>llc</b> foo.bc -f -enable-eh</tt></li>
+ <li><tt><b>llc</b> foo.bc -f -relocation-model=pic -enable-eh</tt></li>
+ <li><tt><b>llc</b> foo.bc -f -relocation-model=static -enable-eh</tt></li>
+ </ol>
+
+ <p>If none of these crash, please follow the instructions for a
+ <a href="#front-end">front-end bug</a>. If one of these do crash, you should
+ be able to reduce this with one of the following bugpoint command lines (use
+ the one corresponding to the command above that failed):</p>
+
+ <ol>
+ <li><tt><b>bugpoint</b> -run-llc foo.bc</tt></li>
+ <li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
+ -relocation-model=pic</tt></li>
+ <li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
+ -relocation-model=static</tt></li>
+ <li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args -enable-eh</tt></li>
+ <li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
+ -relocation-model=pic -enable-eh</tt></li>
+ <li><tt><b>bugpoint</b> -run-llc foo.bc --tool-args
+ -relocation-model=static -enable-eh</tt></li>
+ </ol>
+
+ <p>Please run this, then file a bug with the instructions and reduced .bc file
+ that bugpoint emits. If something goes wrong with bugpoint, please submit the
+ "foo.bc" file and the option that llc crashes with.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="miscompilations">Miscompilations</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>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
+ compiler. The first thing to check is to make sure it is not using undefined
+ behavior (e.g. reading a variable before it is defined). In particular, check
+ to see if the program <a href="http://valgrind.org/">valgrind</a>s clean,
+ passes purify, or some other memory checker tool. Many of the "LLVM bugs" that
+ we have chased down ended up being bugs in the program being compiled, not
+ LLVM.</p>
+
+ <p>Once you determine that the program itself is not buggy, you should choose
+ which code generator you wish to compile the program with (e.g. C backend, the
+ JIT, or LLC) and optionally a series of LLVM passes to run. For example:</p>
+
+ <div class="doc_code">
+ <p><tt>
+ <b>bugpoint</b> -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]</tt></p>
+ </div>
+
+ <p><tt>bugpoint</tt> will try to narrow down your list of passes to the one pass
+ that causes an error, and simplify the bitcode file as much as it can to assist
+ you. It will print a message letting you know how to reproduce the resulting
+ error.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="codegen">Incorrect code generation</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Similarly to debugging incorrect compilation by mis-behaving passes, you can
+ debug incorrect code generation by either LLC or the JIT, using
+ <tt>bugpoint</tt>. The process <tt>bugpoint</tt> follows in this case is to try
+ to narrow the code down to a function that is miscompiled by one or the other
+ method, but since for correctness, the entire program must be run,
+ <tt>bugpoint</tt> will compile the code it deems to not be affected with the C
+ Backend, and then link in the shared object it generates.</p>
+
+ <p>To debug the JIT:</p>
+
+ <div class="doc_code">
+ <pre>
+ bugpoint -run-jit -output=[correct output file] [bitcode file] \
+ --tool-args -- [arguments to pass to lli] \
+ --args -- [program arguments]
+ </pre>
+ </div>
+
+ <p>Similarly, to debug the LLC, one would run:</p>
+
+ <div class="doc_code">
+ <pre>
+ bugpoint -run-llc -output=[correct output file] [bitcode file] \
+ --tool-args -- [arguments to pass to llc] \
+ --args -- [program arguments]
+ </pre>
+ </div>
+
+ <p><b>Special note:</b> if you are debugging MultiSource or SPEC tests that
+ already exist in the <tt>llvm/test</tt> hierarchy, there is an easier way to
+ debug the JIT, LLC, and CBE, using the pre-written Makefile targets, which
+ will pass the program options specified in the Makefiles:</p>
+
+ <div class="doc_code">
+ <p><tt>
+ cd llvm/test/../../program<br>
+ make bugpoint-jit
+ </tt></p>
+ </div>
+
+ <p>At the end of a successful <tt>bugpoint</tt> run, you will be presented
+ with two bitcode files: a <em>safe</em> file which can be compiled with the C
+ backend and the <em>test</em> file which either LLC or the JIT
+ mis-codegenerates, and thus causes the error.</p>
+
+ <p>To reproduce the error that <tt>bugpoint</tt> found, it is sufficient to do
+ the following:</p>
+
+ <ol>
+
+ <li><p>Regenerate the shared object from the safe bitcode file:</p>
+
+ <div class="doc_code">
+ <p><tt>
+ <b>llc</b> -march=c safe.bc -o safe.c<br>
+ <b>gcc</b> -shared safe.c -o safe.so
+ </tt></p>
+ </div></li>
+
+ <li><p>If debugging LLC, compile test bitcode native and link with the shared
+ object:</p>
+
+ <div class="doc_code">
+ <p><tt>
+ <b>llc</b> test.bc -o test.s -f<br>
+ <b>gcc</b> test.s safe.so -o test.llc<br>
+ ./test.llc [program options]
+ </tt></p>
+ </div></li>
+
+ <li><p>If debugging the JIT, load the shared object and supply the test
+ bitcode:</p>
+
+ <div class="doc_code">
+ <p><tt><b>lli</b> -load=safe.so test.bc [program options]</tt></p>
+ </div></li>
+
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/LangRef.html
diff -c /dev/null llvm-www/releases/2.5/docs/LangRef.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/LangRef.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,6551 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM Assembly Language Reference Manual</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <meta name="author" content="Chris Lattner">
+ <meta name="description"
+ content="LLVM Assembly Language Reference Manual.">
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <body>
+
+ <div class="doc_title"> LLVM Language Reference Manual </div>
+ <ol>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#identifiers">Identifiers</a></li>
+ <li><a href="#highlevel">High Level Structure</a>
+ <ol>
+ <li><a href="#modulestructure">Module Structure</a></li>
+ <li><a href="#linkage">Linkage Types</a></li>
+ <li><a href="#callingconv">Calling Conventions</a></li>
+ <li><a href="#namedtypes">Named Types</a></li>
+ <li><a href="#globalvars">Global Variables</a></li>
+ <li><a href="#functionstructure">Functions</a></li>
+ <li><a href="#aliasstructure">Aliases</a></li>
+ <li><a href="#paramattrs">Parameter Attributes</a></li>
+ <li><a href="#fnattrs">Function Attributes</a></li>
+ <li><a href="#gc">Garbage Collector Names</a></li>
+ <li><a href="#moduleasm">Module-Level Inline Assembly</a></li>
+ <li><a href="#datalayout">Data Layout</a></li>
+ </ol>
+ </li>
+ <li><a href="#typesystem">Type System</a>
+ <ol>
+ <li><a href="#t_classifications">Type Classifications</a></li>
+ <li><a href="#t_primitive">Primitive Types</a>
+ <ol>
+ <li><a href="#t_floating">Floating Point Types</a></li>
+ <li><a href="#t_void">Void Type</a></li>
+ <li><a href="#t_label">Label Type</a></li>
+ </ol>
+ </li>
+ <li><a href="#t_derived">Derived Types</a>
+ <ol>
+ <li><a href="#t_integer">Integer Type</a></li>
+ <li><a href="#t_array">Array Type</a></li>
+ <li><a href="#t_function">Function Type</a></li>
+ <li><a href="#t_pointer">Pointer Type</a></li>
+ <li><a href="#t_struct">Structure Type</a></li>
+ <li><a href="#t_pstruct">Packed Structure Type</a></li>
+ <li><a href="#t_vector">Vector Type</a></li>
+ <li><a href="#t_opaque">Opaque Type</a></li>
+ </ol>
+ </li>
+ <li><a href="#t_uprefs">Type Up-references</a></li>
+ </ol>
+ </li>
+ <li><a href="#constants">Constants</a>
+ <ol>
+ <li><a href="#simpleconstants">Simple Constants</a></li>
+ <li><a href="#aggregateconstants">Aggregate Constants</a></li>
+ <li><a href="#globalconstants">Global Variable and Function Addresses</a></li>
+ <li><a href="#undefvalues">Undefined Values</a></li>
+ <li><a href="#constantexprs">Constant Expressions</a></li>
+ </ol>
+ </li>
+ <li><a href="#othervalues">Other Values</a>
+ <ol>
+ <li><a href="#inlineasm">Inline Assembler Expressions</a></li>
+ </ol>
+ </li>
+ <li><a href="#instref">Instruction Reference</a>
+ <ol>
+ <li><a href="#terminators">Terminator Instructions</a>
+ <ol>
+ <li><a href="#i_ret">'<tt>ret</tt>' Instruction</a></li>
+ <li><a href="#i_br">'<tt>br</tt>' Instruction</a></li>
+ <li><a href="#i_switch">'<tt>switch</tt>' Instruction</a></li>
+ <li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a></li>
+ <li><a href="#i_unwind">'<tt>unwind</tt>' Instruction</a></li>
+ <li><a href="#i_unreachable">'<tt>unreachable</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#binaryops">Binary Operations</a>
+ <ol>
+ <li><a href="#i_add">'<tt>add</tt>' Instruction</a></li>
+ <li><a href="#i_sub">'<tt>sub</tt>' Instruction</a></li>
+ <li><a href="#i_mul">'<tt>mul</tt>' Instruction</a></li>
+ <li><a href="#i_udiv">'<tt>udiv</tt>' Instruction</a></li>
+ <li><a href="#i_sdiv">'<tt>sdiv</tt>' Instruction</a></li>
+ <li><a href="#i_fdiv">'<tt>fdiv</tt>' Instruction</a></li>
+ <li><a href="#i_urem">'<tt>urem</tt>' Instruction</a></li>
+ <li><a href="#i_srem">'<tt>srem</tt>' Instruction</a></li>
+ <li><a href="#i_frem">'<tt>frem</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#bitwiseops">Bitwise Binary Operations</a>
+ <ol>
+ <li><a href="#i_shl">'<tt>shl</tt>' Instruction</a></li>
+ <li><a href="#i_lshr">'<tt>lshr</tt>' Instruction</a></li>
+ <li><a href="#i_ashr">'<tt>ashr</tt>' Instruction</a></li>
+ <li><a href="#i_and">'<tt>and</tt>' Instruction</a></li>
+ <li><a href="#i_or">'<tt>or</tt>' Instruction</a></li>
+ <li><a href="#i_xor">'<tt>xor</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#vectorops">Vector Operations</a>
+ <ol>
+ <li><a href="#i_extractelement">'<tt>extractelement</tt>' Instruction</a></li>
+ <li><a href="#i_insertelement">'<tt>insertelement</tt>' Instruction</a></li>
+ <li><a href="#i_shufflevector">'<tt>shufflevector</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#aggregateops">Aggregate Operations</a>
+ <ol>
+ <li><a href="#i_extractvalue">'<tt>extractvalue</tt>' Instruction</a></li>
+ <li><a href="#i_insertvalue">'<tt>insertvalue</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#memoryops">Memory Access and Addressing Operations</a>
+ <ol>
+ <li><a href="#i_malloc">'<tt>malloc</tt>' Instruction</a></li>
+ <li><a href="#i_free">'<tt>free</tt>' Instruction</a></li>
+ <li><a href="#i_alloca">'<tt>alloca</tt>' Instruction</a></li>
+ <li><a href="#i_load">'<tt>load</tt>' Instruction</a></li>
+ <li><a href="#i_store">'<tt>store</tt>' Instruction</a></li>
+ <li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#convertops">Conversion Operations</a>
+ <ol>
+ <li><a href="#i_trunc">'<tt>trunc .. to</tt>' Instruction</a></li>
+ <li><a href="#i_zext">'<tt>zext .. to</tt>' Instruction</a></li>
+ <li><a href="#i_sext">'<tt>sext .. to</tt>' Instruction</a></li>
+ <li><a href="#i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a></li>
+ <li><a href="#i_fpext">'<tt>fpext .. to</tt>' Instruction</a></li>
+ <li><a href="#i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a></li>
+ <li><a href="#i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a></li>
+ <li><a href="#i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a></li>
+ <li><a href="#i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a></li>
+ <li><a href="#i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a></li>
+ <li><a href="#i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a></li>
+ <li><a href="#i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ <li><a href="#otherops">Other Operations</a>
+ <ol>
+ <li><a href="#i_icmp">'<tt>icmp</tt>' Instruction</a></li>
+ <li><a href="#i_fcmp">'<tt>fcmp</tt>' Instruction</a></li>
+ <li><a href="#i_phi">'<tt>phi</tt>' Instruction</a></li>
+ <li><a href="#i_select">'<tt>select</tt>' Instruction</a></li>
+ <li><a href="#i_call">'<tt>call</tt>' Instruction</a></li>
+ <li><a href="#i_va_arg">'<tt>va_arg</tt>' Instruction</a></li>
+ </ol>
+ </li>
+ </ol>
+ </li>
+ <li><a href="#intrinsics">Intrinsic Functions</a>
+ <ol>
+ <li><a href="#int_varargs">Variable Argument Handling Intrinsics</a>
+ <ol>
+ <li><a href="#int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a></li>
+ <li><a href="#int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a></li>
+ <li><a href="#int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ <li><a href="#int_gc">Accurate Garbage Collection Intrinsics</a>
+ <ol>
+ <li><a href="#int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a></li>
+ <li><a href="#int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a></li>
+ <li><a href="#int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ <li><a href="#int_codegen">Code Generator Intrinsics</a>
+ <ol>
+ <li><a href="#int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li>
+ <li><a href="#int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li>
+ <li><a href="#int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a></li>
+ <li><a href="#int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a></li>
+ <li><a href="#int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a></li>
+ <li><a href="#int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a></li>
+ <li><a href="#int_readcyclecounter"><tt>llvm.readcyclecounter</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ <li><a href="#int_libc">Standard C Library Intrinsics</a>
+ <ol>
+ <li><a href="#int_memcpy">'<tt>llvm.memcpy.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_memmove">'<tt>llvm.memmove.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_memset">'<tt>llvm.memset.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ <li><a href="#int_manip">Bit Manipulation Intrinsics</a>
+ <ol>
+ <li><a href="#int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a></li>
+ <li><a href="#int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic </a></li>
+ <li><a href="#int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic </a></li>
+ <li><a href="#int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic </a></li>
+ <li><a href="#int_part_select">'<tt>llvm.part.select.*</tt>' Intrinsic </a></li>
+ <li><a href="#int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic </a></li>
+ </ol>
+ </li>
+ <li><a href="#int_debugger">Debugger intrinsics</a></li>
+ <li><a href="#int_eh">Exception Handling intrinsics</a></li>
+ <li><a href="#int_trampoline">Trampoline Intrinsic</a>
+ <ol>
+ <li><a href="#int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ <li><a href="#int_atomics">Atomic intrinsics</a>
+ <ol>
+ <li><a href="#int_memory_barrier"><tt>llvm.memory_barrier</tt></a></li>
+ <li><a href="#int_atomic_cmp_swap"><tt>llvm.atomic.cmp.swap</tt></a></li>
+ <li><a href="#int_atomic_swap"><tt>llvm.atomic.swap</tt></a></li>
+ <li><a href="#int_atomic_load_add"><tt>llvm.atomic.load.add</tt></a></li>
+ <li><a href="#int_atomic_load_sub"><tt>llvm.atomic.load.sub</tt></a></li>
+ <li><a href="#int_atomic_load_and"><tt>llvm.atomic.load.and</tt></a></li>
+ <li><a href="#int_atomic_load_nand"><tt>llvm.atomic.load.nand</tt></a></li>
+ <li><a href="#int_atomic_load_or"><tt>llvm.atomic.load.or</tt></a></li>
+ <li><a href="#int_atomic_load_xor"><tt>llvm.atomic.load.xor</tt></a></li>
+ <li><a href="#int_atomic_load_max"><tt>llvm.atomic.load.max</tt></a></li>
+ <li><a href="#int_atomic_load_min"><tt>llvm.atomic.load.min</tt></a></li>
+ <li><a href="#int_atomic_load_umax"><tt>llvm.atomic.load.umax</tt></a></li>
+ <li><a href="#int_atomic_load_umin"><tt>llvm.atomic.load.umin</tt></a></li>
+ </ol>
+ </li>
+ <li><a href="#int_general">General intrinsics</a>
+ <ol>
+ <li><a href="#int_var_annotation">
+ '<tt>llvm.var.annotation</tt>' Intrinsic</a></li>
+ <li><a href="#int_annotation">
+ '<tt>llvm.annotation.*</tt>' Intrinsic</a></li>
+ <li><a href="#int_trap">
+ '<tt>llvm.trap</tt>' Intrinsic</a></li>
+ <li><a href="#int_stackprotector">
+ '<tt>llvm.stackprotector</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ </ol>
+ </li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>
+ and <a href="mailto:vadve at cs.uiuc.edu">Vikram Adve</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="abstract">Abstract </a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>This document is a reference manual for the LLVM assembly language.
+ LLVM is a Static Single Assignment (SSA) based representation that provides
+ type safety, low-level operations, flexibility, and the capability of
+ representing 'all' high-level languages cleanly. It is the common code
+ representation used throughout all phases of the LLVM compilation
+ strategy.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="introduction">Introduction</a> </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM code representation is designed to be used in three
+ different forms: as an in-memory compiler IR, as an on-disk bitcode
+ representation (suitable for fast loading by a Just-In-Time compiler),
+ and as a human readable assembly language representation. This allows
+ LLVM to provide a powerful intermediate representation for efficient
+ compiler transformations and analysis, while providing a natural means
+ to debug and visualize the transformations. The three different forms
+ of LLVM are all equivalent. This document describes the human readable
+ representation and notation.</p>
+
+ <p>The LLVM representation aims to be light-weight and low-level
+ while being expressive, typed, and extensible at the same time. It
+ aims to be a "universal IR" of sorts, by being at a low enough level
+ that high-level ideas may be cleanly mapped to it (similar to how
+ microprocessors are "universal IR's", allowing many source languages to
+ be mapped to them). By providing type information, LLVM can be used as
+ the target of optimizations: for example, through pointer analysis, it
+ can be proven that a C automatic variable is never accessed outside of
+ the current function... allowing it to be promoted to a simple SSA
+ value instead of a memory location.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="wellformed">Well-Formedness</a> </div>
+
+ <div class="doc_text">
+
+ <p>It is important to note that this document describes 'well formed'
+ LLVM assembly language. There is a difference between what the parser
+ accepts and what is considered 'well formed'. For example, the
+ following instruction is syntactically okay, but not well formed:</p>
+
+ <div class="doc_code">
+ <pre>
+ %x = <a href="#i_add">add</a> i32 1, %x
+ </pre>
+ </div>
+
+ <p>...because the definition of <tt>%x</tt> does not dominate all of
+ its uses. The LLVM infrastructure provides a verification pass that may
+ be used to verify that an LLVM module is well formed. This pass is
+ automatically run by the parser after parsing input assembly and by
+ the optimizer before it outputs bitcode. The violations pointed out
+ by the verifier pass indicate bugs in transformation passes or input to
+ the parser.</p>
+ </div>
+
+ <!-- Describe the typesetting conventions here. -->
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="identifiers">Identifiers</a> </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM identifiers come in two basic types: global and local. Global
+ identifiers (functions, global variables) begin with the @ character. Local
+ identifiers (register names, types) begin with the % character. Additionally,
+ there are three different formats for identifiers, for different purposes:</p>
+
+ <ol>
+ <li>Named values are represented as a string of characters with their prefix.
+ For example, %foo, @DivisionByZero, %a.really.long.identifier. The actual
+ regular expression used is '<tt>[%@][a-zA-Z$._][a-zA-Z$._0-9]*</tt>'.
+ Identifiers which require other characters in their names can be surrounded
+ with quotes. Special characters may be escaped using "\xx" where xx is the
+ ASCII code for the character in hexadecimal. In this way, any character can
+ be used in a name value, even quotes themselves.
+
+ <li>Unnamed values are represented as an unsigned numeric value with their
+ prefix. For example, %12, @2, %44.</li>
+
+ <li>Constants, which are described in a <a href="#constants">section about
+ constants</a>, below.</li>
+ </ol>
+
+ <p>LLVM requires that values start with a prefix for two reasons: Compilers
+ don't need to worry about name clashes with reserved words, and the set of
+ reserved words may be expanded in the future without penalty. Additionally,
+ unnamed identifiers allow a compiler to quickly come up with a temporary
+ variable without having to avoid symbol table conflicts.</p>
+
+ <p>Reserved words in LLVM are very similar to reserved words in other
+ languages. There are keywords for different opcodes
+ ('<tt><a href="#i_add">add</a></tt>',
+ '<tt><a href="#i_bitcast">bitcast</a></tt>',
+ '<tt><a href="#i_ret">ret</a></tt>', etc...), for primitive type names ('<tt><a
+ href="#t_void">void</a></tt>', '<tt><a href="#t_primitive">i32</a></tt>', etc...),
+ and others. These reserved words cannot conflict with variable names, because
+ none of them start with a prefix character ('%' or '@').</p>
+
+ <p>Here is an example of LLVM code to multiply the integer variable
+ '<tt>%X</tt>' by 8:</p>
+
+ <p>The easy way:</p>
+
+ <div class="doc_code">
+ <pre>
+ %result = <a href="#i_mul">mul</a> i32 %X, 8
+ </pre>
+ </div>
+
+ <p>After strength reduction:</p>
+
+ <div class="doc_code">
+ <pre>
+ %result = <a href="#i_shl">shl</a> i32 %X, i8 3
+ </pre>
+ </div>
+
+ <p>And the hard way:</p>
+
+ <div class="doc_code">
+ <pre>
+ <a href="#i_add">add</a> i32 %X, %X <i>; yields {i32}:%0</i>
+ <a href="#i_add">add</a> i32 %0, %0 <i>; yields {i32}:%1</i>
+ %result = <a href="#i_add">add</a> i32 %1, %1
+ </pre>
+ </div>
+
+ <p>This last way of multiplying <tt>%X</tt> by 8 illustrates several
+ important lexical features of LLVM:</p>
+
+ <ol>
+
+ <li>Comments are delimited with a '<tt>;</tt>' and go until the end of
+ line.</li>
+
+ <li>Unnamed temporaries are created when the result of a computation is not
+ assigned to a named value.</li>
+
+ <li>Unnamed temporaries are numbered sequentially</li>
+
+ </ol>
+
+ <p>...and it also shows a convention that we follow in this document. When
+ demonstrating instructions, we will follow an instruction with a comment that
+ defines the type and name of value produced. Comments are shown in italic
+ text.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="highlevel">High Level Structure</a> </div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="modulestructure">Module Structure</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM programs are composed of "Module"s, each of which is a
+ translation unit of the input programs. Each module consists of
+ functions, global variables, and symbol table entries. Modules may be
+ combined together with the LLVM linker, which merges function (and
+ global variable) definitions, resolves forward declarations, and merges
+ symbol table entries. Here is an example of the "hello world" module:</p>
+
+ <div class="doc_code">
+ <pre><i>; Declare the string constant as a global constant...</i>
+ <a href="#identifiers">@.LC0</a> = <a href="#linkage_internal">internal</a> <a
+ href="#globalvars">constant</a> <a href="#t_array">[13 x i8]</a> c"hello world\0A\00" <i>; [13 x i8]*</i>
+
+ <i>; External declaration of the puts function</i>
+ <a href="#functionstructure">declare</a> i32 @puts(i8 *) <i>; i32(i8 *)* </i>
+
+ <i>; Definition of main function</i>
+ define i32 @main() { <i>; i32()* </i>
+ <i>; Convert [13 x i8]* to i8 *...</i>
+ %cast210 = <a
+ href="#i_getelementptr">getelementptr</a> [13 x i8]* @.LC0, i64 0, i64 0 <i>; i8 *</i>
+
+ <i>; Call puts function to write out the string to stdout...</i>
+ <a
+ href="#i_call">call</a> i32 @puts(i8 * %cast210) <i>; i32</i>
+ <a
+ href="#i_ret">ret</a> i32 0<br>}<br>
+ </pre>
+ </div>
+
+ <p>This example is made up of a <a href="#globalvars">global variable</a>
+ named "<tt>.LC0</tt>", an external declaration of the "<tt>puts</tt>"
+ function, and a <a href="#functionstructure">function definition</a>
+ for "<tt>main</tt>".</p>
+
+ <p>In general, a module is made up of a list of global values,
+ where both functions and global variables are global values. Global values are
+ represented by a pointer to a memory location (in this case, a pointer to an
+ array of char, and a pointer to a function), and have one of the following <a
+ href="#linkage">linkage types</a>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="linkage">Linkage Types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ All Global Variables and Functions have one of the following types of linkage:
+ </p>
+
+ <dl>
+
+ <dt><tt><b><a name="linkage_private">private</a></b></tt>: </dt>
+
+ <dd>Global values with private linkage are only directly accessible by
+ objects in the current module. In particular, linking code into a module with
+ an private global value may cause the private to be renamed as necessary to
+ avoid collisions. Because the symbol is private to the module, all
+ references can be updated. This doesn't show up in any symbol table in the
+ object file.
+ </dd>
+
+ <dt><tt><b><a name="linkage_internal">internal</a></b></tt>: </dt>
+
+ <dd> Similar to private, but the value shows as a local symbol (STB_LOCAL in
+ the case of ELF) in the object file. This corresponds to the notion of the
+ '<tt>static</tt>' keyword in C.
+ </dd>
+
+ <dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt>: </dt>
+
+ <dd>Globals with "<tt>linkonce</tt>" linkage are merged with other globals of
+ the same name when linkage occurs. This is typically used to implement
+ inline functions, templates, or other code which must be generated in each
+ translation unit that uses it. Unreferenced <tt>linkonce</tt> globals are
+ allowed to be discarded.
+ </dd>
+
+ <dt><tt><b><a name="linkage_common">common</a></b></tt>: </dt>
+
+ <dd>"<tt>common</tt>" linkage is exactly the same as <tt>linkonce</tt>
+ linkage, except that unreferenced <tt>common</tt> globals may not be
+ discarded. This is used for globals that may be emitted in multiple
+ translation units, but that are not guaranteed to be emitted into every
+ translation unit that uses them. One example of this is tentative
+ definitions in C, such as "<tt>int X;</tt>" at global scope.
+ </dd>
+
+ <dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt>
+
+ <dd>"<tt>weak</tt>" linkage is the same as <tt>common</tt> linkage, except
+ that some targets may choose to emit different assembly sequences for them
+ for target-dependent reasons. This is used for globals that are declared
+ "weak" in C source code.
+ </dd>
+
+ <dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt>
+
+ <dd>"<tt>appending</tt>" linkage may only be applied to global variables of
+ pointer to array type. When two global variables with appending linkage are
+ linked together, the two global arrays are appended together. This is the
+ LLVM, typesafe, equivalent of having the system linker append together
+ "sections" with identical names when .o files are linked.
+ </dd>
+
+ <dt><tt><b><a name="linkage_externweak">extern_weak</a></b></tt>: </dt>
+ <dd>The semantics of this linkage follow the ELF object file model: the
+ symbol is weak until linked, if not linked, the symbol becomes null instead
+ of being an undefined reference.
+ </dd>
+
+ <dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
+
+ <dd>If none of the above identifiers are used, the global is externally
+ visible, meaning that it participates in linkage and can be used to resolve
+ external symbol references.
+ </dd>
+ </dl>
+
+ <p>
+ The next two types of linkage are targeted for Microsoft Windows platform
+ only. They are designed to support importing (exporting) symbols from (to)
+ DLLs (Dynamic Link Libraries).
+ </p>
+
+ <dl>
+ <dt><tt><b><a name="linkage_dllimport">dllimport</a></b></tt>: </dt>
+
+ <dd>"<tt>dllimport</tt>" linkage causes the compiler to reference a function
+ or variable via a global pointer to a pointer that is set up by the DLL
+ exporting the symbol. On Microsoft Windows targets, the pointer name is
+ formed by combining <code>__imp_</code> and the function or variable name.
+ </dd>
+
+ <dt><tt><b><a name="linkage_dllexport">dllexport</a></b></tt>: </dt>
+
+ <dd>"<tt>dllexport</tt>" linkage causes the compiler to provide a global
+ pointer to a pointer in a DLL, so that it can be referenced with the
+ <tt>dllimport</tt> attribute. On Microsoft Windows targets, the pointer
+ name is formed by combining <code>__imp_</code> and the function or variable
+ name.
+ </dd>
+
+ </dl>
+
+ <p>For example, since the "<tt>.LC0</tt>"
+ variable is defined to be internal, if another module defined a "<tt>.LC0</tt>"
+ variable and was linked with this one, one of the two would be renamed,
+ preventing a collision. Since "<tt>main</tt>" and "<tt>puts</tt>" are
+ external (i.e., lacking any linkage declarations), they are accessible
+ outside of the current module.</p>
+ <p>It is illegal for a function <i>declaration</i>
+ to have any linkage type other than "externally visible", <tt>dllimport</tt>,
+ or <tt>extern_weak</tt>.</p>
+ <p>Aliases can have only <tt>external</tt>, <tt>internal</tt> and <tt>weak</tt>
+ linkages.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="callingconv">Calling Conventions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM <a href="#functionstructure">functions</a>, <a href="#i_call">calls</a>
+ and <a href="#i_invoke">invokes</a> can all have an optional calling convention
+ specified for the call. The calling convention of any pair of dynamic
+ caller/callee must match, or the behavior of the program is undefined. The
+ following calling conventions are supported by LLVM, and more may be added in
+ the future:</p>
+
+ <dl>
+ <dt><b>"<tt>ccc</tt>" - The C calling convention</b>:</dt>
+
+ <dd>This calling convention (the default if no other calling convention is
+ specified) matches the target C calling conventions. This calling convention
+ supports varargs function calls and tolerates some mismatch in the declared
+ prototype and implemented declaration of the function (as does normal C).
+ </dd>
+
+ <dt><b>"<tt>fastcc</tt>" - The fast calling convention</b>:</dt>
+
+ <dd>This calling convention attempts to make calls as fast as possible
+ (e.g. by passing things in registers). This calling convention allows the
+ target to use whatever tricks it wants to produce fast code for the target,
+ without having to conform to an externally specified ABI (Application Binary
+ Interface). Implementations of this convention should allow arbitrary
+ <a href="CodeGenerator.html#tailcallopt">tail call optimization</a> to be
+ supported. This calling convention does not support varargs and requires the
+ prototype of all callees to exactly match the prototype of the function
+ definition.
+ </dd>
+
+ <dt><b>"<tt>coldcc</tt>" - The cold calling convention</b>:</dt>
+
+ <dd>This calling convention attempts to make code in the caller as efficient
+ as possible under the assumption that the call is not commonly executed. As
+ such, these calls often preserve all registers so that the call does not break
+ any live ranges in the caller side. This calling convention does not support
+ varargs and requires the prototype of all callees to exactly match the
+ prototype of the function definition.
+ </dd>
+
+ <dt><b>"<tt>cc <<em>n</em>></tt>" - Numbered convention</b>:</dt>
+
+ <dd>Any calling convention may be specified by number, allowing
+ target-specific calling conventions to be used. Target specific calling
+ conventions start at 64.
+ </dd>
+ </dl>
+
+ <p>More calling conventions can be added/defined on an as-needed basis, to
+ support pascal conventions or any other well-known target-independent
+ convention.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="visibility">Visibility Styles</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ All Global Variables and Functions have one of the following visibility styles:
+ </p>
+
+ <dl>
+ <dt><b>"<tt>default</tt>" - Default style</b>:</dt>
+
+ <dd>On targets that use the ELF object file format, default visibility means
+ that the declaration is visible to other
+ modules and, in shared libraries, means that the declared entity may be
+ overridden. On Darwin, default visibility means that the declaration is
+ visible to other modules. Default visibility corresponds to "external
+ linkage" in the language.
+ </dd>
+
+ <dt><b>"<tt>hidden</tt>" - Hidden style</b>:</dt>
+
+ <dd>Two declarations of an object with hidden visibility refer to the same
+ object if they are in the same shared object. Usually, hidden visibility
+ indicates that the symbol will not be placed into the dynamic symbol table,
+ so no other module (executable or shared library) can reference it
+ directly.
+ </dd>
+
+ <dt><b>"<tt>protected</tt>" - Protected style</b>:</dt>
+
+ <dd>On ELF, protected visibility indicates that the symbol will be placed in
+ the dynamic symbol table, but that references within the defining module will
+ bind to the local symbol. That is, the symbol cannot be overridden by another
+ module.
+ </dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="namedtypes">Named Types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM IR allows you to specify name aliases for certain types. This can make
+ it easier to read the IR and make the IR more condensed (particularly when
+ recursive types are involved). An example of a name specification is:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ %mytype = type { %mytype*, i32 }
+ </pre>
+ </div>
+
+ <p>You may give a name to any <a href="#typesystem">type</a> except "<a
+ href="t_void">void</a>". Type name aliases may be used anywhere a type is
+ expected with the syntax "%mytype".</p>
+
+ <p>Note that type names are aliases for the structural type that they indicate,
+ and that you can therefore specify multiple names for the same type. This often
+ leads to confusing behavior when dumping out a .ll file. Since LLVM IR uses
+ structural typing, the name is not part of the type. When printing out LLVM IR,
+ the printer will pick <em>one name</em> to render all types of a particular
+ shape. This means that if you have code where two different source types end up
+ having the same LLVM type, that the dumper will sometimes print the "wrong" or
+ unexpected type. This is an important design point and isn't going to
+ change.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="globalvars">Global Variables</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Global variables define regions of memory allocated at compilation time
+ instead of run-time. Global variables may optionally be initialized, may have
+ an explicit section to be placed in, and may have an optional explicit alignment
+ specified. A variable may be defined as "thread_local", which means that it
+ will not be shared by threads (each thread will have a separated copy of the
+ variable). A variable may be defined as a global "constant," which indicates
+ that the contents of the variable will <b>never</b> be modified (enabling better
+ optimization, allowing the global data to be placed in the read-only section of
+ an executable, etc). Note that variables that need runtime initialization
+ cannot be marked "constant" as there is a store to the variable.</p>
+
+ <p>
+ LLVM explicitly allows <em>declarations</em> of global variables to be marked
+ constant, even if the final definition of the global is not. This capability
+ can be used to enable slightly better optimization of the program, but requires
+ the language definition to guarantee that optimizations based on the
+ 'constantness' are valid for the translation units that do not include the
+ definition.
+ </p>
+
+ <p>As SSA values, global variables define pointer values that are in
+ scope (i.e. they dominate) all basic blocks in the program. Global
+ variables always define a pointer to their "content" type because they
+ describe a region of memory, and all memory objects in LLVM are
+ accessed through pointers.</p>
+
+ <p>A global variable may be declared to reside in a target-specifc numbered
+ address space. For targets that support them, address spaces may affect how
+ optimizations are performed and/or what target instructions are used to access
+ the variable. The default address space is zero. The address space qualifier
+ must precede any other attributes.</p>
+
+ <p>LLVM allows an explicit section to be specified for globals. If the target
+ supports it, it will emit globals to the section specified.</p>
+
+ <p>An explicit alignment may be specified for a global. If not present, or if
+ the alignment is set to zero, the alignment of the global is set by the target
+ to whatever it feels convenient. If an explicit alignment is specified, the
+ global is forced to have at least that much alignment. All alignments must be
+ a power of 2.</p>
+
+ <p>For example, the following defines a global in a numbered address space with
+ an initializer, section, and alignment:</p>
+
+ <div class="doc_code">
+ <pre>
+ @G = addrspace(5) constant float 1.0, section "foo", align 4
+ </pre>
+ </div>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="functionstructure">Functions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM function definitions consist of the "<tt>define</tt>" keyord,
+ an optional <a href="#linkage">linkage type</a>, an optional
+ <a href="#visibility">visibility style</a>, an optional
+ <a href="#callingconv">calling convention</a>, a return type, an optional
+ <a href="#paramattrs">parameter attribute</a> for the return type, a function
+ name, a (possibly empty) argument list (each with optional
+ <a href="#paramattrs">parameter attributes</a>), optional
+ <a href="#fnattrs">function attributes</a>, an optional section,
+ an optional alignment, an optional <a href="#gc">garbage collector name</a>,
+ an opening curly brace, a list of basic blocks, and a closing curly brace.
+
+ LLVM function declarations consist of the "<tt>declare</tt>" keyword, an
+ optional <a href="#linkage">linkage type</a>, an optional
+ <a href="#visibility">visibility style</a>, an optional
+ <a href="#callingconv">calling convention</a>, a return type, an optional
+ <a href="#paramattrs">parameter attribute</a> for the return type, a function
+ name, a possibly empty list of arguments, an optional alignment, and an optional
+ <a href="#gc">garbage collector name</a>.</p>
+
+ <p>A function definition contains a list of basic blocks, forming the CFG
+ (Control Flow Graph) for
+ the function. Each basic block may optionally start with a label (giving the
+ basic block a symbol table entry), contains a list of instructions, and ends
+ with a <a href="#terminators">terminator</a> instruction (such as a branch or
+ function return).</p>
+
+ <p>The first basic block in a function is special in two ways: it is immediately
+ executed on entrance to the function, and it is not allowed to have predecessor
+ basic blocks (i.e. there can not be any branches to the entry block of a
+ function). Because the block can have no predecessors, it also cannot have any
+ <a href="#i_phi">PHI nodes</a>.</p>
+
+ <p>LLVM allows an explicit section to be specified for functions. If the target
+ supports it, it will emit functions to the section specified.</p>
+
+ <p>An explicit alignment may be specified for a function. If not present, or if
+ the alignment is set to zero, the alignment of the function is set by the target
+ to whatever it feels convenient. If an explicit alignment is specified, the
+ function is forced to have at least that much alignment. All alignments must be
+ a power of 2.</p>
+
+ <h5>Syntax:</h5>
+
+ <div class="doc_code">
+ <tt>
+ define [<a href="#linkage">linkage</a>] [<a href="#visibility">visibility</a>]
+ [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>]
+ <ResultType> @<FunctionName> ([argument list])
+ [<a href="#fnattrs">fn Attrs</a>] [section "name"] [align N]
+ [<a href="#gc">gc</a>] { ... }
+ </tt>
+ </div>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="aliasstructure">Aliases</a>
+ </div>
+ <div class="doc_text">
+ <p>Aliases act as "second name" for the aliasee value (which can be either
+ function, global variable, another alias or bitcast of global value). Aliases
+ may have an optional <a href="#linkage">linkage type</a>, and an
+ optional <a href="#visibility">visibility style</a>.</p>
+
+ <h5>Syntax:</h5>
+
+ <div class="doc_code">
+ <pre>
+ @<Name> = alias [Linkage] [Visibility] <AliaseeTy> @<Aliasee>
+ </pre>
+ </div>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="paramattrs">Parameter Attributes</a></div>
+ <div class="doc_text">
+ <p>The return type and each parameter of a function type may have a set of
+ <i>parameter attributes</i> associated with them. Parameter attributes are
+ used to communicate additional information about the result or parameters of
+ a function. Parameter attributes are considered to be part of the function,
+ not of the function type, so functions with different parameter attributes
+ can have the same function type.</p>
+
+ <p>Parameter attributes are simple keywords that follow the type specified. If
+ multiple parameter attributes are needed, they are space separated. For
+ example:</p>
+
+ <div class="doc_code">
+ <pre>
+ declare i32 @printf(i8* noalias , ...)
+ declare i32 @atoi(i8 zeroext)
+ declare signext i8 @returns_signed_char()
+ </pre>
+ </div>
+
+ <p>Note that any attributes for the function result (<tt>nounwind</tt>,
+ <tt>readonly</tt>) come immediately after the argument list.</p>
+
+ <p>Currently, only the following parameter attributes are defined:</p>
+ <dl>
+ <dt><tt>zeroext</tt></dt>
+ <dd>This indicates to the code generator that the parameter or return value
+ should be zero-extended to a 32-bit value by the caller (for a parameter)
+ or the callee (for a return value).</dd>
+
+ <dt><tt>signext</tt></dt>
+ <dd>This indicates to the code generator that the parameter or return value
+ should be sign-extended to a 32-bit value by the caller (for a parameter)
+ or the callee (for a return value).</dd>
+
+ <dt><tt>inreg</tt></dt>
+ <dd>This indicates that this parameter or return value should be treated
+ in a special target-dependent fashion during while emitting code for a
+ function call or return (usually, by putting it in a register as opposed
+ to memory, though some targets use it to distinguish between two different
+ kinds of registers). Use of this attribute is target-specific.</dd>
+
+ <dt><tt><a name="byval">byval</a></tt></dt>
+ <dd>This indicates that the pointer parameter should really be passed by
+ value to the function. The attribute implies that a hidden copy of the
+ pointee is made between the caller and the callee, so the callee is unable
+ to modify the value in the callee. This attribute is only valid on LLVM
+ pointer arguments. It is generally used to pass structs and arrays by
+ value, but is also valid on pointers to scalars. The copy is considered to
+ belong to the caller not the callee (for example,
+ <tt><a href="#readonly">readonly</a></tt> functions should not write to
+ <tt>byval</tt> parameters). This is not a valid attribute for return
+ values. </dd>
+
+ <dt><tt>sret</tt></dt>
+ <dd>This indicates that the pointer parameter specifies the address of a
+ structure that is the return value of the function in the source program.
+ This pointer must be guaranteed by the caller to be valid: loads and stores
+ to the structure may be assumed by the callee to not to trap. This may only
+ be applied to the first parameter. This is not a valid attribute for
+ return values. </dd>
+
+ <dt><tt>noalias</tt></dt>
+ <dd>This indicates that the pointer does not alias any global or any other
+ parameter. The caller is responsible for ensuring that this is the
+ case. On a function return value, <tt>noalias</tt> additionally indicates
+ that the pointer does not alias any other pointers visible to the
+ caller. For further details, please see the discussion of the NoAlias
+ response in
+ <a href="http://llvm.org/docs/AliasAnalysis.html#MustMayNo">alias
+ analysis</a>.</dd>
+
+ <dt><tt>nocapture</tt></dt>
+ <dd>This indicates that the callee does not make any copies of the pointer
+ that outlive the callee itself. This is not a valid attribute for return
+ values.</dd>
+
+ <dt><tt>nest</tt></dt>
+ <dd>This indicates that the pointer parameter can be excised using the
+ <a href="#int_trampoline">trampoline intrinsics</a>. This is not a valid
+ attribute for return values.</dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="gc">Garbage Collector Names</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Each function may specify a garbage collector name, which is simply a
+ string.</p>
+
+ <div class="doc_code"><pre
+ >define void @f() gc "name" { ...</pre></div>
+
+ <p>The compiler declares the supported values of <i>name</i>. Specifying a
+ collector which will cause the compiler to alter its output in order to support
+ the named garbage collection algorithm.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="fnattrs">Function Attributes</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Function attributes are set to communicate additional information about
+ a function. Function attributes are considered to be part of the function,
+ not of the function type, so functions with different parameter attributes
+ can have the same function type.</p>
+
+ <p>Function attributes are simple keywords that follow the type specified. If
+ multiple attributes are needed, they are space separated. For
+ example:</p>
+
+ <div class="doc_code">
+ <pre>
+ define void @f() noinline { ... }
+ define void @f() alwaysinline { ... }
+ define void @f() alwaysinline optsize { ... }
+ define void @f() optsize
+ </pre>
+ </div>
+
+ <dl>
+ <dt><tt>alwaysinline</tt></dt>
+ <dd>This attribute indicates that the inliner should attempt to inline this
+ function into callers whenever possible, ignoring any active inlining size
+ threshold for this caller.</dd>
+
+ <dt><tt>noinline</tt></dt>
+ <dd>This attribute indicates that the inliner should never inline this function
+ in any situation. This attribute may not be used together with the
+ <tt>alwaysinline</tt> attribute.</dd>
+
+ <dt><tt>optsize</tt></dt>
+ <dd>This attribute suggests that optimization passes and code generator passes
+ make choices that keep the code size of this function low, and otherwise do
+ optimizations specifically to reduce code size.</dd>
+
+ <dt><tt>noreturn</tt></dt>
+ <dd>This function attribute indicates that the function never returns normally.
+ This produces undefined behavior at runtime if the function ever does
+ dynamically return.</dd>
+
+ <dt><tt>nounwind</tt></dt>
+ <dd>This function attribute indicates that the function never returns with an
+ unwind or exceptional control flow. If the function does unwind, its runtime
+ behavior is undefined.</dd>
+
+ <dt><tt>readnone</tt></dt>
+ <dd>This attribute indicates that the function computes its result (or the
+ exception it throws) based strictly on its arguments, without dereferencing any
+ pointer arguments or otherwise accessing any mutable state (e.g. memory, control
+ registers, etc) visible to caller functions. It does not write through any
+ pointer arguments (including <tt><a href="#byval">byval</a></tt> arguments) and
+ never changes any state visible to callers.</dd>
+
+ <dt><tt><a name="readonly">readonly</a></tt></dt>
+ <dd>This attribute indicates that the function does not write through any
+ pointer arguments (including <tt><a href="#byval">byval</a></tt> arguments)
+ or otherwise modify any state (e.g. memory, control registers, etc) visible to
+ caller functions. It may dereference pointer arguments and read state that may
+ be set in the caller. A readonly function always returns the same value (or
+ throws the same exception) when called with the same set of arguments and global
+ state.</dd>
+
+ <dt><tt><a name="ssp">ssp</a></tt></dt>
+ <dd>This attribute indicates that the function should emit a stack smashing
+ protector. It is in the form of a "canary"—a random value placed on the
+ stack before the local variables that's checked upon return from the function to
+ see if it has been overwritten. A heuristic is used to determine if a function
+ needs stack protectors or not.
+
+ <p>If a function that has an <tt>ssp</tt> attribute is inlined into a function
+ that doesn't have an <tt>ssp</tt> attribute, then the resulting function will
+ have an <tt>ssp</tt> attribute.</p></dd>
+
+ <dt><tt>sspreq</tt></dt>
+ <dd>This attribute indicates that the function should <em>always</em> emit a
+ stack smashing protector. This overrides the <tt><a href="#ssp">ssp</a></tt>
+ function attribute.
+
+ <p>If a function that has an <tt>sspreq</tt> attribute is inlined into a
+ function that doesn't have an <tt>sspreq</tt> attribute or which has
+ an <tt>ssp</tt> attribute, then the resulting function will have
+ an <tt>sspreq</tt> attribute.</p></dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="moduleasm">Module-Level Inline Assembly</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Modules may contain "module-level inline asm" blocks, which corresponds to the
+ GCC "file scope inline asm" blocks. These blocks are internally concatenated by
+ LLVM and treated as a single unit, but may be separated in the .ll file if
+ desired. The syntax is very simple:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ module asm "inline asm code goes here"
+ module asm "more can go here"
+ </pre>
+ </div>
+
+ <p>The strings can contain any character by escaping non-printable characters.
+ The escape sequence used is simply "\xx" where "xx" is the two digit hex code
+ for the number.
+ </p>
+
+ <p>
+ The inline asm code is simply printed to the machine code .s file when
+ assembly code is generated.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="datalayout">Data Layout</a>
+ </div>
+
+ <div class="doc_text">
+ <p>A module may specify a target specific data layout string that specifies how
+ data is to be laid out in memory. The syntax for the data layout is simply:</p>
+ <pre> target datalayout = "<i>layout specification</i>"</pre>
+ <p>The <i>layout specification</i> consists of a list of specifications
+ separated by the minus sign character ('-'). Each specification starts with a
+ letter and may include other information after the letter to define some
+ aspect of the data layout. The specifications accepted are as follows: </p>
+ <dl>
+ <dt><tt>E</tt></dt>
+ <dd>Specifies that the target lays out data in big-endian form. That is, the
+ bits with the most significance have the lowest address location.</dd>
+ <dt><tt>e</tt></dt>
+ <dd>Specifies that the target lays out data in little-endian form. That is,
+ the bits with the least significance have the lowest address location.</dd>
+ <dt><tt>p:<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dd>This specifies the <i>size</i> of a pointer and its <i>abi</i> and
+ <i>preferred</i> alignments. All sizes are in bits. Specifying the <i>pref</i>
+ alignment is optional. If omitted, the preceding <tt>:</tt> should be omitted
+ too.</dd>
+ <dt><tt>i<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dd>This specifies the alignment for an integer type of a given bit
+ <i>size</i>. The value of <i>size</i> must be in the range [1,2^23).</dd>
+ <dt><tt>v<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dd>This specifies the alignment for a vector type of a given bit
+ <i>size</i>.</dd>
+ <dt><tt>f<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dd>This specifies the alignment for a floating point type of a given bit
+ <i>size</i>. The value of <i>size</i> must be either 32 (float) or 64
+ (double).</dd>
+ <dt><tt>a<i>size</i>:<i>abi</i>:<i>pref</i></tt></dt>
+ <dd>This specifies the alignment for an aggregate type of a given bit
+ <i>size</i>.</dd>
+ </dl>
+ <p>When constructing the data layout for a given target, LLVM starts with a
+ default set of specifications which are then (possibly) overriden by the
+ specifications in the <tt>datalayout</tt> keyword. The default specifications
+ are given in this list:</p>
+ <ul>
+ <li><tt>E</tt> - big endian</li>
+ <li><tt>p:32:64:64</tt> - 32-bit pointers with 64-bit alignment</li>
+ <li><tt>i1:8:8</tt> - i1 is 8-bit (byte) aligned</li>
+ <li><tt>i8:8:8</tt> - i8 is 8-bit (byte) aligned</li>
+ <li><tt>i16:16:16</tt> - i16 is 16-bit aligned</li>
+ <li><tt>i32:32:32</tt> - i32 is 32-bit aligned</li>
+ <li><tt>i64:32:64</tt> - i64 has ABI alignment of 32-bits but preferred
+ alignment of 64-bits</li>
+ <li><tt>f32:32:32</tt> - float is 32-bit aligned</li>
+ <li><tt>f64:64:64</tt> - double is 64-bit aligned</li>
+ <li><tt>v64:64:64</tt> - 64-bit vector is 64-bit aligned</li>
+ <li><tt>v128:128:128</tt> - 128-bit vector is 128-bit aligned</li>
+ <li><tt>a0:0:1</tt> - aggregates are 8-bit aligned</li>
+ </ul>
+ <p>When LLVM is determining the alignment for a given type, it uses the
+ following rules:</p>
+ <ol>
+ <li>If the type sought is an exact match for one of the specifications, that
+ specification is used.</li>
+ <li>If no match is found, and the type sought is an integer type, then the
+ smallest integer type that is larger than the bitwidth of the sought type is
+ used. If none of the specifications are larger than the bitwidth then the the
+ largest integer type is used. For example, given the default specifications
+ above, the i7 type will use the alignment of i8 (next largest) while both
+ i65 and i256 will use the alignment of i64 (largest specified).</li>
+ <li>If no match is found, and the type sought is a vector type, then the
+ largest vector type that is smaller than the sought vector type will be used
+ as a fall back. This happens because <128 x double> can be implemented
+ in terms of 64 <2 x double>, for example.</li>
+ </ol>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="typesystem">Type System</a> </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM type system is one of the most important features of the
+ intermediate representation. Being typed enables a number of
+ optimizations to be performed on the intermediate representation directly,
+ without having to do
+ extra analyses on the side before the transformation. A strong type
+ system makes it easier to read the generated code and enables novel
+ analyses and transformations that are not feasible to perform on normal
+ three address code representations.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="t_classifications">Type
+ Classifications</a> </div>
+ <div class="doc_text">
+ <p>The types fall into a few useful
+ classifications:</p>
+
+ <table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr><th>Classification</th><th>Types</th></tr>
+ <tr>
+ <td><a href="#t_integer">integer</a></td>
+ <td><tt>i1, i2, i3, ... i8, ... i16, ... i32, ... i64, ... </tt></td>
+ </tr>
+ <tr>
+ <td><a href="#t_floating">floating point</a></td>
+ <td><tt>float, double, x86_fp80, fp128, ppc_fp128</tt></td>
+ </tr>
+ <tr>
+ <td><a name="t_firstclass">first class</a></td>
+ <td><a href="#t_integer">integer</a>,
+ <a href="#t_floating">floating point</a>,
+ <a href="#t_pointer">pointer</a>,
+ <a href="#t_vector">vector</a>,
+ <a href="#t_struct">structure</a>,
+ <a href="#t_array">array</a>,
+ <a href="#t_label">label</a>.
+ </td>
+ </tr>
+ <tr>
+ <td><a href="#t_primitive">primitive</a></td>
+ <td><a href="#t_label">label</a>,
+ <a href="#t_void">void</a>,
+ <a href="#t_floating">floating point</a>.</td>
+ </tr>
+ <tr>
+ <td><a href="#t_derived">derived</a></td>
+ <td><a href="#t_integer">integer</a>,
+ <a href="#t_array">array</a>,
+ <a href="#t_function">function</a>,
+ <a href="#t_pointer">pointer</a>,
+ <a href="#t_struct">structure</a>,
+ <a href="#t_pstruct">packed structure</a>,
+ <a href="#t_vector">vector</a>,
+ <a href="#t_opaque">opaque</a>.
+ </td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>The <a href="#t_firstclass">first class</a> types are perhaps the
+ most important. Values of these types are the only ones which can be
+ produced by instructions, passed as arguments, or used as operands to
+ instructions.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="t_primitive">Primitive Types</a> </div>
+
+ <div class="doc_text">
+ <p>The primitive types are the fundamental building blocks of the LLVM
+ system.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_floating">Floating Point Types</a> </div>
+
+ <div class="doc_text">
+ <table>
+ <tbody>
+ <tr><th>Type</th><th>Description</th></tr>
+ <tr><td><tt>float</tt></td><td>32-bit floating point value</td></tr>
+ <tr><td><tt>double</tt></td><td>64-bit floating point value</td></tr>
+ <tr><td><tt>fp128</tt></td><td>128-bit floating point value (112-bit mantissa)</td></tr>
+ <tr><td><tt>x86_fp80</tt></td><td>80-bit floating point value (X87)</td></tr>
+ <tr><td><tt>ppc_fp128</tt></td><td>128-bit floating point value (two 64-bits)</td></tr>
+ </tbody>
+ </table>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_void">Void Type</a> </div>
+
+ <div class="doc_text">
+ <h5>Overview:</h5>
+ <p>The void type does not represent any value and has no size.</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ void
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_label">Label Type</a> </div>
+
+ <div class="doc_text">
+ <h5>Overview:</h5>
+ <p>The label type represents code labels.</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ label
+ </pre>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="t_derived">Derived Types</a> </div>
+
+ <div class="doc_text">
+
+ <p>The real power in LLVM comes from the derived types in the system.
+ This is what allows a programmer to represent arrays, functions,
+ pointers, and other useful types. Note that these derived types may be
+ recursive: For example, it is possible to have a two dimensional array.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_integer">Integer Type</a> </div>
+
+ <div class="doc_text">
+
+ <h5>Overview:</h5>
+ <p>The integer type is a very simple derived type that simply specifies an
+ arbitrary bit width for the integer type desired. Any bit width from 1 bit to
+ 2^23-1 (about 8 million) can be specified.</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ iN
+ </pre>
+
+ <p>The number of bits the integer will occupy is specified by the <tt>N</tt>
+ value.</p>
+
+ <h5>Examples:</h5>
+ <table class="layout">
+ <tbody>
+ <tr>
+ <td><tt>i1</tt></td>
+ <td>a single-bit integer.</td>
+ </tr><tr>
+ <td><tt>i32</tt></td>
+ <td>a 32-bit integer.</td>
+ </tr><tr>
+ <td><tt>i1942652</tt></td>
+ <td>a really big integer of over 1 million bits.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>Note that the code generator does not yet support large integer types
+ to be used as function return types. The specific limit on how large a
+ return type the code generator can currently handle is target-dependent;
+ currently it's often 64 bits for 32-bit targets and 128 bits for 64-bit
+ targets.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_array">Array Type</a> </div>
+
+ <div class="doc_text">
+
+ <h5>Overview:</h5>
+
+ <p>The array type is a very simple derived type that arranges elements
+ sequentially in memory. The array type requires a size (number of
+ elements) and an underlying data type.</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ [<# elements> x <elementtype>]
+ </pre>
+
+ <p>The number of elements is a constant integer value; elementtype may
+ be any type with a size.</p>
+
+ <h5>Examples:</h5>
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>[40 x i32]</tt></td>
+ <td class="left">Array of 40 32-bit integer values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>[41 x i32]</tt></td>
+ <td class="left">Array of 41 32-bit integer values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>[4 x i8]</tt></td>
+ <td class="left">Array of 4 8-bit integer values.</td>
+ </tr>
+ </table>
+ <p>Here are some examples of multidimensional arrays:</p>
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>[3 x [4 x i32]]</tt></td>
+ <td class="left">3x4 array of 32-bit integer values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>[12 x [10 x float]]</tt></td>
+ <td class="left">12x10 array of single precision floating point values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>[2 x [3 x [4 x i16]]]</tt></td>
+ <td class="left">2x3x4 array of 16-bit integer values.</td>
+ </tr>
+ </table>
+
+ <p>Note that 'variable sized arrays' can be implemented in LLVM with a zero
+ length array. Normally, accesses past the end of an array are undefined in
+ LLVM (e.g. it is illegal to access the 5th element of a 3 element array).
+ As a special case, however, zero length arrays are recognized to be variable
+ length. This allows implementation of 'pascal style arrays' with the LLVM
+ type "{ i32, [0 x float]}", for example.</p>
+
+ <p>Note that the code generator does not yet support large aggregate types
+ to be used as function return types. The specific limit on how large an
+ aggregate return type the code generator can currently handle is
+ target-dependent, and also dependent on the aggregate element types.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_function">Function Type</a> </div>
+ <div class="doc_text">
+
+ <h5>Overview:</h5>
+
+ <p>The function type can be thought of as a function signature. It
+ consists of a return type and a list of formal parameter types. The
+ return type of a function type is a scalar type, a void type, or a struct type.
+ If the return type is a struct type then all struct elements must be of first
+ class types, and the struct must have at least one element.</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <returntype list> (<parameter list>)
+ </pre>
+
+ <p>...where '<tt><parameter list></tt>' is a comma-separated list of type
+ specifiers. Optionally, the parameter list may include a type <tt>...</tt>,
+ which indicates that the function takes a variable number of arguments.
+ Variable argument functions can access their arguments with the <a
+ href="#int_varargs">variable argument handling intrinsic</a> functions.
+ '<tt><returntype list></tt>' is a comma-separated list of
+ <a href="#t_firstclass">first class</a> type specifiers.</p>
+
+ <h5>Examples:</h5>
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>i32 (i32)</tt></td>
+ <td class="left">function taking an <tt>i32</tt>, returning an <tt>i32</tt>
+ </td>
+ </tr><tr class="layout">
+ <td class="left"><tt>float (i16 signext, i32 *) *
+ </tt></td>
+ <td class="left"><a href="#t_pointer">Pointer</a> to a function that takes
+ an <tt>i16</tt> that should be sign extended and a
+ <a href="#t_pointer">pointer</a> to <tt>i32</tt>, returning
+ <tt>float</tt>.
+ </td>
+ </tr><tr class="layout">
+ <td class="left"><tt>i32 (i8*, ...)</tt></td>
+ <td class="left">A vararg function that takes at least one
+ <a href="#t_pointer">pointer</a> to <tt>i8 </tt> (char in C),
+ which returns an integer. This is the signature for <tt>printf</tt> in
+ LLVM.
+ </td>
+ </tr><tr class="layout">
+ <td class="left"><tt>{i32, i32} (i32)</tt></td>
+ <td class="left">A function taking an <tt>i32</tt>, returning two
+ <tt>i32</tt> values as an aggregate of type <tt>{ i32, i32 }</tt>
+ </td>
+ </tr>
+ </table>
+
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_struct">Structure Type</a> </div>
+ <div class="doc_text">
+ <h5>Overview:</h5>
+ <p>The structure type is used to represent a collection of data members
+ together in memory. The packing of the field types is defined to match
+ the ABI of the underlying processor. The elements of a structure may
+ be any type that has a size.</p>
+ <p>Structures are accessed using '<tt><a href="#i_load">load</a></tt>
+ and '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a
+ field with the '<tt><a href="#i_getelementptr">getelementptr</a></tt>'
+ instruction.</p>
+ <h5>Syntax:</h5>
+ <pre> { <type list> }<br></pre>
+ <h5>Examples:</h5>
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>{ i32, i32, i32 }</tt></td>
+ <td class="left">A triple of three <tt>i32</tt> values</td>
+ </tr><tr class="layout">
+ <td class="left"><tt>{ float, i32 (i32) * }</tt></td>
+ <td class="left">A pair, where the first element is a <tt>float</tt> and the
+ second element is a <a href="#t_pointer">pointer</a> to a
+ <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
+ an <tt>i32</tt>.</td>
+ </tr>
+ </table>
+
+ <p>Note that the code generator does not yet support large aggregate types
+ to be used as function return types. The specific limit on how large an
+ aggregate return type the code generator can currently handle is
+ target-dependent, and also dependent on the aggregate element types.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_pstruct">Packed Structure Type</a>
+ </div>
+ <div class="doc_text">
+ <h5>Overview:</h5>
+ <p>The packed structure type is used to represent a collection of data members
+ together in memory. There is no padding between fields. Further, the alignment
+ of a packed structure is 1 byte. The elements of a packed structure may
+ be any type that has a size.</p>
+ <p>Structures are accessed using '<tt><a href="#i_load">load</a></tt>
+ and '<tt><a href="#i_store">store</a></tt>' by getting a pointer to a
+ field with the '<tt><a href="#i_getelementptr">getelementptr</a></tt>'
+ instruction.</p>
+ <h5>Syntax:</h5>
+ <pre> < { <type list> } > <br></pre>
+ <h5>Examples:</h5>
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>< { i32, i32, i32 } ></tt></td>
+ <td class="left">A triple of three <tt>i32</tt> values</td>
+ </tr><tr class="layout">
+ <td class="left">
+ <tt>< { float, i32 (i32)* } ></tt></td>
+ <td class="left">A pair, where the first element is a <tt>float</tt> and the
+ second element is a <a href="#t_pointer">pointer</a> to a
+ <a href="#t_function">function</a> that takes an <tt>i32</tt>, returning
+ an <tt>i32</tt>.</td>
+ </tr>
+ </table>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_pointer">Pointer Type</a> </div>
+ <div class="doc_text">
+ <h5>Overview:</h5>
+ <p>As in many languages, the pointer type represents a pointer or
+ reference to another object, which must live in memory. Pointer types may have
+ an optional address space attribute defining the target-specific numbered
+ address space where the pointed-to object resides. The default address space is
+ zero.</p>
+ <h5>Syntax:</h5>
+ <pre> <type> *<br></pre>
+ <h5>Examples:</h5>
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>[4 x i32]*</tt></td>
+ <td class="left">A <a href="#t_pointer">pointer</a> to <a
+ href="#t_array">array</a> of four <tt>i32</tt> values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>i32 (i32 *) *</tt></td>
+ <td class="left"> A <a href="#t_pointer">pointer</a> to a <a
+ href="#t_function">function</a> that takes an <tt>i32*</tt>, returning an
+ <tt>i32</tt>.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>i32 addrspace(5)*</tt></td>
+ <td class="left">A <a href="#t_pointer">pointer</a> to an <tt>i32</tt> value
+ that resides in address space #5.</td>
+ </tr>
+ </table>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_vector">Vector Type</a> </div>
+ <div class="doc_text">
+
+ <h5>Overview:</h5>
+
+ <p>A vector type is a simple derived type that represents a vector
+ of elements. Vector types are used when multiple primitive data
+ are operated in parallel using a single instruction (SIMD).
+ A vector type requires a size (number of
+ elements) and an underlying primitive data type. Vectors must have a power
+ of two length (1, 2, 4, 8, 16 ...). Vector types are
+ considered <a href="#t_firstclass">first class</a>.</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ < <# elements> x <elementtype> >
+ </pre>
+
+ <p>The number of elements is a constant integer value; elementtype may
+ be any integer or floating point type.</p>
+
+ <h5>Examples:</h5>
+
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt><4 x i32></tt></td>
+ <td class="left">Vector of 4 32-bit integer values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt><8 x float></tt></td>
+ <td class="left">Vector of 8 32-bit floating-point values.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt><2 x i64></tt></td>
+ <td class="left">Vector of 2 64-bit integer values.</td>
+ </tr>
+ </table>
+
+ <p>Note that the code generator does not yet support large vector types
+ to be used as function return types. The specific limit on how large a
+ vector return type codegen can currently handle is target-dependent;
+ currently it's often a few times longer than a hardware vector register.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="t_opaque">Opaque Type</a> </div>
+ <div class="doc_text">
+
+ <h5>Overview:</h5>
+
+ <p>Opaque types are used to represent unknown types in the system. This
+ corresponds (for example) to the C notion of a forward declared structure type.
+ In LLVM, opaque types can eventually be resolved to any type (not just a
+ structure type).</p>
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ opaque
+ </pre>
+
+ <h5>Examples:</h5>
+
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>opaque</tt></td>
+ <td class="left">An opaque type.</td>
+ </tr>
+ </table>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="t_uprefs">Type Up-references</a>
+ </div>
+
+ <div class="doc_text">
+ <h5>Overview:</h5>
+ <p>
+ An "up reference" allows you to refer to a lexically enclosing type without
+ requiring it to have a name. For instance, a structure declaration may contain a
+ pointer to any of the types it is lexically a member of. Example of up
+ references (with their equivalent as named type declarations) include:</p>
+
+ <pre>
+ { \2 * } %x = type { %t* }
+ { \2 }* %y = type { %y }*
+ \1* %z = type %z*
+ </pre>
+
+ <p>
+ An up reference is needed by the asmprinter for printing out cyclic types when
+ there is no declared name for a type in the cycle. Because the asmprinter does
+ not want to print out an infinite type string, it needs a syntax to handle
+ recursive types that have no names (all names are optional in llvm IR).
+ </p>
+
+ <h5>Syntax:</h5>
+ <pre>
+ \<level>
+ </pre>
+
+ <p>
+ The level is the count of the lexical type that is being referred to.
+ </p>
+
+ <h5>Examples:</h5>
+
+ <table class="layout">
+ <tr class="layout">
+ <td class="left"><tt>\1*</tt></td>
+ <td class="left">Self-referential pointer.</td>
+ </tr>
+ <tr class="layout">
+ <td class="left"><tt>{ { \3*, i8 }, i32 }</tt></td>
+ <td class="left">Recursive structure where the upref refers to the out-most
+ structure.</td>
+ </tr>
+ </table>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="constants">Constants</a> </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM has several different basic types of constants. This section describes
+ them all and their syntax.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="simpleconstants">Simple Constants</a></div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt><b>Boolean constants</b></dt>
+
+ <dd>The two strings '<tt>true</tt>' and '<tt>false</tt>' are both valid
+ constants of the <tt><a href="#t_primitive">i1</a></tt> type.
+ </dd>
+
+ <dt><b>Integer constants</b></dt>
+
+ <dd>Standard integers (such as '4') are constants of the <a
+ href="#t_integer">integer</a> type. Negative numbers may be used with
+ integer types.
+ </dd>
+
+ <dt><b>Floating point constants</b></dt>
+
+ <dd>Floating point constants use standard decimal notation (e.g. 123.421),
+ exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal
+ notation (see below). The assembler requires the exact decimal value of
+ a floating-point constant. For example, the assembler accepts 1.25 but
+ rejects 1.3 because 1.3 is a repeating decimal in binary. Floating point
+ constants must have a <a href="#t_floating">floating point</a> type. </dd>
+
+ <dt><b>Null pointer constants</b></dt>
+
+ <dd>The identifier '<tt>null</tt>' is recognized as a null pointer constant
+ and must be of <a href="#t_pointer">pointer type</a>.</dd>
+
+ </dl>
+
+ <p>The one non-intuitive notation for constants is the optional hexadecimal form
+ of floating point constants. For example, the form '<tt>double
+ 0x432ff973cafa8000</tt>' is equivalent to (but harder to read than) '<tt>double
+ 4.5e+15</tt>'. The only time hexadecimal floating point constants are required
+ (and the only time that they are generated by the disassembler) is when a
+ floating point constant must be emitted but it cannot be represented as a
+ decimal floating point number. For example, NaN's, infinities, and other
+ special values are represented in their IEEE hexadecimal format so that
+ assembly and disassembly do not cause any bits to change in the constants.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="aggregateconstants">Aggregate Constants</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Aggregate constants arise from aggregation of simple constants
+ and smaller aggregate constants.</p>
+
+ <dl>
+ <dt><b>Structure constants</b></dt>
+
+ <dd>Structure constants are represented with notation similar to structure
+ type definitions (a comma separated list of elements, surrounded by braces
+ (<tt>{}</tt>)). For example: "<tt>{ i32 4, float 17.0, i32* @G }</tt>",
+ where "<tt>@G</tt>" is declared as "<tt>@G = external global i32</tt>". Structure constants
+ must have <a href="#t_struct">structure type</a>, and the number and
+ types of elements must match those specified by the type.
+ </dd>
+
+ <dt><b>Array constants</b></dt>
+
+ <dd>Array constants are represented with notation similar to array type
+ definitions (a comma separated list of elements, surrounded by square brackets
+ (<tt>[]</tt>)). For example: "<tt>[ i32 42, i32 11, i32 74 ]</tt>". Array
+ constants must have <a href="#t_array">array type</a>, and the number and
+ types of elements must match those specified by the type.
+ </dd>
+
+ <dt><b>Vector constants</b></dt>
+
+ <dd>Vector constants are represented with notation similar to vector type
+ definitions (a comma separated list of elements, surrounded by
+ less-than/greater-than's (<tt><></tt>)). For example: "<tt>< i32 42,
+ i32 11, i32 74, i32 100 ></tt>". Vector constants must have <a
+ href="#t_vector">vector type</a>, and the number and types of elements must
+ match those specified by the type.
+ </dd>
+
+ <dt><b>Zero initialization</b></dt>
+
+ <dd>The string '<tt>zeroinitializer</tt>' can be used to zero initialize a
+ value to zero of <em>any</em> type, including scalar and aggregate types.
+ This is often used to avoid having to print large zero initializers (e.g. for
+ large arrays) and is always exactly equivalent to using explicit zero
+ initializers.
+ </dd>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="globalconstants">Global Variable and Function Addresses</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The addresses of <a href="#globalvars">global variables</a> and <a
+ href="#functionstructure">functions</a> are always implicitly valid (link-time)
+ constants. These constants are explicitly referenced when the <a
+ href="#identifiers">identifier for the global</a> is used and always have <a
+ href="#t_pointer">pointer</a> type. For example, the following is a legal LLVM
+ file:</p>
+
+ <div class="doc_code">
+ <pre>
+ @X = global i32 17
+ @Y = global i32 42
+ @Z = global [2 x i32*] [ i32* @X, i32* @Y ]
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="undefvalues">Undefined Values</a></div>
+ <div class="doc_text">
+ <p>The string '<tt>undef</tt>' is recognized as a type-less constant that has
+ no specific value. Undefined values may be of any type and be used anywhere
+ a constant is permitted.</p>
+
+ <p>Undefined values indicate to the compiler that the program is well defined
+ no matter what value is used, giving the compiler more freedom to optimize.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="constantexprs">Constant Expressions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Constant expressions are used to allow expressions involving other constants
+ to be used as constants. Constant expressions may be of any <a
+ href="#t_firstclass">first class</a> type and may involve any LLVM operation
+ that does not have side effects (e.g. load and call are not supported). The
+ following is the syntax for constant expressions:</p>
+
+ <dl>
+ <dt><b><tt>trunc ( CST to TYPE )</tt></b></dt>
+ <dd>Truncate a constant to another type. The bit size of CST must be larger
+ than the bit size of TYPE. Both types must be integers.</dd>
+
+ <dt><b><tt>zext ( CST to TYPE )</tt></b></dt>
+ <dd>Zero extend a constant to another type. The bit size of CST must be
+ smaller or equal to the bit size of TYPE. Both types must be integers.</dd>
+
+ <dt><b><tt>sext ( CST to TYPE )</tt></b></dt>
+ <dd>Sign extend a constant to another type. The bit size of CST must be
+ smaller or equal to the bit size of TYPE. Both types must be integers.</dd>
+
+ <dt><b><tt>fptrunc ( CST to TYPE )</tt></b></dt>
+ <dd>Truncate a floating point constant to another floating point type. The
+ size of CST must be larger than the size of TYPE. Both types must be
+ floating point.</dd>
+
+ <dt><b><tt>fpext ( CST to TYPE )</tt></b></dt>
+ <dd>Floating point extend a constant to another type. The size of CST must be
+ smaller or equal to the size of TYPE. Both types must be floating point.</dd>
+
+ <dt><b><tt>fptoui ( CST to TYPE )</tt></b></dt>
+ <dd>Convert a floating point constant to the corresponding unsigned integer
+ constant. TYPE must be a scalar or vector integer type. CST must be of scalar
+ or vector floating point type. Both CST and TYPE must be scalars, or vectors
+ of the same number of elements. If the value won't fit in the integer type,
+ the results are undefined.</dd>
+
+ <dt><b><tt>fptosi ( CST to TYPE )</tt></b></dt>
+ <dd>Convert a floating point constant to the corresponding signed integer
+ constant. TYPE must be a scalar or vector integer type. CST must be of scalar
+ or vector floating point type. Both CST and TYPE must be scalars, or vectors
+ of the same number of elements. If the value won't fit in the integer type,
+ the results are undefined.</dd>
+
+ <dt><b><tt>uitofp ( CST to TYPE )</tt></b></dt>
+ <dd>Convert an unsigned integer constant to the corresponding floating point
+ constant. TYPE must be a scalar or vector floating point type. CST must be of
+ scalar or vector integer type. Both CST and TYPE must be scalars, or vectors
+ of the same number of elements. If the value won't fit in the floating point
+ type, the results are undefined.</dd>
+
+ <dt><b><tt>sitofp ( CST to TYPE )</tt></b></dt>
+ <dd>Convert a signed integer constant to the corresponding floating point
+ constant. TYPE must be a scalar or vector floating point type. CST must be of
+ scalar or vector integer type. Both CST and TYPE must be scalars, or vectors
+ of the same number of elements. If the value won't fit in the floating point
+ type, the results are undefined.</dd>
+
+ <dt><b><tt>ptrtoint ( CST to TYPE )</tt></b></dt>
+ <dd>Convert a pointer typed constant to the corresponding integer constant
+ TYPE must be an integer type. CST must be of pointer type. The CST value is
+ zero extended, truncated, or unchanged to make it fit in TYPE.</dd>
+
+ <dt><b><tt>inttoptr ( CST to TYPE )</tt></b></dt>
+ <dd>Convert a integer constant to a pointer constant. TYPE must be a
+ pointer type. CST must be of integer type. The CST value is zero extended,
+ truncated, or unchanged to make it fit in a pointer size. This one is
+ <i>really</i> dangerous!</dd>
+
+ <dt><b><tt>bitcast ( CST to TYPE )</tt></b></dt>
+ <dd>Convert a constant, CST, to another TYPE. The size of CST and TYPE must be
+ identical (same number of bits). The conversion is done as if the CST value
+ was stored to memory and read back as TYPE. In other words, no bits change
+ with this operator, just the type. This can be used for conversion of
+ vector types to any other type, as long as they have the same bit width. For
+ pointers it is only valid to cast to another pointer type. It is not valid
+ to bitcast to or from an aggregate type.
+ </dd>
+
+ <dt><b><tt>getelementptr ( CSTPTR, IDX0, IDX1, ... )</tt></b></dt>
+
+ <dd>Perform the <a href="#i_getelementptr">getelementptr operation</a> on
+ constants. As with the <a href="#i_getelementptr">getelementptr</a>
+ instruction, the index list may have zero or more indexes, which are required
+ to make sense for the type of "CSTPTR".</dd>
+
+ <dt><b><tt>select ( COND, VAL1, VAL2 )</tt></b></dt>
+
+ <dd>Perform the <a href="#i_select">select operation</a> on
+ constants.</dd>
+
+ <dt><b><tt>icmp COND ( VAL1, VAL2 )</tt></b></dt>
+ <dd>Performs the <a href="#i_icmp">icmp operation</a> on constants.</dd>
+
+ <dt><b><tt>fcmp COND ( VAL1, VAL2 )</tt></b></dt>
+ <dd>Performs the <a href="#i_fcmp">fcmp operation</a> on constants.</dd>
+
+ <dt><b><tt>extractelement ( VAL, IDX )</tt></b></dt>
+
+ <dd>Perform the <a href="#i_extractelement">extractelement
+ operation</a> on constants.</dd>
+
+ <dt><b><tt>insertelement ( VAL, ELT, IDX )</tt></b></dt>
+
+ <dd>Perform the <a href="#i_insertelement">insertelement
+ operation</a> on constants.</dd>
+
+
+ <dt><b><tt>shufflevector ( VEC1, VEC2, IDXMASK )</tt></b></dt>
+
+ <dd>Perform the <a href="#i_shufflevector">shufflevector
+ operation</a> on constants.</dd>
+
+ <dt><b><tt>OPCODE ( LHS, RHS )</tt></b></dt>
+
+ <dd>Perform the specified operation of the LHS and RHS constants. OPCODE may
+ be any of the <a href="#binaryops">binary</a> or <a href="#bitwiseops">bitwise
+ binary</a> operations. The constraints on operands are the same as those for
+ the corresponding instruction (e.g. no bitwise operations on floating point
+ values are allowed).</dd>
+ </dl>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="othervalues">Other Values</a> </div>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="inlineasm">Inline Assembler Expressions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ LLVM supports inline assembler expressions (as opposed to <a href="#moduleasm">
+ Module-Level Inline Assembly</a>) through the use of a special value. This
+ value represents the inline assembler as a string (containing the instructions
+ to emit), a list of operand constraints (stored as a string), and a flag that
+ indicates whether or not the inline asm expression has side effects. An example
+ inline assembler expression is:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ i32 (i32) asm "bswap $0", "=r,r"
+ </pre>
+ </div>
+
+ <p>
+ Inline assembler expressions may <b>only</b> be used as the callee operand of
+ a <a href="#i_call"><tt>call</tt> instruction</a>. Thus, typically we have:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ %X = call i32 asm "<a href="#int_bswap">bswap</a> $0", "=r,r"(i32 %Y)
+ </pre>
+ </div>
+
+ <p>
+ Inline asms with side effects not visible in the constraint list must be marked
+ as having side effects. This is done through the use of the
+ '<tt>sideeffect</tt>' keyword, like so:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ call void asm sideeffect "eieio", ""()
+ </pre>
+ </div>
+
+ <p>TODO: The format of the asm and constraints string still need to be
+ documented here. Constraints on what can be done (e.g. duplication, moving, etc
+ need to be documented). This is probably best done by reference to another
+ document that covers inline asm from a holistic perspective.
+ </p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="instref">Instruction Reference</a> </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM instruction set consists of several different
+ classifications of instructions: <a href="#terminators">terminator
+ instructions</a>, <a href="#binaryops">binary instructions</a>,
+ <a href="#bitwiseops">bitwise binary instructions</a>, <a
+ href="#memoryops">memory instructions</a>, and <a href="#otherops">other
+ instructions</a>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="terminators">Terminator
+ Instructions</a> </div>
+
+ <div class="doc_text">
+
+ <p>As mentioned <a href="#functionstructure">previously</a>, every
+ basic block in a program ends with a "Terminator" instruction, which
+ indicates which block should be executed after the current block is
+ finished. These terminator instructions typically yield a '<tt>void</tt>'
+ value: they produce control flow, not values (the one exception being
+ the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction).</p>
+ <p>There are six different terminator instructions: the '<a
+ href="#i_ret"><tt>ret</tt></a>' instruction, the '<a href="#i_br"><tt>br</tt></a>'
+ instruction, the '<a href="#i_switch"><tt>switch</tt></a>' instruction,
+ the '<a href="#i_invoke"><tt>invoke</tt></a>' instruction, the '<a
+ href="#i_unwind"><tt>unwind</tt></a>' instruction, and the '<a
+ href="#i_unreachable"><tt>unreachable</tt></a>' instruction.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_ret">'<tt>ret</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ ret <type> <value> <i>; Return a value from a non-void function</i>
+ ret void <i>; Return from void function</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>ret</tt>' instruction is used to return control flow (and
+ optionally a value) from a function back to the caller.</p>
+ <p>There are two forms of the '<tt>ret</tt>' instruction: one that
+ returns a value and then causes control flow, and one that just causes
+ control flow to occur.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The '<tt>ret</tt>' instruction optionally accepts a single argument,
+ the return value. The type of the return value must be a
+ '<a href="#t_firstclass">first class</a>' type.</p>
+
+ <p>A function is not <a href="#wellformed">well formed</a> if
+ it it has a non-void return type and contains a '<tt>ret</tt>'
+ instruction with no return value or a return value with a type that
+ does not match its type, or if it has a void return type and contains
+ a '<tt>ret</tt>' instruction with a return value.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>When the '<tt>ret</tt>' instruction is executed, control flow
+ returns back to the calling function's context. If the caller is a "<a
+ href="#i_call"><tt>call</tt></a>" instruction, execution continues at
+ the instruction after the call. If the caller was an "<a
+ href="#i_invoke"><tt>invoke</tt></a>" instruction, execution continues
+ at the beginning of the "normal" destination block. If the instruction
+ returns a value, that value shall set the call or invoke instruction's
+ return value.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ ret i32 5 <i>; Return an integer value of 5</i>
+ ret void <i>; Return from a void function</i>
+ ret { i32, i8 } { i32 4, i8 2 } <i>; Return an aggregate of values 4 and 2</i>
+ </pre>
+
+ <p>Note that the code generator does not yet fully support large
+ return values. The specific sizes that are currently supported are
+ dependent on the target. For integers, on 32-bit targets the limit
+ is often 64 bits, and on 64-bit targets the limit is often 128 bits.
+ For aggregate types, the current limits are dependent on the element
+ types; for example targets are often limited to 2 total integer
+ elements and 2 total floating-point elements.</p>
+
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_br">'<tt>br</tt>' Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> br i1 <cond>, label <iftrue>, label <iffalse><br> br label <dest> <i>; Unconditional branch</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>br</tt>' instruction is used to cause control flow to
+ transfer to a different basic block in the current function. There are
+ two forms of this instruction, corresponding to a conditional branch
+ and an unconditional branch.</p>
+ <h5>Arguments:</h5>
+ <p>The conditional branch form of the '<tt>br</tt>' instruction takes a
+ single '<tt>i1</tt>' value and two '<tt>label</tt>' values. The
+ unconditional form of the '<tt>br</tt>' instruction takes a single
+ '<tt>label</tt>' value as a target.</p>
+ <h5>Semantics:</h5>
+ <p>Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>i1</tt>'
+ argument is evaluated. If the value is <tt>true</tt>, control flows
+ to the '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>,
+ control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.</p>
+ <h5>Example:</h5>
+ <pre>Test:<br> %cond = <a href="#i_icmp">icmp</a> eq, i32 %a, %b<br> br i1 %cond, label %IfEqual, label %IfUnequal<br>IfEqual:<br> <a
+ href="#i_ret">ret</a> i32 1<br>IfUnequal:<br> <a href="#i_ret">ret</a> i32 0<br></pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_switch">'<tt>switch</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+
+ <pre>
+ switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of
+ several different places. It is a generalization of the '<tt>br</tt>'
+ instruction, allowing a branch to occur to one of many possible
+ destinations.</p>
+
+
+ <h5>Arguments:</h5>
+
+ <p>The '<tt>switch</tt>' instruction uses three parameters: an integer
+ comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination, and
+ an array of pairs of comparison value constants and '<tt>label</tt>'s. The
+ table is not allowed to contain duplicate constant entries.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The <tt>switch</tt> instruction specifies a table of values and
+ destinations. When the '<tt>switch</tt>' instruction is executed, this
+ table is searched for the given value. If the value is found, control flow is
+ transfered to the corresponding destination; otherwise, control flow is
+ transfered to the default destination.</p>
+
+ <h5>Implementation:</h5>
+
+ <p>Depending on properties of the target machine and the particular
+ <tt>switch</tt> instruction, this instruction may be code generated in different
+ ways. For example, it could be generated as a series of chained conditional
+ branches or with a lookup table.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ <i>; Emulate a conditional br instruction</i>
+ %Val = <a href="#i_zext">zext</a> i1 %value to i32
+ switch i32 %Val, label %truedest [ i32 0, label %falsedest ]
+
+ <i>; Emulate an unconditional br instruction</i>
+ switch i32 0, label %dest [ ]
+
+ <i>; Implement a jump table:</i>
+ switch i32 %val, label %otherwise [ i32 0, label %onzero
+ i32 1, label %onone
+ i32 2, label %ontwo ]
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_invoke">'<tt>invoke</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = invoke [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] <ptr to function ty> <function ptr val>(<function args>) [<a href="#fnattrs">fn attrs</a>]
+ to label <normal label> unwind label <exception label>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>invoke</tt>' instruction causes control to transfer to a specified
+ function, with the possibility of control flow transfer to either the
+ '<tt>normal</tt>' label or the
+ '<tt>exception</tt>' label. If the callee function returns with the
+ "<tt><a href="#i_ret">ret</a></tt>" instruction, control flow will return to the
+ "normal" label. If the callee (or any indirect callees) returns with the "<a
+ href="#i_unwind"><tt>unwind</tt></a>" instruction, control is interrupted and
+ continued at the dynamically nearest "exception" label.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>This instruction requires several arguments:</p>
+
+ <ol>
+ <li>
+ The optional "cconv" marker indicates which <a href="#callingconv">calling
+ convention</a> the call should use. If none is specified, the call defaults
+ to using C calling conventions.
+ </li>
+
+ <li>The optional <a href="#paramattrs">Parameter Attributes</a> list for
+ return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>',
+ and '<tt>inreg</tt>' attributes are valid here.</li>
+
+ <li>'<tt>ptr to function ty</tt>': shall be the signature of the pointer to
+ function value being invoked. In most cases, this is a direct function
+ invocation, but indirect <tt>invoke</tt>s are just as possible, branching off
+ an arbitrary pointer to function value.
+ </li>
+
+ <li>'<tt>function ptr val</tt>': An LLVM value containing a pointer to a
+ function to be invoked. </li>
+
+ <li>'<tt>function args</tt>': argument list whose types match the function
+ signature argument types. If the function signature indicates the function
+ accepts a variable number of arguments, the extra arguments can be
+ specified. </li>
+
+ <li>'<tt>normal label</tt>': the label reached when the called function
+ executes a '<tt><a href="#i_ret">ret</a></tt>' instruction. </li>
+
+ <li>'<tt>exception label</tt>': the label reached when a callee returns with
+ the <a href="#i_unwind"><tt>unwind</tt></a> instruction. </li>
+
+ <li>The optional <a href="#fnattrs">function attributes</a> list. Only
+ '<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and
+ '<tt>readnone</tt>' attributes are valid here.</li>
+ </ol>
+
+ <h5>Semantics:</h5>
+
+ <p>This instruction is designed to operate as a standard '<tt><a
+ href="#i_call">call</a></tt>' instruction in most regards. The primary
+ difference is that it establishes an association with a label, which is used by
+ the runtime library to unwind the stack.</p>
+
+ <p>This instruction is used in languages with destructors to ensure that proper
+ cleanup is performed in the case of either a <tt>longjmp</tt> or a thrown
+ exception. Additionally, this is important for implementation of
+ '<tt>catch</tt>' clauses in high-level languages that support them.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %retval = invoke i32 @Test(i32 15) to label %Continue
+ unwind label %TestCleanup <i>; {i32}:retval set</i>
+ %retval = invoke <a href="#callingconv">coldcc</a> i32 %Testfnptr(i32 15) to label %Continue
+ unwind label %TestCleanup <i>; {i32}:retval set</i>
+ </pre>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_subsubsection"> <a name="i_unwind">'<tt>unwind</tt>'
+ Instruction</a> </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ unwind
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>unwind</tt>' instruction unwinds the stack, continuing control flow
+ at the first callee in the dynamic call stack which used an <a
+ href="#i_invoke"><tt>invoke</tt></a> instruction to perform the call. This is
+ primarily used to implement exception handling.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>unwind</tt>' instruction causes execution of the current function to
+ immediately halt. The dynamic call stack is then searched for the first <a
+ href="#i_invoke"><tt>invoke</tt></a> instruction on the call stack. Once found,
+ execution continues at the "exceptional" destination block specified by the
+ <tt>invoke</tt> instruction. If there is no <tt>invoke</tt> instruction in the
+ dynamic call chain, undefined behavior results.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_subsubsection"> <a name="i_unreachable">'<tt>unreachable</tt>'
+ Instruction</a> </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ unreachable
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>unreachable</tt>' instruction has no defined semantics. This
+ instruction is used to inform the optimizer that a particular portion of the
+ code is not reachable. This can be used to indicate that the code after a
+ no-return function cannot be reached, and other facts.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>unreachable</tt>' instruction has no defined semantics.</p>
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="binaryops">Binary Operations</a> </div>
+ <div class="doc_text">
+ <p>Binary operators are used to do most of the computation in a
+ program. They require two operands of the same type, execute an operation on them, and
+ produce a single value. The operands might represent
+ multiple data, as is the case with the <a href="#t_vector">vector</a> data type.
+ The result value has the same type as its operands.</p>
+ <p>There are several different binary operators:</p>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_add">'<tt>add</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = add <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>add</tt>' instruction returns the sum of its two operands.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>add</tt>' instruction must be <a
+ href="#t_integer">integer</a>, <a href="#t_floating">floating point</a>, or
+ <a href="#t_vector">vector</a> values. Both arguments must have identical
+ types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The value produced is the integer or floating point sum of the two
+ operands.</p>
+
+ <p>If an integer sum has unsigned overflow, the result returned is the
+ mathematical result modulo 2<sup>n</sup>, where n is the bit width of
+ the result.</p>
+
+ <p>Because LLVM integers use a two's complement representation, this
+ instruction is appropriate for both signed and unsigned integers.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ <result> = add i32 4, %var <i>; yields {i32}:result = 4 + %var</i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_sub">'<tt>sub</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = sub <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>sub</tt>' instruction returns the difference of its two
+ operands.</p>
+
+ <p>Note that the '<tt>sub</tt>' instruction is used to represent the
+ '<tt>neg</tt>' instruction present in most other intermediate
+ representations.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>sub</tt>' instruction must be <a
+ href="#t_integer">integer</a>, <a href="#t_floating">floating point</a>,
+ or <a href="#t_vector">vector</a> values. Both arguments must have identical
+ types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The value produced is the integer or floating point difference of
+ the two operands.</p>
+
+ <p>If an integer difference has unsigned overflow, the result returned is the
+ mathematical result modulo 2<sup>n</sup>, where n is the bit width of
+ the result.</p>
+
+ <p>Because LLVM integers use a two's complement representation, this
+ instruction is appropriate for both signed and unsigned integers.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = sub i32 4, %var <i>; yields {i32}:result = 4 - %var</i>
+ <result> = sub i32 0, %val <i>; yields {i32}:result = -%var</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_mul">'<tt>mul</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre> <result> = mul <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>mul</tt>' instruction returns the product of its two
+ operands.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>mul</tt>' instruction must be <a
+ href="#t_integer">integer</a>, <a href="#t_floating">floating point</a>,
+ or <a href="#t_vector">vector</a> values. Both arguments must have identical
+ types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The value produced is the integer or floating point product of the
+ two operands.</p>
+
+ <p>If the result of an integer multiplication has unsigned overflow,
+ the result returned is the mathematical result modulo
+ 2<sup>n</sup>, where n is the bit width of the result.</p>
+ <p>Because LLVM integers use a two's complement representation, and the
+ result is the same width as the operands, this instruction returns the
+ correct result for both signed and unsigned integers. If a full product
+ (e.g. <tt>i32</tt>x<tt>i32</tt>-><tt>i64</tt>) is needed, the operands
+ should be sign-extended or zero-extended as appropriate to the
+ width of the full product.</p>
+ <h5>Example:</h5>
+ <pre> <result> = mul i32 4, %var <i>; yields {i32}:result = 4 * %var</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_udiv">'<tt>udiv</tt>' Instruction
+ </a></div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = udiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>udiv</tt>' instruction returns the quotient of its two
+ operands.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>udiv</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The value produced is the unsigned integer quotient of the two operands.</p>
+ <p>Note that unsigned integer division and signed integer division are distinct
+ operations; for signed integer division, use '<tt>sdiv</tt>'.</p>
+ <p>Division by zero leads to undefined behavior.</p>
+ <h5>Example:</h5>
+ <pre> <result> = udiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_sdiv">'<tt>sdiv</tt>' Instruction
+ </a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = sdiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>sdiv</tt>' instruction returns the quotient of its two
+ operands.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>sdiv</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+ <p>The value produced is the signed integer quotient of the two operands rounded towards zero.</p>
+ <p>Note that signed integer division and unsigned integer division are distinct
+ operations; for unsigned integer division, use '<tt>udiv</tt>'.</p>
+ <p>Division by zero leads to undefined behavior. Overflow also leads to
+ undefined behavior; this is a rare case, but can occur, for example,
+ by doing a 32-bit division of -2147483648 by -1.</p>
+ <h5>Example:</h5>
+ <pre> <result> = sdiv i32 4, %var <i>; yields {i32}:result = 4 / %var</i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_fdiv">'<tt>fdiv</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = fdiv <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+
+ <p>The '<tt>fdiv</tt>' instruction returns the quotient of its two
+ operands.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>fdiv</tt>' instruction must be
+ <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a>
+ of floating point values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The value produced is the floating point quotient of the two operands.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ <result> = fdiv float 4.0, %var <i>; yields {float}:result = 4.0 / %var</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_urem">'<tt>urem</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = urem <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>urem</tt>' instruction returns the remainder from the
+ unsigned division of its two arguments.</p>
+ <h5>Arguments:</h5>
+ <p>The two arguments to the '<tt>urem</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+ <h5>Semantics:</h5>
+ <p>This instruction returns the unsigned integer <i>remainder</i> of a division.
+ This instruction always performs an unsigned division to get the remainder.</p>
+ <p>Note that unsigned integer remainder and signed integer remainder are
+ distinct operations; for signed integer remainder, use '<tt>srem</tt>'.</p>
+ <p>Taking the remainder of a division by zero leads to undefined behavior.</p>
+ <h5>Example:</h5>
+ <pre> <result> = urem i32 4, %var <i>; yields {i32}:result = 4 % %var</i>
+ </pre>
+
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_srem">'<tt>srem</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = srem <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>srem</tt>' instruction returns the remainder from the
+ signed division of its two operands. This instruction can also take
+ <a href="#t_vector">vector</a> versions of the values in which case
+ the elements must be integers.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>srem</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>This instruction returns the <i>remainder</i> of a division (where the result
+ has the same sign as the dividend, <tt>op1</tt>), not the <i>modulo</i>
+ operator (where the result has the same sign as the divisor, <tt>op2</tt>) of
+ a value. For more information about the difference, see <a
+ href="http://mathforum.org/dr.math/problems/anne.4.28.99.html">The
+ Math Forum</a>. For a table of how this is implemented in various languages,
+ please see <a href="http://en.wikipedia.org/wiki/Modulo_operation">
+ Wikipedia: modulo operation</a>.</p>
+ <p>Note that signed integer remainder and unsigned integer remainder are
+ distinct operations; for unsigned integer remainder, use '<tt>urem</tt>'.</p>
+ <p>Taking the remainder of a division by zero leads to undefined behavior.
+ Overflow also leads to undefined behavior; this is a rare case, but can occur,
+ for example, by taking the remainder of a 32-bit division of -2147483648 by -1.
+ (The remainder doesn't actually overflow, but this rule lets srem be
+ implemented using instructions that return both the result of the division
+ and the remainder.)</p>
+ <h5>Example:</h5>
+ <pre> <result> = srem i32 4, %var <i>; yields {i32}:result = 4 % %var</i>
+ </pre>
+
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_frem">'<tt>frem</tt>' Instruction</a> </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre> <result> = frem <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>frem</tt>' instruction returns the remainder from the
+ division of its two operands.</p>
+ <h5>Arguments:</h5>
+ <p>The two arguments to the '<tt>frem</tt>' instruction must be
+ <a href="#t_floating">floating point</a> or <a href="#t_vector">vector</a>
+ of floating point values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>This instruction returns the <i>remainder</i> of a division.
+ The remainder has the same sign as the dividend.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ <result> = frem float 4.0, %var <i>; yields {float}:result = 4.0 % %var</i>
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="bitwiseops">Bitwise Binary
+ Operations</a> </div>
+ <div class="doc_text">
+ <p>Bitwise binary operators are used to do various forms of
+ bit-twiddling in a program. They are generally very efficient
+ instructions and can commonly be strength reduced from other
+ instructions. They require two operands of the same type, execute an operation on them,
+ and produce a single value. The resulting value is the same type as its operands.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_shl">'<tt>shl</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = shl <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>shl</tt>' instruction returns the first operand shifted to
+ the left a specified number of bits.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>Both arguments to the '<tt>shl</tt>' instruction must be the same <a
+ href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ type. '<tt>op2</tt>' is treated as an unsigned value.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The value produced is <tt>op1</tt> * 2<sup><tt>op2</tt></sup> mod 2<sup>n</sup>,
+ where n is the width of the result. If <tt>op2</tt> is (statically or dynamically) negative or
+ equal to or larger than the number of bits in <tt>op1</tt>, the result is undefined.
+ If the arguments are vectors, each vector element of <tt>op1</tt> is shifted by the
+ corresponding shift amount in <tt>op2</tt>.</p>
+
+ <h5>Example:</h5><pre>
+ <result> = shl i32 4, %var <i>; yields {i32}: 4 << %var</i>
+ <result> = shl i32 4, 2 <i>; yields {i32}: 16</i>
+ <result> = shl i32 1, 10 <i>; yields {i32}: 1024</i>
+ <result> = shl i32 1, 32 <i>; undefined</i>
+ <result> = shl <2 x i32> < i32 1, i32 1>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 2, i32 4></i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_lshr">'<tt>lshr</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = lshr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>lshr</tt>' instruction (logical shift right) returns the first
+ operand shifted to the right a specified number of bits with zero fill.</p>
+
+ <h5>Arguments:</h5>
+ <p>Both arguments to the '<tt>lshr</tt>' instruction must be the same
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ type. '<tt>op2</tt>' is treated as an unsigned value.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>This instruction always performs a logical shift right operation. The most
+ significant bits of the result will be filled with zero bits after the
+ shift. If <tt>op2</tt> is (statically or dynamically) equal to or larger than
+ the number of bits in <tt>op1</tt>, the result is undefined. If the arguments are
+ vectors, each vector element of <tt>op1</tt> is shifted by the corresponding shift
+ amount in <tt>op2</tt>.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = lshr i32 4, 1 <i>; yields {i32}:result = 2</i>
+ <result> = lshr i32 4, 2 <i>; yields {i32}:result = 1</i>
+ <result> = lshr i8 4, 3 <i>; yields {i8}:result = 0</i>
+ <result> = lshr i8 -2, 1 <i>; yields {i8}:result = 0x7FFFFFFF </i>
+ <result> = lshr i32 1, 32 <i>; undefined</i>
+ <result> = lshr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 2> <i>; yields: result=<2 x i32> < i32 0x7FFFFFFF, i32 1></i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_ashr">'<tt>ashr</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre> <result> = ashr <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>ashr</tt>' instruction (arithmetic shift right) returns the first
+ operand shifted to the right a specified number of bits with sign extension.</p>
+
+ <h5>Arguments:</h5>
+ <p>Both arguments to the '<tt>ashr</tt>' instruction must be the same
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ type. '<tt>op2</tt>' is treated as an unsigned value.</p>
+
+ <h5>Semantics:</h5>
+ <p>This instruction always performs an arithmetic shift right operation,
+ The most significant bits of the result will be filled with the sign bit
+ of <tt>op1</tt>. If <tt>op2</tt> is (statically or dynamically) equal to or
+ larger than the number of bits in <tt>op1</tt>, the result is undefined. If the
+ arguments are vectors, each vector element of <tt>op1</tt> is shifted by the
+ corresponding shift amount in <tt>op2</tt>.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = ashr i32 4, 1 <i>; yields {i32}:result = 2</i>
+ <result> = ashr i32 4, 2 <i>; yields {i32}:result = 1</i>
+ <result> = ashr i8 4, 3 <i>; yields {i8}:result = 0</i>
+ <result> = ashr i8 -2, 1 <i>; yields {i8}:result = -1</i>
+ <result> = ashr i32 1, 32 <i>; undefined</i>
+ <result> = ashr <2 x i32> < i32 -2, i32 4>, < i32 1, i32 3> <i>; yields: result=<2 x i32> < i32 -1, i32 0></i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_and">'<tt>and</tt>'
+ Instruction</a> </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = and <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>and</tt>' instruction returns the bitwise logical and of
+ its two operands.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>and</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+ <p>The truth table used for the '<tt>and</tt>' instruction is:</p>
+ <p> </p>
+ <div>
+ <table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr>
+ <td>In0</td>
+ <td>In1</td>
+ <td>Out</td>
+ </tr>
+ <tr>
+ <td>0</td>
+ <td>0</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>0</td>
+ <td>1</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>0</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1</td>
+ <td>1</td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+ <h5>Example:</h5>
+ <pre>
+ <result> = and i32 4, %var <i>; yields {i32}:result = 4 & %var</i>
+ <result> = and i32 15, 40 <i>; yields {i32}:result = 8</i>
+ <result> = and i32 4, 8 <i>; yields {i32}:result = 0</i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_or">'<tt>or</tt>' Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = or <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>or</tt>' instruction returns the bitwise logical inclusive
+ or of its two operands.</p>
+ <h5>Arguments:</h5>
+
+ <p>The two arguments to the '<tt>or</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+ <h5>Semantics:</h5>
+ <p>The truth table used for the '<tt>or</tt>' instruction is:</p>
+ <p> </p>
+ <div>
+ <table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr>
+ <td>In0</td>
+ <td>In1</td>
+ <td>Out</td>
+ </tr>
+ <tr>
+ <td>0</td>
+ <td>0</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>0</td>
+ <td>1</td>
+ <td>1</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>0</td>
+ <td>1</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1</td>
+ <td>1</td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+ <h5>Example:</h5>
+ <pre> <result> = or i32 4, %var <i>; yields {i32}:result = 4 | %var</i>
+ <result> = or i32 15, 40 <i>; yields {i32}:result = 47</i>
+ <result> = or i32 4, 8 <i>; yields {i32}:result = 12</i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_xor">'<tt>xor</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = xor <ty> <op1>, <op2> <i>; yields {ty}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>xor</tt>' instruction returns the bitwise logical exclusive
+ or of its two operands. The <tt>xor</tt> is used to implement the
+ "one's complement" operation, which is the "~" operator in C.</p>
+ <h5>Arguments:</h5>
+ <p>The two arguments to the '<tt>xor</tt>' instruction must be
+ <a href="#t_integer">integer</a> or <a href="#t_vector">vector</a> of integer
+ values. Both arguments must have identical types.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The truth table used for the '<tt>xor</tt>' instruction is:</p>
+ <p> </p>
+ <div>
+ <table border="1" cellspacing="0" cellpadding="4">
+ <tbody>
+ <tr>
+ <td>In0</td>
+ <td>In1</td>
+ <td>Out</td>
+ </tr>
+ <tr>
+ <td>0</td>
+ <td>0</td>
+ <td>0</td>
+ </tr>
+ <tr>
+ <td>0</td>
+ <td>1</td>
+ <td>1</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>0</td>
+ <td>1</td>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td>1</td>
+ <td>0</td>
+ </tr>
+ </tbody>
+ </table>
+ </div>
+ <p> </p>
+ <h5>Example:</h5>
+ <pre> <result> = xor i32 4, %var <i>; yields {i32}:result = 4 ^ %var</i>
+ <result> = xor i32 15, 40 <i>; yields {i32}:result = 39</i>
+ <result> = xor i32 4, 8 <i>; yields {i32}:result = 12</i>
+ <result> = xor i32 %V, -1 <i>; yields {i32}:result = ~%V</i>
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="vectorops">Vector Operations</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM supports several instructions to represent vector operations in a
+ target-independent manner. These instructions cover the element-access and
+ vector-specific operations needed to process vectors effectively. While LLVM
+ does directly support these vector operations, many sophisticated algorithms
+ will want to use target-specific intrinsics to take full advantage of a specific
+ target.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_extractelement">'<tt>extractelement</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = extractelement <n x <ty>> <val>, i32 <idx> <i>; yields <ty></i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>extractelement</tt>' instruction extracts a single scalar
+ element from a vector at a specified index.
+ </p>
+
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first operand of an '<tt>extractelement</tt>' instruction is a
+ value of <a href="#t_vector">vector</a> type. The second operand is
+ an index indicating the position from which to extract the element.
+ The index may be a variable.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The result is a scalar of the same type as the element type of
+ <tt>val</tt>. Its value is the value at position <tt>idx</tt> of
+ <tt>val</tt>. If <tt>idx</tt> exceeds the length of <tt>val</tt>, the
+ results are undefined.
+ </p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %result = extractelement <4 x i32> %vec, i32 0 <i>; yields i32</i>
+ </pre>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_insertelement">'<tt>insertelement</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = insertelement <n x <ty>> <val>, <ty> <elt>, i32 <idx> <i>; yields <n x <ty>></i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>insertelement</tt>' instruction inserts a scalar
+ element into a vector at a specified index.
+ </p>
+
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first operand of an '<tt>insertelement</tt>' instruction is a
+ value of <a href="#t_vector">vector</a> type. The second operand is a
+ scalar value whose type must equal the element type of the first
+ operand. The third operand is an index indicating the position at
+ which to insert the value. The index may be a variable.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The result is a vector of the same type as <tt>val</tt>. Its
+ element values are those of <tt>val</tt> except at position
+ <tt>idx</tt>, where it gets the value <tt>elt</tt>. If <tt>idx</tt>
+ exceeds the length of <tt>val</tt>, the results are undefined.
+ </p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %result = insertelement <4 x i32> %vec, i32 1, i32 0 <i>; yields <4 x i32></i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_shufflevector">'<tt>shufflevector</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = shufflevector <n x <ty>> <v1>, <n x <ty>> <v2>, <m x i32> <mask> <i>; yields <m x <ty>></i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>shufflevector</tt>' instruction constructs a permutation of elements
+ from two input vectors, returning a vector with the same element type as
+ the input and length that is the same as the shuffle mask.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first two operands of a '<tt>shufflevector</tt>' instruction are vectors
+ with types that match each other. The third argument is a shuffle mask whose
+ element type is always 'i32'. The result of the instruction is a vector whose
+ length is the same as the shuffle mask and whose element type is the same as
+ the element type of the first two operands.
+ </p>
+
+ <p>
+ The shuffle mask operand is required to be a constant vector with either
+ constant integer or undef values.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The elements of the two input vectors are numbered from left to right across
+ both of the vectors. The shuffle mask operand specifies, for each element of
+ the result vector, which element of the two input vectors the result element
+ gets. The element selector may be undef (meaning "don't care") and the second
+ operand may be undef if performing a shuffle from only one vector.
+ </p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %result = shufflevector <4 x i32> %v1, <4 x i32> %v2,
+ <4 x i32> <i32 0, i32 4, i32 1, i32 5> <i>; yields <4 x i32></i>
+ %result = shufflevector <4 x i32> %v1, <4 x i32> undef,
+ <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i> - Identity shuffle.
+ %result = shufflevector <8 x i32> %v1, <8 x i32> undef,
+ <4 x i32> <i32 0, i32 1, i32 2, i32 3> <i>; yields <4 x i32></i>
+ %result = shufflevector <4 x i32> %v1, <4 x i32> %v2,
+ <8 x i32> <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5, i32 6, i32 7 > <i>; yields <8 x i32></i>
+ </pre>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="aggregateops">Aggregate Operations</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM supports several instructions for working with aggregate values.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_extractvalue">'<tt>extractvalue</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = extractvalue <aggregate type> <val>, <idx>{, <idx>}*
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>extractvalue</tt>' instruction extracts the value of a struct field
+ or array element from an aggregate value.
+ </p>
+
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first operand of an '<tt>extractvalue</tt>' instruction is a
+ value of <a href="#t_struct">struct</a> or <a href="#t_array">array</a>
+ type. The operands are constant indices to specify which value to extract
+ in a similar manner as indices in a
+ '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The result is the value at the position in the aggregate specified by
+ the index operands.
+ </p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %result = extractvalue {i32, float} %agg, 0 <i>; yields i32</i>
+ </pre>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_insertvalue">'<tt>insertvalue</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = insertvalue <aggregate type> <val>, <ty> <val>, <idx> <i>; yields <n x <ty>></i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>insertvalue</tt>' instruction inserts a value
+ into a struct field or array element in an aggregate.
+ </p>
+
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first operand of an '<tt>insertvalue</tt>' instruction is a
+ value of <a href="#t_struct">struct</a> or <a href="#t_array">array</a> type.
+ The second operand is a first-class value to insert.
+ The following operands are constant indices
+ indicating the position at which to insert the value in a similar manner as
+ indices in a
+ '<tt><a href="#i_getelementptr">getelementptr</a></tt>' instruction.
+ The value to insert must have the same type as the value identified
+ by the indices.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The result is an aggregate of the same type as <tt>val</tt>. Its
+ value is that of <tt>val</tt> except that the value at the position
+ specified by the indices is that of <tt>elt</tt>.
+ </p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %result = insertvalue {i32, float} %agg, i32 1, 0 <i>; yields {i32, float}</i>
+ </pre>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="memoryops">Memory Access and Addressing Operations</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>A key design point of an SSA-based representation is how it
+ represents memory. In LLVM, no memory locations are in SSA form, which
+ makes things very simple. This section describes how to read, write,
+ allocate, and free memory in LLVM.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_malloc">'<tt>malloc</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = malloc <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>malloc</tt>' instruction allocates memory from the system
+ heap and returns a pointer to it. The object is always allocated in the generic
+ address space (address space zero).</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The '<tt>malloc</tt>' instruction allocates
+ <tt>sizeof(<type>)*NumElements</tt>
+ bytes of memory from the operating system and returns a pointer of the
+ appropriate type to the program. If "NumElements" is specified, it is the
+ number of elements allocated, otherwise "NumElements" is defaulted to be one.
+ If a constant alignment is specified, the value result of the allocation is guaranteed to
+ be aligned to at least that boundary. If not specified, or if zero, the target can
+ choose to align the allocation on any convenient boundary.</p>
+
+ <p>'<tt>type</tt>' must be a sized type.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>Memory is allocated using the system "<tt>malloc</tt>" function, and
+ a pointer is returned. The result of a zero byte allocation is undefined. The
+ result is null if there is insufficient memory available.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %array = malloc [4 x i8] <i>; yields {[%4 x i8]*}:array</i>
+
+ %size = <a href="#i_add">add</a> i32 2, 2 <i>; yields {i32}:size = i32 4</i>
+ %array1 = malloc i8, i32 4 <i>; yields {i8*}:array1</i>
+ %array2 = malloc [12 x i8], i32 %size <i>; yields {[12 x i8]*}:array2</i>
+ %array3 = malloc i32, i32 4, align 1024 <i>; yields {i32*}:array3</i>
+ %array4 = malloc i32, align 1024 <i>; yields {i32*}:array4</i>
+ </pre>
+
+ <p>Note that the code generator does not yet respect the
+ alignment value.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_free">'<tt>free</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ free <type> <value> <i>; yields {void}</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>free</tt>' instruction returns memory back to the unused
+ memory heap to be reallocated in the future.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>'<tt>value</tt>' shall be a pointer value that points to a value
+ that was allocated with the '<tt><a href="#i_malloc">malloc</a></tt>'
+ instruction.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>Access to the memory pointed to by the pointer is no longer defined
+ after this instruction executes. If the pointer is null, the operation
+ is a noop.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %array = <a href="#i_malloc">malloc</a> [4 x i8] <i>; yields {[4 x i8]*}:array</i>
+ free [4 x i8]* %array
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_alloca">'<tt>alloca</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = alloca <type>[, i32 <NumElements>][, align <alignment>] <i>; yields {type*}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>alloca</tt>' instruction allocates memory on the stack frame of the
+ currently executing function, to be automatically released when this function
+ returns to its caller. The object is always allocated in the generic address
+ space (address space zero).</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The '<tt>alloca</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt>
+ bytes of memory on the runtime stack, returning a pointer of the
+ appropriate type to the program. If "NumElements" is specified, it is the
+ number of elements allocated, otherwise "NumElements" is defaulted to be one.
+ If a constant alignment is specified, the value result of the allocation is guaranteed
+ to be aligned to at least that boundary. If not specified, or if zero, the target
+ can choose to align the allocation on any convenient boundary.</p>
+
+ <p>'<tt>type</tt>' may be any sized type.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>Memory is allocated; a pointer is returned. The operation is undefiend if
+ there is insufficient stack space for the allocation. '<tt>alloca</tt>'d
+ memory is automatically released when the function returns. The '<tt>alloca</tt>'
+ instruction is commonly used to represent automatic variables that must
+ have an address available. When the function returns (either with the <tt><a
+ href="#i_ret">ret</a></tt> or <tt><a href="#i_unwind">unwind</a></tt>
+ instructions), the memory is reclaimed. Allocating zero bytes
+ is legal, but the result is undefined.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %ptr = alloca i32 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, i32 4 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, i32 4, align 1024 <i>; yields {i32*}:ptr</i>
+ %ptr = alloca i32, align 1024 <i>; yields {i32*}:ptr</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_load">'<tt>load</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = load <ty>* <pointer>[, align <alignment>]<br> <result> = volatile load <ty>* <pointer>[, align <alignment>]<br></pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>load</tt>' instruction is used to read from memory.</p>
+ <h5>Arguments:</h5>
+ <p>The argument to the '<tt>load</tt>' instruction specifies the memory
+ address from which to load. The pointer must point to a <a
+ href="#t_firstclass">first class</a> type. If the <tt>load</tt> is
+ marked as <tt>volatile</tt>, then the optimizer is not allowed to modify
+ the number or order of execution of this <tt>load</tt> with other
+ volatile <tt>load</tt> and <tt><a href="#i_store">store</a></tt>
+ instructions. </p>
+ <p>
+ The optional constant "align" argument specifies the alignment of the operation
+ (that is, the alignment of the memory address). A value of 0 or an
+ omitted "align" argument means that the operation has the preferential
+ alignment for the target. It is the responsibility of the code emitter
+ to ensure that the alignment information is correct. Overestimating
+ the alignment results in an undefined behavior. Underestimating the
+ alignment may produce less efficient code. An alignment of 1 is always
+ safe.
+ </p>
+ <h5>Semantics:</h5>
+ <p>The location of memory pointed to is loaded.</p>
+ <h5>Examples:</h5>
+ <pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
+ <a
+ href="#i_store">store</a> i32 3, i32* %ptr <i>; yields {void}</i>
+ %val = load i32* %ptr <i>; yields {i32}:val = i32 3</i>
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"> <a name="i_store">'<tt>store</tt>'
+ Instruction</a> </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> store <ty> <value>, <ty>* <pointer>[, align <alignment>] <i>; yields {void}</i>
+ volatile store <ty> <value>, <ty>* <pointer>[, align <alignment>] <i>; yields {void}</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>store</tt>' instruction is used to write to memory.</p>
+ <h5>Arguments:</h5>
+ <p>There are two arguments to the '<tt>store</tt>' instruction: a value
+ to store and an address at which to store it. The type of the '<tt><pointer></tt>'
+ operand must be a pointer to the <a href="#t_firstclass">first class</a> type
+ of the '<tt><value></tt>'
+ operand. If the <tt>store</tt> is marked as <tt>volatile</tt>, then the
+ optimizer is not allowed to modify the number or order of execution of
+ this <tt>store</tt> with other volatile <tt>load</tt> and <tt><a
+ href="#i_store">store</a></tt> instructions.</p>
+ <p>
+ The optional constant "align" argument specifies the alignment of the operation
+ (that is, the alignment of the memory address). A value of 0 or an
+ omitted "align" argument means that the operation has the preferential
+ alignment for the target. It is the responsibility of the code emitter
+ to ensure that the alignment information is correct. Overestimating
+ the alignment results in an undefined behavior. Underestimating the
+ alignment may produce less efficient code. An alignment of 1 is always
+ safe.
+ </p>
+ <h5>Semantics:</h5>
+ <p>The contents of memory are updated to contain '<tt><value></tt>'
+ at the location specified by the '<tt><pointer></tt>' operand.</p>
+ <h5>Example:</h5>
+ <pre> %ptr = <a href="#i_alloca">alloca</a> i32 <i>; yields {i32*}:ptr</i>
+ store i32 3, i32* %ptr <i>; yields {void}</i>
+ %val = <a href="#i_load">load</a> i32* %ptr <i>; yields {i32}:val = i32 3</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_getelementptr">'<tt>getelementptr</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = getelementptr <pty>* <ptrval>{, <ty> <idx>}*
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>getelementptr</tt>' instruction is used to get the address of a
+ subelement of an aggregate data structure. It performs address calculation only
+ and does not access memory.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The first argument is always a pointer, and forms the basis of the
+ calculation. The remaining arguments are indices, that indicate which of the
+ elements of the aggregate object are indexed. The interpretation of each index
+ is dependent on the type being indexed into. The first index always indexes the
+ pointer value given as the first argument, the second index indexes a value of
+ the type pointed to (not necessarily the value directly pointed to, since the
+ first index can be non-zero), etc. The first type indexed into must be a pointer
+ value, subsequent types can be arrays, vectors and structs. Note that subsequent
+ types being indexed into can never be pointers, since that would require loading
+ the pointer before continuing calculation.</p>
+
+ <p>The type of each index argument depends on the type it is indexing into.
+ When indexing into a (packed) structure, only <tt>i32</tt> integer
+ <b>constants</b> are allowed. When indexing into an array, pointer or vector,
+ only integers of 32 or 64 bits are allowed (also non-constants). 32-bit values
+ will be sign extended to 64-bits if required.</p>
+
+ <p>For example, let's consider a C code fragment and how it gets
+ compiled to LLVM:</p>
+
+ <div class="doc_code">
+ <pre>
+ struct RT {
+ char A;
+ int B[10][20];
+ char C;
+ };
+ struct ST {
+ int X;
+ double Y;
+ struct RT Z;
+ };
+
+ int *foo(struct ST *s) {
+ return &s[1].Z.B[5][13];
+ }
+ </pre>
+ </div>
+
+ <p>The LLVM code generated by the GCC frontend is:</p>
+
+ <div class="doc_code">
+ <pre>
+ %RT = <a href="#namedtypes">type</a> { i8 , [10 x [20 x i32]], i8 }
+ %ST = <a href="#namedtypes">type</a> { i32, double, %RT }
+
+ define i32* %foo(%ST* %s) {
+ entry:
+ %reg = getelementptr %ST* %s, i32 1, i32 2, i32 1, i32 5, i32 13
+ ret i32* %reg
+ }
+ </pre>
+ </div>
+
+ <h5>Semantics:</h5>
+
+ <p>In the example above, the first index is indexing into the '<tt>%ST*</tt>'
+ type, which is a pointer, yielding a '<tt>%ST</tt>' = '<tt>{ i32, double, %RT
+ }</tt>' type, a structure. The second index indexes into the third element of
+ the structure, yielding a '<tt>%RT</tt>' = '<tt>{ i8 , [10 x [20 x i32]],
+ i8 }</tt>' type, another structure. The third index indexes into the second
+ element of the structure, yielding a '<tt>[10 x [20 x i32]]</tt>' type, an
+ array. The two dimensions of the array are subscripted into, yielding an
+ '<tt>i32</tt>' type. The '<tt>getelementptr</tt>' instruction returns a pointer
+ to this element, thus computing a value of '<tt>i32*</tt>' type.</p>
+
+ <p>Note that it is perfectly legal to index partially through a
+ structure, returning a pointer to an inner element. Because of this,
+ the LLVM code for the given testcase is equivalent to:</p>
+
+ <pre>
+ define i32* %foo(%ST* %s) {
+ %t1 = getelementptr %ST* %s, i32 1 <i>; yields %ST*:%t1</i>
+ %t2 = getelementptr %ST* %t1, i32 0, i32 2 <i>; yields %RT*:%t2</i>
+ %t3 = getelementptr %RT* %t2, i32 0, i32 1 <i>; yields [10 x [20 x i32]]*:%t3</i>
+ %t4 = getelementptr [10 x [20 x i32]]* %t3, i32 0, i32 5 <i>; yields [20 x i32]*:%t4</i>
+ %t5 = getelementptr [20 x i32]* %t4, i32 0, i32 13 <i>; yields i32*:%t5</i>
+ ret i32* %t5
+ }
+ </pre>
+
+ <p>Note that it is undefined to access an array out of bounds: array and
+ pointer indexes must always be within the defined bounds of the array type.
+ The one exception for this rule is zero length arrays. These arrays are
+ defined to be accessible as variable length arrays, which requires access
+ beyond the zero'th element.</p>
+
+ <p>The getelementptr instruction is often confusing. For some more insight
+ into how it works, see <a href="GetElementPtr.html">the getelementptr
+ FAQ</a>.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ <i>; yields [12 x i8]*:aptr</i>
+ %aptr = getelementptr {i32, [12 x i8]}* %saptr, i64 0, i32 1
+ <i>; yields i8*:vptr</i>
+ %vptr = getelementptr {i32, <2 x i8>}* %svptr, i64 0, i32 1, i32 1
+ <i>; yields i8*:eptr</i>
+ %eptr = getelementptr [12 x i8]* %aptr, i64 0, i32 1
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="convertops">Conversion Operations</a>
+ </div>
+ <div class="doc_text">
+ <p>The instructions in this category are the conversion instructions (casting)
+ which all take a single operand and a type. They perform various bit conversions
+ on the operand.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_trunc">'<tt>trunc .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = trunc <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>
+ The '<tt>trunc</tt>' instruction truncates its operand to the type <tt>ty2</tt>.
+ </p>
+
+ <h5>Arguments:</h5>
+ <p>
+ The '<tt>trunc</tt>' instruction takes a <tt>value</tt> to trunc, which must
+ be an <a href="#t_integer">integer</a> type, and a type that specifies the size
+ and type of the result, which must be an <a href="#t_integer">integer</a>
+ type. The bit size of <tt>value</tt> must be larger than the bit size of
+ <tt>ty2</tt>. Equal sized types are not allowed.</p>
+
+ <h5>Semantics:</h5>
+ <p>
+ The '<tt>trunc</tt>' instruction truncates the high order bits in <tt>value</tt>
+ and converts the remaining bits to <tt>ty2</tt>. Since the source size must be
+ larger than the destination size, <tt>trunc</tt> cannot be a <i>no-op cast</i>.
+ It will always truncate bits.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = trunc i32 257 to i8 <i>; yields i8:1</i>
+ %Y = trunc i32 123 to i1 <i>; yields i1:true</i>
+ %Y = trunc i32 122 to i1 <i>; yields i1:false</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_zext">'<tt>zext .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = zext <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>zext</tt>' instruction zero extends its operand to type
+ <tt>ty2</tt>.</p>
+
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>zext</tt>' instruction takes a value to cast, which must be of
+ <a href="#t_integer">integer</a> type, and a type to cast it to, which must
+ also be of <a href="#t_integer">integer</a> type. The bit size of the
+ <tt>value</tt> must be smaller than the bit size of the destination type,
+ <tt>ty2</tt>.</p>
+
+ <h5>Semantics:</h5>
+ <p>The <tt>zext</tt> fills the high order bits of the <tt>value</tt> with zero
+ bits until it reaches the size of the destination type, <tt>ty2</tt>.</p>
+
+ <p>When zero extending from i1, the result will always be either 0 or 1.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = zext i32 257 to i64 <i>; yields i64:257</i>
+ %Y = zext i1 true to i32 <i>; yields i32:1</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_sext">'<tt>sext .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = sext <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>sext</tt>' sign extends <tt>value</tt> to the type <tt>ty2</tt>.</p>
+
+ <h5>Arguments:</h5>
+ <p>
+ The '<tt>sext</tt>' instruction takes a value to cast, which must be of
+ <a href="#t_integer">integer</a> type, and a type to cast it to, which must
+ also be of <a href="#t_integer">integer</a> type. The bit size of the
+ <tt>value</tt> must be smaller than the bit size of the destination type,
+ <tt>ty2</tt>.</p>
+
+ <h5>Semantics:</h5>
+ <p>
+ The '<tt>sext</tt>' instruction performs a sign extension by copying the sign
+ bit (highest order bit) of the <tt>value</tt> until it reaches the bit size of
+ the type <tt>ty2</tt>.</p>
+
+ <p>When sign extending from i1, the extension always results in -1 or 0.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = sext i8 -1 to i16 <i>; yields i16 :65535</i>
+ %Y = sext i1 true to i32 <i>; yields i32:-1</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_fptrunc">'<tt>fptrunc .. to</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = fptrunc <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>fptrunc</tt>' instruction truncates <tt>value</tt> to type
+ <tt>ty2</tt>.</p>
+
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>fptrunc</tt>' instruction takes a <a href="#t_floating">floating
+ point</a> value to cast and a <a href="#t_floating">floating point</a> type to
+ cast it to. The size of <tt>value</tt> must be larger than the size of
+ <tt>ty2</tt>. This implies that <tt>fptrunc</tt> cannot be used to make a
+ <i>no-op cast</i>.</p>
+
+ <h5>Semantics:</h5>
+ <p> The '<tt>fptrunc</tt>' instruction truncates a <tt>value</tt> from a larger
+ <a href="#t_floating">floating point</a> type to a smaller
+ <a href="#t_floating">floating point</a> type. If the value cannot fit within
+ the destination type, <tt>ty2</tt>, then the results are undefined.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = fptrunc double 123.0 to float <i>; yields float:123.0</i>
+ %Y = fptrunc double 1.0E+300 to float <i>; yields undefined</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_fpext">'<tt>fpext .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = fpext <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>fpext</tt>' extends a floating point <tt>value</tt> to a larger
+ floating point value.</p>
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>fpext</tt>' instruction takes a
+ <a href="#t_floating">floating point</a> <tt>value</tt> to cast,
+ and a <a href="#t_floating">floating point</a> type to cast it to. The source
+ type must be smaller than the destination type.</p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>fpext</tt>' instruction extends the <tt>value</tt> from a smaller
+ <a href="#t_floating">floating point</a> type to a larger
+ <a href="#t_floating">floating point</a> type. The <tt>fpext</tt> cannot be
+ used to make a <i>no-op cast</i> because it always changes bits. Use
+ <tt>bitcast</tt> to make a <i>no-op cast</i> for a floating point cast.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = fpext float 3.1415 to double <i>; yields double:3.1415</i>
+ %Y = fpext float 1.0 to float <i>; yields float:1.0 (no-op)</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_fptoui">'<tt>fptoui .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = fptoui <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>fptoui</tt>' converts a floating point <tt>value</tt> to its
+ unsigned integer equivalent of type <tt>ty2</tt>.
+ </p>
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>fptoui</tt>' instruction takes a value to cast, which must be a
+ scalar or vector <a href="#t_floating">floating point</a> value, and a type
+ to cast it to <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a>
+ type. If <tt>ty</tt> is a vector floating point type, <tt>ty2</tt> must be a
+ vector integer type with the same number of elements as <tt>ty</tt></p>
+
+ <h5>Semantics:</h5>
+ <p> The '<tt>fptoui</tt>' instruction converts its
+ <a href="#t_floating">floating point</a> operand into the nearest (rounding
+ towards zero) unsigned integer value. If the value cannot fit in <tt>ty2</tt>,
+ the results are undefined.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = fptoui double 123.0 to i32 <i>; yields i32:123</i>
+ %Y = fptoui float 1.0E+300 to i1 <i>; yields undefined:1</i>
+ %X = fptoui float 1.04E+17 to i8 <i>; yields undefined:1</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_fptosi">'<tt>fptosi .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = fptosi <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>fptosi</tt>' instruction converts
+ <a href="#t_floating">floating point</a> <tt>value</tt> to type <tt>ty2</tt>.
+ </p>
+
+ <h5>Arguments:</h5>
+ <p> The '<tt>fptosi</tt>' instruction takes a value to cast, which must be a
+ scalar or vector <a href="#t_floating">floating point</a> value, and a type
+ to cast it to <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a>
+ type. If <tt>ty</tt> is a vector floating point type, <tt>ty2</tt> must be a
+ vector integer type with the same number of elements as <tt>ty</tt></p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>fptosi</tt>' instruction converts its
+ <a href="#t_floating">floating point</a> operand into the nearest (rounding
+ towards zero) signed integer value. If the value cannot fit in <tt>ty2</tt>,
+ the results are undefined.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = fptosi double -123.0 to i32 <i>; yields i32:-123</i>
+ %Y = fptosi float 1.0E-247 to i1 <i>; yields undefined:1</i>
+ %X = fptosi float 1.04E+17 to i8 <i>; yields undefined:1</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_uitofp">'<tt>uitofp .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = uitofp <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>uitofp</tt>' instruction regards <tt>value</tt> as an unsigned
+ integer and converts that value to the <tt>ty2</tt> type.</p>
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>uitofp</tt>' instruction takes a value to cast, which must be a
+ scalar or vector <a href="#t_integer">integer</a> value, and a type to cast it
+ to <tt>ty2</tt>, which must be an <a href="#t_floating">floating point</a>
+ type. If <tt>ty</tt> is a vector integer type, <tt>ty2</tt> must be a vector
+ floating point type with the same number of elements as <tt>ty</tt></p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>uitofp</tt>' instruction interprets its operand as an unsigned
+ integer quantity and converts it to the corresponding floating point value. If
+ the value cannot fit in the floating point value, the results are undefined.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = uitofp i32 257 to float <i>; yields float:257.0</i>
+ %Y = uitofp i8 -1 to double <i>; yields double:255.0</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_sitofp">'<tt>sitofp .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = sitofp <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>sitofp</tt>' instruction regards <tt>value</tt> as a signed
+ integer and converts that value to the <tt>ty2</tt> type.</p>
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>sitofp</tt>' instruction takes a value to cast, which must be a
+ scalar or vector <a href="#t_integer">integer</a> value, and a type to cast it
+ to <tt>ty2</tt>, which must be an <a href="#t_floating">floating point</a>
+ type. If <tt>ty</tt> is a vector integer type, <tt>ty2</tt> must be a vector
+ floating point type with the same number of elements as <tt>ty</tt></p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>sitofp</tt>' instruction interprets its operand as a signed
+ integer quantity and converts it to the corresponding floating point value. If
+ the value cannot fit in the floating point value, the results are undefined.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = sitofp i32 257 to float <i>; yields float:257.0</i>
+ %Y = sitofp i8 -1 to double <i>; yields double:-1.0</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_ptrtoint">'<tt>ptrtoint .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = ptrtoint <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>ptrtoint</tt>' instruction converts the pointer <tt>value</tt> to
+ the integer type <tt>ty2</tt>.</p>
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>ptrtoint</tt>' instruction takes a <tt>value</tt> to cast, which
+ must be a <a href="#t_pointer">pointer</a> value, and a type to cast it to
+ <tt>ty2</tt>, which must be an <a href="#t_integer">integer</a> type.</p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>ptrtoint</tt>' instruction converts <tt>value</tt> to integer type
+ <tt>ty2</tt> by interpreting the pointer value as an integer and either
+ truncating or zero extending that value to the size of the integer type. If
+ <tt>value</tt> is smaller than <tt>ty2</tt> then a zero extension is done. If
+ <tt>value</tt> is larger than <tt>ty2</tt> then a truncation is done. If they
+ are the same size, then nothing is done (<i>no-op cast</i>) other than a type
+ change.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = ptrtoint i32* %X to i8 <i>; yields truncation on 32-bit architecture</i>
+ %Y = ptrtoint i32* %x to i64 <i>; yields zero extension on 32-bit architecture</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_inttoptr">'<tt>inttoptr .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = inttoptr <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>inttoptr</tt>' instruction converts an integer <tt>value</tt> to
+ a pointer type, <tt>ty2</tt>.</p>
+
+ <h5>Arguments:</h5>
+ <p>The '<tt>inttoptr</tt>' instruction takes an <a href="#t_integer">integer</a>
+ value to cast, and a type to cast it to, which must be a
+ <a href="#t_pointer">pointer</a> type.</p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>inttoptr</tt>' instruction converts <tt>value</tt> to type
+ <tt>ty2</tt> by applying either a zero extension or a truncation depending on
+ the size of the integer <tt>value</tt>. If <tt>value</tt> is larger than the
+ size of a pointer then a truncation is done. If <tt>value</tt> is smaller than
+ the size of a pointer then a zero extension is done. If they are the same size,
+ nothing is done (<i>no-op cast</i>).</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = inttoptr i32 255 to i32* <i>; yields zero extension on 64-bit architecture</i>
+ %X = inttoptr i32 255 to i32* <i>; yields no-op on 32-bit architecture</i>
+ %Y = inttoptr i64 0 to i32* <i>; yields truncation on 32-bit architecture</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_bitcast">'<tt>bitcast .. to</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = bitcast <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
+ <tt>ty2</tt> without changing any bits.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The '<tt>bitcast</tt>' instruction takes a value to cast, which must be
+ a non-aggregate first class value, and a type to cast it to, which must also be
+ a non-aggregate <a href="#t_firstclass">first class</a> type. The bit sizes of
+ <tt>value</tt>
+ and the destination type, <tt>ty2</tt>, must be identical. If the source
+ type is a pointer, the destination type must also be a pointer. This
+ instruction supports bitwise conversion of vectors to integers and to vectors
+ of other types (as long as they have the same size).</p>
+
+ <h5>Semantics:</h5>
+ <p>The '<tt>bitcast</tt>' instruction converts <tt>value</tt> to type
+ <tt>ty2</tt>. It is always a <i>no-op cast</i> because no bits change with
+ this conversion. The conversion is done as if the <tt>value</tt> had been
+ stored to memory and read back as type <tt>ty2</tt>. Pointer types may only be
+ converted to other pointer types with this instruction. To convert pointers to
+ other types, use the <a href="#i_inttoptr">inttoptr</a> or
+ <a href="#i_ptrtoint">ptrtoint</a> instructions first.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = bitcast i8 255 to i8 <i>; yields i8 :-1</i>
+ %Y = bitcast i32* %x to sint* <i>; yields sint*:%x</i>
+ %Z = bitcast <2 x int> %V to i64; <i>; yields i64: %V</i>
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"> <a name="otherops">Other Operations</a> </div>
+ <div class="doc_text">
+ <p>The instructions in this category are the "miscellaneous"
+ instructions, which defy better classification.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="i_icmp">'<tt>icmp</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = icmp <cond> <ty> <op1>, <op2> <i>; yields {i1} or {<N x i1>}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>icmp</tt>' instruction returns a boolean value or
+ a vector of boolean values based on comparison
+ of its two integer, integer vector, or pointer operands.</p>
+ <h5>Arguments:</h5>
+ <p>The '<tt>icmp</tt>' instruction takes three operands. The first operand is
+ the condition code indicating the kind of comparison to perform. It is not
+ a value, just a keyword. The possible condition code are:
+ </p>
+ <ol>
+ <li><tt>eq</tt>: equal</li>
+ <li><tt>ne</tt>: not equal </li>
+ <li><tt>ugt</tt>: unsigned greater than</li>
+ <li><tt>uge</tt>: unsigned greater or equal</li>
+ <li><tt>ult</tt>: unsigned less than</li>
+ <li><tt>ule</tt>: unsigned less or equal</li>
+ <li><tt>sgt</tt>: signed greater than</li>
+ <li><tt>sge</tt>: signed greater or equal</li>
+ <li><tt>slt</tt>: signed less than</li>
+ <li><tt>sle</tt>: signed less or equal</li>
+ </ol>
+ <p>The remaining two arguments must be <a href="#t_integer">integer</a> or
+ <a href="#t_pointer">pointer</a>
+ or integer <a href="#t_vector">vector</a> typed.
+ They must also be identical types.</p>
+ <h5>Semantics:</h5>
+ <p>The '<tt>icmp</tt>' compares <tt>op1</tt> and <tt>op2</tt> according to
+ the condition code given as <tt>cond</tt>. The comparison performed always
+ yields either an <a href="#t_primitive"><tt>i1</tt></a> or vector of <tt>i1</tt> result, as follows:
+ </p>
+ <ol>
+ <li><tt>eq</tt>: yields <tt>true</tt> if the operands are equal,
+ <tt>false</tt> otherwise. No sign interpretation is necessary or performed.
+ </li>
+ <li><tt>ne</tt>: yields <tt>true</tt> if the operands are unequal,
+ <tt>false</tt> otherwise. No sign interpretation is necessary or performed.</li>
+ <li><tt>ugt</tt>: interprets the operands as unsigned values and yields
+ <tt>true</tt> if <tt>op1</tt> is greater than <tt>op2</tt>.</li>
+ <li><tt>uge</tt>: interprets the operands as unsigned values and yields
+ <tt>true</tt> if <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
+ <li><tt>ult</tt>: interprets the operands as unsigned values and yields
+ <tt>true</tt> if <tt>op1</tt> is less than <tt>op2</tt>.</li>
+ <li><tt>ule</tt>: interprets the operands as unsigned values and yields
+ <tt>true</tt> if <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
+ <li><tt>sgt</tt>: interprets the operands as signed values and yields
+ <tt>true</tt> if <tt>op1</tt> is greater than <tt>op2</tt>.</li>
+ <li><tt>sge</tt>: interprets the operands as signed values and yields
+ <tt>true</tt> if <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
+ <li><tt>slt</tt>: interprets the operands as signed values and yields
+ <tt>true</tt> if <tt>op1</tt> is less than <tt>op2</tt>.</li>
+ <li><tt>sle</tt>: interprets the operands as signed values and yields
+ <tt>true</tt> if <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
+ </ol>
+ <p>If the operands are <a href="#t_pointer">pointer</a> typed, the pointer
+ values are compared as if they were integers.</p>
+ <p>If the operands are integer vectors, then they are compared
+ element by element. The result is an <tt>i1</tt> vector with
+ the same number of elements as the values being compared.
+ Otherwise, the result is an <tt>i1</tt>.
+ </p>
+
+ <h5>Example:</h5>
+ <pre> <result> = icmp eq i32 4, 5 <i>; yields: result=false</i>
+ <result> = icmp ne float* %X, %X <i>; yields: result=false</i>
+ <result> = icmp ult i16 4, 5 <i>; yields: result=true</i>
+ <result> = icmp sgt i16 4, 5 <i>; yields: result=false</i>
+ <result> = icmp ule i16 -4, 5 <i>; yields: result=false</i>
+ <result> = icmp sge i16 4, 5 <i>; yields: result=false</i>
+ </pre>
+
+ <p>Note that the code generator does not yet support vector types with
+ the <tt>icmp</tt> instruction.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection"><a name="i_fcmp">'<tt>fcmp</tt>' Instruction</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> <result> = fcmp <cond> <ty> <op1>, <op2> <i>; yields {i1} or {<N x i1>}:result</i>
+ </pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>fcmp</tt>' instruction returns a boolean value
+ or vector of boolean values based on comparison
+ of its operands.</p>
+ <p>
+ If the operands are floating point scalars, then the result
+ type is a boolean (<a href="#t_primitive"><tt>i1</tt></a>).
+ </p>
+ <p>If the operands are floating point vectors, then the result type
+ is a vector of boolean with the same number of elements as the
+ operands being compared.</p>
+ <h5>Arguments:</h5>
+ <p>The '<tt>fcmp</tt>' instruction takes three operands. The first operand is
+ the condition code indicating the kind of comparison to perform. It is not
+ a value, just a keyword. The possible condition code are:</p>
+ <ol>
+ <li><tt>false</tt>: no comparison, always returns false</li>
+ <li><tt>oeq</tt>: ordered and equal</li>
+ <li><tt>ogt</tt>: ordered and greater than </li>
+ <li><tt>oge</tt>: ordered and greater than or equal</li>
+ <li><tt>olt</tt>: ordered and less than </li>
+ <li><tt>ole</tt>: ordered and less than or equal</li>
+ <li><tt>one</tt>: ordered and not equal</li>
+ <li><tt>ord</tt>: ordered (no nans)</li>
+ <li><tt>ueq</tt>: unordered or equal</li>
+ <li><tt>ugt</tt>: unordered or greater than </li>
+ <li><tt>uge</tt>: unordered or greater than or equal</li>
+ <li><tt>ult</tt>: unordered or less than </li>
+ <li><tt>ule</tt>: unordered or less than or equal</li>
+ <li><tt>une</tt>: unordered or not equal</li>
+ <li><tt>uno</tt>: unordered (either nans)</li>
+ <li><tt>true</tt>: no comparison, always returns true</li>
+ </ol>
+ <p><i>Ordered</i> means that neither operand is a QNAN while
+ <i>unordered</i> means that either operand may be a QNAN.</p>
+ <p>Each of <tt>val1</tt> and <tt>val2</tt> arguments must be
+ either a <a href="#t_floating">floating point</a> type
+ or a <a href="#t_vector">vector</a> of floating point type.
+ They must have identical types.</p>
+ <h5>Semantics:</h5>
+ <p>The '<tt>fcmp</tt>' instruction compares <tt>op1</tt> and <tt>op2</tt>
+ according to the condition code given as <tt>cond</tt>.
+ If the operands are vectors, then the vectors are compared
+ element by element.
+ Each comparison performed
+ always yields an <a href="#t_primitive">i1</a> result, as follows:</p>
+ <ol>
+ <li><tt>false</tt>: always yields <tt>false</tt>, regardless of operands.</li>
+ <li><tt>oeq</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <tt>op1</tt> is equal to <tt>op2</tt>.</li>
+ <li><tt>ogt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <tt>op1</tt> is greather than <tt>op2</tt>.</li>
+ <li><tt>oge</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
+ <li><tt>olt</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <tt>op1</tt> is less than <tt>op2</tt>.</li>
+ <li><tt>ole</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
+ <li><tt>one</tt>: yields <tt>true</tt> if both operands are not a QNAN and
+ <tt>op1</tt> is not equal to <tt>op2</tt>.</li>
+ <li><tt>ord</tt>: yields <tt>true</tt> if both operands are not a QNAN.</li>
+ <li><tt>ueq</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <tt>op1</tt> is equal to <tt>op2</tt>.</li>
+ <li><tt>ugt</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <tt>op1</tt> is greater than <tt>op2</tt>.</li>
+ <li><tt>uge</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <tt>op1</tt> is greater than or equal to <tt>op2</tt>.</li>
+ <li><tt>ult</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <tt>op1</tt> is less than <tt>op2</tt>.</li>
+ <li><tt>ule</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <tt>op1</tt> is less than or equal to <tt>op2</tt>.</li>
+ <li><tt>une</tt>: yields <tt>true</tt> if either operand is a QNAN or
+ <tt>op1</tt> is not equal to <tt>op2</tt>.</li>
+ <li><tt>uno</tt>: yields <tt>true</tt> if either operand is a QNAN.</li>
+ <li><tt>true</tt>: always yields <tt>true</tt>, regardless of operands.</li>
+ </ol>
+
+ <h5>Example:</h5>
+ <pre> <result> = fcmp oeq float 4.0, 5.0 <i>; yields: result=false</i>
+ <result> = fcmp one float 4.0, 5.0 <i>; yields: result=true</i>
+ <result> = fcmp olt float 4.0, 5.0 <i>; yields: result=true</i>
+ <result> = fcmp ueq double 1.0, 2.0 <i>; yields: result=false</i>
+ </pre>
+
+ <p>Note that the code generator does not yet support vector types with
+ the <tt>fcmp</tt> instruction.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_phi">'<tt>phi</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre> <result> = phi <ty> [ <val0>, <label0>], ...<br></pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>phi</tt>' instruction is used to implement the φ node in
+ the SSA graph representing the function.</p>
+ <h5>Arguments:</h5>
+
+ <p>The type of the incoming values is specified with the first type
+ field. After this, the '<tt>phi</tt>' instruction takes a list of pairs
+ as arguments, with one pair for each predecessor basic block of the
+ current block. Only values of <a href="#t_firstclass">first class</a>
+ type may be used as the value arguments to the PHI node. Only labels
+ may be used as the label arguments.</p>
+
+ <p>There must be no non-phi instructions between the start of a basic
+ block and the PHI instructions: i.e. PHI instructions must be first in
+ a basic block.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>At runtime, the '<tt>phi</tt>' instruction logically takes on the value
+ specified by the pair corresponding to the predecessor basic block that executed
+ just prior to the current block.</p>
+
+ <h5>Example:</h5>
+ <pre>
+ Loop: ; Infinite loop that counts from 0 on up...
+ %indvar = phi i32 [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
+ %nextindvar = add i32 %indvar, 1
+ br label %Loop
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_select">'<tt>select</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <result> = select <i>selty</i> <cond>, <ty> <val1>, <ty> <val2> <i>; yields ty</i>
+
+ <i>selty</i> is either i1 or {<N x i1>}
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>select</tt>' instruction is used to choose one value based on a
+ condition, without branching.
+ </p>
+
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The '<tt>select</tt>' instruction requires an 'i1' value or
+ a vector of 'i1' values indicating the
+ condition, and two values of the same <a href="#t_firstclass">first class</a>
+ type. If the val1/val2 are vectors and
+ the condition is a scalar, then entire vectors are selected, not
+ individual elements.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ If the condition is an i1 and it evaluates to 1, the instruction returns the first
+ value argument; otherwise, it returns the second value argument.
+ </p>
+ <p>
+ If the condition is a vector of i1, then the value arguments must
+ be vectors of the same size, and the selection is done element
+ by element.
+ </p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %X = select i1 true, i8 17, i8 42 <i>; yields i8:17</i>
+ </pre>
+
+ <p>Note that the code generator does not yet support conditions
+ with vector type.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_call">'<tt>call</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = [tail] call [<a href="#callingconv">cconv</a>] [<a href="#paramattrs">ret attrs</a>] <ty> [<fnty>*] <fnptrval>(<function args>) [<a href="#fnattrs">fn attrs</a>]
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>call</tt>' instruction represents a simple function call.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>This instruction requires several arguments:</p>
+
+ <ol>
+ <li>
+ <p>The optional "tail" marker indicates whether the callee function accesses
+ any allocas or varargs in the caller. If the "tail" marker is present, the
+ function call is eligible for tail call optimization. Note that calls may
+ be marked "tail" even if they do not occur before a <a
+ href="#i_ret"><tt>ret</tt></a> instruction.</p>
+ </li>
+ <li>
+ <p>The optional "cconv" marker indicates which <a href="#callingconv">calling
+ convention</a> the call should use. If none is specified, the call defaults
+ to using C calling conventions.</p>
+ </li>
+
+ <li>
+ <p>The optional <a href="#paramattrs">Parameter Attributes</a> list for
+ return values. Only '<tt>zeroext</tt>', '<tt>signext</tt>',
+ and '<tt>inreg</tt>' attributes are valid here.</p>
+ </li>
+
+ <li>
+ <p>'<tt>ty</tt>': the type of the call instruction itself which is also
+ the type of the return value. Functions that return no value are marked
+ <tt><a href="#t_void">void</a></tt>.</p>
+ </li>
+ <li>
+ <p>'<tt>fnty</tt>': shall be the signature of the pointer to function
+ value being invoked. The argument types must match the types implied by
+ this signature. This type can be omitted if the function is not varargs
+ and if the function type does not return a pointer to a function.</p>
+ </li>
+ <li>
+ <p>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to
+ be invoked. In most cases, this is a direct function invocation, but
+ indirect <tt>call</tt>s are just as possible, calling an arbitrary pointer
+ to function value.</p>
+ </li>
+ <li>
+ <p>'<tt>function args</tt>': argument list whose types match the
+ function signature argument types. All arguments must be of
+ <a href="#t_firstclass">first class</a> type. If the function signature
+ indicates the function accepts a variable number of arguments, the extra
+ arguments can be specified.</p>
+ </li>
+ <li>
+ <p>The optional <a href="#fnattrs">function attributes</a> list. Only
+ '<tt>noreturn</tt>', '<tt>nounwind</tt>', '<tt>readonly</tt>' and
+ '<tt>readnone</tt>' attributes are valid here.</p>
+ </li>
+ </ol>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>call</tt>' instruction is used to cause control flow to
+ transfer to a specified function, with its incoming arguments bound to
+ the specified values. Upon a '<tt><a href="#i_ret">ret</a></tt>'
+ instruction in the called function, control flow continues with the
+ instruction after the function call, and the return value of the
+ function is bound to the result argument.</p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ %retval = call i32 @test(i32 %argc)
+ call i32 (i8 *, ...)* @printf(i8 * %msg, i32 12, i8 42) <i>; yields i32</i>
+ %X = tail call i32 @foo() <i>; yields i32</i>
+ %Y = tail call <a href="#callingconv">fastcc</a> i32 @foo() <i>; yields i32</i>
+ call void %foo(i8 97 signext)
+
+ %struct.A = type { i32, i8 }
+ %r = call %struct.A @foo() <i>; yields { 32, i8 }</i>
+ %gr = extractvalue %struct.A %r, 0 <i>; yields i32</i>
+ %gr1 = extractvalue %struct.A %r, 1 <i>; yields i8</i>
+ %Z = call void @foo() noreturn <i>; indicates that %foo never returns normally</i>
+ %ZZ = call zeroext i32 @bar() <i>; Return value is %zero extended</i>
+ </pre>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="i_va_arg">'<tt>va_arg</tt>' Instruction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ <resultval> = va_arg <va_list*> <arglist>, <argty>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>va_arg</tt>' instruction is used to access arguments passed through
+ the "variable argument" area of a function call. It is used to implement the
+ <tt>va_arg</tt> macro in C.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>This instruction takes a <tt>va_list*</tt> value and the type of
+ the argument. It returns a value of the specified argument type and
+ increments the <tt>va_list</tt> to point to the next argument. The
+ actual type of <tt>va_list</tt> is target specific.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>va_arg</tt>' instruction loads an argument of the specified
+ type from the specified <tt>va_list</tt> and causes the
+ <tt>va_list</tt> to point to the next argument. For more information,
+ see the variable argument handling <a href="#int_varargs">Intrinsic
+ Functions</a>.</p>
+
+ <p>It is legal for this instruction to be called in a function which does not
+ take a variable number of arguments, for example, the <tt>vfprintf</tt>
+ function.</p>
+
+ <p><tt>va_arg</tt> is an LLVM instruction instead of an <a
+ href="#intrinsics">intrinsic function</a> because it takes a type as an
+ argument.</p>
+
+ <h5>Example:</h5>
+
+ <p>See the <a href="#int_varargs">variable argument processing</a> section.</p>
+
+ <p>Note that the code generator does not yet fully support va_arg
+ on many targets. Also, it does not currently support va_arg with
+ aggregate types on any target.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"> <a name="intrinsics">Intrinsic Functions</a> </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM supports the notion of an "intrinsic function". These functions have
+ well known names and semantics and are required to follow certain restrictions.
+ Overall, these intrinsics represent an extension mechanism for the LLVM
+ language that does not require changing all of the transformations in LLVM when
+ adding to the language (or the bitcode reader/writer, the parser, etc...).</p>
+
+ <p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This
+ prefix is reserved in LLVM for intrinsic names; thus, function names may not
+ begin with this prefix. Intrinsic functions must always be external functions:
+ you cannot define the body of intrinsic functions. Intrinsic functions may
+ only be used in call or invoke instructions: it is illegal to take the address
+ of an intrinsic function. Additionally, because intrinsic functions are part
+ of the LLVM language, it is required if any are added that they be documented
+ here.</p>
+
+ <p>Some intrinsic functions can be overloaded, i.e., the intrinsic represents
+ a family of functions that perform the same operation but on different data
+ types. Because LLVM can represent over 8 million different integer types,
+ overloading is used commonly to allow an intrinsic function to operate on any
+ integer type. One or more of the argument types or the result type can be
+ overloaded to accept any integer type. Argument types may also be defined as
+ exactly matching a previous argument's type or the result type. This allows an
+ intrinsic function which accepts multiple arguments, but needs all of them to
+ be of the same type, to only be overloaded with respect to a single argument or
+ the result.</p>
+
+ <p>Overloaded intrinsics will have the names of its overloaded argument types
+ encoded into its function name, each preceded by a period. Only those types
+ which are overloaded result in a name suffix. Arguments whose type is matched
+ against another type do not. For example, the <tt>llvm.ctpop</tt> function can
+ take an integer of any width and returns an integer of exactly the same integer
+ width. This leads to a family of functions such as
+ <tt>i8 @llvm.ctpop.i8(i8 %val)</tt> and <tt>i29 @llvm.ctpop.i29(i29 %val)</tt>.
+ Only one type, the return type, is overloaded, and only one type suffix is
+ required. Because the argument's type is matched against the return type, it
+ does not require its own name suffix.</p>
+
+ <p>To learn how to add an intrinsic function, please see the
+ <a href="ExtendingLLVM.html">Extending LLVM Guide</a>.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_varargs">Variable Argument Handling Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Variable argument support is defined in LLVM with the <a
+ href="#i_va_arg"><tt>va_arg</tt></a> instruction and these three
+ intrinsic functions. These functions are related to the similarly
+ named macros defined in the <tt><stdarg.h></tt> header file.</p>
+
+ <p>All of these functions operate on arguments that use a
+ target-specific value type "<tt>va_list</tt>". The LLVM assembly
+ language reference manual does not define what this type is, so all
+ transformations should be prepared to handle these functions regardless of
+ the type used.</p>
+
+ <p>This example shows how the <a href="#i_va_arg"><tt>va_arg</tt></a>
+ instruction and the variable argument handling intrinsic functions are
+ used.</p>
+
+ <div class="doc_code">
+ <pre>
+ define i32 @test(i32 %X, ...) {
+ ; Initialize variable argument processing
+ %ap = alloca i8*
+ %ap2 = bitcast i8** %ap to i8*
+ call void @llvm.va_start(i8* %ap2)
+
+ ; Read a single integer argument
+ %tmp = va_arg i8** %ap, i32
+
+ ; Demonstrate usage of llvm.va_copy and llvm.va_end
+ %aq = alloca i8*
+ %aq2 = bitcast i8** %aq to i8*
+ call void @llvm.va_copy(i8* %aq2, i8* %ap2)
+ call void @llvm.va_end(i8* %aq2)
+
+ ; Stop processing of arguments.
+ call void @llvm.va_end(i8* %ap2)
+ ret i32 %tmp
+ }
+
+ declare void @llvm.va_start(i8*)
+ declare void @llvm.va_copy(i8*, i8*)
+ declare void @llvm.va_end(i8*)
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
+ </div>
+
+
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> declare void %llvm.va_start(i8* <arglist>)<br></pre>
+ <h5>Overview:</h5>
+ <p>The '<tt>llvm.va_start</tt>' intrinsic initializes
+ <tt>*<arglist></tt> for subsequent use by <tt><a
+ href="#i_va_arg">va_arg</a></tt>.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The argument is a pointer to a <tt>va_list</tt> element to initialize.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>llvm.va_start</tt>' intrinsic works just like the <tt>va_start</tt>
+ macro available in C. In a target-dependent way, it initializes the
+ <tt>va_list</tt> element to which the argument points, so that the next call to
+ <tt>va_arg</tt> will produce the first variable argument passed to the function.
+ Unlike the C <tt>va_start</tt> macro, this intrinsic does not need to know the
+ last argument of the function as the compiler can figure that out.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_va_end">'<tt>llvm.va_end</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre> declare void @llvm.va_end(i8* <arglist>)<br></pre>
+ <h5>Overview:</h5>
+
+ <p>The '<tt>llvm.va_end</tt>' intrinsic destroys <tt>*<arglist></tt>,
+ which has been initialized previously with <tt><a href="#int_va_start">llvm.va_start</a></tt>
+ or <tt><a href="#i_va_copy">llvm.va_copy</a></tt>.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The argument is a pointer to a <tt>va_list</tt> to destroy.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>llvm.va_end</tt>' intrinsic works just like the <tt>va_end</tt>
+ macro available in C. In a target-dependent way, it destroys the
+ <tt>va_list</tt> element to which the argument points. Calls to <a
+ href="#int_va_start"><tt>llvm.va_start</tt></a> and <a href="#int_va_copy">
+ <tt>llvm.va_copy</tt></a> must be matched exactly with calls to
+ <tt>llvm.va_end</tt>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ declare void @llvm.va_copy(i8* <destarglist>, i8* <srcarglist>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>llvm.va_copy</tt>' intrinsic copies the current argument position
+ from the source argument list to the destination argument list.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The first argument is a pointer to a <tt>va_list</tt> element to initialize.
+ The second argument is a pointer to a <tt>va_list</tt> element to copy from.</p>
+
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>llvm.va_copy</tt>' intrinsic works just like the <tt>va_copy</tt>
+ macro available in C. In a target-dependent way, it copies the source
+ <tt>va_list</tt> element into the destination <tt>va_list</tt> element. This
+ intrinsic is necessary because the <tt><a href="#int_va_start">
+ llvm.va_start</a></tt> intrinsic may be arbitrarily complex and require, for
+ example, memory allocation.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_gc">Accurate Garbage Collection Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ LLVM support for <a href="GarbageCollection.html">Accurate Garbage
+ Collection</a> (GC) requires the implementation and generation of these
+ intrinsics.
+ These intrinsics allow identification of <a href="#int_gcroot">GC roots on the
+ stack</a>, as well as garbage collector implementations that require <a
+ href="#int_gcread">read</a> and <a href="#int_gcwrite">write</a> barriers.
+ Front-ends for type-safe garbage collected languages should generate these
+ intrinsics to make use of the LLVM garbage collectors. For more details, see <a
+ href="GarbageCollection.html">Accurate Garbage Collection with LLVM</a>.
+ </p>
+
+ <p>The garbage collection intrinsics only operate on objects in the generic
+ address space (address space zero).</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_gcroot">'<tt>llvm.gcroot</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>llvm.gcroot</tt>' intrinsic declares the existence of a GC root to
+ the code generator, and allows some metadata to be associated with it.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The first argument specifies the address of a stack object that contains the
+ root pointer. The second pointer (which must be either a constant or a global
+ value address) contains the meta-data to be associated with the root.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>At runtime, a call to this intrinsic stores a null pointer into the "ptrloc"
+ location. At compile-time, the code generator generates information to allow
+ the runtime to find the pointer at GC safe points. The '<tt>llvm.gcroot</tt>'
+ intrinsic may only be used in a function which <a href="#gc">specifies a GC
+ algorithm</a>.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_gcread">'<tt>llvm.gcread</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ declare i8* @llvm.gcread(i8* %ObjPtr, i8** %Ptr)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>llvm.gcread</tt>' intrinsic identifies reads of references from heap
+ locations, allowing garbage collector implementations that require read
+ barriers.</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The second argument is the address to read from, which should be an address
+ allocated from the garbage collector. The first object is a pointer to the
+ start of the referenced object, if needed by the language runtime (otherwise
+ null).</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>llvm.gcread</tt>' intrinsic has the same semantics as a load
+ instruction, but may be replaced with substantially more complex code by the
+ garbage collector runtime, as needed. The '<tt>llvm.gcread</tt>' intrinsic
+ may only be used in a function which <a href="#gc">specifies a GC
+ algorithm</a>.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_gcwrite">'<tt>llvm.gcwrite</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+
+ <pre>
+ declare void @llvm.gcwrite(i8* %P1, i8* %Obj, i8** %P2)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>The '<tt>llvm.gcwrite</tt>' intrinsic identifies writes of references to heap
+ locations, allowing garbage collector implementations that require write
+ barriers (such as generational or reference counting collectors).</p>
+
+ <h5>Arguments:</h5>
+
+ <p>The first argument is the reference to store, the second is the start of the
+ object to store it to, and the third is the address of the field of Obj to
+ store to. If the runtime does not require a pointer to the object, Obj may be
+ null.</p>
+
+ <h5>Semantics:</h5>
+
+ <p>The '<tt>llvm.gcwrite</tt>' intrinsic has the same semantics as a store
+ instruction, but may be replaced with substantially more complex code by the
+ garbage collector runtime, as needed. The '<tt>llvm.gcwrite</tt>' intrinsic
+ may only be used in a function which <a href="#gc">specifies a GC
+ algorithm</a>.</p>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_codegen">Code Generator Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ These intrinsics are provided by LLVM to expose special features that may only
+ be implemented with code generator support.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare i8 *@llvm.returnaddress(i32 <level>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.returnaddress</tt>' intrinsic attempts to compute a
+ target-specific value indicating the return address of the current function
+ or one of its callers.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The argument to this intrinsic indicates which function to return the address
+ for. Zero indicates the calling function, one indicates its caller, etc. The
+ argument is <b>required</b> to be a constant integer value.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer indicating
+ the return address of the specified call frame, or zero if it cannot be
+ identified. The value returned by this intrinsic is likely to be incorrect or 0
+ for arguments other than zero, so it should only be used for debugging purposes.
+ </p>
+
+ <p>
+ Note that calling this intrinsic does not prevent function inlining or other
+ aggressive transformations, so the value returned may not be that of the obvious
+ source-language caller.
+ </p>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare i8 *@llvm.frameaddress(i32 <level>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.frameaddress</tt>' intrinsic attempts to return the
+ target-specific frame pointer value for the specified stack frame.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The argument to this intrinsic indicates which function to return the frame
+ pointer for. Zero indicates the calling function, one indicates its caller,
+ etc. The argument is <b>required</b> to be a constant integer value.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer indicating
+ the frame address of the specified call frame, or zero if it cannot be
+ identified. The value returned by this intrinsic is likely to be incorrect or 0
+ for arguments other than zero, so it should only be used for debugging purposes.
+ </p>
+
+ <p>
+ Note that calling this intrinsic does not prevent function inlining or other
+ aggressive transformations, so the value returned may not be that of the obvious
+ source-language caller.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_stacksave">'<tt>llvm.stacksave</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare i8 *@llvm.stacksave()
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.stacksave</tt>' intrinsic is used to remember the current state of
+ the function stack, for use with <a href="#int_stackrestore">
+ <tt>llvm.stackrestore</tt></a>. This is useful for implementing language
+ features like scoped automatic variable sized arrays in C99.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This intrinsic returns a opaque pointer value that can be passed to <a
+ href="#int_stackrestore"><tt>llvm.stackrestore</tt></a>. When an
+ <tt>llvm.stackrestore</tt> intrinsic is executed with a value saved from
+ <tt>llvm.stacksave</tt>, it effectively restores the state of the stack to the
+ state it was in when the <tt>llvm.stacksave</tt> intrinsic executed. In
+ practice, this pops any <a href="#i_alloca">alloca</a> blocks from the stack
+ that were allocated after the <tt>llvm.stacksave</tt> was executed.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_stackrestore">'<tt>llvm.stackrestore</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.stackrestore(i8 * %ptr)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.stackrestore</tt>' intrinsic is used to restore the state of
+ the function stack to the state it was in when the corresponding <a
+ href="#int_stacksave"><tt>llvm.stacksave</tt></a> intrinsic executed. This is
+ useful for implementing language features like scoped automatic variable sized
+ arrays in C99.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ See the description for <a href="#int_stacksave"><tt>llvm.stacksave</tt></a>.
+ </p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_prefetch">'<tt>llvm.prefetch</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+
+ <p>
+ The '<tt>llvm.prefetch</tt>' intrinsic is a hint to the code generator to insert
+ a prefetch instruction if supported; otherwise, it is a noop. Prefetches have
+ no
+ effect on the behavior of the program but can change its performance
+ characteristics.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ <tt>address</tt> is the address to be prefetched, <tt>rw</tt> is the specifier
+ determining if the fetch should be for a read (0) or write (1), and
+ <tt>locality</tt> is a temporal locality specifier ranging from (0) - no
+ locality, to (3) - extremely local keep in cache. The <tt>rw</tt> and
+ <tt>locality</tt> arguments must be constant integers.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This intrinsic does not modify the behavior of the program. In particular,
+ prefetches cannot trap and do not produce a value. On targets that support this
+ intrinsic, the prefetch can provide hints to the processor cache for better
+ performance.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_pcmarker">'<tt>llvm.pcmarker</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.pcmarker(i32 <id>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+
+ <p>
+ The '<tt>llvm.pcmarker</tt>' intrinsic is a method to export a Program Counter
+ (PC) in a region of
+ code to simulators and other tools. The method is target specific, but it is
+ expected that the marker will use exported symbols to transmit the PC of the
+ marker.
+ The marker makes no guarantees that it will remain with any specific instruction
+ after optimizations. It is possible that the presence of a marker will inhibit
+ optimizations. The intended use is to be inserted after optimizations to allow
+ correlations of simulation runs.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ <tt>id</tt> is a numerical id identifying the marker.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This intrinsic does not modify the behavior of the program. Backends that do not
+ support this intrinisic may ignore it.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_readcyclecounter">'<tt>llvm.readcyclecounter</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare i64 @llvm.readcyclecounter( )
+ </pre>
+
+ <h5>Overview:</h5>
+
+
+ <p>
+ The '<tt>llvm.readcyclecounter</tt>' intrinsic provides access to the cycle
+ counter register (or similar low latency, high accuracy clocks) on those targets
+ that support it. On X86, it should map to RDTSC. On Alpha, it should map to RPCC.
+ As the backing counters overflow quickly (on the order of 9 seconds on alpha), this
+ should only be used for small timings.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ When directly supported, reading the cycle counter should not modify any memory.
+ Implementations are allowed to either return a application specific value or a
+ system wide value. On backends without support, this is lowered to a constant 0.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_libc">Standard C Library Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ LLVM provides intrinsics for a few important standard C library functions.
+ These intrinsics allow source-language front-ends to pass information about the
+ alignment of the pointer arguments to the code generator, providing opportunity
+ for more efficient code generation.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use llvm.memcpy on any integer bit
+ width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare void @llvm.memcpy.i8(i8 * <dest>, i8 * <src>,
+ i8 <len>, i32 <align>)
+ declare void @llvm.memcpy.i16(i8 * <dest>, i8 * <src>,
+ i16 <len>, i32 <align>)
+ declare void @llvm.memcpy.i32(i8 * <dest>, i8 * <src>,
+ i32 <len>, i32 <align>)
+ declare void @llvm.memcpy.i64(i8 * <dest>, i8 * <src>,
+ i64 <len>, i32 <align>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the source
+ location to the destination location.
+ </p>
+
+ <p>
+ Note that, unlike the standard libc function, the <tt>llvm.memcpy.*</tt>
+ intrinsics do not return a value, and takes an extra alignment argument.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first argument is a pointer to the destination, the second is a pointer to
+ the source. The third argument is an integer argument
+ specifying the number of bytes to copy, and the fourth argument is the alignment
+ of the source and destination locations.
+ </p>
+
+ <p>
+ If the call to this intrinisic has an alignment value that is not 0 or 1, then
+ the caller guarantees that both the source and destination pointers are aligned
+ to that boundary.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.memcpy.*</tt>' intrinsics copy a block of memory from the source
+ location to the destination location, which are not allowed to overlap. It
+ copies "len" bytes of memory over. If the argument is known to be aligned to
+ some boundary, this can be specified as the fourth argument, otherwise it should
+ be set to 0 or 1.
+ </p>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use llvm.memmove on any integer bit
+ width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare void @llvm.memmove.i8(i8 * <dest>, i8 * <src>,
+ i8 <len>, i32 <align>)
+ declare void @llvm.memmove.i16(i8 * <dest>, i8 * <src>,
+ i16 <len>, i32 <align>)
+ declare void @llvm.memmove.i32(i8 * <dest>, i8 * <src>,
+ i32 <len>, i32 <align>)
+ declare void @llvm.memmove.i64(i8 * <dest>, i8 * <src>,
+ i64 <len>, i32 <align>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.memmove.*</tt>' intrinsics move a block of memory from the source
+ location to the destination location. It is similar to the
+ '<tt>llvm.memcpy</tt>' intrinsic but allows the two memory locations to overlap.
+ </p>
+
+ <p>
+ Note that, unlike the standard libc function, the <tt>llvm.memmove.*</tt>
+ intrinsics do not return a value, and takes an extra alignment argument.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first argument is a pointer to the destination, the second is a pointer to
+ the source. The third argument is an integer argument
+ specifying the number of bytes to copy, and the fourth argument is the alignment
+ of the source and destination locations.
+ </p>
+
+ <p>
+ If the call to this intrinisic has an alignment value that is not 0 or 1, then
+ the caller guarantees that the source and destination pointers are aligned to
+ that boundary.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.memmove.*</tt>' intrinsics copy a block of memory from the source
+ location to the destination location, which may overlap. It
+ copies "len" bytes of memory over. If the argument is known to be aligned to
+ some boundary, this can be specified as the fourth argument, otherwise it should
+ be set to 0 or 1.
+ </p>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_memset">'<tt>llvm.memset.*</tt>' Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use llvm.memset on any integer bit
+ width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare void @llvm.memset.i8(i8 * <dest>, i8 <val>,
+ i8 <len>, i32 <align>)
+ declare void @llvm.memset.i16(i8 * <dest>, i8 <val>,
+ i16 <len>, i32 <align>)
+ declare void @llvm.memset.i32(i8 * <dest>, i8 <val>,
+ i32 <len>, i32 <align>)
+ declare void @llvm.memset.i64(i8 * <dest>, i8 <val>,
+ i64 <len>, i32 <align>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.memset.*</tt>' intrinsics fill a block of memory with a particular
+ byte value.
+ </p>
+
+ <p>
+ Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic
+ does not return a value, and takes an extra alignment argument.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first argument is a pointer to the destination to fill, the second is the
+ byte value to fill it with, the third argument is an integer
+ argument specifying the number of bytes to fill, and the fourth argument is the
+ known alignment of destination location.
+ </p>
+
+ <p>
+ If the call to this intrinisic has an alignment value that is not 0 or 1, then
+ the caller guarantees that the destination pointer is aligned to that boundary.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.memset.*</tt>' intrinsics fill "len" bytes of memory starting at
+ the
+ destination location. If the argument is known to be aligned to some boundary,
+ this can be specified as the fourth argument, otherwise it should be set to 0 or
+ 1.
+ </p>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_sqrt">'<tt>llvm.sqrt.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.sqrt</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+ <pre>
+ declare float @llvm.sqrt.f32(float %Val)
+ declare double @llvm.sqrt.f64(double %Val)
+ declare x86_fp80 @llvm.sqrt.f80(x86_fp80 %Val)
+ declare fp128 @llvm.sqrt.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.sqrt.ppcf128(ppc_fp128 %Val)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.sqrt</tt>' intrinsics return the sqrt of the specified operand,
+ returning the same value as the libm '<tt>sqrt</tt>' functions would. Unlike
+ <tt>sqrt</tt> in libm, however, <tt>llvm.sqrt</tt> has undefined behavior for
+ negative numbers other than -0.0 (which allows for better optimization, because
+ there is no need to worry about errno being set). <tt>llvm.sqrt(-0.0)</tt> is
+ defined to return -0.0 like IEEE sqrt.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The argument and return value are floating point numbers of the same type.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This function returns the sqrt of the specified operand if it is a nonnegative
+ floating point number.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_powi">'<tt>llvm.powi.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.powi</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+ <pre>
+ declare float @llvm.powi.f32(float %Val, i32 %power)
+ declare double @llvm.powi.f64(double %Val, i32 %power)
+ declare x86_fp80 @llvm.powi.f80(x86_fp80 %Val, i32 %power)
+ declare fp128 @llvm.powi.f128(fp128 %Val, i32 %power)
+ declare ppc_fp128 @llvm.powi.ppcf128(ppc_fp128 %Val, i32 %power)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.powi.*</tt>' intrinsics return the first operand raised to the
+ specified (positive or negative) power. The order of evaluation of
+ multiplications is not defined. When a vector of floating point type is
+ used, the second argument remains a scalar integer value.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The second argument is an integer power, and the first is a value to raise to
+ that power.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This function returns the first value raised to the second power with an
+ unspecified sequence of rounding operations.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_sin">'<tt>llvm.sin.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.sin</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+ <pre>
+ declare float @llvm.sin.f32(float %Val)
+ declare double @llvm.sin.f64(double %Val)
+ declare x86_fp80 @llvm.sin.f80(x86_fp80 %Val)
+ declare fp128 @llvm.sin.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.sin.ppcf128(ppc_fp128 %Val)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.sin.*</tt>' intrinsics return the sine of the operand.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The argument and return value are floating point numbers of the same type.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This function returns the sine of the specified operand, returning the
+ same values as the libm <tt>sin</tt> functions would, and handles error
+ conditions in the same way.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_cos">'<tt>llvm.cos.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.cos</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+ <pre>
+ declare float @llvm.cos.f32(float %Val)
+ declare double @llvm.cos.f64(double %Val)
+ declare x86_fp80 @llvm.cos.f80(x86_fp80 %Val)
+ declare fp128 @llvm.cos.f128(fp128 %Val)
+ declare ppc_fp128 @llvm.cos.ppcf128(ppc_fp128 %Val)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.cos.*</tt>' intrinsics return the cosine of the operand.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The argument and return value are floating point numbers of the same type.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This function returns the cosine of the specified operand, returning the
+ same values as the libm <tt>cos</tt> functions would, and handles error
+ conditions in the same way.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_pow">'<tt>llvm.pow.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.pow</tt> on any
+ floating point or vector of floating point type. Not all targets support all
+ types however.</p>
+ <pre>
+ declare float @llvm.pow.f32(float %Val, float %Power)
+ declare double @llvm.pow.f64(double %Val, double %Power)
+ declare x86_fp80 @llvm.pow.f80(x86_fp80 %Val, x86_fp80 %Power)
+ declare fp128 @llvm.pow.f128(fp128 %Val, fp128 %Power)
+ declare ppc_fp128 @llvm.pow.ppcf128(ppc_fp128 %Val, ppc_fp128 Power)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.pow.*</tt>' intrinsics return the first operand raised to the
+ specified (positive or negative) power.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The second argument is a floating point power, and the first is a value to
+ raise to that power.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This function returns the first value raised to the second power,
+ returning the
+ same values as the libm <tt>pow</tt> functions would, and handles error
+ conditions in the same way.</p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_manip">Bit Manipulation Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ LLVM provides intrinsics for a few important bit manipulation operations.
+ These allow efficient code generation for some algorithms.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_bswap">'<tt>llvm.bswap.*</tt>' Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic function. You can use bswap on any integer
+ type that is an even number of bytes (i.e. BitWidth % 16 == 0).</p>
+ <pre>
+ declare i16 @llvm.bswap.i16(i16 <id>)
+ declare i32 @llvm.bswap.i32(i32 <id>)
+ declare i64 @llvm.bswap.i64(i64 <id>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.bswap</tt>' family of intrinsics is used to byte swap integer
+ values with an even number of bytes (positive multiple of 16 bits). These are
+ useful for performing operations on data that is not in the target's native
+ byte order.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The <tt>llvm.bswap.i16</tt> intrinsic returns an i16 value that has the high
+ and low byte of the input i16 swapped. Similarly, the <tt>llvm.bswap.i32</tt>
+ intrinsic returns an i32 value that has the four bytes of the input i32
+ swapped, so that if the input bytes are numbered 0, 1, 2, 3 then the returned
+ i32 will have its bytes in 3, 2, 1, 0 order. The <tt>llvm.bswap.i48</tt>,
+ <tt>llvm.bswap.i64</tt> and other intrinsics extend this concept to
+ additional even-byte lengths (6 bytes, 8 bytes and more, respectively).
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_ctpop">'<tt>llvm.ctpop.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit
+ width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.ctpop.i8 (i8 <src>)
+ declare i16 @llvm.ctpop.i16(i16 <src>)
+ declare i32 @llvm.ctpop.i32(i32 <src>)
+ declare i64 @llvm.ctpop.i64(i64 <src>)
+ declare i256 @llvm.ctpop.i256(i256 <src>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.ctpop</tt>' family of intrinsics counts the number of bits set in a
+ value.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The only argument is the value to be counted. The argument may be of any
+ integer type. The return type must match the argument type.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.ctpop</tt>' intrinsic counts the 1's in a variable.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_ctlz">'<tt>llvm.ctlz.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.ctlz</tt> on any
+ integer bit width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.ctlz.i8 (i8 <src>)
+ declare i16 @llvm.ctlz.i16(i16 <src>)
+ declare i32 @llvm.ctlz.i32(i32 <src>)
+ declare i64 @llvm.ctlz.i64(i64 <src>)
+ declare i256 @llvm.ctlz.i256(i256 <src>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.ctlz</tt>' family of intrinsic functions counts the number of
+ leading zeros in a variable.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The only argument is the value to be counted. The argument may be of any
+ integer type. The return type must match the argument type.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.ctlz</tt>' intrinsic counts the leading (most significant) zeros
+ in a variable. If the src == 0 then the result is the size in bits of the type
+ of src. For example, <tt>llvm.ctlz(i32 2) = 30</tt>.
+ </p>
+ </div>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_cttz">'<tt>llvm.cttz.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.cttz</tt> on any
+ integer bit width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.cttz.i8 (i8 <src>)
+ declare i16 @llvm.cttz.i16(i16 <src>)
+ declare i32 @llvm.cttz.i32(i32 <src>)
+ declare i64 @llvm.cttz.i64(i64 <src>)
+ declare i256 @llvm.cttz.i256(i256 <src>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.cttz</tt>' family of intrinsic functions counts the number of
+ trailing zeros.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The only argument is the value to be counted. The argument may be of any
+ integer type. The return type must match the argument type.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ The '<tt>llvm.cttz</tt>' intrinsic counts the trailing (least significant) zeros
+ in a variable. If the src == 0 then the result is the size in bits of the type
+ of src. For example, <tt>llvm.cttz(2) = 1</tt>.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_part_select">'<tt>llvm.part.select.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.part.select</tt>
+ on any integer bit width.</p>
+ <pre>
+ declare i17 @llvm.part.select.i17 (i17 %val, i32 %loBit, i32 %hiBit)
+ declare i29 @llvm.part.select.i29 (i29 %val, i32 %loBit, i32 %hiBit)
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>llvm.part.select</tt>' family of intrinsic functions selects a
+ range of bits from an integer value and returns them in the same bit width as
+ the original value.</p>
+
+ <h5>Arguments:</h5>
+ <p>The first argument, <tt>%val</tt> and the result may be integer types of
+ any bit width but they must have the same bit width. The second and third
+ arguments must be <tt>i32</tt> type since they specify only a bit index.</p>
+
+ <h5>Semantics:</h5>
+ <p>The operation of the '<tt>llvm.part.select</tt>' intrinsic has two modes
+ of operation: forwards and reverse. If <tt>%loBit</tt> is greater than
+ <tt>%hiBits</tt> then the intrinsic operates in reverse mode. Otherwise it
+ operates in forward mode.</p>
+ <p>In forward mode, this intrinsic is the equivalent of shifting <tt>%val</tt>
+ right by <tt>%loBit</tt> bits and then ANDing it with a mask with
+ only the <tt>%hiBit - %loBit</tt> bits set, as follows:</p>
+ <ol>
+ <li>The <tt>%val</tt> is shifted right (LSHR) by the number of bits specified
+ by <tt>%loBits</tt>. This normalizes the value to the low order bits.</li>
+ <li>The <tt>%loBits</tt> value is subtracted from the <tt>%hiBits</tt> value
+ to determine the number of bits to retain.</li>
+ <li>A mask of the retained bits is created by shifting a -1 value.</li>
+ <li>The mask is ANDed with <tt>%val</tt> to produce the result.</li>
+ </ol>
+ <p>In reverse mode, a similar computation is made except that the bits are
+ returned in the reverse order. So, for example, if <tt>X</tt> has the value
+ <tt>i16 0x0ACF (101011001111)</tt> and we apply
+ <tt>part.select(i16 X, 8, 3)</tt> to it, we get back the value
+ <tt>i16 0x0026 (000000100110)</tt>.</p>
+ </div>
+
+ <div class="doc_subsubsection">
+ <a name="int_part_set">'<tt>llvm.part.set.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use <tt>llvm.part.set</tt>
+ on any integer bit width.</p>
+ <pre>
+ declare i17 @llvm.part.set.i17.i9 (i17 %val, i9 %repl, i32 %lo, i32 %hi)
+ declare i29 @llvm.part.set.i29.i9 (i29 %val, i9 %repl, i32 %lo, i32 %hi)
+ </pre>
+
+ <h5>Overview:</h5>
+ <p>The '<tt>llvm.part.set</tt>' family of intrinsic functions replaces a range
+ of bits in an integer value with another integer value. It returns the integer
+ with the replaced bits.</p>
+
+ <h5>Arguments:</h5>
+ <p>The first argument, <tt>%val</tt> and the result may be integer types of
+ any bit width but they must have the same bit width. <tt>%val</tt> is the value
+ whose bits will be replaced. The second argument, <tt>%repl</tt> may be an
+ integer of any bit width. The third and fourth arguments must be <tt>i32</tt>
+ type since they specify only a bit index.</p>
+
+ <h5>Semantics:</h5>
+ <p>The operation of the '<tt>llvm.part.set</tt>' intrinsic has two modes
+ of operation: forwards and reverse. If <tt>%lo</tt> is greater than
+ <tt>%hi</tt> then the intrinsic operates in reverse mode. Otherwise it
+ operates in forward mode.</p>
+ <p>For both modes, the <tt>%repl</tt> value is prepared for use by either
+ truncating it down to the size of the replacement area or zero extending it
+ up to that size.</p>
+ <p>In forward mode, the bits between <tt>%lo</tt> and <tt>%hi</tt> (inclusive)
+ are replaced with corresponding bits from <tt>%repl</tt>. That is the 0th bit
+ in <tt>%repl</tt> replaces the <tt>%lo</tt>th bit in <tt>%val</tt> and etc. up
+ to the <tt>%hi</tt>th bit.</p>
+ <p>In reverse mode, a similar computation is made except that the bits are
+ reversed. That is, the <tt>0</tt>th bit in <tt>%repl</tt> replaces the
+ <tt>%hi</tt> bit in <tt>%val</tt> and etc. down to the <tt>%lo</tt>th bit.</p>
+ <h5>Examples:</h5>
+ <pre>
+ llvm.part.set(0xFFFF, 0, 4, 7) -> 0xFF0F
+ llvm.part.set(0xFFFF, 0, 7, 4) -> 0xFF0F
+ llvm.part.set(0xFFFF, 1, 7, 4) -> 0xFF8F
+ llvm.part.set(0xFFFF, F, 8, 3) -> 0xFFE7
+ llvm.part.set(0xFFFF, 0, 3, 8) -> 0xFE07
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_debugger">Debugger Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The LLVM debugger intrinsics (which all start with <tt>llvm.dbg.</tt> prefix),
+ are described in the <a
+ href="SourceLevelDebugging.html#format_common_intrinsics">LLVM Source Level
+ Debugging</a> document.
+ </p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_eh">Exception Handling Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p> The LLVM exception handling intrinsics (which all start with
+ <tt>llvm.eh.</tt> prefix), are described in the <a
+ href="ExceptionHandling.html#format_common_intrinsics">LLVM Exception
+ Handling</a> document. </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_trampoline">Trampoline Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ This intrinsic makes it possible to excise one parameter, marked with
+ the <tt>nest</tt> attribute, from a function. The result is a callable
+ function pointer lacking the nest parameter - the caller does not need
+ to provide a value for it. Instead, the value to use is stored in
+ advance in a "trampoline", a block of memory usually allocated
+ on the stack, which also contains code to splice the nest value into the
+ argument list. This is used to implement the GCC nested function address
+ extension.
+ </p>
+ <p>
+ For example, if the function is
+ <tt>i32 f(i8* nest %c, i32 %x, i32 %y)</tt> then the resulting function
+ pointer has signature <tt>i32 (i32, i32)*</tt>. It can be created as follows:</p>
+ <pre>
+ %tramp = alloca [10 x i8], align 4 ; size and alignment only correct for X86
+ %tramp1 = getelementptr [10 x i8]* %tramp, i32 0, i32 0
+ %p = call i8* @llvm.init.trampoline( i8* %tramp1, i8* bitcast (i32 (i8* nest , i32, i32)* @f to i8*), i8* %nval )
+ %fp = bitcast i8* %p to i32 (i32, i32)*
+ </pre>
+ <p>The call <tt>%val = call i32 %fp( i32 %x, i32 %y )</tt> is then equivalent
+ to <tt>%val = call i32 %f( i8* %nval, i32 %x, i32 %y )</tt>.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_it">'<tt>llvm.init.trampoline</tt>' Intrinsic</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ declare i8* @llvm.init.trampoline(i8* <tramp>, i8* <func>, i8* <nval>)
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ This fills the memory pointed to by <tt>tramp</tt> with code
+ and returns a function pointer suitable for executing it.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+ The <tt>llvm.init.trampoline</tt> intrinsic takes three arguments, all
+ pointers. The <tt>tramp</tt> argument must point to a sufficiently large
+ and sufficiently aligned block of memory; this memory is written to by the
+ intrinsic. Note that the size and the alignment are target-specific - LLVM
+ currently provides no portable way of determining them, so a front-end that
+ generates this intrinsic needs to have some target-specific knowledge.
+ The <tt>func</tt> argument must hold a function bitcast to an <tt>i8*</tt>.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ The block of memory pointed to by <tt>tramp</tt> is filled with target
+ dependent code, turning it into a function. A pointer to this function is
+ returned, but needs to be bitcast to an
+ <a href="#int_trampoline">appropriate function pointer type</a>
+ before being called. The new function's signature is the same as that of
+ <tt>func</tt> with any arguments marked with the <tt>nest</tt> attribute
+ removed. At most one such <tt>nest</tt> argument is allowed, and it must be
+ of pointer type. Calling the new function is equivalent to calling
+ <tt>func</tt> with the same argument list, but with <tt>nval</tt> used for the
+ missing <tt>nest</tt> argument. If, after calling
+ <tt>llvm.init.trampoline</tt>, the memory pointed to by <tt>tramp</tt> is
+ modified, then the effect of any later call to the returned function pointer is
+ undefined.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_atomics">Atomic Operations and Synchronization Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ These intrinsic functions expand the "universal IR" of LLVM to represent
+ hardware constructs for atomic operations and memory synchronization. This
+ provides an interface to the hardware, not an interface to the programmer. It
+ is aimed at a low enough level to allow any programming models or APIs
+ (Application Programming Interfaces) which
+ need atomic behaviors to map cleanly onto it. It is also modeled primarily on
+ hardware behavior. Just as hardware provides a "universal IR" for source
+ languages, it also provides a starting point for developing a "universal"
+ atomic operation and synchronization IR.
+ </p>
+ <p>
+ These do <em>not</em> form an API such as high-level threading libraries,
+ software transaction memory systems, atomic primitives, and intrinsic
+ functions as found in BSD, GNU libc, atomic_ops, APR, and other system and
+ application libraries. The hardware interface provided by LLVM should allow
+ a clean implementation of all of these APIs and parallel programming models.
+ No one model or paradigm should be selected above others unless the hardware
+ itself ubiquitously does so.
+
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_memory_barrier">'<tt>llvm.memory.barrier</tt>' Intrinsic</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.memory.barrier( i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>,
+ i1 <device> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ The <tt>llvm.memory.barrier</tt> intrinsic guarantees ordering between
+ specific pairs of memory access types.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+ The <tt>llvm.memory.barrier</tt> intrinsic requires five boolean arguments.
+ The first four arguments enables a specific barrier as listed below. The fith
+ argument specifies that the barrier applies to io or device or uncached memory.
+
+ </p>
+ <ul>
+ <li><tt>ll</tt>: load-load barrier</li>
+ <li><tt>ls</tt>: load-store barrier</li>
+ <li><tt>sl</tt>: store-load barrier</li>
+ <li><tt>ss</tt>: store-store barrier</li>
+ <li><tt>device</tt>: barrier applies to device and uncached memory also.</li>
+ </ul>
+ <h5>Semantics:</h5>
+ <p>
+ This intrinsic causes the system to enforce some ordering constraints upon
+ the loads and stores of the program. This barrier does not indicate
+ <em>when</em> any events will occur, it only enforces an <em>order</em> in
+ which they occur. For any of the specified pairs of load and store operations
+ (f.ex. load-load, or store-load), all of the first operations preceding the
+ barrier will complete before any of the second operations succeeding the
+ barrier begin. Specifically the semantics for each pairing is as follows:
+ </p>
+ <ul>
+ <li><tt>ll</tt>: All loads before the barrier must complete before any load
+ after the barrier begins.</li>
+
+ <li><tt>ls</tt>: All loads before the barrier must complete before any
+ store after the barrier begins.</li>
+ <li><tt>ss</tt>: All stores before the barrier must complete before any
+ store after the barrier begins.</li>
+ <li><tt>sl</tt>: All stores before the barrier must complete before any
+ load after the barrier begins.</li>
+ </ul>
+ <p>
+ These semantics are applied with a logical "and" behavior when more than one
+ is enabled in a single memory barrier intrinsic.
+ </p>
+ <p>
+ Backends may implement stronger barriers than those requested when they do not
+ support as fine grained a barrier as requested. Some architectures do not
+ need all types of barriers and on such architectures, these become noops.
+ </p>
+ <h5>Example:</h5>
+ <pre>
+ %ptr = malloc i32
+ store i32 4, %ptr
+
+ %result1 = load i32* %ptr <i>; yields {i32}:result1 = 4</i>
+ call void @llvm.memory.barrier( i1 false, i1 true, i1 false, i1 false )
+ <i>; guarantee the above finishes</i>
+ store i32 8, %ptr <i>; before this begins</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_atomic_cmp_swap">'<tt>llvm.atomic.cmp.swap.*</tt>' Intrinsic</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <p>
+ This is an overloaded intrinsic. You can use <tt>llvm.atomic.cmp.swap</tt> on
+ any integer bit width and for different address spaces. Not all targets
+ support all bit widths however.</p>
+
+ <pre>
+ declare i8 @llvm.atomic.cmp.swap.i8.p0i8( i8* <ptr>, i8 <cmp>, i8 <val> )
+ declare i16 @llvm.atomic.cmp.swap.i16.p0i16( i16* <ptr>, i16 <cmp>, i16 <val> )
+ declare i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* <ptr>, i32 <cmp>, i32 <val> )
+ declare i64 @llvm.atomic.cmp.swap.i64.p0i64( i64* <ptr>, i64 <cmp>, i64 <val> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ This loads a value in memory and compares it to a given value. If they are
+ equal, it stores a new value into the memory.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+ The <tt>llvm.atomic.cmp.swap</tt> intrinsic takes three arguments. The result as
+ well as both <tt>cmp</tt> and <tt>val</tt> must be integer values with the
+ same bit width. The <tt>ptr</tt> argument must be a pointer to a value of
+ this integer type. While any bit width integer may be used, targets may only
+ lower representations they support in hardware.
+
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ This entire intrinsic must be executed atomically. It first loads the value
+ in memory pointed to by <tt>ptr</tt> and compares it with the value
+ <tt>cmp</tt>. If they are equal, <tt>val</tt> is stored into the memory. The
+ loaded value is yielded in all cases. This provides the equivalent of an
+ atomic compare-and-swap operation within the SSA framework.
+ </p>
+ <h5>Examples:</h5>
+
+ <pre>
+ %ptr = malloc i32
+ store i32 4, %ptr
+
+ %val1 = add i32 4, 4
+ %result1 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 4, %val1 )
+ <i>; yields {i32}:result1 = 4</i>
+ %stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
+ %memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
+
+ %val2 = add i32 1, 1
+ %result2 = call i32 @llvm.atomic.cmp.swap.i32.p0i32( i32* %ptr, i32 5, %val2 )
+ <i>; yields {i32}:result2 = 8</i>
+ %stored2 = icmp eq i32 %result2, 5 <i>; yields {i1}:stored2 = false</i>
+
+ %memval2 = load i32* %ptr <i>; yields {i32}:memval2 = 8</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_atomic_swap">'<tt>llvm.atomic.swap.*</tt>' Intrinsic</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+
+ <p>
+ This is an overloaded intrinsic. You can use <tt>llvm.atomic.swap</tt> on any
+ integer bit width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.atomic.swap.i8.p0i8( i8* <ptr>, i8 <val> )
+ declare i16 @llvm.atomic.swap.i16.p0i16( i16* <ptr>, i16 <val> )
+ declare i32 @llvm.atomic.swap.i32.p0i32( i32* <ptr>, i32 <val> )
+ declare i64 @llvm.atomic.swap.i64.p0i64( i64* <ptr>, i64 <val> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ This intrinsic loads the value stored in memory at <tt>ptr</tt> and yields
+ the value from memory. It then stores the value in <tt>val</tt> in the memory
+ at <tt>ptr</tt>.
+ </p>
+ <h5>Arguments:</h5>
+
+ <p>
+ The <tt>llvm.atomic.swap</tt> intrinsic takes two arguments. Both the
+ <tt>val</tt> argument and the result must be integers of the same bit width.
+ The first argument, <tt>ptr</tt>, must be a pointer to a value of this
+ integer type. The targets may only lower integer representations they
+ support.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ This intrinsic loads the value pointed to by <tt>ptr</tt>, yields it, and
+ stores <tt>val</tt> back into <tt>ptr</tt> atomically. This provides the
+ equivalent of an atomic swap operation within the SSA framework.
+
+ </p>
+ <h5>Examples:</h5>
+ <pre>
+ %ptr = malloc i32
+ store i32 4, %ptr
+
+ %val1 = add i32 4, 4
+ %result1 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val1 )
+ <i>; yields {i32}:result1 = 4</i>
+ %stored1 = icmp eq i32 %result1, 4 <i>; yields {i1}:stored1 = true</i>
+ %memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 8</i>
+
+ %val2 = add i32 1, 1
+ %result2 = call i32 @llvm.atomic.swap.i32.p0i32( i32* %ptr, i32 %val2 )
+ <i>; yields {i32}:result2 = 8</i>
+
+ %stored2 = icmp eq i32 %result2, 8 <i>; yields {i1}:stored2 = true</i>
+ %memval2 = load i32* %ptr <i>; yields {i32}:memval2 = 2</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_atomic_load_add">'<tt>llvm.atomic.load.add.*</tt>' Intrinsic</a>
+
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <p>
+ This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.add</tt> on any
+ integer bit width. Not all targets support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.atomic.load.add.i8..p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.add.i16..p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.add.i32..p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.add.i64..p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ This intrinsic adds <tt>delta</tt> to the value stored in memory at
+ <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+
+ The intrinsic takes two arguments, the first a pointer to an integer value
+ and the second an integer value. The result is also an integer value. These
+ integer types can have any bit width, but they must all have the same bit
+ width. The targets may only lower integer representations they support.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ This intrinsic does a series of operations atomically. It first loads the
+ value stored at <tt>ptr</tt>. It then adds <tt>delta</tt>, stores the result
+ to <tt>ptr</tt>. It yields the original value stored at <tt>ptr</tt>.
+ </p>
+
+ <h5>Examples:</h5>
+ <pre>
+ %ptr = malloc i32
+ store i32 4, %ptr
+ %result1 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 4 )
+ <i>; yields {i32}:result1 = 4</i>
+ %result2 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 2 )
+ <i>; yields {i32}:result2 = 8</i>
+ %result3 = call i32 @llvm.atomic.load.add.i32.p0i32( i32* %ptr, i32 5 )
+ <i>; yields {i32}:result3 = 10</i>
+ %memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 15</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_atomic_load_sub">'<tt>llvm.atomic.load.sub.*</tt>' Intrinsic</a>
+
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <p>
+ This is an overloaded intrinsic. You can use <tt>llvm.atomic.load.sub</tt> on
+ any integer bit width and for different address spaces. Not all targets
+ support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.atomic.load.sub.i8.p0i32( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.sub.i16.p0i32( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.sub.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.sub.i64.p0i32( i64* <ptr>, i64 <delta> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ This intrinsic subtracts <tt>delta</tt> to the value stored in memory at
+ <tt>ptr</tt>. It yields the original value at <tt>ptr</tt>.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+
+ The intrinsic takes two arguments, the first a pointer to an integer value
+ and the second an integer value. The result is also an integer value. These
+ integer types can have any bit width, but they must all have the same bit
+ width. The targets may only lower integer representations they support.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ This intrinsic does a series of operations atomically. It first loads the
+ value stored at <tt>ptr</tt>. It then subtracts <tt>delta</tt>, stores the
+ result to <tt>ptr</tt>. It yields the original value stored at <tt>ptr</tt>.
+ </p>
+
+ <h5>Examples:</h5>
+ <pre>
+ %ptr = malloc i32
+ store i32 8, %ptr
+ %result1 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 4 )
+ <i>; yields {i32}:result1 = 8</i>
+ %result2 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 2 )
+ <i>; yields {i32}:result2 = 4</i>
+ %result3 = call i32 @llvm.atomic.load.sub.i32.p0i32( i32* %ptr, i32 5 )
+ <i>; yields {i32}:result3 = 2</i>
+ %memval1 = load i32* %ptr <i>; yields {i32}:memval1 = -3</i>
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_atomic_load_and">'<tt>llvm.atomic.load.and.*</tt>' Intrinsic</a><br>
+ <a name="int_atomic_load_nand">'<tt>llvm.atomic.load.nand.*</tt>' Intrinsic</a><br>
+ <a name="int_atomic_load_or">'<tt>llvm.atomic.load.or.*</tt>' Intrinsic</a><br>
+ <a name="int_atomic_load_xor">'<tt>llvm.atomic.load.xor.*</tt>' Intrinsic</a><br>
+
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <p>
+ These are overloaded intrinsics. You can use <tt>llvm.atomic.load_and</tt>,
+ <tt>llvm.atomic.load_nand</tt>, <tt>llvm.atomic.load_or</tt>, and
+ <tt>llvm.atomic.load_xor</tt> on any integer bit width and for different
+ address spaces. Not all targets support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.atomic.load.and.i8.p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.and.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.and.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.and.i64.p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+
+ <pre>
+ declare i8 @llvm.atomic.load.or.i8.p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.or.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.or.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.or.i64.p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+
+ <pre>
+ declare i8 @llvm.atomic.load.nand.i8.p0i32( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.nand.i16.p0i32( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.nand.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.nand.i64.p0i32( i64* <ptr>, i64 <delta> )
+
+ </pre>
+
+ <pre>
+ declare i8 @llvm.atomic.load.xor.i8.p0i32( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.xor.i16.p0i32( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.xor.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.xor.i64.p0i32( i64* <ptr>, i64 <delta> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ These intrinsics bitwise the operation (and, nand, or, xor) <tt>delta</tt> to
+ the value stored in memory at <tt>ptr</tt>. It yields the original value
+ at <tt>ptr</tt>.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+
+ These intrinsics take two arguments, the first a pointer to an integer value
+ and the second an integer value. The result is also an integer value. These
+ integer types can have any bit width, but they must all have the same bit
+ width. The targets may only lower integer representations they support.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ These intrinsics does a series of operations atomically. They first load the
+ value stored at <tt>ptr</tt>. They then do the bitwise operation
+ <tt>delta</tt>, store the result to <tt>ptr</tt>. They yield the original
+ value stored at <tt>ptr</tt>.
+ </p>
+
+ <h5>Examples:</h5>
+ <pre>
+ %ptr = malloc i32
+ store i32 0x0F0F, %ptr
+ %result0 = call i32 @llvm.atomic.load.nand.i32.p0i32( i32* %ptr, i32 0xFF )
+ <i>; yields {i32}:result0 = 0x0F0F</i>
+ %result1 = call i32 @llvm.atomic.load.and.i32.p0i32( i32* %ptr, i32 0xFF )
+ <i>; yields {i32}:result1 = 0xFFFFFFF0</i>
+ %result2 = call i32 @llvm.atomic.load.or.i32.p0i32( i32* %ptr, i32 0F )
+ <i>; yields {i32}:result2 = 0xF0</i>
+ %result3 = call i32 @llvm.atomic.load.xor.i32.p0i32( i32* %ptr, i32 0F )
+ <i>; yields {i32}:result3 = FF</i>
+ %memval1 = load i32* %ptr <i>; yields {i32}:memval1 = F0</i>
+ </pre>
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_atomic_load_max">'<tt>llvm.atomic.load.max.*</tt>' Intrinsic</a><br>
+ <a name="int_atomic_load_min">'<tt>llvm.atomic.load.min.*</tt>' Intrinsic</a><br>
+ <a name="int_atomic_load_umax">'<tt>llvm.atomic.load.umax.*</tt>' Intrinsic</a><br>
+ <a name="int_atomic_load_umin">'<tt>llvm.atomic.load.umin.*</tt>' Intrinsic</a><br>
+
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <p>
+ These are overloaded intrinsics. You can use <tt>llvm.atomic.load_max</tt>,
+ <tt>llvm.atomic.load_min</tt>, <tt>llvm.atomic.load_umax</tt>, and
+ <tt>llvm.atomic.load_umin</tt> on any integer bit width and for different
+ address spaces. Not all targets
+ support all bit widths however.</p>
+ <pre>
+ declare i8 @llvm.atomic.load.max.i8.p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.max.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.max.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.max.i64.p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+
+ <pre>
+ declare i8 @llvm.atomic.load.min.i8.p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.min.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.min.i32..p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.min.i64..p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+
+ <pre>
+ declare i8 @llvm.atomic.load.umax.i8.p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.umax.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.umax.i32.p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.umax.i64.p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+
+ <pre>
+ declare i8 @llvm.atomic.load.umin.i8..p0i8( i8* <ptr>, i8 <delta> )
+ declare i16 @llvm.atomic.load.umin.i16.p0i16( i16* <ptr>, i16 <delta> )
+ declare i32 @llvm.atomic.load.umin.i32..p0i32( i32* <ptr>, i32 <delta> )
+ declare i64 @llvm.atomic.load.umin.i64..p0i64( i64* <ptr>, i64 <delta> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ These intrinsics takes the signed or unsigned minimum or maximum of
+ <tt>delta</tt> and the value stored in memory at <tt>ptr</tt>. It yields the
+ original value at <tt>ptr</tt>.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+
+ These intrinsics take two arguments, the first a pointer to an integer value
+ and the second an integer value. The result is also an integer value. These
+ integer types can have any bit width, but they must all have the same bit
+ width. The targets may only lower integer representations they support.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ These intrinsics does a series of operations atomically. They first load the
+ value stored at <tt>ptr</tt>. They then do the signed or unsigned min or max
+ <tt>delta</tt> and the value, store the result to <tt>ptr</tt>. They yield
+ the original value stored at <tt>ptr</tt>.
+ </p>
+
+ <h5>Examples:</h5>
+ <pre>
+ %ptr = malloc i32
+ store i32 7, %ptr
+ %result0 = call i32 @llvm.atomic.load.min.i32.p0i32( i32* %ptr, i32 -2 )
+ <i>; yields {i32}:result0 = 7</i>
+ %result1 = call i32 @llvm.atomic.load.max.i32.p0i32( i32* %ptr, i32 8 )
+ <i>; yields {i32}:result1 = -2</i>
+ %result2 = call i32 @llvm.atomic.load.umin.i32.p0i32( i32* %ptr, i32 10 )
+ <i>; yields {i32}:result2 = 8</i>
+ %result3 = call i32 @llvm.atomic.load.umax.i32.p0i32( i32* %ptr, i32 30 )
+ <i>; yields {i32}:result3 = 8</i>
+ %memval1 = load i32* %ptr <i>; yields {i32}:memval1 = 30</i>
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="int_general">General Intrinsics</a>
+ </div>
+
+ <div class="doc_text">
+ <p> This class of intrinsics is designed to be generic and has
+ no specific purpose. </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_var_annotation">'<tt>llvm.var.annotation</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.var.annotation(i8* <val>, i8* <str>, i8* <str>, i32 <int> )
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.var.annotation</tt>' intrinsic
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first argument is a pointer to a value, the second is a pointer to a
+ global string, the third is a pointer to a global string which is the source
+ file name, and the last argument is the line number.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This intrinsic allows annotation of local variables with arbitrary strings.
+ This can be useful for special purpose optimizations that want to look for these
+ annotations. These have no other defined use, they are ignored by code
+ generation and optimization.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_annotation">'<tt>llvm.annotation.*</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <p>This is an overloaded intrinsic. You can use '<tt>llvm.annotation</tt>' on
+ any integer bit width.
+ </p>
+ <pre>
+ declare i8 @llvm.annotation.i8(i8 <val>, i8* <str>, i8* <str>, i32 <int> )
+ declare i16 @llvm.annotation.i16(i16 <val>, i8* <str>, i8* <str>, i32 <int> )
+ declare i32 @llvm.annotation.i32(i32 <val>, i8* <str>, i8* <str>, i32 <int> )
+ declare i64 @llvm.annotation.i64(i64 <val>, i8* <str>, i8* <str>, i32 <int> )
+ declare i256 @llvm.annotation.i256(i256 <val>, i8* <str>, i8* <str>, i32 <int> )
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.annotation</tt>' intrinsic.
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ The first argument is an integer value (result of some expression),
+ the second is a pointer to a global string, the third is a pointer to a global
+ string which is the source file name, and the last argument is the line number.
+ It returns the value of the first argument.
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This intrinsic allows annotations to be put on arbitrary expressions
+ with arbitrary strings. This can be useful for special purpose optimizations
+ that want to look for these annotations. These have no other defined use, they
+ are ignored by code generation and optimization.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_trap">'<tt>llvm.trap</tt>' Intrinsic</a>
+ </div>
+
+ <div class="doc_text">
+
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.trap()
+ </pre>
+
+ <h5>Overview:</h5>
+
+ <p>
+ The '<tt>llvm.trap</tt>' intrinsic
+ </p>
+
+ <h5>Arguments:</h5>
+
+ <p>
+ None
+ </p>
+
+ <h5>Semantics:</h5>
+
+ <p>
+ This intrinsics is lowered to the target dependent trap instruction. If the
+ target does not have a trap instruction, this intrinsic will be lowered to the
+ call of the abort() function.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="int_stackprotector">'<tt>llvm.stackprotector</tt>' Intrinsic</a>
+ </div>
+ <div class="doc_text">
+ <h5>Syntax:</h5>
+ <pre>
+ declare void @llvm.stackprotector( i8* <guard>, i8** <slot> )
+
+ </pre>
+ <h5>Overview:</h5>
+ <p>
+ The <tt>llvm.stackprotector</tt> intrinsic takes the <tt>guard</tt> and stores
+ it onto the stack at <tt>slot</tt>. The stack slot is adjusted to ensure that
+ it is placed on the stack before local variables.
+ </p>
+ <h5>Arguments:</h5>
+ <p>
+ The <tt>llvm.stackprotector</tt> intrinsic requires two pointer arguments. The
+ first argument is the value loaded from the stack guard
+ <tt>@__stack_chk_guard</tt>. The second variable is an <tt>alloca</tt> that
+ has enough space to hold the value of the guard.
+ </p>
+ <h5>Semantics:</h5>
+ <p>
+ This intrinsic causes the prologue/epilogue inserter to force the position of
+ the <tt>AllocaInst</tt> stack slot to be before local variables on the
+ stack. This is to ensure that if a local variable on the stack is overwritten,
+ it will destroy the value of the guard. When the function exits, the guard on
+ the stack is checked against the original guard. If they're different, then
+ the program aborts by calling the <tt>__stack_chk_fail()</tt> function.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/Lexicon.html
diff -c /dev/null llvm-www/releases/2.5/docs/Lexicon.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/Lexicon.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,263 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>The LLVM Lexicon</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <meta name="author" content="Various">
+ <meta name="description"
+ content="A glossary of terms used with the LLVM project.">
+ </head>
+ <body>
+ <div class="doc_title">The LLVM Lexicon</div>
+ <p class="doc_warning">NOTE: This document is a work in progress!</p>
+ <!-- *********************************************************************** -->
+ <div class="doc_section">Table Of Contents</div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <table>
+ <tr><th colspan="8"><b>- <a href="#A">A</a> -</b></th></tr>
+ <tr>
+ <td><a href="#ADCE">ADCE</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#B">B</a> -</b></th></tr>
+ <tr>
+ <td><a href="#BURS">BURS</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#C">C</a> -</b></th></tr>
+ <tr>
+ <td><a href="#CSE">CSE</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#D">D</a> -</b></th></tr>
+ <tr>
+ <td><a href="#DAG">DAG</a></td>
+ <td><a href="#Derived_Pointer">Derived Pointer</a></td>
+ <td><a href="#DSA">DSA</a></td>
+ <td><a href="#DSE">DSE</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#G">G</a> -</b></th></tr>
+ <tr>
+ <td><a href="#GC">GC</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#I">I</a> -</b></th></tr>
+ <tr>
+ <td><a href="#IPA">IPA</a></td>
+ <td><a href="#IPO">IPO</a></td>
+ <td><a href="#ISel">ISel</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#L">L</a> -</b></th></tr>
+ <tr>
+ <td><a href="#LCSSA">LCSSA</a></td>
+ <td><a href="#LICM">LICM</a></td>
+ <td><a href="#Load-VN">Load-VN</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#O">O</a> -</b></th></tr>
+ <tr>
+ <td><a href="#Object_Pointer">Object Pointer</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#P">P</a> -</b></th></tr>
+ <tr>
+ <td><a href="#PRE">PRE</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#R">R</a> -</b></th></tr>
+ <tr>
+ <td><a href="#RAUW">RAUW</a></td>
+ <td><a href="#Reassociation">Reassociation</a></td>
+ <td><a href="#Root">Root</a></td>
+ </tr>
+ <tr><th colspan="8"><b>- <a href="#S">S</a> -</b></th></tr>
+ <tr>
+ <td><a href="#Safe_Point">Safe Point</a></td>
+ <td><a href="#SCC">SCC</a></td>
+ <td><a href="#SCCP">SCCP</a></td>
+ <td><a href="#SDISel">SDISel</a></td>
+ <td><a href="#SRoA">SRoA</a></td>
+ <td><a href="#Stack_Map">Stack Map</a></td>
+ </tr>
+ </table>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">Definitions</div>
+ <!-- *********************************************************************** -->
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="A">- A -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="ADCE"><b>ADCE</b></a></dt>
+ <dd>Aggressive Dead Code Elimination</dd>
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="B">- B -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="BURS"><b>BURS</b></a></dt>
+ <dd>Bottom Up Rewriting System—A method of instruction selection for
+ code generation. An example is the <a
+ href="http://www.program-transformation.org/Transform/BURG">BURG</a> tool.</dd>
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="C">- C -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="CSE"><b>CSE</b></a></dt>
+ <dd>Common Subexpression Elimination. An optimization that removes common
+ subexpression compuation. For example <tt>(a+b)*(a+b)</tt> has two
+ subexpressions that are the same: <tt>(a+b)</tt>. This optimization would
+ perform the addition only once and then perform the multiply (but only if
+ it's compulationally correct/safe).
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="D">- D -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="DAG"><b>DAG</b></a></dt>
+ <dd>Directed Acyclic Graph</dd>
+ <dt><a name="Derived_Pointer"><b>Derived Pointer</b></a></dt>
+ <dd>A pointer to the interior of an object, such that a garbage collector
+ is unable to use the pointer for reachability analysis. While a derived
+ pointer is live, the corresponding object pointer must be kept in a root,
+ otherwise the collector might free the referenced object. With copying
+ collectors, derived pointers pose an additional hazard that they may be
+ invalidated at any <a href="Safe_Point">safe point</a>. This term is used in
+ opposition to <a href="#Object_Pointer">object pointer</a>.</dd>
+ <dt><a name="DSA"><b>DSA</b></a></dt>
+ <dd>Data Structure Analysis</dd>
+ <dt><a name="DSE"><b>DSE</b></a></dt>
+ <dd>Dead Store Elimination</dd>
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="G">- G -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="GC"><b>GC</b></a></dt>
+ <dd>Garbage Collection. The practice of using reachability analysis instead
+ of explicit memory management to reclaim unused memory.</dd>
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="H">- H -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="Heap"><b>Heap</b></a></dt>
+ <dd>In garbage collection, the region of memory which is managed using
+ reachability analysis.</dd>
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="I">- I -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="IPA"><b>IPA</b></a></dt>
+ <dd>Inter-Procedural Analysis. Refers to any variety of code analysis that
+ occurs between procedures, functions or compilation units (modules).</dd>
+ <dt><a name="IPO"><b>IPO</b></a></dt>
+ <dd>Inter-Procedural Optimization. Refers to any variety of code
+ optimization that occurs between procedures, functions or compilation units
+ (modules).</dd>
+ <dt><a name="ISel"><b>ISel</b></a></dt>
+ <dd>Instruction Selection.</dd>
+ </dl>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="L">- L -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="LCSSA"><b>LCSSA</b></a></dt>
+ <dd>Loop-Closed Static Single Assignment Form</dd>
+ <dt><a name="LICM"><b>LICM</b></a></dt>
+ <dd>Loop Invariant Code Motion</dd>
+ <dt><a name="Load-VN"><b>Load-VN</b></a></dt>
+ <dd>Load Value Numbering</dd>
+ </dl>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="O">- O -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="Object_Pointer"><b>Object Pointer</b></a></dt>
+ <dd>A pointer to an object such that the garbage collector is able to trace
+ references contained within the object. This term is used in opposition to
+ <a href="#Derived_Pointer">derived pointer</a>.</dd>
+ </dl>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="P">- P -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="PRE"><b>PRE</b></a></dt>
+ <dd>Partial Redundancy Elimination</dd>
+ </dl>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="R">- R -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="RAUW"><b>RAUW</b></a></dt> <dd>An abbreviation for Replace
+ All Uses With. The functions User::replaceUsesOfWith(),
+ Value::replaceAllUsesWith(), and Constant::replaceUsesOfWithOnConstant()
+ implement the replacement of one Value with another by iterating over its
+ def/use chain and fixing up all of the pointers to point to the new value.
+ See also <a href="ProgrammersManual.html#iterate_chains">def/use chains</a>.
+ </dd>
+ <dt><a name="Reassociation"><b>Reassociation</b></a></dt> <dd>Rearranging
+ associative expressions to promote better redundancy elimination and other
+ optimization. For example, changing (A+B-A) into (B+A-A), permitting it to
+ be optimized into (B+0) then (B).</dd>
+ <dt><a name="Root"><b>Root</b></a></dt> <dd>In garbage collection, a
+ pointer variable lying outside of the <a href="#Heap">heap</a> from which
+ the collector begins its reachability analysis. In the context of code
+ generation, "root" almost always refers to a "stack root" -- a local or
+ temporary variable within an executing function.</dd>
+ </dl>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="S">- S -</a></div>
+ <div class="doc_text">
+ <dl>
+ <dt><a name="Safe_Point"><b>Safe Point</b></a></dt>
+ <dd>In garbage collection, it is necessary to identify <a href="#Root">stack
+ roots</a> so that reachability analysis may proceed. It may be infeasible to
+ provide this information for every instruction, so instead the information
+ may is calculated only at designated safe points. With a copying collector,
+ <a href="#Derived_Pointers">derived pointers</a> must not be retained across
+ safe points and <a href="#Object_Pointers">object pointers</a> must be
+ reloaded from stack roots.</dd>
+ <dt><a name="SDISel"><b>SDISel</b></a></dt>
+ <dd>Selection DAG Instruction Selection.</dd>
+ <dt><a name="SCC"><b>SCC</b></a></dt>
+ <dd>Strongly Connected Component</dd>
+ <dt><a name="SCCP"><b>SCCP</b></a></dt>
+ <dd>Sparse Conditional Constant Propagation</dd>
+ <dt><a name="SRoA"><b>SRoA</b></a></dt>
+ <dd>Scalar Replacement of Aggregates</dd>
+ <dt><a name="SSA"><b>SSA</b></a></dt>
+ <dd>Static Single Assignment</dd>
+ <dt><a name="Stack_Map"><b>Stack Map</b></a></dt>
+ <dd>In garbage collection, metadata emitted by the code generator which
+ identifies <a href="#Root">roots</a> within the stack frame of an executing
+ function.</dd>
+ </dl>
+ </div>
+ <!-- *********************************************************************** -->
+ <hr>
+ <address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a><a
+ href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a><a
+ href="http://llvm.org/">The LLVM Team</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ <!-- vim: sw=2
+ -->
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/LinkTimeOptimization.html
diff -c /dev/null llvm-www/releases/2.5/docs/LinkTimeOptimization.html:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/LinkTimeOptimization.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,390 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM Link Time Optimization: Design and Implementation</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <div class="doc_title">
+ LLVM Link Time Optimization: Design and Implementation
+ </div>
+
+ <ul>
+ <li><a href="#desc">Description</a></li>
+ <li><a href="#design">Design Philosophy</a>
+ <ul>
+ <li><a href="#example1">Example of link time optimization</a></li>
+ <li><a href="#alternative_approaches">Alternative Approaches</a></li>
+ </ul></li>
+ <li><a href="#multiphase">Multi-phase communication between LLVM and linker</a>
+ <ul>
+ <li><a href="#phase1">Phase 1 : Read LLVM Bytecode Files</a></li>
+ <li><a href="#phase2">Phase 2 : Symbol Resolution</a></li>
+ <li><a href="#phase3">Phase 3 : Optimize Bitcode Files</a></li>
+ <li><a href="#phase4">Phase 4 : Symbol Resolution after optimization</a></li>
+ </ul></li>
+ <li><a href="#lto">libLTO</a>
+ <ul>
+ <li><a href="#lto_module_t">lto_module_t</a></li>
+ <li><a href="#lto_code_gen_t">lto_code_gen_t</a></li>
+ </ul>
+ </ul>
+
+ <div class="doc_author">
+ <p>Written by Devang Patel and Nick Kledzik</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="desc">Description</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ LLVM features powerful intermodular optimizations which can be used at link
+ time. Link Time Optimization (LTO) is another name for intermodular optimization
+ when performed during the link stage. This document describes the interface
+ and design between the LTO optimizer and the linker.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="design">Design Philosophy</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ The LLVM Link Time Optimizer provides complete transparency, while doing
+ intermodular optimization, in the compiler tool chain. Its main goal is to let
+ the developer take advantage of intermodular optimizations without making any
+ significant changes to the developer's makefiles or build system. This is
+ achieved through tight integration with the linker. In this model, the linker
+ treates LLVM bitcode files like native object files and allows mixing and
+ matching among them. The linker uses <a href="#lto">libLTO</a>, a shared
+ object, to handle LLVM bitcode files. This tight integration between
+ the linker and LLVM optimizer helps to do optimizations that are not possible
+ in other models. The linker input allows the optimizer to avoid relying on
+ conservative escape analysis.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="example1">Example of link time optimization</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The following example illustrates the advantages of LTO's integrated
+ approach and clean interface. This example requires a system linker which
+ supports LTO through the interface described in this document. Here,
+ llvm-gcc transparently invokes system linker. </p>
+ <ul>
+ <li> Input source file <tt>a.c</tt> is compiled into LLVM bitcode form.
+ <li> Input source file <tt>main.c</tt> is compiled into native object code.
+ </ul>
+ <pre class="doc_code">
+ --- a.h ---
+ extern int foo1(void);
+ extern void foo2(void);
+ extern void foo4(void);
+ --- a.c ---
+ #include "a.h"
+
+ static signed int i = 0;
+
+ void foo2(void) {
+ i = -1;
+ }
+
+ static int foo3() {
+ foo4();
+ return 10;
+ }
+
+ int foo1(void) {
+ int data = 0;
+
+ if (i < 0) { data = foo3(); }
+
+ data = data + 42;
+ return data;
+ }
+
+ --- main.c ---
+ #include <stdio.h>
+ #include "a.h"
+
+ void foo4(void) {
+ printf ("Hi\n");
+ }
+
+ int main() {
+ return foo1();
+ }
+
+ --- command lines ---
+ $ llvm-gcc --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bitcode file
+ $ llvm-gcc -c main.c -o main.o # <-- main.o is native object file
+ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modifications
+ </pre>
+ <p>In this example, the linker recognizes that <tt>foo2()</tt> is an
+ externally visible symbol defined in LLVM bitcode file. The linker completes
+ its usual symbol resolution
+ pass and finds that <tt>foo2()</tt> is not used anywhere. This information
+ is used by the LLVM optimizer and it removes <tt>foo2()</tt>. As soon as
+ <tt>foo2()</tt> is removed, the optimizer recognizes that condition
+ <tt>i < 0</tt> is always false, which means <tt>foo3()</tt> is never
+ used. Hence, the optimizer removes <tt>foo3()</tt>, also. And this in turn,
+ enables linker to remove <tt>foo4()</tt>. This example illustrates the
+ advantage of tight integration with the linker. Here, the optimizer can not
+ remove <tt>foo3()</tt> without the linker's input.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="alternative_approaches">Alternative Approaches</a>
+ </div>
+
+ <div class="doc_text">
+ <dl>
+ <dt><b>Compiler driver invokes link time optimizer separately.</b></dt>
+ <dd>In this model the link time optimizer is not able to take advantage of
+ information collected during the linker's normal symbol resolution phase.
+ In the above example, the optimizer can not remove <tt>foo2()</tt> without
+ the linker's input because it is externally visible. This in turn prohibits
+ the optimizer from removing <tt>foo3()</tt>.</dd>
+ <dt><b>Use separate tool to collect symbol information from all object
+ files.</b></dt>
+ <dd>In this model, a new, separate, tool or library replicates the linker's
+ capability to collect information for link time optimization. Not only is
+ this code duplication difficult to justify, but it also has several other
+ disadvantages. For example, the linking semantics and the features
+ provided by the linker on various platform are not unique. This means,
+ this new tool needs to support all such features and platforms in one
+ super tool or a separate tool per platform is required. This increases
+ maintance cost for link time optimizer significantly, which is not
+ necessary. This approach also requires staying synchronized with linker
+ developements on various platforms, which is not the main focus of the link
+ time optimizer. Finally, this approach increases end user's build time due
+ to the duplication of work done by this separate tool and the linker itself.
+ </dd>
+ </dl>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="multiphase">Multi-phase communication between libLTO and linker</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The linker collects information about symbol defininitions and uses in
+ various link objects which is more accurate than any information collected
+ by other tools during typical build cycles. The linker collects this
+ information by looking at the definitions and uses of symbols in native .o
+ files and using symbol visibility information. The linker also uses
+ user-supplied information, such as a list of exported symbols. LLVM
+ optimizer collects control flow information, data flow information and knows
+ much more about program structure from the optimizer's point of view.
+ Our goal is to take advantage of tight intergration between the linker and
+ the optimizer by sharing this information during various linking phases.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="phase1">Phase 1 : Read LLVM Bitcode Files</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The linker first reads all object files in natural order and collects
+ symbol information. This includes native object files as well as LLVM bitcode
+ files. To minimize the cost to the linker in the case that all .o files
+ are native object files, the linker only calls <tt>lto_module_create()</tt>
+ when a supplied object file is found to not be a native object file. If
+ <tt>lto_module_create()</tt> returns that the file is an LLVM bitcode file,
+ the linker
+ then iterates over the module using <tt>lto_module_get_symbol_name()</tt> and
+ <tt>lto_module_get_symbol_attribute()</tt> to get all symbols defined and
+ referenced.
+ This information is added to the linker's global symbol table.
+ </p>
+ <p>The lto* functions are all implemented in a shared object libLTO. This
+ allows the LLVM LTO code to be updated independently of the linker tool.
+ On platforms that support it, the shared object is lazily loaded.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="phase2">Phase 2 : Symbol Resolution</a>
+ </div>
+
+ <div class="doc_text">
+ <p>In this stage, the linker resolves symbols using global symbol table.
+ It may report undefined symbol errors, read archive members, replace
+ weak symbols, etc. The linker is able to do this seamlessly even though it
+ does not know the exact content of input LLVM bitcode files. If dead code
+ stripping is enabled then the linker collects the list of live symbols.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="phase3">Phase 3 : Optimize Bitcode Files</a>
+ </div>
+ <div class="doc_text">
+ <p>After symbol resolution, the linker tells the LTO shared object which
+ symbols are needed by native object files. In the example above, the linker
+ reports that only <tt>foo1()</tt> is used by native object files using
+ <tt>lto_codegen_add_must_preserve_symbol()</tt>. Next the linker invokes
+ the LLVM optimizer and code generators using <tt>lto_codegen_compile()</tt>
+ which returns a native object file creating by merging the LLVM bitcode files
+ and applying various optimization passes.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="phase4">Phase 4 : Symbol Resolution after optimization</a>
+ </div>
+
+ <div class="doc_text">
+ <p>In this phase, the linker reads optimized a native object file and
+ updates the internal global symbol table to reflect any changes. The linker
+ also collects information about any changes in use of external symbols by
+ LLVM bitcode files. In the examle above, the linker notes that
+ <tt>foo4()</tt> is not used any more. If dead code stripping is enabled then
+ the linker refreshes the live symbol information appropriately and performs
+ dead code stripping.</p>
+ <p>After this phase, the linker continues linking as if it never saw LLVM
+ bitcode files.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="lto">libLTO</a>
+ </div>
+
+ <div class="doc_text">
+ <p><tt>libLTO</tt> is a shared object that is part of the LLVM tools, and
+ is intended for use by a linker. <tt>libLTO</tt> provides an abstract C
+ interface to use the LLVM interprocedural optimizer without exposing details
+ of LLVM's internals. The intention is to keep the interface as stable as
+ possible even when the LLVM optimizer continues to evolve. It should even
+ be possible for a completely different compilation technology to provide
+ a different libLTO that works with their object files and the standard
+ linker tool.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="lto_module_t">lto_module_t</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>A non-native object file is handled via an <tt>lto_module_t</tt>.
+ The following functions allow the linker to check if a file (on disk
+ or in a memory buffer) is a file which libLTO can process:</p>
+
+ <pre class="doc_code">
+ lto_module_is_object_file(const char*)
+ lto_module_is_object_file_for_target(const char*, const char*)
+ lto_module_is_object_file_in_memory(const void*, size_t)
+ lto_module_is_object_file_in_memory_for_target(const void*, size_t, const char*)
+ </pre>
+
+ <p>If the object file can be processed by libLTO, the linker creates a
+ <tt>lto_module_t</tt> by using one of</p>
+
+ <pre class="doc_code">
+ lto_module_create(const char*)
+ lto_module_create_from_memory(const void*, size_t)
+ </pre>
+
+ <p>and when done, the handle is released via</p>
+
+ <pre class="doc_code">
+ lto_module_dispose(lto_module_t)
+ </pre>
+
+ <p>The linker can introspect the non-native object file by getting the number of
+ symbols and getting the name and attributes of each symbol via:</p>
+
+ <pre class="doc_code">
+ lto_module_get_num_symbols(lto_module_t)
+ lto_module_get_symbol_name(lto_module_t, unsigned int)
+ lto_module_get_symbol_attribute(lto_module_t, unsigned int)
+ </pre>
+
+ <p>The attributes of a symbol include the alignment, visibility, and kind.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="lto_code_gen_t">lto_code_gen_t</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Once the linker has loaded each non-native object files into an
+ <tt>lto_module_t</tt>, it can request libLTO to process them all and
+ generate a native object file. This is done in a couple of steps.
+ First, a code generator is created with:</p>
+
+ <pre class="doc_code">lto_codegen_create()</pre>
+
+ <p>Then, each non-native object file is added to the code generator with:</p>
+
+ <pre class="doc_code">
+ lto_codegen_add_module(lto_code_gen_t, lto_module_t)
+ </pre>
+
+ <p>The linker then has the option of setting some codegen options. Whether or
+ not to generate DWARF debug info is set with:</p>
+
+ <pre class="doc_code">lto_codegen_set_debug_model(lto_code_gen_t)</pre>
+
+ <p>Which kind of position independence is set with:</p>
+
+ <pre class="doc_code">lto_codegen_set_pic_model(lto_code_gen_t) </pre>
+
+ <p>And each symbol that is referenced by a native object file or otherwise must
+ not be optimized away is set with:</p>
+
+ <pre class="doc_code">
+ lto_codegen_add_must_preserve_symbol(lto_code_gen_t, const char*)
+ </pre>
+
+ <p>After all these settings are done, the linker requests that a native object
+ file be created from the modules with the settings using:</p>
+
+ <pre class="doc_code">lto_codegen_compile(lto_code_gen_t, size*)</pre>
+
+ <p>which returns a pointer to a buffer containing the generated native
+ object file. The linker then parses that and links it with the rest
+ of the native object files.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ Devang Patel and Nick Kledzik<br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
+
Index: llvm-www/releases/2.5/docs/Makefile
diff -c /dev/null llvm-www/releases/2.5/docs/Makefile:1.1
*** /dev/null Mon Mar 2 23:19:09 2009
--- llvm-www/releases/2.5/docs/Makefile Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,125 ----
+ ##===- docs/Makefile ---------------------------------------*- Makefile -*-===##
+ #
+ # The LLVM Compiler Infrastructure
+ #
+ # This file is distributed under the University of Illinois Open Source
+ # License. See LICENSE.TXT for details.
+ #
+ ##===----------------------------------------------------------------------===##
+
+ LEVEL := ..
+ DIRS := CommandGuide tutorial
+
+ ifdef BUILD_FOR_WEBSITE
+ PROJ_OBJ_DIR = .
+ DOXYGEN = doxygen
+
+ $(PROJ_OBJ_DIR)/doxygen.cfg: doxygen.cfg.in
+ cat $< | sed \
+ -e 's/@abs_top_srcdir@/../g' \
+ -e 's/@DOT@/dot/g' \
+ -e 's/@PACKAGE_VERSION@/mainline/' \
+ -e 's/@abs_top_builddir@/../g' > $@
+ endif
+
+ include $(LEVEL)/Makefile.common
+
+ HTML := $(wildcard $(PROJ_SRC_DIR)/*.html) \
+ $(wildcard $(PROJ_SRC_DIR)/*.css)
+ IMAGES := $(wildcard $(PROJ_SRC_DIR)/img/*.*)
+ DOXYFILES := doxygen.cfg.in doxygen.css doxygen.footer doxygen.header \
+ doxygen.intro
+ EXTRA_DIST := $(HTML) $(DOXYFILES) llvm.css CommandGuide img
+
+ .PHONY: install-html install-doxygen doxygen install-ocamldoc ocamldoc generated
+
+ install_targets := install-html
+ ifeq ($(ENABLE_DOXYGEN),1)
+ install_targets += install-doxygen
+ endif
+ ifneq (,$(filter ocaml,$(BINDINGS_TO_BUILD)))
+ install_targets += install-ocamldoc
+ endif
+ install-local:: $(install_targets)
+
+ # Live documentation is generated for the web site using this target:
+ # 'make generated BUILD_FOR_WEBSITE=1'
+ generated:: doxygen ocamldoc
+
+ install-html: $(PROJ_OBJ_DIR)/html.tar.gz
+ $(Echo) Installing HTML documentation
+ $(Verb) $(MKDIR) $(PROJ_docsdir)/html
+ $(Verb) $(MKDIR) $(PROJ_docsdir)/html/img
+ $(Verb) $(DataInstall) $(HTML) $(PROJ_docsdir)/html
+ $(Verb) $(DataInstall) $(IMAGES) $(PROJ_docsdir)/html/img
+ $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/html.tar.gz $(PROJ_docsdir)
+
+ $(PROJ_OBJ_DIR)/html.tar.gz: $(HTML)
+ $(Echo) Packaging HTML documentation
+ $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/html.tar
+ $(Verb) cd $(PROJ_SRC_DIR) && \
+ $(TAR) cf $(PROJ_OBJ_DIR)/html.tar *.html
+ $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/html.tar
+
+ install-doxygen: doxygen
+ $(Echo) Installing doxygen documentation
+ $(Verb) $(MKDIR) $(PROJ_docsdir)/html/doxygen
+ $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_docsdir)
+ $(Verb) cd $(PROJ_OBJ_DIR)/doxygen && \
+ $(FIND) . -type f -exec \
+ $(DataInstall) {} $(PROJ_docsdir)/html/doxygen \;
+
+ doxygen: regendoc $(PROJ_OBJ_DIR)/doxygen.tar.gz
+
+ regendoc:
+ $(Echo) Building doxygen documentation
+ $(Verb) if test -e $(PROJ_OBJ_DIR)/doxygen ; then \
+ $(RM) -rf $(PROJ_OBJ_DIR)/doxygen ; \
+ fi
+ $(Verb) $(DOXYGEN) $(PROJ_OBJ_DIR)/doxygen.cfg
+
+ $(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg
+ $(Echo) Packaging doxygen documentation
+ $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/doxygen.tar
+ $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/doxygen.tar doxygen
+ $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/doxygen.tar
+ $(Verb) $(CP) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_OBJ_DIR)/doxygen/html/
+
+ userloc: $(LLVM_SRC_ROOT)/docs/userloc.html
+
+ $(LLVM_SRC_ROOT)/docs/userloc.html:
+ $(Echo) Making User LOC Table
+ $(Verb) cd $(LLVM_SRC_ROOT) ; ./utils/userloc.pl -details -recurse \
+ -html lib include tools runtime utils examples autoconf test > docs/userloc.html
+
+ install-ocamldoc: ocamldoc
+ $(Echo) Installing ocamldoc documentation
+ $(Verb) $(MKDIR) $(PROJ_docsdir)/ocamldoc/html
+ $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/ocamldoc.tar.gz $(PROJ_docsdir)
+ $(Verb) cd $(PROJ_OBJ_DIR)/ocamldoc && \
+ $(FIND) . -type f -exec \
+ $(DataInstall) {} $(PROJ_docsdir)/ocamldoc/html \;
+
+ ocamldoc: regen-ocamldoc $(PROJ_OBJ_DIR)/ocamldoc.tar.gz
+
+ regen-ocamldoc:
+ $(Echo) Building ocamldoc documentation
+ $(Verb) if test -e $(PROJ_OBJ_DIR)/ocamldoc ; then \
+ $(RM) -rf $(PROJ_OBJ_DIR)/ocamldoc ; \
+ fi
+ $(Verb) $(MAKE) -C $(LEVEL)/bindings/ocaml ocamldoc
+ $(Verb) $(MKDIR) $(PROJ_OBJ_DIR)/ocamldoc/html
+ $(Verb) \
+ $(OCAMLDOC) -d $(PROJ_OBJ_DIR)/ocamldoc/html -sort -colorize-code -html \
+ `$(FIND) $(LEVEL)/bindings/ocaml -name "*.odoc" -exec echo -load '{}' ';'`
+
+ $(PROJ_OBJ_DIR)/ocamldoc.tar.gz:
+ $(Echo) Packaging ocamldoc documentation
+ $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/ocamldoc.tar
+ $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/ocamldoc.tar ocamldoc
+ $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/ocamldoc.tar
+ $(Verb) $(CP) $(PROJ_OBJ_DIR)/ocamldoc.tar.gz $(PROJ_OBJ_DIR)/ocamldoc/html/
+
+ uninstall-local::
+ $(Echo) Uninstalling Documentation
+ $(Verb) $(RM) -rf $(PROJ_docsdir)
Index: llvm-www/releases/2.5/docs/MakefileGuide.html
diff -c /dev/null llvm-www/releases/2.5/docs/MakefileGuide.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/MakefileGuide.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1033 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>LLVM Makefile Guide</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">LLVM Makefile Guide</div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#general">General Concepts</a>
+ <ol>
+ <li><a href="#projects">Projects</a></li>
+ <li><a href="#varvals">Variable Values</a></li>
+ <li><a href="#including">Including Makefiles</a>
+ <ol>
+ <li><a href="#Makefile">Makefile</a></li>
+ <li><a href="#Makefile.common">Makefile.common</a></li>
+ <li><a href="#Makefile.config">Makefile.config</a></li>
+ <li><a href="#Makefile.rules">Makefile.rules</a></li>
+ </ol>
+ </li>
+ <li><a href="#Comments">Comments</a></li>
+ </ol>
+ </li>
+ <li><a href="#tutorial">Tutorial</a>
+ <ol>
+ <li><a href="#libraries">Libraries</a>
+ <ol>
+ <li><a href="#BCModules">Bitcode Modules</a></li>
+ <li><a href="#LoadableModules">Loadable Modules</a></li>
+ </ol>
+ </li>
+ <li><a href="#tools">Tools</a>
+ <ol>
+ <li><a href="#JIT">JIT Tools</a></li>
+ </ol>
+ </li>
+ <li><a href="#projects">Projects</a></li>
+ </ol>
+ </li>
+ <li><a href="#targets">Targets Supported</a>
+ <ol>
+ <li><a href="#all">all</a></li>
+ <li><a href="#all-local">all-local</a></li>
+ <li><a href="#check">check</a></li>
+ <li><a href="#check-local">check-local</a></li>
+ <li><a href="#clean">clean</a></li>
+ <li><a href="#clean-local">clean-local</a></li>
+ <li><a href="#dist">dist</a></li>
+ <li><a href="#dist-check">dist-check</a></li>
+ <li><a href="#dist-clean">dist-clean</a></li>
+ <li><a href="#install">install</a></li>
+ <li><a href="#preconditions">preconditions</a></li>
+ <li><a href="#printvars">printvars</a></li>
+ <li><a href="#reconfigure">reconfigure</a></li>
+ <li><a href="#spotless">spotless</a></li>
+ <li><a href="#tags">tags</a></li>
+ <li><a href="#uninstall">uninstall</a></li>
+ </ol>
+ </li>
+ <li><a href="#variables">Using Variables</a>
+ <ol>
+ <li><a href="#setvars">Control Variables</a></li>
+ <li><a href="#overvars">Override Variables</a></li>
+ <li><a href="#getvars">Readable Variables</a></li>
+ <li><a href="#intvars">Internal Variables</a></li>
+ </ol>
+ </li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:reid at x10sys.com">Reid Spencer</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="introduction">Introduction </a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>This document provides <em>usage</em> information about the LLVM makefile
+ system. While loosely patterned after the BSD makefile system, LLVM has taken
+ a departure from BSD in order to implement additional features needed by LLVM.
+ Although makefile systems such as automake were attempted at one point, it
+ has become clear that the features needed by LLVM and the Makefile norm are
+ too great to use a more limited tool. Consequently, LLVM requires simply GNU
+ Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy
+ use of the features of GNU Make so the dependency on GNU Make is firm. If
+ you're not familiar with <tt>make</tt>, it is recommended that you read the
+ <a href="http://www.gnu.org/software/make/manual/make.html">GNU Makefile
+ Manual</a>.</p>
+ <p>While this document is rightly part of the
+ <a href="ProgrammersManual.html">LLVM Programmer's Manual</a>, it is treated
+ separately here because of the volume of content and because it is often an
+ early source of bewilderment for new developers.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="general">General Concepts</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>The LLVM Makefile System is the component of LLVM that is responsible for
+ building the software, testing it, generating distributions, checking those
+ distributions, installing and uninstalling, etc. It consists of a several
+ files throughout the source tree. These files and other general concepts are
+ described in this section.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="projects">Projects</a></div>
+ <div class="doc_text">
+ <p>The LLVM Makefile System is quite generous. It not only builds its own
+ software, but it can build yours too. Built into the system is knowledge of
+ the <tt>llvm/projects</tt> directory. Any directory under <tt>projects</tt>
+ that has both a <tt>configure</tt> script and a <tt>Makefile</tt> is assumed
+ to be a project that uses the LLVM Makefile system. Building software that
+ uses LLVM does not require the LLVM Makefile System nor even placement in the
+ <tt>llvm/projects</tt> directory. However, doing so will allow your project
+ to get up and running quickly by utilizing the built-in features that are used
+ to compile LLVM. LLVM compiles itself using the same features of the makefile
+ system as used for projects.</p>
+ <p>For complete details on setting up your projects configuration, simply
+ mimic the <tt>llvm/projects/sample</tt> project or for further details,
+ consult the <a href="Projects.html">Projects.html</a> page.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="varvalues">Variable Values</a></div>
+ <div class="doc_text">
+ <p>To use the makefile system, you simply create a file named
+ <tt>Makefile</tt> in your directory and declare values for certain variables.
+ The variables and values that you select determine what the makefile system
+ will do. These variables enable rules and processing in the makefile system
+ that automatically Do The Right Thing™.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="including">Including Makefiles</a></div>
+ <div class="doc_text">
+ <p>Setting variables alone is not enough. You must include into your Makefile
+ additional files that provide the rules of the LLVM Makefile system. The
+ various files involved are described in the sections that follow.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection"><a name="Makefile">Makefile</a></div>
+ <div class="doc_text">
+ <p>Each directory to participate in the build needs to have a file named
+ <tt>Makefile</tt>. This is the file first read by <tt>make</tt>. It has three
+ sections:</p>
+ <ol>
+ <li><a href="#setvars">Settable Variables</a> - Required that must be set
+ first.</li>
+ <li><a href="#Makefile.common">include <tt>$(LEVEL)/Makefile.common</tt></a>
+ - include the LLVM Makefile system.
+ <li><a href="#overvars">Override Variables</a> - Override variables set by
+ the LLVM Makefile system.
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection"><a name="Makefile.common">Makefile.common</a>
+ </div>
+ <div class="doc_text">
+ <p>Every project must have a <tt>Makefile.common</tt> file at its top source
+ directory. This file serves three purposes:</p>
+ <ol>
+ <li>It includes the project's configuration makefile to obtain values
+ determined by the <tt>configure</tt> script. This is done by including the
+ <a href="#Makefile.config"><tt>$(LEVEL)/Makefile.config</tt></a> file.</li>
+ <li>It specifies any other (static) values that are needed throughout the
+ project. Only values that are used in all or a large proportion of the
+ project's directories should be placed here.</li>
+ <li>It includes the standard rules for the LLVM Makefile system,
+ <a href="#Makefile.rules"><tt>$(LLVM_SRC_ROOT)/Makefile.rules</tt></a>.
+ This file is the "guts" of the LLVM Makefile system.</li>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection"><a name="Makefile.config">Makefile.config</a>
+ </div>
+ <div class="doc_text">
+ <p>Every project must have a <tt>Makefile.config</tt> at the top of its
+ <em>build</em> directory. This file is <b>generated</b> by the
+ <tt>configure</tt> script from the pattern provided by the
+ <tt>Makefile.config.in</tt> file located at the top of the project's
+ <em>source</em> directory. The contents of this file depend largely on what
+ configuration items the project uses, however most projects can get what they
+ need by just relying on LLVM's configuration found in
+ <tt>$(LLVM_OBJ_ROOT)/Makefile.config</tt>.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection"><a name="Makefile.rules">Makefile.rules</a></div>
+ <div class="doc_text">
+ <p>This file, located at <tt>$(LLVM_SRC_ROOT)/Makefile.rules</tt> is the heart
+ of the LLVM Makefile System. It provides all the logic, dependencies, and
+ rules for building the targets supported by the system. What it does largely
+ depends on the values of <tt>make</tt> <a href="#variables">variables</a> that
+ have been set <em>before</em> <tt>Makefile.rules</tt> is included.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="Comments">Comments</a></div>
+ <div class="doc_text">
+ <p>User Makefiles need not have comments in them unless the construction is
+ unusual or it does not strictly follow the rules and patterns of the LLVM
+ makefile system. Makefile comments are invoked with the pound (#) character.
+ The # character and any text following it, to the end of the line, are ignored
+ by <tt>make</tt>.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="tutorial">Tutorial</a></div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>This section provides some examples of the different kinds of modules you
+ can build with the LLVM makefile system. In general, each directory you
+ provide will build a single object although that object may be composed of
+ additionally compiled components.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="libraries">Libraries</a></div>
+ <div class="doc_text">
+ <p>Only a few variable definitions are needed to build a regular library.
+ Normally, the makefile system will build all the software into a single
+ <tt>libname.o</tt> (pre-linked) object. This means the library is not
+ searchable and that the distinction between compilation units has been
+ dissolved. Optionally, you can ask for a shared library (.so), archive library
+ (.a) or to not have the default (relinked) library built. For example:</p>
+ <pre><tt>
+ LIBRARYNAME = mylib
+ SHARED_LIBRARY = 1
+ ARCHIVE_LIBRARY = 1
+ DONT_BUILD_RELINKED = 1
+ </tt></pre>
+ <p>says to build a library named "mylib" with both a shared library
+ (<tt>mylib.so</tt>) and an archive library (<tt>mylib.a</tt>) version but
+ not to build the relinked object (<tt>mylib.o</tt>). The contents of all the
+ libraries produced will be the same, they are just constructed differently.
+ Note that you normally do not need to specify the sources involved. The LLVM
+ Makefile system will infer the source files from the contents of the source
+ directory.</p>
+ <p>The <tt>LOADABLE_MODULE=1</tt> directive can be used in conjunction with
+ <tt>SHARED_LIBRARY=1</tt> to indicate that the resulting shared library should
+ be openable with the <tt>dlopen</tt> function and searchable with the
+ <tt>dlsym</tt> function (or your operating system's equivalents). While this
+ isn't strictly necessary on Linux and a few other platforms, it is required
+ on systems like HP-UX and Darwin. You should use <tt>LOADABLE_MODULE</tt> for
+ any shared library that you intend to be loaded into an tool via the
+ <tt>-load</tt> option. See the
+ <a href="WritingAnLLVMPass.html#makefile">WritingAnLLVMPass.html</a> document
+ for an example of why you might want to do this.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection"><a name="BCModules">Bitcode Modules</a></div>
+ <div class="doc_text">
+ <p>In some situations, it is desireable to build a single bitcode module from
+ a variety of sources, instead of an archive, shared library, or bitcode
+ library. Bitcode modules can be specified in addition to any of the other
+ types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>
+ variable. For example:</p>
+ <pre><tt>
+ LIBRARYNAME = mylib
+ BYTECODE_LIBRARY = 1
+ MODULE_NAME = mymod
+ </tt></pre>
+ <p>will build a module named <tt>mymod.bc</tt> from the sources in the
+ directory. This module will be an aggregation of all the bitcode modules
+ derived from the sources. The example will also build a bitcode archive
+ containing a bitcode module for each compiled source file. The difference is
+ subtle, but important depending on how the module or library is to be linked.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="LoadableModules">Loadable Modules</a>
+ </div>
+ <div class="doc_text">
+ <p>In some situations, you need to create a loadable module. Loadable modules
+ can be loaded into programs like <tt>opt</tt> or <tt>llc</tt> to specify
+ additional passes to run or targets to support. Loadable modules are also
+ useful for debugging a pass or providing a pass with another package if that
+ pass can't be included in LLVM.</p>
+ <p>LLVM provides complete support for building such a module. All you need to
+ do is use the LOADABLE_MODULE variable in your Makefile. For example, to
+ build a loadable module named <tt>MyMod</tt> that uses the LLVM libraries
+ <tt>LLVMSupport.a</tt> and <tt>LLVMSystem.a</tt>, you would specify:</p>
+ <pre><tt>
+ LIBRARYNAME := MyMod
+ LOADABLE_MODULE := 1
+ LINK_COMPONENTS := support system
+ </tt></pre>
+ <p>Use of the <tt>LOADABLE_MODULE</tt> facility implies several things:</p>
+ <ol>
+ <li>There will be no "lib" prefix on the module. This differentiates it from
+ a standard shared library of the same name.</li>
+ <li>The <a href="#SHARED_LIBRARY">SHARED_LIBRARY</a> variable is turned
+ on.</li>
+ <li>The <a href="#LINK_LIBS_IN_SHARED">LINK_LIBS_IN_SHARED</a> variable
+ is turned on.</li>
+ <li>The <a href="#DONT_BUILD_RELINKED">DONT_BUILD_RELINKED</a> variable
+ is turned on.</li>
+ </ol>
+ <p>A loadable module is loaded by LLVM via the facilities of libtool's libltdl
+ library which is part of <tt>lib/System</tt> implementation.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="tools">Tools</a></div>
+ <div class="doc_text">
+ <p>For building executable programs (tools), you must provide the name of the
+ tool and the names of the libraries you wish to link with the tool. For
+ example:</p>
+ <pre><tt>
+ TOOLNAME = mytool
+ USEDLIBS = mylib
+ LINK_COMPONENTS = support system
+ </tt></pre>
+ <p>says that we are to build a tool name <tt>mytool</tt> and that it requires
+ three libraries: <tt>mylib</tt>, <tt>LLVMSupport.a</tt> and
+ <tt>LLVMSystem.a</tt>.</p>
+ <p>Note that two different variables are use to indicate which libraries are
+ linked: <tt>USEDLIBS</tt> and <tt>LLVMLIBS</tt>. This distinction is necessary
+ to support projects. <tt>LLVMLIBS</tt> refers to the LLVM libraries found in
+ the LLVM object directory. <tt>USEDLIBS</tt> refers to the libraries built by
+ your project. In the case of building LLVM tools, <tt>USEDLIBS</tt> and
+ <tt>LLVMLIBS</tt> can be used interchangeably since the "project" is LLVM
+ itself and <tt>USEDLIBS</tt> refers to the same place as <tt>LLVMLIBS</tt>.
+ </p>
+ <p>Also note that there are two different ways of specifying a library: with a
+ <tt>.a</tt> suffix and without. Without the suffix, the entry refers to the
+ re-linked (.o) file which will include <em>all</em> symbols of the library.
+ This is useful, for example, to include all passes from a library of passes.
+ If the <tt>.a</tt> suffix is used then the library is linked as a searchable
+ library (with the <tt>-l</tt> option). In this case, only the symbols that are
+ unresolved <em>at that point</em> will be resolved from the library, if they
+ exist. Other (unreferenced) symbols will not be included when the <tt>.a</tt>
+ syntax is used. Note that in order to use the <tt>.a</tt> suffix, the library
+ in question must have been built with the <tt>ARCHIVE_LIBRARY</tt> option set.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection"><a name="JIT">JIT Tools</a></div>
+ <div class="doc_text">
+ <p>Many tools will want to use the JIT features of LLVM. To do this, you
+ simply specify that you want an execution 'engine', and the makefiles will
+ automatically link in the appropriate JIT for the host or an interpreter
+ if none is available:</p>
+ <pre><tt>
+ TOOLNAME = my_jit_tool
+ USEDLIBS = mylib
+ LINK_COMPONENTS = engine
+ </tt></pre>
+ <p>Of course, any additional libraries may be listed as other components. To
+ get a full understanding of how this changes the linker command, it is
+ recommended that you:</p>
+ <pre><tt>
+ cd examples/Fibonacci
+ make VERBOSE=1
+ </tt></pre>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="targets">Targets Supported</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>This section describes each of the targets that can be built using the LLVM
+ Makefile system. Any target can be invoked from any directory but not all are
+ applicable to a given directory (e.g. "check", "dist" and "install" will
+ always operate as if invoked from the top level directory).</p>
+
+ <table style="text-align:left">
+ <tr>
+ <th>Target Name</th><th>Implied Targets</th><th>Target Description</th>
+ </tr>
+ <tr><td><a href="#all"><tt>all</tt></a></td><td></td>
+ <td>Compile the software recursively. Default target.
+ </td></tr>
+ <tr><td><a href="#all-local"><tt>all-local</tt></a></td><td></td>
+ <td>Compile the software in the local directory only.
+ </td></tr>
+ <tr><td><a href="#check"><tt>check</tt></a></td><td></td>
+ <td>Change to the <tt>test</tt> directory in a project and run the
+ test suite there.
+ </td></tr>
+ <tr><td><a href="#check-local"><tt>check-local</tt></a></td><td></td>
+ <td>Run a local test suite. Generally this is only defined in the
+ <tt>Makefile</tt> of the project's <tt>test</tt> directory.
+ </td></tr>
+ <tr><td><a href="#clean"><tt>clean</tt></a></td><td></td>
+ <td>Remove built objects recursively.
+ </td></tr>
+ <tr><td><a href="#clean-local"><tt>clean-local</tt></a></td><td></td>
+ <td>Remove built objects from the local directory only.
+ </td></tr>
+ <tr><td><a href="#dist"><tt>dist</tt></a></td><td>all</td>
+ <td>Prepare a source distribution tarball.
+ </td></tr>
+ <tr><td><a href="#dist-check"><tt>dist-check</tt></a></td><td>all</td>
+ <td>Prepare a source distribution tarball and check that it builds.
+ </td></tr>
+ <tr><td><a href="#dist-clean"><tt>dist-clean</tt></a></td><td>clean</td>
+ <td>Clean source distribution tarball temporary files.
+ </td></tr>
+ <tr><td><a href="#install"><tt>install</tt></a></td><td>all</td>
+ <td>Copy built objects to installation directory.
+ </td></tr>
+ <tr><td><a href="#preconditions"><tt>preconditions</tt></a></td><td>all</td>
+ <td>Check to make sure configuration and makefiles are up to date.
+ </td></tr>
+ <tr><td><a href="#printvars"><tt>printvars</tt></a></td><td>all</td>
+ <td>Prints variables defined by the makefile system (for debugging).
+ </td></tr>
+ <tr><td><a href="#tags"><tt>tags</tt></a></td><td></td>
+ <td>Make C and C++ tags files for emacs and vi.
+ </td></tr>
+ <tr><td><a href="#uninstall"><tt>uninstall</tt></a></td><td></td>
+ <td>Remove built objects from installation directory.
+ </td></tr>
+ </table>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="all">all (default)</a></div>
+ <div class="doc_text">
+ <p>When you invoke <tt>make</tt> with no arguments, you are implicitly
+ instructing it to seek the "all" target (goal). This target is used for
+ building the software recursively and will do different things in different
+ directories. For example, in a <tt>lib</tt> directory, the "all" target will
+ compile source files and generate libraries. But, in a <tt>tools</tt>
+ directory, it will link libraries and generate executables.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="all-local">all-local</a></div>
+ <div class="doc_text">
+ <p>This target is the same as <a href="#all">all</a> but it operates only on
+ the current directory instead of recursively.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="check">check</a></div>
+ <div class="doc_text">
+ <p>This target can be invoked from anywhere within a project's directories
+ but always invokes the <a href="#check-local"><tt>check-local</tt></a> target
+ in the project's <tt>test</tt> directory, if it exists and has a
+ <tt>Makefile</tt>. A warning is produced otherwise. If
+ <a href="#TESTSUITE"><tt>TESTSUITE</tt></a> is defined on the <tt>make</tt>
+ command line, it will be passed down to the invocation of
+ <tt>make check-local</tt> in the <tt>test</tt> directory. The intended usage
+ for this is to assist in running specific suites of tests. If
+ <tt>TESTSUITE</tt> is not set, the implementation of <tt>check-local</tt>
+ should run all normal tests. It is up to the project to define what
+ different values for <tt>TESTSUTE</tt> will do. See the
+ <a href="TestingGuide.html">TestingGuide</a> for further details.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="check-local">check-local</a></div>
+ <div class="doc_text">
+ <p>This target should be implemented by the <tt>Makefile</tt> in the project's
+ <tt>test</tt> directory. It is invoked by the <tt>check</tt> target elsewhere.
+ Each project is free to define the actions of <tt>check-local</tt> as
+ appropriate for that project. The LLVM project itself uses dejagnu to run a
+ suite of feature and regresson tests. Other projects may choose to use
+ dejagnu or any other testing mechanism.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="clean">clean</a></div>
+ <div class="doc_text">
+ <p>This target cleans the build directory, recursively removing all things
+ that the Makefile builds. The cleaning rules have been made guarded so they
+ shouldn't go awry (via <tt>rm -f $(UNSET_VARIABLE)/*</tt> which will attempt
+ to erase the entire directory structure.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="clean-local">clean-local</a></div>
+ <div class="doc_text">
+ <p>This target does the same thing as <tt>clean</tt> but only for the current
+ (local) directory.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="dist">dist</a></div>
+ <div class="doc_text">
+ <p>This target builds a distribution tarball. It first builds the entire
+ project using the <tt>all</tt> target and then tars up the necessary files and
+ compresses it. The generated tarball is sufficient for a casual source
+ distribution, but probably not for a release (see <tt>dist-check</tt>).</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="dist-check">dist-check</a></div>
+ <div class="doc_text">
+ <p>This target does the same thing as the <tt>dist</tt> target but also checks
+ the distribution tarball. The check is made by unpacking the tarball to a new
+ directory, configuring it, building it, installing it, and then verifying that
+ the installation results are correct (by comparing to the original build).
+ This target can take a long time to run but should be done before a release
+ goes out to make sure that the distributed tarball can actually be built into
+ a working release.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="dist-clean">dist-clean</a></div>
+ <div class="doc_text">
+ <p>This is a special form of the <tt>clean</tt> clean target. It performs a
+ normal <tt>clean</tt> but also removes things pertaining to building the
+ distribution.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="install">install</a></div>
+ <div class="doc_text">
+ <p>This target finalizes shared objects and executables and copies all
+ libraries, headers, executables and documentation to the directory given
+ with the <tt>--prefix</tt> option to <tt>configure</tt>. When completed,
+ the prefix directory will have everything needed to <b>use</b> LLVM. </p>
+ <p>The LLVM makefiles can generate complete <b>internal</b> documentation
+ for all the classes by using <tt>doxygen</tt>. By default, this feature is
+ <b>not</b> enabled because it takes a long time and generates a massive
+ amount of data (>100MB). If you want this feature, you must configure LLVM
+ with the --enable-doxygen switch and ensure that a modern version of doxygen
+ (1.3.7 or later) is available in your <tt>PATH</tt>. You can download
+ doxygen from
+ <a href="http://www.stack.nl/~dimitri/doxygen/download.html#latestsrc">
+ here</a>.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="preconditions">preconditions</a></div>
+ <div class="doc_text">
+ <p>This utility target checks to see if the <tt>Makefile</tt> in the object
+ directory is older than the <tt>Makefile</tt> in the source directory and
+ copies it if so. It also reruns the <tt>configure</tt> script if that needs to
+ be done and rebuilds the <tt>Makefile.config</tt> file similarly. Users may
+ overload this target to ensure that sanity checks are run <em>before</em> any
+ building of targets as all the targets depend on <tt>preconditions</tt>.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="printvars">printvars</a></div>
+ <div class="doc_text">
+ <p>This utility target just causes the LLVM makefiles to print out some of
+ the makefile variables so that you can double check how things are set. </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="reconfigure">reconfigure</a></div>
+ <div class="doc_text">
+ <p>This utility target will force a reconfigure of LLVM or your project. It
+ simply runs <tt>$(PROJ_OBJ_ROOT)/config.status --recheck</tt> to rerun the
+ configuration tests and rebuild the configured files. This isn't generally
+ useful as the makefiles will reconfigure themselves whenever its necessary.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="spotless">spotless</a></div>
+ <div class="doc_text">
+ <p>This utility target, only available when <tt>$(PROJ_OBJ_ROOT)</tt> is not
+ the same as <tt>$(PROJ_SRC_ROOT)</tt>, will completely clean the
+ <tt>$(PROJ_OBJ_ROOT)</tt> directory by removing its content entirely and
+ reconfiguring the directory. This returns the <tt>$(PROJ_OBJ_ROOT)</tt>
+ directory to a completely fresh state. All content in the directory except
+ configured files and top-level makefiles will be lost.</p>
+ <div class="doc_warning"><p>Use with caution.</p></div>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="tags">tags</a></div>
+ <div class="doc_text">
+ <p>This target will generate a <tt>TAGS</tt> file in the top-level source
+ directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file
+ provides an index of symbol definitions so that the editor can jump you to the
+ definition quickly. </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="uninstall">uninstall</a></div>
+ <div class="doc_text">
+ <p>This target is the opposite of the <tt>install</tt> target. It removes the
+ header, library and executable files from the installation directories. Note
+ that the directories themselves are not removed because it is not guaranteed
+ that LLVM is the only thing installing there (e.g. --prefix=/usr).</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="variables">Variables</a></div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>Variables are used to tell the LLVM Makefile System what to do and to
+ obtain information from it. Variables are also used internally by the LLVM
+ Makefile System. Variable names that contain only the upper case alphabetic
+ letters and underscore are intended for use by the end user. All other
+ variables are internal to the LLVM Makefile System and should not be relied
+ upon nor modified. The sections below describe how to use the LLVM Makefile
+ variables.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="setvars">Control Variables</a></div>
+ <div class="doc_text">
+ <p>Variables listed in the table below should be set <em>before</em> the
+ inclusion of <a href="#Makefile.common"><tt>$(LEVEL)/Makefile.common</tt></a>.
+ These variables provide input to the LLVM make system that tell it what to do
+ for the current directory.</p>
+ <dl>
+ <dt><a name="BUILD_ARCHIVE"><tt>BUILD_ARCHIVE</tt></a></dt>
+ <dd>If set to any value, causes an archive (.a) library to be built.</dd>
+ <dt><a name="BUILT_SOURCES"><tt>BUILT_SOURCES</tt></a></dt>
+ <dd>Specifies a set of source files that are generated from other source
+ files. These sources will be built before any other target processing to
+ ensure they are present.</dd>
+ <dt><a name="BYTECODE_LIBRARY"><tt>BYTECODE_LIBRARY</tt></a></dt>
+ <dd>If set to any value, causes a bitcode library (.bc) to be built.</dd>
+ <dt><a name="CONFIG_FILES"><tt>CONFIG_FILES</tt></a></dt>
+ <dd>Specifies a set of configuration files to be installed.</dd>
+ <dt><a name="DIRS"><tt>DIRS</tt></a></dt>
+ <dd>Specifies a set of directories, usually children of the current
+ directory, that should also be made using the same goal. These directories
+ will be built serially.</dd>
+ <dt><a name="DISABLE_AUTO_DEPENDENCIES"><tt>DISABLE_AUTO_DEPENDENCIES</tt></a></dt>
+ <dd>If set to any value, causes the makefiles to <b>not</b> automatically
+ generate dependencies when running the compiler. Use of this feature is
+ discouraged and it may be removed at a later date.</dd>
+ <dt><a name="DONT_BUILD_RELINKED"><tt>DONT_BUILD_RELINKED</tt></a></dt>
+ <dd>If set to any value, causes a relinked library (.o) not to be built. By
+ default, libraries are built as re-linked since most LLVM libraries are
+ needed in their entirety and re-linked libraries will be linked more quickly
+ than equivalent archive libraries.</dd>
+ <dt><a name="ENABLE_OPTIMIZED"><tt>ENABLE_OPTIMIZED</tt></a></dt>
+ <dd>If set to any value, causes the build to generate optimized objects,
+ libraries and executables. This alters the flags specified to the compilers
+ and linkers. Generally debugging won't be a fun experience with an optimized
+ build.</dd>
+ <dt><a name="ENABLE_PROFILING"><tt>ENABLE_PROFILING</tt></a></dt>
+ <dd>If set to any value, causes the build to generate both optimized and
+ profiled objects, libraries and executables. This alters the flags specified
+ to the compilers and linkers to ensure that profile data can be collected
+ from the tools built. Use the <tt>gprof</tt> tool to analyze the output from
+ the profiled tools (<tt>gmon.out</tt>).</dd>
+ <dt><a name="DISABLE_ASSERTIONS"><tt>DISABLE_ASSERTIONS</tt></a></dt>
+ <dd>If set to any value, causes the build to disable assertions, even if
+ building a release or profile build. This will exclude all assertion check
+ code from the build. LLVM will execute faster, but with little help when
+ things go wrong.</dd>
+ <dt><a name="EXPERIMENTAL_DIRS"><tt>EXPERIMENTAL_DIRS</tt></a></dt>
+ <dd>Specify a set of directories that should be built, but if they fail, it
+ should not cause the build to fail. Note that this should only be used
+ temporarily while code is being written.</dd>
+ <dt><a name="EXPORTED_SYMBOL_FILE"><tt>EXPORTED_SYMBOL_FILE</tt></a></dt>
+ <dd>Specifies the name of a single file that contains a list of the
+ symbols to be exported by the linker. One symbol per line.</dd>
+ <dt><a name="EXPORTED_SYMBOL_LIST"><tt>EXPORTED_SYMBOL_LIST</tt></a></dt>
+ <dd>Specifies a set of symbols to be exported by the linker.</dd>
+ <dt><a name="EXTRA_DIST"><tt>EXTRA_DIST</tt></a></dt>
+ <dd>Specifies additional files that should be distributed with LLVM. All
+ source files, all built sources, all Makefiles, and most documentation files
+ will be automatically distributed. Use this variable to distribute any
+ files that are not automatically distributed.</dd>
+ <dt><a name="KEEP_SYMBOLS"><tt>KEEP_SYMBOLS</tt></a></dt>
+ <dd>If set to any value, specifies that when linking executables the
+ makefiles should retain debug symbols in the executable. Normally, symbols
+ are stripped from the executable.</dd>
+ <dt><a name="LEVEL"><tt>LEVEL</tt></a><small>(required)</small></dt>
+ <dd>Specify the level of nesting from the top level. This variable must be
+ set in each makefile as it is used to find the top level and thus the other
+ makefiles.</dd>
+ <dt><a name="LIBRARYNAME"><tt>LIBRARYNAME</tt></a></dt>
+ <dd>Specify the name of the library to be built. (Required For
+ Libraries)</dd>
+ <dt><a name="LINK_COMPONENTS"><tt>LINK_COMPONENTS</tt></a></dt>
+ <dd>When specified for building a tool, the value of this variable will be
+ passed to the <tt>llvm-config</tt> tool to generate a link line for the
+ tool. Unlike <tt>USEDLIBS</tt> and <tt>LLVMLIBS</tt>, not all libraries need
+ to be specified. The <tt>llvm-config</tt> tool will figure out the library
+ dependencies and add any libraries that are needed. The <tt>USEDLIBS</tt>
+ variable can still be used in conjunction with <tt>LINK_COMPONENTS</tt> so
+ that additional project-specific libraries can be linked with the LLVM
+ libraries specified by <tt>LINK_COMPONENTS</tt></dd>
+ <dt><a name="LINK_LIBS_IN_SHARED"><tt>LINK_LIBS_IN_SHARED</tt></a></dt>
+ <dd>By default, shared library linking will ignore any libraries specified
+ with the <a href="LLVMLIBS">LLVMLIBS</a> or <a href="USEDLIBS">USEDLIBS</a>.
+ This prevents shared libs from including things that will be in the LLVM
+ tool the shared library will be loaded into. However, sometimes it is useful
+ to link certain libraries into your shared library and this option enables
+ that feature.</dd>
+ <dt><a name="LLVMLIBS"><tt>LLVMLIBS</tt></a></dt>
+ <dd>Specifies the set of libraries from the LLVM $(ObjDir) that will be
+ linked into the tool or library.</dd>
+ <dt><a name="LOADABLE_MODULE"><tt>LOADABLE_MODULE</tt></a></dt>
+ <dd>If set to any value, causes the shared library being built to also be
+ a loadable module. Loadable modules can be opened with the dlopen() function
+ and searched with dlsym (or the operating system's equivalent). Note that
+ setting this variable without also setting <tt>SHARED_LIBRARY</tt> will have
+ no effect.</dd>
+ <dt><a name="MODULE_NAME"><tt>MODULE_NAME</tt></a></dt>
+ <dd>Specifies the name of a bitcode module to be created. A bitcode
+ module can be specified in conjunction with other kinds of library builds
+ or by itself. It constructs from the sources a single linked bitcode
+ file.</dd>
+ <dt><a name="NO_INSTALL"><tt>NO_INSTALL</tt></a></dt>
+ <dd>Specifies that the build products of the directory should not be
+ installed but should be built even if the <tt>install</tt> target is given.
+ This is handy for directories that build libraries or tools that are only
+ used as part of the build process, such as code generators (e.g.
+ <tt>tblgen</tt>).</dd>
+ <dt><a name="OPTIONAL_DIRS"><tt>OPTIONAL_DIRS</tt></a></dt>
+ <dd>Specify a set of directories that may be built, if they exist, but its
+ not an error for them not to exist.</dd>
+ <dt><a name="PARALLEL_DIRS"><tt>PARALLEL_DIRS</tt></a></dt>
+ <dd>Specify a set of directories to build recursively and in parallel if
+ the -j option was used with <tt>make</tt>.</dd>
+ <dt><a name="SHARED_LIBRARY"><tt>SHARED_LIBRARY</tt></a></dt>
+ <dd>If set to any value, causes a shared library (.so) to be built in
+ addition to any other kinds of libraries. Note that this option will cause
+ all source files to be built twice: once with options for position
+ independent code and once without. Use it only where you really need a
+ shared library.</dd>
+ <dt><a name="SOURCES"><tt>SOURCES</tt><small>(optional)</small></a></dt>
+ <dd>Specifies the list of source files in the current directory to be
+ built. Source files of any type may be specified (programs, documentation,
+ config files, etc.). If not specified, the makefile system will infer the
+ set of source files from the files present in the current directory.</dd>
+ <dt><a name="SUFFIXES"><tt>SUFFIXES</tt></a></dt>
+ <dd>Specifies a set of filename suffixes that occur in suffix match rules.
+ Only set this if your local <tt>Makefile</tt> specifies additional suffix
+ match rules.</dd>
+ <dt><a name="TARGET"><tt>TARGET</tt></a></dt>
+ <dd>Specifies the name of the LLVM code generation target that the
+ current directory builds. Setting this variable enables additional rules to
+ build <tt>.inc</tt> files from <tt>.td</tt> files. </dd>
+ <dt><a name="TESTSUITE"><tt>TESTSUITE</tt></a></dt>
+ <dd>Specifies the directory of tests to run in <tt>llvm/test</tt>.</dd>
+ <dt><a name="TOOLNAME"><tt>TOOLNAME</tt></a></dt>
+ <dd>Specifies the name of the tool that the current directory should
+ build.</dd>
+ <dt><a name="TOOL_VERBOSE"><tt>TOOL_VERBOSE</tt></a></dt>
+ <dd>Implies VERBOSE and also tells each tool invoked to be verbose. This is
+ handy when you're trying to see the sub-tools invoked by each tool invoked
+ by the makefile. For example, this will pass <tt>-v</tt> to the GCC
+ compilers which causes it to print out the command lines it uses to invoke
+ sub-tools (compiler, assembler, linker).</dd>
+ <dt><a name="USEDLIBS"><tt>USEDLIBS</tt></a></dt>
+ <dd>Specifies the list of project libraries that will be linked into the
+ tool or library.</dd>
+ <dt><a name="VERBOSE"><tt>VERBOSE</tt></a></dt>
+ <dd>Tells the Makefile system to produce detailed output of what it is doing
+ instead of just summary comments. This will generate a LOT of output.</dd>
+ </dl>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="overvars">Override Variables</a></div>
+ <div class="doc_text">
+ <p>Override variables can be used to override the default
+ values provided by the LLVM makefile system. These variables can be set in
+ several ways:</p>
+ <ul>
+ <li>In the environment (e.g. setenv, export) -- not recommended.</li>
+ <li>On the <tt>make</tt> command line -- recommended.</li>
+ <li>On the <tt>configure</tt> command line</li>
+ <li>In the Makefile (only <em>after</em> the inclusion of <a
+ href="#Makefile.common"><tt>$(LEVEL)/Makefile.common</tt></a>).</li>
+ </ul>
+ <p>The override variables are given below:</p>
+ <dl>
+ <dt><a name="AR"><tt>AR</tt></a> <small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>ar</tt> tool.</dd>
+ <dt><a name="PROJ_OBJ_DIR"><tt>PROJ_OBJ_DIR</tt></a></dt>
+ <dd>The directory into which the products of build rules will be placed.
+ This might be the same as
+ <a href="#PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a> but typically is
+ not.</dd>
+ <dt><a name="PROJ_SRC_DIR"><tt>PROJ_SRC_DIR</tt></a></dt>
+ <dd>The directory which contains the source files to be built.</dd>
+ <dt><a name="BZIP2"><tt>BZIP2</tt></a><small>(configured)</small></dt>
+ <dd>The path to the <tt>bzip2</tt> tool.</dd>
+ <dt><a name="CC"><tt>CC</tt></a><small>(configured)</small></dt>
+ <dd>The path to the 'C' compiler.</dd>
+ <dt><a name="CFLAGS"><tt>CFLAGS</tt></a></dt>
+ <dd>Additional flags to be passed to the 'C' compiler.</dd>
+ <dt><a name="CXX"><tt>CXX</tt></a></dt>
+ <dd>Specifies the path to the C++ compiler.</dd>
+ <dt><a name="CXXFLAGS"><tt>CXXFLAGS</tt></a></dt>
+ <dd>Additional flags to be passed to the C++ compiler.</dd>
+ <dt><a name="DATE"><tt>DATE<small>(configured)</small></tt></a></dt>
+ <dd>Specifies the path to the <tt>date</tt> program or any program that can
+ generate the current date and time on its standard output</dd>
+ <dt><a name="DOT"><tt>DOT</tt></a><small>(configured)</small></dt>
+ <dd>Specifies the path to the <tt>dot</tt> tool or <tt>false</tt> if there
+ isn't one.</dd>
+ <dt><a name="ECHO"><tt>ECHO</tt></a><small>(configured)</small></dt>
+ <dd>Specifies the path to the <tt>echo</tt> tool for printing output.</dd>
+ <dt><a name="EXEEXT"><tt>EXEEXT</tt></a><small>(configured)</small></dt>
+ <dd>Provides the extension to be used on executables built by the makefiles.
+ The value may be empty on platforms that do not use file extensions for
+ executables (e.g. Unix).</dd>
+ <dt><a name="INSTALL"><tt>INSTALL</tt></a><small>(configured)</small></dt>
+ <dd>Specifies the path to the <tt>install</tt> tool.</dd>
+ <dt><a name="LDFLAGS"><tt>LDFLAGS</tt></a><small>(configured)</small></dt>
+ <dd>Allows users to specify additional flags to pass to the linker.</dd>
+ <dt><a name="LIBS"><tt>LIBS</tt></a><small>(configured)</small></dt>
+ <dd>The list of libraries that should be linked with each tool.</dd>
+ <dt><a name="LIBTOOL"><tt>LIBTOOL</tt></a><small>(configured)</small></dt>
+ <dd>Specifies the path to the <tt>libtool</tt> tool. This tool is renamed
+ <tt>mklib</tt> by the <tt>configure</tt> script and always located in the
+ <dt><a name="LLVMAS"><tt>LLVMAS</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>llvm-as</tt> tool.</dd>
+ <dt><a name="LLVMGCC"><tt>LLVMGCC</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the LLVM version of the GCC 'C' Compiler</dd>
+ <dt><a name="LLVMGXX"><tt>LLVMGXX</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the LLVM version of the GCC C++ Compiler</dd>
+ <dt><a name="LLVMLD"><tt>LLVMLD</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the LLVM bitcode linker tool</dd>
+ <dt><a name="LLVM_OBJ_ROOT"><tt>LLVM_OBJ_ROOT</tt></a><small>(configured)
+ </small></dt>
+ <dd>Specifies the top directory into which the output of the build is
+ placed.</dd>
+ <dt><a name="LLVM_SRC_ROOT"><tt>LLVM_SRC_ROOT</tt></a><small>(configured)
+ </small></dt>
+ <dd>Specifies the top directory in which the sources are found.</dd>
+ <dt><a name="LLVM_TARBALL_NAME"><tt>LLVM_TARBALL_NAME</tt></a>
+ <small>(configured)</small></dt>
+ <dd>Specifies the name of the distribution tarball to create. This is
+ configured from the name of the project and its version number.</dd>
+ <dt><a name="MKDIR"><tt>MKDIR</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>mkdir</tt> tool that creates
+ directories.</dd>
+ <dt><a name="PLATFORMSTRIPOPTS"><tt>PLATFORMSTRIPOPTS</tt></a></dt>
+ <dd>The options to provide to the linker to specify that a stripped (no
+ symbols) executable should be built.</dd>
+ <dt><a name="RANLIB"><tt>RANLIB</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>ranlib</tt> tool.</dd>
+ <dt><a name="RM"><tt>RM</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>rm</tt> tool.</dd>
+ <dt><a name="SED"><tt>SED</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>sed</tt> tool.</dd>
+ <dt><a name="SHLIBEXT"><tt>SHLIBEXT</tt></a><small>(configured)</small></dt>
+ <dd>Provides the filename extension to use for shared libraries.</dd>
+ <dt><a name="TBLGEN"><tt>TBLGEN</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>tblgen</tt> tool.</dd>
+ <dt><a name="TAR"><tt>TAR</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>tar</tt> tool.</dd>
+ <dt><a name="ZIP"><tt>ZIP</tt></a><small>(defaulted)</small></dt>
+ <dd>Specifies the path to the <tt>zip</tt> tool.</dd>
+ </dl>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="getvars">Readable Variables</a></div>
+ <div class="doc_text">
+ <p>Variables listed in the table below can be used by the user's Makefile but
+ should not be changed. Changing the value will generally cause the build to go
+ wrong, so don't do it.</p>
+ <dl>
+ <dt><a name="bindir"><tt>bindir</tt></a></dt>
+ <dd>The directory into which executables will ultimately be installed. This
+ value is derived from the <tt>--prefix</tt> option given to
+ <tt>configure</tt>.</dd>
+ <dt><a name="BuildMode"><tt>BuildMode</tt></a></dt>
+ <dd>The name of the type of build being performed: Debug, Release, or
+ Profile</dd>
+ <dt><a name="bitcode_libdir"><tt>bytecode_libdir</tt></a></dt>
+ <dd>The directory into which bitcode libraries will ultimately be
+ installed. This value is derived from the <tt>--prefix</tt> option given to
+ <tt>configure</tt>.</dd>
+ <dt><a name="ConfigureScriptFLAGS"><tt>ConfigureScriptFLAGS</tt></a></dt>
+ <dd>Additional flags given to the <tt>configure</tt> script when
+ reconfiguring.</dd>
+ <dt><a name="DistDir"><tt>DistDir</tt></a></dt>
+ <dd>The <em>current</em> directory for which a distribution copy is being
+ made.</dd>
+ <dt><a name="Echo"><tt>Echo</tt></a></dt>
+ <dd>The LLVM Makefile System output command. This provides the
+ <tt>llvm[n]</tt> prefix and starts with @ so the command itself is not
+ printed by <tt>make</tt>.</dd>
+ <dt><a name="EchoCmd"><tt>EchoCmd</tt></a></dt>
+ <dd> Same as <a href="#Echo"><tt>Echo</tt></a> but without the leading @.
+ </dd>
+ <dt><a name="includedir"><tt>includedir</tt></a></dt>
+ <dd>The directory into which include files will ultimately be installed.
+ This value is derived from the <tt>--prefix</tt> option given to
+ <tt>configure</tt>.</dd>
+ <dt><a name="libdir"><tt>libdir</tt></a></dt><dd></dd>
+ <dd>The directory into which native libraries will ultimately be installed.
+ This value is derived from the <tt>--prefix</tt> option given to
+ <tt>configure</tt>.</dd>
+ <dt><a name="LibDir"><tt>LibDir</tt></a></dt>
+ <dd>The configuration specific directory into which libraries are placed
+ before installation.</dd>
+ <dt><a name="MakefileConfig"><tt>MakefileConfig</tt></a></dt>
+ <dd>Full path of the <tt>Makefile.config</tt> file.</dd>
+ <dt><a name="MakefileConfigIn"><tt>MakefileConfigIn</tt></a></dt>
+ <dd>Full path of the <tt>Makefile.config.in</tt> file.</dd>
+ <dt><a name="ObjDir"><tt>ObjDir</tt></a></dt>
+ <dd>The configuration and directory specific directory where build objects
+ (compilation results) are placed.</dd>
+ <dt><a name="SubDirs"><tt>SubDirs</tt></a></dt>
+ <dd>The complete list of sub-directories of the current directory as
+ specified by other variables.</dd>
+ <dt><a name="Sources"><tt>Sources</tt></a></dt>
+ <dd>The complete list of source files.</dd>
+ <dt><a name="sysconfdir"><tt>sysconfdir</tt></a></dt>
+ <dd>The directory into which configuration files will ultimately be
+ installed. This value is derived from the <tt>--prefix</tt> option given to
+ <tt>configure</tt>.</dd>
+ <dt><a name="ToolDir"><tt>ToolDir</tt></a></dt>
+ <dd>The configuration specific directory into which executables are placed
+ before they are installed.</dd>
+ <dt><a name="TopDistDir"><tt>TopDistDir</tt></a></dt>
+ <dd>The top most directory into which the distribution files are copied.
+ </dd>
+ <dt><a name="Verb"><tt>Verb</tt></a></dt>
+ <dd>Use this as the first thing on your build script lines to enable or
+ disable verbose mode. It expands to either an @ (quiet mode) or nothing
+ (verbose mode). </dd>
+ </dl>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="intvars">Internal Variables</a></div>
+ <div class="doc_text">
+ <p>Variables listed below are used by the LLVM Makefile System
+ and considered internal. You should not use these variables under any
+ circumstances.</p>
+ <p><tt>
+ Archive
+ AR.Flags
+ BaseNameSources
+ BCCompile.C
+ BCCompile.CXX
+ BCLinkLib
+ C.Flags
+ Compile.C
+ CompileCommonOpts
+ Compile.CXX
+ ConfigStatusScript
+ ConfigureScript
+ CPP.Flags
+ CPP.Flags
+ CXX.Flags
+ DependFiles
+ DestArchiveLib
+ DestBitcodeLib
+ DestModule
+ DestRelinkedLib
+ DestSharedLib
+ DestTool
+ DistAlways
+ DistCheckDir
+ DistCheckTop
+ DistFiles
+ DistName
+ DistOther
+ DistSources
+ DistSubDirs
+ DistTarBZ2
+ DistTarGZip
+ DistZip
+ ExtraLibs
+ FakeSources
+ INCFiles
+ InternalTargets
+ LD.Flags
+ LibName.A
+ LibName.BC
+ LibName.LA
+ LibName.O
+ LibTool.Flags
+ Link
+ LinkModule
+ LLVMLibDir
+ LLVMLibsOptions
+ LLVMLibsPaths
+ LLVMToolDir
+ LLVMUsedLibs
+ LocalTargets
+ LTCompile.C
+ LTCompile.CXX
+ LTInstall
+ Module
+ ObjectsBC
+ ObjectsLO
+ ObjectsO
+ ObjMakefiles
+ ParallelTargets
+ PreConditions
+ ProjLibsOptions
+ ProjLibsPaths
+ ProjUsedLibs
+ Ranlib
+ RecursiveTargets
+ Relink
+ SrcMakefiles
+ Strip
+ StripWarnMsg
+ TableGen
+ TDFiles
+ ToolBuildPath
+ TopLevelTargets
+ UserTargets
+ </tt></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:rspencer at x10sys.com">Reid Spencer</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/Passes.html
diff -c /dev/null llvm-www/releases/2.5/docs/Passes.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/Passes.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1970 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM's Analysis and Transform Passes</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ </head>
+ <body>
+
+ <!--
+
+ If Passes.html is up to date, the following "one-liner" should print
+ an empty diff.
+
+ egrep -e '^<tr><td><a href="#.*">-.*</a></td><td>.*</td></tr>$' \
+ -e '^ <a name=".*">.*</a>$' < Passes.html >html; \
+ perl >help <<'EOT' && diff -u help html; rm -f help html
+ open HTML, "<Passes.html" or die "open: Passes.html: $!\n";
+ while (<HTML>) {
+ m:^<tr><td><a href="#(.*)">-.*</a></td><td>.*</td></tr>$: or next;
+ $order{$1} = sprintf("%03d", 1 + int %order);
+ }
+ open HELP, "../Release/bin/opt -help|" or die "open: opt -help: $!\n";
+ while (<HELP>) {
+ m:^ -([^ ]+) +- (.*)$: or next;
+ my $o = $order{$1};
+ $o = "000" unless defined $o;
+ push @x, "$o<tr><td><a href=\"#$1\">-$1</a></td><td>$2</td></tr>\n";
+ push @y, "$o <a name=\"$1\">$2</a>\n";
+ }
+ @x = map { s/^\d\d\d//; $_ } sort @x;
+ @y = map { s/^\d\d\d//; $_ } sort @y;
+ print @x, @y;
+ EOT
+
+ This (real) one-liner can also be helpful when converting comments to HTML:
+
+ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print " <p>\n" if !$on && $_ =~ /\S/; print " </p>\n" if $on && $_ =~ /^\s*$/; print " $_\n"; $on = ($_ =~ /\S/); } print " </p>\n" if $on'
+
+ -->
+
+ <div class="doc_title">LLVM's Analysis and Transform Passes</div>
+
+ <ol>
+ <li><a href="#intro">Introduction</a></li>
+ <li><a href="#analyses">Analysis Passes</a>
+ <li><a href="#transforms">Transform Passes</a></li>
+ <li><a href="#utilities">Utility Passes</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a>
+ and Gordon Henriksen</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"> <a name="intro">Introduction</a> </div>
+ <div class="doc_text">
+ <p>This document serves as a high level summary of the optimization features
+ that LLVM provides. Optimizations are implemented as Passes that traverse some
+ portion of a program to either collect information or transform the program.
+ The table below divides the passes that LLVM provides into three categories.
+ Analysis passes compute information that other passes can use or for debugging
+ or program visualization purposes. Transform passes can use (or invalidate)
+ the analysis passes. Transform passes all mutate the program in some way.
+ Utility passes provides some utility but don't otherwise fit categorization.
+ For example passes to extract functions to bitcode or write a module to
+ bitcode are neither analysis nor transform passes.
+ <p>The table below provides a quick summary of each pass and links to the more
+ complete pass description later in the document.</p>
+ </div>
+ <div class="doc_text" >
+ <table>
+ <tr><th colspan="2"><b>ANALYSIS PASSES</b></th></tr>
+ <tr><th>Option</th><th>Name</th></tr>
+ <tr><td><a href="#aa-eval">-aa-eval</a></td><td>Exhaustive Alias Analysis Precision Evaluator</td></tr>
+ <tr><td><a href="#anders-aa">-anders-aa</a></td><td>Andersen's Interprocedural Alias Analysis</td></tr>
+ <tr><td><a href="#basicaa">-basicaa</a></td><td>Basic Alias Analysis (default AA impl)</td></tr>
+ <tr><td><a href="#basiccg">-basiccg</a></td><td>Basic CallGraph Construction</td></tr>
+ <tr><td><a href="#basicvn">-basicvn</a></td><td>Basic Value Numbering (default GVN impl)</td></tr>
+ <tr><td><a href="#codegenprepare">-codegenprepare</a></td><td>Optimize for code generation</td></tr>
+ <tr><td><a href="#count-aa">-count-aa</a></td><td>Count Alias Analysis Query Responses</td></tr>
+ <tr><td><a href="#debug-aa">-debug-aa</a></td><td>AA use debugger</td></tr>
+ <tr><td><a href="#domfrontier">-domfrontier</a></td><td>Dominance Frontier Construction</td></tr>
+ <tr><td><a href="#domtree">-domtree</a></td><td>Dominator Tree Construction</td></tr>
+ <tr><td><a href="#dot-callgraph">-dot-callgraph</a></td><td>Print Call Graph to 'dot' file</td></tr>
+ <tr><td><a href="#dot-cfg">-dot-cfg</a></td><td>Print CFG of function to 'dot' file</td></tr>
+ <tr><td><a href="#dot-cfg-only">-dot-cfg-only</a></td><td>Print CFG of function to 'dot' file (with no function bodies)</td></tr>
+ <tr><td><a href="#globalsmodref-aa">-globalsmodref-aa</a></td><td>Simple mod/ref analysis for globals</td></tr>
+ <tr><td><a href="#instcount">-instcount</a></td><td>Counts the various types of Instructions</td></tr>
+ <tr><td><a href="#intervals">-intervals</a></td><td>Interval Partition Construction</td></tr>
+ <tr><td><a href="#load-vn">-load-vn</a></td><td>Load Value Numbering</td></tr>
+ <tr><td><a href="#loops">-loops</a></td><td>Natural Loop Construction</td></tr>
+ <tr><td><a href="#memdep">-memdep</a></td><td>Memory Dependence Analysis</td></tr>
+ <tr><td><a href="#no-aa">-no-aa</a></td><td>No Alias Analysis (always returns 'may' alias)</td></tr>
+ <tr><td><a href="#no-profile">-no-profile</a></td><td>No Profile Information</td></tr>
+ <tr><td><a href="#postdomfrontier">-postdomfrontier</a></td><td>Post-Dominance Frontier Construction</td></tr>
+ <tr><td><a href="#postdomtree">-postdomtree</a></td><td>Post-Dominator Tree Construction</td></tr>
+ <tr><td><a href="#print-alias-sets">-print-alias-sets</a></td><td>Alias Set Printer</td></tr>
+ <tr><td><a href="#print-callgraph">-print-callgraph</a></td><td>Print a call graph</td></tr>
+ <tr><td><a href="#print-callgraph-sccs">-print-callgraph-sccs</a></td><td>Print SCCs of the Call Graph</td></tr>
+ <tr><td><a href="#print-cfg-sccs">-print-cfg-sccs</a></td><td>Print SCCs of each function CFG</td></tr>
+ <tr><td><a href="#print-externalfnconstants">-print-externalfnconstants</a></td><td>Print external fn callsites passed constants</td></tr>
+ <tr><td><a href="#print-function">-print-function</a></td><td>Print function to stderr</td></tr>
+ <tr><td><a href="#print-module">-print-module</a></td><td>Print module to stderr</td></tr>
+ <tr><td><a href="#print-used-types">-print-used-types</a></td><td>Find Used Types</td></tr>
+ <tr><td><a href="#profile-loader">-profile-loader</a></td><td>Load profile information from llvmprof.out</td></tr>
+ <tr><td><a href="#scalar-evolution">-scalar-evolution</a></td><td>Scalar Evolution Analysis</td></tr>
+ <tr><td><a href="#targetdata">-targetdata</a></td><td>Target Data Layout</td></tr>
+
+
+ <tr><th colspan="2"><b>TRANSFORM PASSES</b></th></tr>
+ <tr><th>Option</th><th>Name</th></tr>
+ <tr><td><a href="#adce">-adce</a></td><td>Aggressive Dead Code Elimination</td></tr>
+ <tr><td><a href="#argpromotion">-argpromotion</a></td><td>Promote 'by reference' arguments to scalars</td></tr>
+ <tr><td><a href="#block-placement">-block-placement</a></td><td>Profile Guided Basic Block Placement</td></tr>
+ <tr><td><a href="#break-crit-edges">-break-crit-edges</a></td><td>Break critical edges in CFG</td></tr>
+ <tr><td><a href="#codegenprepare">-codegenprepare</a></td><td>Prepare a function for code generation </td></tr>
+ <tr><td><a href="#condprop">-condprop</a></td><td>Conditional Propagation</td></tr>
+ <tr><td><a href="#constmerge">-constmerge</a></td><td>Merge Duplicate Global Constants</td></tr>
+ <tr><td><a href="#constprop">-constprop</a></td><td>Simple constant propagation</td></tr>
+ <tr><td><a href="#dce">-dce</a></td><td>Dead Code Elimination</td></tr>
+ <tr><td><a href="#deadargelim">-deadargelim</a></td><td>Dead Argument Elimination</td></tr>
+ <tr><td><a href="#deadtypeelim">-deadtypeelim</a></td><td>Dead Type Elimination</td></tr>
+ <tr><td><a href="#die">-die</a></td><td>Dead Instruction Elimination</td></tr>
+ <tr><td><a href="#dse">-dse</a></td><td>Dead Store Elimination</td></tr>
+ <tr><td><a href="#gcse">-gcse</a></td><td>Global Common Subexpression Elimination</td></tr>
+ <tr><td><a href="#globaldce">-globaldce</a></td><td>Dead Global Elimination</td></tr>
+ <tr><td><a href="#globalopt">-globalopt</a></td><td>Global Variable Optimizer</td></tr>
+ <tr><td><a href="#gvn">-gvn</a></td><td>Global Value Numbering</td></tr>
+ <tr><td><a href="#gvnpre">-gvnpre</a></td><td>Global Value Numbering/Partial Redundancy Elimination</td></tr>
+ <tr><td><a href="#indmemrem">-indmemrem</a></td><td>Indirect Malloc and Free Removal</td></tr>
+ <tr><td><a href="#indvars">-indvars</a></td><td>Canonicalize Induction Variables</td></tr>
+ <tr><td><a href="#inline">-inline</a></td><td>Function Integration/Inlining</td></tr>
+ <tr><td><a href="#insert-block-profiling">-insert-block-profiling</a></td><td>Insert instrumentation for block profiling</td></tr>
+ <tr><td><a href="#insert-edge-profiling">-insert-edge-profiling</a></td><td>Insert instrumentation for edge profiling</td></tr>
+ <tr><td><a href="#insert-function-profiling">-insert-function-profiling</a></td><td>Insert instrumentation for function profiling</td></tr>
+ <tr><td><a href="#insert-null-profiling-rs">-insert-null-profiling-rs</a></td><td>Measure profiling framework overhead</td></tr>
+ <tr><td><a href="#insert-rs-profiling-framework">-insert-rs-profiling-framework</a></td><td>Insert random sampling instrumentation framework</td></tr>
+ <tr><td><a href="#instcombine">-instcombine</a></td><td>Combine redundant instructions</td></tr>
+ <tr><td><a href="#internalize">-internalize</a></td><td>Internalize Global Symbols</td></tr>
+ <tr><td><a href="#ipconstprop">-ipconstprop</a></td><td>Interprocedural constant propagation</td></tr>
+ <tr><td><a href="#ipsccp">-ipsccp</a></td><td>Interprocedural Sparse Conditional Constant Propagation</td></tr>
+ <tr><td><a href="#jump-threading">-jump-threading</a></td><td>Thread control through conditional blocks </td></tr>
+ <tr><td><a href="#lcssa">-lcssa</a></td><td>Loop-Closed SSA Form Pass</td></tr>
+ <tr><td><a href="#licm">-licm</a></td><td>Loop Invariant Code Motion</td></tr>
+ <tr><td><a href="#loop-deletion">-loop-deletion</a></td><td>Dead Loop Deletion Pass </td></tr>
+ <tr><td><a href="#loop-extract">-loop-extract</a></td><td>Extract loops into new functions</td></tr>
+ <tr><td><a href="#loop-extract-single">-loop-extract-single</a></td><td>Extract at most one loop into a new function</td></tr>
+ <tr><td><a href="#loop-index-split">-loop-index-split</a></td><td>Index Split Loops</td></tr>
+ <tr><td><a href="#loop-reduce">-loop-reduce</a></td><td>Loop Strength Reduction</td></tr>
+ <tr><td><a href="#loop-rotate">-loop-rotate</a></td><td>Rotate Loops</td></tr>
+ <tr><td><a href="#loop-unroll">-loop-unroll</a></td><td>Unroll loops</td></tr>
+ <tr><td><a href="#loop-unswitch">-loop-unswitch</a></td><td>Unswitch loops</td></tr>
+ <tr><td><a href="#loopsimplify">-loopsimplify</a></td><td>Canonicalize natural loops</td></tr>
+ <tr><td><a href="#lowerallocs">-lowerallocs</a></td><td>Lower allocations from instructions to calls</td></tr>
+ <tr><td><a href="#lowerinvoke">-lowerinvoke</a></td><td>Lower invoke and unwind, for unwindless code generators</td></tr>
+ <tr><td><a href="#lowersetjmp">-lowersetjmp</a></td><td>Lower Set Jump</td></tr>
+ <tr><td><a href="#lowerswitch">-lowerswitch</a></td><td>Lower SwitchInst's to branches</td></tr>
+ <tr><td><a href="#mem2reg">-mem2reg</a></td><td>Promote Memory to Register</td></tr>
+ <tr><td><a href="#memcpyopt">-memcpyopt</a></td><td>Optimize use of memcpy and friends</td></tr>
+ <tr><td><a href="#mergereturn">-mergereturn</a></td><td>Unify function exit nodes</td></tr>
+ <tr><td><a href="#predsimplify">-predsimplify</a></td><td>Predicate Simplifier</td></tr>
+ <tr><td><a href="#prune-eh">-prune-eh</a></td><td>Remove unused exception handling info</td></tr>
+ <tr><td><a href="#raiseallocs">-raiseallocs</a></td><td>Raise allocations from calls to instructions</td></tr>
+ <tr><td><a href="#reassociate">-reassociate</a></td><td>Reassociate expressions</td></tr>
+ <tr><td><a href="#reg2mem">-reg2mem</a></td><td>Demote all values to stack slots</td></tr>
+ <tr><td><a href="#scalarrepl">-scalarrepl</a></td><td>Scalar Replacement of Aggregates</td></tr>
+ <tr><td><a href="#sccp">-sccp</a></td><td>Sparse Conditional Constant Propagation</td></tr>
+ <tr><td><a href="#simplify-libcalls">-simplify-libcalls</a></td><td>Simplify well-known library calls</td></tr>
+ <tr><td><a href="#simplifycfg">-simplifycfg</a></td><td>Simplify the CFG</td></tr>
+ <tr><td><a href="#strip">-strip</a></td><td>Strip all symbols from a module</td></tr>
+ <tr><td><a href="#strip-dead-prototypes">-strip-dead-prototypes</a></td><td>Remove unused function declarations</td></tr>
+ <tr><td><a href="#sretpromotion">-sretpromotion</a></td><td>Promote sret arguments</td></tr>
+ <tr><td><a href="#tailcallelim">-tailcallelim</a></td><td>Tail Call Elimination</td></tr>
+ <tr><td><a href="#tailduplicate">-tailduplicate</a></td><td>Tail Duplication</td></tr>
+
+
+ <tr><th colspan="2"><b>UTILITY PASSES</b></th></tr>
+ <tr><th>Option</th><th>Name</th></tr>
+ <tr><td><a href="#deadarghaX0r">-deadarghaX0r</a></td><td>Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)</td></tr>
+ <tr><td><a href="#extract-blocks">-extract-blocks</a></td><td>Extract Basic Blocks From Module (for bugpoint use)</td></tr>
+ <tr><td><a href="#preverify">-preverify</a></td><td>Preliminary module verification</td></tr>
+ <tr><td><a href="#verify">-verify</a></td><td>Module Verifier</td></tr>
+ <tr><td><a href="#view-cfg">-view-cfg</a></td><td>View CFG of function</td></tr>
+ <tr><td><a href="#view-cfg-only">-view-cfg-only</a></td><td>View CFG of function (with no function bodies)</td></tr>
+ </table>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"> <a name="example">Analysis Passes</a></div>
+ <div class="doc_text">
+ <p>This section describes the LLVM Analysis Passes.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="aa-eval">Exhaustive Alias Analysis Precision Evaluator</a>
+ </div>
+ <div class="doc_text">
+ <p>This is a simple N^2 alias analysis accuracy evaluator.
+ Basically, for each function in the program, it simply queries to see how the
+ alias analysis implementation answers alias queries between each pair of
+ pointers in the function.</p>
+
+ <p>This is inspired and adapted from code by: Naveen Neelakantam, Francesco
+ Spadini, and Wojciech Stryjewski.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="anders-aa">Andersen's Interprocedural Alias Analysis</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This is an implementation of Andersen's interprocedural alias
+ analysis
+ </p>
+
+ <p>
+ In pointer analysis terms, this is a subset-based, flow-insensitive,
+ field-sensitive, and context-insensitive algorithm pointer algorithm.
+ </p>
+
+ <p>
+ This algorithm is implemented as three stages:
+ </p>
+
+ <ol>
+ <li>Object identification.</li>
+ <li>Inclusion constraint identification.</li>
+ <li>Offline constraint graph optimization.</li>
+ <li>Inclusion constraint solving.</li>
+ </ol>
+
+ <p>
+ The object identification stage identifies all of the memory objects in the
+ program, which includes globals, heap allocated objects, and stack allocated
+ objects.
+ </p>
+
+ <p>
+ The inclusion constraint identification stage finds all inclusion constraints
+ in the program by scanning the program, looking for pointer assignments and
+ other statements that effect the points-to graph. For a statement like
+ <code><var>A</var> = <var>B</var></code>, this statement is processed to
+ indicate that <var>A</var> can point to anything that <var>B</var> can point
+ to. Constraints can handle copies, loads, and stores, and address taking.
+ </p>
+
+ <p>
+ The offline constraint graph optimization portion includes offline variable
+ substitution algorithms intended to computer pointer and location
+ equivalences. Pointer equivalences are those pointers that will have the
+ same points-to sets, and location equivalences are those variables that
+ always appear together in points-to sets.
+ </p>
+
+ <p>
+ The inclusion constraint solving phase iteratively propagates the inclusion
+ constraints until a fixed point is reached. This is an O(<var>n</var>³)
+ algorithm.
+ </p>
+
+ <p>
+ Function constraints are handled as if they were structs with <var>X</var>
+ fields. Thus, an access to argument <var>X</var> of function <var>Y</var> is
+ an access to node index <code>getNode(<var>Y</var>) + <var>X</var></code>.
+ This representation allows handling of indirect calls without any issues. To
+ wit, an indirect call <code><var>Y</var>(<var>a</var>,<var>b</var>)</code> is
+ equivalent to <code>*(<var>Y</var> + 1) = <var>a</var>, *(<var>Y</var> + 2) =
+ <var>b</var></code>. The return node for a function <var>F</var> is always
+ located at <code>getNode(<var>F</var>) + CallReturnPos</code>. The arguments
+ start at <code>getNode(<var>F</var>) + CallArgPos</code>.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="basicaa">Basic Alias Analysis (default AA impl)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This is the default implementation of the Alias Analysis interface
+ that simply implements a few identities (two different globals cannot alias,
+ etc), but otherwise does no analysis.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="basiccg">Basic CallGraph Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>Yet to be written.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="basicvn">Basic Value Numbering (default Value Numbering impl)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This is the default implementation of the <code>ValueNumbering</code>
+ interface. It walks the SSA def-use chains to trivially identify
+ lexically identical expressions. This does not require any ahead of time
+ analysis, so it is a very fast default implementation.
+ </p>
+ <p>
+ The ValueNumbering analysis passes are mostly deprecated. They are only used
+ by the <a href="#gcse">Global Common Subexpression Elimination pass</a>, which
+ is deprecated by the <a href="#gvn">Global Value Numbering pass</a> (which
+ does its value numbering on its own).
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="codegenprepare">Optimize for code generation</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass munges the code in the input function to better prepare it for
+ SelectionDAG-based code generation. This works around limitations in it's
+ basic-block-at-a-time approach. It should eventually be removed.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="count-aa">Count Alias Analysis Query Responses</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ A pass which can be used to count how many alias queries
+ are being made and how the alias analysis implementation being used responds.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="debug-aa">AA use debugger</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This simple pass checks alias analysis users to ensure that if they
+ create a new value, they do not query AA without informing it of the value.
+ It acts as a shim over any other AA pass you want.
+ </p>
+
+ <p>
+ Yes keeping track of every value in the program is expensive, but this is
+ a debugging pass.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="domfrontier">Dominance Frontier Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is a simple dominator construction algorithm for finding forward
+ dominator frontiers.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="domtree">Dominator Tree Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is a simple dominator construction algorithm for finding forward
+ dominators.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="dot-callgraph">Print Call Graph to 'dot' file</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints the call graph into a
+ <code>.dot</code> graph. This graph can then be processed with the "dot" tool
+ to convert it to postscript or some other suitable format.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="dot-cfg">Print CFG of function to 'dot' file</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints the control flow graph
+ into a <code>.dot</code> graph. This graph can then be processed with the
+ "dot" tool to convert it to postscript or some other suitable format.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="dot-cfg-only">Print CFG of function to 'dot' file (with no function bodies)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints the control flow graph
+ into a <code>.dot</code> graph, omitting the function bodies. This graph can
+ then be processed with the "dot" tool to convert it to postscript or some
+ other suitable format.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="globalsmodref-aa">Simple mod/ref analysis for globals</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This simple pass provides alias and mod/ref information for global values
+ that do not have their address taken, and keeps track of whether functions
+ read or write memory (are "pure"). For this simple (but very common) case,
+ we can provide pretty accurate and useful information.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="instcount">Counts the various types of Instructions</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass collects the count of all instructions and reports them
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="intervals">Interval Partition Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This analysis calculates and represents the interval partition of a function,
+ or a preexisting interval partition.
+ </p>
+
+ <p>
+ In this way, the interval partition may be used to reduce a flow graph down
+ to its degenerate single node interval partition (unless it is irreducible).
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="load-vn">Load Value Numbering</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass value numbers load and call instructions. To do this, it finds
+ lexically identical load instructions, and uses alias analysis to determine
+ which loads are guaranteed to produce the same value. To value number call
+ instructions, it looks for calls to functions that do not write to memory
+ which do not have intervening instructions that clobber the memory that is
+ read from.
+ </p>
+
+ <p>
+ This pass builds off of another value numbering pass to implement value
+ numbering for non-load and non-call instructions. It uses Alias Analysis so
+ that it can disambiguate the load instructions. The more powerful these base
+ analyses are, the more powerful the resultant value numbering will be.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loops">Natural Loop Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This analysis is used to identify natural loops and determine the loop depth
+ of various nodes of the CFG. Note that the loops identified may actually be
+ several natural loops that share the same header node... not just a single
+ natural loop.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="memdep">Memory Dependence Analysis</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ An analysis that determines, for a given memory operation, what preceding
+ memory operations it depends on. It builds on alias analysis information, and
+ tries to provide a lazy, caching interface to a common kind of alias
+ information query.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="no-aa">No Alias Analysis (always returns 'may' alias)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Always returns "I don't know" for alias queries. NoAA is unlike other alias
+ analysis implementations, in that it does not chain to a previous analysis. As
+ such it doesn't follow many of the rules that other alias analyses must.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="no-profile">No Profile Information</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ The default "no profile" implementation of the abstract
+ <code>ProfileInfo</code> interface.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="postdomfrontier">Post-Dominance Frontier Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is a simple post-dominator construction algorithm for finding
+ post-dominator frontiers.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="postdomtree">Post-Dominator Tree Construction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is a simple post-dominator construction algorithm for finding
+ post-dominators.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-alias-sets">Alias Set Printer</a>
+ </div>
+ <div class="doc_text">
+ <p>Yet to be written.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-callgraph">Print a call graph</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints the call graph to
+ standard output in a human-readable form.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-callgraph-sccs">Print SCCs of the Call Graph</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints the SCCs of the call
+ graph to standard output in a human-readable form.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-cfg-sccs">Print SCCs of each function CFG</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints the SCCs of each
+ function CFG to standard output in a human-readable form.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-externalfnconstants">Print external fn callsites passed constants</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass, only available in <code>opt</code>, prints out call sites to
+ external functions that are called with constant arguments. This can be
+ useful when looking for standard library functions we should constant fold
+ or handle in alias analyses.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-function">Print function to stderr</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ The <code>PrintFunctionPass</code> class is designed to be pipelined with
+ other <code>FunctionPass</code>es, and prints out the functions of the module
+ as they are processed.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-module">Print module to stderr</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass simply prints out the entire module when it is executed.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="print-used-types">Find Used Types</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is used to seek out all of the types in use by the program. Note
+ that this analysis explicitly does not include types only used by the symbol
+ table.
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="profile-loader">Load profile information from llvmprof.out</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ A concrete implementation of profiling information that loads the information
+ from a profile dump file.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="scalar-evolution">Scalar Evolution Analysis</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ The <code>ScalarEvolution</code> analysis can be used to analyze and
+ catagorize scalar expressions in loops. It specializes in recognizing general
+ induction variables, representing them with the abstract and opaque
+ <code>SCEV</code> class. Given this analysis, trip counts of loops and other
+ important properties can be obtained.
+ </p>
+
+ <p>
+ This analysis is primarily useful for induction variable substitution and
+ strength reduction.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="targetdata">Target Data Layout</a>
+ </div>
+ <div class="doc_text">
+ <p>Provides other passes access to information on how the size and alignment
+ required by the the target ABI for various data types.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"> <a name="transform">Transform Passes</a></div>
+ <div class="doc_text">
+ <p>This section describes the LLVM Transform Passes.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="adce">Aggressive Dead Code Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>ADCE aggressively tries to eliminate code. This pass is similar to
+ <a href="#dce">DCE</a> but it assumes that values are dead until proven
+ otherwise. This is similar to <a href="#sccp">SCCP</a>, except applied to
+ the liveness of values.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="argpromotion">Promote 'by reference' arguments to scalars</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass promotes "by reference" arguments to be "by value" arguments. In
+ practice, this means looking for internal functions that have pointer
+ arguments. If it can prove, through the use of alias analysis, that an
+ argument is *only* loaded, then it can pass the value into the function
+ instead of the address of the value. This can cause recursive simplification
+ of code and lead to the elimination of allocas (especially in C++ template
+ code like the STL).
+ </p>
+
+ <p>
+ This pass also handles aggregate arguments that are passed into a function,
+ scalarizing them if the elements of the aggregate are only loaded. Note that
+ it refuses to scalarize aggregates which would require passing in more than
+ three operands to the function, because passing thousands of operands for a
+ large array or structure is unprofitable!
+ </p>
+
+ <p>
+ Note that this transformation could also be done for arguments that are only
+ stored to (returning the value instead), but does not currently. This case
+ would be best handled when and if LLVM starts supporting multiple return
+ values from functions.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="block-placement">Profile Guided Basic Block Placement</a>
+ </div>
+ <div class="doc_text">
+ <p>This pass is a very simple profile guided basic block placement algorithm.
+ The idea is to put frequently executed blocks together at the start of the
+ function and hopefully increase the number of fall-through conditional
+ branches. If there is no profile information for a particular function, this
+ pass basically orders blocks in depth-first order.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="break-crit-edges">Break critical edges in CFG</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Break all of the critical edges in the CFG by inserting a dummy basic block.
+ It may be "required" by passes that cannot deal with critical edges. This
+ transformation obviously invalidates the CFG, but can update forward dominator
+ (set, immediate dominators, tree, and frontier) information.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="codegenprepare">Prepare a function for code generation</a>
+ </div>
+ <div class="doc_text">
+ This pass munges the code in the input function to better prepare it for
+ SelectionDAG-based code generation. This works around limitations in it's
+ basic-block-at-a-time approach. It should eventually be removed.
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="condprop">Conditional Propagation</a>
+ </div>
+ <div class="doc_text">
+ <p>This pass propagates information about conditional expressions through the
+ program, allowing it to eliminate conditional branches in some cases.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="constmerge">Merge Duplicate Global Constants</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Merges duplicate global constants together into a single constant that is
+ shared. This is useful because some passes (ie TraceValues) insert a lot of
+ string constants into the program, regardless of whether or not an existing
+ string is available.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="constprop">Simple constant propagation</a>
+ </div>
+ <div class="doc_text">
+ <p>This file implements constant propagation and merging. It looks for
+ instructions involving only constant operands and replaces them with a
+ constant value instead of an instruction. For example:</p>
+ <blockquote><pre>add i32 1, 2</pre></blockquote>
+ <p>becomes</p>
+ <blockquote><pre>i32 3</pre></blockquote>
+ <p>NOTE: this pass has a habit of making definitions be dead. It is a good
+ idea to to run a <a href="#die">DIE</a> (Dead Instruction Elimination) pass
+ sometime after running this pass.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="dce">Dead Code Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Dead code elimination is similar to <a href="#die">dead instruction
+ elimination</a>, but it rechecks instructions that were used by removed
+ instructions to see if they are newly dead.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="deadargelim">Dead Argument Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass deletes dead arguments from internal functions. Dead argument
+ elimination removes arguments which are directly dead, as well as arguments
+ only passed into function calls as dead arguments of other functions. This
+ pass also deletes dead arguments in a similar way.
+ </p>
+
+ <p>
+ This pass is often useful as a cleanup pass to run after aggressive
+ interprocedural passes, which add possibly-dead arguments.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="deadtypeelim">Dead Type Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is used to cleanup the output of GCC. It eliminate names for types
+ that are unused in the entire translation unit, using the <a
+ href="#findusedtypes">find used types</a> pass.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="die">Dead Instruction Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Dead instruction elimination performs a single pass over the function,
+ removing instructions that are obviously dead.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="dse">Dead Store Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ A trivial dead store elimination that only considers basic-block local
+ redundant stores.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="gcse">Global Common Subexpression Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is designed to be a very quick global transformation that
+ eliminates global common subexpressions from a function. It does this by
+ using an existing value numbering analysis pass to identify the common
+ subexpressions, eliminating them when possible.
+ </p>
+ <p>
+ This pass is deprecated by the <a href="#gvn">Global Value Numbering pass</a>
+ (which does a better job with its own value numbering).
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="globaldce">Dead Global Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This transform is designed to eliminate unreachable internal globals from the
+ program. It uses an aggressive algorithm, searching out globals that are
+ known to be alive. After it finds all of the globals which are needed, it
+ deletes whatever is left over. This allows it to delete recursive chunks of
+ the program which are unreachable.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="globalopt">Global Variable Optimizer</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass transforms simple global variables that never have their address
+ taken. If obviously true, it marks read/write globals as constant, deletes
+ variables only stored to, etc.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="gvn">Global Value Numbering</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs global value numbering to eliminate fully redundant
+ instructions. It also performs simple dead load elimination.
+ </p>
+ <p>
+ Note that this pass does the value numbering itself, it does not use the
+ ValueNumbering analysis passes.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="gvnpre">Global Value Numbering/Partial Redundancy Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs a hybrid of global value numbering and partial redundancy
+ elimination, known as GVN-PRE. It performs partial redundancy elimination on
+ values, rather than lexical expressions, allowing a more comprehensive view
+ the optimization. It replaces redundant values with uses of earlier
+ occurences of the same value. While this is beneficial in that it eliminates
+ unneeded computation, it also increases register pressure by creating large
+ live ranges, and should be used with caution on platforms that are very
+ sensitive to register pressure.
+ </p>
+ <p>
+ Note that this pass does the value numbering itself, it does not use the
+ ValueNumbering analysis passes.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="indmemrem">Indirect Malloc and Free Removal</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass finds places where memory allocation functions may escape into
+ indirect land. Some transforms are much easier (aka possible) only if free
+ or malloc are not called indirectly.
+ </p>
+
+ <p>
+ Thus find places where the address of memory functions are taken and construct
+ bounce functions with direct calls of those functions.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="indvars">Canonicalize Induction Variables</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This transformation analyzes and transforms the induction variables (and
+ computations derived from them) into simpler forms suitable for subsequent
+ analysis and transformation.
+ </p>
+
+ <p>
+ This transformation makes the following changes to each loop with an
+ identifiable induction variable:
+ </p>
+
+ <ol>
+ <li>All loops are transformed to have a <em>single</em> canonical
+ induction variable which starts at zero and steps by one.</li>
+ <li>The canonical induction variable is guaranteed to be the first PHI node
+ in the loop header block.</li>
+ <li>Any pointer arithmetic recurrences are raised to use array
+ subscripts.</li>
+ </ol>
+
+ <p>
+ If the trip count of a loop is computable, this pass also makes the following
+ changes:
+ </p>
+
+ <ol>
+ <li>The exit condition for the loop is canonicalized to compare the
+ induction value against the exit value. This turns loops like:
+ <blockquote><pre>for (i = 7; i*i < 1000; ++i)</pre></blockquote>
+ into
+ <blockquote><pre>for (i = 0; i != 25; ++i)</pre></blockquote></li>
+ <li>Any use outside of the loop of an expression derived from the indvar
+ is changed to compute the derived value outside of the loop, eliminating
+ the dependence on the exit value of the induction variable. If the only
+ purpose of the loop is to compute the exit value of some derived
+ expression, this transformation will make the loop dead.</li>
+ </ol>
+
+ <p>
+ This transformation should be followed by strength reduction after all of the
+ desired loop transformations have been performed. Additionally, on targets
+ where it is profitable, the loop could be transformed to count down to zero
+ (the "do loop" optimization).
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="inline">Function Integration/Inlining</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Bottom-up inlining of functions into callees.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="insert-block-profiling">Insert instrumentation for block profiling</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass instruments the specified program with counters for basic block
+ profiling, which counts the number of times each basic block executes. This
+ is the most basic form of profiling, which can tell which blocks are hot, but
+ cannot reliably detect hot paths through the CFG.
+ </p>
+
+ <p>
+ Note that this implementation is very naïve. Control equivalent regions of
+ the CFG should not require duplicate counters, but it does put duplicate
+ counters in.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="insert-edge-profiling">Insert instrumentation for edge profiling</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass instruments the specified program with counters for edge profiling.
+ Edge profiling can give a reasonable approximation of the hot paths through a
+ program, and is used for a wide variety of program transformations.
+ </p>
+
+ <p>
+ Note that this implementation is very naïve. It inserts a counter for
+ <em>every</em> edge in the program, instead of using control flow information
+ to prune the number of counters inserted.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="insert-function-profiling">Insert instrumentation for function profiling</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass instruments the specified program with counters for function
+ profiling, which counts the number of times each function is called.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="insert-null-profiling-rs">Measure profiling framework overhead</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ The basic profiler that does nothing. It is the default profiler and thus
+ terminates <code>RSProfiler</code> chains. It is useful for measuring
+ framework overhead.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="insert-rs-profiling-framework">Insert random sampling instrumentation framework</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ The second stage of the random-sampling instrumentation framework, duplicates
+ all instructions in a function, ignoring the profiling code, then connects the
+ two versions together at the entry and at backedges. At each connection point
+ a choice is made as to whether to jump to the profiled code (take a sample) or
+ execute the unprofiled code.
+ </p>
+
+ <p>
+ After this pass, it is highly recommended to run<a href="#mem2reg">mem2reg</a>
+ and <a href="#adce">adce</a>. <a href="#instcombine">instcombine</a>,
+ <a href="#load-vn">load-vn</a>, <a href="#gdce">gdce</a>, and
+ <a href="#dse">dse</a> also are good to run afterwards.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="instcombine">Combine redundant instructions</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Combine instructions to form fewer, simple
+ instructions. This pass does not modify the CFG This pass is where algebraic
+ simplification happens.
+ </p>
+
+ <p>
+ This pass combines things like:
+ </p>
+
+ <blockquote><pre
+ >%Y = add i32 %X, 1
+ %Z = add i32 %Y, 1</pre></blockquote>
+
+ <p>
+ into:
+ </p>
+
+ <blockquote><pre
+ >%Z = add i32 %X, 2</pre></blockquote>
+
+ <p>
+ This is a simple worklist driven algorithm.
+ </p>
+
+ <p>
+ This pass guarantees that the following canonicalizations are performed on
+ the program:
+ </p>
+
+ <ul>
+ <li>If a binary operator has a constant operand, it is moved to the right-
+ hand side.</li>
+ <li>Bitwise operators with constant operands are always grouped so that
+ shifts are performed first, then <code>or</code>s, then
+ <code>and</code>s, then <code>xor</code>s.</li>
+ <li>Compare instructions are converted from <code><</code>,
+ <code>></code>, <code>≤</code>, or <code>≥</code> to
+ <code>=</code> or <code>≠</code> if possible.</li>
+ <li>All <code>cmp</code> instructions on boolean values are replaced with
+ logical operations.</li>
+ <li><code>add <var>X</var>, <var>X</var></code> is represented as
+ <code>mul <var>X</var>, 2</code> ⇒ <code>shl <var>X</var>, 1</code></li>
+ <li>Multiplies with a constant power-of-two argument are transformed into
+ shifts.</li>
+ <li>… etc.</li>
+ </ul>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="internalize">Internalize Global Symbols</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass loops over all of the functions in the input module, looking for a
+ main function. If a main function is found, all other functions and all
+ global variables with initializers are marked as internal.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="ipconstprop">Interprocedural constant propagation</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass implements an <em>extremely</em> simple interprocedural constant
+ propagation pass. It could certainly be improved in many different ways,
+ like using a worklist. This pass makes arguments dead, but does not remove
+ them. The existing dead argument elimination pass should be run after this
+ to clean up the mess.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="ipsccp">Interprocedural Sparse Conditional Constant Propagation</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ An interprocedural variant of <a href="#sccp">Sparse Conditional Constant
+ Propagation</a>.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="jump-threading">Thread control through conditional blocks</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Jump threading tries to find distinct threads of control flow running through
+ a basic block. This pass looks at blocks that have multiple predecessors and
+ multiple successors. If one or more of the predecessors of the block can be
+ proven to always cause a jump to one of the successors, we forward the edge
+ from the predecessor to the successor by duplicating the contents of this
+ block.
+ </p>
+ <p>
+ An example of when this can occur is code like this:
+ </p>
+
+ <pre
+ >if () { ...
+ X = 4;
+ }
+ if (X < 3) {</pre>
+
+ <p>
+ In this case, the unconditional branch at the end of the first if can be
+ revectored to the false side of the second if.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="lcssa">Loop-Closed SSA Form Pass</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass transforms loops by placing phi nodes at the end of the loops for
+ all values that are live across the loop boundary. For example, it turns
+ the left into the right code:
+ </p>
+
+ <pre
+ >for (...) for (...)
+ if (c) if (c)
+ X1 = ... X1 = ...
+ else else
+ X2 = ... X2 = ...
+ X3 = phi(X1, X2) X3 = phi(X1, X2)
+ ... = X3 + 4 X4 = phi(X3)
+ ... = X4 + 4</pre>
+
+ <p>
+ This is still valid LLVM; the extra phi nodes are purely redundant, and will
+ be trivially eliminated by <code>InstCombine</code>. The major benefit of
+ this transformation is that it makes many other loop optimizations, such as
+ LoopUnswitching, simpler.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="licm">Loop Invariant Code Motion</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs loop invariant code motion, attempting to remove as much
+ code from the body of a loop as possible. It does this by either hoisting
+ code into the preheader block, or by sinking code to the exit blocks if it is
+ safe. This pass also promotes must-aliased memory locations in the loop to
+ live in registers, thus hoisting and sinking "invariant" loads and stores.
+ </p>
+
+ <p>
+ This pass uses alias analysis for two purposes:
+ </p>
+
+ <ul>
+ <li>Moving loop invariant loads and calls out of loops. If we can determine
+ that a load or call inside of a loop never aliases anything stored to,
+ we can hoist it or sink it like any other instruction.</li>
+ <li>Scalar Promotion of Memory - If there is a store instruction inside of
+ the loop, we try to move the store to happen AFTER the loop instead of
+ inside of the loop. This can only happen if a few conditions are true:
+ <ul>
+ <li>The pointer stored through is loop invariant.</li>
+ <li>There are no stores or loads in the loop which <em>may</em> alias
+ the pointer. There are no calls in the loop which mod/ref the
+ pointer.</li>
+ </ul>
+ If these conditions are true, we can promote the loads and stores in the
+ loop of the pointer to use a temporary alloca'd variable. We then use
+ the mem2reg functionality to construct the appropriate SSA form for the
+ variable.</li>
+ </ul>
+ </div>
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-deletion">Dead Loop Deletion Pass</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This file implements the Dead Loop Deletion Pass. This pass is responsible
+ for eliminating loops with non-infinite computable trip counts that have no
+ side effects or volatile instructions, and do not contribute to the
+ computation of the function's return value.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-extract">Extract loops into new functions</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ A pass wrapper around the <code>ExtractLoop()</code> scalar transformation to
+ extract each top-level loop into its own new function. If the loop is the
+ <em>only</em> loop in a given function, it is not touched. This is a pass most
+ useful for debugging via bugpoint.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-extract-single">Extract at most one loop into a new function</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Similar to <a href="#loop-extract">Extract loops into new functions</a>,
+ this pass extracts one natural loop from the program into a function if it
+ can. This is used by bugpoint.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-index-split">Index Split Loops</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass divides loop's iteration range by spliting loop such that each
+ individual loop is executed efficiently.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-reduce">Loop Strength Reduction</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs a strength reduction on array references inside loops that
+ have as one or more of their components the loop induction variable. This is
+ accomplished by creating a new value to hold the initial value of the array
+ access for the first iteration, and then creating a new GEP instruction in
+ the loop to increment the value by the appropriate amount.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-rotate">Rotate Loops</a>
+ </div>
+ <div class="doc_text">
+ <p>A simple loop rotation transformation.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-unroll">Unroll loops</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass implements a simple loop unroller. It works best when loops have
+ been canonicalized by the <a href="#indvars"><tt>-indvars</tt></a> pass,
+ allowing it to determine the trip counts of loops easily.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loop-unswitch">Unswitch loops</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass transforms loops that contain branches on loop-invariant conditions
+ to have multiple loops. For example, it turns the left into the right code:
+ </p>
+
+ <pre
+ >for (...) if (lic)
+ A for (...)
+ if (lic) A; B; C
+ B else
+ C for (...)
+ A; C</pre>
+
+ <p>
+ This can increase the size of the code exponentially (doubling it every time
+ a loop is unswitched) so we only unswitch if the resultant code will be
+ smaller than a threshold.
+ </p>
+
+ <p>
+ This pass expects LICM to be run before it to hoist invariant conditions out
+ of the loop, to make the unswitching opportunity obvious.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="loopsimplify">Canonicalize natural loops</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs several transformations to transform natural loops into a
+ simpler form, which makes subsequent analyses and transformations simpler and
+ more effective.
+ </p>
+
+ <p>
+ Loop pre-header insertion guarantees that there is a single, non-critical
+ entry edge from outside of the loop to the loop header. This simplifies a
+ number of analyses and transformations, such as LICM.
+ </p>
+
+ <p>
+ Loop exit-block insertion guarantees that all exit blocks from the loop
+ (blocks which are outside of the loop that have predecessors inside of the
+ loop) only have predecessors from inside of the loop (and are thus dominated
+ by the loop header). This simplifies transformations such as store-sinking
+ that are built into LICM.
+ </p>
+
+ <p>
+ This pass also guarantees that loops will have exactly one backedge.
+ </p>
+
+ <p>
+ Note that the simplifycfg pass will clean up blocks which are split out but
+ end up being unnecessary, so usage of this pass should not pessimize
+ generated code.
+ </p>
+
+ <p>
+ This pass obviously modifies the CFG, but updates loop information and
+ dominator information.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="lowerallocs">Lower allocations from instructions to calls</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Turn <tt>malloc</tt> and <tt>free</tt> instructions into <tt>@malloc</tt> and
+ <tt>@free</tt> calls.
+ </p>
+
+ <p>
+ This is a target-dependent tranformation because it depends on the size of
+ data types and alignment constraints.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="lowerinvoke">Lower invoke and unwind, for unwindless code generators</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This transformation is designed for use by code generators which do not yet
+ support stack unwinding. This pass supports two models of exception handling
+ lowering, the 'cheap' support and the 'expensive' support.
+ </p>
+
+ <p>
+ 'Cheap' exception handling support gives the program the ability to execute
+ any program which does not "throw an exception", by turning 'invoke'
+ instructions into calls and by turning 'unwind' instructions into calls to
+ abort(). If the program does dynamically use the unwind instruction, the
+ program will print a message then abort.
+ </p>
+
+ <p>
+ 'Expensive' exception handling support gives the full exception handling
+ support to the program at the cost of making the 'invoke' instruction
+ really expensive. It basically inserts setjmp/longjmp calls to emulate the
+ exception handling as necessary.
+ </p>
+
+ <p>
+ Because the 'expensive' support slows down programs a lot, and EH is only
+ used for a subset of the programs, it must be specifically enabled by the
+ <tt>-enable-correct-eh-support</tt> option.
+ </p>
+
+ <p>
+ Note that after this pass runs the CFG is not entirely accurate (exceptional
+ control flow edges are not correct anymore) so only very simple things should
+ be done after the lowerinvoke pass has run (like generation of native code).
+ This should not be used as a general purpose "my LLVM-to-LLVM pass doesn't
+ support the invoke instruction yet" lowering pass.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="lowersetjmp">Lower Set Jump</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Lowers <tt>setjmp</tt> and <tt>longjmp</tt> to use the LLVM invoke and unwind
+ instructions as necessary.
+ </p>
+
+ <p>
+ Lowering of <tt>longjmp</tt> is fairly trivial. We replace the call with a
+ call to the LLVM library function <tt>__llvm_sjljeh_throw_longjmp()</tt>.
+ This unwinds the stack for us calling all of the destructors for
+ objects allocated on the stack.
+ </p>
+
+ <p>
+ At a <tt>setjmp</tt> call, the basic block is split and the <tt>setjmp</tt>
+ removed. The calls in a function that have a <tt>setjmp</tt> are converted to
+ invoke where the except part checks to see if it's a <tt>longjmp</tt>
+ exception and, if so, if it's handled in the function. If it is, then it gets
+ the value returned by the <tt>longjmp</tt> and goes to where the basic block
+ was split. <tt>invoke</tt> instructions are handled in a similar fashion with
+ the original except block being executed if it isn't a <tt>longjmp</tt>
+ except that is handled by that function.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="lowerswitch">Lower SwitchInst's to branches</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Rewrites <tt>switch</tt> instructions with a sequence of branches, which
+ allows targets to get away with not implementing the switch instruction until
+ it is convenient.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="mem2reg">Promote Memory to Register</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This file promotes memory references to be register references. It promotes
+ <tt>alloca</tt> instructions which only have <tt>load</tt>s and
+ <tt>store</tt>s as uses. An <tt>alloca</tt> is transformed by using dominator
+ frontiers to place <tt>phi</tt> nodes, then traversing the function in
+ depth-first order to rewrite <tt>load</tt>s and <tt>store</tt>s as
+ appropriate. This is just the standard SSA construction algorithm to construct
+ "pruned" SSA form.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="memcpyopt">Optimize use of memcpy and friend</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs various transformations related to eliminating memcpy
+ calls, or transforming sets of stores into memset's.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="mergereturn">Unify function exit nodes</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Ensure that functions have at most one <tt>ret</tt> instruction in them.
+ Additionally, it keeps track of which node is the new exit node of the CFG.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="predsimplify">Predicate Simplifier</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Path-sensitive optimizer. In a branch where <tt>x == y</tt>, replace uses of
+ <tt>x</tt> with <tt>y</tt>. Permits further optimization, such as the
+ elimination of the unreachable call:
+ </p>
+
+ <blockquote><pre
+ >void test(int *p, int *q)
+ {
+ if (p != q)
+ return;
+
+ if (*p != *q)
+ foo(); // unreachable
+ }</pre></blockquote>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="prune-eh">Remove unused exception handling info</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This file implements a simple interprocedural pass which walks the call-graph,
+ turning <tt>invoke</tt> instructions into <tt>call</tt> instructions if and
+ only if the callee cannot throw an exception. It implements this as a
+ bottom-up traversal of the call-graph.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="raiseallocs">Raise allocations from calls to instructions</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Converts <tt>@malloc</tt> and <tt>@free</tt> calls to <tt>malloc</tt> and
+ <tt>free</tt> instructions.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="reassociate">Reassociate expressions</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass reassociates commutative expressions in an order that is designed
+ to promote better constant propagation, GCSE, LICM, PRE, etc.
+ </p>
+
+ <p>
+ For example: 4 + (<var>x</var> + 5) ⇒ <var>x</var> + (4 + 5)
+ </p>
+
+ <p>
+ In the implementation of this algorithm, constants are assigned rank = 0,
+ function arguments are rank = 1, and other values are assigned ranks
+ corresponding to the reverse post order traversal of current function
+ (starting at 2), which effectively gives values in deep loops higher rank
+ than values not in loops.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="reg2mem">Demote all values to stack slots</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This file demotes all registers to memory references. It is intented to be
+ the inverse of <a href="#mem2reg"><tt>-mem2reg</tt></a>. By converting to
+ <tt>load</tt> instructions, the only values live accross basic blocks are
+ <tt>alloca</tt> instructions and <tt>load</tt> instructions before
+ <tt>phi</tt> nodes. It is intended that this should make CFG hacking much
+ easier. To make later hacking easier, the entry block is split into two, such
+ that all introduced <tt>alloca</tt> instructions (and nothing else) are in the
+ entry block.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="scalarrepl">Scalar Replacement of Aggregates</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ The well-known scalar replacement of aggregates transformation. This
+ transform breaks up <tt>alloca</tt> instructions of aggregate type (structure
+ or array) into individual <tt>alloca</tt> instructions for each member if
+ possible. Then, if possible, it transforms the individual <tt>alloca</tt>
+ instructions into nice clean scalar SSA form.
+ </p>
+
+ <p>
+ This combines a simple scalar replacement of aggregates algorithm with the <a
+ href="#mem2reg"><tt>mem2reg</tt></a> algorithm because often interact,
+ especially for C++ programs. As such, iterating between <tt>scalarrepl</tt>,
+ then <a href="#mem2reg"><tt>mem2reg</tt></a> until we run out of things to
+ promote works well.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="sccp">Sparse Conditional Constant Propagation</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Sparse conditional constant propagation and merging, which can be summarized
+ as:
+ </p>
+
+ <ol>
+ <li>Assumes values are constant unless proven otherwise</li>
+ <li>Assumes BasicBlocks are dead unless proven otherwise</li>
+ <li>Proves values to be constant, and replaces them with constants</li>
+ <li>Proves conditional branches to be unconditional</li>
+ </ol>
+
+ <p>
+ Note that this pass has a habit of making definitions be dead. It is a good
+ idea to to run a DCE pass sometime after running this pass.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="simplify-libcalls">Simplify well-known library calls</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Applies a variety of small optimizations for calls to specific well-known
+ function calls (e.g. runtime library functions). For example, a call
+ <tt>exit(3)</tt> that occurs within the <tt>main()</tt> function can be
+ transformed into simply <tt>return 3</tt>.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="simplifycfg">Simplify the CFG</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Performs dead code elimination and basic block merging. Specifically:
+ </p>
+
+ <ol>
+ <li>Removes basic blocks with no predecessors.</li>
+ <li>Merges a basic block into its predecessor if there is only one and the
+ predecessor only has one successor.</li>
+ <li>Eliminates PHI nodes for basic blocks with a single predecessor.</li>
+ <li>Eliminates a basic block that only contains an unconditional
+ branch.</li>
+ </ol>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="strip">Strip all symbols from a module</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Performs code stripping. This transformation can delete:
+ </p>
+
+ <ol>
+ <li>names for virtual registers</li>
+ <li>symbols for internal globals and functions</li>
+ <li>debug information</li>
+ </ol>
+
+ <p>
+ Note that this transformation makes code much less readable, so it should
+ only be used in situations where the <tt>strip</tt> utility would be used,
+ such as reducing code size or making it harder to reverse engineer code.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="strip-dead-prototypes">Remove unused function declarations</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass loops over all of the functions in the input module, looking for
+ dead declarations and removes them. Dead declarations are declarations of
+ functions for which no implementation is available (i.e., declarations for
+ unused library functions).
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="sretpromotion">Promote sret arguments</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass finds functions that return a struct (using a pointer to the struct
+ as the first argument of the function, marked with the '<tt>sret</tt>' attribute) and
+ replaces them with a new function that simply returns each of the elements of
+ that struct (using multiple return values).
+ </p>
+
+ <p>
+ This pass works under a number of conditions:
+ </p>
+
+ <ul>
+ <li>The returned struct must not contain other structs</li>
+ <li>The returned struct must only be used to load values from</li>
+ <li>The placeholder struct passed in is the result of an <tt>alloca</tt></li>
+ </ul>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="tailcallelim">Tail Call Elimination</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This file transforms calls of the current function (self recursion) followed
+ by a return instruction with a branch to the entry of the function, creating
+ a loop. This pass also implements the following extensions to the basic
+ algorithm:
+ </p>
+
+ <ul>
+ <li>Trivial instructions between the call and return do not prevent the
+ transformation from taking place, though currently the analysis cannot
+ support moving any really useful instructions (only dead ones).
+ <li>This pass transforms functions that are prevented from being tail
+ recursive by an associative expression to use an accumulator variable,
+ thus compiling the typical naive factorial or <tt>fib</tt> implementation
+ into efficient code.
+ <li>TRE is performed if the function returns void, if the return
+ returns the result returned by the call, or if the function returns a
+ run-time constant on all exits from the function. It is possible, though
+ unlikely, that the return returns something else (like constant 0), and
+ can still be TRE'd. It can be TRE'd if <em>all other</em> return
+ instructions in the function return the exact same value.
+ <li>If it can prove that callees do not access theier caller stack frame,
+ they are marked as eligible for tail call elimination (by the code
+ generator).
+ </ul>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="tailduplicate">Tail Duplication</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass performs a limited form of tail duplication, intended to simplify
+ CFGs by removing some unconditional branches. This pass is necessary to
+ straighten out loops created by the C front-end, but also is capable of
+ making other code nicer. After this pass is run, the CFG simplify pass
+ should be run to clean up the mess.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"> <a name="transform">Utility Passes</a></div>
+ <div class="doc_text">
+ <p>This section describes the LLVM Utility Passes.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="deadarghaX0r">Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Same as dead argument elimination, but deletes arguments to functions which
+ are external. This is only for use by <a
+ href="Bugpoint.html">bugpoint</a>.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="extract-blocks">Extract Basic Blocks From Module (for bugpoint use)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ This pass is used by bugpoint to extract all blocks from the module into their
+ own functions.</p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="preverify">Preliminary module verification</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Ensures that the module is in the form required by the <a
+ href="#verifier">Module Verifier</a> pass.
+ </p>
+
+ <p>
+ Running the verifier runs this pass automatically, so there should be no need
+ to use it directly.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="verify">Module Verifier</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Verifies an LLVM IR code. This is useful to run after an optimization which is
+ undergoing testing. Note that <tt>llvm-as</tt> verifies its input before
+ emitting bitcode, and also that malformed bitcode is likely to make LLVM
+ crash. All language front-ends are therefore encouraged to verify their output
+ before performing optimizing transformations.
+ </p>
+
+ <ul>
+ <li>Both of a binary operator's parameters are of the same type.</li>
+ <li>Verify that the indices of mem access instructions match other
+ operands.</li>
+ <li>Verify that arithmetic and other things are only performed on
+ first-class types. Verify that shifts and logicals only happen on
+ integrals f.e.</li>
+ <li>All of the constants in a switch statement are of the correct type.</li>
+ <li>The code is in valid SSA form.</li>
+ <li>It should be illegal to put a label into any other type (like a
+ structure) or to return one. [except constant arrays!]</li>
+ <li>Only phi nodes can be self referential: <tt>%x = add i32 %x, %x</tt> is
+ invalid.</li>
+ <li>PHI nodes must have an entry for each predecessor, with no extras.</li>
+ <li>PHI nodes must be the first thing in a basic block, all grouped
+ together.</li>
+ <li>PHI nodes must have at least one entry.</li>
+ <li>All basic blocks should only end with terminator insts, not contain
+ them.</li>
+ <li>The entry node to a function must not have predecessors.</li>
+ <li>All Instructions must be embedded into a basic block.</li>
+ <li>Functions cannot take a void-typed parameter.</li>
+ <li>Verify that a function's argument list agrees with its declared
+ type.</li>
+ <li>It is illegal to specify a name for a void value.</li>
+ <li>It is illegal to have a internal global value with no initializer.</li>
+ <li>It is illegal to have a ret instruction that returns a value that does
+ not agree with the function return value type.</li>
+ <li>Function call argument types match the function prototype.</li>
+ <li>All other things that are tested by asserts spread about the code.</li>
+ </ul>
+
+ <p>
+ Note that this does not provide full security verification (like Java), but
+ instead just tries to ensure that code is well-formed.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="view-cfg">View CFG of function</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Displays the control flow graph using the GraphViz tool.
+ </p>
+ </div>
+
+ <!-------------------------------------------------------------------------- -->
+ <div class="doc_subsection">
+ <a name="view-cfg-only">View CFG of function (with no function bodies)</a>
+ </div>
+ <div class="doc_text">
+ <p>
+ Displays the control flow graph using the GraphViz tool, but omitting function
+ bodies.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:rspencer at x10sys.com">Reid Spencer</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/ProgrammersManual.html
diff -c /dev/null llvm-www/releases/2.5/docs/ProgrammersManual.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/ProgrammersManual.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,3426 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM Programmer's Manual</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ LLVM Programmer's Manual
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#general">General Information</a>
+ <ul>
+ <li><a href="#stl">The C++ Standard Template Library</a></li>
+ <!--
+ <li>The <tt>-time-passes</tt> option</li>
+ <li>How to use the LLVM Makefile system</li>
+ <li>How to write a regression test</li>
+
+ -->
+ </ul>
+ </li>
+ <li><a href="#apis">Important and useful LLVM APIs</a>
+ <ul>
+ <li><a href="#isa">The <tt>isa<></tt>, <tt>cast<></tt>
+ and <tt>dyn_cast<></tt> templates</a> </li>
+ <li><a href="#DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt>
+ option</a>
+ <ul>
+ <li><a href="#DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt>
+ and the <tt>-debug-only</tt> option</a> </li>
+ </ul>
+ </li>
+ <li><a href="#Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt>
+ option</a></li>
+ <!--
+ <li>The <tt>InstVisitor</tt> template
+ <li>The general graph API
+ -->
+ <li><a href="#ViewGraph">Viewing graphs while debugging code</a></li>
+ </ul>
+ </li>
+ <li><a href="#datastructure">Picking the Right Data Structure for a Task</a>
+ <ul>
+ <li><a href="#ds_sequential">Sequential Containers (std::vector, std::list, etc)</a>
+ <ul>
+ <li><a href="#dss_fixedarrays">Fixed Size Arrays</a></li>
+ <li><a href="#dss_heaparrays">Heap Allocated Arrays</a></li>
+ <li><a href="#dss_smallvector">"llvm/ADT/SmallVector.h"</a></li>
+ <li><a href="#dss_vector"><vector></a></li>
+ <li><a href="#dss_deque"><deque></a></li>
+ <li><a href="#dss_list"><list></a></li>
+ <li><a href="#dss_ilist">llvm/ADT/ilist</a></li>
+ <li><a href="#dss_other">Other Sequential Container Options</a></li>
+ </ul></li>
+ <li><a href="#ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a>
+ <ul>
+ <li><a href="#dss_sortedvectorset">A sorted 'vector'</a></li>
+ <li><a href="#dss_smallset">"llvm/ADT/SmallSet.h"</a></li>
+ <li><a href="#dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a></li>
+ <li><a href="#dss_denseset">"llvm/ADT/DenseSet.h"</a></li>
+ <li><a href="#dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a></li>
+ <li><a href="#dss_set"><set></a></li>
+ <li><a href="#dss_setvector">"llvm/ADT/SetVector.h"</a></li>
+ <li><a href="#dss_uniquevector">"llvm/ADT/UniqueVector.h"</a></li>
+ <li><a href="#dss_otherset">Other Set-Like ContainerOptions</a></li>
+ </ul></li>
+ <li><a href="#ds_map">Map-Like Containers (std::map, DenseMap, etc)</a>
+ <ul>
+ <li><a href="#dss_sortedvectormap">A sorted 'vector'</a></li>
+ <li><a href="#dss_stringmap">"llvm/ADT/StringMap.h"</a></li>
+ <li><a href="#dss_indexedmap">"llvm/ADT/IndexedMap.h"</a></li>
+ <li><a href="#dss_densemap">"llvm/ADT/DenseMap.h"</a></li>
+ <li><a href="#dss_map"><map></a></li>
+ <li><a href="#dss_othermap">Other Map-Like Container Options</a></li>
+ </ul></li>
+ <li><a href="#ds_bit">BitVector-like containers</a>
+ <ul>
+ <li><a href="#dss_bitvector">A dense bitvector</a></li>
+ <li><a href="#dss_sparsebitvector">A sparse bitvector</a></li>
+ </ul></li>
+ </ul>
+ </li>
+ <li><a href="#common">Helpful Hints for Common Operations</a>
+ <ul>
+ <li><a href="#inspection">Basic Inspection and Traversal Routines</a>
+ <ul>
+ <li><a href="#iterate_function">Iterating over the <tt>BasicBlock</tt>s
+ in a <tt>Function</tt></a> </li>
+ <li><a href="#iterate_basicblock">Iterating over the <tt>Instruction</tt>s
+ in a <tt>BasicBlock</tt></a> </li>
+ <li><a href="#iterate_institer">Iterating over the <tt>Instruction</tt>s
+ in a <tt>Function</tt></a> </li>
+ <li><a href="#iterate_convert">Turning an iterator into a
+ class pointer</a> </li>
+ <li><a href="#iterate_complex">Finding call sites: a more
+ complex example</a> </li>
+ <li><a href="#calls_and_invokes">Treating calls and invokes
+ the same way</a> </li>
+ <li><a href="#iterate_chains">Iterating over def-use &
+ use-def chains</a> </li>
+ <li><a href="#iterate_preds">Iterating over predecessors &
+ successors of blocks</a></li>
+ </ul>
+ </li>
+ <li><a href="#simplechanges">Making simple changes</a>
+ <ul>
+ <li><a href="#schanges_creating">Creating and inserting new
+ <tt>Instruction</tt>s</a> </li>
+ <li><a href="#schanges_deleting">Deleting <tt>Instruction</tt>s</a> </li>
+ <li><a href="#schanges_replacing">Replacing an <tt>Instruction</tt>
+ with another <tt>Value</tt></a> </li>
+ <li><a href="#schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a> </li>
+ </ul>
+ </li>
+ <!--
+ <li>Working with the Control Flow Graph
+ <ul>
+ <li>Accessing predecessors and successors of a <tt>BasicBlock</tt>
+ <li>
+ <li>
+ </ul>
+ -->
+ </ul>
+ </li>
+
+ <li><a href="#advanced">Advanced Topics</a>
+ <ul>
+ <li><a href="#TypeResolve">LLVM Type Resolution</a>
+ <ul>
+ <li><a href="#BuildRecType">Basic Recursive Type Construction</a></li>
+ <li><a href="#refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a></li>
+ <li><a href="#PATypeHolder">The PATypeHolder Class</a></li>
+ <li><a href="#AbstractTypeUser">The AbstractTypeUser Class</a></li>
+ </ul></li>
+
+ <li><a href="#SymbolTable">The <tt>ValueSymbolTable</tt> and <tt>TypeSymbolTable</tt> classes</a></li>
+ <li><a href="#UserLayout">The <tt>User</tt> and owned <tt>Use</tt> classes' memory layout</a></li>
+ </ul></li>
+
+ <li><a href="#coreclasses">The Core LLVM Class Hierarchy Reference</a>
+ <ul>
+ <li><a href="#Type">The <tt>Type</tt> class</a> </li>
+ <li><a href="#Module">The <tt>Module</tt> class</a></li>
+ <li><a href="#Value">The <tt>Value</tt> class</a>
+ <ul>
+ <li><a href="#User">The <tt>User</tt> class</a>
+ <ul>
+ <li><a href="#Instruction">The <tt>Instruction</tt> class</a></li>
+ <li><a href="#Constant">The <tt>Constant</tt> class</a>
+ <ul>
+ <li><a href="#GlobalValue">The <tt>GlobalValue</tt> class</a>
+ <ul>
+ <li><a href="#Function">The <tt>Function</tt> class</a></li>
+ <li><a href="#GlobalVariable">The <tt>GlobalVariable</tt> class</a></li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li><a href="#BasicBlock">The <tt>BasicBlock</tt> class</a></li>
+ <li><a href="#Argument">The <tt>Argument</tt> class</a></li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
+ <a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a>,
+ <a href="mailto:ggreif at gmail.com">Gabor Greif</a>,
+ <a href="mailto:jstanley at cs.uiuc.edu">Joel Stanley</a> and
+ <a href="mailto:rspencer at x10sys.com">Reid Spencer</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction </a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document is meant to highlight some of the important classes and
+ interfaces available in the LLVM source-base. This manual is not
+ intended to explain what LLVM is, how it works, and what LLVM code looks
+ like. It assumes that you know the basics of LLVM and are interested
+ in writing transformations or otherwise analyzing or manipulating the
+ code.</p>
+
+ <p>This document should get you oriented so that you can find your
+ way in the continuously growing source code that makes up the LLVM
+ infrastructure. Note that this manual is not intended to serve as a
+ replacement for reading the source code, so if you think there should be
+ a method in one of these classes to do something, but it's not listed,
+ check the source. Links to the <a href="/doxygen/">doxygen</a> sources
+ are provided to make this as easy as possible.</p>
+
+ <p>The first section of this document describes general information that is
+ useful to know when working in the LLVM infrastructure, and the second describes
+ the Core LLVM classes. In the future this manual will be extended with
+ information describing how to use extension libraries, such as dominator
+ information, CFG traversal routines, and useful utilities like the <tt><a
+ href="/doxygen/InstVisitor_8h-source.html">InstVisitor</a></tt> template.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="general">General Information</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section contains general information that is useful if you are working
+ in the LLVM source-base, but that isn't specific to any particular API.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="stl">The C++ Standard Template Library</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM makes heavy use of the C++ Standard Template Library (STL),
+ perhaps much more than you are used to, or have seen before. Because of
+ this, you might want to do a little background reading in the
+ techniques used and capabilities of the library. There are many good
+ pages that discuss the STL, and several books on the subject that you
+ can get, so it will not be discussed in this document.</p>
+
+ <p>Here are some useful links:</p>
+
+ <ol>
+
+ <li><a href="http://www.dinkumware.com/refxcpp.html">Dinkumware C++ Library
+ reference</a> - an excellent reference for the STL and other parts of the
+ standard C++ library.</li>
+
+ <li><a href="http://www.tempest-sw.com/cpp/">C++ In a Nutshell</a> - This is an
+ O'Reilly book in the making. It has a decent
+ Standard Library
+ Reference that rivals Dinkumware's, and is unfortunately no longer free since the book has been
+ published.</li>
+
+ <li><a href="http://www.parashift.com/c++-faq-lite/">C++ Frequently Asked
+ Questions</a></li>
+
+ <li><a href="http://www.sgi.com/tech/stl/">SGI's STL Programmer's Guide</a> -
+ Contains a useful <a
+ href="http://www.sgi.com/tech/stl/stl_introduction.html">Introduction to the
+ STL</a>.</li>
+
+ <li><a href="http://www.research.att.com/%7Ebs/C++.html">Bjarne Stroustrup's C++
+ Page</a></li>
+
+ <li><a href="http://64.78.49.204/">
+ Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get
+ the book).</a></li>
+
+ </ol>
+
+ <p>You are also encouraged to take a look at the <a
+ href="CodingStandards.html">LLVM Coding Standards</a> guide which focuses on how
+ to write maintainable code more than where to put your curly braces.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="stl">Other useful references</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ol>
+ <li><a href="http://www.psc.edu/%7Esemke/cvs_branches.html">CVS
+ Branch and Tag Primer</a></li>
+ <li><a href="http://www.fortran-2000.com/ArnaudRecipes/sharedlib.html">Using
+ static and shared libraries across platforms</a></li>
+ </ol>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="apis">Important and useful LLVM APIs</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Here we highlight some LLVM APIs that are generally useful and good to
+ know about when writing transformations.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="isa">The <tt>isa<></tt>, <tt>cast<></tt> and
+ <tt>dyn_cast<></tt> templates</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The LLVM source-base makes extensive use of a custom form of RTTI.
+ These templates have many similarities to the C++ <tt>dynamic_cast<></tt>
+ operator, but they don't have some drawbacks (primarily stemming from
+ the fact that <tt>dynamic_cast<></tt> only works on classes that
+ have a v-table). Because they are used so often, you must know what they
+ do and how they work. All of these templates are defined in the <a
+ href="/doxygen/Casting_8h-source.html"><tt>llvm/Support/Casting.h</tt></a>
+ file (note that you very rarely have to include this file directly).</p>
+
+ <dl>
+ <dt><tt>isa<></tt>: </dt>
+
+ <dd><p>The <tt>isa<></tt> operator works exactly like the Java
+ "<tt>instanceof</tt>" operator. It returns true or false depending on whether
+ a reference or pointer points to an instance of the specified class. This can
+ be very useful for constraint checking of various sorts (example below).</p>
+ </dd>
+
+ <dt><tt>cast<></tt>: </dt>
+
+ <dd><p>The <tt>cast<></tt> operator is a "checked cast" operation. It
+ converts a pointer or reference from a base class to a derived class, causing
+ an assertion failure if it is not really an instance of the right type. This
+ should be used in cases where you have some information that makes you believe
+ that something is of the right type. An example of the <tt>isa<></tt>
+ and <tt>cast<></tt> template is:</p>
+
+ <div class="doc_code">
+ <pre>
+ static bool isLoopInvariant(const <a href="#Value">Value</a> *V, const Loop *L) {
+ if (isa<<a href="#Constant">Constant</a>>(V) || isa<<a href="#Argument">Argument</a>>(V) || isa<<a href="#GlobalValue">GlobalValue</a>>(V))
+ return true;
+
+ // <i>Otherwise, it must be an instruction...</i>
+ return !L->contains(cast<<a href="#Instruction">Instruction</a>>(V)->getParent());
+ }
+ </pre>
+ </div>
+
+ <p>Note that you should <b>not</b> use an <tt>isa<></tt> test followed
+ by a <tt>cast<></tt>, for that use the <tt>dyn_cast<></tt>
+ operator.</p>
+
+ </dd>
+
+ <dt><tt>dyn_cast<></tt>:</dt>
+
+ <dd><p>The <tt>dyn_cast<></tt> operator is a "checking cast" operation.
+ It checks to see if the operand is of the specified type, and if so, returns a
+ pointer to it (this operator does not work with references). If the operand is
+ not of the correct type, a null pointer is returned. Thus, this works very
+ much like the <tt>dynamic_cast<></tt> operator in C++, and should be
+ used in the same circumstances. Typically, the <tt>dyn_cast<></tt>
+ operator is used in an <tt>if</tt> statement or some other flow control
+ statement like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ if (<a href="#AllocationInst">AllocationInst</a> *AI = dyn_cast<<a href="#AllocationInst">AllocationInst</a>>(Val)) {
+ // <i>...</i>
+ }
+ </pre>
+ </div>
+
+ <p>This form of the <tt>if</tt> statement effectively combines together a call
+ to <tt>isa<></tt> and a call to <tt>cast<></tt> into one
+ statement, which is very convenient.</p>
+
+ <p>Note that the <tt>dyn_cast<></tt> operator, like C++'s
+ <tt>dynamic_cast<></tt> or Java's <tt>instanceof</tt> operator, can be
+ abused. In particular, you should not use big chained <tt>if/then/else</tt>
+ blocks to check for lots of different variants of classes. If you find
+ yourself wanting to do this, it is much cleaner and more efficient to use the
+ <tt>InstVisitor</tt> class to dispatch over the instruction type directly.</p>
+
+ </dd>
+
+ <dt><tt>cast_or_null<></tt>: </dt>
+
+ <dd><p>The <tt>cast_or_null<></tt> operator works just like the
+ <tt>cast<></tt> operator, except that it allows for a null pointer as an
+ argument (which it then propagates). This can sometimes be useful, allowing
+ you to combine several null checks into one.</p></dd>
+
+ <dt><tt>dyn_cast_or_null<></tt>: </dt>
+
+ <dd><p>The <tt>dyn_cast_or_null<></tt> operator works just like the
+ <tt>dyn_cast<></tt> operator, except that it allows for a null pointer
+ as an argument (which it then propagates). This can sometimes be useful,
+ allowing you to combine several null checks into one.</p></dd>
+
+ </dl>
+
+ <p>These five templates can be used with any classes, whether they have a
+ v-table or not. To add support for these templates, you simply need to add
+ <tt>classof</tt> static methods to the class you are interested casting
+ to. Describing this is currently outside the scope of this document, but there
+ are lots of examples in the LLVM source base.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="DEBUG">The <tt>DEBUG()</tt> macro and <tt>-debug</tt> option</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Often when working on your pass you will put a bunch of debugging printouts
+ and other code into your pass. After you get it working, you want to remove
+ it, but you may need it again in the future (to work out new bugs that you run
+ across).</p>
+
+ <p> Naturally, because of this, you don't want to delete the debug printouts,
+ but you don't want them to always be noisy. A standard compromise is to comment
+ them out, allowing you to enable them if you need them in the future.</p>
+
+ <p>The "<tt><a href="/doxygen/Debug_8h-source.html">llvm/Support/Debug.h</a></tt>"
+ file provides a macro named <tt>DEBUG()</tt> that is a much nicer solution to
+ this problem. Basically, you can put arbitrary code into the argument of the
+ <tt>DEBUG</tt> macro, and it is only executed if '<tt>opt</tt>' (or any other
+ tool) is run with the '<tt>-debug</tt>' command line argument:</p>
+
+ <div class="doc_code">
+ <pre>
+ DOUT << "I am here!\n";
+ </pre>
+ </div>
+
+ <p>Then you can run your pass like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ $ opt < a.bc > /dev/null -mypass
+ <i><no output></i>
+ $ opt < a.bc > /dev/null -mypass -debug
+ I am here!
+ </pre>
+ </div>
+
+ <p>Using the <tt>DEBUG()</tt> macro instead of a home-brewed solution allows you
+ to not have to create "yet another" command line option for the debug output for
+ your pass. Note that <tt>DEBUG()</tt> macros are disabled for optimized builds,
+ so they do not cause a performance impact at all (for the same reason, they
+ should also not contain side-effects!).</p>
+
+ <p>One additional nice thing about the <tt>DEBUG()</tt> macro is that you can
+ enable or disable it directly in gdb. Just use "<tt>set DebugFlag=0</tt>" or
+ "<tt>set DebugFlag=1</tt>" from the gdb if the program is running. If the
+ program hasn't been started yet, you can always just run it with
+ <tt>-debug</tt>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="DEBUG_TYPE">Fine grained debug info with <tt>DEBUG_TYPE</tt> and
+ the <tt>-debug-only</tt> option</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Sometimes you may find yourself in a situation where enabling <tt>-debug</tt>
+ just turns on <b>too much</b> information (such as when working on the code
+ generator). If you want to enable debug information with more fine-grained
+ control, you define the <tt>DEBUG_TYPE</tt> macro and the <tt>-debug</tt> only
+ option as follows:</p>
+
+ <div class="doc_code">
+ <pre>
+ DOUT << "No debug type\n";
+ #undef DEBUG_TYPE
+ #define DEBUG_TYPE "foo"
+ DOUT << "'foo' debug type\n";
+ #undef DEBUG_TYPE
+ #define DEBUG_TYPE "bar"
+ DOUT << "'bar' debug type\n";
+ #undef DEBUG_TYPE
+ #define DEBUG_TYPE ""
+ DOUT << "No debug type (2)\n";
+ </pre>
+ </div>
+
+ <p>Then you can run your pass like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ $ opt < a.bc > /dev/null -mypass
+ <i><no output></i>
+ $ opt < a.bc > /dev/null -mypass -debug
+ No debug type
+ 'foo' debug type
+ 'bar' debug type
+ No debug type (2)
+ $ opt < a.bc > /dev/null -mypass -debug-only=foo
+ 'foo' debug type
+ $ opt < a.bc > /dev/null -mypass -debug-only=bar
+ 'bar' debug type
+ </pre>
+ </div>
+
+ <p>Of course, in practice, you should only set <tt>DEBUG_TYPE</tt> at the top of
+ a file, to specify the debug type for the entire module (if you do this before
+ you <tt>#include "llvm/Support/Debug.h"</tt>, you don't have to insert the ugly
+ <tt>#undef</tt>'s). Also, you should use names more meaningful than "foo" and
+ "bar", because there is no system in place to ensure that names do not
+ conflict. If two different modules use the same string, they will all be turned
+ on when the name is specified. This allows, for example, all debug information
+ for instruction scheduling to be enabled with <tt>-debug-type=InstrSched</tt>,
+ even if the source lives in multiple files.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Statistic">The <tt>Statistic</tt> class & <tt>-stats</tt>
+ option</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The "<tt><a
+ href="/doxygen/Statistic_8h-source.html">llvm/ADT/Statistic.h</a></tt>" file
+ provides a class named <tt>Statistic</tt> that is used as a unified way to
+ keep track of what the LLVM compiler is doing and how effective various
+ optimizations are. It is useful to see what optimizations are contributing to
+ making a particular program run faster.</p>
+
+ <p>Often you may run your pass on some big program, and you're interested to see
+ how many times it makes a certain transformation. Although you can do this with
+ hand inspection, or some ad-hoc method, this is a real pain and not very useful
+ for big programs. Using the <tt>Statistic</tt> class makes it very easy to
+ keep track of this information, and the calculated information is presented in a
+ uniform manner with the rest of the passes being executed.</p>
+
+ <p>There are many examples of <tt>Statistic</tt> uses, but the basics of using
+ it are as follows:</p>
+
+ <ol>
+ <li><p>Define your statistic like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ #define <a href="#DEBUG_TYPE">DEBUG_TYPE</a> "mypassname" <i>// This goes before any #includes.</i>
+ STATISTIC(NumXForms, "The # of times I did stuff");
+ </pre>
+ </div>
+
+ <p>The <tt>STATISTIC</tt> macro defines a static variable, whose name is
+ specified by the first argument. The pass name is taken from the DEBUG_TYPE
+ macro, and the description is taken from the second argument. The variable
+ defined ("NumXForms" in this case) acts like an unsigned integer.</p></li>
+
+ <li><p>Whenever you make a transformation, bump the counter:</p>
+
+ <div class="doc_code">
+ <pre>
+ ++NumXForms; // <i>I did stuff!</i>
+ </pre>
+ </div>
+
+ </li>
+ </ol>
+
+ <p>That's all you have to do. To get '<tt>opt</tt>' to print out the
+ statistics gathered, use the '<tt>-stats</tt>' option:</p>
+
+ <div class="doc_code">
+ <pre>
+ $ opt -stats -mypassname < program.bc > /dev/null
+ <i>... statistics output ...</i>
+ </pre>
+ </div>
+
+ <p> When running <tt>opt</tt> on a C file from the SPEC benchmark
+ suite, it gives a report that looks like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ 7646 bitcodewriter - Number of normal instructions
+ 725 bitcodewriter - Number of oversized instructions
+ 129996 bitcodewriter - Number of bitcode bytes written
+ 2817 raise - Number of insts DCEd or constprop'd
+ 3213 raise - Number of cast-of-self removed
+ 5046 raise - Number of expression trees converted
+ 75 raise - Number of other getelementptr's formed
+ 138 raise - Number of load/store peepholes
+ 42 deadtypeelim - Number of unused typenames removed from symtab
+ 392 funcresolve - Number of varargs functions resolved
+ 27 globaldce - Number of global variables removed
+ 2 adce - Number of basic blocks removed
+ 134 cee - Number of branches revectored
+ 49 cee - Number of setcc instruction eliminated
+ 532 gcse - Number of loads removed
+ 2919 gcse - Number of instructions removed
+ 86 indvars - Number of canonical indvars added
+ 87 indvars - Number of aux indvars removed
+ 25 instcombine - Number of dead inst eliminate
+ 434 instcombine - Number of insts combined
+ 248 licm - Number of load insts hoisted
+ 1298 licm - Number of insts hoisted to a loop pre-header
+ 3 licm - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
+ 75 mem2reg - Number of alloca's promoted
+ 1444 cfgsimplify - Number of blocks simplified
+ </pre>
+ </div>
+
+ <p>Obviously, with so many optimizations, having a unified framework for this
+ stuff is very nice. Making your pass fit well into the framework makes it more
+ maintainable and useful.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ViewGraph">Viewing graphs while debugging code</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Several of the important data structures in LLVM are graphs: for example
+ CFGs made out of LLVM <a href="#BasicBlock">BasicBlock</a>s, CFGs made out of
+ LLVM <a href="CodeGenerator.html#machinebasicblock">MachineBasicBlock</a>s, and
+ <a href="CodeGenerator.html#selectiondag_intro">Instruction Selection
+ DAGs</a>. In many cases, while debugging various parts of the compiler, it is
+ nice to instantly visualize these graphs.</p>
+
+ <p>LLVM provides several callbacks that are available in a debug build to do
+ exactly that. If you call the <tt>Function::viewCFG()</tt> method, for example,
+ the current LLVM tool will pop up a window containing the CFG for the function
+ where each basic block is a node in the graph, and each node contains the
+ instructions in the block. Similarly, there also exists
+ <tt>Function::viewCFGOnly()</tt> (does not include the instructions), the
+ <tt>MachineFunction::viewCFG()</tt> and <tt>MachineFunction::viewCFGOnly()</tt>,
+ and the <tt>SelectionDAG::viewGraph()</tt> methods. Within GDB, for example,
+ you can usually use something like <tt>call DAG.viewGraph()</tt> to pop
+ up a window. Alternatively, you can sprinkle calls to these functions in your
+ code in places you want to debug.</p>
+
+ <p>Getting this to work requires a small amount of configuration. On Unix
+ systems with X11, install the <a href="http://www.graphviz.org">graphviz</a>
+ toolkit, and make sure 'dot' and 'gv' are in your path. If you are running on
+ Mac OS/X, download and install the Mac OS/X <a
+ href="http://www.pixelglow.com/graphviz/">Graphviz program</a>, and add
+ <tt>/Applications/Graphviz.app/Contents/MacOS/</tt> (or wherever you install
+ it) to your path. Once in your system and path are set up, rerun the LLVM
+ configure script and rebuild LLVM to enable this functionality.</p>
+
+ <p><tt>SelectionDAG</tt> has been extended to make it easier to locate
+ <i>interesting</i> nodes in large complex graphs. From gdb, if you
+ <tt>call DAG.setGraphColor(<i>node</i>, "<i>color</i>")</tt>, then the
+ next <tt>call DAG.viewGraph()</tt> would highlight the node in the
+ specified color (choices of colors can be found at <a
+ href="http://www.graphviz.org/doc/info/colors.html">colors</a>.) More
+ complex node attributes can be provided with <tt>call
+ DAG.setGraphAttrs(<i>node</i>, "<i>attributes</i>")</tt> (choices can be
+ found at <a href="http://www.graphviz.org/doc/info/attrs.html">Graph
+ Attributes</a>.) If you want to restart and clear all the current graph
+ attributes, then you can <tt>call DAG.clearGraphAttrs()</tt>. </p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="datastructure">Picking the Right Data Structure for a Task</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM has a plethora of data structures in the <tt>llvm/ADT/</tt> directory,
+ and we commonly use STL data structures. This section describes the trade-offs
+ you should consider when you pick one.</p>
+
+ <p>
+ The first step is a choose your own adventure: do you want a sequential
+ container, a set-like container, or a map-like container? The most important
+ thing when choosing a container is the algorithmic properties of how you plan to
+ access the container. Based on that, you should use:</p>
+
+ <ul>
+ <li>a <a href="#ds_map">map-like</a> container if you need efficient look-up
+ of an value based on another value. Map-like containers also support
+ efficient queries for containment (whether a key is in the map). Map-like
+ containers generally do not support efficient reverse mapping (values to
+ keys). If you need that, use two maps. Some map-like containers also
+ support efficient iteration through the keys in sorted order. Map-like
+ containers are the most expensive sort, only use them if you need one of
+ these capabilities.</li>
+
+ <li>a <a href="#ds_set">set-like</a> container if you need to put a bunch of
+ stuff into a container that automatically eliminates duplicates. Some
+ set-like containers support efficient iteration through the elements in
+ sorted order. Set-like containers are more expensive than sequential
+ containers.
+ </li>
+
+ <li>a <a href="#ds_sequential">sequential</a> container provides
+ the most efficient way to add elements and keeps track of the order they are
+ added to the collection. They permit duplicates and support efficient
+ iteration, but do not support efficient look-up based on a key.
+ </li>
+
+ <li>a <a href="#ds_bit">bit</a> container provides an efficient way to store and
+ perform set operations on sets of numeric id's, while automatically
+ eliminating duplicates. Bit containers require a maximum of 1 bit for each
+ identifier you want to store.
+ </li>
+ </ul>
+
+ <p>
+ Once the proper category of container is determined, you can fine tune the
+ memory use, constant factors, and cache behaviors of access by intelligently
+ picking a member of the category. Note that constant factors and cache behavior
+ can be a big deal. If you have a vector that usually only contains a few
+ elements (but could contain many), for example, it's much better to use
+ <a href="#dss_smallvector">SmallVector</a> than <a href="#dss_vector">vector</a>
+ . Doing so avoids (relatively) expensive malloc/free calls, which dwarf the
+ cost of adding the elements to the container. </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ds_sequential">Sequential Containers (std::vector, std::list, etc)</a>
+ </div>
+
+ <div class="doc_text">
+ There are a variety of sequential containers available for you, based on your
+ needs. Pick the first in this section that will do what you want.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_fixedarrays">Fixed Size Arrays</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Fixed size arrays are very simple and very fast. They are good if you know
+ exactly how many elements you have, or you have a (low) upper bound on how many
+ you have.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_heaparrays">Heap Allocated Arrays</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Heap allocated arrays (new[] + delete[]) are also simple. They are good if
+ the number of elements is variable, if you know how many elements you will need
+ before the array is allocated, and if the array is usually large (if not,
+ consider a <a href="#dss_smallvector">SmallVector</a>). The cost of a heap
+ allocated array is the cost of the new/delete (aka malloc/free). Also note that
+ if you are allocating an array of a type with a constructor, the constructor and
+ destructors will be run for every element in the array (re-sizable vectors only
+ construct those elements actually used).</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_smallvector">"llvm/ADT/SmallVector.h"</a>
+ </div>
+
+ <div class="doc_text">
+ <p><tt>SmallVector<Type, N></tt> is a simple class that looks and smells
+ just like <tt>vector<Type></tt>:
+ it supports efficient iteration, lays out elements in memory order (so you can
+ do pointer arithmetic between elements), supports efficient push_back/pop_back
+ operations, supports efficient random access to its elements, etc.</p>
+
+ <p>The advantage of SmallVector is that it allocates space for
+ some number of elements (N) <b>in the object itself</b>. Because of this, if
+ the SmallVector is dynamically smaller than N, no malloc is performed. This can
+ be a big win in cases where the malloc/free call is far more expensive than the
+ code that fiddles around with the elements.</p>
+
+ <p>This is good for vectors that are "usually small" (e.g. the number of
+ predecessors/successors of a block is usually less than 8). On the other hand,
+ this makes the size of the SmallVector itself large, so you don't want to
+ allocate lots of them (doing so will waste a lot of space). As such,
+ SmallVectors are most useful when on the stack.</p>
+
+ <p>SmallVector also provides a nice portable and efficient replacement for
+ <tt>alloca</tt>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_vector"><vector></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ std::vector is well loved and respected. It is useful when SmallVector isn't:
+ when the size of the vector is often large (thus the small optimization will
+ rarely be a benefit) or if you will be allocating many instances of the vector
+ itself (which would waste space for elements that aren't in the container).
+ vector is also useful when interfacing with code that expects vectors :).
+ </p>
+
+ <p>One worthwhile note about std::vector: avoid code like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ for ( ... ) {
+ std::vector<foo> V;
+ use V;
+ }
+ </pre>
+ </div>
+
+ <p>Instead, write this as:</p>
+
+ <div class="doc_code">
+ <pre>
+ std::vector<foo> V;
+ for ( ... ) {
+ use V;
+ V.clear();
+ }
+ </pre>
+ </div>
+
+ <p>Doing so will save (at least) one heap allocation and free per iteration of
+ the loop.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_deque"><deque></a>
+ </div>
+
+ <div class="doc_text">
+ <p>std::deque is, in some senses, a generalized version of std::vector. Like
+ std::vector, it provides constant time random access and other similar
+ properties, but it also provides efficient access to the front of the list. It
+ does not guarantee continuity of elements within memory.</p>
+
+ <p>In exchange for this extra flexibility, std::deque has significantly higher
+ constant factor costs than std::vector. If possible, use std::vector or
+ something cheaper.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_list"><list></a>
+ </div>
+
+ <div class="doc_text">
+ <p>std::list is an extremely inefficient class that is rarely useful.
+ It performs a heap allocation for every element inserted into it, thus having an
+ extremely high constant factor, particularly for small data types. std::list
+ also only supports bidirectional iteration, not random access iteration.</p>
+
+ <p>In exchange for this high cost, std::list supports efficient access to both
+ ends of the list (like std::deque, but unlike std::vector or SmallVector). In
+ addition, the iterator invalidation characteristics of std::list are stronger
+ than that of a vector class: inserting or removing an element into the list does
+ not invalidate iterator or pointers to other elements in the list.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_ilist">llvm/ADT/ilist</a>
+ </div>
+
+ <div class="doc_text">
+ <p><tt>ilist<T></tt> implements an 'intrusive' doubly-linked list. It is
+ intrusive, because it requires the element to store and provide access to the
+ prev/next pointers for the list.</p>
+
+ <p>ilist has the same drawbacks as std::list, and additionally requires an
+ ilist_traits implementation for the element type, but it provides some novel
+ characteristics. In particular, it can efficiently store polymorphic objects,
+ the traits class is informed when an element is inserted or removed from the
+ list, and ilists are guaranteed to support a constant-time splice operation.
+ </p>
+
+ <p>These properties are exactly what we want for things like Instructions and
+ basic blocks, which is why these are implemented with ilists.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_other">Other Sequential Container options</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Other STL containers are available, such as std::string.</p>
+
+ <p>There are also various STL adapter classes such as std::queue,
+ std::priority_queue, std::stack, etc. These provide simplified access to an
+ underlying container but don't affect the cost of the container itself.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ds_set">Set-Like Containers (std::set, SmallSet, SetVector, etc)</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Set-like containers are useful when you need to canonicalize multiple values
+ into a single representation. There are several different choices for how to do
+ this, providing various trade-offs.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_sortedvectorset">A sorted 'vector'</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If you intend to insert a lot of elements, then do a lot of queries, a
+ great approach is to use a vector (or other sequential container) with
+ std::sort+std::unique to remove duplicates. This approach works really well if
+ your usage pattern has these two distinct phases (insert then query), and can be
+ coupled with a good choice of <a href="#ds_sequential">sequential container</a>.
+ </p>
+
+ <p>
+ This combination provides the several nice properties: the result data is
+ contiguous in memory (good for cache locality), has few allocations, is easy to
+ address (iterators in the final vector are just indices or pointers), and can be
+ efficiently queried with a standard binary or radix search.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_smallset">"llvm/ADT/SmallSet.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If you have a set-like data structure that is usually small and whose elements
+ are reasonably small, a <tt>SmallSet<Type, N></tt> is a good choice. This set
+ has space for N elements in place (thus, if the set is dynamically smaller than
+ N, no malloc traffic is required) and accesses them with a simple linear search.
+ When the set grows beyond 'N' elements, it allocates a more expensive representation that
+ guarantees efficient access (for most types, it falls back to std::set, but for
+ pointers it uses something far better, <a
+ href="#dss_smallptrset">SmallPtrSet</a>).</p>
+
+ <p>The magic of this class is that it handles small sets extremely efficiently,
+ but gracefully handles extremely large sets without loss of efficiency. The
+ drawback is that the interface is quite small: it supports insertion, queries
+ and erasing, but does not support iteration.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_smallptrset">"llvm/ADT/SmallPtrSet.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is
+ transparently implemented with a SmallPtrSet), but also supports iterators. If
+ more than 'N' insertions are performed, a single quadratically
+ probed hash table is allocated and grows as needed, providing extremely
+ efficient access (constant time insertion/deleting/queries with low constant
+ factors) and is very stingy with malloc traffic.</p>
+
+ <p>Note that, unlike std::set, the iterators of SmallPtrSet are invalidated
+ whenever an insertion occurs. Also, the values visited by the iterators are not
+ visited in sorted order.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_denseset">"llvm/ADT/DenseSet.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ DenseSet is a simple quadratically probed hash table. It excels at supporting
+ small values: it uses a single allocation to hold all of the pairs that
+ are currently inserted in the set. DenseSet is a great way to unique small
+ values that are not simple pointers (use <a
+ href="#dss_smallptrset">SmallPtrSet</a> for pointers). Note that DenseSet has
+ the same requirements for the value type that <a
+ href="#dss_densemap">DenseMap</a> has.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_FoldingSet">"llvm/ADT/FoldingSet.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ FoldingSet is an aggregate class that is really good at uniquing
+ expensive-to-create or polymorphic objects. It is a combination of a chained
+ hash table with intrusive links (uniqued objects are required to inherit from
+ FoldingSetNode) that uses <a href="#dss_smallvector">SmallVector</a> as part of
+ its ID process.</p>
+
+ <p>Consider a case where you want to implement a "getOrCreateFoo" method for
+ a complex object (for example, a node in the code generator). The client has a
+ description of *what* it wants to generate (it knows the opcode and all the
+ operands), but we don't want to 'new' a node, then try inserting it into a set
+ only to find out it already exists, at which point we would have to delete it
+ and return the node that already exists.
+ </p>
+
+ <p>To support this style of client, FoldingSet perform a query with a
+ FoldingSetNodeID (which wraps SmallVector) that can be used to describe the
+ element that we want to query for. The query either returns the element
+ matching the ID or it returns an opaque ID that indicates where insertion should
+ take place. Construction of the ID usually does not require heap traffic.</p>
+
+ <p>Because FoldingSet uses intrusive links, it can support polymorphic objects
+ in the set (for example, you can have SDNode instances mixed with LoadSDNodes).
+ Because the elements are individually allocated, pointers to the elements are
+ stable: inserting or removing elements does not invalidate any pointers to other
+ elements.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_set"><set></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>std::set</tt> is a reasonable all-around set class, which is decent at
+ many things but great at nothing. std::set allocates memory for each element
+ inserted (thus it is very malloc intensive) and typically stores three pointers
+ per element in the set (thus adding a large amount of per-element space
+ overhead). It offers guaranteed log(n) performance, which is not particularly
+ fast from a complexity standpoint (particularly if the elements of the set are
+ expensive to compare, like strings), and has extremely high constant factors for
+ lookup, insertion and removal.</p>
+
+ <p>The advantages of std::set are that its iterators are stable (deleting or
+ inserting an element from the set does not affect iterators or pointers to other
+ elements) and that iteration over the set is guaranteed to be in sorted order.
+ If the elements in the set are large, then the relative overhead of the pointers
+ and malloc traffic is not a big deal, but if the elements of the set are small,
+ std::set is almost never a good choice.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_setvector">"llvm/ADT/SetVector.h"</a>
+ </div>
+
+ <div class="doc_text">
+ <p>LLVM's SetVector<Type> is an adapter class that combines your choice of
+ a set-like container along with a <a href="#ds_sequential">Sequential
+ Container</a>. The important property
+ that this provides is efficient insertion with uniquing (duplicate elements are
+ ignored) with iteration support. It implements this by inserting elements into
+ both a set-like container and the sequential container, using the set-like
+ container for uniquing and the sequential container for iteration.
+ </p>
+
+ <p>The difference between SetVector and other sets is that the order of
+ iteration is guaranteed to match the order of insertion into the SetVector.
+ This property is really important for things like sets of pointers. Because
+ pointer values are non-deterministic (e.g. vary across runs of the program on
+ different machines), iterating over the pointers in the set will
+ not be in a well-defined order.</p>
+
+ <p>
+ The drawback of SetVector is that it requires twice as much space as a normal
+ set and has the sum of constant factors from the set-like container and the
+ sequential container that it uses. Use it *only* if you need to iterate over
+ the elements in a deterministic order. SetVector is also expensive to delete
+ elements out of (linear time), unless you use it's "pop_back" method, which is
+ faster.
+ </p>
+
+ <p>SetVector is an adapter class that defaults to using std::vector and std::set
+ for the underlying containers, so it is quite expensive. However,
+ <tt>"llvm/ADT/SetVector.h"</tt> also provides a SmallSetVector class, which
+ defaults to using a SmallVector and SmallSet of a specified size. If you use
+ this, and if your sets are dynamically smaller than N, you will save a lot of
+ heap traffic.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_uniquevector">"llvm/ADT/UniqueVector.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ UniqueVector is similar to <a href="#dss_setvector">SetVector</a>, but it
+ retains a unique ID for each element inserted into the set. It internally
+ contains a map and a vector, and it assigns a unique ID for each value inserted
+ into the set.</p>
+
+ <p>UniqueVector is very expensive: its cost is the sum of the cost of
+ maintaining both the map and vector, it has high complexity, high constant
+ factors, and produces a lot of malloc traffic. It should be avoided.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_otherset">Other Set-Like Container Options</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ The STL provides several other options, such as std::multiset and the various
+ "hash_set" like containers (whether from C++ TR1 or from the SGI library).</p>
+
+ <p>std::multiset is useful if you're not interested in elimination of
+ duplicates, but has all the drawbacks of std::set. A sorted vector (where you
+ don't delete duplicate entries) or some other approach is almost always
+ better.</p>
+
+ <p>The various hash_set implementations (exposed portably by
+ "llvm/ADT/hash_set") is a simple chained hashtable. This algorithm is as malloc
+ intensive as std::set (performing an allocation for each element inserted,
+ thus having really high constant factors) but (usually) provides O(1)
+ insertion/deletion of elements. This can be useful if your elements are large
+ (thus making the constant-factor cost relatively low) or if comparisons are
+ expensive. Element iteration does not visit elements in a useful order.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ds_map">Map-Like Containers (std::map, DenseMap, etc)</a>
+ </div>
+
+ <div class="doc_text">
+ Map-like containers are useful when you want to associate data to a key. As
+ usual, there are a lot of different ways to do this. :)
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_sortedvectormap">A sorted 'vector'</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ If your usage pattern follows a strict insert-then-query approach, you can
+ trivially use the same approach as <a href="#dss_sortedvectorset">sorted vectors
+ for set-like containers</a>. The only difference is that your query function
+ (which uses std::lower_bound to get efficient log(n) lookup) should only compare
+ the key, not both the key and value. This yields the same advantages as sorted
+ vectors for sets.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_stringmap">"llvm/ADT/StringMap.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ Strings are commonly used as keys in maps, and they are difficult to support
+ efficiently: they are variable length, inefficient to hash and compare when
+ long, expensive to copy, etc. StringMap is a specialized container designed to
+ cope with these issues. It supports mapping an arbitrary range of bytes to an
+ arbitrary other object.</p>
+
+ <p>The StringMap implementation uses a quadratically-probed hash table, where
+ the buckets store a pointer to the heap allocated entries (and some other
+ stuff). The entries in the map must be heap allocated because the strings are
+ variable length. The string data (key) and the element object (value) are
+ stored in the same allocation with the string data immediately after the element
+ object. This container guarantees the "<tt>(char*)(&Value+1)</tt>" points
+ to the key string for a value.</p>
+
+ <p>The StringMap is very fast for several reasons: quadratic probing is very
+ cache efficient for lookups, the hash value of strings in buckets is not
+ recomputed when lookup up an element, StringMap rarely has to touch the
+ memory for unrelated objects when looking up a value (even when hash collisions
+ happen), hash table growth does not recompute the hash values for strings
+ already in the table, and each pair in the map is store in a single allocation
+ (the string data is stored in the same allocation as the Value of a pair).</p>
+
+ <p>StringMap also provides query methods that take byte ranges, so it only ever
+ copies a string if a value is inserted into the table.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_indexedmap">"llvm/ADT/IndexedMap.h"</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ IndexedMap is a specialized container for mapping small dense integers (or
+ values that can be mapped to small dense integers) to some other type. It is
+ internally implemented as a vector with a mapping function that maps the keys to
+ the dense integer range.
+ </p>
+
+ <p>
+ This is useful for cases like virtual registers in the LLVM code generator: they
+ have a dense mapping that is offset by a compile-time constant (the first
+ virtual register ID).</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_densemap">"llvm/ADT/DenseMap.h"</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ DenseMap is a simple quadratically probed hash table. It excels at supporting
+ small keys and values: it uses a single allocation to hold all of the pairs that
+ are currently inserted in the map. DenseMap is a great way to map pointers to
+ pointers, or map other small types to each other.
+ </p>
+
+ <p>
+ There are several aspects of DenseMap that you should be aware of, however. The
+ iterators in a densemap are invalidated whenever an insertion occurs, unlike
+ map. Also, because DenseMap allocates space for a large number of key/value
+ pairs (it starts with 64 by default), it will waste a lot of space if your keys
+ or values are large. Finally, you must implement a partial specialization of
+ DenseMapInfo for the key that you want, if it isn't already supported. This
+ is required to tell DenseMap about two special marker values (which can never be
+ inserted into the map) that it needs internally.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_map"><map></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ std::map has similar characteristics to <a href="#dss_set">std::set</a>: it uses
+ a single allocation per pair inserted into the map, it offers log(n) lookup with
+ an extremely large constant factor, imposes a space penalty of 3 pointers per
+ pair in the map, etc.</p>
+
+ <p>std::map is most useful when your keys or values are very large, if you need
+ to iterate over the collection in sorted order, or if you need stable iterators
+ into the map (i.e. they don't get invalidated if an insertion or deletion of
+ another element takes place).</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_othermap">Other Map-Like Container Options</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ The STL provides several other options, such as std::multimap and the various
+ "hash_map" like containers (whether from C++ TR1 or from the SGI library).</p>
+
+ <p>std::multimap is useful if you want to map a key to multiple values, but has
+ all the drawbacks of std::map. A sorted vector or some other approach is almost
+ always better.</p>
+
+ <p>The various hash_map implementations (exposed portably by
+ "llvm/ADT/hash_map") are simple chained hash tables. This algorithm is as
+ malloc intensive as std::map (performing an allocation for each element
+ inserted, thus having really high constant factors) but (usually) provides O(1)
+ insertion/deletion of elements. This can be useful if your elements are large
+ (thus making the constant-factor cost relatively low) or if comparisons are
+ expensive. Element iteration does not visit elements in a useful order.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ds_bit">Bit storage containers (BitVector, SparseBitVector)</a>
+ </div>
+
+ <div class="doc_text">
+ <p>Unlike the other containers, there are only two bit storage containers, and
+ choosing when to use each is relatively straightforward.</p>
+
+ <p>One additional option is
+ <tt>std::vector<bool></tt>: we discourage its use for two reasons 1) the
+ implementation in many common compilers (e.g. commonly available versions of
+ GCC) is extremely inefficient and 2) the C++ standards committee is likely to
+ deprecate this container and/or change it significantly somehow. In any case,
+ please don't use it.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_bitvector">BitVector</a>
+ </div>
+
+ <div class="doc_text">
+ <p> The BitVector container provides a fixed size set of bits for manipulation.
+ It supports individual bit setting/testing, as well as set operations. The set
+ operations take time O(size of bitvector), but operations are performed one word
+ at a time, instead of one bit at a time. This makes the BitVector very fast for
+ set operations compared to other containers. Use the BitVector when you expect
+ the number of set bits to be high (IE a dense set).
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="dss_sparsebitvector">SparseBitVector</a>
+ </div>
+
+ <div class="doc_text">
+ <p> The SparseBitVector container is much like BitVector, with one major
+ difference: Only the bits that are set, are stored. This makes the
+ SparseBitVector much more space efficient than BitVector when the set is sparse,
+ as well as making set operations O(number of set bits) instead of O(size of
+ universe). The downside to the SparseBitVector is that setting and testing of random bits is O(N), and on large SparseBitVectors, this can be slower than BitVector. In our implementation, setting or testing bits in sorted order
+ (either forwards or reverse) is O(1) worst case. Testing and setting bits within 128 bits (depends on size) of the current bit is also O(1). As a general statement, testing/setting bits in a SparseBitVector is O(distance away from last set bit).
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="common">Helpful Hints for Common Operations</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section describes how to perform some very simple transformations of
+ LLVM code. This is meant to give examples of common idioms used, showing the
+ practical side of LLVM transformations. <p> Because this is a "how-to" section,
+ you should also read about the main classes that you will be working with. The
+ <a href="#coreclasses">Core LLVM Class Hierarchy Reference</a> contains details
+ and descriptions of the main classes that you should know about.</p>
+
+ </div>
+
+ <!-- NOTE: this section should be heavy on example code -->
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="inspection">Basic Inspection and Traversal Routines</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The LLVM compiler infrastructure have many different data structures that may
+ be traversed. Following the example of the C++ standard template library, the
+ techniques used to traverse these various data structures are all basically the
+ same. For a enumerable sequence of values, the <tt>XXXbegin()</tt> function (or
+ method) returns an iterator to the start of the sequence, the <tt>XXXend()</tt>
+ function returns an iterator pointing to one past the last valid element of the
+ sequence, and there is some <tt>XXXiterator</tt> data type that is common
+ between the two operations.</p>
+
+ <p>Because the pattern for iteration is common across many different aspects of
+ the program representation, the standard template library algorithms may be used
+ on them, and it is easier to remember how to iterate. First we show a few common
+ examples of the data structures that need to be traversed. Other data
+ structures are traversed in very similar ways.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="iterate_function">Iterating over the </a><a
+ href="#BasicBlock"><tt>BasicBlock</tt></a>s in a <a
+ href="#Function"><tt>Function</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>It's quite common to have a <tt>Function</tt> instance that you'd like to
+ transform in some way; in particular, you'd like to manipulate its
+ <tt>BasicBlock</tt>s. To facilitate this, you'll need to iterate over all of
+ the <tt>BasicBlock</tt>s that constitute the <tt>Function</tt>. The following is
+ an example that prints the name of a <tt>BasicBlock</tt> and the number of
+ <tt>Instruction</tt>s it contains:</p>
+
+ <div class="doc_code">
+ <pre>
+ // <i>func is a pointer to a Function instance</i>
+ for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i)
+ // <i>Print out the name of the basic block if it has one, and then the</i>
+ // <i>number of instructions that it contains</i>
+ llvm::cerr << "Basic block (name=" << i->getName() << ") has "
+ << i->size() << " instructions.\n";
+ </pre>
+ </div>
+
+ <p>Note that i can be used as if it were a pointer for the purposes of
+ invoking member functions of the <tt>Instruction</tt> class. This is
+ because the indirection operator is overloaded for the iterator
+ classes. In the above code, the expression <tt>i->size()</tt> is
+ exactly equivalent to <tt>(*i).size()</tt> just like you'd expect.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="iterate_basicblock">Iterating over the </a><a
+ href="#Instruction"><tt>Instruction</tt></a>s in a <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Just like when dealing with <tt>BasicBlock</tt>s in <tt>Function</tt>s, it's
+ easy to iterate over the individual instructions that make up
+ <tt>BasicBlock</tt>s. Here's a code snippet that prints out each instruction in
+ a <tt>BasicBlock</tt>:</p>
+
+ <div class="doc_code">
+ <pre>
+ // <i>blk is a pointer to a BasicBlock instance</i>
+ for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
+ // <i>The next statement works since operator<<(ostream&,...)</i>
+ // <i>is overloaded for Instruction&</i>
+ llvm::cerr << *i << "\n";
+ </pre>
+ </div>
+
+ <p>However, this isn't really the best way to print out the contents of a
+ <tt>BasicBlock</tt>! Since the ostream operators are overloaded for virtually
+ anything you'll care about, you could have just invoked the print routine on the
+ basic block itself: <tt>llvm::cerr << *blk << "\n";</tt>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="iterate_institer">Iterating over the </a><a
+ href="#Instruction"><tt>Instruction</tt></a>s in a <a
+ href="#Function"><tt>Function</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If you're finding that you commonly iterate over a <tt>Function</tt>'s
+ <tt>BasicBlock</tt>s and then that <tt>BasicBlock</tt>'s <tt>Instruction</tt>s,
+ <tt>InstIterator</tt> should be used instead. You'll need to include <a
+ href="/doxygen/InstIterator_8h-source.html"><tt>llvm/Support/InstIterator.h</tt></a>,
+ and then instantiate <tt>InstIterator</tt>s explicitly in your code. Here's a
+ small example that shows how to dump all instructions in a function to the standard error stream:<p>
+
+ <div class="doc_code">
+ <pre>
+ #include "<a href="/doxygen/InstIterator_8h-source.html">llvm/Support/InstIterator.h</a>"
+
+ // <i>F is a pointer to a Function instance</i>
+ for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
+ llvm::cerr << *I << "\n";
+ </pre>
+ </div>
+
+ <p>Easy, isn't it? You can also use <tt>InstIterator</tt>s to fill a
+ work list with its initial contents. For example, if you wanted to
+ initialize a work list to contain all instructions in a <tt>Function</tt>
+ F, all you would need to do is something like:</p>
+
+ <div class="doc_code">
+ <pre>
+ std::set<Instruction*> worklist;
+ // or better yet, SmallPtrSet<Instruction*, 64> worklist;
+
+ for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)
+ worklist.insert(&*I);
+ </pre>
+ </div>
+
+ <p>The STL set <tt>worklist</tt> would now contain all instructions in the
+ <tt>Function</tt> pointed to by F.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="iterate_convert">Turning an iterator into a class pointer (and
+ vice-versa)</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Sometimes, it'll be useful to grab a reference (or pointer) to a class
+ instance when all you've got at hand is an iterator. Well, extracting
+ a reference or a pointer from an iterator is very straight-forward.
+ Assuming that <tt>i</tt> is a <tt>BasicBlock::iterator</tt> and <tt>j</tt>
+ is a <tt>BasicBlock::const_iterator</tt>:</p>
+
+ <div class="doc_code">
+ <pre>
+ Instruction& inst = *i; // <i>Grab reference to instruction reference</i>
+ Instruction* pinst = &*i; // <i>Grab pointer to instruction reference</i>
+ const Instruction& inst = *j;
+ </pre>
+ </div>
+
+ <p>However, the iterators you'll be working with in the LLVM framework are
+ special: they will automatically convert to a ptr-to-instance type whenever they
+ need to. Instead of dereferencing the iterator and then taking the address of
+ the result, you can simply assign the iterator to the proper pointer type and
+ you get the dereference and address-of operation as a result of the assignment
+ (behind the scenes, this is a result of overloading casting mechanisms). Thus
+ the last line of the last example,</p>
+
+ <div class="doc_code">
+ <pre>
+ Instruction *pinst = &*i;
+ </pre>
+ </div>
+
+ <p>is semantically equivalent to</p>
+
+ <div class="doc_code">
+ <pre>
+ Instruction *pinst = i;
+ </pre>
+ </div>
+
+ <p>It's also possible to turn a class pointer into the corresponding iterator,
+ and this is a constant time operation (very efficient). The following code
+ snippet illustrates use of the conversion constructors provided by LLVM
+ iterators. By using these, you can explicitly grab the iterator of something
+ without actually obtaining it via iteration over some structure:</p>
+
+ <div class="doc_code">
+ <pre>
+ void printNextInstruction(Instruction* inst) {
+ BasicBlock::iterator it(inst);
+ ++it; // <i>After this line, it refers to the instruction after *inst</i>
+ if (it != inst->getParent()->end()) llvm::cerr << *it << "\n";
+ }
+ </pre>
+ </div>
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="iterate_complex">Finding call sites: a slightly more complex
+ example</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Say that you're writing a FunctionPass and would like to count all the
+ locations in the entire module (that is, across every <tt>Function</tt>) where a
+ certain function (i.e., some <tt>Function</tt>*) is already in scope. As you'll
+ learn later, you may want to use an <tt>InstVisitor</tt> to accomplish this in a
+ much more straight-forward manner, but this example will allow us to explore how
+ you'd do it if you didn't have <tt>InstVisitor</tt> around. In pseudo-code, this
+ is what we want to do:</p>
+
+ <div class="doc_code">
+ <pre>
+ initialize callCounter to zero
+ for each Function f in the Module
+ for each BasicBlock b in f
+ for each Instruction i in b
+ if (i is a CallInst and calls the given function)
+ increment callCounter
+ </pre>
+ </div>
+
+ <p>And the actual code is (remember, because we're writing a
+ <tt>FunctionPass</tt>, our <tt>FunctionPass</tt>-derived class simply has to
+ override the <tt>runOnFunction</tt> method):</p>
+
+ <div class="doc_code">
+ <pre>
+ Function* targetFunc = ...;
+
+ class OurFunctionPass : public FunctionPass {
+ public:
+ OurFunctionPass(): callCounter(0) { }
+
+ virtual runOnFunction(Function& F) {
+ for (Function::iterator b = F.begin(), be = F.end(); b != be; ++b) {
+ for (BasicBlock::iterator i = b->begin(), ie = b->end(); i != ie; ++i) {
+ if (<a href="#CallInst">CallInst</a>* callInst = <a href="#isa">dyn_cast</a><<a
+ href="#CallInst">CallInst</a>>(&*i)) {
+ // <i>We know we've encountered a call instruction, so we</i>
+ // <i>need to determine if it's a call to the</i>
+ // <i>function pointed to by m_func or not.</i>
+ if (callInst->getCalledFunction() == targetFunc)
+ ++callCounter;
+ }
+ }
+ }
+ }
+
+ private:
+ unsigned callCounter;
+ };
+ </pre>
+ </div>
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="calls_and_invokes">Treating calls and invokes the same way</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>You may have noticed that the previous example was a bit oversimplified in
+ that it did not deal with call sites generated by 'invoke' instructions. In
+ this, and in other situations, you may find that you want to treat
+ <tt>CallInst</tt>s and <tt>InvokeInst</tt>s the same way, even though their
+ most-specific common base class is <tt>Instruction</tt>, which includes lots of
+ less closely-related things. For these cases, LLVM provides a handy wrapper
+ class called <a
+ href="http://llvm.org/doxygen/classllvm_1_1CallSite.html"><tt>CallSite</tt></a>.
+ It is essentially a wrapper around an <tt>Instruction</tt> pointer, with some
+ methods that provide functionality common to <tt>CallInst</tt>s and
+ <tt>InvokeInst</tt>s.</p>
+
+ <p>This class has "value semantics": it should be passed by value, not by
+ reference and it should not be dynamically allocated or deallocated using
+ <tt>operator new</tt> or <tt>operator delete</tt>. It is efficiently copyable,
+ assignable and constructable, with costs equivalents to that of a bare pointer.
+ If you look at its definition, it has only a single pointer member.</p>
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="iterate_chains">Iterating over def-use & use-def chains</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Frequently, we might have an instance of the <a
+ href="/doxygen/classllvm_1_1Value.html">Value Class</a> and we want to
+ determine which <tt>User</tt>s use the <tt>Value</tt>. The list of all
+ <tt>User</tt>s of a particular <tt>Value</tt> is called a <i>def-use</i> chain.
+ For example, let's say we have a <tt>Function*</tt> named <tt>F</tt> to a
+ particular function <tt>foo</tt>. Finding all of the instructions that
+ <i>use</i> <tt>foo</tt> is as simple as iterating over the <i>def-use</i> chain
+ of <tt>F</tt>:</p>
+
+ <div class="doc_code">
+ <pre>
+ Function *F = ...;
+
+ for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i)
+ if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
+ llvm::cerr << "F is used in instruction:\n";
+ llvm::cerr << *Inst << "\n";
+ }
+ </pre>
+ </div>
+
+ <p>Alternately, it's common to have an instance of the <a
+ href="/doxygen/classllvm_1_1User.html">User Class</a> and need to know what
+ <tt>Value</tt>s are used by it. The list of all <tt>Value</tt>s used by a
+ <tt>User</tt> is known as a <i>use-def</i> chain. Instances of class
+ <tt>Instruction</tt> are common <tt>User</tt>s, so we might want to iterate over
+ all of the values that a particular instruction uses (that is, the operands of
+ the particular <tt>Instruction</tt>):</p>
+
+ <div class="doc_code">
+ <pre>
+ Instruction *pi = ...;
+
+ for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
+ Value *v = *i;
+ // <i>...</i>
+ }
+ </pre>
+ </div>
+
+ <!--
+ def-use chains ("finding all users of"): Value::use_begin/use_end
+ use-def chains ("finding all values used"): User::op_begin/op_end [op=operand]
+ -->
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="iterate_preds">Iterating over predecessors &
+ successors of blocks</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Iterating over the predecessors and successors of a block is quite easy
+ with the routines defined in <tt>"llvm/Support/CFG.h"</tt>. Just use code like
+ this to iterate over all predecessors of BB:</p>
+
+ <div class="doc_code">
+ <pre>
+ #include "llvm/Support/CFG.h"
+ BasicBlock *BB = ...;
+
+ for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++PI) {
+ BasicBlock *Pred = *PI;
+ // <i>...</i>
+ }
+ </pre>
+ </div>
+
+ <p>Similarly, to iterate over successors use
+ succ_iterator/succ_begin/succ_end.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="simplechanges">Making simple changes</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>There are some primitive transformation operations present in the LLVM
+ infrastructure that are worth knowing about. When performing
+ transformations, it's fairly common to manipulate the contents of basic
+ blocks. This section describes some of the common methods for doing so
+ and gives example code.</p>
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="schanges_creating">Creating and inserting new
+ <tt>Instruction</tt>s</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><i>Instantiating Instructions</i></p>
+
+ <p>Creation of <tt>Instruction</tt>s is straight-forward: simply call the
+ constructor for the kind of instruction to instantiate and provide the necessary
+ parameters. For example, an <tt>AllocaInst</tt> only <i>requires</i> a
+ (const-ptr-to) <tt>Type</tt>. Thus:</p>
+
+ <div class="doc_code">
+ <pre>
+ AllocaInst* ai = new AllocaInst(Type::Int32Ty);
+ </pre>
+ </div>
+
+ <p>will create an <tt>AllocaInst</tt> instance that represents the allocation of
+ one integer in the current stack frame, at run time. Each <tt>Instruction</tt>
+ subclass is likely to have varying default parameters which change the semantics
+ of the instruction, so refer to the <a
+ href="/doxygen/classllvm_1_1Instruction.html">doxygen documentation for the subclass of
+ Instruction</a> that you're interested in instantiating.</p>
+
+ <p><i>Naming values</i></p>
+
+ <p>It is very useful to name the values of instructions when you're able to, as
+ this facilitates the debugging of your transformations. If you end up looking
+ at generated LLVM machine code, you definitely want to have logical names
+ associated with the results of instructions! By supplying a value for the
+ <tt>Name</tt> (default) parameter of the <tt>Instruction</tt> constructor, you
+ associate a logical name with the result of the instruction's execution at
+ run time. For example, say that I'm writing a transformation that dynamically
+ allocates space for an integer on the stack, and that integer is going to be
+ used as some kind of index by some other code. To accomplish this, I place an
+ <tt>AllocaInst</tt> at the first point in the first <tt>BasicBlock</tt> of some
+ <tt>Function</tt>, and I'm intending to use it within the same
+ <tt>Function</tt>. I might do:</p>
+
+ <div class="doc_code">
+ <pre>
+ AllocaInst* pa = new AllocaInst(Type::Int32Ty, 0, "indexLoc");
+ </pre>
+ </div>
+
+ <p>where <tt>indexLoc</tt> is now the logical name of the instruction's
+ execution value, which is a pointer to an integer on the run time stack.</p>
+
+ <p><i>Inserting instructions</i></p>
+
+ <p>There are essentially two ways to insert an <tt>Instruction</tt>
+ into an existing sequence of instructions that form a <tt>BasicBlock</tt>:</p>
+
+ <ul>
+ <li>Insertion into an explicit instruction list
+
+ <p>Given a <tt>BasicBlock* pb</tt>, an <tt>Instruction* pi</tt> within that
+ <tt>BasicBlock</tt>, and a newly-created instruction we wish to insert
+ before <tt>*pi</tt>, we do the following: </p>
+
+ <div class="doc_code">
+ <pre>
+ BasicBlock *pb = ...;
+ Instruction *pi = ...;
+ Instruction *newInst = new Instruction(...);
+
+ pb->getInstList().insert(pi, newInst); // <i>Inserts newInst before pi in pb</i>
+ </pre>
+ </div>
+
+ <p>Appending to the end of a <tt>BasicBlock</tt> is so common that
+ the <tt>Instruction</tt> class and <tt>Instruction</tt>-derived
+ classes provide constructors which take a pointer to a
+ <tt>BasicBlock</tt> to be appended to. For example code that
+ looked like: </p>
+
+ <div class="doc_code">
+ <pre>
+ BasicBlock *pb = ...;
+ Instruction *newInst = new Instruction(...);
+
+ pb->getInstList().push_back(newInst); // <i>Appends newInst to pb</i>
+ </pre>
+ </div>
+
+ <p>becomes: </p>
+
+ <div class="doc_code">
+ <pre>
+ BasicBlock *pb = ...;
+ Instruction *newInst = new Instruction(..., pb);
+ </pre>
+ </div>
+
+ <p>which is much cleaner, especially if you are creating
+ long instruction streams.</p></li>
+
+ <li>Insertion into an implicit instruction list
+
+ <p><tt>Instruction</tt> instances that are already in <tt>BasicBlock</tt>s
+ are implicitly associated with an existing instruction list: the instruction
+ list of the enclosing basic block. Thus, we could have accomplished the same
+ thing as the above code without being given a <tt>BasicBlock</tt> by doing:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ Instruction *pi = ...;
+ Instruction *newInst = new Instruction(...);
+
+ pi->getParent()->getInstList().insert(pi, newInst);
+ </pre>
+ </div>
+
+ <p>In fact, this sequence of steps occurs so frequently that the
+ <tt>Instruction</tt> class and <tt>Instruction</tt>-derived classes provide
+ constructors which take (as a default parameter) a pointer to an
+ <tt>Instruction</tt> which the newly-created <tt>Instruction</tt> should
+ precede. That is, <tt>Instruction</tt> constructors are capable of
+ inserting the newly-created instance into the <tt>BasicBlock</tt> of a
+ provided instruction, immediately before that instruction. Using an
+ <tt>Instruction</tt> constructor with a <tt>insertBefore</tt> (default)
+ parameter, the above code becomes:</p>
+
+ <div class="doc_code">
+ <pre>
+ Instruction* pi = ...;
+ Instruction* newInst = new Instruction(..., pi);
+ </pre>
+ </div>
+
+ <p>which is much cleaner, especially if you're creating a lot of
+ instructions and adding them to <tt>BasicBlock</tt>s.</p></li>
+ </ul>
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Deleting an instruction from an existing sequence of instructions that form a
+ <a href="#BasicBlock"><tt>BasicBlock</tt></a> is very straight-forward. First,
+ you must have a pointer to the instruction that you wish to delete. Second, you
+ need to obtain the pointer to that instruction's basic block. You use the
+ pointer to the basic block to get its list of instructions and then use the
+ erase function to remove your instruction. For example:</p>
+
+ <div class="doc_code">
+ <pre>
+ <a href="#Instruction">Instruction</a> *I = .. ;
+ I->eraseFromParent();
+ </pre>
+ </div>
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="schanges_replacing">Replacing an <tt>Instruction</tt> with another
+ <tt>Value</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><i>Replacing individual instructions</i></p>
+
+ <p>Including "<a href="/doxygen/BasicBlockUtils_8h-source.html">llvm/Transforms/Utils/BasicBlockUtils.h</a>"
+ permits use of two very useful replace functions: <tt>ReplaceInstWithValue</tt>
+ and <tt>ReplaceInstWithInst</tt>.</p>
+
+ <h4><a name="schanges_deleting">Deleting <tt>Instruction</tt>s</a></h4>
+
+ <ul>
+ <li><tt>ReplaceInstWithValue</tt>
+
+ <p>This function replaces all uses of a given instruction with a value,
+ and then removes the original instruction. The following example
+ illustrates the replacement of the result of a particular
+ <tt>AllocaInst</tt> that allocates memory for a single integer with a null
+ pointer to an integer.</p>
+
+ <div class="doc_code">
+ <pre>
+ AllocaInst* instToReplace = ...;
+ BasicBlock::iterator ii(instToReplace);
+
+ ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
+ Constant::getNullValue(PointerType::getUnqual(Type::Int32Ty)));
+ </pre></div></li>
+
+ <li><tt>ReplaceInstWithInst</tt>
+
+ <p>This function replaces a particular instruction with another
+ instruction, inserting the new instruction into the basic block at the
+ location where the old instruction was, and replacing any uses of the old
+ instruction with the new instruction. The following example illustrates
+ the replacement of one <tt>AllocaInst</tt> with another.</p>
+
+ <div class="doc_code">
+ <pre>
+ AllocaInst* instToReplace = ...;
+ BasicBlock::iterator ii(instToReplace);
+
+ ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
+ new AllocaInst(Type::Int32Ty, 0, "ptrToReplacedInt"));
+ </pre></div></li>
+ </ul>
+
+ <p><i>Replacing multiple uses of <tt>User</tt>s and <tt>Value</tt>s</i></p>
+
+ <p>You can use <tt>Value::replaceAllUsesWith</tt> and
+ <tt>User::replaceUsesOfWith</tt> to change more than one use at a time. See the
+ doxygen documentation for the <a href="/doxygen/classllvm_1_1Value.html">Value Class</a>
+ and <a href="/doxygen/classllvm_1_1User.html">User Class</a>, respectively, for more
+ information.</p>
+
+ <!-- Value::replaceAllUsesWith User::replaceUsesOfWith Point out:
+ include/llvm/Transforms/Utils/ especially BasicBlockUtils.h with:
+ ReplaceInstWithValue, ReplaceInstWithInst -->
+
+ </div>
+
+ <!--_______________________________________________________________________-->
+ <div class="doc_subsubsection">
+ <a name="schanges_deletingGV">Deleting <tt>GlobalVariable</tt>s</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Deleting a global variable from a module is just as easy as deleting an
+ Instruction. First, you must have a pointer to the global variable that you wish
+ to delete. You use this pointer to erase it from its parent, the module.
+ For example:</p>
+
+ <div class="doc_code">
+ <pre>
+ <a href="#GlobalVariable">GlobalVariable</a> *GV = .. ;
+
+ GV->eraseFromParent();
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="advanced">Advanced Topics</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ This section describes some of the advanced or obscure API's that most clients
+ do not need to be aware of. These API's tend manage the inner workings of the
+ LLVM system, and only need to be accessed in unusual circumstances.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="TypeResolve">LLVM Type Resolution</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ The LLVM type system has a very simple goal: allow clients to compare types for
+ structural equality with a simple pointer comparison (aka a shallow compare).
+ This goal makes clients much simpler and faster, and is used throughout the LLVM
+ system.
+ </p>
+
+ <p>
+ Unfortunately achieving this goal is not a simple matter. In particular,
+ recursive types and late resolution of opaque types makes the situation very
+ difficult to handle. Fortunately, for the most part, our implementation makes
+ most clients able to be completely unaware of the nasty internal details. The
+ primary case where clients are exposed to the inner workings of it are when
+ building a recursive type. In addition to this case, the LLVM bitcode reader,
+ assembly parser, and linker also have to be aware of the inner workings of this
+ system.
+ </p>
+
+ <p>
+ For our purposes below, we need three concepts. First, an "Opaque Type" is
+ exactly as defined in the <a href="LangRef.html#t_opaque">language
+ reference</a>. Second an "Abstract Type" is any type which includes an
+ opaque type as part of its type graph (for example "<tt>{ opaque, i32 }</tt>").
+ Third, a concrete type is a type that is not an abstract type (e.g. "<tt>{ i32,
+ float }</tt>").
+ </p>
+
+ </div>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="BuildRecType">Basic Recursive Type Construction</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ Because the most common question is "how do I build a recursive type with LLVM",
+ we answer it now and explain it as we go. Here we include enough to cause this
+ to be emitted to an output .ll file:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ %mylist = type { %mylist*, i32 }
+ </pre>
+ </div>
+
+ <p>
+ To build this, use the following LLVM APIs:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ // <i>Create the initial outer struct</i>
+ <a href="#PATypeHolder">PATypeHolder</a> StructTy = OpaqueType::get();
+ std::vector<const Type*> Elts;
+ Elts.push_back(PointerType::getUnqual(StructTy));
+ Elts.push_back(Type::Int32Ty);
+ StructType *NewSTy = StructType::get(Elts);
+
+ // <i>At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that</i>
+ // <i>the struct and the opaque type are actually the same.</i>
+ cast<OpaqueType>(StructTy.get())-><a href="#refineAbstractTypeTo">refineAbstractTypeTo</a>(NewSTy);
+
+ // <i>NewSTy is potentially invalidated, but StructTy (a <a href="#PATypeHolder">PATypeHolder</a>) is</i>
+ // <i>kept up-to-date</i>
+ NewSTy = cast<StructType>(StructTy.get());
+
+ // <i>Add a name for the type to the module symbol table (optional)</i>
+ MyModule->addTypeName("mylist", NewSTy);
+ </pre>
+ </div>
+
+ <p>
+ This code shows the basic approach used to build recursive types: build a
+ non-recursive type using 'opaque', then use type unification to close the cycle.
+ The type unification step is performed by the <tt><a
+ href="#refineAbstractTypeTo">refineAbstractTypeTo</a></tt> method, which is
+ described next. After that, we describe the <a
+ href="#PATypeHolder">PATypeHolder class</a>.
+ </p>
+
+ </div>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="refineAbstractTypeTo">The <tt>refineAbstractTypeTo</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The <tt>refineAbstractTypeTo</tt> method starts the type unification process.
+ While this method is actually a member of the DerivedType class, it is most
+ often used on OpaqueType instances. Type unification is actually a recursive
+ process. After unification, types can become structurally isomorphic to
+ existing types, and all duplicates are deleted (to preserve pointer equality).
+ </p>
+
+ <p>
+ In the example above, the OpaqueType object is definitely deleted.
+ Additionally, if there is an "{ \2*, i32}" type already created in the system,
+ the pointer and struct type created are <b>also</b> deleted. Obviously whenever
+ a type is deleted, any "Type*" pointers in the program are invalidated. As
+ such, it is safest to avoid having <i>any</i> "Type*" pointers to abstract types
+ live across a call to <tt>refineAbstractTypeTo</tt> (note that non-abstract
+ types can never move or be deleted). To deal with this, the <a
+ href="#PATypeHolder">PATypeHolder</a> class is used to maintain a stable
+ reference to a possibly refined type, and the <a
+ href="#AbstractTypeUser">AbstractTypeUser</a> class is used to update more
+ complex datastructures.
+ </p>
+
+ </div>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="PATypeHolder">The PATypeHolder Class</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ PATypeHolder is a form of a "smart pointer" for Type objects. When VMCore
+ happily goes about nuking types that become isomorphic to existing types, it
+ automatically updates all PATypeHolder objects to point to the new type. In the
+ example above, this allows the code to maintain a pointer to the resultant
+ resolved recursive type, even though the Type*'s are potentially invalidated.
+ </p>
+
+ <p>
+ PATypeHolder is an extremely light-weight object that uses a lazy union-find
+ implementation to update pointers. For example the pointer from a Value to its
+ Type is maintained by PATypeHolder objects.
+ </p>
+
+ </div>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="AbstractTypeUser">The AbstractTypeUser Class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ Some data structures need more to perform more complex updates when types get
+ resolved. To support this, a class can derive from the AbstractTypeUser class.
+ This class
+ allows it to get callbacks when certain types are resolved. To register to get
+ callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser
+ methods can be called on a type. Note that these methods only work for <i>
+ abstract</i> types. Concrete types (those that do not include any opaque
+ objects) can never be refined.
+ </p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="SymbolTable">The <tt>ValueSymbolTable</tt> and
+ <tt>TypeSymbolTable</tt> classes</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The <tt><a href="http://llvm.org/doxygen/classllvm_1_1ValueSymbolTable.html">
+ ValueSymbolTable</a></tt> class provides a symbol table that the <a
+ href="#Function"><tt>Function</tt></a> and <a href="#Module">
+ <tt>Module</tt></a> classes use for naming value definitions. The symbol table
+ can provide a name for any <a href="#Value"><tt>Value</tt></a>.
+ The <tt><a href="http://llvm.org/doxygen/classllvm_1_1TypeSymbolTable.html">
+ TypeSymbolTable</a></tt> class is used by the <tt>Module</tt> class to store
+ names for types.</p>
+
+ <p>Note that the <tt>SymbolTable</tt> class should not be directly accessed
+ by most clients. It should only be used when iteration over the symbol table
+ names themselves are required, which is very special purpose. Note that not
+ all LLVM
+ <tt><a href="#Value">Value</a></tt>s have names, and those without names (i.e. they have
+ an empty name) do not exist in the symbol table.
+ </p>
+
+ <p>These symbol tables support iteration over the values/types in the symbol
+ table with <tt>begin/end/iterator</tt> and supports querying to see if a
+ specific name is in the symbol table (with <tt>lookup</tt>). The
+ <tt>ValueSymbolTable</tt> class exposes no public mutator methods, instead,
+ simply call <tt>setName</tt> on a value, which will autoinsert it into the
+ appropriate symbol table. For types, use the Module::addTypeName method to
+ insert entries into the symbol table.</p>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="UserLayout">The <tt>User</tt> and owned <tt>Use</tt> classes' memory layout</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The <tt><a href="http://llvm.org/doxygen/classllvm_1_1User.html">
+ User</a></tt> class provides a basis for expressing the ownership of <tt>User</tt>
+ towards other <tt><a href="http://llvm.org/doxygen/classllvm_1_1Value.html">
+ Value</a></tt>s. The <tt><a href="http://llvm.org/doxygen/classllvm_1_1Use.html">
+ Use</a></tt> helper class is employed to do the bookkeeping and to facilitate <i>O(1)</i>
+ addition and removal.</p>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="Use2User">Interaction and relationship between <tt>User</tt> and <tt>Use</tt> objects</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ A subclass of <tt>User</tt> can choose between incorporating its <tt>Use</tt> objects
+ or refer to them out-of-line by means of a pointer. A mixed variant
+ (some <tt>Use</tt>s inline others hung off) is impractical and breaks the invariant
+ that the <tt>Use</tt> objects belonging to the same <tt>User</tt> form a contiguous array.
+ </p>
+ </div>
+
+ <p>
+ We have 2 different layouts in the <tt>User</tt> (sub)classes:
+ <ul>
+ <li><p>Layout a)
+ The <tt>Use</tt> object(s) are inside (resp. at fixed offset) of the <tt>User</tt>
+ object and there are a fixed number of them.</p>
+
+ <li><p>Layout b)
+ The <tt>Use</tt> object(s) are referenced by a pointer to an
+ array from the <tt>User</tt> object and there may be a variable
+ number of them.</p>
+ </ul>
+ <p>
+ As of v2.4 each layout still possesses a direct pointer to the
+ start of the array of <tt>Use</tt>s. Though not mandatory for layout a),
+ we stick to this redundancy for the sake of simplicity.
+ The <tt>User</tt> object also stores the number of <tt>Use</tt> objects it
+ has. (Theoretically this information can also be calculated
+ given the scheme presented below.)</p>
+ <p>
+ Special forms of allocation operators (<tt>operator new</tt>)
+ enforce the following memory layouts:</p>
+
+ <ul>
+ <li><p>Layout a) is modelled by prepending the <tt>User</tt> object by the <tt>Use[]</tt> array.</p>
+
+ <pre>
+ ...---.---.---.---.-------...
+ | P | P | P | P | User
+ '''---'---'---'---'-------'''
+ </pre>
+
+ <li><p>Layout b) is modelled by pointing at the <tt>Use[]</tt> array.</p>
+ <pre>
+ .-------...
+ | User
+ '-------'''
+ |
+ v
+ .---.---.---.---...
+ | P | P | P | P |
+ '---'---'---'---'''
+ </pre>
+ </ul>
+ <i>(In the above figures '<tt>P</tt>' stands for the <tt>Use**</tt> that
+ is stored in each <tt>Use</tt> object in the member <tt>Use::Prev</tt>)</i>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="Waymarking">The waymarking algorithm</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Since the <tt>Use</tt> objects are deprived of the direct (back)pointer to
+ their <tt>User</tt> objects, there must be a fast and exact method to
+ recover it. This is accomplished by the following scheme:</p>
+ </div>
+
+ A bit-encoding in the 2 LSBits (least significant bits) of the <tt>Use::Prev</tt> allows to find the
+ start of the <tt>User</tt> object:
+ <ul>
+ <li><tt>00</tt> —> binary digit 0</li>
+ <li><tt>01</tt> —> binary digit 1</li>
+ <li><tt>10</tt> —> stop and calculate (<tt>s</tt>)</li>
+ <li><tt>11</tt> —> full stop (<tt>S</tt>)</li>
+ </ul>
+ <p>
+ Given a <tt>Use*</tt>, all we have to do is to walk till we get
+ a stop and we either have a <tt>User</tt> immediately behind or
+ we have to walk to the next stop picking up digits
+ and calculating the offset:</p>
+ <pre>
+ .---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.---.----------------
+ | 1 | s | 1 | 0 | 1 | 0 | s | 1 | 1 | 0 | s | 1 | 1 | s | 1 | S | User (or User*)
+ '---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'---'----------------
+ |+15 |+10 |+6 |+3 |+1
+ | | | | |__>
+ | | | |__________>
+ | | |______________________>
+ | |______________________________________>
+ |__________________________________________________________>
+ </pre>
+ <p>
+ Only the significant number of bits need to be stored between the
+ stops, so that the <i>worst case is 20 memory accesses</i> when there are
+ 1000 <tt>Use</tt> objects associated with a <tt>User</tt>.</p>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="ReferenceImpl">Reference implementation</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The following literate Haskell fragment demonstrates the concept:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>
+ > import Test.QuickCheck
+ >
+ > digits :: Int -> [Char] -> [Char]
+ > digits 0 acc = '0' : acc
+ > digits 1 acc = '1' : acc
+ > digits n acc = digits (n `div` 2) $ digits (n `mod` 2) acc
+ >
+ > dist :: Int -> [Char] -> [Char]
+ > dist 0 [] = ['S']
+ > dist 0 acc = acc
+ > dist 1 acc = let r = dist 0 acc in 's' : digits (length r) r
+ > dist n acc = dist (n - 1) $ dist 1 acc
+ >
+ > takeLast n ss = reverse $ take n $ reverse ss
+ >
+ > test = takeLast 40 $ dist 20 []
+ >
+ </pre>
+ </div>
+ <p>
+ Printing <test> gives: <tt>"1s100000s11010s10100s1111s1010s110s11s1S"</tt></p>
+ <p>
+ The reverse algorithm computes the length of the string just by examining
+ a certain prefix:</p>
+
+ <div class="doc_code">
+ <pre>
+ > pref :: [Char] -> Int
+ > pref "S" = 1
+ > pref ('s':'1':rest) = decode 2 1 rest
+ > pref (_:rest) = 1 + pref rest
+ >
+ > decode walk acc ('0':rest) = decode (walk + 1) (acc * 2) rest
+ > decode walk acc ('1':rest) = decode (walk + 1) (acc * 2 + 1) rest
+ > decode walk acc _ = walk + acc
+ >
+ </pre>
+ </div>
+ <p>
+ Now, as expected, printing <pref test> gives <tt>40</tt>.</p>
+ <p>
+ We can <i>quickCheck</i> this with following property:</p>
+
+ <div class="doc_code">
+ <pre>
+ > testcase = dist 2000 []
+ > testcaseLength = length testcase
+ >
+ > identityProp n = n > 0 && n <= testcaseLength ==> length arr == pref arr
+ > where arr = takeLast n testcase
+ >
+ </pre>
+ </div>
+ <p>
+ As expected <quickCheck identityProp> gives:</p>
+
+ <pre>
+ *Main> quickCheck identityProp
+ OK, passed 100 tests.
+ </pre>
+ <p>
+ Let's be a bit more exhaustive:</p>
+
+ <div class="doc_code">
+ <pre>
+ >
+ > deepCheck p = check (defaultConfig { configMaxTest = 500 }) p
+ >
+ </pre>
+ </div>
+ <p>
+ And here is the result of <deepCheck identityProp>:</p>
+
+ <pre>
+ *Main> deepCheck identityProp
+ OK, passed 500 tests.
+ </pre>
+
+ <!-- ______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="Tagging">Tagging considerations</a>
+ </div>
+
+ <p>
+ To maintain the invariant that the 2 LSBits of each <tt>Use**</tt> in <tt>Use</tt>
+ never change after being set up, setters of <tt>Use::Prev</tt> must re-tag the
+ new <tt>Use**</tt> on every modification. Accordingly getters must strip the
+ tag bits.</p>
+ <p>
+ For layout b) instead of the <tt>User</tt> we find a pointer (<tt>User*</tt> with LSBit set).
+ Following this pointer brings us to the <tt>User</tt>. A portable trick ensures
+ that the first bytes of <tt>User</tt> (if interpreted as a pointer) never has
+ the LSBit set. (Portability is relying on the fact that all known compilers place the
+ <tt>vptr</tt> in the first word of the instances.)</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="coreclasses">The Core LLVM Class Hierarchy Reference </a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p><tt>#include "<a href="/doxygen/Type_8h-source.html">llvm/Type.h</a>"</tt>
+ <br>doxygen info: <a href="/doxygen/classllvm_1_1Type.html">Type Class</a></p>
+
+ <p>The Core LLVM classes are the primary means of representing the program
+ being inspected or transformed. The core LLVM classes are defined in
+ header files in the <tt>include/llvm/</tt> directory, and implemented in
+ the <tt>lib/VMCore</tt> directory.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Type">The <tt>Type</tt> class and Derived Types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>Type</tt> is a superclass of all type classes. Every <tt>Value</tt> has
+ a <tt>Type</tt>. <tt>Type</tt> cannot be instantiated directly but only
+ through its subclasses. Certain primitive types (<tt>VoidType</tt>,
+ <tt>LabelType</tt>, <tt>FloatType</tt> and <tt>DoubleType</tt>) have hidden
+ subclasses. They are hidden because they offer no useful functionality beyond
+ what the <tt>Type</tt> class offers except to distinguish themselves from
+ other subclasses of <tt>Type</tt>.</p>
+ <p>All other types are subclasses of <tt>DerivedType</tt>. Types can be
+ named, but this is not a requirement. There exists exactly
+ one instance of a given shape at any one time. This allows type equality to
+ be performed with address equality of the Type Instance. That is, given two
+ <tt>Type*</tt> values, the types are identical if the pointers are identical.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_Type">Important Public Methods</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt>bool isInteger() const</tt>: Returns true for any integer type.</li>
+
+ <li><tt>bool isFloatingPoint()</tt>: Return true if this is one of the two
+ floating point types.</li>
+
+ <li><tt>bool isAbstract()</tt>: Return true if the type is abstract (contains
+ an OpaqueType anywhere in its definition).</li>
+
+ <li><tt>bool isSized()</tt>: Return true if the type has known size. Things
+ that don't have a size are abstract types, labels and void.</li>
+
+ </ul>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="derivedtypes">Important Derived Types</a>
+ </div>
+ <div class="doc_text">
+ <dl>
+ <dt><tt>IntegerType</tt></dt>
+ <dd>Subclass of DerivedType that represents integer types of any bit width.
+ Any bit width between <tt>IntegerType::MIN_INT_BITS</tt> (1) and
+ <tt>IntegerType::MAX_INT_BITS</tt> (~8 million) can be represented.
+ <ul>
+ <li><tt>static const IntegerType* get(unsigned NumBits)</tt>: get an integer
+ type of a specific bit width.</li>
+ <li><tt>unsigned getBitWidth() const</tt>: Get the bit width of an integer
+ type.</li>
+ </ul>
+ </dd>
+ <dt><tt>SequentialType</tt></dt>
+ <dd>This is subclassed by ArrayType and PointerType
+ <ul>
+ <li><tt>const Type * getElementType() const</tt>: Returns the type of each
+ of the elements in the sequential type. </li>
+ </ul>
+ </dd>
+ <dt><tt>ArrayType</tt></dt>
+ <dd>This is a subclass of SequentialType and defines the interface for array
+ types.
+ <ul>
+ <li><tt>unsigned getNumElements() const</tt>: Returns the number of
+ elements in the array. </li>
+ </ul>
+ </dd>
+ <dt><tt>PointerType</tt></dt>
+ <dd>Subclass of SequentialType for pointer types.</dd>
+ <dt><tt>VectorType</tt></dt>
+ <dd>Subclass of SequentialType for vector types. A
+ vector type is similar to an ArrayType but is distinguished because it is
+ a first class type wherease ArrayType is not. Vector types are used for
+ vector operations and are usually small vectors of of an integer or floating
+ point type.</dd>
+ <dt><tt>StructType</tt></dt>
+ <dd>Subclass of DerivedTypes for struct types.</dd>
+ <dt><tt><a name="FunctionType">FunctionType</a></tt></dt>
+ <dd>Subclass of DerivedTypes for function types.
+ <ul>
+ <li><tt>bool isVarArg() const</tt>: Returns true if its a vararg
+ function</li>
+ <li><tt> const Type * getReturnType() const</tt>: Returns the
+ return type of the function.</li>
+ <li><tt>const Type * getParamType (unsigned i)</tt>: Returns
+ the type of the ith parameter.</li>
+ <li><tt> const unsigned getNumParams() const</tt>: Returns the
+ number of formal parameters.</li>
+ </ul>
+ </dd>
+ <dt><tt>OpaqueType</tt></dt>
+ <dd>Sublcass of DerivedType for abstract types. This class
+ defines no content and is used as a placeholder for some other type. Note
+ that OpaqueType is used (temporarily) during type resolution for forward
+ references of types. Once the referenced type is resolved, the OpaqueType
+ is replaced with the actual type. OpaqueType can also be used for data
+ abstraction. At link time opaque types can be resolved to actual types
+ of the same name.</dd>
+ </dl>
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Module">The <tt>Module</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "<a
+ href="/doxygen/Module_8h-source.html">llvm/Module.h</a>"</tt><br> doxygen info:
+ <a href="/doxygen/classllvm_1_1Module.html">Module Class</a></p>
+
+ <p>The <tt>Module</tt> class represents the top level structure present in LLVM
+ programs. An LLVM module is effectively either a translation unit of the
+ original program or a combination of several translation units merged by the
+ linker. The <tt>Module</tt> class keeps track of a list of <a
+ href="#Function"><tt>Function</tt></a>s, a list of <a
+ href="#GlobalVariable"><tt>GlobalVariable</tt></a>s, and a <a
+ href="#SymbolTable"><tt>SymbolTable</tt></a>. Additionally, it contains a few
+ helpful member functions that try to make common operations easy.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_Module">Important Public Members of the <tt>Module</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt>Module::Module(std::string name = "")</tt></li>
+ </ul>
+
+ <p>Constructing a <a href="#Module">Module</a> is easy. You can optionally
+ provide a name for it (probably based on the name of the translation unit).</p>
+
+ <ul>
+ <li><tt>Module::iterator</tt> - Typedef for function list iterator<br>
+ <tt>Module::const_iterator</tt> - Typedef for const_iterator.<br>
+
+ <tt>begin()</tt>, <tt>end()</tt>
+ <tt>size()</tt>, <tt>empty()</tt>
+
+ <p>These are forwarding methods that make it easy to access the contents of
+ a <tt>Module</tt> object's <a href="#Function"><tt>Function</tt></a>
+ list.</p></li>
+
+ <li><tt>Module::FunctionListType &getFunctionList()</tt>
+
+ <p> Returns the list of <a href="#Function"><tt>Function</tt></a>s. This is
+ necessary to use when you need to update the list or perform a complex
+ action that doesn't have a forwarding method.</p>
+
+ <p><!-- Global Variable --></p></li>
+ </ul>
+
+ <hr>
+
+ <ul>
+ <li><tt>Module::global_iterator</tt> - Typedef for global variable list iterator<br>
+
+ <tt>Module::const_global_iterator</tt> - Typedef for const_iterator.<br>
+
+ <tt>global_begin()</tt>, <tt>global_end()</tt>
+ <tt>global_size()</tt>, <tt>global_empty()</tt>
+
+ <p> These are forwarding methods that make it easy to access the contents of
+ a <tt>Module</tt> object's <a
+ href="#GlobalVariable"><tt>GlobalVariable</tt></a> list.</p></li>
+
+ <li><tt>Module::GlobalListType &getGlobalList()</tt>
+
+ <p>Returns the list of <a
+ href="#GlobalVariable"><tt>GlobalVariable</tt></a>s. This is necessary to
+ use when you need to update the list or perform a complex action that
+ doesn't have a forwarding method.</p>
+
+ <p><!-- Symbol table stuff --> </p></li>
+ </ul>
+
+ <hr>
+
+ <ul>
+ <li><tt><a href="#SymbolTable">SymbolTable</a> *getSymbolTable()</tt>
+
+ <p>Return a reference to the <a href="#SymbolTable"><tt>SymbolTable</tt></a>
+ for this <tt>Module</tt>.</p>
+
+ <p><!-- Convenience methods --></p></li>
+ </ul>
+
+ <hr>
+
+ <ul>
+ <li><tt><a href="#Function">Function</a> *getFunction(const std::string
+ &Name, const <a href="#FunctionType">FunctionType</a> *Ty)</tt>
+
+ <p>Look up the specified function in the <tt>Module</tt> <a
+ href="#SymbolTable"><tt>SymbolTable</tt></a>. If it does not exist, return
+ <tt>null</tt>.</p></li>
+
+ <li><tt><a href="#Function">Function</a> *getOrInsertFunction(const
+ std::string &Name, const <a href="#FunctionType">FunctionType</a> *T)</tt>
+
+ <p>Look up the specified function in the <tt>Module</tt> <a
+ href="#SymbolTable"><tt>SymbolTable</tt></a>. If it does not exist, add an
+ external declaration for the function and return it.</p></li>
+
+ <li><tt>std::string getTypeName(const <a href="#Type">Type</a> *Ty)</tt>
+
+ <p>If there is at least one entry in the <a
+ href="#SymbolTable"><tt>SymbolTable</tt></a> for the specified <a
+ href="#Type"><tt>Type</tt></a>, return it. Otherwise return the empty
+ string.</p></li>
+
+ <li><tt>bool addTypeName(const std::string &Name, const <a
+ href="#Type">Type</a> *Ty)</tt>
+
+ <p>Insert an entry in the <a href="#SymbolTable"><tt>SymbolTable</tt></a>
+ mapping <tt>Name</tt> to <tt>Ty</tt>. If there is already an entry for this
+ name, true is returned and the <a
+ href="#SymbolTable"><tt>SymbolTable</tt></a> is not modified.</p></li>
+ </ul>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Value">The <tt>Value</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "<a href="/doxygen/Value_8h-source.html">llvm/Value.h</a>"</tt>
+ <br>
+ doxygen info: <a href="/doxygen/classllvm_1_1Value.html">Value Class</a></p>
+
+ <p>The <tt>Value</tt> class is the most important class in the LLVM Source
+ base. It represents a typed value that may be used (among other things) as an
+ operand to an instruction. There are many different types of <tt>Value</tt>s,
+ such as <a href="#Constant"><tt>Constant</tt></a>s,<a
+ href="#Argument"><tt>Argument</tt></a>s. Even <a
+ href="#Instruction"><tt>Instruction</tt></a>s and <a
+ href="#Function"><tt>Function</tt></a>s are <tt>Value</tt>s.</p>
+
+ <p>A particular <tt>Value</tt> may be used many times in the LLVM representation
+ for a program. For example, an incoming argument to a function (represented
+ with an instance of the <a href="#Argument">Argument</a> class) is "used" by
+ every instruction in the function that references the argument. To keep track
+ of this relationship, the <tt>Value</tt> class keeps a list of all of the <a
+ href="#User"><tt>User</tt></a>s that is using it (the <a
+ href="#User"><tt>User</tt></a> class is a base class for all nodes in the LLVM
+ graph that can refer to <tt>Value</tt>s). This use list is how LLVM represents
+ def-use information in the program, and is accessible through the <tt>use_</tt>*
+ methods, shown below.</p>
+
+ <p>Because LLVM is a typed representation, every LLVM <tt>Value</tt> is typed,
+ and this <a href="#Type">Type</a> is available through the <tt>getType()</tt>
+ method. In addition, all LLVM values can be named. The "name" of the
+ <tt>Value</tt> is a symbolic string printed in the LLVM code:</p>
+
+ <div class="doc_code">
+ <pre>
+ %<b>foo</b> = add i32 1, 2
+ </pre>
+ </div>
+
+ <p><a name="nameWarning">The name of this instruction is "foo".</a> <b>NOTE</b>
+ that the name of any value may be missing (an empty string), so names should
+ <b>ONLY</b> be used for debugging (making the source code easier to read,
+ debugging printouts), they should not be used to keep track of values or map
+ between them. For this purpose, use a <tt>std::map</tt> of pointers to the
+ <tt>Value</tt> itself instead.</p>
+
+ <p>One important aspect of LLVM is that there is no distinction between an SSA
+ variable and the operation that produces it. Because of this, any reference to
+ the value produced by an instruction (or the value available as an incoming
+ argument, for example) is represented as a direct pointer to the instance of
+ the class that
+ represents this value. Although this may take some getting used to, it
+ simplifies the representation and makes it easier to manipulate.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_Value">Important Public Members of the <tt>Value</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt>Value::use_iterator</tt> - Typedef for iterator over the
+ use-list<br>
+ <tt>Value::use_const_iterator</tt> - Typedef for const_iterator over
+ the use-list<br>
+ <tt>unsigned use_size()</tt> - Returns the number of users of the
+ value.<br>
+ <tt>bool use_empty()</tt> - Returns true if there are no users.<br>
+ <tt>use_iterator use_begin()</tt> - Get an iterator to the start of
+ the use-list.<br>
+ <tt>use_iterator use_end()</tt> - Get an iterator to the end of the
+ use-list.<br>
+ <tt><a href="#User">User</a> *use_back()</tt> - Returns the last
+ element in the list.
+ <p> These methods are the interface to access the def-use
+ information in LLVM. As with all other iterators in LLVM, the naming
+ conventions follow the conventions defined by the <a href="#stl">STL</a>.</p>
+ </li>
+ <li><tt><a href="#Type">Type</a> *getType() const</tt>
+ <p>This method returns the Type of the Value.</p>
+ </li>
+ <li><tt>bool hasName() const</tt><br>
+ <tt>std::string getName() const</tt><br>
+ <tt>void setName(const std::string &Name)</tt>
+ <p> This family of methods is used to access and assign a name to a <tt>Value</tt>,
+ be aware of the <a href="#nameWarning">precaution above</a>.</p>
+ </li>
+ <li><tt>void replaceAllUsesWith(Value *V)</tt>
+
+ <p>This method traverses the use list of a <tt>Value</tt> changing all <a
+ href="#User"><tt>User</tt>s</a> of the current value to refer to
+ "<tt>V</tt>" instead. For example, if you detect that an instruction always
+ produces a constant value (for example through constant folding), you can
+ replace all uses of the instruction with the constant like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ Inst->replaceAllUsesWith(ConstVal);
+ </pre>
+ </div>
+
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="User">The <tt>User</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ <tt>#include "<a href="/doxygen/User_8h-source.html">llvm/User.h</a>"</tt><br>
+ doxygen info: <a href="/doxygen/classllvm_1_1User.html">User Class</a><br>
+ Superclass: <a href="#Value"><tt>Value</tt></a></p>
+
+ <p>The <tt>User</tt> class is the common base class of all LLVM nodes that may
+ refer to <a href="#Value"><tt>Value</tt></a>s. It exposes a list of "Operands"
+ that are all of the <a href="#Value"><tt>Value</tt></a>s that the User is
+ referring to. The <tt>User</tt> class itself is a subclass of
+ <tt>Value</tt>.</p>
+
+ <p>The operands of a <tt>User</tt> point directly to the LLVM <a
+ href="#Value"><tt>Value</tt></a> that it refers to. Because LLVM uses Static
+ Single Assignment (SSA) form, there can only be one definition referred to,
+ allowing this direct connection. This connection provides the use-def
+ information in LLVM.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_User">Important Public Members of the <tt>User</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>User</tt> class exposes the operand list in two ways: through
+ an index access interface and through an iterator based interface.</p>
+
+ <ul>
+ <li><tt>Value *getOperand(unsigned i)</tt><br>
+ <tt>unsigned getNumOperands()</tt>
+ <p> These two methods expose the operands of the <tt>User</tt> in a
+ convenient form for direct access.</p></li>
+
+ <li><tt>User::op_iterator</tt> - Typedef for iterator over the operand
+ list<br>
+ <tt>op_iterator op_begin()</tt> - Get an iterator to the start of
+ the operand list.<br>
+ <tt>op_iterator op_end()</tt> - Get an iterator to the end of the
+ operand list.
+ <p> Together, these methods make up the iterator based interface to
+ the operands of a <tt>User</tt>.</p></li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Instruction">The <tt>Instruction</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "</tt><tt><a
+ href="/doxygen/Instruction_8h-source.html">llvm/Instruction.h</a>"</tt><br>
+ doxygen info: <a href="/doxygen/classllvm_1_1Instruction.html">Instruction Class</a><br>
+ Superclasses: <a href="#User"><tt>User</tt></a>, <a
+ href="#Value"><tt>Value</tt></a></p>
+
+ <p>The <tt>Instruction</tt> class is the common base class for all LLVM
+ instructions. It provides only a few methods, but is a very commonly used
+ class. The primary data tracked by the <tt>Instruction</tt> class itself is the
+ opcode (instruction type) and the parent <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a> the <tt>Instruction</tt> is embedded
+ into. To represent a specific type of instruction, one of many subclasses of
+ <tt>Instruction</tt> are used.</p>
+
+ <p> Because the <tt>Instruction</tt> class subclasses the <a
+ href="#User"><tt>User</tt></a> class, its operands can be accessed in the same
+ way as for other <a href="#User"><tt>User</tt></a>s (with the
+ <tt>getOperand()</tt>/<tt>getNumOperands()</tt> and
+ <tt>op_begin()</tt>/<tt>op_end()</tt> methods).</p> <p> An important file for
+ the <tt>Instruction</tt> class is the <tt>llvm/Instruction.def</tt> file. This
+ file contains some meta-data about the various different types of instructions
+ in LLVM. It describes the enum values that are used as opcodes (for example
+ <tt>Instruction::Add</tt> and <tt>Instruction::ICmp</tt>), as well as the
+ concrete sub-classes of <tt>Instruction</tt> that implement the instruction (for
+ example <tt><a href="#BinaryOperator">BinaryOperator</a></tt> and <tt><a
+ href="#CmpInst">CmpInst</a></tt>). Unfortunately, the use of macros in
+ this file confuses doxygen, so these enum values don't show up correctly in the
+ <a href="/doxygen/classllvm_1_1Instruction.html">doxygen output</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="s_Instruction">Important Subclasses of the <tt>Instruction</tt>
+ class</a>
+ </div>
+ <div class="doc_text">
+ <ul>
+ <li><tt><a name="BinaryOperator">BinaryOperator</a></tt>
+ <p>This subclasses represents all two operand instructions whose operands
+ must be the same type, except for the comparison instructions.</p></li>
+ <li><tt><a name="CastInst">CastInst</a></tt>
+ <p>This subclass is the parent of the 12 casting instructions. It provides
+ common operations on cast instructions.</p>
+ <li><tt><a name="CmpInst">CmpInst</a></tt>
+ <p>This subclass respresents the two comparison instructions,
+ <a href="LangRef.html#i_icmp">ICmpInst</a> (integer opreands), and
+ <a href="LangRef.html#i_fcmp">FCmpInst</a> (floating point operands).</p>
+ <li><tt><a name="TerminatorInst">TerminatorInst</a></tt>
+ <p>This subclass is the parent of all terminator instructions (those which
+ can terminate a block).</p>
+ </ul>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_Instruction">Important Public Members of the <tt>Instruction</tt>
+ class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt><a href="#BasicBlock">BasicBlock</a> *getParent()</tt>
+ <p>Returns the <a href="#BasicBlock"><tt>BasicBlock</tt></a> that
+ this <tt>Instruction</tt> is embedded into.</p></li>
+ <li><tt>bool mayWriteToMemory()</tt>
+ <p>Returns true if the instruction writes to memory, i.e. it is a
+ <tt>call</tt>,<tt>free</tt>,<tt>invoke</tt>, or <tt>store</tt>.</p></li>
+ <li><tt>unsigned getOpcode()</tt>
+ <p>Returns the opcode for the <tt>Instruction</tt>.</p></li>
+ <li><tt><a href="#Instruction">Instruction</a> *clone() const</tt>
+ <p>Returns another instance of the specified instruction, identical
+ in all ways to the original except that the instruction has no parent
+ (ie it's not embedded into a <a href="#BasicBlock"><tt>BasicBlock</tt></a>),
+ and it has no name</p></li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Constant">The <tt>Constant</tt> class and subclasses</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Constant represents a base class for different types of constants. It
+ is subclassed by ConstantInt, ConstantArray, etc. for representing
+ the various types of Constants. <a href="#GlobalValue">GlobalValue</a> is also
+ a subclass, which represents the address of a global variable or function.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">Important Subclasses of Constant </div>
+ <div class="doc_text">
+ <ul>
+ <li>ConstantInt : This subclass of Constant represents an integer constant of
+ any width.
+ <ul>
+ <li><tt>const APInt& getValue() const</tt>: Returns the underlying
+ value of this constant, an APInt value.</li>
+ <li><tt>int64_t getSExtValue() const</tt>: Converts the underlying APInt
+ value to an int64_t via sign extension. If the value (not the bit width)
+ of the APInt is too large to fit in an int64_t, an assertion will result.
+ For this reason, use of this method is discouraged.</li>
+ <li><tt>uint64_t getZExtValue() const</tt>: Converts the underlying APInt
+ value to a uint64_t via zero extension. IF the value (not the bit width)
+ of the APInt is too large to fit in a uint64_t, an assertion will result.
+ For this reason, use of this method is discouraged.</li>
+ <li><tt>static ConstantInt* get(const APInt& Val)</tt>: Returns the
+ ConstantInt object that represents the value provided by <tt>Val</tt>.
+ The type is implied as the IntegerType that corresponds to the bit width
+ of <tt>Val</tt>.</li>
+ <li><tt>static ConstantInt* get(const Type *Ty, uint64_t Val)</tt>:
+ Returns the ConstantInt object that represents the value provided by
+ <tt>Val</tt> for integer type <tt>Ty</tt>.</li>
+ </ul>
+ </li>
+ <li>ConstantFP : This class represents a floating point constant.
+ <ul>
+ <li><tt>double getValue() const</tt>: Returns the underlying value of
+ this constant. </li>
+ </ul>
+ </li>
+ <li>ConstantArray : This represents a constant array.
+ <ul>
+ <li><tt>const std::vector<Use> &getValues() const</tt>: Returns
+ a vector of component constants that makeup this array. </li>
+ </ul>
+ </li>
+ <li>ConstantStruct : This represents a constant struct.
+ <ul>
+ <li><tt>const std::vector<Use> &getValues() const</tt>: Returns
+ a vector of component constants that makeup this array. </li>
+ </ul>
+ </li>
+ <li>GlobalValue : This represents either a global variable or a function. In
+ either case, the value is a constant fixed address (after linking).
+ </li>
+ </ul>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="GlobalValue">The <tt>GlobalValue</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "<a
+ href="/doxygen/GlobalValue_8h-source.html">llvm/GlobalValue.h</a>"</tt><br>
+ doxygen info: <a href="/doxygen/classllvm_1_1GlobalValue.html">GlobalValue
+ Class</a><br>
+ Superclasses: <a href="#Constant"><tt>Constant</tt></a>,
+ <a href="#User"><tt>User</tt></a>, <a href="#Value"><tt>Value</tt></a></p>
+
+ <p>Global values (<a href="#GlobalVariable"><tt>GlobalVariable</tt></a>s or <a
+ href="#Function"><tt>Function</tt></a>s) are the only LLVM values that are
+ visible in the bodies of all <a href="#Function"><tt>Function</tt></a>s.
+ Because they are visible at global scope, they are also subject to linking with
+ other globals defined in different translation units. To control the linking
+ process, <tt>GlobalValue</tt>s know their linkage rules. Specifically,
+ <tt>GlobalValue</tt>s know whether they have internal or external linkage, as
+ defined by the <tt>LinkageTypes</tt> enumeration.</p>
+
+ <p>If a <tt>GlobalValue</tt> has internal linkage (equivalent to being
+ <tt>static</tt> in C), it is not visible to code outside the current translation
+ unit, and does not participate in linking. If it has external linkage, it is
+ visible to external code, and does participate in linking. In addition to
+ linkage information, <tt>GlobalValue</tt>s keep track of which <a
+ href="#Module"><tt>Module</tt></a> they are currently part of.</p>
+
+ <p>Because <tt>GlobalValue</tt>s are memory objects, they are always referred to
+ by their <b>address</b>. As such, the <a href="#Type"><tt>Type</tt></a> of a
+ global is always a pointer to its contents. It is important to remember this
+ when using the <tt>GetElementPtrInst</tt> instruction because this pointer must
+ be dereferenced first. For example, if you have a <tt>GlobalVariable</tt> (a
+ subclass of <tt>GlobalValue)</tt> that is an array of 24 ints, type <tt>[24 x
+ i32]</tt>, then the <tt>GlobalVariable</tt> is a pointer to that array. Although
+ the address of the first element of this array and the value of the
+ <tt>GlobalVariable</tt> are the same, they have different types. The
+ <tt>GlobalVariable</tt>'s type is <tt>[24 x i32]</tt>. The first element's type
+ is <tt>i32.</tt> Because of this, accessing a global value requires you to
+ dereference the pointer with <tt>GetElementPtrInst</tt> first, then its elements
+ can be accessed. This is explained in the <a href="LangRef.html#globalvars">LLVM
+ Language Reference Manual</a>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_GlobalValue">Important Public Members of the <tt>GlobalValue</tt>
+ class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt>bool hasInternalLinkage() const</tt><br>
+ <tt>bool hasExternalLinkage() const</tt><br>
+ <tt>void setInternalLinkage(bool HasInternalLinkage)</tt>
+ <p> These methods manipulate the linkage characteristics of the <tt>GlobalValue</tt>.</p>
+ <p> </p>
+ </li>
+ <li><tt><a href="#Module">Module</a> *getParent()</tt>
+ <p> This returns the <a href="#Module"><tt>Module</tt></a> that the
+ GlobalValue is currently embedded into.</p></li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Function">The <tt>Function</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "<a
+ href="/doxygen/Function_8h-source.html">llvm/Function.h</a>"</tt><br> doxygen
+ info: <a href="/doxygen/classllvm_1_1Function.html">Function Class</a><br>
+ Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,
+ <a href="#Constant"><tt>Constant</tt></a>,
+ <a href="#User"><tt>User</tt></a>,
+ <a href="#Value"><tt>Value</tt></a></p>
+
+ <p>The <tt>Function</tt> class represents a single procedure in LLVM. It is
+ actually one of the more complex classes in the LLVM heirarchy because it must
+ keep track of a large amount of data. The <tt>Function</tt> class keeps track
+ of a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, a list of formal
+ <a href="#Argument"><tt>Argument</tt></a>s, and a
+ <a href="#SymbolTable"><tt>SymbolTable</tt></a>.</p>
+
+ <p>The list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s is the most
+ commonly used part of <tt>Function</tt> objects. The list imposes an implicit
+ ordering of the blocks in the function, which indicate how the code will be
+ layed out by the backend. Additionally, the first <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a> is the implicit entry node for the
+ <tt>Function</tt>. It is not legal in LLVM to explicitly branch to this initial
+ block. There are no implicit exit nodes, and in fact there may be multiple exit
+ nodes from a single <tt>Function</tt>. If the <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a> list is empty, this indicates that
+ the <tt>Function</tt> is actually a function declaration: the actual body of the
+ function hasn't been linked in yet.</p>
+
+ <p>In addition to a list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s, the
+ <tt>Function</tt> class also keeps track of the list of formal <a
+ href="#Argument"><tt>Argument</tt></a>s that the function receives. This
+ container manages the lifetime of the <a href="#Argument"><tt>Argument</tt></a>
+ nodes, just like the <a href="#BasicBlock"><tt>BasicBlock</tt></a> list does for
+ the <a href="#BasicBlock"><tt>BasicBlock</tt></a>s.</p>
+
+ <p>The <a href="#SymbolTable"><tt>SymbolTable</tt></a> is a very rarely used
+ LLVM feature that is only used when you have to look up a value by name. Aside
+ from that, the <a href="#SymbolTable"><tt>SymbolTable</tt></a> is used
+ internally to make sure that there are not conflicts between the names of <a
+ href="#Instruction"><tt>Instruction</tt></a>s, <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a>s, or <a
+ href="#Argument"><tt>Argument</tt></a>s in the function body.</p>
+
+ <p>Note that <tt>Function</tt> is a <a href="#GlobalValue">GlobalValue</a>
+ and therefore also a <a href="#Constant">Constant</a>. The value of the function
+ is its address (after linking) which is guaranteed to be constant.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_Function">Important Public Members of the <tt>Function</tt>
+ class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt>Function(const </tt><tt><a href="#FunctionType">FunctionType</a>
+ *Ty, LinkageTypes Linkage, const std::string &N = "", Module* Parent = 0)</tt>
+
+ <p>Constructor used when you need to create new <tt>Function</tt>s to add
+ the the program. The constructor must specify the type of the function to
+ create and what type of linkage the function should have. The <a
+ href="#FunctionType"><tt>FunctionType</tt></a> argument
+ specifies the formal arguments and return value for the function. The same
+ <a href="#FunctionType"><tt>FunctionType</tt></a> value can be used to
+ create multiple functions. The <tt>Parent</tt> argument specifies the Module
+ in which the function is defined. If this argument is provided, the function
+ will automatically be inserted into that module's list of
+ functions.</p></li>
+
+ <li><tt>bool isDeclaration()</tt>
+
+ <p>Return whether or not the <tt>Function</tt> has a body defined. If the
+ function is "external", it does not have a body, and thus must be resolved
+ by linking with a function defined in a different translation unit.</p></li>
+
+ <li><tt>Function::iterator</tt> - Typedef for basic block list iterator<br>
+ <tt>Function::const_iterator</tt> - Typedef for const_iterator.<br>
+
+ <tt>begin()</tt>, <tt>end()</tt>
+ <tt>size()</tt>, <tt>empty()</tt>
+
+ <p>These are forwarding methods that make it easy to access the contents of
+ a <tt>Function</tt> object's <a href="#BasicBlock"><tt>BasicBlock</tt></a>
+ list.</p></li>
+
+ <li><tt>Function::BasicBlockListType &getBasicBlockList()</tt>
+
+ <p>Returns the list of <a href="#BasicBlock"><tt>BasicBlock</tt></a>s. This
+ is necessary to use when you need to update the list or perform a complex
+ action that doesn't have a forwarding method.</p></li>
+
+ <li><tt>Function::arg_iterator</tt> - Typedef for the argument list
+ iterator<br>
+ <tt>Function::const_arg_iterator</tt> - Typedef for const_iterator.<br>
+
+ <tt>arg_begin()</tt>, <tt>arg_end()</tt>
+ <tt>arg_size()</tt>, <tt>arg_empty()</tt>
+
+ <p>These are forwarding methods that make it easy to access the contents of
+ a <tt>Function</tt> object's <a href="#Argument"><tt>Argument</tt></a>
+ list.</p></li>
+
+ <li><tt>Function::ArgumentListType &getArgumentList()</tt>
+
+ <p>Returns the list of <a href="#Argument"><tt>Argument</tt></a>s. This is
+ necessary to use when you need to update the list or perform a complex
+ action that doesn't have a forwarding method.</p></li>
+
+ <li><tt><a href="#BasicBlock">BasicBlock</a> &getEntryBlock()</tt>
+
+ <p>Returns the entry <a href="#BasicBlock"><tt>BasicBlock</tt></a> for the
+ function. Because the entry block for the function is always the first
+ block, this returns the first block of the <tt>Function</tt>.</p></li>
+
+ <li><tt><a href="#Type">Type</a> *getReturnType()</tt><br>
+ <tt><a href="#FunctionType">FunctionType</a> *getFunctionType()</tt>
+
+ <p>This traverses the <a href="#Type"><tt>Type</tt></a> of the
+ <tt>Function</tt> and returns the return type of the function, or the <a
+ href="#FunctionType"><tt>FunctionType</tt></a> of the actual
+ function.</p></li>
+
+ <li><tt><a href="#SymbolTable">SymbolTable</a> *getSymbolTable()</tt>
+
+ <p> Return a pointer to the <a href="#SymbolTable"><tt>SymbolTable</tt></a>
+ for this <tt>Function</tt>.</p></li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="GlobalVariable">The <tt>GlobalVariable</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "<a
+ href="/doxygen/GlobalVariable_8h-source.html">llvm/GlobalVariable.h</a>"</tt>
+ <br>
+ doxygen info: <a href="/doxygen/classllvm_1_1GlobalVariable.html">GlobalVariable
+ Class</a><br>
+ Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>,
+ <a href="#Constant"><tt>Constant</tt></a>,
+ <a href="#User"><tt>User</tt></a>,
+ <a href="#Value"><tt>Value</tt></a></p>
+
+ <p>Global variables are represented with the (suprise suprise)
+ <tt>GlobalVariable</tt> class. Like functions, <tt>GlobalVariable</tt>s are also
+ subclasses of <a href="#GlobalValue"><tt>GlobalValue</tt></a>, and as such are
+ always referenced by their address (global values must live in memory, so their
+ "name" refers to their constant address). See
+ <a href="#GlobalValue"><tt>GlobalValue</tt></a> for more on this. Global
+ variables may have an initial value (which must be a
+ <a href="#Constant"><tt>Constant</tt></a>), and if they have an initializer,
+ they may be marked as "constant" themselves (indicating that their contents
+ never change at runtime).</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_GlobalVariable">Important Public Members of the
+ <tt>GlobalVariable</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><tt>GlobalVariable(const </tt><tt><a href="#Type">Type</a> *Ty, bool
+ isConstant, LinkageTypes& Linkage, <a href="#Constant">Constant</a>
+ *Initializer = 0, const std::string &Name = "", Module* Parent = 0)</tt>
+
+ <p>Create a new global variable of the specified type. If
+ <tt>isConstant</tt> is true then the global variable will be marked as
+ unchanging for the program. The Linkage parameter specifies the type of
+ linkage (internal, external, weak, linkonce, appending) for the variable. If
+ the linkage is InternalLinkage, WeakLinkage, or LinkOnceLinkage, then
+ the resultant global variable will have internal linkage. AppendingLinkage
+ concatenates together all instances (in different translation units) of the
+ variable into a single variable but is only applicable to arrays. See
+ the <a href="LangRef.html#modulestructure">LLVM Language Reference</a> for
+ further details on linkage types. Optionally an initializer, a name, and the
+ module to put the variable into may be specified for the global variable as
+ well.</p></li>
+
+ <li><tt>bool isConstant() const</tt>
+
+ <p>Returns true if this is a global variable that is known not to
+ be modified at runtime.</p></li>
+
+ <li><tt>bool hasInitializer()</tt>
+
+ <p>Returns true if this <tt>GlobalVariable</tt> has an intializer.</p></li>
+
+ <li><tt><a href="#Constant">Constant</a> *getInitializer()</tt>
+
+ <p>Returns the intial value for a <tt>GlobalVariable</tt>. It is not legal
+ to call this method if there is no initializer.</p></li>
+ </ul>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="BasicBlock">The <tt>BasicBlock</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>#include "<a
+ href="/doxygen/BasicBlock_8h-source.html">llvm/BasicBlock.h</a>"</tt><br>
+ doxygen info: <a href="/doxygen/structllvm_1_1BasicBlock.html">BasicBlock
+ Class</a><br>
+ Superclass: <a href="#Value"><tt>Value</tt></a></p>
+
+ <p>This class represents a single entry multiple exit section of the code,
+ commonly known as a basic block by the compiler community. The
+ <tt>BasicBlock</tt> class maintains a list of <a
+ href="#Instruction"><tt>Instruction</tt></a>s, which form the body of the block.
+ Matching the language definition, the last element of this list of instructions
+ is always a terminator instruction (a subclass of the <a
+ href="#TerminatorInst"><tt>TerminatorInst</tt></a> class).</p>
+
+ <p>In addition to tracking the list of instructions that make up the block, the
+ <tt>BasicBlock</tt> class also keeps track of the <a
+ href="#Function"><tt>Function</tt></a> that it is embedded into.</p>
+
+ <p>Note that <tt>BasicBlock</tt>s themselves are <a
+ href="#Value"><tt>Value</tt></a>s, because they are referenced by instructions
+ like branches and can go in the switch tables. <tt>BasicBlock</tt>s have type
+ <tt>label</tt>.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="m_BasicBlock">Important Public Members of the <tt>BasicBlock</tt>
+ class</a>
+ </div>
+
+ <div class="doc_text">
+ <ul>
+
+ <li><tt>BasicBlock(const std::string &Name = "", </tt><tt><a
+ href="#Function">Function</a> *Parent = 0)</tt>
+
+ <p>The <tt>BasicBlock</tt> constructor is used to create new basic blocks for
+ insertion into a function. The constructor optionally takes a name for the new
+ block, and a <a href="#Function"><tt>Function</tt></a> to insert it into. If
+ the <tt>Parent</tt> parameter is specified, the new <tt>BasicBlock</tt> is
+ automatically inserted at the end of the specified <a
+ href="#Function"><tt>Function</tt></a>, if not specified, the BasicBlock must be
+ manually inserted into the <a href="#Function"><tt>Function</tt></a>.</p></li>
+
+ <li><tt>BasicBlock::iterator</tt> - Typedef for instruction list iterator<br>
+ <tt>BasicBlock::const_iterator</tt> - Typedef for const_iterator.<br>
+ <tt>begin()</tt>, <tt>end()</tt>, <tt>front()</tt>, <tt>back()</tt>,
+ <tt>size()</tt>, <tt>empty()</tt>
+ STL-style functions for accessing the instruction list.
+
+ <p>These methods and typedefs are forwarding functions that have the same
+ semantics as the standard library methods of the same names. These methods
+ expose the underlying instruction list of a basic block in a way that is easy to
+ manipulate. To get the full complement of container operations (including
+ operations to update the list), you must use the <tt>getInstList()</tt>
+ method.</p></li>
+
+ <li><tt>BasicBlock::InstListType &getInstList()</tt>
+
+ <p>This method is used to get access to the underlying container that actually
+ holds the Instructions. This method must be used when there isn't a forwarding
+ function in the <tt>BasicBlock</tt> class for the operation that you would like
+ to perform. Because there are no forwarding functions for "updating"
+ operations, you need to use this if you want to update the contents of a
+ <tt>BasicBlock</tt>.</p></li>
+
+ <li><tt><a href="#Function">Function</a> *getParent()</tt>
+
+ <p> Returns a pointer to <a href="#Function"><tt>Function</tt></a> the block is
+ embedded into, or a null pointer if it is homeless.</p></li>
+
+ <li><tt><a href="#TerminatorInst">TerminatorInst</a> *getTerminator()</tt>
+
+ <p> Returns a pointer to the terminator instruction that appears at the end of
+ the <tt>BasicBlock</tt>. If there is no terminator instruction, or if the last
+ instruction in the block is not a terminator, then a null pointer is
+ returned.</p></li>
+
+ </ul>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="Argument">The <tt>Argument</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>This subclass of Value defines the interface for incoming formal
+ arguments to a function. A Function maintains a list of its formal
+ arguments. An argument has a pointer to the parent Function.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01 Strict"></a>
+
+ <a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a> and
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/Projects.html
diff -c /dev/null llvm-www/releases/2.5/docs/Projects.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/Projects.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,460 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Creating an LLVM Project</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">Creating an LLVM Project</div>
+
+ <ol>
+ <li><a href="#overview">Overview</a></li>
+ <li><a href="#create">Create a project from the Sample Project</a></li>
+ <li><a href="#source">Source tree layout</a></li>
+ <li><a href="#makefiles">Writing LLVM-style Makefiles</a>
+ <ol>
+ <li><a href="#reqVars">Required Variables</a></li>
+ <li><a href="#varsBuildDir">Variables for Building Subdirectories</a></li>
+ <li><a href="#varsBuildLib">Variables for Building Libraries</a></li>
+ <li><a href="#varsBuildProg">Variables for Building Programs</a></li>
+ <li><a href="#miscVars">Miscellaneous Variables</a></li>
+ </ol></li>
+ <li><a href="#objcode">Placement of object code</a></li>
+ <li><a href="#help">Further help</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by John Criswell</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="overview">Overview</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM build system is designed to facilitate the building of third party
+ projects that use LLVM header files, libraries, and tools. In order to use
+ these facilities, a Makefile from a project must do the following things:</p>
+
+ <ol>
+ <li>Set <tt>make</tt> variables. There are several variables that a Makefile
+ needs to set to use the LLVM build system:
+ <ul>
+ <li><tt>PROJECT_NAME</tt> - The name by which your project is known.</li>
+ <li><tt>LLVM_SRC_ROOT</tt> - The root of the LLVM source tree.</li>
+ <li><tt>LLVM_OBJ_ROOT</tt> - The root of the LLVM object tree.</li>
+ <li><tt>PROJ_SRC_ROOT</tt> - The root of the project's source tree.</li>
+ <li><tt>PROJ_OBJ_ROOT</tt> - The root of the project's object tree.</li>
+ <li><tt>PROJ_INSTALL_ROOT</tt> - The root installation directory.</li>
+ <li><tt>LEVEL</tt> - The relative path from the current directory to the
+ project's root ($PROJ_OBJ_ROOT).</li>
+ </ul></li>
+ <li>Include <tt>Makefile.config</tt> from <tt>$(LLVM_OBJ_ROOT)</tt>.</li>
+ <li>Include <tt>Makefile.rules</tt> from <tt>$(LLVM_SRC_ROOT)</tt>.</li>
+ </ol>
+
+ <p>There are two ways that you can set all of these variables:</p>
+ <ol>
+ <li>You can write your own Makefiles which hard-code these values.</li>
+ <li>You can use the pre-made LLVM sample project. This sample project
+ includes Makefiles, a configure script that can be used to configure the
+ location of LLVM, and the ability to support multiple object directories
+ from a single source directory.</li>
+ </ol>
+
+ <p>This document assumes that you will base your project on the LLVM sample
+ project found in <tt>llvm/projects/sample</tt>. If you want to devise your own
+ build system, studying the sample project and LLVM Makefiles will probably
+ provide enough information on how to write your own Makefiles.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="create">Create a Project from the Sample Project</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Follow these simple steps to start your project:</p>
+
+ <ol>
+ <li>Copy the <tt>llvm/projects/sample</tt> directory to any place of your
+ choosing. You can place it anywhere you like. Rename the directory to match
+ the name of your project.</li>
+
+ <li>
+ If you downloaded LLVM using Subversion, remove all the directories named .svn
+ (and all the files therein) from your project's new source tree. This will
+ keep Subversion from thinking that your project is inside
+ <tt>llvm/trunk/projects/sample</tt>.</li>
+
+ <li>Add your source code and Makefiles to your source tree.</li>
+
+ <li>If you want your project to be configured with the <tt>configure</tt> script
+ then you need to edit <tt>autoconf/configure.ac</tt> as follows:
+ <ul>
+ <li><b>AC_INIT</b>. Place the name of your project, its version number and
+ a contact email address for your project as the arguments to this macro</li>
+ <li><b>AC_CONFIG_AUX_DIR</b>. If your project isn't in the
+ <tt>llvm/projects</tt> directory then you might need to adjust this so that
+ it specifies a relative path to the <tt>llvm/autoconf</tt> directory.</li>
+ <li><b>LLVM_CONFIG_PROJECT</b>. Just leave this alone.</li>
+ <li><b>AC_CONFIG_SRCDIR</b>. Specify a path to a file name that identifies
+ your project; or just leave it at <tt>Makefile.common.in</tt></li>
+ <li><b>AC_CONFIG_FILES</b>. Do not change.</li>
+ <li><b>AC_CONFIG_MAKEFILE</b>. Use one of these macros for each Makefile
+ that your project uses. This macro arranges for your makefiles to be copied
+ from the source directory, unmodified, to the build directory.</li>
+ </ul>
+ </li>
+
+ <li>After updating <tt>autoconf/configure.ac</tt>, regenerate the
+ configure script with these commands:
+
+ <div class="doc_code">
+ <p><tt>% cd autoconf<br>
+ % ./AutoRegen.sh</tt></p>
+ </div>
+
+ <p>You must be using Autoconf version 2.59 or later and your aclocal version
+ should 1.9 or later.</p></li>
+
+ <li>Run <tt>configure</tt> in the directory in which you want to place
+ object code. Use the following options to tell your project where it
+ can find LLVM:
+
+ <dl>
+ <dt><tt>--with-llvmsrc=<directory></tt></dt>
+ <dd>Tell your project where the LLVM source tree is located.</dd>
+ <dt><br><tt>--with-llvmobj=<directory></tt></dt>
+ <dd>Tell your project where the LLVM object tree is located.</dd>
+ <dt><br><tt>--prefix=<directory></tt></dt>
+ <dd>Tell your project where it should get installed.</dd>
+ </dl>
+ </ol>
+
+ <p>That's it! Now all you have to do is type <tt>gmake</tt> (or <tt>make</tt>
+ if your on a GNU/Linux system) in the root of your object directory, and your
+ project should build.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="source">Source Tree Layout</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>In order to use the LLVM build system, you will want to organize your
+ source code so that it can benefit from the build system's features.
+ Mainly, you want your source tree layout to look similar to the LLVM
+ source tree layout. The best way to do this is to just copy the
+ project tree from <tt>llvm/projects/sample</tt> and modify it to meet
+ your needs, but you can certainly add to it if you want.</p>
+
+ <p>Underneath your top level directory, you should have the following
+ directories:</p>
+
+ <dl>
+ <dt><b>lib</b>
+ <dd>
+ This subdirectory should contain all of your library source
+ code. For each library that you build, you will have one
+ directory in <b>lib</b> that will contain that library's source
+ code.
+
+ <p>
+ Libraries can be object files, archives, or dynamic libraries.
+ The <b>lib</b> directory is just a convenient place for libraries
+ as it places them all in a directory from which they can be linked
+ later.
+
+ <dt><b>include</b>
+ <dd>
+ This subdirectory should contain any header files that are
+ global to your project. By global, we mean that they are used
+ by more than one library or executable of your project.
+ <p>
+ By placing your header files in <b>include</b>, they will be
+ found automatically by the LLVM build system. For example, if
+ you have a file <b>include/jazz/note.h</b>, then your source
+ files can include it simply with <b>#include "jazz/note.h"</b>.
+
+ <dt><b>tools</b>
+ <dd>
+ This subdirectory should contain all of your source
+ code for executables. For each program that you build, you
+ will have one directory in <b>tools</b> that will contain that
+ program's source code.
+ <p>
+
+ <dt><b>test</b>
+ <dd>
+ This subdirectory should contain tests that verify that your code
+ works correctly. Automated tests are especially useful.
+ <p>
+ Currently, the LLVM build system provides basic support for tests.
+ The LLVM system provides the following:
+ <ul>
+ <li>
+ LLVM provides a tcl procedure that is used by Dejagnu to run
+ tests. It can be found in <tt>llvm/lib/llvm-dg.exp</tt>. This
+ test procedure uses RUN lines in the actual test case to determine
+ how to run the test. See the <a
+ href="TestingGuide.html">TestingGuide</a> for more details. You
+ can easily write Makefile support similar to the Makefiles in
+ <tt>llvm/test</tt> to use Dejagnu to run your project's tests.<br></li>
+ <li>
+ LLVM contains an optional package called <tt>llvm-test</tt>
+ which provides benchmarks and programs that are known to compile with the
+ LLVM GCC front ends. You can use these
+ programs to test your code, gather statistics information, and
+ compare it to the current LLVM performance statistics.
+ <br>Currently, there is no way to hook your tests directly into the
+ <tt>llvm/test</tt> testing harness. You will simply
+ need to find a way to use the source provided within that directory
+ on your own.
+ </ul>
+ </dl>
+
+ <p>Typically, you will want to build your <b>lib</b> directory first followed by
+ your <b>tools</b> directory.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="makefiles">Writing LLVM Style Makefiles</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM build system provides a convenient way to build libraries and
+ executables. Most of your project Makefiles will only need to define a few
+ variables. Below is a list of the variables one can set and what they can
+ do:</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="reqVars">Required Variables</a>
+ </div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt>LEVEL
+ <dd>
+ This variable is the relative path from this Makefile to the
+ top directory of your project's source code. For example, if
+ your source code is in <tt>/tmp/src</tt>, then the Makefile in
+ <tt>/tmp/src/jump/high</tt> would set <tt>LEVEL</tt> to <tt>"../.."</tt>.
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="varsBuildDir">Variables for Building Subdirectories</a>
+ </div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt>DIRS
+ <dd>
+ This is a space separated list of subdirectories that should be
+ built. They will be built, one at a time, in the order
+ specified.
+ <p>
+
+ <dt>PARALLEL_DIRS
+ <dd>
+ This is a list of directories that can be built in parallel.
+ These will be built after the directories in DIRS have been
+ built.
+ <p>
+
+ <dt>OPTIONAL_DIRS
+ <dd>
+ This is a list of directories that can be built if they exist,
+ but will not cause an error if they do not exist. They are
+ built serially in the order in which they are listed.
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="varsBuildLib">Variables for Building Libraries</a>
+ </div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt>LIBRARYNAME
+ <dd>
+ This variable contains the base name of the library that will
+ be built. For example, to build a library named
+ <tt>libsample.a</tt>, LIBRARYNAME should be set to
+ <tt>sample</tt>.
+ <p>
+
+ <dt>BUILD_ARCHIVE
+ <dd>
+ By default, a library is a <tt>.o</tt> file that is linked
+ directly into a program. To build an archive (also known as
+ a static library), set the BUILD_ARCHIVE variable.
+ <p>
+
+ <dt>SHARED_LIBRARY
+ <dd>
+ If SHARED_LIBRARY is defined in your Makefile, a shared
+ (or dynamic) library will be built.
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="varsBuildProg">Variables for Building Programs</a>
+ </div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt>TOOLNAME
+ <dd>
+ This variable contains the name of the program that will
+ be built. For example, to build an executable named
+ <tt>sample</tt>, TOOLNAME should be set to <tt>sample</tt>.
+ <p>
+
+ <dt>USEDLIBS
+ <dd>
+ This variable holds a space separated list of libraries that
+ should be linked into the program. These libraries must either
+ be LLVM libraries or libraries that come from your <b>lib</b>
+ directory. The libraries must be specified by their base name.
+ For example, to link libsample.a, you would set USEDLIBS to
+ <tt>sample</tt>.
+ <p>
+ Note that this works only for statically linked libraries.
+ <p>
+
+ <dt>LIBS
+ <dd>
+ To link dynamic libraries, add <tt>-l<library base name></tt> to
+ the LIBS variable. The LLVM build system will look in the same places
+ for dynamic libraries as it does for static libraries.
+ <p>
+ For example, to link <tt>libsample.so</tt>, you would have the
+ following line in your <tt>Makefile</tt>:
+ <p>
+ <tt>
+ LIBS += -lsample
+ </tt>
+ </dl>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="miscVars">Miscellaneous Variables</a>
+ </div>
+
+ <div class="doc_text">
+
+ <dl>
+ <dt>ExtraSource
+ <dd>
+ This variable contains a space separated list of extra source
+ files that need to be built. It is useful for including the
+ output of Lex and Yacc programs.
+ <p>
+
+ <dt>CFLAGS
+ <dt>CPPFLAGS
+ <dd>
+ This variable can be used to add options to the C and C++
+ compiler, respectively. It is typically used to add options
+ that tell the compiler the location of additional directories
+ to search for header files.
+ <p>
+ It is highly suggested that you append to CFLAGS and CPPFLAGS as
+ opposed to overwriting them. The master Makefiles may already
+ have useful options in them that you may not want to overwrite.
+ <p>
+ </dl>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="objcode">Placement of Object Code</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The final location of built libraries and executables will depend upon
+ whether you do a Debug, Release, or Profile build.</p>
+
+ <dl>
+ <dt>Libraries
+ <dd>
+ All libraries (static and dynamic) will be stored in
+ <tt>PROJ_OBJ_ROOT/<type>/lib</tt>, where type is <tt>Debug</tt>,
+ <tt>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or
+ profiled build, respectively.<p>
+
+ <dt>Executables
+ <dd>All executables will be stored in
+ <tt>PROJ_OBJ_ROOT/<type>/bin</tt>, where type is <tt>Debug</tt>,
+ <tt>Release</tt>, or <tt>Profile</tt> for a debug, optimized, or profiled
+ build, respectively.
+ </dl>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="help">Further Help</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>If you have any questions or need any help creating an LLVM project,
+ the LLVM team would be more than happy to help. You can always post your
+ questions to the <a
+ href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developers
+ Mailing List</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:criswell at uiuc.edu">John Criswell</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/ReleaseNotes.html
diff -c /dev/null llvm-www/releases/2.5/docs/ReleaseNotes.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/ReleaseNotes.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,964 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <title>LLVM 2.5 Release Notes</title>
+ </head>
+ <body>
+
+ <div class="doc_title">LLVM 2.5 Release Notes</div>
+
+ <ol>
+ <li><a href="#intro">Introduction</a></li>
+ <li><a href="#subproj">Sub-project Status Update</a></li>
+ <li><a href="#externalproj">External Projects Using LLVM 2.5</a></li>
+ <li><a href="#whatsnew">What's New in LLVM 2.5?</a></li>
+ <li><a href="GettingStarted.html">Installation Instructions</a></li>
+ <li><a href="#portability">Portability and Supported Platforms</a></li>
+ <li><a href="#knownproblems">Known Problems</a></li>
+ <li><a href="#additionalinfo">Additional Information</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by the <a href="http://llvm.org">LLVM Team</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="intro">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document contains the release notes for the LLVM Compiler
+ Infrastructure, release 2.5. Here we describe the status of LLVM, including
+ major improvements from the previous release and significant known problems.
+ All LLVM releases may be downloaded from the <a
+ href="http://llvm.org/releases/">LLVM releases web site</a>.</p>
+
+ <p>For more information about LLVM, including information about the latest
+ release, please check out the <a href="http://llvm.org/">main LLVM
+ web site</a>. If you have questions or comments, the <a
+ href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM Developer's Mailing
+ List</a> is a good place to send them.</p>
+
+ <p>Note that if you are reading this file from a Subversion checkout or the
+ main LLVM web page, this document applies to the <i>next</i> release, not the
+ current one. To see the release notes for a specific release, please see the
+ <a href="http://llvm.org/releases/">releases page</a>.</p>
+
+ </div>
+
+ <!-- Unfinished features in 2.5:
+ Machine LICM
+ Machine Sinking
+ target-specific intrinsics
+ gold lto plugin
+ pre-alloc splitter, strong phi elim
+ <tt>llc -enable-value-prop</tt>, propagation of value info
+ (sign/zero ext info) from one MBB to another
+ debug info for optimized code
+ interpreter + libffi
+ postalloc scheduler: anti dependence breaking, hazard recognizer?
+
+ initial support for debug line numbers when optimization enabled, not useful in
+ 2.5 but will be for 2.6.
+
+ -->
+
+ <!-- for announcement email:
+ -->
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="subproj">Sub-project Status Update</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ The LLVM 2.5 distribution currently consists of code from the core LLVM
+ repository —which roughly includes the LLVM optimizers, code generators
+ and supporting tools — and the llvm-gcc repository. In addition to this
+ code, the LLVM Project includes other sub-projects that are in development. The
+ two which are the most actively developed are the <a href="#clang">Clang
+ Project</a> and the <a href="#vmkit">VMKit Project</a>.
+ </p>
+
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="clang">Clang: C/C++/Objective-C Frontend Toolkit</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <a href="http://clang.llvm.org/">Clang project</a> is an effort to build
+ a set of new 'LLVM native' front-end technologies for the LLVM optimizer and
+ code generator. While Clang is not included in the LLVM 2.5 release, it is
+ continuing to make major strides forward in all areas. Its C and Objective-C
+ parsing and code generation support is now very solid. For example, it is
+ capable of successfully building many real-world applications for X86-32
+ and X86-64,
+ including the <a href="http://wiki.freebsd.org/BuildingFreeBSDWithClang">FreeBSD
+ kernel</a> and <a href="http://gcc.gnu.org/gcc-4.2/">gcc 4.2</a>. C++ is also
+ making <a href="http://clang.llvm.org/cxx_status.html">incredible progress</a>,
+ and work on templates has recently started. If you are
+ interested in fast compiles and good diagnostics, we encourage you to try it out
+ by <a href="http://clang.llvm.org/get_started.html">building from mainline</a>
+ and reporting any issues you hit to the <a
+ href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">Clang front-end mailing
+ list</a>.</p>
+
+ <p>In the LLVM 2.5 time-frame, the Clang team has made many improvements:</p>
+
+ <ul>
+ <li>Clang now has a new driver, which is focused on providing a GCC-compatible
+ interface.</li>
+ <li>The X86-64 ABI is now supported, including support for the Apple
+ 64-bit Objective-C runtime and zero cost exception handling.</li>
+ <li>Precompiled header support is now implemented.</li>
+ <li>Objective-C support is significantly improved beyond LLVM 2.4, supporting
+ many features, such as Objective-C Garbage Collection.</li>
+ <li>Variable length arrays are now fully supported.</li>
+ <li>C99 designated initializers are now fully supported.</li>
+ <li>Clang now includes all major compiler headers, including a
+ redesigned <i>tgmath.h</i> and several more intrinsic headers.</li>
+ <li>Many many bugs are fixed and many features have been added.</li>
+ </ul>
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="clangsa">Clang Static Analyzer</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Previously announced in the last LLVM release, the Clang project also
+ includes an early stage static source code analysis tool for <a
+ href="http://clang.llvm.org/StaticAnalysis.html">automatically finding bugs</a>
+ in C and Objective-C programs. The tool performs a growing set of checks to find
+ bugs that occur on a specific path within a program.</p>
+
+ <p>In the LLVM 2.5 time-frame there have been many significant improvements to
+ the analyzer's core path simulation engine and machinery for generating
+ path-based bug reports to end-users. Particularly noteworthy improvements
+ include experimental support for full field-sensitivity and reasoning about heap
+ objects as well as an improved value-constraints subengine that does a much
+ better job of reasoning about inequality relationships (e.g., <tt>x > 2</tt>)
+ between variables and constants.
+
+ <p>The set of checks performed by the static analyzer continues to expand, and
+ future plans for the tool include full source-level inter-procedural analysis
+ and deeper checks such as buffer overrun detection. There are many opportunities
+ to extend and enhance the static analyzer, and anyone interested in working on
+ this project is encouraged to get involved!</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="vmkit">VMKit: JVM/CLI Virtual Machine Implementation</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The <a href="http://vmkit.llvm.org/">VMKit project</a> is an implementation of
+ a JVM and a CLI Virtual Machines (Microsoft .NET is an
+ implementation of the CLI) using the Just-In-Time compiler of LLVM.</p>
+
+ <p>Following LLVM 2.5, VMKit has its second release that you can find on its
+ <a href="http://vmkit.llvm.org/releases/">webpage</a>. The release includes
+ bug fixes, cleanup and new features. The major changes are:</p>
+
+ <ul>
+
+ <li>Ahead of Time compiler: compiles .class files to llvm .bc. VMKit uses this
+ functionality to native compile the standard classes (e.g. java.lang.String).
+ Users can compile AoT .class files into dynamic libraries and run them with the
+ help of VMKit.</li>
+
+ <li>New exception model: the dwarf exception model is very slow for
+ exception-intensive applications, so the JVM has had a new implementation of
+ exceptions which check at each function call if an exception happened. There is
+ a low performance penalty on applications without exceptions, but it is a big
+ gain for exception-intensive applications. For example the jack benchmark in
+ Spec JVM98 is 6x faster (performance gain of 83%).</li>
+
+ <li>User-level management of thread stacks, so that thread local data access
+ at runtime is fast and portable. </li>
+
+ <li>Implementation of biased locking for faster object synchronizations at
+ runtime.</li>
+
+ <li>New support for OSX/X64, Linux/X64 (with the Boehm GC) and Linux/ppc32.</li>
+
+ </ul>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="externalproj">External Projects Using LLVM 2.5</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="pure">Pure</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ <a href="http://pure-lang.googlecode.com/">Pure</a>
+ is an algebraic/functional programming language based on term rewriting.
+ Programs are collections of equations which are used to evaluate expressions in
+ a symbolic fashion. Pure offers dynamic typing, eager and lazy evaluation,
+ lexical closures, a hygienic macro system (also based on term rewriting),
+ built-in list and matrix support (including list and matrix comprehensions) and
+ an easy-to-use C interface. The interpreter uses LLVM as a backend to
+ JIT-compile Pure programs to fast native code.</p>
+
+ <p>In addition to the usual algebraic data structures, Pure also has
+ MATLAB-style matrices in order to support numeric computations and signal
+ processing in an efficient way. Pure is mainly aimed at mathematical
+ applications right now, but it has been designed as a general purpose language.
+ The dynamic interpreter environment and the C interface make it possible to use
+ it as a kind of functional scripting language for many application areas.
+ </p>
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="ldc">LLVM D Compiler</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ <a href="http://www.dsource.org/projects/ldc">LDC</a> is an implementation of
+ the D Programming Language using the LLVM optimizer and code generator.
+ The LDC project works great with the LLVM 2.5 release. General improvements in
+ this
+ cycle have included new inline asm constraint handling, better debug info
+ support, general bugfixes, and better x86-64 support. This has allowed
+ some major improvements in LDC, getting us much closer to being as
+ fully featured as the original DMD compiler from DigitalMars.
+ </p>
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="RoadsendPHP">Roadsend PHP</a>
+ </div>
+
+ <div class="doc_text">
+ <p><a href="http://code.roadsend.com/rphp">Roadsend PHP</a> (rphp) is an open
+ source implementation of the PHP programming
+ language that uses LLVM for its optimizer, JIT, and static compiler. This is a
+ reimplementation of an earlier project that is now based on LLVM.</p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="whatsnew">What's New in LLVM 2.5?</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This release includes a huge number of bug fixes, performance tweaks, and
+ minor improvements. Some of the major improvements and new features are listed
+ in this section.
+ </p>
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="majorfeatures">Major New Features</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM 2.5 includes several major new capabilities:</p>
+
+ <ul>
+ <li>LLVM 2.5 includes a brand new <a
+ href="http://en.wikipedia.org/wiki/XCore">XCore</a> backend.</li>
+
+ <li>llvm-gcc now generally supports the GFortran front-end, and the precompiled
+ release binaries now support Fortran, even on Mac OS/X.</li>
+
+ <li>CMake is now used by the <a href="GettingStartedVS.html">LLVM build process
+ on Windows</a>. It automatically generates Visual Studio project files (and
+ more) from a set of simple text files. This makes it much easier to
+ maintain. In time, we'd like to standardize on CMake for everything.</li>
+
+ <li>LLVM 2.5 now uses (and includes) Google Test for unit testing.</li>
+
+ <li>The LLVM native code generator now supports arbitrary precision integers.
+ Types like <tt>i33</tt> have long been valid in the LLVM IR, but were previously
+ only supported by the interpreter. Note that the C backend still does not
+ support these.</li>
+
+ <li>LLVM 2.5 no longer uses 'bison,' so it is easier to build on Windows.</li>
+ </ul>
+
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="llvm-gcc">llvm-gcc 4.2 Improvements</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM fully supports the llvm-gcc 4.2 front-end, which marries the GCC
+ front-ends and driver with the LLVM optimizer and code generator. It currently
+ includes support for the C, C++, Objective-C, Ada, and Fortran front-ends.</p>
+
+ <ul>
+ <li>In this release, the GCC inliner is completely disabled. Previously the GCC
+ inliner was used to handle always-inline functions and other cases. This caused
+ problems with code size growth, and it is completely disabled in this
+ release.</li>
+
+ <li>llvm-gcc (and LLVM in general) now support code generation for stack
+ canaries, which is an effective form of <a
+ href="http://en.wikipedia.org/wiki/Stack-smashing_protection">buffer overflow
+ protection</a>. llvm-gcc supports this with the <tt>-fstack-protector</tt>
+ command line option (just like GCC). In LLVM IR, you can request code
+ generation for stack canaries with function attributes.
+ </li>
+ </ul>
+
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="coreimprovements">LLVM IR and Core Improvements</a>
+ </div>
+
+ <div class="doc_text">
+ <p>LLVM IR has several new features that are used by our existing front-ends and
+ can be useful if you are writing a front-end for LLVM:</p>
+
+ <ul>
+ <li>The <a href="LangRef.html#i_shufflevector">shufflevector</a> instruction
+ has been generalized to allow different shuffle mask width than its input
+ vectors. This allows you to use shufflevector to combine two
+ "<4 x float>" vectors into a "<8 x float>" for example.</li>
+
+ <li>LLVM IR now supports new intrinsics for computing and acting on <a
+ href="LangRef.html#int_overflow">overflow of integer operations</a>. This allows
+ efficient code generation for languages that must trap or throw an exception on
+ overflow. While these intrinsics work on all targets, they only generate
+ efficient code on X86 so far.</li>
+
+ <li>LLVM IR now supports a new <a href="LangRef.html#linkage">private
+ linkage</a> type to produce labels that are stripped by the assembler before it
+ produces a .o file (thus they are invisible to the linker).</li>
+
+ <li>LLVM IR supports two new attributes for better alias analysis. The <a
+ href="LangRef.html#paramattrs">noalias</a> attribute can now be used on the
+ return value of a function to indicate that it returns new memory (e.g.
+ 'malloc', 'calloc', etc).
+ The new <a href="LangRef.html#paramattrs">nocapture</a> attribute can be used
+ on pointer arguments to indicate that the function does not return the pointer,
+ store it in an object that outlives the call, or let the value of the pointer
+ escape from the function in any other way.
+ Note that it is the pointer itself that must not escape, not the value it
+ points to: loading a value out of the pointer is perfectly fine.
+ Many standard library functions (e.g. 'strlen', 'memcpy') have this property.
+ <!-- The simplifylibcalls pass applies these attributes to standard libc functions. -->
+ </li>
+
+ <li>The parser for ".ll" files in lib/AsmParser is now completely rewritten as a
+ recursive descent parser. This parser produces better error messages (including
+ caret diagnostics), is less fragile (less likely to crash on strange things),
+ does not leak memory, is more efficient, and eliminates LLVM's last use of the
+ 'bison' tool.</li>
+
+ <li>Debug information representation and manipulation internals have been
+ consolidated to use a new set of classes in
+ <tt>llvm/Analysis/DebugInfo.h</tt>. These routines are more
+ efficient, robust, and extensible and replace the older mechanisms.
+ llvm-gcc, clang, and the code generator now use them to create and process
+ debug information.</li>
+
+ </ul>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="optimizer">Optimizer Improvements</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In addition to a large array of bug fixes and minor performance tweaks, this
+ release includes a few major enhancements and additions to the optimizers:</p>
+
+ <ul>
+
+ <li>The loop optimizer now improves floating point induction variables in
+ several ways, including adding shadow induction variables to avoid
+ "integer <-> floating point" conversions in loops when safe.</li>
+
+ <li>The "-mem2reg" pass is now much faster on code with large basic blocks.</li>
+
+ <li>The "-jump-threading" pass is more powerful: it is iterative
+ and handles threading based on values with fully and partially redundant
+ loads.</li>
+
+ <li>The "-memdep" memory dependence analysis pass (used by GVN and memcpyopt) is
+ both faster and more aggressive.</li>
+
+ <li>The "-scalarrepl" scalar replacement of aggregates pass is more aggressive
+ about promoting unions to registers.</li>
+
+ </ul>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="codegen">Target Independent Code Generator Improvements</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>We have put a significant amount of work into the code generator
+ infrastructure, which allows us to implement more aggressive algorithms and make
+ it run faster:</p>
+
+ <ul>
+ <li>The <a href="WritingAnLLVMBackend.html">Writing an LLVM Compiler
+ Backend</a> document has been greatly expanded and is substantially more
+ complete.</li>
+
+ <li>The SelectionDAG type legalization logic has been completely rewritten, is
+ now more powerful (it supports arbitrary precision integer types for example),
+ and is more correct in several corner cases. The type legalizer converts
+ operations on types that are not natively supported by the target machine into
+ equivalent code sequences that only use natively supported types. The old type
+ legalizer is still available (for now) and will be used if
+ <tt>-disable-legalize-types</tt> is passed to the code generator.
+ </li>
+
+ <li>The code generator now supports widening illegal vectors to larger legal
+ ones (for example, converting operations on <3 x float> to work on
+ <4 x float>) which is very important for common graphics
+ applications.</li>
+
+ <li>The assembly printers for each target are now split out into their own
+ libraries that are separate from the main code generation logic. This reduces
+ the code size of JIT compilers by not requiring them to be linked in.</li>
+
+ <li>The 'fast' instruction selection path (used at -O0 and for fast JIT
+ compilers) now supports accelerating codegen for code that uses exception
+ handling constructs.</li>
+
+ <li>The optional PBQP register allocator now supports register coalescing.</li>
+ </ul>
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="x86">X86-32 and X86-64 Target Improvements</a>
+ </div>
+
+ <div class="doc_text">
+ <p>New features of the X86 target include:
+ </p>
+
+ <ul>
+ <li>The <tt><a href="LangRef.html#int_returnaddress">llvm.returnaddress</a></tt>
+ intrinsic (which is used to implement <tt>__builtin_return_address</tt>) now
+ supports non-zero stack depths on X86.</li>
+
+ <li>The X86 backend now supports code generation of vector shift operations
+ using SSE instructions.</li>
+
+ <li>X86-64 code generation now takes advantage of red zone, unless the
+ <tt>-mno-red-zone</tt> option is specified.</li>
+
+ <li>The X86 backend now supports using address space #256 in LLVM IR as a way of
+ performing memory references off the GS segment register. This allows a
+ front-end to take advantage of very low-level programming techniques when
+ targeting X86 CPUs. See <tt>test/CodeGen/X86/movgs.ll</tt> for a simple
+ example.</li>
+
+ <li>The X86 backend now supports a <tt>-disable-mmx</tt> command line option to
+ prevent use of MMX even on chips that support it. This is important for cases
+ where code does not contain the proper <tt>llvm.x86.mmx.emms</tt>
+ intrinsics.</li>
+
+ <li>The X86 JIT now detects the new Intel <a
+ href="http://en.wikipedia.org/wiki/Intel_Core_i7">Core i7</a> and <a
+ href="http://en.wikipedia.org/wiki/Intel_Atom">Atom</a> chips and
+ auto-configures itself appropriately for the features of these chips.</li>
+
+ <li>The JIT now supports exception handling constructs on Linux/X86-64 and
+ Darwin/x86-64.</li>
+
+ <li>The JIT supports Thread Local Storage (TLS) on Linux/X86-32 but not yet on
+ X86-64.</li>
+ </ul>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="pic16">PIC16 Target Improvements</a>
+ </div>
+
+ <div class="doc_text">
+ <p>New features of the PIC16 target include:
+ </p>
+
+ <ul>
+ <li>Both direct and indirect load/stores work now.</li>
+ <li>Logical, bitwise and conditional operations now work for integer data
+ types.</li>
+ <li>Function calls involving basic types work now.</li>
+ <li>Support for integer arrays.</li>
+ <li>The compiler can now emit libcalls for operations not supported by m/c
+ instructions.</li>
+ <li>Support for both data and ROM address spaces.</li>
+ </ul>
+
+ <p>Things not yet supported:</p>
+
+ <ul>
+ <li>Floating point.</li>
+ <li>Passing/returning aggregate types to and from functions.</li>
+ <li>Variable arguments.</li>
+ <li>Indirect function calls.</li>
+ <li>Interrupts/programs.</li>
+ <li>Debug info.</li>
+ </ul>
+
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="llvmc">Improvements in LLVMC</a>
+ </div>
+
+ <div class="doc_text">
+ <p>New features include:</p>
+
+ <ul>
+ <li>Beginning with LLVM 2.5, <tt>llvmc2</tt> is known as
+ just <tt>llvmc</tt>. The old <tt>llvmc</tt> driver was removed.</li>
+
+ <li>The Clang plugin was substantially improved and is now enabled
+ by default. The command <tt>llvmc --clang</tt> can be now used as a
+ synonym to <tt>ccc</tt>.</li>
+
+ <li>There is now a <tt>--check-graph</tt> option, which is supposed to catch
+ common errors like multiple default edges, mismatched output/input language
+ names and cycles. In general, these checks can't be done at compile-time
+ because of the need to support plugins.</li>
+
+ <li>Plugins are now more flexible and can refer to compilation graph nodes and
+ options defined in other plugins. To manage dependencies, a priority-sorting
+ mechanism was introduced. This change affects the TableGen file syntax. See the
+ documentation for details.</li>
+
+ <li>Hooks can now be provided with arguments. The syntax is "<tt>$CALL(MyHook,
+ 'Arg1', 'Arg2', 'Arg3')</tt>".</li>
+
+ <li>A new option type: multi-valued option, for options that take more than one
+ argument (for example, "<tt>-foo a b c</tt>").</li>
+
+ <li>New option properties: '<tt>one_or_more</tt>', '<tt>zero_or_more</tt>',
+ '<tt>hidden</tt>' and '<tt>really_hidden</tt>'.</li>
+
+ <li>The '<tt>case</tt>' expression gained an '<tt>error</tt>' action and
+ an '<tt>empty</tt>' test (equivalent to "<tt>(not (not_empty ...))</tt>").</li>
+
+ <li>Documentation now looks more consistent to the rest of the LLVM
+ docs. There is also a man page now.</li>
+
+ </ul>
+
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_subsection">
+ <a name="changes">Major Changes and Removed Features</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>If you're already an LLVM user or developer with out-of-tree changes based
+ on LLVM 2.4, this section lists some "gotchas" that you may run into upgrading
+ from the previous release.</p>
+
+ <ul>
+
+ <li>llvm-gcc defaults to <tt>-fno-math-errno</tt> on all X86 targets.</li>
+
+ </ul>
+
+
+ <p>In addition, many APIs have changed in this release. Some of the major LLVM
+ API changes are:</p>
+
+ <ul>
+ <li>Some deprecated interfaces to create <tt>Instruction</tt> subclasses, that
+ were spelled with lower case "create," have been removed.</li>
+ </ul>
+
+ </div>
+
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="portability">Portability and Supported Platforms</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM is known to work on the following platforms:</p>
+
+ <ul>
+ <li>Intel and AMD machines (IA32, X86-64, AMD64, EMT-64) running Red Hat
+ Linux, Fedora Core and FreeBSD (and probably other unix-like systems).</li>
+ <li>PowerPC and X86-based Mac OS X systems, running 10.3 and above in 32-bit
+ and 64-bit modes.</li>
+ <li>Intel and AMD machines running on Win32 using MinGW libraries (native).</li>
+ <li>Intel and AMD machines running on Win32 with the Cygwin libraries (limited
+ support is available for native builds with Visual C++).</li>
+ <li>Sun UltraSPARC workstations running Solaris 10.</li>
+ <li>Alpha-based machines running Debian GNU/Linux.</li>
+ <li>Itanium-based (IA64) machines running Linux and HP-UX.</li>
+ </ul>
+
+ <p>The core LLVM infrastructure uses GNU autoconf to adapt itself
+ to the machine and operating system on which it is built. However, minor
+ porting may be required to get LLVM to work on new platforms. We welcome your
+ portability patches and reports of successful builds or error messages.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="knownproblems">Known Problems</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This section contains significant known problems with the LLVM system,
+ listed by component. If you run into a problem, please check the <a
+ href="http://llvm.org/bugs/">LLVM bug database</a> and submit a bug if
+ there isn't already one.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="experimental">Experimental features included with this release</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The following components of this LLVM release are either untested, known to
+ be broken or unreliable, or are in early development. These components should
+ not be relied on, and bugs should not be filed against them, but they may be
+ useful to some people. In particular, if you would like to work on one of these
+ components, please contact us on the <a
+ href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVMdev list</a>.</p>
+
+ <ul>
+ <li>The MSIL, IA64, Alpha, SPU, MIPS, and PIC16 backends are experimental.</li>
+ <li>The <tt>llc</tt> "<tt>-filetype=asm</tt>" (the default) is the only
+ supported value for this option.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="x86-be">Known problems with the X86 back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li>The X86 backend does not yet support
+ all <a href="http://llvm.org/PR879">inline assembly that uses the X86
+ floating point stack</a>. It supports the 'f' and 't' constraints, but not
+ 'u'.</li>
+ <li>The X86 backend generates inefficient floating point code when configured
+ to generate code for systems that don't have SSE2.</li>
+ <li>Win64 code generation wasn't widely tested. Everything should work, but we
+ expect small issues to happen. Also, llvm-gcc cannot build the mingw64
+ runtime currently due
+ to <a href="http://llvm.org/PR2255">several</a>
+ <a href="http://llvm.org/PR2257">bugs</a> and due to lack of support for
+ the
+ 'u' inline assembly constraint and for X87 floating point inline assembly.</li>
+ <li>The X86-64 backend does not yet support the LLVM IR instruction
+ <tt>va_arg</tt>. Currently, the llvm-gcc and front-ends support variadic
+ argument constructs on X86-64 by lowering them manually.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ppc-be">Known problems with the PowerPC back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li>The Linux PPC32/ABI support needs testing for the interpreter and static
+ compilation, and lacks support for debug information.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="arm-be">Known problems with the ARM back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li>Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6
+ processors, thumb programs can crash or produce wrong
+ results (<a href="http://llvm.org/PR1388">PR1388</a>).</li>
+ <li>Compilation for ARM Linux OABI (old ABI) is supported but not fully tested.
+ </li>
+ <li>There is a bug in QEMU-ARM (<= 0.9.0) which causes it to incorrectly
+ execute
+ programs compiled with LLVM. Please use more recent versions of QEMU.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="sparc-be">Known problems with the SPARC back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li>The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not
+ support the 64-bit SPARC ABI (-m64).</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="mips-be">Known problems with the MIPS back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li>The O32 ABI is not fully supported.</li>
+ <li>64-bit MIPS targets are not supported yet.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="alpha-be">Known problems with the Alpha back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+
+ <li>On 21164s, some rare FP arithmetic sequences which may trap do not have the
+ appropriate nops inserted to ensure restartability.</li>
+
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ia64-be">Known problems with the IA64 back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li>The Itanium backend is highly experimental and has a number of known
+ issues. We are looking for a maintainer for the Itanium backend. If you
+ are interested, please contact the LLVMdev mailing list.</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="c-be">Known problems with the C back-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <ul>
+ <li><a href="http://llvm.org/PR802">The C backend has only basic support for
+ inline assembly code</a>.</li>
+ <li><a href="http://llvm.org/PR1658">The C backend violates the ABI of common
+ C++ programs</a>, preventing intermixing between C++ compiled by the CBE and
+ C++ code compiled with <tt>llc</tt> or native compilers.</li>
+ <li>The C backend does not support all exception handling constructs.</li>
+ <li>The C backend does not support arbitrary precision integers.</li>
+ </ul>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="c-fe">Known problems with the llvm-gcc C front-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>llvm-gcc does not currently support <a href="http://llvm.org/PR869">Link-Time
+ Optimization</a> on most platforms "out-of-the-box". Please inquire on the
+ LLVMdev mailing list if you are interested.</p>
+
+ <p>The only major language feature of GCC not supported by llvm-gcc is
+ the <tt>__builtin_apply</tt> family of builtins. However, some extensions
+ are only supported on some targets. For example, trampolines are only
+ supported on some targets (these are used when you take the address of a
+ nested function).</p>
+
+ <p>If you run into GCC extensions which are not supported, please let us know.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="c++-fe">Known problems with the llvm-gcc C++ front-end</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The C++ front-end is considered to be fully
+ tested and works for a number of non-trivial programs, including LLVM
+ itself, Qt, Mozilla, etc.</p>
+
+ <ul>
+ <li>Exception handling works well on the X86 and PowerPC targets. Currently
+ only Linux and Darwin targets are supported (both 32 and 64 bit).</li>
+ </ul>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="fortran-fe">Known problems with the llvm-gcc Fortran front-end</a>
+ </div>
+
+ <div class="doc_text">
+ <ul>
+ <li>Fortran support generally works, but there are still several unresolved bugs
+ in Bugzilla. Please see the tools/gfortran component for details.</li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ada-fe">Known problems with the llvm-gcc Ada front-end</a>
+ </div>
+
+ <div class="doc_text">
+ The llvm-gcc 4.2 Ada compiler works fairly well; however, this is not a mature
+ technology, and problems should be expected.
+ <ul>
+ <li>The Ada front-end currently only builds on X86-32. This is mainly due
+ to lack of trampoline support (pointers to nested functions) on other platforms.
+ However, it <a href="http://llvm.org/PR2006">also fails to build on X86-64</a>
+ which does support trampolines.</li>
+ <li>The Ada front-end <a href="http://llvm.org/PR2007">fails to bootstrap</a>.
+ This is due to lack of LLVM support for <tt>setjmp</tt>/<tt>longjmp</tt> style
+ exception handling, which is used internally by the compiler.
+ Workaround: configure with --disable-bootstrap.</li>
+ <li>The c380004, <a href="http://llvm.org/PR2010">c393010</a>
+ and <a href="http://llvm.org/PR2421">cxg2021</a> ACATS tests fail
+ (c380004 also fails with gcc-4.2 mainline).
+ If the compiler is built with checks disabled then <a href="http://llvm.org/PR2010">c393010</a>
+ causes the compiler to go into an infinite loop, using up all system memory.</li>
+ <li>Some GCC specific Ada tests continue to crash the compiler.</li>
+ <li>The -E binder option (exception backtraces)
+ <a href="http://llvm.org/PR1982">does not work</a> and will result in programs
+ crashing if an exception is raised. Workaround: do not use -E.</li>
+ <li>Only discrete types <a href="http://llvm.org/PR1981">are allowed to start
+ or finish at a non-byte offset</a> in a record. Workaround: do not pack records
+ or use representation clauses that result in a field of a non-discrete type
+ starting or finishing in the middle of a byte.</li>
+ <li>The <tt>lli</tt> interpreter <a href="http://llvm.org/PR2009">considers
+ 'main' as generated by the Ada binder to be invalid</a>.
+ Workaround: hand edit the file to use pointers for <tt>argv</tt> and
+ <tt>envp</tt> rather than integers.</li>
+ <li>The <tt>-fstack-check</tt> option <a href="http://llvm.org/PR2008">is
+ ignored</a>.</li>
+ </ul>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="additionalinfo">Additional Information</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>A wide variety of additional information is available on the <a
+ href="http://llvm.org">LLVM web page</a>, in particular in the <a
+ href="http://llvm.org/docs/">documentation</a> section. The web page also
+ contains versions of the API documentation which is up-to-date with the
+ Subversion version of the source code.
+ You can access versions of these documents specific to this release by going
+ into the "<tt>llvm/doc/</tt>" directory in the LLVM tree.</p>
+
+ <p>If you have any questions or comments about LLVM, please feel free to contact
+ us via the <a href="http://llvm.org/docs/#maillist"> mailing
+ lists</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/SourceLevelDebugging.html
diff -c /dev/null llvm-www/releases/2.5/docs/SourceLevelDebugging.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/SourceLevelDebugging.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1812 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Source Level Debugging with LLVM</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">Source Level Debugging with LLVM</div>
+
+ <table class="layout" style="width:100%">
+ <tr class="layout">
+ <td class="left">
+ <ul>
+ <li><a href="#introduction">Introduction</a>
+ <ol>
+ <li><a href="#phil">Philosophy behind LLVM debugging information</a></li>
+ <li><a href="#consumers">Debug information consumers</a></li>
+ <li><a href="#debugopt">Debugging optimized code</a></li>
+ </ol></li>
+ <li><a href="#format">Debugging information format</a>
+ <ol>
+ <li><a href="#debug_info_descriptors">Debug information descriptors</a>
+ <ul>
+ <li><a href="#format_anchors">Anchor descriptors</a></li>
+ <li><a href="#format_compile_units">Compile unit descriptors</a></li>
+ <li><a href="#format_global_variables">Global variable descriptors</a></li>
+ <li><a href="#format_subprograms">Subprogram descriptors</a></li>
+ <li><a href="#format_blocks">Block descriptors</a></li>
+ <li><a href="#format_basic_type">Basic type descriptors</a></li>
+ <li><a href="#format_derived_type">Derived type descriptors</a></li>
+ <li><a href="#format_composite_type">Composite type descriptors</a></li>
+ <li><a href="#format_subrange">Subrange descriptors</a></li>
+ <li><a href="#format_enumeration">Enumerator descriptors</a></li>
+ <li><a href="#format_variables">Local variables</a></li>
+ </ul></li>
+ <li><a href="#format_common_intrinsics">Debugger intrinsic functions</a>
+ <ul>
+ <li><a href="#format_common_stoppoint">llvm.dbg.stoppoint</a></li>
+ <li><a href="#format_common_func_start">llvm.dbg.func.start</a></li>
+ <li><a href="#format_common_region_start">llvm.dbg.region.start</a></li>
+ <li><a href="#format_common_region_end">llvm.dbg.region.end</a></li>
+ <li><a href="#format_common_declare">llvm.dbg.declare</a></li>
+ </ul></li>
+ <li><a href="#format_common_stoppoints">Representing stopping points in the
+ source program</a></li>
+ </ol></li>
+ <li><a href="#ccxx_frontend">C/C++ front-end specific debug information</a>
+ <ol>
+ <li><a href="#ccxx_compile_units">C/C++ source file information</a></li>
+ <li><a href="#ccxx_global_variable">C/C++ global variable information</a></li>
+ <li><a href="#ccxx_subprogram">C/C++ function information</a></li>
+ <li><a href="#ccxx_basic_types">C/C++ basic types</a></li>
+ <li><a href="#ccxx_derived_types">C/C++ derived types</a></li>
+ <li><a href="#ccxx_composite_types">C/C++ struct/union types</a></li>
+ <li><a href="#ccxx_enumeration_types">C/C++ enumeration types</a></li>
+ </ol></li>
+ </ul>
+ </td>
+ <td class="right">
+ <img src="img/venusflytrap.jpg" alt="A leafy and green bug eater" width="247"
+ height="369">
+ </td>
+ </tr></table>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>
+ and <a href="mailto:jlaskey at mac.com">Jim Laskey</a></p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="introduction">Introduction</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>This document is the central repository for all information pertaining to
+ debug information in LLVM. It describes the <a href="#format">actual format
+ that the LLVM debug information</a> takes, which is useful for those interested
+ in creating front-ends or dealing directly with the information. Further, this
+ document provides specifc examples of what debug information for C/C++.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="phil">Philosophy behind LLVM debugging information</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The idea of the LLVM debugging information is to capture how the important
+ pieces of the source-language's Abstract Syntax Tree map onto LLVM code.
+ Several design aspects have shaped the solution that appears here. The
+ important ones are:</p>
+
+ <ul>
+ <li>Debugging information should have very little impact on the rest of the
+ compiler. No transformations, analyses, or code generators should need to be
+ modified because of debugging information.</li>
+
+ <li>LLVM optimizations should interact in <a href="#debugopt">well-defined and
+ easily described ways</a> with the debugging information.</li>
+
+ <li>Because LLVM is designed to support arbitrary programming languages,
+ LLVM-to-LLVM tools should not need to know anything about the semantics of the
+ source-level-language.</li>
+
+ <li>Source-level languages are often <b>widely</b> different from one another.
+ LLVM should not put any restrictions of the flavor of the source-language, and
+ the debugging information should work with any language.</li>
+
+ <li>With code generator support, it should be possible to use an LLVM compiler
+ to compile a program to native machine code and standard debugging formats.
+ This allows compatibility with traditional machine-code level debuggers, like
+ GDB or DBX.</li>
+
+ </ul>
+
+ <p>The approach used by the LLVM implementation is to use a small set of <a
+ href="#format_common_intrinsics">intrinsic functions</a> to define a mapping
+ between LLVM program objects and the source-level objects. The description of
+ the source-level program is maintained in LLVM global variables in an <a
+ href="#ccxx_frontend">implementation-defined format</a> (the C/C++ front-end
+ currently uses working draft 7 of the <a
+ href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3 standard</a>).</p>
+
+ <p>When a program is being debugged, a debugger interacts with the user and
+ turns the stored debug information into source-language specific information.
+ As such, a debugger must be aware of the source-language, and is thus tied to
+ a specific language or family of languages.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="consumers">Debug information consumers</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The role of debug information is to provide meta information normally
+ stripped away during the compilation process. This meta information provides an
+ LLVM user a relationship between generated code and the original program source
+ code.</p>
+
+ <p>Currently, debug information is consumed by the DwarfWriter to produce dwarf
+ information used by the gdb debugger. Other targets could use the same
+ information to produce stabs or other debug forms.</p>
+
+ <p>It would also be reasonable to use debug information to feed profiling tools
+ for analysis of generated code, or, tools for reconstructing the original source
+ from generated code.</p>
+
+ <p>TODO - expound a bit more.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="debugopt">Debugging optimized code</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>An extremely high priority of LLVM debugging information is to make it
+ interact well with optimizations and analysis. In particular, the LLVM debug
+ information provides the following guarantees:</p>
+
+ <ul>
+
+ <li>LLVM debug information <b>always provides information to accurately read the
+ source-level state of the program</b>, regardless of which LLVM optimizations
+ have been run, and without any modification to the optimizations themselves.
+ However, some optimizations may impact the ability to modify the current state
+ of the program with a debugger, such as setting program variables, or calling
+ functions that have been deleted.</li>
+
+ <li>LLVM optimizations gracefully interact with debugging information. If they
+ are not aware of debug information, they are automatically disabled as necessary
+ in the cases that would invalidate the debug info. This retains the LLVM
+ features, making it easy to write new transformations.</li>
+
+ <li>As desired, LLVM optimizations can be upgraded to be aware of the LLVM
+ debugging information, allowing them to update the debugging information as they
+ perform aggressive optimizations. This means that, with effort, the LLVM
+ optimizers could optimize debug code just as well as non-debug code.</li>
+
+ <li>LLVM debug information does not prevent many important optimizations from
+ happening (for example inlining, basic block reordering/merging/cleanup, tail
+ duplication, etc), further reducing the amount of the compiler that eventually
+ is "aware" of debugging information.</li>
+
+ <li>LLVM debug information is automatically optimized along with the rest of the
+ program, using existing facilities. For example, duplicate information is
+ automatically merged by the linker, and unused information is automatically
+ removed.</li>
+
+ </ul>
+
+ <p>Basically, the debug information allows you to compile a program with
+ "<tt>-O0 -g</tt>" and get full debug information, allowing you to arbitrarily
+ modify the program as it executes from a debugger. Compiling a program with
+ "<tt>-O3 -g</tt>" gives you full debug information that is always available and
+ accurate for reading (e.g., you get accurate stack traces despite tail call
+ elimination and inlining), but you might lose the ability to modify the program
+ and call functions where were optimized out of the program, or inlined away
+ completely.</p>
+
+ <p><a href="TestingGuide.html#quicktestsuite">LLVM test suite</a> provides a
+ framework to test optimizer's handling of debugging information. It can be run
+ like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ % cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level
+ % make TEST=dbgopt
+ </pre>
+ </div>
+
+ <p>
+ This will test impact of debugging information on optimization passes. If
+ debugging information influences optimization passes then it will be reported
+ as a failure. See <a href="TestingGuide.html">TestingGuide</a>
+ for more information on LLVM test infrastructure and how to run various tests.
+ </p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="format">Debugging information format</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>LLVM debugging information has been carefully designed to make it possible
+ for the optimizer to optimize the program and debugging information without
+ necessarily having to know anything about debugging information. In particular,
+ the global constant merging pass automatically eliminates duplicated debugging
+ information (often caused by header files), the global dead code elimination
+ pass automatically deletes debugging information for a function if it decides to
+ delete the function, and the linker eliminates debug information when it merges
+ <tt>linkonce</tt> functions.</p>
+
+ <p>To do this, most of the debugging information (descriptors for types,
+ variables, functions, source files, etc) is inserted by the language front-end
+ in the form of LLVM global variables. These LLVM global variables are no
+ different from any other global variables, except that they have a web of LLVM
+ intrinsic functions that point to them. If the last references to a particular
+ piece of debugging information are deleted (for example, by the
+ <tt>-globaldce</tt> pass), the extraneous debug information will automatically
+ become dead and be removed by the optimizer.</p>
+
+ <p>Debug information is designed to be agnostic about the target debugger and
+ debugging information representation (e.g. DWARF/Stabs/etc). It uses a generic
+ machine debug information pass to decode the information that represents
+ variables, types, functions, namespaces, etc: this allows for arbitrary
+ source-language semantics and type-systems to be used, as long as there is a
+ module written for the target debugger to interpret the information. In
+ addition, debug global variables are declared in the <tt>"llvm.metadata"</tt>
+ section. All values declared in this section are stripped away after target
+ debug information is constructed and before the program object is emitted.</p>
+
+ <p>To provide basic functionality, the LLVM debugger does have to make some
+ assumptions about the source-level language being debugged, though it keeps
+ these to a minimum. The only common features that the LLVM debugger assumes
+ exist are <a href="#format_compile_units">source files</a>, and <a
+ href="#format_global_variables">program objects</a>. These abstract objects are
+ used by a debugger to form stack traces, show information about local
+ variables, etc.</p>
+
+ <p>This section of the documentation first describes the representation aspects
+ common to any source-language. The <a href="#ccxx_frontend">next section</a>
+ describes the data layout conventions used by the C and C++ front-ends.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="debug_info_descriptors">Debug information descriptors</a>
+ </div>
+
+ <div class="doc_text">
+ <p>In consideration of the complexity and volume of debug information, LLVM
+ provides a specification for well formed debug global variables. The constant
+ value of each of these globals is one of a limited set of structures, known as
+ debug descriptors.</p>
+
+ <p>Consumers of LLVM debug information expect the descriptors for program
+ objects to start in a canonical format, but the descriptors can include
+ additional information appended at the end that is source-language specific. All
+ LLVM debugging information is versioned, allowing backwards compatibility in the
+ case that the core structures need to change in some way. Also, all debugging
+ information objects start with a tag to indicate what type of object it is. The
+ source-language is allowed to define its own objects, by using unreserved tag
+ numbers. We recommend using with tags in the range 0x1000 thru 0x2000 (there is
+ a defined enum DW_TAG_user_base = 0x1000.)</p>
+
+ <p>The fields of debug descriptors used internally by LLVM (MachineModuleInfo)
+ are restricted to only the simple data types <tt>int</tt>, <tt>uint</tt>,
+ <tt>bool</tt>, <tt>float</tt>, <tt>double</tt>, <tt>sbyte*</tt> and <tt> { }*
+ </tt>. References to arbitrary values are handled using a <tt> { }* </tt> and a
+ cast to <tt> { }* </tt> expression; typically references to other field
+ descriptors, arrays of descriptors or global variables.</p>
+
+ <pre>
+ %llvm.dbg.object.type = type {
+ uint, ;; A tag
+ ...
+ }
+ </pre>
+
+ <p><a name="LLVMDebugVersion">The first field of a descriptor is always an
+ <tt>uint</tt> containing a tag value identifying the content of the descriptor.
+ The remaining fields are specific to the descriptor. The values of tags are
+ loosely bound to the tag values of Dwarf information entries. However, that
+ does not restrict the use of the information supplied to Dwarf targets. To
+ facilitate versioning of debug information, the tag is augmented with the
+ current debug version (LLVMDebugVersion = 4 << 16 or 0x40000 or 262144.)</a></p>
+
+ <p>The details of the various descriptors follow.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_anchors">Anchor descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_anchors">llvm.dbg.anchor.type</a> = type {
+ uint, ;; Tag = 0 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a>
+ uint ;; Tag of descriptors grouped by the anchor
+ }
+ </pre>
+
+ <p>One important aspect of the LLVM debug representation is that it allows the
+ LLVM debugger to efficiently index all of the global objects without having the
+ scan the program. To do this, all of the global objects use "anchor"
+ descriptors with designated names. All of the global objects of a particular
+ type (e.g., compile units) contain a pointer to the anchor. This pointer allows
+ a debugger to use def-use chains to find all global objects of that type.</p>
+
+ <p>The following names are recognized as anchors by LLVM:</p>
+
+ <pre>
+ %<a href="#format_compile_units">llvm.dbg.compile_units</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 17 } ;; DW_TAG_compile_unit
+ %<a href="#format_global_variables">llvm.dbg.global_variables</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 52 } ;; DW_TAG_variable
+ %<a href="#format_subprograms">llvm.dbg.subprograms</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 46 } ;; DW_TAG_subprogram
+ </pre>
+
+ <p>Using anchors in this way (where the compile unit descriptor points to the
+ anchors, as opposed to having a list of compile unit descriptors) allows for the
+ standard dead global elimination and merging passes to automatically remove
+ unused debugging information. If the globals were kept track of through lists,
+ there would always be an object pointing to the descriptors, thus would never be
+ deleted.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_compile_units">Compile unit descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> = type {
+ uint, ;; Tag = 17 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_compile_unit)
+ { }*, ;; Compile unit anchor = cast = (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_units</a> to { }*)
+ uint, ;; Dwarf language identifier (ex. DW_LANG_C89)
+ sbyte*, ;; Source file name
+ sbyte*, ;; Source file directory (includes trailing slash)
+ sbyte* ;; Producer (ex. "4.0.1 LLVM (LLVM research group)")
+ bool ;; True if this is a main compile unit.
+ }
+ </pre>
+
+ <p>These descriptors contain a source language ID for the file (we use the Dwarf
+ 3.0 ID numbers, such as <tt>DW_LANG_C89</tt>, <tt>DW_LANG_C_plus_plus</tt>,
+ <tt>DW_LANG_Cobol74</tt>, etc), three strings describing the filename, working
+ directory of the compiler, and an identifier string for the compiler that
+ produced it.</p>
+
+ <p> Compile unit descriptors provide the root context for objects declared in a
+ specific source file. Global variables and top level functions would be defined
+ using this context. Compile unit descriptors also provide context for source
+ line correspondence.</p>
+
+ <p> Each input file is encoded as a separate compile unit in LLVM debugging
+ information output. However, many target specific tool chains prefer to encode
+ only one compile unit in an object file. In this situation, the LLVM code
+ generator will include debugging information entities in the compile unit
+ that is marked as main compile unit. The code generator accepts maximum one main
+ compile unit per module. If a module does not contain any main compile unit
+ then the code generator will emit multiple compile units in the output object
+ file.
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_global_variables">Global variable descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_global_variables">llvm.dbg.global_variable.type</a> = type {
+ uint, ;; Tag = 52 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_variable)
+ { }*, ;; Global variable anchor = cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_global_variables">llvm.dbg.global_variables</a> to { }*),
+ { }*, ;; Reference to context descriptor
+ sbyte*, ;; Name
+ sbyte*, ;; Display name (fully qualified C++ name)
+ sbyte*, ;; MIPS linkage name (for C++)
+ { }*, ;; Reference to compile unit where defined
+ uint, ;; Line number where defined
+ { }*, ;; Reference to type descriptor
+ bool, ;; True if the global is local to compile unit (static)
+ bool, ;; True if the global is defined in the compile unit (not extern)
+ { }* ;; Reference to the global variable
+ }
+ </pre>
+
+ <p>These descriptors provide debug information about globals variables. The
+ provide details such as name, type and where the variable is defined.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_subprograms">Subprogram descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_subprograms">llvm.dbg.subprogram.type</a> = type {
+ uint, ;; Tag = 46 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subprogram)
+ { }*, ;; Subprogram anchor = cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_subprograms">llvm.dbg.subprograms</a> to { }*),
+ { }*, ;; Reference to context descriptor
+ sbyte*, ;; Name
+ sbyte*, ;; Display name (fully qualified C++ name)
+ sbyte*, ;; MIPS linkage name (for C++)
+ { }*, ;; Reference to compile unit where defined
+ uint, ;; Line number where defined
+ { }*, ;; Reference to type descriptor
+ bool, ;; True if the global is local to compile unit (static)
+ bool ;; True if the global is defined in the compile unit (not extern)
+ }
+ </pre>
+
+ <p>These descriptors provide debug information about functions, methods and
+ subprograms. They provide details such as name, return types and the source
+ location where the subprogram is defined.</p>
+
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_blocks">Block descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_blocks">llvm.dbg.block</a> = type {
+ uint, ;; Tag = 13 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_lexical_block)
+ { }* ;; Reference to context descriptor
+ }
+ </pre>
+
+ <p>These descriptors provide debug information about nested blocks within a
+ subprogram. The array of member descriptors is used to define local variables
+ and deeper nested blocks.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_basic_type">Basic type descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype.type</a> = type {
+ uint, ;; Tag = 36 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_base_type)
+ { }*, ;; Reference to context (typically a compile unit)
+ sbyte*, ;; Name (may be "" for anonymous types)
+ { }*, ;; Reference to compile unit where defined (may be NULL)
+ uint, ;; Line number where defined (may be 0)
+ uint, ;; Size in bits
+ uint, ;; Alignment in bits
+ uint, ;; Offset in bits
+ uint ;; Dwarf type encoding
+ }
+ </pre>
+
+ <p>These descriptors define primitive types used in the code. Example int, bool
+ and float. The context provides the scope of the type, which is usually the top
+ level. Since basic types are not usually user defined the compile unit and line
+ number can be left as NULL and 0. The size, alignment and offset are expressed
+ in bits and can be 64 bit values. The alignment is used to round the offset
+ when embedded in a <a href="#format_composite_type">composite type</a>
+ (example to keep float doubles on 64 bit boundaries.) The offset is the bit
+ offset if embedded in a <a href="#format_composite_type">composite
+ type</a>.</p>
+
+ <p>The type encoding provides the details of the type. The values are typically
+ one of the following:</p>
+
+ <pre>
+ DW_ATE_address = 1
+ DW_ATE_boolean = 2
+ DW_ATE_float = 4
+ DW_ATE_signed = 5
+ DW_ATE_signed_char = 6
+ DW_ATE_unsigned = 7
+ DW_ATE_unsigned_char = 8
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_derived_type">Derived type descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> = type {
+ uint, ;; Tag (see below)
+ { }*, ;; Reference to context
+ sbyte*, ;; Name (may be "" for anonymous types)
+ { }*, ;; Reference to compile unit where defined (may be NULL)
+ uint, ;; Line number where defined (may be 0)
+ uint, ;; Size in bits
+ uint, ;; Alignment in bits
+ uint, ;; Offset in bits
+ { }* ;; Reference to type derived from
+ }
+ </pre>
+
+ <p>These descriptors are used to define types derived from other types. The
+ value of the tag varies depending on the meaning. The following are possible
+ tag values:</p>
+
+ <pre>
+ DW_TAG_formal_parameter = 5
+ DW_TAG_member = 13
+ DW_TAG_pointer_type = 15
+ DW_TAG_reference_type = 16
+ DW_TAG_typedef = 22
+ DW_TAG_const_type = 38
+ DW_TAG_volatile_type = 53
+ DW_TAG_restrict_type = 55
+ </pre>
+
+ <p> <tt>DW_TAG_member</tt> is used to define a member of a <a
+ href="#format_composite_type">composite type</a> or <a
+ href="#format_subprograms">subprogram</a>. The type of the member is the <a
+ href="#format_derived_type">derived type</a>. <tt>DW_TAG_formal_parameter</tt>
+ is used to define a member which is a formal argument of a subprogram.</p>
+
+ <p><tt>DW_TAG_typedef</tt> is used to
+ provide a name for the derived type.</p>
+
+ <p><tt>DW_TAG_pointer_type</tt>,
+ <tt>DW_TAG_reference_type</tt>, <tt>DW_TAG_const_type</tt>,
+ <tt>DW_TAG_volatile_type</tt> and <tt>DW_TAG_restrict_type</tt> are used to
+ qualify the <a href="#format_derived_type">derived type</a>. </p>
+
+ <p><a href="#format_derived_type">Derived type</a> location can be determined
+ from the compile unit and line number. The size, alignment and offset are
+ expressed in bits and can be 64 bit values. The alignment is used to round the
+ offset when embedded in a <a href="#format_composite_type">composite type</a>
+ (example to keep float doubles on 64 bit boundaries.) The offset is the bit
+ offset if embedded in a <a href="#format_composite_type">composite
+ type</a>.</p>
+
+ <p>Note that the <tt>void *</tt> type is expressed as a
+ <tt>llvm.dbg.derivedtype.type</tt> with tag of <tt>DW_TAG_pointer_type</tt> and
+ NULL derived type.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_composite_type">Composite type descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_composite_type">llvm.dbg.compositetype.type</a> = type {
+ uint, ;; Tag (see below)
+ { }*, ;; Reference to context
+ sbyte*, ;; Name (may be "" for anonymous types)
+ { }*, ;; Reference to compile unit where defined (may be NULL)
+ uint, ;; Line number where defined (may be 0)
+ uint, ;; Size in bits
+ uint, ;; Alignment in bits
+ uint, ;; Offset in bits
+ { }* ;; Reference to array of member descriptors
+ }
+ </pre>
+
+ <p>These descriptors are used to define types that are composed of 0 or more
+ elements. The value of the tag varies depending on the meaning. The following
+ are possible tag values:</p>
+
+ <pre>
+ DW_TAG_array_type = 1
+ DW_TAG_enumeration_type = 4
+ DW_TAG_structure_type = 19
+ DW_TAG_union_type = 23
+ DW_TAG_vector_type = 259
+ DW_TAG_subroutine_type = 46
+ DW_TAG_inheritance = 26
+ </pre>
+
+ <p>The vector flag indicates that an array type is a native packed vector.</p>
+
+ <p>The members of array types (tag = <tt>DW_TAG_array_type</tt>) or vector types
+ (tag = <tt>DW_TAG_vector_type</tt>) are <a href="#format_subrange">subrange
+ descriptors</a>, each representing the range of subscripts at that level of
+ indexing.</p>
+
+ <p>The members of enumeration types (tag = <tt>DW_TAG_enumeration_type</tt>) are
+ <a href="#format_enumeration">enumerator descriptors</a>, each representing the
+ definition of enumeration value
+ for the set.</p>
+
+ <p>The members of structure (tag = <tt>DW_TAG_structure_type</tt>) or union (tag
+ = <tt>DW_TAG_union_type</tt>) types are any one of the <a
+ href="#format_basic_type">basic</a>, <a href="#format_derived_type">derived</a>
+ or <a href="#format_composite_type">composite</a> type descriptors, each
+ representing a field member of the structure or union.</p>
+
+ <p>For C++ classes (tag = <tt>DW_TAG_structure_type</tt>), member descriptors
+ provide information about base classes, static members and member functions. If
+ a member is a <a href="#format_derived_type">derived type descriptor</a> and has
+ a tag of <tt>DW_TAG_inheritance</tt>, then the type represents a base class. If
+ the member of is a <a href="#format_global_variables">global variable
+ descriptor</a> then it represents a static member. And, if the member is a <a
+ href="#format_subprograms">subprogram descriptor</a> then it represents a member
+ function. For static members and member functions, <tt>getName()</tt> returns
+ the members link or the C++ mangled name. <tt>getDisplayName()</tt> the
+ simplied version of the name.</p>
+
+ <p>The first member of subroutine (tag = <tt>DW_TAG_subroutine_type</tt>)
+ type elements is the return type for the subroutine. The remaining
+ elements are the formal arguments to the subroutine.</p>
+
+ <p><a href="#format_composite_type">Composite type</a> location can be
+ determined from the compile unit and line number. The size, alignment and
+ offset are expressed in bits and can be 64 bit values. The alignment is used to
+ round the offset when embedded in a <a href="#format_composite_type">composite
+ type</a> (as an example, to keep float doubles on 64 bit boundaries.) The offset
+ is the bit offset if embedded in a <a href="#format_composite_type">composite
+ type</a>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_subrange">Subrange descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_subrange">llvm.dbg.subrange.type</a> = type {
+ uint, ;; Tag = 33 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_subrange_type)
+ uint, ;; Low value
+ uint ;; High value
+ }
+ </pre>
+
+ <p>These descriptors are used to define ranges of array subscripts for an array
+ <a href="#format_composite_type">composite type</a>. The low value defines the
+ lower bounds typically zero for C/C++. The high value is the upper bounds.
+ Values are 64 bit. High - low + 1 is the size of the array. If
+ low == high the array will be unbounded.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_enumeration">Enumerator descriptors</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_enumeration">llvm.dbg.enumerator.type</a> = type {
+ uint, ;; Tag = 40 + <a href="#LLVMDebugVersion">LLVMDebugVersion</a> (DW_TAG_enumerator)
+ sbyte*, ;; Name
+ uint ;; Value
+ }
+ </pre>
+
+ <p>These descriptors are used to define members of an enumeration <a
+ href="#format_composite_type">composite type</a>, it associates the name to the
+ value.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_variables">Local variables</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ %<a href="#format_variables">llvm.dbg.variable.type</a> = type {
+ uint, ;; Tag (see below)
+ { }*, ;; Context
+ sbyte*, ;; Name
+ { }*, ;; Reference to compile unit where defined
+ uint, ;; Line number where defined
+ { }* ;; Type descriptor
+ }
+ </pre>
+
+ <p>These descriptors are used to define variables local to a sub program. The
+ value of the tag depends on the usage of the variable:</p>
+
+ <pre>
+ DW_TAG_auto_variable = 256
+ DW_TAG_arg_variable = 257
+ DW_TAG_return_variable = 258
+ </pre>
+
+ <p>An auto variable is any variable declared in the body of the function. An
+ argument variable is any variable that appears as a formal argument to the
+ function. A return variable is used to track the result of a function and has
+ no source correspondent.</p>
+
+ <p>The context is either the subprogram or block where the variable is defined.
+ Name the source variable name. Compile unit and line indicate where the
+ variable was defined. Type descriptor defines the declared type of the
+ variable.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="format_common_intrinsics">Debugger intrinsic functions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to
+ provide debug information at various points in generated code.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_common_stoppoint">llvm.dbg.stoppoint</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint, uint, { }* )
+ </pre>
+
+ <p>This intrinsic is used to provide correspondence between the source file and
+ the generated code. The first argument is the line number (base 1), second
+ argument is the column number (0 if unknown) and the third argument the source
+ <tt>%<a href="#format_compile_units">llvm.dbg.compile_unit</a>*</tt> cast to a
+ <tt>{ }*</tt>. Code following a call to this intrinsic will have been defined
+ in close proximity of the line, column and file. This information holds until
+ the next call to <tt>%<a
+ href="#format_common_stoppoint">lvm.dbg.stoppoint</a></tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_common_func_start">llvm.dbg.func.start</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ void %<a href="#format_common_func_start">llvm.dbg.func.start</a>( { }* )
+ </pre>
+
+ <p>This intrinsic is used to link the debug information in <tt>%<a
+ href="#format_subprograms">llvm.dbg.subprogram</a></tt> to the function. It
+ defines the beginning of the function's declarative region (scope). It also
+ implies a call to %<tt><a
+ href="#format_common_stoppoint">llvm.dbg.stoppoint</a></tt> which defines a
+ source line "stop point". The intrinsic should be called early in the function
+ after the all the alloca instructions. It should be paired off with a closing
+ <tt>%<a
+ href="#format_common_region_end">llvm.dbg.region.end</a></tt>. The function's
+ single argument is the <tt>%<a
+ href="#format_subprograms">llvm.dbg.subprogram.type</a></tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_common_region_start">llvm.dbg.region.start</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ void %<a href="#format_common_region_start">llvm.dbg.region.start</a>( { }* )
+ </pre>
+
+ <p>This intrinsic is used to define the beginning of a declarative scope (ex.
+ block) for local language elements. It should be paired off with a closing
+ <tt>%<a href="#format_common_region_end">llvm.dbg.region.end</a></tt>. The
+ function's single argument is the <tt>%<a
+ href="#format_blocks">llvm.dbg.block</a></tt> which is starting.</p>
+
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_common_region_end">llvm.dbg.region.end</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ void %<a href="#format_common_region_end">llvm.dbg.region.end</a>( { }* )
+ </pre>
+
+ <p>This intrinsic is used to define the end of a declarative scope (ex. block)
+ for local language elements. It should be paired off with an opening <tt>%<a
+ href="#format_common_region_start">llvm.dbg.region.start</a></tt> or <tt>%<a
+ href="#format_common_func_start">llvm.dbg.func.start</a></tt>. The function's
+ single argument is either the <tt>%<a
+ href="#format_blocks">llvm.dbg.block</a></tt> or the <tt>%<a
+ href="#format_subprograms">llvm.dbg.subprogram.type</a></tt> which is
+ ending.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="format_common_declare">llvm.dbg.declare</a>
+ </div>
+
+ <div class="doc_text">
+ <pre>
+ void %<a href="#format_common_declare">llvm.dbg.declare</a>( { } *, { }* )
+ </pre>
+
+ <p>This intrinsic provides information about a local element (ex. variable.) The
+ first argument is the alloca for the variable, cast to a <tt>{ }*</tt>. The
+ second argument is the <tt>%<a
+ href="#format_variables">llvm.dbg.variable</a></tt> containing the description
+ of the variable, also cast to a <tt>{ }*</tt>.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="format_common_stoppoints">
+ Representing stopping points in the source program
+ </a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>LLVM debugger "stop points" are a key part of the debugging representation
+ that allows the LLVM to maintain simple semantics for <a
+ href="#debugopt">debugging optimized code</a>. The basic idea is that the
+ front-end inserts calls to the <a
+ href="#format_common_stoppoint">%<tt>llvm.dbg.stoppoint</tt></a> intrinsic
+ function at every point in the program where a debugger should be able to
+ inspect the program (these correspond to places a debugger stops when you
+ "<tt>step</tt>" through it). The front-end can choose to place these as
+ fine-grained as it would like (for example, before every subexpression
+ evaluated), but it is recommended to only put them after every source statement
+ that includes executable code.</p>
+
+ <p>Using calls to this intrinsic function to demark legal points for the
+ debugger to inspect the program automatically disables any optimizations that
+ could potentially confuse debugging information. To non-debug-information-aware
+ transformations, these calls simply look like calls to an external function,
+ which they must assume to do anything (including reading or writing to any part
+ of reachable memory). On the other hand, it does not impact many optimizations,
+ such as code motion of non-trapping instructions, nor does it impact
+ optimization of subexpressions, code duplication transformations, or basic-block
+ reordering transformations.</p>
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="format_common_lifetime">Object lifetimes and scoping</a>
+ </div>
+
+ <div class="doc_text">
+ <p>In many languages, the local variables in functions can have their lifetime
+ or scope limited to a subset of a function. In the C family of languages, for
+ example, variables are only live (readable and writable) within the source block
+ that they are defined in. In functional languages, values are only readable
+ after they have been defined. Though this is a very obvious concept, it is also
+ non-trivial to model in LLVM, because it has no notion of scoping in this sense,
+ and does not want to be tied to a language's scoping rules.</p>
+
+ <p>In order to handle this, the LLVM debug format uses the notion of "regions"
+ of a function, delineated by calls to intrinsic functions. These intrinsic
+ functions define new regions of the program and indicate when the region
+ lifetime expires. Consider the following C fragment, for example:</p>
+
+ <pre>
+ 1. void foo() {
+ 2. int X = ...;
+ 3. int Y = ...;
+ 4. {
+ 5. int Z = ...;
+ 6. ...
+ 7. }
+ 8. ...
+ 9. }
+ </pre>
+
+ <p>Compiled to LLVM, this function would be represented like this:</p>
+
+ <pre>
+ void %foo() {
+ entry:
+ %X = alloca int
+ %Y = alloca int
+ %Z = alloca int
+
+ ...
+
+ call void %<a href="#format_common_func_start">llvm.dbg.func.start</a>( %<a href="#format_subprograms">llvm.dbg.subprogram.type</a>* %llvm.dbg.subprogram )
+
+ call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 2, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+
+ call void %<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
+ call void %<a href="#format_common_declare">llvm.dbg.declare</a>({}* %Y, ...)
+
+ <i>;; Evaluate expression on line 2, assigning to X.</i>
+
+ call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 3, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+
+ <i>;; Evaluate expression on line 3, assigning to Y.</i>
+
+ call void %<a href="#format_common_stoppoint">llvm.region.start</a>()
+ call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 5, uint 4, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+ call void %<a href="#format_common_declare">llvm.dbg.declare</a>({}* %X, ...)
+
+ <i>;; Evaluate expression on line 5, assigning to Z.</i>
+
+ call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 7, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+ call void %<a href="#format_common_region_end">llvm.region.end</a>()
+
+ call void %<a href="#format_common_stoppoint">llvm.dbg.stoppoint</a>( uint 9, uint 2, %<a href="#format_compile_units">llvm.dbg.compile_unit</a>* %llvm.dbg.compile_unit )
+
+ call void %<a href="#format_common_region_end">llvm.region.end</a>()
+
+ ret void
+ }
+ </pre>
+
+ <p>This example illustrates a few important details about the LLVM debugging
+ information. In particular, it shows how the various intrinsics are applied
+ together to allow a debugger to analyze the relationship between statements,
+ variable definitions, and the code used to implement the function.</p>
+
+ <p>The first intrinsic <tt>%<a
+ href="#format_common_func_start">llvm.dbg.func.start</a></tt> provides
+ a link with the <a href="#format_subprograms">subprogram descriptor</a>
+ containing the details of this function. This call also defines the beginning
+ of the function region, bounded by the <tt>%<a
+ href="#format_common_region_end">llvm.region.end</a></tt> at the end of
+ the function. This region is used to bracket the lifetime of variables declared
+ within. For a function, this outer region defines a new stack frame whose
+ lifetime ends when the region is ended.</p>
+
+ <p>It is possible to define inner regions for short term variables by using the
+ %<a href="#format_common_stoppoint"><tt>llvm.region.start</tt></a> and <a
+ href="#format_common_region_end"><tt>%llvm.region.end</tt></a> to bound a
+ region. The inner region in this example would be for the block containing the
+ declaration of Z.</p>
+
+ <p>Using regions to represent the boundaries of source-level functions allow
+ LLVM interprocedural optimizations to arbitrarily modify LLVM functions without
+ having to worry about breaking mapping information between the LLVM code and the
+ and source-level program. In particular, the inliner requires no modification
+ to support inlining with debugging information: there is no explicit correlation
+ drawn between LLVM functions and their source-level counterparts (note however,
+ that if the inliner inlines all instances of a non-strong-linkage function into
+ its caller that it will not be possible for the user to manually invoke the
+ inlined function from a debugger).</p>
+
+ <p>Once the function has been defined, the <a
+ href="#format_common_stoppoint"><tt>stopping point</tt></a> corresponding to
+ line #2 (column #2) of the function is encountered. At this point in the
+ function, <b>no</b> local variables are live. As lines 2 and 3 of the example
+ are executed, their variable definitions are introduced into the program using
+ %<a href="#format_common_declare"><tt>llvm.dbg.declare</tt></a>, without the
+ need to specify a new region. These variables do not require new regions to be
+ introduced because they go out of scope at the same point in the program: line
+ 9.</p>
+
+ <p>In contrast, the <tt>Z</tt> variable goes out of scope at a different time,
+ on line 7. For this reason, it is defined within the inner region, which kills
+ the availability of <tt>Z</tt> before the code for line 8 is executed. In this
+ way, regions can support arbitrary source-language scoping rules, as long as
+ they can only be nested (ie, one scope cannot partially overlap with a part of
+ another scope).</p>
+
+ <p>It is worth noting that this scoping mechanism is used to control scoping of
+ all declarations, not just variable declarations. For example, the scope of a
+ C++ using declaration is controlled with this and could change how name lookup is
+ performed.</p>
+
+ </div>
+
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="ccxx_frontend">C/C++ front-end specific debug information</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The C and C++ front-ends represent information about the program in a format
+ that is effectively identical to <a
+ href="http://www.eagercon.com/dwarf/dwarf3std.htm">Dwarf 3.0</a> in terms of
+ information content. This allows code generators to trivially support native
+ debuggers by generating standard dwarf information, and contains enough
+ information for non-dwarf targets to translate it as needed.</p>
+
+ <p>This section describes the forms used to represent C and C++ programs. Other
+ languages could pattern themselves after this (which itself is tuned to
+ representing programs in the same way that Dwarf 3 does), or they could choose
+ to provide completely different forms if they don't fit into the Dwarf model.
+ As support for debugging information gets added to the various LLVM
+ source-language front-ends, the information used should be documented here.</p>
+
+ <p>The following sections provide examples of various C/C++ constructs and the
+ debug information that would best describe those constructs.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_compile_units">C/C++ source file information</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Given the source files "MySource.cpp" and "MyHeader.h" located in the
+ directory "/Users/mine/sources", the following code:</p>
+
+ <pre>
+ #include "MyHeader.h"
+
+ int main(int argc, char *argv[]) {
+ return 0;
+ }
+ </pre>
+
+ <p>a C/C++ front-end would generate the following descriptors:</p>
+
+ <pre>
+ ...
+ ;;
+ ;; Define types used. In this case we need one for compile unit anchors and one
+ ;; for compile units.
+ ;;
+ %<a href="#format_anchors">llvm.dbg.anchor.type</a> = type { uint, uint }
+ %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> = type { uint, { }*, uint, uint, sbyte*, sbyte*, sbyte* }
+ ...
+ ;;
+ ;; Define the anchor for compile units. Note that the second field of the
+ ;; anchor is 17, which is the same as the tag for compile units
+ ;; (17 = DW_TAG_compile_unit.)
+ ;;
+ %<a href="#format_compile_units">llvm.dbg.compile_units</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 17 }, section "llvm.metadata"
+
+ ;;
+ ;; Define the compile unit for the source file "/Users/mine/sources/MySource.cpp".
+ ;;
+ %<a href="#format_compile_units">llvm.dbg.compile_unit1</a> = internal constant %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> {
+ uint add(uint 17, uint 262144),
+ { }* cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_units</a> to { }*),
+ uint 1,
+ uint 1,
+ sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0),
+ sbyte* getelementptr ([21 x sbyte]* %str2, int 0, int 0),
+ sbyte* getelementptr ([33 x sbyte]* %str3, int 0, int 0) }, section "llvm.metadata"
+
+ ;;
+ ;; Define the compile unit for the header file "/Users/mine/sources/MyHeader.h".
+ ;;
+ %<a href="#format_compile_units">llvm.dbg.compile_unit2</a> = internal constant %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> {
+ uint add(uint 17, uint 262144),
+ { }* cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_units</a> to { }*),
+ uint 1,
+ uint 1,
+ sbyte* getelementptr ([11 x sbyte]* %str4, int 0, int 0),
+ sbyte* getelementptr ([21 x sbyte]* %str2, int 0, int 0),
+ sbyte* getelementptr ([33 x sbyte]* %str3, int 0, int 0) }, section "llvm.metadata"
+
+ ;;
+ ;; Define each of the strings used in the compile units.
+ ;;
+ %str1 = internal constant [13 x sbyte] c"MySource.cpp\00", section "llvm.metadata";
+ %str2 = internal constant [21 x sbyte] c"/Users/mine/sources/\00", section "llvm.metadata";
+ %str3 = internal constant [33 x sbyte] c"4.0.1 LLVM (LLVM research group)\00", section "llvm.metadata";
+ %str4 = internal constant [11 x sbyte] c"MyHeader.h\00", section "llvm.metadata";
+ ...
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_global_variable">C/C++ global variable information</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Given an integer global variable declared as follows:</p>
+
+ <pre>
+ int MyGlobal = 100;
+ </pre>
+
+ <p>a C/C++ front-end would generate the following descriptors:</p>
+
+ <pre>
+ ;;
+ ;; Define types used. One for global variable anchors, one for the global
+ ;; variable descriptor, one for the global's basic type and one for the global's
+ ;; compile unit.
+ ;;
+ %<a href="#format_anchors">llvm.dbg.anchor.type</a> = type { uint, uint }
+ %<a href="#format_global_variables">llvm.dbg.global_variable.type</a> = type { uint, { }*, { }*, sbyte*, { }*, uint, { }*, bool, bool, { }*, uint }
+ %<a href="#format_basic_type">llvm.dbg.basictype.type</a> = type { uint, { }*, sbyte*, { }*, int, uint, uint, uint, uint }
+ %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> = ...
+ ...
+ ;;
+ ;; Define the global itself.
+ ;;
+ %MyGlobal = global int 100
+ ...
+ ;;
+ ;; Define the anchor for global variables. Note that the second field of the
+ ;; anchor is 52, which is the same as the tag for global variables
+ ;; (52 = DW_TAG_variable.)
+ ;;
+ %<a href="#format_global_variables">llvm.dbg.global_variables</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 52 }, section "llvm.metadata"
+
+ ;;
+ ;; Define the global variable descriptor. Note the reference to the global
+ ;; variable anchor and the global variable itself.
+ ;;
+ %<a href="#format_global_variables">llvm.dbg.global_variable</a> = internal constant %<a href="#format_global_variables">llvm.dbg.global_variable.type</a> {
+ uint add(uint 52, uint 262144),
+ { }* cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_global_variables">llvm.dbg.global_variables</a> to { }*),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([9 x sbyte]* %str1, int 0, int 0),
+ sbyte* getelementptr ([1 x sbyte]* %str2, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ uint 1,
+ { }* cast (%<a href="#format_basic_type">llvm.dbg.basictype.type</a>* %<a href="#format_basic_type">llvm.dbg.basictype</a> to { }*),
+ bool false,
+ bool true,
+ { }* cast (int* %MyGlobal to { }*) }, section "llvm.metadata"
+
+ ;;
+ ;; Define the basic type of 32 bit signed integer. Note that since int is an
+ ;; intrinsic type the source file is NULL and line 0.
+ ;;
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 5 }, section "llvm.metadata"
+
+ ;;
+ ;; Define the names of the global variable and basic type.
+ ;;
+ %str1 = internal constant [9 x sbyte] c"MyGlobal\00", section "llvm.metadata"
+ %str2 = internal constant [1 x sbyte] c"\00", section "llvm.metadata"
+ %str3 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_subprogram">C/C++ function information</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Given a function declared as follows:</p>
+
+ <pre>
+ int main(int argc, char *argv[]) {
+ return 0;
+ }
+ </pre>
+
+ <p>a C/C++ front-end would generate the following descriptors:</p>
+
+ <pre>
+ ;;
+ ;; Define types used. One for subprogram anchors, one for the subprogram
+ ;; descriptor, one for the global's basic type and one for the subprogram's
+ ;; compile unit.
+ ;;
+ %<a href="#format_subprograms">llvm.dbg.subprogram.type</a> = type { uint, { }*, { }*, sbyte*, { }*, bool, bool }
+ %<a href="#format_anchors">llvm.dbg.anchor.type</a> = type { uint, uint }
+ %<a href="#format_compile_units">llvm.dbg.compile_unit.type</a> = ...
+
+ ;;
+ ;; Define the anchor for subprograms. Note that the second field of the
+ ;; anchor is 46, which is the same as the tag for subprograms
+ ;; (46 = DW_TAG_subprogram.)
+ ;;
+ %<a href="#format_subprograms">llvm.dbg.subprograms</a> = linkonce constant %<a href="#format_anchors">llvm.dbg.anchor.type</a> { uint 0, uint 46 }, section "llvm.metadata"
+
+ ;;
+ ;; Define the descriptor for the subprogram. TODO - more details.
+ ;;
+ %<a href="#format_subprograms">llvm.dbg.subprogram</a> = internal constant %<a href="#format_subprograms">llvm.dbg.subprogram.type</a> {
+ uint add(uint 46, uint 262144),
+ { }* cast (%<a href="#format_anchors">llvm.dbg.anchor.type</a>* %<a href="#format_subprograms">llvm.dbg.subprograms</a> to { }*),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0),
+ sbyte* getelementptr ([1 x sbyte]* %str2, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ uint 1,
+ { }* null,
+ bool false,
+ bool true }, section "llvm.metadata"
+
+ ;;
+ ;; Define the name of the subprogram.
+ ;;
+ %str1 = internal constant [5 x sbyte] c"main\00", section "llvm.metadata"
+ %str2 = internal constant [1 x sbyte] c"\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the subprogram itself.
+ ;;
+ int %main(int %argc, sbyte** %argv) {
+ ...
+ }
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_basic_types">C/C++ basic types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The following are the basic type descriptors for C/C++ core types:</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_type_bool">bool</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 2 }, section "llvm.metadata"
+ %str1 = internal constant [5 x sbyte] c"bool\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_char">char</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([5 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 8,
+ uint 8,
+ uint 0,
+ uint 6 }, section "llvm.metadata"
+ %str1 = internal constant [5 x sbyte] c"char\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_unsigned_char">unsigned char</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([14 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 8,
+ uint 8,
+ uint 0,
+ uint 8 }, section "llvm.metadata"
+ %str1 = internal constant [14 x sbyte] c"unsigned char\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_short">short</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([10 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 16,
+ uint 16,
+ uint 0,
+ uint 5 }, section "llvm.metadata"
+ %str1 = internal constant [10 x sbyte] c"short int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_unsigned_short">unsigned short</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([19 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 16,
+ uint 16,
+ uint 0,
+ uint 7 }, section "llvm.metadata"
+ %str1 = internal constant [19 x sbyte] c"short unsigned int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_int">int</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([4 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 5 }, section "llvm.metadata"
+ %str1 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_unsigned_int">unsigned int</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 7 }, section "llvm.metadata"
+ %str1 = internal constant [13 x sbyte] c"unsigned int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_long_long">long long</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([14 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 64,
+ uint 64,
+ uint 0,
+ uint 5 }, section "llvm.metadata"
+ %str1 = internal constant [14 x sbyte] c"long long int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_unsigned_long_long">unsigned long long</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([23 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 64,
+ uint 64,
+ uint 0,
+ uint 7 }, section "llvm.metadata"
+ %str1 = internal constant [23 x sbyte] c"long long unsigned int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_float">float</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([6 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 4 }, section "llvm.metadata"
+ %str1 = internal constant [6 x sbyte] c"float\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsubsection">
+ <a name="ccxx_basic_double">double</a>
+ </div>
+
+ <div class="doc_text">
+
+ <pre>
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([7 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 64,
+ uint 64,
+ uint 0,
+ uint 4 }, section "llvm.metadata"
+ %str1 = internal constant [7 x sbyte] c"double\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_derived_types">C/C++ derived types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Given the following as an example of C/C++ derived type:</p>
+
+ <pre>
+ typedef const int *IntPtr;
+ </pre>
+
+ <p>a C/C++ front-end would generate the following descriptors:</p>
+
+ <pre>
+ ;;
+ ;; Define the typedef "IntPtr".
+ ;;
+ %<a href="#format_derived_type">llvm.dbg.derivedtype1</a> = internal constant %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> {
+ uint add(uint 22, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([7 x sbyte]* %str1, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ int 1,
+ uint 0,
+ uint 0,
+ uint 0,
+ { }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype2</a> to { }*) }, section "llvm.metadata"
+ %str1 = internal constant [7 x sbyte] c"IntPtr\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the pointer type.
+ ;;
+ %<a href="#format_derived_type">llvm.dbg.derivedtype2</a> = internal constant %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> {
+ uint add(uint 15, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* null,
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ { }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype3</a> to { }*) }, section "llvm.metadata"
+
+ ;;
+ ;; Define the const type.
+ ;;
+ %<a href="#format_derived_type">llvm.dbg.derivedtype3</a> = internal constant %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> {
+ uint add(uint 38, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* null,
+ { }* null,
+ int 0,
+ uint 0,
+ uint 0,
+ uint 0,
+ { }* cast (%<a href="#format_basic_type">llvm.dbg.basictype.type</a>* %<a href="#format_basic_type">llvm.dbg.basictype1</a> to { }*) }, section "llvm.metadata"
+
+ ;;
+ ;; Define the int type.
+ ;;
+ %<a href="#format_basic_type">llvm.dbg.basictype1</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([4 x sbyte]* %str2, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 5 }, section "llvm.metadata"
+ %str2 = internal constant [4 x sbyte] c"int\00", section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_composite_types">C/C++ struct/union types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Given the following as an example of C/C++ struct type:</p>
+
+ <pre>
+ struct Color {
+ unsigned Red;
+ unsigned Green;
+ unsigned Blue;
+ };
+ </pre>
+
+ <p>a C/C++ front-end would generate the following descriptors:</p>
+
+ <pre>
+ ;;
+ ;; Define basic type for unsigned int.
+ ;;
+ %<a href="#format_basic_type">llvm.dbg.basictype</a> = internal constant %<a href="#format_basic_type">llvm.dbg.basictype.type</a> {
+ uint add(uint 36, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([13 x sbyte]* %str1, int 0, int 0),
+ { }* null,
+ int 0,
+ uint 32,
+ uint 32,
+ uint 0,
+ uint 7 }, section "llvm.metadata"
+ %str1 = internal constant [13 x sbyte] c"unsigned int\00", section "llvm.metadata"
+
+ ;;
+ ;; Define composite type for struct Color.
+ ;;
+ %<a href="#format_composite_type">llvm.dbg.compositetype</a> = internal constant %<a href="#format_composite_type">llvm.dbg.compositetype.type</a> {
+ uint add(uint 19, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([6 x sbyte]* %str2, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ int 1,
+ uint 96,
+ uint 32,
+ uint 0,
+ { }* null,
+ { }* cast ([3 x { }*]* %llvm.dbg.array to { }*) }, section "llvm.metadata"
+ %str2 = internal constant [6 x sbyte] c"Color\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the Red field.
+ ;;
+ %<a href="#format_derived_type">llvm.dbg.derivedtype1</a> = internal constant %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> {
+ uint add(uint 13, uint 262144),
+ { }* null,
+ sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ int 2,
+ uint 32,
+ uint 32,
+ uint 0,
+ { }* cast (%<a href="#format_basic_type">llvm.dbg.basictype.type</a>* %<a href="#format_basic_type">llvm.dbg.basictype</a> to { }*) }, section "llvm.metadata"
+ %str3 = internal constant [4 x sbyte] c"Red\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the Green field.
+ ;;
+ %<a href="#format_derived_type">llvm.dbg.derivedtype2</a> = internal constant %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> {
+ uint add(uint 13, uint 262144),
+ { }* null,
+ sbyte* getelementptr ([6 x sbyte]* %str4, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ int 3,
+ uint 32,
+ uint 32,
+ uint 32,
+ { }* cast (%<a href="#format_basic_type">llvm.dbg.basictype.type</a>* %<a href="#format_basic_type">llvm.dbg.basictype</a> to { }*) }, section "llvm.metadata"
+ %str4 = internal constant [6 x sbyte] c"Green\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the Blue field.
+ ;;
+ %<a href="#format_derived_type">llvm.dbg.derivedtype3</a> = internal constant %<a href="#format_derived_type">llvm.dbg.derivedtype.type</a> {
+ uint add(uint 13, uint 262144),
+ { }* null,
+ sbyte* getelementptr ([5 x sbyte]* %str5, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ int 4,
+ uint 32,
+ uint 32,
+ uint 64,
+ { }* cast (%<a href="#format_basic_type">llvm.dbg.basictype.type</a>* %<a href="#format_basic_type">llvm.dbg.basictype</a> to { }*) }, section "llvm.metadata"
+ %str5 = internal constant [5 x sbyte] c"Blue\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the array of fields used by the composite type Color.
+ ;;
+ %llvm.dbg.array = internal constant [3 x { }*] [
+ { }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype1</a> to { }*),
+ { }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype2</a> to { }*),
+ { }* cast (%<a href="#format_derived_type">llvm.dbg.derivedtype.type</a>* %<a href="#format_derived_type">llvm.dbg.derivedtype3</a> to { }*) ], section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ccxx_enumeration_types">C/C++ enumeration types</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Given the following as an example of C/C++ enumeration type:</p>
+
+ <pre>
+ enum Trees {
+ Spruce = 100,
+ Oak = 200,
+ Maple = 300
+ };
+ </pre>
+
+ <p>a C/C++ front-end would generate the following descriptors:</p>
+
+ <pre>
+ ;;
+ ;; Define composite type for enum Trees
+ ;;
+ %<a href="#format_composite_type">llvm.dbg.compositetype</a> = internal constant %<a href="#format_composite_type">llvm.dbg.compositetype.type</a> {
+ uint add(uint 4, uint 262144),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ sbyte* getelementptr ([6 x sbyte]* %str1, int 0, int 0),
+ { }* cast (%<a href="#format_compile_units">llvm.dbg.compile_unit.type</a>* %<a href="#format_compile_units">llvm.dbg.compile_unit</a> to { }*),
+ int 1,
+ uint 32,
+ uint 32,
+ uint 0,
+ { }* null,
+ { }* cast ([3 x { }*]* %llvm.dbg.array to { }*) }, section "llvm.metadata"
+ %str1 = internal constant [6 x sbyte] c"Trees\00", section "llvm.metadata"
+
+ ;;
+ ;; Define Spruce enumerator.
+ ;;
+ %<a href="#format_enumeration">llvm.dbg.enumerator1</a> = internal constant %<a href="#format_enumeration">llvm.dbg.enumerator.type</a> {
+ uint add(uint 40, uint 262144),
+ sbyte* getelementptr ([7 x sbyte]* %str2, int 0, int 0),
+ int 100 }, section "llvm.metadata"
+ %str2 = internal constant [7 x sbyte] c"Spruce\00", section "llvm.metadata"
+
+ ;;
+ ;; Define Oak enumerator.
+ ;;
+ %<a href="#format_enumeration">llvm.dbg.enumerator2</a> = internal constant %<a href="#format_enumeration">llvm.dbg.enumerator.type</a> {
+ uint add(uint 40, uint 262144),
+ sbyte* getelementptr ([4 x sbyte]* %str3, int 0, int 0),
+ int 200 }, section "llvm.metadata"
+ %str3 = internal constant [4 x sbyte] c"Oak\00", section "llvm.metadata"
+
+ ;;
+ ;; Define Maple enumerator.
+ ;;
+ %<a href="#format_enumeration">llvm.dbg.enumerator3</a> = internal constant %<a href="#format_enumeration">llvm.dbg.enumerator.type</a> {
+ uint add(uint 40, uint 262144),
+ sbyte* getelementptr ([6 x sbyte]* %str4, int 0, int 0),
+ int 300 }, section "llvm.metadata"
+ %str4 = internal constant [6 x sbyte] c"Maple\00", section "llvm.metadata"
+
+ ;;
+ ;; Define the array of enumerators used by composite type Trees.
+ ;;
+ %llvm.dbg.array = internal constant [3 x { }*] [
+ { }* cast (%<a href="#format_enumeration">llvm.dbg.enumerator.type</a>* %<a href="#format_enumeration">llvm.dbg.enumerator1</a> to { }*),
+ { }* cast (%<a href="#format_enumeration">llvm.dbg.enumerator.type</a>* %<a href="#format_enumeration">llvm.dbg.enumerator2</a> to { }*),
+ { }* cast (%<a href="#format_enumeration">llvm.dbg.enumerator.type</a>* %<a href="#format_enumeration">llvm.dbg.enumerator3</a> to { }*) ], section "llvm.metadata"
+ </pre>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/SystemLibrary.html
diff -c /dev/null llvm-www/releases/2.5/docs/SystemLibrary.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/SystemLibrary.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,344 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>System Library</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">System Library</div>
+ <ul>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#requirements">Keeping LLVM Portable</a>
+ <ol>
+ <li><a href="#headers">Don't Include System Headers</a></li>
+ <li><a href="#expose">Don't Expose System Headers</a></li>
+ <li><a href="#c_headers">Allow Standard C Header Files</a></li>
+ <li><a href="#cpp_headers">Allow Standard C++ Header Files</a></li>
+ <li><a href="#highlev">High-Level Interface</a></li>
+ <li><a href="#nofunc">No Exposed Functions</a></li>
+ <li><a href="#nodata">No Exposed Data</a></li>
+ <li><a href="#nodupl">No Duplicate Implementations</a></li>
+ <li><a href="#nounused">No Unused Functionality</a></li>
+ <li><a href="#virtuals">No Virtual Methods</a></li>
+ <li><a href="#softerrors">Minimize Soft Errors</a></li>
+ <li><a href="#throw">Throw Only std::string</a></li>
+ <li><a href="#throw_spec">No throw() Specifications</a></li>
+ <li><a href="#organization">Code Organization</a></li>
+ <li><a href="#semantics">Consistent Semantics</a></li>
+ <li><a href="#bug">Tracking Bugzilla Bug: 351</a></li>
+ </ol></li>
+ </ul>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a></p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="abstract">Abstract</a></div>
+ <div class="doc_text">
+ <p>This document provides some details on LLVM's System Library, located in
+ the source at <tt>lib/System</tt> and <tt>include/llvm/System</tt>. The
+ library's purpose is to shield LLVM from the differences between operating
+ systems for the few services LLVM needs from the operating system. Much of
+ LLVM is written using portability features of standard C++. However, in a few
+ areas, system dependent facilities are needed and the System Library is the
+ wrapper around those system calls.</p>
+ <p>By centralizing LLVM's use of operating system interfaces, we make it
+ possible for the LLVM tool chain and runtime libraries to be more easily
+ ported to new platforms since (theoretically) only <tt>lib/System</tt> needs
+ to be ported. This library also unclutters the rest of LLVM from #ifdef use
+ and special cases for specific operating systems. Such uses are replaced
+ with simple calls to the interfaces provided in <tt>include/llvm/System</tt>.
+ </p>
+ <p>Note that the System Library is not intended to be a complete operating
+ system wrapper (such as the Adaptive Communications Environment (ACE) or
+ Apache Portable Runtime (APR)), but only provides the functionality necessary
+ to support LLVM.
+ <p>The System Library was written by Reid Spencer who formulated the
+ design based on similar work originating from the eXtensible Programming
+ System (XPS). Several people helped with the effort; especially,
+ Jeff Cohen and Henrik Bach on the Win32 port.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="requirements">Keeping LLVM Portable</a>
+ </div>
+ <div class="doc_text">
+ <p>In order to keep LLVM portable, LLVM developers should adhere to a set of
+ portability rules associated with the System Library. Adherence to these rules
+ should help the System Library achieve its goal of shielding LLVM from the
+ variations in operating system interfaces and doing so efficiently. The
+ following sections define the rules needed to fulfill this objective.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="headers">Don't Inlcude System Headers</a>
+ </div>
+ <div class="doc_text">
+ <p>Except in <tt>lib/System</tt>, no LLVM source code should directly
+ <tt>#include</tt> a system header. Care has been taken to remove all such
+ <tt>#includes</tt> from LLVM while <tt>lib/System</tt> was being
+ developed. Specifically this means that header files like "unistd.h",
+ "windows.h", "stdio.h", and "string.h" are forbidden to be included by LLVM
+ source code outside the implementation of <tt>lib/System</tt>.</p>
+ <p>To obtain system-dependent functionality, existing interfaces to the system
+ found in <tt>include/llvm/System</tt> should be used. If an appropriate
+ interface is not available, it should be added to <tt>include/llvm/System</tt>
+ and implemented in <tt>lib/System</tt> for all supported platforms.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="expose">Don't Expose System Headers</a>
+ </div>
+ <div class="doc_text">
+ <p>The System Library must shield LLVM from <em>all</em> system headers. To
+ obtain system level functionality, LLVM source must
+ <tt>#include "llvm/System/Thing.h"</tt> and nothing else. This means that
+ <tt>Thing.h</tt> cannot expose any system header files. This protects LLVM
+ from accidentally using system specific functionality and only allows it
+ via the <tt>lib/System</tt> interface.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="c_headers">Use Standard C Headers</a></div>
+ <div class="doc_text">
+ <p>The <em>standard</em> C headers (the ones beginning with "c") are allowed
+ to be exposed through the <tt>lib/System</tt> interface. These headers and
+ the things they declare are considered to be platform agnostic. LLVM source
+ files may include them directly or obtain their inclusion through
+ <tt>lib/System</tt> interfaces.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="cpp_headers">Use Standard C++ Headers</a>
+ </div>
+ <div class="doc_text">
+ <p>The <em>standard</em> C++ headers from the standard C++ library and
+ standard template library may be exposed through the <tt>lib/System</tt>
+ interface. These headers and the things they declare are considered to be
+ platform agnostic. LLVM source files may include them or obtain their
+ inclusion through lib/System interfaces.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="highlev">High Level Interface</a></div>
+ <div class="doc_text">
+ <p>The entry points specified in the interface of lib/System must be aimed at
+ completing some reasonably high level task needed by LLVM. We do not want to
+ simply wrap each operating system call. It would be preferable to wrap several
+ operating system calls that are always used in conjunction with one another by
+ LLVM.</p>
+ <p>For example, consider what is needed to execute a program, wait for it to
+ complete, and return its result code. On Unix, this involves the following
+ operating system calls: <tt>getenv, fork, execve,</tt> and <tt>wait</tt>. The
+ correct thing for lib/System to provide is a function, say
+ <tt>ExecuteProgramAndWait</tt>, that implements the functionality completely.
+ what we don't want is wrappers for the operating system calls involved.</p>
+ <p>There must <em>not</em> be a one-to-one relationship between operating
+ system calls and the System library's interface. Any such interface function
+ will be suspicious.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="nounused">No Unused Functionality</a></div>
+ <div class="doc_text">
+ <p>There must be no functionality specified in the interface of lib/System
+ that isn't actually used by LLVM. We're not writing a general purpose
+ operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM
+ doesn't need much. This design goal aims to keep the lib/System interface
+ small and understandable which should foster its actual use and adoption.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="nodupl">No Duplicate Implementations</a>
+ </div>
+ <div class="doc_text">
+ <p>The implementation of a function for a given platform must be written
+ exactly once. This implies that it must be possible to apply a function's
+ implementation to multiple operating systems if those operating systems can
+ share the same implementation. This rule applies to the set of operating
+ systems supported for a given class of operating system (e.g. Unix, Win32).
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="virtuals">No Virtual Methods</a></div>
+ <div class="doc_text">
+ <p>The System Library interfaces can be called quite frequently by LLVM. In
+ order to make those calls as efficient as possible, we discourage the use of
+ virtual methods. There is no need to use inheritance for implementation
+ differences, it just adds complexity. The <tt>#include</tt> mechanism works
+ just fine.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="nofunc">No Exposed Functions</a></div>
+ <div class="doc_text">
+ <p>Any functions defined by system libraries (i.e. not defined by lib/System)
+ must not be exposed through the lib/System interface, even if the header file
+ for that function is not exposed. This prevents inadvertent use of system
+ specific functionality.</p>
+ <p>For example, the <tt>stat</tt> system call is notorious for having
+ variations in the data it provides. <tt>lib/System</tt> must not declare
+ <tt>stat</tt> nor allow it to be declared. Instead it should provide its own
+ interface to discovering information about files and directories. Those
+ interfaces may be implemented in terms of <tt>stat</tt> but that is strictly
+ an implementation detail. The interface provided by the System Library must
+ be implemented on all platforms (even those without <tt>stat</tt>).</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="nodata">No Exposed Data</a></div>
+ <div class="doc_text">
+ <p>Any data defined by system libraries (i.e. not defined by lib/System) must
+ not be exposed through the lib/System interface, even if the header file for
+ that function is not exposed. As with functions, this prevents inadvertent use
+ of data that might not exist on all platforms.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="softerrors">Minimize Soft Errors</a></div>
+ <div class="doc_text">
+ <p>Operating system interfaces will generally provide error results for every
+ little thing that could go wrong. In almost all cases, you can divide these
+ error results into two groups: normal/good/soft and abnormal/bad/hard. That
+ is, some of the errors are simply information like "file not found",
+ "insufficient privileges", etc. while other errors are much harder like
+ "out of space", "bad disk sector", or "system call interrupted". We'll call
+ the first group "<i>soft</i>" errors and the second group "<i>hard</i>"
+ errors.<p>
+ <p>lib/System must always attempt to minimize soft errors and always just
+ throw a std::string on hard errors. This is a design requirement because the
+ minimization of soft errors can affect the granularity and the nature of the
+ interface. In general, if you find that you're wanting to throw soft errors,
+ you must review the granularity of the interface because it is likely you're
+ trying to implement something that is too low level. The rule of thumb is to
+ provide interface functions that <em>can't</em> fail, except when faced with
+ hard errors.</p>
+ <p>For a trivial example, suppose we wanted to add an "OpenFileForWriting"
+ function. For many operating systems, if the file doesn't exist, attempting
+ to open the file will produce an error. However, lib/System should not
+ simply throw that error if it occurs because its a soft error. The problem
+ is that the interface function, OpenFileForWriting is too low level. It should
+ be OpenOrCreateFileForWriting. In the case of the soft "doesn't exist" error,
+ this function would just create it and then open it for writing.</p>
+ <p>This design principle needs to be maintained in lib/System because it
+ avoids the propagation of soft error handling throughout the rest of LLVM.
+ Hard errors will generally just cause a termination for an LLVM tool so don't
+ be bashful about throwing them.</p>
+ <p>Rules of thumb:</p>
+ <ol>
+ <li>Don't throw soft errors, only hard errors.</li>
+ <li>If you're tempted to throw a soft error, re-think the interface.</li>
+ <li>Handle internally the most common normal/good/soft error conditions
+ so the rest of LLVM doesn't have to.</li>
+ </ol>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="throw">Throw Only std::string</a></div>
+ <div class="doc_text">
+ <p>If an error occurs that lib/System cannot handle, the only action taken by
+ lib/System is to throw an instance of std:string. The contents of the string
+ must explain both what happened and the context in which it happened. The
+ format of the string should be a (possibly empty) list of contexts each
+ terminated with a : and a space, followed by the error message, optionally
+ followed by a reason, and optionally followed by a suggestion.</p>
+ <p>For example, failure to open a file named "foo" could result in a message
+ like:</p>
+ <ul><li>foo: Unable to open file because it doesn't exist."</li></ul>
+ <p>The "foo:" part is the context. The "Unable to open file" part is the error
+ message. The "because it doesn't exist." part is the reason. This message has
+ no suggestion. Where possible, the implementation of lib/System should use
+ operating system specific facilities for converting the error code returned by
+ a system call into an error message. This will help to make the error message
+ more familiar to users of that type of operating system.</p>
+ <p>Note that this requirement precludes the throwing of any other exceptions.
+ For example, various C++ standard library functions can cause exceptions to be
+ thrown (e.g. out of memory situation). In all cases, if there is a possibility
+ that non-string exceptions could be thrown, the lib/System library must ensure
+ that the exceptions are translated to std::string form.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="throw_spec">No throw Specifications</a>
+ </div>
+ <div class="doc_text">
+ <p>None of the lib/System interface functions may be declared with C++
+ <tt>throw()</tt> specifications on them. This requirement makes sure that the
+ compiler does not insert additional exception handling code into the interface
+ functions. This is a performance consideration: lib/System functions are at
+ the bottom of many call chains and as such can be frequently called. We
+ need them to be as efficient as possible.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="organization">Code Organization</a></div>
+ <div class="doc_text">
+ <p>Implementations of the System Library interface are separated by their
+ general class of operating system. Currently only Unix and Win32 classes are
+ defined but more could be added for other operating system classifications.
+ To distinguish which implementation to compile, the code in lib/System uses
+ the LLVM_ON_UNIX and LLVM_ON_WIN32 #defines provided via configure through the
+ llvm/Config/config.h file. Each source file in lib/System, after implementing
+ the generic (operating system independent) functionality needs to include the
+ correct implementation using a set of <tt>#if defined(LLVM_ON_XYZ)</tt>
+ directives. For example, if we had lib/System/File.cpp, we'd expect to see in
+ that file:</p>
+ <pre><tt>
+ #if defined(LLVM_ON_UNIX)
+ #include "Unix/File.cpp"
+ #endif
+ #if defined(LLVM_ON_WIN32)
+ #include "Win32/File.cpp"
+ #endif
+ </tt></pre>
+ <p>The implementation in lib/System/Unix/File.cpp should handle all Unix
+ variants. The implementation in lib/System/Win32/File.cpp should handle all
+ Win32 variants. What this does is quickly differentiate the basic class of
+ operating system that will provide the implementation. The specific details
+ for a given platform must still be determined through the use of
+ <tt>#ifdef</tt>.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="semantics">Consistent Semantics</a></div>
+ <div class="doc_text">
+ <p>The implementation of a lib/System interface can vary drastically between
+ platforms. That's okay as long as the end result of the interface function
+ is the same. For example, a function to create a directory is pretty straight
+ forward on all operating system. System V IPC on the other hand isn't even
+ supported on all platforms. Instead of "supporting" System V IPC, lib/System
+ should provide an interface to the basic concept of inter-process
+ communications. The implementations might use System V IPC if that was
+ available or named pipes, or whatever gets the job done effectively for a
+ given operating system. In all cases, the interface and the implementation
+ must be semantically consistent. </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="bug">Bug 351</a></div>
+ <div class="doc_text">
+ <p>See <a href="http://llvm.org/PR351">bug 351</a>
+ for further details on the progress of this work</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:rspencer at x10sys.com">Reid Spencer</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/TableGenFundamentals.html
diff -c /dev/null llvm-www/releases/2.5/docs/TableGenFundamentals.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/TableGenFundamentals.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,753 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>TableGen Fundamentals</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">TableGen Fundamentals</div>
+
+ <div class="doc_text">
+ <ul>
+ <li><a href="#introduction">Introduction</a>
+ <ol>
+ <li><a href="#concepts">Basic concepts</a></li>
+ <li><a href="#example">An example record</a></li>
+ <li><a href="#running">Running TableGen</a></li>
+ </ol></li>
+ <li><a href="#syntax">TableGen syntax</a>
+ <ol>
+ <li><a href="#primitives">TableGen primitives</a>
+ <ol>
+ <li><a href="#comments">TableGen comments</a></li>
+ <li><a href="#types">The TableGen type system</a></li>
+ <li><a href="#values">TableGen values and expressions</a></li>
+ </ol></li>
+ <li><a href="#classesdefs">Classes and definitions</a>
+ <ol>
+ <li><a href="#valuedef">Value definitions</a></li>
+ <li><a href="#recordlet">'let' expressions</a></li>
+ <li><a href="#templateargs">Class template arguments</a></li>
+ <li><a href="#multiclass">Multiclass definitions and instances</a></li>
+ </ol></li>
+ <li><a href="#filescope">File scope entities</a>
+ <ol>
+ <li><a href="#include">File inclusion</a></li>
+ <li><a href="#globallet">'let' expressions</a></li>
+ </ol></li>
+ </ol></li>
+ <li><a href="#backends">TableGen backends</a>
+ <ol>
+ <li><a href="#">todo</a></li>
+ </ol></li>
+ </ul>
+ </div>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="introduction">Introduction</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>TableGen's purpose is to help a human develop and maintain records of
+ domain-specific information. Because there may be a large number of these
+ records, it is specifically designed to allow writing flexible descriptions and
+ for common features of these records to be factored out. This reduces the
+ amount of duplication in the description, reduces the chance of error, and
+ makes it easier to structure domain specific information.</p>
+
+ <p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
+ the declarations, and hands the result off to a domain-specific "<a
+ href="#backends">TableGen backend</a>" for processing. The current major user
+ of TableGen is the <a href="CodeGenerator.html">LLVM code generator</a>.</p>
+
+ <p>Note that if you work on TableGen much, and use emacs or vim, that you can
+ find an emacs "TableGen mode" and a vim language file in the
+ <tt>llvm/utils/emacs</tt> and <tt>llvm/utils/vim</tt> directories of your LLVM
+ distribution, respectively.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="concepts">Basic concepts</a></div>
+
+ <div class="doc_text">
+
+ <p>TableGen files consist of two key parts: 'classes' and 'definitions', both
+ of which are considered 'records'.</p>
+
+ <p><b>TableGen records</b> have a unique name, a list of values, and a list of
+ superclasses. The list of values is the main data that TableGen builds for each
+ record; it is this that holds the domain specific information for the
+ application. The interpretation of this data is left to a specific <a
+ href="#backends">TableGen backend</a>, but the structure and format rules are
+ taken care of and are fixed by TableGen.</p>
+
+ <p><b>TableGen definitions</b> are the concrete form of 'records'. These
+ generally do not have any undefined values, and are marked with the
+ '<tt>def</tt>' keyword.</p>
+
+ <p><b>TableGen classes</b> are abstract records that are used to build and
+ describe other records. These 'classes' allow the end-user to build
+ abstractions for either the domain they are targeting (such as "Register",
+ "RegisterClass", and "Instruction" in the LLVM code generator) or for the
+ implementor to help factor out common properties of records (such as "FPInst",
+ which is used to represent floating point instructions in the X86 backend).
+ TableGen keeps track of all of the classes that are used to build up a
+ definition, so the backend can find all definitions of a particular class, such
+ as "Instruction".</p>
+
+ <p><b>TableGen multiclasses</b> are groups of abstract records that are
+ instantiated all at once. Each instantiation can result in multiple TableGen
+ definitions.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="example">An example record</a></div>
+
+ <div class="doc_text">
+
+ <p>With no other arguments, TableGen parses the specified file and prints out
+ all of the classes, then all of the definitions. This is a good way to see what
+ the various definitions expand to fully. Running this on the <tt>X86.td</tt>
+ file prints this (at the time of this writing):</p>
+
+ <div class="doc_code">
+ <pre>
+ ...
+ <b>def</b> ADD32rr { <i>// Instruction X86Inst I</i>
+ <b>string</b> Namespace = "X86";
+ <b>dag</b> OutOperandList = (outs GR32:$dst);
+ <b>dag</b> InOperandList = (ins GR32:$src1, GR32:$src2);
+ <b>string</b> AsmString = "add{l}\t{$src2, $dst|$dst, $src2}";
+ <b>list</b><dag> Pattern = [(set GR32:$dst, (add GR32:$src1, GR32:$src2))];
+ <b>list</b><Register> Uses = [];
+ <b>list</b><Register> Defs = [EFLAGS];
+ <b>list</b><Predicate> Predicates = [];
+ <b>int</b> CodeSize = 3;
+ <b>int</b> AddedComplexity = 0;
+ <b>bit</b> isReturn = 0;
+ <b>bit</b> isBranch = 0;
+ <b>bit</b> isIndirectBranch = 0;
+ <b>bit</b> isBarrier = 0;
+ <b>bit</b> isCall = 0;
+ <b>bit</b> canFoldAsLoad = 0;
+ <b>bit</b> mayLoad = 0;
+ <b>bit</b> mayStore = 0;
+ <b>bit</b> isImplicitDef = 0;
+ <b>bit</b> isTwoAddress = 1;
+ <b>bit</b> isConvertibleToThreeAddress = 1;
+ <b>bit</b> isCommutable = 1;
+ <b>bit</b> isTerminator = 0;
+ <b>bit</b> isReMaterializable = 0;
+ <b>bit</b> isPredicable = 0;
+ <b>bit</b> hasDelaySlot = 0;
+ <b>bit</b> usesCustomDAGSchedInserter = 0;
+ <b>bit</b> hasCtrlDep = 0;
+ <b>bit</b> isNotDuplicable = 0;
+ <b>bit</b> hasSideEffects = 0;
+ <b>bit</b> mayHaveSideEffects = 0;
+ <b>bit</b> neverHasSideEffects = 0;
+ InstrItinClass Itinerary = NoItinerary;
+ <b>string</b> Constraints = "";
+ <b>string</b> DisableEncoding = "";
+ <b>bits</b><8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 1 };
+ Format Form = MRMDestReg;
+ <b>bits</b><6> FormBits = { 0, 0, 0, 0, 1, 1 };
+ ImmType ImmT = NoImm;
+ <b>bits</b><3> ImmTypeBits = { 0, 0, 0 };
+ <b>bit</b> hasOpSizePrefix = 0;
+ <b>bit</b> hasAdSizePrefix = 0;
+ <b>bits</b><4> Prefix = { 0, 0, 0, 0 };
+ <b>bit</b> hasREX_WPrefix = 0;
+ FPFormat FPForm = ?;
+ <b>bits</b><3> FPFormBits = { 0, 0, 0 };
+ }
+ ...
+ </pre>
+ </div>
+
+ <p>This definition corresponds to a 32-bit register-register add instruction in
+ the X86. The string after the '<tt>def</tt>' string indicates the name of the
+ record—"<tt>ADD32rr</tt>" in this case—and the comment at the end of
+ the line indicates the superclasses of the definition. The body of the record
+ contains all of the data that TableGen assembled for the record, indicating that
+ the instruction is part of the "X86" namespace, the pattern indicating how the
+ the instruction should be emitted into the assembly file, that it is a
+ two-address instruction, has a particular encoding, etc. The contents and
+ semantics of the information in the record is specific to the needs of the X86
+ backend, and is only shown as an example.</p>
+
+ <p>As you can see, a lot of information is needed for every instruction
+ supported by the code generator, and specifying it all manually would be
+ unmaintainble, prone to bugs, and tiring to do in the first place. Because we
+ are using TableGen, all of the information was derived from the following
+ definition:</p>
+
+ <div class="doc_code">
+ <pre>
+ let Defs = [EFLAGS],
+ isCommutable = 1, <i>// X = ADD Y,Z --> X = ADD Z,Y</i>
+ isConvertibleToThreeAddress = 1 <b>in</b> <i>// Can transform into LEA.</i>
+ def ADD32rr : I<0x01, MRMDestReg, (outs GR32:$dst),
+ (ins GR32:$src1, GR32:$src2),
+ "add{l}\t{$src2, $dst|$dst, $src2}",
+ [(set GR32:$dst, (add GR32:$src1, GR32:$src2))]>;
+ </pre>
+ </div>
+
+ <p>This definition makes use of the custom class <tt>I</tt> (extended from the
+ custom class <tt>X86Inst</tt>), which is defined in the X86-specific TableGen
+ file, to factor out the common features that instructions of its class share. A
+ key feature of TableGen is that it allows the end-user to define the
+ abstractions they prefer to use when describing their information.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="running">Running TableGen</a></div>
+
+ <div class="doc_text">
+
+ <p>TableGen runs just like any other LLVM tool. The first (optional) argument
+ specifies the file to read. If a filename is not specified, <tt>tblgen</tt>
+ reads from standard input.</p>
+
+ <p>To be useful, one of the <a href="#backends">TableGen backends</a> must be
+ used. These backends are selectable on the command line (type '<tt>tblgen
+ -help</tt>' for a list). For example, to get a list of all of the definitions
+ that subclass a particular type (which can be useful for building up an enum
+ list of these records), use the <tt>-print-enums</tt> option:</p>
+
+ <div class="doc_code">
+ <pre>
+ $ tblgen X86.td -print-enums -class=Register
+ AH, AL, AX, BH, BL, BP, BPL, BX, CH, CL, CX, DH, DI, DIL, DL, DX, EAX, EBP, EBX,
+ ECX, EDI, EDX, EFLAGS, EIP, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6, IP,
+ MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7, R10, R10B, R10D, R10W, R11, R11B, R11D,
+ R11W, R12, R12B, R12D, R12W, R13, R13B, R13D, R13W, R14, R14B, R14D, R14W, R15,
+ R15B, R15D, R15W, R8, R8B, R8D, R8W, R9, R9B, R9D, R9W, RAX, RBP, RBX, RCX, RDI,
+ RDX, RIP, RSI, RSP, SI, SIL, SP, SPL, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
+ XMM0, XMM1, XMM10, XMM11, XMM12, XMM13, XMM14, XMM15, XMM2, XMM3, XMM4, XMM5,
+ XMM6, XMM7, XMM8, XMM9,
+
+ $ tblgen X86.td -print-enums -class=Instruction
+ ABS_F, ABS_Fp32, ABS_Fp64, ABS_Fp80, ADC32mi, ADC32mi8, ADC32mr, ADC32ri,
+ ADC32ri8, ADC32rm, ADC32rr, ADC64mi32, ADC64mi8, ADC64mr, ADC64ri32, ADC64ri8,
+ ADC64rm, ADC64rr, ADD16mi, ADD16mi8, ADD16mr, ADD16ri, ADD16ri8, ADD16rm,
+ ADD16rr, ADD32mi, ADD32mi8, ADD32mr, ADD32ri, ADD32ri8, ADD32rm, ADD32rr,
+ ADD64mi32, ADD64mi8, ADD64mr, ADD64ri32, ...
+ </pre>
+ </div>
+
+ <p>The default backend prints out all of the records, as described <a
+ href="#example">above</a>.</p>
+
+ <p>If you plan to use TableGen, you will most likely have to <a
+ href="#backends">write a backend</a> that extracts the information specific to
+ what you need and formats it in the appropriate way.</p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="syntax">TableGen syntax</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>TableGen doesn't care about the meaning of data (that is up to the backend to
+ define), but it does care about syntax, and it enforces a simple type system.
+ This section describes the syntax and the constructs allowed in a TableGen file.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="primitives">TableGen primitives</a></div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection"><a name="comments">TableGen comments</a></div>
+
+ <div class="doc_text">
+
+ <p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
+ the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
+
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="types">The TableGen type system</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>TableGen files are strongly typed, in a simple (but complete) type-system.
+ These types are used to perform automatic conversions, check for errors, and to
+ help interface designers constrain the input that they allow. Every <a
+ href="#valuedef">value definition</a> is required to have an associated type.
+ </p>
+
+ <p>TableGen supports a mixture of very low-level types (such as <tt>bit</tt>)
+ and very high-level types (such as <tt>dag</tt>). This flexibility is what
+ allows it to describe a wide range of information conveniently and compactly.
+ The TableGen types are:</p>
+
+ <dl>
+ <dt><tt><b>bit</b></tt></dt>
+ <dd>A 'bit' is a boolean value that can hold either 0 or 1.</dd>
+
+ <dt><tt><b>int</b></tt></dt>
+ <dd>The 'int' type represents a simple 32-bit integer value, such as 5.</dd>
+
+ <dt><tt><b>string</b></tt></dt>
+ <dd>The 'string' type represents an ordered sequence of characters of
+ arbitrary length.</dd>
+
+ <dt><tt><b>bits</b><n></tt></dt>
+ <dd>A 'bits' type is an arbitrary, but fixed, size integer that is broken up
+ into individual bits. This type is useful because it can handle some bits
+ being defined while others are undefined.</dd>
+
+ <dt><tt><b>list</b><ty></tt></dt>
+ <dd>This type represents a list whose elements are some other type. The
+ contained type is arbitrary: it can even be another list type.</dd>
+
+ <dt>Class type</dt>
+ <dd>Specifying a class name in a type context means that the defined value
+ must be a subclass of the specified class. This is useful in conjunction with
+ the <b><tt>list</tt></b> type, for example, to constrain the elements of the
+ list to a common base class (e.g., a <tt><b>list</b><Register></tt> can
+ only contain definitions derived from the "<tt>Register</tt>" class).</dd>
+
+ <dt><tt><b>dag</b></tt></dt>
+ <dd>This type represents a nestable directed graph of elements.</dd>
+
+ <dt><tt><b>code</b></tt></dt>
+ <dd>This represents a big hunk of text. NOTE: I don't remember why this is
+ distinct from string!</dd>
+ </dl>
+
+ <p>To date, these types have been sufficient for describing things that
+ TableGen has been used for, but it is straight-forward to extend this list if
+ needed.</p>
+
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="values">TableGen values and expressions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>TableGen allows for a pretty reasonable number of different expression forms
+ when building up values. These forms allow the TableGen file to be written in a
+ natural syntax and flavor for the application. The current expression forms
+ supported include:</p>
+
+ <dl>
+ <dt><tt>?</tt></dt>
+ <dd>uninitialized field</dd>
+ <dt><tt>0b1001011</tt></dt>
+ <dd>binary integer value</dd>
+ <dt><tt>07654321</tt></dt>
+ <dd>octal integer value (indicated by a leading 0)</dd>
+ <dt><tt>7</tt></dt>
+ <dd>decimal integer value</dd>
+ <dt><tt>0x7F</tt></dt>
+ <dd>hexadecimal integer value</dd>
+ <dt><tt>"foo"</tt></dt>
+ <dd>string value</dd>
+ <dt><tt>[{ ... }]</tt></dt>
+ <dd>code fragment</dd>
+ <dt><tt>[ X, Y, Z ]</tt></dt>
+ <dd>list value.</dd>
+ <dt><tt>{ a, b, c }</tt></dt>
+ <dd>initializer for a "bits<3>" value</dd>
+ <dt><tt>value</tt></dt>
+ <dd>value reference</dd>
+ <dt><tt>value{17}</tt></dt>
+ <dd>access to one bit of a value</dd>
+ <dt><tt>value{15-17}</tt></dt>
+ <dd>access to multiple bits of a value</dd>
+ <dt><tt>DEF</tt></dt>
+ <dd>reference to a record definition</dd>
+ <dt><tt>CLASS<val list></tt></dt>
+ <dd>reference to a new anonymous definition of CLASS with the specified
+ template arguments.</dd>
+ <dt><tt>X.Y</tt></dt>
+ <dd>reference to the subfield of a value</dd>
+ <dt><tt>list[4-7,17,2-3]</tt></dt>
+ <dd>A slice of the 'list' list, including elements 4,5,6,7,17,2, and 3 from
+ it. Elements may be included multiple times.</dd>
+ <dt><tt>(DEF a, b)</tt></dt>
+ <dd>a dag value. The first element is required to be a record definition, the
+ remaining elements in the list may be arbitrary other values, including nested
+ `<tt>dag</tt>' values.</dd>
+ <dt><tt>!strconcat(a, b)</tt></dt>
+ <dd>A string value that is the result of concatenating the 'a' and 'b'
+ strings.</dd>
+ </dl>
+
+ <p>Note that all of the values have rules specifying how they convert to values
+ for different types. These rules allow you to assign a value like "<tt>7</tt>"
+ to a "<tt>bits<4></tt>" value, for example.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="classesdefs">Classes and definitions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>As mentioned in the <a href="#concepts">intro</a>, classes and definitions
+ (collectively known as 'records') in TableGen are the main high-level unit of
+ information that TableGen collects. Records are defined with a <tt>def</tt> or
+ <tt>class</tt> keyword, the record name, and an optional list of "<a
+ href="#templateargs">template arguments</a>". If the record has superclasses,
+ they are specified as a comma separated list that starts with a colon character
+ ("<tt>:</tt>"). If <a href="#valuedef">value definitions</a> or <a
+ href="#recordlet">let expressions</a> are needed for the class, they are
+ enclosed in curly braces ("<tt>{}</tt>"); otherwise, the record ends with a
+ semicolon.</p>
+
+ <p>Here is a simple TableGen file:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>class</b> C { <b>bit</b> V = 1; }
+ <b>def</b> X : C;
+ <b>def</b> Y : C {
+ <b>string</b> Greeting = "hello";
+ }
+ </pre>
+ </div>
+
+ <p>This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of
+ which derive from the <tt>C</tt> class. Because of this, they both get the
+ <tt>V</tt> bit value. The <tt>Y</tt> definition also gets the Greeting member
+ as well.</p>
+
+ <p>In general, classes are useful for collecting together the commonality
+ between a group of records and isolating it in a single place. Also, classes
+ permit the specification of default values for their subclasses, allowing the
+ subclasses to override them as they wish.</p>
+
+ </div>
+
+ <!---------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="valuedef">Value definitions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Value definitions define named entries in records. A value must be defined
+ before it can be referred to as the operand for another value definition or
+ before the value is reset with a <a href="#recordlet">let expression</a>. A
+ value is defined by specifying a <a href="#types">TableGen type</a> and a name.
+ If an initial value is available, it may be specified after the type with an
+ equal sign. Value definitions require terminating semicolons.</p>
+
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="recordlet">'let' expressions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>A record-level let expression is used to change the value of a value
+ definition in a record. This is primarily useful when a superclass defines a
+ value that a derived class or definition wants to override. Let expressions
+ consist of the '<tt>let</tt>' keyword followed by a value name, an equal sign
+ ("<tt>=</tt>"), and a new value. For example, a new class could be added to the
+ example above, redefining the <tt>V</tt> field for all of its subclasses:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>class</b> D : C { let V = 0; }
+ <b>def</b> Z : D;
+ </pre>
+ </div>
+
+ <p>In this case, the <tt>Z</tt> definition will have a zero value for its "V"
+ value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
+ because the <tt>D</tt> class overrode its value.</p>
+
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="templateargs">Class template arguments</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>TableGen permits the definition of parameterized classes as well as normal
+ concrete classes. Parameterized TableGen classes specify a list of variable
+ bindings (which may optionally have defaults) that are bound when used. Here is
+ a simple example:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>class</b> FPFormat<<b>bits</b><3> val> {
+ <b>bits</b><3> Value = val;
+ }
+ <b>def</b> NotFP : FPFormat<0>;
+ <b>def</b> ZeroArgFP : FPFormat<1>;
+ <b>def</b> OneArgFP : FPFormat<2>;
+ <b>def</b> OneArgFPRW : FPFormat<3>;
+ <b>def</b> TwoArgFP : FPFormat<4>;
+ <b>def</b> CompareFP : FPFormat<5>;
+ <b>def</b> CondMovFP : FPFormat<6>;
+ <b>def</b> SpecialFP : FPFormat<7>;
+ </pre>
+ </div>
+
+ <p>In this case, template arguments are used as a space efficient way to specify
+ a list of "enumeration values", each with a "<tt>Value</tt>" field set to the
+ specified integer.</p>
+
+ <p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
+ useful in conjunction with template arguments. As an example:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>class</b> ModRefVal<<b>bits</b><2> val> {
+ <b>bits</b><2> Value = val;
+ }
+
+ <b>def</b> None : ModRefVal<0>;
+ <b>def</b> Mod : ModRefVal<1>;
+ <b>def</b> Ref : ModRefVal<2>;
+ <b>def</b> ModRef : ModRefVal<3>;
+
+ <b>class</b> Value<ModRefVal MR> {
+ <i>// Decode some information into a more convenient format, while providing
+ // a nice interface to the user of the "Value" class.</i>
+ <b>bit</b> isMod = MR.Value{0};
+ <b>bit</b> isRef = MR.Value{1};
+
+ <i>// other stuff...</i>
+ }
+
+ <i>// Example uses</i>
+ <b>def</b> bork : Value<Mod>;
+ <b>def</b> zork : Value<Ref>;
+ <b>def</b> hork : Value<ModRef>;
+ </pre>
+ </div>
+
+ <p>This is obviously a contrived example, but it shows how template arguments
+ can be used to decouple the interface provided to the user of the class from the
+ actual internal data representation expected by the class. In this case,
+ running <tt>tblgen</tt> on the example prints the following definitions:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>def</b> bork { <i>// Value</i>
+ <b>bit</b> isMod = 1;
+ <b>bit</b> isRef = 0;
+ }
+ <b>def</b> hork { <i>// Value</i>
+ <b>bit</b> isMod = 1;
+ <b>bit</b> isRef = 1;
+ }
+ <b>def</b> zork { <i>// Value</i>
+ <b>bit</b> isMod = 0;
+ <b>bit</b> isRef = 1;
+ }
+ </pre>
+ </div>
+
+ <p> This shows that TableGen was able to dig into the argument and extract a
+ piece of information that was requested by the designer of the "Value" class.
+ For more realistic examples, please see existing users of TableGen, such as the
+ X86 backend.</p>
+
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="multiclass">Multiclass definitions and instances</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ While classes with template arguments are a good way to factor commonality
+ between two instances of a definition, multiclasses allow a convenient notation
+ for defining multiple definitions at once (instances of implicitly constructed
+ classes). For example, consider an 3-address instruction set whose instructions
+ come in two forms: "<tt>reg = reg op reg</tt>" and "<tt>reg = reg op imm</tt>"
+ (e.g. SPARC). In this case, you'd like to specify in one place that this
+ commonality exists, then in a separate place indicate what all the ops are.
+ </p>
+
+ <p>
+ Here is an example TableGen fragment that shows this idea:
+ </p>
+
+ <div class="doc_code">
+ <pre>
+ <b>def</b> ops;
+ <b>def</b> GPR;
+ <b>def</b> Imm;
+ <b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
+
+ <b>multiclass</b> ri_inst<<b>int</b> opc, <b>string</b> asmstr> {
+ def _rr : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+ def _ri : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+ }
+
+ <i>// Instantiations of the ri_inst multiclass.</i>
+ <b>defm</b> ADD : ri_inst<0b111, "add">;
+ <b>defm</b> SUB : ri_inst<0b101, "sub">;
+ <b>defm</b> MUL : ri_inst<0b100, "mul">;
+ ...
+ </pre>
+ </div>
+
+ <p>The name of the resultant definitions has the multidef fragment names
+ appended to them, so this defines <tt>ADD_rr</tt>, <tt>ADD_ri</tt>,
+ <tt>SUB_rr</tt>, etc. Using a multiclass this way is exactly equivalent to
+ instantiating the classes multiple times yourself, e.g. by writing:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>def</b> ops;
+ <b>def</b> GPR;
+ <b>def</b> Imm;
+ <b>class</b> inst<<b>int</b> opc, <b>string</b> asmstr, <b>dag</b> operandlist>;
+
+ <b>class</b> rrinst<<b>int</b> opc, <b>string</b> asmstr>
+ : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, GPR:$src2)>;
+
+ <b>class</b> riinst<<b>int</b> opc, <b>string</b> asmstr>
+ : inst<opc, !strconcat(asmstr, " $dst, $src1, $src2"),
+ (ops GPR:$dst, GPR:$src1, Imm:$src2)>;
+
+ <i>// Instantiations of the ri_inst multiclass.</i>
+ <b>def</b> ADD_rr : rrinst<0b111, "add">;
+ <b>def</b> ADD_ri : riinst<0b111, "add">;
+ <b>def</b> SUB_rr : rrinst<0b101, "sub">;
+ <b>def</b> SUB_ri : riinst<0b101, "sub">;
+ <b>def</b> MUL_rr : rrinst<0b100, "mul">;
+ <b>def</b> MUL_ri : riinst<0b100, "mul">;
+ ...
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="filescope">File scope entities</a>
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="include">File inclusion</a>
+ </div>
+
+ <div class="doc_text">
+ <p>TableGen supports the '<tt>include</tt>' token, which textually substitutes
+ the specified file in place of the include directive. The filename should be
+ specified as a double quoted string immediately after the '<tt>include</tt>'
+ keyword. Example:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>include</b> "foo.td"
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- -------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="globallet">'let' expressions</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>"Let" expressions at file scope are similar to <a href="#recordlet">"let"
+ expressions within a record</a>, except they can specify a value binding for
+ multiple records at a time, and may be useful in certain other cases.
+ File-scope let expressions are really just another way that TableGen allows the
+ end-user to factor out commonality from the records.</p>
+
+ <p>File-scope "let" expressions take a comma-separated list of bindings to
+ apply, and one or more records to bind the values in. Here are some
+ examples:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b>let</b> isTerminator = 1, isReturn = 1, isBarrier = 1, hasCtrlDep = 1 <b>in</b>
+ <b>def</b> RET : I<0xC3, RawFrm, (outs), (ins), "ret", [(X86retflag 0)]>;
+
+ <b>let</b> isCall = 1 <b>in</b>
+ <i>// All calls clobber the non-callee saved registers...</i>
+ <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6, ST0,
+ MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7,
+ XMM0, XMM1, XMM2, XMM3, XMM4, XMM5, XMM6, XMM7, EFLAGS] <b>in</b> {
+ <b>def</b> CALLpcrel32 : Ii32<0xE8, RawFrm, (outs), (ins i32imm:$dst,variable_ops),
+ "call\t${dst:call}", []>;
+ <b>def</b> CALL32r : I<0xFF, MRM2r, (outs), (ins GR32:$dst, variable_ops),
+ "call\t{*}$dst", [(X86call GR32:$dst)]>;
+ <b>def</b> CALL32m : I<0xFF, MRM2m, (outs), (ins i32mem:$dst, variable_ops),
+ "call\t{*}$dst", []>;
+ }
+ </pre>
+ </div>
+
+ <p>File-scope "let" expressions are often useful when a couple of definitions
+ need to be added to several records, and the records do not otherwise need to be
+ opened, as in the case with the <tt>CALL*</tt> instructions above.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="backends">TableGen backends</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>TODO: How they work, how to write one. This section should not contain
+ details about any particular backend, except maybe -print-enums as an example.
+ This should highlight the APIs in <tt>TableGen/Record.h</tt>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/TestingGuide.html
diff -c /dev/null llvm-www/releases/2.5/docs/TestingGuide.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/TestingGuide.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,963 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>LLVM Testing Infrastructure Guide</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ LLVM Testing Infrastructure Guide
+ </div>
+
+ <ol>
+ <li><a href="#overview">Overview</a></li>
+ <li><a href="#requirements">Requirements</a></li>
+ <li><a href="#org">LLVM testing infrastructure organization</a>
+ <ul>
+ <li><a href="#dejagnu">DejaGNU tests</a></li>
+ <li><a href="#testsuite">Test suite</a></li>
+ </ul>
+ </li>
+ <li><a href="#quick">Quick start</a>
+ <ul>
+ <li><a href="#quickdejagnu">DejaGNU tests</a></li>
+ <li><a href="#quicktestsuite">Test suite</a></li>
+ </ul>
+ </li>
+ <li><a href="#dgstructure">DejaGNU structure</a>
+ <ul>
+ <li><a href="#dgcustom">Writing new DejaGNU tests</a></li>
+ <li><a href="#dgvars">Variables and substitutions</a></li>
+ <li><a href="#dgfeatures">Other features</a></li>
+ </ul>
+ </li>
+ <li><a href="#testsuitestructure">Test suite structure</a></li>
+ <li><a href="#testsuiterun">Running the test suite</a>
+ <ul>
+ <li><a href="#testsuiteexternal">Configuring external tests</a></li>
+ <li><a href="#testsuitetests">Running different tests</a></li>
+ <li><a href="#testsuiteoutput">Generating test output</a></li>
+ <li><a href="#testsuitecustom">Writing custom tests for llvm-test</a></li>
+ </ul>
+ </li>
+ <li><a href="#nightly">Running the nightly tester</a></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by John T. Criswell, <a
+ href="http://llvm.x10sys.com/rspencer">Reid Spencer</a>, and Tanya Lattner</p>
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="overview">Overview</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>This document is the reference manual for the LLVM testing infrastructure. It documents
+ the structure of the LLVM testing infrastructure, the tools needed to use it,
+ and how to add and run tests.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="requirements">Requirements</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>In order to use the LLVM testing infrastructure, you will need all of the software
+ required to build LLVM, plus the following:</p>
+
+ <dl>
+ <dt><a href="http://www.gnu.org/software/dejagnu/">DejaGNU</a></dt>
+ <dd>The Feature and Regressions tests are organized and run by DejaGNU.</dd>
+ <dt><a href="http://expect.nist.gov/">Expect</a></dt>
+ <dd>Expect is required by DejaGNU.</dd>
+ <dt><a href="http://www.tcl.tk/software/tcltk/">tcl</a></dt>
+ <dd>Tcl is required by DejaGNU. </dd>
+
+ <ul>
+ <li><tt>./configure --with-f2c=$DIR</tt><br>
+ This will specify a new <tt>$DIR</tt> for the above-described search
+ process. This will only work if the binary, header, and library are in their
+ respective subdirectories of <tt>$DIR</tt>.</li>
+
+ <li><tt>./configure --with-f2c-bin=/binary/path --with-f2c-inc=/include/path
+ --with-f2c-lib=/lib/path</tt><br>
+ This allows you to specify the F2C components separately. Note: if you choose
+ this route, you MUST specify all three components, and you need to only specify
+ <em>directories</em> where the files are located; do NOT include the
+ filenames themselves on the <tt>configure</tt> line.</li>
+ </ul></dd>
+ </dl>
+
+ <p>Darwin (Mac OS X) developers can simplify the installation of Expect and tcl
+ by using fink. <tt>fink install expect</tt> will install both. Alternatively,
+ Darwinports users can use <tt>sudo port install expect</tt> to install Expect
+ and tcl.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="org">LLVM testing infrastructure organization</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>The LLVM testing infrastructure contains two major categories of tests: code
+ fragments and whole programs. Code fragments are referred to as the "DejaGNU
+ tests" and are in the <tt>llvm</tt> module in subversion under the
+ <tt>llvm/test</tt> directory. The whole programs tests are referred to as the
+ "Test suite" and are in the <tt>test-suite</tt> module in subversion.
+ </p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="dejagnu">DejaGNU tests</a></div>
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_text">
+
+ <p>Code fragments are small pieces of code that test a specific feature of LLVM
+ or trigger a specific bug in LLVM. They are usually written in LLVM assembly
+ language, but can be written in other languages if the test targets a particular
+ language front end. These tests are driven by the DejaGNU testing framework,
+ which is hidden behind a few simple makefiles.</p>
+
+ <p>These code fragments are not complete programs. The code generated from them is
+ never executed to determine correct behavior.</p>
+
+ <p>These code fragment tests are located in the <tt>llvm/test</tt>
+ directory.</p>
+
+ <p>Typically when a bug is found in LLVM, a regression test containing
+ just enough code to reproduce the problem should be written and placed
+ somewhere underneath this directory. In most cases, this will be a small
+ piece of LLVM assembly language code, often distilled from an actual
+ application or benchmark.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="testsuite">Test suite</a></div>
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_text">
+
+ <p>The test suite contains whole programs, which are pieces of
+ code which can be compiled and linked into a stand-alone program that can be
+ executed. These programs are generally written in high level languages such as
+ C or C++, but sometimes they are written straight in LLVM assembly.</p>
+
+ <p>These programs are compiled and then executed using several different
+ methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation,
+ etc). The output of these programs is compared to ensure that LLVM is compiling
+ the program correctly.</p>
+
+ <p>In addition to compiling and executing programs, whole program tests serve as
+ a way of benchmarking LLVM performance, both in terms of the efficiency of the
+ programs generated as well as the speed with which LLVM compiles, optimizes, and
+ generates code.</p>
+
+ <p>The test-suite is located in the <tt>test-suite</tt> Subversion module.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="quick">Quick start</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>The tests are located in two separate Subversion modules. The
+ DejaGNU tests are in the main "llvm" module under the directory
+ <tt>llvm/test</tt> (so you get these tests for free with the main llvm tree).
+ The more comprehensive test suite that includes whole
+ programs in C and C++ is in the <tt>test-suite</tt> module. This module should
+ be checked out to the <tt>llvm/projects</tt> directory (don't use another name
+ then the default "test-suite", for then the test suite will be run every time
+ you run <tt>make</tt> in the main <tt>llvm</tt> directory).
+ When you <tt>configure</tt> the <tt>llvm</tt> module,
+ the <tt>test-suite</tt> directory will be automatically configured.
+ Alternatively, you can configure the <tt>test-suite</tt> module manually.</p>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="quickdejagnu">DejaGNU tests</a></div>
+ <!-- _______________________________________________________________________ -->
+ <p>To run all of the simple tests in LLVM using DejaGNU, use the master Makefile
+ in the <tt>llvm/test</tt> directory:</p>
+
+ <div class="doc_code">
+ <pre>
+ % gmake -C llvm/test
+ </pre>
+ </div>
+
+ <p>or</p>
+
+ <div class="doc_code">
+ <pre>
+ % gmake check
+ </pre>
+ </div>
+
+ <p>To run only a subdirectory of tests in <tt>llvm/test</tt> using DejaGNU (ie.
+ Transforms), just set the TESTSUITE variable to the path of the
+ subdirectory (relative to <tt>llvm/test</tt>):</p>
+
+ <div class="doc_code">
+ <pre>
+ % gmake TESTSUITE=Transforms check
+ </pre>
+ </div>
+
+ <p><b>Note: If you are running the tests with <tt>objdir != subdir</tt>, you
+ must have run the complete testsuite before you can specify a
+ subdirectory.</b></p>
+
+ <p>To run only a single test, set <tt>TESTONE</tt> to its path (relative to
+ <tt>llvm/test</tt>) and make the <tt>check-one</tt> target:</p>
+
+ <div class="doc_code">
+ <pre>
+ % gmake TESTONE=Feature/basictest.ll check-one
+ </pre>
+ </div>
+
+ <p>To run the tests with Valgrind (Memcheck by default), just append
+ <tt>VG=1</tt> to the commands above, e.g.:</p>
+
+ <div class="doc_code">
+ <pre>
+ % gmake check VG=1
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="quicktestsuite">Test suite</a></div>
+ <!-- _______________________________________________________________________ -->
+
+ <p>To run the comprehensive test suite (tests that compile and execute whole
+ programs), first checkout and setup the <tt>test-suite</tt> module:</p>
+
+ <div class="doc_code">
+ <pre>
+ % cd llvm/projects
+ % svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
+ % cd ..
+ % ./configure --with-llvmgccdir=$LLVM_GCC_DIR
+ </pre>
+ <p>where <tt>$LLVM_GCC_DIR</tt> is the directory where you <em>installed</em>
+ llvm-gcc, not it's src or obj dir.</p>
+ </div>
+
+ <p>Then, run the entire test suite by running make in the <tt>test-suite</tt>
+ directory:</p>
+
+ <div class="doc_code">
+ <pre>
+ % cd projects/test-suite
+ % gmake
+ </pre>
+ </div>
+
+ <p>Usually, running the "nightly" set of tests is a good idea, and you can also
+ let it generate a report by running:</p>
+
+ <div class="doc_code">
+ <pre>
+ % cd projects/test-suite
+ % gmake TEST=nightly report report.html
+ </pre>
+ </div>
+
+ <p>Any of the above commands can also be run in a subdirectory of
+ <tt>projects/test-suite</tt> to run the specified test only on the programs in
+ that subdirectory.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="dgstructure">DejaGNU structure</a></div>
+ <!--=========================================================================-->
+ <div class="doc_text">
+ <p>The LLVM DejaGNU tests are driven by DejaGNU together with GNU Make and are
+ located in the <tt>llvm/test</tt> directory.
+
+ <p>This directory contains a large array of small tests
+ that exercise various features of LLVM and to ensure that regressions do not
+ occur. The directory is broken into several sub-directories, each focused on
+ a particular area of LLVM. A few of the important ones are:</p>
+
+ <ul>
+ <li><tt>Analysis</tt>: checks Analysis passes.</li>
+ <li><tt>Archive</tt>: checks the Archive library.</li>
+ <li><tt>Assembler</tt>: checks Assembly reader/writer functionality.</li>
+ <li><tt>Bitcode</tt>: checks Bitcode reader/writer functionality.</li>
+ <li><tt>CodeGen</tt>: checks code generation and each target.</li>
+ <li><tt>Features</tt>: checks various features of the LLVM language.</li>
+ <li><tt>Linker</tt>: tests bitcode linking.</li>
+ <li><tt>Transforms</tt>: tests each of the scalar, IPO, and utility
+ transforms to ensure they make the right transformations.</li>
+ <li><tt>Verifier</tt>: tests the IR verifier.</li>
+ </ul>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="dgcustom">Writing new DejaGNU tests</a></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_text">
+ <p>The DejaGNU structure is very simple, but does require some information to
+ be set. This information is gathered via <tt>configure</tt> and is written
+ to a file, <tt>site.exp</tt> in <tt>llvm/test</tt>. The <tt>llvm/test</tt>
+ Makefile does this work for you.</p>
+
+ <p>In order for DejaGNU to work, each directory of tests must have a
+ <tt>dg.exp</tt> file. DejaGNU looks for this file to determine how to run the
+ tests. This file is just a Tcl script and it can do anything you want, but
+ we've standardized it for the LLVM regression tests. If you're adding a
+ directory of tests, just copy <tt>dg.exp</tt> from another directory to get
+ running. The standard <tt>dg.exp</tt> simply loads a Tcl
+ library (<tt>test/lib/llvm.exp</tt>) and calls the <tt>llvm_runtests</tt>
+ function defined in that library with a list of file names to run. The names
+ are obtained by using Tcl's glob command. Any directory that contains only
+ directories does not need the <tt>dg.exp</tt> file.</p>
+
+ <p>The <tt>llvm-runtests</tt> function lookas at each file that is passed to
+ it and gathers any lines together that match "RUN:". This are the "RUN" lines
+ that specify how the test is to be run. So, each test script must contain
+ RUN lines if it is to do anything. If there are no RUN lines, the
+ <tt>llvm-runtests</tt> function will issue an error and the test will
+ fail.</p>
+
+ <p>RUN lines are specified in the comments of the test program using the
+ keyword <tt>RUN</tt> followed by a colon, and lastly the command (pipeline)
+ to execute. Together, these lines form the "script" that
+ <tt>llvm-runtests</tt> executes to run the test case. The syntax of the
+ RUN lines is similar to a shell's syntax for pipelines including I/O
+ redirection and variable substitution. However, even though these lines
+ may <i>look</i> like a shell script, they are not. RUN lines are interpreted
+ directly by the Tcl <tt>exec</tt> command. They are never executed by a
+ shell. Consequently the syntax differs from normal shell script syntax in a
+ few ways. You can specify as many RUN lines as needed.</p>
+
+ <p>Each RUN line is executed on its own, distinct from other lines unless
+ its last character is <tt>\</tt>. This continuation character causes the RUN
+ line to be concatenated with the next one. In this way you can build up long
+ pipelines of commands without making huge line lengths. The lines ending in
+ <tt>\</tt> are concatenated until a RUN line that doesn't end in <tt>\</tt> is
+ found. This concatenated set of RUN lines then constitutes one execution.
+ Tcl will substitute variables and arrange for the pipeline to be executed. If
+ any process in the pipeline fails, the entire line (and test case) fails too.
+ </p>
+
+ <p> Below is an example of legal RUN lines in a <tt>.ll</tt> file:</p>
+
+ <div class="doc_code">
+ <pre>
+ ; RUN: llvm-as < %s | llvm-dis > %t1
+ ; RUN: llvm-dis < %s.bc-13 > %t2
+ ; RUN: diff %t1 %t2
+ </pre>
+ </div>
+
+ <p>As with a Unix shell, the RUN: lines permit pipelines and I/O redirection
+ to be used. However, the usage is slightly different than for Bash. To check
+ what's legal, see the documentation for the
+ <a href="http://www.tcl.tk/man/tcl8.5/TclCmd/exec.htm#M2">Tcl exec</a>
+ command and the
+ <a href="http://www.tcl.tk/man/tcl8.5/tutorial/Tcl26.html">tutorial</a>.
+ The major differences are:</p>
+ <ul>
+ <li>You can't do <tt>2>&1</tt>. That will cause Tcl to write to a
+ file named <tt>&1</tt>. Usually this is done to get stderr to go through
+ a pipe. You can do that in tcl with <tt>|&</tt> so replace this idiom:
+ <tt>... 2>&1 | grep</tt> with <tt>... |& grep</tt></li>
+ <li>You can only redirect to a file, not to another descriptor and not from
+ a here document.</li>
+ <li>tcl supports redirecting to open files with the @ syntax but you
+ shouldn't use that here.</li>
+ </ul>
+
+ <p>There are some quoting rules that you must pay attention to when writing
+ your RUN lines. In general nothing needs to be quoted. Tcl won't strip off any
+ ' or " so they will get passed to the invoked program. For example:</p>
+
+ <div class="doc_code">
+ <pre>
+ ... | grep 'find this string'
+ </pre>
+ </div>
+
+ <p>This will fail because the ' characters are passed to grep. This would
+ instruction grep to look for <tt>'find</tt> in the files <tt>this</tt> and
+ <tt>string'</tt>. To avoid this use curly braces to tell Tcl that it should
+ treat everything enclosed as one value. So our example would become:</p>
+
+ <div class="doc_code">
+ <pre>
+ ... | grep {find this string}
+ </pre>
+ </div>
+
+ <p>Additionally, the characters <tt>[</tt> and <tt>]</tt> are treated
+ specially by Tcl. They tell Tcl to interpret the content as a command to
+ execute. Since these characters are often used in regular expressions this can
+ have disastrous results and cause the entire test run in a directory to fail.
+ For example, a common idiom is to look for some basicblock number:</p>
+
+ <div class="doc_code">
+ <pre>
+ ... | grep bb[2-8]
+ </pre>
+ </div>
+
+ <p>This, however, will cause Tcl to fail because its going to try to execute
+ a program named "2-8". Instead, what you want is this:</p>
+
+ <div class="doc_code">
+ <pre>
+ ... | grep {bb\[2-8\]}
+ </pre>
+ </div>
+
+ <p>Finally, if you need to pass the <tt>\</tt> character down to a program,
+ then it must be doubled. This is another Tcl special character. So, suppose
+ you had:
+
+ <div class="doc_code">
+ <pre>
+ ... | grep 'i32\*'
+ </pre>
+ </div>
+
+ <p>This will fail to match what you want (a pointer to i32). First, the
+ <tt>'</tt> do not get stripped off. Second, the <tt>\</tt> gets stripped off
+ by Tcl so what grep sees is: <tt>'i32*'</tt>. That's not likely to match
+ anything. To resolve this you must use <tt>\\</tt> and the <tt>{}</tt>, like
+ this:</p>
+
+ <div class="doc_code">
+ <pre>
+ ... | grep {i32\\*}
+ </pre>
+ </div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="dgvars">Variables and substitutions</a></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_text">
+ <p>With a RUN line there are a number of substitutions that are permitted. In
+ general, any Tcl variable that is available in the <tt>substitute</tt>
+ function (in <tt>test/lib/llvm.exp</tt>) can be substituted into a RUN line.
+ To make a substitution just write the variable's name preceded by a $.
+ Additionally, for compatibility reasons with previous versions of the test
+ library, certain names can be accessed with an alternate syntax: a % prefix.
+ These alternates are deprecated and may go away in a future version.
+ </p>
+ <p>Here are the available variable names. The alternate syntax is listed in
+ parentheses.</p>
+
+ <dl style="margin-left: 25px">
+ <dt><b>$test</b> (%s)</dt>
+ <dd>The full path to the test case's source. This is suitable for passing
+ on the command line as the input to an llvm tool.</dd>
+
+ <dt><b>$srcdir</b></dt>
+ <dd>The source directory from where the "<tt>make check</tt>" was run.</dd>
+
+ <dt><b>objdir</b></dt>
+ <dd>The object directory that corresponds to the <tt>$srcdir</tt>.</dd>
+
+ <dt><b>subdir</b></dt>
+ <dd>A partial path from the <tt>test</tt> directory that contains the
+ sub-directory that contains the test source being executed.</dd>
+
+ <dt><b>srcroot</b></dt>
+ <dd>The root directory of the LLVM src tree.</dd>
+
+ <dt><b>objroot</b></dt>
+ <dd>The root directory of the LLVM object tree. This could be the same
+ as the srcroot.</dd>
+
+ <dt><b>path</b><dt>
+ <dd>The path to the directory that contains the test case source. This is
+ for locating any supporting files that are not generated by the test, but
+ used by the test.</dd>
+
+ <dt><b>tmp</b></dt>
+ <dd>The path to a temporary file name that could be used for this test case.
+ The file name won't conflict with other test cases. You can append to it if
+ you need multiple temporaries. This is useful as the destination of some
+ redirected output.</dd>
+
+ <dt><b>llvmlibsdir</b> (%llvmlibsdir)</dt>
+ <dd>The directory where the LLVM libraries are located.</dd>
+
+ <dt><b>target_triplet</b> (%target_triplet)</dt>
+ <dd>The target triplet that corresponds to the current host machine (the one
+ running the test cases). This should probably be called "host".<dd>
+
+ <dt><b>prcontext</b> (%prcontext)</dt>
+ <dd>Path to the prcontext tcl script that prints some context around a
+ line that matches a pattern. This isn't strictly necessary as the test suite
+ is run with its PATH altered to include the test/Scripts directory where
+ the prcontext script is located. Note that this script is similar to
+ <tt>grep -C</tt> but you should use the <tt>prcontext</tt> script because
+ not all platforms support <tt>grep -C</tt>.</dd>
+
+ <dt><b>llvmgcc</b> (%llvmgcc)</dt>
+ <dd>The full path to the <tt>llvm-gcc</tt> executable as specified in the
+ configured LLVM environment</dd>
+
+ <dt><b>llvmgxx</b> (%llvmgxx)</dt>
+ <dd>The full path to the <tt>llvm-gxx</tt> executable as specified in the
+ configured LLVM environment</dd>
+
+ <dt><b>llvmgcc_version</b> (%llvmgcc_version)</dt>
+ <dd>The full version number of the <tt>llvm-gcc</tt> executable.</dd>
+
+ <dt><b>llvmgccmajvers</b> (%llvmgccmajvers)</dt>
+ <dd>The major version number of the <tt>llvm-gcc</tt> executable.</dd>
+
+ <dt><b>gccpath</b></dt>
+ <dd>The full path to the C compiler used to <i>build </i> LLVM. Note that
+ this might not be gcc.</dd>
+
+ <dt><b>gxxpath</b></dt>
+ <dd>The full path to the C++ compiler used to <i>build </i> LLVM. Note that
+ this might not be g++.</dd>
+
+ <dt><b>compile_c</b> (%compile_c)</dt>
+ <dd>The full command line used to compile LLVM C source code. This has all
+ the configured -I, -D and optimization options.</dd>
+
+ <dt><b>compile_cxx</b> (%compile_cxx)</dt>
+ <dd>The full command used to compile LLVM C++ source code. This has
+ all the configured -I, -D and optimization options.</dd>
+
+ <dt><b>link</b> (%link)</dt>
+ <dd>This full link command used to link LLVM executables. This has all the
+ configured -I, -L and -l options.</dd>
+
+ <dt><b>shlibext</b> (%shlibext)</dt>
+ <dd>The suffix for the host platforms share library (dll) files. This
+ includes the period as the first character.</dd>
+ </dl>
+ <p>To add more variables, two things need to be changed. First, add a line in
+ the <tt>test/Makefile</tt> that creates the <tt>site.exp</tt> file. This will
+ "set" the variable as a global in the site.exp file. Second, in the
+ <tt>test/lib/llvm.exp</tt> file, in the substitute proc, add the variable name
+ to the list of "global" declarations at the beginning of the proc. That's it,
+ the variable can then be used in test scripts.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection"><a name="dgfeatures">Other Features</a></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_text">
+ <p>To make RUN line writing easier, there are several shell scripts located
+ in the <tt>llvm/test/Scripts</tt> directory. This directory is in the PATH
+ when running tests, so you can just call these scripts using their name. For
+ example:</p>
+ <dl>
+ <dt><b>ignore</b></dt>
+ <dd>This script runs its arguments and then always returns 0. This is useful
+ in cases where the test needs to cause a tool to generate an error (e.g. to
+ check the error output). However, any program in a pipeline that returns a
+ non-zero result will cause the test to fail. This script overcomes that
+ issue and nicely documents that the test case is purposefully ignoring the
+ result code of the tool</dd>
+
+ <dt><b>not</b></dt>
+ <dd>This script runs its arguments and then inverts the result code from
+ it. Zero result codes become 1. Non-zero result codes become 0. This is
+ useful to invert the result of a grep. For example "not grep X" means
+ succeed only if you don't find X in the input.</dd>
+ </dl>
+
+ <p>Sometimes it is necessary to mark a test case as "expected fail" or XFAIL.
+ You can easily mark a test as XFAIL just by including <tt>XFAIL: </tt> on a
+ line near the top of the file. This signals that the test case should succeed
+ if the test fails. Such test cases are counted separately by DejaGnu. To
+ specify an expected fail, use the XFAIL keyword in the comments of the test
+ program followed by a colon and one or more regular expressions (separated by
+ a comma). The regular expressions allow you to XFAIL the test conditionally
+ by host platform. The regular expressions following the : are matched against
+ the target triplet or llvmgcc version number for the host machine. If there is
+ a match, the test is expected to fail. If not, the test is expected to
+ succeed. To XFAIL everywhere just specify <tt>XFAIL: *</tt>. When matching
+ the llvm-gcc version, you can specify the major (e.g. 3) or full version
+ (i.e. 3.4) number. Here is an example of an <tt>XFAIL</tt> line:</p>
+
+ <div class="doc_code">
+ <pre>
+ ; XFAIL: darwin,sun,llvmgcc4
+ </pre>
+ </div>
+
+ <p>To make the output more useful, the <tt>llvm_runtest</tt> function wil
+ scan the lines of the test case for ones that contain a pattern that matches
+ PR[0-9]+. This is the syntax for specifying a PR (Problem Report) number that
+ is related to the test case. The number after "PR" specifies the LLVM bugzilla
+ number. When a PR number is specified, it will be used in the pass/fail
+ reporting. This is useful to quickly get some context when a test fails.</p>
+
+ <p>Finally, any line that contains "END." will cause the special
+ interpretation of lines to terminate. This is generally done right after the
+ last RUN: line. This has two side effects: (a) it prevents special
+ interpretation of lines that are part of the test program, not the
+ instructions to the test case, and (b) it speeds things up for really big test
+ cases by avoiding interpretation of the remainder of the file.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="testsuitestructure">Test suite
+ Structure</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>The <tt>test-suite</tt> module contains a number of programs that can be compiled
+ with LLVM and executed. These programs are compiled using the native compiler
+ and various LLVM backends. The output from the program compiled with the
+ native compiler is assumed correct; the results from the other programs are
+ compared to the native program output and pass if they match.</p>
+
+ <p>When executing tests, it is usually a good idea to start out with a subset of
+ the available tests or programs. This makes test run times smaller at first and
+ later on this is useful to investigate individual test failures. To run some
+ test only on a subset of programs, simply change directory to the programs you
+ want tested and run <tt>gmake</tt> there. Alternatively, you can run a different
+ test using the <tt>TEST</tt> variable to change what tests or run on the
+ selected programs (see below for more info).</p>
+
+ <p>In addition for testing correctness, the <tt>llvm-test</tt> directory also
+ performs timing tests of various LLVM optimizations. It also records
+ compilation times for the compilers and the JIT. This information can be
+ used to compare the effectiveness of LLVM's optimizations and code
+ generation.</p>
+
+ <p><tt>llvm-test</tt> tests are divided into three types of tests: MultiSource,
+ SingleSource, and External.</p>
+
+ <ul>
+ <li><tt>llvm-test/SingleSource</tt>
+ <p>The SingleSource directory contains test programs that are only a single
+ source file in size. These are usually small benchmark programs or small
+ programs that calculate a particular value. Several such programs are grouped
+ together in each directory.</p></li>
+
+ <li><tt>llvm-test/MultiSource</tt>
+ <p>The MultiSource directory contains subdirectories which contain entire
+ programs with multiple source files. Large benchmarks and whole applications
+ go here.</p></li>
+
+ <li><tt>llvm-test/External</tt>
+ <p>The External directory contains Makefiles for building code that is external
+ to (i.e., not distributed with) LLVM. The most prominent members of this
+ directory are the SPEC 95 and SPEC 2000 benchmark suites. The <tt>External</tt>
+ directory does not contain these actual tests,but only the Makefiles that know
+ how to properly compile these programs from somewhere else. The presence and
+ location of these external programs is configured by the llvm-test
+ <tt>configure</tt> script.</p></li>
+ </ul>
+
+ <p>Each tree is then subdivided into several categories, including applications,
+ benchmarks, regression tests, code that is strange grammatically, etc. These
+ organizations should be relatively self explanatory.</p>
+
+ <p>Some tests are known to fail. Some are bugs that we have not fixed yet;
+ others are features that we haven't added yet (or may never add). In DejaGNU,
+ the result for such tests will be XFAIL (eXpected FAILure). In this way, you
+ can tell the difference between an expected and unexpected failure.</p>
+
+ <p>The tests in the test suite have no such feature at this time. If the
+ test passes, only warnings and other miscellaneous output will be generated. If
+ a test fails, a large <program> FAILED message will be displayed. This
+ will help you separate benign warnings from actual test failures.</p>
+
+ </div>
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="testsuiterun">Running the test suite</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>First, all tests are executed within the LLVM object directory tree. They
+ <i>are not</i> executed inside of the LLVM source tree. This is because the
+ test suite creates temporary files during execution.</p>
+
+ <p>To run the test suite, you need to use the following steps:</p>
+
+ <ol>
+ <li><tt>cd</tt> into the <tt>llvm/projects</tt> directory</li>
+
+ <li><p>Check out the <tt>test-suite</tt> module with:</p>
+
+ <div class="doc_code">
+ <pre>
+ % svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
+ </pre>
+ </div>
+
+ <p>This will get the test suite into <tt>llvm/projects/llvm-test</tt></p>
+
+ <li><p>Configure the test suite using llvm configure. This will automatically
+ configure test-suite. You must do it from the top level otherwise llvm-gcc
+ will not be set which is required to run llvm-test:</p>
+ <div class="doc_code">
+ <pre>
+ % cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure --with-llvmgccdir=$LLVM_GCC_DIR
+ </pre>
+ </div>
+ <p>Note that that <tt>$LLVM_GCC_DIR</tt> is the directory where you
+ <em>installed</em> llvm-gcc, not its src or obj directory.</p>
+ </li>
+
+ <li><p>Change back to the <tt>llvm/projects/test-suite</tt> directory you created before
+ and run <tt>gmake</tt> (or just "<tt>make</tt>" on systems where GNU make is
+ the default, such as linux.</p></li>
+ </ol>
+ <p>Note that the second and third steps only need to be done once. After you
+ have the suite checked out and configured, you don't need to do it again (unless
+ the test code or configure script changes).</p>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="testsuiteexternal">Configuring external tests</a></div>
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_text">
+ <p>Note, when configuring the <tt>test-suite</tt> module, you might want to
+ specify the following configuration option:</p>
+ <dl>
+ <dt><i>--with-externals</i></dt>
+ <dt><i>--with-externals=<<tt>directory</tt>></i></dt>
+ </dl>
+ This tells LLVM where to find any external tests. They are expected to be
+ in specifically named subdirectories of <<tt>directory</tt>>.
+ If <tt>directory</tt> is left unspecified,
+ <tt>configure</tt> uses the default value
+ <tt>/home/vadve/shared/benchmarks/speccpu2000/benchspec</tt>.
+ Subdirectory names known to LLVM include:
+ <dl>
+ <dt>spec95</dt>
+ <dt>speccpu2000</dt>
+ <dt>speccpu2006</dt>
+ <dt>povray31</dt>
+ </dl>
+ Others are added from time to time, and can be determined from
+ <tt>configure</tt>.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="testsuitetests">Running different tests</a></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_text">
+ <p>In addition to the regular "whole program" tests, the <tt>test-suite</tt>
+ module also provides a mechanism for compiling the programs in different ways.
+ If the variable TEST is defined on the <tt>gmake</tt> command line, the test system will
+ include a Makefile named <tt>TEST.<value of TEST variable>.Makefile</tt>.
+ This Makefile can modify build rules to yield different results.</p>
+
+ <p>For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt> to
+ create the nightly test reports. To run the nightly tests, run <tt>gmake
+ TEST=nightly</tt>.</p>
+
+ <p>There are several TEST Makefiles available in the tree. Some of them are
+ designed for internal LLVM research and will not work outside of the LLVM
+ research group. They may still be valuable, however, as a guide to writing your
+ own TEST Makefile for any optimization or analysis passes that you develop with
+ LLVM.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="testsuiteoutput">Generating test output</a></div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_text">
+ <p>There are a number of ways to run the tests and generate output. The most
+ simple one is simply running <tt>gmake</tt> with no arguments. This will
+ compile and run all programs in the tree using a number of different methods
+ and compare results. Any failures are reported in the output, but are likely
+ drowned in the other output. Passes are not reported explicitely.</p>
+
+ <p>Somewhat better is running <tt>gmake TEST=sometest test</tt>, which runs
+ the specified test and usually adds per-program summaries to the output
+ (depending on which sometest you use). For example, the <tt>nightly</tt> test
+ explicitely outputs TEST-PASS or TEST-FAIL for every test after each program.
+ Though these lines are still drowned in the output, it's easy to grep the
+ output logs in the Output directories.</p>
+
+ <p>Even better are the <tt>report</tt> and <tt>report.format</tt> targets
+ (where <tt>format</tt> is one of <tt>html</tt>, <tt>csv</tt>, <tt>text</tt> or
+ <tt>graphs</tt>). The exact contents of the report are dependent on which
+ <tt>TEST</tt> you are running, but the text results are always shown at the
+ end of the run and the results are always stored in the
+ <tt>report.<type>.format</tt> file (when running with
+ <tt>TEST=<type></tt>).
+
+ The <tt>report</tt> also generate a file called
+ <tt>report.<type>.raw.out</tt> containing the output of the entire test
+ run.
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="testsuitecustom">Writing custom tests for the test suite</a></div>
+ <!-- _______________________________________________________________________ -->
+
+ <div class="doc_text">
+
+ <p>Assuming you can run the test suite, (e.g. "<tt>gmake TEST=nightly report</tt>"
+ should work), it is really easy to run optimizations or code generator
+ components against every program in the tree, collecting statistics or running
+ custom checks for correctness. At base, this is how the nightly tester works,
+ it's just one example of a general framework.</p>
+
+ <p>Lets say that you have an LLVM optimization pass, and you want to see how
+ many times it triggers. First thing you should do is add an LLVM
+ <a href="ProgrammersManual.html#Statistic">statistic</a> to your pass, which
+ will tally counts of things you care about.</p>
+
+ <p>Following this, you can set up a test and a report that collects these and
+ formats them for easy viewing. This consists of two files, an
+ "<tt>test-suite/TEST.XXX.Makefile</tt>" fragment (where XXX is the name of your
+ test) and an "<tt>llvm-test/TEST.XXX.report</tt>" file that indicates how to
+ format the output into a table. There are many example reports of various
+ levels of sophistication included with the test suite, and the framework is very
+ general.</p>
+
+ <p>If you are interested in testing an optimization pass, check out the
+ "libcalls" test as an example. It can be run like this:<p>
+
+ <div class="doc_code">
+ <pre>
+ % cd llvm/projects/test-suite/MultiSource/Benchmarks # or some other level
+ % make TEST=libcalls report
+ </pre>
+ </div>
+
+ <p>This will do a bunch of stuff, then eventually print a table like this:</p>
+
+ <div class="doc_code">
+ <pre>
+ Name | total | #exit |
+ ...
+ FreeBench/analyzer/analyzer | 51 | 6 |
+ FreeBench/fourinarow/fourinarow | 1 | 1 |
+ FreeBench/neural/neural | 19 | 9 |
+ FreeBench/pifft/pifft | 5 | 3 |
+ MallocBench/cfrac/cfrac | 1 | * |
+ MallocBench/espresso/espresso | 52 | 12 |
+ MallocBench/gs/gs | 4 | * |
+ Prolangs-C/TimberWolfMC/timberwolfmc | 302 | * |
+ Prolangs-C/agrep/agrep | 33 | 12 |
+ Prolangs-C/allroots/allroots | * | * |
+ Prolangs-C/assembler/assembler | 47 | * |
+ Prolangs-C/bison/mybison | 74 | * |
+ ...
+ </pre>
+ </div>
+
+ <p>This basically is grepping the -stats output and displaying it in a table.
+ You can also use the "TEST=libcalls report.html" target to get the table in HTML
+ form, similarly for report.csv and report.tex.</p>
+
+ <p>The source for this is in test-suite/TEST.libcalls.*. The format is pretty
+ simple: the Makefile indicates how to run the test (in this case,
+ "<tt>opt -simplify-libcalls -stats</tt>"), and the report contains one line for
+ each column of the output. The first value is the header for the column and the
+ second is the regex to grep the output of the command for. There are lots of
+ example reports that can do fancy stuff.</p>
+
+ </div>
+
+
+ <!--=========================================================================-->
+ <div class="doc_section"><a name="nightly">Running the nightly tester</a></div>
+ <!--=========================================================================-->
+
+ <div class="doc_text">
+
+ <p>
+ The <a href="http://llvm.org/nightlytest/">LLVM Nightly Testers</a>
+ automatically check out an LLVM tree, build it, run the "nightly"
+ program test (described above), run all of the DejaGNU tests,
+ delete the checked out tree, and then submit the results to
+ <a href="http://llvm.org/nightlytest/">http://llvm.org/nightlytest/</a>.
+ After test results are submitted to
+ <a href="http://llvm.org/nightlytest/">http://llvm.org/nightlytest/</a>,
+ they are processed and displayed on the tests page. An email to
+ <a href="http://lists.cs.uiuc.edu/pipermail/llvm-testresults/">
+ llvm-testresults at cs.uiuc.edu</a> summarizing the results is also generated.
+ This testing scheme is designed to ensure that programs don't break as well
+ as keep track of LLVM's progress over time.</p>
+
+ <p>If you'd like to set up an instance of the nightly tester to run on your
+ machine, take a look at the comments at the top of the
+ <tt>utils/NewNightlyTest.pl</tt> file. If you decide to set up a nightly tester
+ please choose a unique nickname and invoke <tt>utils/NewNightlyTest.pl</tt>
+ with the "-nickname [yournickname]" command line option.
+
+ <p>You can create a shell script to encapsulate the running of the script.
+ The optimized x86 Linux nightly test is run from just such a script:</p>
+
+ <div class="doc_code">
+ <pre>
+ #!/bin/bash
+ BASE=/proj/work/llvm/nightlytest
+ export BUILDDIR=$BASE/build
+ export WEBDIR=$BASE/testresults
+ export LLVMGCCDIR=/proj/work/llvm/cfrontend/install
+ export PATH=/proj/install/bin:$LLVMGCCDIR/bin:$PATH
+ export LD_LIBRARY_PATH=/proj/install/lib
+ cd $BASE
+ cp /proj/work/llvm/llvm/utils/NewNightlyTest.pl .
+ nice ./NewNightlyTest.pl -nice -release -verbose -parallel -enable-linscan \
+ -nickname NightlyTester -noexternals > output.log 2>&1
+ </pre>
+ </div>
+
+ <p>It is also possible to specify the the location your nightly test results
+ are submitted. You can do this by passing the command line option
+ "-submit-server [server_address]" and "-submit-script [script_on_server]" to
+ <tt>utils/NewNightlyTest.pl</tt>. For example, to submit to the llvm.org
+ nightly test results page, you would invoke the nightly test script with
+ "-submit-server llvm.org -submit-script /nightlytest/NightlyTestAccept.cgi".
+ If these options are not specified, the nightly test script sends the results
+ to the llvm.org nightly test results page.</p>
+
+ <p>Take a look at the <tt>NewNightlyTest.pl</tt> file to see what all of the
+ flags and strings do. If you start running the nightly tests, please let us
+ know. Thanks!</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ John T. Criswell, Reid Spencer, and Tanya Lattner<br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/UsingLibraries.html
diff -c /dev/null llvm-www/releases/2.5/docs/UsingLibraries.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/UsingLibraries.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,449 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Using The LLVM Libraries</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+ <div class="doc_title">Using The LLVM Libraries</div>
+ <ol>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#descriptions">Library Descriptions</a></li>
+ <li><a href="#dependencies">Library Dependencies</a></li>
+ <li><a href="#rot">Linkage Rules Of Thumb</a>
+ <ol>
+ <li><a href="#always">Always link LLVMCore, LLVMSupport, LLVMSystem</a>
+ <li><a href="#onlyone">Never link both archive and re-linked</a>
+ </ol>
+ </li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a></p>
+ </div>
+
+ <p class="doc_warning">Warning: This document is out of date, please see <a href="CommandGuide/html/llvm-config.html">llvm-config</a> for more information.</p>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="abstract">Abstract</a></div>
+ <div class="doc_text">
+ <p>Amongst other things, LLVM is a toolkit for building compilers, linkers,
+ runtime executives, virtual machines, and other program execution related
+ tools. In addition to the LLVM tool set, the functionality of LLVM is
+ available through a set of libraries. To use LLVM as a toolkit for
+ constructing tools, a developer needs to understand what is contained in the
+ various libraries, what they depend on, and how to use them. Fortunately,
+ there is a tool, <tt>llvm-config</tt> to aid with this. This document
+ describes the contents of the libraries and how to use <tt>llvm-config</tt>
+ to generate command line options.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"> <a name="introduction">Introduction</a></div>
+ <div class="doc_text">
+ <p>If you're writing a compiler, virtual machine, or any other utility based
+ on LLVM, you'll need to figure out which of the many libraries files you will
+ need to link with to be successful. An understanding of the contents of these
+ libraries will be useful in coming up with an optimal specification for the
+ libraries to link with. The purpose of this document is to reduce some of
+ the trial and error that the author experienced in using LLVM.</p>
+ <p>LLVM produces two types of libraries: archives (ending in <tt>.a</tt>) and
+ objects (ending in <tt>.o</tt>). However, both are libraries. Libraries ending
+ in <tt>.o</tt> are known as re-linked libraries because they contain all the
+ compilation units of the library linked together as a single <tt>.o</tt> file.
+ Furthermore, several of the libraries have <em>both</em> forms of library. The
+ re-linked libraries are used whenever you want to include all symbols from the
+ library. The archive libraries are used whenever you want to only resolve
+ outstanding symbols at that point in the link without including everything in
+ the library. </p>
+ <p>If you're using the LLVM Makefile system to link your tools,you will use
+ the <tt>LLVMLIBS</tt> make variable.
+ (see the <a href="MakefileGuide.html#LLVMLIBS">Makefile Guide</a> for
+ details). This variable specifies which LLVM libraries to link into your tool
+ and the order in which they will be linked. You specify re-linked libraries by
+ naming the library without a suffix. You specify archive libraries by naming
+ the library with a <tt>.a</tt> suffix but without the <tt>lib</tt> prefix. The
+ order in which the libraries appear in the <tt>LLVMLIBS</tt> variable
+ definition is the order in which they will be linked. Getting this order
+ correct for your tool can sometimes be challenging.
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="descriptions"></a>Library Descriptions</div>
+ <div class="doc_text">
+ <p>The table below categorizes each library
+ <table style="text-align:left">
+ <tr><th>Library</th><th>Forms</th><th>Description</th></tr>
+ <tr><th colspan="3">Core Libraries</th></tr>
+ <tr><td>LLVMArchive</td><td><tt>.a</tt></td>
+ <td>LLVM archive reading and writing</td></tr>
+ <tr><td>LLVMAsmParser</td><td><tt>.a</tt></td>
+ <td>LLVM assembly parsing</td></tr>
+ <tr><td>LLVMBCReader</td><td><tt>.a</tt></td>
+ <td>LLVM bitcode reading</td></tr>
+ <tr><td>LLVMBCWriter</td><td><tt>.a</tt></td>
+ <td>LLVM bitcode writing</td></tr>
+ <tr><td>LLVMCore</td><td><tt>.a</tt></td>
+ <td>LLVM core intermediate representation</td></tr>
+ <tr><td>LLVMDebugger</td><td><tt>.a</tt></td>
+ <td>Source level debugging support</td></tr>
+ <tr><td>LLVMLinker</td><td><tt>.a</tt></td>
+ <td>Bitcode and archive linking interface</td></tr>
+ <tr><td>LLVMSupport</td><td><tt>.a</tt></td>
+ <td>General support utilities</td></tr>
+ <tr><td>LLVMSystem</td><td><tt>.a</tt></td>
+ <td>Operating system abstraction layer</td></tr>
+ <tr><td>LLVMbzip2</td><td><tt>.a</tt></td>
+ <td>BZip2 compression library</td></tr>
+
+ <tr><th colspan="3">Analysis Libraries</th></tr>
+ <tr><td>LLVMAnalysis</td><td><tt>.a</tt></td>
+ <td>Various analysis passes.</td></tr>
+ <tr><td>LLVMDataStructure</td><td><tt>.o</tt></td>
+ <td>Data structure analysis passes.</td></tr>
+ <tr><td>LLVMipa</td><td><tt>.a</tt></td>
+ <td>Inter-procedural analysis passes.</td></tr>
+
+ <tr><th colspan="3">Transformation Libraries</th></tr>
+ <tr><td>LLVMInstrumentation</td><td><tt>.a</tt></td>
+ <td>Instrumentation passes.</td></tr>
+ <tr><td>LLVMipo</td><td><tt>.a</tt></td>
+ <td>All inter-procedural optimization passes.</td></tr>
+ <tr><td>LLVMScalarOpts</td><td><tt>.a</tt></td>
+ <td>All scalar optimization passes.</td></tr>
+ <tr><td>LLVMTransformUtils</td><td><tt>.a</tt></td>
+ <td>Transformation utilities used by many passes.</td></tr>
+
+ <tr><th colspan="3">Code Generation Libraries </th></tr>
+ <tr><td>LLVMCodeGen</td><td><tt>.o</tt></td>
+ <td>Native code generation infrastructure</td></tr>
+ <tr><td>LLVMSelectionDAG</td><td><tt>.o</tt></td>
+ <td>Aggressive instruction selector for directed acyclic graphs</td></tr>
+
+ <tr><th colspan="3">Target Libraries</th></tr>
+ <tr><td>LLVMAlpha</td><td><tt>.o</tt></td>
+ <td>Code generation for Alpha architecture</td></tr>
+ <tr><td>LLVMARM</td><td><tt>.o</tt></td>
+ <td>Code generation for ARM architecture</td></tr>
+ <tr><td>LLVMCBackend</td><td><tt>.o</tt></td>
+ <td>'C' language code generator.</td></tr>
+ <tr><td>LLVMIA64</td><td><tt>.o</tt></td>
+ <td>Code generation for IA64 architecture</td></tr>
+ <tr><td>LLVMPowerPC</td><td><tt>.o</tt></td>
+ <td>Code generation for PowerPC architecture</td></tr>
+ <tr><td>LLVMSparc</td><td><tt>.o</tt></td>
+ <td>Code generation for Sparc architecture</td></tr>
+ <tr><td>LLVMTarget</td><td><tt>.a</tt></td>
+ <td>Generic code generation utilities.</td></tr>
+ <tr><td>LLVMX86</td><td><tt>.o</tt></td>
+ <td>Code generation for Intel x86 architecture</td></tr>
+
+ <tr><th colspan="3">Runtime Libraries</th></tr>
+ <tr><td>LLVMInterpreter</td><td><tt>.o</tt></td>
+ <td>Bitcode Interpreter</td></tr>
+ <tr><td>LLVMJIT</td><td><tt>.o</tt></td>
+ <td>Bitcode JIT Compiler</td></tr>
+ <tr><td>LLVMExecutionEngine</td><td><tt>.o</tt></td>
+ <td>Virtual machine engine</td></tr>
+ </table>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="dependencies"></a>Using llvm-config</div>
+ <div class="doc_text">
+ <p>The <tt>llvm-config</tt> tool is a perl script that produces on its output
+ various kinds of information. For example, the source or object directories
+ used to build LLVM can be accessed by passing options to <tt>llvm-config</tt>.
+ For complete details on this tool, please see the
+ <a href="CommandGuide/html/llvm-config.html">manual page</a>.</p>
+ <p>To understand the relationships between libraries, the <tt>llvm-config</tt>
+ can be very useful. If all you know is that you want certain libraries to
+ be available, you can generate the complete set of libraries to link with
+ using one of four options, as below:</p>
+ <ol>
+ <li><tt>--ldflags</tt>. This generates the command line options necessary to
+ be passed to the <tt>ld</tt> tool in order to link with LLVM. Most notably,
+ the <tt>-L</tt> option is provided to specify a library search directory
+ that contains the LLVM libraries.</li>
+ <li><tt>--libs</tt>. This generates command line options suitable for
+ use with a gcc-style linker. That is, libraries are given with a -l option
+ and object files are given with a full path.</li>
+ <li><tt>--libnames</tt>. This generates a list of just the library file
+ names. If you know the directory in which these files reside (see --ldflags)
+ then you can find the libraries there.</li>
+ <li><tt>--libfiles</tt>. This generates the full path names of the
+ LLVM library files.</li>
+ </ol>
+ <p>If you wish to delve further into how <tt>llvm-config</tt> generates the
+ correct order (based on library dependencies), please see the tool named
+ <tt>GenLibDeps.pl</tt> in the <tt>utils</tt> source directory of LLVM.</p>
+
+ <!-- =======NOTE: =========================================================-->
+ <!-- === The following graphs and <dl> list are generated automatically ===-->
+ <!-- === by the util named GenLibDeps.pl in the llvm/utils directory. ===-->
+ <!-- === This should be updated whenever new libraries are added, ===-->
+ <!-- === removed, or changed ===-->
+ <!-- =======NOTE: =========================================================-->
+ <h2>Dependency Relationships Of Libraries</h2>
+ <p>This graph shows the dependency of archive libraries on other archive
+ libraries or objects. Where a library has both archive and object forms, only
+ the archive form is shown.</p>
+ <img src="img/libdeps.gif" alt="Library Dependencies"/>
+ <h2>Dependency Relationships Of Object Files</h2>
+ <p>This graph shows the dependency of object files on archive libraries or
+ other objects. Where a library has both object and archive forms, only the
+ dependency to the archive form is shown.</p>
+ <img src="img/objdeps.gif" alt="Object File Dependencies"/>
+ <p>The following list shows the dependency relationships between libraries in
+ textual form. The information is the same as shown on the graphs but arranged
+ alphabetically.</p>
+ <dl>
+ <dt><b>libLLVMAnalysis.a</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>libLLVMArchive.a</b></dt><dd><ul>
+ <li>libLLVMBCReader.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMAsmParser.a</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMBCReader.a</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMBCWriter.a</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMCodeGen.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMScalarOpts.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMTransformUtils.a</li>
+ </ul></dd>
+ <dt><b>libLLVMCore.a</b></dt><dd><ul>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMDebugger.a</b></dt><dd><ul>
+ <li>libLLVMBCReader.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMInstrumentation.a</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMScalarOpts.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMTransformUtils.a</li>
+ </ul></dd>
+ <dt><b>libLLVMLinker.a</b></dt><dd><ul>
+ <li>libLLVMArchive.a</li>
+ <li>libLLVMBCReader.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMScalarOpts.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMTransformUtils.a</li>
+ </ul></dd>
+ <dt><b>libLLVMSelectionDAG.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMTransformUtils.a</li>
+ </ul></dd>
+ <dt><b>libLLVMSupport.a</b></dt><dd><ul>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMbzip2.a</li>
+ </ul></dd>
+ <dt><b>libLLVMSystem.a</b></dt><dd><ul>
+ </ul></dd>
+ <dt><b>libLLVMTarget.a</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMTransformUtils.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMipa.a</li>
+ </ul></dd>
+ <dt><b>libLLVMbzip2.a</b></dt><dd><ul>
+ </ul></dd>
+ <dt><b>libLLVMipa.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ </ul></dd>
+ <dt><b>libLLVMipo.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMTransformUtils.a</li>
+ <li>libLLVMipa.a</li>
+ </ul></dd>
+ <dt><b>libLLVMlto.a</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMBCReader.a</li>
+ <li>libLLVMBCWriter.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMLinker.a</li>
+ <li>libLLVMScalarOpts.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMipa.a</li>
+ <li>libLLVMipo.a</li>
+ </ul></dd>
+ <dt><b>LLVMARM.o</b></dt><dd><ul>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSelectionDAG.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMAlpha.o</b></dt><dd><ul>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSelectionDAG.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMCBackend.o</b></dt><dd><ul>
+ <li>libLLVMAnalysis.a</li>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMScalarOpts.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ <li>libLLVMTransformUtils.a</li>
+ <li>libLLVMipa.a</li>
+ </ul></dd>
+ <dt><b>LLVMExecutionEngine.o</b></dt><dd><ul>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMIA64.o</b></dt><dd><ul>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSelectionDAG.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMInterpreter.o</b></dt><dd><ul>
+ <li>LLVMExecutionEngine.o</li>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMJIT.o</b></dt><dd><ul>
+ <li>LLVMExecutionEngine.o</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMPowerPC.o</b></dt><dd><ul>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSelectionDAG.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMSparc.o</b></dt><dd><ul>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSelectionDAG.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ <dt><b>LLVMX86.o</b></dt><dd><ul>
+ <li>libLLVMCodeGen.a</li>
+ <li>libLLVMCore.a</li>
+ <li>libLLVMSelectionDAG.a</li>
+ <li>libLLVMSupport.a</li>
+ <li>libLLVMSystem.a</li>
+ <li>libLLVMTarget.a</li>
+ </ul></dd>
+ </dl>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="rot">Linkage Rules Of Thumb</a></div>
+ <div class="doc_text">
+ <p>This section contains various "rules of thumb" about what files you
+ should link into your programs.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="always">Always Link LLVMCore, LLVMSupport,
+ and LLVMSystem</a></div>
+ <div class="doc_text">
+ <p>No matter what you do with LLVM, the last three entries in the value of
+ your LLVMLIBS make variable should always be:
+ <tt>LLVMCore LLVMSupport.a LLVMSystem.a</tt>. There are no <tt>LLVM</tt>
+ programs that don't depend on these three.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="onlyone">Never link both archive and
+ re-linked library</a></div>
+ <div class="doc_text">
+ <p>There is never any point to linking both the re-linked (<tt>.o</tt>) and
+ the archive (<tt>.a</tt>) versions of a library. Since the re-linked version
+ includes the entire library, the archive version will not resolve any symbols.
+ You could even end up with link error if you place the archive version before
+ the re-linked version on the linker's command line.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <hr>
+ <div class="doc_footer">
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"/></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+ <a href="mailto:rspencer at x10sys.com">Reid Spencer</a>
+ </address>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
+ <br>Last modified: $Date: 2009/03/03 05:17:36 $ </div>
+ </body>
+ </html>
+ <!-- vim: sw=2 ts=2 ai
+ -->
Index: llvm-www/releases/2.5/docs/WritingAnLLVMBackend.html
diff -c /dev/null llvm-www/releases/2.5/docs/WritingAnLLVMBackend.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/WritingAnLLVMBackend.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,2162 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Writing an LLVM Compiler Backend</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+
+ <body>
+
+ <div class="doc_title">
+ Writing an LLVM Compiler Backend
+ </div>
+
+ <ol>
+ <li><a href="#intro">Introduction</a>
+ <ul>
+ <li><a href="#Audience">Audience</a></li>
+ <li><a href="#Prerequisite">Prerequisite Reading</a></li>
+ <li><a href="#Basic">Basic Steps</a></li>
+ <li><a href="#Preliminaries">Preliminaries</a></li>
+ </ul>
+ <li><a href="#TargetMachine">Target Machine</a></li>
+ <li><a href="#RegisterSet">Register Set and Register Classes</a>
+ <ul>
+ <li><a href="#RegisterDef">Defining a Register</a></li>
+ <li><a href="#RegisterClassDef">Defining a Register Class</a></li>
+ <li><a href="#implementRegister">Implement a subclass of TargetRegisterInfo</a></li>
+ </ul></li>
+ <li><a href="#InstructionSet">Instruction Set</a>
+ <ul>
+ <li><a href="#operandMapping">Instruction Operand Mapping</a></li>
+ <li><a href="#implementInstr">Implement a subclass of TargetInstrInfo</a></li>
+ <li><a href="#branchFolding">Branch Folding and If Conversion</a></li>
+ </ul></li>
+ <li><a href="#InstructionSelector">Instruction Selector</a>
+ <ul>
+ <li><a href="#LegalizePhase">The SelectionDAG Legalize Phase</a>
+ <ul>
+ <li><a href="#promote">Promote</a></li>
+ <li><a href="#expand">Expand</a></li>
+ <li><a href="#custom">Custom</a></li>
+ <li><a href="#legal">Legal</a></li>
+ </ul></li>
+ <li><a href="#callingConventions">Calling Conventions</a></li>
+ </ul></li>
+ <li><a href="#assemblyPrinter">Assembly Printer</a></li>
+ <li><a href="#subtargetSupport">Subtarget Support</a></li>
+ <li><a href="#jitSupport">JIT Support</a>
+ <ul>
+ <li><a href="#mce">Machine Code Emitter</a></li>
+ <li><a href="#targetJITInfo">Target JIT Info</a></li>
+ </ul></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="http://www.woo.com">Mason Woo</a> and <a href="http://misha.brukman.net">Misha Brukman</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="intro">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>This document describes techniques for writing compiler backends
+ that convert the LLVM IR (intermediate representation) to code for a specified
+ machine or other languages. Code intended for a specific machine can take the
+ form of either assembly code or binary code (usable for a JIT compiler). </p>
+
+ <p>The backend of LLVM features a target-independent code generator
+ that may create output for several types of target CPUs, including X86,
+ PowerPC, Alpha, and SPARC. The backend may also be used to generate code
+ targeted at SPUs of the Cell processor or GPUs to support the execution of
+ compute kernels.</p>
+
+ <p>The document focuses on existing examples found in subdirectories
+ of <tt>llvm/lib/Target</tt> in a downloaded LLVM release. In particular, this document
+ focuses on the example of creating a static compiler (one that emits text
+ assembly) for a SPARC target, because SPARC has fairly standard
+ characteristics, such as a RISC instruction set and straightforward calling
+ conventions.</p>
+ </div>
+
+ <div class="doc_subsection">
+ <a name="Audience">Audience</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The audience for this document is anyone who needs to write an
+ LLVM backend to generate code for a specific hardware or software target.</p>
+ </div>
+
+ <div class="doc_subsection">
+ <a name="Prerequisite">Prerequisite Reading</a>
+ </div>
+
+ <div class="doc_text">
+ These essential documents must be read before reading this document:
+ <ul>
+ <li>
+ <i><a href="http://www.llvm.org/docs/LangRef.html">LLVM Language Reference Manual</a></i> -
+ a reference manual for the LLVM assembly language
+ </li>
+ <li>
+ <i><a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM Target-Independent Code Generator </a></i> -
+ a guide to the components (classes and code generation algorithms) for translating
+ the LLVM internal representation to the machine code for a specified target.
+ Pay particular attention to the descriptions of code generation stages:
+ Instruction Selection, Scheduling and Formation, SSA-based Optimization,
+ Register Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations,
+ and Code Emission.
+ </li>
+ <li>
+ <i><a href="http://www.llvm.org/docs/TableGenFundamentals.html">TableGen Fundamentals</a></i> -
+ a document that describes the TableGen (tblgen) application that manages domain-specific
+ information to support LLVM code generation. TableGen processes input from a
+ target description file (.td suffix) and generates C++ code that can be used
+ for code generation.
+ </li>
+ <li>
+ <i><a href="http://www.llvm.org/docs/WritingAnLLVMPass.html">Writing an LLVM Pass</a></i> -
+ The assembly printer is a FunctionPass, as are several SelectionDAG processing steps.
+ </li>
+ </ul>
+ To follow the SPARC examples in this document, have a copy of
+ <i><a href="http://www.sparc.org/standards/V8.pdf">The SPARC Architecture Manual, Version 8</a></i>
+ for reference. For details about the ARM instruction set, refer to the
+ <i><a href="http://infocenter.arm.com/">ARM Architecture Reference Manual</a></i>
+ For more about the GNU Assembler format (GAS), see
+ <i><a href="http://sourceware.org/binutils/docs/as/index.html">Using As</a></i>
+ especially for the assembly printer. <i>Using As</i> contains lists of target machine dependent features.
+ </div>
+
+ <div class="doc_subsection">
+ <a name="Basic">Basic Steps</a>
+ </div>
+ <div class="doc_text">
+ <p>To write a compiler
+ backend for LLVM that converts the LLVM IR (intermediate representation)
+ to code for a specified target (machine or other language), follow these steps:</p>
+
+ <ul>
+ <li>
+ Create a subclass of the TargetMachine class that describes
+ characteristics of your target machine. Copy existing examples of specific
+ TargetMachine class and header files; for example, start with <tt>SparcTargetMachine.cpp</tt>
+ and <tt>SparcTargetMachine.h</tt>, but change the file names for your target. Similarly,
+ change code that references "Sparc" to reference your target. </li>
+
+ <li>Describe the register set of the target. Use TableGen to generate
+ code for register definition, register aliases, and register classes from a
+ target-specific <tt>RegisterInfo.td</tt> input file. You should also write additional
+ code for a subclass of TargetRegisterInfo class that represents the class
+ register file data used for register allocation and also describes the
+ interactions between registers.</li>
+
+ <li>Describe the instruction set of the target. Use TableGen to
+ generate code for target-specific instructions from target-specific versions of
+ <tt>TargetInstrFormats.td</tt> and <tt>TargetInstrInfo.td</tt>. You should write additional code
+ for a subclass of the TargetInstrInfo
+ class to represent machine
+ instructions supported by the target machine. </li>
+
+ <li>Describe the selection and conversion of the LLVM IR from a DAG (directed
+ acyclic graph) representation of instructions to native target-specific
+ instructions. Use TableGen to generate code that matches patterns and selects
+ instructions based on additional information in a target-specific version of
+ <tt>TargetInstrInfo.td</tt>. Write code for <tt>XXXISelDAGToDAG.cpp</tt>
+ (where XXX identifies the specific target) to perform pattern
+ matching and DAG-to-DAG instruction selection. Also write code in <tt>XXXISelLowering.cpp</tt>
+ to replace or remove operations and data types that are not supported natively
+ in a SelectionDAG. </li>
+
+ <li>Write code for an
+ assembly printer that converts LLVM IR to a GAS format for your target machine.
+ You should add assembly strings to the instructions defined in your
+ target-specific version of <tt>TargetInstrInfo.td</tt>. You should also write code for a
+ subclass of AsmPrinter that performs the LLVM-to-assembly conversion and a
+ trivial subclass of TargetAsmInfo.</li>
+
+ <li>Optionally, add support for subtargets (that is, variants with
+ different capabilities). You should also write code for a subclass of the
+ TargetSubtarget class, which allows you to use the <tt>-mcpu=</tt>
+ and <tt>-mattr=</tt> command-line options.</li>
+
+ <li>Optionally, add JIT support and create a machine code emitter (subclass
+ of TargetJITInfo) that is used to emit binary code directly into memory. </li>
+ </ul>
+
+ <p>In the .cpp and .h files, initially stub up these methods and
+ then implement them later. Initially, you may not know which private members
+ that the class will need and which components will need to be subclassed.</p>
+ </div>
+
+ <div class="doc_subsection">
+ <a name="Preliminaries">Preliminaries</a>
+ </div>
+ <div class="doc_text">
+ <p>To actually create
+ your compiler backend, you need to create and modify a few files. The absolute
+ minimum is discussed here, but to actually use the LLVM target-independent code
+ generator, you must perform the steps described in the <a
+ href="http://www.llvm.org/docs/CodeGenerator.html">LLVM
+ Target-Independent Code Generator</a> document.</p>
+
+ <p>First, you should
+ create a subdirectory under <tt>lib/Target</tt> to hold all the files related to your
+ target. If your target is called "Dummy", create the directory
+ <tt>lib/Target/Dummy</tt>.</p>
+
+ <p>In this new
+ directory, create a <tt>Makefile</tt>. It is easiest to copy a <tt>Makefile</tt> of another
+ target and modify it. It should at least contain the <tt>LEVEL</tt>, <tt>LIBRARYNAME</tt> and
+ <tt>TARGET</tt> variables, and then include <tt>$(LEVEL)/Makefile.common</tt>. The library can be
+ named LLVMDummy (for example, see the MIPS target). Alternatively, you can
+ split the library into LLVMDummyCodeGen and LLVMDummyAsmPrinter, the latter of
+ which should be implemented in a subdirectory below <tt>lib/Target/Dummy</tt> (for
+ example, see the PowerPC target).</p>
+
+ <p>Note that these two
+ naming schemes are hardcoded into <tt>llvm-config</tt>. Using any other naming scheme
+ will confuse <tt>llvm-config</tt> and produce lots of (seemingly unrelated) linker
+ errors when linking <tt>llc</tt>.</p>
+
+ <p>To make your target
+ actually do something, you need to implement a subclass of TargetMachine. This
+ implementation should typically be in the file
+ <tt>lib/Target/DummyTargetMachine.cpp</tt>, but any file in the <tt>lib/Target</tt> directory will
+ be built and should work. To use LLVM's target
+ independent code generator, you should do what all current machine backends do: create a subclass
+ of LLVMTargetMachine. (To create a target from scratch, create a subclass of
+ TargetMachine.)</p>
+
+ <p>To get LLVM to
+ actually build and link your target, you need to add it to the <tt>TARGETS_TO_BUILD</tt>
+ variable. To do this, you modify the configure script to know about your target
+ when parsing the <tt>--enable-targets</tt> option. Search the configure script for <tt>TARGETS_TO_BUILD</tt>,
+ add your target to the lists there (some creativity required) and then
+ reconfigure. Alternatively, you can change <tt>autotools/configure.ac</tt> and
+ regenerate configure by running <tt>./autoconf/AutoRegen.sh</tt></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="TargetMachine">Target Machine</a>
+ </div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>LLVMTargetMachine is designed as a base class for targets
+ implemented with the LLVM target-independent code generator. The
+ LLVMTargetMachine class should be specialized by a concrete target class that
+ implements the various virtual methods. LLVMTargetMachine is defined as a
+ subclass of TargetMachine in <tt>include/llvm/Target/TargetMachine.h</tt>. The
+ TargetMachine class implementation (<tt>TargetMachine.cpp</tt>) also processes numerous
+ command-line options. </p>
+
+ <p>To create a concrete target-specific subclass of
+ LLVMTargetMachine, start by copying an existing TargetMachine class and header.
+ You should name the files that you create to reflect your specific target. For
+ instance, for the SPARC target, name the files <tt>SparcTargetMachine.h</tt> and
+ <tt>SparcTargetMachine.cpp</tt></p>
+
+ <p>For a target machine XXX, the implementation of XXXTargetMachine
+ must have access methods to obtain objects that represent target components.
+ These methods are named <tt>get*Info</tt> and are intended to obtain the instruction set
+ (<tt>getInstrInfo</tt>), register set (<tt>getRegisterInfo</tt>), stack frame layout
+ (<tt>getFrameInfo</tt>), and similar information. XXXTargetMachine must also implement
+ the <tt>getTargetData</tt> method to access an object with target-specific data
+ characteristics, such as data type size and alignment requirements. </p>
+
+ <p>For instance, for the SPARC target, the header file <tt>SparcTargetMachine.h</tt>
+ declares prototypes for several <tt>get*Info</tt> and <tt>getTargetData</tt> methods that simply
+ return a class member. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>namespace llvm {
+
+ class Module;
+
+ class SparcTargetMachine : public LLVMTargetMachine {
+ const TargetData DataLayout; // Calculates type size & alignment
+ SparcSubtarget Subtarget;
+ SparcInstrInfo InstrInfo;
+ TargetFrameInfo FrameInfo;
+
+ protected:
+ virtual const TargetAsmInfo *createTargetAsmInfo()
+ const;
+
+ public:
+ SparcTargetMachine(const Module &M, const std::string &FS);
+
+ virtual const SparcInstrInfo *getInstrInfo() const {return &InstrInfo; }
+ virtual const TargetFrameInfo *getFrameInfo() const {return &FrameInfo; }
+ virtual const TargetSubtarget *getSubtargetImpl() const{return &Subtarget; }
+ virtual const TargetRegisterInfo *getRegisterInfo() const {
+ return &InstrInfo.getRegisterInfo();
+ }
+ virtual const TargetData *getTargetData() const { return &DataLayout; }
+ static unsigned getModuleMatchQuality(const Module &M);
+
+ // Pass Pipeline Configuration
+ virtual bool addInstSelector(PassManagerBase &PM, bool Fast);
+ virtual bool addPreEmitPass(PassManagerBase &PM, bool Fast);
+ virtual bool addAssemblyEmitter(PassManagerBase &PM, bool Fast,
+ std::ostream &Out);
+ };
+
+ } // end namespace llvm
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <ul>
+ <li><tt>getInstrInfo </tt></li>
+ <li><tt>getRegisterInfo</tt></li>
+ <li><tt>getFrameInfo</tt></li>
+ <li><tt>getTargetData</tt></li>
+ <li><tt>getSubtargetImpl</tt></li>
+ </ul>
+ <p>For some targets, you also need to support the following methods:
+ </p>
+
+ <ul>
+ <li><tt>getTargetLowering </tt></li>
+ <li><tt>getJITInfo</tt></li>
+ </ul>
+ <p>In addition, the XXXTargetMachine constructor should specify a
+ TargetDescription string that determines the data layout for the target machine,
+ including characteristics such as pointer size, alignment, and endianness. For
+ example, the constructor for SparcTargetMachine contains the following: </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>
+ SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &FS)
+ : DataLayout("E-p:32:32-f128:128:128"),
+ Subtarget(M, FS), InstrInfo(Subtarget),
+ FrameInfo(TargetFrameInfo::StackGrowsDown, 8, 0) {
+ }
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>Hyphens separate portions of the TargetDescription string. </p>
+ <ul>
+ <li>The "E" in the string indicates a big-endian target data model; a
+ lower-case "e" would indicate little-endian. </li>
+ <li>"p:" is followed by pointer information: size, ABI alignment, and
+ preferred alignment. If only two figures follow "p:", then the first value is
+ pointer size, and the second value is both ABI and preferred alignment.</li>
+ <li>then a letter for numeric type alignment: "i", "f", "v", or "a"
+ (corresponding to integer, floating point, vector, or aggregate). "i", "v", or
+ "a" are followed by ABI alignment and preferred alignment. "f" is followed by
+ three values, the first indicates the size of a long double, then ABI alignment
+ and preferred alignment.</li>
+ </ul>
+ <p>You must also register your target using the RegisterTarget
+ template. (See the TargetMachineRegistry class.) For example, in <tt>SparcTargetMachine.cpp</tt>,
+ the target is registered with:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>
+ namespace {
+ // Register the target.
+ RegisterTarget<SparcTargetMachine>X("sparc", "SPARC");
+ }
+ </pre>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="RegisterSet">Register Set and Register Classes</a>
+ </div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>You should describe
+ a concrete target-specific class
+ that represents the register file of a target machine. This class is
+ called XXXRegisterInfo (where XXX identifies the target) and represents the
+ class register file data that is used for register allocation and also
+ describes the interactions between registers. </p>
+
+ <p>You also need to
+ define register classes to categorize related registers. A register class
+ should be added for groups of registers that are all treated the same way for
+ some instruction. Typical examples are register classes that include integer,
+ floating-point, or vector registers. A register allocator allows an
+ instruction to use any register in a specified register class to perform the
+ instruction in a similar manner. Register classes allocate virtual registers to
+ instructions from these sets, and register classes let the target-independent
+ register allocator automatically choose the actual registers.</p>
+
+ <p>Much of the code for registers, including register definition,
+ register aliases, and register classes, is generated by TableGen from
+ <tt>XXXRegisterInfo.td</tt> input files and placed in <tt>XXXGenRegisterInfo.h.inc</tt> and
+ <tt>XXXGenRegisterInfo.inc</tt> output files. Some of the code in the implementation of
+ XXXRegisterInfo requires hand-coding. </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="RegisterDef">Defining a Register</a>
+ </div>
+ <div class="doc_text">
+ <p>The <tt>XXXRegisterInfo.td</tt> file typically starts with register definitions
+ for a target machine. The Register class (specified in <tt>Target.td</tt>) is used to
+ define an object for each register. The specified string n becomes the Name of
+ the register. The basic Register object does not have any subregisters and does
+ not specify any aliases.</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ class Register<string n> {
+ string Namespace = "";
+ string AsmName = n;
+ string Name = n;
+ int SpillSize = 0;
+ int SpillAlignment = 0;
+ list<Register> Aliases = [];
+ list<Register> SubRegs = [];
+ list<int> DwarfNumbers = [];
+ }
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>For example, in the <tt>X86RegisterInfo.td</tt> file, there are register
+ definitions that utilize the Register class, such as:</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ def AL : Register<"AL">,
+ DwarfRegNum<[0, 0, 0]>;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>This defines the register AL and assigns it values (with
+ DwarfRegNum) that are used by <tt>gcc</tt>, <tt>gdb</tt>, or a debug information writer (such as
+ DwarfWriter in <tt>llvm/lib/CodeGen</tt>) to identify a register. For register AL,
+ DwarfRegNum takes an array of 3 values, representing 3 different modes: the
+ first element is for X86-64, the second for EH (exception handling) on X86-32,
+ and the third is generic. -1 is a special Dwarf number that indicates the gcc
+ number is undefined, and -2 indicates the register number is invalid for this
+ mode.</p>
+
+ <p>From the previously described line in the <tt>X86RegisterInfo.td</tt>
+ file, TableGen generates this code in the <tt>X86GenRegisterInfo.inc</tt> file:</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ static const unsigned GR8[] = { X86::AL, ... };
+
+ const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 };
+
+ const TargetRegisterDesc RegisterDescriptors[] = {
+ ...
+ { "AL", "AL", AL_AliasSet, Empty_SubRegsSet, Empty_SubRegsSet, AL_SuperRegsSet }, ...
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>From the register info file, TableGen generates a
+ TargetRegisterDesc object for each register. TargetRegisterDesc is defined in
+ <tt>include/llvm/Target/TargetRegisterInfo.h</tt> with the following fields:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>
+ struct TargetRegisterDesc {
+ const char *AsmName; // Assembly language name for the register
+ const char *Name; // Printable name for the reg (for debugging)
+ const unsigned *AliasSet; // Register Alias Set
+ const unsigned *SubRegs; // Sub-register set
+ const unsigned *ImmSubRegs; // Immediate sub-register set
+ const unsigned *SuperRegs; // Super-register set
+ };</pre>
+ </div>
+
+ <div class="doc_text">
+ <p>TableGen uses the entire target description file (<tt>.td</tt>) to
+ determine text names for the register (in the AsmName and Name fields of
+ TargetRegisterDesc) and the relationships of other registers to the defined
+ register (in the other TargetRegisterDesc fields). In this example, other
+ definitions establish the registers "AX", "EAX", and "RAX" as aliases for one
+ another, so TableGen generates a null-terminated array (AL_AliasSet) for this
+ register alias set. </p>
+
+ <p>The Register class is commonly used as a base class for more
+ complex classes. In <tt>Target.td</tt>, the Register class is the base for the
+ RegisterWithSubRegs class that is used to define registers that need to specify
+ subregisters in the SubRegs list, as shown here:</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ class RegisterWithSubRegs<string n,
+ list<Register> subregs> : Register<n> {
+ let SubRegs = subregs;
+ }</pre>
+ </div>
+
+ <div class="doc_text">
+ <p>In <tt>SparcRegisterInfo.td</tt>, additional register classes are defined
+ for SPARC: a Register subclass, SparcReg, and further subclasses: Ri, Rf, and
+ Rd. SPARC registers are identified by 5-bit ID numbers, which is a feature
+ common to these subclasses. Note the use of ‘let’ expressions to override values
+ that are initially defined in a superclass (such as SubRegs field in the Rd
+ class). </p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ class SparcReg<string n> : Register<n> {
+ field bits<5> Num;
+ let Namespace = "SP";
+ }
+ // Ri - 32-bit integer registers
+ class Ri<bits<5> num, string n> :
+ SparcReg<n> {
+ let Num = num;
+ }
+ // Rf - 32-bit floating-point registers
+ class Rf<bits<5> num, string n> :
+ SparcReg<n> {
+ let Num = num;
+ }
+ // Rd - Slots in the FP register file for 64-bit
+ floating-point values.
+ class Rd<bits<5> num, string n,
+ list<Register> subregs> : SparcReg<n> {
+ let Num = num;
+ let SubRegs = subregs;
+ }</pre>
+ </div>
+ <div class="doc_text">
+ <p>In the <tt>SparcRegisterInfo.td</tt> file, there are register definitions
+ that utilize these subclasses of Register, such as:</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ def G0 : Ri< 0, "G0">,
+ DwarfRegNum<[0]>;
+ def G1 : Ri< 1, "G1">, DwarfRegNum<[1]>;
+ ...
+ def F0 : Rf< 0, "F0">,
+ DwarfRegNum<[32]>;
+ def F1 : Rf< 1, "F1">,
+ DwarfRegNum<[33]>;
+ ...
+ def D0 : Rd< 0, "F0", [F0, F1]>,
+ DwarfRegNum<[32]>;
+ def D1 : Rd< 2, "F2", [F2, F3]>,
+ DwarfRegNum<[34]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>The last two registers shown above (D0 and D1) are double-precision
+ floating-point registers that are aliases for pairs of single-precision
+ floating-point sub-registers. In addition to aliases, the sub-register and
+ super-register relationships of the defined register are in fields of a
+ register’s TargetRegisterDesc.</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="RegisterClassDef">Defining a Register Class</a>
+ </div>
+ <div class="doc_text">
+ <p>The RegisterClass class (specified in <tt>Target.td</tt>) is used to
+ define an object that represents a group of related registers and also defines
+ the default allocation order of the registers. A target description file
+ <tt>XXXRegisterInfo.td</tt> that uses <tt>Target.td</tt> can construct register classes using the
+ following class:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>
+ class RegisterClass<string namespace,
+ list<ValueType> regTypes, int alignment,
+ list<Register> regList> {
+ string Namespace = namespace;
+ list<ValueType> RegTypes = regTypes;
+ int Size = 0; // spill size, in bits; zero lets tblgen pick the size
+ int Alignment = alignment;
+
+ // CopyCost is the cost of copying a value between two registers
+ // default value 1 means a single instruction
+ // A negative value means copying is extremely expensive or impossible
+ int CopyCost = 1;
+ list<Register> MemberList = regList;
+
+ // for register classes that are subregisters of this class
+ list<RegisterClass> SubRegClassList = [];
+
+ code MethodProtos = [{}]; // to insert arbitrary code
+ code MethodBodies = [{}];
+ }</pre>
+ </div>
+ <div class="doc_text">
+ <p>To define a RegisterClass, use the following 4 arguments:</p>
+ <ul>
+ <li>The first argument of the definition is the name of the
+ namespace. </li>
+
+ <li>The second argument is a list of ValueType register type values
+ that are defined in <tt>include/llvm/CodeGen/ValueTypes.td</tt>. Defined values include
+ integer types (such as i16, i32, and i1 for Boolean), floating-point types
+ (f32, f64), and vector types (for example, v8i16 for an 8 x i16 vector). All
+ registers in a RegisterClass must have the same ValueType, but some registers
+ may store vector data in different configurations. For example a register that
+ can process a 128-bit vector may be able to handle 16 8-bit integer elements, 8
+ 16-bit integers, 4 32-bit integers, and so on. </li>
+
+ <li>The third argument of the RegisterClass definition specifies the
+ alignment required of the registers when they are stored or loaded to memory.</li>
+
+ <li>The final argument, <tt>regList</tt>, specifies which registers are in
+ this class. If an <tt>allocation_order_*</tt> method is not specified, then <tt>regList</tt> also
+ defines the order of allocation used by the register allocator.</li>
+ </ul>
+
+ <p>In <tt>SparcRegisterInfo.td</tt>, three RegisterClass objects are defined:
+ FPRegs, DFPRegs, and IntRegs. For all three register classes, the first
+ argument defines the namespace with the string “SP”. FPRegs defines a group of 32
+ single-precision floating-point registers (F0 to F31); DFPRegs defines a group
+ of 16 double-precision registers (D0-D15). For IntRegs, the MethodProtos and
+ MethodBodies methods are used by TableGen to insert the specified code into generated
+ output.</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ def FPRegs : RegisterClass<"SP", [f32], 32, [F0, F1, F2, F3, F4, F5, F6, F7,
+ F8, F9, F10, F11, F12, F13, F14, F15, F16, F17, F18, F19, F20, F21, F22,
+ F23, F24, F25, F26, F27, F28, F29, F30, F31]>;
+
+ def DFPRegs : RegisterClass<"SP", [f64], 64, [D0, D1, D2, D3, D4, D5, D6, D7,
+ D8, D9, D10, D11, D12, D13, D14, D15]>;
+
+ def IntRegs : RegisterClass<"SP", [i32], 32, [L0, L1, L2, L3, L4, L5, L6, L7,
+ I0, I1, I2, I3, I4, I5,
+ O0, O1, O2, O3, O4, O5, O7,
+ G1,
+ // Non-allocatable regs:
+ G2, G3, G4,
+ O6, // stack ptr
+ I6, // frame ptr
+ I7, // return address
+ G0, // constant zero
+ G5, G6, G7 // reserved for kernel
+ ]> {
+ let MethodProtos = [{
+ iterator allocation_order_end(const MachineFunction &MF) const;
+ }];
+ let MethodBodies = [{
+ IntRegsClass::iterator
+ IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
+ return end()-10 // Don't allocate special registers
+ -1;
+ }
+ }];
+ }
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>Using <tt>SparcRegisterInfo.td</tt> with TableGen generates several output
+ files that are intended for inclusion in other source code that you write.
+ <tt>SparcRegisterInfo.td</tt> generates <tt>SparcGenRegisterInfo.h.inc</tt>, which should be
+ included in the header file for the implementation of the SPARC register
+ implementation that you write (<tt>SparcRegisterInfo.h</tt>). In
+ <tt>SparcGenRegisterInfo.h.inc</tt> a new structure is defined called
+ SparcGenRegisterInfo that uses TargetRegisterInfo as its base. It also
+ specifies types, based upon the defined register classes: DFPRegsClass, FPRegsClass,
+ and IntRegsClass. </p>
+
+ <p><tt>SparcRegisterInfo.td</tt> also generates SparcGenRegisterInfo.inc,
+ which is included at the bottom of <tt>SparcRegisterInfo.cpp</tt>, the SPARC register
+ implementation. The code below shows only the generated integer registers and
+ associated register classes. The order of registers in IntRegs reflects the
+ order in the definition of IntRegs in the target description file. Take special
+ note of the use of MethodBodies in <tt>SparcRegisterInfo.td</tt> to create code in
+ <tt>SparcGenRegisterInfo.inc</tt>. MethodProtos generates similar code in
+ <tt>SparcGenRegisterInfo.h.inc</tt>.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre> // IntRegs Register Class...
+ static const unsigned IntRegs[] = {
+ SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5,
+ SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3, SP::I4, SP::I5, SP::O0, SP::O1,
+ SP::O2, SP::O3, SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3, SP::G4, SP::O6,
+ SP::I6, SP::I7, SP::G0, SP::G5, SP::G6, SP::G7,
+ };
+
+ // IntRegsVTs Register Class Value Types...
+ static const MVT::ValueType IntRegsVTs[] = {
+ MVT::i32, MVT::Other
+ };
+ namespace SP { // Register class instances
+ DFPRegsClass DFPRegsRegClass;
+ FPRegsClass FPRegsRegClass;
+ IntRegsClass IntRegsRegClass;
+ ...
+
+ // IntRegs Sub-register Classess...
+ static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
+ NULL
+ };
+ ...
+ // IntRegs Super-register Classess...
+ static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
+ NULL
+ };
+
+ // IntRegs Register Class sub-classes...
+ static const TargetRegisterClass* const IntRegsSubclasses [] = {
+ NULL
+ };
+ ...
+
+ // IntRegs Register Class super-classes...
+ static const TargetRegisterClass* const IntRegsSuperclasses [] = {
+ NULL
+ };
+ ...
+
+ IntRegsClass::iterator
+ IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
+
+ return end()-10 // Don't allocate special registers
+ -1;
+ }
+
+ IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID,
+ IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses,
+ IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {}
+ }
+ </pre>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="implementRegister">Implement a subclass of</a>
+ <a href="http://www.llvm.org/docs/CodeGenerator.html#targetregisterinfo">TargetRegisterInfo</a>
+ </div>
+ <div class="doc_text">
+ <p>The final step is to hand code portions of XXXRegisterInfo, which
+ implements the interface described in <tt>TargetRegisterInfo.h</tt>. These functions
+ return 0, NULL, or false, unless overridden. Here’s a list of functions that
+ are overridden for the SPARC implementation in <tt>SparcRegisterInfo.cpp</tt>:</p>
+ <ul>
+ <li><tt>getCalleeSavedRegs</tt> (returns a list of callee-saved registers in
+ the order of the desired callee-save stack frame offset)</li>
+
+ <li><tt>getCalleeSavedRegClasses</tt> (returns a list of preferred register
+ classes with which to spill each callee saved register)</li>
+
+ <li><tt>getReservedRegs</tt> (returns a bitset indexed by physical register
+ numbers, indicating if a particular register is unavailable)</li>
+
+ <li><tt>hasFP</tt> (return a Boolean indicating if a function should have a
+ dedicated frame pointer register)</li>
+
+ <li><tt>eliminateCallFramePseudoInstr</tt> (if call frame setup or destroy
+ pseudo instructions are used, this can be called to eliminate them)</li>
+
+ <li><tt>eliminateFrameIndex</tt> (eliminate abstract frame indices from
+ instructions that may use them)</li>
+
+ <li><tt>emitPrologue</tt> (insert prologue code into the function)</li>
+
+ <li><tt>emitEpilogue</tt> (insert epilogue code into the function)</li>
+ </ul>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="InstructionSet">Instruction Set</a>
+ </div>
+ <!-- *********************************************************************** -->
+ <div class="doc_text">
+ <p>During the early stages of code generation, the LLVM IR code is
+ converted to a SelectionDAG with nodes that are instances of the SDNode class
+ containing target instructions. An SDNode has an opcode, operands, type
+ requirements, and operation properties (for example, is an operation
+ commutative, does an operation load from memory). The various operation node
+ types are described in the <tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt> file (values
+ of the NodeType enum in the ISD namespace).</p>
+
+ <p>TableGen uses the following target description (.td) input files
+ to generate much of the code for instruction definition:</p>
+ <ul>
+ <li><tt>Target.td</tt>, where the Instruction, Operand, InstrInfo, and other
+ fundamental classes are defined</li>
+
+ <li><tt>TargetSelectionDAG.td</tt>, used by SelectionDAG instruction selection
+ generators, contains SDTC* classes (selection DAG type constraint), definitions
+ of SelectionDAG nodes (such as imm, cond, bb, add, fadd, sub), and pattern
+ support (Pattern, Pat, PatFrag, PatLeaf, ComplexPattern)</li>
+
+ <li><tt>XXXInstrFormats.td</tt>, patterns for definitions of target-specific
+ instructions</li>
+
+ <li><tt>XXXInstrInfo.td</tt>, target-specific definitions of instruction
+ templates, condition codes, and instructions of an instruction set. (For architecture
+ modifications, a different file name may be used. For example, for Pentium with
+ SSE instruction, this file is <tt>X86InstrSSE.td</tt>, and for Pentium with MMX, this
+ file is <tt>X86InstrMMX.td</tt>.)</li>
+ </ul>
+ <p>There is also a target-specific <tt>XXX.td</tt> file, where XXX is the
+ name of the target. The <tt>XXX.td</tt> file includes the other .td input files, but its
+ contents are only directly important for subtargets.</p>
+
+ <p>You should describe
+ a concrete target-specific class
+ XXXInstrInfo that represents machine
+ instructions supported by a target machine. XXXInstrInfo contains an array of
+ XXXInstrDescriptor objects, each of which describes one instruction. An
+ instruction descriptor defines:</p>
+ <ul>
+ <li>opcode mnemonic</li>
+
+ <li>number of operands</li>
+
+ <li>list of implicit register definitions and uses</li>
+
+ <li>target-independent properties (such as memory access, is
+ commutable)</li>
+
+ <li>target-specific flags </li>
+ </ul>
+
+ <p>The Instruction class (defined in <tt>Target.td</tt>) is mostly used as a
+ base for more complex instruction classes.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>class Instruction {
+ string Namespace = "";
+ dag OutOperandList; // An dag containing the MI def operand list.
+ dag InOperandList; // An dag containing the MI use operand list.
+ string AsmString = ""; // The .s format to print the instruction with.
+ list<dag> Pattern; // Set to the DAG pattern for this instruction
+ list<Register> Uses = [];
+ list<Register> Defs = [];
+ list<Predicate> Predicates = []; // predicates turned into isel match code
+ ... remainder not shown for space ...
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>A SelectionDAG node (SDNode) should contain an object
+ representing a target-specific instruction that is defined in <tt>XXXInstrInfo.td</tt>. The
+ instruction objects should represent instructions from the architecture manual
+ of the target machine (such as the
+ SPARC Architecture Manual for the SPARC target). </p>
+
+ <p>A single
+ instruction from the architecture manual is often modeled as multiple target
+ instructions, depending upon its operands. For example, a manual might
+ describe an add instruction that takes a register or an immediate operand. An
+ LLVM target could model this with two instructions named ADDri and ADDrr.</p>
+
+ <p>You should define a
+ class for each instruction category and define each opcode as a subclass of the
+ category with appropriate parameters such as the fixed binary encoding of
+ opcodes and extended opcodes. You should map the register bits to the bits of
+ the instruction in which they are encoded (for the JIT). Also you should specify
+ how the instruction should be printed when the automatic assembly printer is
+ used.</p>
+
+ <p>As is described in
+ the SPARC Architecture Manual, Version 8, there are three major 32-bit formats
+ for instructions. Format 1 is only for the CALL instruction. Format 2 is for
+ branch on condition codes and SETHI (set high bits of a register) instructions.
+ Format 3 is for other instructions. </p>
+
+ <p>Each of these
+ formats has corresponding classes in <tt>SparcInstrFormat.td</tt>. InstSP is a base
+ class for other instruction classes. Additional base classes are specified for
+ more precise formats: for example in <tt>SparcInstrFormat.td</tt>, F2_1 is for SETHI,
+ and F2_2 is for branches. There are three other base classes: F3_1 for
+ register/register operations, F3_2 for register/immediate operations, and F3_3 for
+ floating-point operations. <tt>SparcInstrInfo.td</tt> also adds the base class Pseudo for
+ synthetic SPARC instructions. </p>
+
+ <p><tt>SparcInstrInfo.td</tt>
+ largely consists of operand and instruction definitions for the SPARC target. In
+ <tt>SparcInstrInfo.td</tt>, the following target description file entry, LDrr, defines
+ the Load Integer instruction for a Word (the LD SPARC opcode) from a memory
+ address to a register. The first parameter, the value 3 (11<sub>2</sub>), is
+ the operation value for this category of operation. The second parameter
+ (000000<sub>2</sub>) is the specific operation value for LD/Load Word. The
+ third parameter is the output destination, which is a register operand and
+ defined in the Register target description file (IntRegs). </p>
+ </div>
+ <div class="doc_code">
+ <pre>def LDrr : F3_1 <3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
+ "ld [$addr], $dst",
+ [(set IntRegs:$dst, (load ADDRrr:$addr))]>;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>The fourth
+ parameter is the input source, which uses the address operand MEMrr that is
+ defined earlier in <tt>SparcInstrInfo.td</tt>:</p>
+ </div>
+ <div class="doc_code">
+ <pre>def MEMrr : Operand<i32> {
+ let PrintMethod = "printMemOperand";
+ let MIOperandInfo = (ops IntRegs, IntRegs);
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>The fifth parameter is a string that is used by the assembly
+ printer and can be left as an empty string until the assembly printer interface
+ is implemented. The sixth and final parameter is the pattern used to match the
+ instruction during the SelectionDAG Select Phase described in
+ (<a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM Target-Independent Code Generator</a>).
+ This parameter is detailed in the next section, <a href="#InstructionSelector">Instruction Selector</a>.</p>
+
+ <p>Instruction class definitions are not overloaded for different
+ operand types, so separate versions of instructions are needed for register,
+ memory, or immediate value operands. For example, to perform a
+ Load Integer instruction for a Word
+ from an immediate operand to a register, the following instruction class is
+ defined: </p>
+ </div>
+ <div class="doc_code">
+ <pre>def LDri : F3_2 <3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
+ "ld [$addr], $dst",
+ [(set IntRegs:$dst, (load ADDRri:$addr))]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>Writing these definitions for so many similar instructions can
+ involve a lot of cut and paste. In td files, the <tt>multiclass</tt> directive enables
+ the creation of templates to define several instruction classes at once (using
+ the <tt>defm</tt> directive). For example in
+ <tt>SparcInstrInfo.td</tt>, the <tt>multiclass</tt> pattern F3_12 is defined to create 2
+ instruction classes each time F3_12 is invoked: </p>
+ </div>
+ <div class="doc_code">
+ <pre>multiclass F3_12 <string OpcStr, bits<6> Op3Val, SDNode OpNode> {
+ def rr : F3_1 <2, Op3Val,
+ (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
+ !strconcat(OpcStr, " $b, $c, $dst"),
+ [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>;
+ def ri : F3_2 <2, Op3Val,
+ (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
+ !strconcat(OpcStr, " $b, $c, $dst"),
+ [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>;
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>So when the <tt>defm</tt> directive is used for the XOR and ADD
+ instructions, as seen below, it creates four instruction objects: XORrr, XORri,
+ ADDrr, and ADDri.</p>
+ </div>
+ <div class="doc_code">
+ <pre>defm XOR : F3_12<"xor", 0b000011, xor>;
+ defm ADD : F3_12<"add", 0b000000, add>;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p><tt>SparcInstrInfo.td</tt>
+ also includes definitions for condition codes that are referenced by branch
+ instructions. The following definitions in <tt>SparcInstrInfo.td</tt> indicate the bit location
+ of the SPARC condition code; for example, the 10<sup>th</sup> bit represents
+ the ‘greater than’ condition for integers, and the 22<sup>nd</sup> bit
+ represents the ‘greater than’ condition for floats. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def ICC_NE : ICC_VAL< 9>; // Not Equal
+ def ICC_E : ICC_VAL< 1>; // Equal
+ def ICC_G : ICC_VAL<10>; // Greater
+ ...
+ def FCC_U : FCC_VAL<23>; // Unordered
+ def FCC_G : FCC_VAL<22>; // Greater
+ def FCC_UG : FCC_VAL<21>; // Unordered or Greater
+ ...
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>(Note that <tt>Sparc.h</tt>
+ also defines enums that correspond to the same SPARC condition codes. Care must
+ be taken to ensure the values in <tt>Sparc.h</tt> correspond to the values in
+ <tt>SparcInstrInfo.td</tt>; that is, <tt>SPCC::ICC_NE = 9</tt>, <tt>SPCC::FCC_U = 23</tt> and so on.)</p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="operandMapping">Instruction Operand Mapping</a>
+ </div>
+ <div class="doc_text">
+ <p>The code generator backend maps instruction operands to fields in
+ the instruction. Operands are assigned to unbound fields in the instruction in
+ the order they are defined. Fields are bound when they are assigned a value.
+ For example, the Sparc target defines the XNORrr instruction as a F3_1 format
+ instruction having three operands.</p>
+ </div>
+
+ <div class="doc_code"> <pre>
+ def XNORrr : F3_1<2, 0b000111,
+ (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
+ "xnor $b, $c, $dst",
+ [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]>;
+ </pre></div>
+
+ <div class="doc_text">
+ <p>The instruction templates in <tt>SparcInstrFormats.td</tt> show the base class for F3_1 is InstSP.</p>
+ </div>
+
+ <div class="doc_code"> <pre>
+ class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction {
+ field bits<32> Inst;
+ let Namespace = "SP";
+ bits<2> op;
+ let Inst{31-30} = op;
+ dag OutOperandList = outs;
+ dag InOperandList = ins;
+ let AsmString = asmstr;
+ let Pattern = pattern;
+ }
+ </pre></div>
+ <div class="doc_text">
+ <p>
+ InstSP leaves the op field unbound.
+ </p>
+ </div>
+
+ <div class="doc_code"> <pre>
+ class F3<dag outs, dag ins, string asmstr, list<dag> pattern>
+ : InstSP<outs, ins, asmstr, pattern> {
+ bits<5> rd;
+ bits<6> op3;
+ bits<5> rs1;
+ let op{1} = 1; // Op = 2 or 3
+ let Inst{29-25} = rd;
+ let Inst{24-19} = op3;
+ let Inst{18-14} = rs1;
+ }
+ </pre></div>
+ <div class="doc_text">
+ <p>
+ F3 binds the op field and defines the rd, op3, and rs1 fields. F3 format instructions will
+ bind the operands rd, op3, and rs1 fields.
+ </p>
+ </div>
+
+ <div class="doc_code"> <pre>
+ class F3_1<bits<2> opVal, bits<6> op3val, dag outs, dag ins,
+ string asmstr, list<dag> pattern> : F3<outs, ins, asmstr, pattern> {
+ bits<8> asi = 0; // asi not currently used
+ bits<5> rs2;
+ let op = opVal;
+ let op3 = op3val;
+ let Inst{13} = 0; // i field = 0
+ let Inst{12-5} = asi; // address space identifier
+ let Inst{4-0} = rs2;
+ }
+ </pre></div>
+ <div class="doc_text">
+ <p>
+ F3_1 binds the op3 field and defines the rs2 fields. F3_1 format instructions will
+ bind the operands to the rd, rs1, and rs2 fields. This results in the XNORrr instruction
+ binding $dst, $b, and $c operands to the rd, rs1, and rs2 fields respectively.
+ </p>
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="implementInstr">Implement a subclass of </a>
+ <a href="http://www.llvm.org/docs/CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a>
+ </div>
+
+ <div class="doc_text">
+ <p>The final step is to hand code portions of XXXInstrInfo, which
+ implements the interface described in <tt>TargetInstrInfo.h</tt>. These functions return
+ 0 or a Boolean or they assert, unless overridden. Here's a list of functions
+ that are overridden for the SPARC implementation in <tt>SparcInstrInfo.cpp</tt>:</p>
+ <ul>
+ <li><tt>isMoveInstr</tt> (return true if the instruction is a register to
+ register move; false, otherwise)</li>
+
+ <li><tt>isLoadFromStackSlot</tt> (if the specified machine instruction is a
+ direct load from a stack slot, return the register number of the destination
+ and the FrameIndex of the stack slot)</li>
+
+ <li><tt>isStoreToStackSlot</tt> (if the specified machine instruction is a
+ direct store to a stack slot, return the register number of the destination and
+ the FrameIndex of the stack slot)</li>
+
+ <li><tt>copyRegToReg</tt> (copy values between a pair of registers)</li>
+
+ <li><tt>storeRegToStackSlot</tt> (store a register value to a stack slot)</li>
+
+ <li><tt>loadRegFromStackSlot</tt> (load a register value from a stack slot)</li>
+
+ <li><tt>storeRegToAddr</tt> (store a register value to memory)</li>
+
+ <li><tt>loadRegFromAddr</tt> (load a register value from memory)</li>
+
+ <li><tt>foldMemoryOperand</tt> (attempt to combine instructions of any load or
+ store instruction for the specified operand(s))</li>
+ </ul>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="branchFolding">Branch Folding and If Conversion</a>
+ </div>
+ <div class="doc_text">
+ <p>Performance can be improved by combining instructions or by eliminating
+ instructions that are never reached. The <tt>AnalyzeBranch</tt> method in XXXInstrInfo may
+ be implemented to examine conditional instructions and remove unnecessary
+ instructions. <tt>AnalyzeBranch</tt> looks at the end of a machine basic block (MBB) for
+ opportunities for improvement, such as branch folding and if conversion. The
+ <tt>BranchFolder</tt> and <tt>IfConverter</tt> machine function passes (see the source files
+ <tt>BranchFolding.cpp</tt> and <tt>IfConversion.cpp</tt> in the <tt>lib/CodeGen</tt> directory) call
+ <tt>AnalyzeBranch</tt> to improve the control flow graph that represents the
+ instructions. </p>
+
+ <p>Several implementations of <tt>AnalyzeBranch</tt> (for ARM, Alpha, and
+ X86) can be examined as models for your own <tt>AnalyzeBranch</tt> implementation. Since
+ SPARC does not implement a useful <tt>AnalyzeBranch</tt>, the ARM target implementation
+ is shown below.</p>
+
+ <p><tt>AnalyzeBranch</tt> returns a Boolean value and takes four parameters:</p>
+ <ul>
+ <li>MachineBasicBlock &MBB – the incoming block to be
+ examined</li>
+
+ <li>MachineBasicBlock *&TBB – a destination block that is
+ returned; for a conditional branch that evaluates to true, TBB is the
+ destination </li>
+
+ <li>MachineBasicBlock *&FBB – for a conditional branch that
+ evaluates to false, FBB is returned as the destination</li>
+
+ <li>std::vector<MachineOperand> &Cond – list of
+ operands to evaluate a condition for a conditional branch</li>
+ </ul>
+
+ <p>In the simplest case, if a block ends without a branch, then it
+ falls through to the successor block. No destination blocks are specified for
+ either TBB or FBB, so both parameters return NULL. The start of the <tt>AnalyzeBranch</tt>
+ (see code below for the ARM target) shows the function parameters and the code
+ for the simplest case.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &MBB,
+ MachineBasicBlock *&TBB, MachineBasicBlock *&FBB,
+ std::vector<MachineOperand> &Cond) const
+ {
+ MachineBasicBlock::iterator I = MBB.end();
+ if (I == MBB.begin() || !isUnpredicatedTerminator(--I))
+ return false;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>If a block ends with a single unconditional branch instruction,
+ then <tt>AnalyzeBranch</tt> (shown below) should return the destination of that branch
+ in the TBB parameter. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>if (LastOpc == ARM::B || LastOpc == ARM::tB) {
+ TBB = LastInst->getOperand(0).getMBB();
+ return false;
+ }
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>If a block ends with two unconditional branches, then the second
+ branch is never reached. In that situation, as shown below, remove the last
+ branch instruction and return the penultimate branch in the TBB parameter. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) &&
+ (LastOpc == ARM::B || LastOpc == ARM::tB)) {
+ TBB = SecondLastInst->getOperand(0).getMBB();
+ I = LastInst;
+ I->eraseFromParent();
+ return false;
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>A block may end with a single conditional branch instruction that
+ falls through to successor block if the condition evaluates to false. In that
+ case, <tt>AnalyzeBranch</tt> (shown below) should return the destination of that
+ conditional branch in the TBB parameter and a list of operands in the <tt>Cond</tt>
+ parameter to evaluate the condition. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) {
+ // Block ends with fall-through condbranch.
+ TBB = LastInst->getOperand(0).getMBB();
+ Cond.push_back(LastInst->getOperand(1));
+ Cond.push_back(LastInst->getOperand(2));
+ return false;
+ }
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>If a block ends with both a conditional branch and an ensuing
+ unconditional branch, then <tt>AnalyzeBranch</tt> (shown below) should return the
+ conditional branch destination (assuming it corresponds to a conditional
+ evaluation of ‘true’) in the TBB parameter and the unconditional branch
+ destination in the FBB (corresponding to a conditional evaluation of ‘false’).
+ A list of operands to evaluate the condition should be returned in the <tt>Cond</tt>
+ parameter.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>unsigned SecondLastOpc = SecondLastInst->getOpcode();
+ if ((SecondLastOpc == ARM::Bcc && LastOpc == ARM::B) ||
+ (SecondLastOpc == ARM::tBcc && LastOpc == ARM::tB)) {
+ TBB = SecondLastInst->getOperand(0).getMBB();
+ Cond.push_back(SecondLastInst->getOperand(1));
+ Cond.push_back(SecondLastInst->getOperand(2));
+ FBB = LastInst->getOperand(0).getMBB();
+ return false;
+ }
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>For the last two cases (ending with a single conditional branch or
+ ending with one conditional and one unconditional branch), the operands returned
+ in the <tt>Cond</tt> parameter can be passed to methods of other instructions to create
+ new branches or perform other operations. An implementation of <tt>AnalyzeBranch</tt>
+ requires the helper methods <tt>RemoveBranch</tt> and <tt>InsertBranch</tt> to manage subsequent
+ operations.</p>
+
+ <p><tt>AnalyzeBranch</tt> should return false indicating success in most circumstances.
+ <tt>AnalyzeBranch</tt> should only return true when the method is stumped about what to
+ do, for example, if a block has three terminating branches. <tt>AnalyzeBranch</tt> may
+ return true if it encounters a terminator it cannot handle, such as an indirect
+ branch.</p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="InstructionSelector">Instruction Selector</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>LLVM uses a SelectionDAG to represent LLVM IR instructions, and nodes
+ of the SelectionDAG ideally represent native target instructions. During code
+ generation, instruction selection passes are performed to convert non-native
+ DAG instructions into native target-specific instructions. The pass described
+ in <tt>XXXISelDAGToDAG.cpp</tt> is used to match patterns and perform DAG-to-DAG
+ instruction selection. Optionally, a pass may be defined (in
+ <tt>XXXBranchSelector.cpp</tt>) to perform similar DAG-to-DAG operations for branch
+ instructions. Later,
+ the code in <tt>XXXISelLowering.cpp</tt> replaces or removes operations and data types
+ not supported natively (legalizes) in a Selection DAG. </p>
+
+ <p>TableGen generates code for instruction selection using the
+ following target description input files:</p>
+ <ul>
+ <li><tt>XXXInstrInfo.td</tt> contains definitions of instructions in a
+ target-specific instruction set, generates <tt>XXXGenDAGISel.inc</tt>, which is included
+ in <tt>XXXISelDAGToDAG.cpp</tt>. </li>
+
+ <li><tt>XXXCallingConv.td</tt> contains the calling and return value conventions
+ for the target architecture, and it generates <tt>XXXGenCallingConv.inc</tt>, which is
+ included in <tt>XXXISelLowering.cpp</tt>.</li>
+ </ul>
+
+ <p>The implementation of an instruction selection pass must include
+ a header that declares the FunctionPass class or a subclass of FunctionPass. In
+ <tt>XXXTargetMachine.cpp</tt>, a Pass Manager (PM) should add each instruction selection
+ pass into the queue of passes to run.</p>
+
+ <p>The LLVM static
+ compiler (<tt>llc</tt>) is an excellent tool for visualizing the contents of DAGs. To display
+ the SelectionDAG before or after specific processing phases, use the command
+ line options for <tt>llc</tt>, described at <a
+ href="http://llvm.org/docs/CodeGenerator.html#selectiondag_process">
+ SelectionDAG Instruction Selection Process</a>.
+ </p>
+
+ <p>To describe instruction selector behavior, you should add
+ patterns for lowering LLVM code into a SelectionDAG as the last parameter of
+ the instruction definitions in <tt>XXXInstrInfo.td</tt>. For example, in
+ <tt>SparcInstrInfo.td</tt>, this entry defines a register store operation, and the last
+ parameter describes a pattern with the store DAG operator.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def STrr : F3_1< 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
+ "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]>;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>ADDRrr is a memory mode that is also defined in <tt>SparcInstrInfo.td</tt>:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def ADDRrr : ComplexPattern<i32, 2, "SelectADDRrr", [], []>;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>The definition of ADDRrr refers to SelectADDRrr, which is a function defined in an
+ implementation of the Instructor Selector (such as <tt>SparcISelDAGToDAG.cpp</tt>). </p>
+
+ <p>In <tt>lib/Target/TargetSelectionDAG.td</tt>, the DAG operator for store
+ is defined below:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def store : PatFrag<(ops node:$val, node:$ptr),
+ (st node:$val, node:$ptr), [{
+ if (StoreSDNode *ST = dyn_cast<StoreSDNode>(N))
+ return !ST->isTruncatingStore() &&
+ ST->getAddressingMode() == ISD::UNINDEXED;
+ return false;
+ }]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p><tt>XXXInstrInfo.td</tt> also generates (in <tt>XXXGenDAGISel.inc</tt>) the
+ <tt>SelectCode</tt> method that is used to call the appropriate processing method for an
+ instruction. In this example, <tt>SelectCode</tt> calls <tt>Select_ISD_STORE</tt> for the
+ ISD::STORE opcode.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>SDNode *SelectCode(SDValue N) {
+ ...
+ MVT::ValueType NVT = N.getNode()->getValueType(0);
+ switch (N.getOpcode()) {
+ case ISD::STORE: {
+ switch (NVT) {
+ default:
+ return Select_ISD_STORE(N);
+ break;
+ }
+ break;
+ }
+ ...
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>The pattern for STrr is matched, so elsewhere in
+ <tt>XXXGenDAGISel.inc</tt>, code for STrr is created for <tt>Select_ISD_STORE</tt>. The <tt>Emit_22</tt> method
+ is also generated in <tt>XXXGenDAGISel.inc</tt> to complete the processing of this
+ instruction. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>SDNode *Select_ISD_STORE(const SDValue &N) {
+ SDValue Chain = N.getOperand(0);
+ if (Predicate_store(N.getNode())) {
+ SDValue N1 = N.getOperand(1);
+ SDValue N2 = N.getOperand(2);
+ SDValue CPTmp0;
+ SDValue CPTmp1;
+
+ // Pattern: (st:void IntRegs:i32:$src,
+ // ADDRrr:i32:$addr)<<P:Predicate_store>>
+ // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)
+ // Pattern complexity = 13 cost = 1 size = 0
+ if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) &&
+ N1.getNode()->getValueType(0) == MVT::i32 &&
+ N2.getNode()->getValueType(0) == MVT::i32) {
+ return Emit_22(N, SP::STrr, CPTmp0, CPTmp1);
+ }
+ ...
+ </pre>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="LegalizePhase">The SelectionDAG Legalize Phase</a>
+ </div>
+ <div class="doc_text">
+ <p>The Legalize phase converts a DAG to use types and operations
+ that are natively supported by the target. For natively unsupported types and
+ operations, you need to add code to the target-specific XXXTargetLowering implementation
+ to convert unsupported types and operations to supported ones.</p>
+
+ <p>In the constructor for the XXXTargetLowering class, first use the
+ <tt>addRegisterClass</tt> method to specify which types are supports and which register
+ classes are associated with them. The code for the register classes are generated
+ by TableGen from <tt>XXXRegisterInfo.td</tt> and placed in <tt>XXXGenRegisterInfo.h.inc</tt>. For
+ example, the implementation of the constructor for the SparcTargetLowering
+ class (in <tt>SparcISelLowering.cpp</tt>) starts with the following code:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>addRegisterClass(MVT::i32, SP::IntRegsRegisterClass);
+ addRegisterClass(MVT::f32, SP::FPRegsRegisterClass);
+ addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass);
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>You should examine the node types in the ISD namespace
+ (<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>)
+ and determine which operations the target natively supports. For operations
+ that do <b>not</b> have native support, add a callback to the constructor for
+ the XXXTargetLowering class, so the instruction selection process knows what to
+ do. The TargetLowering class callback methods (declared in
+ <tt>llvm/Target/TargetLowering.h</tt>) are:</p>
+ <ul>
+ <li><tt>setOperationAction</tt> (general operation)</li>
+
+ <li><tt>setLoadExtAction</tt> (load with extension)</li>
+
+ <li><tt>setTruncStoreAction</tt> (truncating store)</li>
+
+ <li><tt>setIndexedLoadAction</tt> (indexed load)</li>
+
+ <li><tt>setIndexedStoreAction</tt> (indexed store)</li>
+
+ <li><tt>setConvertAction</tt> (type conversion)</li>
+
+ <li><tt>setCondCodeAction</tt> (support for a given condition code)</li>
+ </ul>
+
+ <p>Note: on older releases, <tt>setLoadXAction</tt> is used instead of <tt>setLoadExtAction</tt>.
+ Also, on older releases, <tt>setCondCodeAction</tt> may not be supported. Examine your
+ release to see what methods are specifically supported.</p>
+
+ <p>These callbacks are used to determine that an operation does or
+ does not work with a specified type (or types). And in all cases, the third
+ parameter is a LegalAction type enum value: <tt>Promote</tt>, <tt>Expand</tt>,
+ <tt>Custom</tt>, or <tt>Legal</tt>. <tt>SparcISelLowering.cpp</tt>
+ contains examples of all four LegalAction values.</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="promote">Promote</a>
+ </div>
+
+ <div class="doc_text">
+ <p>For an operation without native support for a given type, the
+ specified type may be promoted to a larger type that is supported. For example,
+ SPARC does not support a sign-extending load for Boolean values (<tt>i1</tt> type), so
+ in <tt>SparcISelLowering.cpp</tt> the third
+ parameter below, <tt>Promote</tt>, changes <tt>i1</tt> type
+ values to a large type before loading.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="expand">Expand</a>
+ </div>
+ <div class="doc_text">
+ <p>For a type without native support, a value may need to be broken
+ down further, rather than promoted. For an operation without native support, a
+ combination of other operations may be used to similar effect. In SPARC, the
+ floating-point sine and cosine trig operations are supported by expansion to
+ other operations, as indicated by the third parameter, <tt>Expand</tt>, to
+ <tt>setOperationAction</tt>:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>setOperationAction(ISD::FSIN, MVT::f32, Expand);
+ setOperationAction(ISD::FCOS, MVT::f32, Expand);
+ </pre>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="custom">Custom</a>
+ </div>
+ <div class="doc_text">
+ <p>For some operations, simple type promotion or operation expansion
+ may be insufficient. In some cases, a special intrinsic function must be
+ implemented. </p>
+
+ <p>For example, a constant value may require special treatment, or
+ an operation may require spilling and restoring registers in the stack and
+ working with register allocators. </p>
+
+ <p>As seen in <tt>SparcISelLowering.cpp</tt> code below, to perform a type
+ conversion from a floating point value to a signed integer, first the
+ <tt>setOperationAction</tt> should be called with <tt>Custom</tt> as the third parameter:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>In the <tt>LowerOperation</tt> method, for each <tt>Custom</tt> operation, a case
+ statement should be added to indicate what function to call. In the following
+ code, an FP_TO_SINT opcode will call the <tt>LowerFP_TO_SINT</tt> method:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>SDValue SparcTargetLowering::LowerOperation(
+ SDValue Op, SelectionDAG &DAG) {
+ switch (Op.getOpcode()) {
+ case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG);
+ ...
+ }
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>Finally, the <tt>LowerFP_TO_SINT</tt> method is implemented, using an FP
+ register to convert the floating-point value to an integer.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) {
+ assert(Op.getValueType() == MVT::i32);
+ Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0));
+ return DAG.getNode(ISD::BIT_CONVERT, MVT::i32, Op);
+ }
+ </pre>
+ </div>
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="legal">Legal</a>
+ </div>
+ <div class="doc_text">
+ <p>The <tt>Legal</tt> LegalizeAction enum value simply indicates that an
+ operation <b>is</b> natively supported. <tt>Legal</tt> represents the default condition,
+ so it is rarely used. In <tt>SparcISelLowering.cpp</tt>, the action for CTPOP (an
+ operation to count the bits set in an integer) is natively supported only for
+ SPARC v9. The following code enables the <tt>Expand</tt> conversion technique for non-v9
+ SPARC implementations.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>setOperationAction(ISD::CTPOP, MVT::i32, Expand);
+ ...
+ if (TM.getSubtarget<SparcSubtarget>().isV9())
+ setOperationAction(ISD::CTPOP, MVT::i32, Legal);
+ case ISD::SETULT: return SPCC::ICC_CS;
+ case ISD::SETULE: return SPCC::ICC_LEU;
+ case ISD::SETUGT: return SPCC::ICC_GU;
+ case ISD::SETUGE: return SPCC::ICC_CC;
+ }
+ }
+ </pre>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="callingConventions">Calling Conventions</a>
+ </div>
+ <div class="doc_text">
+ <p>To support target-specific calling conventions, <tt>XXXGenCallingConv.td</tt>
+ uses interfaces (such as CCIfType and CCAssignToReg) that are defined in
+ <tt>lib/Target/TargetCallingConv.td</tt>. TableGen can take the target descriptor file
+ <tt>XXXGenCallingConv.td</tt> and generate the header file <tt>XXXGenCallingConv.inc</tt>, which
+ is typically included in <tt>XXXISelLowering.cpp</tt>. You can use the interfaces in
+ <tt>TargetCallingConv.td</tt> to specify:</p>
+ <ul>
+ <li>the order of parameter allocation</li>
+
+ <li>where parameters and return values are placed (that is, on the
+ stack or in registers)</li>
+
+ <li>which registers may be used</li>
+
+ <li>whether the caller or callee unwinds the stack</li>
+ </ul>
+
+ <p>The following example demonstrates the use of the CCIfType and
+ CCAssignToReg interfaces. If the CCIfType predicate is true (that is, if the
+ current argument is of type f32 or f64), then the action is performed. In this
+ case, the CCAssignToReg action assigns the argument value to the first
+ available register: either R0 or R1. </p>
+ </div>
+ <div class="doc_code">
+ <pre>CCIfType<[f32,f64], CCAssignToReg<[R0, R1]>>
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p><tt>SparcCallingConv.td</tt> contains definitions for a target-specific return-value
+ calling convention (RetCC_Sparc32) and a basic 32-bit C calling convention
+ (CC_Sparc32). The definition of RetCC_Sparc32 (shown below) indicates which
+ registers are used for specified scalar return types. A single-precision float
+ is returned to register F0, and a double-precision float goes to register D0. A
+ 32-bit integer is returned in register I0 or I1. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def RetCC_Sparc32 : CallingConv<[
+ CCIfType<[i32], CCAssignToReg<[I0, I1]>>,
+ CCIfType<[f32], CCAssignToReg<[F0]>>,
+ CCIfType<[f64], CCAssignToReg<[D0]>>
+ ]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>The definition of CC_Sparc32 in <tt>SparcCallingConv.td</tt> introduces
+ CCAssignToStack, which assigns the value to a stack slot with the specified size
+ and alignment. In the example below, the first parameter, 4, indicates the size
+ of the slot, and the second parameter, also 4, indicates the stack alignment
+ along 4-byte units. (Special cases: if size is zero, then the ABI size is used;
+ if alignment is zero, then the ABI alignment is used.) </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def CC_Sparc32 : CallingConv<[
+ // All arguments get passed in integer registers if there is space.
+ CCIfType<[i32, f32, f64], CCAssignToReg<[I0, I1, I2, I3, I4, I5]>>,
+ CCAssignToStack<4, 4>
+ ]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>CCDelegateTo is another commonly used interface, which tries to find
+ a specified sub-calling convention and, if a match is found, it is invoked. In
+ the following example (in <tt>X86CallingConv.td</tt>), the definition of RetCC_X86_32_C
+ ends with CCDelegateTo. After the current value is assigned to the register ST0
+ or ST1, the RetCC_X86Common is invoked.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def RetCC_X86_32_C : CallingConv<[
+ CCIfType<[f32], CCAssignToReg<[ST0, ST1]>>,
+ CCIfType<[f64], CCAssignToReg<[ST0, ST1]>>,
+ CCDelegateTo<RetCC_X86Common>
+ ]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>CCIfCC is an interface that attempts to match the given name to
+ the current calling convention. If the name identifies the current calling
+ convention, then a specified action is invoked. In the following example (in
+ <tt>X86CallingConv.td</tt>), if the Fast calling convention is in use, then RetCC_X86_32_Fast
+ is invoked. If the SSECall calling convention is in use, then RetCC_X86_32_SSE
+ is invoked. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def RetCC_X86_32 : CallingConv<[
+ CCIfCC<"CallingConv::Fast", CCDelegateTo<RetCC_X86_32_Fast>>,
+ CCIfCC<"CallingConv::X86_SSECall", CCDelegateTo<RetCC_X86_32_SSE>>,
+ CCDelegateTo<RetCC_X86_32_C>
+ ]>;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>Other calling convention interfaces include:</p>
+ <ul>
+ <li>CCIf <predicate, action> - if the predicate matches, apply
+ the action</li>
+
+ <li>CCIfInReg <action> - if the argument is marked with the
+ ‘inreg’ attribute, then apply the action </li>
+
+ <li>CCIfNest <action> - if the argument is marked with the
+ ‘nest’ attribute, then apply the action</li>
+
+ <li>CCIfNotVarArg <action> - if the current function does not
+ take a variable number of arguments, apply the action</li>
+
+ <li>CCAssignToRegWithShadow <registerList, shadowList> -
+ similar to CCAssignToReg, but with a shadow list of registers</li>
+
+ <li>CCPassByVal <size, align> - assign value to a stack slot
+ with the minimum specified size and alignment </li>
+
+ <li>CCPromoteToType <type> - promote the current value to the specified
+ type</li>
+
+ <li>CallingConv <[actions]> - define each calling convention
+ that is supported</li>
+ </ul>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="assemblyPrinter">Assembly Printer</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>During the code
+ emission stage, the code generator may utilize an LLVM pass to produce assembly
+ output. To do this, you want to implement the code for a printer that converts
+ LLVM IR to a GAS-format assembly language for your target machine, using the
+ following steps:</p>
+ <ul>
+ <li>Define all the assembly strings for your target, adding them to
+ the instructions defined in the <tt>XXXInstrInfo.td</tt> file.
+ (See <a href="#InstructionSet">Instruction Set</a>.)
+ TableGen will produce an output file (<tt>XXXGenAsmWriter.inc</tt>) with an
+ implementation of the <tt>printInstruction</tt> method for the XXXAsmPrinter class.</li>
+
+ <li>Write <tt>XXXTargetAsmInfo.h</tt>, which contains the bare-bones
+ declaration of the XXXTargetAsmInfo class (a subclass of TargetAsmInfo). </li>
+
+ <li>Write <tt>XXXTargetAsmInfo.cpp</tt>, which contains target-specific values
+ for TargetAsmInfo properties and sometimes new implementations for methods</li>
+
+ <li>Write <tt>XXXAsmPrinter.cpp</tt>, which implements the AsmPrinter class
+ that performs the LLVM-to-assembly conversion. </li>
+ </ul>
+
+ <p>The code in <tt>XXXTargetAsmInfo.h</tt> is usually a trivial declaration
+ of the XXXTargetAsmInfo class for use in <tt>XXXTargetAsmInfo.cpp</tt>. Similarly,
+ <tt>XXXTargetAsmInfo.cpp</tt> usually has a few declarations of XXXTargetAsmInfo replacement
+ values that override the default values in <tt>TargetAsmInfo.cpp</tt>. For example in
+ <tt>SparcTargetAsmInfo.cpp</tt>, </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) {
+ Data16bitsDirective = "\t.half\t";
+ Data32bitsDirective = "\t.word\t";
+ Data64bitsDirective = 0; // .xword is only supported by V9.
+ ZeroDirective = "\t.skip\t";
+ CommentString = "!";
+ ConstantPoolSection = "\t.section \".rodata\",#alloc\n";
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>The X86 assembly printer implementation (X86TargetAsmInfo) is an
+ example where the target specific TargetAsmInfo class uses overridden methods:
+ <tt>ExpandInlineAsm</tt> and <tt>PreferredEHDataFormat</tt>. </p>
+
+ <p>A target-specific implementation of AsmPrinter is written in
+ <tt>XXXAsmPrinter.cpp</tt>, which implements the AsmPrinter class that converts the LLVM
+ to printable assembly. The implementation must include the following headers
+ that have declarations for the AsmPrinter and MachineFunctionPass classes. The
+ MachineFunctionPass is a subclass of FunctionPass. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>#include "llvm/CodeGen/AsmPrinter.h"
+ #include "llvm/CodeGen/MachineFunctionPass.h"
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>As a FunctionPass, AsmPrinter first calls <tt>doInitialization</tt> to set
+ up the AsmPrinter. In SparcAsmPrinter, a Mangler object is instantiated to
+ process variable names.</p>
+
+ <p>In <tt>XXXAsmPrinter.cpp</tt>, the <tt>runOnMachineFunction</tt> method (declared
+ in MachineFunctionPass) must be implemented for XXXAsmPrinter. In
+ MachineFunctionPass, the <tt>runOnFunction</tt> method invokes <tt>runOnMachineFunction</tt>.
+ Target-specific implementations of <tt>runOnMachineFunction</tt> differ, but generally
+ do the following to process each machine function:</p>
+ <ul>
+ <li>call <tt>SetupMachineFunction</tt> to perform initialization</li>
+
+ <li>call <tt>EmitConstantPool</tt> to print out (to the output stream)
+ constants which have been spilled to memory </li>
+
+ <li>call <tt>EmitJumpTableInfo</tt> to print out jump tables used by the
+ current function </li>
+
+ <li>print out the label for the current function</li>
+
+ <li>print out the code for the function, including basic block labels
+ and the assembly for the instruction (using <tt>printInstruction</tt>)</li>
+ </ul>
+ <p>The XXXAsmPrinter implementation must also include the code
+ generated by TableGen that is output in the <tt>XXXGenAsmWriter.inc</tt> file. The code
+ in <tt>XXXGenAsmWriter.inc</tt> contains an implementation of the <tt>printInstruction</tt>
+ method that may call these methods:</p>
+ <ul>
+ <li><tt>printOperand</tt></li>
+
+ <li><tt>printMemOperand</tt></li>
+
+ <li><tt>printCCOperand (for conditional statements)</tt></li>
+
+ <li><tt>printDataDirective</tt></li>
+
+ <li><tt>printDeclare</tt></li>
+
+ <li><tt>printImplicitDef</tt></li>
+
+ <li><tt>printInlineAsm</tt></li>
+
+ <li><tt>printLabel</tt></li>
+
+ <li><tt>printPICJumpTableEntry</tt></li>
+
+ <li><tt>printPICJumpTableSetLabel</tt></li>
+ </ul>
+
+ <p>The implementations of <tt>printDeclare</tt>, <tt>printImplicitDef</tt>,
+ <tt>printInlineAsm</tt>, and <tt>printLabel</tt> in <tt>AsmPrinter.cpp</tt> are generally adequate for
+ printing assembly and do not need to be overridden. (<tt>printBasicBlockLabel</tt> is
+ another method that is implemented in <tt>AsmPrinter.cpp</tt> that may be directly used
+ in an implementation of XXXAsmPrinter.)</p>
+
+ <p>The <tt>printOperand</tt> method is implemented with a long switch/case
+ statement for the type of operand: register, immediate, basic block, external
+ symbol, global address, constant pool index, or jump table index. For an
+ instruction with a memory address operand, the <tt>printMemOperand</tt> method should be
+ implemented to generate the proper output. Similarly, <tt>printCCOperand</tt> should be
+ used to print a conditional operand. </p>
+
+ <p><tt>doFinalization</tt> should be overridden in XXXAsmPrinter, and
+ it should be called to shut down the assembly printer. During <tt>doFinalization</tt>,
+ global variables and constants are printed to output.</p>
+ </div>
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="subtargetSupport">Subtarget Support</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>Subtarget support is used to inform the code generation process
+ of instruction set variations for a given chip set. For example, the LLVM
+ SPARC implementation provided covers three major versions of the SPARC
+ microprocessor architecture: Version 8 (V8, which is a 32-bit architecture),
+ Version 9 (V9, a 64-bit architecture), and the UltraSPARC architecture. V8 has
+ 16 double-precision floating-point registers that are also usable as either 32
+ single-precision or 8 quad-precision registers. V8 is also purely big-endian. V9
+ has 32 double-precision floating-point registers that are also usable as 16
+ quad-precision registers, but cannot be used as single-precision registers. The
+ UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set
+ extensions.</p>
+
+ <p>If subtarget support is needed, you should implement a
+ target-specific XXXSubtarget class for your architecture. This class should
+ process the command-line options <tt>–mcpu=</tt> and <tt>–mattr=</tt></p>
+
+ <p>TableGen uses definitions in the <tt>Target.td</tt> and <tt>Sparc.td</tt> files to
+ generate code in <tt>SparcGenSubtarget.inc</tt>. In <tt>Target.td</tt>, shown below, the
+ SubtargetFeature interface is defined. The first 4 string parameters of the
+ SubtargetFeature interface are a feature name, an attribute set by the feature,
+ the value of the attribute, and a description of the feature. (The fifth
+ parameter is a list of features whose presence is implied, and its default
+ value is an empty array.)</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>class SubtargetFeature<string n, string a, string v, string d,
+ list<SubtargetFeature> i = []> {
+ string Name = n;
+ string Attribute = a;
+ string Value = v;
+ string Desc = d;
+ list<SubtargetFeature> Implies = i;
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>In the <tt>Sparc.td</tt> file, the SubtargetFeature is used to define the
+ following features. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>def FeatureV9 : SubtargetFeature<"v9", "IsV9", "true",
+ "Enable SPARC-V9 instructions">;
+ def FeatureV8Deprecated : SubtargetFeature<"deprecated-v8",
+ "V8DeprecatedInsts", "true",
+ "Enable deprecated V8 instructions in V9 mode">;
+ def FeatureVIS : SubtargetFeature<"vis", "IsVIS", "true",
+ "Enable UltraSPARC Visual Instruction Set extensions">;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>Elsewhere in <tt>Sparc.td</tt>, the Proc class is defined and then is used
+ to define particular SPARC processor subtypes that may have the previously
+ described features. </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>class Proc<string Name, list<SubtargetFeature> Features>
+ : Processor<Name, NoItineraries, Features>;
+
+ def : Proc<"generic", []>;
+ def : Proc<"v8", []>;
+ def : Proc<"supersparc", []>;
+ def : Proc<"sparclite", []>;
+ def : Proc<"f934", []>;
+ def : Proc<"hypersparc", []>;
+ def : Proc<"sparclite86x", []>;
+ def : Proc<"sparclet", []>;
+ def : Proc<"tsc701", []>;
+ def : Proc<"v9", [FeatureV9]>;
+ def : Proc<"ultrasparc", [FeatureV9, FeatureV8Deprecated]>;
+ def : Proc<"ultrasparc3", [FeatureV9, FeatureV8Deprecated]>;
+ def : Proc<"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]>;
+ </pre>
+ </div>
+
+ <div class="doc_text">
+ <p>From <tt>Target.td</tt> and <tt>Sparc.td</tt> files, the resulting
+ SparcGenSubtarget.inc specifies enum values to identify the features, arrays of
+ constants to represent the CPU features and CPU subtypes, and the
+ ParseSubtargetFeatures method that parses the features string that sets
+ specified subtarget options. The generated <tt>SparcGenSubtarget.inc</tt> file should be
+ included in the <tt>SparcSubtarget.cpp</tt>. The target-specific implementation of the XXXSubtarget
+ method should follow this pseudocode:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) {
+ // Set the default features
+ // Determine default and user specified characteristics of the CPU
+ // Call ParseSubtargetFeatures(FS, CPU) to parse the features string
+ // Perform any additional operations
+ }
+ </pre>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="jitSupport">JIT Support</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>The implementation of a target machine optionally includes a Just-In-Time
+ (JIT) code generator that emits machine code and auxiliary structures as binary
+ output that can be written directly to memory.
+ To do this, implement JIT code generation by performing the following
+ steps:</p>
+ <ul>
+ <li>Write an <tt>XXXCodeEmitter.cpp</tt> file that contains a machine function
+ pass that transforms target-machine instructions into relocatable machine code.</li>
+
+ <li>Write an <tt>XXXJITInfo.cpp</tt> file that implements the JIT interfaces
+ for target-specific code-generation
+ activities, such as emitting machine code and stubs. </li>
+
+ <li>Modify XXXTargetMachine so that it provides a TargetJITInfo
+ object through its <tt>getJITInfo</tt> method. </li>
+ </ul>
+
+ <p>There are several different approaches to writing the JIT support
+ code. For instance, TableGen and target descriptor files may be used for
+ creating a JIT code generator, but are not mandatory. For the Alpha and PowerPC
+ target machines, TableGen is used to generate <tt>XXXGenCodeEmitter.inc</tt>, which
+ contains the binary coding of machine instructions and the
+ <tt>getBinaryCodeForInstr</tt> method to access those codes. Other JIT implementations
+ do not.</p>
+
+ <p>Both <tt>XXXJITInfo.cpp</tt> and <tt>XXXCodeEmitter.cpp</tt> must include the
+ <tt>llvm/CodeGen/MachineCodeEmitter.h</tt> header file that defines the MachineCodeEmitter
+ class containing code for several callback functions that write data (in bytes,
+ words, strings, etc.) to the output stream.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="mce">Machine Code Emitter</a>
+ </div>
+
+ <div class="doc_text">
+ <p>In <tt>XXXCodeEmitter.cpp</tt>, a target-specific of the Emitter class is
+ implemented as a function pass (subclass of MachineFunctionPass). The
+ target-specific implementation of <tt>runOnMachineFunction</tt> (invoked by
+ <tt>runOnFunction</tt> in MachineFunctionPass) iterates through the MachineBasicBlock
+ calls <tt>emitInstruction</tt> to process each instruction and emit binary code. <tt>emitInstruction</tt>
+ is largely implemented with case statements on the instruction types defined in
+ <tt>XXXInstrInfo.h</tt>. For example, in <tt>X86CodeEmitter.cpp</tt>, the <tt>emitInstruction</tt> method
+ is built around the following switch/case statements:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>switch (Desc->TSFlags & X86::FormMask) {
+ case X86II::Pseudo: // for not yet implemented instructions
+ ... // or pseudo-instructions
+ break;
+ case X86II::RawFrm: // for instructions with a fixed opcode value
+ ...
+ break;
+ case X86II::AddRegFrm: // for instructions that have one register operand
+ ... // added to their opcode
+ break;
+ case X86II::MRMDestReg:// for instructions that use the Mod/RM byte
+ ... // to specify a destination (register)
+ break;
+ case X86II::MRMDestMem:// for instructions that use the Mod/RM byte
+ ... // to specify a destination (memory)
+ break;
+ case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte
+ ... // to specify a source (register)
+ break;
+ case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte
+ ... // to specify a source (memory)
+ break;
+ case X86II::MRM0r: case X86II::MRM1r: // for instructions that operate on
+ case X86II::MRM2r: case X86II::MRM3r: // a REGISTER r/m operand and
+ case X86II::MRM4r: case X86II::MRM5r: // use the Mod/RM byte and a field
+ case X86II::MRM6r: case X86II::MRM7r: // to hold extended opcode data
+ ...
+ break;
+ case X86II::MRM0m: case X86II::MRM1m: // for instructions that operate on
+ case X86II::MRM2m: case X86II::MRM3m: // a MEMORY r/m operand and
+ case X86II::MRM4m: case X86II::MRM5m: // use the Mod/RM byte and a field
+ case X86II::MRM6m: case X86II::MRM7m: // to hold extended opcode data
+ ...
+ break;
+ case X86II::MRMInitReg: // for instructions whose source and
+ ... // destination are the same register
+ break;
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>The implementations of these case statements often first emit the
+ opcode and then get the operand(s). Then depending upon the operand, helper
+ methods may be called to process the operand(s). For example, in <tt>X86CodeEmitter.cpp</tt>,
+ for the <tt>X86II::AddRegFrm</tt> case, the first data emitted (by <tt>emitByte</tt>) is the
+ opcode added to the register operand. Then an object representing the machine
+ operand, MO1, is extracted. The helper methods such as <tt>isImmediate</tt>,
+ <tt>isGlobalAddress</tt>, <tt>isExternalSymbol</tt>, <tt>isConstantPoolIndex</tt>, and
+ <tt>isJumpTableIndex</tt>
+ determine the operand type. (<tt>X86CodeEmitter.cpp</tt> also has private methods such
+ as <tt>emitConstant</tt>, <tt>emitGlobalAddress</tt>,
+ <tt>emitExternalSymbolAddress</tt>, <tt>emitConstPoolAddress</tt>,
+ and <tt>emitJumpTableAddress</tt> that emit the data into the output stream.) </p>
+ </div>
+
+ <div class="doc_code">
+ <pre>case X86II::AddRegFrm:
+ MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg()));
+
+ if (CurOp != NumOps) {
+ const MachineOperand &MO1 = MI.getOperand(CurOp++);
+ unsigned Size = X86InstrInfo::sizeOfImm(Desc);
+ if (MO1.isImmediate())
+ emitConstant(MO1.getImm(), Size);
+ else {
+ unsigned rt = Is64BitMode ? X86::reloc_pcrel_word
+ : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word);
+ if (Opcode == X86::MOV64ri)
+ rt = X86::reloc_absolute_dword; // FIXME: add X86II flag?
+ if (MO1.isGlobalAddress()) {
+ bool NeedStub = isa<Function>(MO1.getGlobal());
+ bool isLazy = gvNeedsLazyPtr(MO1.getGlobal());
+ emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0,
+ NeedStub, isLazy);
+ } else if (MO1.isExternalSymbol())
+ emitExternalSymbolAddress(MO1.getSymbolName(), rt);
+ else if (MO1.isConstantPoolIndex())
+ emitConstPoolAddress(MO1.getIndex(), rt);
+ else if (MO1.isJumpTableIndex())
+ emitJumpTableAddress(MO1.getIndex(), rt);
+ }
+ }
+ break;
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>In the previous example, <tt>XXXCodeEmitter.cpp</tt> uses the variable <tt>rt</tt>,
+ which is a RelocationType enum that may be used to relocate addresses (for
+ example, a global address with a PIC base offset). The RelocationType enum for
+ that target is defined in the short target-specific <tt>XXXRelocations.h</tt> file. The
+ RelocationType is used by the <tt>relocate</tt> method defined in <tt>XXXJITInfo.cpp</tt> to
+ rewrite addresses for referenced global symbols.</p>
+
+ <p>For example, <tt>X86Relocations.h</tt> specifies the following relocation
+ types for the X86 addresses. In all four cases, the relocated value is added to
+ the value already in memory. For <tt>reloc_pcrel_word</tt> and <tt>reloc_picrel_word</tt>,
+ there is an additional initial adjustment.</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>enum RelocationType {
+ reloc_pcrel_word = 0, // add reloc value after adjusting for the PC loc
+ reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base
+ reloc_absolute_word = 2, // absolute relocation; no additional adjustment
+ reloc_absolute_dword = 3 // absolute relocation; no additional adjustment
+ };
+ </pre>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="targetJITInfo">Target JIT Info</a>
+ </div>
+ <div class="doc_text">
+ <p><tt>XXXJITInfo.cpp</tt> implements the JIT interfaces for target-specific code-generation
+ activities, such as emitting machine code and stubs. At minimum,
+ a target-specific version of XXXJITInfo implements the following:</p>
+ <ul>
+ <li><tt>getLazyResolverFunction</tt> – initializes the JIT, gives the
+ target a function that is used for compilation </li>
+
+ <li><tt>emitFunctionStub</tt> – returns a native function with a
+ specified address for a callback function</li>
+
+ <li><tt>relocate</tt> – changes the addresses of referenced globals,
+ based on relocation types</li>
+
+ <li>callback function that are wrappers to a function stub that is
+ used when the real target is not initially known </li>
+ </ul>
+
+ <p><tt>getLazyResolverFunction</tt> is generally trivial to implement. It
+ makes the incoming parameter as the global JITCompilerFunction and returns the
+ callback function that will be used a function wrapper. For the Alpha target
+ (in <tt>AlphaJITInfo.cpp</tt>), the <tt>getLazyResolverFunction</tt> implementation is simply:</p>
+ </div>
+
+ <div class="doc_code">
+ <pre>TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction(
+ JITCompilerFn F)
+ {
+ JITCompilerFunction = F;
+ return AlphaCompilationCallback;
+ }
+ </pre>
+ </div>
+ <div class="doc_text">
+ <p>For the X86 target, the <tt>getLazyResolverFunction</tt> implementation is
+ a little more complication, because it returns a different callback function
+ for processors with SSE instructions and XMM registers. </p>
+
+ <p>The callback function initially saves and later restores the
+ callee register values, incoming arguments, and frame and return address. The
+ callback function needs low-level access to the registers or stack, so it is typically
+ implemented with assembler. </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://www.woo.com">Mason Woo</a> and <a href="http://misha.brukman.net">Misha Brukman</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/WritingAnLLVMPass.html
diff -c /dev/null llvm-www/releases/2.5/docs/WritingAnLLVMPass.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/WritingAnLLVMPass.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1828 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>Writing an LLVM Pass</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">
+ Writing an LLVM Pass
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction - What is a pass?</a></li>
+ <li><a href="#quickstart">Quick Start - Writing hello world</a>
+ <ul>
+ <li><a href="#makefile">Setting up the build environment</a></li>
+ <li><a href="#basiccode">Basic code required</a></li>
+ <li><a href="#running">Running a pass with <tt>opt</tt></a></li>
+ </ul></li>
+ <li><a href="#passtype">Pass classes and requirements</a>
+ <ul>
+ <li><a href="#ImmutablePass">The <tt>ImmutablePass</tt> class</a></li>
+ <li><a href="#ModulePass">The <tt>ModulePass</tt> class</a>
+ <ul>
+ <li><a href="#runOnModule">The <tt>runOnModule</tt> method</a></li>
+ </ul></li>
+ <li><a href="#CallGraphSCCPass">The <tt>CallGraphSCCPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_scc">The <tt>doInitialization(CallGraph
+ &)</tt> method</a></li>
+ <li><a href="#runOnSCC">The <tt>runOnSCC</tt> method</a></li>
+ <li><a href="#doFinalization_scc">The <tt>doFinalization(CallGraph
+ &)</tt> method</a></li>
+ </ul></li>
+ <li><a href="#FunctionPass">The <tt>FunctionPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_mod">The <tt>doInitialization(Module
+ &)</tt> method</a></li>
+ <li><a href="#runOnFunction">The <tt>runOnFunction</tt> method</a></li>
+ <li><a href="#doFinalization_mod">The <tt>doFinalization(Module
+ &)</tt> method</a></li>
+ </ul></li>
+ <li><a href="#LoopPass">The <tt>LoopPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_loop">The <tt>doInitialization(Loop *,
+ LPPassManager &)</tt> method</a></li>
+ <li><a href="#runOnLoop">The <tt>runOnLoop</tt> method</a></li>
+ <li><a href="#doFinalization_loop">The <tt>doFinalization()
+ </tt> method</a></li>
+ </ul></li>
+ <li><a href="#BasicBlockPass">The <tt>BasicBlockPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_fn">The <tt>doInitialization(Function
+ &)</tt> method</a></li>
+ <li><a href="#runOnBasicBlock">The <tt>runOnBasicBlock</tt>
+ method</a></li>
+ <li><a href="#doFinalization_fn">The <tt>doFinalization(Function
+ &)</tt> method</a></li>
+ </ul></li>
+ <li><a href="#MachineFunctionPass">The <tt>MachineFunctionPass</tt>
+ class</a>
+ <ul>
+ <li><a href="#runOnMachineFunction">The
+ <tt>runOnMachineFunction(MachineFunction &)</tt> method</a></li>
+ </ul></li>
+ </ul>
+ <li><a href="#registration">Pass Registration</a>
+ <ul>
+ <li><a href="#print">The <tt>print</tt> method</a></li>
+ </ul></li>
+ <li><a href="#interaction">Specifying interactions between passes</a>
+ <ul>
+ <li><a href="#getAnalysisUsage">The <tt>getAnalysisUsage</tt>
+ method</a></li>
+ <li><a href="#AU::addRequired">The <tt>AnalysisUsage::addRequired<></tt> and <tt>AnalysisUsage::addRequiredTransitive<></tt> methods</a></li>
+ <li><a href="#AU::addPreserved">The <tt>AnalysisUsage::addPreserved<></tt> method</a></li>
+ <li><a href="#AU::examples">Example implementations of <tt>getAnalysisUsage</tt></a></li>
+ <li><a href="#getAnalysis">The <tt>getAnalysis<></tt> and
+ <tt>getAnalysisIfAvailable<></tt> methods</a></li>
+ </ul></li>
+ <li><a href="#analysisgroup">Implementing Analysis Groups</a>
+ <ul>
+ <li><a href="#agconcepts">Analysis Group Concepts</a></li>
+ <li><a href="#registerag">Using <tt>RegisterAnalysisGroup</tt></a></li>
+ </ul></li>
+ <li><a href="#passStatistics">Pass Statistics</a>
+ <li><a href="#passmanager">What PassManager does</a>
+ <ul>
+ <li><a href="#releaseMemory">The <tt>releaseMemory</tt> method</a></li>
+ </ul></li>
+ <li><a href="#registering">Registering dynamically loaded passes</a>
+ <ul>
+ <li><a href="#registering_existing">Using existing registries</a></li>
+ <li><a href="#registering_new">Creating new registries</a></li>
+ </ul></li>
+ <li><a href="#debughints">Using GDB with dynamically loaded passes</a>
+ <ul>
+ <li><a href="#breakpoint">Setting a breakpoint in your pass</a></li>
+ <li><a href="#debugmisc">Miscellaneous Problems</a></li>
+ </ul></li>
+ <li><a href="#future">Future extensions planned</a>
+ <ul>
+ <li><a href="#SMP">Multithreaded LLVM</a></li>
+ </ul></li>
+ </ol>
+
+ <div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and
+ <a href="mailto:jlaskey at mac.com">Jim Laskey</a></p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction - What is a pass?</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The LLVM Pass Framework is an important part of the LLVM system, because LLVM
+ passes are where most of the interesting parts of the compiler exist. Passes
+ perform the transformations and optimizations that make up the compiler, they
+ build the analysis results that are used by these transformations, and they are,
+ above all, a structuring technique for compiler code.</p>
+
+ <p>All LLVM passes are subclasses of the <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1Pass.html">Pass</a></tt>
+ class, which implement functionality by overriding virtual methods inherited
+ from <tt>Pass</tt>. Depending on how your pass works, you should inherit from
+ the <tt><a href="#ModulePass">ModulePass</a></tt>, <tt><a
+ href="#CallGraphSCCPass">CallGraphSCCPass</a></tt>, <tt><a
+ href="#FunctionPass">FunctionPass</a></tt>, or <tt><a
+ href="#LoopPass">LoopPass</a></tt>, or <tt><a
+ href="#BasicBlockPass">BasicBlockPass</a></tt> classes, which gives the system
+ more information about what your pass does, and how it can be combined with
+ other passes. One of the main features of the LLVM Pass Framework is that it
+ schedules passes to run in an efficient way based on the constraints that your
+ pass meets (which are indicated by which class they derive from).</p>
+
+ <p>We start by showing you how to construct a pass, everything from setting up
+ the code, to compiling, loading, and executing it. After the basics are down,
+ more advanced features are discussed.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="quickstart">Quick Start - Writing hello world</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Here we describe how to write the "hello world" of passes. The "Hello" pass
+ is designed to simply print out the name of non-external functions that exist in
+ the program being compiled. It does not modify the program at all, it just
+ inspects it. The source code and files for this pass are available in the LLVM
+ source tree in the <tt>lib/Transforms/Hello</tt> directory.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="makefile">Setting up the build environment</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>First, you need to create a new directory somewhere in the LLVM source
+ base. For this example, we'll assume that you made
+ <tt>lib/Transforms/Hello</tt>. Next, you must set up a build script
+ (Makefile) that will compile the source code for the new pass. To do this,
+ copy the following into <tt>Makefile</tt>:</p>
+ <hr/>
+
+ <div class="doc_code"><pre>
+ # Makefile for hello pass
+
+ # Path to top level of LLVM heirarchy
+ LEVEL = ../../..
+
+ # Name of the library to build
+ LIBRARYNAME = Hello
+
+ # Make the shared library become a loadable module so the tools can
+ # dlopen/dlsym on the resulting library.
+ LOADABLE_MODULE = 1
+
+ # Tell the build system which LLVM libraries your pass needs. You'll probably
+ # need at least LLVMSystem.a, LLVMSupport.a, LLVMCore.a but possibly several
+ # others too.
+ LLVMLIBS = LLVMCore.a LLVMSupport.a LLVMSystem.a
+
+ # Include the makefile implementation stuff
+ include $(LEVEL)/Makefile.common
+ </pre></div>
+
+ <p>This makefile specifies that all of the <tt>.cpp</tt> files in the current
+ directory are to be compiled and linked together into a
+ <tt>Debug/lib/Hello.so</tt> shared object that can be dynamically loaded by
+ the <tt>opt</tt> or <tt>bugpoint</tt> tools via their <tt>-load</tt> options.
+ If your operating system uses a suffix other than .so (such as windows or
+ Mac OS/X), the appropriate extension will be used.</p>
+
+ <p>Now that we have the build scripts set up, we just need to write the code for
+ the pass itself.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="basiccode">Basic code required</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Now that we have a way to compile our new pass, we just have to write it.
+ Start out with:</p>
+
+ <div class="doc_code"><pre>
+ <b>#include</b> "<a href="http://llvm.org/doxygen/Pass_8h-source.html">llvm/Pass.h</a>"
+ <b>#include</b> "<a href="http://llvm.org/doxygen/Function_8h-source.html">llvm/Function.h</a>"
+ </pre></div>
+
+ <p>Which are needed because we are writing a <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1Pass.html">Pass</a></tt>, and
+ we are operating on <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1Function.html">Function</a></tt>'s.</p>
+
+ <p>Next we have:</p>
+ <div class="doc_code"><pre>
+ <b>using namespace llvm;</b>
+ </pre></div>
+ <p>... which is required because the functions from the include files
+ live in the llvm namespace.
+ </p>
+
+ <p>Next we have:</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> {
+ </pre></div>
+
+ <p>... which starts out an anonymous namespace. Anonymous namespaces are to C++
+ what the "<tt>static</tt>" keyword is to C (at global scope). It makes the
+ things declared inside of the anonymous namespace only visible to the current
+ file. If you're not familiar with them, consult a decent C++ book for more
+ information.</p>
+
+ <p>Next, we declare our pass itself:</p>
+
+ <div class="doc_code"><pre>
+ <b>struct</b> Hello : <b>public</b> <a href="#FunctionPass">FunctionPass</a> {
+ </pre></div><p>
+
+ <p>This declares a "<tt>Hello</tt>" class that is a subclass of <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1FunctionPass.html">FunctionPass</a></tt>.
+ The different builtin pass subclasses are described in detail <a
+ href="#passtype">later</a>, but for now, know that <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a>'s operate a function at a
+ time.</p>
+
+ <div class="doc_code"><pre>
+ static char ID;
+ Hello() : FunctionPass((intptr_t)&ID) {}
+ </pre></div><p>
+
+ <p> This declares pass identifier used by LLVM to identify pass. This allows LLVM to
+ avoid using expensive C++ runtime information.</p>
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
+ llvm::cerr << "<i>Hello: </i>" << F.getName() << "\n";
+ <b>return false</b>;
+ }
+ }; <i>// end of struct Hello</i>
+ </pre></div>
+
+ <p>We declare a "<a href="#runOnFunction"><tt>runOnFunction</tt></a>" method,
+ which overloads an abstract virtual method inherited from <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a>. This is where we are supposed
+ to do our thing, so we just print out our message with the name of each
+ function.</p>
+
+ <div class="doc_code"><pre>
+ char Hello::ID = 0;
+ </pre></div>
+
+ <p> We initialize pass ID here. LLVM uses ID's address to identify pass so
+ initialization value is not important.</p>
+
+ <div class="doc_code"><pre>
+ RegisterPass<Hello> X("<i>hello</i>", "<i>Hello World Pass</i>",
+ false /* Only looks at CFG */,
+ false /* Analysis Pass */);
+ } <i>// end of anonymous namespace</i>
+ </pre></div>
+
+ <p>Lastly, we <a href="#registration">register our class</a> <tt>Hello</tt>,
+ giving it a command line
+ argument "<tt>hello</tt>", and a name "<tt>Hello World Pass</tt>".
+ Last two RegisterPass arguments are optional. Their default value is false.
+ If a pass walks CFG without modifying it then third argument is set to true.
+ If a pass is an analysis pass, for example dominator tree pass, then true
+ is supplied as fourth argument. </p>
+
+ <p>As a whole, the <tt>.cpp</tt> file looks like:</p>
+
+ <div class="doc_code"><pre>
+ <b>#include</b> "<a href="http://llvm.org/doxygen/Pass_8h-source.html">llvm/Pass.h</a>"
+ <b>#include</b> "<a href="http://llvm.org/doxygen/Function_8h-source.html">llvm/Function.h</a>"
+
+ <b>using namespace llvm;</b>
+
+ <b>namespace</b> {
+ <b>struct Hello</b> : <b>public</b> <a href="#FunctionPass">FunctionPass</a> {
+
+ static char ID;
+ Hello() : FunctionPass((intptr_t)&ID) {}
+
+ <b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
+ llvm::cerr << "<i>Hello: </i>" << F.getName() << "\n";
+ <b>return false</b>;
+ }
+ };
+
+ char Hello::ID = 0;
+ RegisterPass<Hello> X("<i>hello</i>", "<i>Hello World Pass</i>");
+ }
+ </pre></div>
+
+ <p>Now that it's all together, compile the file with a simple "<tt>gmake</tt>"
+ command in the local directory and you should get a new
+ "<tt>Debug/lib/Hello.so</tt> file. Note that everything in this file is
+ contained in an anonymous namespace: this reflects the fact that passes are self
+ contained units that do not need external interfaces (although they can have
+ them) to be useful.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="running">Running a pass with <tt>opt</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Now that you have a brand new shiny shared object file, we can use the
+ <tt>opt</tt> command to run an LLVM program through your pass. Because you
+ registered your pass with the <tt>RegisterPass</tt> template, you will be able to
+ use the <tt>opt</tt> tool to access it, once loaded.</p>
+
+ <p>To test it, follow the example at the end of the <a
+ href="GettingStarted.html">Getting Started Guide</a> to compile "Hello World" to
+ LLVM. We can now run the bitcode file (<tt>hello.bc</tt>) for the program
+ through our transformation like this (or course, any bitcode file will
+ work):</p>
+
+ <div class="doc_code"><pre>
+ $ opt -load ../../../Debug/lib/Hello.so -hello < hello.bc > /dev/null
+ Hello: __main
+ Hello: puts
+ Hello: main
+ </pre></div>
+
+ <p>The '<tt>-load</tt>' option specifies that '<tt>opt</tt>' should load your
+ pass as a shared object, which makes '<tt>-hello</tt>' a valid command line
+ argument (which is one reason you need to <a href="#registration">register your
+ pass</a>). Because the hello pass does not modify the program in any
+ interesting way, we just throw away the result of <tt>opt</tt> (sending it to
+ <tt>/dev/null</tt>).</p>
+
+ <p>To see what happened to the other string you registered, try running
+ <tt>opt</tt> with the <tt>--help</tt> option:</p>
+
+ <div class="doc_code"><pre>
+ $ opt -load ../../../Debug/lib/Hello.so --help
+ OVERVIEW: llvm .bc -> .bc modular optimizer
+
+ USAGE: opt [options] <input bitcode>
+
+ OPTIONS:
+ Optimizations available:
+ ...
+ -funcresolve - Resolve Functions
+ -gcse - Global Common Subexpression Elimination
+ -globaldce - Dead Global Elimination
+ <b>-hello - Hello World Pass</b>
+ -indvars - Canonicalize Induction Variables
+ -inline - Function Integration/Inlining
+ -instcombine - Combine redundant instructions
+ ...
+ </pre></div>
+
+ <p>The pass name get added as the information string for your pass, giving some
+ documentation to users of <tt>opt</tt>. Now that you have a working pass, you
+ would go ahead and make it do the cool transformations you want. Once you get
+ it all working and tested, it may become useful to find out how fast your pass
+ is. The <a href="#passManager"><tt>PassManager</tt></a> provides a nice command
+ line option (<tt>--time-passes</tt>) that allows you to get information about
+ the execution time of your pass along with the other passes you queue up. For
+ example:</p>
+
+ <div class="doc_code"><pre>
+ $ opt -load ../../../Debug/lib/Hello.so -hello -time-passes < hello.bc > /dev/null
+ Hello: __main
+ Hello: puts
+ Hello: main
+ ===============================================================================
+ ... Pass execution timing report ...
+ ===============================================================================
+ Total Execution Time: 0.02 seconds (0.0479059 wall clock)
+
+ ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Pass Name ---
+ 0.0100 (100.0%) 0.0000 ( 0.0%) 0.0100 ( 50.0%) 0.0402 ( 84.0%) Bitcode Writer
+ 0.0000 ( 0.0%) 0.0100 (100.0%) 0.0100 ( 50.0%) 0.0031 ( 6.4%) Dominator Set Construction
+ 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0013 ( 2.7%) Module Verifier
+ <b> 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0033 ( 6.9%) Hello World Pass</b>
+ 0.0100 (100.0%) 0.0100 (100.0%) 0.0200 (100.0%) 0.0479 (100.0%) TOTAL
+ </pre></div>
+
+ <p>As you can see, our implementation above is pretty fast :). The additional
+ passes listed are automatically inserted by the '<tt>opt</tt>' tool to verify
+ that the LLVM emitted by your pass is still valid and well formed LLVM, which
+ hasn't been broken somehow.</p>
+
+ <p>Now that you have seen the basics of the mechanics behind passes, we can talk
+ about some more details of how they work and how to use them.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="passtype">Pass classes and requirements</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>One of the first things that you should do when designing a new pass is to
+ decide what class you should subclass for your pass. The <a
+ href="#basiccode">Hello World</a> example uses the <tt><a
+ href="#FunctionPass">FunctionPass</a></tt> class for its implementation, but we
+ did not discuss why or when this should occur. Here we talk about the classes
+ available, from the most general to the most specific.</p>
+
+ <p>When choosing a superclass for your Pass, you should choose the <b>most
+ specific</b> class possible, while still being able to meet the requirements
+ listed. This gives the LLVM Pass Infrastructure information necessary to
+ optimize how passes are run, so that the resultant compiler isn't unneccesarily
+ slow.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ImmutablePass">The <tt>ImmutablePass</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The most plain and boring type of pass is the "<tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1ImmutablePass.html">ImmutablePass</a></tt>"
+ class. This pass type is used for passes that do not have to be run, do not
+ change state, and never need to be updated. This is not a normal type of
+ transformation or analysis, but can provide information about the current
+ compiler configuration.</p>
+
+ <p>Although this pass class is very infrequently used, it is important for
+ providing information about the current target machine being compiled for, and
+ other static information that can affect the various transformations.</p>
+
+ <p><tt>ImmutablePass</tt>es never invalidate other transformations, are never
+ invalidated, and are never "run".</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="ModulePass">The <tt>ModulePass</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The "<tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">ModulePass</a></tt>"
+ class is the most general of all superclasses that you can use. Deriving from
+ <tt>ModulePass</tt> indicates that your pass uses the entire program as a unit,
+ refering to function bodies in no predictable order, or adding and removing
+ functions. Because nothing is known about the behavior of <tt>ModulePass</tt>
+ subclasses, no optimization can be done for their execution. A module pass
+ can use function level passes (e.g. dominators) using getAnalysis interface
+ <tt> getAnalysis<DominatorTree>(Function)</tt>, if the function pass
+ does not require any module passes. </p>
+
+ <p>To write a correct <tt>ModulePass</tt> subclass, derive from
+ <tt>ModulePass</tt> and overload the <tt>runOnModule</tt> method with the
+ following signature:</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="runOnModule">The <tt>runOnModule</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> runOnModule(Module &M) = 0;
+ </pre></div>
+
+ <p>The <tt>runOnModule</tt> method performs the interesting work of the pass.
+ It should return true if the module was modified by the transformation and
+ false otherwise.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="CallGraphSCCPass">The <tt>CallGraphSCCPass</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The "<tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1CallGraphSCCPass.html">CallGraphSCCPass</a></tt>"
+ is used by passes that need to traverse the program bottom-up on the call graph
+ (callees before callers). Deriving from CallGraphSCCPass provides some
+ mechanics for building and traversing the CallGraph, but also allows the system
+ to optimize execution of CallGraphSCCPass's. If your pass meets the
+ requirements outlined below, and doesn't meet the requirements of a <tt><a
+ href="#FunctionPass">FunctionPass</a></tt> or <tt><a
+ href="#BasicBlockPass">BasicBlockPass</a></tt>, you should derive from
+ <tt>CallGraphSCCPass</tt>.</p>
+
+ <p><b>TODO</b>: explain briefly what SCC, Tarjan's algo, and B-U mean.</p>
+
+ <p>To be explicit, <tt>CallGraphSCCPass</tt> subclasses are:</p>
+
+ <ol>
+
+ <li>... <em>not allowed</em> to modify any <tt>Function</tt>s that are not in
+ the current SCC.</li>
+
+ <li>... <em>not allowed</em> to inspect any Function's other than those in the
+ current SCC and the direct callees of the SCC.</li>
+
+ <li>... <em>required</em> to preserve the current CallGraph object, updating it
+ to reflect any changes made to the program.</li>
+
+ <li>... <em>not allowed</em> to add or remove SCC's from the current Module,
+ though they may change the contents of an SCC.</li>
+
+ <li>... <em>allowed</em> to add or remove global variables from the current
+ Module.</li>
+
+ <li>... <em>allowed</em> to maintain state across invocations of
+ <a href="#runOnSCC"><tt>runOnSCC</tt></a> (including global data).</li>
+ </ol>
+
+ <p>Implementing a <tt>CallGraphSCCPass</tt> is slightly tricky in some cases
+ because it has to handle SCCs with more than one node in it. All of the virtual
+ methods described below should return true if they modified the program, or
+ false if they didn't.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doInitialization_scc">The <tt>doInitialization(CallGraph &)</tt>
+ method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doInitialization(CallGraph &CG);
+ </pre></div>
+
+ <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that
+ <tt>CallGraphSCCPass</tt>'s are not allowed to do. They can add and remove
+ functions, get pointers to functions, etc. The <tt>doInitialization</tt> method
+ is designed to do simple initialization type of stuff that does not depend on
+ the SCCs being processed. The <tt>doInitialization</tt> method call is not
+ scheduled to overlap with any other pass executions (thus it should be very
+ fast).</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="runOnSCC">The <tt>runOnSCC</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> runOnSCC(const std::vector<CallGraphNode *> &SCCM) = 0;
+ </pre></div>
+
+ <p>The <tt>runOnSCC</tt> method performs the interesting work of the pass, and
+ should return true if the module was modified by the transformation, false
+ otherwise.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doFinalization_scc">The <tt>doFinalization(CallGraph
+ &)</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doFinalization(CallGraph &CG);
+ </pre></div>
+
+ <p>The <tt>doFinalization</tt> method is an infrequently used method that is
+ called when the pass framework has finished calling <a
+ href="#runOnFunction"><tt>runOnFunction</tt></a> for every function in the
+ program being compiled.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="FunctionPass">The <tt>FunctionPass</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>In contrast to <tt>ModulePass</tt> subclasses, <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1Pass.html">FunctionPass</a></tt>
+ subclasses do have a predictable, local behavior that can be expected by the
+ system. All <tt>FunctionPass</tt> execute on each function in the program
+ independent of all of the other functions in the program.
+ <tt>FunctionPass</tt>'s do not require that they are executed in a particular
+ order, and <tt>FunctionPass</tt>'s do not modify external functions.</p>
+
+ <p>To be explicit, <tt>FunctionPass</tt> subclasses are not allowed to:</p>
+
+ <ol>
+ <li>Modify a Function other than the one currently being processed.</li>
+ <li>Add or remove Function's from the current Module.</li>
+ <li>Add or remove global variables from the current Module.</li>
+ <li>Maintain state across invocations of
+ <a href="#runOnFunction"><tt>runOnFunction</tt></a> (including global data)</li>
+ </ol>
+
+ <p>Implementing a <tt>FunctionPass</tt> is usually straightforward (See the <a
+ href="#basiccode">Hello World</a> pass for example). <tt>FunctionPass</tt>'s
+ may overload three virtual methods to do their work. All of these methods
+ should return true if they modified the program, or false if they didn't.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doInitialization_mod">The <tt>doInitialization(Module &)</tt>
+ method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doInitialization(Module &M);
+ </pre></div>
+
+ <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that
+ <tt>FunctionPass</tt>'s are not allowed to do. They can add and remove
+ functions, get pointers to functions, etc. The <tt>doInitialization</tt> method
+ is designed to do simple initialization type of stuff that does not depend on
+ the functions being processed. The <tt>doInitialization</tt> method call is not
+ scheduled to overlap with any other pass executions (thus it should be very
+ fast).</p>
+
+ <p>A good example of how this method should be used is the <a
+ href="http://llvm.org/doxygen/LowerAllocations_8cpp-source.html">LowerAllocations</a>
+ pass. This pass converts <tt>malloc</tt> and <tt>free</tt> instructions into
+ platform dependent <tt>malloc()</tt> and <tt>free()</tt> function calls. It
+ uses the <tt>doInitialization</tt> method to get a reference to the malloc and
+ free functions that it needs, adding prototypes to the module if necessary.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="runOnFunction">The <tt>runOnFunction</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> runOnFunction(Function &F) = 0;
+ </pre></div><p>
+
+ <p>The <tt>runOnFunction</tt> method must be implemented by your subclass to do
+ the transformation or analysis work of your pass. As usual, a true value should
+ be returned if the function is modified.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doFinalization_mod">The <tt>doFinalization(Module
+ &)</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doFinalization(Module &M);
+ </pre></div>
+
+ <p>The <tt>doFinalization</tt> method is an infrequently used method that is
+ called when the pass framework has finished calling <a
+ href="#runOnFunction"><tt>runOnFunction</tt></a> for every function in the
+ program being compiled.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="LoopPass">The <tt>LoopPass</tt> class </a>
+ </div>
+
+ <div class="doc_text">
+
+ <p> All <tt>LoopPass</tt> execute on each loop in the function independent of
+ all of the other loops in the function. <tt>LoopPass</tt> processes loops in
+ loop nest order such that outer most loop is processed last. </p>
+
+ <p> <tt>LoopPass</tt> subclasses are allowed to update loop nest using
+ <tt>LPPassManager</tt> interface. Implementing a loop pass is usually
+ straightforward. <tt>Looppass</tt>'s may overload three virtual methods to
+ do their work. All these methods should return true if they modified the
+ program, or false if they didn't. </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doInitialization_loop">The <tt>doInitialization(Loop *,
+ LPPassManager &)</tt>
+ method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doInitialization(Loop *, LPPassManager &LPM);
+ </pre></div>
+
+ <p>The <tt>doInitialization</tt> method is designed to do simple initialization
+ type of stuff that does not depend on the functions being processed. The
+ <tt>doInitialization</tt> method call is not scheduled to overlap with any
+ other pass executions (thus it should be very fast). LPPassManager
+ interface should be used to access Function or Module level analysis
+ information.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="runOnLoop">The <tt>runOnLoop</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> runOnLoop(Loop *, LPPassManager &LPM) = 0;
+ </pre></div><p>
+
+ <p>The <tt>runOnLoop</tt> method must be implemented by your subclass to do
+ the transformation or analysis work of your pass. As usual, a true value should
+ be returned if the function is modified. <tt>LPPassManager</tt> interface
+ should be used to update loop nest.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doFinalization_loop">The <tt>doFinalization()</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doFinalization();
+ </pre></div>
+
+ <p>The <tt>doFinalization</tt> method is an infrequently used method that is
+ called when the pass framework has finished calling <a
+ href="#runOnLoop"><tt>runOnLoop</tt></a> for every loop in the
+ program being compiled. </p>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="BasicBlockPass">The <tt>BasicBlockPass</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p><tt>BasicBlockPass</tt>'s are just like <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a>'s, except that they must limit
+ their scope of inspection and modification to a single basic block at a time.
+ As such, they are <b>not</b> allowed to do any of the following:</p>
+
+ <ol>
+ <li>Modify or inspect any basic blocks outside of the current one</li>
+ <li>Maintain state across invocations of
+ <a href="#runOnBasicBlock"><tt>runOnBasicBlock</tt></a></li>
+ <li>Modify the control flow graph (by altering terminator instructions)</li>
+ <li>Any of the things forbidden for
+ <a href="#FunctionPass"><tt>FunctionPass</tt></a>es.</li>
+ </ol>
+
+ <p><tt>BasicBlockPass</tt>es are useful for traditional local and "peephole"
+ optimizations. They may override the same <a
+ href="#doInitialization_mod"><tt>doInitialization(Module &)</tt></a> and <a
+ href="#doFinalization_mod"><tt>doFinalization(Module &)</tt></a> methods that <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a>'s have, but also have the following virtual methods that may also be implemented:</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doInitialization_fn">The <tt>doInitialization(Function
+ &)</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doInitialization(Function &F);
+ </pre></div>
+
+ <p>The <tt>doIninitialize</tt> method is allowed to do most of the things that
+ <tt>BasicBlockPass</tt>'s are not allowed to do, but that
+ <tt>FunctionPass</tt>'s can. The <tt>doInitialization</tt> method is designed
+ to do simple initialization that does not depend on the
+ BasicBlocks being processed. The <tt>doInitialization</tt> method call is not
+ scheduled to overlap with any other pass executions (thus it should be very
+ fast).</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="runOnBasicBlock">The <tt>runOnBasicBlock</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> runOnBasicBlock(BasicBlock &BB) = 0;
+ </pre></div>
+
+ <p>Override this function to do the work of the <tt>BasicBlockPass</tt>. This
+ function is not allowed to inspect or modify basic blocks other than the
+ parameter, and are not allowed to modify the CFG. A true value must be returned
+ if the basic block is modified.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="doFinalization_fn">The <tt>doFinalization(Function &)</tt>
+ method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> doFinalization(Function &F);
+ </pre></div>
+
+ <p>The <tt>doFinalization</tt> method is an infrequently used method that is
+ called when the pass framework has finished calling <a
+ href="#runOnBasicBlock"><tt>runOnBasicBlock</tt></a> for every BasicBlock in the
+ program being compiled. This can be used to perform per-function
+ finalization.</p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="MachineFunctionPass">The <tt>MachineFunctionPass</tt> class</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>A <tt>MachineFunctionPass</tt> is a part of the LLVM code generator that
+ executes on the machine-dependent representation of each LLVM function in the
+ program. A <tt>MachineFunctionPass</tt> is also a <tt>FunctionPass</tt>, so all
+ the restrictions that apply to a <tt>FunctionPass</tt> also apply to it.
+ <tt>MachineFunctionPass</tt>es also have additional restrictions. In particular,
+ <tt>MachineFunctionPass</tt>es are not allowed to do any of the following:</p>
+
+ <ol>
+ <li>Modify any LLVM Instructions, BasicBlocks or Functions.</li>
+ <li>Modify a MachineFunction other than the one currently being processed.</li>
+ <li>Add or remove MachineFunctions from the current Module.</li>
+ <li>Add or remove global variables from the current Module.</li>
+ <li>Maintain state across invocations of <a
+ href="#runOnMachineFunction"><tt>runOnMachineFunction</tt></a> (including global
+ data)</li>
+ </ol>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="runOnMachineFunction">The <tt>runOnMachineFunction(MachineFunction
+ &MF)</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual bool</b> runOnMachineFunction(MachineFunction &MF) = 0;
+ </pre></div>
+
+ <p><tt>runOnMachineFunction</tt> can be considered the main entry point of a
+ <tt>MachineFunctionPass</tt>; that is, you should override this method to do the
+ work of your <tt>MachineFunctionPass</tt>.</p>
+
+ <p>The <tt>runOnMachineFunction</tt> method is called on every
+ <tt>MachineFunction</tt> in a <tt>Module</tt>, so that the
+ <tt>MachineFunctionPass</tt> may perform optimizations on the machine-dependent
+ representation of the function. If you want to get at the LLVM <tt>Function</tt>
+ for the <tt>MachineFunction</tt> you're working on, use
+ <tt>MachineFunction</tt>'s <tt>getFunction()</tt> accessor method -- but
+ remember, you may not modify the LLVM <tt>Function</tt> or its contents from a
+ <tt>MachineFunctionPass</tt>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="registration">Pass registration</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>In the <a href="#basiccode">Hello World</a> example pass we illustrated how
+ pass registration works, and discussed some of the reasons that it is used and
+ what it does. Here we discuss how and why passes are registered.</p>
+
+ <p>As we saw above, passes are registered with the <b><tt>RegisterPass</tt></b>
+ template, which requires you to pass at least two
+ parameters. The first parameter is the name of the pass that is to be used on
+ the command line to specify that the pass should be added to a program (for
+ example, with <tt>opt</tt> or <tt>bugpoint</tt>). The second argument is the
+ name of the pass, which is to be used for the <tt>--help</tt> output of
+ programs, as
+ well as for debug output generated by the <tt>--debug-pass</tt> option.</p>
+
+ <p>If you want your pass to be easily dumpable, you should
+ implement the virtual <tt>print</tt> method:</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="print">The <tt>print</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual void</b> print(std::ostream &O, <b>const</b> Module *M) <b>const</b>;
+ </pre></div>
+
+ <p>The <tt>print</tt> method must be implemented by "analyses" in order to print
+ a human readable version of the analysis results. This is useful for debugging
+ an analysis itself, as well as for other people to figure out how an analysis
+ works. Use the <tt>opt -analyze</tt> argument to invoke this method.</p>
+
+ <p>The <tt>llvm::OStream</tt> parameter specifies the stream to write the results on,
+ and the <tt>Module</tt> parameter gives a pointer to the top level module of the
+ program that has been analyzed. Note however that this pointer may be null in
+ certain circumstances (such as calling the <tt>Pass::dump()</tt> from a
+ debugger), so it should only be used to enhance debug output, it should not be
+ depended on.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="interaction">Specifying interactions between passes</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>One of the main responsibilities of the <tt>PassManager</tt> is to make sure
+ that passes interact with each other correctly. Because <tt>PassManager</tt>
+ tries to <a href="#passmanager">optimize the execution of passes</a> it must
+ know how the passes interact with each other and what dependencies exist between
+ the various passes. To track this, each pass can declare the set of passes that
+ are required to be executed before the current pass, and the passes which are
+ invalidated by the current pass.</p>
+
+ <p>Typically this functionality is used to require that analysis results are
+ computed before your pass is run. Running arbitrary transformation passes can
+ invalidate the computed analysis results, which is what the invalidation set
+ specifies. If a pass does not implement the <tt><a
+ href="#getAnalysisUsage">getAnalysisUsage</a></tt> method, it defaults to not
+ having any prerequisite passes, and invalidating <b>all</b> other passes.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="getAnalysisUsage">The <tt>getAnalysisUsage</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual void</b> getAnalysisUsage(AnalysisUsage &Info) <b>const</b>;
+ </pre></div>
+
+ <p>By implementing the <tt>getAnalysisUsage</tt> method, the required and
+ invalidated sets may be specified for your transformation. The implementation
+ should fill in the <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1AnalysisUsage.html">AnalysisUsage</a></tt>
+ object with information about which passes are required and not invalidated. To
+ do this, a pass may call any of the following methods on the AnalysisUsage
+ object:</p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="AU::addRequired">The <tt>AnalysisUsage::addRequired<></tt> and <tt>AnalysisUsage::addRequiredTransitive<></tt> methods</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ If your pass requires a previous pass to be executed (an analysis for example),
+ it can use one of these methods to arrange for it to be run before your pass.
+ LLVM has many different types of analyses and passes that can be required,
+ spanning the range from <tt>DominatorSet</tt> to <tt>BreakCriticalEdges</tt>.
+ Requiring <tt>BreakCriticalEdges</tt>, for example, guarantees that there will
+ be no critical edges in the CFG when your pass has been run.
+ </p>
+
+ <p>
+ Some analyses chain to other analyses to do their job. For example, an <a
+ href="AliasAnalysis.html">AliasAnalysis</a> implementation is required to <a
+ href="AliasAnalysis.html#chaining">chain</a> to other alias analysis passes. In
+ cases where analyses chain, the <tt>addRequiredTransitive</tt> method should be
+ used instead of the <tt>addRequired</tt> method. This informs the PassManager
+ that the transitively required pass should be alive as long as the requiring
+ pass is.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="AU::addPreserved">The <tt>AnalysisUsage::addPreserved<></tt> method</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ One of the jobs of the PassManager is to optimize how and when analyses are run.
+ In particular, it attempts to avoid recomputing data unless it needs to. For
+ this reason, passes are allowed to declare that they preserve (i.e., they don't
+ invalidate) an existing analysis if it's available. For example, a simple
+ constant folding pass would not modify the CFG, so it can't possibly affect the
+ results of dominator analysis. By default, all passes are assumed to invalidate
+ all others.
+ </p>
+
+ <p>
+ The <tt>AnalysisUsage</tt> class provides several methods which are useful in
+ certain circumstances that are related to <tt>addPreserved</tt>. In particular,
+ the <tt>setPreservesAll</tt> method can be called to indicate that the pass does
+ not modify the LLVM program at all (which is true for analyses), and the
+ <tt>setPreservesCFG</tt> method can be used by transformations that change
+ instructions in the program but do not modify the CFG or terminator instructions
+ (note that this property is implicitly set for <a
+ href="#BasicBlockPass">BasicBlockPass</a>'s).
+ </p>
+
+ <p>
+ <tt>addPreserved</tt> is particularly useful for transformations like
+ <tt>BreakCriticalEdges</tt>. This pass knows how to update a small set of loop
+ and dominator related analyses if they exist, so it can preserve them, despite
+ the fact that it hacks on the CFG.
+ </p>
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="AU::examples">Example implementations of <tt>getAnalysisUsage</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <i>// This is an example implementation from an analysis, which does not modify
+ // the program at all, yet has a prerequisite.</i>
+ <b>void</b> <a href="http://llvm.org/doxygen/classllvm_1_1PostDominanceFrontier.html">PostDominanceFrontier</a>::getAnalysisUsage(AnalysisUsage &AU) <b>const</b> {
+ AU.setPreservesAll();
+ AU.addRequired<<a href="http://llvm.org/doxygen/classllvm_1_1PostDominatorTree.html">PostDominatorTree</a>>();
+ }
+ </pre></div>
+
+ <p>and:</p>
+
+ <div class="doc_code"><pre>
+ <i>// This example modifies the program, but does not modify the CFG</i>
+ <b>void</b> <a href="http://llvm.org/doxygen/structLICM.html">LICM</a>::getAnalysisUsage(AnalysisUsage &AU) <b>const</b> {
+ AU.setPreservesCFG();
+ AU.addRequired<<a href="http://llvm.org/doxygen/classllvm_1_1LoopInfo.html">LoopInfo</a>>();
+ }
+ </pre></div>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="getAnalysis">The <tt>getAnalysis<></tt> and
+ <tt>getAnalysisIfAvailable<></tt> methods</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>Pass::getAnalysis<></tt> method is automatically inherited by
+ your class, providing you with access to the passes that you declared that you
+ required with the <a href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a>
+ method. It takes a single template argument that specifies which pass class you
+ want, and returns a reference to that pass. For example:</p>
+
+ <div class="doc_code"><pre>
+ bool LICM::runOnFunction(Function &F) {
+ LoopInfo &LI = getAnalysis<LoopInfo>();
+ ...
+ }
+ </pre></div>
+
+ <p>This method call returns a reference to the pass desired. You may get a
+ runtime assertion failure if you attempt to get an analysis that you did not
+ declare as required in your <a
+ href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a> implementation. This
+ method can be called by your <tt>run*</tt> method implementation, or by any
+ other local method invoked by your <tt>run*</tt> method.
+
+ A module level pass can use function level analysis info using this interface.
+ For example:</p>
+
+ <div class="doc_code"><pre>
+ bool ModuleLevelPass::runOnModule(Module &M) {
+ ...
+ DominatorTree &DT = getAnalysis<DominatorTree>(Func);
+ ...
+ }
+ </pre></div>
+
+ <p>In above example, runOnFunction for DominatorTree is called by pass manager
+ before returning a reference to the desired pass.</p>
+
+ <p>
+ If your pass is capable of updating analyses if they exist (e.g.,
+ <tt>BreakCriticalEdges</tt>, as described above), you can use the
+ <tt>getAnalysisIfAvailable</tt> method, which returns a pointer to the analysis
+ if it is active. For example:</p>
+
+ <div class="doc_code"><pre>
+ ...
+ if (DominatorSet *DS = getAnalysisIfAvailable<DominatorSet>()) {
+ <i>// A DominatorSet is active. This code will update it.</i>
+ }
+ ...
+ </pre></div>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="analysisgroup">Implementing Analysis Groups</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Now that we understand the basics of how passes are defined, how they are
+ used, and how they are required from other passes, it's time to get a little bit
+ fancier. All of the pass relationships that we have seen so far are very
+ simple: one pass depends on one other specific pass to be run before it can run.
+ For many applications, this is great, for others, more flexibility is
+ required.</p>
+
+ <p>In particular, some analyses are defined such that there is a single simple
+ interface to the analysis results, but multiple ways of calculating them.
+ Consider alias analysis for example. The most trivial alias analysis returns
+ "may alias" for any alias query. The most sophisticated analysis a
+ flow-sensitive, context-sensitive interprocedural analysis that can take a
+ significant amount of time to execute (and obviously, there is a lot of room
+ between these two extremes for other implementations). To cleanly support
+ situations like this, the LLVM Pass Infrastructure supports the notion of
+ Analysis Groups.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="agconcepts">Analysis Group Concepts</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>An Analysis Group is a single simple interface that may be implemented by
+ multiple different passes. Analysis Groups can be given human readable names
+ just like passes, but unlike passes, they need not derive from the <tt>Pass</tt>
+ class. An analysis group may have one or more implementations, one of which is
+ the "default" implementation.</p>
+
+ <p>Analysis groups are used by client passes just like other passes are: the
+ <tt>AnalysisUsage::addRequired()</tt> and <tt>Pass::getAnalysis()</tt> methods.
+ In order to resolve this requirement, the <a href="#passmanager">PassManager</a>
+ scans the available passes to see if any implementations of the analysis group
+ are available. If none is available, the default implementation is created for
+ the pass to use. All standard rules for <A href="#interaction">interaction
+ between passes</a> still apply.</p>
+
+ <p>Although <a href="#registration">Pass Registration</a> is optional for normal
+ passes, all analysis group implementations must be registered, and must use the
+ <A href="#registerag"><tt>RegisterAnalysisGroup</tt></a> template to join the
+ implementation pool. Also, a default implementation of the interface
+ <b>must</b> be registered with <A
+ href="#registerag"><tt>RegisterAnalysisGroup</tt></a>.</p>
+
+ <p>As a concrete example of an Analysis Group in action, consider the <a
+ href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>
+ analysis group. The default implementation of the alias analysis interface (the
+ <tt><a
+ href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">basicaa</a></tt>
+ pass) just does a few simple checks that don't require significant analysis to
+ compute (such as: two different globals can never alias each other, etc).
+ Passes that use the <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a></tt>
+ interface (for example the <tt><a
+ href="http://llvm.org/doxygen/structGCSE.html">gcse</a></tt> pass), do
+ not care which implementation of alias analysis is actually provided, they just
+ use the designated interface.</p>
+
+ <p>From the user's perspective, commands work just like normal. Issuing the
+ command '<tt>opt -gcse ...</tt>' will cause the <tt>basicaa</tt> class to be
+ instantiated and added to the pass sequence. Issuing the command '<tt>opt
+ -somefancyaa -gcse ...</tt>' will cause the <tt>gcse</tt> pass to use the
+ <tt>somefancyaa</tt> alias analysis (which doesn't actually exist, it's just a
+ hypothetical example) instead.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="registerag">Using <tt>RegisterAnalysisGroup</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The <tt>RegisterAnalysisGroup</tt> template is used to register the analysis
+ group itself as well as add pass implementations to the analysis group. First,
+ an analysis should be registered, with a human readable name provided for it.
+ Unlike registration of passes, there is no command line argument to be specified
+ for the Analysis Group Interface itself, because it is "abstract":</p>
+
+ <div class="doc_code"><pre>
+ <b>static</b> RegisterAnalysisGroup<<a href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>> A("<i>Alias Analysis</i>");
+ </pre></div>
+
+ <p>Once the analysis is registered, passes can declare that they are valid
+ implementations of the interface by using the following code:</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> {
+ //<i> Analysis Group implementations <b>must</b> be registered normally...</i>
+ RegisterPass<FancyAA>
+ B("<i>somefancyaa</i>", "<i>A more complex alias analysis implementation</i>");
+
+ //<i> Declare that we implement the AliasAnalysis interface</i>
+ RegisterAnalysisGroup<<a href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>> C(B);
+ }
+ </pre></div>
+
+ <p>This just shows a class <tt>FancyAA</tt> that is registered normally, then
+ uses the <tt>RegisterAnalysisGroup</tt> template to "join" the <tt><a
+ href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a></tt>
+ analysis group. Every implementation of an analysis group should join using
+ this template. A single pass may join multiple different analysis groups with
+ no problem.</p>
+
+ <div class="doc_code"><pre>
+ <b>namespace</b> {
+ //<i> Analysis Group implementations <b>must</b> be registered normally...</i>
+ RegisterPass<<a href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a>>
+ D("<i>basicaa</i>", "<i>Basic Alias Analysis (default AA impl)</i>");
+
+ //<i> Declare that we implement the AliasAnalysis interface</i>
+ RegisterAnalysisGroup<<a href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html">AliasAnalysis</a>, <b>true</b>> E(D);
+ }
+ </pre></div>
+
+ <p>Here we show how the default implementation is specified (using the extra
+ argument to the <tt>RegisterAnalysisGroup</tt> template). There must be exactly
+ one default implementation available at all times for an Analysis Group to be
+ used. Only default implementation can derive from <tt>ImmutablePass</tt>.
+ Here we declare that the
+ <tt><a href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a></tt>
+ pass is the default implementation for the interface.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="passStatistics">Pass Statistics</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>The <a
+ href="http://llvm.org/doxygen/Statistic_8h-source.html"><tt>Statistic</tt></a>
+ class is designed to be an easy way to expose various success
+ metrics from passes. These statistics are printed at the end of a
+ run, when the -stats command line option is enabled on the command
+ line. See the <a href="http://llvm.org/docs/ProgrammersManual.html#Statistic">Statistics section</a> in the Programmer's Manual for details.
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="passmanager">What PassManager does</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>The <a
+ href="http://llvm.org/doxygen/PassManager_8h-source.html"><tt>PassManager</tt></a>
+ <a
+ href="http://llvm.org/doxygen/classllvm_1_1PassManager.html">class</a>
+ takes a list of passes, ensures their <a href="#interaction">prerequisites</a>
+ are set up correctly, and then schedules passes to run efficiently. All of the
+ LLVM tools that run passes use the <tt>PassManager</tt> for execution of these
+ passes.</p>
+
+ <p>The <tt>PassManager</tt> does two main things to try to reduce the execution
+ time of a series of passes:</p>
+
+ <ol>
+ <li><b>Share analysis results</b> - The PassManager attempts to avoid
+ recomputing analysis results as much as possible. This means keeping track of
+ which analyses are available already, which analyses get invalidated, and which
+ analyses are needed to be run for a pass. An important part of work is that the
+ <tt>PassManager</tt> tracks the exact lifetime of all analysis results, allowing
+ it to <a href="#releaseMemory">free memory</a> allocated to holding analysis
+ results as soon as they are no longer needed.</li>
+
+ <li><b>Pipeline the execution of passes on the program</b> - The
+ <tt>PassManager</tt> attempts to get better cache and memory usage behavior out
+ of a series of passes by pipelining the passes together. This means that, given
+ a series of consequtive <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s, it
+ will execute all of the <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s on
+ the first function, then all of the <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a>es on the second function,
+ etc... until the entire program has been run through the passes.
+
+ <p>This improves the cache behavior of the compiler, because it is only touching
+ the LLVM program representation for a single function at a time, instead of
+ traversing the entire program. It reduces the memory consumption of compiler,
+ because, for example, only one <a
+ href="http://llvm.org/doxygen/classllvm_1_1DominatorSet.html"><tt>DominatorSet</tt></a>
+ needs to be calculated at a time. This also makes it possible to implement
+ some <a
+ href="#SMP">interesting enhancements</a> in the future.</p></li>
+
+ </ol>
+
+ <p>The effectiveness of the <tt>PassManager</tt> is influenced directly by how
+ much information it has about the behaviors of the passes it is scheduling. For
+ example, the "preserved" set is intentionally conservative in the face of an
+ unimplemented <a href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a> method.
+ Not implementing when it should be implemented will have the effect of not
+ allowing any analysis results to live across the execution of your pass.</p>
+
+ <p>The <tt>PassManager</tt> class exposes a <tt>--debug-pass</tt> command line
+ options that is useful for debugging pass execution, seeing how things work, and
+ diagnosing when you should be preserving more analyses than you currently are
+ (To get information about all of the variants of the <tt>--debug-pass</tt>
+ option, just type '<tt>opt --help-hidden</tt>').</p>
+
+ <p>By using the <tt>--debug-pass=Structure</tt> option, for example, we can see
+ how our <a href="#basiccode">Hello World</a> pass interacts with other passes.
+ Lets try it out with the <tt>gcse</tt> and <tt>licm</tt> passes:</p>
+
+ <div class="doc_code"><pre>
+ $ opt -load ../../../Debug/lib/Hello.so -gcse -licm --debug-pass=Structure < hello.bc > /dev/null
+ Module Pass Manager
+ Function Pass Manager
+ Dominator Set Construction
+ Immediate Dominators Construction
+ Global Common Subexpression Elimination
+ -- Immediate Dominators Construction
+ -- Global Common Subexpression Elimination
+ Natural Loop Construction
+ Loop Invariant Code Motion
+ -- Natural Loop Construction
+ -- Loop Invariant Code Motion
+ Module Verifier
+ -- Dominator Set Construction
+ -- Module Verifier
+ Bitcode Writer
+ --Bitcode Writer
+ </pre></div>
+
+ <p>This output shows us when passes are constructed and when the analysis
+ results are known to be dead (prefixed with '<tt>--</tt>'). Here we see that
+ GCSE uses dominator and immediate dominator information to do its job. The LICM
+ pass uses natural loop information, which uses dominator sets, but not immediate
+ dominators. Because immediate dominators are no longer useful after the GCSE
+ pass, it is immediately destroyed. The dominator sets are then reused to
+ compute natural loop information, which is then used by the LICM pass.</p>
+
+ <p>After the LICM pass, the module verifier runs (which is automatically added
+ by the '<tt>opt</tt>' tool), which uses the dominator set to check that the
+ resultant LLVM code is well formed. After it finishes, the dominator set
+ information is destroyed, after being computed once, and shared by three
+ passes.</p>
+
+ <p>Lets see how this changes when we run the <a href="#basiccode">Hello
+ World</a> pass in between the two passes:</p>
+
+ <div class="doc_code"><pre>
+ $ opt -load ../../../Debug/lib/Hello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null
+ Module Pass Manager
+ Function Pass Manager
+ Dominator Set Construction
+ Immediate Dominators Construction
+ Global Common Subexpression Elimination
+ <b>-- Dominator Set Construction</b>
+ -- Immediate Dominators Construction
+ -- Global Common Subexpression Elimination
+ <b> Hello World Pass
+ -- Hello World Pass
+ Dominator Set Construction</b>
+ Natural Loop Construction
+ Loop Invariant Code Motion
+ -- Natural Loop Construction
+ -- Loop Invariant Code Motion
+ Module Verifier
+ -- Dominator Set Construction
+ -- Module Verifier
+ Bitcode Writer
+ --Bitcode Writer
+ Hello: __main
+ Hello: puts
+ Hello: main
+ </pre></div>
+
+ <p>Here we see that the <a href="#basiccode">Hello World</a> pass has killed the
+ Dominator Set pass, even though it doesn't modify the code at all! To fix this,
+ we need to add the following <a
+ href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a> method to our pass:</p>
+
+ <div class="doc_code"><pre>
+ <i>// We don't modify the program, so we preserve all analyses</i>
+ <b>virtual void</b> getAnalysisUsage(AnalysisUsage &AU) <b>const</b> {
+ AU.setPreservesAll();
+ }
+ </pre></div>
+
+ <p>Now when we run our pass, we get this output:</p>
+
+ <div class="doc_code"><pre>
+ $ opt -load ../../../Debug/lib/Hello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null
+ Pass Arguments: -gcse -hello -licm
+ Module Pass Manager
+ Function Pass Manager
+ Dominator Set Construction
+ Immediate Dominators Construction
+ Global Common Subexpression Elimination
+ -- Immediate Dominators Construction
+ -- Global Common Subexpression Elimination
+ Hello World Pass
+ -- Hello World Pass
+ Natural Loop Construction
+ Loop Invariant Code Motion
+ -- Loop Invariant Code Motion
+ -- Natural Loop Construction
+ Module Verifier
+ -- Dominator Set Construction
+ -- Module Verifier
+ Bitcode Writer
+ --Bitcode Writer
+ Hello: __main
+ Hello: puts
+ Hello: main
+ </pre></div>
+
+ <p>Which shows that we don't accidentally invalidate dominator information
+ anymore, and therefore do not have to compute it twice.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="releaseMemory">The <tt>releaseMemory</tt> method</a>
+ </div>
+
+ <div class="doc_text">
+
+ <div class="doc_code"><pre>
+ <b>virtual void</b> releaseMemory();
+ </pre></div>
+
+ <p>The <tt>PassManager</tt> automatically determines when to compute analysis
+ results, and how long to keep them around for. Because the lifetime of the pass
+ object itself is effectively the entire duration of the compilation process, we
+ need some way to free analysis results when they are no longer useful. The
+ <tt>releaseMemory</tt> virtual method is the way to do this.</p>
+
+ <p>If you are writing an analysis or any other pass that retains a significant
+ amount of state (for use by another pass which "requires" your pass and uses the
+ <a href="#getAnalysis">getAnalysis</a> method) you should implement
+ <tt>releaseMEmory</tt> to, well, release the memory allocated to maintain this
+ internal state. This method is called after the <tt>run*</tt> method for the
+ class, before the next call of <tt>run*</tt> in your pass.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="registering">Registering dynamically loaded passes</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p><i>Size matters</i> when constructing production quality tools using llvm,
+ both for the purposes of distribution, and for regulating the resident code size
+ when running on the target system. Therefore, it becomes desirable to
+ selectively use some passes, while omitting others and maintain the flexibility
+ to change configurations later on. You want to be able to do all this, and,
+ provide feedback to the user. This is where pass registration comes into
+ play.</p>
+
+ <p>The fundamental mechanisms for pass registration are the
+ <tt>MachinePassRegistry</tt> class and subclasses of
+ <tt>MachinePassRegistryNode</tt>.</p>
+
+ <p>An instance of <tt>MachinePassRegistry</tt> is used to maintain a list of
+ <tt>MachinePassRegistryNode</tt> objects. This instance maintains the list and
+ communicates additions and deletions to the command line interface.</p>
+
+ <p>An instance of <tt>MachinePassRegistryNode</tt> subclass is used to maintain
+ information provided about a particular pass. This information includes the
+ command line name, the command help string and the address of the function used
+ to create an instance of the pass. A global static constructor of one of these
+ instances <i>registers</i> with a corresponding <tt>MachinePassRegistry</tt>,
+ the static destructor <i>unregisters</i>. Thus a pass that is statically linked
+ in the tool will be registered at start up. A dynamically loaded pass will
+ register on load and unregister at unload.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="registering_existing">Using existing registries</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>There are predefined registries to track instruction scheduling
+ (<tt>RegisterScheduler</tt>) and register allocation (<tt>RegisterRegAlloc</tt>)
+ machine passes. Here we will describe how to <i>register</i> a register
+ allocator machine pass.</p>
+
+ <p>Implement your register allocator machine pass. In your register allocator
+ .cpp file add the following include;</p>
+
+ <div class="doc_code"><pre>
+ #include "llvm/CodeGen/RegAllocRegistry.h"
+ </pre></div>
+
+ <p>Also in your register allocator .cpp file, define a creator function in the
+ form; </p>
+
+ <div class="doc_code"><pre>
+ FunctionPass *createMyRegisterAllocator() {
+ return new MyRegisterAllocator();
+ }
+ </pre></div>
+
+ <p>Note that the signature of this function should match the type of
+ <tt>RegisterRegAlloc::FunctionPassCtor</tt>. In the same file add the
+ "installing" declaration, in the form;</p>
+
+ <div class="doc_code"><pre>
+ static RegisterRegAlloc myRegAlloc("myregalloc",
+ " my register allocator help string",
+ createMyRegisterAllocator);
+ </pre></div>
+
+ <p>Note the two spaces prior to the help string produces a tidy result on the
+ --help query.</p>
+
+ <div class="doc_code"><pre>
+ $ llc --help
+ ...
+ -regalloc - Register allocator to use: (default = linearscan)
+ =linearscan - linear scan register allocator
+ =local - local register allocator
+ =simple - simple register allocator
+ =myregalloc - my register allocator help string
+ ...
+ </pre></div>
+
+ <p>And that's it. The user is now free to use <tt>-regalloc=myregalloc</tt> as
+ an option. Registering instruction schedulers is similar except use the
+ <tt>RegisterScheduler</tt> class. Note that the
+ <tt>RegisterScheduler::FunctionPassCtor</tt> is significantly different from
+ <tt>RegisterRegAlloc::FunctionPassCtor</tt>.</p>
+
+ <p>To force the load/linking of your register allocator into the llc/lli tools,
+ add your creator function's global declaration to "Passes.h" and add a "pseudo"
+ call line to <tt>llvm/Codegen/LinkAllCodegenComponents.h</tt>.</p>
+
+ </div>
+
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsection">
+ <a name="registering_new">Creating new registries</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>The easiest way to get started is to clone one of the existing registries; we
+ recommend <tt>llvm/CodeGen/RegAllocRegistry.h</tt>. The key things to modify
+ are the class name and the <tt>FunctionPassCtor</tt> type.</p>
+
+ <p>Then you need to declare the registry. Example: if your pass registry is
+ <tt>RegisterMyPasses</tt> then define;</p>
+
+ <div class="doc_code"><pre>
+ MachinePassRegistry RegisterMyPasses::Registry;
+ </pre></div>
+
+ <p>And finally, declare the command line option for your passes. Example:</p>
+
+ <div class="doc_code"><pre>
+ cl::opt<RegisterMyPasses::FunctionPassCtor, false,
+ RegisterPassParser<RegisterMyPasses> >
+ MyPassOpt("mypass",
+ cl::init(&createDefaultMyPass),
+ cl::desc("my pass option help"));
+ </pre></div>
+
+ <p>Here the command option is "mypass", with createDefaultMyPass as the default
+ creator.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="debughints">Using GDB with dynamically loaded passes</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Unfortunately, using GDB with dynamically loaded passes is not as easy as it
+ should be. First of all, you can't set a breakpoint in a shared object that has
+ not been loaded yet, and second of all there are problems with inlined functions
+ in shared objects. Here are some suggestions to debugging your pass with
+ GDB.</p>
+
+ <p>For sake of discussion, I'm going to assume that you are debugging a
+ transformation invoked by <tt>opt</tt>, although nothing described here depends
+ on that.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="breakpoint">Setting a breakpoint in your pass</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>First thing you do is start <tt>gdb</tt> on the <tt>opt</tt> process:</p>
+
+ <div class="doc_code"><pre>
+ $ <b>gdb opt</b>
+ GNU gdb 5.0
+ Copyright 2000 Free Software Foundation, Inc.
+ GDB is free software, covered by the GNU General Public License, and you are
+ welcome to change it and/or distribute copies of it under certain conditions.
+ Type "show copying" to see the conditions.
+ There is absolutely no warranty for GDB. Type "show warranty" for details.
+ This GDB was configured as "sparc-sun-solaris2.6"...
+ (gdb)
+ </pre></div>
+
+ <p>Note that <tt>opt</tt> has a lot of debugging information in it, so it takes
+ time to load. Be patient. Since we cannot set a breakpoint in our pass yet
+ (the shared object isn't loaded until runtime), we must execute the process, and
+ have it stop before it invokes our pass, but after it has loaded the shared
+ object. The most foolproof way of doing this is to set a breakpoint in
+ <tt>PassManager::run</tt> and then run the process with the arguments you
+ want:</p>
+
+ <div class="doc_code"><pre>
+ (gdb) <b>break llvm::PassManager::run</b>
+ Breakpoint 1 at 0x2413bc: file Pass.cpp, line 70.
+ (gdb) <b>run test.bc -load $(LLVMTOP)/llvm/Debug/lib/[libname].so -[passoption]</b>
+ Starting program: opt test.bc -load $(LLVMTOP)/llvm/Debug/lib/[libname].so -[passoption]
+ Breakpoint 1, PassManager::run (this=0xffbef174, M=@0x70b298) at Pass.cpp:70
+ 70 bool PassManager::run(Module &M) { return PM->run(M); }
+ (gdb)
+ </pre></div>
+
+ <p>Once the <tt>opt</tt> stops in the <tt>PassManager::run</tt> method you are
+ now free to set breakpoints in your pass so that you can trace through execution
+ or do other standard debugging stuff.</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="debugmisc">Miscellaneous Problems</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Once you have the basics down, there are a couple of problems that GDB has,
+ some with solutions, some without.</p>
+
+ <ul>
+ <li>Inline functions have bogus stack information. In general, GDB does a
+ pretty good job getting stack traces and stepping through inline functions.
+ When a pass is dynamically loaded however, it somehow completely loses this
+ capability. The only solution I know of is to de-inline a function (move it
+ from the body of a class to a .cpp file).</li>
+
+ <li>Restarting the program breaks breakpoints. After following the information
+ above, you have succeeded in getting some breakpoints planted in your pass. Nex
+ thing you know, you restart the program (i.e., you type '<tt>run</tt>' again),
+ and you start getting errors about breakpoints being unsettable. The only way I
+ have found to "fix" this problem is to <tt>delete</tt> the breakpoints that are
+ already set in your pass, run the program, and re-set the breakpoints once
+ execution stops in <tt>PassManager::run</tt>.</li>
+
+ </ul>
+
+ <p>Hopefully these tips will help with common case debugging situations. If
+ you'd like to contribute some tips of your own, just contact <a
+ href="mailto:sabre at nondot.org">Chris</a>.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="future">Future extensions planned</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>Although the LLVM Pass Infrastructure is very capable as it stands, and does
+ some nifty stuff, there are things we'd like to add in the future. Here is
+ where we are going:</p>
+
+ </div>
+
+ <!-- _______________________________________________________________________ -->
+ <div class="doc_subsubsection">
+ <a name="SMP">Multithreaded LLVM</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>Multiple CPU machines are becoming more common and compilation can never be
+ fast enough: obviously we should allow for a multithreaded compiler. Because of
+ the semantics defined for passes above (specifically they cannot maintain state
+ across invocations of their <tt>run*</tt> methods), a nice clean way to
+ implement a multithreaded compiler would be for the <tt>PassManager</tt> class
+ to create multiple instances of each pass object, and allow the separate
+ instances to be hacking on different parts of the program at the same time.</p>
+
+ <p>This implementation would prevent each of the passes from having to implement
+ multithreaded constructs, requiring only the LLVM core to have locking in a few
+ places (for global resources). Although this is a simple extension, we simply
+ haven't had time (or multiprocessor machines, thus a reason) to implement this.
+ Despite that, we have kept the LLVM passes SMP ready, and you should too.</p>
+
+ </div>
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/doxygen.cfg
diff -c /dev/null llvm-www/releases/2.5/docs/doxygen.cfg:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/doxygen.cfg Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1419 ----
+ # Doxyfile 1.5.6
+
+ # This file describes the settings to be used by the documentation system
+ # doxygen (www.doxygen.org) for a project
+ #
+ # All text after a hash (#) is considered a comment and will be ignored
+ # The format is:
+ # TAG = value [value, ...]
+ # For lists items can also be appended using:
+ # TAG += value [value, ...]
+ # Values that contain spaces should be placed between quotes (" ")
+
+ #---------------------------------------------------------------------------
+ # Project related configuration options
+ #---------------------------------------------------------------------------
+
+ # This tag specifies the encoding used for all characters in the config file
+ # that follow. The default is UTF-8 which is also the encoding used for all
+ # text before the first occurrence of this tag. Doxygen uses libiconv (or the
+ # iconv built into libc) for the transcoding. See
+ # http://www.gnu.org/software/libiconv for the list of possible encodings.
+
+ DOXYFILE_ENCODING = UTF-8
+
+ # The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+ # by quotes) that should identify the project.
+
+ PROJECT_NAME = LLVM
+
+ # The PROJECT_NUMBER tag can be used to enter a project or revision number.
+ # This could be handy for archiving the generated documentation or
+ # if some version control system is used.
+
+ PROJECT_NUMBER = 2.5
+
+ # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+ # base path where the generated documentation will be put.
+ # If a relative path is entered, it will be relative to the location
+ # where doxygen was started. If left blank the current directory will be used.
+
+ OUTPUT_DIRECTORY = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/docs/doxygen
+
+ # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+ # 4096 sub-directories (in 2 levels) under the output directory of each output
+ # format and will distribute the generated files over these directories.
+ # Enabling this option can be useful when feeding doxygen a huge amount of
+ # source files, where putting all generated files in the same directory would
+ # otherwise cause performance problems for the file system.
+
+ CREATE_SUBDIRS = NO
+
+ # The OUTPUT_LANGUAGE tag is used to specify the language in which all
+ # documentation generated by doxygen is written. Doxygen will use this
+ # information to generate all constant output in the proper language.
+ # The default language is English, other supported languages are:
+ # Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
+ # Croatian, Czech, Danish, Dutch, Farsi, Finnish, French, German, Greek,
+ # Hungarian, Italian, Japanese, Japanese-en (Japanese with English messages),
+ # Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, Polish,
+ # Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish,
+ # and Ukrainian.
+
+ OUTPUT_LANGUAGE = English
+
+ # If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+ # include brief member descriptions after the members that are listed in
+ # the file and class documentation (similar to JavaDoc).
+ # Set to NO to disable this.
+
+ BRIEF_MEMBER_DESC = YES
+
+ # If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+ # the brief description of a member or function before the detailed description.
+ # Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+ # brief descriptions will be completely suppressed.
+
+ REPEAT_BRIEF = YES
+
+ # This tag implements a quasi-intelligent brief description abbreviator
+ # that is used to form the text in various listings. Each string
+ # in this list, if found as the leading text of the brief description, will be
+ # stripped from the text and the result after processing the whole list, is
+ # used as the annotated text. Otherwise, the brief description is used as-is.
+ # If left blank, the following values are used ("$name" is automatically
+ # replaced with the name of the entity): "The $name class" "The $name widget"
+ # "The $name file" "is" "provides" "specifies" "contains"
+ # "represents" "a" "an" "the"
+
+ ABBREVIATE_BRIEF =
+
+ # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+ # Doxygen will generate a detailed section even if there is only a brief
+ # description.
+
+ ALWAYS_DETAILED_SEC = NO
+
+ # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+ # inherited members of a class in the documentation of that class as if those
+ # members were ordinary class members. Constructors, destructors and assignment
+ # operators of the base classes will not be shown.
+
+ INLINE_INHERITED_MEMB = NO
+
+ # If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+ # path before files name in the file list and in the header files. If set
+ # to NO the shortest path that makes the file name unique will be used.
+
+ FULL_PATH_NAMES = NO
+
+ # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+ # can be used to strip a user-defined part of the path. Stripping is
+ # only done if one of the specified strings matches the left-hand part of
+ # the path. The tag can be used to show relative paths in the file list.
+ # If left blank the directory from which doxygen is run is used as the
+ # path to strip.
+
+ STRIP_FROM_PATH = ../..
+
+ # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+ # the path mentioned in the documentation of a class, which tells
+ # the reader which header file to include in order to use a class.
+ # If left blank only the name of the header file containing the class
+ # definition is used. Otherwise one should specify the include paths that
+ # are normally passed to the compiler using the -I flag.
+
+ STRIP_FROM_INC_PATH =
+
+ # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+ # (but less readable) file names. This can be useful is your file systems
+ # doesn't support long names like on DOS, Mac, or CD-ROM.
+
+ SHORT_NAMES = NO
+
+ # If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+ # will interpret the first line (until the first dot) of a JavaDoc-style
+ # comment as the brief description. If set to NO, the JavaDoc
+ # comments will behave just like regular Qt-style comments
+ # (thus requiring an explicit @brief command for a brief description.)
+
+ JAVADOC_AUTOBRIEF = NO
+
+ # If the QT_AUTOBRIEF tag is set to YES then Doxygen will
+ # interpret the first line (until the first dot) of a Qt-style
+ # comment as the brief description. If set to NO, the comments
+ # will behave just like regular Qt-style comments (thus requiring
+ # an explicit \brief command for a brief description.)
+
+ QT_AUTOBRIEF = NO
+
+ # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+ # treat a multi-line C++ special comment block (i.e. a block of //! or ///
+ # comments) as a brief description. This used to be the default behaviour.
+ # The new default is to treat a multi-line C++ comment block as a detailed
+ # description. Set this tag to YES if you prefer the old behaviour instead.
+
+ MULTILINE_CPP_IS_BRIEF = NO
+
+ # If the DETAILS_AT_TOP tag is set to YES then Doxygen
+ # will output the detailed description near the top, like JavaDoc.
+ # If set to NO, the detailed description appears after the member
+ # documentation.
+
+ DETAILS_AT_TOP = NO
+
+ # If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+ # member inherits the documentation from any documented member that it
+ # re-implements.
+
+ INHERIT_DOCS = YES
+
+ # If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+ # a new page for each member. If set to NO, the documentation of a member will
+ # be part of the file/class/namespace that contains it.
+
+ SEPARATE_MEMBER_PAGES = NO
+
+ # The TAB_SIZE tag can be used to set the number of spaces in a tab.
+ # Doxygen uses this value to replace tabs by spaces in code fragments.
+
+ TAB_SIZE = 2
+
+ # This tag can be used to specify a number of aliases that acts
+ # as commands in the documentation. An alias has the form "name=value".
+ # For example adding "sideeffect=\par Side Effects:\n" will allow you to
+ # put the command \sideeffect (or @sideeffect) in the documentation, which
+ # will result in a user-defined paragraph with heading "Side Effects:".
+ # You can put \n's in the value part of an alias to insert newlines.
+
+ ALIASES =
+
+ # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+ # sources only. Doxygen will then generate output that is more tailored for C.
+ # For instance, some of the names that are used will be different. The list
+ # of all members will be omitted, etc.
+
+ OPTIMIZE_OUTPUT_FOR_C = NO
+
+ # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+ # sources only. Doxygen will then generate output that is more tailored for
+ # Java. For instance, namespaces will be presented as packages, qualified
+ # scopes will look different, etc.
+
+ OPTIMIZE_OUTPUT_JAVA = NO
+
+ # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+ # sources only. Doxygen will then generate output that is more tailored for
+ # Fortran.
+
+ OPTIMIZE_FOR_FORTRAN = NO
+
+ # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+ # sources. Doxygen will then generate output that is tailored for
+ # VHDL.
+
+ OPTIMIZE_OUTPUT_VHDL = NO
+
+ # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+ # to include (a tag file for) the STL sources as input, then you should
+ # set this tag to YES in order to let doxygen match functions declarations and
+ # definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+ # func(std::string) {}). This also make the inheritance and collaboration
+ # diagrams that involve STL classes more complete and accurate.
+
+ BUILTIN_STL_SUPPORT = NO
+
+ # If you use Microsoft's C++/CLI language, you should set this option to YES to
+ # enable parsing support.
+
+ CPP_CLI_SUPPORT = NO
+
+ # Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
+ # Doxygen will parse them like normal C++ but will assume all classes use public
+ # instead of private inheritance when no explicit protection keyword is present.
+
+ SIP_SUPPORT = NO
+
+ # For Microsoft's IDL there are propget and propput attributes to indicate getter
+ # and setter methods for a property. Setting this option to YES (the default)
+ # will make doxygen to replace the get and set methods by a property in the
+ # documentation. This will only work if the methods are indeed getting or
+ # setting a simple type. If this is not the case, or you want to show the
+ # methods anyway, you should set this option to NO.
+
+ IDL_PROPERTY_SUPPORT = YES
+
+ # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+ # tag is set to YES, then doxygen will reuse the documentation of the first
+ # member in the group (if any) for the other members of the group. By default
+ # all members of a group must be documented explicitly.
+
+ DISTRIBUTE_GROUP_DOC = NO
+
+ # Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+ # the same type (for instance a group of public functions) to be put as a
+ # subgroup of that type (e.g. under the Public Functions section). Set it to
+ # NO to prevent subgrouping. Alternatively, this can be done per class using
+ # the \nosubgrouping command.
+
+ SUBGROUPING = YES
+
+ # When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
+ # is documented as struct, union, or enum with the name of the typedef. So
+ # typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+ # with name TypeT. When disabled the typedef will appear as a member of a file,
+ # namespace, or class. And the struct will be named TypeS. This can typically
+ # be useful for C code in case the coding convention dictates that all compound
+ # types are typedef'ed and only the typedef is referenced, never the tag name.
+
+ TYPEDEF_HIDES_STRUCT = NO
+
+ #---------------------------------------------------------------------------
+ # Build related configuration options
+ #---------------------------------------------------------------------------
+
+ # If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+ # documentation are documented, even if no documentation was available.
+ # Private class members and static file members will be hidden unless
+ # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+ EXTRACT_ALL = YES
+
+ # If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+ # will be included in the documentation.
+
+ EXTRACT_PRIVATE = NO
+
+ # If the EXTRACT_STATIC tag is set to YES all static members of a file
+ # will be included in the documentation.
+
+ EXTRACT_STATIC = YES
+
+ # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+ # defined locally in source files will be included in the documentation.
+ # If set to NO only classes defined in header files are included.
+
+ EXTRACT_LOCAL_CLASSES = YES
+
+ # This flag is only useful for Objective-C code. When set to YES local
+ # methods, which are defined in the implementation section but not in
+ # the interface are included in the documentation.
+ # If set to NO (the default) only methods in the interface are included.
+
+ EXTRACT_LOCAL_METHODS = NO
+
+ # If this flag is set to YES, the members of anonymous namespaces will be
+ # extracted and appear in the documentation as a namespace called
+ # 'anonymous_namespace{file}', where file will be replaced with the base
+ # name of the file that contains the anonymous namespace. By default
+ # anonymous namespace are hidden.
+
+ EXTRACT_ANON_NSPACES = NO
+
+ # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+ # undocumented members of documented classes, files or namespaces.
+ # If set to NO (the default) these members will be included in the
+ # various overviews, but no documentation section is generated.
+ # This option has no effect if EXTRACT_ALL is enabled.
+
+ HIDE_UNDOC_MEMBERS = NO
+
+ # If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+ # undocumented classes that are normally visible in the class hierarchy.
+ # If set to NO (the default) these classes will be included in the various
+ # overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+ HIDE_UNDOC_CLASSES = NO
+
+ # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+ # friend (class|struct|union) declarations.
+ # If set to NO (the default) these declarations will be included in the
+ # documentation.
+
+ HIDE_FRIEND_COMPOUNDS = NO
+
+ # If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+ # documentation blocks found inside the body of a function.
+ # If set to NO (the default) these blocks will be appended to the
+ # function's detailed documentation block.
+
+ HIDE_IN_BODY_DOCS = NO
+
+ # The INTERNAL_DOCS tag determines if documentation
+ # that is typed after a \internal command is included. If the tag is set
+ # to NO (the default) then the documentation will be excluded.
+ # Set it to YES to include the internal documentation.
+
+ INTERNAL_DOCS = NO
+
+ # If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+ # file names in lower-case letters. If set to YES upper-case letters are also
+ # allowed. This is useful if you have classes or files whose names only differ
+ # in case and if your file system supports case sensitive file names. Windows
+ # and Mac users are advised to set this option to NO.
+
+ CASE_SENSE_NAMES = YES
+
+ # If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+ # will show members with their full class and namespace scopes in the
+ # documentation. If set to YES the scope will be hidden.
+
+ HIDE_SCOPE_NAMES = NO
+
+ # If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+ # will put a list of the files that are included by a file in the documentation
+ # of that file.
+
+ SHOW_INCLUDE_FILES = YES
+
+ # If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+ # is inserted in the documentation for inline members.
+
+ INLINE_INFO = YES
+
+ # If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+ # will sort the (detailed) documentation of file and class members
+ # alphabetically by member name. If set to NO the members will appear in
+ # declaration order.
+
+ SORT_MEMBER_DOCS = YES
+
+ # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+ # brief documentation of file, namespace and class members alphabetically
+ # by member name. If set to NO (the default) the members will appear in
+ # declaration order.
+
+ SORT_BRIEF_DOCS = NO
+
+ # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
+ # hierarchy of group names into alphabetical order. If set to NO (the default)
+ # the group names will appear in their defined order.
+
+ SORT_GROUP_NAMES = NO
+
+ # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+ # sorted by fully-qualified names, including namespaces. If set to
+ # NO (the default), the class list will be sorted only by class name,
+ # not including the namespace part.
+ # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+ # Note: This option applies only to the class list, not to the
+ # alphabetical list.
+
+ SORT_BY_SCOPE_NAME = NO
+
+ # The GENERATE_TODOLIST tag can be used to enable (YES) or
+ # disable (NO) the todo list. This list is created by putting \todo
+ # commands in the documentation.
+
+ GENERATE_TODOLIST = YES
+
+ # The GENERATE_TESTLIST tag can be used to enable (YES) or
+ # disable (NO) the test list. This list is created by putting \test
+ # commands in the documentation.
+
+ GENERATE_TESTLIST = YES
+
+ # The GENERATE_BUGLIST tag can be used to enable (YES) or
+ # disable (NO) the bug list. This list is created by putting \bug
+ # commands in the documentation.
+
+ GENERATE_BUGLIST = YES
+
+ # The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+ # disable (NO) the deprecated list. This list is created by putting
+ # \deprecated commands in the documentation.
+
+ GENERATE_DEPRECATEDLIST= YES
+
+ # The ENABLED_SECTIONS tag can be used to enable conditional
+ # documentation sections, marked by \if sectionname ... \endif.
+
+ ENABLED_SECTIONS =
+
+ # The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+ # the initial value of a variable or define consists of for it to appear in
+ # the documentation. If the initializer consists of more lines than specified
+ # here it will be hidden. Use a value of 0 to hide initializers completely.
+ # The appearance of the initializer of individual variables and defines in the
+ # documentation can be controlled using \showinitializer or \hideinitializer
+ # command in the documentation regardless of this setting.
+
+ MAX_INITIALIZER_LINES = 30
+
+ # Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+ # at the bottom of the documentation of classes and structs. If set to YES the
+ # list will mention the files that were used to generate the documentation.
+
+ SHOW_USED_FILES = YES
+
+ # If the sources in your project are distributed over multiple directories
+ # then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+ # in the documentation. The default is NO.
+
+ SHOW_DIRECTORIES = YES
+
+ # Set the SHOW_FILES tag to NO to disable the generation of the Files page.
+ # This will remove the Files entry from the Quick Index and from the
+ # Folder Tree View (if specified). The default is YES.
+
+ SHOW_FILES = YES
+
+ # Set the SHOW_NAMESPACES tag to NO to disable the generation of the
+ # Namespaces page. This will remove the Namespaces entry from the Quick Index
+ # and from the Folder Tree View (if specified). The default is YES.
+
+ SHOW_NAMESPACES = YES
+
+ # The FILE_VERSION_FILTER tag can be used to specify a program or script that
+ # doxygen should invoke to get the current version for each file (typically from
+ # the version control system). Doxygen will invoke the program by executing (via
+ # popen()) the command <command> <input-file>, where <command> is the value of
+ # the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file
+ # provided by doxygen. Whatever the program writes to standard output
+ # is used as the file version. See the manual for examples.
+
+ FILE_VERSION_FILTER =
+
+ #---------------------------------------------------------------------------
+ # configuration options related to warning and progress messages
+ #---------------------------------------------------------------------------
+
+ # The QUIET tag can be used to turn on/off the messages that are generated
+ # by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+ QUIET = NO
+
+ # The WARNINGS tag can be used to turn on/off the warning messages that are
+ # generated by doxygen. Possible values are YES and NO. If left blank
+ # NO is used.
+
+ WARNINGS = NO
+
+ # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+ # for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+ # automatically be disabled.
+
+ WARN_IF_UNDOCUMENTED = NO
+
+ # If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+ # potential errors in the documentation, such as not documenting some
+ # parameters in a documented function, or documenting parameters that
+ # don't exist or using markup commands wrongly.
+
+ WARN_IF_DOC_ERROR = YES
+
+ # This WARN_NO_PARAMDOC option can be abled to get warnings for
+ # functions that are documented, but have no documentation for their parameters
+ # or return value. If set to NO (the default) doxygen will only warn about
+ # wrong or incomplete parameter documentation, but not about the absence of
+ # documentation.
+
+ WARN_NO_PARAMDOC = NO
+
+ # The WARN_FORMAT tag determines the format of the warning messages that
+ # doxygen can produce. The string should contain the $file, $line, and $text
+ # tags, which will be replaced by the file and line number from which the
+ # warning originated and the warning text. Optionally the format may contain
+ # $version, which will be replaced by the version of the file (if it could
+ # be obtained via FILE_VERSION_FILTER)
+
+ WARN_FORMAT =
+
+ # The WARN_LOGFILE tag can be used to specify a file to which warning
+ # and error messages should be written. If left blank the output is written
+ # to stderr.
+
+ WARN_LOGFILE =
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the input files
+ #---------------------------------------------------------------------------
+
+ # The INPUT tag can be used to specify the files and/or directories that contain
+ # documented source files. You may enter file names like "myfile.cpp" or
+ # directories like "/usr/src/myproject". Separate the files or directories
+ # with spaces.
+
+ INPUT = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/include \
+ /localhome/tbrethou/2.5/prerelease2/llvm-2.5/lib \
+ /localhome/tbrethou/2.5/prerelease2/llvm-2.5/docs/doxygen.intro
+
+ # This tag can be used to specify the character encoding of the source files
+ # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
+ # also the default input encoding. Doxygen uses libiconv (or the iconv built
+ # into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
+ # the list of possible encodings.
+
+ INPUT_ENCODING = UTF-8
+
+ # If the value of the INPUT tag contains directories, you can use the
+ # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+ # and *.h) to filter out the source-files in the directories. If left
+ # blank the following patterns are tested:
+ # *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+ # *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
+
+ FILE_PATTERNS =
+
+ # The RECURSIVE tag can be used to turn specify whether or not subdirectories
+ # should be searched for input files as well. Possible values are YES and NO.
+ # If left blank NO is used.
+
+ RECURSIVE = YES
+
+ # The EXCLUDE tag can be used to specify files and/or directories that should
+ # excluded from the INPUT source files. This way you can easily exclude a
+ # subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+ EXCLUDE =
+
+ # The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+ # directories that are symbolic links (a Unix filesystem feature) are excluded
+ # from the input.
+
+ EXCLUDE_SYMLINKS = NO
+
+ # If the value of the INPUT tag contains directories, you can use the
+ # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+ # certain files from those directories. Note that the wildcards are matched
+ # against the file with absolute path, so to exclude all test directories
+ # for example use the pattern */test/*
+
+ EXCLUDE_PATTERNS =
+
+ # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+ # (namespaces, classes, functions, etc.) that should be excluded from the
+ # output. The symbol name can be a fully qualified name, a word, or if the
+ # wildcard * is used, a substring. Examples: ANamespace, AClass,
+ # AClass::ANamespace, ANamespace::*Test
+
+ EXCLUDE_SYMBOLS =
+
+ # The EXAMPLE_PATH tag can be used to specify one or more files or
+ # directories that contain example code fragments that are included (see
+ # the \include command).
+
+ EXAMPLE_PATH = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/examples
+
+ # If the value of the EXAMPLE_PATH tag contains directories, you can use the
+ # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+ # and *.h) to filter out the source-files in the directories. If left
+ # blank all files are included.
+
+ EXAMPLE_PATTERNS =
+
+ # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+ # searched for input files to be used with the \include or \dontinclude
+ # commands irrespective of the value of the RECURSIVE tag.
+ # Possible values are YES and NO. If left blank NO is used.
+
+ EXAMPLE_RECURSIVE = YES
+
+ # The IMAGE_PATH tag can be used to specify one or more files or
+ # directories that contain image that are included in the documentation (see
+ # the \image command).
+
+ IMAGE_PATH = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/docs/img
+
+ # The INPUT_FILTER tag can be used to specify a program that doxygen should
+ # invoke to filter for each input file. Doxygen will invoke the filter program
+ # by executing (via popen()) the command <filter> <input-file>, where <filter>
+ # is the value of the INPUT_FILTER tag, and <input-file> is the name of an
+ # input file. Doxygen will then use the output that the filter program writes
+ # to standard output. If FILTER_PATTERNS is specified, this tag will be
+ # ignored.
+
+ INPUT_FILTER =
+
+ # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+ # basis. Doxygen will compare the file name with each pattern and apply the
+ # filter if there is a match. The filters are a list of the form:
+ # pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+ # info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+ # is applied to all files.
+
+ FILTER_PATTERNS =
+
+ # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+ # INPUT_FILTER) will be used to filter the input files when producing source
+ # files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+ FILTER_SOURCE_FILES = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to source browsing
+ #---------------------------------------------------------------------------
+
+ # If the SOURCE_BROWSER tag is set to YES then a list of source files will
+ # be generated. Documented entities will be cross-referenced with these sources.
+ # Note: To get rid of all source code in the generated output, make sure also
+ # VERBATIM_HEADERS is set to NO.
+
+ SOURCE_BROWSER = YES
+
+ # Setting the INLINE_SOURCES tag to YES will include the body
+ # of functions and classes directly in the documentation.
+
+ INLINE_SOURCES = NO
+
+ # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+ # doxygen to hide any special comment blocks from generated source code
+ # fragments. Normal C and C++ comments will always remain visible.
+
+ STRIP_CODE_COMMENTS = NO
+
+ # If the REFERENCED_BY_RELATION tag is set to YES
+ # then for each documented function all documented
+ # functions referencing it will be listed.
+
+ REFERENCED_BY_RELATION = YES
+
+ # If the REFERENCES_RELATION tag is set to YES
+ # then for each documented function all documented entities
+ # called/used by that function will be listed.
+
+ REFERENCES_RELATION = YES
+
+ # If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
+ # and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
+ # functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
+ # link to the source code. Otherwise they will link to the documentstion.
+
+ REFERENCES_LINK_SOURCE = YES
+
+ # If the USE_HTAGS tag is set to YES then the references to source code
+ # will point to the HTML generated by the htags(1) tool instead of doxygen
+ # built-in source browser. The htags tool is part of GNU's global source
+ # tagging system (see http://www.gnu.org/software/global/global.html). You
+ # will need version 4.8.6 or higher.
+
+ USE_HTAGS = NO
+
+ # If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+ # will generate a verbatim copy of the header file for each class for
+ # which an include is specified. Set to NO to disable this.
+
+ VERBATIM_HEADERS = YES
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the alphabetical class index
+ #---------------------------------------------------------------------------
+
+ # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+ # of all compounds will be generated. Enable this if the project
+ # contains a lot of classes, structs, unions or interfaces.
+
+ ALPHABETICAL_INDEX = YES
+
+ # If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+ # the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+ # in which this list will be split (can be a number in the range [1..20])
+
+ COLS_IN_ALPHA_INDEX = 4
+
+ # In case all classes in a project start with a common prefix, all
+ # classes will be put under the same header in the alphabetical index.
+ # The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+ # should be ignored while generating the index headers.
+
+ IGNORE_PREFIX = llvm::
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the HTML output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+ # generate HTML output.
+
+ GENERATE_HTML = YES
+
+ # The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `html' will be used as the default path.
+
+ HTML_OUTPUT = html
+
+ # The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+ # each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+ # doxygen will generate files with .html extension.
+
+ HTML_FILE_EXTENSION = .html
+
+ # The HTML_HEADER tag can be used to specify a personal HTML header for
+ # each generated HTML page. If it is left blank doxygen will generate a
+ # standard header.
+
+ HTML_HEADER = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/docs/doxygen.header
+
+ # The HTML_FOOTER tag can be used to specify a personal HTML footer for
+ # each generated HTML page. If it is left blank doxygen will generate a
+ # standard footer.
+
+ HTML_FOOTER = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/docs/doxygen.footer
+
+ # The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+ # style sheet that is used by each HTML page. It can be used to
+ # fine-tune the look of the HTML output. If the tag is left blank doxygen
+ # will generate a default style sheet. Note that doxygen will try to copy
+ # the style sheet file to the HTML output directory, so don't put your own
+ # stylesheet in the HTML output directory as well, or it will be erased!
+
+ HTML_STYLESHEET = /localhome/tbrethou/2.5/prerelease2/llvm-2.5/docs/doxygen.css
+
+ # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+ # files or namespaces will be aligned in HTML using tables. If set to
+ # NO a bullet list will be used.
+
+ HTML_ALIGN_MEMBERS = YES
+
+ # If the GENERATE_HTMLHELP tag is set to YES, additional index files
+ # will be generated that can be used as input for tools like the
+ # Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
+ # of the generated HTML documentation.
+
+ GENERATE_HTMLHELP = NO
+
+ # If the GENERATE_DOCSET tag is set to YES, additional index files
+ # will be generated that can be used as input for Apple's Xcode 3
+ # integrated development environment, introduced with OSX 10.5 (Leopard).
+ # To create a documentation set, doxygen will generate a Makefile in the
+ # HTML output directory. Running make will produce the docset in that
+ # directory and running "make install" will install the docset in
+ # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
+ # it at startup.
+
+ GENERATE_DOCSET = NO
+
+ # When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
+ # feed. A documentation feed provides an umbrella under which multiple
+ # documentation sets from a single provider (such as a company or product suite)
+ # can be grouped.
+
+ DOCSET_FEEDNAME = "Doxygen generated docs"
+
+ # When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
+ # should uniquely identify the documentation set bundle. This should be a
+ # reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
+ # will append .docset to the name.
+
+ DOCSET_BUNDLE_ID = org.doxygen.Project
+
+ # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+ # documentation will contain sections that can be hidden and shown after the
+ # page has loaded. For this to work a browser that supports
+ # JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
+ # Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
+
+ HTML_DYNAMIC_SECTIONS = NO
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+ # be used to specify the file name of the resulting .chm file. You
+ # can add a path in front of the file if the result should not be
+ # written to the html output directory.
+
+ CHM_FILE =
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+ # be used to specify the location (absolute path including file name) of
+ # the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+ # the HTML help compiler on the generated index.hhp.
+
+ HHC_LOCATION =
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+ # controls if a separate .chi index file is generated (YES) or that
+ # it should be included in the master .chm file (NO).
+
+ GENERATE_CHI = NO
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
+ # is used to encode HtmlHelp index (hhk), content (hhc) and project file
+ # content.
+
+ CHM_INDEX_ENCODING =
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+ # controls whether a binary table of contents is generated (YES) or a
+ # normal table of contents (NO) in the .chm file.
+
+ BINARY_TOC = NO
+
+ # The TOC_EXPAND flag can be set to YES to add extra items for group members
+ # to the contents of the HTML help documentation and to the tree view.
+
+ TOC_EXPAND = NO
+
+ # The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+ # top of each HTML page. The value NO (the default) enables the index and
+ # the value YES disables it.
+
+ DISABLE_INDEX = NO
+
+ # This tag can be used to set the number of enum values (range [1..20])
+ # that doxygen will group on one line in the generated HTML documentation.
+
+ ENUM_VALUES_PER_LINE = 4
+
+ # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+ # structure should be generated to display hierarchical information.
+ # If the tag value is set to FRAME, a side panel will be generated
+ # containing a tree-like index structure (just like the one that
+ # is generated for HTML Help). For this to work a browser that supports
+ # JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
+ # Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
+ # probably better off using the HTML help feature. Other possible values
+ # for this tag are: HIERARCHIES, which will generate the Groups, Directories,
+ # and Class Hiererachy pages using a tree view instead of an ordered list;
+ # ALL, which combines the behavior of FRAME and HIERARCHIES; and NONE, which
+ # disables this behavior completely. For backwards compatibility with previous
+ # releases of Doxygen, the values YES and NO are equivalent to FRAME and NONE
+ # respectively.
+
+ GENERATE_TREEVIEW = NO
+
+ # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+ # used to set the initial width (in pixels) of the frame in which the tree
+ # is shown.
+
+ TREEVIEW_WIDTH = 250
+
+ # Use this tag to change the font size of Latex formulas included
+ # as images in the HTML documentation. The default is 10. Note that
+ # when you change the font size after a successful doxygen run you need
+ # to manually remove any form_*.png images from the HTML output directory
+ # to force them to be regenerated.
+
+ FORMULA_FONTSIZE = 10
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the LaTeX output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+ # generate Latex output.
+
+ GENERATE_LATEX = NO
+
+ # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `latex' will be used as the default path.
+
+ LATEX_OUTPUT =
+
+ # The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+ # invoked. If left blank `latex' will be used as the default command name.
+
+ LATEX_CMD_NAME = latex
+
+ # The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+ # generate index for LaTeX. If left blank `makeindex' will be used as the
+ # default command name.
+
+ MAKEINDEX_CMD_NAME = makeindex
+
+ # If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+ # LaTeX documents. This may be useful for small projects and may help to
+ # save some trees in general.
+
+ COMPACT_LATEX = NO
+
+ # The PAPER_TYPE tag can be used to set the paper type that is used
+ # by the printer. Possible values are: a4, a4wide, letter, legal and
+ # executive. If left blank a4wide will be used.
+
+ PAPER_TYPE = letter
+
+ # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+ # packages that should be included in the LaTeX output.
+
+ EXTRA_PACKAGES =
+
+ # The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+ # the generated latex document. The header should contain everything until
+ # the first chapter. If it is left blank doxygen will generate a
+ # standard header. Notice: only use this tag if you know what you are doing!
+
+ LATEX_HEADER =
+
+ # If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+ # is prepared for conversion to pdf (using ps2pdf). The pdf file will
+ # contain links (just like the HTML output) instead of page references
+ # This makes the output suitable for online browsing using a pdf viewer.
+
+ PDF_HYPERLINKS = NO
+
+ # If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+ # plain latex in the generated Makefile. Set this option to YES to get a
+ # higher quality PDF documentation.
+
+ USE_PDFLATEX = NO
+
+ # If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+ # command to the generated LaTeX files. This will instruct LaTeX to keep
+ # running if errors occur, instead of asking the user for help.
+ # This option is also used when generating formulas in HTML.
+
+ LATEX_BATCHMODE = NO
+
+ # If LATEX_HIDE_INDICES is set to YES then doxygen will not
+ # include the index chapters (such as File Index, Compound Index, etc.)
+ # in the output.
+
+ LATEX_HIDE_INDICES = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the RTF output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+ # The RTF output is optimized for Word 97 and may not look very pretty with
+ # other RTF readers or editors.
+
+ GENERATE_RTF = NO
+
+ # The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `rtf' will be used as the default path.
+
+ RTF_OUTPUT =
+
+ # If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+ # RTF documents. This may be useful for small projects and may help to
+ # save some trees in general.
+
+ COMPACT_RTF = NO
+
+ # If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+ # will contain hyperlink fields. The RTF file will
+ # contain links (just like the HTML output) instead of page references.
+ # This makes the output suitable for online browsing using WORD or other
+ # programs which support those fields.
+ # Note: wordpad (write) and others do not support links.
+
+ RTF_HYPERLINKS = NO
+
+ # Load stylesheet definitions from file. Syntax is similar to doxygen's
+ # config file, i.e. a series of assignments. You only have to provide
+ # replacements, missing definitions are set to their default value.
+
+ RTF_STYLESHEET_FILE =
+
+ # Set optional variables used in the generation of an rtf document.
+ # Syntax is similar to doxygen's config file.
+
+ RTF_EXTENSIONS_FILE =
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the man page output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+ # generate man pages
+
+ GENERATE_MAN = NO
+
+ # The MAN_OUTPUT tag is used to specify where the man pages will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `man' will be used as the default path.
+
+ MAN_OUTPUT =
+
+ # The MAN_EXTENSION tag determines the extension that is added to
+ # the generated man pages (default is the subroutine's section .3)
+
+ MAN_EXTENSION =
+
+ # If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+ # then it will generate one additional man file for each entity
+ # documented in the real man page(s). These additional files
+ # only source the real man page, but without them the man command
+ # would be unable to find the correct page. The default is NO.
+
+ MAN_LINKS = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the XML output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_XML tag is set to YES Doxygen will
+ # generate an XML file that captures the structure of
+ # the code including all documentation.
+
+ GENERATE_XML = NO
+
+ # The XML_OUTPUT tag is used to specify where the XML pages will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `xml' will be used as the default path.
+
+ XML_OUTPUT = xml
+
+ # The XML_SCHEMA tag can be used to specify an XML schema,
+ # which can be used by a validating XML parser to check the
+ # syntax of the XML files.
+
+ XML_SCHEMA =
+
+ # The XML_DTD tag can be used to specify an XML DTD,
+ # which can be used by a validating XML parser to check the
+ # syntax of the XML files.
+
+ XML_DTD =
+
+ # If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+ # dump the program listings (including syntax highlighting
+ # and cross-referencing information) to the XML output. Note that
+ # enabling this will significantly increase the size of the XML output.
+
+ XML_PROGRAMLISTING = YES
+
+ #---------------------------------------------------------------------------
+ # configuration options for the AutoGen Definitions output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+ # generate an AutoGen Definitions (see autogen.sf.net) file
+ # that captures the structure of the code including all
+ # documentation. Note that this feature is still experimental
+ # and incomplete at the moment.
+
+ GENERATE_AUTOGEN_DEF = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the Perl module output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_PERLMOD tag is set to YES Doxygen will
+ # generate a Perl module file that captures the structure of
+ # the code including all documentation. Note that this
+ # feature is still experimental and incomplete at the
+ # moment.
+
+ GENERATE_PERLMOD = NO
+
+ # If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+ # the necessary Makefile rules, Perl scripts and LaTeX code to be able
+ # to generate PDF and DVI output from the Perl module output.
+
+ PERLMOD_LATEX = NO
+
+ # If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+ # nicely formatted so it can be parsed by a human reader. This is useful
+ # if you want to understand what is going on. On the other hand, if this
+ # tag is set to NO the size of the Perl module output will be much smaller
+ # and Perl will parse it just the same.
+
+ PERLMOD_PRETTY = YES
+
+ # The names of the make variables in the generated doxyrules.make file
+ # are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+ # This is useful so different doxyrules.make files included by the same
+ # Makefile don't overwrite each other's variables.
+
+ PERLMOD_MAKEVAR_PREFIX =
+
+ #---------------------------------------------------------------------------
+ # Configuration options related to the preprocessor
+ #---------------------------------------------------------------------------
+
+ # If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+ # evaluate all C-preprocessor directives found in the sources and include
+ # files.
+
+ ENABLE_PREPROCESSING = YES
+
+ # If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+ # names in the source code. If set to NO (the default) only conditional
+ # compilation will be performed. Macro expansion can be done in a controlled
+ # way by setting EXPAND_ONLY_PREDEF to YES.
+
+ MACRO_EXPANSION = NO
+
+ # If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+ # then the macro expansion is limited to the macros specified with the
+ # PREDEFINED and EXPAND_AS_DEFINED tags.
+
+ EXPAND_ONLY_PREDEF = NO
+
+ # If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+ # in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+ SEARCH_INCLUDES = YES
+
+ # The INCLUDE_PATH tag can be used to specify one or more directories that
+ # contain include files that are not input files but should be processed by
+ # the preprocessor.
+
+ INCLUDE_PATH = ../include
+
+ # You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+ # patterns (like *.h and *.hpp) to filter out the header-files in the
+ # directories. If left blank, the patterns specified with FILE_PATTERNS will
+ # be used.
+
+ INCLUDE_FILE_PATTERNS =
+
+ # The PREDEFINED tag can be used to specify one or more macro names that
+ # are defined before the preprocessor is started (similar to the -D option of
+ # gcc). The argument of the tag is a list of macros of the form: name
+ # or name=definition (no spaces). If the definition and the = are
+ # omitted =1 is assumed. To prevent a macro definition from being
+ # undefined via #undef or recursively expanded use the := operator
+ # instead of the = operator.
+
+ PREDEFINED =
+
+ # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+ # this tag can be used to specify a list of macro names that should be expanded.
+ # The macro definition that is found in the sources will be used.
+ # Use the PREDEFINED tag if you want to use a different macro definition.
+
+ EXPAND_AS_DEFINED =
+
+ # If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+ # doxygen's preprocessor will remove all function-like macros that are alone
+ # on a line, have an all uppercase name, and do not end with a semicolon. Such
+ # function macros are typically used for boiler-plate code, and will confuse
+ # the parser if not removed.
+
+ SKIP_FUNCTION_MACROS = YES
+
+ #---------------------------------------------------------------------------
+ # Configuration::additions related to external references
+ #---------------------------------------------------------------------------
+
+ # The TAGFILES option can be used to specify one or more tagfiles.
+ # Optionally an initial location of the external documentation
+ # can be added for each tagfile. The format of a tag file without
+ # this location is as follows:
+ # TAGFILES = file1 file2 ...
+ # Adding location for the tag files is done as follows:
+ # TAGFILES = file1=loc1 "file2 = loc2" ...
+ # where "loc1" and "loc2" can be relative or absolute paths or
+ # URLs. If a location is present for each tag, the installdox tool
+ # does not have to be run to correct the links.
+ # Note that each tag file must have a unique name
+ # (where the name does NOT include the path)
+ # If a tag file is not located in the directory in which doxygen
+ # is run, you must also specify the path to the tagfile here.
+
+ TAGFILES =
+
+ # When a file name is specified after GENERATE_TAGFILE, doxygen will create
+ # a tag file that is based on the input files it reads.
+
+ GENERATE_TAGFILE =
+
+ # If the ALLEXTERNALS tag is set to YES all external classes will be listed
+ # in the class index. If set to NO only the inherited external classes
+ # will be listed.
+
+ ALLEXTERNALS = YES
+
+ # If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+ # in the modules index. If set to NO, only the current project's groups will
+ # be listed.
+
+ EXTERNAL_GROUPS = YES
+
+ # The PERL_PATH should be the absolute path and name of the perl script
+ # interpreter (i.e. the result of `which perl').
+
+ PERL_PATH =
+
+ #---------------------------------------------------------------------------
+ # Configuration options related to the dot tool
+ #---------------------------------------------------------------------------
+
+ # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+ # generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+ # or super classes. Setting the tag to NO turns the diagrams off. Note that
+ # this option is superseded by the HAVE_DOT option below. This is only a
+ # fallback. It is recommended to install and use dot, since it yields more
+ # powerful graphs.
+
+ CLASS_DIAGRAMS = YES
+
+ # You can define message sequence charts within doxygen comments using the \msc
+ # command. Doxygen will then run the mscgen tool (see
+ # http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
+ # documentation. The MSCGEN_PATH tag allows you to specify the directory where
+ # the mscgen tool resides. If left empty the tool is assumed to be found in the
+ # default search path.
+
+ MSCGEN_PATH =
+
+ # If set to YES, the inheritance and collaboration graphs will hide
+ # inheritance and usage relations if the target is undocumented
+ # or is not a class.
+
+ HIDE_UNDOC_RELATIONS = NO
+
+ # If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+ # available from the path. This tool is part of Graphviz, a graph visualization
+ # toolkit from AT&T and Lucent Bell Labs. The other options in this section
+ # have no effect if this option is set to NO (the default)
+
+ HAVE_DOT = YES
+
+ # By default doxygen will write a font called FreeSans.ttf to the output
+ # directory and reference it in all dot files that doxygen generates. This
+ # font does not include all possible unicode characters however, so when you need
+ # these (or just want a differently looking font) you can specify the font name
+ # using DOT_FONTNAME. You need need to make sure dot is able to find the font,
+ # which can be done by putting it in a standard location or by setting the
+ # DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory
+ # containing the font.
+
+ DOT_FONTNAME = FreeSans
+
+ # By default doxygen will tell dot to use the output directory to look for the
+ # FreeSans.ttf font (which doxygen will put there itself). If you specify a
+ # different font using DOT_FONTNAME you can set the path where dot
+ # can find it using this tag.
+
+ DOT_FONTPATH =
+
+ # If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+ # will generate a graph for each documented class showing the direct and
+ # indirect inheritance relations. Setting this tag to YES will force the
+ # the CLASS_DIAGRAMS tag to NO.
+
+ CLASS_GRAPH = YES
+
+ # If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+ # will generate a graph for each documented class showing the direct and
+ # indirect implementation dependencies (inheritance, containment, and
+ # class references variables) of the class with other documented classes.
+
+ COLLABORATION_GRAPH = YES
+
+ # If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+ # will generate a graph for groups, showing the direct groups dependencies
+
+ GROUP_GRAPHS = YES
+
+ # If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+ # collaboration diagrams in a style similar to the OMG's Unified Modeling
+ # Language.
+
+ UML_LOOK = NO
+
+ # If set to YES, the inheritance and collaboration graphs will show the
+ # relations between templates and their instances.
+
+ TEMPLATE_RELATIONS = YES
+
+ # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+ # tags are set to YES then doxygen will generate a graph for each documented
+ # file showing the direct and indirect include dependencies of the file with
+ # other documented files.
+
+ INCLUDE_GRAPH = YES
+
+ # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+ # HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+ # documented header file showing the documented files that directly or
+ # indirectly include this file.
+
+ INCLUDED_BY_GRAPH = YES
+
+ # If the CALL_GRAPH and HAVE_DOT options are set to YES then
+ # doxygen will generate a call dependency graph for every global function
+ # or class method. Note that enabling this option will significantly increase
+ # the time of a run. So in most cases it will be better to enable call graphs
+ # for selected functions only using the \callgraph command.
+
+ CALL_GRAPH = NO
+
+ # If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
+ # doxygen will generate a caller dependency graph for every global function
+ # or class method. Note that enabling this option will significantly increase
+ # the time of a run. So in most cases it will be better to enable caller
+ # graphs for selected functions only using the \callergraph command.
+
+ CALLER_GRAPH = NO
+
+ # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+ # will graphical hierarchy of all classes instead of a textual one.
+
+ GRAPHICAL_HIERARCHY = YES
+
+ # If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+ # then doxygen will show the dependencies a directory has on other directories
+ # in a graphical way. The dependency relations are determined by the #include
+ # relations between the files in the directories.
+
+ DIRECTORY_GRAPH = YES
+
+ # The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+ # generated by dot. Possible values are png, jpg, or gif
+ # If left blank png will be used.
+
+ DOT_IMAGE_FORMAT = png
+
+ # The tag DOT_PATH can be used to specify the path where the dot tool can be
+ # found. If left blank, it is assumed the dot tool can be found in the path.
+
+ DOT_PATH = echo dot
+
+ # The DOTFILE_DIRS tag can be used to specify one or more directories that
+ # contain dot files that are included in the documentation (see the
+ # \dotfile command).
+
+ DOTFILE_DIRS =
+
+ # The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
+ # nodes that will be shown in the graph. If the number of nodes in a graph
+ # becomes larger than this value, doxygen will truncate the graph, which is
+ # visualized by representing a node as a red box. Note that doxygen if the
+ # number of direct children of the root node in a graph is already larger than
+ # DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
+ # that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+
+ DOT_GRAPH_MAX_NODES = 50
+
+ # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+ # graphs generated by dot. A depth value of 3 means that only nodes reachable
+ # from the root by following a path via at most 3 edges will be shown. Nodes
+ # that lay further from the root node will be omitted. Note that setting this
+ # option to 1 or 2 may greatly reduce the computation time needed for large
+ # code bases. Also note that the size of a graph can be further restricted by
+ # DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+
+ MAX_DOT_GRAPH_DEPTH = 0
+
+ # Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+ # background. This is enabled by default, which results in a transparent
+ # background. Warning: Depending on the platform used, enabling this option
+ # may lead to badly anti-aliased labels on the edges of a graph (i.e. they
+ # become hard to read).
+
+ DOT_TRANSPARENT = YES
+
+ # Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+ # files in one run (i.e. multiple -o and -T options on the command line). This
+ # makes dot run faster, but since only newer versions of dot (>1.8.10)
+ # support this, this feature is disabled by default.
+
+ DOT_MULTI_TARGETS = NO
+
+ # If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+ # generate a legend page explaining the meaning of the various boxes and
+ # arrows in the dot generated graphs.
+
+ GENERATE_LEGEND = YES
+
+ # If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+ # remove the intermediate dot files that are used to generate
+ # the various graphs.
+
+ DOT_CLEANUP = YES
+
+ #---------------------------------------------------------------------------
+ # Configuration::additions related to the search engine
+ #---------------------------------------------------------------------------
+
+ # The SEARCHENGINE tag specifies whether or not a search engine should be
+ # used. If set to NO the values of all tags below this one will be ignored.
+
+ SEARCHENGINE = NO
Index: llvm-www/releases/2.5/docs/doxygen.cfg.in
diff -c /dev/null llvm-www/releases/2.5/docs/doxygen.cfg.in:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/doxygen.cfg.in Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,1419 ----
+ # Doxyfile 1.5.6
+
+ # This file describes the settings to be used by the documentation system
+ # doxygen (www.doxygen.org) for a project
+ #
+ # All text after a hash (#) is considered a comment and will be ignored
+ # The format is:
+ # TAG = value [value, ...]
+ # For lists items can also be appended using:
+ # TAG += value [value, ...]
+ # Values that contain spaces should be placed between quotes (" ")
+
+ #---------------------------------------------------------------------------
+ # Project related configuration options
+ #---------------------------------------------------------------------------
+
+ # This tag specifies the encoding used for all characters in the config file
+ # that follow. The default is UTF-8 which is also the encoding used for all
+ # text before the first occurrence of this tag. Doxygen uses libiconv (or the
+ # iconv built into libc) for the transcoding. See
+ # http://www.gnu.org/software/libiconv for the list of possible encodings.
+
+ DOXYFILE_ENCODING = UTF-8
+
+ # The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+ # by quotes) that should identify the project.
+
+ PROJECT_NAME = LLVM
+
+ # The PROJECT_NUMBER tag can be used to enter a project or revision number.
+ # This could be handy for archiving the generated documentation or
+ # if some version control system is used.
+
+ PROJECT_NUMBER = @PACKAGE_VERSION@
+
+ # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+ # base path where the generated documentation will be put.
+ # If a relative path is entered, it will be relative to the location
+ # where doxygen was started. If left blank the current directory will be used.
+
+ OUTPUT_DIRECTORY = @abs_top_builddir@/docs/doxygen
+
+ # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+ # 4096 sub-directories (in 2 levels) under the output directory of each output
+ # format and will distribute the generated files over these directories.
+ # Enabling this option can be useful when feeding doxygen a huge amount of
+ # source files, where putting all generated files in the same directory would
+ # otherwise cause performance problems for the file system.
+
+ CREATE_SUBDIRS = NO
+
+ # The OUTPUT_LANGUAGE tag is used to specify the language in which all
+ # documentation generated by doxygen is written. Doxygen will use this
+ # information to generate all constant output in the proper language.
+ # The default language is English, other supported languages are:
+ # Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
+ # Croatian, Czech, Danish, Dutch, Farsi, Finnish, French, German, Greek,
+ # Hungarian, Italian, Japanese, Japanese-en (Japanese with English messages),
+ # Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, Polish,
+ # Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish, Swedish,
+ # and Ukrainian.
+
+ OUTPUT_LANGUAGE = English
+
+ # If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+ # include brief member descriptions after the members that are listed in
+ # the file and class documentation (similar to JavaDoc).
+ # Set to NO to disable this.
+
+ BRIEF_MEMBER_DESC = YES
+
+ # If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+ # the brief description of a member or function before the detailed description.
+ # Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+ # brief descriptions will be completely suppressed.
+
+ REPEAT_BRIEF = YES
+
+ # This tag implements a quasi-intelligent brief description abbreviator
+ # that is used to form the text in various listings. Each string
+ # in this list, if found as the leading text of the brief description, will be
+ # stripped from the text and the result after processing the whole list, is
+ # used as the annotated text. Otherwise, the brief description is used as-is.
+ # If left blank, the following values are used ("$name" is automatically
+ # replaced with the name of the entity): "The $name class" "The $name widget"
+ # "The $name file" "is" "provides" "specifies" "contains"
+ # "represents" "a" "an" "the"
+
+ ABBREVIATE_BRIEF =
+
+ # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+ # Doxygen will generate a detailed section even if there is only a brief
+ # description.
+
+ ALWAYS_DETAILED_SEC = NO
+
+ # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+ # inherited members of a class in the documentation of that class as if those
+ # members were ordinary class members. Constructors, destructors and assignment
+ # operators of the base classes will not be shown.
+
+ INLINE_INHERITED_MEMB = NO
+
+ # If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+ # path before files name in the file list and in the header files. If set
+ # to NO the shortest path that makes the file name unique will be used.
+
+ FULL_PATH_NAMES = NO
+
+ # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+ # can be used to strip a user-defined part of the path. Stripping is
+ # only done if one of the specified strings matches the left-hand part of
+ # the path. The tag can be used to show relative paths in the file list.
+ # If left blank the directory from which doxygen is run is used as the
+ # path to strip.
+
+ STRIP_FROM_PATH = ../..
+
+ # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+ # the path mentioned in the documentation of a class, which tells
+ # the reader which header file to include in order to use a class.
+ # If left blank only the name of the header file containing the class
+ # definition is used. Otherwise one should specify the include paths that
+ # are normally passed to the compiler using the -I flag.
+
+ STRIP_FROM_INC_PATH =
+
+ # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+ # (but less readable) file names. This can be useful is your file systems
+ # doesn't support long names like on DOS, Mac, or CD-ROM.
+
+ SHORT_NAMES = NO
+
+ # If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+ # will interpret the first line (until the first dot) of a JavaDoc-style
+ # comment as the brief description. If set to NO, the JavaDoc
+ # comments will behave just like regular Qt-style comments
+ # (thus requiring an explicit @brief command for a brief description.)
+
+ JAVADOC_AUTOBRIEF = NO
+
+ # If the QT_AUTOBRIEF tag is set to YES then Doxygen will
+ # interpret the first line (until the first dot) of a Qt-style
+ # comment as the brief description. If set to NO, the comments
+ # will behave just like regular Qt-style comments (thus requiring
+ # an explicit \brief command for a brief description.)
+
+ QT_AUTOBRIEF = NO
+
+ # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+ # treat a multi-line C++ special comment block (i.e. a block of //! or ///
+ # comments) as a brief description. This used to be the default behaviour.
+ # The new default is to treat a multi-line C++ comment block as a detailed
+ # description. Set this tag to YES if you prefer the old behaviour instead.
+
+ MULTILINE_CPP_IS_BRIEF = NO
+
+ # If the DETAILS_AT_TOP tag is set to YES then Doxygen
+ # will output the detailed description near the top, like JavaDoc.
+ # If set to NO, the detailed description appears after the member
+ # documentation.
+
+ DETAILS_AT_TOP = NO
+
+ # If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+ # member inherits the documentation from any documented member that it
+ # re-implements.
+
+ INHERIT_DOCS = YES
+
+ # If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+ # a new page for each member. If set to NO, the documentation of a member will
+ # be part of the file/class/namespace that contains it.
+
+ SEPARATE_MEMBER_PAGES = NO
+
+ # The TAB_SIZE tag can be used to set the number of spaces in a tab.
+ # Doxygen uses this value to replace tabs by spaces in code fragments.
+
+ TAB_SIZE = 2
+
+ # This tag can be used to specify a number of aliases that acts
+ # as commands in the documentation. An alias has the form "name=value".
+ # For example adding "sideeffect=\par Side Effects:\n" will allow you to
+ # put the command \sideeffect (or @sideeffect) in the documentation, which
+ # will result in a user-defined paragraph with heading "Side Effects:".
+ # You can put \n's in the value part of an alias to insert newlines.
+
+ ALIASES =
+
+ # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+ # sources only. Doxygen will then generate output that is more tailored for C.
+ # For instance, some of the names that are used will be different. The list
+ # of all members will be omitted, etc.
+
+ OPTIMIZE_OUTPUT_FOR_C = NO
+
+ # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+ # sources only. Doxygen will then generate output that is more tailored for
+ # Java. For instance, namespaces will be presented as packages, qualified
+ # scopes will look different, etc.
+
+ OPTIMIZE_OUTPUT_JAVA = NO
+
+ # Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+ # sources only. Doxygen will then generate output that is more tailored for
+ # Fortran.
+
+ OPTIMIZE_FOR_FORTRAN = NO
+
+ # Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+ # sources. Doxygen will then generate output that is tailored for
+ # VHDL.
+
+ OPTIMIZE_OUTPUT_VHDL = NO
+
+ # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+ # to include (a tag file for) the STL sources as input, then you should
+ # set this tag to YES in order to let doxygen match functions declarations and
+ # definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+ # func(std::string) {}). This also make the inheritance and collaboration
+ # diagrams that involve STL classes more complete and accurate.
+
+ BUILTIN_STL_SUPPORT = NO
+
+ # If you use Microsoft's C++/CLI language, you should set this option to YES to
+ # enable parsing support.
+
+ CPP_CLI_SUPPORT = NO
+
+ # Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
+ # Doxygen will parse them like normal C++ but will assume all classes use public
+ # instead of private inheritance when no explicit protection keyword is present.
+
+ SIP_SUPPORT = NO
+
+ # For Microsoft's IDL there are propget and propput attributes to indicate getter
+ # and setter methods for a property. Setting this option to YES (the default)
+ # will make doxygen to replace the get and set methods by a property in the
+ # documentation. This will only work if the methods are indeed getting or
+ # setting a simple type. If this is not the case, or you want to show the
+ # methods anyway, you should set this option to NO.
+
+ IDL_PROPERTY_SUPPORT = YES
+
+ # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+ # tag is set to YES, then doxygen will reuse the documentation of the first
+ # member in the group (if any) for the other members of the group. By default
+ # all members of a group must be documented explicitly.
+
+ DISTRIBUTE_GROUP_DOC = NO
+
+ # Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+ # the same type (for instance a group of public functions) to be put as a
+ # subgroup of that type (e.g. under the Public Functions section). Set it to
+ # NO to prevent subgrouping. Alternatively, this can be done per class using
+ # the \nosubgrouping command.
+
+ SUBGROUPING = YES
+
+ # When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
+ # is documented as struct, union, or enum with the name of the typedef. So
+ # typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+ # with name TypeT. When disabled the typedef will appear as a member of a file,
+ # namespace, or class. And the struct will be named TypeS. This can typically
+ # be useful for C code in case the coding convention dictates that all compound
+ # types are typedef'ed and only the typedef is referenced, never the tag name.
+
+ TYPEDEF_HIDES_STRUCT = NO
+
+ #---------------------------------------------------------------------------
+ # Build related configuration options
+ #---------------------------------------------------------------------------
+
+ # If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+ # documentation are documented, even if no documentation was available.
+ # Private class members and static file members will be hidden unless
+ # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+ EXTRACT_ALL = YES
+
+ # If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+ # will be included in the documentation.
+
+ EXTRACT_PRIVATE = NO
+
+ # If the EXTRACT_STATIC tag is set to YES all static members of a file
+ # will be included in the documentation.
+
+ EXTRACT_STATIC = YES
+
+ # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+ # defined locally in source files will be included in the documentation.
+ # If set to NO only classes defined in header files are included.
+
+ EXTRACT_LOCAL_CLASSES = YES
+
+ # This flag is only useful for Objective-C code. When set to YES local
+ # methods, which are defined in the implementation section but not in
+ # the interface are included in the documentation.
+ # If set to NO (the default) only methods in the interface are included.
+
+ EXTRACT_LOCAL_METHODS = NO
+
+ # If this flag is set to YES, the members of anonymous namespaces will be
+ # extracted and appear in the documentation as a namespace called
+ # 'anonymous_namespace{file}', where file will be replaced with the base
+ # name of the file that contains the anonymous namespace. By default
+ # anonymous namespace are hidden.
+
+ EXTRACT_ANON_NSPACES = NO
+
+ # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+ # undocumented members of documented classes, files or namespaces.
+ # If set to NO (the default) these members will be included in the
+ # various overviews, but no documentation section is generated.
+ # This option has no effect if EXTRACT_ALL is enabled.
+
+ HIDE_UNDOC_MEMBERS = NO
+
+ # If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+ # undocumented classes that are normally visible in the class hierarchy.
+ # If set to NO (the default) these classes will be included in the various
+ # overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+ HIDE_UNDOC_CLASSES = NO
+
+ # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+ # friend (class|struct|union) declarations.
+ # If set to NO (the default) these declarations will be included in the
+ # documentation.
+
+ HIDE_FRIEND_COMPOUNDS = NO
+
+ # If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+ # documentation blocks found inside the body of a function.
+ # If set to NO (the default) these blocks will be appended to the
+ # function's detailed documentation block.
+
+ HIDE_IN_BODY_DOCS = NO
+
+ # The INTERNAL_DOCS tag determines if documentation
+ # that is typed after a \internal command is included. If the tag is set
+ # to NO (the default) then the documentation will be excluded.
+ # Set it to YES to include the internal documentation.
+
+ INTERNAL_DOCS = NO
+
+ # If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+ # file names in lower-case letters. If set to YES upper-case letters are also
+ # allowed. This is useful if you have classes or files whose names only differ
+ # in case and if your file system supports case sensitive file names. Windows
+ # and Mac users are advised to set this option to NO.
+
+ CASE_SENSE_NAMES = YES
+
+ # If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+ # will show members with their full class and namespace scopes in the
+ # documentation. If set to YES the scope will be hidden.
+
+ HIDE_SCOPE_NAMES = NO
+
+ # If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+ # will put a list of the files that are included by a file in the documentation
+ # of that file.
+
+ SHOW_INCLUDE_FILES = YES
+
+ # If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+ # is inserted in the documentation for inline members.
+
+ INLINE_INFO = YES
+
+ # If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+ # will sort the (detailed) documentation of file and class members
+ # alphabetically by member name. If set to NO the members will appear in
+ # declaration order.
+
+ SORT_MEMBER_DOCS = YES
+
+ # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+ # brief documentation of file, namespace and class members alphabetically
+ # by member name. If set to NO (the default) the members will appear in
+ # declaration order.
+
+ SORT_BRIEF_DOCS = NO
+
+ # If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
+ # hierarchy of group names into alphabetical order. If set to NO (the default)
+ # the group names will appear in their defined order.
+
+ SORT_GROUP_NAMES = NO
+
+ # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+ # sorted by fully-qualified names, including namespaces. If set to
+ # NO (the default), the class list will be sorted only by class name,
+ # not including the namespace part.
+ # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+ # Note: This option applies only to the class list, not to the
+ # alphabetical list.
+
+ SORT_BY_SCOPE_NAME = NO
+
+ # The GENERATE_TODOLIST tag can be used to enable (YES) or
+ # disable (NO) the todo list. This list is created by putting \todo
+ # commands in the documentation.
+
+ GENERATE_TODOLIST = YES
+
+ # The GENERATE_TESTLIST tag can be used to enable (YES) or
+ # disable (NO) the test list. This list is created by putting \test
+ # commands in the documentation.
+
+ GENERATE_TESTLIST = YES
+
+ # The GENERATE_BUGLIST tag can be used to enable (YES) or
+ # disable (NO) the bug list. This list is created by putting \bug
+ # commands in the documentation.
+
+ GENERATE_BUGLIST = YES
+
+ # The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+ # disable (NO) the deprecated list. This list is created by putting
+ # \deprecated commands in the documentation.
+
+ GENERATE_DEPRECATEDLIST= YES
+
+ # The ENABLED_SECTIONS tag can be used to enable conditional
+ # documentation sections, marked by \if sectionname ... \endif.
+
+ ENABLED_SECTIONS =
+
+ # The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+ # the initial value of a variable or define consists of for it to appear in
+ # the documentation. If the initializer consists of more lines than specified
+ # here it will be hidden. Use a value of 0 to hide initializers completely.
+ # The appearance of the initializer of individual variables and defines in the
+ # documentation can be controlled using \showinitializer or \hideinitializer
+ # command in the documentation regardless of this setting.
+
+ MAX_INITIALIZER_LINES = 30
+
+ # Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+ # at the bottom of the documentation of classes and structs. If set to YES the
+ # list will mention the files that were used to generate the documentation.
+
+ SHOW_USED_FILES = YES
+
+ # If the sources in your project are distributed over multiple directories
+ # then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+ # in the documentation. The default is NO.
+
+ SHOW_DIRECTORIES = YES
+
+ # Set the SHOW_FILES tag to NO to disable the generation of the Files page.
+ # This will remove the Files entry from the Quick Index and from the
+ # Folder Tree View (if specified). The default is YES.
+
+ SHOW_FILES = YES
+
+ # Set the SHOW_NAMESPACES tag to NO to disable the generation of the
+ # Namespaces page. This will remove the Namespaces entry from the Quick Index
+ # and from the Folder Tree View (if specified). The default is YES.
+
+ SHOW_NAMESPACES = YES
+
+ # The FILE_VERSION_FILTER tag can be used to specify a program or script that
+ # doxygen should invoke to get the current version for each file (typically from
+ # the version control system). Doxygen will invoke the program by executing (via
+ # popen()) the command <command> <input-file>, where <command> is the value of
+ # the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file
+ # provided by doxygen. Whatever the program writes to standard output
+ # is used as the file version. See the manual for examples.
+
+ FILE_VERSION_FILTER =
+
+ #---------------------------------------------------------------------------
+ # configuration options related to warning and progress messages
+ #---------------------------------------------------------------------------
+
+ # The QUIET tag can be used to turn on/off the messages that are generated
+ # by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+ QUIET = NO
+
+ # The WARNINGS tag can be used to turn on/off the warning messages that are
+ # generated by doxygen. Possible values are YES and NO. If left blank
+ # NO is used.
+
+ WARNINGS = NO
+
+ # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+ # for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+ # automatically be disabled.
+
+ WARN_IF_UNDOCUMENTED = NO
+
+ # If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+ # potential errors in the documentation, such as not documenting some
+ # parameters in a documented function, or documenting parameters that
+ # don't exist or using markup commands wrongly.
+
+ WARN_IF_DOC_ERROR = YES
+
+ # This WARN_NO_PARAMDOC option can be abled to get warnings for
+ # functions that are documented, but have no documentation for their parameters
+ # or return value. If set to NO (the default) doxygen will only warn about
+ # wrong or incomplete parameter documentation, but not about the absence of
+ # documentation.
+
+ WARN_NO_PARAMDOC = NO
+
+ # The WARN_FORMAT tag determines the format of the warning messages that
+ # doxygen can produce. The string should contain the $file, $line, and $text
+ # tags, which will be replaced by the file and line number from which the
+ # warning originated and the warning text. Optionally the format may contain
+ # $version, which will be replaced by the version of the file (if it could
+ # be obtained via FILE_VERSION_FILTER)
+
+ WARN_FORMAT =
+
+ # The WARN_LOGFILE tag can be used to specify a file to which warning
+ # and error messages should be written. If left blank the output is written
+ # to stderr.
+
+ WARN_LOGFILE =
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the input files
+ #---------------------------------------------------------------------------
+
+ # The INPUT tag can be used to specify the files and/or directories that contain
+ # documented source files. You may enter file names like "myfile.cpp" or
+ # directories like "/usr/src/myproject". Separate the files or directories
+ # with spaces.
+
+ INPUT = @abs_top_srcdir@/include \
+ @abs_top_srcdir@/lib \
+ @abs_top_srcdir@/docs/doxygen.intro
+
+ # This tag can be used to specify the character encoding of the source files
+ # that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
+ # also the default input encoding. Doxygen uses libiconv (or the iconv built
+ # into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
+ # the list of possible encodings.
+
+ INPUT_ENCODING = UTF-8
+
+ # If the value of the INPUT tag contains directories, you can use the
+ # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+ # and *.h) to filter out the source-files in the directories. If left
+ # blank the following patterns are tested:
+ # *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+ # *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
+
+ FILE_PATTERNS =
+
+ # The RECURSIVE tag can be used to turn specify whether or not subdirectories
+ # should be searched for input files as well. Possible values are YES and NO.
+ # If left blank NO is used.
+
+ RECURSIVE = YES
+
+ # The EXCLUDE tag can be used to specify files and/or directories that should
+ # excluded from the INPUT source files. This way you can easily exclude a
+ # subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+ EXCLUDE =
+
+ # The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+ # directories that are symbolic links (a Unix filesystem feature) are excluded
+ # from the input.
+
+ EXCLUDE_SYMLINKS = NO
+
+ # If the value of the INPUT tag contains directories, you can use the
+ # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+ # certain files from those directories. Note that the wildcards are matched
+ # against the file with absolute path, so to exclude all test directories
+ # for example use the pattern */test/*
+
+ EXCLUDE_PATTERNS =
+
+ # The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+ # (namespaces, classes, functions, etc.) that should be excluded from the
+ # output. The symbol name can be a fully qualified name, a word, or if the
+ # wildcard * is used, a substring. Examples: ANamespace, AClass,
+ # AClass::ANamespace, ANamespace::*Test
+
+ EXCLUDE_SYMBOLS =
+
+ # The EXAMPLE_PATH tag can be used to specify one or more files or
+ # directories that contain example code fragments that are included (see
+ # the \include command).
+
+ EXAMPLE_PATH = @abs_top_srcdir@/examples
+
+ # If the value of the EXAMPLE_PATH tag contains directories, you can use the
+ # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+ # and *.h) to filter out the source-files in the directories. If left
+ # blank all files are included.
+
+ EXAMPLE_PATTERNS =
+
+ # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+ # searched for input files to be used with the \include or \dontinclude
+ # commands irrespective of the value of the RECURSIVE tag.
+ # Possible values are YES and NO. If left blank NO is used.
+
+ EXAMPLE_RECURSIVE = YES
+
+ # The IMAGE_PATH tag can be used to specify one or more files or
+ # directories that contain image that are included in the documentation (see
+ # the \image command).
+
+ IMAGE_PATH = @abs_top_srcdir@/docs/img
+
+ # The INPUT_FILTER tag can be used to specify a program that doxygen should
+ # invoke to filter for each input file. Doxygen will invoke the filter program
+ # by executing (via popen()) the command <filter> <input-file>, where <filter>
+ # is the value of the INPUT_FILTER tag, and <input-file> is the name of an
+ # input file. Doxygen will then use the output that the filter program writes
+ # to standard output. If FILTER_PATTERNS is specified, this tag will be
+ # ignored.
+
+ INPUT_FILTER =
+
+ # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+ # basis. Doxygen will compare the file name with each pattern and apply the
+ # filter if there is a match. The filters are a list of the form:
+ # pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+ # info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+ # is applied to all files.
+
+ FILTER_PATTERNS =
+
+ # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+ # INPUT_FILTER) will be used to filter the input files when producing source
+ # files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+ FILTER_SOURCE_FILES = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to source browsing
+ #---------------------------------------------------------------------------
+
+ # If the SOURCE_BROWSER tag is set to YES then a list of source files will
+ # be generated. Documented entities will be cross-referenced with these sources.
+ # Note: To get rid of all source code in the generated output, make sure also
+ # VERBATIM_HEADERS is set to NO.
+
+ SOURCE_BROWSER = YES
+
+ # Setting the INLINE_SOURCES tag to YES will include the body
+ # of functions and classes directly in the documentation.
+
+ INLINE_SOURCES = NO
+
+ # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+ # doxygen to hide any special comment blocks from generated source code
+ # fragments. Normal C and C++ comments will always remain visible.
+
+ STRIP_CODE_COMMENTS = NO
+
+ # If the REFERENCED_BY_RELATION tag is set to YES
+ # then for each documented function all documented
+ # functions referencing it will be listed.
+
+ REFERENCED_BY_RELATION = YES
+
+ # If the REFERENCES_RELATION tag is set to YES
+ # then for each documented function all documented entities
+ # called/used by that function will be listed.
+
+ REFERENCES_RELATION = YES
+
+ # If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
+ # and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
+ # functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
+ # link to the source code. Otherwise they will link to the documentstion.
+
+ REFERENCES_LINK_SOURCE = YES
+
+ # If the USE_HTAGS tag is set to YES then the references to source code
+ # will point to the HTML generated by the htags(1) tool instead of doxygen
+ # built-in source browser. The htags tool is part of GNU's global source
+ # tagging system (see http://www.gnu.org/software/global/global.html). You
+ # will need version 4.8.6 or higher.
+
+ USE_HTAGS = NO
+
+ # If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+ # will generate a verbatim copy of the header file for each class for
+ # which an include is specified. Set to NO to disable this.
+
+ VERBATIM_HEADERS = YES
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the alphabetical class index
+ #---------------------------------------------------------------------------
+
+ # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+ # of all compounds will be generated. Enable this if the project
+ # contains a lot of classes, structs, unions or interfaces.
+
+ ALPHABETICAL_INDEX = YES
+
+ # If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+ # the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+ # in which this list will be split (can be a number in the range [1..20])
+
+ COLS_IN_ALPHA_INDEX = 4
+
+ # In case all classes in a project start with a common prefix, all
+ # classes will be put under the same header in the alphabetical index.
+ # The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+ # should be ignored while generating the index headers.
+
+ IGNORE_PREFIX = llvm::
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the HTML output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+ # generate HTML output.
+
+ GENERATE_HTML = YES
+
+ # The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `html' will be used as the default path.
+
+ HTML_OUTPUT = html
+
+ # The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+ # each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+ # doxygen will generate files with .html extension.
+
+ HTML_FILE_EXTENSION = .html
+
+ # The HTML_HEADER tag can be used to specify a personal HTML header for
+ # each generated HTML page. If it is left blank doxygen will generate a
+ # standard header.
+
+ HTML_HEADER = @abs_top_srcdir@/docs/doxygen.header
+
+ # The HTML_FOOTER tag can be used to specify a personal HTML footer for
+ # each generated HTML page. If it is left blank doxygen will generate a
+ # standard footer.
+
+ HTML_FOOTER = @abs_top_srcdir@/docs/doxygen.footer
+
+ # The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+ # style sheet that is used by each HTML page. It can be used to
+ # fine-tune the look of the HTML output. If the tag is left blank doxygen
+ # will generate a default style sheet. Note that doxygen will try to copy
+ # the style sheet file to the HTML output directory, so don't put your own
+ # stylesheet in the HTML output directory as well, or it will be erased!
+
+ HTML_STYLESHEET = @abs_top_srcdir@/docs/doxygen.css
+
+ # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+ # files or namespaces will be aligned in HTML using tables. If set to
+ # NO a bullet list will be used.
+
+ HTML_ALIGN_MEMBERS = YES
+
+ # If the GENERATE_HTMLHELP tag is set to YES, additional index files
+ # will be generated that can be used as input for tools like the
+ # Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
+ # of the generated HTML documentation.
+
+ GENERATE_HTMLHELP = NO
+
+ # If the GENERATE_DOCSET tag is set to YES, additional index files
+ # will be generated that can be used as input for Apple's Xcode 3
+ # integrated development environment, introduced with OSX 10.5 (Leopard).
+ # To create a documentation set, doxygen will generate a Makefile in the
+ # HTML output directory. Running make will produce the docset in that
+ # directory and running "make install" will install the docset in
+ # ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
+ # it at startup.
+
+ GENERATE_DOCSET = NO
+
+ # When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
+ # feed. A documentation feed provides an umbrella under which multiple
+ # documentation sets from a single provider (such as a company or product suite)
+ # can be grouped.
+
+ DOCSET_FEEDNAME = "Doxygen generated docs"
+
+ # When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
+ # should uniquely identify the documentation set bundle. This should be a
+ # reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
+ # will append .docset to the name.
+
+ DOCSET_BUNDLE_ID = org.doxygen.Project
+
+ # If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+ # documentation will contain sections that can be hidden and shown after the
+ # page has loaded. For this to work a browser that supports
+ # JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
+ # Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
+
+ HTML_DYNAMIC_SECTIONS = NO
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+ # be used to specify the file name of the resulting .chm file. You
+ # can add a path in front of the file if the result should not be
+ # written to the html output directory.
+
+ CHM_FILE =
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+ # be used to specify the location (absolute path including file name) of
+ # the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+ # the HTML help compiler on the generated index.hhp.
+
+ HHC_LOCATION =
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+ # controls if a separate .chi index file is generated (YES) or that
+ # it should be included in the master .chm file (NO).
+
+ GENERATE_CHI = NO
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
+ # is used to encode HtmlHelp index (hhk), content (hhc) and project file
+ # content.
+
+ CHM_INDEX_ENCODING =
+
+ # If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+ # controls whether a binary table of contents is generated (YES) or a
+ # normal table of contents (NO) in the .chm file.
+
+ BINARY_TOC = NO
+
+ # The TOC_EXPAND flag can be set to YES to add extra items for group members
+ # to the contents of the HTML help documentation and to the tree view.
+
+ TOC_EXPAND = NO
+
+ # The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+ # top of each HTML page. The value NO (the default) enables the index and
+ # the value YES disables it.
+
+ DISABLE_INDEX = NO
+
+ # This tag can be used to set the number of enum values (range [1..20])
+ # that doxygen will group on one line in the generated HTML documentation.
+
+ ENUM_VALUES_PER_LINE = 4
+
+ # The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+ # structure should be generated to display hierarchical information.
+ # If the tag value is set to FRAME, a side panel will be generated
+ # containing a tree-like index structure (just like the one that
+ # is generated for HTML Help). For this to work a browser that supports
+ # JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+,
+ # Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are
+ # probably better off using the HTML help feature. Other possible values
+ # for this tag are: HIERARCHIES, which will generate the Groups, Directories,
+ # and Class Hiererachy pages using a tree view instead of an ordered list;
+ # ALL, which combines the behavior of FRAME and HIERARCHIES; and NONE, which
+ # disables this behavior completely. For backwards compatibility with previous
+ # releases of Doxygen, the values YES and NO are equivalent to FRAME and NONE
+ # respectively.
+
+ GENERATE_TREEVIEW = NO
+
+ # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+ # used to set the initial width (in pixels) of the frame in which the tree
+ # is shown.
+
+ TREEVIEW_WIDTH = 250
+
+ # Use this tag to change the font size of Latex formulas included
+ # as images in the HTML documentation. The default is 10. Note that
+ # when you change the font size after a successful doxygen run you need
+ # to manually remove any form_*.png images from the HTML output directory
+ # to force them to be regenerated.
+
+ FORMULA_FONTSIZE = 10
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the LaTeX output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+ # generate Latex output.
+
+ GENERATE_LATEX = NO
+
+ # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `latex' will be used as the default path.
+
+ LATEX_OUTPUT =
+
+ # The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+ # invoked. If left blank `latex' will be used as the default command name.
+
+ LATEX_CMD_NAME = latex
+
+ # The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+ # generate index for LaTeX. If left blank `makeindex' will be used as the
+ # default command name.
+
+ MAKEINDEX_CMD_NAME = makeindex
+
+ # If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+ # LaTeX documents. This may be useful for small projects and may help to
+ # save some trees in general.
+
+ COMPACT_LATEX = NO
+
+ # The PAPER_TYPE tag can be used to set the paper type that is used
+ # by the printer. Possible values are: a4, a4wide, letter, legal and
+ # executive. If left blank a4wide will be used.
+
+ PAPER_TYPE = letter
+
+ # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+ # packages that should be included in the LaTeX output.
+
+ EXTRA_PACKAGES =
+
+ # The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+ # the generated latex document. The header should contain everything until
+ # the first chapter. If it is left blank doxygen will generate a
+ # standard header. Notice: only use this tag if you know what you are doing!
+
+ LATEX_HEADER =
+
+ # If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+ # is prepared for conversion to pdf (using ps2pdf). The pdf file will
+ # contain links (just like the HTML output) instead of page references
+ # This makes the output suitable for online browsing using a pdf viewer.
+
+ PDF_HYPERLINKS = NO
+
+ # If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+ # plain latex in the generated Makefile. Set this option to YES to get a
+ # higher quality PDF documentation.
+
+ USE_PDFLATEX = NO
+
+ # If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+ # command to the generated LaTeX files. This will instruct LaTeX to keep
+ # running if errors occur, instead of asking the user for help.
+ # This option is also used when generating formulas in HTML.
+
+ LATEX_BATCHMODE = NO
+
+ # If LATEX_HIDE_INDICES is set to YES then doxygen will not
+ # include the index chapters (such as File Index, Compound Index, etc.)
+ # in the output.
+
+ LATEX_HIDE_INDICES = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the RTF output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+ # The RTF output is optimized for Word 97 and may not look very pretty with
+ # other RTF readers or editors.
+
+ GENERATE_RTF = NO
+
+ # The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `rtf' will be used as the default path.
+
+ RTF_OUTPUT =
+
+ # If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+ # RTF documents. This may be useful for small projects and may help to
+ # save some trees in general.
+
+ COMPACT_RTF = NO
+
+ # If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+ # will contain hyperlink fields. The RTF file will
+ # contain links (just like the HTML output) instead of page references.
+ # This makes the output suitable for online browsing using WORD or other
+ # programs which support those fields.
+ # Note: wordpad (write) and others do not support links.
+
+ RTF_HYPERLINKS = NO
+
+ # Load stylesheet definitions from file. Syntax is similar to doxygen's
+ # config file, i.e. a series of assignments. You only have to provide
+ # replacements, missing definitions are set to their default value.
+
+ RTF_STYLESHEET_FILE =
+
+ # Set optional variables used in the generation of an rtf document.
+ # Syntax is similar to doxygen's config file.
+
+ RTF_EXTENSIONS_FILE =
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the man page output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+ # generate man pages
+
+ GENERATE_MAN = NO
+
+ # The MAN_OUTPUT tag is used to specify where the man pages will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `man' will be used as the default path.
+
+ MAN_OUTPUT =
+
+ # The MAN_EXTENSION tag determines the extension that is added to
+ # the generated man pages (default is the subroutine's section .3)
+
+ MAN_EXTENSION =
+
+ # If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+ # then it will generate one additional man file for each entity
+ # documented in the real man page(s). These additional files
+ # only source the real man page, but without them the man command
+ # would be unable to find the correct page. The default is NO.
+
+ MAN_LINKS = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the XML output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_XML tag is set to YES Doxygen will
+ # generate an XML file that captures the structure of
+ # the code including all documentation.
+
+ GENERATE_XML = NO
+
+ # The XML_OUTPUT tag is used to specify where the XML pages will be put.
+ # If a relative path is entered the value of OUTPUT_DIRECTORY will be
+ # put in front of it. If left blank `xml' will be used as the default path.
+
+ XML_OUTPUT = xml
+
+ # The XML_SCHEMA tag can be used to specify an XML schema,
+ # which can be used by a validating XML parser to check the
+ # syntax of the XML files.
+
+ XML_SCHEMA =
+
+ # The XML_DTD tag can be used to specify an XML DTD,
+ # which can be used by a validating XML parser to check the
+ # syntax of the XML files.
+
+ XML_DTD =
+
+ # If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+ # dump the program listings (including syntax highlighting
+ # and cross-referencing information) to the XML output. Note that
+ # enabling this will significantly increase the size of the XML output.
+
+ XML_PROGRAMLISTING = YES
+
+ #---------------------------------------------------------------------------
+ # configuration options for the AutoGen Definitions output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+ # generate an AutoGen Definitions (see autogen.sf.net) file
+ # that captures the structure of the code including all
+ # documentation. Note that this feature is still experimental
+ # and incomplete at the moment.
+
+ GENERATE_AUTOGEN_DEF = NO
+
+ #---------------------------------------------------------------------------
+ # configuration options related to the Perl module output
+ #---------------------------------------------------------------------------
+
+ # If the GENERATE_PERLMOD tag is set to YES Doxygen will
+ # generate a Perl module file that captures the structure of
+ # the code including all documentation. Note that this
+ # feature is still experimental and incomplete at the
+ # moment.
+
+ GENERATE_PERLMOD = NO
+
+ # If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+ # the necessary Makefile rules, Perl scripts and LaTeX code to be able
+ # to generate PDF and DVI output from the Perl module output.
+
+ PERLMOD_LATEX = NO
+
+ # If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+ # nicely formatted so it can be parsed by a human reader. This is useful
+ # if you want to understand what is going on. On the other hand, if this
+ # tag is set to NO the size of the Perl module output will be much smaller
+ # and Perl will parse it just the same.
+
+ PERLMOD_PRETTY = YES
+
+ # The names of the make variables in the generated doxyrules.make file
+ # are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+ # This is useful so different doxyrules.make files included by the same
+ # Makefile don't overwrite each other's variables.
+
+ PERLMOD_MAKEVAR_PREFIX =
+
+ #---------------------------------------------------------------------------
+ # Configuration options related to the preprocessor
+ #---------------------------------------------------------------------------
+
+ # If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+ # evaluate all C-preprocessor directives found in the sources and include
+ # files.
+
+ ENABLE_PREPROCESSING = YES
+
+ # If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+ # names in the source code. If set to NO (the default) only conditional
+ # compilation will be performed. Macro expansion can be done in a controlled
+ # way by setting EXPAND_ONLY_PREDEF to YES.
+
+ MACRO_EXPANSION = NO
+
+ # If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+ # then the macro expansion is limited to the macros specified with the
+ # PREDEFINED and EXPAND_AS_DEFINED tags.
+
+ EXPAND_ONLY_PREDEF = NO
+
+ # If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+ # in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+ SEARCH_INCLUDES = YES
+
+ # The INCLUDE_PATH tag can be used to specify one or more directories that
+ # contain include files that are not input files but should be processed by
+ # the preprocessor.
+
+ INCLUDE_PATH = ../include
+
+ # You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+ # patterns (like *.h and *.hpp) to filter out the header-files in the
+ # directories. If left blank, the patterns specified with FILE_PATTERNS will
+ # be used.
+
+ INCLUDE_FILE_PATTERNS =
+
+ # The PREDEFINED tag can be used to specify one or more macro names that
+ # are defined before the preprocessor is started (similar to the -D option of
+ # gcc). The argument of the tag is a list of macros of the form: name
+ # or name=definition (no spaces). If the definition and the = are
+ # omitted =1 is assumed. To prevent a macro definition from being
+ # undefined via #undef or recursively expanded use the := operator
+ # instead of the = operator.
+
+ PREDEFINED =
+
+ # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+ # this tag can be used to specify a list of macro names that should be expanded.
+ # The macro definition that is found in the sources will be used.
+ # Use the PREDEFINED tag if you want to use a different macro definition.
+
+ EXPAND_AS_DEFINED =
+
+ # If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+ # doxygen's preprocessor will remove all function-like macros that are alone
+ # on a line, have an all uppercase name, and do not end with a semicolon. Such
+ # function macros are typically used for boiler-plate code, and will confuse
+ # the parser if not removed.
+
+ SKIP_FUNCTION_MACROS = YES
+
+ #---------------------------------------------------------------------------
+ # Configuration::additions related to external references
+ #---------------------------------------------------------------------------
+
+ # The TAGFILES option can be used to specify one or more tagfiles.
+ # Optionally an initial location of the external documentation
+ # can be added for each tagfile. The format of a tag file without
+ # this location is as follows:
+ # TAGFILES = file1 file2 ...
+ # Adding location for the tag files is done as follows:
+ # TAGFILES = file1=loc1 "file2 = loc2" ...
+ # where "loc1" and "loc2" can be relative or absolute paths or
+ # URLs. If a location is present for each tag, the installdox tool
+ # does not have to be run to correct the links.
+ # Note that each tag file must have a unique name
+ # (where the name does NOT include the path)
+ # If a tag file is not located in the directory in which doxygen
+ # is run, you must also specify the path to the tagfile here.
+
+ TAGFILES =
+
+ # When a file name is specified after GENERATE_TAGFILE, doxygen will create
+ # a tag file that is based on the input files it reads.
+
+ GENERATE_TAGFILE =
+
+ # If the ALLEXTERNALS tag is set to YES all external classes will be listed
+ # in the class index. If set to NO only the inherited external classes
+ # will be listed.
+
+ ALLEXTERNALS = YES
+
+ # If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+ # in the modules index. If set to NO, only the current project's groups will
+ # be listed.
+
+ EXTERNAL_GROUPS = YES
+
+ # The PERL_PATH should be the absolute path and name of the perl script
+ # interpreter (i.e. the result of `which perl').
+
+ PERL_PATH =
+
+ #---------------------------------------------------------------------------
+ # Configuration options related to the dot tool
+ #---------------------------------------------------------------------------
+
+ # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+ # generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+ # or super classes. Setting the tag to NO turns the diagrams off. Note that
+ # this option is superseded by the HAVE_DOT option below. This is only a
+ # fallback. It is recommended to install and use dot, since it yields more
+ # powerful graphs.
+
+ CLASS_DIAGRAMS = YES
+
+ # You can define message sequence charts within doxygen comments using the \msc
+ # command. Doxygen will then run the mscgen tool (see
+ # http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
+ # documentation. The MSCGEN_PATH tag allows you to specify the directory where
+ # the mscgen tool resides. If left empty the tool is assumed to be found in the
+ # default search path.
+
+ MSCGEN_PATH =
+
+ # If set to YES, the inheritance and collaboration graphs will hide
+ # inheritance and usage relations if the target is undocumented
+ # or is not a class.
+
+ HIDE_UNDOC_RELATIONS = NO
+
+ # If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+ # available from the path. This tool is part of Graphviz, a graph visualization
+ # toolkit from AT&T and Lucent Bell Labs. The other options in this section
+ # have no effect if this option is set to NO (the default)
+
+ HAVE_DOT = YES
+
+ # By default doxygen will write a font called FreeSans.ttf to the output
+ # directory and reference it in all dot files that doxygen generates. This
+ # font does not include all possible unicode characters however, so when you need
+ # these (or just want a differently looking font) you can specify the font name
+ # using DOT_FONTNAME. You need need to make sure dot is able to find the font,
+ # which can be done by putting it in a standard location or by setting the
+ # DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory
+ # containing the font.
+
+ DOT_FONTNAME = FreeSans
+
+ # By default doxygen will tell dot to use the output directory to look for the
+ # FreeSans.ttf font (which doxygen will put there itself). If you specify a
+ # different font using DOT_FONTNAME you can set the path where dot
+ # can find it using this tag.
+
+ DOT_FONTPATH =
+
+ # If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+ # will generate a graph for each documented class showing the direct and
+ # indirect inheritance relations. Setting this tag to YES will force the
+ # the CLASS_DIAGRAMS tag to NO.
+
+ CLASS_GRAPH = YES
+
+ # If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+ # will generate a graph for each documented class showing the direct and
+ # indirect implementation dependencies (inheritance, containment, and
+ # class references variables) of the class with other documented classes.
+
+ COLLABORATION_GRAPH = YES
+
+ # If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+ # will generate a graph for groups, showing the direct groups dependencies
+
+ GROUP_GRAPHS = YES
+
+ # If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+ # collaboration diagrams in a style similar to the OMG's Unified Modeling
+ # Language.
+
+ UML_LOOK = NO
+
+ # If set to YES, the inheritance and collaboration graphs will show the
+ # relations between templates and their instances.
+
+ TEMPLATE_RELATIONS = YES
+
+ # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+ # tags are set to YES then doxygen will generate a graph for each documented
+ # file showing the direct and indirect include dependencies of the file with
+ # other documented files.
+
+ INCLUDE_GRAPH = YES
+
+ # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+ # HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+ # documented header file showing the documented files that directly or
+ # indirectly include this file.
+
+ INCLUDED_BY_GRAPH = YES
+
+ # If the CALL_GRAPH and HAVE_DOT options are set to YES then
+ # doxygen will generate a call dependency graph for every global function
+ # or class method. Note that enabling this option will significantly increase
+ # the time of a run. So in most cases it will be better to enable call graphs
+ # for selected functions only using the \callgraph command.
+
+ CALL_GRAPH = NO
+
+ # If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
+ # doxygen will generate a caller dependency graph for every global function
+ # or class method. Note that enabling this option will significantly increase
+ # the time of a run. So in most cases it will be better to enable caller
+ # graphs for selected functions only using the \callergraph command.
+
+ CALLER_GRAPH = NO
+
+ # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+ # will graphical hierarchy of all classes instead of a textual one.
+
+ GRAPHICAL_HIERARCHY = YES
+
+ # If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+ # then doxygen will show the dependencies a directory has on other directories
+ # in a graphical way. The dependency relations are determined by the #include
+ # relations between the files in the directories.
+
+ DIRECTORY_GRAPH = YES
+
+ # The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+ # generated by dot. Possible values are png, jpg, or gif
+ # If left blank png will be used.
+
+ DOT_IMAGE_FORMAT = png
+
+ # The tag DOT_PATH can be used to specify the path where the dot tool can be
+ # found. If left blank, it is assumed the dot tool can be found in the path.
+
+ DOT_PATH = @DOT@
+
+ # The DOTFILE_DIRS tag can be used to specify one or more directories that
+ # contain dot files that are included in the documentation (see the
+ # \dotfile command).
+
+ DOTFILE_DIRS =
+
+ # The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
+ # nodes that will be shown in the graph. If the number of nodes in a graph
+ # becomes larger than this value, doxygen will truncate the graph, which is
+ # visualized by representing a node as a red box. Note that doxygen if the
+ # number of direct children of the root node in a graph is already larger than
+ # DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
+ # that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+
+ DOT_GRAPH_MAX_NODES = 50
+
+ # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+ # graphs generated by dot. A depth value of 3 means that only nodes reachable
+ # from the root by following a path via at most 3 edges will be shown. Nodes
+ # that lay further from the root node will be omitted. Note that setting this
+ # option to 1 or 2 may greatly reduce the computation time needed for large
+ # code bases. Also note that the size of a graph can be further restricted by
+ # DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+
+ MAX_DOT_GRAPH_DEPTH = 0
+
+ # Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+ # background. This is enabled by default, which results in a transparent
+ # background. Warning: Depending on the platform used, enabling this option
+ # may lead to badly anti-aliased labels on the edges of a graph (i.e. they
+ # become hard to read).
+
+ DOT_TRANSPARENT = YES
+
+ # Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+ # files in one run (i.e. multiple -o and -T options on the command line). This
+ # makes dot run faster, but since only newer versions of dot (>1.8.10)
+ # support this, this feature is disabled by default.
+
+ DOT_MULTI_TARGETS = NO
+
+ # If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+ # generate a legend page explaining the meaning of the various boxes and
+ # arrows in the dot generated graphs.
+
+ GENERATE_LEGEND = YES
+
+ # If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+ # remove the intermediate dot files that are used to generate
+ # the various graphs.
+
+ DOT_CLEANUP = YES
+
+ #---------------------------------------------------------------------------
+ # Configuration::additions related to the search engine
+ #---------------------------------------------------------------------------
+
+ # The SEARCHENGINE tag specifies whether or not a search engine should be
+ # used. If set to NO the values of all tags below this one will be ignored.
+
+ SEARCHENGINE = NO
Index: llvm-www/releases/2.5/docs/doxygen.css
diff -c /dev/null llvm-www/releases/2.5/docs/doxygen.css:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/doxygen.css Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,378 ----
+ BODY,H1,H2,H3,H4,H5,H6,P,CENTER,TD,TH,UL,DL,DIV {
+ font-family: Verdana,Geneva,Arial,Helvetica,sans-serif;
+ }
+ BODY,TD {
+ font-size: 90%;
+ }
+ H1 {
+ text-align: center;
+ font-size: 140%;
+ font-weight: bold;
+ }
+ H2 {
+ font-size: 120%;
+ font-style: italic;
+ }
+ H3 {
+ font-size: 100%;
+ }
+ CAPTION { font-weight: bold }
+ DIV.qindex {
+ width: 100%;
+ background-color: #eeeeff;
+ border: 1px solid #b0b0b0;
+ text-align: center;
+ margin: 2px;
+ padding: 2px;
+ line-height: 140%;
+ }
+ DIV.nav {
+ width: 100%;
+ background-color: #eeeeff;
+ border: 1px solid #b0b0b0;
+ text-align: center;
+ margin: 2px;
+ padding: 2px;
+ line-height: 140%;
+ }
+ DIV.navtab {
+ background-color: #eeeeff;
+ border: 1px solid #b0b0b0;
+ text-align: center;
+ margin: 2px;
+ margin-right: 15px;
+ padding: 2px;
+ }
+ TD.navtab {
+ font-size: 70%;
+ }
+ A.qindex {
+ text-decoration: none;
+ font-weight: bold;
+ color: #1A419D;
+ }
+ A.qindex:visited {
+ text-decoration: none;
+ font-weight: bold;
+ color: #1A419D
+ }
+ A.qindex:hover {
+ text-decoration: none;
+ background-color: #ddddff;
+ }
+ A.qindexHL {
+ text-decoration: none;
+ font-weight: bold;
+ background-color: #6666cc;
+ color: #ffffff;
+ border: 1px double #9295C2;
+ }
+ A.qindexHL:hover {
+ text-decoration: none;
+ background-color: #6666cc;
+ color: #ffffff;
+ }
+ A.qindexHL:visited {
+ text-decoration: none; background-color: #6666cc; color: #ffffff }
+ A.el { text-decoration: none; font-weight: bold }
+ A.elRef { font-weight: bold }
+ A.code:link { text-decoration: none; font-weight: normal; color: #0000FF}
+ A.code:visited { text-decoration: none; font-weight: normal; color: #0000FF}
+ A.codeRef:link { font-weight: normal; color: #0000FF}
+ A.codeRef:visited { font-weight: normal; color: #0000FF}
+ A:hover { text-decoration: none; background-color: #f2f2ff }
+ DL.el { margin-left: -1cm }
+ .fragment {
+ font-family: Fixed, monospace;
+ font-size: 95%;
+ }
+ PRE.fragment {
+ border: 1px solid #CCCCCC;
+ background-color: #f5f5f5;
+ margin-top: 4px;
+ margin-bottom: 4px;
+ margin-left: 2px;
+ margin-right: 8px;
+ padding-left: 6px;
+ padding-right: 6px;
+ padding-top: 4px;
+ padding-bottom: 4px;
+ }
+ DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px }
+ TD.md { background-color: #F4F4FB; font-weight: bold; }
+ TD.mdPrefix {
+ background-color: #F4F4FB;
+ color: #606060;
+ font-size: 80%;
+ }
+ TD.mdname1 { background-color: #F4F4FB; font-weight: bold; color: #602020; }
+ TD.mdname { background-color: #F4F4FB; font-weight: bold; color: #602020; width: 600px; }
+ DIV.groupHeader {
+ margin-left: 16px;
+ margin-top: 12px;
+ margin-bottom: 6px;
+ font-weight: bold;
+ }
+ DIV.groupText { margin-left: 16px; font-style: italic; font-size: 90% }
+ BODY {
+ background: white;
+ color: black;
+ margin-right: 20px;
+ margin-left: 20px;
+ }
+ TD.indexkey {
+ background-color: #eeeeff;
+ font-weight: bold;
+ padding-right : 10px;
+ padding-top : 2px;
+ padding-left : 10px;
+ padding-bottom : 2px;
+ margin-left : 0px;
+ margin-right : 0px;
+ margin-top : 2px;
+ margin-bottom : 2px;
+ border: 1px solid #CCCCCC;
+ }
+ TD.indexvalue {
+ background-color: #eeeeff;
+ font-style: italic;
+ padding-right : 10px;
+ padding-top : 2px;
+ padding-left : 10px;
+ padding-bottom : 2px;
+ margin-left : 0px;
+ margin-right : 0px;
+ margin-top : 2px;
+ margin-bottom : 2px;
+ border: 1px solid #CCCCCC;
+ }
+ TR.memlist {
+ background-color: #f0f0f0;
+ }
+ P.formulaDsp { text-align: center; }
+ IMG.formulaDsp { }
+ IMG.formulaInl { vertical-align: middle; }
+ SPAN.keyword { color: #008000 }
+ SPAN.keywordtype { color: #604020 }
+ SPAN.keywordflow { color: #e08000 }
+ SPAN.comment { color: #800000 }
+ SPAN.preprocessor { color: #806020 }
+ SPAN.stringliteral { color: #002080 }
+ SPAN.charliteral { color: #008080 }
+ .mdTable {
+ border: 1px solid #868686;
+ background-color: #F4F4FB;
+ }
+ .mdRow {
+ padding: 8px 10px;
+ }
+ .mdescLeft {
+ padding: 0px 8px 4px 8px;
+ font-size: 80%;
+ font-style: italic;
+ background-color: #FAFAFA;
+ border-top: 1px none #E0E0E0;
+ border-right: 1px none #E0E0E0;
+ border-bottom: 1px none #E0E0E0;
+ border-left: 1px none #E0E0E0;
+ margin: 0px;
+ }
+ .mdescRight {
+ padding: 0px 8px 4px 8px;
+ font-size: 80%;
+ font-style: italic;
+ background-color: #FAFAFA;
+ border-top: 1px none #E0E0E0;
+ border-right: 1px none #E0E0E0;
+ border-bottom: 1px none #E0E0E0;
+ border-left: 1px none #E0E0E0;
+ margin: 0px;
+ }
+ .memItemLeft {
+ padding: 1px 0px 0px 8px;
+ margin: 4px;
+ border-top-width: 1px;
+ border-right-width: 1px;
+ border-bottom-width: 1px;
+ border-left-width: 1px;
+ border-top-color: #E0E0E0;
+ border-right-color: #E0E0E0;
+ border-bottom-color: #E0E0E0;
+ border-left-color: #E0E0E0;
+ border-top-style: solid;
+ border-right-style: none;
+ border-bottom-style: none;
+ border-left-style: none;
+ background-color: #FAFAFA;
+ font-size: 80%;
+ }
+ .memItemRight {
+ padding: 1px 8px 0px 8px;
+ margin: 4px;
+ border-top-width: 1px;
+ border-right-width: 1px;
+ border-bottom-width: 1px;
+ border-left-width: 1px;
+ border-top-color: #E0E0E0;
+ border-right-color: #E0E0E0;
+ border-bottom-color: #E0E0E0;
+ border-left-color: #E0E0E0;
+ border-top-style: solid;
+ border-right-style: none;
+ border-bottom-style: none;
+ border-left-style: none;
+ background-color: #FAFAFA;
+ font-size: 80%;
+ }
+ .memTemplItemLeft {
+ padding: 1px 0px 0px 8px;
+ margin: 4px;
+ border-top-width: 1px;
+ border-right-width: 1px;
+ border-bottom-width: 1px;
+ border-left-width: 1px;
+ border-top-color: #E0E0E0;
+ border-right-color: #E0E0E0;
+ border-bottom-color: #E0E0E0;
+ border-left-color: #E0E0E0;
+ border-top-style: none;
+ border-right-style: none;
+ border-bottom-style: none;
+ border-left-style: none;
+ background-color: #FAFAFA;
+ font-size: 80%;
+ }
+ .memTemplItemRight {
+ padding: 1px 8px 0px 8px;
+ margin: 4px;
+ border-top-width: 1px;
+ border-right-width: 1px;
+ border-bottom-width: 1px;
+ border-left-width: 1px;
+ border-top-color: #E0E0E0;
+ border-right-color: #E0E0E0;
+ border-bottom-color: #E0E0E0;
+ border-left-color: #E0E0E0;
+ border-top-style: none;
+ border-right-style: none;
+ border-bottom-style: none;
+ border-left-style: none;
+ background-color: #FAFAFA;
+ font-size: 80%;
+ }
+ .memTemplParams {
+ padding: 1px 0px 0px 8px;
+ margin: 4px;
+ border-top-width: 1px;
+ border-right-width: 1px;
+ border-bottom-width: 1px;
+ border-left-width: 1px;
+ border-top-color: #E0E0E0;
+ border-right-color: #E0E0E0;
+ border-bottom-color: #E0E0E0;
+ border-left-color: #E0E0E0;
+ border-top-style: solid;
+ border-right-style: none;
+ border-bottom-style: none;
+ border-left-style: none;
+ color: #606060;
+ background-color: #FAFAFA;
+ font-size: 80%;
+ }
+ .search { color: #003399;
+ font-weight: bold;
+ }
+ FORM.search {
+ margin-bottom: 0px;
+ margin-top: 0px;
+ }
+ INPUT.search { font-size: 75%;
+ color: #000080;
+ font-weight: normal;
+ background-color: #eeeeff;
+ }
+ TD.tiny { font-size: 75%;
+ }
+ a {
+ color: #252E78;
+ }
+ a:visited {
+ color: #3D2185;
+ }
+ .dirtab { padding: 4px;
+ border-collapse: collapse;
+ border: 1px solid #b0b0b0;
+ }
+ TH.dirtab { background: #eeeeff;
+ font-weight: bold;
+ }
+ HR { height: 1px;
+ border: none;
+ border-top: 1px solid black;
+ }
+
+ /*
+ * LLVM Modifications.
+ * Note: Everything above here is generated with "doxygen -w htlm" command. See
+ * "doxygen --help" for details. What follows are CSS overrides for LLVM
+ * specific formatting. We want to keep the above so it can be replaced with
+ * subsequent doxygen upgrades.
+ */
+
+ .footer {
+ font-size: 80%;
+ font-weight: bold;
+ text-align: center;
+ vertical-align: middle;
+ }
+ .title {
+ font-size: 25pt;
+ color: black; background: url("../img/lines.gif");
+ font-weight: bold;
+ border-width: 1px;
+ border-style: solid none solid none;
+ text-align: center;
+ vertical-align: middle;
+ padding-left: 8pt;
+ padding-top: 1px;
+ padding-bottom: 2px
+ }
+ A:link {
+ cursor: pointer;
+ text-decoration: none;
+ font-weight: bolder;
+ }
+ A:visited {
+ cursor: pointer;
+ text-decoration: underline;
+ font-weight: bolder;
+ }
+ A:hover {
+ cursor: pointer;
+ text-decoration: underline;
+ font-weight: bolder;
+ }
+ A:active {
+ cursor: pointer;
+ text-decoration: underline;
+ font-weight: bolder;
+ font-style: italic;
+ }
+ H1 {
+ text-align: center;
+ font-size: 140%;
+ font-weight: bold;
+ }
+ H2 {
+ font-size: 120%;
+ font-style: italic;
+ }
+ H3 {
+ font-size: 100%;
+ }
+ A.qindex {}
+ A.qindexRef {}
+ A.el { text-decoration: none; font-weight: bold }
+ A.elRef { font-weight: bold }
+ A.code { text-decoration: none; font-weight: normal; color: #4444ee }
+ A.codeRef { font-weight: normal; color: #4444ee }
Index: llvm-www/releases/2.5/docs/doxygen.footer
diff -c /dev/null llvm-www/releases/2.5/docs/doxygen.footer:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/doxygen.footer Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,13 ----
+ <hr>
+ <p class="footer">
+ Generated on $datetime for <a href="http://llvm.org">$projectname</a> by
+ <a href="http://www.doxygen.org"><img src="doxygen.png" alt="Doxygen"
+ align="middle" border="0"/>$doxygenversion</a><br>
+ Copyright © 2003-2007 University of Illinois at Urbana-Champaign.
+ All Rights Reserved.</p>
+
+ <hr>
+ <!--#include virtual="/attrib.incl" -->
+
+ </body>
+ </html>
Index: llvm-www/releases/2.5/docs/doxygen.header
diff -c /dev/null llvm-www/releases/2.5/docs/doxygen.header:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/doxygen.header Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,9 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
+ <html><head>
+ <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"/>
+ <meta name="keywords" content="LLVM,Low Level Virtual Machine,C++,doxygen,API,documentation"/>
+ <meta name="description" content="C++ source code API documentation for the Low Level Virtual Machine (LLVM)."/>
+ <title>LLVM: $title</title>
+ <link href="doxygen.css" rel="stylesheet" type="text/css"/>
+ </head><body>
+ <p class="title">LLVM API Documentation</p>
Index: llvm-www/releases/2.5/docs/doxygen.intro
diff -c /dev/null llvm-www/releases/2.5/docs/doxygen.intro:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/doxygen.intro Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,18 ----
+ /// @mainpage Low Level Virtual Machine
+ ///
+ /// @section main_intro Introduction
+ /// Welcome to the Low Level Virtual Machine (LLVM).
+ ///
+ /// This documentation describes the @b internal software that makes
+ /// up LLVM, not the @b external use of LLVM. There are no instructions
+ /// here on how to use LLVM, only the APIs that make up the software. For usage
+ /// instructions, please see the programmer's guide or reference manual.
+ ///
+ /// @section main_caveat Caveat
+ /// This documentation is generated directly from the source code with doxygen.
+ /// Since LLVM is constantly under active development, what you're about to
+ /// read is out of date! However, it may still be useful since certain portions
+ /// of LLVM are very stable.
+ ///
+ /// @section main_changelog Change Log
+ /// - Original content written 12/30/2003 by Reid Spencer
Index: llvm-www/releases/2.5/docs/index.html
diff -c /dev/null llvm-www/releases/2.5/docs/index.html:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/index.html Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,282 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>Documentation for the LLVM System</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">Documentation for the LLVM System</div>
+
+ <div class="doc_text">
+ <table class="layout" width="95%"><tr class="layout"><td class="left">
+ <ul>
+ <li><a href="#llvmdesign">LLVM Design</a></li>
+ <li><a href="/pubs/">LLVM Publications</a></li>
+ <li><a href="#userguide">LLVM User Guides</a></li>
+ <li><a href="#llvmprog">General LLVM Programming Documentation</a></li>
+ <li><a href="#subsystems">LLVM Subsystem Documentation</a></li>
+ <li><a href="#maillist">LLVM Mailing Lists</a></li>
+ </ul>
+ </td><td class="right">
+ <form action="http://www.google.com/search" method=get>
+ <p>
+ <input type="hidden" name="sitesearch" value="llvm.org/docs">
+ <input type=text name=q size=25><br>
+ <input type=submit value="Search the LLVM Docs" name="submit">
+ </p>
+ </form>
+ </td></tr></table>
+ </div>
+
+ <div class="doc_author">
+ <p>Written by <a href="http://llvm.org">The LLVM Team</a></p>
+ </div>
+
+ <!--=======================================================================-->
+ <div class="doc_section"><a name="llvmdesign">LLVM Design & Overview</a></div>
+ <!--=======================================================================-->
+
+ <ul>
+ <li><a href="LangRef.html">LLVM Language Reference Manual</a> - Defines the LLVM
+ intermediate representation.</li>
+ <li><a href="http://llvm.org/pubs/2006-04-25-GelatoLLVMIntro.html">Introduction to the LLVM Compiler Infrastructure</a> - Presentation describing LLVM.</li>
+ <li><a href="http://llvm.org/pubs/2004-09-22-LCPCLLVMTutorial.html">The LLVM Compiler Framework and
+ Infrastructure Tutorial</a> - Tutorial for writing passes, exploring the system.</li>
+ <li><a href="http://llvm.org/pubs/2004-01-30-CGO-LLVM.html">LLVM: A Compilation Framework for
+ Lifelong Program Analysis & Transformation</a> - Design overview.</li>
+ <li><a href="http://llvm.org/pubs/2002-12-LattnerMSThesis.html">LLVM: An Infrastructure for
+ Multi-Stage Optimization</a> - More details (somewhat old now).</li>
+ <li><a href="GetElementPtr.html">GetElementPtr FAQ</a> - Answers to some very
+ frequent questions about LLVM's most frequently misunderstood instruction.</li>
+ </ul>
+
+ <!--=======================================================================-->
+ <div class="doc_section"><a name="userguide">LLVM User Guides</a></div>
+ <!--=======================================================================-->
+
+ <ul>
+ <li><a href="GettingStarted.html">The LLVM Getting Started Guide</a> -
+ Discusses how to get up and running quickly with the LLVM infrastructure.
+ Everything from unpacking and compilation of the distribution to execution of
+ some tools.</li>
+
+ <li><a href="GettingStartedVS.html">Getting Started with the LLVM System using
+ Microsoft Visual Studio</a> - An addendum to the main Getting Started guide for
+ those using Visual Studio on Windows.</li>
+
+ <li><a href="tutorial/">LLVM Tutorial</a> - A walk through the process of using
+ LLVM for a custom language, and the facilities LLVM offers in tutorial form.</li>
+ <li><a href="DeveloperPolicy.html">Developer Policy</a> - The LLVM project's
+ policy towards developers and their contributions.</li>
+
+ <li><a href="/docs/CommandGuide/index.html">LLVM Command Guide</a> - A reference
+ manual for the LLVM command line utilities ("man" pages for LLVM tools).<br>
+ Current tools:
+ <a href="/releases/2.5/docs/llvm-ar.html">llvm-ar</a>,
+ <a href="/releases/2.5/docs//llvm-as.html">llvm-as</a>,
+ <a href="/releases/2.5/docs/llvm-dis.html">llvm-dis</a>,
+ <a href="/releases/2.5/docs/llvm-extract.html">llvm-extract</a>,
+ <a href="/releases/2.5/docs/llvm-ld.html">llvm-ld</a>,
+ <a href="/releases/2.5/docs/llvm-link.html">llvm-link</a>,
+ <a href="/releases/2.5/docs/llvm-nm.html">llvm-nm</a>,
+ <a href="/releases/2.5/docs/llvm-prof.html">llvm-prof</a>,
+ <a href="/releases/2.5/docs/llvm-ranlib.html">llvm-ranlib</a>,
+ <a href="/releases/2.5/docs/opt.html">opt</a>,
+ <a href="/releases/2.5/docs/llc.html">llc</a>,
+ <a href="/releases/2.5/docs/lli.html">lli</a>,
+ <a href="/releases/2.5/docs/llvmc.html">llvmc</a>
+ <a href="/releases/2.5/docs/llvmgcc.html">llvm-gcc</a>,
+ <a href="/releases/2.5/docs/llvmgxx.html">llvm-g++</a>,
+ <a href="/releases/2.5/docs/stkrc.html">stkrc</a>,
+ <a href="/releases/2.5/docs/bugpoint.html">bugpoint</a>,
+ <a href="/releases/2.5/docs/llvm-bcanalyzer.html">llvm-bcanalyzer</a>,
+ </li>
+
+ <li><a href="Passes.html">LLVM's Analysis and Transform Passes</a> - A list of
+ optimizations and analyses implemented in LLVM.</li>
+
+ <li><a href="FAQ.html">Frequently Asked Questions</a> - A list of common
+ questions and problems and their solutions.</li>
+
+ <li><a href="ReleaseNotes.html">Release notes for the current release</a>
+ - This describes new features, known bugs, and other limitations.</li>
+
+ <li><a href="HowToSubmitABug.html">How to Submit A Bug Report</a> -
+ Instructions for properly submitting information about any bugs you run into in
+ the LLVM system.</li>
+
+ <li><a href="TestingGuide.html">LLVM Testing Infrastructure Guide</a> - A reference
+ manual for using the LLVM testing infrastructure.</li>
+
+ <li><a href="GCCFEBuildInstrs.html">How to build the Ada/C/C++/Fortran front-ends</a> -
+ Instructions for building gcc front-ends from source.</li>
+
+ <li><a href="Lexicon.html">The LLVM Lexicon</a> - Definition of acronyms, terms
+ and concepts used in LLVM.</li>
+
+ <li><a name="irc">You can probably find help on the unofficial LLVM IRC
+ channel</a>. We often are on irc.oftc.net in the #llvm channel. If you are
+ using the mozilla browser, and have chatzilla installed, you can <a
+ href="irc://irc.oftc.net/llvm">join #llvm on irc.oftc.net</a> directly.</li>
+
+ </ul>
+
+
+ <!--=======================================================================-->
+ <div class="doc_section"><a name="llvmprog">General LLVM Programming Documentation</a></div>
+ <!--=======================================================================-->
+
+ <ul>
+ <li><a href="LangRef.html">LLVM Language Reference Manual</a> - Defines the LLVM
+ intermediate representation and the assembly form of the different nodes.</li>
+
+ <li><a href="ProgrammersManual.html">The LLVM Programmers Manual</a> -
+ Introduction to the general layout of the LLVM sourcebase, important classes
+ and APIs, and some tips & tricks.</li>
+
+ <li><a href="Projects.html">LLVM Project Guide</a> - How-to guide and
+ templates for new projects that <em>use</em> the LLVM infrastructure. The
+ templates (directory organization, Makefiles, and test tree) allow the project
+ code to be located outside (or inside) the <tt>llvm/</tt> tree, while using LLVM
+ header files and libraries.</li>
+
+ <li><a href="MakefileGuide.html">LLVM Makefile Guide</a> - Describes how the
+ LLVM makefiles work and how to use them.</li>
+
+ <li><a href="CommandLine.html">CommandLine library Reference Manual</a> -
+ Provides information on using the command line parsing library.</li>
+
+ <li><a href="CodingStandards.html">LLVM Coding standards</a> -
+ Details the LLVM coding standards and provides useful information on writing
+ efficient C++ code.</li>
+
+ <li><a href="ExtendingLLVM.html">Extending LLVM</a> - Look here to see how
+ to add instructions and intrinsics to LLVM.</li>
+
+ <li><a href="UsingLibraries.html">Using LLVM Libraries</a> - Look here to
+ understand how to use the libraries produced when LLVM is compiled.</li>
+
+ <li><a href="HowToReleaseLLVM.html">How To Release LLVM To The Public</a> - This
+ is a guide to preparing LLVM releases. Most developers can ignore it.</li>
+
+ <li><a href="http://llvm.org/doxygen/">Doxygen generated
+ documentation</a> (<a
+ href="http://llvm.org/doxygen/inherits.html">classes</a>)
+
+ (<a href="http://llvm.org/doxygen/doxygen.tar.gz">tarball</a>)
+ </li>
+
+ <li><a href="http://llvm.org/viewvc/">ViewVC Repository Browser</a></li>
+
+ </ul>
+
+ <!--=======================================================================-->
+ <div class="doc_section"><a name="subsystems">LLVM Subsystem Documentation</a></div>
+ <!--=======================================================================-->
+
+ <ul>
+
+ <li><a href="WritingAnLLVMPass.html">Writing an LLVM Pass</a> - Information
+ on how to write LLVM transformations and analyses.</li>
+
+ <li><a href="WritingAnLLVMBackend.html">Writing an LLVM Backend</a> - Information
+ on how to write LLVM backends for machine targets.</li>
+
+ <li><a href="CodeGenerator.html">The LLVM Target-Independent Code
+ Generator</a> - The design and implementation of the LLVM code generator.
+ Useful if you are working on retargetting LLVM to a new architecture, designing
+ a new codegen pass, or enhancing existing components.</li>
+
+ <li><a href="TableGenFundamentals.html">TableGen Fundamentals</a> -
+ Describes the TableGen tool, which is used heavily by the LLVM code
+ generator.</li>
+
+ <li><a href="AliasAnalysis.html">Alias Analysis in LLVM</a> - Information
+ on how to write a new alias analysis implementation or how to use existing
+ analyses.</li>
+
+ <li><a href="GarbageCollection.html">Accurate Garbage Collection with
+ LLVM</a> - The interfaces source-language compilers should use for compiling
+ GC'd programs.</li>
+
+ <li><a href="SourceLevelDebugging.html">Source Level Debugging with
+ LLVM</a> - This document describes the design and philosophy behind the LLVM
+ source-level debugger.</li>
+
+ <li><a href="ExceptionHandling.html">Zero Cost Exception handling in LLVM</a>
+ - This document describes the design and implementation of exception handling
+ in LLVM.</li>
+
+ <li><a href="Bugpoint.html">Bugpoint</a> - automatic bug finder and test-case
+ reducer description and usage information.</li>
+
+ <li><a href="CompilerDriverTutorial.html">Compiler Driver (llvmc) Tutorial</a>
+ - This document is a tutorial introduction to the usage and
+ configuration of the LLVM compiler driver tool, <tt>llvmc</tt>.</li>
+
+ <li><a href="CompilerDriver.html">Compiler Driver (llvmc)
+ Reference</a> - This document describes the design and configuration
+ of <tt>llvmc</tt> in more detail.</li>
+
+ <li><a href="BitCodeFormat.html">LLVM Bitcode File Format</a> - This describes
+ the file format and encoding used for LLVM "bc" files.</li>
+
+ <li><a href="SystemLibrary.html">System Library</a> - This document describes
+ the LLVM System Library (<tt>lib/System</tt>) and how to keep LLVM source code
+ portable</li>
+
+ <li><a href="LinkTimeOptimization.html">Link Time Optimization</a> - This
+ document describes the interface between LLVM intermodular optimizer and
+ the linker and its design</li>
+
+ </ul>
+
+
+ <!--=======================================================================-->
+ <div class="doc_section"><a name="maillist">LLVM Mailing Lists</a></div>
+ <!--=======================================================================-->
+
+ <ul>
+ <li>The <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-announce">
+ LLVM Announcements List</a>: This is a low volume list that provides important
+ announcements regarding LLVM. It gets email about once a month.</li>
+
+ <li>The <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">Developer's
+ List</a>: This list is for people who want to be included in technical
+ discussions of LLVM. People post to this list when they have questions about
+ writing code for or using the LLVM tools. It is relatively low volume.</li>
+
+ <li>The <a href="http://lists.cs.uiuc.edu/pipermail/llvmbugs/">Bugs &
+ Patches Archive</a>: This list gets emailed every time a bug is opened and
+ closed, and when people submit patches to be included in LLVM. It is higher
+ volume than the LLVMdev list.</li>
+
+ <li>The <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/">Commits
+ Archive</a>: This list contains all commit messages that are made when LLVM
+ developers commit code changes to the repository. It is useful for those who
+ want to stay on the bleeding edge of LLVM development. This list is very high
+ volume.</li>
+
+ <li>The <a href="http://lists.cs.uiuc.edu/pipermail/llvm-testresults/">
+ Test Results Archive</a>: A message is automatically sent to this list by every
+ active nightly tester when it completes. As such, this list gets email several
+ times each day, making it a high volume list.</li>
+
+ </ul>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2009/03/03 05:17:36 $
+ </address>
+ </body></html>
+
Index: llvm-www/releases/2.5/docs/llvm.css
diff -c /dev/null llvm-www/releases/2.5/docs/llvm.css:1.1
*** /dev/null Mon Mar 2 23:19:10 2009
--- llvm-www/releases/2.5/docs/llvm.css Mon Mar 2 23:17:36 2009
***************
*** 0 ****
--- 1,100 ----
+ /*
+ * LLVM documentation style sheet
+ */
+
+ /* Common styles */
+ .body { color: black; background: white; margin: 0 0 0 0 }
+
+ /* No borders on image links */
+ a:link img, a:visited img { border-style: none }
+
+ address img { float: right; width: 88px; height: 31px; }
+ address { clear: right; }
+
+ table { text-align: center; border: 2px solid black;
+ border-collapse: collapse; margin-top: 1em; margin-left: 1em;
+ margin-right: 1em; margin-bottom: 1em; }
+ tr, td { border: 2px solid gray; padding: 4pt 4pt 2pt 2pt; }
+ th { border: 2px solid gray; font-weight: bold; font-size: 105%;
+ background: url("img/lines.gif");
+ font-family: "Georgia,Palatino,Times,Roman,SanSerif";
+ text-align: center; vertical-align: middle; }
+ /*
+ * Documentation
+ */
+ /* Common for title and header */
+ .doc_title, .doc_section, .doc_subsection, h1, h2 {
+ color: black; background: url("img/lines.gif");
+ font-family: "Georgia,Palatino,Times,Roman,SanSerif"; font-weight: bold;
+ border-width: 1px;
+ border-style: solid none solid none;
+ text-align: center;
+ vertical-align: middle;
+ padding-left: 8pt;
+ padding-top: 1px;
+ padding-bottom: 2px
+ }
+
+ h1, .doc_section { text-align: center; font-size: 22pt;
+ margin: 20pt 0pt 5pt 0pt; }
+
+ .doc_title, .title { text-align: left; font-size: 25pt }
+
+ h2, .doc_subsection { width: 75%;
+ text-align: left; font-size: 12pt;
+ padding: 4pt 4pt 4pt 4pt;
+ margin: 1.5em 0.5em 0.5em 0.5em }
+
+ h3, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em;
+ font-weight: bold; font-style: oblique;
+ border-bottom: 1px solid #999999; font-size: 12pt;
+ width: 75%; }
+
+ .doc_author { text-align: left; font-weight: bold; padding-left: 20pt }
+ .doc_text { text-align: left; padding-left: 20pt; padding-right: 10pt }
+
+ .doc_footer { text-align: left; padding: 0 0 0 0 }
+
+ .doc_hilite { color: blue; font-weight: bold; }
+
+ .doc_table { text-align: center; width: 90%;
+ padding: 1px 1px 1px 1px; border: 1px; }
+
+ .doc_warning { color: red; font-weight: bold }
+
+ /* <div class="doc_code"> would use this class, and <div> adds more padding */
+ .doc_code, .literal-block
+ { border: solid 1px gray; background: #eeeeee;
+ margin: 0 1em 0 1em;
+ padding: 0 1em 0 1em;
+ display: table;
+ }
+
+ /* It is preferrable to use <pre class="doc_code"> everywhere instead of the
+ * <div class="doc_code"><pre>...</ptr></div> construct.
+ *
+ * Once all docs use <pre> for code regions, this style can be merged with the
+ * one above, and we can drop the [pre] qualifier.
+ */
+ pre.doc_code, .literal-block { padding: 1em 2em 1em 1em }
+
+ .doc_notes { background: #fafafa; border: 1px solid #cecece;
+ display: table; padding: 0 1em 0 .1em }
+
+ table.layout { text-align: left; border: none; border-collapse: collapse;
+ padding: 4px 4px 4px 4px; }
+ tr.layout, td.layout, td.left, td.right
+ { border: none; padding: 4pt 4pt 2pt 2pt; vertical-align: top; }
+ td.left { text-align: left }
+ td.right { text-align: right }
+ th.layout { border: none; font-weight: bold; font-size: 105%;
+ text-align: center; vertical-align: middle; }
+
+ /* Left align table cell */
+ .td_left { border: 2px solid gray; text-align: left; }
+
+ /* ReST-specific */
+ .title { margin-top: 0 }
+ #contents { display: none }
+ div.contents ul { list-style-type: decimal }
+ .toc-backref { color: black; text-decoration: none; }
More information about the llvm-commits
mailing list