[llvm-commits] [www-releases] r157276 [1/5] - in /www-releases/trunk/3.1/docs: ./ CommandGuide/ CommandGuide/html/ CommandGuide/man/ CommandGuide/man/man1/ CommandGuide/ps/ HistoricalNotes/ doxygen/ img/ tutorial/
Tanya Lattner
tonic at nondot.org
Tue May 22 12:32:30 PDT 2012
Author: tbrethou
Date: Tue May 22 14:32:29 2012
New Revision: 157276
URL: http://llvm.org/viewvc/llvm-project?rev=157276&view=rev
Log:
Add release docs
Added:
www-releases/trunk/3.1/docs/
www-releases/trunk/3.1/docs/AliasAnalysis.html
www-releases/trunk/3.1/docs/Atomics.html
www-releases/trunk/3.1/docs/BitCodeFormat.html
www-releases/trunk/3.1/docs/BranchWeightMetadata.html
www-releases/trunk/3.1/docs/Bugpoint.html
www-releases/trunk/3.1/docs/CMake.html
www-releases/trunk/3.1/docs/CodeGenerator.html
www-releases/trunk/3.1/docs/CodingStandards.html
www-releases/trunk/3.1/docs/CommandGuide/
www-releases/trunk/3.1/docs/CommandGuide/FileCheck.pod
www-releases/trunk/3.1/docs/CommandGuide/Makefile
www-releases/trunk/3.1/docs/CommandGuide/bugpoint.pod
www-releases/trunk/3.1/docs/CommandGuide/html/
www-releases/trunk/3.1/docs/CommandGuide/html/FileCheck.html
www-releases/trunk/3.1/docs/CommandGuide/html/bugpoint.html
www-releases/trunk/3.1/docs/CommandGuide/html/lit.html
www-releases/trunk/3.1/docs/CommandGuide/html/llc.html
www-releases/trunk/3.1/docs/CommandGuide/html/lli.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ar.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-as.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-bcanalyzer.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-build.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-config.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-cov.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-diff.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-dis.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-extract.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ld.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-link.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-nm.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-prof.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ranlib.html
www-releases/trunk/3.1/docs/CommandGuide/html/llvm-stress.html
www-releases/trunk/3.1/docs/CommandGuide/html/manpage.css
www-releases/trunk/3.1/docs/CommandGuide/html/opt.html
www-releases/trunk/3.1/docs/CommandGuide/html/tblgen.html
www-releases/trunk/3.1/docs/CommandGuide/index.html
www-releases/trunk/3.1/docs/CommandGuide/lit.pod
www-releases/trunk/3.1/docs/CommandGuide/llc.pod
www-releases/trunk/3.1/docs/CommandGuide/lli.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-ar.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-as.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-bcanalyzer.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-build.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-config.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-cov.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-diff.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-dis.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-extract.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-ld.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-link.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-nm.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-prof.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-ranlib.pod
www-releases/trunk/3.1/docs/CommandGuide/llvm-stress.pod
www-releases/trunk/3.1/docs/CommandGuide/man/
www-releases/trunk/3.1/docs/CommandGuide/man/man1/
www-releases/trunk/3.1/docs/CommandGuide/man/man1/FileCheck.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/bugpoint.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/lit.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llc.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/lli.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ar.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-as.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-bcanalyzer.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-build.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-config.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-cov.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-diff.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-dis.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-extract.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ld.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-link.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-nm.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-prof.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ranlib.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-stress.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/opt.1
www-releases/trunk/3.1/docs/CommandGuide/man/man1/tblgen.1
www-releases/trunk/3.1/docs/CommandGuide/manpage.css
www-releases/trunk/3.1/docs/CommandGuide/opt.pod
www-releases/trunk/3.1/docs/CommandGuide/pod2htmd.tmp
www-releases/trunk/3.1/docs/CommandGuide/pod2htmi.tmp
www-releases/trunk/3.1/docs/CommandGuide/ps/
www-releases/trunk/3.1/docs/CommandGuide/ps/FileCheck.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/bugpoint.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/lit.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llc.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/lli.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-ar.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-as.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-bcanalyzer.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-build.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-config.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-cov.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-diff.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-dis.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-extract.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-ld.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-link.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-nm.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-prof.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-ranlib.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/llvm-stress.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/opt.ps
www-releases/trunk/3.1/docs/CommandGuide/ps/tblgen.ps
www-releases/trunk/3.1/docs/CommandGuide/tblgen.pod
www-releases/trunk/3.1/docs/CommandLine.html
www-releases/trunk/3.1/docs/CompilerWriterInfo.html
www-releases/trunk/3.1/docs/DebuggingJITedCode.html
www-releases/trunk/3.1/docs/DeveloperPolicy.html
www-releases/trunk/3.1/docs/ExceptionHandling.html
www-releases/trunk/3.1/docs/ExtendedIntegerResults.txt
www-releases/trunk/3.1/docs/ExtendingLLVM.html
www-releases/trunk/3.1/docs/FAQ.html
www-releases/trunk/3.1/docs/GCCFEBuildInstrs.html
www-releases/trunk/3.1/docs/GarbageCollection.html
www-releases/trunk/3.1/docs/GetElementPtr.html
www-releases/trunk/3.1/docs/GettingStarted.html
www-releases/trunk/3.1/docs/GettingStartedVS.html
www-releases/trunk/3.1/docs/GoldPlugin.html
www-releases/trunk/3.1/docs/HistoricalNotes/
www-releases/trunk/3.1/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeas.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2000-12-06-EncodingIdea.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-01-31-UniversalIRIdea.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-06-TypeNotationDebate.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp1.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp2.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-09-AdveComments.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-13-Reference-Memory.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-02-13-Reference-MemoryResponse.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-04-16-DynamicCompilation.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-05-18-ExceptionHandling.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-05-19-ExceptionResponse.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-06-01-GCCOptimizations.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-06-20-.NET-Differences.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-07-06-LoweringIRForCodeGen.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2001-09-18-OptimizeExceptions.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2002-05-12-InstListChange.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2002-06-25-MegaPatchInfo.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2003-01-23-CygwinNotes.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2003-06-25-Reoptimizer1.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2003-06-26-Reoptimizer2.txt
www-releases/trunk/3.1/docs/HistoricalNotes/2007-OriginalClangReadme.txt
www-releases/trunk/3.1/docs/HowToAddABuilder.html
www-releases/trunk/3.1/docs/HowToReleaseLLVM.html
www-releases/trunk/3.1/docs/HowToSubmitABug.html
www-releases/trunk/3.1/docs/LLVMBuild.html
www-releases/trunk/3.1/docs/LLVMBuild.txt
www-releases/trunk/3.1/docs/LangRef.html
www-releases/trunk/3.1/docs/Lexicon.html
www-releases/trunk/3.1/docs/LinkTimeOptimization.html
www-releases/trunk/3.1/docs/Makefile
www-releases/trunk/3.1/docs/MakefileGuide.html
www-releases/trunk/3.1/docs/Packaging.html
www-releases/trunk/3.1/docs/Passes.html
www-releases/trunk/3.1/docs/ProgrammersManual.html
www-releases/trunk/3.1/docs/Projects.html
www-releases/trunk/3.1/docs/ReleaseNotes.html
www-releases/trunk/3.1/docs/SegmentedStacks.html
www-releases/trunk/3.1/docs/SourceLevelDebugging.html
www-releases/trunk/3.1/docs/SystemLibrary.html
www-releases/trunk/3.1/docs/TableGenFundamentals.html
www-releases/trunk/3.1/docs/TestSuiteMakefileGuide.html
www-releases/trunk/3.1/docs/TestingGuide.html
www-releases/trunk/3.1/docs/WritingAnLLVMBackend.html
www-releases/trunk/3.1/docs/WritingAnLLVMPass.html
www-releases/trunk/3.1/docs/doxygen/
www-releases/trunk/3.1/docs/doxygen.cfg
www-releases/trunk/3.1/docs/doxygen.cfg.in
www-releases/trunk/3.1/docs/doxygen.css
www-releases/trunk/3.1/docs/doxygen.footer
www-releases/trunk/3.1/docs/doxygen.header
www-releases/trunk/3.1/docs/doxygen.intro
www-releases/trunk/3.1/docs/doxygen.tar.gz (with props)
www-releases/trunk/3.1/docs/img/
www-releases/trunk/3.1/docs/img/Debugging.gif (with props)
www-releases/trunk/3.1/docs/img/libdeps.gif (with props)
www-releases/trunk/3.1/docs/img/lines.gif (with props)
www-releases/trunk/3.1/docs/img/objdeps.gif (with props)
www-releases/trunk/3.1/docs/img/venusflytrap.jpg (with props)
www-releases/trunk/3.1/docs/index.html
www-releases/trunk/3.1/docs/llvm.css
www-releases/trunk/3.1/docs/re_format.7
www-releases/trunk/3.1/docs/tutorial/
www-releases/trunk/3.1/docs/tutorial/LangImpl1.html
www-releases/trunk/3.1/docs/tutorial/LangImpl2.html
www-releases/trunk/3.1/docs/tutorial/LangImpl3.html
www-releases/trunk/3.1/docs/tutorial/LangImpl4.html
www-releases/trunk/3.1/docs/tutorial/LangImpl5-cfg.png (with props)
www-releases/trunk/3.1/docs/tutorial/LangImpl5.html
www-releases/trunk/3.1/docs/tutorial/LangImpl6.html
www-releases/trunk/3.1/docs/tutorial/LangImpl7.html
www-releases/trunk/3.1/docs/tutorial/LangImpl8.html
www-releases/trunk/3.1/docs/tutorial/Makefile
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl1.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl2.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl3.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl4.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl5.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl6.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl7.html
www-releases/trunk/3.1/docs/tutorial/OCamlLangImpl8.html
www-releases/trunk/3.1/docs/tutorial/index.html
Added: www-releases/trunk/3.1/docs/AliasAnalysis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/AliasAnalysis.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/AliasAnalysis.html (added)
+++ www-releases/trunk/3.1/docs/AliasAnalysis.html Tue May 22 14:32:29 2012
@@ -0,0 +1,1067 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>LLVM Alias Analysis Infrastructure</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+<body>
+
+<h1>
+ LLVM Alias Analysis Infrastructure
+</h1>
+
+<ol>
+ <li><a href="#introduction">Introduction</a></li>
+
+ <li><a href="#overview"><tt>AliasAnalysis</tt> Class Overview</a>
+ <ul>
+ <li><a href="#pointers">Representation of Pointers</a></li>
+ <li><a href="#alias">The <tt>alias</tt> method</a></li>
+ <li><a href="#ModRefInfo">The <tt>getModRefInfo</tt> methods</a></li>
+ <li><a href="#OtherItfs">Other useful <tt>AliasAnalysis</tt> methods</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a>
+ <ul>
+ <li><a href="#passsubclasses">Different Pass styles</a></li>
+ <li><a href="#requiredcalls">Required initialization calls</a></li>
+ <li><a href="#interfaces">Interfaces which may be specified</a></li>
+ <li><a href="#chaining"><tt>AliasAnalysis</tt> chaining behavior</a></li>
+ <li><a href="#updating">Updating analysis results for transformations</a></li>
+ <li><a href="#implefficiency">Efficiency Issues</a></li>
+ <li><a href="#limitations">Limitations</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#using">Using alias analysis results</a>
+ <ul>
+ <li><a href="#memdep">Using the <tt>MemoryDependenceAnalysis</tt> Pass</a></li>
+ <li><a href="#ast">Using the <tt>AliasSetTracker</tt> class</a></li>
+ <li><a href="#direct">Using the <tt>AliasAnalysis</tt> interface directly</a></li>
+ </ul>
+ </li>
+
+ <li><a href="#exist">Existing alias analysis implementations and clients</a>
+ <ul>
+ <li><a href="#impls">Available <tt>AliasAnalysis</tt> implementations</a></li>
+ <li><a href="#aliasanalysis-xforms">Alias analysis driven transformations</a></li>
+ <li><a href="#aliasanalysis-debug">Clients for debugging and evaluation of
+ implementations</a></li>
+ </ul>
+ </li>
+ <li><a href="#memdep">Memory Dependence Analysis</a></li>
+</ol>
+
+<div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="introduction">Introduction</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt
+to determine whether or not two pointers ever can point to the same object in
+memory. There are many different algorithms for alias analysis and many
+different ways of classifying them: flow-sensitive vs flow-insensitive,
+context-sensitive vs context-insensitive, field-sensitive vs field-insensitive,
+unification-based vs subset-based, etc. Traditionally, alias analyses respond
+to a query with a <a href="#MustMayNo">Must, May, or No</a> alias response,
+indicating that two pointers always point to the same object, might point to the
+same object, or are known to never point to the same object.</p>
+
+<p>The LLVM <a
+href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
+class is the primary interface used by clients and implementations of alias
+analyses in the LLVM system. This class is the common interface between clients
+of alias analysis information and the implementations providing it, and is
+designed to support a wide range of implementations and clients (but currently
+all clients are assumed to be flow-insensitive). In addition to simple alias
+analysis information, this class exposes Mod/Ref information from those
+implementations which can provide it, allowing for powerful analyses and
+transformations to work well together.</p>
+
+<p>This document contains information necessary to successfully implement this
+interface, use it, and to test both sides. It also explains some of the finer
+points about what exactly results mean. If you feel that something is unclear
+or should be added, please <a href="mailto:sabre at nondot.org">let me
+know</a>.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="overview"><tt>AliasAnalysis</tt> Class Overview</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>The <a
+href="http://llvm.org/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
+class defines the interface that the various alias analysis implementations
+should support. This class exports two important enums: <tt>AliasResult</tt>
+and <tt>ModRefResult</tt> which represent the result of an alias query or a
+mod/ref query, respectively.</p>
+
+<p>The <tt>AliasAnalysis</tt> interface exposes information about memory,
+represented in several different ways. In particular, memory objects are
+represented as a starting address and size, and function calls are represented
+as the actual <tt>call</tt> or <tt>invoke</tt> instructions that performs the
+call. The <tt>AliasAnalysis</tt> interface also exposes some helper methods
+which allow you to get mod/ref information for arbitrary instructions.</p>
+
+<p>All <tt>AliasAnalysis</tt> interfaces require that in queries involving
+multiple values, values which are not
+<a href="LangRef.html#constants">constants</a> are all defined within the
+same function.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="pointers">Representation of Pointers</a>
+</h3>
+
+<div>
+
+<p>Most importantly, the <tt>AliasAnalysis</tt> class provides several methods
+which are used to query whether or not two memory objects alias, whether
+function calls can modify or read a memory object, etc. For all of these
+queries, memory objects are represented as a pair of their starting address (a
+symbolic LLVM <tt>Value*</tt>) and a static size.</p>
+
+<p>Representing memory objects as a starting address and a size is critically
+important for correct Alias Analyses. For example, consider this (silly, but
+possible) C code:</p>
+
+<div class="doc_code">
+<pre>
+int i;
+char C[2];
+char A[10];
+/* ... */
+for (i = 0; i != 10; ++i) {
+ C[0] = A[i]; /* One byte store */
+ C[1] = A[9-i]; /* One byte store */
+}
+</pre>
+</div>
+
+<p>In this case, the <tt>basicaa</tt> pass will disambiguate the stores to
+<tt>C[0]</tt> and <tt>C[1]</tt> because they are accesses to two distinct
+locations one byte apart, and the accesses are each one byte. In this case, the
+LICM pass can use store motion to remove the stores from the loop. In
+constrast, the following code:</p>
+
+<div class="doc_code">
+<pre>
+int i;
+char C[2];
+char A[10];
+/* ... */
+for (i = 0; i != 10; ++i) {
+ ((short*)C)[0] = A[i]; /* Two byte store! */
+ C[1] = A[9-i]; /* One byte store */
+}
+</pre>
+</div>
+
+<p>In this case, the two stores to C do alias each other, because the access to
+the <tt>&C[0]</tt> element is a two byte access. If size information wasn't
+available in the query, even the first case would have to conservatively assume
+that the accesses alias.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="alias">The <tt>alias</tt> method</a>
+</h3>
+
+<div>
+<p>The <tt>alias</tt> method is the primary interface used to determine whether
+or not two memory objects alias each other. It takes two memory objects as
+input and returns MustAlias, PartialAlias, MayAlias, or NoAlias as
+appropriate.</p>
+
+<p>Like all <tt>AliasAnalysis</tt> interfaces, the <tt>alias</tt> method requires
+that either the two pointer values be defined within the same function, or at
+least one of the values is a <a href="LangRef.html#constants">constant</a>.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="MustMayNo">Must, May, and No Alias Responses</a>
+</h4>
+
+<div>
+<p>The NoAlias response may be used when there is never an immediate dependence
+between any memory reference <i>based</i> on one pointer and any memory
+reference <i>based</i> the other. The most obvious example is when the two
+pointers point to non-overlapping memory ranges. Another is when the two
+pointers are only ever used for reading memory. Another is when the memory is
+freed and reallocated between accesses through one pointer and accesses through
+the other -- in this case, there is a dependence, but it's mediated by the free
+and reallocation.</p>
+
+<p>As an exception to this is with the
+<a href="LangRef.html#noalias"><tt>noalias</tt></a> keyword; the "irrelevant"
+dependencies are ignored.</p>
+
+<p>The MayAlias response is used whenever the two pointers might refer to the
+same object.</p>
+
+<p>The PartialAlias response is used when the two memory objects are known
+to be overlapping in some way, but do not start at the same address.</p>
+
+<p>The MustAlias response may only be returned if the two memory objects are
+guaranteed to always start at exactly the same location. A MustAlias response
+implies that the pointers compare equal.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="ModRefInfo">The <tt>getModRefInfo</tt> methods</a>
+</h3>
+
+<div>
+
+<p>The <tt>getModRefInfo</tt> methods return information about whether the
+execution of an instruction can read or modify a memory location. Mod/Ref
+information is always conservative: if an instruction <b>might</b> read or write
+a location, ModRef is returned.</p>
+
+<p>The <tt>AliasAnalysis</tt> class also provides a <tt>getModRefInfo</tt>
+method for testing dependencies between function calls. This method takes two
+call sites (CS1 & CS2), returns NoModRef if neither call writes to memory
+read or written by the other, Ref if CS1 reads memory written by CS2, Mod if CS1
+writes to memory read or written by CS2, or ModRef if CS1 might read or write
+memory written to by CS2. Note that this relation is not commutative.</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="OtherItfs">Other useful <tt>AliasAnalysis</tt> methods</a>
+</h3>
+
+<div>
+
+<p>
+Several other tidbits of information are often collected by various alias
+analysis implementations and can be put to good use by various clients.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ The <tt>pointsToConstantMemory</tt> method
+</h4>
+
+<div>
+
+<p>The <tt>pointsToConstantMemory</tt> method returns true if and only if the
+analysis can prove that the pointer only points to unchanging memory locations
+(functions, constant global variables, and the null pointer). This information
+can be used to refine mod/ref information: it is impossible for an unchanging
+memory location to be modified.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="simplemodref">The <tt>doesNotAccessMemory</tt> and
+ <tt>onlyReadsMemory</tt> methods</a>
+</h4>
+
+<div>
+
+<p>These methods are used to provide very simple mod/ref information for
+function calls. The <tt>doesNotAccessMemory</tt> method returns true for a
+function if the analysis can prove that the function never reads or writes to
+memory, or if the function only reads from constant memory. Functions with this
+property are side-effect free and only depend on their input arguments, allowing
+them to be eliminated if they form common subexpressions or be hoisted out of
+loops. Many common functions behave this way (e.g., <tt>sin</tt> and
+<tt>cos</tt>) but many others do not (e.g., <tt>acos</tt>, which modifies the
+<tt>errno</tt> variable).</p>
+
+<p>The <tt>onlyReadsMemory</tt> method returns true for a function if analysis
+can prove that (at most) the function only reads from non-volatile memory.
+Functions with this property are side-effect free, only depending on their input
+arguments and the state of memory when they are called. This property allows
+calls to these functions to be eliminated and moved around, as long as there is
+no store instruction that changes the contents of memory. Note that all
+functions that satisfy the <tt>doesNotAccessMemory</tt> method also satisfies
+<tt>onlyReadsMemory</tt>.</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="writingnew">Writing a new <tt>AliasAnalysis</tt> Implementation</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Writing a new alias analysis implementation for LLVM is quite
+straight-forward. There are already several implementations that you can use
+for examples, and the following information should help fill in any details.
+For a examples, take a look at the <a href="#impls">various alias analysis
+implementations</a> included with LLVM.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="passsubclasses">Different Pass styles</a>
+</h3>
+
+<div>
+
+<p>The first step to determining what type of <a
+href="WritingAnLLVMPass.html">LLVM pass</a> you need to use for your Alias
+Analysis. As is the case with most other analyses and transformations, the
+answer should be fairly obvious from what type of problem you are trying to
+solve:</p>
+
+<ol>
+ <li>If you require interprocedural analysis, it should be a
+ <tt>Pass</tt>.</li>
+ <li>If you are a function-local analysis, subclass <tt>FunctionPass</tt>.</li>
+ <li>If you don't need to look at the program at all, subclass
+ <tt>ImmutablePass</tt>.</li>
+</ol>
+
+<p>In addition to the pass that you subclass, you should also inherit from the
+<tt>AliasAnalysis</tt> interface, of course, and use the
+<tt>RegisterAnalysisGroup</tt> template to register as an implementation of
+<tt>AliasAnalysis</tt>.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="requiredcalls">Required initialization calls</a>
+</h3>
+
+<div>
+
+<p>Your subclass of <tt>AliasAnalysis</tt> is required to invoke two methods on
+the <tt>AliasAnalysis</tt> base class: <tt>getAnalysisUsage</tt> and
+<tt>InitializeAliasAnalysis</tt>. In particular, your implementation of
+<tt>getAnalysisUsage</tt> should explicitly call into the
+<tt>AliasAnalysis::getAnalysisUsage</tt> method in addition to doing any
+declaring any pass dependencies your pass has. Thus you should have something
+like this:</p>
+
+<div class="doc_code">
+<pre>
+void getAnalysisUsage(AnalysisUsage &AU) const {
+ AliasAnalysis::getAnalysisUsage(AU);
+ <i>// declare your dependencies here.</i>
+}
+</pre>
+</div>
+
+<p>Additionally, your must invoke the <tt>InitializeAliasAnalysis</tt> method
+from your analysis run method (<tt>run</tt> for a <tt>Pass</tt>,
+<tt>runOnFunction</tt> for a <tt>FunctionPass</tt>, or <tt>InitializePass</tt>
+for an <tt>ImmutablePass</tt>). For example (as part of a <tt>Pass</tt>):</p>
+
+<div class="doc_code">
+<pre>
+bool run(Module &M) {
+ InitializeAliasAnalysis(this);
+ <i>// Perform analysis here...</i>
+ return false;
+}
+</pre>
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="interfaces">Interfaces which may be specified</a>
+</h3>
+
+<div>
+
+<p>All of the <a
+href="/doxygen/classllvm_1_1AliasAnalysis.html"><tt>AliasAnalysis</tt></a>
+virtual methods default to providing <a href="#chaining">chaining</a> to another
+alias analysis implementation, which ends up returning conservatively correct
+information (returning "May" Alias and "Mod/Ref" for alias and mod/ref queries
+respectively). Depending on the capabilities of the analysis you are
+implementing, you just override the interfaces you can improve.</p>
+
+</div>
+
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="chaining"><tt>AliasAnalysis</tt> chaining behavior</a>
+</h3>
+
+<div>
+
+<p>With only one special exception (the <a href="#no-aa"><tt>no-aa</tt></a>
+pass) every alias analysis pass chains to another alias analysis
+implementation (for example, the user can specify "<tt>-basicaa -ds-aa
+-licm</tt>" to get the maximum benefit from both alias
+analyses). The alias analysis class automatically takes care of most of this
+for methods that you don't override. For methods that you do override, in code
+paths that return a conservative MayAlias or Mod/Ref result, simply return
+whatever the superclass computes. For example:</p>
+
+<div class="doc_code">
+<pre>
+AliasAnalysis::AliasResult alias(const Value *V1, unsigned V1Size,
+ const Value *V2, unsigned V2Size) {
+ if (...)
+ return NoAlias;
+ ...
+
+ <i>// Couldn't determine a must or no-alias result.</i>
+ return AliasAnalysis::alias(V1, V1Size, V2, V2Size);
+}
+</pre>
+</div>
+
+<p>In addition to analysis queries, you must make sure to unconditionally pass
+LLVM <a href="#updating">update notification</a> methods to the superclass as
+well if you override them, which allows all alias analyses in a change to be
+updated.</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="updating">Updating analysis results for transformations</a>
+</h3>
+
+<div>
+<p>
+Alias analysis information is initially computed for a static snapshot of the
+program, but clients will use this information to make transformations to the
+code. All but the most trivial forms of alias analysis will need to have their
+analysis results updated to reflect the changes made by these transformations.
+</p>
+
+<p>
+The <tt>AliasAnalysis</tt> interface exposes four methods which are used to
+communicate program changes from the clients to the analysis implementations.
+Various alias analysis implementations should use these methods to ensure that
+their internal data structures are kept up-to-date as the program changes (for
+example, when an instruction is deleted), and clients of alias analysis must be
+sure to call these interfaces appropriately.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>The <tt>deleteValue</tt> method</h4>
+
+<div>
+The <tt>deleteValue</tt> method is called by transformations when they remove an
+instruction or any other value from the program (including values that do not
+use pointers). Typically alias analyses keep data structures that have entries
+for each value in the program. When this method is called, they should remove
+any entries for the specified value, if they exist.
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>The <tt>copyValue</tt> method</h4>
+
+<div>
+The <tt>copyValue</tt> method is used when a new value is introduced into the
+program. There is no way to introduce a value into the program that did not
+exist before (this doesn't make sense for a safe compiler transformation), so
+this is the only way to introduce a new value. This method indicates that the
+new value has exactly the same properties as the value being copied.
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>The <tt>replaceWithNewValue</tt> method</h4>
+
+<div>
+This method is a simple helper method that is provided to make clients easier to
+use. It is implemented by copying the old analysis information to the new
+value, then deleting the old value. This method cannot be overridden by alias
+analysis implementations.
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>The <tt>addEscapingUse</tt> method</h4>
+
+<div>
+<p>The <tt>addEscapingUse</tt> method is used when the uses of a pointer
+value have changed in ways that may invalidate precomputed analysis information.
+Implementations may either use this callback to provide conservative responses
+for points whose uses have change since analysis time, or may recompute some
+or all of their internal state to continue providing accurate responses.</p>
+
+<p>In general, any new use of a pointer value is considered an escaping use,
+and must be reported through this callback, <em>except</em> for the
+uses below:</p>
+
+<ul>
+ <li>A <tt>bitcast</tt> or <tt>getelementptr</tt> of the pointer</li>
+ <li>A <tt>store</tt> through the pointer (but not a <tt>store</tt>
+ <em>of</em> the pointer)</li>
+ <li>A <tt>load</tt> through the pointer</li>
+</ul>
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="implefficiency">Efficiency Issues</a>
+</h3>
+
+<div>
+
+<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>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="limitations">Limitations</a>
+</h3>
+
+<div>
+
+<p>The AliasAnalysis infrastructure has several limitations which make
+writing a new <tt>AliasAnalysis</tt> implementation difficult.</p>
+
+<p>There is no way to override the default alias analysis. It would
+be very useful to be able to do something like "opt -my-aa -O2" and
+have it use -my-aa for all passes which need AliasAnalysis, but there
+is currently no support for that, short of changing the source code
+and recompiling. Similarly, there is also no way of setting a chain
+of analyses as the default.</p>
+
+<p>There is no way for transform passes to declare that they preserve
+<tt>AliasAnalysis</tt> implementations. The <tt>AliasAnalysis</tt>
+interface includes <tt>deleteValue</tt> and <tt>copyValue</tt> methods
+which are intended to allow a pass to keep an AliasAnalysis consistent,
+however there's no way for a pass to declare in its
+<tt>getAnalysisUsage</tt> that it does so. Some passes attempt to use
+<tt>AU.addPreserved<AliasAnalysis></tt>, however this doesn't
+actually have any effect.</p>
+
+<p><tt>AliasAnalysisCounter</tt> (<tt>-count-aa</tt>) and <tt>AliasDebugger</tt>
+(<tt>-debug-aa</tt>) are implemented as <tt>ModulePass</tt> classes, so if your
+alias analysis uses <tt>FunctionPass</tt>, it won't be able to use
+these utilities. If you try to use them, the pass manager will
+silently route alias analysis queries directly to
+<tt>BasicAliasAnalysis</tt> instead.</p>
+
+<p>Similarly, the <tt>opt -p</tt> option introduces <tt>ModulePass</tt>
+passes between each pass, which prevents the use of <tt>FunctionPass</tt>
+alias analysis passes.</p>
+
+<p>The <tt>AliasAnalysis</tt> API does have functions for notifying
+implementations when values are deleted or copied, however these
+aren't sufficient. There are many other ways that LLVM IR can be
+modified which could be relevant to <tt>AliasAnalysis</tt>
+implementations which can not be expressed.</p>
+
+<p>The <tt>AliasAnalysisDebugger</tt> utility seems to suggest that
+<tt>AliasAnalysis</tt> implementations can expect that they will be
+informed of any relevant <tt>Value</tt> before it appears in an
+alias query. However, popular clients such as <tt>GVN</tt> don't
+support this, and are known to trigger errors when run with the
+<tt>AliasAnalysisDebugger</tt>.</p>
+
+<p>Due to several of the above limitations, the most obvious use for
+the <tt>AliasAnalysisCounter</tt> utility, collecting stats on all
+alias queries in a compilation, doesn't work, even if the
+<tt>AliasAnalysis</tt> implementations don't use <tt>FunctionPass</tt>.
+There's no way to set a default, much less a default sequence,
+and there's no way to preserve it.</p>
+
+<p>The <tt>AliasSetTracker</tt> class (which is used by <tt>LICM</tt>
+makes a non-deterministic number of alias queries. This can cause stats
+collected by <tt>AliasAnalysisCounter</tt> to have fluctuations among
+identical runs, for example. Another consequence is that debugging
+techniques involving pausing execution after a predetermined number
+of queries can be unreliable.</p>
+
+<p>Many alias queries can be reformulated in terms of other alias
+queries. When multiple <tt>AliasAnalysis</tt> queries are chained together,
+it would make sense to start those queries from the beginning of the chain,
+with care taken to avoid infinite looping, however currently an
+implementation which wants to do this can only start such queries
+from itself.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="using">Using alias analysis results</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>There are several different ways to use alias analysis results. In order of
+preference, these are...</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="memdep">Using the <tt>MemoryDependenceAnalysis</tt> Pass</a>
+</h3>
+
+<div>
+
+<p>The <tt>memdep</tt> pass uses alias analysis to provide high-level dependence
+information about memory-using instructions. This will tell you which store
+feeds into a load, for example. It uses caching and other techniques to be
+efficient, and is used by Dead Store Elimination, GVN, and memcpy optimizations.
+</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="ast">Using the <tt>AliasSetTracker</tt> class</a>
+</h3>
+
+<div>
+
+<p>Many transformations need information about alias <b>sets</b> that are active
+in some scope, rather than information about pairwise aliasing. The <tt><a
+href="/doxygen/classllvm_1_1AliasSetTracker.html">AliasSetTracker</a></tt> class
+is used to efficiently build these Alias Sets from the pairwise alias analysis
+information provided by the <tt>AliasAnalysis</tt> interface.</p>
+
+<p>First you initialize the AliasSetTracker by using the "<tt>add</tt>" methods
+to add information about various potentially aliasing instructions in the scope
+you are interested in. Once all of the alias sets are completed, your pass
+should simply iterate through the constructed alias sets, using the
+<tt>AliasSetTracker</tt> <tt>begin()</tt>/<tt>end()</tt> methods.</p>
+
+<p>The <tt>AliasSet</tt>s formed by the <tt>AliasSetTracker</tt> are guaranteed
+to be disjoint, calculate mod/ref information and volatility for the set, and
+keep track of whether or not all of the pointers in the set are Must aliases.
+The AliasSetTracker also makes sure that sets are properly folded due to call
+instructions, and can provide a list of pointers in each set.</p>
+
+<p>As an example user of this, the <a href="/doxygen/structLICM.html">Loop
+Invariant Code Motion</a> pass uses <tt>AliasSetTracker</tt>s to calculate alias
+sets for each loop nest. If an <tt>AliasSet</tt> in a loop is not modified,
+then all load instructions from that set may be hoisted out of the loop. If any
+alias sets are stored to <b>and</b> are must alias sets, then the stores may be
+sunk to outside of the loop, promoting the memory location to a register for the
+duration of the loop nest. Both of these transformations only apply if the
+pointer argument is loop-invariant.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ The AliasSetTracker implementation
+</h4>
+
+<div>
+
+<p>The AliasSetTracker class is implemented to be as efficient as possible. It
+uses the union-find algorithm to efficiently merge AliasSets when a pointer is
+inserted into the AliasSetTracker that aliases multiple sets. The primary data
+structure is a hash table mapping pointers to the AliasSet they are in.</p>
+
+<p>The AliasSetTracker class must maintain a list of all of the LLVM Value*'s
+that are in each AliasSet. Since the hash table already has entries for each
+LLVM Value* of interest, the AliasesSets thread the linked list through these
+hash-table nodes to avoid having to allocate memory unnecessarily, and to make
+merging alias sets extremely efficient (the linked list merge is constant time).
+</p>
+
+<p>You shouldn't need to understand these details if you are just a client of
+the AliasSetTracker, but if you look at the code, hopefully this brief
+description will help make sense of why things are designed the way they
+are.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="direct">Using the <tt>AliasAnalysis</tt> interface directly</a>
+</h3>
+
+<div>
+
+<p>If neither of these utility class are what your pass needs, you should use
+the interfaces exposed by the <tt>AliasAnalysis</tt> class directly. Try to use
+the higher-level methods when possible (e.g., use mod/ref information instead of
+the <a href="#alias"><tt>alias</tt></a> method directly if possible) to get the
+best precision and efficiency.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="exist">Existing alias analysis implementations and clients</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>If you're going to be working with the LLVM alias analysis infrastructure,
+you should know what clients and implementations of alias analysis are
+available. In particular, if you are implementing an alias analysis, you should
+be aware of the <a href="#aliasanalysis-debug">the clients</a> that are useful
+for monitoring and evaluating different implementations.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="impls">Available <tt>AliasAnalysis</tt> implementations</a>
+</h3>
+
+<div>
+
+<p>This section lists the various implementations of the <tt>AliasAnalysis</tt>
+interface. With the exception of the <a href="#no-aa"><tt>-no-aa</tt></a>
+implementation, all of these <a href="#chaining">chain</a> to other alias
+analysis implementations.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="no-aa">The <tt>-no-aa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-no-aa</tt> pass is just like what it sounds: an alias analysis that
+never returns any useful information. This pass can be useful if you think that
+alias analysis is doing something wrong and are trying to narrow down a
+problem.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="basic-aa">The <tt>-basicaa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-basicaa</tt> pass is an aggressive local analysis that "knows"
+many important facts:</p>
+
+<ul>
+<li>Distinct globals, stack allocations, and heap allocations can never
+ alias.</li>
+<li>Globals, stack allocations, and heap allocations never alias the null
+ pointer.</li>
+<li>Different fields of a structure do not alias.</li>
+<li>Indexes into arrays with statically differing subscripts cannot alias.</li>
+<li>Many common standard C library functions <a
+ href="#simplemodref">never access memory or only read memory</a>.</li>
+<li>Pointers that obviously point to constant globals
+ "<tt>pointToConstantMemory</tt>".</li>
+<li>Function calls can not modify or references stack allocations if they never
+ escape from the function that allocates them (a common case for automatic
+ arrays).</li>
+</ul>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="globalsmodref">The <tt>-globalsmodref-aa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>This pass implements a simple context-sensitive mod/ref and alias analysis
+for internal global variables that don't "have their address taken". If a
+global does not have its address taken, the pass knows that no pointers alias
+the global. This pass also keeps track of functions that it knows never access
+memory or never read memory. This allows certain optimizations (e.g. GVN) to
+eliminate call instructions entirely.
+</p>
+
+<p>The real power of this pass is that it provides context-sensitive mod/ref
+information for call instructions. This allows the optimizer to know that
+calls to a function do not clobber or read the value of the global, allowing
+loads and stores to be eliminated.</p>
+
+<p>Note that this pass is somewhat limited in its scope (only support
+non-address taken globals), but is very quick analysis.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="steens-aa">The <tt>-steens-aa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-steens-aa</tt> pass implements a variation on the well-known
+"Steensgaard's algorithm" for interprocedural alias analysis. Steensgaard's
+algorithm is a unification-based, flow-insensitive, context-insensitive, and
+field-insensitive alias analysis that is also very scalable (effectively linear
+time).</p>
+
+<p>The LLVM <tt>-steens-aa</tt> pass implements a "speculatively
+field-<b>sensitive</b>" version of Steensgaard's algorithm using the Data
+Structure Analysis framework. This gives it substantially more precision than
+the standard algorithm while maintaining excellent analysis scalability.</p>
+
+<p>Note that <tt>-steens-aa</tt> is available in the optional "poolalloc"
+module, it is not part of the LLVM core.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ds-aa">The <tt>-ds-aa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-ds-aa</tt> pass implements the full Data Structure Analysis
+algorithm. Data Structure Analysis is a modular unification-based,
+flow-insensitive, context-<b>sensitive</b>, and speculatively
+field-<b>sensitive</b> alias analysis that is also quite scalable, usually at
+O(n*log(n)).</p>
+
+<p>This algorithm is capable of responding to a full variety of alias analysis
+queries, and can provide context-sensitive mod/ref information as well. The
+only major facility not implemented so far is support for must-alias
+information.</p>
+
+<p>Note that <tt>-ds-aa</tt> is available in the optional "poolalloc"
+module, it is not part of the LLVM core.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scev-aa">The <tt>-scev-aa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-scev-aa</tt> pass implements AliasAnalysis queries by
+translating them into ScalarEvolution queries. This gives it a
+more complete understanding of <tt>getelementptr</tt> instructions
+and loop induction variables than other alias analyses have.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="aliasanalysis-xforms">Alias analysis driven transformations</a>
+</h3>
+
+<div>
+LLVM includes several alias-analysis driven transformations which can be used
+with any of the implementations above.
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="adce">The <tt>-adce</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-adce</tt> pass, which implements Aggressive Dead Code Elimination
+uses the <tt>AliasAnalysis</tt> interface to delete calls to functions that do
+not have side-effects and are not used.</p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="licm">The <tt>-licm</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-licm</tt> pass implements various Loop Invariant Code Motion related
+transformations. It uses the <tt>AliasAnalysis</tt> interface for several
+different transformations:</p>
+
+<ul>
+<li>It uses mod/ref information to hoist or sink load instructions out of loops
+if there are no instructions in the loop that modifies the memory loaded.</li>
+
+<li>It uses mod/ref information to hoist function calls out of loops that do not
+write to memory and are loop-invariant.</li>
+
+<li>If uses alias information to promote memory objects that are loaded and
+stored to in loops to live in a register instead. It can do this if there are
+no may aliases to the loaded/stored memory location.</li>
+</ul>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="argpromotion">The <tt>-argpromotion</tt> pass</a>
+</h4>
+
+<div>
+<p>
+The <tt>-argpromotion</tt> pass promotes by-reference arguments to be passed in
+by-value instead. In particular, if pointer arguments are only loaded from it
+passes in the value loaded instead of the address to the function. This pass
+uses alias information to make sure that the value loaded from the argument
+pointer is not modified between the entry of the function and any load of the
+pointer.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="gvn">The <tt>-gvn</tt>, <tt>-memcpyopt</tt>, and <tt>-dse</tt>
+ passes</a>
+</h4>
+
+<div>
+
+<p>These passes use AliasAnalysis information to reason about loads and stores.
+</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="aliasanalysis-debug">Clients for debugging and evaluation of
+ implementations</a>
+</h3>
+
+<div>
+
+<p>These passes are useful for evaluating the various alias analysis
+implementations. You can use them with commands like '<tt>opt -ds-aa
+-aa-eval foo.bc -disable-output -stats</tt>'.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="print-alias-sets">The <tt>-print-alias-sets</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-print-alias-sets</tt> pass is exposed as part of the
+<tt>opt</tt> tool to print out the Alias Sets formed by the <a
+href="#ast"><tt>AliasSetTracker</tt></a> class. This is useful if you're using
+the <tt>AliasSetTracker</tt> class. To use it, use something like:</p>
+
+<div class="doc_code">
+<pre>
+% opt -ds-aa -print-alias-sets -disable-output
+</pre>
+</div>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="count-aa">The <tt>-count-aa</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-count-aa</tt> pass is useful to see how many queries a particular
+pass is making and what responses are returned by the alias analysis. As an
+example,</p>
+
+<div class="doc_code">
+<pre>
+% opt -basicaa -count-aa -ds-aa -count-aa -licm
+</pre>
+</div>
+
+<p>will print out how many queries (and what responses are returned) by the
+<tt>-licm</tt> pass (of the <tt>-ds-aa</tt> pass) and how many queries are made
+of the <tt>-basicaa</tt> pass by the <tt>-ds-aa</tt> pass. This can be useful
+when debugging a transformation or an alias analysis implementation.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="aa-eval">The <tt>-aa-eval</tt> pass</a>
+</h4>
+
+<div>
+
+<p>The <tt>-aa-eval</tt> pass simply iterates through all pairs of pointers in a
+function and asks an alias analysis whether or not the pointers alias. This
+gives an indication of the precision of the alias analysis. Statistics are
+printed indicating the percent of no/may/must aliases found (a more precise
+algorithm will have a lower number of may aliases).</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="memdep">Memory Dependence Analysis</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>If you're just looking to be a client of alias analysis information, consider
+using the Memory Dependence Analysis interface instead. MemDep is a lazy,
+caching layer on top of alias analysis that is able to answer the question of
+what preceding memory operations a given instruction depends on, either at an
+intra- or inter-block level. Because of its laziness and caching
+policy, using MemDep can be a significant performance win over accessing alias
+analysis directly.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2012-01-30 15:05:41 -0800 (Mon, 30 Jan 2012) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/Atomics.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/Atomics.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/Atomics.html (added)
+++ www-releases/trunk/3.1/docs/Atomics.html Tue May 22 14:32:29 2012
@@ -0,0 +1,569 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <title>LLVM Atomic Instructions and Concurrency Guide</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+<body>
+
+<h1>
+ LLVM Atomic Instructions and Concurrency Guide
+</h1>
+
+<ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#outsideatomic">Optimization outside atomic</a></li>
+ <li><a href="#atomicinst">Atomic instructions</a></li>
+ <li><a href="#ordering">Atomic orderings</a></li>
+ <li><a href="#iropt">Atomics and IR optimization</a></li>
+ <li><a href="#codegen">Atomics and Codegen</a></li>
+</ol>
+
+<div class="doc_author">
+ <p>Written by Eli Friedman</p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="introduction">Introduction</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Historically, LLVM has not had very strong support for concurrency; some
+minimal intrinsics were provided, and <code>volatile</code> was used in some
+cases to achieve rough semantics in the presence of concurrency. However, this
+is changing; there are now new instructions which are well-defined in the
+presence of threads and asynchronous signals, and the model for existing
+instructions has been clarified in the IR.</p>
+
+<p>The atomic instructions are designed specifically to provide readable IR and
+ optimized code generation for the following:</p>
+<ul>
+ <li>The new C++0x <code><atomic></code> header.
+ (<a href="http://www.open-std.org/jtc1/sc22/wg21/">C++0x draft available here</a>.)
+ (<a href="http://www.open-std.org/jtc1/sc22/wg14/">C1x draft available here</a>)</li>
+ <li>Proper semantics for Java-style memory, for both <code>volatile</code> and
+ regular shared variables.
+ (<a href="http://java.sun.com/docs/books/jls/third_edition/html/memory.html">Java Specification</a>)</li>
+ <li>gcc-compatible <code>__sync_*</code> builtins.
+ (<a href="http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html">Description</a>)</li>
+ <li>Other scenarios with atomic semantics, including <code>static</code>
+ variables with non-trivial constructors in C++.</li>
+</ul>
+
+<p>Atomic and volatile in the IR are orthogonal; "volatile" is the C/C++
+ volatile, which ensures that every volatile load and store happens and is
+ performed in the stated order. A couple examples: if a
+ SequentiallyConsistent store is immediately followed by another
+ SequentiallyConsistent store to the same address, the first store can
+ be erased. This transformation is not allowed for a pair of volatile
+ stores. On the other hand, a non-volatile non-atomic load can be moved
+ across a volatile load freely, but not an Acquire load.</p>
+
+<p>This document is intended to provide a guide to anyone either writing a
+ frontend for LLVM or working on optimization passes for LLVM with a guide
+ for how to deal with instructions with special semantics in the presence of
+ concurrency. This is not intended to be a precise guide to the semantics;
+ the details can get extremely complicated and unreadable, and are not
+ usually necessary.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="outsideatomic">Optimization outside atomic</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>The basic <code>'load'</code> and <code>'store'</code> allow a variety of
+ optimizations, but can lead to undefined results in a concurrent environment;
+ see <a href="#o_nonatomic">NonAtomic</a>. This section specifically goes
+ into the one optimizer restriction which applies in concurrent environments,
+ which gets a bit more of an extended description because any optimization
+ dealing with stores needs to be aware of it.</p>
+
+<p>From the optimizer's point of view, the rule is that if there
+ are not any instructions with atomic ordering involved, concurrency does
+ not matter, with one exception: if a variable might be visible to another
+ thread or signal handler, a store cannot be inserted along a path where it
+ might not execute otherwise. Take the following example:</p>
+
+<pre>
+/* C code, for readability; run through clang -O2 -S -emit-llvm to get
+ equivalent IR */
+int x;
+void f(int* a) {
+ for (int i = 0; i < 100; i++) {
+ if (a[i])
+ x += 1;
+ }
+}
+</pre>
+
+<p>The following is equivalent in non-concurrent situations:</p>
+
+<pre>
+int x;
+void f(int* a) {
+ int xtemp = x;
+ for (int i = 0; i < 100; i++) {
+ if (a[i])
+ xtemp += 1;
+ }
+ x = xtemp;
+}
+</pre>
+
+<p>However, LLVM is not allowed to transform the former to the latter: it could
+ indirectly introduce undefined behavior if another thread can access x at
+ the same time. (This example is particularly of interest because before the
+ concurrency model was implemented, LLVM would perform this
+ transformation.)</p>
+
+<p>Note that speculative loads are allowed; a load which
+ is part of a race returns <code>undef</code>, but does not have undefined
+ behavior.</p>
+
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="atomicinst">Atomic instructions</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>For cases where simple loads and stores are not sufficient, LLVM provides
+ various atomic instructions. The exact guarantees provided depend on the
+ ordering; see <a href="#ordering">Atomic orderings</a></p>
+
+<p><code>load atomic</code> and <code>store atomic</code> provide the same
+ basic functionality as non-atomic loads and stores, but provide additional
+ guarantees in situations where threads and signals are involved.</p>
+
+<p><code>cmpxchg</code> and <code>atomicrmw</code> are essentially like an
+ atomic load followed by an atomic store (where the store is conditional for
+ <code>cmpxchg</code>), but no other memory operation can happen on any thread
+ between the load and store. Note that LLVM's cmpxchg does not provide quite
+ as many options as the C++0x version.</p>
+
+<p>A <code>fence</code> provides Acquire and/or Release ordering which is not
+ part of another operation; it is normally used along with Monotonic memory
+ operations. A Monotonic load followed by an Acquire fence is roughly
+ equivalent to an Acquire load.</p>
+
+<p>Frontends generating atomic instructions generally need to be aware of the
+ target to some degree; atomic instructions are guaranteed to be lock-free,
+ and therefore an instruction which is wider than the target natively supports
+ can be impossible to generate.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="ordering">Atomic orderings</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>In order to achieve a balance between performance and necessary guarantees,
+ there are six levels of atomicity. They are listed in order of strength;
+ each level includes all the guarantees of the previous level except for
+ Acquire/Release. (See also <a href="LangRef.html#ordering">LangRef</a>.)</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_notatomic">NotAtomic</a>
+</h3>
+
+<div>
+
+<p>NotAtomic is the obvious, a load or store which is not atomic. (This isn't
+ really a level of atomicity, but is listed here for comparison.) This is
+ essentially a regular load or store. If there is a race on a given memory
+ location, loads from that location return undef.</p>
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This is intended to match shared variables in C/C++, and to be used
+ in any other context where memory access is necessary, and
+ a race is impossible. (The precise definition is in
+ <a href="LangRef.html#memmodel">LangRef</a>.)
+ <dt>Notes for frontends</dt>
+ <dd>The rule is essentially that all memory accessed with basic loads and
+ stores by multiple threads should be protected by a lock or other
+ synchronization; otherwise, you are likely to run into undefined
+ behavior. If your frontend is for a "safe" language like Java,
+ use Unordered to load and store any shared variable. Note that NotAtomic
+ volatile loads and stores are not properly atomic; do not try to use
+ them as a substitute. (Per the C/C++ standards, volatile does provide
+ some limited guarantees around asynchronous signals, but atomics are
+ generally a better solution.)
+ <dt>Notes for optimizers</dt>
+ <dd>Introducing loads to shared variables along a codepath where they would
+ not otherwise exist is allowed; introducing stores to shared variables
+ is not. See <a href="#outsideatomic">Optimization outside
+ atomic</a>.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>The one interesting restriction here is that it is not allowed to write
+ to bytes outside of the bytes relevant to a store. This is mostly
+ relevant to unaligned stores: it is not allowed in general to convert
+ an unaligned store into two aligned stores of the same width as the
+ unaligned store. Backends are also expected to generate an i8 store
+ as an i8 store, and not an instruction which writes to surrounding
+ bytes. (If you are writing a backend for an architecture which cannot
+ satisfy these restrictions and cares about concurrency, please send an
+ email to llvmdev.)</dd>
+</dl>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_unordered">Unordered</a>
+</h3>
+
+<div>
+
+<p>Unordered is the lowest level of atomicity. It essentially guarantees that
+ races produce somewhat sane results instead of having undefined behavior.
+ It also guarantees the operation to be lock-free, so it do not depend on
+ the data being part of a special atomic structure or depend on a separate
+ per-process global lock. Note that code generation will fail for
+ unsupported atomic operations; if you need such an operation, use explicit
+ locking.</p>
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This is intended to match the Java memory model for shared
+ variables.</dd>
+ <dt>Notes for frontends</dt>
+ <dd>This cannot be used for synchronization, but is useful for Java and
+ other "safe" languages which need to guarantee that the generated
+ code never exhibits undefined behavior. Note that this guarantee
+ is cheap on common platforms for loads of a native width, but can
+ be expensive or unavailable for wider loads, like a 64-bit store
+ on ARM. (A frontend for Java or other "safe" languages would normally
+ split a 64-bit store on ARM into two 32-bit unordered stores.)
+ <dt>Notes for optimizers</dt>
+ <dd>In terms of the optimizer, this prohibits any transformation that
+ transforms a single load into multiple loads, transforms a store
+ into multiple stores, narrows a store, or stores a value which
+ would not be stored otherwise. Some examples of unsafe optimizations
+ are narrowing an assignment into a bitfield, rematerializing
+ a load, and turning loads and stores into a memcpy call. Reordering
+ unordered operations is safe, though, and optimizers should take
+ advantage of that because unordered operations are common in
+ languages that need them.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>These operations are required to be atomic in the sense that if you
+ use unordered loads and unordered stores, a load cannot see a value
+ which was never stored. A normal load or store instruction is usually
+ sufficient, but note that an unordered load or store cannot
+ be split into multiple instructions (or an instruction which
+ does multiple memory operations, like <code>LDRD</code> on ARM).</dd>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_monotonic">Monotonic</a>
+</h3>
+
+<div>
+
+<p>Monotonic is the weakest level of atomicity that can be used in
+ synchronization primitives, although it does not provide any general
+ synchronization. It essentially guarantees that if you take all the
+ operations affecting a specific address, a consistent ordering exists.
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This corresponds to the C++0x/C1x <code>memory_order_relaxed</code>;
+ see those standards for the exact definition.
+ <dt>Notes for frontends</dt>
+ <dd>If you are writing a frontend which uses this directly, use with caution.
+ The guarantees in terms of synchronization are very weak, so make
+ sure these are only used in a pattern which you know is correct.
+ Generally, these would either be used for atomic operations which
+ do not protect other memory (like an atomic counter), or along with
+ a <code>fence</code>.</dd>
+ <dt>Notes for optimizers</dt>
+ <dd>In terms of the optimizer, this can be treated as a read+write on the
+ relevant memory location (and alias analysis will take advantage of
+ that). In addition, it is legal to reorder non-atomic and Unordered
+ loads around Monotonic loads. CSE/DSE and a few other optimizations
+ are allowed, but Monotonic operations are unlikely to be used in ways
+ which would make those optimizations useful.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>Code generation is essentially the same as that for unordered for loads
+ and stores. No fences are required. <code>cmpxchg</code> and
+ <code>atomicrmw</code> are required to appear as a single operation.</dd>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_acquire">Acquire</a>
+</h3>
+
+<div>
+
+<p>Acquire provides a barrier of the sort necessary to acquire a lock to access
+ other memory with normal loads and stores.
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This corresponds to the C++0x/C1x <code>memory_order_acquire</code>. It
+ should also be used for C++0x/C1x <code>memory_order_consume</code>.
+ <dt>Notes for frontends</dt>
+ <dd>If you are writing a frontend which uses this directly, use with caution.
+ Acquire only provides a semantic guarantee when paired with a Release
+ operation.</dd>
+ <dt>Notes for optimizers</dt>
+ <dd>Optimizers not aware of atomics can treat this like a nothrow call.
+ It is also possible to move stores from before an Acquire load
+ or read-modify-write operation to after it, and move non-Acquire
+ loads from before an Acquire operation to after it.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>Architectures with weak memory ordering (essentially everything relevant
+ today except x86 and SPARC) require some sort of fence to maintain
+ the Acquire semantics. The precise fences required varies widely by
+ architecture, but for a simple implementation, most architectures provide
+ a barrier which is strong enough for everything (<code>dmb</code> on ARM,
+ <code>sync</code> on PowerPC, etc.). Putting such a fence after the
+ equivalent Monotonic operation is sufficient to maintain Acquire
+ semantics for a memory operation.</dd>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_acquire">Release</a>
+</h3>
+
+<div>
+
+<p>Release is similar to Acquire, but with a barrier of the sort necessary to
+ release a lock.
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This corresponds to the C++0x/C1x <code>memory_order_release</code>.</dd>
+ <dt>Notes for frontends</dt>
+ <dd>If you are writing a frontend which uses this directly, use with caution.
+ Release only provides a semantic guarantee when paired with a Acquire
+ operation.</dd>
+ <dt>Notes for optimizers</dt>
+ <dd>Optimizers not aware of atomics can treat this like a nothrow call.
+ It is also possible to move loads from after a Release store
+ or read-modify-write operation to before it, and move non-Release
+ stores from after an Release operation to before it.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>See the section on Acquire; a fence before the relevant operation is
+ usually sufficient for Release. Note that a store-store fence is not
+ sufficient to implement Release semantics; store-store fences are
+ generally not exposed to IR because they are extremely difficult to
+ use correctly.</dd>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_acqrel">AcquireRelease</a>
+</h3>
+
+<div>
+
+<p>AcquireRelease (<code>acq_rel</code> in IR) provides both an Acquire and a
+ Release barrier (for fences and operations which both read and write memory).
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This corresponds to the C++0x/C1x <code>memory_order_acq_rel</code>.
+ <dt>Notes for frontends</dt>
+ <dd>If you are writing a frontend which uses this directly, use with caution.
+ Acquire only provides a semantic guarantee when paired with a Release
+ operation, and vice versa.</dd>
+ <dt>Notes for optimizers</dt>
+ <dd>In general, optimizers should treat this like a nothrow call; the
+ the possible optimizations are usually not interesting.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>This operation has Acquire and Release semantics; see the sections on
+ Acquire and Release.</dd>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="o_seqcst">SequentiallyConsistent</a>
+</h3>
+
+<div>
+
+<p>SequentiallyConsistent (<code>seq_cst</code> in IR) provides
+ Acquire semantics for loads and Release semantics for
+ stores. Additionally, it guarantees that a total ordering exists
+ between all SequentiallyConsistent operations.
+
+<dl>
+ <dt>Relevant standard</dt>
+ <dd>This corresponds to the C++0x/C1x <code>memory_order_seq_cst</code>,
+ Java volatile, and the gcc-compatible <code>__sync_*</code> builtins
+ which do not specify otherwise.
+ <dt>Notes for frontends</dt>
+ <dd>If a frontend is exposing atomic operations, these are much easier to
+ reason about for the programmer than other kinds of operations, and using
+ them is generally a practical performance tradeoff.</dd>
+ <dt>Notes for optimizers</dt>
+ <dd>Optimizers not aware of atomics can treat this like a nothrow call.
+ For SequentiallyConsistent loads and stores, the same reorderings are
+ allowed as for Acquire loads and Release stores, except that
+ SequentiallyConsistent operations may not be reordered.</dd>
+ <dt>Notes for code generation</dt>
+ <dd>SequentiallyConsistent loads minimally require the same barriers
+ as Acquire operations and SequentiallyConsistent stores require
+ Release barriers. Additionally, the code generator must enforce
+ ordering between SequentiallyConsistent stores followed by
+ SequentiallyConsistent loads. This is usually done by emitting
+ either a full fence before the loads or a full fence after the
+ stores; which is preferred varies by architecture.</dd>
+</dl>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="iropt">Atomics and IR optimization</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Predicates for optimizer writers to query:
+<ul>
+ <li>isSimple(): A load or store which is not volatile or atomic. This is
+ what, for example, memcpyopt would check for operations it might
+ transform.</li>
+ <li>isUnordered(): A load or store which is not volatile and at most
+ Unordered. This would be checked, for example, by LICM before hoisting
+ an operation.</li>
+ <li>mayReadFromMemory()/mayWriteToMemory(): Existing predicate, but note
+ that they return true for any operation which is volatile or at least
+ Monotonic.</li>
+ <li>Alias analysis: Note that AA will return ModRef for anything Acquire or
+ Release, and for the address accessed by any Monotonic operation.</li>
+</ul>
+
+<p>To support optimizing around atomic operations, make sure you are using
+ the right predicates; everything should work if that is done. If your
+ pass should optimize some atomic operations (Unordered operations in
+ particular), make sure it doesn't replace an atomic load or store with
+ a non-atomic operation.</p>
+
+<p>Some examples of how optimizations interact with various kinds of atomic
+ operations:
+<ul>
+ <li>memcpyopt: An atomic operation cannot be optimized into part of a
+ memcpy/memset, including unordered loads/stores. It can pull operations
+ across some atomic operations.
+ <li>LICM: Unordered loads/stores can be moved out of a loop. It just treats
+ monotonic operations like a read+write to a memory location, and anything
+ stricter than that like a nothrow call.
+ <li>DSE: Unordered stores can be DSE'ed like normal stores. Monotonic stores
+ can be DSE'ed in some cases, but it's tricky to reason about, and not
+ especially important.
+ <li>Folding a load: Any atomic load from a constant global can be
+ constant-folded, because it cannot be observed. Similar reasoning allows
+ scalarrepl with atomic loads and stores.
+</ul>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="codegen">Atomics and Codegen</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Atomic operations are represented in the SelectionDAG with
+ <code>ATOMIC_*</code> opcodes. On architectures which use barrier
+ instructions for all atomic ordering (like ARM), appropriate fences are
+ split out as the DAG is built.</p>
+
+<p>The MachineMemOperand for all atomic operations is currently marked as
+ volatile; this is not correct in the IR sense of volatile, but CodeGen
+ handles anything marked volatile very conservatively. This should get
+ fixed at some point.</p>
+
+<p>Common architectures have some way of representing at least a pointer-sized
+ lock-free <code>cmpxchg</code>; such an operation can be used to implement
+ all the other atomic operations which can be represented in IR up to that
+ size. Backends are expected to implement all those operations, but not
+ operations which cannot be implemented in a lock-free manner. It is
+ expected that backends will give an error when given an operation which
+ cannot be implemented. (The LLVM code generator is not very helpful here
+ at the moment, but hopefully that will change.)</p>
+
+<p>The implementation of atomics on LL/SC architectures (like ARM) is currently
+ a bit of a mess; there is a lot of copy-pasted code across targets, and
+ the representation is relatively unsuited to optimization (it would be nice
+ to be able to optimize loops involving cmpxchg etc.).</p>
+
+<p>On x86, all atomic loads generate a <code>MOV</code>.
+ SequentiallyConsistent stores generate an <code>XCHG</code>, other stores
+ generate a <code>MOV</code>. SequentiallyConsistent fences generate an
+ <code>MFENCE</code>, other fences do not cause any code to be generated.
+ cmpxchg uses the <code>LOCK CMPXCHG</code> instruction.
+ <code>atomicrmw xchg</code> uses <code>XCHG</code>,
+ <code>atomicrmw add</code> and <code>atomicrmw sub</code> use
+ <code>XADD</code>, and all other <code>atomicrmw</code> operations generate
+ a loop with <code>LOCK CMPXCHG</code>. Depending on the users of the
+ result, some <code>atomicrmw</code> operations can be translated into
+ operations like <code>LOCK AND</code>, but that does not work in
+ general.</p>
+
+<p>On ARM, MIPS, and many other RISC architectures, Acquire, Release, and
+ SequentiallyConsistent semantics require barrier instructions
+ for every such operation. Loads and stores generate normal instructions.
+ <code>cmpxchg</code> and <code>atomicrmw</code> can be represented using
+ a loop with LL/SC-style instructions which take some sort of exclusive
+ lock on a cache line (<code>LDREX</code> and <code>STREX</code> on
+ ARM, etc.). At the moment, the IR does not provide any way to represent a
+ weak <code>cmpxchg</code> which would not require a loop.</p>
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2011-08-09 02:07:00 -0700 (Tue, 09 Aug 2011) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/BitCodeFormat.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/BitCodeFormat.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/BitCodeFormat.html (added)
+++ www-releases/trunk/3.1/docs/BitCodeFormat.html Tue May 22 14:32:29 2012
@@ -0,0 +1,1470 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>LLVM Bitcode File Format</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+<body>
+<h1> LLVM Bitcode File Format</h1>
+<ol>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#overview">Overview</a></li>
+ <li><a href="#bitstream">Bitstream Format</a>
+ <ol>
+ <li><a href="#magic">Magic Numbers</a></li>
+ <li><a href="#primitives">Primitives</a></li>
+ <li><a href="#abbrevid">Abbreviation IDs</a></li>
+ <li><a href="#blocks">Blocks</a></li>
+ <li><a href="#datarecord">Data Records</a></li>
+ <li><a href="#abbreviations">Abbreviations</a></li>
+ <li><a href="#stdblocks">Standard Blocks</a></li>
+ </ol>
+ </li>
+ <li><a href="#wrapper">Bitcode Wrapper Format</a>
+ </li>
+ <li><a href="#llvmir">LLVM IR Encoding</a>
+ <ol>
+ <li><a href="#basics">Basics</a></li>
+ <li><a href="#MODULE_BLOCK">MODULE_BLOCK Contents</a></li>
+ <li><a href="#PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a></li>
+ <li><a href="#TYPE_BLOCK">TYPE_BLOCK Contents</a></li>
+ <li><a href="#CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a></li>
+ <li><a href="#FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a></li>
+ <li><a href="#TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a></li>
+ <li><a href="#VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a></li>
+ <li><a href="#METADATA_BLOCK">METADATA_BLOCK Contents</a></li>
+ <li><a href="#METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a></li>
+ </ol>
+ </li>
+</ol>
+<div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a>,
+ <a href="http://www.reverberate.org">Joshua Haberman</a>,
+ and <a href="mailto:housel at acm.org">Peter S. Housel</a>.
+</p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="abstract">Abstract</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This document describes the LLVM bitstream file format and the encoding of
+the LLVM IR into it.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="overview">Overview</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>
+What is commonly known as the LLVM bitcode file format (also, sometimes
+anachronistically known as bytecode) is actually two things: a <a
+href="#bitstream">bitstream container format</a>
+and an <a href="#llvmir">encoding of LLVM IR</a> into the container format.</p>
+
+<p>
+The bitstream format is an abstract encoding of structured data, very
+similar to XML in some ways. Like XML, bitstream files contain tags, and nested
+structures, and you can parse the file without having to understand the tags.
+Unlike XML, the bitstream format is a binary encoding, and unlike XML it
+provides a mechanism for the file to self-describe "abbreviations", which are
+effectively size optimizations for the content.</p>
+
+<p>LLVM IR files may be optionally embedded into a <a
+href="#wrapper">wrapper</a> structure that makes it easy to embed extra data
+along with LLVM IR files.</p>
+
+<p>This document first describes the LLVM bitstream format, describes the
+wrapper format, then describes the record structure used by LLVM IR files.
+</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="bitstream">Bitstream Format</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>
+The bitstream format is literally a stream of bits, with a very simple
+structure. This structure consists of the following concepts:
+</p>
+
+<ul>
+<li>A "<a href="#magic">magic number</a>" that identifies the contents of
+ the stream.</li>
+<li>Encoding <a href="#primitives">primitives</a> like variable bit-rate
+ integers.</li>
+<li><a href="#blocks">Blocks</a>, which define nested content.</li>
+<li><a href="#datarecord">Data Records</a>, which describe entities within the
+ file.</li>
+<li>Abbreviations, which specify compression optimizations for the file.</li>
+</ul>
+
+<p>Note that the <a
+href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer</a> tool can be
+used to dump and inspect arbitrary bitstreams, which is very useful for
+understanding the encoding.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="magic">Magic Numbers</a>
+</h3>
+
+<div>
+
+<p>The first two bytes of a bitcode file are 'BC' (0x42, 0x43).
+The second two bytes are an application-specific magic number. Generic
+bitcode tools can look at only the first two bytes to verify the file is
+bitcode, while application-specific programs will want to look at all four.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="primitives">Primitives</a>
+</h3>
+
+<div>
+
+<p>
+A bitstream literally consists of a stream of bits, which are read in order
+starting with the least significant bit of each byte. The stream is made up of a
+number of primitive values that encode a stream of unsigned integer values.
+These integers are encoded in two ways: either as <a href="#fixedwidth">Fixed
+Width Integers</a> or as <a href="#variablewidth">Variable Width
+Integers</a>.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="fixedwidth">Fixed Width Integers</a>
+</h4>
+
+<div>
+
+<p>Fixed-width integer values have their low bits emitted directly to the file.
+ For example, a 3-bit integer value encodes 1 as 001. Fixed width integers
+ are used when there are a well-known number of options for a field. For
+ example, boolean values are usually encoded with a 1-bit wide integer.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="variablewidth">Variable Width Integers</a>
+</h4>
+
+<div>
+
+<p>Variable-width integer (VBR) values encode values of arbitrary size,
+optimizing for the case where the values are small. Given a 4-bit VBR field,
+any 3-bit value (0 through 7) is encoded directly, with the high bit set to
+zero. Values larger than N-1 bits emit their bits in a series of N-1 bit
+chunks, where all but the last set the high bit.</p>
+
+<p>For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a
+vbr4 value. The first set of four bits indicates the value 3 (011) with a
+continuation piece (indicated by a high bit of 1). The next word indicates a
+value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value
+27.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="char6">6-bit characters</a></h4>
+
+<div>
+
+<p>6-bit characters encode common characters into a fixed 6-bit field. They
+represent the following characters with the following 6-bit values:</p>
+
+<div class="doc_code">
+<pre>
+'a' .. 'z' — 0 .. 25
+'A' .. 'Z' — 26 .. 51
+'0' .. '9' — 52 .. 61
+ '.' — 62
+ '_' — 63
+</pre>
+</div>
+
+<p>This encoding is only suitable for encoding characters and strings that
+consist only of the above characters. It is completely incapable of encoding
+characters not in the set.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="wordalign">Word Alignment</a></h4>
+
+<div>
+
+<p>Occasionally, it is useful to emit zero bits until the bitstream is a
+multiple of 32 bits. This ensures that the bit position in the stream can be
+represented as a multiple of 32-bit words.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="abbrevid">Abbreviation IDs</a>
+</h3>
+
+<div>
+
+<p>
+A bitstream is a sequential series of <a href="#blocks">Blocks</a> and
+<a href="#datarecord">Data Records</a>. Both of these start with an
+abbreviation ID encoded as a fixed-bitwidth field. The width is specified by
+the current block, as described below. The value of the abbreviation ID
+specifies either a builtin ID (which have special meanings, defined below) or
+one of the abbreviation IDs defined for the current block by the stream itself.
+</p>
+
+<p>
+The set of builtin abbrev IDs is:
+</p>
+
+<ul>
+<li><tt>0 - <a href="#END_BLOCK">END_BLOCK</a></tt> — This abbrev ID marks
+ the end of the current block.</li>
+<li><tt>1 - <a href="#ENTER_SUBBLOCK">ENTER_SUBBLOCK</a></tt> — This
+ abbrev ID marks the beginning of a new block.</li>
+<li><tt>2 - <a href="#DEFINE_ABBREV">DEFINE_ABBREV</a></tt> — This defines
+ a new abbreviation.</li>
+<li><tt>3 - <a href="#UNABBREV_RECORD">UNABBREV_RECORD</a></tt> — This ID
+ specifies the definition of an unabbreviated record.</li>
+</ul>
+
+<p>Abbreviation IDs 4 and above are defined by the stream itself, and specify
+an <a href="#abbrev_records">abbreviated record encoding</a>.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="blocks">Blocks</a>
+</h3>
+
+<div>
+
+<p>
+Blocks in a bitstream denote nested regions of the stream, and are identified by
+a content-specific id number (for example, LLVM IR uses an ID of 12 to represent
+function bodies). Block IDs 0-7 are reserved for <a href="#stdblocks">standard blocks</a>
+whose meaning is defined by Bitcode; block IDs 8 and greater are
+application specific. Nested blocks capture the hierarchical structure of the data
+encoded in it, and various properties are associated with blocks as the file is
+parsed. Block definitions allow the reader to efficiently skip blocks
+in constant time if the reader wants a summary of blocks, or if it wants to
+efficiently skip data it does not understand. The LLVM IR reader uses this
+mechanism to skip function bodies, lazily reading them on demand.
+</p>
+
+<p>
+When reading and encoding the stream, several properties are maintained for the
+block. In particular, each block maintains:
+</p>
+
+<ol>
+<li>A current abbrev id width. This value starts at 2 at the beginning of
+ the stream, and is set every time a
+ block record is entered. The block entry specifies the abbrev id width for
+ the body of the block.</li>
+
+<li>A set of abbreviations. Abbreviations may be defined within a block, in
+ which case they are only defined in that block (neither subblocks nor
+ enclosing blocks see the abbreviation). Abbreviations can also be defined
+ inside a <tt><a href="#BLOCKINFO">BLOCKINFO</a></tt> block, in which case
+ they are defined in all blocks that match the ID that the BLOCKINFO block is
+ describing.
+</li>
+</ol>
+
+<p>
+As sub blocks are entered, these properties are saved and the new sub-block has
+its own set of abbreviations, and its own abbrev id width. When a sub-block is
+popped, the saved values are restored.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="ENTER_SUBBLOCK">ENTER_SUBBLOCK Encoding</a></h4>
+
+<div>
+
+<p><tt>[ENTER_SUBBLOCK, blockid<sub>vbr8</sub>, newabbrevlen<sub>vbr4</sub>,
+ <align32bits>, blocklen<sub>32</sub>]</tt></p>
+
+<p>
+The <tt>ENTER_SUBBLOCK</tt> abbreviation ID specifies the start of a new block
+record. The <tt>blockid</tt> value is encoded as an 8-bit VBR identifier, and
+indicates the type of block being entered, which can be
+a <a href="#stdblocks">standard block</a> or an application-specific block.
+The <tt>newabbrevlen</tt> value is a 4-bit VBR, which specifies the abbrev id
+width for the sub-block. The <tt>blocklen</tt> value is a 32-bit aligned value
+that specifies the size of the subblock in 32-bit words. This value allows the
+reader to skip over the entire block in one jump.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="END_BLOCK">END_BLOCK Encoding</a></h4>
+
+<div>
+
+<p><tt>[END_BLOCK, <align32bits>]</tt></p>
+
+<p>
+The <tt>END_BLOCK</tt> abbreviation ID specifies the end of the current block
+record. Its end is aligned to 32-bits to ensure that the size of the block is
+an even multiple of 32-bits.
+</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="datarecord">Data Records</a>
+</h3>
+
+<div>
+<p>
+Data records consist of a record code and a number of (up to) 64-bit
+integer values. The interpretation of the code and values is
+application specific and may vary between different block types.
+Records can be encoded either using an unabbrev record, or with an
+abbreviation. In the LLVM IR format, for example, there is a record
+which encodes the target triple of a module. The code is
+<tt>MODULE_CODE_TRIPLE</tt>, and the values of the record are the
+ASCII codes for the characters in the string.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="UNABBREV_RECORD">UNABBREV_RECORD Encoding</a></h4>
+
+<div>
+
+<p><tt>[UNABBREV_RECORD, code<sub>vbr6</sub>, numops<sub>vbr6</sub>,
+ op0<sub>vbr6</sub>, op1<sub>vbr6</sub>, ...]</tt></p>
+
+<p>
+An <tt>UNABBREV_RECORD</tt> provides a default fallback encoding, which is both
+completely general and extremely inefficient. It can describe an arbitrary
+record by emitting the code and operands as VBRs.
+</p>
+
+<p>
+For example, emitting an LLVM IR target triple as an unabbreviated record
+requires emitting the <tt>UNABBREV_RECORD</tt> abbrevid, a vbr6 for the
+<tt>MODULE_CODE_TRIPLE</tt> code, a vbr6 for the length of the string, which is
+equal to the number of operands, and a vbr6 for each character. Because there
+are no letters with values less than 32, each letter would need to be emitted as
+at least a two-part VBR, which means that each letter would require at least 12
+bits. This is not an efficient encoding, but it is fully general.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="abbrev_records">Abbreviated Record Encoding</a></h4>
+
+<div>
+
+<p><tt>[<abbrevid>, fields...]</tt></p>
+
+<p>
+An abbreviated record is a abbreviation id followed by a set of fields that are
+encoded according to the <a href="#abbreviations">abbreviation definition</a>.
+This allows records to be encoded significantly more densely than records
+encoded with the <tt><a href="#UNABBREV_RECORD">UNABBREV_RECORD</a></tt> type,
+and allows the abbreviation types to be specified in the stream itself, which
+allows the files to be completely self describing. The actual encoding of
+abbreviations is defined below.
+</p>
+
+<p>The record code, which is the first field of an abbreviated record,
+may be encoded in the abbreviation definition (as a literal
+operand) or supplied in the abbreviated record (as a Fixed or VBR
+operand value).</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="abbreviations">Abbreviations</a>
+</h3>
+
+<div>
+<p>
+Abbreviations are an important form of compression for bitstreams. The idea is
+to specify a dense encoding for a class of records once, then use that encoding
+to emit many records. It takes space to emit the encoding into the file, but
+the space is recouped (hopefully plus some) when the records that use it are
+emitted.
+</p>
+
+<p>
+Abbreviations can be determined dynamically per client, per file. Because the
+abbreviations are stored in the bitstream itself, different streams of the same
+format can contain different sets of abbreviations according to the needs
+of the specific stream.
+As a concrete example, LLVM IR files usually emit an abbreviation
+for binary operators. If a specific LLVM module contained no or few binary
+operators, the abbreviation does not need to be emitted.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="DEFINE_ABBREV">DEFINE_ABBREV Encoding</a></h4>
+
+<div>
+
+<p><tt>[DEFINE_ABBREV, numabbrevops<sub>vbr5</sub>, abbrevop0, abbrevop1,
+ ...]</tt></p>
+
+<p>
+A <tt>DEFINE_ABBREV</tt> record adds an abbreviation to the list of currently
+defined abbreviations in the scope of this block. This definition only exists
+inside this immediate block — it is not visible in subblocks or enclosing
+blocks. Abbreviations are implicitly assigned IDs sequentially starting from 4
+(the first application-defined abbreviation ID). Any abbreviations defined in a
+<tt>BLOCKINFO</tt> record for the particular block type
+receive IDs first, in order, followed by any
+abbreviations defined within the block itself. Abbreviated data records
+reference this ID to indicate what abbreviation they are invoking.
+</p>
+
+<p>
+An abbreviation definition consists of the <tt>DEFINE_ABBREV</tt> abbrevid
+followed by a VBR that specifies the number of abbrev operands, then the abbrev
+operands themselves. Abbreviation operands come in three forms. They all start
+with a single bit that indicates whether the abbrev operand is a literal operand
+(when the bit is 1) or an encoding operand (when the bit is 0).
+</p>
+
+<ol>
+<li>Literal operands — <tt>[1<sub>1</sub>, litvalue<sub>vbr8</sub>]</tt>
+— Literal operands specify that the value in the result is always a single
+specific value. This specific value is emitted as a vbr8 after the bit
+indicating that it is a literal operand.</li>
+<li>Encoding info without data — <tt>[0<sub>1</sub>,
+ encoding<sub>3</sub>]</tt> — Operand encodings that do not have extra
+ data are just emitted as their code.
+</li>
+<li>Encoding info with data — <tt>[0<sub>1</sub>, encoding<sub>3</sub>,
+value<sub>vbr5</sub>]</tt> — Operand encodings that do have extra data are
+emitted as their code, followed by the extra data.
+</li>
+</ol>
+
+<p>The possible operand encodings are:</p>
+
+<ul>
+<li>Fixed (code 1): The field should be emitted as
+ a <a href="#fixedwidth">fixed-width value</a>, whose width is specified by
+ the operand's extra data.</li>
+<li>VBR (code 2): The field should be emitted as
+ a <a href="#variablewidth">variable-width value</a>, whose width is
+ specified by the operand's extra data.</li>
+<li>Array (code 3): This field is an array of values. The array operand
+ has no extra data, but expects another operand to follow it, indicating
+ the element type of the array. When reading an array in an abbreviated
+ record, the first integer is a vbr6 that indicates the array length,
+ followed by the encoded elements of the array. An array may only occur as
+ the last operand of an abbreviation (except for the one final operand that
+ gives the array's type).</li>
+<li>Char6 (code 4): This field should be emitted as
+ a <a href="#char6">char6-encoded value</a>. This operand type takes no
+ extra data. Char6 encoding is normally used as an array element type.
+ </li>
+<li>Blob (code 5): This field is emitted as a vbr6, followed by padding to a
+ 32-bit boundary (for alignment) and an array of 8-bit objects. The array of
+ bytes is further followed by tail padding to ensure that its total length is
+ a multiple of 4 bytes. This makes it very efficient for the reader to
+ decode the data without having to make a copy of it: it can use a pointer to
+ the data in the mapped in file and poke directly at it. A blob may only
+ occur as the last operand of an abbreviation.</li>
+</ul>
+
+<p>
+For example, target triples in LLVM modules are encoded as a record of the
+form <tt>[TRIPLE, 'a', 'b', 'c', 'd']</tt>. Consider if the bitstream emitted
+the following abbrev entry:
+</p>
+
+<div class="doc_code">
+<pre>
+[0, Fixed, 4]
+[0, Array]
+[0, Char6]
+</pre>
+</div>
+
+<p>
+When emitting a record with this abbreviation, the above entry would be emitted
+as:
+</p>
+
+<div class="doc_code">
+<p>
+<tt>[4<sub>abbrevwidth</sub>, 2<sub>4</sub>, 4<sub>vbr6</sub>, 0<sub>6</sub>,
+1<sub>6</sub>, 2<sub>6</sub>, 3<sub>6</sub>]</tt>
+</p>
+</div>
+
+<p>These values are:</p>
+
+<ol>
+<li>The first value, 4, is the abbreviation ID for this abbreviation.</li>
+<li>The second value, 2, is the record code for <tt>TRIPLE</tt> records within LLVM IR file <tt>MODULE_BLOCK</tt> blocks.</li>
+<li>The third value, 4, is the length of the array.</li>
+<li>The rest of the values are the char6 encoded values
+ for <tt>"abcd"</tt>.</li>
+</ol>
+
+<p>
+With this abbreviation, the triple is emitted with only 37 bits (assuming a
+abbrev id width of 3). Without the abbreviation, significantly more space would
+be required to emit the target triple. Also, because the <tt>TRIPLE</tt> value
+is not emitted as a literal in the abbreviation, the abbreviation can also be
+used for any other string value.
+</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="stdblocks">Standard Blocks</a>
+</h3>
+
+<div>
+
+<p>
+In addition to the basic block structure and record encodings, the bitstream
+also defines specific built-in block types. These block types specify how the
+stream is to be decoded or other metadata. In the future, new standard blocks
+may be added. Block IDs 0-7 are reserved for standard blocks.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="BLOCKINFO">#0 - BLOCKINFO Block</a></h4>
+
+<div>
+
+<p>
+The <tt>BLOCKINFO</tt> block allows the description of metadata for other
+blocks. The currently specified records are:
+</p>
+
+<div class="doc_code">
+<pre>
+[SETBID (#1), blockid]
+[DEFINE_ABBREV, ...]
+[BLOCKNAME, ...name...]
+[SETRECORDNAME, RecordID, ...name...]
+</pre>
+</div>
+
+<p>
+The <tt>SETBID</tt> record (code 1) indicates which block ID is being
+described. <tt>SETBID</tt> records can occur multiple times throughout the
+block to change which block ID is being described. There must be
+a <tt>SETBID</tt> record prior to any other records.
+</p>
+
+<p>
+Standard <tt>DEFINE_ABBREV</tt> records can occur inside <tt>BLOCKINFO</tt>
+blocks, but unlike their occurrence in normal blocks, the abbreviation is
+defined for blocks matching the block ID we are describing, <i>not</i> the
+<tt>BLOCKINFO</tt> block itself. The abbreviations defined
+in <tt>BLOCKINFO</tt> blocks receive abbreviation IDs as described
+in <tt><a href="#DEFINE_ABBREV">DEFINE_ABBREV</a></tt>.
+</p>
+
+<p>The <tt>BLOCKNAME</tt> record (code 2) can optionally occur in this block. The elements of
+the record are the bytes of the string name of the block. llvm-bcanalyzer can use
+this to dump out bitcode files symbolically.</p>
+
+<p>The <tt>SETRECORDNAME</tt> record (code 3) can also optionally occur in this block. The
+first operand value is a record ID number, and the rest of the elements of the record are
+the bytes for the string name of the record. llvm-bcanalyzer can use
+this to dump out bitcode files symbolically.</p>
+
+<p>
+Note that although the data in <tt>BLOCKINFO</tt> blocks is described as
+"metadata," the abbreviations they contain are essential for parsing records
+from the corresponding blocks. It is not safe to skip them.
+</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="wrapper">Bitcode Wrapper Format</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>
+Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper
+structure. This structure contains a simple header that indicates the offset
+and size of the embedded BC file. This allows additional information to be
+stored alongside the BC file. The structure of this file header is:
+</p>
+
+<div class="doc_code">
+<p>
+<tt>[Magic<sub>32</sub>, Version<sub>32</sub>, Offset<sub>32</sub>,
+Size<sub>32</sub>, CPUType<sub>32</sub>]</tt>
+</p>
+</div>
+
+<p>
+Each of the fields are 32-bit fields stored in little endian form (as with
+the rest of the bitcode file fields). The Magic number is always
+<tt>0x0B17C0DE</tt> and the version is currently always <tt>0</tt>. The Offset
+field is the offset in bytes to the start of the bitcode stream in the file, and
+the Size field is the size in bytes of the stream. CPUType is a target-specific
+value that can be used to encode the CPU of the target.
+</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2><a name="llvmir">LLVM IR Encoding</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>
+LLVM IR is encoded into a bitstream by defining blocks and records. It uses
+blocks for things like constant pools, functions, symbol tables, etc. It uses
+records for things like instructions, global variable descriptors, type
+descriptions, etc. This document does not describe the set of abbreviations
+that the writer uses, as these are fully self-described in the file, and the
+reader is not allowed to build in any knowledge of this.
+</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="basics">Basics</a>
+</h3>
+
+<div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="ir_magic">LLVM IR Magic Number</a></h4>
+
+<div>
+
+<p>
+The magic number for LLVM IR files is:
+</p>
+
+<div class="doc_code">
+<p>
+<tt>[0x0<sub>4</sub>, 0xC<sub>4</sub>, 0xE<sub>4</sub>, 0xD<sub>4</sub>]</tt>
+</p>
+</div>
+
+<p>
+When combined with the bitcode magic number and viewed as bytes, this is
+<tt>"BC 0xC0DE"</tt>.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="ir_signed_vbr">Signed VBRs</a></h4>
+
+<div>
+
+<p>
+<a href="#variablewidth">Variable Width Integer</a> encoding is an efficient way to
+encode arbitrary sized unsigned values, but is an extremely inefficient for
+encoding signed values, as signed values are otherwise treated as maximally large
+unsigned values.
+</p>
+
+<p>
+As such, signed VBR values of a specific width are emitted as follows:
+</p>
+
+<ul>
+<li>Positive values are emitted as VBRs of the specified width, but with their
+ value shifted left by one.</li>
+<li>Negative values are emitted as VBRs of the specified width, but the negated
+ value is shifted left by one, and the low bit is set.</li>
+</ul>
+
+<p>
+With this encoding, small positive and small negative values can both
+be emitted efficiently. Signed VBR encoding is used in
+<tt>CST_CODE_INTEGER</tt> and <tt>CST_CODE_WIDE_INTEGER</tt> records
+within <tt>CONSTANTS_BLOCK</tt> blocks.
+</p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="ir_blocks">LLVM IR Blocks</a></h4>
+
+<div>
+
+<p>
+LLVM IR is defined with the following blocks:
+</p>
+
+<ul>
+<li>8 — <a href="#MODULE_BLOCK"><tt>MODULE_BLOCK</tt></a> — This is the top-level block that
+ contains the entire module, and describes a variety of per-module
+ information.</li>
+<li>9 — <a href="#PARAMATTR_BLOCK"><tt>PARAMATTR_BLOCK</tt></a> — This enumerates the parameter
+ attributes.</li>
+<li>10 — <a href="#TYPE_BLOCK"><tt>TYPE_BLOCK</tt></a> — This describes all of the types in
+ the module.</li>
+<li>11 — <a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a> — This describes constants for a
+ module or function.</li>
+<li>12 — <a href="#FUNCTION_BLOCK"><tt>FUNCTION_BLOCK</tt></a> — This describes a function
+ body.</li>
+<li>13 — <a href="#TYPE_SYMTAB_BLOCK"><tt>TYPE_SYMTAB_BLOCK</tt></a> — This describes the type symbol
+ table.</li>
+<li>14 — <a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a> — This describes a value symbol
+ table.</li>
+<li>15 — <a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a> — This describes metadata items.</li>
+<li>16 — <a href="#METADATA_ATTACHMENT"><tt>METADATA_ATTACHMENT</tt></a> — This contains records associating metadata with function instruction values.</li>
+</ul>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="MODULE_BLOCK">MODULE_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>MODULE_BLOCK</tt> block (id 8) is the top-level block for LLVM
+bitcode files, and each bitcode file must contain exactly one. In
+addition to records (described below) containing information
+about the module, a <tt>MODULE_BLOCK</tt> block may contain the
+following sub-blocks:
+</p>
+
+<ul>
+<li><a href="#BLOCKINFO"><tt>BLOCKINFO</tt></a></li>
+<li><a href="#PARAMATTR_BLOCK"><tt>PARAMATTR_BLOCK</tt></a></li>
+<li><a href="#TYPE_BLOCK"><tt>TYPE_BLOCK</tt></a></li>
+<li><a href="#TYPE_SYMTAB_BLOCK"><tt>TYPE_SYMTAB_BLOCK</tt></a></li>
+<li><a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a></li>
+<li><a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a></li>
+<li><a href="#FUNCTION_BLOCK"><tt>FUNCTION_BLOCK</tt></a></li>
+<li><a href="#METADATA_BLOCK"><tt>METADATA_BLOCK</tt></a></li>
+</ul>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_VERSION">MODULE_CODE_VERSION Record</a></h4>
+
+<div>
+
+<p><tt>[VERSION, version#]</tt></p>
+
+<p>The <tt>VERSION</tt> record (code 1) contains a single value
+indicating the format version. Only version 0 is supported at this
+time.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_TRIPLE">MODULE_CODE_TRIPLE Record</a></h4>
+
+<div>
+<p><tt>[TRIPLE, ...string...]</tt></p>
+
+<p>The <tt>TRIPLE</tt> record (code 2) contains a variable number of
+values representing the bytes of the <tt>target triple</tt>
+specification string.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_DATALAYOUT">MODULE_CODE_DATALAYOUT Record</a></h4>
+
+<div>
+<p><tt>[DATALAYOUT, ...string...]</tt></p>
+
+<p>The <tt>DATALAYOUT</tt> record (code 3) contains a variable number of
+values representing the bytes of the <tt>target datalayout</tt>
+specification string.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_ASM">MODULE_CODE_ASM Record</a></h4>
+
+<div>
+<p><tt>[ASM, ...string...]</tt></p>
+
+<p>The <tt>ASM</tt> record (code 4) contains a variable number of
+values representing the bytes of <tt>module asm</tt> strings, with
+individual assembly blocks separated by newline (ASCII 10) characters.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME Record</a></h4>
+
+<div>
+<p><tt>[SECTIONNAME, ...string...]</tt></p>
+
+<p>The <tt>SECTIONNAME</tt> record (code 5) contains a variable number
+of values representing the bytes of a single section name
+string. There should be one <tt>SECTIONNAME</tt> record for each
+section name referenced (e.g., in global variable or function
+<tt>section</tt> attributes) within the module. These records can be
+referenced by the 1-based index in the <i>section</i> fields of
+<tt>GLOBALVAR</tt> or <tt>FUNCTION</tt> records.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_DEPLIB">MODULE_CODE_DEPLIB Record</a></h4>
+
+<div>
+<p><tt>[DEPLIB, ...string...]</tt></p>
+
+<p>The <tt>DEPLIB</tt> record (code 6) contains a variable number of
+values representing the bytes of a single dependent library name
+string, one of the libraries mentioned in a <tt>deplibs</tt>
+declaration. There should be one <tt>DEPLIB</tt> record for each
+library name referenced.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_GLOBALVAR">MODULE_CODE_GLOBALVAR Record</a></h4>
+
+<div>
+<p><tt>[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal]</tt></p>
+
+<p>The <tt>GLOBALVAR</tt> record (code 7) marks the declaration or
+definition of a global variable. The operand fields are:</p>
+
+<ul>
+<li><i>pointer type</i>: The type index of the pointer type used to point to
+this global variable</li>
+
+<li><i>isconst</i>: Non-zero if the variable is treated as constant within
+the module, or zero if it is not</li>
+
+<li><i>initid</i>: If non-zero, the value index of the initializer for this
+variable, plus 1.</li>
+
+<li><a name="linkage"><i>linkage</i></a>: An encoding of the linkage
+type for this variable:
+ <ul>
+ <li><tt>external</tt>: code 0</li>
+ <li><tt>weak</tt>: code 1</li>
+ <li><tt>appending</tt>: code 2</li>
+ <li><tt>internal</tt>: code 3</li>
+ <li><tt>linkonce</tt>: code 4</li>
+ <li><tt>dllimport</tt>: code 5</li>
+ <li><tt>dllexport</tt>: code 6</li>
+ <li><tt>extern_weak</tt>: code 7</li>
+ <li><tt>common</tt>: code 8</li>
+ <li><tt>private</tt>: code 9</li>
+ <li><tt>weak_odr</tt>: code 10</li>
+ <li><tt>linkonce_odr</tt>: code 11</li>
+ <li><tt>available_externally</tt>: code 12</li>
+ <li><tt>linker_private</tt>: code 13</li>
+ </ul>
+</li>
+
+<li><i>alignment</i>: The logarithm base 2 of the variable's requested
+alignment, plus 1</li>
+
+<li><i>section</i>: If non-zero, the 1-based section index in the
+table of <a href="#MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME</a>
+entries.</li>
+
+<li><a name="visibility"><i>visibility</i></a>: If present, an
+encoding of the visibility of this variable:
+ <ul>
+ <li><tt>default</tt>: code 0</li>
+ <li><tt>hidden</tt>: code 1</li>
+ <li><tt>protected</tt>: code 2</li>
+ </ul>
+</li>
+
+<li><i>threadlocal</i>: If present and non-zero, indicates that the variable
+is <tt>thread_local</tt></li>
+
+<li><i>unnamed_addr</i>: If present and non-zero, indicates that the variable
+has <tt>unnamed_addr</tt></li>
+
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_FUNCTION">MODULE_CODE_FUNCTION Record</a></h4>
+
+<div>
+
+<p><tt>[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]</tt></p>
+
+<p>The <tt>FUNCTION</tt> record (code 8) marks the declaration or
+definition of a function. The operand fields are:</p>
+
+<ul>
+<li><i>type</i>: The type index of the function type describing this function</li>
+
+<li><i>callingconv</i>: The calling convention number:
+ <ul>
+ <li><tt>ccc</tt>: code 0</li>
+ <li><tt>fastcc</tt>: code 8</li>
+ <li><tt>coldcc</tt>: code 9</li>
+ <li><tt>x86_stdcallcc</tt>: code 64</li>
+ <li><tt>x86_fastcallcc</tt>: code 65</li>
+ <li><tt>arm_apcscc</tt>: code 66</li>
+ <li><tt>arm_aapcscc</tt>: code 67</li>
+ <li><tt>arm_aapcs_vfpcc</tt>: code 68</li>
+ </ul>
+</li>
+
+<li><i>isproto</i>: Non-zero if this entry represents a declaration
+rather than a definition</li>
+
+<li><i>linkage</i>: An encoding of the <a href="#linkage">linkage type</a>
+for this function</li>
+
+<li><i>paramattr</i>: If nonzero, the 1-based parameter attribute index
+into the table of <a href="#PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY</a>
+entries.</li>
+
+<li><i>alignment</i>: The logarithm base 2 of the function's requested
+alignment, plus 1</li>
+
+<li><i>section</i>: If non-zero, the 1-based section index in the
+table of <a href="#MODULE_CODE_SECTIONNAME">MODULE_CODE_SECTIONNAME</a>
+entries.</li>
+
+<li><i>visibility</i>: An encoding of the <a href="#visibility">visibility</a>
+ of this function</li>
+
+<li><i>gc</i>: If present and nonzero, the 1-based garbage collector
+index in the table of
+<a href="#MODULE_CODE_GCNAME">MODULE_CODE_GCNAME</a> entries.</li>
+
+<li><i>unnamed_addr</i>: If present and non-zero, indicates that the function
+has <tt>unnamed_addr</tt></li>
+
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_ALIAS">MODULE_CODE_ALIAS Record</a></h4>
+
+<div>
+
+<p><tt>[ALIAS, alias type, aliasee val#, linkage, visibility]</tt></p>
+
+<p>The <tt>ALIAS</tt> record (code 9) marks the definition of an
+alias. The operand fields are</p>
+
+<ul>
+<li><i>alias type</i>: The type index of the alias</li>
+
+<li><i>aliasee val#</i>: The value index of the aliased value</li>
+
+<li><i>linkage</i>: An encoding of the <a href="#linkage">linkage type</a>
+for this alias</li>
+
+<li><i>visibility</i>: If present, an encoding of the
+<a href="#visibility">visibility</a> of the alias</li>
+
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_PURGEVALS">MODULE_CODE_PURGEVALS Record</a></h4>
+
+<div>
+<p><tt>[PURGEVALS, numvals]</tt></p>
+
+<p>The <tt>PURGEVALS</tt> record (code 10) resets the module-level
+value list to the size given by the single operand value. Module-level
+value list items are added by <tt>GLOBALVAR</tt>, <tt>FUNCTION</tt>,
+and <tt>ALIAS</tt> records. After a <tt>PURGEVALS</tt> record is seen,
+new value indices will start from the given <i>numvals</i> value.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="MODULE_CODE_GCNAME">MODULE_CODE_GCNAME Record</a></h4>
+
+<div>
+<p><tt>[GCNAME, ...string...]</tt></p>
+
+<p>The <tt>GCNAME</tt> record (code 11) contains a variable number of
+values representing the bytes of a single garbage collector name
+string. There should be one <tt>GCNAME</tt> record for each garbage
+collector name referenced in function <tt>gc</tt> attributes within
+the module. These records can be referenced by 1-based index in the <i>gc</i>
+fields of <tt>FUNCTION</tt> records.</p>
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="PARAMATTR_BLOCK">PARAMATTR_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>PARAMATTR_BLOCK</tt> block (id 9) contains a table of
+entries describing the attributes of function parameters. These
+entries are referenced by 1-based index in the <i>paramattr</i> field
+of module block <a name="MODULE_CODE_FUNCTION"><tt>FUNCTION</tt></a>
+records, or within the <i>attr</i> field of function block <a
+href="#FUNC_CODE_INST_INVOKE"><tt>INST_INVOKE</tt></a> and <a
+href="#FUNC_CODE_INST_CALL"><tt>INST_CALL</tt></a> records.</p>
+
+<p>Entries within <tt>PARAMATTR_BLOCK</tt> are constructed to ensure
+that each is unique (i.e., no two indicies represent equivalent
+attribute lists). </p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="PARAMATTR_CODE_ENTRY">PARAMATTR_CODE_ENTRY Record</a></h4>
+
+<div>
+
+<p><tt>[ENTRY, paramidx0, attr0, paramidx1, attr1...]</tt></p>
+
+<p>The <tt>ENTRY</tt> record (code 1) contains an even number of
+values describing a unique set of function parameter attributes. Each
+<i>paramidx</i> value indicates which set of attributes is
+represented, with 0 representing the return value attributes,
+0xFFFFFFFF representing function attributes, and other values
+representing 1-based function parameters. Each <i>attr</i> value is a
+bitmap with the following interpretation:
+</p>
+
+<ul>
+<li>bit 0: <tt>zeroext</tt></li>
+<li>bit 1: <tt>signext</tt></li>
+<li>bit 2: <tt>noreturn</tt></li>
+<li>bit 3: <tt>inreg</tt></li>
+<li>bit 4: <tt>sret</tt></li>
+<li>bit 5: <tt>nounwind</tt></li>
+<li>bit 6: <tt>noalias</tt></li>
+<li>bit 7: <tt>byval</tt></li>
+<li>bit 8: <tt>nest</tt></li>
+<li>bit 9: <tt>readnone</tt></li>
+<li>bit 10: <tt>readonly</tt></li>
+<li>bit 11: <tt>noinline</tt></li>
+<li>bit 12: <tt>alwaysinline</tt></li>
+<li>bit 13: <tt>optsize</tt></li>
+<li>bit 14: <tt>ssp</tt></li>
+<li>bit 15: <tt>sspreq</tt></li>
+<li>bits 16–31: <tt>align <var>n</var></tt></li>
+<li>bit 32: <tt>nocapture</tt></li>
+<li>bit 33: <tt>noredzone</tt></li>
+<li>bit 34: <tt>noimplicitfloat</tt></li>
+<li>bit 35: <tt>naked</tt></li>
+<li>bit 36: <tt>inlinehint</tt></li>
+<li>bits 37–39: <tt>alignstack <var>n</var></tt>, represented as
+the logarithm base 2 of the requested alignment, plus 1</li>
+</ul>
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="TYPE_BLOCK">TYPE_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>TYPE_BLOCK</tt> block (id 10) contains records which
+constitute a table of type operator entries used to represent types
+referenced within an LLVM module. Each record (with the exception of
+<a href="#TYPE_CODE_NUMENTRY"><tt>NUMENTRY</tt></a>) generates a
+single type table entry, which may be referenced by 0-based index from
+instructions, constants, metadata, type symbol table entries, or other
+type operator records.
+</p>
+
+<p>Entries within <tt>TYPE_BLOCK</tt> are constructed to ensure that
+each entry is unique (i.e., no two indicies represent structurally
+equivalent types). </p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_NUMENTRY">TYPE_CODE_NUMENTRY Record</a></h4>
+
+<div>
+
+<p><tt>[NUMENTRY, numentries]</tt></p>
+
+<p>The <tt>NUMENTRY</tt> record (code 1) contains a single value which
+indicates the total number of type code entries in the type table of
+the module. If present, <tt>NUMENTRY</tt> should be the first record
+in the block.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_VOID">TYPE_CODE_VOID Record</a></h4>
+
+<div>
+
+<p><tt>[VOID]</tt></p>
+
+<p>The <tt>VOID</tt> record (code 2) adds a <tt>void</tt> type to the
+type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_FLOAT">TYPE_CODE_FLOAT Record</a></h4>
+
+<div>
+
+<p><tt>[FLOAT]</tt></p>
+
+<p>The <tt>FLOAT</tt> record (code 3) adds a <tt>float</tt> (32-bit
+floating point) type to the type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_DOUBLE">TYPE_CODE_DOUBLE Record</a></h4>
+
+<div>
+
+<p><tt>[DOUBLE]</tt></p>
+
+<p>The <tt>DOUBLE</tt> record (code 4) adds a <tt>double</tt> (64-bit
+floating point) type to the type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_LABEL">TYPE_CODE_LABEL Record</a></h4>
+
+<div>
+
+<p><tt>[LABEL]</tt></p>
+
+<p>The <tt>LABEL</tt> record (code 5) adds a <tt>label</tt> type to
+the type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_OPAQUE">TYPE_CODE_OPAQUE Record</a></h4>
+
+<div>
+
+<p><tt>[OPAQUE]</tt></p>
+
+<p>The <tt>OPAQUE</tt> record (code 6) adds an <tt>opaque</tt> type to
+the type table. Note that distinct <tt>opaque</tt> types are not
+unified.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_INTEGER">TYPE_CODE_INTEGER Record</a></h4>
+
+<div>
+
+<p><tt>[INTEGER, width]</tt></p>
+
+<p>The <tt>INTEGER</tt> record (code 7) adds an integer type to the
+type table. The single <i>width</i> field indicates the width of the
+integer type.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_POINTER">TYPE_CODE_POINTER Record</a></h4>
+
+<div>
+
+<p><tt>[POINTER, pointee type, address space]</tt></p>
+
+<p>The <tt>POINTER</tt> record (code 8) adds a pointer type to the
+type table. The operand fields are</p>
+
+<ul>
+<li><i>pointee type</i>: The type index of the pointed-to type</li>
+
+<li><i>address space</i>: If supplied, the target-specific numbered
+address space where the pointed-to object resides. Otherwise, the
+default address space is zero.
+</li>
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_FUNCTION">TYPE_CODE_FUNCTION Record</a></h4>
+
+<div>
+
+<p><tt>[FUNCTION, vararg, ignored, retty, ...paramty... ]</tt></p>
+
+<p>The <tt>FUNCTION</tt> record (code 9) adds a function type to the
+type table. The operand fields are</p>
+
+<ul>
+<li><i>vararg</i>: Non-zero if the type represents a varargs function</li>
+
+<li><i>ignored</i>: This value field is present for backward
+compatibility only, and is ignored</li>
+
+<li><i>retty</i>: The type index of the function's return type</li>
+
+<li><i>paramty</i>: Zero or more type indices representing the
+parameter types of the function</li>
+</ul>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_STRUCT">TYPE_CODE_STRUCT Record</a></h4>
+
+<div>
+
+<p><tt>[STRUCT, ispacked, ...eltty...]</tt></p>
+
+<p>The <tt>STRUCT </tt> record (code 10) adds a struct type to the
+type table. The operand fields are</p>
+
+<ul>
+<li><i>ispacked</i>: Non-zero if the type represents a packed structure</li>
+
+<li><i>eltty</i>: Zero or more type indices representing the element
+types of the structure</li>
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_ARRAY">TYPE_CODE_ARRAY Record</a></h4>
+
+<div>
+
+<p><tt>[ARRAY, numelts, eltty]</tt></p>
+
+<p>The <tt>ARRAY</tt> record (code 11) adds an array type to the type
+table. The operand fields are</p>
+
+<ul>
+<li><i>numelts</i>: The number of elements in arrays of this type</li>
+
+<li><i>eltty</i>: The type index of the array element type</li>
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_VECTOR">TYPE_CODE_VECTOR Record</a></h4>
+
+<div>
+
+<p><tt>[VECTOR, numelts, eltty]</tt></p>
+
+<p>The <tt>VECTOR</tt> record (code 12) adds a vector type to the type
+table. The operand fields are</p>
+
+<ul>
+<li><i>numelts</i>: The number of elements in vectors of this type</li>
+
+<li><i>eltty</i>: The type index of the vector element type</li>
+</ul>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_X86_FP80">TYPE_CODE_X86_FP80 Record</a></h4>
+
+<div>
+
+<p><tt>[X86_FP80]</tt></p>
+
+<p>The <tt>X86_FP80</tt> record (code 13) adds an <tt>x86_fp80</tt> (80-bit
+floating point) type to the type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_FP128">TYPE_CODE_FP128 Record</a></h4>
+
+<div>
+
+<p><tt>[FP128]</tt></p>
+
+<p>The <tt>FP128</tt> record (code 14) adds an <tt>fp128</tt> (128-bit
+floating point) type to the type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_PPC_FP128">TYPE_CODE_PPC_FP128 Record</a></h4>
+
+<div>
+
+<p><tt>[PPC_FP128]</tt></p>
+
+<p>The <tt>PPC_FP128</tt> record (code 15) adds a <tt>ppc_fp128</tt>
+(128-bit floating point) type to the type table.
+</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TYPE_CODE_METADATA">TYPE_CODE_METADATA Record</a></h4>
+
+<div>
+
+<p><tt>[METADATA]</tt></p>
+
+<p>The <tt>METADATA</tt> record (code 16) adds a <tt>metadata</tt>
+type to the type table.
+</p>
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="CONSTANTS_BLOCK">CONSTANTS_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>CONSTANTS_BLOCK</tt> block (id 11) ...
+</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="FUNCTION_BLOCK">FUNCTION_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>FUNCTION_BLOCK</tt> block (id 12) ...
+</p>
+
+<p>In addition to the record types described below, a
+<tt>FUNCTION_BLOCK</tt> block may contain the following sub-blocks:
+</p>
+
+<ul>
+<li><a href="#CONSTANTS_BLOCK"><tt>CONSTANTS_BLOCK</tt></a></li>
+<li><a href="#VALUE_SYMTAB_BLOCK"><tt>VALUE_SYMTAB_BLOCK</tt></a></li>
+<li><a href="#METADATA_ATTACHMENT"><tt>METADATA_ATTACHMENT</tt></a></li>
+</ul>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="TYPE_SYMTAB_BLOCK">TYPE_SYMTAB_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>TYPE_SYMTAB_BLOCK</tt> block (id 13) contains entries which
+map between module-level named types and their corresponding type
+indices.
+</p>
+
+<!-- _______________________________________________________________________ -->
+<h4><a name="TST_CODE_ENTRY">TST_CODE_ENTRY Record</a></h4>
+
+<div>
+
+<p><tt>[ENTRY, typeid, ...string...]</tt></p>
+
+<p>The <tt>ENTRY</tt> record (code 1) contains a variable number of
+values, with the first giving the type index of the designated type,
+and the remaining values giving the character codes of the type
+name. Each entry corresponds to a single named type.
+</p>
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="VALUE_SYMTAB_BLOCK">VALUE_SYMTAB_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>VALUE_SYMTAB_BLOCK</tt> block (id 14) ...
+</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="METADATA_BLOCK">METADATA_BLOCK Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>METADATA_BLOCK</tt> block (id 15) ...
+</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="METADATA_ATTACHMENT">METADATA_ATTACHMENT Contents</a>
+</h3>
+
+<div>
+
+<p>The <tt>METADATA_ATTACHMENT</tt> block (id 16) ...
+</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<hr>
+<address> <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+<a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+<a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br>
+Last modified: $Date: 2011-04-22 17:30:22 -0700 (Fri, 22 Apr 2011) $
+</address>
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/BranchWeightMetadata.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/BranchWeightMetadata.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/BranchWeightMetadata.html (added)
+++ www-releases/trunk/3.1/docs/BranchWeightMetadata.html Tue May 22 14:32:29 2012
@@ -0,0 +1,164 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>LLVM Branch Weight Metadata</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+<body>
+
+<h1>
+ LLVM Branch Weight Metadata
+</h1>
+
+<ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#supported_instructions">Supported Instructions</a></li>
+ <li><a href="#builtin_expect">Built-in "expect" Instruction </a></li>
+ <li><a href="#cfg_modifications">CFG Modifications</a></li>
+</ol>
+
+<div class="doc_author">
+ <p>Written by <a href="mailto:jstaszak at apple.com">Jakub Staszak</a></p>
+</div>
+
+<h2>
+ <a name="introduction">Introduction</a>
+</h2>
+<div>
+<p>Branch Weight Metadata represents branch weights as its likeliness to
+be taken. Metadata is assigned to the <tt>TerminatorInst</tt> as a
+<tt>MDNode</tt> of the <tt>MD_prof</tt> kind. The first operator is always a
+<tt>MDString</tt> node with the string "branch_weights". Number of operators
+depends on the terminator type.</p>
+
+<p>Branch weights might be fetch from the profiling file, or generated based on
+<a href="#builtin_expect"><tt>__builtin_expect</tt></a> instruction.
+</p>
+
+<p>All weights are represented as an unsigned 32-bit values, where higher value
+indicates greater chance to be taken.</p>
+</div>
+
+<h2>
+ <a name="supported_instructions">Supported Instructions</a>
+</h2>
+
+<div>
+ <h4>BranchInst</h4>
+ <div>
+ <p>Metadata is only assign to the conditional branches. There are two extra
+ operarands, for the true and the false branch.</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <TRUE_BRANCH_WEIGHT>,
+ i32 <FALSE_BRANCH_WEIGHT>
+}
+ </pre>
+ </div>
+
+ <h4>SwitchInst</h4>
+ <div>
+ <p>Branch weights are assign to every case (including <tt>default</tt> case
+ which is always case #0).</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <DEFAULT_BRANCH_WEIGHT>
+ [ , i32 <CASE_BRANCH_WEIGHT> ... ]
+}
+ </pre>
+ </div>
+
+ <h4>IndirectBrInst</h4>
+ <div>
+ <p>Branch weights are assign to every destination.</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+!0 = metadata !{
+ metadata !"branch_weights",
+ i32 <LABEL_BRANCH_WEIGHT>
+ [ , i32 <LABEL_BRANCH_WEIGHT> ... ]
+}
+ </pre>
+ </div>
+
+ <h4>Other</h4>
+ <div>
+ <p>Other terminator instructions are not allowed to contain Branch Weight
+ Metadata.</p>
+ </div>
+</div>
+
+<h2>
+ <a name="builtin_expect">Built-in "expect" Instructions</a>
+</h2>
+<div>
+ <p><tt>__builtin_expect(long exp, long c)</tt> instruction provides branch
+ prediction information. The return value is the value of <tt>exp</tt>.</p>
+
+ <p>It is especially useful in conditional statements. Currently Clang supports
+ two conditional statements:
+ </p>
+ <h4><tt>if</tt> statement</h4>
+ <div>
+ <p>The <tt>exp</tt> parameter is the condition. The <tt>c</tt> parameter is
+ the expected comparision value. If it is equal to 1 (true), the condition is
+ likely to be true, in other case condition is likely to be false. For example:
+ </p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ if (__builtin_expect(x > 0, 1)) {
+ // This block is likely to be taken.
+ }
+ </pre>
+ </div>
+
+ <h4><tt>switch</tt> statement</h4>
+ <div>
+ <p>The <tt>exp</tt> parameter is the value. The <tt>c</tt> parameter is the
+ expected value. If the expected value doesn't show on the cases list, the
+ <tt>default</tt> case is assumed to be likely taken.</p>
+ </div>
+ <div class="doc_code">
+ <pre>
+ switch (__builtin_expect(x, 5)) {
+ default: break;
+ case 0: // ...
+ case 3: // ...
+ case 5: // This case is likely to be taken.
+ }
+ </pre>
+ </div>
+</div>
+
+<h2>
+ <a name="cfg_modifications">CFG Modifications</a>
+</h2>
+<div>
+<p>Branch Weight Metatada is not proof against CFG changes. If terminator
+operands' are changed some action should be taken. In other case some
+misoptimizations may occur due to incorrent branch prediction information.</p>
+</div>
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:jstaszak at apple.com">Jakub Staszak</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/Bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/Bugpoint.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/Bugpoint.html (added)
+++ www-releases/trunk/3.1/docs/Bugpoint.html Tue May 22 14:32:29 2012
@@ -0,0 +1,239 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>LLVM bugpoint tool: design and usage</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+
+<h1>
+ LLVM bugpoint tool: design and usage
+</h1>
+
+<ul>
+ <li><a href="#desc">Description</a></li>
+ <li><a href="#design">Design Philosophy</a>
+ <ul>
+ <li><a href="#autoselect">Automatic Debugger Selection</a></li>
+ <li><a href="#crashdebug">Crash debugger</a></li>
+ <li><a href="#codegendebug">Code generator debugger</a></li>
+ <li><a href="#miscompilationdebug">Miscompilation debugger</a></li>
+ </ul></li>
+ <li><a href="#advice">Advice for using <tt>bugpoint</tt></a></li>
+</ul>
+
+<div class="doc_author">
+<p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+<a name="desc">Description</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p><tt>bugpoint</tt> narrows down the source of problems in LLVM tools and
+passes. It can be used to debug three types of failures: optimizer crashes,
+miscompilations by optimizers, or bad native code generation (including problems
+in the static and JIT compilers). It aims to reduce large test cases to small,
+useful ones. For example, if <tt>opt</tt> crashes while optimizing a
+file, it will identify the optimization (or combination of optimizations) that
+causes the crash, and reduce the file down to a small example which triggers the
+crash.</p>
+
+<p>For detailed case scenarios, such as debugging <tt>opt</tt>,
+<tt>llvm-ld</tt>, or one of the LLVM code generators, see <a
+href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+<a name="design">Design Philosophy</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p><tt>bugpoint</tt> is designed to be a useful tool without requiring any
+hooks into the LLVM infrastructure at all. It works with any and all LLVM
+passes and code generators, and does not need to "know" how they work. Because
+of this, it may appear to do stupid things or miss obvious
+simplifications. <tt>bugpoint</tt> is also designed to trade off programmer
+time for computer time in the compiler-debugging process; consequently, it may
+take a long period of (unattended) time to reduce a test case, but we feel it
+is still worth it. Note that <tt>bugpoint</tt> is generally very quick unless
+debugging a miscompilation where each test of the program (which requires
+executing it) takes a long time.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="autoselect">Automatic Debugger Selection</a>
+</h3>
+
+<div>
+
+<p><tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file specified on
+the command line and links them together into a single module, called the test
+program. If any LLVM passes are specified on the command line, it runs these
+passes on the test program. If any of the passes crash, or if they produce
+malformed output (which causes the verifier to abort), <tt>bugpoint</tt> starts
+the <a href="#crashdebug">crash debugger</a>.</p>
+
+<p>Otherwise, if the <tt>-output</tt> option was not specified,
+<tt>bugpoint</tt> runs the test program with the C backend (which is assumed to
+generate good code) to generate a reference output. Once <tt>bugpoint</tt> has
+a reference output for the test program, it tries executing it with the
+selected code generator. If the selected code generator crashes,
+<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a> on the
+code generator. Otherwise, if the resulting output differs from the reference
+output, it assumes the difference resulted from a code generator failure, and
+starts the <a href="#codegendebug">code generator debugger</a>.</p>
+
+<p>Finally, if the output of the selected code generator matches the reference
+output, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
+have been applied to it. If its output differs from the reference output, it
+assumes the difference resulted from a failure in one of the LLVM passes, and
+enters the <a href="#miscompilationdebug">miscompilation debugger</a>.
+Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="crashdebug">Crash debugger</a>
+</h3>
+
+<div>
+
+<p>If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard
+as it can to reduce the list of passes (for optimizer crashes) and the size of
+the test program. First, <tt>bugpoint</tt> figures out which combination of
+optimizer passes triggers the bug. This is useful when debugging a problem
+exposed by <tt>opt</tt>, for example, because it runs over 38 passes.</p>
+
+<p>Next, <tt>bugpoint</tt> tries removing functions from the test program, to
+reduce its size. Usually it is able to reduce a test program to a single
+function, when debugging intraprocedural optimizations. Once the number of
+functions has been reduced, it attempts to delete various edges in the control
+flow graph, to reduce the size of the function as much as possible. Finally,
+<tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
+not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
+passes crash, give you a bitcode file, and give you instructions on how to
+reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="codegendebug">Code generator debugger</a>
+</h3>
+
+<div>
+
+<p>The code generator debugger attempts to narrow down the amount of code that
+is being miscompiled by the selected code generator. To do this, it takes the
+test program and partitions it into two pieces: one piece which it compiles
+with the C backend (into a shared object), and one piece which it runs with
+either the JIT or the static LLC compiler. It uses several techniques to
+reduce the amount of code pushed through the LLVM code generator, to reduce the
+potential scope of the problem. After it is finished, it emits two bitcode
+files (called "test" [to be compiled with the code generator] and "safe" [to be
+compiled with the C backend], respectively), and instructions for reproducing
+the problem. The code generator debugger assumes that the C backend produces
+good code.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="miscompilationdebug">Miscompilation debugger</a>
+</h3>
+
+<div>
+
+<p>The miscompilation debugger works similarly to the code generator debugger.
+It works by splitting the test program into two pieces, running the
+optimizations specified on one piece, linking the two pieces back together, and
+then executing the result. It attempts to narrow down the list of passes to
+the one (or few) which are causing the miscompilation, then reduce the portion
+of the test program which is being miscompiled. The miscompilation debugger
+assumes that the selected code generator is working properly.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="advice">Advice for using bugpoint</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<tt>bugpoint</tt> can be a remarkably useful tool, but it sometimes works in
+non-obvious ways. Here are some hints and tips:<p>
+
+<ol>
+<li>In the code generator and miscompilation debuggers, <tt>bugpoint</tt> only
+ works with programs that have deterministic output. Thus, if the program
+ outputs <tt>argv[0]</tt>, the date, time, or any other "random" data,
+ <tt>bugpoint</tt> may misinterpret differences in these data, when output,
+ as the result of a miscompilation. Programs should be temporarily modified
+ to disable outputs that are likely to vary from run to run.
+
+<li>In the code generator and miscompilation debuggers, debugging will go
+ faster if you manually modify the program or its inputs to reduce the
+ runtime, but still exhibit the problem.
+
+<li><tt>bugpoint</tt> is extremely useful when working on a new optimization:
+ it helps track down regressions quickly. To avoid having to relink
+ <tt>bugpoint</tt> every time you change your optimization however, have
+ <tt>bugpoint</tt> dynamically load your optimization with the
+ <tt>-load</tt> option.
+
+<li><p><tt>bugpoint</tt> can generate a lot of output and run for a long period
+ of time. It is often useful to capture the output of the program to file.
+ For example, in the C shell, you can run:</p>
+
+<div class="doc_code">
+<p><tt>bugpoint ... |& tee bugpoint.log</tt></p>
+</div>
+
+ <p>to get a copy of <tt>bugpoint</tt>'s output in the file
+ <tt>bugpoint.log</tt>, as well as on your terminal.</p>
+
+<li><tt>bugpoint</tt> cannot debug problems with the LLVM linker. If
+ <tt>bugpoint</tt> crashes before you see its "All input ok" message,
+ you might try <tt>llvm-link -v</tt> on the same set of input files. If
+ that also crashes, you may be experiencing a linker bug.
+
+<li><tt>bugpoint</tt> is useful for proactively finding bugs in LLVM.
+ Invoking <tt>bugpoint</tt> with the <tt>-find-bugs</tt> option will cause
+ the list of specified optimizations to be randomized and applied to the
+ program. This process will repeat until a bug is found or the user
+ kills <tt>bugpoint</tt>.
+</ol>
+
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2011-10-31 04:21:59 -0700 (Mon, 31 Oct 2011) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/CMake.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CMake.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CMake.html (added)
+++ www-releases/trunk/3.1/docs/CMake.html Tue May 22 14:32:29 2012
@@ -0,0 +1,584 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>Building LLVM with CMake</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+</head>
+
+<h1>
+ Building LLVM with CMake
+</h1>
+
+<ul>
+ <li><a href="#intro">Introduction</a></li>
+ <li><a href="#quickstart">Quick start</a></li>
+ <li><a href="#usage">Basic CMake usage</a>
+ <li><a href="#options">Options and variables</a>
+ <ul>
+ <li><a href="#freccmake">Frequently-used CMake variables</a></li>
+ <li><a href="#llvmvars">LLVM-specific variables</a></li>
+ </ul></li>
+ <li><a href="#testing">Executing the test suite</a>
+ <li><a href="#cross">Cross compiling</a>
+ <li><a href="#embedding">Embedding LLVM in your project</a>
+ <ul>
+ <li><a href="#passdev">Developing LLVM pass out of source</a></li>
+ </ul></li>
+ <li><a href="#specifics">Compiler/Platform specific topics</a>
+ <ul>
+ <li><a href="#msvc">Microsoft Visual C++</a></li>
+ </ul></li>
+</ul>
+
+<div class="doc_author">
+<p>Written by <a href="mailto:ofv at wanadoo.es">Oscar Fuentes</a></p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+<a name="intro">Introduction</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+ <p><a href="http://www.cmake.org/">CMake</a> is a cross-platform
+ build-generator tool. CMake does not build the project, it generates
+ the files needed by your build tool (GNU make, Visual Studio, etc) for
+ building LLVM.</p>
+
+ <p>If you are really anxious about getting a functional LLVM build,
+ go to the <a href="#quickstart">Quick start</a> section. If you
+ are a CMake novice, start on <a href="#usage">Basic CMake
+ usage</a> and then go back to the <a href="#quickstart">Quick
+ start</a> once you know what you are
+ doing. The <a href="#options">Options and variables</a> section
+ is a reference for customizing your build. If you already have
+ experience with CMake, this is the recommended starting point.
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+<a name="quickstart">Quick start</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p> We use here the command-line, non-interactive CMake interface </p>
+
+<ol>
+
+ <li><p><a href="http://www.cmake.org/cmake/resources/software.html">Download</a>
+ and install CMake. Version 2.8 is the minimum required.</p>
+
+ <li><p>Open a shell. Your development tools must be reachable from this
+ shell through the PATH environment variable.</p>
+
+ <li><p>Create a directory for containing the build. It is not
+ supported to build LLVM on the source directory. cd to this
+ directory:</p>
+ <div class="doc_code">
+ <p><tt>mkdir mybuilddir</tt></p>
+ <p><tt>cd mybuilddir</tt></p>
+ </div>
+
+ <li><p>Execute this command on the shell
+ replacing <i>path/to/llvm/source/root</i> with the path to the
+ root of your LLVM source tree:</p>
+ <div class="doc_code">
+ <p><tt>cmake path/to/llvm/source/root</tt></p>
+ </div>
+
+ <p>CMake will detect your development environment, perform a
+ series of test and generate the files required for building
+ LLVM. CMake will use default values for all build
+ parameters. See the <a href="#options">Options and variables</a>
+ section for fine-tuning your build</p>
+
+ <p>This can fail if CMake can't detect your toolset, or if it
+ thinks that the environment is not sane enough. On this case
+ make sure that the toolset that you intend to use is the only
+ one reachable from the shell and that the shell itself is the
+ correct one for you development environment. CMake will refuse
+ to build MinGW makefiles if you have a POSIX shell reachable
+ through the PATH environment variable, for instance. You can
+ force CMake to use a given build tool, see
+ the <a href="#usage">Usage</a> section.</p>
+
+</ol>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="usage">Basic CMake usage</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+ <p>This section explains basic aspects of CMake, mostly for
+ explaining those options which you may need on your day-to-day
+ usage.</p>
+
+ <p>CMake comes with extensive documentation in the form of html
+ files and on the cmake executable itself. Execute <i>cmake
+ --help</i> for further help options.</p>
+
+ <p>CMake requires to know for which build tool it shall generate
+ files (GNU make, Visual Studio, Xcode, etc). If not specified on
+ the command line, it tries to guess it based on you
+ environment. Once identified the build tool, CMake uses the
+ corresponding <i>Generator</i> for creating files for your build
+ tool. You can explicitly specify the generator with the command
+ line option <i>-G "Name of the generator"</i>. For knowing the
+ available generators on your platform, execute</p>
+
+ <div class="doc_code">
+ <p><tt>cmake --help</tt></p>
+ </div>
+
+ <p>This will list the generator's names at the end of the help
+ text. Generator's names are case-sensitive. Example:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -G "Visual Studio 9 2008" path/to/llvm/source/root</tt></p>
+ </div>
+
+ <p>For a given development platform there can be more than one
+ adequate generator. If you use Visual Studio "NMake Makefiles"
+ is a generator you can use for building with NMake. By default,
+ CMake chooses the more specific generator supported by your
+ development environment. If you want an alternative generator,
+ you must tell this to CMake with the <i>-G</i> option.</p>
+
+ <p>TODO: explain variables and cache. Move explanation here from
+ #options section.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="options">Options and variables</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+ <p>Variables customize how the build will be generated. Options are
+ boolean variables, with possible values ON/OFF. Options and
+ variables are defined on the CMake command line like this:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -DVARIABLE=value path/to/llvm/source</tt></p>
+ </div>
+
+ <p>You can set a variable after the initial CMake invocation for
+ changing its value. You can also undefine a variable:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -UVARIABLE path/to/llvm/source</tt></p>
+ </div>
+
+ <p>Variables are stored on the CMake cache. This is a file
+ named <tt>CMakeCache.txt</tt> on the root of the build
+ directory. Do not hand-edit it.</p>
+
+ <p>Variables are listed here appending its type after a colon. It is
+ correct to write the variable and the type on the CMake command
+ line:</p>
+
+ <div class="doc_code">
+ <p><tt>cmake -DVARIABLE:TYPE=value path/to/llvm/source</tt></p>
+ </div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="freccmake">Frequently-used CMake variables</a>
+</h3>
+
+<div>
+
+<p>Here are listed some of the CMake variables that are used often,
+ along with a brief explanation and LLVM-specific notes. For full
+ documentation, check the CMake docs or execute <i>cmake
+ --help-variable VARIABLE_NAME</i>.</p>
+
+<dl>
+ <dt><b>CMAKE_BUILD_TYPE</b>:STRING</dt>
+
+ <dd>Sets the build type for <i>make</i> based generators. Possible
+ values are Release, Debug, RelWithDebInfo and MinSizeRel. On
+ systems like Visual Studio the user sets the build type with the IDE
+ settings.</dd>
+
+ <dt><b>CMAKE_INSTALL_PREFIX</b>:PATH</dt>
+ <dd>Path where LLVM will be installed if "make install" is invoked
+ or the "INSTALL" target is built.</dd>
+
+ <dt><b>LLVM_LIBDIR_SUFFIX</b>:STRING</dt>
+ <dd>Extra suffix to append to the directory where libraries are to
+ be installed. On a 64-bit architecture, one could use
+ -DLLVM_LIBDIR_SUFFIX=64 to install libraries to /usr/lib64.</dd>
+
+ <dt><b>CMAKE_C_FLAGS</b>:STRING</dt>
+ <dd>Extra flags to use when compiling C source files.</dd>
+
+ <dt><b>CMAKE_CXX_FLAGS</b>:STRING</dt>
+ <dd>Extra flags to use when compiling C++ source files.</dd>
+
+ <dt><b>BUILD_SHARED_LIBS</b>:BOOL</dt>
+ <dd>Flag indicating is shared libraries will be built. Its default
+ value is OFF. Shared libraries are not supported on Windows and
+ not recommended in the other OSes.</dd>
+</dl>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="llvmvars">LLVM-specific variables</a>
+</h3>
+
+<div>
+
+<dl>
+ <dt><b>LLVM_TARGETS_TO_BUILD</b>:STRING</dt>
+ <dd>Semicolon-separated list of targets to build, or <i>all</i> for
+ building all targets. Case-sensitive. For Visual C++ defaults
+ to <i>X86</i>. On the other cases defaults to <i>all</i>. Example:
+ <i>-DLLVM_TARGETS_TO_BUILD="X86;PowerPC"</i>.</dd>
+
+ <dt><b>LLVM_BUILD_TOOLS</b>:BOOL</dt>
+ <dd>Build LLVM tools. Defaults to ON. Targets for building each tool
+ are generated in any case. You can build an tool separately by
+ invoking its target. For example, you can build <i>llvm-as</i>
+ with a makefile-based system executing <i>make llvm-as</i> on the
+ root of your build directory.</dd>
+
+ <dt><b>LLVM_INCLUDE_TOOLS</b>:BOOL</dt>
+ <dd>Generate build targets for the LLVM tools. Defaults to
+ ON. You can use that option for disabling the generation of build
+ targets for the LLVM tools.</dd>
+
+ <dt><b>LLVM_BUILD_EXAMPLES</b>:BOOL</dt>
+ <dd>Build LLVM examples. Defaults to OFF. Targets for building each
+ example are generated in any case. See documentation
+ for <i>LLVM_BUILD_TOOLS</i> above for more details.</dd>
+
+ <dt><b>LLVM_INCLUDE_EXAMPLES</b>:BOOL</dt>
+ <dd>Generate build targets for the LLVM examples. Defaults to
+ ON. You can use that option for disabling the generation of build
+ targets for the LLVM examples.</dd>
+
+ <dt><b>LLVM_BUILD_TESTS</b>:BOOL</dt>
+ <dd>Build LLVM unit tests. Defaults to OFF. Targets for building
+ each unit test are generated in any case. You can build a specific
+ unit test with the target <i>UnitTestNameTests</i> (where at this
+ time <i>UnitTestName</i> can be ADT, Analysis, ExecutionEngine,
+ JIT, Support, Transform, VMCore; see the subdirectories
+ of <i>unittests</i> for an updated list.) It is possible to build
+ all unit tests with the target <i>UnitTests</i>.</dd>
+
+ <dt><b>LLVM_INCLUDE_TESTS</b>:BOOL</dt>
+ <dd>Generate build targets for the LLVM unit tests. Defaults to
+ ON. You can use that option for disabling the generation of build
+ targets for the LLVM unit tests.</dd>
+
+ <dt><b>LLVM_APPEND_VC_REV</b>:BOOL</dt>
+ <dd>Append version control revision info (svn revision number or git
+ revision id) to LLVM version string (stored in the PACKAGE_VERSION
+ macro). For this to work cmake must be invoked before the
+ build. Defaults to OFF.</dd>
+
+ <dt><b>LLVM_ENABLE_THREADS</b>:BOOL</dt>
+ <dd>Build with threads support, if available. Defaults to ON.</dd>
+
+ <dt><b>LLVM_ENABLE_ASSERTIONS</b>:BOOL</dt>
+ <dd>Enables code assertions. Defaults to OFF if and only if
+ CMAKE_BUILD_TYPE is <i>Release</i>.</dd>
+
+ <dt><b>LLVM_ENABLE_PIC</b>:BOOL</dt>
+ <dd>Add the <i>-fPIC</i> flag for the compiler command-line, if the
+ compiler supports this flag. Some systems, like Windows, do not
+ need this flag. Defaults to ON.</dd>
+
+ <dt><b>LLVM_ENABLE_WARNINGS</b>:BOOL</dt>
+ <dd>Enable all compiler warnings. Defaults to ON.</dd>
+
+ <dt><b>LLVM_ENABLE_PEDANTIC</b>:BOOL</dt>
+ <dd>Enable pedantic mode. This disable compiler specific extensions, is
+ possible. Defaults to ON.</dd>
+
+ <dt><b>LLVM_ENABLE_WERROR</b>:BOOL</dt>
+ <dd>Stop and fail build, if a compiler warning is
+ triggered. Defaults to OFF.</dd>
+
+ <dt><b>LLVM_BUILD_32_BITS</b>:BOOL</dt>
+ <dd>Build 32-bits executables and libraries on 64-bits systems. This
+ option is available only on some 64-bits unix systems. Defaults to
+ OFF.</dd>
+
+ <dt><b>LLVM_TARGET_ARCH</b>:STRING</dt>
+ <dd>LLVM target to use for native code generation. This is required
+ for JIT generation. It defaults to "host", meaning that it shall
+ pick the architecture of the machine where LLVM is being built. If
+ you are cross-compiling, set it to the target architecture
+ name.</dd>
+
+ <dt><b>LLVM_TABLEGEN</b>:STRING</dt>
+ <dd>Full path to a native TableGen executable (usually
+ named <i>tblgen</i>). This is intented for cross-compiling: if the
+ user sets this variable, no native TableGen will be created.</dd>
+
+ <dt><b>LLVM_LIT_ARGS</b>:STRING</dt>
+ <dd>Arguments given to lit.
+ <tt>make check</tt> and <tt>make clang-test</tt> are affected.
+ By default, <tt>"-sv --no-progress-bar"</tt>
+ on Visual C++ and Xcode,
+ <tt>"-sv"</tt> on others.</dd>
+
+ <dt><b>LLVM_LIT_TOOLS_DIR</b>:PATH</dt>
+ <dd>The path to GnuWin32 tools for tests. Valid on Windows host.
+ Defaults to "", then Lit seeks tools according to %PATH%.
+ Lit can find tools(eg. grep, sort, &c) on LLVM_LIT_TOOLS_DIR at first,
+ without specifying GnuWin32 to %PATH%.</dd>
+
+ <dt><b>LLVM_ENABLE_FFI</b>:BOOL</dt>
+ <dd>Indicates whether LLVM Interpreter will be linked with Foreign
+ Function Interface library. If the library or its headers are
+ installed on a custom location, you can set the variables
+ FFI_INCLUDE_DIR and FFI_LIBRARY_DIR. Defaults to OFF.</dd>
+
+ <dt><b>LLVM_CLANG_SOURCE_DIR</b>:PATH</dt>
+ <dd>Path to Clang's source directory. Defaults to tools/clang.
+ Clang will not be built when it is empty or it does not point valid
+ path.</dd>
+
+ <dt><b>LLVM_USE_OPROFILE</b>:BOOL</dt>
+ <dd> Enable building OProfile JIT support. Defaults to OFF</dd>
+
+ <dt><b>LLVM_USE_INTEL_JITEVENTS</b>:BOOL</dt>
+ <dd> Enable building support for Intel JIT Events API. Defaults to OFF</dd>
+
+ <dt><b>LLVM_INTEL_JITEVENTS_DIR</b>:PATH</dt>
+ <dd> Path to installation of Intel(R) VTune(TM) Amplifier XE 2011,
+ used to locate the <tt>jitprofiling</tt> library. Default =
+ <tt>%VTUNE_AMPLIFIER_XE_2011_DIR%</tt> (Windows)
+ | <tt>/opt/intel/vtune_amplifier_xe_2011</tt> (Linux) </dd>
+
+</dl>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="testing">Executing the test suite</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Testing is performed when the <i>check</i> target is built. For
+ instance, if you are using makefiles, execute this command while on
+ the top level of your build directory:</p>
+
+<div class="doc_code">
+ <p><tt>make check</tt></p>
+</div>
+
+<p>On Visual Studio, you may run tests to build the project "check".</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="cross">Cross compiling</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>See <a href="http://www.vtk.org/Wiki/CMake_Cross_Compiling">this
+ wiki page</a> for generic instructions on how to cross-compile
+ with CMake. It goes into detailed explanations and may seem
+ daunting, but it is not. On the wiki page there are several
+ examples including toolchain files. Go directly to
+ <a href="http://www.vtk.org/Wiki/CMake_Cross_Compiling#Information_how_to_set_up_various_cross_compiling_toolchains">this
+ section</a> for a quick solution.</p>
+
+<p>Also see the <a href="#llvmvars">LLVM-specific variables</a>
+ section for variables used when cross-compiling.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="embedding">Embedding LLVM in your project</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+ <p>The most difficult part of adding LLVM to the build of a project
+ is to determine the set of LLVM libraries corresponding to the set
+ of required LLVM features. What follows is an example of how to
+ obtain this information:</p>
+
+ <div class="doc_code">
+ <pre>
+ <b># A convenience variable:</b>
+ set(LLVM_ROOT "" CACHE PATH "Root of LLVM install.")
+ <b># A bit of a sanity check:</b>
+ if( NOT EXISTS ${LLVM_ROOT}/include/llvm )
+ message(FATAL_ERROR "LLVM_ROOT (${LLVM_ROOT}) is not a valid LLVM install")
+ endif()
+ <b># We incorporate the CMake features provided by LLVM:</b>
+ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${LLVM_ROOT}/share/llvm/cmake")
+ include(LLVMConfig)
+ <b># Now set the header and library paths:</b>
+ include_directories( ${LLVM_INCLUDE_DIRS} )
+ link_directories( ${LLVM_LIBRARY_DIRS} )
+ add_definitions( ${LLVM_DEFINITIONS} )
+ <b># Let's suppose we want to build a JIT compiler with support for
+ # binary code (no interpreter):</b>
+ llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native)
+ <b># Finally, we link the LLVM libraries to our executable:</b>
+ target_link_libraries(mycompiler ${REQ_LLVM_LIBRARIES})
+ </pre>
+ </div>
+
+ <p>This assumes that LLVM_ROOT points to an install of LLVM. The
+ procedure works too for uninstalled builds although we need to take
+ care to add an <i>include_directories</i> for the location of the
+ headers on the LLVM source directory (if we are building
+ out-of-source.)</p>
+
+ <p>Alternativaly, you can utilize CMake's <i>find_package</i>
+ functionality. Here is an equivalent variant of snippet shown above:</p>
+
+ <div class="doc_code">
+ <pre>
+ find_package(LLVM)
+
+ if( NOT LLVM_FOUND )
+ message(FATAL_ERROR "LLVM package can't be found. Set CMAKE_PREFIX_PATH variable to LLVM's installation prefix.")
+ endif()
+
+ include_directories( ${LLVM_INCLUDE_DIRS} )
+ link_directories( ${LLVM_LIBRARY_DIRS} )
+
+ llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native)
+
+ target_link_libraries(mycompiler ${REQ_LLVM_LIBRARIES})
+ </pre>
+ </div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="passdev">Developing LLVM pass out of source</a>
+</h3>
+
+<div>
+
+ <p>It is possible to develop LLVM passes against installed LLVM.
+ An example of project layout provided below:</p>
+
+ <div class="doc_code">
+ <pre>
+ <project dir>/
+ |
+ CMakeLists.txt
+ <pass name>/
+ |
+ CMakeLists.txt
+ Pass.cpp
+ ...
+ </pre>
+ </div>
+
+ <p>Contents of <project dir>/CMakeLists.txt:</p>
+
+ <div class="doc_code">
+ <pre>
+ find_package(LLVM)
+
+ <b># Define add_llvm_* macro's.</b>
+ include(AddLLVM)
+
+ add_definitions(${LLVM_DEFINITIONS})
+ include_directories(${LLVM_INCLUDE_DIRS})
+ link_directories(${LLVM_LIBRARY_DIRS})
+
+ add_subdirectory(<pass name>)
+ </pre>
+ </div>
+
+ <p>Contents of <project dir>/<pass name>/CMakeLists.txt:</p>
+
+ <div class="doc_code">
+ <pre>
+ add_llvm_loadable_module(LLVMPassname
+ Pass.cpp
+ )
+ </pre>
+ </div>
+
+ <p>When you are done developing your pass, you may wish to integrate it
+ into LLVM source tree. You can achieve it in two easy steps:<br>
+ 1. Copying <pass name> folder into <LLVM root>/lib/Transform directory.<br>
+ 2. Adding "add_subdirectory(<pass name>)" line into <LLVM root>/lib/Transform/CMakeLists.txt</p>
+</div>
+<!-- *********************************************************************** -->
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="specifics">Compiler/Platform specific topics</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Notes for specific compilers and/or platforms.</p>
+
+<h3>
+ <a name="msvc">Microsoft Visual C++</a>
+</h3>
+
+<div>
+
+<dl>
+ <dt><b>LLVM_COMPILER_JOBS</b>:STRING</dt>
+ <dd>Specifies the maximum number of parallell compiler jobs to use
+ per project when building with msbuild or Visual Studio. Only supported for
+ Visual Studio 2008 and Visual Studio 2010 CMake generators. 0 means use all
+ processors. Default is 0.</dd>
+</dl>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:ofv at wanadoo.es">Oscar Fuentes</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2010-08-09 03:59:36 +0100 (Mon, 9 Aug 2010) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/CodeGenerator.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CodeGenerator.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CodeGenerator.html (added)
+++ www-releases/trunk/3.1/docs/CodeGenerator.html Tue May 22 14:32:29 2012
@@ -0,0 +1,3189 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="content-type" content="text/html; charset=utf-8">
+ <title>The LLVM Target-Independent Code Generator</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+
+ <style type="text/css">
+ .unknown { background-color: #C0C0C0; text-align: center; }
+ .unknown:before { content: "?" }
+ .no { background-color: #C11B17 }
+ .no:before { content: "N" }
+ .partial { background-color: #F88017 }
+ .yes { background-color: #0F0; }
+ .yes:before { content: "Y" }
+ </style>
+
+</head>
+<body>
+
+<h1>
+ The LLVM Target-Independent Code Generator
+</h1>
+
+<ol>
+ <li><a href="#introduction">Introduction</a>
+ <ul>
+ <li><a href="#required">Required components in the code generator</a></li>
+ <li><a href="#high-level-design">The high-level design of the code
+ generator</a></li>
+ <li><a href="#tablegen">Using TableGen for target description</a></li>
+ </ul>
+ </li>
+ <li><a href="#targetdesc">Target description classes</a>
+ <ul>
+ <li><a href="#targetmachine">The <tt>TargetMachine</tt> class</a></li>
+ <li><a href="#targetdata">The <tt>TargetData</tt> class</a></li>
+ <li><a href="#targetlowering">The <tt>TargetLowering</tt> class</a></li>
+ <li><a href="#targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a></li>
+ <li><a href="#targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a></li>
+ <li><a href="#targetframeinfo">The <tt>TargetFrameInfo</tt> class</a></li>
+ <li><a href="#targetsubtarget">The <tt>TargetSubtarget</tt> class</a></li>
+ <li><a href="#targetjitinfo">The <tt>TargetJITInfo</tt> class</a></li>
+ </ul>
+ </li>
+ <li><a href="#codegendesc">The "Machine" Code Generator classes</a>
+ <ul>
+ <li><a href="#machineinstr">The <tt>MachineInstr</tt> class</a></li>
+ <li><a href="#machinebasicblock">The <tt>MachineBasicBlock</tt>
+ class</a></li>
+ <li><a href="#machinefunction">The <tt>MachineFunction</tt> class</a></li>
+ <li><a href="#machineinstrbundle"><tt>MachineInstr Bundles</tt></a></li>
+ </ul>
+ </li>
+ <li><a href="#mc">The "MC" Layer</a>
+ <ul>
+ <li><a href="#mcstreamer">The <tt>MCStreamer</tt> API</a></li>
+ <li><a href="#mccontext">The <tt>MCContext</tt> class</a>
+ <li><a href="#mcsymbol">The <tt>MCSymbol</tt> class</a></li>
+ <li><a href="#mcsection">The <tt>MCSection</tt> class</a></li>
+ <li><a href="#mcinst">The <tt>MCInst</tt> class</a></li>
+ </ul>
+ </li>
+ <li><a href="#codegenalgs">Target-independent code generation algorithms</a>
+ <ul>
+ <li><a href="#instselect">Instruction Selection</a>
+ <ul>
+ <li><a href="#selectiondag_intro">Introduction to SelectionDAGs</a></li>
+ <li><a href="#selectiondag_process">SelectionDAG Code Generation
+ Process</a></li>
+ <li><a href="#selectiondag_build">Initial SelectionDAG
+ Construction</a></li>
+ <li><a href="#selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a></li>
+ <li><a href="#selectiondag_legalize">SelectionDAG Legalize Phase</a></li>
+ <li><a href="#selectiondag_optimize">SelectionDAG Optimization
+ Phase: the DAG Combiner</a></li>
+ <li><a href="#selectiondag_select">SelectionDAG Select Phase</a></li>
+ <li><a href="#selectiondag_sched">SelectionDAG Scheduling and Formation
+ Phase</a></li>
+ <li><a href="#selectiondag_future">Future directions for the
+ SelectionDAG</a></li>
+ </ul></li>
+ <li><a href="#liveintervals">Live Intervals</a>
+ <ul>
+ <li><a href="#livevariable_analysis">Live Variable Analysis</a></li>
+ <li><a href="#liveintervals_analysis">Live Intervals Analysis</a></li>
+ </ul></li>
+ <li><a href="#regalloc">Register Allocation</a>
+ <ul>
+ <li><a href="#regAlloc_represent">How registers are represented in
+ LLVM</a></li>
+ <li><a href="#regAlloc_howTo">Mapping virtual registers to physical
+ registers</a></li>
+ <li><a href="#regAlloc_twoAddr">Handling two address instructions</a></li>
+ <li><a href="#regAlloc_ssaDecon">The SSA deconstruction phase</a></li>
+ <li><a href="#regAlloc_fold">Instruction folding</a></li>
+ <li><a href="#regAlloc_builtIn">Built in register allocators</a></li>
+ </ul></li>
+ <li><a href="#codeemit">Code Emission</a></li>
+ <li><a href="#vliw_packetizer">VLIW Packetizer</a>
+ <ul>
+ <li><a href="#vliw_mapping">Mapping from instructions to functional
+ units</a></li>
+ <li><a href="#vliw_repr">How the packetization tables are
+ generated and used</a></li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li><a href="#nativeassembler">Implementing a Native Assembler</a></li>
+
+ <li><a href="#targetimpls">Target-specific Implementation Notes</a>
+ <ul>
+ <li><a href="#targetfeatures">Target Feature Matrix</a></li>
+ <li><a href="#tailcallopt">Tail call optimization</a></li>
+ <li><a href="#sibcallopt">Sibling call optimization</a></li>
+ <li><a href="#x86">The X86 backend</a></li>
+ <li><a href="#ppc">The PowerPC backend</a>
+ <ul>
+ <li><a href="#ppc_abi">LLVM PowerPC ABI</a></li>
+ <li><a href="#ppc_frame">Frame Layout</a></li>
+ <li><a href="#ppc_prolog">Prolog/Epilog</a></li>
+ <li><a href="#ppc_dynamic">Dynamic Allocation</a></li>
+ </ul></li>
+ <li><a href="#ptx">The PTX backend</a></li>
+ </ul></li>
+
+</ol>
+
+<div class="doc_author">
+ <p>Written by the LLVM Team.</p>
+</div>
+
+<div class="doc_warning">
+ <p>Warning: This is a work in progress.</p>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="introduction">Introduction</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>The LLVM target-independent code generator is a framework that provides a
+ suite of reusable components for translating the LLVM internal representation
+ to the machine code for a specified target—either in assembly form
+ (suitable for a static compiler) or in binary machine code format (usable for
+ a JIT compiler). The LLVM target-independent code generator consists of six
+ main components:</p>
+
+<ol>
+ <li><a href="#targetdesc">Abstract target description</a> interfaces which
+ capture important properties about various aspects of the machine,
+ independently of how they will be used. These interfaces are defined in
+ <tt>include/llvm/Target/</tt>.</li>
+
+ <li>Classes used to represent the <a href="#codegendesc">code being
+ generated</a> for a target. These classes are intended to be abstract
+ enough to represent the machine code for <i>any</i> target machine. These
+ classes are defined in <tt>include/llvm/CodeGen/</tt>. At this level,
+ concepts like "constant pool entries" and "jump tables" are explicitly
+ exposed.</li>
+
+ <li>Classes and algorithms used to represent code as the object file level,
+ the <a href="#mc">MC Layer</a>. These classes represent assembly level
+ constructs like labels, sections, and instructions. At this level,
+ concepts like "constant pool entries" and "jump tables" don't exist.</li>
+
+ <li><a href="#codegenalgs">Target-independent algorithms</a> used to implement
+ various phases of native code generation (register allocation, scheduling,
+ stack frame representation, etc). This code lives
+ in <tt>lib/CodeGen/</tt>.</li>
+
+ <li><a href="#targetimpls">Implementations of the abstract target description
+ interfaces</a> for particular targets. These machine descriptions make
+ use of the components provided by LLVM, and can optionally provide custom
+ target-specific passes, to build complete code generators for a specific
+ target. Target descriptions live in <tt>lib/Target/</tt>.</li>
+
+ <li><a href="#jit">The target-independent JIT components</a>. The LLVM JIT is
+ completely target independent (it uses the <tt>TargetJITInfo</tt>
+ structure to interface for target-specific issues. The code for the
+ target-independent JIT lives in <tt>lib/ExecutionEngine/JIT</tt>.</li>
+</ol>
+
+<p>Depending on which part of the code generator you are interested in working
+ on, different pieces of this will be useful to you. In any case, you should
+ be familiar with the <a href="#targetdesc">target description</a>
+ and <a href="#codegendesc">machine code representation</a> classes. If you
+ want to add a backend for a new target, you will need
+ to <a href="#targetimpls">implement the target description</a> classes for
+ your new target and understand the <a href="LangRef.html">LLVM code
+ representation</a>. If you are interested in implementing a
+ new <a href="#codegenalgs">code generation algorithm</a>, it should only
+ depend on the target-description and machine code representation classes,
+ ensuring that it is portable.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="required">Required components in the code generator</a>
+</h3>
+
+<div>
+
+<p>The two pieces of the LLVM code generator are the high-level interface to the
+ code generator and the set of reusable components that can be used to build
+ target-specific backends. The two most important interfaces
+ (<a href="#targetmachine"><tt>TargetMachine</tt></a>
+ and <a href="#targetdata"><tt>TargetData</tt></a>) are the only ones that are
+ required to be defined for a backend to fit into the LLVM system, but the
+ others must be defined if the reusable code generator components are going to
+ be used.</p>
+
+<p>This design has two important implications. The first is that LLVM can
+ support completely non-traditional code generation targets. For example, the
+ C backend does not require register allocation, instruction selection, or any
+ of the other standard components provided by the system. As such, it only
+ implements these two interfaces, and does its own thing. Another example of
+ a code generator like this is a (purely hypothetical) backend that converts
+ LLVM to the GCC RTL form and uses GCC to emit machine code for a target.</p>
+
+<p>This design also implies that it is possible to design and implement
+ radically different code generators in the LLVM system that do not make use
+ of any of the built-in components. Doing so is not recommended at all, but
+ could be required for radically different targets that do not fit into the
+ LLVM machine description model: FPGAs for example.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="high-level-design">The high-level design of the code generator</a>
+</h3>
+
+<div>
+
+<p>The LLVM target-independent code generator is designed to support efficient
+ and quality code generation for standard register-based microprocessors.
+ Code generation in this model is divided into the following stages:</p>
+
+<ol>
+ <li><b><a href="#instselect">Instruction Selection</a></b> — This phase
+ determines an efficient way to express the input LLVM code in the target
+ instruction set. This stage produces the initial code for the program in
+ the target instruction set, then makes use of virtual registers in SSA
+ form and physical registers that represent any required register
+ assignments due to target constraints or calling conventions. This step
+ turns the LLVM code into a DAG of target instructions.</li>
+
+ <li><b><a href="#selectiondag_sched">Scheduling and Formation</a></b> —
+ This phase takes the DAG of target instructions produced by the
+ instruction selection phase, determines an ordering of the instructions,
+ then emits the instructions
+ as <tt><a href="#machineinstr">MachineInstr</a></tt>s with that ordering.
+ Note that we describe this in the <a href="#instselect">instruction
+ selection section</a> because it operates on
+ a <a href="#selectiondag_intro">SelectionDAG</a>.</li>
+
+ <li><b><a href="#ssamco">SSA-based Machine Code Optimizations</a></b> —
+ This optional stage consists of a series of machine-code optimizations
+ that operate on the SSA-form produced by the instruction selector.
+ Optimizations like modulo-scheduling or peephole optimization work
+ here.</li>
+
+ <li><b><a href="#regalloc">Register Allocation</a></b> — The target code
+ is transformed from an infinite virtual register file in SSA form to the
+ concrete register file used by the target. This phase introduces spill
+ code and eliminates all virtual register references from the program.</li>
+
+ <li><b><a href="#proepicode">Prolog/Epilog Code Insertion</a></b> — Once
+ the machine code has been generated for the function and the amount of
+ stack space required is known (used for LLVM alloca's and spill slots),
+ the prolog and epilog code for the function can be inserted and "abstract
+ stack location references" can be eliminated. This stage is responsible
+ for implementing optimizations like frame-pointer elimination and stack
+ packing.</li>
+
+ <li><b><a href="#latemco">Late Machine Code Optimizations</a></b> —
+ Optimizations that operate on "final" machine code can go here, such as
+ spill code scheduling and peephole optimizations.</li>
+
+ <li><b><a href="#codeemit">Code Emission</a></b> — The final stage
+ actually puts out the code for the current function, either in the target
+ assembler format or in machine code.</li>
+</ol>
+
+<p>The code generator is based on the assumption that the instruction selector
+ will use an optimal pattern matching selector to create high-quality
+ sequences of native instructions. Alternative code generator designs based
+ on pattern expansion and aggressive iterative peephole optimization are much
+ slower. This design permits efficient compilation (important for JIT
+ environments) and aggressive optimization (used when generating code offline)
+ by allowing components of varying levels of sophistication to be used for any
+ step of compilation.</p>
+
+<p>In addition to these stages, target implementations can insert arbitrary
+ target-specific passes into the flow. For example, the X86 target uses a
+ special pass to handle the 80x87 floating point stack architecture. Other
+ targets with unusual requirements can be supported with custom passes as
+ needed.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="tablegen">Using TableGen for target description</a>
+</h3>
+
+<div>
+
+<p>The target description classes require a detailed description of the target
+ architecture. These target descriptions often have a large amount of common
+ information (e.g., an <tt>add</tt> instruction is almost identical to a
+ <tt>sub</tt> instruction). In order to allow the maximum amount of
+ commonality to be factored out, the LLVM code generator uses
+ the <a href="TableGenFundamentals.html">TableGen</a> tool to describe big
+ chunks of the target machine, which allows the use of domain-specific and
+ target-specific abstractions to reduce the amount of repetition.</p>
+
+<p>As LLVM continues to be developed and refined, we plan to move more and more
+ of the target description to the <tt>.td</tt> form. Doing so gives us a
+ number of advantages. The most important is that it makes it easier to port
+ LLVM because it reduces the amount of C++ code that has to be written, and
+ the surface area of the code generator that needs to be understood before
+ someone can get something working. Second, it makes it easier to change
+ things. In particular, if tables and other things are all emitted
+ by <tt>tblgen</tt>, we only need a change in one place (<tt>tblgen</tt>) to
+ update all of the targets to a new interface.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="targetdesc">Target description classes</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>The LLVM target description classes (located in the
+ <tt>include/llvm/Target</tt> directory) provide an abstract description of
+ the target machine independent of any particular client. These classes are
+ designed to capture the <i>abstract</i> properties of the target (such as the
+ instructions and registers it has), and do not incorporate any particular
+ pieces of code generation algorithms.</p>
+
+<p>All of the target description classes (except the
+ <tt><a href="#targetdata">TargetData</a></tt> class) are designed to be
+ subclassed by the concrete target implementation, and have virtual methods
+ implemented. To get to these implementations, the
+ <tt><a href="#targetmachine">TargetMachine</a></tt> class provides accessors
+ that should be implemented by the target.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetmachine">The <tt>TargetMachine</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetMachine</tt> class provides virtual methods that are used to
+ access the target-specific implementations of the various target description
+ classes via the <tt>get*Info</tt> methods (<tt>getInstrInfo</tt>,
+ <tt>getRegisterInfo</tt>, <tt>getFrameInfo</tt>, etc.). This class is
+ designed to be specialized by a concrete target implementation
+ (e.g., <tt>X86TargetMachine</tt>) which implements the various virtual
+ methods. The only required target description class is
+ the <a href="#targetdata"><tt>TargetData</tt></a> class, but if the code
+ generator components are to be used, the other interfaces should be
+ implemented as well.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetdata">The <tt>TargetData</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetData</tt> class is the only required target description class,
+ and it is the only class that is not extensible (you cannot derived a new
+ class from it). <tt>TargetData</tt> specifies information about how the
+ target lays out memory for structures, the alignment requirements for various
+ data types, the size of pointers in the target, and whether the target is
+ little-endian or big-endian.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetlowering">The <tt>TargetLowering</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetLowering</tt> class is used by SelectionDAG based instruction
+ selectors primarily to describe how LLVM code should be lowered to
+ SelectionDAG operations. Among other things, this class indicates:</p>
+
+<ul>
+ <li>an initial register class to use for various <tt>ValueType</tt>s,</li>
+
+ <li>which operations are natively supported by the target machine,</li>
+
+ <li>the return type of <tt>setcc</tt> operations,</li>
+
+ <li>the type to use for shift amounts, and</li>
+
+ <li>various high-level characteristics, like whether it is profitable to turn
+ division by a constant into a multiplication sequence</li>
+</ul>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetregisterinfo">The <tt>TargetRegisterInfo</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetRegisterInfo</tt> class is used to describe the register file
+ of the target and any interactions between the registers.</p>
+
+<p>Registers in the code generator are represented in the code generator by
+ unsigned integers. Physical registers (those that actually exist in the
+ target description) are unique small numbers, and virtual registers are
+ generally large. Note that register #0 is reserved as a flag value.</p>
+
+<p>Each register in the processor description has an associated
+ <tt>TargetRegisterDesc</tt> entry, which provides a textual name for the
+ register (used for assembly output and debugging dumps) and a set of aliases
+ (used to indicate whether one register overlaps with another).</p>
+
+<p>In addition to the per-register description, the <tt>TargetRegisterInfo</tt>
+ class exposes a set of processor specific register classes (instances of the
+ <tt>TargetRegisterClass</tt> class). Each register class contains sets of
+ registers that have the same properties (for example, they are all 32-bit
+ integer registers). Each SSA virtual register created by the instruction
+ selector has an associated register class. When the register allocator runs,
+ it replaces virtual registers with a physical register in the set.</p>
+
+<p>The target-specific implementations of these classes is auto-generated from
+ a <a href="TableGenFundamentals.html">TableGen</a> description of the
+ register file.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetinstrinfo">The <tt>TargetInstrInfo</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetInstrInfo</tt> class is used to describe the machine
+ instructions supported by the target. It is essentially an array of
+ <tt>TargetInstrDescriptor</tt> objects, each of which describes one
+ instruction the target supports. Descriptors define things like the mnemonic
+ for the opcode, the number of operands, the list of implicit register uses
+ and defs, whether the instruction has certain target-independent properties
+ (accesses memory, is commutable, etc), and holds any target-specific
+ flags.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetframeinfo">The <tt>TargetFrameInfo</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetFrameInfo</tt> class is used to provide information about the
+ stack frame layout of the target. It holds the direction of stack growth, the
+ known stack alignment on entry to each function, and the offset to the local
+ area. The offset to the local area is the offset from the stack pointer on
+ function entry to the first location where function data (local variables,
+ spill locations) can be stored.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetsubtarget">The <tt>TargetSubtarget</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetSubtarget</tt> class is used to provide information about the
+ specific chip set being targeted. A sub-target informs code generation of
+ which instructions are supported, instruction latencies and instruction
+ execution itinerary; i.e., which processing units are used, in what order,
+ and for how long.</p>
+
+</div>
+
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetjitinfo">The <tt>TargetJITInfo</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>TargetJITInfo</tt> class exposes an abstract interface used by the
+ Just-In-Time code generator to perform target-specific activities, such as
+ emitting stubs. If a <tt>TargetMachine</tt> supports JIT code generation, it
+ should provide one of these objects through the <tt>getJITInfo</tt>
+ method.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="codegendesc">Machine code description classes</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>At the high-level, LLVM code is translated to a machine specific
+ representation formed out of
+ <a href="#machinefunction"><tt>MachineFunction</tt></a>,
+ <a href="#machinebasicblock"><tt>MachineBasicBlock</tt></a>,
+ and <a href="#machineinstr"><tt>MachineInstr</tt></a> instances (defined
+ in <tt>include/llvm/CodeGen</tt>). This representation is completely target
+ agnostic, representing instructions in their most abstract form: an opcode
+ and a series of operands. This representation is designed to support both an
+ SSA representation for machine code, as well as a register allocated, non-SSA
+ form.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="machineinstr">The <tt>MachineInstr</tt> class</a>
+</h3>
+
+<div>
+
+<p>Target machine instructions are represented as instances of the
+ <tt>MachineInstr</tt> class. This class is an extremely abstract way of
+ representing machine instructions. In particular, it only keeps track of an
+ opcode number and a set of operands.</p>
+
+<p>The opcode number is a simple unsigned integer that only has meaning to a
+ specific backend. All of the instructions for a target should be defined in
+ the <tt>*InstrInfo.td</tt> file for the target. The opcode enum values are
+ auto-generated from this description. The <tt>MachineInstr</tt> class does
+ not have any information about how to interpret the instruction (i.e., what
+ the semantics of the instruction are); for that you must refer to the
+ <tt><a href="#targetinstrinfo">TargetInstrInfo</a></tt> class.</p>
+
+<p>The operands of a machine instruction can be of several different types: a
+ register reference, a constant integer, a basic block reference, etc. In
+ addition, a machine operand should be marked as a def or a use of the value
+ (though only registers are allowed to be defs).</p>
+
+<p>By convention, the LLVM code generator orders instruction operands so that
+ all register definitions come before the register uses, even on architectures
+ that are normally printed in other orders. For example, the SPARC add
+ instruction: "<tt>add %i1, %i2, %i3</tt>" adds the "%i1", and "%i2" registers
+ and stores the result into the "%i3" register. In the LLVM code generator,
+ the operands should be stored as "<tt>%i3, %i1, %i2</tt>": with the
+ destination first.</p>
+
+<p>Keeping destination (definition) operands at the beginning of the operand
+ list has several advantages. In particular, the debugging printer will print
+ the instruction like this:</p>
+
+<div class="doc_code">
+<pre>
+%r3 = add %i1, %i2
+</pre>
+</div>
+
+<p>Also if the first operand is a def, it is easier to <a href="#buildmi">create
+ instructions</a> whose only def is the first operand.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="buildmi">Using the <tt>MachineInstrBuilder.h</tt> functions</a>
+</h4>
+
+<div>
+
+<p>Machine instructions are created by using the <tt>BuildMI</tt> functions,
+ located in the <tt>include/llvm/CodeGen/MachineInstrBuilder.h</tt> file. The
+ <tt>BuildMI</tt> functions make it easy to build arbitrary machine
+ instructions. Usage of the <tt>BuildMI</tt> functions look like this:</p>
+
+<div class="doc_code">
+<pre>
+// Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
+// instruction. The '1' specifies how many operands will be added.
+MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
+
+// Create the same instr, but insert it at the end of a basic block.
+MachineBasicBlock &MBB = ...
+BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
+
+// Create the same instr, but insert it before a specified iterator point.
+MachineBasicBlock::iterator MBBI = ...
+BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
+
+// Create a 'cmp Reg, 0' instruction, no destination reg.
+MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
+// Create an 'sahf' instruction which takes no operands and stores nothing.
+MI = BuildMI(X86::SAHF, 0);
+
+// Create a self looping branch instruction.
+BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
+</pre>
+</div>
+
+<p>The key thing to remember with the <tt>BuildMI</tt> functions is that you
+ have to specify the number of operands that the machine instruction will
+ take. This allows for efficient memory allocation. You also need to specify
+ if operands default to be uses of values, not definitions. If you need to
+ add a definition operand (other than the optional destination register), you
+ must explicitly mark it as such:</p>
+
+<div class="doc_code">
+<pre>
+MI.addReg(Reg, RegState::Define);
+</pre>
+</div>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="fixedregs">Fixed (preassigned) registers</a>
+</h4>
+
+<div>
+
+<p>One important issue that the code generator needs to be aware of is the
+ presence of fixed registers. In particular, there are often places in the
+ instruction stream where the register allocator <em>must</em> arrange for a
+ particular value to be in a particular register. This can occur due to
+ limitations of the instruction set (e.g., the X86 can only do a 32-bit divide
+ with the <tt>EAX</tt>/<tt>EDX</tt> registers), or external factors like
+ calling conventions. In any case, the instruction selector should emit code
+ that copies a virtual register into or out of a physical register when
+ needed.</p>
+
+<p>For example, consider this simple LLVM example:</p>
+
+<div class="doc_code">
+<pre>
+define i32 @test(i32 %X, i32 %Y) {
+ %Z = udiv i32 %X, %Y
+ ret i32 %Z
+}
+</pre>
+</div>
+
+<p>The X86 instruction selector produces this machine code for the <tt>div</tt>
+ and <tt>ret</tt> (use "<tt>llc X.bc -march=x86 -print-machineinstrs</tt>" to
+ get this):</p>
+
+<div class="doc_code">
+<pre>
+;; Start of div
+%EAX = mov %reg1024 ;; Copy X (in reg1024) into EAX
+%reg1027 = sar %reg1024, 31
+%EDX = mov %reg1027 ;; Sign extend X into EDX
+idiv %reg1025 ;; Divide by Y (in reg1025)
+%reg1026 = mov %EAX ;; Read the result (Z) out of EAX
+
+;; Start of ret
+%EAX = mov %reg1026 ;; 32-bit return value goes in EAX
+ret
+</pre>
+</div>
+
+<p>By the end of code generation, the register allocator has coalesced the
+ registers and deleted the resultant identity moves producing the following
+ code:</p>
+
+<div class="doc_code">
+<pre>
+;; X is in EAX, Y is in ECX
+mov %EAX, %EDX
+sar %EDX, 31
+idiv %ECX
+ret
+</pre>
+</div>
+
+<p>This approach is extremely general (if it can handle the X86 architecture, it
+ can handle anything!) and allows all of the target specific knowledge about
+ the instruction stream to be isolated in the instruction selector. Note that
+ physical registers should have a short lifetime for good code generation, and
+ all physical registers are assumed dead on entry to and exit from basic
+ blocks (before register allocation). Thus, if you need a value to be live
+ across basic block boundaries, it <em>must</em> live in a virtual
+ register.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="callclobber">Call-clobbered registers</a>
+</h4>
+
+<div>
+
+<p>Some machine instructions, like calls, clobber a large number of physical
+ registers. Rather than adding <code><def,dead></code> operands for
+ all of them, it is possible to use an <code>MO_RegisterMask</code> operand
+ instead. The register mask operand holds a bit mask of preserved registers,
+ and everything else is considered to be clobbered by the instruction. </p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ssa">Machine code in SSA form</a>
+</h4>
+
+<div>
+
+<p><tt>MachineInstr</tt>'s are initially selected in SSA-form, and are
+ maintained in SSA-form until register allocation happens. For the most part,
+ this is trivially simple since LLVM is already in SSA form; LLVM PHI nodes
+ become machine code PHI nodes, and virtual registers are only allowed to have
+ a single definition.</p>
+
+<p>After register allocation, machine code is no longer in SSA-form because
+ there are no virtual registers left in the code.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="machinebasicblock">The <tt>MachineBasicBlock</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>MachineBasicBlock</tt> class contains a list of machine instructions
+ (<tt><a href="#machineinstr">MachineInstr</a></tt> instances). It roughly
+ corresponds to the LLVM code input to the instruction selector, but there can
+ be a one-to-many mapping (i.e. one LLVM basic block can map to multiple
+ machine basic blocks). The <tt>MachineBasicBlock</tt> class has a
+ "<tt>getBasicBlock</tt>" method, which returns the LLVM basic block that it
+ comes from.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="machinefunction">The <tt>MachineFunction</tt> class</a>
+</h3>
+
+<div>
+
+<p>The <tt>MachineFunction</tt> class contains a list of machine basic blocks
+ (<tt><a href="#machinebasicblock">MachineBasicBlock</a></tt> instances). It
+ corresponds one-to-one with the LLVM function input to the instruction
+ selector. In addition to a list of basic blocks,
+ the <tt>MachineFunction</tt> contains a a <tt>MachineConstantPool</tt>,
+ a <tt>MachineFrameInfo</tt>, a <tt>MachineFunctionInfo</tt>, and a
+ <tt>MachineRegisterInfo</tt>. See
+ <tt>include/llvm/CodeGen/MachineFunction.h</tt> for more information.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="machineinstrbundle"><tt>MachineInstr Bundles</tt></a>
+</h3>
+
+<div>
+
+<p>LLVM code generator can model sequences of instructions as MachineInstr
+ bundles. A MI bundle can model a VLIW group / pack which contains an
+ arbitrary number of parallel instructions. It can also be used to model
+ a sequential list of instructions (potentially with data dependencies) that
+ cannot be legally separated (e.g. ARM Thumb2 IT blocks).</p>
+
+<p>Conceptually a MI bundle is a MI with a number of other MIs nested within:
+</p>
+
+<div class="doc_code">
+<pre>
+--------------
+| Bundle | ---------
+-------------- \
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ |
+--------------
+| Bundle | --------
+-------------- \
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ----------------
+ | | MI |
+ | ----------------
+ | |
+ | ...
+ |
+--------------
+| Bundle | --------
+-------------- \
+ |
+ ...
+</pre>
+</div>
+
+<p> MI bundle support does not change the physical representations of
+ MachineBasicBlock and MachineInstr. All the MIs (including top level and
+ nested ones) are stored as sequential list of MIs. The "bundled" MIs are
+ marked with the 'InsideBundle' flag. A top level MI with the special BUNDLE
+ opcode is used to represent the start of a bundle. It's legal to mix BUNDLE
+ MIs with indiviual MIs that are not inside bundles nor represent bundles.
+</p>
+
+<p> MachineInstr passes should operate on a MI bundle as a single unit. Member
+ methods have been taught to correctly handle bundles and MIs inside bundles.
+ The MachineBasicBlock iterator has been modified to skip over bundled MIs to
+ enforce the bundle-as-a-single-unit concept. An alternative iterator
+ instr_iterator has been added to MachineBasicBlock to allow passes to
+ iterate over all of the MIs in a MachineBasicBlock, including those which
+ are nested inside bundles. The top level BUNDLE instruction must have the
+ correct set of register MachineOperand's that represent the cumulative
+ inputs and outputs of the bundled MIs.</p>
+
+<p> Packing / bundling of MachineInstr's should be done as part of the register
+ allocation super-pass. More specifically, the pass which determines what
+ MIs should be bundled together must be done after code generator exits SSA
+ form (i.e. after two-address pass, PHI elimination, and copy coalescing).
+ Bundles should only be finalized (i.e. adding BUNDLE MIs and input and
+ output register MachineOperands) after virtual registers have been
+ rewritten into physical registers. This requirement eliminates the need to
+ add virtual register operands to BUNDLE instructions which would effectively
+ double the virtual register def and use lists.</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="mc">The "MC" Layer</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>
+The MC Layer is used to represent and process code at the raw machine code
+level, devoid of "high level" information like "constant pools", "jump tables",
+"global variables" or anything like that. At this level, LLVM handles things
+like label names, machine instructions, and sections in the object file. The
+code in this layer is used for a number of important purposes: the tail end of
+the code generator uses it to write a .s or .o file, and it is also used by the
+llvm-mc tool to implement standalone machine code assemblers and disassemblers.
+</p>
+
+<p>
+This section describes some of the important classes. There are also a number
+of important subsystems that interact at this layer, they are described later
+in this manual.
+</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="mcstreamer">The <tt>MCStreamer</tt> API</a>
+</h3>
+
+<div>
+
+<p>
+MCStreamer is best thought of as an assembler API. It is an abstract API which
+is <em>implemented</em> in different ways (e.g. to output a .s file, output an
+ELF .o file, etc) but whose API correspond directly to what you see in a .s
+file. MCStreamer has one method per directive, such as EmitLabel,
+EmitSymbolAttribute, SwitchSection, EmitValue (for .byte, .word), etc, which
+directly correspond to assembly level directives. It also has an
+EmitInstruction method, which is used to output an MCInst to the streamer.
+</p>
+
+<p>
+This API is most important for two clients: the llvm-mc stand-alone assembler is
+effectively a parser that parses a line, then invokes a method on MCStreamer. In
+the code generator, the <a href="#codeemit">Code Emission</a> phase of the code
+generator lowers higher level LLVM IR and Machine* constructs down to the MC
+layer, emitting directives through MCStreamer.</p>
+
+<p>
+On the implementation side of MCStreamer, there are two major implementations:
+one for writing out a .s file (MCAsmStreamer), and one for writing out a .o
+file (MCObjectStreamer). MCAsmStreamer is a straight-forward implementation
+that prints out a directive for each method (e.g. EmitValue -> .byte), but
+MCObjectStreamer implements a full assembler.
+</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="mccontext">The <tt>MCContext</tt> class</a>
+</h3>
+
+<div>
+
+<p>
+The MCContext class is the owner of a variety of uniqued data structures at the
+MC layer, including symbols, sections, etc. As such, this is the class that you
+interact with to create symbols and sections. This class can not be subclassed.
+</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="mcsymbol">The <tt>MCSymbol</tt> class</a>
+</h3>
+
+<div>
+
+<p>
+The MCSymbol class represents a symbol (aka label) in the assembly file. There
+are two interesting kinds of symbols: assembler temporary symbols, and normal
+symbols. Assembler temporary symbols are used and processed by the assembler
+but are discarded when the object file is produced. The distinction is usually
+represented by adding a prefix to the label, for example "L" labels are
+assembler temporary labels in MachO.
+</p>
+
+<p>MCSymbols are created by MCContext and uniqued there. This means that
+MCSymbols can be compared for pointer equivalence to find out if they are the
+same symbol. Note that pointer inequality does not guarantee the labels will
+end up at different addresses though. It's perfectly legal to output something
+like this to the .s file:<p>
+
+<pre>
+ foo:
+ bar:
+ .byte 4
+</pre>
+
+<p>In this case, both the foo and bar symbols will have the same address.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="mcsection">The <tt>MCSection</tt> class</a>
+</h3>
+
+<div>
+
+<p>
+The MCSection class represents an object-file specific section. It is subclassed
+by object file specific implementations (e.g. <tt>MCSectionMachO</tt>,
+<tt>MCSectionCOFF</tt>, <tt>MCSectionELF</tt>) and these are created and uniqued
+by MCContext. The MCStreamer has a notion of the current section, which can be
+changed with the SwitchToSection method (which corresponds to a ".section"
+directive in a .s file).
+</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="mcinst">The <tt>MCInst</tt> class</a>
+</h3>
+
+<div>
+
+<p>
+The MCInst class is a target-independent representation of an instruction. It
+is a simple class (much more so than <a href="#machineinstr">MachineInstr</a>)
+that holds a target-specific opcode and a vector of MCOperands. MCOperand, in
+turn, is a simple discriminated union of three cases: 1) a simple immediate,
+2) a target register ID, 3) a symbolic expression (e.g. "Lfoo-Lbar+42") as an
+MCExpr.
+</p>
+
+<p>MCInst is the common currency used to represent machine instructions at the
+MC layer. It is the type used by the instruction encoder, the instruction
+printer, and the type generated by the assembly parser and disassembler.
+</p>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="codegenalgs">Target-independent code generation algorithms</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This section documents the phases described in the
+ <a href="#high-level-design">high-level design of the code generator</a>.
+ It explains how they work and some of the rationale behind their design.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="instselect">Instruction Selection</a>
+</h3>
+
+<div>
+
+<p>Instruction Selection is the process of translating LLVM code presented to
+ the code generator into target-specific machine instructions. There are
+ several well-known ways to do this in the literature. LLVM uses a
+ SelectionDAG based instruction selector.</p>
+
+<p>Portions of the DAG instruction selector are generated from the target
+ description (<tt>*.td</tt>) files. Our goal is for the entire instruction
+ selector to be generated from these <tt>.td</tt> files, though currently
+ there are still things that require custom C++ code.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_intro">Introduction to SelectionDAGs</a>
+</h4>
+
+<div>
+
+<p>The SelectionDAG provides an abstraction for code representation in a way
+ that is amenable to instruction selection using automatic techniques
+ (e.g. dynamic-programming based optimal pattern matching selectors). It is
+ also well-suited to other phases of code generation; in particular,
+ instruction scheduling (SelectionDAG's are very close to scheduling DAGs
+ post-selection). Additionally, the SelectionDAG provides a host
+ representation where a large variety of very-low-level (but
+ target-independent) <a href="#selectiondag_optimize">optimizations</a> may be
+ performed; ones which require extensive information about the instructions
+ efficiently supported by the target.</p>
+
+<p>The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the
+ <tt>SDNode</tt> class. The primary payload of the <tt>SDNode</tt> is its
+ operation code (Opcode) that indicates what operation the node performs and
+ the operands to the operation. The various operation node types are
+ described at the top of the <tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>
+ file.</p>
+
+<p>Although most operations define a single value, each node in the graph may
+ define multiple values. For example, a combined div/rem operation will
+ define both the dividend and the remainder. Many other situations require
+ multiple values as well. Each node also has some number of operands, which
+ are edges to the node defining the used value. Because nodes may define
+ multiple values, edges are represented by instances of the <tt>SDValue</tt>
+ class, which is a <tt><SDNode, unsigned></tt> pair, indicating the node
+ and result value being used, respectively. Each value produced by
+ an <tt>SDNode</tt> has an associated <tt>MVT</tt> (Machine Value Type)
+ indicating what the type of the value is.</p>
+
+<p>SelectionDAGs contain two different kinds of values: those that represent
+ data flow and those that represent control flow dependencies. Data values
+ are simple edges with an integer or floating point value type. Control edges
+ are represented as "chain" edges which are of type <tt>MVT::Other</tt>.
+ These edges provide an ordering between nodes that have side effects (such as
+ loads, stores, calls, returns, etc). All nodes that have side effects should
+ take a token chain as input and produce a new one as output. By convention,
+ token chain inputs are always operand #0, and chain results are always the
+ last value produced by an operation.</p>
+
+<p>A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is
+ always a marker node with an Opcode of <tt>ISD::EntryToken</tt>. The Root
+ node is the final side-effecting node in the token chain. For example, in a
+ single basic block function it would be the return node.</p>
+
+<p>One important concept for SelectionDAGs is the notion of a "legal" vs.
+ "illegal" DAG. A legal DAG for a target is one that only uses supported
+ operations and supported types. On a 32-bit PowerPC, for example, a DAG with
+ a value of type i1, i8, i16, or i64 would be illegal, as would a DAG that
+ uses a SREM or UREM operation. The
+ <a href="#selectinodag_legalize_types">legalize types</a> and
+ <a href="#selectiondag_legalize">legalize operations</a> phases are
+ responsible for turning an illegal DAG into a legal DAG.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_process">SelectionDAG Instruction Selection Process</a>
+</h4>
+
+<div>
+
+<p>SelectionDAG-based instruction selection consists of the following steps:</p>
+
+<ol>
+ <li><a href="#selectiondag_build">Build initial DAG</a> — This stage
+ performs a simple translation from the input LLVM code to an illegal
+ SelectionDAG.</li>
+
+ <li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> — This
+ stage performs simple optimizations on the SelectionDAG to simplify it,
+ and recognize meta instructions (like rotates
+ and <tt>div</tt>/<tt>rem</tt> pairs) for targets that support these meta
+ operations. This makes the resultant code more efficient and
+ the <a href="#selectiondag_select">select instructions from DAG</a> phase
+ (below) simpler.</li>
+
+ <li><a href="#selectiondag_legalize_types">Legalize SelectionDAG Types</a>
+ — This stage transforms SelectionDAG nodes to eliminate any types
+ that are unsupported on the target.</li>
+
+ <li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> — The
+ SelectionDAG optimizer is run to clean up redundancies exposed by type
+ legalization.</li>
+
+ <li><a href="#selectiondag_legalize">Legalize SelectionDAG Ops</a> —
+ This stage transforms SelectionDAG nodes to eliminate any operations
+ that are unsupported on the target.</li>
+
+ <li><a href="#selectiondag_optimize">Optimize SelectionDAG</a> — The
+ SelectionDAG optimizer is run to eliminate inefficiencies introduced by
+ operation legalization.</li>
+
+ <li><a href="#selectiondag_select">Select instructions from DAG</a> —
+ Finally, the target instruction selector matches the DAG operations to
+ target instructions. This process translates the target-independent input
+ DAG into another DAG of target instructions.</li>
+
+ <li><a href="#selectiondag_sched">SelectionDAG Scheduling and Formation</a>
+ — The last phase assigns a linear order to the instructions in the
+ target-instruction DAG and emits them into the MachineFunction being
+ compiled. This step uses traditional prepass scheduling techniques.</li>
+</ol>
+
+<p>After all of these steps are complete, the SelectionDAG is destroyed and the
+ rest of the code generation passes are run.</p>
+
+<p>One great way to visualize what is going on here is to take advantage of a
+ few LLC command line options. The following options pop up a window
+ displaying the SelectionDAG at specific times (if you only get errors printed
+ to the console while using this, you probably
+ <a href="ProgrammersManual.html#ViewGraph">need to configure your system</a>
+ to add support for it).</p>
+
+<ul>
+ <li><tt>-view-dag-combine1-dags</tt> displays the DAG after being built,
+ before the first optimization pass.</li>
+
+ <li><tt>-view-legalize-dags</tt> displays the DAG before Legalization.</li>
+
+ <li><tt>-view-dag-combine2-dags</tt> displays the DAG before the second
+ optimization pass.</li>
+
+ <li><tt>-view-isel-dags</tt> displays the DAG before the Select phase.</li>
+
+ <li><tt>-view-sched-dags</tt> displays the DAG before Scheduling.</li>
+</ul>
+
+<p>The <tt>-view-sunit-dags</tt> displays the Scheduler's dependency graph.
+ This graph is based on the final SelectionDAG, with nodes that must be
+ scheduled together bundled into a single scheduling-unit node, and with
+ immediate operands and other nodes that aren't relevant for scheduling
+ omitted.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_build">Initial SelectionDAG Construction</a>
+</h4>
+
+<div>
+
+<p>The initial SelectionDAG is naïvely peephole expanded from the LLVM
+ input by the <tt>SelectionDAGLowering</tt> class in the
+ <tt>lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp</tt> file. The intent of
+ this pass is to expose as much low-level, target-specific details to the
+ SelectionDAG as possible. This pass is mostly hard-coded (e.g. an
+ LLVM <tt>add</tt> turns into an <tt>SDNode add</tt> while a
+ <tt>getelementptr</tt> is expanded into the obvious arithmetic). This pass
+ requires target-specific hooks to lower calls, returns, varargs, etc. For
+ these features, the <tt><a href="#targetlowering">TargetLowering</a></tt>
+ interface is used.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_legalize_types">SelectionDAG LegalizeTypes Phase</a>
+</h4>
+
+<div>
+
+<p>The Legalize phase is in charge of converting a DAG to only use the types
+ that are natively supported by the target.</p>
+
+<p>There are two main ways of converting values of unsupported scalar types to
+ values of supported types: converting small types to larger types
+ ("promoting"), and breaking up large integer types into smaller ones
+ ("expanding"). For example, a target might require that all f32 values are
+ promoted to f64 and that all i1/i8/i16 values are promoted to i32. The same
+ target might require that all i64 values be expanded into pairs of i32
+ values. These changes can insert sign and zero extensions as needed to make
+ sure that the final code has the same behavior as the input.</p>
+
+<p>There are two main ways of converting values of unsupported vector types to
+ value of supported types: splitting vector types, multiple times if
+ necessary, until a legal type is found, and extending vector types by adding
+ elements to the end to round them out to legal types ("widening"). If a
+ vector gets split all the way down to single-element parts with no supported
+ vector type being found, the elements are converted to scalars
+ ("scalarizing").</p>
+
+<p>A target implementation tells the legalizer which types are supported (and
+ which register class to use for them) by calling the
+ <tt>addRegisterClass</tt> method in its TargetLowering constructor.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_legalize">SelectionDAG Legalize Phase</a>
+</h4>
+
+<div>
+
+<p>The Legalize phase is in charge of converting a DAG to only use the
+ operations that are natively supported by the target.</p>
+
+<p>Targets often have weird constraints, such as not supporting every operation
+ on every supported datatype (e.g. X86 does not support byte conditional moves
+ and PowerPC does not support sign-extending loads from a 16-bit memory
+ location). Legalize takes care of this by open-coding another sequence of
+ operations to emulate the operation ("expansion"), by promoting one type to a
+ larger type that supports the operation ("promotion"), or by using a
+ target-specific hook to implement the legalization ("custom").</p>
+
+<p>A target implementation tells the legalizer which operations are not
+ supported (and which of the above three actions to take) by calling the
+ <tt>setOperationAction</tt> method in its <tt>TargetLowering</tt>
+ constructor.</p>
+
+<p>Prior to the existence of the Legalize passes, we required that every target
+ <a href="#selectiondag_optimize">selector</a> supported and handled every
+ operator and type even if they are not natively supported. The introduction
+ of the Legalize phases allows all of the canonicalization patterns to be
+ shared across targets, and makes it very easy to optimize the canonicalized
+ code because it is still in the form of a DAG.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_optimize">
+ SelectionDAG Optimization Phase: the DAG Combiner
+ </a>
+</h4>
+
+<div>
+
+<p>The SelectionDAG optimization phase is run multiple times for code
+ generation, immediately after the DAG is built and once after each
+ legalization. The first run of the pass allows the initial code to be
+ cleaned up (e.g. performing optimizations that depend on knowing that the
+ operators have restricted type inputs). Subsequent runs of the pass clean up
+ the messy code generated by the Legalize passes, which allows Legalize to be
+ very simple (it can focus on making code legal instead of focusing on
+ generating <em>good</em> and legal code).</p>
+
+<p>One important class of optimizations performed is optimizing inserted sign
+ and zero extension instructions. We currently use ad-hoc techniques, but
+ could move to more rigorous techniques in the future. Here are some good
+ papers on the subject:</p>
+
+<p>"<a href="http://www.eecs.harvard.edu/~nr/pubs/widen-abstract.html">Widening
+ integer arithmetic</a>"<br>
+ Kevin Redwine and Norman Ramsey<br>
+ International Conference on Compiler Construction (CC) 2004</p>
+
+<p>"<a href="http://portal.acm.org/citation.cfm?doid=512529.512552">Effective
+ sign extension elimination</a>"<br>
+ Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani<br>
+ Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design
+ and Implementation.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_select">SelectionDAG Select Phase</a>
+</h4>
+
+<div>
+
+<p>The Select phase is the bulk of the target-specific code for instruction
+ selection. This phase takes a legal SelectionDAG as input, pattern matches
+ the instructions supported by the target to this DAG, and produces a new DAG
+ of target code. For example, consider the following LLVM fragment:</p>
+
+<div class="doc_code">
+<pre>
+%t1 = fadd float %W, %X
+%t2 = fmul float %t1, %Y
+%t3 = fadd float %t2, %Z
+</pre>
+</div>
+
+<p>This LLVM code corresponds to a SelectionDAG that looks basically like
+ this:</p>
+
+<div class="doc_code">
+<pre>
+(fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
+</pre>
+</div>
+
+<p>If a target supports floating point multiply-and-add (FMA) operations, one of
+ the adds can be merged with the multiply. On the PowerPC, for example, the
+ output of the instruction selector might look like this DAG:</p>
+
+<div class="doc_code">
+<pre>
+(FMADDS (FADDS W, X), Y, Z)
+</pre>
+</div>
+
+<p>The <tt>FMADDS</tt> instruction is a ternary instruction that multiplies its
+first two operands and adds the third (as single-precision floating-point
+numbers). The <tt>FADDS</tt> instruction is a simple binary single-precision
+add instruction. To perform this pattern match, the PowerPC backend includes
+the following instruction definitions:</p>
+
+<div class="doc_code">
+<pre>
+def FMADDS : AForm_1<59, 29,
+ (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
+ "fmadds $FRT, $FRA, $FRC, $FRB",
+ [<b>(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
+ F4RC:$FRB))</b>]>;
+def FADDS : AForm_2<59, 21,
+ (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
+ "fadds $FRT, $FRA, $FRB",
+ [<b>(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))</b>]>;
+</pre>
+</div>
+
+<p>The portion of the instruction definition in bold indicates the pattern used
+ to match the instruction. The DAG operators
+ (like <tt>fmul</tt>/<tt>fadd</tt>) are defined in
+ the <tt>include/llvm/Target/TargetSelectionDAG.td</tt> file. "
+ <tt>F4RC</tt>" is the register class of the input and result values.</p>
+
+<p>The TableGen DAG instruction selector generator reads the instruction
+ patterns in the <tt>.td</tt> file and automatically builds parts of the
+ pattern matching code for your target. It has the following strengths:</p>
+
+<ul>
+ <li>At compiler-compiler time, it analyzes your instruction patterns and tells
+ you if your patterns make sense or not.</li>
+
+ <li>It can handle arbitrary constraints on operands for the pattern match. In
+ particular, it is straight-forward to say things like "match any immediate
+ that is a 13-bit sign-extended value". For examples, see the
+ <tt>immSExt16</tt> and related <tt>tblgen</tt> classes in the PowerPC
+ backend.</li>
+
+ <li>It knows several important identities for the patterns defined. For
+ example, it knows that addition is commutative, so it allows the
+ <tt>FMADDS</tt> pattern above to match "<tt>(fadd X, (fmul Y, Z))</tt>" as
+ well as "<tt>(fadd (fmul X, Y), Z)</tt>", without the target author having
+ to specially handle this case.</li>
+
+ <li>It has a full-featured type-inferencing system. In particular, you should
+ rarely have to explicitly tell the system what type parts of your patterns
+ are. In the <tt>FMADDS</tt> case above, we didn't have to tell
+ <tt>tblgen</tt> that all of the nodes in the pattern are of type 'f32'.
+ It was able to infer and propagate this knowledge from the fact that
+ <tt>F4RC</tt> has type 'f32'.</li>
+
+ <li>Targets can define their own (and rely on built-in) "pattern fragments".
+ Pattern fragments are chunks of reusable patterns that get inlined into
+ your patterns during compiler-compiler time. For example, the integer
+ "<tt>(not x)</tt>" operation is actually defined as a pattern fragment
+ that expands as "<tt>(xor x, -1)</tt>", since the SelectionDAG does not
+ have a native '<tt>not</tt>' operation. Targets can define their own
+ short-hand fragments as they see fit. See the definition of
+ '<tt>not</tt>' and '<tt>ineg</tt>' for examples.</li>
+
+ <li>In addition to instructions, targets can specify arbitrary patterns that
+ map to one or more instructions using the 'Pat' class. For example, the
+ PowerPC has no way to load an arbitrary integer immediate into a register
+ in one instruction. To tell tblgen how to do this, it defines:
+ <br>
+ <br>
+<div class="doc_code">
+<pre>
+// Arbitrary immediate support. Implement in terms of LIS/ORI.
+def : Pat<(i32 imm:$imm),
+ (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
+</pre>
+</div>
+ <br>
+ If none of the single-instruction patterns for loading an immediate into a
+ register match, this will be used. This rule says "match an arbitrary i32
+ immediate, turning it into an <tt>ORI</tt> ('or a 16-bit immediate') and
+ an <tt>LIS</tt> ('load 16-bit immediate, where the immediate is shifted to
+ the left 16 bits') instruction". To make this work, the
+ <tt>LO16</tt>/<tt>HI16</tt> node transformations are used to manipulate
+ the input immediate (in this case, take the high or low 16-bits of the
+ immediate).</li>
+
+ <li>While the system does automate a lot, it still allows you to write custom
+ C++ code to match special cases if there is something that is hard to
+ express.</li>
+</ul>
+
+<p>While it has many strengths, the system currently has some limitations,
+ primarily because it is a work in progress and is not yet finished:</p>
+
+<ul>
+ <li>Overall, there is no way to define or match SelectionDAG nodes that define
+ multiple values (e.g. <tt>SMUL_LOHI</tt>, <tt>LOAD</tt>, <tt>CALL</tt>,
+ etc). This is the biggest reason that you currently still <em>have
+ to</em> write custom C++ code for your instruction selector.</li>
+
+ <li>There is no great way to support matching complex addressing modes yet.
+ In the future, we will extend pattern fragments to allow them to define
+ multiple values (e.g. the four operands of the <a href="#x86_memory">X86
+ addressing mode</a>, which are currently matched with custom C++ code).
+ In addition, we'll extend fragments so that a fragment can match multiple
+ different patterns.</li>
+
+ <li>We don't automatically infer flags like isStore/isLoad yet.</li>
+
+ <li>We don't automatically generate the set of supported registers and
+ operations for the <a href="#selectiondag_legalize">Legalizer</a>
+ yet.</li>
+
+ <li>We don't have a way of tying in custom legalized nodes yet.</li>
+</ul>
+
+<p>Despite these limitations, the instruction selector generator is still quite
+ useful for most of the binary and logical operations in typical instruction
+ sets. If you run into any problems or can't figure out how to do something,
+ please let Chris know!</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_sched">SelectionDAG Scheduling and Formation Phase</a>
+</h4>
+
+<div>
+
+<p>The scheduling phase takes the DAG of target instructions from the selection
+ phase and assigns an order. The scheduler can pick an order depending on
+ various constraints of the machines (i.e. order for minimal register pressure
+ or try to cover instruction latencies). Once an order is established, the
+ DAG is converted to a list
+ of <tt><a href="#machineinstr">MachineInstr</a></tt>s and the SelectionDAG is
+ destroyed.</p>
+
+<p>Note that this phase is logically separate from the instruction selection
+ phase, but is tied to it closely in the code because it operates on
+ SelectionDAGs.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="selectiondag_future">Future directions for the SelectionDAG</a>
+</h4>
+
+<div>
+
+<ol>
+ <li>Optional function-at-a-time selection.</li>
+
+ <li>Auto-generate entire selector from <tt>.td</tt> file.</li>
+</ol>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="ssamco">SSA-based Machine Code Optimizations</a>
+</h3>
+<div><p>To Be Written</p></div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="liveintervals">Live Intervals</a>
+</h3>
+
+<div>
+
+<p>Live Intervals are the ranges (intervals) where a variable is <i>live</i>.
+ They are used by some <a href="#regalloc">register allocator</a> passes to
+ determine if two or more virtual registers which require the same physical
+ register are live at the same point in the program (i.e., they conflict).
+ When this situation occurs, one virtual register must be <i>spilled</i>.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="livevariable_analysis">Live Variable Analysis</a>
+</h4>
+
+<div>
+
+<p>The first step in determining the live intervals of variables is to calculate
+ the set of registers that are immediately dead after the instruction (i.e.,
+ the instruction calculates the value, but it is never used) and the set of
+ registers that are used by the instruction, but are never used after the
+ instruction (i.e., they are killed). Live variable information is computed
+ for each <i>virtual</i> register and <i>register allocatable</i> physical
+ register in the function. This is done in a very efficient manner because it
+ uses SSA to sparsely compute lifetime information for virtual registers
+ (which are in SSA form) and only has to track physical registers within a
+ block. Before register allocation, LLVM can assume that physical registers
+ are only live within a single basic block. This allows it to do a single,
+ local analysis to resolve physical register lifetimes within each basic
+ block. If a physical register is not register allocatable (e.g., a stack
+ pointer or condition codes), it is not tracked.</p>
+
+<p>Physical registers may be live in to or out of a function. Live in values are
+ typically arguments in registers. Live out values are typically return values
+ in registers. Live in values are marked as such, and are given a dummy
+ "defining" instruction during live intervals analysis. If the last basic
+ block of a function is a <tt>return</tt>, then it's marked as using all live
+ out values in the function.</p>
+
+<p><tt>PHI</tt> nodes need to be handled specially, because the calculation of
+ the live variable information from a depth first traversal of the CFG of the
+ function won't guarantee that a virtual register used by the <tt>PHI</tt>
+ node is defined before it's used. When a <tt>PHI</tt> node is encountered,
+ only the definition is handled, because the uses will be handled in other
+ basic blocks.</p>
+
+<p>For each <tt>PHI</tt> node of the current basic block, we simulate an
+ assignment at the end of the current basic block and traverse the successor
+ basic blocks. If a successor basic block has a <tt>PHI</tt> node and one of
+ the <tt>PHI</tt> node's operands is coming from the current basic block, then
+ the variable is marked as <i>alive</i> within the current basic block and all
+ of its predecessor basic blocks, until the basic block with the defining
+ instruction is encountered.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="liveintervals_analysis">Live Intervals Analysis</a>
+</h4>
+
+<div>
+
+<p>We now have the information available to perform the live intervals analysis
+ and build the live intervals themselves. We start off by numbering the basic
+ blocks and machine instructions. We then handle the "live-in" values. These
+ are in physical registers, so the physical register is assumed to be killed
+ by the end of the basic block. Live intervals for virtual registers are
+ computed for some ordering of the machine instructions <tt>[1, N]</tt>. A
+ live interval is an interval <tt>[i, j)</tt>, where <tt>1 <= i <= j
+ < N</tt>, for which a variable is live.</p>
+
+<p><i><b>More to come...</b></i></p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="regalloc">Register Allocation</a>
+</h3>
+
+<div>
+
+<p>The <i>Register Allocation problem</i> consists in mapping a program
+ <i>P<sub>v</sub></i>, that can use an unbounded number of virtual registers,
+ to a program <i>P<sub>p</sub></i> that contains a finite (possibly small)
+ number of physical registers. Each target architecture has a different number
+ of physical registers. If the number of physical registers is not enough to
+ accommodate all the virtual registers, some of them will have to be mapped
+ into memory. These virtuals are called <i>spilled virtuals</i>.</p>
+
+<!-- _______________________________________________________________________ -->
+
+<h4>
+ <a name="regAlloc_represent">How registers are represented in LLVM</a>
+</h4>
+
+<div>
+
+<p>In LLVM, physical registers are denoted by integer numbers that normally
+ range from 1 to 1023. To see how this numbering is defined for a particular
+ architecture, you can read the <tt>GenRegisterNames.inc</tt> file for that
+ architecture. For instance, by
+ inspecting <tt>lib/Target/X86/X86GenRegisterInfo.inc</tt> we see that the
+ 32-bit register <tt>EAX</tt> is denoted by 43, and the MMX register
+ <tt>MM0</tt> is mapped to 65.</p>
+
+<p>Some architectures contain registers that share the same physical location. A
+ notable example is the X86 platform. For instance, in the X86 architecture,
+ the registers <tt>EAX</tt>, <tt>AX</tt> and <tt>AL</tt> share the first eight
+ bits. These physical registers are marked as <i>aliased</i> in LLVM. Given a
+ particular architecture, you can check which registers are aliased by
+ inspecting its <tt>RegisterInfo.td</tt> file. Moreover, the method
+ <tt>MCRegisterInfo::getAliasSet(p_reg)</tt> returns an array containing
+ all the physical registers aliased to the register <tt>p_reg</tt>.</p>
+
+<p>Physical registers, in LLVM, are grouped in <i>Register Classes</i>.
+ Elements in the same register class are functionally equivalent, and can be
+ interchangeably used. Each virtual register can only be mapped to physical
+ registers of a particular class. For instance, in the X86 architecture, some
+ virtuals can only be allocated to 8 bit registers. A register class is
+ described by <tt>TargetRegisterClass</tt> objects. To discover if a virtual
+ register is compatible with a given physical, this code can be used:</p>
+
+<div class="doc_code">
+<pre>
+bool RegMapping_Fer::compatible_class(MachineFunction &mf,
+ unsigned v_reg,
+ unsigned p_reg) {
+ assert(TargetRegisterInfo::isPhysicalRegister(p_reg) &&
+ "Target register must be physical");
+ const TargetRegisterClass *trc = mf.getRegInfo().getRegClass(v_reg);
+ return trc->contains(p_reg);
+}
+</pre>
+</div>
+
+<p>Sometimes, mostly for debugging purposes, it is useful to change the number
+ of physical registers available in the target architecture. This must be done
+ statically, inside the <tt>TargetRegsterInfo.td</tt> file. Just <tt>grep</tt>
+ for <tt>RegisterClass</tt>, the last parameter of which is a list of
+ registers. Just commenting some out is one simple way to avoid them being
+ used. A more polite way is to explicitly exclude some registers from
+ the <i>allocation order</i>. See the definition of the <tt>GR8</tt> register
+ class in <tt>lib/Target/X86/X86RegisterInfo.td</tt> for an example of this.
+ </p>
+
+<p>Virtual registers are also denoted by integer numbers. Contrary to physical
+ registers, different virtual registers never share the same number. Whereas
+ physical registers are statically defined in a <tt>TargetRegisterInfo.td</tt>
+ file and cannot be created by the application developer, that is not the case
+ with virtual registers. In order to create new virtual registers, use the
+ method <tt>MachineRegisterInfo::createVirtualRegister()</tt>. This method
+ will return a new virtual register. Use an <tt>IndexedMap<Foo,
+ VirtReg2IndexFunctor></tt> to hold information per virtual register. If you
+ need to enumerate all virtual registers, use the function
+ <tt>TargetRegisterInfo::index2VirtReg()</tt> to find the virtual register
+ numbers:</p>
+
+<div class="doc_code">
+<pre>
+ for (unsigned i = 0, e = MRI->getNumVirtRegs(); i != e; ++i) {
+ unsigned VirtReg = TargetRegisterInfo::index2VirtReg(i);
+ stuff(VirtReg);
+ }
+</pre>
+</div>
+
+<p>Before register allocation, the operands of an instruction are mostly virtual
+ registers, although physical registers may also be used. In order to check if
+ a given machine operand is a register, use the boolean
+ function <tt>MachineOperand::isRegister()</tt>. To obtain the integer code of
+ a register, use <tt>MachineOperand::getReg()</tt>. An instruction may define
+ or use a register. For instance, <tt>ADD reg:1026 := reg:1025 reg:1024</tt>
+ defines the registers 1024, and uses registers 1025 and 1026. Given a
+ register operand, the method <tt>MachineOperand::isUse()</tt> informs if that
+ register is being used by the instruction. The
+ method <tt>MachineOperand::isDef()</tt> informs if that registers is being
+ defined.</p>
+
+<p>We will call physical registers present in the LLVM bitcode before register
+ allocation <i>pre-colored registers</i>. Pre-colored registers are used in
+ many different situations, for instance, to pass parameters of functions
+ calls, and to store results of particular instructions. There are two types
+ of pre-colored registers: the ones <i>implicitly</i> defined, and
+ those <i>explicitly</i> defined. Explicitly defined registers are normal
+ operands, and can be accessed
+ with <tt>MachineInstr::getOperand(int)::getReg()</tt>. In order to check
+ which registers are implicitly defined by an instruction, use
+ the <tt>TargetInstrInfo::get(opcode)::ImplicitDefs</tt>,
+ where <tt>opcode</tt> is the opcode of the target instruction. One important
+ difference between explicit and implicit physical registers is that the
+ latter are defined statically for each instruction, whereas the former may
+ vary depending on the program being compiled. For example, an instruction
+ that represents a function call will always implicitly define or use the same
+ set of physical registers. To read the registers implicitly used by an
+ instruction,
+ use <tt>TargetInstrInfo::get(opcode)::ImplicitUses</tt>. Pre-colored
+ registers impose constraints on any register allocation algorithm. The
+ register allocator must make sure that none of them are overwritten by
+ the values of virtual registers while still alive.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+
+<h4>
+ <a name="regAlloc_howTo">Mapping virtual registers to physical registers</a>
+</h4>
+
+<div>
+
+<p>There are two ways to map virtual registers to physical registers (or to
+ memory slots). The first way, that we will call <i>direct mapping</i>, is
+ based on the use of methods of the classes <tt>TargetRegisterInfo</tt>,
+ and <tt>MachineOperand</tt>. The second way, that we will call <i>indirect
+ mapping</i>, relies on the <tt>VirtRegMap</tt> class in order to insert loads
+ and stores sending and getting values to and from memory.</p>
+
+<p>The direct mapping provides more flexibility to the developer of the register
+ allocator; however, it is more error prone, and demands more implementation
+ work. Basically, the programmer will have to specify where load and store
+ instructions should be inserted in the target function being compiled in
+ order to get and store values in memory. To assign a physical register to a
+ virtual register present in a given operand,
+ use <tt>MachineOperand::setReg(p_reg)</tt>. To insert a store instruction,
+ use <tt>TargetInstrInfo::storeRegToStackSlot(...)</tt>, and to insert a
+ load instruction, use <tt>TargetInstrInfo::loadRegFromStackSlot</tt>.</p>
+
+<p>The indirect mapping shields the application developer from the complexities
+ of inserting load and store instructions. In order to map a virtual register
+ to a physical one, use <tt>VirtRegMap::assignVirt2Phys(vreg, preg)</tt>. In
+ order to map a certain virtual register to memory,
+ use <tt>VirtRegMap::assignVirt2StackSlot(vreg)</tt>. This method will return
+ the stack slot where <tt>vreg</tt>'s value will be located. If it is
+ necessary to map another virtual register to the same stack slot,
+ use <tt>VirtRegMap::assignVirt2StackSlot(vreg, stack_location)</tt>. One
+ important point to consider when using the indirect mapping, is that even if
+ a virtual register is mapped to memory, it still needs to be mapped to a
+ physical register. This physical register is the location where the virtual
+ register is supposed to be found before being stored or after being
+ reloaded.</p>
+
+<p>If the indirect strategy is used, after all the virtual registers have been
+ mapped to physical registers or stack slots, it is necessary to use a spiller
+ object to place load and store instructions in the code. Every virtual that
+ has been mapped to a stack slot will be stored to memory after been defined
+ and will be loaded before being used. The implementation of the spiller tries
+ to recycle load/store instructions, avoiding unnecessary instructions. For an
+ example of how to invoke the spiller,
+ see <tt>RegAllocLinearScan::runOnMachineFunction</tt>
+ in <tt>lib/CodeGen/RegAllocLinearScan.cpp</tt>.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="regAlloc_twoAddr">Handling two address instructions</a>
+</h4>
+
+<div>
+
+<p>With very rare exceptions (e.g., function calls), the LLVM machine code
+ instructions are three address instructions. That is, each instruction is
+ expected to define at most one register, and to use at most two registers.
+ However, some architectures use two address instructions. In this case, the
+ defined register is also one of the used register. For instance, an
+ instruction such as <tt>ADD %EAX, %EBX</tt>, in X86 is actually equivalent
+ to <tt>%EAX = %EAX + %EBX</tt>.</p>
+
+<p>In order to produce correct code, LLVM must convert three address
+ instructions that represent two address instructions into true two address
+ instructions. LLVM provides the pass <tt>TwoAddressInstructionPass</tt> for
+ this specific purpose. It must be run before register allocation takes
+ place. After its execution, the resulting code may no longer be in SSA
+ form. This happens, for instance, in situations where an instruction such
+ as <tt>%a = ADD %b %c</tt> is converted to two instructions such as:</p>
+
+<div class="doc_code">
+<pre>
+%a = MOVE %b
+%a = ADD %a %c
+</pre>
+</div>
+
+<p>Notice that, internally, the second instruction is represented as
+ <tt>ADD %a[def/use] %c</tt>. I.e., the register operand <tt>%a</tt> is both
+ used and defined by the instruction.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="regAlloc_ssaDecon">The SSA deconstruction phase</a>
+</h4>
+
+<div>
+
+<p>An important transformation that happens during register allocation is called
+ the <i>SSA Deconstruction Phase</i>. The SSA form simplifies many analyses
+ that are performed on the control flow graph of programs. However,
+ traditional instruction sets do not implement PHI instructions. Thus, in
+ order to generate executable code, compilers must replace PHI instructions
+ with other instructions that preserve their semantics.</p>
+
+<p>There are many ways in which PHI instructions can safely be removed from the
+ target code. The most traditional PHI deconstruction algorithm replaces PHI
+ instructions with copy instructions. That is the strategy adopted by
+ LLVM. The SSA deconstruction algorithm is implemented
+ in <tt>lib/CodeGen/PHIElimination.cpp</tt>. In order to invoke this pass, the
+ identifier <tt>PHIEliminationID</tt> must be marked as required in the code
+ of the register allocator.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="regAlloc_fold">Instruction folding</a>
+</h4>
+
+<div>
+
+<p><i>Instruction folding</i> is an optimization performed during register
+ allocation that removes unnecessary copy instructions. For instance, a
+ sequence of instructions such as:</p>
+
+<div class="doc_code">
+<pre>
+%EBX = LOAD %mem_address
+%EAX = COPY %EBX
+</pre>
+</div>
+
+<p>can be safely substituted by the single instruction:</p>
+
+<div class="doc_code">
+<pre>
+%EAX = LOAD %mem_address
+</pre>
+</div>
+
+<p>Instructions can be folded with
+ the <tt>TargetRegisterInfo::foldMemoryOperand(...)</tt> method. Care must be
+ taken when folding instructions; a folded instruction can be quite different
+ from the original
+ instruction. See <tt>LiveIntervals::addIntervalsForSpills</tt>
+ in <tt>lib/CodeGen/LiveIntervalAnalysis.cpp</tt> for an example of its
+ use.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+
+<h4>
+ <a name="regAlloc_builtIn">Built in register allocators</a>
+</h4>
+
+<div>
+
+<p>The LLVM infrastructure provides the application developer with three
+ different register allocators:</p>
+
+<ul>
+ <li><i>Fast</i> — This register allocator is the default for debug
+ builds. It allocates registers on a basic block level, attempting to keep
+ values in registers and reusing registers as appropriate.</li>
+
+ <li><i>Basic</i> — This is an incremental approach to register
+ allocation. Live ranges are assigned to registers one at a time in
+ an order that is driven by heuristics. Since code can be rewritten
+ on-the-fly during allocation, this framework allows interesting
+ allocators to be developed as extensions. It is not itself a
+ production register allocator but is a potentially useful
+ stand-alone mode for triaging bugs and as a performance baseline.
+
+ <li><i>Greedy</i> — <i>The default allocator</i>. This is a
+ highly tuned implementation of the <i>Basic</i> allocator that
+ incorporates global live range splitting. This allocator works hard
+ to minimize the cost of spill code.
+
+ <li><i>PBQP</i> — A Partitioned Boolean Quadratic Programming (PBQP)
+ based register allocator. This allocator works by constructing a PBQP
+ problem representing the register allocation problem under consideration,
+ solving this using a PBQP solver, and mapping the solution back to a
+ register assignment.</li>
+</ul>
+
+<p>The type of register allocator used in <tt>llc</tt> can be chosen with the
+ command line option <tt>-regalloc=...</tt>:</p>
+
+<div class="doc_code">
+<pre>
+$ llc -regalloc=linearscan file.bc -o ln.s;
+$ llc -regalloc=fast file.bc -o fa.s;
+$ llc -regalloc=pbqp file.bc -o pbqp.s;
+</pre>
+</div>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="proepicode">Prolog/Epilog Code Insertion</a>
+</h3>
+
+<div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="compact_unwind">Compact Unwind</a>
+</h4>
+
+<div>
+
+<p>Throwing an exception requires <em>unwinding</em> out of a function. The
+ information on how to unwind a given function is traditionally expressed in
+ DWARF unwind (a.k.a. frame) info. But that format was originally developed
+ for debuggers to backtrace, and each Frame Description Entry (FDE) requires
+ ~20-30 bytes per function. There is also the cost of mapping from an address
+ in a function to the corresponding FDE at runtime. An alternative unwind
+ encoding is called <em>compact unwind</em> and requires just 4-bytes per
+ function.</p>
+
+<p>The compact unwind encoding is a 32-bit value, which is encoded in an
+ architecture-specific way. It specifies which registers to restore and from
+ where, and how to unwind out of the function. When the linker creates a final
+ linked image, it will create a <code>__TEXT,__unwind_info</code>
+ section. This section is a small and fast way for the runtime to access
+ unwind info for any given function. If we emit compact unwind info for the
+ function, that compact unwind info will be encoded in
+ the <code>__TEXT,__unwind_info</code> section. If we emit DWARF unwind info,
+ the <code>__TEXT,__unwind_info</code> section will contain the offset of the
+ FDE in the <code>__TEXT,__eh_frame</code> section in the final linked
+ image.</p>
+
+<p>For X86, there are three modes for the compact unwind encoding:</p>
+
+<dl>
+ <dt><i>Function with a Frame Pointer (<code>EBP</code> or <code>RBP</code>)</i></dt>
+ <dd><p><code>EBP/RBP</code>-based frame, where <code>EBP/RBP</code> is pushed
+ onto the stack immediately after the return address,
+ then <code>ESP/RSP</code> is moved to <code>EBP/RBP</code>. Thus to
+ unwind, <code>ESP/RSP</code> is restored with the
+ current <code>EBP/RBP</code> value, then <code>EBP/RBP</code> is restored
+ by popping the stack, and the return is done by popping the stack once
+ more into the PC. All non-volatile registers that need to be restored must
+ have been saved in a small range on the stack that
+ starts <code>EBP-4</code> to <code>EBP-1020</code> (<code>RBP-8</code>
+ to <code>RBP-1020</code>). The offset (divided by 4 in 32-bit mode and 8
+ in 64-bit mode) is encoded in bits 16-23 (mask: <code>0x00FF0000</code>).
+ The registers saved are encoded in bits 0-14
+ (mask: <code>0x00007FFF</code>) as five 3-bit entries from the following
+ table:</p>
+<table border="1" cellspacing="0">
+ <tr>
+ <th>Compact Number</th>
+ <th>i386 Register</th>
+ <th>x86-64 Regiser</th>
+ </tr>
+ <tr>
+ <td>1</td>
+ <td><code>EBX</code></td>
+ <td><code>RBX</code></td>
+ </tr>
+ <tr>
+ <td>2</td>
+ <td><code>ECX</code></td>
+ <td><code>R12</code></td>
+ </tr>
+ <tr>
+ <td>3</td>
+ <td><code>EDX</code></td>
+ <td><code>R13</code></td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td><code>EDI</code></td>
+ <td><code>R14</code></td>
+ </tr>
+ <tr>
+ <td>5</td>
+ <td><code>ESI</code></td>
+ <td><code>R15</code></td>
+ </tr>
+ <tr>
+ <td>6</td>
+ <td><code>EBP</code></td>
+ <td><code>RBP</code></td>
+ </tr>
+</table>
+
+</dd>
+
+ <dt><i>Frameless with a Small Constant Stack Size (<code>EBP</code>
+ or <code>RBP</code> is not used as a frame pointer)</i></dt>
+ <dd><p>To return, a constant (encoded in the compact unwind encoding) is added
+ to the <code>ESP/RSP</code>. Then the return is done by popping the stack
+ into the PC. All non-volatile registers that need to be restored must have
+ been saved on the stack immediately after the return address. The stack
+ size (divided by 4 in 32-bit mode and 8 in 64-bit mode) is encoded in bits
+ 16-23 (mask: <code>0x00FF0000</code>). There is a maximum stack size of
+ 1024 bytes in 32-bit mode and 2048 in 64-bit mode. The number of registers
+ saved is encoded in bits 9-12 (mask: <code>0x00001C00</code>). Bits 0-9
+ (mask: <code>0x000003FF</code>) contain which registers were saved and
+ their order. (See
+ the <code>encodeCompactUnwindRegistersWithoutFrame()</code> function
+ in <code>lib/Target/X86FrameLowering.cpp</code> for the encoding
+ algorithm.)</p></dd>
+
+ <dt><i>Frameless with a Large Constant Stack Size (<code>EBP</code>
+ or <code>RBP</code> is not used as a frame pointer)</i></dt>
+ <dd><p>This case is like the "Frameless with a Small Constant Stack Size"
+ case, but the stack size is too large to encode in the compact unwind
+ encoding. Instead it requires that the function contains "<code>subl
+ $nnnnnn, %esp</code>" in its prolog. The compact encoding contains the
+ offset to the <code>$nnnnnn</code> value in the function in bits 9-12
+ (mask: <code>0x00001C00</code>).</p></dd>
+</dl>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="latemco">Late Machine Code Optimizations</a>
+</h3>
+<div><p>To Be Written</p></div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="codeemit">Code Emission</a>
+</h3>
+
+<div>
+
+<p>The code emission step of code generation is responsible for lowering from
+the code generator abstractions (like <a
+href="#machinefunction">MachineFunction</a>, <a
+href="#machineinstr">MachineInstr</a>, etc) down
+to the abstractions used by the MC layer (<a href="#mcinst">MCInst</a>,
+<a href="#mcstreamer">MCStreamer</a>, etc). This is
+done with a combination of several different classes: the (misnamed)
+target-independent AsmPrinter class, target-specific subclasses of AsmPrinter
+(such as SparcAsmPrinter), and the TargetLoweringObjectFile class.</p>
+
+<p>Since the MC layer works at the level of abstraction of object files, it
+doesn't have a notion of functions, global variables etc. Instead, it thinks
+about labels, directives, and instructions. A key class used at this time is
+the MCStreamer class. This is an abstract API that is implemented in different
+ways (e.g. to output a .s file, output an ELF .o file, etc) that is effectively
+an "assembler API". MCStreamer has one method per directive, such as EmitLabel,
+EmitSymbolAttribute, SwitchSection, etc, which directly correspond to assembly
+level directives.
+</p>
+
+<p>If you are interested in implementing a code generator for a target, there
+are three important things that you have to implement for your target:</p>
+
+<ol>
+<li>First, you need a subclass of AsmPrinter for your target. This class
+implements the general lowering process converting MachineFunction's into MC
+label constructs. The AsmPrinter base class provides a number of useful methods
+and routines, and also allows you to override the lowering process in some
+important ways. You should get much of the lowering for free if you are
+implementing an ELF, COFF, or MachO target, because the TargetLoweringObjectFile
+class implements much of the common logic.</li>
+
+<li>Second, you need to implement an instruction printer for your target. The
+instruction printer takes an <a href="#mcinst">MCInst</a> and renders it to a
+raw_ostream as text. Most of this is automatically generated from the .td file
+(when you specify something like "<tt>add $dst, $src1, $src2</tt>" in the
+instructions), but you need to implement routines to print operands.</li>
+
+<li>Third, you need to implement code that lowers a <a
+href="#machineinstr">MachineInstr</a> to an MCInst, usually implemented in
+"<target>MCInstLower.cpp". This lowering process is often target
+specific, and is responsible for turning jump table entries, constant pool
+indices, global variable addresses, etc into MCLabels as appropriate. This
+translation layer is also responsible for expanding pseudo ops used by the code
+generator into the actual machine instructions they correspond to. The MCInsts
+that are generated by this are fed into the instruction printer or the encoder.
+</li>
+
+</ol>
+
+<p>Finally, at your choosing, you can also implement an subclass of
+MCCodeEmitter which lowers MCInst's into machine code bytes and relocations.
+This is important if you want to support direct .o file emission, or would like
+to implement an assembler for your target.</p>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="vliw_packetizer">VLIW Packetizer</a>
+</h3>
+
+<div>
+
+<p>In a Very Long Instruction Word (VLIW) architecture, the compiler is
+ responsible for mapping instructions to functional-units available on
+ the architecture. To that end, the compiler creates groups of instructions
+ called <i>packets</i> or <i>bundles</i>. The VLIW packetizer in LLVM is
+ a target-independent mechanism to enable the packetization of machine
+ instructions.</p>
+
+<!-- _______________________________________________________________________ -->
+
+<h4>
+ <a name="vliw_mapping">Mapping from instructions to functional units</a>
+</h4>
+
+<div>
+
+<p>Instructions in a VLIW target can typically be mapped to multiple functional
+units. During the process of packetizing, the compiler must be able to reason
+about whether an instruction can be added to a packet. This decision can be
+complex since the compiler has to examine all possible mappings of instructions
+to functional units. Therefore to alleviate compilation-time complexity, the
+VLIW packetizer parses the instruction classes of a target and generates tables
+at compiler build time. These tables can then be queried by the provided
+machine-independent API to determine if an instruction can be accommodated in a
+packet.</p>
+</div>
+
+<!-- ======================================================================= -->
+<h4>
+ <a name="vliw_repr">
+ How the packetization tables are generated and used
+ </a>
+</h4>
+
+<div>
+
+<p>The packetizer reads instruction classes from a target's itineraries and
+creates a deterministic finite automaton (DFA) to represent the state of a
+packet. A DFA consists of three major elements: inputs, states, and
+transitions. The set of inputs for the generated DFA represents the instruction
+being added to a packet. The states represent the possible consumption
+of functional units by instructions in a packet. In the DFA, transitions from
+one state to another occur on the addition of an instruction to an existing
+packet. If there is a legal mapping of functional units to instructions, then
+the DFA contains a corresponding transition. The absence of a transition
+indicates that a legal mapping does not exist and that the instruction cannot
+be added to the packet.</p>
+
+<p>To generate tables for a VLIW target, add <i>Target</i>GenDFAPacketizer.inc
+as a target to the Makefile in the target directory. The exported API provides
+three functions: <tt>DFAPacketizer::clearResources()</tt>,
+<tt>DFAPacketizer::reserveResources(MachineInstr *MI)</tt>, and
+<tt>DFAPacketizer::canReserveResources(MachineInstr *MI)</tt>. These functions
+allow a target packetizer to add an instruction to an existing packet and to
+check whether an instruction can be added to a packet. See
+<tt>llvm/CodeGen/DFAPacketizer.h</tt> for more information.</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="nativeassembler">Implementing a Native Assembler</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>Though you're probably reading this because you want to write or maintain a
+compiler backend, LLVM also fully supports building a native assemblers too.
+We've tried hard to automate the generation of the assembler from the .td files
+(in particular the instruction syntax and encodings), which means that a large
+part of the manual and repetitive data entry can be factored and shared with the
+compiler.</p>
+
+<!-- ======================================================================= -->
+<h3 id="na_instparsing">Instruction Parsing</h3>
+
+<div><p>To Be Written</p></div>
+
+
+<!-- ======================================================================= -->
+<h3 id="na_instaliases">
+ Instruction Alias Processing
+</h3>
+
+<div>
+<p>Once the instruction is parsed, it enters the MatchInstructionImpl function.
+The MatchInstructionImpl function performs alias processing and then does
+actual matching.</p>
+
+<p>Alias processing is the phase that canonicalizes different lexical forms of
+the same instructions down to one representation. There are several different
+kinds of alias that are possible to implement and they are listed below in the
+order that they are processed (which is in order from simplest/weakest to most
+complex/powerful). Generally you want to use the first alias mechanism that
+meets the needs of your instruction, because it will allow a more concise
+description.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>Mnemonic Aliases</h4>
+
+<div>
+
+<p>The first phase of alias processing is simple instruction mnemonic
+remapping for classes of instructions which are allowed with two different
+mnemonics. This phase is a simple and unconditionally remapping from one input
+mnemonic to one output mnemonic. It isn't possible for this form of alias to
+look at the operands at all, so the remapping must apply for all forms of a
+given mnemonic. Mnemonic aliases are defined simply, for example X86 has:
+</p>
+
+<div class="doc_code">
+<pre>
+def : MnemonicAlias<"cbw", "cbtw">;
+def : MnemonicAlias<"smovq", "movsq">;
+def : MnemonicAlias<"fldcww", "fldcw">;
+def : MnemonicAlias<"fucompi", "fucomip">;
+def : MnemonicAlias<"ud2a", "ud2">;
+</pre>
+</div>
+
+<p>... and many others. With a MnemonicAlias definition, the mnemonic is
+remapped simply and directly. Though MnemonicAlias's can't look at any aspect
+of the instruction (such as the operands) they can depend on global modes (the
+same ones supported by the matcher), through a Requires clause:</p>
+
+<div class="doc_code">
+<pre>
+def : MnemonicAlias<"pushf", "pushfq">, Requires<[In64BitMode]>;
+def : MnemonicAlias<"pushf", "pushfl">, Requires<[In32BitMode]>;
+</pre>
+</div>
+
+<p>In this example, the mnemonic gets mapped into different a new one depending
+on the current instruction set.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>Instruction Aliases</h4>
+
+<div>
+
+<p>The most general phase of alias processing occurs while matching is
+happening: it provides new forms for the matcher to match along with a specific
+instruction to generate. An instruction alias has two parts: the string to
+match and the instruction to generate. For example:
+</p>
+
+<div class="doc_code">
+<pre>
+def : InstAlias<"movsx $src, $dst", (MOVSX16rr8W GR16:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX16rm8W GR16:$dst, i8mem:$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr8 GR32:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX32rr16 GR32:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr8 GR64:$dst, GR8 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr16 GR64:$dst, GR16 :$src)>;
+def : InstAlias<"movsx $src, $dst", (MOVSX64rr32 GR64:$dst, GR32 :$src)>;
+</pre>
+</div>
+
+<p>This shows a powerful example of the instruction aliases, matching the
+same mnemonic in multiple different ways depending on what operands are present
+in the assembly. The result of instruction aliases can include operands in a
+different order than the destination instruction, and can use an input
+multiple times, for example:</p>
+
+<div class="doc_code">
+<pre>
+def : InstAlias<"clrb $reg", (XOR8rr GR8 :$reg, GR8 :$reg)>;
+def : InstAlias<"clrw $reg", (XOR16rr GR16:$reg, GR16:$reg)>;
+def : InstAlias<"clrl $reg", (XOR32rr GR32:$reg, GR32:$reg)>;
+def : InstAlias<"clrq $reg", (XOR64rr GR64:$reg, GR64:$reg)>;
+</pre>
+</div>
+
+<p>This example also shows that tied operands are only listed once. In the X86
+backend, XOR8rr has two input GR8's and one output GR8 (where an input is tied
+to the output). InstAliases take a flattened operand list without duplicates
+for tied operands. The result of an instruction alias can also use immediates
+and fixed physical registers which are added as simple immediate operands in the
+result, for example:</p>
+
+<div class="doc_code">
+<pre>
+// Fixed Immediate operand.
+def : InstAlias<"aad", (AAD8i8 10)>;
+
+// Fixed register operand.
+def : InstAlias<"fcomi", (COM_FIr ST1)>;
+
+// Simple alias.
+def : InstAlias<"fcomi $reg", (COM_FIr RST:$reg)>;
+</pre>
+</div>
+
+
+<p>Instruction aliases can also have a Requires clause to make them
+subtarget specific.</p>
+
+<p>If the back-end supports it, the instruction printer can automatically emit
+ the alias rather than what's being aliased. It typically leads to better,
+ more readable code. If it's better to print out what's being aliased, then
+ pass a '0' as the third parameter to the InstAlias definition.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3 id="na_matching">Instruction Matching</h3>
+
+<div><p>To Be Written</p></div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="targetimpls">Target-specific Implementation Notes</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This section of the document explains features or design decisions that are
+ specific to the code generator for a particular target. First we start
+ with a table that summarizes what features are supported by each target.</p>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="targetfeatures">Target Feature Matrix</a>
+</h3>
+
+<div>
+
+<p>Note that this table does not include the C backend or Cpp backends, since
+they do not use the target independent code generator infrastructure. It also
+doesn't list features that are not supported fully by any target yet. It
+considers a feature to be supported if at least one subtarget supports it. A
+feature being supported means that it is useful and works for most cases, it
+does not indicate that there are zero known bugs in the implementation. Here
+is the key:</p>
+
+
+<table border="1" cellspacing="0">
+ <tr>
+ <th>Unknown</th>
+ <th>No support</th>
+ <th>Partial Support</th>
+ <th>Complete Support</th>
+ </tr>
+ <tr>
+ <td class="unknown"></td>
+ <td class="no"></td>
+ <td class="partial"></td>
+ <td class="yes"></td>
+ </tr>
+</table>
+
+<p>Here is the table:</p>
+
+<table width="689" border="1" cellspacing="0">
+<tr><td></td>
+<td colspan="13" align="center" style="background-color:#ffc">Target</td>
+</tr>
+ <tr>
+ <th>Feature</th>
+ <th>ARM</th>
+ <th>CellSPU</th>
+ <th>Hexagon</th>
+ <th>MBlaze</th>
+ <th>MSP430</th>
+ <th>Mips</th>
+ <th>PTX</th>
+ <th>PowerPC</th>
+ <th>Sparc</th>
+ <th>X86</th>
+ <th>XCore</th>
+ </tr>
+
+<tr>
+ <td><a href="#feat_reliable">is generally reliable</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- Hexagon -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="yes"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="yes"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_asmparser">assembly parser</a></td>
+ <td class="no"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- Hexagon -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_disassembler">disassembler</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- Hexagon -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_inlineasm">inline asm</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- Hexagon -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="unknown"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="unknown"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_jit">jit</a></td>
+ <td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- Hexagon -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="yes"></td> <!-- Mips -->
+ <td class="unknown"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="unknown"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_objectwrite">.o file writing</a></td>
+ <td class="no"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- Hexagon -->
+ <td class="yes"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_tailcall">tail calls</a></td>
+ <td class="yes"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="yes"></td> <!-- Hexagon -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="unknown"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="unknown"></td> <!-- PTX -->
+ <td class="yes"></td> <!-- PowerPC -->
+ <td class="unknown"></td> <!-- Sparc -->
+ <td class="yes"></td> <!-- X86 -->
+ <td class="unknown"></td> <!-- XCore -->
+</tr>
+
+<tr>
+ <td><a href="#feat_segstacks">segmented stacks</a></td>
+ <td class="no"></td> <!-- ARM -->
+ <td class="no"></td> <!-- CellSPU -->
+ <td class="no"></td> <!-- Hexagon -->
+ <td class="no"></td> <!-- MBlaze -->
+ <td class="no"></td> <!-- MSP430 -->
+ <td class="no"></td> <!-- Mips -->
+ <td class="no"></td> <!-- PTX -->
+ <td class="no"></td> <!-- PowerPC -->
+ <td class="no"></td> <!-- Sparc -->
+ <td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 -->
+ <td class="no"></td> <!-- XCore -->
+</tr>
+
+
+</table>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_reliable">Is Generally Reliable</h4>
+
+<div>
+<p>This box indicates whether the target is considered to be production quality.
+This indicates that the target has been used as a static compiler to
+compile large amounts of code by a variety of different people and is in
+continuous use.</p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_asmparser">Assembly Parser</h4>
+
+<div>
+<p>This box indicates whether the target supports parsing target specific .s
+files by implementing the MCAsmParser interface. This is required for llvm-mc
+to be able to act as a native assembler and is required for inline assembly
+support in the native .o file writer.</p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_disassembler">Disassembler</h4>
+
+<div>
+<p>This box indicates whether the target supports the MCDisassembler API for
+disassembling machine opcode bytes into MCInst's.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_inlineasm">Inline Asm</h4>
+
+<div>
+<p>This box indicates whether the target supports most popular inline assembly
+constraints and modifiers.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_jit">JIT Support</h4>
+
+<div>
+<p>This box indicates whether the target supports the JIT compiler through
+the ExecutionEngine interface.</p>
+
+<p id="feat_jit_arm">The ARM backend has basic support for integer code
+in ARM codegen mode, but lacks NEON and full Thumb support.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_objectwrite">.o File Writing</h4>
+
+<div>
+
+<p>This box indicates whether the target supports writing .o files (e.g. MachO,
+ELF, and/or COFF) files directly from the target. Note that the target also
+must include an assembly parser and general inline assembly support for full
+inline assembly support in the .o writer.</p>
+
+<p>Targets that don't support this feature can obviously still write out .o
+files, they just rely on having an external assembler to translate from a .s
+file to a .o file (as is the case for many C compilers).</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_tailcall">Tail Calls</h4>
+
+<div>
+
+<p>This box indicates whether the target supports guaranteed tail calls. These
+are calls marked "<a href="LangRef.html#i_call">tail</a>" and use the fastcc
+calling convention. Please see the <a href="#tailcallopt">tail call section
+more more details</a>.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4 id="feat_segstacks">Segmented Stacks</h4>
+
+<div>
+
+<p>This box indicates whether the target supports segmented stacks. This
+replaces the traditional large C stack with many linked segments. It
+is compatible with the <a href="http://gcc.gnu.org/wiki/SplitStacks">gcc
+implementation</a> used by the Go front end.</p>
+
+<p id="feat_segstacks_x86">Basic support exists on the X86 backend. Currently
+vararg doesn't work and the object files are not marked the way the gold
+linker expects, but simple Go programs can be built by dragonegg.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="tailcallopt">Tail call optimization</a>
+</h3>
+
+<div>
+
+<p>Tail call optimization, callee reusing the stack of the caller, is currently
+ supported on x86/x86-64 and PowerPC. It is performed if:</p>
+
+<ul>
+ <li>Caller and callee have the calling convention <tt>fastcc</tt> or
+ <tt>cc 10</tt> (GHC call convention).</li>
+
+ <li>The call is a tail call - in tail position (ret immediately follows call
+ and ret uses value of call or is void).</li>
+
+ <li>Option <tt>-tailcallopt</tt> is enabled.</li>
+
+ <li>Platform specific constraints are met.</li>
+</ul>
+
+<p>x86/x86-64 constraints:</p>
+
+<ul>
+ <li>No variable argument lists are used.</li>
+
+ <li>On x86-64 when generating GOT/PIC code only module-local calls (visibility
+ = hidden or protected) are supported.</li>
+</ul>
+
+<p>PowerPC constraints:</p>
+
+<ul>
+ <li>No variable argument lists are used.</li>
+
+ <li>No byval parameters are used.</li>
+
+ <li>On ppc32/64 GOT/PIC only module-local calls (visibility = hidden or protected) are supported.</li>
+</ul>
+
+<p>Example:</p>
+
+<p>Call as <tt>llc -tailcallopt test.ll</tt>.</p>
+
+<div class="doc_code">
+<pre>
+declare fastcc i32 @tailcallee(i32 inreg %a1, i32 inreg %a2, i32 %a3, i32 %a4)
+
+define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
+ %l1 = add i32 %in1, %in2
+ %tmp = tail call fastcc i32 @tailcallee(i32 %in1 inreg, i32 %in2 inreg, i32 %in1, i32 %l1)
+ ret i32 %tmp
+}
+</pre>
+</div>
+
+<p>Implications of <tt>-tailcallopt</tt>:</p>
+
+<p>To support tail call optimization in situations where the callee has more
+ arguments than the caller a 'callee pops arguments' convention is used. This
+ currently causes each <tt>fastcc</tt> call that is not tail call optimized
+ (because one or more of above constraints are not met) to be followed by a
+ readjustment of the stack. So performance might be worse in such cases.</p>
+
+</div>
+<!-- ======================================================================= -->
+<h3>
+ <a name="sibcallopt">Sibling call optimization</a>
+</h3>
+
+<div>
+
+<p>Sibling call optimization is a restricted form of tail call optimization.
+ Unlike tail call optimization described in the previous section, it can be
+ performed automatically on any tail calls when <tt>-tailcallopt</tt> option
+ is not specified.</p>
+
+<p>Sibling call optimization is currently performed on x86/x86-64 when the
+ following constraints are met:</p>
+
+<ul>
+ <li>Caller and callee have the same calling convention. It can be either
+ <tt>c</tt> or <tt>fastcc</tt>.
+
+ <li>The call is a tail call - in tail position (ret immediately follows call
+ and ret uses value of call or is void).</li>
+
+ <li>Caller and callee have matching return type or the callee result is not
+ used.
+
+ <li>If any of the callee arguments are being passed in stack, they must be
+ available in caller's own incoming argument stack and the frame offsets
+ must be the same.
+</ul>
+
+<p>Example:</p>
+<div class="doc_code">
+<pre>
+declare i32 @bar(i32, i32)
+
+define i32 @foo(i32 %a, i32 %b, i32 %c) {
+entry:
+ %0 = tail call i32 @bar(i32 %a, i32 %b)
+ ret i32 %0
+}
+</pre>
+</div>
+
+</div>
+<!-- ======================================================================= -->
+<h3>
+ <a name="x86">The X86 backend</a>
+</h3>
+
+<div>
+
+<p>The X86 code generator lives in the <tt>lib/Target/X86</tt> directory. This
+ code generator is capable of targeting a variety of x86-32 and x86-64
+ processors, and includes support for ISA extensions such as MMX and SSE.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="x86_tt">X86 Target Triples supported</a>
+</h4>
+
+<div>
+
+<p>The following are the known target triples that are supported by the X86
+ backend. This is not an exhaustive list, and it would be useful to add those
+ that people test.</p>
+
+<ul>
+ <li><b>i686-pc-linux-gnu</b> — Linux</li>
+
+ <li><b>i386-unknown-freebsd5.3</b> — FreeBSD 5.3</li>
+
+ <li><b>i686-pc-cygwin</b> — Cygwin on Win32</li>
+
+ <li><b>i686-pc-mingw32</b> — MingW on Win32</li>
+
+ <li><b>i386-pc-mingw32msvc</b> — MingW crosscompiler on Linux</li>
+
+ <li><b>i686-apple-darwin*</b> — Apple Darwin on X86</li>
+
+ <li><b>x86_64-unknown-linux-gnu</b> — Linux</li>
+</ul>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="x86_cc">X86 Calling Conventions supported</a>
+</h4>
+
+
+<div>
+
+<p>The following target-specific calling conventions are known to backend:</p>
+
+<ul>
+<li><b>x86_StdCall</b> — stdcall calling convention seen on Microsoft
+ Windows platform (CC ID = 64).</li>
+<li><b>x86_FastCall</b> — fastcall calling convention seen on Microsoft
+ Windows platform (CC ID = 65).</li>
+<li><b>x86_ThisCall</b> — Similar to X86_StdCall. Passes first argument
+ in ECX, others via stack. Callee is responsible for stack cleaning. This
+ convention is used by MSVC by default for methods in its ABI
+ (CC ID = 70).</li>
+</ul>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="x86_memory">Representing X86 addressing modes in MachineInstrs</a>
+</h4>
+
+<div>
+
+<p>The x86 has a very flexible way of accessing memory. It is capable of
+ forming memory addresses of the following expression directly in integer
+ instructions (which use ModR/M addressing):</p>
+
+<div class="doc_code">
+<pre>
+SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32
+</pre>
+</div>
+
+<p>In order to represent this, LLVM tracks no less than 5 operands for each
+ memory operand of this form. This means that the "load" form of
+ '<tt>mov</tt>' has the following <tt>MachineOperand</tt>s in this order:</p>
+
+<div class="doc_code">
+<pre>
+Index: 0 | 1 2 3 4 5
+Meaning: DestReg, | BaseReg, Scale, IndexReg, Displacement Segment
+OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg
+</pre>
+</div>
+
+<p>Stores, and all other instructions, treat the four memory operands in the
+ same way and in the same order. If the segment register is unspecified
+ (regno = 0), then no segment override is generated. "Lea" operations do not
+ have a segment register specified, so they only have 4 operands for their
+ memory reference.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="x86_memory">X86 address spaces supported</a>
+</h4>
+
+<div>
+
+<p>x86 has a feature which provides
+ the ability to perform loads and stores to different address spaces
+ via the x86 segment registers. A segment override prefix byte on an
+ instruction causes the instruction's memory access to go to the specified
+ segment. LLVM address space 0 is the default address space, which includes
+ the stack, and any unqualified memory accesses in a program. Address spaces
+ 1-255 are currently reserved for user-defined code. The GS-segment is
+ represented by address space 256, while the FS-segment is represented by
+ address space 257. Other x86 segments have yet to be allocated address space
+ numbers.</p>
+
+<p>While these address spaces may seem similar to TLS via the
+ <tt>thread_local</tt> keyword, and often use the same underlying hardware,
+ there are some fundamental differences.</p>
+
+<p>The <tt>thread_local</tt> keyword applies to global variables and
+ specifies that they are to be allocated in thread-local memory. There are
+ no type qualifiers involved, and these variables can be pointed to with
+ normal pointers and accessed with normal loads and stores.
+ The <tt>thread_local</tt> keyword is target-independent at the LLVM IR
+ level (though LLVM doesn't yet have implementations of it for some
+ configurations).<p>
+
+<p>Special address spaces, in contrast, apply to static types. Every
+ load and store has a particular address space in its address operand type,
+ and this is what determines which address space is accessed.
+ LLVM ignores these special address space qualifiers on global variables,
+ and does not provide a way to directly allocate storage in them.
+ At the LLVM IR level, the behavior of these special address spaces depends
+ in part on the underlying OS or runtime environment, and they are specific
+ to x86 (and LLVM doesn't yet handle them correctly in some cases).</p>
+
+<p>Some operating systems and runtime environments use (or may in the future
+ use) the FS/GS-segment registers for various low-level purposes, so care
+ should be taken when considering them.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="x86_names">Instruction naming</a>
+</h4>
+
+<div>
+
+<p>An instruction name consists of the base name, a default operand size, and a
+ a character per operand with an optional special size. For example:</p>
+
+<div class="doc_code">
+<pre>
+ADD8rr -> add, 8-bit register, 8-bit register
+IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
+IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
+MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
+</pre>
+</div>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="ppc">The PowerPC backend</a>
+</h3>
+
+<div>
+
+<p>The PowerPC code generator lives in the lib/Target/PowerPC directory. The
+ code generation is retargetable to several variations or <i>subtargets</i> of
+ the PowerPC ISA; including ppc32, ppc64 and altivec.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ppc_abi">LLVM PowerPC ABI</a>
+</h4>
+
+<div>
+
+<p>LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC
+ relative (PIC) or static addressing for accessing global values, so no TOC
+ (r2) is used. Second, r31 is used as a frame pointer to allow dynamic growth
+ of a stack frame. LLVM takes advantage of having no TOC to provide space to
+ save the frame pointer in the PowerPC linkage area of the caller frame.
+ Other details of PowerPC ABI can be found at <a href=
+ "http://developer.apple.com/documentation/DeveloperTools/Conceptual/LowLevelABI/Articles/32bitPowerPC.html"
+ >PowerPC ABI.</a> Note: This link describes the 32 bit ABI. The 64 bit ABI
+ is similar except space for GPRs are 8 bytes wide (not 4) and r13 is reserved
+ for system use.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ppc_frame">Frame Layout</a>
+</h4>
+
+<div>
+
+<p>The size of a PowerPC frame is usually fixed for the duration of a
+ function's invocation. Since the frame is fixed size, all references
+ into the frame can be accessed via fixed offsets from the stack pointer. The
+ exception to this is when dynamic alloca or variable sized arrays are
+ present, then a base pointer (r31) is used as a proxy for the stack pointer
+ and stack pointer is free to grow or shrink. A base pointer is also used if
+ llvm-gcc is not passed the -fomit-frame-pointer flag. The stack pointer is
+ always aligned to 16 bytes, so that space allocated for altivec vectors will
+ be properly aligned.</p>
+
+<p>An invocation frame is laid out as follows (low memory at top);</p>
+
+<table class="layout">
+ <tr>
+ <td>Linkage<br><br></td>
+ </tr>
+ <tr>
+ <td>Parameter area<br><br></td>
+ </tr>
+ <tr>
+ <td>Dynamic area<br><br></td>
+ </tr>
+ <tr>
+ <td>Locals area<br><br></td>
+ </tr>
+ <tr>
+ <td>Saved registers area<br><br></td>
+ </tr>
+ <tr style="border-style: none hidden none hidden;">
+ <td><br></td>
+ </tr>
+ <tr>
+ <td>Previous Frame<br><br></td>
+ </tr>
+</table>
+
+<p>The <i>linkage</i> area is used by a callee to save special registers prior
+ to allocating its own frame. Only three entries are relevant to LLVM. The
+ first entry is the previous stack pointer (sp), aka link. This allows
+ probing tools like gdb or exception handlers to quickly scan the frames in
+ the stack. A function epilog can also use the link to pop the frame from the
+ stack. The third entry in the linkage area is used to save the return
+ address from the lr register. Finally, as mentioned above, the last entry is
+ used to save the previous frame pointer (r31.) The entries in the linkage
+ area are the size of a GPR, thus the linkage area is 24 bytes long in 32 bit
+ mode and 48 bytes in 64 bit mode.</p>
+
+<p>32 bit linkage area</p>
+
+<table class="layout">
+ <tr>
+ <td>0</td>
+ <td>Saved SP (r1)</td>
+ </tr>
+ <tr>
+ <td>4</td>
+ <td>Saved CR</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>Saved LR</td>
+ </tr>
+ <tr>
+ <td>12</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>16</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>20</td>
+ <td>Saved FP (r31)</td>
+ </tr>
+</table>
+
+<p>64 bit linkage area</p>
+
+<table class="layout">
+ <tr>
+ <td>0</td>
+ <td>Saved SP (r1)</td>
+ </tr>
+ <tr>
+ <td>8</td>
+ <td>Saved CR</td>
+ </tr>
+ <tr>
+ <td>16</td>
+ <td>Saved LR</td>
+ </tr>
+ <tr>
+ <td>24</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>32</td>
+ <td>Reserved</td>
+ </tr>
+ <tr>
+ <td>40</td>
+ <td>Saved FP (r31)</td>
+ </tr>
+</table>
+
+<p>The <i>parameter area</i> is used to store arguments being passed to a callee
+ function. Following the PowerPC ABI, the first few arguments are actually
+ passed in registers, with the space in the parameter area unused. However,
+ if there are not enough registers or the callee is a thunk or vararg
+ function, these register arguments can be spilled into the parameter area.
+ Thus, the parameter area must be large enough to store all the parameters for
+ the largest call sequence made by the caller. The size must also be
+ minimally large enough to spill registers r3-r10. This allows callees blind
+ to the call signature, such as thunks and vararg functions, enough space to
+ cache the argument registers. Therefore, the parameter area is minimally 32
+ bytes (64 bytes in 64 bit mode.) Also note that since the parameter area is
+ a fixed offset from the top of the frame, that a callee can access its spilt
+ arguments using fixed offsets from the stack pointer (or base pointer.)</p>
+
+<p>Combining the information about the linkage, parameter areas and alignment. A
+ stack frame is minimally 64 bytes in 32 bit mode and 128 bytes in 64 bit
+ mode.</p>
+
+<p>The <i>dynamic area</i> starts out as size zero. If a function uses dynamic
+ alloca then space is added to the stack, the linkage and parameter areas are
+ shifted to top of stack, and the new space is available immediately below the
+ linkage and parameter areas. The cost of shifting the linkage and parameter
+ areas is minor since only the link value needs to be copied. The link value
+ can be easily fetched by adding the original frame size to the base pointer.
+ Note that allocations in the dynamic space need to observe 16 byte
+ alignment.</p>
+
+<p>The <i>locals area</i> is where the llvm compiler reserves space for local
+ variables.</p>
+
+<p>The <i>saved registers area</i> is where the llvm compiler spills callee
+ saved registers on entry to the callee.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ppc_prolog">Prolog/Epilog</a>
+</h4>
+
+<div>
+
+<p>The llvm prolog and epilog are the same as described in the PowerPC ABI, with
+ the following exceptions. Callee saved registers are spilled after the frame
+ is created. This allows the llvm epilog/prolog support to be common with
+ other targets. The base pointer callee saved register r31 is saved in the
+ TOC slot of linkage area. This simplifies allocation of space for the base
+ pointer and makes it convenient to locate programatically and during
+ debugging.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ppc_dynamic">Dynamic Allocation</a>
+</h4>
+
+<div>
+
+<p><i>TODO - More to come.</i></p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="ptx">The PTX backend</a>
+</h3>
+
+<div>
+
+<p>The PTX code generator lives in the lib/Target/PTX directory. It is
+ currently a work-in-progress, but already supports most of the code
+ generation functionality needed to generate correct PTX kernels for
+ CUDA devices.</p>
+
+<p>The code generator can target PTX 2.0+, and shader model 1.0+. The
+ PTX ISA Reference Manual is used as the primary source of ISA
+ information, though an effort is made to make the output of the code
+ generator match the output of the NVidia nvcc compiler, whenever
+ possible.</p>
+
+<p>Code Generator Options:</p>
+<table border="1" cellspacing="0">
+ <tr>
+ <th>Option</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td><code>double</code></td>
+ <td align="left">If enabled, the map_f64_to_f32 directive is
+ disabled in the PTX output, allowing native double-precision
+ arithmetic</td>
+ </tr>
+ <tr>
+ <td><code>no-fma</code></td>
+ <td align="left">Disable generation of Fused-Multiply Add
+ instructions, which may be beneficial for some devices</td>
+ </tr>
+ <tr>
+ <td><code>smxy / computexy</code></td>
+ <td align="left">Set shader model/compute capability to x.y,
+ e.g. sm20 or compute13</td>
+ </tr>
+</table>
+
+<p>Working:</p>
+<ul>
+ <li>Arithmetic instruction selection (including combo FMA)</li>
+ <li>Bitwise instruction selection</li>
+ <li>Control-flow instruction selection</li>
+ <li>Function calls (only on SM 2.0+ and no return arguments)</li>
+ <li>Addresses spaces (0 = global, 1 = constant, 2 = local, 4 =
+ shared)</li>
+ <li>Thread synchronization (bar.sync)</li>
+ <li>Special register reads ([N]TID, [N]CTAID, PMx, CLOCK, etc.)</li>
+</ul>
+
+<p>In Progress:</p>
+<ul>
+ <li>Robust call instruction selection</li>
+ <li>Stack frame allocation</li>
+ <li>Device-specific instruction scheduling optimizations</li>
+</ul>
+
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2012-04-15 13:22:36 -0700 (Sun, 15 Apr 2012) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/CodingStandards.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CodingStandards.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CodingStandards.html (added)
+++ www-releases/trunk/3.1/docs/CodingStandards.html Tue May 22 14:32:29 2012
@@ -0,0 +1,1568 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ <title>LLVM Coding Standards</title>
+</head>
+<body>
+
+<h1>
+ LLVM Coding Standards
+</h1>
+
+<ol>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#mechanicalissues">Mechanical Source Issues</a>
+ <ol>
+ <li><a href="#sourceformating">Source Code Formatting</a>
+ <ol>
+ <li><a href="#scf_commenting">Commenting</a></li>
+ <li><a href="#scf_commentformat">Comment Formatting</a></li>
+ <li><a href="#scf_includes"><tt>#include</tt> Style</a></li>
+ <li><a href="#scf_codewidth">Source Code Width</a></li>
+ <li><a href="#scf_spacestabs">Use Spaces Instead of Tabs</a></li>
+ <li><a href="#scf_indentation">Indent Code Consistently</a></li>
+ </ol></li>
+ <li><a href="#compilerissues">Compiler Issues</a>
+ <ol>
+ <li><a href="#ci_warningerrors">Treat Compiler Warnings Like
+ Errors</a></li>
+ <li><a href="#ci_portable_code">Write Portable Code</a></li>
+ <li><a href="#ci_rtti_exceptions">Do not use RTTI or Exceptions</a></li>
+ <li><a href="#ci_static_ctors">Do not use Static Constructors</a></li>
+ <li><a href="#ci_class_struct">Use of <tt>class</tt>/<tt>struct</tt> Keywords</a></li>
+ </ol></li>
+ </ol></li>
+ <li><a href="#styleissues">Style Issues</a>
+ <ol>
+ <li><a href="#macro">The High-Level Issues</a>
+ <ol>
+ <li><a href="#hl_module">A Public Header File <b>is</b> a
+ Module</a></li>
+ <li><a href="#hl_dontinclude"><tt>#include</tt> as Little as Possible</a></li>
+ <li><a href="#hl_privateheaders">Keep "internal" Headers
+ Private</a></li>
+ <li><a href="#hl_earlyexit">Use Early Exits and <tt>continue</tt> to Simplify
+ Code</a></li>
+ <li><a href="#hl_else_after_return">Don't use <tt>else</tt> after a
+ <tt>return</tt></a></li>
+ <li><a href="#hl_predicateloops">Turn Predicate Loops into Predicate
+ Functions</a></li>
+ </ol></li>
+ <li><a href="#micro">The Low-Level Issues</a>
+ <ol>
+ <li><a href="#ll_naming">Name Types, Functions, Variables, and Enumerators Properly</a></li>
+ <li><a href="#ll_assert">Assert Liberally</a></li>
+ <li><a href="#ll_ns_std">Do not use '<tt>using namespace std</tt>'</a></li>
+ <li><a href="#ll_virtual_anch">Provide a virtual method anchor for
+ classes in headers</a></li>
+ <li><a href="#ll_end">Don't evaluate <tt>end()</tt> every time through a
+ loop</a></li>
+ <li><a href="#ll_iostream"><tt>#include <iostream></tt> is
+ <em>forbidden</em></a></li>
+ <li><a href="#ll_raw_ostream">Use <tt>raw_ostream</tt></a></li>
+ <li><a href="#ll_avoidendl">Avoid <tt>std::endl</tt></a></li>
+ </ol></li>
+
+ <li><a href="#nano">Microscopic Details</a>
+ <ol>
+ <li><a href="#micro_spaceparen">Spaces Before Parentheses</a></li>
+ <li><a href="#micro_preincrement">Prefer Preincrement</a></li>
+ <li><a href="#micro_namespaceindent">Namespace Indentation</a></li>
+ <li><a href="#micro_anonns">Anonymous Namespaces</a></li>
+ </ol></li>
+
+
+ </ol></li>
+ <li><a href="#seealso">See Also</a></li>
+</ol>
+
+<div class="doc_author">
+ <p>Written by <a href="mailto:sabre at nondot.org">Chris Lattner</a></p>
+</div>
+
+
+<!-- *********************************************************************** -->
+<h2><a name="introduction">Introduction</a></h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>This document attempts to describe a few coding standards that are being used
+in the LLVM source tree. Although no coding standards should be regarded as
+absolute requirements to be followed in all instances, coding standards are
+particularly important for large-scale code bases that follow a library-based
+design (like LLVM).</p>
+
+<p>This document intentionally does not prescribe fixed standards for religious
+issues such as brace placement and space usage. For issues like this, follow
+the golden rule:</p>
+
+<blockquote>
+
+<p><b><a name="goldenrule">If you are extending, enhancing, or bug fixing
+already implemented code, use the style that is already being used so that the
+source is uniform and easy to follow.</a></b></p>
+
+</blockquote>
+
+<p>Note that some code bases (e.g. libc++) have really good reasons to deviate
+from the coding standards. In the case of libc++, this is because the naming
+and other conventions are dictated by the C++ standard. If you think there is
+a specific good reason to deviate from the standards here, please bring it up
+on the LLVMdev mailing list.</p>
+
+<p>There are some conventions that are not uniformly followed in the code base
+(e.g. the naming convention). This is because they are relatively new, and a
+lot of code was written before they were put in place. Our long term goal is
+for the entire codebase to follow the convention, but we explicitly <em>do
+not</em> want patches that do large-scale reformating of existing code. OTOH,
+it is reasonable to rename the methods of a class if you're about to change it
+in some other way. Just do the reformating as a separate commit from the
+functionality change. </p>
+
+<p>The ultimate goal of these guidelines is the increase readability and
+maintainability of our common source base. If you have suggestions for topics to
+be included, please mail them to <a
+href="mailto:sabre at nondot.org">Chris</a>.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="mechanicalissues">Mechanical Source Issues</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="sourceformating">Source Code Formatting</a>
+</h3>
+
+<div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scf_commenting">Commenting</a>
+</h4>
+
+<div>
+
+<p>Comments are one critical part of readability and maintainability. Everyone
+knows they should comment their code, and so should you. When writing comments,
+write them as English prose, which means they should use proper capitalization,
+punctuation, etc. Aim to describe what a code is trying to do and why, not
+"how" it does it at a micro level. Here are a few critical things to
+document:</p>
+
+<h5>File Headers</h5>
+
+<div>
+
+<p>Every source file should have a header on it that describes the basic
+purpose of the file. If a file does not have a header, it should not be
+checked into the tree. The standard header looks like this:</p>
+
+<div class="doc_code">
+<pre>
+//===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===----------------------------------------------------------------------===//
+//
+// This file contains the declaration of the Instruction class, which is the
+// base class for all of the VM instructions.
+//
+//===----------------------------------------------------------------------===//
+</pre>
+</div>
+
+<p>A few things to note about this particular format: The "<tt>-*- C++
+-*-</tt>" string on the first line is there to tell Emacs that the source file
+is a C++ file, not a C file (Emacs assumes <tt>.h</tt> files are C files by default).
+Note that this tag is not necessary in <tt>.cpp</tt> files. The name of the file is also
+on the first line, along with a very short description of the purpose of the
+file. This is important when printing out code and flipping though lots of
+pages.</p>
+
+<p>The next section in the file is a concise note that defines the license
+that the file is released under. This makes it perfectly clear what terms the
+source code can be distributed under and should not be modified in any way.</p>
+
+<p>The main body of the description does not have to be very long in most cases.
+Here it's only two lines. If an algorithm is being implemented or something
+tricky is going on, a reference to the paper where it is published should be
+included, as well as any notes or "gotchas" in the code to watch out for.</p>
+
+</div>
+
+<h5>Class overviews</h5>
+
+<p>Classes are one fundamental part of a good object oriented design. As such,
+a class definition should have a comment block that explains what the class is
+used for and how it works. Every non-trivial class is expected to have a
+doxygen comment block.</p>
+
+
+<h5>Method information</h5>
+
+<div>
+
+<p>Methods defined in a class (as well as any global functions) should also be
+documented properly. A quick note about what it does and a description of the
+borderline behaviour is all that is necessary here (unless something
+particularly tricky or insidious is going on). The hope is that people can
+figure out how to use your interfaces without reading the code itself.</p>
+
+<p>Good things to talk about here are what happens when something unexpected
+happens: does the method return null? Abort? Format your hard disk?</p>
+
+</div>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scf_commentformat">Comment Formatting</a>
+</h4>
+
+<div>
+
+<p>In general, prefer C++ style (<tt>//</tt>) comments. They take less space,
+require less typing, don't have nesting problems, etc. There are a few cases
+when it is useful to use C style (<tt>/* */</tt>) comments however:</p>
+
+<ol>
+ <li>When writing C code: Obviously if you are writing C code, use C style
+ comments.</li>
+ <li>When writing a header file that may be <tt>#include</tt>d by a C source
+ file.</li>
+ <li>When writing a source file that is used by a tool that only accepts C
+ style comments.</li>
+</ol>
+
+<p>To comment out a large block of code, use <tt>#if 0</tt> and <tt>#endif</tt>.
+These nest properly and are better behaved in general than C style comments.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scf_includes"><tt>#include</tt> Style</a>
+</h4>
+
+<div>
+
+<p>Immediately after the <a href="#scf_commenting">header file comment</a> (and
+include guards if working on a header file), the <a
+href="#hl_dontinclude">minimal</a> list of <tt>#include</tt>s required by the
+file should be listed. We prefer these <tt>#include</tt>s to be listed in this
+order:</p>
+
+<ol>
+ <li><a href="#mmheader">Main Module Header</a></li>
+ <li><a href="#hl_privateheaders">Local/Private Headers</a></li>
+ <li><tt>llvm/*</tt></li>
+ <li><tt>llvm/Analysis/*</tt></li>
+ <li><tt>llvm/Assembly/*</tt></li>
+ <li><tt>llvm/Bitcode/*</tt></li>
+ <li><tt>llvm/CodeGen/*</tt></li>
+ <li>...</li>
+ <li><tt>Support/*</tt></li>
+ <li><tt>Config/*</tt></li>
+ <li>System <tt>#includes</tt></li>
+</ol>
+
+<p>and each category should be sorted by name.</p>
+
+<p><a name="mmheader">The "Main Module Header"</a> file applies to <tt>.cpp</tt> files
+which implement an interface defined by a <tt>.h</tt> file. This <tt>#include</tt>
+should always be included <b>first</b> regardless of where it lives on the file
+system. By including a header file first in the <tt>.cpp</tt> 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 <tt>.cpp</tt> file to indicate where the interfaces it
+implements are defined.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scf_codewidth">Source Code Width</a>
+</h4>
+
+<div>
+
+<p>Write your code to fit within 80 columns of text. This helps those of us who
+like to print out code and look at your code in an xterm without resizing
+it.</p>
+
+<p>The longer answer is that there must be some limit to the width of the code
+in order to reasonably allow developers to have multiple files side-by-side in
+windows on a modest display. If you are going to pick a width limit, it is
+somewhat arbitrary but you might as well pick something standard. Going with
+90 columns (for example) instead of 80 columns wouldn't add any significant
+value and would be detrimental to printing out code. Also many other projects
+have standardized on 80 columns, so some people have already configured their
+editors for it (vs something else, like 90 columns).</p>
+
+<p>This is one of many contentious issues in coding standards, but it is not up
+for debate.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scf_spacestabs">Use Spaces Instead of Tabs</a>
+</h4>
+
+<div>
+
+<p>In all cases, prefer spaces to tabs in source files. People have different
+preferred indentation levels, and different styles of indentation that they
+like; this is fine. What isn't fine is that different editors/viewers expand
+tabs out to different tab stops. This can cause your code to look completely
+unreadable, and it is not worth dealing with.</p>
+
+<p>As always, follow the <a href="#goldenrule">Golden Rule</a> above: follow the
+style of existing code if you are modifying and extending it. If you like four
+spaces of indentation, <b>DO NOT</b> do that in the middle of a chunk of code
+with two spaces of indentation. Also, do not reindent a whole source file: it
+makes for incredible diffs that are absolutely worthless.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="scf_indentation">Indent Code Consistently</a>
+</h4>
+
+<div>
+
+<p>Okay, in your first year of programming you were told that indentation is
+important. If you didn't believe and internalize this then, now is the time.
+Just do it.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="compilerissues">Compiler Issues</a>
+</h3>
+
+<div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ci_warningerrors">Treat Compiler Warnings Like Errors</a>
+</h4>
+
+<div>
+
+<p>If your code has compiler warnings in it, something is wrong — you
+aren't casting values correctly, your have "questionable" constructs in your
+code, or you are doing something legitimately wrong. Compiler warnings can
+cover up legitimate errors in output and make dealing with a translation unit
+difficult.</p>
+
+<p>It is not possible to prevent all warnings from all compilers, nor is it
+desirable. Instead, pick a standard compiler (like <tt>gcc</tt>) that provides
+a good thorough set of warnings, and stick to it. 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, a warning that annoys me occurs when
+I write code like this:</p>
+
+<div class="doc_code">
+<pre>
+if (V = getValue()) {
+ ...
+}
+</pre>
+</div>
+
+<p><tt>gcc</tt> will warn me that I probably want to use the <tt>==</tt>
+operator, and that I probably mistyped it. In most cases, I haven't, and I
+really don't want the spurious errors. To fix this particular problem, I
+rewrite the code like this:</p>
+
+<div class="doc_code">
+<pre>
+if ((V = getValue())) {
+ ...
+}
+</pre>
+</div>
+
+<p>which shuts <tt>gcc</tt> up. Any <tt>gcc</tt> warning that annoys you can
+be fixed by massaging the code appropriately.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ci_portable_code">Write Portable Code</a>
+</h4>
+
+<div>
+
+<p>In almost all cases, it is possible and within reason to write completely
+portable code. If there are cases where it isn't possible to write portable
+code, isolate it behind a well defined (and well documented) interface.</p>
+
+<p>In practice, this means that you shouldn't assume much about the host
+compiler, and Visual Studio tends to be the lowest common denominator.
+If advanced features are used, they should only be an implementation detail of
+a library which has a simple exposed API, and preferably be buried in
+libSystem.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+<a name="ci_rtti_exceptions">Do not use RTTI or Exceptions</a>
+</h4>
+<div>
+
+<p>In an effort to reduce code and executable size, LLVM does not use RTTI
+(e.g. <tt>dynamic_cast<></tt>) or exceptions. These two language features
+violate the general C++ principle of <i>"you only pay for what you use"</i>,
+causing executable bloat even if exceptions are never used in the code base, or
+if RTTI is never used for a class. Because of this, we turn them off globally
+in the code.</p>
+
+<p>That said, LLVM does make extensive use of a hand-rolled form of RTTI that
+use templates like <a href="ProgrammersManual.html#isa"><tt>isa<></tt>,
+<tt>cast<></tt>, and <tt>dyn_cast<></tt></a>. This form of RTTI is
+opt-in and can be added to any class. It is also substantially more efficient
+than <tt>dynamic_cast<></tt>.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+<a name="ci_static_ctors">Do not use Static Constructors</a>
+</h4>
+<div>
+
+<p>Static constructors and destructors (e.g. global variables whose types have
+a constructor or destructor) should not be added to the code base, and should be
+removed wherever possible. Besides <a
+href="http://yosefk.com/c++fqa/ctors.html#fqa-10.12">well known problems</a>
+where the order of initialization is undefined between globals in different
+source files, the entire concept of static constructors is at odds with the
+common use case of LLVM as a library linked into a larger application.</p>
+
+<p>Consider the use of LLVM as a JIT linked into another application (perhaps
+for <a href="http://llvm.org/Users.html">OpenGL, custom languages</a>,
+<a href="http://llvm.org/devmtg/2010-11/Gritz-OpenShadingLang.pdf">shaders in
+movies</a>, etc). Due to the design of static constructors, they must be
+executed at startup time of the entire application, regardless of whether or
+how LLVM is used in that larger application. There are two problems with
+this:</p>
+
+<ol>
+ <li>The time to run the static constructors impacts startup time of
+ applications — a critical time for GUI apps, among others.</li>
+
+ <li>The static constructors cause the app to pull many extra pages of memory
+ off the disk: both the code for the constructor in each <tt>.o</tt> file and
+ the small amount of data that gets touched. In addition, touched/dirty pages
+ put more pressure on the VM system on low-memory machines.</li>
+</ol>
+
+<p>We would really like for there to be zero cost for linking in an additional
+LLVM target or other library into an application, but static constructors
+violate this goal.</p>
+
+<p>That said, LLVM unfortunately does contain static constructors. It would be
+a <a href="http://llvm.org/PR11944">great project</a> for someone to purge all
+static constructors from LLVM, and then enable the
+<tt>-Wglobal-constructors</tt> warning flag (when building with Clang) to ensure
+we do not regress in the future.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+<a name="ci_class_struct">Use of <tt>class</tt> and <tt>struct</tt> Keywords</a>
+</h4>
+<div>
+
+<p>In C++, the <tt>class</tt> and <tt>struct</tt> keywords can be used almost
+interchangeably. The only difference is when they are used to declare a class:
+<tt>class</tt> makes all members private by default while <tt>struct</tt> makes
+all members public by default.</p>
+
+<p>Unfortunately, not all compilers follow the rules and some will generate
+different symbols based on whether <tt>class</tt> or <tt>struct</tt> was used to
+declare the symbol. This can lead to problems at link time.</p>
+
+<p>So, the rule for LLVM is to always use the <tt>class</tt> keyword, unless
+<b>all</b> members are public and the type is a C++
+<a href="http://en.wikipedia.org/wiki/Plain_old_data_structure">POD</a> type, in
+which case <tt>struct</tt> is allowed.</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="styleissues">Style Issues</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="macro">The High-Level Issues</a>
+</h3>
+<!-- ======================================================================= -->
+
+<div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="hl_module">A Public Header File <b>is</b> a Module</a>
+</h4>
+
+<div>
+
+<p>C++ doesn't do too well in the modularity department. There is no real
+encapsulation or data hiding (unless you use expensive protocol classes), but it
+is what we have to work with. When you write a public header file (in the LLVM
+source tree, they live in the top level "<tt>include</tt>" directory), you are
+defining a module of functionality.</p>
+
+<p>Ideally, modules should be completely independent of each other, and their
+header files should only <tt>#include</tt> the absolute minimum number of
+headers possible. A module is not just a class, a function, or a
+namespace: <a href="http://www.cuj.com/articles/2000/0002/0002c/0002c.htm">it's
+a collection of these</a> that defines an interface. This interface may be
+several functions, classes, or data structures, but the important issue is how
+they work together.</p>
+
+<p>In general, a module should be implemented by one or more <tt>.cpp</tt>
+files. Each of these <tt>.cpp</tt> files should include the header that defines
+their interface first. This ensures that all of the dependences of the module
+header have been properly added to the module header itself, and are not
+implicit. System headers should be included after user headers for a
+translation unit.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="hl_dontinclude"><tt>#include</tt> as Little as Possible</a>
+</h4>
+
+<div>
+
+<p><tt>#include</tt> hurts compile time performance. Don't do it unless you
+have to, especially in header files.</p>
+
+<p>But wait! Sometimes you need to have the definition of a class to use it, or
+to inherit from it. In these cases go ahead and <tt>#include</tt> that header
+file. Be aware however that there are many cases where you don't need to have
+the full definition of a class. If you are using a pointer or reference to a
+class, you don't need the header file. If you are simply returning a class
+instance from a prototyped function or method, you don't need it. In fact, for
+most cases, you simply don't need the definition of a class. And not
+<tt>#include</tt>'ing speeds up compilation.</p>
+
+<p>It is easy to try to go too overboard on this recommendation, however. You
+<b>must</b> include all of the header files that you are using — you can
+include them either directly or indirectly (through another header file). To
+make sure that you don't accidentally forget to include a header file in your
+module header, make sure to include your module header <b>first</b> in the
+implementation file (as mentioned above). This way there won't be any hidden
+dependencies that you'll find out about later.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="hl_privateheaders">Keep "Internal" Headers Private</a>
+</h4>
+
+<div>
+
+<p>Many modules have a complex implementation that causes them to use more than
+one implementation (<tt>.cpp</tt>) file. It is often tempting to put the
+internal communication interface (helper classes, extra functions, etc) in the
+public module header file. Don't do this!</p>
+
+<p>If you really need to do something like this, put a private header file in
+the same directory as the source files, and include it locally. This ensures
+that your private interface remains private and undisturbed by outsiders.</p>
+
+<p>Note however, that it's okay to put extra implementation methods in a public
+class itself. Just make them private (or protected) and all is well.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="hl_earlyexit">Use Early Exits and <tt>continue</tt> to Simplify Code</a>
+</h4>
+
+<div>
+
+<p>When reading code, keep in mind how much state and how many previous
+decisions have to be remembered by the reader to understand a block of code.
+Aim to reduce indentation where possible when it doesn't make it more difficult
+to understand the code. One great way to do this is by making use of early
+exits and the <tt>continue</tt> keyword in long loops. As an example of using
+an early exit from a function, consider this "bad" code:</p>
+
+<div class="doc_code">
+<pre>
+Value *DoSomething(Instruction *I) {
+ if (!isa<TerminatorInst>(I) &&
+ I->hasOneUse() && SomeOtherThing(I)) {
+ ... some long code ....
+ }
+
+ return 0;
+}
+</pre>
+</div>
+
+<p>This code has several problems if the body of the '<tt>if</tt>' is large.
+When you're looking at the top of the function, it isn't immediately clear that
+this <em>only</em> does interesting things with non-terminator instructions, and
+only applies to things with the other predicates. Second, it is relatively
+difficult to describe (in comments) why these predicates are important because
+the <tt>if</tt> statement makes it difficult to lay out the comments. Third,
+when you're deep within the body of the code, it is indented an extra level.
+Finally, when reading the top of the function, it isn't clear what the result is
+if the predicate isn't true; you have to read to the end of the function to know
+that it returns null.</p>
+
+<p>It is much preferred to format the code like this:</p>
+
+<div class="doc_code">
+<pre>
+Value *DoSomething(Instruction *I) {
+ // Terminators never need 'something' done to them because ...
+ if (isa<TerminatorInst>(I))
+ return 0;
+
+ // We conservatively avoid transforming instructions with multiple uses
+ // because goats like cheese.
+ if (!I->hasOneUse())
+ return 0;
+
+ // This is really just here for example.
+ if (!SomeOtherThing(I))
+ return 0;
+
+ ... some long code ....
+}
+</pre>
+</div>
+
+<p>This fixes these problems. A similar problem frequently happens in <tt>for</tt>
+loops. A silly example is something like this:</p>
+
+<div class="doc_code">
+<pre>
+ for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
+ if (BinaryOperator *BO = dyn_cast<BinaryOperator>(II)) {
+ Value *LHS = BO->getOperand(0);
+ Value *RHS = BO->getOperand(1);
+ if (LHS != RHS) {
+ ...
+ }
+ }
+ }
+</pre>
+</div>
+
+<p>When you have very, very small loops, this sort of structure is fine. But if
+it exceeds more than 10-15 lines, it becomes difficult for people to read and
+understand at a glance. The problem with this sort of code is that it gets very
+nested very quickly. Meaning that the reader of the code has to keep a lot of
+context in their brain to remember what is going immediately on in the loop,
+because they don't know if/when the <tt>if</tt> conditions will have elses etc.
+It is strongly preferred to structure the loop like this:</p>
+
+<div class="doc_code">
+<pre>
+ for (BasicBlock::iterator II = BB->begin(), E = BB->end(); II != E; ++II) {
+ BinaryOperator *BO = dyn_cast<BinaryOperator>(II);
+ if (!BO) continue;
+
+ Value *LHS = BO->getOperand(0);
+ Value *RHS = BO->getOperand(1);
+ if (LHS == RHS) continue;
+
+ ...
+ }
+</pre>
+</div>
+
+<p>This has all the benefits of using early exits for functions: it reduces
+nesting of the loop, it makes it easier to describe why the conditions are true,
+and it makes it obvious to the reader that there is no <tt>else</tt> coming up
+that they have to push context into their brain for. If a loop is large, this
+can be a big understandability win.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="hl_else_after_return">Don't use <tt>else</tt> after a <tt>return</tt></a>
+</h4>
+
+<div>
+
+<p>For similar reasons above (reduction of indentation and easier reading),
+please do not use '<tt>else</tt>' or '<tt>else if</tt>' after something that
+interrupts control flow — like <tt>return</tt>, <tt>break</tt>,
+<tt>continue</tt>, <tt>goto</tt>, etc. For example, this is <em>bad</em>:</p>
+
+<div class="doc_code">
+<pre>
+ case 'J': {
+ if (Signed) {
+ Type = Context.getsigjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_sigjmp_buf;
+ return QualType();
+ <b>} else {
+ break;
+ }</b>
+ } else {
+ Type = Context.getjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_jmp_buf;
+ return QualType();
+ <b>} else {
+ break;
+ }</b>
+ }
+ }
+ }
+</pre>
+</div>
+
+<p>It is better to write it like this:</p>
+
+<div class="doc_code">
+<pre>
+ case 'J':
+ if (Signed) {
+ Type = Context.getsigjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_sigjmp_buf;
+ return QualType();
+ }
+ } else {
+ Type = Context.getjmp_bufType();
+ if (Type.isNull()) {
+ Error = ASTContext::GE_Missing_jmp_buf;
+ return QualType();
+ }
+ }
+ <b>break;</b>
+</pre>
+</div>
+
+<p>Or better yet (in this case) as:</p>
+
+<div class="doc_code">
+<pre>
+ case 'J':
+ if (Signed)
+ Type = Context.getsigjmp_bufType();
+ else
+ Type = Context.getjmp_bufType();
+
+ if (Type.isNull()) {
+ Error = Signed ? ASTContext::GE_Missing_sigjmp_buf :
+ ASTContext::GE_Missing_jmp_buf;
+ return QualType();
+ }
+ <b>break;</b>
+</pre>
+</div>
+
+<p>The idea is to reduce indentation and the amount of code you have to keep
+track of when reading the code.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="hl_predicateloops">Turn Predicate Loops into Predicate Functions</a>
+</h4>
+
+<div>
+
+<p>It is very common to write small loops that just compute a boolean value.
+There are a number of ways that people commonly write these, but an example of
+this sort of thing is:</p>
+
+<div class="doc_code">
+<pre>
+ <b>bool FoundFoo = false;</b>
+ for (unsigned i = 0, e = BarList.size(); i != e; ++i)
+ if (BarList[i]->isFoo()) {
+ <b>FoundFoo = true;</b>
+ break;
+ }
+
+ <b>if (FoundFoo) {</b>
+ ...
+ }
+</pre>
+</div>
+
+<p>This sort of code is awkward to write, and is almost always a bad sign.
+Instead of this sort of loop, we strongly prefer to use a predicate function
+(which may be <a href="#micro_anonns">static</a>) that uses
+<a href="#hl_earlyexit">early exits</a> to compute the predicate. We prefer
+the code to be structured like this:</p>
+
+<div class="doc_code">
+<pre>
+/// ListContainsFoo - Return true if the specified list has an element that is
+/// a foo.
+static bool ListContainsFoo(const std::vector<Bar*> &List) {
+ for (unsigned i = 0, e = List.size(); i != e; ++i)
+ if (List[i]->isFoo())
+ return true;
+ return false;
+}
+...
+
+ <b>if (ListContainsFoo(BarList)) {</b>
+ ...
+ }
+</pre>
+</div>
+
+<p>There are many reasons for doing this: it reduces indentation and factors out
+code which can often be shared by other code that checks for the same predicate.
+More importantly, it <em>forces you to pick a name</em> for the function, and
+forces you to write a comment for it. In this silly example, this doesn't add
+much value. However, if the condition is complex, this can make it a lot easier
+for the reader to understand the code that queries for this predicate. Instead
+of being faced with the in-line details of how we check to see if the BarList
+contains a foo, we can trust the function name and continue reading with better
+locality.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="micro">The Low-Level Issues</a>
+</h3>
+<!-- ======================================================================= -->
+
+<div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_naming">
+ Name Types, Functions, Variables, and Enumerators Properly
+ </a>
+</h4>
+
+<div>
+
+<p>Poorly-chosen names can mislead the reader and cause bugs. We cannot stress
+enough how important it is to use <em>descriptive</em> names. Pick names that
+match the semantics and role of the underlying entities, within reason. Avoid
+abbreviations unless they are well known. After picking a good name, make sure
+to use consistent capitalization for the name, as inconsistency requires clients
+to either memorize the APIs or to look it up to find the exact spelling.</p>
+
+<p>In general, names should be in camel case (e.g. <tt>TextFileReader</tt>
+and <tt>isLValue()</tt>). Different kinds of declarations have different
+rules:</p>
+
+<ul>
+<li><p><b>Type names</b> (including classes, structs, enums, typedefs, etc)
+ should be nouns and start with an upper-case letter (e.g.
+ <tt>TextFileReader</tt>).</p></li>
+
+<li><p><b>Variable names</b> should be nouns (as they represent state). The
+ name should be camel case, and start with an upper case letter (e.g.
+ <tt>Leader</tt> or <tt>Boats</tt>).</p></li>
+
+<li><p><b>Function names</b> should be verb phrases (as they represent
+ actions), and command-like function should be imperative. The name should
+ be camel case, and start with a lower case letter (e.g. <tt>openFile()</tt>
+ or <tt>isFoo()</tt>).</p></li>
+
+<li><p><b>Enum declarations</b> (e.g. <tt>enum Foo {...}</tt>) are types, so
+ they should follow the naming conventions for types. A common use for enums
+ is as a discriminator for a union, or an indicator of a subclass. When an
+ enum is used for something like this, it should have a <tt>Kind</tt> suffix
+ (e.g. <tt>ValueKind</tt>).</p></li>
+
+<li><p><b>Enumerators</b> (e.g. <tt>enum { Foo, Bar }</tt>) and <b>public member
+ variables</b> should start with an upper-case letter, just like types.
+ Unless the enumerators are defined in their own small namespace or inside a
+ class, enumerators should have a prefix corresponding to the enum
+ declaration name. For example, <tt>enum ValueKind { ... };</tt> may contain
+ enumerators like <tt>VK_Argument</tt>, <tt>VK_BasicBlock</tt>, etc.
+ Enumerators that are just convenience constants are exempt from the
+ requirement for a prefix. For instance:</p>
+
+<div class="doc_code">
+<pre>
+enum {
+ MaxSize = 42,
+ Density = 12
+};
+</pre>
+</div>
+</li>
+
+</ul>
+
+<p>As an exception, classes that mimic STL classes can have member names in
+STL's style of lower-case words separated by underscores (e.g. <tt>begin()</tt>,
+<tt>push_back()</tt>, and <tt>empty()</tt>).</p>
+
+<p>Here are some examples of good and bad names:</p>
+
+<div class="doc_code">
+<pre>
+class VehicleMaker {
+ ...
+ Factory<Tire> F; // Bad -- abbreviation and non-descriptive.
+ Factory<Tire> Factory; // Better.
+ Factory<Tire> TireFactory; // Even better -- if VehicleMaker has more than one
+ // kind of factories.
+};
+
+Vehicle MakeVehicle(VehicleType Type) {
+ VehicleMaker M; // Might be OK if having a short life-span.
+ Tire tmp1 = M.makeTire(); // Bad -- 'tmp1' provides no information.
+ Light headlight = M.makeLight("head"); // Good -- descriptive.
+ ...
+}
+</pre>
+</div>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_assert">Assert Liberally</a>
+</h4>
+
+<div>
+
+<p>Use the "<tt>assert</tt>" macro to its fullest. Check all of your
+preconditions and assumptions, you never know when a bug (not necessarily even
+yours) might be caught early by an assertion, which reduces debugging time
+dramatically. The "<tt><cassert></tt>" header file is probably already
+included by the header files you are using, so it doesn't cost anything to use
+it.</p>
+
+<p>To further assist with debugging, make sure to put some kind of error message
+in the assertion statement, which is printed if the assertion is tripped. This
+helps the poor debugger make sense of why an assertion is being made and
+enforced, and hopefully what to do about it. Here is one complete example:</p>
+
+<div class="doc_code">
+<pre>
+inline Value *getOperand(unsigned i) {
+ assert(i < Operands.size() && "getOperand() out of range!");
+ return Operands[i];
+}
+</pre>
+</div>
+
+<p>Here are more examples:</p>
+
+<div class="doc_code">
+<pre>
+assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+
+assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
+
+assert(idx < getNumSuccessors() && "Successor # out of range!");
+
+assert(V1.getType() == V2.getType() && "Constant types must be identical!");
+
+assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+</pre>
+</div>
+
+<p>You get the idea.</p>
+
+<p>Please be aware that, when adding assert statements, not all compilers are aware of
+the semantics of the assert. In some places, asserts are used to indicate a piece of
+code that should not be reached. These are typically of the form:</p>
+
+<div class="doc_code">
+<pre>
+assert(0 && "Some helpful error message");
+</pre>
+</div>
+
+<p>When used in a function that returns a value, they should be followed with a return
+statement and a comment indicating that this line is never reached. This will prevent
+a compiler which is unable to deduce that the assert statement never returns from
+generating a warning.</p>
+
+<div class="doc_code">
+<pre>
+assert(0 && "Some helpful error message");
+// Not reached
+return 0;
+</pre>
+</div>
+
+<p>Another issue is that values used only by assertions will produce an "unused
+value" warning when assertions are disabled. For example, this code will
+warn:</p>
+
+<div class="doc_code">
+<pre>
+unsigned Size = V.size();
+assert(Size > 42 && "Vector smaller than it should be");
+
+bool NewToSet = Myset.insert(Value);
+assert(NewToSet && "The value shouldn't be in the set yet");
+</pre>
+</div>
+
+<p>These are two interesting different cases. In the first case, the call to
+V.size() is only useful for the assert, and we don't want it executed when
+assertions are disabled. Code like this should move the call into the assert
+itself. In the second case, the side effects of the call must happen whether
+the assert is enabled or not. In this case, the value should be cast to void to
+disable the warning. To be specific, it is preferred to write the code like
+this:</p>
+
+<div class="doc_code">
+<pre>
+assert(V.size() > 42 && "Vector smaller than it should be");
+
+bool NewToSet = Myset.insert(Value); (void)NewToSet;
+assert(NewToSet && "The value shouldn't be in the set yet");
+</pre>
+</div>
+
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_ns_std">Do Not Use '<tt>using namespace std</tt>'</a>
+</h4>
+
+<div>
+
+<p>In LLVM, we prefer to explicitly prefix all identifiers from the standard
+namespace with an "<tt>std::</tt>" prefix, rather than rely on
+"<tt>using namespace std;</tt>".</p>
+
+<p> In header files, adding a '<tt>using namespace XXX</tt>' directive pollutes
+the namespace of any source file that <tt>#include</tt>s the header. This is
+clearly a bad thing.</p>
+
+<p>In implementation files (e.g. <tt>.cpp</tt> files), the rule is more of a stylistic
+rule, but is still important. Basically, using explicit namespace prefixes
+makes the code <b>clearer</b>, because it is immediately obvious what facilities
+are being used and where they are coming from. And <b>more portable</b>, because
+namespace clashes cannot occur between LLVM code and other namespaces. The
+portability rule is important because different standard library implementations
+expose different symbols (potentially ones they shouldn't), and future revisions
+to the C++ standard will add more symbols to the <tt>std</tt> namespace. As
+such, we never use '<tt>using namespace std;</tt>' in LLVM.</p>
+
+<p>The exception to the general rule (i.e. it's not an exception for
+the <tt>std</tt> namespace) is for implementation files. For example, all of
+the code in the LLVM project implements code that lives in the 'llvm' namespace.
+As such, it is ok, and actually clearer, for the <tt>.cpp</tt> files to have a
+'<tt>using namespace llvm;</tt>' directive at the top, after the
+<tt>#include</tt>s. This reduces indentation in the body of the file for source
+editors that indent based on braces, and keeps the conceptual context cleaner.
+The general form of this rule is that any <tt>.cpp</tt> file that implements
+code in any namespace may use that namespace (and its parents'), but should not
+use any others.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_virtual_anch">
+ Provide a Virtual Method Anchor for Classes in Headers
+ </a>
+</h4>
+
+<div>
+
+<p>If a class is defined in a header file and has a v-table (either it has
+virtual methods or it derives from classes with virtual methods), it must
+always have at least one out-of-line virtual method in the class. Without
+this, the compiler will copy the vtable and RTTI into every <tt>.o</tt> file
+that <tt>#include</tt>s the header, bloating <tt>.o</tt> file sizes and
+increasing link times.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_end">Don't evaluate <tt>end()</tt> every time through a loop</a>
+</h4>
+
+<div>
+
+<p>Because C++ doesn't have a standard "<tt>foreach</tt>" loop (though it can be
+emulated with macros and may be coming in C++'0x) we end up writing a lot of
+loops that manually iterate from begin to end on a variety of containers or
+through other data structures. One common mistake is to write a loop in this
+style:</p>
+
+<div class="doc_code">
+<pre>
+ BasicBlock *BB = ...
+ for (BasicBlock::iterator I = BB->begin(); I != <b>BB->end()</b>; ++I)
+ ... use I ...
+</pre>
+</div>
+
+<p>The problem with this construct is that it evaluates "<tt>BB->end()</tt>"
+every time through the loop. Instead of writing the loop like this, we strongly
+prefer loops to be written so that they evaluate it once before the loop starts.
+A convenient way to do this is like so:</p>
+
+<div class="doc_code">
+<pre>
+ BasicBlock *BB = ...
+ for (BasicBlock::iterator I = BB->begin(), E = <b>BB->end()</b>; I != E; ++I)
+ ... use I ...
+</pre>
+</div>
+
+<p>The observant may quickly point out that these two loops may have different
+semantics: if the container (a basic block in this case) is being mutated, then
+"<tt>BB->end()</tt>" may change its value every time through the loop and the
+second loop may not in fact be correct. If you actually do depend on this
+behavior, please write the loop in the first form and add a comment indicating
+that you did it intentionally.</p>
+
+<p>Why do we prefer the second form (when correct)? Writing the loop in the
+first form has two problems. First it may be less efficient than evaluating it
+at the start of the loop. In this case, the cost is probably minor — a
+few extra loads every time through the loop. However, if the base expression is
+more complex, then the cost can rise quickly. I've seen loops where the end
+expression was actually something like: "<tt>SomeMap[x]->end()</tt>" and map
+lookups really aren't cheap. By writing it in the second form consistently, you
+eliminate the issue entirely and don't even have to think about it.</p>
+
+<p>The second (even bigger) issue is that writing the loop in the first form
+hints to the reader that the loop is mutating the container (a fact that a
+comment would handily confirm!). If you write the loop in the second form, it
+is immediately obvious without even looking at the body of the loop that the
+container isn't being modified, which makes it easier to read the code and
+understand what it does.</p>
+
+<p>While the second form of the loop is a few extra keystrokes, we do strongly
+prefer it.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_iostream"><tt>#include <iostream></tt> is Forbidden</a>
+</h4>
+
+<div>
+
+<p>The use of <tt>#include <iostream></tt> in library files is
+hereby <b><em>forbidden</em></b>, because many common implementations
+transparently inject a <a href="#ci_static_ctors">static constructor</a> into
+every translation unit that includes it.</p>
+
+<p>Note that using the other stream headers (<tt><sstream></tt> for
+example) is not problematic in this regard —
+just <tt><iostream></tt>. However, <tt>raw_ostream</tt> provides various
+APIs that are better performing for almost every use than <tt>std::ostream</tt>
+style APIs. <b>Therefore new code should always
+use <a href="#ll_raw_ostream"><tt>raw_ostream</tt></a> for writing, or
+the <tt>llvm::MemoryBuffer</tt> API for reading files.</b></p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_raw_ostream">Use <tt>raw_ostream</tt></a>
+</h4>
+
+<div>
+
+<p>LLVM includes a lightweight, simple, and efficient stream implementation
+in <tt>llvm/Support/raw_ostream.h</tt>, which provides all of the common
+features of <tt>std::ostream</tt>. All new code should use <tt>raw_ostream</tt>
+instead of <tt>ostream</tt>.</p>
+
+<p>Unlike <tt>std::ostream</tt>, <tt>raw_ostream</tt> is not a template and can
+be forward declared as <tt>class raw_ostream</tt>. Public headers should
+generally not include the <tt>raw_ostream</tt> header, but use forward
+declarations and constant references to <tt>raw_ostream</tt> instances.</p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="ll_avoidendl">Avoid <tt>std::endl</tt></a>
+</h4>
+
+<div>
+
+<p>The <tt>std::endl</tt> modifier, when used with <tt>iostreams</tt> outputs a
+newline to the output stream specified. In addition to doing this, however, it
+also flushes the output stream. In other words, these are equivalent:</p>
+
+<div class="doc_code">
+<pre>
+std::cout << std::endl;
+std::cout << '\n' << std::flush;
+</pre>
+</div>
+
+<p>Most of the time, you probably have no reason to flush the output stream, so
+it's better to use a literal <tt>'\n'</tt>.</p>
+
+</div>
+
+</div>
+
+<!-- ======================================================================= -->
+<h3>
+ <a name="nano">Microscopic Details</a>
+</h3>
+<!-- ======================================================================= -->
+
+<div>
+
+<p>This section describes preferred low-level formatting guidelines along with
+reasoning on why we prefer them.</p>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="micro_spaceparen">Spaces Before Parentheses</a>
+</h4>
+
+<div>
+
+<p>We prefer to put a space before an open parenthesis only in control flow
+statements, but not in normal function call expressions and function-like
+macros. For example, this is good:</p>
+
+<div class="doc_code">
+<pre>
+<b>if (</b>x) ...
+<b>for (</b>i = 0; i != 100; ++i) ...
+<b>while (</b>llvm_rocks) ...
+
+<b>somefunc(</b>42);
+<b><a href="#ll_assert">assert</a>(</b>3 != 4 && "laws of math are failing me");
+
+a = <b>foo(</b>42, 92) + <b>bar(</b>x);
+</pre>
+</div>
+
+<p>and this is bad:</p>
+
+<div class="doc_code">
+<pre>
+<b>if(</b>x) ...
+<b>for(</b>i = 0; i != 100; ++i) ...
+<b>while(</b>llvm_rocks) ...
+
+<b>somefunc (</b>42);
+<b><a href="#ll_assert">assert</a> (</b>3 != 4 && "laws of math are failing me");
+
+a = <b>foo (</b>42, 92) + <b>bar (</b>x);
+</pre>
+</div>
+
+<p>The reason for doing this is not completely arbitrary. This style makes
+control flow operators stand out more, and makes expressions flow better. The
+function call operator binds very tightly as a postfix operator. Putting a
+space after a function name (as in the last example) makes it appear that the
+code might bind the arguments of the left-hand-side of a binary operator with
+the argument list of a function and the name of the right side. More
+specifically, it is easy to misread the "a" example as:</p>
+
+<div class="doc_code">
+<pre>
+a = foo <b>(</b>(42, 92) + bar<b>)</b> (x);
+</pre>
+</div>
+
+<p>when skimming through the code. By avoiding a space in a function, we avoid
+this misinterpretation.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="micro_preincrement">Prefer Preincrement</a>
+</h4>
+
+<div>
+
+<p>Hard fast rule: Preincrement (<tt>++X</tt>) may be no slower than
+postincrement (<tt>X++</tt>) and could very well be a lot faster than it. Use
+preincrementation whenever possible.</p>
+
+<p>The semantics of postincrement include making a copy of the value being
+incremented, returning it, and then preincrementing the "work value". For
+primitive types, this isn't a big deal... but for iterators, it can be a huge
+issue (for example, some iterators contains stack and set objects in them...
+copying an iterator could invoke the copy ctor's of these as well). In general,
+get in the habit of always using preincrement, and you won't have a problem.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="micro_namespaceindent">Namespace Indentation</a>
+</h4>
+
+<div>
+
+<p>
+In general, we strive to reduce indentation wherever possible. This is useful
+because we want code to <a href="#scf_codewidth">fit into 80 columns</a> without
+wrapping horribly, but also because it makes it easier to understand the code.
+Namespaces are a funny thing: they are often large, and we often desire to put
+lots of stuff into them (so they can be large). Other times they are tiny,
+because they just hold an enum or something similar. In order to balance this,
+we use different approaches for small versus large namespaces.
+</p>
+
+<p>
+If a namespace definition is small and <em>easily</em> fits on a screen (say,
+less than 35 lines of code), then you should indent its body. Here's an
+example:
+</p>
+
+<div class="doc_code">
+<pre>
+namespace llvm {
+ namespace X86 {
+ /// RelocationType - An enum for the x86 relocation codes. Note that
+ /// the terminology here doesn't follow x86 convention - word means
+ /// 32-bit and dword means 64-bit.
+ enum RelocationType {
+ /// reloc_pcrel_word - PC relative relocation, add the relocated value to
+ /// the value already in memory, after we adjust it for where the PC is.
+ reloc_pcrel_word = 0,
+
+ /// reloc_picrel_word - PIC base relative relocation, add the relocated
+ /// value to the value already in memory, after we adjust it for where the
+ /// PIC base is.
+ reloc_picrel_word = 1,
+
+ /// reloc_absolute_word, reloc_absolute_dword - Absolute relocation, just
+ /// add the relocated value to the value already in memory.
+ reloc_absolute_word = 2,
+ reloc_absolute_dword = 3
+ };
+ }
+}
+</pre>
+</div>
+
+<p>Since the body is small, indenting adds value because it makes it very clear
+where the namespace starts and ends, and it is easy to take the whole thing in
+in one "gulp" when reading the code. If the blob of code in the namespace is
+larger (as it typically is in a header in the <tt>llvm</tt> or <tt>clang</tt> namespaces), do not
+indent the code, and add a comment indicating what namespace is being closed.
+For example:</p>
+
+<div class="doc_code">
+<pre>
+namespace llvm {
+namespace knowledge {
+
+/// Grokable - This class represents things that Smith can have an intimate
+/// understanding of and contains the data associated with it.
+class Grokable {
+...
+public:
+ explicit Grokable() { ... }
+ virtual ~Grokable() = 0;
+
+ ...
+
+};
+
+} // end namespace knowledge
+} // end namespace llvm
+</pre>
+</div>
+
+<p>Because the class is large, we don't expect that the reader can easily
+understand the entire concept in a glance, and the end of the file (where the
+namespaces end) may be a long ways away from the place they open. As such,
+indenting the contents of the namespace doesn't add any value, and detracts from
+the readability of the class. In these cases it is best to <em>not</em> indent
+the contents of the namespace.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<h4>
+ <a name="micro_anonns">Anonymous Namespaces</a>
+</h4>
+
+<div>
+
+<p>After talking about namespaces in general, you may be wondering about
+anonymous namespaces in particular.
+Anonymous namespaces are a great language feature that tells the C++ compiler
+that the contents of the namespace are only visible within the current
+translation unit, allowing more aggressive optimization and eliminating the
+possibility of symbol name collisions. Anonymous namespaces are to C++ as
+"static" is to C functions and global variables. While "static" is available
+in C++, anonymous namespaces are more general: they can make entire classes
+private to a file.</p>
+
+<p>The problem with anonymous namespaces is that they naturally want to
+encourage indentation of their body, and they reduce locality of reference: if
+you see a random function definition in a C++ file, it is easy to see if it is
+marked static, but seeing if it is in an anonymous namespace requires scanning
+a big chunk of the file.</p>
+
+<p>Because of this, we have a simple guideline: make anonymous namespaces as
+small as possible, and only use them for class declarations. For example, this
+is good:</p>
+
+<div class="doc_code">
+<pre>
+<b>namespace {</b>
+ class StringSort {
+ ...
+ public:
+ StringSort(...)
+ bool operator<(const char *RHS) const;
+ };
+<b>} // end anonymous namespace</b>
+
+static void Helper() {
+ ...
+}
+
+bool StringSort::operator<(const char *RHS) const {
+ ...
+}
+
+</pre>
+</div>
+
+<p>This is bad:</p>
+
+
+<div class="doc_code">
+<pre>
+<b>namespace {</b>
+class StringSort {
+...
+public:
+ StringSort(...)
+ bool operator<(const char *RHS) const;
+};
+
+void Helper() {
+ ...
+}
+
+bool StringSort::operator<(const char *RHS) const {
+ ...
+}
+
+<b>} // end anonymous namespace</b>
+
+</pre>
+</div>
+
+
+<p>This is bad specifically because if you're looking at "Helper" in the middle
+of a large C++ file, that you have no immediate way to tell if it is local to
+the file. When it is marked static explicitly, this is immediately obvious.
+Also, there is no reason to enclose the definition of "operator<" in the
+namespace just because it was declared there.
+</p>
+
+</div>
+
+</div>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="seealso">See Also</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<p>A lot of these comments and recommendations have been culled for other
+sources. Two particularly important books for our work are:</p>
+
+<ol>
+
+<li><a href="http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0321334876">Effective
+C++</a> by Scott Meyers. Also
+interesting and useful are "More Effective C++" and "Effective STL" by the same
+author.</li>
+
+<li>Large-Scale C++ Software Design by John Lakos</li>
+
+</ol>
+
+<p>If you get some free time, and you haven't read them: do so, you might learn
+something.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2012-03-27 04:25:16 -0700 (Tue, 27 Mar 2012) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/FileCheck.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/FileCheck.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/FileCheck.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/FileCheck.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,245 @@
+
+=pod
+
+=head1 NAME
+
+FileCheck - Flexible pattern matching file verifier
+
+=head1 SYNOPSIS
+
+B<FileCheck> I<match-filename> [I<--check-prefix=XXX>] [I<--strict-whitespace>]
+
+=head1 DESCRIPTION
+
+B<FileCheck> reads two files (one from standard input, and one specified on the
+command line) and uses one to verify the other. This behavior is particularly
+useful for the testsuite, which wants to verify that the output of some tool
+(e.g. llc) contains the expected information (for example, a movsd from esp or
+whatever is interesting). This is similar to using grep, but it is optimized
+for matching multiple different inputs in one file in a specific order.
+
+The I<match-filename> file specifies the file that contains the patterns to
+match. The file to verify is always read from standard input.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<--check-prefix> I<prefix>
+
+FileCheck searches the contents of I<match-filename> for patterns to match. By
+default, these patterns are prefixed with "CHECK:". If you'd like to use a
+different prefix (e.g. because the same input file is checking multiple
+different tool or options), the B<--check-prefix> argument allows you to specify
+a specific prefix to match.
+
+=item B<--strict-whitespace>
+
+By default, FileCheck canonicalizes input horizontal whitespace (spaces and
+tabs) which causes it to ignore these differences (a space will match a tab).
+The --strict-whitespace argument disables this behavior.
+
+=item B<-version>
+
+Show the version number of this program.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<FileCheck> verifies that the file matches the expected contents, it exits
+with 0. Otherwise, if not, or if an error occurs, it will exit with a non-zero
+value.
+
+=head1 TUTORIAL
+
+FileCheck is typically used from LLVM regression tests, being invoked on the RUN
+line of the test. A simple example of using FileCheck from a RUN line looks
+like this:
+
+ ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s
+
+This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
+llc, then pipe the output of llc into FileCheck. This means that FileCheck will
+be verifying its standard input (the llc output) against the filename argument
+specified (the original .ll file specified by "%s"). To see how this works,
+let's look at the rest of the .ll file (after the RUN line):
+
+ define void @sub1(i32* %p, i32 %v) {
+ entry:
+ ; CHECK: sub1:
+ ; CHECK: subl
+ %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
+ ret void
+ }
+
+ define void @inc4(i64* %p) {
+ entry:
+ ; CHECK: inc4:
+ ; CHECK: incq
+ %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
+ ret void
+ }
+
+Here you can see some "CHECK:" lines specified in comments. Now you can see
+how the file is piped into llvm-as, then llc, and the machine code output is
+what we are verifying. FileCheck checks the machine code output to verify that
+it matches what the "CHECK:" lines specify.
+
+The syntax of the CHECK: lines is very simple: they are fixed strings that
+must occur in order. FileCheck defaults to ignoring horizontal whitespace
+differences (e.g. a space is allowed to match a tab) but otherwise, the contents
+of the CHECK: line is required to match some thing in the test file exactly.
+
+One nice thing about FileCheck (compared to grep) is that it allows merging
+test cases together into logical groups. For example, because the test above
+is checking for the "sub1:" and "inc4:" labels, it will not match unless there
+is a "subl" in between those labels. If it existed somewhere else in the file,
+that would not count: "grep subl" matches if subl exists anywhere in the
+file.
+
+
+
+=head2 The FileCheck -check-prefix option
+
+The FileCheck -check-prefix option allows multiple test configurations to be
+driven from one .ll file. This is useful in many circumstances, for example,
+testing different architectural variants with llc. Here's a simple example:
+
+ ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
+ ; RUN: | FileCheck %s -check-prefix=X32>
+ ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
+ ; RUN: | FileCheck %s -check-prefix=X64>
+
+ define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
+ %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
+ ret <4 x i32> %tmp1
+ ; X32: pinsrd_1:
+ ; X32: pinsrd $1, 4(%esp), %xmm0
+
+ ; X64: pinsrd_1:
+ ; X64: pinsrd $1, %edi, %xmm0
+ }
+
+In this case, we're testing that we get the expected code generation with
+both 32-bit and 64-bit code generation.
+
+
+
+=head2 The "CHECK-NEXT:" directive
+
+Sometimes you want to match lines and would like to verify that matches
+happen on exactly consecutive lines with no other lines in between them. In
+this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
+you specified a custom check prefix, just use "<PREFIX>-NEXT:". For
+example, something like this works as you'd expect:
+
+ define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
+ %tmp3 = load <2 x double>* %A, align 16
+ %tmp7 = insertelement <2 x double> undef, double %B, i32 0
+ %tmp9 = shufflevector <2 x double> %tmp3,
+ <2 x double> %tmp7,
+ <2 x i32> < i32 0, i32 2 >
+ store <2 x double> %tmp9, <2 x double>* %r, align 16
+ ret void
+
+ ; CHECK: t2:
+ ; CHECK: movl 8(%esp), %eax
+ ; CHECK-NEXT: movapd (%eax), %xmm0
+ ; CHECK-NEXT: movhpd 12(%esp), %xmm0
+ ; CHECK-NEXT: movl 4(%esp), %eax
+ ; CHECK-NEXT: movapd %xmm0, (%eax)
+ ; CHECK-NEXT: ret
+ }
+
+CHECK-NEXT: directives reject the input unless there is exactly one newline
+between it an the previous directive. A CHECK-NEXT cannot be the first
+directive in a file.
+
+
+
+=head2 The "CHECK-NOT:" directive
+
+The CHECK-NOT: directive is used to verify that a string doesn't occur
+between two matches (or before the first match, or after the last match). For
+example, to verify that a load is removed by a transformation, a test like this
+can be used:
+
+ define i8 @coerce_offset0(i32 %V, i32* %P) {
+ store i32 %V, i32* %P
+
+ %P2 = bitcast i32* %P to i8*
+ %P3 = getelementptr i8* %P2, i32 2
+
+ %A = load i8* %P3
+ ret i8 %A
+ ; CHECK: @coerce_offset0
+ ; CHECK-NOT: load
+ ; CHECK: ret i8
+ }
+
+
+
+=head2 FileCheck Pattern Matching Syntax
+
+The CHECK: and CHECK-NOT: directives both take a pattern to match. For most
+uses of FileCheck, fixed string matching is perfectly sufficient. For some
+things, a more flexible form of matching is desired. To support this, FileCheck
+allows you to specify regular expressions in matching strings, surrounded by
+double braces: B<{{yourregex}}>. Because we want to use fixed string
+matching for a majority of what we do, FileCheck has been designed to support
+mixing and matching fixed string matching with regular expressions. This allows
+you to write things like this:
+
+ ; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}
+
+In this case, any offset from the ESP register will be allowed, and any xmm
+register will be allowed.
+
+Because regular expressions are enclosed with double braces, they are
+visually distinct, and you don't need to use escape characters within the double
+braces like you would in C. In the rare case that you want to match double
+braces explicitly from the input, you can use something ugly like
+B<{{[{][{]}}> as your pattern.
+
+
+
+=head2 FileCheck Variables
+
+It is often useful to match a pattern and then verify that it occurs again
+later in the file. For codegen tests, this can be useful to allow any register,
+but verify that that register is used consistently later. To do this, FileCheck
+allows named variables to be defined and substituted into patterns. Here is a
+simple example:
+
+ ; CHECK: test5:
+ ; CHECK: notw [[REGISTER:%[a-z]+]]
+ ; CHECK: andw {{.*}}[REGISTER]]
+
+The first check line matches a regex (B<%[a-z]+>) and captures it into
+the variable "REGISTER". The second line verifies that whatever is in REGISTER
+occurs later in the file after an "andw". FileCheck variable references are
+always contained in B<[[ ]]> pairs, are named, and their names can be
+formed with the regex "B<[a-zA-Z_][a-zA-Z0-9_]*>". If a colon follows the
+name, then it is a definition of the variable, if not, it is a use.
+
+FileCheck variables can be defined multiple times, and uses always get the
+latest value. Note that variables are all read at the start of a "CHECK" line
+and are all defined at the end. This means that if you have something like
+"B<CHECK: [[XYZ:.*]]x[[XYZ]]>", the check line will read the previous
+value of the XYZ variable and define a new one after the match is performed. If
+you need to do something like this you can probably take advantage of the fact
+that FileCheck is not actually line-oriented when it matches, this allows you to
+define two separate CHECK lines that match on the same line.
+
+
+
+=head1 AUTHORS
+
+Maintained by The LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/Makefile
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/Makefile?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/Makefile (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/Makefile Tue May 22 14:32:29 2012
@@ -0,0 +1,103 @@
+##===- docs/CommandGuide/Makefile --------------------------*- Makefile -*-===##
+#
+# The LLVM Compiler Infrastructure
+#
+# This file is distributed under the University of Illinois Open Source
+# License. See LICENSE.TXT for details.
+#
+##===----------------------------------------------------------------------===##
+
+ifdef BUILD_FOR_WEBSITE
+# This special case is for keeping the CommandGuide on the LLVM web site
+# up to date automatically as the documents are checked in. It must build
+# the POD files to HTML only and keep them in the src directories. It must also
+# build in an unconfigured tree, hence the ifdef. To use this, run
+# make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script.
+SRC_DOC_DIR=
+DST_HTML_DIR=html/
+DST_MAN_DIR=man/man1/
+DST_PS_DIR=ps/
+
+# If we are in BUILD_FOR_WEBSITE mode, default to the all target.
+all:: html man ps
+
+clean:
+ rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
+
+# To create other directories, as needed, and timestamp their creation
+%/.dir:
+ -mkdir $* > /dev/null
+ date > $@
+
+else
+
+# Otherwise, if not in BUILD_FOR_WEBSITE mode, use the project info.
+LEVEL := ../..
+include $(LEVEL)/Makefile.common
+
+SRC_DOC_DIR=$(PROJ_SRC_DIR)/
+DST_HTML_DIR=$(PROJ_OBJ_DIR)/
+DST_MAN_DIR=$(PROJ_OBJ_DIR)/
+DST_PS_DIR=$(PROJ_OBJ_DIR)/
+
+endif
+
+
+POD := $(wildcard $(SRC_DOC_DIR)*.pod)
+HTML := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_HTML_DIR)%.html, $(POD))
+MAN := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_MAN_DIR)%.1, $(POD))
+PS := $(patsubst $(SRC_DOC_DIR)%.pod, $(DST_PS_DIR)%.ps, $(POD))
+
+# The set of man pages we will not install
+NO_INSTALL_MANS = $(DST_MAN_DIR)FileCheck.1 $(DST_MAN_DIR)llvm-build.1
+
+# The set of man pages that we will install
+INSTALL_MANS = $(filter-out $(NO_INSTALL_MANS), $(MAN))
+
+.SUFFIXES:
+.SUFFIXES: .html .pod .1 .ps
+
+$(DST_HTML_DIR)%.html: %.pod $(DST_HTML_DIR)/.dir
+ pod2html --css=manpage.css --htmlroot=. \
+ --podpath=. --noindex --infile=$< --outfile=$@ --title=$*
+
+$(DST_MAN_DIR)%.1: %.pod $(DST_MAN_DIR)/.dir
+ pod2man --release=CVS --center="LLVM Command Guide" $< $@
+
+$(DST_PS_DIR)%.ps: $(DST_MAN_DIR)%.1 $(DST_PS_DIR)/.dir
+ groff -Tps -man $< > $@
+
+
+html: $(HTML)
+man: $(MAN)
+ps: $(PS)
+
+EXTRA_DIST := $(POD) index.html
+
+clean-local::
+ $(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS)
+
+HTML_DIR := $(DESTDIR)$(PROJ_docsdir)/html/CommandGuide
+MAN_DIR := $(DESTDIR)$(PROJ_mandir)/man1
+PS_DIR := $(DESTDIR)$(PROJ_docsdir)/ps
+
+install-local:: $(HTML) $(INSTALL_MANS) $(PS)
+ $(Echo) Installing HTML CommandGuide Documentation
+ $(Verb) $(MKDIR) $(HTML_DIR)
+ $(Verb) $(DataInstall) $(HTML) $(HTML_DIR)
+ $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/index.html $(HTML_DIR)
+ $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/manpage.css $(HTML_DIR)
+ $(Echo) Installing MAN CommandGuide Documentation
+ $(Verb) $(MKDIR) $(MAN_DIR)
+ $(Verb) $(DataInstall) $(INSTALL_MANS) $(MAN_DIR)
+ $(Echo) Installing PS CommandGuide Documentation
+ $(Verb) $(MKDIR) $(PS_DIR)
+ $(Verb) $(DataInstall) $(PS) $(PS_DIR)
+
+uninstall-local::
+ $(Echo) Uninstalling CommandGuide Documentation
+ $(Verb) $(RM) -rf $(HTML_DIR) $(MAN_DIR) $(PS_DIR)
+
+printvars::
+ $(Echo) "POD : " '$(POD)'
+ $(Echo) "HTML : " '$(HTML)'
Added: www-releases/trunk/3.1/docs/CommandGuide/bugpoint.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/bugpoint.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/bugpoint.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/bugpoint.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,186 @@
+=pod
+
+=head1 NAME
+
+bugpoint - automatic test case reduction tool
+
+=head1 SYNOPSIS
+
+B<bugpoint> [I<options>] [I<input LLVM ll/bc files>] [I<LLVM passes>] B<--args>
+I<program arguments>
+
+=head1 DESCRIPTION
+
+B<bugpoint> narrows down the source of problems in LLVM tools and passes. It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and JIT compilers). It aims to reduce large test cases to small, useful ones.
+For more information on the design and inner workings of B<bugpoint>, as well as
+advice for using bugpoint, see F<llvm/docs/Bugpoint.html> in the LLVM
+distribution.
+
+=head1 OPTIONS
+
+=over
+
+=item B<--additional-so> F<library>
+
+Load the dynamic shared object F<library> into the test program whenever it is
+run. This is useful if you are debugging programs which depend on non-LLVM
+libraries (such as the X or curses libraries) to run.
+
+=item B<--append-exit-code>=I<{true,false}>
+
+Append the test programs exit code to the output file so that a change in exit
+code is considered a test failure. Defaults to false.
+
+=item B<--args> I<program args>
+
+Pass all arguments specified after -args to the test program whenever it runs.
+Note that if any of the I<program args> start with a '-', you should use:
+
+ bugpoint [bugpoint args] --args -- [program args]
+
+The "--" right after the B<--args> option tells B<bugpoint> to consider any
+options starting with C<-> to be part of the B<--args> option, not as options to
+B<bugpoint> itself.
+
+=item B<--tool-args> I<tool args>
+
+Pass all arguments specified after --tool-args to the LLVM tool under test
+(B<llc>, B<lli>, etc.) whenever it runs. You should use this option in the
+following way:
+
+ bugpoint [bugpoint args] --tool-args -- [tool args]
+
+The "--" right after the B<--tool-args> option tells B<bugpoint> to consider any
+options starting with C<-> to be part of the B<--tool-args> option, not as
+options to B<bugpoint> itself. (See B<--args>, above.)
+
+=item B<--safe-tool-args> I<tool args>
+
+Pass all arguments specified after B<--safe-tool-args> to the "safe" execution
+tool.
+
+=item B<--gcc-tool-args> I<gcc tool args>
+
+Pass all arguments specified after B<--gcc-tool-args> to the invocation of
+B<gcc>.
+
+=item B<--opt-args> I<opt args>
+
+Pass all arguments specified after B<--opt-args> to the invocation of B<opt>.
+
+=item B<--disable-{dce,simplifycfg}>
+
+Do not run the specified passes to clean up and reduce the size of the test
+program. By default, B<bugpoint> uses these passes internally when attempting to
+reduce test programs. If you're trying to find a bug in one of these passes,
+B<bugpoint> may crash.
+
+=item B<--enable-valgrind>
+
+Use valgrind to find faults in the optimization phase. This will allow
+bugpoint to find otherwise asymptomatic problems caused by memory
+mis-management.
+
+=item B<-find-bugs>
+
+Continually randomize the specified passes and run them on the test program
+until a bug is found or the user kills B<bugpoint>.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<--input> F<filename>
+
+Open F<filename> and redirect the standard input of the test program, whenever
+it runs, to come from that file.
+
+=item B<--load> F<plugin>
+
+Load the dynamic object F<plugin> into B<bugpoint> itself. This object should
+register new optimization passes. Once loaded, the object will add new command
+line options to enable various optimizations. To see the new complete list of
+optimizations, use the B<-help> and B<--load> options together; for example:
+
+ bugpoint --load myNewPass.so -help
+
+=item B<--mlimit> F<megabytes>
+
+Specifies an upper limit on memory usage of the optimization and codegen. Set
+to zero to disable the limit.
+
+=item B<--output> F<filename>
+
+Whenever the test program produces output on its standard output stream, it
+should match the contents of F<filename> (the "reference output"). If you
+do not use this option, B<bugpoint> will attempt to generate a reference output
+by compiling the program with the "safe" backend and running it.
+
+=item B<--profile-info-file> F<filename>
+
+Profile file loaded by B<--profile-loader>.
+
+=item B<--run-{int,jit,llc,cbe,custom}>
+
+Whenever the test program is compiled, B<bugpoint> should generate code for it
+using the specified code generator. These options allow you to choose the
+interpreter, the JIT compiler, the static native code compiler, the C
+backend, or a custom command (see B<--exec-command>) respectively.
+
+=item B<--safe-{llc,cbe,custom}>
+
+When debugging a code generator, B<bugpoint> should use the specified code
+generator as the "safe" code generator. This is a known-good code generator
+used to generate the "reference output" if it has not been provided, and to
+compile portions of the program that as they are excluded from the testcase.
+These options allow you to choose the
+static native code compiler, the C backend, or a custom command,
+(see B<--exec-command>) respectively. The interpreter and the JIT backends
+cannot currently be used as the "safe" backends.
+
+=item B<--exec-command> I<command>
+
+This option defines the command to use with the B<--run-custom> and
+B<--safe-custom> options to execute the bitcode testcase. This can
+be useful for cross-compilation.
+
+=item B<--compile-command> I<command>
+
+This option defines the command to use with the B<--compile-custom>
+option to compile the bitcode testcase. This can be useful for
+testing compiler output without running any link or execute stages. To
+generate a reduced unit test, you may add CHECK directives to the
+testcase and pass the name of an executable compile-command script in this form:
+
+ #!/bin/sh
+ llc "$@"
+ not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
+
+This script will "fail" as long as FileCheck passes. So the result
+will be the minimum bitcode that passes FileCheck.
+
+=item B<--safe-path> I<path>
+
+This option defines the path to the command to execute with the
+B<--safe-{int,jit,llc,cbe,custom}>
+option.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<bugpoint> succeeds in finding a problem, it will exit with 0. Otherwise,
+if an error occurs, it will exit with a non-zero value.
+
+=head1 SEE ALSO
+
+L<opt|opt>
+
+=head1 AUTHOR
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/html/FileCheck.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/FileCheck.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/FileCheck.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/FileCheck.html Tue May 22 14:32:29 2012
@@ -0,0 +1,276 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>FileCheck</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#tutorial">TUTORIAL</a></li>
+ <ul>
+
+ <li><a href="#the_filecheck__check_prefix_option">The FileCheck -check-prefix option</a></li>
+ <li><a href="#the_check_next__directive">The "CHECK-NEXT:" directive</a></li>
+ <li><a href="#the_check_not__directive">The "CHECK-NOT:" directive</a></li>
+ <li><a href="#filecheck_pattern_matching_syntax">FileCheck Pattern Matching Syntax</a></li>
+ <li><a href="#filecheck_variables">FileCheck Variables</a></li>
+ </ul>
+
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>FileCheck - Flexible pattern matching file verifier</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>FileCheck</strong> <em>match-filename</em> [<em>--check-prefix=XXX</em>] [<em>--strict-whitespace</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>FileCheck</strong> reads two files (one from standard input, and one specified on the
+command line) and uses one to verify the other. This behavior is particularly
+useful for the testsuite, which wants to verify that the output of some tool
+(e.g. llc) contains the expected information (for example, a movsd from esp or
+whatever is interesting). This is similar to using grep, but it is optimized
+for matching multiple different inputs in one file in a specific order.</p>
+<p>The <em>match-filename</em> file specifies the file that contains the patterns to
+match. The file to verify is always read from standard input.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="check_prefix_prefix" class="item"><strong>--check-prefix</strong> <em>prefix</em></a></strong></dt>
+
+<dd>
+<p>FileCheck searches the contents of <em>match-filename</em> for patterns to match. By
+default, these patterns are prefixed with "CHECK:". If you'd like to use a
+different prefix (e.g. because the same input file is checking multiple
+different tool or options), the <strong>--check-prefix</strong> argument allows you to specify
+a specific prefix to match.</p>
+</dd>
+<dt><strong><a name="strict_whitespace" class="item"><strong>--strict-whitespace</strong></a></strong></dt>
+
+<dd>
+<p>By default, FileCheck canonicalizes input horizontal whitespace (spaces and
+tabs) which causes it to ignore these differences (a space will match a tab).
+The --strict-whitespace argument disables this behavior.</p>
+</dd>
+<dt><strong><a name="version" class="item"><strong>-version</strong></a></strong></dt>
+
+<dd>
+<p>Show the version number of this program.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>FileCheck</strong> verifies that the file matches the expected contents, it exits
+with 0. Otherwise, if not, or if an error occurs, it will exit with a non-zero
+value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="tutorial">TUTORIAL</a></h1>
+<p>FileCheck is typically used from LLVM regression tests, being invoked on the RUN
+line of the test. A simple example of using FileCheck from a RUN line looks
+like this:</p>
+<pre>
+ ; RUN: llvm-as < %s | llc -march=x86-64 | FileCheck %s</pre>
+<p>This syntax says to pipe the current file ("%s") into llvm-as, pipe that into
+llc, then pipe the output of llc into FileCheck. This means that FileCheck will
+be verifying its standard input (the llc output) against the filename argument
+specified (the original .ll file specified by "%s"). To see how this works,
+let's look at the rest of the .ll file (after the RUN line):</p>
+<pre>
+ define void @sub1(i32* %p, i32 %v) {
+ entry:
+ ; CHECK: sub1:
+ ; CHECK: subl
+ %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
+ ret void
+ }
+
+ define void @inc4(i64* %p) {
+ entry:
+ ; CHECK: inc4:
+ ; CHECK: incq
+ %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
+ ret void
+ }</pre>
+<p>Here you can see some "CHECK:" lines specified in comments. Now you can see
+how the file is piped into llvm-as, then llc, and the machine code output is
+what we are verifying. FileCheck checks the machine code output to verify that
+it matches what the "CHECK:" lines specify.</p>
+<p>The syntax of the CHECK: lines is very simple: they are fixed strings that
+must occur in order. FileCheck defaults to ignoring horizontal whitespace
+differences (e.g. a space is allowed to match a tab) but otherwise, the contents
+of the CHECK: line is required to match some thing in the test file exactly.</p>
+<p>One nice thing about FileCheck (compared to grep) is that it allows merging
+test cases together into logical groups. For example, because the test above
+is checking for the "sub1:" and "inc4:" labels, it will not match unless there
+is a "subl" in between those labels. If it existed somewhere else in the file,
+that would not count: "grep subl" matches if subl exists anywhere in the
+file.</p>
+<p>
+</p>
+<h2><a name="the_filecheck__check_prefix_option">The FileCheck -check-prefix option</a></h2>
+<p>The FileCheck -check-prefix option allows multiple test configurations to be
+driven from one .ll file. This is useful in many circumstances, for example,
+testing different architectural variants with llc. Here's a simple example:</p>
+<pre>
+ ; RUN: llvm-as < %s | llc -mtriple=i686-apple-darwin9 -mattr=sse41 \
+ ; RUN: | FileCheck %s -check-prefix=X32>
+ ; RUN: llvm-as < %s | llc -mtriple=x86_64-apple-darwin9 -mattr=sse41 \
+ ; RUN: | FileCheck %s -check-prefix=X64></pre>
+<pre>
+ define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
+ %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
+ ret <4 x i32> %tmp1
+ ; X32: pinsrd_1:
+ ; X32: pinsrd $1, 4(%esp), %xmm0
+
+ ; X64: pinsrd_1:
+ ; X64: pinsrd $1, %edi, %xmm0
+ }</pre>
+<p>In this case, we're testing that we get the expected code generation with
+both 32-bit and 64-bit code generation.</p>
+<p>
+</p>
+<h2><a name="the_check_next__directive">The "CHECK-NEXT:" directive</a></h2>
+<p>Sometimes you want to match lines and would like to verify that matches
+happen on exactly consecutive lines with no other lines in between them. In
+this case, you can use CHECK: and CHECK-NEXT: directives to specify this. If
+you specified a custom check prefix, just use "<PREFIX>-NEXT:". For
+example, something like this works as you'd expect:</p>
+<pre>
+ define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
+ %tmp3 = load <2 x double>* %A, align 16
+ %tmp7 = insertelement <2 x double> undef, double %B, i32 0
+ %tmp9 = shufflevector <2 x double> %tmp3,
+ <2 x double> %tmp7,
+ <2 x i32> < i32 0, i32 2 >
+ store <2 x double> %tmp9, <2 x double>* %r, align 16
+ ret void
+
+ ; CHECK: t2:
+ ; CHECK: movl 8(%esp), %eax
+ ; CHECK-NEXT: movapd (%eax), %xmm0
+ ; CHECK-NEXT: movhpd 12(%esp), %xmm0
+ ; CHECK-NEXT: movl 4(%esp), %eax
+ ; CHECK-NEXT: movapd %xmm0, (%eax)
+ ; CHECK-NEXT: ret
+ }</pre>
+<p>CHECK-NEXT: directives reject the input unless there is exactly one newline
+between it an the previous directive. A CHECK-NEXT cannot be the first
+directive in a file.</p>
+<p>
+</p>
+<h2><a name="the_check_not__directive">The "CHECK-NOT:" directive</a></h2>
+<p>The CHECK-NOT: directive is used to verify that a string doesn't occur
+between two matches (or before the first match, or after the last match). For
+example, to verify that a load is removed by a transformation, a test like this
+can be used:</p>
+<pre>
+ define i8 @coerce_offset0(i32 %V, i32* %P) {
+ store i32 %V, i32* %P
+
+ %P2 = bitcast i32* %P to i8*
+ %P3 = getelementptr i8* %P2, i32 2</pre>
+<pre>
+ %A = load i8* %P3
+ ret i8 %A
+ ; CHECK: @coerce_offset0
+ ; CHECK-NOT: load
+ ; CHECK: ret i8
+ }</pre>
+<p>
+</p>
+<h2><a name="filecheck_pattern_matching_syntax">FileCheck Pattern Matching Syntax</a></h2>
+<p>The CHECK: and CHECK-NOT: directives both take a pattern to match. For most
+uses of FileCheck, fixed string matching is perfectly sufficient. For some
+things, a more flexible form of matching is desired. To support this, FileCheck
+allows you to specify regular expressions in matching strings, surrounded by
+double braces: <strong>{{yourregex}}</strong>. Because we want to use fixed string
+matching for a majority of what we do, FileCheck has been designed to support
+mixing and matching fixed string matching with regular expressions. This allows
+you to write things like this:</p>
+<pre>
+ ; CHECK: movhpd {{[0-9]+}}(%esp), {{%xmm[0-7]}}</pre>
+<p>In this case, any offset from the ESP register will be allowed, and any xmm
+register will be allowed.</p>
+<p>Because regular expressions are enclosed with double braces, they are
+visually distinct, and you don't need to use escape characters within the double
+braces like you would in C. In the rare case that you want to match double
+braces explicitly from the input, you can use something ugly like
+<strong>{{[{][{]}}</strong> as your pattern.</p>
+<p>
+</p>
+<h2><a name="filecheck_variables">FileCheck Variables</a></h2>
+<p>It is often useful to match a pattern and then verify that it occurs again
+later in the file. For codegen tests, this can be useful to allow any register,
+but verify that that register is used consistently later. To do this, FileCheck
+allows named variables to be defined and substituted into patterns. Here is a
+simple example:</p>
+<pre>
+ ; CHECK: test5:
+ ; CHECK: notw [[REGISTER:%[a-z]+]]
+ ; CHECK: andw {{.*}}[REGISTER]]</pre>
+<p>The first check line matches a regex (<strong>%[a-z]+</strong>) and captures it into
+the variable "REGISTER". The second line verifies that whatever is in REGISTER
+occurs later in the file after an "andw". FileCheck variable references are
+always contained in <strong>[[ ]]</strong> pairs, are named, and their names can be
+formed with the regex "<strong>[a-zA-Z_][a-zA-Z0-9_]*</strong>". If a colon follows the
+name, then it is a definition of the variable, if not, it is a use.</p>
+<p>FileCheck variables can be defined multiple times, and uses always get the
+latest value. Note that variables are all read at the start of a "CHECK" line
+and are all defined at the end. This means that if you have something like
+"<strong>CHECK: [[XYZ:.*]]x[[XYZ]]</strong>", the check line will read the previous
+value of the XYZ variable and define a new one after the match is performed. If
+you need to do something like this you can probably take advantage of the fact
+that FileCheck is not actually line-oriented when it matches, this allows you to
+define two separate CHECK lines that match on the same line.</p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by The LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/bugpoint.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/bugpoint.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/bugpoint.html Tue May 22 14:32:29 2012
@@ -0,0 +1,246 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>bugpoint</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>bugpoint - automatic test case reduction tool</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>bugpoint</strong> [<em>options</em>] [<em>input LLVM ll/bc files</em>] [<em>LLVM passes</em>] <strong>--args</strong>
+<em>program arguments</em></p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>bugpoint</strong> narrows down the source of problems in LLVM tools and passes. It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and JIT compilers). It aims to reduce large test cases to small, useful ones.
+For more information on the design and inner workings of <strong>bugpoint</strong>, as well as
+advice for using bugpoint, see <em class="file">llvm/docs/Bugpoint.html</em> in the LLVM
+distribution.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="additional_so_library" class="item"><strong>--additional-so</strong> <em class="file">library</em></a></strong></dt>
+
+<dd>
+<p>Load the dynamic shared object <em class="file">library</em> into the test program whenever it is
+run. This is useful if you are debugging programs which depend on non-LLVM
+libraries (such as the X or curses libraries) to run.</p>
+</dd>
+<dt><strong><a name="append_exit_code_true_false" class="item"><strong>--append-exit-code</strong>=<em>{true,false}</em></a></strong></dt>
+
+<dd>
+<p>Append the test programs exit code to the output file so that a change in exit
+code is considered a test failure. Defaults to false.</p>
+</dd>
+<dt><strong><a name="args_program_args" class="item"><strong>--args</strong> <em>program args</em></a></strong></dt>
+
+<dd>
+<p>Pass all arguments specified after -args to the test program whenever it runs.
+Note that if any of the <em>program args</em> start with a '-', you should use:</p>
+<pre>
+ bugpoint [bugpoint args] --args -- [program args]</pre>
+<p>The "--" right after the <strong>--args</strong> option tells <strong>bugpoint</strong> to consider any
+options starting with <code>-</code> to be part of the <strong>--args</strong> option, not as options to
+<strong>bugpoint</strong> itself.</p>
+</dd>
+<dt><strong><a name="tool_args_tool_args" class="item"><strong>--tool-args</strong> <em>tool args</em></a></strong></dt>
+
+<dd>
+<p>Pass all arguments specified after --tool-args to the LLVM tool under test
+(<strong>llc</strong>, <strong>lli</strong>, etc.) whenever it runs. You should use this option in the
+following way:</p>
+<pre>
+ bugpoint [bugpoint args] --tool-args -- [tool args]</pre>
+<p>The "--" right after the <strong>--tool-args</strong> option tells <strong>bugpoint</strong> to consider any
+options starting with <code>-</code> to be part of the <strong>--tool-args</strong> option, not as
+options to <strong>bugpoint</strong> itself. (See <strong>--args</strong>, above.)</p>
+</dd>
+<dt><strong><a name="safe_tool_args_tool_args" class="item"><strong>--safe-tool-args</strong> <em>tool args</em></a></strong></dt>
+
+<dd>
+<p>Pass all arguments specified after <strong>--safe-tool-args</strong> to the "safe" execution
+tool.</p>
+</dd>
+<dt><strong><a name="gcc_tool_args_gcc_tool_args" class="item"><strong>--gcc-tool-args</strong> <em>gcc tool args</em></a></strong></dt>
+
+<dd>
+<p>Pass all arguments specified after <strong>--gcc-tool-args</strong> to the invocation of
+<strong>gcc</strong>.</p>
+</dd>
+<dt><strong><a name="opt_args_opt_args" class="item"><strong>--opt-args</strong> <em>opt args</em></a></strong></dt>
+
+<dd>
+<p>Pass all arguments specified after <strong>--opt-args</strong> to the invocation of <strong>opt</strong>.</p>
+</dd>
+<dt><strong><a name="disable_dce_simplifycfg" class="item"><strong>--disable-{dce,simplifycfg}</strong></a></strong></dt>
+
+<dd>
+<p>Do not run the specified passes to clean up and reduce the size of the test
+program. By default, <strong>bugpoint</strong> uses these passes internally when attempting to
+reduce test programs. If you're trying to find a bug in one of these passes,
+<strong>bugpoint</strong> may crash.</p>
+</dd>
+<dt><strong><a name="enable_valgrind" class="item"><strong>--enable-valgrind</strong></a></strong></dt>
+
+<dd>
+<p>Use valgrind to find faults in the optimization phase. This will allow
+bugpoint to find otherwise asymptomatic problems caused by memory
+mis-management.</p>
+</dd>
+<dt><strong><a name="find_bugs" class="item"><strong>-find-bugs</strong></a></strong></dt>
+
+<dd>
+<p>Continually randomize the specified passes and run them on the test program
+until a bug is found or the user kills <strong>bugpoint</strong>.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="input_filename" class="item"><strong>--input</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Open <em class="file">filename</em> and redirect the standard input of the test program, whenever
+it runs, to come from that file.</p>
+</dd>
+<dt><strong><a name="load_plugin" class="item"><strong>--load</strong> <em class="file">plugin</em></a></strong></dt>
+
+<dd>
+<p>Load the dynamic object <em class="file">plugin</em> into <strong>bugpoint</strong> itself. This object should
+register new optimization passes. Once loaded, the object will add new command
+line options to enable various optimizations. To see the new complete list of
+optimizations, use the <strong>-help</strong> and <strong>--load</strong> options together; for example:</p>
+<pre>
+ bugpoint --load myNewPass.so -help</pre>
+</dd>
+<dt><strong><a name="mlimit_megabytes" class="item"><strong>--mlimit</strong> <em class="file">megabytes</em></a></strong></dt>
+
+<dd>
+<p>Specifies an upper limit on memory usage of the optimization and codegen. Set
+to zero to disable the limit.</p>
+</dd>
+<dt><strong><a name="output_filename" class="item"><strong>--output</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Whenever the test program produces output on its standard output stream, it
+should match the contents of <em class="file">filename</em> (the "reference output"). If you
+do not use this option, <strong>bugpoint</strong> will attempt to generate a reference output
+by compiling the program with the "safe" backend and running it.</p>
+</dd>
+<dt><strong><a name="profile_info_file_filename" class="item"><strong>--profile-info-file</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Profile file loaded by <strong>--profile-loader</strong>.</p>
+</dd>
+<dt><strong><a name="run_int_jit_llc_cbe_custom" class="item"><strong>--run-{int,jit,llc,cbe,custom}</strong></a></strong></dt>
+
+<dd>
+<p>Whenever the test program is compiled, <strong>bugpoint</strong> should generate code for it
+using the specified code generator. These options allow you to choose the
+interpreter, the JIT compiler, the static native code compiler, the C
+backend, or a custom command (see <strong>--exec-command</strong>) respectively.</p>
+</dd>
+<dt><strong><a name="safe_llc_cbe_custom" class="item"><strong>--safe-{llc,cbe,custom}</strong></a></strong></dt>
+
+<dd>
+<p>When debugging a code generator, <strong>bugpoint</strong> should use the specified code
+generator as the "safe" code generator. This is a known-good code generator
+used to generate the "reference output" if it has not been provided, and to
+compile portions of the program that as they are excluded from the testcase.
+These options allow you to choose the
+static native code compiler, the C backend, or a custom command,
+(see <strong>--exec-command</strong>) respectively. The interpreter and the JIT backends
+cannot currently be used as the "safe" backends.</p>
+</dd>
+<dt><strong><a name="exec_command_command" class="item"><strong>--exec-command</strong> <em>command</em></a></strong></dt>
+
+<dd>
+<p>This option defines the command to use with the <strong>--run-custom</strong> and
+<strong>--safe-custom</strong> options to execute the bitcode testcase. This can
+be useful for cross-compilation.</p>
+</dd>
+<dt><strong><a name="compile_command_command" class="item"><strong>--compile-command</strong> <em>command</em></a></strong></dt>
+
+<dd>
+<p>This option defines the command to use with the <strong>--compile-custom</strong>
+option to compile the bitcode testcase. This can be useful for
+testing compiler output without running any link or execute stages. To
+generate a reduced unit test, you may add CHECK directives to the
+testcase and pass the name of an executable compile-command script in this form:</p>
+<pre>
+ #!/bin/sh
+ llc "$@"
+ not FileCheck [bugpoint input file].ll < bugpoint-test-program.s</pre>
+<p>This script will "fail" as long as FileCheck passes. So the result
+will be the minimum bitcode that passes FileCheck.</p>
+</dd>
+<dt><strong><a name="safe_path_path" class="item"><strong>--safe-path</strong> <em>path</em></a></strong></dt>
+
+<dd>
+<p>This option defines the path to the command to execute with the
+<strong>--safe-{int,jit,llc,cbe,custom}</strong>
+option.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>bugpoint</strong> succeeds in finding a problem, it will exit with 0. Otherwise,
+if an error occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././opt.html">opt</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/lit.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/lit.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/lit.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/lit.html Tue May 22 14:32:29 2012
@@ -0,0 +1,455 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>lit</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#general_options">GENERAL OPTIONS</a></li>
+ <li><a href="#output_options">OUTPUT OPTIONS</a></li>
+ <li><a href="#execution_options">EXECUTION OPTIONS</a></li>
+ <li><a href="#selection_options">SELECTION OPTIONS</a></li>
+ <li><a href="#additional_options">ADDITIONAL OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#test_discovery">TEST DISCOVERY</a></li>
+ <li><a href="#test_status_results">TEST STATUS RESULTS</a></li>
+ <li><a href="#lit_infrastructure">LIT INFRASTRUCTURE</a></li>
+ <ul>
+
+ <li><a href="#test_suites">TEST SUITES</a></li>
+ <li><a href="#test_discovery">TEST DISCOVERY</a></li>
+ <li><a href="#local_configuration_files">LOCAL CONFIGURATION FILES</a></li>
+ <li><a href="#test_run_output_format">TEST RUN OUTPUT FORMAT</a></li>
+ <ul>
+
+ <li><a href="#example_test_run_output_listing">Example Test Run Output Listing</a></li>
+ </ul>
+
+ <li><a href="#lit_example_tests">LIT EXAMPLE TESTS</a></li>
+ </ul>
+
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>lit - LLVM Integrated Tester</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>lit</strong> [<em>options</em>] [<em>tests</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>lit</strong> is a portable tool for executing LLVM and Clang style test suites,
+summarizing their results, and providing indication of failures. <strong>lit</strong> is
+designed to be a lightweight testing tool with as simple a user interface as
+possible.</p>
+<p><strong>lit</strong> should be run with one or more <em>tests</em> to run specified on the command
+line. Tests can be either individual test files or directories to search for
+tests (see <a href="#test_discovery">TEST DISCOVERY</a>).</p>
+<p>Each specified test will be executed (potentially in parallel) and once all
+tests have been run <strong>lit</strong> will print summary information on the number of tests
+which passed or failed (see <a href="#test_status_results">TEST STATUS RESULTS</a>). The <strong>lit</strong> program will
+execute with a non-zero exit code if any tests fail.</p>
+<p>By default <strong>lit</strong> will use a succinct progress display and will only print
+summary information for test failures. See <a href="#output_options">OUTPUT OPTIONS</a> for options
+controlling the <strong>lit</strong> progress display and output.</p>
+<p><strong>lit</strong> also includes a number of options for controlling how tests are executed
+(specific features may depend on the particular test format). See <a href="#execution_options">EXECUTION OPTIONS</a> for more information.</p>
+<p>Finally, <strong>lit</strong> also supports additional options for only running a subset of
+the options specified on the command line, see <a href="#selection_options">SELECTION OPTIONS</a> for
+more information.</p>
+<p>Users interested in the <strong>lit</strong> architecture or designing a <strong>lit</strong> testing
+implementation should see <a href="#lit_infrastructure">LIT INFRASTRUCTURE</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="general_options">GENERAL OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="h_help" class="item"><strong>-h</strong>, <strong>--help</strong></a></strong></dt>
+
+<dd>
+<p>Show the <strong>lit</strong> help message.</p>
+</dd>
+<dt><strong><a name="j_n_threads_n" class="item"><strong>-j</strong> <em>N</em>, <strong>--threads</strong>=<em>N</em></a></strong></dt>
+
+<dd>
+<p>Run <em>N</em> tests in parallel. By default, this is automatically chosen to match
+the number of detected available CPUs.</p>
+</dd>
+<dt><strong><a name="config_prefix_name" class="item"><strong>--config-prefix</strong>=<em>NAME</em></a></strong></dt>
+
+<dd>
+<p>Search for <em>NAME.cfg</em> and <em>NAME.site.cfg</em> when searching for test suites,
+instead of <em>lit.cfg</em> and <em>lit.site.cfg</em>.</p>
+</dd>
+<dt><strong><a name="param_name_param_name_value" class="item"><strong>--param</strong> <em>NAME</em>, <strong>--param</strong> <em>NAME</em>=<em>VALUE</em></a></strong></dt>
+
+<dd>
+<p>Add a user defined parameter <em>NAME</em> with the given <em>VALUE</em> (or the empty
+string if not given). The meaning and use of these parameters is test suite
+dependent.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="output_options">OUTPUT OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="q_quiet" class="item"><strong>-q</strong>, <strong>--quiet</strong></a></strong></dt>
+
+<dd>
+<p>Suppress any output except for test failures.</p>
+</dd>
+<dt><strong><a name="s_succinct" class="item"><strong>-s</strong>, <strong>--succinct</strong></a></strong></dt>
+
+<dd>
+<p>Show less output, for example don't show information on tests that pass.</p>
+</dd>
+<dt><strong><a name="v_verbose" class="item"><strong>-v</strong>, <strong>--verbose</strong></a></strong></dt>
+
+<dd>
+<p>Show more information on test failures, for example the entire test output
+instead of just the test result.</p>
+</dd>
+<dt><strong><a name="no_progress_bar" class="item"><strong>--no-progress-bar</strong></a></strong></dt>
+
+<dd>
+<p>Do not use curses based progress bar.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="execution_options">EXECUTION OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="path_path" class="item"><strong>--path</strong>=<em>PATH</em></a></strong></dt>
+
+<dd>
+<p>Specify an addition <em>PATH</em> to use when searching for executables in tests.</p>
+</dd>
+<dt><strong><a name="vg" class="item"><strong>--vg</strong></a></strong></dt>
+
+<dd>
+<p>Run individual tests under valgrind (using the memcheck tool). The
+<em>--error-exitcode</em> argument for valgrind is used so that valgrind failures will
+cause the program to exit with a non-zero status.</p>
+</dd>
+<dt><strong><a name="vg_arg_arg" class="item"><strong>--vg-arg</strong>=<em>ARG</em></a></strong></dt>
+
+<dd>
+<p>When <em>--vg</em> is used, specify an additional argument to pass to valgrind itself.</p>
+</dd>
+<dt><strong><a name="time_tests" class="item"><strong>--time-tests</strong></a></strong></dt>
+
+<dd>
+<p>Track the wall time individual tests take to execute and includes the results in
+the summary output. This is useful for determining which tests in a test suite
+take the most time to execute. Note that this option is most useful with <em>-j
+1</em>.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="selection_options">SELECTION OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="max_tests_n" class="item"><strong>--max-tests</strong>=<em>N</em></a></strong></dt>
+
+<dd>
+<p>Run at most <em>N</em> tests and then terminate.</p>
+</dd>
+<dt><strong><a name="max_time_n" class="item"><strong>--max-time</strong>=<em>N</em></a></strong></dt>
+
+<dd>
+<p>Spend at most <em>N</em> seconds (approximately) running tests and then terminate.</p>
+</dd>
+<dt><strong><a name="shuffle" class="item"><strong>--shuffle</strong></a></strong></dt>
+
+<dd>
+<p>Run the tests in a random order.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="additional_options">ADDITIONAL OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="debug" class="item"><strong>--debug</strong></a></strong></dt>
+
+<dd>
+<p>Run <strong>lit</strong> in debug mode, for debugging configuration issues and <strong>lit</strong> itself.</p>
+</dd>
+<dt><strong><a name="show_suites" class="item"><strong>--show-suites</strong></a></strong></dt>
+
+<dd>
+<p>List the discovered test suites as part of the standard output.</p>
+</dd>
+<dt><strong><a name="no_tcl_as_sh" class="item"><strong>--no-tcl-as-sh</strong></a></strong></dt>
+
+<dd>
+<p>Run Tcl scripts internally (instead of converting to shell scripts).</p>
+</dd>
+<dt><strong><a name="repeat_n" class="item"><strong>--repeat</strong>=<em>N</em></a></strong></dt>
+
+<dd>
+<p>Run each test <em>N</em> times. Currently this is primarily useful for timing tests,
+other results are not collated in any reasonable fashion.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p><strong>lit</strong> will exit with an exit code of 1 if there are any FAIL or XPASS
+results. Otherwise, it will exit with the status 0. Other exit codes are used
+for non-test related failures (for example a user error or an internal program
+error).</p>
+<p>
+</p>
+<hr />
+<h1><a name="test_discovery">TEST DISCOVERY</a></h1>
+<p>The inputs passed to <strong>lit</strong> can be either individual tests, or entire
+directories or hierarchies of tests to run. When <strong>lit</strong> starts up, the first
+thing it does is convert the inputs into a complete list of tests to run as part
+of <em>test discovery</em>.</p>
+<p>In the <strong>lit</strong> model, every test must exist inside some <em>test suite</em>. <strong>lit</strong>
+resolves the inputs specified on the command line to test suites by searching
+upwards from the input path until it finds a <em>lit.cfg</em> or <em>lit.site.cfg</em>
+file. These files serve as both a marker of test suites and as configuration
+files which <strong>lit</strong> loads in order to understand how to find and run the tests
+inside the test suite.</p>
+<p>Once <strong>lit</strong> has mapped the inputs into test suites it traverses the list of
+inputs adding tests for individual files and recursively searching for tests in
+directories.</p>
+<p>This behavior makes it easy to specify a subset of tests to run, while still
+allowing the test suite configuration to control exactly how tests are
+interpreted. In addition, <strong>lit</strong> always identifies tests by the test suite they
+are in, and their relative path inside the test suite. For appropriately
+configured projects, this allows <strong>lit</strong> to provide convenient and flexible
+support for out-of-tree builds.</p>
+<p>
+</p>
+<hr />
+<h1><a name="test_status_results">TEST STATUS RESULTS</a></h1>
+<p>Each test ultimately produces one of the following six results:</p>
+<dl>
+<dt><strong><a name="pass" class="item"><strong>PASS</strong></a></strong></dt>
+
+<dd>
+<p>The test succeeded.</p>
+</dd>
+<dt><strong><a name="xfail" class="item"><strong>XFAIL</strong></a></strong></dt>
+
+<dd>
+<p>The test failed, but that is expected. This is used for test formats which allow
+specifying that a test does not currently work, but wish to leave it in the test
+suite.</p>
+</dd>
+<dt><strong><a name="xpass" class="item"><strong>XPASS</strong></a></strong></dt>
+
+<dd>
+<p>The test succeeded, but it was expected to fail. This is used for tests which
+were specified as expected to fail, but are now succeeding (generally because
+the feature they test was broken and has been fixed).</p>
+</dd>
+<dt><strong><a name="fail" class="item"><strong>FAIL</strong></a></strong></dt>
+
+<dd>
+<p>The test failed.</p>
+</dd>
+<dt><strong><a name="unresolved" class="item"><strong>UNRESOLVED</strong></a></strong></dt>
+
+<dd>
+<p>The test result could not be determined. For example, this occurs when the test
+could not be run, the test itself is invalid, or the test was interrupted.</p>
+</dd>
+<dt><strong><a name="unsupported" class="item"><strong>UNSUPPORTED</strong></a></strong></dt>
+
+<dd>
+<p>The test is not supported in this environment. This is used by test formats
+which can report unsupported tests.</p>
+</dd>
+</dl>
+<p>Depending on the test format tests may produce additional information about
+their status (generally only for failures). See the <a href="#output_options">Output</a>
+section for more information.</p>
+<p>
+</p>
+<hr />
+<h1><a name="lit_infrastructure">LIT INFRASTRUCTURE</a></h1>
+<p>This section describes the <strong>lit</strong> testing architecture for users interested in
+creating a new <strong>lit</strong> testing implementation, or extending an existing one.</p>
+<p><strong>lit</strong> proper is primarily an infrastructure for discovering and running
+arbitrary tests, and to expose a single convenient interface to these
+tests. <strong>lit</strong> itself doesn't know how to run tests, rather this logic is
+defined by <em>test suites</em>.</p>
+<p>
+</p>
+<h2><a name="test_suites">TEST SUITES</a></h2>
+<p>As described in <a href="#test_discovery">TEST DISCOVERY</a>, tests are always located inside a <em>test
+suite</em>. Test suites serve to define the format of the tests they contain, the
+logic for finding those tests, and any additional information to run the tests.</p>
+<p><strong>lit</strong> identifies test suites as directories containing <em>lit.cfg</em> or
+<em>lit.site.cfg</em> files (see also <strong>--config-prefix</strong>). Test suites are initially
+discovered by recursively searching up the directory hierarchy for all the input
+files passed on the command line. You can use <strong>--show-suites</strong> to display the
+discovered test suites at startup.</p>
+<p>Once a test suite is discovered, its config file is loaded. Config files
+themselves are Python modules which will be executed. When the config file is
+executed, two important global variables are predefined:</p>
+<dl>
+<dt><strong><a name="lit" class="item"><strong>lit</strong></a></strong></dt>
+
+<dd>
+<p>The global <strong>lit</strong> configuration object (a <em>LitConfig</em> instance), which defines
+the builtin test formats, global configuration parameters, and other helper
+routines for implementing test configurations.</p>
+</dd>
+<dt><strong><a name="config" class="item"><strong>config</strong></a></strong></dt>
+
+<dd>
+<p>This is the config object (a <em>TestingConfig</em> instance) for the test suite,
+which the config file is expected to populate. The following variables are also
+available on the <em>config</em> object, some of which must be set by the config and
+others are optional or predefined:</p>
+<p><strong>name</strong> <em>[required]</em> The name of the test suite, for use in reports and
+diagnostics.</p>
+<p><strong>test_format</strong> <em>[required]</em> The test format object which will be used to
+discover and run tests in the test suite. Generally this will be a builtin test
+format available from the <em>lit.formats</em> module.</p>
+<p><strong>test_src_root</strong> The filesystem path to the test suite root. For out-of-dir
+builds this is the directory that will be scanned for tests.</p>
+<p><strong>test_exec_root</strong> For out-of-dir builds, the path to the test suite root inside
+the object directory. This is where tests will be run and temporary output files
+placed.</p>
+<p><strong>environment</strong> A dictionary representing the environment to use when executing
+tests in the suite.</p>
+<p><strong>suffixes</strong> For <strong>lit</strong> test formats which scan directories for tests, this
+variable is a list of suffixes to identify test files. Used by: <em>ShTest</em>,
+<em>TclTest</em>.</p>
+<p><strong>substitutions</strong> For <strong>lit</strong> test formats which substitute variables into a test
+script, the list of substitutions to perform. Used by: <em>ShTest</em>, <em>TclTest</em>.</p>
+<p><strong>unsupported</strong> Mark an unsupported directory, all tests within it will be
+reported as unsupported. Used by: <em>ShTest</em>, <em>TclTest</em>.</p>
+<p><strong>parent</strong> The parent configuration, this is the config object for the directory
+containing the test suite, or None.</p>
+<p><strong>root</strong> The root configuration. This is the top-most <strong>lit</strong> configuration in
+the project.</p>
+<p><strong>on_clone</strong> The config is actually cloned for every subdirectory inside a test
+suite, to allow local configuration on a per-directory basis. The <em>on_clone</em>
+variable can be set to a Python function which will be called whenever a
+configuration is cloned (for a subdirectory). The function should takes three
+arguments: (1) the parent configuration, (2) the new configuration (which the
+<em>on_clone</em> function will generally modify), and (3) the test path to the new
+directory being scanned.</p>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="test_discovery">TEST DISCOVERY</a></h2>
+<p>Once test suites are located, <strong>lit</strong> recursively traverses the source directory
+(following <em>test_src_root</em>) looking for tests. When <strong>lit</strong> enters a
+sub-directory, it first checks to see if a nested test suite is defined in that
+directory. If so, it loads that test suite recursively, otherwise it
+instantiates a local test config for the directory (see <a href="#local_configuration_files">LOCAL CONFIGURATION FILES</a>).</p>
+<p>Tests are identified by the test suite they are contained within, and the
+relative path inside that suite. Note that the relative path may not refer to an
+actual file on disk; some test formats (such as <em>GoogleTest</em>) define "virtual
+tests" which have a path that contains both the path to the actual test file and
+a subpath to identify the virtual test.</p>
+<p>
+</p>
+<h2><a name="local_configuration_files">LOCAL CONFIGURATION FILES</a></h2>
+<p>When <strong>lit</strong> loads a subdirectory in a test suite, it instantiates a local test
+configuration by cloning the configuration for the parent direction -- the root
+of this configuration chain will always be a test suite. Once the test
+configuration is cloned <strong>lit</strong> checks for a <em>lit.local.cfg</em> file in the
+subdirectory. If present, this file will be loaded and can be used to specialize
+the configuration for each individual directory. This facility can be used to
+define subdirectories of optional tests, or to change other configuration
+parameters -- for example, to change the test format, or the suffixes which
+identify test files.</p>
+<p>
+</p>
+<h2><a name="test_run_output_format">TEST RUN OUTPUT FORMAT</a></h2>
+<p>The b<lit> output for a test run conforms to the following schema, in both short
+and verbose modes (although in short mode no PASS lines will be shown). This
+schema has been chosen to be relatively easy to reliably parse by a machine (for
+example in buildbot log scraping), and for other tools to generate.</p>
+<p>Each test result is expected to appear on a line that matches:</p>
+<p><result code>: <test name> (<progress info>)</p>
+<p>where <result-code> is a standard test result such as PASS, FAIL, XFAIL, XPASS,
+UNRESOLVED, or UNSUPPORTED. The performance result codes of IMPROVED and
+REGRESSED are also allowed.</p>
+<p>The <test name> field can consist of an arbitrary string containing no newline.</p>
+<p>The <progress info> field can be used to report progress information such as
+(1/300) or can be empty, but even when empty the parentheses are required.</p>
+<p>Each test result may include additional (multiline) log information in the
+following format.</p>
+<p><log delineator> TEST '(<test name>)' <trailing delineator>
+... log message ...
+<log delineator></p>
+<p>where <test name> should be the name of a preceeding reported test, <log
+delineator> is a string of '*' characters <em>at least</em> four characters long (the
+recommended length is 20), and <trailing delineator> is an arbitrary (unparsed)
+string.</p>
+<p>The following is an example of a test run output which consists of four tests A,
+B, C, and D, and a log message for the failing test C.</p>
+<p>
+</p>
+<h3><a name="example_test_run_output_listing">Example Test Run Output Listing</a></h3>
+<p>PASS: A (1 of 4)
+PASS: B (2 of 4)
+FAIL: C (3 of 4)
+******************** TEST 'C' FAILED ********************
+Test 'C' failed as a result of exit code 1.
+********************
+PASS: D (4 of 4)</p>
+<p>
+</p>
+<h2><a name="lit_example_tests">LIT EXAMPLE TESTS</a></h2>
+<p>The <strong>lit</strong> distribution contains several example implementations of test suites
+in the <em>ExampleTests</em> directory.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><em>valgrind(1)</em></p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Written by Daniel Dunbar and maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llc.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llc.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llc.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llc.html Tue May 22 14:32:29 2012
@@ -0,0 +1,265 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llc</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <ul>
+
+ <li><a href="#end_user_options">End-user Options</a></li>
+ <li><a href="#tuning_configuration_options">Tuning/Configuration Options</a></li>
+ <li><a href="#intel_ia_32_specific_options">Intel IA-32-specific Options</a></li>
+ </ul>
+
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llc - LLVM static compiler</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llc</strong> [<em>options</em>] [<em>filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llc</strong> command compiles LLVM source inputs into assembly language for a
+specified architecture. The assembly language output can then be passed through
+a native assembler and linker to generate a native executable.</p>
+<p>The choice of architecture for the output assembly code is automatically
+determined from the input file, unless the <strong>-march</strong> option is used to override
+the default.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<p>If <em>filename</em> is - or omitted, <strong>llc</strong> reads from standard input. Otherwise, it
+will from <em>filename</em>. Inputs can be in either the LLVM assembly language
+format (.ll) or the LLVM bitcode format (.bc).</p>
+<p>If the <strong>-o</strong> option is omitted, then <strong>llc</strong> will send its output to standard
+output if the input is from standard input. If the <strong>-o</strong> option specifies -,
+then the output will also be sent to standard output.</p>
+<p>If no <strong>-o</strong> option is specified and an input file other than - is specified,
+then <strong>llc</strong> creates the output filename by taking the input filename,
+removing any existing <em class="file">.bc</em> extension, and adding a <em class="file">.s</em> suffix.</p>
+<p>Other <strong>llc</strong> options are as follows:</p>
+<p>
+</p>
+<h2><a name="end_user_options">End-user Options</a></h2>
+<dl>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="o_uint" class="item"><strong>-O</strong>=<em>uint</em></a></strong></dt>
+
+<dd>
+<p>Generate code at different optimization levels. These correspond to the <em>-O0</em>,
+<em>-O1</em>, <em>-O2</em>, and <em>-O3</em> optimization levels used by <strong>llvm-gcc</strong> and
+<strong>clang</strong>.</p>
+</dd>
+<dt><strong><a name="mtriple_target_triple" class="item"><strong>-mtriple</strong>=<em>target triple</em></a></strong></dt>
+
+<dd>
+<p>Override the target triple specified in the input file with the specified
+string.</p>
+</dd>
+<dt><strong><a name="march_arch" class="item"><strong>-march</strong>=<em>arch</em></a></strong></dt>
+
+<dd>
+<p>Specify the architecture for which to generate assembly, overriding the target
+encoded in the input file. See the output of <strong>llc -help</strong> for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.</p>
+</dd>
+<dt><strong><a name="mcpu_cpuname" class="item"><strong>-mcpu</strong>=<em>cpuname</em></a></strong></dt>
+
+<dd>
+<p>Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mcpu=help</strong></p>
+</dd>
+<dt><strong><a name="mattr_a1_a2_a3" class="item"><strong>-mattr</strong>=<em>a1,+a2,-a3,...</em></a></strong></dt>
+
+<dd>
+<p>Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not. The default set of attributes is set by the
+current CPU. For a list of available attributes, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mattr=help</strong></p>
+</dd>
+<dt><strong><a name="disable_fp_elim" class="item"><strong>--disable-fp-elim</strong></a></strong></dt>
+
+<dd>
+<p>Disable frame pointer elimination optimization.</p>
+</dd>
+<dt><strong><a name="disable_excess_fp_precision" class="item"><strong>--disable-excess-fp-precision</strong></a></strong></dt>
+
+<dd>
+<p>Disable optimizations that may produce excess precision for floating point.
+Note that this option can dramatically slow down code on some systems
+(e.g. X86).</p>
+</dd>
+<dt><strong><a name="enable_no_infs_fp_math" class="item"><strong>--enable-no-infs-fp-math</strong></a></strong></dt>
+
+<dd>
+<p>Enable optimizations that assume no Inf values.</p>
+</dd>
+<dt><strong><a name="enable_no_nans_fp_math" class="item"><strong>--enable-no-nans-fp-math</strong></a></strong></dt>
+
+<dd>
+<p>Enable optimizations that assume no NAN values.</p>
+</dd>
+<dt><strong><a name="enable_unsafe_fp_math" class="item"><strong>--enable-unsafe-fp-math</strong></a></strong></dt>
+
+<dd>
+<p>Enable optimizations that make unsafe assumptions about IEEE math (e.g. that
+addition is associative) or may not work for all input ranges. These
+optimizations allow the code generator to make use of some instructions which
+would otherwise not be usable (such as fsin on X86).</p>
+</dd>
+<dt><strong><a name="enable_correct_eh_support" class="item"><strong>--enable-correct-eh-support</strong></a></strong></dt>
+
+<dd>
+<p>Instruct the <strong>lowerinvoke</strong> pass to insert code for correct exception handling
+support. This is expensive and is by default omitted for efficiency.</p>
+</dd>
+<dt><strong><a name="stats" class="item"><strong>--stats</strong></a></strong></dt>
+
+<dd>
+<p>Print statistics recorded by code-generation passes.</p>
+</dd>
+<dt><strong><a name="time_passes" class="item"><strong>--time-passes</strong></a></strong></dt>
+
+<dd>
+<p>Record the amount of time needed for each pass and print a report to standard
+error.</p>
+</dd>
+<dt><strong><a name="load_dso_path" class="item"><strong>--load</strong>=<em class="file">dso_path</em></a></strong></dt>
+
+<dd>
+<p>Dynamically load <em class="file">dso_path</em> (a path to a dynamically shared object) that
+implements an LLVM target. This will permit the target name to be used with the
+<strong>-march</strong> option so that code can be generated for that target.</p>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="tuning_configuration_options">Tuning/Configuration Options</a></h2>
+<dl>
+<dt><strong><a name="print_machineinstrs" class="item"><strong>--print-machineinstrs</strong></a></strong></dt>
+
+<dd>
+<p>Print generated machine code between compilation phases (useful for debugging).</p>
+</dd>
+<dt><strong><a name="regalloc_allocator" class="item"><strong>--regalloc</strong>=<em>allocator</em></a></strong></dt>
+
+<dd>
+<p>Specify the register allocator to use. The default <em>allocator</em> is <em>local</em>.
+Valid register allocators are:</p>
+<dl>
+<dt><strong><a name="simple" class="item"><em>simple</em></a></strong></dt>
+
+<dd>
+<p>Very simple "always spill" register allocator</p>
+</dd>
+<dt><strong><a name="local" class="item"><em>local</em></a></strong></dt>
+
+<dd>
+<p>Local register allocator</p>
+</dd>
+<dt><strong><a name="linearscan" class="item"><em>linearscan</em></a></strong></dt>
+
+<dd>
+<p>Linear scan global register allocator</p>
+</dd>
+<dt><strong><a name="iterativescan" class="item"><em>iterativescan</em></a></strong></dt>
+
+<dd>
+<p>Iterative scan global register allocator</p>
+</dd>
+</dl>
+</dd>
+<dt><strong><a name="spiller_spiller" class="item"><strong>--spiller</strong>=<em>spiller</em></a></strong></dt>
+
+<dd>
+<p>Specify the spiller to use for register allocators that support it. Currently
+this option is used only by the linear scan register allocator. The default
+<em>spiller</em> is <em>local</em>. Valid spillers are:</p>
+<dl>
+<dt><strong><em>simple</em></strong></dt>
+
+<dd>
+<p>Simple spiller</p>
+</dd>
+<dt><strong><em>local</em></strong></dt>
+
+<dd>
+<p>Local spiller</p>
+</dd>
+</dl>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="intel_ia_32_specific_options">Intel IA-32-specific Options</a></h2>
+<dl>
+<dt><strong><a name="x86_asm_syntax_att_intel" class="item"><strong>--x86-asm-syntax=att|intel</strong></a></strong></dt>
+
+<dd>
+<p>Specify whether to emit assembly code in AT&T syntax (the default) or intel
+syntax.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llc</strong> succeeds, it will exit with 0. Otherwise, if an error occurs,
+it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././lli.html">lli</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/lli.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/lli.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/lli.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/lli.html Tue May 22 14:32:29 2012
@@ -0,0 +1,288 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>lli</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#general_options">GENERAL OPTIONS</a></li>
+ <li><a href="#target_options">TARGET OPTIONS</a></li>
+ <li><a href="#floating_point_options">FLOATING POINT OPTIONS</a></li>
+ <li><a href="#code_generation_options">CODE GENERATION OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>lli - directly execute programs from LLVM bitcode</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>lli</strong> [<em>options</em>] [<em>filename</em>] [<em>program args</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>lli</strong> directly executes programs in LLVM bitcode format. It takes a program
+in LLVM bitcode format and executes it using a just-in-time compiler, if one is
+available for the current architecture, or an interpreter. <strong>lli</strong> takes all of
+the same code generator options as <a href="././llc.html">llc</a>, but they are only effective when
+<strong>lli</strong> is using the just-in-time compiler.</p>
+<p>If <em>filename</em> is not specified, then <strong>lli</strong> reads the LLVM bitcode for the
+program from standard input.</p>
+<p>The optional <em>args</em> specified on the command line are passed to the program as
+arguments.</p>
+<p>
+</p>
+<hr />
+<h1><a name="general_options">GENERAL OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="fake_argv0_executable" class="item"><strong>-fake-argv0</strong>=<em>executable</em></a></strong></dt>
+
+<dd>
+<p>Override the <code>argv[0]</code> value passed into the executing program.</p>
+</dd>
+<dt><strong><a name="force_interpreter_false_true" class="item"><strong>-force-interpreter</strong>=<em>{false,true}</em></a></strong></dt>
+
+<dd>
+<p>If set to true, use the interpreter even if a just-in-time compiler is available
+for this architecture. Defaults to false.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="load_puginfilename" class="item"><strong>-load</strong>=<em>puginfilename</em></a></strong></dt>
+
+<dd>
+<p>Causes <strong>lli</strong> to load the plugin (shared object) named <em>pluginfilename</em> and use
+it for optimization.</p>
+</dd>
+<dt><strong><a name="stats" class="item"><strong>-stats</strong></a></strong></dt>
+
+<dd>
+<p>Print statistics from the code-generation passes. This is only meaningful for
+the just-in-time compiler, at present.</p>
+</dd>
+<dt><strong><a name="time_passes" class="item"><strong>-time-passes</strong></a></strong></dt>
+
+<dd>
+<p>Record the amount of time needed for each code-generation pass and print it to
+standard error.</p>
+</dd>
+<dt><strong><a name="version" class="item"><strong>-version</strong></a></strong></dt>
+
+<dd>
+<p>Print out the version of <strong>lli</strong> and exit without doing anything else.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="target_options">TARGET OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="mtriple_target_triple" class="item"><strong>-mtriple</strong>=<em>target triple</em></a></strong></dt>
+
+<dd>
+<p>Override the target triple specified in the input bitcode file with the
+specified string. This may result in a crash if you pick an
+architecture which is not compatible with the current system.</p>
+</dd>
+<dt><strong><a name="march_arch" class="item"><strong>-march</strong>=<em>arch</em></a></strong></dt>
+
+<dd>
+<p>Specify the architecture for which to generate assembly, overriding the target
+encoded in the bitcode file. See the output of <strong>llc -help</strong> for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.</p>
+</dd>
+<dt><strong><a name="mcpu_cpuname" class="item"><strong>-mcpu</strong>=<em>cpuname</em></a></strong></dt>
+
+<dd>
+<p>Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mcpu=help</strong></p>
+</dd>
+<dt><strong><a name="mattr_a1_a2_a3" class="item"><strong>-mattr</strong>=<em>a1,+a2,-a3,...</em></a></strong></dt>
+
+<dd>
+<p>Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not. The default set of attributes is set by the
+current CPU. For a list of available attributes, use:
+<strong>llvm-as < /dev/null | llc -march=xyz -mattr=help</strong></p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="floating_point_options">FLOATING POINT OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="disable_excess_fp_precision" class="item"><strong>-disable-excess-fp-precision</strong></a></strong></dt>
+
+<dd>
+<p>Disable optimizations that may increase floating point precision.</p>
+</dd>
+<dt><strong><a name="enable_no_infs_fp_math" class="item"><strong>-enable-no-infs-fp-math</strong></a></strong></dt>
+
+<dd>
+<p>Enable optimizations that assume no Inf values.</p>
+</dd>
+<dt><strong><a name="enable_no_nans_fp_math" class="item"><strong>-enable-no-nans-fp-math</strong></a></strong></dt>
+
+<dd>
+<p>Enable optimizations that assume no NAN values.</p>
+</dd>
+<dt><strong><a name="enable_unsafe_fp_math" class="item"><strong>-enable-unsafe-fp-math</strong></a></strong></dt>
+
+<dd>
+<p>Causes <strong>lli</strong> to enable optimizations that may decrease floating point
+precision.</p>
+</dd>
+<dt><strong><a name="soft_float" class="item"><strong>-soft-float</strong></a></strong></dt>
+
+<dd>
+<p>Causes <strong>lli</strong> to generate software floating point library calls instead of
+equivalent hardware instructions.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="code_generation_options">CODE GENERATION OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="code_model_model" class="item"><strong>-code-model</strong>=<em>model</em></a></strong></dt>
+
+<dd>
+<p>Choose the code model from:</p>
+<pre>
+ default: Target default code model
+ small: Small code model
+ kernel: Kernel code model
+ medium: Medium code model
+ large: Large code model</pre>
+</dd>
+<dt><strong><a name="disable_post_ra_scheduler" class="item"><strong>-disable-post-RA-scheduler</strong></a></strong></dt>
+
+<dd>
+<p>Disable scheduling after register allocation.</p>
+</dd>
+<dt><strong><a name="disable_spill_fusing" class="item"><strong>-disable-spill-fusing</strong></a></strong></dt>
+
+<dd>
+<p>Disable fusing of spill code into instructions.</p>
+</dd>
+<dt><strong><a name="enable_correct_eh_support" class="item"><strong>-enable-correct-eh-support</strong></a></strong></dt>
+
+<dd>
+<p>Make the -lowerinvoke pass insert expensive, but correct, EH code.</p>
+</dd>
+<dt><strong><a name="jit_enable_eh" class="item"><strong>-jit-enable-eh</strong></a></strong></dt>
+
+<dd>
+<p>Exception handling should be enabled in the just-in-time compiler.</p>
+</dd>
+<dt><strong><a name="join_liveintervals" class="item"><strong>-join-liveintervals</strong></a></strong></dt>
+
+<dd>
+<p>Coalesce copies (default=true).</p>
+</dd>
+<dt><strong><a name="nozero_initialized_in_bss_don_t_place_zero_initialized_symbols_into_the_bss_section" class="item"><strong>-nozero-initialized-in-bss</strong>
+Don't place zero-initialized symbols into the BSS section.</a></strong></dt>
+
+<dt><strong><a name="pre_ra_sched_scheduler" class="item"><strong>-pre-RA-sched</strong>=<em>scheduler</em></a></strong></dt>
+
+<dd>
+<p>Instruction schedulers available (before register allocation):</p>
+<pre>
+ =default: Best scheduler for the target
+ =none: No scheduling: breadth first sequencing
+ =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization
+ =simple-noitin: Simple two pass scheduling: Same as simple except using generic latency
+ =list-burr: Bottom-up register reduction list scheduling
+ =list-tdrr: Top-down register reduction list scheduling
+ =list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code</pre>
+</dd>
+<dt><strong><a name="regalloc_allocator" class="item"><strong>-regalloc</strong>=<em>allocator</em></a></strong></dt>
+
+<dd>
+<p>Register allocator to use (default=linearscan)</p>
+<pre>
+ =bigblock: Big-block register allocator
+ =linearscan: linear scan register allocator =local - local register allocator
+ =simple: simple register allocator</pre>
+</dd>
+<dt><strong><a name="relocation_model_model" class="item"><strong>-relocation-model</strong>=<em>model</em></a></strong></dt>
+
+<dd>
+<p>Choose relocation model from:</p>
+<pre>
+ =default: Target default relocation model
+ =static: Non-relocatable code =pic - Fully relocatable, position independent code
+ =dynamic-no-pic: Relocatable external references, non-relocatable code</pre>
+</dd>
+<dt><strong><a name="spiller" class="item"><strong>-spiller</strong></a></strong></dt>
+
+<dd>
+<p>Spiller to use (default=local)</p>
+<pre>
+ =simple: simple spiller
+ =local: local spiller</pre>
+</dd>
+<dt><strong><a name="x86_asm_syntax_syntax" class="item"><strong>-x86-asm-syntax</strong>=<em>syntax</em></a></strong></dt>
+
+<dd>
+<p>Choose style of code to emit from X86 backend:</p>
+<pre>
+ =att: Emit AT&T-style assembly
+ =intel: Emit Intel-style assembly</pre>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>lli</strong> fails to load the program, it will exit with an exit code of 1.
+Otherwise, it will return the exit code of the program it executes.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llc.html">llc</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ar.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ar.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ar.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ar.html Tue May 22 14:32:29 2012
@@ -0,0 +1,479 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-ar</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <ul>
+
+ <li><a href="#operations">Operations</a></li>
+ <li><a href="#modifiers__operation_specific_">Modifiers (operation specific)</a></li>
+ <li><a href="#modifiers__generic_">Modifiers (generic)</a></li>
+ </ul>
+
+ <li><a href="#standards">STANDARDS</a></li>
+ <li><a href="#file_format">FILE FORMAT</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-ar - LLVM archiver</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-ar</strong> [-]{dmpqrtx}[Rabfikouz] [relpos] [count] <archive> [files...]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-ar</strong> command is similar to the common Unix utility, <code>ar</code>. It
+archives several files together into a single file. The intent for this is
+to produce archive libraries by LLVM bitcode that can be linked into an
+LLVM program. However, the archive can contain any kind of file. By default,
+<strong>llvm-ar</strong> generates a symbol table that makes linking faster because
+only the symbol table needs to be consulted, not each individual file member
+of the archive.</p>
+<p>The <strong>llvm-ar</strong> command can be used to <em>read</em> both SVR4 and BSD style archive
+files. However, it cannot be used to write them. While the <strong>llvm-ar</strong> command
+produces files that are <em>almost</em> identical to the format used by other <code>ar</code>
+implementations, it has two significant departures in order to make the
+archive appropriate for LLVM. The first departure is that <strong>llvm-ar</strong> only
+uses BSD4.4 style long path names (stored immediately after the header) and
+never contains a string table for long names. The second departure is that the
+symbol table is formated for efficient construction of an in-memory data
+structure that permits rapid (red-black tree) lookups. Consequently, archives
+produced with <strong>llvm-ar</strong> usually won't be readable or editable with any
+<code>ar</code> implementation or useful for linking. Using the <a href="#f"><code>f</code></a> modifier to flatten
+file names will make the archive readable by other <code>ar</code> implementations
+but not for linking because the symbol table format for LLVM is unique. If an
+SVR4 or BSD style archive is used with the <code>r</code> (replace) or <code>q</code> (quick
+update) operations, the archive will be reconstructed in LLVM format. This
+means that the string table will be dropped (in deference to BSD 4.4 long names)
+and an LLVM symbol table will be added (by default). The system symbol table
+will be retained.</p>
+<p>Here's where <strong>llvm-ar</strong> departs from previous <code>ar</code> implementations:</p>
+<dl>
+<dt><strong><a name="symbol_table" class="item"><em>Symbol Table</em></a></strong></dt>
+
+<dd>
+<p>Since <strong>llvm-ar</strong> is intended to archive bitcode files, the symbol table
+won't make much sense to anything but LLVM. Consequently, the symbol table's
+format has been simplified. It consists simply of a sequence of pairs
+of a file member index number as an LSB 4byte integer and a null-terminated
+string.</p>
+</dd>
+<dt><strong><a name="long_paths" class="item"><em>Long Paths</em></a></strong></dt>
+
+<dd>
+<p>Some <code>ar</code> implementations (SVR4) use a separate file member to record long
+path names (> 15 characters). <strong>llvm-ar</strong> takes the BSD 4.4 and Mac OS X
+approach which is to simply store the full path name immediately preceding
+the data for the file. The path name is null terminated and may contain the
+slash (/) character.</p>
+</dd>
+<dt><strong><a name="compression" class="item"><em>Compression</em></a></strong></dt>
+
+<dd>
+<p><strong>llvm-ar</strong> can compress the members of an archive to save space. The
+compression used depends on what's available on the platform and what choices
+the LLVM Compressor utility makes. It generally favors bzip2 but will select
+between "no compression" or bzip2 depending on what makes sense for the
+file's content.</p>
+</dd>
+<dt><strong><a name="directory_recursion" class="item"><em>Directory Recursion</em></a></strong></dt>
+
+<dd>
+<p>Most <code>ar</code> implementations do not recurse through directories but simply
+ignore directories if they are presented to the program in the <em class="file">files</em>
+option. <strong>llvm-ar</strong>, however, can recurse through directory structures and
+add all the files under a directory, if requested.</p>
+</dd>
+<dt><strong><a name="toc_verbose_output" class="item"><em>TOC Verbose Output</em></a></strong></dt>
+
+<dd>
+<p>When <strong>llvm-ar</strong> prints out the verbose table of contents (<code>tv</code> option), it
+precedes the usual output with a character indicating the basic kind of
+content in the file. A blank means the file is a regular file. A 'Z' means
+the file is compressed. A 'B' means the file is an LLVM bitcode file. An
+'S' means the file is the symbol table.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<p>The options to <strong>llvm-ar</strong> are compatible with other <code>ar</code> implementations.
+However, there are a few modifiers (<em class="file">zR</em>) that are not found in other
+<code>ar</code>s. The options to <strong>llvm-ar</strong> specify a single basic operation to
+perform on the archive, a variety of modifiers for that operation, the
+name of the archive file, and an optional list of file names. These options
+are used to determine how <strong>llvm-ar</strong> should process the archive file.</p>
+<p>The Operations and Modifiers are explained in the sections below. The minimal
+set of options is at least one operator and the name of the archive. Typically
+archive files end with a <a href="#a"><code>.a</code></a> suffix, but this is not required. Following
+the <em class="file">archive-name</em> comes a list of <em class="file">files</em> that indicate the specific members
+of the archive to operate on. If the <em class="file">files</em> option is not specified, it
+generally means either "none" or "all" members, depending on the operation.</p>
+<p>
+</p>
+<h2><a name="operations">Operations</a></h2>
+<dl>
+<dt><strong><a name="d" class="item">d</a></strong></dt>
+
+<dd>
+<p>Delete files from the archive. No modifiers are applicable to this operation.
+The <em class="file">files</em> options specify which members should be removed from the
+archive. It is not an error if a specified file does not appear in the archive.
+If no <em class="file">files</em> are specified, the archive is not modified.</p>
+</dd>
+<dt><strong><a name="m_abi" class="item">m[abi]</a></strong></dt>
+
+<dd>
+<p>Move files from one location in the archive to another. The <em class="file">a</em>, <em class="file">b</em>, and
+<em class="file">i</em> modifiers apply to this operation. The <em class="file">files</em> will all be moved
+to the location given by the modifiers. If no modifiers are used, the files
+will be moved to the end of the archive. If no <em class="file">files</em> are specified, the
+archive is not modified.</p>
+</dd>
+<dt><strong><a name="p_k" class="item">p[k]</a></strong></dt>
+
+<dd>
+<p>Print files to the standard output. The <em class="file">k</em> modifier applies to this
+operation. This operation simply prints the <em class="file">files</em> indicated to the
+standard output. If no <em class="file">files</em> are specified, the entire archive is printed.
+Printing bitcode files is ill-advised as they might confuse your terminal
+settings. The <em class="file">p</em> operation never modifies the archive.</p>
+</dd>
+<dt><strong><a name="q_rfz" class="item">q[Rfz]</a></strong></dt>
+
+<dd>
+<p>Quickly append files to the end of the archive. The <em class="file">R</em>, <em class="file">f</em>, and <em class="file">z</em>
+modifiers apply to this operation. This operation quickly adds the
+<em class="file">files</em> to the archive without checking for duplicates that should be
+removed first. If no <em class="file">files</em> are specified, the archive is not modified.
+Because of the way that <strong>llvm-ar</strong> constructs the archive file, its dubious
+whether the <em class="file">q</em> operation is any faster than the <em class="file">r</em> operation.</p>
+</dd>
+<dt><strong><a name="r_rabfuz" class="item">r[Rabfuz]</a></strong></dt>
+
+<dd>
+<p>Replace or insert file members. The <em class="file">R</em>, <em class="file">a</em>, <em class="file">b</em>, <em class="file">f</em>, <em class="file">u</em>, and <em class="file">z</em>
+modifiers apply to this operation. This operation will replace existing
+<em class="file">files</em> or insert them at the end of the archive if they do not exist. If no
+<em class="file">files</em> are specified, the archive is not modified.</p>
+</dd>
+<dt><strong><a name="t_v" class="item">t[v]</a></strong></dt>
+
+<dd>
+<p>Print the table of contents. Without any modifiers, this operation just prints
+the names of the members to the standard output. With the <em class="file">v</em> modifier,
+<strong>llvm-ar</strong> also prints out the file type (B=bitcode, Z=compressed, S=symbol
+table, blank=regular file), the permission mode, the owner and group, the
+size, and the date. If any <em class="file">files</em> are specified, the listing is only for
+those files. If no <em class="file">files</em> are specified, the table of contents for the
+whole archive is printed.</p>
+</dd>
+<dt><strong><a name="x_op" class="item">x[oP]</a></strong></dt>
+
+<dd>
+<p>Extract archive members back to files. The <em class="file">o</em> modifier applies to this
+operation. This operation retrieves the indicated <em class="file">files</em> from the archive
+and writes them back to the operating system's file system. If no
+<em class="file">files</em> are specified, the entire archive is extract.</p>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="modifiers__operation_specific_">Modifiers (operation specific)</a></h2>
+<p>The modifiers below are specific to certain operations. See the Operations
+section (above) to determine which modifiers are applicable to which operations.</p>
+<dl>
+<dt><strong><a name="a" class="item">[a]</a></strong></dt>
+
+<dd>
+<p>When inserting or moving member files, this option specifies the destination of
+the new files as being <a href="#a"><code>a</code></a>fter the <em class="file">relpos</em> member. If <em class="file">relpos</em> is not found,
+the files are placed at the end of the archive.</p>
+</dd>
+<dt><strong><a name="b" class="item">[b]</a></strong></dt>
+
+<dd>
+<p>When inserting or moving member files, this option specifies the destination of
+the new files as being <a href="#b"><code>b</code></a>efore the <em class="file">relpos</em> member. If <em class="file">relpos</em> is not
+found, the files are placed at the end of the archive. This modifier is
+identical to the the <em class="file">i</em> modifier.</p>
+</dd>
+<dt><strong><a name="f" class="item">[f]</a></strong></dt>
+
+<dd>
+<p>Normally, <strong>llvm-ar</strong> stores the full path name to a file as presented to it on
+the command line. With this option, truncated (15 characters max) names are
+used. This ensures name compatibility with older versions of <code>ar</code> but may also
+thwart correct extraction of the files (duplicates may overwrite). If used with
+the <em class="file">R</em> option, the directory recursion will be performed but the file names
+will all be <a href="#f"><code>f</code></a>lattened to simple file names.</p>
+</dd>
+<dt><strong><a name="i" class="item">[i]</a></strong></dt>
+
+<dd>
+<p>A synonym for the <em class="file">b</em> option.</p>
+</dd>
+<dt><strong><a name="k" class="item">[k]</a></strong></dt>
+
+<dd>
+<p>Normally, <strong>llvm-ar</strong> will not print the contents of bitcode files when the
+<em class="file">p</em> operation is used. This modifier defeats the default and allows the
+bitcode members to be printed.</p>
+</dd>
+<dt><strong><a name="n" class="item">[N]</a></strong></dt>
+
+<dd>
+<p>This option is ignored by <strong>llvm-ar</strong> but provided for compatibility.</p>
+</dd>
+<dt><strong><a name="o" class="item">[o]</a></strong></dt>
+
+<dd>
+<p>When extracting files, this option will cause <strong>llvm-ar</strong> to preserve the
+original modification times of the files it writes.</p>
+</dd>
+<dt><strong><a name="p" class="item">[P]</a></strong></dt>
+
+<dd>
+<p>use full path names when matching</p>
+</dd>
+<dt><strong><a name="r" class="item">[R]</a></strong></dt>
+
+<dd>
+<p>This modifier instructions the <em class="file">r</em> option to recursively process directories.
+Without <em class="file">R</em>, directories are ignored and only those <em class="file">files</em> that refer to
+files will be added to the archive. When <em class="file">R</em> is used, any directories specified
+with <em class="file">files</em> will be scanned (recursively) to find files to be added to the
+archive. Any file whose name begins with a dot will not be added.</p>
+</dd>
+<dt><strong><a name="u" class="item">[u]</a></strong></dt>
+
+<dd>
+<p>When replacing existing files in the archive, only replace those files that have
+a time stamp than the time stamp of the member in the archive.</p>
+</dd>
+<dt><strong><a name="z" class="item">[z]</a></strong></dt>
+
+<dd>
+<p>When inserting or replacing any file in the archive, compress the file first.
+This
+modifier is safe to use when (previously) compressed bitcode files are added to
+the archive; the compressed bitcode files will not be doubly compressed.</p>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="modifiers__generic_">Modifiers (generic)</a></h2>
+<p>The modifiers below may be applied to any operation.</p>
+<dl>
+<dt><strong><a name="c" class="item">[c]</a></strong></dt>
+
+<dd>
+<p>For all operations, <strong>llvm-ar</strong> will always create the archive if it doesn't
+exist. Normally, <strong>llvm-ar</strong> will print a warning message indicating that the
+archive is being created. Using this modifier turns off that warning.</p>
+</dd>
+<dt><strong><a name="s" class="item">[s]</a></strong></dt>
+
+<dd>
+<p>This modifier requests that an archive index (or symbol table) be added to the
+archive. This is the default mode of operation. The symbol table will contain
+all the externally visible functions and global variables defined by all the
+bitcode files in the archive. Using this modifier is more efficient that using
+<a href="././llvm-ranlib.html">llvm-ranlib</a> which also creates the symbol table.</p>
+</dd>
+<dt><strong><a name="s" class="item">[S]</a></strong></dt>
+
+<dd>
+<p>This modifier is the opposite of the <em class="file">s</em> modifier. It instructs <strong>llvm-ar</strong> to
+not build the symbol table. If both <em class="file">s</em> and <em class="file">S</em> are used, the last modifier to
+occur in the options will prevail.</p>
+</dd>
+<dt><strong><a name="v" class="item">[v]</a></strong></dt>
+
+<dd>
+<p>This modifier instructs <strong>llvm-ar</strong> to be verbose about what it is doing. Each
+editing operation taken against the archive will produce a line of output saying
+what is being done.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="standards">STANDARDS</a></h1>
+<p>The <strong>llvm-ar</strong> utility is intended to provide a superset of the IEEE Std 1003.2
+(POSIX.2) functionality for <code>ar</code>. <strong>llvm-ar</strong> can read both SVR4 and BSD4.4 (or
+Mac OS X) archives. If the <a href="#f"><code>f</code></a> modifier is given to the <code>x</code> or <code>r</code> operations
+then <strong>llvm-ar</strong> will write SVR4 compatible archives. Without this modifier,
+<strong>llvm-ar</strong> will write BSD4.4 compatible archives that have long names
+immediately after the header and indicated using the "#1/ddd" notation for the
+name in the header.</p>
+<p>
+</p>
+<hr />
+<h1><a name="file_format">FILE FORMAT</a></h1>
+<p>The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+archive files. In fact, except for the symbol table, the <code>ar</code> commands on those
+operating systems should be able to read LLVM archive files. The details of the
+file format follow.</p>
+<p>Each archive begins with the archive magic number which is the eight printable
+characters "!<arch>\n" where \n represents the newline character (0x0A).
+Following the magic number, the file is composed of even length members that
+begin with an archive header and end with a \n padding character if necessary
+(to make the length even). Each file member is composed of a header (defined
+below), an optional newline-terminated "long file name" and the contents of
+the file.</p>
+<p>The fields of the header are described in the items below. All fields of the
+header contain only ASCII characters, are left justified and are right padded
+with space characters.</p>
+<dl>
+<dt><strong><a name="name_char_16" class="item">name - char[16]</a></strong></dt>
+
+<dd>
+<p>This field of the header provides the name of the archive member. If the name is
+longer than 15 characters or contains a slash (/) character, then this field
+contains <code>#1/nnn</code> where <code>nnn</code> provides the length of the name and the <code>#1/</code>
+is literal. In this case, the actual name of the file is provided in the <code>nnn</code>
+bytes immediately following the header. If the name is 15 characters or less, it
+is contained directly in this field and terminated with a slash (/) character.</p>
+</dd>
+<dt><strong><a name="date_char_12" class="item">date - char[12]</a></strong></dt>
+
+<dd>
+<p>This field provides the date of modification of the file in the form of a
+decimal encoded number that provides the number of seconds since the epoch
+(since 00:00:00 Jan 1, 1970) per Posix specifications.</p>
+</dd>
+<dt><strong><a name="uid_char_6" class="item">uid - char[6]</a></strong></dt>
+
+<dd>
+<p>This field provides the user id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_uid field of the stat structure returned by the <code>stat(2)</code>
+operating system call.</p>
+</dd>
+<dt><strong><a name="gid_char_6" class="item">gid - char[6]</a></strong></dt>
+
+<dd>
+<p>This field provides the group id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_gid field of the stat structure returned by the <code>stat(2)</code>
+operating system call.</p>
+</dd>
+<dt><strong><a name="mode_char_8" class="item">mode - char[8]</a></strong></dt>
+
+<dd>
+<p>This field provides the access mode of the file encoded as an octal ASCII
+string. This field might not make much sense on non-Unix systems. On Unix, it
+is the same value as the st_mode field of the stat structure returned by the
+<code>stat(2)</code> operating system call.</p>
+</dd>
+<dt><strong><a name="size_char_10" class="item">size - char[10]</a></strong></dt>
+
+<dd>
+<p>This field provides the size of the file, in bytes, encoded as a decimal ASCII
+string. If the size field is negative (starts with a minus sign, 0x02D), then
+the archive member is stored in compressed form. The first byte of the archive
+member's data indicates the compression type used. A value of 0 (0x30) indicates
+that no compression was used. A value of 2 (0x32) indicates that bzip2
+compression was used.</p>
+</dd>
+<dt><strong><a name="fmag_char_2" class="item">fmag - char[2]</a></strong></dt>
+
+<dd>
+<p>This field is the archive file member magic number. Its content is always the
+two characters back tick (0x60) and newline (0x0A). This provides some measure
+utility in identifying archive files that have been corrupted.</p>
+</dd>
+</dl>
+<p>The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed
+that no regular archive member file will want this name. The LLVM symbol table
+is simply composed of a sequence of triplets: byte offset, length of symbol,
+and the symbol itself. Symbols are not null or newline terminated. Here are
+the details on each of these items:</p>
+<dl>
+<dt><strong><a name="offset_vbr_encoded_32_bit_integer" class="item">offset - vbr encoded 32-bit integer</a></strong></dt>
+
+<dd>
+<p>The offset item provides the offset into the archive file where the bitcode
+member is stored that is associated with the symbol. The offset value is 0
+based at the start of the first "normal" file member. To derive the actual
+file offset of the member, you must add the number of bytes occupied by the file
+signature (8 bytes) and the symbol tables. The value of this item is encoded
+using variable bit rate encoding to reduce the size of the symbol table.
+Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
+if there are more bytes to follow. The remaining 7 bits in each byte carry bits
+from the value. The final byte does not have the high bit set.</p>
+</dd>
+<dt><strong><a name="length_vbr_encoded_32_bit_integer" class="item">length - vbr encoded 32-bit integer</a></strong></dt>
+
+<dd>
+<p>The length item provides the length of the symbol that follows. Like this
+<em>offset</em> item, the length is variable bit rate encoded.</p>
+</dd>
+<dt><strong><a name="symbol_character_array" class="item">symbol - character array</a></strong></dt>
+
+<dd>
+<p>The symbol item provides the text of the symbol that is associated with the
+<em>offset</em>. The symbol is not terminated by any character. Its length is provided
+by the <em>length</em> field. Note that is allowed (but unwise) to use non-printing
+characters (even 0x00) in the symbol. This allows for multiple encodings of
+symbol names.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-ar</strong> succeeds, it will exit with 0. A usage error, results
+in an exit code of 1. A hard (file system typically) error results in an
+exit code of 2. Miscellaneous or unknown errors result in an
+exit code of 3.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-ranlib.html">llvm-ranlib</a>, <code>ar(1)</code></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-as.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-as.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-as.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-as.html Tue May 22 14:32:29 2012
@@ -0,0 +1,115 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-as</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-as - LLVM assembler</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-as</strong> [<em>options</em>] [<em>filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>llvm-as</strong> is the LLVM assembler. It reads a file containing human-readable
+LLVM assembly language, translates it to LLVM bitcode, and writes the result
+into a file or to standard output.</p>
+<p>If <em class="file">filename</em> is omitted or is <code>-</code>, then <strong>llvm-as</strong> reads its input from
+standard input.</p>
+<p>If an output file is not specified with the <strong>-o</strong> option, then
+<strong>llvm-as</strong> sends its output to a file or standard output by following
+these rules:</p>
+<ul>
+<li>
+<p>If the input is standard input, then the output is standard output.</p>
+</li>
+<li>
+<p>If the input is a file that ends with <code>.ll</code>, then the output file is of
+the same name, except that the suffix is changed to <code>.bc</code>.</p>
+</li>
+<li>
+<p>If the input is a file that does not end with the <code>.ll</code> suffix, then the
+output file has the same name as the input file, except that the <code>.bc</code>
+suffix is appended.</p>
+</li>
+</ul>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="f" class="item"><strong>-f</strong></a></strong></dt>
+
+<dd>
+<p>Enable binary output on terminals. Normally, <strong>llvm-as</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-as</strong> will write raw bitcode regardless of the output device.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output file name. If <em class="file">filename</em> is <code>-</code>, then <strong>llvm-as</strong>
+sends its output to standard output.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-as</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-dis.html">llvm-dis</a>, <em>gccas</em></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-bcanalyzer.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-bcanalyzer.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-bcanalyzer.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-bcanalyzer.html Tue May 22 14:32:29 2012
@@ -0,0 +1,409 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-bcanalyzer</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#summary_output_definitions">SUMMARY OUTPUT DEFINITIONS</a></li>
+ <li><a href="#detailed_output_definitions">DETAILED OUTPUT DEFINITIONS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-bcanalyzer - LLVM bitcode analyzer</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-bcanalyzer</strong> [<em>options</em>] [<em class="file">filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-bcanalyzer</strong> command is a small utility for analyzing bitcode files.
+The tool reads a bitcode file (such as generated with the <strong>llvm-as</strong> tool) and
+produces a statistical report on the contents of the bitcode file. The tool
+can also dump a low level but human readable version of the bitcode file.
+This tool is probably not of much interest or utility except for those working
+directly with the bitcode file format. Most LLVM users can just ignore
+this tool.</p>
+<p>If <em class="file">filename</em> is omitted or is <code>-</code>, then <strong>llvm-bcanalyzer</strong> reads its input
+from standard input. This is useful for combining the tool into a pipeline.
+Output is written to the standard output.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="nodetails" class="item"><strong>-nodetails</strong></a></strong></dt>
+
+<dd>
+<p>Causes <strong>llvm-bcanalyzer</strong> to abbreviate its output by writing out only a module
+level summary. The details for individual functions are not displayed.</p>
+</dd>
+<dt><strong><a name="dump" class="item"><strong>-dump</strong></a></strong></dt>
+
+<dd>
+<p>Causes <strong>llvm-bcanalyzer</strong> to dump the bitcode in a human readable format. This
+format is significantly different from LLVM assembly and provides details about
+the encoding of the bitcode file.</p>
+</dd>
+<dt><strong><a name="verify" class="item"><strong>-verify</strong></a></strong></dt>
+
+<dd>
+<p>Causes <strong>llvm-bcanalyzer</strong> to verify the module produced by reading the
+bitcode. This ensures that the statistics generated are based on a consistent
+module.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-bcanalyzer</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value, usually 1.</p>
+<p>
+</p>
+<hr />
+<h1><a name="summary_output_definitions">SUMMARY OUTPUT DEFINITIONS</a></h1>
+<p>The following items are always printed by llvm-bcanalyzer. They comprize the
+summary output.</p>
+<dl>
+<dt><strong><a name="bitcode_analysis_of_module" class="item"><strong>Bitcode Analysis Of Module</strong></a></strong></dt>
+
+<dd>
+<p>This just provides the name of the module for which bitcode analysis is being
+generated.</p>
+</dd>
+<dt><strong><a name="bitcode_version_number" class="item"><strong>Bitcode Version Number</strong></a></strong></dt>
+
+<dd>
+<p>The bitcode version (not LLVM version) of the file read by the analyzer.</p>
+</dd>
+<dt><strong><a name="file_size" class="item"><strong>File Size</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of the entire bitcode file.</p>
+</dd>
+<dt><strong><a name="module_bytes" class="item"><strong>Module Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of the module block. Percentage is relative to File Size.</p>
+</dd>
+<dt><strong><a name="function_bytes" class="item"><strong>Function Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of all the function blocks. Percentage is relative to File
+Size.</p>
+</dd>
+<dt><strong><a name="global_types_bytes" class="item"><strong>Global Types Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of the Global Types Pool. Percentage is relative to File
+Size. This is the size of the definitions of all types in the bitcode file.</p>
+</dd>
+<dt><strong><a name="constant_pool_bytes" class="item"><strong>Constant Pool Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+Size.</p>
+</dd>
+<dt><strong><a name="module_globals_bytes" class="item"><strong>Module Globals Bytes</strong></a></strong></dt>
+
+<dd>
+<p>Ths size, in bytes, of the Global Variable Definitions and their initializers.
+Percentage is relative to File Size.</p>
+</dd>
+<dt><strong><a name="instruction_list_bytes" class="item"><strong>Instruction List Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of all the instruction lists in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.</p>
+</dd>
+<dt><strong><a name="compaction_table_bytes" class="item"><strong>Compaction Table Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of all the compaction tables in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.</p>
+</dd>
+<dt><strong><a name="symbol_table_bytes" class="item"><strong>Symbol Table Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of all the symbol tables in all the functions. Percentage is
+relative to File Size. Note that this value is also included in the Function
+Bytes.</p>
+</dd>
+<dt><strong><a name="dependent_libraries_bytes" class="item"><strong>Dependent Libraries Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The size, in bytes, of the list of dependent libraries in the module. Percentage
+is relative to File Size. Note that this value is also included in the Module
+Global Bytes.</p>
+</dd>
+<dt><strong><a name="number_of_bitcode_blocks" class="item"><strong>Number Of Bitcode Blocks</strong></a></strong></dt>
+
+<dd>
+<p>The total number of blocks of any kind in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_functions" class="item"><strong>Number Of Functions</strong></a></strong></dt>
+
+<dd>
+<p>The total number of function definitions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_types" class="item"><strong>Number Of Types</strong></a></strong></dt>
+
+<dd>
+<p>The total number of types defined in the Global Types Pool.</p>
+</dd>
+<dt><strong><a name="number_of_constants" class="item"><strong>Number Of Constants</strong></a></strong></dt>
+
+<dd>
+<p>The total number of constants (of any type) defined in the Constant Pool.</p>
+</dd>
+<dt><strong><a name="number_of_basic_blocks" class="item"><strong>Number Of Basic Blocks</strong></a></strong></dt>
+
+<dd>
+<p>The total number of basic blocks defined in all functions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_instructions" class="item"><strong>Number Of Instructions</strong></a></strong></dt>
+
+<dd>
+<p>The total number of instructions defined in all functions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_long_instructions" class="item"><strong>Number Of Long Instructions</strong></a></strong></dt>
+
+<dd>
+<p>The total number of long instructions defined in all functions in the bitcode
+file. Long instructions are those taking greater than 4 bytes. Typically long
+instructions are GetElementPtr with several indices, PHI nodes, and calls to
+functions with large numbers of arguments.</p>
+</dd>
+<dt><strong><a name="number_of_operands" class="item"><strong>Number Of Operands</strong></a></strong></dt>
+
+<dd>
+<p>The total number of operands used in all instructions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_compaction_tables" class="item"><strong>Number Of Compaction Tables</strong></a></strong></dt>
+
+<dd>
+<p>The total number of compaction tables in all functions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_symbol_tables" class="item"><strong>Number Of Symbol Tables</strong></a></strong></dt>
+
+<dd>
+<p>The total number of symbol tables in all functions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="number_of_dependent_libs" class="item"><strong>Number Of Dependent Libs</strong></a></strong></dt>
+
+<dd>
+<p>The total number of dependent libraries found in the bitcode file.</p>
+</dd>
+<dt><strong><a name="total_instruction_size" class="item"><strong>Total Instruction Size</strong></a></strong></dt>
+
+<dd>
+<p>The total size of the instructions in all functions in the bitcode file.</p>
+</dd>
+<dt><strong><a name="average_instruction_size" class="item"><strong>Average Instruction Size</strong></a></strong></dt>
+
+<dd>
+<p>The average number of bytes per instruction across all functions in the bitcode
+file. This value is computed by dividing Total Instruction Size by Number Of
+Instructions.</p>
+</dd>
+<dt><strong><a name="maximum_type_slot_number" class="item"><strong>Maximum Type Slot Number</strong></a></strong></dt>
+
+<dd>
+<p>The maximum value used for a type's slot number. Larger slot number values take
+more bytes to encode.</p>
+</dd>
+<dt><strong><a name="maximum_value_slot_number" class="item"><strong>Maximum Value Slot Number</strong></a></strong></dt>
+
+<dd>
+<p>The maximum value used for a value's slot number. Larger slot number values take
+more bytes to encode.</p>
+</dd>
+<dt><strong><a name="bytes_per_value" class="item"><strong>Bytes Per Value</strong></a></strong></dt>
+
+<dd>
+<p>The average size of a Value definition (of any type). This is computed by
+dividing File Size by the total number of values of any type.</p>
+</dd>
+<dt><strong><a name="bytes_per_global" class="item"><strong>Bytes Per Global</strong></a></strong></dt>
+
+<dd>
+<p>The average size of a global definition (constants and global variables).</p>
+</dd>
+<dt><strong><a name="bytes_per_function" class="item"><strong>Bytes Per Function</strong></a></strong></dt>
+
+<dd>
+<p>The average number of bytes per function definition. This is computed by
+dividing Function Bytes by Number Of Functions.</p>
+</dd>
+<dt><strong><a name="of_vbr_32_bit_integers" class="item"><strong># of VBR 32-bit Integers</strong></a></strong></dt>
+
+<dd>
+<p>The total number of 32-bit integers encoded using the Variable Bit Rate
+encoding scheme.</p>
+</dd>
+<dt><strong><a name="of_vbr_64_bit_integers" class="item"><strong># of VBR 64-bit Integers</strong></a></strong></dt>
+
+<dd>
+<p>The total number of 64-bit integers encoded using the Variable Bit Rate encoding
+scheme.</p>
+</dd>
+<dt><strong><a name="of_vbr_compressed_bytes" class="item"><strong># of VBR Compressed Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes consumed by the 32-bit and 64-bit integers that use
+the Variable Bit Rate encoding scheme.</p>
+</dd>
+<dt><strong><a name="of_vbr_expanded_bytes" class="item"><strong># of VBR Expanded Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes that would have been consumed by the 32-bit and 64-bit
+integers had they not been compressed with the Variable Bit Rage encoding
+scheme.</p>
+</dd>
+<dt><strong><a name="bytes_saved_with_vbr" class="item"><strong>Bytes Saved With VBR</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+The percentage is relative to # of VBR Expanded Bytes.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="detailed_output_definitions">DETAILED OUTPUT DEFINITIONS</a></h1>
+<p>The following definitions occur only if the -nodetails option was not given.
+The detailed output provides additional information on a per-function basis.</p>
+<dl>
+<dt><strong><a name="type" class="item"><strong>Type</strong></a></strong></dt>
+
+<dd>
+<p>The type signature of the function.</p>
+</dd>
+<dt><strong><a name="byte_size" class="item"><strong>Byte Size</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes in the function's block.</p>
+</dd>
+<dt><strong><a name="basic_blocks" class="item"><strong>Basic Blocks</strong></a></strong></dt>
+
+<dd>
+<p>The number of basic blocks defined by the function.</p>
+</dd>
+<dt><strong><a name="instructions" class="item"><strong>Instructions</strong></a></strong></dt>
+
+<dd>
+<p>The number of instructions defined by the function.</p>
+</dd>
+<dt><strong><a name="long_instructions" class="item"><strong>Long Instructions</strong></a></strong></dt>
+
+<dd>
+<p>The number of instructions using the long instruction format in the function.</p>
+</dd>
+<dt><strong><a name="operands" class="item"><strong>Operands</strong></a></strong></dt>
+
+<dd>
+<p>The number of operands used by all instructions in the function.</p>
+</dd>
+<dt><strong><a name="instruction_size" class="item"><strong>Instruction Size</strong></a></strong></dt>
+
+<dd>
+<p>The number of bytes consumed by instructions in the function.</p>
+</dd>
+<dt><strong><a name="average_instruction_size2" class="item"><strong>Average Instruction Size</strong></a></strong></dt>
+
+<dd>
+<p>The average number of bytes consumed by the instructions in the function. This
+value is computed by dividing Instruction Size by Instructions.</p>
+</dd>
+<dt><strong><a name="bytes_per_instruction" class="item"><strong>Bytes Per Instruction</strong></a></strong></dt>
+
+<dd>
+<p>The average number of bytes used by the function per instruction. This value is
+computed by dividing Byte Size by Instructions. Note that this is not the same
+as Average Instruction Size. It computes a number relative to the total function
+size not just the size of the instruction list.</p>
+</dd>
+<dt><strong><a name="number_of_vbr_32_bit_integers" class="item"><strong>Number of VBR 32-bit Integers</strong></a></strong></dt>
+
+<dd>
+<p>The total number of 32-bit integers found in this function (for any use).</p>
+</dd>
+<dt><strong><a name="number_of_vbr_64_bit_integers" class="item"><strong>Number of VBR 64-bit Integers</strong></a></strong></dt>
+
+<dd>
+<p>The total number of 64-bit integers found in this function (for any use).</p>
+</dd>
+<dt><strong><a name="number_of_vbr_compressed_bytes" class="item"><strong>Number of VBR Compressed Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes in this function consumed by the 32-bit and 64-bit
+integers that use the Variable Bit Rate encoding scheme.</p>
+</dd>
+<dt><strong><a name="number_of_vbr_expanded_bytes" class="item"><strong>Number of VBR Expanded Bytes</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes in this function that would have been consumed by
+the 32-bit and 64-bit integers had they not been compressed with the Variable
+Bit Rate encoding scheme.</p>
+</dd>
+<dt><strong><a name="bytes_saved_with_vbr2" class="item"><strong>Bytes Saved With VBR</strong></a></strong></dt>
+
+<dd>
+<p>The total number of bytes saved in this function by using the Variable Bit
+Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-dis.html">llvm-dis</a>, <a href="http://llvm.org/docs/BitCodeFormat.html">http://llvm.org/docs/BitCodeFormat.html</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-build.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-build.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-build.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-build.html Tue May 22 14:32:29 2012
@@ -0,0 +1,133 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-build</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-build - LLVM Project Build Utility</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-build</strong> [<em>options</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>llvm-build</strong> is a tool for working with LLVM projects that use the LLVMBuild
+system for describing their components.</p>
+<p>At heart, <strong>llvm-build</strong> is responsible for loading, verifying, and manipulating
+the project's component data. The tool is primarily designed for use in
+implementing build systems and tools which need access to the project structure
+information.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="h_help" class="item"><strong>-h</strong>, <strong>--help</strong></a></strong></dt>
+
+<dd>
+<p>Print the builtin program help.</p>
+</dd>
+<dt><strong><a name="source_root_path" class="item"><strong>--source-root</strong>=<em>PATH</em></a></strong></dt>
+
+<dd>
+<p>If given, load the project at the given source root path. If this option is not
+given, the location of the project sources will be inferred from the location of
+the <strong>llvm-build</strong> script itself.</p>
+</dd>
+<dt><strong><a name="print_tree" class="item"><strong>--print-tree</strong></a></strong></dt>
+
+<dd>
+<p>Print the component tree for the project.</p>
+</dd>
+<dt><strong><a name="write_library_table" class="item"><strong>--write-library-table</strong></a></strong></dt>
+
+<dd>
+<p>Write out the C++ fragment which defines the components, library names, and
+required libraries. This C++ fragment is built into <a href="././llvm-config.html">llvm-config</a>
+in order to provide clients with the list of required libraries for arbitrary
+component combinations.</p>
+</dd>
+<dt><strong><a name="write_llvmbuild" class="item"><strong>--write-llvmbuild</strong></a></strong></dt>
+
+<dd>
+<p>Write out new <em>LLVMBuild.txt</em> files based on the loaded components. This is
+useful for auto-upgrading the schema of the files. <strong>llvm-build</strong> will try to a
+limited extent to preserve the comments which were written in the original
+source file, although at this time it only preserves block comments that preceed
+the section names in the <em>LLVMBuild</em> files.</p>
+</dd>
+<dt><strong><a name="write_cmake_fragment" class="item"><strong>--write-cmake-fragment</strong></a></strong></dt>
+
+<dd>
+<p>Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+consumed by the CMake based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with CMake, see LLVM's
+top-level CMakeLists.txt.</p>
+</dd>
+<dt><strong><a name="write_make_fragment" class="item"><strong>--write-make-fragment</strong></a></strong></dt>
+
+<dd>
+<p>Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
+consumed by a Make based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with the Makefiles, see
+LLVM's Makefile.rules.</p>
+</dd>
+<dt><strong><a name="llvmbuild_source_root_path" class="item"><strong>--llvmbuild-source-root</strong>=<em>PATH</em></a></strong></dt>
+
+<dd>
+<p>If given, expect the <em>LLVMBuild</em> files for the project to be rooted at the
+given path, instead of inside the source tree itself. This option is primarily
+designed for use in conjunction with <strong>--write-llvmbuild</strong> to test changes to
+<em>LLVMBuild</em> schema.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p><strong>llvm-build</strong> exits with 0 if operation was successful. Otherwise, it will exist
+with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-config.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-config.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-config.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-config.html Tue May 22 14:32:29 2012
@@ -0,0 +1,192 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-config</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#examples">EXAMPLES</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#components">COMPONENTS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-config - Print LLVM compilation options</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-config</strong> <em>option</em> [<em>components</em>...]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>llvm-config</strong> makes it easier to build applications that use LLVM. It can
+print the compiler flags, linker flags and object libraries needed to link
+against LLVM.</p>
+<p>
+</p>
+<hr />
+<h1><a name="examples">EXAMPLES</a></h1>
+<p>To link against the JIT:</p>
+<pre>
+ g++ `llvm-config --cxxflags` -o HowToUseJIT.o -c HowToUseJIT.cpp
+ g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \
+ `llvm-config --libs engine bcreader scalaropts`</pre>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="version" class="item"><strong>--version</strong></a></strong></dt>
+
+<dd>
+<p>Print the version number of LLVM.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of <strong>llvm-config</strong> arguments.</p>
+</dd>
+<dt><strong><a name="prefix" class="item"><strong>--prefix</strong></a></strong></dt>
+
+<dd>
+<p>Print the installation prefix for LLVM.</p>
+</dd>
+<dt><strong><a name="src_root" class="item"><strong>--src-root</strong></a></strong></dt>
+
+<dd>
+<p>Print the source root from which LLVM was built.</p>
+</dd>
+<dt><strong><a name="obj_root" class="item"><strong>--obj-root</strong></a></strong></dt>
+
+<dd>
+<p>Print the object root used to build LLVM.</p>
+</dd>
+<dt><strong><a name="bindir" class="item"><strong>--bindir</strong></a></strong></dt>
+
+<dd>
+<p>Print the installation directory for LLVM binaries.</p>
+</dd>
+<dt><strong><a name="includedir" class="item"><strong>--includedir</strong></a></strong></dt>
+
+<dd>
+<p>Print the installation directory for LLVM headers.</p>
+</dd>
+<dt><strong><a name="libdir" class="item"><strong>--libdir</strong></a></strong></dt>
+
+<dd>
+<p>Print the installation directory for LLVM libraries.</p>
+</dd>
+<dt><strong><a name="cxxflags" class="item"><strong>--cxxflags</strong></a></strong></dt>
+
+<dd>
+<p>Print the C++ compiler flags needed to use LLVM headers.</p>
+</dd>
+<dt><strong><a name="ldflags" class="item"><strong>--ldflags</strong></a></strong></dt>
+
+<dd>
+<p>Print the flags needed to link against LLVM libraries.</p>
+</dd>
+<dt><strong><a name="libs" class="item"><strong>--libs</strong></a></strong></dt>
+
+<dd>
+<p>Print all the libraries needed to link against the specified LLVM
+<em>components</em>, including any dependencies.</p>
+</dd>
+<dt><strong><a name="libnames" class="item"><strong>--libnames</strong></a></strong></dt>
+
+<dd>
+<p>Similar to <strong>--libs</strong>, but prints the bare filenames of the libraries
+without <strong>-l</strong> or pathnames. Useful for linking against a not-yet-installed
+copy of LLVM.</p>
+</dd>
+<dt><strong><a name="libfiles" class="item"><strong>--libfiles</strong></a></strong></dt>
+
+<dd>
+<p>Similar to <strong>--libs</strong>, but print the full path to each library file. This is
+useful when creating makefile dependencies, to ensure that a tool is relinked if
+any library it uses changes.</p>
+</dd>
+<dt><strong><a name="components" class="item"><strong>--components</strong></a></strong></dt>
+
+<dd>
+<p>Print all valid component names.</p>
+</dd>
+<dt><strong><a name="targets_built" class="item"><strong>--targets-built</strong></a></strong></dt>
+
+<dd>
+<p>Print the component names for all targets supported by this copy of LLVM.</p>
+</dd>
+<dt><strong><a name="build_mode" class="item"><strong>--build-mode</strong></a></strong></dt>
+
+<dd>
+<p>Print the build mode used when LLVM was built (e.g. Debug or Release)</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="components">COMPONENTS</a></h1>
+<p>To print a list of all available components, run <strong>llvm-config
+--components</strong>. In most cases, components correspond directly to LLVM
+libraries. Useful "virtual" components include:</p>
+<dl>
+<dt><strong><a name="all" class="item"><strong>all</strong></a></strong></dt>
+
+<dd>
+<p>Includes all LLVM libaries. The default if no components are specified.</p>
+</dd>
+<dt><strong><a name="backend" class="item"><strong>backend</strong></a></strong></dt>
+
+<dd>
+<p>Includes either a native backend or the C backend.</p>
+</dd>
+<dt><strong><a name="engine" class="item"><strong>engine</strong></a></strong></dt>
+
+<dd>
+<p>Includes either a native JIT or the bitcode interpreter.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-config</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-cov.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-cov.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-cov.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-cov.html Tue May 22 14:32:29 2012
@@ -0,0 +1,88 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-cov</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-cov - emit coverage information</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-cov</strong> [-gcno=filename] [-gcda=filename] [dump]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The experimental <strong>llvm-cov</strong> tool reads in description file generated by compiler
+and coverage data file generated by instrumented program. This program assumes
+that the description and data file uses same format as gcov files.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="gcno_filename" class="item"><strong></strong>-gcno=filename]</a></strong></dt>
+
+<dd>
+<p>This option selects input description file generated by compiler while instrumenting
+program.</p>
+</dd>
+<dt><strong><a name="gcda_filename" class="item"><strong></strong>-gcda=filename]</a></strong></dt>
+
+<dd>
+<p>This option selects coverage data file generated by instrumented compiler.</p>
+</dd>
+<dt><strong><a name="dump" class="item"><strong>-dump</strong></a></strong></dt>
+
+<dd>
+<p>This options enables output dump that is suitable for a developer to help debug
+<strong>llvm-cov</strong> itself.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p><strong>llvm-cov</strong> returns 1 if it cannot read input files. Otherwise, it exits with zero.</p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p><strong>llvm-cov</strong> is maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-diff.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-diff.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-diff.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-diff.html Tue May 22 14:32:29 2012
@@ -0,0 +1,89 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-diff</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#bugs">BUGS</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-diff - LLVM structural 'diff'</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-diff</strong> [<em>options</em>] <em>module 1</em> <em>module 2</em> [<em>global name ...</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>llvm-diff</strong> compares the structure of two LLVM modules, primarily
+focusing on differences in function definitions. Insignificant
+differences, such as changes in the ordering of globals or in the
+names of local values, are ignored.</p>
+<p>An input module will be interpreted as an assembly file if its name
+ends in '.ll'; otherwise it will be read in as a bitcode file.</p>
+<p>If a list of global names is given, just the values with those names
+are compared; otherwise, all global values are compared, and
+diagnostics are produced for globals which only appear in one module
+or the other.</p>
+<p><strong>llvm-diff</strong> compares two functions by comparing their basic blocks,
+beginning with the entry blocks. If the terminators seem to match,
+then the corresponding successors are compared; otherwise they are
+ignored. This algorithm is very sensitive to changes in control flow,
+which tend to stop any downstream changes from being detected.</p>
+<p><strong>llvm-diff</strong> is intended as a debugging tool for writers of LLVM
+passes and frontends. It does not have a stable output format.</p>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-diff</strong> finds no differences between the modules, it will exit
+with 0 and produce no output. Otherwise it will exit with a non-zero
+value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="bugs">BUGS</a></h1>
+<p>Many important differences, like changes in linkage or function
+attributes, are not diagnosed.</p>
+<p>Changes in memory behavior (for example, coalescing loads) can cause
+massive detected differences in blocks.</p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-dis.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-dis.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-dis.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-dis.html Tue May 22 14:32:29 2012
@@ -0,0 +1,103 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-dis</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-dis - LLVM disassembler</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-dis</strong> [<em>options</em>] [<em>filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-dis</strong> command is the LLVM disassembler. It takes an LLVM
+bitcode file and converts it into human-readable LLVM assembly language.</p>
+<p>If filename is omitted or specified as <code>-</code>, <strong>llvm-dis</strong> reads its
+input from standard input.</p>
+<p>If the input is being read from standard input, then <strong>llvm-dis</strong>
+will send its output to standard output by default. Otherwise, the
+output will be written to a file named after the input file, with
+a <code>.ll</code> suffix added (any existing <code>.bc</code> suffix will first be
+removed). You can override the choice of output file using the
+<strong>-o</strong> option.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="f" class="item"><strong>-f</strong></a></strong></dt>
+
+<dd>
+<p>Enable binary output on terminals. Normally, <strong>llvm-dis</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-dis</strong> will write raw bitcode regardless of the output device.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output file name. If <em class="file">filename</em> is -, then the output is sent
+to standard output.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-dis</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-as.html">llvm-as</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-extract.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-extract.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-extract.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-extract.html Tue May 22 14:32:29 2012
@@ -0,0 +1,133 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-extract</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-extract - extract a function from an LLVM module</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-extract</strong> [<em>options</em>] <strong>--func</strong> <em>function-name</em> [<em>filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-extract</strong> command takes the name of a function and extracts it from
+the specified LLVM bitcode file. It is primarily used as a debugging tool to
+reduce test cases from larger programs that are triggering a bug.</p>
+<p>In addition to extracting the bitcode of the specified function,
+<strong>llvm-extract</strong> will also remove unreachable global variables, prototypes, and
+unused types.</p>
+<p>The <strong>llvm-extract</strong> command reads its input from standard input if filename is
+omitted or if filename is -. The output is always written to standard output,
+unless the <strong>-o</strong> option is specified (see below).</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="f" class="item"><strong>-f</strong></a></strong></dt>
+
+<dd>
+<p>Enable binary output on terminals. Normally, <strong>llvm-extract</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-extract</strong> will write raw bitcode regardless of the output device.</p>
+</dd>
+<dt><strong><a name="func_function_name" class="item"><strong>--func</strong> <em>function-name</em></a></strong></dt>
+
+<dd>
+<p>Extract the function named <em>function-name</em> from the LLVM bitcode. May be
+specified multiple times to extract multiple functions at once.</p>
+</dd>
+<dt><strong><a name="rfunc_function_regular_expr" class="item"><strong>--rfunc</strong> <em>function-regular-expr</em></a></strong></dt>
+
+<dd>
+<p>Extract the function(s) matching <em>function-regular-expr</em> from the LLVM bitcode.
+All functions matching the regular expression will be extracted. May be
+specified multiple times.</p>
+</dd>
+<dt><strong><a name="glob_global_name" class="item"><strong>--glob</strong> <em>global-name</em></a></strong></dt>
+
+<dd>
+<p>Extract the global variable named <em>global-name</em> from the LLVM bitcode. May be
+specified multiple times to extract multiple global variables at once.</p>
+</dd>
+<dt><strong><a name="rglob_glob_regular_expr" class="item"><strong>--rglob</strong> <em>glob-regular-expr</em></a></strong></dt>
+
+<dd>
+<p>Extract the global variable(s) matching <em>global-regular-expr</em> from the LLVM
+bitcode. All global variables matching the regular expression will be extracted.
+May be specified multiple times.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em>filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output filename. If filename is "-" (the default), then
+<strong>llvm-extract</strong> sends its output to standard output.</p>
+</dd>
+<dt><strong><a name="s" class="item"><strong>-S</strong></a></strong></dt>
+
+<dd>
+<p>Write output in LLVM intermediate language (instead of bitcode).</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-extract</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././bugpoint.html">bugpoint</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ld.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ld.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ld.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ld.html Tue May 22 14:32:29 2012
@@ -0,0 +1,308 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-ld</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <ul>
+
+ <li><a href="#search_order">Search Order</a></li>
+ <li><a href="#link_order">Link order</a></li>
+ <li><a href="#library_linkage">Library Linkage</a></li>
+ <li><a href="#native_code_generation">Native code generation</a></li>
+ </ul>
+
+ <li><a href="#options">OPTIONS</a></li>
+ <ul>
+
+ <li><a href="#general_options">General Options</a></li>
+ <li><a href="#input_output_options">Input/Output Options</a></li>
+ <li><a href="#optimization_options">Optimization Options</a></li>
+ </ul>
+
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#environment">ENVIRONMENT</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-ld - LLVM linker</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-ld</strong> <options> <files></p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-ld</strong> tool takes a set of LLVM bitcode files and links them
+together into a single LLVM bitcode file. The output bitcode file can be
+another bitcode file or an executable bitcode program. Using additional
+options, <strong>llvm-ld</strong> is able to produce native code executables.</p>
+<p>The <strong>llvm-ld</strong> tool is the main linker for LLVM. It is used to link together
+the output of LLVM front-end compilers and run "link time" optimizations (mostly
+the inter-procedural kind).</p>
+<p>The <strong>llvm-ld</strong> tools attempts to mimic the interface provided by the default
+system linker so that it can act as a <em>drop-in</em> replacement.</p>
+<p>
+</p>
+<h2><a name="search_order">Search Order</a></h2>
+<p>When looking for objects specified on the command line, <strong>llvm-ld</strong> will search
+for the object first in the current directory and then in the directory
+specified by the <strong>LLVM_LIB_SEARCH_PATH</strong> environment variable. If it cannot
+find the object, it fails.</p>
+<p>When looking for a library specified with the <strong>-l</strong> option, <strong>llvm-ld</strong> first
+attempts to load a file with that name from the current directory. If that
+fails, it looks for lib<em>library</em>.bc, lib<em>library</em>.a, or lib<em>library</em>.<em>shared
+library extension</em>, in that order, in each directory added to the library search
+path with the <strong>-L</strong> option. These directories are searched in the order they
+are specified. If the library cannot be located, then <strong>llvm-ld</strong> looks in the
+directory specified by the <strong>LLVM_LIB_SEARCH_PATH</strong> environment variable. If it
+does not find a library there, it fails.</p>
+<p>The <em>shared library extension</em> may be <em>.so</em>, <em>.dyld</em>, <em>.dll</em>, or something
+different, depending upon the system.</p>
+<p>The <strong>-L</strong> option is global. It does not matter where it is specified in the
+list of command line arguments; the directory is simply added to the search path
+and is applied to all libraries, preceding or succeeding, in the command line.</p>
+<p>
+</p>
+<h2><a name="link_order">Link order</a></h2>
+<p>All object and bitcode files are linked first in the order they were
+specified on the command line. All library files are linked next.
+Some libraries may not be linked into the object program; see below.</p>
+<p>
+</p>
+<h2><a name="library_linkage">Library Linkage</a></h2>
+<p>Object files and static bitcode objects are always linked into the output
+file. Library archives (.a files) load only the objects within the archive
+that define symbols needed by the output file. Hence, libraries should be
+listed after the object files and libraries which need them; otherwise, the
+library may not be linked in, and the dependent library will not have its
+undefined symbols defined.</p>
+<p>
+</p>
+<h2><a name="native_code_generation">Native code generation</a></h2>
+<p>The <strong>llvm-ld</strong> program has limited support for native code generation, when
+using the <strong>-native</strong> or <strong>-native-cbe</strong> options. Native code generation is
+performed by converting the linked bitcode into native assembly (.s) or C code
+and running the system compiler (typically gcc) on the result.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<p>
+</p>
+<h2><a name="general_options">General Options</a></h2>
+<dl>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="v" class="item"><strong>-v</strong></a></strong></dt>
+
+<dd>
+<p>Specifies verbose mode. In this mode the linker will print additional
+information about the actions it takes, programs it executes, etc.</p>
+</dd>
+<dt><strong><a name="stats" class="item"><strong>-stats</strong></a></strong></dt>
+
+<dd>
+<p>Print statistics.</p>
+</dd>
+<dt><strong><a name="time_passes" class="item"><strong>-time-passes</strong></a></strong></dt>
+
+<dd>
+<p>Record the amount of time needed for each pass and print it to standard
+error.</p>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="input_output_options">Input/Output Options</a></h2>
+<dl>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>This overrides the default output file and specifies the name of the file that
+should be generated by the linker. By default, <strong>llvm-ld</strong> generates a file named
+<em class="file">a.out</em> for compatibility with <strong>ld</strong>. The output will be written to
+<em class="file">filename</em>.</p>
+</dd>
+<dt><strong><a name="b_filename" class="item"><strong>-b</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>This option can be used to override the output bitcode file name. By default,
+the name of the bitcode output file is one more ".bc" suffix added to the name
+specified by <strong>-o filename</strong> option.</p>
+</dd>
+<dt><strong><a name="lname" class="item"><strong>-l</strong><em class="file">name</em></a></strong></dt>
+
+<dd>
+<p>This option specifies the <em class="file">name</em> of a library to search when resolving symbols
+for the program. Only the base name should be specified as <em class="file">name</em>, without a
+<em class="file">lib</em> prefix or any suffix.</p>
+</dd>
+<dt><strong><a name="lpath" class="item"><strong>-L</strong><em class="file">Path</em></a></strong></dt>
+
+<dd>
+<p>This option tells <strong>llvm-ld</strong> to look in <em class="file">Path</em> to find any library subsequently
+specified with the <strong>-l</strong> option. The paths will be searched in the order in
+which they are specified on the command line. If the library is still not found,
+a small set of system specific directories will also be searched. Note that
+libraries specified with the <strong>-l</strong> option that occur <em>before</em> any <strong>-L</strong> options
+will not search the paths given by the <strong>-L</strong> options following it.</p>
+</dd>
+<dt><strong><a name="link_as_library" class="item"><strong>-link-as-library</strong></a></strong></dt>
+
+<dd>
+<p>Link the bitcode files together as a library, not an executable. In this mode,
+undefined symbols will be permitted.</p>
+</dd>
+<dt><strong><a name="r" class="item"><strong>-r</strong></a></strong></dt>
+
+<dd>
+<p>An alias for -link-as-library.</p>
+</dd>
+<dt><strong><a name="native" class="item"><strong>-native</strong></a></strong></dt>
+
+<dd>
+<p>Generate a native machine code executable.</p>
+<p>When generating native executables, <strong>llvm-ld</strong> first checks for a bitcode
+version of the library and links it in, if necessary. If the library is
+missing, <strong>llvm-ld</strong> skips it. Then, <strong>llvm-ld</strong> links in the same
+libraries as native code.</p>
+<p>In this way, <strong>llvm-ld</strong> should be able to link in optimized bitcode
+subsets of common libraries and then link in any part of the library that
+hasn't been converted to bitcode.</p>
+</dd>
+<dt><strong><a name="native_cbe" class="item"><strong>-native-cbe</strong></a></strong></dt>
+
+<dd>
+<p>Generate a native machine code executable with the LLVM C backend.</p>
+<pre>
+
+This option is identical to the B<-native> option, but uses the
+C backend to generate code for the program instead of an LLVM native
+code generator.</pre>
+</dd>
+</dl>
+<p>
+</p>
+<h2><a name="optimization_options">Optimization Options</a></h2>
+<dl>
+<dt><strong><a name="disable_inlining" class="item"><strong>-disable-inlining</strong></a></strong></dt>
+
+<dd>
+<p>Do not run the inlining pass. Functions will not be inlined into other
+functions.</p>
+</dd>
+<dt><strong><a name="disable_opt" class="item"><strong>-disable-opt</strong></a></strong></dt>
+
+<dd>
+<p>Completely disable optimization.</p>
+</dd>
+<dt><strong><a name="disable_internalize" class="item"><strong>-disable-internalize</strong></a></strong></dt>
+
+<dd>
+<p>Do not mark all symbols as internal.</p>
+</dd>
+<dt><strong><a name="verify_each" class="item"><strong>-verify-each</strong></a></strong></dt>
+
+<dd>
+<p>Run the verification pass after each of the passes to verify intermediate
+results.</p>
+</dd>
+<dt><strong><a name="strip_all" class="item"><strong>-strip-all</strong></a></strong></dt>
+
+<dd>
+<p>Strip all debug and symbol information from the executable to make it smaller.</p>
+</dd>
+<dt><strong><a name="strip_debug" class="item"><strong>-strip-debug</strong></a></strong></dt>
+
+<dd>
+<p>Strip all debug information from the executable to make it smaller.</p>
+</dd>
+<dt><strong><a name="s" class="item"><strong>-s</strong></a></strong></dt>
+
+<dd>
+<p>An alias for <strong>-strip-all</strong>.</p>
+</dd>
+<dt><strong><a name="s" class="item"><strong>-S</strong></a></strong></dt>
+
+<dd>
+<p>An alias for <strong>-strip-debug</strong>.</p>
+</dd>
+<dt><strong><a name="export_dynamic" class="item"><strong>-export-dynamic</strong></a></strong></dt>
+
+<dd>
+<p>An alias for <strong>-disable-internalize</strong></p>
+</dd>
+<dt><strong><a name="post_link_optpath" class="item"><strong>-post-link-opt</strong><em class="file">Path</em></a></strong></dt>
+
+<dd>
+<p>Run post-link optimization program. After linking is completed a bitcode file
+will be generated. It will be passed to the program specified by <em class="file">Path</em> as the
+first argument. The second argument to the program will be the name of a
+temporary file into which the program should place its optimized output. For
+example, the "no-op optimization" would be a simple shell script:</p>
+<pre>
+ #!/bin/bash
+ cp $1 $2</pre>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-ld</strong> succeeds, it will exit with 0 return code. If an error occurs,
+it will exit with a non-zero return code.</p>
+<p>
+</p>
+<hr />
+<h1><a name="environment">ENVIRONMENT</a></h1>
+<p>The <code>LLVM_LIB_SEARCH_PATH</code> environment variable is used to find bitcode
+libraries. Any paths specified in this variable will be searched after the <code>-L</code>
+options.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-link.html">llvm-link</a></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-link.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-link.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-link.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-link.html Tue May 22 14:32:29 2012
@@ -0,0 +1,127 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-link</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-link - LLVM linker</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-link</strong> [<em>options</em>] <em>filename ...</em></p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>llvm-link</strong> takes several LLVM bitcode files and links them together into a
+single LLVM bitcode file. It writes the output file to standard output, unless
+the <strong>-o</strong> option is used to specify a filename.</p>
+<p><strong>llvm-link</strong> attempts to load the input files from the current directory. If
+that fails, it looks for each file in each of the directories specified by the
+<strong>-L</strong> options on the command line. The library search paths are global; each
+one is searched for every input file if necessary. The directories are searched
+in the order they were specified on the command line.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="l_directory" class="item"><strong>-L</strong> <em class="file">directory</em></a></strong></dt>
+
+<dd>
+<p>Add the specified <em class="file">directory</em> to the library search path. When looking for
+libraries, <strong>llvm-link</strong> will look in path name for libraries. This option can be
+specified multiple times; <strong>llvm-link</strong> will search inside these directories in
+the order in which they were specified on the command line.</p>
+</dd>
+<dt><strong><a name="f" class="item"><strong>-f</strong></a></strong></dt>
+
+<dd>
+<p>Enable binary output on terminals. Normally, <strong>llvm-link</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>llvm-link</strong> will write raw bitcode regardless of the output device.</p>
+</dd>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output file name. If <em class="file">filename</em> is <code>-</code>, then <strong>llvm-link</strong> will
+write its output to standard output.</p>
+</dd>
+<dt><strong><a name="s" class="item"><strong>-S</strong></a></strong></dt>
+
+<dd>
+<p>Write output in LLVM intermediate language (instead of bitcode).</p>
+</dd>
+<dt><strong><a name="d" class="item"><strong>-d</strong></a></strong></dt>
+
+<dd>
+<p>If specified, <strong>llvm-link</strong> prints a human-readable version of the output
+bitcode file to standard error.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="v" class="item"><strong>-v</strong></a></strong></dt>
+
+<dd>
+<p>Verbose mode. Print information about what <strong>llvm-link</strong> is doing. This
+typically includes a message for each bitcode file linked in and for each
+library found.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-link</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><em>gccld</em></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-nm.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-nm.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-nm.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-nm.html Tue May 22 14:32:29 2012
@@ -0,0 +1,176 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-nm</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#bugs">BUGS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-nm - list LLVM bitcode file's symbol table</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-nm</strong> [<em>options</em>] [<em>filenames...</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-nm</strong> utility lists the names of symbols from the LLVM bitcode files,
+or <strong>ar</strong> archives containing LLVM bitcode files, named on the command line.
+Each symbol is listed along with some simple information about its provenance.
+If no file name is specified, or <em>-</em> is used as a file name, <strong>llvm-nm</strong> will
+process a bitcode file on its standard input stream.</p>
+<p><strong>llvm-nm</strong>'s default output format is the traditional BSD <strong>nm</strong> output format.
+Each such output record consists of an (optional) 8-digit hexadecimal address,
+followed by a type code character, followed by a name, for each symbol. One
+record is printed per line; fields are separated by spaces. When the address is
+omitted, it is replaced by 8 spaces.</p>
+<p>Type code characters currently supported, and their meanings, are as follows:</p>
+<dl>
+<dt><strong><a name="u" class="item">U</a></strong></dt>
+
+<dd>
+<p>Named object is referenced but undefined in this bitcode file</p>
+</dd>
+<dt><strong><a name="c" class="item">C</a></strong></dt>
+
+<dd>
+<p>Common (multiple definitions link together into one def)</p>
+</dd>
+<dt><strong><a name="w" class="item">W</a></strong></dt>
+
+<dd>
+<p>Weak reference (multiple definitions link together into zero or one definitions)</p>
+</dd>
+<dt><strong><a name="t" class="item">t</a></strong></dt>
+
+<dd>
+<p>Local function (text) object</p>
+</dd>
+<dt><strong><a name="t" class="item">T</a></strong></dt>
+
+<dd>
+<p>Global function (text) object</p>
+</dd>
+<dt><strong><a name="d" class="item">d</a></strong></dt>
+
+<dd>
+<p>Local data object</p>
+</dd>
+<dt><strong><a name="d" class="item">D</a></strong></dt>
+
+<dd>
+<p>Global data object</p>
+</dd>
+<dt><strong><a name="" class="item">?</a></strong></dt>
+
+<dd>
+<p>Something unrecognizable</p>
+</dd>
+</dl>
+<p>Because LLVM bitcode files typically contain objects that are not considered to
+have addresses until they are linked into an executable image or dynamically
+compiled "just-in-time", <strong>llvm-nm</strong> does not print an address for any symbol,
+even symbols which are defined in the bitcode file.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="p" class="item"><strong>-P</strong></a></strong></dt>
+
+<dd>
+<p>Use POSIX.2 output format. Alias for <strong>--format=posix</strong>.</p>
+</dd>
+<dt><strong><a name="b" class="item"><strong>-B</strong> (default)</a></strong></dt>
+
+<dd>
+<p>Use BSD output format. Alias for <strong>--format=bsd</strong>.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command-line options and their meanings.</p>
+</dd>
+<dt><strong><a name="defined_only" class="item"><strong>--defined-only</strong></a></strong></dt>
+
+<dd>
+<p>Print only symbols defined in this bitcode file (as opposed to
+symbols which may be referenced by objects in this file, but not
+defined in this file.)</p>
+</dd>
+<dt><strong><a name="extern_only_g" class="item"><strong>--extern-only</strong>, <strong>-g</strong></a></strong></dt>
+
+<dd>
+<p>Print only symbols whose definitions are external; that is, accessible
+from other bitcode files.</p>
+</dd>
+<dt><strong><a name="undefined_only_u" class="item"><strong>--undefined-only</strong>, <strong>-u</strong></a></strong></dt>
+
+<dd>
+<p>Print only symbols referenced but not defined in this bitcode file.</p>
+</dd>
+<dt><strong><a name="format_fmt_f" class="item"><strong>--format=</strong><em>fmt</em>, <strong>-f</strong></a></strong></dt>
+
+<dd>
+<p>Select an output format; <em>fmt</em> may be <em>sysv</em>, <em>posix</em>, or <em>bsd</em>. The
+default is <em>bsd</em>.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="bugs">BUGS</a></h1>
+<p><strong>llvm-nm</strong> cannot demangle C++ mangled names, like GNU <strong>nm</strong> can.</p>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p><strong>llvm-nm</strong> exits with an exit code of zero.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-dis.html">llvm-dis</a>, <code>ar(1)</code>, <code>nm(1)</code></p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-prof.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-prof.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-prof.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-prof.html Tue May 22 14:32:29 2012
@@ -0,0 +1,99 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-prof</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-prof - print execution profile of LLVM program</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-prof</strong> [<em>options</em>] [<em>bitcode file</em>] [<em>llvmprof.out</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-prof</strong> tool reads in an <em class="file">llvmprof.out</em> file (which can
+optionally use a specific file with the third program argument), a bitcode file
+for the program, and produces a human readable report, suitable for determining
+where the program hotspots are.</p>
+<p>This program is often used in conjunction with the <em class="file">utils/profile.pl</em>
+script. This script automatically instruments a program, runs it with the JIT,
+then runs <strong>llvm-prof</strong> to format a report. To get more information about
+<em class="file">utils/profile.pl</em>, execute it with the <strong>-help</strong> option.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="annotated_llvm_or_a" class="item"><strong>--annotated-llvm</strong> or <strong>-A</strong></a></strong></dt>
+
+<dd>
+<p>In addition to the normal report printed, print out the code for the
+program, annotated with execution frequency information. This can be
+particularly useful when trying to visualize how frequently basic blocks
+are executed. This is most useful with basic block profiling
+information or better.</p>
+</dd>
+<dt><strong><a name="print_all_code" class="item"><strong>--print-all-code</strong></a></strong></dt>
+
+<dd>
+<p>Using this option enables the <strong>--annotated-llvm</strong> option, but it
+prints the entire module, instead of just the most commonly executed
+functions.</p>
+</dd>
+<dt><strong><a name="time_passes" class="item"><strong>--time-passes</strong></a></strong></dt>
+
+<dd>
+<p>Record the amount of time needed for each pass and print it to standard
+error.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p><strong>llvm-prof</strong> returns 1 if it cannot load the bitcode file or the profile
+information. Otherwise, it exits with zero.</p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p><strong>llvm-prof</strong> is maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ranlib.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ranlib.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ranlib.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-ranlib.html Tue May 22 14:32:29 2012
@@ -0,0 +1,97 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-ranlib</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#see_also">SEE ALSO</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-ranlib - Generate index for LLVM archive</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-ranlib</strong> [--version] [-help] <archive-file></p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-ranlib</strong> command is similar to the common Unix utility, <code>ranlib</code>. It
+adds or updates the symbol table in an LLVM archive file. Note that using the
+<strong>llvm-ar</strong> modifier <em class="file">s</em> is usually more efficient than running <strong>llvm-ranlib</strong>
+which is only provided only for completness and compatibility. Unlike other
+implementations of <code>ranlib</code>, <strong>llvm-ranlib</strong> indexes LLVM bitcode files, not
+native object modules. You can list the contents of the symbol table with the
+<code>llvm-nm -s</code> command.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="archive_file" class="item"><em class="file">archive-file</em></a></strong></dt>
+
+<dd>
+<p>Specifies the archive-file to which the symbol table is added or updated.</p>
+</dd>
+<dt><strong><a name="version" class="item"><em class="file">--version</em></a></strong></dt>
+
+<dd>
+<p>Print the version of <strong>llvm-ranlib</strong> and exit without building a symbol table.</p>
+</dd>
+<dt><strong><a name="help" class="item"><em class="file">-help</em></a></strong></dt>
+
+<dd>
+<p>Print usage help for <strong>llvm-ranlib</strong> and exit without building a symbol table.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>llvm-ranlib</strong> succeeds, it will exit with 0. If an error occurs, a non-zero
+exit code will be returned.</p>
+<p>
+</p>
+<hr />
+<h1><a name="see_also">SEE ALSO</a></h1>
+<p><a href="././llvm-ar.html">llvm-ar</a>, <code>ranlib(1)</code></p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/llvm-stress.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/llvm-stress.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/llvm-stress.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/llvm-stress.html Tue May 22 14:32:29 2012
@@ -0,0 +1,85 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>llvm-stress</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#author">AUTHOR</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>llvm-stress - generate random .ll files</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>llvm-cov</strong> [-gcno=filename] [-gcda=filename] [dump]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>llvm-stress</strong> tool is used to generate random .ll files that can be used to
+test different components of LLVM.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em>filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output filename.</p>
+</dd>
+<dt><strong><a name="size_size" class="item"><strong>-size</strong> <em>size</em></a></strong></dt>
+
+<dd>
+<p>Specify the size of the generated .ll file.</p>
+</dd>
+<dt><strong><a name="seed_seed" class="item"><strong>-seed</strong> <em>seed</em></a></strong></dt>
+
+<dd>
+<p>Specify the seed to be used for the randomly generated instructions.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p><strong>llvm-stress</strong> returns 0.</p>
+<p>
+</p>
+<hr />
+<h1><a name="author">AUTHOR</a></h1>
+<p><strong>llvm-stress</strong> is maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/manpage.css
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/manpage.css?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/manpage.css (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/manpage.css Tue May 22 14:32:29 2012
@@ -0,0 +1,256 @@
+/* Based on http://www.perldoc.com/css/perldoc.css */
+
+ at import url("../llvm.css");
+
+body { font-family: Arial,Helvetica; }
+
+blockquote { margin: 10pt; }
+
+h1, a { color: #336699; }
+
+
+/*** Top menu style ****/
+.mmenuon {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ff6600; font-size: 10pt;
+ }
+.mmenuoff {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ffffff; font-size: 10pt;
+}
+.cpyright {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ffffff; font-size: xx-small;
+}
+.cpyrightText {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ffffff; font-size: xx-small;
+}
+.sections {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 11pt;
+}
+.dsections {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 12pt;
+}
+.slink {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #000000; font-size: 9pt;
+}
+
+.slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }
+
+.maintitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 18pt;
+}
+.dblArrow {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: small;
+}
+.menuSec {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: small;
+}
+
+.newstext {
+ font-family: Arial,Helvetica; font-size: small;
+}
+
+.linkmenu {
+ font-family: Arial,Helvetica; color: #000000; font-weight: bold;
+ text-decoration: none;
+}
+
+P {
+ font-family: Arial,Helvetica;
+}
+
+PRE {
+ font-size: 10pt;
+}
+.quote {
+ font-family: Times; text-decoration: none;
+ color: #000000; font-size: 9pt; font-style: italic;
+}
+.smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; }
+.std { font-family: Arial,Helvetica; color: #000000; }
+.meerkatTitle {
+ font-family: sans-serif; font-size: x-small; color: black; }
+
+.meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
+.meerkatCategory {
+ font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic;
+ color: brown; }
+.meerkatChannel {
+ font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
+.meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
+
+.tocTitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #333333; font-size: 10pt;
+}
+
+.toc-item {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #336699; font-size: 10pt; text-decoration: underline;
+}
+
+.perlVersion {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #336699; font-size: 10pt; text-decoration: none;
+}
+
+.podTitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #000000;
+}
+
+.docTitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #000000; font-size: 10pt;
+}
+.dotDot {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #000000; font-size: 9pt;
+}
+
+.docSec {
+ font-family: Arial,Helvetica; font-weight: normal;
+ color: #333333; font-size: 9pt;
+}
+.docVersion {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 10pt;
+}
+
+.docSecs-on {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #ff0000; font-size: 10pt;
+}
+.docSecs-off {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #333333; font-size: 10pt;
+}
+
+h2 {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: medium;
+}
+h1 {
+ font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: large;
+}
+
+DL {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #333333; font-size: 10pt;
+}
+
+UL > LI > A {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #336699; font-size: 10pt;
+}
+
+.moduleInfo {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #333333; font-size: 11pt;
+}
+
+.moduleInfoSec {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 10pt;
+}
+
+.moduleInfoVal {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
+ color: #000000; font-size: 10pt;
+}
+
+.cpanNavTitle {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #ffffff; font-size: 10pt;
+}
+.cpanNavLetter {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #333333; font-size: 9pt;
+}
+.cpanCat {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 9pt;
+}
+
+.bttndrkblue-bkgd-top {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
+}
+.bttndrkblue-bkgd-left {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
+}
+.bttndrkblue-bkgd {
+ padding-top: 0px;
+ padding-bottom: 0px;
+ margin-bottom: 0px;
+ margin-top: 0px;
+ background-repeat: no-repeat;
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
+ vertical-align: top;
+}
+.bttndrkblue-bkgd-right {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
+}
+.bttndrkblue-bkgd-bottom {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
+}
+.bttndrkblue-text a {
+ color: #ffffff;
+ text-decoration: none;
+}
+a.bttndrkblue-text:hover {
+ color: #ffDD3C;
+ text-decoration: none;
+}
+.bg-ltblue {
+ background-color: #f0f5fa;
+}
+
+.border-left-b {
+ background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
+}
+
+.border-right-b {
+ background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
+}
+
+.border-top-b {
+ background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
+}
+
+.border-bottom-b {
+ background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
+}
+
+.border-right-w {
+ background: #ffffff url(/i/corner-rightline.gif) repeat-y;
+}
+
+.border-top-w {
+ background: #ffffff url(/i/corner-topline.gif) repeat-x;
+}
+
+.border-bottom-w {
+ background: #ffffff url(/i/corner-botline.gif) repeat-x;
+}
+
+.bg-white {
+ background-color: #ffffff;
+}
+
+.border-left-w {
+ background: #ffffff url(/i/corner-leftline.gif) repeat-y;
+}
Added: www-releases/trunk/3.1/docs/CommandGuide/html/opt.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/opt.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/opt.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/opt.html Tue May 22 14:32:29 2012
@@ -0,0 +1,195 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>opt</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>opt - LLVM optimizer</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>opt</strong> [<em>options</em>] [<em>filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p>The <strong>opt</strong> command is the modular LLVM optimizer and analyzer. It takes LLVM
+source files as input, runs the specified optimizations or analyses on it, and then
+outputs the optimized file or the analysis results. The function of
+<strong>opt</strong> depends on whether the <strong>-analyze</strong> option is given.</p>
+<p>When <strong>-analyze</strong> is specified, <strong>opt</strong> performs various analyses of the input
+source. It will usually print the results on standard output, but in a few
+cases, it will print output to standard error or generate a file with the
+analysis output, which is usually done when the output is meant for another
+program.</p>
+<p>While <strong>-analyze</strong> is <em>not</em> given, <strong>opt</strong> attempts to produce an optimized
+output file. The optimizations available via <strong>opt</strong> depend upon what
+libraries were linked into it as well as any additional libraries that have
+been loaded with the <strong>-load</strong> option. Use the <strong>-help</strong> option to determine
+what optimizations you can use.</p>
+<p>If <em>filename</em> is omitted from the command line or is <em>-</em>, <strong>opt</strong> reads its
+input from standard input. Inputs can be in either the LLVM assembly language
+format (.ll) or the LLVM bitcode format (.bc).</p>
+<p>If an output filename is not specified with the <strong>-o</strong> option, <strong>opt</strong>
+writes its output to the standard output.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="f" class="item"><strong>-f</strong></a></strong></dt>
+
+<dd>
+<p>Enable binary output on terminals. Normally, <strong>opt</strong> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+<strong>opt</strong> will write raw bitcode regardless of the output device.</p>
+</dd>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em>filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output filename.</p>
+</dd>
+<dt><strong><a name="s" class="item"><strong>-S</strong></a></strong></dt>
+
+<dd>
+<p>Write output in LLVM intermediate language (instead of bitcode).</p>
+</dd>
+<dt><strong><a name="passname" class="item"><strong>-{passname}</strong></a></strong></dt>
+
+<dd>
+<p><strong>opt</strong> provides the ability to run any of LLVM's optimization or analysis passes
+in any order. The <strong>-help</strong> option lists all the passes available. The order in
+which the options occur on the command line are the order in which they are
+executed (within pass constraints).</p>
+</dd>
+<dt><strong><a name="std_compile_opts" class="item"><strong>-std-compile-opts</strong></a></strong></dt>
+
+<dd>
+<p>This is short hand for a standard list of <em>compile time optimization</em> passes.
+This is typically used to optimize the output from the llvm-gcc front end. It
+might be useful for other front end compilers as well. To discover the full set
+of options available, use the following command:</p>
+<pre>
+ llvm-as < /dev/null | opt -std-compile-opts -disable-output -debug-pass=Arguments</pre>
+</dd>
+<dt><strong><a name="disable_inlining" class="item"><strong>-disable-inlining</strong></a></strong></dt>
+
+<dd>
+<p>This option is only meaningful when <strong>-std-compile-opts</strong> is given. It simply
+removes the inlining pass from the standard list.</p>
+</dd>
+<dt><strong><a name="disable_opt" class="item"><strong>-disable-opt</strong></a></strong></dt>
+
+<dd>
+<p>This option is only meaningful when <strong>-std-compile-opts</strong> is given. It disables
+most, but not all, of the <strong>-std-compile-opts</strong>. The ones that remain are
+<strong>-verify</strong>, <strong>-lower-setjmp</strong>, and <strong>-funcresolve</strong>.</p>
+</dd>
+<dt><strong><a name="strip_debug" class="item"><strong>-strip-debug</strong></a></strong></dt>
+
+<dd>
+<p>This option causes opt to strip debug information from the module before
+applying other optimizations. It is essentially the same as <strong>-strip</strong> but it
+ensures that stripping of debug information is done first.</p>
+</dd>
+<dt><strong><a name="verify_each" class="item"><strong>-verify-each</strong></a></strong></dt>
+
+<dd>
+<p>This option causes opt to add a verify pass after every pass otherwise specified
+on the command line (including <strong>-verify</strong>). This is useful for cases where it
+is suspected that a pass is creating an invalid module but it is not clear which
+pass is doing it. The combination of <strong>-std-compile-opts</strong> and <strong>-verify-each</strong>
+can quickly track down this kind of problem.</p>
+</dd>
+<dt><strong><a name="profile_info_file_filename" class="item"><strong>-profile-info-file</strong> <em>filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the name of the file loaded by the -profile-loader option.</p>
+</dd>
+<dt><strong><a name="stats" class="item"><strong>-stats</strong></a></strong></dt>
+
+<dd>
+<p>Print statistics.</p>
+</dd>
+<dt><strong><a name="time_passes" class="item"><strong>-time-passes</strong></a></strong></dt>
+
+<dd>
+<p>Record the amount of time needed for each pass and print it to standard
+error.</p>
+</dd>
+<dt><strong><a name="debug" class="item"><strong>-debug</strong></a></strong></dt>
+
+<dd>
+<p>If this is a debug build, this option will enable debug printouts
+from passes which use the <em>DEBUG()</em> macro. See the <strong>LLVM Programmer's
+Manual</strong>, section <em>#DEBUG</em> for more information.</p>
+</dd>
+<dt><strong><a name="load_plugin" class="item"><strong>-load</strong>=<em>plugin</em></a></strong></dt>
+
+<dd>
+<p>Load the dynamic object <em>plugin</em>. This object should register new optimization
+or analysis passes. Once loaded, the object will add new command line options to
+enable various optimizations or analyses. To see the new complete list of
+optimizations, use the <strong>-help</strong> and <strong>-load</strong> options together. For example:</p>
+<pre>
+ opt -load=plugin.so -help</pre>
+</dd>
+<dt><strong><a name="p" class="item"><strong>-p</strong></a></strong></dt>
+
+<dd>
+<p>Print module after each transformation.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>opt</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by the LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/html/tblgen.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/html/tblgen.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/html/tblgen.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/html/tblgen.html Tue May 22 14:32:29 2012
@@ -0,0 +1,200 @@
+<?xml version="1.0" ?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>tblgen</title>
+<link rel="stylesheet" href="manpage.css" type="text/css" />
+<meta http-equiv="content-type" content="text/html; charset=utf-8" />
+<link rev="made" href="mailto:root at localhost" />
+</head>
+
+<body>
+
+
+<!-- INDEX BEGIN -->
+<div name="index">
+<p><a name="__index__"></a></p>
+<!--
+
+<ul>
+
+ <li><a href="#name">NAME</a></li>
+ <li><a href="#synopsis">SYNOPSIS</a></li>
+ <li><a href="#description">DESCRIPTION</a></li>
+ <li><a href="#options">OPTIONS</a></li>
+ <li><a href="#exit_status">EXIT STATUS</a></li>
+ <li><a href="#authors">AUTHORS</a></li>
+</ul>
+
+-->
+
+
+</div>
+<!-- INDEX END -->
+
+<p>
+</p>
+<hr />
+<h1><a name="name">NAME</a></h1>
+<p>tblgen - Target Description To C++ Code Generator</p>
+<p>
+</p>
+<hr />
+<h1><a name="synopsis">SYNOPSIS</a></h1>
+<p><strong>tblgen</strong> [<em>options</em>] [<em>filename</em>]</p>
+<p>
+</p>
+<hr />
+<h1><a name="description">DESCRIPTION</a></h1>
+<p><strong>tblgen</strong> translates from target description (.td) files into C++ code that can
+be included in the definition of an LLVM target library. Most users of LLVM will
+not need to use this program. It is only for assisting with writing an LLVM
+target backend.</p>
+<p>The input and output of <strong>tblgen</strong> is beyond the scope of this short
+introduction. Please see the <em>CodeGeneration</em> page in the LLVM documentation.</p>
+<p>The <em class="file">filename</em> argument specifies the name of a Target Description (.td) file
+to read as input.</p>
+<p>
+</p>
+<hr />
+<h1><a name="options">OPTIONS</a></h1>
+<dl>
+<dt><strong><a name="help" class="item"><strong>-help</strong></a></strong></dt>
+
+<dd>
+<p>Print a summary of command line options.</p>
+</dd>
+<dt><strong><a name="o_filename" class="item"><strong>-o</strong> <em class="file">filename</em></a></strong></dt>
+
+<dd>
+<p>Specify the output file name. If <em class="file">filename</em> is <code>-</code>, then <strong>tblgen</strong>
+sends its output to standard output.</p>
+</dd>
+<dt><strong><a name="i_directory" class="item"><strong>-I</strong> <em class="file">directory</em></a></strong></dt>
+
+<dd>
+<p>Specify where to find other target description files for inclusion. The
+<em class="file">directory</em> value should be a full or partial path to a directory that contains
+target description files.</p>
+</dd>
+<dt><strong><a name="asmparsernum_n" class="item"><strong>-asmparsernum</strong> <em class="file">N</em></a></strong></dt>
+
+<dd>
+<p>Make -gen-asm-parser emit assembly writer number <em class="file">N</em>.</p>
+</dd>
+<dt><strong><a name="asmwriternum_n" class="item"><strong>-asmwriternum</strong> <em class="file">N</em></a></strong></dt>
+
+<dd>
+<p>Make -gen-asm-writer emit assembly writer number <em class="file">N</em>.</p>
+</dd>
+<dt><strong><a name="class_class_name" class="item"><strong>-class</strong> <em class="file">class Name</em></a></strong></dt>
+
+<dd>
+<p>Print the enumeration list for this class.</p>
+</dd>
+<dt><strong><a name="print_records" class="item"><strong>-print-records</strong></a></strong></dt>
+
+<dd>
+<p>Print all records to standard output (default).</p>
+</dd>
+<dt><strong><a name="print_enums" class="item"><strong>-print-enums</strong></a></strong></dt>
+
+<dd>
+<p>Print enumeration values for a class</p>
+</dd>
+<dt><strong><a name="print_sets" class="item"><strong>-print-sets</strong></a></strong></dt>
+
+<dd>
+<p>Print expanded sets for testing DAG exprs.</p>
+</dd>
+<dt><strong><a name="gen_emitter" class="item"><strong>-gen-emitter</strong></a></strong></dt>
+
+<dd>
+<p>Generate machine code emitter.</p>
+</dd>
+<dt><strong><a name="gen_register_info" class="item"><strong>-gen-register-info</strong></a></strong></dt>
+
+<dd>
+<p>Generate registers and register classes info.</p>
+</dd>
+<dt><strong><a name="gen_instr_info" class="item"><strong>-gen-instr-info</strong></a></strong></dt>
+
+<dd>
+<p>Generate instruction descriptions.</p>
+</dd>
+<dt><strong><a name="gen_asm_writer" class="item"><strong>-gen-asm-writer</strong></a></strong></dt>
+
+<dd>
+<p>Generate the assembly writer.</p>
+</dd>
+<dt><strong><a name="gen_disassembler" class="item"><strong>-gen-disassembler</strong></a></strong></dt>
+
+<dd>
+<p>Generate disassembler.</p>
+</dd>
+<dt><strong><a name="gen_pseudo_lowering" class="item"><strong>-gen-pseudo-lowering</strong></a></strong></dt>
+
+<dd>
+<p>Generate pseudo instruction lowering.</p>
+</dd>
+<dt><strong><a name="gen_dag_isel" class="item"><strong>-gen-dag-isel</strong></a></strong></dt>
+
+<dd>
+<p>Generate a DAG (Directed Acycle Graph) instruction selector.</p>
+</dd>
+<dt><strong><a name="gen_asm_matcher" class="item"><strong>-gen-asm-matcher</strong></a></strong></dt>
+
+<dd>
+<p>Generate assembly instruction matcher.</p>
+</dd>
+<dt><strong><a name="gen_dfa_packetizer" class="item"><strong>-gen-dfa-packetizer</strong></a></strong></dt>
+
+<dd>
+<p>Generate DFA Packetizer for VLIW targets.</p>
+</dd>
+<dt><strong><a name="gen_fast_isel" class="item"><strong>-gen-fast-isel</strong></a></strong></dt>
+
+<dd>
+<p>Generate a "fast" instruction selector.</p>
+</dd>
+<dt><strong><a name="gen_subtarget" class="item"><strong>-gen-subtarget</strong></a></strong></dt>
+
+<dd>
+<p>Generate subtarget enumerations.</p>
+</dd>
+<dt><strong><a name="gen_intrinsic" class="item"><strong>-gen-intrinsic</strong></a></strong></dt>
+
+<dd>
+<p>Generate intrinsic information.</p>
+</dd>
+<dt><strong><a name="gen_tgt_intrinsic" class="item"><strong>-gen-tgt-intrinsic</strong></a></strong></dt>
+
+<dd>
+<p>Generate target intrinsic information.</p>
+</dd>
+<dt><strong><a name="gen_enhanced_disassembly_info" class="item"><strong>-gen-enhanced-disassembly-info</strong></a></strong></dt>
+
+<dd>
+<p>Generate enhanced disassembly info.</p>
+</dd>
+<dt><strong><a name="version" class="item"><strong>-version</strong></a></strong></dt>
+
+<dd>
+<p>Show the version number of this program.</p>
+</dd>
+</dl>
+<p>
+</p>
+<hr />
+<h1><a name="exit_status">EXIT STATUS</a></h1>
+<p>If <strong>tblgen</strong> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.</p>
+<p>
+</p>
+<hr />
+<h1><a name="authors">AUTHORS</a></h1>
+<p>Maintained by The LLVM Team (<a href="http://llvm.org/">http://llvm.org/</a>).</p>
+
+</body>
+
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/index.html
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/index.html?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/index.html (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/index.html Tue May 22 14:32:29 2012
@@ -0,0 +1,142 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+<head>
+ <title>LLVM Command Guide</title>
+ <link rel="stylesheet" href="../llvm.css" type="text/css">
+</head>
+<body>
+
+<h1>
+ LLVM Command Guide
+</h1>
+
+<div>
+
+<p>These documents are HTML versions of the <a href="man/man1/">man pages</a>
+for all of the LLVM tools. These pages describe how to use the LLVM commands
+and what their options are. Note that these pages do not describe all of the
+options available for all tools. To get a complete listing, pass the
+<tt>-help</tt> (general options) or <tt>-help-hidden</tt> (general+debugging
+options) arguments to the tool you are interested in.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="basic">Basic Commands</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+
+<ul>
+
+<li><a href="/cmds/llvm-as.html"><b>llvm-as</b></a> -
+ assemble a human-readable .ll file into bytecode</li>
+
+<li><a href="/cmds/llvm-dis.html"><b>llvm-dis</b></a> -
+ disassemble a bytecode file into a human-readable .ll file</li>
+
+<li><a href="/cmds/opt.html"><b>opt</b></a> -
+ run a series of LLVM-to-LLVM optimizations on a bytecode file</li>
+
+<li><a href="/cmds/llc.html"><b>llc</b></a> -
+ generate native machine code for a bytecode file</li>
+
+<li><a href="/cmds/lli.html"><b>lli</b></a> -
+ directly run a program compiled to bytecode using a JIT compiler or
+ interpreter</li>
+
+<li><a href="/cmds/llvm-link.html"><b>llvm-link</b></a> -
+ link several bytecode files into one</li>
+
+<li><a href="/cmds/llvm-ar.html"><b>llvm-ar</b></a> -
+ archive bytecode files</li>
+
+<li><a href="/cmds/llvm-ranlib.html"><b>llvm-ranlib</b></a> -
+ create an index for archives made with llvm-ar</li>
+
+<li><a href="/cmds/llvm-nm.html"><b>llvm-nm</b></a> -
+ print out the names and types of symbols in a bytecode file</li>
+
+<li><a href="/cmds/llvm-prof.html"><b>llvm-prof</b></a> -
+ format raw `<tt>llvmprof.out</tt>' data into a human-readable report</li>
+
+<li><a href="/cmds/llvm-ld.html"><b>llvm-ld</b></a> -
+ general purpose linker with loadable runtime optimization support</li>
+
+<li><a href="/cmds/llvm-config.html"><b>llvm-config</b></a> -
+ print out LLVM compilation options, libraries, etc. as configured</li>
+
+<li><a href="/cmds/llvm-diff.html"><b>llvm-diff</b></a> -
+ structurally compare two modules</li>
+
+<li><a href="/cmds/llvm-cov.html"><b>llvm-cov</b></a> -
+ emit coverage information</li>
+
+<li><a href="/cmds/llvm-stress.html"><b>llvm-stress</b></a> -
+ generate random .ll files to fuzz different llvm components</li>
+
+</ul>
+
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="debug">Debugging Tools</a>
+</h2>
+<!-- *********************************************************************** -->
+
+
+<div>
+
+<ul>
+
+<li><a href="/cmds/bugpoint.html"><b>bugpoint</b></a> -
+ automatic test-case reducer</li>
+
+<li><a href="/cmds/llvm-extract.html"><b>llvm-extract</b></a> -
+ extract a function from an LLVM bytecode file</li>
+
+<li><a href="/cmds/llvm-bcanalyzer.html"><b>llvm-bcanalyzer</b></a> -
+ bytecode analyzer (analyzes the binary encoding itself, not the program it
+ represents)</li>
+
+</ul>
+</div>
+
+<!-- *********************************************************************** -->
+<h2>
+ <a name="internal">Internal Tools</a>
+</h2>
+<!-- *********************************************************************** -->
+
+<div>
+<ul>
+
+<li><a href="/cmds/FileCheck.html"><b>FileCheck</b></a> -
+ Flexible file verifier used extensively by the testing harness</li>
+<li><a href="/cmds/tblgen.html"><b>tblgen</b></a> -
+ target description reader and generator</li>
+<li><a href="/cmds/lit.html"><b>lit</b></a> -
+ LLVM Integrated Tester, for running tests</li>
+
+</ul>
+</div>
+
+<!-- *********************************************************************** -->
+
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
+
+ <a href="http://llvm.org/">LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2012-02-26 00:35:53 -0800 (Sun, 26 Feb 2012) $
+</address>
+
+</body>
+</html>
Added: www-releases/trunk/3.1/docs/CommandGuide/lit.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/lit.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/lit.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/lit.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,404 @@
+=pod
+
+=head1 NAME
+
+lit - LLVM Integrated Tester
+
+=head1 SYNOPSIS
+
+B<lit> [I<options>] [I<tests>]
+
+=head1 DESCRIPTION
+
+B<lit> is a portable tool for executing LLVM and Clang style test suites,
+summarizing their results, and providing indication of failures. B<lit> is
+designed to be a lightweight testing tool with as simple a user interface as
+possible.
+
+B<lit> should be run with one or more I<tests> to run specified on the command
+line. Tests can be either individual test files or directories to search for
+tests (see L<"TEST DISCOVERY">).
+
+Each specified test will be executed (potentially in parallel) and once all
+tests have been run B<lit> will print summary information on the number of tests
+which passed or failed (see L<"TEST STATUS RESULTS">). The B<lit> program will
+execute with a non-zero exit code if any tests fail.
+
+By default B<lit> will use a succinct progress display and will only print
+summary information for test failures. See L<"OUTPUT OPTIONS"> for options
+controlling the B<lit> progress display and output.
+
+B<lit> also includes a number of options for controlling how tests are executed
+(specific features may depend on the particular test format). See L<"EXECUTION
+OPTIONS"> for more information.
+
+Finally, B<lit> also supports additional options for only running a subset of
+the options specified on the command line, see L<"SELECTION OPTIONS"> for
+more information.
+
+Users interested in the B<lit> architecture or designing a B<lit> testing
+implementation should see L<"LIT INFRASTRUCTURE">
+
+=head1 GENERAL OPTIONS
+
+=over
+
+=item B<-h>, B<--help>
+
+Show the B<lit> help message.
+
+=item B<-j> I<N>, B<--threads>=I<N>
+
+Run I<N> tests in parallel. By default, this is automatically chosen to match
+the number of detected available CPUs.
+
+=item B<--config-prefix>=I<NAME>
+
+Search for I<NAME.cfg> and I<NAME.site.cfg> when searching for test suites,
+instead of I<lit.cfg> and I<lit.site.cfg>.
+
+=item B<--param> I<NAME>, B<--param> I<NAME>=I<VALUE>
+
+Add a user defined parameter I<NAME> with the given I<VALUE> (or the empty
+string if not given). The meaning and use of these parameters is test suite
+dependent.
+
+=back
+
+=head1 OUTPUT OPTIONS
+
+=over
+
+=item B<-q>, B<--quiet>
+
+Suppress any output except for test failures.
+
+=item B<-s>, B<--succinct>
+
+Show less output, for example don't show information on tests that pass.
+
+=item B<-v>, B<--verbose>
+
+Show more information on test failures, for example the entire test output
+instead of just the test result.
+
+=item B<--no-progress-bar>
+
+Do not use curses based progress bar.
+
+=back
+
+=head1 EXECUTION OPTIONS
+
+=over
+
+=item B<--path>=I<PATH>
+
+Specify an addition I<PATH> to use when searching for executables in tests.
+
+=item B<--vg>
+
+Run individual tests under valgrind (using the memcheck tool). The
+I<--error-exitcode> argument for valgrind is used so that valgrind failures will
+cause the program to exit with a non-zero status.
+
+=item B<--vg-arg>=I<ARG>
+
+When I<--vg> is used, specify an additional argument to pass to valgrind itself.
+
+=item B<--time-tests>
+
+Track the wall time individual tests take to execute and includes the results in
+the summary output. This is useful for determining which tests in a test suite
+take the most time to execute. Note that this option is most useful with I<-j
+1>.
+
+=back
+
+=head1 SELECTION OPTIONS
+
+=over
+
+=item B<--max-tests>=I<N>
+
+Run at most I<N> tests and then terminate.
+
+=item B<--max-time>=I<N>
+
+Spend at most I<N> seconds (approximately) running tests and then terminate.
+
+=item B<--shuffle>
+
+Run the tests in a random order.
+
+=back
+
+=head1 ADDITIONAL OPTIONS
+
+=over
+
+=item B<--debug>
+
+Run B<lit> in debug mode, for debugging configuration issues and B<lit> itself.
+
+=item B<--show-suites>
+
+List the discovered test suites as part of the standard output.
+
+=item B<--no-tcl-as-sh>
+
+Run Tcl scripts internally (instead of converting to shell scripts).
+
+=item B<--repeat>=I<N>
+
+Run each test I<N> times. Currently this is primarily useful for timing tests,
+other results are not collated in any reasonable fashion.
+
+=back
+
+=head1 EXIT STATUS
+
+B<lit> will exit with an exit code of 1 if there are any FAIL or XPASS
+results. Otherwise, it will exit with the status 0. Other exit codes are used
+for non-test related failures (for example a user error or an internal program
+error).
+
+=head1 TEST DISCOVERY
+
+The inputs passed to B<lit> can be either individual tests, or entire
+directories or hierarchies of tests to run. When B<lit> starts up, the first
+thing it does is convert the inputs into a complete list of tests to run as part
+of I<test discovery>.
+
+In the B<lit> model, every test must exist inside some I<test suite>. B<lit>
+resolves the inputs specified on the command line to test suites by searching
+upwards from the input path until it finds a I<lit.cfg> or I<lit.site.cfg>
+file. These files serve as both a marker of test suites and as configuration
+files which B<lit> loads in order to understand how to find and run the tests
+inside the test suite.
+
+Once B<lit> has mapped the inputs into test suites it traverses the list of
+inputs adding tests for individual files and recursively searching for tests in
+directories.
+
+This behavior makes it easy to specify a subset of tests to run, while still
+allowing the test suite configuration to control exactly how tests are
+interpreted. In addition, B<lit> always identifies tests by the test suite they
+are in, and their relative path inside the test suite. For appropriately
+configured projects, this allows B<lit> to provide convenient and flexible
+support for out-of-tree builds.
+
+=head1 TEST STATUS RESULTS
+
+Each test ultimately produces one of the following six results:
+
+=over
+
+=item B<PASS>
+
+The test succeeded.
+
+=item B<XFAIL>
+
+The test failed, but that is expected. This is used for test formats which allow
+specifying that a test does not currently work, but wish to leave it in the test
+suite.
+
+=item B<XPASS>
+
+The test succeeded, but it was expected to fail. This is used for tests which
+were specified as expected to fail, but are now succeeding (generally because
+the feature they test was broken and has been fixed).
+
+=item B<FAIL>
+
+The test failed.
+
+=item B<UNRESOLVED>
+
+The test result could not be determined. For example, this occurs when the test
+could not be run, the test itself is invalid, or the test was interrupted.
+
+=item B<UNSUPPORTED>
+
+The test is not supported in this environment. This is used by test formats
+which can report unsupported tests.
+
+=back
+
+Depending on the test format tests may produce additional information about
+their status (generally only for failures). See the L<Output|"OUTPUT OPTIONS">
+section for more information.
+
+=head1 LIT INFRASTRUCTURE
+
+This section describes the B<lit> testing architecture for users interested in
+creating a new B<lit> testing implementation, or extending an existing one.
+
+B<lit> proper is primarily an infrastructure for discovering and running
+arbitrary tests, and to expose a single convenient interface to these
+tests. B<lit> itself doesn't know how to run tests, rather this logic is
+defined by I<test suites>.
+
+=head2 TEST SUITES
+
+As described in L<"TEST DISCOVERY">, tests are always located inside a I<test
+suite>. Test suites serve to define the format of the tests they contain, the
+logic for finding those tests, and any additional information to run the tests.
+
+B<lit> identifies test suites as directories containing I<lit.cfg> or
+I<lit.site.cfg> files (see also B<--config-prefix>). Test suites are initially
+discovered by recursively searching up the directory hierarchy for all the input
+files passed on the command line. You can use B<--show-suites> to display the
+discovered test suites at startup.
+
+Once a test suite is discovered, its config file is loaded. Config files
+themselves are Python modules which will be executed. When the config file is
+executed, two important global variables are predefined:
+
+=over
+
+=item B<lit>
+
+The global B<lit> configuration object (a I<LitConfig> instance), which defines
+the builtin test formats, global configuration parameters, and other helper
+routines for implementing test configurations.
+
+=item B<config>
+
+This is the config object (a I<TestingConfig> instance) for the test suite,
+which the config file is expected to populate. The following variables are also
+available on the I<config> object, some of which must be set by the config and
+others are optional or predefined:
+
+B<name> I<[required]> The name of the test suite, for use in reports and
+diagnostics.
+
+B<test_format> I<[required]> The test format object which will be used to
+discover and run tests in the test suite. Generally this will be a builtin test
+format available from the I<lit.formats> module.
+
+B<test_src_root> The filesystem path to the test suite root. For out-of-dir
+builds this is the directory that will be scanned for tests.
+
+B<test_exec_root> For out-of-dir builds, the path to the test suite root inside
+the object directory. This is where tests will be run and temporary output files
+placed.
+
+B<environment> A dictionary representing the environment to use when executing
+tests in the suite.
+
+B<suffixes> For B<lit> test formats which scan directories for tests, this
+variable is a list of suffixes to identify test files. Used by: I<ShTest>,
+I<TclTest>.
+
+B<substitutions> For B<lit> test formats which substitute variables into a test
+script, the list of substitutions to perform. Used by: I<ShTest>, I<TclTest>.
+
+B<unsupported> Mark an unsupported directory, all tests within it will be
+reported as unsupported. Used by: I<ShTest>, I<TclTest>.
+
+B<parent> The parent configuration, this is the config object for the directory
+containing the test suite, or None.
+
+B<root> The root configuration. This is the top-most B<lit> configuration in
+the project.
+
+B<on_clone> The config is actually cloned for every subdirectory inside a test
+suite, to allow local configuration on a per-directory basis. The I<on_clone>
+variable can be set to a Python function which will be called whenever a
+configuration is cloned (for a subdirectory). The function should takes three
+arguments: (1) the parent configuration, (2) the new configuration (which the
+I<on_clone> function will generally modify), and (3) the test path to the new
+directory being scanned.
+
+=back
+
+=head2 TEST DISCOVERY
+
+Once test suites are located, B<lit> recursively traverses the source directory
+(following I<test_src_root>) looking for tests. When B<lit> enters a
+sub-directory, it first checks to see if a nested test suite is defined in that
+directory. If so, it loads that test suite recursively, otherwise it
+instantiates a local test config for the directory (see L<"LOCAL CONFIGURATION
+FILES">).
+
+Tests are identified by the test suite they are contained within, and the
+relative path inside that suite. Note that the relative path may not refer to an
+actual file on disk; some test formats (such as I<GoogleTest>) define "virtual
+tests" which have a path that contains both the path to the actual test file and
+a subpath to identify the virtual test.
+
+=head2 LOCAL CONFIGURATION FILES
+
+When B<lit> loads a subdirectory in a test suite, it instantiates a local test
+configuration by cloning the configuration for the parent direction -- the root
+of this configuration chain will always be a test suite. Once the test
+configuration is cloned B<lit> checks for a I<lit.local.cfg> file in the
+subdirectory. If present, this file will be loaded and can be used to specialize
+the configuration for each individual directory. This facility can be used to
+define subdirectories of optional tests, or to change other configuration
+parameters -- for example, to change the test format, or the suffixes which
+identify test files.
+
+=head2 TEST RUN OUTPUT FORMAT
+
+The b<lit> output for a test run conforms to the following schema, in both short
+and verbose modes (although in short mode no PASS lines will be shown). This
+schema has been chosen to be relatively easy to reliably parse by a machine (for
+example in buildbot log scraping), and for other tools to generate.
+
+Each test result is expected to appear on a line that matches:
+
+<result code>: <test name> (<progress info>)
+
+where <result-code> is a standard test result such as PASS, FAIL, XFAIL, XPASS,
+UNRESOLVED, or UNSUPPORTED. The performance result codes of IMPROVED and
+REGRESSED are also allowed.
+
+The <test name> field can consist of an arbitrary string containing no newline.
+
+The <progress info> field can be used to report progress information such as
+(1/300) or can be empty, but even when empty the parentheses are required.
+
+Each test result may include additional (multiline) log information in the
+following format.
+
+<log delineator> TEST '(<test name>)' <trailing delineator>
+... log message ...
+<log delineator>
+
+where <test name> should be the name of a preceeding reported test, <log
+delineator> is a string of '*' characters I<at least> four characters long (the
+recommended length is 20), and <trailing delineator> is an arbitrary (unparsed)
+string.
+
+The following is an example of a test run output which consists of four tests A,
+B, C, and D, and a log message for the failing test C.
+
+=head3 Example Test Run Output Listing
+
+PASS: A (1 of 4)
+PASS: B (2 of 4)
+FAIL: C (3 of 4)
+******************** TEST 'C' FAILED ********************
+Test 'C' failed as a result of exit code 1.
+********************
+PASS: D (4 of 4)
+
+=back
+
+=head2 LIT EXAMPLE TESTS
+
+The B<lit> distribution contains several example implementations of test suites
+in the I<ExampleTests> directory.
+
+=head1 SEE ALSO
+
+L<valgrind(1)>
+
+=head1 AUTHOR
+
+Written by Daniel Dunbar and maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llc.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llc.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llc.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llc.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,201 @@
+=pod
+
+=head1 NAME
+
+llc - LLVM static compiler
+
+=head1 SYNOPSIS
+
+B<llc> [I<options>] [I<filename>]
+
+=head1 DESCRIPTION
+
+The B<llc> command compiles LLVM source inputs into assembly language for a
+specified architecture. The assembly language output can then be passed through
+a native assembler and linker to generate a native executable.
+
+The choice of architecture for the output assembly code is automatically
+determined from the input file, unless the B<-march> option is used to override
+the default.
+
+=head1 OPTIONS
+
+If I<filename> is - or omitted, B<llc> reads from standard input. Otherwise, it
+will from I<filename>. Inputs can be in either the LLVM assembly language
+format (.ll) or the LLVM bitcode format (.bc).
+
+If the B<-o> option is omitted, then B<llc> will send its output to standard
+output if the input is from standard input. If the B<-o> option specifies -,
+then the output will also be sent to standard output.
+
+If no B<-o> option is specified and an input file other than - is specified,
+then B<llc> creates the output filename by taking the input filename,
+removing any existing F<.bc> extension, and adding a F<.s> suffix.
+
+Other B<llc> options are as follows:
+
+=head2 End-user Options
+
+=over
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-O>=I<uint>
+
+Generate code at different optimization levels. These correspond to the I<-O0>,
+I<-O1>, I<-O2>, and I<-O3> optimization levels used by B<llvm-gcc> and
+B<clang>.
+
+=item B<-mtriple>=I<target triple>
+
+Override the target triple specified in the input file with the specified
+string.
+
+=item B<-march>=I<arch>
+
+Specify the architecture for which to generate assembly, overriding the target
+encoded in the input file. See the output of B<llc -help> for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.
+
+=item B<-mcpu>=I<cpuname>
+
+Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+B<llvm-as E<lt> /dev/null | llc -march=xyz -mcpu=help>
+
+=item B<-mattr>=I<a1,+a2,-a3,...>
+
+Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not. The default set of attributes is set by the
+current CPU. For a list of available attributes, use:
+B<llvm-as E<lt> /dev/null | llc -march=xyz -mattr=help>
+
+=item B<--disable-fp-elim>
+
+Disable frame pointer elimination optimization.
+
+=item B<--disable-excess-fp-precision>
+
+Disable optimizations that may produce excess precision for floating point.
+Note that this option can dramatically slow down code on some systems
+(e.g. X86).
+
+=item B<--enable-no-infs-fp-math>
+
+Enable optimizations that assume no Inf values.
+
+=item B<--enable-no-nans-fp-math>
+
+Enable optimizations that assume no NAN values.
+
+=item B<--enable-unsafe-fp-math>
+
+Enable optimizations that make unsafe assumptions about IEEE math (e.g. that
+addition is associative) or may not work for all input ranges. These
+optimizations allow the code generator to make use of some instructions which
+would otherwise not be usable (such as fsin on X86).
+
+=item B<--enable-correct-eh-support>
+
+Instruct the B<lowerinvoke> pass to insert code for correct exception handling
+support. This is expensive and is by default omitted for efficiency.
+
+=item B<--stats>
+
+Print statistics recorded by code-generation passes.
+
+=item B<--time-passes>
+
+Record the amount of time needed for each pass and print a report to standard
+error.
+
+=item B<--load>=F<dso_path>
+
+Dynamically load F<dso_path> (a path to a dynamically shared object) that
+implements an LLVM target. This will permit the target name to be used with the
+B<-march> option so that code can be generated for that target.
+
+=back
+
+=head2 Tuning/Configuration Options
+
+=over
+
+=item B<--print-machineinstrs>
+
+Print generated machine code between compilation phases (useful for debugging).
+
+=item B<--regalloc>=I<allocator>
+
+Specify the register allocator to use. The default I<allocator> is I<local>.
+Valid register allocators are:
+
+=over
+
+=item I<simple>
+
+Very simple "always spill" register allocator
+
+=item I<local>
+
+Local register allocator
+
+=item I<linearscan>
+
+Linear scan global register allocator
+
+=item I<iterativescan>
+
+Iterative scan global register allocator
+
+=back
+
+=item B<--spiller>=I<spiller>
+
+Specify the spiller to use for register allocators that support it. Currently
+this option is used only by the linear scan register allocator. The default
+I<spiller> is I<local>. Valid spillers are:
+
+=over
+
+=item I<simple>
+
+Simple spiller
+
+=item I<local>
+
+Local spiller
+
+=back
+
+=back
+
+=head2 Intel IA-32-specific Options
+
+=over
+
+=item B<--x86-asm-syntax=att|intel>
+
+Specify whether to emit assembly code in AT&T syntax (the default) or intel
+syntax.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llc> succeeds, it will exit with 0. Otherwise, if an error occurs,
+it will exit with a non-zero value.
+
+=head1 SEE ALSO
+
+L<lli|lli>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/lli.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/lli.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/lli.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/lli.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,219 @@
+=pod
+
+=head1 NAME
+
+lli - directly execute programs from LLVM bitcode
+
+=head1 SYNOPSIS
+
+B<lli> [I<options>] [I<filename>] [I<program args>]
+
+=head1 DESCRIPTION
+
+B<lli> directly executes programs in LLVM bitcode format. It takes a program
+in LLVM bitcode format and executes it using a just-in-time compiler, if one is
+available for the current architecture, or an interpreter. B<lli> takes all of
+the same code generator options as L<llc|llc>, but they are only effective when
+B<lli> is using the just-in-time compiler.
+
+If I<filename> is not specified, then B<lli> reads the LLVM bitcode for the
+program from standard input.
+
+The optional I<args> specified on the command line are passed to the program as
+arguments.
+
+=head1 GENERAL OPTIONS
+
+=over
+
+=item B<-fake-argv0>=I<executable>
+
+Override the C<argv[0]> value passed into the executing program.
+
+=item B<-force-interpreter>=I<{false,true}>
+
+If set to true, use the interpreter even if a just-in-time compiler is available
+for this architecture. Defaults to false.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-load>=I<puginfilename>
+
+Causes B<lli> to load the plugin (shared object) named I<pluginfilename> and use
+it for optimization.
+
+=item B<-stats>
+
+Print statistics from the code-generation passes. This is only meaningful for
+the just-in-time compiler, at present.
+
+=item B<-time-passes>
+
+Record the amount of time needed for each code-generation pass and print it to
+standard error.
+
+=item B<-version>
+
+Print out the version of B<lli> and exit without doing anything else.
+
+=back
+
+=head1 TARGET OPTIONS
+
+=over
+
+=item B<-mtriple>=I<target triple>
+
+Override the target triple specified in the input bitcode file with the
+specified string. This may result in a crash if you pick an
+architecture which is not compatible with the current system.
+
+=item B<-march>=I<arch>
+
+Specify the architecture for which to generate assembly, overriding the target
+encoded in the bitcode file. See the output of B<llc -help> for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.
+
+=item B<-mcpu>=I<cpuname>
+
+Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+B<llvm-as E<lt> /dev/null | llc -march=xyz -mcpu=help>
+
+=item B<-mattr>=I<a1,+a2,-a3,...>
+
+Override or control specific attributes of the target, such as whether SIMD
+operations are enabled or not. The default set of attributes is set by the
+current CPU. For a list of available attributes, use:
+B<llvm-as E<lt> /dev/null | llc -march=xyz -mattr=help>
+
+=back
+
+
+=head1 FLOATING POINT OPTIONS
+
+=over
+
+=item B<-disable-excess-fp-precision>
+
+Disable optimizations that may increase floating point precision.
+
+=item B<-enable-no-infs-fp-math>
+
+Enable optimizations that assume no Inf values.
+
+=item B<-enable-no-nans-fp-math>
+
+Enable optimizations that assume no NAN values.
+
+=item B<-enable-unsafe-fp-math>
+
+Causes B<lli> to enable optimizations that may decrease floating point
+precision.
+
+=item B<-soft-float>
+
+Causes B<lli> to generate software floating point library calls instead of
+equivalent hardware instructions.
+
+=back
+
+=head1 CODE GENERATION OPTIONS
+
+=over
+
+=item B<-code-model>=I<model>
+
+Choose the code model from:
+
+ default: Target default code model
+ small: Small code model
+ kernel: Kernel code model
+ medium: Medium code model
+ large: Large code model
+
+=item B<-disable-post-RA-scheduler>
+
+Disable scheduling after register allocation.
+
+=item B<-disable-spill-fusing>
+
+Disable fusing of spill code into instructions.
+
+=item B<-enable-correct-eh-support>
+
+Make the -lowerinvoke pass insert expensive, but correct, EH code.
+
+=item B<-jit-enable-eh>
+
+Exception handling should be enabled in the just-in-time compiler.
+
+=item B<-join-liveintervals>
+
+Coalesce copies (default=true).
+
+=item B<-nozero-initialized-in-bss>
+Don't place zero-initialized symbols into the BSS section.
+
+=item B<-pre-RA-sched>=I<scheduler>
+
+Instruction schedulers available (before register allocation):
+
+ =default: Best scheduler for the target
+ =none: No scheduling: breadth first sequencing
+ =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization
+ =simple-noitin: Simple two pass scheduling: Same as simple except using generic latency
+ =list-burr: Bottom-up register reduction list scheduling
+ =list-tdrr: Top-down register reduction list scheduling
+ =list-td: Top-down list scheduler -print-machineinstrs - Print generated machine code
+
+=item B<-regalloc>=I<allocator>
+
+Register allocator to use (default=linearscan)
+
+ =bigblock: Big-block register allocator
+ =linearscan: linear scan register allocator =local - local register allocator
+ =simple: simple register allocator
+
+=item B<-relocation-model>=I<model>
+
+Choose relocation model from:
+
+ =default: Target default relocation model
+ =static: Non-relocatable code =pic - Fully relocatable, position independent code
+ =dynamic-no-pic: Relocatable external references, non-relocatable code
+
+=item B<-spiller>
+
+Spiller to use (default=local)
+
+ =simple: simple spiller
+ =local: local spiller
+
+=item B<-x86-asm-syntax>=I<syntax>
+
+Choose style of code to emit from X86 backend:
+
+ =att: Emit AT&T-style assembly
+ =intel: Emit Intel-style assembly
+
+=back
+
+=head1 EXIT STATUS
+
+If B<lli> fails to load the program, it will exit with an exit code of 1.
+Otherwise, it will return the exit code of the program it executes.
+
+=head1 SEE ALSO
+
+L<llc|llc>
+
+=head1 AUTHOR
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-ar.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-ar.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-ar.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-ar.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,406 @@
+=pod
+
+=head1 NAME
+
+llvm-ar - LLVM archiver
+
+=head1 SYNOPSIS
+
+B<llvm-ar> [-]{dmpqrtx}[Rabfikouz] [relpos] [count] <archive> [files...]
+
+
+=head1 DESCRIPTION
+
+The B<llvm-ar> command is similar to the common Unix utility, C<ar>. It
+archives several files together into a single file. The intent for this is
+to produce archive libraries by LLVM bitcode that can be linked into an
+LLVM program. However, the archive can contain any kind of file. By default,
+B<llvm-ar> generates a symbol table that makes linking faster because
+only the symbol table needs to be consulted, not each individual file member
+of the archive.
+
+The B<llvm-ar> command can be used to I<read> both SVR4 and BSD style archive
+files. However, it cannot be used to write them. While the B<llvm-ar> command
+produces files that are I<almost> identical to the format used by other C<ar>
+implementations, it has two significant departures in order to make the
+archive appropriate for LLVM. The first departure is that B<llvm-ar> only
+uses BSD4.4 style long path names (stored immediately after the header) and
+never contains a string table for long names. The second departure is that the
+symbol table is formated for efficient construction of an in-memory data
+structure that permits rapid (red-black tree) lookups. Consequently, archives
+produced with B<llvm-ar> usually won't be readable or editable with any
+C<ar> implementation or useful for linking. Using the C<f> modifier to flatten
+file names will make the archive readable by other C<ar> implementations
+but not for linking because the symbol table format for LLVM is unique. If an
+SVR4 or BSD style archive is used with the C<r> (replace) or C<q> (quick
+update) operations, the archive will be reconstructed in LLVM format. This
+means that the string table will be dropped (in deference to BSD 4.4 long names)
+and an LLVM symbol table will be added (by default). The system symbol table
+will be retained.
+
+Here's where B<llvm-ar> departs from previous C<ar> implementations:
+
+=over
+
+=item I<Symbol Table>
+
+Since B<llvm-ar> is intended to archive bitcode files, the symbol table
+won't make much sense to anything but LLVM. Consequently, the symbol table's
+format has been simplified. It consists simply of a sequence of pairs
+of a file member index number as an LSB 4byte integer and a null-terminated
+string.
+
+=item I<Long Paths>
+
+Some C<ar> implementations (SVR4) use a separate file member to record long
+path names (> 15 characters). B<llvm-ar> takes the BSD 4.4 and Mac OS X
+approach which is to simply store the full path name immediately preceding
+the data for the file. The path name is null terminated and may contain the
+slash (/) character.
+
+=item I<Compression>
+
+B<llvm-ar> can compress the members of an archive to save space. The
+compression used depends on what's available on the platform and what choices
+the LLVM Compressor utility makes. It generally favors bzip2 but will select
+between "no compression" or bzip2 depending on what makes sense for the
+file's content.
+
+=item I<Directory Recursion>
+
+Most C<ar> implementations do not recurse through directories but simply
+ignore directories if they are presented to the program in the F<files>
+option. B<llvm-ar>, however, can recurse through directory structures and
+add all the files under a directory, if requested.
+
+=item I<TOC Verbose Output>
+
+When B<llvm-ar> prints out the verbose table of contents (C<tv> option), it
+precedes the usual output with a character indicating the basic kind of
+content in the file. A blank means the file is a regular file. A 'Z' means
+the file is compressed. A 'B' means the file is an LLVM bitcode file. An
+'S' means the file is the symbol table.
+
+=back
+
+=head1 OPTIONS
+
+The options to B<llvm-ar> are compatible with other C<ar> implementations.
+However, there are a few modifiers (F<zR>) that are not found in other
+C<ar>s. The options to B<llvm-ar> specify a single basic operation to
+perform on the archive, a variety of modifiers for that operation, the
+name of the archive file, and an optional list of file names. These options
+are used to determine how B<llvm-ar> should process the archive file.
+
+The Operations and Modifiers are explained in the sections below. The minimal
+set of options is at least one operator and the name of the archive. Typically
+archive files end with a C<.a> suffix, but this is not required. Following
+the F<archive-name> comes a list of F<files> that indicate the specific members
+of the archive to operate on. If the F<files> option is not specified, it
+generally means either "none" or "all" members, depending on the operation.
+
+=head2 Operations
+
+=over
+
+=item d
+
+Delete files from the archive. No modifiers are applicable to this operation.
+The F<files> options specify which members should be removed from the
+archive. It is not an error if a specified file does not appear in the archive.
+If no F<files> are specified, the archive is not modified.
+
+=item m[abi]
+
+Move files from one location in the archive to another. The F<a>, F<b>, and
+F<i> modifiers apply to this operation. The F<files> will all be moved
+to the location given by the modifiers. If no modifiers are used, the files
+will be moved to the end of the archive. If no F<files> are specified, the
+archive is not modified.
+
+=item p[k]
+
+Print files to the standard output. The F<k> modifier applies to this
+operation. This operation simply prints the F<files> indicated to the
+standard output. If no F<files> are specified, the entire archive is printed.
+Printing bitcode files is ill-advised as they might confuse your terminal
+settings. The F<p> operation never modifies the archive.
+
+=item q[Rfz]
+
+Quickly append files to the end of the archive. The F<R>, F<f>, and F<z>
+modifiers apply to this operation. This operation quickly adds the
+F<files> to the archive without checking for duplicates that should be
+removed first. If no F<files> are specified, the archive is not modified.
+Because of the way that B<llvm-ar> constructs the archive file, its dubious
+whether the F<q> operation is any faster than the F<r> operation.
+
+=item r[Rabfuz]
+
+Replace or insert file members. The F<R>, F<a>, F<b>, F<f>, F<u>, and F<z>
+modifiers apply to this operation. This operation will replace existing
+F<files> or insert them at the end of the archive if they do not exist. If no
+F<files> are specified, the archive is not modified.
+
+=item t[v]
+
+Print the table of contents. Without any modifiers, this operation just prints
+the names of the members to the standard output. With the F<v> modifier,
+B<llvm-ar> also prints out the file type (B=bitcode, Z=compressed, S=symbol
+table, blank=regular file), the permission mode, the owner and group, the
+size, and the date. If any F<files> are specified, the listing is only for
+those files. If no F<files> are specified, the table of contents for the
+whole archive is printed.
+
+=item x[oP]
+
+Extract archive members back to files. The F<o> modifier applies to this
+operation. This operation retrieves the indicated F<files> from the archive
+and writes them back to the operating system's file system. If no
+F<files> are specified, the entire archive is extract.
+
+=back
+
+=head2 Modifiers (operation specific)
+
+The modifiers below are specific to certain operations. See the Operations
+section (above) to determine which modifiers are applicable to which operations.
+
+=over
+
+=item [a]
+
+When inserting or moving member files, this option specifies the destination of
+the new files as being C<a>fter the F<relpos> member. If F<relpos> is not found,
+the files are placed at the end of the archive.
+
+=item [b]
+
+When inserting or moving member files, this option specifies the destination of
+the new files as being C<b>efore the F<relpos> member. If F<relpos> is not
+found, the files are placed at the end of the archive. This modifier is
+identical to the the F<i> modifier.
+
+=item [f]
+
+Normally, B<llvm-ar> stores the full path name to a file as presented to it on
+the command line. With this option, truncated (15 characters max) names are
+used. This ensures name compatibility with older versions of C<ar> but may also
+thwart correct extraction of the files (duplicates may overwrite). If used with
+the F<R> option, the directory recursion will be performed but the file names
+will all be C<f>lattened to simple file names.
+
+=item [i]
+
+A synonym for the F<b> option.
+
+=item [k]
+
+Normally, B<llvm-ar> will not print the contents of bitcode files when the
+F<p> operation is used. This modifier defeats the default and allows the
+bitcode members to be printed.
+
+=item [N]
+
+This option is ignored by B<llvm-ar> but provided for compatibility.
+
+=item [o]
+
+When extracting files, this option will cause B<llvm-ar> to preserve the
+original modification times of the files it writes.
+
+=item [P]
+
+use full path names when matching
+
+=item [R]
+
+This modifier instructions the F<r> option to recursively process directories.
+Without F<R>, directories are ignored and only those F<files> that refer to
+files will be added to the archive. When F<R> is used, any directories specified
+with F<files> will be scanned (recursively) to find files to be added to the
+archive. Any file whose name begins with a dot will not be added.
+
+=item [u]
+
+When replacing existing files in the archive, only replace those files that have
+a time stamp than the time stamp of the member in the archive.
+
+=item [z]
+
+When inserting or replacing any file in the archive, compress the file first.
+This
+modifier is safe to use when (previously) compressed bitcode files are added to
+the archive; the compressed bitcode files will not be doubly compressed.
+
+=back
+
+=head2 Modifiers (generic)
+
+The modifiers below may be applied to any operation.
+
+=over
+
+=item [c]
+
+For all operations, B<llvm-ar> will always create the archive if it doesn't
+exist. Normally, B<llvm-ar> will print a warning message indicating that the
+archive is being created. Using this modifier turns off that warning.
+
+=item [s]
+
+This modifier requests that an archive index (or symbol table) be added to the
+archive. This is the default mode of operation. The symbol table will contain
+all the externally visible functions and global variables defined by all the
+bitcode files in the archive. Using this modifier is more efficient that using
+L<llvm-ranlib|llvm-ranlib> which also creates the symbol table.
+
+=item [S]
+
+This modifier is the opposite of the F<s> modifier. It instructs B<llvm-ar> to
+not build the symbol table. If both F<s> and F<S> are used, the last modifier to
+occur in the options will prevail.
+
+=item [v]
+
+This modifier instructs B<llvm-ar> to be verbose about what it is doing. Each
+editing operation taken against the archive will produce a line of output saying
+what is being done.
+
+=back
+
+=head1 STANDARDS
+
+The B<llvm-ar> utility is intended to provide a superset of the IEEE Std 1003.2
+(POSIX.2) functionality for C<ar>. B<llvm-ar> can read both SVR4 and BSD4.4 (or
+Mac OS X) archives. If the C<f> modifier is given to the C<x> or C<r> operations
+then B<llvm-ar> will write SVR4 compatible archives. Without this modifier,
+B<llvm-ar> will write BSD4.4 compatible archives that have long names
+immediately after the header and indicated using the "#1/ddd" notation for the
+name in the header.
+
+=head1 FILE FORMAT
+
+The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX
+archive files. In fact, except for the symbol table, the C<ar> commands on those
+operating systems should be able to read LLVM archive files. The details of the
+file format follow.
+
+Each archive begins with the archive magic number which is the eight printable
+characters "!<arch>\n" where \n represents the newline character (0x0A).
+Following the magic number, the file is composed of even length members that
+begin with an archive header and end with a \n padding character if necessary
+(to make the length even). Each file member is composed of a header (defined
+below), an optional newline-terminated "long file name" and the contents of
+the file.
+
+The fields of the header are described in the items below. All fields of the
+header contain only ASCII characters, are left justified and are right padded
+with space characters.
+
+=over
+
+=item name - char[16]
+
+This field of the header provides the name of the archive member. If the name is
+longer than 15 characters or contains a slash (/) character, then this field
+contains C<#1/nnn> where C<nnn> provides the length of the name and the C<#1/>
+is literal. In this case, the actual name of the file is provided in the C<nnn>
+bytes immediately following the header. If the name is 15 characters or less, it
+is contained directly in this field and terminated with a slash (/) character.
+
+=item date - char[12]
+
+This field provides the date of modification of the file in the form of a
+decimal encoded number that provides the number of seconds since the epoch
+(since 00:00:00 Jan 1, 1970) per Posix specifications.
+
+=item uid - char[6]
+
+This field provides the user id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_uid field of the stat structure returned by the stat(2)
+operating system call.
+
+=item gid - char[6]
+
+This field provides the group id of the file encoded as a decimal ASCII string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_gid field of the stat structure returned by the stat(2)
+operating system call.
+
+=item mode - char[8]
+
+This field provides the access mode of the file encoded as an octal ASCII
+string. This field might not make much sense on non-Unix systems. On Unix, it
+is the same value as the st_mode field of the stat structure returned by the
+stat(2) operating system call.
+
+=item size - char[10]
+
+This field provides the size of the file, in bytes, encoded as a decimal ASCII
+string. If the size field is negative (starts with a minus sign, 0x02D), then
+the archive member is stored in compressed form. The first byte of the archive
+member's data indicates the compression type used. A value of 0 (0x30) indicates
+that no compression was used. A value of 2 (0x32) indicates that bzip2
+compression was used.
+
+=item fmag - char[2]
+
+This field is the archive file member magic number. Its content is always the
+two characters back tick (0x60) and newline (0x0A). This provides some measure
+utility in identifying archive files that have been corrupted.
+
+=back
+
+The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed
+that no regular archive member file will want this name. The LLVM symbol table
+is simply composed of a sequence of triplets: byte offset, length of symbol,
+and the symbol itself. Symbols are not null or newline terminated. Here are
+the details on each of these items:
+
+=over
+
+=item offset - vbr encoded 32-bit integer
+
+The offset item provides the offset into the archive file where the bitcode
+member is stored that is associated with the symbol. The offset value is 0
+based at the start of the first "normal" file member. To derive the actual
+file offset of the member, you must add the number of bytes occupied by the file
+signature (8 bytes) and the symbol tables. The value of this item is encoded
+using variable bit rate encoding to reduce the size of the symbol table.
+Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
+if there are more bytes to follow. The remaining 7 bits in each byte carry bits
+from the value. The final byte does not have the high bit set.
+
+=item length - vbr encoded 32-bit integer
+
+The length item provides the length of the symbol that follows. Like this
+I<offset> item, the length is variable bit rate encoded.
+
+=item symbol - character array
+
+The symbol item provides the text of the symbol that is associated with the
+I<offset>. The symbol is not terminated by any character. Its length is provided
+by the I<length> field. Note that is allowed (but unwise) to use non-printing
+characters (even 0x00) in the symbol. This allows for multiple encodings of
+symbol names.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-ar> succeeds, it will exit with 0. A usage error, results
+in an exit code of 1. A hard (file system typically) error results in an
+exit code of 2. Miscellaneous or unknown errors result in an
+exit code of 3.
+
+=head1 SEE ALSO
+
+L<llvm-ranlib|llvm-ranlib>, ar(1)
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-as.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-as.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-as.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-as.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,77 @@
+=pod
+
+=head1 NAME
+
+llvm-as - LLVM assembler
+
+=head1 SYNOPSIS
+
+B<llvm-as> [I<options>] [I<filename>]
+
+=head1 DESCRIPTION
+
+B<llvm-as> is the LLVM assembler. It reads a file containing human-readable
+LLVM assembly language, translates it to LLVM bitcode, and writes the result
+into a file or to standard output.
+
+If F<filename> is omitted or is C<->, then B<llvm-as> reads its input from
+standard input.
+
+If an output file is not specified with the B<-o> option, then
+B<llvm-as> sends its output to a file or standard output by following
+these rules:
+
+=over
+
+=item *
+
+If the input is standard input, then the output is standard output.
+
+=item *
+
+If the input is a file that ends with C<.ll>, then the output file is of
+the same name, except that the suffix is changed to C<.bc>.
+
+=item *
+
+If the input is a file that does not end with the C<.ll> suffix, then the
+output file has the same name as the input file, except that the C<.bc>
+suffix is appended.
+
+=back
+
+=head1 OPTIONS
+
+=over
+
+=item B<-f>
+
+Enable binary output on terminals. Normally, B<llvm-as> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+B<llvm-as> will write raw bitcode regardless of the output device.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-o> F<filename>
+
+Specify the output file name. If F<filename> is C<->, then B<llvm-as>
+sends its output to standard output.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-as> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+=head1 SEE ALSO
+
+L<llvm-dis|llvm-dis>, L<gccas|gccas>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-bcanalyzer.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-bcanalyzer.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-bcanalyzer.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-bcanalyzer.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,315 @@
+=pod
+
+=head1 NAME
+
+llvm-bcanalyzer - LLVM bitcode analyzer
+
+=head1 SYNOPSIS
+
+B<llvm-bcanalyzer> [I<options>] [F<filename>]
+
+=head1 DESCRIPTION
+
+The B<llvm-bcanalyzer> command is a small utility for analyzing bitcode files.
+The tool reads a bitcode file (such as generated with the B<llvm-as> tool) and
+produces a statistical report on the contents of the bitcode file. The tool
+can also dump a low level but human readable version of the bitcode file.
+This tool is probably not of much interest or utility except for those working
+directly with the bitcode file format. Most LLVM users can just ignore
+this tool.
+
+If F<filename> is omitted or is C<->, then B<llvm-bcanalyzer> reads its input
+from standard input. This is useful for combining the tool into a pipeline.
+Output is written to the standard output.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-nodetails>
+
+Causes B<llvm-bcanalyzer> to abbreviate its output by writing out only a module
+level summary. The details for individual functions are not displayed.
+
+=item B<-dump>
+
+Causes B<llvm-bcanalyzer> to dump the bitcode in a human readable format. This
+format is significantly different from LLVM assembly and provides details about
+the encoding of the bitcode file.
+
+=item B<-verify>
+
+Causes B<llvm-bcanalyzer> to verify the module produced by reading the
+bitcode. This ensures that the statistics generated are based on a consistent
+module.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-bcanalyzer> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value, usually 1.
+
+=head1 SUMMARY OUTPUT DEFINITIONS
+
+The following items are always printed by llvm-bcanalyzer. They comprize the
+summary output.
+
+=over
+
+=item B<Bitcode Analysis Of Module>
+
+This just provides the name of the module for which bitcode analysis is being
+generated.
+
+=item B<Bitcode Version Number>
+
+The bitcode version (not LLVM version) of the file read by the analyzer.
+
+=item B<File Size>
+
+The size, in bytes, of the entire bitcode file.
+
+=item B<Module Bytes>
+
+The size, in bytes, of the module block. Percentage is relative to File Size.
+
+=item B<Function Bytes>
+
+The size, in bytes, of all the function blocks. Percentage is relative to File
+Size.
+
+=item B<Global Types Bytes>
+
+The size, in bytes, of the Global Types Pool. Percentage is relative to File
+Size. This is the size of the definitions of all types in the bitcode file.
+
+=item B<Constant Pool Bytes>
+
+The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+Size.
+
+=item B<Module Globals Bytes>
+
+Ths size, in bytes, of the Global Variable Definitions and their initializers.
+Percentage is relative to File Size.
+
+=item B<Instruction List Bytes>
+
+The size, in bytes, of all the instruction lists in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.
+
+=item B<Compaction Table Bytes>
+
+The size, in bytes, of all the compaction tables in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.
+
+=item B<Symbol Table Bytes>
+
+The size, in bytes, of all the symbol tables in all the functions. Percentage is
+relative to File Size. Note that this value is also included in the Function
+Bytes.
+
+=item B<Dependent Libraries Bytes>
+
+The size, in bytes, of the list of dependent libraries in the module. Percentage
+is relative to File Size. Note that this value is also included in the Module
+Global Bytes.
+
+=item B<Number Of Bitcode Blocks>
+
+The total number of blocks of any kind in the bitcode file.
+
+=item B<Number Of Functions>
+
+The total number of function definitions in the bitcode file.
+
+=item B<Number Of Types>
+
+The total number of types defined in the Global Types Pool.
+
+=item B<Number Of Constants>
+
+The total number of constants (of any type) defined in the Constant Pool.
+
+=item B<Number Of Basic Blocks>
+
+The total number of basic blocks defined in all functions in the bitcode file.
+
+=item B<Number Of Instructions>
+
+The total number of instructions defined in all functions in the bitcode file.
+
+=item B<Number Of Long Instructions>
+
+The total number of long instructions defined in all functions in the bitcode
+file. Long instructions are those taking greater than 4 bytes. Typically long
+instructions are GetElementPtr with several indices, PHI nodes, and calls to
+functions with large numbers of arguments.
+
+=item B<Number Of Operands>
+
+The total number of operands used in all instructions in the bitcode file.
+
+=item B<Number Of Compaction Tables>
+
+The total number of compaction tables in all functions in the bitcode file.
+
+=item B<Number Of Symbol Tables>
+
+The total number of symbol tables in all functions in the bitcode file.
+
+=item B<Number Of Dependent Libs>
+
+The total number of dependent libraries found in the bitcode file.
+
+=item B<Total Instruction Size>
+
+The total size of the instructions in all functions in the bitcode file.
+
+=item B<Average Instruction Size>
+
+The average number of bytes per instruction across all functions in the bitcode
+file. This value is computed by dividing Total Instruction Size by Number Of
+Instructions.
+
+=item B<Maximum Type Slot Number>
+
+The maximum value used for a type's slot number. Larger slot number values take
+more bytes to encode.
+
+=item B<Maximum Value Slot Number>
+
+The maximum value used for a value's slot number. Larger slot number values take
+more bytes to encode.
+
+=item B<Bytes Per Value>
+
+The average size of a Value definition (of any type). This is computed by
+dividing File Size by the total number of values of any type.
+
+=item B<Bytes Per Global>
+
+The average size of a global definition (constants and global variables).
+
+=item B<Bytes Per Function>
+
+The average number of bytes per function definition. This is computed by
+dividing Function Bytes by Number Of Functions.
+
+=item B<# of VBR 32-bit Integers>
+
+The total number of 32-bit integers encoded using the Variable Bit Rate
+encoding scheme.
+
+=item B<# of VBR 64-bit Integers>
+
+The total number of 64-bit integers encoded using the Variable Bit Rate encoding
+scheme.
+
+=item B<# of VBR Compressed Bytes>
+
+The total number of bytes consumed by the 32-bit and 64-bit integers that use
+the Variable Bit Rate encoding scheme.
+
+=item B<# of VBR Expanded Bytes>
+
+The total number of bytes that would have been consumed by the 32-bit and 64-bit
+integers had they not been compressed with the Variable Bit Rage encoding
+scheme.
+
+=item B<Bytes Saved With VBR>
+
+The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+The percentage is relative to # of VBR Expanded Bytes.
+
+=back
+
+=head1 DETAILED OUTPUT DEFINITIONS
+
+The following definitions occur only if the -nodetails option was not given.
+The detailed output provides additional information on a per-function basis.
+
+=over
+
+=item B<Type>
+
+The type signature of the function.
+
+=item B<Byte Size>
+
+The total number of bytes in the function's block.
+
+=item B<Basic Blocks>
+
+The number of basic blocks defined by the function.
+
+=item B<Instructions>
+
+The number of instructions defined by the function.
+
+=item B<Long Instructions>
+
+The number of instructions using the long instruction format in the function.
+
+=item B<Operands>
+
+The number of operands used by all instructions in the function.
+
+=item B<Instruction Size>
+
+The number of bytes consumed by instructions in the function.
+
+=item B<Average Instruction Size>
+
+The average number of bytes consumed by the instructions in the function. This
+value is computed by dividing Instruction Size by Instructions.
+
+=item B<Bytes Per Instruction>
+
+The average number of bytes used by the function per instruction. This value is
+computed by dividing Byte Size by Instructions. Note that this is not the same
+as Average Instruction Size. It computes a number relative to the total function
+size not just the size of the instruction list.
+
+=item B<Number of VBR 32-bit Integers>
+
+The total number of 32-bit integers found in this function (for any use).
+
+=item B<Number of VBR 64-bit Integers>
+
+The total number of 64-bit integers found in this function (for any use).
+
+=item B<Number of VBR Compressed Bytes>
+
+The total number of bytes in this function consumed by the 32-bit and 64-bit
+integers that use the Variable Bit Rate encoding scheme.
+
+=item B<Number of VBR Expanded Bytes>
+
+The total number of bytes in this function that would have been consumed by
+the 32-bit and 64-bit integers had they not been compressed with the Variable
+Bit Rate encoding scheme.
+
+=item B<Bytes Saved With VBR>
+
+The total number of bytes saved in this function by using the Variable Bit
+Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes.
+
+=back
+
+=head1 SEE ALSO
+
+L<llvm-dis|llvm-dis>, L<http://llvm.org/docs/BitCodeFormat.html>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-build.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-build.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-build.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-build.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,86 @@
+=pod
+
+=head1 NAME
+
+llvm-build - LLVM Project Build Utility
+
+=head1 SYNOPSIS
+
+B<llvm-build> [I<options>]
+
+=head1 DESCRIPTION
+
+B<llvm-build> is a tool for working with LLVM projects that use the LLVMBuild
+system for describing their components.
+
+At heart, B<llvm-build> is responsible for loading, verifying, and manipulating
+the project's component data. The tool is primarily designed for use in
+implementing build systems and tools which need access to the project structure
+information.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-h>, B<--help>
+
+Print the builtin program help.
+
+=item B<--source-root>=I<PATH>
+
+If given, load the project at the given source root path. If this option is not
+given, the location of the project sources will be inferred from the location of
+the B<llvm-build> script itself.
+
+=item B<--print-tree>
+
+Print the component tree for the project.
+
+=item B<--write-library-table>
+
+Write out the C++ fragment which defines the components, library names, and
+required libraries. This C++ fragment is built into L<llvm-config|llvm-config>
+in order to provide clients with the list of required libraries for arbitrary
+component combinations.
+
+=item B<--write-llvmbuild>
+
+Write out new I<LLVMBuild.txt> files based on the loaded components. This is
+useful for auto-upgrading the schema of the files. B<llvm-build> will try to a
+limited extent to preserve the comments which were written in the original
+source file, although at this time it only preserves block comments that preceed
+the section names in the I<LLVMBuild> files.
+
+=item B<--write-cmake-fragment>
+
+Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+consumed by the CMake based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with CMake, see LLVM's
+top-level CMakeLists.txt.
+
+=item B<--write-make-fragment>
+
+Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
+consumed by a Make based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with the Makefiles, see
+LLVM's Makefile.rules.
+
+=item B<--llvmbuild-source-root>=I<PATH>
+
+If given, expect the I<LLVMBuild> files for the project to be rooted at the
+given path, instead of inside the source tree itself. This option is primarily
+designed for use in conjunction with B<--write-llvmbuild> to test changes to
+I<LLVMBuild> schema.
+
+=back
+
+=head1 EXIT STATUS
+
+B<llvm-build> exits with 0 if operation was successful. Otherwise, it will exist
+with a non-zero value.
+
+=head1 AUTHOR
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-config.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-config.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-config.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-config.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,131 @@
+=pod
+
+=head1 NAME
+
+llvm-config - Print LLVM compilation options
+
+=head1 SYNOPSIS
+
+B<llvm-config> I<option> [I<components>...]
+
+=head1 DESCRIPTION
+
+B<llvm-config> makes it easier to build applications that use LLVM. It can
+print the compiler flags, linker flags and object libraries needed to link
+against LLVM.
+
+=head1 EXAMPLES
+
+To link against the JIT:
+
+ g++ `llvm-config --cxxflags` -o HowToUseJIT.o -c HowToUseJIT.cpp
+ g++ `llvm-config --ldflags` -o HowToUseJIT HowToUseJIT.o \
+ `llvm-config --libs engine bcreader scalaropts`
+
+=head1 OPTIONS
+
+=over
+
+=item B<--version>
+
+Print the version number of LLVM.
+
+=item B<-help>
+
+Print a summary of B<llvm-config> arguments.
+
+=item B<--prefix>
+
+Print the installation prefix for LLVM.
+
+=item B<--src-root>
+
+Print the source root from which LLVM was built.
+
+=item B<--obj-root>
+
+Print the object root used to build LLVM.
+
+=item B<--bindir>
+
+Print the installation directory for LLVM binaries.
+
+=item B<--includedir>
+
+Print the installation directory for LLVM headers.
+
+=item B<--libdir>
+
+Print the installation directory for LLVM libraries.
+
+=item B<--cxxflags>
+
+Print the C++ compiler flags needed to use LLVM headers.
+
+=item B<--ldflags>
+
+Print the flags needed to link against LLVM libraries.
+
+=item B<--libs>
+
+Print all the libraries needed to link against the specified LLVM
+I<components>, including any dependencies.
+
+=item B<--libnames>
+
+Similar to B<--libs>, but prints the bare filenames of the libraries
+without B<-l> or pathnames. Useful for linking against a not-yet-installed
+copy of LLVM.
+
+=item B<--libfiles>
+
+Similar to B<--libs>, but print the full path to each library file. This is
+useful when creating makefile dependencies, to ensure that a tool is relinked if
+any library it uses changes.
+
+=item B<--components>
+
+Print all valid component names.
+
+=item B<--targets-built>
+
+Print the component names for all targets supported by this copy of LLVM.
+
+=item B<--build-mode>
+
+Print the build mode used when LLVM was built (e.g. Debug or Release)
+
+=back
+
+=head1 COMPONENTS
+
+To print a list of all available components, run B<llvm-config
+--components>. In most cases, components correspond directly to LLVM
+libraries. Useful "virtual" components include:
+
+=over
+
+=item B<all>
+
+Includes all LLVM libaries. The default if no components are specified.
+
+=item B<backend>
+
+Includes either a native backend or the C backend.
+
+=item B<engine>
+
+Includes either a native JIT or the bitcode interpreter.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-config> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-cov.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-cov.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-cov.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-cov.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,45 @@
+=pod
+
+=head1 NAME
+
+llvm-cov - emit coverage information
+
+=head1 SYNOPSIS
+
+B<llvm-cov> [-gcno=filename] [-gcda=filename] [dump]
+
+=head1 DESCRIPTION
+
+The experimental B<llvm-cov> tool reads in description file generated by compiler
+and coverage data file generated by instrumented program. This program assumes
+that the description and data file uses same format as gcov files.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-gcno=filename]
+
+This option selects input description file generated by compiler while instrumenting
+program.
+
+=item B<-gcda=filename]
+
+This option selects coverage data file generated by instrumented compiler.
+
+=item B<-dump>
+
+This options enables output dump that is suitable for a developer to help debug
+B<llvm-cov> itself.
+
+=back
+
+=head1 EXIT STATUS
+
+B<llvm-cov> returns 1 if it cannot read input files. Otherwise, it exits with zero.
+
+=head1 AUTHOR
+
+B<llvm-cov> is maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-diff.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-diff.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-diff.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-diff.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,53 @@
+=pod
+
+=head1 NAME
+
+llvm-diff - LLVM structural 'diff'
+
+=head1 SYNOPSIS
+
+B<llvm-diff> [I<options>] I<module 1> I<module 2> [I<global name ...>]
+
+=head1 DESCRIPTION
+
+B<llvm-diff> compares the structure of two LLVM modules, primarily
+focusing on differences in function definitions. Insignificant
+differences, such as changes in the ordering of globals or in the
+names of local values, are ignored.
+
+An input module will be interpreted as an assembly file if its name
+ends in '.ll'; otherwise it will be read in as a bitcode file.
+
+If a list of global names is given, just the values with those names
+are compared; otherwise, all global values are compared, and
+diagnostics are produced for globals which only appear in one module
+or the other.
+
+B<llvm-diff> compares two functions by comparing their basic blocks,
+beginning with the entry blocks. If the terminators seem to match,
+then the corresponding successors are compared; otherwise they are
+ignored. This algorithm is very sensitive to changes in control flow,
+which tend to stop any downstream changes from being detected.
+
+B<llvm-diff> is intended as a debugging tool for writers of LLVM
+passes and frontends. It does not have a stable output format.
+
+=head1 EXIT STATUS
+
+If B<llvm-diff> finds no differences between the modules, it will exit
+with 0 and produce no output. Otherwise it will exit with a non-zero
+value.
+
+=head1 BUGS
+
+Many important differences, like changes in linkage or function
+attributes, are not diagnosed.
+
+Changes in memory behavior (for example, coalescing loads) can cause
+massive detected differences in blocks.
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-dis.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-dis.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-dis.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-dis.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,60 @@
+=pod
+
+=head1 NAME
+
+llvm-dis - LLVM disassembler
+
+=head1 SYNOPSIS
+
+B<llvm-dis> [I<options>] [I<filename>]
+
+=head1 DESCRIPTION
+
+The B<llvm-dis> command is the LLVM disassembler. It takes an LLVM
+bitcode file and converts it into human-readable LLVM assembly language.
+
+If filename is omitted or specified as C<->, B<llvm-dis> reads its
+input from standard input.
+
+If the input is being read from standard input, then B<llvm-dis>
+will send its output to standard output by default. Otherwise, the
+output will be written to a file named after the input file, with
+a C<.ll> suffix added (any existing C<.bc> suffix will first be
+removed). You can override the choice of output file using the
+B<-o> option.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-f>
+
+Enable binary output on terminals. Normally, B<llvm-dis> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+B<llvm-dis> will write raw bitcode regardless of the output device.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-o> F<filename>
+
+Specify the output file name. If F<filename> is -, then the output is sent
+to standard output.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-dis> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+=head1 SEE ALSO
+
+L<llvm-as|llvm-as>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-extract.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-extract.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-extract.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-extract.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,85 @@
+=pod
+
+=head1 NAME
+
+llvm-extract - extract a function from an LLVM module
+
+=head1 SYNOPSIS
+
+B<llvm-extract> [I<options>] B<--func> I<function-name> [I<filename>]
+
+=head1 DESCRIPTION
+
+The B<llvm-extract> command takes the name of a function and extracts it from
+the specified LLVM bitcode file. It is primarily used as a debugging tool to
+reduce test cases from larger programs that are triggering a bug.
+
+In addition to extracting the bitcode of the specified function,
+B<llvm-extract> will also remove unreachable global variables, prototypes, and
+unused types.
+
+The B<llvm-extract> command reads its input from standard input if filename is
+omitted or if filename is -. The output is always written to standard output,
+unless the B<-o> option is specified (see below).
+
+=head1 OPTIONS
+
+=over
+
+=item B<-f>
+
+Enable binary output on terminals. Normally, B<llvm-extract> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+B<llvm-extract> will write raw bitcode regardless of the output device.
+
+=item B<--func> I<function-name>
+
+Extract the function named I<function-name> from the LLVM bitcode. May be
+specified multiple times to extract multiple functions at once.
+
+=item B<--rfunc> I<function-regular-expr>
+
+Extract the function(s) matching I<function-regular-expr> from the LLVM bitcode.
+All functions matching the regular expression will be extracted. May be
+specified multiple times.
+
+=item B<--glob> I<global-name>
+
+Extract the global variable named I<global-name> from the LLVM bitcode. May be
+specified multiple times to extract multiple global variables at once.
+
+=item B<--rglob> I<glob-regular-expr>
+
+Extract the global variable(s) matching I<global-regular-expr> from the LLVM
+bitcode. All global variables matching the regular expression will be extracted.
+May be specified multiple times.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-o> I<filename>
+
+Specify the output filename. If filename is "-" (the default), then
+B<llvm-extract> sends its output to standard output.
+
+=item B<-S>
+
+Write output in LLVM intermediate language (instead of bitcode).
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-extract> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+=head1 SEE ALSO
+
+L<bugpoint|bugpoint>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-ld.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-ld.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-ld.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-ld.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,234 @@
+=pod
+
+=head1 NAME
+
+llvm-ld - LLVM linker
+
+=head1 SYNOPSIS
+
+B<llvm-ld> <options> <files>
+
+=head1 DESCRIPTION
+
+The B<llvm-ld> tool takes a set of LLVM bitcode files and links them
+together into a single LLVM bitcode file. The output bitcode file can be
+another bitcode file or an executable bitcode program. Using additional
+options, B<llvm-ld> is able to produce native code executables.
+
+The B<llvm-ld> tool is the main linker for LLVM. It is used to link together
+the output of LLVM front-end compilers and run "link time" optimizations (mostly
+the inter-procedural kind).
+
+The B<llvm-ld> tools attempts to mimic the interface provided by the default
+system linker so that it can act as a I<drop-in> replacement.
+
+=head2 Search Order
+
+When looking for objects specified on the command line, B<llvm-ld> will search
+for the object first in the current directory and then in the directory
+specified by the B<LLVM_LIB_SEARCH_PATH> environment variable. If it cannot
+find the object, it fails.
+
+When looking for a library specified with the B<-l> option, B<llvm-ld> first
+attempts to load a file with that name from the current directory. If that
+fails, it looks for libI<library>.bc, libI<library>.a, or libI<library>.I<shared
+library extension>, in that order, in each directory added to the library search
+path with the B<-L> option. These directories are searched in the order they
+are specified. If the library cannot be located, then B<llvm-ld> looks in the
+directory specified by the B<LLVM_LIB_SEARCH_PATH> environment variable. If it
+does not find a library there, it fails.
+
+The I<shared library extension> may be I<.so>, I<.dyld>, I<.dll>, or something
+different, depending upon the system.
+
+The B<-L> option is global. It does not matter where it is specified in the
+list of command line arguments; the directory is simply added to the search path
+and is applied to all libraries, preceding or succeeding, in the command line.
+
+=head2 Link order
+
+All object and bitcode files are linked first in the order they were
+specified on the command line. All library files are linked next.
+Some libraries may not be linked into the object program; see below.
+
+=head2 Library Linkage
+
+Object files and static bitcode objects are always linked into the output
+file. Library archives (.a files) load only the objects within the archive
+that define symbols needed by the output file. Hence, libraries should be
+listed after the object files and libraries which need them; otherwise, the
+library may not be linked in, and the dependent library will not have its
+undefined symbols defined.
+
+=head2 Native code generation
+
+The B<llvm-ld> program has limited support for native code generation, when
+using the B<-native> or B<-native-cbe> options. Native code generation is
+performed by converting the linked bitcode into native assembly (.s) or C code
+and running the system compiler (typically gcc) on the result.
+
+=head1 OPTIONS
+
+=head2 General Options
+
+=over
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-v>
+
+Specifies verbose mode. In this mode the linker will print additional
+information about the actions it takes, programs it executes, etc.
+
+=item B<-stats>
+
+Print statistics.
+
+=item B<-time-passes>
+
+Record the amount of time needed for each pass and print it to standard
+error.
+
+=back
+
+=head2 Input/Output Options
+
+=over
+
+=item B<-o> F<filename>
+
+This overrides the default output file and specifies the name of the file that
+should be generated by the linker. By default, B<llvm-ld> generates a file named
+F<a.out> for compatibility with B<ld>. The output will be written to
+F<filename>.
+
+=item B<-b> F<filename>
+
+This option can be used to override the output bitcode file name. By default,
+the name of the bitcode output file is one more ".bc" suffix added to the name
+specified by B<-o filename> option.
+
+=item B<-l>F<name>
+
+This option specifies the F<name> of a library to search when resolving symbols
+for the program. Only the base name should be specified as F<name>, without a
+F<lib> prefix or any suffix.
+
+=item B<-L>F<Path>
+
+This option tells B<llvm-ld> to look in F<Path> to find any library subsequently
+specified with the B<-l> option. The paths will be searched in the order in
+which they are specified on the command line. If the library is still not found,
+a small set of system specific directories will also be searched. Note that
+libraries specified with the B<-l> option that occur I<before> any B<-L> options
+will not search the paths given by the B<-L> options following it.
+
+=item B<-link-as-library>
+
+Link the bitcode files together as a library, not an executable. In this mode,
+undefined symbols will be permitted.
+
+=item B<-r>
+
+An alias for -link-as-library.
+
+=item B<-native>
+
+Generate a native machine code executable.
+
+When generating native executables, B<llvm-ld> first checks for a bitcode
+version of the library and links it in, if necessary. If the library is
+missing, B<llvm-ld> skips it. Then, B<llvm-ld> links in the same
+libraries as native code.
+
+In this way, B<llvm-ld> should be able to link in optimized bitcode
+subsets of common libraries and then link in any part of the library that
+hasn't been converted to bitcode.
+
+=item B<-native-cbe>
+
+Generate a native machine code executable with the LLVM C backend.
+
+This option is identical to the B<-native> option, but uses the
+C backend to generate code for the program instead of an LLVM native
+code generator.
+
+=back
+
+=head2 Optimization Options
+
+=over
+
+=item B<-disable-inlining>
+
+Do not run the inlining pass. Functions will not be inlined into other
+functions.
+
+=item B<-disable-opt>
+
+Completely disable optimization.
+
+=item B<-disable-internalize>
+
+Do not mark all symbols as internal.
+
+=item B<-verify-each>
+
+Run the verification pass after each of the passes to verify intermediate
+results.
+
+=item B<-strip-all>
+
+Strip all debug and symbol information from the executable to make it smaller.
+
+=item B<-strip-debug>
+
+Strip all debug information from the executable to make it smaller.
+
+=item B<-s>
+
+An alias for B<-strip-all>.
+
+=item B<-S>
+
+An alias for B<-strip-debug>.
+
+=item B<-export-dynamic>
+
+An alias for B<-disable-internalize>
+
+=item B<-post-link-opt>F<Path>
+
+Run post-link optimization program. After linking is completed a bitcode file
+will be generated. It will be passed to the program specified by F<Path> as the
+first argument. The second argument to the program will be the name of a
+temporary file into which the program should place its optimized output. For
+example, the "no-op optimization" would be a simple shell script:
+
+ #!/bin/bash
+ cp $1 $2
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-ld> succeeds, it will exit with 0 return code. If an error occurs,
+it will exit with a non-zero return code.
+
+=head1 ENVIRONMENT
+
+The C<LLVM_LIB_SEARCH_PATH> environment variable is used to find bitcode
+libraries. Any paths specified in this variable will be searched after the C<-L>
+options.
+
+=head1 SEE ALSO
+
+L<llvm-link|llvm-link>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-link.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-link.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-link.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-link.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,79 @@
+=pod
+
+=head1 NAME
+
+llvm-link - LLVM linker
+
+=head1 SYNOPSIS
+
+B<llvm-link> [I<options>] I<filename ...>
+
+=head1 DESCRIPTION
+
+B<llvm-link> takes several LLVM bitcode files and links them together into a
+single LLVM bitcode file. It writes the output file to standard output, unless
+the B<-o> option is used to specify a filename.
+
+B<llvm-link> attempts to load the input files from the current directory. If
+that fails, it looks for each file in each of the directories specified by the
+B<-L> options on the command line. The library search paths are global; each
+one is searched for every input file if necessary. The directories are searched
+in the order they were specified on the command line.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-L> F<directory>
+
+Add the specified F<directory> to the library search path. When looking for
+libraries, B<llvm-link> will look in path name for libraries. This option can be
+specified multiple times; B<llvm-link> will search inside these directories in
+the order in which they were specified on the command line.
+
+=item B<-f>
+
+Enable binary output on terminals. Normally, B<llvm-link> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+B<llvm-link> will write raw bitcode regardless of the output device.
+
+=item B<-o> F<filename>
+
+Specify the output file name. If F<filename> is C<->, then B<llvm-link> will
+write its output to standard output.
+
+=item B<-S>
+
+Write output in LLVM intermediate language (instead of bitcode).
+
+=item B<-d>
+
+If specified, B<llvm-link> prints a human-readable version of the output
+bitcode file to standard error.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-v>
+
+Verbose mode. Print information about what B<llvm-link> is doing. This
+typically includes a message for each bitcode file linked in and for each
+library found.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-link> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+=head1 SEE ALSO
+
+L<gccld|gccld>
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-nm.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-nm.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-nm.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-nm.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,122 @@
+=pod
+
+=head1 NAME
+
+llvm-nm - list LLVM bitcode file's symbol table
+
+=head1 SYNOPSIS
+
+B<llvm-nm> [I<options>] [I<filenames...>]
+
+=head1 DESCRIPTION
+
+The B<llvm-nm> utility lists the names of symbols from the LLVM bitcode files,
+or B<ar> archives containing LLVM bitcode files, named on the command line.
+Each symbol is listed along with some simple information about its provenance.
+If no file name is specified, or I<-> is used as a file name, B<llvm-nm> will
+process a bitcode file on its standard input stream.
+
+B<llvm-nm>'s default output format is the traditional BSD B<nm> output format.
+Each such output record consists of an (optional) 8-digit hexadecimal address,
+followed by a type code character, followed by a name, for each symbol. One
+record is printed per line; fields are separated by spaces. When the address is
+omitted, it is replaced by 8 spaces.
+
+Type code characters currently supported, and their meanings, are as follows:
+
+=over
+
+=item U
+
+Named object is referenced but undefined in this bitcode file
+
+=item C
+
+Common (multiple definitions link together into one def)
+
+=item W
+
+Weak reference (multiple definitions link together into zero or one definitions)
+
+=item t
+
+Local function (text) object
+
+=item T
+
+Global function (text) object
+
+=item d
+
+Local data object
+
+=item D
+
+Global data object
+
+=item ?
+
+Something unrecognizable
+
+=back
+
+Because LLVM bitcode files typically contain objects that are not considered to
+have addresses until they are linked into an executable image or dynamically
+compiled "just-in-time", B<llvm-nm> does not print an address for any symbol,
+even symbols which are defined in the bitcode file.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-P>
+
+Use POSIX.2 output format. Alias for B<--format=posix>.
+
+=item B<-B> (default)
+
+Use BSD output format. Alias for B<--format=bsd>.
+
+=item B<-help>
+
+Print a summary of command-line options and their meanings.
+
+=item B<--defined-only>
+
+Print only symbols defined in this bitcode file (as opposed to
+symbols which may be referenced by objects in this file, but not
+defined in this file.)
+
+=item B<--extern-only>, B<-g>
+
+Print only symbols whose definitions are external; that is, accessible
+from other bitcode files.
+
+=item B<--undefined-only>, B<-u>
+
+Print only symbols referenced but not defined in this bitcode file.
+
+=item B<--format=>I<fmt>, B<-f>
+
+Select an output format; I<fmt> may be I<sysv>, I<posix>, or I<bsd>. The
+default is I<bsd>.
+
+=back
+
+=head1 BUGS
+
+B<llvm-nm> cannot demangle C++ mangled names, like GNU B<nm> can.
+
+=head1 EXIT STATUS
+
+B<llvm-nm> exits with an exit code of zero.
+
+=head1 SEE ALSO
+
+L<llvm-dis|llvm-dis>, ar(1), nm(1)
+
+=head1 AUTHOR
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-prof.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-prof.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-prof.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-prof.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,57 @@
+=pod
+
+=head1 NAME
+
+llvm-prof - print execution profile of LLVM program
+
+=head1 SYNOPSIS
+
+B<llvm-prof> [I<options>] [I<bitcode file>] [I<llvmprof.out>]
+
+=head1 DESCRIPTION
+
+The B<llvm-prof> tool reads in an F<llvmprof.out> file (which can
+optionally use a specific file with the third program argument), a bitcode file
+for the program, and produces a human readable report, suitable for determining
+where the program hotspots are.
+
+This program is often used in conjunction with the F<utils/profile.pl>
+script. This script automatically instruments a program, runs it with the JIT,
+then runs B<llvm-prof> to format a report. To get more information about
+F<utils/profile.pl>, execute it with the B<-help> option.
+
+=head1 OPTIONS
+
+=over
+
+=item B<--annotated-llvm> or B<-A>
+
+In addition to the normal report printed, print out the code for the
+program, annotated with execution frequency information. This can be
+particularly useful when trying to visualize how frequently basic blocks
+are executed. This is most useful with basic block profiling
+information or better.
+
+=item B<--print-all-code>
+
+Using this option enables the B<--annotated-llvm> option, but it
+prints the entire module, instead of just the most commonly executed
+functions.
+
+=item B<--time-passes>
+
+Record the amount of time needed for each pass and print it to standard
+error.
+
+=back
+
+=head1 EXIT STATUS
+
+B<llvm-prof> returns 1 if it cannot load the bitcode file or the profile
+information. Otherwise, it exits with zero.
+
+=head1 AUTHOR
+
+B<llvm-prof> is maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-ranlib.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-ranlib.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-ranlib.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-ranlib.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,52 @@
+=pod
+
+=head1 NAME
+
+llvm-ranlib - Generate index for LLVM archive
+
+=head1 SYNOPSIS
+
+B<llvm-ranlib> [--version] [-help] <archive-file>
+
+=head1 DESCRIPTION
+
+The B<llvm-ranlib> command is similar to the common Unix utility, C<ranlib>. It
+adds or updates the symbol table in an LLVM archive file. Note that using the
+B<llvm-ar> modifier F<s> is usually more efficient than running B<llvm-ranlib>
+which is only provided only for completness and compatibility. Unlike other
+implementations of C<ranlib>, B<llvm-ranlib> indexes LLVM bitcode files, not
+native object modules. You can list the contents of the symbol table with the
+C<llvm-nm -s> command.
+
+=head1 OPTIONS
+
+=over
+
+=item F<archive-file>
+
+Specifies the archive-file to which the symbol table is added or updated.
+
+=item F<--version>
+
+Print the version of B<llvm-ranlib> and exit without building a symbol table.
+
+=item F<-help>
+
+Print usage help for B<llvm-ranlib> and exit without building a symbol table.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<llvm-ranlib> succeeds, it will exit with 0. If an error occurs, a non-zero
+exit code will be returned.
+
+=head1 SEE ALSO
+
+L<llvm-ar|llvm-ar>, ranlib(1)
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/llvm-stress.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/llvm-stress.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/llvm-stress.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/llvm-stress.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,42 @@
+=pod
+
+=head1 NAME
+
+llvm-stress - generate random .ll files
+
+=head1 SYNOPSIS
+
+B<llvm-cov> [-gcno=filename] [-gcda=filename] [dump]
+
+=head1 DESCRIPTION
+
+The B<llvm-stress> tool is used to generate random .ll files that can be used to
+test different components of LLVM.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-o> I<filename>
+
+Specify the output filename.
+
+=item B<-size> I<size>
+
+Specify the size of the generated .ll file.
+
+=item B<-seed> I<seed>
+
+Specify the seed to be used for the randomly generated instructions.
+
+=back
+
+=head1 EXIT STATUS
+
+B<llvm-stress> returns 0.
+
+=head1 AUTHOR
+
+B<llvm-stress> is maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/FileCheck.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/FileCheck.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/FileCheck.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/FileCheck.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,356 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "FILECHECK 1"
+.TH FILECHECK 1 "2012-04-18" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+FileCheck \- Flexible pattern matching file verifier
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBFileCheck\fR \fImatch-filename\fR [\fI\-\-check\-prefix=XXX\fR] [\fI\-\-strict\-whitespace\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBFileCheck\fR reads two files (one from standard input, and one specified on the
+command line) and uses one to verify the other. This behavior is particularly
+useful for the testsuite, which wants to verify that the output of some tool
+(e.g. llc) contains the expected information (for example, a movsd from esp or
+whatever is interesting). This is similar to using grep, but it is optimized
+for matching multiple different inputs in one file in a specific order.
+.PP
+The \fImatch-filename\fR file specifies the file that contains the patterns to
+match. The file to verify is always read from standard input.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-\-check\-prefix\fR \fIprefix\fR" 4
+.IX Item "--check-prefix prefix"
+FileCheck searches the contents of \fImatch-filename\fR for patterns to match. By
+default, these patterns are prefixed with \*(L"\s-1CHECK:\s0\*(R". If you'd like to use a
+different prefix (e.g. because the same input file is checking multiple
+different tool or options), the \fB\-\-check\-prefix\fR argument allows you to specify
+a specific prefix to match.
+.IP "\fB\-\-strict\-whitespace\fR" 4
+.IX Item "--strict-whitespace"
+By default, FileCheck canonicalizes input horizontal whitespace (spaces and
+tabs) which causes it to ignore these differences (a space will match a tab).
+The \-\-strict\-whitespace argument disables this behavior.
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+Show the version number of this program.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBFileCheck\fR verifies that the file matches the expected contents, it exits
+with 0. Otherwise, if not, or if an error occurs, it will exit with a non-zero
+value.
+.SH "TUTORIAL"
+.IX Header "TUTORIAL"
+FileCheck is typically used from \s-1LLVM\s0 regression tests, being invoked on the \s-1RUN\s0
+line of the test. A simple example of using FileCheck from a \s-1RUN\s0 line looks
+like this:
+.PP
+.Vb 1
+\& ; RUN: llvm\-as < %s | llc \-march=x86\-64 | FileCheck %s
+.Ve
+.PP
+This syntax says to pipe the current file (\*(L"%s\*(R") into llvm-as, pipe that into
+llc, then pipe the output of llc into FileCheck. This means that FileCheck will
+be verifying its standard input (the llc output) against the filename argument
+specified (the original .ll file specified by \*(L"%s\*(R"). To see how this works,
+let's look at the rest of the .ll file (after the \s-1RUN\s0 line):
+.PP
+.Vb 7
+\& define void @sub1(i32* %p, i32 %v) {
+\& entry:
+\& ; CHECK: sub1:
+\& ; CHECK: subl
+\& %0 = tail call i32 @llvm.atomic.load.sub.i32.p0i32(i32* %p, i32 %v)
+\& ret void
+\& }
+\&
+\& define void @inc4(i64* %p) {
+\& entry:
+\& ; CHECK: inc4:
+\& ; CHECK: incq
+\& %0 = tail call i64 @llvm.atomic.load.add.i64.p0i64(i64* %p, i64 1)
+\& ret void
+\& }
+.Ve
+.PP
+Here you can see some \*(L"\s-1CHECK:\s0\*(R" lines specified in comments. Now you can see
+how the file is piped into llvm-as, then llc, and the machine code output is
+what we are verifying. FileCheck checks the machine code output to verify that
+it matches what the \*(L"\s-1CHECK:\s0\*(R" lines specify.
+.PP
+The syntax of the \s-1CHECK:\s0 lines is very simple: they are fixed strings that
+must occur in order. FileCheck defaults to ignoring horizontal whitespace
+differences (e.g. a space is allowed to match a tab) but otherwise, the contents
+of the \s-1CHECK:\s0 line is required to match some thing in the test file exactly.
+.PP
+One nice thing about FileCheck (compared to grep) is that it allows merging
+test cases together into logical groups. For example, because the test above
+is checking for the \*(L"sub1:\*(R" and \*(L"inc4:\*(R" labels, it will not match unless there
+is a \*(L"subl\*(R" in between those labels. If it existed somewhere else in the file,
+that would not count: \*(L"grep subl\*(R" matches if subl exists anywhere in the
+file.
+.SS "The FileCheck \-check\-prefix option"
+.IX Subsection "The FileCheck -check-prefix option"
+The FileCheck \-check\-prefix option allows multiple test configurations to be
+driven from one .ll file. This is useful in many circumstances, for example,
+testing different architectural variants with llc. Here's a simple example:
+.PP
+.Vb 4
+\& ; RUN: llvm\-as < %s | llc \-mtriple=i686\-apple\-darwin9 \-mattr=sse41 \e
+\& ; RUN: | FileCheck %s \-check\-prefix=X32>
+\& ; RUN: llvm\-as < %s | llc \-mtriple=x86_64\-apple\-darwin9 \-mattr=sse41 \e
+\& ; RUN: | FileCheck %s \-check\-prefix=X64>
+\&
+\& define <4 x i32> @pinsrd_1(i32 %s, <4 x i32> %tmp) nounwind {
+\& %tmp1 = insertelement <4 x i32>; %tmp, i32 %s, i32 1
+\& ret <4 x i32> %tmp1
+\& ; X32: pinsrd_1:
+\& ; X32: pinsrd $1, 4(%esp), %xmm0
+\&
+\& ; X64: pinsrd_1:
+\& ; X64: pinsrd $1, %edi, %xmm0
+\& }
+.Ve
+.PP
+In this case, we're testing that we get the expected code generation with
+both 32\-bit and 64\-bit code generation.
+.ie n .SS "The ""CHECK-NEXT:"" directive"
+.el .SS "The ``CHECK-NEXT:'' directive"
+.IX Subsection "The CHECK-NEXT: directive"
+Sometimes you want to match lines and would like to verify that matches
+happen on exactly consecutive lines with no other lines in between them. In
+this case, you can use \s-1CHECK:\s0 and CHECK-NEXT: directives to specify this. If
+you specified a custom check prefix, just use \*(L"<\s-1PREFIX\s0>\-NEXT:\*(R". For
+example, something like this works as you'd expect:
+.PP
+.Vb 8
+\& define void @t2(<2 x double>* %r, <2 x double>* %A, double %B) {
+\& %tmp3 = load <2 x double>* %A, align 16
+\& %tmp7 = insertelement <2 x double> undef, double %B, i32 0
+\& %tmp9 = shufflevector <2 x double> %tmp3,
+\& <2 x double> %tmp7,
+\& <2 x i32> < i32 0, i32 2 >
+\& store <2 x double> %tmp9, <2 x double>* %r, align 16
+\& ret void
+\&
+\& ; CHECK: t2:
+\& ; CHECK: movl 8(%esp), %eax
+\& ; CHECK\-NEXT: movapd (%eax), %xmm0
+\& ; CHECK\-NEXT: movhpd 12(%esp), %xmm0
+\& ; CHECK\-NEXT: movl 4(%esp), %eax
+\& ; CHECK\-NEXT: movapd %xmm0, (%eax)
+\& ; CHECK\-NEXT: ret
+\& }
+.Ve
+.PP
+CHECK-NEXT: directives reject the input unless there is exactly one newline
+between it an the previous directive. A CHECK-NEXT cannot be the first
+directive in a file.
+.ie n .SS "The ""CHECK-NOT:"" directive"
+.el .SS "The ``CHECK-NOT:'' directive"
+.IX Subsection "The CHECK-NOT: directive"
+The CHECK-NOT: directive is used to verify that a string doesn't occur
+between two matches (or before the first match, or after the last match). For
+example, to verify that a load is removed by a transformation, a test like this
+can be used:
+.PP
+.Vb 2
+\& define i8 @coerce_offset0(i32 %V, i32* %P) {
+\& store i32 %V, i32* %P
+\&
+\& %P2 = bitcast i32* %P to i8*
+\& %P3 = getelementptr i8* %P2, i32 2
+\&
+\& %A = load i8* %P3
+\& ret i8 %A
+\& ; CHECK: @coerce_offset0
+\& ; CHECK\-NOT: load
+\& ; CHECK: ret i8
+\& }
+.Ve
+.SS "FileCheck Pattern Matching Syntax"
+.IX Subsection "FileCheck Pattern Matching Syntax"
+The \s-1CHECK:\s0 and CHECK-NOT: directives both take a pattern to match. For most
+uses of FileCheck, fixed string matching is perfectly sufficient. For some
+things, a more flexible form of matching is desired. To support this, FileCheck
+allows you to specify regular expressions in matching strings, surrounded by
+double braces: \fB{{yourregex}}\fR. Because we want to use fixed string
+matching for a majority of what we do, FileCheck has been designed to support
+mixing and matching fixed string matching with regular expressions. This allows
+you to write things like this:
+.PP
+.Vb 1
+\& ; CHECK: movhpd {{[0\-9]+}}(%esp), {{%xmm[0\-7]}}
+.Ve
+.PP
+In this case, any offset from the \s-1ESP\s0 register will be allowed, and any xmm
+register will be allowed.
+.PP
+Because regular expressions are enclosed with double braces, they are
+visually distinct, and you don't need to use escape characters within the double
+braces like you would in C. In the rare case that you want to match double
+braces explicitly from the input, you can use something ugly like
+\&\fB{{[{][{]}}\fR as your pattern.
+.SS "FileCheck Variables"
+.IX Subsection "FileCheck Variables"
+It is often useful to match a pattern and then verify that it occurs again
+later in the file. For codegen tests, this can be useful to allow any register,
+but verify that that register is used consistently later. To do this, FileCheck
+allows named variables to be defined and substituted into patterns. Here is a
+simple example:
+.PP
+.Vb 3
+\& ; CHECK: test5:
+\& ; CHECK: notw [[REGISTER:%[a\-z]+]]
+\& ; CHECK: andw {{.*}}[REGISTER]]
+.Ve
+.PP
+The first check line matches a regex (\fB%[a\-z]+\fR) and captures it into
+the variable \*(L"\s-1REGISTER\s0\*(R". The second line verifies that whatever is in \s-1REGISTER\s0
+occurs later in the file after an \*(L"andw\*(R". FileCheck variable references are
+always contained in \fB[[ ]]\fR pairs, are named, and their names can be
+formed with the regex "\fB[a\-zA\-Z_][a\-zA\-Z0\-9_]*\fR". If a colon follows the
+name, then it is a definition of the variable, if not, it is a use.
+.PP
+FileCheck variables can be defined multiple times, and uses always get the
+latest value. Note that variables are all read at the start of a \*(L"\s-1CHECK\s0\*(R" line
+and are all defined at the end. This means that if you have something like
+"\fB\s-1CHECK:\s0 [[\s-1XYZ:\s0.*]]x[[\s-1XYZ\s0]]\fR", the check line will read the previous
+value of the \s-1XYZ\s0 variable and define a new one after the match is performed. If
+you need to do something like this you can probably take advantage of the fact
+that FileCheck is not actually line-oriented when it matches, this allows you to
+define two separate \s-1CHECK\s0 lines that match on the same line.
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by The \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/bugpoint.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/bugpoint.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/bugpoint.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/bugpoint.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,290 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "BUGPOINT 1"
+.TH BUGPOINT 1 "2011-04-22" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+bugpoint \- automatic test case reduction tool
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBbugpoint\fR [\fIoptions\fR] [\fIinput \s-1LLVM\s0 ll/bc files\fR] [\fI\s-1LLVM\s0 passes\fR] \fB\-\-args\fR
+\&\fIprogram arguments\fR
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBbugpoint\fR narrows down the source of problems in \s-1LLVM\s0 tools and passes. It
+can be used to debug three types of failures: optimizer crashes, miscompilations
+by optimizers, or bad native code generation (including problems in the static
+and \s-1JIT\s0 compilers). It aims to reduce large test cases to small, useful ones.
+For more information on the design and inner workings of \fBbugpoint\fR, as well as
+advice for using bugpoint, see \fIllvm/docs/Bugpoint.html\fR in the \s-1LLVM\s0
+distribution.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-\-additional\-so\fR \fIlibrary\fR" 4
+.IX Item "--additional-so library"
+Load the dynamic shared object \fIlibrary\fR into the test program whenever it is
+run. This is useful if you are debugging programs which depend on non-LLVM
+libraries (such as the X or curses libraries) to run.
+.IP "\fB\-\-append\-exit\-code\fR=\fI{true,false}\fR" 4
+.IX Item "--append-exit-code={true,false}"
+Append the test programs exit code to the output file so that a change in exit
+code is considered a test failure. Defaults to false.
+.IP "\fB\-\-args\fR \fIprogram args\fR" 4
+.IX Item "--args program args"
+Pass all arguments specified after \-args to the test program whenever it runs.
+Note that if any of the \fIprogram args\fR start with a '\-', you should use:
+.Sp
+.Vb 1
+\& bugpoint [bugpoint args] \-\-args \-\- [program args]
+.Ve
+.Sp
+The \*(L"\-\-\*(R" right after the \fB\-\-args\fR option tells \fBbugpoint\fR to consider any
+options starting with \f(CW\*(C`\-\*(C'\fR to be part of the \fB\-\-args\fR option, not as options to
+\&\fBbugpoint\fR itself.
+.IP "\fB\-\-tool\-args\fR \fItool args\fR" 4
+.IX Item "--tool-args tool args"
+Pass all arguments specified after \-\-tool\-args to the \s-1LLVM\s0 tool under test
+(\fBllc\fR, \fBlli\fR, etc.) whenever it runs. You should use this option in the
+following way:
+.Sp
+.Vb 1
+\& bugpoint [bugpoint args] \-\-tool\-args \-\- [tool args]
+.Ve
+.Sp
+The \*(L"\-\-\*(R" right after the \fB\-\-tool\-args\fR option tells \fBbugpoint\fR to consider any
+options starting with \f(CW\*(C`\-\*(C'\fR to be part of the \fB\-\-tool\-args\fR option, not as
+options to \fBbugpoint\fR itself. (See \fB\-\-args\fR, above.)
+.IP "\fB\-\-safe\-tool\-args\fR \fItool args\fR" 4
+.IX Item "--safe-tool-args tool args"
+Pass all arguments specified after \fB\-\-safe\-tool\-args\fR to the \*(L"safe\*(R" execution
+tool.
+.IP "\fB\-\-gcc\-tool\-args\fR \fIgcc tool args\fR" 4
+.IX Item "--gcc-tool-args gcc tool args"
+Pass all arguments specified after \fB\-\-gcc\-tool\-args\fR to the invocation of
+\&\fBgcc\fR.
+.IP "\fB\-\-opt\-args\fR \fIopt args\fR" 4
+.IX Item "--opt-args opt args"
+Pass all arguments specified after \fB\-\-opt\-args\fR to the invocation of \fBopt\fR.
+.IP "\fB\-\-disable\-{dce,simplifycfg}\fR" 4
+.IX Item "--disable-{dce,simplifycfg}"
+Do not run the specified passes to clean up and reduce the size of the test
+program. By default, \fBbugpoint\fR uses these passes internally when attempting to
+reduce test programs. If you're trying to find a bug in one of these passes,
+\&\fBbugpoint\fR may crash.
+.IP "\fB\-\-enable\-valgrind\fR" 4
+.IX Item "--enable-valgrind"
+Use valgrind to find faults in the optimization phase. This will allow
+bugpoint to find otherwise asymptomatic problems caused by memory
+mis-management.
+.IP "\fB\-find\-bugs\fR" 4
+.IX Item "-find-bugs"
+Continually randomize the specified passes and run them on the test program
+until a bug is found or the user kills \fBbugpoint\fR.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-\-input\fR \fIfilename\fR" 4
+.IX Item "--input filename"
+Open \fIfilename\fR and redirect the standard input of the test program, whenever
+it runs, to come from that file.
+.IP "\fB\-\-load\fR \fIplugin\fR" 4
+.IX Item "--load plugin"
+Load the dynamic object \fIplugin\fR into \fBbugpoint\fR itself. This object should
+register new optimization passes. Once loaded, the object will add new command
+line options to enable various optimizations. To see the new complete list of
+optimizations, use the \fB\-help\fR and \fB\-\-load\fR options together; for example:
+.Sp
+.Vb 1
+\& bugpoint \-\-load myNewPass.so \-help
+.Ve
+.IP "\fB\-\-mlimit\fR \fImegabytes\fR" 4
+.IX Item "--mlimit megabytes"
+Specifies an upper limit on memory usage of the optimization and codegen. Set
+to zero to disable the limit.
+.IP "\fB\-\-output\fR \fIfilename\fR" 4
+.IX Item "--output filename"
+Whenever the test program produces output on its standard output stream, it
+should match the contents of \fIfilename\fR (the \*(L"reference output\*(R"). If you
+do not use this option, \fBbugpoint\fR will attempt to generate a reference output
+by compiling the program with the \*(L"safe\*(R" backend and running it.
+.IP "\fB\-\-profile\-info\-file\fR \fIfilename\fR" 4
+.IX Item "--profile-info-file filename"
+Profile file loaded by \fB\-\-profile\-loader\fR.
+.IP "\fB\-\-run\-{int,jit,llc,cbe,custom}\fR" 4
+.IX Item "--run-{int,jit,llc,cbe,custom}"
+Whenever the test program is compiled, \fBbugpoint\fR should generate code for it
+using the specified code generator. These options allow you to choose the
+interpreter, the \s-1JIT\s0 compiler, the static native code compiler, the C
+backend, or a custom command (see \fB\-\-exec\-command\fR) respectively.
+.IP "\fB\-\-safe\-{llc,cbe,custom}\fR" 4
+.IX Item "--safe-{llc,cbe,custom}"
+When debugging a code generator, \fBbugpoint\fR should use the specified code
+generator as the \*(L"safe\*(R" code generator. This is a known-good code generator
+used to generate the \*(L"reference output\*(R" if it has not been provided, and to
+compile portions of the program that as they are excluded from the testcase.
+These options allow you to choose the
+static native code compiler, the C backend, or a custom command,
+(see \fB\-\-exec\-command\fR) respectively. The interpreter and the \s-1JIT\s0 backends
+cannot currently be used as the \*(L"safe\*(R" backends.
+.IP "\fB\-\-exec\-command\fR \fIcommand\fR" 4
+.IX Item "--exec-command command"
+This option defines the command to use with the \fB\-\-run\-custom\fR and
+\&\fB\-\-safe\-custom\fR options to execute the bitcode testcase. This can
+be useful for cross-compilation.
+.IP "\fB\-\-compile\-command\fR \fIcommand\fR" 4
+.IX Item "--compile-command command"
+This option defines the command to use with the \fB\-\-compile\-custom\fR
+option to compile the bitcode testcase. This can be useful for
+testing compiler output without running any link or execute stages. To
+generate a reduced unit test, you may add \s-1CHECK\s0 directives to the
+testcase and pass the name of an executable compile-command script in this form:
+.Sp
+.Vb 3
+\& #!/bin/sh
+\& llc "$@"
+\& not FileCheck [bugpoint input file].ll < bugpoint\-test\-program.s
+.Ve
+.Sp
+This script will \*(L"fail\*(R" as long as FileCheck passes. So the result
+will be the minimum bitcode that passes FileCheck.
+.IP "\fB\-\-safe\-path\fR \fIpath\fR" 4
+.IX Item "--safe-path path"
+This option defines the path to the command to execute with the
+\&\fB\-\-safe\-{int,jit,llc,cbe,custom}\fR
+option.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBbugpoint\fR succeeds in finding a problem, it will exit with 0. Otherwise,
+if an error occurs, it will exit with a non-zero value.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+opt
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/lit.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/lit.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/lit.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/lit.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,467 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LIT 1"
+.TH LIT 1 "2012-03-26" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+lit \- LLVM Integrated Tester
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBlit\fR [\fIoptions\fR] [\fItests\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBlit\fR is a portable tool for executing \s-1LLVM\s0 and Clang style test suites,
+summarizing their results, and providing indication of failures. \fBlit\fR is
+designed to be a lightweight testing tool with as simple a user interface as
+possible.
+.PP
+\&\fBlit\fR should be run with one or more \fItests\fR to run specified on the command
+line. Tests can be either individual test files or directories to search for
+tests (see \*(L"\s-1TEST\s0 \s-1DISCOVERY\s0\*(R").
+.PP
+Each specified test will be executed (potentially in parallel) and once all
+tests have been run \fBlit\fR will print summary information on the number of tests
+which passed or failed (see \*(L"\s-1TEST\s0 \s-1STATUS\s0 \s-1RESULTS\s0\*(R"). The \fBlit\fR program will
+execute with a non-zero exit code if any tests fail.
+.PP
+By default \fBlit\fR will use a succinct progress display and will only print
+summary information for test failures. See \*(L"\s-1OUTPUT\s0 \s-1OPTIONS\s0\*(R" for options
+controlling the \fBlit\fR progress display and output.
+.PP
+\&\fBlit\fR also includes a number of options for controlling how tests are executed
+(specific features may depend on the particular test format). See \*(L"\s-1EXECUTION\s0
+\&\s-1OPTIONS\s0\*(R" for more information.
+.PP
+Finally, \fBlit\fR also supports additional options for only running a subset of
+the options specified on the command line, see \*(L"\s-1SELECTION\s0 \s-1OPTIONS\s0\*(R" for
+more information.
+.PP
+Users interested in the \fBlit\fR architecture or designing a \fBlit\fR testing
+implementation should see \*(L"\s-1LIT\s0 \s-1INFRASTRUCTURE\s0\*(R"
+.SH "GENERAL OPTIONS"
+.IX Header "GENERAL OPTIONS"
+.IP "\fB\-h\fR, \fB\-\-help\fR" 4
+.IX Item "-h, --help"
+Show the \fBlit\fR help message.
+.IP "\fB\-j\fR \fIN\fR, \fB\-\-threads\fR=\fIN\fR" 4
+.IX Item "-j N, --threads=N"
+Run \fIN\fR tests in parallel. By default, this is automatically chosen to match
+the number of detected available CPUs.
+.IP "\fB\-\-config\-prefix\fR=\fI\s-1NAME\s0\fR" 4
+.IX Item "--config-prefix=NAME"
+Search for \fI\s-1NAME\s0.cfg\fR and \fI\s-1NAME\s0.site.cfg\fR when searching for test suites,
+instead of \fIlit.cfg\fR and \fIlit.site.cfg\fR.
+.IP "\fB\-\-param\fR \fI\s-1NAME\s0\fR, \fB\-\-param\fR \fI\s-1NAME\s0\fR=\fI\s-1VALUE\s0\fR" 4
+.IX Item "--param NAME, --param NAME=VALUE"
+Add a user defined parameter \fI\s-1NAME\s0\fR with the given \fI\s-1VALUE\s0\fR (or the empty
+string if not given). The meaning and use of these parameters is test suite
+dependent.
+.SH "OUTPUT OPTIONS"
+.IX Header "OUTPUT OPTIONS"
+.IP "\fB\-q\fR, \fB\-\-quiet\fR" 4
+.IX Item "-q, --quiet"
+Suppress any output except for test failures.
+.IP "\fB\-s\fR, \fB\-\-succinct\fR" 4
+.IX Item "-s, --succinct"
+Show less output, for example don't show information on tests that pass.
+.IP "\fB\-v\fR, \fB\-\-verbose\fR" 4
+.IX Item "-v, --verbose"
+Show more information on test failures, for example the entire test output
+instead of just the test result.
+.IP "\fB\-\-no\-progress\-bar\fR" 4
+.IX Item "--no-progress-bar"
+Do not use curses based progress bar.
+.SH "EXECUTION OPTIONS"
+.IX Header "EXECUTION OPTIONS"
+.IP "\fB\-\-path\fR=\fI\s-1PATH\s0\fR" 4
+.IX Item "--path=PATH"
+Specify an addition \fI\s-1PATH\s0\fR to use when searching for executables in tests.
+.IP "\fB\-\-vg\fR" 4
+.IX Item "--vg"
+Run individual tests under valgrind (using the memcheck tool). The
+\&\fI\-\-error\-exitcode\fR argument for valgrind is used so that valgrind failures will
+cause the program to exit with a non-zero status.
+.IP "\fB\-\-vg\-arg\fR=\fI\s-1ARG\s0\fR" 4
+.IX Item "--vg-arg=ARG"
+When \fI\-\-vg\fR is used, specify an additional argument to pass to valgrind itself.
+.IP "\fB\-\-time\-tests\fR" 4
+.IX Item "--time-tests"
+Track the wall time individual tests take to execute and includes the results in
+the summary output. This is useful for determining which tests in a test suite
+take the most time to execute. Note that this option is most useful with \fI\-j
+1\fR.
+.SH "SELECTION OPTIONS"
+.IX Header "SELECTION OPTIONS"
+.IP "\fB\-\-max\-tests\fR=\fIN\fR" 4
+.IX Item "--max-tests=N"
+Run at most \fIN\fR tests and then terminate.
+.IP "\fB\-\-max\-time\fR=\fIN\fR" 4
+.IX Item "--max-time=N"
+Spend at most \fIN\fR seconds (approximately) running tests and then terminate.
+.IP "\fB\-\-shuffle\fR" 4
+.IX Item "--shuffle"
+Run the tests in a random order.
+.SH "ADDITIONAL OPTIONS"
+.IX Header "ADDITIONAL OPTIONS"
+.IP "\fB\-\-debug\fR" 4
+.IX Item "--debug"
+Run \fBlit\fR in debug mode, for debugging configuration issues and \fBlit\fR itself.
+.IP "\fB\-\-show\-suites\fR" 4
+.IX Item "--show-suites"
+List the discovered test suites as part of the standard output.
+.IP "\fB\-\-no\-tcl\-as\-sh\fR" 4
+.IX Item "--no-tcl-as-sh"
+Run Tcl scripts internally (instead of converting to shell scripts).
+.IP "\fB\-\-repeat\fR=\fIN\fR" 4
+.IX Item "--repeat=N"
+Run each test \fIN\fR times. Currently this is primarily useful for timing tests,
+other results are not collated in any reasonable fashion.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+\&\fBlit\fR will exit with an exit code of 1 if there are any \s-1FAIL\s0 or \s-1XPASS\s0
+results. Otherwise, it will exit with the status 0. Other exit codes are used
+for non-test related failures (for example a user error or an internal program
+error).
+.SH "TEST DISCOVERY"
+.IX Header "TEST DISCOVERY"
+The inputs passed to \fBlit\fR can be either individual tests, or entire
+directories or hierarchies of tests to run. When \fBlit\fR starts up, the first
+thing it does is convert the inputs into a complete list of tests to run as part
+of \fItest discovery\fR.
+.PP
+In the \fBlit\fR model, every test must exist inside some \fItest suite\fR. \fBlit\fR
+resolves the inputs specified on the command line to test suites by searching
+upwards from the input path until it finds a \fIlit.cfg\fR or \fIlit.site.cfg\fR
+file. These files serve as both a marker of test suites and as configuration
+files which \fBlit\fR loads in order to understand how to find and run the tests
+inside the test suite.
+.PP
+Once \fBlit\fR has mapped the inputs into test suites it traverses the list of
+inputs adding tests for individual files and recursively searching for tests in
+directories.
+.PP
+This behavior makes it easy to specify a subset of tests to run, while still
+allowing the test suite configuration to control exactly how tests are
+interpreted. In addition, \fBlit\fR always identifies tests by the test suite they
+are in, and their relative path inside the test suite. For appropriately
+configured projects, this allows \fBlit\fR to provide convenient and flexible
+support for out-of-tree builds.
+.SH "TEST STATUS RESULTS"
+.IX Header "TEST STATUS RESULTS"
+Each test ultimately produces one of the following six results:
+.IP "\fB\s-1PASS\s0\fR" 4
+.IX Item "PASS"
+The test succeeded.
+.IP "\fB\s-1XFAIL\s0\fR" 4
+.IX Item "XFAIL"
+The test failed, but that is expected. This is used for test formats which allow
+specifying that a test does not currently work, but wish to leave it in the test
+suite.
+.IP "\fB\s-1XPASS\s0\fR" 4
+.IX Item "XPASS"
+The test succeeded, but it was expected to fail. This is used for tests which
+were specified as expected to fail, but are now succeeding (generally because
+the feature they test was broken and has been fixed).
+.IP "\fB\s-1FAIL\s0\fR" 4
+.IX Item "FAIL"
+The test failed.
+.IP "\fB\s-1UNRESOLVED\s0\fR" 4
+.IX Item "UNRESOLVED"
+The test result could not be determined. For example, this occurs when the test
+could not be run, the test itself is invalid, or the test was interrupted.
+.IP "\fB\s-1UNSUPPORTED\s0\fR" 4
+.IX Item "UNSUPPORTED"
+The test is not supported in this environment. This is used by test formats
+which can report unsupported tests.
+.PP
+Depending on the test format tests may produce additional information about
+their status (generally only for failures). See the Output
+section for more information.
+.SH "LIT INFRASTRUCTURE"
+.IX Header "LIT INFRASTRUCTURE"
+This section describes the \fBlit\fR testing architecture for users interested in
+creating a new \fBlit\fR testing implementation, or extending an existing one.
+.PP
+\&\fBlit\fR proper is primarily an infrastructure for discovering and running
+arbitrary tests, and to expose a single convenient interface to these
+tests. \fBlit\fR itself doesn't know how to run tests, rather this logic is
+defined by \fItest suites\fR.
+.SS "\s-1TEST\s0 \s-1SUITES\s0"
+.IX Subsection "TEST SUITES"
+As described in \*(L"\s-1TEST\s0 \s-1DISCOVERY\s0\*(R", tests are always located inside a \fItest
+suite\fR. Test suites serve to define the format of the tests they contain, the
+logic for finding those tests, and any additional information to run the tests.
+.PP
+\&\fBlit\fR identifies test suites as directories containing \fIlit.cfg\fR or
+\&\fIlit.site.cfg\fR files (see also \fB\-\-config\-prefix\fR). Test suites are initially
+discovered by recursively searching up the directory hierarchy for all the input
+files passed on the command line. You can use \fB\-\-show\-suites\fR to display the
+discovered test suites at startup.
+.PP
+Once a test suite is discovered, its config file is loaded. Config files
+themselves are Python modules which will be executed. When the config file is
+executed, two important global variables are predefined:
+.IP "\fBlit\fR" 4
+.IX Item "lit"
+The global \fBlit\fR configuration object (a \fILitConfig\fR instance), which defines
+the builtin test formats, global configuration parameters, and other helper
+routines for implementing test configurations.
+.IP "\fBconfig\fR" 4
+.IX Item "config"
+This is the config object (a \fITestingConfig\fR instance) for the test suite,
+which the config file is expected to populate. The following variables are also
+available on the \fIconfig\fR object, some of which must be set by the config and
+others are optional or predefined:
+.Sp
+\&\fBname\fR \fI[required]\fR The name of the test suite, for use in reports and
+diagnostics.
+.Sp
+\&\fBtest_format\fR \fI[required]\fR The test format object which will be used to
+discover and run tests in the test suite. Generally this will be a builtin test
+format available from the \fIlit.formats\fR module.
+.Sp
+\&\fBtest_src_root\fR The filesystem path to the test suite root. For out-of-dir
+builds this is the directory that will be scanned for tests.
+.Sp
+\&\fBtest_exec_root\fR For out-of-dir builds, the path to the test suite root inside
+the object directory. This is where tests will be run and temporary output files
+placed.
+.Sp
+\&\fBenvironment\fR A dictionary representing the environment to use when executing
+tests in the suite.
+.Sp
+\&\fBsuffixes\fR For \fBlit\fR test formats which scan directories for tests, this
+variable is a list of suffixes to identify test files. Used by: \fIShTest\fR,
+\&\fITclTest\fR.
+.Sp
+\&\fBsubstitutions\fR For \fBlit\fR test formats which substitute variables into a test
+script, the list of substitutions to perform. Used by: \fIShTest\fR, \fITclTest\fR.
+.Sp
+\&\fBunsupported\fR Mark an unsupported directory, all tests within it will be
+reported as unsupported. Used by: \fIShTest\fR, \fITclTest\fR.
+.Sp
+\&\fBparent\fR The parent configuration, this is the config object for the directory
+containing the test suite, or None.
+.Sp
+\&\fBroot\fR The root configuration. This is the top-most \fBlit\fR configuration in
+the project.
+.Sp
+\&\fBon_clone\fR The config is actually cloned for every subdirectory inside a test
+suite, to allow local configuration on a per-directory basis. The \fIon_clone\fR
+variable can be set to a Python function which will be called whenever a
+configuration is cloned (for a subdirectory). The function should takes three
+arguments: (1) the parent configuration, (2) the new configuration (which the
+\&\fIon_clone\fR function will generally modify), and (3) the test path to the new
+directory being scanned.
+.SS "\s-1TEST\s0 \s-1DISCOVERY\s0"
+.IX Subsection "TEST DISCOVERY"
+Once test suites are located, \fBlit\fR recursively traverses the source directory
+(following \fItest_src_root\fR) looking for tests. When \fBlit\fR enters a
+sub-directory, it first checks to see if a nested test suite is defined in that
+directory. If so, it loads that test suite recursively, otherwise it
+instantiates a local test config for the directory (see \*(L"\s-1LOCAL\s0 \s-1CONFIGURATION\s0
+\&\s-1FILES\s0\*(R").
+.PP
+Tests are identified by the test suite they are contained within, and the
+relative path inside that suite. Note that the relative path may not refer to an
+actual file on disk; some test formats (such as \fIGoogleTest\fR) define \*(L"virtual
+tests\*(R" which have a path that contains both the path to the actual test file and
+a subpath to identify the virtual test.
+.SS "\s-1LOCAL\s0 \s-1CONFIGURATION\s0 \s-1FILES\s0"
+.IX Subsection "LOCAL CONFIGURATION FILES"
+When \fBlit\fR loads a subdirectory in a test suite, it instantiates a local test
+configuration by cloning the configuration for the parent direction \*(-- the root
+of this configuration chain will always be a test suite. Once the test
+configuration is cloned \fBlit\fR checks for a \fIlit.local.cfg\fR file in the
+subdirectory. If present, this file will be loaded and can be used to specialize
+the configuration for each individual directory. This facility can be used to
+define subdirectories of optional tests, or to change other configuration
+parameters \*(-- for example, to change the test format, or the suffixes which
+identify test files.
+.SS "\s-1TEST\s0 \s-1RUN\s0 \s-1OUTPUT\s0 \s-1FORMAT\s0"
+.IX Subsection "TEST RUN OUTPUT FORMAT"
+The b<lit> output for a test run conforms to the following schema, in both short
+and verbose modes (although in short mode no \s-1PASS\s0 lines will be shown). This
+schema has been chosen to be relatively easy to reliably parse by a machine (for
+example in buildbot log scraping), and for other tools to generate.
+.PP
+Each test result is expected to appear on a line that matches:
+.PP
+<result code>: <test name> (<progress info>)
+.PP
+where <result\-code> is a standard test result such as \s-1PASS\s0, \s-1FAIL\s0, \s-1XFAIL\s0, \s-1XPASS\s0,
+\&\s-1UNRESOLVED\s0, or \s-1UNSUPPORTED\s0. The performance result codes of \s-1IMPROVED\s0 and
+\&\s-1REGRESSED\s0 are also allowed.
+.PP
+The <test name> field can consist of an arbitrary string containing no newline.
+.PP
+The <progress info> field can be used to report progress information such as
+(1/300) or can be empty, but even when empty the parentheses are required.
+.PP
+Each test result may include additional (multiline) log information in the
+following format.
+.PP
+<log delineator> \s-1TEST\s0 '(<test name>)' <trailing delineator>
+\&... log message ...
+<log delineator>
+.PP
+where <test name> should be the name of a preceeding reported test, <log
+delineator> is a string of '*' characters \fIat least\fR four characters long (the
+recommended length is 20), and <trailing delineator> is an arbitrary (unparsed)
+string.
+.PP
+The following is an example of a test run output which consists of four tests A,
+B, C, and D, and a log message for the failing test C.
+.PP
+\fIExample Test Run Output Listing\fR
+.IX Subsection "Example Test Run Output Listing"
+.PP
+\&\s-1PASS:\s0 A (1 of 4)
+\&\s-1PASS:\s0 B (2 of 4)
+\&\s-1FAIL:\s0 C (3 of 4)
+******************** \s-1TEST\s0 'C' \s-1FAILED\s0 ********************
+Test 'C' failed as a result of exit code 1.
+********************
+\&\s-1PASS:\s0 D (4 of 4)
+.SS "\s-1LIT\s0 \s-1EXAMPLE\s0 \s-1TESTS\s0"
+.IX Subsection "LIT EXAMPLE TESTS"
+The \fBlit\fR distribution contains several example implementations of test suites
+in the \fIExampleTests\fR directory.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIvalgrind\fR\|(1)
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+Written by Daniel Dunbar and maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
+.SH "POD ERRORS"
+.IX Header "POD ERRORS"
+Hey! \fBThe above document had some coding errors, which are explained below:\fR
+.IP "Around line 389:" 4
+.IX Item "Around line 389:"
+=back without =over
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llc.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llc.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llc.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llc.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,284 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLC 1"
+.TH LLC 1 "2012-03-29" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llc \- LLVM static compiler
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllc\fR [\fIoptions\fR] [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllc\fR command compiles \s-1LLVM\s0 source inputs into assembly language for a
+specified architecture. The assembly language output can then be passed through
+a native assembler and linker to generate a native executable.
+.PP
+The choice of architecture for the output assembly code is automatically
+determined from the input file, unless the \fB\-march\fR option is used to override
+the default.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+If \fIfilename\fR is \- or omitted, \fBllc\fR reads from standard input. Otherwise, it
+will from \fIfilename\fR. Inputs can be in either the \s-1LLVM\s0 assembly language
+format (.ll) or the \s-1LLVM\s0 bitcode format (.bc).
+.PP
+If the \fB\-o\fR option is omitted, then \fBllc\fR will send its output to standard
+output if the input is from standard input. If the \fB\-o\fR option specifies \-,
+then the output will also be sent to standard output.
+.PP
+If no \fB\-o\fR option is specified and an input file other than \- is specified,
+then \fBllc\fR creates the output filename by taking the input filename,
+removing any existing \fI.bc\fR extension, and adding a \fI.s\fR suffix.
+.PP
+Other \fBllc\fR options are as follows:
+.SS "End-user Options"
+.IX Subsection "End-user Options"
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-O\fR=\fIuint\fR" 4
+.IX Item "-O=uint"
+Generate code at different optimization levels. These correspond to the \fI\-O0\fR,
+\&\fI\-O1\fR, \fI\-O2\fR, and \fI\-O3\fR optimization levels used by \fBllvm-gcc\fR and
+\&\fBclang\fR.
+.IP "\fB\-mtriple\fR=\fItarget triple\fR" 4
+.IX Item "-mtriple=target triple"
+Override the target triple specified in the input file with the specified
+string.
+.IP "\fB\-march\fR=\fIarch\fR" 4
+.IX Item "-march=arch"
+Specify the architecture for which to generate assembly, overriding the target
+encoded in the input file. See the output of \fBllc \-help\fR for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.
+.IP "\fB\-mcpu\fR=\fIcpuname\fR" 4
+.IX Item "-mcpu=cpuname"
+Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+\&\fBllvm-as < /dev/null | llc \-march=xyz \-mcpu=help\fR
+.IP "\fB\-mattr\fR=\fIa1,+a2,\-a3,...\fR" 4
+.IX Item "-mattr=a1,+a2,-a3,..."
+Override or control specific attributes of the target, such as whether \s-1SIMD\s0
+operations are enabled or not. The default set of attributes is set by the
+current \s-1CPU\s0. For a list of available attributes, use:
+\&\fBllvm-as < /dev/null | llc \-march=xyz \-mattr=help\fR
+.IP "\fB\-\-disable\-fp\-elim\fR" 4
+.IX Item "--disable-fp-elim"
+Disable frame pointer elimination optimization.
+.IP "\fB\-\-disable\-excess\-fp\-precision\fR" 4
+.IX Item "--disable-excess-fp-precision"
+Disable optimizations that may produce excess precision for floating point.
+Note that this option can dramatically slow down code on some systems
+(e.g. X86).
+.IP "\fB\-\-enable\-no\-infs\-fp\-math\fR" 4
+.IX Item "--enable-no-infs-fp-math"
+Enable optimizations that assume no Inf values.
+.IP "\fB\-\-enable\-no\-nans\-fp\-math\fR" 4
+.IX Item "--enable-no-nans-fp-math"
+Enable optimizations that assume no \s-1NAN\s0 values.
+.IP "\fB\-\-enable\-unsafe\-fp\-math\fR" 4
+.IX Item "--enable-unsafe-fp-math"
+Enable optimizations that make unsafe assumptions about \s-1IEEE\s0 math (e.g. that
+addition is associative) or may not work for all input ranges. These
+optimizations allow the code generator to make use of some instructions which
+would otherwise not be usable (such as fsin on X86).
+.IP "\fB\-\-enable\-correct\-eh\-support\fR" 4
+.IX Item "--enable-correct-eh-support"
+Instruct the \fBlowerinvoke\fR pass to insert code for correct exception handling
+support. This is expensive and is by default omitted for efficiency.
+.IP "\fB\-\-stats\fR" 4
+.IX Item "--stats"
+Print statistics recorded by code-generation passes.
+.IP "\fB\-\-time\-passes\fR" 4
+.IX Item "--time-passes"
+Record the amount of time needed for each pass and print a report to standard
+error.
+.IP "\fB\-\-load\fR=\fIdso_path\fR" 4
+.IX Item "--load=dso_path"
+Dynamically load \fIdso_path\fR (a path to a dynamically shared object) that
+implements an \s-1LLVM\s0 target. This will permit the target name to be used with the
+\&\fB\-march\fR option so that code can be generated for that target.
+.SS "Tuning/Configuration Options"
+.IX Subsection "Tuning/Configuration Options"
+.IP "\fB\-\-print\-machineinstrs\fR" 4
+.IX Item "--print-machineinstrs"
+Print generated machine code between compilation phases (useful for debugging).
+.IP "\fB\-\-regalloc\fR=\fIallocator\fR" 4
+.IX Item "--regalloc=allocator"
+Specify the register allocator to use. The default \fIallocator\fR is \fIlocal\fR.
+Valid register allocators are:
+.RS 4
+.IP "\fIsimple\fR" 4
+.IX Item "simple"
+Very simple \*(L"always spill\*(R" register allocator
+.IP "\fIlocal\fR" 4
+.IX Item "local"
+Local register allocator
+.IP "\fIlinearscan\fR" 4
+.IX Item "linearscan"
+Linear scan global register allocator
+.IP "\fIiterativescan\fR" 4
+.IX Item "iterativescan"
+Iterative scan global register allocator
+.RE
+.RS 4
+.RE
+.IP "\fB\-\-spiller\fR=\fIspiller\fR" 4
+.IX Item "--spiller=spiller"
+Specify the spiller to use for register allocators that support it. Currently
+this option is used only by the linear scan register allocator. The default
+\&\fIspiller\fR is \fIlocal\fR. Valid spillers are:
+.RS 4
+.IP "\fIsimple\fR" 4
+.IX Item "simple"
+Simple spiller
+.IP "\fIlocal\fR" 4
+.IX Item "local"
+Local spiller
+.RE
+.RS 4
+.RE
+.SS "Intel IA\-32\-specific Options"
+.IX Subsection "Intel IA-32-specific Options"
+.IP "\fB\-\-x86\-asm\-syntax=att|intel\fR" 4
+.IX Item "--x86-asm-syntax=att|intel"
+Specify whether to emit assembly code in \s-1AT&T\s0 syntax (the default) or intel
+syntax.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllc\fR succeeds, it will exit with 0. Otherwise, if an error occurs,
+it will exit with a non-zero value.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+lli
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/lli.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/lli.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/lli.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/lli.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,309 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLI 1"
+.TH LLI 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+lli \- directly execute programs from LLVM bitcode
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBlli\fR [\fIoptions\fR] [\fIfilename\fR] [\fIprogram args\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBlli\fR directly executes programs in \s-1LLVM\s0 bitcode format. It takes a program
+in \s-1LLVM\s0 bitcode format and executes it using a just-in-time compiler, if one is
+available for the current architecture, or an interpreter. \fBlli\fR takes all of
+the same code generator options as llc, but they are only effective when
+\&\fBlli\fR is using the just-in-time compiler.
+.PP
+If \fIfilename\fR is not specified, then \fBlli\fR reads the \s-1LLVM\s0 bitcode for the
+program from standard input.
+.PP
+The optional \fIargs\fR specified on the command line are passed to the program as
+arguments.
+.SH "GENERAL OPTIONS"
+.IX Header "GENERAL OPTIONS"
+.IP "\fB\-fake\-argv0\fR=\fIexecutable\fR" 4
+.IX Item "-fake-argv0=executable"
+Override the \f(CW\*(C`argv[0]\*(C'\fR value passed into the executing program.
+.IP "\fB\-force\-interpreter\fR=\fI{false,true}\fR" 4
+.IX Item "-force-interpreter={false,true}"
+If set to true, use the interpreter even if a just-in-time compiler is available
+for this architecture. Defaults to false.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-load\fR=\fIpuginfilename\fR" 4
+.IX Item "-load=puginfilename"
+Causes \fBlli\fR to load the plugin (shared object) named \fIpluginfilename\fR and use
+it for optimization.
+.IP "\fB\-stats\fR" 4
+.IX Item "-stats"
+Print statistics from the code-generation passes. This is only meaningful for
+the just-in-time compiler, at present.
+.IP "\fB\-time\-passes\fR" 4
+.IX Item "-time-passes"
+Record the amount of time needed for each code-generation pass and print it to
+standard error.
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+Print out the version of \fBlli\fR and exit without doing anything else.
+.SH "TARGET OPTIONS"
+.IX Header "TARGET OPTIONS"
+.IP "\fB\-mtriple\fR=\fItarget triple\fR" 4
+.IX Item "-mtriple=target triple"
+Override the target triple specified in the input bitcode file with the
+specified string. This may result in a crash if you pick an
+architecture which is not compatible with the current system.
+.IP "\fB\-march\fR=\fIarch\fR" 4
+.IX Item "-march=arch"
+Specify the architecture for which to generate assembly, overriding the target
+encoded in the bitcode file. See the output of \fBllc \-help\fR for a list of
+valid architectures. By default this is inferred from the target triple or
+autodetected to the current architecture.
+.IP "\fB\-mcpu\fR=\fIcpuname\fR" 4
+.IX Item "-mcpu=cpuname"
+Specify a specific chip in the current architecture to generate code for.
+By default this is inferred from the target triple and autodetected to
+the current architecture. For a list of available CPUs, use:
+\&\fBllvm-as < /dev/null | llc \-march=xyz \-mcpu=help\fR
+.IP "\fB\-mattr\fR=\fIa1,+a2,\-a3,...\fR" 4
+.IX Item "-mattr=a1,+a2,-a3,..."
+Override or control specific attributes of the target, such as whether \s-1SIMD\s0
+operations are enabled or not. The default set of attributes is set by the
+current \s-1CPU\s0. For a list of available attributes, use:
+\&\fBllvm-as < /dev/null | llc \-march=xyz \-mattr=help\fR
+.SH "FLOATING POINT OPTIONS"
+.IX Header "FLOATING POINT OPTIONS"
+.IP "\fB\-disable\-excess\-fp\-precision\fR" 4
+.IX Item "-disable-excess-fp-precision"
+Disable optimizations that may increase floating point precision.
+.IP "\fB\-enable\-no\-infs\-fp\-math\fR" 4
+.IX Item "-enable-no-infs-fp-math"
+Enable optimizations that assume no Inf values.
+.IP "\fB\-enable\-no\-nans\-fp\-math\fR" 4
+.IX Item "-enable-no-nans-fp-math"
+Enable optimizations that assume no \s-1NAN\s0 values.
+.IP "\fB\-enable\-unsafe\-fp\-math\fR" 4
+.IX Item "-enable-unsafe-fp-math"
+Causes \fBlli\fR to enable optimizations that may decrease floating point
+precision.
+.IP "\fB\-soft\-float\fR" 4
+.IX Item "-soft-float"
+Causes \fBlli\fR to generate software floating point library calls instead of
+equivalent hardware instructions.
+.SH "CODE GENERATION OPTIONS"
+.IX Header "CODE GENERATION OPTIONS"
+.IP "\fB\-code\-model\fR=\fImodel\fR" 4
+.IX Item "-code-model=model"
+Choose the code model from:
+.Sp
+.Vb 5
+\& default: Target default code model
+\& small: Small code model
+\& kernel: Kernel code model
+\& medium: Medium code model
+\& large: Large code model
+.Ve
+.IP "\fB\-disable\-post\-RA\-scheduler\fR" 4
+.IX Item "-disable-post-RA-scheduler"
+Disable scheduling after register allocation.
+.IP "\fB\-disable\-spill\-fusing\fR" 4
+.IX Item "-disable-spill-fusing"
+Disable fusing of spill code into instructions.
+.IP "\fB\-enable\-correct\-eh\-support\fR" 4
+.IX Item "-enable-correct-eh-support"
+Make the \-lowerinvoke pass insert expensive, but correct, \s-1EH\s0 code.
+.IP "\fB\-jit\-enable\-eh\fR" 4
+.IX Item "-jit-enable-eh"
+Exception handling should be enabled in the just-in-time compiler.
+.IP "\fB\-join\-liveintervals\fR" 4
+.IX Item "-join-liveintervals"
+Coalesce copies (default=true).
+.IP "\fB\-nozero\-initialized\-in\-bss\fR Don't place zero-initialized symbols into the \s-1BSS\s0 section." 4
+.IX Item "-nozero-initialized-in-bss Don't place zero-initialized symbols into the BSS section."
+.PD 0
+.IP "\fB\-pre\-RA\-sched\fR=\fIscheduler\fR" 4
+.IX Item "-pre-RA-sched=scheduler"
+.PD
+Instruction schedulers available (before register allocation):
+.Sp
+.Vb 7
+\& =default: Best scheduler for the target
+\& =none: No scheduling: breadth first sequencing
+\& =simple: Simple two pass scheduling: minimize critical path and maximize processor utilization
+\& =simple\-noitin: Simple two pass scheduling: Same as simple except using generic latency
+\& =list\-burr: Bottom\-up register reduction list scheduling
+\& =list\-tdrr: Top\-down register reduction list scheduling
+\& =list\-td: Top\-down list scheduler \-print\-machineinstrs \- Print generated machine code
+.Ve
+.IP "\fB\-regalloc\fR=\fIallocator\fR" 4
+.IX Item "-regalloc=allocator"
+Register allocator to use (default=linearscan)
+.Sp
+.Vb 3
+\& =bigblock: Big\-block register allocator
+\& =linearscan: linear scan register allocator =local \- local register allocator
+\& =simple: simple register allocator
+.Ve
+.IP "\fB\-relocation\-model\fR=\fImodel\fR" 4
+.IX Item "-relocation-model=model"
+Choose relocation model from:
+.Sp
+.Vb 3
+\& =default: Target default relocation model
+\& =static: Non\-relocatable code =pic \- Fully relocatable, position independent code
+\& =dynamic\-no\-pic: Relocatable external references, non\-relocatable code
+.Ve
+.IP "\fB\-spiller\fR" 4
+.IX Item "-spiller"
+Spiller to use (default=local)
+.Sp
+.Vb 2
+\& =simple: simple spiller
+\& =local: local spiller
+.Ve
+.IP "\fB\-x86\-asm\-syntax\fR=\fIsyntax\fR" 4
+.IX Item "-x86-asm-syntax=syntax"
+Choose style of code to emit from X86 backend:
+.Sp
+.Vb 2
+\& =att: Emit AT&T\-style assembly
+\& =intel: Emit Intel\-style assembly
+.Ve
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBlli\fR fails to load the program, it will exit with an exit code of 1.
+Otherwise, it will return the exit code of the program it executes.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llc
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ar.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ar.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ar.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ar.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,460 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-AR 1"
+.TH LLVM-AR 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-ar \- LLVM archiver
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-ar\fR [\-]{dmpqrtx}[Rabfikouz] [relpos] [count] <archive> [files...]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-ar\fR command is similar to the common Unix utility, \f(CW\*(C`ar\*(C'\fR. It
+archives several files together into a single file. The intent for this is
+to produce archive libraries by \s-1LLVM\s0 bitcode that can be linked into an
+\&\s-1LLVM\s0 program. However, the archive can contain any kind of file. By default,
+\&\fBllvm-ar\fR generates a symbol table that makes linking faster because
+only the symbol table needs to be consulted, not each individual file member
+of the archive.
+.PP
+The \fBllvm-ar\fR command can be used to \fIread\fR both \s-1SVR4\s0 and \s-1BSD\s0 style archive
+files. However, it cannot be used to write them. While the \fBllvm-ar\fR command
+produces files that are \fIalmost\fR identical to the format used by other \f(CW\*(C`ar\*(C'\fR
+implementations, it has two significant departures in order to make the
+archive appropriate for \s-1LLVM\s0. The first departure is that \fBllvm-ar\fR only
+uses \s-1BSD4\s0.4 style long path names (stored immediately after the header) and
+never contains a string table for long names. The second departure is that the
+symbol table is formated for efficient construction of an in-memory data
+structure that permits rapid (red-black tree) lookups. Consequently, archives
+produced with \fBllvm-ar\fR usually won't be readable or editable with any
+\&\f(CW\*(C`ar\*(C'\fR implementation or useful for linking. Using the \f(CW\*(C`f\*(C'\fR modifier to flatten
+file names will make the archive readable by other \f(CW\*(C`ar\*(C'\fR implementations
+but not for linking because the symbol table format for \s-1LLVM\s0 is unique. If an
+\&\s-1SVR4\s0 or \s-1BSD\s0 style archive is used with the \f(CW\*(C`r\*(C'\fR (replace) or \f(CW\*(C`q\*(C'\fR (quick
+update) operations, the archive will be reconstructed in \s-1LLVM\s0 format. This
+means that the string table will be dropped (in deference to \s-1BSD\s0 4.4 long names)
+and an \s-1LLVM\s0 symbol table will be added (by default). The system symbol table
+will be retained.
+.PP
+Here's where \fBllvm-ar\fR departs from previous \f(CW\*(C`ar\*(C'\fR implementations:
+.IP "\fISymbol Table\fR" 4
+.IX Item "Symbol Table"
+Since \fBllvm-ar\fR is intended to archive bitcode files, the symbol table
+won't make much sense to anything but \s-1LLVM\s0. Consequently, the symbol table's
+format has been simplified. It consists simply of a sequence of pairs
+of a file member index number as an \s-1LSB\s0 4byte integer and a null-terminated
+string.
+.IP "\fILong Paths\fR" 4
+.IX Item "Long Paths"
+Some \f(CW\*(C`ar\*(C'\fR implementations (\s-1SVR4\s0) use a separate file member to record long
+path names (> 15 characters). \fBllvm-ar\fR takes the \s-1BSD\s0 4.4 and Mac \s-1OS\s0 X
+approach which is to simply store the full path name immediately preceding
+the data for the file. The path name is null terminated and may contain the
+slash (/) character.
+.IP "\fICompression\fR" 4
+.IX Item "Compression"
+\&\fBllvm-ar\fR can compress the members of an archive to save space. The
+compression used depends on what's available on the platform and what choices
+the \s-1LLVM\s0 Compressor utility makes. It generally favors bzip2 but will select
+between \*(L"no compression\*(R" or bzip2 depending on what makes sense for the
+file's content.
+.IP "\fIDirectory Recursion\fR" 4
+.IX Item "Directory Recursion"
+Most \f(CW\*(C`ar\*(C'\fR implementations do not recurse through directories but simply
+ignore directories if they are presented to the program in the \fIfiles\fR
+option. \fBllvm-ar\fR, however, can recurse through directory structures and
+add all the files under a directory, if requested.
+.IP "\fI\s-1TOC\s0 Verbose Output\fR" 4
+.IX Item "TOC Verbose Output"
+When \fBllvm-ar\fR prints out the verbose table of contents (\f(CW\*(C`tv\*(C'\fR option), it
+precedes the usual output with a character indicating the basic kind of
+content in the file. A blank means the file is a regular file. A 'Z' means
+the file is compressed. A 'B' means the file is an \s-1LLVM\s0 bitcode file. An
+\&'S' means the file is the symbol table.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+The options to \fBllvm-ar\fR are compatible with other \f(CW\*(C`ar\*(C'\fR implementations.
+However, there are a few modifiers (\fIzR\fR) that are not found in other
+\&\f(CW\*(C`ar\*(C'\fRs. The options to \fBllvm-ar\fR specify a single basic operation to
+perform on the archive, a variety of modifiers for that operation, the
+name of the archive file, and an optional list of file names. These options
+are used to determine how \fBllvm-ar\fR should process the archive file.
+.PP
+The Operations and Modifiers are explained in the sections below. The minimal
+set of options is at least one operator and the name of the archive. Typically
+archive files end with a \f(CW\*(C`.a\*(C'\fR suffix, but this is not required. Following
+the \fIarchive-name\fR comes a list of \fIfiles\fR that indicate the specific members
+of the archive to operate on. If the \fIfiles\fR option is not specified, it
+generally means either \*(L"none\*(R" or \*(L"all\*(R" members, depending on the operation.
+.SS "Operations"
+.IX Subsection "Operations"
+.IP "d" 4
+.IX Item "d"
+Delete files from the archive. No modifiers are applicable to this operation.
+The \fIfiles\fR options specify which members should be removed from the
+archive. It is not an error if a specified file does not appear in the archive.
+If no \fIfiles\fR are specified, the archive is not modified.
+.IP "m[abi]" 4
+.IX Item "m[abi]"
+Move files from one location in the archive to another. The \fIa\fR, \fIb\fR, and
+\&\fIi\fR modifiers apply to this operation. The \fIfiles\fR will all be moved
+to the location given by the modifiers. If no modifiers are used, the files
+will be moved to the end of the archive. If no \fIfiles\fR are specified, the
+archive is not modified.
+.IP "p[k]" 4
+.IX Item "p[k]"
+Print files to the standard output. The \fIk\fR modifier applies to this
+operation. This operation simply prints the \fIfiles\fR indicated to the
+standard output. If no \fIfiles\fR are specified, the entire archive is printed.
+Printing bitcode files is ill-advised as they might confuse your terminal
+settings. The \fIp\fR operation never modifies the archive.
+.IP "q[Rfz]" 4
+.IX Item "q[Rfz]"
+Quickly append files to the end of the archive. The \fIR\fR, \fIf\fR, and \fIz\fR
+modifiers apply to this operation. This operation quickly adds the
+\&\fIfiles\fR to the archive without checking for duplicates that should be
+removed first. If no \fIfiles\fR are specified, the archive is not modified.
+Because of the way that \fBllvm-ar\fR constructs the archive file, its dubious
+whether the \fIq\fR operation is any faster than the \fIr\fR operation.
+.IP "r[Rabfuz]" 4
+.IX Item "r[Rabfuz]"
+Replace or insert file members. The \fIR\fR, \fIa\fR, \fIb\fR, \fIf\fR, \fIu\fR, and \fIz\fR
+modifiers apply to this operation. This operation will replace existing
+\&\fIfiles\fR or insert them at the end of the archive if they do not exist. If no
+\&\fIfiles\fR are specified, the archive is not modified.
+.IP "t[v]" 4
+.IX Item "t[v]"
+Print the table of contents. Without any modifiers, this operation just prints
+the names of the members to the standard output. With the \fIv\fR modifier,
+\&\fBllvm-ar\fR also prints out the file type (B=bitcode, Z=compressed, S=symbol
+table, blank=regular file), the permission mode, the owner and group, the
+size, and the date. If any \fIfiles\fR are specified, the listing is only for
+those files. If no \fIfiles\fR are specified, the table of contents for the
+whole archive is printed.
+.IP "x[oP]" 4
+.IX Item "x[oP]"
+Extract archive members back to files. The \fIo\fR modifier applies to this
+operation. This operation retrieves the indicated \fIfiles\fR from the archive
+and writes them back to the operating system's file system. If no
+\&\fIfiles\fR are specified, the entire archive is extract.
+.SS "Modifiers (operation specific)"
+.IX Subsection "Modifiers (operation specific)"
+The modifiers below are specific to certain operations. See the Operations
+section (above) to determine which modifiers are applicable to which operations.
+.IP "[a]" 4
+.IX Item "[a]"
+When inserting or moving member files, this option specifies the destination of
+the new files as being \f(CW\*(C`a\*(C'\fRfter the \fIrelpos\fR member. If \fIrelpos\fR is not found,
+the files are placed at the end of the archive.
+.IP "[b]" 4
+.IX Item "[b]"
+When inserting or moving member files, this option specifies the destination of
+the new files as being \f(CW\*(C`b\*(C'\fRefore the \fIrelpos\fR member. If \fIrelpos\fR is not
+found, the files are placed at the end of the archive. This modifier is
+identical to the the \fIi\fR modifier.
+.IP "[f]" 4
+.IX Item "[f]"
+Normally, \fBllvm-ar\fR stores the full path name to a file as presented to it on
+the command line. With this option, truncated (15 characters max) names are
+used. This ensures name compatibility with older versions of \f(CW\*(C`ar\*(C'\fR but may also
+thwart correct extraction of the files (duplicates may overwrite). If used with
+the \fIR\fR option, the directory recursion will be performed but the file names
+will all be \f(CW\*(C`f\*(C'\fRlattened to simple file names.
+.IP "[i]" 4
+.IX Item "[i]"
+A synonym for the \fIb\fR option.
+.IP "[k]" 4
+.IX Item "[k]"
+Normally, \fBllvm-ar\fR will not print the contents of bitcode files when the
+\&\fIp\fR operation is used. This modifier defeats the default and allows the
+bitcode members to be printed.
+.IP "[N]" 4
+.IX Item "[N]"
+This option is ignored by \fBllvm-ar\fR but provided for compatibility.
+.IP "[o]" 4
+.IX Item "[o]"
+When extracting files, this option will cause \fBllvm-ar\fR to preserve the
+original modification times of the files it writes.
+.IP "[P]" 4
+.IX Item "[P]"
+use full path names when matching
+.IP "[R]" 4
+.IX Item "[R]"
+This modifier instructions the \fIr\fR option to recursively process directories.
+Without \fIR\fR, directories are ignored and only those \fIfiles\fR that refer to
+files will be added to the archive. When \fIR\fR is used, any directories specified
+with \fIfiles\fR will be scanned (recursively) to find files to be added to the
+archive. Any file whose name begins with a dot will not be added.
+.IP "[u]" 4
+.IX Item "[u]"
+When replacing existing files in the archive, only replace those files that have
+a time stamp than the time stamp of the member in the archive.
+.IP "[z]" 4
+.IX Item "[z]"
+When inserting or replacing any file in the archive, compress the file first.
+This
+modifier is safe to use when (previously) compressed bitcode files are added to
+the archive; the compressed bitcode files will not be doubly compressed.
+.SS "Modifiers (generic)"
+.IX Subsection "Modifiers (generic)"
+The modifiers below may be applied to any operation.
+.IP "[c]" 4
+.IX Item "[c]"
+For all operations, \fBllvm-ar\fR will always create the archive if it doesn't
+exist. Normally, \fBllvm-ar\fR will print a warning message indicating that the
+archive is being created. Using this modifier turns off that warning.
+.IP "[s]" 4
+.IX Item "[s]"
+This modifier requests that an archive index (or symbol table) be added to the
+archive. This is the default mode of operation. The symbol table will contain
+all the externally visible functions and global variables defined by all the
+bitcode files in the archive. Using this modifier is more efficient that using
+llvm-ranlib which also creates the symbol table.
+.IP "[S]" 4
+.IX Item "[S]"
+This modifier is the opposite of the \fIs\fR modifier. It instructs \fBllvm-ar\fR to
+not build the symbol table. If both \fIs\fR and \fIS\fR are used, the last modifier to
+occur in the options will prevail.
+.IP "[v]" 4
+.IX Item "[v]"
+This modifier instructs \fBllvm-ar\fR to be verbose about what it is doing. Each
+editing operation taken against the archive will produce a line of output saying
+what is being done.
+.SH "STANDARDS"
+.IX Header "STANDARDS"
+The \fBllvm-ar\fR utility is intended to provide a superset of the \s-1IEEE\s0 Std 1003.2
+(\s-1POSIX\s0.2) functionality for \f(CW\*(C`ar\*(C'\fR. \fBllvm-ar\fR can read both \s-1SVR4\s0 and \s-1BSD4\s0.4 (or
+Mac \s-1OS\s0 X) archives. If the \f(CW\*(C`f\*(C'\fR modifier is given to the \f(CW\*(C`x\*(C'\fR or \f(CW\*(C`r\*(C'\fR operations
+then \fBllvm-ar\fR will write \s-1SVR4\s0 compatible archives. Without this modifier,
+\&\fBllvm-ar\fR will write \s-1BSD4\s0.4 compatible archives that have long names
+immediately after the header and indicated using the \*(L"#1/ddd\*(R" notation for the
+name in the header.
+.SH "FILE FORMAT"
+.IX Header "FILE FORMAT"
+The file format for \s-1LLVM\s0 Archive files is similar to that of \s-1BSD\s0 4.4 or Mac \s-1OSX\s0
+archive files. In fact, except for the symbol table, the \f(CW\*(C`ar\*(C'\fR commands on those
+operating systems should be able to read \s-1LLVM\s0 archive files. The details of the
+file format follow.
+.PP
+Each archive begins with the archive magic number which is the eight printable
+characters \*(L"!<arch>\en\*(R" where \en represents the newline character (0x0A).
+Following the magic number, the file is composed of even length members that
+begin with an archive header and end with a \en padding character if necessary
+(to make the length even). Each file member is composed of a header (defined
+below), an optional newline-terminated \*(L"long file name\*(R" and the contents of
+the file.
+.PP
+The fields of the header are described in the items below. All fields of the
+header contain only \s-1ASCII\s0 characters, are left justified and are right padded
+with space characters.
+.IP "name \- char[16]" 4
+.IX Item "name - char[16]"
+This field of the header provides the name of the archive member. If the name is
+longer than 15 characters or contains a slash (/) character, then this field
+contains \f(CW\*(C`#1/nnn\*(C'\fR where \f(CW\*(C`nnn\*(C'\fR provides the length of the name and the \f(CW\*(C`#1/\*(C'\fR
+is literal. In this case, the actual name of the file is provided in the \f(CW\*(C`nnn\*(C'\fR
+bytes immediately following the header. If the name is 15 characters or less, it
+is contained directly in this field and terminated with a slash (/) character.
+.IP "date \- char[12]" 4
+.IX Item "date - char[12]"
+This field provides the date of modification of the file in the form of a
+decimal encoded number that provides the number of seconds since the epoch
+(since 00:00:00 Jan 1, 1970) per Posix specifications.
+.IP "uid \- char[6]" 4
+.IX Item "uid - char[6]"
+This field provides the user id of the file encoded as a decimal \s-1ASCII\s0 string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_uid field of the stat structure returned by the \fIstat\fR\|(2)
+operating system call.
+.IP "gid \- char[6]" 4
+.IX Item "gid - char[6]"
+This field provides the group id of the file encoded as a decimal \s-1ASCII\s0 string.
+This field might not make much sense on non-Unix systems. On Unix, it is the
+same value as the st_gid field of the stat structure returned by the \fIstat\fR\|(2)
+operating system call.
+.IP "mode \- char[8]" 4
+.IX Item "mode - char[8]"
+This field provides the access mode of the file encoded as an octal \s-1ASCII\s0
+string. This field might not make much sense on non-Unix systems. On Unix, it
+is the same value as the st_mode field of the stat structure returned by the
+\&\fIstat\fR\|(2) operating system call.
+.IP "size \- char[10]" 4
+.IX Item "size - char[10]"
+This field provides the size of the file, in bytes, encoded as a decimal \s-1ASCII\s0
+string. If the size field is negative (starts with a minus sign, 0x02D), then
+the archive member is stored in compressed form. The first byte of the archive
+member's data indicates the compression type used. A value of 0 (0x30) indicates
+that no compression was used. A value of 2 (0x32) indicates that bzip2
+compression was used.
+.IP "fmag \- char[2]" 4
+.IX Item "fmag - char[2]"
+This field is the archive file member magic number. Its content is always the
+two characters back tick (0x60) and newline (0x0A). This provides some measure
+utility in identifying archive files that have been corrupted.
+.PP
+The \s-1LLVM\s0 symbol table has the special name \*(L"#_LLVM_SYM_TAB_#\*(R". It is presumed
+that no regular archive member file will want this name. The \s-1LLVM\s0 symbol table
+is simply composed of a sequence of triplets: byte offset, length of symbol,
+and the symbol itself. Symbols are not null or newline terminated. Here are
+the details on each of these items:
+.IP "offset \- vbr encoded 32\-bit integer" 4
+.IX Item "offset - vbr encoded 32-bit integer"
+The offset item provides the offset into the archive file where the bitcode
+member is stored that is associated with the symbol. The offset value is 0
+based at the start of the first \*(L"normal\*(R" file member. To derive the actual
+file offset of the member, you must add the number of bytes occupied by the file
+signature (8 bytes) and the symbol tables. The value of this item is encoded
+using variable bit rate encoding to reduce the size of the symbol table.
+Variable bit rate encoding uses the high bit (0x80) of each byte to indicate
+if there are more bytes to follow. The remaining 7 bits in each byte carry bits
+from the value. The final byte does not have the high bit set.
+.IP "length \- vbr encoded 32\-bit integer" 4
+.IX Item "length - vbr encoded 32-bit integer"
+The length item provides the length of the symbol that follows. Like this
+\&\fIoffset\fR item, the length is variable bit rate encoded.
+.IP "symbol \- character array" 4
+.IX Item "symbol - character array"
+The symbol item provides the text of the symbol that is associated with the
+\&\fIoffset\fR. The symbol is not terminated by any character. Its length is provided
+by the \fIlength\fR field. Note that is allowed (but unwise) to use non-printing
+characters (even 0x00) in the symbol. This allows for multiple encodings of
+symbol names.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-ar\fR succeeds, it will exit with 0. A usage error, results
+in an exit code of 1. A hard (file system typically) error results in an
+exit code of 2. Miscellaneous or unknown errors result in an
+exit code of 3.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-ranlib, \fIar\fR\|(1)
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-as.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-as.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-as.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-as.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,181 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-AS 1"
+.TH LLVM-AS 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-as \- LLVM assembler
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-as\fR [\fIoptions\fR] [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBllvm-as\fR is the \s-1LLVM\s0 assembler. It reads a file containing human-readable
+\&\s-1LLVM\s0 assembly language, translates it to \s-1LLVM\s0 bitcode, and writes the result
+into a file or to standard output.
+.PP
+If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR reads its input from
+standard input.
+.PP
+If an output file is not specified with the \fB\-o\fR option, then
+\&\fBllvm-as\fR sends its output to a file or standard output by following
+these rules:
+.IP "\(bu" 4
+If the input is standard input, then the output is standard output.
+.IP "\(bu" 4
+If the input is a file that ends with \f(CW\*(C`.ll\*(C'\fR, then the output file is of
+the same name, except that the suffix is changed to \f(CW\*(C`.bc\*(C'\fR.
+.IP "\(bu" 4
+If the input is a file that does not end with the \f(CW\*(C`.ll\*(C'\fR suffix, then the
+output file has the same name as the input file, except that the \f(CW\*(C`.bc\*(C'\fR
+suffix is appended.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+Enable binary output on terminals. Normally, \fBllvm-as\fR will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+\&\fBllvm-as\fR will write raw bitcode regardless of the output device.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR
+sends its output to standard output.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-as\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-dis, gccas
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-bcanalyzer.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-bcanalyzer.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-bcanalyzer.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-bcanalyzer.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,369 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-BCANALYZER 1"
+.TH LLVM-BCANALYZER 1 "2011-04-15" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-bcanalyzer \- LLVM bitcode analyzer
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-bcanalyzer\fR [\fIoptions\fR] [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-bcanalyzer\fR command is a small utility for analyzing bitcode files.
+The tool reads a bitcode file (such as generated with the \fBllvm-as\fR tool) and
+produces a statistical report on the contents of the bitcode file. The tool
+can also dump a low level but human readable version of the bitcode file.
+This tool is probably not of much interest or utility except for those working
+directly with the bitcode file format. Most \s-1LLVM\s0 users can just ignore
+this tool.
+.PP
+If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-bcanalyzer\fR reads its input
+from standard input. This is useful for combining the tool into a pipeline.
+Output is written to the standard output.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-nodetails\fR" 4
+.IX Item "-nodetails"
+Causes \fBllvm-bcanalyzer\fR to abbreviate its output by writing out only a module
+level summary. The details for individual functions are not displayed.
+.IP "\fB\-dump\fR" 4
+.IX Item "-dump"
+Causes \fBllvm-bcanalyzer\fR to dump the bitcode in a human readable format. This
+format is significantly different from \s-1LLVM\s0 assembly and provides details about
+the encoding of the bitcode file.
+.IP "\fB\-verify\fR" 4
+.IX Item "-verify"
+Causes \fBllvm-bcanalyzer\fR to verify the module produced by reading the
+bitcode. This ensures that the statistics generated are based on a consistent
+module.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-bcanalyzer\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value, usually 1.
+.SH "SUMMARY OUTPUT DEFINITIONS"
+.IX Header "SUMMARY OUTPUT DEFINITIONS"
+The following items are always printed by llvm-bcanalyzer. They comprize the
+summary output.
+.IP "\fBBitcode Analysis Of Module\fR" 4
+.IX Item "Bitcode Analysis Of Module"
+This just provides the name of the module for which bitcode analysis is being
+generated.
+.IP "\fBBitcode Version Number\fR" 4
+.IX Item "Bitcode Version Number"
+The bitcode version (not \s-1LLVM\s0 version) of the file read by the analyzer.
+.IP "\fBFile Size\fR" 4
+.IX Item "File Size"
+The size, in bytes, of the entire bitcode file.
+.IP "\fBModule Bytes\fR" 4
+.IX Item "Module Bytes"
+The size, in bytes, of the module block. Percentage is relative to File Size.
+.IP "\fBFunction Bytes\fR" 4
+.IX Item "Function Bytes"
+The size, in bytes, of all the function blocks. Percentage is relative to File
+Size.
+.IP "\fBGlobal Types Bytes\fR" 4
+.IX Item "Global Types Bytes"
+The size, in bytes, of the Global Types Pool. Percentage is relative to File
+Size. This is the size of the definitions of all types in the bitcode file.
+.IP "\fBConstant Pool Bytes\fR" 4
+.IX Item "Constant Pool Bytes"
+The size, in bytes, of the Constant Pool Blocks Percentage is relative to File
+Size.
+.IP "\fBModule Globals Bytes\fR" 4
+.IX Item "Module Globals Bytes"
+Ths size, in bytes, of the Global Variable Definitions and their initializers.
+Percentage is relative to File Size.
+.IP "\fBInstruction List Bytes\fR" 4
+.IX Item "Instruction List Bytes"
+The size, in bytes, of all the instruction lists in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.
+.IP "\fBCompaction Table Bytes\fR" 4
+.IX Item "Compaction Table Bytes"
+The size, in bytes, of all the compaction tables in all the functions.
+Percentage is relative to File Size. Note that this value is also included in
+the Function Bytes.
+.IP "\fBSymbol Table Bytes\fR" 4
+.IX Item "Symbol Table Bytes"
+The size, in bytes, of all the symbol tables in all the functions. Percentage is
+relative to File Size. Note that this value is also included in the Function
+Bytes.
+.IP "\fBDependent Libraries Bytes\fR" 4
+.IX Item "Dependent Libraries Bytes"
+The size, in bytes, of the list of dependent libraries in the module. Percentage
+is relative to File Size. Note that this value is also included in the Module
+Global Bytes.
+.IP "\fBNumber Of Bitcode Blocks\fR" 4
+.IX Item "Number Of Bitcode Blocks"
+The total number of blocks of any kind in the bitcode file.
+.IP "\fBNumber Of Functions\fR" 4
+.IX Item "Number Of Functions"
+The total number of function definitions in the bitcode file.
+.IP "\fBNumber Of Types\fR" 4
+.IX Item "Number Of Types"
+The total number of types defined in the Global Types Pool.
+.IP "\fBNumber Of Constants\fR" 4
+.IX Item "Number Of Constants"
+The total number of constants (of any type) defined in the Constant Pool.
+.IP "\fBNumber Of Basic Blocks\fR" 4
+.IX Item "Number Of Basic Blocks"
+The total number of basic blocks defined in all functions in the bitcode file.
+.IP "\fBNumber Of Instructions\fR" 4
+.IX Item "Number Of Instructions"
+The total number of instructions defined in all functions in the bitcode file.
+.IP "\fBNumber Of Long Instructions\fR" 4
+.IX Item "Number Of Long Instructions"
+The total number of long instructions defined in all functions in the bitcode
+file. Long instructions are those taking greater than 4 bytes. Typically long
+instructions are GetElementPtr with several indices, \s-1PHI\s0 nodes, and calls to
+functions with large numbers of arguments.
+.IP "\fBNumber Of Operands\fR" 4
+.IX Item "Number Of Operands"
+The total number of operands used in all instructions in the bitcode file.
+.IP "\fBNumber Of Compaction Tables\fR" 4
+.IX Item "Number Of Compaction Tables"
+The total number of compaction tables in all functions in the bitcode file.
+.IP "\fBNumber Of Symbol Tables\fR" 4
+.IX Item "Number Of Symbol Tables"
+The total number of symbol tables in all functions in the bitcode file.
+.IP "\fBNumber Of Dependent Libs\fR" 4
+.IX Item "Number Of Dependent Libs"
+The total number of dependent libraries found in the bitcode file.
+.IP "\fBTotal Instruction Size\fR" 4
+.IX Item "Total Instruction Size"
+The total size of the instructions in all functions in the bitcode file.
+.IP "\fBAverage Instruction Size\fR" 4
+.IX Item "Average Instruction Size"
+The average number of bytes per instruction across all functions in the bitcode
+file. This value is computed by dividing Total Instruction Size by Number Of
+Instructions.
+.IP "\fBMaximum Type Slot Number\fR" 4
+.IX Item "Maximum Type Slot Number"
+The maximum value used for a type's slot number. Larger slot number values take
+more bytes to encode.
+.IP "\fBMaximum Value Slot Number\fR" 4
+.IX Item "Maximum Value Slot Number"
+The maximum value used for a value's slot number. Larger slot number values take
+more bytes to encode.
+.IP "\fBBytes Per Value\fR" 4
+.IX Item "Bytes Per Value"
+The average size of a Value definition (of any type). This is computed by
+dividing File Size by the total number of values of any type.
+.IP "\fBBytes Per Global\fR" 4
+.IX Item "Bytes Per Global"
+The average size of a global definition (constants and global variables).
+.IP "\fBBytes Per Function\fR" 4
+.IX Item "Bytes Per Function"
+The average number of bytes per function definition. This is computed by
+dividing Function Bytes by Number Of Functions.
+.IP "\fB# of \s-1VBR\s0 32\-bit Integers\fR" 4
+.IX Item "# of VBR 32-bit Integers"
+The total number of 32\-bit integers encoded using the Variable Bit Rate
+encoding scheme.
+.IP "\fB# of \s-1VBR\s0 64\-bit Integers\fR" 4
+.IX Item "# of VBR 64-bit Integers"
+The total number of 64\-bit integers encoded using the Variable Bit Rate encoding
+scheme.
+.IP "\fB# of \s-1VBR\s0 Compressed Bytes\fR" 4
+.IX Item "# of VBR Compressed Bytes"
+The total number of bytes consumed by the 32\-bit and 64\-bit integers that use
+the Variable Bit Rate encoding scheme.
+.IP "\fB# of \s-1VBR\s0 Expanded Bytes\fR" 4
+.IX Item "# of VBR Expanded Bytes"
+The total number of bytes that would have been consumed by the 32\-bit and 64\-bit
+integers had they not been compressed with the Variable Bit Rage encoding
+scheme.
+.IP "\fBBytes Saved With \s-1VBR\s0\fR" 4
+.IX Item "Bytes Saved With VBR"
+The total number of bytes saved by using the Variable Bit Rate encoding scheme.
+The percentage is relative to # of \s-1VBR\s0 Expanded Bytes.
+.SH "DETAILED OUTPUT DEFINITIONS"
+.IX Header "DETAILED OUTPUT DEFINITIONS"
+The following definitions occur only if the \-nodetails option was not given.
+The detailed output provides additional information on a per-function basis.
+.IP "\fBType\fR" 4
+.IX Item "Type"
+The type signature of the function.
+.IP "\fBByte Size\fR" 4
+.IX Item "Byte Size"
+The total number of bytes in the function's block.
+.IP "\fBBasic Blocks\fR" 4
+.IX Item "Basic Blocks"
+The number of basic blocks defined by the function.
+.IP "\fBInstructions\fR" 4
+.IX Item "Instructions"
+The number of instructions defined by the function.
+.IP "\fBLong Instructions\fR" 4
+.IX Item "Long Instructions"
+The number of instructions using the long instruction format in the function.
+.IP "\fBOperands\fR" 4
+.IX Item "Operands"
+The number of operands used by all instructions in the function.
+.IP "\fBInstruction Size\fR" 4
+.IX Item "Instruction Size"
+The number of bytes consumed by instructions in the function.
+.IP "\fBAverage Instruction Size\fR" 4
+.IX Item "Average Instruction Size"
+The average number of bytes consumed by the instructions in the function. This
+value is computed by dividing Instruction Size by Instructions.
+.IP "\fBBytes Per Instruction\fR" 4
+.IX Item "Bytes Per Instruction"
+The average number of bytes used by the function per instruction. This value is
+computed by dividing Byte Size by Instructions. Note that this is not the same
+as Average Instruction Size. It computes a number relative to the total function
+size not just the size of the instruction list.
+.IP "\fBNumber of \s-1VBR\s0 32\-bit Integers\fR" 4
+.IX Item "Number of VBR 32-bit Integers"
+The total number of 32\-bit integers found in this function (for any use).
+.IP "\fBNumber of \s-1VBR\s0 64\-bit Integers\fR" 4
+.IX Item "Number of VBR 64-bit Integers"
+The total number of 64\-bit integers found in this function (for any use).
+.IP "\fBNumber of \s-1VBR\s0 Compressed Bytes\fR" 4
+.IX Item "Number of VBR Compressed Bytes"
+The total number of bytes in this function consumed by the 32\-bit and 64\-bit
+integers that use the Variable Bit Rate encoding scheme.
+.IP "\fBNumber of \s-1VBR\s0 Expanded Bytes\fR" 4
+.IX Item "Number of VBR Expanded Bytes"
+The total number of bytes in this function that would have been consumed by
+the 32\-bit and 64\-bit integers had they not been compressed with the Variable
+Bit Rate encoding scheme.
+.IP "\fBBytes Saved With \s-1VBR\s0\fR" 4
+.IX Item "Bytes Saved With VBR"
+The total number of bytes saved in this function by using the Variable Bit
+Rate encoding scheme. The percentage is relative to # of \s-1VBR\s0 Expanded Bytes.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-dis, <http://llvm.org/docs/BitCodeFormat.html>
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-build.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-build.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-build.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-build.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,196 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-BUILD 1"
+.TH LLVM-BUILD 1 "2011-12-12" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-build \- LLVM Project Build Utility
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-build\fR [\fIoptions\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBllvm-build\fR is a tool for working with \s-1LLVM\s0 projects that use the LLVMBuild
+system for describing their components.
+.PP
+At heart, \fBllvm-build\fR is responsible for loading, verifying, and manipulating
+the project's component data. The tool is primarily designed for use in
+implementing build systems and tools which need access to the project structure
+information.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-h\fR, \fB\-\-help\fR" 4
+.IX Item "-h, --help"
+Print the builtin program help.
+.IP "\fB\-\-source\-root\fR=\fI\s-1PATH\s0\fR" 4
+.IX Item "--source-root=PATH"
+If given, load the project at the given source root path. If this option is not
+given, the location of the project sources will be inferred from the location of
+the \fBllvm-build\fR script itself.
+.IP "\fB\-\-print\-tree\fR" 4
+.IX Item "--print-tree"
+Print the component tree for the project.
+.IP "\fB\-\-write\-library\-table\fR" 4
+.IX Item "--write-library-table"
+Write out the \*(C+ fragment which defines the components, library names, and
+required libraries. This \*(C+ fragment is built into llvm-config
+in order to provide clients with the list of required libraries for arbitrary
+component combinations.
+.IP "\fB\-\-write\-llvmbuild\fR" 4
+.IX Item "--write-llvmbuild"
+Write out new \fILLVMBuild.txt\fR files based on the loaded components. This is
+useful for auto-upgrading the schema of the files. \fBllvm-build\fR will try to a
+limited extent to preserve the comments which were written in the original
+source file, although at this time it only preserves block comments that preceed
+the section names in the \fILLVMBuild\fR files.
+.IP "\fB\-\-write\-cmake\-fragment\fR" 4
+.IX Item "--write-cmake-fragment"
+Write out the LLVMBuild in the form of a CMake fragment, so it can easily be
+consumed by the CMake based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with CMake, see \s-1LLVM\s0's
+top-level CMakeLists.txt.
+.IP "\fB\-\-write\-make\-fragment\fR" 4
+.IX Item "--write-make-fragment"
+Write out the LLVMBuild in the form of a Makefile fragment, so it can easily be
+consumed by a Make based build system. The exact contents and format of this
+file are closely tied to how LLVMBuild is integrated with the Makefiles, see
+\&\s-1LLVM\s0's Makefile.rules.
+.IP "\fB\-\-llvmbuild\-source\-root\fR=\fI\s-1PATH\s0\fR" 4
+.IX Item "--llvmbuild-source-root=PATH"
+If given, expect the \fILLVMBuild\fR files for the project to be rooted at the
+given path, instead of inside the source tree itself. This option is primarily
+designed for use in conjunction with \fB\-\-write\-llvmbuild\fR to test changes to
+\&\fILLVMBuild\fR schema.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+\&\fBllvm-build\fR exits with 0 if operation was successful. Otherwise, it will exist
+with a non-zero value.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-config.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-config.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-config.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-config.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,226 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-CONFIG 1"
+.TH LLVM-CONFIG 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-config \- Print LLVM compilation options
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-config\fR \fIoption\fR [\fIcomponents\fR...]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBllvm-config\fR makes it easier to build applications that use \s-1LLVM\s0. It can
+print the compiler flags, linker flags and object libraries needed to link
+against \s-1LLVM\s0.
+.SH "EXAMPLES"
+.IX Header "EXAMPLES"
+To link against the \s-1JIT:\s0
+.PP
+.Vb 3
+\& g++ \`llvm\-config \-\-cxxflags\` \-o HowToUseJIT.o \-c HowToUseJIT.cpp
+\& g++ \`llvm\-config \-\-ldflags\` \-o HowToUseJIT HowToUseJIT.o \e
+\& \`llvm\-config \-\-libs engine bcreader scalaropts\`
+.Ve
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Print the version number of \s-1LLVM\s0.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of \fBllvm-config\fR arguments.
+.IP "\fB\-\-prefix\fR" 4
+.IX Item "--prefix"
+Print the installation prefix for \s-1LLVM\s0.
+.IP "\fB\-\-src\-root\fR" 4
+.IX Item "--src-root"
+Print the source root from which \s-1LLVM\s0 was built.
+.IP "\fB\-\-obj\-root\fR" 4
+.IX Item "--obj-root"
+Print the object root used to build \s-1LLVM\s0.
+.IP "\fB\-\-bindir\fR" 4
+.IX Item "--bindir"
+Print the installation directory for \s-1LLVM\s0 binaries.
+.IP "\fB\-\-includedir\fR" 4
+.IX Item "--includedir"
+Print the installation directory for \s-1LLVM\s0 headers.
+.IP "\fB\-\-libdir\fR" 4
+.IX Item "--libdir"
+Print the installation directory for \s-1LLVM\s0 libraries.
+.IP "\fB\-\-cxxflags\fR" 4
+.IX Item "--cxxflags"
+Print the \*(C+ compiler flags needed to use \s-1LLVM\s0 headers.
+.IP "\fB\-\-ldflags\fR" 4
+.IX Item "--ldflags"
+Print the flags needed to link against \s-1LLVM\s0 libraries.
+.IP "\fB\-\-libs\fR" 4
+.IX Item "--libs"
+Print all the libraries needed to link against the specified \s-1LLVM\s0
+\&\fIcomponents\fR, including any dependencies.
+.IP "\fB\-\-libnames\fR" 4
+.IX Item "--libnames"
+Similar to \fB\-\-libs\fR, but prints the bare filenames of the libraries
+without \fB\-l\fR or pathnames. Useful for linking against a not-yet-installed
+copy of \s-1LLVM\s0.
+.IP "\fB\-\-libfiles\fR" 4
+.IX Item "--libfiles"
+Similar to \fB\-\-libs\fR, but print the full path to each library file. This is
+useful when creating makefile dependencies, to ensure that a tool is relinked if
+any library it uses changes.
+.IP "\fB\-\-components\fR" 4
+.IX Item "--components"
+Print all valid component names.
+.IP "\fB\-\-targets\-built\fR" 4
+.IX Item "--targets-built"
+Print the component names for all targets supported by this copy of \s-1LLVM\s0.
+.IP "\fB\-\-build\-mode\fR" 4
+.IX Item "--build-mode"
+Print the build mode used when \s-1LLVM\s0 was built (e.g. Debug or Release)
+.SH "COMPONENTS"
+.IX Header "COMPONENTS"
+To print a list of all available components, run \fBllvm-config
+\&\-\-components\fR. In most cases, components correspond directly to \s-1LLVM\s0
+libraries. Useful \*(L"virtual\*(R" components include:
+.IP "\fBall\fR" 4
+.IX Item "all"
+Includes all \s-1LLVM\s0 libaries. The default if no components are specified.
+.IP "\fBbackend\fR" 4
+.IX Item "backend"
+Includes either a native backend or the C backend.
+.IP "\fBengine\fR" 4
+.IX Item "engine"
+Includes either a native \s-1JIT\s0 or the bitcode interpreter.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-config\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-cov.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-cov.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-cov.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-cov.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,169 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-COV 1"
+.TH LLVM-COV 1 "2011-11-28" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-cov \- emit coverage information
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-cov\fR [\-gcno=filename] [\-gcda=filename] [dump]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The experimental \fBllvm-cov\fR tool reads in description file generated by compiler
+and coverage data file generated by instrumented program. This program assumes
+that the description and data file uses same format as gcov files.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-gcno=filename]\fR" 4
+.IX Item "-gcno=filename]"
+This option selects input description file generated by compiler while instrumenting
+program.
+.IP "\fB\-gcda=filename]\fR" 4
+.IX Item "-gcda=filename]"
+This option selects coverage data file generated by instrumented compiler.
+.IP "\fB\-dump\fR" 4
+.IX Item "-dump"
+This options enables output dump that is suitable for a developer to help debug
+\&\fBllvm-cov\fR itself.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+\&\fBllvm-cov\fR returns 1 if it cannot read input files. Otherwise, it exits with zero.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+\&\fBllvm-cov\fR is maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
+.SH "POD ERRORS"
+.IX Header "POD ERRORS"
+Hey! \fBThe above document had some coding errors, which are explained below:\fR
+.IP "Around line 21:" 4
+.IX Item "Around line 21:"
+Unterminated B<...> sequence
+.IP "Around line 26:" 4
+.IX Item "Around line 26:"
+Unterminated B<...> sequence
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-diff.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-diff.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-diff.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-diff.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,174 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-DIFF 1"
+.TH LLVM-DIFF 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-diff \- LLVM structural 'diff'
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-diff\fR [\fIoptions\fR] \fImodule 1\fR \fImodule 2\fR [\fIglobal name ...\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBllvm-diff\fR compares the structure of two \s-1LLVM\s0 modules, primarily
+focusing on differences in function definitions. Insignificant
+differences, such as changes in the ordering of globals or in the
+names of local values, are ignored.
+.PP
+An input module will be interpreted as an assembly file if its name
+ends in '.ll'; otherwise it will be read in as a bitcode file.
+.PP
+If a list of global names is given, just the values with those names
+are compared; otherwise, all global values are compared, and
+diagnostics are produced for globals which only appear in one module
+or the other.
+.PP
+\&\fBllvm-diff\fR compares two functions by comparing their basic blocks,
+beginning with the entry blocks. If the terminators seem to match,
+then the corresponding successors are compared; otherwise they are
+ignored. This algorithm is very sensitive to changes in control flow,
+which tend to stop any downstream changes from being detected.
+.PP
+\&\fBllvm-diff\fR is intended as a debugging tool for writers of \s-1LLVM\s0
+passes and frontends. It does not have a stable output format.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-diff\fR finds no differences between the modules, it will exit
+with 0 and produce no output. Otherwise it will exit with a non-zero
+value.
+.SH "BUGS"
+.IX Header "BUGS"
+Many important differences, like changes in linkage or function
+attributes, are not diagnosed.
+.PP
+Changes in memory behavior (for example, coalescing loads) can cause
+massive detected differences in blocks.
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-dis.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-dis.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-dis.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-dis.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,174 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-DIS 1"
+.TH LLVM-DIS 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-dis \- LLVM disassembler
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-dis\fR [\fIoptions\fR] [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-dis\fR command is the \s-1LLVM\s0 disassembler. It takes an \s-1LLVM\s0
+bitcode file and converts it into human-readable \s-1LLVM\s0 assembly language.
+.PP
+If filename is omitted or specified as \f(CW\*(C`\-\*(C'\fR, \fBllvm-dis\fR reads its
+input from standard input.
+.PP
+If the input is being read from standard input, then \fBllvm-dis\fR
+will send its output to standard output by default. Otherwise, the
+output will be written to a file named after the input file, with
+a \f(CW\*(C`.ll\*(C'\fR suffix added (any existing \f(CW\*(C`.bc\*(C'\fR suffix will first be
+removed). You can override the choice of output file using the
+\&\fB\-o\fR option.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+Enable binary output on terminals. Normally, \fBllvm-dis\fR will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+\&\fBllvm-dis\fR will write raw bitcode regardless of the output device.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output file name. If \fIfilename\fR is \-, then the output is sent
+to standard output.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-dis\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-as
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-extract.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-extract.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-extract.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-extract.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,194 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-EXTRACT 1"
+.TH LLVM-EXTRACT 1 "2011-09-16" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-extract \- extract a function from an LLVM module
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-extract\fR [\fIoptions\fR] \fB\-\-func\fR \fIfunction-name\fR [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-extract\fR command takes the name of a function and extracts it from
+the specified \s-1LLVM\s0 bitcode file. It is primarily used as a debugging tool to
+reduce test cases from larger programs that are triggering a bug.
+.PP
+In addition to extracting the bitcode of the specified function,
+\&\fBllvm-extract\fR will also remove unreachable global variables, prototypes, and
+unused types.
+.PP
+The \fBllvm-extract\fR command reads its input from standard input if filename is
+omitted or if filename is \-. The output is always written to standard output,
+unless the \fB\-o\fR option is specified (see below).
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+Enable binary output on terminals. Normally, \fBllvm-extract\fR will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+\&\fBllvm-extract\fR will write raw bitcode regardless of the output device.
+.IP "\fB\-\-func\fR \fIfunction-name\fR" 4
+.IX Item "--func function-name"
+Extract the function named \fIfunction-name\fR from the \s-1LLVM\s0 bitcode. May be
+specified multiple times to extract multiple functions at once.
+.IP "\fB\-\-rfunc\fR \fIfunction-regular-expr\fR" 4
+.IX Item "--rfunc function-regular-expr"
+Extract the function(s) matching \fIfunction-regular-expr\fR from the \s-1LLVM\s0 bitcode.
+All functions matching the regular expression will be extracted. May be
+specified multiple times.
+.IP "\fB\-\-glob\fR \fIglobal-name\fR" 4
+.IX Item "--glob global-name"
+Extract the global variable named \fIglobal-name\fR from the \s-1LLVM\s0 bitcode. May be
+specified multiple times to extract multiple global variables at once.
+.IP "\fB\-\-rglob\fR \fIglob-regular-expr\fR" 4
+.IX Item "--rglob glob-regular-expr"
+Extract the global variable(s) matching \fIglobal-regular-expr\fR from the \s-1LLVM\s0
+bitcode. All global variables matching the regular expression will be extracted.
+May be specified multiple times.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output filename. If filename is \*(L"\-\*(R" (the default), then
+\&\fBllvm-extract\fR sends its output to standard output.
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+Write output in \s-1LLVM\s0 intermediate language (instead of bitcode).
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-extract\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+bugpoint
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ld.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ld.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ld.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ld.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,318 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-LD 1"
+.TH LLVM-LD 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-ld \- LLVM linker
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-ld\fR <options> <files>
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-ld\fR tool takes a set of \s-1LLVM\s0 bitcode files and links them
+together into a single \s-1LLVM\s0 bitcode file. The output bitcode file can be
+another bitcode file or an executable bitcode program. Using additional
+options, \fBllvm-ld\fR is able to produce native code executables.
+.PP
+The \fBllvm-ld\fR tool is the main linker for \s-1LLVM\s0. It is used to link together
+the output of \s-1LLVM\s0 front-end compilers and run \*(L"link time\*(R" optimizations (mostly
+the inter-procedural kind).
+.PP
+The \fBllvm-ld\fR tools attempts to mimic the interface provided by the default
+system linker so that it can act as a \fIdrop-in\fR replacement.
+.SS "Search Order"
+.IX Subsection "Search Order"
+When looking for objects specified on the command line, \fBllvm-ld\fR will search
+for the object first in the current directory and then in the directory
+specified by the \fB\s-1LLVM_LIB_SEARCH_PATH\s0\fR environment variable. If it cannot
+find the object, it fails.
+.PP
+When looking for a library specified with the \fB\-l\fR option, \fBllvm-ld\fR first
+attempts to load a file with that name from the current directory. If that
+fails, it looks for lib\fIlibrary\fR.bc, lib\fIlibrary\fR.a, or lib\fIlibrary\fR.\fIshared
+library extension\fR, in that order, in each directory added to the library search
+path with the \fB\-L\fR option. These directories are searched in the order they
+are specified. If the library cannot be located, then \fBllvm-ld\fR looks in the
+directory specified by the \fB\s-1LLVM_LIB_SEARCH_PATH\s0\fR environment variable. If it
+does not find a library there, it fails.
+.PP
+The \fIshared library extension\fR may be \fI.so\fR, \fI.dyld\fR, \fI.dll\fR, or something
+different, depending upon the system.
+.PP
+The \fB\-L\fR option is global. It does not matter where it is specified in the
+list of command line arguments; the directory is simply added to the search path
+and is applied to all libraries, preceding or succeeding, in the command line.
+.SS "Link order"
+.IX Subsection "Link order"
+All object and bitcode files are linked first in the order they were
+specified on the command line. All library files are linked next.
+Some libraries may not be linked into the object program; see below.
+.SS "Library Linkage"
+.IX Subsection "Library Linkage"
+Object files and static bitcode objects are always linked into the output
+file. Library archives (.a files) load only the objects within the archive
+that define symbols needed by the output file. Hence, libraries should be
+listed after the object files and libraries which need them; otherwise, the
+library may not be linked in, and the dependent library will not have its
+undefined symbols defined.
+.SS "Native code generation"
+.IX Subsection "Native code generation"
+The \fBllvm-ld\fR program has limited support for native code generation, when
+using the \fB\-native\fR or \fB\-native\-cbe\fR options. Native code generation is
+performed by converting the linked bitcode into native assembly (.s) or C code
+and running the system compiler (typically gcc) on the result.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.SS "General Options"
+.IX Subsection "General Options"
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Specifies verbose mode. In this mode the linker will print additional
+information about the actions it takes, programs it executes, etc.
+.IP "\fB\-stats\fR" 4
+.IX Item "-stats"
+Print statistics.
+.IP "\fB\-time\-passes\fR" 4
+.IX Item "-time-passes"
+Record the amount of time needed for each pass and print it to standard
+error.
+.SS "Input/Output Options"
+.IX Subsection "Input/Output Options"
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+This overrides the default output file and specifies the name of the file that
+should be generated by the linker. By default, \fBllvm-ld\fR generates a file named
+\&\fIa.out\fR for compatibility with \fBld\fR. The output will be written to
+\&\fIfilename\fR.
+.IP "\fB\-b\fR \fIfilename\fR" 4
+.IX Item "-b filename"
+This option can be used to override the output bitcode file name. By default,
+the name of the bitcode output file is one more \*(L".bc\*(R" suffix added to the name
+specified by \fB\-o filename\fR option.
+.IP "\fB\-l\fR\fIname\fR" 4
+.IX Item "-lname"
+This option specifies the \fIname\fR of a library to search when resolving symbols
+for the program. Only the base name should be specified as \fIname\fR, without a
+\&\fIlib\fR prefix or any suffix.
+.IP "\fB\-L\fR\fIPath\fR" 4
+.IX Item "-LPath"
+This option tells \fBllvm-ld\fR to look in \fIPath\fR to find any library subsequently
+specified with the \fB\-l\fR option. The paths will be searched in the order in
+which they are specified on the command line. If the library is still not found,
+a small set of system specific directories will also be searched. Note that
+libraries specified with the \fB\-l\fR option that occur \fIbefore\fR any \fB\-L\fR options
+will not search the paths given by the \fB\-L\fR options following it.
+.IP "\fB\-link\-as\-library\fR" 4
+.IX Item "-link-as-library"
+Link the bitcode files together as a library, not an executable. In this mode,
+undefined symbols will be permitted.
+.IP "\fB\-r\fR" 4
+.IX Item "-r"
+An alias for \-link\-as\-library.
+.IP "\fB\-native\fR" 4
+.IX Item "-native"
+Generate a native machine code executable.
+.Sp
+When generating native executables, \fBllvm-ld\fR first checks for a bitcode
+version of the library and links it in, if necessary. If the library is
+missing, \fBllvm-ld\fR skips it. Then, \fBllvm-ld\fR links in the same
+libraries as native code.
+.Sp
+In this way, \fBllvm-ld\fR should be able to link in optimized bitcode
+subsets of common libraries and then link in any part of the library that
+hasn't been converted to bitcode.
+.IP "\fB\-native\-cbe\fR" 4
+.IX Item "-native-cbe"
+Generate a native machine code executable with the \s-1LLVM\s0 C backend.
+.Sp
+This option is identical to the \fB\-native\fR option, but uses the
+C backend to generate code for the program instead of an \s-1LLVM\s0 native
+code generator.
+.SS "Optimization Options"
+.IX Subsection "Optimization Options"
+.IP "\fB\-disable\-inlining\fR" 4
+.IX Item "-disable-inlining"
+Do not run the inlining pass. Functions will not be inlined into other
+functions.
+.IP "\fB\-disable\-opt\fR" 4
+.IX Item "-disable-opt"
+Completely disable optimization.
+.IP "\fB\-disable\-internalize\fR" 4
+.IX Item "-disable-internalize"
+Do not mark all symbols as internal.
+.IP "\fB\-verify\-each\fR" 4
+.IX Item "-verify-each"
+Run the verification pass after each of the passes to verify intermediate
+results.
+.IP "\fB\-strip\-all\fR" 4
+.IX Item "-strip-all"
+Strip all debug and symbol information from the executable to make it smaller.
+.IP "\fB\-strip\-debug\fR" 4
+.IX Item "-strip-debug"
+Strip all debug information from the executable to make it smaller.
+.IP "\fB\-s\fR" 4
+.IX Item "-s"
+An alias for \fB\-strip\-all\fR.
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+An alias for \fB\-strip\-debug\fR.
+.IP "\fB\-export\-dynamic\fR" 4
+.IX Item "-export-dynamic"
+An alias for \fB\-disable\-internalize\fR
+.IP "\fB\-post\-link\-opt\fR\fIPath\fR" 4
+.IX Item "-post-link-optPath"
+Run post-link optimization program. After linking is completed a bitcode file
+will be generated. It will be passed to the program specified by \fIPath\fR as the
+first argument. The second argument to the program will be the name of a
+temporary file into which the program should place its optimized output. For
+example, the \*(L"no-op optimization\*(R" would be a simple shell script:
+.Sp
+.Vb 2
+\& #!/bin/bash
+\& cp $1 $2
+.Ve
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-ld\fR succeeds, it will exit with 0 return code. If an error occurs,
+it will exit with a non-zero return code.
+.SH "ENVIRONMENT"
+.IX Header "ENVIRONMENT"
+The \f(CW\*(C`LLVM_LIB_SEARCH_PATH\*(C'\fR environment variable is used to find bitcode
+libraries. Any paths specified in this variable will be searched after the \f(CW\*(C`\-L\*(C'\fR
+options.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-link
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-link.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-link.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-link.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-link.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,189 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-LINK 1"
+.TH LLVM-LINK 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-link \- LLVM linker
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-link\fR [\fIoptions\fR] \fIfilename ...\fR
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBllvm-link\fR takes several \s-1LLVM\s0 bitcode files and links them together into a
+single \s-1LLVM\s0 bitcode file. It writes the output file to standard output, unless
+the \fB\-o\fR option is used to specify a filename.
+.PP
+\&\fBllvm-link\fR attempts to load the input files from the current directory. If
+that fails, it looks for each file in each of the directories specified by the
+\&\fB\-L\fR options on the command line. The library search paths are global; each
+one is searched for every input file if necessary. The directories are searched
+in the order they were specified on the command line.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-L\fR \fIdirectory\fR" 4
+.IX Item "-L directory"
+Add the specified \fIdirectory\fR to the library search path. When looking for
+libraries, \fBllvm-link\fR will look in path name for libraries. This option can be
+specified multiple times; \fBllvm-link\fR will search inside these directories in
+the order in which they were specified on the command line.
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+Enable binary output on terminals. Normally, \fBllvm-link\fR will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+\&\fBllvm-link\fR will write raw bitcode regardless of the output device.
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-link\fR will
+write its output to standard output.
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+Write output in \s-1LLVM\s0 intermediate language (instead of bitcode).
+.IP "\fB\-d\fR" 4
+.IX Item "-d"
+If specified, \fBllvm-link\fR prints a human-readable version of the output
+bitcode file to standard error.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Verbose mode. Print information about what \fBllvm-link\fR is doing. This
+typically includes a message for each bitcode file linked in and for each
+library found.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-link\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+gccld
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-nm.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-nm.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-nm.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-nm.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,218 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-NM 1"
+.TH LLVM-NM 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-nm \- list LLVM bitcode file's symbol table
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-nm\fR [\fIoptions\fR] [\fIfilenames...\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-nm\fR utility lists the names of symbols from the \s-1LLVM\s0 bitcode files,
+or \fBar\fR archives containing \s-1LLVM\s0 bitcode files, named on the command line.
+Each symbol is listed along with some simple information about its provenance.
+If no file name is specified, or \fI\-\fR is used as a file name, \fBllvm-nm\fR will
+process a bitcode file on its standard input stream.
+.PP
+\&\fBllvm-nm\fR's default output format is the traditional \s-1BSD\s0 \fBnm\fR output format.
+Each such output record consists of an (optional) 8\-digit hexadecimal address,
+followed by a type code character, followed by a name, for each symbol. One
+record is printed per line; fields are separated by spaces. When the address is
+omitted, it is replaced by 8 spaces.
+.PP
+Type code characters currently supported, and their meanings, are as follows:
+.IP "U" 4
+.IX Item "U"
+Named object is referenced but undefined in this bitcode file
+.IP "C" 4
+.IX Item "C"
+Common (multiple definitions link together into one def)
+.IP "W" 4
+.IX Item "W"
+Weak reference (multiple definitions link together into zero or one definitions)
+.IP "t" 4
+.IX Item "t"
+Local function (text) object
+.IP "T" 4
+.IX Item "T"
+Global function (text) object
+.IP "d" 4
+.IX Item "d"
+Local data object
+.IP "D" 4
+.IX Item "D"
+Global data object
+.IP "?" 4
+Something unrecognizable
+.PP
+Because \s-1LLVM\s0 bitcode files typically contain objects that are not considered to
+have addresses until they are linked into an executable image or dynamically
+compiled \*(L"just-in-time\*(R", \fBllvm-nm\fR does not print an address for any symbol,
+even symbols which are defined in the bitcode file.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-P\fR" 4
+.IX Item "-P"
+Use \s-1POSIX\s0.2 output format. Alias for \fB\-\-format=posix\fR.
+.IP "\fB\-B\fR (default)" 4
+.IX Item "-B (default)"
+Use \s-1BSD\s0 output format. Alias for \fB\-\-format=bsd\fR.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command-line options and their meanings.
+.IP "\fB\-\-defined\-only\fR" 4
+.IX Item "--defined-only"
+Print only symbols defined in this bitcode file (as opposed to
+symbols which may be referenced by objects in this file, but not
+defined in this file.)
+.IP "\fB\-\-extern\-only\fR, \fB\-g\fR" 4
+.IX Item "--extern-only, -g"
+Print only symbols whose definitions are external; that is, accessible
+from other bitcode files.
+.IP "\fB\-\-undefined\-only\fR, \fB\-u\fR" 4
+.IX Item "--undefined-only, -u"
+Print only symbols referenced but not defined in this bitcode file.
+.IP "\fB\-\-format=\fR\fIfmt\fR, \fB\-f\fR" 4
+.IX Item "--format=fmt, -f"
+Select an output format; \fIfmt\fR may be \fIsysv\fR, \fIposix\fR, or \fIbsd\fR. The
+default is \fIbsd\fR.
+.SH "BUGS"
+.IX Header "BUGS"
+\&\fBllvm-nm\fR cannot demangle \*(C+ mangled names, like \s-1GNU\s0 \fBnm\fR can.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+\&\fBllvm-nm\fR exits with an exit code of zero.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-dis, \fIar\fR\|(1), \fInm\fR\|(1)
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-prof.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-prof.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-prof.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-prof.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,172 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-PROF 1"
+.TH LLVM-PROF 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-prof \- print execution profile of LLVM program
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-prof\fR [\fIoptions\fR] [\fIbitcode file\fR] [\fIllvmprof.out\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-prof\fR tool reads in an \fIllvmprof.out\fR file (which can
+optionally use a specific file with the third program argument), a bitcode file
+for the program, and produces a human readable report, suitable for determining
+where the program hotspots are.
+.PP
+This program is often used in conjunction with the \fIutils/profile.pl\fR
+script. This script automatically instruments a program, runs it with the \s-1JIT\s0,
+then runs \fBllvm-prof\fR to format a report. To get more information about
+\&\fIutils/profile.pl\fR, execute it with the \fB\-help\fR option.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-\-annotated\-llvm\fR or \fB\-A\fR" 4
+.IX Item "--annotated-llvm or -A"
+In addition to the normal report printed, print out the code for the
+program, annotated with execution frequency information. This can be
+particularly useful when trying to visualize how frequently basic blocks
+are executed. This is most useful with basic block profiling
+information or better.
+.IP "\fB\-\-print\-all\-code\fR" 4
+.IX Item "--print-all-code"
+Using this option enables the \fB\-\-annotated\-llvm\fR option, but it
+prints the entire module, instead of just the most commonly executed
+functions.
+.IP "\fB\-\-time\-passes\fR" 4
+.IX Item "--time-passes"
+Record the amount of time needed for each pass and print it to standard
+error.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+\&\fBllvm-prof\fR returns 1 if it cannot load the bitcode file or the profile
+information. Otherwise, it exits with zero.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+\&\fBllvm-prof\fR is maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ranlib.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ranlib.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ranlib.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-ranlib.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,166 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-RANLIB 1"
+.TH LLVM-RANLIB 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-ranlib \- Generate index for LLVM archive
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-ranlib\fR [\-\-version] [\-help] <archive\-file>
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-ranlib\fR command is similar to the common Unix utility, \f(CW\*(C`ranlib\*(C'\fR. It
+adds or updates the symbol table in an \s-1LLVM\s0 archive file. Note that using the
+\&\fBllvm-ar\fR modifier \fIs\fR is usually more efficient than running \fBllvm-ranlib\fR
+which is only provided only for completness and compatibility. Unlike other
+implementations of \f(CW\*(C`ranlib\*(C'\fR, \fBllvm-ranlib\fR indexes \s-1LLVM\s0 bitcode files, not
+native object modules. You can list the contents of the symbol table with the
+\&\f(CW\*(C`llvm\-nm \-s\*(C'\fR command.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fIarchive-file\fR" 4
+.IX Item "archive-file"
+Specifies the archive-file to which the symbol table is added or updated.
+.IP "\fI\-\-version\fR" 4
+.IX Item "--version"
+Print the version of \fBllvm-ranlib\fR and exit without building a symbol table.
+.IP "\fI\-help\fR" 4
+.IX Item "-help"
+Print usage help for \fBllvm-ranlib\fR and exit without building a symbol table.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBllvm-ranlib\fR succeeds, it will exit with 0. If an error occurs, a non-zero
+exit code will be returned.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+llvm-ar, \fIranlib\fR\|(1)
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-stress.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-stress.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-stress.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/llvm-stress.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,157 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "LLVM-STRESS 1"
+.TH LLVM-STRESS 1 "2012-02-26" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+llvm\-stress \- generate random .ll files
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBllvm-cov\fR [\-gcno=filename] [\-gcda=filename] [dump]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBllvm-stress\fR tool is used to generate random .ll files that can be used to
+test different components of \s-1LLVM\s0.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output filename.
+.IP "\fB\-size\fR \fIsize\fR" 4
+.IX Item "-size size"
+Specify the size of the generated .ll file.
+.IP "\fB\-seed\fR \fIseed\fR" 4
+.IX Item "-seed seed"
+Specify the seed to be used for the randomly generated instructions.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+\&\fBllvm-stress\fR returns 0.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+\&\fBllvm-stress\fR is maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/opt.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/opt.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/opt.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/opt.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,249 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "OPT 1"
+.TH OPT 1 "2011-04-08" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+opt \- LLVM optimizer
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBopt\fR [\fIoptions\fR] [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBopt\fR command is the modular \s-1LLVM\s0 optimizer and analyzer. It takes \s-1LLVM\s0
+source files as input, runs the specified optimizations or analyses on it, and then
+outputs the optimized file or the analysis results. The function of
+\&\fBopt\fR depends on whether the \fB\-analyze\fR option is given.
+.PP
+When \fB\-analyze\fR is specified, \fBopt\fR performs various analyses of the input
+source. It will usually print the results on standard output, but in a few
+cases, it will print output to standard error or generate a file with the
+analysis output, which is usually done when the output is meant for another
+program.
+.PP
+While \fB\-analyze\fR is \fInot\fR given, \fBopt\fR attempts to produce an optimized
+output file. The optimizations available via \fBopt\fR depend upon what
+libraries were linked into it as well as any additional libraries that have
+been loaded with the \fB\-load\fR option. Use the \fB\-help\fR option to determine
+what optimizations you can use.
+.PP
+If \fIfilename\fR is omitted from the command line or is \fI\-\fR, \fBopt\fR reads its
+input from standard input. Inputs can be in either the \s-1LLVM\s0 assembly language
+format (.ll) or the \s-1LLVM\s0 bitcode format (.bc).
+.PP
+If an output filename is not specified with the \fB\-o\fR option, \fBopt\fR
+writes its output to the standard output.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+Enable binary output on terminals. Normally, \fBopt\fR will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+\&\fBopt\fR will write raw bitcode regardless of the output device.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output filename.
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+Write output in \s-1LLVM\s0 intermediate language (instead of bitcode).
+.IP "\fB\-{passname}\fR" 4
+.IX Item "-{passname}"
+\&\fBopt\fR provides the ability to run any of \s-1LLVM\s0's optimization or analysis passes
+in any order. The \fB\-help\fR option lists all the passes available. The order in
+which the options occur on the command line are the order in which they are
+executed (within pass constraints).
+.IP "\fB\-std\-compile\-opts\fR" 4
+.IX Item "-std-compile-opts"
+This is short hand for a standard list of \fIcompile time optimization\fR passes.
+This is typically used to optimize the output from the llvm-gcc front end. It
+might be useful for other front end compilers as well. To discover the full set
+of options available, use the following command:
+.Sp
+.Vb 1
+\& llvm\-as < /dev/null | opt \-std\-compile\-opts \-disable\-output \-debug\-pass=Arguments
+.Ve
+.IP "\fB\-disable\-inlining\fR" 4
+.IX Item "-disable-inlining"
+This option is only meaningful when \fB\-std\-compile\-opts\fR is given. It simply
+removes the inlining pass from the standard list.
+.IP "\fB\-disable\-opt\fR" 4
+.IX Item "-disable-opt"
+This option is only meaningful when \fB\-std\-compile\-opts\fR is given. It disables
+most, but not all, of the \fB\-std\-compile\-opts\fR. The ones that remain are
+\&\fB\-verify\fR, \fB\-lower\-setjmp\fR, and \fB\-funcresolve\fR.
+.IP "\fB\-strip\-debug\fR" 4
+.IX Item "-strip-debug"
+This option causes opt to strip debug information from the module before
+applying other optimizations. It is essentially the same as \fB\-strip\fR but it
+ensures that stripping of debug information is done first.
+.IP "\fB\-verify\-each\fR" 4
+.IX Item "-verify-each"
+This option causes opt to add a verify pass after every pass otherwise specified
+on the command line (including \fB\-verify\fR). This is useful for cases where it
+is suspected that a pass is creating an invalid module but it is not clear which
+pass is doing it. The combination of \fB\-std\-compile\-opts\fR and \fB\-verify\-each\fR
+can quickly track down this kind of problem.
+.IP "\fB\-profile\-info\-file\fR \fIfilename\fR" 4
+.IX Item "-profile-info-file filename"
+Specify the name of the file loaded by the \-profile\-loader option.
+.IP "\fB\-stats\fR" 4
+.IX Item "-stats"
+Print statistics.
+.IP "\fB\-time\-passes\fR" 4
+.IX Item "-time-passes"
+Record the amount of time needed for each pass and print it to standard
+error.
+.IP "\fB\-debug\fR" 4
+.IX Item "-debug"
+If this is a debug build, this option will enable debug printouts
+from passes which use the \fI\s-1\fIDEBUG\s0()\fI\fR macro. See the \fB\s-1LLVM\s0 Programmer's
+Manual\fR, section \fI#DEBUG\fR for more information.
+.IP "\fB\-load\fR=\fIplugin\fR" 4
+.IX Item "-load=plugin"
+Load the dynamic object \fIplugin\fR. This object should register new optimization
+or analysis passes. Once loaded, the object will add new command line options to
+enable various optimizations or analyses. To see the new complete list of
+optimizations, use the \fB\-help\fR and \fB\-load\fR options together. For example:
+.Sp
+.Vb 1
+\& opt \-load=plugin.so \-help
+.Ve
+.IP "\fB\-p\fR" 4
+.IX Item "-p"
+Print module after each transformation.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBopt\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by the \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/man/man1/tblgen.1
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/man/man1/tblgen.1?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/man/man1/tblgen.1 (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/man/man1/tblgen.1 Tue May 22 14:32:29 2012
@@ -0,0 +1,232 @@
+.\" Automatically generated by Pod::Man 2.1801 (Pod::Simple 3.05)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings. \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote. \*(C+ will
+.\" give a nicer C++. Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+. ds -- \(*W-
+. ds PI pi
+. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
+. ds L" ""
+. ds R" ""
+. ds C` ""
+. ds C' ""
+'br\}
+.el\{\
+. ds -- \|\(em\|
+. ds PI \(*p
+. ds L" ``
+. ds R" ''
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD. Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.ie \nF \{\
+. de IX
+. tm Index:\\$1\t\\n%\t"\\$2"
+..
+. nr % 0
+. rr F
+.\}
+.el \{\
+. de IX
+..
+.\}
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear. Run. Save yourself. No user-serviceable parts.
+. \" fudge factors for nroff and troff
+.if n \{\
+. ds #H 0
+. ds #V .8m
+. ds #F .3m
+. ds #[ \f1
+. ds #] \fP
+.\}
+.if t \{\
+. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+. ds #V .6m
+. ds #F 0
+. ds #[ \&
+. ds #] \&
+.\}
+. \" simple accents for nroff and troff
+.if n \{\
+. ds ' \&
+. ds ` \&
+. ds ^ \&
+. ds , \&
+. ds ~ ~
+. ds /
+.\}
+.if t \{\
+. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+. \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+. \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+. \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+. ds : e
+. ds 8 ss
+. ds o a
+. ds d- d\h'-1'\(ga
+. ds D- D\h'-1'\(hy
+. ds th \o'bp'
+. ds Th \o'LP'
+. ds ae ae
+. ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "TBLGEN 1"
+.TH TBLGEN 1 "2012-02-26" "CVS" "LLVM Command Guide"
+.\" For nroff, turn off justification. Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+tblgen \- Target Description To C++ Code Generator
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBtblgen\fR [\fIoptions\fR] [\fIfilename\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBtblgen\fR translates from target description (.td) files into \*(C+ code that can
+be included in the definition of an \s-1LLVM\s0 target library. Most users of \s-1LLVM\s0 will
+not need to use this program. It is only for assisting with writing an \s-1LLVM\s0
+target backend.
+.PP
+The input and output of \fBtblgen\fR is beyond the scope of this short
+introduction. Please see the \fICodeGeneration\fR page in the \s-1LLVM\s0 documentation.
+.PP
+The \fIfilename\fR argument specifies the name of a Target Description (.td) file
+to read as input.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a summary of command line options.
+.IP "\fB\-o\fR \fIfilename\fR" 4
+.IX Item "-o filename"
+Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBtblgen\fR
+sends its output to standard output.
+.IP "\fB\-I\fR \fIdirectory\fR" 4
+.IX Item "-I directory"
+Specify where to find other target description files for inclusion. The
+\&\fIdirectory\fR value should be a full or partial path to a directory that contains
+target description files.
+.IP "\fB\-asmparsernum\fR \fIN\fR" 4
+.IX Item "-asmparsernum N"
+Make \-gen\-asm\-parser emit assembly writer number \fIN\fR.
+.IP "\fB\-asmwriternum\fR \fIN\fR" 4
+.IX Item "-asmwriternum N"
+Make \-gen\-asm\-writer emit assembly writer number \fIN\fR.
+.IP "\fB\-class\fR \fIclass Name\fR" 4
+.IX Item "-class class Name"
+Print the enumeration list for this class.
+.IP "\fB\-print\-records\fR" 4
+.IX Item "-print-records"
+Print all records to standard output (default).
+.IP "\fB\-print\-enums\fR" 4
+.IX Item "-print-enums"
+Print enumeration values for a class
+.IP "\fB\-print\-sets\fR" 4
+.IX Item "-print-sets"
+Print expanded sets for testing \s-1DAG\s0 exprs.
+.IP "\fB\-gen\-emitter\fR" 4
+.IX Item "-gen-emitter"
+Generate machine code emitter.
+.IP "\fB\-gen\-register\-info\fR" 4
+.IX Item "-gen-register-info"
+Generate registers and register classes info.
+.IP "\fB\-gen\-instr\-info\fR" 4
+.IX Item "-gen-instr-info"
+Generate instruction descriptions.
+.IP "\fB\-gen\-asm\-writer\fR" 4
+.IX Item "-gen-asm-writer"
+Generate the assembly writer.
+.IP "\fB\-gen\-disassembler\fR" 4
+.IX Item "-gen-disassembler"
+Generate disassembler.
+.IP "\fB\-gen\-pseudo\-lowering\fR" 4
+.IX Item "-gen-pseudo-lowering"
+Generate pseudo instruction lowering.
+.IP "\fB\-gen\-dag\-isel\fR" 4
+.IX Item "-gen-dag-isel"
+Generate a \s-1DAG\s0 (Directed Acycle Graph) instruction selector.
+.IP "\fB\-gen\-asm\-matcher\fR" 4
+.IX Item "-gen-asm-matcher"
+Generate assembly instruction matcher.
+.IP "\fB\-gen\-dfa\-packetizer\fR" 4
+.IX Item "-gen-dfa-packetizer"
+Generate \s-1DFA\s0 Packetizer for \s-1VLIW\s0 targets.
+.IP "\fB\-gen\-fast\-isel\fR" 4
+.IX Item "-gen-fast-isel"
+Generate a \*(L"fast\*(R" instruction selector.
+.IP "\fB\-gen\-subtarget\fR" 4
+.IX Item "-gen-subtarget"
+Generate subtarget enumerations.
+.IP "\fB\-gen\-intrinsic\fR" 4
+.IX Item "-gen-intrinsic"
+Generate intrinsic information.
+.IP "\fB\-gen\-tgt\-intrinsic\fR" 4
+.IX Item "-gen-tgt-intrinsic"
+Generate target intrinsic information.
+.IP "\fB\-gen\-enhanced\-disassembly\-info\fR" 4
+.IX Item "-gen-enhanced-disassembly-info"
+Generate enhanced disassembly info.
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+Show the version number of this program.
+.SH "EXIT STATUS"
+.IX Header "EXIT STATUS"
+If \fBtblgen\fR succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+.SH "AUTHORS"
+.IX Header "AUTHORS"
+Maintained by The \s-1LLVM\s0 Team (<http://llvm.org/>).
Added: www-releases/trunk/3.1/docs/CommandGuide/manpage.css
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/manpage.css?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/manpage.css (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/manpage.css Tue May 22 14:32:29 2012
@@ -0,0 +1,256 @@
+/* Based on http://www.perldoc.com/css/perldoc.css */
+
+ at import url("../llvm.css");
+
+body { font-family: Arial,Helvetica; }
+
+blockquote { margin: 10pt; }
+
+h1, a { color: #336699; }
+
+
+/*** Top menu style ****/
+.mmenuon {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ff6600; font-size: 10pt;
+}
+.mmenuoff {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ffffff; font-size: 10pt;
+}
+.cpyright {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ffffff; font-size: xx-small;
+}
+.cpyrightText {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #ffffff; font-size: xx-small;
+}
+.sections {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 11pt;
+}
+.dsections {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 12pt;
+}
+.slink {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #000000; font-size: 9pt;
+}
+
+.slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; }
+
+.maintitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 18pt;
+}
+.dblArrow {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: small;
+}
+.menuSec {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: small;
+}
+
+.newstext {
+ font-family: Arial,Helvetica; font-size: small;
+}
+
+.linkmenu {
+ font-family: Arial,Helvetica; color: #000000; font-weight: bold;
+ text-decoration: none;
+}
+
+P {
+ font-family: Arial,Helvetica;
+}
+
+PRE {
+ font-size: 10pt;
+}
+.quote {
+ font-family: Times; text-decoration: none;
+ color: #000000; font-size: 9pt; font-style: italic;
+}
+.smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; }
+.std { font-family: Arial,Helvetica; color: #000000; }
+.meerkatTitle {
+ font-family: sans-serif; font-size: x-small; color: black; }
+
+.meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black }
+.meerkatCategory {
+ font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic;
+ color: brown; }
+.meerkatChannel {
+ font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; }
+.meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; }
+
+.tocTitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #333333; font-size: 10pt;
+}
+
+.toc-item {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #336699; font-size: 10pt; text-decoration: underline;
+}
+
+.perlVersion {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #336699; font-size: 10pt; text-decoration: none;
+}
+
+.podTitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #000000;
+}
+
+.docTitle {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #000000; font-size: 10pt;
+}
+.dotDot {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #000000; font-size: 9pt;
+}
+
+.docSec {
+ font-family: Arial,Helvetica; font-weight: normal;
+ color: #333333; font-size: 9pt;
+}
+.docVersion {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 10pt;
+}
+
+.docSecs-on {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #ff0000; font-size: 10pt;
+}
+.docSecs-off {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #333333; font-size: 10pt;
+}
+
+h2 {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: medium;
+}
+h1 {
+ font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: large;
+}
+
+DL {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: none;
+ color: #333333; font-size: 10pt;
+}
+
+UL > LI > A {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #336699; font-size: 10pt;
+}
+
+.moduleInfo {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #333333; font-size: 11pt;
+}
+
+.moduleInfoSec {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 10pt;
+}
+
+.moduleInfoVal {
+ font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline;
+ color: #000000; font-size: 10pt;
+}
+
+.cpanNavTitle {
+ font-family: Arial,Helvetica; font-weight: bold;
+ color: #ffffff; font-size: 10pt;
+}
+.cpanNavLetter {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #333333; font-size: 9pt;
+}
+.cpanCat {
+ font-family: Arial,Helvetica; font-weight: bold; text-decoration: none;
+ color: #336699; font-size: 9pt;
+}
+
+.bttndrkblue-bkgd-top {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif);
+}
+.bttndrkblue-bkgd-left {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif);
+}
+.bttndrkblue-bkgd {
+ padding-top: 0px;
+ padding-bottom: 0px;
+ margin-bottom: 0px;
+ margin-top: 0px;
+ background-repeat: no-repeat;
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif);
+ vertical-align: top;
+}
+.bttndrkblue-bkgd-right {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif);
+}
+.bttndrkblue-bkgd-bottom {
+ background-color: #225688;
+ background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif);
+}
+.bttndrkblue-text a {
+ color: #ffffff;
+ text-decoration: none;
+}
+a.bttndrkblue-text:hover {
+ color: #ffDD3C;
+ text-decoration: none;
+}
+.bg-ltblue {
+ background-color: #f0f5fa;
+}
+
+.border-left-b {
+ background: #f0f5fa url(/i/corner-leftline.gif) repeat-y;
+}
+
+.border-right-b {
+ background: #f0f5fa url(/i/corner-rightline.gif) repeat-y;
+}
+
+.border-top-b {
+ background: #f0f5fa url(/i/corner-topline.gif) repeat-x;
+}
+
+.border-bottom-b {
+ background: #f0f5fa url(/i/corner-botline.gif) repeat-x;
+}
+
+.border-right-w {
+ background: #ffffff url(/i/corner-rightline.gif) repeat-y;
+}
+
+.border-top-w {
+ background: #ffffff url(/i/corner-topline.gif) repeat-x;
+}
+
+.border-bottom-w {
+ background: #ffffff url(/i/corner-botline.gif) repeat-x;
+}
+
+.bg-white {
+ background-color: #ffffff;
+}
+
+.border-left-w {
+ background: #ffffff url(/i/corner-leftline.gif) repeat-y;
+}
Added: www-releases/trunk/3.1/docs/CommandGuide/opt.pod
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/opt.pod?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/opt.pod (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/opt.pod Tue May 22 14:32:29 2012
@@ -0,0 +1,143 @@
+=pod
+
+=head1 NAME
+
+opt - LLVM optimizer
+
+=head1 SYNOPSIS
+
+B<opt> [I<options>] [I<filename>]
+
+=head1 DESCRIPTION
+
+The B<opt> command is the modular LLVM optimizer and analyzer. It takes LLVM
+source files as input, runs the specified optimizations or analyses on it, and then
+outputs the optimized file or the analysis results. The function of
+B<opt> depends on whether the B<-analyze> option is given.
+
+When B<-analyze> is specified, B<opt> performs various analyses of the input
+source. It will usually print the results on standard output, but in a few
+cases, it will print output to standard error or generate a file with the
+analysis output, which is usually done when the output is meant for another
+program.
+
+While B<-analyze> is I<not> given, B<opt> attempts to produce an optimized
+output file. The optimizations available via B<opt> depend upon what
+libraries were linked into it as well as any additional libraries that have
+been loaded with the B<-load> option. Use the B<-help> option to determine
+what optimizations you can use.
+
+If I<filename> is omitted from the command line or is I<->, B<opt> reads its
+input from standard input. Inputs can be in either the LLVM assembly language
+format (.ll) or the LLVM bitcode format (.bc).
+
+If an output filename is not specified with the B<-o> option, B<opt>
+writes its output to the standard output.
+
+=head1 OPTIONS
+
+=over
+
+=item B<-f>
+
+Enable binary output on terminals. Normally, B<opt> will refuse to
+write raw bitcode output if the output stream is a terminal. With this option,
+B<opt> will write raw bitcode regardless of the output device.
+
+=item B<-help>
+
+Print a summary of command line options.
+
+=item B<-o> I<filename>
+
+Specify the output filename.
+
+=item B<-S>
+
+Write output in LLVM intermediate language (instead of bitcode).
+
+=item B<-{passname}>
+
+B<opt> provides the ability to run any of LLVM's optimization or analysis passes
+in any order. The B<-help> option lists all the passes available. The order in
+which the options occur on the command line are the order in which they are
+executed (within pass constraints).
+
+=item B<-std-compile-opts>
+
+This is short hand for a standard list of I<compile time optimization> passes.
+This is typically used to optimize the output from the llvm-gcc front end. It
+might be useful for other front end compilers as well. To discover the full set
+of options available, use the following command:
+
+ llvm-as < /dev/null | opt -std-compile-opts -disable-output -debug-pass=Arguments
+
+=item B<-disable-inlining>
+
+This option is only meaningful when B<-std-compile-opts> is given. It simply
+removes the inlining pass from the standard list.
+
+=item B<-disable-opt>
+
+This option is only meaningful when B<-std-compile-opts> is given. It disables
+most, but not all, of the B<-std-compile-opts>. The ones that remain are
+B<-verify>, B<-lower-setjmp>, and B<-funcresolve>.
+
+=item B<-strip-debug>
+
+This option causes opt to strip debug information from the module before
+applying other optimizations. It is essentially the same as B<-strip> but it
+ensures that stripping of debug information is done first.
+
+=item B<-verify-each>
+
+This option causes opt to add a verify pass after every pass otherwise specified
+on the command line (including B<-verify>). This is useful for cases where it
+is suspected that a pass is creating an invalid module but it is not clear which
+pass is doing it. The combination of B<-std-compile-opts> and B<-verify-each>
+can quickly track down this kind of problem.
+
+=item B<-profile-info-file> I<filename>
+
+Specify the name of the file loaded by the -profile-loader option.
+
+=item B<-stats>
+
+Print statistics.
+
+=item B<-time-passes>
+
+Record the amount of time needed for each pass and print it to standard
+error.
+
+=item B<-debug>
+
+If this is a debug build, this option will enable debug printouts
+from passes which use the I<DEBUG()> macro. See the B<LLVM Programmer's
+Manual>, section I<#DEBUG> for more information.
+
+=item B<-load>=I<plugin>
+
+Load the dynamic object I<plugin>. This object should register new optimization
+or analysis passes. Once loaded, the object will add new command line options to
+enable various optimizations or analyses. To see the new complete list of
+optimizations, use the B<-help> and B<-load> options together. For example:
+
+ opt -load=plugin.so -help
+
+=item B<-p>
+
+Print module after each transformation.
+
+=back
+
+=head1 EXIT STATUS
+
+If B<opt> succeeds, it will exit with 0. Otherwise, if an error
+occurs, it will exit with a non-zero value.
+
+=head1 AUTHORS
+
+Maintained by the LLVM Team (L<http://llvm.org/>).
+
+=cut
Added: www-releases/trunk/3.1/docs/CommandGuide/pod2htmd.tmp
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/pod2htmd.tmp?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/pod2htmd.tmp (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/pod2htmd.tmp Tue May 22 14:32:29 2012
@@ -0,0 +1,29 @@
+.
+.
+lli ./lli.pod:
+llvm-bcanalyzer ./llvm-bcanalyzer.pod:
+llvm-nm ./llvm-nm.pod:
+opt ./opt.pod:
+html ./html:
+llvm-diff ./llvm-diff.pod:
+llvm-link ./llvm-link.pod:
+llvm-ar ./llvm-ar.pod:
+lit ./lit.pod:
+llc ./llc.pod:
+tblgen ./tblgen.pod:
+llvm-config ./llvm-config.pod:
+llvm-extract ./llvm-extract.pod:
+llvm-as ./llvm-as.pod:
+llvm-prof ./llvm-prof.pod:
+llvm-build ./llvm-build.pod:
+bugpoint ./bugpoint.pod:./html/bugpoint.pod:
+llvm-cov ./llvm-cov.pod:
+man ./man:
+index ./index.pod:
+llvm-stress ./llvm-stress.pod:
+llvm-ranlib ./llvm-ranlib.pod:
+FileCheck ./FileCheck.pod:
+man1 ./man/man1:
+llvm-ld ./llvm-ld.pod:
+ps ./ps:
+llvm-dis ./llvm-dis.pod:
Added: www-releases/trunk/3.1/docs/CommandGuide/pod2htmi.tmp
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/pod2htmi.tmp?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/pod2htmi.tmp (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/pod2htmi.tmp Tue May 22 14:32:29 2012
@@ -0,0 +1,2 @@
+.
+.
Added: www-releases/trunk/3.1/docs/CommandGuide/ps/FileCheck.ps
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/ps/FileCheck.ps?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/ps/FileCheck.ps (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/ps/FileCheck.ps Tue May 22 14:32:29 2012
@@ -0,0 +1,618 @@
+%!PS-Adobe-3.0
+%%Creator: groff version 1.18.1
+%%CreationDate: Tue May 22 00:24:04 2012
+%%DocumentNeededResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+%%+ font Courier
+%%DocumentSuppliedResources: procset grops 1.18 1
+%%Pages: 4
+%%PageOrder: Ascend
+%%Orientation: Portrait
+%%EndComments
+%%BeginProlog
+%%BeginResource: procset grops 1.18 1
+/setpacking where{
+pop
+currentpacking
+true setpacking
+}if
+/grops 120 dict dup begin
+/SC 32 def
+/A/show load def
+/B{0 SC 3 -1 roll widthshow}bind def
+/C{0 exch ashow}bind def
+/D{0 exch 0 SC 5 2 roll awidthshow}bind def
+/E{0 rmoveto show}bind def
+/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def
+/G{0 rmoveto 0 exch ashow}bind def
+/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/I{0 exch rmoveto show}bind def
+/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def
+/K{0 exch rmoveto 0 exch ashow}bind def
+/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/M{rmoveto show}bind def
+/N{rmoveto 0 SC 3 -1 roll widthshow}bind def
+/O{rmoveto 0 exch ashow}bind def
+/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/Q{moveto show}bind def
+/R{moveto 0 SC 3 -1 roll widthshow}bind def
+/S{moveto 0 exch ashow}bind def
+/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/SF{
+findfont exch
+[exch dup 0 exch 0 exch neg 0 0]makefont
+dup setfont
+[exch/setfont cvx]cvx bind def
+}bind def
+/MF{
+findfont
+[5 2 roll
+0 3 1 roll
+neg 0 0]makefont
+dup setfont
+[exch/setfont cvx]cvx bind def
+}bind def
+/level0 0 def
+/RES 0 def
+/PL 0 def
+/LS 0 def
+/MANUAL{
+statusdict begin/manualfeed true store end
+}bind def
+/PLG{
+gsave newpath clippath pathbbox grestore
+exch pop add exch pop
+}bind def
+/BP{
+/level0 save def
+1 setlinecap
+1 setlinejoin
+72 RES div dup scale
+LS{
+90 rotate
+}{
+0 PL translate
+}ifelse
+1 -1 scale
+}bind def
+/EP{
+level0 restore
+showpage
+}bind def
+/DA{
+newpath arcn stroke
+}bind def
+/SN{
+transform
+.25 sub exch .25 sub exch
+round .25 add exch round .25 add exch
+itransform
+}bind def
+/DL{
+SN
+moveto
+SN
+lineto stroke
+}bind def
+/DC{
+newpath 0 360 arc closepath
+}bind def
+/TM matrix def
+/DE{
+TM currentmatrix pop
+translate scale newpath 0 0 .5 0 360 arc closepath
+TM setmatrix
+}bind def
+/RC/rcurveto load def
+/RL/rlineto load def
+/ST/stroke load def
+/MT/moveto load def
+/CL/closepath load def
+/Fr{
+setrgbcolor fill
+}bind def
+/Fk{
+setcmykcolor fill
+}bind def
+/Fg{
+setgray fill
+}bind def
+/FL/fill load def
+/LW/setlinewidth load def
+/Cr/setrgbcolor load def
+/Ck/setcmykcolor load def
+/Cg/setgray load def
+/RE{
+findfont
+dup maxlength 1 index/FontName known not{1 add}if dict begin
+{
+1 index/FID ne{def}{pop pop}ifelse
+}forall
+/Encoding exch def
+dup/FontName exch def
+currentdict end definefont pop
+}bind def
+/DEFS 0 def
+/EBEGIN{
+moveto
+DEFS begin
+}bind def
+/EEND/end load def
+/CNT 0 def
+/level1 0 def
+/PBEGIN{
+/level1 save def
+translate
+div 3 1 roll div exch scale
+neg exch neg exch translate
+0 setgray
+0 setlinecap
+1 setlinewidth
+0 setlinejoin
+10 setmiterlimit
+[]0 setdash
+/setstrokeadjust where{
+pop
+false setstrokeadjust
+}if
+/setoverprint where{
+pop
+false setoverprint
+}if
+newpath
+/CNT countdictstack def
+userdict begin
+/showpage{}def
+}bind def
+/PEND{
+clear
+countdictstack CNT sub{end}repeat
+level1 restore
+}bind def
+end def
+/setpacking where{
+pop
+setpacking
+}if
+%%EndResource
+%%IncludeResource: font Times-Roman
+%%IncludeResource: font Times-Bold
+%%IncludeResource: font Times-Italic
+%%IncludeResource: font Courier
+grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72
+def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron
+/scaron/zcaron/Ydieresis/trademark/quotesingle/Euro/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent
+/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen
+/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon
+/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O
+/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex
+/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y
+/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft
+/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl
+/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut
+/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash
+/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen
+/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft
+/logicalnot/minus/registered/macron/degree/plusminus/twosuperior
+/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior
+/ordmasculine/guilsinglright/onequarter/onehalf/threequarters
+/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE
+/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn
+/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
+/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
+/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash
+/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def
+/Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE
+/Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE
+%%EndProlog
+%%Page: 1 1
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF 115.62<46494c45434845434b283129204c4c>72 48 R
+<564d20436f6d6d616e64204775696465>-1 E<46494c45434845434b283129>118.12 E
+/F1 10.95/Times-Bold at 0 SF -.219<4e41>72 84 S<4d45>.219 E F0
+<46696c65436865636b20ad20466c65>108 96 Q
+<7869626c65207061747465726e206d61746368696e67208c6c652076>-.15 E
+<6572698c6572>-.15 E F1<53594e4f50534953>72 112.8 Q/F2 10/Times-Bold at 0
+SF<46696c65436865636b>108 124.8 Q/F3 10/Times-Italic at 0 SF<6d617463>2.5 E
+<682d8c6c656e616d65>-.15 E F0<5b>2.5 E F3<adad63>A<686563>-.15 E
+<6bad7072>-.2 E<658c783d585858>-.37 E F0 2.5<5d5b>C F3
+<adad737472696374ad77686974657370616365>-2.5 E F0<5d>A F1
+<4445534352495054494f4e>72 141.6 Q F2<46696c65436865636b>108 153.6 Q F0
+.52<7265616473207477>3.02 F 3.02<6f8c>-.1 G .519<6c657320286f6e65206672
+6f6d207374616e6461726420696e7075742c20616e64206f6e652073706563698c656420
+6f6e2074686520636f6d6d616e64206c696e652920616e642075736573206f6e65>-3.02
+F 1.495<746f2076>108 165.6 R 1.495<657269667920746865206f74686572>-.15 F
+6.496<2e54>-.55 G 1.496<6869732062656861>-6.496 F 1.496<76696f7220697320
+706172746963756c61726c792075736566756c20666f7220746865207465737473756974
+652c2077686963682077>-.2 F 1.496<616e747320746f2076>-.1 F 1.496
+<6572696679207468617420746865>-.15 F .009<6f7574707574206f6620736f6d6520
+746f6f6c2028652e672e206c6c632920636f6e7461696e73207468652065>108 177.6 R
+.009<7870656374656420696e666f726d6174696f6e2028666f722065>-.15 F .009
+<78616d706c652c2061206d6f>-.15 F .008
+<7673642066726f6d20657370206f72207768617465>-.15 F -.15<7665>-.25 G<72>
+.15 E .993<697320696e746572657374696e67292e>108 189.6 R .993
+<546869732069732073696d696c617220746f207573696e6720677265702c2062>5.993
+F .994<7574206974206973206f7074696d697a656420666f72206d61746368696e6720
+6d756c7469706c6520646966>-.2 F .994<666572656e7420696e7075747320696e>
+-.25 F<6f6e65208c6c6520696e20612073706563698c63206f72646572>108 201.6 Q
+<2e>-.55 E<546865>108 218.4 Q F3<6d617463>3.484 E<682d8c6c656e616d65>
+-.15 E F0 .984<8c6c652073706563698c657320746865208c6c65207468617420636f
+6e7461696e7320746865207061747465726e7320746f206d617463682e>3.484 F .983
+<546865208c6c6520746f2076>5.983 F .983<657269667920697320616c>-.15 F -.1
+<7761>-.1 G<7973>.1 E
+<726561642066726f6d207374616e6461726420696e7075742e>108 230.4 Q F1
+<4f5054494f4e53>72 247.2 Q F2<ad68656c70>108 259.2 Q F0<5072696e74206120
+73756d6d617279206f6620636f6d6d616e64206c696e65206f7074696f6e732e>128
+271.2 Q F2<adad636865636bad7072>108 288 Q<658c78>-.18 E F3<7072>2.5 E
+<658c78>-.37 E F0 1.119
+<46696c65436865636b2073656172636865732074686520636f6e74656e7473206f66>
+128 300 R F3<6d617463>3.619 E<682d8c6c656e616d65>-.15 E F0 1.119
+<666f72207061747465726e7320746f206d617463682e>3.619 F 1.12<427920646566>
+6.119 F 1.12<61756c742c207468657365207061747465726e73>-.1 F .273
+<617265207072658c78>128 312 R .272<656420776974682060>-.15 F<60>-.74 E
+/F4 9/Times-Roman at 0 SF<434845434b3a>A F0 -.74<2727>C 5.272<2e49>.74 G
+2.772<6679>-5.272 G<6f7527>-2.772 E 2.772<646c>-.5 G<696b>-2.772 E 2.772
+<6574>-.1 G 2.772<6f75>-2.772 G .272<7365206120646966>-2.772 F .272<6665
+72656e74207072658c782028652e672e2062656361757365207468652073616d6520696e
+707574208c6c65206973>-.25 F 1.429
+<636865636b696e67206d756c7469706c6520646966>128 324 R 1.429
+<666572656e7420746f6f6c206f72206f7074696f6e73292c20746865>-.25 F F2
+<adad636865636bad7072>3.929 E<658c78>-.18 E F0<6172>3.929 E 1.429
+<67756d656e7420616c6c6f>-.18 F 1.43
+<777320796f7520746f20737065636966792061>-.25 F
+<73706563698c63207072658c7820746f206d617463682e>128 336 Q F2
+<adad737472696374ad77686974657370616365>108 352.8 Q F0 .766
+<427920646566>128 364.8 R .765<61756c742c2046696c65436865636b2063616e6f
+6e6963616c697a657320696e70757420686f72697a6f6e74616c20776869746573706163
+65202873706163657320616e642074616273292077686963682063617573657320697420
+746f>-.1 F 1.007<69676e6f726520746865736520646966>128 376.8 R 1.008<6665
+72656e6365732028612073706163652077696c6c206d61746368206120746162292e>
+-.25 F 1.008<54686520adad737472696374ad77686974657370616365206172>6.008
+F 1.008<67756d656e742064697361626c65732074686973>-.18 F<62656861>128
+388.8 Q<76696f72>-.2 E<2e>-.55 E F2<ad76>108 405.6 Q<657273696f6e>-.1 E
+F0<53686f>128 417.6 Q 2.5<7774>-.25 G<68652076>-2.5 E
+<657273696f6e206e756d626572206f6620746869732070726f6772616d2e>-.15 E F1
+<45584954205354>72 434.4 Q -1.04<4154>-.986 G<5553>1.04 E F0<4966>108
+446.4 Q F2<46696c65436865636b>2.925 E F0 -.15<7665>2.925 G .424
+<72698c6573207468617420746865208c6c65206d617463686573207468652065>.15 F
+.424<7870656374656420636f6e74656e74732c2069742065>-.15 F .424
+<78697473207769746820302e>-.15 F .424
+<4f74686572776973652c206966206e6f742c206f7220696620616e>5.424 F
+<6572726f72206f63637572732c2069742077696c6c2065>108 458.4 Q
+<78697420776974682061206e6f6e2d7a65726f2076>-.15 E<616c75652e>-.25 E F1
+<545554>72 475.2 Q<4f5249414c>-.197 E F0 1.58
+<46696c65436865636b206973207479706963616c6c7920757365642066726f6d>108
+487.2 R F4<4c4c>4.08 E<564d>-.9 E F0<7265>4.08 E 1.58
+<6772657373696f6e2074657374732c206265696e6720696e>-.15 F -.2<766f>-.4 G
+-.1<6b65>.2 G 4.08<646f>.1 G 4.08<6e74>-4.08 G<6865>-4.08 E F4 -.36
+<5255>4.08 G<4e>.36 E F0 1.581<6c696e65206f662074686520746573742e>4.08 F
+<41>6.581 E<73696d706c652065>108 499.2 Q
+<78616d706c65206f66207573696e672046696c65436865636b2066726f6d2061>-.15 E
+F4 -.36<5255>2.5 G<4e>.36 E F0<6c696e65206c6f6f6b73206c696b>2.5 E 2.5
+<6574>-.1 G<6869733a>-2.5 E/F5 10/Courier at 0 SF 6<3b52>120 516 S<554e3a20
+6c6c766dad6173203c202573207c206c6c6320ad6d617263683d783836ad3634207c2046
+696c65436865636b202573>-6 E F0 .648<546869732073796e74617820736179732074
+6f2070697065207468652063757272656e74208c6c65202860>108 532.8 R<60257327>
+-.74 E .648<272920696e746f206c6c766d2d61732c2070697065207468617420696e74
+6f206c6c632c207468656e207069706520746865206f7574707574206f66206c6c63>
+-.74 F .659<696e746f2046696c65436865636b2e>108 544.8 R .659
+<54686973206d65616e7320746861742046696c65436865636b2077696c6c2062652076>
+5.659 F .66<6572696679696e6720697473207374616e6461726420696e707574202874
+6865206c6c63206f757470757429206167>-.15 F .66<61696e737420746865>-.05 F
+.793<8c6c656e616d65206172>108 556.8 R .793<67756d656e742073706563698c65
+642028746865206f726967696e616c202e6c6c208c6c652073706563698c656420627920
+60>-.18 F<60257327>-.74 E 3.292<27292e2054>-.74 F 3.292<6f73>-.8 G .792
+<656520686f>-3.292 F 3.292<7774>-.25 G .792<6869732077>-3.292 F .792
+<6f726b732c206c657427>-.1 F 3.292<736c>-.55 G .792<6f6f6b206174>-3.292 F
+<7468652072657374206f6620746865202e6c6c208c6c652028616674657220746865>
+108 568.8 Q F4 -.36<5255>2.5 G<4e>.36 E F0<6c696e65293a>2.5 E F5<646566
+696e6520766f6964204073756231286933322a2025702c2069333220257629207b>120
+585.6 Q<656e7472793a>120 597.6 Q 6<3b43>120 609.6 S
+<4845434b3a20737562313a>-6 E 6<3b43>120 621.6 S<4845434b3a207375626c>-6
+E<2530203d207461696c2063616c6c2069333220406c6c766d2e61746f6d69632e6c6f61
+642e7375622e6933322e7030693332286933322a2025702c2069333220257629>168
+633.6 Q<72657420766f6964>168 645.6 Q<7d>120 657.6 Q
+<646566696e6520766f69642040696e6334286936342a20257029207b>120 681.6 Q
+<656e7472793a>120 693.6 Q 6<3b43>120 705.6 S<4845434b3a20696e63343a>-6 E
+6<3b43>120 717.6 S<4845434b3a20696e6371>-6 E<2530203d207461696c2063616c
+6c2069363420406c6c766d2e61746f6d69632e6c6f61642e6164642e6936342e70306936
+34286936342a2025702c20693634203129>168 729.6 Q F0 188.72
+<43565320323031322d30342d3138>72 768 R<31>205.67 E 0 Cg EP
+%%Page: 2 2
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF 115.62<46494c45434845434b283129204c4c>72 48 R
+<564d20436f6d6d616e64204775696465>-1 E<46494c45434845434b283129>118.12 E
+/F1 10/Courier at 0 SF<72657420766f6964>168 84 Q<7d>120 96 Q F0 .098
+<4865726520796f752063616e2073656520736f6d652060>108 112.8 R<60>-.74 E/F2
+9/Times-Roman at 0 SF<434845434b3a>A F0 1.579 -.74<2727206c>D .099
+<696e65732073706563698c656420696e20636f6d6d656e74732e>.74 F<4e6f>5.099 E
+2.599<7779>-.25 G .099<6f752063616e2073656520686f>-2.599 F 2.599<7774>
+-.25 G .099<6865208c6c6520697320706970656420696e746f>-2.599 F 1.181<6c6c
+766d2d61732c207468656e206c6c632c20616e6420746865206d616368696e6520636f64
+65206f75747075742069732077686174207765206172652076>108 124.8 R 3.68
+<6572696679696e672e2046696c65436865636b>-.15 F 1.18
+<636865636b7320746865206d616368696e65>3.68 F
+<636f6465206f757470757420746f2076>108 136.8 Q
+<65726966792074686174206974206d6174636865732077686174207468652060>-.15 E
+<60>-.74 E F2<434845434b3a>A F0 1.48 -.74<2727206c>D
+<696e65732073706563696679>.74 E<2e>-.65 E .681
+<5468652073796e746178206f6620746865>108 153.6 R F2<434845434b3a>3.181 E
+F0 .681<6c696e65732069732076>3.181 F .681
+<6572792073696d706c653a20746865>-.15 F 3.181<7961>-.15 G .681
+<7265208c78>-3.181 F .681
+<656420737472696e67732074686174206d757374206f6363757220696e206f72646572>
+-.15 F 5.681<2e46>-.55 G<696c65436865636b>-5.681 E<646566>108 165.6 Q
+.06<61756c747320746f2069676e6f72696e6720686f72697a6f6e74616c207768697465
+737061636520646966>-.1 F .059
+<666572656e6365732028652e672e206120737061636520697320616c6c6f>-.25 F
+.059<77656420746f206d61746368206120746162292062>-.25 F .059
+<7574206f74686572776973652c>-.2 F
+<74686520636f6e74656e7473206f6620746865>108 177.6 Q F2<434845434b3a>2.5
+E F0<6c696e6520697320726571756972656420746f206d6174636820736f6d65207468
+696e6720696e207468652074657374208c6c652065>2.5 E<786163746c79>-.15 E<2e>
+-.65 E .227<4f6e65206e696365207468696e672061626f75742046696c65436865636b
+2028636f6d706172656420746f206772657029206973207468617420697420616c6c6f>
+108 194.4 R .228<7773206d6572>-.25 F .228<67696e672074657374206361736573
+20746f67657468657220696e746f206c6f676963616c>-.18 F 3.665
+<67726f7570732e2046>108 206.4 R 1.165<6f722065>-.15 F 1.165
+<78616d706c652c20626563617573652074686520746573742061626f>-.15 F 1.465
+-.15<76652069>-.15 H 3.665<7363>.15 G 1.165
+<6865636b696e6720666f72207468652060>-3.665 F<60737562313a27>-.74 E 3.665
+<2761>-.74 G 1.164<6e642060>-3.665 F<60696e63343a27>-.74 E 3.664<276c>
+-.74 G 1.164<6162656c732c2069742077696c6c206e6f74>-3.664 F .446
+<6d6174636820756e6c65737320746865726520697320612060>108 218.4 R
+<607375626c27>-.74 E 2.947<2769>-.74 G 2.947<6e62>-2.947 G .447
+<65747765656e2074686f7365206c6162656c732e>-2.947 F .447<49662069742065>
+5.447 F .447<78697374656420736f6d65>-.15 F .447
+<776865726520656c736520696e20746865208c6c652c20746861742077>-.25 F
+<6f756c64>-.1 E<6e6f7420636f756e743a2060>108 230.4 Q
+<6067726570207375626c27>-.74 E 2.5<276d>-.74 G
+<617463686573206966207375626c2065>-2.5 E<786973747320616e>-.15 E
+<79776865726520696e20746865208c6c652e>-.15 E/F3 10/Times-Bold at 0 SF
+<5468652046696c65436865636b20ad636865636bad7072>87 247.2 Q
+<658c78206f7074696f6e>-.18 E F0 .278<5468652046696c65436865636b20ad6368
+65636bad7072658c78206f7074696f6e20616c6c6f>108 259.2 R .278<7773206d756c
+7469706c65207465737420636f6e8c6775726174696f6e7320746f20626520647269>
+-.25 F -.15<7665>-.25 G 2.778<6e66>.15 G .278
+<726f6d206f6e65202e6c6c208c6c652e>-2.778 F<54686973>5.278 E 1.674
+<69732075736566756c20696e206d616e>108 271.2 R 4.174<7963>-.15 G 1.674
+<697263756d7374616e6365732c20666f722065>-4.174 F 1.674
+<78616d706c652c2074657374696e6720646966>-.15 F 1.674
+<666572656e74206172636869746563747572616c2076>-.25 F 1.675
+<617269616e74732077697468206c6c632e>-.25 F<4865726527>6.675 E 4.175
+<7361>-.55 G<73696d706c652065>108 283.2 Q<78616d706c653a>-.15 E F1 6
+<3b52>120 300 S<554e3a206c6c766dad6173203c202573207c206c6c6320ad6d747269
+706c653d69363836ad6170706c65ad64617277696e3920ad6d617474723d737365343120
+5c>-6 E 6<3b52>120 312 S 78<554e3a207c>-6 F
+<46696c65436865636b20257320ad636865636bad7072656669783d5833323e>6 E 6
+<3b52>120 324 S<554e3a206c6c766dad6173203c202573207c206c6c6320ad6d747269
+706c653d7838365f3634ad6170706c65ad64617277696e3920ad6d617474723d73736534
+31205c>-6 E 6<3b52>120 336 S 78<554e3a207c>-6 F
+<46696c65436865636b20257320ad636865636bad7072656669783d5836343e>6 E<6465
+66696e65203c342078206933323e204070696e7372645f31286933322025732c203c3420
+78206933323e2025746d7029206e6f756e77696e64207b>120 360 Q<25746d7031203d
+20696e73657274656c656d656e74203c342078206933323e3b2025746d702c2069333220
+25732c206933322031>168 372 Q<726574203c342078206933323e2025746d7031>168
+384 Q 6<3b58>120 396 S<33323a2070696e7372645f313a>-6 E 6<3b58>120 408 S
+18<33323a2070696e737264>-6 F<24312c20342825657370292c2025786d6d30>6 E 6
+<3b58>120 432 S<36343a2070696e7372645f313a>-6 E 6<3b58>120 444 S 18
+<36343a2070696e737264>-6 F<24312c20256564692c2025786d6d30>6 E<7d>120 456
+Q F0 1.719<496e207468697320636173652c20776527>108 472.8 R 1.719
+<72652074657374696e67207468617420776520676574207468652065>-.5 F 1.719<78
+70656374656420636f64652067656e65726174696f6e207769746820626f7468203332ad
+62697420616e64203634ad62697420636f6465>-.15 F<67656e65726174696f6e2e>108
+484.8 Q F3<5468652060>87 501.6 Q<60434845434b2d4e455854>-.63 E<3a27>-.74
+E 2.5<2764>-.63 G<6972>-2.5 E<65637469>-.18 E -.1<7665>-.1 G F0 .885
+<536f6d6574696d657320796f752077>108 513.6 R .885
+<616e7420746f206d61746368206c696e657320616e642077>-.1 F .885
+<6f756c64206c696b>-.1 F 3.385<6574>-.1 G 3.385<6f76>-3.385 G .885
+<65726966792074686174206d6174636865732068617070656e206f6e2065>-3.535 F
+.885<786163746c7920636f6e736563757469>-.15 F -.15<7665>-.25 G .03<6c696e
+65732077697468206e6f206f74686572206c696e657320696e206265747765656e207468
+656d2e>108 525.6 R .03
+<496e207468697320636173652c20796f752063616e20757365>5.03 F F2
+<434845434b3a>2.53 E F0 .029<616e6420434845434b2d4e455854>2.529 F 2.529
+<3a64>-.5 G<697265637469>-2.529 E -.15<7665>-.25 G<73>.15 E 2.124
+<746f207370656369667920746869732e>108 537.6 R 2.125<496620796f7520737065
+63698c6564206120637573746f6d20636865636b207072658c782c206a75737420757365
+2060>7.124 F<603c>-.74 E F2<505245464958>A F0<3ead4e455854>A<3a27>-.5 E
+4.625<272e2046>-.74 F 2.125<6f722065>-.15 F<78616d706c652c>-.15 E
+<736f6d657468696e67206c696b>108 549.6 Q 2.5<6574>-.1 G<6869732077>-2.5 E
+<6f726b7320617320796f7527>-.1 E 2.5<6465>-.5 G<78706563743a>-2.65 E F1<
+646566696e6520766f696420407432283c32207820646f75626c653e2a2025722c203c32
+207820646f75626c652667743b2a2025412c20646f75626c6520254229207b>120 566.4
+Q<25746d7033203d206c6f6164203c32207820646f75626c652667743b2a2025412c2061
+6c69676e203136>156 578.4 Q<25746d7037203d20696e73657274656c656d656e7420
+3c32207820646f75626c652667743b20756e6465662c20646f75626c652025422c206933
+322030>156 590.4 Q<25746d7039203d2073687566666c65766563746f72203c322078
+20646f75626c652667743b2025746d70332c>156 602.4 Q
+<3c32207820646f75626c652667743b2025746d70372c>288 614.4 Q
+<3c322078206933322667743b203c2069333220302c206933322032202667743b>288
+626.4 Q<73746f7265203c32207820646f75626c652667743b2025746d70392c203c3220
+7820646f75626c652667743b2a2025722c20616c69676e203136>156 638.4 Q
+<72657420766f6964>156 650.4 Q 6<3b43>120 674.4 S 54<4845434b3a2074323a>
+-6 F 6<3b43>120 686.4 S 78<4845434b3a206d6f766c>-6 F
+<382825657370292c2025656178>24 E 6<3b43>120 698.4 S 48
+<4845434bad4e4558543a206d6f76617064>-6 F<2825656178292c2025786d6d30>12 E
+6<3b43>120 710.4 S 48<4845434bad4e4558543a206d6f76687064>-6 F
+<31322825657370292c2025786d6d30>12 E 6<3b43>120 722.4 S 48
+<4845434bad4e4558543a206d6f766c>-6 F<342825657370292c2025656178>24 E F0
+188.72<43565320323031322d30342d3138>72 768 R<32>205.67 E 0 Cg EP
+%%Page: 3 3
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF 115.62<46494c45434845434b283129204c4c>72 48 R
+<564d20436f6d6d616e64204775696465>-1 E<46494c45434845434b283129>118.12 E
+/F1 10/Courier at 0 SF 6<3b43>120 84 S 48
+<4845434bad4e4558543a206d6f76617064>-6 F<25786d6d302c20282565617829>12 E
+6<3b43>120 96 S 48<4845434bad4e4558543a20726574>-6 F<7d>120 108 Q F0
+<434845434b2d4e455854>108 124.8 Q 3.427<3a64>-.5 G<697265637469>-3.427 E
+-.15<7665>-.25 G 3.427<7372>.15 G .927
+<656a6563742074686520696e70757420756e6c6573732074686572652069732065>
+-3.427 F .927<786163746c79206f6e65206e65>-.15 F .926
+<776c696e65206265747765656e20697420616e2074686520707265>-.25 F
+<76696f7573>-.25 E<64697265637469>108 136.8 Q -.15<7665>-.25 G 5<2e41>
+.15 G<434845434b2d4e4558542063616e6e6f7420626520746865208c72737420646972
+65637469>-2.5 E .3 -.15<76652069>-.25 H 2.5<6e618c>.15 G<6c652e>-2.5 E
+/F2 10/Times-Bold at 0 SF<5468652060>87 153.6 Q<60434845434b2d4e4f>-.63 E
+-.74<543a>-.4 G 1.26 -.63<27272064>.74 H<6972>.63 E<65637469>-.18 E -.1
+<7665>-.1 G F0 .863<54686520434845434b2d4e4f>108 165.6 R 1.863 -.5
+<543a2064>-.4 H<697265637469>.5 E 1.163 -.15<76652069>-.25 H 3.363<7375>
+.15 G .864<73656420746f2076>-3.363 F .864
+<65726966792074686174206120737472696e6720646f65736e27>-.15 F 3.364<746f>
+-.18 G .864<63637572206265747765656e207477>-3.364 F 3.364<6f6d>-.1 G
+.864<61746368657320286f72206265666f7265>-3.364 F .1<746865208c727374206d
+617463682c206f7220616674657220746865206c617374206d61746368292e>108 177.6
+R -.15<466f>5.1 G 2.6<7265>.15 G .1<78616d706c652c20746f2076>-2.75 F
+.099<657269667920746861742061206c6f61642069732072656d6f>-.15 F -.15
+<7665>-.15 G 2.599<6462>.15 G 2.599<796174>-2.599 G .099
+<72616e73666f726d6174696f6e2c2061>-2.599 F<74657374206c696b>108 189.6 Q
+2.5<6574>-.1 G<6869732063616e20626520757365643a>-2.5 E F1<646566696e6520
+69382040636f657263655f6f666673657430286933322025562c206933322a2025502920
+7b>120 206.4 Q<73746f7265206933322025562c206933322a202550>132 218.4 Q
+<255032203d2062697463617374206933322a20255020746f2069382a>132 242.4 Q
+<255033203d20676574656c656d656e747074722069382a202550322c206933322032>
+132 254.4 Q<2541203d206c6f61642069382a20255033>132 278.4 Q
+<726574206938202541>132 290.4 Q 6<3b43>120 302.4 S
+<4845434b3a2040636f657263655f6f666673657430>-6 E 6<3b43>120 314.4 S
+<4845434bad4e4f543a206c6f6164>-6 E 6<3b43>120 326.4 S
+<4845434b3a20726574206938>-6 E<7d>120 338.4 Q F2<46696c65436865636b2050>
+87 355.2 Q<6174746572>-.1 E 2.5<6e4d>-.15 G
+<61746368696e672053796e746178>-2.5 E F0<546865>108 367.2 Q/F3 9
+/Times-Roman at 0 SF<434845434b3a>2.806 E F0 .306<616e6420434845434b2d4e4f>
+2.806 F 1.306 -.5<543a2064>-.4 H<697265637469>.5 E -.15<7665>-.25 G
+2.806<7362>.15 G .307<6f74682074616b>-2.806 F 2.807<656170>-.1 G .307
+<61747465726e20746f206d617463682e>-2.807 F -.15<466f>5.307 G 2.807<726d>
+.15 G .307<6f73742075736573206f662046696c65436865636b2c208c78>-2.807 F
+<6564>-.15 E .959
+<737472696e67206d61746368696e6720697320706572666563746c7920737566>108
+379.2 R 3.458<8c6369656e742e2046>-.25 F .958
+<6f7220736f6d65207468696e67732c2061206d6f7265208d65>-.15 F .958
+<7869626c6520666f726d206f66206d61746368696e6720697320646573697265642e>
+-.15 F -.8<546f>5.958 G .025
+<737570706f727420746869732c2046696c65436865636b20616c6c6f>108 391.2 R
+.026<777320796f7520746f2073706563696679207265>-.25 F .026
+<67756c61722065>-.15 F .026<787072657373696f6e7320696e206d61746368696e67
+20737472696e67732c20737572726f756e64656420627920646f75626c65>-.15 F
+<6272616365733a>108 403.2 Q F2<7b7b79>4.552 E<6f757272>-.25 E
+<656765787d7d>-.18 E F0 7.052<2e42>C 2.052<6563617573652077652077>-7.052
+F 2.052<616e7420746f20757365208c78>-.1 F 2.052<656420737472696e67206d61
+746368696e6720666f722061206d616a6f72697479206f66207768617420776520646f2c>
+-.15 F 3.619<46696c65436865636b20686173206265656e2064657369676e65642074
+6f20737570706f7274206d6978696e6720616e64206d61746368696e67208c78>108
+415.2 R 3.62<656420737472696e67206d61746368696e672077697468207265>-.15 F
+<67756c6172>-.15 E -.15<6578>108 427.2 S 2.5
+<7072657373696f6e732e2054686973>.15 F<616c6c6f>2.5 E
+<777320796f7520746f207772697465207468696e6773206c696b>-.25 E 2.5<6574>
+-.1 G<6869733a>-2.5 E F1 6<3b43>120 444 S<4845434b3a206d6f76687064>-6 E
+<7b7b5b30ad395d2b7d7d2825657370292c207b7b25786d6d5b30ad375d7d7d>42 E F0
+<496e207468697320636173652c20616e>108 460.8 Q 2.5<796f>-.15 G -.25<6666>
+-2.5 G<7365742066726f6d20746865>.25 E F3<455350>2.5 E F0<7265>2.5 E
+<6769737465722077696c6c20626520616c6c6f>-.15 E<7765642c20616e6420616e>
+-.25 E 2.5<7978>-.15 G<6d6d207265>-2.5 E
+<6769737465722077696c6c20626520616c6c6f>-.15 E<7765642e>-.25 E .274
+<42656361757365207265>108 477.6 R .274<67756c61722065>-.15 F .274<787072
+657373696f6e732061726520656e636c6f736564207769746820646f75626c6520627261
+6365732c20746865>-.15 F 2.774<7961>-.15 G .274
+<72652076697375616c6c792064697374696e63742c20616e6420796f7520646f6e27>
+-2.774 F 2.774<746e>-.18 G<656564>-2.774 E .925<746f20757365206573636170
+6520636861726163746572732077697468696e2074686520646f75626c65206272616365
+73206c696b>108 489.6 R 3.425<6579>-.1 G .925<6f752077>-3.425 F .925
+<6f756c6420696e20432e>-.1 F .925
+<496e2074686520726172652063617365207468617420796f752077>5.925 F .925
+<616e7420746f>-.1 F<6d6174636820646f75626c65206272616365732065>108 501.6
+Q<78706c696369746c792066726f6d2074686520696e7075742c20796f752063616e2075
+736520736f6d657468696e672075676c79206c696b>-.15 E<65>-.1 E F2
+<7b7b5b7b5d5b7b5d7d7d>2.5 E F0<617320796f7572207061747465726e2e>2.5 E F2
+<46696c65436865636b2056>87 518.4 Q<61726961626c6573>-.92 E F0 .519<4974
+206973206f6674656e2075736566756c20746f206d617463682061207061747465726e20
+616e64207468656e2076>108 530.4 R .519
+<65726966792074686174206974206f6363757273206167>-.15 F .519
+<61696e206c6174657220696e20746865208c6c652e>-.05 F -.15<466f>5.519 G
+3.019<7263>.15 G<6f6465>-3.019 E .519<67656e2074657374732c>-.15 F .942
+<746869732063616e2062652075736566756c20746f20616c6c6f>108 542.4 R 3.442
+<7761>-.25 G 1.242 -.15<6e792072>-3.442 H -.15<6567>.15 G<6973746572>.15
+E 3.442<2c62>-.4 G .942<75742076>-3.642 F .942
+<657269667920746861742074686174207265>-.15 F .942
+<676973746572206973207573656420636f6e73697374656e746c79206c61746572>-.15
+F 5.942<2e54>-.55 G 3.443<6f64>-6.742 G 3.443<6f74>-3.443 G<6869732c>
+-3.443 E<46696c65436865636b20616c6c6f>108 554.4 Q<7773206e616d65642076>
+-.25 E<61726961626c657320746f2062652064658c6e656420616e6420737562737469
+747574656420696e746f207061747465726e732e>-.25 E
+<4865726520697320612073696d706c652065>5 E<78616d706c653a>-.15 E F1 6
+<3b43>120 571.2 S<4845434b3a2074657374353a>-6 E 6<3b43>120 583.2 S 18
+<4845434b3a206e6f7477>-6 F<5b5b52454749535445523a255b61ad7a5d2b5d5d>36 E
+6<3b43>120 595.2 S 18<4845434b3a20616e6477>-6 F
+<7b7b2e2a7d7d5b52454749535445525d5d>36 E F0 .192
+<546865208c72737420636865636b206c696e65206d6174636865732061207265>108
+612 R<6765>-.15 E 2.692<7828>-.15 G F2<255b61ad7a5d2b>-2.692 E F0 2.692
+<2961>C .192<6e6420636170747572657320697420696e746f207468652076>-2.692 F
+.191<61726961626c652060>-.25 F<60>-.74 E F3<5245474953544552>A F0 -.74
+<2727>C 5.191<2e54>.74 G .191<6865207365636f6e64>-5.191 F 1.439
+<6c696e652076>108 624 R 1.439<6572698c65732074686174207768617465>-.15 F
+-.15<7665>-.25 G 3.939<7269>.15 G 3.939<7369>-3.939 G<6e>-3.939 E F3
+<5245474953544552>3.939 E F0 1.439
+<6f6363757273206c6174657220696e20746865208c6c6520616674657220616e2060>
+3.939 F<60616e647727>-.74 E 3.94<272e2046696c65436865636b>-.74 F -.25
+<7661>3.94 G<726961626c65>.25 E 1.135
+<7265666572656e6365732061726520616c>108 636 R -.1<7761>-.1 G 1.135
+<797320636f6e7461696e656420696e>.1 F F2 1.135<5b5b205d5d>3.635 F F0
+1.134<70616972732c20617265206e616d65642c20616e64207468656972206e616d6573
+2063616e20626520666f726d6564207769746820746865207265>3.635 F<6765>-.15 E
+<78>-.15 E<22>108 648 Q F2<5b61ad7a41ad5a5f5d5b61ad7a41ad5a30ad395f5d2a>
+A F0 2.502<222e204966>B 2.502<6163>2.502 G .002<6f6c6f6e20666f6c6c6f>
+-2.502 F .003<777320746865206e616d652c207468656e20697420697320612064658c
+6e6974696f6e206f66207468652076>-.25 F .003
+<61726961626c652c206966206e6f742c206974206973>-.25 F 2.5<6175>108 660 S
+<73652e>-2.5 E .206<46696c65436865636b2076>108 676.8 R .206<61726961626c
+65732063616e2062652064658c6e6564206d756c7469706c652074696d65732c20616e64
+207573657320616c>-.25 F -.1<7761>-.1 G .205
+<79732067657420746865206c61746573742076>.1 F 2.705<616c75652e204e6f7465>
+-.25 F .205<746861742076>2.705 F<61726961626c6573>-.25 E 1.266
+<61726520616c6c207265616420617420746865207374617274206f6620612060>108
+688.8 R<60>-.74 E F3<434845434b>A F0 2.747 -.74<2727206c>D 1.267
+<696e6520616e642061726520616c6c2064658c6e65642061742074686520656e642e>
+.74 F 1.267<54686973206d65616e73207468617420696620796f75206861>6.267 F
+-.15<7665>-.2 G 1.676<736f6d657468696e67206c696b>108 700.8 R 4.176<6522>
+-.1 G/F4 9/Times-Bold at 0 SF<434845434b3a>-4.176 E F2<5b5b>4.176 E F4
+<58595a3a>A F2<2e2a5d5d785b5b>A F4<58595a>A F2<5d5d>A F0 1.676
+<222c2074686520636865636b206c696e652077696c6c20726561642074686520707265>
+B 1.675<76696f75732076>-.25 F 1.675<616c7565206f6620746865>-.25 F F3
+<58595a>4.175 E F0 -.25<7661>108 712.8 S .467
+<726961626c6520616e642064658c6e652061206e65>.25 F 2.967<776f>-.25 G .467
+<6e6520616674657220746865206d6174636820697320706572666f726d65642e>-2.967
+F .468<496620796f75206e65656420746f20646f20736f6d657468696e67206c696b>
+5.468 F 2.968<6574>-.1 G .468<68697320796f752063616e>-2.968 F .19
+<70726f6261626c792074616b>108 724.8 R 2.69<6561>-.1 G<6476>-2.69 E .19
+<616e74616765206f66207468652066>-.25 F .19<61637420746861742046696c6543
+6865636b206973206e6f742061637475616c6c79206c696e652d6f7269656e7465642077
+68656e206974206d6174636865732c207468697320616c6c6f>-.1 F<7773>-.25 E
+188.72<43565320323031322d30342d3138>72 768 R<33>205.67 E 0 Cg EP
+%%Page: 4 4
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF 115.62<46494c45434845434b283129204c4c>72 48 R
+<564d20436f6d6d616e64204775696465>-1 E<46494c45434845434b283129>118.12 E
+<796f7520746f2064658c6e65207477>108 84 Q 2.5<6f73>-.1 G<65706172617465>
+-2.5 E/F1 9/Times-Roman at 0 SF<434845434b>2.5 E F0
+<6c696e65732074686174206d61746368206f6e207468652073616d65206c696e652e>
+2.5 E/F2 10.95/Times-Bold at 0 SF -.548<4155>72 100.8 S<54484f5253>.548 E
+F0<4d61696e7461696e656420627920546865>108 112.8 Q F1<4c4c>2.5 E<564d>-.9
+E F0 -.7<5465>2.5 G<616d20283c687474703a2f2f6c6c766d2e6f72>.7 E
+<672f3e292e>-.18 E 188.72<43565320323031322d30342d3138>72 768 R<34>
+205.67 E 0 Cg EP
+%%Trailer
+end
+%%EOF
Added: www-releases/trunk/3.1/docs/CommandGuide/ps/bugpoint.ps
URL: http://llvm.org/viewvc/llvm-project/www-releases/trunk/3.1/docs/CommandGuide/ps/bugpoint.ps?rev=157276&view=auto
==============================================================================
--- www-releases/trunk/3.1/docs/CommandGuide/ps/bugpoint.ps (added)
+++ www-releases/trunk/3.1/docs/CommandGuide/ps/bugpoint.ps Tue May 22 14:32:29 2012
@@ -0,0 +1,502 @@
+%!PS-Adobe-3.0
+%%Creator: groff version 1.18.1
+%%CreationDate: Tue May 22 00:24:04 2012
+%%DocumentNeededResources: font Times-Roman
+%%+ font Times-Bold
+%%+ font Times-Italic
+%%+ font Courier
+%%DocumentSuppliedResources: procset grops 1.18 1
+%%Pages: 3
+%%PageOrder: Ascend
+%%Orientation: Portrait
+%%EndComments
+%%BeginProlog
+%%BeginResource: procset grops 1.18 1
+/setpacking where{
+pop
+currentpacking
+true setpacking
+}if
+/grops 120 dict dup begin
+/SC 32 def
+/A/show load def
+/B{0 SC 3 -1 roll widthshow}bind def
+/C{0 exch ashow}bind def
+/D{0 exch 0 SC 5 2 roll awidthshow}bind def
+/E{0 rmoveto show}bind def
+/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def
+/G{0 rmoveto 0 exch ashow}bind def
+/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/I{0 exch rmoveto show}bind def
+/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def
+/K{0 exch rmoveto 0 exch ashow}bind def
+/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/M{rmoveto show}bind def
+/N{rmoveto 0 SC 3 -1 roll widthshow}bind def
+/O{rmoveto 0 exch ashow}bind def
+/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/Q{moveto show}bind def
+/R{moveto 0 SC 3 -1 roll widthshow}bind def
+/S{moveto 0 exch ashow}bind def
+/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def
+/SF{
+findfont exch
+[exch dup 0 exch 0 exch neg 0 0]makefont
+dup setfont
+[exch/setfont cvx]cvx bind def
+}bind def
+/MF{
+findfont
+[5 2 roll
+0 3 1 roll
+neg 0 0]makefont
+dup setfont
+[exch/setfont cvx]cvx bind def
+}bind def
+/level0 0 def
+/RES 0 def
+/PL 0 def
+/LS 0 def
+/MANUAL{
+statusdict begin/manualfeed true store end
+}bind def
+/PLG{
+gsave newpath clippath pathbbox grestore
+exch pop add exch pop
+}bind def
+/BP{
+/level0 save def
+1 setlinecap
+1 setlinejoin
+72 RES div dup scale
+LS{
+90 rotate
+}{
+0 PL translate
+}ifelse
+1 -1 scale
+}bind def
+/EP{
+level0 restore
+showpage
+}bind def
+/DA{
+newpath arcn stroke
+}bind def
+/SN{
+transform
+.25 sub exch .25 sub exch
+round .25 add exch round .25 add exch
+itransform
+}bind def
+/DL{
+SN
+moveto
+SN
+lineto stroke
+}bind def
+/DC{
+newpath 0 360 arc closepath
+}bind def
+/TM matrix def
+/DE{
+TM currentmatrix pop
+translate scale newpath 0 0 .5 0 360 arc closepath
+TM setmatrix
+}bind def
+/RC/rcurveto load def
+/RL/rlineto load def
+/ST/stroke load def
+/MT/moveto load def
+/CL/closepath load def
+/Fr{
+setrgbcolor fill
+}bind def
+/Fk{
+setcmykcolor fill
+}bind def
+/Fg{
+setgray fill
+}bind def
+/FL/fill load def
+/LW/setlinewidth load def
+/Cr/setrgbcolor load def
+/Ck/setcmykcolor load def
+/Cg/setgray load def
+/RE{
+findfont
+dup maxlength 1 index/FontName known not{1 add}if dict begin
+{
+1 index/FID ne{def}{pop pop}ifelse
+}forall
+/Encoding exch def
+dup/FontName exch def
+currentdict end definefont pop
+}bind def
+/DEFS 0 def
+/EBEGIN{
+moveto
+DEFS begin
+}bind def
+/EEND/end load def
+/CNT 0 def
+/level1 0 def
+/PBEGIN{
+/level1 save def
+translate
+div 3 1 roll div exch scale
+neg exch neg exch translate
+0 setgray
+0 setlinecap
+1 setlinewidth
+0 setlinejoin
+10 setmiterlimit
+[]0 setdash
+/setstrokeadjust where{
+pop
+false setstrokeadjust
+}if
+/setoverprint where{
+pop
+false setoverprint
+}if
+newpath
+/CNT countdictstack def
+userdict begin
+/showpage{}def
+}bind def
+/PEND{
+clear
+countdictstack CNT sub{end}repeat
+level1 restore
+}bind def
+end def
+/setpacking where{
+pop
+setpacking
+}if
+%%EndResource
+%%IncludeResource: font Times-Roman
+%%IncludeResource: font Times-Bold
+%%IncludeResource: font Times-Italic
+%%IncludeResource: font Courier
+grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72
+def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron
+/scaron/zcaron/Ydieresis/trademark/quotesingle/Euro/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef
+/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent
+/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen
+/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon
+/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O
+/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex
+/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y
+/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft
+/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl
+/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut
+/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash
+/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen
+/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft
+/logicalnot/minus/registered/macron/degree/plusminus/twosuperior
+/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior
+/ordmasculine/guilsinglright/onequarter/onehalf/threequarters
+/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE
+/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex
+/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis
+/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn
+/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
+/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
+/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash
+/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def
+/Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE
+/Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE
+%%EndProlog
+%%Page: 1 1
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF -.1<4255>72 48 S 120.17
+<47504f494e54283129204c4c>.1 F<564d20436f6d6d616e64204775696465>-1 E -.1
+<4255>122.67 G<47504f494e54283129>.1 E/F1 10.95/Times-Bold at 0 SF -.219
+<4e41>72 84 S<4d45>.219 E F0 -.2<6275>108 96 S<67706f696e7420ad20617574
+6f6d617469632074657374206361736520726564756374696f6e20746f6f6c>.2 E F1
+<53594e4f50534953>72 112.8 Q/F2 10/Times-Bold at 0 SF -.2<6275>108 124.8 S
+<67706f696e74>.2 E F0<5b>2.5 E/F3 10/Times-Italic at 0 SF<6f7074696f6e73>A
+F0 2.5<5d5b>C F3<696e707574>-2.5 E/F4 9/Times-Italic at 0 SF<4c4c>2.5 E
+<564d>-.495 E F3<6c6c2f6263208c6c6573>2.5 E F0 2.5<5d5b>C F4<4c4c>-2.5 E
+<564d>-.495 E F3<706173736573>2.5 E F0<5d>A F2<adad6172>2.5 E<6773>-.1 E
+F3<7072>2.5 E -.1<6f67>-.45 G -.15<7261>.1 G 2.5<6d61>.15 G -.37<7267>
+-2.5 G<756d656e7473>.37 E F1<4445534352495054494f4e>72 141.6 Q F2 -.2
+<6275>108 153.6 S<67706f696e74>.2 E F0<6e6172726f>3.304 E .804
+<777320646f>-.25 F .804
+<776e2074686520736f75726365206f662070726f626c656d7320696e>-.25 F/F5 9
+/Times-Roman at 0 SF<4c4c>3.304 E<564d>-.9 E F0 .803
+<746f6f6c7320616e64207061737365732e>3.304 F .803
+<49742063616e206265207573656420746f20646562>5.803 F .803
+<7567207468726565>-.2 F 3.407<7479706573206f662066>108 165.6 R 3.407<61
+696c757265733a206f7074696d697a657220637261736865732c206d6973636f6d70696c
+6174696f6e73206279206f7074696d697a6572732c206f7220626164206e617469>-.1 F
+3.708 -.15<76652063>-.25 H 3.408<6f64652067656e65726174696f6e>.15 F .106
+<28696e636c7564696e672070726f626c656d7320696e20746865207374617469632061
+6e64>108 177.6 R F5<4a4954>2.606 E F0 2.606
+<636f6d70696c657273292e204974>2.606 F .106
+<61696d7320746f20726564756365206c6172>2.606 F .105<67652074657374206361
+73657320746f20736d616c6c2c2075736566756c206f6e65732e>-.18 F -.15<466f>
+108 189.6 S 2.935<726d>.15 G .435<6f726520696e666f726d6174696f6e206f6e20
+7468652064657369676e20616e6420696e6e65722077>-2.935 F .435
+<6f726b696e6773206f66>-.1 F F2 -.2<6275>2.935 G<67706f696e74>.2 E F0
+2.935<2c61>C 2.935<7377>-2.935 G .436
+<656c6c2061732061647669636520666f72207573696e672062>-2.935 F
+<7567706f696e742c>-.2 E<736565>108 201.6 Q F3
+<6c6c766d2f646f63732f427567706f696e742e68746d6c>2.5 E F0<696e20746865>
+2.5 E F5<4c4c>2.5 E<564d>-.9 E F0<64697374726962>2.5 E<7574696f6e2e>-.2
+E F1<4f5054494f4e53>72 218.4 Q F2<adad6164646974696f6e616cad736f>108
+230.4 Q F3<6c696272>2.5 E<617279>-.15 E F0 .392
+<4c6f6164207468652064796e616d696320736861726564206f626a656374>128 242.4
+R F3<6c696272>2.891 E<617279>-.15 E F0 .391
+<696e746f2074686520746573742070726f6772616d207768656e65>2.891 F -.15
+<7665>-.25 G 2.891<7269>.15 G 2.891<7469>-2.891 G 2.891<7372>-2.891 G
+2.891<756e2e2054686973>-2.891 F .391<69732075736566756c20696620796f75>
+2.891 F .941<61726520646562>128 254.4 R .941<756767696e672070726f677261
+6d7320776869636820646570656e64206f6e206e6f6e2d4c4c>-.2 F .942<564d206c69
+62726172696573202873756368206173207468652058206f7220637572736573206c6962
+7261726965732920746f>-1 F<72756e2e>128 266.4 Q F2
+<adad617070656e64ad65786974ad636f6465>108 283.2 Q F0<3d>A F3<7b74727565>
+A<2c66616c73657d>-.1 E F0 .396
+<417070656e642074686520746573742070726f6772616d732065>128 295.2 R .396<
+78697420636f646520746f20746865206f7574707574208c6c6520736f20746861742061
+206368616e676520696e2065>-.15 F .395
+<78697420636f646520697320636f6e7369646572656420612074657374>-.15 F -.1
+<6661>128 307.2 S<696c7572652e20446566>.1 E<61756c747320746f2066>-.1 E
+<616c73652e>-.1 E F2<adad6172>108 324 Q<6773>-.1 E F3<7072>2.5 E -.1
+<6f67>-.45 G -.15<7261>.1 G 2.5<6d61>.15 G -.37<7267>-2.5 G<73>.37 E F0
+-.15<5061>128 336 S .693<737320616c6c206172>.15 F .694
+<67756d656e74732073706563698c656420616674657220ad6172>-.18 F .694
+<677320746f2074686520746573742070726f6772616d207768656e65>-.18 F -.15
+<7665>-.25 G 3.194<7269>.15 G 3.194<7472>-3.194 G 3.194
+<756e732e204e6f7465>-3.194 F .694<7468617420696620616e>3.194 F 3.194
+<796f>-.15 G 3.194<6674>-3.194 G<6865>-3.194 E F3<7072>128 348 Q -.1
+<6f67>-.45 G -.15<7261>.1 G 2.5<6d61>.15 G -.37<7267>-2.5 G<73>.37 E F0
+<7374617274207769746820612027ad272c20796f752073686f756c64207573653a>2.5
+E/F6 10/Courier at 0 SF<627567706f696e74205b627567706f696e7420617267735d20
+adad6172677320adad205b70726f6772616d20617267735d>152 366 Q F0 .882
+<5468652060>128 384 R<60adad27>-.74 E 3.382<2772>-.74 G .882
+<6967687420616674657220746865>-3.382 F F2<adad6172>3.382 E<6773>-.1 E F0
+.882<6f7074696f6e2074656c6c73>3.382 F F2 -.2<6275>3.382 G<67706f696e74>
+.2 E F0 .882<746f20636f6e736964657220616e>3.382 F 3.382<796f>-.15 G .882
+<7074696f6e73207374617274696e672077697468>-3.382 F F6<ad>3.381 E F0 .881
+<746f206265>3.381 F<70617274206f6620746865>128 396 Q F2<adad6172>2.5 E
+<6773>-.1 E F0<6f7074696f6e2c206e6f74206173206f7074696f6e7320746f>2.5 E
+F2 -.2<6275>2.5 G<67706f696e74>.2 E F0<697473656c662e>2.5 E F2
+<adad746f6f6cad6172>108 412.8 Q<6773>-.1 E F3<746f6f6c206172>2.5 E<6773>
+-.37 E F0 -.15<5061>128 424.8 S .94<737320616c6c206172>.15 F .941
+<67756d656e74732073706563698c656420616674657220adad746f6f6cad6172>-.18 F
+.941<677320746f20746865>-.18 F F5<4c4c>3.441 E<564d>-.9 E F0 .941
+<746f6f6c20756e64657220746573742028>3.441 F F2<6c6c63>A F0<2c>A F2
+<6c6c69>3.441 E F0 3.441<2c65>C .941<74632e29207768656e65>-3.441 F -.15
+<7665>-.25 G 3.441<7269>.15 G<74>-3.441 E 2.5<72756e732e2059>128 436.8 R
+<6f752073686f756c64207573652074686973206f7074696f6e20696e2074686520666f
+6c6c6f>-1.1 E<77696e672077>-.25 E<61793a>-.1 E F6<627567706f696e74205b62
+7567706f696e7420617267735d20adad746f6f6cad6172677320adad205b746f6f6c2061
+7267735d>152 454.8 Q F0 .32<5468652060>128 472.8 R<60adad27>-.74 E 2.82
+<2772>-.74 G .32<6967687420616674657220746865>-2.82 F F2
+<adad746f6f6cad6172>2.82 E<6773>-.1 E F0 .32<6f7074696f6e2074656c6c73>
+2.82 F F2 -.2<6275>2.82 G<67706f696e74>.2 E F0 .32
+<746f20636f6e736964657220616e>2.82 F 2.82<796f>-.15 G .32
+<7074696f6e73207374617274696e672077697468>-2.82 F F6<ad>2.82 E F0<746f>
+2.82 E<62652070617274206f6620746865>128 484.8 Q F2<adad746f6f6cad6172>
+2.5 E<6773>-.1 E F0<6f7074696f6e2c206e6f74206173206f7074696f6e7320746f>
+2.5 E F2 -.2<6275>2.5 G<67706f696e74>.2 E F0<697473656c662e2028536565>
+2.5 E F2<adad6172>2.5 E<6773>-.1 E F0 2.5<2c61>C<626f>-2.5 E -.15<7665>
+-.15 G<2e29>.15 E F2<adad73616665ad746f6f6cad6172>108 501.6 Q<6773>-.1 E
+F3<746f6f6c206172>2.5 E<6773>-.37 E F0 -.15<5061>128 513.6 S
+<737320616c6c206172>.15 E<67756d656e74732073706563698c6564206166746572>
+-.18 E F2<adad73616665ad746f6f6cad6172>2.5 E<6773>-.1 E F0
+<746f207468652060>2.5 E<607361666527>-.74 E 2.5<2765>-.74 G -.15<7865>
+-2.65 G<637574696f6e20746f6f6c2e>.15 E F2<adad676363ad746f6f6cad6172>108
+530.4 Q<6773>-.1 E F3<67636320746f6f6c206172>2.5 E<6773>-.37 E F0 -.15
+<5061>128 542.4 S<737320616c6c206172>.15 E
+<67756d656e74732073706563698c6564206166746572>-.18 E F2
+<adad676363ad746f6f6cad6172>2.5 E<6773>-.1 E F0<746f2074686520696e>2.5 E
+-.2<766f>-.4 G<636174696f6e206f66>.2 E F2<676363>2.5 E F0<2e>A F2
+<adad6f7074ad6172>108 559.2 Q<6773>-.1 E F3<6f7074206172>2.5 E<6773>-.37
+E F0 -.15<5061>128 571.2 S<737320616c6c206172>.15 E
+<67756d656e74732073706563698c6564206166746572>-.18 E F2
+<adad6f7074ad6172>2.5 E<6773>-.1 E F0<746f2074686520696e>2.5 E -.2<766f>
+-.4 G<636174696f6e206f66>.2 E F2<6f7074>2.5 E F0<2e>A F2
+<adad64697361626c65ad7b6463652c73696d706c6966796366677d>108 588 Q F0
+1.942<446f206e6f742072756e207468652073706563698c65642070617373657320746f
+20636c65616e20757020616e6420726564756365207468652073697a65206f6620746865
+20746573742070726f6772616d2e20427920646566>128 600 R<61756c742c>-.1 E F2
+-.2<6275>128 612 S<67706f696e74>.2 E F0 1.267<75736573207468657365207061
+7373657320696e7465726e616c6c79207768656e20617474656d7074696e6720746f2072
+656475636520746573742070726f6772616d732e>3.768 F 1.267<496620796f7527>
+6.267 F 1.267<726520747279696e6720746f>-.5 F<8c6e6420612062>128 624 Q
+<756720696e206f6e65206f66207468657365207061737365732c>-.2 E F2 -.2<6275>
+2.5 G<67706f696e74>.2 E F0<6d61792063726173682e>2.5 E F2
+<adad656e61626c65ad76>108 640.8 Q<616c6772696e64>-.1 E F0 2.112
+<5573652076>128 652.8 R 2.112<616c6772696e6420746f208c6e642066>-.25 F
+2.113<61756c747320696e20746865206f7074696d697a6174696f6e2070686173652e20
+546869732077696c6c20616c6c6f>-.1 F 4.613<7762>-.25 G 2.113
+<7567706f696e7420746f208c6e64206f7468657277697365>-4.813 F<6173796d7074
+6f6d617469632070726f626c656d7320636175736564206279206d656d6f7279206d6973
+2d6d616e6167656d656e742e>128 664.8 Q F2<ad8c6e64ad62>108 681.6 Q<756773>
+-.2 E F0 .769<436f6e74696e75616c6c792072616e646f6d697a652074686520737065
+63698c65642070617373657320616e642072756e207468656d206f6e2074686520746573
+742070726f6772616d20756e74696c20612062>128 693.6 R .768
+<756720697320666f756e64206f72>-.2 F<7468652075736572206b696c6c73>128
+705.6 Q F2 -.2<6275>2.5 G<67706f696e74>.2 E F0<2e>A 188.72
+<43565320323031312d30342d3232>72 768 R<31>205.67 E 0 Cg EP
+%%Page: 2 2
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF -.1<4255>72 48 S 120.17
+<47504f494e54283129204c4c>.1 F<564d20436f6d6d616e64204775696465>-1 E -.1
+<4255>122.67 G<47504f494e54283129>.1 E/F1 10/Times-Bold at 0 SF<ad68656c70>
+108 84 Q F0<5072696e7420612073756d6d617279206f6620636f6d6d616e64206c696e
+65206f7074696f6e732e>128 96 Q F1<adad696e707574>108 112.8 Q/F2 10
+/Times-Italic at 0 SF<8c6c656e616d65>2.5 E F0<4f70656e>128 124.8 Q F2
+<8c6c656e616d65>2.727 E F0 .228<616e642072656469726563742074686520737461
+6e6461726420696e707574206f662074686520746573742070726f6772616d2c20776865
+6e65>2.727 F -.15<7665>-.25 G 2.728<7269>.15 G 2.728<7472>-2.728 G .228
+<756e732c20746f20636f6d652066726f6d2074686174>-2.728 F<8c6c652e>128
+136.8 Q F1<adad6c6f6164>108 153.6 Q F2<706c7567696e>2.5 E F0 1.376
+<4c6f6164207468652064796e616d6963206f626a656374>128 165.6 R F2
+<706c7567696e>3.876 E F0<696e746f>3.876 E F1 -.2<6275>3.875 G
+<67706f696e74>.2 E F0 3.875<697473656c662e2054686973>3.875 F 1.375
+<6f626a6563742073686f756c64207265>3.875 F 1.375<676973746572206e65>-.15
+F 3.875<776f>-.25 G<7074696d697a6174696f6e>-3.875 E 3.157
+<7061737365732e204f6e6365>128 177.6 R .658
+<6c6f616465642c20746865206f626a6563742077696c6c20616464206e65>3.157 F
+3.158<7763>-.25 G .658
+<6f6d6d616e64206c696e65206f7074696f6e7320746f20656e61626c652076>-3.158 F
+.658<6172696f7573206f7074696d697a6174696f6e732e>-.25 F 4.146 -.8
+<546f2073>128 189.6 T 2.546<656520746865206e65>.8 F 5.046<7763>-.25 G
+2.546<6f6d706c657465206c697374206f66206f7074696d697a6174696f6e732c207573
+6520746865>-5.046 F F1<ad68656c70>5.046 E F0<616e64>5.046 E F1
+<adad6c6f6164>5.046 E F0 2.546
+<6f7074696f6e7320746f6765746865723b20666f72>5.046 F -.15<6578>128 201.6
+S<616d706c653a>.15 E/F3 10/Courier at 0 SF
+<627567706f696e7420adad6c6f6164206d794e6577506173732e736f20ad68656c70>
+152 219.6 Q F1<adad6d6c696d6974>108 236.4 Q F2<6d65>2.5 E
+<67616279746573>-.4 E F0 .521<53706563698c657320616e207570706572206c696d
+6974206f6e206d656d6f7279207573616765206f6620746865206f7074696d697a617469
+6f6e20616e6420636f6465>128 248.4 R .521
+<67656e2e2053657420746f207a65726f20746f2064697361626c6520746865>-.15 F
+<6c696d69742e>128 260.4 Q F1<adad6f7574707574>108 277.2 Q F2
+<8c6c656e616d65>2.5 E F0<5768656e65>128 289.2 Q -.15<7665>-.25 G 2.626
+<7274>.15 G .126<686520746573742070726f6772616d2070726f6475636573206f75
+74707574206f6e20697473207374616e64617264206f75747075742073747265616d2c20
+69742073686f756c64206d617463682074686520636f6e74656e7473>-2.626 F<6f66>
+128 301.2 Q F2<8c6c656e616d65>2.572 E F0 .073<287468652060>2.573 F .073
+<607265666572656e6365206f757470757427>-.74 F .073
+<27292e20496620796f7520646f206e6f74207573652074686973206f7074696f6e2c>
+-.74 F F1 -.2<6275>2.573 G<67706f696e74>.2 E F0 .073
+<77696c6c20617474656d707420746f2067656e65726174652061>2.573 F<7265666572
+656e6365206f757470757420627920636f6d70696c696e67207468652070726f6772616d
+2077697468207468652060>128 313.2 Q<607361666527>-.74 E 2.5<2762>-.74 G
+<61636b>-2.5 E<656e6420616e642072756e6e696e672069742e>-.1 E F1<adad7072>
+108 330 Q<6f8c6c65ad696e66>-.18 E<6fad8c6c65>-.25 E F2<8c6c656e616d65>
+2.5 E F0<50726f8c6c65208c6c65206c6f61646564206279>128 342 Q F1<adad7072>
+2.5 E<6f8c6c65ad6c6f61646572>-.18 E F0<2e>A F1
+<adad72756ead7b696e742c6a69742c6c6c632c6362652c637573746f6d7d>108 358.8
+Q F0<5768656e65>128 370.8 Q -.15<7665>-.25 G 2.788<7274>.15 G .288
+<686520746573742070726f6772616d20697320636f6d70696c65642c>-2.788 F F1
+-.2<6275>2.788 G<67706f696e74>.2 E F0 .288<73686f756c642067656e65726174
+6520636f646520666f72206974207573696e67207468652073706563698c656420636f64
+65>2.788 F<67656e657261746f72>128 382.8 Q 5.823<2e54>-.55 G .823
+<68657365206f7074696f6e7320616c6c6f>-5.823 F 3.323<7779>-.25 G .823
+<6f7520746f2063686f6f73652074686520696e746572707265746572>-3.323 F 3.324
+<2c74>-.4 G<6865>-3.324 E/F4 9/Times-Roman at 0 SF<4a4954>3.324 E F0
+<636f6d70696c6572>3.324 E 3.324<2c74>-.4 G .824
+<686520737461746963206e617469>-3.324 F 1.124 -.15<76652063>-.25 H
+<6f6465>.15 E<636f6d70696c6572>128 394.8 Q 2.5<2c74>-.4 G
+<68652043206261636b>-2.5 E
+<656e642c206f72206120637573746f6d20636f6d6d616e642028736565>-.1 E F1
+<adad65786563ad636f6d6d616e64>2.5 E F0 2.5<2972>C<65737065637469>-2.5 E
+-.15<7665>-.25 G<6c79>.15 E<2e>-.65 E F1
+<adad73616665ad7b6c6c632c6362652c637573746f6d7d>108 411.6 Q F0 1.205
+<5768656e20646562>128 423.6 R 1.205
+<756767696e67206120636f64652067656e657261746f72>-.2 F<2c>-.4 E F1 -.2
+<6275>3.705 G<67706f696e74>.2 E F0 1.205<73686f756c64207573652074686520
+73706563698c656420636f64652067656e657261746f72206173207468652060>3.705 F
+<607361666527>-.74 E<27>-.74 E .361<636f64652067656e657261746f72>128
+435.6 R 2.861<2e54>-.55 G .362<6869732069732061206b6e6f>-2.861 F .362<77
+6e2d676f6f6420636f64652067656e657261746f72207573656420746f2067656e657261
+7465207468652060>-.25 F .362<607265666572656e6365206f757470757427>-.74 F
+2.862<2769>-.74 G 2.862<6669>-2.862 G 2.862<7468>-2.862 G<6173>-2.862 E
+.263<6e6f74206265656e2070726f>128 447.6 R .263<76696465642c20616e642074
+6f20636f6d70696c6520706f7274696f6e73206f66207468652070726f6772616d207468
+617420617320746865>-.15 F 2.763<7961>-.15 G .263<72652065>-2.763 F .263
+<78636c756465642066726f6d207468652074657374636173652e>-.15 F 2.248
+<5468657365206f7074696f6e7320616c6c6f>128 459.6 R 4.748<7779>-.25 G
+2.249<6f7520746f2063686f6f73652074686520737461746963206e617469>-4.748 F
+2.549 -.15<76652063>-.25 H 2.249<6f646520636f6d70696c6572>.15 F 4.749
+<2c74>-.4 G 2.249<68652043206261636b>-4.749 F 2.249
+<656e642c206f72206120637573746f6d>-.1 F 3.86<636f6d6d616e642c2028736565>
+128 471.6 R F1<adad65786563ad636f6d6d616e64>6.36 E F0 6.36<2972>C
+<65737065637469>-6.36 E -.15<7665>-.25 G<6c79>.15 E 6.359<2e54>-.65 G
+3.859<686520696e74657270726574657220616e6420746865>-6.359 F F4<4a4954>
+6.359 E F0<6261636b>6.359 E 3.859<656e64732063616e6e6f74>-.1 F
+<63757272656e746c792062652075736564206173207468652060>128 483.6 Q
+<607361666527>-.74 E 2.5<2762>-.74 G<61636b>-2.5 E<656e64732e>-.1 E F1
+<adad65786563ad636f6d6d616e64>108 500.4 Q F2<636f6d6d616e64>2.5 E F0
+1.99<54686973206f7074696f6e2064658c6e65732074686520636f6d6d616e6420746f
+20757365207769746820746865>128 512.4 R F1<adad72756ead637573746f6d>4.49
+E F0<616e64>4.49 E F1<adad73616665ad637573746f6d>4.49 E F0 1.99
+<6f7074696f6e7320746f>4.49 F -.15<657865>128 524.4 S<637574652074686520
+626974636f64652074657374636173652e20546869732063616e2062652075736566756c
+20666f722063726f73732d636f6d70696c6174696f6e2e>.15 E F1
+<adad636f6d70696c65ad636f6d6d616e64>108 541.2 Q F2<636f6d6d616e64>2.5 E
+F0 1.026<54686973206f7074696f6e2064658c6e65732074686520636f6d6d616e6420
+746f20757365207769746820746865>128 553.2 R F1
+<adad636f6d70696c65ad637573746f6d>3.526 E F0 1.025
+<6f7074696f6e20746f20636f6d70696c652074686520626974636f6465>3.526 F .38<
+74657374636173652e20546869732063616e2062652075736566756c20666f7220746573
+74696e6720636f6d70696c6572206f757470757420776974686f75742072756e6e696e67
+20616e>128 565.2 R 2.88<796c>-.15 G .38<696e6b206f722065>-2.88 F -.15
+<7865>-.15 G .38<63757465207374616765732e2054>.15 F<6f>-.8 E .836<67656e
+65726174652061207265647563656420756e697420746573742c20796f75206d61792061
+6464>128 577.2 R F4<434845434b>3.336 E F0<64697265637469>3.336 E -.15
+<7665>-.25 G 3.335<7374>.15 G 3.335<6f74>-3.335 G .835
+<686520746573746361736520616e64207061737320746865206e616d65206f6620616e>
+-3.335 F -.15<657865>128 589.2 S<63757461626c6520636f6d70696c652d636f6d
+6d616e642073637269707420696e207468697320666f726d3a>.15 E F3
+<23212f62696e2f7368>152 607.2 Q<6c6c632022244022>152 619.2 Q<6e6f742046
+696c65436865636b205b627567706f696e7420696e7075742066696c655d2e6c6c203c20
+627567706f696e74ad74657374ad70726f6772616d2e73>152 631.2 Q F0 1.159
+<54686973207363726970742077696c6c2060>128 649.2 R<6066>-.74 E<61696c27>
+-.1 E 3.659<2761>-.74 G 3.659<736c>-3.659 G 1.16<6f6e672061732046696c65
+436865636b207061737365732e20536f2074686520726573756c742077696c6c20626520
+746865206d696e696d756d20626974636f64652074686174>-3.659 F
+<7061737365732046696c65436865636b2e>128 661.2 Q F1
+<adad73616665ad70617468>108 678 Q F2<70617468>2.5 E F0 2.141<5468697320
+6f7074696f6e2064658c6e657320746865207061746820746f2074686520636f6d6d616e
+6420746f2065>128 690 R -.15<7865>-.15 G 2.141
+<63757465207769746820746865>.15 F F1
+<adad73616665ad7b696e742c6a69742c6c6c632c6362652c637573746f6d7d>4.64 E
+F0<6f7074696f6e2e>128 702 Q 188.72<43565320323031312d30342d3232>72 768 R
+<32>205.67 E 0 Cg EP
+%%Page: 3 3
+%%BeginPageSetup
+BP
+%%EndPageSetup
+/F0 10/Times-Roman at 0 SF -.1<4255>72 48 S 120.17
+<47504f494e54283129204c4c>.1 F<564d20436f6d6d616e64204775696465>-1 E -.1
+<4255>122.67 G<47504f494e54283129>.1 E/F1 10.95/Times-Bold at 0 SF
+<45584954205354>72 84 Q -1.04<4154>-.986 G<5553>1.04 E F0<4966>108 96 Q
+/F2 10/Times-Bold at 0 SF -.2<6275>2.529 G<67706f696e74>.2 E F0 .029<737563
+636565647320696e208c6e64696e6720612070726f626c656d2c2069742077696c6c2065>
+2.529 F .029<786974207769746820302e>-.15 F .029<4f74686572776973652c2069
+6620616e206572726f72206f63637572732c2069742077696c6c2065>5.029 F .029
+<7869742077697468>-.15 F 2.5<616e>108 108 S<6f6e2d7a65726f2076>-2.5 E
+<616c75652e>-.25 E F1<53454520414c534f>72 124.8 Q F0<6f7074>108 136.8 Q
+F1 -.548<4155>72 153.6 S<54484f52>.548 E F0
+<4d61696e7461696e656420627920746865>108 165.6 Q/F3 9/Times-Roman at 0 SF
+<4c4c>2.5 E<564d>-.9 E F0 -.7<5465>2.5 G
+<616d20283c687474703a2f2f6c6c766d2e6f72>.7 E<672f3e292e>-.18 E 188.72
+<43565320323031312d30342d3232>72 768 R<33>205.67 E 0 Cg EP
+%%Trailer
+end
+%%EOF
More information about the llvm-commits
mailing list