[llvm-commits] CVS: llvm-www/releases/1.0/AliasAnalysis.html CFEBuildInstrs.html CodingStandards.html CommandLine.html DSGraphStatus.html FAQ.html GettingStarted.html HowToSubmitABug.html LangRef.html OpenProjects.html ProgrammersManual.html Projects.html ReleaseNotes.html ReleaseTasks.html TestingGuide.html WritingAnLLVMPass.html download.html register.cgi register.html index.html
John Criswell
criswell at cs.uiuc.edu
Fri Oct 24 15:52:03 PDT 2003
Changes in directory llvm-www/releases/1.0:
AliasAnalysis.html added (r1.1)
CFEBuildInstrs.html added (r1.1)
CodingStandards.html added (r1.1)
CommandLine.html added (r1.1)
DSGraphStatus.html added (r1.1)
FAQ.html added (r1.1)
GettingStarted.html added (r1.1)
HowToSubmitABug.html added (r1.1)
LangRef.html added (r1.1)
OpenProjects.html added (r1.1)
ProgrammersManual.html added (r1.1)
Projects.html added (r1.1)
ReleaseNotes.html added (r1.1)
ReleaseTasks.html added (r1.1)
TestingGuide.html added (r1.1)
WritingAnLLVMPass.html added (r1.1)
download.html added (r1.1)
register.cgi added (r1.1)
register.html added (r1.1)
index.html updated: 1.1 -> 1.2
---
Log message:
Added documentation to the release section of the website.
Also adding registration script.
---
Diffs of the changes: (+12737 -1)
Index: llvm-www/releases/1.0/AliasAnalysis.html
diff -c /dev/null llvm-www/releases/1.0/AliasAnalysis.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/AliasAnalysis.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,505 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <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>Alias Analysis Infrastructure in LLVM</title>
+ </head>
+
+ <body>
+
+ <div class="doc_title">
+ Alias Analysis Infrastructure in LLVM
+ </div>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a></li>
+
+ <li><a href="#overview">AliasAnalysis Overview</a></li>
+ <ul>
+ <li><a href="#pointers">Representation of Pointers</a></li>
+ <li><a href="#MustMayNo">Must, May, and No Alias Responses</a></li>
+ <li><a href="#ModRefInfo">The <tt>getModRefInfo</tt> methods</a></li>
+ </ul>
+
+ <li><a href="#writingnew">Writing a new AliasAnalysis Implementation</a></li>
+ <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">The AliasAnalysis chaining behavior</a></li>
+ <li><a href="#implefficiency">Efficiency Issues</a></li>
+ </ul>
+
+ <li><a href="#using">Using AliasAnalysis results</a></li>
+ <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 AliasAnalysis interface directly</a></li>
+ </ul>
+ <li><a href="#tools">Helpful alias analysis related tools</a></li>
+ <ul>
+ <li><a href="#no-aa">The <tt>-no-aa</tt> pass</a></li>
+ <li><a href="#print-alias-sets">The <tt>-print-alias-sets</tt> pass</a></li>
+ <li><a href="#count-aa">The <tt>-count-aa</tt> pass</a></li>
+ <li><a href="#aa-eval">The <tt>-aa-eval</tt> pass</a></li>
+ </ul>
+ </ul>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></b></p>
+ </ol>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="introduction">Introduction</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ Alias Analysis (or Pointer Analysis) is a technique which attempts to determine
+ whether or not two pointers ever can point to the same object in memory.
+ Traditionally, Alias Analyses respond to a query with either a <a
+ href="#MustNoMay">Must, May, or No</a> alias response, indicating that two
+ pointers do point to the same object, might point to the same object, or are
+ known not to point to the same object.
+ </p>
+ <p>
+ The <a href="/doxygen/classAliasAnalysis.html">AliasAnalysis</a> class is the
+ centerpiece of the LLVM Alias Analysis related infrastructure. This class is
+ the common interface between clients of alias analysis information and the
+ implementations providing it. 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">AliasAnalysis Overview</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ The <a href="/doxygen/classAliasAnalysis.html">AliasAnalysis</a> class defines
+ the interface that 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 AliasAnalysis 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
+ AliasAnalysis 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 AliasAnalysis class provides several methods which are
+ used to query whether or not pointers alias, whether function calls can modify
+ or read memory, etc.
+ </p>
+ <p>
+ Representing memory objects as a starting address and a size is critically
+ important for precise Alias Analyses. For example, consider this (silly) C
+ code:
+ </p>
+ <p>
+ <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>
+ </p>
+ <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>
+ <p>
+ <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>
+ </p>
+ <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="MustMayNo">Must, May, and No Alias Responses</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ An Alias Analysis implementation can return one of three responses: MustAlias,
+ MayAlias, and NoAlias. The No and May alias results are obvious: if the two
+ pointers may never equal each other, return NoAlias, if they might, return
+ MayAlias.
+ </p>
+ <p>
+ The Must Alias response is trickier though. In LLVM, the Must Alias response
+ may only be returned if the two memory objects are guaranteed to always start at
+ exactly the same location. If two memory objects overlap, but do not start at
+ the same location, MayAlias must be returned.
+ </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 action <b>may</b> read a location, Ref
+ is returned.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="writingnew">Writing a new AliasAnalysis 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 minimal example,
+ take a look at the <a href="/doxygen/structNoAA.html"><tt>no-aa</tt></a>
+ implementation.
+ </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>
+ <p>
+ <ol>
+ <li>If you require interprocedural analysis, it should be a
+ <tt>Pass</tt>.</li>
+ <li>If you are a global analysis, subclass <tt>FunctionPass</tt>.</li>
+ <li>If you are a local pass, subclass <tt>BasicBlockPass</tt>.</li>
+ <li>If you don't need to look at the program at all, subclass
+ <tt>ImmutablePass</tt>.</li>
+ </ol>
+ </p>
+ <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 AliasAnalysis is required to invoke two methods on the
+ AliasAnalysis 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>
+ <p>
+ <pre>
+ void getAnalysisUsage(AnalysisUsage &AU) const {
+ AliasAnalysis::getAnalysisUsage(AU);
+ <i>// declare your dependencies here.</i>
+ }
+ </pre>
+ </p>
+ <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>, <tt>runOnBasicBlock</tt> for
+ a <tt>BasicBlockPass</tt>, or <tt>InitializeAliasAnalysis</tt> for an
+ <tt>ImmutablePass</tt>). For example (as part of a <tt>Pass</tt>):
+ </p>
+ <p>
+ <pre>
+ bool run(Module &M) {
+ InitializeAliasAnalysis(this);
+ <i>// Perform analysis here...</i>
+ return false;
+ }
+ </pre>
+ </p>
+ </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/classAliasAnalysis.html">AliasAnalysis</a> virtual
+ methods default to providing 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">The AliasAnalysis chaining behavior</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ With only two special exceptions (the <tt>basicaa</tt> and <a
+ href="#no-aa"><tt>no-aa</tt></a> passes) every alias analysis pass should chain
+ to another alias analysis implementation (for example, you could specify
+ "<tt>-basic-aa -ds-aa -andersens-aa -licm</tt>" to get the maximum benefit from
+ the three alias analyses). To do this, simply "Require" AliasAnalysis in your
+ <tt>getAnalysisUsage</tt> method, and if you need to return a conservative
+ MayAlias or Mod/Ref result, simply chain to a lower analysis.
+ </p>
+ </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 AliasAnalysis 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. If your analysis or transformation
+ can be modelled 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/classAliasSetTracker.html">AliasSetTracker</a></tt> class is used
+ to efficiently build these Alias Sets from the pairwise alias analysis
+ information provided by the AliasAnalysis interface.
+ </p>
+ <p>
+ First you initialize the AliasSetTracker by use 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 AliasSetTracker
+ <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 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 AliasSetTrackers to build alias information
+ about each loop nest. If an AliasSet 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 <b>and</b> are must alias sets, then the stores may be sunk to
+ outside of the loop. Both of these transformations obviously only apply if the
+ pointer argument is loop-invariant.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="direct">Using the AliasAnalysis interface directly</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ As a last resort, your pass could use the AliasAnalysis interface directly to
+ service your pass. If you find the need to do this, please <a
+ href="mailto:sabre at nondot.org">let me know</a> so I can see if something new
+ needs to be added to LLVM.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="tools">Helpful alias-analysis-related tools</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ If you're going to be working with the AliasAnalysis infrastructure, there are
+ several nice tools that may be useful for you and are worth knowing about...
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="no-aa">The <tt>-no-aa</tt> pass</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ The <tt>-no-aa</tt> analysis 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.
+ If you don't specify an alias analysis, the default will be to use the
+ <tt>basicaa</tt> pass which does quite a bit of disambiguation on its own.
+ </p>
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <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>analyze</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>.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <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 kinds of responses are returned by the alias analysis. An
+ example usage is:
+ </p>
+ <p>
+ <pre>
+ $ opt -basicaa -count-aa -ds-aa -count-aa -licm
+ </pre>
+ </p>
+ <p>
+ Which 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 evaluating an alias analysis for precision.
+ </p>
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <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.
+ </p>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <font size="-1">
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2003/10/24 20:51:39 $
+ </font>
+ </body>
+ </html>
Index: llvm-www/releases/1.0/CFEBuildInstrs.html
diff -c /dev/null llvm-www/releases/1.0/CFEBuildInstrs.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/CFEBuildInstrs.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,166 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <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>Bootstrapping the C/C++ Front-End</title>
+ </head>
+ <body>
+
+ <div class="doc_title">
+ Bootstrapping the C/C++ Front-End
+ </div>
+
+ <p>This document is intended to explain the process of building the LLVM
+ C/C++ front-end, based on GCC 3.4, from source.</p>
+
+ <p><b>NOTE:</b> This is currently a somewhat fragile, error-prone
+ process, and you should only try to do it if
+ <ul>
+ <li>(A) you really, really, really can't use the binaries we distribute
+ <li>(B) you need GCC to fix some of the header files on your system
+ <li>(C) you are an elite GCC hacker.</p>
+ </ul>
+
+ <p>We welcome patches to help make this process simpler.</p>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section">
+ <a name="instructions">Instructions</a>
+ </div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+ <p>
+ <ol>
+ <li><p>Configure and build the LLVM libraries and tools using:</p>
+ <pre>
+ % cd llvm
+ % ./configure [options...]
+ % gmake tools-only
+ </pre>
+ <p>The use of the non-default target "tools-only" means that the
+ LLVM tools and libraries will build, and the binaries will be
+ deposited in llvm/tools/Debug, but the runtime (bytecode)
+ libraries will not build.</p></li>
+
+ <li><p>Add the directory containing the tools to your PATH.</p>
+ <pre>
+ % set path = ( `cd llvm/tools/Debug && pwd` $path )
+ </pre></li>
+
+ <li><p>Unpack the C/C++ front-end source into cfrontend/src.</p></li>
+
+ <li><p>Edit src/configure. Change the first line (starting w/ #!) to
+ contain the correct full pathname of sh.</p></li>
+
+ <li><p>Make "build" and "install" directories as siblings of the "src"
+ tree.</p>
+ <pre>
+ % pwd
+ /usr/local/example/cfrontend/src
+ % cd ..
+ % mkdir build install
+ % set CFEINSTALL = `pwd`/install
+ </pre></li>
+
+ <li><p>Configure, build and install the C front-end:</p>
+ <pre>
+ % cd build
+ % ../src/configure --prefix=$CFEINSTALL --disable-nls --disable-shared \
+ --enable-languages=c,c++
+ % gmake all-gcc
+ % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc
+ % gmake all; gmake install
+ </pre>
+
+ <p><b>Common Problem:</b> You may get error messages regarding the fact
+ that LLVM does not support inline assembly. Here are two common
+ fixes:</p>
+
+ <ul>
+ <li><p><b>Fix 1:</b> If you have system header files that include
+ inline assembly, you may have to modify them to remove the inline
+ assembly, and install the modified versions in
+ <code>$CFEINSTALL/<i>target-triplet</i>/sys-include</code>.</p></li>
+
+ <li><b>Fix 2:</b> If you are building the C++ front-end on a CPU we
+ haven't tried yet, you will probably have to edit the appropriate
+ version of atomicity.h under
+ <code>src/libstdc++-v3/config/cpu/<i>name-of-cpu</i>/atomicity.h</code>
+ and apply a patch so that it does not use inline assembly.</p></li>
+ </ul>
+
+ <p><b>Porting to a new architecture:</b> If you are porting the new front-end
+ to a new architecture, or compiling in a different configuration that we have
+ previously, there are probably several changes you will have to make to the GCC
+ target to get it to work correctly. These include:<p>
+
+ <ul>
+ <li>Often targets include special or assembler linker flags which
+ <tt>gccas</tt>/<tt>gccld</tt> does not understand. In general, these can
+ just be removed.</li>
+ <li>LLVM currently does not support any floating point values other than
+ 32-bit and 64-bit IEEE floating point. The primary effect of this is
+ that you may have to map "long double" onto "double".</li>
+ <li>The profiling hooks in GCC do not apply at all to the LLVM front-end.
+ These may need to be disabled.</li>
+ <li>No inline assembly for position independent code. At the LLVM level,
+ everything is position independent.</li>
+ <li>We handle <tt>.init</tt> and <tt>.fini</tt> differently.</li>
+ <li>You may have to disable multilib support in your target. Using multilib
+ support causes the GCC compiler driver to add a lot of "<tt>-L</tt>"
+ options to the link line, which do not relate to LLVM and confuse
+ <tt>gccld</tt>. To disable multilibs, delete any
+ <tt>MULTILIB_OPTIONS</tt> lines from your target files.</li>
+ <li>Did we mention that we don't support inline assembly? You'll probably
+ have to add some fixinclude hacks to disable it in the system
+ headers.</li>
+ </ul>
+ </li>
+
+ <li><p>Go back into the LLVM source tree proper. Edit Makefile.config
+ to redefine <code>LLVMGCCDIR</code> to the full pathname of the
+ <code>$CFEINSTALL</code> directory, which is the directory you just
+ installed the C front-end into. (The ./configure script is likely to
+ have set this to a directory which does not exist on your system.)</p></li>
+
+ <li><p>If you edited header files during the C/C++ front-end build as
+ described in "Fix 1" above, you must now copy those header files from
+ <code>$CFEINSTALL/<i>target-triplet</i>/sys-include</code> to
+ <code>$CFEINSTALL/lib/gcc/<i>target-triplet</i>/3.4-llvm/include</code>.
+ (This should be the "include" directory in the same directory as the
+ libgcc.a library, which you can find by running
+ <code>$CFEINSTALL/bin/gcc --print-libgcc-file-name</code>.)</p></li>
+
+ <li><p>Build and install the runtime (bytecode) libraries by running:</p>
+ <pre>
+ % gmake -C runtime
+ % mkdir $CFEINSTALL/bytecode-libs
+ % gmake -C runtime install
+ % setenv LLVM_LIB_SEARCH_PATH $CFEINSTALL/bytecode-libs
+ </pre></li>
+
+ <li><p>Test the newly-installed C frontend by one or more of the
+ following means:</p>
+ <ul>
+ <li> compiling and running a "hello, LLVM" program in C and C++.</li>
+ <li> running the tests under <tt>test/Programs</tt> using <code>gmake -C
+ test/Programs</code></li>
+ </ul>
+ </p>
+ </li>
+ </ol>
+ </div>
+
+ <!-- *********************************************************************** -->
+
+ <hr><font size="-1">
+ <address><a href="mailto:gaeke -at- uiuc.edu">Brian Gaeke</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2003/10/24 20:51:39 $
+ </font>
+
+ </body>
+ </html>
Index: llvm-www/releases/1.0/CodingStandards.html
diff -c /dev/null llvm-www/releases/1.0/CodingStandards.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/CodingStandards.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,841 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>A Few Coding Standards</title></head>
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+5 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>A Few Coding Standards</b></font></td>
+ </tr></table>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a>
+ <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><a href="#scf_commentformat">Comment Formatting</a>
+ <li><a href="#scf_includes">#include Style</a>
+ <li><a href="#scf_codewidth">Source Code Width</a>
+ <li><a href="#scf_spacestabs">Use Spaces Instead of Tabs</a>
+ <li><a href="#scf_indentation">Indent Code Consistently</a>
+ </ol>
+ <li><a href="#compilerissues">Compiler Issues</a>
+ <ol>
+ <li><a href="#ci_warningerrors">Treat Compiler Warnings Like Errors</a>
+ <li><a href="#ci_cpp_features">Which C++ features can I use?</a>
+ <li><a href="#ci_portable_code">Write Portable Code</a>
+ </ol>
+ </ol>
+ <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><a href="#hl_dontinclude">#include as Little as Possible</a>
+ <li><a href="#hl_privateheaders">Keep "internal" Headers Private</a>
+ </ol>
+ <li><a href="#micro">The Low Level Issues</a>
+ <ol>
+ <li><a href="#hl_assert">Assert Liberally</a>
+ <li><a href="#hl_preincrement">Prefer Preincrement</a>
+ <li><a href="#hl_avoidendl">Avoid endl</a>
+ <li><a href="#hl_exploitcpp">Exploit C++ to its Fullest</a>
+ </ol>
+ <li><a href="#iterators">Writing Iterators</a>
+ </ol>
+ <li><a href="#seealso">See Also</a>
+ </ol><p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="introduction">Introduction
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ 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:
+
+ <a name="goldenrule">
+ <blockquote><b>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.</b></blockquote>
+
+ 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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="mechanicalissues">Mechanical Source Issues
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="sourceformating">Source Code Formatting
+ </b></font></td></tr></table><ul>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="scf_commenting"><h4><hr size=0>Commenting</h4><ul>
+
+ 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>
+
+ <ol>
+ <h4><li>File Headers</h4>
+ 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 CVS.
+ Most source trees will probably have a standard file header format. The
+ standard format for the LLVM source tree looks like this:<p>
+
+ <pre>
+ //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
+ //
+ // This file contains the declaration of the Instruction class, which is the
+ // base class for all of the VM instructions.
+ //
+ //===----------------------------------------------------------------------===//
+ </pre>
+
+ 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 tag
+ this 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>
+
+ 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>
+
+
+ <h4><li>Class overviews</h4>
+
+ Classes are one fundemental 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>
+
+
+ <h4><li>Method information</h4>
+
+ 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>
+
+ Good things to talk about here are what happens when something unexpected
+ happens: does the method return null? Abort? Format your hard disk?<p>
+ </ol>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="scf_commentformat"><h4><hr size=0>Comment Formatting</h4><ul>
+
+ 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>When writing a header file that may be #included by a C source file.
+ <li>When writing a source file that is used by a tool that only accepts C style
+ comments.
+ </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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="scf_includes"><h4><hr size=0>#include Style</h4><ul>
+
+ 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 #includes required by the file should
+ be listed. We prefer these #includes to be listed in this order:<p>
+
+ <ol>
+ <li><a href="#mmheader">Main Module header</a>
+ <li><a href="#hl_privateheaders">Local/Private Headers</a>
+ <li>llvm/*
+ <li>llvm/Analysis/*
+ <li>llvm/Assembly/*
+ <li>llvm/Bytecode/*
+ <li>llvm/CodeGen/*
+ <li>...
+ <li>Support/*
+ <li>Config/*
+ <li>System #includes
+ </ol>
+
+ ... and each catagory should be sorted by name.<p>
+
+ <a name="mmheader">The "Main Module Header" file applies to .cpp file which
+ implement an interface defined by a .h file. This #include 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="scf_codewidth"><h4><hr size=0>Source Code Width</h4><ul>
+
+ 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.
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="scf_spacestabs"><h4><hr size=0>Use Spaces Instead of Tabs</h4><ul>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="scf_indentation"><h4><hr size=0>Indent Code Consistently</h4><ul>
+
+ 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>
+
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="compilerissues">Compiler Issues
+ </b></font></td></tr></table><ul>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="ci_warningerrors"><h4><hr size=0>Treat Compiler Warnings Like Errors</h4><ul>
+
+ 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>
+
+ 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>
+
+ <pre>
+ if (V = getValue()) {
+ ..
+ }
+ </pre><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>
+
+ <pre>
+ if ((V = getValue())) {
+ ..
+ }
+ </pre><p>
+
+ ...which shuts <tt>gcc</tt> up. Any <tt>gcc</tt> warning that annoys you can be
+ fixed by massaging the code appropriately.<p>
+
+ These are the <tt>gcc</tt> warnings that I prefer to enable: <tt>-Wall -Winline
+ -W -Wwrite-strings -Wno-unused</tt><p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="ci_cpp_features"><h4><hr size=0>Which C++ features can I use?</h4><ul>
+
+ Compilers are finally catching up to the C++ standard. Most compilers implement
+ most features, so you can use just about any features that you would like. In
+ the LLVM source tree, I have chosen to not use these features:<p>
+
+ <ol>
+ <li>Exceptions: Exceptions are very useful for error reporting and handling
+ exceptional conditions. I do not use them in LLVM because they do have an
+ associated performance impact (by restricting restructuring of code), and parts
+ of LLVM are designed for performance critical purposes.<p>
+
+ Just like most of the rules in this document, this isn't a hard and fast
+ requirement. Exceptions are used in the Parser, because it simplifies error
+ reporting <b>significantly</b>, and the LLVM parser is not at all in the
+ critical path.<p>
+
+ <li>RTTI: RTTI has a large cost in terms of executable size, and compilers are
+ not yet very good at stomping out "dead" class information blocks. Because of
+ this, typeinfo and dynamic cast are not used.
+ </ol><p>
+
+ Other features, such as templates (without partial specialization) can be used
+ freely. The general goal is to have clear, consise, performant code... if a
+ technique assists with that then use it.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="ci_portable_code"><h4><hr size=0>Write Portable Code</h4><ul>
+
+ 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>
+
+ 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>
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="styleissues">Style Issues
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="macro">The High Level Issues
+ </b></font></td></tr></table><ul>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_module"><h4><hr size=0>A Public Header File <b>is</b> a Module</h4><ul>
+
+ 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>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_dontinclude"><h4><hr size=0>#include as Little as Possible</h4><ul>
+
+ <tt>#include</tt> hurts compile time performance. Don't do it unless you have
+ to, especially in header files.<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 #include 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>
+
+ 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, 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_privateheaders"><h4><hr size=0>Keep "internal" Headers Private</h4><ul>
+
+ 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>
+
+ 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>
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="micro">The Low Level Issues
+ </b></font></td></tr></table><ul>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_assert"><h4><hr size=0>Assert Liberally</h4><ul>
+
+ 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>
+
+ 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>
+
+ <pre>
+ inline Value *getOperand(unsigned i) {
+ assert(i < Operands.size() && "getOperand() out of range!");
+ return Operands[i];
+ }
+ </pre>
+
+ Here are some examples:
+
+ <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><p>
+
+ You get the idea...<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_preincrement"><h4><hr size=0>Prefer Preincrement</h4><ul>
+
+ Hard fast rule: Preincrement (++X) may be no slower than postincrement (X++) and
+ could very well be a lot faster than it. Use preincrementation whenever
+ possible.<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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_avoidendl"><h4><hr size=0>Avoid endl</h4><ul>
+
+ The <tt>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>
+
+ <pre>
+ cout << endl;
+ cout << "\n" << flush;
+ </pre>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hl_exploitcpp"><h4><hr size=0>Exploit C++ to its Fullest</h4><ul>
+
+ C++ is a powerful language. With a firm grasp on its capabilities, you can make
+ write effective, consise, readable and maintainable code all at the same time.
+ By staying consistent, you reduce the amount of special cases that need to be
+ remembered. Reducing the total number of lines of code you write is a good way
+ to avoid documentation, and avoid giving bugs a place to hide.<p>
+
+ For these reasons, come to know and love the contents of your local
+ <algorithm> header file. Know about <functional> and what it can do
+ for you. C++ is just a tool that wants you to master it. :)<p>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="iterators">Writing Iterators
+ </b></font></td></tr></table><ul>
+
+ Here's a pretty good summary of how to write your own data structure iterators
+ in a way that is compatible with the STL, and with a lot of other code out there
+ (slightly edited by Chris):<p>
+
+ <pre>
+ From: Ross Smith <ross.s at ihug.co.nz>
+ Newsgroups: comp.lang.c++.moderated
+ Subject: Writing iterators (was: Re: Non-template functions that take iterators)
+ Date: 28 Jun 2001 12:07:10 -0400
+
+ Andre Majorel wrote:
+ > Any pointers handy on "writing STL-compatible iterators for
+ > dummies ?"
+
+ I'll give it a try...
+
+ The usual situation requiring user-defined iterators is that you have
+ a type that bears some resemblance to an STL container, and you want
+ to provide iterators so it can be used with STL algorithms. You need
+ to ask three questions:
+
+ First, is this simply a wrapper for an underlying collection of
+ objects that's held somewhere as a real STL container, or is it a
+ "virtual container" for which iteration is (under the hood) more
+ complicated than simply incrementing some underlying iterator (or
+ pointer or index or whatever)? In the former case you can frequently
+ get away with making your container's iterators simply typedefs for
+ those of the underlying container; your begin() function would call
+ member_container.begin(), and so on.
+
+ Second, do you only need read-only iterators, or do you need separate
+ read-only (const) and read-write (non-const) iterators?
+
+ Third, which kind of iterator (input, output, forward, bidirectional,
+ or random access) is appropriate? If you're familiar with the
+ properties of the iterator types (if not, visit
+ <a href="http://www.sgi.com/tech/stl/">http://www.sgi.com/tech/stl/</a>), the appropriate choice should be
+ obvious from the semantics of the container.
+
+ I'll start with forward iterators, as the simplest case that's likely
+ to come up in normal code. Input and output iterators have some odd
+ properties and rarely need to be implemented in user code; I'll leave
+ them out of discussion. Bidirectional and random access iterators are
+ covered below.
+
+ The exact behaviour of a forward iterator is spelled out in the
+ Standard in terms of a set of expressions with specified behaviour,
+ rather than a set of member functions, which leaves some leeway in how
+ you actually implement it. Typically it looks something like this
+ (I'll start with the const-iterator-only situation):
+
+ #include <iterator>
+
+ class container {
+ public:
+ typedef something_or_other value_type;
+ class const_iterator:
+ public std::iterator<std::forward_iterator_tag, value_type> {
+ friend class container;
+ public:
+ const value_type& operator*() const;
+ const value_type* operator->() const;
+ const_iterator& operator++();
+ const_iterator operator++(int);
+ friend bool operator==(const_iterator lhs,
+ const_iterator rhs);
+ friend bool operator!=(const_iterator lhs,
+ const_iterator rhs);
+ private:
+ //...
+ };
+ //...
+ };
+
+ An iterator should always be derived from an instantiation of the
+ std::iterator template. The iterator's life cycle functions
+ (constructors, destructor, and assignment operator) aren't declared
+ here; in most cases the compiler-generated ones are sufficient. The
+ container needs to be a friend of the iterator so that the container's
+ begin() and end() functions can fill in the iterator's private members
+ with the appropriate values.
+
+ <i>[Chris's Note: I prefer to not make my iterators friends. Instead, two
+ ctor's are provided for the iterator class: one to start at the end of the
+ container, and one at the beginning. Typically this is done by providing
+ two constructors with different signatures.]</i>
+
+ There are normally only three member functions that need nontrivial
+ implementations; the rest are just boilerplate.
+
+ const container::value_type&
+ container::const_iterator::operator*() const {
+ // find the element and return a reference to it
+ }
+
+ const container::value_type*
+ container::const_iterator::operator->() const {
+ return &**this;
+ }
+
+ If there's an underlying real container, operator*() can just return a
+ reference to the appropriate element. If there's no actual container
+ and the elements need to be generated on the fly -- what I think of as
+ a "virtual container" -- things get a bit more complicated; you'll
+ probably need to give the iterator a value_type member object, and
+ fill it in when you need to. This might be done as part of the
+ increment operator (below), or if the operation is nontrivial, you
+ might choose the "lazy" approach and only generate the actual value
+ when one of the dereferencing operators is called.
+
+ The operator->() function is just boilerplate around a call to
+ operator*().
+
+ container::const_iterator&
+ container::const_iterator::operator++() {
+ // the incrementing logic goes here
+ return *this;
+ }
+
+ container::const_iterator
+ container::const_iterator::operator++(int) {
+ const_iterator old(*this);
+ ++*this;
+ return old;
+ }
+
+ Again, the incrementing logic will usually be trivial if there's a
+ real container involved, more complicated if you're working with a
+ virtual container. In particular, watch out for what happens when you
+ increment past the last valid item -- this needs to produce an
+ iterator that will compare equal to container.end(), and making this
+ work is often nontrivial for virtual containers.
+
+ The post-increment function is just boilerplate again (and
+ incidentally makes it obvious why all the experts recommend using
+ pre-increment wherever possible).
+
+ bool operator==(container::const_iterator lhs,
+ container::const_iterator rhs) {
+ // equality comparison goes here
+ }
+
+ bool operator!=(container::const_iterator lhs,
+ container::const_iterator rhs) {
+ return !(lhs == rhs);
+ }
+
+ For a real container, the equality comparison will usually just
+ compare the underlying iterators (or pointers or indices or whatever).
+ The semantics of comparisons for virtual container iterators are often
+ tricky. Remember that iterator comparison only needs to be defined for
+ iterators into the same container, so you can often simplify things by
+ taking for granted that lhs and rhs both point into the same container
+ object. Again, the second function is just boilerplate.
+
+ It's a matter of taste whether iterator arguments are passed by value
+ or reference; I've shown tham passed by value to reduce clutter, but
+ if the iterator contains several data members, passing by reference
+ may be better.
+
+ That convers the const-iterator-only situation. When we need separate
+ const and mutable iterators, one small complication is added beyond
+ the simple addition of a second class.
+
+ class container {
+ public:
+ typedef something_or_other value_type;
+ class const_iterator;
+ class iterator:
+ public std::iterator<std::forward_iterator_tag, value_type> {
+ friend class container;
+ friend class container::const_iterator;
+ public:
+ value_type& operator*() const;
+ value_type* operator->() const;
+ iterator& operator++();
+ iterator operator++(int);
+ friend bool operator==(iterator lhs, iterator rhs);
+ friend bool operator!=(iterator lhs, iterator rhs);
+ private:
+ //...
+ };
+ class const_iterator:
+ public std::iterator<std::forward_iterator_tag, value_type> {
+ friend class container;
+ public:
+ const_iterator();
+ const_iterator(const iterator& i);
+ const value_type& operator*() const;
+ const value_type* operator->() const;
+ const_iterator& operator++();
+ const_iterator operator++(int);
+ friend bool operator==(const_iterator lhs,
+ const_iterator rhs);
+ friend bool operator!=(const_iterator lhs,
+ const_iterator rhs);
+ private:
+ //...
+ };
+ //...
+ };
+
+ There needs to be a conversion from iterator to const_iterator (so
+ that mixed-type operations, such as comparison between an iterator and
+ a const_iterator, will work). This is done here by giving
+ const_iterator a conversion constructor from iterator (equivalently,
+ we could have given iterator an operator const_iterator()), which
+ requires const_iterator to be a friend of iterator, so it can copy its
+ data members. (It also requires the addition of an explicit default
+ constructor to const_iterator, since the existence of another
+ user-defined constructor inhibits the compiler-defined one.)
+
+ Bidirectional iterators add just two member functions to forward
+ iterators:
+
+ class iterator:
+ public std::iterator<std::bidirectional_iterator_tag, value_type> {
+ public:
+ //...
+ iterator& operator--();
+ iterator operator--(int);
+ //...
+ };
+
+ I won't detail the implementations, they're obvious variations on
+ operator++().
+
+ Random access iterators add several more member and friend functions:
+
+ class iterator:
+ public std::iterator<std::random_access_iterator_tag, value_type> {
+ public:
+ //...
+ iterator& operator+=(difference_type rhs);
+ iterator& operator-=(difference_type rhs);
+ friend iterator operator+(iterator lhs, difference_type rhs);
+ friend iterator operator+(difference_type lhs, iterator rhs);
+ friend iterator operator-(iterator lhs, difference_type rhs);
+ friend difference_type operator-(iterator lhs, iterator rhs);
+ friend bool operator<(iterator lhs, iterator rhs);
+ friend bool operator>(iterator lhs, iterator rhs);
+ friend bool operator<=(iterator lhs, iterator rhs);
+ friend bool operator>=(iterator lhs, iterator rhs);
+ //...
+ };
+
+ container::iterator&
+ container::iterator::operator+=(container::difference_type rhs) {
+ // add rhs to iterator position
+ return *this;
+ }
+
+ container::iterator&
+ container::iterator::operator-=(container::difference_type rhs) {
+ // subtract rhs from iterator position
+ return *this;
+ }
+
+ container::iterator operator+(container::iterator lhs,
+ container::difference_type rhs) {
+ return iterator(lhs) += rhs;
+ }
+
+ container::iterator operator+(container::difference_type lhs,
+ container::iterator rhs) {
+ return iterator(rhs) += lhs;
+ }
+
+ container::iterator operator-(container::iterator lhs,
+ container::difference_type rhs) {
+ return iterator(lhs) -= rhs;
+ }
+
+ container::difference_type operator-(container::iterator lhs,
+ container::iterator rhs) {
+ // calculate distance between iterators
+ }
+
+ bool operator<(container::iterator lhs, container::iterator rhs) {
+ // perform less-than comparison
+ }
+
+ bool operator>(container::iterator lhs, container::iterator rhs) {
+ return rhs < lhs;
+ }
+
+ bool operator<=(container::iterator lhs, container::iterator rhs) {
+ return !(rhs < lhs);
+ }
+
+ bool operator>=(container::iterator lhs, container::iterator rhs) {
+ return !(lhs < rhs);
+ }
+
+ Four of the functions (operator+=(), operator-=(), the second
+ operator-(), and operator<()) are nontrivial; the rest are
+ boilerplate.
+
+ One feature of the above code that some experts may disapprove of is
+ the declaration of all the free functions as friends, when in fact
+ only a few of them need direct access to the iterator's private data.
+ I originally got into the habit of doing this simply to keep the
+ declarations together; declaring some functions inside the class and
+ some outside seemed awkward. Since then, though, I've been told that
+ there's a subtle difference in the way name lookup works for functions
+ declared inside a class (as friends) and outside, so keeping them
+ together in the class is probably a good idea for practical as well as
+ aesthetic reasons.
+
+ I hope all this is some help to anyone who needs to write their own
+ STL-like containers and iterators.
+
+ --
+ Ross Smith <ross.s at ihug.co.nz> The Internet Group, Auckland, New Zealand
+ </pre>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="seealso">See Also
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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.aw.com/product/0,2627,0201924889,00.html">Effective C++</a> by Scott Meyers. There is an online version of the book (only some chapters though) <a href="http://www.awlonline.com/cseng/meyerscddemo/">available as well</a>.
+ <li><a href="http://cseng.aw.com/book/0,3828,0201633620,00.html">Large-Scale C++ Software Design</a> by John Lakos
+ </ol><p>
+
+ If you get some free time, and you haven't read them: do so, you might learn
+ something. :)
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <font size=-1>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
+ <!-- hhmts start -->
+ Last modified: Sun Oct 12 22:12:43 CDT 2003
+ <!-- hhmts end -->
+ </font>
+ </body></html>
Index: llvm-www/releases/1.0/CommandLine.html
diff -c /dev/null llvm-www/releases/1.0/CommandLine.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/CommandLine.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,1540 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>CommandLine 2.0 Library Manual</title></head>
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>CommandLine 2.0 Library Manual</b></font></td>
+ </tr></table>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a>
+ <li><a href="#quickstart">Quick Start Guide</a>
+ <ol>
+ <li><a href="#bool">Boolean Arguments</a>
+ <li><a href="#alias">Argument Aliases</a>
+ <li><a href="#onealternative">Selecting an alternative from a
+ set of possibilities</a>
+ <li><a href="#namedalternatives">Named alternatives</a>
+ <li><a href="#list">Parsing a list of options</a>
+ <li><a href="#description">Adding freeform text to help output</a>
+ </ol>
+ <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><a href="#cl::ConsumeAfter">The <tt>cl::ConsumeAfter</tt>
+ modifier</a>
+ </ul>
+ <li><a href="#storage">Internal vs External Storage</a>
+ <li><a href="#attributes">Option Attributes</a>
+ <li><a href="#modifiers">Option Modifiers</a>
+ <ul>
+ <li><a href="#hiding">Hiding an option from <tt>--help</tt> output</a>
+ <li><a href="#numoccurances">Controlling the number of occurances
+ required and allowed</a>
+ <li><a href="#valrequired">Controlling whether or not a value must be
+ specified</a>
+ <li><a href="#formatting">Controlling other formatting options</a>
+ <li><a href="#misc">Miscellaneous option modifiers</a>
+ </ul>
+ <li><a href="#toplevel">Top-Level Classes and Functions</a>
+ <ul>
+ <li><a href="#cl::ParseCommandLineOptions">The
+ <tt>cl::ParseCommandLineOptions</tt> function</a>
+ <li><a href="#cl::ParseEnvironmentOptions">The
+ <tt>cl::ParseEnvironmentOptions</tt> function</a>
+ <li><a href="#cl::opt">The <tt>cl::opt</tt> class</a>
+ <li><a href="#cl::list">The <tt>cl::list</tt> class</a>
+ <li><a href="#cl::alias">The <tt>cl::alias</tt> class</a>
+ </ul>
+ <li><a href="#builtinparsers">Builtin parsers</a>
+ <ul>
+ <li><a href="#genericparser">The Generic <tt>parser<t></tt>
+ parser</a>
+ <li><a href="#boolparser">The <tt>parser<bool></tt>
+ specialization</a>
+ <li><a href="#stringparser">The <tt>parser<string></tt>
+ specialization</a>
+ <li><a href="#intparser">The <tt>parser<int></tt>
+ specialization</a>
+ <li><a href="#doubleparser">The <tt>parser<double></tt> and
+ <tt>parser<float></tt> specializations</a>
+ </ul>
+ </ol>
+ <li><a href="#extensionguide">Extension Guide</a>
+ <ol>
+ <li><a href="#customparser">Writing a custom parser</a>
+ <li><a href="#explotingexternal">Exploiting external storage</a>
+ <li><a href="#dynamicopts">Dynamically adding command line options</a>
+ </ol>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></b><p>
+ </ol><p>
+
+
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="introduction">Introduction
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ 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).<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ <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...<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ <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>.<p>
+
+ </ol>
+
+ 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>
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="quickstart">Quick Start Guide
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ To start out, you need to include the CommandLine header file into your
+ program:<p>
+
+ <pre>
+ #include "Support/CommandLine.h"
+ </pre><p>
+
+ Additionally, you need to add this as the first line of your main program:<p>
+
+ <pre>
+ int main(int argc, char **argv) {
+ <a href="#cl::ParseCommandLineOptions">cl::ParseCommandLineOptions</a>(argc, argv);
+ ...
+ }
+ </pre><p>
+
+ ... which actually parses the arguments and fills in the variable
+ declarations.<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 argument 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>
+
+ <pre><a name="value_desc_example">
+ <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><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>
+
+ 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>
+
+ <pre>
+ USAGE: compiler [options]
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ <b>-o <filename> - Specify output filename</b>
+ </pre>
+
+ 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>
+
+ <pre>
+ ...
+ ofstream Output(OutputFilename.c_str());
+ if (Out.good()) ...
+ ...
+ </pre><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>
+
+
+ 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>
+
+ <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>
+
+ 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>
+
+ <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>
+
+ Again, the CommandLine library does not require the options to be specified in
+ any particular order, so the above declaration is equivalent to:<p>
+
+ <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>
+
+ 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>
+
+ <pre>
+ USAGE: compiler [options] <b><input file></b>
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ -o <filename> - Specify output filename
+ </pre>
+
+ ... indicating that an input filename is expected.<p>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="bool">Boolean Arguments
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ <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><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>
+
+ 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>
+
+ <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>
+
+ ... 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>
+
+ With the declarations above, "<tt>compiler --help</tt>" emits this:<p>
+
+ <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><p>
+
+ and "<tt>opt --help-hidden</tt>" prints this:<p>
+
+ <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><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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="alias">Argument Aliases
+ </b></font></td></tr></table><ul>
+
+ So far, the example works well, except for the fact that we need to check the
+ quiet condition like this now:<p>
+
+ <pre>
+ ...
+ if (!Quiet && !Quiet2) printInformationalMessage(...);
+ ...
+ </pre><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>
+
+ <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><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>
+
+ Now the application code can simply use:<p>
+
+ <pre>
+ ...
+ if (!Quiet) printInformationalMessage(...);
+ ...
+ </pre><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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="onealternative">Selecting an alternative from a set of possibilities
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ 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, are
+ requires you to tell it what this mapping should be.<p>
+
+ Lets say that we would like to add four optimizations 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>opt -O3 -O2</tt>". The CommandLine library would not be able to catch this
+ erroneous input for us.
+
+ <li>We would have to test 4 different variables to see which ones are set.
+
+ <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.
+
+ </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>
+
+ <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>"),
+ 0));
+
+ ...
+ if (OptimizationLevel >= O2) doPartialRedundancyElimination(...);
+ ...
+ </pre><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>0</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>
+
+ <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>
+
+ 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>
+
+ <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>"),
+ 0));
+
+ ...
+ if (OptimizationLevel == Debug) outputDebugInfo(...);
+ ...
+ </pre><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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="namedalternatives">Named Alternatives
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ <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>"),
+ 0));
+ </pre>
+
+ 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>
+
+ <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><p>
+
+ Again, the only structural difference between the debug level declaration and
+ the optimiation 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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="list">Parsing a list of options
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ <pre>
+ enum Opts {
+ // 'inline' is a C++ keyword, so name it 'inlining'
+ dce, constprop, inlining, strip
+ };
+ </pre><p>
+
+ Then define your "<tt><a href="#cl::list">cl::list</a></tt>" variable:<p>
+
+ <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>"),
+ 0));
+ </pre><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>
+
+ <pre>
+ for (unsigned i = 0; i != OptimizationList.size(); ++i)
+ switch (OptimizationList[i])
+ ...
+ </pre>
+
+ ... to iterate through the list of options specified.<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>
+
+ <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><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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="description">Adding freeform text to help output
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ <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><p>
+
+ Would yield the help output:
+
+ <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><p>
+
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="referenceguide">Reference Guide
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="positional">Positional Arguments
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ <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>
+
+ Given these two option declarations, the <tt>--help</tt> output for our grep
+ replacement would look like this:<p>
+
+ <pre>
+ USAGE: spiffygrep [options] <b><regular expression> <input file></b>
+
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ </pre>
+
+ ... and the resultant program could be used just like the standard <tt>grep</tt>
+ tool.<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 they 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>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="--"><h4><hr size=0>Specifying positional options with hyphens</h4><ul>
+
+ 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>
+
+ <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><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>
+
+ <pre>
+ $ spiffygrep -- -foo test.txt
+ ...output...
+ </pre><p>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="cl::ConsumeAfter"><h4><hr size=0>The <tt>cl::ConsumeAfter</tt> modifier</h4><ul>
+
+ 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>
+
+ 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>
+
+ <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><p>
+
+ which automatically provides the help output:<p>
+
+ <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><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>
+
+ 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, and the <tt>cl::ConsumeAfter</tt> option should be a <a
+ href="#cl::list">cl::list</a> option.<p>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="storage">Internal vs External Storage
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ 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>
+
+ To do this, set up your .h file with your option, like this for example:<p>
+
+ <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. Example:
+ //
+ // DEBUG(cerr << "Bitset contains: " << Bitset << "\n");
+ //</i>
+ <font color=red>#ifdef NDEBUG
+ #define DEBUG(X)
+ #else
+ #define DEBUG(X)</font> \
+ do { if (DebugFlag) { X; } } while (0)
+ <font color=red>#endif</font>
+ </pre>
+
+ 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 additial 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>
+
+ <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>, <a href="#cl::Hidden">cl::Hidden</a>,
+ <a href="#cl::location">cl::location</a>(DebugFlag));
+ </pre>
+
+ In the above example, we specify "<tt>true</tt>" as the second argument to the
+ <a href="#cl::opt">cl::opt</a> template, indicating that the template should not
+ maintain a copy of the value itself. In addition to this, we specify the <a
+ href="#cl::location">cl::location</a> attribute, so that <tt>DebugFlag</tt> is
+ automatically set.<p>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="attributes">Option Attributes
+ </b></font></td></tr></table><ul>
+
+ 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:<p>
+
+ <pre>
+ <a href="#cl::opt">cl::opt</a><<b>bool</b>> Quiet("<i>quiet</i>");
+ </pre><p>
+
+ <li><a name="cl::desc">The <b><tt>cl::desc</tt></b> attribute specifies a
+ description for the option to be shown in the <tt>--help</tt> output for the
+ program.<p>
+
+ <li><a name="cl::value_desc">The <b><tt>cl::value_desc</tt></b> 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.<p>
+
+ <li><a name="cl::init">The <b><tt>cl::init</tt></b> 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.)<p>
+
+ <li><a name="cl::location">The <b><tt>cl::location</tt></b> 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.<p>
+
+ <li><a name="cl::aliasopt">The <b><tt>cl::aliasopt</tt></b> attribute specifies
+ which option a <a href="#cl::alias">cl::alias</a> option is an alias for.<p>
+
+ <li><a name="cl::values">The <b><tt>cl::values</tt></b> attribute specifies the
+ string-to-value mapping to be used by the generic parser. It takes a <b>null
+ 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:<p>
+ <ol>
+ <li><a name="clEnumVal">The <b><tt>clEnumVal</tt></b> 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.<p> <li><a
+ name="clEnumValN">The <b><tt>clEnumValN</tt></b> 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.<p>
+ </ol>
+
+ You will get a compile time error if you try to use cl::values with a parser
+ that does not support it.<p>
+
+ </ul>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="modifiers">Option Modifiers
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ These options fall into five main catagories:<p>
+
+ <ol>
+ <li><a href="#hiding">Hiding an option from <tt>--help</tt> output</a>
+ <li><a href="#numoccurances">Controlling the number of occurances
+ required and allowed</a>
+ <li><a href="#valrequired">Controlling whether or not a value must be
+ specified</a>
+ <li><a href="#formatting">Controlling other formatting options</a>
+ <li><a href="#misc">Miscellaneous option modifiers</a>
+ </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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="hiding"><h4><hr size=0>Hiding an option from <tt>--help</tt> output</h4><ul>
+
+ 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>
+
+ <a name="cl::NotHidden">The <b><tt>cl::NotHidden</tt></b> 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.<p>
+
+ <a name="cl::Hidden">The <b><tt>cl::Hidden</tt></b> 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.<p>
+
+ <a name="cl::ReallyHidden">The <b><tt>cl::ReallyHidden</tt></b> modifier,
+ indicates that the option should not appear in any help output.<p>
+ </ul>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="numoccurances"><h4><hr size=0>Controlling the number of occurances required and allowed</h4><ul>
+
+ 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>
+
+ The allowed values for this option group are:<p>
+
+ <ul>
+ <a name="cl::Optional">The <b><tt>cl::Optional</tt></b> 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 occurance of the option to be specified.<p>
+
+ <a name="cl::ZeroOrMore">The <b><tt>cl::ZeroOrMore</tt></b> 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.<p>
+
+ <a name="cl::Required">The <b><tt>cl::Required</tt></b> modifier indicates that
+ the specified option must be specified exactly one time.<p>
+
+ <a name="cl::OneOrMore">The <b><tt>cl::OneOrMore</tt></b> modifier indicates
+ that the option must be specified at least one time.<p>
+
+ The <b><tt>cl::ConsumeAfter</tt></b> modifier is described in the <a
+ href="#positional">Positional arguments section</a><p>
+
+ </ul>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="valrequired"><h4><hr size=0>Controlling whether or not a value must be specified</h4><ul>
+
+ 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>
+
+ The allowed values for this option group are:<p>
+
+ <ul>
+ <a name="cl::ValueOptional">The <b><tt>cl::ValueOptional</tt></b> 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.<p>
+
+ <a name="cl::ValueRequired">The <b><tt>cl::ValueRequired</tt></b> 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.<p>
+
+ <a name="cl::ValueDisallowed">The <b><tt>cl::ValueDisallowed</tt></b> 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>').<p>
+
+ </ul>
+
+ 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>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="formatting"><h4><hr size=0>Controlling other formatting options</h4><ul>
+
+ 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 at most one of these arguments.<p>
+
+ <ul>
+ <a name="cl::NormalFormatting">The <b><tt>cl::NormalFormatting</tt></b> modifier
+ (which is the default all options) specifies that this option is "normal".<p>
+
+ <a name="cl::Positional">The <b><tt>cl::Positional</tt></b> 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.<p>
+
+ 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>.<p>
+
+
+ <a name="cl::Prefix">The <b><tt>cl::Prefix</tt></b> modifier specifies that this
+ option prefixes its value. With 'Prefix' options, there is no equal sign that
+ separates the value from the option name specified. This is useful for
+ processing odd arguments like '<tt>-lmalloc -L/usr/lib'</tt> in a linker tool.
+ Here, the '<tt>l</tt>' and '<tt>L</tt>' options are normal string (list)
+ options, that have the <a href="#cl::Prefix">cl::Prefix</a> modifier added to
+ allow the CommandLine library to recognize them. Note that <a
+ href="#cl::Prefix">cl::Prefix</a> options must not have the <a
+ href="#cl::ValueDisallowed">cl::ValueDisallowed</a> modifier specified.<p>
+
+ <a name="cl::Grouping">The <b><tt>cl::Grouping</tt></b> 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 <a href="#cl::Grouping">cl::Grouping</a> options cannot have
+ values.<p>
+
+ </ul>
+
+ The CommandLine library does not restrict how you use the <a
+ href="#cl::Prefix">cl::Prefix</a> or <a href="#cl::Grouping">cl::Grouping</a>
+ 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>
+
+ 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>
+
+ <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>
+ </tt>
+
+ </ol>
+ <tt>}</tt><p>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="misc"><h4><hr size=0>Miscellaneous option modifiers</h4><ul>
+
+ 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>
+
+ <a name="cl::CommaSeparated">The <b><tt>cl::CommaSeparated</tt></b> 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).<p>
+ </ul>
+
+ So far, the only miscellaneous option modifier is the
+ <tt>cl::CommaSeparated</tt> modifier.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="toplevel">Top-Level Classes and Functions
+ </b></font></td></tr></table><ul>
+
+ Despite all of the builtin 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="cl::ParseCommandLineOptions"><h4><hr size=0>The
+ <tt>cl::ParseCommandLineOptions</tt> function</h4><ul>
+
+ 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>
+
+ 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.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="cl::ParseEnvironmentOptions"><h4><hr size=0>The
+ <tt>cl::ParseEnvironmentOptions</tt> function</h4><ul>
+
+ 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 not 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>
+
+ It takes three parameters: first, the name of the program (since <tt>argv</tt>
+ may not be available, it can't just look in <tt>argv[0]</tt>), second,
+ the name of the environment variable to examine, and third, the optional
+ <a href="#description">additional extra text</a> to emit when the
+ <tt>--help</tt> option is invoked.<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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="cl::opt"><h4><hr size=0>The <tt>cl::opt</tt> class</h4><ul>
+
+ 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>
+
+ <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><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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="cl::list"><h4><hr size=0>The <tt>cl::list</tt> class</h4><ul>
+
+ 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>
+
+ <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><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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="cl::alias"><h4><hr size=0>The <tt>cl::alias</tt> class</h4><ul>
+
+ The <tt>cl::alias</tt> class is a nontemplated class that is used to form
+ aliases for other arguments.<p>
+
+ <pre>
+ <b>namespace</b> cl {
+ <b>class</b> alias;
+ }
+ </pre></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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="builtinparsers">Builtin parsers
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ 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>
+
+ <li><a name="genericparser">The <b>generic <tt>parser<t></tt> parser</b>
+ 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.<p>
+
+ <li><a name="boolparser">The <b><tt>parser<bool></tt> specialization</b>
+ 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>".<p>
+
+ <li><a name="stringparser">The <b><tt>parser<string></tt> specialization</b> simply stores the parsed string into the string value specified. No conversion or modification of the data is performed.<p>
+
+ <li><a name="intparser">The <b><tt>parser<int></tt> specialization</b>
+ 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>'.<p>
+
+ <li><a name="doubleparser">The <b><tt>parser<double></tt></b> 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.
+ <p>
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0><tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="extensionguide">Extension Guide
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF"
+ face="Georgia,Palatino"><b> <a name="customparser">Writing a custom parser
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ There are two ways to use a new parser:<p>
+
+ <ol>
+ <li>Specialize the <a href="#genericparser"><tt>cl::parser</tt></a> template for
+ your custom data type.<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 fundemental data type is something that is already
+ supported.<p>
+
+ <li>Write an independent class, using it explicitly from options that need
+ it.<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>
+
+ </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>
+
+ To start out, we declare our new <tt>FileSizeParser</tt> class:<p>
+
+ <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><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>
+
+ 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>
+
+ <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><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>
+
+ <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><p>
+
+ Which adds this to the output of our program:<p>
+
+ <pre>
+ OPTIONS:
+ -help - display available options (--help-hidden for more)
+ ...
+ <b>-max-file-size=<size> - Maximum file size to accept</b>
+ </pre><p>
+
+ And we can test that our parse works correctly now (the test program just prints
+ out the max-file-size argument value):<p>
+
+ <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><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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF"
+ face="Georgia,Palatino"><b> <a name="explotingexternal">Exploiting external
+ storage </b></font></td></tr></table><ul>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF"
+ face="Georgia,Palatino"><b> <a name="dynamicopts">Dynamically adding command
+ line options </b></font></td></tr></table><ul>
+
+
+
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr>
+ <font size=-1>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
+ <!-- hhmts start -->
+ Last modified: Fri Aug 1 16:30:11 CDT 2003
+ <!-- hhmts end -->
+ </font>
+ </body></html>
Index: llvm-www/releases/1.0/DSGraphStatus.html
diff -c /dev/null llvm-www/releases/1.0/DSGraphStatus.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/DSGraphStatus.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,885 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>Data Structure Graph Analysis Status Page</title></head>
+
+ <body><h1>Data Structure Graph Analysis Status Page</h1>
+
+ This page records information and the progress the data structure analysis
+ passes have been making. Times are in seconds, sizes are #bytes allocated for a
+ particular pass. Runs that are all '*'d out were not completed because they
+ were taking too long (time listed show how long I waited).<p>
+
+ Fields that appear in bold have changes from the last entry on the page.
+ Floating point entries are only highlighted if they change significantly from
+ their previous value.<p>
+
+ <hr>
+ <a name="20021113"><h2>Nov 14, 2002:</h2>
+
+ Some fine tuning happened here. The DSNode object was shrunk by a little bit,
+ lowering memory consumption. The type merging code now ignores access to
+ structure fields when checking compatibility, reducing node collapses and
+ increasing memory consumption in some cases. This table also includes data for
+ the number of indirect call sites, and the number of indirect call targets. The
+ final column is the average number of call targets per indirect call site.<p>
+
+ <pre>
+ Name: Anlyz: LocTm: BUTim: TDTim: TimeSum: BCTime: LocSize: BUSize: TDSize: BUTDSz: BCSize: NumFold NumNodes MaxSz GlobGr MaxSCC | Loads Store Calls Allca Mallc Sum | num/ind indcallee ratio
+ 254.gap 0.6627 0.1810 0.6627 0.4697 1.3134 0.6080 | 2024800 2822584 2018424 4841008 16585864 | 2076 24032+3948 268 0+0 20 | 18420 3888 5805 87 3 28203 | 11 11 1
+ 255.vortex 0.3589 0.1648 0.3589 0.6751 1.1988 0.4810 | 1381200 1259752 2001576 3261328 11694840 | 1038 7343+2842 166 0+0 38 | 13901 6136 6829 1420 2 28288 | 6 95 15.8333
+ 300.twolf 0.0690 0.0663 0.0690 0.1151 0.2504 0.2424 | 466600 392384 400272 792656 7054760 | 95 4144+784 215 0+0 1 | 11246 2911 1865 114 3 16139 | 269 269 1
+ 197.parser 0.0481 0.0305 0.0481 0.0479 0.1265 0.1291 | 281184 225008 212296 437304 4409632 | 338 2257+707 97 0+0 3 | 2611 908 1651 25 2 5197 | 2 4 2
+ burg.llvm 0.0265 0.0218 0.0265 0.0389 0.0872 0.1565 | 536960 477848 188472 666320 2997272 | 213 2309+575 98 0+0 2 | 2265 363 1128 44 4 3804 | 8 24 3
+ ptrdist-bc 0.0107 0.0079 0.0107 0.0116 0.0302 0.0354 | 198640 269032 91248 360280 1332992 | 62 680+199 42 0+0 1 | 764 411 425 21 25 1646 | 3 3 1
+ ptrdist-yacr2 0.0100 0.0073 0.0100 0.0078 0.0251 0.0212 | 176112 193048 72296 265344 982896 | * 1036+90 53 0+0 1 | 872 174 289 16 27 1378 | * * n/a
+ 164.gzip.llvm 0.0062 0.0094 0.0062 0.0070 0.0226 0.1029 | 201568 129000 70880 199880 1873760 | 8 971+87 67 0+0 1 | 1014 622 351 19 3 2009 | 9 9 1
+ optimizer-eval.llvm 0.0060 0.0034 0.0060 0.0344 0.0438 0.0145 | 100008 78968 61784 140752 626688 | * 309+41 72 0+0 1 | 278 405 108 32 * 823 | 2 174 87
+ 181.mcf 0.0050 0.0040 0.0050 0.0055 0.0145 0.0195 | 130984 120848 43208 164056 579064 | 46 376+52 83 0+0 1 | 362 225 81 8 2 678 | * * n/a
+ voronoi.llvm 0.0037 0.0028 0.0037 0.0054 0.0119 0.0098 | 63768 82584 48808 131392 413304 | 3 307+77 58 0+0 1 | 399 171 121 44 4 739 | * * n/a
+ 256.bzip2 0.0030 0.0060 0.0030 0.0025 0.0115 0.0907 | 138536 83624 39760 123384 1363416 | * 563+37 59 0+0 1 | 698 307 287 18 10 1320 | 2 2 1
+ sgefa.llvm 0.0028 0.0019 0.0028 0.0029 0.0076 0.0080 | 85680 81992 67056 149048 372736 | * 130+24 36 0+0 1 | 159 65 77 5 5 311 | 1 1 1
+ sim.llvm 0.0022 0.0032 0.0022 0.0026 0.008 0.0193 | 54952 81152 21976 103128 737584 | * 261+36 60 0+0 1 | 687 305 75 2 21 1090 | * * n/a
+ bh.llvm 0.0021 0.0025 0.0021 0.0019 0.0065 0.0113 | 75656 51520 27768 79288 470680 | 38 194+35 23 0+0 1 | 266 189 151 36 3 645 | 2 2 1
+ ptrdist-ft 0.0019 0.0020 0.0019 0.0021 0.006 0.0115 | 46336 58552 15464 74016 502704 | * 192+42 19 0+0 1 | 147 80 96 1 5 329 | 6 6 1
+ ptrdist-ks 0.0017 0.0028 0.0017 0.0017 0.0062 0.0089 | 48792 44664 31304 75968 381528 | * 215+30 36 0+0 1 | 155 87 88 2 6 338 | * * n/a
+ ptrdist-anagram 0.0014 0.0017 0.0014 0.0012 0.0043 0.0079 | 43400 41992 14864 56856 409312 | 5 196+28 20 0+0 1 | 105 77 60 5 3 250 | 3 3 1
+ em3d.llvm 0.0013 0.0012 0.0013 0.0010 0.0035 0.0056 | 24256 43304 13024 56328 223952 | 1 178+28 21 0+0 1 | 114 41 71 * 12 238 | 3 8 2.66666
+ health.llvm 0.0012 0.0010 0.0012 0.0013 0.0035 0.0070 | 32064 31992 12720 44712 202312 | 3 97+31 13 0+0 1 | 85 72 47 5 3 212 | * * n/a
+ lists.llvm 0.0010 0.0008 0.0010 0.0015 0.0033 0.0033 | 24968 22808 6640 29448 139832 | * 67+26 28 0+0 1 | 40 31 53 * 3 127 | * * n/a
+ mst.llvm 0.0008 0.0008 0.0008 0.0007 0.0023 0.0044 | 18944 15584 16680 32264 183080 | 4 97+15 13 0+0 1 | 55 36 42 5 5 143 | 2 2 1
+ hash.llvm 0.0008 0.0006 0.0008 0.0008 0.0022 0.0035 | 17504 26464 8208 34672 150160 | * 117+17 19 0+0 1 | 35 25 25 1 4 90 | * * n/a
+ tsp.llvm 0.0007 0.0009 0.0007 0.0005 0.0021 0.0042 | 18416 15024 5408 20432 183312 | * 42+15 7 0+0 1 | 54 61 64 * 1 180 | * * n/a
+ power.llvm 0.0007 0.0008 0.0007 0.0007 0.0022 0.0050 | 19704 18880 18120 37000 212104 | * 81+18 11 0+0 1 | 141 86 46 11 4 288 | * * n/a
+ perimeter.llvm 0.0007 0.0006 0.0007 0.0004 0.0017 0.0035 | 14944 13072 3936 17008 155240 | * 35+15 7 0+0 1 | 30 25 49 * 1 105 | * * n/a
+ bisort.llvm 0.0005 0.0006 0.0005 0.0003 0.0014 0.0032 | 13480 11608 3704 15312 124416 | * 35+13 7 0+0 1 | 37 24 40 * 1 102 | * * n/a
+ objinst.llvm 0.0004 0.0004 0.0004 0.0005 0.0013 0.0028 | 11360 11008 12288 23296 86552 | 7 53+14 19 0+0 1 | 18 11 19 * 2 50 | * * n/a
+ methcall.llvm 0.0004 0.0004 0.0004 0.0006 0.0014 0.0026 | 10280 9816 9128 18944 86632 | 17 45+12 15 0+0 1 | 18 11 16 * 2 47 | 1 3 3
+ treeadd.llvm 0.0003 0.0003 0.0003 0.0002 0.0008 0.0019 | 8712 7568 2216 9784 70776 | * 25+7 7 0+0 1 | 15 6 18 * 1 40 | * * n/a
+ matrix.llvm 0.0003 0.0003 0.0003 0.0003 0.0009 0.0019 | 3840 15744 3064 18808 69184 | * 38+9 12 0+0 1 | 21 4 11 * 2 38 | * * n/a
+ llubenchmark.llvm 0.0003 0.0005 0.0003 0.0003 0.0011 0.0028 | 11016 9448 2616 12064 123384 | * 31+7 15 0+0 1 | 29 9 26 * 2 66 | * * n/a
+ ary3.llvm 0.0003 0.0003 0.0003 0.0002 0.0008 0.0018 | 8832 12584 3008 15592 71432 | 4 44+5 17 0+0 1 | 10 14 7 * 1 32 | * * n/a
+ sumarraymalloc.llvm 0.0002 0.0005 0.0002 0.0002 0.0009 0.0016 | 7032 2680 2064 4744 54544 | * 23+5 7 0+0 1 | 8 2 8 * 1 19 | * * n/a
+ sieve.llvm 0.0002 0.0002 0.0002 0.0006 0.001 0.0032 | 5704 1944 1616 3560 216328 | * 22+2 12 0+0 1 | 7 3 4 * * 14 | * * n/a
+ random.llvm 0.0002 0.0002 0.0002 0.0001 0.0005 0.0014 | 2056 7176 1312 8488 46680 | * 15+2 7 0+0 1 | 8 2 6 * * 16 | * * n/a
+ heapsort.llvm 0.0002 0.0003 0.0002 0.0001 0.0006 0.0016 | 2856 6976 1992 8968 63368 | * 26+3 7 0+0 1 | 14 7 6 * 1 28 | * * n/a
+ fib2.llvm 0.0002 0.0002 0.0002 0.0001 0.0005 0.0014 | 5744 6168 1632 7800 42448 | * 21+5 8 0+0 1 | 6 1 7 * * 14 | * * n/a
+ ackermann.llvm 0.0002 0.0002 0.0002 0.0001 0.0005 0.0013 | 1744 1536 1192 2728 47528 | * 13+2 7 0+0 1 | 6 1 6 * * 13 | * * n/a
+ sumarray.llvm 0.0001 0.0001 0.0001 0.0000 0.0002 0.0007 | 912 624 632 1256 15112 | * 6+1 4 0+0 1 | 1 3 2 * 1 7 | * * n/a
+ sumarray2d.llvm 0.0001 0.0001 0.0001 0.0001 0.0003 0.0009 | 1576 3656 848 4504 22544 | * 10+1 7 0+0 1 | 1 2 3 1 * 7 | * * n/a
+ printargs.llvm 0.0001 0.0001 0.0001 0.0001 0.0003 0.0007 | 3712 1048 704 1752 19104 | * 6+1 4 0+0 1 | 4 * 5 * * 9 | * * n/a
+ pi.llvm 0.0001 0.0002 0.0001 0.0001 0.0004 0.0011 | 2368 4720 4736 9456 35208 | * 17+2 13 0+0 1 | 7 3 7 2 * 19 | * * n/a
+ matrixTranspose.llvm 0.0001 0.0002 0.0001 0.0001 0.0004 0.0013 | 1392 4128 736 4864 69720 | * 8+1 5 0+0 1 | 6 5 4 * * 15 | * * n/a
+ indvars.llvm 0.0001 0.0002 0.0001 0.0001 0.0004 0.0010 | 4752 1072 1024 2096 31536 | * 13+1 8 0+0 1 | 2 6 3 1 * 12 | * * n/a
+ hello.llvm 0.0000 0.0001 0.0000 0.0000 0.0001 0.0006 | 752 472 472 944 14112 | * 2+0 2 0+0 1 | 3 * 4 * * 7 | * * n/a
+ </pre><p>
+
+ <hr>
+ <a name="20021113"><h2>Nov 13, 2002:</h2>
+
+ New numbers, same as last time, just some extra columns on the end:<p>
+
+ This data set also includes new data for the ptrdist benchmark.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TimeSum: BCTime: LocSize: BUSize: TDSize: BUTDSz: BCSize: NumFold NumNodes MaxSz GlobGr MaxSCC | Loads Store Calls Allca Mallc Sum
+ 254.gap 4.39 0.1773 0.6581 0.4703 1.3057 0.6054 | 2024952 2823064 2018920 4841984 16585864 | 2080 24032+3948 268 0+0 20 | 18420 3888 5805 87 3 28203
+ 255.vortex 4.03 0.1154 0.3172 0.6416 1.0742 0.4523 | 1381344 1261232 1997512 3258744 11694840 | 1043 7331+2844 166 0+0 38 | 13901 6136 6829 1420 2 28288
+ 300.twolf 0.80 0.0557 0.0593 0.1062 0.2212 0.2191 | 466544 391432 394760 786192 7054760 | 115 4127+784 215 0+0 1 | 11246 2911 1865 114 3 16139
+ 197.parser 0.44 0.0302 0.0403 0.0442 0.1147 0.1204 | 280960 224800 212168 436968 4409632 | 338 2255+706 97 0+0 3 | 2611 908 1651 25 2 5197
+ burg.llvm 0.33 0.0208 0.0268 0.0356 0.0832 0.1293 | 536552 478856 185880 664736 2997272 | 205 2273+576 98 0+0 2 | 2265 363 1128 44 4 3804
+ 164.gzip.llvm 0.20 0.0093 0.0062 0.0073 0.0228 0.0999 | 201568 129000 70880 199880 1873760 | 8 971+87 67 0+0 1 | 1014 622 351 19 3 2009
+ ptrdist-bc 0.12 0.0080 0.0111 0.0132 0.0323 0.0304 | 198640 269032 91232 360264 1332992 | 62 680+199 42 0+0 1 | 764 411 425 21 25 1646
+ 256.bzip2 0.11 0.0057 0.0028 0.0024 0.0109 0.0462 | 138536 83624 39760 123384 1363416 | * 563+37 59 0+0 1 | 698 307 287 18 10 1320
+ optimizer-eval.llvm 0.10 0.0033 0.0064 0.0304 0.0401 0.0133 | 100008 78968 61784 140752 626688 | * 309+41 72 0+0 1 | 278 405 108 32 * 823
+ ptrdist-yacr2 0.09 0.0075 0.0097 0.0084 0.0256 0.0211 | 176112 193048 72296 265344 982896 | * 1036+90 53 0+0 1 | 872 174 289 16 27 1378
+ 181.mcf 0.09 0.0081 0.0051 0.0054 0.0186 0.0216 | 130816 121096 43648 164744 579064 | 44 388+51 83 0+0 1 | 362 225 81 8 2 678
+ sgefa.llvm 0.08 0.0019 0.0026 0.0029 0.0074 0.0081 | 85680 81992 67056 149048 372736 | * 130+24 36 0+0 1 | 159 65 77 5 5 311
+ voronoi.llvm 0.06 0.0028 0.0037 0.0053 0.0118 0.0097 | 63768 82416 51856 134272 413304 | 11 299+77 58 0+0 1 | 399 171 121 44 4 739
+ sim.llvm 0.06 0.0032 0.0022 0.0025 0.0079 0.0162 | 54952 81152 21976 103128 737584 | * 261+36 60 0+0 1 | 687 305 75 2 21 1090
+ bh.llvm 0.06 0.0025 0.0021 0.0023 0.0069 0.0116 | 75656 51520 27768 79288 470680 | 38 194+35 23 0+0 1 | 266 189 151 36 3 645
+ ptrdist-ft 0.05 0.0020 0.0019 0.0021 0.006 0.0113 | 46336 58552 15464 74016 502704 | * 192+42 19 0+0 1 | 147 80 96 1 5 329
+ em3d.llvm 0.05 0.0012 0.0012 0.0011 0.0035 0.0056 | 24256 43304 13024 56328 223952 | 1 178+28 21 0+0 1 | 114 41 71 * 12 238
+ ptrdist-ks 0.04 0.0023 0.0016 0.0017 0.0056 0.0081 | 48792 44664 31304 75968 381528 | * 215+30 36 0+0 1 | 155 87 88 2 6 338
+ ptrdist-anagram 0.04 0.0016 0.0014 0.0025 0.0055 0.0079 | 43400 41992 14864 56856 409312 | 5 196+28 20 0+0 1 | 105 77 60 5 3 250
+ mst.llvm 0.04 0.0008 0.0007 0.0007 0.0022 0.0044 | 18944 15584 16680 32264 183080 | 4 97+15 13 0+0 1 | 55 36 42 5 5 143
+ health.llvm 0.04 0.0010 0.0012 0.0017 0.0039 0.0070 | 32064 31992 12720 44712 202312 | 3 97+31 13 0+0 1 | 85 72 47 5 3 212
+ tsp.llvm 0.03 0.0009 0.0006 0.0005 0.002 0.0041 | 18416 14504 4872 19376 183312 | 9 42+15 7 0+0 1 | 54 61 64 * 1 180
+ treeadd.llvm 0.03 0.0003 0.0003 0.0002 0.0008 0.0019 | 8712 7568 2216 9784 70776 | * 25+7 7 0+0 1 | 15 6 18 * 1 40
+ sieve.llvm 0.03 0.0002 0.0002 0.0001 0.0005 0.0032 | 5704 1944 1616 3560 216328 | * 22+2 12 0+0 1 | 7 3 4 * * 14
+ power.llvm 0.03 0.0008 0.0007 0.0007 0.0022 0.0049 | 19704 18880 18120 37000 212104 | * 81+18 11 0+0 1 | 141 86 46 11 4 288
+ pi.llvm 0.03 0.0002 0.0001 0.0001 0.0004 0.0010 | 2368 4720 4736 9456 35208 | * 17+2 13 0+0 1 | 7 3 7 2 * 19
+ perimeter.llvm 0.03 0.0006 0.0007 0.0004 0.0017 0.0035 | 14944 13072 3936 17008 155240 | * 35+15 7 0+0 1 | 30 25 49 * 1 105
+ objinst.llvm 0.03 0.0005 0.0005 0.0006 0.0016 0.0025 | 11360 16328 4112 20440 86552 | 19 45+14 16 0+0 1 | 18 11 19 * 2 50
+ methcall.llvm 0.03 0.0004 0.0004 0.0006 0.0014 0.0026 | 10280 9752 9040 18792 86632 | 19 43+12 14 0+0 1 | 18 11 16 * 2 47
+ matrixTranspose.llvm 0.03 0.0002 0.0001 0.0002 0.0005 0.0013 | 1392 4128 736 4864 69720 | * 8+1 5 0+0 1 | 6 5 4 * * 15
+ matrix.llvm 0.03 0.0003 0.0003 0.0003 0.0009 0.0019 | 3840 15744 3064 18808 69184 | * 38+9 12 0+0 1 | 21 4 11 * 2 38
+ llubenchmark.llvm 0.03 0.0005 0.0003 0.0003 0.0011 0.0028 | 11016 9448 2616 12064 123384 | * 31+7 15 0+0 1 | 29 9 26 * 2 66
+ lists.llvm 0.03 0.0008 0.0010 0.0014 0.0032 0.0033 | 24968 22552 6128 28680 139832 | 15 67+26 28 0+0 1 | 40 31 53 * 3 127
+ hash.llvm 0.03 0.0006 0.0008 0.0008 0.0022 0.0035 | 17504 26464 8208 34672 150160 | * 117+17 19 0+0 1 | 35 25 25 1 4 90
+ bisort.llvm 0.03 0.0006 0.0005 0.0003 0.0014 0.0029 | 13480 11608 3704 15312 124416 | * 35+13 7 0+0 1 | 37 24 40 * 1 102
+ ary3.llvm 0.03 0.0003 0.0003 0.0002 0.0008 0.0018 | 8832 12584 3008 15592 71432 | 4 44+5 17 0+0 1 | 10 14 7 * 1 32
+ sumarraymalloc.llvm 0.02 0.0002 0.0002 0.0002 0.0006 0.0015 | 7032 2680 2064 4744 54544 | * 23+5 7 0+0 1 | 8 2 8 * 1 19
+ sumarray.llvm 0.02 0.0001 0.0001 0.0000 0.0002 0.0007 | 912 624 632 1256 15112 | * 6+1 4 0+0 1 | 1 3 2 * 1 7
+ sumarray2d.llvm 0.02 0.0001 0.0001 0.0001 0.0003 0.0009 | 1576 3656 848 4504 22544 | * 10+1 7 0+0 1 | 1 2 3 1 * 7
+ random.llvm 0.02 0.0002 0.0002 0.0001 0.0005 0.0014 | 2056 7176 1312 8488 46680 | * 15+2 7 0+0 1 | 8 2 6 * * 16
+ printargs.llvm 0.02 0.0001 0.0001 0.0000 0.0002 0.0008 | 3712 1048 704 1752 19104 | * 6+1 4 0+0 1 | 4 * 5 * * 9
+ indvars.llvm 0.02 0.0002 0.0001 0.0001 0.0004 0.0010 | 4752 1072 1024 2096 31536 | * 13+1 8 0+0 1 | 2 6 3 1 * 12
+ heapsort.llvm 0.02 0.0002 0.0002 0.0001 0.0005 0.0017 | 2856 6976 1992 8968 63368 | * 26+3 7 0+0 1 | 14 7 6 * 1 28
+ fib2.llvm 0.02 0.0002 0.0002 0.0001 0.0005 0.0013 | 5744 6168 1632 7800 42448 | * 21+5 8 0+0 1 | 6 1 7 * * 14
+ ackermann.llvm 0.02 0.0002 0.0002 0.0001 0.0005 0.0017 | 1744 1536 1192 2728 47528 | * 13+2 7 0+0 1 | 6 1 6 * * 13
+ hello.llvm 0.01 0.0001 0.0001 0.0000 0.0002 0.0006 | 752 472 472 944 14112 | * 2+0 2 0+0 1 | 3 * 4 * * 7
+ </pre><p>
+
+ <hr>
+ <a name="20021112-2"><h2>Nov 12, 2002 #2:</h2>
+
+ This build is the same as <a href="#20021112">before</a>, except now this is
+ compiled in release mode (optimizations enabled, assertions off).<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: BCTime: LocSize: BUSize: TDSize: TotSize: BCSize: NumFold NumNodes main __main GlobGr
+ 254.gap.lib 3.43 0.1783 0.6490 0.4676 1.7957 0.5938 | 2024904 2816256 2016824 6857984 16561248 | 5973 24033+3949 44+9 0+0 0+0
+ 255.vortex.lib 3.01 0.1177 0.3156 0.6452 1.5678 0.4652 | 1381488 1260088 2000864 4642440 11691072 | 5851 7324+2837 166+11 0+0 0+0
+ 300.twolf.lib 0.72 0.0547 0.0591 0.1054 0.3435 0.2076 | 466544 391448 394984 1252976 6950016 | 768 4127+784 90+53 0+0 0+0
+ 197.parser.lib 0.38 0.0301 0.0400 0.0448 0.1712 0.1206 | 407728 224960 212368 964008 4442008 | 1332 2256+707 14+6 0+0 0+0
+ burg.llvm.lib 0.31 0.0207 0.0264 0.0359 0.1114 0.1493 | 535720 477752 185808 1265384 2998392 | 754 2273+576 45+7 0+0 0+0
+ 164.gzip.llvm.lib 0.17 0.0089 0.0062 0.0070 0.0400 0.0977 | 201336 128072 135240 561056 1860784 | 24 971+87 8+2 0+0 0+0
+ optimizer-eval.llvm.lib 0.08 0.0033 0.0063 0.0311 0.0528 0.0131 | 101272 79216 61760 242248 624880 | * 309+41 72+27 0+0 0+0
+ 256.bzip2.lib 0.08 0.0056 0.0028 0.0024 0.0242 0.0342 | 139696 84264 39688 335984 1371144 | * 563+37 8+2 0+0 0+0
+ 181.mcf.lib 0.07 0.0038 0.0049 0.0055 0.0345 0.0155 | 109872 142976 43664 313504 585632 | 167 388+51 22+10 0+0 0+0
+ sim.llvm.lib 0.05 0.0031 0.0023 0.0026 0.0187 0.0159 | 55880 51128 21864 225776 728104 | * 260+35 39+22 0+0 0+0
+ voronoi.llvm.lib 0.04 0.0028 0.0037 0.0054 0.0165 0.0098 | 79696 83000 27112 203160 412912 | 18 299+77 15+8 0+0 0+0
+ hash.llvm.lib 0.04 0.0006 0.0008 0.0008 0.0045 0.0038 | 25568 23384 8184 70024 150480 | * 117+17 14+6 0+0 0+0
+ bh.llvm.lib 0.04 0.0025 0.0021 0.0019 0.0118 0.0114 | 75208 51032 27800 202752 482440 | 64 194+35 6+2 0+0 0+0
+ sgefa.llvm.lib 0.03 0.0019 0.0026 0.0028 0.0124 0.0085 | 85856 82224 67032 260752 375800 | * 130+24 24+14 0+0 0+0
+ health.llvm.lib 0.03 0.0010 0.0012 0.0013 0.0077 0.0072 | 30416 30184 12704 80824 197952 | 18 97+31 12+4 0+0 0+0
+ tsp.llvm.lib 0.02 0.0009 0.0006 0.0005 0.0044 0.0044 | 18416 14448 4880 52472 183104 | 22 42+15 7+4 0+0 0+0
+ power.llvm.lib 0.02 0.0008 0.0007 0.0007 0.0049 0.0065 | 19592 27536 7848 63072 218032 | * 81+18 11+2 0+0 0+0
+ perimeter.llvm.lib 0.02 0.0006 0.0006 0.0004 0.0039 0.0035 | 15200 14104 3944 46320 158680 | * 35+15 7+4 0+0 0+0
+ objinst.llvm.lib 0.02 0.0004 0.0004 0.0006 0.0038 0.0026 | 11368 15280 4112 45376 90432 | 32 45+14 16+10 0+0 0+0
+ mst.llvm.lib 0.02 0.0008 0.0008 0.0007 0.0047 0.0046 | 18952 16568 7024 58032 183080 | 10 97+15 12+3 0+0 0+0
+ methcall.llvm.lib 0.02 0.0004 0.0004 0.0005 0.0035 0.0026 | 10944 11088 3928 39584 87008 | 30 43+12 14+8 0+0 0+0
+ llubenchmark.llvm.lib 0.02 0.0005 0.0003 0.0003 0.0037 0.0030 | 11008 9448 2600 33976 123336 | * 31+7 15+5 0+0 0+0
+ lists.llvm.lib 0.02 0.0010 0.0010 0.0014 0.0054 0.0036 | 25352 15608 14344 67520 139752 | 29 67+26 3+1 0+0 0+0
+ em3d.llvm.lib 0.02 0.0011 0.0013 0.0011 0.0063 0.0055 | 24320 32736 12984 86912 224936 | 1 178+28 12+4 0+0 0+0
+ bisort.llvm.lib 0.02 0.0006 0.0005 0.0003 0.0033 0.0030 | 13520 11672 3704 45912 125120 | * 35+13 7+4 0+0 0+0
+ treeadd.llvm.lib 0.01 0.0003 0.0003 0.0002 0.0023 0.0019 | 8064 7512 2200 29880 70776 | * 25+7 6+3 0+0 0+0
+ sumarraymalloc.llvm.lib 0.01 0.0002 0.0002 0.0002 0.0020 0.0015 | 2712 7000 2048 25576 54608 | * 23+5 7+4 0+0 0+0
+ sumarray.llvm.lib 0.01 0.0001 0.0001 0.0001 0.0011 0.0007 | 904 3192 624 4720 15112 | * 6+1 4+1 0+0 0+0
+ sumarray2d.llvm.lib 0.01 0.0002 0.0001 0.0001 0.0013 0.0009 | 1568 3536 848 8176 22504 | * 10+1 7+1 0+0 0+0
+ sieve.llvm.lib 0.01 0.0002 0.0002 0.0001 0.0020 0.0033 | 2152 6144 1616 23240 216328 | * 22+2 12+1 0+0 0+0
+ random.llvm.lib 0.01 0.0002 0.0002 0.0001 0.0017 0.0014 | 7616 1632 1320 23104 46680 | * 15+2 3+1 0+0 0+0
+ printargs.llvm.lib 0.01 0.0001 0.0001 0.0001 0.0011 0.0008 | 1248 1048 704 5144 19104 | * 6+1 4+1 0+0 0+0
+ pi.llvm.lib 0.01 0.0002 0.0001 0.0001 0.0016 0.0011 | 5392 3800 4728 13920 35880 | * 17+2 13+2 0+0 0+0
+ matrixTranspose.llvm.lib 0.01 0.0002 0.0001 0.0001 0.0012 0.0013 | 5800 1144 736 7680 69712 | * 8+1 5+1 0+0 0+0
+ matrix.llvm.lib 0.01 0.0003 0.0003 0.0003 0.0028 0.0018 | 10088 8616 10672 40912 68728 | * 38+9 12+8 0+0 0+0
+ indvars.llvm.lib 0.01 0.0002 0.0001 0.0001 0.0014 0.0010 | 4760 1080 1016 9392 31536 | * 13+1 8+1 0+0 0+0
+ hello.llvm.lib 0.01 0.0001 0.0001 0.0000 0.0009 0.0007 | 752 2952 472 6512 12216 | * 2+0 0+0 0+0 0+0
+ heapsort.llvm.lib 0.01 0.0002 0.0002 0.0001 0.0021 0.0017 | 2856 6968 2008 26672 63368 | * 26+3 7+2 0+0 0+0
+ fib2.llvm.lib 0.01 0.0002 0.0002 0.0001 0.0019 0.0013 | 5696 6136 1640 26200 41992 | * 21+5 8+3 0+0 0+0
+ ary3.llvm.lib 0.01 0.0003 0.0004 0.0002 0.0026 0.0018 | 10264 21184 3008 45968 72576 | 6 44+5 12+3 0+0 0+0
+ ackermann.llvm.lib 0.01 0.0002 0.0002 0.0001 0.0016 0.0014 | 1752 5736 1200 24944 46728 | * 13+2 3+1 0+0 0+0
+ </pre><p>
+
+
+ <hr>
+ <a name="20021112"><h2>Nov 12, 2002:</h2>
+
+ <a
+ href="http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20021111/001567.html">This
+ small change</a> is important to programs with large SCC's. It basically makes
+ sure to inline calls to non-scc functions before we inline <b>any</b> intra-scc
+ calls. The problem is that inlining an SCC call could add <b>more</b> call
+ sites that would slow things down.<p>
+
+ Note that the total time underestimates the improvement. Take a look at the
+ change on BU time/total time to get an accurate accessment. I had some of the
+ graph IO printing code commented out in the last run, which affected Analyze
+ time, but not total time.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: BCTime: LocSize: BUSize: TDSize: TotSize: BCSize: NumFold NumNodes main __main GlobGr
+ 254.gap.lib 17.69 0.8298 4.1158 2.4087 8.9138 2.9912 | 2024984 <b>2840288</b> <b>2024560</b> <b>6889832</b> 16554904 | <b>5985</b> <b>24035+3950</b> 44+9 0+0 0+0
+ 255.vortex.lib 14.99 0.5988 1.8871 3.6557 7.3284 2.4054 | 1381056 <b>1259144</b> <b>1997120</b> <b>4637320</b> 11689312 | <b>5853</b> <b>7328+2841</b> 166+11 0+0 0+0
+ 300.twolf.lib 3.34 0.2774 0.2827 0.5115 1.5475 1.0153 | 466528 391512 396552 1254592 6936728 | 749 4128+784 90+53 0+0 0+0
+ 197.parser.lib 1.85 0.1485 0.3190 0.2156 0.8689 0.6872 | 408392 <b>225184</b> <b>212552</b> <b>965384</b> 4447944 | <b>1343</b> 2257+707 14+6 0+0 0+0
+ burg.llvm.lib 1.22 0.1027 0.1926 0.1739 0.5598 0.4947 | 530600 <b>474592</b> 185792 <b>1190984</b> 3040208 | <b>758</b> 2273+576 45+7 0+0 0+0
+ 164.gzip.llvm.lib 0.74 0.0398 0.0559 0.0350 0.1957 0.4561 | 145952 184776 70872 499912 1876248 | 24 971+87 8+2 0+0 0+0
+ optimizer-eval.llvm.lib 0.43 0.0183 0.0485 0.2054 0.3047 0.0839 | 101184 79456 61760 242400 624688 | * 309+41 72+27 0+0 0+0
+ 256.bzip2.lib 0.34 0.0241 0.0404 0.0113 0.1250 0.1624 | 139504 83400 39712 335144 1373216 | * 563+37 8+2 0+0 0+0
+ 181.mcf.lib 0.23 0.0216 0.0279 0.0301 0.1126 0.0795 | 115448 146520 43680 322864 589440 | 166 388+51 22+10 0+0 0+0
+ sim.llvm.lib 0.20 0.0137 0.0138 0.0131 0.0800 0.0876 | 81632 51496 21872 226584 734152 | * 260+35 39+22 0+0 0+0
+ voronoi.llvm.lib 0.17 0.0139 0.0246 0.0282 0.0811 0.0591 | 79824 84152 27112 204904 420568 | 18 299+77 15+8 0+0 0+0
+ sgefa.llvm.lib 0.16 0.0090 0.0195 0.0201 0.0848 0.0542 | 85688 100456 67024 277864 368680 | * 130+24 24+14 0+0 0+0
+ bh.llvm.lib 0.16 0.0121 0.0164 0.0115 0.0581 0.0682 | 75000 51080 27760 217632 470720 | 61 194+35 6+2 0+0 0+0
+ power.llvm.lib <b>0.13</b> 0.0044 <b>0.0122</b> 0.0037 0.0282 0.0484 | 27776 17688 18144 71424 213760 | * 81+18 11+2 0+0 0+0
+ em3d.llvm.lib 0.11 0.0060 0.0110 0.0059 0.0308 0.0561 | 33040 36256 13008 90632 227520 | 1 178+28 12+4 0+0 0+0
+ health.llvm.lib 0.10 0.0052 <b>0.0203</b> 0.0073 0.0406 0.0421 | 30632 31432 12704 89592 199888 | 18 97+31 12+4 0+0 0+0
+ tsp.llvm.lib 0.07 0.0051 0.0063 0.0027 0.0217 0.0332 | 18232 14336 4920 51888 180744 | 21 43+15 8+4 0+0 0+0
+ mst.llvm.lib 0.07 0.0040 0.0065 0.0037 0.0215 0.0296 | 18624 25576 7040 65808 178832 | 10 97+15 12+3 0+0 0+0
+ lists.llvm.lib 0.07 0.0043 0.0131 0.0071 0.0299 0.0269 | 24552 16920 14440 68024 141480 | 30 67+26 3+1 0+0 0+0
+ fib2.llvm.lib <b>0.07</b> <b>0.0053</b> <b>0.0217</b> 0.0008 <b>0.0313</b> <b>0.0076</b> | 7960 6288 1640 28408 42256 | * 21+5 8+3 0+0 0+0
+ perimeter.llvm.lib 0.06 0.0031 0.0064 0.0021 0.0190 0.0275 | 15016 14192 3936 45912 156352 | * 35+15 7+4 0+0 0+0
+ hash.llvm.lib 0.06 0.0031 0.0050 0.0052 0.0200 0.0211 | 25728 16608 8208 63576 151680 | * 117+17 14+6 0+0 0+0
+ bisort.llvm.lib 0.06 0.0030 0.0055 0.0019 0.0318 <b>0.0126</b> | 13288 11408 3712 39448 127360 | * 35+13 7+4 0+0 0+0
+ sumarraymalloc.llvm.lib 0.04 0.0009 0.0014 0.0009 0.0075 <b>0.0240</b> | 7040 2672 2048 25872 54352 | * 23+5 7+4 0+0 0+0
+ objinst.llvm.lib 0.04 0.0019 0.0050 0.0032 0.0154 <b>0.0100</b> | 11280 15784 4112 45296 89856 | 34 45+14 16+10 0+0 0+0
+ methcall.llvm.lib 0.04 0.0018 0.0047 0.0031 0.0145 <b>0.0122</b> | 11008 9880 3928 38624 87976 | 30 43+12 14+8 0+0 0+0
+ matrix.llvm.lib 0.04 0.0013 0.0021 0.0014 0.0106 <b>0.0198</b> | 8808 8872 3072 33144 69112 | * 38+9 12+8 0+0 0+0
+ llubenchmark.llvm.lib 0.04 0.0024 0.0026 0.0015 0.0142 0.0118 | 11072 11760 2624 36480 124344 | * 31+7 15+5 0+0 0+0
+ heapsort.llvm.lib 0.04 0.0009 0.0019 0.0007 0.0073 <b>0.0137</b> | 2856 6968 2008 26976 63160 | * 26+3 7+2 0+0 0+0
+ ary3.llvm.lib 0.04 0.0013 0.0020 0.0011 0.0090 <b>0.0134</b> | 10240 13104 10888 45832 73064 | 6 44+5 12+3 0+0 0+0
+ ackermann.llvm.lib 0.04 0.0007 0.0015 0.0004 0.0066 0.0262 | 1744 5728 1200 22056 46448 | * 13+2 3+1 0+0 0+0
+ treeadd.llvm.lib 0.03 0.0015 0.0028 0.0010 0.0090 0.0084 | 3856 7384 2200 29784 72064 | * 25+7 6+3 0+0 0+0
+ sieve.llvm.lib 0.03 0.0008 0.0012 0.0006 0.0061 0.0162 | 2176 6176 1632 23432 216840 | * 22+2 12+1 0+0 0+0
+ random.llvm.lib <b>0.03</b> 0.0008 0.0017 0.0004 0.0059 <b>0.0133</b> | 2056 5720 1320 22080 45264 | * 15+2 3+1 0+0 0+0
+ matrixTranspose.llvm.lib 0.03 0.0005 0.0010 0.0003 0.0032 0.0129 | 4272 1144 736 8560 68448 | * 8+1 5+1 0+0 0+0
+ hello.llvm.lib 0.03 0.0004 0.0015 0.0001 0.0066 0.0107 | 752 2952 472 6512 14160 | * 2+0 0+0 0+0 0+0
+ sumarray2d.llvm.lib <b>0.02</b> 0.0005 0.0009 0.0002 0.0034 <b>0.0055</b> | 1568 3584 848 8264 23288 | * 10+1 7+1 0+0 0+0
+ printargs.llvm.lib <b>0.02</b> 0.0004 0.0013 0.0002 0.0032 0.0058 | 1240 1048 696 5128 19160 | * 6+1 4+1 0+0 0+0
+ pi.llvm.lib 0.02 0.0008 0.0021 0.0005 0.0052 0.0036 | 5392 1560 1392 8344 36032 | * 17+2 13+2 0+0 0+0
+ indvars.llvm.lib 0.02 0.0006 0.0010 0.0003 0.0037 0.0036 | 4744 1072 4208 12544 31336 | * 13+1 8+1 0+0 0+0
+ sumarray.llvm.lib <b>0.01</b> 0.0004 0.0008 0.0002 0.0026 <b>0.0029</b> | 904 3192 624 4720 15152 | * 6+1 4+1 0+0 0+0
+ </pre><p>
+
+ <hr>
+ <a name="20021111-2"><h2>Nov 11, 2002 #2:</h2>
+
+ This is the result after <a
+ href="http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20021111/001565.html">fixing
+ some major bugs</a>. The globals list was supposed to be kept sorted, but there
+ was one minor, tiny, little, bug that caused it to get screwed up sometimes.
+ This caused vortex to explode, fixing it gets things back in control where you'd
+ expect. Viola.<p>
+
+ This also includes a merging bug that caused some things to be merged and some
+ other things to happen when they shouldn't, which accounts for folding
+ reductions.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: BCTime: LocSize: BUSize: TDSize: TotSize: BCSize: NumFold NumNodes main __main GlobGr
+ 254.gap.lib 17.65 0.8186 4.5919 2.3718 9.2483 2.8978 | <b>2024984</b> <b>2984936</b> <b>2025480</b> <b>7035400</b> <b>16554904</b> | <b>6853</b> <b>24032+3950</b> 44+9 0+0 0+0
+ 255.vortex.lib 15.02 0.5766 2.4586 <b>3.5717</b> <b>7.6692</b> 2.2728 | <b>1381056</b> <b>1340216</b> <b>2461232</b> <b>5182504</b> <b>11689312</b> | <b>7127</b> <b>7302+2815</b> 166+11 0+0 0+0
+ 300.twolf.lib 3.23 0.2747 0.2856 0.5057 1.5129 0.9846 | <b>466528</b> <b>391512</b> <b>396552</b> <b>1254592</b> <b>6936728</b> | <b>749</b> <b>4128+784</b> <b>90+53</b> 0+0 0+0
+ 197.parser.lib 1.84 0.1528 0.3458 0.2180 0.8983 0.6469 | <b>408392</b> <b>225312</b> <b>212688</b> <b>965648</b> <b>4447944</b> | <b>1357</b> <b>2257+707</b> 14+6 0+0 0+0
+ burg.llvm.lib 1.20 0.1017 0.1867 0.1765 0.5525 0.4912 | <b>530600</b> <b>473296</b> <b>185792</b> <b>1189688</b> <b>3040208</b> | <b>756</b> <b>2273+576</b> <b>45+7</b> 0+0 0+0
+ 164.gzip.llvm.lib 0.71 0.0392 0.0649 0.0330 0.2008 0.4263 | <b>145952</b> <b>184776</b> <b>70872</b> <b>499912</b> <b>1876248</b> | 24 971+87 8+2 0+0 0+0
+ optimizer-eval.llvm.lib 0.42 0.0163 0.0446 0.2063 0.2953 <b>0.0798</b> | <b>101184</b> <b>79456</b> <b>61760</b> <b>242400</b> <b>624688</b> | * 309+41 72+27 0+0 0+0
+ 256.bzip2.lib 0.34 0.0238 0.0491 0.0112 0.1311 0.1543 | <b>139504</b> <b>83400</b> <b>39712</b> <b>335144</b> <b>1373216</b> | * 563+37 8+2 0+0 0+0
+ 181.mcf.lib 0.20 0.0174 0.0267 0.0272 0.0906 0.0744 | <b>115448</b> <b>146520</b> <b>43680</b> <b>322864</b> <b>589440</b> | <b>166</b> <b>388+51</b> <b>22+10</b> 0+0 0+0
+ sim.llvm.lib 0.19 0.0135 0.0136 0.0130 0.0776 0.0794 | <b>81632</b> <b>51496</b> <b>21872</b> <b>226584</b> <b>734152</b> | * <b>260+35</b> 39+22 0+0 0+0
+ voronoi.llvm.lib 0.17 0.0137 0.0267 0.0286 0.0829 0.0561 | <b>79824</b> <b>84152</b> <b>27112</b> <b>204904</b> <b>420568</b> | 18 299+77 15+8 0+0 0+0
+ bh.llvm.lib 0.16 0.0116 0.0161 0.0111 0.0591 0.0675 | <b>75000</b> <b>51080</b> <b>27760</b> <b>217632</b> <b>470720</b> | 61 194+35 6+2 0+0 0+0
+ sgefa.llvm.lib 0.14 0.0086 0.0201 0.0208 0.0656 0.0517 | <b>85688</b> <b>100456</b> <b>67024</b> <b>277864</b> <b>368680</b> | * 130+24 24+14 0+0 0+0
+ sumarray2d.llvm.lib <b>0.11</b> 0.0005 0.0009 0.0002 0.0033 <b>0.0922</b> | <b>1568</b> <b>3584</b> <b>848</b> <b>8264</b> <b>23288</b> | * 10+1 7+1 0+0 0+0
+ health.llvm.lib 0.09 0.0050 0.0082 0.0073 0.0280 0.0419 | <b>30632</b> <b>31432</b> <b>12704</b> <b>89592</b> <b>199888</b> | <b>18</b> <b>97+31</b> <b>12+4</b> 0+0 0+0
+ em3d.llvm.lib 0.09 0.0058 0.0110 0.0059 0.0304 0.0395 | <b>33040</b> <b>36256</b> <b>13008</b> <b>90632</b> <b>227520</b> | <b>1</b> <b>178+28</b> 12+4 0+0 0+0
+ power.llvm.lib 0.08 0.0042 0.0067 0.0040 0.0222 0.0365 | <b>27776</b> <b>17688</b> <b>18144</b> <b>71424</b> <b>213760</b> | * 81+18 11+2 0+0 0+0
+ mst.llvm.lib 0.08 0.0039 0.0072 0.0037 0.0218 0.0306 | <b>18624</b> <b>25576</b> 7040 <b>65808</b> <b>178832</b> | 10 97+15 12+3 0+0 0+0
+ lists.llvm.lib 0.08 0.0043 0.0137 0.0072 0.0306 0.0283 | <b>24552</b> <b>16920</b> 14440 <b>68024</b> 141480 | 30 67+26 3+1 0+0 0+0
+ tsp.llvm.lib 0.07 0.0048 0.0066 0.0027 0.0217 0.0327 | <b>18232</b> <b>14336</b> <b>4920</b> <b>51888</b> <b>180744</b> | 21 <b>43+15</b> <b>8+4</b> 0+0 0+0
+ perimeter.llvm.lib 0.06 0.0031 0.0066 0.0024 0.0194 0.0260 | <b>15016</b> <b>14192</b> <b>3936</b> <b>45912</b> <b>156352</b> | * 35+15 7+4 0+0 0+0
+ bisort.llvm.lib 0.06 0.0029 0.0056 0.0018 0.0230 0.0229 | <b>13288</b> <b>11408</b> 3712 <b>39448</b> <b>127360</b> | * 35+13 7+4 0+0 0+0
+ objinst.llvm.lib 0.05 0.0019 0.0048 0.0031 0.0153 0.0174 | <b>11280</b> <b>15784</b> <b>4112</b> <b>45296</b> <b>89856</b> | 34 45+14 16+10 0+0 0+0
+ methcall.llvm.lib 0.05 0.0017 0.0043 0.0028 0.0135 0.0187 | <b>11008</b> <b>9880</b> <b>3928</b> <b>38624</b> <b>87976</b> | 30 43+12 14+8 0+0 0+0
+ heapsort.llvm.lib 0.05 0.0009 0.0020 0.0007 0.0074 <b>0.0306</b> | <b>2856</b> <b>6968</b> <b>2008</b> <b>26976</b> <b>63160</b> | * 26+3 7+2 0+0 0+0
+ hash.llvm.lib 0.05 0.0030 0.0052 0.0040 0.0184 0.0173 | <b>25728</b> <b>16608</b> <b>8208</b> <b>63576</b> <b>151680</b> | * 117+17 14+6 0+0 0+0
+ sumarraymalloc.llvm.lib 0.04 0.0009 0.0015 0.0009 0.0067 0.0156 | 7040 2672 2048 25872 54352 | * 23+5 7+4 0+0 0+0
+ random.llvm.lib 0.04 0.0009 0.0018 0.0004 0.0060 0.0223 | 2056 5720 1320 22080 45264 | * 15+2 3+1 0+0 0+0
+ llubenchmark.llvm.lib 0.04 0.0022 0.0028 0.0015 0.0130 0.0118 | <b>11072</b> <b>11760</b> <b>2624</b> <b>36480</b> <b>124344</b> | * 31+7 15+5 0+0 0+0
+ ackermann.llvm.lib 0.04 0.0007 0.0015 0.0004 0.0055 0.0230 | 1744 5728 1200 22056 46448 | * 13+2 3+1 0+0 0+0
+ treeadd.llvm.lib 0.03 0.0015 0.0029 0.0009 0.0090 0.0076 | 3856 7384 2200 29784 72064 | * 25+7 6+3 0+0 0+0
+ sieve.llvm.lib 0.03 0.0007 0.0013 0.0005 0.0060 0.0140 | 2176 6176 1632 23432 216840 | * 22+2 12+1 0+0 0+0
+ printargs.llvm.lib 0.03 0.0005 0.0015 0.0002 0.0034 0.0077 | 1240 1048 696 5128 19160 | * 6+1 4+1 0+0 0+0
+ matrixTranspose.llvm.lib 0.03 0.0005 0.0010 0.0003 0.0032 0.0167 | <b>4272</b> 1144 736 <b>8560</b> <b>68448</b> | * 8+1 5+1 0+0 0+0
+ matrix.llvm.lib 0.03 0.0013 0.0022 0.0014 0.0092 0.0100 | <b>8808</b> <b>8872</b> <b>3072</b> <b>33144</b> <b>69112</b> | * 38+9 12+8 0+0 0+0
+ hello.llvm.lib 0.03 0.0004 0.0014 0.0001 0.0067 0.0123 | 752 2952 472 6512 <b>14160</b> | * 2+0 0+0 0+0 0+0
+ fib2.llvm.lib 0.03 0.0008 0.0015 0.0007 0.0061 <b>0.0135</b> | <b>7960</b> <b>6288</b> <b>1640</b> <b>28408</b> <b>42256</b> | * 21+5 8+3 0+0 0+0
+ ary3.llvm.lib 0.03 0.0012 0.0020 0.0011 0.0086 0.0084 | <b>10240</b> <b>13104</b> <b>10888</b> <b>45832</b> 73064 | 6 44+5 12+3 0+0 0+0
+ sumarray.llvm.lib 0.02 0.0003 0.0009 0.0002 0.0028 <b>0.0114</b> | 904 3192 624 4720 15152 | * 6+1 4+1 0+0 0+0
+ pi.llvm.lib 0.02 0.0008 0.0020 0.0004 0.0050 0.0037 | 5392 1560 1392 8344 36032 | * 17+2 13+2 0+0 0+0
+ indvars.llvm.lib 0.02 <b>0.0005</b> 0.0009 0.0003 0.0035 0.0035 | <b>4744</b> <b>1072</b> <b>4208</b> <b>12544</b> 31336 | * 13+1 8+1 0+0 0+0
+ </pre><p>
+
+ <hr>
+ <a name="20021111"><h2>Nov 11, 2002:</h2>
+
+ This is the first successful run of all of the benchmarks! This is still
+ compiled in debug mode, still has lots of tweaks and minor improvements that
+ could be made, lots of optimizations even, but they will have to wait for a
+ bit.<p>
+
+ Also note that we now include time taken the parse the bytecode file into LLVM
+ IR, and the space used by the LLVM IR.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: BCTime: LocSize: BUSize: TDSize: TotSize: BCSize: NumFold NumNodes main __main GlobGr
+ 255.vortex.lib <b>24.44</b> <b>0.5896</b> <b>2.7741</b> <b>11.5906</b> <b>16.5760</b> <b>2.3257</b> | <b>1381816</b> <b>1338688</b> <b>14822760</b> <b>17543264</b> <b>11691568</b> | <b>7288</b> <b>7321+3135</b> <b>166+11</b> <b>0+0</b> <b>0+0</b>
+ 254.gap.lib 19.51 0.8708 4.6071 3.5835 10.6354 2.9075 | 2024600 <b>3155592</b> <b>2323136</b> <b>7503328</b> 16555920 | <b>6934</b> <b>24027+3950</b> <b>44+9</b> 0+0 0+0
+ 300.twolf.lib 3.38 0.2753 0.2930 0.5233 1.5807 0.9966 | 466248 <b>392352</b> <b>398296</b> <b>1256896</b> 6936800 | <b>765</b> <b>4129+784</b> <b>91+53</b> 0+0 0+0
+ 197.parser.lib 1.89 0.1478 0.3243 0.2178 0.8755 0.6667 | 408560 <b>224928</b> <b>213736</b> <b>966696</b> 4451256 | <b>1350</b> <b>2259+711</b> <b>14+6</b> 0+0 0+0
+ burg.llvm.lib 1.23 0.1039 0.1877 0.1779 0.5589 0.4972 | 530224 <b>471200</b> <b>183504</b> <b>1184928</b> 3039960 | <b>790</b> <b>2239+575</b> <b>42+7</b> 0+0 0+0
+ 164.gzip.llvm.lib 0.71 0.0408 0.0578 0.0332 0.1965 0.4323 | 201664 <b>128768</b> <b>70864</b> <b>498912</b> 1870880 | 24 <b>971+87</b> <b>8+2</b> 0+0 0+0
+ optimizer-eval.llvm.lib 0.51 0.0166 0.0480 0.2086 0.3041 <b>0.1716</b> | 81584 <b>78352</b> <b>60304</b> <b>238616</b> 620296 | * <b>309+41</b> <b>72+27</b> 0+0 0+0
+ 256.bzip2.lib 0.33 0.0240 0.0383 0.0114 0.1214 0.1565 | 139536 <b>84224</b> <b>39704</b> <b>335680</b> 1370784 | * <b>563+37</b> <b>8+2</b> 0+0 0+0
+ 181.mcf.lib 0.22 0.0184 0.0286 0.0287 0.0959 0.0874 | 111384 <b>145792</b> <b>43360</b> <b>317776</b> 589808 | <b>156</b> <b>393+51</b> <b>23+10</b> 0+0 0+0
+ sim.llvm.lib 0.20 0.0136 0.0137 0.0130 0.0792 0.0848 | 55376 <b>81000</b> <b>21960</b> <b>253344</b> 721520 | * <b>261+36</b> <b>39+22</b> 0+0 0+0
+ voronoi.llvm.lib 0.17 0.0135 0.0262 0.0289 0.0833 0.0553 | 79696 <b>87968</b> <b>27128</b> <b>208568</b> 419920 | 18 <b>299+77</b> <b>15+8</b> 0+0 0+0
+ bh.llvm.lib 0.16 0.0116 0.0164 0.0118 0.0590 0.0665 | 55864 71416 27432 219376 473840 | 61 194+35 6+2 0+0 0+0
+ sgefa.llvm.lib 0.15 0.0089 0.0222 0.0246 0.0720 0.0530 | 85904 82240 67064 260872 364520 | * 130+24 24+14 0+0 0+0
+ health.llvm.lib 0.10 0.0050 0.0096 0.0055 0.0275 0.0450 | 29880 27920 7608 73008 199064 | 71 79+29 10+4 0+0 0+0
+ tsp.llvm.lib 0.08 0.0049 0.0072 0.0027 0.0224 0.0350 | 25704 14472 4872 52216 176600 | 21 42+15 7+4 0+0 0+0
+ power.llvm.lib 0.08 0.0041 0.0067 0.0037 0.0222 0.0361 | 28512 17760 7848 61960 214128 | * 81+18 11+2 0+0 0+0
+ em3d.llvm.lib 0.08 0.0060 0.0113 0.0055 0.0312 0.0315 | 24280 32960 12536 86576 224616 | 13 172+25 12+4 0+0 0+0
+ perimeter.llvm.lib 0.07 0.0031 0.0069 0.0020 0.0196 0.0261 | 14936 14112 3928 45592 155208 | * 35+15 7+4 0+0 0+0
+ mst.llvm.lib 0.07 0.0039 0.0067 0.0037 0.0216 0.0285 | 27408 16752 7040 66048 178328 | 10 97+15 12+3 0+0 0+0
+ lists.llvm.lib 0.07 0.0043 0.0128 0.0072 0.0299 0.0276 | 24544 16912 14440 68008 141480 | 30 67+26 3+1 0+0 0+0
+ hash.llvm.lib 0.06 0.0030 0.0051 0.0054 0.0202 0.0186 | 17936 24808 8216 64232 153552 | * 117+17 14+6 0+0 0+0
+ methcall.llvm.lib 0.05 0.0017 0.0047 0.0029 0.0142 0.0174 | 10984 9856 9144 44000 87328 | 30 43+12 14+8 0+0 0+0
+ objinst.llvm.lib 0.04 0.0019 0.0042 0.0033 0.0147 0.0114 | 11072 15328 10536 50496 87064 | 34 45+14 16+10 0+0 0+0
+ matrix.llvm.lib 0.04 0.0012 0.0021 0.0016 0.0094 <b>0.0164</b> | 8720 8784 3048 36600 68048 | * 38+9 12+8 0+0 0+0
+ llubenchmark.llvm.lib 0.04 0.0021 0.0027 0.0014 0.0130 0.0117 | 4728 <b>9368</b> <b>2608</b> <b>33440</b> 122712 | * 31+7 15+5 0+0 0+0
+ bisort.llvm.lib 0.04 0.0029 0.0056 0.0019 0.0160 0.0125 | 13608 11744 3712 45984 126584 | * 35+13 7+4 0+0 0+0
+ ary3.llvm.lib 0.04 0.0012 0.0020 0.0011 0.0088 0.0138 | 8648 19856 2976 43080 73064 | 6 44+5 12+3 0+0 0+0
+ ackermann.llvm.lib 0.04 0.0007 0.0017 0.0004 0.0058 <b>0.0226</b> | 1744 5728 1200 22056 46448 | * 13+2 3+1 0+0 0+0
+ treeadd.llvm.lib 0.03 0.0014 0.0029 0.0009 0.0090 0.0077 | 3856 7384 2200 29784 72064 | * 25+7 6+3 0+0 0+0
+ sumarraymalloc.llvm.lib 0.03 0.0009 <b>0.0017</b> 0.0009 0.0069 0.0100 | 7040 2672 2048 25872 54352 | * 23+5 7+4 0+0 0+0
+ sieve.llvm.lib 0.03 0.0007 0.0012 0.0005 0.0060 0.0138 | 2176 6176 1632 23432 216840 | * 22+2 12+1 0+0 0+0
+ random.llvm.lib 0.03 0.0008 0.0018 0.0004 0.0060 <b>0.0137</b> | 2056 5720 1320 22080 45264 | * 15+2 3+1 0+0 0+0
+ matrixTranspose.llvm.lib 0.03 0.0005 0.0010 0.0003 0.0033 <b>0.0151</b> | 4248 1144 736 8520 68104 | * 8+1 5+1 0+0 0+0
+ hello.llvm.lib <b>0.03</b> 0.0004 0.0018 0.0001 <b>0.0064</b> <b>0.0105</b> | 752 2952 472 6512 12264 | * 2+0 0+0 0+0 0+0
+ heapsort.llvm.lib 0.03 0.0009 0.0020 0.0007 0.0074 0.0080 | 7448 7224 1992 28032 62704 | * 26+3 7+2 0+0 0+0
+ sumarray2d.llvm.lib 0.02 0.0005 0.0009 0.0002 0.0033 0.0030 | 4208 856 3656 10904 21968 | * 10+1 7+1 0+0 0+0
+ printargs.llvm.lib 0.02 0.0004 0.0014 0.0002 0.0033 <b>0.0061</b> | 1240 1048 696 5128 19160 | * 6+1 4+1 0+0 0+0
+ pi.llvm.lib 0.02 0.0007 0.0019 0.0004 0.0050 0.0037 | 5392 1560 1392 8344 36032 | * 17+2 13+2 0+0 0+0
+ indvars.llvm.lib 0.02 <b>0.0011</b> 0.0010 0.0003 0.0043 0.0035 | 1744 4088 1024 9696 31336 | * 13+1 8+1 0+0 0+0
+ fib2.llvm.lib 0.02 0.0008 0.0015 0.0007 0.0061 0.0050 | 2416 10376 1648 30088 43792 | * 21+5 8+3 0+0 0+0
+ sumarray.llvm.lib 0.01 <b>0.0003</b> 0.0009 0.0002 0.0027 0.0022 | 904 3192 624 4720 15152 | * 6+1 4+1 0+0 0+0
+ </pre><p>
+
+
+
+ <hr>
+ <a name="20021110"><h2>Nov 10, 2002:</h2>
+
+ This data set has the prototype Tarjan SCC code in to help with cases that were
+ causing exponential behavior. This gets Gap working, but Vortex is still either
+ infinite looping or really slow. I'm almost certain there are a couple of bugs
+ still remaining in the implementation, so these should be regarded as
+ preliminary numbers.<p>
+
+ Here is some trivia for you: Vortex contains a SCC with 38 nodes, and another
+ with 19. Gap contains SCCs of size 2, 2, 20, 6, 2.<p>
+
+ Also note that the bytecode file for GAP is 3x the size of the bytecode file for
+ twolf.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: BCTime: LocSize: BUSize: TDSize: TotSize: BCSize: NumFold NumNodes main __main GlobGr
+ 255.vortex.lib <b>7.56</b> * * * * * | * * * * * | * * * * *
+ 254.gap.lib <b>22.53</b> <b>0.8908</b> <b>7.0430</b> <b>3.2424</b> <b>12.8506</b> <b>3.1879</b> | <b>2024600</b> <b>5229888</b> <b>3882656</b> <b>11137144</b> <b>16555920</b> | <b>6959</b> <b>42275+3949</b> <b>59+9</b> <b>0+0</b> <b>0+0</b>
+ 300.twolf.lib 3.92 0.3259 0.3470 0.8163 2.0253 1.0287 | <b>466248</b> <b>405936</b> <b>456456</b> <b>1328640</b> <b>6936800</b> | <b>821</b> <b>4119+784</b> <b>90+53</b> 0+0 0+0
+ 197.parser.lib 2.23 0.1939 <b>0.4020</b> 0.2499 1.0864 0.7768 | 408560 <b>229568</b> <b>220672</b> <b>978272</b> 4451256 | <b>1362</b> <b>2272+704</b> <b>16+6</b> 0+0 0+0
+ burg.llvm.lib 1.28 0.1085 0.1942 0.1954 0.5911 0.5072 | 530224 <b>477440</b> <b>290376</b> <b>1298040</b> 3039960 | <b>796</b> <b>2248+575</b> <b>39+7</b> 0+0 0+0
+ 164.gzip.llvm.lib 0.67 0.0392 0.0506 0.0326 0.1873 0.4044 | 201664 <b>130312</b> <b>72000</b> <b>501592</b> 1870880 | 24 <b>988+87</b> <b>12+2</b> 0+0 0+0
+ optimizer-eval.llvm.lib 0.43 0.0172 0.0570 0.2122 0.3200 0.0725 | 81584 <b>78640</b> <b>60384</b> <b>238984</b> 620296 | * <b>299+41</b> <b>62+27</b> 0+0 0+0
+ 256.bzip2.lib 0.34 0.0250 <b>0.0374</b> 0.0117 0.1242 0.1508 | 139536 <b>84856</b> <b>40208</b> <b>336816</b> 1370784 | * <b>569+37</b> <b>12+2</b> 0+0 0+0
+ 181.mcf.lib 0.23 0.0304 0.0296 0.0438 0.1255 0.0685 | 111384 <b>145928</b> <b>38568</b> <b>313120</b> 589808 | <b>161</b> <b>384+51</b> <b>27+10</b> 0+0 0+0
+ sim.llvm.lib 0.22 0.0138 0.0162 0.0146 0.0850 0.0891 | 55376 <b>81680</b> <b>21784</b> <b>253848</b> 721520 | * <b>259+36</b> <b>37+22</b> 0+0 0+0
+ voronoi.llvm.lib 0.20 0.0140 0.0311 0.0293 0.0962 0.0547 | 79696 <b>85176</b> <b>27272</b> <b>205920</b> 419920 | 18 <b>294+76</b> <b>17+8</b> 0+0 0+0
+ sgefa.llvm.lib 0.17 0.0088 0.0250 0.0223 0.0730 0.0615 | 85904 <b>82240</b> <b>67064</b> <b>260872</b> 364520 | * 130+24 24+14 0+0 0+0
+ bh.llvm.lib 0.15 0.0120 0.0173 0.0126 0.0614 0.0548 | 55864 <b>71416</b> <b>27432</b> <b>219376</b> 473840 | 61 194+35 6+2 0+0 0+0
+ em3d.llvm.lib 0.09 0.0066 0.0111 0.0088 0.0350 0.0284 | 24280 <b>32960</b> <b>12536</b> <b>86576</b> 224616 | <b>13</b> <b>172+25</b> 12+4 0+0 0+0
+ health.llvm.lib 0.08 0.0052 0.0098 0.0062 0.0287 0.0330 | 29880 <b>27920</b> <b>7608</b> <b>73008</b> 199064 | 71 79+29 10+4 0+0 0+0
+ mst.llvm.lib 0.07 0.0048 <b>0.0068</b> 0.0056 0.0266 0.0218 | 27408 <b>16752</b> <b>7040</b> <b>66048</b> 178328 | 10 97+15 12+3 0+0 0+0
+ tsp.llvm.lib 0.06 0.0049 <b>0.0069</b> 0.0026 0.0222 0.0212 | 25704 <b>14472</b> <b>4872</b> <b>52216</b> 176600 | 21 42+15 7+4 0+0 0+0
+ power.llvm.lib 0.06 0.0042 <b>0.0065</b> 0.0036 0.0217 0.0214 | 28512 <b>17760</b> <b>7848</b> <b>61960</b> 214128 | * 81+18 11+2 0+0 0+0
+ lists.llvm.lib 0.06 0.0042 0.0113 0.0071 0.0293 0.0146 | 24544 <b>16912</b> <b>14440</b> <b>68008</b> 141480 | 30 67+26 3+1 0+0 0+0
+ perimeter.llvm.lib 0.05 0.0030 0.0058 0.0020 0.0186 0.0161 | 14936 <b>14112</b> <b>3928</b> <b>45592</b> 155208 | * 35+15 7+4 0+0 0+0
+ methcall.llvm.lib 0.05 0.0017 <b>0.0042</b> 0.0028 0.0137 0.0099 | 10984 <b>9856</b> <b>9144</b> <b>44000</b> 87328 | 30 43+12 14+8 0+0 0+0
+ hash.llvm.lib 0.05 0.0031 0.0050 0.0039 0.0187 0.0163 | 17936 <b>24808</b> <b>8216</b> <b>64232</b> 153552 | * 117+17 14+6 0+0 0+0
+ bisort.llvm.lib 0.05 0.0048 <b>0.0053</b> 0.0018 0.0188 0.0125 | 13608 <b>11744</b> <b>3712</b> <b>45984</b> 126584 | * 35+13 7+4 0+0 0+0
+ objinst.llvm.lib 0.04 0.0018 <b>0.0044</b> 0.0032 0.0163 0.0103 | 11072 <b>15328</b> <b>10536</b> <b>50496</b> 87064 | <b>34</b> 45+14 16+10 0+0 0+0
+ llubenchmark.llvm.lib 0.04 0.0021 <b>0.0022</b> 0.0014 0.0125 0.0124 | 4728 <b>9520</b> <b>2624</b> <b>33608</b> 122712 | * 31+7 15+5 0+0 0+0
+ treeadd.llvm.lib 0.03 0.0015 <b>0.0024</b> 0.0009 0.0085 0.0077 | 3856 <b>7384</b> <b>2200</b> <b>29784</b> 72064 | * 25+7 6+3 0+0 0+0
+ sumarraymalloc.llvm.lib 0.03 0.0009 <b>0.0035</b> 0.0009 0.0088 0.0058 | 7040 <b>2672</b> <b>2048</b> <b>25872</b> 54352 | * 23+5 7+4 0+0 0+0
+ sieve.llvm.lib 0.03 0.0007 <b>0.0011</b> 0.0005 0.0060 0.0144 | 2176 <b>6176</b> <b>1632</b> <b>23432</b> 216840 | * 22+2 12+1 0+0 0+0
+ random.llvm.lib 0.03 0.0008 <b>0.0016</b> 0.0004 0.0063 0.0050 | 2056 <b>5720</b> <b>1320</b> <b>22080</b> 45264 | * 15+2 3+1 0+0 0+0
+ matrix.llvm.lib 0.03 0.0012 0.0021 0.0014 0.0093 0.0081 | 8720 <b>8784</b> <b>3048</b> <b>36600</b> 68048 | * 38+9 12+8 0+0 0+0
+ heapsort.llvm.lib 0.03 0.0010 <b>0.0018</b> 0.0006 0.0084 0.0064 | 7448 <b>7224</b> <b>1992</b> <b>28032</b> 62704 | * 26+3 7+2 0+0 0+0
+ fib2.llvm.lib 0.03 0.0008 <b>0.0016</b> 0.0007 0.0063 0.0048 | 2416 <b>10376</b> <b>1648</b> <b>30088</b> 43792 | * 21+5 8+3 0+0 0+0
+ ary3.llvm.lib 0.03 0.0012 0.0019 0.0011 0.0086 0.0073 | 8648 <b>19856</b> <b>2976</b> <b>43080</b> 73064 | 6 44+5 12+3 0+0 0+0
+ sumarray2d.llvm.lib 0.02 0.0004 <b>0.0008</b> 0.0003 0.0031 0.0029 | 4208 856 3656 10904 21968 | * 10+1 7+1 0+0 0+0
+ printargs.llvm.lib 0.02 0.0005 <b>0.0012</b> 0.0002 0.0031 0.0024 | 1240 <b>1048</b> <b>696</b> <b>5128</b> 19160 | * 6+1 4+1 0+0 0+0
+ pi.llvm.lib 0.02 0.0007 <b>0.0015</b> 0.0004 0.0050 0.0035 | 5392 <b>1560</b> <b>1392</b> <b>8344</b> 36032 | * 17+2 13+2 0+0 0+0
+ matrixTranspose.llvm.lib 0.02 0.0006 <b>0.0011</b> 0.0003 0.0036 0.0051 | 4248 <b>1144</b> <b>736</b> 8520 68104 | * 8+1 5+1 0+0 0+0
+ indvars.llvm.lib 0.02 0.0005 <b>0.0009</b> 0.0003 0.0035 0.0037 | 1744 4088 <b>1024</b> <b>9696</b> 31336 | * 13+1 8+1 0+0 0+0
+ ackermann.llvm.lib 0.02 0.0008 <b>0.0014</b> 0.0004 0.0056 0.0060 | 1744 <b>5728</b> <b>1200</b> <b>22056</b> 46448 | * 13+2 3+1 0+0 0+0
+ sumarray.llvm.lib 0.01 <b>0.0014</b> <b>0.0008</b> 0.0002 0.0036 0.0021 | 904 <b>3192</b> 624 <b>4720</b> 15152 | * 6+1 4+1 0+0 0+0
+ hello.llvm.lib 0.01 0.0004 <b>0.0015</b> 0.0001 0.0028 0.0019 | 752 2952 472 6512 12264 | * 2+0 0+0 0+0 0+0
+ </pre><p>
+
+
+ <hr>
+ <a name="20021109-2"><h2>Nov 9, 2002 #2:</h2>
+
+ This has the first part of the globals graph implemented, this simply deletes
+ the nodes that should be moved to the globals graph, without saving them and
+ then later merging them back in (The GlobGr size indicates the size of the
+ globals graph: right now it is empty, this will be fixed in the future). From
+ this we can get some <b>best case</b> times that the final algorithm will not be
+ able to match, but it is interesting to see badly how the N<sup>2</sup> case
+ hurts the TD pass.<p>
+
+ Note that I now know that gap and vortex are not working because of an infinite
+ loop in the algorithm, now that this is identified, hopefully it will be fixed
+ shortly.<p>
+
+ Note that these numbers are still with a debug build. Compiling with
+ optimizations and without assertions improves run time 3-4x.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main GlobGr
+ 254.gap.lib 4.92 * * * * | * * * * | * * * * *
+ 255.vortex.lib 2.78 * * * * | * * * * | * * * * *
+ 300.twolf.lib <b>3.50</b> 0.2890 <b>0.3094</b> <b>0.5272</b> <b>1.6337</b> | <b>487976</b> <b>434248</b> <b>418472</b> <b>1340696</b> | <b>794</b> <b>4223+808</b> <b>88+45</b> <b>0+0</b> 0+0
+ 197.parser.lib <b>1.70</b> 0.1517 <b>0.1978</b> <b>0.2152</b> <b>0.7588</b> | <b>408560</b> <b>243688</b> <b>213776</b> <b>985496</b> | <b>1327</b> <b>2257+706</b> <b>14+6</b> <b>0+0</b> 0+0
+ burg.llvm.lib <b>1.14</b> 0.1056 <b>0.1296</b> <b>0.1720</b> <b>0.5084</b> | <b>530224</b> <b>478880</b> <b>179080</b> <b>1188184</b> | <b>722</b> <b>2167+577</b> <b>30+7</b> <b>0+0</b> 0+0
+ 164.gzip.llvm.lib 0.65 0.0406 <b>0.0256</b> <b>0.0328</b> <b>0.1651</b> | <b>201664</b> <b>129304</b> <b>70864</b> <b>499448</b> | <b>24</b> <b>971+87</b> <b>8+2</b> <b>0+0</b> 0+0
+ optimizer-eval.llvm.lib 0.40 0.0170 <b>0.0366</b> 0.2099 0.3047 | <b>81584</b> <b>79352</b> <b>62232</b> <b>241544</b> | * <b>309+41</b> <b>72+27</b> <b>0+0</b> 0+0
+ 256.bzip2.lib <b>0.29</b> 0.0249 <b>0.0107</b> <b>0.0112</b> <b>0.0943</b> | <b>139536</b> <b>84752</b> <b>39720</b> <b>336224</b> | <b>*</b> <b>563+37</b> <b>8+2</b> <b>0+0</b> 0+0
+ 181.mcf.lib 0.20 0.0185 0.0247 <b>0.0285</b> 0.1042 | <b>111384</b> <b>145912</b> <b>43544</b> <b>318080</b> | <b>156</b> <b>393+51</b> <b>23+10</b> <b>0+0</b> 0+0
+ sim.llvm.lib 0.18 0.0143 0.0106 <b>0.0129</b> 0.0765 | <b>55376</b> <b>83072</b> <b>21968</b> <b>255424</b> | * <b>261+36</b> <b>39+22</b> <b>0+0</b> 0+0
+ voronoi.llvm.lib 0.15 0.0152 0.0203 0.0309 0.0807 | <b>79696</b> <b>87280</b> <b>27336</b> <b>208088</b> | <b>18</b> <b>299+77</b> <b>15+8</b> <b>0+0</b> 0+0
+ bh.llvm.lib 0.13 0.0120 0.0100 <b>0.0110</b> 0.0506 | <b>55864</b> <b>72480</b> <b>27632</b> <b>220640</b> | <b>61</b> <b>194+35</b> <b>6+2</b> <b>0+0</b> 0+0
+ sgefa.llvm.lib 0.12 0.0088 <b>0.0165</b> <b>0.0199</b> 0.0616 | <b>85904</b> <b>82032</b> <b>67032</b> <b>260632</b> | * <b>130+24</b> <b>24+14</b> <b>0+0</b> 0+0
+ health.llvm.lib 0.07 0.0051 0.0065 0.0054 0.0243 | <b>29880</b> <b>31328</b> <b>7816</b> <b>76624</b> | 71 <b>79+29</b> <b>10+4</b> <b>0+0</b> 0+0
+ em3d.llvm.lib 0.07 0.0059 0.0058 <b>0.0058</b> 0.0254 | <b>24280</b> <b>33360</b> <b>13344</b> <b>87784</b> | <b>10</b> <b>179+27</b> <b>12+4</b> <b>0+0</b> 0+0
+ power.llvm.lib 0.06 0.0043 0.0029 0.0051 0.0197 | <b>28512</b> <b>17808</b> <b>8008</b> <b>62168</b> | * <b>81+18</b> <b>11+2</b> <b>0+0</b> 0+0
+ tsp.llvm.lib 0.05 0.0051 0.0031 <b>0.0027</b> 0.0185 | <b>25704</b> <b>14576</b> <b>5040</b> <b>52488</b> | <b>21</b> <b>42+15</b> <b>7+4</b> <b>0+0</b> 0+0
+ perimeter.llvm.lib 0.05 0.0030 0.0036 0.0020 0.0163 | <b>14936</b> <b>22008</b> <b>4296</b> <b>53856</b> | * <b>35+15</b> <b>7+4</b> <b>0+0</b> 0+0
+ mst.llvm.lib 0.05 0.0051 0.0033 <b>0.0038</b> 0.0193 | <b>27408</b> <b>16880</b> <b>7216</b> <b>66352</b> | 10 <b>97+15</b> <b>12+3</b> <b>0+0</b> 0+0
+ lists.llvm.lib 0.05 0.0042 0.0058 0.0071 0.0227 | <b>24544</b> <b>17384</b> <b>13696</b> <b>67736</b> | <b>30</b> <b>67+26</b> <b>3+1</b> <b>0+0</b> 0+0
+ hash.llvm.lib 0.05 0.0030 0.0033 0.0041 0.0168 | <b>17936</b> <b>25000</b> <b>8544</b> <b>64752</b> | * <b>117+17</b> <b>14+6</b> <b>0+0</b> 0+0
+ objinst.llvm.lib 0.04 0.0018 0.0018 0.0033 0.0122 | <b>11072</b> <b>16344</b> <b>12040</b> <b>53016</b> | <b>35</b> <b>45+14</b> <b>16+10</b> <b>0+0</b> 0+0
+ methcall.llvm.lib 0.04 0.0017 0.0015 0.0029 0.0111 | <b>10984</b> <b>9816</b> <b>11880</b> <b>46696</b> | <b>30</b> <b>43+12</b> <b>14+8</b> <b>0+0</b> 0+0
+ llubenchmark.llvm.lib 0.04 0.0021 <b>0.0010</b> <b>0.0015</b> 0.0115 | <b>4728</b> <b>9384</b> <b>2808</b> <b>33656</b> | * <b>31+7</b> <b>15+5</b> <b>0+0</b> 0+0
+ bisort.llvm.lib 0.04 0.0029 0.0022 <b>0.0019</b> 0.0128 | <b>13608</b> <b>11840</b> <b>3888</b> <b>46256</b> | * <b>35+13</b> <b>7+4</b> <b>0+0</b> 0+0
+ treeadd.llvm.lib 0.03 0.0014 0.0009 0.0010 0.0071 | <b>3856</b> <b>12496</b> <b>2392</b> <b>35088</b> | * <b>25+7</b> <b>6+3</b> <b>0+0</b> 0+0
+ sumarraymalloc.llvm.lib 0.03 0.0009 0.0008 0.0010 0.0063 | <b>7040</b> <b>2192</b> <b>2656</b> <b>26000</b> | * <b>23+5</b> <b>7+4</b> <b>0+0</b> 0+0
+ sieve.llvm.lib 0.03 0.0007 0.0005 0.0006 0.0063 | <b>2176</b> <b>5832</b> <b>1968</b> <b>23424</b> | * <b>22+2</b> <b>12+1</b> <b>0+0</b> 0+0
+ matrixTranspose.llvm.lib <b>0.03</b> 0.0005 0.0002 0.0003 0.0026 | <b>4248</b> <b>792</b> <b>1088</b> <b>8520</b> | * <b>8+1</b> <b>5+1</b> <b>0+0</b> 0+0
+ matrix.llvm.lib 0.03 0.0013 0.0013 0.0015 0.0085 | <b>8720</b> <b>8704</b> <b>3416</b> <b>36888</b> | * <b>38+9</b> <b>12+8</b> <b>0+0</b> 0+0
+ ary3.llvm.lib 0.03 0.0012 0.0012 0.0012 0.0078 | <b>8648</b> <b>14136</b> <b>3328</b> <b>37712</b> | 6 <b>44+5</b> <b>12+3</b> <b>0+0</b> 0+0
+ random.llvm.lib 0.02 0.0008 0.0004 0.0005 0.0047 | <b>2056</b> <b>4720</b> <b>1656</b> <b>21416</b> | * <b>15+2</b> <b>3+1</b> <b>0+0</b> 0+0
+ pi.llvm.lib 0.02 0.0007 0.0003 <b>0.0005</b> 0.0036 | <b>5392</b> <b>1384</b> <b>4768</b> <b>11544</b> | * <b>17+2</b> <b>13+2</b> <b>0+0</b> 0+0
+ hello.llvm.lib 0.02 0.0004 <b>0.0001</b> <b>0.0001</b> 0.0015 | <b>752</b> <b>2952</b> <b>472</b> <b>6512</b> | * <b>2+0</b> <b>0+0</b> <b>0+0</b> 0+0
+ heapsort.llvm.lib 0.02 0.0009 0.0006 0.0007 0.0062 | <b>7448</b> <b>6864</b> <b>2360</b> <b>28040</b> | * <b>26+3</b> <b>7+2</b> <b>0+0</b> 0+0
+ fib2.llvm.lib 0.02 0.0008 0.0007 0.0007 0.0055 | <b>2416</b> <b>5680</b> <b>2000</b> <b>25744</b> | * <b>21+5</b> <b>8+3</b> <b>0+0</b> 0+0
+ ackermann.llvm.lib <b>0.02</b> <b>0.0007</b> <b>0.0004</b> <b>0.0005</b> <b>0.0046</b> | <b>1744</b> <b>5368</b> <b>1552</b> <b>22048</b> | * <b>13+2</b> <b>3+1</b> <b>0+0</b> 0+0
+ sumarray.llvm.lib 0.01 0.0003 0.0002 0.0002 0.0021 | <b>904</b> <b>2232</b> <b>624</b> <b>3760</b> | * <b>6+1</b> <b>4+1</b> 0+0 0+0
+ sumarray2d.llvm.lib 0.01 0.0004 0.0002 0.0003 0.0026 | <b>4208</b> <b>856</b> <b>3656</b> <b>10904</b> | * <b>10+1</b> <b>7+1</b> <b>0+0</b> 0+0
+ printargs.llvm.lib 0.01 0.0004 0.0002 0.0003 0.0023 | <b>1240</b> <b>704</b> <b>1064</b> <b>5152</b> | * <b>6+1</b> <b>4+1</b> <b>0+0</b> 0+0
+ indvars.llvm.lib 0.01 0.0005 0.0003 0.0003 0.0030 | <b>1744</b> <b>4088</b> <b>1032</b> <b>9704</b> | * <b>13+1</b> <b>8+1</b> <b>0+0</b> 0+0
+ </pre><p>
+
+
+ <hr>
+ <a name="20021109-1"><h2>Nov 9, 2002:</h2>
+
+ Same as the <a href="#20021108-3">previous run</a>, but now with a small tweak:
+ constants are never put into the scalar map for a function. This is in
+ preparation for the global graph work, but it does speed analysis up
+ marginally:<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ 254.gap.lib 2.16 * * * * | * * * * | * * * *
+ 255.vortex.lib 1.11 * * * * | * * * * | * * * *
+ 300.twolf.lib 11.63 0.2468 0.7464 7.5333 9.2461 | <b>595576</b> <b>795896</b> <b>10397040</b> <b>11788512</b> | <b>3577</b> <b>161901+1222</b> 854+0 854+0
+ 197.parser.lib 10.97 0.1258 0.4903 8.6508 9.5864 | <b>464920</b> <b>621904</b> <b>12987664</b> <b>14309904</b> | <b>2643</b> <b>197546+1185</b> 601+0 601+0
+ burg.llvm.lib 5.18 0.0904 0.2948 3.7480 4.3338 | <b>576064</b> <b>893240</b> <b>4821880</b> <b>6356592</b> | <b>1557</b> <b>72659+919</b> 436+0 436+0
+ 164.gzip.llvm.lib 1.28 0.0355 0.1037 0.5037 0.7448 | <b>228456</b> <b>511192</b> <b>1971048</b> <b>2809016</b> | <b>70</b> <b>16642+233</b> 171+0 171+0
+ 256.bzip2.lib 0.69 0.0201 0.0535 0.3301 0.4626 | <b>163016</b> <b>284360</b> <b>1450312</b> <b>1970944</b> | 20 <b>11464+202</b> 148+0 148+0
+ optimizer-eval.llvm.lib 0.57 0.0195 0.0846 0.3000 0.4423 | <b>86832</b> <b>180296</b> <b>702840</b> <b>988152</b> | * 3693+101 63+0 63+0
+ sim.llvm.lib 0.26 0.0137 0.0195 0.0619 0.1439 | <b>92280</b> <b>106632</b> <b>330888</b> <b>602464</b> | * <b>2738+67</b> 99+0 99+0
+ 181.mcf.lib 0.23 0.0164 0.0294 0.0572 0.1265 | <b>133872</b> <b>128088</b> <b>229576</b> <b>508384</b> | <b>180</b> <b>1923+73</b> 44+0 44+0
+ voronoi.llvm.lib 0.19 0.0119 0.0245 0.0606 0.1138 | <b>83592</b> <b>93192</b> <b>211920</b> <b>402648</b> | 17 <b>1734+106</b> 30+0 30+0
+ sgefa.llvm.lib 0.17 0.0071 0.0333 0.0406 0.0994 | <b>88880</b> <b>102320</b> <b>133176</b> <b>349144</b> | * 634+55 31+0 31+0
+ bh.llvm.lib 0.15 0.0102 0.0154 0.0239 0.0697 | <b>77528</b> <b>80672</b> <b>110160</b> <b>316400</b> | 66 <b>716+64</b> 13+0 13+0
+ em3d.llvm.lib 0.09 0.0045 0.0105 0.0229 0.0477 | <b>37816</b> <b>55256</b> <b>123168</b> <b>232944</b> | <b>8</b> <b>1032+59</b> 28+0 28+0
+ mst.llvm.lib 0.07 0.0033 0.0056 0.0115 0.0310 | <b>30744</b> <b>21600</b> <b>62072</b> <b>129088</b> | 10 <b>471+36</b> 21+0 21+0
+ health.llvm.lib 0.07 0.0042 0.0080 0.0105 0.0313 | <b>31520</b> <b>31784</b> <b>45624</b> <b>123896</b> | 71 <b>362+40</b> 14+0 14+0
+ tsp.llvm.lib 0.06 0.0046 0.0047 0.0060 0.0240 | <b>19552</b> <b>26040</b> <b>25800</b> <b>85696</b> | 19 <b>248+31</b> 10+0 10+0
+ power.llvm.lib 0.06 0.0034 0.0050 0.0086 0.0254 | <b>30904</b> <b>31232</b> <b>29704</b> <b>99512</b> | * 277+35 9+0 9+0
+ perimeter.llvm.lib 0.05 0.0025 0.0044 0.0037 0.0195 | <b>15760</b> <b>24296</b> <b>8552</b> <b>61448</b> | * <b>106+24</b> 4+0 4+0
+ lists.llvm.lib 0.05 0.0037 0.0075 0.0105 0.0283 | <b>25912</b> <b>29360</b> <b>28352</b> <b>101472</b> | 50 <b>252+34</b> 10+0 10+0
+ hash.llvm.lib 0.05 0.0025 0.0040 0.0059 0.0194 | <b>18464</b> <b>25408</b> <b>24192</b> <b>81464</b> | * <b>242+23</b> 7+0 7+0
+ llubenchmark.llvm.lib 0.04 0.0017 0.0022 0.0038 0.0198 | <b>12040</b> <b>13368</b> <b>17600</b> <b>54016</b> | * <b>145+20</b> 15+0 15+0
+ bisort.llvm.lib 0.04 0.0024 0.0035 0.0051 0.0176 | <b>14648</b> <b>28160</b> <b>22256</b> <b>76136</b> | * <b>211+27</b> 10+0 10+0
+ treeadd.llvm.lib 0.03 0.0011 0.0015 0.0020 0.0090 | <b>9320</b> <b>8552</b> <b>10120</b> <b>44152</b> | * <b>77+14</b> 5+0 5+0
+ sieve.llvm.lib 0.03 0.0006 0.0006 0.0008 0.0063 | <b>8032</b> <b>1720</b> <b>2552</b> <b>22672</b> | * <b>31+4</b> 2+0 2+0
+ objinst.llvm.lib 0.03 0.0015 0.0021 <b>0.0036</b> 0.0129 | <b>11272</b> <b>19896</b> <b>6096</b> <b>50920</b> | 33 <b>74+17</b> 3+0 3+0
+ methcall.llvm.lib 0.03 0.0014 0.0018 0.0028 0.0111 | <b>10936</b> <b>15720</b> <b>5152</b> <b>45064</b> | 26 <b>59+14</b> 2+0 2+0
+ matrix.llvm.lib 0.03 0.0014 0.0023 0.0025 0.0118 | <b>8984</b> <b>8096</b> <b>4352</b> <b>37776</b> | * <b>47+11</b> 1+0 1+0
+ ary3.llvm.lib 0.03 0.0010 0.0014 0.0014 0.0084 | <b>8992</b> <b>8624</b> <b>4344</b> <b>37624</b> | 6 <b>52+7</b> 1+0 1+0
+ sumarraymalloc.llvm.lib 0.02 0.0007 0.0009 0.0012 0.0069 | <b>2936</b> <b>6984</b> <b>7216</b> <b>31496</b> | * <b>39+8</b> 2+0 2+0
+ random.llvm.lib 0.02 0.0006 0.0006 0.0008 0.0057 | <b>2336</b> <b>6000</b> <b>2856</b> <b>26944</b> | * <b>32+5</b> 3+0 3+0
+ pi.llvm.lib 0.02 0.0006 0.0006 0.0013 0.0047 | <b>5816</b> <b>7240</b> <b>6688</b> <b>19744</b> | * 34+6 3+0 3+0
+ heapsort.llvm.lib 0.02 0.0007 0.0009 0.0012 0.0070 | <b>3128</b> <b>7336</b> <b>4008</b> <b>29640</b> | * <b>46+6</b> 3+0 3+0
+ fib2.llvm.lib 0.02 0.0007 0.0008 0.0008 0.0056 | <b>5704</b> <b>1928</b> <b>2520</b> <b>22440</b> | * <b>26+6</b> 1+0 1+0
+ sumarray.llvm.lib 0.01 0.0003 0.0002 0.0003 0.0022 | <b>960</b> <b>3176</b> <b>608</b> <b>6856</b> | * 7+2 0+0 0+0
+ sumarray2d.llvm.lib 0.01 0.0003 0.0003 0.0004 0.0028 | <b>1736</b> <b>6056</b> <b>1064</b> <b>11176</b> | * 15+3 1+0 1+0
+ printargs.llvm.lib 0.01 0.0003 0.0004 0.0005 0.0026 | <b>1464</b> <b>848</b> <b>3512</b> <b>5824</b> | * 13+4 1+0 1+0
+ matrixTranspose.llvm.lib 0.01 0.0004 0.0004 0.0005 0.0030 | <b>4384</b> <b>1248</b> <b>3824</b> <b>9456</b> | * 17+4 3+0 3+0
+ indvars.llvm.lib 0.01 0.0004 0.0005 0.0005 0.0033 | <b>4800</b> <b>7440</b> <b>1224</b> <b>13464</b> | * 18+3 1+0 1+0
+ hello.llvm.lib 0.01 0.0003 0.0003 0.0003 0.0021 | <b>976</b> <b>3024</b> <b>2968</b> <b>9224</b> | * 8+3 1+0 1+0
+ ackermann.llvm.lib 0.00 0.0000 0.0000 0.0001 0.0004 | <b>72</b> 0 832 <b>904</b> | * 0+0 * *
+ </pre><p>
+
+ <hr>
+ <a name="20021108-3"><h2>Nov 8, 2002 #3:</h2>
+
+ Same as the <a href="#20021108-2">previous run</a>, but now we automatically
+ collapse arrays down to a single element in the representation. The graphs
+ produced should be exactly the same, it's just memory consumption that goes
+ dramatically down, for example: 197.parser (64M->14M), 164.gzip
+ (14M->2.7M), 256.bzip (9M -> 1.9M), etc.<p>
+
+ With reduced memory consumption comes higher performance of course (better cache
+ behavior n stuff).<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ 254.gap.lib 71.65 * * * * | * * * * | * * * *
+ 255.vortex.lib <b>4.62</b> * * * * | * * * * | * * * *
+ 300.twolf.lib 12.22 0.2369 0.8840 8.0785 9.9177 | <b>573880</b> <b>770752</b> <b>10364040</b> <b>11708672</b> | <b>3514</b> 161528+1101 854+0 854+0
+ 197.parser.lib <b>11.73</b> 0.1216 <b>0.5217</b> <b>9.3368</b> <b>10.3099</b> | <b>461720</b> <b>619960</b> <b>12948496</b> <b>14266336</b> | <b>2641</b> 196932+1184 601+0 601+0
+ burg.llvm.lib 5.35 0.0857 0.2873 3.9878 4.5484 | <b>650608</b> <b>906016</b> <b>4691952</b> <b>6248576</b> | <b>1555</b> 72533+902 436+0 436+0
+ 164.gzip.llvm.lib <b>1.33</b> <b>0.0309</b> <b>0.1085</b> <b>0.5445</b> <b>0.7708</b> | <b>284312</b> <b>521048</b> <b>1877416</b> <b>2779368</b> | <b>67</b> 16632+232 171+0 171+0
+ 256.bzip2.lib <b>0.73</b> 0.0191 <b>0.0588</b> <b>0.3611</b> <b>0.4995</b> | <b>156760</b> <b>336272</b> <b>1390240</b> <b>1956528</b> | <b>20</b> 11456+201 148+0 148+0
+ optimizer-eval.llvm.lib 0.56 0.0129 0.0957 0.2881 0.4359 | <b>85720</b> <b>178016</b> <b>750424</b> <b>1032352</b> | <b>*</b> 3693+101 63+0 63+0
+ sim.llvm.lib <b>0.29</b> 0.0126 <b>0.0237</b> <b>0.0731</b> <b>0.1630</b> | <b>93240</b> <b>106144</b> <b>331688</b> <b>626088</b> | <b>*</b> 2739+67 99+0 99+0
+ 181.mcf.lib 0.28 0.0153 0.0379 <b>0.0649</b> 0.1457 | <b>136744</b> <b>155416</b> <b>202496</b> <b>511544</b> | <b>178</b> 1914+72 44+0 44+0
+ voronoi.llvm.lib 0.22 0.0122 0.0296 0.0728 0.1324 | <b>83568</b> <b>94008</b> <b>212560</b> <b>404128</b> | <b>17</b> 1733+106 30+0 30+0
+ sgefa.llvm.lib 0.19 0.0072 0.0375 0.0491 0.1131 | <b>102144</b> <b>109744</b> <b>117064</b> <b>353720</b> | <b>*</b> 634+55 31+0 31+0
+ bh.llvm.lib 0.17 0.0098 0.0164 0.0260 0.0728 | <b>78048</b> <b>82616</b> <b>86688</b> <b>311168</b> | 66 715+64 13+0 13+0
+ em3d.llvm.lib 0.11 0.0046 0.0114 0.0327 0.0590 | <b>36344</b> <b>64760</b> <b>125360</b> <b>243088</b> | <b>9</b> 1031+59 28+0 28+0
+ power.llvm.lib 0.09 0.0043 0.0053 0.0100 0.0296 | <b>22840</b> <b>33912</b> <b>30440</b> <b>103016</b> | <b>*</b> 277+35 9+0 9+0
+ tsp.llvm.lib 0.08 0.0043 0.0057 0.0066 0.0276 | <b>20640</b> <b>25416</b> <b>25784</b> <b>86464</b> | <b>19</b> 247+31 10+0 10+0
+ mst.llvm.lib 0.08 0.0033 0.0060 0.0123 0.0308 | <b>29088</b> 31400 <b>51632</b> <b>126792</b> | <b>10</b> 470+36 21+0 21+0
+ lists.llvm.lib 0.08 <b>0.0035</b> 0.0080 0.0111 0.0294 | <b>25048</b> <b>33872</b> <b>25520</b> <b>96760</b> | <b>50</b> 246+34 10+0 10+0
+ health.llvm.lib 0.08 <b>0.0043</b> 0.0083 0.0120 0.0344 | 31232 <b>31256</b> <b>45008</b> <b>122464</b> | <b>71</b> 361+40 14+0 14+0
+ perimeter.llvm.lib 0.07 0.0036 0.0047 0.0049 0.0251 | 15336 22904 <b>15968</b> <b>66864</b> | * 105+24 4+0 4+0
+ objinst.llvm.lib 0.06 0.0016 0.0024 <b>0.0090</b> 0.0191 | 11032 <b>15560</b> <b>12416</b> <b>52664</b> | <b>33</b> 73+17 3+0 3+0
+ bisort.llvm.lib 0.06 0.0023 0.0036 0.0065 0.0202 | 14376 <b>20968</b> <b>22152</b> <b>68568</b> | <b>*</b> 210+27 10+0 10+0
+ llubenchmark.llvm.lib 0.05 0.0018 0.0024 0.0042 0.0166 | 11824 <b>15464</b> <b>23480</b> <b>61776</b> | <b>*</b> 144+20 15+0 15+0
+ hash.llvm.lib 0.05 0.0026 0.0044 0.0062 0.0206 | <b>18192</b> <b>24928</b> <b>23976</b> <b>80496</b> | <b>*</b> 241+23 7+0 7+0
+ methcall.llvm.lib 0.04 0.0014 0.0019 0.0031 0.0120 | 10824 9704 11128 45312 | <b>26</b> 58+14 2+0 2+0
+ ary3.llvm.lib 0.04 0.0010 0.0015 0.0014 0.0102 | 8752 17136 4168 45720 | 6 50+7 1+0 1+0
+ treeadd.llvm.lib 0.03 0.0011 0.0016 0.0023 0.0098 | 9080 8408 <b>9944</b> <b>39424</b> | <b>*</b> 76+14 5+0 5+0
+ sieve.llvm.lib 0.03 0.0006 <b>0.0006</b> <b>0.0009</b> 0.0063 | <b>7856</b> <b>6056</b> <b>2480</b> <b>26760</b> | * 30+4 2+0 2+0
+ pi.llvm.lib 0.03 0.0006 0.0007 0.0012 0.0050 | 5696 5272 <b>5584</b> <b>16552</b> | * 34+6 3+0 3+0
+ matrix.llvm.lib 0.03 0.0010 0.0017 0.0018 0.0096 | 8584 17680 4208 46232 | * 46+11 1+0 1+0
+ heapsort.llvm.lib 0.03 0.0010 0.0009 0.0013 0.0076 | 2936 7224 3912 29240 | * 45+6 3+0 3+0
+ sumarraymalloc.llvm.lib 0.02 0.0007 0.0009 0.0015 0.0072 | 2720 <b>6872</b> <b>7128</b> <b>31152</b> | * 38+8 2+0 2+0
+ sumarray.llvm.lib 0.02 0.0003 0.0002 0.0003 0.0025 | <b>864</b> <b>3144</b> <b>592</b> <b>6712</b> | <b>*</b> 7+2 0+0 0+0
+ random.llvm.lib 0.02 0.0006 0.0006 0.0009 0.0057 | 6184 1808 2752 23600 | * 31+5 3+0 3+0
+ printargs.llvm.lib 0.02 0.0003 0.0004 0.0006 0.0028 | 1360 816 <b>3480</b> <b>5656</b> | * 13+4 1+0 1+0
+ matrixTranspose.llvm.lib 0.02 0.0004 <b>0.0004</b> <b>0.0006</b> <b>0.0034</b> | <b>5888</b> <b>1224</b> <b>4864</b> <b>11976</b> | * 17+4 3+0 3+0
+ indvars.llvm.lib <b>0.02</b> <b>0.0005</b> <b>0.0005</b> <b>0.0005</b> <b>0.0037</b> | <b>4680</b> <b>3552</b> <b>1200</b> <b>9432</b> | * 18+3 1+0 1+0
+ fib2.llvm.lib 0.02 0.0007 0.0008 0.0009 0.0059 | 6176 1808 2400 23008 | * 25+6 1+0 1+0
+ sumarray2d.llvm.lib <b>0.01</b> <b>0.0004</b> <b>0.0004</b> <b>0.0004</b> <b>0.0030</b> | <b>1648</b> <b>6024</b> <b>4144</b> <b>14136</b> | * 15+3 1+0 1+0
+ hello.llvm.lib 0.01 0.0003 0.0003 0.0003 0.0022 | 880 592 2944 6672 | * 8+3 1+0 1+0
+ ackermann.llvm.lib <b>0.00</b> 0.0000 0.0000 0.0002 0.0004 | 0 0 832 832 | * 0+0 * *
+ </pre><p>
+
+
+
+ <hr>
+ <a name="20021108-2"><h2>Nov 8, 2002 #2:</h2>
+
+ Same as the <a href="#20021108">previous run</a>, but with a huge bug fix:
+ before, all of the call nodes (from the local pass) were being passed up in the
+ BU pass, causing graph exposions. Now these call sites are not propagated. The
+ times and sized of graphs are all much smaller now.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ 254.gap.lib <b>130.47</b> * * * * | * * * * | * * * *
+ 255.vortex.lib <b>86.17</b> * * * * | * * * * | * * * *
+ 197.parser.lib <b>26.50</b> 0.1601 <b>1.4931</b> <b>22.7485</b> <b>24.7647</b> | <b>2187656</b> <b>4037056</b> <b>57704672</b> <b>64165544</b> | <b>4550</b> <b>196932+1184</b> 601+0 601+0
+ 300.twolf.lib <b>14.33</b> 0.2311 1.0000 <b>10.1733</b> <b>12.1591</b> | 629008 <b>1085616</b> <b>15564712</b> <b>17279336</b> | <b>4655</b> <b>161528+1101</b> 854+0 854+0
+ burg.llvm.lib <b>6.71</b> 0.0904 <b>0.3799</b> <b>5.1871</b> <b>5.8809</b> | <b>745152</b> <b>1254280</b> <b>6822216</b> <b>8821648</b> | <b>3253</b> <b>72533+902</b> <b>436+0</b> <b>436+0</b>
+ 164.gzip.llvm.lib <b>6.07</b> 0.1158 0.9992 <b>4.1925</b> <b>5.3966</b> | <b>2113120</b> <b>2772872</b> <b>9043760</b> <b>14026344</b> | <b>233</b> <b>16632+232</b> 171+0 171+0
+ 256.bzip2.lib <b>2.16</b> 0.0239 0.1987 <b>1.6047</b> <b>1.8899</b> | 372776 <b>1059888</b> <b>7503640</b> <b>9009560</b> | <b>132</b> <b>11456+201</b> 148+0 148+0
+ sim.llvm.lib 1.54 0.0163 0.2356 1.0723 1.3738 | <b>106096</b> <b>124280</b> <b>400760</b> <b>726152</b> | <b>41</b> <b>2739+67</b> 99+0 99+0
+ optimizer-eval.llvm.lib <b>0.58</b> 0.0126 <b>0.0890</b> <b>0.3282</b> <b>0.4696</b> | <b>110464</b> <b>188584</b> <b>1055832</b> <b>1373072</b> | <b>287</b> <b>3693+101</b> 63+0 63+0
+ 181.mcf.lib 0.33 0.0155 0.0465 <b>0.1437</b> <b>0.2308</b> | <b>156864</b> <b>225184</b> <b>805584</b> <b>1204520</b> | <b>209</b> <b>1914+72</b> 44+0 44+0
+ voronoi.llvm.lib <b>0.19</b> 0.0111 0.0253 <b>0.0644</b> <b>0.1178</b> | <b>83248</b> <b>93616</b> <b>238648</b> <b>429504</b> | <b>31</b> <b>1733+106</b> 30+0 30+0
+ sgefa.llvm.lib 0.18 0.0069 0.0398 0.0492 0.1156 | 104712 <b>108472</b> <b>178920</b> <b>416872</b> | <b>67</b> <b>634+55</b> 31+0 31+0
+ bh.llvm.lib <b>0.16</b> 0.0100 0.0177 <b>0.0355</b> <b>0.0838</b> | <b>81376</b> <b>93656</b> <b>190104</b> <b>428952</b> | 66 <b>715+64</b> 13+0 13+0
+ health.llvm.lib 0.10 <b>0.0230</b> 0.0084 0.0138 0.0551 | 31232 <b>31552</b> <b>56984</b> <b>134736</b> | <b>75</b> <b>361+40</b> 14+0 14+0
+ em3d.llvm.lib 0.09 0.0045 0.0117 <b>0.0255</b> 0.0519 | <b>37336</b> <b>67808</b> <b>126960</b> <b>248728</b> | <b>50</b> <b>1031+59</b> <b>28+0</b> <b>28+0</b>
+ power.llvm.lib 0.07 0.0035 0.0053 <b>0.0105</b> <b>0.0287</b> | <b>23432</b> <b>31680</b> <b>42680</b> <b>113616</b> | <b>3</b> <b>277+35</b> 9+0 9+0
+ mst.llvm.lib 0.07 0.0033 0.0060 <b>0.0145</b> 0.0333 | <b>29080</b> <b>31400</b> <b>56720</b> <b>131872</b> | <b>35</b> <b>470+36</b> 21+0 21+0
+ lists.llvm.lib 0.07 <b>0.0079</b> 0.0129 0.0170 0.0453 | <b>27616</b> <b>39648</b> <b>75280</b> <b>154864</b> | <b>54</b> <b>246+34</b> 10+0 10+0
+ indvars.llvm.lib 0.07 0.0020 0.0257 0.0269 0.0569 | <b>85496</b> <b>87560</b> 161216 <b>334272</b> | * 18+3 1+0 1+0
+ tsp.llvm.lib 0.06 0.0041 0.0049 <b>0.0065</b> 0.0250 | <b>19360</b> <b>26216</b> <b>26712</b> <b>86912</b> | <b>23</b> <b>247+31</b> 10+0 10+0
+ perimeter.llvm.lib 0.05 0.0024 0.0045 <b>0.0039</b> 0.0194 | <b>15336</b> <b>22904</b> <b>16288</b> <b>67184</b> | * <b>105+24</b> 4+0 4+0
+ hash.llvm.lib 0.05 0.0029 0.0043 <b>0.0066</b> 0.0211 | 25880 <b>18176</b> <b>28168</b> <b>85624</b> | <b>2</b> <b>241+23</b> 7+0 7+0
+ bisort.llvm.lib <b>0.05</b> 0.0022 0.0036 0.0064 0.0192 | 14376 <b>28616</b> <b>22416</b> <b>76480</b> | <b>3</b> <b>210+27</b> 10+0 10+0
+ llubenchmark.llvm.lib 0.04 0.0017 0.0026 0.0045 0.0169 | 11824 <b>24304</b> <b>18168</b> <b>65304</b> | <b>8</b> <b>144+20</b> 15+0 15+0
+ treeadd.llvm.lib 0.03 0.0013 0.0016 0.0023 0.0101 | <b>9080</b> <b>8408</b> <b>11224</b> <b>40704</b> | <b>2</b> <b>76+14</b> 5+0 5+0
+ sumarray2d.llvm.lib 0.03 0.0014 0.0097 0.0106 0.0238 | 42056 46440 83192 174008 | * 15+3 1+0 1+0
+ sieve.llvm.lib 0.03 0.0008 0.0021 0.0032 0.0103 | 16064 <b>14264</b> <b>35312</b> <b>76008</b> | * <b>30+4</b> 2+0 2+0
+ objinst.llvm.lib <b>0.03</b> 0.0015 0.0024 <b>0.0037</b> 0.0134 | 11032 <b>15488</b> <b>11440</b> <b>51616</b> | 39 <b>73+17</b> 3+0 3+0
+ methcall.llvm.lib 0.03 0.0014 0.0018 0.0030 0.0115 | <b>10824</b> <b>9704</b> <b>11128</b> <b>45312</b> | 31 <b>58+14</b> 2+0 2+0
+ matrix.llvm.lib 0.03 0.0011 0.0017 0.0018 0.0109 | <b>8584</b> <b>17680</b> <b>4208</b> <b>46232</b> | * <b>46+11</b> 1+0 1+0
+ ary3.llvm.lib 0.03 0.0010 0.0014 0.0014 0.0085 | 8752 <b>17136</b> <b>4168</b> <b>45720</b> | 6 <b>50+7</b> 1+0 1+0
+ sumarraymalloc.llvm.lib 0.02 0.0007 0.0009 0.0013 0.0070 | 2720 <b>12824</b> <b>3376</b> <b>33352</b> | * <b>38+8</b> 2+0 2+0
+ random.llvm.lib 0.02 0.0006 0.0009 0.0009 0.0060 | <b>6184</b> <b>1808</b> <b>2752</b> <b>23600</b> | * <b>31+5</b> 3+0 3+0
+ pi.llvm.lib 0.02 0.0006 0.0007 0.0011 0.0049 | 5696 <b>5272</b> <b>6544</b> <b>17512</b> | * <b>34+6</b> 3+0 3+0
+ matrixTranspose.llvm.lib 0.02 0.0007 0.0033 0.0034 0.0095 | 14088 9424 29480 52992 | * 17+4 3+0 3+0
+ heapsort.llvm.lib <b>0.02</b> 0.0008 0.0009 0.0013 <b>0.0076</b> | 2936 <b>7224</b> <b>3912</b> <b>29240</b> | * <b>45+6</b> 3+0 3+0
+ fib2.llvm.lib 0.02 0.0014 0.0008 0.0009 0.0067 | <b>6176</b> <b>1808</b> <b>2400</b> <b>23008</b> | * <b>25+6</b> 1+0 1+0
+ sumarray.llvm.lib <b>0.01</b> 0.0003 0.0003 0.0003 0.0022 | 1280 3552 584 7528 | 3 7+2 0+0 0+0
+ printargs.llvm.lib 0.01 0.0005 0.0004 0.0006 0.0030 | 1360 <b>816</b> <b>4760</b> <b>6936</b> | * <b>13+4</b> 1+0 1+0
+ hello.llvm.lib 0.01 0.0003 0.0003 0.0003 0.0022 | 880 <b>592</b> <b>2944</b> <b>6672</b> | * <b>8+3</b> 1+0 1+0
+ ackermann.llvm.lib 0.01 0.0000 0.0000 0.0001 0.0004 | 0 0 832 832 | * 0+0 * *
+ </pre><p>
+
+ <hr>
+ <a name="20021108"><h2>Nov 8, 2002:</h2>
+
+ Same as the <a href="#20021107-2">previous run</a>, but now the Top-Down pass
+ has been rewritten to:<p>
+
+ <ul>
+ <li>Actually work on all of the benchmarks
+ <li>Require less book-keeping
+ <li>Only clone a caller graph into a particular callee graph once
+ <li>Not prune nodes as aggressively, this is probably the reason for many
+ slowdowns below.
+ </ul><p>
+
+ Looking deeper into the results, gzip got slower by a factor of 4, optimizer
+ eval got slower by a factor of 3, sim slowed down just a little bit.<p>
+
+ Note that without the globals graph, some benchmarks are still VERY slow (those
+ with heavy use of globals).<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ 254.gap.lib 330.50 * * * * | * * * * | * * * *
+ 255.vortex.lib * * * * * | * * * * | * * * *
+ 197.parser.lib 120.10 0.1649 11.8198 105.3900 118.0119 | 2188536 4525320 60972272 67921544 | 22575 202604+8604 601+0 601+0
+ 300.twolf.lib 72.38 0.2431 1.8500 30.5671 72.3845 | 629008 1375352 16515832 18520192 | 18090 163168+3906 854+0 854+0
+ burg.llvm.lib 34.18 0.0871 1.0919 15.8467 34.1754 | 749304 1755232 7209416 9779360 | 21707 78464+4387 393+0 393+0
+ 164.gzip.llvm.lib 21.81 0.1149 1.2083 19.6981 21.1201 | 2055024 3145544 8929008 14227896 | 2387 18236+1588 171+0 171+0
+ 256.bzip2.lib 7.44 0.0250 0.3032 6.2987 7.4430 | 372776 1205520 7660752 9312304 | 1765 11947+1011 148+0 148+0
+ optimizer-eval.llvm.lib 3.24 0.0131 1.0648 1.9117 3.0792 | 110456 343032 1971952 2443624 | 5293 4186+1033 63+0 63+0
+ sim.llvm.lib 2.27 0.0170 0.2274 1.7720 2.0708 | 104728 130376 451320 759088 | 62 2755+122 99+0 99+0
+ 181.mcf.lib 0.61 0.0162 0.0556 0.3631 0.4646 | 156648 234864 866704 1275064 | 243 2023+163 44+0 44+0
+ voronoi.llvm.lib 0.45 0.0117 0.0447 0.2557 0.3385 | 83088 150936 337552 585520 | 157 2063+390 30+0 30+0
+ bh.llvm.lib 0.38 0.0101 0.0253 0.1778 0.2394 | 79736 129328 245408 502512 | 66 858+198 13+0 13+0
+ sgefa.llvm.lib 0.27 0.0071 0.0396 0.0780 0.1465 | 104712 112576 204600 446656 | 130 640+103 31+0 31+0
+ power.llvm.lib 0.14 0.0035 0.0080 0.0451 0.0675 | 31272 49768 66968 155680 | 6 359+96 9+0 9+0
+ em3d.llvm.lib 0.13 0.0046 0.0140 0.0524 0.0825 | 37096 65320 122624 241744 | 141 920+127 21+0 21+0
+ mst.llvm.lib 0.13 0.0033 0.0084 0.0381 0.0605 | 29104 36104 70496 150376 | 100 506+91 21+0 21+0
+ lists.llvm.lib 0.12 0.0036 0.0118 0.0328 0.0664 | 27880 33064 98728 177520 | 58 270+63 10+0 10+0
+ bisort.llvm.lib 0.11 0.0023 0.0047 0.0125 0.0270 | 14376 29520 33808 88776 | 6 226+42 10+0 10+0
+ indvars.llvm.lib 0.11 0.0020 0.0254 0.0310 0.0606 | 85520 88232 161216 334968 | * 18+3 1+0 1+0
+ health.llvm.lib 0.10 0.0044 0.0113 0.0255 0.0519 | 31232 44592 53456 144248 | 79 385+69 14+0 14+0
+ tsp.llvm.lib 0.10 0.0042 0.0062 0.0176 0.0382 | 27840 19008 51376 112528 | 27 271+55 10+0 10+0
+ hash.llvm.lib 0.10 0.0026 0.0056 0.0168 0.0336 | 25880 29936 35312 104528 | 6 271+44 7+0 7+0
+ heapsort.llvm.lib 0.09 0.0007 0.0009 0.0015 0.0429 | 2936 7384 4064 29552 | * 47+7 3+0 3+0
+ perimeter.llvm.lib 0.08 0.0025 0.0064 0.0090 0.0271 | 15432 25616 18552 72440 | * 121+39 4+0 4+0
+ objinst.llvm.lib 0.08 0.0015 0.0027 0.0076 0.0180 | 11032 16088 19848 60624 | 39 78+25 3+0 3+0
+ sumarray2d.llvm.lib 0.06 0.0011 0.0098 0.0111 0.0241 | 42056 46440 83192 174008 | * 15+3 1+0 1+0
+ ary3.llvm.lib 0.06 0.0010 0.0016 0.0021 0.0096 | 8752 17528 4696 46640 | 6 55+10 1+0 1+0
+ llubenchmark.llvm.lib 0.05 0.0018 0.0034 0.0063 0.0199 | 11824 20384 28056 71272 | 32 141+31 15+0 15+0
+ treeadd.llvm.lib 0.05 0.0012 0.0023 0.0036 0.0121 | 9120 17640 10960 53880 | 4 82+18 5+0 5+0
+ sumarray.llvm.lib 0.04 0.0003 0.0003 0.0003 0.0022 | 1280 3552 584 7528 | 3 7+2 0+0 0+0
+ methcall.llvm.lib 0.03 0.0014 0.0021 0.0045 0.0147 | 10680 16000 11784 51720 | 31 63+19 2+0 2+0
+ sieve.llvm.lib 0.03 0.0008 0.0022 0.0047 0.0120 | 16064 14528 39672 80632 | * 32+5 2+0 2+0
+ fib2.llvm.lib 0.03 0.0007 0.0009 0.0011 0.0063 | 5512 6088 2544 26432 | * 27+7 1+0 1+0
+ matrix.llvm.lib 0.02 0.0010 0.0017 0.0021 0.0100 | 8760 8104 8976 42184 | * 48+12 1+0 1+0
+ matrixTranspose.llvm.lib 0.02 0.0007 0.0034 0.0037 0.0098 | 14088 9424 29480 52992 | * 17+4 3+0 3+0
+ sumarraymalloc.llvm.lib 0.02 0.0007 0.0010 0.0016 0.0075 | 2720 12928 3536 33544 | * 40+9 2+0 2+0
+ pi.llvm.lib 0.02 0.0006 0.0007 0.0014 0.0052 | 5696 5368 5680 16744 | * 35+7 3+0 3+0
+ random.llvm.lib 0.02 0.0006 0.0007 0.0012 0.0061 | 2136 6040 7248 31176 | * 33+6 3+0 3+0
+ printargs.llvm.lib 0.02 0.0003 0.0004 0.0007 0.0030 | 1360 1024 1728 4112 | * 14+5 1+0 1+0
+ hello.llvm.lib 0.02 0.0003 0.0003 0.0005 0.0023 | 880 648 768 4552 | * 9+4 1+0 1+0
+ ackermann.llvm.lib 0.02 0.0000 0.0000 0.0002 0.0004 | 0 0 832 832 | * 0+0 * *
+ </pre><p>
+
+
+ <hr>
+ <a name="20021107-2"><h2>Nov 7, 2002 #2:</h2>
+
+ Same as the <a href="#20021107">previous run</a>, but now we actually handle
+ constants (especially constantexprs) correctly in the local and all subsequent
+ passes. This seems to dramatically improve many benchmarks, only slowing down
+ gzip significantly.<p>
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ 300.twolf.lib 30.88 * * * * | * * * * | * * * *
+ 255.vortex.lib 15.71 * * * * | * * * * | * * * *
+ 254.gap.lib 6.07 analyze: ../../../include/llvm/Analysis/DSNode.h:77: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ 164.gzip.llvm.lib 5.32 0.1157 1.0296 3.4025 4.6326 | 2054352 2631576 7804656 12588904 | 398 13372+217 174+3 174+3
+ 256.bzip2.lib 2.36 0.0250 0.1913 1.8190 2.0966 | 371928 1045320 7533440 9023600 | 407 11415+149 151+2 151+2
+ sim.llvm.lib 1.97 0.0174 0.2155 1.4731 1.7539 | 104584 120112 449736 747416 | 46 2745+52 101+2 101+2
+ 197.parser.lib 1.27 analyze: ../../../include/llvm/Analysis/DSNode.h:77: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ optimizer-eval.llvm.lib 1.09 0.0132 0.0926 0.8104 0.9528 | 109416 186592 1827184 2141376 | 1709 8189+43 63+0 63+0
+ burg.llvm.lib 0.81 analyze: ../../../include/llvm/Analysis/DSNode.h:77: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ 181.mcf.lib 0.38 0.0163 0.0470 0.1847 0.2714 | 156304 219896 808112 1201160 | 226 1859+0 44+0 44+0
+ voronoi.llvm.lib 0.22 0.0118 0.0241 0.0776 0.1293 | 82728 87872 214584 399128 | 31 1650+0 30+0 30+0
+ sgefa.llvm.lib 0.19 0.0074 0.0324 0.0716 0.1303 | 104560 104744 200024 434096 | 89 610+1 32+0 32+0
+ bh.llvm.lib 0.17 0.0106 0.0158 0.0344 0.0813 | 80112 86984 210008 425144 | 66 678+3 16+0 16+0
+ em3d.llvm.lib 0.16 0.0067 0.0111 0.0619 0.0899 | 37600 55936 217632 327872 | 90 1584+522 38+3 38+3
+ health.llvm.lib 0.10 0.0044 0.0071 0.0117 0.0322 | 31120 38712 35248 120048 | 81 328+0 14+0 14+0
+ lists.llvm.lib 0.09 0.0037 0.0075 0.0296 0.0477 | 27792 32968 83288 162264 | 61 222+0 10+0 10+0
+ llubenchmark.llvm.lib 0.09 0.0018 0.0021 0.0060 0.0178 | 11104 12176 32552 66840 | 35 152+22 17+1 17+1
+ power.llvm.lib 0.08 0.0036 0.0045 0.0139 0.0308 | 21672 31000 40512 109008 | 5 246+0 9+0 9+0
+ mst.llvm.lib 0.07 0.0033 0.0051 0.0125 0.0296 | 28368 27552 49088 119680 | 54 435+1 21+0 21+0
+ indvars.llvm.lib 0.07 0.0020 0.0199 0.0281 0.0521 | 85496 84840 164280 334616 | * 15+0 1+0 1+0
+ perimeter.llvm.lib 0.06 0.0027 0.0035 0.0037 0.0180 | 15312 12112 14536 54800 | * 83+0 4+0 4+0
+ tsp.llvm.lib 0.05 0.0045 0.0041 0.0063 0.0254 | 27736 15016 25296 82352 | 28 228+1 11+0 11+0
+ hash.llvm.lib 0.04 0.0025 0.0038 0.0054 0.0202 | 18288 24528 26104 82320 | 2 220+0 7+0 7+0
+ bisort.llvm.lib 0.04 0.0025 0.0030 0.0050 0.0178 | 14296 19056 28384 72808 | 5 186+0 10+0 10+0
+ sumarray2d.llvm.lib 0.04 0.0011 0.0077 0.0102 0.0210 | 42032 46264 83960 174576 | * 12+0 1+0 1+0
+ treeadd.llvm.lib 0.04 0.0011 0.0013 0.0017 0.0086 | 9008 7360 10264 42432 | 2 64+0 5+0 5+0
+ objinst.llvm.lib 0.03 0.0021 0.0019 0.0049 0.0147 | 10928 15344 24592 64520 | 31 151+72 9+4 9+4
+ methcall.llvm.lib 0.03 0.0014 0.0016 0.0030 0.0111 | 15520 8928 8032 45736 | 27 99+44 8+4 8+4
+ matrix.llvm.lib 0.03 0.0010 0.0015 0.0017 0.0086 | 8680 8424 8200 41304 | * 39+0 1+0 1+0
+ sieve.llvm.lib 0.03 0.0007 0.0021 0.0032 0.0101 | 10320 13864 34512 72456 | * 26+0 2+0 2+0
+ sumarraymalloc.llvm.lib 0.03 0.0007 0.0008 0.0008 0.0060 | 2656 6144 6848 30024 | * 31+0 2+0 2+0
+ matrixTranspose.llvm.lib 0.03 0.0006 0.0027 0.0034 0.0087 | 14064 9080 28600 51744 | * 14+0 3+0 3+0
+ ary3.llvm.lib 0.02 0.0011 0.0013 0.0012 0.0081 | 8720 6968 8256 39992 | 6 44+0 1+0 1+0
+ heapsort.llvm.lib 0.02 0.0008 0.0008 0.0008 0.0077 | 2896 13464 2552 33728 | * 39+0 3+0 3+0
+ random.llvm.lib 0.02 0.0007 0.0006 0.0006 0.0056 | 6296 4848 6112 29856 | * 26+0 3+0 3+0
+ fib2.llvm.lib 0.01 0.0007 0.0007 0.0006 0.0052 | 5488 5408 1344 24888 | * 19+0 1+0 1+0
+ pi.llvm.lib 0.01 0.0006 0.0006 0.0009 0.0043 | 5656 4768 5416 15840 | * 29+0 3+0 3+0
+ printargs.llvm.lib 0.01 0.0003 0.0003 0.0003 0.0023 | 1336 560 728 2624 | * 9+0 1+0 1+0
+ sumarray.llvm.lib 0.01 0.0003 0.0003 0.0002 0.0022 | 1256 2456 456 6280 | 3 5+0 0+0 0+0
+ hello.llvm.lib 0.01 0.0003 0.0003 0.0002 0.0019 | 840 2872 3136 6848 | * 5+0 1+0 1+0
+ ackermann.llvm.lib 0.01 * * * * | * * * * | * 0+0 * *
+ </pre><p>
+
+
+ <hr>
+ <a name="20021107"><h2>Nov 7, 2002:</h2>
+
+ Notes: Debug build, no globals graph, no array collapsing.<p>
+
+ Things are a big slower than before due to corrected handling of global
+ variables.
+
+ <pre>
+ Name: Anlyz: LocTime: BUTime: TDTime: TotTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ 254.gap.lib 6.23 analyze: ../../../include/llvm/Analysis/DSNode.h:77: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ sim.llvm.lib 3.77 0.0156 0.3313 1.6634 2.0787 | 63080 98008 192424 426656 | * 1825+84 63+2 63+2
+ 300.twolf.lib 374.15 * * * * | * * * * | * * * *
+ 255.vortex.lib 185.26 * * * * | * * * * | * * * *
+ 256.bzip2.lib 1.10 0.0158 0.0679 0.7397 0.8794 | 213592 385312 3368648 4040464 | 18 5238+257 64+1 64+1
+ 164.gzip.llvm.lib 1.08 0.0260 0.0797 0.3326 0.5279 | 235048 421744 1484408 2237792 | 21 9628+634 113+1 113+1
+ 197.parser.lib 1.06 analyze: ../../../include/llvm/Analysis/DSNode.h:77: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ burg.llvm.lib 0.71 analyze: ../../../include/llvm/Analysis/DSNode.h:77: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ optimizer-eval.llvm.lib 0.67 0.0115 0.0793 0.4125 0.5422 | 78080 141896 372592 610760 | 58 666+27 2+0 2+0
+ 181.mcf.lib 0.32 0.0125 0.0418 0.1271 0.2052 | 120504 192920 545696 876008 | 186 753+0 14+0 14+0
+ voronoi.llvm.lib 0.18 0.0098 0.0204 0.0661 0.1116 | 78560 83344 116304 292200 | 19 1006+0 16+0 16+0
+ sgefa.llvm.lib 0.16 0.0064 0.0340 0.0413 0.0999 | 82280 96016 67960 270944 | * 125+2 2+0 2+0
+ sieve.llvm.lib 0.16 0.0007 0.0028 0.0209 0.0295 | 9872 13808 38872 76312 | * 22+0 1+0 1+0
+ lists.llvm.lib 0.15 0.0027 0.0061 0.0042 0.0217 | 22256 14256 3208 51720 | 52 38+0 0+0 0+0
+ bh.llvm.lib 0.14 0.0082 0.0140 0.0171 0.0630 | 73320 75448 42920 255160 | 74 402+4 10+0 10+0
+ em3d.llvm.lib 0.14 0.0037 0.0091 0.0303 0.0522 | 33816 50768 109200 202192 | 10 925+410 19+3 19+3
+ hash.llvm.lib 0.14 0.0020 0.0033 0.0036 0.0154 | 17488 23928 12584 67400 | * 131+0 2+0 2+0
+ llubenchmark.llvm.lib 0.13 0.0013 0.0011 0.0019 0.0128 | 9680 2144 10072 32904 | * 51+10 4+1 4+1
+ indvars.llvm.lib 0.12 0.0022 0.0248 0.0422 0.0713 | 82040 87944 160872 333400 | * 12+0 0+0 0+0
+ ary3.llvm.lib 0.12 0.0008 0.0011 0.0009 0.0072 | 7992 7808 2416 34264 | 6 37+0 0+0 0+0
+ health.llvm.lib 0.10 0.0035 0.0067 0.0067 0.0280 | 28432 27984 12640 83984 | 72 151+1 6+0 6+0
+ hello.llvm.lib 0.10 0.0002 0.0002 0.0002 0.0016 | 504 2816 336 3656 | * 2+0 0+0 0+0
+ ackermann.llvm.lib 0.09 0.0004 0.0005 0.0004 0.0045 | 6976 992 840 18736 | * 10+0 0+0 0+0
+ objinst.llvm.lib 0.08 0.0014 0.0019 0.0052 0.0137 | 9480 19064 12216 54416 | 25 148+80 7+4 7+4
+ sumarray2d.llvm.lib 0.08 0.0012 0.0096 0.0109 0.0235 | 41416 47080 80696 171512 | * 9+0 0+0 0+0
+ methcall.llvm.lib 0.08 0.0011 0.0016 0.0032 0.0108 | 3952 17528 8584 43720 | 23 104+52 7+4 7+4
+ heapsort.llvm.lib 0.08 0.0006 0.0008 0.0007 0.0063 | 2264 13720 2216 33016 | * 33+0 2+0 2+0
+ fib2.llvm.lib 0.08 0.0005 0.0006 0.0004 0.0048 | 1776 5312 1080 23992 | * 14+0 0+0 0+0
+ tsp.llvm.lib 0.07 0.0036 0.0035 0.0041 0.0197 | 17304 13808 17968 63704 | 18 95+1 4+0 4+0
+ random.llvm.lib 0.07 0.0005 0.0006 0.0005 0.0066 | 1584 4704 5752 25264 | * 21+0 2+0 2+0
+ pi.llvm.lib 0.07 0.0004 0.0004 0.0005 0.0031 | 4744 1248 4368 10360 | * 14+0 0+0 0+0
+ power.llvm.lib 0.06 0.0031 0.0063 0.0070 0.0251 | 19440 28024 23544 86832 | * 146+0 4+0 4+0
+ bisort.llvm.lib 0.06 0.0019 0.0036 0.0026 0.0168 | 12776 18296 6808 48952 | * 89+0 4+0 4+0
+ matrixTranspose.llvm.lib 0.06 0.0005 0.0019 0.0025 0.0065 | 9136 14520 25336 48992 | * 10+0 1+0 1+0
+ printargs.llvm.lib 0.06 0.0003 0.0003 0.0003 0.0021 | 888 504 512 1904 | * 5+0 0+0 0+0
+ perimeter.llvm.lib 0.05 0.0026 0.0042 0.0044 0.0220 | 13968 12464 3928 43016 | * 35+0 1+0 1+0
+ mst.llvm.lib 0.05 0.0026 0.0040 0.0052 0.0227 | 16520 25840 14016 71048 | 10 217+1 9+0 9+0
+ sumarray.llvm.lib 0.05 0.0002 0.0003 0.0002 0.0020 | 976 3424 464 6976 | 3 5+0 0+0 0+0
+ treeadd.llvm.lib 0.03 0.0010 0.0011 0.0009 0.0085 | 7928 6424 2088 28432 | * 27+0 1+0 1+0
+ matrix.llvm.lib 0.02 0.0020 0.0013 0.0014 0.0090 | 7856 10416 2200 36232 | * 32+0 0+0 0+0
+ sumarraymalloc.llvm.lib 0.02 0.0006 0.0007 0.0005 0.0056 | 2032 5984 1368 23472 | * 17+0 0+0 0+0
+ </pre><p>
+
+
+
+ <hr>
+ <a name="20021106"><h2>Nov 6, 2002:</h2>
+
+ Notes: Debug build, no globals graph, no array collapsing.<p>
+
+ <pre>
+ Name: LocTime: BUTime: TDTime: TotTime: AnlzTime: LocSize: BUSize: TDSize: TotSize: NumFold NumNodes main __main
+ ackermann.llvm.lib 0.0004 0.0005 0.0004 0.0045 0m0.040s | 6976 992 840 18736 | * 10+0 0+0 0+0
+ ary3.llvm.lib 0.0008 0.0012 0.0012 0.0074 0m0.034s | 7992 7808 2416 34264 | 6 37+0 0+0 0+0
+ fib2.llvm.lib 0.0005 0.0006 0.0004 0.0047 0m0.019s | 1776 5312 1080 23992 | * 14+0 0+0 0+0
+ hash.llvm.lib 0.0020 0.0031 0.0036 0.0157 0m0.046s | 17488 23928 12584 67400 | * 131+0 2+0 2+0
+ heapsort.llvm.lib 0.0006 0.0008 0.0007 0.0061 0m0.023s | 2264 13720 2216 33016 | * 33+0 2+0 2+0
+ hello.llvm.lib 0.0002 0.0002 0.0002 0.0015 0m0.014s | 504 2816 336 3656 | * 2+0 0+0 0+0
+ lists.llvm.lib 0.0029 0.0057 0.0057 0.0203 0m0.077s | 22272 14264 12128 60688 | 57 38+0 0+0 0+0
+ llubenchmark.llvm.lib 0.0012 0.0011 0.0017 0.0111 0m0.036s | 9680 2144 9944 32776 | * 49+8 4+1 4+1
+ matrix.llvm.lib 0.0008 0.0013 0.0014 0.0079 0m0.038s | 7848 10416 2200 36176 | * 32+0 0+0 0+0
+ matrixTranspose.llvm.lib 0.0004 0.0015 0.0019 0.0054 0m0.031s | 9136 14520 25336 48992 | * 10+0 1+0 1+0
+ methcall.llvm.lib 0.0010 0.0018 0.0030 0.0108 0m0.080s | 3952 17528 9024 44160 | 30 112+52 7+4 7+4
+ objinst.llvm.lib 0.0011 0.0018 0.0058 0.0149 0m0.061s | 9480 19064 13192 55392 | 37 163+80 7+4 7+4
+ pi.llvm.lib 0.0005 0.0004 0.0005 0.0032 0m0.027s | 4744 1248 4368 10360 | * 14+0 0+0 0+0
+ printargs.llvm.lib 0.0003 0.0005 0.0003 0.0023 0m0.042s | 888 504 512 1904 | * 5+0 0+0 0+0
+ random.llvm.lib 0.0005 0.0005 0.0005 0.0056 0m0.032s | 1584 4704 5752 25264 | * 21+0 2+0 2+0
+ sumarray.llvm.lib 0.0002 0.0003 0.0002 0.0020 0m0.034s | 976 3424 464 6976 | 3 5+0 0+0 0+0
+ sumarray2d.llvm.lib 0.0010 0.0077 0.0111 0.0216 0m0.047s | 41416 47080 80696 171512 | * 9+0 0+0 0+0
+ sumarraymalloc.llvm.lib 0.0007 0.0007 0.0005 0.0054 0m0.032s | 2032 5984 1368 23472 | * 17+0 0+0 0+0
+ indvars.llvm.lib 0.0018 0.0189 0.0264 0.0490 0m0.065s | 82040 87944 160872 333400 | * 12+0 0+0 0+0
+ bh.llvm.lib 0.0113 0.0128 0.0163 0.0597 0m0.148s | 55112 75768 42928 240056 | 74 400+5 11+0 11+0
+ bisort.llvm.lib 0.0018 0.0024 0.0024 0.0123 0m0.051s | 12776 18296 6808 48952 | * 89+0 4+0 4+0
+ em3d.llvm.lib 0.0035 0.0098 0.0196 0.0490 0m0.103s | 33816 49744 54144 146112 | 10 518+33 14+1 14+1
+ health.llvm.lib 0.0033 0.0061 0.0057 0.0226 0m0.088s | 28432 27992 12640 83992 | 72 151+1 6+0 6+0
+ mst.llvm.lib 0.0025 0.0039 0.0050 0.0192 0m0.074s | 16520 25840 14016 71048 | 10 217+1 9+0 9+0
+ perimeter.llvm.lib 0.0020 0.0032 0.0025 0.0154 0m0.045s | 13968 12720 3928 43272 | * 35+0 1+0 1+0
+ power.llvm.lib 0.0027 0.0039 0.0060 0.0232 0m0.062s | 20960 30136 23504 82696 | * 146+0 4+0 4+0
+ treeadd.llvm.lib 0.0009 0.0010 0.0008 0.0070 0m0.054s | 7928 6424 2088 28432 | * 27+0 1+0 1+0
+ tsp.llvm.lib 0.0035 0.0034 0.0032 0.0187 0m0.064s | 17304 13808 17968 63704 | 18 95+1 4+0 4+0
+ voronoi.llvm.lib 0.0093 0.0193 0.0567 0.1033 0m0.199s | 78560 83336 116312 292200 | 19 1006+0 16+0 16+0
+ optimizer-eval.llvm.lib 0.0099 0.1017 0.4073 0.5492 0m0.674s | 76736 140000 409448 644528 | 58 1259+23 7+0 7+0
+ sgefa.llvm.lib 0.0057 0.0283 0.0357 0.0863 0m0.153s | 82280 96016 67728 270712 | * 121+2 2+0 2+0
+ sieve.llvm.lib 0.0006 0.0020 0.0030 0.0096 0m0.033s | 9872 13808 38872 76312 | * 22+0 1+0 1+0
+ sim.llvm.lib 0.0134 0.2127 1.1230 1.3938 0m1.559s | 62864 98984 200600 457536 | * 1807+206 71+7 71+7
+ 164.gzip.llvm.lib 0.0225 0.0727 0.2910 0.4651 0m1.003s | 235048 421864 1439120 2192624 | 17 9181+106 114+1 114+1
+ 181.mcf.lib 0.0121 0.0354 0.1096 0.1780 0m0.292s | 120504 192920 545720 876032 | 195 753+0 14+0 14+0
+ 197.parser.lib analyze: ../../../include/llvm/Analysis/DSNode.h:74: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ 254.gap.lib analyze: ../../../include/llvm/Analysis/DSNode.h:74: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ 255.vortex.lib analyze: ../../../include/llvm/Analysis/DSNode.h:74: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ 256.bzip2.lib 0.0149 0.0604 0.6503 0.7810 0m1.027s | 210880 387776 3371632 4041800 | 18 5005+76 65+1 65+1
+ 300.twolf.lib 0.1806 0.5248 42.5463 43.8329 0m45.785s | 522056 653816 10076992 11252864 | 1269 78066+4900 410+12 410+12
+ burg.llvm.lib analyze: ../../../include/llvm/Analysis/DSNode.h:74: DSNode::~DSNode(): Assertion `Referrers.empty() && "Referrers to dead node exist!"' failed.
+ </pre>
+
+ <hr>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Wed Nov 6 19:57:57 CST 2002 -->
+ <!-- hhmts start -->
+ Last modified: Thu Nov 14 20:00:50 CST 2002
+ <!-- hhmts end -->
+ </body>
+ </html>
Index: llvm-www/releases/1.0/FAQ.html
diff -c /dev/null llvm-www/releases/1.0/FAQ.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/FAQ.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,162 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+ <h1>
+ <center>
+ LLVM: Frequently Asked Questions
+ </center>
+ </h1>
+
+ <hr>
+
+ <!--=====================================================================-->
+ <h2>
+ <a name="source">Source Code</a>
+ </h2>
+ <!--=====================================================================-->
+
+ <dl compact>
+ <dt> <b>In what language is LLVM written?</b>
+ <dd>
+ All of the LLVM tools and libraries are written in C++ with extensive use
+ of the STL.
+ <p>
+
+ <dt><b>How portable is the LLVM source code?</b>
+ <dd>
+ 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>
+ Some porting problems may exist in the following areas:
+ <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.
+
+ <p>
+
+ <li>The Python test classes are more UNIX-centric than they should be,
+ so porting to non-UNIX like platforms (i.e. Windows, MacOS 9) will
+ require some effort.
+ <p>
+
+ <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.
+ </ul>
+ </dl>
+
+ <hr>
+
+ <!--=====================================================================-->
+ <h2>
+ <a name="build">Build Problems</a>
+ </h2>
+ <!--=====================================================================-->
+
+ <dl compact>
+ <dt><b>When I run configure, it finds the wrong C compiler.</b>
+ <dd>
+ 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.
+
+ 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>
+
+ <dt><b>I compile the code, and I get some error about /localhome</b>.
+ <dd>
+ There are several possible causes for this. The first is that you
+ didn't set a pathname properly when using <tt>configure</tt>, and it
+ defaulted to a pathname that we use on our research machines.
+ <p>
+ Another possibility is that we hardcoded a path in our Makefiles. If
+ you see this, please email the LLVM bug mailing list with the name of
+ the offending Makefile and a description of what is wrong with it.
+
+ <dt><b>The <tt>configure</tt> script finds the right C compiler, but it
+ uses the LLVM linker from a previous build. What do I do?</b>
+ <dd>
+ 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:
+ <ol>
+ <li>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>Run <tt>configure</tt> with an alternative <tt>PATH</tt> that
+ is correct. In a Borne compatible shell, the syntax would be:
+ <p>
+ <tt>PATH=<the path without the bad program> ./configure ...</tt>
+ <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.
+ </ol>
+
+ <dt><b>When creating a dynamic library, I get a strange GLIBC error.</b>
+ <dd>
+ 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>
+
+ <dt><b>I've updated my source tree from CVS, and now my build is trying to
+ use a file/directory that doesn't exist.</b>
+ <dd>
+ 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>
+
+ <dt><b>I've modified a Makefile in my source tree, but my build tree keeps
+ using the old version. What do I do?</b>
+ <dd>
+ 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>
+ <tt>./config.status <relative path to Makefile></tt>
+ <p>
+ If the Makefile is new, you will have to modify the configure script to copy
+ it over.
+ <p>
+
+ <dt><b>I've upgraded to a new version of LLVM, and I get strange build
+ errors.</b>
+ <dd>
+ 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>
+ 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>
+
+ <dt><b>I've built LLVM and am testing it, but the tests freeze.</b>
+ <dd>
+ 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>
+ For example, if you built LLVM with the command:
+ <p>
+ <tt>gmake ENABLE_PROFILING=1</tt>
+ <p>
+ ...then you must run the tests with the following commands:
+ <p>
+ <tt>cd llvm/test<br>gmake ENABLE_PROFILING=1</tt>
+ </dl>
+ <hr>
+
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+
+ </body>
+ </html>
Index: llvm-www/releases/1.0/GettingStarted.html
diff -c /dev/null llvm-www/releases/1.0/GettingStarted.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/GettingStarted.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,1049 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html>
+ <head>
+ <title>Getting Started with LLVM System</title>
+ </head>
+
+ <body bgcolor=white>
+ <center><h1>Getting Started with the LLVM System<br><font size=3>By: <a
+ href="mailto:gshi1 at uiuc.edu">Guochun Shi</a>,
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
+ <a href="mailto:criswell at uiuc.edu">John Criswell</a>,
+ <a href="http://misha.brukman.net">Misha Brukman</a>, and
+ <a href="http://www.cs.uiuc.edu/~vadve">Vikram Adve</a>
+ </font></h1></center>
+
+ <!--=====================================================================-->
+ <h2><a name="Contents">Contents</a></h2>
+ <!--=====================================================================-->
+
+ <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><a href="#starting">Getting Started with LLVM</a>
+ <ol>
+ <li><a href="#terminology">Terminology and Notation</tt></a>
+ <li><a href="#environment">Setting Up Your Environment</a>
+ <li><a href="#unpack">Unpacking the LLVM Archives</a>
+ <li><a href="#checkout">Checkout LLVM from CVS</a>
+ <li><a href="#installcf">Install the GCC Front End</a>
+ <li><a href="#config">Local LLVM Configuration</tt></a>
+ <li><a href="#compile">Compiling the LLVM Suite Source Code</a>
+ <li><a href="#objfiles">The Location of LLVM Object Files</tt></a>
+ </ol>
+ <li><a href="#layout">Program layout</a>
+ <ol>
+ <li><a href="#cvsdir"><tt>CVS</tt> directories</a>
+ <li><a href="#include"><tt>llvm/include</tt></a>
+ <li><a href="#lib"><tt>llvm/lib</tt></a>
+ <li><a href="#runtime"><tt>llvm/runtime</tt></a>
+ <li><a href="#test"><tt>llvm/test</tt></a>
+ <li><a href="#tools"><tt>llvm/tools</tt></a>
+ <li><a href="#utils"><tt>llvm/utils</tt></a>
+ </ol>
+ <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>
+
+
+ <!--=====================================================================-->
+ <center>
+ <h2><a name="overview"><b>Overview</b></a></h2>
+ </center>
+ <hr>
+ <!--=====================================================================-->
+
+ Welcome to LLVM! In order to get started, you first need to know some
+ basic information.
+
+ <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,
+ bytecode analyzer, and bytecode optimizer. It also contains a test suite
+ that can be used to test the LLVM tools and the GCC front end.
+ <p>
+ The second piece is the GCC front end. This component provides a version
+ of GCC that compiles C and C++ code into LLVM bytecode. Currently, the
+ GCC front end is a modified version of GCC 3.4 (we track the GCC 3.4
+ development). Once compiled into LLVM bytecode, a program can be
+ manipulated with the LLVM tools from the LLVM suite.
+
+ <!--=====================================================================-->
+ <center>
+ <h2><a name="quickstart"><b>Getting Started Quickly (A Summary)</b></a></h2>
+ </center>
+ <hr>
+ <!--=====================================================================-->
+
+ Here's the short story for getting up and running quickly with LLVM:
+ <ol>
+ <li>Install the GCC front end:
+ <ol>
+ <li><tt>cd <i>where-you-want-the-C-front-end-to-live</i></tt>
+ <li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf
+ -</tt>
+ <li><b>Sparc Only:</b><br>
+ <tt>
+ cd cfrontend/sparc<br>
+ ./fixheaders
+ </tt>
+ </ol>
+
+ <p>
+
+ <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.tar.gz | tar -xvf -</tt>
+ <li><tt>cd llvm</tt>
+ </ol>
+
+ <p>
+
+ <li>With anonymous CVS access:
+ <ol>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+ <li><tt>cvs -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login</tt>
+ <li>Hit the return key when prompted for the password.
+ <li><tt>cvs -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm</tt>
+ <li><tt>cd llvm</tt>
+ </ol>
+ </ul>
+ </ul>
+
+ <p>
+
+ <li>Configure the LLVM Build Environment
+ <ol>
+ <li>Change directory to where you want to store the LLVM object
+ files and run <tt>configure</tt> to configure the Makefiles and
+ header files for the default platform.
+ Useful options include:
+ <ul>
+ <li><tt>--with-llvmgccdir=<i>directory</i></tt>
+ <br>
+ Specify where the LLVM GCC frontend is installed.
+ <p>
+
+ <li><tt>--enable-spec2000=<i>directory</i></tt>
+ <br>
+ Enable the SPEC2000 benchmarks for testing. The SPEC2000
+ benchmarks should be available in <tt><i>directory</i></tt>.
+ </ul>
+ </ol>
+
+ <p>
+
+ <li>Build the LLVM Suite
+ <ol>
+ <li>Set your LLVM_LIB_SEARCH_PATH environment variable.
+ <li><tt>gmake -k |& tee gnumake.out
+ # this is csh or tcsh syntax</tt>
+ </ol>
+
+ <p>
+
+ </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.
+
+ <!--=====================================================================-->
+ <center>
+ <h2><a name="requirements"><b>Requirements</b></a></h2>
+ </center>
+ <hr>
+ <!--=====================================================================-->
+
+ 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.
+
+ <!--=====================================================================-->
+ <h3><a name="hardware"><b>Hardware</b></a></h3>
+ <!--=====================================================================-->
+ LLVM is known to work on the following platforms:
+ <ul>
+ <li> Linux on x86 (Pentium and above)
+ <ul>
+ <li> Approximately 760 MB of Free Disk Space
+ <ul>
+ <li>Source code: 30 MB
+ <li>Object code: 670 MB
+ <li>GCC front end: 60 MB
+ </ul>
+ </ul>
+
+ <p>
+
+ <li> Solaris on SparcV9 (Ultrasparc)
+ <ul>
+ <li> Approximately 1.24 GB of Free Disk Space
+ <ul>
+ <li>Source code: 30 MB
+ <li>Object code: 1000 MB
+ <li>GCC front end: 210 MB
+ </ul>
+ </ul>
+ </ul>
+
+ 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
+ bytecode. Code generation should work as well, although the generated
+ native code may not work on your platform.
+ <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 try to compile it on your platform.
+ </p>
+
+ <!--=====================================================================-->
+ <h3><a name="software"><b>Software</b></a></h3>
+ <!--=====================================================================-->
+ <p>
+
+ Compiling LLVM requires that you have several software packages installed:
+
+ <ul compact>
+ <li>
+ <a href="http://gcc.gnu.org">GCC 3.x with C and C++ language support</a>
+
+ <li>
+ <a href="http://savannah.gnu.org/projects/make">GNU Make</a>
+
+ <li>
+ <a href="http://www.gnu.org/software/flex">Flex</a>
+
+ <li>
+ <a href="http://www.gnu.org/software/bison/bison.html">Bison</a>
+ </ul>
+
+ <p>
+ There are some additional tools that you may want to have when working with
+ LLVM:
+ </p>
+
+ <ul>
+ <li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A>
+ <li><A href="http://savannah.gnu.org/projects/m4">GNU M4</A>
+ <p>
+ If you want to make changes to the configure scripts, you will need
+ GNU autoconf (2.57 or higher), and consequently, GNU M4 (version 1.4
+ or higher).
+ </p>
+
+ <li><A href="http://www.codesourcery.com/qm/qmtest">QMTest</A>
+ <li><A href="http://www.python.org">Python</A>
+ <p>
+ These are needed to use the LLVM test suite.
+ </ul>
+
+
+ <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.
+ A <a href="#starting">complete guide to installation</a> is provided in the
+ next section.
+
+ <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.
+
+ <!--=====================================================================-->
+ <center>
+ <h2><a name="starting"><b>Getting Started with LLVM</b></a></h2>
+ </center>
+ <hr>
+ <!--=====================================================================-->
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="terminology">Terminology and Notation</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <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 compact>
+ <dt>SRC_ROOT
+ <dd>
+ This is the top level directory of the LLVM source tree.
+ <p>
+
+ <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).
+ <p>
+
+ <dt>LLVMGCCDIR
+ <dd>
+ This is the where the LLVM GCC Front End is installed.
+ <p>
+ For the pre-built GCC front end binaries, the LLVMGCCDIR is
+ <tt>cfrontend/<i>platform</i>/llvm-gcc</tt>.
+ </dl>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="environment">Setting Up Your Environment</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <p>
+ In order to compile and use LLVM, you will need to set some environment
+ variables. There are also some shell aliases which you may find useful.
+ You can set these on the command line, or better yet, set them in your
+ <tt>.cshrc</tt> or <tt>.profile</tt>.
+
+ <dl compact>
+ <dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt><i>LLVMGCCDIR</i>/llvm-gcc/bytecode-libs</tt>
+ <dd>
+ This environment variable helps the LLVM GCC front end find bytecode
+ libraries that it will need for compilation.
+ <p>
+
+ <dt>alias llvmgcc <i>LLVMGCCDIR</i><tt>/llvm-gcc/bin/gcc</tt>
+ <dt>alias llvmg++ <i>LLVMGCCDIR</i><tt>/llvm-gcc/bin/g++</tt>
+ <dd>
+ This alias allows you to use the LLVM C and C++ front ends without putting
+ them in your <tt>PATH</tt> or typing in their complete pathnames.
+ </dl>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="unpack">Unpacking the LLVM Archives</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <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 three files. Each
+ file is a TAR archive that is compressed with the gzip program.
+ </p>
+
+ <p> The three files are as follows:
+ <dl compact>
+ <dt>llvm.tar.gz
+ <dd>This is the source code to the LLVM suite.
+ <p>
+
+ <dt>cfrontend.sparc.tar.gz
+ <dd>This is the binary release of the GCC front end for Solaris/Sparc.
+ <p>
+
+ <dt>cfrontend.x86.tar.gz
+ <dd>This is the binary release of the GCC front end for Linux/x86.
+ </dl>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="checkout">Checkout LLVM from CVS</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <p>If you have access to our CVS repository, you can get a fresh copy of
+ the entire source code. All you need to do is check it out from CVS as
+ follows:
+ <ul>
+ <li><tt>cd <i>where-you-want-llvm-to-live</i></tt>
+ <li><tt>cvs -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login</tt>
+ <li>Hit the return key when prompted for the password.
+ <li><tt>cvs -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm</tt>
+ </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>
+ Note that the GCC front end is not included in the CVS repository. You
+ should have downloaded the binary distribution for your platform.
+ </p>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="installcf">Install the GCC Front End</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <p>
+ Before configuring and compiling the LLVM suite, you need to extract the
+ LLVM GCC front end from the binary distribution. It is used for building
+ the
+ bytecode libraries later used by the GCC front end for linking programs, and
+ its location must be specified when the LLVM suite is configured.
+ </p>
+
+ <p>
+ To install the GCC front end, do the following:
+ <ol>
+ <li><tt>cd <i>where-you-want-the-front-end-to-live</i></tt>
+ <li><tt>gunzip --stdout cfrontend.<i>platform</i>.tar.gz | tar -xvf
+ -</tt>
+ </ol>
+
+ If you are on a Sparc/Solaris machine, you will need to fix the header
+ files:
+
+ <p>
+
+ <tt>
+ cd cfrontend/sparc
+ <br>
+ ./fixheaders
+ </tt>
+
+ <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="CFEBuildInstrs.html">building the GCC front end from source.</a>
+ This is not for the faint of heart, so be forewarned.
+ </p>
+ <!------------------------------------------------------------------------->
+ <h3><a name="config">Local LLVM Configuration</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <p>Once checked out from the CVS repository, the LLVM suite source code
+ must be configured via the <tt>configure</tt> script. This script sets
+ variables in <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 build LLVM.
+
+ <p>
+ The following environment variables are used by the <tt>configure</tt>
+ script to configure the build system:
+ </p>
+
+ <table border=1>
+ <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 compact>
+ <dt><i>--with-llvmgccdir=LLVMGCCDIR</i>
+ <dd>
+ Path to the location where the LLVM C front end binaries and
+ associated libraries will be installed.
+ <p>
+ <dt><i>--enable-optimized</i>
+ <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).
+ <p>
+ <dt><i>--enable-jit</i>
+ <dd>
+ Compile the Just In Time (JIT) 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.
+ <p>
+ <dt><i>--enable-spec2000</i>
+ <dt><i>--enable-spec2000=<<tt>directory</tt>></i>
+ <dd>
+ Enable the use of SPEC2000 when testing LLVM. This is disabled by default
+ (unless <tt>configure</tt> finds SPEC2000 installed). By specifying
+ <tt>directory</tt>, you can tell configure where to find the SPEC2000
+ benchmarks. If <tt>directory</tt> is left unspecified, <tt>configure</tt>
+ uses the default value
+ <tt>/home/vadve/shared/benchmarks/speccpu2000/benchspec</tt>.
+ </dl>
+
+ <p>
+ To configure LLVM, follow these steps:
+ <ol>
+ <li>Change directory into the object root directory:
+ <br>
+ <tt>cd <i>OBJ_ROOT</i></tt>
+ <p>
+
+ <li>Run the <tt>configure</tt> script located in the LLVM source tree:
+ <br>
+ <tt><i>SRC_ROOT</i>/configure</tt>
+ <p>
+ </ol>
+ </p>
+
+ In addition to running <tt>configure</tt>, you must set the
+ <tt>LLVM_LIB_SEARCH_PATH</tt> environment variable in your startup scripts.
+ This environment variable is used to locate "system" libraries like
+ "<tt>-lc</tt>" and "<tt>-lm</tt>" when linking. This variable should be set
+ to the absolute path for the bytecode-libs subdirectory of the GCC front end
+ install, or <i>LLVMGCCDIR</i>/llvm-gcc/bytecode-libs. For example, one might
+ set <tt>LLVM_LIB_SEARCH_PATH</tt> to
+ <tt>/home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs</tt> for the X86
+ version of the GCC front end on our research machines.<p>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="compile">Compiling the LLVM Suite Source Code</a></h3>
+ <!------------------------------------------------------------------------->
+
+ Once you have configured LLVM, you can build it. There are three types of
+ builds:
+
+ <dl compact>
+ <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.
+ <p>
+
+ <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.
+ <p>
+
+ <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>
+
+ Once you have LLVM configured, you can build it by entering the
+ <i>OBJ_ROOT</i> directory and issuing the following command:
+ <p>
+ <tt>gmake</tt>
+
+ <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>
+
+ <p>
+ <tt>gmake -j2</tt>
+
+ <p>
+ There are several special targets which are useful when working with the LLVM
+ source code:
+
+ <dl compact>
+ <dt><tt>gmake clean</tt>
+ <dd>
+ Removes all files generated by the build. This includes object files,
+ generated C/C++ files, libraries, and executables.
+ <p>
+
+ <dt><tt>gmake distclean</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.
+ <p>
+
+ <dt><tt>gmake install</tt>
+ <dd>
+ Installs LLVM files into the proper location. For the most part,
+ this does nothing, but it does install bytecode libraries into the
+ GCC front end's bytecode library directory. If you need to update
+ your bytecode libraries, this is the target to use once you've built
+ them.
+ <p>
+
+ </dl>
+
+ It is also possible to override default values from <tt>configure</tt> by
+ declaring variables on the command line. The following are some examples:
+
+ <dl compact>
+ <dt><tt>gmake ENABLE_OPTIMIZED=1</tt>
+ <dd>
+ Perform a Release (Optimized) build.
+ <p>
+
+ <dt><tt>gmake ENABLE_PROFILING=1</tt>
+ <dd>
+ Perform a Profiling build.
+ <p>
+
+ <dt><tt>gmake VERBOSE=1</tt>
+ <dd>
+ Print what <tt>gmake</tt> is doing on standard output.
+ <p>
+ </dl>
+
+ 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.
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="objfiles">The Location of LLVM Object Files</a></h3>
+ <!------------------------------------------------------------------------->
+
+ <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>
+ This is accomplished in the typical autoconf manner:
+ <ul>
+ <li>Change directory to where the LLVM object files should live:
+ <p>
+ <tt>cd <i>OBJ_ROOT</i></tt>
+
+ <li>Run the <tt>configure</tt> script found in the LLVM source directory:
+ <p>
+ <tt><i>SRC_ROOT</i>/configure</tt>
+ </ul>
+
+ <p>
+ The LLVM build will place files underneath <i>OBJ_ROOT</i> in directories
+ named after the build type:
+ </p>
+
+ <dl compact>
+ <dt>Debug Builds
+ <dd>
+ <dl compact>
+ <dt>Tools
+ <dd><tt><i>OBJ_ROOT</i>/tools/Debug</tt>
+ <dt>Libraries
+ <dd><tt><i>OBJ_ROOT</i>/lib/Debug</tt>
+ </dl>
+ <p>
+
+ <dt>Release Builds
+ <dd>
+ <dl compact>
+ <dt>Tools
+ <dd><tt><i>OBJ_ROOT</i>/tools/Release</tt>
+ <dt>Libraries
+ <dd><tt><i>OBJ_ROOT</i>/lib/Release</tt>
+ </dl>
+ <p>
+
+ <dt>Profile Builds
+ <dd>
+ <dl compact>
+ <dt>Tools
+ <dd><tt><i>OBJ_ROOT</i>/tools/Profile</tt>
+ <dt>Libraries
+ <dd><tt><i>OBJ_ROOT</i>/lib/Profile</tt>
+ </dl>
+ </dl>
+
+ <!--=====================================================================-->
+ <center>
+ <h2><a name="layout"><b>Program Layout</b></a></h2>
+ </center>
+ <hr>
+ <!--=====================================================================-->
+
+ <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.cs.uiuc.edu/doxygen/">http://llvm.cs.uiuc.edu/doxygen/</a></tt>.
+ The following is a brief introduction to code layout:
+ </p>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="cvsdir"><tt>CVS</tt> directories</a></h3>
+ <!------------------------------------------------------------------------->
+
+ Every directory checked out of CVS will contain a <tt>CVS</tt> directory;
+ for the most part these can just be ignored.
+
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="include"><tt>llvm/include</tt></a></h3>
+ <!------------------------------------------------------------------------->
+
+ This directory contains public header files exported from the LLVM
+ library. The three main subdirectories of this directory are:<p>
+
+ <ol>
+ <li><tt>llvm/include/llvm</tt> - 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...
+
+ <li><tt>llvm/include/Support</tt> - This directory contains generic
+ support libraries that are independent of LLVM, but are used by LLVM.
+ For example, some C++ STL utilities and a Command Line option processing
+ library store their header files here.
+
+ <li><tt>llvm/include/Config</tt> - 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.
+ </ol>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="lib"><tt>llvm/lib</tt></a></h3>
+ <!------------------------------------------------------------------------->
+
+ 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 compact>
+ <dt><tt>llvm/lib/VMCore/</tt><dd> This directory holds the core LLVM
+ source files that implement core classes like Instruction and BasicBlock.
+
+ <dt><tt>llvm/lib/AsmParser/</tt><dd> This directory holds the source code
+ for the LLVM assembly language parser library.
+
+ <dt><tt>llvm/lib/ByteCode/</tt><dd> This directory holds code for reading
+ and write LLVM bytecode.
+
+ <dt><tt>llvm/lib/CWriter/</tt><dd> This directory implements the LLVM to C
+ converter.
+
+ <dt><tt>llvm/lib/Analysis/</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...
+
+ <dt><tt>llvm/lib/Transforms/</tt><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...
+
+ <dt><tt>llvm/lib/Target/</tt><dd> This directory contains files that
+ describe various target architectures for code generation. For example,
+ the llvm/lib/Target/Sparc directory holds the Sparc machine
+ description.<br>
+
+ <dt><tt>llvm/lib/CodeGen/</tt><dd> This directory contains the major parts
+ of the code generator: Instruction Selector, Instruction Scheduling, and
+ Register Allocation.
+
+ <dt><tt>llvm/lib/Support/</tt><dd> This directory contains the source code
+ that corresponds to the header files located in
+ <tt>llvm/include/Support/</tt>.
+ </dl>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="runtime"><tt>llvm/runtime</tt></a></h3>
+ <!------------------------------------------------------------------------->
+
+ <p>
+ This directory contains libraries which are compiled into LLVM bytecode 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>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="test"><tt>llvm/test</tt></a></h3>
+ <!------------------------------------------------------------------------->
+
+ <p>This directory contains regression tests and source code that is used to
+ test the LLVM infrastructure.
+ </p>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="tools"><tt>llvm/tools</tt></a></h3>
+ <!------------------------------------------------------------------------->
+
+ <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.</p>
+
+ <dl compact>
+ <dt>
+
+ <dt><tt><b>analyze</b></tt><dd> <tt>analyze</tt> is used to run a specific
+ analysis on an input LLVM bytecode file and print out the results. It is
+ primarily useful for debugging analyses, or familiarizing yourself with
+ what an analysis does.<p>
+
+ <dt><tt><b>bugpoint</b></tt><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>.<p>
+
+ <dt><tt><b>llvm-ar</b></tt><dd>The archiver produces an archive containing
+ the given LLVM bytecode files, optionally with an index for faster
+ lookup.<p>
+
+ <dt><tt><b>llvm-as</b></tt><dd>The assembler transforms the human readable
+ LLVM assembly to LLVM bytecode.<p>
+
+ <dt><tt><b>llvm-dis</b></tt><dd>The disassembler transforms the LLVM
+ bytecode to human readable LLVM assembly. Additionally, it can convert
+ LLVM bytecode to C, which is enabled with the <tt>-c</tt> option.<p>
+
+ <dt><tt><b>llvm-link</b></tt><dd> <tt>llvm-link</tt>, not surprisingly,
+ links multiple LLVM modules into a single program.<p>
+
+ <dt><tt><b>lli</b></tt><dd> <tt>lli</tt> is the LLVM interpreter, which
+ can directly execute LLVM bytecode (although very slowly...). In addition
+ to a simple interpreter, <tt>lli</tt> also has a tracing mode (entered by
+ specifying <tt>-trace</tt> on the command line). Finally, for
+ architectures that support it (currently only x86 and Sparc), 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.<p>
+
+ <dt><tt><b>llc</b></tt><dd> <tt>llc</tt> is the LLVM backend compiler,
+ which translates LLVM bytecode to a SPARC or x86 assembly file.<p>
+
+ <dt><tt><b>llvmgcc</b></tt><dd> <tt>llvmgcc</tt> is a GCC-based C frontend
+ that has been retargeted to emit LLVM code as the 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. The source code for the
+ <tt>llvmgcc</tt> tool is currently not included in the LLVM cvs tree
+ because it is quite large and not very interesting.<p>
+
+ <ol>
+ <dt><tt><b>gccas</b></tt><dd> This tool is invoked by the
+ <tt>llvmgcc</tt> frontend as the "assembler" part of the compiler. This
+ tool actually assembles LLVM assembly to LLVM bytecode,
+ performs a variety of optimizations, and outputs LLVM bytecode. Thus
+ when you invoke <tt>llvmgcc -c x.c -o x.o</tt>, you are causing
+ <tt>gccas</tt> to be run, which writes the <tt>x.o</tt> file (which is
+ an LLVM bytecode file that can be disassembled or manipulated just like
+ any other bytecode file). The command line interface to <tt>gccas</tt>
+ is designed to be as close as possible to the <b>system</b>
+ `<tt>as</tt>' utility so that the gcc frontend itself did not have to be
+ modified to interface to a "weird" assembler.<p>
+
+ <dt><tt><b>gccld</b></tt><dd> <tt>gccld</tt> links together several LLVM
+ bytecode files into one bytecode file and does some optimization. It is
+ the linker invoked by the GCC frontend when multiple .o files need to be
+ linked together. Like <tt>gccas</tt>, the command line interface of
+ <tt>gccld</tt> is designed to match the system linker, to aid
+ interfacing with the GCC frontend.<p>
+ </ol>
+
+ <dt><tt><b>opt</b></tt><dd> <tt>opt</tt> reads LLVM bytecode, applies a
+ series of LLVM to LLVM transformations (which are specified on the command
+ line), and then outputs the resultant bytecode. The '<tt>opt --help</tt>'
+ command is a good way to get a list of the program transformations
+ available in LLVM.<p>
+
+ </dl>
+
+ <!------------------------------------------------------------------------->
+ <h3><a name="utils"><tt>llvm/utils</tt></a></h3>
+ <!------------------------------------------------------------------------->
+
+ 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.
+
+ <dl compact>
+ <td><tt><b>Burg/</b></tt><dd> <tt>Burg</tt> is an instruction selector
+ generator -- it builds trees on which it then performs pattern-matching to
+ select instructions according to the patterns the user has specified. Burg
+ is currently used in the Sparc V9 backend.<p>
+
+ <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>.<p>
+
+ <dt><tt><b>cvsupdate</b></tt><dd> <tt>cvsupdate</tt> is a script that will
+ update your CVS tree, but produce a much cleaner and more organized output
+ than simply running <tt>`cvs up -dP'</tt> will. For example, it will group
+ together all the new and updated files and modified files in separate
+ sections, so you can see at a glance what has changed. If you are at the
+ top of your LLVM CVS tree, running <tt>utils/cvsupdate</tt> is the
+ preferred way of updating the tree.<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ <dt><tt><b>NightlyTest.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.cs.uiuc.edu/">LLVM homepage</a>.<p>
+
+ <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.<p>
+
+ <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.<p>
+
+ </dl>
+
+ <!--=====================================================================-->
+ <h2>
+ <center><a name="tutorial">An Example Using the LLVM Tool Chain</center>
+ </h2>
+ <hr>
+ <!--=====================================================================-->
+
+ <ol>
+ <li>First, create a simple C file, name it 'hello.c':
+ <pre>
+ #include <stdio.h>
+ int main() {
+ printf("hello world\n");
+ return 0;
+ }
+ </pre>
+
+ <li>Next, compile the C file into a LLVM bytecode file:<p>
+
+ <tt>% llvmgcc hello.c -o hello</tt><p>
+
+ This will create two result files: <tt>hello</tt> and
+ <tt>hello.bc</tt>. The <tt>hello.bc</tt> is the LLVM bytecode that
+ corresponds the the compiled program and the library facilities that it
+ required. <tt>hello</tt> is a simple shell script that runs the bytecode
+ file with <tt>lli</tt>, making the result directly executable.<p>
+
+ <li>Run the program. To make sure the program ran, execute one of the
+ following commands:<p>
+
+ <tt>% ./hello</tt><p>
+
+ or<p>
+
+ <tt>% lli hello.bc</tt><p>
+
+ <li>Use the <tt>llvm-dis</tt> utility to take a look at the LLVM assembly
+ code:<p>
+
+ <tt>% llvm-dis < hello.bc | less</tt><p>
+
+ <li>Compile the program to native Sparc assembly using the code
+ generator (assuming you are currently on a Sparc system):<p>
+
+ <tt>% llc hello.bc -o hello.s</tt><p>
+
+ <li>Assemble the native sparc assemble file into a program:<p>
+
+ <tt>% /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.sparc</tt><p>
+
+ <li>Execute the native sparc program:<p>
+
+ <tt>% ./hello.sparc</tt><p>
+
+ </ol>
+
+
+ <!--=====================================================================-->
+ <h2>
+ <center><a name="problems">Common Problems</a></center>
+ </h2>
+ <hr>
+ <!--=====================================================================-->
+
+ 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.
+
+ <!--=====================================================================-->
+ <h2><center><a name="links">Links</a></center></h2>
+ <hr>
+ <!--=====================================================================-->
+
+ <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.cs.uiuc.edu/">LLVM homepage</a></li>
+ <li><a href="http://llvm.cs.uiuc.edu/doxygen/">LLVM doxygen tree</a></li>
+ <li><a href="http://llvm.cs.uiuc.edu/docs/Projects.html">Starting a Project that Uses LLVM</a></li>
+ </ul>
+
+ <hr>
+
+ If you have any questions or run into any snags (or you have any
+ additions...), please send an email to
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a>.</p>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+
+ <!-- Created: Mon Jul 1 02:29:02 CDT 2002 -->
+ <!-- hhmts start -->
+ Last modified: Mon Aug 11 13:52:22 CDT 2003
+ <!-- hhmts end -->
+ </body>
+ </html>
Index: llvm-www/releases/1.0/HowToSubmitABug.html
diff -c /dev/null llvm-www/releases/1.0/HowToSubmitABug.html:1.1
*** /dev/null Fri Oct 24 15:51:50 2003
--- llvm-www/releases/1.0/HowToSubmitABug.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,282 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>How to submit an LLVM bug report</title></head>
+
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>How to submit an LLVM bug report</b></font></td>
+ </tr></table>
+
+ <table border=0 width=100%>
+ <tr><td valign=top>
+ <p><font size=+1>
+ <ol>
+ <li><a href="#introduction">Introduction - Got bugs?</a>
+ <li><a href="#crashers">Crashing Bugs</a>
+ <ul>
+ <li><a href="#front-end">Front-end bugs</a>
+ <li><a href="#gccas">GCCAS bugs</a>
+ <li><a href="#gccld">GCCLD bugs</a>
+ <li><a href="#passes">Bugs in LLVM passes</a>
+ </ul>
+ <li><a href="#miscompilations">Miscompilations</a>
+ <li><a href="#codegen">Incorrect code generation (JIT and LLC)</a>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and
+ <a href="http://misha.brukman.net">Misha Brukman</a></b><p>
+ </ol><p></font>
+ </td><td valign=top align=right>
+ <img src="Debugging.gif" width=444 height=314>
+ </td></tr>
+ </table>
+
+
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="introduction">Introduction - Got bugs?
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ 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. 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>
+
+ Once you have a reduced test-case, go to
+ <a href="http://llvm.cs.uiuc.edu/bugs/enter_bug.cgi">
+ the LLVM Bug Tracking System,
+ </a>
+ select the catagory in which the bug falls, and fill out the form with the
+ necessary details. The bug description should contain the following
+ information:
+ <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 CVS
+ repository).</li>
+ </ul>
+
+ <p>
+ Thanks for helping us make LLVM better!<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="crashers">Crashing Bugs
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ More often than not, bugs in the compiler cause it to crash - often due to an
+ assertion failure of some sort. If you are running <tt><b>opt</b></tt> or
+ <tt><b>analyze</b></tt> directly, and something crashes, jump to the section on
+ <a href="#passes">bugs in LLVM passes</a>. Otherwise, the most important
+ piece of the puzzle is to figure out if it is the GCC-based front-end that is
+ buggy or if it's one of the LLVM tools that has problems.<p>
+
+ To figure out which program is crashing (the front-end, <tt><b>gccas</b></tt>,
+ or <tt><b>gccld</b></tt>), run the <tt><b>llvm-gcc</b></tt> command line as you
+ were when the crash occurred, but add a <tt>-v</tt> option to the command line.
+ The compiler will print out a bunch of stuff, and should end with telling you
+ that one of <tt><b>cc1</b></tt>, <tt><b>gccas</b></tt>, or <tt><b>gccld</b></tt>
+ crashed.<p>
+
+ <ul>
+ <li>If <tt><b>cc1</b></tt> crashed, you found a problem with the front-end.
+ Jump ahead to the section on <a href="#front-end">front-end bugs</a>.
+ <li>If <tt><b>gccas</b></tt> crashed, you found a bug in <a href="#gccas">one of
+ the passes in <tt><b>gccas</b></tt></a>.
+ <li>If <tt><b>gccld</b></tt> crashed, you found a bug in <a href="#gccld">one
+ of the passes in <tt><b>gccld</b></tt></a>.
+ <li>Otherwise, something really weird happened. Email the list with what you
+ have at this point.
+ </ul><p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="front-end">Front-end bugs
+ </b></font></td></tr></table><ul>
+
+ 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> (containing LLVM
+ assembly code), for each compiled <tt><i>foo</i>.c</tt> file. Send us
+ the <tt><i>foo</i>.i</tt> file, along with a brief description of the
+ error it caused.<p>
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="gccas">GCCAS bugs
+ </b></font></td></tr></table><ul>
+
+ If you find that a bug crashes in the <tt><b>gccas</b></tt> stage of
+ compilation, compile your test-case to a <tt>.s</tt> file with the
+ <tt>-save-temps</tt> option to <tt><b>llvm-gcc</b></tt>. Then run:<p>
+
+ <pre>
+ <b>gccas</b> -debug-pass=Arguments < /dev/null -o - > /dev/null
+ </pre><p>
+
+ ... which will print a list of arguments, indicating the list of passes that
+ <tt><b>gccas</b></tt> runs. Once you have the input file and the list of
+ passes, go to the section on <a href="#passes">debugging bugs in LLVM
+ passes</a>.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="gccld">GCCLD bugs
+ </b></font></td></tr></table><ul>
+
+ If you find that a bug crashes in the <tt><b>gccld</b></tt> stage of
+ compilation, gather all of the <tt>.o</tt> bytecode files and libraries that are
+ being linked together (the "<tt><b>llvm-gcc</b> -v</tt>" output should include
+ the full list of objects linked). Then run:<p>
+
+ <pre>
+ <b>llvm-as</b> < /dev/null > null.bc
+ <b>gccld</b> -debug-pass=Arguments null.bc
+ </pre><p>
+
+ ... which will print a list of arguments, indicating the list of passes that
+ <tt><b>gccld</b></tt> runs. Once you have the input files and the list of
+ passes, go to the section on <a href="#passes">debugging bugs in LLVM
+ passes</a>.<p>
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="passes">Bugs in LLVM passes
+ </b></font></td></tr></table><ul>
+
+ At this point, you should have some number of LLVM assembly files or bytecode
+ files and a list of passes which crash when run on the specified input. In
+ order to reduce the list of passes (which is probably large) and the input to
+ something tractable, use the <tt><b>bugpoint</b></tt> tool as follows:<p>
+
+ <pre>
+ <b>bugpoint</b> <input files> <list of passes>
+ </pre><p>
+
+ <tt><b>bugpoint</b></tt> will print a bunch of output as it reduces the
+ test-case, but it should eventually print something like this:<p>
+
+ <pre>
+ ...
+ Emitted bytecode to 'bugpoint-reduced-simplified.bc'
+
+ *** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -licm
+ </pre><p>
+
+ Once you complete this, please send the LLVM bytecode file and the command line
+ to reproduce the problem to the llvmbugs mailing list.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="miscompilations">Miscompilations</a>
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ A miscompilation occurs when a pass does not correctly transform a program, thus
+ producing errors that are only noticed during execution. This is different from
+ producing invalid LLVM code (i.e., code not in SSA form, using values before
+ defining them, etc.) which the verifier will check for after a pass finishes its
+ run.<p>
+
+ To debug a miscompilation, you should choose which program you wish to run the
+ output through, e.g. C backend, the JIT, or LLC, and a selection of passes, one
+ of which may be causing the error, and run, for example:
+
+ <pre>
+ <b>bugpoint</b> -run-cbe [... optimization passes ...] file-to-test.bc
+ </pre>
+
+ <tt>bugpoint</tt> will try to narrow down your list of passes to the one pass
+ that causes an error, and simplify the bytecode file as much as it can to assist
+ you. It will print a message letting you know how to reproduce the resulting
+ error.
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="codegen">Incorrect code generation</a>
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ To debug the JIT:
+ <pre>
+ <b>bugpoint</b> -run-jit -output=[correct output file] [bytecodefile]
+ </pre>
+
+ Similarly, to debug the LLC, one would run:
+ <pre>
+ <b>bugpoint</b> -run-llc -output=[correct output file] [bytecodefile]
+ </pre>
+
+ At the end of a successful <tt>bugpoint</tt> run, you will be presented
+ with two bytecode 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>
+
+ To reproduce the error that <tt>bugpoint</tt> found, it is sufficient to do the
+ following:
+
+ <ol>
+ <li>Regenerate the shared object from the safe bytecode file:<br>
+ <pre>
+ <b>llvm-dis</b> -c safe.bc -o safe.c<br>
+ <b>gcc</b> -shared safe.c -o safe.so
+ </pre></li>
+ <li>If debugging LLC, compile test bytecode native and link with the shared object:<br>
+ <pre>
+ <b>llc</b> test.bc -o test.s -f<br>
+ gcc test.s safe.so -o test.llc<br>
+ ./test.llc [program options]
+ </pre></li>
+ <p>
+ If debugging the JIT, load the shared object and supply the test bytecode:<br>
+ <pre>
+ <b>lli</b> -load=safe.so test.bc [program options]
+ </pre></li>
+ </ol>
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr><font size-1>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Aug 6 15:00:33 CDT 2002 -->
+ <!-- hhmts start -->
+ Last modified: Tue Oct 14 15:57:47 CDT 2003
+ <!-- hhmts end -->
+ </font></body></html>
Index: llvm-www/releases/1.0/LangRef.html
diff -c /dev/null llvm-www/releases/1.0/LangRef.html:1.1
*** /dev/null Fri Oct 24 15:51:51 2003
--- llvm-www/releases/1.0/LangRef.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,1957 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>LLVM Assembly Language Reference Manual</title></head>
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+5 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>LLVM Language Reference Manual</b></font></td>
+ </tr></table>
+
+ <ol>
+ <li><a href="#abstract">Abstract</a>
+ <li><a href="#introduction">Introduction</a>
+ <li><a href="#identifiers">Identifiers</a>
+ <li><a href="#typesystem">Type System</a>
+ <ol>
+ <li><a href="#t_primitive">Primitive Types</a>
+ <ol>
+ <li><a href="#t_classifications">Type Classifications</a>
+ </ol>
+ <li><a href="#t_derived">Derived Types</a>
+ <ol>
+ <li><a href="#t_array" >Array Type</a>
+ <li><a href="#t_function">Function Type</a>
+ <li><a href="#t_pointer">Pointer Type</a>
+ <li><a href="#t_struct" >Structure Type</a>
+ <!-- <li><a href="#t_packed" >Packed Type</a> -->
+ </ol>
+ </ol>
+ <li><a href="#highlevel">High Level Structure</a>
+ <ol>
+ <li><a href="#modulestructure">Module Structure</a>
+ <li><a href="#globalvars">Global Variables</a>
+ <li><a href="#functionstructure">Function Structure</a>
+ </ol>
+ <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><a href="#i_br" >'<tt>br</tt>' Instruction</a>
+ <li><a href="#i_switch">'<tt>switch</tt>' Instruction</a>
+ <li><a href="#i_invoke">'<tt>invoke</tt>' Instruction</a>
+ <li><a href="#i_unwind" >'<tt>unwind</tt>' Instruction</a>
+ </ol>
+ <li><a href="#binaryops">Binary Operations</a>
+ <ol>
+ <li><a href="#i_add" >'<tt>add</tt>' Instruction</a>
+ <li><a href="#i_sub" >'<tt>sub</tt>' Instruction</a>
+ <li><a href="#i_mul" >'<tt>mul</tt>' Instruction</a>
+ <li><a href="#i_div" >'<tt>div</tt>' Instruction</a>
+ <li><a href="#i_rem" >'<tt>rem</tt>' Instruction</a>
+ <li><a href="#i_setcc">'<tt>set<i>cc</i></tt>' Instructions</a>
+ </ol>
+ <li><a href="#bitwiseops">Bitwise Binary Operations</a>
+ <ol>
+ <li><a href="#i_and">'<tt>and</tt>' Instruction</a>
+ <li><a href="#i_or" >'<tt>or</tt>' Instruction</a>
+ <li><a href="#i_xor">'<tt>xor</tt>' Instruction</a>
+ <li><a href="#i_shl">'<tt>shl</tt>' Instruction</a>
+ <li><a href="#i_shr">'<tt>shr</tt>' Instruction</a>
+ </ol>
+ <li><a href="#memoryops">Memory Access Operations</a>
+ <ol>
+ <li><a href="#i_malloc" >'<tt>malloc</tt>' Instruction</a>
+ <li><a href="#i_free" >'<tt>free</tt>' Instruction</a>
+ <li><a href="#i_alloca" >'<tt>alloca</tt>' Instruction</a>
+ <li><a href="#i_load" >'<tt>load</tt>' Instruction</a>
+ <li><a href="#i_store" >'<tt>store</tt>' Instruction</a>
+ <li><a href="#i_getelementptr">'<tt>getelementptr</tt>' Instruction</a>
+ </ol>
+ <li><a href="#otherops">Other Operations</a>
+ <ol>
+ <li><a href="#i_phi" >'<tt>phi</tt>' Instruction</a>
+ <li><a href="#i_cast">'<tt>cast .. to</tt>' Instruction</a>
+ <li><a href="#i_call" >'<tt>call</tt>' Instruction</a>
+ <li><a href="#i_vanext">'<tt>vanext</tt>' Instruction</a>
+ <li><a href="#i_vaarg" >'<tt>vaarg</tt>' Instruction</a>
+ </ol>
+ </ol>
+ <li><a href="#intrinsics">Intrinsic Functions</a>
+ <ol>
+ <li><a href="#int_varargs">Variable Argument Handling Intrinsics</a>
+ <ol>
+ <li><a href="#i_va_start">'<tt>llvm.va_start</tt>' Intrinsic</a>
+ <li><a href="#i_va_end" >'<tt>llvm.va_end</tt>' Intrinsic</a>
+ <li><a href="#i_va_copy" >'<tt>llvm.va_copy</tt>' Intrinsic</a>
+ </ol>
+ </ol>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a> and <A href="mailto:vadve at cs.uiuc.edu">Vikram Adve</a></b><p>
+
+
+ </ol>
+
+
+ <!-- *********************************************************************** -->
+ <p><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="abstract">Abstract
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ <blockquote>
+ This document is a reference manual for the LLVM assembly language. LLVM is
+ an 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.
+ </blockquote>
+
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="introduction">Introduction
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ The LLVM code representation is designed to be used in three different forms: as
+ an in-memory compiler IR, as an on-disk bytecode 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>
+
+ The LLVM representation aims to be a 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="wellformed"><h4><hr size=0>Well Formedness</h4><ul>
+
+ 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>
+
+ <pre>
+ %x = <a href="#i_add">add</a> int 1, %x
+ </pre>
+
+ ...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 bytecode.
+ The violations pointed out by the verifier pass indicate bugs in transformation
+ passes or input to the parser.<p>
+
+ <!-- Describe the typesetting conventions here. -->
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="identifiers">Identifiers
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ LLVM uses three different forms of identifiers, for different purposes:<p>
+
+ <ol>
+ <li>Numeric constants are represented as you would expect: 12, -3 123.421, etc.
+ Floating point constants have an optional hexidecimal notation.
+
+ <li>Named values are represented as a string of characters with a '%' 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. In
+ this way, anything except a <tt>"</tt> character can be used in a name.
+
+ <li>Unnamed values are represented as an unsigned numeric value with a '%'
+ prefix. For example, %12, %2, %44.
+ </ol><p>
+
+ LLVM requires the values start with a '%' sign 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>
+
+ 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_cast">cast</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_uint">uint</a></tt>', etc...), and others. These reserved
+ words cannot conflict with variable names, because none of them start with a '%'
+ character.<p>
+
+ Here is an example of LLVM code to multiply the integer variable '<tt>%X</tt>'
+ by 8:<p>
+
+ The easy way:
+ <pre>
+ %result = <a href="#i_mul">mul</a> uint %X, 8
+ </pre>
+
+ After strength reduction:
+ <pre>
+ %result = <a href="#i_shl">shl</a> uint %X, ubyte 3
+ </pre>
+
+ And the hard way:
+ <pre>
+ <a href="#i_add">add</a> uint %X, %X <i>; yields {uint}:%0</i>
+ <a href="#i_add">add</a> uint %0, %0 <i>; yields {uint}:%1</i>
+ %result = <a href="#i_add">add</a> uint %1, %1
+ </pre>
+
+ 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>Unnamed temporaries are created when the result of a computation is not
+ assigned to a named value.
+ <li>Unnamed temporaries are numbered sequentially
+ </ol><p>
+
+ ...and it also show 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>
+
+ The one non-intuitive notation for constants is the optional hexidecimal 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>' which is also supported by the parser. The only time hexadecimal
+ floating point constants are useful (and the only time that they are generated
+ by the disassembler) is when an FP constant has to be emitted that is not
+ representable as a decimal floating point number exactly. For example, NaN's,
+ infinities, and other special cases are represented in their IEEE hexadecimal
+ format so that assembly and disassembly do not cause any bits to change in the
+ constants.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="typesystem">Type System
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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 IR 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>
+
+ <!-- The written form for the type system was heavily influenced by the
+ syntactic problems with types in the C language<sup><a
+ href="#rw_stroustrup">1</a></sup>.<p> -->
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="t_primitive">Primitive Types
+ </b></font></td></tr></table><ul>
+
+ The primitive types are the fundemental building blocks of the LLVM system. The
+ current set of primitive types are as follows:<p>
+
+ <table border=0 align=center><tr><td>
+
+ <table border=1 cellspacing=0 cellpadding=4 align=center>
+ <tr><td><tt>void</tt></td> <td>No value</td></tr>
+ <tr><td><tt>ubyte</tt></td> <td>Unsigned 8 bit value</td></tr>
+ <tr><td><tt>ushort</tt></td><td>Unsigned 16 bit value</td></tr>
+ <tr><td><tt>uint</tt></td> <td>Unsigned 32 bit value</td></tr>
+ <tr><td><tt>ulong</tt></td> <td>Unsigned 64 bit value</td></tr>
+ <tr><td><tt>float</tt></td> <td>32 bit floating point value</td></tr>
+ <tr><td><tt>label</tt></td> <td>Branch destination</td></tr>
+ </table>
+
+ </td><td valign=top>
+
+ <table border=1 cellspacing=0 cellpadding=4 align=center>
+ <tr><td><tt>bool</tt></td> <td>True or False value</td></tr>
+ <tr><td><tt>sbyte</tt></td> <td>Signed 8 bit value</td></tr>
+ <tr><td><tt>short</tt></td> <td>Signed 16 bit value</td></tr>
+ <tr><td><tt>int</tt></td> <td>Signed 32 bit value</td></tr>
+ <tr><td><tt>long</tt></td> <td>Signed 64 bit value</td></tr>
+ <tr><td><tt>double</tt></td><td>64 bit floating point value</td></tr>
+ </table>
+
+ </td></tr></table><p>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="t_classifications"><h4><hr size=0>Type Classifications</h4><ul>
+
+ These different primitive types fall into a few useful classifications:<p>
+
+ <table border=1 cellspacing=0 cellpadding=4 align=center>
+ <tr><td><a name="t_signed">signed</td> <td><tt>sbyte, short, int, long, float, double</tt></td></tr>
+ <tr><td><a name="t_unsigned">unsigned</td><td><tt>ubyte, ushort, uint, ulong</tt></td></tr>
+ <tr><td><a name="t_integer">integer</td><td><tt>ubyte, sbyte, ushort, short, uint, int, ulong, long</tt></td></tr>
+ <tr><td><a name="t_integral">integral</td><td><tt>bool, ubyte, sbyte, ushort, short, uint, int, ulong, long</tt></td></tr>
+ <tr><td><a name="t_floating">floating point</td><td><tt>float, double</tt></td></tr>
+ <tr><td><a name="t_firstclass">first class</td><td><tt>bool, ubyte, sbyte, ushort, short,<br> uint, int, ulong, long, float, double, <a href="#t_pointer">pointer</a></tt></td></tr>
+ </table><p>
+
+
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="t_derived">Derived Types
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="t_array"><h4><hr size=0>Array Type</h4><ul>
+
+ <h5>Overview:</h5>
+
+ 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>
+
+ The number of elements is a constant integer value, elementtype may be any type
+ with a size.<p>
+
+ <h5>Examples:</h5>
+ <ul>
+ <tt>[40 x int ]</tt>: Array of 40 integer values.<br>
+ <tt>[41 x int ]</tt>: Array of 41 integer values.<br>
+ <tt>[40 x uint]</tt>: Array of 40 unsigned integer values.<p>
+ </ul>
+
+ Here are some examples of multidimensional arrays:<p>
+ <ul>
+ <table border=0 cellpadding=0 cellspacing=0>
+ <tr><td><tt>[3 x [4 x int]]</tt></td><td>: 3x4 array integer values.</td></tr>
+ <tr><td><tt>[12 x [10 x float]]</tt></td><td>: 12x10 array of single precision floating point values.</td></tr>
+ <tr><td><tt>[2 x [3 x [4 x uint]]]</tt></td><td>: 2x3x4 array of unsigned integer values.</td></tr>
+ </table>
+ </ul>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="t_function"><h4><hr size=0>Function Type</h4><ul>
+
+ <h5>Overview:</h5>
+
+ The function type can be thought of as a function signature. It consists of a
+ return type and a list of formal parameter types. Function types are usually
+ used when to build virtual function tables (which are structures of pointers to
+ functions), for indirect function calls, and when defining a function.<p>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <returntype> (<parameter list>)
+ </pre>
+
+ 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.
+ <p>
+
+ <h5>Examples:</h5>
+ <ul>
+ <table border=0 cellpadding=0 cellspacing=0>
+
+ <tr><td><tt>int (int)</tt></td><td>: function taking an <tt>int</tt>, returning
+ an <tt>int</tt></td></tr>
+
+ <tr><td><tt>float (int, int *) *</tt></td><td>: <a href="#t_pointer">Pointer</a>
+ to a function that takes an <tt>int</tt> and a <a href="#t_pointer">pointer</a>
+ to <tt>int</tt>, returning <tt>float</tt>.</td></tr>
+
+ <tr><td><tt>int (sbyte *, ...)</tt></td><td>: A vararg function that takes at
+ least one <a href="#t_pointer">pointer</a> to <tt>sbyte</tt> (signed char in C),
+ which returns an integer. This is the signature for <tt>printf</tt> in
+ LLVM.</td></tr>
+
+ </table>
+ </ul>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="t_struct"><h4><hr size=0>Structure Type</h4><ul>
+
+ <h5>Overview:</h5>
+
+ 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>
+
+ Structures are accessed using '<tt><a href="#i_load">load</a></tt> and '<tt><a
+ href="#i_store">store</a></tt>' by getting a pointer to a field with the '<tt><a
+ href="#i_getelementptr">getelementptr</a></tt>' instruction.<p>
+
+ <h5>Syntax:</h5>
+ <pre>
+ { <type list> }
+ </pre>
+
+
+ <h5>Examples:</h5>
+ <table border=0 cellpadding=0 cellspacing=0>
+
+ <tr><td><tt>{ int, int, int }</tt></td><td>: a triple of three <tt>int</tt>
+ values</td></tr>
+
+ <tr><td><tt>{ float, int (int) * }</tt></td><td>: 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>int</tt>, returning an <tt>int</tt>.</td></tr>
+
+ </table>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="t_pointer"><h4><hr size=0>Pointer Type</h4><ul>
+
+ <h5>Overview:</h5>
+
+ As in many languages, the pointer type represents a pointer or reference to
+ another object, which must live in memory.<p>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <type> *
+ </pre>
+
+ <h5>Examples:</h5>
+
+ <table border=0 cellpadding=0 cellspacing=0>
+
+ <tr><td><tt>[4x int]*</tt></td><td>: <a href="#t_pointer">pointer</a> to <a
+ href="#t_array">array</a> of four <tt>int</tt> values</td></tr>
+
+ <tr><td><tt>int (int *) *</tt></td><td>: A <a href="#t_pointer">pointer</a> to a
+ <a href="t_function">function</a> that takes an <tt>int</tt>, returning an
+ <tt>int</tt>.</td></tr>
+
+ </table>
+ <p>
+
+
+ <!-- _______________________________________________________________________ -->
+ <!--
+ </ul><a name="t_packed"><h4><hr size=0>Packed Type</h4><ul>
+
+ Mention/decide that packed types work with saturation or not. Maybe have a packed+saturated type in addition to just a packed type.<p>
+
+ Packed types should be 'nonsaturated' because standard data types are not saturated. Maybe have a saturated packed type?<p>
+
+ -->
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="highlevel">High Level Structure
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="modulestructure">Module Structure
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ <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 sbyte]</a> c"hello world\0A\00" <i>; [13 x sbyte]*</i>
+
+ <i>; External declaration of the puts function</i>
+ <a href="#functionstructure">declare</a> int %puts(sbyte*) <i>; int(sbyte*)* </i>
+
+ <i>; Definition of main function</i>
+ int %main() { <i>; int()* </i>
+ <i>; Convert [13x sbyte]* to sbyte *...</i>
+ %cast210 = <a href="#i_getelementptr">getelementptr</a> [13 x sbyte]* %.LC0, long 0, long 0 <i>; sbyte*</i>
+
+ <i>; Call puts function to write out the string to stdout...</i>
+ <a href="#i_call">call</a> int %puts(sbyte* %cast210) <i>; int</i>
+ <a href="#i_ret">ret</a> int 0
+ }
+ </pre>
+
+ 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>
+
+ <a name="linkage">
+ 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 linkage types:<p>
+
+ <dl>
+ <a name="linkage_internal">
+ <dt><tt><b>internal</b></tt>
+
+ <dd>Global values with internal linkage are only directly accessible by objects
+ in the current module. In particular, linking code into a module with an
+ internal global value may cause the internal to be renamed as necessary to avoid
+ collisions. Because the symbol is internal to the module, all references can be
+ updated. This corresponds to the notion of the '<tt>static</tt>' keyword in C,
+ or the idea of "anonymous namespaces" in C++.<p>
+
+ <a name="linkage_linkonce">
+ <dt><tt><b>linkonce</b></tt>:
+
+ <dd>"<tt>linkonce</tt>" linkage is similar to <tt>internal</tt> linkage, with
+ the twist that linking together two modules defining the same <tt>linkonce</tt>
+ globals will cause one of the globals to be discarded. This is typically used
+ to implement inline functions. Unreferenced <tt>linkonce</tt> globals are
+ allowed to be discarded.<p>
+
+ <a name="linkage_weak">
+ <dt><tt><b>weak</b></tt>:
+
+ <dd>"<tt>weak</tt>" linkage is exactly the same as <tt>linkonce</tt> linkage,
+ except that unreferenced <tt>weak</tt> globals may not be discarded. This is
+ used to implement constructs in C such as "<tt>int X;</tt>" at global scope.<p>
+
+ <a name="linkage_appending">
+ <dt><tt><b>appending</b></tt>:
+
+ <dd>"<tt>appending</tt>" linkage may only 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.<p>
+
+ <a name="linkage_external">
+ <dt><tt><b>externally visible</b></tt>:
+
+ <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.<p>
+
+ </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. It is illegal for a function
+ <i>declaration</i> to have any linkage type other than "externally visible".<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="globalvars">Global Variables
+ </b></font></td></tr></table><ul>
+
+ Global variables define regions of memory allocated at compilation time instead
+ of run-time. Global variables may optionally be initialized. A variable may
+ be defined as a global "constant", which indicates that the contents of the
+ variable will never be modified (opening options for optimization). Constants
+ must always have an initial value.<p>
+
+ As SSA values, global variables define pointer values that are in scope
+ (i.e. they dominate) for 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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="functionstructure">Functions
+ </b></font></td></tr></table><ul>
+
+ LLVM functions definitions are composed of a (possibly empty) argument list, an
+ opening curly brace, a list of basic blocks, and a closing curly brace. LLVM
+ function declarations are defined with the "<tt>declare</tt>" keyword, a
+ function name and a function signature.<p>
+
+ A function definition contains a list of basic blocks, forming the CFG 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>
+
+ The first basic block in program 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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="instref">Instruction Reference
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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="#memoryops">memory
+ instructions</a>, and <a href="#otherops">other instructions</a>.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="terminators">Terminator Instructions
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ There are five 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, and the '<a
+ href="#i_unwind"><tt>unwind</tt></a>' instruction.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_ret"><h4><hr size=0>'<tt>ret</tt>' Instruction</h4><ul>
+
+ <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>
+
+ The '<tt>ret</tt>' instruction is used to return control flow (and a value) from
+ a function, back to the caller.<p>
+
+ There are two forms of the '<tt>ret</tt>' instructruction: one that returns a
+ value and then causes control flow, and one that just causes control flow to
+ occur.<p>
+
+ <h5>Arguments:</h5>
+
+ The '<tt>ret</tt>' instruction may return any '<a href="#t_firstclass">first
+ class</a>' type. Notice that a function is not <a href="#wellformed">well
+ formed</a> if there exists a '<tt>ret</tt>' instruction inside of the function
+ that returns a value that does not match the return type of the function.<p>
+
+ <h5>Semantics:</h5>
+
+ 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 "normal" of the 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 int 5 <i>; Return an integer value of 5</i>
+ ret void <i>; Return from a void function</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_br"><h4><hr size=0>'<tt>br</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ br bool <cond>, label <iftrue>, label <iffalse>
+ br label <dest> <i>; Unconditional branch</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ 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>
+
+ The conditional branch form of the '<tt>br</tt>' instruction takes a single
+ '<tt>bool</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>
+
+ Upon execution of a conditional '<tt>br</tt>' instruction, the '<tt>bool</tt>'
+ argument is evaluated. If the value is <tt>true</tt>, control flows to the
+ '<tt>iftrue</tt>' <tt>label</tt> argument. If "cond" is <tt>false</tt>,
+ control flows to the '<tt>iffalse</tt>' <tt>label</tt> argument.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ Test:
+ %cond = <a href="#i_setcc">seteq</a> int %a, %b
+ br bool %cond, label %IfEqual, label %IfUnequal
+ IfEqual:
+ <a href="#i_ret">ret</a> int 1
+ IfUnequal:
+ <a href="#i_ret">ret</a> int 0
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_switch"><h4><hr size=0>'<tt>switch</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ switch uint <value>, label <defaultdest> [ int <val>, label &dest>, ... ]
+
+ </pre>
+
+ <h5>Overview:</h5>
+
+ 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>
+
+ The '<tt>switch</tt>' instruction uses three parameters: a '<tt>uint</tt>'
+ 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.<p>
+
+ <h5>Semantics:</h5>
+
+ 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, the corresponding destination is
+ branched to, otherwise the default value it transfered to.<p>
+
+ <h5>Implementation:</h5>
+
+ Depending on properties of the target machine and the particular <tt>switch</tt>
+ instruction, this instruction may be code 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_cast">cast</a> bool %value to uint
+ switch uint %Val, label %truedest [int 0, label %falsedest ]
+
+ <i>; Emulate an unconditional br instruction</i>
+ switch uint 0, label %dest [ ]
+
+ <i>; Implement a jump table:</i>
+ switch uint %val, label %otherwise [ int 0, label %onzero,
+ int 1, label %onone,
+ int 2, label %ontwo ]
+ </pre>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_invoke"><h4><hr size=0>'<tt>invoke</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = invoke <ptr to function ty> %<function ptr val>(<function args>)
+ to label <normal label> except label <exception label>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ 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>' <tt>label</tt> label or the '<tt>exception</tt>'
+ <tt>label</tt>. 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 "except" label.<p>
+
+
+ <h5>Arguments:</h5>
+
+ This instruction requires several arguments:<p>
+ <ol>
+
+ <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>'<tt>function ptr val</tt>': An LLVM value containing a pointer to a
+ function to be invoked.
+
+ <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>'<tt>normal label</tt>': the label reached when the called function executes
+ a '<tt><a href="#i_ret">ret</a></tt>' instruction.
+
+ <li>'<tt>exception label</tt>': the label reached when a callee returns with the
+ <a href="#i_unwind"><tt>unwind</tt></a> instruction.
+ </ol>
+
+ <h5>Semantics:</h5>
+
+ 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>
+
+ 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 int %Test(int 15)
+ to label %Continue
+ except label %TestCleanup <i>; {int}:retval set</i>
+ </pre>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_unwind"><h4><hr size=0>'<tt>unwind</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ unwind
+ </pre>
+
+ <h5>Overview:</h5>
+
+ 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.
+
+ <h5>Semantics:</h5>
+
+ The '<tt>unwind</tt>' intrinsic 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.
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0><tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="binaryops">Binary Operations
+ </b></font></td></tr></table><ul>
+
+ Binary operators are used to do most of the computation in a program. They
+ require two operands, execute an operation on them, and produce a single value.
+ The result value of a binary operator is not necessarily the same type as its
+ operands.<p>
+
+ There are several different binary operators:<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_add"><h4><hr size=0>'<tt>add</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = add <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>add</tt>' instruction returns the sum of its two operands.<p>
+
+ <h5>Arguments:</h5>
+ The two arguments to the '<tt>add</tt>' instruction must be either <a href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> values. Both arguments must have identical types.<p>
+
+ <h5>Semantics:</h5>
+
+ The value produced is the integer or floating point sum of the two operands.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = add int 4, %var <i>; yields {int}:result = 4 + %var</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_sub"><h4><hr size=0>'<tt>sub</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = sub <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>sub</tt>' instruction returns the difference of its two operands.<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>
+
+ The two arguments to the '<tt>sub</tt>' instruction must be either <a
+ href="#t_integer">integer</a> or <a href="#t_floating">floating point</a>
+ values. Both arguments must have identical types.<p>
+
+ <h5>Semantics:</h5>
+
+ The value produced is the integer or floating point difference of the two
+ operands.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = sub int 4, %var <i>; yields {int}:result = 4 - %var</i>
+ <result> = sub int 0, %val <i>; yields {int}:result = -%var</i>
+ </pre>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_mul"><h4><hr size=0>'<tt>mul</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = mul <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>mul</tt>' instruction returns the product of its two operands.<p>
+
+ <h5>Arguments:</h5>
+ The two arguments to the '<tt>mul</tt>' instruction must be either <a href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> values. Both arguments must have identical types.<p>
+
+ <h5>Semantics:</h5>
+
+ The value produced is the integer or floating point product of the two
+ operands.<p>
+
+ There is no signed vs unsigned multiplication. The appropriate action is taken
+ based on the type of the operand. <p>
+
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = mul int 4, %var <i>; yields {int}:result = 4 * %var</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_div"><h4><hr size=0>'<tt>div</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = div <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>div</tt>' instruction returns the quotient of its two operands.<p>
+
+ <h5>Arguments:</h5>
+
+ The two arguments to the '<tt>div</tt>' instruction must be either <a
+ href="#t_integer">integer</a> or <a href="#t_floating">floating point</a>
+ values. Both arguments must have identical types.<p>
+
+ <h5>Semantics:</h5>
+
+ The value produced is the integer or floating point quotient of the two
+ operands.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = div int 4, %var <i>; yields {int}:result = 4 / %var</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_rem"><h4><hr size=0>'<tt>rem</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = rem <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>rem</tt>' instruction returns the remainder from the division of its two operands.<p>
+
+ <h5>Arguments:</h5>
+ The two arguments to the '<tt>rem</tt>' instruction must be either <a href="#t_integer">integer</a> or <a href="#t_floating">floating point</a> values. Both arguments must have identical types.<p>
+
+ <h5>Semantics:</h5>
+
+ This returns the <i>remainder</i> of a division (where the result has the same
+ sign as the divisor), not the <i>modulus</i> (where the result has the same sign
+ as the dividend) 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>.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = rem int 4, %var <i>; yields {int}:result = 4 % %var</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_setcc"><h4><hr size=0>'<tt>set<i>cc</i></tt>' Instructions</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = seteq <ty> <var1>, <var2> <i>; yields {bool}:result</i>
+ <result> = setne <ty> <var1>, <var2> <i>; yields {bool}:result</i>
+ <result> = setlt <ty> <var1>, <var2> <i>; yields {bool}:result</i>
+ <result> = setgt <ty> <var1>, <var2> <i>; yields {bool}:result</i>
+ <result> = setle <ty> <var1>, <var2> <i>; yields {bool}:result</i>
+ <result> = setge <ty> <var1>, <var2> <i>; yields {bool}:result</i>
+ </pre>
+
+ <h5>Overview:</h5> The '<tt>set<i>cc</i></tt>' family of instructions returns a
+ boolean value based on a comparison of their two operands.<p>
+
+ <h5>Arguments:</h5> The two arguments to the '<tt>set<i>cc</i></tt>'
+ instructions must be of <a href="#t_firstclass">first class</a> or <a
+ href="#t_pointer">pointer</a> type (it is not possible to compare
+ '<tt>label</tt>'s, '<tt>array</tt>'s, '<tt>structure</tt>' or '<tt>void</tt>'
+ values, etc...). Both arguments must have identical types.<p>
+
+ <h5>Semantics:</h5>
+
+ The '<tt>seteq</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+ both operands are equal.<br>
+
+ The '<tt>setne</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+ both operands are unequal.<br>
+
+ The '<tt>setlt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+ the first operand is less than the second operand.<br>
+
+ The '<tt>setgt</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+ the first operand is greater than the second operand.<br>
+
+ The '<tt>setle</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+ the first operand is less than or equal to the second operand.<br>
+
+ The '<tt>setge</tt>' instruction yields a <tt>true</tt> '<tt>bool</tt>' value if
+ the first operand is greater than or equal to the second operand.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = seteq int 4, 5 <i>; yields {bool}:result = false</i>
+ <result> = setne float 4, 5 <i>; yields {bool}:result = true</i>
+ <result> = setlt uint 4, 5 <i>; yields {bool}:result = true</i>
+ <result> = setgt sbyte 4, 5 <i>; yields {bool}:result = false</i>
+ <result> = setle sbyte 4, 5 <i>; yields {bool}:result = true</i>
+ <result> = setge sbyte 4, 5 <i>; yields {bool}:result = false</i>
+ </pre>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="bitwiseops">Bitwise Binary Operations
+ </b></font></td></tr></table><ul>
+
+ 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, execute an
+ operation on them, and produce a single value. The resulting value of the
+ bitwise binary operators is always the same type as its first operand.<p>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_and"><h4><hr size=0>'<tt>and</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = and <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>and</tt>' instruction returns the bitwise logical and of its two operands.<p>
+
+ <h5>Arguments:</h5>
+
+ The two arguments to the '<tt>and</tt>' instruction must be <a
+ href="#t_integral">integral</a> values. Both arguments must have identical
+ types.<p>
+
+
+ <h5>Semantics:</h5>
+
+ The truth table used for the '<tt>and</tt>' instruction is:<p>
+
+ <center><table border=1 cellspacing=0 cellpadding=4>
+ <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>
+ </table></center><p>
+
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = and int 4, %var <i>; yields {int}:result = 4 & %var</i>
+ <result> = and int 15, 40 <i>; yields {int}:result = 8</i>
+ <result> = and int 4, 8 <i>; yields {int}:result = 0</i>
+ </pre>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_or"><h4><hr size=0>'<tt>or</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = or <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5> The '<tt>or</tt>' instruction returns the bitwise logical
+ inclusive or of its two operands.<p>
+
+ <h5>Arguments:</h5>
+
+ The two arguments to the '<tt>or</tt>' instruction must be <a
+ href="#t_integral">integral</a> values. Both arguments must have identical
+ types.<p>
+
+
+ <h5>Semantics:</h5>
+
+ The truth table used for the '<tt>or</tt>' instruction is:<p>
+
+ <center><table border=1 cellspacing=0 cellpadding=4>
+ <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>
+ </table></center><p>
+
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = or int 4, %var <i>; yields {int}:result = 4 | %var</i>
+ <result> = or int 15, 40 <i>; yields {int}:result = 47</i>
+ <result> = or int 4, 8 <i>; yields {int}:result = 12</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_xor"><h4><hr size=0>'<tt>xor</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = xor <ty> <var1>, <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ 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>
+
+ The two arguments to the '<tt>xor</tt>' instruction must be <a
+ href="#t_integral">integral</a> values. Both arguments must have identical
+ types.<p>
+
+
+ <h5>Semantics:</h5>
+
+ The truth table used for the '<tt>xor</tt>' instruction is:<p>
+
+ <center><table border=1 cellspacing=0 cellpadding=4>
+ <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>
+ </table></center><p>
+
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = xor int 4, %var <i>; yields {int}:result = 4 ^ %var</i>
+ <result> = xor int 15, 40 <i>; yields {int}:result = 39</i>
+ <result> = xor int 4, 8 <i>; yields {int}:result = 12</i>
+ <result> = xor int %V, -1 <i>; yields {int}:result = ~%V</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_shl"><h4><hr size=0>'<tt>shl</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = shl <ty> <var1>, ubyte <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>shl</tt>' instruction returns the first operand shifted to the left a
+ specified number of bits.
+
+ <h5>Arguments:</h5>
+
+ The first argument to the '<tt>shl</tt>' instruction must be an <a
+ href="#t_integer">integer</a> type. The second argument must be an
+ '<tt>ubyte</tt>' type.<p>
+
+ <h5>Semantics:</h5>
+
+ The value produced is <tt>var1</tt> * 2<sup><tt>var2</tt></sup>.<p>
+
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = shl int 4, ubyte %var <i>; yields {int}:result = 4 << %var</i>
+ <result> = shl int 4, ubyte 2 <i>; yields {int}:result = 16</i>
+ <result> = shl int 1, ubyte 10 <i>; yields {int}:result = 1024</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_shr"><h4><hr size=0>'<tt>shr</tt>' Instruction</h4><ul>
+
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = shr <ty> <var1>, ubyte <var2> <i>; yields {ty}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>shr</tt>' instruction returns the first operand shifted to the right a specified number of bits.
+
+ <h5>Arguments:</h5>
+ The first argument to the '<tt>shr</tt>' instruction must be an <a href="#t_integer">integer</a> type. The second argument must be an '<tt>ubyte</tt>' type.<p>
+
+ <h5>Semantics:</h5>
+
+ If the first argument is a <a href="#t_signed">signed</a> type, the most
+ significant bit is duplicated in the newly free'd bit positions. If the first
+ argument is unsigned, zero bits shall fill the empty positions.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ <result> = shr int 4, ubyte %var <i>; yields {int}:result = 4 >> %var</i>
+ <result> = shr uint 4, ubyte 1 <i>; yields {uint}:result = 2</i>
+ <result> = shr int 4, ubyte 2 <i>; yields {int}:result = 1</i>
+ <result> = shr sbyte 4, ubyte 3 <i>; yields {sbyte}:result = 0</i>
+ <result> = shr sbyte -2, ubyte 1 <i>; yields {sbyte}:result = -1</i>
+ </pre>
+
+
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="memoryops">Memory Access Operations
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_malloc"><h4><hr size=0>'<tt>malloc</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = malloc <type>, uint <NumElements> <i>; yields {type*}:result</i>
+ <result> = malloc <type> <i>; yields {type*}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>malloc</tt>' instruction allocates memory from the system heap and returns a pointer to it.<p>
+
+ <h5>Arguments:</h5>
+
+ The 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. The
+ second form of the instruction is a shorter version of the first instruction
+ that defaults to allocating one element.<p>
+
+ '<tt>type</tt>' must be a sized type.<p>
+
+ <h5>Semantics:</h5>
+
+ Memory is allocated using the system "<tt>malloc</tt>" function, and a pointer
+ is returned.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ %array = malloc [4 x ubyte ] <i>; yields {[%4 x ubyte]*}:array</i>
+
+ %size = <a href="#i_add">add</a> uint 2, 2 <i>; yields {uint}:size = uint 4</i>
+ %array1 = malloc ubyte, uint 4 <i>; yields {ubyte*}:array1</i>
+ %array2 = malloc [12 x ubyte], uint %size <i>; yields {[12 x ubyte]*}:array2</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_free"><h4><hr size=0>'<tt>free</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ free <type> <value> <i>; yields {void}</i>
+ </pre>
+
+
+ <h5>Overview:</h5>
+ The '<tt>free</tt>' instruction returns memory back to the unused memory heap, to be reallocated in the future.<p>
+
+
+ <h5>Arguments:</h5>
+
+ '<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>
+
+ Access to the memory pointed to by the pointer is not longer defined after this instruction executes.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ %array = <a href="#i_malloc">malloc</a> [4 x ubyte] <i>; yields {[4 x ubyte]*}:array</i>
+ free [4 x ubyte]* %array
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_alloca"><h4><hr size=0>'<tt>alloca</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = alloca <type>, uint <NumElements> <i>; yields {type*}:result</i>
+ <result> = alloca <type> <i>; yields {type*}:result</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>alloca</tt>' instruction allocates memory on the current stack frame of
+ the procedure that is live until the current function returns to its caller.<p>
+
+ <h5>Arguments:</h5>
+
+ The 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. The second form of
+ the instruction is a shorter version of the first that defaults to allocating
+ one element.<p>
+
+ '<tt>type</tt>' may be any sized type.<p>
+
+ <h5>Semantics:</h5>
+
+ Memory is allocated, a pointer is returned. '<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_invoke">invoke</a></tt>
+ instructions), the memory is reclaimed.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ %ptr = alloca int <i>; yields {int*}:ptr</i>
+ %ptr = alloca int, uint 4 <i>; yields {int*}:ptr</i>
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_load"><h4><hr size=0>'<tt>load</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = load <ty>* <pointer>
+ <result> = volatile load <ty>* <pointer>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>load</tt>' instruction is used to read from memory.<p>
+
+ <h5>Arguments:</h5>
+
+ The argument to the '<tt>load</tt>' instruction specifies the memory address to
+ load from. 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>
+
+ <h5>Semantics:</h5>
+
+ The location of memory pointed to is loaded.
+
+ <h5>Examples:</h5>
+ <pre>
+ %ptr = <a href="#i_alloca">alloca</a> int <i>; yields {int*}:ptr</i>
+ <a href="#i_store">store</a> int 3, int* %ptr <i>; yields {void}</i>
+ %val = load int* %ptr <i>; yields {int}:val = int 3</i>
+ </pre>
+
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_store"><h4><hr size=0>'<tt>store</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ store <ty> <value>, <ty>* <pointer> <i>; yields {void}</i>
+ volatile store <ty> <value>, <ty>* <pointer> <i>; yields {void}</i>
+ </pre>
+
+ <h5>Overview:</h5>
+ The '<tt>store</tt>' instruction is used to write to memory.<p>
+
+ <h5>Arguments:</h5>
+
+ There are two arguments to the '<tt>store</tt>' instruction: a value to store
+ and an address to store it into. The type of the '<tt><pointer></tt>'
+ operand must be a pointer to the 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>
+
+ <h5>Semantics:</h5> 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> int <i>; yields {int*}:ptr</i>
+ <a href="#i_store">store</a> int 3, int* %ptr <i>; yields {void}</i>
+ %val = load int* %ptr <i>; yields {int}:val = int 3</i>
+ </pre>
+
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_getelementptr"><h4><hr size=0>'<tt>getelementptr</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = getelementptr <ty>* <ptrval>{, long <aidx>|, ubyte <sidx>}*
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>getelementptr</tt>' instruction is used to get the address of a
+ subelement of an aggregate data structure.<p>
+
+ <h5>Arguments:</h5>
+
+ This instruction takes a list of <tt>long</tt> values and <tt>ubyte</tt>
+ constants that indicate what form of addressing to perform. The actual types of
+ the arguments provided depend on the type of the first pointer argument. The
+ '<tt>getelementptr</tt>' instruction is used to index down through the type
+ levels of a structure.<p>
+
+ For example, lets consider a C code fragment and how it gets compiled to
+ LLVM:<p>
+
+ <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>
+
+ The LLVM code generated by the GCC frontend is:
+
+ <pre>
+ %RT = type { sbyte, [10 x [20 x int]], sbyte }
+ %ST = type { int, double, %RT }
+
+ int* "foo"(%ST* %s) {
+ %reg = getelementptr %ST* %s, long 1, ubyte 2, ubyte 1, long 5, long 13
+ ret int* %reg
+ }
+ </pre>
+
+ <h5>Semantics:</h5>
+
+ The index types specified for the '<tt>getelementptr</tt>' instruction depend on
+ the pointer type that is being index into. <a href="t_pointer">Pointer</a> and
+ <a href="t_array">array</a> types require '<tt>long</tt>' values, and <a
+ href="t_struct">structure</a> types require '<tt>ubyte</tt>'
+ <b>constants</b>.<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>{ int, double, %RT }</tt>'
+ type, a structure. The second index indexes into the third element of the
+ structure, yielding a '<tt>%RT</tt>' = '<tt>{ sbyte, [10 x [20 x int]], sbyte
+ }</tt>' type, another structure. The third index indexes into the second
+ element of the structure, yielding a '<tt>[10 x [20 x int]]</tt>' type, an
+ array. The two dimensions of the array are subscripted into, yielding an
+ '<tt>int</tt>' type. The '<tt>getelementptr</tt>' instruction return a pointer
+ to this element, thus yielding a '<tt>int*</tt>' type.<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>
+ int* "foo"(%ST* %s) {
+ %t1 = getelementptr %ST* %s , long 1 <i>; yields %ST*:%t1</i>
+ %t2 = getelementptr %ST* %t1, long 0, ubyte 2 <i>; yields %RT*:%t2</i>
+ %t3 = getelementptr %RT* %t2, long 0, ubyte 1 <i>; yields [10 x [20 x int]]*:%t3</i>
+ %t4 = getelementptr [10 x [20 x int]]* %t3, long 0, long 5 <i>; yields [20 x int]*:%t4</i>
+ %t5 = getelementptr [20 x int]* %t4, long 0, long 13 <i>; yields int*:%t5</i>
+ ret int* %t5
+ }
+ </pre>
+
+
+
+ <h5>Example:</h5>
+ <pre>
+ <i>; yields [12 x ubyte]*:aptr</i>
+ %aptr = getelementptr {int, [12 x ubyte]}* %sptr, long 0, ubyte 1
+ </pre>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="otherops">Other Operations
+ </b></font></td></tr></table><ul>
+
+ The instructions in this catagory are the "miscellaneous" instructions, which defy better classification.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_phi"><h4><hr size=0>'<tt>phi</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = phi <ty> [ <val0>, <label0>], ...
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>phi</tt>' instruction is used to implement the φ node in the SSA
+ graph representing the function.<p>
+
+ <h5>Arguments:</h5>
+
+ The type of the incoming values are 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.<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>
+
+ At runtime, the '<tt>phi</tt>' instruction logically takes on the value
+ specified by the parameter, depending on which basic block we came from in the
+ last <a href="#terminators">terminator</a> instruction.<p>
+
+ <h5>Example:</h5>
+
+ <pre>
+ Loop: ; Infinite loop that counts from 0 on up...
+ %indvar = phi uint [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
+ %nextindvar = add uint %indvar, 1
+ br label %Loop
+ </pre>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_cast"><h4><hr size=0>'<tt>cast .. to</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = cast <ty> <value> to <ty2> <i>; yields ty2</i>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>cast</tt>' instruction is used as the primitive means to convert
+ integers to floating point, change data type sizes, and break type safety (by
+ casting pointers).<p>
+
+ <h5>Arguments:</h5>
+
+ The '<tt>cast</tt>' instruction takes a value to cast, which must be a first
+ class value, and a type to cast it to, which must also be a first class type.<p>
+
+ <h5>Semantics:</h5>
+
+ This instruction follows the C rules for explicit casts when determining how the
+ data being cast must change to fit in its new container.<p>
+
+ When casting to bool, any value that would be considered true in the context of
+ a C '<tt>if</tt>' condition is converted to the boolean '<tt>true</tt>' values,
+ all else are '<tt>false</tt>'.<p>
+
+ When extending an integral value from a type of one signness to another (for
+ example '<tt>sbyte</tt>' to '<tt>ulong</tt>'), the value is sign-extended if the
+ <b>source</b> value is signed, and zero-extended if the source value is
+ unsigned. <tt>bool</tt> values are always zero extended into either zero or
+ one.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ %X = cast int 257 to ubyte <i>; yields ubyte:1</i>
+ %Y = cast int 123 to bool <i>; yields bool:true</i>
+ </pre>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_call"><h4><hr size=0>'<tt>call</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <result> = call <ty>* <fnptrval>(<param list>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>call</tt>' instruction represents a simple function call.<p>
+
+ <h5>Arguments:</h5>
+
+ This instruction requires several arguments:<p>
+ <ol>
+
+ <li>'<tt>ty</tt>': shall be the signature of the pointer to function value being
+ invoked. The argument types must match the types implied by this signature.<p>
+
+ <li>'<tt>fnptrval</tt>': An LLVM value containing a pointer to a function to be
+ invoked. In most cases, this is a direct function invocation, but indirect
+ <tt>call</tt>s are just as possible, calling an arbitrary pointer to function
+ values.<p>
+
+ <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.
+ </ol>
+
+ <h5>Semantics:</h5>
+
+ 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. This is a simpler
+ case of the <a href="#i_invoke">invoke</a> instruction.<p>
+
+ <h5>Example:</h5>
+ <pre>
+ %retval = call int %test(int %argc)
+ call int(sbyte*, ...) *%printf(sbyte* %msg, int 12, sbyte 42);
+
+ </pre>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_vanext"><h4><hr size=0>'<tt>vanext</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <resultarglist> = vanext <va_list> <arglist>, <argty>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>vanext</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>
+
+ This instruction takes a <tt>valist</tt> value and the type of the argument. It
+ returns another <tt>valist</tt>.
+
+ <h5>Semantics:</h5>
+
+ The '<tt>vanext</tt>' instruction advances the specified <tt>valist</tt> past
+ an argument of the specified type. In conjunction with the <a
+ href="#i_vaarg"><tt>vaarg</tt></a> instruction, it is used to implement the
+ <tt>va_arg</tt> macro available in C. For more information, see the variable
+ argument handling <a href="#int_varargs">Intrinsic Functions</a>.<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>
+
+ <tt>vanext</tt> is an LLVM instruction instead of an <a
+ href="#intrinsics">intrinsic function</a> because it takes an type as an
+ argument.</p>
+
+ <h5>Example:</h5>
+
+ See the <a href="#int_varargs">variable argument processing</a> section.<p>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_vaarg"><h4><hr size=0>'<tt>vaarg</tt>' Instruction</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ <resultval> = vaarg <va_list> <arglist>, <argty>
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>vaarg</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>
+
+ This instruction takes a <tt>valist</tt> value and the type of the argument. It
+ returns a value of the specified argument type.
+
+ <h5>Semantics:</h5>
+
+ The '<tt>vaarg</tt>' instruction loads an argument of the specified type from
+ the specified <tt>va_list</tt>. In conjunction with the <a
+ href="#i_vanext"><tt>vanext</tt></a> instruction, it is used to implement the
+ <tt>va_arg</tt> macro available in C. For more information, see the variable
+ argument handling <a href="#int_varargs">Intrinsic Functions</a>.<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>
+
+ <tt>vaarg</tt> is an LLVM instruction instead of an <a
+ href="#intrinsics">intrinsic function</a> because it takes an type as an
+ argument.</p>
+
+ <h5>Example:</h5>
+
+ See the <a href="#int_varargs">variable argument processing</a> section.<p>
+
+
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="intrinsics">Intrinsic Functions
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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 instructions represent an extension mechanism for the LLVM
+ language that does not require changing all of the transformations in LLVM to
+ add to the language (or the bytecode reader/writer, the parser, etc...).<p>
+
+ Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
+ prefix is reserved in LLVM for intrinsic names, thus functions may not be named
+ this. 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 that they all be documented here if any are added.<p>
+
+ Unless an intrinsic function is target-specific, there must be a lowering pass
+ to eliminate the intrinsic or all backends must support the intrinsic
+ function.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%"> <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="int_varargs">Variable Argument Handling Intrinsics
+ </b></font></td></tr></table><ul>
+
+ Variable argument support is defined in LLVM with the <a
+ href="#i_vanext"><tt>vanext</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>
+
+ 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
+ intrinsics with any type used.<p>
+
+ This example shows how the <a href="#i_vanext"><tt>vanext</tt></a> instruction
+ and the variable argument handling intrinsic functions are used.<p>
+
+ <pre>
+ int %test(int %X, ...) {
+ ; Initialize variable argument processing
+ %ap = call sbyte*()* %<a href="#i_va_start">llvm.va_start</a>()
+
+ ; Read a single integer argument
+ %tmp = vaarg sbyte* %ap, int
+
+ ; Advance to the next argument
+ %ap2 = vanext sbyte* %ap, int
+
+ ; Demonstrate usage of llvm.va_copy and llvm.va_end
+ %aq = call sbyte* (sbyte*)* %<a href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)
+ call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %aq)
+
+ ; Stop processing of arguments.
+ call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)
+ ret int %tmp
+ }
+ </pre>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_va_start"><h4><hr size=0>'<tt>llvm.va_start</tt>' Intrinsic</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ call va_list ()* %llvm.va_start()
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>llvm.va_start</tt>' intrinsic returns a new <tt><arglist></tt>
+ for subsequent use by the variable argument intrinsics.<p>
+
+ <h5>Semantics:</h5>
+
+ 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 and returns a
+ <tt>va_list</tt> element, so that the next <tt>vaarg</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, the
+ compiler can figure that out.<p>
+
+ Note that this intrinsic function is only legal to be called from within the
+ body of a variable argument function.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_va_end"><h4><hr size=0>'<tt>llvm.va_end</tt>' Intrinsic</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ call void (va_list)* %llvm.va_end(va_list <arglist>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ The '<tt>llvm.va_end</tt>' intrinsic destroys <tt><arglist></tt> which has
+ been initialized previously with <tt><a
+ href="#i_va_start">llvm.va_start</a></tt> or <tt><a
+ href="#i_va_copy">llvm.va_copy</a></tt>.<p>
+
+ <h5>Arguments:</h5>
+
+ The argument is a <tt>va_list</tt> to destroy.<p>
+
+ <h5>Semantics:</h5>
+
+ 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>.
+ Calls to <a href="#i_va_start"><tt>llvm.va_start</tt></a> and <a
+ href="#i_va_copy"><tt>llvm.va_copy</tt></a> must be matched exactly with calls
+ to <tt>llvm.va_end</tt>.<p>
+
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><a name="i_va_copy"><h4><hr size=0>'<tt>llvm.va_copy</tt>' Intrinsic</h4><ul>
+
+ <h5>Syntax:</h5>
+ <pre>
+ call va_list (va_list)* %llvm.va_copy(va_list <destarglist>)
+ </pre>
+
+ <h5>Overview:</h5>
+
+ 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>
+
+ The argument is the <tt>va_list</tt> to copy.
+
+ <h5>Semantics:</h5>
+
+ 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 returned list. This intrinsic is necessary
+ because the <tt><a href="i_va_start">llvm.va_start</a></tt> intrinsic may be
+ arbitrarily complex and require memory allocation, for example.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+
+ <hr>
+ <font size=-1>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Jan 23 15:19:28 CST 2001 -->
+ <!-- hhmts start -->
+ Last modified: Tue Oct 21 10:43:36 CDT 2003
+ <!-- hhmts end -->
+ </font>
+ </body></html>
Index: llvm-www/releases/1.0/OpenProjects.html
diff -c /dev/null llvm-www/releases/1.0/OpenProjects.html:1.1
*** /dev/null Fri Oct 24 15:51:51 2003
--- llvm-www/releases/1.0/OpenProjects.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,284 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>Open LLVM Projects</title></head>
+
+ <body bgcolor=white>
+ <center><h1><font size=7>Open LLVM Projects</font></h1></center>
+
+ <ul>
+ <li><a href="#what">What is this?</a>
+ <li><a href="#improving">Improving the current system</a>
+ <ol>
+ <li><a href="#glibc">Port glibc to LLVM</a>
+ <li><a href="#NightlyTest">Improving the Nightly Tester</a>
+ <li><a href="#programs">Compile programs with the LLVM Compiler</a>
+ <li><a href="#llvm_ir">Extend the LLVM intermediate representation</a>
+ <li><a href="#misc_imp">Miscellaneous Improvements</a>
+ </ol>
+
+ <li><a href="#new">Adding new capabilities to LLVM</a>
+ <ol>
+ <li><a href="#pointeranalysis">Pointer and Alias Analysis</a>
+ <li><a href="#profileguided">Profile Guided Optimization</a>
+ <li><a href="#xforms">New Transformations and Analyses</a>
+ <li><a href="#x86be">X86 Back-end Improvements</a>
+ <li><a href="#misc_new">Miscellaneous Additions</a>
+ </ol>
+ </ul>
+
+ <br><br>
+
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="what">What is this?
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ This document is meant to be a sort of "big TODO list" for LLVM. Each project
+ in this document is something that would be useful for LLVM to have, and would
+ also be a great way to get familiar with the system. Some of these projects are
+ small and self-contained, which may be implemented in a couple of days, others
+ are larger. Several of these projects may lead to interesting research projects
+ in their own right. In any case, we welcome all contributions.<p>
+
+ If you are thinking about tackling one of these projects, please send a mail to
+ the <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">LLVM
+ Developer's</a> mailing list, so that we know the project is being worked on.
+ Additionally this is a good way to get more information about a specific project
+ or to suggest other projects to add to this page.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="improving">Improving the current system
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ Improvements to the current infrastructure are always very welcome and tend to
+ be fairly straight-forward to implement. Here are some of the key areas that
+ can use improvement...<p>
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="glibc">Port glibc to LLVM
+ </b></font></td></tr></table><ul>
+
+ It would be very useful to <a
+ href="http://www.gnu.org/software/libc/porting.html">port</a> <a
+ href="http://www.gnu.org/software/glibc/">glibc</a> to LLVM. This would allow a
+ variety of interprocedural algorithms to be much more effective in the face of
+ library calls. The most important pieces to port are things like the string
+ library and the <tt>stdio</tt> related functions... low-level system calls like
+ '<tt>read</tt>' should stay unimplemented in LLVM.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="NightlyTest">Improving the Nightly Tester
+ </b></font></td></tr></table><ul>
+
+ The <a href="/testresults/">Nightly Tester</a> is a simple perl script (located
+ in utils/NightlyTest.pl) which runs every night to generate a daily report. It
+ could use the following improvements:<p>
+
+ <ol>
+ <li>Olden timings - Time the compilation and execution times for the Olden
+ benchmark suite, keeping track of these values over time.
+
+ <li>Graphs - It would be great to have gnuplot graphs to keep track of how the
+ tree is changing over time. We already gather a several statistics, it
+ just necessary to add the script-fu to gnuplotize it.
+
+ <li>Regression tests - We should run the regression tests in addition to the
+ program tests...
+ </ol><p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="programs">Compile programs with the LLVM Compiler
+ </b></font></td></tr></table><ul>
+
+ We are always looking for new testcases and benchmarks for use with LLVM. In
+ particular, it is useful to try compiling your favorite C source code with LLVM.
+ If it doesn't compile, try to figure out why or report it to the <a
+ href="http://mail.cs.uiuc.edu/pipermail/llvmbugs/">llvm-bugs</a> list. If you
+ get the program to compile, it would be extremely useful to convert the build
+ system to be compatible with the LLVM Programs testsuite so that we can check it
+ into CVS and the automated tester can use it to track progress of the
+ compiler.<p>
+
+ When testing a code, try running it with a variety of optimizations, and with
+ all the back-ends: CBE, llc, and lli.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="llvm_ir">Extend the LLVM intermediate representation
+ </b></font></td></tr></table><ul>
+
+ <ol>
+ <li>Add a new conditional move instruction: <tt>X = select bool Cond, Y, Z</tt>
+ <li>Add support for platform independent prefetch support. The GCC <a
+ href="http://gcc.gnu.org/projects/prefetch.html">prefetch project</a> page
+ has a good survey of the prefetching capabilities of a variety of modern
+ processors.
+ </ol>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="misc_imp">Miscellaneous Improvements
+ </b></font></td></tr></table><ul>
+
+ <ol>
+ <li>Someone needs to look into getting the <tt>ranlib</tt> tool to index LLVM
+ bytecode files, so that linking in .a files is not hideously slow. They
+ would also then have to implement the reader for this index in
+ <tt>gccld</tt>.<br>
+
+ <li>Improve the efficiency of the bytecode loader/writer<br>
+ <li>Extend the FunctionPassManager to use a ModuleProvider to stream functions
+ in on demand. This would improve the efficiency of the JIT.
+ <li>Rework the PassManager to be more flexible
+ <li>Some transformations and analyses only work on reducible flow graphs. It
+ would be nice to have a transformation which could be "required" by these passes
+ which makes irreducible graphs reducible. This can easily be accomplished
+ through code duplication. See <a
+ href="http://citeseer.nj.nec.com/janssen97making.html">Making Graphs Reducible
+ with Controlled Node Splitting</a> and perhaps <a
+ href="http://doi.acm.org/10.1145/262004.262005">Nesting of Reducible and
+ Irreducible Loops</a>.
+ </ol>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="new">Adding new capabilities to LLVM
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ Sometimes creating new things is more fun that improving existing things. These
+ projects tend to be more involved and perhaps require more work, but can also be
+ very rewarding.<p>
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="pointeranalysis">Pointer and Alias Analysis
+ </b></font></td></tr></table><ul>
+
+ We have a <a href="AliasAnalysis.html">strong base for development</a> of both
+ pointer analysis based optimizations as well as pointer analyses themselves. It
+ seems natural to want to take advantage of this...<p>
+
+ <ol>
+ <li>Implement a flow-sensitive context-sensitive alias analysis algorithm<br>
+ - Pick one of the somewhat efficient algorithms, but strive for maximum
+ precision
+ <li>Implement a flow-sensitive context-insensitive alias analysis algorithm<br>
+ - Just an efficient local algorithm perhaps?
+
+ <li>Implement an interface to update analyses in response to common code motion
+ transformations
+ <li>Implement alias analysis based optimizations:
+ <ul>
+ <li>Dead store elimination
+ </ul>
+ </ol>
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="profileguided">Profile Guided Optimization
+ </b></font></td></tr></table><ul>
+
+ We are getting to the point where we really need a unified infrastructure for
+ profile guided optimizations. It would be wonderful to be able to write profile
+ guided transformations which can be performed either at static compile time
+ (compile time or offline optimization time) or at runtime in a JIT type setup.
+ The LLVM transformation itself shouldn't need to know how it is being used.<p>
+
+ Ideas for profile guided transformations:<p>
+
+ <ol>
+ <li>Superblock formation (with many optimizations)
+ <li>Loop unrolling/peeling
+ <li>Profile directed inlining
+ <li>Code layout
+ <li>...
+ </ol><p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="xforms">New Transformations and Analyses
+ </b></font></td></tr></table><ul>
+
+ <ol>
+ <li>Implement a Dependence Analysis Infrastructure<br>
+ - Design some way to represent and query dep analysis
+ <li>Implement a faster Dominator Set Construction Algorithm<br>
+ - A linear time or nearly so algorithm
+ <li>Implement a strength reduction pass
+ <li>Value range propagation pass
+ <li>Implement an unswitching pass
+ <li>Write a loop unroller, with a simple heuristic for when to unroll
+ </ol>
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="x86be">X86 Back-end Improvements
+ </b></font></td></tr></table><ul>
+
+ <ol>
+ <li>Implement a global register allocator
+ <li>Implement a better instruction selector
+ <li>Implement support for the "switch" instruction without requiring the
+ lower-switches pass.
+ </ol>
+
+ <!-- ======================================================================= -->
+ </ul><table width="50%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width=100%>
+ <font color="#EEEEFF" size=+1 face="Georgia,Palatino"><b>
+ <a name="misc_new">Miscellaneous Additions
+ </b></font></td></tr></table><ul>
+
+ <ol>
+ <li>Write a new frontend for some language (Java? OCaml? Forth?)
+ <li>Write a new backend for a target (IA64? MIPS? MMIX?)
+ </ol>
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr><font size-1>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Aug 6 15:00:33 CDT 2002 -->
+ <!-- hhmts start -->
+ Last modified: Wed Oct 1 16:48:54 CDT 2003
+ <!-- hhmts end -->
+ </font></body></html>
Index: llvm-www/releases/1.0/ProgrammersManual.html
diff -c /dev/null llvm-www/releases/1.0/ProgrammersManual.html:1.1
*** /dev/null Fri Oct 24 15:51:51 2003
--- llvm-www/releases/1.0/ProgrammersManual.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,1796 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>LLVM Programmer's Manual</title></head>
+
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>LLVM Programmer's Manual</b></font></td>
+ </tr></table>
+
+ <ol>
+ <li><a href="#introduction">Introduction</a>
+ <li><a href="#general">General Information</a>
+ <ul>
+ <li><a href="#stl">The C++ Standard Template Library</a>
+ <!--
+ <li>The <tt>-time-passes</tt> option
+ <li>How to use the LLVM Makefile system
+ <li>How to write a regression test
+ -->
+ </ul>
+ <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><a href="#DEBUG">The <tt>DEBUG()</tt> macro &
+ <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/>
+ </ul>
+ <li><a href="#Statistic">The <tt>Statistic</tt> template &
+ <tt>-stats</tt> option</a>
+ <!--
+ <li>The <tt>InstVisitor</tt> template
+ <li>The general graph API
+ -->
+ </ul>
+ <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><a href="#iterate_basicblock">Iterating over the <tt>Instruction</tt>s
+ in a <tt>BasicBlock</tt></a>
+ <li><a href="#iterate_institer">Iterating over the <tt>Instruction</tt>s
+ in a <tt>Function</tt></a>
+ <li><a href="#iterate_convert">Turning an iterator into a class
+ pointer</a>
+ <li><a href="#iterate_complex">Finding call sites: a more complex
+ example</a>
+ <li><a href="#iterate_chains">Iterating over def-use & use-def
+ chains</a>
+ </ul>
+ <li><a href="#simplechanges">Making simple changes</a>
+ <ul>
+ <li><a href="#schanges_creating">Creating and inserting new
+ <tt>Instruction</tt>s</a>
+ <li><a href="#schanges_deleting">Deleting
+ <tt>Instruction</tt>s</a>
+ <li><a href="#schanges_replacing">Replacing an
+ <tt>Instruction</tt> with another <tt>Value</tt></a>
+ </ul>
+ <!--
+ <li>Working with the Control Flow Graph
+ <ul>
+ <li>Accessing predecessors and successors of a <tt>BasicBlock</tt>
+ <li>
+ <li>
+ </ul>
+ -->
+ </ul>
+ <li><a href="#coreclasses">The Core LLVM Class Hierarchy Reference</a>
+ <ul>
+ <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>
+ <ul>
+ <li>
+ </ul>
+ <li><a href="#GlobalValue">The <tt>GlobalValue</tt> class</a>
+ <ul>
+ <li><a href="#BasicBlock">The <tt>BasicBlock</tt> class</a>
+ <li><a href="#Function">The <tt>Function</tt> class</a>
+ <li><a href="#GlobalVariable">The <tt>GlobalVariable</tt> class</a>
+ </ul>
+ <li><a href="#Module">The <tt>Module</tt> class</a>
+ <li><a href="#Constant">The <tt>Constant</tt> class</a>
+ <ul>
+ <li>
+ <li>
+ </ul>
+ </ul>
+ <li><a href="#Type">The <tt>Type</tt> class</a>
+ <li><a href="#Argument">The <tt>Argument</tt> class</a>
+ </ul>
+ <li>The <tt>SymbolTable</tt> class
+ <li>The <tt>ilist</tt> and <tt>iplist</tt> classes
+ <ul>
+ <li>Creating, inserting, moving and deleting from LLVM lists
+ </ul>
+ <li>Important iterator invalidation semantics to be aware of
+ </ul>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
+ <a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a>, and
+ <a href="mailto:jstanley at cs.uiuc.edu">Joel Stanley</a></b><p>
+ </ol>
+
+
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="introduction">Introduction
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ 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>
+
+ 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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="general">General Information
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="stl">The C++ Standard Template Library</a>
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ 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><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 <a
+ href="http://www.tempest-sw.com/cpp/ch13-libref.html">Standard Library
+ Reference</a> that rivals Dinkumware's, and is actually free until the book is
+ published.
+
+ <li><a href="http://www.parashift.com/c++-faq-lite/">C++ Frequently Asked
+ Questions</a>
+
+ <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><a href="http://www.research.att.com/~bs/C++.html">Bjarne Stroustrup's C++
+ Page</a>
+
+ </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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="apis">Important and useful LLVM APIs
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ Here we highlight some LLVM APIs that are generally useful and good to know
+ about when writing transformations.<p>
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="isa">The isa<>, cast<> and dyn_cast<> templates</a>
+ </b></font></td></tr></table><ul>
+
+ 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>Support/Casting.h</tt></a> file (note
+ that you very rarely have to include this file directly).<p>
+
+ <dl>
+
+ <dt><tt>isa<></tt>:
+
+ <dd>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>
+
+
+ <dt><tt>cast<></tt>:
+
+ <dd>The <tt>cast<></tt> operator is a "checked cast" operation. It
+ converts a pointer or reference from a base class to a derived cast, 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>
+
+ <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><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>
+
+
+ <dt><tt>dyn_cast<></tt>:
+
+ <dd>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>
+
+ <pre>
+ if (<a href="#AllocationInst">AllocationInst</a> *AI = dyn_cast<<a href="#AllocationInst">AllocationInst</a>>(Val)) {
+ ...
+ }
+ </pre><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>
+
+ Another common example is:<p>
+
+ <pre>
+ <i>// Loop over all of the phi nodes in a basic block</i>
+ BasicBlock::iterator BBI = BB->begin();
+ for (; <a href="#PhiNode">PHINode</a> *PN = dyn_cast<<a href="#PHINode">PHINode</a>>(BBI); ++BBI)
+ cerr << *PN;
+ </pre><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 InstVisitor class to
+ dispatch over the instruction type directly.<p>
+
+
+ <dt><tt>cast_or_null<></tt>:
+
+ <dd>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>
+
+
+ <dt><tt>dyn_cast_or_null<></tt>:
+
+ <dd>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>
+
+ </dl>
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="DEBUG">The <tt>DEBUG()</tt> macro & <tt>-debug</tt> option</a>
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ 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>
+
+ The "<tt><a href="/doxygen/Debug_8h-source.html">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:
+
+ <pre>
+ ...
+ DEBUG(std::cerr << "I am here!\n");
+ ...
+ </pre><p>
+
+ Then you can run your pass like this:<p>
+
+ <pre>
+ $ opt < a.bc > /dev/null -mypass
+ <no output>
+ $ opt < a.bc > /dev/null -mypass -debug
+ I am here!
+ $
+ </pre><p>
+
+ Using the <tt>DEBUG()</tt> macro instead of a home-brewed solution allows you to
+ now 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>
+
+ 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="DEBUG_TYPE"><hr size=0>Fine grained debug info with
+ <tt>DEBUG_TYPE()</tt> and the <tt>-debug-only</tt> option</a> </h4><ul>
+
+ 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>
+
+ <pre>
+ ...
+ DEBUG(std::cerr << "No debug type\n");
+ #undef DEBUG_TYPE
+ #define DEBUG_TYPE "foo"
+ DEBUG(std::cerr << "'foo' debug type\n");
+ #undef DEBUG_TYPE
+ #define DEBUG_TYPE "bar"
+ DEBUG(std::cerr << "'bar' debug type\n");
+ #undef DEBUG_TYPE
+ #define DEBUG_TYPE ""
+ DEBUG(std::cerr << "No debug type (2)\n");
+ ...
+ </pre><p>
+
+ Then you can run your pass like this:<p>
+
+ <pre>
+ $ opt < a.bc > /dev/null -mypass
+ <no output>
+ $ 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><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 "Support/Debug.h"</tt>, you don't have to insert the ugly
+ <tt>#undef</tt>'s). Also, you should use names more meaningful that "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 all, say, instruction scheduling, debug
+ information to be enabled with <tt>-debug-type=InstrSched</tt>, even if the
+ source lives in multiple files.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Statistic">The <tt>Statistic</tt> template & <tt>-stats</tt>
+ option</a>
+ </b></font></td></tr></table><ul>
+
+ The "<tt><a
+ href="/doxygen/Statistic_8h-source.html">Support/Statistic.h</a></tt>"
+ file provides a template named <tt>Statistic</tt> that is used as a unified way
+ to keeping 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>
+
+ 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> template 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>
+
+ There are many examples of <tt>Statistic</tt> users, but this basics of using it
+ are as follows:<p>
+
+ <ol>
+ <li>Define your statistic like this:<p>
+
+ <pre>
+ static Statistic<> NumXForms("mypassname", "The # of times I did stuff");
+ </pre><p>
+
+ The <tt>Statistic</tt> template can emulate just about any data-type, but if you
+ do not specify a template argument, it defaults to acting like an unsigned int
+ counter (this is usually what you want).<p>
+
+ <li>Whenever you make a transformation, bump the counter:<p>
+
+ <pre>
+ ++NumXForms; // I did stuff
+ </pre><p>
+
+ </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>
+
+ <pre>
+ $ opt -stats -mypassname < program.bc > /dev/null
+ ... statistic output ...
+ </pre><p>
+
+ When running <tt>gccas</tt> on a C file from the SPEC benchmark suite, it gives
+ a report that looks like this:<p>
+
+ <pre>
+ 7646 bytecodewriter - Number of normal instructions
+ 725 bytecodewriter - Number of oversized instructions
+ 129996 bytecodewriter - Number of bytecode 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><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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="common">Helpful Hints for Common Operations
+ </b></font></td></tr></table><ul> <!--
+ *********************************************************************** -->
+
+ 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>
+
+ <!-- NOTE: this section should be heavy on example code -->
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="inspection">Basic Inspection and Traversal Routines</a>
+ </b></font></td></tr></table><ul>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="iterate_function"><hr size=0>Iterating over the <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a>s in a <a
+ href="#Function"><tt>Function</tt></a> </h4><ul>
+
+ 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:
+
+ <pre>
+ // func is a pointer to a Function instance
+ for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i) {
+
+ // print out the name of the basic block if it has one, and then the
+ // number of instructions that it contains
+
+ cerr << "Basic block (name=" << i->getName() << ") has "
+ << i->size() << " instructions.\n";
+ }
+ </pre>
+
+ 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.
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="iterate_basicblock"><hr size=0>Iterating over the <a
+ href="#Instruction"><tt>Instruction</tt></a>s in a <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a> </h4><ul>
+
+ 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>:
+
+ <pre>
+ // blk is a pointer to a BasicBlock instance
+ for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
+ // the next statement works since operator<<(ostream&,...)
+ // is overloaded for Instruction&
+ cerr << *i << "\n";
+ </pre>
+
+ 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>cerr << *blk <<
+ "\n";</tt>.<p>
+
+ Note that currently operator<< is implemented for <tt>Value*</tt>, so it
+ will print out the contents of the pointer, instead of
+ the pointer value you might expect. This is a deprecated interface that will
+ be removed in the future, so it's best not to depend on it. To print out the
+ pointer value for now, you must cast to <tt>void*</tt>.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="iterate_institer"><hr size=0>Iterating over the <a
+ href="#Instruction"><tt>Instruction</tt></a>s in a <a
+ href="#Function"><tt>Function</tt></a></h4><ul>
+
+ 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
+ stderr (<b>Note:</b> Dereferencing an <tt>InstIterator</tt> yields an
+ <tt>Instruction*</tt>, <i>not</i> an <tt>Instruction&</tt>!):
+
+ <pre>
+ #include "<a href="/doxygen/InstIterator_8h-source.html">llvm/Support/InstIterator.h</a>"
+ ...
+ // Suppose F is a ptr to a function
+ for (inst_iterator i = inst_begin(F), e = inst_end(F); i != e; ++i)
+ cerr << **i << "\n";
+ </pre>
+
+ Easy, isn't it? You can also use <tt>InstIterator</tt>s to fill a
+ worklist with its initial contents. For example, if you wanted to
+ initialize a worklist to contain all instructions in a
+ <tt>Function</tt> F, all you would need to do is something like:
+
+ <pre>
+ std::set<Instruction*> worklist;
+ worklist.insert(inst_begin(F), inst_end(F));
+ </pre>
+
+ The STL set <tt>worklist</tt> would now contain all instructions in
+ the <tt>Function</tt> pointed to by F.
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="iterate_convert"><hr size=0>Turning an iterator into a class
+ pointer (and vice-versa) </h4><ul>
+
+ 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 straightforward.
+ Assuming that <tt>i</tt> is a <tt>BasicBlock::iterator</tt> and
+ <tt>j</tt> is a <tt>BasicBlock::const_iterator</tt>:
+
+ <pre>
+ Instruction& inst = *i; // grab reference to instruction reference
+ Instruction* pinst = &*i; // grab pointer to instruction reference
+ const Instruction& inst = *j;
+ </pre>
+ 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,
+
+ <pre>Instruction* pinst = &*i;</pre>
+
+ is semantically equivalent to
+
+ <pre>Instruction* pinst = i;</pre>
+
+ It's also possible to turn a class pointer into the corresponding
+ iterator. Usually, this conversion is quite inexpensive. 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:
+
+ <pre>
+ void printNextInstruction(Instruction* inst) {
+ BasicBlock::iterator it(inst);
+ ++it; // after this line, it refers to the instruction after *inst.
+ if (it != inst->getParent()->end()) cerr << *it << "\n";
+ }
+ </pre>
+ Of course, this example is strictly pedagogical, because it'd be much
+ better to explicitly grab the next instruction directly from inst.
+
+
+ <!--_______________________________________________________________________-->
+ </ul><h4><a name="iterate_complex"><hr size=0>Finding call sites: a slightly
+ more complex example </h4><ul>
+
+ 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
+ straightforward manner, but this example will allow us to explore how
+ you'd do it if you didn't have <tt>InstVisitor</tt> around. In
+ pseudocode, this is what we want to do:
+
+ <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>
+
+ And the actual code is (remember, since we're writing a
+ <tt>FunctionPass</tt>, our <tt>FunctionPass</tt>-derived class simply
+ has to override the <tt>runOnFunction</tt> method...):
+
+ <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)) {
+ // we know we've encountered a call instruction, so we
+ // need to determine if it's a call to the
+ // function pointed to by m_func or not.
+
+ if (callInst->getCalledFunction() == targetFunc)
+ ++callCounter;
+ }
+ }
+ }
+
+ private:
+ unsigned callCounter;
+ };
+ </pre>
+
+ <!--_______________________________________________________________________-->
+ </ul><h4><a name="iterate_chains"><hr size=0>Iterating over def-use &
+ use-def chains</h4><ul>
+
+ Frequently, we might have an instance of the <a
+ href="/doxygen/classValue.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>:
+
+ <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)) {
+ cerr << "F is used in instruction:\n";
+ cerr << *Inst << "\n";
+ }
+ }
+ </pre>
+
+ Alternately, it's common to have an instance of the <a
+ href="/doxygen/classUser.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>):
+
+ <pre>
+ Instruction* pi = ...;
+
+ for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
+ Value* v = *i;
+ ...
+ }
+ </pre>
+
+
+ <!--
+ 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]
+ -->
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="simplechanges">Making simple changes</a>
+ </b></font></td></tr></table><ul>
+
+ 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.
+
+ <!--_______________________________________________________________________-->
+ </ul><h4><a name="schanges_creating"><hr size=0>Creating and inserting
+ new <tt>Instruction</tt>s</h4><ul>
+
+ <i>Instantiating Instructions</i>
+
+ <p>Creation of <tt>Instruction</tt>s is straightforward: 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:
+
+ <pre>AllocaInst* ai = new AllocaInst(Type::IntTy);</pre>
+
+ will create an <tt>AllocaInst</tt> instance that represents the
+ allocation of one integer in the current stack frame, at runtime.
+ 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/classInstruction.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 runtime. 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:
+
+ <pre>AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc");</pre>
+
+ where <tt>indexLoc</tt> is now the logical name of the instruction's
+ execution value, which is a pointer to an integer on the runtime
+ 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>:
+ <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:
+
+ <pre>
+ BasicBlock *pb = ...;
+ Instruction *pi = ...;
+ Instruction *newInst = new Instruction(...);
+ pb->getInstList().insert(pi, newInst); // inserts newInst before pi in pb
+ </pre>
+ </p>
+
+ <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:
+ <pre>
+ Instruction *pi = ...;
+ Instruction *newInst = new Instruction(...);
+ pi->getParent()->getInstList().insert(pi, newInst);
+ </pre>
+ 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:
+ <pre>
+ Instruction* pi = ...;
+ Instruction* newInst = new Instruction(..., pi);
+ </pre>
+ which is much cleaner, especially if you're creating a lot of
+ instructions and adding them to <tt>BasicBlock</tt>s.
+ </p>
+ </p>
+ </ul>
+
+ <!--_______________________________________________________________________-->
+ </ul><h4><a name="schanges_deleting"><hr size=0>Deleting
+ <tt>Instruction</tt>s</h4><ul>
+
+ Deleting an instruction from an existing sequence of instructions that form a <a
+ href="#BasicBlock"><tt>BasicBlock</tt></a> is very straightforward. 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.<p>
+
+ For example:<p>
+
+ <pre>
+ <a href="#Instruction">Instruction</a> *I = .. ;
+ <a href="#BasicBlock">BasicBlock</a> *BB = I->getParent();
+ BB->getInstList().erase(I);
+ </pre><p>
+
+ <!--_______________________________________________________________________-->
+ </ul><h4><a name="schanges_replacing"><hr size=0>Replacing an
+ <tt>Instruction</tt> with another <tt>Value</tt></h4><ul>
+
+ <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>.
+
+ <ul>
+
+ <li><tt>ReplaceInstWithValue</tt>
+
+ <p>This function replaces all uses (within a basic block) 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 an null pointer to an integer.</p>
+
+ <pre>
+ AllocaInst* instToReplace = ...;
+ BasicBlock::iterator ii(instToReplace);
+ ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
+ Constant::getNullValue(PointerType::get(Type::IntTy)));
+ </pre>
+
+ <li><tt>ReplaceInstWithInst</tt>
+
+ <p>This function replaces a particular instruction with another
+ instruction. The following example illustrates the replacement of one
+ <tt>AllocaInst</tt> with another.<p>
+
+ <pre>
+ AllocaInst* instToReplace = ...;
+ BasicBlock::iterator ii(instToReplace);
+ ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
+ new AllocaInst(Type::IntTy, 0, "ptrToReplacedInt"));
+ </pre>
+
+ </ul>
+ <p><i>Replacing multiple uses of <tt>User</tt>s and
+ <tt>Value</tt>s</i></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/classValue.html">Value Class</a> and <a
+ href="/doxygen/classUser.html">User Class</a>, respectively, for more
+ information.
+
+ <!-- Value::replaceAllUsesWith User::replaceUsesOfWith Point out:
+ include/llvm/Transforms/Utils/ especially BasicBlockUtils.h with:
+ ReplaceInstWithValue, ReplaceInstWithInst
+ -->
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="coreclasses">The Core LLVM Class Hierarchy Reference
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Value">The <tt>Value</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a href="/doxygen/Value_8h-source.html">llvm/Value.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classValue.html">Value Class</a><p>
+
+
+ The <tt>Value</tt> class is the most important class in 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, and even <a
+ href="#Instruction"><tt>Instruction</tt></a>s and <a
+ href="#Function"><tt>Function</tt></a>s are <tt>Value</tt>s.<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>
+
+ 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. <a name="#nameWarning">In addition, all LLVM values can be named. The
+ "name" of the <tt>Value</tt> is symbolic string printed in the LLVM code:<p>
+
+ <pre>
+ %<b>foo</b> = add int 1, 2
+ </pre>
+
+ The name of this instruction is "foo". <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>
+
+ 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 class that
+ represents this value. Although this may take some getting used to, it
+ simplifies the representation and makes it easier to manipulate.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_Value"><hr size=0>Important Public Members of
+ the <tt>Value</tt> class</h4><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><tt><a href="#Type">Type</a> *getType() const</tt><p>
+ This method returns the Type of the Value.
+
+ <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><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>
+
+ <pre>
+ Inst->replaceAllUsesWith(ConstVal);
+ </pre><p>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="User">The <tt>User</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a href="/doxygen/User_8h-source.html">llvm/User.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classUser.html">User Class</a><br>
+ Superclass: <a href="#Value"><tt>Value</tt></a><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>
+
+ 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_User"><hr size=0>Important Public Members of
+ the <tt>User</tt> class</h4><ul>
+
+ The <tt>User</tt> class exposes the operand list in two ways: through an index
+ access interface and through an iterator based interface.<p>
+
+ <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><tt>User::op_iterator</tt> - Typedef for iterator over the operand list<br>
+ <tt>User::op_const_iterator</tt>
+ <tt>use_iterator op_begin()</tt>
+ - Get an iterator to the start of the operand list.<br>
+ <tt>use_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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Instruction">The <tt>Instruction</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a
+ href="/doxygen/Instruction_8h-source.html">llvm/Instruction.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classInstruction.html">Instruction Class</a><br>
+ Superclasses: <a href="#User"><tt>User</tt></a>, <a
+ href="#Value"><tt>Value</tt></a><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>
+
+ 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>
+
+ 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::SetLE</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="#SetCondInst">SetCondInst</a></tt>). Unfortunately, the use of macros in
+ this file confused doxygen, so these enum values don't show up correctly in the
+ <a href="/doxygen/classInstruction.html">doxygen output</a>.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_Instruction"><hr size=0>Important Public Members of
+ the <tt>Instruction</tt> class</h4><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><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><tt>unsigned getOpcode()</tt><p>
+
+ Returns the opcode for the <tt>Instruction</tt>.<p>
+
+ <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>
+
+
+
+ <!--
+
+ \subsection{Subclasses of Instruction :}
+ \begin{itemize}
+ <li>BinaryOperator : This subclass of Instruction defines a general interface to the all the instructions involvong binary operators in LLVM.
+ \begin{itemize}
+ <li><tt>bool swapOperands()</tt>: Exchange the two operands to this instruction. If the instruction cannot be reversed (i.e. if it's a Div), it returns true.
+ \end{itemize}
+ <li>TerminatorInst : This subclass of Instructions defines an interface for all instructions that can terminate a BasicBlock.
+ \begin{itemize}
+ <li> <tt>unsigned getNumSuccessors()</tt>: Returns the number of successors for this terminator instruction.
+ <li><tt>BasicBlock *getSuccessor(unsigned i)</tt>: As the name suggests returns the ith successor BasicBlock.
+ <li><tt>void setSuccessor(unsigned i, BasicBlock *B)</tt>: sets BasicBlock B as the ith succesor to this terminator instruction.
+ \end{itemize}
+
+ <li>PHINode : This represents the PHI instructions in the SSA form.
+ \begin{itemize}
+ <li><tt> unsigned getNumIncomingValues()</tt>: Returns the number of incoming edges to this PHI node.
+ <li><tt> Value *getIncomingValue(unsigned i)</tt>: Returns the ith incoming Value.
+ <li><tt>void setIncomingValue(unsigned i, Value *V)</tt>: Sets the ith incoming Value as V
+ <li><tt>BasicBlock *getIncomingBlock(unsigned i)</tt>: Returns the Basic Block corresponding to the ith incoming Value.
+ <li><tt> void addIncoming(Value *D, BasicBlock *BB)</tt>:
+ Add an incoming value to the end of the PHI list
+ <li><tt> int getBasicBlockIndex(const BasicBlock *BB) const</tt>:
+ Returns the first index of the specified basic block in the value list for this PHI. Returns -1 if no instance.
+ \end{itemize}
+ <li>CastInst : In LLVM all casts have to be done through explicit cast instructions. CastInst defines the interface to the cast instructions.
+ <li>CallInst : This defines an interface to the call instruction in LLVM. ARguments to the function are nothing but operands of the instruction.
+ \begin{itemize}
+ <li>: <tt>Function *getCalledFunction()</tt>: Returns a handle to the function that is being called by this Function.
+ \end{itemize}
+ <li>LoadInst, StoreInst, GetElemPtrInst : These subclasses represent load, store and getelementptr instructions in LLVM.
+ \begin{itemize}
+ <li><tt>Value * getPointerOperand()</tt>: Returns the Pointer Operand which is typically the 0th operand.
+ \end{itemize}
+ <li>BranchInst : This is a subclass of TerminatorInst and defines the interface for conditional and unconditional branches in LLVM.
+ \begin{itemize}
+ <li><tt>bool isConditional()</tt>: Returns true if the branch is a conditional branch else returns false
+ <li> <tt>Value *getCondition()</tt>: Returns the condition if it is a conditional branch else returns null.
+ <li> <tt>void setUnconditionalDest(BasicBlock *Dest)</tt>: Changes the current branch to an unconditional one targetting the specified block.
+ \end{itemize}
+
+ \end{itemize}
+
+ -->
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="BasicBlock">The <tt>BasicBlock</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a
+ href="/doxygen/BasicBlock_8h-source.html">llvm/BasicBlock.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classBasicBlock.html">BasicBlock Class</a><br>
+ Superclass: <a href="#Value"><tt>Value</tt></a><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>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_BasicBlock"><hr size=0>Important Public Members of
+ the <tt>BasicBlock</tt> class</h4><ul>
+
+ <li><tt>BasicBlock(const std::string &Name = "", <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 simply takes a name for the new
+ block, and optionally 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><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>, <tt>rbegin()</tt>, <tt>rend()</tt><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><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><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><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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="GlobalValue">The <tt>GlobalValue</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a
+ href="/doxygen/GlobalValue_8h-source.html">llvm/GlobalValue.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classGlobalValue.html">GlobalValue Class</a><br>
+ Superclasses: <a href="#User"><tt>User</tt></a>, <a
+ href="#Value"><tt>Value</tt></a><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.<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>
+
+ Because <tt>GlobalValue</tt>s are memory objects, they are always referred to by
+ their address. As such, the <a href="#Type"><tt>Type</tt></a> of a global is
+ always a pointer to its contents. This is explained in the LLVM Language
+ Reference Manual.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_GlobalValue"><hr size=0>Important Public Members of
+ the <tt>GlobalValue</tt> class</h4><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>
+
+ <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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Function">The <tt>Function</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a
+ href="/doxygen/Function_8h-source.html">llvm/Function.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classFunction.html">Function Class</a><br>
+ Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>, <a
+ href="#User"><tt>User</tt></a>, <a href="#Value"><tt>Value</tt></a><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>
+
+ 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 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>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_Function"><hr size=0>Important Public Members of
+ the <tt>Function</tt> class</h4><ul>
+
+ <li><tt>Function(const <a href="#FunctionType">FunctionType</a> *Ty, bool isInternal, const std::string &N = "")</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
+ whether or not it should start out with internal or external linkage.<p>
+
+ <li><tt>bool isExternal()</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><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>front()</tt>, <tt>back()</tt>,
+ <tt>size()</tt>, <tt>empty()</tt>, <tt>rbegin()</tt>, <tt>rend()</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><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><tt>Function::aiterator</tt> - Typedef for the argument list iterator<br>
+ <tt>Function::const_aiterator</tt> - Typedef for const_iterator.<br>
+ <tt>abegin()</tt>, <tt>aend()</tt>, <tt>afront()</tt>, <tt>aback()</tt>,
+ <tt>asize()</tt>, <tt>aempty()</tt>, <tt>arbegin()</tt>, <tt>arend()</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><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><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><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><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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="GlobalVariable">The <tt>GlobalVariable</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a
+ href="/doxygen/GlobalVariable_8h-source.html">llvm/GlobalVariable.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classGlobalVariable.html">GlobalVariable Class</a><br>
+ Superclasses: <a href="#GlobalValue"><tt>GlobalValue</tt></a>, <a
+ href="#User"><tt>User</tt></a>, <a href="#Value"><tt>Value</tt></a><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 address). 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_GlobalVariable"><hr size=0>Important Public Members of the
+ <tt>GlobalVariable</tt> class</h4><ul>
+
+ <li><tt>GlobalVariable(const <a href="#Type">Type</a> *Ty, bool isConstant, bool
+ isInternal, <a href="#Constant">Constant</a> *Initializer = 0, const std::string
+ &Name = "")</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, and
+ if <tt>isInternal</tt> is true the resultant global variable will have internal
+ linkage. Optionally an initializer and name may be specified for the global variable as well.<p>
+
+
+ <li><tt>bool isConstant() const</tt><p>
+
+ Returns true if this is a global variable is known not to be modified at
+ runtime.<p>
+
+
+ <li><tt>bool hasInitializer()</tt><p>
+
+ Returns true if this <tt>GlobalVariable</tt> has an intializer.<p>
+
+
+ <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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Module">The <tt>Module</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <tt>#include "<a
+ href="/doxygen/Module_8h-source.html">llvm/Module.h</a>"</tt></b><br>
+ doxygen info: <a href="/doxygen/classModule.html">Module Class</a><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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_Module"><hr size=0>Important Public Members of the
+ <tt>Module</tt> class</h4><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>front()</tt>, <tt>back()</tt>,
+ <tt>size()</tt>, <tt>empty()</tt>, <tt>rbegin()</tt>, <tt>rend()</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><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>
+
+ <!-- Global Variable -->
+ <hr size=0>
+
+ <li><tt>Module::giterator</tt> - Typedef for global variable list iterator<br>
+ <tt>Module::const_giterator</tt> - Typedef for const_iterator.<br>
+ <tt>gbegin()</tt>, <tt>gend()</tt>, <tt>gfront()</tt>, <tt>gback()</tt>,
+ <tt>gsize()</tt>, <tt>gempty()</tt>, <tt>grbegin()</tt>, <tt>grend()</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><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>
+
+
+ <!-- Symbol table stuff -->
+ <hr size=0>
+
+ <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>
+
+
+ <!-- Convenience methods -->
+ <hr size=0>
+
+ <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><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><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><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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Constant">The <tt>Constant</tt> class and subclasses</a>
+ </b></font></td></tr></table><ul>
+
+ Constant represents a base class for different types of constants. It is
+ subclassed by ConstantBool, ConstantInt, ConstantSInt, ConstantUInt,
+ ConstantArray etc for representing the various types of Constants.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_Value"><hr size=0>Important Public Methods</h4><ul>
+
+ <li><tt>bool isConstantExpr()</tt>: Returns true if it is a ConstantExpr
+
+
+ <hr>
+ Important Subclasses of Constant<p>
+
+ <ul>
+ <li>ConstantSInt : This subclass of Constant represents a signed integer constant.
+ <ul>
+ <li><tt>int64_t getValue() const</tt>: Returns the underlying value of this constant.
+ </ul>
+ <li>ConstantUInt : This class represents an unsigned integer.
+ <ul>
+ <li><tt>uint64_t getValue() const</tt>: Returns the underlying value of this constant.
+ </ul>
+ <li>ConstantFP : This class represents a floating point constant.
+ <ul>
+ <li><tt>double getValue() const</tt>: Returns the underlying value of this constant.
+ </ul>
+ <li>ConstantBool : This represents a boolean constant.
+ <ul>
+ <li><tt>bool getValue() const</tt>: Returns the underlying value of this constant.
+ </ul>
+ <li>ConstantArray : This represents a constant array.
+ <ul>
+ <li><tt>const std::vector<Use> &getValues() const</tt>: Returns a Vecotr of component constants that makeup this array.
+ </ul>
+ <li>ConstantStruct : This represents a constant struct.
+ <ul>
+ <li><tt>const std::vector<Use> &getValues() const</tt>: Returns a Vecotr of component constants that makeup this array.
+ </ul>
+ <li>ConstantPointerRef : This represents a constant pointer value that is initialized to point to a global value, which lies at a constant fixed address.
+ <ul>
+ <li><tt>GlobalValue *getValue()</tt>: Returns the global value to which this pointer is pointing to.
+ </ul>
+ </ul>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Type">The <tt>Type</tt> class and Derived Types</a>
+ </b></font></td></tr></table><ul>
+
+ Type as noted earlier is also a subclass of a Value class. Any primitive
+ type (like int, short etc) in LLVM is an instance of Type Class. All
+ other types are instances of subclasses of type like FunctionType,
+ ArrayType etc. DerivedType is the interface for all such dervied types
+ including FunctionType, ArrayType, PointerType, StructType. Types can have
+ names. They can be recursive (StructType). There exists exactly one instance
+ of any type structure at a time. This allows using pointer equality of Type *s for comparing types.
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="m_Value"><hr size=0>Important Public Methods</h4><ul>
+
+ <li><tt>PrimitiveID getPrimitiveID() const</tt>: Returns the base type of the type.
+ <li><tt> bool isSigned() const</tt>: Returns whether an integral numeric type is signed. This is true for SByteTy, ShortTy, IntTy, LongTy. Note that this is not true for Float and Double.
+ <li><tt>bool isUnsigned() const</tt>: Returns whether a numeric type is unsigned. This is not quite the complement of isSigned... nonnumeric types return false as they do with isSigned. This returns true for UByteTy, UShortTy, UIntTy, and ULongTy.
+ <li><tt> bool isInteger() const</tt>: Equilivent to isSigned() || isUnsigned(), but with only a single virtual function invocation.
+ <li><tt>bool isIntegral() const</tt>: Returns true if this is an integral type, which is either Bool type or one of the Integer types.
+
+ <li><tt>bool isFloatingPoint()</tt>: Return true if this is one of the two floating point types.
+ <li><tt>bool isRecursive() const</tt>: Returns rue if the type graph contains a cycle.
+ <li><tt>isLosslesslyConvertableTo (const Type *Ty) const</tt>: Return true if this type can be converted to 'Ty' without any reinterpretation of bits. For example, uint to int.
+ <li><tt>bool isPrimitiveType() const</tt>: Returns true if it is a primitive type.
+ <li><tt>bool isDerivedType() const</tt>: Returns true if it is a derived type.
+ <li><tt>const Type * getContainedType (unsigned i) const</tt>:
+ This method is used to implement the type iterator. For derived types, this returns the types 'contained' in the derived type, returning 0 when 'i' becomes invalid. This allows the user to iterate over the types in a struct, for example, really easily.
+ <li><tt>unsigned getNumContainedTypes() const</tt>: Return the number of types in the derived type.
+
+ <p>
+
+ <hr>
+ Derived Types<p>
+
+ <ul>
+ <li>SequentialType : 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.
+ </ul>
+ <li>ArrayType : This is a subclass of SequentialType and defines interface for array types.
+ <ul>
+ <li><tt>unsigned getNumElements() const</tt>: Returns the number of elements in the array.
+ </ul>
+ <li>PointerType : Subclass of SequentialType for pointer types.
+ <li>StructType : subclass of DerivedTypes for struct types
+ <li>FunctionType : subclass of DerivedTypes for function types.
+
+ <ul>
+
+ <li><tt>bool isVarArg() const</tt>: Returns true if its a vararg function
+ <li><tt> const Type * getReturnType() const</tt>: Returns the return type of the function.
+ <li><tt> const ParamTypes &getParamTypes() const</tt>: Returns a vector of parameter types.
+ <li><tt>const Type * getParamType (unsigned i)</tt>: Returns the type of the ith parameter.
+ <li><tt> const unsigned getNumParams() const</tt>: Returns the number of formal parameters.
+ </ul>
+ </ul>
+
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Argument">The <tt>Argument</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ This subclass of Value defines the interface for incoming formal arguments to a
+ function. A Function maitanis a list of its formal arguments. An argument has a
+ pointer to the parent Function.
+
+
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr><font size-1>
+ <address>By: <a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a> and
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Aug 6 15:00:33 CDT 2002 -->
+ <!-- hhmts start -->
+ Last modified: Sat Sep 20 09:25:11 CDT 2003
+ <!-- hhmts end -->
+ </font></body></html>
Index: llvm-www/releases/1.0/Projects.html
diff -c /dev/null llvm-www/releases/1.0/Projects.html:1.1
*** /dev/null Fri Oct 24 15:51:51 2003
--- llvm-www/releases/1.0/Projects.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,390 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html>
+ <head>
+ <title>Creating an LLVM Project</title>
+ </head>
+
+ <body bgcolor=white>
+
+ <center><h1>Creating an LLVM Project<br></h1></center>
+
+ <!--===============================================================-->
+ <h2><a name="a">Overview</a><hr></h2>
+ <!--===============================================================-->
+
+ 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:
+
+ <ol>
+ <li>Set environment variables.
+ <p>
+ There are several environment variables that a Makefile needs to set to
+ use the LLVM build system:
+ <dl compact>
+ <dt>LLVM_SRC_ROOT
+ <dd>
+ The root of the LLVM source tree.
+ <p>
+
+ <dt>LLVM_OBJ_ROOT
+ <dd>
+ The root of the LLVM object tree.
+ <p>
+
+ <dt>BUILD_SRC_ROOT
+ <dd>
+ The root of the project's source tree.
+ <p>
+
+ <dt>BUILD_OBJ_ROOT
+ <dd>
+ The root of the project's object tree.
+ <p>
+
+ <dt>BUILD_SRC_DIR
+ <dd>
+ The directory containing the current source to be compiled.
+ <p>
+
+ <dt>BUILD_OBJ_DIR
+ <dd>
+ The directory where the current source will place the new object
+ files. This should always be the current directory.
+ <p>
+
+ <dt>LEVEL
+ <dd>
+ The relative path from the current directory to the root of the
+ object tree.
+ <p>
+ </dl>
+
+ <li>Include the LLVM Makefile.config from $(LLVM_OBJ_ROOT).
+ <p>
+
+ <li>Include the LLVM Makefile.rules from $(LLVM_SRC_ROOT).
+ </ol>
+
+ There are two ways that you can set all of these variables:
+ <ol>
+ <li>
+ You can write your own Makefiles which hard-code these values.
+
+ <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.
+ </ol>
+
+ This document assumes that you will base your project off of 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>
+
+ <!--===============================================================-->
+ <h2><a name="a">Create a Project from the Sample Project</a><hr></h2>
+ <!--===============================================================-->
+
+ Follow these simple steps to start your project:
+
+ <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.
+ <p>
+
+ <li>
+ Add your source code and Makefiles to your source tree.
+ <p>
+
+ <li>
+ If you want your Makefiles to be configured by the
+ <tt>configure</tt> script, or if you want to support multiple
+ object directories, add your Makefiles to the <tt>configure</tt>
+ script by adding them into the <tt>autoconf/configure.ac</tt> file.
+ The macro <tt>AC_CONFIG_MAKEFILE</tt> will copy a file, unmodified,
+ from the source directory to the object directory.
+
+ <p>
+ After updating <tt>autoconf/configure.ac</tt>, regenerate the
+ configure script with these commands:
+ <p>
+ <tt>
+ cd autoconf<br>
+ autoconf -o ../configure
+ </tt>
+
+ <p>
+
+ You must be using Autoconf version 2.57 or higher.
+ <p>
+
+ <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 compact>
+ <dt><tt>--with-llvmsrc=<directory></tt>
+ <dd>
+ Tell your project where the LLVM source tree is located.
+ <p>
+ <dt><tt>--with-llvmobj=<directory></tt>
+ <dd>
+ Tell your project where the LLVM object tree is located.
+ </dl>
+ </ol>
+
+ That's it! Now all you have to do is type <tt>gmake</tt> in the root of
+ your object directory, and your project should build.
+
+ <!--===============================================================-->
+ <h2><a name="Source Tree Layout">Source Tree Layout</a><hr></h2>
+ <!--===============================================================-->
+
+ 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.
+
+ Underneath your top level directory, you should have the following
+ directories:
+
+ <dl compact>
+ <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 little support for tests,
+ although some exists. Expanded support for tests will hopefully
+ occur in the future. In the meantime, the LLVM system does provide the
+ following:
+ <ul>
+ <li>
+ LLVM provides several QMTest test classes that can be used to
+ create tests. They can be found in
+ <tt>llvm/test/QMTest/llvm.py</tt>. These test classes perform a
+ variety of functions, including code optimization tests, assembly
+ tests, and code analysis tests. The Makefile in
+ <tt>llvm/test</tt> provides the QMTest context needed by LLVM test
+ classes.
+ <p>
+
+ <li>
+ The LLVM source tree provides benchmarks and programs which 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. These
+ programs are found in the <tt>llvm/test/Programs</tt> directory.
+ <p>
+ Currently, there is no way to hook your tests directly into the
+ <tt>llvm/test/Programs</tt> testing harness. You will simply
+ need to find a way to use the source provided within that directory
+ on your own.
+ </ul>
+ </dl>
+
+ Typically, you will want to build your <b>lib</b> directory first
+ followed by your <b>tools</b> directory.
+
+ <!--===============================================================-->
+ <h2><a name="Makefile Variables">Writing LLVM Style Makefiles</a><hr></h2>
+ <!--===============================================================-->
+ 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:
+
+ <h3> Required Variables </h3>
+ <dl compact>
+ <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 /tmp/src, then the Makefile in
+ /tmp/src/jump/high would set LEVEL to "../..".
+ </dl>
+
+ <h3> Variables for Building Subdirectories</h3>
+ <dl compact>
+ <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>
+
+ <h3> Variables for Building Libraries</h3>
+ <dl compact>
+ <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>
+
+ <h3> Variables for Building Programs</h3>
+ <dl compact>
+ <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>
+
+ <h3> Miscellaneous Variables</h3>
+ <dl compact>
+ <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>
+
+ <!--===============================================================-->
+ <h2><a name="objcode">Placement of Object Code</a><hr></h2>
+ <!--===============================================================-->
+
+ The final location of built libraries and executables will depend upon
+ whether you do a Debug, Release, or Profile build.
+
+ <dl compact>
+ <dt>Libraries
+ <dd>
+ All libraries (static and dynamic) will be stored in
+ BUILD_OBJ_ROOT/lib/<type>, 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 BUILD_OBJ_ROOT/lib/<type>,
+ where type is <tt>Debug</tt>, <tt>Release</tt>, or <tt>Profile</tt> for
+ a debug, optimized, or profiled build, respectively.
+ </dl>
+
+ <!--===============================================================-->
+ <h2><a name="help">Further Help</a><hr></h2>
+ <!--===============================================================-->
+
+ 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 LLVM Developers Mailing List (<a
+ href="mailto:llvmdev.cs.uiuc.edu">llvmdev at cs.uiuc.edu</a>).
+
+ <hr>
+ Written by <a href="mailto:criswell at uiuc.edu">John Criswell</a>.
+ <br>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ </body>
+ </html>
Index: llvm-www/releases/1.0/ReleaseNotes.html
diff -c /dev/null llvm-www/releases/1.0/ReleaseNotes.html:1.1
*** /dev/null Fri Oct 24 15:51:51 2003
--- llvm-www/releases/1.0/ReleaseNotes.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,405 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>LLVM 1.0 Release Notes</title></head>
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>LLVM 1.0 Release Notes</b></font></td>
+ </tr></table>
+
+ <ol>
+ <li><a href="#intro">Introduction</a>
+ <li><a href="#whatsnew">What's New?</a>
+ <li><a href="#portability">Portability and Supported Platforms</a>
+ <li><a href="#install-instructions">Installation Instructions</a>
+ <li><a href="#knownproblems">Known Problems</a>
+ <ul>
+ <!-- <li><a href="#portabilityprobs">Portability Problems</a> -->
+ <li><a href="#core">Known problems with the LLVM Core</a>
+ <li><a href="#c-fe">Known problems with the C Front-end</a>
+ <li><a href="#c++-fe">Known problems with the C++ Front-end</a>
+ <li><a href="#x86-be">Known problems with the X86 Back-end</a>
+ <li><a href="#sparc-be">Known problems with the Sparc Back-end</a>
+ <li><a href="#c-be">Known problems with the C back-end</a>
+ </ul>
+ <li><a href="#additionalinfo">Additional Information</a>
+ </ul>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></b><p>
+ </ol>
+
+
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="intro">Introduction
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ This document contains the release notes for the LLVM compiler infrastructure,
+ release 1.0. Here we describe how to install LLVM, as well as any known
+ problems. The most up-to-date version of this document can be found on the <a
+ href="http://llvm.cs.uiuc.edu/releases/1.0/">LLVM 1.0 web site</a>. If you are
+ not reading this on the LLVM web pages, you should probably go there, because
+ this document may be updated after the release.<p>
+
+ For more information about LLVM, including information about potentially more
+ current releases, please check out the <a href="http://llvm.cs.uiuc.edu">main
+ 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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="whatsnew">What's New?
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ This is the first public release of the LLVM compiler infrastructure. As such,
+ it is all new! In particular, we are providing a stable C compiler, beta C++
+ compiler, a C back-end, stable X86 and Sparc V9 static and JIT code generators,
+ as well as a large suite of scalar and interprocedural optimizations.<p>
+
+ The default optimizer sequence used by the C/C++ front-ends is:<p>
+
+ <ol>
+ <li>CFG simplification (-simplifycfg)
+ <li>Interprocedural dead code elimination (-globaldce)
+ <li>Interprocedural constant propagation (-ipconstprop)
+ <li>Dead argument elimination (-deadargelim)
+ <li>Exception handling pruning (-prune-eh)
+ <li>Function inlining (-inline)
+ <li>Instruction combining (-instcombine)
+ <li>Cast elimination (-raise)
+ <li>Tail duplication (-tailduplicate)
+ <li>CFG simplification (-simplifycfg)
+ <li>Scalar replacement of aggregates (-scalarrepl)
+ <li>Tail call elimination (-tailcallelim)
+ <li>Instruction combining (-instcombine)
+ <li>Reassociation (-reassociate)
+ <li>Instruction combining (-instcombine)
+ <li>CFG simplification (-simplifycfg)
+ <li>Loop canonicalization (-loopsimplify)
+ <li>Loop invariant code motion, with scalar promotion (-licm)
+ <li>Global common subexpression elimination, with load elimination (-gcse)
+ <li>Sparse conditional constant propagation (-sccp)
+ <li>Instruction combining (-instcombine)
+ <li>Induction variable canonicalization (-indvars)
+ <li>Aggressive dead code elimination (-adce)
+ <li>CFG simplication (-simplifycfg)
+ <li>Dead type elimination (-deadtypeelim)
+ <li>Global constant merging (-constmerge)
+ </ol><p>
+
+ At link-time, the following optimizations are run:<p>
+
+ <ol>
+ <li>Global constant merging (-constmerge)
+ <li>[optional] Internalization [which marks most functions and global variables static] (-internalize)
+ <li>Interprocedural constant propagation (-ipconstprop)
+ <li>Interprocedural dead argument elimination (-deadargelim)
+ <li>Instruction combining (-instcombine)
+ <li>CFG simplification (-simplifycfg)
+ <li>Interprocedural dead code elimination (-globaldce)
+ </ol><p>
+
+ At this time, LLVM is known to work properly with SPEC CPU 2000, the Olden
+ benchmarks, and the Ptrdist benchmarks among many other programs. Note however
+ that the Sparc and X86 backends do not currently support exception throwing or
+ long jumping (including 253.perlbmk in SPEC). For these programs you must use
+ the C backend.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="portability">Portability and Supported Platforms
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ LLVM has only been extensively tested on Intel and AMD machines running Red
+ Hat Linux, and Sun UltraSPARC workstations running Solaris 8.
+ The core LLVM infrastructure uses "autoconf" for portability, so hopefully we
+ work on more platforms than that. However, it is extremely likely that we
+ missed something. We welcome portability patches and error messages.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="install-instructions">Installation Instructions
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ FIXME
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="knownproblems">Known Problems
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ This section contains all known problems with the LLVM system, listed by
+ component. As new problems are discovered, they will be added to these
+ sections.
+
+
+ <!-- _______________________________________________________________________ -->
+ <!--
+ </ul><h4><a name="portability"><hr size=0>Portability Problems</h4><ul>
+ -->
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="core"><hr size=0>Known problems with the LLVM Core</h4><ul>
+
+ <li>In the JIT, <tt>dlsym</tt> on a symbol compiled by the JIT will not work.<p>
+
+ <li>The JIT does not use mutexes to protect its internal data structures. As
+ such, execution of a threaded program could cause these data structures to
+ be corrupted.<p>
+
+ <li>It is not possible to <tt>dlopen</tt> an LLVM bytecode file in the JIT.<p>
+
+ <li>Linking in static archive files (.a files) is very slow (there is no symbol
+ table in the archive).
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="c-fe"><hr size=0>Known problems with the C front-end</h4><ul>
+
+ <li>Inline assembly is not yet supported.<p>
+
+ <li>"long double" is transformed by the front-end into "double". There is no
+ support for floating point data types of any size other than 32 and 64 bits.
+ <p>
+ <li>C99 Variable sized arrays do not release stack memory when they go out of
+ scope. Thus, the following program may run out of stack space:
+ <pre>
+ for (i = 0; i != 1000000; ++i) {
+ int X[n];
+ foo(X);
+ }
+ </pre><p>
+
+ <li>The following Unix system functionality has not been tested and may not work:
+ <ol>
+ <li><tt>sigsetjmp</tt>, <tt>siglongjmp</tt> - These are not turned into the
+ appropriate <tt>invoke</tt>/<tt>unwind</tt> instructions.
+ <li><tt>getcontext</tt>, <tt>setcontext</tt>, <tt>makecontext</tt>
+ - These functions have not been tested.
+ </ol><p>
+
+ <li>Bugs:<br>
+ <a href="http://llvm.cs.uiuc.edu/PR6">Oversized integer bitfields cause crash</a>.<br>
+ <p>
+
+ <li>Although many GCC extensions are supported, some are not. In particular,
+ the following extensions are known to <b>not be</b> supported:
+ <ol>
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels">Local Labels</a>: Labels local to a block.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values">Labels as Values</a>: Getting pointers to labels, and computed gotos.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html#Nested%20Functions">Nested Functions</a>: As in Algol and Pascal, lexical scoping of functions.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html#Constructing%20Calls">Constructing Calls</a>: Dispatching a call to another function.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended%20Asm">Extended Asm</a>: Assembler instructions with C expressions as operands.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html#Vector%20Extensions">Vector Extensions</a>: Using vector instructions through built-in functions.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target%20Builtins">Target Builtins</a>: Built-in functions specific to particular targets.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html#Thread-Local">Thread-Local</a>: Per-thread variables.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pragmas.html#Pragmas">Pragmas</a>: Pragmas accepted by GCC.
+ </ol><p>
+
+ The following GCC extensions are <b>partially</b> supported. An ignored
+ attribute means that the LLVM compiler ignores the presence of the attribute,
+ but the code should still work. An unsupported attribute is one which is
+ ignored by the LLVM compiler, which will cause a different interpretation of
+ the program.<p>
+
+ <ol>
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable%20Length">Variable Length</a>:
+ Arrays whose length is computed at run time.<br>
+ Supported, but allocated stack space is not freed until the function returns (noted above).
+
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function%20Attributes">Function Attributes</a>:
+ Declaring that functions have no side effects, or that they can never return.<br>
+ <b>Supported:</b> <tt>format</tt>, <tt>format_arg</tt>, <tt>non_null</tt>, <tt>constructor</tt>, <tt>destructor</tt>, <tt>unused</tt>, <tt>deprecated</tt>,
+ <tt>warn_unused_result</tt>, <tt>weak</tt><br>
+ <b>Ignored:</b> <tt>noreturn</tt>, <tt>noinline</tt>, <tt>always_inline</tt>, <tt>pure</tt>, <tt>const</tt>, <tt>nothrow</tt>, <tt>malloc</tt>
+ <tt>no_instrument_function</tt>, <tt>cdecl</tt><br>
+ <b>Unsupported:</b> <tt>used</tt>, <tt>section</tt>, <tt>alias</tt>, <tt>visibility</tt>, <tt>regparm</tt>, <tt>stdcall</tt>,
+ <tt>fastcall</tt>, all other target specific attributes
+
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html#Variable%20Attributes">Variable Attributes</a>:
+ Specifying attributes of variables.<br>
+ <b>Supported:</b> <tt>cleanup</tt>, <tt>common</tt>, <tt>nocommon</tt>,
+ <tt>deprecated</tt>, <tt>transparent_union</tt>,
+ <tt>unused</tt>, <tt>weak</tt><br>
+ <b>Unsupported:</b> <tt>aligned</tt>, <tt>mode</tt>, <tt>packed</tt>,
+ <tt>section</tt>, <tt>shared</tt>, <tt>tls_model</tt>,
+ <tt>vector_size</tt>, <tt>dllimport</tt>,
+ <tt>dllexport</tt>, all target specific attributes.<br>
+
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Attributes.html#Type%20Attributes">Type Attributes</a>: Specifying attributes of types.
+ <b>Supported:</b> <tt>transparent_union</tt>, <tt>unused</tt>,
+ <tt>deprecated</tt>, <tt>may_alias</tt>
+ <b>Unsupported:</b> <tt>aligned</tt>, <tt>packed</tt>
+ all target specific attributes.<br>
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other%20Builtins">Other Builtins</a>:
+ Other built-in functions.<br>
+ We support all builtins which have a C language equivalent (e.g.,
+ <tt>__builtin_cos</tt>), <tt>__builtin_alloca</tt>,
+ <tt>__builtin_types_compatible_p</tt>, <tt>__builtin_choose_expr</tt>,
+ <tt>__builtin_constant_p</tt>, and <tt>__builtin_expect</tt> (ignored).
+ </ol><p>
+
+
+ The following extensions <b>are</b> known to be supported:
+ <ol>
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html#Statement%20Exprs">Statement Exprs</a>: Putting statements and declarations inside expressions.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Typeof.html#Typeof">Typeof</a>: <code>typeof</code>: referring to the type of an expression.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Lvalues.html#Lvalues">Lvalues</a>: Using <code>?:</code>, "<code>,</code>" and casts in lvalues.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Conditionals.html#Conditionals">Conditionals</a>: Omitting the middle operand of a <code>?:</code> expression.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Long-Long.html#Long%20Long">Long Long</a>: Double-word integers.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Complex.html#Complex">Complex</a>: Data types for complex numbers.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Hex-Floats.html#Hex%20Floats">Hex Floats</a>:Hexadecimal floating-point constants.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html#Zero%20Length">Zero Length</a>: Zero-length arrays.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Empty-Structures.html#Empty%20Structures">Empty Structures</a>: Structures with no members.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html#Variadic%20Macros">Variadic Macros</a>: Macros with a variable number of arguments.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Escaped-Newlines.html#Escaped%20Newlines">Escaped Newlines</a>: Slightly looser rules for escaped newlines.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Subscripting.html#Subscripting">Subscripting</a>: Any array can be subscripted, even if not an lvalue.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html#Pointer%20Arith">Pointer Arith</a>:Arithmetic on <code>void</code>-pointers and function pointers.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Initializers.html#Initializers">Initializers</a>: Non-constant initializers.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html#Compound%20Literals">Compound Literals</a>: Compound literals give structures, unions or arrays as values.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html#Designated%20Inits">Designated Inits</a>: Labeling elements of initializers.
+
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html#Cast%20to%20Union">Cast to Union</a>:Casting to union type from any member of the union.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html#Case%20Ranges">Case Ranges</a>: `case 1 ... 9' and such.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Mixed-Declarations.html#Mixed%20Declarations">Mixed Declarations</a>: Mixing declarations and code.
+
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Prototypes.html#Function%20Prototypes">Function Prototypes</a>: Prototype declarations and old-style definitions.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/C---Comments.html#C++%20Comments">C++ Comments</a>: C++ comments are recognized.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Dollar-Signs.html#Dollar%20Signs">Dollar Signs</a>: Dollar sign is allowed in identifiers.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Character-Escapes.html#Character%20Escapes">Character Escapes</a>: <code>\e</code> stands for the character <ESC>.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alignment.html#Alignment">Alignment</a>: Inquiring about the alignment of a type or variable.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Inline.html#Inline">Inline</a>: Defining inline functions (as fast as macros).
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>:<code>__const__</code>, <code>__asm__</code>, etc., for header files.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete%20Enums">Incomplete Enums</a>: <code>enum foo;</code>, with details to follow.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html#Function%20Names">Function Names</a>: Printable strings which are the name of the current function.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed%20Fields">Unnamed Fields</a>: Unnamed struct/union fields within structs/unions.
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute%20Syntax">Attribute Syntax</a>: Formal syntax for attributes.
+ </ol><p>
+
+ If you run into GCC extensions which have not been included in any of these
+ lists, please let us know (also including whether or not they work).
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="c++-fe"><hr size=0>Known problems with the C++ front-end</h4><ul>
+
+ For this release, the C++ front-end is considered to be of <b>beta</b> quality.
+ It works for a large number of simple programs, but has not been extensively
+ tested. We welcome bug reports though!<p>
+
+ <li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
+ front-end</a><p>
+
+ <li>The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser. This
+ parser is significantly more standards compliant (and picky) than prior GCC
+ versions. For more information, see the C++ section of the <a
+ href="http://gcc.gnu.org/gcc-3.4/changes.html">GCC 3.4 release notes</a>.<p>
+
+ <li>Destructors for local objects are not always run when a <tt>longjmp</tt> is
+ performed. In particular, destructors for objects in the <tt>longjmp</tt>ing
+ function and in the <tt>setjmp</tt> receiver function may not be run.
+ Objects in intervening stack frames will be destroyed however (which is
+ better than most compilers).<p>
+
+ <li>The LLVM C++ front-end follows the <a
+ href="http://www.codesourcery.com/cxx-abi">Itanium C++ ABI</a>.
+ This document, which is not Itanium specific, specifies a standard for name
+ mangling, class layout, v-table layout, RTTI formats, and other C++
+ representation issues. Because we use this API, code generated by the LLVM
+ compilers should be binary compatible with machine code generated by other
+ Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc).
+ <i>However</i>, the exception handling mechanism used by LLVM is very
+ different from the model used in the Itanium ABI, so <b>exceptions will not
+ interact correctly</b> .
+
+ <li><a href="http://llvm.cs.uiuc.edu/PR11">Code for executing
+ destructors when unwinding is not shared</a>.
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="x86-be"><hr size=0>Known problems with the X86 back-end</h4><ul>
+
+ <li>The X86 code generator <a
+ href="http://llvm.cs.uiuc.edu/PR16">does not currently
+ support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
+ or calls the C <tt>longjmp</tt> function will abort.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="sparc-be"><hr size=0>Known problems with the Sparc back-end</h4><ul>
+
+ <li>The Sparc code generator <a
+ href="http://llvm.cs.uiuc.edu/PR15">does not currently
+ support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
+ or calls the C <tt>longjmp</tt> function will abort.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="c-be"><hr size=0>Known problems with the C back-end</h4><ul>
+
+ <li>The C back-end produces code that violates the ANSI C Type-Based Alias
+ Analysis rules. As such, special options may be necessary to compile the code
+ (for example, GCC requires the <tt>-fno-strict-aliasing</tt> option). This
+ problem probably cannot be fixed.<p>
+
+ <li><a href="http://llvm.cs.uiuc.edu/PR33">Initializers for global variables</a>
+ cannot include special floating point numbers like Not-A-Number or Infinity.<p>
+
+ <li><a href="http://zion.cs.uiuc.edu/PR56">Zero arg vararg functions are not
+ supported</a>. This should not affect LLVM produced by the C or C++
+ frontends.<p>
+
+ <li>The code produces by the C back-end has only been tested with the Sun CC and
+ GCC compilers. It is possible that it will have to be adjusted to support other
+ C compilers.<p>
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="additionalinfo">Additional Information
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ A wide variety of additional information is available on the LLVM web page,
+ including mailing lists publications describing algorithms and components
+ implemented in LLVM. The web page also contains versions of the API
+ documentation which is up-to-date with the CVS 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>
+
+ If you have any questions or comments about LLVM, please feel free to contact us
+ via the mailing lists.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr><font size-1>
+
+ Maintained By: <a href="http://llvm.cs.uiuc.edu/">The LLVM Team</a><br>
+ <!-- Created: Wed Oct 1 17:38:54 CDT 2003 -->
+ <!-- hhmts start -->
+ Last modified: Mon Oct 20 14:04:51 CDT 2003
+ <!-- hhmts end -->
+ </body></html>
Index: llvm-www/releases/1.0/ReleaseTasks.html
diff -c /dev/null llvm-www/releases/1.0/ReleaseTasks.html:1.1
*** /dev/null Fri Oct 24 15:51:51 2003
--- llvm-www/releases/1.0/ReleaseTasks.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,179 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html>
+ <head>
+ <title>LLVM Public Release Project</title>
+ </head>
+ <body bgcolor="white">
+ <center>
+ <h1><font size="7">LLVM Public Release Project</font></h1>
+ </center>
+ <ul>
+ <li><a href="#what">What is this?</a> </li>
+ <li><a href="#priorities">Priorities</a>
+ <ol>
+ <li><a href="#high">High Priority</a> </li>
+ <li><a href="#medium">Medimum Priority</a> </li>
+ <li><a href="#low">Low Priority</a> </li>
+ </ol>
+ </li>
+ </ul>
+ <br>
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border="0" cellpadding="4"
+ cellspacing="0">
+ <tbody>
+ <tr>
+ <td align="center"><font color="#eeeeff" size="+2"
+ face="Georgia,Palatino"><b> <a name="what">What is this? </a></b><a
+ name="what"></a></font></td>
+ </tr>
+ </tbody>
+ </table>
+ <ul>
+ <!-- *********************************************************************** -->
+ This document is a list of things to do before the LLVM project is
+ publicly released. It will provide a checklist so that we know
+ what has been done and what is left to be done. It will also keep
+ a "wishlist" of desirable features.
+ <p><!-- *********************************************************************** -->
+ </p>
+ </ul>
+ <table width="100%" bgcolor="#330077" border="0" cellpadding="4"
+ cellspacing="0">
+ <tbody>
+ <tr>
+ <td align="center"><font color="#eeeeff" size="+2"
+ face="Georgia,Palatino"><b> <a name="priorities">Priorities</a></b><a
+ name="improving"></a></font></td>
+ </tr>
+ </tbody>
+ </table>
+ <ul>
+ <!-- *********************************************************************** -->The
+ list of things to do...
+ <p><!-- ======================================================================= -->
+ </p>
+ </ul>
+ <table width="50%" bgcolor="#441188" border="0" cellpadding="4"
+ cellspacing="0">
+ <tbody>
+ <tr>
+ <td> </td>
+ <td width="100%"> <font color="#eeeeff" size="+1"
+ face="Georgia,Palatino"><b><a name="high">High Priority</a></b><a
+ name="glibc"></a></font></td>
+ </tr>
+ </tbody>
+ </table>
+ <ul>
+ <ul>
+ <ul>
+ </ul>
+ <li>Documentation</li>
+ <ul>
+ <li>Expand documentation on creating an LLVM project.</li>
+ </ul>
+ <li>Licenses</li>
+ <ul>
+ <li>Create license files for anything in the distribution that is
+ not under our license.<br>
+ </li>
+ </ul>
+ <li>Ensure SafeCode builds.</li>
+ <li>Create a system for managing development and releases (i.e. CVS
+ branching, labeling revisions, etc).</li>
+ <li>Create a web page for downloading LLVM.
+ <li>Create a method for requesting the GCC front end source code.
+ </ul>
+ <p><!-- ======================================================================= -->
+ </p>
+ </ul>
+ <table width="50%" bgcolor="#441188" border="0" cellpadding="4"
+ cellspacing="0">
+ <tbody>
+ <tr>
+ <td> </td>
+ <td width="100%"> <font color="#eeeeff" size="+1"
+ face="Georgia,Palatino"><b><a name="medium">Medium Priority</a></b><a
+ name="NightlyTest"></a></font></td>
+ </tr>
+ </tbody>
+ </table>
+ <ul>
+ <ul>
+ <li>Improve documentation on how to create an LLVM project.<br>
+ </li>
+ <li>Test Suite</li>
+ <ul>
+ <li>Add Feature and Regression tests to nightly tester.</li>
+ <li>Develop better QMTest database method.<br>
+ </li>
+ </ul>
+ <li>Write regression tests.</li>
+ <ul>
+ <li>The C++ constructor on dlopen() bug on Solaris.</li>
+ </ul>
+ </ul>
+ <ul>
+ <li>Release Management</li>
+ </ul>
+ <ul>
+ <ul>
+ <li>Find and implement a bug reporting system (i.e. Bugzilla).</li>
+ </ul>
+ </ul>
+ <p><!-- ======================================================================= -->
+ </p>
+ </ul>
+ <table width="50%" bgcolor="#441188" border="0" cellpadding="4"
+ cellspacing="0">
+ <tbody>
+ <tr>
+ <td> </td>
+ <td width="100%"> <font color="#eeeeff" size="+1"
+ face="Georgia,Palatino"><b><a name="low">Low Priority</a></b><a
+ name="programs"></a></font></td>
+ </tr>
+ </tbody>
+ </table>
+ <ul>
+ <ul>
+ <li>GCC C Front End</li>
+ <ul>
+ <li>Place the C front end into the CVS repository.</li>
+ <li>Ensure that the C front end compiles and installs nicely.</li>
+ </ul>
+ <li>Create an installer for the software.</li>
+ <li>Testing</li>
+ <ul>
+ <li>Create descriptions of what each test is doing (test
+ specifications).<br>
+ </li>
+ <li>Test LLVM on various Linux distributions.</li>
+ <li>Test LLVM on various Solaris versions.</li>
+ <li>Test LLVM on Solaris/x86.</li>
+ </ul>
+ <ul>
+ </ul>
+ <li>Documentation</li>
+ <ul>
+ <li>Create man pages for the LLVM utilities.</li>
+ <li>Create man pages for the LLVM libraries.</li>
+ </ul>
+ <li>Rewrite this page without Netscape Composer :)<br>
+ </li>
+ </ul>
+ </ul>
+ <font size-1="">
+ <address><a href="mailto:criswell at cs.uiuc.edu">John Criswell</a></address>
+ <!-- Created: Tue Aug 6 15:00:33 CDT 2002 --><!-- hhmts start --> Last
+ modified: Sat May 31 14:54:03 CDT 2003<!-- hhmts end --> </font> <br>
+ <br>
+ <br>
+ <br>
+ <br>
+ <br>
+ <br>
+ <br>
+ </body>
+ </html>
Index: llvm-www/releases/1.0/TestingGuide.html
diff -c /dev/null llvm-www/releases/1.0/TestingGuide.html:1.1
*** /dev/null Fri Oct 24 15:51:52 2003
--- llvm-www/releases/1.0/TestingGuide.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,429 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <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>LLVM Test Suite Guide</title>
+ </head>
+
+ <body>
+
+ <div class="doc_title">
+ LLVM Test Suite Guide
+ </div>
+
+ <ol>
+ <li><a href="#overview">Overview</a></li>
+ <li><a href="#Requirements">Requirements</a></li>
+ <li><a href="#quick">Quick Start</a></li>
+ <li><a href="#org">LLVM Test Suite Organization</a></li>
+ <ul>
+ <li><a href="#codefragments">Code Fragments</a></li>
+ <li><a href="#wholeprograms">Whole Programs</a></li>
+ </ul>
+ <li><a href="#tree">LLVM Test Suite Tree</a></li>
+ <li><a href="#qmstructure">QMTest Structure</a></li>
+ <li><a href="#progstructure">Programs Structure</a></li>
+ <li><a href="#run">Running the LLVM Tests</a></li>
+ <p><b>Written by John T. Criswell</b></p>
+ </ol>
+
+ <!--===============================================================-->
+ <div class="doc_section"><a name="overview">Overview</a></div>
+ <!--===============================================================-->
+
+ <div class="doc_text">
+ <p>
+ This document is the reference manual for the LLVM test suite. It
+ documents the structure of the LLVM test suite, 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 test suite, you will need all of the software
+ required to build LLVM, plus the following:
+ </p>
+ <dl compact>
+ <dt><A HREF="http://www.qmtest.com">QMTest</A></dt>
+ <dd>The LLVM test suite uses QMTest to organize and
+ run tests.</dd>
+
+ <dt><A HREF="http://www.python.org">Python</A></dt>
+ <dd>You will need a Python interpreter that works with
+ QMTest. Python will need zlib and SAX support
+ enabled.</dd>
+ </dl>
+ </div>
+
+ <!--===============================================================-->
+ <div class="doc_section"><a name="quick">Quick Start</a></div>
+ <!--===============================================================-->
+
+ <div class="doc_text">
+ <p>
+ The tests are located in the LLVM source tree under the directory
+ <tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master
+ Makefile in that directory:
+ </p>
+ <pre>
+ % make -C llvm/test
+ </pre>
+
+ <p>
+ To run only the code fragment tests (i.e. those that do basic testing of
+ LLVM), run the tests organized by QMTest:
+ </p>
+
+ <pre>
+ % make -C llvm/test qmtest
+ </pre>
+
+ <p>
+ To run only the tests that compile and execute whole programs, run the
+ Programs tests:
+ </p>
+
+ <pre>
+ % make -C llvm/test/Programs
+ </pre>
+ </div>
+
+ <!--===============================================================-->
+ <div class="doc_section"><h2><a name="org">LLVM Test Suite
+ Organization </a></div>
+ <!--===============================================================-->
+
+ <div class="doc_text">
+ <p>The LLVM test suite contains two major categories of tests: code
+ fragments and whole programs.</p>
+ </div>
+
+ <div class="doc_subsection"><a name="codefragments">Code Fragments</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.
+ </p><p>
+ Code fragments are not complete programs, and they are
+ never executed to determine correct behavior.
+ </p><p>
+ The tests in the Features and
+ Regression directories contain code fragments.
+ </p>
+ </div>
+
+ <div class="doc_subsection"><a name="wholeprograms">Whole Programs</a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Whole Programs 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 Programs directory contains all tests which compile and
+ benchmark whole programs.
+ </p>
+ </div>
+
+ <!--===============================================================-->
+ <div class="doc_section"><h2><a name="tree">LLVM Test Suite Tree</a>
+ </div>
+ <!--===============================================================-->
+
+ <div class="doc_text">
+ <p>Each type of test in the LLVM test suite has its own directory. The
+ major subtrees of the test suite directory tree are as follows:</p>
+
+ <ul>
+ <li>Features
+ <p>
+ This directory contains sample codes that test various features
+ of the LLVM language. These pieces of sample code are run
+ through various assembler, disassembler, and optimizer passes.
+ </p>
+
+ <li>Regression
+ <p>
+ This directory contains regression tests for LLVM. 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>
+
+ <li>Programs
+ <p>
+ The Programs directory contains 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>
+ In addition for testing correctness, the Programs 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>
+ The Programs directory is subdivided into several smaller
+ subdirectories:
+ </p>
+
+ <ul>
+ <li>Programs/SingleSource
+ <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>Programs/MultiSource
+ <p>
+ The MultiSource directory contains subdirectories which
+ contain entire programs with multiple source files.
+ Large benchmarks and whole applications go here.
+ </p>
+
+ <li>Programs/External
+ <p>
+ The External directory contains Makefiles for building
+ code that is external to (i.e. not distributed with)
+ LLVM. The most prominent member of this directory is
+ the SPEC 2000 benchmark suite. The presence and
+ location of these external programs is configured by the
+ LLVM <tt>configure</tt> script.
+ </p>
+ </ul>
+
+ <p>
+
+ <li>QMTest
+ <p>
+ This directory contains the QMTest information files. Inside
+ this directory are QMTest administration files and the Python
+ code that implements the LLVM test and database classes.
+ </p>
+ </ul>
+ </div>
+
+ <!--===============================================================-->
+ <div class="doc_section"><h2><a name="qmstructure">QMTest Structure</a>
+ </div>
+ <!--===============================================================-->
+
+ <div class="doc_text">
+ <p>
+ The LLVM test suite is partially driven by QMTest and partially
+ driven by GNU Make. Specifically, the Features and Regression tests
+ are all driven by QMTest. The Programs directory is currently
+ driven by a set of Makefiles.
+ </p><p>
+ The QMTest system needs to have several pieces of information
+ available; these pieces of configuration information are known
+ collectively as the "context" in QMTest parlance. Since the context
+ for LLVM is relatively large, the master Makefile in llvm/test
+ sets it for you.
+ </p><p>
+ The LLVM database class makes the subdirectories of llvm/test a
+ QMTest test database. For each directory that contains tests driven by
+ QMTest, it knows what type of test the source file is and how to run it.
+ </p><p>
+ Hence, the QMTest namespace is essentially what you see in the
+ Feature and Regression directories, but there is some magic that
+ the database class performs (as described below).
+ </p><p>
+ The QMTest namespace is currently composed of the following tests and
+ test suites:
+ </p>
+
+ <ul>
+ <li>Feature
+ <p>
+ These are the feature tests found in the Feature directory.
+ They are broken up into the following categories:
+ </p>
+ <ul>
+ <li>ad
+ <p>
+ Assembler/Disassembler tests. These tests verify that a
+ piece of LLVM assembly language can be assembled into
+ bytecode and then disassembled into the original
+ assembly language code. It does this several times to
+ ensure that assembled output can be disassembled and
+ disassembler output can be assembled. It also verifies
+ that the give assembly language file can be assembled
+ correctly.
+ </p>
+
+ <li>opt
+ <p>
+ Optimizer tests. These tests verify that two of the
+ optimizer passes completely optimize a program (i.e.
+ after a single pass, they cannot optimize a program
+ any further).
+ </p>
+
+ <li>mc
+ <p>
+ Machine code tests. These tests verify that the LLVM
+ assembly language file can be translated into native
+ assembly code.
+ </p>
+
+ <li>cc
+ <p>
+ C code tests. These tests verify that the specified
+ LLVM assembly code can be converted into C source code
+ using the C backend.
+ </p>
+ </ul>
+
+ <p>
+ The LLVM database class looks at every file in the Feature
+ directory and creates a fake test hierarchy containing
+ <tt>Feature.<testtype>.<testname></tt>. So, if you
+ add an LLVM assembly language file to the Feature directory, it
+ actually creates 5 new tests: assembler/disassembler, assembler,
+ optimizer, machine code, and C code.
+ </p>
+
+ <li>Regression
+ <p>
+ These are the regression tests. There is one suite for each
+ subdirectory of the Regression directory. If you add a new
+ subdirectory there, you will need to modify, at least, the
+ <tt>RegressionMap</tt> variable in <tt>QMTest/llvmdb.py</tt> so
+ that QMTest knows how to run the tests in the new subdirectory.
+ </p>
+ </ul>
+ </div>
+
+ <!--===============================================================-->
+ <div class="doc_section"><h2><a name="progstructure">Programs
+ Structure</a></div>
+ <!--===============================================================-->
+
+ <div class="doc_text">
+ <p>
+ As mentioned previously, the Programs tree in llvm/test provides three
+ types of tests: MultiSource, SingleSource, and External. 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>
+ In addition to the regular Programs tests, the Programs tree also
+ provides a mechanism for compiling the programs in different ways. If
+ the variable TEST is defined on the gmake 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_section"><h2><a name="run">Running the LLVM Tests</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>
+ The master Makefile in llvm/test is capable of running both the
+ QMTest driven tests and the Programs tests. By default, it will run
+ all of the tests.
+ </p><p>
+ To run only the QMTest driven tests, run <tt>make qmtest</tt> at the
+ command line in llvm/tests. To run a specific qmtest, suffix the test
+ name with ".t" when running make.
+ </p><p>
+ For example, to run the Regression.LLC tests, type
+ <tt>make Regression.LLC.t</tt> in llvm/tests.
+ </p><p>
+ Note that the Makefiles in llvm/test/Features and llvm/test/Regression
+ are gone. You must now use QMTest from the llvm/test directory to run
+ them.
+ </p><p>
+ To run the Programs test, cd into the llvm/test/Programs directory and
+ type <tt>make</tt>. Alternatively, you can type <tt>make
+ TEST=<type> test</tt> to run one of the specialized tests in
+ llvm/test/Programs/TEST.<type>.Makefile. For example, you could
+ run the nightly tester tests using the following commands:
+ </p>
+
+ <pre>
+ % cd llvm/test/Programs
+ % make TEST=nightly test
+ </pre>
+
+ <p>
+ Regardless of which test you're running, the results are printed on
+ standard output and standard error. You can redirect these results to a
+ file if you choose.
+ </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
+ QMTest, 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 Programs tests have no such feature as of 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>
+
+ <!-- *********************************************************************** -->
+
+ <hr><font size="-1">
+ <address>John T. Criswell</address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2003/10/24 20:51:39 $
+ </font>
+
+ </body>
+ </html>
Index: llvm-www/releases/1.0/WritingAnLLVMPass.html
diff -c /dev/null llvm-www/releases/1.0/WritingAnLLVMPass.html:1.1
*** /dev/null Fri Oct 24 15:51:52 2003
--- llvm-www/releases/1.0/WritingAnLLVMPass.html Fri Oct 24 15:51:39 2003
***************
*** 0 ****
--- 1,1283 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+ <html><head><title>Writing an LLVM Pass</title></head>
+
+ <body bgcolor=white>
+
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> <font size=+3 color="#EEEEFF" face="Georgia,Palatino,Times,Roman"><b>Writing an LLVM Pass</b></font></td>
+ </tr></table>
+
+
+ <ol>
+ <li><a href="#introduction">Introduction - What is a pass?</a>
+ <li><a href="#quickstart">Quick Start - Writing hello world</a>
+ <ul>
+ <li><a href="#makefile">Setting up the build environment</a>
+ <li><a href="#basiccode">Basic code required</a>
+ <li><a href="#running">Running a pass with <tt>opt</tt>
+ or <tt>analyze</tt></a>
+ </ul>
+ <li><a href="#passtype">Pass classes and requirements</a>
+ <ul>
+ <li><a href="#ImmutablePass">The <tt>ImmutablePass</tt> class</a>
+ <li><a href="#Pass">The <tt>Pass</tt> class</a>
+ <ul>
+ <li><a href="#run">The <tt>run</tt> method</a>
+ </ul>
+ <li><a href="#FunctionPass">The <tt>FunctionPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_mod">The <tt>doInitialization(Module
+ &)</tt> method</a>
+ <li><a href="#runOnFunction">The <tt>runOnFunction</tt> method</a>
+ <li><a href="#doFinalization_mod">The <tt>doFinalization(Module
+ &)</tt> method</a>
+ </ul>
+ <li><a href="#BasicBlockPass">The <tt>BasicBlockPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_fn">The <tt>doInitialization(Function
+ &)</tt> method</a>
+ <li><a href="#runOnBasicBlock">The <tt>runOnBasicBlock</tt> method</a>
+ <li><a href="#doFinalization_fn">The <tt>doFinalization(Function
+ &)</tt> method</a>
+ </ul>
+ <li><a href="#MachineFunctionPass">The <tt>MachineFunctionPass</tt>
+ class</a>
+ <ul>
+ <li><a href="#runOnMachineFunction">The
+ <tt>runOnMachineFunction(MachineFunction &)</tt> method</a>
+ </ul>
+ </ul>
+ <li><a href="#registration">Pass Registration</a>
+ <ul>
+ <li><a href="#print">The <tt>print</tt> method</a>
+ </ul>
+ <li><a href="#interaction">Specifying interactions between passes</a>
+ <ul>
+ <li><a href="#getAnalysisUsage">The <tt>getAnalysisUsage</tt> method</a>
+ <li><a href="#getAnalysis">The <tt>getAnalysis</tt> method</a>
+ </ul>
+ <li><a href="#analysisgroup">Implementing Analysis Groups</a>
+ <ul>
+ <li><a href="#agconcepts">Analysis Group Concepts</a>
+ <li><a href="#registerag">Using <tt>RegisterAnalysisGroup</tt></a>
+ </ul>
+ <li><a href="#passmanager">What PassManager does</a>
+ <ul>
+ <li><a href="#releaseMemory">The <tt>releaseMemory</tt> method</a>
+ </ul>
+ <li><a href="#debughints">Using GDB with dynamically loaded passes</a>
+ <ul>
+ <li><a href="#breakpoint">Setting a breakpoint in your pass
+ <li><a href="#debugmisc">Miscellaneous Problems
+ </ul>
+ <li><a href="#future">Future extensions planned</a>
+ <ul>
+ <li><a href="#SMP">Multithreaded LLVM</a>
+ <li><a href="#ModuleSource">A new <tt>ModuleSource</tt> interface</a>
+ <li><a href="#PassFunctionPass"><tt>Pass</tt>'s requiring <tt>FunctionPass</tt>'s</a>
+ </ul>
+
+ <p><b>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></b><p>
+ </ol><p>
+
+
+
+ <!-- *********************************************************************** -->
+ <table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="introduction">Introduction - What is a pass?
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ The LLVM Pass Framework is an important part of the LLVM system, because LLVM
+ passes are where 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>
+
+ All LLVM passes are subclasses of the <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classPass.html">Pass</a></tt> class, which
+ implement functionality by overriding virtual methods inherited from
+ <tt>Pass</tt>. Depending on how your pass works, you may be able to inherit
+ from the <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/structFunctionPass.html">FunctionPass</a></tt>
+ or <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/structBasicBlockPass.html">BasicBlockPass</a></tt>,
+ 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 has.<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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="quickstart">Quick Start - Writing hello world
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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, 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="makefile">Setting up the build environment
+ </b></font></td></tr></table><ul>
+
+ First thing you need to do is create a new directory somewhere in the LLVM
+ source base. For this example, we'll assume that you made
+ "<tt>lib/Transforms/Hello</tt>". The first thing you must do is set up a build
+ script (Makefile) that will compile the source code for the new pass. To do
+ this, copy this into "<tt>Makefile</tt>":<p>
+
+ </ul><hr><ul><pre>
+ # Makefile for hello pass
+
+ # Path to top level of LLVM heirarchy
+ LEVEL = ../../..
+
+ # Name of the library to build
+ LIBRARYNAME = hello
+
+ # Build a dynamically loadable shared object
+ SHARED_LIBRARY = 1
+
+ # Include the makefile implementation stuff
+ include $(LEVEL)/Makefile.common
+ </pre></ul><hr><ul><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>lib/Debug/libhello.so</tt> shared object that can be dynamically loaded by
+ the <tt>opt</tt> or <tt>analyze</tt> tools.<p>
+
+ Now that we have the build scripts set up, we just need to write the code for
+ the pass itself.<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="basiccode">Basic code required
+ </b></font></td></tr></table><ul>
+
+ Now that we have a way to compile our new pass, we just have to write it. Start
+ out with:<p>
+
+ <pre>
+ <b>#include</b> "<a href="http://llvm.cs.uiuc.edu/doxygen/Pass_8h-source.html">llvm/Pass.h</a>"
+ <b>#include</b> "<a href="http://llvm.cs.uiuc.edu/doxygen/Function_8h-source.html">llvm/Function.h</a>"
+ </pre>
+
+ Which are needed because we are writing a <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classPass.html">Pass</a></tt>, and we are
+ operating on <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classFunction.html">Function</a></tt>'s.<p>
+
+ Next we have:<p>
+
+ <pre>
+ <b>namespace</b> {
+ </pre><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>
+
+ Next, we declare our pass itself:<p>
+
+ <pre>
+ <b>struct</b> Hello : <b>public</b> <a href="#FunctionPass">FunctionPass</a> {
+ </pre><p>
+
+ This declares a "<tt>Hello</tt>" class that is a subclass of <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/structFunctionPass.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>
+
+ <pre>
+ <b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
+ std::cerr << "<i>Hello: </i>" << F.getName() << "\n";
+ <b>return false</b>;
+ }
+ }; <i>// end of struct Hello</i>
+ </pre>
+
+ 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>
+
+ <pre>
+ RegisterOpt<Hello> X("<i>hello</i>", "<i>Hello World Pass</i>");
+ } <i>// end of anonymous namespace</i>
+ </pre><p>
+
+ Lastly, we register our class <tt>Hello</tt>, giving it a command line argument
+ "<tt>hello</tt>", and a name "<tt>Hello World Pass</tt>". There are several
+ different ways of <a href="#registration">registering your pass</a>, depending
+ on what it is to be used for. For "optimizations" we use the
+ <tt>RegisterOpt</tt> template.<p>
+
+ As a whole, the <tt>.cpp</tt> file looks like:<p>
+
+ <pre>
+ <b>#include</b> "<a href="http://llvm.cs.uiuc.edu/doxygen/Pass_8h-source.html">llvm/Pass.h</a>"
+ <b>#include</b> "<a href="http://llvm.cs.uiuc.edu/doxygen/Function_8h-source.html">llvm/Function.h</a>"
+
+ <b>namespace</b> {
+ <b>struct Hello</b> : <b>public</b> <a href="#FunctionPass">FunctionPass</a> {
+ <b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
+ std::cerr << "<i>Hello: </i>" << F.getName() << "\n";
+ <b>return false</b>;
+ }
+ };
+
+ RegisterOpt<Hello> X("<i>hello</i>", "<i>Hello World Pass</i>");
+ }
+ </pre><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>lib/Debug/libhello.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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="running">Running a pass with <tt>opt</tt> or <tt>analyze</tt>
+ </b></font></td></tr></table><ul>
+
+ Now that you have a brand new shiny <tt>.so</tt> 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>RegisterOpt</tt> template, you will be able to
+ use the <tt>opt</tt> tool to access it, once loaded.<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 bytecode file (<tt>hello.bc</tt>) for the program
+ through our transformation like this (or course, any bytecode file will
+ work):<p>
+
+ <pre>
+ $ opt -load ../../../lib/Debug/libhello.so -hello < hello.bc > /dev/null
+ Hello: __main
+ Hello: puts
+ Hello: main
+ </pre><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>
+
+ To see what happened to the other string you registered, try running
+ <tt>opt</tt> with the <tt>--help</tt> option:<p>
+
+ <pre>
+ $ opt -load ../../../lib/Debug/libhello.so --help
+ OVERVIEW: llvm .bc -> .bc modular optimizer
+
+ USAGE: opt [options] <input bytecode>
+
+ 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><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>
+
+ <pre>
+ $ opt -load ../../../lib/Debug/libhello.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%) Bytecode 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><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.
+
+ 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>
+
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="passtype">Pass classes and requirements
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ 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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="ImmutablePass">The <tt>ImmutablePass</tt> class
+ </b></font></td></tr></table><ul>
+
+ The most plain and boring type of pass is the "<tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/structImmutablePass.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>
+
+ 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>
+
+ <tt>ImmutablePass</tt>'s never invalidate other transformations, are never
+ invalidated, and are never "run".<p>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="Pass">The <tt>Pass</tt> class
+ </b></font></td></tr></table><ul>
+
+ The "<tt><a href="http://llvm.cs.uiuc.edu/doxygen/classPass.html">Pass</a></tt>"
+ class is the most general of all superclasses that you can use. Deriving from
+ <tt>Pass</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 direct <tt>Pass</tt>
+ subclasses, no optimization can be done for their execution.<p>
+
+ To write a correct <tt>Pass</tt> subclass, derive from <tt>Pass</tt> and
+ overload the <tt>run</tt> method with the following signature:<p>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="run"><hr size=0>The <tt>run</tt> method</h4><ul>
+
+
+ <pre>
+ <b>virtual bool</b> run(Module &M) = 0;
+ </pre><p>
+
+ The <tt>run</tt> method performs the interesting work of the pass, and should
+ return true if the module was modified by the transformation, false
+ otherwise.<p>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="FunctionPass">The <tt>FunctionPass</tt> class
+ </b></font></td></tr></table><ul>
+
+ In contrast to direct <tt>Pass</tt> subclasses, direct <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classPass.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>
+
+ 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>Add or remove Function's from the current Module.
+ <li>Add or remove global variables from the current Module.
+ <li>Maintain state across invocations of
+ <a href="#runOnFunction"><tt>runOnFunction</tt></a> (including global data)
+ </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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="doInitialization_mod"><hr size=0>The
+ <tt>doInitialization(Module &)</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> doInitialization(Module &M);
+ </pre><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>
+
+ A good example of how this method should be used is the <a
+ href="http://llvm.cs.uiuc.edu/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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="runOnFunction"><hr size=0>The <tt>runOnFunction</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> runOnFunction(Function &F) = 0;
+ </pre><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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="doFinalization_mod"><hr size=0>The <tt>doFinalization(Module &)</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> doFinalization(Module &M);
+ </pre></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>
+
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="BasicBlockPass">The <tt>BasicBlockPass</tt> class</a>
+ </b></font></td></tr></table><ul>
+
+ <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>Maintain state across invocations of
+ <a href="#runOnBasicBlock"><tt>runOnBasicBlock</tt></a>
+ <li>Modify the constrol flow graph (by altering terminator instructions)
+ <li>Any of the things verboten for
+ <a href="#FunctionPass"><tt>FunctionPass</tt></a>'s.
+ </ol><p>
+
+ <tt>BasicBlockPass</tt>'s 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="doInitialization_fn"><hr size=0>The
+ <tt>doInitialization(Function &)</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> doInitialization(Function &F);
+ </pre><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 type of stuff 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="runOnBasicBlock"><hr size=0>The <tt>runOnBasicBlock</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> runOnBasicBlock(BasicBlock &BB) = 0;
+ </pre><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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="doFinalization_fn"><hr size=0>The <tt>doFinalization(Function
+ &)</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> doFinalization(Function &F);
+ </pre></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>
+
+
+ <!-- ======================================================================= -->
+ </ul><table width="100%" bgcolor="#441188" border=0 cellpadding=4 cellspacing=0>
+ <tr><td> </td><td width="100%">
+ <font color="#EEEEFF" face="Georgia,Palatino"><b>
+ <a name="MachineFunctionPass">The <tt>MachineFunctionPass</tt> class
+ </b></font></td></tr></table><ul>
+
+ A <tt>MachineFunctionPass</tt> executes on the machine-dependent
+ representation of each LLVM function in the program,
+ independent of all of the other functions 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:
+
+ <ol>
+ <li>Modify any LLVM Instructions, BasicBlocks or Functions.
+ <li>Modify a MachineFunction other than the one currently being processed.
+ <li>Add or remove MachineFunctions from the current Module.
+ <li>Add or remove global variables from the current Module.
+ <li>Maintain state across invocations of
+ <a href="#runOnMachineFunction"><tt>runOnMachineFunction</tt></a> (including global data)
+ </ol><p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="runOnMachineFunction"><hr size=0>The
+ <tt>runOnMachineFunction(MachineFunction &MF)</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual bool</b> runOnMachineFunction(MachineFunction &MF) = 0;
+ </pre></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>
+
+ 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>
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="registration">Pass registration
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ Passes can be registered in several different ways. Depending on the general
+ classification of the pass, you should use one of the following templates to
+ register the pass:<p>
+
+ <ul>
+ <li><b><tt>RegisterOpt</tt></b> - This template should be used when you are
+ registering a pass that logically should be available for use in the
+ '<tt>opt</tt>' utility.<p>
+
+ <li><b><tt>RegisterAnalysis</tt></b> - This template should be used when you are
+ registering a pass that logically should be available for use in the
+ '<tt>analysis</tt>' utility.<p>
+
+ <li><b><tt>RegisterLLC</tt></b> - This template should be used when you are
+ registering a pass that logically should be available for use in the
+ '<tt>llc</tt>' utility.<p>
+
+ <li><b><tt>RegisterPass</tt></b> - This is the generic form of the
+ <tt>Register*</tt> templates that should be used if you want your pass listed by
+ multiple or no utilities. This template takes an extra third argument that
+ specifies which tools it should be listed in. See the <a
+ href="http://llvm.cs.uiuc.edu/doxygen/PassSupport_8h-source.html">PassSupport.h</a>
+ file for more information.<p>
+ </ul><p>
+
+ Regardless of how you register your pass, you must specify 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 <tt>opt</tt> or <tt>analyze</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>
+
+ If you pass is constructed by its default constructor, you only ever have to
+ pass these two arguments. If, on the other hand, you require other information
+ (like target specific information), you must pass an additional argument. This
+ argument is a pointer to a function used to create the pass. For an example of
+ how this works, look at the <a
+ href="http://llvm.cs.uiuc.edu/doxygen/LowerAllocations_8cpp-source.html">LowerAllocations.cpp</a>
+ file.<p>
+
+ If a pass is registered to be used by the <tt>analyze</tt> utility, you should
+ implement the virtual <tt>print</tt> method:<p>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="print"><hr size=0>The <tt>print</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual void</b> print(std::ostream &O, <b>const</b> Module *M) <b>const</b>;
+ </pre><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. The <tt>analyze</tt> tool uses this method to generate its output.<p>
+
+ The <tt>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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="interaction">Specifying interactions between passes
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ One of the main responsibilities of the <tt>PassManager</tt> is the 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="getAnalysisUsage"><hr size=0>The <tt>getAnalysisUsage</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual void</b> getAnalysisUsage(AnalysisUsage &Info) <b>const</b>;
+ </pre><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.cs.uiuc.edu/doxygen/classAnalysisUsage.html">AnalysisUsage</a></tt>
+ object with information about which passes are required and not invalidated. To do this, the following set methods are provided by the <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classAnalysisUsage.html">AnalysisUsage</a></tt> class:<p>
+
+ <pre>
+ <i>// addRequires - Add the specified pass to the required set for your pass.</i>
+ <b>template</b><<b>class</b> PassClass>
+ AnalysisUsage &AnalysisUsage::addRequired();
+
+ <i>// addPreserved - Add the specified pass to the set of analyses preserved by
+ // this pass</i>
+ <b>template</b><<b>class</b> PassClass>
+ AnalysisUsage &AnalysisUsage::addPreserved();
+
+ <i>// setPreservesAll - Call this if the pass does not modify its input at all</i>
+ <b>void</b> AnalysisUsage::setPreservesAll();
+
+ <i>// setPreservesCFG - This function should be called by the pass, iff they do not:
+ //
+ // 1. Add or remove basic blocks from the function
+ // 2. Modify terminator instructions in any way.
+ //
+ // This is automatically implied for <a href="#BasicBlockPass">BasicBlockPass</a>'s
+ //</i>
+ <b>void</b> AnalysisUsage::setPreservesCFG();
+ </pre><p>
+
+ Some examples of how to use these methods are:<p>
+
+ <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.cs.uiuc.edu/doxygen/structPostDominanceFrontier.html">PostDominanceFrontier</a>::getAnalysisUsage(AnalysisUsage &AU) <b>const</b> {
+ AU.setPreservesAll();
+ AU.addRequired<<a href="http://llvm.cs.uiuc.edu/doxygen/structPostDominatorTree.html">PostDominatorTree</a>>();
+ }
+ </pre><p>
+
+ and:<p>
+
+ <pre>
+ <i>// This example modifies the program, but does not modify the CFG</i>
+ <b>void</b> <a href="http://llvm.cs.uiuc.edu/doxygen/structLICM.html">LICM</a>::getAnalysisUsage(AnalysisUsage &AU) <b>const</b> {
+ AU.setPreservesCFG();
+ AU.addRequired<<a href="http://llvm.cs.uiuc.edu/doxygen/classLoopInfo.html">LoopInfo</a>>();
+ }
+ </pre><p>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="getAnalysis"><hr size=0>The <tt>getAnalysis<></tt> method</h4><ul>
+
+ The <tt>Pass::getAnalysis<></tt> method is 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.<p>
+
+ <pre>
+ <b>template</b><<b>typename</b> PassClass>
+ AnalysisType &getAnalysis();
+ </pre><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.<p>
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="analysisgroup">Implementing Analysis Groups
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ Now that we understand the basics of how passes are defined, how the 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>
+
+ 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="agconcepts"><hr size=0>Analysis Group Concepts</h4><ul>
+
+ 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>
+
+ 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>
+
+ 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>
+
+ As a concrete example of an Analysis Group in action, consider the <a
+ href="http://llvm.cs.uiuc.edu/doxygen/structAliasAnalysis.html">AliasAnalysis</a>
+ analysis group. The default implementation of the alias analysis interface (the
+ <tt><a
+ href="http://llvm.cs.uiuc.edu/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.cs.uiuc.edu/doxygen/structAliasAnalysis.html">AliasAnalysis</a></tt>
+ interface (for example the <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classGCSE.html">gcse</a></tt> pass), do not care which implementation
+ of alias analysis is actually provided, they just use the designated
+ interface.<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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="registerag"><hr size=0>Using <tt>RegisterAnalysisGroup</tt></h4><ul>
+
+ 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>
+
+ <pre>
+ <b>static</b> RegisterAnalysisGroup<<a href="http://llvm.cs.uiuc.edu/doxygen/structAliasAnalysis.html">AliasAnalysis</a>> A("<i>Alias Analysis</i>");
+ </pre><p>
+
+ Once the analysis is registered, passes can declare that they are valid
+ implementations of the interface by using the following code:<p>
+
+ <pre>
+ <b>namespace</b> {
+ //<i> Analysis Group implementations <b>must</b> be registered normally...</i>
+ RegisterOpt<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.cs.uiuc.edu/doxygen/structAliasAnalysis.html">AliasAnalysis</a>, FancyAA> C;
+ }
+ </pre><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.cs.uiuc.edu/doxygen/structAliasAnalysis.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>
+
+ <pre>
+ <b>namespace</b> {
+ //<i> Analysis Group implementations <b>must</b> be registered normally...</i>
+ RegisterOpt<<a href="http://llvm.cs.uiuc.edu/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.cs.uiuc.edu/doxygen/structAliasAnalysis.html">AliasAnalysis</a>, <a href="http://llvm.cs.uiuc.edu/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a>, <b>true</b>> E;
+ }
+ </pre><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. Here we declare that the <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a></tt>
+ pass is the default implementation for the interface.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="passmanager">What PassManager does
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ The <a
+ href="http://llvm.cs.uiuc.edu/doxygen/PassManager_8h-source.html"><tt>PassManager</tt></a>
+ <a href="http://llvm.cs.uiuc.edu/doxygen/classPassManager.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>
+
+ 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.<p>
+
+ <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>'s 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.cs.uiuc.edu/doxygen/structDominatorSet.html"><tt>DominatorSet</tt></a>
+ needs to be calculated at a time. This also makes it possible some <a
+ href="#SMP">interesting enhancements</a> in the future.<p>
+
+ </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>
+
+ 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>
+
+ 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>
+
+ <pre>
+ $ opt -load ../../../lib/Debug/libhello.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
+ Bytecode Writer
+ --Bytecode Writer
+ </pre><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>
+
+ 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>
+
+ Lets see how this changes when we run the <a href="#basiccode">Hello World</a>
+ pass in between the two passes:<p>
+
+ <pre>
+ $ opt -load ../../../lib/Debug/libhello.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
+ Bytecode Writer
+ --Bytecode Writer
+ Hello: __main
+ Hello: puts
+ Hello: main
+ </pre><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>
+
+ <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><p>
+
+ Now when we run our pass, we get this output:<p>
+
+ <pre>
+ $ opt -load ../../../lib/Debug/libhello.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
+ Bytecode Writer
+ --Bytecode Writer
+ Hello: __main
+ Hello: puts
+ Hello: main
+ </pre><p>
+
+ Which shows that we don't accidentally invalidate dominator information
+ anymore, and therefore do not have to compute it twice.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="releaseMemory"><hr size=0>The <tt>releaseMemory</tt> method</h4><ul>
+
+ <pre>
+ <b>virtual void</b> releaseMemory();
+ </pre><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>
+
+ 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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="debughints">Using GDB with dynamically loaded passes
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="breakpoint"><hr size=0>Setting a breakpoint in your pass</h4><ul>
+
+ First thing you do is start <tt>gdb</tt> on the <tt>opt</tt> process:<p>
+
+ <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><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>
+
+ <pre>
+ (gdb) <b>break PassManager::run</b>
+ Breakpoint 1 at 0x2413bc: file Pass.cpp, line 70.
+ (gdb) <b>run test.bc -load /shared/lattner/cvs/llvm/lib/Debug/[libname].so -[passoption]</b>
+ Starting program: /shared/lattner/cvs/llvm/tools/Debug/opt test.bc
+ -load /shared/lattner/cvs/llvm/lib/Debug/[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></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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="debugmisc"><hr size=0>Miscellaneous Problems</h4><ul>
+
+ 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).<p>
+
+ <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>.<p>
+
+ </ul>
+
+ 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>
+
+
+ <!-- *********************************************************************** -->
+ </ul><table width="100%" bgcolor="#330077" border=0 cellpadding=4 cellspacing=0>
+ <tr><td align=center><font color="#EEEEFF" size=+2 face="Georgia,Palatino"><b>
+ <a name="future">Future extensions planned
+ </b></font></td></tr></table><ul>
+ <!-- *********************************************************************** -->
+
+ 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>
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="SMP"><hr size=0>Multithreaded LLVM</h4><ul>
+
+ 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>
+
+ 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>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="ModuleSource"><hr size=0>A new <tt>ModuleSource</tt> interface</h4><ul>
+
+ Currently, the <tt>PassManager</tt>'s <tt>run</tt> method takes a <tt><a
+ href="http://llvm.cs.uiuc.edu/doxygen/classModule.html">Module</a></tt> as
+ input, and runs all of the passes on this module. The problem with this
+ approach is that none of the <tt>PassManager</tt> features can be used for
+ timing and debugging the actual <b>loading</b> of the module from disk or
+ standard input.<p>
+
+ To solve this problem, eventually the <tt>PassManger</tt> class will accept a
+ <tt>ModuleSource</tt> object instead of a Module itself. When complete, this
+ will also allow for streaming of functions out of the bytecode representation,
+ allowing us to avoid holding the entire program in memory at once if we only are
+ dealing with <a href="#FunctionPass">FunctionPass</a>'s.<p>
+
+ As part of a different issue, eventually the bytecode loader will be extended to
+ allow on-demand loading of functions from the bytecode representation, in order
+ to better support the runtime reoptimizer. The bytecode format is already
+ capable of this, the loader just needs to be reworked a bit.<p>
+
+
+ <!-- _______________________________________________________________________ -->
+ </ul><h4><a name="PassFunctionPass"><hr size=0><tt>Pass</tt>'s requiring <tt>FunctionPass</tt>'s</h4><ul>
+
+ Currently it is illegal for a <a href="#Pass"><tt>Pass</tt></a> to require a <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a>. This is because there is only
+ one instance of the <a href="#FunctionPass"><tt>FunctionPass</tt></a> object
+ ever created, thus nowhere to store information for all of the functions in the
+ program at the same time. Although this has come up a couple of times before,
+ this has always been worked around by factoring one big complicated pass into a
+ global and an interprocedural part, both of which are distinct. In the future,
+ it would be nice to have this though.<p>
+
+ Note that it is no problem for a <a
+ href="#FunctionPass"><tt>FunctionPass</tt></a> to require the results of a <a
+ href="#Pass"><tt>Pass</tt></a>, only the other way around.<p>
+
+
+ <!-- *********************************************************************** -->
+ </ul>
+ <!-- *********************************************************************** -->
+
+ <hr><font size-1>
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ <!-- Created: Tue Aug 6 15:00:33 CDT 2002 -->
+ <!-- hhmts start -->
+ Last modified: Tue Jul 22 15:52:30 CDT 2003
+ <!-- hhmts end -->
+ </font></body></html>
Index: llvm-www/releases/1.0/download.html
diff -c /dev/null llvm-www/releases/1.0/download.html:1.1
*** /dev/null Fri Oct 24 15:51:52 2003
--- llvm-www/releases/1.0/download.html Fri Oct 24 15:51:40 2003
***************
*** 0 ****
--- 1,48 ----
+ <html>
+ <title>
+ LLVM Download Page
+ </title>
+
+ <body>
+
+ <center>
+ <h1>
+ LLVM Download Page
+ </h1>
+ </center>
+
+ <hr>
+
+ If you signed up for the LLVM Announcements list, you should receive a
+ confirmation email. If you don't, you can register for the mailing list at
+ <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce">
+ http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce
+ </a>.
+
+ <hr>
+
+ <h3>
+ LLVM 1.0
+ </h3>
+
+ Please read the <a href="1.0/ReleaseNotes.html">Release Notes</a> before
+ downloading:
+ <p>
+
+ <ul>
+ <li>
+ <a href="1.0/llvm.tar.gz">LLVM</a>
+
+ <li>
+ <a href="1.0/cfrontend.x86.tar.gz">GCC Front End Binaries for Linux/x86</a>
+
+ <li>
+ <a href="1.0/cfrontend.sparc.tar.gz">GCC Front End Binaries for Solaris/Sparc</a>
+
+ <li>
+ <a href="1.0/cfrontend-src.tar.gz">GCC Front End Source Code</a>
+ </ul>
+
+ </body>
+ </html>
+
Index: llvm-www/releases/1.0/register.cgi
diff -c /dev/null llvm-www/releases/1.0/register.cgi:1.1
*** /dev/null Fri Oct 24 15:51:52 2003
--- llvm-www/releases/1.0/register.cgi Fri Oct 24 15:51:40 2003
***************
*** 0 ****
--- 1,197 ----
+ #!/usr/dcs/software/supported/bin/python
+
+ import cgi
+ import urllib
+ import smtplib
+ import os
+ import sys
+
+ # List of email addresses that want to know when people download
+ notifylist=['criswell at uiuc.edu', 'jcriswel at bigw.org']
+
+ #
+ # Function: Subscribe()
+ #
+ # Description:
+ # This function subscribes the specified user to the LLVM announce mailing
+ # list.
+ #
+ def Subscribe (form):
+ # Name of the LLVM subscription CGI script
+ scriptURL='http://mail.cs.uiuc.edu/mailman/subscribe/llvm-announce'
+
+ #
+ # Extract from the form any information that we need
+ #
+ email = form.getfirst ('email', '')
+ pw1 = form.getfirst ('pw1', '')
+ pw2 = form.getfirst ('pw2', '')
+ announce = form.getfirst ('announce','yes')
+
+ #
+ # Exit now if we do not need to subscribe.
+ #
+ if (announce != 'yes'):
+ return
+
+ #
+ # Create a POST request with all of the information that the CGI
+ # script will require.
+ #
+ options = {'email': email, 'pw': pw1, 'pw-conf': pw2, 'digest': '0'}
+
+ #
+ # Convert the POST options into a string that we can send to the
+ # subscription CGI script.
+ #
+ postdata = urllib.urlencode (options)
+
+ #
+ # Subscribe the user.
+ #
+ urllib.urlopen (scriptURL, postdata)
+
+ return
+
+ #
+ # Function: ValidateForm ()
+ #
+ # Description:
+ # Make sure that the input to the CGI script is valid.
+ #
+ def ValidateForm (form):
+ #
+ # Verify if the required fields have been supplied.
+ #
+ firstname = form.getfirst ('firstname', '')
+ lastname = form.getfirst ('lastname', '')
+ email = form.getfirst ('email', '')
+ pw1 = form.getfirst ('pw1', '')
+ pw2 = form.getfirst ('pw2', '')
+ announce = form.getfirst ('announce','yes')
+
+ #
+ # Verify that the name and email fields have been filled in.
+ #
+ if (firstname == ''):
+ return 'First name is empty.'
+
+ if (lastname == ''):
+ return 'Last name is empty.'
+
+ if (email == ''):
+ return 'Email address is empty.'
+
+ #
+ # Verify that the email address has an at sign and some periods.
+ #
+ length = len (email) - 1
+ while (length != 0):
+ if (email[length] == '@'):
+ break
+ length=length - 1
+ else:
+ return 'Email address has no at sign'
+
+ length = len (email) - 1
+ while (length != 0):
+ if (email[length] == '.'):
+ break
+ length=length - 1
+ else:
+ return 'Email address has no periods'
+
+ #
+ # Verify that a non-empty password has been selected.
+ #
+ if ((announce == 'yes') and ((pw1 == '') or (pw2 == ''))):
+ return 'Password for mailing address is empty.'
+
+ #
+ # Verify that the passwords are equal.
+ #
+ if (pw1 != pw2):
+ return 'Confirmation password does not match original password.'
+
+ return ''
+
+ #
+ # Function: LogForm ()
+ #
+ # Description:
+ # Append a log record to the logfile that another users has registered to
+ # download LLVM.
+ #
+ def LogForm (form):
+ #
+ # Extract the information from the form that we want.
+ #
+ firstname = form.getfirst ('firstname', '')
+ lastname = form.getfirst ('lastname', '')
+ title = form.getfirst ('title','')
+ organization = form.getfirst ('organization', '')
+ email = form.getfirst ('email','')
+ plans = form.getfirst ('plans','')
+ if (plans == ''):
+ plans = 'No plans.'
+
+ #
+ # Construct an email message describing the user who is downloading
+ # LLVM.
+ #
+ msg = 'Subject: [LLVM DOWNLOAD]\r\n\r\n'
+ msg = msg + 'Name: ' + firstname + ' ' + lastname + '\n'
+ msg = msg + 'Email: ' + email + '\n'
+ msg = msg + 'Title: ' + title + '\n'
+ msg = msg + 'Organization: ' + organization + '\n'
+ msg = msg + 'Plans with LLVM:\n' + plans + '\n'
+
+ #
+ # Send email to notify that someone has downloaded LLVM yet again!
+ #
+ mailer = smtplib.SMTP ('localhost')
+ for receiver in notifylist:
+ header = 'From: ' + email + '\r\nTo: ' + receiver + '\r\n'
+ try:
+ mailer.sendmail (email, receiver, msg)
+ except:
+ pass
+ mailer.quit ()
+ return
+
+ #
+ # Parse the CGI input
+ #
+ form = cgi.FieldStorage ()
+
+ #
+ # Verify that everything in the form is correct.
+ #
+ error = ValidateForm (form)
+ if (error != ''):
+ print ('Content-type: text/html')
+ print ('Status: 400 Bad Request')
+ print ('')
+ print ('<h2>')
+ print ('Error in form:' + error)
+ print ('</h2>')
+ sys.exit (0)
+
+ #
+ # Log the information provided by the form.
+ #
+ LogForm (form)
+
+ #
+ # Subscribe the user the LLVM Announcements list (if they so desire)
+ #
+ Subscribe (form)
+
+ #
+ # Everything so far has worked. Send the user to the download page.
+ #
+ print ('Location: /releases/1.0/download.html')
+ print ('')
+
+ sys.exit (0)
+
Index: llvm-www/releases/1.0/register.html
diff -c /dev/null llvm-www/releases/1.0/register.html:1.1
*** /dev/null Fri Oct 24 15:51:52 2003
--- llvm-www/releases/1.0/register.html Fri Oct 24 15:51:40 2003
***************
*** 0 ****
--- 1,74 ----
+ <html>
+ <title>
+ LLVM Registration Page
+ </title>
+
+ <body>
+
+ <center>
+ <h1>
+ LLVM Registration Page
+ </h1>
+ </center>
+
+ <hr>
+
+ <b>
+ NOTE: This registration page is currently up for testing. If you want to
+ download LLVM, you will have to re-register once we finish the 1.0 Release.
+ <p>
+ If you want to know when the 1.0 Release of LLVM will be ready, you can
+ subscribe to our LLVM Announcements mailing list at
+ <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce">
+ http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce
+ </a>.
+ We will send mail to the list once the 1.0 Release is finished.
+ </b>
+ <hr>
+
+ Welcome to the LLVM registration page! Please complete the following form
+ below to download a copy of the LLVM software.
+ <p>
+
+ <FORM ACTION="/releases/register.cgi" METHOD="POST">
+ First Name (required):<br>
+ <INPUT TYPE="text" SIZE=40 NAME="firstname"><br>
+ <p>
+
+ Last Name (required):<br>
+ <INPUT TYPE="text" SIZE=40 NAME="lastname"><br>
+ <p>
+
+ Email Address (required):<br>
+ <INPUT TYPE="text" SIZE=40 NAME="email"><br>
+ <p>
+
+ Organizational Affiliation:<br>
+ <INPUT TYPE="text" SIZE=40 NAME="organization"><br>
+ <p>
+
+ Position/Title:<br>
+ <INPUT TYPE="text" SIZE=40 NAME="title"><br>
+ <p>
+
+ Subscribe to LLVM Announcements List (default is yes):<br>
+ <INPUT TYPE="radio" NAME="announce" VALUE="yes" CHECKED> Yes<br>
+ <INPUT TYPE="radio" NAME="announce"VALUE="no" > No<br>
+
+ Password for LLVM Announcements List:<br>
+ <INPUT TYPE="password" SIZE=8 NAME="pw1"> Password<br>
+ <INPUT TYPE="password" SIZE=8 NAME="pw2"> Confirm Password<br>
+ <p>
+
+ What plans, if any, do you have for using LLVM:<br>
+ <TEXTAREA ROWS=10 COLS=80 NAME="plans"></TEXTAREA><br>
+ <p>
+
+ <INPUT TYPE="submit" VALUE="Download">
+ <INPUT TYPE="reset" VALUE="Clear Form">
+
+ </FORM>
+
+ </body>
+ </html>
+
Index: llvm-www/releases/1.0/index.html
diff -u llvm-www/releases/1.0/index.html:1.1 llvm-www/releases/1.0/index.html:1.2
--- llvm-www/releases/1.0/index.html:1.1 Wed Oct 1 17:36:17 2003
+++ llvm-www/releases/1.0/index.html Fri Oct 24 15:51:40 2003
@@ -1 +1,265 @@
-<A href="../../">nothing to see here</a>
+<html>
+<title>
+The LLVM Compiler Infrastructure
+</title>
+
+<body>
+
+<center>
+<h1>
+ The LLVM Compiler Infrastructure
+ <br>
+ <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
+</h1>
+</center>
+
+<hr>
+
+<h2>
+Welcome to LLVM!
+</h2>
+This file is intended to do four things:
+<ol>
+ <li>
+ help you get started using LLVM;
+ </li>
+
+ <li>
+ tell you how to get questions about LLVM answered;
+ </li>
+
+ <li>
+ tell you where to find documentation for different kinds of questions; and
+ </li>
+
+ <li>
+ tell you about three LLVM-related mailing lists.
+ </li>
+</ol>
+
+
+<hr>
+
+<h2>
+Getting Started with LLVM
+</h2>
+
+<dl compact>
+ <dt>
+ For license information:
+ <dd>
+ <a href="../LICENSE.TXT">llvm/LICENSE.TXT</a>
+ <p>
+
+ <dt>
+ Installing and compiling LLVM:
+ <dd>
+ <a href="GettingStarted.html">llvm/docs/GettingStarted.html</a>
+ <p>
+
+ <dt>
+ Learn about features and limitations of this release:
+ <dd>
+ <a href="ReleaseNotes.html">llvm/docs/ReleaseNotes.html</a>
+ <p>
+
+ <dt>
+ Learn how to write a pass within the LLVM system:
+ <dd>
+ <a href="WritingAnLLVMPass.html">llvm/docs/WritingAnLLVMPass.html </a>
+ <p>
+
+ <dt>
+ Learn how to start a new development project using LLVM, where your
+ new source code can live anywhere (outside or inside the LLVM tree),
+ while using LLVM header files and libraries:
+ <dd>
+ <a href="Projects.html">llvm/docs/Projects.html</a>
+</dl>
+
+<hr>
+
+<h2>
+Getting Help with LLVM
+</h2>
+
+<ol>
+ <li>
+ If you have questions or development problems not answered in the
+ documentation, send e-mail to llvmdev at cs.uiuc.edu. This mailing list is
+ monitored by all the people in the LLVM group at Illinois, and you
+ should expect prompt first responses.
+ </li>
+
+ <li>
+ To report a bug, submit a bug report as described in the document:
+ <a href="http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html">
+ http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html</a>
+ </li>
+
+ <li>
+ We now use Bugzilla to track bugs, so you can check the status of
+ previous bugs at:
+ <a href="http://llvm.cs.uiuc.edu/bugs/query.cgi">
+ http://llvm.cs.uiuc.edu/bugs/query.cgi </a>
+ </li>
+</ol>
+
+<hr>
+
+<h2>
+LLVM Documentation
+</h2>
+
+All the documents mentioned below except the design overview tech report
+are included as part of the LLVM release (in llvm/docs/*):
+
+<h3>
+LLVM Design Overview:
+</h3>
+
+<dl compact>
+ <dt>
+ LLVM : A Compilation Framework for Lifelong Program Analysis
+ and Transformation:
+ <dd>
+ <a href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">
+ http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html </a>
+
+</dl>
+
+<h3>
+LLVM User Guides:
+</h3>
+
+<dl compact>
+ <dt>
+ Download and Installation Instructions:
+ <dd>
+ <a href="GettingStarted.html"> llvm/docs/GettingStarted.html</a>
+ <p>
+
+ <dt>
+ LLVM Command Guide:
+ <dd>
+ <a href="CommandGuide/index.html">
+ llvm/docs/CommandGuide/index.html</a>
+ <p>
+
+ <dt>
+ LLVM Assembly Language:
+ <dd>
+ <a href="LangRef.html"> llvm/docs/LangRef.html</a>
+ <p>
+
+ <dt>
+ LLVM Test Suite Guide:
+ <dd>
+ <a href="TestingGuide.html"> llvm/docs/TestingGuide.html</a>
+ <p>
+</dl>
+
+<h3>
+LLVM Programming Documentation:
+</h3>
+
+<dl compact>
+ <dt>
+ LLVM Programmers Manual:
+ <dd>
+ <a href="ProgrammersManual.html"> llvm/docs/ProgrammersManual.html</a>
+ <p>
+
+ <dt>
+ Writing an LLVM Pass:
+ <dd>
+ <a href="WritingAnLLVMPass.html"> llvm/docs/WritingAnLLVMPass.html</a>
+ <p>
+
+ <dt>
+ Alias Analysis in LLVM:
+ <dd>
+ <a href="AliasAnalysis.html"> llvm/docs/AliasAnalysis.html</a>
+ <p>
+
+ <dt>
+ Command Line Library:
+ <dd>
+ <a href="CommandLine.html"> llvm/docs/CommandLine.html</a>
+ <p>
+
+ <dt>
+ Coding Standards:
+ <dd>
+ <a href="CodingStandards.html"> llvm/docs/CodingStandards.html</a>
+ <p>
+</dl>
+
+<h3>
+Other LLVM Resources:
+</h3>
+
+<dl compact>
+ <dt>
+ Submitting a Bug:
+ <dd>
+ <a href="http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html">
+ http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html</a>
+ <p>
+
+ <dt>
+ Open Projects:
+ <dd>
+ <a href="OpenProjects.html"> llvm/docs/OpenProjects.html</a>
+ <p>
+
+ <dt>
+ Creating a new LLVM Project:
+ <dd>
+ <a href="Projects.html"> llvm/docs/Projects.html</a>
+ <p>
+</dl>
+
+<hr>
+
+<h2>
+Mailing Lists
+</h2>
+There are three mailing lists for providing LLVM users with information:
+
+<ol>
+ <li> LLVM Announcements List:<br>
+ <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce">
+ http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce</a>
+
+ <p>
+ This is a low volume list that provides important announcements regarding
+ LLVM. It is primarily intended to announce new releases, major updates to
+ the software, etc. This list is highly recommended for anyone that uses
+ LLVM.
+ </p>
+
+ <li> LLVM Developers List:<br>
+ <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev">
+ http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
+
+ <p>
+ 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.
+ </p>
+
+ <li> LLVM Commits List<br>
+ <a href="http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits">
+ http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
+
+ <p>
+ This list contains all commit messages that are made when LLVM developers
+ commit code changes to the CVS archive. It is useful for those who want to
+ stay on the bleeding edge of LLVM development. This list is very high
+ volume.
+ </p>
+</ol>
+</body>
+</html>
+
More information about the llvm-commits
mailing list