From 6b943ff3a3f8617113ecbf611cf0f8957e4e19d2 Mon Sep 17 00:00:00 2001 From: Dimitry Andric Date: Mon, 2 May 2011 19:34:44 +0000 Subject: Vendor import of llvm trunk r130700: http://llvm.org/svn/llvm-project/llvm/trunk@130700 --- docs/AliasAnalysis.html | 307 ++--- docs/BitCodeFormat.html | 401 +++--- docs/Bugpoint.html | 54 +- docs/CFEBuildInstrs.html | 2 +- docs/CMake.html | 170 ++- docs/CodeGenerator.html | 528 ++++---- docs/CodingStandards.html | 258 ++-- docs/CommandGuide/FileCheck.pod | 2 +- docs/CommandGuide/bugpoint.pod | 21 +- docs/CommandGuide/index.html | 36 +- docs/CommandGuide/lit.pod | 2 +- docs/CommandGuide/llc.pod | 2 +- docs/CommandGuide/lli.pod | 2 +- docs/CommandGuide/llvm-ar.pod | 2 +- docs/CommandGuide/llvm-as.pod | 2 +- docs/CommandGuide/llvm-bcanalyzer.pod | 4 +- docs/CommandGuide/llvm-config.pod | 2 +- docs/CommandGuide/llvm-diff.pod | 2 +- docs/CommandGuide/llvm-dis.pod | 2 +- docs/CommandGuide/llvm-extract.pod | 2 +- docs/CommandGuide/llvm-ld.pod | 2 +- docs/CommandGuide/llvm-link.pod | 2 +- docs/CommandGuide/llvm-nm.pod | 2 +- docs/CommandGuide/llvm-prof.pod | 2 +- docs/CommandGuide/llvm-ranlib.pod | 2 +- docs/CommandGuide/llvmc.pod | 2 +- docs/CommandGuide/llvmgcc.pod | 2 +- docs/CommandGuide/llvmgxx.pod | 2 +- docs/CommandGuide/opt.pod | 2 +- docs/CommandGuide/tblgen.pod | 2 +- docs/CommandLine.html | 263 ++-- docs/CompilerDriver.html | 771 +++++------ docs/CompilerDriverTutorial.html | 107 +- docs/CompilerWriterInfo.html | 86 +- docs/DebuggingJITedCode.html | 14 +- docs/DeveloperPolicy.html | 81 +- docs/ExceptionHandling.html | 160 +-- docs/ExtendingLLVM.html | 54 +- docs/FAQ.html | 34 +- docs/GCCFEBuildInstrs.html | 26 +- docs/GarbageCollection.html | 151 ++- docs/GetElementPtr.html | 232 ++-- docs/GettingStarted.html | 284 ++-- docs/GettingStartedVS.html | 72 +- docs/GoldPlugin.html | 41 +- .../2000-11-18-EarlyDesignIdeasResp.txt | 4 +- docs/HistoricalNotes/2000-12-06-MeetingSummary.txt | 2 +- .../2001-02-06-TypeNotationDebateResp4.txt | 2 +- .../2001-02-09-AdveCommentsResponse.txt | 6 +- .../2001-06-01-GCCOptimizations2.txt | 2 +- docs/HistoricalNotes/2002-05-12-InstListChange.txt | 2 +- docs/HowToReleaseLLVM.html | 814 +++++++----- docs/HowToSubmitABug.html | 54 +- docs/LangRef.html | 1380 +++++++++++--------- docs/Lexicon.html | 67 +- docs/LinkTimeOptimization.html | 89 +- docs/MakefileGuide.html | 183 +-- docs/Packaging.html | 26 +- docs/Passes.html | 1131 +++++++--------- docs/ProgrammersManual.html | 844 ++++++------ docs/Projects.html | 74 +- docs/ReleaseNotes.html | 1342 ++++++++----------- docs/SourceLevelDebugging.html | 321 ++--- docs/SystemLibrary.html | 84 +- docs/TableGenFundamentals.html | 119 +- docs/TestingGuide.html | 166 +-- docs/UsingLibraries.html | 64 +- docs/WritingAnLLVMBackend.html | 221 ++-- docs/WritingAnLLVMPass.html | 480 +++---- docs/doxygen.css | 30 + docs/doxygen.footer | 2 +- docs/index.html | 22 +- docs/llvm.css | 16 +- docs/tutorial/LangImpl1.html | 18 +- docs/tutorial/LangImpl2.html | 44 +- docs/tutorial/LangImpl3.html | 31 +- docs/tutorial/LangImpl4.html | 30 +- docs/tutorial/LangImpl5.html | 91 +- docs/tutorial/LangImpl6.html | 36 +- docs/tutorial/LangImpl7.html | 43 +- docs/tutorial/LangImpl8.html | 52 +- docs/tutorial/OCamlLangImpl1.html | 18 +- docs/tutorial/OCamlLangImpl2.html | 44 +- docs/tutorial/OCamlLangImpl3.html | 31 +- docs/tutorial/OCamlLangImpl4.html | 28 +- docs/tutorial/OCamlLangImpl5.html | 79 +- docs/tutorial/OCamlLangImpl6.html | 30 +- docs/tutorial/OCamlLangImpl7.html | 43 +- docs/tutorial/OCamlLangImpl8.html | 50 +- docs/tutorial/index.html | 2 +- 90 files changed, 6232 insertions(+), 6182 deletions(-) (limited to 'docs') diff --git a/docs/AliasAnalysis.html b/docs/AliasAnalysis.html index 20b7e96460f3..b93cff07bc4d 100644 --- a/docs/AliasAnalysis.html +++ b/docs/AliasAnalysis.html @@ -7,9 +7,9 @@ -
+

LLVM Alias Analysis Infrastructure -

+
  1. Introduction
    2. @@ -59,12 +59,12 @@ -
    +

    Introduction -

    + -
    +

    Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt to determine whether or not two pointers ever can point to the same object in @@ -96,12 +96,12 @@ know.

    -
    +

    AliasAnalysis Class Overview -

    + -
    +

    The AliasAnalysis @@ -122,14 +122,12 @@ multiple values, values which are not constants are all defined within the same function.

    -
    - -
    +

    Representation of Pointers -

    + -
    +

    Most importantly, the AliasAnalysis class provides several methods which are used to query whether or not two memory objects alias, whether @@ -181,11 +179,11 @@ that the accesses alias.

    -
    +

    The alias method -

    + -
    +

    The alias method is the primary interface used to determine whether or not two memory objects alias each other. It takes two memory objects as input and returns MustAlias, PartialAlias, MayAlias, or NoAlias as @@ -194,14 +192,13 @@ appropriate.

    Like all AliasAnalysis interfaces, the alias method requires that either the two pointer values be defined within the same function, or at least one of the values is a constant.

    -
    -
    +

    Must, May, and No Alias Responses -

    + -
    +

    The NoAlias response may be used when there is never an immediate dependence between any memory reference based on one pointer and any memory reference based the other. The most obvious example is when the two @@ -227,12 +224,14 @@ implies that the pointers compare equal.

    +
    + -
    +

    The getModRefInfo methods -

    + -
    +

    The getModRefInfo methods return information about whether the execution of an instruction can read or modify a memory location. Mod/Ref @@ -250,25 +249,23 @@ memory written to by CS2. Note that this relation is not commutative.

    -
    +

    Other useful AliasAnalysis methods -

    + -
    +

    Several other tidbits of information are often collected by various alias analysis implementations and can be put to good use by various clients.

    -
    - -
    +

    The pointsToConstantMemory method -

    + -
    +

    The pointsToConstantMemory method returns true if and only if the analysis can prove that the pointer only points to unchanging memory locations @@ -279,12 +276,12 @@ memory location to be modified.

    -
    +

    The doesNotAccessMemory and onlyReadsMemory methods -

    + -
    +

    These methods are used to provide very simple mod/ref information for function calls. The doesNotAccessMemory method returns true for a @@ -307,13 +304,17 @@ functions that satisfy the doesNotAccessMemory method also satisfies

    +
    + +
    + -
    +

    Writing a new AliasAnalysis Implementation -

    + -
    +

    Writing a new alias analysis implementation for LLVM is quite straight-forward. There are already several implementations that you can use @@ -321,14 +322,12 @@ for examples, and the following information should help fill in any details. For a examples, take a look at the various alias analysis implementations included with LLVM.

    -
    - -
    +

    Different Pass styles -

    + -
    +

    The first step to determining what type of LLVM pass you need to use for your Alias @@ -352,11 +351,11 @@ solve:

    -
    +

    Required initialization calls -

    + -
    +

    Your subclass of AliasAnalysis is required to invoke two methods on the AliasAnalysis base class: getAnalysisUsage and @@ -393,11 +392,11 @@ bool run(Module &M) {

    -
    +

    Interfaces which may be specified -

    + -
    +

    All of the AliasAnalysis @@ -412,11 +411,11 @@ implementing, you just override the interfaces you can improve.

    -
    +

    AliasAnalysis chaining behavior -

    + -
    +

    With only two special exceptions (the basicaa and no-aa @@ -451,11 +450,11 @@ updated.

    -
    +

    Updating analysis results for transformations -

    + -
    +

    Alias analysis information is initially computed for a static snapshot of the program, but clients will use this information to make transformations to the @@ -471,12 +470,11 @@ their internal data structures are kept up-to-date as the program changes (for example, when an instruction is deleted), and clients of alias analysis must be sure to call these interfaces appropriately.

    -
    -
    The deleteValue method
    +

    The deleteValue method

    -
    +
    The deleteValue method is called by transformations when they remove an instruction or any other value from the program (including values that do not use pointers). Typically alias analyses keep data structures that have entries @@ -485,9 +483,9 @@ any entries for the specified value, if they exist.
    -
    The copyValue method
    +

    The copyValue method

    -
    +
    The copyValue method is used when a new value is introduced into the program. There is no way to introduce a value into the program that did not exist before (this doesn't make sense for a safe compiler transformation), so @@ -496,9 +494,9 @@ new value has exactly the same properties as the value being copied.
    -
    The replaceWithNewValue method
    +

    The replaceWithNewValue method

    -
    +
    This method is a simple helper method that is provided to make clients easier to use. It is implemented by copying the old analysis information to the new value, then deleting the old value. This method cannot be overridden by alias @@ -506,9 +504,9 @@ analysis implementations.
    -
    The addEscapingUse method
    +

    The addEscapingUse method

    -
    +

    The addEscapingUse method is used when the uses of a pointer value have changed in ways that may invalidate precomputed analysis information. Implementations may either use this callback to provide conservative responses @@ -527,12 +525,14 @@ uses below:

    +
    + -
    +

    Efficiency Issues -

    + -
    +

    From the LLVM perspective, the only thing you need to do to provide an efficient alias analysis is to make sure that alias analysis queries are @@ -544,11 +544,11 @@ method as possible (within reason).

    -
    +

    Limitations -

    + -
    +

    The AliasAnalysis infrastructure has several limitations which make writing a new AliasAnalysis implementation difficult.

    @@ -567,7 +567,7 @@ which are intended to allow a pass to keep an AliasAnalysis consistent, however there's no way for a pass to declare in its getAnalysisUsage that it does so. Some passes attempt to use AU.addPreserved<AliasAnalysis>, however this doesn't -actually have any effect. +actually have any effect.

    AliasAnalysisCounter (-count-aa) and AliasDebugger (-debug-aa) are implemented as ModulePass classes, so if your @@ -616,25 +616,25 @@ from itself.

    +
    + -
    +

    Using alias analysis results -

    + -
    +

    There are several different ways to use alias analysis results. In order of preference, these are...

    -
    - -
    +

    Using the MemoryDependenceAnalysis Pass -

    + -
    +

    The memdep pass uses alias analysis to provide high-level dependence information about memory-using instructions. This will tell you which store @@ -645,11 +645,11 @@ efficient, and is used by Dead Store Elimination, GVN, and memcpy optimizations.

    -
    +

    Using the AliasSetTracker class -

    + -
    +

    Many transformations need information about alias sets that are active in some scope, rather than information about pairwise aliasing. The -

    - -
    +

    The AliasSetTracker implementation -

    + -
    +

    The AliasSetTracker class is implemented to be as efficient as possible. It uses the union-find algorithm to efficiently merge AliasSets when a pointer is @@ -706,12 +704,14 @@ are.

    +
    + -
    +

    Using the AliasAnalysis interface directly -

    + -
    +

    If neither of these utility class are what your pass needs, you should use the interfaces exposed by the AliasAnalysis class directly. Try to use @@ -721,13 +721,15 @@ best precision and efficiency.

    +
    + -
    +

    Existing alias analysis implementations and clients -

    + -
    +

    If you're going to be working with the LLVM alias analysis infrastructure, you should know what clients and implementations of alias analysis are @@ -735,28 +737,24 @@ available. In particular, if you are implementing an alias analysis, you should be aware of the the clients that are useful for monitoring and evaluating different implementations.

    -
    - -
    +

    Available AliasAnalysis implementations -

    + -
    +

    This section lists the various implementations of the AliasAnalysis interface. With the exception of the -no-aa and -basicaa implementations, all of these chain to other alias analysis implementations.

    -
    - -
    +

    The -no-aa pass -

    + -
    +

    The -no-aa pass is just like what it sounds: an alias analysis that never returns any useful information. This pass can be useful if you think that @@ -766,11 +764,11 @@ problem.

    -
    +

    The -basicaa pass -

    + -
    +

    The -basicaa pass is an aggressive local analysis that "knows" many important facts:

    @@ -794,11 +792,11 @@ many important facts:

    -
    +

    The -globalsmodref-aa pass -

    + -
    +

    This pass implements a simple context-sensitive mod/ref and alias analysis for internal global variables that don't "have their address taken". If a @@ -818,11 +816,11 @@ non-address taken globals), but is very quick analysis.

    -
    +

    The -steens-aa pass -

    + -
    +

    The -steens-aa pass implements a variation on the well-known "Steensgaard's algorithm" for interprocedural alias analysis. Steensgaard's @@ -841,11 +839,11 @@ module, it is not part of the LLVM core.

    -
    +

    The -ds-aa pass -

    + -
    +

    The -ds-aa pass implements the full Data Structure Analysis algorithm. Data Structure Analysis is a modular unification-based, @@ -864,11 +862,11 @@ module, it is not part of the LLVM core.

    -
    +

    The -scev-aa pass -

    + -
    +

    The -scev-aa pass implements AliasAnalysis queries by translating them into ScalarEvolution queries. This gives it a @@ -877,22 +875,23 @@ and loop induction variables than other alias analyses have.

    +
    + -
    +

    Alias analysis driven transformations -

    + -
    +
    LLVM includes several alias-analysis driven transformations which can be used with any of the implementations above. -
    -
    +

    The -adce pass -

    + -
    +

    The -adce pass, which implements Aggressive Dead Code Elimination uses the AliasAnalysis interface to delete calls to functions that do @@ -902,11 +901,11 @@ not have side-effects and are not used.

    -
    +

    The -licm pass -

    + -
    +

    The -licm pass implements various Loop Invariant Code Motion related transformations. It uses the AliasAnalysis interface for several @@ -927,11 +926,11 @@ no may aliases to the loaded/stored memory location.

    -
    +

    The -argpromotion pass -

    + -
    +

    The -argpromotion pass promotes by-reference arguments to be passed in by-value instead. In particular, if pointer arguments are only loaded from it @@ -942,38 +941,38 @@ pointer.

    -
    +

    The -gvn, -memcpyopt, and -dse passes -

    + -
    +

    These passes use AliasAnalysis information to reason about loads and stores.

    +
    + -
    +

    Clients for debugging and evaluation of implementations -

    + -
    +

    These passes are useful for evaluating the various alias analysis implementations. You can use them with commands like 'opt -ds-aa -aa-eval foo.bc -disable-output -stats'.

    -
    - -
    +

    The -print-alias-sets pass -

    + -
    +

    The -print-alias-sets pass is exposed as part of the opt tool to print out the Alias Sets formed by the AliasSetTracker class. To use it, use something like:

    -
    +

    The -count-aa pass -

    + -
    +

    The -count-aa pass is useful to see how many queries a particular pass is making and what responses are returned by the alias analysis. As an @@ -1014,11 +1013,11 @@ when debugging a transformation or an alias analysis implementation.

    -
    +

    The -aa-eval pass -

    + -
    +

    The -aa-eval pass simply iterates through all pairs of pointers in a function and asks an alias analysis whether or not the pointers alias. This @@ -1028,13 +1027,17 @@ algorithm will have a lower number of may aliases).

    +
    + +
    + -
    +

    Memory Dependence Analysis -

    + -
    +

    If you're just looking to be a client of alias analysis information, consider using the Memory Dependence Analysis interface instead. MemDep is a lazy, @@ -1056,8 +1059,8 @@ analysis directly.

    src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
    - LLVM Compiler Infrastructure
    - Last modified: $Date: 2011-01-03 22:38:41 +0100 (Mon, 03 Jan 2011) $ + LLVM Compiler Infrastructure
    + Last modified: $Date: 2011-04-21 03:52:00 +0200 (Thu, 21 Apr 2011) $ diff --git a/docs/BitCodeFormat.html b/docs/BitCodeFormat.html index 8d3d382da7a9..9a042a0dbaa8 100644 --- a/docs/BitCodeFormat.html +++ b/docs/BitCodeFormat.html @@ -7,7 +7,7 @@ -
    LLVM Bitcode File Format
    +

    LLVM Bitcode File Format

    1. Abstract
    2. Overview
      3. @@ -47,10 +47,10 @@
    -
    Abstract
    +

    Abstract

    -
    +

    This document describes the LLVM bitstream file format and the encoding of the LLVM IR into it.

    @@ -58,10 +58,10 @@ the LLVM IR into it.

    -
    Overview
    +

    Overview

    -
    +

    What is commonly known as the LLVM bitcode file format (also, sometimes @@ -88,10 +88,10 @@ wrapper format, then describes the record structure used by LLVM IR files.

    -
    Bitstream Format
    +

    Bitstream Format

    -
    +

    The bitstream format is literally a stream of bits, with a very simple @@ -114,13 +114,12 @@ href="CommandGuide/html/llvm-bcanalyzer.html">llvm-bcanalyzer tool can be used to dump and inspect arbitrary bitstreams, which is very useful for understanding the encoding.

    -
    - -
    Magic Numbers -
    +

    + Magic Numbers +

    -
    +

    The first two bytes of a bitcode file are 'BC' (0x42, 0x43). The second two bytes are an application-specific magic number. Generic @@ -130,10 +129,11 @@ bitcode, while application-specific programs will want to look at all four.

    -
    Primitives -
    +

    + Primitives +

    -
    +

    A bitstream literally consists of a stream of bits, which are read in order @@ -144,13 +144,12 @@ Width Integers or as Variable Width Integers.

    -
    - -
    Fixed Width Integers -
    +

    + Fixed Width Integers +

    -
    +

    Fixed-width integer values have their low bits emitted directly to the file. For example, a 3-bit integer value encodes 1 as 001. Fixed width integers @@ -161,10 +160,11 @@ Integers.

    -
    Variable Width -Integers
    +

    + Variable Width Integers +

    -
    +

    Variable-width integer (VBR) values encode values of arbitrary size, optimizing for the case where the values are small. Given a 4-bit VBR field, @@ -182,9 +182,9 @@ value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value

    -
    6-bit characters
    +

    6-bit characters

    -
    +

    6-bit characters encode common characters into a fixed 6-bit field. They represent the following characters with the following 6-bit values:

    @@ -206,9 +206,9 @@ characters not in the set.

    -
    Word Alignment
    +

    Word Alignment

    -
    +

    Occasionally, it is useful to emit zero bits until the bitstream is a multiple of 32 bits. This ensures that the bit position in the stream can be @@ -216,12 +216,14 @@ represented as a multiple of 32-bit words.

    +
    -
    Abbreviation IDs -
    +

    + Abbreviation IDs +

    -
    +

    A bitstream is a sequential series of Blocks and @@ -253,10 +255,11 @@ an abbreviated record encoding.

    -
    Blocks -
    +

    + Blocks +

    -
    +

    Blocks in a bitstream denote nested regions of the stream, and are identified by @@ -297,13 +300,10 @@ its own set of abbreviations, and its own abbrev id width. When a sub-block is popped, the saved values are restored.

    -
    - -
    ENTER_SUBBLOCK -Encoding
    +

    ENTER_SUBBLOCK Encoding

    -
    +

    [ENTER_SUBBLOCK, blockidvbr8, newabbrevlenvbr4, <align32bits>, blocklen32]

    @@ -322,10 +322,9 @@ reader to skip over the entire block in one jump.
    -
    END_BLOCK -Encoding
    +

    END_BLOCK Encoding

    -
    +

    [END_BLOCK, <align32bits>]

    @@ -337,13 +336,14 @@ an even multiple of 32-bits.
    - +
    -
    Data Records -
    +

    + Data Records +

    -
    +

    Data records consist of a record code and a number of (up to) 64-bit integer values. The interpretation of the code and values is @@ -355,13 +355,10 @@ which encodes the target triple of a module. The code is ASCII codes for the characters in the string.

    -
    - -
    UNABBREV_RECORD -Encoding
    +

    UNABBREV_RECORD Encoding

    -
    +

    [UNABBREV_RECORD, codevbr6, numopsvbr6, op0vbr6, op1vbr6, ...]

    @@ -385,10 +382,9 @@ bits. This is not an efficient encoding, but it is fully general.
    -
    Abbreviated Record -Encoding
    +

    Abbreviated Record Encoding

    -
    +

    [<abbrevid>, fields...]

    @@ -409,11 +405,14 @@ operand value).

    - -
    Abbreviations
    -
    + +

    + Abbreviations +

    + +

    Abbreviations are an important form of compression for bitstreams. The idea is to specify a dense encoding for a class of records once, then use that encoding @@ -431,13 +430,11 @@ As a concrete example, LLVM IR files usually emit an abbreviation for binary operators. If a specific LLVM module contained no or few binary operators, the abbreviation does not need to be emitted.

    -
    -
    DEFINE_ABBREV - Encoding
    +

    DEFINE_ABBREV Encoding

    -
    +

    [DEFINE_ABBREV, numabbrevopsvbr5, abbrevop0, abbrevop1, ...]

    @@ -552,11 +549,14 @@ used for any other string value.
    - -
    Standard Blocks
    -
    + +

    + Standard Blocks +

    + +

    In addition to the basic block structure and record encodings, the bitstream @@ -565,13 +565,10 @@ stream is to be decoded or other metadata. In the future, new standard blocks may be added. Block IDs 0-7 are reserved for standard blocks.

    -
    - -
    #0 - BLOCKINFO -Block
    +

    #0 - BLOCKINFO Block

    -
    +

    The BLOCKINFO block allows the description of metadata for other @@ -620,11 +617,15 @@ from the corresponding blocks. It is not safe to skip them.

    +
    + +
    + -
    Bitcode Wrapper Format
    +

    Bitcode Wrapper Format

    -
    +

    Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper @@ -652,10 +653,10 @@ value that can be used to encode the CPU of the target.

    -
    LLVM IR Encoding
    +

    LLVM IR Encoding

    -
    +

    LLVM IR is encoded into a bitstream by defining blocks and records. It uses @@ -666,16 +667,17 @@ that the writer uses, as these are fully self-described in the file, and the reader is not allowed to build in any knowledge of this.

    -
    - -
    Basics -
    +

    + Basics +

    + +
    -
    LLVM IR Magic Number
    +

    LLVM IR Magic Number

    -
    +

    The magic number for LLVM IR files is: @@ -695,9 +697,9 @@ When combined with the bitcode magic number and viewed as bytes, this is

    -
    Signed VBRs
    +

    Signed VBRs

    -
    +

    Variable Width Integer encoding is an efficient way to @@ -728,9 +730,9 @@ within CONSTANTS_BLOCK blocks. -

    LLVM IR Blocks
    +

    LLVM IR Blocks

    -
    +

    LLVM IR is defined with the following blocks: @@ -758,11 +760,14 @@ LLVM IR is defined with the following blocks:

    - -
    MODULE_BLOCK Contents
    -
    + +

    + MODULE_BLOCK Contents +

    + +

    The MODULE_BLOCK block (id 8) is the top-level block for LLVM bitcode files, and each bitcode file must contain exactly one. In @@ -782,13 +787,10 @@ following sub-blocks:

  2. METADATA_BLOCK
    3. -
    - -
    MODULE_CODE_VERSION Record -
    +

    MODULE_CODE_VERSION Record

    -
    +

    [VERSION, version#]

    @@ -798,10 +800,9 @@ time.

    -
    MODULE_CODE_TRIPLE Record -
    +

    MODULE_CODE_TRIPLE Record

    -
    +

    [TRIPLE, ...string...]

    The TRIPLE record (code 2) contains a variable number of @@ -810,10 +811,9 @@ specification string.

    -
    MODULE_CODE_DATALAYOUT Record -
    +

    MODULE_CODE_DATALAYOUT Record

    -
    +

    [DATALAYOUT, ...string...]

    The DATALAYOUT record (code 3) contains a variable number of @@ -822,10 +822,9 @@ specification string.

    -
    MODULE_CODE_ASM Record -
    +

    MODULE_CODE_ASM Record

    -
    +

    [ASM, ...string...]

    The ASM record (code 4) contains a variable number of @@ -834,10 +833,9 @@ individual assembly blocks separated by newline (ASCII 10) characters.

    -
    MODULE_CODE_SECTIONNAME Record -
    +

    MODULE_CODE_SECTIONNAME Record

    -
    +

    [SECTIONNAME, ...string...]

    The SECTIONNAME record (code 5) contains a variable number @@ -850,10 +848,9 @@ referenced by the 1-based index in the section fields of

    -
    MODULE_CODE_DEPLIB Record -
    +

    MODULE_CODE_DEPLIB Record

    -
    +

    [DEPLIB, ...string...]

    The DEPLIB record (code 6) contains a variable number of @@ -864,10 +861,9 @@ library name referenced.

    -
    MODULE_CODE_GLOBALVAR Record -
    +

    MODULE_CODE_GLOBALVAR Record

    -
    +

    [GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal]

    The GLOBALVAR record (code 7) marks the declaration or @@ -923,16 +919,15 @@ encoding of the visibility of this variable: is thread_local

  3. unnamed_addr: If present and non-zero, indicates that the variable -has unnamed_addr
    4. +has unnamed_addr
    -
    MODULE_CODE_FUNCTION Record -
    +

    MODULE_CODE_FUNCTION Record

    -
    +

    [FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]

    @@ -980,16 +975,15 @@ index in the table of MODULE_CODE_GCNAME entries.
  4. unnamed_addr: If present and non-zero, indicates that the function -has unnamed_addr
    5. +has unnamed_addr
    -
    MODULE_CODE_ALIAS Record -
    +

    MODULE_CODE_ALIAS Record

    -
    +

    [ALIAS, alias type, aliasee val#, linkage, visibility]

    @@ -1011,10 +1005,9 @@ for this alias
    -
    MODULE_CODE_PURGEVALS Record -
    +

    MODULE_CODE_PURGEVALS Record

    -
    +

    [PURGEVALS, numvals]

    The PURGEVALS record (code 10) resets the module-level @@ -1025,10 +1018,9 @@ new value indices will start from the given numvals value.

    -
    MODULE_CODE_GCNAME Record -
    +

    MODULE_CODE_GCNAME Record

    -
    +

    [GCNAME, ...string...]

    The GCNAME record (code 11) contains a variable number of @@ -1039,11 +1031,14 @@ the module. These records can be referenced by 1-based index in the gc fields of FUNCTION records.

    - -
    PARAMATTR_BLOCK Contents
    -
    + +

    + PARAMATTR_BLOCK Contents +

    + +

    The PARAMATTR_BLOCK block (id 9) contains a table of entries describing the attributes of function parameters. These @@ -1057,14 +1052,10 @@ href="#FUNC_CODE_INST_CALL">INST_CALL records.

    that each is unique (i.e., no two indicies represent equivalent attribute lists).

    -
    - - -
    PARAMATTR_CODE_ENTRY Record -
    +

    PARAMATTR_CODE_ENTRY Record

    -
    +

    [ENTRY, paramidx0, attr0, paramidx1, attr1...]

    @@ -1105,11 +1096,14 @@ the logarithm base 2 of the requested alignment, plus 1
    - -
    TYPE_BLOCK Contents
    -
    + +

    + TYPE_BLOCK Contents +

    + +

    The TYPE_BLOCK block (id 10) contains records which constitute a table of type operator entries used to represent types @@ -1124,13 +1118,10 @@ type operator records. each entry is unique (i.e., no two indicies represent structurally equivalent types).

    -
    - -
    TYPE_CODE_NUMENTRY Record -
    +

    TYPE_CODE_NUMENTRY Record

    -
    +

    [NUMENTRY, numentries]

    @@ -1142,10 +1133,9 @@ in the block.
    -
    TYPE_CODE_VOID Record -
    +

    TYPE_CODE_VOID Record

    -
    +

    [VOID]

    @@ -1155,10 +1145,9 @@ type table.
    -
    TYPE_CODE_FLOAT Record -
    +

    TYPE_CODE_FLOAT Record

    -
    +

    [FLOAT]

    @@ -1168,10 +1157,9 @@ floating point) type to the type table.
    -
    TYPE_CODE_DOUBLE Record -
    +

    TYPE_CODE_DOUBLE Record

    -
    +

    [DOUBLE]

    @@ -1181,10 +1169,9 @@ floating point) type to the type table.
    -
    TYPE_CODE_LABEL Record -
    +

    TYPE_CODE_LABEL Record

    -
    +

    [LABEL]

    @@ -1194,10 +1181,9 @@ the type table.
    -
    TYPE_CODE_OPAQUE Record -
    +

    TYPE_CODE_OPAQUE Record

    -
    +

    [OPAQUE]

    @@ -1208,10 +1194,9 @@ unified.
    -
    TYPE_CODE_INTEGER Record -
    +

    TYPE_CODE_INTEGER Record

    -
    +

    [INTEGER, width]

    @@ -1222,10 +1207,9 @@ integer type.
    -
    TYPE_CODE_POINTER Record -
    +

    TYPE_CODE_POINTER Record

    -
    +

    [POINTER, pointee type, address space]

    @@ -1243,10 +1227,9 @@ default address space is zero.
    -
    TYPE_CODE_FUNCTION Record -
    +

    TYPE_CODE_FUNCTION Record

    -
    +

    [FUNCTION, vararg, ignored, retty, ...paramty... ]

    @@ -1268,10 +1251,9 @@ parameter types of the function
    -
    TYPE_CODE_STRUCT Record -
    +

    TYPE_CODE_STRUCT Record

    -
    +

    [STRUCT, ispacked, ...eltty...]

    @@ -1287,10 +1269,9 @@ types of the structure
    -
    TYPE_CODE_ARRAY Record -
    +

    TYPE_CODE_ARRAY Record

    -
    +

    [ARRAY, numelts, eltty]

    @@ -1305,10 +1286,9 @@ table. The operand fields are

    -
    TYPE_CODE_VECTOR Record -
    +

    TYPE_CODE_VECTOR Record

    -
    +

    [VECTOR, numelts, eltty]

    @@ -1323,10 +1303,9 @@ table. The operand fields are

    -
    TYPE_CODE_X86_FP80 Record -
    +

    TYPE_CODE_X86_FP80 Record

    -
    +

    [X86_FP80]

    @@ -1336,10 +1315,9 @@ floating point) type to the type table.
    -
    TYPE_CODE_FP128 Record -
    +

    TYPE_CODE_FP128 Record

    -
    +

    [FP128]

    @@ -1349,10 +1327,9 @@ floating point) type to the type table.
    -
    TYPE_CODE_PPC_FP128 Record -
    +

    TYPE_CODE_PPC_FP128 Record

    -
    +

    [PPC_FP128]

    @@ -1362,10 +1339,9 @@ floating point) type to the type table.
    -
    TYPE_CODE_METADATA Record -
    +

    TYPE_CODE_METADATA Record

    -
    +

    [METADATA]

    @@ -1374,11 +1350,14 @@ type to the type table.

    - -
    CONSTANTS_BLOCK Contents
    -
    + +

    + CONSTANTS_BLOCK Contents +

    + +

    The CONSTANTS_BLOCK block (id 11) ...

    @@ -1387,10 +1366,11 @@ type to the type table. -
    FUNCTION_BLOCK Contents -
    +

    + FUNCTION_BLOCK Contents +

    -
    +

    The FUNCTION_BLOCK block (id 12) ...

    @@ -1409,23 +1389,21 @@ type to the type table. -
    TYPE_SYMTAB_BLOCK Contents -
    +

    + TYPE_SYMTAB_BLOCK Contents +

    -
    +

    The TYPE_SYMTAB_BLOCK block (id 13) contains entries which map between module-level named types and their corresponding type indices.

    -
    - -
    TST_CODE_ENTRY Record -
    +

    TST_CODE_ENTRY Record

    -
    +

    [ENTRY, typeid, ...string...]

    @@ -1436,12 +1414,14 @@ name. Each entry corresponds to a single named type.

    +
    -
    VALUE_SYMTAB_BLOCK Contents -
    +

    + VALUE_SYMTAB_BLOCK Contents +

    -
    +

    The VALUE_SYMTAB_BLOCK block (id 14) ...

    @@ -1450,10 +1430,11 @@ name. Each entry corresponds to a single named type. -
    METADATA_BLOCK Contents -
    +

    + METADATA_BLOCK Contents +

    -
    +

    The METADATA_BLOCK block (id 15) ...

    @@ -1462,16 +1443,18 @@ name. Each entry corresponds to a single named type. -
    METADATA_ATTACHMENT Contents -
    +

    + METADATA_ATTACHMENT Contents +

    -
    +

    The METADATA_ATTACHMENT block (id 16) ...

    +
    @@ -1480,8 +1463,8 @@ name. Each entry corresponds to a single named type. Valid HTML 4.01 Chris Lattner
    -The LLVM Compiler Infrastructure
    -Last modified: $Date: 2011-01-08 17:42:36 +0100 (Sat, 08 Jan 2011) $ +The LLVM Compiler Infrastructure
    +Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html index cbd71aab91a7..05c867bcb08c 100644 --- a/docs/Bugpoint.html +++ b/docs/Bugpoint.html @@ -6,9 +6,9 @@ -
    +

    LLVM bugpoint tool: design and usage -

    +
    -
    +

    Description -

    + -
    +

    bugpoint narrows down the source of problems in LLVM tools and passes. It can be used to debug three types of failures: optimizer crashes, @@ -50,12 +50,12 @@ href="HowToSubmitABug.html">How To Submit a Bug Report document.

    -
    +

    Design Philosophy -

    + -
    +

    bugpoint is designed to be a useful tool without requiring any hooks into the LLVM infrastructure at all. It works with any and all LLVM @@ -68,14 +68,12 @@ is still worth it. Note that bugpoint is generally very quick unless debugging a miscompilation where each test of the program (which requires executing it) takes a long time.

    -
    - -
    +

    Automatic Debugger Selection -

    + -
    +

    bugpoint reads each .bc or .ll file specified on the command line and links them together into a single module, called the test @@ -104,11 +102,11 @@ Otherwise, there is no problem bugpoint can debug.

    -
    +

    Crash debugger -

    + -
    +

    If an optimizer or code generator crashes, bugpoint will try as hard as it can to reduce the list of passes (for optimizer crashes) and the size of @@ -129,11 +127,11 @@ reproduce the failure with opt or llc.

    -
    +

    Code generator debugger -

    + -
    +

    The code generator debugger attempts to narrow down the amount of code that is being miscompiled by the selected code generator. To do this, it takes the @@ -150,11 +148,11 @@ good code.

    -
    +

    Miscompilation debugger -

    + -
    +

    The miscompilation debugger works similarly to the code generator debugger. It works by splitting the test program into two pieces, running the @@ -166,13 +164,15 @@ assumes that the selected code generator is working properly.

    +
    + -
    +

    Advice for using bugpoint -

    + -
    +
    bugpoint can be a remarkably useful tool, but it sometimes works in non-obvious ways. Here are some hints and tips:

    @@ -242,8 +242,8 @@ non-obvious ways. Here are some hints and tips:

    src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
    - LLVM Compiler Infrastructure
    - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + LLVM Compiler Infrastructure
    + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/CFEBuildInstrs.html b/docs/CFEBuildInstrs.html index ed2f295b7aff..ab10844a8e0e 100644 --- a/docs/CFEBuildInstrs.html +++ b/docs/CFEBuildInstrs.html @@ -21,7 +21,7 @@ This page has moved here. Valid HTML 4.01 - LLVM Compiler Infrastructure
    + LLVM Compiler Infrastructure
    Last modified: $Date: 2008-02-13 17:46:10 +0100 (Wed, 13 Feb 2008) $ diff --git a/docs/CMake.html b/docs/CMake.html index e303d132b590..0d8cf62e33c4 100644 --- a/docs/CMake.html +++ b/docs/CMake.html @@ -6,9 +6,9 @@ -

    +

    Building LLVM with CMake -

    +
    -
    +

    Introduction -

    + -
    +

    CMake is a cross-platform build-generator tool. CMake does not build the project, it generates @@ -56,12 +59,12 @@

    -
    +

    Quick start -

    + -
    +

    We use here the command-line, non-interactive CMake interface

    @@ -109,12 +112,12 @@
    -
    +

    Basic CMake usage -

    + -
    +

    This section explains basic aspects of CMake, mostly for explaining those options which you may need on your day-to-day @@ -157,12 +160,12 @@

    -
    +

    Options and variables -

    + -
    +

    Variables customize how the build will be generated. Options are boolean variables, with possible values ON/OFF. Options and @@ -191,14 +194,12 @@

    cmake -DVARIABLE:TYPE=value path/to/llvm/source

    -
    - -
    +

    Frequently-used CMake variables -

    + -
    +

    Here are listed some of the CMake variables that are used often, along with a brief explanation and LLVM-specific notes. For full @@ -237,11 +238,11 @@

    -
    +

    LLVM-specific variables -

    + -
    +
    LLVM_TARGETS_TO_BUILD:STRING
    @@ -342,7 +343,7 @@
    LLVM_LIT_TOOLS_DIR:STRING
    The path to GnuWin32 tools for tests. Valid on Windows host. Defaults to "", then Lit seeks tools according to %PATH%. - Lit can find tools(eg. grep, sort, &c) on LLVM_LIT_TOOLS_DIR at first, + Lit can find tools(eg. grep, sort, &c) on LLVM_LIT_TOOLS_DIR at first, without specifying GnuWin32 to %PATH%.
    LLVM_ENABLE_FFI:BOOL
    @@ -354,13 +355,15 @@
    +
    + -
    +

    Executing the test suite -

    + -
    +

    Testing is performed when the check target is built. For instance, if you are using makefiles, execute this command while on @@ -375,12 +378,12 @@

    -
    +

    Cross compiling -

    + -
    +

    See this wiki page for generic instructions on how to cross-compile @@ -396,12 +399,12 @@

    -
    +

    Embedding LLVM in your project -

    + -
    +

    The most difficult part of adding LLVM to the build of a project is to determine the set of LLVM libraries corresponding to the set @@ -418,7 +421,7 @@ endif() # We incorporate the CMake features provided by LLVM: set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${LLVM_ROOT}/share/llvm/cmake") - include(LLVM) + include(LLVMConfig) # Now set the header and library paths: include_directories( ${LLVM_ROOT}/include ) link_directories( ${LLVM_ROOT}/lib ) @@ -436,20 +439,111 @@ headers on the LLVM source directory (if we are building out-of-source.)

    -
    +

    Alternativaly, you can utilize CMake's find_package + functionality. Here is an equivalent variant of snippet shown above:

    + +
    + 
    +    find_package(LLVM)
+
+    if( NOT LLVM_FOUND )
+      message(FATAL_ERROR "LLVM package can't be found. Set CMAKE_PREFIX_PATH variable to LLVM's installation prefix.")
+    endif()
+
+    include_directories( ${LLVM_INCLUDE_DIRS} )
+    link_directories( ${LLVM_LIBRARY_DIRS} )
+
+    llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native)
+
+    target_link_libraries(mycompiler ${REQ_LLVM_LIBRARIES})
+
    +
    + + +

    + Developing LLVM pass out of source +

    + +
    +

    It is possible to develop LLVM passes against installed LLVM. + An example of project layout provided below:

    + +
    + 
    +      <project dir>/
+          |
+          CMakeLists.txt
+          <pass name>/
+              |
+              CMakeLists.txt
+              Pass.cpp
+              ...
+
    +
    + +

    Contents of <project dir>/CMakeLists.txt:

    + +
    + 
    +    find_package(LLVM)
+
+    # Define add_llvm_* macro's.
+    include(AddLLVM)
+
+    add_definitions(${LLVM_DEFINITIONS})
+    include_directories(${LLVM_INCLUDE_DIRS})
+    link_directories(${LLVM_LIBRARY_DIRS})
+
+    add_subdirectory(<pass name>)
+
    +
    + +

    Contents of <project dir>/<pass name>/CMakeLists.txt:

    + +
    + 
    +    add_llvm_loadable_module(LLVMPassname
+      Pass.cpp
+      )
+
    +
    + +

    When you are done developing your pass, you may wish to integrate it + into LLVM source tree. You can achieve it in two easy steps:
    + 1. Copying <pass name> folder into <LLVM root>/lib/Transform directory.
    + 2. Adding "add_subdirectory(<pass name>)" line into <LLVM root>/lib/Transform/CMakeLists.txt

    +
    +
    + -
    +

    Compiler/Platform specific topics -

    + -
    +

    Notes for specific compilers and/or platforms.

    +

    + Microsoft Visual C++ +

    + +
    + +
    +
    LLVM_COMPILER_JOBS:STRING
    +
    Specifies the maximum number of parallell compiler jobs to use + per project when building with msbuild or Visual Studio. Only supported for + Visual Studio 2008 and Visual Studio 2010 CMake generators. 0 means use all + processors. Default is 0.
    +
    + +
    +
    @@ -462,7 +556,7 @@ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Oscar Fuentes
    - LLVM Compiler Infrastructure
    + LLVM Compiler Infrastructure
    Last modified: $Date: 2010-08-09 03:59:36 +0100 (Mon, 9 Aug 2010) $ diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 925156ff0787..d082acc57dc1 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -19,9 +19,9 @@ -
    +

    The LLVM Target-Independent Code Generator -

    +
    1. Introduction @@ -127,12 +127,12 @@
    -
    +

    Introduction -

    + -
    +

    The LLVM target-independent code generator is a framework that provides a suite of reusable components for translating the LLVM internal representation @@ -188,14 +188,12 @@ depend on the target-description and machine code representation classes, ensuring that it is portable.

    -
    - -
    +

    Required components in the code generator -

    + -
    +

    The two pieces of the LLVM code generator are the high-level interface to the code generator and the set of reusable components that can be used to build @@ -223,11 +221,11 @@

    -
    +

    The high-level design of the code generator -

    + -
    +

    The LLVM target-independent code generator is designed to support efficient and quality code generation for standard register-based microprocessors. @@ -297,11 +295,11 @@

    -
    +

    Using TableGen for target description -

    + -
    +

    The target description classes require a detailed description of the target architecture. These target descriptions often have a large amount of common @@ -324,13 +322,15 @@

    +
    + -
    +

    Target description classes -

    + -
    +

    The LLVM target description classes (located in the include/llvm/Target directory) provide an abstract description of @@ -346,14 +346,12 @@ TargetMachine class provides accessors that should be implemented by the target.

    -
    - -
    +

    The TargetMachine class -

    + -
    +

    The TargetMachine class provides virtual methods that are used to access the target-specific implementations of the various target description @@ -369,11 +367,11 @@

    -
    +

    The TargetData class -

    + -
    +

    The TargetData class is the only required target description class, and it is the only class that is not extensible (you cannot derived a new @@ -385,11 +383,11 @@

    -
    +

    The TargetLowering class -

    + -
    +

    The TargetLowering class is used by SelectionDAG based instruction selectors primarily to describe how LLVM code should be lowered to @@ -411,11 +409,11 @@

    -
    +

    The TargetRegisterInfo class -

    + -
    +

    The TargetRegisterInfo class is used to describe the register file of the target and any interactions between the registers.

    @@ -445,11 +443,11 @@
    -
    +

    The TargetInstrInfo class -

    + -
    +

    The TargetInstrInfo class is used to describe the machine instructions supported by the target. It is essentially an array of @@ -463,11 +461,11 @@

    -
    +

    The TargetFrameInfo class -

    + -
    +

    The TargetFrameInfo class is used to provide information about the stack frame layout of the target. It holds the direction of stack growth, the @@ -479,11 +477,11 @@

    -
    +

    The TargetSubtarget class -

    + -
    +

    The TargetSubtarget class is used to provide information about the specific chip set being targeted. A sub-target informs code generation of @@ -495,11 +493,11 @@ -

    +

    The TargetJITInfo class -

    + -
    +

    The TargetJITInfo class exposes an abstract interface used by the Just-In-Time code generator to perform target-specific activities, such as @@ -509,13 +507,15 @@

    +
    + -
    +

    Machine code description classes -

    + -
    +

    At the high-level, LLVM code is translated to a machine specific representation formed out of @@ -528,14 +528,12 @@ SSA representation for machine code, as well as a register allocated, non-SSA form.

    -
    - -
    +

    The MachineInstr class -

    + -
    +

    Target machine instructions are represented as instances of the MachineInstr class. This class is an extremely abstract way of @@ -576,14 +574,12 @@

    Also if the first operand is a def, it is easier to create instructions whose only def is the first operand.

    -
    - -
    +

    Using the MachineInstrBuilder.h functions -

    + -
    +

    Machine instructions are created by using the BuildMI functions, located in the include/llvm/CodeGen/MachineInstrBuilder.h file. The @@ -630,11 +626,11 @@ MI.addReg(Reg, RegState::Define);

    -
    +

    Fixed (preassigned) registers -

    + -
    +

    One important issue that the code generator needs to be aware of is the presence of fixed registers. In particular, there are often places in the @@ -702,11 +698,11 @@ ret

    -
    +

    Machine code in SSA form -

    + -
    +

    MachineInstr's are initially selected in SSA-form, and are maintained in SSA-form until register allocation happens. For the most part, @@ -719,12 +715,14 @@ ret

    +
    + -
    +

    The MachineBasicBlock class -

    + -
    +

    The MachineBasicBlock class contains a list of machine instructions (MachineInstr instances). It roughly @@ -737,11 +735,11 @@ ret

    -
    +

    The MachineFunction class -

    + -
    +

    The MachineFunction class contains a list of machine basic blocks (MachineBasicBlock instances). It @@ -754,14 +752,15 @@ ret

    +
    -
    +

    The "MC" Layer -

    + -
    +

    The MC Layer is used to represent and process code at the raw machine code @@ -770,7 +769,7 @@ level, devoid of "high level" information like "constant pools", "jump tables", like label names, machine instructions, and sections in the object file. The code in this layer is used for a number of important purposes: the tail end of the code generator uses it to write a .s or .o file, and it is also used by the -llvm-mc tool to implement standalone machine codeassemblers and disassemblers. +llvm-mc tool to implement standalone machine code assemblers and disassemblers.

    @@ -779,15 +778,12 @@ of important subsystems that interact at this layer, they are described later in this manual.

    -
    - - -
    +

    The MCStreamer API -

    + -
    +

    MCStreamer is best thought of as an assembler API. It is an abstract API which @@ -817,11 +813,11 @@ MCObjectStreamer implements a full assembler.

    -
    +

    The MCContext class -

    + -
    +

    The MCContext class is the owner of a variety of uniqued data structures at the @@ -832,11 +828,11 @@ interact with to create symbols and sections. This class can not be subclassed.

    -
    +

    The MCSymbol class -

    + -
    +

    The MCSymbol class represents a symbol (aka label) in the assembly file. There @@ -864,11 +860,11 @@ like this to the .s file:

    -
    +

    The MCSection class -

    + -
    +

    The MCSection class represents an object-file specific section. It is subclassed @@ -882,11 +878,11 @@ directive in a .s file).

    -
    +

    The MCInst class -

    + -
    +

    The MCInst class is a target-independent representation of an instruction. It @@ -904,27 +900,26 @@ printer, and the type generated by the assembly parser and disassembler.

    +
    -
    +

    Target-independent code generation algorithms -

    + -
    +

    This section documents the phases described in the high-level design of the code generator. It explains how they work and some of the rationale behind their design.

    -
    - -
    +

    Instruction Selection -

    + -
    +

    Instruction Selection is the process of translating LLVM code presented to the code generator into target-specific machine instructions. There are @@ -936,14 +931,12 @@ printer, and the type generated by the assembly parser and disassembler. selector to be generated from these .td files, though currently there are still things that require custom C++ code.

    -
    - -
    +

    Introduction to SelectionDAGs -

    + -
    +

    The SelectionDAG provides an abstraction for code representation in a way that is amenable to instruction selection using automatic techniques @@ -1001,11 +994,11 @@ printer, and the type generated by the assembly parser and disassembler.

    -
    +

    SelectionDAG Instruction Selection Process -

    + -
    +

    SelectionDAG-based instruction selection consists of the following steps:

    @@ -1082,11 +1075,11 @@ printer, and the type generated by the assembly parser and disassembler.
    -
    +

    Initial SelectionDAG Construction -

    + -
    +

    The initial SelectionDAG is naïvely peephole expanded from the LLVM input by the SelectionDAGLowering class in the @@ -1102,11 +1095,11 @@ printer, and the type generated by the assembly parser and disassembler.

    -
    +

    SelectionDAG LegalizeTypes Phase -

    + -
    +

    The Legalize phase is in charge of converting a DAG to only use the types that are natively supported by the target.

    @@ -1135,11 +1128,11 @@ printer, and the type generated by the assembly parser and disassembler.
    -
    +

    SelectionDAG Legalize Phase -

    + -
    +

    The Legalize phase is in charge of converting a DAG to only use the operations that are natively supported by the target.

    @@ -1167,12 +1160,13 @@ printer, and the type generated by the assembly parser and disassembler.
    -
    - SelectionDAG Optimization Phase: the DAG - Combiner -
    +

    + + SelectionDAG Optimization Phase: the DAG Combiner + +

    -
    +

    The SelectionDAG optimization phase is run multiple times for code generation, immediately after the DAG is built and once after each @@ -1202,11 +1196,11 @@ printer, and the type generated by the assembly parser and disassembler.

    -
    +

    SelectionDAG Select Phase -

    + -
    +

    The Select phase is the bulk of the target-specific code for instruction selection. This phase takes a legal SelectionDAG as input, pattern matches @@ -1363,11 +1357,11 @@ def : Pat<(i32 imm:$imm),

    -
    +

    SelectionDAG Scheduling and Formation Phase -

    + -
    +

    The scheduling phase takes the DAG of target instructions from the selection phase and assigns an order. The scheduler can pick an order depending on @@ -1384,11 +1378,11 @@ def : Pat<(i32 imm:$imm),

    -
    +

    Future directions for the SelectionDAG -

    + -
    +
    1. Optional function-at-a-time selection.
      2. @@ -1398,18 +1392,20 @@ def : Pat<(i32 imm:$imm),
    +
    + -
    +

    SSA-based Machine Code Optimizations -

    -

    To Be Written

    + +

    To Be Written

    -
    +

    Live Intervals -

    + -
    +

    Live Intervals are the ranges (intervals) where a variable is live. They are used by some register allocator passes to @@ -1417,14 +1413,12 @@ def : Pat<(i32 imm:$imm), register are live at the same point in the program (i.e., they conflict). When this situation occurs, one virtual register must be spilled.

    -
    - -
    +

    Live Variable Analysis -

    + -
    +

    The first step in determining the live intervals of variables is to calculate the set of registers that are immediately dead after the instruction (i.e., @@ -1466,11 +1460,11 @@ def : Pat<(i32 imm:$imm),

    -
    +

    Live Intervals Analysis -

    + -
    +

    We now have the information available to perform the live intervals analysis and build the live intervals themselves. We start off by numbering the basic @@ -1485,12 +1479,14 @@ def : Pat<(i32 imm:$imm),

    +
    + -
    +

    Register Allocation -

    + -
    +

    The Register Allocation problem consists in mapping a program Pv, that can use an unbounded number of virtual registers, @@ -1500,15 +1496,13 @@ def : Pat<(i32 imm:$imm), accommodate all the virtual registers, some of them will have to be mapped into memory. These virtuals are called spilled virtuals.

    -
    - -
    +

    How registers are represented in LLVM -

    + -
    +

    In LLVM, physical registers are denoted by integer numbers that normally range from 1 to 1023. To see how this numbering is defined for a particular @@ -1617,11 +1611,11 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, -

    +

    Mapping virtual registers to physical registers -

    + -
    +

    There are two ways to map virtual registers to physical registers (or to memory slots). The first way, that we will call direct mapping, is @@ -1667,11 +1661,11 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf,

    -
    +

    Handling two address instructions -

    + -
    +

    With very rare exceptions (e.g., function calls), the LLVM machine code instructions are three address instructions. That is, each instruction is @@ -1703,11 +1697,11 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf,

    -
    +

    The SSA deconstruction phase -

    + -
    +

    An important transformation that happens during register allocation is called the SSA Deconstruction Phase. The SSA form simplifies many analyses @@ -1727,11 +1721,11 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf,

    -
    +

    Instruction folding -

    + -
    +

    Instruction folding is an optimization performed during register allocation that removes unnecessary copy instructions. For instance, a @@ -1764,11 +1758,11 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, -

    +

    Built in register allocators -

    + -
    +

    The LLVM infrastructure provides the application developer with three different register allocators:

    @@ -1805,23 +1799,25 @@ $ llc -regalloc=pbqp file.bc -o pbqp.s;
    +
    + -
    +

    Prolog/Epilog Code Insertion -

    -

    To Be Written

    + +

    To Be Written

    -
    +

    Late Machine Code Optimizations -

    -

    To Be Written

    + +

    To Be Written

    -
    +

    Code Emission -

    + -
    +

    The code emission step of code generation is responsible for lowering from the code generator abstractions (like

    +
    -
    +

    Implementing a Native Assembler -

    + -
    +

    Though you're probably reading this because you want to write or maintain a compiler backend, LLVM also fully supports building a native assemblers too. @@ -1896,20 +1893,18 @@ We've tried hard to automate the generation of the assembler from the .td files part of the manual and repetitive data entry can be factored and shared with the compiler.

    -
    - -
    Instruction Parsing
    +

    Instruction Parsing

    -

    To Be Written

    +

    To Be Written

    -
    +

    Instruction Alias Processing -

    + -
    +

    Once the instruction is parsed, it enters the MatchInstructionImpl function. The MatchInstructionImpl function performs alias processing and then does actual matching.

    @@ -1922,12 +1917,10 @@ complex/powerful). Generally you want to use the first alias mechanism that meets the needs of your instruction, because it will allow a more concise description.

    -
    - -
    Mnemonic Aliases
    +

    Mnemonic Aliases

    -
    +

    The first phase of alias processing is simple instruction mnemonic remapping for classes of instructions which are allowed with two different @@ -1965,9 +1958,9 @@ on the current instruction set.

    -
    Instruction Aliases
    +

    Instruction Aliases

    -
    +

    The most general phase of alias processing occurs while matching is happening: it provides new forms for the matcher to match along with a specific @@ -2028,36 +2021,33 @@ subtarget specific.

    - +
    -
    Instruction Matching
    - -

    To Be Written

    - +

    Instruction Matching

    +

    To Be Written

    +
    -
    +

    Target-specific Implementation Notes -

    + -
    +

    This section of the document explains features or design decisions that are specific to the code generator for a particular target. First we start with a table that summarizes what features are supported by each target.

    -
    - -
    +

    Target Feature Matrix -

    + -
    +

    Note that this table does not include the C backend or Cpp backends, since they do not use the target independent code generator infrastructure. It also @@ -2228,12 +2218,10 @@ is the key:

    -
    - -
    Is Generally Reliable
    +

    Is Generally Reliable

    -
    +

    This box indicates whether the target is considered to be production quality. This indicates that the target has been used as a static compiler to compile large amounts of code by a variety of different people and is in @@ -2241,9 +2229,9 @@ continuous use.

    -
    Assembly Parser
    +

    Assembly Parser

    -
    +

    This box indicates whether the target supports parsing target specific .s files by implementing the MCAsmParser interface. This is required for llvm-mc to be able to act as a native assembler and is required for inline assembly @@ -2253,18 +2241,18 @@ support in the native .o file writer.

    -
    Disassembler
    +

    Disassembler

    -
    +

    This box indicates whether the target supports the MCDisassembler API for disassembling machine opcode bytes into MCInst's.

    -
    Inline Asm
    +

    Inline Asm

    -
    +

    This box indicates whether the target supports most popular inline assembly constraints and modifiers.

    @@ -2274,9 +2262,9 @@ constraints relating to the X86 floating point stack.

    -
    JIT Support
    +

    JIT Support

    -
    +

    This box indicates whether the target supports the JIT compiler through the ExecutionEngine interface.

    @@ -2286,9 +2274,9 @@ in ARM codegen mode, but lacks NEON and full Thumb support.

    -
    .o File Writing
    +

    .o File Writing

    -
    +

    This box indicates whether the target supports writing .o files (e.g. MachO, ELF, and/or COFF) files directly from the target. Note that the target also @@ -2302,9 +2290,9 @@ file to a .o file (as is the case for many C compilers).

    -
    Tail Calls
    +

    Tail Calls

    -
    +

    This box indicates whether the target supports guaranteed tail calls. These are calls marked "tail" and use the fastcc @@ -2313,15 +2301,14 @@ more more details.

    - - +
    -
    +

    Tail call optimization -

    + -
    +

    Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if:

    @@ -2383,11 +2370,11 @@ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) {
    -
    +

    Sibling call optimization -

    + -
    +

    Sibling call optimization is a restricted form of tail call optimization. Unlike tail call optimization described in the previous section, it can be @@ -2427,24 +2414,22 @@ entry:

    -
    +

    The X86 backend -

    + -
    +

    The X86 code generator lives in the lib/Target/X86 directory. This code generator is capable of targeting a variety of x86-32 and x86-64 processors, and includes support for ISA extensions such as MMX and SSE.

    -
    - -
    +

    X86 Target Triples supported -

    + -
    +

    The following are the known target triples that are supported by the X86 backend. This is not an exhaustive list, and it would be useful to add those @@ -2469,12 +2454,12 @@ entry:

    -
    +

    X86 Calling Conventions supported -

    + -
    +

    The following target-specific calling conventions are known to backend:

    @@ -2489,11 +2474,11 @@ entry:
    -
    +

    Representing X86 addressing modes in MachineInstrs -

    + -
    +

    The x86 has a very flexible way of accessing memory. It is capable of forming memory addresses of the following expression directly in integer @@ -2526,13 +2511,13 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg

    -
    +

    X86 address spaces supported -

    + -
    +
    -

    x86 has an experimental feature which provides +

    x86 has a feature which provides the ability to perform loads and stores to different address spaces via the x86 segment registers. A segment override prefix byte on an instruction causes the instruction's memory access to go to the specified @@ -2571,11 +2556,11 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg

    -
    +

    Instruction naming -

    + -
    +

    An instruction name consists of the base name, a default operand size, and a a character per operand with an optional special size. For example:

    @@ -2591,25 +2576,25 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
    +
    + -
    +

    The PowerPC backend -

    + -
    +

    The PowerPC code generator lives in the lib/Target/PowerPC directory. The code generation is retargetable to several variations or subtargets of the PowerPC ISA; including ppc32, ppc64 and altivec.

    -
    - -
    +

    LLVM PowerPC ABI -

    + -
    +

    LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative (PIC) or static addressing for accessing global values, so no TOC @@ -2625,11 +2610,11 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory

    -
    +

    Frame Layout -

    + -
    +

    The size of a PowerPC frame is usually fixed for the duration of a function's invocation. Since the frame is fixed size, all references @@ -2772,11 +2757,11 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory

    -
    +

    Prolog/Epilog -

    + -
    +

    The llvm prolog and epilog are the same as described in the PowerPC ABI, with the following exceptions. Callee saved registers are spilled after the frame @@ -2789,16 +2774,19 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory

    -
    +

    Dynamic Allocation -

    + -
    +

    TODO - More to come.

    +
    + +
    @@ -2809,8 +2797,8 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
    - The LLVM Compiler Infrastructure
    - Last modified: $Date: 2011-01-09 00:10:59 +0100 (Sun, 09 Jan 2011) $ + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html index 4a9ab7d857a8..139bbdb24902 100644 --- a/docs/CodingStandards.html +++ b/docs/CodingStandards.html @@ -7,9 +7,9 @@ -
    +

    LLVM Coding Standards -

    +
    1. Introduction
      2. @@ -83,12 +83,12 @@ -
      +

      Introduction -

      + -
      +

      This document attempts to describe a few coding standards that are being used in the LLVM source tree. Although no coding standards should be regarded as @@ -117,22 +117,26 @@ href="mailto:sabre@nondot.org">Chris.

      -
      +

      Mechanical Source Issues -

      + +
      + -
      +

      Source Code Formatting -

      + + +
      -
      +

      Commenting -

      + -
      +

      Comments are one critical part of readability and maintainability. Everyone knows they should comment, so should you. When writing comments, write them as @@ -141,7 +145,9 @@ etc. Although we all should probably comment our code more than we do, there are a few very critical places that documentation is very useful:

      -File Headers +
      File Headers
      + +

      Every source file should have a header on it that describes the basic purpose of the file. If a file does not have a header, it should not be @@ -184,7 +190,9 @@ Here it's only two lines. If an algorithm is being implemented or something tricky is going on, a reference to the paper where it is published should be included, as well as any notes or "gotchas" in the code to watch out for.

      -Class overviews +
      + +
      Class overviews

      Classes are one fundamental part of a good object oriented design. As such, a class definition should have a comment block that explains what the class is @@ -193,7 +201,9 @@ could figure it out, it's probably safe to leave it out. Naming classes something sane goes a long ways towards avoiding writing documentation.

      -Method information +
      Method information
      + +

      Methods defined in a class (as well as any global functions) should also be documented properly. A quick note about what it does and a description of the @@ -207,12 +217,14 @@ happens: does the method return null? Abort? Format your hard disk?

      +
      + -
      +

      Comment Formatting -

      + -
      +

      In general, prefer C++ style (//) comments. They take less space, require less typing, don't have nesting problems, etc. There are a few cases @@ -233,11 +245,11 @@ These nest properly and are better behaved in general than C style comments.

      -
      +

      #include Style -

      + -
      +

      Immediately after the header file comment (and include guards if working on a header file), the

      -
      +

      Source Code Width -

      + -
      +

      Write your code to fit within 80 columns of text. This helps those of us who like to print out code and look at your code in an xterm without resizing @@ -298,11 +310,11 @@ for debate.

      -
      +

      Use Spaces Instead of Tabs -

      + -
      +

      In all cases, prefer spaces to tabs in source files. People have different preferred indentation levels, and different styles of indentation that they @@ -319,11 +331,11 @@ makes for incredible diffs that are absolutely worthless.

      -
      +

      Indent Code Consistently -

      + -
      +

      Okay, in your first year of programming you were told that indentation is important. If you didn't believe and internalize this then, now is the time. @@ -331,19 +343,21 @@ Just do it.

      +
      -
      +

      Compiler Issues -

      + +
      -
      +

      Treat Compiler Warnings Like Errors -

      + -
      +

      If your code has compiler warnings in it, something is wrong — you aren't casting values correctly, your have "questionable" constructs in your @@ -393,11 +407,11 @@ be fixed by massaging the code appropriately.

      -
      +

      Write Portable Code -

      + -
      +

      In almost all cases, it is possible and within reason to write completely portable code. If there are cases where it isn't possible to write portable @@ -412,10 +426,10 @@ libSystem.

      -
      +

      Do not use RTTI or Exceptions -

      -
      + +

      In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast<>) or exceptions. These two language features @@ -433,10 +447,10 @@ than dynamic_cast<>.

      -
      +

      Use of class and struct Keywords -

      -
      + +

      In C++, the class and struct keywords can be used almost interchangeably. The only difference is when they are used to declare a class: @@ -454,26 +468,32 @@ which case struct is allowed.

      +
      + +
      + -
      +

      Style Issues -

      + +
      -
      +

      The High-Level Issues -

      + +
      -
      +

      A Public Header File is a Module -

      + -
      +

      C++ doesn't do too well in the modularity department. There is no real encapsulation or data hiding (unless you use expensive protocol classes), but it @@ -499,11 +519,11 @@ translation unit.

      -
      +

      #include as Little as Possible -

      + -
      +

      #include hurts compile time performance. Don't do it unless you have to, especially in header files.

      @@ -528,11 +548,11 @@ dependencies that you'll find out about later.

      -
      +

      Keep "Internal" Headers Private -

      + -
      +

      Many modules have a complex implementation that causes them to use more than one implementation (.cpp) file. It is often tempting to put the @@ -549,11 +569,11 @@ class itself. Just make them private (or protected) and all is well.

      -
      +

      Use Early Exits and continue to Simplify Code -

      + -
      +

      When reading code, keep in mind how much state and how many previous decisions have to be remembered by the reader to understand a block of code. @@ -658,11 +678,11 @@ can be a big understandability win.

      -
      +

      Don't use else after a return -

      + -
      +

      For similar reasons above (reduction of indentation and easier reading), please do not use 'else' or 'else if' after something that @@ -741,11 +761,11 @@ track of when reading the code.

      -
      +

      Turn Predicate Loops into Predicate Functions -

      + -
      +

      It is very common to write small loops that just compute a boolean value. There are a number of ways that people commonly write these, but an example of @@ -802,20 +822,24 @@ locality.

      +
      -
      +

      The Low-Level Issues -

      + +
      -
      - Name Types, Functions, Variables, and Enumerators Properly -
      +

      + + Name Types, Functions, Variables, and Enumerators Properly + +

      -
      +

      Poorly-chosen names can mislead the reader and cause bugs. We cannot stress enough how important it is to use descriptive names. Pick names that @@ -894,11 +918,11 @@ Vehicle MakeVehicle(VehicleType Type) { -

      +

      Assert Liberally -

      + -
      +

      Use the "assert" macro to its fullest. Check all of your preconditions and assumptions, you never know when a bug (not necessarily even @@ -997,11 +1021,11 @@ assert(NewToSet && "The value shouldn't be in the set yet");

      -
      +

      Do Not Use 'using namespace std' -

      + -
      +

      In LLVM, we prefer to explicitly prefix all identifiers from the standard namespace with an "std::" prefix, rather than rely on @@ -1035,12 +1059,13 @@ use any others.

      -
      - Provide a Virtual Method Anchor for Classes - in Headers -
      +

      + + Provide a Virtual Method Anchor for Classes in Headers + +

      -
      +

      If a class is defined in a header file and has a v-table (either it has virtual methods or it derives from classes with virtual methods), it must @@ -1052,11 +1077,11 @@ increasing link times.

      -
      +

      Don't evaluate end() every time through a loop -

      + -
      +

      Because C++ doesn't have a standard "foreach" loop (though it can be emulated with macros and may be coming in C++'0x) we end up writing a lot of @@ -1114,11 +1139,11 @@ prefer it.

      -
      +

      #include <iostream> is Forbidden -

      + -
      +

      The use of #include <iostream> in library files is hereby forbidden. The primary reason for doing this is to @@ -1149,11 +1174,11 @@ the llvm::MemoryBuffer API for reading files.

      -
      +

      Use raw_ostream -

      + -
      +

      LLVM includes a lightweight, simple, and efficient stream implementation in llvm/Support/raw_ostream.h, which provides all of the common @@ -1169,11 +1194,11 @@ declarations and constant references to raw_ostream instances.

      -
      +

      Avoid std::endl -

      + -
      +

      The std::endl modifier, when used with iostreams outputs a newline to the output stream specified. In addition to doing this, however, it @@ -1191,22 +1216,25 @@ it's better to use a literal '\n'.

      +
      -
      +

      Microscopic Details -

      + +
      +

      This section describes preferred low-level formatting guidelines along with reasoning on why we prefer them.

      -
      +

      Spaces Before Parentheses -

      + -
      +

      We prefer to put a space before an open parenthesis only in control flow statements, but not in normal function call expressions and function-like @@ -1260,11 +1288,11 @@ this misinterpretation.

      -
      +

      Prefer Preincrement -

      + -
      +

      Hard fast rule: Preincrement (++X) may be no slower than postincrement (X++) and could very well be a lot faster than it. Use @@ -1280,11 +1308,11 @@ get in the habit of always using preincrement, and you won't have a problem.

      -
      +

      Namespace Indentation -

      + -
      +

      In general, we strive to reduce indentation wherever possible. This is useful @@ -1368,11 +1396,11 @@ the contents of the namespace.

      -
      +

      Anonymous Namespaces -

      + -
      +

      After talking about namespaces in general, you may be wondering about anonymous namespaces in particular. @@ -1452,15 +1480,17 @@ namespace just because it was declared there.

      +
      +
      -
      +

      See Also -

      + -
      +

      A lot of these comments and recommendations have been culled for other sources. Two particularly important books for our work are:

      @@ -1491,8 +1521,8 @@ something.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
      - LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-20 03:03:04 +0100 (Sun, 20 Feb 2011) $ + LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/CommandGuide/FileCheck.pod b/docs/CommandGuide/FileCheck.pod index 3ccaa63e176b..dbd626c7cb7f 100644 --- a/docs/CommandGuide/FileCheck.pod +++ b/docs/CommandGuide/FileCheck.pod @@ -240,6 +240,6 @@ define two separate CHECK lines that match on the same line. =head1 AUTHORS -Maintained by The LLVM Team (L). +Maintained by The LLVM Team (L). =cut diff --git a/docs/CommandGuide/bugpoint.pod b/docs/CommandGuide/bugpoint.pod index 1870a0d84b60..31db62fe2d6b 100644 --- a/docs/CommandGuide/bugpoint.pod +++ b/docs/CommandGuide/bugpoint.pod @@ -21,7 +21,7 @@ distribution. =head1 OPTIONS -=over +=over =item B<--additional-so> F @@ -87,7 +87,7 @@ mis-management. =item B<-find-bugs> Continually randomize the specified passes and run them on the test program -until a bug is found or the user kills B. +until a bug is found or the user kills B. =item B<-help> @@ -147,6 +147,21 @@ This option defines the command to use with the B<--run-custom> and B<--safe-custom> options to execute the bitcode testcase. This can be useful for cross-compilation. +=item B<--compile-command> I + +This option defines the command to use with the B<--compile-custom> +option to compile the bitcode testcase. This can be useful for +testing compiler output without running any link or execute stages. To +generate a reduced unit test, you may add CHECK directives to the +testcase and pass the name of an executable compile-command script in this form: + + #!/bin/sh + llc "$@" + not FileCheck [bugpoint input file].ll < bugpoint-test-program.s + +This script will "fail" as long as FileCheck passes. So the result +will be the minimum bitcode that passes FileCheck. + =item B<--safe-path> I This option defines the path to the command to execute with the @@ -166,6 +181,6 @@ L =head1 AUTHOR -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/index.html b/docs/CommandGuide/index.html index 3c1a9f9ed4f0..cb5438f58baa 100644 --- a/docs/CommandGuide/index.html +++ b/docs/CommandGuide/index.html @@ -3,15 +3,15 @@ LLVM Command Guide - + -
      +

      LLVM Command Guide -

      + -
      +

      These documents are HTML versions of the man pages for all of the LLVM tools. These pages describe how to use the LLVM commands @@ -23,12 +23,12 @@ options) arguments to the tool you are interested in.

      -
      +

      Basic Commands -

      + -
      +
        @@ -80,12 +80,12 @@ options) arguments to the tool you are interested in.

      -
      +

      C and C++ Front-end Commands -

      + -
      +
      • llvm-gcc - @@ -99,13 +99,13 @@ options) arguments to the tool you are interested in.

      -
      +

      Debugging Tools -

      + -
      +
        @@ -123,12 +123,12 @@ options) arguments to the tool you are interested in.

      -
      +

      Internal Tools -

      + -
      +
      • FileCheck - @@ -150,8 +150,8 @@ options) arguments to the tool you are interested in.

        Valid HTML 4.01 - LLVM Compiler Infrastructure
        - Last modified: $Date: 2010-09-08 01:10:21 +0200 (Wed, 08 Sep 2010) $ + LLVM Compiler Infrastructure
        + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/CommandGuide/lit.pod b/docs/CommandGuide/lit.pod index 989a5d7acb51..faf4811dd18c 100644 --- a/docs/CommandGuide/lit.pod +++ b/docs/CommandGuide/lit.pod @@ -349,6 +349,6 @@ L =head1 AUTHOR -Written by Daniel Dunbar and maintained by the LLVM Team (L). +Written by Daniel Dunbar and maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llc.pod b/docs/CommandGuide/llc.pod index eb26ec00fd76..50b45c8d5a2a 100644 --- a/docs/CommandGuide/llc.pod +++ b/docs/CommandGuide/llc.pod @@ -196,6 +196,6 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/lli.pod b/docs/CommandGuide/lli.pod index 52a2721e7d70..a313a31718c4 100644 --- a/docs/CommandGuide/lli.pod +++ b/docs/CommandGuide/lli.pod @@ -214,6 +214,6 @@ L =head1 AUTHOR -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-ar.pod b/docs/CommandGuide/llvm-ar.pod index 63ba43f6f6f8..a8f01b0319a0 100644 --- a/docs/CommandGuide/llvm-ar.pod +++ b/docs/CommandGuide/llvm-ar.pod @@ -401,6 +401,6 @@ L, ar(1) =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-as.pod b/docs/CommandGuide/llvm-as.pod index 185c009698f3..cc8188708a53 100644 --- a/docs/CommandGuide/llvm-as.pod +++ b/docs/CommandGuide/llvm-as.pod @@ -72,6 +72,6 @@ L, L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-bcanalyzer.pod b/docs/CommandGuide/llvm-bcanalyzer.pod index b0bc0cddba82..9c5021b639f1 100644 --- a/docs/CommandGuide/llvm-bcanalyzer.pod +++ b/docs/CommandGuide/llvm-bcanalyzer.pod @@ -268,7 +268,7 @@ The number of bytes consumed by instructions in the function. =item B -The average number of bytes consumed by the instructions in the funtion. This +The average number of bytes consumed by the instructions in the function. This value is computed by dividing Instruction Size by Instructions. =item B @@ -310,6 +310,6 @@ L, L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-config.pod b/docs/CommandGuide/llvm-config.pod index 4e38dae3df63..7d68564a6d75 100644 --- a/docs/CommandGuide/llvm-config.pod +++ b/docs/CommandGuide/llvm-config.pod @@ -126,6 +126,6 @@ occurs, it will exit with a non-zero value. =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-diff.pod b/docs/CommandGuide/llvm-diff.pod index c8cfdb3be94d..ffe0b4896fdd 100644 --- a/docs/CommandGuide/llvm-diff.pod +++ b/docs/CommandGuide/llvm-diff.pod @@ -48,6 +48,6 @@ massive detected differences in blocks. =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-dis.pod b/docs/CommandGuide/llvm-dis.pod index 5b2f4ef4e924..9f4026c27fe7 100644 --- a/docs/CommandGuide/llvm-dis.pod +++ b/docs/CommandGuide/llvm-dis.pod @@ -55,6 +55,6 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-extract.pod b/docs/CommandGuide/llvm-extract.pod index d4baab73991a..797e79d128d4 100644 --- a/docs/CommandGuide/llvm-extract.pod +++ b/docs/CommandGuide/llvm-extract.pod @@ -68,6 +68,6 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-ld.pod b/docs/CommandGuide/llvm-ld.pod index 536ab0fa43d5..efa9ebd06c53 100644 --- a/docs/CommandGuide/llvm-ld.pod +++ b/docs/CommandGuide/llvm-ld.pod @@ -229,6 +229,6 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-link.pod b/docs/CommandGuide/llvm-link.pod index 8d06cc9d9d9f..1e466a56f4ec 100644 --- a/docs/CommandGuide/llvm-link.pod +++ b/docs/CommandGuide/llvm-link.pod @@ -74,6 +74,6 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-nm.pod b/docs/CommandGuide/llvm-nm.pod index a580d3f5ca70..a6dc4901dd61 100644 --- a/docs/CommandGuide/llvm-nm.pod +++ b/docs/CommandGuide/llvm-nm.pod @@ -117,6 +117,6 @@ L, ar(1), nm(1) =head1 AUTHOR -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-prof.pod b/docs/CommandGuide/llvm-prof.pod index 9541b05dcafc..4b2e09d70470 100644 --- a/docs/CommandGuide/llvm-prof.pod +++ b/docs/CommandGuide/llvm-prof.pod @@ -52,6 +52,6 @@ information. Otherwise, it exits with zero. =head1 AUTHOR -B is maintained by the LLVM Team (L). +B is maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvm-ranlib.pod b/docs/CommandGuide/llvm-ranlib.pod index 53cd34bbb5c4..431bc551048a 100644 --- a/docs/CommandGuide/llvm-ranlib.pod +++ b/docs/CommandGuide/llvm-ranlib.pod @@ -47,6 +47,6 @@ L, ranlib(1) =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvmc.pod b/docs/CommandGuide/llvmc.pod index d237ca4c14fa..95a9e5ef3611 100644 --- a/docs/CommandGuide/llvmc.pod +++ b/docs/CommandGuide/llvmc.pod @@ -185,6 +185,6 @@ L, L, L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvmgcc.pod b/docs/CommandGuide/llvmgcc.pod index 9892ca71861e..30af0a06e06f 100644 --- a/docs/CommandGuide/llvmgcc.pod +++ b/docs/CommandGuide/llvmgcc.pod @@ -70,7 +70,7 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/llvmgxx.pod b/docs/CommandGuide/llvmgxx.pod index 64b670ebe069..1ea3d4967006 100644 --- a/docs/CommandGuide/llvmgxx.pod +++ b/docs/CommandGuide/llvmgxx.pod @@ -79,7 +79,7 @@ L =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/opt.pod b/docs/CommandGuide/opt.pod index d1d1db5ef67e..f5f496817eb8 100644 --- a/docs/CommandGuide/opt.pod +++ b/docs/CommandGuide/opt.pod @@ -138,6 +138,6 @@ occurs, it will exit with a non-zero value. =head1 AUTHORS -Maintained by the LLVM Team (L). +Maintained by the LLVM Team (L). =cut diff --git a/docs/CommandGuide/tblgen.pod b/docs/CommandGuide/tblgen.pod index d127492a91bb..fe1be5ecfa3c 100644 --- a/docs/CommandGuide/tblgen.pod +++ b/docs/CommandGuide/tblgen.pod @@ -110,6 +110,6 @@ occurs, it will exit with a non-zero value. =head1 AUTHORS -Maintained by The LLVM Team (L). +Maintained by The LLVM Team (L). =cut diff --git a/docs/CommandLine.html b/docs/CommandLine.html index 2e5b3a2c4dcb..7535ca498400 100644 --- a/docs/CommandLine.html +++ b/docs/CommandLine.html @@ -8,9 +8,9 @@ -
        +

        CommandLine 2.0 Library Manual -

        +
        1. Introduction
          2. @@ -100,12 +100,12 @@
      -
      +

      Introduction -

      + -
      +

      This document describes the CommandLine argument processing library. It will show you how to use it, and what it can do. The CommandLine library uses a @@ -184,12 +184,12 @@ href="mailto:sabre@nondot.org">Chris Lattner.

      -
      +

      Quick Start Guide -

      + -
      +

      This section of the manual runs through a simple CommandLine'ification of a basic compiler tool. This is intended to show you how to jump into using the @@ -231,11 +231,11 @@ represented like this:

      cl::opt<string> OutputFilename("o", cl::desc("Specify output filename"), cl::value_desc("filename"));
      -

      This declares a global variable "OutputFilename" that is used to -capture the result of the "o" argument (first parameter). We specify -that this is a simple scalar option by using the "cl::opt" template (as opposed to the "cl::list template), and tell the CommandLine library +

      This declares a global variable "OutputFilename" that is used to +capture the result of the "o" argument (first parameter). We specify +that this is a simple scalar option by using the "cl::opt" template (as opposed to the "cl::list template), and tell the CommandLine library that the data type that we are parsing is a string.

      The second and third parameters (which are optional) are used to specify what @@ -321,14 +321,12 @@ OPTIONS:

      ... indicating that an input filename is expected.

      -
      - -
      +

      Boolean Arguments -

      + -
      +

      In addition to input and output filenames, we would like the compiler example to support three boolean flags: "-f" to force writing binary output to @@ -406,11 +404,11 @@ and lists of options.

      -
      +

      Argument Aliases -

      + -
      +

      So far, the example works well, except for the fact that we need to check the quiet condition like this now:

      @@ -456,12 +454,12 @@ uses.

      -
      +

      Selecting an alternative from a set of possibilities -

      + -
      +

      So far we have seen how the CommandLine library handles builtin types like std::string, bool and int, but how does it handle @@ -567,11 +565,11 @@ which is when you would use it.

      -
      +

      Named Alternatives -

      + -
      +

      Another useful argument form is a named alternative style. We shall use this style in our compiler to specify different debug levels that can be used. @@ -629,11 +627,11 @@ that you can choose the form most appropriate for your application.

      -
      +

      Parsing a list of options -

      + -
      +

      Now that we have the standard run-of-the-mill argument types out of the way, lets get a little wild and crazy. Lets say that we want our optimizer to accept @@ -699,11 +697,11 @@ checking we have to do.

      -
      +

      Collecting options as a set of flags -

      + -
      +

      Instead of collecting sets of options in a list, it is also possible to gather information for enum values in a bit vector. The representation used by @@ -758,11 +756,11 @@ href="#list"> cl::list option.

      -
      +

      Adding freeform text to help output -

      + -
      +

      As our program grows and becomes more mature, we may decide to put summary information about what it does into the help output. The help output is styled @@ -800,28 +798,27 @@ OPTIONS:

      +
      -
      +

      Reference Guide -

      + -
      +

      Now that you know the basics of how to use the CommandLine library, this section will give you the detailed information you need to tune how command line options work, as well as information on more "advanced" command line option processing capabilities.

      -
      - -
      +

      Positional Arguments -

      + -
      +

      Positional arguments are those arguments that are not named, and are not specified with a hyphen. Positional arguments should be used when an option is @@ -854,15 +851,12 @@ that command line options will be ordered according to how they are listed in a are defined in multiple .cpp files. The fix for this problem is simply to define all of your positional arguments in one .cpp file.

      -
      - - -
      +

      Specifying positional options with hyphens -

      + -
      +

      Sometimes you may want to specify a value to your positional argument that starts with a hyphen (for example, searching for '-foo' in a file). At @@ -895,10 +889,10 @@ can use it like this:

      -
      +

      Determining absolute position with getPosition() -

      -
      + +

      Sometimes an option can affect or modify the meaning of another option. For example, consider gcc's -x LANG option. This tells gcc to ignore the suffix of subsequent positional arguments and force @@ -954,11 +948,11 @@ can use it like this:

      -
      +

      The cl::ConsumeAfter modifier -

      + -
      +

      The cl::ConsumeAfter formatting option is used to construct programs that use "interpreter style" option processing. With @@ -1006,12 +1000,14 @@ href="#cl::list">cl::list option.

      +
      + -
      +

      Internal vs External Storage -

      + -
      +

      By default, all command line options automatically hold the value that they parse from the command line. This is very convenient in the common case, @@ -1076,11 +1072,11 @@ that DebugFlag is automatically set.

      -
      +

      Option Attributes -

      + -
      +

      This section describes the basic attributes that you can specify on options.

      @@ -1166,11 +1162,11 @@ obviously).
      -
      +

      Option Modifiers -

      + -
      +

      Option modifiers are the flags and expressions that you pass into the constructors for cl::opt and -

      - -
      +

      Hiding an option from -help output -

      + -
      +

      The cl::NotHidden, cl::Hidden, and cl::ReallyHidden modifiers are used to control whether or not an option @@ -1230,12 +1224,12 @@ indicates that the option should not appear in any help output.

      -
      +

      Controlling the number of occurrences required and allowed -

      + -
      +

      This group of options is used to control how many time an option is allowed (or required) to be specified on the command line of your program. Specifying a @@ -1279,11 +1273,11 @@ retained.

      -
      +

      Controlling whether or not a value must be specified -

      + -
      +

      This group of options is used to control whether or not the option allows a value to be present. In the case of the CommandLine library, a value is either @@ -1328,11 +1322,11 @@ when extending the library.

      -
      +

      Controlling other formatting options -

      + -
      +

      The formatting option group is used to specify that the command line option has special abilities and is otherwise different from other command line @@ -1409,11 +1403,11 @@ strategy basically looks like this:

      -
      +

      Miscellaneous option modifiers -

      + -
      +

      The miscellaneous option modifiers are the only flags where you can specify more than one flag from the set: they are not mutually exclusive. These flags @@ -1453,11 +1447,11 @@ only makes sense with a cl::list option.

      -
      +

      Response files -

      + -
      +

      Some systems, such as certain variants of Microsoft Windows and some older Unices have a relatively low limit on command-line @@ -1474,13 +1468,14 @@ and

      +
      -
      +

      Top-Level Classes and Functions -

      + -
      +

      Despite all of the built-in flexibility, the CommandLine option library really only consists of one function (cl::list, and cl::alias. This section describes these three classes in detail.

      -
      - -
      +

      The cl::ParseCommandLineOptions function -

      + -
      +

      The cl::ParseCommandLineOptions function is designed to be called directly from main, and is used to fill in the values of all of the @@ -1514,12 +1507,12 @@ which holds additional extra text to emit when the

      -
      +

      The cl::ParseEnvironmentOptions function -

      + -
      +

      The cl::ParseEnvironmentOptions function has mostly the same effects as

      -
      +

      The cl::SetVersionPrinter function -

      + -
      +

      The cl::SetVersionPrinter function is designed to be called directly from main and before @@ -1572,11 +1565,11 @@ called when the --version option is given by the user.

      -
      +

      The cl::opt class -

      + -
      +

      The cl::opt class is the class used to represent scalar command line options, and is the one used most of the time. It is a templated class which @@ -1607,11 +1600,11 @@ href="#customparser">custom parser.

      -
      +

      The cl::list class -

      + -
      +

      The cl::list class is the class used to represent a list of command line options. It too is a templated class which can take up to three @@ -1634,11 +1627,11 @@ be used.

      -
      +

      The cl::bits class -

      + -
      +

      The cl::bits class is the class used to represent a list of command line options in the form of a bit vector. It is also a templated class which @@ -1659,11 +1652,11 @@ must be of type unsigned if external storage is used.

      -
      +

      The cl::alias class -

      + -
      +

      The cl::alias class is a nontemplated class that is used to form aliases for other arguments.

      @@ -1682,11 +1675,11 @@ the conversion from string to data.

      -
      +

      The cl::extrahelp class -

      + -
      +

      The cl::extrahelp class is a nontemplated class that allows extra help text to be printed out for the -help option.

      @@ -1709,12 +1702,14 @@ single cl::extrahelp instance.

      +
      + -
      +

      Builtin parsers -

      + -
      +

      Parsers control how the string value taken from the command line is translated into a typed value, suitable for use in a C++ program. By default, @@ -1773,27 +1768,27 @@ exponential notation (ex: 1.7e15) and properly supports locales.

      +
      + -
      +

      Extension Guide -

      + -
      +

      Although the CommandLine library has a lot of functionality built into it already (as discussed previously), one of its true strengths lie in its extensibility. This section discusses how the CommandLine library works under the covers and illustrates how to do some simple, common, extensions.

      -
      - -
      +

      Writing a custom parser -

      + -
      +

      One of the simplest and most common extensions is the use of a custom parser. As discussed previously, parsers are the portion @@ -1932,11 +1927,11 @@ tutorial.

      -
      +

      Exploiting external storage -

      + -
      +

      Several of the LLVM libraries define static cl::opt instances that will automatically be included in any program that links with that library. This is a feature. However, sometimes it is necessary to know the value of the @@ -1951,16 +1946,18 @@ tutorial.

      -
      +

      Dynamically adding command line options -

      + -
      +

      TODO: fill in this section

      +
      +
      @@ -1971,8 +1968,8 @@ tutorial.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
      - LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/CompilerDriver.html b/docs/CompilerDriver.html index c63e1747fa69..03db3a09bde7 100644 --- a/docs/CompilerDriver.html +++ b/docs/CompilerDriver.html @@ -3,7 +3,7 @@ - + Customizing LLVMC: Reference Manual @@ -17,28 +17,23 @@ The ReST source lives in the directory 'tools/llvmc/doc'. -->

      Contents

        -
      • Introduction
        • -
      • Compiling with LLVMC
        • -
      • Predefined options
        • -
      • Compiling LLVMC plugins
        • -
      • Compiling standalone LLVMC-based drivers
        • -
      • Customizing LLVMC: the compilation graph
        • -
      • Describing options
          -
        • External options
          • +
        • Introduction
          • +
        • Compiling with llvmc
          • +
        • Predefined options
          • +
        • Compiling LLVMC-based drivers
          • +
        • Customizing LLVMC: the compilation graph
          • +
        • Describing options
          • +
        • Conditional evaluation
          • +
        • Writing a tool description
          • -
        • Conditional evaluation
          • -
        • Writing a tool description -
          • -
        • Language map
          • -
        • Option preprocessor
          • -
        • More advanced topics @@ -46,25 +41,24 @@ The ReST source lives in the directory 'tools/llvmc/doc'. -->

          Written by Mikhail Glushenkov

          -

          Introduction

          +

          Introduction

          LLVMC is a generic compiler driver, designed to be customizable and -extensible. It plays the same role for LLVM as the gcc program -does for GCC - LLVMC's job is essentially to transform a set of input -files into a set of targets depending on configuration rules and user -options. What makes LLVMC different is that these transformation rules -are completely customizable - in fact, LLVMC knows nothing about the -specifics of transformation (even the command-line options are mostly -not hard-coded) and regards the transformation structure as an -abstract graph. The structure of this graph is completely determined -by plugins, which can be either statically or dynamically linked. This -makes it possible to easily adapt LLVMC for other purposes - for -example, as a build tool for game resources.

          +extensible. It plays the same role for LLVM as the gcc program does for +GCC - LLVMC's job is essentially to transform a set of input files into a set of +targets depending on configuration rules and user options. What makes LLVMC +different is that these transformation rules are completely customizable - in +fact, LLVMC knows nothing about the specifics of transformation (even the +command-line options are mostly not hard-coded) and regards the transformation +structure as an abstract graph. The structure of this graph is described in +high-level TableGen code, from which an efficient C++ representation is +automatically derived. This makes it possible to adapt LLVMC for other +purposes - for example, as a build tool for game resources.

          Because LLVMC employs TableGen as its configuration language, you need to be familiar with it to customize LLVMC.

          -

          Compiling with LLVMC

          -

          LLVMC tries hard to be as compatible with gcc as possible, +

          Compiling with llvmc

          +

          LLVMC tries hard to be as compatible with gcc as possible, although there are some small differences. Most of the time, however, you shouldn't be able to notice them:

          @@ -74,11 +68,11 @@ $ ./a.out
 hello

          One nice feature of LLVMC is that one doesn't have to distinguish between -different compilers for different languages (think g++ vs. gcc) - the +different compilers for different languages (think g++ vs. gcc) - the right toolchain is chosen automatically based on input language names (which are, in turn, determined from file extensions). If you want to force files ending with ".c" to compile as C++, use the -x option, just like you would -do it with gcc:

          +do it with gcc:

           $ # hello.c is really a C++ file
 $ llvmc -x c++ hello.c
@@ -97,138 +91,100 @@ $ ./a.out
 hello

          By default, LLVMC uses llvm-gcc to compile the source code. It is also -possible to choose the clang compiler with the -clang option.

          +possible to choose the clang compiler with the -clang option.

          -

          Predefined options

          -

          LLVMC has some built-in options that can't be overridden in the -configuration libraries:

          +

          Predefined options

          +

          LLVMC has some built-in options that can't be overridden in the TableGen code:

            -
          • -o FILE - Output file name.
            • -
          • -x LANGUAGE - Specify the language of the following input files +
          • -o FILE - Output file name.
            • +
          • -x LANGUAGE - Specify the language of the following input files until the next -x option.
            • -
          • -load PLUGIN_NAME - Load the specified plugin DLL. Example: --load $LLVM_DIR/Release/lib/LLVMCSimple.so.
          • -v - Enable verbose mode, i.e. print out all executed commands.
          • --save-temps - Write temporary files to the current directory and do not delete them on exit. This option can also take an argument: the --save-temps=obj switch will write files into the directory specified with the -o option. The --save-temps=cwd and --save-temps switches are both synonyms for the default behaviour.
            • -
          • --temp-dir DIRECTORY - Store temporary files in the given directory. This +
          • --temp-dir DIRECTORY - Store temporary files in the given directory. This directory is deleted on exit unless --save-temps is specified. If --save-temps=obj is also specified, --temp-dir is given the precedence.
          • --check-graph - Check the compilation for common errors like mismatched -output/input language names, multiple default edges and cycles. Because of -plugins, these checks can't be performed at compile-time. Exit with code zero -if no errors were found, and return the number of found errors -otherwise. Hidden option, useful for debugging LLVMC plugins.
            • +output/input language names, multiple default edges and cycles. Exit with code +zero if no errors were found, and return the number of found errors +otherwise. Hidden option, useful for debugging.
          • --view-graph - Show a graphical representation of the compilation graph -and exit. Requires that you have dot and gv programs installed. Hidden -option, useful for debugging LLVMC plugins.
            • +and exit. Requires that you have dot and gv programs installed. Hidden +option, useful for debugging.
          • --write-graph - Write a compilation-graph.dot file in the current directory with the compilation graph description in Graphviz format (identical to the file used by the --view-graph option). The -o option can be -used to set the output file name. Hidden option, useful for debugging LLVMC -plugins.
            • -
          • -help, -help-hidden, --version - These options have +used to set the output file name. Hidden option, useful for debugging.
            • +
          • --help, --help-hidden, --version - These options have their standard meaning.
          -
          -

          Compiling LLVMC plugins

          -

          It's easiest to start working on your own LLVMC plugin by copying the -skeleton project which lives under $LLVMC_DIR/plugins/Simple:

          +
          +

          Compiling LLVMC-based drivers

          +

          It's easiest to start working on your own LLVMC driver by copying the skeleton +project which lives under $LLVMC_DIR/examples/Skeleton:

          -$ cd $LLVMC_DIR/plugins
-$ cp -r Simple MyPlugin
-$ cd MyPlugin
+$ cd $LLVMC_DIR/examples
+$ cp -r Skeleton MyDriver
+$ cd MyDriver
 $ ls
-Makefile PluginMain.cpp Simple.td
-
          -

          As you can see, our basic plugin consists of only two files (not -counting the build script). Simple.td contains TableGen -description of the compilation graph; its format is documented in the -following sections. PluginMain.cpp is just a helper file used to -compile the auto-generated C++ code produced from TableGen source. It -can also contain hook definitions (see below).

          -

          The first thing that you should do is to change the LLVMC_PLUGIN -variable in the Makefile to avoid conflicts (since this variable -is used to name the resulting library):

          -
          -LLVMC_PLUGIN=MyPlugin
+AutoGenerated.td  Hooks.cpp  Main.cpp  Makefile
          -

          It is also a good idea to rename Simple.td to something less -generic:

          +

          As you can see, our basic driver consists of only three files (not counting the +build script). AutoGenerated.td contains TableGen description of the +compilation graph; its format is documented in the following +sections. Hooks.cpp is an empty file that should be used for hook +definitions (see below). Main.cpp is just a helper used to compile the +auto-generated C++ code produced from TableGen source.

          +

          The first thing that you should do is to change the LLVMC_BASED_DRIVER +variable in the Makefile:

          -$ mv Simple.td MyPlugin.td
+LLVMC_BASED_DRIVER=MyDriver
          -

          To build your plugin as a dynamic library, just cd to its source -directory and run make. The resulting file will be called -plugin_llvmc_$(LLVMC_PLUGIN).$(DLL_EXTENSION) (in our case, -plugin_llvmc_MyPlugin.so). This library can be then loaded in with the --load option. Example:

          -
          -$ cd $LLVMC_DIR/plugins/Simple
-$ make
-$ llvmc -load $LLVM_DIR/Release/lib/plugin_llvmc_Simple.so
-
          -
          -
          -

          Compiling standalone LLVMC-based drivers

          -

          By default, the llvmc executable consists of a driver core plus several -statically linked plugins (Base and Clang at the moment). You can -produce a standalone LLVMC-based driver executable by linking the core with your -own plugins. The recommended way to do this is by starting with the provided -Skeleton example ($LLVMC_DIR/example/Skeleton):

          +

          It can also be a good idea to put your TableGen code into a file with a less +generic name:

          -$ cd $LLVMC_DIR/example/
-$ cp -r Skeleton mydriver
-$ cd mydriver
-$ vim Makefile
+$ touch MyDriver.td
+$ vim AutoGenerated.td
 [...]
-$ make
+include "MyDriver.td"
          +

          If you have more than one TableGen source file, they all should be included from +AutoGenerated.td, since this file is used by the build system to generate +C++ code.

          +

          To build your driver, just cd to its source directory and run make. The +resulting executable will be put into $LLVM_OBJ_DIR/$(BuildMode)/bin.

          If you're compiling LLVM with different source and object directories, then you -must perform the following additional steps before running make:

          +must perform the following additional steps before running make:

           # LLVMC_SRC_DIR = $LLVM_SRC_DIR/tools/llvmc/
 # LLVMC_OBJ_DIR = $LLVM_OBJ_DIR/tools/llvmc/
-$ cp $LLVMC_SRC_DIR/example/mydriver/Makefile \
-  $LLVMC_OBJ_DIR/example/mydriver/
-$ cd $LLVMC_OBJ_DIR/example/mydriver
+$ mkdir $LLVMC_OBJ_DIR/examples/MyDriver/
+$ cp $LLVMC_SRC_DIR/examples/MyDriver/Makefile \
+  $LLVMC_OBJ_DIR/examples/MyDriver/
+$ cd $LLVMC_OBJ_DIR/examples/MyDriver
 $ make
          -

          Another way to do the same thing is by using the following command:

          -
          -$ cd $LLVMC_DIR
-$ make LLVMC_BUILTIN_PLUGINS=MyPlugin LLVMC_BASED_DRIVER_NAME=mydriver
-
          -

          This works with both srcdir == objdir and srcdir != objdir, but assumes that the -plugin source directory was placed under $LLVMC_DIR/plugins.

          -

          Sometimes, you will want a 'bare-bones' version of LLVMC that has no -built-in plugins. It can be compiled with the following command:

          -
          -$ cd $LLVMC_DIR
-$ make LLVMC_BUILTIN_PLUGINS=""
-
          -

          Customizing LLVMC: the compilation graph

          -

          Each TableGen configuration file should include the common -definitions:

          +

          Customizing LLVMC: the compilation graph

          +

          Each TableGen configuration file should include the common definitions:

           include "llvm/CompilerDriver/Common.td"
          -

          Internally, LLVMC stores information about possible source -transformations in form of a graph. Nodes in this graph represent -tools, and edges between two nodes represent a transformation path. A -special "root" node is used to mark entry points for the -transformations. LLVMC also assigns a weight to each edge (more on -this later) to choose between several alternative edges.

          -

          The definition of the compilation graph (see file -plugins/Base/Base.td for an example) is just a list of edges:

          +

          Internally, LLVMC stores information about possible source transformations in +form of a graph. Nodes in this graph represent tools, and edges between two +nodes represent a transformation path. A special "root" node is used to mark +entry points for the transformations. LLVMC also assigns a weight to each edge +(more on this later) to choose between several alternative edges.

          +

          The definition of the compilation graph (see file llvmc/src/Base.td for an +example) is just a list of edges:

           def CompilationGraph : CompilationGraph<[
     Edge<"root", "llvm_gcc_c">,
@@ -253,39 +209,33 @@ def CompilationGraph : CompilationGraph<[
 
     ]>;
          -

          As you can see, the edges can be either default or optional, where -optional edges are differentiated by an additional case expression -used to calculate the weight of this edge. Notice also that we refer -to tools via their names (as strings). This makes it possible to add -edges to an existing compilation graph in plugins without having to -know about all tool definitions used in the graph.

          -

          The default edges are assigned a weight of 1, and optional edges get a -weight of 0 + 2*N where N is the number of tests that evaluated to -true in the case expression. It is also possible to provide an -integer parameter to inc_weight and dec_weight - in this case, -the weight is increased (or decreased) by the provided value instead -of the default 2. It is also possible to change the default weight of -an optional edge by using the default clause of the case +

          As you can see, the edges can be either default or optional, where optional +edges are differentiated by an additional case expression used to calculate +the weight of this edge. Notice also that we refer to tools via their names (as +strings). This makes it possible to add edges to an existing compilation graph +without having to know about all tool definitions used in the graph.

          +

          The default edges are assigned a weight of 1, and optional edges get a weight of +0 + 2*N where N is the number of tests that evaluated to true in the case +expression. It is also possible to provide an integer parameter to +inc_weight and dec_weight - in this case, the weight is increased (or +decreased) by the provided value instead of the default 2. Default weight of an +optional edge can be changed by using the default clause of the case construct.

          -

          When passing an input file through the graph, LLVMC picks the edge -with the maximum weight. To avoid ambiguity, there should be only one -default edge between two nodes (with the exception of the root node, -which gets a special treatment - there you are allowed to specify one -default edge per language).

          -

          When multiple plugins are loaded, their compilation graphs are merged -together. Since multiple edges that have the same end nodes are not -allowed (i.e. the graph is not a multigraph), an edge defined in -several plugins will be replaced by the definition from the plugin -that was loaded last. Plugin load order can be controlled by using the -plugin priority feature described above.

          -

          To get a visual representation of the compilation graph (useful for -debugging), run llvmc --view-graph. You will need dot and -gsview installed for this to work properly.

          +

          When passing an input file through the graph, LLVMC picks the edge with the +maximum weight. To avoid ambiguity, there should be only one default edge +between two nodes (with the exception of the root node, which gets a special +treatment - there you are allowed to specify one default edge per language).

          +

          When multiple compilation graphs are defined, they are merged together. Multiple +edges with the same end nodes are not allowed (i.e. the graph is not a +multigraph), and will lead to a compile-time error.

          +

          To get a visual representation of the compilation graph (useful for debugging), +run llvmc --view-graph. You will need dot and gsview installed for +this to work properly.

          -

          Describing options

          -

          Command-line options that the plugin supports are defined by using an -OptionList:

          +

          Describing options

          +

          Command-line options supported by the driver are defined by using an +OptionList:

           def Options : OptionList<[
 (switch_option "E", (help "Help string")),
@@ -293,101 +243,95 @@ def Options : OptionList<[
 ...
 ]>;
          -

          As you can see, the option list is just a list of DAGs, where each DAG -is an option description consisting of the option name and some -properties. A plugin can define more than one option list (they are -all merged together in the end), which can be handy if one wants to -separate option groups syntactically.

          +

          As you can see, the option list is just a list of DAGs, where each DAG is an +option description consisting of the option name and some properties. More than +one option list can be defined (they are all merged together in the end), which +can be handy if one wants to separate option groups syntactically.

          • Possible option types:

              -
            • switch_option - a simple boolean switch without arguments, for example --O2 or -time. At most one occurrence is allowed.
              • -
            • parameter_option - option that takes one argument, for example +
            • switch_option - a simple boolean switch without arguments, for example +-O2 or -time. At most one occurrence is allowed by default.
              • +
            • parameter_option - option that takes one argument, for example -std=c99. It is also allowed to use spaces instead of the equality -sign: -std c99. At most one occurrence is allowed.
              • -
            • parameter_list_option - same as the above, but more than one option -occurence is allowed.
              • -
            • prefix_option - same as the parameter_option, but the option name and +sign: -std c99. At most one occurrence is allowed.
              • +
            • parameter_list_option - same as the above, but more than one option +occurrence is allowed.
              • +
            • prefix_option - same as the parameter_option, but the option name and argument do not have to be separated. Example: -ofile. This can be also -specified as -o file; however, -o=file will be parsed incorrectly -(=file will be interpreted as option value). At most one occurrence is +specified as -o file; however, -o=file will be parsed incorrectly +(=file will be interpreted as option value). At most one occurrence is allowed.
              • -
            • prefix_list_option - same as the above, but more than one occurence of +
            • prefix_list_option - same as the above, but more than one occurrence of the option is allowed; example: -lm -lpthread.
              • -
            • alias_option - a special option type for creating aliases. Unlike other +
            • alias_option - a special option type for creating aliases. Unlike other option types, aliases are not allowed to have any properties besides the -aliased option name. Usage example: (alias_option "preprocess", "E")
              • +aliased option name. +Usage example: (alias_option "preprocess", "E") +
            • switch_list_option - like switch_option with the zero_or_more +property, but remembers how many times the switch was turned on. Useful +mostly for forwarding. Example: when -foo is a switch option (with the +zero_or_more property), the command driver -foo -foo is forwarded +as some-tool -foo, but when -foo is a switch list, the same command +is forwarded as some-tool -foo -foo.

          • Possible option properties:

              -
            • help - help string associated with this option. Used for -help +
            • help - help string associated with this option. Used for --help output.
              • -
            • required - this option must be specified exactly once (or, in case of -the list options without the multi_val property, at least -once). Incompatible with zero_or_one and one_or_more.
              • -
            • one_or_more - the option must be specified at least one time. Useful -only for list options in conjunction with multi_val; for ordinary lists -it is synonymous with required. Incompatible with required and -zero_or_one.
              • -
            • optional - the option can be specified zero or one times. Useful only -for list options in conjunction with multi_val. Incompatible with -required and one_or_more.
              • -
            • hidden - the description of this option will not appear in -the -help output (but will appear in the -help-hidden +
            • required - this option must be specified exactly once (or, in case of +the list options without the multi_val property, at least +once). Incompatible with optional and one_or_more.
              • +
            • optional - the option can be specified either zero times or exactly +once. The default for switch options. Useful only for list options in +conjunction with multi_val. Incompatible with required, +zero_or_more and one_or_more.
              • +
            • one_or_more - the option must be specified at least once. Can be useful +to allow switch options be both obligatory and be specified multiple +times. For list options is useful only in conjunction with multi_val; +for ordinary it is synonymous with required. Incompatible with +required, optional and zero_or_more.
              • +
            • zero_or_more - the option can be specified zero or more times. Useful +to allow a single switch option to be specified more than +once. Incompatible with required, optional and one_or_more.
              • +
            • hidden - the description of this option will not appear in +the --help output (but will appear in the --help-hidden output).
              • -
            • really_hidden - the option will not be mentioned in any help +
            • really_hidden - the option will not be mentioned in any help output.
              • -
            • comma_separated - Indicates that any commas specified for an option's +
            • comma_separated - Indicates that any commas specified for an option's value should be used to split the value up into multiple values for the option. This property is valid only for list options. In conjunction with -forward_value can be used to implement option forwarding in style of +forward_value can be used to implement option forwarding in style of gcc's -Wa,.
              • -
            • multi_val n - this option takes n arguments (can be useful in some -special cases). Usage example: (parameter_list_option "foo", (multi_val -3)); the command-line syntax is '-foo a b c'. Only list options can have -this attribute; you can, however, use the one_or_more, optional -and required properties.
              • -
            • init - this option has a default value, either a string (if it is a +
            • multi_val n - this option takes n arguments (can be useful in some +special cases). Usage example: (parameter_list_option "foo", (multi_val +3)); the command-line syntax is '-foo a b c'. Only list options can have +this attribute; you can, however, use the one_or_more, optional +and required properties.
              • +
            • init - this option has a default value, either a string (if it is a parameter), or a boolean (if it is a switch; as in C++, boolean constants -are called true and false). List options can't have init +are called true and false). List options can't have init attribute. -Usage examples: (switch_option "foo", (init true)); (prefix_option -"bar", (init "baz")).
              • -
            • extern - this option is defined in some other plugin, see below.
              • +Usage examples: (switch_option "foo", (init true)); (prefix_option +"bar", (init "baz")).
          -
          -

          External options

          -

          Sometimes, when linking several plugins together, one plugin needs to -access options defined in some other plugin. Because of the way -options are implemented, such options must be marked as -extern. This is what the extern option property is -for. Example:

          -
          -...
-(switch_option "E", (extern))
-...
-
          -

          If an external option has additional attributes besides 'extern', they are -ignored. See also the section on plugin priorities.

          -
          -

          Conditional evaluation

          -

          The 'case' construct is the main means by which programmability is -achieved in LLVMC. It can be used to calculate edge weights, program -actions and modify the shell commands to be executed. The 'case' -expression is designed after the similarly-named construct in -functional languages and takes the form (case (test_1), statement_1, -(test_2), statement_2, ... (test_N), statement_N). The statements -are evaluated only if the corresponding tests evaluate to true.

          +

          Conditional evaluation

          +

          The 'case' construct is the main means by which programmability is achieved in +LLVMC. It can be used to calculate edge weights, program actions and modify the +shell commands to be executed. The 'case' expression is designed after the +similarly-named construct in functional languages and takes the form (case +(test_1), statement_1, (test_2), statement_2, ... (test_N), statement_N). The +statements are evaluated only if the corresponding tests evaluate to true.

          Examples:

           // Edge weight calculation
@@ -410,129 +354,139 @@ are evaluated only if the corresponding tests evaluate to true.
          
     (switch_on "B"), "cmdline2",
     (default), "cmdline3")
          -

          Note the slight difference in 'case' expression handling in contexts -of edge weights and command line specification - in the second example -the value of the "B" switch is never checked when switch "A" is -enabled, and the whole expression always evaluates to "cmdline1" in -that case.

          +

          Note the slight difference in 'case' expression handling in contexts of edge +weights and command line specification - in the second example the value of the +"B" switch is never checked when switch "A" is enabled, and the whole +expression always evaluates to "cmdline1" in that case.

          Case expressions can also be nested, i.e. the following is legal:

           (case (switch_on "E"), (case (switch_on "o"), ..., (default), ...)
       (default), ...)
          -

          You should, however, try to avoid doing that because it hurts -readability. It is usually better to split tool descriptions and/or -use TableGen inheritance instead.

          +

          You should, however, try to avoid doing that because it hurts readability. It is +usually better to split tool descriptions and/or use TableGen inheritance +instead.

          • Possible tests are:
              -
            • switch_on - Returns true if a given command-line switch is provided by -the user. Can be given a list as argument, in that case (switch_on ["foo", -"bar", "baz"]) is equivalent to (and (switch_on "foo"), (switch_on -"bar"), (switch_on "baz")). -Example: (switch_on "opt").
              • -
            • any_switch_on - Given a list of switch options, returns true if any of +
            • switch_on - Returns true if a given command-line switch is provided by +the user. Can be given multiple arguments, in that case (switch_on "foo", +"bar", "baz") is equivalent to (and (switch_on "foo"), (switch_on +"bar"), (switch_on "baz")). +Example: (switch_on "opt").
              • +
            • any_switch_on - Given a number of switch options, returns true if any of the switches is turned on. -Example: (any_switch_on ["foo", "bar", "baz"]) is equivalent to (or -(switch_on "foo"), (switch_on "bar"), (switch_on "baz")).
              • -
            • parameter_equals - Returns true if a command-line parameter equals -a given value. -Example: (parameter_equals "W", "all").
              • -
            • element_in_list - Returns true if a command-line parameter -list contains a given value. -Example: (element_in_list "l", "pthread").
              • -
            • input_languages_contain - Returns true if a given language +Example: (any_switch_on "foo", "bar", "baz") is equivalent to (or +(switch_on "foo"), (switch_on "bar"), (switch_on "baz")).
              • +
            • parameter_equals - Returns true if a command-line parameter (first +argument) equals a given value (second argument). +Example: (parameter_equals "W", "all").
              • +
            • element_in_list - Returns true if a command-line parameter list (first +argument) contains a given value (second argument). +Example: (element_in_list "l", "pthread").
              • +
            • input_languages_contain - Returns true if a given language belongs to the current input language set. -Example: (input_languages_contain "c++").
              • -
            • in_language - Evaluates to true if the input file language is equal to -the argument. At the moment works only with cmd_line and actions (on +Example: (input_languages_contain "c++").
              • +
            • in_language - Evaluates to true if the input file language is equal to +the argument. At the moment works only with command and actions (on non-join nodes). -Example: (in_language "c++").
              • -
            • not_empty - Returns true if a given option (which should be either a -parameter or a parameter list) is set by the user. Like switch_on, can -be also given a list as argument. -Example: (not_empty "o").
              • -
            • any_not_empty - Returns true if not_empty returns true for any of -the options in the list. -Example: (any_not_empty ["foo", "bar", "baz"]) is equivalent to (or -(not_empty "foo"), (not_empty "bar"), (not_empty "baz")).
              • -
            • empty - The opposite of not_empty. Equivalent to (not (not_empty -X)). Provided for convenience. Can be given a list as argument.
              • -
            • any_not_empty - Returns true if not_empty returns true for any of -the options in the list. -Example: (any_empty ["foo", "bar", "baz"]) is equivalent to (not (and -(not_empty "foo"), (not_empty "bar"), (not_empty "baz"))).
              • -
            • single_input_file - Returns true if there was only one input file +Example: (in_language "c++").
              • +
            • not_empty - Returns true if a given option (which should be either a +parameter or a parameter list) is set by the user. Like switch_on, can +be also given multiple arguments. +Examples: (not_empty "o"), (not_empty "o", "l").
              • +
            • any_not_empty - Returns true if not_empty returns true for any of +the provided options. +Example: (any_not_empty "foo", "bar", "baz") is equivalent to (or +(not_empty "foo"), (not_empty "bar"), (not_empty "baz")).
              • +
            • empty - The opposite of not_empty. Equivalent to (not (not_empty +X)). Can be given multiple arguments.
              • +
            • any_not_empty - Returns true if not_empty returns true for any of +the provided options. +Example: (any_empty "foo", "bar", "baz") is equivalent to (or +(not_empty "foo"), (not_empty "bar"), (not_empty "baz")).
              • +
            • single_input_file - Returns true if there was only one input file provided on the command-line. Used without arguments: -(single_input_file).
              • -
            • multiple_input_files - Equivalent to (not (single_input_file)) (the +(single_input_file).
              • +
            • multiple_input_files - Equivalent to (not (single_input_file)) (the case of zero input files is considered an error).
              • -
            • default - Always evaluates to true. Should always be the last -test in the case expression.
              • -
            • and - A standard binary logical combinator that returns true iff all of -its arguments return true. Used like this: (and (test1), (test2), -... (testN)). Nesting of and and or is allowed, but not +
            • default - Always evaluates to true. Should always be the last +test in the case expression.
              • +
            • and - A standard logical combinator that returns true iff all of +its arguments return true. Used like this: (and (test1), (test2), +... (testN)). Nesting of and and or is allowed, but not encouraged.
              • -
            • or - A binary logical combinator that returns true iff any of its -arguments returns true. Example: (or (test1), (test2), ... (testN)).
              • -
            • not - Standard unary logical combinator that negates its -argument. Example: (not (or (test1), (test2), ... (testN))).
              • +
            • or - A logical combinator that returns true iff any of its arguments +return true. +Example: (or (test1), (test2), ... (testN)).
              • +
            • not - Standard unary logical combinator that negates its +argument. +Example: (not (or (test1), (test2), ... (testN))).
          -

          Writing a tool description

          -

          As was said earlier, nodes in the compilation graph represent tools, -which are described separately. A tool definition looks like this -(taken from the include/llvm/CompilerDriver/Tools.td file):

          +

          Writing a tool description

          +

          As was said earlier, nodes in the compilation graph represent tools, which are +described separately. A tool definition looks like this (taken from the +llvmc/src/Base.td file):

           def llvm_gcc_cpp : Tool<[
     (in_language "c++"),
     (out_language "llvm-assembler"),
     (output_suffix "bc"),
-    (cmd_line "llvm-g++ -c $INFILE -o $OUTFILE -emit-llvm"),
+    (command "llvm-g++ -c -emit-llvm"),
     (sink)
     ]>;
          -

          This defines a new tool called llvm_gcc_cpp, which is an alias for -llvm-g++. As you can see, a tool definition is just a list of -properties; most of them should be self-explanatory. The sink -property means that this tool should be passed all command-line -options that aren't mentioned in the option list.

          +

          This defines a new tool called llvm_gcc_cpp, which is an alias for +llvm-g++. As you can see, a tool definition is just a list of properties; +most of them should be self-explanatory. The sink property means that this +tool should be passed all command-line options that aren't mentioned in the +option list.

          The complete list of all currently implemented tool properties follows.

          • Possible tool properties:
              -
            • in_language - input language name. Can be either a string or a -list, in case the tool supports multiple input languages.
              • -
            • out_language - output language name. Multiple output languages are not -allowed.
              • -
            • output_suffix - output file suffix. Can also be changed -dynamically, see documentation on actions.
              • -
            • cmd_line - the actual command used to run the tool. You can -use $INFILE and $OUTFILE variables, output redirection -with >, hook invocations ($CALL), environment variables -(via $ENV) and the case construct.
              • -
            • join - this tool is a "join node" in the graph, i.e. it gets a -list of input files and joins them together. Used for linkers.
              • -
            • sink - all command-line options that are not handled by other -tools are passed to this tool.
              • -
            • actions - A single big case expression that specifies how -this tool reacts on command-line options (described in more detail -below).
              • +
            • in_language - input language name. Can be given multiple arguments, in +case the tool supports multiple input languages. Used for typechecking and +mapping file extensions to tools.
              • +
            • out_language - output language name. Multiple output languages are +allowed. Used for typechecking the compilation graph.
              • +
            • output_suffix - output file suffix. Can also be changed dynamically, see +documentation on actions.
          -
          -

          Actions

          -

          A tool often needs to react to command-line options, and this is -precisely what the actions property is for. The next example -illustrates this feature:

          +
          +
            +
          • command - the actual command used to run the tool. You can use output +redirection with >, hook invocations ($CALL), environment variables +(via $ENV) and the case construct.
            • +
          • join - this tool is a "join node" in the graph, i.e. it gets a list of +input files and joins them together. Used for linkers.
            • +
          • sink - all command-line options that are not handled by other tools are +passed to this tool.
            • +
          • actions - A single big case expression that specifies how this tool +reacts on command-line options (described in more detail below).
            • +
          +
          +
          +
            +
          • out_file_option, in_file_option - Options appended to the +command string to designate output and input files. Default values are +"-o" and "", respectively.
            • +
          +
          +
          +

          Actions

          +

          A tool often needs to react to command-line options, and this is precisely what +the actions property is for. The next example illustrates this feature:

           def llvm_gcc_linker : Tool<[
     (in_language "object-code"),
     (out_language "executable"),
     (output_suffix "out"),
-    (cmd_line "llvm-gcc $INFILE -o $OUTFILE"),
+    (command "llvm-gcc"),
     (join),
     (actions (case (not_empty "L"), (forward "L"),
                    (not_empty "l"), (forward "l"),
@@ -540,47 +494,46 @@ def llvm_gcc_linker : Tool<[
                              [(append_cmd "-dummy1"), (append_cmd "-dummy2")])
     ]>;
          -

          The actions tool property is implemented on top of the omnipresent -case expression. It associates one or more different actions -with given conditions - in the example, the actions are forward, -which forwards a given option unchanged, and append_cmd, which -appends a given string to the tool execution command. Multiple actions -can be associated with a single condition by using a list of actions -(used in the example to append some dummy options). The same case -construct can also be used in the cmd_line property to modify the -tool command line.

          -

          The "join" property used in the example means that this tool behaves -like a linker.

          +

          The actions tool property is implemented on top of the omnipresent case +expression. It associates one or more different actions with given +conditions - in the example, the actions are forward, which forwards a given +option unchanged, and append_cmd, which appends a given string to the tool +execution command. Multiple actions can be associated with a single condition by +using a list of actions (used in the example to append some dummy options). The +same case construct can also be used in the cmd_line property to modify +the tool command line.

          +

          The "join" property used in the example means that this tool behaves like a +linker.

          The list of all possible actions follows.

          • Possible actions:

              -
            • append_cmd - Append a string to the tool invocation command. -Example: (case (switch_on "pthread"), (append_cmd "-lpthread")).
              • -
            • error - Exit with error. -Example: (error "Mixing -c and -S is not allowed!").
              • -
            • warning - Print a warning. -Example: (warning "Specifying both -O1 and -O2 is meaningless!").
              • -
            • forward - Forward the option unchanged. -Example: (forward "Wall").
              • -
            • forward_as - Change the option's name, but forward the argument +
            • append_cmd - Append a string to the tool invocation command. +Example: (case (switch_on "pthread"), (append_cmd "-lpthread")).
              • +
            • error - Exit with error. +Example: (error "Mixing -c and -S is not allowed!").
              • +
            • warning - Print a warning. +Example: (warning "Specifying both -O1 and -O2 is meaningless!").
              • +
            • forward - Forward the option unchanged. +Example: (forward "Wall").
              • +
            • forward_as - Change the option's name, but forward the argument unchanged. -Example: (forward_as "O0", "--disable-optimization").
              • -
            • forward_value - Forward only option's value. Cannot be used with switch +Example: (forward_as "O0", "--disable-optimization").
              • +
            • forward_value - Forward only option's value. Cannot be used with switch options (since they don't have values), but works fine with lists. -Example: (forward_value "Wa,").
              • -
            • forward_transformed_value - As above, but applies a hook to the +Example: (forward_value "Wa,").
              • +
            • forward_transformed_value - As above, but applies a hook to the option's value before forwarding (see below). When -forward_transformed_value is applied to a list +forward_transformed_value is applied to a list option, the hook must have signature -std::string hooks::HookName (const std::vector<std::string>&). -Example: (forward_transformed_value "m", "ConvertToMAttr").
              • -
            • output_suffix - Modify the output suffix of this tool. -Example: (output_suffix "i").
              • -
            • stop_compilation - Stop compilation after this tool processes its +std::string hooks::HookName (const std::vector<std::string>&). +Example: (forward_transformed_value "m", "ConvertToMAttr").
              • +
            • output_suffix - Modify the output suffix of this tool. +Example: (output_suffix "i").
              • +
            • stop_compilation - Stop compilation after this tool processes its input. Used without arguments. -Example: (stop_compilation).
              • +Example: (stop_compilation).
            • @@ -588,11 +541,11 @@ Example: (stop_compilation)
          -

          Language map

          -

          If you are adding support for a new language to LLVMC, you'll need to -modify the language map, which defines mappings from file extensions -to language names. It is used to choose the proper toolchain(s) for a -given input file set. Language map definition looks like this:

          +

          Language map

          +

          If you are adding support for a new language to LLVMC, you'll need to modify the +language map, which defines mappings from file extensions to language names. It +is used to choose the proper toolchain(s) for a given input file set. Language +map definition looks like this:

           def LanguageMap : LanguageMap<
     [LangToSuffixes<"c++", ["cc", "cp", "cxx", "cpp", "CPP", "c++", "C"]>,
@@ -606,73 +559,69 @@ $ llvmc hello.cpp
 llvmc: Unknown suffix: cpp

          The language map entries are needed only for the tools that are linked from the -root node. Since a tool can't have multiple output languages, for inner nodes of -the graph the input and output languages should match. This is enforced at -compile-time.

          +root node. A tool can have multiple output languages.

          -

          Option preprocessor

          +

          Option preprocessor

          It is sometimes useful to run error-checking code before processing the compilation graph. For example, if optimization options "-O1" and "-O2" are implemented as switches, we might want to output a warning if the user invokes the driver with both of these options enabled.

          -

          The OptionPreprocessor feature is reserved specially for these -occasions. Example (adapted from the built-in Base plugin):

          +

          The OptionPreprocessor feature is reserved specially for these +occasions. Example (adapted from llvm/src/Base.td.in):

           def Preprocess : OptionPreprocessor<
-(case (not (any_switch_on ["O0", "O1", "O2", "O3"])),
+(case (not (any_switch_on "O0", "O1", "O2", "O3")),
            (set_option "O2"),
-      (and (switch_on "O3"), (any_switch_on ["O0", "O1", "O2"])),
-           (unset_option ["O0", "O1", "O2"]),
-      (and (switch_on "O2"), (any_switch_on ["O0", "O1"])),
-           (unset_option ["O0", "O1"]),
+      (and (switch_on "O3"), (any_switch_on "O0", "O1", "O2")),
+           (unset_option "O0", "O1", "O2"),
+      (and (switch_on "O2"), (any_switch_on "O0", "O1")),
+           (unset_option "O0", "O1"),
       (and (switch_on "O1"), (switch_on "O0")),
            (unset_option "O0"))
 >;
          -

          Here, OptionPreprocessor is used to unset all spurious -O options so +

          Here, OptionPreprocessor is used to unset all spurious -O options so that they are not forwarded to the compiler. If no optimization options are specified, -O2 is enabled.

          -

          OptionPreprocessor is basically a single big case expression, which is -evaluated only once right after the plugin is loaded. The only allowed actions -in OptionPreprocessor are error, warning, and two special actions: -unset_option and set_option. As their names suggest, they can be used to -set or unset a given option. To set an option with set_option, use the -two-argument form: (set_option "parameter", VALUE). Here, VALUE can be +

          OptionPreprocessor is basically a single big case expression, which is +evaluated only once right after the driver is started. The only allowed actions +in OptionPreprocessor are error, warning, and two special actions: +unset_option and set_option. As their names suggest, they can be used to +set or unset a given option. To set an option with set_option, use the +two-argument form: (set_option "parameter", VALUE). Here, VALUE can be either a string, a string list, or a boolean constant.

          -

          For convenience, set_option and unset_option also work on lists. That -is, instead of [(unset_option "A"), (unset_option "B")] you can use -(unset_option ["A", "B"]). Obviously, (set_option ["A", "B"]) is valid -only if both A and B are switches.

          +

          For convenience, set_option and unset_option also work with multiple +arguments. That is, instead of [(unset_option "A"), (unset_option "B")] you +can use (unset_option "A", "B"). Obviously, (set_option "A", "B") is +only valid if both A and B are switches.

          -

          More advanced topics

          +

          More advanced topics

          -

          Hooks and environment variables

          -

          Normally, LLVMC executes programs from the system PATH. Sometimes, -this is not sufficient: for example, we may want to specify tool paths -or names in the configuration file. This can be easily achieved via -the hooks mechanism. To write your own hooks, just add their -definitions to the PluginMain.cpp or drop a .cpp file into the -your plugin directory. Hooks should live in the hooks namespace -and have the signature std::string hooks::MyHookName ([const char* -Arg0 [ const char* Arg2 [, ...]]]). They can be used from the -cmd_line tool property:

          +

          Hooks and environment variables

          +

          Normally, LLVMC searches for programs in the system PATH. Sometimes, this is +not sufficient: for example, we may want to specify tool paths or names in the +configuration file. This can be achieved via the hooks mechanism. To write your +own hooks, add their definitions to the Hooks.cpp or drop a .cpp file +into your driver directory. Hooks should live in the hooks namespace and +have the signature std::string hooks::MyHookName ([const char* Arg0 [ const +char* Arg2 [, ...]]]). They can be used from the command tool property:

          -(cmd_line "$CALL(MyHook)/path/to/file -o $CALL(AnotherHook)")
+(command "$CALL(MyHook)/path/to/file -o $CALL(AnotherHook)")

          To pass arguments to hooks, use the following syntax:

          -(cmd_line "$CALL(MyHook, 'Arg1', 'Arg2', 'Arg # 3')/path/to/file -o1 -o2")
+(command "$CALL(MyHook, 'Arg1', 'Arg2', 'Arg # 3')/path/to/file -o1 -o2")

          It is also possible to use environment variables in the same manner:

          -(cmd_line "$ENV(VAR1)/path/to/file -o $ENV(VAR2)")
+(command "$ENV(VAR1)/path/to/file -o $ENV(VAR2)")

          To change the command line string based on user-provided options use -the case expression (documented above):

          +the case expression (documented above):

          -(cmd_line
+(command
   (case
     (switch_on "E"),
        "llvm-g++ -E -x c $INFILE -o $OUTFILE",
@@ -680,41 +629,23 @@ the case expression (
        "llvm-g++ -c -x c $INFILE -o $OUTFILE -emit-llvm"))
          -
          -

          How plugins are loaded

          -

          It is possible for LLVMC plugins to depend on each other. For example, -one can create edges between nodes defined in some other plugin. To -make this work, however, that plugin should be loaded first. To -achieve this, the concept of plugin priority was introduced. By -default, every plugin has priority zero; to specify the priority -explicitly, put the following line in your plugin's TableGen file:

          -
          -def Priority : PluginPriority<$PRIORITY_VALUE>;
-# Where PRIORITY_VALUE is some integer > 0
-
          -

          Plugins are loaded in order of their (increasing) priority, starting -with 0. Therefore, the plugin with the highest priority value will be -loaded last.

          -
          -

          Debugging

          -

          When writing LLVMC plugins, it can be useful to get a visual view of -the resulting compilation graph. This can be achieved via the command -line option --view-graph. This command assumes that Graphviz and -Ghostview are installed. There is also a --write-graph option that -creates a Graphviz source file (compilation-graph.dot) in the -current directory.

          -

          Another useful llvmc option is --check-graph. It checks the -compilation graph for common errors like mismatched output/input -language names, multiple default edges and cycles. These checks can't -be performed at compile-time because the plugins can load code -dynamically. When invoked with --check-graph, llvmc doesn't -perform any compilation tasks and returns the number of encountered -errors as its status code.

          +

          Debugging

          +

          When writing LLVMC-based drivers, it can be useful to get a visual view of the +resulting compilation graph. This can be achieved via the command line option +--view-graph (which assumes that Graphviz and Ghostview are +installed). There is also a --write-graph option that creates a Graphviz +source file (compilation-graph.dot) in the current directory.

          +

          Another useful llvmc option is --check-graph. It checks the compilation +graph for common errors like mismatched output/input language names, multiple +default edges and cycles. When invoked with --check-graph, llvmc doesn't +perform any compilation tasks and returns the number of encountered errors as +its status code. In the future, these checks will be performed at compile-time +and this option will disappear.

          -

          Conditioning on the executable name

          -

          For now, the executable name (the value passed to the driver in argv[0]) is +

          Conditioning on the executable name

          +

          For now, the executable name (the value passed to the driver in argv[0]) is accessible only in the C++ code (i.e. hooks). Use the following code:

           namespace llvmc {
@@ -734,8 +665,8 @@ if (strcmp(ProgramName, "mydriver") == 0) {

          In general, you're encouraged not to make the behaviour dependent on the executable file name, and use command-line switches instead. See for example how -the Base plugin behaves when it needs to choose the correct linker options -(think g++ vs. gcc).

          +the llvmc program behaves when it needs to choose the correct linker options +(think g++ vs. gcc).

          @@ -748,7 +679,7 @@ the Base plugin behav Mikhail Glushenkov
          LLVM Compiler Infrastructure
          -Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ +Last modified: $Date: 2011-04-24 16:17:37 +0200 (Sun, 24 Apr 2011) $
          diff --git a/docs/CompilerDriverTutorial.html b/docs/CompilerDriverTutorial.html index 317b1d127127..4ed373aa160a 100644 --- a/docs/CompilerDriverTutorial.html +++ b/docs/CompilerDriverTutorial.html @@ -3,7 +3,7 @@ - + Tutorial - Using LLVMC @@ -18,7 +18,7 @@ The ReST source lives in the directory 'tools/llvmc/doc'. -->

          Contents

          @@ -26,51 +26,47 @@ The ReST source lives in the directory 'tools/llvmc/doc'. -->

          Written by Mikhail Glushenkov

          Introduction

          -

          LLVMC is a generic compiler driver, which plays the same role for LLVM -as the gcc program does for GCC - the difference being that LLVMC -is designed to be more adaptable and easier to customize. Most of -LLVMC functionality is implemented via plugins, which can be loaded -dynamically or compiled in. This tutorial describes the basic usage -and configuration of LLVMC.

          +

          LLVMC is a generic compiler driver, which plays the same role for LLVM as the +gcc program does for GCC - the difference being that LLVMC is designed to be +more adaptable and easier to customize. Most of LLVMC functionality is +implemented via high-level TableGen code, from which a corresponding C++ source +file is automatically generated. This tutorial describes the basic usage and +configuration of LLVMC.

          -
          -

          Compiling with LLVMC

          -

          In general, LLVMC tries to be command-line compatible with gcc as -much as possible, so most of the familiar options work:

          +
          +

          Using the llvmc program

          +

          In general, llvmc tries to be command-line compatible with gcc as much +as possible, so most of the familiar options work:

           $ llvmc -O3 -Wall hello.cpp
 $ ./a.out
 hello
          -

          This will invoke llvm-g++ under the hood (you can see which -commands are executed by using the -v option). For further help on -command-line LLVMC usage, refer to the llvmc --help output.

          +

          This will invoke llvm-g++ under the hood (you can see which commands are +executed by using the -v option). For further help on command-line LLVMC +usage, refer to the llvmc --help output.

          Using LLVMC to generate toolchain drivers

          -

          LLVMC plugins are written mostly using TableGen, so you need to -be familiar with it to get anything done.

          -

          Start by compiling example/Simple, which is a primitive wrapper for -gcc:

          +

          LLVMC-based drivers are written mostly using TableGen, so you need to be +familiar with it to get anything done.

          +

          Start by compiling example/Simple, which is a primitive wrapper for +gcc:

          -$ cd $LLVM_DIR/tools/llvmc
-$ cp -r example/Simple plugins/Simple
-
-  # NB: A less verbose way to compile standalone LLVMC-based drivers is
-  # described in the reference manual.
-
-$ make LLVMC_BASED_DRIVER_NAME=mygcc LLVMC_BUILTIN_PLUGINS=Simple
+$ cd $LLVM_OBJ_DIR/tools/examples/Simple
+$ make
 $ cat > hello.c
-[...]
-$ mygcc hello.c
+#include <stdio.h>
+int main() { printf("Hello\n"); }
+$ $LLVM_BIN_DIR/Simple -v hello.c
+gcc hello.c -o hello.out
 $ ./hello.out
 Hello
          -

          Here we link our plugin with the LLVMC core statically to form an executable -file called mygcc. It is also possible to build our plugin as a dynamic -library to be loaded by the llvmc executable (or any other LLVMC-based -standalone driver); this is described in the reference manual.

          -

          Contents of the file Simple.td look like this:

          +

          We have thus produced a simple driver called, appropriately, Simple, from +the input TableGen file Simple.td. The llvmc program itself is generated +using a similar process (see llvmc/src). Contents of the file Simple.td +look like this:

           // Include common definitions
 include "llvm/CompilerDriver/Common.td"
@@ -80,33 +76,36 @@ def gcc : Tool<
 [(in_language "c"),
  (out_language "executable"),
  (output_suffix "out"),
- (cmd_line "gcc $INFILE -o $OUTFILE"),
- (sink)
+ (command "gcc"),
+ (sink),
+
+ // -o is what is used by default, out_file_option here is included for
+ // instructive purposes.
+ (out_file_option "-o")
 ]>;
 
 // Language map
-def LanguageMap : LanguageMap<[LangToSuffixes<"c", ["c"]>]>;
+def LanguageMap : LanguageMap<[(lang_to_suffixes "c", "c")]>;
 
 // Compilation graph
-def CompilationGraph : CompilationGraph<[Edge<"root", "gcc">]>;
+def CompilationGraph : CompilationGraph<[(edge "root", "gcc")]>;
          -

          As you can see, this file consists of three parts: tool descriptions, -language map, and the compilation graph definition.

          -

          At the heart of LLVMC is the idea of a compilation graph: vertices in -this graph are tools, and edges represent a transformation path -between two tools (for example, assembly source produced by the -compiler can be transformed into executable code by an assembler). The -compilation graph is basically a list of edges; a special node named -root is used to mark graph entry points.

          -

          Tool descriptions are represented as property lists: most properties -in the example above should be self-explanatory; the sink property -means that all options lacking an explicit description should be -forwarded to this tool.

          -

          The LanguageMap associates a language name with a list of suffixes -and is used for deciding which toolchain corresponds to a given input -file.

          -

          To learn more about LLVMC customization, refer to the reference -manual and plugin source code in the plugins directory.

          +

          As you can see, this file consists of three parts: tool descriptions, language +map, and the compilation graph definition.

          +

          At the heart of LLVMC is the idea of a compilation graph: vertices in this graph +are tools, and edges represent a transformation path between two tools (for +example, assembly source produced by the compiler can be transformed into +executable code by an assembler). The compilation graph is basically a list of +edges; a special node named root is used to mark graph entry points.

          +

          Tool descriptions are represented as property lists: most properties in the +example above should be self-explanatory; the sink property means that all +options lacking an explicit description should be forwarded to this tool.

          +

          The LanguageMap associates a language name with a list of suffixes and is +used for deciding which toolchain corresponds to a given input file.

          +

          To learn more about writing your own drivers with LLVMC, refer to the reference +manual and examples in the examples directory. Of a particular interest is +the Skeleton example, which can serve as a template for your LLVMC-based +drivers.

          diff --git a/docs/CompilerWriterInfo.html b/docs/CompilerWriterInfo.html index 6cd9d7df509d..ed326b30eb6d 100644 --- a/docs/CompilerWriterInfo.html +++ b/docs/CompilerWriterInfo.html @@ -9,9 +9,9 @@ -
          +

          Architecture/platform information for compiler writers -

          +

          Note: This document is a work-in-progress. Additions and clarifications @@ -43,13 +43,15 @@

          -
          Hardware
          +

          Hardware

          +
          + -
          Alpha
          +

          Alpha

          -
          +
          • Alpha manuals @@ -58,9 +60,9 @@ href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-libra
          -
          ARM
          +

          ARM

          -
          + -
          Itanium (ia64)
          +

          Itanium (ia64)

          -
          +
          • Itanium documentation @@ -81,9 +83,9 @@ href="http://developer.intel.com/design/itanium2/documentation.htm">Itanium docu
          -
          MIPS
          +

          MIPS

          -
          + -
          PowerPC
          +

          PowerPC

          + +
          -
          IBM - Official manuals and docs
          +

          IBM - Official manuals and docs

          -
          + -
          Other documents, collections, notes
          +

          Other documents, collections, notes

          -
          +
          +
          + -
          SPARC
          +

          SPARC

          -
          +
          • SPARC resources
            • @@ -156,12 +162,14 @@ branch stubs for powerpc64-linux (from binutils)
          -
          X86
          +

          X86

          + +
          -
          AMD - Official manuals and docs
          +

          AMD - Official manuals and docs

          -
          +
          • AMD processor manuals
            • @@ -170,9 +178,9 @@ href="http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.ht
          -
          Intel - Official manuals and docs
          +

          Intel - Official manuals and docs

          -
          + -
          Other x86-specific information
          +

          Other x86-specific information

          -
          + +
          + -
          Other relevant lists
          +

          Other relevant lists

          -
          +
          • GCC reading list
            • @@ -204,14 +214,18 @@ conventions for different C++ compilers and operating systems
          +
          + -
          ABI
          +

          ABI

          +
          + -
          Linux
          +

          Linux

          -
          +
          1. PowerPC 64-bit ELF ABI Supplement
            2. @@ -219,9 +233,9 @@ Supplement
          -
          OS X
          +

          OS X

          -
          + +
          + -
          Miscellaneous resources
          +

          Miscellaneous resources

          diff --git a/docs/DebuggingJITedCode.html b/docs/DebuggingJITedCode.html index a9193f2f9590..fa15633fddbf 100644 --- a/docs/DebuggingJITedCode.html +++ b/docs/DebuggingJITedCode.html @@ -7,7 +7,7 @@ -
          Debugging JITed Code With GDB
          +

          Debugging JITed Code With GDB

          1. Example usage
          2. Background
            3. @@ -15,9 +15,9 @@
            Written by Reid Kleckner
            -
            Example usage
            +

            Example usage

            -
            +

            In order to debug code JITed by LLVM, you need GDB 7.0 or newer, which is available on most modern distributions of Linux. The version of GDB that Apple @@ -96,9 +96,9 @@ function names.

            -
            Background
            +

            Background

            -
            +

            Without special runtime support, debugging dynamically generated code with GDB (as well as most debuggers) can be quite painful. Debuggers generally read @@ -145,8 +145,8 @@ coordinate with GDB to get better debug information. Valid HTML 4.01 Reid Kleckner
            - The LLVM Compiler Infrastructure
            - Last modified: $Date: 2010-07-07 22:16:45 +0200 (Wed, 07 Jul 2010) $ + The LLVM Compiler Infrastructure
            + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/DeveloperPolicy.html b/docs/DeveloperPolicy.html index ef99ebc9d412..c12165750668 100644 --- a/docs/DeveloperPolicy.html +++ b/docs/DeveloperPolicy.html @@ -8,7 +8,7 @@ -

            LLVM Developer Policy
            +

            LLVM Developer Policy

            1. Introduction
            2. Developer Policies @@ -34,9 +34,9 @@
              Written by the LLVM Oversight Team
              -
              Introduction
              +

              Introduction

              -
              +

              This document contains the LLVM Developer Policy which defines the project's policy towards developers and their contributions. The intent of this policy is to eliminate miscommunication, rework, and confusion that might arise from @@ -63,20 +63,19 @@

              -
              Developer Policies
              +

              Developer Policies

              -
              +

              This section contains policies that pertain to frequent LLVM developers. We always welcome one-off patches from people who do not routinely contribute to LLVM, but we expect more from frequent contributors to keep the system as efficient as possible for everyone. Frequent LLVM contributors are expected to meet the following requirements in order for LLVM to maintain a high standard of quality.

              -

              -
              Stay Informed
              -
              +

              Stay Informed

              +

              Developers should stay informed by reading at least the "dev" mailing list for the projects you are interested in, such as llvmdev for @@ -102,9 +101,9 @@

              -
              Making a Patch
              +

              Making a Patch

              -
              +

              When making a patch for review, the goal is to make it as easy for the reviewer to read it as possible. As such, we recommend that you:

              @@ -142,8 +141,8 @@
              -
              Code Reviews
              -
              +

              Code Reviews

              +

              LLVM has a code review policy. Code review is one way to increase the quality of software. We generally follow these policies:

              @@ -174,8 +173,8 @@
              -
              Code Owners
              -
              +

              Code Owners

              +

              The LLVM Project relies on two features of its process to maintain rapid development in addition to the high quality of its source base: the @@ -225,8 +224,8 @@

              -
              Test Cases
              -
              +

              Test Cases

              +

              Developers are required to create test cases for any bugs fixed and any new features added. Some tips for getting your testcase approved:

              @@ -258,8 +257,8 @@
              -
              Quality
              -
              +

              Quality

              +

              The minimum quality standards that any change must satisfy before being committed to the main development branch are:

              @@ -318,9 +317,8 @@
              -
              - Obtaining Commit Access
              -
              +

              Obtaining Commit Access

              +

              We grant commit access to contributors with a track record of submitting high quality patches. If you would like commit access, please send an email to @@ -381,8 +379,8 @@

              -
              Making a Major Change
              -
              +

              Making a Major Change

              +

              When a developer begins a major new project with the aim of contributing it back to LLVM, s/he should inform the community with an email to the llvmdev @@ -410,9 +408,8 @@

              -
              Incremental Development -
              -
              +

              Incremental Development

              +

              In the LLVM project, we do all significant changes as a series of incremental patches. We have a strong dislike for huge changes or long-term development branches. Long-term development branches have a number of drawbacks:

              @@ -472,9 +469,8 @@
              -
              Attribution of -Changes
              -
              +

              Attribution of Changes

              +

              We believe in correct attribution of contributions to their contributors. However, we do not want the source code to be littered with random attributions "this code written by J. Random Hacker" (this is noisy and @@ -486,13 +482,15 @@ Changes

              Overall, please do not add contributor names to the source code.

              +
              + -
              +

              Copyright, License, and Patents -

              + -
              +

              This section addresses the issues of copyright, license and patents for the LLVM project. Currently, the University of Illinois is the LLVM copyright holder and the terms of its license to LLVM users and developers is the @@ -504,11 +502,10 @@ Changes

              legal matters but does not provide legal advice. We are not lawyers, please seek legal counsel from an attorney.

              -
              -
              Copyright
              -
              +

              Copyright

              +

              The LLVM project does not require copyright assignments, which means that the copyright for the code in the project is held by its respective contributors @@ -530,8 +527,8 @@ Changes

              -
              License
              -
              +

              License

              +

              We intend to keep LLVM perpetually open source and to use a liberal open source license. All of the code in LLVM is available under the University of @@ -585,8 +582,8 @@ Changes

              -
              Patents
              -
              +

              Patents

              +

              To the best of our knowledge, LLVM does not infringe on any patents (we have actually removed code from LLVM in the past that was found to infringe). Having code in LLVM that infringes on patents would violate an important goal @@ -602,6 +599,8 @@ Changes

              details.

              +
              +
              @@ -611,8 +610,8 @@ Changes
              src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Written by the LLVM Oversight Group
              - The LLVM Compiler Infrastructure
              - Last modified: $Date: 2010-11-16 22:32:53 +0100 (Tue, 16 Nov 2010) $ + The LLVM Compiler Infrastructure
              + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/ExceptionHandling.html b/docs/ExceptionHandling.html index 009dbb5abd53..16820f3b045b 100644 --- a/docs/ExceptionHandling.html +++ b/docs/ExceptionHandling.html @@ -11,7 +11,7 @@ -
              Exception Handling in LLVM
              +

              Exception Handling in LLVM

              @@ -58,10 +58,10 @@ -
              Introduction
              +

              Introduction

              -
              +

              This document is the central repository for all information pertaining to exception handling in LLVM. It describes the format that LLVM exception @@ -70,14 +70,12 @@ provides specific examples of what exception handling information is used for in C/C++.

              -
              - -
              +

              Itanium ABI Zero-cost Exception Handling -

              + -
              +

              Exception handling for most programming languages is designed to recover from conditions that rarely occur during general use of an application. To that @@ -106,11 +104,11 @@

              -
              +

              Setjmp/Longjmp Exception Handling -

              + -
              +

              Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics llvm.eh.sjlj.setjmp and @@ -138,11 +136,11 @@

              -
              +

              Overview -

              + -
              +

              When an exception is thrown in LLVM code, the runtime does its best to find a handler suited to processing the circumstance.

              @@ -185,12 +183,14 @@
              +
              + -
              +

              LLVM Code Generation -

              + -
              +

              At the time of this writing, only C++ exception handling support is available in LLVM. So the remainder of this document will be somewhat C++-centric.

              @@ -200,14 +200,12 @@ we will describe the implementation of LLVM exception handling in terms of C++ examples.

              -
              - -
              +

              Throw -

              + -
              +

              Languages that support exception handling typically provide a throw operation to initiate the exception process. Internally, a throw operation @@ -225,11 +223,11 @@

              -
              +

              Try/Catch -

              + -
              +

              A call within the scope of a try statement can potentially raise an exception. In those circumstances, the LLVM C++ front-end replaces the call @@ -313,11 +311,11 @@

              -
              +

              Cleanups -

              + -
              +

              To handle destructors and cleanups in try code, control may not run directly from a landing pad to the first catch. Control may actually flow @@ -332,11 +330,11 @@

              -
              +

              Throw Filters -

              + -
              +

              C++ allows the specification of which exception types can be thrown from a function. To represent this a top level landing pad may exist to filter out @@ -359,11 +357,11 @@

              -
              +

              Restrictions -

              + -
              +

              The semantics of the invoke instruction require that any exception that unwinds through an invoke call should result in a branch to the invoke's @@ -384,25 +382,25 @@

              +
              + -
              +

              Exception Handling Intrinsics -

              + -
              +

              LLVM uses several intrinsic functions (name prefixed with "llvm.eh") to provide exception handling information at various points in generated code.

              -
              - -
              +

              llvm.eh.exception -

              + -
              +
                 i8* %llvm.eh.exception()
@@ -413,11 +411,11 @@
              -
              +

              llvm.eh.selector -

              + -
              +
                 i32 %llvm.eh.selector(i8*, i8*, ...)
@@ -445,11 +443,11 @@
              -
              +

              llvm.eh.typeid.for -

              + -
              +
                 i32 %llvm.eh.typeid.for(i8*)
@@ -463,11 +461,11 @@
              -
              +

              llvm.eh.sjlj.setjmp -

              + -
              +
                 i32 %llvm.eh.sjlj.setjmp(i8*)
@@ -492,11 +490,11 @@
              -
              +

              llvm.eh.sjlj.longjmp -

              + -
              +
                 void %llvm.eh.sjlj.setjmp(i8*)
@@ -507,16 +505,16 @@
    style exception handling. The single parameter is a pointer to a
    buffer populated by 
      llvm.eh.sjlj.setjmp. The frame pointer and stack pointer
-   are restored from the buffer, then control is transfered to the
+   are restored from the buffer, then control is transferred to the
    destination address.
              -
              +

              llvm.eh.sjlj.lsda -

              + -
              +
                 i8* %llvm.eh.sjlj.lsda()
@@ -531,11 +529,11 @@
              -
              +

              llvm.eh.sjlj.callsite -

              + -
              +
                 void %llvm.eh.sjlj.callsite(i32)
@@ -549,11 +547,11 @@
              -
              +

              llvm.eh.sjlj.dispatchsetup -

              + -
              +
                 void %llvm.eh.sjlj.dispatchsetup(i32)
@@ -565,24 +563,24 @@
              +
              + -
              +

              Asm Table Formats -

              + -
              +

              There are two tables that are used by the exception handling runtime to determine which actions should take place when an exception is thrown.

              -
              - -
              +

              Exception Handling Frame -

              + -
              +

              An exception handling frame eh_frame is very similar to the unwind frame used by dwarf debug info. The frame contains all the information @@ -596,11 +594,11 @@

              -
              +

              Exception Tables -

              + -
              +

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

              +
              + -
              +

              ToDo -

              + -
              +
                @@ -636,8 +636,8 @@ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
                - LLVM Compiler Infrastructure
                - Last modified: $Date: 2010-12-10 00:05:48 +0100 (Fri, 10 Dec 2010) $ + LLVM Compiler Infrastructure
                + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index 22375608457e..03cfa7e841ea 100644 --- a/docs/ExtendingLLVM.html +++ b/docs/ExtendingLLVM.html @@ -8,9 +8,9 @@ -
                +

                Extending LLVM: Adding instructions, intrinsics, types, etc. -

                +
                1. Introduction and Warning
                  2. @@ -31,12 +31,12 @@
              -
              +

              Introduction and Warning -

              + -
              +

              During the course of using LLVM, you may wish to customize it for your research project or for experimentation. At this point, you may realize that @@ -68,12 +68,12 @@ effort by doing so.

              -
              +

              Adding a new intrinsic function -

              + -
              +

              Adding a new intrinsic function to LLVM is much easier than adding a new instruction. Almost all extensions to LLVM should start as an intrinsic @@ -130,12 +130,12 @@ support for it. Generally you must do the following steps:

              -
              +

              Adding a new SelectionDAG node -

              + -
              +

              As with intrinsics, adding a new SelectionDAG node to LLVM is much easier than adding a new instruction. New nodes are often added to help represent @@ -220,12 +220,12 @@ complicated behavior in a single node (rotate).

              -
              +

              Adding a new instruction -

              + -
              +

              WARNING: adding instructions changes the bitcode format, and it will take some effort to maintain compatibility with @@ -277,25 +277,23 @@ to understand this new instruction.

              -
              +

              Adding a new type -

              + -
              +

              WARNING: adding new types changes the bitcode format, and will break compatibility with currently-existing LLVM installations. Only add new types if it is absolutely necessary.

              -
              - -
              +

              Adding a fundamental type -

              + -
              +
                @@ -317,11 +315,11 @@ installations. Only add new types if it is absolutely necessary.

              -
              +

              Adding a derived type -

              + -
              +
              1. llvm/include/llvm/Type.h: @@ -373,6 +371,8 @@ void calcTypeName(const Type *Ty,
              +
              +
              @@ -382,9 +382,9 @@ void calcTypeName(const Type *Ty, Valid HTML 4.01 - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
              - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/FAQ.html b/docs/FAQ.html index 9415a902756b..20ba1d5d2912 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -12,9 +12,9 @@ -
              +

              LLVM: Frequently Asked Questions -

              +
              1. License @@ -133,14 +133,14 @@
              -

              Written by The LLVM Team

              +

              Written by The LLVM Team

              -
              +

              License -

              +
              @@ -189,9 +189,9 @@
              -
              +

              Source Code -

              +
              @@ -227,9 +227,9 @@ LLVM have been ported to a plethora of platforms.

              -
              +

              Build Problems -

              +
              @@ -449,7 +449,9 @@ Stop.
              -
              Source Languages
              +

              + Source Languages +

              What source languages are supported?

              @@ -555,9 +557,9 @@ Stop.
              -
              +

              Using the GCC Front End -

              +

              When I compile software that uses a configure script, the configure script @@ -712,9 +714,9 @@ Stop.

              -
              +

              Questions about code generated by the GCC front-end -

              +

              What is this llvm.global_ctors and @@ -930,8 +932,8 @@ F.i: Valid HTML 4.01 - LLVM Compiler Infrastructure
              - Last modified: $Date: 2010-05-28 19:07:41 +0200 (Fri, 28 May 2010) $ + LLVM Compiler Infrastructure
              + Last modified: $Date: 2011-04-19 01:59:50 +0200 (Tue, 19 Apr 2011) $ diff --git a/docs/GCCFEBuildInstrs.html b/docs/GCCFEBuildInstrs.html index 0b2827c9d5c1..f502481b89ea 100644 --- a/docs/GCCFEBuildInstrs.html +++ b/docs/GCCFEBuildInstrs.html @@ -8,9 +8,9 @@ -

              +

              Building the LLVM GCC Front-End -

              +
              1. Building llvm-gcc from Source
                2. @@ -24,10 +24,10 @@
              -

              Building llvm-gcc from Source

              +

              Building llvm-gcc from Source

              -
              +

              This section describes how to acquire and build llvm-gcc 4.2, which is based on the GCC 4.2.1 front-end. Supported languages are Ada, C, C++, Fortran, @@ -67,10 +67,10 @@ svn co http://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk dst-directory

              -

              Building the Ada front-end

              +

              Building the Ada front-end

              -
              +

              Building with support for Ada amounts to following the directions in the top-level README.LLVM file, adding ",ada" to EXTRALANGS, for example: EXTRALANGS=,ada

              @@ -100,7 +100,7 @@ top-level README.LLVM file, adding ",ada" to EXTRALANGS, for example:

            3. Because the Ada front-end is experimental, it is wise to build the compiler with checking enabled. This causes it to run much slower, but helps catch mistakes in the compiler (please report any problems using - LLVM bugzilla).

              4. + LLVM bugzilla).

            4. The Ada front-end fails to bootstrap, due to lack of LLVM support for setjmp/longjmp style exception handling (used @@ -233,10 +233,10 @@ make install

              5. -

              Building the Fortran front-end

              +

              Building the Fortran front-end

              -
              +

              To build with support for Fortran, follow the directions in the top-level README.LLVM file, adding ",fortran" to EXTRALANGS, for example:

              @@ -247,10 +247,10 @@ EXTRALANGS=,fortran
              -

              License Information

              +

              License Information

              -
              +

              The LLVM GCC frontend is licensed to you under the GNU General Public License and the GNU Lesser General Public License. Please see the files COPYING and @@ -271,8 +271,8 @@ More information is available in the FAQ. Valid HTML 4.01 - LLVM Compiler Infrastructure
              - Last modified: $Date: 2010-08-31 21:40:21 +0200 (Tue, 31 Aug 2010) $ + LLVM Compiler Infrastructure
              + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/GarbageCollection.html b/docs/GarbageCollection.html index fde070ce6b45..13a3714e8233 100644 --- a/docs/GarbageCollection.html +++ b/docs/GarbageCollection.html @@ -13,9 +13,9 @@ -

              +

              Accurate Garbage Collection with LLVM -

              +
              1. Introduction @@ -79,12 +79,12 @@
              -
              +

              Introduction -

              + -
              +

              Garbage collection is a widely used technique that frees the programmer from having to know the lifetimes of heap objects, making software easier to produce @@ -124,14 +124,12 @@ techniques dominates any low-level losses.

              This document describes the mechanisms and interfaces provided by LLVM to support accurate garbage collection.

              -
              - -
              +

              Goals and non-goals -

              + -
              +

              LLVM's intermediate representation provides garbage collection intrinsics that offer support for a broad class of @@ -151,14 +149,14 @@ collector models. For instance, the intrinsics permit:

              support a broad class of garbage collected languages including Scheme, ML, Java, C#, Perl, Python, Lua, Ruby, other scripting languages, and more.

              -

              However, LLVM does not itself provide a garbage collector—this should +

              However, LLVM does not itself provide a garbage collector—this should be part of your language's runtime library. LLVM provides a framework for compile time code generation plugins. The role of these plugins is to generate code and data structures which conforms to the binary interface specified by the runtime library. This is similar to the relationship between LLVM and DWARF debugging info, for example. The difference primarily lies in the lack of an established standard in the domain -of garbage collection—thus the plugins.

              +of garbage collection—thus the plugins.

              The aspects of the binary interface with which LLVM's GC support is concerned are:

              @@ -198,13 +196,15 @@ compiler matures.

              +
              + -
              +

              Getting started -

              + -
              +

              Using a GC with LLVM implies many things, for example:

              @@ -246,14 +246,12 @@ compiler matures.

              includes a highly portable, built-in ShadowStack code generator. It is compiled into llc and works even with the interpreter and C backends.

              -
              - -
              +

              In your compiler -

              + -
              +

              To turn the shadow stack on for your functions, first call:

              @@ -276,11 +274,11 @@ switching to a more advanced GC.

              -
              +

              In your runtime -

              + -
              +

              The shadow stack doesn't imply a memory allocation algorithm. A semispace collector or building atop malloc are great places to start, and can @@ -343,11 +341,11 @@ void visitGCRoots(void (*Visitor)(void **Root, const void *Meta)) { }

              -
              +

              About the shadow stack -

              + -
              +

              Unlike many GC algorithms which rely on a cooperative code generator to compile stack maps, this algorithm carefully maintains a linked list of stack @@ -372,13 +370,15 @@ in order to improve performance.

              +
              + -
              +

              IR features -

              + -
              +

              This section describes the garbage collection facilities provided by the LLVM intermediate representation. The exact behavior @@ -390,18 +390,16 @@ intended to be a complete interface to any garbage collector. A program will need to interface with the GC library using the facilities provided by that program.

              -
              - -
              +

              Specifying GC code generation: gc "..." -

              +
              define ty @name(...) gc "name" { ...
              -
              +

              The gc function attribute is used to specify the desired GC style to the compiler. Its programmatic equivalent is the setGC method of @@ -418,15 +416,15 @@ programs that use different garbage collection algorithms (or none at all).

              -
              +

              Identifying GC roots on the stack: llvm.gcroot -

              +
              void @llvm.gcroot(i8** %ptrloc, i8* %metadata)
              -
              +

              The llvm.gcroot intrinsic is used to inform LLVM that a stack variable references an object on the heap and is to be tracked for garbage @@ -494,11 +492,11 @@ CodeBlock:

              -
              +

              Reading and writing references in the heap -

              + -
              +

              Some collectors need to be informed when the mutator (the program that needs garbage collection) either reads a pointer from or writes a pointer to a field @@ -534,18 +532,16 @@ require the corresponding barrier. Such a GC plugin will replace the intrinsic calls with the corresponding load or store instruction if they are used.

              -
              - -
              +

              Write barrier: llvm.gcwrite -

              +
              void @llvm.gcwrite(i8* %value, i8* %object, i8** %derived)
              -
              +

              For write barriers, LLVM provides the llvm.gcwrite intrinsic function. It has exactly the same semantics as a non-volatile store to @@ -559,15 +555,15 @@ implement reference counting.

              -
              +

              Read barrier: llvm.gcread -

              +
              i8* @llvm.gcread(i8* %object, i8** %derived)
              -
              +

              For read barriers, LLVM provides the llvm.gcread intrinsic function. It has exactly the same semantics as a non-volatile load from the @@ -580,13 +576,17 @@ writes.

              +
              + +
              + -
              +

              Implementing a collector plugin -

              + -
              +

              User code specifies which GC code generation to use with the gc function attribute or, equivalently, with the setGC method of @@ -666,14 +666,12 @@ $ llvm-as < sample.ll | llc -load=MyGC.so

              It is also possible to statically link the collector plugin into tools, such as a language-specific compiler front-end.

              -
              - -
              +

              Overview of available features -

              + -
              +

              GCStrategy provides a range of features through which a plugin may do useful work. Some of these are callbacks, some are algorithms that can @@ -958,11 +956,11 @@ interest.

              -
              +

              Computing stack maps -

              + -
              +

              LLVM automatically computes a stack map. One of the most important features of a GCStrategy is to compile this information into the executable in @@ -1014,11 +1012,11 @@ for collector plugins which implement reference counting or a shadow stack.

              -
              +

              Initializing roots to null: InitRoots -

              + -
              +
              MyGC::MyGC() {
@@ -1039,12 +1037,12 @@ this feature should be used by all GC plugins. It is enabled by default.
              
 
 
 
-
              
+
              
   Custom lowering of intrinsics: CustomRoots, 
     CustomReadBarriers, and CustomWriteBarriers
-
              
+
 
-
              
+
              
 
 
              For GCs which use barriers or unusual treatment of stack roots, these
 flags allow the collector to perform arbitrary transformations of the LLVM
@@ -1129,11 +1127,11 @@ bool MyGC::performCustomLowering(Function &F) {
 
 
 
-
              
+
              
   Generating safe points: NeededSafePoints
-
              
+
 
-
              
+
              
 
 
              LLVM can compute four kinds of safe points:
              
 
@@ -1193,11 +1191,11 @@ safe point (because only the topmost function has been patched).
              
 
 
 
-
              
+
              
   Emitting assembly code: GCMetadataPrinter
-
              
+
 
-
              
+
              
 
 
              LLVM allows a plugin to print arbitrary assembly code before and after the
 rest of a module's assembly code. At the end of the module, the GC can compile
@@ -1341,14 +1339,15 @@ void MyGCPrinter::finishAssembly(std::ostream &OS, AsmPrinter &AP,
 
 
              
 
+
              
 
 
-
              
+
              
   References
-
              
+
 
 
-
              
+
              
 
 
              [Appel89] Runtime Tags Aren't Necessary. Andrew
 W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.
              
@@ -1379,8 +1378,8 @@ Fergus Henderson. International Symposium on Memory Management 2002.
              
   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
 
   Chris Lattner
              
-  LLVM Compiler Infrastructure
              
-  Last modified: $Date: 2010-05-11 22:16:09 +0200 (Tue, 11 May 2010) $
+  LLVM Compiler Infrastructure
              
+  Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
 
 
 
diff --git a/docs/GetElementPtr.html b/docs/GetElementPtr.html
index 5410137861ff..4c347a6aaf12 100644
--- a/docs/GetElementPtr.html
+++ b/docs/GetElementPtr.html
@@ -11,9 +11,9 @@
 
 
 
-
              
+
              
   The Often Misunderstood GEP Instruction
-
              
+
 
 
                
   
              1. Introduction
                2. 
@@ -58,10 +58,10 @@
 
 
 
-
                Introduction
                
+
                Introduction
                
 
 
-
                 
+
                
   
                This document seeks to dispel the mystery and confusion surrounding LLVM's
   GetElementPtr (GEP) instruction.
   Questions about the wily GEP instruction are
@@ -72,21 +72,20 @@
 
                
 
 
-
                Address Computation
                
+
                Address Computation
                
 
-
                
+
                
   
                When people are first confronted with the GEP instruction, they tend to
   relate it to known concepts from other programming paradigms, most notably C
   array indexing and field selection. GEP closely resembles C array indexing
   and field selection, however it's is a little different and this leads to
   the following questions.
                
-
                
 
 
-
                
-  What is the first index of the GEP instruction?
-
                
-
                
+
                
+  What is the first index of the GEP instruction?
+
                
+
                
   
                Quick answer: The index stepping through the first operand.
                 
   
                The confusion with the first index usually arises from thinking about 
   the GetElementPtr instruction as if it was a C index operator. They aren't the
@@ -205,11 +204,11 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Why is the extra 0 index required?
-
                
+
                
+  Why is the extra 0 index required?
+
                
 
-
                
+
                
   
                Quick answer: there are no superfluous indices.
                
   
                This question arises most often when the GEP instruction is applied to a
   global variable which is always a pointer type. For example, consider
@@ -247,10 +246,10 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  What is dereferenced by GEP?
-
                
-
                
+
                
+  What is dereferenced by GEP?
+
                
+
                
   
                Quick answer: nothing.
                 
   
                The GetElementPtr instruction dereferences nothing. That is, it doesn't
   access memory in any way. That's what the Load and Store instructions are for.
@@ -302,10 +301,10 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Why don't GEP x,0,0,1 and GEP x,1 alias?
-
                
-
                
+
                
+  Why don't GEP x,0,0,1 and GEP x,1 alias?
+
                
+
                
   
                Quick Answer: They compute different address locations.
                
   
                If you look at the first indices in these GEP
   instructions you find that they are different (0 and 1), therefore the address
@@ -331,10 +330,10 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Why do GEP x,1,0,0 and GEP x,1 alias?
-
                
-
                
+
                
+  Why do GEP x,1,0,0 and GEP x,1 alias?
+
                
+
                
   
                Quick Answer: They compute the same address location.
                
   
                These two GEP instructions will compute the same address because indexing
   through the 0th element does not change the address. However, it does change
@@ -355,10 +354,10 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  Can GEP index into vector elements?
-
                
-
                
+
                
+  Can GEP index into vector elements?
+
                
+
                
   
                This hasn't always been forcefully disallowed, though it's not recommended.
      It leads to awkward special cases in the optimizers, and fundamental
      inconsistency in the IR. In the future, it will probably be outright
@@ -368,10 +367,10 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  What effect do address spaces have on GEPs?
-
                
-
                
+
                
+  What effect do address spaces have on GEPs?
+
                
+
                
    
                None, except that the address space qualifier on the first operand pointer
       type always matches the address space qualifier on the result type.
                
 
@@ -379,11 +378,12 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  How is GEP different from ptrtoint, arithmetic,
-                   and inttoptr?
-
                
-
                
+
                
+  
+    How is GEP different from ptrtoint, arithmetic, and inttoptr?
+  
+
                
+
                
   
                It's very similar; there are only subtle differences.
                
 
   
                With ptrtoint, you have to pick an integer type. One approach is to pick i64;
@@ -409,11 +409,13 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  I'm writing a backend for a target which needs custom
-                  lowering for GEP. How do I do this?
-
                
-
                
+
                
+  
+    I'm writing a backend for a target which needs custom lowering for GEP.
+    How do I do this?
+  
+
                
+
                
   
                You don't. The integer computation implied by a GEP is target-independent.
      Typically what you'll need to do is make your backend pattern-match
      expressions trees involving ADD, MUL, etc., which are what GEP is lowered
@@ -431,10 +433,10 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  How does VLA addressing work with GEPs?
-
                
-
                
+
                
+  How does VLA addressing work with GEPs?
+
                
+
                
   
                GEPs don't natively support VLAs. LLVM's type system is entirely static,
      and GEP address computations are guided by an LLVM type.
                
 
@@ -450,16 +452,18 @@ idx3 = (char*) &MyVar + 8
      VLA and non-VLA indexing in the same manner.
                
 
                
 
+
                
+
 
-
                Rules
                
+
                Rules
                
 
-
+
                
 
 
-
                
-  What happens if an array index is out of bounds?
-
                
-
                
+
                
+  What happens if an array index is out of bounds?
+
                
+
                
   
                There are two senses in which an array index can be out of bounds.
                
 
   
                First, there's the array type which comes from the (static) type of
@@ -498,20 +502,20 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Can array indices be negative?
-
                
-
                
+
                
+  Can array indices be negative?
+
                
+
                
   
                Yes. This is basically a special case of array indices being out
      of bounds.
                
 
 
                
 
 
-
                
-  Can I compare two values computed with GEPs?
-
                
-
                
+
                
+  Can I compare two values computed with GEPs?
+
                
+
                
   
                Yes. If both addresses are within the same allocated object, or 
      one-past-the-end, you'll get the comparison result you expect. If either
      is outside of it, integer arithmetic wrapping may occur, so the
@@ -520,11 +524,13 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Can I do GEP with a different pointer type than the type of
-                     the underlying object?
-
                
-
                
+
                
+  
+    Can I do GEP with a different pointer type than the type of
+    the underlying object?
+  
+
                
+
                
   
                Yes. There are no restrictions on bitcasting a pointer value to an arbitrary
      pointer type. The types in a GEP serve only to define the parameters for the
      underlying integer computation. They need not correspond with the actual
@@ -538,11 +544,12 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Can I cast an object's address to integer and add it
-                    to null?
-
                
-
                
+
                
+  
+    Can I cast an object's address to integer and add it to null?
+  
+
                
+
                
   
                You can compute an address that way, but if you use GEP to do the add,
      you can't use that pointer to actually access the object, unless the
      object is managed outside of LLVM.
                
@@ -562,11 +569,13 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Can I compute the distance between two objects, and add
-                       that value to one address to compute the other address?
-
                
-
                
+
                
+  
+    Can I compute the distance between two objects, and add
+    that value to one address to compute the other address?
+  
+
                
+
                
   
                As with arithmetic on null, You can use GEP to compute an address that
      way, but you can't use that pointer to actually access the object if you
      do, unless the object is managed outside of LLVM.
                
@@ -577,10 +586,10 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Can I do type-based alias analysis on LLVM IR?
-
                
-
                
+
                
+  Can I do type-based alias analysis on LLVM IR?
+
                
+
                
   
                You can't do type-based alias analysis using LLVM's built-in type system,
      because LLVM has no restrictions on mixing types in addressing, loads or
      stores.
                
@@ -594,10 +603,10 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  What happens if a GEP computation overflows?
-
                
-
                
+
                
+  What happens if a GEP computation overflows?
+
                
+
                
    
                If the GEP lacks the inbounds keyword, the value is the result
       from evaluating the implied two's complement integer computation. However,
       since there's no guarantee of where an object will be allocated in the
@@ -624,11 +633,12 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  How can I tell if my front-end is following the
-                     rules?
-
                
-
                
+
                
+  
+    How can I tell if my front-end is following the rules?
+  
+
                
+
                
    
                There is currently no checker for the getelementptr rules. Currently,
       the only way to do this is to manually check each place in your front-end
       where GetElementPtr operators are created.
                
@@ -641,16 +651,18 @@ idx3 = (char*) &MyVar + 8
 
 
                
 
+
                
+
 
-
                Rationale
                
+
                Rationale
                
 
-
+
                
 
 
-
                
-  Why is GEP designed this way?
-
                
-
                
+
                
+  Why is GEP designed this way?
+
                
+
                
    
                The design of GEP has the following goals, in rough unofficial
       order of priority:
                
    
                  
@@ -669,10 +681,10 @@ idx3 = (char*) &MyVar + 8
 
                
 
 
-
                
-  Why do struct member indices always use i32?
-
                
-
                
+
                
+  Why do struct member indices always use i32?
+
                
+
                
   
                The specific type i32 is probably just a historical artifact, however it's
      wide enough for all practical purposes, so there's been no need to change it.
      It doesn't necessarily imply i32 address arithmetic; it's just an identifier
@@ -684,10 +696,10 @@ idx3 = (char*) &MyVar + 8
 
 
 
-
                
-  What's an uglygep?
-
                
-
                
+
                
+  What's an uglygep?
+
                
+
                
   
                Some LLVM optimizers operate on GEPs by internally lowering them into
      more primitive integer expressions, which allows them to be combined
      with other integer expressions and/or split into multiple separate
@@ -704,11 +716,13 @@ idx3 = (char*) &MyVar + 8
 
 
                
 
+
                
+
 
-
                Summary
                
+
                Summary
                
 
 
-
                
+
                
   
                In summary, here's some things to always remember about the GetElementPtr
   instruction:
                
   
                  
@@ -732,8 +746,8 @@ idx3 = (char*) &MyVar + 8
   src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS">
   Valid HTML 4.01
-  The LLVM Compiler Infrastructure
                  
-  Last modified: $Date: 2011-02-11 22:50:52 +0100 (Fri, 11 Feb 2011) $
+  The LLVM Compiler Infrastructure
                  
+  Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
 
 
 
diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html
index dfb976a29f1e..cc5c59e78f66 100644
--- a/docs/GettingStarted.html
+++ b/docs/GettingStarted.html
@@ -8,9 +8,9 @@
 
 
 
-
                  
+
                  
   Getting Started with the LLVM System  
-
                  
+
 
 
                    
   
                  • Overview
@@ -62,7 +62,7 @@
   
                    Written by: 
     John Criswell, 
     Chris Lattner,
-    Misha Brukman, 
+    Misha Brukman, 
     Vikram Adve, and
     Guochun Shi.
   
                    
@@ -70,12 +70,12 @@
 
 
 
-
                    
-  Overview
-
                    
+
                    
+  Overview
+
                    
 
 
-
                    
+
                    
 
 
                    Welcome to LLVM! In order to get started, you first need to know some
 basic information.
                    
@@ -102,12 +102,12 @@ and performance.
 
                    
 
 
-
                    
-  Getting Started Quickly (A Summary)
-
                    
+
                    
+  Getting Started Quickly (A Summary)
+
                    
 
 
-
                    
+
                    
 
 
                    Here's the short story for getting up and running quickly with LLVM:
                    
 
@@ -116,13 +116,13 @@ and performance.
   
                  • Read the documentation.
                    • 
   
                  • Remember that you were warned twice about reading the documentation.
                    • 
   
                  • Install the llvm-gcc-4.2 front end if you intend to compile C or C++
-      (see Install the GCC Front End for details):
                    • 
+      (see Install the GCC Front End for details):
     
                      
       
                    1. cd where-you-want-the-C-front-end-to-live
                      2. 
       
                    2. gunzip --stdout llvm-gcc-4.2-version-platform.tar.gz | tar -xvf -
                      3. 
 	  
                    3. install-binutils-binary-from-MinGW (Windows only)
                      4. 
 	  
                    4. Note: If the binary extension is ".bz" use bunzip2 instead of gunzip.
                      5. 
-	  
                    5. Note: On Windows, use 7-Zip or a similar archiving tool.
                      6. 
+	  
                    6. Note: On Windows, use 7-Zip or a similar archiving tool.
                      7. 
 	  
                    7. Add llvm-gcc's "bin" directory to your PATH environment variable.
                      8. 
     
                    
 
@@ -191,25 +191,23 @@ Layout to learn about the layout of the source code tree.
                    
 
                
 
 
-
                
-  Requirements
-
                
+
                
+  Requirements
+
                
 
 
-
                
+
                
 
 
                Before you begin to use the LLVM system, review the requirements given below.
 This may save you some trouble by knowing ahead of time what hardware and
 software you will need.
                
 
-
                
-
 
-
                
-  Hardware
-
                
+
                
+  Hardware
+
                
 
-
                
+
                
 
 
                LLVM is known to work on the following platforms:
                
 
@@ -268,7 +266,8 @@ software you will need.
              + 8, 10, + 11
              MinGW/Win32 x861,6, - 8, 10 GCC 3.4.X, binutils 2.20
              @@ -311,6 +310,11 @@ software you will need.

              Itanium (IA-64) HP aCC + + Windows x64 + x86-64 + mingw-w64's GCC-4.5.x12 +

              Notes:

              @@ -337,9 +341,10 @@ up
              5. before any Windows-based versions such as Strawberry Perl and ActivePerl, as these have Windows-specifics that will cause the build to fail. -
            5. In general, LLVM modules requiring dynamic linking can - not be built on Windows. However, you can build LLVM tools using - "make tools-only".
              6. +
            6. To use LLVM modules on Win32-based system, + you may configure LLVM with "--enable-shared".
              7. +
            7. To compile SPU backend, you need to add + "LDFLAGS=-Wl,--stack,16777216" to configure.
            @@ -363,8 +368,10 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.

            -
            Software
            -
            +

            + Software +

            +

            Compiling LLVM requires that you have several software packages installed. The table below lists those required packages. The Package column is the usual name for the software package that LLVM depends on. The Version @@ -380,13 +387,13 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.

            - GCC + GCC 3.4.2 C/C++ compiler1 - TeXinfo + TeXinfo 4.5 For building the CFE @@ -397,6 +404,11 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.

            Subversion access to LLVM2 + + DejaGnu 1.4.2 @@ -428,13 +440,13 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.

            - GNU Autoconf + GNU Autoconf 2.60 Configuration script builder4 - GNU Automake + GNU Automake 1.9.6 aclocal macro generator4 @@ -496,11 +508,11 @@ href="GCCFEBuildInstrs.html">try to compile it on your platform.

            -
            +

            Broken versions of GCC and other tools -

            + -
            +

            LLVM is very demanding of the host C++ compiler, and as such tends to expose bugs in the compiler. In particular, several versions of GCC crash when trying @@ -593,15 +605,15 @@ upgrading to a newer version of Gold.

            - +
            -
            - Getting Started with LLVM -
            +

            + Getting Started with LLVM +

            -
            +

            The remainder of this guide is meant to get you up and running with LLVM and to give you some basic information about the LLVM environment.

            @@ -611,14 +623,13 @@ href="#layout">general layout of the the LLVM source tree, a simple example using the LLVM tool chain, and links to find more information about LLVM or to get help via e-mail.

            -
            -
            +

            Terminology and Notation -

            + -
            +

            Throughout this manual, the following names are used to denote paths specific to the local system and working environment. These are not @@ -651,11 +662,11 @@ All these paths are absolute:

            -
            +

            Setting Up Your Environment -

            + -
            +

            In order to compile and use LLVM, you may need to set some environment @@ -674,11 +685,11 @@ variables.

            -
            +

            Unpacking the LLVM Archives -

            + -
            +

            If you have the LLVM distribution, you will need to unpack it before you @@ -708,11 +719,11 @@ compressed with the gzip program.

            -
            +

            Checkout LLVM from Subversion -

            + -
            +

            If you have access to our Subversion repository, you can get a fresh copy of the entire source code. All you need to do is check it out from Subversion as @@ -736,6 +747,7 @@ revision), you can checkout it from the 'tags' directory (instead of subdirectories of the 'tags' directory:

              +
            • Release 2.9: RELEASE_29/final
            • Release 2.8: RELEASE_28
            • Release 2.7: RELEASE_27
            • Release 2.6: RELEASE_26
              • @@ -778,30 +790,30 @@ instructions to successfully get and build the LLVM GCC front-end.

            -
            +

            GIT mirror -

            + -
            +

            GIT mirrors are available for a number of LLVM subprojects. These mirrors sync automatically with each Subversion commit and contain all necessary git-svn marks (so, you can recreate git-svn metadata locally). Note that right now mirrors reflect only trunk for each project. You can do the - read-only GIT clone of LLVM via: + read-only GIT clone of LLVM via:

            + 
             % git clone http://llvm.org/git/llvm.git
            -

            -
            +

            Install the GCC Front End -

            + -
            +

            Before configuring and compiling the LLVM suite (or if you want to use just the LLVM GCC front end) you can optionally extract the front end from the binary distribution. @@ -810,7 +822,7 @@ you can optionally build llvm-gcc yourself a main LLVM repository.

            To install the GCC front end, do the following (on Windows, use an archival tool -like 7-zip that understands gzipped tars):

            +like 7-zip that understands gzipped tars):

            1. cd where-you-want-the-front-end-to-live
              2. @@ -867,11 +879,11 @@ please let us know how you would like to see things improved by dropping us a no
            -
            +

            Local LLVM Configuration -

            + -
            +

            Once checked out from the Subversion repository, the LLVM suite source code must be @@ -989,11 +1001,11 @@ script to configure the build system:

            -
            +

            Compiling the LLVM Suite Source Code -

            + -
            +

            Once you have configured LLVM, you can build it. There are three types of builds:

            @@ -1123,11 +1135,11 @@ that directory that is out of date.

            -
            +

            Cross-Compiling LLVM -

            + -
            +

            It is possible to cross-compile LLVM itself. That is, you can create LLVM executables and libraries to be hosted on a platform different from the platform where they are build (a Canadian Cross build). To configure a @@ -1141,11 +1153,11 @@ that directory that is out of date.

            -
            +

            The Location of LLVM Object Files -

            + -
            +

            The LLVM build system is capable of sharing a single LLVM source tree among several LLVM builds. Hence, it is possible to build LLVM for several different @@ -1201,11 +1213,11 @@ named after the build type:

            -
            +

            Optional Configuration Items -

            + -
            +

            If you're running on a Linux system that supports the " This allows you to execute LLVM bitcode files directly. On Debian, you -can also use this command instead of the 'echo' command above:

            +can also use this command instead of the 'echo' command above:

            @@ -1236,31 +1248,37 @@ $ sudo update-binfmts --install llvm /path/to/lli --magic 'BC'
            - -
            - Program Layout
            + + +

            + Program Layout +

            -
            +

            One useful source of information about the LLVM source base is the LLVM doxygen documentation available at doxygen documentation available at http://llvm.org/doxygen/. The following is a brief introduction to code layout:

            -
            - -
            llvm/examples
            -
            +

            + llvm/examples +

            + +

            This directory contains some simple examples of how to use the LLVM IR and JIT.

            -
            llvm/include
            -
            +

            + llvm/include +

            + +

            This directory contains public header files exported from the LLVM library. The three main subdirectories of this directory are:

            @@ -1287,8 +1305,11 @@ library. The three main subdirectories of this directory are:

            -
            llvm/lib
            -
            +

            + llvm/lib +

            + +

            This directory contains most of the source files of the LLVM system. In LLVM, almost all code exists in libraries, making it very easy to share code among the @@ -1327,6 +1348,10 @@ different tools.

            This directory contains the major parts of the code generator: Instruction Selector, Instruction Scheduling, and Register Allocation.
            +
            llvm/lib/MC/
            +
            (FIXME: T.B.D.)
            + +
            llvm/lib/Debugger/
            This directory contains the source level debugger library that makes it possible to instrument LLVM programs so that a debugger could identify @@ -1340,6 +1365,7 @@ different tools.

            This directory contains the source code that corresponds to the header files located in llvm/include/Support/.
            +
            llvm/lib/System/
            This directory contains the operating system abstraction layer that shields LLVM from platform-specific coding.
            @@ -1348,8 +1374,11 @@ different tools.

            -
            llvm/projects
            -
            +

            + llvm/projects +

            + +

            This directory contains projects that are not strictly part of LLVM but are shipped with LLVM. This is also the directory where you should create your own LLVM-based projects. See llvm/projects/sample for an example of how @@ -1357,8 +1386,11 @@ different tools.

            -
            llvm/runtime
            -
            +

            + llvm/runtime +

            + +

            This directory contains libraries which are compiled into LLVM bitcode and used when linking programs with the GCC front end. Most of these libraries are @@ -1371,16 +1403,22 @@ end to compile.

            -
            llvm/test
            -
            +

            + llvm/test +

            + +

            This directory contains feature and regression tests and other basic sanity checks on the LLVM infrastructure. These are intended to run quickly and cover a lot of territory without being exhaustive.

            -
            test-suite
            -
            +

            + test-suite +

            + +

            This is not a directory in the normal llvm module; it is a separate Subversion module that must be checked out (usually to projects/test-suite). @@ -1395,8 +1433,11 @@ end to compile.

            -
            llvm/tools
            -
            +

            + llvm/tools +

            + +

            The tools directory contains the executables built out of the libraries above, which form the main part of the user interface. You can @@ -1480,8 +1521,11 @@ information is in the Command Guide.

            -
            llvm/utils
            -
            +

            + llvm/utils +

            + +

            This directory contains utilities for working with LLVM source code, and some of the utilities are actually required as part of the build process because they @@ -1542,13 +1586,15 @@ are code generators for parts of LLVM infrastructure.

            +
            + -
            +

            An Example Using the LLVM Tool Chain -

            + -
            +

            This section gives an example of using LLVM. llvm-gcc3 is now obsolete, so we only include instructions for llvm-gcc4.

            @@ -1559,12 +1605,13 @@ create bitcode by default: gcc4 produces native code. As the example belo the '--emit-llvm' flag is needed to produce LLVM bitcode output. For makefiles and configure scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode output.

            -
            -
            Example with llvm-gcc4
            +

            + Example with llvm-gcc4 +

            -
            +

            1. First, create a simple C file, name it 'hello.c':

              @@ -1645,14 +1692,15 @@ int main() {
            +
            -
            +

            Common Problems -

            + -
            +

            If you are having problems building or using LLVM, or if you have any other general questions about LLVM, please consult the Frequently @@ -1661,12 +1709,12 @@ Asked Questions page.

            -
            +

            Links -

            + -
            +

            This document is just an introduction on how to use LLVM to do some simple things... there are many more interesting and complicated things @@ -1694,8 +1742,8 @@ out:

            Chris Lattner
            Reid Spencer
            - The LLVM Compiler Infrastructure
            - Last modified: $Date: 2011-02-01 21:08:28 +0100 (Tue, 01 Feb 2011) $ + The LLVM Compiler Infrastructure
            + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/GettingStartedVS.html b/docs/GettingStartedVS.html index 7c0bf007ec3a..6a604333c8f1 100644 --- a/docs/GettingStartedVS.html +++ b/docs/GettingStartedVS.html @@ -8,9 +8,9 @@ -
            +

            Getting Started with the LLVM System using Microsoft Visual Studio -

            +
            -

            Written by: - Jeff Cohen -

            +

            Written by: The LLVM Team

            -
            +

            Overview -

            + -
            +

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

            -
            +

            Requirements -

            + -
            +

            Before you begin to use the LLVM system, review the requirements given below. This may save you some trouble by knowing ahead of time what hardware and software you will need.

            -
            - -
            +

            Hardware -

            + -
            +

            Any system that can adequately run Visual Studio .NET 2005 SP1 is fine. The LLVM source tree and object files, libraries and executables will consume @@ -99,8 +95,8 @@

            -
            Software
            -
            +

            Software

            +

            You will need Visual Studio .NET 2005 SP1 or higher. The VS2005 SP1 beta and the normal VS2005 still have bugs that are not completely @@ -120,13 +116,15 @@

            +
            + -
            +

            Getting Started -

            + -
            +

            Here's the short story for getting up and running quickly with LLVM:

            @@ -196,7 +194,9 @@
            • If %PATH% does not contain GnuWin32, you may specify LLVM_LIT_TOOLS_DIR on CMake for the path to GnuWin32.
              • -
            • You can run LLVM tests to build the project "check".
              • +
            • You can run LLVM tests by merely building the project + "check". The test results will be shown in the VS output + window.
            @@ -215,25 +215,26 @@

            Note that quite a few of these test will fail.

            -
          3. A specific test or test directory can be run with:
            4. +
          4. A specific test or test directory can be run with: 
             % llvm-lit test/path/to/test
            - +
            5. +
    -
    +

    An Example Using the LLVM Tool Chain -

    + -
    +

    1. First, create a simple C file, name it 'hello.c':

      @@ -318,12 +319,12 @@ int main() {
    -
    +

    Common Problems -

    + -
    +

    If you are having problems building or using LLVM, or if you have any other general questions about LLVM, please consult the Frequently @@ -332,12 +333,12 @@ Asked Questions page.

    -
    +

    Links -

    + -
    +

    This document is just an introduction to how to use LLVM to do some simple things... there are many more interesting and complicated things @@ -361,9 +362,8 @@ out:

    Valid HTML 4.01 - Jeff Cohen
    - The LLVM Compiler Infrastructure
    - Last modified: $Date: 2011-02-20 16:34:12 +0100 (Sun, 20 Feb 2011) $ + The LLVM Compiler Infrastructure
    + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/GoldPlugin.html b/docs/GoldPlugin.html index 68c5cf192802..e25c45751929 100644 --- a/docs/GoldPlugin.html +++ b/docs/GoldPlugin.html @@ -7,7 +7,7 @@ -
    LLVM gold plugin
    +

    LLVM gold plugin

    1. Introduction
    2. How to build it
      3. @@ -21,9 +21,9 @@
      Written by Nick Lewycky
      -
      Introduction
      +

      Introduction

      -
      +

      Building with link time optimization requires cooperation from the system linker. LTO support on Linux systems requires that you use the gold linker which supports @@ -33,14 +33,14 @@ project.

      The LLVM gold plugin implements the gold plugin interface on top of -libLTO. +libLTO. The same plugin can also be used by other tools such as ar and nm.

      -
      How to build it
      +

      How to build it

      -
      +

      You need to have gold with plugin support and build the LLVMgold plugin. Check whether you have gold running /usr/bin/ld -v. It will report “GNU gold” or else “GNU ld” if not. If you have @@ -72,9 +72,9 @@ placed.

      -
      Usage
      +

      Usage

      -
      +

      The linker takes a -plugin option that points to the path of the plugin .so file. To find out what link command gcc would run in a given situation, run gcc -v [...] and look @@ -95,14 +95,13 @@ placed. own gold, be sure to install the ar and nm-new you built to /usr/bin.

      -

      -
      +

      Example of link time optimization -

      + -
      +

      The following example shows a worked example of the gold plugin mixing LLVM bitcode and native code. 

      @@ -145,14 +144,20 @@ $ llvm-gcc -use-gold-plugin a.a b.o -o main # <-- link with LLVMgold plugin

      Gold informs the plugin that foo3 is never referenced outside the IR, leading LLVM to delete that function. However, unlike in the - libLTO + libLTO example gold does not currently eliminate foo4.

      +
      + -
      Quickstart for using LTO with autotooled projects
      +

      + + Quickstart for using LTO with autotooled projects + +

      -
      +

      Once your system ld, ar and nm all support LLVM bitcode, everything is in place for an easy to use LTO build of autotooled projects:

      @@ -189,9 +194,9 @@ export CFLAGS="-O4"
      -
      Licensing
      +

      Licensing

      -
      +

      Gold is licensed under the GPLv3. LLVMgold uses the interface file plugin-api.h from gold which means that the resulting LLVMgold.so binary is also GPLv3. This can still be used to link non-GPLv3 programs just @@ -206,7 +211,7 @@ as much as gold could without the plugin.

      Valid HTML 4.01 Nick Lewycky
      - The LLVM Compiler Infrastructure
      + The LLVM Compiler Infrastructure
      Last modified: $Date: 2010-04-16 23:58:21 -0800 (Fri, 16 Apr 2010) $ diff --git a/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt b/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt index 1c725f5aa715..81ca53919d42 100644 --- a/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt +++ b/docs/HistoricalNotes/2000-11-18-EarlyDesignIdeasResp.txt @@ -60,11 +60,11 @@ Understood. :) Yup, I think that this makes a lot of sense. I am still intrigued, however, by the prospect of a minimally allocated VM representation... I -think that it could have definate advantages for certain applications +think that it could have definite advantages for certain applications (think very small machines, like PDAs). I don't, however, think that our initial implementations should focus on this. :) -Here are some other auxilliary goals that I think we should consider: +Here are some other auxiliary goals that I think we should consider: 1. Primary goal: Support a high performance dynamic compilation system. This means that we have an "ideal" division of labor between diff --git a/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt b/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt index b66e18556f5e..01b644b3517f 100644 --- a/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt +++ b/docs/HistoricalNotes/2000-12-06-MeetingSummary.txt @@ -40,7 +40,7 @@ IDEAS TO CONSIDER packaged with the bytecodes themselves. As a conceptual implementation idea, we could include an immediate dominator number for each basic block in the LLVM bytecode program. Basic blocks could be numbered according - to the order of occurance in the bytecode representation. + to the order of occurrence in the bytecode representation. 2. Including loop header and body information. This would facilitate detection of intervals and natural loops. diff --git a/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt b/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt index 7b9032742a27..839732444f93 100644 --- a/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt +++ b/docs/HistoricalNotes/2001-02-06-TypeNotationDebateResp4.txt @@ -39,7 +39,7 @@ declaration and calling syntax. Very true. If you're implementing an object oriented language, however, remember that you have to do all the pointer to member function stuff -yourself.... so everytime you invoke a virtual method one is involved +yourself.... so every time you invoke a virtual method one is involved (instead of having C++ hide it for you behind "syntactic sugar"). > And the old array syntax: diff --git a/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt b/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt index 5c87330fb7ea..da5026366539 100644 --- a/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt +++ b/docs/HistoricalNotes/2001-02-09-AdveCommentsResponse.txt @@ -18,7 +18,7 @@ suggested, as specified below: Very true. We should discuss this more, but my reasoning is more of a consistency argument. There are VERY few instructions that can have all -of the types eliminated, and doing so when available unnecesarily makes +of the types eliminated, and doing so when available unnecessarily makes the language more difficult to handle. Especially when you see 'int %this' and 'bool %that' all over the place, I think it would be disorienting to see: @@ -44,7 +44,7 @@ branches). No. This was something I was debating for a while, and didn't really feel strongly about either way. It is common to switch on other types in HLL's -(for example signed int's are particually common), but in this case, all +(for example signed int's are particularly common), but in this case, all that will be added is an additional 'cast' instruction. I removed that from the spec. @@ -160,7 +160,7 @@ that can be trivally translated into a conditional move... > I agree that we need a static data space. Otherwise, emulating global > data gets unnecessarily complex. -Definately. Also a later item though. :) +Definitely. Also a later item though. :) > We once talked about adding a symbolic thread-id field to each > .. diff --git a/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt b/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt index 6c9e0971a04d..e61042fd657a 100644 --- a/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt +++ b/docs/HistoricalNotes/2001-06-01-GCCOptimizations2.txt @@ -42,7 +42,7 @@ Does using GCC's backend buy us anything? > optimization (step 16 in your list). Do you have a breakdown of that? Not really. The irritating part of GCC is that it mixes it all up and -doesn't have a clean seperation of concerns. A lot of the "back end +doesn't have a clean separation of concerns. A lot of the "back end optimization" happens right along with other data optimizations (ie, CSE of machine specific things). diff --git a/docs/HistoricalNotes/2002-05-12-InstListChange.txt b/docs/HistoricalNotes/2002-05-12-InstListChange.txt index 004edb068d73..638682b49fda 100644 --- a/docs/HistoricalNotes/2002-05-12-InstListChange.txt +++ b/docs/HistoricalNotes/2002-05-12-InstListChange.txt @@ -17,7 +17,7 @@ iterator to an instruction, which, given just an Instruction*, requires a linear search of the basic block the instruction is contained in... just to insert an instruction before another instruction, or to delete an instruction! This complicates algorithms that should be very simple (like -simple constant propogation), because they aren't actually sparse anymore, +simple constant propagation), because they aren't actually sparse anymore, they have to traverse basic blocks to remove constant propogated instructions. diff --git a/docs/HowToReleaseLLVM.html b/docs/HowToReleaseLLVM.html index 7663321fdb82..f52f326eef62 100644 --- a/docs/HowToReleaseLLVM.html +++ b/docs/HowToReleaseLLVM.html @@ -7,7 +7,7 @@ -
      How To Release LLVM To The Public
      +

      How To Release LLVM To The Public

      1. Introduction
      2. Qualification Criteria
        3. @@ -17,495 +17,597 @@

        Written by Tanya Lattner, Reid Spencer, - John Criswell + John Criswell, & + Bill Wendling

        -
        Introduction
        +

        Introduction

        -
        -

        - This document collects information about successfully releasing LLVM - (including subprojects llvm-gcc and Clang) to the public. - It is the release manager's responsibility to ensure that a high quality - build of LLVM is released. -

        +
        + +

        This document contains information about successfully releasing LLVM — + including subprojects: e.g., llvm-gcc and clang — to + the public. It is the Release Manager's responsibility to ensure that a high + quality build of LLVM is released.

        +
        -
        Release Timeline
        +

        Release Timeline

        -
        -

        LLVM is released on a time based schedule (currently every 6 months). We - do not have dot releases because of the nature of LLVM incremental - development philosophy. The release schedule is roughly as follows: -

        -
          -
        1. Set code freeze and branch creation date for 6 months after last code freeze -date. Announce release schedule to the LLVM community and update the website.
          2. -
        2. Create release branch and begin release process.
          3. -
        3. Send out pre-release for first round of testing. Testing will last 7-10 days. -During the first round of testing, regressions should be found and fixed. Patches -are merged from mainline to the release branch.
          4. -
        4. Generate and send out second pre-release. Bugs found during this time will -not be fixed unless absolutely critical. Bugs introduce by patches merged in -will be fixed and if so, a 3rd round of testing is needed.
          5. -
        5. The release notes should be updated during the first and second round of -pre-release testing.
          6. -
        6. Finally, release!
          7. -
        -
        +
        + +

        LLVM is released on a time based schedule — roughly every 6 months. We + do not normally have dot releases because of the nature of LLVM's incremental + development philosophy. That said, the only thing preventing dot releases for + critical bug fixes from happening is a lack of resources — testers, + machines, time, etc. And, because of the high quality we desire for LLVM + releases, we cannot allow for a truncated form of release qualification.

        + +

        The release process is roughly as follows:

        + +
          +

        • Set code freeze and branch creation date for 6 months after last code + freeze date. Announce release schedule to the LLVM community and update + the website.

          • + +

        • Create release branch and begin release process.

          • + +

        • Send out release candidate sources for first round of testing. Testing + lasts 7-10 days. During the first round of testing, any regressions found + should be fixed. Patches are merged from mainline into the release + branch. Also, all features need to be completed during this time. Any + features not completed at the end of the first round of testing will be + removed or disabled for the release.

          • +

        • Generate and send out the second release candidate sources. Only + critial bugs found during this testing phase will be fixed. Any + bugs introduced by merged patches will be fixed. If so a third round of + testing is needed.

          • + +

        • The release notes are updated.

          • + +

        • Finally, release!

          • +
        + +
        -
        Release Process
        +

        Release Process

        -
        + + +
      -
      -Release Administrative Tasks
      - -
      -This section describes a few administrative tasks that need to be done for the -release process to begin. Specifically, it involves creating the release branch, - resetting version numbers, and creating the release tarballs for the release - team to begin testing. -
      +

      Release Administrative Tasks

      + +
      + +

      This section describes a few administrative tasks that need to be done for + the release process to begin. Specifically, it involves:

      + +
        +
      • Creating the release branch,
        • +
      • Setting version numbers, and
        • +
      • Tagging release candidates for the release team to begin testing
        • +
      -
      Create Release Branch
      -
      -

      Branch the Subversion HEAD using the following procedure:

      -
        -
      1. -

        Verify that the current Subversion HEAD is in decent shape by examining - nightly tester or buildbot results.

        2. -
      2. -

        Request all developers to refrain from committing. Offenders get commit - rights taken away (temporarily).

        3. -
      3. -

        Create the release branch for llvm, llvm-gcc4.2, - clang, and the test-suite. The branch name will be - release_XX,where XX is the major and minor release numbers. - Clang will have a different release number than llvm/ - llvm-gcc4 since its first release was years later - (still deciding if this will be true or not). These branches - can be created without checking out anything from subversion. -

        +

        Create Release Branch

        + +
        + +

        Branch the Subversion trunk using the following procedure:

        + +
          +

        1. Remind developers that the release branching is imminent and to refrain + from committing patches that might break the build. E.g., new features, + large patches for works in progress, an overhaul of the type system, an + exciting new TableGen feature, etc.

          2. + +

        2. Verify that the current Subversion trunk is in decent shape by + examining nightly tester and buildbot results.

          3. + +

        3. Create the release branch for llvm, llvm-gcc-4.2, + clang, and the test-suite from the last known good + revision. The branch's name is release_XY, where X is + the major and Y the minor release numbers. The branches should be + created using the following commands:

          -
          +
          -svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
-         https://llvm.org/svn/llvm-project/llvm/branches/release_XX
-svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \
-         https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX
-svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
-         https://llvm.org/svn/llvm-project/test-suite/branches/release_XX
-svn copy https://llvm.org/svn/llvm-project/cfe/trunk \
-         https://llvm.org/svn/llvm-project/cfe/branches/release_XX
+$ svn copy https://llvm.org/svn/llvm-project/llvm/trunk \
+           https://llvm.org/svn/llvm-project/llvm/branches/release_XY
+
+$ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/trunk \
+           https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY
+
+$ svn copy https://llvm.org/svn/llvm-project/test-suite/trunk \
+           https://llvm.org/svn/llvm-project/test-suite/branches/release_XY
+
+$ svn copy https://llvm.org/svn/llvm-project/cfe/trunk \
+           https://llvm.org/svn/llvm-project/cfe/branches/release_XY
          -
          +
          4. -
        4. -

          Advise developers they can work on Subversion HEAD again.

          5. - -
        5. -

          The Release Manager should switch to the release branch (as all changes - to the release will now be done in the branch). The easiest way to do this - is to grab another working copy using the following commands:

          +

        6. Advise developers that they may now check their patches into the + Subversion tree again.

          7. + +

        7. The Release Manager should switch to the release branch, because all + changes to the release will now be done in the branch. The easiest way to + do this is to grab a working copy using the following commands:

          -svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XX
-svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX
-svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XX
-svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XX
+$ svn co https://llvm.org/svn/llvm-project/llvm/branches/release_XY llvm-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY llvm-gcc-4.2-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/test-suite/branches/release_XY test-suite-X.Y
+
+$ svn co https://llvm.org/svn/llvm-project/cfe/branches/release_XY clang-X.Y
          8. +
        -
      -
      Update LLVM Version
      -
      -

      - After creating the LLVM release branch, update the release branches' - autoconf/configure.ac version from X.Xsvn to just X.X. Update it on mainline - as well to be the next version (X.X+1svn). Regenerated the configure script - for both. This must be done for both llvm and the - test-suite. -

      -

      FIXME: Add a note about clang.

      -

      In addition, the version number of all the Bugzilla components must be - updated for the next release. -

      +

      Update LLVM Version

      + +
      + +

      After creating the LLVM release branch, update the release branches' + autoconf and configure.ac versions from 'X.Ysvn' + to 'X.Y'. Update it on mainline as well to be the next version + ('X.Y+1svn'). Regenerate the configure scripts for both + llvm and the test-suite.

      + +

      In addition, the version numbers of all the Bugzilla components must be + updated for the next release.

      +
      -
      Build the LLVM Source Distributions
      -
      -

      - Create source distributions for LLVM, LLVM-GCC, - clang, and the llvm test-suite by exporting the source from - Subversion and archiving it. This can be done with the following commands: -

      +

      Build the LLVM Release Candidates

      + +
      + +

      Create release candidates for llvm, llvm-gcc, + clang, and the LLVM test-suite by tagging the branch with + the respective release candidate number. For instance, to create Release + Candidate 1 you would issue the following commands:

      -svn export https://llvm.org/svn/llvm-project/llvm/branches/release_XX llvm-X.X
-svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX llvm-gcc4.2-X.X.source
-svn export https://llvm.org/svn/llvm-project/test-suite/branches/release_XX llvm-test-X.X
-svn export https://llvm.org/svn/llvm-project/cfe/branches/release_XX clang-X.X
-tar -czvf - llvm-X.X          | gzip > llvm-X.X.tar.gz
-tar -czvf - llvm-test-X.X     | gzip > llvm-test-X.X.tar.gz
-tar -czvf - llvm-gcc4.2-X.X.source | gzip > llvm-gcc-4.2-X.X.source.tar.gz
-tar -czvf - clang-X.X | gzip > clang-X.X.tar.gz
+$ svn mkdir https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY
+$ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \
+           https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/rc1
+
+$ svn mkdir https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XY
+$ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY \
+           https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XY/rc1
+
+$ svn mkdir https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY
+$ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \
+           https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/rc1
+
+$ svn mkdir https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY
+$ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
+           https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/rc1
      + +

      Similarly, Release Candidate 2 would be named RC2 and so + on. This keeps a permanent copy of the release candidate around for people to + export and build as they wish. The final released sources will be tagged in + the RELEASE_XY directory as Final + (c.f. Tag the LLVM Final Release).

      + +

      The Release Manager may supply pre-packaged source tarballs for users. This + can be done with the following commands:

      + +
      +
      +$ svn export https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/rc1 llvm-X.Yrc1
+$ svn export https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XY/rc1 llvm-gcc4.2-X.Yrc1
+$ svn export https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/rc1 llvm-test-X.Yrc1
+$ svn export https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/rc1 clang-X.Yrc1
+
+$ tar -cvf - llvm-X.Yrc1        | gzip > llvm-X.Yrc1.src.tar.gz
+$ tar -cvf - llvm-test-X.Yrc1   | gzip > llvm-test-X.Yrc1.src.tar.gz
+$ tar -cvf - llvm-gcc4.2-X.Yrc1 | gzip > llvm-gcc-4.2-X.Yrc1.src.tar.gz
+$ tar -cvf - clang-X.Yrc1       | gzip > clang-X.Yrc1.src.tar.gz
+
      +
      + +
      +
      -
      -Building the Release
      +

      Building the Release

      -
      -The build of llvm, llvm-gcc, and clang must be free -of errors and warnings in both debug, release+asserts, and release builds. -If all builds are clean, then the release passes build qualification. +
      -
        -
      1. debug: ENABLE_OPTIMIZED=0
        2. -
      2. release+asserts: ENABLE_OPTIMIZED=1
        3. -
      3. release: ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1
        4. -
      -
      +

      The builds of llvm, llvm-gcc, and clang + must be free of errors and warnings in Debug, Release+Asserts, and + Release builds. If all builds are clean, then the release passes Build + Qualification.

      + +

      The make options for building the different modes:

      + + + + + + +
      ModeOptions
      DebugENABLE_OPTIMIZED=0
      Release+AssertsENABLE_OPTIMIZED=1
      ReleaseENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1
      -
      Build LLVM
      -
      -

      - Build both debug, release+asserts (optimized), and release versions of - LLVM on all supported platforms. Direction to build llvm are - here. -

      +

      Build LLVM

      + +
      + +

      Build Debug, Release+Asserts, and Release versions + of llvm on all supported platforms. Directions to build + llvm are + here.

      +
      -
      Build the LLVM GCC Binary Distribution
      -
      -

      - Creating the LLVM GCC binary distribution (release/optimized) requires - performing the following steps for each supported platform: -

      +

      Build the LLVM GCC Binary Distribution

      + +
      + +

      Creating the llvm-gcc binary distribution (Release/Optimized) + requires performing the following steps for each supported platform:

      + +
        +

      1. Build the llvm-gcc front-end by following the directions in + the README.LLVM file. The front-end must be compiled with C, C++, + Objective-C (Mac only), Objective-C++ (Mac only), and Fortran + support.

        2. + +

      2. Boostrapping must be enabled.

        3. + +

      3. Be sure to build with LLVM_VERSION_INFO=X.Y, where X + is the major and Y is the minor release numbers.

        4. + +

      4. Copy the installation directory to a directory named for the specific + target. For example on Red Hat Enterprise Linux, the directory would be + named llvm-gcc4.2-2.6-x86-linux-RHEL4. Archive and compress the + new directory.

        5. +
      -
        -
      1. - Build the LLVM GCC front-end by following the directions in the README.LLVM - file. The frontend must be compiled with c, c++, objc (mac only), - objc++ (mac only) and fortran support.
        2. -
      2. Please boostrap as well.
        3. -
      3. Be sure to build with LLVM_VERSION_INFO=X.X, where X is the major and - minor release numbers. -
        4. - -
      4. - Copy the installation directory to a directory named for the specific target. - For example on Red Hat Enterprise Linux, the directory would be named - llvm-gcc4.2-2.6-x86-linux-RHEL4. Archive and compress the new directory. -
        5. -
      -
      Build Clang -Binary Distribution
      -
      -

      - Creating the Clang binary distribution (debug/release/release) requires - performing the following steps for each supported platform: -

      +

      Build Clang Binary Distribution

      -
        -
      1. - Build clang according to the directions - here. -
        2. - -
      2. Build both a debug and release version of clang, but the binary - will be a release build.
        3. - -
      3. - Package clang (details to follow). -
        4. -
      -
      +
      + +

      Creating the clang binary distribution + (Debug/Release+Asserts/Release) requires performing the following steps for + each supported platform:

      + +
        +
      1. Build clang according to the directions + here.
        2. + +
      2. Build both a debug and release version of clang. The binary will be the + release build.
        3. + +
      3. Package clang (details to follow).
        4. +
      +
      -
      Target Specific Build -Details
      -
      -

      - The table below specifies which compilers are used for each arch/os combination - when qualifying the build of llvm, llvm-gcc, clang. -

      - -

      - +

      Target Specific Build Details

      + +
      + +

      The table below specifies which compilers are used for each Arch/OS + combination when qualifying the build of llvm, llvm-gcc, + and clang.

      + +
      - + - -
      ArchitectureOScompiler
      x86-32Mac OS 10.5gcc 4.0.1
      x86-32Linuxgcc 4.2.X, gcc 4.3.X
      x86-32FreeBSDgcc 4.2.X
      x86-32mingwgcc 3.4.5
      x86-32mingwgcc 3.4.5
      x86-64Mac OS 10.5gcc 4.0.1
      x86-64Linuxgcc 4.2.X, gcc 4.3.X
      x86-64FreeBSDgcc 4.2.X
      -

      +
      +
      -
      -Building the Release
      - -
      - A release is qualified when it has no regressions from the previous - release (or baseline). Regressions are related to correctness only and not - performance at this time. Regressions are new failures in the set of tests that - are used to qualify each product and only include things on the list. - Ultimately, there is no end to the number of possible bugs in a release. We - need a very concrete and definitive release criteria that ensures we have - monotonically improving quality on some metric. The metric we use is - described below. This doesn't mean that we don't care about other things, - but this are things that must be satisfied before a release can go out -
      +

      Building the Release

      +
      + +

      A release is qualified when it has no regressions from the previous release + (or baseline). Regressions are related to correctness first and performance + second. (We may tolerate some minor performance regressions if they are + deemed necessary for the general quality of the compiler.)

      + +

      Regressions are new failures in the set of tests that are used to qualify + each product and only include things on the list. Every release will have + some bugs in it. It is the reality of developing a complex piece of + software. We need a very concrete and definitive release criteria that + ensures we have monotonically improving quality on some metric. The metric we + use is described below. This doesn't mean that we don't care about other + criteria, but these are the criteria which we found to be most important and + which must be satisfied before a release can go out

      -
      Qualify LLVM
      -
      -

      - LLVM is qualified when it has a clean dejagnu test run without a frontend and - it has no regressions when using either llvm-gcc or clang - with the test-suite from the previous release. -

      +

      Qualify LLVM

      + +
      + +

      LLVM is qualified when it has a clean test run without a front-end. And it + has no regressions when using either llvm-gcc or clang with + the test-suite from the previous release.

      +
      -
      Qualify LLVM-GCC
      -
      -

      - LLVM-GCC is qualified when front-end specific tests in the - llvm dejagnu test suite all pass and there are no regressions in - the test-suite.

      -

      We do not use the gcc dejagnu test suite as release criteria.

      +

      Qualify LLVM-GCC

      + +
      + +

      LLVM-GCC is qualified when front-end specific tests in the + llvm regression test suite all pass and there are no regressions in + the test-suite.

      + +

      We do not use the GCC DejaGNU test suite as release criteria.

      +
      -
      Qualify Clang
      -
      - Clang is qualified when front-end specific tests in the - llvm dejagnu test suite all pass, clang's own test suite passes - cleanly, and there are no regressions in the test-suite.

      +

      Qualify Clang

      + +
      + +

      Clang is qualified when front-end specific tests in the + llvm dejagnu test suite all pass, clang's own test suite passes + cleanly, and there are no regressions in the test-suite.

      +
      -
      Specific Target -Qualification Details
      -
      -

      - +

      Specific Target Qualification Details

      + +
      + +
      ArchitectureOSllvm-gcc baselineclang baseline - tests
      + -
      ArchitectureOSllvm-gcc baselineclang baselinetests
      x86-32Linuxlast releaselast releasellvm dejagnu, clang tests, test-suite (including spec)
      x86-32FreeBSDnonelast releasellvm dejagnu, clang tests, test-suite
      x86-32mingwlast releasenoneQT
      x86-64Mac OS 10.Xlast releaselast releasellvm dejagnu, clang tests, test-suite (including spec)
      x86-64Linuxlast releaselast releasellvm dejagnu, clang tests, test-suite (including spec)
      x86-64FreeBSDnonelast releasellvm dejagnu, clang tests, test-suite

      + + +
      +
      -
      Community Testing
      -
      -

      - Once all testing has been completed and appropriate bugs filed, the pre-release - tar balls may be put on the website and the LLVM community is notified. Ask that - all LLVM developers test the release in 2 ways:

      -
        -
      1. Download llvm-X.X, llvm-test-X.X, and the appropriate llvm-gcc4 - and/or clang binary. Build LLVM. - Run "make check" and the full llvm-test suite (make TEST=nightly report).
        2. -
      2. Download llvm-X.X, llvm-test-X.X, and the llvm-gcc4 and/or clang source. - Compile everything. Run "make check" and the full llvm-test suite (make TEST=nightly - report).
        3. -
      -

      Ask LLVM developers to submit the report and make check results to the list. - Attempt to verify that there are no regressions from the previous release. - The results are not used to qualify a release, but to spot other potential - problems. For unsupported targets, verify that make check at least is - clean.

      +

      Community Testing

      +
      + +

      Once all testing has been completed and appropriate bugs filed, the release + candidate tarballs are put on the website and the LLVM community is + notified. Ask that all LLVM developers test the release in 2 ways:

      + +
        +
      1. Download llvm-X.Y, llvm-test-X.Y, and the + appropriate llvm-gcc and/or clang binary. Build + LLVM. Run make check and the full LLVM test suite (make + TEST=nightly report).
        2. + +
      2. Download llvm-X.Y, llvm-test-X.Y, and the + llvm-gcc and/or clang source. Compile everything. Run + make check and the full LLVM test suite (make TEST=nightly + report).
        3. +
      + +

      Ask LLVM developers to submit the test suite report and make check + results to the list. Verify that there are no regressions from the previous + release. The results are not used to qualify a release, but to spot other + potential problems. For unsupported targets, verify that make check + is at least clean.

      -

      During the first round of testing time, - all regressions must be fixed before the second pre-release is created.

      +

      During the first round of testing, all regressions must be fixed before the + second release candidate is tagged.

      -

      If this is the second round of testing, this is only to ensure the bug - fixes previously merged in have not created new major problems. This is not - the time to solve additional and unrelated bugs. If no patches are merged in, - the release is determined to be ready and the release manager may move onto - the next step. -

      +

      If this is the second round of testing, the testing is only to ensure that + bug fixes previously merged in have not created new major problems. This + is not the time to solve additional and unrelated bugs! If no patches are + merged in, the release is determined to be ready and the release manager may + move onto the next stage.

      +
      -
      Release Patch Rules -
      -
      -

      - Below are the rules regarding patching the release branch.

      -

      -

    3. Patches applied to the release branch are only applied by the release - manager.
      4. -
    4. During the first round of testing, patches that fix regressions or that - are small and relatively risk free (verified by the appropriate code owner) - are applied to the branch. Code owners are asked to be very conservative in - approving patches for the branch and we reserve the right to reject any patch - that does not fix a regression as previously defined.
      5. -
    5. During the remaining rounds of testing, only patches that fix regressions - may be applied.
      6. - -

      -
      +

      Release Patch Rules

      +
      + +

      Below are the rules regarding patching the release branch:

      + +
        +

      1. Patches applied to the release branch may only be applied by the + release manager.

        2. + +

      2. During the first round of testing, patches that fix regressions or that + are small and relatively risk free (verified by the appropriate code + owner) are applied to the branch. Code owners are asked to be very + conservative in approving patches for the branch. We reserve the right to + reject any patch that does not fix a regression as previously + defined.

        3. + +

      3. During the remaining rounds of testing, only patches that fix critical + regressions may be applied.

        4. +
      - -
      Release Final Tasks -
      -
      -

      - The final stages of the release process involving tagging the release branch, - updating documentation that refers to the release, and updating the demo - page.

      -

      FIXME: Add a note if anything needs to be done to the clang website. - Eventually the websites will be merged hopefully.

      + +

      Release Final Tasks

      + +
      + +

      The final stages of the release process involves tagging the "final" release + branch, updating documentation that refers to the release, and updating the + demo page.

      -
      Update Documentation
      -
      -

      - Review the documentation and ensure that it is up to date. The Release Notes - must be updated to reflect bug fixes, new known issues, and changes in the - list of supported platforms. The Getting Started Guide should be updated to - reflect the new release version number tag avaiable from Subversion and - changes in basic system requirements. Merge both changes from mainline into - the release branch. -

      +

      Update Documentation

      + +
      + +

      Review the documentation and ensure that it is up to date. The "Release + Notes" must be updated to reflect new features, bug fixes, new known issues, + and changes in the list of supported platforms. The "Getting Started Guide" + should be updated to reflect the new release version number tag avaiable from + Subversion and changes in basic system requirements. Merge both changes from + mainline into the release branch.

      +
      -
      Tag the Release Branch
      -
      -

      Tag the release branch using the following procedure:

      +

      Tag the LLVM Final Release

      + +
      + +

      Tag the final release sources using the following procedure:

      + 
      -svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XX \
-         https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XX
-svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XX \
-         https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XX
-svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \
-         https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XX
+$ svn copy https://llvm.org/svn/llvm-project/llvm/branches/release_XY \
+           https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_XY/Final
+
+$ svn copy https://llvm.org/svn/llvm-project/llvm-gcc-4.2/branches/release_XY \
+           https://llvm.org/svn/llvm-project/llvm-gcc-4.2/tags/RELEASE_XY/Final
+
+$ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XY \
+           https://llvm.org/svn/llvm-project/test-suite/tags/RELEASE_XY/Final
+
+$ svn copy https://llvm.org/svn/llvm-project/cfe/branches/release_XY \
+           https://llvm.org/svn/llvm-project/cfe/tags/RELEASE_XY/Final
      +
      +
      + + +

      Update the LLVM Demo Page

      +
      + +

      The LLVM demo page must be updated to use the new release. This consists of + using the new llvm-gcc binary and building LLVM.

      -
      Update the LLVM Demo Page
      -
      -

      - The LLVM demo page must be updated to use the new release. This consists of - using the llvm-gcc binary and building LLVM. Update the website demo page - configuration to use the new release.

      +

      Update the LLVM Website

      + +
      + +

      The website must be updated before the release announcement is sent out. Here + is what to do:

      + +
        +
      1. Check out the www module from Subversion.
        2. + +
      2. Create a new subdirectory X.Y in the releases directory.
        3. + +
      3. Commit the llvm, test-suite, llvm-gcc source, + clang source, clang binaries, and llvm-gcc + binaries in this new directory.
        4. + +
      4. Copy and commit the llvm/docs and LICENSE.txt files + into this new directory. The docs should be built with + BUILD_FOR_WEBSITE=1.
        5. + +
      5. Commit the index.html to the release/X.Y directory to + redirect (use from previous release.
        6. + +
      6. Update the releases/download.html file with the new release.
        7. + +
      7. Update the releases/index.html with the new release and link to + release documentation.
        8. + +
      8. Finally, update the main page (index.html and sidebar) to point + to the new release and release announcement. Make sure this all gets + committed back into Subversion.
        9. +
      +
      -
      Update the LLVM Website
      -
      -

      - The website must be updated before the release announcement is sent out. Here is - what to do:

      -
        -
      1. Check out the website module from CVS.
        2. -
      2. Create a new subdirectory X.X in the releases directory.
        3. -
      3. Commit the llvm, test-suite, llvm-gcc source, - clang source, clang binaries, - and llvm-gcc binaries in this new directory.
        4. -
      4. Copy and commit the llvm/docs and LICENSE.txt - files into this new directory. The docs should be built with BUILD_FOR_WEBSITE=1.
        5. -
      5. Commit the index.html to the release/X.X directory to redirect (use from previous - release.
        6. -
      6. Update the releases/download.html file with the new release.
        7. -
      7. Update the releases/index.html with the new release and link to - release documentation.
        8. -
      8. Finally, update the main page (index.html and sidebar) to - point to the new release and release announcement. Make sure this all gets - committed back into Subversion.
        9. -
      +

      Announce the Release

      + +
      + +

      Have Chris send out the release announcement when everything is finished.

      + +
      +
      - -
      Announce the Release
      -
      -

      Have Chris send out the release announcement when everything is finished.

      @@ -515,9 +617,9 @@ svn copy https://llvm.org/svn/llvm-project/test-suite/branches/release_XX \ src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"> Valid HTML 4.01 - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-07-07 09:48:00 +0200 (Wed, 07 Jul 2010) $ + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/HowToSubmitABug.html b/docs/HowToSubmitABug.html index 64c6141ec7b1..54f548cefd90 100644 --- a/docs/HowToSubmitABug.html +++ b/docs/HowToSubmitABug.html @@ -7,9 +7,9 @@ -
      +

      How to submit an LLVM bug report -

      + @@ -37,12 +37,12 @@
      -
      +

      Introduction - Got bugs? -

      + -
      +

      If you're working with LLVM and run into a bug, we definitely want to know about it. This document describes what you can do to increase the odds of @@ -76,12 +76,12 @@ information:

      -
      +

      Crashing Bugs -

      + -
      +

      More often than not, bugs in the compiler cause it to crash—often due to an assertion failure of some sort. The most important @@ -109,14 +109,12 @@ with the following extra command line options:

      -
      - -
      +

      Front-end bugs -

      + -
      +

      If the problem is in the front-end, you should re-run the same llvm-gcc command that resulted in the crash, but add the @@ -137,11 +135,11 @@ has instructions on the best way to use delta.

      -
      +

      Compile-time optimization bugs -

      + -
      +

      If you find that a bug crashes in the optimizer, compile your test-case to a .bc file by passing "-emit-llvm -O0 -c -o foo.bc". @@ -171,11 +169,11 @@ that bugpoint emits. If something goes wrong with bugpoint, please submit the

      -
      +

      Code generator bugs -

      + -
      +

      If you find a bug that crashes llvm-gcc in the code generator, compile your source file to a .bc file by passing "-emit-llvm -c -o foo.bc" @@ -207,13 +205,15 @@ that bugpoint emits. If something goes wrong with bugpoint, please submit the

      +
      + -
      +

      Miscompilations -

      + -
      +

      If llvm-gcc successfully produces an executable, but that executable doesn't run right, this is either a bug in the code or a bug in the @@ -241,12 +241,12 @@ error.

      -
      +

      Incorrect code generation -

      + -
      +

      Similarly to debugging incorrect compilation by mis-behaving passes, you can debug incorrect code generation by either LLC or the JIT, using @@ -338,9 +338,9 @@ the following:

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
      - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/LangRef.html b/docs/LangRef.html index 580ae7964b5a..0e37e8231c82 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -12,7 +12,7 @@ -
      LLVM Language Reference Manual
      +

      LLVM Language Reference Manual

      1. Abstract
      2. Introduction
        3. @@ -321,10 +321,10 @@
      -
      Abstract
      +

      Abstract

      -
      +

      This document is a reference manual for the LLVM assembly language. LLVM is a Static Single Assignment (SSA) based representation that provides type @@ -335,10 +335,10 @@

      -
      Introduction
      +

      Introduction

      -
      +

      The LLVM code representation is designed to be used in three different forms: as an in-memory compiler IR, as an on-disk bitcode representation (suitable @@ -359,12 +359,12 @@ variable is never accessed outside of the current function, allowing it to be promoted to a simple SSA value instead of a memory location.

      -
      - -
      Well-Formedness
      +

      + Well-Formedness +

      -
      +

      It is important to note that this document describes 'well formed' LLVM assembly language. There is a difference between what the parser accepts and @@ -384,13 +384,15 @@

      +
      + -
      Identifiers
      +

      Identifiers

      -
      +

      LLVM identifiers come in two basic types: global and local. Global identifiers (functions, global variables) begin with the '@' @@ -475,14 +477,15 @@

      -
      High Level Structure
      +

      High Level Structure

      - +
      -
      Module Structure -
      +

      + Module Structure +

      -
      +

      LLVM programs are composed of "Module"s, each of which is a translation unit of the input programs. Each module consists of functions, global variables, @@ -528,11 +531,11 @@ define i32 @main() { ; i32()*  

      -
      +

      Linkage Types -

      + -
      +

      All Global Variables and Functions have one of the following types of linkage:

      @@ -677,11 +680,11 @@ define i32 @main() { ; i32()*  
      -
      +

      Calling Conventions -

      + -
      +

      LLVM functions, calls and invokes can all have an optional calling @@ -750,11 +753,11 @@ define i32 @main() { ; i32()*  

      -
      +

      Visibility Styles -

      + -
      +

      All Global Variables and Functions have one of the following visibility styles:

      @@ -784,11 +787,11 @@ define i32 @main() { ; i32()*  
      -
      +

      Named Types -

      + -
      +

      LLVM IR allows you to specify name aliases for certain types. This can make it easier to read the IR and make the IR more condensed (particularly when @@ -815,11 +818,11 @@ define i32 @main() { ; i32()*  

      -
      +

      Global Variables -

      + -
      +

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

      +

      Functions -

      + -
      +

      LLVM function definitions consist of the "define" keyword, an optional linkage type, an optional @@ -946,11 +949,11 @@ define [linkage] [visibility]

      -
      +

      Aliases -

      + -
      +

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

      -
      +

      Named Metadata -

      + -
      +

      Named metadata is a collection of metadata. Metadata nodes (but not metadata strings) are the only valid operands for @@ -988,9 +991,11 @@ define [linkage] [visibility]

      -
      Parameter Attributes
      +

      + Parameter Attributes +

      -
      +

      The return type and each parameter of a function type may have a set of parameter attributes associated with them. Parameter attributes are @@ -1017,13 +1022,15 @@ declare signext i8 @returns_signed_char()

      zeroext
      This indicates to the code generator that the parameter or return value - should be zero-extended to a 32-bit value by the caller (for a parameter) - or the callee (for a return value).
      + should be zero-extended to the extent required by the target's ABI (which + is usually 32-bits, but is 8-bits for a i1 on x86-64) by the caller (for a + parameter) or the callee (for a return value).
      signext
      This indicates to the code generator that the parameter or return value - should be sign-extended to a 32-bit value by the caller (for a parameter) - or the callee (for a return value).
      + should be sign-extended to the extent required by the target's ABI (which + is usually 32-bits) by the caller (for a parameter) or the callee (for a + return value).
      inreg
      This indicates that this parameter or return value should be treated in a @@ -1095,11 +1102,11 @@ declare signext i8 @returns_signed_char()
      -
      +

      Garbage Collector Names -

      + -
      +

      Each function may specify a garbage collector name, which is simply a string:

      @@ -1115,11 +1122,11 @@ define void @f() gc "name" { ... }
      -
      +

      Function Attributes -

      + -
      +

      Function attributes are set to communicate additional information about a function. Function attributes are considered to be part of the function, not @@ -1238,11 +1245,11 @@ define void @f() optsize { ... }

      -
      +

      Module-Level Inline Assembly -

      + -
      +

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

      -
      +

      Data Layout -

      + -
      +

      A module may specify a target specific data layout string that specifies how data is to be laid out in memory. The syntax for the data layout is @@ -1376,11 +1383,11 @@ target datalayout = "layout specification"

      -
      +

      Pointer Aliasing Rules -

      + -
      +

      Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior @@ -1440,11 +1447,11 @@ to implement type-based alias analysis.

      -
      +

      Volatile Memory Accesses -

      + -
      +

      Certain memory accesses, such as loads, stores, and

      +
      + -
      Type System
      +

      Type System

      -
      +

      The LLVM type system is one of the most important features of the intermediate representation. Being typed enables a number of optimizations @@ -1471,13 +1480,12 @@ synchronization behavior.

      and transformations that are not feasible to perform on normal three address code representations.

      -
      - -
      Type -Classifications
      +

      + Type Classifications +

      -
      +

      The types fall into a few useful classifications:

      @@ -1534,19 +1542,21 @@ Classifications
      -
      Primitive Types
      +

      + Primitive Types +

      -
      +

      The primitive types are the fundamental building blocks of the LLVM system.

      -
      - -
      Integer Type
      +

      + Integer Type +

      -
      +
      Overview:

      The integer type is a very simple type that simply specifies an arbitrary @@ -1580,9 +1590,11 @@ Classifications

      -
      Floating Point Types
      +

      + Floating Point Types +

      -
      +
      @@ -1598,9 +1610,11 @@ Classifications -
      X86mmx Type
      +

      + X86mmx Type +

      -
      +
      Overview:

      The x86mmx type represents a value held in an MMX register on an x86 machine. The operations allowed on it are quite limited: parameters and return values, load and store, and bitcast. User-specified MMX instructions are represented as intrinsic or asm calls with arguments and/or results of this type. There are no arrays, vectors or constants of this type.

      @@ -1613,9 +1627,11 @@ Classifications
      -
      Void Type
      +

      + Void Type +

      -
      +
      Overview:

      The void type does not represent any value and has no size.

      @@ -1628,9 +1644,11 @@ Classifications
      -
      Label Type
      +

      + Label Type +

      -
      +
      Overview:

      The label type represents code labels.

      @@ -1643,9 +1661,11 @@ Classifications
      -
      Metadata Type
      +

      + Metadata Type +

      -
      +
      Overview:

      The metadata type represents embedded metadata. No derived types may be @@ -1659,11 +1679,14 @@ Classifications

      + -
      Derived Types
      +

      + Derived Types +

      -
      +

      The real power in LLVM comes from the derived types in the system. This is what allows a programmer to represent arrays, functions, pointers, and other @@ -1673,12 +1696,12 @@ Classifications

      of another array.

      -
      - -
      Aggregate Types
      +

      + Aggregate Types +

      -
      +

      Aggregate Types are a subset of derived types that can contain multiple member types. Arrays, @@ -1688,9 +1711,11 @@ Classifications

      -
      Array Type
      +

      + Array Type +

      -
      +
      Overview:

      The array type is a very simple derived type that arranges elements @@ -1746,9 +1771,11 @@ Classifications

      -
      Function Type
      +

      + Function Type +

      -
      +
      Overview:

      The function type can be thought of as a function signature. It consists of @@ -1799,9 +1826,11 @@ Classifications

      -
      Structure Type
      +

      + Structure Type +

      -
      +
      Overview:

      The structure type is used to represent a collection of data members together @@ -1837,10 +1866,11 @@ Classifications

      -
      Packed Structure Type -
      +

      + Packed Structure Type +

      -
      +
      Overview:

      The packed structure type is used to represent a collection of data members @@ -1875,9 +1905,11 @@ Classifications

      -
      Pointer Type
      +

      + Pointer Type +

      -
      +
      Overview:

      The pointer type is used to specify memory locations. @@ -1919,9 +1951,11 @@ Classifications

      -
      Vector Type
      +

      + Vector Type +

      -
      +
      Overview:

      A vector type is a simple derived type that represents a vector of elements. @@ -1958,8 +1992,11 @@ Classifications

      -
      Opaque Type
      -
      +

      + Opaque Type +

      + +
      Overview:

      Opaque types are used to represent unknown types in the system. This @@ -1982,12 +2019,14 @@ Classifications

      + + -
      +

      Type Up-references -

      + -
      +
      Overview:

      An "up reference" allows you to refer to a lexically enclosing type without @@ -2030,21 +2069,23 @@ Classifications

      + + -
      Constants
      +

      Constants

      -
      +

      LLVM has several different basic types of constants. This section describes them all and their syntax.

      -
      - -
      Simple Constants
      +

      + Simple Constants +

      -
      +
      Boolean constants
      @@ -2097,12 +2138,12 @@ Classifications
      -
      +

      Complex Constants -

      + -
      +

      Complex constants are a (potentially recursive) combination of simple constants and smaller complex constants.

      @@ -2152,11 +2193,11 @@ Classifications
      -
      +

      Global Variable and Function Addresses -

      + -
      +

      The addresses of global variables and functions are always implicitly valid @@ -2174,8 +2215,11 @@ Classifications

      -
      Undefined Values
      -
      +

      + Undefined Values +

      + +

      The string 'undef' can be used anywhere a constant is expected, and indicates that the user of the value may receive an unspecified bit-pattern. @@ -2314,8 +2358,11 @@ b: unreachable

      -
      Trap Values
      -
      +

      + Trap Values +

      + +

      Trap values are similar to undef values, however instead of representing an unspecified bit pattern, they represent the @@ -2367,7 +2414,12 @@ b: unreachable terminator instruction if the terminator instruction has multiple successors and the instruction is always executed when control transfers to one of the successors, and - may not be executed when control is transfered to another. + may not be executed when control is transferred to another. + +

    6. Additionally, an instruction also control-depends on a terminator + instruction if the set of instructions it otherwise depends on would be + different if the terminator had transferred control to a different + successor.
    7. Dependence is transitive.
      8. @@ -2411,17 +2463,34 @@ end: ; control-dependent on %cmp, so this ; always results in a trap value. - volatile store i32 0, i32* @g ; %end is control-equivalent to %entry - ; so this is defined (ignoring earlier + volatile store i32 0, i32* @g ; This would depend on the store in %true + ; if %cmp is true, or the store in %entry + ; otherwise, so this is undefined behavior. + + %br i1 %cmp, %second_true, %second_end + ; The same branch again, but this time the + ; true block doesn't have side effects. + +second_true: + ; No side effects! + br label %end + +second_end: + volatile store i32 0, i32* @g ; This time, the instruction always depends + ; on the store in %end. Also, it is + ; control-equivalent to %end, so this is + ; well- defined (again, ignoring earlier ; undefined behavior in this example).
      -
      Addresses of Basic - Blocks
      -
      +

      + Addresses of Basic Blocks +

      + +

      blockaddress(@function, %block)

      @@ -2446,10 +2515,11 @@ end: -
      Constant Expressions -
      +

      + Constant Expressions +

      -
      +

      Constant expressions are used to allow expressions involving other constants to be used as constants. Constant expressions may be of @@ -2575,16 +2645,18 @@ end:

      +
      + -
      Other Values
      +

      Other Values

      - +
      -
      +

      Inline Assembler Expressions -

      + -
      +

      LLVM supports inline assembler expressions (as opposed to Module-Level Inline Assembly) through the use of @@ -2633,13 +2705,12 @@ call void asm alignstack "eieio", ""() documented here. Constraints on what can be done (e.g. duplication, moving, etc need to be documented). This is probably best done by reference to another document that covers inline asm from a holistic perspective.

      -
      -
      +

      Inline Asm Metadata -

      + -
      +

      The call instructions that wrap inline asm nodes may have a "!srcloc" MDNode attached to it that contains a list of constant integers. If present, the @@ -2660,12 +2731,14 @@ call void asm sideeffect "something bad", ""(), !srcloc !42

      - -
      Metadata Nodes and Metadata - Strings
      -
      + +

      + Metadata Nodes and Metadata Strings +

      + +

      LLVM IR allows metadata to be attached to instructions in the program that can convey extra information about the code to the optimizers and code @@ -2690,25 +2763,31 @@ call void asm sideeffect "something bad", ""(), !srcloc !42

      Metadata can be used as function arguments. Here llvm.dbg.value function is using two metadata arguments.

      - 
      -       call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
-
      +
      +
      +call void @llvm.dbg.value(metadata !24, i64 0, metadata !25)
+
      +

      Metadata can be attached with an instruction. Here metadata !21 is attached with add instruction using !dbg identifier.

      - 
      -      %indvar.next = add i64 %indvar, 1, !dbg !21
-
      +
      +
      +%indvar.next = add i64 %indvar, 1, !dbg !21
+
      +
      +
      +
      -
      +

      Intrinsic Global Variables -

      + - +

      LLVM has a number of "magic" global variables that contain data that affect code generation or other IR semantics. These are documented here. All globals of this sort should have a section specified as "llvm.metadata". This @@ -2716,11 +2795,11 @@ section and all globals that start with "llvm." are reserved for use by LLVM.

      -
      +

      The 'llvm.used' Global Variable -

      + -
      +

      The @llvm.used global is an array with i8* element type which has appending linkage. This array contains a list of @@ -2751,11 +2830,13 @@ object file to prevent the assembler and linker from molesting the symbol.

      -
      -The 'llvm.compiler.used' Global Variable -
      +

      + + The 'llvm.compiler.used' Global Variable + +

      -
      +

      The @llvm.compiler.used directive is the same as the @llvm.used directive, except that it only prevents the compiler from @@ -2769,11 +2850,11 @@ should not be exposed to source languages.

      -
      +

      The 'llvm.global_ctors' Global Variable -

      + -
      +
       %0 = type { i32, void ()* }
 @llvm.global_ctors = appending global [1 x %0] [%0 { i32 65535, void ()* @ctor }]
@@ -2784,11 +2865,11 @@ should not be exposed to source languages.
      -
      +

      The 'llvm.global_dtors' Global Variable -

      + -
      +
       %0 = type { i32, void ()* }
 @llvm.global_dtors = appending global [1 x %0] [%0 { i32 65535, void ()* @dtor }]
@@ -2799,12 +2880,13 @@ should not be exposed to source languages.
      +
      -
      Instruction Reference
      +

      Instruction Reference

      -
      +

      The LLVM instruction set consists of several different classifications of instructions: terminator @@ -2813,13 +2895,12 @@ should not be exposed to source languages.

      memory instructions, and other instructions.

      -
      - -
      Terminator -Instructions
      +

      + Terminator Instructions +

      -
      +

      As mentioned previously, every basic block in a program ends with a "Terminator" instruction, which indicates which @@ -2837,13 +2918,12 @@ Instructions

      'unwind' instruction, and the 'unreachable' instruction.

      -
      - -
      'ret' -Instruction
      +

      + 'ret' Instruction +

      -
      +
      Syntax:
      @@ -2889,9 +2969,11 @@ Instruction
      -
      'br' Instruction
      +

      + 'br' Instruction +

      -
      +
      Syntax:
      @@ -2930,11 +3012,11 @@ IfUnequal:
      -
      +

      'switch' Instruction -

      + -
      +
      Syntax:
      @@ -2985,11 +3067,11 @@ IfUnequal:
 
 
 
-
      
+
      
    'indirectbr' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3033,11 +3115,11 @@ IfUnequal:
 
 
 
-
      
+
      
   'invoke' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3123,10 +3205,11 @@ that the invoke/unwind semantics are likely to change in future versions.
      
 
 
 
-
       'unwind'
-Instruction 
      
+
      
+  'unwind' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3154,10 +3237,11 @@ that the invoke/unwind semantics are likely to change in future versions.
      
 
 
 
-
       'unreachable'
-Instruction 
      
+
      
+  'unreachable' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3175,10 +3259,14 @@ Instruction 
      
 
 
      
 
+
      
+
 
-
       Binary Operations 
      
+
      
+  Binary Operations
+
      
 
-
      
+
      
 
 
      Binary operators are used to do most of the computation in a program.  They
    require two operands of the same type, execute an operation on them, and
@@ -3188,14 +3276,12 @@ Instruction 
      
 
 
      There are several different binary operators:
      
 
-
      
-
 
-
      
+
      
   'add' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3236,11 +3322,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
   'fadd' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3266,11 +3352,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
    'sub' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3318,11 +3404,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
    'fsub' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3354,11 +3440,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
   'mul' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3404,11 +3490,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
   'fmul' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3434,10 +3520,11 @@ Instruction 
      
 
      
 
 
-
       'udiv' Instruction
-
      
+
      
+  'udiv' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3474,10 +3561,11 @@ Instruction 
      
 
      
 
 
-
       'sdiv' Instruction
- 
      
+
      
+  'sdiv' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3516,10 +3604,11 @@ Instruction 
      
 
      
 
 
-
       'fdiv'
-Instruction 
      
+
      
+  'fdiv' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3545,10 +3634,11 @@ Instruction 
      
 
      
 
 
-
       'urem' Instruction
-
      
+
      
+  'urem' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3582,11 +3672,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
   'srem' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3606,9 +3696,10 @@ Instruction 
      
 
 
      Semantics:
      
 
      This instruction returns the remainder of a division (where the result
-   has the same sign as the dividend, op1), not the modulo
-   operator (where the result has the same sign as the divisor, op2) of
-   a value.  For more information about the difference,
+   is either zero or has the same sign as the dividend, op1), not the
+   modulo operator (where the result is either zero or has the same sign
+   as the divisor, op2) of a value.
+   For more information about the difference,
    see The
    Math Forum. For a table of how this is implemented in various languages,
    please see 
@@ -3632,10 +3723,11 @@ Instruction 
      
 
      
 
 
-
      
-  'frem' Instruction 
      
+
      
+  'frem' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3662,11 +3754,14 @@ Instruction 
      
 
 
      
 
+
      
+
 
-
       Bitwise Binary
-Operations 
      
+
      
+  Bitwise Binary Operations
+
      
 
-
      
+
      
 
 
      Bitwise binary operators are used to do various forms of bit-twiddling in a
    program.  They are generally very efficient instructions and can commonly be
@@ -3674,13 +3769,12 @@ Operations 
      
    same type, execute an operation on them, and produce a single value.  The
    resulting value is the same type as its operands.
      
 
-
      
-
 
-
       'shl'
-Instruction 
      
+
      
+  'shl' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3727,10 +3821,11 @@ Instruction 
      
 
      
 
 
-
       'lshr'
-Instruction 
      
+
      
+  'lshr' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3773,9 +3868,11 @@ Instruction 
      
 
      
 
 
-
       'ashr'
-Instruction 
      
-
      
+
      
+  'ashr' Instruction
+
      
+
+
      
 
 
      Syntax:
      
 
      @@ -3818,10 +3915,11 @@ Instruction 
      
 
      
 
 
-
       'and'
-Instruction 
      
+
      
+  'and' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3878,9 +3976,11 @@ Instruction 
      
 
      
 
      
 
-
       'or' Instruction 
      
+
      
+  'or' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -3939,10 +4039,11 @@ Instruction 
      
 
      
 
 
-
       'xor'
-Instruction 
      
+
      
+  'xor' Instruction
+
      
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -4002,12 +4103,14 @@ Instruction 
      
 
 
      
 
+
      
+
 
-
      
+
      
   Vector Operations
-
      
+
 
-
      
+
      
 
 
      LLVM supports several instructions to represent vector operations in a
    target-independent manner.  These instructions cover the element-access and
@@ -4016,14 +4119,12 @@ Instruction 
      
    will want to use target-specific intrinsics to take full advantage of a
    specific target.
      
 
-
      
-
 
-
      
+
      
    'extractelement' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -4055,11 +4156,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
    'insertelement' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -4091,11 +4192,11 @@ Instruction 
      
 
      
 
 
-
      
+
      
    'shufflevector' Instruction
-
      
+
 
-
      
+
      
 
 
      Syntax:
      
 
      @@ -4138,24 +4239,24 @@ Instruction 
      
 
 
      
 
+
      + -
      +

      Aggregate Operations -

      + -
      +

      LLVM supports several instructions for working with aggregate values.

      -
      - -
      +

      'extractvalue' Instruction -

      + -
      +
      Syntax:
      @@ -4193,11 +4294,11 @@ Instruction
      -
      +

      'insertvalue' Instruction -

      + -
      +
      Syntax:
      @@ -4231,27 +4332,26 @@ Instruction
      +
      -
      +

      Memory Access and Addressing Operations -

      + -
      +

      A key design point of an SSA-based representation is how it represents memory. In LLVM, no memory locations are in SSA form, which makes things very simple. This section describes how to read, write, and allocate memory in LLVM.

      -
      - -
      +

      'alloca' Instruction -

      + -
      +
      Syntax:
      @@ -4298,10 +4398,11 @@ Instruction
      -
      'load' -Instruction
      +

      + 'load' Instruction +

      -
      +
      Syntax:
      @@ -4356,10 +4457,11 @@ Instruction
      -
      'store' -Instruction
      +

      + 'store' Instruction +

      -
      +
      Syntax:
      @@ -4417,11 +4519,11 @@ Instruction
      -
      +

      'getelementptr' Instruction -

      + -
      +
      Syntax:
      @@ -4547,23 +4649,25 @@ entry:
      - -
      Conversion Operations
      -
      + +

      + Conversion Operations +

      + +

      The instructions in this category are the conversion instructions (casting) which all take a single operand and a type. They perform various bit conversions on the operand.

      -
      - -
      +

      'trunc .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4599,10 +4703,11 @@ entry:
      -
      +

      'zext .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4638,10 +4743,11 @@ entry:
      -
      +

      'sext .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4676,11 +4782,11 @@ entry:
      -
      +

      'fptrunc .. to' Instruction -

      + -
      +
      Syntax:
      @@ -4714,10 +4820,11 @@ entry:
      -
      +

      'fpext .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4743,17 +4850,18 @@ entry:
 
 
      Example:
      
 
      -  %X = fpext float 3.1415 to double        ; yields double:3.1415
-  %Y = fpext float 1.0 to float            ; yields float:1.0 (no-op)
+  %X = fpext float 3.125 to double         ; yields double:3.125000e+00
+  %Y = fpext double %X to fp128            ; yields fp128:0xL00000000000000004000900000000000
      -
      +

      'fptoui .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4787,10 +4895,11 @@ entry:
      -
      +

      'fptosi .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4825,10 +4934,11 @@ entry:
      -
      +

      'uitofp .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4861,10 +4971,11 @@ entry:
      -
      +

      'sitofp .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4896,10 +5007,11 @@ entry:
      -
      +

      'ptrtoint .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4933,10 +5045,11 @@ entry:
      -
      +

      'inttoptr .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -4970,10 +5083,11 @@ entry:
      -
      +

      'bitcast .. to' Instruction -

      -
      + + +
      Syntax:
      @@ -5012,21 +5126,24 @@ entry:
      +
      + -
      Other Operations
      +

      + Other Operations +

      -
      +

      The instructions in this category are the "miscellaneous" instructions, which defy better classification.

      -
      - -
      'icmp' Instruction -
      +

      + 'icmp' Instruction +

      -
      +
      Syntax:
      @@ -5125,10 +5242,11 @@ entry:
      -
      'fcmp' Instruction -
      +

      + 'fcmp' Instruction +

      -
      +
      Syntax:
      @@ -5245,11 +5363,11 @@ entry:
      -
      +

      'phi' Instruction -

      + -
      +
      Syntax:
      @@ -5293,11 +5411,11 @@ Loop:       ; Infinite loop that counts from 0 on up...
      -
      +

      'select' Instruction -

      + -
      +
      Syntax:
      @@ -5336,11 +5454,11 @@ Loop:       ; Infinite loop that counts from 0 on up...
      -
      +

      'call' Instruction -

      + -
      +
      Syntax:
      @@ -5445,11 +5563,11 @@ freestanding environments and non-C-based languages.
      -
      +

      'va_arg' Instruction -

      + -
      +
      Syntax:
      @@ -5490,11 +5608,15 @@ freestanding environments and non-C-based languages.
      +
      + +
      + -
      Intrinsic Functions
      +

      Intrinsic Functions

      -
      +

      LLVM supports the notion of an "intrinsic function". These functions have well known names and semantics and are required to follow certain @@ -5537,14 +5659,12 @@ freestanding environments and non-C-based languages.

      To learn how to add an intrinsic function, please see the Extending LLVM Guide.

      -
      - -
      +

      Variable Argument Handling Intrinsics -

      + -
      +

      Variable argument support is defined in LLVM with the va_arg instruction and these three @@ -5586,15 +5706,13 @@ declare void @llvm.va_copy(i8*, i8*) declare void @llvm.va_end(i8*) -

      - -
      +

      'llvm.va_start' Intrinsic -

      + -
      +
      Syntax:
      @@ -5620,11 +5738,11 @@ declare void @llvm.va_end(i8*)
      -
      +

      'llvm.va_end' Intrinsic -

      + -
      +
      Syntax:
      @@ -5651,11 +5769,11 @@ declare void @llvm.va_end(i8*)
      -
      +

      'llvm.va_copy' Intrinsic -

      + -
      +
      Syntax:
      @@ -5681,12 +5799,14 @@ declare void @llvm.va_end(i8*)
      +
      + -
      +

      Accurate Garbage Collection Intrinsics -

      + -
      +

      LLVM support for Accurate Garbage Collection (GC) requires the implementation and generation of these @@ -5701,14 +5821,12 @@ LLVM.

      The garbage collection intrinsics only operate on objects in the generic address space (address space zero).

      -
      - -
      +

      'llvm.gcroot' Intrinsic -

      + -
      +
      Syntax:
      @@ -5735,11 +5853,11 @@ LLVM.
      -
      +

      'llvm.gcread' Intrinsic -

      + -
      +
      Syntax:
      @@ -5767,11 +5885,11 @@ LLVM.
      -
      +

      'llvm.gcwrite' Intrinsic -

      + -
      +
      Syntax:
      @@ -5798,24 +5916,24 @@ LLVM.
      +
      + -
      +

      Code Generator Intrinsics -

      + -
      +

      These intrinsics are provided by LLVM to expose special features that may only be implemented with code generator support.

      -
      - -
      +

      'llvm.returnaddress' Intrinsic -

      + -
      +
      Syntax:
      @@ -5846,11 +5964,11 @@ LLVM.
      -
      +

      'llvm.frameaddress' Intrinsic -

      + -
      +
      Syntax:
      @@ -5880,11 +5998,11 @@ LLVM.
      -
      +

      'llvm.stacksave' Intrinsic -

      + -
      +
      Syntax:
      @@ -5910,11 +6028,11 @@ LLVM.
      -
      +

      'llvm.stackrestore' Intrinsic -

      + -
      +
      Syntax:
      @@ -5935,11 +6053,11 @@ LLVM.
      -
      +

      'llvm.prefetch' Intrinsic -

      + -
      +
      Syntax:
      @@ -5968,11 +6086,11 @@ LLVM.
      -
      +

      'llvm.pcmarker' Intrinsic -

      + -
      +
      Syntax:
      @@ -5999,11 +6117,11 @@ LLVM.
      -
      +

      'llvm.readcyclecounter' Intrinsic -

      + -
      +
      Syntax:
      @@ -6025,26 +6143,26 @@ LLVM.
      +
      + -
      +

      Standard C Library Intrinsics -

      + -
      +

      LLVM provides intrinsics for a few important standard C library functions. These intrinsics allow source-language front-ends to pass information about the alignment of the pointer arguments to the code generator, providing opportunity for more efficient code generation.

      -
      - -
      +

      'llvm.memcpy' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.memcpy on any @@ -6094,11 +6212,11 @@ LLVM.

      -
      +

      'llvm.memmove' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.memmove on any integer bit @@ -6150,11 +6268,11 @@ LLVM.

      -
      +

      'llvm.memset.*' Intrinsics -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.memset on any integer bit @@ -6200,11 +6318,11 @@ LLVM.

      -
      +

      'llvm.sqrt.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.sqrt on any @@ -6238,11 +6356,11 @@ LLVM.

      -
      +

      'llvm.powi.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.powi on any @@ -6274,11 +6392,11 @@ LLVM.

      -
      +

      'llvm.sin.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.sin on any @@ -6308,11 +6426,11 @@ LLVM.

      -
      +

      'llvm.cos.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.cos on any @@ -6342,11 +6460,11 @@ LLVM.

      -
      +

      'llvm.pow.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.pow on any @@ -6376,24 +6494,24 @@ LLVM.

      +
      + -
      +

      Bit Manipulation Intrinsics -

      + -
      +

      LLVM provides intrinsics for a few important bit manipulation operations. These allow efficient code generation for some algorithms.

      -
      - -
      +

      'llvm.bswap.*' Intrinsics -

      + -
      +
      Syntax:

      This is an overloaded intrinsic function. You can use bswap on any integer @@ -6424,11 +6542,11 @@ LLVM.

      -
      +

      'llvm.ctpop.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.ctpop on any integer bit @@ -6456,11 +6574,11 @@ LLVM.

      -
      +

      'llvm.ctlz.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.ctlz on any @@ -6490,11 +6608,11 @@ LLVM.

      -
      +

      'llvm.cttz.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.cttz on any @@ -6523,23 +6641,25 @@ LLVM.

      +
      + -
      +

      Arithmetic with Overflow Intrinsics -

      + -
      +

      LLVM provides intrinsics for some arithmetic with overflow operations.

      -
      - -
      - 'llvm.sadd.with.overflow.*' Intrinsics -
      +

      + + 'llvm.sadd.with.overflow.*' Intrinsics + +

      -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.sadd.with.overflow @@ -6581,11 +6701,13 @@ LLVM.

      -
      - 'llvm.uadd.with.overflow.*' Intrinsics -
      +

      + + 'llvm.uadd.with.overflow.*' Intrinsics + +

      -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.uadd.with.overflow @@ -6626,11 +6748,13 @@ LLVM.

      -
      - 'llvm.ssub.with.overflow.*' Intrinsics -
      +

      + + 'llvm.ssub.with.overflow.*' Intrinsics + +

      -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.ssub.with.overflow @@ -6672,11 +6796,13 @@ LLVM.

      -
      - 'llvm.usub.with.overflow.*' Intrinsics -
      +

      + + 'llvm.usub.with.overflow.*' Intrinsics + +

      -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.usub.with.overflow @@ -6718,11 +6844,13 @@ LLVM.

      -
      - 'llvm.smul.with.overflow.*' Intrinsics -
      +

      + + 'llvm.smul.with.overflow.*' Intrinsics + +

      -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.smul.with.overflow @@ -6765,11 +6893,13 @@ LLVM.

      -
      - 'llvm.umul.with.overflow.*' Intrinsics -
      +

      + + 'llvm.umul.with.overflow.*' Intrinsics + +

      -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.umul.with.overflow @@ -6810,12 +6940,14 @@ LLVM.

      +
      + -
      +

      Half Precision Floating Point Intrinsics -

      + -
      +

      Half precision floating point is a storage-only format. This means that it is a dense encoding (in memory) but does not support computation in the @@ -6829,14 +6961,15 @@ LLVM.

      float if needed, then converted to i16 with llvm.convert.to.fp16, then storing as an i16 value.

      -
      -
      - 'llvm.convert.to.fp16' Intrinsic -
      +

      + + 'llvm.convert.to.fp16' Intrinsic + +

      -
      +
      Syntax:
      @@ -6867,11 +7000,13 @@ LLVM.
      -
      - 'llvm.convert.from.fp16' Intrinsic -
      +

      + + 'llvm.convert.from.fp16' Intrinsic + +

      -
      +
      Syntax:
      @@ -6901,12 +7036,14 @@ LLVM.
      +
      + -
      +

      Debugger Intrinsics -

      + -
      +

      The LLVM debugger intrinsics (which all start with llvm.dbg. prefix), are described in @@ -6916,11 +7053,11 @@ LLVM.

      -
      +

      Exception Handling Intrinsics -

      + -
      +

      The LLVM exception handling intrinsics (which all start with llvm.eh. prefix), are described in @@ -6930,11 +7067,11 @@ LLVM.

      -
      +

      Trampoline Intrinsic -

      + -
      +

      This intrinsic makes it possible to excise one parameter, marked with the nest attribute, from a function. @@ -6960,14 +7097,14 @@ LLVM.

      The call %val = call i32 %fp(i32 %x, i32 %y) is then equivalent to %val = call i32 %f(i8* %nval, i32 %x, i32 %y).

      -
      - -
      - 'llvm.init.trampoline' Intrinsic -
      +

      + + 'llvm.init.trampoline' Intrinsic + +

      -
      +
      Syntax:
      @@ -7004,12 +7141,14 @@ LLVM.
      +
      + -
      +

      Atomic Operations and Synchronization Intrinsics -

      + -
      +

      These intrinsic functions expand the "universal IR" of LLVM to represent hardware constructs for atomic operations and memory synchronization. This @@ -7029,13 +7168,12 @@ LLVM.

      No one model or paradigm should be selected above others unless the hardware itself ubiquitously does so.

      -
      - -
      +

      'llvm.memory.barrier' Intrinsic -

      -
      + + +
      Syntax:
         declare void @llvm.memory.barrier(i1 <ll>, i1 <ls>, i1 <sl>, i1 <ss>, i1 <device>)
@@ -7103,11 +7241,11 @@ LLVM.
      -
      +

      'llvm.atomic.cmp.swap.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.atomic.cmp.swap on @@ -7163,10 +7301,11 @@ LLVM.

      -
      +

      'llvm.atomic.swap.*' Intrinsic -

      -
      + + +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.atomic.swap on any @@ -7219,12 +7358,11 @@ LLVM.

      -
      +

      'llvm.atomic.load.add.*' Intrinsic +

      -
      - -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.atomic.load.add on @@ -7269,12 +7407,11 @@ LLVM.

      -
      +

      'llvm.atomic.load.sub.*' Intrinsic +

      -
      - -
      +
      Syntax:

      This is an overloaded intrinsic. You can use llvm.atomic.load.sub on @@ -7321,14 +7458,25 @@ LLVM.

      -
      - 'llvm.atomic.load.and.*' Intrinsic
      - 'llvm.atomic.load.nand.*' Intrinsic
      - 'llvm.atomic.load.or.*' Intrinsic
      - 'llvm.atomic.load.xor.*' Intrinsic
      -
      - -
      +

      + + 'llvm.atomic.load.and.*' Intrinsic + +
      + + 'llvm.atomic.load.nand.*' Intrinsic + +
      + + 'llvm.atomic.load.or.*' Intrinsic + +
      + + 'llvm.atomic.load.xor.*' Intrinsic + +

      + +
      Syntax:

      These are overloaded intrinsics. You can @@ -7401,14 +7549,25 @@ LLVM.

      -
      - 'llvm.atomic.load.max.*' Intrinsic
      - 'llvm.atomic.load.min.*' Intrinsic
      - 'llvm.atomic.load.umax.*' Intrinsic
      - 'llvm.atomic.load.umin.*' Intrinsic
      -
      - -
      +

      + + 'llvm.atomic.load.max.*' Intrinsic + +
      + + 'llvm.atomic.load.min.*' Intrinsic + +
      + + 'llvm.atomic.load.umax.*' Intrinsic + +
      + + 'llvm.atomic.load.umin.*' Intrinsic + +

      + +
      Syntax:

      These are overloaded intrinsics. You can use llvm.atomic.load_max, @@ -7479,25 +7638,24 @@ LLVM.

      +
      -
      +

      Memory Use Markers -

      + -
      +

      This class of intrinsics exists to information about the lifetime of memory objects and ranges where variables are immutable.

      -
      - -
      +

      'llvm.lifetime.start' Intrinsic -

      + -
      +
      Syntax:
      @@ -7523,11 +7681,11 @@ LLVM.
      -
      +

      'llvm.lifetime.end' Intrinsic -

      + -
      +
      Syntax:
      @@ -7552,11 +7710,11 @@ LLVM.
      -
      +

      'llvm.invariant.start' Intrinsic -

      + -
      +
      Syntax:
      @@ -7580,11 +7738,11 @@ LLVM.
      -
      +

      'llvm.invariant.end' Intrinsic -

      + -
      +
      Syntax:
      @@ -7606,24 +7764,24 @@ LLVM.
      +
      + -
      +

      General Intrinsics -

      + -
      +

      This class of intrinsics is designed to be generic and has no specific purpose.

      -
      - -
      +

      'llvm.var.annotation' Intrinsic -

      + -
      +
      Syntax:
      @@ -7647,11 +7805,11 @@ LLVM.
      -
      +

      'llvm.annotation.*' Intrinsic -

      + -
      +
      Syntax:

      This is an overloaded intrinsic. You can use 'llvm.annotation' on @@ -7683,11 +7841,11 @@ LLVM.

      -
      +

      'llvm.trap' Intrinsic -

      + -
      +
      Syntax:
      @@ -7708,11 +7866,11 @@ LLVM.
      -
      +

      'llvm.stackprotector' Intrinsic -

      + -
      +
      Syntax:
      @@ -7742,11 +7900,11 @@ LLVM.
      -
      +

      'llvm.objectsize' Intrinsic -

      + -
      +
      Syntax:
      @@ -7776,6 +7934,10 @@ LLVM.
      +
      + +
      +
      @@ -7785,8 +7947,8 @@ LLVM.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-24 22:01:34 +0100 (Thu, 24 Feb 2011) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
      diff --git a/docs/Lexicon.html b/docs/Lexicon.html index 09fae3996605..449e26eb922e 100644 --- a/docs/Lexicon.html +++ b/docs/Lexicon.html @@ -9,12 +9,12 @@ content="A glossary of terms used with the LLVM project."> -
      The LLVM Lexicon
      +

      The LLVM Lexicon

      NOTE: This document is a work in progress!

      -
      Table Of Contents
      +

      Table Of Contents

      -
      +
      @@ -83,19 +83,20 @@ -
      Definitions
      +

      Definitions

      +
      -
      - A -
      -
      +

      - A -

      +
      ADCE
      Aggressive Dead Code Elimination
      -
      - B -
      -
      +

      - B -

      +
      BURS
      Bottom Up Rewriting System—A method of instruction selection for @@ -104,8 +105,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - C -
      -
      +

      - C -

      +
      CSE
      Common Subexpression Elimination. An optimization that removes common @@ -116,8 +117,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - D -
      -
      +

      - D -

      +
      DAG
      Directed Acyclic Graph
      @@ -136,8 +137,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - G -
      -
      +

      - G -

      +
      GC
      Garbage Collection. The practice of using reachability analysis instead @@ -145,8 +146,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - H -
      -
      +

      - H -

      +
      Heap
      In garbage collection, the region of memory which is managed using @@ -154,8 +155,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - I -
      -
      +

      - I -

      +
      IPA
      Inter-Procedural Analysis. Refers to any variety of code analysis that @@ -169,8 +170,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - L -
      -
      +

      - L -

      +
      LCSSA
      Loop-Closed Static Single Assignment Form
      @@ -183,16 +184,16 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - M -
      -
      +

      - M -

      +
      MC
      Machine Code
      -
      - O -
      -
      +

      - O -

      +
      Object Pointer
      A pointer to an object such that the garbage collector is able to trace @@ -202,8 +203,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - P -
      -
      +

      - P -

      +
      PRE
      Partial Redundancy Elimination
      @@ -211,8 +212,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - R -
      -
      +

      - R -

      +
      RAUW
      An abbreviation for Replace All Uses With. The functions User::replaceUsesOfWith(), @@ -234,8 +235,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      -
      - S -
      -
      +

      - S -

      +
      Safe Point
      In garbage collection, it is necessary to identify stack @@ -261,6 +262,8 @@ href="http://www.program-transformation.org/Transform/BURG">BURG tool.
      function.
      + +
      BURG tool. href="http://validator.w3.org/check/referer">Valid HTML 4.01The LLVM Team
      -The LLVM Compiler Infrastructure
      -Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ +The LLVM Compiler Infrastructure
      +Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
      diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html index 30334744d7f9..289da236270a 100644 --- a/docs/LinkTimeOptimization.html +++ b/docs/LinkTimeOptimization.html @@ -6,9 +6,9 @@ -
      +

      LLVM Link Time Optimization: Design and Implementation -

      +
      -
      +

      Description -

      + -
      +

      LLVM features powerful intermodular optimizations which can be used at link time. Link Time Optimization (LTO) is another name for intermodular optimization @@ -50,12 +50,12 @@ and design between the LTO optimizer and the linker.

      -
      +

      Design Philosophy -

      + -
      +

      The LLVM Link Time Optimizer provides complete transparency, while doing intermodular optimization, in the compiler tool chain. Its main goal is to let @@ -69,14 +69,13 @@ the linker and LLVM optimizer helps to do optimizations that are not possible in other models. The linker input allows the optimizer to avoid relying on conservative escape analysis.

      -
      -
      +

      Example of link time optimization -

      + -
      +

      The following example illustrates the advantages of LTO's integrated approach and clean interface. This example requires a system linker which supports LTO through the interface described in this document. Here, @@ -145,11 +144,11 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific

      -
      +

      Alternative Approaches -

      + -
      +
      Compiler driver invokes link time optimizer separately.
      In this model the link time optimizer is not able to take advantage of @@ -175,12 +174,14 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific
      +
      + -
      +

      Multi-phase communication between libLTO and linker -

      + -
      +

      The linker collects information about symbol defininitions and uses in various link objects which is more accurate than any information collected by other tools during typical build cycles. The linker collects this @@ -192,14 +193,13 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific Our goal is to take advantage of tight integration between the linker and the optimizer by sharing this information during various linking phases.

      -
      -
      +

      Phase 1 : Read LLVM Bitcode Files -

      + -
      +

      The linker first reads all object files in natural order and collects symbol information. This includes native object files as well as LLVM bitcode files. To minimize the cost to the linker in the case that all .o files @@ -219,11 +219,11 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific

      -
      +

      Phase 2 : Symbol Resolution -

      + -
      +

      In this stage, the linker resolves symbols using global symbol table. It may report undefined symbol errors, read archive members, replace weak symbols, etc. The linker is able to do this seamlessly even though it @@ -233,10 +233,10 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific

      -
      +

      Phase 3 : Optimize Bitcode Files -

      -
      + +

      After symbol resolution, the linker tells the LTO shared object which symbols are needed by native object files. In the example above, the linker reports that only foo1() is used by native object files using @@ -248,11 +248,11 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific

      -
      +

      Phase 4 : Symbol Resolution after optimization -

      + -
      +

      In this phase, the linker reads optimized a native object file and updates the internal global symbol table to reflect any changes. The linker also collects information about any changes in use of external symbols by @@ -264,12 +264,14 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific bitcode files.

      +
      + -
      +

      libLTO -

      + -
      +

      libLTO is a shared object that is part of the LLVM tools, and is intended for use by a linker. libLTO provides an abstract C interface to use the LLVM interprocedural optimizer without exposing details @@ -278,14 +280,13 @@ $ llvm-gcc a.o main.o -o main # <-- standard link command without any modific be possible for a completely different compilation technology to provide a different libLTO that works with their object files and the standard linker tool.

      -
      -
      +

      lto_module_t -

      + -
      +

      A non-native object file is handled via an lto_module_t. The following functions allow the linker to check if a file (on disk @@ -325,11 +326,11 @@ lto_module_get_symbol_attribute(lto_module_t, unsigned int)

      -
      +

      lto_code_gen_t -

      + -
      +

      Once the linker has loaded each non-native object files into an lto_module_t, it can request libLTO to process them all and @@ -371,6 +372,8 @@ of the native object files.

      +
      +
      @@ -381,8 +384,8 @@ of the native object files.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Devang Patel and Nick Kledzik
      - LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-09-29 22:09:55 +0200 (Wed, 29 Sep 2010) $ + LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html index 6ceb09db3274..1e7c346952f0 100644 --- a/docs/MakefileGuide.html +++ b/docs/MakefileGuide.html @@ -7,7 +7,7 @@ -
      LLVM Makefile Guide
      +

      LLVM Makefile Guide

      1. Introduction
        2. @@ -77,10 +77,10 @@
      -
      Introduction
      +

      Introduction

      -
      +

      This document provides usage information about the LLVM makefile system. While loosely patterned after the BSD makefile system, LLVM has taken a departure from BSD in order to implement additional features needed by LLVM. @@ -99,20 +99,19 @@

      -
      General Concepts
      +

      General Concepts

      -
      +

      The LLVM Makefile System is the component of LLVM that is responsible for building the software, testing it, generating distributions, checking those distributions, installing and uninstalling, etc. It consists of a several files throughout the source tree. These files and other general concepts are described in this section.

      -
      -
      Projects
      -
      +

      Projects

      +

      The LLVM Makefile System is quite generous. It not only builds its own software, but it can build yours too. Built into the system is knowledge of the llvm/projects directory. Any directory under projects @@ -129,8 +128,8 @@

      -
      Variable Values
      -
      +

      Variable Values

      +

      To use the makefile system, you simply create a file named Makefile in your directory and declare values for certain variables. The variables and values that you select determine what the makefile system @@ -139,16 +138,15 @@

      -
      Including Makefiles
      -
      +

      Including Makefiles

      +

      Setting variables alone is not enough. You must include into your Makefile additional files that provide the rules of the LLVM Makefile system. The various files involved are described in the sections that follow.

      -
      -
      Makefile
      -
      +

      Makefile

      +

      Each directory to participate in the build needs to have a file named Makefile. This is the file first read by make. It has three sections:

      @@ -163,9 +161,8 @@
      -
      Makefile.common -
      -
      +

      Makefile.common

      +

      Every project must have a Makefile.common file at its top source directory. This file serves three purposes:

        @@ -182,9 +179,8 @@
      -
      Makefile.config -
      -
      +

      Makefile.config

      +

      Every project must have a Makefile.config at the top of its build directory. This file is generated by the configure script from the pattern provided by the @@ -196,8 +192,8 @@

      -
      Makefile.rules
      -
      +

      Makefile.rules

      +

      This file, located at $(LLVM_SRC_ROOT)/Makefile.rules is the heart of the LLVM Makefile System. It provides all the logic, dependencies, and rules for building the targets supported by the system. What it does largely @@ -205,9 +201,11 @@ have been set before Makefile.rules is included.

      +
      + -
      Comments
      -
      +

      Comments

      +

      User Makefiles need not have comments in them unless the construction is unusual or it does not strictly follow the rules and patterns of the LLVM makefile system. Makefile comments are invoked with the pound (#) character. @@ -215,19 +213,20 @@ by make.

      +
      + -
      Tutorial
      +

      Tutorial

      -
      +

      This section provides some examples of the different kinds of modules you can build with the LLVM makefile system. In general, each directory you provide will build a single object although that object may be composed of additionally compiled components.

      -
      -
      Libraries
      -
      +

      Libraries

      +

      Only a few variable definitions are needed to build a regular library. Normally, the makefile system will build all the software into a single libname.o (pre-linked) object. This means the library is not @@ -256,11 +255,10 @@ -load option. See the WritingAnLLVMPass.html document for an example of why you might want to do this. -

      -
      Bitcode Modules
      -
      +

      Bitcode Modules

      +

      In some situations, it is desirable to build a single bitcode module from a variety of sources, instead of an archive, shared library, or bitcode library. Bitcode modules can be specified in addition to any of the other @@ -280,10 +278,10 @@

      -
      +

      Loadable Modules -

      -
      + +

      In some situations, you need to create a loadable module. Loadable modules can be loaded into programs like opt or llc to specify additional passes to run or targets to support. Loadable modules are also @@ -311,9 +309,11 @@ library which is part of lib/System implementation.

      +
      + -
      Tools
      -
      +

      Tools

      +

      For building executable programs (tools), you must provide the name of the tool and the names of the libraries you wish to link with the tool. For example:

      @@ -344,11 +344,10 @@ syntax is used. Note that in order to use the .a suffix, the library in question must have been built with the ARCHIVE_LIBRARY option set.

      -
      -
      JIT Tools
      -
      +

      JIT Tools

      +

      Many tools will want to use the JIT features of LLVM. To do this, you simply specify that you want an execution 'engine', and the makefiles will automatically link in the appropriate JIT for the host or an interpreter @@ -367,11 +366,15 @@

      +
      + +
      + -
      Targets Supported
      +

      Targets Supported

      -
      +

      This section describes each of the targets that can be built using the LLVM Makefile system. Any target can be invoked from any directory but not all are applicable to a given directory (e.g. "check", "dist" and "install" will @@ -426,11 +429,10 @@

      - A -
      Remove built objects from installation directory.
      -
      -
      all (default)
      -
      +

      all (default)

      +

      When you invoke make with no arguments, you are implicitly instructing it to seek the "all" target (goal). This target is used for building the software recursively and will do different things in different @@ -440,15 +442,15 @@

      -
      all-local
      -
      +

      all-local

      +

      This target is the same as all but it operates only on the current directory instead of recursively.

      -
      check
      -
      +

      check

      +

      This target can be invoked from anywhere within a project's directories but always invokes the check-local target in the project's test directory, if it exists and has a @@ -464,8 +466,8 @@

      -
      check-local
      -
      +

      check-local

      +

      This target should be implemented by the Makefile in the project's test directory. It is invoked by the check target elsewhere. Each project is free to define the actions of check-local as @@ -475,8 +477,8 @@

      -
      clean
      -
      +

      clean

      +

      This target cleans the build directory, recursively removing all things that the Makefile builds. The cleaning rules have been made guarded so they shouldn't go awry (via rm -f $(UNSET_VARIABLE)/* which will attempt @@ -484,15 +486,15 @@

      -
      clean-local
      -
      +

      clean-local

      +

      This target does the same thing as clean but only for the current (local) directory.

      -
      dist
      -
      +

      dist

      +

      This target builds a distribution tarball. It first builds the entire project using the all target and then tars up the necessary files and compresses it. The generated tarball is sufficient for a casual source @@ -500,8 +502,8 @@

      -
      dist-check
      -
      +

      dist-check

      +

      This target does the same thing as the dist target but also checks the distribution tarball. The check is made by unpacking the tarball to a new directory, configuring it, building it, installing it, and then verifying that @@ -512,16 +514,16 @@

      -
      dist-clean
      -
      +

      dist-clean

      +

      This is a special form of the clean clean target. It performs a normal clean but also removes things pertaining to building the distribution.

      -
      install
      -
      +

      install

      +

      This target finalizes shared objects and executables and copies all libraries, headers, executables and documentation to the directory given with the --prefix option to configure. When completed, @@ -538,8 +540,8 @@

      -
      preconditions
      -
      +

      preconditions

      +

      This utility target checks to see if the Makefile in the object directory is older than the Makefile in the source directory and copies it if so. It also reruns the configure script if that needs to @@ -549,15 +551,15 @@

      -
      printvars
      -
      +

      printvars

      +

      This utility target just causes the LLVM makefiles to print out some of the makefile variables so that you can double check how things are set.

      -
      reconfigure
      -
      +

      reconfigure

      +

      This utility target will force a reconfigure of LLVM or your project. It simply runs $(PROJ_OBJ_ROOT)/config.status --recheck to rerun the configuration tests and rebuild the configured files. This isn't generally @@ -566,8 +568,8 @@

      -
      spotless
      -
      +

      spotless

      +

      This utility target, only available when $(PROJ_OBJ_ROOT) is not the same as $(PROJ_SRC_ROOT), will completely clean the $(PROJ_OBJ_ROOT) directory by removing its content entirely and @@ -578,8 +580,8 @@

      -
      tags
      -
      +

      tags

      +

      This target will generate a TAGS file in the top-level source directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file provides an index of symbol definitions so that the editor can jump you to the @@ -587,18 +589,20 @@

      -
      uninstall
      -
      +

      uninstall

      +

      This target is the opposite of the install target. It removes the header, library and executable files from the installation directories. Note that the directories themselves are not removed because it is not guaranteed that LLVM is the only thing installing there (e.g. --prefix=/usr).

      +
      + -
      Variables
      +

      Variables

      -
      +

      Variables are used to tell the LLVM Makefile System what to do and to obtain information from it. Variables are also used internally by the LLVM Makefile System. Variable names that contain only the upper case alphabetic @@ -606,11 +610,10 @@ variables are internal to the LLVM Makefile System and should not be relied upon nor modified. The sections below describe how to use the LLVM Makefile variables.

      -
      -
      Control Variables
      -
      +

      Control Variables

      +

      Variables listed in the table below should be set before the inclusion of $(LEVEL)/Makefile.common. These variables provide input to the LLVM make system that tell it what to do @@ -762,8 +765,8 @@

      -
      Override Variables
      -
      +

      Override Variables

      +

      Override variables can be used to override the default values provided by the LLVM makefile system. These variables can be set in several ways:

      @@ -868,8 +871,8 @@
      -
      Readable Variables
      -
      +

      Readable Variables

      +

      Variables listed in the table below can be used by the user's Makefile but should not be changed. Changing the value will generally cause the build to go wrong, so don't do it.

      @@ -939,8 +942,8 @@
      -
      Internal Variables
      -
      +

      Internal Variables

      +

      Variables listed below are used by the LLVM Makefile System and considered internal. You should not use these variables under any circumstances.

      @@ -1018,6 +1021,8 @@

      +
      +
      @@ -1027,8 +1032,8 @@ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Reid Spencer
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-10-22 14:54:34 +0200 (Fri, 22 Oct 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
      diff --git a/docs/Packaging.html b/docs/Packaging.html index 7aa4a1c2e16b..b9329726991f 100644 --- a/docs/Packaging.html +++ b/docs/Packaging.html @@ -7,7 +7,7 @@ -
      Advice on Packaging LLVM
      +

      Advice on Packaging LLVM

      1. Overview
      2. Compile Flags
        3. @@ -17,9 +17,9 @@
      -
      Overview
      +

      Overview

      -
      +

      LLVM sets certain default configure options to make sure our developers don't break things for constrained platforms. These settings are not optimal for most @@ -34,9 +34,9 @@ developed against each.

      -
      Compile Flags
      +

      Compile Flags

      -
      +

      LLVM runs much more quickly when it's optimized and assertions are removed. However, such a build is currently incompatible with users who build without @@ -65,9 +65,9 @@ versions of LLVM in parallel. The following configure flags are relevant:

      -
      C++ Features
      +

      C++ Features

      -
      +
      RTTI
      LLVM disables RTTI by default. Add REQUIRES_RTTI=1 @@ -78,9 +78,9 @@ versions of LLVM in parallel. The following configure flags are relevant:
      -
      Shared Library
      +

      Shared Library

      -
      +

      Configure with --enable-shared to build libLLVM-major.minor.(so|dylib) and link the tools @@ -89,9 +89,9 @@ against it. This saves lots of binary size at the cost of some startup time.

      -
      Dependencies
      +

      Dependencies

      -
      +
      --enable-libffi
      Depend on src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"> Valid HTML 4.01 - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/Passes.html b/docs/Passes.html index fb2aff585bdb..ca9602c6e076 100644 --- a/docs/Passes.html +++ b/docs/Passes.html @@ -40,7 +40,7 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if ! --> -

      LLVM's Analysis and Transform Passes
      +

      LLVM's Analysis and Transform Passes

      1. Introduction
        2. @@ -55,8 +55,8 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

        \n" if !

      -
      Introduction
      -
      +

      Introduction

      +

      This document serves as a high level summary of the optimization features that LLVM provides. Optimizations are implemented as Passes that traverse some portion of a program to either collect information or transform the program. @@ -69,15 +69,13 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if ! bitcode are neither analysis nor transform passes.

      The table below provides a quick summary of each pass and links to the more complete pass description later in the document.

      -
      -
      + - + - @@ -85,27 +83,23 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      - - - - + + + + - - - - + - + - @@ -120,8 +114,8 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      - + @@ -129,13 +123,12 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      - - + @@ -155,46 +148,40 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      - + - + - + - - + - + - - + - - - - - + + - + - @@ -208,24 +195,24 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      - - - - + + + +
      ANALYSIS PASSES
      OptionName
      -aa-evalExhaustive Alias Analysis Precision Evaluator
      -basicaaBasic Alias Analysis (default AA impl)
      -basicaaBasic Alias Analysis (stateless AA impl)
      -basiccgBasic CallGraph Construction
      -codegenprepareOptimize for code generation
      -count-aaCount Alias Analysis Query Responses
      -debug-aaAA use debugger
      -domfrontierDominance Frontier Construction
      -dot-callgraphPrint Call Graph to 'dot' file
      -dot-cfgPrint CFG of function to 'dot' file
      -dot-cfg-onlyPrint CFG of function to 'dot' file (with no function bodies)
      -dot-domPrint dominator tree of function to 'dot' file
      -dot-dom-onlyPrint dominator tree of function to 'dot' file (with no function bodies)
      -dot-postdomPrint post dominator tree of function to 'dot' file
      -dot-postdom-onlyPrint post dominator tree of function to 'dot' file (with no function bodies)
      -dot-domPrint dominance tree of function to 'dot' file
      -dot-dom-onlyPrint dominance tree of function to 'dot' file (with no function bodies)
      -dot-postdomPrint postdominance tree of function to 'dot' file
      -dot-postdom-onlyPrint postdominance tree of function to 'dot' file (with no function bodies)
      -globalsmodref-aaSimple mod/ref analysis for globals
      -instcountCounts the various types of Instructions
      -interprocedural-aa-evalExhaustive Interprocedural Alias Analysis Precision Evaluator
      -interprocedural-basic-aaInterprocedural Basic Alias Analysis
      -intervalsInterval Partition Construction
      -iv-usersInduction Variable Users
      -lazy-value-infoLazy Value Information Analysis
      -ldaLoop Dependence Analysis
      -libcall-aaLibCall Alias Analysis
      -lintCheck for common errors in LLVM IR
      -live-valuesValue Liveness Analysis
      -lintStatically lint-checks LLVM IR
      -loopsNatural Loop Information
      -memdepMemory Dependence Analysis
      -module-debuginfoPrints module debug info metadata
      -module-debuginfoDecodes module-level debug info
      -no-aaNo Alias Analysis (always returns 'may' alias)
      -no-profileNo Profile Information
      -pointertrackingTrack pointer bounds
      -postdomfrontierPost-Dominance Frontier Construction
      -postdomtreePost-Dominator Tree Construction
      -print-alias-setsAlias Set Printer
      -print-used-typesFind Used Types
      -profile-estimatorEstimate profiling information
      -profile-loaderLoad profile information from llvmprof.out
      -regionsDetect single entry single exit regions in a function
      -profile-verifierVerify profiling information
      -regionsDetect single entry single exit regions
      -scalar-evolutionScalar Evolution Analysis
      -scev-aaScalarEvolution-based Alias Analysis
      -targetdataTarget Data Layout
      TRANSFORM PASSES
      OptionName
      -abcdRemove redundant conditional branches
      -adceAggressive Dead Code Elimination
      -always-inlineInliner for always_inline functions
      -argpromotionPromote 'by reference' arguments to scalars
      -block-placementProfile Guided Basic Block Placement
      -break-crit-edgesBreak critical edges in CFG
      -codegenpreparePrepare a function for code generation
      -codegenprepareOptimize for code generation
      -constmergeMerge Duplicate Global Constants
      -constpropSimple constant propagation
      -dceDead Code Elimination
      -internalizeInternalize Global Symbols
      -ipconstpropInterprocedural constant propagation
      -ipsccpInterprocedural Sparse Conditional Constant Propagation
      -jump-threadingThread control through conditional blocks
      -jump-threadingJump Threading
      -lcssaLoop-Closed SSA Form Pass
      -licmLoop Invariant Code Motion
      -loop-deletionDead Loop Deletion Pass
      -loop-deletionDelete dead loops
      -loop-extractExtract loops into new functions
      -loop-extract-singleExtract at most one loop into a new function
      -loop-index-splitIndex Split Loops
      -loop-reduceLoop Strength Reduction
      -loop-rotateRotate Loops
      -loop-simplifyCanonicalize natural loops
      -loop-unrollUnroll loops
      -loop-unswitchUnswitch loops
      -loop-simplifyCanonicalize natural loops
      -loweratomicLower atomic intrinsics
      -loweratomicLower atomic intrinsics to non-atomic form
      -lowerinvokeLower invoke and unwind, for unwindless code generators
      -lowersetjmpLower Set Jump
      -lowerswitchLower SwitchInst's to branches
      -mem2regPromote Memory to Register
      -memcpyoptOptimize use of memcpy and friends
      -memcpyoptMemCpy Optimization
      -mergefuncMerge Functions
      -mergereturnUnify function exit nodes
      -partial-inlinerPartial Inliner
      -partialspecializationPartial Specialization
      -prune-ehRemove unused exception handling info
      -reassociateReassociate expressions
      -reg2memDemote all values to stack slots
      -scalarreplScalar Replacement of Aggregates
      -scalarreplScalar Replacement of Aggregates (DT)
      -sccpSparse Conditional Constant Propagation
      -sinkCode Sinking
      -simplify-libcallsSimplify well-known library calls
      -simplify-libcalls-halfpowrSimplify half_powr library calls
      -simplifycfgSimplify the CFG
      -split-gepsSplit complex GEPs into simple GEPs
      -ssiStatic Single Information Construction
      -ssi-everythingStatic Single Information Construction (everything, intended for debugging)
      -sinkCode sinking
      -sretpromotionPromote sret arguments to multiple ret values
      -stripStrip all symbols from a module
      -strip-dead-debug-infoStrip debug info for unused symbols
      -strip-dead-prototypesRemove unused function declarations
      -strip-dead-prototypesStrip Unused Function Prototypes
      -strip-debug-declareStrip all llvm.dbg.declare intrinsics
      -strip-nondebugStrip all symbols, except dbg symbols, from a module
      -sretpromotionPromote sret arguments
      -tailcallelimTail Call Elimination
      -tailduplicateTail Duplication
      -verifyModule Verifier
      -view-cfgView CFG of function
      -view-cfg-onlyView CFG of function (with no function bodies)
      -view-domView dominator tree of function
      -view-dom-onlyView dominator tree of function (with no function bodies)
      -view-postdomView post dominator tree of function
      -view-postdom-onlyView post dominator tree of function (with no function bodies)
      -view-domView dominance tree of function
      -view-dom-onlyView dominance tree of function (with no function bodies)
      -view-postdomView postdominance tree of function
      -view-postdom-onlyView postdominance tree of function (with no function bodies)
      +
      -
      Analysis Passes
      -
      +

      Analysis Passes

      +

      This section describes the LLVM Analysis Passes.

      -
      -
      +

      -aa-eval: Exhaustive Alias Analysis Precision Evaluator -

      -
      + +

      This is a simple N^2 alias analysis accuracy evaluator. Basically, for each function in the program, it simply queries to see how the alias analysis implementation answers alias queries between each pair of @@ -236,10 +223,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -basicaa: Basic Alias Analysis (default AA impl) -
      -
      +

      + -basicaa: Basic Alias Analysis (stateless AA impl) +

      +

      This is the default implementation of the Alias Analysis interface that simply implements a few identities (two different globals cannot alias, @@ -248,30 +235,18 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -basiccg: Basic CallGraph Construction -

      -
      + +

      Yet to be written.

      -
      - -codegenprepare: Optimize for code generation -
      -
      -

      - This pass munges the code in the input function to better prepare it for - SelectionDAG-based code generation. This works around limitations in it's - basic-block-at-a-time approach. It should eventually be removed. -

      -
      - - -
      +

      -count-aa: Count Alias Analysis Query Responses -

      -
      + +

      A pass which can be used to count how many alias queries are being made and how the alias analysis implementation being used responds. @@ -279,10 +254,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -debug-aa: AA use debugger -

      -
      + +

      This simple pass checks alias analysis users to ensure that if they create a new value, they do not query AA without informing it of the value. @@ -296,10 +271,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -domfrontier: Dominance Frontier Construction -

      -
      + +

      This pass is a simple dominator construction algorithm for finding forward dominator frontiers. @@ -307,10 +282,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -domtree: Dominator Tree Construction -

      -
      + +

      This pass is a simple dominator construction algorithm for finding forward dominators. @@ -318,10 +293,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -dot-callgraph: Print Call Graph to 'dot' file -

      -
      + +

      This pass, only available in opt, prints the call graph into a .dot graph. This graph can then be processed with the "dot" tool @@ -330,10 +305,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -dot-cfg: Print CFG of function to 'dot' file -

      -
      + +

      This pass, only available in opt, prints the control flow graph into a .dot graph. This graph can then be processed with the @@ -342,10 +317,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -dot-cfg-only: Print CFG of function to 'dot' file (with no function bodies) -

      -
      + +

      This pass, only available in opt, prints the control flow graph into a .dot graph, omitting the function bodies. This graph can @@ -355,10 +330,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -dot-dom: Print dominator tree of function to 'dot' file -
      -
      +

      + -dot-dom: Print dominance tree of function to 'dot' file +

      +

      This pass, only available in opt, prints the dominator tree into a .dot graph. This graph can then be processed with the @@ -367,11 +342,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -dot-dom-only: Print dominator tree of function to 'dot' file (with no - function bodies) -
      -
      +

      + -dot-dom-only: Print dominance tree of function to 'dot' file (with no function bodies) +

      +

      This pass, only available in opt, prints the dominator tree into a .dot graph, omitting the function bodies. This graph can @@ -381,10 +355,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -dot-postdom: Print post dominator tree of function to 'dot' file -
      -
      +

      + -dot-postdom: Print postdominance tree of function to 'dot' file +

      +

      This pass, only available in opt, prints the post dominator tree into a .dot graph. This graph can then be processed with the @@ -393,11 +367,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -dot-postdom-only: Print post dominator tree of function to 'dot' file - (with no function bodies) -
      -
      +

      + -dot-postdom-only: Print postdominance tree of function to 'dot' file (with no function bodies) +

      +

      This pass, only available in opt, prints the post dominator tree into a .dot graph, omitting the function bodies. This graph can @@ -407,10 +380,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -globalsmodref-aa: Simple mod/ref analysis for globals -

      -
      + +

      This simple pass provides alias and mod/ref information for global values that do not have their address taken, and keeps track of whether functions @@ -420,43 +393,20 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -instcount: Counts the various types of Instructions -

      -
      + +

      This pass collects the count of all instructions and reports them

      -
      - -interprocedural-aa-eval: Exhaustive Interprocedural Alias Analysis Precision Evaluator -
      -
      -

      This pass implements a simple N^2 alias analysis accuracy evaluator. - Basically, for each function in the program, it simply queries to see how the - alias analysis implementation answers alias queries between each pair of - pointers in the function. -

      -
      - - -
      - -interprocedural-basic-aa: Interprocedural Basic Alias Analysis -
      -
      -

      This pass defines the default implementation of the Alias Analysis interface - that simply implements a few identities (two different globals cannot alias, - etc), but otherwise does no analysis. -

      -
      - - -
      +

      -intervals: Interval Partition Construction -

      -
      + +

      This analysis calculates and represents the interval partition of a function, or a preexisting interval partition. @@ -469,44 +419,44 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -iv-users: Induction Variable Users -

      -
      + +

      Bookkeeping for "interesting" users of expressions computed from induction variables.

      -
      +

      -lazy-value-info: Lazy Value Information Analysis -

      -
      + +

      Interface for lazy computation of value constraint information.

      -
      +

      -lda: Loop Dependence Analysis -

      -
      + +

      Loop dependence analysis framework, which is used to detect dependences in memory accesses in loops.

      -
      +

      -libcall-aa: LibCall Alias Analysis -

      -
      + +

      LibCall Alias Analysis.

      -
      - -lint: Check for common errors in LLVM IR -
      -
      +

      + -lint: Statically lint-checks LLVM IR +

      +

      This pass statically checks for common and easily-identified constructs which produce undefined or likely unintended behavior in LLVM IR.

      @@ -534,18 +484,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -live-values: Values Liveness Analysis -
      -
      -

      LLVM IR Value liveness analysis pass.

      -
      - - -
      - -loops: Natural Loop Construction -
      -
      +

      + -loops: Natural Loop Information +

      +

      This analysis is used to identify natural loops and determine the loop depth of various nodes of the CFG. Note that the loops identified may actually be @@ -555,10 +497,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -memdep: Memory Dependence Analysis -

      -
      + +

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

      \n" if !

      -
      - -module-debuginfo: Prints module debug info metadata -
      -
      +

      + -module-debuginfo: Decodes module-level debug info +

      +

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

      \n" if !

      -
      +

      -no-aa: No Alias Analysis (always returns 'may' alias) -

      -
      + +

      Always returns "I don't know" for alias queries. NoAA is unlike other alias analysis implementations, in that it does not chain to a previous analysis. As @@ -593,10 +535,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -no-profile: No Profile Information -

      -
      + +

      The default "no profile" implementation of the abstract ProfileInfo interface. @@ -604,19 +546,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -pointertracking: Track pointer bounds. -
      -
      -

      Tracking of pointer bounds. -

      -
      - - -
      +

      -postdomfrontier: Post-Dominance Frontier Construction -

      -
      + +

      This pass is a simple post-dominator construction algorithm for finding post-dominator frontiers. @@ -624,10 +557,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -postdomtree: Post-Dominator Tree Construction -

      -
      + +

      This pass is a simple post-dominator construction algorithm for finding post-dominators. @@ -635,18 +568,18 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -print-alias-sets: Alias Set Printer -

      -
      + +

      Yet to be written.

      -
      +

      -print-callgraph: Print a call graph -

      -
      + +

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

      \n" if !

      -
      +

      -print-callgraph-sccs: Print SCCs of the Call Graph -

      -
      + +

      This pass, only available in opt, prints the SCCs of the call graph to standard error in a human-readable form. @@ -665,10 +598,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -print-cfg-sccs: Print SCCs of each function CFG -

      -
      + +

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

      \n" if !

      -
      +

      -print-dbginfo: Print debug info in human readable form -

      -
      + +

      Pass that prints instructions, and associated debug info:

        @@ -690,18 +623,18 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

        \n" if !

      -
      +

      -print-dom-info: Dominator Info Printer -

      -
      + +

      Dominator Info Printer.

      -
      +

      -print-externalfnconstants: Print external fn callsites passed constants -

      -
      + +

      This pass, only available in opt, prints out call sites to external functions that are called with constant arguments. This can be @@ -711,10 +644,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -print-function: Print function to stderr -

      -
      + +

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

      \n" if !

      -
      +

      -print-module: Print module to stderr -

      -
      + +

      This pass simply prints out the entire module when it is executed.

      -
      +

      -print-used-types: Find Used Types -

      -
      + +

      This pass is used to seek out all of the types in use by the program. Note that this analysis explicitly does not include types only used by the symbol @@ -744,20 +677,20 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -profile-estimator: Estimate profiling information -

      -
      + +

      Profiling information that estimates the profiling information in a very crude and unimaginative way.

      -
      +

      -profile-loader: Load profile information from llvmprof.out -

      -
      + +

      A concrete implementation of profiling information that loads the information from a profile dump file. @@ -765,16 +698,16 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -profile-verifier: Verify profiling information -

      -
      + +

      Pass that checks profiling information for plausibility.

      -
      - -regions: Detect single entry single exit regions in a function -
      -
      +

      + -regions: Detect single entry single exit regions +

      +

      The RegionInfo pass detects single entry single exit regions in a function, where a region is defined as any subgraph that is connected to the @@ -784,10 +717,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -scalar-evolution: Scalar Evolution Analysis -

      -
      + +

      The ScalarEvolution analysis can be used to analyze and catagorize scalar expressions in loops. It specializes in recognizing general @@ -803,10 +736,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -scev-aa: -
      -
      +

      + -scev-aa: ScalarEvolution-based Alias Analysis +

      +

      Simple alias analysis implemented in terms of ScalarEvolution queries. This differs from traditional loop dependence analysis in that it tests @@ -819,62 +752,26 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -strip-dead-debug-info: Strip debug info for unused symbols -
      -
      -

      - performs code stripping. this transformation can delete: -

      - -
        -
      1. names for virtual registers
        2. -
      2. symbols for internal globals and functions
        3. -
      3. debug information
        4. -
      - -

      - note that this transformation makes code much less readable, so it should - only be used in situations where the strip utility would be used, - such as reducing code size or making it harder to reverse engineer code. -

      -
      - - -
      +

      -targetdata: Target Data Layout -

      -
      + +

      Provides other passes access to information on how the size and alignment required by the the target ABI for various data types.

      - -
      Transform Passes
      -
      -

      This section describes the LLVM Transform Passes.

      - -
      - -abcd: Remove redundant conditional branches -
      -
      -

      ABCD removes conditional branch instructions that can be proved redundant. - With the SSI representation, each variable has a constraint. By analyzing these - constraints we can prove that a branch is redundant. When a branch is proved - redundant it means that one direction will always be taken; thus, we can change - this branch into an unconditional jump.

      -

      It is advisable to run SimplifyCFG and - Aggressive Dead Code Elimination after ABCD - to clean up the code.

      -
      + +

      Transform Passes

      +
      +

      This section describes the LLVM Transform Passes.

      -
      +

      -adce: Aggressive Dead Code Elimination -

      -
      + +

      ADCE aggressively tries to eliminate code. This pass is similar to DCE but it assumes that values are dead until proven otherwise. This is similar to SCCP, except applied to @@ -882,19 +779,19 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -always-inline: Inliner for always_inline functions -

      -
      + +

      A custom inliner that handles only functions that are marked as "always inline".

      -
      +

      -argpromotion: Promote 'by reference' arguments to scalars -

      -
      + +

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

      \n" if !

      -
      +

      -block-placement: Profile Guided Basic Block Placement -

      -
      + +

      This pass is a very simple profile guided basic block placement algorithm. The idea is to put frequently executed blocks together at the start of the function and hopefully increase the number of fall-through conditional @@ -934,10 +831,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -break-crit-edges: Break critical edges in CFG -

      -
      + +

      Break all of the critical edges in the CFG by inserting a dummy basic block. It may be "required" by passes that cannot deal with critical edges. This @@ -947,20 +844,20 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      - -codegenprepare: Prepare a function for code generation -
      -
      +

      + -codegenprepare: Optimize for code generation +

      +
      This pass munges the code in the input function to better prepare it for SelectionDAG-based code generation. This works around limitations in it's basic-block-at-a-time approach. It should eventually be removed.
      -
      +

      -constmerge: Merge Duplicate Global Constants -

      -
      + +

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

      \n" if !

      -
      +

      -constprop: Simple constant propagation -

      -
      + +

      This file implements constant propagation and merging. It looks for instructions involving only constant operands and replaces them with a constant value instead of an instruction. For example:

      @@ -986,10 +883,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -dce: Dead Code Elimination -

      -
      + +

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

      \n" if !

      -
      +

      -deadargelim: Dead Argument Elimination -

      -
      + +

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

      \n" if !

      -
      +

      -deadtypeelim: Dead Type Elimination -

      -
      + +

      This pass is used to cleanup the output of GCC. It eliminate names for types that are unused in the entire translation unit, using the )) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -die: Dead Instruction Elimination -

      -
      + +

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

      \n" if !

      -
      +

      -dse: Dead Store Elimination -

      -
      + +

      A trivial dead store elimination that only considers basic-block local redundant stores. @@ -1050,10 +947,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -functionattrs: Deduce function attributes -

      -
      + +

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

      \n" if !

      -
      +

      -globaldce: Dead Global Elimination -

      -
      + +

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

      \n" if !

      -
      +

      -globalopt: Global Variable Optimizer -

      -
      + +

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

      \n" if !

      -
      +

      -gvn: Global Value Numbering -

      -
      + +

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

      \n" if !

      -
      +

      -indvars: Canonicalize Induction Variables -

      -
      + +

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

      \n" if !

      -
      +

      -inline: Function Integration/Inlining -

      -
      + +

      Bottom-up inlining of functions into callees.

      -
      +

      -insert-edge-profiling: Insert instrumentation for edge profiling -

      -
      + +

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

      \n" if !

      -
      +

      -insert-optimal-edge-profiling: Insert optimal instrumentation for edge profiling -

      -
      + +

      This pass instruments the specified program with counters for edge profiling. Edge profiling can give a reasonable approximation of the hot paths through a program, and is used for a wide variety of program transformations. @@ -1192,10 +1089,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -instcombine: Combine redundant instructions -

      -
      + +

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

      \n" if !

      -
      +

      -internalize: Internalize Global Symbols -

      -
      + +

      This pass loops over all of the functions in the input module, looking for a main function. If a main function is found, all other functions and all @@ -1258,10 +1155,10 @@ perl -e '$/ = undef; for (split(/\n/, <>)) { s:^ *///? ?::; print "

      \n" if !

      -
      +

      -ipconstprop: Interprocedural constant propagation -

      -
      + +

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

      \n" if !

      -
      +

      -ipsccp: Interprocedural Sparse Conditional Constant Propagation -

      -
      + +

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

      \n" if !

      -
      - -jump-threading: Thread control through conditional blocks -
      -
      +

      + -jump-threading: Jump Threading +

      +

      Jump threading tries to find distinct threads of control flow running through a basic block. This pass looks at blocks that have multiple predecessors and @@ -1312,10 +1209,10 @@ if (X < 3) {

      -
      +

      -lcssa: Loop-Closed SSA Form Pass -

      -
      + +

      This pass transforms loops by placing phi nodes at the end of the loops for all values that are live across the loop boundary. For example, it turns @@ -1341,10 +1238,10 @@ if (X < 3) {

      -
      +

      -licm: Loop Invariant Code Motion -

      -
      + +

      This pass performs loop invariant code motion, attempting to remove as much code from the body of a loop as possible. It does this by either hoisting @@ -1376,11 +1273,12 @@ if (X < 3) { variable.

      + -
      - -loop-deletion: Dead Loop Deletion Pass -
      -
      +

      + -loop-deletion: Delete dead loops +

      +

      This file implements the Dead Loop Deletion Pass. This pass is responsible for eliminating loops with non-infinite computable trip counts that have no @@ -1390,10 +1288,10 @@ if (X < 3) {

      -
      +

      -loop-extract: Extract loops into new functions -

      -
      + +

      A pass wrapper around the ExtractLoop() scalar transformation to extract each top-level loop into its own new function. If the loop is the @@ -1403,10 +1301,10 @@ if (X < 3) {

      -
      +

      -loop-extract-single: Extract at most one loop into a new function -

      -
      + +

      Similar to Extract loops into new functions, this pass extracts one natural loop from the program into a function if it @@ -1415,21 +1313,10 @@ if (X < 3) {

      -
      - -loop-index-split: Index Split Loops -
      -
      -

      - This pass divides loop's iteration range by spliting loop such that each - individual loop is executed efficiently. -

      -
      - - -
      +

      -loop-reduce: Loop Strength Reduction -

      -
      + +

      This pass performs a strength reduction on array references inside loops that have as one or more of their components the loop induction variable. This is @@ -1440,60 +1327,18 @@ if (X < 3) {

      -
      +

      -loop-rotate: Rotate Loops -

      -
      + +

      A simple loop rotation transformation.

      -
      - -loop-unroll: Unroll loops -
      -
      -

      - This pass implements a simple loop unroller. It works best when loops have - been canonicalized by the -indvars pass, - allowing it to determine the trip counts of loops easily. -

      -
      - - -
      - -loop-unswitch: Unswitch loops -
      -
      -

      - This pass transforms loops that contain branches on loop-invariant conditions - to have multiple loops. For example, it turns the left into the right code: -

      - - 
      for (...)                  if (lic)
-  A                          for (...)
-  if (lic)                     A; B; C
-    B                      else
-  C                          for (...)
-                               A; C
      - -

      - This can increase the size of the code exponentially (doubling it every time - a loop is unswitched) so we only unswitch if the resultant code will be - smaller than a threshold. -

      - -

      - This pass expects LICM to be run before it to hoist invariant conditions out - of the loop, to make the unswitching opportunity obvious. -

      -
      - - -
      +

      -loop-simplify: Canonicalize natural loops -

      -
      + +

      This pass performs several transformations to transform natural loops into a simpler form, which makes subsequent analyses and transformations simpler and @@ -1531,26 +1376,52 @@ if (X < 3) {

      -
      - -lowerallocs: Lower allocations from instructions to calls -
      -
      +

      + -loop-unroll: Unroll loops +

      +

      - Turn malloc and free instructions into @malloc and - @free calls. + This pass implements a simple loop unroller. It works best when loops have + been canonicalized by the -indvars pass, + allowing it to determine the trip counts of loops easily.

      +
      + +

      + -loop-unswitch: Unswitch loops +

      +
      +

      + This pass transforms loops that contain branches on loop-invariant conditions + to have multiple loops. For example, it turns the left into the right code: +

      + + 
      for (...)                  if (lic)
+  A                          for (...)
+  if (lic)                     A; B; C
+    B                      else
+  C                          for (...)
+                               A; C
      +

      - This is a target-dependent tranformation because it depends on the size of - data types and alignment constraints. + This can increase the size of the code exponentially (doubling it every time + a loop is unswitched) so we only unswitch if the resultant code will be + smaller than a threshold. +

      + +

      + This pass expects LICM to be run before it to hoist invariant conditions out + of the loop, to make the unswitching opportunity obvious.

      -
      - -loweratomic: Lower atomic intrinsics -
      -
      +

      + -loweratomic: Lower atomic intrinsics to non-atomic form +

      +

      This pass lowers atomic intrinsics to non-atomic form for use in a known non-preemptible environment. @@ -1565,10 +1436,10 @@ if (X < 3) {

      -
      +

      -lowerinvoke: Lower invoke and unwind, for unwindless code generators -

      -
      + +

      This transformation is designed for use by code generators which do not yet support stack unwinding. This pass supports two models of exception handling @@ -1606,10 +1477,10 @@ if (X < 3) {

      -
      +

      -lowersetjmp: Lower Set Jump -

      -
      + +

      Lowers setjmp and longjmp to use the LLVM invoke and unwind instructions as necessary. @@ -1635,10 +1506,10 @@ if (X < 3) {

      -
      +

      -lowerswitch: Lower SwitchInst's to branches -

      -
      + +

      Rewrites switch instructions with a sequence of branches, which allows targets to get away with not implementing the switch instruction until @@ -1647,10 +1518,10 @@ if (X < 3) {

      -
      +

      -mem2reg: Promote Memory to Register -

      -
      + +

      This file promotes memory references to be register references. It promotes alloca instructions which only have loads and @@ -1663,10 +1534,10 @@ if (X < 3) {

      -
      - -memcpyopt: Optimize use of memcpy and friend -
      -
      +

      + -memcpyopt: MemCpy Optimization +

      +

      This pass performs various transformations related to eliminating memcpy calls, or transforming sets of stores into memset's. @@ -1674,10 +1545,10 @@ if (X < 3) {

      -
      +

      -mergefunc: Merge Functions -

      -
      + +

      This pass looks for equivalent functions that are mergable and folds them. A hash is computed from the function, based on its type and number of @@ -1695,10 +1566,10 @@ if (X < 3) {

      -
      +

      -mergereturn: Unify function exit nodes -

      -
      + +

      Ensure that functions have at most one ret instruction in them. Additionally, it keeps track of which node is the new exit node of the CFG. @@ -1706,36 +1577,20 @@ if (X < 3) {

      -
      +

      -partial-inliner: Partial Inliner -

      -
      + +

      This pass performs partial inlining, typically by inlining an if statement that surrounds the body of the function.

      -
      - -partialspecialization: Partial Specialization -
      -
      -

      This pass finds function arguments that are often a common constant and - specializes a version of the called function for that constant. - - This pass simply does the cloning for functions it specializes. It depends - on IPSCCP and DAE to clean up the results. - - The initial heuristic favors constant arguments that are used in control - flow. -

      -
      - - -
      +

      -prune-eh: Remove unused exception handling info -

      -
      + +

      This file implements a simple interprocedural pass which walks the call-graph, turning invoke instructions into call instructions if and @@ -1745,10 +1600,10 @@ if (X < 3) {

      -
      +

      -reassociate: Reassociate expressions -

      -
      + +

      This pass reassociates commutative expressions in an order that is designed to promote better constant propagation, GCSE, LICM, PRE, etc. @@ -1768,10 +1623,10 @@ if (X < 3) {

      -
      +

      -reg2mem: Demote all values to stack slots -

      -
      + +

      This file demotes all registers to memory references. It is intented to be the inverse of -mem2reg. By converting to @@ -1785,10 +1640,10 @@ if (X < 3) {

      -
      - -scalarrepl: Scalar Replacement of Aggregates -
      -
      +

      + -scalarrepl: Scalar Replacement of Aggregates (DT) +

      +

      The well-known scalar replacement of aggregates transformation. This transform breaks up alloca instructions of aggregate type (structure @@ -1807,10 +1662,10 @@ if (X < 3) {

      -
      +

      -sccp: Sparse Conditional Constant Propagation -

      -
      + +

      Sparse conditional constant propagation and merging, which can be summarized as: @@ -1830,20 +1685,10 @@ if (X < 3) {

      -
      - -sink: Code Sinking -
      -
      -

      This pass moves instructions into successor blocks, when possible, so that - they aren't executed on paths where their results aren't needed. -

      -
      - - -
      +

      -simplify-libcalls: Simplify well-known library calls -

      -
      + +

      Applies a variety of small optimizations for calls to specific well-known function calls (e.g. runtime library functions). For example, a call @@ -1853,20 +1698,10 @@ if (X < 3) {

      -
      - -simplify-libcalls-halfpowr: Simplify half_powr library calls -
      -
      -

      Simple pass that applies an experimental transformation on calls - to specific functions. -

      -
      - - -
      +

      -simplifycfg: Simplify the CFG -

      -
      + +

      Performs dead code elimination and basic block merging. Specifically:

      @@ -1882,47 +1717,43 @@ if (X < 3) {
      -
      - -split-geps: Split complex GEPs into simple GEPs -
      -
      -

      This function breaks GEPs with more than 2 non-zero operands into smaller - GEPs each with no more than 2 non-zero operands. This exposes redundancy - between GEPs with common initial operand sequences. +

      + -sink: Code sinking +

      +
      +

      This pass moves instructions into successor blocks, when possible, so that + they aren't executed on paths where their results aren't needed.

      -
      - -ssi: Static Single Information Construction -
      -
      -

      This pass converts a list of variables to the Static Single Information - form. - - We are building an on-demand representation, that is, we do not convert - every single variable in the target function to SSI form. Rather, we receive - a list of target variables that must be converted. We also do not - completely convert a target variable to the SSI format. Instead, we only - change the variable in the points where new information can be attached - to its live range, that is, at branch points. +

      + -sretpromotion: Promote sret arguments to multiple ret values +

      +
      +

      + This pass finds functions that return a struct (using a pointer to the struct + as the first argument of the function, marked with the 'sret' attribute) and + replaces them with a new function that simply returns each of the elements of + that struct (using multiple return values).

      -
      - -
      - -ssi-everything: Static Single Information Construction (everything, intended for debugging) -
      -
      -

      A pass that runs SSI on every non-void variable, intended for debugging. +

      + This pass works under a number of conditions:

      + +
        +
      • The returned struct must not contain other structs
        • +
      • The returned struct must only be used to load values from
        • +
      • The placeholder struct passed in is the result of an alloca
        • +
      -
      +

      -strip: Strip all symbols from a module -

      -
      + +

      performs code stripping. this transformation can delete:

      @@ -1941,10 +1772,32 @@ if (X < 3) {
      -
      - -strip-dead-prototypes: Remove unused function declarations +

      + -strip-dead-debug-info: Strip debug info for unused symbols +

      +
      +

      + performs code stripping. this transformation can delete: +

      + +
        +
      1. names for virtual registers
        2. +
      2. symbols for internal globals and functions
        3. +
      3. debug information
        4. +
      + +

      + note that this transformation makes code much less readable, so it should + only be used in situations where the strip utility would be used, + such as reducing code size or making it harder to reverse engineer code. +

      -
      + + +

      + -strip-dead-prototypes: Strip Unused Function Prototypes +

      +

      This pass loops over all of the functions in the input module, looking for dead declarations and removes them. Dead declarations are declarations of @@ -1954,10 +1807,10 @@ if (X < 3) {

      -
      +

      -strip-debug-declare: Strip all llvm.dbg.declare intrinsics -

      -
      + +

      This pass implements code stripping. Specifically, it can delete:

      • names for virtual registers
        • @@ -1972,10 +1825,10 @@ if (X < 3) {
      -
      +

      -strip-nondebug: Strip all symbols, except dbg symbols, from a module -

      -
      + +

      This pass implements code stripping. Specifically, it can delete:

      • names for virtual registers
        • @@ -1990,33 +1843,10 @@ if (X < 3) {
      -
      - -sretpromotion: Promote sret arguments -
      -
      -

      - This pass finds functions that return a struct (using a pointer to the struct - as the first argument of the function, marked with the 'sret' attribute) and - replaces them with a new function that simply returns each of the elements of - that struct (using multiple return values). -

      - -

      - This pass works under a number of conditions: -

      - -
        -
      • The returned struct must not contain other structs
        • -
      • The returned struct must only be used to load values from
        • -
      • The placeholder struct passed in is the result of an alloca
        • -
      -
      - - -
      +

      -tailcallelim: Tail Call Elimination -

      -
      + +

      This file transforms calls of the current function (self recursion) followed by a return instruction with a branch to the entry of the function, creating @@ -2045,10 +1875,10 @@ if (X < 3) {

      -
      +

      -tailduplicate: Tail Duplication -

      -
      + +

      This pass performs a limited form of tail duplication, intended to simplify CFGs by removing some unconditional branches. This pass is necessary to @@ -2058,17 +1888,18 @@ if (X < 3) {

      +
      + -
      Utility Passes
      -
      +

      Utility Passes

      +

      This section describes the LLVM Utility Passes.

      -
      -
      +

      -deadarghaX0r: Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE) -

      -
      + +

      Same as dead argument elimination, but deletes arguments to functions which are external. This is only for use by

      -
      +

      -extract-blocks: Extract Basic Blocks From Module (for bugpoint use) -

      -
      + +

      This pass is used by bugpoint to extract all blocks from the module into their own functions.

      -
      +

      -instnamer: Assign names to anonymous instructions -

      -
      + +

      This is a little utility pass that gives instructions names, this is mostly useful when diffing the effect of an optimization because deleting an unnamed instruction can change all other instruction numbering, making the @@ -2098,10 +1929,10 @@ if (X < 3) {

      -
      +

      -preverify: Preliminary module verification -

      -
      + +

      Ensures that the module is in the form required by the Module Verifier pass. @@ -2114,10 +1945,10 @@ if (X < 3) {

      -
      +

      -verify: Module Verifier -

      -
      + +

      Verifies an LLVM IR code. This is useful to run after an optimization which is undergoing testing. Note that llvm-as verifies its input before @@ -2165,20 +1996,20 @@ if (X < 3) {

      -
      +

      -view-cfg: View CFG of function -

      -
      + +

      Displays the control flow graph using the GraphViz tool.

      -
      +

      -view-cfg-only: View CFG of function (with no function bodies) -

      -
      + +

      Displays the control flow graph using the GraphViz tool, but omitting function bodies. @@ -2186,22 +2017,20 @@ if (X < 3) {

      -
      - -view-dom: View dominator tree of function -
      -
      +

      + -view-dom: View dominance tree of function +

      +

      Displays the dominator tree using the GraphViz tool.

      -
      - -view-dom-only: View dominator tree of function (with no function - bodies) - -
      -
      +

      + -view-dom-only: View dominance tree of function (with no function bodies) +

      +

      Displays the dominator tree using the GraphViz tool, but omitting function bodies. @@ -2209,28 +2038,28 @@ if (X < 3) {

      -
      - -view-postdom: View post dominator tree of function -
      -
      +

      + -view-postdom: View postdominance tree of function +

      +

      Displays the post dominator tree using the GraphViz tool.

      -
      - -view-postdom-only: View post dominator tree of function (with no - function bodies) - -
      -
      +

      + -view-postdom-only: View postdominance tree of function (with no function bodies) +

      +

      Displays the post dominator tree using the GraphViz tool, but omitting function bodies.

      +
      +
      @@ -2241,8 +2070,8 @@ if (X < 3) { src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Reid Spencer
      - LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-13 21:57:25 +0100 (Sun, 13 Feb 2011) $ + LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index 0351dd03b7d0..6af922b4071c 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -8,9 +8,9 @@ -
      +

      LLVM Programmer's Manual -

      +
      1. Introduction
        2. @@ -56,6 +56,7 @@ option
      -
      +

      Introduction -

      + -
      +

      This document is meant to highlight some of the important classes and interfaces available in the LLVM source-base. This manual is not @@ -240,24 +242,22 @@ href="/doxygen/InstVisitor_8h-source.html">InstVisitor template.

      -
      +

      General Information -

      + -
      +

      This section contains general information that is useful if you are working in the LLVM source-base, but that isn't specific to any particular API.

      -
      - -
      +

      The C++ Standard Template Library -

      + -
      +

      LLVM makes heavy use of the C++ Standard Template Library (STL), perhaps much more than you are used to, or have seen before. Because of @@ -303,11 +303,11 @@ to write maintainable code more than where to put your curly braces.

      -
      +

      Other useful references -

      + -
      + +
      + -
      +

      Important and useful LLVM APIs -

      + -
      +

      Here we highlight some LLVM APIs that are generally useful and good to know about when writing transformations.

      -
      - -
      +

      The isa<>, cast<> and dyn_cast<> templates -

      + -
      +

      The LLVM source-base makes extensive use of a custom form of RTTI. These templates have many similarities to the C++ dynamic_cast<> @@ -440,12 +440,12 @@ are lots of examples in the LLVM source base.

      -
      +

      Passing strings (the StringRef and Twine classes) -

      + -
      +

      Although LLVM generally does not do much string manipulation, we do have several important APIs which take strings. Two important examples are the @@ -459,14 +459,12 @@ clients to perform a heap allocation which is usually unnecessary. Instead, many LLVM APIs use a StringRef or a const Twine& for passing strings efficiently.

      -
      - -
      +

      The StringRef class -

      + -
      +

      The StringRef data type represents a reference to a constant string (a character array and a length) and supports the common operations available @@ -502,11 +500,11 @@ small and pervasive enough in LLVM that it should always be passed by value.

      -
      +

      The Twine class -

      + -
      +

      The Twine class is an efficient way for APIs to accept concatenated strings. For example, a common LLVM paradigm is to name one instruction based on @@ -537,13 +535,14 @@ accept concatenated strings.

      +
      -
      +

      The DEBUG() macro and -debug option -

      + -
      +

      Often when working on your pass you will put a bunch of debugging printouts and other code into your pass. After you get it working, you want to remove @@ -589,15 +588,13 @@ enable or disable it directly in gdb. Just use "set DebugFlag=0" or program hasn't been started yet, you can always just run it with -debug.

      -
      - -
      +

      Fine grained debug info with DEBUG_TYPE and the -debug-only option -

      + -
      +

      Sometimes you may find yourself in a situation where enabling -debug just turns on too much information (such as when working on the code @@ -665,13 +662,15 @@ DEBUG_WITH_TYPE("", errs() << "No debug type (2)\n");

      +
      + -
      +

      The Statistic class & -stats option -

      + -
      +

      The "llvm/ADT/Statistic.h" file @@ -766,11 +765,11 @@ maintainable and useful.

      -
      +

      Viewing graphs while debugging code -

      + -
      +

      Several of the important data structures in LLVM are graphs: for example CFGs made out of LLVM BasicBlocks, CFGs made out of @@ -814,13 +813,15 @@ attributes, then you can call DAG.clearGraphAttrs().

      +
      + -
      +

      Picking the Right Data Structure for a Task -

      + -
      +

      LLVM has a plethora of data structures in the llvm/ADT/ directory, and we commonly use STL data structures. This section describes the trade-offs @@ -876,35 +877,47 @@ elements (but could contain many), for example, it's much better to use . Doing so avoids (relatively) expensive malloc/free calls, which dwarf the cost of adding the elements to the container.

      -
      - -
      +

      Sequential Containers (std::vector, std::list, etc) -

      + -
      +
      There are a variety of sequential containers available for you, based on your needs. Pick the first in this section that will do what you want. + + +

      + llvm/ADT/ArrayRef.h +

      + +
      +

      The llvm::ArrayRef class is the preferred class to use in an interface that + accepts a sequential list of elements in memory and just reads from them. By + taking an ArrayRef, the API can be passed a fixed size array, an std::vector, + an llvm::SmallVector and anything else that is contiguous in memory. +

      + + -
      +

      Fixed Size Arrays -

      + -
      +

      Fixed size arrays are very simple and very fast. They are good if you know exactly how many elements you have, or you have a (low) upper bound on how many you have.

      -
      +

      Heap Allocated Arrays -

      + -
      +

      Heap allocated arrays (new[] + delete[]) are also simple. They are good if the number of elements is variable, if you know how many elements you will need before the array is allocated, and if the array is usually large (if not, @@ -916,11 +929,11 @@ construct those elements actually used).

      -
      +

      "llvm/ADT/SmallVector.h" -

      + -
      +

      SmallVector<Type, N> is a simple class that looks and smells just like vector<Type>: it supports efficient iteration, lays out elements in memory order (so you can @@ -945,11 +958,11 @@ SmallVectors are most useful when on the stack.

      -
      +

      <vector> -

      + -
      +

      std::vector is well loved and respected. It is useful when SmallVector isn't: when the size of the vector is often large (thus the small optimization will @@ -987,11 +1000,11 @@ the loop.

      -
      +

      <deque> -

      + -
      +

      std::deque is, in some senses, a generalized version of std::vector. Like std::vector, it provides constant time random access and other similar properties, but it also provides efficient access to the front of the list. It @@ -1003,11 +1016,11 @@ something cheaper.

      -
      +

      <list> -

      + -
      +

      std::list is an extremely inefficient class that is rarely useful. It performs a heap allocation for every element inserted into it, thus having an extremely high constant factor, particularly for small data types. std::list @@ -1021,11 +1034,11 @@ not invalidate iterator or pointers to other elements in the list.

      -
      +

      llvm/ADT/ilist.h -

      + -
      +

      ilist<T> implements an 'intrusive' doubly-linked list. It is intrusive, because it requires the element to store and provide access to the prev/next pointers for the list.

      @@ -1051,22 +1064,22 @@ Related classes of interest are explained in the following subsections:
      -
      +

      ilist_traits -

      + -
      +

      ilist_traits<T> is ilist<T>'s customization mechanism. iplist<T> (and consequently ilist<T>) publicly derive from this traits class.

      -
      +

      iplist -

      + -
      +

      iplist<T> is ilist<T>'s base and as such supports a slightly narrower interface. Notably, inserters from T& are absent.

      @@ -1076,11 +1089,11 @@ used for a wide variety of customizations.

      -
      +

      llvm/ADT/ilist_node.h -

      + -
      +

      ilist_node<T> implements a the forward and backward links that are expected by the ilist<T> (and analogous containers) in the default manner.

      @@ -1091,11 +1104,11 @@ in the default manner.

      -
      +

      Sentinels -

      + -
      +

      ilists have another specialty that must be considered. To be a good citizen in the C++ ecosystem, it needs to support the standard container operations, such as begin and end iterators, etc. Also, the @@ -1129,11 +1142,11 @@ field in the ghostly sentinel which can be legally accessed.

      -
      +

      Other Sequential Container options -

      + -
      +

      Other STL containers are available, such as std::string.

      There are also various STL adapter classes such as std::queue, @@ -1142,27 +1155,25 @@ underlying container but don't affect the cost of the container itself.

      +
      -
      +

      Set-Like Containers (std::set, SmallSet, SetVector, etc) -

      + -
      +

      Set-like containers are useful when you need to canonicalize multiple values into a single representation. There are several different choices for how to do this, providing various trade-offs.

      -
      - - -
      +

      A sorted 'vector' -

      + -
      +

      If you intend to insert a lot of elements, then do a lot of queries, a great approach is to use a vector (or other sequential container) with @@ -1180,11 +1191,11 @@ efficiently queried with a standard binary or radix search.

      -
      +

      "llvm/ADT/SmallSet.h" -

      + -
      +

      If you have a set-like data structure that is usually small and whose elements are reasonably small, a SmallSet<Type, N> is a good choice. This set @@ -1203,11 +1214,11 @@ and erasing, but does not support iteration.

      -
      +

      "llvm/ADT/SmallPtrSet.h" -

      + -
      +

      SmallPtrSet has all the advantages of SmallSet (and a SmallSet of pointers is transparently implemented with a SmallPtrSet), but also supports iterators. If @@ -1223,11 +1234,11 @@ visited in sorted order.

      -
      +

      "llvm/ADT/DenseSet.h" -

      + -
      +

      DenseSet is a simple quadratically probed hash table. It excels at supporting @@ -1242,11 +1253,11 @@ href="#dss_densemap">DenseMap has.

      -
      +

      "llvm/ADT/FoldingSet.h" -

      + -
      +

      FoldingSet is an aggregate class that is really good at uniquing @@ -1279,11 +1290,11 @@ elements.

      -
      +

      <set> -

      + -
      +

      std::set is a reasonable all-around set class, which is decent at many things but great at nothing. std::set allocates memory for each element @@ -1304,11 +1315,11 @@ std::set is almost never a good choice.

      -
      +

      "llvm/ADT/SetVector.h" -

      + -
      +

      LLVM's SetVector<Type> is an adapter class that combines your choice of a set-like container along with a Sequential Container. The important property @@ -1344,11 +1355,11 @@ heap traffic.

      -
      +

      "llvm/ADT/UniqueVector.h" -

      + -
      +

      UniqueVector is similar to SetVector, but it @@ -1364,11 +1375,11 @@ factors, and produces a lot of malloc traffic. It should be avoided.

      -
      +

      Other Set-Like Container Options -

      + -
      +

      The STL provides several other options, such as std::multiset and the various @@ -1384,22 +1395,23 @@ better.

      +
      + -
      +

      Map-Like Containers (std::map, DenseMap, etc) -

      + -
      +
      Map-like containers are useful when you want to associate data to a key. As usual, there are a lot of different ways to do this. :) -
      -
      +

      A sorted 'vector' -

      + -
      +

      If your usage pattern follows a strict insert-then-query approach, you can @@ -1412,11 +1424,11 @@ vectors for sets.

      -
      +

      "llvm/ADT/StringMap.h" -

      + -
      +

      Strings are commonly used as keys in maps, and they are difficult to support @@ -1446,11 +1458,11 @@ copies a string if a value is inserted into the table.

      -
      +

      "llvm/ADT/IndexedMap.h" -

      + -
      +

      IndexedMap is a specialized container for mapping small dense integers (or values that can be mapped to small dense integers) to some other type. It is @@ -1466,11 +1478,11 @@ virtual register ID).

      -
      +

      "llvm/ADT/DenseMap.h" -

      + -
      +

      DenseMap is a simple quadratically probed hash table. It excels at supporting @@ -1492,11 +1504,11 @@ inserted into the map) that it needs internally.

      -
      +

      "llvm/ADT/ValueMap.h" -

      + -
      +

      ValueMap is a wrapper around a DenseMap mapping @@ -1509,11 +1521,11 @@ a Config parameter to the ValueMap template.

      -
      +

      "llvm/ADT/IntervalMap.h" -

      + -
      +

      IntervalMap is a compact map for small keys and values. It maps key intervals instead of single keys, and it will automatically coalesce adjacent @@ -1526,11 +1538,11 @@ as STL iterators. The heavyweight iterators allow a smaller data structure.

      -
      +

      <map> -

      + -
      +

      std::map has similar characteristics to std::set: it uses @@ -1546,11 +1558,31 @@ another element takes place).

      -
      - Other Map-Like Container Options +

      + "llvm/ADT/IntEqClasses.h" +

      + +
      + +

      IntEqClasses provides a compact representation of equivalence classes of +small integers. Initially, each integer in the range 0..n-1 has its own +equivalence class. Classes can be joined by passing two class representatives to +the join(a, b) method. Two integers are in the same class when findLeader() +returns the same representative.

      + +

      Once all equivalence classes are formed, the map can be compressed so each +integer 0..n-1 maps to an equivalence class number in the range 0..m-1, where m +is the total number of equivalence classes. The map must be uncompressed before +it can be edited again.

      +
      -
      + +

      + Other Map-Like Container Options +

      + +

      The STL provides several other options, such as std::multimap and the various @@ -1564,12 +1596,14 @@ always better.

      +
      + -
      +

      String-like containers -

      + -
      +

      TODO: const char* vs stringref vs smallstring vs std::string. Describe twine, @@ -1579,11 +1613,11 @@ xref to #string_apis.

      -
      +

      Bit storage containers (BitVector, SparseBitVector) -

      + -
      +

      Unlike the other containers, there are only two bit storage containers, and choosing when to use each is relatively straightforward.

      @@ -1593,14 +1627,13 @@ implementation in many common compilers (e.g. commonly available versions of GCC) is extremely inefficient and 2) the C++ standards committee is likely to deprecate this container and/or change it significantly somehow. In any case, please don't use it.

      -
      -
      +

      BitVector -

      + -
      +

      The BitVector container provides a dynamic size set of bits for manipulation. It supports individual bit setting/testing, as well as set operations. The set operations take time O(size of bitvector), but operations are performed one word @@ -1611,11 +1644,11 @@ the number of set bits to be high (IE a dense set).

      -
      +

      SmallBitVector -

      + -
      +

      The SmallBitVector container provides the same interface as BitVector, but it is optimized for the case where only a small number of bits, less than 25 or so, are needed. It also transparently supports larger bit counts, but @@ -1630,11 +1663,11 @@ and its operator[] does not provide an assignable lvalue.

      -
      +

      SparseBitVector -

      + -
      +

      The SparseBitVector container is much like BitVector, with one major difference: Only the bits that are set, are stored. This makes the SparseBitVector much more space efficient than BitVector when the set is sparse, @@ -1644,13 +1677,17 @@ universe). The downside to the SparseBitVector is that setting and testing of r

      +
      + +
      + -
      +

      Helpful Hints for Common Operations -

      + -
      +

      This section describes how to perform some very simple transformations of LLVM code. This is meant to give examples of common idioms used, showing the @@ -1659,15 +1696,13 @@ you should also read about the main classes that you will be working with. The Core LLVM Class Hierarchy Reference contains details and descriptions of the main classes that you should know about.

      -
      - -
      +

      Basic Inspection and Traversal Routines -

      + -
      +

      The LLVM compiler infrastructure have many different data structures that may be traversed. Following the example of the C++ standard template library, the @@ -1684,16 +1719,14 @@ on them, and it is easier to remember how to iterate. First we show a few common examples of the data structures that need to be traversed. Other data structures are traversed in very similar ways.

      -
      - -
      +

      Iterating over the BasicBlocks in a Function -

      + -
      +

      It's quite common to have a Function instance that you'd like to transform in some way; in particular, you'd like to manipulate its @@ -1722,13 +1755,13 @@ exactly equivalent to (*i).size() just like you'd expect.

      -
      +

      Iterating over the Instructions in a BasicBlock -

      + -
      +

      Just like when dealing with BasicBlocks in Functions, it's easy to iterate over the individual instructions that make up @@ -1753,13 +1786,13 @@ basic block itself: errs() << *blk << "\n";.

      -
      +

      Iterating over the Instructions in a Function -

      + -
      +

      If you're finding that you commonly iterate over a Function's BasicBlocks and then that BasicBlock's Instructions, @@ -1799,12 +1832,12 @@ for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I)

      -
      +

      Turning an iterator into a class pointer (and vice-versa) -

      + -
      +

      Sometimes, it'll be useful to grab a reference (or pointer) to a class instance when all you've got at hand is an iterator. Well, extracting @@ -1876,12 +1909,12 @@ and operator* changed to return a pointer instead of a reference.

      -
      +

      Finding call sites: a slightly more complex example -

      + -
      +

      Say that you're writing a FunctionPass and would like to count all the locations in the entire module (that is, across every Function) where a @@ -1938,11 +1971,11 @@ class OurFunctionPass : public FunctionPass {

      -
      +

      Treating calls and invokes the same way -

      + -
      +

      You may have noticed that the previous example was a bit oversimplified in that it did not deal with call sites generated by 'invoke' instructions. In @@ -1965,11 +1998,11 @@ If you look at its definition, it has only a single pointer member.

      -
      +

      Iterating over def-use & use-def chains -

      + -
      +

      Frequently, we might have an instance of the Value Class and we want to @@ -2026,12 +2059,12 @@ calling use/op_begin() on const Value*s or

      -
      +

      Iterating over predecessors & successors of blocks -

      + -
      +

      Iterating over the predecessors and successors of a block is quite easy with the routines defined in "llvm/Support/CFG.h". Just use code like @@ -2054,13 +2087,14 @@ succ_iterator/succ_begin/succ_end.

      +
      -
      +

      Making simple changes -

      + -
      +

      There are some primitive transformation operations present in the LLVM infrastructure that are worth knowing about. When performing @@ -2068,15 +2102,13 @@ transformations, it's fairly common to manipulate the contents of basic blocks. This section describes some of the common methods for doing so and gives example code.

      -
      - -
      +

      Creating and inserting new Instructions -

      + -
      +

      Instantiating Instructions

      @@ -2212,18 +2244,15 @@ Instruction* newInst = new Instruction(..., pi);
      -
      +

      Deleting Instructions -

      + -
      +

      Deleting an instruction from an existing sequence of instructions that form a -BasicBlock is very straight-forward. First, -you must have a pointer to the instruction that you wish to delete. Second, you -need to obtain the pointer to that instruction's basic block. You use the -pointer to the basic block to get its list of instructions and then use the -erase function to remove your instruction. For example:

      +BasicBlock is very straight-forward: just +call the instruction's eraseFromParent() method. For example:

      @@ -2232,15 +2261,19 @@ I->eraseFromParent();
      +

      This unlinks the instruction from its containing basic block and deletes +it. If you'd just like to unlink the instruction from its containing basic +block but not delete it, you can use the removeFromParent() method.

      +
      -
      +

      Replacing an Instruction with another Value -

      + -
      +

      Replacing individual instructions

      @@ -2248,7 +2281,7 @@ I->eraseFromParent(); permits use of two very useful replace functions: ReplaceInstWithValue and ReplaceInstWithInst.

      -

      Deleting Instructions

      +
      Deleting Instructions
      • ReplaceInstWithValue @@ -2301,11 +2334,11 @@ ReplaceInstWithValue, ReplaceInstWithInst -->
      -
      +

      Deleting GlobalVariables -

      + -
      +

      Deleting a global variable from a module is just as easy as deleting an Instruction. First, you must have a pointer to the global variable that you wish @@ -2322,12 +2355,14 @@ GV->eraseFromParent();

      +
      + -
      +

      How to Create Types -

      + -
      +

      In generating IR, you may need some complex types. If you know these types statically, you can use TypeBuilder<...>::get(), defined @@ -2362,13 +2397,15 @@ comment for more details.

      +
      + -
      +

      Threads and LLVM -

      + -
      +

      This section describes the interaction of the LLVM APIs with multithreading, both on the part of client applications, and in the JIT, in the hosted @@ -2391,14 +2428,13 @@ compiler, consider compiling LLVM and LLVM-GCC in single-threaded mode, and using the resultant compiler to build a copy of LLVM with multithreading support.

      -
      -
      +

      Entering and Exiting Multithreaded Mode -

      + -
      +

      In order to properly protect its internal data structures while avoiding @@ -2431,11 +2467,11 @@ result in concurrent LLVM API calls.

      -
      +

      Ending Execution with llvm_shutdown() -

      + -
      +

      When you are done using the LLVM APIs, you should call llvm_shutdown() to deallocate memory used for internal structures. This will also invoke @@ -2451,11 +2487,11 @@ destructor.

      -
      +

      Lazy Initialization with ManagedStatic -

      + -
      +

      ManagedStatic is a utility class in LLVM used to implement static initialization of static resources, such as the global type tables. Before the @@ -2480,11 +2516,11 @@ and only if you know what you're doing!

      -
      +

      Achieving Isolation with LLVMContext -

      + -
      +

      LLVMContext is an opaque class in the LLVM API which clients can use to operate multiple, isolated instances of LLVM concurrently within the same @@ -2524,11 +2560,11 @@ isolation is not a concern.

      -
      +

      Threads and the JIT -

      + -
      +

      LLVM's "eager" JIT compiler is safe to use in threaded programs. Multiple threads can call ExecutionEngine::getPointerToFunction() or @@ -2551,26 +2587,27 @@ access, but we suggest using only the eager JIT in threaded programs.

      +
      + -
      +

      Advanced Topics -

      + -
      +

      This section describes some of the advanced or obscure API's that most clients do not need to be aware of. These API's tend manage the inner workings of the LLVM system, and only need to be accessed in unusual circumstances.

      -
      -
      +

      LLVM Type Resolution -

      + -
      +

      The LLVM type system has a very simple goal: allow clients to compare types for @@ -2599,14 +2636,12 @@ Third, a concrete type is a type that is not an abstract type (e.g. "{ i32, float }").

      -
      - -
      +

      Basic Recursive Type Construction -

      + -
      +

      Because the most common question is "how do I build a recursive type with LLVM", @@ -2658,11 +2693,11 @@ href="#PATypeHolder">PATypeHolder class.

      -
      +

      The refineAbstractTypeTo method -

      + -
      +

      The refineAbstractTypeTo method starts the type unification process. While this method is actually a member of the DerivedType class, it is most @@ -2688,11 +2723,11 @@ complex datastructures.

      -
      +

      The PATypeHolder Class -

      + -
      +

      PATypeHolder is a form of a "smart pointer" for Type objects. When VMCore happily goes about nuking types that become isomorphic to existing types, it @@ -2710,11 +2745,11 @@ Type is maintained by PATypeHolder objects.

      -
      +

      The AbstractTypeUser Class -

      + -
      +

      Some data structures need more to perform more complex updates when types get @@ -2728,14 +2763,15 @@ objects) can never be refined.

      +
      -
      +

      The ValueSymbolTable and TypeSymbolTable classes -

      + -
      +

      The ValueSymbolTable class provides a symbol table that the Function and @@ -2766,11 +2802,11 @@ insert entries into the symbol table.

      -
      +

      The User and owned Use classes' memory layout -

      + -
      +

      The User class provides a basis for expressing the ownership of User towards other @@ -2779,18 +2815,19 @@ Use helper class is employed to do the bookkeeping and to facilitate -

      - Interaction and relationship between User and Use objects -
      +

      + + Interaction and relationship between User and Use objects + +

      -
      +

      A subclass of User can choose between incorporating its Use objects or refer to them out-of-line by means of a pointer. A mixed variant (some Uses inline others hung off) is impractical and breaks the invariant that the Use objects belonging to the same User form a contiguous array.

      -

      We have 2 different layouts in the User (sub)classes: @@ -2839,17 +2876,18 @@ enforce the following memory layouts:

      (In the above figures 'P' stands for the Use** that is stored in each Use object in the member Use::Prev) +
      + -
      +

      The waymarking algorithm -

      + -
      +

      Since the Use objects are deprived of the direct (back)pointer to their User objects, there must be a fast and exact method to recover it. This is accomplished by the following scheme:

      -
      A bit-encoding in the 2 LSBits (least significant bits) of the Use::Prev allows to find the start of the User object: @@ -2880,15 +2918,16 @@ Only the significant number of bits need to be stored between the stops, so that the worst case is 20 memory accesses when there are 1000 Use objects associated with a User.

      +
      + -
      +

      Reference implementation -

      + -
      +

      The following literate Haskell fragment demonstrates the concept:

      -
      @@ -2970,10 +3009,14 @@ And here is the result of <deepCheck identityProp>:
      
 OK, passed 500 tests.
      +
      + -
      +

      Tagging considerations -

      + + +

      To maintain the invariant that the 2 LSBits of each Use** in Use @@ -2989,13 +3032,17 @@ the LSBit set. (Portability is relying on the fact that all known compilers plac

      - -
      - The Core LLVM Class Hierarchy Reference
      + +
      + + +

      + The Core LLVM Class Hierarchy Reference +

      -
      +

      #include "llvm/Type.h"
      doxygen info: Type Class

      @@ -3004,14 +3051,12 @@ being inspected or transformed. The core LLVM classes are defined in header files in the include/llvm/ directory, and implemented in the lib/VMCore directory.

      -
      - -
      +

      The Type class and Derived Types -

      + -
      +

      Type is a superclass of all type classes. Every Value has a Type. Type cannot be instantiated directly but only @@ -3026,14 +3071,13 @@ the lib/VMCore directory.

      be performed with address equality of the Type Instance. That is, given two Type* values, the types are identical if the pointers are identical.

      -
      -
      +

      Important Public Methods -

      + -
      +
      • bool isIntegerTy() const: Returns true for any integer type.
        • @@ -3051,10 +3095,10 @@ the lib/VMCore directory.

      -
      +

      Important Derived Types -

      -
      + +
      IntegerType
      Subclass of DerivedType that represents integer types of any bit width. @@ -3116,14 +3160,14 @@ the lib/VMCore directory.

      - +
      -
      +

      The Module class -

      + -
      +

      #include "llvm/Module.h"
      doxygen info: @@ -3138,14 +3182,12 @@ href="#GlobalVariable">GlobalVariables, and a SymbolTable. Additionally, it contains a few helpful member functions that try to make common operations easy.

      -
      - -
      +

      Important Public Members of the Module class -

      + -
      +
      • Module::Module(std::string name = "")
        • @@ -3244,13 +3286,14 @@ provide a name for it (probably based on the name of the translation unit).

      +
      -
      +

      The Value class -

      + -
      +

      #include "llvm/Value.h"
      @@ -3301,14 +3344,12 @@ the class that represents this value. Although this may take some getting used to, it simplifies the representation and makes it easier to manipulate.

      -
      - -
      +

      Important Public Members of the Value class -

      + -
      +
      • Value::use_iterator - Typedef for iterator over the @@ -3355,12 +3396,14 @@ Inst->replaceAllUsesWith(ConstVal);
      +
      + -
      +

      The User class -

      + -
      +

      #include "llvm/User.h"
      @@ -3379,14 +3422,12 @@ Single Assignment (SSA) form, there can only be one definition referred to, allowing this direct connection. This connection provides the use-def information in LLVM.

      -
      - -
      +

      Important Public Members of the User class -

      + -
      +

      The User class exposes the operand list in two ways: through an index access interface and through an iterator based interface.

      @@ -3409,12 +3450,14 @@ the operands of a User.

      +
      + -
      +

      The Instruction class -

      + -
      +

      #include "llvm/Instruction.h"
      @@ -3445,14 +3488,13 @@ href="#CmpInst">CmpInst). Unfortunately, the use of macros in this file confuses doxygen, so these enum values don't show up correctly in the doxygen output.

      -
      - -
      - Important Subclasses of the Instruction - class -
      -
      +

      + + Important Subclasses of the Instruction class + +

      +
      • BinaryOperator

        This subclasses represents all two operand instructions whose operands @@ -3471,12 +3513,13 @@ this file confuses doxygen, so these enum values don't show up correctly in the

      -
      - Important Public Members of the Instruction - class -
      +

      + + Important Public Members of the Instruction class + +

      -
      +
      • BasicBlock *getParent() @@ -3496,12 +3539,14 @@ and it has no name

      +
      + -
      +

      The Constant class and subclasses -

      + -
      +

      Constant represents a base class for different types of constants. It is subclassed by ConstantInt, ConstantArray, etc. for representing @@ -3509,11 +3554,9 @@ the various types of Constants. GlobalValue is also a subclass, which represents the address of a global variable or function.

      -
      - -
      Important Subclasses of Constant
      -
      +

      Important Subclasses of Constant

      +
      • ConstantInt : This subclass of Constant represents an integer constant of any width. @@ -3561,13 +3604,14 @@ a subclass, which represents the address of a global variable or function.
      +
      -
      +

      The GlobalValue class -

      + -
      +

      #include "llvm/GlobalValue.h"
      @@ -3607,15 +3651,14 @@ dereference the pointer with GetElementPtrInst first, then its elements can be accessed. This is explained in the LLVM Language Reference Manual.

      -
      - -
      - Important Public Members of the GlobalValue - class -
      +

      + + Important Public Members of the GlobalValue class + +

      -
      +
      • bool hasInternalLinkage() const
        @@ -3631,12 +3674,14 @@ GlobalValue is currently embedded into.

      +
      + -
      +

      The Function class -

      + -
      +

      #include "llvm/Function.h"
      doxygen @@ -3683,15 +3728,15 @@ href="#Argument">Arguments in the function body.

      Note that Function is a GlobalValue and therefore also a Constant. The value of the function is its address (after linking) which is guaranteed to be constant.

      -
      -
      - Important Public Members of the Function - class -
      +

      + + Important Public Members of the Function class + +

      -
      +
      • Function(const FunctionType @@ -3769,12 +3814,14 @@ iterator
      +
      + -
      +

      The GlobalVariable class -

      + -
      +

      #include "llvm/GlobalVariable.h" @@ -3796,15 +3843,15 @@ variables may have an initial value (which must be a Constant), and if they have an initializer, they may be marked as "constant" themselves (indicating that their contents never change at runtime).

      -
      -
      - Important Public Members of the - GlobalVariable class -
      +

      + + Important Public Members of the GlobalVariable class + +

      -
      +
      • GlobalVariable(const Type *Ty, bool @@ -3842,13 +3889,14 @@ never change at runtime).

      +
      -
      +

      The BasicBlock class -

      + -
      +

      #include "llvm/BasicBlock.h"
      @@ -3873,15 +3921,14 @@ href="#Value">Values, because they are referenced by instructions like branches and can go in the switch tables. BasicBlocks have type label.

      -
      - -
      - Important Public Members of the BasicBlock - class -
      +

      + + Important Public Members of the BasicBlock class + +

      -
      +
      • BasicBlock(const std::string &Name = "",
      +
      -
      +

      The Argument class -

      + -
      +

      This subclass of Value defines the interface for incoming formal arguments to a function. A Function maintains a list of its formal @@ -3947,6 +3995,8 @@ arguments. An argument has a pointer to the parent Function.

      +
      +
      @@ -3957,8 +4007,8 @@ arguments. An argument has a pointer to the parent Function.

      Dinakar Dhurjati and Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-17 03:19:22 +0100 (Thu, 17 Feb 2011) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
      diff --git a/docs/Projects.html b/docs/Projects.html index 76da086657c1..3c6d4ad78ba4 100644 --- a/docs/Projects.html +++ b/docs/Projects.html @@ -7,7 +7,7 @@ -
      Creating an LLVM Project
      +

      Creating an LLVM Project

      1. Overview
        2. @@ -30,10 +30,10 @@
      -
      Overview
      +

      Overview

      -
      +

      The LLVM build system is designed to facilitate the building of third party projects that use LLVM header files, libraries, and tools. In order to use @@ -73,12 +73,12 @@ provide enough information on how to write your own Makefiles.

      -
      +

      Create a Project from the Sample Project -

      + -
      +

      Follow these simple steps to start your project:

      @@ -145,12 +145,12 @@ project should build.

      -
      +

      Source Tree Layout -

      + -
      +

      In order to use the LLVM build system, you will want to organize your source code so that it can benefit from the build system's features. @@ -230,26 +230,24 @@ your tools directory.

      -
      +

      Writing LLVM Style Makefiles -

      + -
      +

      The LLVM build system provides a convenient way to build libraries and executables. Most of your project Makefiles will only need to define a few variables. Below is a list of the variables one can set and what they can do:

      -
      - -
      +

      Required Variables -

      + -
      +
      LEVEL @@ -263,11 +261,11 @@ do:

      -
      +

      Variables for Building Subdirectories -

      + -
      +
      DIRS @@ -294,11 +292,11 @@ do:

      -
      +

      Variables for Building Libraries -

      + -
      +
      LIBRARYNAME @@ -325,11 +323,11 @@ do:

      -
      +

      Variables for Building Programs -

      + -
      +
      TOOLNAME @@ -368,11 +366,11 @@ do:

      -
      +

      Miscellaneous Variables -

      + -
      +
      ExtraSource @@ -398,13 +396,15 @@ do:

      +
      + -
      +

      Placement of Object Code -

      + -
      +

      The final location of built libraries and executables will depend upon whether you do a Debug, Release, or Profile build.

      @@ -427,12 +427,12 @@ whether you do a Debug, Release, or Profile build.

      -
      +

      Further Help -

      + -
      +

      If you have any questions or need any help creating an LLVM project, the LLVM team would be more than happy to help. You can always post your @@ -451,9 +451,9 @@ Mailing List.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> John Criswell
      - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/ReleaseNotes.html b/docs/ReleaseNotes.html index 84298376a732..71bf16ea9167 100644 --- a/docs/ReleaseNotes.html +++ b/docs/ReleaseNotes.html @@ -3,13 +3,12 @@ - - LLVM 2.8 Release Notes + LLVM 2.9 Release Notes -
      LLVM 2.8 Release Notes
      +

      LLVM 2.9 Release Notes

      LLVM Dragon Logo @@ -17,35 +16,35 @@
      1. Introduction
      2. Sub-project Status Update
        3. -
      3. External Projects Using LLVM 2.8
        4. -
      4. What's New in LLVM 2.8?
        5. +
      5. External Projects Using LLVM 2.9
        6. +
      6. What's New in LLVM 2.9?
      7. Installation Instructions
      8. Known Problems
      9. Additional Information
      -

      Written by the LLVM Team

      +

      Written by the LLVM Team

      + --> -
      +

      Introduction -

      + -
      +

      This document contains the release notes for the LLVM Compiler -Infrastructure, release 2.8. Here we describe the status of LLVM, including +Infrastructure, release 2.9. Here we describe the status of LLVM, including major improvements from the previous release and significant known problems. All LLVM releases may be downloaded from the LLVM releases web site.

      @@ -62,51 +61,37 @@ current one. To see the release notes for a specific release, please see the releases page.

      - - - - - - - - -
      +

      Sub-project Status Update -

      + -
      +

      -The LLVM 2.8 distribution currently consists of code from the core LLVM +The LLVM 2.9 distribution currently consists of code from the core LLVM repository (which roughly includes the LLVM optimizers, code generators and supporting tools), the Clang repository and the llvm-gcc repository. In addition to this code, the LLVM Project includes other sub-projects that are in development. Here we include updates on these subprojects.

      -
      - - -
      +

      Clang: C/C++/Objective-C Frontend Toolkit -

      + -
      +

      Clang is an LLVM front end for the C, C++, and Objective-C languages. Clang aims to provide a better user experience @@ -115,112 +100,61 @@ standards, fast compilation, and low memory use. Like LLVM, Clang provides a modular, library-based architecture that makes it suitable for creating or integrating with other development tools. Clang is considered a production-quality compiler for C, Objective-C, C++ and Objective-C++ on x86 -(32- and 64-bit), and for darwin-arm targets.

      - -

      In the LLVM 2.8 time-frame, the Clang team has made many improvements:

      - -
        -
      • Clang C++ is now feature-complete with respect to the ISO C++ 1998 and 2003 standards.
        • -
      • Added support for Objective-C++.
        • -
      • Clang now uses LLVM-MC to directly generate object code and to parse inline assembly (on Darwin).
        • -
      • Introduced many new warnings, including -Wmissing-field-initializers, -Wshadow, -Wno-protocol, -Wtautological-compare, -Wstrict-selector-match, -Wcast-align, -Wunused improvements, and greatly improved format-string checking.
        • -
      • Introduced the "libclang" library, a C interface to Clang intended to support IDE clients.
        • -
      • Added support for #pragma GCC visibility, #pragma align, and others.
        • -
      • Added support for SSE, AVX, ARM NEON, and AltiVec.
        • -
      • Improved support for many Microsoft extensions.
        • -
      • Implemented support for blocks in C++.
        • -
      • Implemented precompiled headers for C++.
        • -
      • Improved abstract syntax trees to retain more accurate source information.
        • -
      • Added driver support for handling LLVM IR and bitcode files directly.
        • -
      • Major improvements to compiler correctness for exception handling.
        • -
      • Improved generated code quality in some areas: -
          -
        • Good code generation for X86-32 and X86-64 ABI handling.
          • -
        • Improved code generation for bit-fields, although important work remains.
          • -
        -
        • -
      -
      - - -
      -Clang Static Analyzer -
      - -
      - -

      The Clang Static Analyzer - project is an effort to use static source code analysis techniques to - automatically find bugs in C and Objective-C programs (and hopefully C++ in the - future!). The tool is very good at finding bugs that occur on specific - paths through code, such as on error conditions.

      - -

      The LLVM 2.8 release fixes a number of bugs and slightly improves precision - over 2.7, but there are no major new features in the release. +(32- and 64-bit), and for darwin/arm targets.

      + +

      In the LLVM 2.9 time-frame, the Clang team has made many improvements in C, +C++ and Objective-C support. C++ support is now generally rock solid, has +been exercised on a broad variety of code, and has several new C++'0x features +implemented (such as rvalue references and variadic templates). LLVM 2.9 has +also brought in a large range of bug fixes and minor features (e.g. __label__ +support), and is much more compatible with the Linux Kernel.

      + +

      If Clang rejects your code but another compiler accepts it, please take a +look at the language +compatibility guide to make sure this is not intentional or a known issue.

      -
      -DragonEgg: llvm-gcc ported to gcc-4.5 -
      - -
      -

      -DragonEgg is a port of llvm-gcc to -gcc-4.5. Unlike llvm-gcc, dragonegg in theory does not require any gcc-4.5 -modifications whatsoever (currently one small patch is needed) thanks to the -new gcc plugin architecture. -DragonEgg is a gcc plugin that makes gcc-4.5 use the LLVM optimizers and code -generators instead of gcc's, just like with llvm-gcc. -

      +

      +DragonEgg: GCC front-ends, LLVM back-end +

      +

      -DragonEgg is still a work in progress, but it is able to compile a lot of code, -for example all of gcc, LLVM and clang. Currently Ada, C, C++ and Fortran work -well, while all other languages either don't work at all or only work poorly. -For the moment only the x86-32 and x86-64 targets are supported, and only on -linux and darwin (darwin may need additional gcc patches). +DragonEgg is a +gcc plugin that replaces GCC's +optimizers and code generators with LLVM's. +Currently it requires a patched version of gcc-4.5. +The plugin can target the x86-32 and x86-64 processor families and has been +used successfully on the Darwin, FreeBSD and Linux platforms. +The Ada, C, C++ and Fortran languages work well. +The plugin is capable of compiling plenty of Obj-C, Obj-C++ and Java but it is +not known whether the compiled code actually works or not!

      -The 2.8 release has the following notable changes: +The 2.9 release has the following notable changes:

        -
      • The plugin loads faster due to exporting fewer symbols.
        • -
      • Additional vector operations such as addps256 are now supported.
        • -
      • Ada global variables with no initial value are no longer zero initialized, -resulting in better optimization.
        • -
      • The '-fplugin-arg-dragonegg-enable-gcc-optzns' flag now runs all gcc -optimizers, rather than just a handful.
        • -
      • Fortran programs using common variables now link correctly.
        • -
      • GNU OMP constructs no longer crash the compiler.
        • +
      • The plugin is much more stable when compiling Fortran.
        • +
      • Inline assembly where an asm output is tied to an input of a different size +is now supported in many more cases.
        • +
      • Basic support for the __float128 type was added. It is now possible to +generate LLVM IR from programs using __float128 but code generation does not +work yet.
        • +
      • Compiling Java programs no longer systematically crashes the plugin.
      -
      -VMKit: JVM/CLI Virtual Machine Implementation -
      - -
      -

      -The VMKit project is an implementation of -a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and -just-in-time compilation. As of LLVM 2.8, VMKit now supports copying garbage -collectors, and can be configured to use MMTk's copy mark-sweep garbage -collector. In LLVM 2.8, the VMKit .NET VM is no longer being maintained. -

      -
      - - -
      +

      compiler-rt: Compiler Runtime Library -

      + -
      +

      The new LLVM compiler-rt project is a simple library that provides an implementation of the low-level @@ -231,21 +165,22 @@ function. The compiler-rt library provides highly optimized implementations of this and other low-level routines (some are 3x faster than the equivalent libgcc routines).

      -

      -All of the code in the compiler-rt project is available under the standard LLVM -License, a "BSD-style" license. New in LLVM 2.8, compiler_rt now supports -soft floating point (for targets that don't have a real floating point unit), -and includes an extensive testsuite for the "blocks" language feature and the -blocks runtime included in compiler_rt.

      +

      In the LLVM 2.9 timeframe, compiler_rt has had several minor changes for + better ARM support, and a fairly major license change. All of the code in the + compiler-rt project is now dual + licensed under MIT and UIUC license, which allows you to use compiler-rt + in applications without the binary copyright reproduction clause. If you + prefer the LLVM/UIUC license, you are free to continue using it under that + license as well.

      -
      +

      LLDB: Low Level Debugger -

      + -
      +

      LLDB is a brand new member of the LLVM umbrella of projects. LLDB is a next generation, high-performance debugger. It @@ -254,20 +189,20 @@ libraries in the larger LLVM Project, such as the Clang expression parser, the LLVM disassembler and the LLVM JIT.

      -LLDB is in early development and not included as part of the LLVM 2.8 release, -but is mature enough to support basic debugging scenarios on Mac OS X in C, -Objective-C and C++. We'd really like help extending and expanding LLDB to -support new platforms, new languages, new architectures, and new features. -

      +LLDB is has advanced by leaps and bounds in the 2.9 timeframe. It is +dramatically more stable and useful, and includes both a new tutorial and a side-by-side comparison with +GDB.

      -
      +

      libc++: C++ Standard Library -

      + -
      +

      libc++ is another new member of the LLVM family. It is an implementation of the C++ standard library, written from the @@ -275,21 +210,56 @@ ground up to specifically target the forthcoming C++'0X standard and focus on delivering great performance.

      -As of the LLVM 2.8 release, libc++ is virtually feature complete, but would -benefit from more testing and better integration with Clang++. It is also -looking forward to the C++ committee finalizing the C++'0x standard. +In the LLVM 2.9 timeframe, libc++ has had numerous bugs fixed, and is now being +co-developed with Clang's C++'0x mode.

      + +

      +Like compiler_rt, libc++ is now dual + licensed under the MIT and UIUC license, allowing it to be used more + permissively.

      + +

      +LLBrowse: IR Browser +

      + +
      +

      + + LLBrowse is an interactive viewer for LLVM modules. It can load any LLVM + module and displays its contents as an expandable tree view, facilitating an + easy way to inspect types, functions, global variables, or metadata nodes. It + is fully cross-platform, being based on the popular wxWidgets GUI toolkit. +

      +
      -
      -KLEE: A Symbolic Execution Virtual Machine +

      +VMKit +

      + +
      +

      The VMKit project is an implementation + of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and + just-in-time compilation. As of LLVM 2.9, VMKit now supports generational + garbage collectors. The garbage collectors are provided by the MMTk framework, + and VMKit can be configured to use one of the numerous implemented collectors + of MMTk. +

      + + + +
      - -
      - External Open Source Projects Using LLVM 2.8 -
      +

      + External Open Source Projects Using LLVM 2.9 +

      -
      +

      An exciting aspect of LLVM is that it is used as an enabling technology for a lot of other language and tools projects. This section lists some of the - projects that have already been updated to work with LLVM 2.8.

      -
      + projects that have already been updated to work with LLVM 2.9.

      -
      -TTA-based Codesign Environment (TCE) -
      +

      Crack Programming Language

      -
      +

      -TCE is a toolset for designing -application-specific processors (ASP) based on the Transport triggered -architecture (TTA). The toolset provides a complete co-design flow from C/C++ -programs down to synthesizable VHDL and parallel program binaries. Processor -customization points include the register files, function units, supported -operations, and the interconnection network.

      - -

      TCE uses llvm-gcc/Clang and LLVM for C/C++ language support, target -independent optimizations and also for parts of code generation. It generates -new LLVM-based code generators "on the fly" for the designed TTA processors and -loads them in to the compiler backend as runtime libraries to avoid per-target -recompilation of larger parts of the compiler chain.

      - +Crack aims to provide the +ease of development of a scripting language with the performance of a compiled +language. The language derives concepts from C++, Java and Python, incorporating +object-oriented programming, operator overloading and strong typing.

      - + + -
      -Horizon Bytecode Compiler +

      TTA-based Codesign Environment (TCE)

      + +
      +

      TCE is a toolset for designing application-specific processors (ASP) based on +the Transport triggered architecture (TTA). The toolset provides a complete +co-design flow from C/C++ programs down to synthesizable VHDL and parallel +program binaries. Processor customization points include the register files, +function units, supported operations, and the interconnection network.

      + +

      TCE uses Clang and LLVM for C/C++ language support, target independent +optimizations and also for parts of code generation. It generates new LLVM-based +code generators "on the fly" for the designed TTA processors and loads them in +to the compiler backend as runtime libraries to avoid per-target recompilation +of larger parts of the compiler chain.

      -
      -

      -Horizon is a bytecode -language and compiler written on top of LLVM, intended for producing -single-address-space managed code operating systems that -run faster than the equivalent multiple-address-space C systems. -More in-depth blurb is available on the wiki.

      - -
      + -
      -Clam AntiVirus +

      PinaVM

      + +
      +

      PinaVM is an open +source, SystemC front-end. Unlike many +other front-ends, PinaVM actually executes the elaboration of the +program analyzed using LLVM's JIT infrastructure. It later enriches the +bitcode with SystemC-specific information.

      -
      -

      -Clam AntiVirus is an open source (GPL) -anti-virus toolkit for UNIX, designed especially for e-mail scanning on mail -gateways. Since version 0.96 it has bytecode -signatures that allow writing detections for complex malware. It -uses LLVM's JIT to speed up the execution of bytecode on -X86, X86-64, PPC32/64, falling back to its own interpreter otherwise. -The git version was updated to work with LLVM 2.8. -

      - -

      The -ClamAV bytecode compiler uses Clang and LLVM to compile a C-like -language, insert runtime checks, and generate ClamAV bytecode.

      - + +

      Pure

      + +
      +

      Pure is an + algebraic/functional + programming language based on term rewriting. Programs are collections + of equations which are used to evaluate expressions in a symbolic + fashion. The interpreter uses LLVM as a backend to JIT-compile Pure + programs to fast native code. Pure offers dynamic typing, eager and lazy + evaluation, lexical closures, a hygienic macro system (also based on + term rewriting), built-in list and matrix support (including list and + matrix comprehensions) and an easy-to-use interface to C and other + programming languages (including the ability to load LLVM bitcode + modules, and inline C, C++, Fortran and Faust code in Pure programs if + the corresponding LLVM-enabled compilers are installed).

      + +

      Pure version 0.47 has been tested and is known to work with LLVM 2.9 + (and continues to work with older LLVM releases >= 2.5).

      -
      -Pure -
      +

      IcedTea Java Virtual Machine Implementation

      -
      +

      -Pure -is an algebraic/functional -programming language based on term rewriting. Programs are collections -of equations which are used to evaluate expressions in a symbolic -fashion. Pure offers dynamic typing, eager and lazy evaluation, lexical -closures, a hygienic macro system (also based on term rewriting), -built-in list and matrix support (including list and matrix -comprehensions) and an easy-to-use C interface. The interpreter uses -LLVM as a backend to JIT-compile Pure programs to fast native code.

      - -

      Pure versions 0.44 and later have been tested and are known to work with -LLVM 2.8 (and continue to work with older LLVM releases >= 2.5).

      +IcedTea provides a +harness to build OpenJDK using only free software build tools and to provide +replacements for the not-yet free parts of OpenJDK. One of the extensions that +IcedTea provides is a new JIT compiler named Shark which uses LLVM +to provide native code generation without introducing processor-dependent +code. +

      +

      OpenJDK 7 b112, IcedTea6 1.9 and IcedTea7 1.13 and later have been tested +and are known to work with LLVM 2.9 (and continue to work with older LLVM +releases >= 2.6 as well).

      -
      -Glasgow Haskell Compiler (GHC) -
      - -
      -

      -GHC is an open source, -state-of-the-art programming suite for -Haskell, a standard lazy functional programming language. It includes -an optimizing static compiler generating good code for a variety of +

      Glasgow Haskell Compiler (GHC)

      + +
      +

      GHC is an open source, state-of-the-art programming suite for Haskell, +a standard lazy functional programming language. It includes an +optimizing static compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development.

      In addition to the existing C and native code generators, GHC 7.0 now -supports an LLVM -code generator. GHC supports LLVM 2.7 and later.

      - +supports an LLVM code generator. GHC supports LLVM 2.7 and later.

      -
      -Clay Programming Language -
      - -
      -

      -Clay is a new systems programming -language that is specifically designed for generic programming. It makes -generic programming very concise thanks to whole program type propagation. It -uses LLVM as its backend.

      - +

      Polly - Polyhedral optimizations for LLVM

      + +
      +

      Polly is a project that aims to provide advanced memory access optimizations +to better take advantage of SIMD units, cache hierarchies, multiple cores or +even vector accelerators for LLVM. Built around an abstract mathematical +description based on Z-polyhedra, it provides the infrastructure to develop +advanced optimizations in LLVM and to connect complex external optimizers. In +its first year of existence Polly already provides an exact value-based +dependency analysis as well as basic SIMD and OpenMP code generation support. +Furthermore, Polly can use PoCC(Pluto) an advanced optimizer for data-locality +and parallelism.

      -
      -llvm-py Python Bindings for LLVM -
      - -
      -

      -llvm-py has been updated to work -with LLVM 2.8. llvm-py provides Python bindings for LLVM, allowing you to write a -compiler backend or a VM in Python.

      +

      Rubinius

      +
      +

      Rubinius is an environment + for running Ruby code which strives to write as much of the implementation in + Ruby as possible. Combined with a bytecode interpreting VM, it uses LLVM to + optimize and compile ruby code down to machine code. Techniques such as type + feedback, method inlining, and deoptimization are all used to remove dynamism + from ruby execution and increase performance.

      -
      +

      FAUST Real-Time Audio Signal Processing Language -

      + -
      +

      FAUST is a compiled language for real-time audio signal processing. The name FAUST stands for Functional AUdio STream. Its programming model combines two approaches: functional programming and block diagram composition. In addition with the C, C++, JAVA output formats, the -Faust compiler can now generate LLVM bitcode, and works with LLVM 2.7 and -2.8.

      - -
      +Faust compiler can now generate LLVM bitcode, and works with LLVM 2.7-2.9.

      - -
      -Jade Just-in-time Adaptive Decoder Engine
      - -
      -

      Jade -(Just-in-time Adaptive Decoder Engine) is a generic video decoder engine using -LLVM for just-in-time compilation of video decoder configurations. Those -configurations are designed by MPEG Reconfigurable Video Coding (RVC) committee. -MPEG RVC standard is built on a stream-based dataflow representation of -decoders. It is composed of a standard library of coding tools written in -RVC-CAL language and a dataflow configuration — block diagram — -of a decoder.

      - -

      Jade project is hosted as part of the Open -RVC-CAL Compiler and requires it to translate the RVC-CAL standard library -of video coding tools into an LLVM assembly code.

      - -
      - - -
      -LLVM JIT for Neko VM -
      - -
      -

      Neko LLVM JIT -replaces the standard Neko JIT with an LLVM-based implementation. While not -fully complete, it is already providing a 1.5x speedup on 64-bit systems. -Neko LLVM JIT requires LLVM 2.8 or later.

      - -
      - - -
      -Crack Scripting Language -
      - -
      -

      -Crack aims to provide -the ease of development of a scripting language with the performance of a -compiled language. The language derives concepts from C++, Java and Python, -incorporating object-oriented programming, operator overloading and strong -typing. Crack 0.2 works with LLVM 2.7, and the forthcoming Crack 0.2.1 release -builds on LLVM 2.8.

      - -
      - - -
      -Dresden TM Compiler (DTMC) -
      - -
      -

      -DTMC provides support for -Transactional Memory, which is an easy-to-use and efficient way to synchronize -accesses to shared memory. Transactions can contain normal C/C++ code (e.g., -__transaction { list.remove(x); x.refCount--; }) and will be executed -virtually atomically and isolated from other transactions.

      - -
      - - -
      -Kai Programming Language -
      - -
      -

      -Kai (Japanese 会 for -meeting/gathering) is an experimental interpreter that provides a highly -extensible runtime environment and explicit control over the compilation -process. Programs are defined using nested symbolic expressions, which are all -parsed into first-class values with minimal intrinsic semantics. Kai can -generate optimised code at run-time (using LLVM) in order to exploit the nature -of the underlying hardware and to integrate with external software libraries. -It is a unique exploration into world of dynamic code compilation, and the -interaction between high level and low level semantics.

      - -
      - - -
      -OSL: Open Shading Language -
      - -
      -

      -OSL is a shading -language designed for use in physically based renderers and in particular -production rendering. By using LLVM instead of the interpreter, it was able to -meet its performance goals (>= C-code) while retaining the benefits of -runtime specialization and a portable high-level language. -

      - +
      - - -
      - What's New in LLVM 2.8? -
      +

      + What's New in LLVM 2.9? +

      -
      +

      This release includes a huge number of bug fixes, performance tweaks and minor improvements. Some of the major improvements and new features are listed in this section.

      -
      - -
      +

      Major New Features -

      + -
      +
      -

      LLVM 2.8 includes several major new capabilities:

      +

      LLVM 2.9 includes several major new capabilities:

        -
      • As mentioned above, libc++ and LLDB are major new additions to the LLVM collective.
        • -
      • LLVM 2.8 now has pretty decent support for debugging optimized code. You - should be able to reliably get debug info for function arguments, assuming - that the value is actually available where you have stopped.
        • -
      • A new 'llvm-diff' tool is available that does a semantic diff of .ll - files.
        • -
      • The MC subproject has made major progress in this release. - Direct .o file writing support for darwin/x86[-64] is now reliable and - support for other targets and object file formats are in progress.
        • -
      + +
    8. Type Based Alias Analysis (TBAA) is now implemented and turned on by default + in Clang. This allows substantially better load/store optimization in some + cases. TBAA can be disabled by passing -fno-strict-aliasing. +
      9. + +
    9. This release has seen a continued focus on quality of debug information. + LLVM now generates much higher fidelity debug information, particularly when + debugging optimized code.
      10. + +
    10. Inline assembly now supports multiple alternative constraints.
      11. +
    11. A new backend for the NVIDIA PTX virtual ISA (used to target its GPUs) is + under rapid development. It is not generally useful in 2.9, but is making + rapid progress.
      12. + + +
      -
      +

      LLVM IR and Core Improvements -

      + -
      +

      LLVM IR has several new features for better support of new targets and that expose new optimization opportunities:

        -
      • The memcpy, memmove, and memset - intrinsics now take address space qualified pointers and a bit to indicate - whether the transfer is "volatile" or not. -
        • -
      • Per-instruction debug info metadata is much faster and uses less memory by - using the new DebugLoc class.
        • -
      • LLVM IR now has a more formalized concept of "trap values", which allow the optimizer - to optimize more aggressively in the presence of undefined behavior, while - still producing predictable results.
        • -
      • LLVM IR now supports two new linkage - types (linker_private_weak and linker_private_weak_def_auto) which map - onto some obscure MachO concepts.
        • +
      • The udiv, ashr, lshr, and shl + instructions now have support exact and nuw/nsw bits to indicate that they + don't overflow or shift out bits. This is useful for optimization of pointer differences and other cases.
        • + +
      • LLVM IR now supports the unnamed_addr + attribute to indicate that constant global variables with identical + initializers can be merged. This fixed an + issue where LLVM would incorrectly merge two globals which were supposed + to have distinct addresses.
        • + +
      • The new hotpatch attribute has been added + to allow runtime patching of functions.
      -
      +

      Optimizer Improvements -

      + -
      +

      In addition to a large array of minor performance tweaks and bug fixes, this release includes a few major enhancements and additions to the optimizers:

        -
      • As mentioned above, the optimizer now has support for updating debug - information as it goes. A key aspect of this is the new llvm.dbg.value - intrinsic. This intrinsic represents debug info for variables that are - promoted to SSA values (typically by mem2reg or the -scalarrepl passes).
        • - -
      • The JumpThreading pass is now much more aggressive about implied value - relations, allowing it to thread conditions like "a == 4" when a is known to - be 13 in one of the predecessors of a block. It does this in conjunction - with the new LazyValueInfo analysis pass.
        • -
      • The new RegionInfo analysis pass identifies single-entry single-exit regions - in the CFG. You can play with it with the "opt -regions -analyze" or - "opt -view-regions" commands.
        • -
      • The loop optimizer has significantly improved strength reduction and analysis - capabilities. Notably it is able to build on the trap value and signed - integer overflow information to optimize <= and >= loops.
        • -
      • The CallGraphSCCPassManager now has some basic support for iterating within - an SCC when a optimizer devirtualizes a function call. This allows inlining - through indirect call sites that are devirtualized by store-load forwarding - and other optimizations.
        • -
      • The new -loweratomic pass is available - to lower atomic instructions into their non-atomic form. This can be useful - to optimize generic code that expects to run in a single-threaded - environment.
        • -
      +
    12. Link Time Optimization (LTO) has been improved to use MC for parsing inline + assembly and now can build large programs like Firefox 4 on both Mac OS X and + Linux.
      13. + +
    13. The new -loop-idiom pass recognizes memset/memcpy loops (and memset_pattern + on darwin), turning them into library calls, which are typically better + optimized than inline code. If you are building a libc and notice that your + memcpy and memset functions are compiled into infinite recursion, please build + with -ffreestanding or -fno-builtin to disable this pass.
      14. + +
    14. A new -early-cse pass does a fast pass over functions to fold constants, + simplify expressions, perform simple dead store elimination, and perform + common subexpression elimination. It does a good job at catching some of the + trivial redundancies that exist in unoptimized code, making later passes more + effective.
      15. + +
    15. A new -loop-instsimplify pass is used to clean up loop bodies in the loop + optimizer.
      16. + +
    16. The new TargetLibraryInfo interface allows mid-level optimizations to know + whether the current target's runtime library has certain functions. For + example, the optimizer can now transform integer-only printf calls to call + iprintf, allowing reduced code size for embedded C libraries (e.g. newlib). +
      17. + +
    17. LLVM has a new RegionPass + infrastructure for region-based optimizations.
      18. + +
    18. Several optimizer passes have been substantially sped up: + GVN is much faster on functions with deep dominator trees and lots of basic + blocks. The dominator tree and dominance frontier passes are much faster to + compute, and preserved by more passes (so they are computed less often). The + -scalar-repl pass is also much faster and doesn't use DominanceFrontier. +
      19. - +
    19. The Dead Store Elimination pass is more aggressive optimizing stores of + different types: e.g. a large store following a small one to the same address. + The MemCpyOptimizer pass handles several new forms of memcpy elimination.
      20. + +
    20. LLVM now optimizes various idioms for overflow detection into check of the + flag register on various CPUs. For example, we now compile: + + 
      +   unsigned long t = a+b;
+   if (t < a) ...
+
      + into: + 
      +   addq %rdi, %rbx
+   jno  LBB0_2
+
      +
      21. + +
      -
      +

      MC Level Improvements -

      + -
      +

      The LLVM Machine Code (aka MC) subsystem was created to solve a number of problems in the realm of assembly, disassembly, object file format handling, and a number of other related areas that CPU instruction-set level tools work in.

      -

      The MC subproject has made great leaps in LLVM 2.8. For example, support for - directly writing .o files from LLC (and clang) now works reliably for - darwin/x86[-64] (including inline assembly support) and the integrated - assembler is turned on by default in Clang for these targets. This provides - improved compile times among other things.

      -
        -
      • The entire compiler has converted over to using the MCStreamer assembler API - instead of writing out a .s file textually.
        • -
      • The "assembler parser" is far more mature than in 2.7, supporting a full - complement of directives, now supports assembler macros, etc.
        • -
      • The "assembler backend" has been completed, including support for relaxation - relocation processing and all the other things that an assembler does.
        • -
      • The MachO file format support is now fully functional and works.
        • -
      • The MC disassembler now fully supports ARM and Thumb. ARM assembler support - is still in early development though.
        • -
      • The X86 MC assembler now supports the X86 AES and AVX instruction set.
        • -
      • Work on ELF and COFF object files and ARM target support is well underway, - but isn't useful yet in LLVM 2.8. Please contact the llvmdev mailing list - if you're interested in this.
        • +
      • ELF MC support has matured enough for the integrated assembler to be turned + on by default in Clang on X86-32 and X86-64 ELF systems.
        • + +
      • MC supports and CodeGen uses the .file and .loc directives + for producing line number debug info. This produces more compact line + tables and easier to read .s files.
        • + +
      • MC supports the .cfi_* directives for producing DWARF + frame information, but it is still not used by CodeGen by default.
        • + + +
      • The MC assembler now generates much better diagnostics for common errors, + is much faster at matching instructions, is much more bug-compatible with + the GAS assembler, and is now generally useful for a broad range of X86 + assembly.
        • + +
      • We now have some basic internals + documentation for MC.
        • + +
      • .td files can now specify assembler aliases directly with the MnemonicAlias and InstAlias + tblgen classes.
        • + +
      • LLVM now has an experimental format-independent object file manipulation + library (lib/Object). It supports both PE/COFF and ELF. The llvm-nm tool has + been extended to work with native object files, and the new llvm-objdump tool + supports disassembly of object files (but no relocations are displayed yet). +
        • + +
      • Win32 PE-COFF support in the MC assembler has made a lot of progress in the + 2.9 timeframe, but is still not generally useful.
        • +

      For more information, please see the Intro to the LLVM MC Project Blog Post.

      -
      - +
      -
      +

      Target Independent Code Generator Improvements -

      + -
      +

      We have put a significant amount of work into the code generator infrastructure, which allows us to implement more aggressive algorithms and make it run faster:

        -
      • The clang/gcc -momit-leaf-frame-pointer argument is now supported.
        • -
      • The clang/gcc -ffunction-sections and -fdata-sections arguments are now - supported on ELF targets (like GCC).
        • -
      • The MachineCSE pass is now tuned and on by default. It eliminates common - subexpressions that are exposed when lowering to machine instructions.
        • -
      • The "local" register allocator was replaced by a new "fast" register - allocator. This new allocator (which is often used at -O0) is substantially - faster and produces better code than the old local register allocator.
        • -
      • A new LLC "-regalloc=default" option is available, which automatically - chooses a register allocator based on the -O optimization level.
        • -
      • The common code generator code was modified to promote illegal argument and - return value vectors to wider ones when possible instead of scalarizing - them. For example, <3 x float> will now pass in one SSE register - instead of 3 on X86. This generates substantially better code since the - rest of the code generator was already expecting this.
        • -
      • The code generator uses a new "COPY" machine instruction. This speeds up - the code generator and eliminates the need for targets to implement the - isMoveInstr hook. Also, the copyRegToReg hook was renamed to copyPhysReg - and simplified.
        • -
      • The code generator now has a "LocalStackSlotPass", which optimizes stack - slot access for targets (like ARM) that have limited stack displacement - addressing.
        • -
      • A new "PeepholeOptimizer" is available, which eliminates sign and zero - extends, and optimizes away compare instructions when the condition result - is available from a previous instruction.
        • -
      • Atomic operations now get legalized into simpler atomic operations if not - natively supported, easing the implementation burden on targets.
        • -
      • We have added two new bottom-up pre-allocation register pressure aware schedulers: -
          -
        1. The hybrid scheduler schedules aggressively to minimize schedule length when registers are available and avoid overscheduling in high pressure situations.
          2. -
        2. The instruction-level-parallelism scheduler schedules for maximum ILP when registers are available and avoid overscheduling in high pressure situations.
          3. -
        • -
      • The tblgen type inference algorithm was rewritten to be more consistent and - diagnose more target bugs. If you have an out-of-tree backend, you may - find that it finds bugs in your target description. This support also - allows limited support for writing patterns for instructions that return - multiple results (e.g. a virtual register and a flag result). The - 'parallel' modifier in tblgen was removed, you should use the new support - for multiple results instead.
        • -
      • A new (experimental) "-rendermf" pass is available which renders a - MachineFunction into HTML, showing live ranges and other useful - details.
        • -
      • The new SubRegIndex tablegen class allows subregisters to be indexed - symbolically instead of numerically. If your target uses subregisters you - will need to adapt to use SubRegIndex when you upgrade to 2.8.
        • - - -
      • The -fast-isel instruction selection path (used at -O0 on X86) was rewritten - to work bottom-up on basic blocks instead of top down. This makes it - slightly faster (because the MachineDCE pass is not needed any longer) and - allows it to generate better code in some cases.
        • +
      • The pre-register-allocation (preRA) instruction scheduler models register + pressure much more accurately in some cases. This allows the adoption of more + aggressive scheduling heuristics without causing spills to be generated. +
        • + +
      • LiveDebugVariables is a new pass that keeps track of debugging information + for user variables that are promoted to registers in optimized builds.
        • + +
      • The scheduler now models operand latency and pipeline forwarding.
        • +
      • A major register allocator infrastructure rewrite is underway. It is not on + by default for 2.9 and you are not advised to use it, but it has made + substantial progress in the 2.9 timeframe: +
          +
        • A new -regalloc=basic "basic" register allocator can be used as a simple + fallback when debugging. It uses the new infrastructure.
          • +
        • New infrastructure is in place for live range splitting. "SplitKit" can + break a live interval into smaller pieces while preserving SSA form, and + SpillPlacement can help find the best split points. This is a work in + progress so the API is changing quickly.
          • +
        • The inline spiller has learned to clean up after live range splitting. It + can hoist spills out of loops, and it can eliminate redundant spills.
          • +
        • Rematerialization works with live range splitting.
          • +
        • The new "greedy" register allocator using live range splitting. This will + be the default register allocator in the next LLVM release, but it is not + turned on by default in 2.9.
          • +
        +
      -
      +

      X86-32 and X86-64 Target Improvements -

      + -
      +

      New features and major changes in the X86 target include:

        -
      • The X86 backend now supports holding X87 floating point stack values - in registers across basic blocks, dramatically improving performance of code - that uses long double, and when targeting CPUs that don't support SSE.
        • - -
      • The X86 backend now uses a SSEDomainFix pass to optimize SSE operations. On - Nehalem ("Core i7") and newer CPUs there is a 2 cycle latency penalty on - using a register in a different domain than where it was defined. This pass - optimizes away these stalls.
        • - -
      • The X86 backend now promotes 16-bit integer operations to 32-bits when - possible. This avoids 0x66 prefixes, which are slow on some - microarchitectures and bloat the code on all of them.
        • - -
      • The X86 backend now supports the Microsoft "thiscall" calling convention, - and a calling convention to support - ghc.
        • - -
      • The X86 backend supports a new "llvm.x86.int" intrinsic, which maps onto - the X86 "int $42" and "int3" instructions.
        • - -
      • At the IR level, the <2 x float> datatype is now promoted and passed - around as a <4 x float> instead of being passed and returned as an MMX - vector. If you have a frontend that uses this, please pass and return a - <2 x i32> instead (using bitcasts).
        • - -
      • When printing .s files in verbose assembly mode (the default for clang -S), - the X86 backend now decodes X86 shuffle instructions and prints human - readable comments after the most inscrutable of them, e.g.: - -
        -  insertps $113, %xmm3, %xmm0 # xmm0 = zero,xmm0[1,2],xmm3[1]
-  unpcklps %xmm1, %xmm0       # xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
-  pshufd   $1, %xmm1, %xmm1   # xmm1 = xmm1[1,0,0,0]
-
        +
      • LLVM 2.9 includes a complete reimplementation of the MMX instruction set. + The reimplementation uses a new LLVM IR x86_mmx type to ensure that MMX operations + are only generated from source that uses MMX builtin operations. With + this, random types like <2 x i32> are not turned into MMX operations + (which can be catastrophic without proper "emms" insertion). Because the X86 + code generator always generates reliable code, the -disable-mmx flag is now + removed. +
        • + +
      • X86 support for FS/GS relative loads and stores using address space 256/257 works reliably + now.
        • + +
      • LLVM 2.9 generates much better code in several cases by using adc/sbb to + avoid generation of conditional move instructions for conditional increment + and other idioms.
        • + +
      • The X86 backend has adopted a new preRA scheduling mode, "list-ilp", to + shorten the height of instruction schedules without inducing register spills.
        • - + +
      • The MC assembler supports 3dNow! and 3DNowA instructions.
        • + +
      • Several bugs have been fixed for Windows x64 code generator.
      -
      +

      ARM Target Improvements -

      + -
      +

      New features of the ARM target include:

        -
      • The ARM backend now optimizes tail calls into jumps.
        • -
      • Scheduling is improved through the new list-hybrid scheduler as well - as through better modeling of structural hazards.
        • -
      • Half float instructions are now - supported.
        • -
      • NEON support has been improved to model instructions which operate onto - multiple consecutive registers more aggressively. This avoids lots of - extraneous register copies.
        • -
      • The ARM backend now uses a new "ARMGlobalMerge" pass, which merges several - global variables into one, saving extra address computation (all the global - variables can be accessed via same base address) and potentially reducing - register pressure.
        • - -
      • The ARM backend has received many minor improvements and tweaks which lead - to substantially better performance in a wide range of different scenarios. -
        • +
      • The ARM backend now has a fast instruction selector, which dramatically + improves -O0 compile times.
        • +
      • The ARM backend has new tuning for Cortex-A8 and Cortex-A9 CPUs.
        • +
      • The __builtin_prefetch builtin (and llvm.prefetch intrinsic) is compiled + into prefetch instructions instead of being discarded.
        • -
      • The ARM NEON intrinsics have been substantially reworked to reduce - redundancy and improve code generation. Some of the major changes are: -
          -
        1. - All of the NEON load and store intrinsics (llvm.arm.neon.vld* and - llvm.arm.neon.vst*) take an extra parameter to specify the alignment in bytes - of the memory being accessed. -
          2. -
        2. - The llvm.arm.neon.vaba intrinsic (vector absolute difference and - accumulate) has been removed. This operation is now represented using - the llvm.arm.neon.vabd intrinsic (vector absolute difference) followed by a - vector add. -
          3. -
        3. - The llvm.arm.neon.vabdl and llvm.arm.neon.vabal intrinsics (lengthening - vector absolute difference with and without accumulation) have been removed. - They are represented using the llvm.arm.neon.vabd intrinsic (vector absolute - difference) followed by a vector zero-extend operation, and for vabal, - a vector add. -
          4. -
        4. - The llvm.arm.neon.vmovn intrinsic has been removed. Calls of this intrinsic - are now replaced by vector truncate operations. -
          5. -
        5. - The llvm.arm.neon.vmovls and llvm.arm.neon.vmovlu intrinsics have been - removed. They are now represented as vector sign-extend (vmovls) and - zero-extend (vmovlu) operations. -
          6. -
        6. - The llvm.arm.neon.vaddl*, llvm.arm.neon.vaddw*, llvm.arm.neon.vsubl*, and - llvm.arm.neon.vsubw* intrinsics (lengthening vector add and subtract) have - been removed. They are replaced by vector add and vector subtract operations - where one (vaddw, vsubw) or both (vaddl, vsubl) of the operands are either - sign-extended or zero-extended. -
          7. -
        7. - The llvm.arm.neon.vmulls, llvm.arm.neon.vmullu, llvm.arm.neon.vmlal*, and - llvm.arm.neon.vmlsl* intrinsics (lengthening vector multiply with and without - accumulation and subtraction) have been removed. These operations are now - represented as vector multiplications where the operands are either - sign-extended or zero-extended, followed by a vector add for vmlal or a - vector subtract for vmlsl. Note that the polynomial vector multiply - intrinsic, llvm.arm.neon.vmullp, remains unchanged. -
          8. -
        -
        • +
      • The ARM backend preRA scheduler now models machine resources at cycle + granularity. This allows the scheduler to both accurately model + instruction latency and avoid overcommitting functional units.
        • +
      • Countless ARM microoptimizations have landed in LLVM 2.9.
      + + +

      +Other Target Specific Improvements +

      + +
      +
        +
      • MicroBlaze: major updates for aggressive delay slot filler, MC-based + assembly printing, assembly instruction parsing, ELF .o file emission, and MC + instruction disassembler have landed.
        • +
      • SPARC: Many improvements, including using the Y registers for + multiplications and addition of a simple delay slot filler.
        • + +
      • PowerPC: The backend has been largely MC'ized and is ready to support + directly writing out mach-o object files. No one seems interested in finishing + this final step though.
        • + +
      • Mips: Improved o32 ABI support, including better varags handling. +More instructions supported in codegen: madd, msub, rotr, rotrv and clo. +It also now supports lowering block addresses.
        • + +
      +
      -
      +

      Major Changes and Removed Features -

      + -
      +

      If you're already an LLVM user or developer with out-of-tree changes based -on LLVM 2.7, this section lists some "gotchas" that you may run into upgrading +on LLVM 2.8, this section lists some "gotchas" that you may run into upgrading from the previous release.

        -
      • The build configuration machinery changed the output directory names. It - wasn't clear to many people that a "Release-Asserts" build was a release build - without asserts. To make this more clear, "Release" does not include - assertions and "Release+Asserts" does (likewise, "Debug" and - "Debug+Asserts").
        • -
      • The MSIL Backend was removed, it was unsupported and broken.
        • -
      • The ABCD, SSI, and SCCVN passes were removed. These were not fully - functional and their behavior has been or will be subsumed by the - LazyValueInfo pass.
        • -
      • The LLVM IR 'Union' feature was removed. While this is a desirable feature - for LLVM IR to support, the existing implementation was half baked and - barely useful. We'd really like anyone interested to resurrect the work and - finish it for a future release.
        • -
      • If you're used to reading .ll files, you'll probably notice that .ll file - dumps don't produce #uses comments anymore. To get them, run a .bc file - through "llvm-dis --show-annotations".
        • -
      • Target triples are now stored in a normalized form, and all inputs from - humans are expected to be normalized by Triple::normalize before being - stored in a module triple or passed to another library.
        • -
      +
    21. This is the last release to support the llvm-gcc frontend.
      22. +
    22. LLVM has a new naming + convention standard, though the codebase hasn't fully adopted it yet.
      23. + +
    23. The new DIBuilder class provides a simpler interface for front ends to + encode debug info in LLVM IR, and has replaced DIFactory.
      24. +
    24. LLVM IR and other tools always work on normalized target triples (which have + been run through Triple::normalize).
      25. -

      In addition, many APIs have changed in this release. Some of the major LLVM -API changes are:

      -
        -
      • LLVM 2.8 changes the internal order of operands in InvokeInst - and CallInst. - To be portable across releases, please use the CallSite class and the - high-level accessors, such as getCalledValue and - setUnwindDest. -
        • -
      • - You can no longer pass use_iterators directly to cast<> (and similar), - because these routines tend to perform costly dereference operations more - than once. You have to dereference the iterators yourself and pass them in. -
        • -
      • - llvm.memcpy.*, llvm.memset.*, llvm.memmove.* intrinsics take an extra - parameter now ("i1 isVolatile"), totaling 5 parameters, and the pointer - operands are now address-space qualified. - If you were creating these intrinsic calls and prototypes yourself (as opposed - to using Intrinsic::getDeclaration), you can use - UpgradeIntrinsicFunction/UpgradeIntrinsicCall to be portable across releases. -
        • -
      • - SetCurrentDebugLocation takes a DebugLoc now instead of a MDNode. - Change your code to use - SetCurrentDebugLocation(DebugLoc::getFromDILocation(...)). -
        • -
      • - The RegisterPass and RegisterAnalysisGroup templates are - considered deprecated, but continue to function in LLVM 2.8. Clients are - strongly advised to use the upcoming INITIALIZE_PASS() and - INITIALIZE_AG_PASS() macros instead. -
        • -
      • - The constructor for the Triple class no longer tries to understand odd triple - specifications. Frontends should ensure that they only pass valid triples to - LLVM. The Triple::normalize utility method has been added to help front-ends - deal with funky triples. -
        • -
      • - The signature of the GCMetadataPrinter::finishAssembly virtual - function changed: the raw_ostream and MCAsmInfo arguments - were dropped. GC plugins which compute stack maps must be updated to avoid - having the old definition overload the new signature. -
        • -
      • - The signature of MemoryBuffer::getMemBuffer changed. Unfortunately - calls intended for the old version still compile, but will not work correctly, - leading to a confusing error about an invalid header in the bitcode. -
        • - -
      • - Some APIs were renamed: -
          -
        • llvm_report_error -> report_fatal_error
          • -
        • llvm_install_error_handler -> install_fatal_error_handler
          • -
        • llvm::DwarfExceptionHandling -> llvm::JITExceptionHandling
          • -
        • VISIBILITY_HIDDEN -> LLVM_LIBRARY_VISIBILITY
          • -
        -
        • +
      • The target triple x86_64--mingw64 is obsoleted. Use x86_64--mingw32 + instead.
        • -
      • - Some public headers were renamed: -
          -
        • llvm/Assembly/AsmAnnotationWriter.h was renamed - to llvm/Assembly/AssemblyAnnotationWriter.h -
          • -
        +
      • The PointerTracking pass has been removed from mainline, and moved to The + ClamAV project (its only client).
        • + +
      • The LoopIndexSplit, LiveValues, SimplifyHalfPowrLibCalls, GEPSplitter, and + PartialSpecialization passes were removed. They were unmaintained, + buggy, or deemed to be a bad idea.
      -
      -Development Infrastructure Changes -
      +

      +Internal API Changes +

      -
      +
      -

      This section lists changes to the LLVM development infrastructure. This -mostly impacts users who actively work on LLVM or follow development on -mainline, but may also impact users who leverage the LLVM build infrastructure -or are interested in LLVM qualification.

      +

      In addition, many APIs have changed in this release. Some of the major + LLVM API changes are:

        -
      • The default for make check is now to use - the lit testing tool, which is - part of LLVM itself. You can use lit directly as well, or use - the llvm-lit tool which is created as part of a Makefile or CMake - build (and knows how to find the appropriate tools). See the lit - documentation and the blog - post, and PR5217 - for more information.
        • - -
      • The LLVM test-suite infrastructure has a new "simple" test format - (make TEST=simple). The new format is intended to require only a - compiler and not a full set of LLVM tools. This makes it useful for testing - released compilers, for running the test suite with other compilers (for - performance comparisons), and makes sure that we are testing the compiler as - users would see it. The new format is also designed to work using reference - outputs instead of comparison to a baseline compiler, which makes it run much - faster and makes it less system dependent.
        • - -
      • Significant progress has been made on a new interface to running the - LLVM test-suite (aka the LLVM "nightly tests") using - the LNT infrastructure. The LNT - interface to the test-suite brings significantly improved reporting - capabilities for monitoring the correctness and generated code quality - produced by LLVM over time.
        • +
      • include/llvm/System merged into include/llvm/Support.
        • +
      • The llvm::APInt API was significantly + cleaned up.
        • + +
      • In the code generator, MVT::Flag was renamed to MVT::Glue to more accurately + describe its behavior.
        • + +
      • The system_error header from C++0x was added, and is now pervasively used to + capture and handle i/o and other errors in LLVM.
        • + +
      • The old sys::Path API has been deprecated in favor of the new PathV2 API, + which is more efficient and flexible.
      +
      + -
      +

      Known Problems -

      + -
      +

      This section contains significant known problems with the LLVM system, listed by component. If you run into a problem, please check the LLVM bug database and submit a bug if there isn't already one.

      -
      - -
      +

      Experimental features included with this release -

      + -
      +

      The following components of this LLVM release are either untested, known to be broken or unreliable, or are in early development. These components should @@ -1114,43 +841,54 @@ components, please contact us on the LLVMdev list.

        -
      • The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, SystemZ +
      • The Alpha, Blackfin, CellSPU, MicroBlaze, MSP430, MIPS, PTX, SystemZ and XCore backends are experimental.
      • llc "-filetype=obj" is experimental on all targets - other than darwin-i386 and darwin-x86_64.
        • + other than darwin and ELF X86 systems. +
      -
      +

      Known problems with the X86 back-end -

      + -
      +
      • The X86 backend does not yet support all inline assembly that uses the X86 floating point stack. It supports the 'f' and 't' constraints, but not 'u'.
        • -
      • Win64 code generation wasn't widely tested. Everything should work, but we - expect small issues to happen. Also, llvm-gcc cannot build the mingw64 - runtime currently due to lack of support for the 'u' inline assembly - constraint and for X87 floating point inline assembly.
      • The X86-64 backend does not yet support the LLVM IR instruction va_arg. Currently, front-ends support variadic argument constructs on X86-64 by lowering them manually.
        • +
      • Windows x64 (aka Win64) code generator has a few issues. +
          +
        • llvm-gcc cannot build the mingw-w64 runtime currently + due to lack of support for the 'u' inline assembly + constraint and for X87 floating point inline assembly.
          • +
        • On mingw-w64, you will see unresolved symbol __chkstk + due to Bug 8919. + It is fixed in r128206.
          • +
        • Miss-aligned MOVDQA might crash your program. It is due to + Bug 9483, + lack of handling aligned internal globals.
          • +
        +
        • +
      -
      +

      Known problems with the PowerPC back-end -

      + -
      +
      • The Linux PPC32/ABI support needs testing for the interpreter and static @@ -1160,11 +898,11 @@ compilation, and lacks support for debug information.
      -
      +

      Known problems with the ARM back-end -

      + -
      +
      • Thumb mode works only on ARMv6 or higher processors. On sub-ARMv6 @@ -1177,11 +915,11 @@ results (PR1388).
      -
      +

      Known problems with the SPARC back-end -

      + -
      +
      • The SPARC backend only supports the 32-bit SPARC ABI (-m32); it does not @@ -1191,11 +929,11 @@ results (PR1388).
      -
      +

      Known problems with the MIPS back-end -

      + -
      +
      • 64-bit MIPS targets are not supported yet.
        • @@ -1204,11 +942,11 @@ results (PR1388).
      -
      +

      Known problems with the Alpha back-end -

      + -
      +
        @@ -1219,11 +957,11 @@ appropriate nops inserted to ensure restartability.
      -
      +

      Known problems with the C back-end -

      + -
      +

      The C backend has numerous problems and is not being actively maintained. Depending on it for anything serious is not advised.

      @@ -1242,11 +980,13 @@ Depending on it for anything serious is not advised.

      -
      +

      Known problems with the llvm-gcc front-end -

      + -
      +
      + +

      LLVM 2.9 will be the last release of llvm-gcc.

      llvm-gcc is generally very stable for the C family of languages. The only major language feature of GCC not supported by llvm-gcc is the @@ -1267,16 +1007,18 @@ actively maintained. If you are interested in Ada, we recommend that you consider using dragonegg instead.

      +
      + -
      +

      Additional Information -

      + -
      +

      A wide variety of additional information is available on the LLVM web page, in particular in the LLVM web page, in particular in the documentation section. The web page also contains versions of the API documentation which is up-to-date with the Subversion version of the source code. @@ -1299,7 +1041,7 @@ lists.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-10-26 14:43:36 +0200 (Tue, 26 Oct 2010) $ + Last modified: $Date: 2011-04-21 03:52:00 +0200 (Thu, 21 Apr 2011) $ diff --git a/docs/SourceLevelDebugging.html b/docs/SourceLevelDebugging.html index 186ea4abe732..4cfb52ee3a60 100644 --- a/docs/SourceLevelDebugging.html +++ b/docs/SourceLevelDebugging.html @@ -8,7 +8,7 @@ -
      Source Level Debugging with LLVM
      +

      Source Level Debugging with LLVM

      @@ -68,10 +68,10 @@ height="369"> -
      Introduction
      +

      Introduction

      -
      +

      This document is the central repository for all information pertaining to debug information in LLVM. It describes the actual format @@ -80,14 +80,12 @@ height="369"> Further, this document provides specific examples of what debug information for C/C++ looks like.

      -
      - -
      +

      Philosophy behind LLVM debugging information -

      + -
      +

      The idea of the LLVM debugging information is to capture how the important pieces of the source-language's Abstract Syntax Tree map onto LLVM code. @@ -133,11 +131,11 @@ height="369">

      -
      +

      Debug information consumers -

      + -
      +

      The role of debug information is to provide meta information normally stripped away during the compilation process. This meta information provides @@ -157,11 +155,11 @@ height="369">

      -
      +

      Debugging optimized code -

      + -
      +

      An extremely high priority of LLVM debugging information is to make it interact well with optimizations and analysis. In particular, the LLVM debug @@ -226,13 +224,15 @@ height="369">

      +
      + -
      +

      Debugging information format -

      + -
      +

      LLVM debugging information has been carefully designed to make it possible for the optimizer to optimize the program and debugging information without @@ -265,14 +265,12 @@ height="369"> common to any source-language. The next section describes the data layout conventions used by the C and C++ front-ends.

      -
      - -
      +

      Debug information descriptors -

      + -
      +

      In consideration of the complexity and volume of debug information, LLVM provides a specification for well formed debug descriptors.

      @@ -312,14 +310,12 @@ height="369">

      The details of the various descriptors follow.

      -
      - -
      +

      Compile unit descriptors -

      + -
      +
      @@ -351,11 +347,11 @@ height="369">
      -
      +

      File descriptors -

      + -
      +
      @@ -380,11 +376,11 @@ height="369">
      -
      +

      Global variable descriptors -

      + -
      +
      @@ -407,16 +403,17 @@ height="369">

      These descriptors provide debug information about globals variables. The -provide details such as name, type and where the variable is defined.

      +provide details such as name, type and where the variable is defined. All +global variables are collected by named metadata !llvm.dbg.gv.

      -
      +

      Subprogram descriptors -

      + -
      +
      @@ -432,30 +429,35 @@ provide details such as name, type and where the variable is defined.
      
   i32,      ;; Line number where defined
   metadata, ;; Reference to type descriptor
   i1,       ;; True if the global is local to compile unit (static)
-  i1        ;; True if the global is defined in the compile unit (not extern)
-  i32       ;; Virtuality, e.g. dwarf::DW_VIRTUALITY__virtual
-  i32       ;; Index into a virtual function
+  i1,       ;; True if the global is defined in the compile unit (not extern)
+  i32,      ;; Virtuality, e.g. dwarf::DW_VIRTUALITY__virtual
+  i32,      ;; Index into a virtual function
   metadata, ;; indicates which base type contains the vtable pointer for the 
             ;; derived class
-  i1        ;; isArtificial
-  i1        ;; isOptimized
-  Function *;; Pointer to LLVM function
+  i1,       ;; isArtificial
+  i1,       ;; isOptimized
+  Function *,;; Pointer to LLVM function
+  metadata, ;; Lists function template parameters
+  metadata  ;; Function declaration descriptor
 }

      These descriptors provide debug information about functions, methods and subprograms. They provide details such as name, return types and the source - location where the subprogram is defined.

      + location where the subprogram is defined. + All subprogram descriptors are collected by a named metadata + !llvm.dbg.sp. +

      -
      +

      Block descriptors -

      + -
      +
      @@ -463,7 +465,9 @@ provide details such as name, type and where the variable is defined.
      
   i32,     ;; Tag = 11 + LLVMDebugVersion (DW_TAG_lexical_block)
   metadata,;; Reference to context descriptor
   i32,     ;; Line number
-  i32      ;; Column number
+  i32,     ;; Column number
+  metadata,;; Reference to source file
+  i32      ;; Unique ID to identify blocks from a template function
 }
      @@ -475,11 +479,11 @@ provide details such as name, type and where the variable is defined.

      -
      +

      Basic type descriptors -

      + -
      +
      @@ -527,11 +531,11 @@ DW_ATE_unsigned_char = 8
      -
      +

      Derived type descriptors -

      + -
      +
      @@ -544,7 +548,12 @@ DW_ATE_unsigned_char = 8
   i64,      ;; Size in bits
   i64,      ;; Alignment in bits
   i64,      ;; Offset in bits
-  metadata  ;; Reference to type derived from
+  metadata, ;; Reference to type derived from
+  metadata, ;; (optional) Name of the Objective C property assoicated with 
+            ;; Objective-C an ivar 
+  metadata, ;; (optional) Name of the Objective C property getter selector.
+  metadata, ;; (optional) Name of the Objective C property setter selector.
+  i32       ;; (optional) Objective C property attributes.
 }
      @@ -594,11 +603,11 @@ DW_TAG_restrict_type = 55
      -
      +

      Composite type descriptors -

      + -
      +
      @@ -644,7 +653,8 @@ DW_TAG_inheritance      = 28
 
 
      The members of enumeration types (tag = DW_TAG_enumeration_type) are
    enumerator descriptors, each representing
-   the definition of enumeration value for the set.
      
+   the definition of enumeration value for the set. All enumeration type
+   descriptors are collected by named metadata !llvm.dbg.enum.
      
 
 
      The members of structure (tag = DW_TAG_structure_type) or union (tag
    = DW_TAG_union_type) types are any one of
@@ -680,11 +690,11 @@ DW_TAG_inheritance      = 28
      -
      +

      Subrange descriptors -

      + -
      +
      @@ -700,16 +710,17 @@ DW_TAG_inheritance      = 28
    composite type.  The low value defines
    the lower bounds typically zero for C/C++.  The high value is the upper
    bounds.  Values are 64 bit.  High - low + 1 is the size of the array.  If low
-   == high the array will be unbounded.
      
+   > high the array bounds are not included in generated debugging information.
+
      -
      +

      Enumerator descriptors -

      + -
      +
      @@ -729,11 +740,11 @@ DW_TAG_inheritance      = 28
      -
      +

      Local variables -

      + -
      +
      @@ -742,7 +753,8 @@ DW_TAG_inheritance      = 28
   metadata, ;; Context
   metadata, ;; Name
   metadata, ;; Reference to file where defined
-  i32,      ;; Line number where defined
+  i32,      ;; 24 bit - Line number where defined
+            ;; 8 bit - Argument number. 1 indicates 1st argument.
   metadata  ;; Type descriptor
 }
      @@ -771,39 +783,39 @@ DW_TAG_return_variable = 258
      +
      + -
      +

      Debugger intrinsic functions -

      + -
      +

      LLVM uses several intrinsic functions (name prefixed with "llvm.dbg") to provide debug information at various points in generated code.

      -
      - -
      +

      llvm.dbg.declare -

      + -
      +
         void %llvm.dbg.declare(metadata, metadata)

      This intrinsic provides information about a local element (ex. variable.) The - first argument is metadata holding alloca for the variable.. The + first argument is metadata holding alloca for the variable. The second argument is metadata containing description of the variable.

      -
      +

      llvm.dbg.value -

      + -
      +
         void %llvm.dbg.value(metadata, i64, metadata)
      @@ -815,12 +827,14 @@ DW_TAG_return_variable = 258 user source variable.

      +
      + -
      +

      Object lifetimes and scoping -

      + -
      +

      In many languages, the local variables in functions can have their lifetimes or scopes limited to a subset of a function. In the C family of languages, for example, variables are only live (readable and writable) within the @@ -978,13 +992,15 @@ call void @llvm.dbg.declare(metadata, metadata !12), !dbg !14

      +
      + -
      +

      C/C++ front-end specific debug information -

      + -
      +

      The C and C++ front-ends represent information about the program in a format that is effectively identical @@ -1005,14 +1021,12 @@ call void @llvm.dbg.declare(metadata, metadata !12), !dbg !14

      The following sections provide examples of various C/C++ constructs and the debug information that would best describe those constructs.

      -
      - -
      +

      C/C++ source file information -

      + -
      +

      Given the source files MySource.cpp and MyHeader.h located in the directory /Users/mine/sources, the following code:

      @@ -1086,11 +1100,11 @@ using Instruction::getMetadata() and
      -
      +

      C/C++ global variable information -

      + -
      +

      Given an integer global variable declared as follows:

      @@ -1156,11 +1170,11 @@ int MyGlobal = 100;
      -
      +

      C/C++ function information -

      + -
      +

      Given a function declared as follows:

      @@ -1192,7 +1206,14 @@ int main(int argc, char *argv[]) { i32 1, ;; Line number metadata !4, ;; Type i1 false, ;; Is local - i1 true ;; Is definition + i1 true, ;; Is definition + i32 0, ;; Virtuality attribute, e.g. pure virtual function + i32 0, ;; Index into virtual table for C++ methods + i32 0, ;; Type that holds virtual table. + i32 0, ;; Flags + i1 false, ;; True if this function is optimized + Function *, ;; Pointer to llvm::Function + null ;; Function template parameters } ;; ;; Define the subprogram itself. @@ -1206,22 +1227,20 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      C/C++ basic types -

      + -
      +

      The following are the basic type descriptors for C/C++ core types:

      -
      - -
      +

      bool -

      + -
      +
      @@ -1243,11 +1262,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      char -

      + -
      +
      @@ -1269,11 +1288,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      unsigned char -

      + -
      +
      @@ -1295,11 +1314,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      short -

      + -
      +
      @@ -1321,11 +1340,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      unsigned short -

      + -
      +
      @@ -1347,11 +1366,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      int -

      + -
      +
      @@ -1372,11 +1391,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      unsigned int -

      + -
      +
      @@ -1398,11 +1417,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      long long -

      + -
      +
      @@ -1424,11 +1443,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      unsigned long long -

      + -
      +
      @@ -1450,11 +1469,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      float -

      + -
      +
      @@ -1476,11 +1495,11 @@ define i32 @main(i32 %argc, i8** %argv) {
      -
      +

      double -

      + -
      +
      @@ -1501,12 +1520,14 @@ define i32 @main(i32 %argc, i8** %argv) {
      +
      + -
      +

      C/C++ derived types -

      + -
      +

      Given the following as an example of C/C++ derived type:

      @@ -1587,11 +1608,11 @@ typedef const int *IntPtr;
      -
      +

      C/C++ struct/union types -

      + -
      +

      Given the following as an example of C/C++ struct type:

      @@ -1700,11 +1721,11 @@ struct Color {
      -
      +

      C/C++ enumeration types -

      + -
      +

      Given the following as an example of C/C++ enumeration type:

      @@ -1765,6 +1786,8 @@ enum Trees {
      +
      +
      @@ -1775,8 +1798,8 @@ enum Trees { src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
      - LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-03 01:22:17 +0100 (Thu, 03 Feb 2011) $ + LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/SystemLibrary.html b/docs/SystemLibrary.html index b81b1a80d25d..57dc2391d535 100644 --- a/docs/SystemLibrary.html +++ b/docs/SystemLibrary.html @@ -7,7 +7,7 @@ -
      System Library
      +

      System Library

      • Abstract
      • Keeping LLVM Portable @@ -36,8 +36,8 @@ -
        Abstract
        -
        +

        Abstract

        +

        This document provides some details on LLVM's System Library, located in the source at lib/System and include/llvm/System. The library's purpose is to shield LLVM from the differences between operating @@ -63,21 +63,19 @@

        -
        +

        Keeping LLVM Portable -

        -
        + +

        In order to keep LLVM portable, LLVM developers should adhere to a set of portability rules associated with the System Library. Adherence to these rules should help the System Library achieve its goal of shielding LLVM from the variations in operating system interfaces and doing so efficiently. The following sections define the rules needed to fulfill this objective.

        -
        -
        Don't Include System Headers -
        -
        +

        Don't Include System Headers

        +

        Except in lib/System, no LLVM source code should directly #include a system header. Care has been taken to remove all such #includes from LLVM while lib/System was being @@ -91,9 +89,8 @@

        -
        Don't Expose System Headers -
        -
        +

        Don't Expose System Headers

        +

        The System Library must shield LLVM from all system headers. To obtain system level functionality, LLVM source must #include "llvm/System/Thing.h" and nothing else. This means that @@ -103,8 +100,8 @@

        -
        Use Standard C Headers
        -
        +

        Use Standard C Headers

        +

        The standard C headers (the ones beginning with "c") are allowed to be exposed through the lib/System interface. These headers and the things they declare are considered to be platform agnostic. LLVM source @@ -113,9 +110,8 @@

        -
        Use Standard C++ Headers -
        -
        +

        Use Standard C++ Headers

        +

        The standard C++ headers from the standard C++ library and standard template library may be exposed through the lib/System interface. These headers and the things they declare are considered to be @@ -124,8 +120,8 @@

        -
        High Level Interface
        -
        +

        High Level Interface

        +

        The entry points specified in the interface of lib/System must be aimed at completing some reasonably high level task needed by LLVM. We do not want to simply wrap each operating system call. It would be preferable to wrap several @@ -143,8 +139,8 @@

        -
        No Unused Functionality
        -
        +

        No Unused Functionality

        +

        There must be no functionality specified in the interface of lib/System that isn't actually used by LLVM. We're not writing a general purpose operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM @@ -153,9 +149,8 @@

        -
        No Duplicate Implementations -
        -
        +

        No Duplicate Implementations

        +

        The implementation of a function for a given platform must be written exactly once. This implies that it must be possible to apply a function's implementation to multiple operating systems if those operating systems can @@ -165,8 +160,8 @@

        -
        No Virtual Methods
        -
        +

        No Virtual Methods

        +

        The System Library interfaces can be called quite frequently by LLVM. In order to make those calls as efficient as possible, we discourage the use of virtual methods. There is no need to use inheritance for implementation @@ -175,8 +170,8 @@

        -
        No Exposed Functions
        -
        +

        No Exposed Functions

        +

        Any functions defined by system libraries (i.e. not defined by lib/System) must not be exposed through the lib/System interface, even if the header file for that function is not exposed. This prevents inadvertent use of system @@ -191,8 +186,8 @@

        -
        No Exposed Data
        -
        +

        No Exposed Data

        +

        Any data defined by system libraries (i.e. not defined by lib/System) must not be exposed through the lib/System interface, even if the header file for that function is not exposed. As with functions, this prevents inadvertent use @@ -200,8 +195,8 @@

        -
        Minimize Soft Errors
        -
        +

        Minimize Soft Errors

        +

        Operating system interfaces will generally provide error results for every little thing that could go wrong. In almost all cases, you can divide these error results into two groups: normal/good/soft and abnormal/bad/hard. That @@ -239,9 +234,8 @@

        -
        No throw Specifications -
        -
        +

        No throw Specifications

        +

        None of the lib/System interface functions may be declared with C++ throw() specifications on them. This requirement makes sure that the compiler does not insert additional exception handling code into the interface @@ -252,8 +246,8 @@

        -
        Code Organization
        -
        +

        Code Organization

        +

        Implementations of the System Library interface are separated by their general class of operating system. Currently only Unix and Win32 classes are defined but more could be added for other operating system classifications. @@ -281,8 +275,8 @@

        -
        Consistent Semantics
        -
        +

        Consistent Semantics

        +

        The implementation of a lib/System interface can vary drastically between platforms. That's okay as long as the end result of the interface function is the same. For example, a function to create a directory is pretty straight @@ -296,12 +290,14 @@

        -
        Bug 351
        -
        +

        Bug 351

        +

        See bug 351 for further details on the progress of this work

        +
        +
        @@ -312,8 +308,8 @@ src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Reid Spencer
        - LLVM Compiler Infrastructure
        - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + LLVM Compiler Infrastructure
        + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/TableGenFundamentals.html b/docs/TableGenFundamentals.html index d118332c9939..37ca04621a34 100644 --- a/docs/TableGenFundamentals.html +++ b/docs/TableGenFundamentals.html @@ -7,9 +7,9 @@ -
        TableGen Fundamentals
        +

        TableGen Fundamentals

        -
        +
        -
        Introduction
        +

        Introduction

        -
        +

        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 @@ -72,12 +72,10 @@ find an emacs "TableGen mode" and a vim language file in the llvm/utils/emacs and llvm/utils/vim directories of your LLVM distribution, respectively.

        -
        - -
        Basic concepts
        +

        Basic concepts

        -
        +

        TableGen files consist of two key parts: 'classes' and 'definitions', both of which are considered 'records'.

        @@ -112,9 +110,9 @@ multiclass, as if they were declared in the current multiclass.

        -
        An example record
        +

        An example record

        -
        +

        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 @@ -212,9 +210,9 @@ abstractions they prefer to use when describing their information.

        -
        Running TableGen
        +

        Running TableGen

        -
        +

        TableGen runs just like any other LLVM tool. The first (optional) argument specifies the file to read. If a filename is not specified, tblgen @@ -256,27 +254,28 @@ what you need and formats it in the appropriate way.

        +
        -
        TableGen syntax
        +

        TableGen syntax

        -
        +

        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.

        -
        - -
        TableGen primitives
        +

        TableGen primitives

        + +
        -
        TableGen comments
        +

        TableGen comments

        -
        +

        TableGen supports BCPL style "//" comments, which run to the end of the line, and it also supports nestable "/* */" comments.

        @@ -284,11 +283,11 @@ the line, and it also supports nestable "/* */" comments.

        -
        +

        The TableGen type system -

        + -
        +

        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 @@ -344,11 +343,11 @@ needed.

        -
        +

        TableGen values and expressions -

        + -
        +

        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 @@ -433,12 +432,14 @@ to a "bits<4>" value, for example.

        +
        + -
        +

        Classes and definitions -

        + -
        +

        As mentioned in the intro, classes and definitions (collectively known as 'records') in TableGen are the main high-level unit of @@ -473,14 +474,12 @@ 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.

        -
        - -
        +

        Value definitions -

        + -
        +

        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 @@ -492,11 +491,11 @@ equal sign. Value definitions require terminating semicolons.

        -
        +

        'let' expressions -

        + -
        +

        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 @@ -519,11 +518,11 @@ because the D class overrode its value.

        -
        +

        Class template arguments -

        + -
        +

        TableGen permits the definition of parameterized classes as well as normal concrete classes. Parameterized TableGen classes specify a list of variable @@ -610,11 +609,11 @@ X86 backend.

        -
        +

        Multiclass definitions and instances -

        + -
        +

        While classes with template arguments are a good way to factor commonality @@ -772,17 +771,21 @@ before them.

        +
        + -
        +

        File scope entities -

        + + +
        -
        +

        File inclusion -

        + -
        +

        TableGen supports the 'include' 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 'include' @@ -797,11 +800,11 @@ keyword. Example:

        -
        +

        'let' expressions -

        + -
        +

        "Let" expressions at file scope are similar to "let" expressions within a record, except they can specify a value binding for @@ -864,11 +867,15 @@ several levels of multiclass instanciations. This also avoids the need of using

        +
        + +
        + -
        Code Generator backend info
        +

        Code Generator backend info

        -
        +

        Expressions used by code generator to describe instructions and isel patterns:

        @@ -882,10 +889,10 @@ patterns:

        -
        TableGen backends
        +

        TableGen backends

        -
        +

        TODO: How they work, how to write one. This section should not contain details about any particular backend, except maybe -print-enums as an example. @@ -903,8 +910,8 @@ This should highlight the APIs in TableGen/Record.h.

        src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Chris Lattner
        - LLVM Compiler Infrastructure
        - Last modified: $Date: 2011-01-07 18:05:37 +0100 (Fri, 07 Jan 2011) $ + LLVM Compiler Infrastructure
        + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html index 964bdc31247d..4fc4c70011ab 100644 --- a/docs/TestingGuide.html +++ b/docs/TestingGuide.html @@ -7,9 +7,9 @@ -
        +

        LLVM Testing Infrastructure Guide -

        +
        1. Overview
          2. @@ -52,10 +52,10 @@
        -
        Overview
        +

        Overview

        -
        +

        This document is the reference manual for the LLVM testing infrastructure. It documents the structure of the LLVM testing infrastructure, the tools needed to @@ -64,10 +64,10 @@ use it, and how to add and run tests.

        -
        Requirements
        +

        Requirements

        -
        +

        In order to use the LLVM testing infrastructure, you will need all of the software required to build LLVM, as well @@ -76,10 +76,10 @@ as Python 2.4 or later.

        -
        LLVM testing infrastructure organization
        +

        LLVM testing infrastructure organization

        -
        +

        The LLVM testing infrastructure contains two major categories of tests: regression tests and whole programs. The regression tests are contained inside @@ -89,13 +89,11 @@ referred to as the "LLVM test suite" and are in the test-suite module in subversion.

        -
        - -
        Regression tests
        +

        Regression tests

        -
        +

        The regression tests 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 @@ -119,10 +117,10 @@ application or benchmark.

        -
        Test suite
        +

        Test suite

        -
        +

        The test suite contains whole programs, which are pieces of code which can be compiled and linked into a stand-alone program that can be @@ -144,11 +142,10 @@ generates code.

        -
        Debugging Information -tests
        +

        Debugging Information tests

        -
        +

        The test suite contains tests to check quality of debugging information. The test are written in C based languages or in LLVM assembly language.

        @@ -160,11 +157,13 @@ test suite for more information . This test suite is located in the
        +
        + -
        Quick start
        +

        Quick start

        -
        +

        The tests are located in two separate Subversion modules. The regressions tests are in the main "llvm" module under the directory @@ -179,7 +178,8 @@ the test-suite directory will be automatically configured. Alternatively, you can configure the test-suite module manually.

        -
        Regression tests
        +

        Regression tests

        +

        To run all of the LLVM regression tests, use master Makefile in the llvm/test directory:

        @@ -198,7 +198,7 @@ Alternatively, you can configure the test-suite module manually.

        -

        If you have Clang checked out and built, +

        If you have Clang checked out and built, you can run the LLVM and Clang tests simultaneously using:

        or

        @@ -239,10 +239,14 @@ script which is built as part of LLVM. For example, to run the

        For more information on using the 'lit' tool, see 'llvm-lit --help' or the 'lit' man page.

        +
        + -
        Test suite
        +

        Test suite

        +
        +

        To run the comprehensive test suite (tests that compile and execute whole programs), first checkout and setup the test-suite module:

        @@ -292,9 +296,10 @@ that subdirectory.

        -
        Debugging Information -tests
        +

        Debugging Information tests

        +
        +

        To run debugging information tests simply checkout the tests inside clang/test directory.

        @@ -310,10 +315,14 @@ clang/test directory.

        +
        + +
        + -
        Regression test structure
        +

        Regression test structure

        -
        +

        The LLVM regression tests are driven by 'lit' and are located in the llvm/test directory. @@ -335,12 +344,10 @@ clang/test directory.

      • Verifier: tests the IR verifier.
      -
      - -
      Writing new regression tests
      +

      Writing new regression tests

      -
      +

      The regression test structure is very simple, but does require some information to be set. This information is gathered via configure and is written to a file, lit.site.cfg @@ -492,10 +499,10 @@ negatives).

      -
      The FileCheck utility
      +

      The FileCheck utility

      -
      +

      A powerful feature of the RUN: lines is that it allows any arbitrary commands to be executed as part of the test harness. While standard (portable) unix @@ -561,13 +568,12 @@ is a "subl" in between those labels. If it existed somewhere else in the file, that would not count: "grep subl" matches if subl exists anywhere in the file.

      -
      - -
      The FileCheck -check-prefix option
      +

      + The FileCheck -check-prefix option +

      -
      +

      The FileCheck -check-prefix option allows multiple test configurations to be driven from one .ll file. This is useful in many circumstances, for example, @@ -598,10 +604,11 @@ both 32-bit and 64-bit code generation.

      -
      The "CHECK-NEXT:" directive
      +

      + The "CHECK-NEXT:" directive +

      -
      +

      Sometimes you want to match lines and would like to verify that matches happen on exactly consecutive lines with no other lines in between them. In @@ -638,10 +645,11 @@ directive in a file.

      -
      The "CHECK-NOT:" directive
      +

      + The "CHECK-NOT:" directive +

      -
      +

      The CHECK-NOT: directive is used to verify that a string doesn't occur between two matches (or the first match and the beginning of the file). For @@ -668,10 +676,11 @@ define i8 @coerce_offset0(i32 %V, i32* %P) {

      -
      FileCheck Pattern Matching Syntax
      +

      + FileCheck Pattern Matching Syntax +

      -
      +

      The CHECK: and CHECK-NOT: directives both take a pattern to match. For most uses of FileCheck, fixed string matching is perfectly sufficient. For some @@ -700,10 +709,11 @@ braces explicitly from the input, you can use something ugly like

      -
      FileCheck Variables
      +

      + FileCheck Variables +

      -
      +

      It is often useful to match a pattern and then verify that it occurs again later in the file. For codegen tests, this can be useful to allow any register, @@ -738,11 +748,12 @@ define two separate CHECK lines that match on the same line.

      +
      + -
      Variables and -substitutions
      +

      Variables and substitutions

      -
      +

      With a RUN line there are a number of substitutions that are permitted. In general, any Tcl variable that is available in the substitute function (in test/lib/llvm.exp) can be substituted into a RUN line. @@ -835,9 +846,9 @@ substitutions

      -
      Other Features
      +

      Other Features

      -
      +

      To make RUN line writing easier, there are several shell scripts located in the llvm/test/Scripts directory. This directory is in the PATH when running tests, so you can just call these scripts using their name. For @@ -892,12 +903,13 @@ substitutions

      +
      + -
      Test suite -Structure
      +

      Test suite Structure

      -
      +

      The test-suite module contains a number of programs that can be compiled with LLVM and executed. These programs are compiled using the native compiler @@ -962,10 +974,10 @@ will help you separate benign warnings from actual test failures.

      -
      Running the test suite
      +

      Running the test suite

      -
      +

      First, all tests are executed within the LLVM object directory tree. They are not executed inside of the LLVM source tree. This is because the @@ -1020,14 +1032,13 @@ test suite creates temporary files during execution.

      have the suite checked out and configured, you don't need to do it again (unless the test code or configure script changes).

      -
      - -
      -Configuring External Tests
      +

      + Configuring External Tests +

      -
      +

      In order to run the External tests in the test-suite module, you must specify --with-externals. This must be done during the re-configuration step (see above), @@ -1055,10 +1066,11 @@ the test code or configure script changes).

      -
      -Running different tests
      +

      + Running different tests +

      -
      +

      In addition to the regular "whole program" tests, the test-suite module 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 @@ -1078,10 +1090,11 @@ LLVM.

      -
      -Generating test output
      +

      + Generating test output +

      -
      +

      There are a number of ways to run the tests and generate output. The most simple one is simply running gmake with no arguments. This will compile and run all programs in the tree using a number of different methods @@ -1109,11 +1122,12 @@ LLVM.

      -
      -Writing custom tests for the test suite
      +

      + Writing custom tests for the test suite +

      -
      +

      Assuming you can run the test suite, (e.g. "gmake TEST=nightly report" should work), it is really easy to run optimizations or code generator @@ -1179,6 +1193,8 @@ example reports that can do fancy stuff.

      +
      +
      @@ -1189,8 +1205,8 @@ example reports that can do fancy stuff.

      src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> John T. Criswell, Daniel Dunbar, Reid Spencer, and Tanya Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-15 10:23:02 +0100 (Tue, 15 Feb 2011) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/UsingLibraries.html b/docs/UsingLibraries.html index ea28dbec0cc4..2c1c69a69a5f 100644 --- a/docs/UsingLibraries.html +++ b/docs/UsingLibraries.html @@ -5,7 +5,7 @@ -
      Using The LLVM Libraries
      +

      Using The LLVM Libraries

      1. Abstract
      2. Introduction
        3. @@ -26,12 +26,12 @@

        Warning: This document is out of date, for more information please see llvm-config or, - if you use CMake, the CMake LLVM + if you use CMake, the CMake LLVM guide.

        -
        Abstract
        -
        +

        Abstract

        +

        Amongst other things, LLVM is a toolkit for building compilers, linkers, runtime executives, virtual machines, and other program execution related tools. In addition to the LLVM tool set, the functionality of LLVM is @@ -45,8 +45,8 @@

        -
        Introduction
        -
        +

        Introduction

        +

        If you're writing a compiler, virtual machine, or any other utility based on LLVM, you'll need to figure out which of the many libraries files you will need to link with to be successful. An understanding of the contents of these @@ -74,8 +74,8 @@ correct for your tool can sometimes be challenging.

        -
        Library Descriptions
        -
        +

        Library Descriptions

        +

        The table below categorizes each library

      @@ -152,8 +152,8 @@ -
      Using llvm-config
      -
      +

      Using llvm-config

      +

      The llvm-config tool is a perl script that produces on its output various kinds of information. For example, the source or object directories used to build LLVM can be accessed by passing options to llvm-config. @@ -187,16 +187,16 @@ -

      Dependency Relationships Of Libraries

      +

      Dependency Relationships Of Libraries

      This graph shows the dependency of archive libraries on other archive libraries or objects. Where a library has both archive and object forms, only the archive form is shown.

      - Library Dependencies -

      Dependency Relationships Of Object Files

      + Library Dependencies +

      Dependency Relationships Of Object Files

      This graph shows the dependency of object files on archive libraries or other objects. Where a library has both object and archive forms, only the dependency to the archive form is shown.

      - Object File Dependencies + Object File Dependencies

      The following list shows the dependency relationships between libraries in textual form. The information is the same as shown on the graphs but arranged alphabetically.

      @@ -280,8 +280,8 @@
    25. libLLVMSystem.a
    26. libLLVMbzip2.a
      27. -
      libLLVMSystem.a
        -
      +
      libLLVMSystem.a
      +
      libLLVMTarget.a
      • libLLVMCore.a
      • libLLVMSupport.a
        • @@ -295,8 +295,8 @@
      • libLLVMTarget.a
      • libLLVMipa.a
      -
      libLLVMbzip2.a
        -
      +
      libLLVMbzip2.a
      +
      libLLVMipa.a
      • libLLVMAnalysis.a
      • libLLVMCore.a
        • @@ -401,42 +401,46 @@
      -
      Linkage Rules Of Thumb
      -
      +

      Linkage Rules Of Thumb

      +

      This section contains various "rules of thumb" about what files you should link into your programs.

      -
      -
      Always Link LLVMCore, LLVMSupport, - and LLVMSystem
      -
      +

      + Always Link LLVMCore, LLVMSupport, and LLVMSystem +

      +

      No matter what you do with LLVM, the last three entries in the value of your LLVMLIBS make variable should always be: LLVMCore LLVMSupport.a LLVMSystem.a. There are no LLVM programs that don't depend on these three.

      -
      Never link both archive and - re-linked library
      -
      +

      + Never link both archive and re-linked library +

      +

      There is never any point to linking both the re-linked (.o) and the archive (.a) versions of a library. Since the re-linked version includes the entire library, the archive version will not resolve any symbols. You could even end up with link error if you place the archive version before the re-linked version on the linker's command line.

      + +
      +
      Valid CSS + src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"> Valid HTML 4.01 Reid Spencer
      -The LLVM Compiler Infrastructure -
      Last modified: $Date: 2010-09-17 02:30:52 +0200 (Fri, 17 Sep 2010) $
      +The LLVM Compiler Infrastructure +
      Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
      -
      +

      Introduction -

      + -
      +

      This document describes techniques for writing compiler backends that convert @@ -91,13 +91,11 @@ characteristics, such as a RISC instruction set and straightforward calling conventions.

      -
      - -
      +

      Audience -

      + -
      +

      The audience for this document is anyone who needs to write an LLVM backend to @@ -106,21 +104,21 @@ generate code for a specific hardware or software target.

      -
      +

      Prerequisite Reading -

      + -
      +

      These essential documents must be read before reading this document:

        -
      • LLVM Language Reference +
      • LLVM Language Reference Manual — a reference manual for the LLVM assembly language.
        • -
      • The LLVM +
      • The LLVM Target-Independent Code Generator — a guide to the components (classes and code generation algorithms) for translating the LLVM internal representation into machine code for a specified target. Pay particular @@ -129,14 +127,14 @@ These essential documents must be read before reading this document: Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations, and Code Emission.
        • -
      • TableGen +
      • TableGen Fundamentals —a document that describes the TableGen (tblgen) application that manages domain-specific information to support LLVM code generation. TableGen processes input from a target description file (.td suffix) and generates C++ code that can be used for code generation.
        • -
      • Writing an LLVM +
      • Writing an LLVM Pass — The assembly printer is a FunctionPass, as are several SelectionDAG processing steps.
      @@ -155,11 +153,11 @@ machine dependent features.
      -
      +

      Basic Steps -

      + -
      +

      To write a compiler backend for LLVM that converts the LLVM IR to code for a @@ -220,17 +218,17 @@ that the class will need and which components will need to be subclassed.

      -
      +

      Preliminaries -

      + -
      +

      To actually create your compiler backend, you need to create and modify a few files. The absolute minimum is discussed here. But to actually use the LLVM target-independent code generator, you must perform the steps described in -the LLVM +the LLVM Target-Independent Code Generator document.

      @@ -281,13 +279,15 @@ regenerate configure by running ./autoconf/AutoRegen.sh.
      +
      + -
      +

      Target Machine -

      + -
      +

      LLVMTargetMachine is designed as a base class for targets implemented @@ -360,11 +360,6 @@ public:

      -
      - - -
      -
      • getInstrInfo()
      • getRegisterInfo()
        • @@ -398,10 +393,6 @@ SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &a
      -
      - -
      -

      Hyphens separate portions of the TargetDescription string.

        @@ -424,12 +415,12 @@ SparcTargetMachine::SparcTargetMachine(const Module &M, const std::string &a
      -
      +

      Target Registration -

      + -
      +

      You must also register your target with the TargetRegistry, which is @@ -480,12 +471,12 @@ For more information, see

      -
      +

      Register Set and Register Classes -

      + -
      +

      You should describe a concrete target-specific class that represents the @@ -514,14 +505,12 @@ input files and placed in XXXGenRegisterInfo.h.inc and implementation of XXXRegisterInfo requires hand-coding.

      -
      - -
      +

      Defining a Register -

      + -
      +

      The XXXRegisterInfo.td file typically starts with register definitions @@ -700,11 +689,11 @@ fields of a register's TargetRegisterDesc.

      -
      +

      Defining a Register Class -

      + -
      +

      The RegisterClass class (specified in Target.td) is used to @@ -894,12 +883,12 @@ namespace SP { // Register class instances

      -
      +

      Implement a subclass of - TargetRegisterInfo -

      + TargetRegisterInfo + -
      +

      The final step is to hand code portions of XXXRegisterInfo, which @@ -933,13 +922,15 @@ implementation in SparcRegisterInfo.cpp:

      +
      + -
      +

      Instruction Set -

      + -
      +

      During the early stages of code generation, the LLVM IR code is converted to a @@ -1103,7 +1094,7 @@ The fifth parameter is a string that is used by the assembly printer and can be left as an empty string until the assembly printer interface is implemented. The sixth and final parameter is the pattern used to match the instruction during the SelectionDAG Select Phase described in -(The LLVM +(The LLVM Target-Independent Code Generator). This parameter is detailed in the next section, Instruction Selector.

      @@ -1188,14 +1179,12 @@ correspond to the values in SparcInstrInfo.td. I.e., SPCC::ICC_NE = 9, SPCC::FCC_U = 23 and so on.)

      -
      - -
      +

      Instruction Operand Mapping -

      + -
      +

      The code generator backend maps instruction operands to fields in the @@ -1283,12 +1272,12 @@ the rd, rs1, and rs2 fields respectively.

      -
      +

      Implement a subclass of - TargetInstrInfo -

      + TargetInstrInfo + -
      +

      The final step is to hand code portions of XXXInstrInfo, which @@ -1327,10 +1316,10 @@ implementation in SparcInstrInfo.cpp:

      -
      +

      Branch Folding and If Conversion -

      -
      + +

      Performance can be improved by combining instructions or by eliminating @@ -1485,13 +1474,15 @@ branch.

      +
      + -
      +

      Instruction Selector -

      + -
      +

      LLVM uses a SelectionDAG to represent LLVM IR instructions, and nodes @@ -1533,7 +1524,7 @@ selection pass into the queue of passes to run. The LLVM static compiler (llc) is an excellent tool for visualizing the contents of DAGs. To display the SelectionDAG before or after specific processing phases, use the command line options for llc, described -at +at SelectionDAG Instruction Selection Process.

      @@ -1642,14 +1633,12 @@ SDNode *Select_ISD_STORE(const SDValue &N) {
      -
      - -
      +

      The SelectionDAG Legalize Phase -

      + -
      +

      The Legalize phase converts a DAG to use types and operations that are natively @@ -1716,14 +1705,12 @@ a LegalAction type enum value: Promote, Expand, contains examples of all four LegalAction values.

      -
      - -
      +

      Promote -

      + -
      +

      For an operation without native support for a given type, the specified type may @@ -1742,11 +1729,11 @@ setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);

      -
      +

      Expand -

      + -
      +

      For a type without native support, a value may need to be broken down further, @@ -1767,11 +1754,11 @@ setOperationAction(ISD::FCOS, MVT::f32, Expand);

      -
      +

      Custom -

      + -
      +

      For some operations, simple type promotion or operation expansion may be @@ -1833,11 +1820,11 @@ static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) {

      -
      +

      Legal -

      + -
      +

      The Legal LegalizeAction enum value simply indicates that an @@ -1865,12 +1852,14 @@ if (TM.getSubtarget<SparcSubtarget>().isV9())

      +
      + -
      +

      Calling Conventions -

      + -
      +

      To support target-specific calling conventions, XXXGenCallingConv.td @@ -2015,13 +2004,15 @@ def RetCC_X86_32 : CallingConv<[

      +
      + -
      +

      Assembly Printer -

      + -
      +

      During the code emission stage, the code generator may utilize an LLVM pass to @@ -2171,12 +2162,12 @@ output.

      -
      +

      Subtarget Support -

      + -
      +

      Subtarget support is used to inform the code generation process of instruction @@ -2289,12 +2280,12 @@ XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) {

      -
      +

      JIT Support -

      + -
      +

      The implementation of a target machine optionally includes a Just-In-Time (JIT) @@ -2333,14 +2324,12 @@ Both XXXJITInfo.cpp and XXXCodeEmitter.cpp must include the that write data (in bytes, words, strings, etc.) to the output stream.

      -
      - -
      +

      Machine Code Emitter -

      + -
      +

      In XXXCodeEmitter.cpp, a target-specific of the Emitter class @@ -2478,11 +2467,11 @@ enum RelocationType {

      -
      +

      Target JIT Info -

      + -
      +

      XXXJITInfo.cpp implements the JIT interfaces for target-specific @@ -2537,6 +2526,8 @@ with assembler.

      +
      +
      @@ -2547,9 +2538,9 @@ with assembler. src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"> Mason Woo and Misha Brukman
      - The LLVM Compiler Infrastructure + The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-11-23 04:31:01 +0100 (Tue, 23 Nov 2010) $ + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html index 80258e428352..75426e051d35 100644 --- a/docs/WritingAnLLVMPass.html +++ b/docs/WritingAnLLVMPass.html @@ -8,9 +8,9 @@ -
      +

      Writing an LLVM Pass -

      +
      1. Introduction - What is a pass?
        2. @@ -121,12 +121,12 @@
      -
      +

      Introduction - What is a pass? -

      + -
      +

      The LLVM Pass Framework is an important part of the LLVM system, because LLVM passes are where most of the interesting parts of the compiler exist. Passes @@ -156,12 +156,12 @@ more advanced features are discussed.

      -
      +

      Quick Start - Writing hello world -

      + -
      +

      Here we describe how to write the "hello world" of passes. The "Hello" pass is designed to simply print out the name of non-external functions that exist in @@ -169,14 +169,12 @@ the program being compiled. It does not modify the program at all, it just inspects it. The source code and files for this pass are available in the LLVM source tree in the lib/Transforms/Hello directory.

      -
      - -
      +

      Setting up the build environment -

      + -
      +

      First, configure and build LLVM. This needs to be done directly inside the LLVM source tree rather than in a separate objects directory. @@ -185,7 +183,7 @@ source tree in the lib/Transforms/Hello directory.

      lib/Transforms/Hello. Finally, you must set up a build script (Makefile) that will compile the source code for the new pass. To do this, copy the following into Makefile:

      -
      + 
       # Makefile for hello pass
@@ -211,17 +209,20 @@ the opt or bugpoint tools via their -load options.
 If your operating system uses a suffix other than .so (such as windows or 
 Mac OS/X), the appropriate extension will be used.
      
 
+
      If you are used CMake to build LLVM, see
+Developing an LLVM pass with CMake.
      
+
 
      Now that we have the build scripts set up, we just need to write the code for
 the pass itself.
      -
      +

      Basic code required -

      + -
      +

      Now that we have a way to compile our new pass, we just have to write it. Start out with:

      @@ -301,7 +302,7 @@ function.

      initialization value is not important.

      -  static RegisterPass X("hello", "Hello World Pass",
+  static RegisterPass<Hello> X("hello", "Hello World Pass",
                         false /* Only looks at CFG */,
                         false /* Analysis Pass */);
 }  // end of anonymous namespace
@@ -337,7 +338,7 @@ is supplied as fourth argument. 
      
   };
   
   char Hello::ID = 0;
-  static RegisterPass X("hello", "Hello World Pass", false, false);
+  static RegisterPass<Hello> X("hello", "Hello World Pass", false, false);
 }
      @@ -353,11 +354,11 @@ them) to be useful.

      -
      +

      Running a pass with opt -

      + -
      +

      Now that you have a brand new shiny shared object file, we can use the opt command to run an LLVM program through your pass. Because you @@ -443,13 +444,15 @@ about some more details of how they work and how to use them.

      +
      + -
      +

      Pass classes and requirements -

      + -
      +

      One of the first things that you should do when designing a new pass is to decide what class you should subclass for your pass. The -

      - -
      +

      The ImmutablePass class -

      + -
      +

      The most plain and boring type of pass is the "ImmutablePass" @@ -490,11 +491,11 @@ invalidated, and are never "run".

      -
      +

      The ModulePass class -

      + -
      +

      The "ModulePass" @@ -516,14 +517,12 @@ DominatorTree for function definitions, not declarations.

      ModulePass and overload the runOnModule method with the following signature:

      -
      - -
      +

      The runOnModule method -

      + -
      +
         virtual bool runOnModule(Module &M) = 0;
@@ -535,12 +534,14 @@ false otherwise.
      +
      + -
      +

      The CallGraphSCCPass class -

      + -
      +

      The "CallGraphSCCPass" @@ -581,15 +582,14 @@ because it has to handle SCCs with more than one node in it. All of the virtual methods described below should return true if they modified the program, or false if they didn't.

      -
      - -
      - The doInitialization(CallGraph &) - method -
      +

      + + The doInitialization(CallGraph &) method + +

      -
      +
         virtual bool doInitialization(CallGraph &CG);
@@ -606,11 +606,11 @@ fast).
      -
      +

      The runOnSCC method -

      + -
      +
         virtual bool runOnSCC(CallGraphSCC &SCC) = 0;
@@ -623,12 +623,13 @@ otherwise.
      -
      - The doFinalization(CallGraph - &) method -
      +

      + + The doFinalization(CallGraph &) method + +

      -
      +
         virtual bool doFinalization(CallGraph &CG);
@@ -641,12 +642,14 @@ program being compiled.
      +
      + -
      +

      The FunctionPass class -

      + -
      +

      In contrast to ModulePass subclasses, FunctionPass @@ -671,15 +674,14 @@ href="#basiccode">Hello World pass for example). FunctionPass's may overload three virtual methods to do their work. All of these methods should return true if they modified the program, or false if they didn't.

      -
      - -
      - The doInitialization(Module &) - method -
      +

      + + The doInitialization(Module &) method + +

      -
      +
         virtual bool doInitialization(Module &M);
@@ -703,11 +705,11 @@ free functions that it needs, adding prototypes to the module if necessary.
      -
      +

      The runOnFunction method -

      + -
      +
         virtual bool runOnFunction(Function &F) = 0;
@@ -720,12 +722,13 @@ be returned if the function is modified.
      -
      - The doFinalization(Module - &) method -
      +

      + + The doFinalization(Module &) method + +

      -
      +
         virtual bool doFinalization(Module &M);
@@ -738,12 +741,14 @@ program being compiled.
      +
      + -
      +

      The LoopPass class -

      + -
      +

      All LoopPass execute on each loop in the function independent of all of the other loops in the function. LoopPass processes loops in @@ -751,19 +756,18 @@ loop nest order such that outer most loop is processed last.

      LoopPass subclasses are allowed to update loop nest using LPPassManager interface. Implementing a loop pass is usually -straightforward. Looppass's may overload three virtual methods to +straightforward. LoopPass's may overload three virtual methods to do their work. All these methods should return true if they modified the program, or false if they didn't.

      -
      -
      - The doInitialization(Loop *, - LPPassManager &) - method -
      +

      + + The doInitialization(Loop *,LPPassManager &) method + +

      -
      +
         virtual bool doInitialization(Loop *, LPPassManager &LPM);
@@ -780,11 +784,11 @@ information.
      
 
 
 
-
      
+
      
   The runOnLoop method
-
      
+
 
-
      
+
      
 
 
         virtual bool runOnLoop(Loop *, LPPassManager &LPM) = 0;
@@ -798,11 +802,11 @@ should be used to update loop nest.
      
 
      
 
 
-
      
+
      
   The doFinalization() method
-
      
+
 
-
      
+
      
 
 
         virtual bool doFinalization();
@@ -815,12 +819,14 @@ program being compiled. 
      
 
 
      
 
+
      
+
 
-
      
+
      
   The RegionPass class 
-
      
+
 
-
      
+
      
 
 
       RegionPass is similar to LoopPass,
 but executes on each single entry single exit region in the function.
@@ -829,19 +835,18 @@ region is processed last.  
      
 
 
       RegionPass subclasses are allowed to update the region tree by using
 the RGPassManager interface. You may overload three virtual methods of
-RegionPass to implementing your own region pass is usually. All these
+RegionPass to implement your own region pass. All these
 methods should return true if they modified the program, or false if they didn not.
 
      
-
      
 
 
-
      
-  The doInitialization(Region *,
-                                                 RGPassManager &)
-  method
-
      
+
      
+  
+    The doInitialization(Region *, RGPassManager &) method
+  
+
      
 
-
      
+
      
 
 
         virtual bool doInitialization(Region *, RGPassManager &RGM);
@@ -858,11 +863,11 @@ information.
      
 
 
 
-
      
+
      
   The runOnRegion method
-
      
+
 
-
      
+
      
 
 
         virtual bool runOnRegion(Region *, RGPassManager &RGM) = 0;
@@ -876,11 +881,11 @@ should be used to update region tree.
      
 
      
 
 
-
      
+
      
   The doFinalization() method
-
      
+
 
-
      
+
      
 
 
         virtual bool doFinalization();
@@ -893,14 +898,14 @@ program being compiled. 
      
 
 
      
 
-
+
      
 
 
-
      
+
      
   The BasicBlockPass class
-
      
+
 
-
      
+
      
 
 
      BasicBlockPass's are just like FunctionPass's, except that they must limit
@@ -922,15 +927,14 @@ href="#doInitialization_mod">doInitialization(Module &) and doFinalization(Module &) methods that FunctionPass's have, but also have the following virtual methods that may also be implemented:
      
 
-
      
-
 
-
      
-  The doInitialization(Function
-  &) method
-
      
+
      
+  
+    The doInitialization(Function &) method
+  
+
      
 
-
      
+
      
 
 
         virtual bool doInitialization(Function &F);
@@ -947,11 +951,11 @@ fast).
      
 
      
 
 
-
      
+
      
   The runOnBasicBlock method
-
      
+
 
-
      
+
      
 
 
         virtual bool runOnBasicBlock(BasicBlock &BB) = 0;
@@ -965,12 +969,13 @@ if the basic block is modified.
      
 
      
 
 
-
      
-  The doFinalization(Function &) 
-  method
-
      
+
      
+  
+    The doFinalization(Function &) method
+  
+
      
 
-
      
+
      
 
 
         virtual bool doFinalization(Function &F);
@@ -984,12 +989,14 @@ finalization.
      
 
 
      
 
+
      
+
 
-
      
+
      
   The MachineFunctionPass class
-
      
+
 
-
      
+
      
 
 
      A MachineFunctionPass is a part of the LLVM code generator that
 executes on the machine-dependent representation of each LLVM function in the
@@ -1014,15 +1021,14 @@ href="#runOnMachineFunction">runOnMachineFunction (including global
 data)
 
 
-
      
-
 
-
      
-  The runOnMachineFunction(MachineFunction
-  &MF) method
-
      
+
      
+  
+    The runOnMachineFunction(MachineFunction &MF) method
+  
+
      
 
-
      
+
      
 
 
         virtual bool runOnMachineFunction(MachineFunction &MF) = 0;
@@ -1043,13 +1049,17 @@ remember, you may not modify the LLVM Function or its contents from a
 
 
      
 
+
      
+
+
      
+
 
-
      
+
      
   Pass registration
-
      
+
 
 
-
      
+
      
 
 
      In the Hello World example pass we illustrated how
 pass registration works, and discussed some of the reasons that it is used and
@@ -1066,14 +1076,12 @@ well as for debug output generated by the --debug-pass option.
      
 
      If you want your pass to be easily dumpable, you should 
 implement the virtual print method:
      
 
-
      
-
 
-
      
+
      
   The print method
-
      
+
 
-
      
+
      
 
 
         virtual void print(std::ostream &O, const Module *M) const;
@@ -1093,13 +1101,15 @@ depended on.
      
 
 
      
 
+
      
+
 
-
      
+
      
   Specifying interactions between passes
-
      
+
 
 
-
      
+
      
 
 
      One of the main responsibilities of the PassManager is to make sure
 that passes interact with each other correctly.  Because PassManager
@@ -1116,14 +1126,12 @@ specifies.  If a pass does not implement the getAnalysisUsage method, it defaults to not
 having any prerequisite passes, and invalidating all other passes.
      
 
-
      
-
 
-
      
+
      
   The getAnalysisUsage method
-
      
+
 
-
      
+
      
 
 
         virtual void getAnalysisUsage(AnalysisUsage &Info) const;
@@ -1139,11 +1147,14 @@ object:
      
 
      
 
 
-
      
-  The AnalysisUsage::addRequired<> and AnalysisUsage::addRequiredTransitive<> methods
-
      
-
-
      
+
      
+  
+    The AnalysisUsage::addRequired<>
+    and AnalysisUsage::addRequiredTransitive<> methods
+  
+
      
+
+
      
 
      
 If your pass requires a previous pass to be executed (an analysis for example),
 it can use one of these methods to arrange for it to be run before your pass.
@@ -1165,11 +1176,13 @@ pass is.
 
      
 
 
-
      
-  The AnalysisUsage::addPreserved<> method
-
      
+
      
+  
+    The AnalysisUsage::addPreserved<> method
+  
+
      
 
-
      
+
      
 
      
 One of the jobs of the PassManager is to optimize how and when analyses are run.
 In particular, it attempts to avoid recomputing data unless it needs to.  For
@@ -1200,22 +1213,13 @@ the fact that it hacks on the CFG.
 
      
 
 
-
      
-  Example implementations of getAnalysisUsage
-
      
-
-
      
-
-
      -  // This is an example implementation from an analysis, which does not modify
-  // the program at all, yet has a prerequisite.
-  void PostDominanceFrontier::getAnalysisUsage(AnalysisUsage &AU) const {
-    AU.setPreservesAll();
-    AU.addRequired<PostDominatorTree>();
-  }
-
      
+
      
+  
+    Example implementations of getAnalysisUsage
+  
+
      
 
-
      and:
      
+
      
 
 
         // This example modifies the program, but does not modify the CFG
@@ -1228,12 +1232,14 @@ the fact that it hacks on the CFG.
 
      
 
 
-
      
-  The getAnalysis<> and
-getAnalysisIfAvailable<> methods
-
      
+
      
+  
+    The getAnalysis<> and
+    getAnalysisIfAvailable<> methods
+  
+
      
 
-
      
+
      
 
 
      The Pass::getAnalysis<> method is automatically inherited by
 your class, providing you with access to the passes that you declared that you
@@ -1285,13 +1291,15 @@ if it is active.  For example:
      
 
 
      
 
+
      
+
 
-
      
+
      
   Implementing Analysis Groups
-
      
+
 
 
-
      
+
      
 
 
      Now that we understand the basics of how passes are defined, how they are
 used, and how they are required from other passes, it's time to get a little bit
@@ -1310,14 +1318,12 @@ between these two extremes for other implementations).  To cleanly support
 situations like this, the LLVM Pass Infrastructure supports the notion of
 Analysis Groups.
      
 
-
      
-
 
-
      
+
      
   Analysis Group Concepts
-
      
+
 
-
      
+
      
 
 
      An Analysis Group is a single simple interface that may be implemented by
 multiple different passes.  Analysis Groups can be given human readable names
@@ -1364,11 +1370,11 @@ hypothetical example) instead.
      
 
      
 
 
-
      
+
      
   Using RegisterAnalysisGroup
-
      
+
 
-
      
+
      
 
 
      The RegisterAnalysisGroup template is used to register the analysis
 group itself, while the INITIALIZE_AG_PASS is used to add pass
@@ -1425,13 +1431,15 @@ pass is the default implementation for the interface.
      
 
 
      
 
+
      
+
 
-
      
+
      
   Pass Statistics
-
      
+
 
 
-
      
+
      
 
      The Statistic
 class is designed to be an easy way to expose various success
@@ -1443,12 +1451,12 @@ line. See the St
 
 
 
-
      
+
      
   What PassManager does
-
      
+
 
 
-
      
+
      
 
 
      The PassManager
@@ -1615,14 +1623,12 @@ Hello: main
 
      Which shows that we don't accidentally invalidate dominator information
 anymore, and therefore do not have to compute it twice.
      
 
-
      
-
 
-
      
+
      
   The releaseMemory method
-
      
+
 
-
      
+
      
 
 
         virtual void releaseMemory();
@@ -1643,13 +1649,15 @@ class, before the next call of run* in your pass.
      
 
 
      
 
+
      
+
 
-
      
+
      
   Registering dynamically loaded passes
-
      
+
 
 
-
      
+
      
 
 
      Size matters when constructing production quality tools using llvm, 
 both for the purposes of distribution, and for regulating the resident code size
@@ -1676,14 +1684,12 @@ the static destructor unregisters. Thus a pass that is statically linked
 in the tool will be registered at start up. A dynamically loaded pass will
 register on load and unregister at unload.
      
 
-
      
-
 
-
      
+
      
   Using existing registries
-
      
+
 
-
      
+
      
 
 
      There are predefined registries to track instruction scheduling
 (RegisterScheduler) and register allocation (RegisterRegAlloc)
@@ -1744,11 +1750,11 @@ call line to llvm/Codegen/LinkAllCodegenComponents.h.
      
 
 
 
-
      
+
      
   Creating new registries
-
      
+
 
-
      
+
      
 
 
      The easiest way to get started is to clone one of the existing registries; we
 recommend llvm/CodeGen/RegAllocRegistry.h.  The key things to modify
@@ -1776,13 +1782,15 @@ creator.
      
 
 
      
 
+
      
+
 
-
      
+
      
   Using GDB with dynamically loaded passes
-
      
+
 
 
-
      
+
      
 
 
      Unfortunately, using GDB with dynamically loaded passes is not as easy as it
 should be.  First of all, you can't set a breakpoint in a shared object that has
@@ -1794,14 +1802,12 @@ GDB.
      
 transformation invoked by opt, although nothing described here depends
 on that.
      
 
-
      
-
 
-
      
+
      
   Setting a breakpoint in your pass
-
      
+
 
-
      
+
      
 
 
      First thing you do is start gdb on the opt process:
      
 
@@ -1842,11 +1848,11 @@ or do other standard debugging stuff.
      
 
      
 
 
-
      
+
      
   Miscellaneous Problems
-
      
+
 
-
      
+
      
 
 
      Once you have the basics down, there are a couple of problems that GDB has,
 some with solutions, some without.
      
@@ -1874,26 +1880,26 @@ href="mailto:sabre@nondot.org">Chris.
      
 
 
      
 
+
      
+
 
-
      
+
      
   Future extensions planned
-
      
+
 
 
-
      
+
      
 
 
      Although the LLVM Pass Infrastructure is very capable as it stands, and does
 some nifty stuff, there are things we'd like to add in the future.  Here is
 where we are going:
      
 
-
      
-
 
-
      
+
      
   Multithreaded LLVM
-
      
+
 
-
      
+
      
 
 
      Multiple CPU machines are becoming more common and compilation can never be
 fast enough: obviously we should allow for a multithreaded compiler.  Because of
@@ -1911,6 +1917,8 @@ Despite that, we have kept the LLVM passes SMP ready, and you should too.
      
 
 
      
 
+
      
+
 
 
      
 
      
@@ -1920,8 +1928,8 @@ Despite that, we have kept the LLVM passes SMP ready, and you should too.
      
   src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01">
 
   Chris Lattner
      
-  The LLVM Compiler Infrastructure
      
-  Last modified: $Date: 2011-02-15 10:23:02 +0100 (Tue, 15 Feb 2011) $
+  The LLVM Compiler Infrastructure
      
+  Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
 
      
 
 
diff --git a/docs/doxygen.css b/docs/doxygen.css
index 83b049b5f1b7..80c6cad558c0 100644
--- a/docs/doxygen.css
+++ b/docs/doxygen.css
@@ -370,9 +370,39 @@ H2 {
 H3 {
  font-size: 100%;
 }
+
+H2, H3 {
+  border-bottom: 2px solid;
+  margin-top: 2em;
+}
+
 A.qindex {}
 A.qindexRef {}
 A.el { text-decoration: none; font-weight: bold }
 A.elRef { font-weight: bold }
 A.code { text-decoration: none; font-weight: normal; color: #4444ee }
 A.codeRef { font-weight: normal; color: #4444ee }
+
+div.memitem {
+  border: 1px solid #999999;
+  margin-top: 1.0em;
+  margin-bottom: 1.0em;
+  -webkit-border-radius: 0.5em;
+  -webkit-box-shadow: 3px 3px 6px #777777;
+  -moz-border-radius: 0.5em;
+  -moz-box-shadow: black 3px 3px 3px;
+}
+
+div.memproto {
+  background-color: #E3E4E5;
+  padding: 0.25em 0.5em;
+  -webkit-border-top-left-radius: 0.5em;
+  -webkit-border-top-right-radius: 0.5em;
+  -moz-border-radius-topleft: 0.5em;
+  -moz-border-radius-topright: 0.5em;
+}
+
+div.memdoc {
+  padding-left: 1em;
+  padding-right: 1em;
+}
diff --git a/docs/doxygen.footer b/docs/doxygen.footer
index d75fff5e4ccc..15585b8da733 100644
--- a/docs/doxygen.footer
+++ b/docs/doxygen.footer
@@ -1,6 +1,6 @@
 
      
 
      
-Generated on $datetime for $projectname by
+Generated on $datetime for $projectname by
 Doxygen$doxygenversion
      
 Copyright © 2003-2009 University of Illinois at Urbana-Champaign.
diff --git a/docs/index.html b/docs/index.html
index 74c39f619ea6..a25148a62d6f 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -7,13 +7,12 @@
 
 
 
-
      Documentation for the LLVM System at SVN head
      
+
      Documentation for the LLVM System at SVN head
      
 
 
      If you are using a released version of LLVM,
 see the download page to find
 your documentation.
      
 
-
      LibraryFormsDescription
      -
      -

      Written by The LLVM Team

      +

      Written by The LLVM Team

      -
      LLVM Design & Overview
      +

      LLVM Design & Overview

        @@ -57,7 +55,7 @@ frequent questions about LLVM's most frequently misunderstood instruction.
      -
      LLVM User Guides
      +

      LLVM User Guides

        @@ -75,7 +73,7 @@ LLVM for a custom language, and the facilities LLVM offers in tutorial form.Developer Policy - The LLVM project's policy towards developers and their contributions. -
      • LLVM Command Guide - A reference +
      • LLVM Command Guide - A reference manual for the LLVM command line utilities ("man" pages for LLVM tools).
        Current tools: llvm-ar, @@ -131,7 +129,7 @@ href="irc://irc.oftc.net/llvm">join #llvm on irc.oftc.net directly.
        • -
        General LLVM Programming Documentation
        +

        General LLVM Programming Documentation

          @@ -179,7 +177,7 @@ href="http://llvm.org/doxygen/inherits.html">classes)
        -
        LLVM Subsystem Documentation
        +

        LLVM Subsystem Documentation

          @@ -246,7 +244,7 @@ JITed code with GDB. -
          LLVM Mailing Lists
          +

          LLVM Mailing Lists

            @@ -286,8 +284,8 @@ times each day, making it a high volume list. Valid HTML 4.01 - LLVM Compiler Infrastructure
            - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + LLVM Compiler Infrastructure
            + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/llvm.css b/docs/llvm.css index f572b5e57141..1222cf12bcb1 100644 --- a/docs/llvm.css +++ b/docs/llvm.css @@ -23,7 +23,7 @@ th { border: 2px solid gray; font-weight: bold; font-size: 105%; * Documentation */ /* Common for title and header */ -.doc_title, .doc_section, .doc_subsection, h1, h2 { +.doc_title, .doc_section, .doc_subsection, h1, h2, h3 { color: black; background: url("img/lines.gif"); font-family: "Georgia,Palatino,Times,Roman,SanSerif"; font-weight: bold; border-width: 1px; @@ -35,17 +35,17 @@ th { border: 2px solid gray; font-weight: bold; font-size: 105%; padding-bottom: 2px } -h1, .doc_section { text-align: center; font-size: 22pt; - margin: 20pt 0pt 5pt 0pt; } +h1, .doc_title, .title { text-align: left; font-size: 25pt } -.doc_title, .title { text-align: left; font-size: 25pt } +h2, .doc_section { text-align: center; font-size: 22pt; + margin: 20pt 0pt 5pt 0pt; } -h2, .doc_subsection { width: 75%; +h3, .doc_subsection { width: 75%; text-align: left; font-size: 12pt; padding: 4pt 4pt 4pt 4pt; margin: 1.5em 0.5em 0.5em 0.5em } -h3, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em; +h4, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em; font-weight: bold; font-style: oblique; border-bottom: 1px solid #999999; font-size: 12pt; width: 75%; } @@ -70,6 +70,10 @@ h3, .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em; display: table; } +h2+div, h2+p {text-align: left; padding-left: 20pt; padding-right: 10pt;} +h3+div, h3+p {text-align: left; padding-left: 20pt; padding-right: 10pt;} +h4+div, h4+p {text-align: left; padding-left: 20pt; padding-right: 10pt;} + /* It is preferrable to use 
             everywhere instead of the
  * 
            ...
             construct.
  *
diff --git a/docs/tutorial/LangImpl1.html b/docs/tutorial/LangImpl1.html
index c256af488b7f..22a2b127b466 100644
--- a/docs/tutorial/LangImpl1.html
+++ b/docs/tutorial/LangImpl1.html
@@ -11,7 +11,7 @@
 
 
 
-
            Kaleidoscope: Tutorial Introduction and the Lexer
            
+
            Kaleidoscope: Tutorial Introduction and the Lexer
      -
      Tutorial Introduction
      +

      Tutorial Introduction

      -
      +

      Welcome to the "Implementing a language with LLVM" tutorial. This tutorial runs through the implementation of a simple language, showing how fun and @@ -123,10 +123,10 @@ languages!

      -
      The Basic Language
      +

      The Basic Language

      -
      +

      This tutorial will be illustrated with a toy language that we'll call "Kaleidoscope" (derived @@ -181,10 +181,10 @@ a Mandelbrot Set at various levels of magnification.

      -
      The Lexer
      +

      The Lexer

      -
      +

      When it comes to implementing a language, the first thing needed is the ability to process a text file and recognize what it says. The traditional @@ -341,8 +341,8 @@ so that you can use the lexer and parser together. src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl2.html b/docs/tutorial/LangImpl2.html index f39ed6ccffef..c6a9bb1ec1c3 100644 --- a/docs/tutorial/LangImpl2.html +++ b/docs/tutorial/LangImpl2.html @@ -11,7 +11,7 @@ -

      Kaleidoscope: Implementing a Parser and AST
      +

      Kaleidoscope: Implementing a Parser and AST

      -
      Chapter 2 Introduction
      +

      Chapter 2 Introduction

      -
      +

      Welcome to Chapter 2 of the "Implementing a language with LLVM" tutorial. This chapter shows you how to use the lexer, built in @@ -61,10 +61,10 @@ Tree.

      -
      The Abstract Syntax Tree (AST)
      +

      The Abstract Syntax Tree (AST)

      -
      +

      The AST for a program captures its behavior in such a way that it is easy for later stages of the compiler (e.g. code generation) to interpret. We basically @@ -178,10 +178,10 @@ bodies in Kaleidoscope.

      -
      Parser Basics
      +

      Parser Basics

      -
      +

      Now that we have an AST to build, we need to define the parser code to build it. The idea here is that we want to parse something like "x+y" (which is @@ -239,11 +239,10 @@ piece of our grammar: numeric literals.

      -
      Basic Expression - Parsing
      +

      Basic Expression Parsing

      -
      +

      We start with numeric literals, because they are the simplest to process. For each production in our grammar, we'll define a function which parses that @@ -394,11 +393,10 @@ They are a bit more complex.

      -
      Binary Expression - Parsing
      +

      Binary Expression Parsing

      -
      +

      Binary expressions are significantly harder to parse because they are often ambiguous. For example, when given the string "x+y*z", the parser can choose @@ -617,10 +615,10 @@ handle function definitions, etc.

      -
      Parsing the Rest
      +

      Parsing the Rest

      -
      +

      The next thing missing is handling of function prototypes. In Kaleidoscope, @@ -714,10 +712,10 @@ actually execute this code we've built!

      -
      The Driver
      +

      The Driver

      -
      +

      The driver for this simply invokes all of the parsing pieces with a top-level dispatch loop. There isn't much interesting here, so I'll just include the @@ -753,10 +751,10 @@ type "4+5;", and the parser will know you are done.

      -
      Conclusions
      +

      Conclusions

      -
      +

      With just under 400 lines of commented code (240 lines of non-comment, non-blank code), we fully defined our minimal language, including a lexer, @@ -790,10 +788,10 @@ Representation (IR) from the AST.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for this and the previous chapter. @@ -1226,8 +1224,8 @@ int main() { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl3.html b/docs/tutorial/LangImpl3.html index a320ff7e9064..47406ca36e41 100644 --- a/docs/tutorial/LangImpl3.html +++ b/docs/tutorial/LangImpl3.html @@ -11,7 +11,7 @@ -

      Kaleidoscope: Code generation to LLVM IR
      +

      Kaleidoscope: Code generation to LLVM IR

      -
      Chapter 3 Introduction
      +

      Chapter 3 Introduction

      -
      +

      Welcome to Chapter 3 of the "Implementing a language with LLVM" tutorial. This chapter shows you how to transform the .

      -
      Code Generation Setup
      +

      Code Generation Setup

      -
      +

      In order to generate LLVM IR, we want some simple setup to get started. First @@ -147,10 +147,10 @@ has already been done, and we'll just use it to emit code.

      -
      Expression Code Generation
      +

      Expression Code Generation

      -
      +

      Generating LLVM code for expression nodes is very straightforward: less than 45 lines of commented code for all four of our expression nodes. First @@ -293,10 +293,10 @@ basic framework.

      -
      Function Code Generation
      +

      Function Code Generation

      -
      +

      Code generation for prototypes and functions must handle a number of details, which make their code less beautiful than expression code @@ -515,11 +515,10 @@ def bar() foo(1, 2); # error, unknown function "foo"

      -
      Driver Changes and -Closing Thoughts
      +

      Driver Changes and Closing Thoughts

      -
      +

      For now, code generation to LLVM doesn't really get us much, except that we can @@ -657,10 +656,10 @@ support to this so we can actually start running code!

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1262,8 +1261,8 @@ int main() { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2011-02-15 01:24:32 +0100 (Tue, 15 Feb 2011) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl4.html b/docs/tutorial/LangImpl4.html index a2511d959e7b..5b8990e441e4 100644 --- a/docs/tutorial/LangImpl4.html +++ b/docs/tutorial/LangImpl4.html @@ -11,7 +11,7 @@ -

      Kaleidoscope: Adding JIT and Optimizer Support
      +

      Kaleidoscope: Adding JIT and Optimizer Support

      -
      Chapter 4 Introduction
      +

      Chapter 4 Introduction

      -
      +

      Welcome to Chapter 4 of the "Implementing a language with LLVM" tutorial. Chapters 1-3 described the implementation of a simple @@ -48,11 +48,10 @@ for the Kaleidoscope language.

      -
      Trivial Constant -Folding
      +

      Trivial Constant Folding

      -
      +

      Our demonstration for Chapter 3 is elegant and easy to extend. Unfortunately, @@ -134,11 +133,10 @@ range of optimizations that you can use, in the form of "passes".

      -
      LLVM Optimization - Passes
      +

      LLVM Optimization Passes

      -
      +

      LLVM provides many optimization passes, which do many different sorts of things and have different tradeoffs. Unlike other systems, LLVM doesn't hold @@ -266,10 +264,10 @@ executing it!

      -
      Adding a JIT Compiler
      +

      Adding a JIT Compiler

      -
      +

      Code that is available in LLVM IR can have a wide variety of tools applied to it. For example, you can run optimizations on it (as we did above), @@ -474,10 +472,10 @@ tackling some interesting LLVM IR issues along the way.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1078,7 +1076,7 @@ int main() { // Create the JIT. This takes ownership of the module. std::string ErrStr; - TheExecutionEngine = EngineBuilder(TheModule).setErrorStr(&ErrStr).create(); +TheExecutionEngine = EngineBuilder(TheModule).setErrorStr(&ErrStr).create(); if (!TheExecutionEngine) { fprintf(stderr, "Could not create ExecutionEngine: %s\n", ErrStr.c_str()); exit(1); @@ -1130,8 +1128,8 @@ int main() { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-11-16 18:28:22 +0100 (Tue, 16 Nov 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl5.html b/docs/tutorial/LangImpl5.html index d2c3bd03dc4e..4fc23a149429 100644 --- a/docs/tutorial/LangImpl5.html +++ b/docs/tutorial/LangImpl5.html @@ -11,7 +11,7 @@ -

      Kaleidoscope: Extending the Language: Control Flow
      +

      Kaleidoscope: Extending the Language: Control Flow

      -
      Chapter 5 Introduction
      +

      Chapter 5 Introduction

      -
      +

      Welcome to Chapter 5 of the "Implementing a language with LLVM" tutorial. Parts 1-4 described the implementation of the simple @@ -65,14 +65,14 @@ have an if/then/else expression plus a simple 'for' loop.

      -
      If/Then/Else
      +

      If/Then/Else

      -
      +

      Extending Kaleidoscope to support if/then/else is quite straightforward. It -basically requires adding lexer support for this "new" concept to the lexer, +basically requires adding support for this "new" concept to the lexer, parser, AST, and LLVM code emitter. This example is nice, because it shows how easy it is to "grow" a language over time, incrementally extending it as new ideas are discovered.

      @@ -108,15 +108,12 @@ Since Kaleidoscope allows side-effects, this behavior is important to nail down.

      Now that we know what we "want", lets break this down into its constituent pieces.

      -
      - -
      Lexer Extensions for -If/Then/Else
      +

      Lexer Extensions for If/Then/Else

      -
      +

      The lexer extensions are straightforward. First we add new enum values for the relevant tokens:

      @@ -146,11 +143,10 @@ stuff:

      -
      AST Extensions for - If/Then/Else
      +

      AST Extensions for If/Then/Else

      -
      +

      To represent the new expression we add a new AST node for it:

      @@ -172,11 +168,10 @@ public:
      -
      Parser Extensions for -If/Then/Else
      +

      Parser Extensions for If/Then/Else

      -
      +

      Now that we have the relevant tokens coming from the lexer and we have the AST node to build, our parsing logic is relatively straightforward. First we @@ -231,10 +226,10 @@ static ExprAST *ParsePrimary() {

      -
      LLVM IR for If/Then/Else
      +

      LLVM IR for If/Then/Else

      -
      +

      Now that we have it parsing and building the AST, the final piece is adding LLVM code generation support. This is the most interesting part of the @@ -347,11 +342,10 @@ directly.

      -
      Code Generation for -If/Then/Else
      +

      Code Generation for If/Then/Else

      -
      +

      In order to generate code for this, we implement the Codegen method for IfExprAST:

      @@ -472,7 +466,7 @@ are emitted, we can finish up with the merge code:

      // Emit merge block. TheFunction->getBasicBlockList().push_back(MergeBB); Builder.SetInsertPoint(MergeBB); - PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), + PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, "iftmp"); PN->addIncoming(ThenV, ThenBB); @@ -500,11 +494,13 @@ another useful expression that is familiar from non-functional languages...

      +
      + -
      'for' Loop Expression
      +

      'for' Loop Expression

      -
      +

      Now that we know how to add basic control flow constructs to the language, we have the tools to add more powerful things. Lets add something more @@ -533,14 +529,11 @@ variables, it will get more useful.

      As before, lets talk about the changes that we need to Kaleidoscope to support this.

      -
      - -
      Lexer Extensions for -the 'for' Loop
      +

      Lexer Extensions for the 'for' Loop

      -
      +

      The lexer extensions are the same sort of thing as for if/then/else:

      @@ -566,11 +559,10 @@ the 'for' Loop
      -
      AST Extensions for -the 'for' Loop
      +

      AST Extensions for the 'for' Loop

      -
      +

      The AST node is just as simple. It basically boils down to capturing the variable name and the constituent expressions in the node.

      @@ -593,11 +585,10 @@ public:
      -
      Parser Extensions for -the 'for' Loop
      +

      Parser Extensions for the 'for' Loop

      -
      +

      The parser code is also fairly standard. The only interesting thing here is handling of the optional step value. The parser code handles it by checking to @@ -653,11 +644,10 @@ static ExprAST *ParseForExpr() {

      -
      LLVM IR for -the 'for' Loop
      +

      LLVM IR for the 'for' Loop

      -
      +

      Now we get to the good part: the LLVM IR we want to generate for this thing. With the simple example above, we get this LLVM IR (note that this dump is @@ -699,11 +689,10 @@ expressions, and some basic blocks. Lets see how this fits together.

      -
      Code Generation for -the 'for' Loop
      +

      Code Generation for the 'for' Loop

      -
      +

      The first part of Codegen is very simple: we just output the start expression for the loop value:

      @@ -746,7 +735,7 @@ create an unconditional branch for the fall-through between the two blocks.

      Builder.SetInsertPoint(LoopBB); // Start the PHI node with an entry for Start. - PHINode *Variable = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), VarName.c_str()); + PHINode *Variable = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, VarName.c_str()); Variable->addIncoming(StartVal, PreheaderBB);
      @@ -876,11 +865,13 @@ language.

      +
      + -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1452,7 +1443,7 @@ Value *IfExprAST::Codegen() { // Emit merge block. TheFunction->getBasicBlockList().push_back(MergeBB); Builder.SetInsertPoint(MergeBB); - PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), + PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, "iftmp"); PN->addIncoming(ThenV, ThenBB); @@ -1494,7 +1485,7 @@ Value *ForExprAST::Codegen() { Builder.SetInsertPoint(LoopBB); // Start the PHI node with an entry for Start. - PHINode *Variable = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), VarName.c_str()); + PHINode *Variable = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, VarName.c_str()); Variable->addIncoming(StartVal, PreheaderBB); // Within the loop, the variable is defined equal to the PHI node. If it @@ -1721,7 +1712,7 @@ int main() { // Create the JIT. This takes ownership of the module. std::string ErrStr; - TheExecutionEngine = EngineBuilder(TheModule).setErrorStr(&ErrStr).create(); + TheExecutionEngine = EngineBuilder(TheModule).setErrorStr(&ErrStr).create(); if (!TheExecutionEngine) { fprintf(stderr, "Could not create ExecutionEngine: %s\n", ErrStr.c_str()); exit(1); @@ -1773,8 +1764,8 @@ int main() { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-11-16 18:28:22 +0100 (Tue, 16 Nov 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl6.html b/docs/tutorial/LangImpl6.html index 7ddf3a099cbc..31d7ff4cd215 100644 --- a/docs/tutorial/LangImpl6.html +++ b/docs/tutorial/LangImpl6.html @@ -11,7 +11,7 @@ -

      Kaleidoscope: Extending the Language: User-defined Operators
      +

      Kaleidoscope: Extending the Language: User-defined Operators

      -
      Chapter 6 Introduction
      +

      Chapter 6 Introduction

      -
      +

      Welcome to Chapter 6 of the "Implementing a language with LLVM" tutorial. At this point in our tutorial, we now have a fully @@ -60,10 +60,10 @@ an example of what you can build with Kaleidoscope and its feature set.

      -
      User-defined Operators: the Idea
      +

      User-defined Operators: the Idea

      -
      +

      The "operator overloading" that we will add to Kaleidoscope is more general than @@ -125,10 +125,10 @@ operators.

      -
      User-defined Binary Operators
      +

      User-defined Binary Operators

      -
      +

      Adding support for user-defined binary operators is pretty simple with our current framework. We'll first add support for the unary/binary keywords:

      @@ -342,10 +342,10 @@ see what it takes.

      -
      User-defined Unary Operators
      +

      User-defined Unary Operators

      -
      +

      Since we don't currently support unary operators in the Kaleidoscope language, we'll need to add everything to support them. Above, we added simple @@ -491,10 +491,10 @@ is simpler primarily because it doesn't need to handle any predefined operators.

      -
      Kicking the Tires
      +

      Kicking the Tires

      -
      +

      It is somewhat hard to believe, but with a few simple extensions we've covered in the last chapters, we have grown a real-ish language. With this, we @@ -796,10 +796,10 @@ add variable mutation without building SSA in your front-end.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1475,7 +1475,7 @@ Value *IfExprAST::Codegen() { // Emit merge block. TheFunction->getBasicBlockList().push_back(MergeBB); Builder.SetInsertPoint(MergeBB); - PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), + PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, "iftmp"); PN->addIncoming(ThenV, ThenBB); @@ -1517,7 +1517,7 @@ Value *ForExprAST::Codegen() { Builder.SetInsertPoint(LoopBB); // Start the PHI node with an entry for Start. - PHINode *Variable = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), VarName.c_str()); + PHINode *Variable = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, VarName.c_str()); Variable->addIncoming(StartVal, PreheaderBB); // Within the loop, the variable is defined equal to the PHI node. If it @@ -1758,7 +1758,7 @@ int main() { // Create the JIT. This takes ownership of the module. std::string ErrStr; - TheExecutionEngine = EngineBuilder(TheModule).setErrorStr(&ErrStr).create(); + TheExecutionEngine = EngineBuilder(TheModule).setErrorStr(&ErrStr).create(); if (!TheExecutionEngine) { fprintf(stderr, "Could not create ExecutionEngine: %s\n", ErrStr.c_str()); exit(1); @@ -1810,8 +1810,8 @@ int main() { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-11-16 18:28:22 +0100 (Tue, 16 Nov 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl7.html b/docs/tutorial/LangImpl7.html index 3b36129d6716..a4a21f1aed22 100644 --- a/docs/tutorial/LangImpl7.html +++ b/docs/tutorial/LangImpl7.html @@ -12,7 +12,7 @@ -

      Kaleidoscope: Extending the Language: Mutable Variables
      +

      Kaleidoscope: Extending the Language: Mutable Variables

      -
      Chapter 7 Introduction
      +

      Chapter 7 Introduction

      -
      +

      Welcome to Chapter 7 of the "Implementing a language with LLVM" tutorial. In chapters 1 through 6, we've built a very @@ -66,10 +66,10 @@ support for this, though the way it works is a bit unexpected for some.

      -
      Why is this a hard problem?
      +

      Why is this a hard problem?

      -
      +

      To understand why mutable variables cause complexities in SSA construction, @@ -140,10 +140,10 @@ logic.

      -
      Memory in LLVM
      +

      Memory in LLVM

      -
      +

      The 'trick' here is that while LLVM does require all register values to be in SSA form, it does not require (or permit) memory objects to be in SSA form. @@ -321,11 +321,10 @@ variables now!

      -
      Mutable Variables in -Kaleidoscope
      +

      Mutable Variables in Kaleidoscope

      -
      +

      Now that we know the sort of problem we want to tackle, lets see what this looks like in the context of our little Kaleidoscope language. We're going to @@ -378,11 +377,10 @@ Kaleidoscope to support new variable definitions.

      -
      Adjusting Existing Variables for -Mutation
      +

      Adjusting Existing Variables for Mutation

      -
      +

      The symbol table in Kaleidoscope is managed at code generation time by the @@ -648,10 +646,10 @@ we'll add the assignment operator.

      -
      New Assignment Operator
      +

      New Assignment Operator

      -
      +

      With our current framework, adding a new assignment operator is really simple. We will parse it just like any other binary operator, but handle it @@ -745,11 +743,10 @@ add this next!

      -
      User-defined Local -Variables
      +

      User-defined Local Variables

      -
      +

      Adding var/in is just like any other other extensions we made to Kaleidoscope: we extend the lexer, the parser, the AST and the code generator. @@ -979,10 +976,10 @@ anywhere in sight.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with mutable @@ -1755,7 +1752,7 @@ Value *IfExprAST::Codegen() { // Emit merge block. TheFunction->getBasicBlockList().push_back(MergeBB); Builder.SetInsertPoint(MergeBB); - PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), + PHINode *PN = Builder.CreatePHI(Type::getDoubleTy(getGlobalContext()), 2, "iftmp"); PN->addIncoming(ThenV, ThenBB); @@ -2160,8 +2157,8 @@ int main() { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-11-16 18:28:22 +0100 (Tue, 16 Nov 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/LangImpl8.html b/docs/tutorial/LangImpl8.html index fe42a22e0304..cc55d401a4c7 100644 --- a/docs/tutorial/LangImpl8.html +++ b/docs/tutorial/LangImpl8.html @@ -11,8 +11,7 @@ -

      Kaleidoscope: Conclusion and other useful LLVM - tidbits
      +

      Kaleidoscope: Conclusion and other useful LLVM tidbits

      -
      Tutorial Conclusion
      +

      Tutorial Conclusion

      -
      +

      Welcome to the the final chapter of the "Implementing a language with LLVM" tutorial. In the course of this tutorial, we have grown @@ -154,23 +153,19 @@ are very useful if you want to take advantage of LLVM's capabilities.

      -
      Properties of the LLVM -IR
      +

      Properties of the LLVM IR

      -
      +

      We have a couple common questions about code in the LLVM IR form - lets just get these out of the way right now, shall we?

      -
      - -
      Target -Independence
      +

      Target Independence

      -
      +

      Kaleidoscope is an example of a "portable language": any program written in Kaleidoscope will work the same way on any target that it runs on. Many other @@ -221,10 +216,10 @@ in-kernel language.

      -
      Safety Guarantees
      +

      Safety Guarantees

      -
      +

      Many of the languages above are also "safe" languages: it is impossible for a program written in Java to corrupt its address space and crash the process @@ -243,11 +238,10 @@ list if you are interested in more details.

      -
      Language-Specific -Optimizations
      +

      Language-Specific Optimizations

      -
      +

      One thing about LLVM that turns off many people is that it does not solve all the world's problems in one system (sorry 'world hunger', someone else will have @@ -297,24 +291,23 @@ language-specific AST.

      +
      + -
      Tips and Tricks
      +

      Tips and Tricks

      -
      +

      There is a variety of useful tips and tricks that you come to know after working on/with LLVM that aren't obvious at first glance. Instead of letting everyone rediscover them, this section talks about some of these issues.

      -
      - -
      Implementing portable -offsetof/sizeof
      +

      Implementing portable offsetof/sizeof

      -
      +

      One interesting thing that comes up, if you are trying to keep the code generated by your compiler "target independent", is that you often need to know @@ -331,11 +324,10 @@ in a portable way.

      -
      Garbage Collected -Stack Frames
      +

      Garbage Collected Stack Frames

      -
      +

      Some languages want to explicitly manage their stack frames, often so that they are garbage collected or to allow easy implementation of closures. There @@ -349,6 +341,8 @@ Passing Style and the use of tail calls (which LLVM also supports).

      +
      +
      @@ -358,8 +352,8 @@ Passing Style and the use of tail calls (which LLVM also supports).

      src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $
      diff --git a/docs/tutorial/OCamlLangImpl1.html b/docs/tutorial/OCamlLangImpl1.html index 44106132fbe8..7cae68c988ab 100644 --- a/docs/tutorial/OCamlLangImpl1.html +++ b/docs/tutorial/OCamlLangImpl1.html @@ -12,7 +12,7 @@ -
      Kaleidoscope: Tutorial Introduction and the Lexer
      +

      Kaleidoscope: Tutorial Introduction and the Lexer

      -
      Tutorial Introduction
      +

      Tutorial Introduction

      -
      +

      Welcome to the "Implementing a language with LLVM" tutorial. This tutorial runs through the implementation of a simple language, showing how fun and @@ -130,10 +130,10 @@ languages!

      -
      The Basic Language
      +

      The Basic Language

      -
      +

      This tutorial will be illustrated with a toy language that we'll call "Kaleidoscope" (derived @@ -188,10 +188,10 @@ a Mandelbrot Set at various levels of magnification.

      -
      The Lexer
      +

      The Lexer

      -
      +

      When it comes to implementing a language, the first thing needed is the ability to process a text file and recognize what it says. The traditional @@ -358,8 +358,8 @@ include a driver so that you can use the lexer and parser together. Chris Lattner
      Erick Tryzelaar
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl2.html b/docs/tutorial/OCamlLangImpl2.html index 41d0956e4620..e1bb87122506 100644 --- a/docs/tutorial/OCamlLangImpl2.html +++ b/docs/tutorial/OCamlLangImpl2.html @@ -12,7 +12,7 @@ -

      Kaleidoscope: Implementing a Parser and AST
      +

      Kaleidoscope: Implementing a Parser and AST

      -
      Chapter 2 Introduction
      +

      Chapter 2 Introduction

      -
      +

      Welcome to Chapter 2 of the "Implementing a language with LLVM in Objective Caml" tutorial. This chapter shows you how to use @@ -65,10 +65,10 @@ Tree.

      -
      The Abstract Syntax Tree (AST)
      +

      The Abstract Syntax Tree (AST)

      -
      +

      The AST for a program captures its behavior in such a way that it is easy for later stages of the compiler (e.g. code generation) to interpret. We basically @@ -146,10 +146,10 @@ bodies in Kaleidoscope.

      -
      Parser Basics
      +

      Parser Basics

      -
      +

      Now that we have an AST to build, we need to define the parser code to build it. The idea here is that we want to parse something like "x+y" (which is @@ -181,11 +181,10 @@ piece of our grammar: numeric literals.

      -
      Basic Expression - Parsing
      +

      Basic Expression Parsing

      -
      +

      We start with numeric literals, because they are the simplest to process. For each production in our grammar, we'll define a function which parses that @@ -303,11 +302,10 @@ They are a bit more complex.

      -
      Binary Expression - Parsing
      +

      Binary Expression Parsing

      -
      +

      Binary expressions are significantly harder to parse because they are often ambiguous. For example, when given the string "x+y*z", the parser can choose @@ -517,10 +515,10 @@ handle function definitions, etc.

      -
      Parsing the Rest
      +

      Parsing the Rest

      -
      +

      The next thing missing is handling of function prototypes. In Kaleidoscope, @@ -596,10 +594,10 @@ actually execute this code we've built!

      -
      The Driver
      +

      The Driver

      -
      +

      The driver for this simply invokes all of the parsing pieces with a top-level dispatch loop. There isn't much interesting here, so I'll just include the @@ -652,10 +650,10 @@ type "4+5;", and the parser will know you are done.

      -
      Conclusions
      +

      Conclusions

      -
      +

      With just under 300 lines of commented code (240 lines of non-comment, non-blank code), we fully defined our minimal language, including a lexer, @@ -689,10 +687,10 @@ Representation (IR) from the AST.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for this and the previous chapter. @@ -1038,8 +1036,8 @@ main () Chris Lattner Erick Tryzelaar
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-07 02:28:04 +0200 (Fri, 07 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl3.html b/docs/tutorial/OCamlLangImpl3.html index c7c53709a060..e52bb6c9008d 100644 --- a/docs/tutorial/OCamlLangImpl3.html +++ b/docs/tutorial/OCamlLangImpl3.html @@ -12,7 +12,7 @@ -

      Kaleidoscope: Code generation to LLVM IR
      +

      Kaleidoscope: Code generation to LLVM IR

      -
      Chapter 3 Introduction
      +

      Chapter 3 Introduction

      -
      +

      Welcome to Chapter 3 of the "Implementing a language with LLVM" tutorial. This chapter shows you how to transform the

      -
      Code Generation Setup
      +

      Code Generation Setup

      -
      +

      In order to generate LLVM IR, we want some simple setup to get started. First @@ -128,10 +128,10 @@ that this has already been done, and we'll just use it to emit code.

      -
      Expression Code Generation
      +

      Expression Code Generation

      -
      +

      Generating LLVM code for expression nodes is very straightforward: less than 30 lines of commented code for all four of our expression nodes. First @@ -263,10 +263,10 @@ basic framework.

      -
      Function Code Generation
      +

      Function Code Generation

      -
      +

      Code generation for prototypes and functions must handle a number of details, which make their code less beautiful than expression code @@ -466,11 +466,10 @@ def bar() foo(1, 2); # error, unknown function "foo"

      -
      Driver Changes and -Closing Thoughts
      +

      Driver Changes and Closing Thoughts

      -
      +

      For now, code generation to LLVM doesn't really get us much, except that we can @@ -607,10 +606,10 @@ support to this so we can actually start running code!

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1086,8 +1085,8 @@ main () Chris Lattner
      Erick Tryzelaar
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-28 19:07:41 +0200 (Fri, 28 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl4.html b/docs/tutorial/OCamlLangImpl4.html index a86184c94520..db164d5e6a1a 100644 --- a/docs/tutorial/OCamlLangImpl4.html +++ b/docs/tutorial/OCamlLangImpl4.html @@ -12,7 +12,7 @@ -

      Kaleidoscope: Adding JIT and Optimizer Support
      +

      Kaleidoscope: Adding JIT and Optimizer Support

      -
      Chapter 4 Introduction
      +

      Chapter 4 Introduction

      -
      +

      Welcome to Chapter 4 of the "Implementing a language with LLVM" tutorial. Chapters 1-3 described the implementation of a simple @@ -52,11 +52,10 @@ for the Kaleidoscope language.

      -
      Trivial Constant -Folding
      +

      Trivial Constant Folding

      -
      +

      Note: the default IRBuilder now always includes the constant folding optimisations below.

      @@ -148,11 +147,10 @@ range of optimizations that you can use, in the form of "passes".

      -
      LLVM Optimization - Passes
      +

      LLVM Optimization Passes

      -
      +

      LLVM provides many optimization passes, which do many different sorts of things and have different tradeoffs. Unlike other systems, LLVM doesn't hold @@ -283,10 +281,10 @@ executing it!

      -
      Adding a JIT Compiler
      +

      Adding a JIT Compiler

      -
      +

      Code that is available in LLVM IR can have a wide variety of tools applied to it. For example, you can run optimizations on it (as we did above), @@ -486,10 +484,10 @@ constructs, tackling some interesting LLVM IR issues along the way.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1022,8 +1020,8 @@ extern double putchard(double X) { Chris Lattner
      Erick Tryzelaar
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-28 19:07:41 +0200 (Fri, 28 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl5.html b/docs/tutorial/OCamlLangImpl5.html index 3173803cfa6b..ca796916ef14 100644 --- a/docs/tutorial/OCamlLangImpl5.html +++ b/docs/tutorial/OCamlLangImpl5.html @@ -12,7 +12,7 @@ -

      Kaleidoscope: Extending the Language: Control Flow
      +

      Kaleidoscope: Extending the Language: Control Flow

      -
      Chapter 5 Introduction
      +

      Chapter 5 Introduction

      -
      +

      Welcome to Chapter 5 of the "Implementing a language with LLVM" tutorial. Parts 1-4 described the implementation of the simple @@ -69,10 +69,10 @@ have an if/then/else expression plus a simple 'for' loop.

      -
      If/Then/Else
      +

      If/Then/Else

      -
      +

      Extending Kaleidoscope to support if/then/else is quite straightforward. It @@ -112,15 +112,12 @@ Since Kaleidoscope allows side-effects, this behavior is important to nail down.

      Now that we know what we "want", lets break this down into its constituent pieces.

      -
      - -
      Lexer Extensions for -If/Then/Else
      +

      Lexer Extensions for If/Then/Else

      -
      +

      The lexer extensions are straightforward. First we add new variants for the relevant tokens:

      @@ -153,11 +150,10 @@ stuff:

      -
      AST Extensions for - If/Then/Else
      +

      AST Extensions for If/Then/Else

      -
      +

      To represent the new expression we add a new AST variant for it:

      @@ -175,11 +171,10 @@ type expr =
      -
      Parser Extensions for -If/Then/Else
      +

      Parser Extensions for If/Then/Else

      -
      +

      Now that we have the relevant tokens coming from the lexer and we have the AST node to build, our parsing logic is relatively straightforward. First we @@ -214,10 +209,10 @@ let rec parse_primary = parser

      -
      LLVM IR for If/Then/Else
      +

      LLVM IR for If/Then/Else

      -
      +

      Now that we have it parsing and building the AST, the final piece is adding LLVM code generation support. This is the most interesting part of the @@ -331,11 +326,10 @@ directly.

      -
      Code Generation for -If/Then/Else
      +

      Code Generation for If/Then/Else

      -
      +

      In order to generate code for this, we implement the Codegen method for IfExprAST:

      @@ -492,11 +486,13 @@ another useful expression that is familiar from non-functional languages...

      +
      + -
      'for' Loop Expression
      +

      'for' Loop Expression

      -
      +

      Now that we know how to add basic control flow constructs to the language, we have the tools to add more powerful things. Lets add something more @@ -525,14 +521,11 @@ variables, it will get more useful.

      As before, lets talk about the changes that we need to Kaleidoscope to support this.

      -
      - -
      Lexer Extensions for -the 'for' Loop
      +

      Lexer Extensions for the 'for' Loop

      -
      +

      The lexer extensions are the same sort of thing as for if/then/else:

      @@ -559,11 +552,10 @@ the 'for' Loop
      -
      AST Extensions for -the 'for' Loop
      +

      AST Extensions for the 'for' Loop

      -
      +

      The AST variant is just as simple. It basically boils down to capturing the variable name and the constituent expressions in the node.

      @@ -580,11 +572,10 @@ type expr =
      -
      Parser Extensions for -the 'for' Loop
      +

      Parser Extensions for the 'for' Loop

      -
      +

      The parser code is also fairly standard. The only interesting thing here is handling of the optional step value. The parser code handles it by checking to @@ -628,11 +619,10 @@ let rec parse_primary = parser

      -
      LLVM IR for -the 'for' Loop
      +

      LLVM IR for the 'for' Loop

      -
      +

      Now we get to the good part: the LLVM IR we want to generate for this thing. With the simple example above, we get this LLVM IR (note that this dump is @@ -674,11 +664,10 @@ expressions, and some basic blocks. Lets see how this fits together.

      -
      Code Generation for -the 'for' Loop
      +

      Code Generation for the 'for' Loop

      -
      +

      The first part of Codegen is very simple: we just output the start expression for the loop value:

      @@ -851,11 +840,13 @@ to our poor innocent language.

      +
      + -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1562,8 +1553,8 @@ operators Chris Lattner
      Erick Tryzelaar
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-05-28 19:07:41 +0200 (Fri, 28 May 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl6.html b/docs/tutorial/OCamlLangImpl6.html index 1d4f8c7509f8..bde429b5afcf 100644 --- a/docs/tutorial/OCamlLangImpl6.html +++ b/docs/tutorial/OCamlLangImpl6.html @@ -12,7 +12,7 @@ -

      Kaleidoscope: Extending the Language: User-defined Operators
      +

      Kaleidoscope: Extending the Language: User-defined Operators

      -
      Chapter 6 Introduction
      +

      Chapter 6 Introduction

      -
      +

      Welcome to Chapter 6 of the "Implementing a language with LLVM" tutorial. At this point in our tutorial, we now have a fully @@ -64,10 +64,10 @@ an example of what you can build with Kaleidoscope and its feature set.

      -
      User-defined Operators: the Idea
      +

      User-defined Operators: the Idea

      -
      +

      The "operator overloading" that we will add to Kaleidoscope is more general than @@ -129,10 +129,10 @@ operators.

      -
      User-defined Binary Operators
      +

      User-defined Binary Operators

      -
      +

      Adding support for user-defined binary operators is pretty simple with our current framework. We'll first add support for the unary/binary keywords:

      @@ -320,10 +320,10 @@ see what it takes.

      -
      User-defined Unary Operators
      +

      User-defined Unary Operators

      -
      +

      Since we don't currently support unary operators in the Kaleidoscope language, we'll need to add everything to support them. Above, we added simple @@ -472,10 +472,10 @@ is simpler primarily because it doesn't need to handle any predefined operators.

      -
      Kicking the Tires
      +

      Kicking the Tires

      -
      +

      It is somewhat hard to believe, but with a few simple extensions we've covered in the last chapters, we have grown a real-ish language. With this, we @@ -778,10 +778,10 @@ add variable mutation without building SSA in your front-end.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with the @@ -1567,8 +1567,8 @@ SSA construction Chris Lattner
      Erick Tryzelaar
      - The LLVM Compiler Infrastructure
      - Last modified: $Date: 2010-06-21 22:31:30 +0200 (Mon, 21 Jun 2010) $ + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl7.html b/docs/tutorial/OCamlLangImpl7.html index a9fcd704cf8b..a48e679cecef 100644 --- a/docs/tutorial/OCamlLangImpl7.html +++ b/docs/tutorial/OCamlLangImpl7.html @@ -13,7 +13,7 @@ -

      Kaleidoscope: Extending the Language: Mutable Variables
      +

      Kaleidoscope: Extending the Language: Mutable Variables

      -
      Chapter 7 Introduction
      +

      Chapter 7 Introduction

      -
      +

      Welcome to Chapter 7 of the "Implementing a language with LLVM" tutorial. In chapters 1 through 6, we've built a very @@ -70,10 +70,10 @@ support for this, though the way it works is a bit unexpected for some.

      -
      Why is this a hard problem?
      +

      Why is this a hard problem?

      -
      +

      To understand why mutable variables cause complexities in SSA construction, @@ -144,10 +144,10 @@ logic.

      -
      Memory in LLVM
      +

      Memory in LLVM

      -
      +

      The 'trick' here is that while LLVM does require all register values to be in SSA form, it does not require (or permit) memory objects to be in SSA form. @@ -325,11 +325,10 @@ variables now!

      -
      Mutable Variables in -Kaleidoscope
      +

      Mutable Variables in Kaleidoscope

      -
      +

      Now that we know the sort of problem we want to tackle, lets see what this looks like in the context of our little Kaleidoscope language. We're going to @@ -382,11 +381,10 @@ Kaleidoscope to support new variable definitions.

      -
      Adjusting Existing Variables for -Mutation
      +

      Adjusting Existing Variables for Mutation

      -
      +

      The symbol table in Kaleidoscope is managed at code generation time by the @@ -672,10 +670,10 @@ we'll add the assignment operator.

      -
      New Assignment Operator
      +

      New Assignment Operator

      -
      +

      With our current framework, adding a new assignment operator is really simple. We will parse it just like any other binary operator, but handle it @@ -773,11 +771,10 @@ add this next!

      -
      User-defined Local -Variables
      +

      User-defined Local Variables

      -
      +

      Adding var/in is just like any other other extensions we made to Kaleidoscope: we extend the lexer, the parser, the AST and the code generator. @@ -956,10 +953,10 @@ anywhere in sight.

      -
      Full Code Listing
      +

      Full Code Listing

      -
      +

      Here is the complete code listing for our running example, enhanced with mutable @@ -1887,7 +1884,7 @@ extern double printd(double X) { -Next: Conclusion and other useful LLVM tidbits +Next: Conclusion and other useful LLVM tidbits

      @@ -1899,9 +1896,9 @@ extern double printd(double X) { src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      + The LLVM Compiler Infrastructure
      Erick Tryzelaar
      - Last modified: $Date: 2011-01-01 04:27:43 +0100 (Sat, 01 Jan 2011) $ + Last modified: $Date: 2011-04-23 02:30:22 +0200 (Sat, 23 Apr 2011) $ diff --git a/docs/tutorial/OCamlLangImpl8.html b/docs/tutorial/OCamlLangImpl8.html index 64a62002c4cc..eed8c03d21ca 100644 --- a/docs/tutorial/OCamlLangImpl8.html +++ b/docs/tutorial/OCamlLangImpl8.html @@ -11,8 +11,7 @@ -
      Kaleidoscope: Conclusion and other useful LLVM - tidbits
      +

      Kaleidoscope: Conclusion and other useful LLVM tidbits

      -
      Tutorial Conclusion
      +

      Tutorial Conclusion

      -
      +

      Welcome to the the final chapter of the "Implementing a language with LLVM" tutorial. In the course of this tutorial, we have grown @@ -154,23 +153,19 @@ are very useful if you want to take advantage of LLVM's capabilities.

      -
      Properties of the LLVM -IR
      +

      Properties of the LLVM IR

      -
      +

      We have a couple common questions about code in the LLVM IR form - lets just get these out of the way right now, shall we?

      -
      - -
      Target -Independence
      +

      Target Independence

      -
      +

      Kaleidoscope is an example of a "portable language": any program written in Kaleidoscope will work the same way on any target that it runs on. Many other @@ -221,10 +216,10 @@ in-kernel language.

      -
      Safety Guarantees
      +

      Safety Guarantees

      -
      +

      Many of the languages above are also "safe" languages: it is impossible for a program written in Java to corrupt its address space and crash the process @@ -243,11 +238,10 @@ list if you are interested in more details.

      -
      Language-Specific -Optimizations
      +

      Language-Specific Optimizations

      -
      +

      One thing about LLVM that turns off many people is that it does not solve all the world's problems in one system (sorry 'world hunger', someone else will have @@ -297,24 +291,23 @@ language-specific AST.

      +
      + -
      Tips and Tricks
      +

      Tips and Tricks

      -
      +

      There is a variety of useful tips and tricks that you come to know after working on/with LLVM that aren't obvious at first glance. Instead of letting everyone rediscover them, this section talks about some of these issues.

      -
      - -
      Implementing portable -offsetof/sizeof
      +

      Implementing portable offsetof/sizeof

      -
      +

      One interesting thing that comes up, if you are trying to keep the code generated by your compiler "target independent", is that you often need to know @@ -331,11 +324,10 @@ in a portable way.

      -
      Garbage Collected -Stack Frames
      +

      Garbage Collected Stack Frames

      -
      +

      Some languages want to explicitly manage their stack frames, often so that they are garbage collected or to allow easy implementation of closures. There @@ -349,6 +341,8 @@ Passing Style and the use of tail calls (which LLVM also supports).

      +
      +
      @@ -358,7 +352,7 @@ Passing Style and the use of tail calls (which LLVM also supports).

      src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!"> Chris Lattner
      - The LLVM Compiler Infrastructure
      + The LLVM Compiler Infrastructure
      Last modified: $Date$
      diff --git a/docs/tutorial/index.html b/docs/tutorial/index.html index 11dd5e2d732a..0a8cae2c2c9b 100644 --- a/docs/tutorial/index.html +++ b/docs/tutorial/index.html @@ -12,7 +12,7 @@ -
      LLVM Tutorial: Table of Contents
      +

      LLVM Tutorial: Table of Contents

      1. Kaleidoscope: Implementing a Language with LLVM -- cgit v1.3