[llvm-commits] [parallel] CVS: llvm/docs/ObjectFiles.html TableGenFundamentals.html CFEBuildInstrs.html GettingStarted.html HowToSubmitABug.html LLVMVsTheWorld.html LangRef.html ProgrammersManual.html ReleaseNotes.html TestingGuide.html WritingAnLLVMPass.html index.html
Misha Brukman
brukman at cs.uiuc.edu
Mon Mar 1 17:57:06 PST 2004
Changes in directory llvm/docs:
ObjectFiles.html added (r1.2.2.1)
TableGenFundamentals.html added (r1.4.2.1)
CFEBuildInstrs.html updated: 1.11 -> 1.11.2.1
GettingStarted.html updated: 1.48 -> 1.48.2.1
HowToSubmitABug.html updated: 1.11 -> 1.11.2.1
LLVMVsTheWorld.html updated: 1.5 -> 1.5.4.1
LangRef.html updated: 1.43 -> 1.43.2.1
ProgrammersManual.html updated: 1.53 -> 1.53.2.1
ReleaseNotes.html updated: 1.102 -> 1.102.2.1
TestingGuide.html updated: 1.6 -> 1.6.4.1
WritingAnLLVMPass.html updated: 1.22 -> 1.22.2.1
index.html updated: 1.6 -> 1.6.4.1
---
Log message:
Merge from trunk
---
Diffs of the changes: (+1859 -604)
Index: llvm/docs/ObjectFiles.html
diff -c /dev/null llvm/docs/ObjectFiles.html:1.2.2.1
*** /dev/null Mon Mar 1 17:56:11 2004
--- llvm/docs/ObjectFiles.html Mon Mar 1 17:56:01 2004
***************
*** 0 ****
--- 1,298 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+ <html>
+ <head>
+ <title>Object Files: Understanding The Result Of LLVM Compilation</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+ <div class="doc_title">Object Files: Understanding The Result Of LLVM Compilation</div>
+ <hr>
+ <ol>
+ <li><a href="#abstract">Abstract</a></li>
+ <li><a href="#introduction">Introduction</a></li>
+ <li><a href="#files">File Contents</a></li>
+ <li><a href="#rot">Linkage Rules Of Thumb</a>
+ <ol>
+ <li><a href="#always">Always Link vmcore.o, support.a</a>
+ <li><a href="#placeholder">Placeholder</a>
+ </ol>
+ </li>
+ </ol>
+ <div class="doc_text">
+ <p><b>Written by <a href="mailto:rspencer at x10sys.com">Reid Spencer</a> </b></p>
+ <p> </p>
+ </div>
+ <hr>
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="abstract">Abstract</a></div>
+ <div class="doc_text">
+ <p>This document describes the contents of the many objects files and libraries
+ that are produced by compiling LLVM. To make use of LLVM this information is
+ needed in order to understand what files should be linked into your program.
+ </p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_section"> <a name="introduction">Introduction</a></div>
+ <div class="doc_text">
+ <p>If you're writing a compiler, virtual machine, or any other utility for
+ LLVM, you'll need to figure out which of the many .a (archive) and .o
+ (object) files you will need to link with to be successful. An
+ understanding of the contents of these files and their inter-relationships
+ will be useful in coming up with an optimal specification for the objects
+ and libraries to link with.
+ </p>
+ <p>The purpose of this document is to hopefully reduce some of the trial and
+ error that the author experienced in using LLVM.
+ </p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="files"></a>File Contents</div>
+ <div class="doc_text">
+ <p>The table below provides a summary of the basic contents of each file.</p>
+ <table class="doc_table"
+ style="width:80%; text-align: left; border: 2px solid blue; border-collapse: collapse;">
+ <tr class="doc_table">
+ <td colspan="2" class="doc_section">Summary Of LLVM Library And Object Files
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue"><h2><u>Library</u></h2></td>
+ <td style="border: 2px solid blue"><h2><u>Description</u></h2></td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libipo.a</td>
+ <td style="border: 2px solid blue">
+ An archive of all inter-procedural optimizations.
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libscalaropts.a</td>
+ <td style="border: 2px solid blue">
+ An archive of all scalar optimizations.
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libtransforms.a</td>
+ <td style="border: 2px solid blue">
+ An archive of just the level raise pass.
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libtarget.a</td>
+ <td style="border: 2px solid blue">
+ An archive containing code generator support for describing
+ target architectures.
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libanalysis.a</td>
+ <td style="border: 2px solid blue">
+ An archive containing intra-procedural analyses.
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libdatastructure.a</td>
+ <td style="border: 2px solid blue">
+ An archive containing optimizations for data structures.
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libinstrument.a</td>
+ <td style="border: 2px solid blue">No idea.</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libregalloc.a</td>
+ <td style="border: 2px solid blue">Register Allocation code.</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libipa.a</td>
+ <td style="border: 2px solid blue">
+ An archive containing inter-procedural analyses</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libtransformutils.a</td>
+ <td style="border: 2px solid blue">
+ Utiltities for transformations?
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libsupport.a</td>
+ <td style="border: 2px solid blue">General support utilities</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">libevar.a</td>
+ <td style="border: 2px solid blue">Live variable analysis for SPARC</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue"><h2><u>Object File</u></h2></td>
+ <td style="border: 2px solid blue"><h2><u>Description</u></h2></td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">support.o</td>
+ <td style="border: 2px solid blue">General support utilities</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">asmparser.o</td>
+ <td style="border: 2px solid blue">Assembler Parser</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">bcreader.o</td>
+ <td style="border: 2px solid blue">Byte Code Reader</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">bcwriter.o</td>
+ <td style="border: 2px solid blue">Byte Code Writer</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">sched.o</td>
+ <td style="border: 2px solid blue">SPARC instruction scheduler</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">selectiondag.o</td>
+ <td style="border: 2px solid blue">Aggressive instruction selector for Directed Acyclic Graphs</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">transformutils.o</td>
+ <td style="border: 2px solid blue">Utilities for code transformations</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">ipa.o</td>
+ <td style="border: 2px solid blue">Inter-Procedural Analysis Optimizations</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">select.o</td>
+ <td style="border: 2px solid blue">SPARC instruction selector</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">cwriter.o</td>
+ <td style="border: 2px solid blue">"C" Code Writer</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">profpaths.o</td>
+ <td style="border: 2px solid blue">Path profiling instrumentation</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">regalloc.o</td>
+ <td style="border: 2px solid blue">Register Allocation</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">instrument.o</td>
+ <td style="border: 2px solid blue">Instrumentation? Of What?</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">datastructure.o</td>
+ <td style="border: 2px solid blue">Data Structure Analysis</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">codegen.o</td>
+ <td style="border: 2px solid blue">Native code generation</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">livevar.o</td>
+ <td style="border: 2px solid blue">Live Variable Analysis</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">vmcore.o</td>
+ <td style="border: 2px solid blue">Virtual Machine Core</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">lli-interpreter.o</td>
+ <td style="border: 2px solid blue">Interpreter for LLVM ByteCode</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">lli-jit.o</td>
+ <td style="border: 2px solid blue">
+ Just-In-Time Compiler For LLVM ByteCode
+ </td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">executionengine.o</td>
+ <td style="border: 2px solid blue">Engine for LLI</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">debugger.o</td>
+ <td style="border: 2px solid blue">Source Level Debugging Support</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">analysis.o</td>
+ <td style="border: 2px solid blue">General Framework For Analysis?</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">sparc.o</td>
+ <td style="border: 2px solid blue">Sun SPARC Processor Specific</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">target.o</td>
+ <td style="border: 2px solid blue">Target Machine Support?</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">transforms.o</td>
+ <td style="border: 2px solid blue">Code Transformations</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">x86.o</td>
+ <td style="border: 2px solid blue">Intel x86 Processor Specific</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">powerpc.o</td>
+ <td style="border: 2px solid blue">PowerPC Processor Specific</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">scalaropts.o</td>
+ <td style="border: 2px solid blue">Optimizations For Scalars</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">ipo.o</td>
+ <td style="border: 2px solid blue">Inter-Procedural Optimization</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">trace.o</td>
+ <td style="border: 2px solid blue">Support For Tracing/Debugging?</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">profile_rt.o</td>
+ <td style="border: 2px solid blue">Runtime Library For Profiler</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">sample.o</td>
+ <td style="border: 2px solid blue">Sample Program ?</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">stkr_compiler.o</td>
+ <td style="border: 2px solid blue">Stacker Language Compiler Library</td>
+ </tr>
+ <tr class="doc_table">
+ <td style="border: 2px solid blue">stkr_runtime.o</td>
+ <td style="border: 2px solid blue">Stacker Language Runtime Library</td>
+ </tr>
+ </table>
+ </div>
+ <p></p>
+ <!-- ======================================================================= -->
+ <div class="doc_section"><a name="rot">Linkage Rules Of Thumb</a></div>
+ <div class="doc_text">
+ <p>This section contains various "rules of thumb" about what files you
+ should link into your programs.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="always">Always Link vmcore.o support.a</a>
+ </div>
+ <div class="doc_text">
+ <p>No matter what you do with LLVM, you'll always need to link with vmcore.o
+ and support.a.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <div class="doc_subsection"><a name="Placeholder">Placeholder</a></div>
+ <div class="doc_text">
+ <p>Need more rules of thumb here.</p>
+ </div>
+ <!-- ======================================================================= -->
+ <hr>
+ <div class="doc_footer">
+ <address><a href="mailto:rspencer at x10sys.com">Reid Spencer</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>Last modified: $Date: 2004/03/01 23:56:01 $ </div>
+ </body>
+ </html>
+ <!-- vim: sw=2 ts=2 ai
+ -->
Index: llvm/docs/TableGenFundamentals.html
diff -c /dev/null llvm/docs/TableGenFundamentals.html:1.4.2.1
*** /dev/null Mon Mar 1 17:56:11 2004
--- llvm/docs/TableGenFundamentals.html Mon Mar 1 17:56:01 2004
***************
*** 0 ****
--- 1,653 ----
+ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
+ <html>
+ <head>
+ <title>TableGen Fundamentals</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
+ </head>
+ <body>
+
+ <div class="doc_title">TableGen Fundamentals</div>
+
+ <ul>
+ <li><a href="#introduction">Introduction</a></li>
+ <ol>
+ <li><a href="#concepts">Basic concepts</a></li>
+ <li><a href="#example">An example record</a></li>
+ <li><a href="#running">Running TableGen</a></li>
+ </ol>
+ <li><a href="#syntax">TableGen syntax</a></li>
+ <ol>
+ <li><a href="#primitives">TableGen primitives</a></li>
+ <ol>
+ <li><a href="#comments">TableGen comments</a></li>
+ <li><a href="#types">The TableGen type system</a></li>
+ <li><a href="#values">TableGen values and expressions</a></li>
+ </ol>
+ <li><a href="#classesdefs">Classes and definitions</a></li>
+ <ol>
+ <li><a href="#valuedef">Value definitions</a></li>
+ <li><a href="#recordlet">'let' expressions</a></li>
+ <li><a href="#templateargs">Class template arguments</a></li>
+ </ol>
+ <li><a href="#filescope">File scope entities</a></li>
+ <ol>
+ <li><a href="#include">File inclusion</a></li>
+ <li><a href="#globallet">'let' expressions</a></li>
+ </ol>
+ </ol>
+ <li><a href="#backends">TableGen backends</a></li>
+ <ol>
+ <li><a href="#">todo</a></li>
+ </ol>
+ <li><a href="#codegenerator">The LLVM code generator</a></li>
+ <ol>
+ <li><a href="#">todo</a></li>
+ </ol>
+ </ul>
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="introduction">Introduction</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>TableGen's purpose is to help a human develop and maintain records of
+ domain-specific information. Because there may be a large number of these
+ records, it is specifically designed to allow writing flexible descriptions and
+ for common features of these records to be factored out. This reduces the
+ amount of duplication in the description, reduces the chance of error, and
+ makes it easier to structure domain specific information.</p>
+
+ <p>The core part of TableGen <a href="#syntax">parses a file</a>, instantiates
+ the declarations, and hands the result off to a domain-specific "<a
+ href="#backends">TableGen backend</a>" for processing. The current major user
+ of TableGen is the <a href="#codegenerator">LLVM code generator</a>.
+ </p>
+
+ <p>
+ Note that if you work on TableGen much, and use emacs or vim, that you can find
+ an emacs "TableGen mode" and a vim language file in <tt>llvm/utils/emacs</tt>
+ and <tt>llvm/utils/vim</tt> directory of your LLVM distribution, respectively.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="running">Basic concepts</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ TableGen files consist of two key parts: 'classes' and 'definitions', both of
+ which are considered 'records'.
+ </p>
+
+ <p>
+ <b>TableGen records</b> have a unique name, a list of values, and a list of
+ superclasses. The list of values is main data that TableGen builds for each
+ record, it is this that holds the domain specific information for the
+ application. The interpretation of this data is left to a specific <a
+ href="#backends">TableGen backend</a>, but the structure and format rules are
+ taken care of and fixed by TableGen.
+ </p>
+
+ <p>
+ <b>TableGen definitions</b> are the concrete form of 'records'. These generally
+ do not have any undefined values, and are marked with the '<tt>def</tt>'
+ keyword.
+ </p>
+
+ <p>
+ <b>TableGen classes</b> are abstract records that are used to build and describe
+ other records. These 'classes' allow the end-user to build abstractions for
+ either the domain they are targetting (such as "Register", "RegisterClass", and
+ "Instruction" in the LLVM code generator) or for the implementor to help factor
+ out common properties of records (such as "FPInst", which is used to represent
+ floating point instructions in the X86 backend). TableGen keeps track of all of
+ the classes that are used to build up a definition, so the backend can find all
+ definitions of a particular class, such as "Instruction".
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="example">An example record</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ With no other arguments, TableGen parses the specified file and prints out all
+ of the classes, then all of the definitions. This is a good way to see what the
+ various definitions expand to fully. Running this on the <tt>X86.td</tt> file
+ prints this (at the time of this writing):
+ </p>
+
+ <p>
+ <pre>
+ ...
+ <b>def</b> ADDrr8 { <i>// Instruction X86Inst I2A8 Pattern</i>
+ <b>string</b> Name = "add";
+ <b>string</b> Namespace = "X86";
+ <b>list</b><Register> Uses = [];
+ <b>list</b><Register> Defs = [];
+ <b>bit</b> isReturn = 0;
+ <b>bit</b> isBranch = 0;
+ <b>bit</b> isCall = 0;
+ <b>bit</b> isTwoAddress = 1;
+ <b>bit</b> isTerminator = 0;
+ <b>dag</b> Pattern = (set R8, (plus R8, R8));
+ <b>bits</b><8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 0 };
+ Format Form = MRMDestReg;
+ <b>bits</b><5> FormBits = { 0, 0, 0, 1, 1 };
+ ArgType Type = Arg8;
+ <b>bits</b><3> TypeBits = { 0, 0, 1 };
+ <b>bit</b> hasOpSizePrefix = 0;
+ <b>bit</b> printImplicitUses = 0;
+ <b>bits</b><4> Prefix = { 0, 0, 0, 0 };
+ FPFormat FPForm = ?;
+ <b>bits</b><3> FPFormBits = { 0, 0, 0 };
+ }
+ ...
+ </pre><p>
+
+ <p>
+ This definition corresponds to an 8-bit register-register add instruction in the
+ X86. The string after the '<tt>def</tt>' string indicates the name of the
+ record ("<tt>ADDrr8</tt>" in this case), and the comment at the end of the line
+ indicates the superclasses of the definition. The body of the record contains
+ all of the data that TableGen assembled for the record, indicating that the
+ instruction is part of the "X86" namespace, should be printed as "<tt>add</tt>"
+ in the assembly file, it is a two-address instruction, has a particular
+ encoding, etc. The contents and semantics of the information in the record is
+ specific to the needs of the X86 backend, and is only shown as an example.
+ </p>
+
+ <p>
+ As you can see, a lot of information is needed for every instruction supported
+ by the code generator, and specifying it all manually would be unmaintainble,
+ prone to bugs, and tiring to do in the first place. Because we are using
+ TableGen, all of the information was derived from the following definition:
+ </p>
+
+ <p><pre>
+ <b>def</b> ADDrr8 : I2A8<"add", 0x00, MRMDestReg>,
+ Pattern<(set R8, (plus R8, R8))>;
+ </pre></p>
+
+ <p>
+ This definition makes use of the custom I2A8 (two address instruction with 8-bit
+ operand) class, which is defined in the X86-specific TableGen file to factor out
+ the common features that instructions of its class share. A key feature of
+ TableGen is that it allows the end-user to define the abstractions they prefer
+ to use when describing their information.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="running">Running TableGen</a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>
+ TableGen runs just like any other LLVM tool. The first (optional) argument
+ specifies the file to read. If a filename is not specified, <tt>tblgen</tt>
+ reads from standard input.
+ </p>
+
+ <p>
+ To be useful, one of the <a href="#backends">TableGen backends</a> must be used.
+ These backends are selectable on the command line (type '<tt>tblgen --help</tt>'
+ for a list). For example, to get a list of all of the definitions that subclass
+ a particular type (which can be useful for building up an enum list of these
+ records), use the <tt>--print-enums</tt> option:
+ </p>
+
+ <p><pre>
+ $ tblgen X86.td -print-enums -class=Register
+ AH, AL, AX, BH, BL, BP, BX, CH, CL, CX, DH, DI, DL, DX,
+ EAX, EBP, EBX, ECX, EDI, EDX, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6,
+ SI, SP, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7,
+
+ $ tblgen X86.td -print-enums -class=Instruction
+ ADCrr32, ADDri16, ADDri16b, ADDri32, ADDri32b, ADDri8, ADDrr16, ADDrr32,
+ ADDrr8, ADJCALLSTACKDOWN, ADJCALLSTACKUP, ANDri16, ANDri16b, ANDri32, ANDri32b,
+ ANDri8, ANDrr16, ANDrr32, ANDrr8, BSWAPr32, CALLm32, CALLpcrel32, ...
+ </pre></p>
+
+ <p>
+ The default backend prints out all of the records, as described <a
+ href="#example">above</a>.
+ </p>
+
+ <p>
+ If you plan to use TableGen for some purpose, you will most likely have to <a
+ href="#backends">write a backend</a> that extracts the information specific to
+ what you need and formats it in the appropriate way.
+ </p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="syntax">TableGen syntax</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>
+ TableGen doesn't care about the meaning of data (that is up to the backend to
+ define), but it does care about syntax, and it enforces a simple type system.
+ This section describes the syntax and the constructs allowed in a TableGen file.
+ </p>
+
+ </div>
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="primitives">TableGen primitives</tt></a>
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="comments">TableGen comments</tt></a>
+ </div>
+
+ <div class="doc_text">
+
+ <p>TableGen supports BCPL style "<tt>//</tt>" comments, which run to the end of
+ the line, and it also supports <b>nestable</b> "<tt>/* */</tt>" comments.</p>
+
+ </div>
+
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="types">The TableGen type system</tt></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ TableGen files are strongly typed, in a simple (but complete) type-system.
+ These types are used to perform automatic conversions, check for errors, and to
+ help interface designers constrain the input that they allow. Every <a
+ href="#valuedef">value definition</a> is required to have an associated type.
+ </p>
+
+ <p>
+ TableGen supports a mixture of very low-level types (such as <tt>bit</tt>) and
+ very high-level types (such as <tt>dag</tt>). This flexibility is what allows
+ it to describe a wide range of information conveniently and compactly. The
+ TableGen types are:
+ </p>
+
+ <p>
+ <ul>
+ <li>"<tt><b>bit</b></tt>" - A 'bit' is a boolean value that can hold either 0 or
+ 1.</li>
+
+ <li>"<tt><b>int</b></tt>" - The 'int' type represents a simple 32-bit integer
+ value, such as 5.</li>
+
+ <li>"<tt><b>string</b></tt>" - The 'string' type represents an ordered sequence
+ of characters of arbitrary length.</li>
+
+ <li>"<tt><b>bits</b><n></tt>" - A 'bits' type is an arbitrary, but fixed,
+ size integer that is broken up into individual bits. This type is useful
+ because it can handle some bits being defined while others are undefined.</li>
+
+ <li>"<tt><b>list</b><ty></tt>" - This type represents a list whose
+ elements are some other type. The contained type is arbitrary: it can even be
+ another list type.</li>
+
+ <li>Class type - Specifying a class name in a type context means that the
+ defined value must be a subclass of the specified class. This is useful in
+ conjunction with the "list" type, for example, to constrain the elements of the
+ list to a common base class (e.g., a <tt><b>list</b><Register></tt> can
+ only contain definitions derived from the "<tt>Register</tt>" class).</li>
+
+ <li>"<tt><b>code</b></tt>" - This represents a big hunk of text. NOTE: I don't
+ remember why this is distinct from string!</li>
+
+ <li>"<tt><b>dag</b></tt>" - This type represents a nestable directed graph of
+ elements.</li>
+ </ul>
+ </p>
+
+ <p>
+ To date, these types have been sufficient for describing things that TableGen
+ has been used for, but it is straight-forward to extend this list if needed.
+ </p>
+
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="values">TableGen values and expressions</tt></a>
+ </div>
+
+ <div>
+ <p>
+ TableGen allows for a pretty reasonable number of different expression forms
+ when building up values. These forms allow the TableGen file to be written in a
+ natural syntax and flavor for the application. The current expression forms
+ supported include:
+ </p>
+
+ <p><ul>
+ <li>? - Uninitialized field.</li>
+ <li>0b1001011 - Binary integer value.</li>
+ <li>07654321 - Octal integer value (indicated by a leading 0).</li>
+ <li>7 - Decimal integer value.</li>
+ <li>0x7F - Hexadecimal integer value.</li>
+ <li>"foo" - String value.</li>
+ <li>[{ .... }] - Code fragment.</li>
+ <li>[ X, Y, Z ] - List value.</li>
+ <li>{ a, b, c } - Initializer for a "bits<3>" value.</li>
+ <li>value - Value reference.</li>
+ <li>value{17} - Access to one or more bits of a value.</li>
+ <li>DEF - Reference to a record definition.</li>
+ <li>X.Y - Reference to the subfield of a value.</li>
+
+ <li>(DEF a, b) - A dag value. The first element is required to be a record
+ definition, the remaining elements in the list may be arbitrary other values,
+ including nested 'dag' values.</li>
+
+ </ul></p>
+
+ <p>
+ Note that all of the values have rules specifying how they convert to values
+ for different types. These rules allow you to assign a value like "7" to a
+ "bits<4>" value, for example.
+ </p>
+
+
+
+ </div>
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="classesdefs">Classes and definitions</tt></a>
+ </div>
+
+ <div>
+ <p>
+ As mentioned in the <a href="#concepts">intro</a>, classes and definitions
+ (collectively known as 'records') in TableGen are the main high-level unit of
+ information that TableGen collects. Records are defined with a <tt>def</tt> or
+ <tt>class</tt> keyword, the record name, and an optional list of "<a
+ href="templateargs">template arguments</a>". If the record has superclasses,
+ they are specified as a comma seperated list that starts with a colon character
+ (":"). If <a href="#valuedef">value definitions</a> or <a href="#recordlet">let
+ expressions</a> are needed for the class, they are enclosed in curly braces
+ ("{}"); otherwise, the record ends with a semicolon. Here is a simple TableGen
+ file:
+ </p>
+
+ <p><pre>
+ <b>class</b> C { <b>bit</b> V = 1; }
+ <b>def</b> X : C;
+ <b>def</b> Y : C {
+ <b>string</b> Greeting = "hello";
+ }
+ </pre></p>
+
+ <p>
+ This example defines two definitions, <tt>X</tt> and <tt>Y</tt>, both of which
+ derive from the <tt>C</tt> class. Because of this, they both get the <tt>V</tt>
+ bit value. The <tt>Y</tt> definition also gets the Greeting member as well.
+ </p>
+
+ <p>
+ In general, classes are useful for collecting together the commonality between a
+ group of records and isolating it in a single place. Also, classes permit the
+ specification of default values for their subclasses, allowing the subclasses to
+ override them as they wish.
+ </p>
+
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="valuedef">Value definitions</tt></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ Value definitions define named entries in records. A value must be defined
+ before it can be referred to as the operand for another value definition or
+ before the value is reset with a <a href="#recordlet">let expression</a>. A
+ value is defined by specifying a <a href="#types">TableGen type</a> and a name.
+ If an initial value is available, it may be specified after the type with an
+ equal sign. Value definitions require terminating semicolons.
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="recordlet">'let' expressions</tt></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ A record-level let expression is used to change the value of a value definition
+ in a record. This is primarily useful when a superclass defines a value that a
+ derived class or definition wants to override. Let expressions consist of the
+ '<tt>let</tt>' keyword followed by a value name, an equal sign ("="), and a new
+ value. For example, a new class could be added to the example above, redefining
+ the <tt>V</tt> field for all of its subclasses:</p>
+
+ <p><pre>
+ <b>class</b> D : C { let V = 0; }
+ <b>def</b> Z : D;
+ </pre></p>
+
+ <p>
+ In this case, the <tt>Z</tt> definition will have a zero value for its "V"
+ value, despite the fact that it derives (indirectly) from the <tt>C</tt> class,
+ because the <tt>D</tt> class overrode its value.
+ </p>
+
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="templateargs">Class template arguments</tt></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ TableGen permits the definition of parameterized classes as well as normal
+ concrete classes. Parameterized TableGen classes specify a list of variable
+ bindings (which may optionally have defaults) that are bound when used. Here is
+ a simple example:</p>
+
+ <p><pre>
+ <b>class</b> FPFormat<<b>bits</b><3> val> {
+ <b>bits</b><3> Value = val;
+ }
+ <b>def</b> NotFP : FPFormat<0>;
+ <b>def</b> ZeroArgFP : FPFormat<1>;
+ <b>def</b> OneArgFP : FPFormat<2>;
+ <b>def</b> OneArgFPRW : FPFormat<3>;
+ <b>def</b> TwoArgFP : FPFormat<4>;
+ <b>def</b> SpecialFP : FPFormat<5>;
+ </pre></p>
+
+ <p>
+ In this case, template arguments are used as a space efficient way to specify a
+ list of "enumeration values", each with a "Value" field set to the specified
+ integer.</p>
+
+ <p>The more esoteric forms of <a href="#values">TableGen expressions</a> are
+ useful in conjunction with template arguments. As an example:</p>
+
+ <p><pre>
+ <b>class</b> ModRefVal<<b>bits</b><2> val> {
+ <b>bits</b><2> Value = val;
+ }
+
+ <b>def</b> None : ModRefVal<0>;
+ <b>def</b> Mod : ModRefVal<1>;
+ <b>def</b> Ref : ModRefVal<2>;
+ <b>def</b> ModRef : ModRefVal<3>;
+
+ <b>class</b> Value<ModRefVal MR> {
+ <i>// decode some information into a more convenient format, while providing
+ // a nice interface to the user of the "Value" class.</i>
+ <b>bit</b> isMod = MR.Value{0};
+ <b>bit</b> isRef = MR.Value{1};
+
+ <i>// other stuff...</i>
+ }
+
+ <i>// Example uses</i>
+ <b>def</b> bork : Value<Mod>;
+ <b>def</b> zork : Value<Ref>;
+ <b>def</b> hork : Value<ModRef>;
+ </pre></p>
+
+ <p>
+ This is obviously a contrived example, but it shows how template arguments can
+ be used to decouple the interface provided to the user of the class from the
+ actual internal data representation expected by the class. In this case,
+ running <tt>tblgen</tt> on the example prints the following definitions:</p>
+
+ <p><pre>
+ <b>def</b> bork { <i>// Value</i>
+ bit isMod = 1;
+ bit isRef = 0;
+ }
+ <b>def</b> hork { <i>// Value</i>
+ bit isMod = 1;
+ bit isRef = 1;
+ }
+ <b>def</b> zork { <i>// Value</i>
+ bit isMod = 0;
+ bit isRef = 1;
+ }
+ </pre></p>
+
+ <p>
+ This shows that TableGen was able to dig into the argument and extract a piece
+ of information that was requested by the designer of the "Value" class. For
+ more realistic examples, please see existing users of TableGen, such as the X86
+ backend.</p>
+
+ </div>
+
+
+
+ <!-- ======================================================================= -->
+ <div class="doc_subsection">
+ <a name="filescope">File scope entities</tt></a>
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="include">File inclusion</tt></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ TableGen supports the '<tt>include</tt>' token, which textually substitutes the
+ specified file in place of the include directive. The filename should be
+ specified as a double quoted string immediately after the '<tt>include</tt>'
+ keyword. Example:
+
+ <p><pre>
+ <b>include</b> "foo.td"
+ </pre></p>
+
+ </div>
+
+ <!----------------------------------------------------------------------------->
+ <div class="doc_subsubsection">
+ <a name="globallet">'let' expressions</tt></a>
+ </div>
+
+ <div class="doc_text">
+ <p>
+ "let" expressions at file scope are similar to <a href="#recordlet">"let"
+ expressions within a record</a>, except they can specify a value binding for
+ multiple records at a time, and may be useful in certain other cases.
+ File-scope let expressions are really just another way that TableGen allows the
+ end-user to factor out commonality from the records.
+ </p>
+
+ <p>
+ File-scope "let" expressions take a comma-seperated list of bindings to apply,
+ and one of more records to bind the values in. Here are some examples:
+ </p>
+
+ <p><pre>
+ <b>let</b> isTerminator = 1, isReturn = 1 <b>in</b>
+ <b>def</b> RET : X86Inst<"ret", 0xC3, RawFrm, NoArg>;
+
+ <b>let</b> isCall = 1 <b>in</b>
+ <i>// All calls clobber the non-callee saved registers...</i>
+ <b>let</b> Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6] in {
+ <b>def</b> CALLpcrel32 : X86Inst<"call", 0xE8, RawFrm, NoArg>;
+ <b>def</b> CALLr32 : X86Inst<"call", 0xFF, MRMS2r, Arg32>;
+ <b>def</b> CALLm32 : X86Inst<"call", 0xFF, MRMS2m, Arg32>;
+ }
+ </pre></p>
+
+ <p>
+ File-scope "let" expressions are often useful when a couple of definitions need
+ to be added to several records, and the records do not otherwise need to be
+ opened, as in the case with the CALL* instructions above.
+ </p>
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="backends">TableGen backends</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>
+ How they work, how to write one. This section should not contain details about
+ any particular backend, except maybe -print-enums as an example. This should
+ highlight the APIs in TableGen/Record.h.
+ </p>
+
+ </div>
+
+
+ <!-- *********************************************************************** -->
+ <div class="doc_section"><a name="codegenerator">The LLVM code generator</a></div>
+ <!-- *********************************************************************** -->
+
+ <div class="doc_text">
+
+ <p>
+ This is just a temporary, convenient, place to put stuff about the code
+ generator before it gets its own document. This should describe all of the
+ tablegen backends used by the code generator and the classes/definitions they
+ expect.
+ </p>
+
+ </div>
+
+
+
+ <!-- *********************************************************************** -->
+ <hr>
+ <div class="doc_footer">
+ <address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
+ <br>
+ Last modified: $Date: 2004/03/01 23:56:01 $
+ </div>
+
+ </body>
+ </html>
Index: llvm/docs/CFEBuildInstrs.html
diff -u llvm/docs/CFEBuildInstrs.html:1.11 llvm/docs/CFEBuildInstrs.html:1.11.2.1
--- llvm/docs/CFEBuildInstrs.html:1.11 Thu Dec 18 10:43:11 2003
+++ llvm/docs/CFEBuildInstrs.html Mon Mar 1 17:56:01 2004
@@ -101,37 +101,25 @@
</pre>
<p>
-<b>Solaris/Sparc:</b>
+<b>Solaris/SPARC:</b>
</p>
<p>
-For Solaris/Sparc, LLVM only supports SparcV9. Therefore, the configure
-command line should like something like this:
+For Solaris/SPARC, LLVM only supports the SPARC V9. Therefore, the
+configure command line should specify sparcv9, as shown below. Also,
+note that Solaris has trouble with various wide (multibyte) character
+functions from C as referenced from C++, so we typically configure with
+--disable-c-mbchar (cf. <a href="http://llvm.cs.uiuc.edu/PR206">Bug 206</a>).
</p>
<pre>
% cd build
- % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
- --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8
+ % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
+ --disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
+ --disable-c-mbchar
% gmake all-gcc
% setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc
- % gmake all
-</pre>
-
-<p>
-At this point, libstdc++ may fail to build because of wchar errors (look for
-errors that reference <tt>vfwscanf</tt> or <tt>wcstof</tt>). If that happens,
-edit <tt>sparcv9-sun-solaris2.8/libstdc++-v3/config.h</tt> and comment out the
-line that defines <tt>_GLIBCXX_USE_WCHAR_T</tt>.
-</p>
-
-<p>
-Then, continue as below:
-</p>
-
-<pre>
- % gmake all
- % gmake install
+ % gmake all; gmake install
</pre>
<p><b>Common Problem:</b> You may get error messages regarding the fact
@@ -262,7 +250,7 @@
<address>Brian Gaeke</address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
- Last modified: $Date: 2003/12/18 16:43:11 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</div>
</body>
Index: llvm/docs/GettingStarted.html
diff -u llvm/docs/GettingStarted.html:1.48 llvm/docs/GettingStarted.html:1.48.2.1
--- llvm/docs/GettingStarted.html:1.48 Mon Jan 19 18:20:17 2004
+++ llvm/docs/GettingStarted.html Mon Mar 1 17:56:01 2004
@@ -264,12 +264,15 @@
LLVM:</p>
<ul>
- <li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A>
+ <li><A href="http://www.gnu.org/software/automake">GNU Automake</A></li>
+ <li><A href="http://www.gnu.org/software/autoconf">GNU Autoconf</A></li>
<li><A href="http://savannah.gnu.org/projects/m4">GNU M4</A>
<p>If you want to make changes to the configure scripts, you will need GNU
autoconf (2.57 or higher), and consequently, GNU M4 (version 1.4 or
- higher).</p></li>
+ higher). You will also need automake. Any old version of
+ automake from 1.4p5 on should work; we only use aclocal from that
+ package.</p></li>
<li><A href="http://www.codesourcery.com/qm/qmtest">QMTest</A></li>
<li><A href="http://www.python.org">Python</A>
@@ -908,8 +911,7 @@
LLVM assembly to LLVM bytecode.<p>
<dt><tt><b>llvm-dis</b></tt><dd>The disassembler transforms the LLVM
- bytecode to human readable LLVM assembly. Additionally, it can convert
- LLVM bytecode to C, which is enabled with the <tt>-c</tt> option.<p>
+ bytecode to human readable LLVM assembly.<p>
<dt><tt><b>llvm-link</b></tt><dd> <tt>llvm-link</tt>, not surprisingly,
links multiple LLVM modules into a single program.<p>
@@ -923,8 +925,9 @@
functionality was compiled in), and will execute the code <i>much</i>
faster than the interpreter.<p>
- <dt><tt><b>llc</b></tt><dd> <tt>llc</tt> is the LLVM backend compiler,
- which translates LLVM bytecode to a SPARC or x86 assembly file.<p>
+ <dt><tt><b>llc</b></tt><dd> <tt>llc</tt> is the LLVM backend compiler, which
+ translates LLVM bytecode to a SPARC or x86 assembly file, or to C code (with
+ the -march=c option).<p>
<dt><tt><b>llvmgcc</b></tt><dd> <tt>llvmgcc</tt> is a GCC-based C frontend
that has been retargeted to emit LLVM code as the machine code output. It
@@ -1144,7 +1147,7 @@
<a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date: 2004/01/20 00:20:17 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</address>
</body>
Index: llvm/docs/HowToSubmitABug.html
diff -u llvm/docs/HowToSubmitABug.html:1.11 llvm/docs/HowToSubmitABug.html:1.11.2.1
--- llvm/docs/HowToSubmitABug.html:1.11 Thu Jan 15 13:03:47 2004
+++ llvm/docs/HowToSubmitABug.html Mon Mar 1 17:56:01 2004
@@ -281,7 +281,7 @@
<li>Regenerate the shared object from the safe bytecode file:<br>
<pre>
- <b>llvm-dis</b> -c safe.bc -o safe.c<br>
+ <b>llc</b> -march=c safe.bc -o safe.c<br>
<b>gcc</b> -shared safe.c -o safe.so
</pre></li>
@@ -315,7 +315,7 @@
<a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
- Last modified: $Date: 2004/01/15 19:03:47 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</address>
</body>
Index: llvm/docs/LLVMVsTheWorld.html
diff -u llvm/docs/LLVMVsTheWorld.html:1.5 llvm/docs/LLVMVsTheWorld.html:1.5.4.1
--- llvm/docs/LLVMVsTheWorld.html:1.5 Wed Nov 12 15:39:31 2003
+++ llvm/docs/LLVMVsTheWorld.html Mon Mar 1 17:56:01 2004
@@ -60,8 +60,8 @@
<p>LLVM: Supports compilation of C and C++ (with more languages coming soon),
strong SSA-based optimization at compile-time, link-time, run-time, and
off-line, and multiple platform backends with Just-in-Time and ahead-of-time
-compilation frameworks. (See our tech report on <a
-href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">Lifelong
+compilation frameworks. (See our document on <a
+href="http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html">Lifelong
Code Optimization</a> for more.)</p>
<p>GCC: Many relatively mature platform backends support assembly-language code
@@ -173,7 +173,7 @@
<address>Brian R. Gaeke</address>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
<br>
- Last modified: $Date: 2003/11/12 21:39:31 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</div>
</body>
Index: llvm/docs/LangRef.html
diff -u llvm/docs/LangRef.html:1.43 llvm/docs/LangRef.html:1.43.2.1
--- llvm/docs/LangRef.html:1.43 Mon Jan 5 23:31:32 2004
+++ llvm/docs/LangRef.html Mon Mar 1 17:56:01 2004
@@ -1,4 +1,5 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>LLVM Assembly Language Reference Manual</title>
@@ -95,6 +96,19 @@
<li><a href="#i_va_copy">'<tt>llvm.va_copy</tt>' Intrinsic</a></li>
</ol>
</li>
+ <li><a href="#int_codegen">Code Generator Intrinsics</a>
+ <ol>
+ <li><a href="#i_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a></li>
+ <li><a href="#i_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
+ <li><a href="#int_libc">Standard C Library Intrinsics</a>
+ <ol>
+ <li><a href="#i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a></li>
+ <li><a href="#i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a></li>
+ <li><a href="#i_memset">'<tt>llvm.memset</tt>' Intrinsic</a></li>
+ </ol>
+ </li>
<li><a href="#int_debugger">Debugger intrinsics</a>
</ol>
</li>
@@ -242,12 +256,12 @@
<div class="doc_text">
<p>The primitive types are the fundemental building blocks of the LLVM
system. The current set of primitive types are as follows:</p>
-<p>
-<table border="0" align="center">
+
+<table border="0" style="align: center">
<tbody>
<tr>
<td>
- <table border="1" cellspacing="0" cellpadding="4" align="center">
+ <table border="1" cellspacing="0" cellpadding="4" style="align: center">
<tbody>
<tr>
<td><tt>void</tt></td>
@@ -281,7 +295,7 @@
</table>
</td>
<td valign="top">
- <table border="1" cellspacing="0" cellpadding="4" align="center"">
+ <table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
<td><tt>bool</tt></td>
@@ -313,7 +327,7 @@
</tr>
</tbody>
</table>
-</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_classifications">Type
@@ -321,8 +335,8 @@
<div class="doc_text">
<p>These different primitive types fall into a few useful
classifications:</p>
-<p>
-<table border="1" cellspacing="0" cellpadding="4" align="center">
+
+<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
<td><a name="t_signed">signed</a></td>
@@ -351,7 +365,7 @@
</tr>
</tbody>
</table>
-</p>
+
<p>The <a href="#t_firstclass">first class</a> types are perhaps the
most important. Values of these types are the only ones which can be
produced by instructions, passed as arguments, or used as operands to
@@ -383,7 +397,7 @@
<tt>[40 x uint]</tt>: Array of 40 unsigned integer values.</p>
<p> </p>
<p>Here are some examples of multidimensional arrays:</p>
-<p>
+
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -400,7 +414,7 @@
</tr>
</tbody>
</table>
-</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_function">Function Type</a> </div>
@@ -422,7 +436,7 @@
Variable argument functions can access their arguments with the <a
href="#int_varargs">variable argument handling intrinsic</a> functions.</p>
<h5>Examples:</h5>
-<p>
+
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -444,7 +458,7 @@
</tr>
</tbody>
</table>
-</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_struct">Structure Type</a> </div>
@@ -461,7 +475,7 @@
<h5>Syntax:</h5>
<pre> { <type list> }<br></pre>
<h5>Examples:</h5>
-<p>
+
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -477,7 +491,7 @@
</tr>
</tbody>
</table>
-</p>
+
</div>
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection"> <a name="t_pointer">Pointer Type</a> </div>
@@ -488,7 +502,7 @@
<h5>Syntax:</h5>
<pre> <type> *<br></pre>
<h5>Examples:</h5>
-<p>
+
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
@@ -504,7 +518,7 @@
</tr>
</tbody>
</table>
-</p>
+
</div>
<!-- _______________________________________________________________________ --><!--
<div class="doc_subsubsection">
@@ -559,7 +573,7 @@
and have one of the following linkage types:</a>
<p> </p>
<dl>
- <a name="linkage_internal"> <dt><tt><b>internal</b></tt> </dt>
+ <dt><tt><b><a name="linkage_internal">internal</a></b></tt> </dt>
<dd>Global values with internal linkage are only directly accessible
by objects in the current module. In particular, linking code into a
module with an internal global value may cause the internal to be
@@ -569,7 +583,7 @@
idea of "anonymous namespaces" in C++.
<p> </p>
</dd>
- </a><a name="linkage_linkonce"> <dt><tt><b>linkonce</b></tt>: </dt>
+ <dt><tt><b><a name="linkage_linkonce">linkonce</a></b></tt>: </dt>
<dd>"<tt>linkonce</tt>" linkage is similar to <tt>internal</tt>
linkage, with the twist that linking together two modules defining the
same <tt>linkonce</tt> globals will cause one of the globals to be
@@ -577,14 +591,14 @@
Unreferenced <tt>linkonce</tt> globals are allowed to be discarded.
<p> </p>
</dd>
- </a><a name="linkage_weak"> <dt><tt><b>weak</b></tt>: </dt>
+ <dt><tt><b><a name="linkage_weak">weak</a></b></tt>: </dt>
<dd>"<tt>weak</tt>" linkage is exactly the same as <tt>linkonce</tt>
linkage, except that unreferenced <tt>weak</tt> globals may not be
discarded. This is used to implement constructs in C such as "<tt>int
X;</tt>" at global scope.
<p> </p>
</dd>
- </a><a name="linkage_appending"> <dt><tt><b>appending</b></tt>: </dt>
+ <dt><tt><b><a name="linkage_appending">appending</a></b></tt>: </dt>
<dd>"<tt>appending</tt>" linkage may only be applied to global
variables of pointer to array type. When two global variables with
appending linkage are linked together, the two global arrays are
@@ -593,13 +607,12 @@
.o files are linked.
<p> </p>
</dd>
- </a><a name="linkage_external"> <dt><tt><b>externally visible</b></tt>:</dt>
+ <dt><tt><b><a name="linkage_external">externally visible</a></b></tt>:</dt>
<dd>If none of the above identifiers are used, the global is
externally visible, meaning that it participates in linkage and can be
used to resolve external symbol references.
<p> </p>
</dd>
- </a>
</dl>
<p> </p>
<p><a name="linkage_external">For example, since the "<tt>.LC0</tt>"
@@ -735,40 +748,61 @@
href="#i_ret">ret</a> int 1<br>IfUnequal:<br> <a href="#i_ret">ret</a> int 0<br></pre>
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection"> <a name="i_switch">'<tt>switch</tt>'
-Instruction</a> </div>
+<div class="doc_subsubsection">
+ <a name="i_switch">'<tt>switch</tt>' Instruction</a>
+</div>
+
<div class="doc_text">
<h5>Syntax:</h5>
-<pre> switch uint <value>, label <defaultdest> [ int <val>, label &dest>, ... ]<br></pre>
+
+<pre>
+ switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
+</pre>
+
<h5>Overview:</h5>
-<p>The '<tt>switch</tt>' instruction is used to transfer control flow
-to one of several different places. It is a generalization of the '<tt>br</tt>'
+
+<p>The '<tt>switch</tt>' instruction is used to transfer control flow to one of
+several different places. It is a generalization of the '<tt>br</tt>'
instruction, allowing a branch to occur to one of many possible
destinations.</p>
+
+
<h5>Arguments:</h5>
-<p>The '<tt>switch</tt>' instruction uses three parameters: a '<tt>uint</tt>'
-comparison value '<tt>value</tt>', a default '<tt>label</tt>'
-destination, and an array of pairs of comparison value constants and '<tt>label</tt>'s.</p>
+
+<p>The '<tt>switch</tt>' instruction uses three parameters: an integer
+comparison value '<tt>value</tt>', a default '<tt>label</tt>' destination, and
+an array of pairs of comparison value constants and '<tt>label</tt>'s. The
+table is not allowed to contain duplicate constant entries.</p>
+
<h5>Semantics:</h5>
+
<p>The <tt>switch</tt> instruction specifies a table of values and
destinations. When the '<tt>switch</tt>' instruction is executed, this
table is searched for the given value. If the value is found, the
corresponding destination is branched to, otherwise the default value
it transfered to.</p>
+
<h5>Implementation:</h5>
-<p>Depending on properties of the target machine and the particular <tt>switch</tt>
-instruction, this instruction may be code generated as a series of
-chained conditional branches, or with a lookup table.</p>
-<h5>Example:</h5>
-<pre> <i>; Emulate a conditional br instruction</i>
- %Val = <a
- href="#i_cast">cast</a> bool %value to uint<br> switch uint %Val, label %truedest [int 0, label %falsedest ]<br><br> <i>; Emulate an unconditional br instruction</i>
- switch uint 0, label %dest [ ]
-
- <i>; Implement a jump table:</i>
- switch uint %val, label %otherwise [ int 0, label %onzero,
- int 1, label %onone,
- int 2, label %ontwo ]
+
+<p>Depending on properties of the target machine and the particular
+<tt>switch</tt> instruction, this instruction may be code generated in different
+ways, for example as a series of chained conditional branches, or with a lookup
+table.</p>
+
+<h5>Example:</h5>
+
+<pre>
+ <i>; Emulate a conditional br instruction</i>
+ %Val = <a href="#i_cast">cast</a> bool %value to int
+ switch int %Val, label %truedest [int 0, label %falsedest ]
+
+ <i>; Emulate an unconditional br instruction</i>
+ switch uint 0, label %dest [ ]
+
+ <i>; Implement a jump table:</i>
+ switch uint %val, label %otherwise [ uint 0, label %onzero
+ uint 1, label %onone
+ uint 2, label %ontwo ]
</pre>
</div>
<!-- _______________________________________________________________________ -->
@@ -1032,7 +1066,7 @@
<h5>Semantics:</h5>
<p>The truth table used for the '<tt>and</tt>' instruction is:</p>
<p> </p>
-<center>
+<div style="align: center">
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
@@ -1062,7 +1096,7 @@
</tr>
</tbody>
</table>
-</center>
+</div>
<h5>Example:</h5>
<pre> <result> = and int 4, %var <i>; yields {int}:result = 4 & %var</i>
<result> = and int 15, 40 <i>; yields {int}:result = 8</i>
@@ -1085,7 +1119,7 @@
<h5>Semantics:</h5>
<p>The truth table used for the '<tt>or</tt>' instruction is:</p>
<p> </p>
-<center>
+<div style="align: center">
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
@@ -1115,7 +1149,7 @@
</tr>
</tbody>
</table>
-</center>
+</div>
<h5>Example:</h5>
<pre> <result> = or int 4, %var <i>; yields {int}:result = 4 | %var</i>
<result> = or int 15, 40 <i>; yields {int}:result = 47</i>
@@ -1140,7 +1174,7 @@
<h5>Semantics:</h5>
<p>The truth table used for the '<tt>xor</tt>' instruction is:</p>
<p> </p>
-<center>
+<div style="align: center">
<table border="1" cellspacing="0" cellpadding="4">
<tbody>
<tr>
@@ -1170,7 +1204,7 @@
</tr>
</tbody>
</table>
-</center>
+</div>
<p> </p>
<h5>Example:</h5>
<pre> <result> = xor int 4, %var <i>; yields {int}:result = 4 ^ %var</i>
@@ -1249,8 +1283,8 @@
<p>The '<tt>malloc</tt>' instruction allocates memory from the system
heap and returns a pointer to it.</p>
<h5>Arguments:</h5>
-<p>The the '<tt>malloc</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt>
-bytes of memory from the operating system, and returns a pointer of the
+<p>The '<tt>malloc</tt>' instruction allocates <tt>sizeof(<type>)*NumElements</tt>
+bytes of memory from the operating system and returns a pointer of the
appropriate type to the program. The second form of the instruction is
a shorter version of the first instruction that defaults to allocating
one element.</p>
@@ -1594,23 +1628,31 @@
<!-- *********************************************************************** -->
<div class="doc_text">
-<p>LLVM supports the notion of an "intrinsic function". These
-functions have well known names and semantics, and are required to
-follow certain restrictions. Overall, these instructions represent an
-extension mechanism for the LLVM language that does not require
-changing all of the transformations in LLVM to add to the language (or
-the bytecode reader/writer, the parser, etc...).</p>
-<p>Intrinsic function names must all start with an "<tt>llvm.</tt>"
-prefix, this prefix is reserved in LLVM for intrinsic names, thus
-functions may not be named this. Intrinsic functions must always be
-external functions: you cannot define the body of intrinsic functions.
-Intrinsic functions may only be used in call or invoke instructions: it
-is illegal to take the address of an intrinsic function. Additionally,
-because intrinsic functions are part of the LLVM language, it is
-required that they all be documented here if any are added.</p>
-<p>Unless an intrinsic function is target-specific, there must be a
-lowering pass to eliminate the intrinsic or all backends must support
-the intrinsic function.</p>
+
+<p>LLVM supports the notion of an "intrinsic function". These functions have
+well known names and semantics, and are required to follow certain
+restrictions. Overall, these instructions represent an extension mechanism for
+the LLVM language that does not require changing all of the transformations in
+LLVM to add to the language (or the bytecode reader/writer, the parser,
+etc...).</p>
+
+<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix, this
+prefix is reserved in LLVM for intrinsic names, thus functions may not be named
+this. Intrinsic functions must always be external functions: you cannot define
+the body of intrinsic functions. Intrinsic functions may only be used in call
+or invoke instructions: it is illegal to take the address of an intrinsic
+function. Additionally, because intrinsic functions are part of the LLVM
+language, it is required that they all be documented here if any are added.</p>
+
+
+<p>
+Adding an intrinsic to LLVM is straight-forward if it is possible to express the
+concept in LLVM directly (ie, code generator support is not _required_). To do
+this, extend the default implementation of the IntrinsicLowering class to handle
+the intrinsic. Code generators use this class to lower intrinsics they do not
+understand to raw LLVM instructions that they do.
+</p>
+
</div>
<!-- ======================================================================= -->
@@ -1631,11 +1673,26 @@
<p>This example shows how the <a href="#i_vanext"><tt>vanext</tt></a>
instruction and the variable argument handling intrinsic functions are
used.</p>
-<pre>int %test(int %X, ...) {<br> ; Initialize variable argument processing<br> %ap = call sbyte*()* %<a
- href="#i_va_start">llvm.va_start</a>()<br><br> ; Read a single integer argument<br> %tmp = vaarg sbyte* %ap, int<br><br> ; Advance to the next argument<br> %ap2 = vanext sbyte* %ap, int<br><br> ; Demonstrate usage of llvm.va_copy and llvm.va_end<br> %aq = call sbyte* (sbyte*)* %<a
- href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)<br> call void %<a
- href="#i_va_end">llvm.va_end</a>(sbyte* %aq)<br><br> ; Stop processing of arguments.<br> call void %<a
- href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)<br> ret int %tmp<br>}<br></pre>
+<pre>
+int %test(int %X, ...) {
+ ; Initialize variable argument processing
+ %ap = call sbyte* %<a href="#i_va_start">llvm.va_start</a>()
+
+ ; Read a single integer argument
+ %tmp = vaarg sbyte* %ap, int
+
+ ; Advance to the next argument
+ %ap2 = vanext sbyte* %ap, int
+
+ ; Demonstrate usage of llvm.va_copy and llvm.va_end
+ %aq = call sbyte* %<a href="#i_va_copy">llvm.va_copy</a>(sbyte* %ap2)
+ call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %aq)
+
+ ; Stop processing of arguments.
+ call void %<a href="#i_va_end">llvm.va_end</a>(sbyte* %ap2)
+ ret int %tmp
+}
+</pre>
</div>
<!-- _______________________________________________________________________ -->
@@ -1704,6 +1761,277 @@
complex and require memory allocation, for example.</p>
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="int_codegen">Code Generator Intrinsics</a>
+</div>
+
+<div class="doc_text">
+<p>
+These intrinsics are provided by LLVM to expose special features that may only
+be implemented with code generator support.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_returnaddress">'<tt>llvm.returnaddress</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ call void* ()* %llvm.returnaddress(uint <level>)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.returnaddress</tt>' intrinsic returns a target-specific value
+indicating the return address of the current function or one of its callers.
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+The argument to this intrinsic indicates which function to return the address
+for. Zero indicates the calling function, one indicates its caller, etc. The
+argument is <b>required</b> to be a constant integer value.
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+The '<tt>llvm.returnaddress</tt>' intrinsic either returns a pointer indicating
+the return address of the specified call frame, or zero if it cannot be
+identified. The value returned by this intrinsic is likely to be incorrect or 0
+for arguments other than zero, so it should only be used for debugging purposes.
+</p>
+
+<p>
+Note that calling this intrinsic does not prevent function inlining or other
+aggressive transformations, so the value returned may not that of the obvious
+source-language caller.
+</p>
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_frameaddress">'<tt>llvm.frameaddress</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ call void* ()* %llvm.frameaddress(uint <level>)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.frameaddress</tt>' intrinsic returns the target-specific frame
+pointer value for the specified stack frame.
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+The argument to this intrinsic indicates which function to return the frame
+pointer for. Zero indicates the calling function, one indicates its caller,
+etc. The argument is <b>required</b> to be a constant integer value.
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+The '<tt>llvm.frameaddress</tt>' intrinsic either returns a pointer indicating
+the frame address of the specified call frame, or zero if it cannot be
+identified. The value returned by this intrinsic is likely to be incorrect or 0
+for arguments other than zero, so it should only be used for debugging purposes.
+</p>
+
+<p>
+Note that calling this intrinsic does not prevent function inlining or other
+aggressive transformations, so the value returned may not that of the obvious
+source-language caller.
+</p>
+</div>
+
+
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="int_libc">Standard C Library Intrinsics</a>
+</div>
+
+<div class="doc_text">
+<p>
+LLVM provides intrinsics for a few important standard C library functions.
+These intrinsics allow source-language front-ends to pass information about the
+alignment of the pointer arguments to the code generator, providing opportunity
+for more efficient code generation.
+</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_memcpy">'<tt>llvm.memcpy</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ call void (sbyte*, sbyte*, uint, uint)* %llvm.memcpy(sbyte* <dest>, sbyte* <src>,
+ uint <len>, uint <align>)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
+location to the destination location.
+</p>
+
+<p>
+Note that, unlike the standard libc function, the <tt>llvm.memcpy</tt> intrinsic
+does not return a value, and takes an extra alignment argument.
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+The first argument is a pointer to the destination, the second is a pointer to
+the source. The third argument is an (arbitrarily sized) integer argument
+specifying the number of bytes to copy, and the fourth argument is the alignment
+of the source and destination locations.
+</p>
+
+<p>
+If the call to this intrinisic has an alignment value that is not 0 or 1, then
+the caller guarantees that the size of the copy is a multiple of the alignment
+and that both the source and destination pointers are aligned to that boundary.
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+The '<tt>llvm.memcpy</tt>' intrinsic copies a block of memory from the source
+location to the destination location, which are not allowed to overlap. It
+copies "len" bytes of memory over. If the argument is known to be aligned to
+some boundary, this can be specified as the fourth argument, otherwise it should
+be set to 0 or 1.
+</p>
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_memmove">'<tt>llvm.memmove</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ call void (sbyte*, sbyte*, uint, uint)* %llvm.memmove(sbyte* <dest>, sbyte* <src>,
+ uint <len>, uint <align>)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.memmove</tt>' intrinsic moves a block of memory from the source
+location to the destination location. It is similar to the '<tt>llvm.memcpy</tt>'
+intrinsic but allows the two memory locations to overlap.
+</p>
+
+<p>
+Note that, unlike the standard libc function, the <tt>llvm.memmove</tt> intrinsic
+does not return a value, and takes an extra alignment argument.
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+The first argument is a pointer to the destination, the second is a pointer to
+the source. The third argument is an (arbitrarily sized) integer argument
+specifying the number of bytes to copy, and the fourth argument is the alignment
+of the source and destination locations.
+</p>
+
+<p>
+If the call to this intrinisic has an alignment value that is not 0 or 1, then
+the caller guarantees that the size of the copy is a multiple of the alignment
+and that both the source and destination pointers are aligned to that boundary.
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+The '<tt>llvm.memmove</tt>' intrinsic copies a block of memory from the source
+location to the destination location, which may overlap. It
+copies "len" bytes of memory over. If the argument is known to be aligned to
+some boundary, this can be specified as the fourth argument, otherwise it should
+be set to 0 or 1.
+</p>
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="i_memset">'<tt>llvm.memset</tt>' Intrinsic</a>
+</div>
+
+<div class="doc_text">
+
+<h5>Syntax:</h5>
+<pre>
+ call void (sbyte*, ubyte, uint, uint)* %llvm.memset(sbyte* <dest>, ubyte <val>,
+ uint <len>, uint <align>)
+</pre>
+
+<h5>Overview:</h5>
+
+<p>
+The '<tt>llvm.memset</tt>' intrinsic fills a block of memory with a particular
+byte value.
+</p>
+
+<p>
+Note that, unlike the standard libc function, the <tt>llvm.memset</tt> intrinsic
+does not return a value, and takes an extra alignment argument.
+</p>
+
+<h5>Arguments:</h5>
+
+<p>
+The first argument is a pointer to the destination to fill, the second is the
+byte value to fill it with, the third argument is an (arbitrarily sized) integer
+argument specifying the number of bytes to fill, and the fourth argument is the
+known alignment of destination location.
+</p>
+
+<p>
+If the call to this intrinisic has an alignment value that is not 0 or 1, then
+the caller guarantees that the size of the copy is a multiple of the alignment
+and that the destination pointer is aligned to that boundary.
+</p>
+
+<h5>Semantics:</h5>
+
+<p>
+The '<tt>llvm.memset</tt>' intrinsic fills "len" bytes of memory starting at the
+destination location. If the argument is known to be aligned to some boundary,
+this can be specified as the fourth argument, otherwise it should be set to 0 or
+1.
+</p>
+</div>
+
<!-- ======================================================================= -->
<div class="doc_subsection">
@@ -1722,9 +2050,15 @@
<!-- *********************************************************************** -->
<hr>
-<div class="doc_footer">
-<address><a href="mailto:sabre at nondot.org">Chris Lattner</a></address>
-<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a> <br>
-Last modified: $Date: 2004/01/06 05:31:32 $ </div>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
+
+ <a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2004/03/01 23:56:01 $
+</address>
</body>
</html>
Index: llvm/docs/ProgrammersManual.html
diff -u llvm/docs/ProgrammersManual.html:1.53 llvm/docs/ProgrammersManual.html:1.53.2.1
--- llvm/docs/ProgrammersManual.html:1.53 Wed Jan 14 18:14:41 2004
+++ llvm/docs/ProgrammersManual.html Mon Mar 1 17:56:01 2004
@@ -1793,8 +1793,6 @@
function</li>
<li><tt> const Type * getReturnType() const</tt>: Returns the
return type of the function.</li>
- <li><tt> const ParamTypes &getParamTypes() const</tt>:
- Returns a vector of parameter types.</li>
<li><tt>const Type * getParamType (unsigned i)</tt>: Returns
the type of the ith parameter.</li>
<li><tt> const unsigned getNumParams() const</tt>: Returns the
@@ -1831,7 +1829,7 @@
<a href="mailto:dhurjati at cs.uiuc.edu">Dinakar Dhurjati</a> and
<a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date: 2004/01/15 00:14:41 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</address>
</body>
Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.102 llvm/docs/ReleaseNotes.html:1.102.2.1
--- llvm/docs/ReleaseNotes.html:1.102 Tue Jan 20 13:16:50 2004
+++ llvm/docs/ReleaseNotes.html Mon Mar 1 17:56:01 2004
@@ -69,34 +69,62 @@
<div class="doc_text">
-<p>This is the third public release of the LLVM compiler infrastructure.
+<p>
+This is the third public release of the LLVM compiler infrastructure. This
+release incorporates several <a href="#newfeatures">new features</a> (including
+exception handling support for the native code generators, the start of a
+source-level debugger, and profile guided optimizer components), many <a
+href="#qualityofimp">speedups</a> and <a href="#codequality">code quality</a>
+improvements, documentation improvements, and a small collection of important <a
+href="bugfix">bug fixes</a>. Overall, this is our highest quality release to
+date, and we encourage you to upgrade if you are using LLVM 1.0 or 1.1.
</p>
-<p>At this time, LLVM is known to correctly compile and run all non-unwinding C
+<p><B> FIXME: UPDATE: </b>
+At this time, LLVM is known to correctly compile and run all C
& C++ SPEC CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist
benchmarks. It has also been used to compile <b>many</b> other programs. LLVM
now also works with a broad variety of C++ programs, though it has still
-received much less testing than the C front-end.
+received less testing than the C front-end.
</p>
-<p>
-The LLVM native code generators are very stable but do not currently support
-unwinding (exception throwing or <tt>longjmp</tt>ing), which prevent them from
-working with programs like the <tt>253.perlbmk</tt> in SPEC CPU2000. The C
-backend and the rest of LLVM supports these programs, so you can
-still use LLVM with them. Support for unwinding will be added in a future
-release.
-</p>
-
-
<!--=========================================================================-->
<div class="doc_subsubsection">
-This release implements the following new features:
+<a name="newfeatures">This release implements the following new features:</a>
</div>
<ol>
-<li></li>
-<li></li>
+<li><a href="SourceLevelDebugging.html">A new LLVM source-level debugger has been started.</a></li>
+<li>LLVM 1.2 encodes bytecode files for large programs in 10-30% less space.</li>
+<li>LLVM can now feed profile information back into optimizers for Profile Guided Optimization, and includes a simple basic block reordering pass.</li>
+<li>The LLVM JIT lazily initializes global variables, reducing startup time for programs with lots of globals (like C++ programs).</li>
+
+<li>The build and installation infrastructure in this release is dramatically
+improved. There is now an <a
+href="http://llvm.cs.uiuc.edu/PR105"><tt>autoconf/AutoRegen.sh</tt> script</a>
+that you can run to rebuild the <tt>configure</tt> script and its associated
+files as well as beta support for "<a
+href="http://llvm.cs.uiuc.edu/PR208">make</a> <a
+href="http://llvm.cs.uiuc.edu/PR220">install</a>" and <a
+href="http://llvm.cs.uiuc.edu/PR203">RPM package generation</a>.</li>
+
+<li>The "tblgen" tool is <a href="TableGenFundamentals.html">now documented</a>.</li>
+<li>The LLVM code generator got a multitude of improvements:
+<ul>
+<li>It can now fold spill code into instructions on targets that support it.</li>
+<li>A generic machine code spiller/rewriter was added. It provides an API for
+global register allocators to eliminate virtual registers and add the
+appropriate spill code.</li>
+<li>The represenation of machine basic blocks got cleaned up and improved to
+allow easier development and more efficient implementation.</li>
+</ul>
+</li>
+<li><a href="http://llvm.cs.uiuc.edu/PR253">LLVM now no longer depends on the boost library</a>.</li>
+<li>The X86 backend now generates <b>substantially</b> better native code, and is faster.</li>
+<li>The C backend has been turned moved from the "llvm-dis" tool to the "llc"
+tool. You can activate it with "<tt>llc -march=c foo.bc -o foo.c</tt>".</li>
+<li>LLVM includes a new interprocedural optimization that marks global variables
+"constant" when they are provably never written to.</li>
</ol>
@@ -106,14 +134,16 @@
</div>
<ol>
-<li></li>
-<li></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR16">Exception handling support in the X86
+& Sparc native code generators</a></li>
+<li>The C/C++ front-end now support the GCC <tt>__builtin_return_address</tt> and <tt>__builtin_frame_address</tt> extensions.</li>
+<li><a href="http://llvm.cs.uiuc.edu/PR249">[X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808</a></li>
</ol>
<!--=========================================================================-->
<div class="doc_subsubsection">
-In this release, the following Quality of Implementation issues were fixed:
+<a name="qualityofimp">In this release, the following Quality of Implementation issues were fixed:</a>
</div>
<ol>
@@ -123,6 +153,11 @@
<li><a href="http://llvm.cs.uiuc.edu/PR196">[vmcore] OpaqueType objects memory leak</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR182">[llvmgcc] C front-end does not compile "extern inline" into linkonce</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR73">Bytecode format inconsistent</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR209">[loadvn/inline/scalarrepl] Slow optimizations with extremely large basic blocks</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR224">[asmparser] Really slow parsing of types with complex upreferences</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR205">[llvmgcc] C front-end does not emit 'zeroinitializer' when possible</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR233">[llvmgcc] Structure copies result in a LOT of code</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR239">LLVM is now much more memory efficient when handling large zero initialized arrays</a></li>
</ol>
<!--=========================================================================-->
@@ -132,21 +167,28 @@
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR210">[build] Makefiles break if C frontend target string has unexpected value</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR214">[build] hard-wired assumption that shared-library extension is ".so"</a></li>
+<li><A href="http://llvm.cs.uiuc.edu/PR222">make tools-only doesn't make lib/Support</a></li>
</ol>
<!--=========================================================================-->
<div class="doc_subsubsection">
-In this release, the following Code Quality issues were fixed:
+<a name="codequality">In this release, the following Code Quality issues were fixed:</a>
</div>
<ol>
<li><a href="http://llvm.cs.uiuc.edu/PR187">[loopsimplify] Many pointless phi nodes are created</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR237">[x86] wierd stack/frame pointer manipulation</a></li>
+
+<li>The X86 backend now generate <tt>fchs</tt> to negate floating point numbers,
+compiles memcpy() into the <tt>rep movs</tt> instruction, and makes much better
+use of powerful addressing modes and instructions.</li>
</ol>
<!--=========================================================================-->
<div class="doc_subsubsection">
-In this release, the following bugs in the previous release were fixed:
+<a name="bugfix">In this release, the following bugs in the previous release were fixed:</a>
</div>
<p>Bugs in the LLVM Core:</p>
@@ -161,10 +203,22 @@
<li><a href="http://llvm.cs.uiuc.edu/PR193">[constantmerge] Merging globals can
cause use of invalid pointers!</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR212">[bcreader] Bytecode reader misreads 'long -9223372036854775808'!</a></li>
-
+<li><a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=174">Tail duplication does not update SSA form correctly.</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR218">VMCore mishandles double -0.0</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR219">[X86] X86 backend code generates -0.0 as +0.0</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR223">[loopsimplify] Loopsimplify incorrectly updates dominator information</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR225">[pruneeh] -pruneeh pass removes invoke instructions it shouldn't</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR228">[sparc] Boolean constants are emitted as true and false</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR234">[interpreter] va_list values silently corrupted by function calls</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR235">Tablegen aborts on errors</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR236">[inliner] Error inlining intrinsic calls into invoke instructions</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR245">Linking weak and strong global variables is dependent on link order</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR258">Variables used to define non-printable FP constants are externally visible</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR259">CBE gives linkonce functions wrong linkage semantics</a></li>
</ol>
+
<p>Bugs in the C/C++ front-end:</p>
<ol>
@@ -172,6 +226,9 @@
management functions in libc runtime to allow them to be overriden</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR202">[llvm-gcc] asserts when an extern inline function is redefined</a></li>
<li><a href="http://llvm.cs.uiuc.edu/PR204">[llvmg++] Dynamically initialized constants cannot be marked 'constant'</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR216">[llvmgcc] floating-point unary minus is incorrect for +0.0</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR221">[llvm-gcc] miscompilation of 'X = Y = Z' with aggregate values</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR244">[llvm-gcc] miscompilation when a function is re-declared as static</a></li>
</ol>
</div>
@@ -242,24 +299,13 @@
<li><a href="http://llvm.cs.uiuc.edu/PR82">LLVM cannot handle structures with
more than 256 elements</a>.</li>
-<li>
-The gccld program
-<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=139">
-does not link objects/archives in the order specified on the command line.
-</a>
-</li>
-
-<li>
-<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=174">
-Tail duplication does not update SSA form correctly.
-</a>
-</li>
-
-<li><a href="http://llvm.cs.uiuc.edu/PR16">[lowerinvoke] The -lowerinvoke pass
-does not insert calls to setjmp/longjmp</a>.</li>
+<li>The gccld program <a href="http://llvm.cs.uiuc.edu/PR139">does not link objects/archives in the order specified on the command line.</a></li>
+<li><a href="http://llvm.cs.uiuc.edu/PR240">The lower-invoke pass does not mark
+values live across a setjmp as volatile</a>. This missing feature only effects
+targets whose setjmp/longjmp libraries do not save and restore the entire
+register file.</li>
</ul>
-
</div>
<!-- ======================================================================= -->
@@ -286,21 +332,6 @@
<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=162">with the largest
union member</a>.
</li>
-
-<li>
-<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=182">
-Functions marked "extern inline" are not compiled into LLVM with linkonce
-linkage.
-</a>
-</li>
-
-
-<li>
-The memory management functions in the libc runtime
-<a href="http://llvm.cs.uiuc.edu/PR186">need weak linkage so that they can be
-overridden.
-</a>
-</li>
</ul>
</div>
@@ -340,7 +371,6 @@
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Constraints.html#Constraints">Constraints</a>: Constraints for asm operands.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html#Asm%20Labels">Asm Labels</a>: Specifying the assembler name to use for a C symbol.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Explicit-Reg-Vars.html#Explicit%20Reg%20Vars">Explicit Reg Vars</a>: Defining variables residing in specified registers.</li>
- <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html#Vector%20Extensions">Vector Extensions</a>: Using vector instructions through built-in functions.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Target-Builtins.html#Target%20Builtins">Target Builtins</a>: Built-in functions specific to particular targets.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html#Thread-Local">Thread-Local</a>: Per-thread variables.</li>
@@ -434,6 +464,7 @@
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Alternate-Keywords.html#Alternate%20Keywords">Alternate Keywords</a>:<code>__const__</code>, <code>__asm__</code>, etc., for header files.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html#Incomplete%20Enums">Incomplete Enums</a>: <code>enum foo;</code>, with details to follow.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Function-Names.html#Function%20Names">Function Names</a>: Printable strings which are the name of the current function.</li>
+ <li><a href="http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html#Return%20Address">Return Address</a>: Getting the return or frame address of a function.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed%20Fields">Unnamed Fields</a>: Unnamed struct/union fields within structs/unions.</li>
<li><a href="http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute%20Syntax">Attribute Syntax</a>: Formal syntax for attributes.</li>
</ol></li>
@@ -460,21 +491,13 @@
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
- Bugs
-</div>
+<div class="doc_subsubsection">Bugs</div>
<div class="doc_text">
<ul>
<li>The C++ front-end inherits all problems afflicting the <a href="#c-fe">C
front-end</a>.</li>
-
-<li>
-<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=137">
-Code is generated for empty classes.
-</a>
-</li>
</ul>
</div>
@@ -521,12 +544,7 @@
<div class="doc_text">
<ul>
-
-<li>The X86 code generator <a
-href="http://llvm.cs.uiuc.edu/PR16">does not currently
-support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
-or calls the C <tt>longjmp</tt> function will abort.</li>
-
+<li>None so far.
</ul>
</div>
@@ -539,17 +557,7 @@
<div class="doc_text">
<ul>
-
-<li>The Sparc code generator <a
-href="http://llvm.cs.uiuc.edu/PR16">does not currently
-support the <tt>unwind</tt> instruction</a>, so code that throws a C++ exception
-or calls the C <tt>longjmp</tt> function will abort.</li>
-
-<li>
-<a href="http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=167">
-The llc program can crash on legal code.
-</a>
-</li>
+<li>None so far.
</ul>
</div>
@@ -611,7 +619,7 @@
src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date: 2004/01/20 19:16:50 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</address>
</body>
Index: llvm/docs/TestingGuide.html
diff -u llvm/docs/TestingGuide.html:1.6 llvm/docs/TestingGuide.html:1.6.4.1
--- llvm/docs/TestingGuide.html:1.6 Mon Nov 3 08:59:59 2003
+++ llvm/docs/TestingGuide.html Mon Mar 1 17:56:01 2004
@@ -1,11 +1,10 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
+ "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
- <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
- <link rel="stylesheet" href="llvm.css" type="text/css" media="screen" />
- <title>LLVM Test Suite Guide</title>
+ <title>LLVM Test Suite Guide</title>
+ <link rel="stylesheet" href="llvm.css" type="text/css">
</head>
-
<body>
<div class="doc_title">
@@ -16,414 +15,369 @@
<li><a href="#overview">Overview</a></li>
<li><a href="#Requirements">Requirements</a></li>
<li><a href="#quick">Quick Start</a></li>
-<li><a href="#org">LLVM Test Suite Organization</a></li>
+<li><a href="#org">LLVM Test Suite Organization</a>
<ul>
<li><a href="#codefragments">Code Fragments</a></li>
<li><a href="#wholeprograms">Whole Programs</a></li>
-</ul>
+</ul></li>
<li><a href="#tree">LLVM Test Suite Tree</a></li>
<li><a href="#qmstructure">QMTest Structure</a></li>
<li><a href="#progstructure">Programs Structure</a></li>
<li><a href="#run">Running the LLVM Tests</a></li>
-<p><b>Written by John T. Criswell</b></p>
</ol>
- <!--===============================================================-->
- <div class="doc_section"><a name="overview">Overview</a></div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>
- This document is the reference manual for the LLVM test suite. It
- documents the structure of the LLVM test suite, the tools needed to
- use it, and how to add and run tests.
- </p>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><a name="Requirements">Requirements</a></div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>
- In order to use the LLVM test suite, you will need all of the software
- required to build LLVM, plus the following:
- </p>
- <dl compact>
- <dt><A HREF="http://www.qmtest.com">QMTest</A></dt>
- <dd>The LLVM test suite uses QMTest to organize and
- run tests.</dd>
-
- <dt><A HREF="http://www.python.org">Python</A></dt>
- <dd>You will need a Python interpreter that works with
- QMTest. Python will need zlib and SAX support
- enabled.</dd>
- </dl>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><a name="quick">Quick Start</a></div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>
- The tests are located in the LLVM source tree under the directory
- <tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master
- Makefile in that directory:
- </p>
- <pre>
- % gmake -C llvm/test
- </pre>
-
- <p>
- To run only the code fragment tests (i.e. those that do basic testing of
- LLVM), run the tests organized by QMTest:
- </p>
-
- <pre>
- % gmake -C llvm/test qmtest
- </pre>
-
- <p>
- To run only the tests that compile and execute whole programs, run the
- Programs tests:
- </p>
-
- <pre>
- % gmake -C llvm/test/Programs
- </pre>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><h2><a name="org">LLVM Test Suite
- Organization </a></h2></div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>The LLVM test suite contains two major categories of tests: code
- fragments and whole programs.</p>
- </div>
-
- <div class="doc_subsection"><a name="codefragments">Code Fragments</a>
- </div>
-
- <div class="doc_text">
- <p>
- Code fragments are small pieces of code that test a specific
- feature of LLVM or trigger a specific bug in LLVM. They are
- usually written in LLVM assembly language, but can be
- written in other languages if the test targets a
- particular language front end.
- </p><p>
- Code fragments are not complete programs, and they are
- never executed to determine correct behavior.
- </p><p>
- The tests in the Features and
- Regression directories contain code fragments.
- </p>
- </div>
-
- <div class="doc_subsection"><a name="wholeprograms">Whole Programs</a>
- </div>
-
- <div class="doc_text">
- <p>
- Whole Programs are pieces of code which can be compiled and
- linked into a stand-alone program that can be executed. These
- programs are generally written in high level languages such as C
- or C++, but sometimes they are written straight in LLVM
- assembly.
- </p><p>
- These programs are compiled and then executed using several
- different methods (native compiler, LLVM C backend, LLVM JIT,
- LLVM native code generation, etc). The output of these programs
- is compared to ensure that LLVM is compiling the program
- correctly.
- </p><p>
- In addition to compiling and executing programs, whole program
- tests serve as a way of benchmarking LLVM performance, both in
- terms of the efficiency of the programs generated as well as the
- speed with which LLVM compiles, optimizes, and generates code.
- </p><p>
- The Programs directory contains all tests which compile and
- benchmark whole programs.
- </p>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><h2><a name="tree">LLVM Test Suite Tree</a>
- </div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>Each type of test in the LLVM test suite has its own directory. The
- major subtrees of the test suite directory tree are as follows:</p>
+<p><b>Written by John T. Criswell</b></p>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="overview">Overview</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>This document is the reference manual for the LLVM test suite. It documents
+the structure of the LLVM test suite, the tools needed to use it, and how to add
+and run tests.</p>
+
+</div>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="Requirements">Requirements</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>In order to use the LLVM test suite, you will need all of the software
+required to build LLVM, plus the following:</p>
+
+<dl>
+ <dt><a href="http://www.qmtest.com">QMTest</A></dt>
+ <dd>The LLVM test suite uses QMTest to organize and run tests.</dd>
+
+ <dt><a href="http://www.python.org">Python</A></dt>
+ <dd>You will need a Python interpreter that works with QMTest. Python will
+ need zlib and SAX support enabled.</dd>
+</dl>
+
+</div>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="quick">Quick Start</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p> The tests are located in the LLVM source tree under the directory
+<tt>llvm/test</tt>. To run all of the tests in LLVM, use the Master Makefile in
+that directory:</p>
+
+<pre>
+ % gmake -C llvm/test
+</pre>
+
+<p>To run only the code fragment tests (i.e. those that do basic testing of
+LLVM), run the tests organized by QMTest:</p>
+
+<pre>
+ % gmake -C llvm/test qmtest
+</pre>
+
+<p>To run only the tests that compile and execute whole programs, run the
+Programs tests:</p>
+
+<pre>
+ % gmake -C llvm/test/Programs
+</pre>
+
+</div>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="org">LLVM Test Suite Organization</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>The LLVM test suite contains two major categories of tests: code
+fragments and whole programs.</p>
+
+</div>
+
+<div class="doc_subsection"><a name="codefragments">Code Fragments</a>
+</div>
+
+<div class="doc_text">
+
+<p>Code fragments are small pieces of code that test a specific feature of LLVM
+or trigger a specific bug in LLVM. They are usually written in LLVM assembly
+language, but can be written in other languages if the test targets a particular
+language front end.</p>
+
+<p>Code fragments are not complete programs, and they are never executed to
+determine correct behavior.</p>
+
+<p>The tests in the Features and Regression directories contain code
+fragments.</p>
+
+</div>
+
+<div class="doc_subsection"><a name="wholeprograms">Whole Programs</a></div>
+
+<div class="doc_text">
+
+<p>Whole Programs are pieces of code which can be compiled and linked into a
+stand-alone program that can be executed. These programs are generally written
+in high level languages such as C or C++, but sometimes they are written
+straight in LLVM assembly.</p>
+
+<p>These programs are compiled and then executed using several different
+methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation,
+etc). The output of these programs is compared to ensure that LLVM is compiling
+the program correctly.</p>
+
+<p>In addition to compiling and executing programs, whole program tests serve as
+a way of benchmarking LLVM performance, both in terms of the efficiency of the
+programs generated as well as the speed with which LLVM compiles, optimizes, and
+generates code.</p>
+
+<p>The Programs directory contains all tests which compile and benchmark whole
+programs.</p>
+
+</div>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="tree">LLVM Test Suite Tree</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>Each type of test in the LLVM test suite has its own directory. The major
+subtrees of the test suite directory tree are as follows:</p>
+
+<ul>
+ <li>Features
+ <p>This directory contains sample codes that test various features of the
+ LLVM language. These pieces of sample code are run through various
+ assembler, disassembler, and optimizer passes.</p>
+
+ <li>Regression
+ <p>This directory contains regression tests for LLVM. When a bug is found
+ in LLVM, a regression test containing just enough code to reproduce the
+ problem should be written and placed somewhere underneath this directory.
+ In most cases, this will be a small piece of LLVM assembly language code,
+ often distilled from an actual application or benchmark.</p>
+
+ <li>Programs
+ <p>The Programs directory contains programs that can be compiled with LLVM
+ and executed. These programs are compiled using the native compiler and
+ various LLVM backends. The output from the program compiled with the native
+ compiler is assumed correct; the results from the other programs are
+ compared to the native program output and pass if they match. </p>
+
+ <p> In addition for testing correctness, the Programs directory also
+ performs timing tests of various LLVM optimizations. It also records
+ compilation times for the compilers and the JIT. This information can be
+ used to compare the effectiveness of LLVM's optimizations and code
+ generation.</p>
+
+ <p>The Programs directory is subdivided into several smaller subdirectories:
+ </p>
+
+ <ul>
+ <li>Programs/SingleSource
+ <p>The SingleSource directory contains test programs that are only a
+ single source file in size. These are usually small benchmark programs
+ or small programs that calculate a particular value. Several such
+ programs are grouped together in each directory.</p></li>
+
+ <li>Programs/MultiSource
+ <p>The MultiSource directory contains subdirectories which contain
+ entire programs with multiple source files. Large benchmarks and whole
+ applications go here.</p></li>
+
+ <li>Programs/External
+ <p>The External directory contains Makefiles for building code that is
+ external to (i.e. not distributed with) LLVM. The most prominent member
+ of this directory is the SPEC 2000 benchmark suite. The presence and
+ location of these external programs is configured by the LLVM
+ <tt>configure</tt> script.</p></li>
- <ul>
- <li>Features
- <p>
- This directory contains sample codes that test various features
- of the LLVM language. These pieces of sample code are run
- through various assembler, disassembler, and optimizer passes.
- </p>
-
- <li>Regression
- <p>
- This directory contains regression tests for LLVM. When a bug
- is found in LLVM, a regression test containing just enough
- code to reproduce the problem should be written and placed
- somewhere underneath this directory. In most cases, this
- will be a small piece of LLVM assembly language code, often
- distilled from an actual application or benchmark.
- </p>
-
- <li>Programs
- <p>
- The Programs directory contains programs that can be compiled
- with LLVM and executed. These programs are compiled using the
- native compiler and various LLVM backends. The output from the
- program compiled with the native compiler is assumed correct;
- the results from the other programs are compared to the native
- program output and pass if they match.
- </p><p>
- In addition for testing correctness, the Programs directory
- also performs timing tests of various LLVM optimizations.
- It also records compilation times for the compilers and the
- JIT. This information can be used to compare the
- effectiveness of LLVM's optimizations and code generation.
- </p><p>
- The Programs directory is subdivided into several smaller
- subdirectories:
- </p>
-
- <ul>
- <li>Programs/SingleSource
- <p>
- The SingleSource directory contains test programs that
- are only a single source file in size. These are
- usually small benchmark programs or small programs that
- calculate a particular value. Several such programs are
- grouped together in each directory.
- </p>
-
- <li>Programs/MultiSource
- <p>
- The MultiSource directory contains subdirectories which
- contain entire programs with multiple source files.
- Large benchmarks and whole applications go here.
- </p>
-
- <li>Programs/External
- <p>
- The External directory contains Makefiles for building
- code that is external to (i.e. not distributed with)
- LLVM. The most prominent member of this directory is
- the SPEC 2000 benchmark suite. The presence and
- location of these external programs is configured by the
- LLVM <tt>configure</tt> script.
- </p>
- </ul>
-
- <p>
-
- <li>QMTest
- <p>
- This directory contains the QMTest information files. Inside
- this directory are QMTest administration files and the Python
- code that implements the LLVM test and database classes.
- </p>
- </ul>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><h2><a name="qmstructure">QMTest Structure</a>
- </div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>
- The LLVM test suite is partially driven by QMTest and partially
- driven by GNU Make. Specifically, the Features and Regression tests
- are all driven by QMTest. The Programs directory is currently
- driven by a set of Makefiles.
- </p><p>
- The QMTest system needs to have several pieces of information
- available; these pieces of configuration information are known
- collectively as the "context" in QMTest parlance. Since the context
- for LLVM is relatively large, the master Makefile in llvm/test
- sets it for you.
- </p><p>
- The LLVM database class makes the subdirectories of llvm/test a
- QMTest test database. For each directory that contains tests driven by
- QMTest, it knows what type of test the source file is and how to run it.
- </p><p>
- Hence, the QMTest namespace is essentially what you see in the
- Feature and Regression directories, but there is some magic that
- the database class performs (as described below).
- </p><p>
- The QMTest namespace is currently composed of the following tests and
- test suites:
- </p>
-
- <ul>
- <li>Feature
- <p>
- These are the feature tests found in the Feature directory.
- They are broken up into the following categories:
- </p>
- <ul>
- <li>ad
- <p>
- Assembler/Disassembler tests. These tests verify that a
- piece of LLVM assembly language can be assembled into
- bytecode and then disassembled into the original
- assembly language code. It does this several times to
- ensure that assembled output can be disassembled and
- disassembler output can be assembled. It also verifies
- that the give assembly language file can be assembled
- correctly.
- </p>
-
- <li>opt
- <p>
- Optimizer tests. These tests verify that two of the
- optimizer passes completely optimize a program (i.e.
- after a single pass, they cannot optimize a program
- any further).
- </p>
-
- <li>mc
- <p>
- Machine code tests. These tests verify that the LLVM
- assembly language file can be translated into native
- assembly code.
- </p>
-
- <li>cc
- <p>
- C code tests. These tests verify that the specified
- LLVM assembly code can be converted into C source code
- using the C backend.
- </p>
- </ul>
-
- <p>
- The LLVM database class looks at every file in the Feature
- directory and creates a fake test hierarchy containing
- <tt>Feature.<testtype>.<testname></tt>. So, if you
- add an LLVM assembly language file to the Feature directory, it
- actually creates 5 new tests: assembler/disassembler, assembler,
- optimizer, machine code, and C code.
- </p>
-
- <li>Regression
- <p>
- These are the regression tests. There is one suite for each
- subdirectory of the Regression directory. If you add a new
- subdirectory there, you will need to modify, at least, the
- <tt>RegressionMap</tt> variable in <tt>QMTest/llvmdb.py</tt> so
- that QMTest knows how to run the tests in the new subdirectory.
- </p>
- </ul>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><h2><a name="progstructure">Programs
- Structure</a></div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>
- As mentioned previously, the Programs tree in llvm/test provides three
- types of tests: MultiSource, SingleSource, and External. Each tree is
- then subdivided into several categories, including applications,
- benchmarks, regression tests, code that is strange grammatically, etc.
- These organizations should be relatively self explanatory.
- </p><p>
- In addition to the regular Programs tests, the Programs tree also
- provides a mechanism for compiling the programs in different ways. If
- the variable TEST is defined on the gmake command line, the test system
- will include a Makefile named <tt>TEST.<value of TEST
- variable>.Makefile</tt>. This Makefile can modify build rules to
- yield different results.
- </p><p>
- For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt>
- to create the nightly test reports. To run the nightly tests, run
- <tt>gmake TEST=nightly</tt>.
- </p><p>
- There are several TEST Makefiles available in the tree. Some of them
- are designed for internal LLVM research and will not work outside of the
- LLVM research group. They may still be valuable, however, as a guide to
- writing your own TEST Makefile for any optimization or analysis passes
- that you develop with LLVM.
- </p>
- </div>
-
- <!--===============================================================-->
- <div class="doc_section"><h2><a name="run">Running the LLVM Tests</a>
- </div>
- <!--===============================================================-->
-
- <div class="doc_text">
- <p>
- First, all tests are executed within the LLVM object directory tree.
- They <i>are not</i> executed inside of the LLVM source tree. This is
- because the test suite creates temporary files during execution.
- </p><p>
- The master Makefile in llvm/test is capable of running both the
- QMTest driven tests and the Programs tests. By default, it will run
- all of the tests.
- </p><p>
- To run only the QMTest driven tests, run <tt>gmake qmtest</tt> at the
- command line in llvm/tests. To run a specific qmtest, suffix the test
- name with ".t" when running gmake.
- </p><p>
- For example, to run the Regression.LLC tests, type
- <tt>gmake Regression.LLC.t</tt> in llvm/tests.
- </p><p>
- Note that the Makefiles in llvm/test/Features and llvm/test/Regression
- are gone. You must now use QMTest from the llvm/test directory to run
- them.
- </p><p>
- To run the Programs test, cd into the llvm/test/Programs directory and
- type <tt>gmake</tt>. Alternatively, you can type <tt>gmake
- TEST=<type> test</tt> to run one of the specialized tests in
- llvm/test/Programs/TEST.<type>.Makefile. For example, you could
- run the nightly tester tests using the following commands:
- </p>
-
- <pre>
- % cd llvm/test/Programs
- % gmake TEST=nightly test
- </pre>
-
- <p>
- Regardless of which test you're running, the results are printed on
- standard output and standard error. You can redirect these results to a
- file if you choose.
- </p><p>
- Some tests are known to fail. Some are bugs that we have not fixed yet;
- others are features that we haven't added yet (or may never add). In
- QMTest, the result for such tests will be XFAIL (eXpected FAILure). In
- this way, you can tell the difference between an expected and unexpected
- failure.
- </p><p>
- The Programs tests have no such feature as of this time. If the test
- passes, only warnings and other miscellaneous output will be generated.
- If a test fails, a large <program> FAILED message will be
- displayed. This will help you separate benign warnings from actual test
- failures.
- </p>
- </div>
+ </ul></li>
-<!-- *********************************************************************** -->
+ <li>QMTest
+ <p>This directory contains the QMTest information files. Inside this
+ directory are QMTest administration files and the Python code that
+ implements the LLVM test and database classes.</p>
+
+</ul>
+
+</div>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="qmstructure">QMTest Structure</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>The LLVM test suite is partially driven by QMTest and partially
+driven by GNU Make. Specifically, the Features and Regression tests
+are all driven by QMTest. The Programs directory is currently
+driven by a set of Makefiles.</p>
+
+<p>The QMTest system needs to have several pieces of information
+available; these pieces of configuration information are known
+collectively as the "context" in QMTest parlance. Since the context
+for LLVM is relatively large, the master Makefile in llvm/test
+sets it for you.</p>
+
+<p>The LLVM database class makes the subdirectories of llvm/test a
+QMTest test database. For each directory that contains tests driven by
+QMTest, it knows what type of test the source file is and how to run it.</p>
+
+<p>Hence, the QMTest namespace is essentially what you see in the
+Feature and Regression directories, but there is some magic that
+the database class performs (as described below).</p>
+
+<p>The QMTest namespace is currently composed of the following tests and test
+suites:</p>
+
+<ul>
+ <li>Feature
+ <p>
+ These are the feature tests found in the Feature directory.
+ They are broken up into the following categories:
+ </p>
+ <ul>
+ <li>ad
+ <p>Assembler/Disassembler tests. These tests verify that a piece of LLVM
+ assembly language can be assembled into bytecode and then disassembled
+ into the original assembly language code. It does this several times to
+ ensure that assembled output can be disassembled and disassembler output
+ can be assembled. It also verifies that the give assembly language file
+ can be assembled correctly.</p></li>
+
+ <li>opt
+ <p>Optimizer tests. These tests verify that two of the optimizer passes
+ completely optimize a program (i.e. after a single pass, they cannot
+ optimize a program any further).</p></li>
+
+ <li>mc
+ <p> Machine code tests. These tests verify that the LLVM assembly
+ language file can be translated into native assembly code.</p></li>
+
+ <li>cc
+ <p>C code tests. These tests verify that the specified LLVM assembly
+ code can be converted into C source code using the C backend.</p></li>
+ </ul>
+
+ <p>The LLVM database class looks at every file in the Feature directory and
+ creates a fake test hierarchy containing
+ <tt>Feature.<testtype>.<testname></tt>. So, if you add an LLVM
+ assembly language file to the Feature directory, it actually creates 5 new
+ tests: assembler/disassembler, assembler, optimizer, machine code, and C code.
+ </p>
+
+ <li>Regression
+ <p>These are the regression tests. There is one suite for each
+ subdirectory of the Regression directory. If you add a new subdirectory
+ there, you will need to modify, at least, the <tt>RegressionMap</tt>
+ variable in <tt>QMTest/llvmdb.py</tt> so that QMTest knows how to run the
+ tests in the new subdirectory.</p>
+
+</ul>
+
+</div>
+
+<!--===============================================================-->
+<div class="doc_section"><a name="progstructure">Programs Structure</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>As mentioned previously, the Programs tree in llvm/test provides three types
+of tests: MultiSource, SingleSource, and External. Each tree is then subdivided
+into several categories, including applications, benchmarks, regression tests,
+code that is strange grammatically, etc. These organizations should be
+relatively self explanatory.</p>
+
+<p>In addition to the regular Programs tests, the Programs tree also provides a
+mechanism for compiling the programs in different ways. If the variable TEST is
+defined on the gmake command line, the test system will include a Makefile named
+<tt>TEST.<value of TEST variable>.Makefile</tt>. This Makefile can modify
+build rules to yield different results.</p>
+
+<p>For example, the LLVM nightly tester uses <tt>TEST.nightly.Makefile</tt> to
+create the nightly test reports. To run the nightly tests, run <tt>gmake
+TEST=nightly</tt>.</p>
+
+<p>There are several TEST Makefiles available in the tree. Some of them are
+designed for internal LLVM research and will not work outside of the LLVM
+research group. They may still be valuable, however, as a guide to writing your
+own TEST Makefile for any optimization or analysis passes that you develop with
+LLVM.</p>
+
+</div>
-<hr><font size="-1">
-<address>John T. Criswell</address>
-<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a>
-<br>
-Last modified: $Date: 2003/11/03 14:59:59 $
-</font>
+<!--===============================================================-->
+<div class="doc_section"><a name="run">Running the LLVM Tests</a></div>
+<!--===============================================================-->
+
+<div class="doc_text">
+
+<p>First, all tests are executed within the LLVM object directory tree. They
+<i>are not</i> executed inside of the LLVM source tree. This is because the
+test suite creates temporary files during execution. </p>
+
+<p>The master Makefile in llvm/test is capable of running both the QMTest driven
+tests and the Programs tests. By default, it will run all of the tests.</p>
+
+<p>To run only the QMTest driven tests, run <tt>gmake qmtest</tt> at the
+command line in llvm/tests. To run a specific qmtest, suffix the test name with
+".t" when running gmake.</p>
+
+<p>For example, to run the Regression.LLC tests, type <tt>gmake
+Regression.LLC.t</tt> in llvm/tests.</p>
+
+<p>Note that the Makefiles in llvm/test/Features and llvm/test/Regression are
+gone. You must now use QMTest from the llvm/test directory to run them.</p>
+
+<p>To run the Programs test, cd into the llvm/test/Programs directory and type
+<tt>gmake</tt>. Alternatively, you can type <tt>gmake TEST=<type>
+test</tt> to run one of the specialized tests in
+llvm/test/Programs/TEST.<type>.Makefile. For example, you could run the
+nightly tester tests using the following commands:</p>
+
+<pre>
+ % cd llvm/test/Programs
+ % gmake TEST=nightly test
+</pre>
+
+<p>Regardless of which test you're running, the results are printed on standard
+output and standard error. You can redirect these results to a file if you
+choose.</p>
+
+<p>Some tests are known to fail. Some are bugs that we have not fixed yet;
+others are features that we haven't added yet (or may never add). In QMTest,
+the result for such tests will be XFAIL (eXpected FAILure). In this way, you
+can tell the difference between an expected and unexpected failure.</p>
+
+<p>The Programs tests have no such feature as of this time. If the test passes,
+only warnings and other miscellaneous output will be generated. If a test
+fails, a large <program> FAILED message will be displayed. This will help
+you separate benign warnings from actual test failures.</p>
+
+</div>
+
+<!-- *********************************************************************** -->
+<hr>
+<address>
+ <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
+ src="http://jigsaw.w3.org/css-validator/images/vcss" alt="Valid CSS!"></a>
+ <a href="http://validator.w3.org/check/referer"><img
+ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /></a>
+
+ John T. Criswell<br>
+ <a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
+ Last modified: $Date: 2004/03/01 23:56:01 $
+</address>
</body>
</html>
Index: llvm/docs/WritingAnLLVMPass.html
diff -u llvm/docs/WritingAnLLVMPass.html:1.22 llvm/docs/WritingAnLLVMPass.html:1.22.2.1
--- llvm/docs/WritingAnLLVMPass.html:1.22 Thu Jan 15 12:34:11 2004
+++ llvm/docs/WritingAnLLVMPass.html Mon Mar 1 17:56:01 2004
@@ -173,6 +173,11 @@
<tt>lib/Debug/libhello.so</tt> shared object that can be dynamically loaded by
the <tt>opt</tt> or <tt>analyze</tt> tools.</p>
+<p>
+Note that the suffix of the shared library may differ from the example above if
+your system uses a different suffix by default.
+</p>
+
<p>Now that we have the build scripts set up, we just need to write the code for
the pass itself.</p>
@@ -282,7 +287,7 @@
<div class="doc_text">
-<p>Now that you have a brand new shiny <tt>.so</tt> file, we can use the
+<p>Now that you have a brand new shiny shared object file, we can use the
<tt>opt</tt> command to run an LLVM program through your pass. Because you
registered your pass with the <tt>RegisterOpt</tt> template, you will be able to
use the <tt>opt</tt> tool to access it, once loaded.</p>
@@ -1421,7 +1426,7 @@
<a href="mailto:sabre at nondot.org">Chris Lattner</a><br>
<a href="http://llvm.cs.uiuc.edu">The LLVM Compiler Infrastructure</a><br>
- Last modified: $Date: 2004/01/15 18:34:11 $
+ Last modified: $Date: 2004/03/01 23:56:01 $
</address>
</body>
Index: llvm/docs/index.html
diff -u llvm/docs/index.html:1.6 llvm/docs/index.html:1.6.4.1
--- llvm/docs/index.html:1.6 Mon Nov 24 21:32:57 2003
+++ llvm/docs/index.html Mon Mar 1 17:56:01 2004
@@ -120,11 +120,11 @@
<dl compact>
<dt>
- LLVM : A Compilation Framework for Lifelong Program Analysis
- and Transformation:
+ LLVM: A Compilation Framework for Lifelong Program Analysis
+ & Transformation
<dd>
- <a href="http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html">
- http://llvm.cs.uiuc.edu/pubs/2003-09-30-LifelongOptimizationTR.html </a>
+ <a href="http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html">
+ http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html </a>
</dl>
@@ -181,6 +181,20 @@
<dd>
<a href="AliasAnalysis.html"> llvm/docs/AliasAnalysis.html</a>
<p>
+
+ <dt>
+ Source Level Debugging with LLVM:
+ <dd>
+ <a href="SourceLevelDebugging.html"> llvm/docs/SourceLevelDebugging.html</a>
+ <p>
+
+
+ <dt>
+ TableGen Fundamentals:
+ <dd>
+ <a href="TableGenFundamentals.html"> llvm/docs/TableGenFundamentals.html</a>
+ <p>
+
<dt>
The Stacker Cronicles
More information about the llvm-commits
mailing list