From lattner at cs.uiuc.edu Mon Mar 15 00:01:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:01:02 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/GCSE/call_pure_function.ll Message-ID: <200403150418.WAA23119@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/GCSE: call_pure_function.ll added (r1.1) --- Log message: Make sure that pure calls don't kill loads --- Diffs of the changes: (+13 -0) Index: llvm/test/Regression/Transforms/GCSE/call_pure_function.ll diff -c /dev/null llvm/test/Regression/Transforms/GCSE/call_pure_function.ll:1.1 *** /dev/null Sun Mar 14 22:18:03 2004 --- llvm/test/Regression/Transforms/GCSE/call_pure_function.ll Sun Mar 14 22:17:53 2004 *************** *** 0 **** --- 1,13 ---- + ; RUN: llvm-as < %s | opt -basicaa -load-vn -gcse -instcombine | llvm-dis | not grep sub + declare int %strlen(sbyte*) + declare void %use(int %X) + + sbyte %test(sbyte* %P, sbyte* %Q) { + %A = load sbyte* %Q + %X = call int %strlen(sbyte* %P) + %B = load sbyte* %Q ;; CSE with A. + call void %use(int %X) ;; make strlen not dead + + %C = sub sbyte %A, %B + ret sbyte %C + } From lattner at cs.uiuc.edu Mon Mar 15 00:01:04 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:01:04 2004 Subject: [llvm-commits] CVS: llvm/lib/Analysis/BasicAliasAnalysis.cpp Message-ID: <200403150418.WAA23130@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: BasicAliasAnalysis.cpp updated: 1.33 -> 1.34 --- Log message: Fix a minor bug, implementing GCSE/call_pure_function.ll Also, add some stuff I missed before. --- Diffs of the changes: (+6 -3) Index: llvm/lib/Analysis/BasicAliasAnalysis.cpp diff -u llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.33 llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.34 --- llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.33 Sun Mar 14 21:36:49 2004 +++ llvm/lib/Analysis/BasicAliasAnalysis.cpp Sun Mar 14 22:18:28 2004 @@ -186,9 +186,8 @@ return NoModRef; } - // If P points to a constant memory location, the call definitely could not - // modify the memory location. - return pointsToConstantMemory(P) ? Ref : ModRef; + // The AliasAnalysis base class has some smarts, lets use them. + return AliasAnalysis::getModRefInfo(CS, P, Size); } // alias - Provide a bunch of ad-hoc rules to disambiguate in common cases, such @@ -597,11 +596,15 @@ "sin", "sinf", "sinl", "sinh", "sinhf", "sinhl", "tan", "tanf", "tanl", "tanh", "tanhf", "tanhl", + // ctype.h "isalnum", "isalpha", "iscntrl", "isdigit", "isgraph", "islower", "isprint" "ispunct", "isspace", "isupper", "isxdigit", "tolower", "toupper", + // wctype.h" "iswalnum", "iswalpha", "iswcntrl", "iswdigit", "iswgraph", "iswlower", "iswprint", "iswpunct", "iswspace", "iswupper", "iswxdigit", + + "iswctype", "towctrans", "towlower", "towupper", "btowc", "wctob", }; From lattner at cs.uiuc.edu Mon Mar 15 00:01:18 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:01:18 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/GCSE/call_cse.ll Message-ID: <200403150544.XAA25230@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/GCSE: call_cse.ll added (r1.1) --- Log message: New testcase for CSE of call instructions --- Diffs of the changes: (+11 -0) Index: llvm/test/Regression/Transforms/GCSE/call_cse.ll diff -c /dev/null llvm/test/Regression/Transforms/GCSE/call_cse.ll:1.1 *** /dev/null Sun Mar 14 23:44:39 2004 --- llvm/test/Regression/Transforms/GCSE/call_cse.ll Sun Mar 14 23:44:29 2004 *************** *** 0 **** --- 1,11 ---- + ; RUN: llvm-as < %s | opt -basicaa -load-vn -gcse -instcombine | llvm-dis | not grep sub + declare int %strlen(sbyte*) + + int %test(sbyte* %P) { + %X = call int %strlen(sbyte* %P) + %A = add int %X, 14 + %Y = call int %strlen(sbyte* %P) + %Z = sub int %X, %Y + %B = add int %A, %Z + ret int %B + } From lattner at cs.uiuc.edu Mon Mar 15 00:01:19 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:01:19 2004 Subject: [llvm-commits] CVS: llvm/lib/Analysis/LoadValueNumbering.cpp Message-ID: <200403150545.XAA25245@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: LoadValueNumbering.cpp updated: 1.15 -> 1.16 --- Log message: Implement CSE of call instructions in the most trivial case. This implements GCSE/call_cse.ll --- Diffs of the changes: (+139 -11) Index: llvm/lib/Analysis/LoadValueNumbering.cpp diff -u llvm/lib/Analysis/LoadValueNumbering.cpp:1.15 llvm/lib/Analysis/LoadValueNumbering.cpp:1.16 --- llvm/lib/Analysis/LoadValueNumbering.cpp:1.15 Thu Feb 5 11:20:00 2004 +++ llvm/lib/Analysis/LoadValueNumbering.cpp Sun Mar 14 23:44:59 2004 @@ -7,27 +7,31 @@ // //===----------------------------------------------------------------------===// // -// This file implements a value numbering pass that value #'s load instructions. -// To do this, it finds lexically identical load instructions, and uses alias -// analysis to determine which loads are guaranteed to produce the same value. +// This file implements a value numbering pass that value numbers load and call +// instructions. To do this, it finds lexically identical load instructions, +// and uses alias analysis to determine which loads are guaranteed to produce +// the same value. To value number call instructions, it looks for calls to +// functions that do not write to memory which do not have intervening +// instructions that clobber the memory that is read from. // // This pass builds off of another value numbering pass to implement value -// numbering for non-load instructions. It uses Alias Analysis so that it can -// disambiguate the load instructions. The more powerful these base analyses -// are, the more powerful the resultant analysis will be. +// numbering for non-load and non-call instructions. It uses Alias Analysis so +// that it can disambiguate the load instructions. The more powerful these base +// analyses are, the more powerful the resultant value numbering will be. // //===----------------------------------------------------------------------===// #include "llvm/Analysis/LoadValueNumbering.h" +#include "llvm/Function.h" +#include "llvm/iMemory.h" +#include "llvm/iOther.h" +#include "llvm/Pass.h" +#include "llvm/Type.h" #include "llvm/Analysis/ValueNumbering.h" #include "llvm/Analysis/AliasAnalysis.h" #include "llvm/Analysis/Dominators.h" -#include "llvm/Target/TargetData.h" -#include "llvm/Pass.h" -#include "llvm/Type.h" -#include "llvm/iMemory.h" -#include "llvm/BasicBlock.h" #include "llvm/Support/CFG.h" +#include "llvm/Target/TargetData.h" #include using namespace llvm; @@ -50,6 +54,11 @@ /// virtual void getEqualNumberNodes(Value *V1, std::vector &RetVals) const; + + /// getCallEqualNumberNodes - Given a call instruction, find other calls + /// that have the same value number. + void getCallEqualNumberNodes(CallInst *CI, + std::vector &RetVals) const; }; // Register this pass... @@ -109,6 +118,122 @@ return true; } +/// getCallEqualNumberNodes - Given a call instruction, find other calls that +/// have the same value number. +void LoadVN::getCallEqualNumberNodes(CallInst *CI, + std::vector &RetVals) const { + Function *CF = CI->getCalledFunction(); + if (CF == 0) return; // Indirect call. + AliasAnalysis &AA = getAnalysis(); + if (!AA.onlyReadsMemory(CF)) return; // Nothing we can do. + + // Scan all of the arguments of the function, looking for one that is not + // global. In particular, we would prefer to have an argument or instruction + // operand to chase the def-use chains of. + Value *Op = CF; + for (unsigned i = 1, e = CI->getNumOperands(); i != e; ++i) + if (isa(CI->getOperand(i)) || + isa(CI->getOperand(i))) { + Op = CI->getOperand(i); + break; + } + + // Identify all lexically identical calls in this function. + std::vector IdenticalCalls; + + Function *CIFunc = CI->getParent()->getParent(); + for (Value::use_iterator UI = Op->use_begin(), E = Op->use_end(); UI != E; + ++UI) + if (CallInst *C = dyn_cast(*UI)) + if (C->getNumOperands() == CI->getNumOperands() && + C->getOperand(0) == CI->getOperand(0) && + C->getParent()->getParent() == CIFunc && C != CI) { + bool AllOperandsEqual = true; + for (unsigned i = 1, e = CI->getNumOperands(); i != e; ++i) + if (C->getOperand(i) != CI->getOperand(i)) { + AllOperandsEqual = false; + break; + } + + if (AllOperandsEqual) + IdenticalCalls.push_back(C); + } + + if (IdenticalCalls.empty()) return; + + // Eliminate duplicates, which could occur if we chose a value that is passed + // into a call site multiple times. + std::sort(IdenticalCalls.begin(), IdenticalCalls.end()); + IdenticalCalls.erase(std::unique(IdenticalCalls.begin(),IdenticalCalls.end()), + IdenticalCalls.end()); + + // If the call reads memory, we must make sure that there are no stores + // between the calls in question. + // + // FIXME: This should use mod/ref information. What we really care about it + // whether an intervening instruction could modify memory that is read, not + // ANY memory. + // + if (!AA.doesNotAccessMemory(CF)) { + DominatorSet &DomSetInfo = getAnalysis(); + BasicBlock *CIBB = CI->getParent(); + for (unsigned i = 0; i != IdenticalCalls.size(); ++i) { + CallInst *C = IdenticalCalls[i]; + bool CantEqual = false; + + if (DomSetInfo.dominates(CIBB, C->getParent())) { + // FIXME: we currently only handle the case where both calls are in the + // same basic block. + if (CIBB != C->getParent()) { + CantEqual = true; + } else { + Instruction *First = CI, *Second = C; + if (!DomSetInfo.dominates(CI, C)) + std::swap(First, Second); + + // Scan the instructions between the calls, checking for stores or + // calls to dangerous functions. + BasicBlock::iterator I = First; + for (++First; I != BasicBlock::iterator(Second); ++I) { + if (isa(I)) { + // FIXME: We could use mod/ref information to make this much + // better! + CantEqual = true; + break; + } else if (CallInst *CI = dyn_cast(I)) { + if (CI->getCalledFunction() == 0 || + !AA.onlyReadsMemory(CI->getCalledFunction())) { + CantEqual = true; + break; + } + } else if (I->mayWriteToMemory()) { + CantEqual = true; + break; + } + } + } + + } else if (DomSetInfo.dominates(C->getParent(), CIBB)) { + // FIXME: We could implement this, but we don't for now. + CantEqual = true; + } else { + // FIXME: if one doesn't dominate the other, we can't tell yet. + CantEqual = true; + } + + + if (CantEqual) { + // This call does not produce the same value as the one in the query. + std::swap(IdenticalCalls[i--], IdenticalCalls.back()); + IdenticalCalls.pop_back(); + } + } + } + + // Any calls that are identical and not destroyed will produce equal values! + for (unsigned i = 0, e = IdenticalCalls.size(); i != e; ++i) + RetVals.push_back(IdenticalCalls[i]); +} // getEqualNumberNodes - Return nodes with the same value number as the // specified Value. This fills in the argument vector with any equal values. @@ -121,6 +246,9 @@ getAnalysis().getMustAliases(V, RetVals); if (!isa(V)) { + if (CallInst *CI = dyn_cast(V)) + return getCallEqualNumberNodes(CI, RetVals); + // Not a load instruction? Just chain to the base value numbering // implementation to satisfy the request... assert(&getAnalysis() != (ValueNumbering*)this && From lattner at cs.uiuc.edu Mon Mar 15 00:01:21 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:01:21 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/GCSE.cpp Message-ID: <200403150547.XAA25892@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: GCSE.cpp updated: 1.34 -> 1.35 --- Log message: Add counters for the number of calls elimianted --- Diffs of the changes: (+6 -0) Index: llvm/lib/Transforms/Scalar/GCSE.cpp diff -u llvm/lib/Transforms/Scalar/GCSE.cpp:1.34 llvm/lib/Transforms/Scalar/GCSE.cpp:1.35 --- llvm/lib/Transforms/Scalar/GCSE.cpp:1.34 Thu Feb 5 16:33:19 2004 +++ llvm/lib/Transforms/Scalar/GCSE.cpp Sun Mar 14 23:46:59 2004 @@ -16,6 +16,7 @@ #include "llvm/Transforms/Scalar.h" #include "llvm/iMemory.h" +#include "llvm/iOther.h" #include "llvm/Type.h" #include "llvm/Analysis/Dominators.h" #include "llvm/Analysis/ValueNumbering.h" @@ -28,6 +29,7 @@ namespace { Statistic<> NumInstRemoved("gcse", "Number of instructions removed"); Statistic<> NumLoadRemoved("gcse", "Number of loads removed"); + Statistic<> NumCallRemoved("gcse", "Number of calls removed"); Statistic<> NumNonInsts ("gcse", "Number of instructions removed due " "to non-instruction values"); @@ -123,6 +125,8 @@ if (isa(I)) ++NumLoadRemoved; // Keep track of loads eliminated + if (isa(I)) + ++NumCallRemoved; // Keep track of calls eliminated ++NumInstRemoved; // Keep track of number of instructions eliminated ++NumNonInsts; // Keep track of number of insts repl with values @@ -264,6 +268,8 @@ if (isa(Ret)) ++NumLoadRemoved; // Keep track of loads eliminated + if (isa(Ret)) + ++NumCallRemoved; // Keep track of calls eliminated ++NumInstRemoved; // Keep track of number of instructions eliminated // Add all users of Ret to the worklist... From lattner at cs.uiuc.edu Mon Mar 15 00:25:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:25:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Analysis/AliasSetTracker.cpp Message-ID: <200403150624.AAA31208@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: AliasSetTracker.cpp updated: 1.11 -> 1.12 --- Log message: This assertion is bogus now that calls do not necessarily read/write memory --- Diffs of the changes: (+0 -2) Index: llvm/lib/Analysis/AliasSetTracker.cpp diff -u llvm/lib/Analysis/AliasSetTracker.cpp:1.11 llvm/lib/Analysis/AliasSetTracker.cpp:1.12 --- llvm/lib/Analysis/AliasSetTracker.cpp:1.11 Sun Mar 14 22:08:36 2004 +++ llvm/lib/Analysis/AliasSetTracker.cpp Mon Mar 15 00:24:15 2004 @@ -117,8 +117,6 @@ bool AliasSet::aliasesPointer(const Value *Ptr, unsigned Size, AliasAnalysis &AA) const { if (AliasTy == MustAlias) { - assert(CallSites.empty() && "Illegal must alias set!"); - // If this is a set of MustAliases, only check to see if the pointer aliases // SOME value in the set... HashNodePair *SomePtr = getSomePointer(); From lattner at cs.uiuc.edu Mon Mar 15 00:29:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:29:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Analysis/AliasSetTracker.cpp Message-ID: <200403150628.AAA31692@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: AliasSetTracker.cpp updated: 1.12 -> 1.13 --- Log message: Ok, the assertion was bogus. Calls that do not read/write memory should not have an alias set, just like adds and subtracts don't. --- Diffs of the changes: (+6 -0) Index: llvm/lib/Analysis/AliasSetTracker.cpp diff -u llvm/lib/Analysis/AliasSetTracker.cpp:1.12 llvm/lib/Analysis/AliasSetTracker.cpp:1.13 --- llvm/lib/Analysis/AliasSetTracker.cpp:1.12 Mon Mar 15 00:24:15 2004 +++ llvm/lib/Analysis/AliasSetTracker.cpp Mon Mar 15 00:28:07 2004 @@ -117,6 +117,8 @@ bool AliasSet::aliasesPointer(const Value *Ptr, unsigned Size, AliasAnalysis &AA) const { if (AliasTy == MustAlias) { + assert(CallSites.empty() && "Illegal must alias set!"); + // If this is a set of MustAliases, only check to see if the pointer aliases // SOME value in the set... HashNodePair *SomePtr = getSomePointer(); @@ -222,6 +224,10 @@ void AliasSetTracker::add(CallSite CS) { + if (Function *F = CS.getCalledFunction()) + if (AA.doesNotAccessMemory(F)) + return; + AliasSet *AS = findAliasSetForCallSite(CS); if (!AS) { AliasSets.push_back(AliasSet()); From lattner at cs.uiuc.edu Mon Mar 15 00:39:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 00:39:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/IPO/InlineSimple.cpp Message-ID: <200403150638.AAA32166@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/IPO: InlineSimple.cpp updated: 1.60 -> 1.61 --- Log message: Restore old inlining heuristic. As the comment indicates, this is a nasty horrible hack. --- Diffs of the changes: (+8 -1) Index: llvm/lib/Transforms/IPO/InlineSimple.cpp diff -u llvm/lib/Transforms/IPO/InlineSimple.cpp:1.60 llvm/lib/Transforms/IPO/InlineSimple.cpp:1.61 --- llvm/lib/Transforms/IPO/InlineSimple.cpp:1.60 Sat Mar 13 17:15:45 2004 +++ llvm/lib/Transforms/IPO/InlineSimple.cpp Mon Mar 15 00:38:14 2004 @@ -216,7 +216,14 @@ // Don't inline into something too big, which would make it bigger. Here, we // count each basic block as a single unit. - InlineCost += Caller->size()/20; + // + // FIXME: THIS IS A TOTAL HACK. The problem is that we don't keep track of + // which call sites are the result of an inlining operation. Because of this, + // if we inline a recursive function into a callee, we will see a new call to + // the recursive function. Every time we inline we get a new callsite for the + // function, which only stops when the caller reaches its inlining limit. + // Until the real problem is fixed, we apply this gnasty hack. + InlineCost += Caller->size(); // Look at the size of the callee. Each basic block counts as 20 units, and From criswell at cs.uiuc.edu Mon Mar 15 09:41:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon Mar 15 09:41:02 2004 Subject: [llvm-commits] [GNU_GCC] CVS: llvm-gcc/libiberty/hashtab.c Message-ID: <200403151540.JAA05977@choi.cs.uiuc.edu> Changes in directory llvm-gcc/libiberty: hashtab.c updated: 1.1.1.1 -> 1.1.1.2 --- Log message: Updated to revision 1.38 from the GCC sources. This fixes a minor bug and might help prevent segfaults. --- Diffs of the changes: (+2 -2) Index: llvm-gcc/libiberty/hashtab.c diff -u llvm-gcc/libiberty/hashtab.c:1.1.1.1 llvm-gcc/libiberty/hashtab.c:1.1.1.2 --- llvm-gcc/libiberty/hashtab.c:1.1.1.1 Thu Jan 8 15:59:18 2004 +++ llvm-gcc/libiberty/hashtab.c Mon Mar 15 09:40:06 2004 @@ -535,14 +535,14 @@ if (insert == NO_INSERT) return NULL; - htab->n_elements++; - if (first_deleted_slot) { + htab->n_deleted--; *first_deleted_slot = EMPTY_ENTRY; return first_deleted_slot; } + htab->n_elements++; return &htab->entries[index]; } From criswell at cs.uiuc.edu Mon Mar 15 09:44:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon Mar 15 09:44:02 2004 Subject: [llvm-commits] CVS: llvm-gcc/libiberty/hashtab.c Message-ID: <200403151543.JAA06048@choi.cs.uiuc.edu> Changes in directory llvm-gcc/libiberty: hashtab.c updated: 1.1.1.2 -> 1.2 --- Log message: Merged in fix from mainline GCC. It fixes a small error, and hopefully it will help prevent segfaults, too. --- Diffs of the changes: (+2 -2) Index: llvm-gcc/libiberty/hashtab.c diff -u llvm-gcc/libiberty/hashtab.c:1.1.1.2 llvm-gcc/libiberty/hashtab.c:1.2 --- llvm-gcc/libiberty/hashtab.c:1.1.1.2 Mon Mar 15 09:40:06 2004 +++ llvm-gcc/libiberty/hashtab.c Mon Mar 15 09:43:22 2004 @@ -535,14 +535,14 @@ if (insert == NO_INSERT) return NULL; + htab->n_elements++; + if (first_deleted_slot) { - htab->n_deleted--; *first_deleted_slot = EMPTY_ENTRY; return first_deleted_slot; } - htab->n_elements++; return &htab->entries[index]; } From brukman at cs.uiuc.edu Mon Mar 15 10:55:01 2004 From: brukman at cs.uiuc.edu (Misha Brukman) Date: Mon Mar 15 10:55:01 2004 Subject: [llvm-commits] CVS: llvm-www/status/index.html Message-ID: <200403151654.KAA23038@zion.cs.uiuc.edu> Changes in directory llvm-www/status: index.html updated: 1.38 -> 1.39 --- Log message: Close correctly. --- Diffs of the changes: (+2 -2) Index: llvm-www/status/index.html diff -u llvm-www/status/index.html:1.38 llvm-www/status/index.html:1.39 --- llvm-www/status/index.html:1.38 Sat Feb 14 19:15:45 2004 +++ llvm-www/status/index.html Mon Mar 15 10:54:13 2004 @@ -156,7 +156,7 @@ ./build CC=llvm-gcc lrh lrh = Linux Red Hat, there are many such targets. - Compile fails: see bug 141 and + Compile fails: see bug 141 and bug 82 for details. @@ -454,7 +454,7 @@
Misha Brukman
The LLVM Compiler Infrastructure
- Last modified: $Date: 2004/02/15 01:15:45 $ + Last modified: $Date: 2004/03/15 16:54:13 $ From alkis at cs.uiuc.edu Mon Mar 15 11:21:01 2004 From: alkis at cs.uiuc.edu (Alkis Evlogimenos) Date: Mon Mar 15 11:21:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Target/X86/X86InstrInfo.td Message-ID: <200403151720.LAA32297@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/X86: X86InstrInfo.td updated: 1.61 -> 1.62 --- Log message: Add LAHF instruction --- Diffs of the changes: (+1 -0) Index: llvm/lib/Target/X86/X86InstrInfo.td diff -u llvm/lib/Target/X86/X86InstrInfo.td:1.61 llvm/lib/Target/X86/X86InstrInfo.td:1.62 --- llvm/lib/Target/X86/X86InstrInfo.td:1.61 Fri Mar 12 11:59:56 2004 +++ llvm/lib/Target/X86/X86InstrInfo.td Mon Mar 15 11:20:14 2004 @@ -600,6 +600,7 @@ // Condition code ops, incl. set if equal/not equal/... def SAHF : I <"sahf" , 0x9E, RawFrm>, Imp<[AH],[]>; // flags = AH +def LAHF : I <"lahf" , 0x9F, RawFrm>, Imp<[],[AH]>; // AH = flags def SETBr : I <"setb" , 0x92, MRM0r>, TB; // R8 = < unsign def SETBm : Im8<"setb" , 0x92, MRM0m>, TB; // [mem8] = < unsign From criswell at cs.uiuc.edu Mon Mar 15 12:20:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon Mar 15 12:20:02 2004 Subject: [llvm-commits] CVS: llvm/test/QMTest/llvmdb.py Message-ID: <200403151819.MAA00962@choi.cs.uiuc.edu> Changes in directory llvm/test/QMTest: llvmdb.py updated: 1.11 -> 1.12 --- Log message: Ignore the Regressions Debugger directory. It is not automatic yet. --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/llvmdb.py diff -u llvm/test/QMTest/llvmdb.py:1.11 llvm/test/QMTest/llvmdb.py:1.12 --- llvm/test/QMTest/llvmdb.py:1.11 Tue Dec 2 08:52:12 2003 +++ llvm/test/QMTest/llvmdb.py Mon Mar 15 12:19:29 2004 @@ -164,7 +164,7 @@ # Record names of invalid directories and files. # invalid_dirs = ['CVS', 'QMTest', 'QMTestDB', 'Scripts', 'Programs', - 'Fragments', 'Reoptimizer', 'tmp'] + 'Fragments', 'Reoptimizer', 'Debugger', 'tmp'] invalid_files = ['Makefile', 'README.txt', '.cvsignore', 'opaquetypes.ll'] From brukman at cs.uiuc.edu Mon Mar 15 18:01:00 2004 From: brukman at cs.uiuc.edu (Misha Brukman) Date: Mon Mar 15 18:01:00 2004 Subject: [llvm-commits] CVS: llvm-www/status/index.html Message-ID: <200403160000.SAA09135@zion.cs.uiuc.edu> Changes in directory llvm-www/status: index.html updated: 1.39 -> 1.40 --- Log message: Some tests moved into auto-testing, some reconfirmed working, some fixed. --- Diffs of the changes: (+80 -141) Index: llvm-www/status/index.html diff -u llvm-www/status/index.html:1.39 llvm-www/status/index.html:1.40 --- llvm-www/status/index.html:1.39 Mon Mar 15 10:54:13 2004 +++ llvm-www/status/index.html Mon Mar 15 17:59:53 2004 @@ -18,9 +18,7 @@ following:

-% setenv CC  llvm-gcc
-% setenv CXX llvm-g++
-% ./configure [configure options]
+% env CC=llvm-gcc CXX=llvm-g++ ./configure [configure options]
 % make
@@ -34,7 +32,27 @@
- Compilation / running results + Switched to automated testing +
+ +

The following programs are no longer tested for this page as they are part of +the external tester: + +

+ed, +nano, +gawk, +sed, +gnugo, +bison, +recode, +grep, +

+ +
+ +
+ Manually tested programs

@@ -47,13 +65,67 @@ Status Notes + + + mutt + 1.4.1i + 15 Mar 2004 + WORKS + Run with: +
lli -load=/usr/lib/libncurses.so mutt.bc
+ Sometimes suspend and resume act funny. + + + + xboard + 4.2.6 + 15 Mar 2004 + WORKS + Works well with Crafty and GNU chess, all compiled to LLVM! + + + + gnuchess + 5.06 + 15 Mar 2004 + WORKS + Requires several libraries, run with: +
+lli -load=/lib/libpthread.so.0    \
+    -load=/usr/lib/libncurses.so  \
+    -load=/usr/lib/libreadline.so \
+    gnuchess.bc [gnuchess options]
+
+ + + + + crafty + 19.3 + 15 Mar 2004 + WORKS + Apply this patch to the + Makefile, then run make linux-llvm . Afterwards, run with + 
lli -load=/lib/libpthread.so.0 crafty.bc
+ Crafty has been successfully used with XBoard, both compiled with LLVM. + + + + cvs + 1.11.6 + 15 Mar 2004 + FAILS + Cannot compile: see bug 295. + llvm 1.1 - 15 Dec 2003 - WORKS - Just did some simple touch testing after 'make tools'. Things seem to work, but I didn't try running the testsuite or anything. + 15 Mar 2004 + FAILS + bugpoint does not compile: bug 291. @@ -63,15 +135,6 @@ WORKS Did not try the install target. - - - recode - 3.6 - 21 Nov 2003 - WORKS - passes its own regression test suite - char* vs. unsigned char* has been resolved, and the patch has been accepted into screen - - - nano - 1.2.1 - 20 Nov 2003 - WORKS - It just works. - - - - xboard - 4.2.6 - 20 Nov 2003 - WORKS - Works well with Crafty, both compiled to LLVM! - xemacs @@ -159,23 +205,6 @@ Compile fails: see bug 141 and bug 82 for details. - - - grep - 2.5 - 18 Nov 2003 - WORKS - Passes own regression tests. - - - - cvs - 1.11.6 - 18 Nov 2003 - FAILS - Fails to login to remote anonymous repository or checkout. May have - something to do with all the "type conflict" warnings at compile-time. - xpdf @@ -203,18 +232,6 @@ Seems to detect valid input. Have not tried a valid Kimwitu++ input file. - - - ed - 0.2 - 17 Nov 2003 - FAILS - With CBE, LLC: passes its own regression test suite. - With JIT: 'H' command prints garbage. With all backends: - "Ed is the standard text - editor." - Unix Seventh Edition manual, Bell Telephone Laboratories, - 1979. - tcsh @@ -224,31 +241,6 @@ Inexplicably crashes in the JIT soon after start-up. Not yet investigated. - - - gawk - 3.1.3 - 13 Nov 2003 - WORKS - passes its own regression test suite - - - - gnugo - 5.06 - 13 Nov 2003 - WORKS - passes its own regression test suite - - - - sed - 4.0.7 - 13 Nov 2003 - WORKS - passes its own regression test suite - WORKS passes its own regression test suite - - - mutt - 1.4.1i - 13 Nov 2003 - WORKS - Run with: -
lli -load=/usr/lib/libncurses.so mutt.bc
- Sometimes suspend and resume act funny. - - - - gnuchess - 5.06 - 12 Nov 2003 - FAILS - Requires several libraries, run with: -
-lli -load=/lib/libpthread.so.0    \
-    -load=/usr/lib/libncurses.so  \
-    -load=/usr/lib/libreadline.so \
-    gnuchess.bc [gnuchess options]
-
- Does not seem to work on the command line or with xboard. - - - - crafty - 19.3 - 12 Nov 2003 - WORKS - Apply this patch to the - Makefile, then run make linux-llvm . Afterwards, run with - 
lli -load=/lib/libpthread.so.0 crafty.bc
- Crafty has been successfully used with XBoard, both compiled with LLVM. - ddd @@ -341,14 +296,6 @@ - - - GNU Go - 3.4 - 29 Oct 2003 - WORKS - Bytecode files must be installed by hand. - Obsequi @@ -394,14 +341,6 @@ after running ./configure and it all compiles, however, with many warnings: 
gccld: Cannot find ypsec
passes own tests. - - - bison - 1.875 - 15 Oct 2003 - WORKS - passes its own regression test suite - Misha Brukman The LLVM Compiler Infrastructure
- Last modified: $Date: 2004/03/15 16:54:13 $ + Last modified: $Date: 2004/03/15 23:59:53 $ From lattner at cs.uiuc.edu Mon Mar 15 19:47:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 19:47:01 2004 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/RegAllocSimple.cpp Message-ID: <200403160146.TAA12452@zion.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen: RegAllocSimple.cpp updated: 1.54 -> 1.55 --- Log message: Fix PR294 --- Diffs of the changes: (+2 -1) Index: llvm/lib/CodeGen/RegAllocSimple.cpp diff -u llvm/lib/CodeGen/RegAllocSimple.cpp:1.54 llvm/lib/CodeGen/RegAllocSimple.cpp:1.55 --- llvm/lib/CodeGen/RegAllocSimple.cpp:1.54 Sun Feb 22 22:12:30 2004 +++ llvm/lib/CodeGen/RegAllocSimple.cpp Mon Mar 15 19:45:55 2004 @@ -172,7 +172,8 @@ for (int i = MI->getNumOperands() - 1; i >= 0; --i) { MachineOperand &op = MI->getOperand(i); - if (op.isRegister() && MRegisterInfo::isVirtualRegister(op.getReg())) { + if (op.isRegister() && op.getReg() && + MRegisterInfo::isVirtualRegister(op.getReg())) { unsigned virtualReg = (unsigned) op.getReg(); DEBUG(std::cerr << "op: " << op << "\n"); DEBUG(std::cerr << "\t inst[" << i << "]: "; From lattner at cs.uiuc.edu Mon Mar 15 19:53:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 19:53:01 2004 Subject: [llvm-commits] CVS: llvm/tools/bugpoint/Miscompilation.cpp Message-ID: <200403160152.TAA13173@zion.cs.uiuc.edu> Changes in directory llvm/tools/bugpoint: Miscompilation.cpp updated: 1.31 -> 1.32 --- Log message: Fix thinko, and PR292 --- Diffs of the changes: (+1 -1) Index: llvm/tools/bugpoint/Miscompilation.cpp diff -u llvm/tools/bugpoint/Miscompilation.cpp:1.31 llvm/tools/bugpoint/Miscompilation.cpp:1.32 --- llvm/tools/bugpoint/Miscompilation.cpp:1.31 Sun Mar 14 16:08:00 2004 +++ llvm/tools/bugpoint/Miscompilation.cpp Mon Mar 15 19:51:54 2004 @@ -245,7 +245,7 @@ std::cout << "done.\n"; std::cout << " Checking to see if the merged program executes correctly: "; - bool Broken = TestMergedProgram(BD, Optimized, ToNotOptimize, true); + bool Broken = TestMergedProgram(BD, Optimized, ToNotOptimize, false); delete Optimized; if (!Broken) { std::cout << "yup: loop extraction masked the problem. Undoing.\n"; From lattner at cs.uiuc.edu Mon Mar 15 21:42:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 21:42:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Analysis/BasicAliasAnalysis.cpp LoadValueNumbering.cpp Message-ID: <200403160341.VAA14301@zion.cs.uiuc.edu> Changes in directory llvm/lib/Analysis: BasicAliasAnalysis.cpp updated: 1.34 -> 1.35 LoadValueNumbering.cpp updated: 1.16 -> 1.17 --- Log message: Add some missing functions. Make sure to handle calls together in case the client has another VN implementation that can VN calls. --- Diffs of the changes: (+21 -3) Index: llvm/lib/Analysis/BasicAliasAnalysis.cpp diff -u llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.34 llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.35 --- llvm/lib/Analysis/BasicAliasAnalysis.cpp:1.34 Sun Mar 14 22:18:28 2004 +++ llvm/lib/Analysis/BasicAliasAnalysis.cpp Mon Mar 15 21:41:35 2004 @@ -607,6 +607,17 @@ "iswctype", "towctrans", "towlower", "towupper", "btowc", "wctob", + + "isinf", "isnan", "finite", + + // C99 math functions + "copysign", "copysignf", "copysignd", + "nexttoward", "nexttowardf", "nexttowardd", + "nextafter", "nextafterf", "nextafterd", + + // glibc functions: + "__fpclassify", "__fpclassifyf", "__fpclassifyl", + "__signbit", "__signbitf", "__signbitl", }; static const unsigned DAMTableSize = @@ -636,16 +647,23 @@ static const char *OnlyReadsMemoryTable[] = { - "atoi", "atol", "atof", "atoll", "atoq", - "bcmp", "memcmp", "memchr", "wmemcmp", "wmemchr", + "atoi", "atol", "atof", "atoll", "atoq", "a64l", + "bcmp", "memcmp", "memchr", "memrchr", "wmemcmp", "wmemchr", // Strings "strcmp", "strcasecmp", "strcoll", "strncmp", "strncasecmp", "strchr", "strcspn", "strlen", "strpbrk", "strrchr", "strspn", "strstr", + "index", "rindex", // Wide char strings "wcschr", "wcscmp", "wcscoll", "wcscspn", "wcslen", "wcsncmp", "wcspbrk", "wcsrchr", "wcsspn", "wcsstr", + + // glibc + "alphasort", "alphasort64", "versionsort", "versionsort64", + + // C99 + "nan", "nanf", "nand", }; static const unsigned ORMTableSize = Index: llvm/lib/Analysis/LoadValueNumbering.cpp diff -u llvm/lib/Analysis/LoadValueNumbering.cpp:1.16 llvm/lib/Analysis/LoadValueNumbering.cpp:1.17 --- llvm/lib/Analysis/LoadValueNumbering.cpp:1.16 Sun Mar 14 23:44:59 2004 +++ llvm/lib/Analysis/LoadValueNumbering.cpp Mon Mar 15 21:41:35 2004 @@ -247,7 +247,7 @@ if (!isa(V)) { if (CallInst *CI = dyn_cast(V)) - return getCallEqualNumberNodes(CI, RetVals); + getCallEqualNumberNodes(CI, RetVals); // Not a load instruction? Just chain to the base value numbering // implementation to satisfy the request... From sabre at nondot.org Mon Mar 15 23:10:02 2004 From: sabre at nondot.org (Chris Lattner) Date: Mon Mar 15 23:10:02 2004 Subject: [llvm-commits] Test: ignore me Message-ID: Just checking to see if llvmcommits autolinkifies tags and URLS in the web archive. URL: http://llvm.cs.uiuc.edu/ URL -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/ From lattner at cs.uiuc.edu Mon Mar 15 23:15:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:15:01 2004 Subject: [llvm-commits] CVS: CVSROOT/commit-diffs.pl Message-ID: <200403160514.XAA14950@zion.cs.uiuc.edu> Changes in directory CVSROOT: commit-diffs.pl updated: 1.51 -> 1.52 --- Log message: Yes I suck at perl. Despite that, here's an attempt to autolinkify PR/Bug identifiers when commits go in. --- Diffs of the changes: (+2 -0) Index: CVSROOT/commit-diffs.pl diff -u CVSROOT/commit-diffs.pl:1.51 CVSROOT/commit-diffs.pl:1.52 --- CVSROOT/commit-diffs.pl:1.51 Thu Jan 29 19:25:26 2004 +++ CVSROOT/commit-diffs.pl Mon Mar 15 23:14:19 2004 @@ -88,6 +88,8 @@ foreach $s (@loginfodata) { if ($islogmessage) { + $s =~ s/([bB][uU][gG]\s*([0-9]+))/$1 (http://llvm.cs.uiuc.edu/PR$2)/g; + $s =~ s/([pP][rR]\s*([0-9]+))/$1 (http://llvm.cs.uiuc.edu/PR$2)/g; @logmessage = (@logmessage, $s); next; } From lattner at cs.uiuc.edu Mon Mar 15 23:19:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:19:02 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/C++Frontend/2004-03-15-CleanupsAndGotos.cpp Message-ID: <200403160518.XAA15005@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/C++Frontend: 2004-03-15-CleanupsAndGotos.cpp updated: 1.3 -> 1.4 --- Log message: foo Bug 291: http://llvm.cs.uiuc.edu/PR291: http://llvm.cs.uiuc.edu/PR291 , bar PR291: http://llvm.cs.uiuc.edu/PR291 --- Diffs of the changes: (+1 -0) Index: llvm/test/Regression/C++Frontend/2004-03-15-CleanupsAndGotos.cpp diff -u llvm/test/Regression/C++Frontend/2004-03-15-CleanupsAndGotos.cpp:1.3 llvm/test/Regression/C++Frontend/2004-03-15-CleanupsAndGotos.cpp:1.4 --- llvm/test/Regression/C++Frontend/2004-03-15-CleanupsAndGotos.cpp:1.3 Mon Mar 15 23:17:07 2004 +++ llvm/test/Regression/C++Frontend/2004-03-15-CleanupsAndGotos.cpp Mon Mar 15 23:18:24 2004 @@ -1,4 +1,5 @@ // Testcase from Bug 291 + struct X { ~X(); }; From lattner at cs.uiuc.edu Mon Mar 15 23:22:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:22:01 2004 Subject: [llvm-commits] CVS: CVSROOT/commit-diffs.pl Message-ID: <200403160521.XAA15036@zion.cs.uiuc.edu> Changes in directory CVSROOT: commit-diffs.pl updated: 1.55 -> 1.56 --- Log message: Don't transform Bug NN -> Bug NN: blah PRNN then the PRNN into PRNN: blah PRNN again --- Diffs of the changes: (+1 -1) Index: CVSROOT/commit-diffs.pl diff -u CVSROOT/commit-diffs.pl:1.55 CVSROOT/commit-diffs.pl:1.56 --- CVSROOT/commit-diffs.pl:1.55 Mon Mar 15 23:17:47 2004 +++ CVSROOT/commit-diffs.pl Mon Mar 15 23:21:47 2004 @@ -88,8 +88,8 @@ foreach $s (@loginfodata) { if ($islogmessage) { - $s =~ s|([bB][uU][gG]\s*([0-9]+))|$1: http://llvm.cs.uiuc.edu/PR$2 |g; $s =~ s|([pP][rR]\s*([0-9]+))|$1: http://llvm.cs.uiuc.edu/PR$2 |g; + $s =~ s|([bB][uU][gG]\s*([0-9]+))|$1: http://llvm.cs.uiuc.edu/PR$2 |g; @logmessage = (@logmessage, $s); next; } From lattner at cs.uiuc.edu Mon Mar 15 23:24:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:24:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c llvm-representation.h Message-ID: <200403160523.XAA15241@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.24 -> 1.25 llvm-representation.h updated: 1.2 -> 1.3 --- Log message: Fix PR291: http://llvm.cs.uiuc.edu/PR291 : [llvm-g++] Cleanups and exception handlers don't mix properly --- Diffs of the changes: (+30 -4) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.24 llvm-gcc/gcc/llvm-expand.c:1.25 --- llvm-gcc/gcc/llvm-expand.c:1.24 Tue Mar 9 21:05:22 2004 +++ llvm-gcc/gcc/llvm-expand.c Mon Mar 15 23:23:37 2004 @@ -951,6 +951,9 @@ case COND_NESTING: break; } + if (f->target_bb->EnclosingScope == thisblock) + DeleteThisFixup = 1; + ReallyDeleteThisFixup: if (DeleteThisFixup) { /* Unlink this node in the fixup chain */ @@ -1010,9 +1013,10 @@ /* add the new basic block to the function */ llvm_ilist_push_back(llvm_basicblock, Fn->BasicBlocks, BB); + BB->EnclosingScope = Fn->ExpandInfo->InnermostBlockScope; /* If there were any pending fixups that branch to this block, they can be - * deleted now, because they do not exit the current scope. + * deleted now, because they do not exist the current scope. */ if (BB->FixupExistsForThisBlock) { llvm_goto_fixup **fl = &Fn->ExpandInfo->GotoFixupList; @@ -1563,8 +1567,23 @@ /* Does any containing block have a stack level or cleanups? If not, no fixup is needed, and that is the normal case (the only case, for standard C). */ block = Fn->ExpandInfo->InnermostBlockScope; - while (block && !block->x.block.cleanups) - block = block->next; + if (!BB->EnclosingScope) { + /* This is a forward reference to a block. Since we know that we can't jump + * INTO a region that has cleanups, we can only be branching out. + */ + while (block && !block->x.block.cleanups) + block = block->next; + } else { + /* This is not a forward reference. Check to see if there are any blocks + * with cleanups before we get to the enclosing block. + */ + llvm_nesting *EnclosingScope = (llvm_nesting *)BB->EnclosingScope; + + while (block && block != EnclosingScope && !block->x.block.cleanups) + block = block->next; + if (block == EnclosingScope) + return; + } /* If there are no cleanups that need to be fun for this branch, don't create * a fixup. @@ -6619,7 +6638,7 @@ assert(!Fn->ExpandInfo->CleanupBlock && "Cleanupblock not handled yet!"); - /* C++ uses this. */ + /* C++ uses this? */ if (end_bindings) { LLVM_TODO(); expand_end_bindings (0, 0, 0); Index: llvm-gcc/gcc/llvm-representation.h diff -u llvm-gcc/gcc/llvm-representation.h:1.2 llvm-gcc/gcc/llvm-representation.h:1.3 --- llvm-gcc/gcc/llvm-representation.h:1.2 Tue Mar 9 20:50:57 2004 +++ llvm-gcc/gcc/llvm-representation.h Mon Mar 15 23:23:37 2004 @@ -217,6 +217,13 @@ * which will branch to this block. */ int FixupExistsForThisBlock; + + /* EnclosingScope - This member contains the innermost scope that contains the + * basic block. This is only valid when a basic block is added to the + * program, it is not valid if a label or block is, for example, forward + * referenced. This member is used when expanding cleanups. + */ + void *EnclosingScope; } llvm_basicblock; llvm_basicblock *llvm_basicblock_new(const char *); From lattner at cs.uiuc.edu Mon Mar 15 23:29:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:29:01 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403160528.XAA16731@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.146 -> 1.147 --- Log message: Bug fixed --- Diffs of the changes: (+2 -1) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.146 llvm/docs/ReleaseNotes.html:1.147 --- llvm/docs/ReleaseNotes.html:1.146 Sat Mar 13 20:03:02 2004 +++ llvm/docs/ReleaseNotes.html Mon Mar 15 23:28:35 2004 @@ -237,6 +237,7 @@
  • [llvmgcc] Invalid code created for complex division operation
  • [llvmgcc] Incorrect code generation for pointer subtraction
  • [llvmg++] Crash assigning pointers-to-members with casted types
    • +
  • [llvm-g++] Cleanups and exception handlers don't mix properly
    • @@ -648,7 +649,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/14 02:03:02 $ + Last modified: $Date: 2004/03/16 05:28:35 $ From lattner at cs.uiuc.edu Mon Mar 15 23:30:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:30:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.1/docs/ReleaseNotes.html Message-ID: <200403160529.XAA17192@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.1/docs: ReleaseNotes.html updated: 1.34 -> 1.35 --- Log message: Bug found --- Diffs of the changes: (+2 -1) Index: llvm-www/releases/1.1/docs/ReleaseNotes.html diff -u llvm-www/releases/1.1/docs/ReleaseNotes.html:1.34 llvm-www/releases/1.1/docs/ReleaseNotes.html:1.35 --- llvm-www/releases/1.1/docs/ReleaseNotes.html:1.34 Wed Mar 10 15:45:43 2004 +++ llvm-www/releases/1.1/docs/ReleaseNotes.html Mon Mar 15 23:28:54 2004 @@ -453,6 +453,7 @@
  • [llvmg++] Crash assigning pointers-to-members with casted types
    • +
  • [llvm-g++] Cleanups and exception handlers don't mix properly
    • @@ -763,7 +764,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/10 21:45:43 $ + Last modified: $Date: 2004/03/16 05:28:54 $ From lattner at cs.uiuc.edu Mon Mar 15 23:45:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon Mar 15 23:45:01 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/LoopSimplify/2004-03-15-IncorrectDomUpdate.ll Message-ID: <200403160544.XAA17429@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/LoopSimplify: 2004-03-15-IncorrectDomUpdate.ll added (r1.1) --- Log message: New testcase for PR293: http://llvm.cs.uiuc.edu/PR293 --- Diffs of the changes: (+12 -0) Index: llvm/test/Regression/Transforms/LoopSimplify/2004-03-15-IncorrectDomUpdate.ll diff -c /dev/null llvm/test/Regression/Transforms/LoopSimplify/2004-03-15-IncorrectDomUpdate.ll:1.1 *** /dev/null Mon Mar 15 23:44:12 2004 --- llvm/test/Regression/Transforms/LoopSimplify/2004-03-15-IncorrectDomUpdate.ll Mon Mar 15 23:44:02 2004 *************** *** 0 **** --- 1,12 ---- + ; RUN: llvm-as < %s | opt -loopsimplify -licm -disable-output + void %main() { + entry: + br bool false, label %Out, label %loop + + loop: + %LI = setgt int 0, 0 + br bool %LI, label %loop, label %Out + + Out: + ret void + } From lattner at cs.uiuc.edu Tue Mar 16 00:01:03 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 00:01:03 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/LoopSimplify.cpp Message-ID: <200403160600.AAA18670@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: LoopSimplify.cpp updated: 1.36 -> 1.37 --- Log message: Fix a regression from this patch: http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040308/013095.html Basically, this patch only updated the immediate dominatees of the header node to tell them that the preheader also dominated them. In practice, ALL dominatees of the header node are also dominated by the preheader. This fixes: LoopSimplify/2004-03-15-IncorrectDomUpdate. and PR293: http://llvm.cs.uiuc.edu/PR293 --- Diffs of the changes: (+13 -16) Index: llvm/lib/Transforms/Scalar/LoopSimplify.cpp diff -u llvm/lib/Transforms/Scalar/LoopSimplify.cpp:1.36 llvm/lib/Transforms/Scalar/LoopSimplify.cpp:1.37 --- llvm/lib/Transforms/Scalar/LoopSimplify.cpp:1.36 Sat Mar 13 21:59:22 2004 +++ llvm/lib/Transforms/Scalar/LoopSimplify.cpp Tue Mar 16 00:00:15 2004 @@ -312,31 +312,28 @@ DominatorSet &DS = getAnalysis(); // Update dominator info DominatorTree &DT = getAnalysis(); - DominatorTree::Node *HeaderDTNode = DT.getNode(Header); + + + // Update the dominator tree information. + // The immediate dominator of the preheader is the immediate dominator of + // the old header. + DominatorTree::Node *PHDomTreeNode = + DT.createNewNode(NewBB, DT.getNode(Header)->getIDom()); + + // Change the header node so that PNHode is the new immediate dominator + DT.changeImmediateDominator(DT.getNode(Header), PHDomTreeNode); { // The blocks that dominate NewBB are the blocks that dominate Header, // minus Header, plus NewBB. DominatorSet::DomSetType DomSet = DS.getDominators(Header); - DomSet.insert(NewBB); // We dominate ourself DomSet.erase(Header); // Header does not dominate us... DS.addBasicBlock(NewBB, DomSet); // The newly created basic block dominates all nodes dominated by Header. - for (DominatorTree::Node::iterator I = HeaderDTNode->begin(), - E = HeaderDTNode->end(); I != E; ++I) - DS.addDominator((*I)->getBlock(), NewBB); - } - - { // Update the dominator tree information. - // The immediate dominator of the preheader is the immediate dominator of - // the old header. - // - DominatorTree::Node *PHNode = - DT.createNewNode(NewBB, HeaderDTNode->getIDom()); - - // Change the header node so that PNHode is the new immediate dominator - DT.changeImmediateDominator(HeaderDTNode, PHNode); + for (df_iterator DFI = df_begin(PHDomTreeNode), + E = df_end(PHDomTreeNode); DFI != E; ++DFI) + DS.addDominator((*DFI)->getBlock(), NewBB); } // Update immediate dominator information if we have it... From lattner at cs.uiuc.edu Tue Mar 16 01:07:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 01:07:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-representation.h Message-ID: <200403160706.BAA21196@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-representation.h updated: 1.3 -> 1.4 --- Log message: remove dead member, add new member to llvm_basicblock --- Diffs of the changes: (+8 -2) Index: llvm-gcc/gcc/llvm-representation.h diff -u llvm-gcc/gcc/llvm-representation.h:1.3 llvm-gcc/gcc/llvm-representation.h:1.4 --- llvm-gcc/gcc/llvm-representation.h:1.3 Mon Mar 15 23:23:37 2004 +++ llvm-gcc/gcc/llvm-representation.h Tue Mar 16 01:06:12 2004 @@ -224,6 +224,14 @@ * referenced. This member is used when expanding cleanups. */ void *EnclosingScope; + + /* BlockID - If the "address" of this basic block is ever taken, assign the + * block an ID number. This ID number will be returned by any statements + * taking the address of the block, and will be used by the switch instruction + * used to do the indirect goto. If this value is null, the address of the + * block has not been taken yet. + */ + llvm_value *BlockID; } llvm_basicblock; llvm_basicblock *llvm_basicblock_new(const char *); @@ -254,8 +262,6 @@ llvm_ilist(llvm_argument , Arguments); /* List of arguments */ llvm_ilist(llvm_basicblock, BasicBlocks); /* List of basic blocks */ struct llvm_expand_info *ExpandInfo; - - int FunctionUsesVarArgs; /* True if function accesses variable args */ /* ForwardedFunction - This member is here only because we don't have a * replaceAllUsesWith equivalent in the C frontend. In C, we can create a From lattner at cs.uiuc.edu Tue Mar 16 01:10:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 01:10:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403160709.BAA21236@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.25 -> 1.26 --- Log message: First half of a patch to implement PR273: http://llvm.cs.uiuc.edu/PR273 : [llvm-gcc] "Address of label" GCC extension not implemented This is not exception correct, but should handle C just fine. I note that this exposes a bug in the JIT though, which I'll file. --- Diffs of the changes: (+115 -3) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.25 llvm-gcc/gcc/llvm-expand.c:1.26 --- llvm-gcc/gcc/llvm-expand.c:1.25 Mon Mar 15 23:23:37 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 01:09:47 2004 @@ -650,6 +650,21 @@ * TerminateBlock instead of throwing the exception. */ int ThrownExceptionsCallTerminate; + + /* NumAddrTakenBlocks - The number of basic blocks whose address has been + * taken. + */ + unsigned NumAddrTakenBlocks; + + /* IndirectGotoBlock - This block contains the switch instruction that is used + * to implement indirect gotos. This block is *ONLY* allowed to contain a + * load (the first entry) and a switch instruction on the load (which must be + * from the IndirectGotoValue alloca. The switch instruction contains one + * entry for each basic block that has its address taken. This block is + * created on demand, then inserted at the end of the function. + */ + llvm_value *IndirectGotoValue; /* The dynamic block id to go to. */ + llvm_basicblock *IndirectGotoBlock; } llvm_expand_info; /* add_scope_stack - Allocate and add a scope to the top of the scope list, with @@ -1654,7 +1669,7 @@ } /* getLabelDeclBlock - This is a wrapper function that is used to lazily create - llvm_basicblock's for labels on demand. + * llvm_basicblock's for labels on demand. */ static llvm_basicblock* getLabelDeclBlock(tree LD) { const char *Name; @@ -1669,6 +1684,41 @@ return BB; } +/* EnsureIndirectGotoBlockExists - This function ensures that the specified LLVM + * function has a block to be used for computed gotos. If not it creates one. + * In any case, it return the switch instruction at the end of the block and + * ensures that Fn->IndirectGoto* are not null. + */ +static llvm_instruction *EnsureIndirectGotoBlockExists(llvm_function *Fn) { + if (Fn->ExpandInfo->IndirectGotoBlock == 0) { + /* Create the value that we will load from to determine which destination to + * branch to. + */ + llvm_instruction *Load; + llvm_instruction *I = create_alloca_inst("computed_dest", UIntTy, + llvm_constant_uint_1); + insert_alloca_into_entry_block(Fn, I); + Fn->ExpandInfo->IndirectGotoValue = D2V(I); + Fn->ExpandInfo->IndirectGotoBlock = + llvm_basicblock_new("computed_branch_block"); + + /* Create and insert the load instruction */ + Load = create_load_inst("dest_block", Fn->ExpandInfo->IndirectGotoValue, 0); + llvm_ilist_push_back(llvm_instruction, + Fn->ExpandInfo->IndirectGotoBlock->Instructions, Load); + /* Create and insert the switch instruction. */ + I = llvm_instruction_new(VoidTy, "", O_Switch, 2); + I->Operands[0] = D2V(Load); + /* The default destination block will be filled in later! */ + llvm_ilist_push_back(llvm_instruction, + Fn->ExpandInfo->IndirectGotoBlock->Instructions, I); + return I; + } + return llvm_ilist_back(llvm_instruction, + Fn->ExpandInfo->IndirectGotoBlock->Instructions); +} + + /* Specify the location in the LLVM code of a label LABEL, which is a LABEL_DECL tree node. @@ -2058,8 +2108,20 @@ if (TREE_CODE(dest) == IDENTIFIER_NODE) abort (); if (TREE_CODE(dest) != LABEL_DECL) { - fprintf(stderr, "Computed gotos not supported!!!"); - LLVM_TODO_TREE(dest); + /* If this is a computed goto, evaluate the condition. */ + llvm_value *V = llvm_expand_expr(Fn, dest, 0); + V = cast_if_type_not_equal(Fn, V, UIntTy); + + /* Make sure the function knows that indirect gotos occur. */ + EnsureIndirectGotoBlockExists(Fn); + + append_inst(Fn, create_store_inst(V, Fn->ExpandInfo->IndirectGotoValue, 0)); + + /* FIXME: This is HORRIBLY INCORRECT in the presence of exception handlers. + * There should be one collector block per cleanup level! + */ + llvm_expand_goto_internal(Fn, Fn->ExpandInfo->IndirectGotoBlock, 1, 0); + return; } TREE_USED(dest) = 1; @@ -5021,6 +5083,43 @@ LLVM_TODO_TREE(exp); } + case LABEL_DECL: { + /* The user took the address of this label. */ + llvm_basicblock *BB = getLabelDeclBlock(exp); + if (DECL_CONTEXT(exp)) { + assert(TREE_CODE(DECL_CONTEXT(exp)) == FUNCTION_DECL && + "Address of label in nested function?"); + if (Fn == 0) { + /* We know that we must be expanding the label into the context of the + * function, despite the fact that we may have lost the value of Fn + * along the way. + */ + Fn = (llvm_function*)DECL_LLVM(DECL_CONTEXT(exp)); + assert(((llvm_value*)Fn)->VTy == Function); + } + } + + if (BB->BlockID == 0) { + /* If this is the first time the addr of this block is taken, assign it an + * ID, and add it to the indirect branch switch block. + */ + llvm_instruction *TheSwitch = EnsureIndirectGotoBlockExists(Fn); + llvm_switch_case *Case; + unsigned ID = Fn->ExpandInfo->NumAddrTakenBlocks++; + + BB->BlockID = llvm_constant_new_integral(UIntTy, ID); + + /* Update the switch instruction to include an entry for this block. */ + Case = xmalloc(sizeof(llvm_switch_case)); + Case->Next = TheSwitch->x.Switch.Cases; + TheSwitch->x.Switch.Cases = Case; + Case->Value = ID; + Case->Dest = BB; + } + Result = BB->BlockID; + break; + } + case PARM_DECL: if (!DECL_LLVM_SET_P (exp)) { error ("%Hprior parameter's size depends on '%D'", @@ -6642,6 +6741,19 @@ if (end_bindings) { LLVM_TODO(); expand_end_bindings (0, 0, 0); + } + + /* If there are indirect gotos in the function, insert the block for it. */ + if (Fn->ExpandInfo->IndirectGotoBlock) { + llvm_instruction *Switch = EnsureIndirectGotoBlockExists(Fn); + llvm_emit_label(Fn, Fn->ExpandInfo->IndirectGotoBlock); + + /* We never set the default destination for the switch instruction in this + * block. If there were addresses of blocks taken, make it one of the block + * destinations. We know that the default edge can never be taken. + */ + Switch->Operands[1] = Switch->x.Switch.Cases ? + Switch->x.Switch.Cases->Dest : Fn->ExpandInfo->IndirectGotoBlock; } if (Fn->ExpandInfo->RethrowBlock) { From lattner at cs.uiuc.edu Tue Mar 16 02:40:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:40:01 2004 Subject: [llvm-commits] CVS: llvm/lib/ExecutionEngine/ExecutionEngine.cpp Message-ID: <200403160839.CAA30820@zion.cs.uiuc.edu> Changes in directory llvm/lib/ExecutionEngine: ExecutionEngine.cpp updated: 1.48 -> 1.49 --- Log message: Fix PR296: http://llvm.cs.uiuc.edu/PR296 : [execution engines] Unhandled cast constant expression --- Diffs of the changes: (+17 -6) Index: llvm/lib/ExecutionEngine/ExecutionEngine.cpp diff -u llvm/lib/ExecutionEngine/ExecutionEngine.cpp:1.48 llvm/lib/ExecutionEngine/ExecutionEngine.cpp:1.49 --- llvm/lib/ExecutionEngine/ExecutionEngine.cpp:1.48 Sat Feb 14 23:54:06 2004 +++ llvm/lib/ExecutionEngine/ExecutionEngine.cpp Tue Mar 16 02:38:56 2004 @@ -179,19 +179,30 @@ // automatically fold, just the ones involving pointers won't. // Constant *Op = CE->getOperand(0); + GenericValue GV = getConstantValue(Op); // Handle cast of pointer to pointer... if (Op->getType()->getPrimitiveID() == C->getType()->getPrimitiveID()) - return getConstantValue(Op); + return GV; // Handle a cast of pointer to any integral type... if (isa(Op->getType()) && C->getType()->isIntegral()) - return getConstantValue(Op); + return GV; - // Handle cast of long to pointer... - if (isa(C->getType()) && (Op->getType() == Type::LongTy || - Op->getType() == Type::ULongTy)) - return getConstantValue(Op); + // Handle cast of integer to a pointer... + if (isa(C->getType()) && Op->getType()->isIntegral()) + switch (Op->getType()->getPrimitiveID()) { + case Type::BoolTyID: return PTOGV((void*)(uintptr_t)GV.BoolVal); + case Type::SByteTyID: return PTOGV((void*)( intptr_t)GV.SByteVal); + case Type::UByteTyID: return PTOGV((void*)(uintptr_t)GV.UByteVal); + case Type::ShortTyID: return PTOGV((void*)( intptr_t)GV.ShortVal); + case Type::UShortTyID: return PTOGV((void*)(uintptr_t)GV.UShortVal); + case Type::IntTyID: return PTOGV((void*)( intptr_t)GV.IntVal); + case Type::UIntTyID: return PTOGV((void*)(uintptr_t)GV.UIntVal); + case Type::LongTyID: return PTOGV((void*)( intptr_t)GV.LongVal); + case Type::ULongTyID: return PTOGV((void*)(uintptr_t)GV.ULongVal); + default: assert(0 && "Unknown integral type!"); + } break; } From lattner at cs.uiuc.edu Tue Mar 16 02:41:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:41:02 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403160840.CAA31284@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.147 -> 1.148 --- Log message: boog fixed --- Diffs of the changes: (+3 -1) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.147 llvm/docs/ReleaseNotes.html:1.148 --- llvm/docs/ReleaseNotes.html:1.147 Mon Mar 15 23:28:35 2004 +++ llvm/docs/ReleaseNotes.html Tue Mar 16 02:40:35 2004 @@ -220,6 +220,8 @@
  • CBE gives linkonce functions wrong linkage semantics
  • [JIT] Programs cannot resolve the fstat function
  • [indvars] Induction variable analysis violates LLVM invariants
    • +
  • [execution engines] Unhandled cast constant expression
    • + @@ -649,7 +651,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/16 05:28:35 $ + Last modified: $Date: 2004/03/16 08:40:35 $ From lattner at cs.uiuc.edu Tue Mar 16 02:42:00 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:42:00 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.1/docs/ReleaseNotes.html Message-ID: <200403160841.CAA31738@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.1/docs: ReleaseNotes.html updated: 1.35 -> 1.36 --- Log message: Boog found --- Diffs of the changes: (+2 -1) Index: llvm-www/releases/1.1/docs/ReleaseNotes.html diff -u llvm-www/releases/1.1/docs/ReleaseNotes.html:1.35 llvm-www/releases/1.1/docs/ReleaseNotes.html:1.36 --- llvm-www/releases/1.1/docs/ReleaseNotes.html:1.35 Mon Mar 15 23:28:54 2004 +++ llvm-www/releases/1.1/docs/ReleaseNotes.html Tue Mar 16 02:40:58 2004 @@ -397,6 +397,7 @@
  • [X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808
  • [JIT] Programs cannot resolve the fstat function
  • [indvars] Induction variable analysis violates LLVM invariants
    • +
  • [execution engines] Unhandled cast constant expression
    • @@ -764,7 +765,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/16 05:28:54 $ + Last modified: $Date: 2004/03/16 08:40:58 $ From lattner at cs.uiuc.edu Tue Mar 16 02:45:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:45:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403160844.CAA31778@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.26 -> 1.27 --- Log message: Begin numbering labels at 1 so that code that uses the null pointer as a sentinal value will work. --- Diffs of the changes: (+1 -1) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.26 llvm-gcc/gcc/llvm-expand.c:1.27 --- llvm-gcc/gcc/llvm-expand.c:1.26 Tue Mar 16 01:09:47 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 02:44:49 2004 @@ -5105,7 +5105,7 @@ */ llvm_instruction *TheSwitch = EnsureIndirectGotoBlockExists(Fn); llvm_switch_case *Case; - unsigned ID = Fn->ExpandInfo->NumAddrTakenBlocks++; + unsigned ID = ++Fn->ExpandInfo->NumAddrTakenBlocks; BB->BlockID = llvm_constant_new_integral(UIntTy, ID); From lattner at cs.uiuc.edu Tue Mar 16 02:50:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:50:01 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/CFrontend/2004-03-15-SimpleIndirectGoto.c Message-ID: <200403160849.CAA31859@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/CFrontend: 2004-03-15-SimpleIndirectGoto.c added (r1.1) --- Log message: New testcase --- Diffs of the changes: (+21 -0) Index: llvm/test/Regression/CFrontend/2004-03-15-SimpleIndirectGoto.c diff -c /dev/null llvm/test/Regression/CFrontend/2004-03-15-SimpleIndirectGoto.c:1.1 *** /dev/null Tue Mar 16 02:49:59 2004 --- llvm/test/Regression/CFrontend/2004-03-15-SimpleIndirectGoto.c Tue Mar 16 02:49:48 2004 *************** *** 0 **** --- 1,21 ---- + int code[]={0,0,0,0,1}; + void foo(int x) { + volatile int b; + b = 0xffffffff; + } + void bar(int *pc) { + static const void *l[] = {&&lab0, &&end}; + + foo(0); + goto *l[*pc]; + lab0: + foo(0); + pc++; + goto *l[*pc]; + end: + return; + } + int main() { + bar(code); + return 0; + } From lattner at cs.uiuc.edu Tue Mar 16 02:51:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:51:01 2004 Subject: [llvm-commits] CVS: llvm/test/Programs/SingleSource/Regression/C/2004-03-15-IndirectGoto.c Message-ID: <200403160850.CAA32002@zion.cs.uiuc.edu> Changes in directory llvm/test/Programs/SingleSource/Regression/C: 2004-03-15-IndirectGoto.c added (r1.1) --- Log message: New testcase for PR273: http://llvm.cs.uiuc.edu/PR273 --- Diffs of the changes: (+16 -0) Index: llvm/test/Programs/SingleSource/Regression/C/2004-03-15-IndirectGoto.c diff -c /dev/null llvm/test/Programs/SingleSource/Regression/C/2004-03-15-IndirectGoto.c:1.1 *** /dev/null Tue Mar 16 02:50:43 2004 --- llvm/test/Programs/SingleSource/Regression/C/2004-03-15-IndirectGoto.c Tue Mar 16 02:50:33 2004 *************** *** 0 **** --- 1,16 ---- + #include + int main() { + static const void *L[] = {&&L1, &&L2, &&L3, &&L4, 0 }; + unsigned i = 0; + printf("A\n"); + L1: + printf("B\n"); + L2: + printf("C\n"); + L3: + printf("D\n"); + goto *L[i++]; + L4: + printf("E\n"); + return 0; + } From lattner at cs.uiuc.edu Tue Mar 16 02:55:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 02:55:01 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403160854.CAA32475@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.148 -> 1.149 --- Log message: Implement a new feature in the CFE, moving a GCC extension from the unsupported to the supported list --- Diffs of the changes: (+5 -2) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.148 llvm/docs/ReleaseNotes.html:1.149 --- llvm/docs/ReleaseNotes.html:1.148 Tue Mar 16 02:40:35 2004 +++ llvm/docs/ReleaseNotes.html Tue Mar 16 02:54:07 2004 @@ -140,6 +140,9 @@ & Sparc native code generators
  • The C/C++ front-end now support the GCC __builtin_return_address and __builtin_frame_address extensions.
  • [X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808
    • +
  • The C/C++ front-end now supports +the "labels as values" GCC extension, often used to build "threaded interpreters".
    • + @@ -396,7 +399,6 @@ the following extensions are known to not be supported:
    1. Local Labels: Labels local to a block.
      2. -
    2. Labels as Values: Getting pointers to labels and computed gotos.
    3. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
    4. Constructing Calls: Dispatching a call to another function.
    5. Extended Asm: Assembler instructions with C expressions as operands.
      6. @@ -467,6 +469,7 @@

      The following extensions are known to be supported:

        +
      1. Labels as Values: Getting pointers to labels and computed gotos.
      2. Statement Exprs: Putting statements and declarations inside expressions.
      3. Typeof: typeof: referring to the type of an expression.
      4. Lvalues: Using ?:, "," and casts in lvalues.
        5. @@ -651,7 +654,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/16 08:40:35 $ + Last modified: $Date: 2004/03/16 08:54:07 $ From lattner at cs.uiuc.edu Tue Mar 16 03:02:00 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 03:02:00 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403160901.DAA00531@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.149 -> 1.150 --- Log message: Fix bug in bug name. It must be the painkillers that I haven't been taking --- Diffs of the changes: (+2 -2) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.149 llvm/docs/ReleaseNotes.html:1.150 --- llvm/docs/ReleaseNotes.html:1.149 Tue Mar 16 02:54:07 2004 +++ llvm/docs/ReleaseNotes.html Tue Mar 16 03:01:10 2004 @@ -242,7 +242,7 @@
      5. [llvmgcc] Invalid code created for complex division operation
      6. [llvmgcc] Incorrect code generation for pointer subtraction
      7. [llvmg++] Crash assigning pointers-to-members with casted types
        8. -
      8. [llvm-g++] Cleanups and exception handlers don't mix properly
        9. +
      9. [llvm-g++] Cleanups and gotos don't mix properly
      @@ -654,7 +654,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/16 08:54:07 $ + Last modified: $Date: 2004/03/16 09:01:10 $ From lattner at cs.uiuc.edu Tue Mar 16 03:02:03 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 03:02:03 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.1/docs/ReleaseNotes.html Message-ID: <200403160901.DAA01027@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.1/docs: ReleaseNotes.html updated: 1.36 -> 1.37 --- Log message: Fix bug in bug name. It must be the painkillers that I haven't been taking --- Diffs of the changes: (+2 -2) Index: llvm-www/releases/1.1/docs/ReleaseNotes.html diff -u llvm-www/releases/1.1/docs/ReleaseNotes.html:1.36 llvm-www/releases/1.1/docs/ReleaseNotes.html:1.37 --- llvm-www/releases/1.1/docs/ReleaseNotes.html:1.36 Tue Mar 16 02:40:58 2004 +++ llvm-www/releases/1.1/docs/ReleaseNotes.html Tue Mar 16 03:01:47 2004 @@ -454,7 +454,7 @@
    6. [llvmg++] Crash assigning pointers-to-members with casted types
      7. -
    7. [llvm-g++] Cleanups and exception handlers don't mix properly
      8. +
    8. [llvm-g++] Cleanups and gotos don't mix properly
      9. @@ -765,7 +765,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/16 08:40:58 $ + Last modified: $Date: 2004/03/16 09:01:47 $ From lattner at cs.uiuc.edu Tue Mar 16 13:46:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 13:46:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/SimplifyCFG.cpp Message-ID: <200403161945.NAA07024@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Utils: SimplifyCFG.cpp updated: 1.29 -> 1.30 --- Log message: Do not copy gigantic switch instructions --- Diffs of the changes: (+8 -1) Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp diff -u llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1.29 llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1.30 --- llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1.29 Sat Feb 28 15:28:10 2004 +++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp Tue Mar 16 13:45:07 2004 @@ -331,8 +331,15 @@ // isValueEqualityComparison - Return true if the specified terminator checks to // see if a value is equal to constant integer value. static Value *isValueEqualityComparison(TerminatorInst *TI) { - if (SwitchInst *SI = dyn_cast(TI)) + if (SwitchInst *SI = dyn_cast(TI)) { + // Do not permit merging of large switch instructions into their + // predecessors unless there is only one predecessor. + if (SI->getNumSuccessors() * std::distance(pred_begin(SI->getParent()), + pred_end(SI->getParent())) > 128) + return 0; + return SI->getCondition(); + } if (BranchInst *BI = dyn_cast(TI)) if (BI->isConditional() && BI->getCondition()->hasOneUse()) if (SetCondInst *SCI = dyn_cast(BI->getCondition())) From lattner at cs.uiuc.edu Tue Mar 16 13:46:05 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 13:46:05 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/TailDuplication.cpp Message-ID: <200403161945.NAA07034@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: TailDuplication.cpp updated: 1.15 -> 1.16 --- Log message: Do not copy gigantic switch instructions --- Diffs of the changes: (+11 -1) Index: llvm/lib/Transforms/Scalar/TailDuplication.cpp diff -u llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.15 llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.16 --- llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.15 Sun Feb 29 19:12:13 2004 +++ llvm/lib/Transforms/Scalar/TailDuplication.cpp Tue Mar 16 13:45:22 2004 @@ -91,7 +91,8 @@ if (Dest == BI->getParent()) return false; // Do not loop infinitely! // Do not inline a block if we will just get another branch to the same block! - if (BranchInst *DBI = dyn_cast(Dest->getTerminator())) + TerminatorInst *DTI = Dest->getTerminator(); + if (BranchInst *DBI = dyn_cast(DTI)) if (DBI->isUnconditional() && DBI->getSuccessor(0) == Dest) return false; // Do not loop infinitely! @@ -110,6 +111,15 @@ for (unsigned Size = 0; I != Dest->end(); ++Size, ++I) if (Size == 6) return false; // The block is too large... + + // Do not tail duplicate a block that has thousands of successors into a block + // with a single successor if the block has many other predecessors. This can + // cause an N^2 explosion in CFG edges (and PHI node entries), as seen in + // cases that have a large number of indirect gotos. + if (DTI->getNumSuccessors() > 8) + if (std::distance(PI, PE) * DTI->getNumSuccessors() > 128) + return false; + return true; } From lattner at cs.uiuc.edu Tue Mar 16 13:51:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 13:51:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/SCCP.cpp Message-ID: <200403161950.NAA07733@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: SCCP.cpp updated: 1.91 -> 1.92 --- Log message: Do not try to optimize PHI nodes with incredibly high degree. This reduces SCCP time from 615s to 1.49s on a large testcase that has a gigantic switch statement that all of the blocks in the function go to (an intepreter). --- Diffs of the changes: (+7 -0) Index: llvm/lib/Transforms/Scalar/SCCP.cpp diff -u llvm/lib/Transforms/Scalar/SCCP.cpp:1.91 llvm/lib/Transforms/Scalar/SCCP.cpp:1.92 --- llvm/lib/Transforms/Scalar/SCCP.cpp:1.91 Thu Mar 11 23:52:44 2004 +++ llvm/lib/Transforms/Scalar/SCCP.cpp Tue Mar 16 13:49:59 2004 @@ -500,6 +500,13 @@ return; // Quick exit } + // Super-extra-high-degree PHI nodes are unlikely to ever be marked constant, + // and slow us down a lot. Just mark them overdefined. + if (PN.getNumIncomingValues() > 64) { + markOverdefined(PNIV, &PN); + return; + } + // Look at all of the executable operands of the PHI node. If any of them // are overdefined, the PHI becomes overdefined as well. If they are all // constant, and they agree with each other, the PHI becomes the identical From lattner at cs.uiuc.edu Tue Mar 16 13:54:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 13:54:02 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/ExprTypeConvert.cpp Message-ID: <200403161953.NAA08365@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms: ExprTypeConvert.cpp updated: 1.89 -> 1.90 --- Log message: Punt if we see gigantic PHI nodes. This improves a huge interpreter loop testcase from 32.5s in -raise to take .3s --- Diffs of the changes: (+6 -0) Index: llvm/lib/Transforms/ExprTypeConvert.cpp diff -u llvm/lib/Transforms/ExprTypeConvert.cpp:1.89 llvm/lib/Transforms/ExprTypeConvert.cpp:1.90 --- llvm/lib/Transforms/ExprTypeConvert.cpp:1.89 Sun Feb 8 22:13:57 2004 +++ llvm/lib/Transforms/ExprTypeConvert.cpp Tue Mar 16 13:52:53 2004 @@ -206,6 +206,9 @@ } case Instruction::PHI: { PHINode *PN = cast(I); + // Be conservative if we find a giant PHI node. + if (PN->getNumIncomingValues() > 32) return false; + for (unsigned i = 0; i < PN->getNumIncomingValues(); ++i) if (!ExpressionConvertibleToType(PN->getIncomingValue(i), Ty, CTMap, TD)) return false; @@ -815,6 +818,9 @@ case Instruction::PHI: { PHINode *PN = cast(I); + // Be conservative if we find a giant PHI node. + if (PN->getNumIncomingValues() > 32) return false; + for (unsigned i = 0; i < PN->getNumIncomingValues(); ++i) if (!ExpressionConvertibleToType(PN->getIncomingValue(i), Ty, CTMap, TD)) return false; From lattner at cs.uiuc.edu Tue Mar 16 14:06:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 14:06:01 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Analysis/DSGraph/strcpy.ll Message-ID: <200403162005.OAA08606@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Analysis/DSGraph: strcpy.ll updated: 1.1 -> 1.2 --- Log message: Fix testcase --- Diffs of the changes: (+1 -1) Index: llvm/test/Regression/Analysis/DSGraph/strcpy.ll diff -u llvm/test/Regression/Analysis/DSGraph/strcpy.ll:1.1 llvm/test/Regression/Analysis/DSGraph/strcpy.ll:1.2 --- llvm/test/Regression/Analysis/DSGraph/strcpy.ll:1.1 Fri Feb 20 17:05:43 2004 +++ llvm/test/Regression/Analysis/DSGraph/strcpy.ll Tue Mar 16 14:04:55 2004 @@ -3,7 +3,7 @@ ; has no defined way to check for this, so DSA can know that strcpy doesn't ; require merging the input arguments. -; RUN: analyze %s -datastructure-gc --dsgc-abort-if-merged=A,B --dsgc-check-flags=A:SM,B:SR --dsgc-dspass=bu +; RUN: analyze %s -datastructure-gc --dsgc-abort-if-merged=A,B --dsgc-check-flags=A:ASM,B:ASR --dsgc-dspass=bu implementation From lattner at cs.uiuc.edu Tue Mar 16 14:59:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 14:59:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403162058.OAA09442@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.27 -> 1.28 --- Log message: Fix compile warning Fix a regression in testcase C++Frontend/2004-01-11-DynamicInitializedConstant.cpp.tr that was introduced when fixing CFrontend/2004-03-07-ExternalConstant.c.tr --- Diffs of the changes: (+6 -3) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.27 llvm-gcc/gcc/llvm-expand.c:1.28 --- llvm-gcc/gcc/llvm-expand.c:1.27 Tue Mar 16 02:44:49 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 14:58:43 2004 @@ -6752,8 +6752,8 @@ * block. If there were addresses of blocks taken, make it one of the block * destinations. We know that the default edge can never be taken. */ - Switch->Operands[1] = Switch->x.Switch.Cases ? - Switch->x.Switch.Cases->Dest : Fn->ExpandInfo->IndirectGotoBlock; + Switch->Operands[1] = D2V(Switch->x.Switch.Cases ? + Switch->x.Switch.Cases->Dest : Fn->ExpandInfo->IndirectGotoBlock); } if (Fn->ExpandInfo->RethrowBlock) { @@ -6951,8 +6951,11 @@ G->Linkage = L_LinkOnce; } else if (*/DECL_WEAK(decl) || DECL_COMMON(decl) || DECL_VIRTUAL_P(decl)) G->Linkage = L_Weak; + if (TREE_READONLY(decl) && !TREE_SIDE_EFFECTS(decl) && - (!DECL_INITIAL(decl) || TREE_CONSTANT(DECL_INITIAL(decl)))) + DECL_EXTERNAL(decl) || + (DECL_INITIAL(decl) != error_mark_node && /* no ctor? */ + DECL_INITIAL(decl) && TREE_CONSTANT(DECL_INITIAL(decl)))) G->isConstant = 1; /* Allociate the LLVM global with the tree global */ From lattner at cs.uiuc.edu Tue Mar 16 15:11:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:11:01 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/IndVarsSimplify/2003-09-12-MultiplePred.ll Message-ID: <200403162110.PAA09682@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/IndVarsSimplify: 2003-09-12-MultiplePred.ll updated: 1.2 -> 1.3 --- Log message: Fix test --- Diffs of the changes: (+1 -1) Index: llvm/test/Regression/Transforms/IndVarsSimplify/2003-09-12-MultiplePred.ll diff -u llvm/test/Regression/Transforms/IndVarsSimplify/2003-09-12-MultiplePred.ll:1.2 llvm/test/Regression/Transforms/IndVarsSimplify/2003-09-12-MultiplePred.ll:1.3 --- llvm/test/Regression/Transforms/IndVarsSimplify/2003-09-12-MultiplePred.ll:1.2 Tue Sep 16 10:29:30 2003 +++ llvm/test/Regression/Transforms/IndVarsSimplify/2003-09-12-MultiplePred.ll Tue Mar 16 15:10:15 2004 @@ -4,7 +4,7 @@ br bool true, label %LoopHead, label %LoopHead LoopHead: - %A = phi int [0, %0], [0, %0], [%B, %LoopHead] + %A = phi int [7, %0], [7, %0], [%B, %LoopHead] %B = add int %A, 1 br bool false, label %LoopHead, label %Out Out: From lattner at cs.uiuc.edu Tue Mar 16 15:37:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:37:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403162136.PAA09895@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.28 -> 1.29 --- Log message: Parenthesize correctly --- Diffs of the changes: (+3 -3) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.28 llvm-gcc/gcc/llvm-expand.c:1.29 --- llvm-gcc/gcc/llvm-expand.c:1.28 Tue Mar 16 14:58:43 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 15:36:47 2004 @@ -6953,9 +6953,9 @@ G->Linkage = L_Weak; if (TREE_READONLY(decl) && !TREE_SIDE_EFFECTS(decl) && - DECL_EXTERNAL(decl) || - (DECL_INITIAL(decl) != error_mark_node && /* no ctor? */ - DECL_INITIAL(decl) && TREE_CONSTANT(DECL_INITIAL(decl)))) + (DECL_EXTERNAL(decl) || + (DECL_INITIAL(decl) != error_mark_node && /* no ctor? */ + DECL_INITIAL(decl) && TREE_CONSTANT(DECL_INITIAL(decl))))) G->isConstant = 1; /* Allociate the LLVM global with the tree global */ From lattner at cs.uiuc.edu Tue Mar 16 15:40:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:40:01 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403162139.PAA09941@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.150 -> 1.151 --- Log message: Bug not fixed after all --- Diffs of the changes: (+4 -2) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.150 llvm/docs/ReleaseNotes.html:1.151 --- llvm/docs/ReleaseNotes.html:1.150 Tue Mar 16 03:01:10 2004 +++ llvm/docs/ReleaseNotes.html Tue Mar 16 15:39:04 2004 @@ -238,7 +238,6 @@
    9. [llvmg++] Dynamically initialized constants cannot be marked 'constant'
    10. [llvmgcc] floating-point unary minus is incorrect for +0.0
    11. [llvm-gcc] miscompilation of 'X = Y = Z' with aggregate values
      12. -
    12. [llvm-gcc] miscompilation when a function is re-declared as static
    13. [llvmgcc] Invalid code created for complex division operation
    14. [llvmgcc] Incorrect code generation for pointer subtraction
    15. [llvmg++] Crash assigning pointers-to-members with casted types
      16. @@ -367,6 +366,9 @@ with the largest union member. + +
    16. [llvm-gcc] Error when an implicitly external function is re-declared as static
      17. + @@ -654,7 +656,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/16 09:01:10 $ + Last modified: $Date: 2004/03/16 21:39:04 $ From lattner at cs.uiuc.edu Tue Mar 16 15:41:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:41:02 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.1/docs/ReleaseNotes.html Message-ID: <200403162140.PAA10867@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.1/docs: ReleaseNotes.html updated: 1.37 -> 1.38 --- Log message: Bug not actually fixed in 1.2 --- Diffs of the changes: (+3 -3) Index: llvm-www/releases/1.1/docs/ReleaseNotes.html diff -u llvm-www/releases/1.1/docs/ReleaseNotes.html:1.37 llvm-www/releases/1.1/docs/ReleaseNotes.html:1.38 --- llvm-www/releases/1.1/docs/ReleaseNotes.html:1.37 Tue Mar 16 03:01:47 2004 +++ llvm-www/releases/1.1/docs/ReleaseNotes.html Tue Mar 16 15:40:04 2004 @@ -425,6 +425,8 @@ } +
    17. [llvm-gcc] Error when an implicitly external function is re-declared as static
      18. +
    18. Initialization of global union variables can only be done with the largest @@ -446,8 +448,6 @@
    19. [llvmgcc] Structure copies result in a LOT of code
      20. -
    20. [llvm-gcc] miscompilation when a function is re-declared as static
      21. -
    21. [llvmgcc] Invalid code created for complex division operation
    22. [llvmgcc] Incorrect code generation for pointer subtraction
      23. @@ -765,7 +765,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/16 09:01:47 $ + Last modified: $Date: 2004/03/16 21:40:04 $ From gaeke at cs.uiuc.edu Tue Mar 16 15:49:02 2004 From: gaeke at cs.uiuc.edu (Brian Gaeke) Date: Tue Mar 16 15:49:02 2004 Subject: [llvm-commits] CVS: llvm/tools/llc/llc.cpp Message-ID: <200403162147.PAA11326@zion.cs.uiuc.edu> Changes in directory llvm/tools/llc: llc.cpp updated: 1.95 -> 1.96 --- Log message: Add a better head-of-file comment. --- Diffs of the changes: (+3 -1) Index: llvm/tools/llc/llc.cpp diff -u llvm/tools/llc/llc.cpp:1.95 llvm/tools/llc/llc.cpp:1.96 --- llvm/tools/llc/llc.cpp:1.95 Thu Mar 11 12:16:33 2004 +++ llvm/tools/llc/llc.cpp Tue Mar 16 15:47:20 2004 @@ -7,7 +7,9 @@ // //===----------------------------------------------------------------------===// // -// This is the llc code generator. +// This is the llc code generator driver. It provides a convenient +// command-line interface for generating native assembly-language code +// or C code, given LLVM bytecode. // //===----------------------------------------------------------------------===// From lattner at cs.uiuc.edu Tue Mar 16 15:53:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:53:02 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403162152.PAA11445@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.29 -> 1.30 --- Log message: Fix PR297: http://llvm.cs.uiuc.edu/PR297 : [llvmgcc] Crash on auto register variable with specific register specified --- Diffs of the changes: (+3 -1) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.29 llvm-gcc/gcc/llvm-expand.c:1.30 --- llvm-gcc/gcc/llvm-expand.c:1.29 Tue Mar 16 15:36:47 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 15:51:49 2004 @@ -2423,7 +2423,9 @@ /* Let the back-end know about DECL. */ static void llvm_emit_local_var (llvm_function *Fn, tree decl) { if (DECL_C_HARD_REGISTER (decl)) { - LLVM_TODO_TREE(decl); + warning ("%Hllvm doesn't support asm specifier on '%D'", + &DECL_SOURCE_LOCATION (decl), decl); + #if 0 /* The user specified an assembler name for this variable. Set that up now. */ From lattner at cs.uiuc.edu Tue Mar 16 15:53:05 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:53:05 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/CFrontend/2004-03-16-AsmRegisterCrash.c Message-ID: <200403162152.PAA11460@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/CFrontend: 2004-03-16-AsmRegisterCrash.c added (r1.1) --- Log message: New testcase for PR297: http://llvm.cs.uiuc.edu/PR297 --- Diffs of the changes: (+4 -0) Index: llvm/test/Regression/CFrontend/2004-03-16-AsmRegisterCrash.c diff -c /dev/null llvm/test/Regression/CFrontend/2004-03-16-AsmRegisterCrash.c:1.1 *** /dev/null Tue Mar 16 15:52:34 2004 --- llvm/test/Regression/CFrontend/2004-03-16-AsmRegisterCrash.c Tue Mar 16 15:52:24 2004 *************** *** 0 **** --- 1,4 ---- + int foo() { + register int X __asm__("ebx"); + return X; + } From lattner at cs.uiuc.edu Tue Mar 16 15:56:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:56:01 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403162155.PAA11956@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.151 -> 1.152 --- Log message: Bug fixed --- Diffs of the changes: (+2 -1) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.151 llvm/docs/ReleaseNotes.html:1.152 --- llvm/docs/ReleaseNotes.html:1.151 Tue Mar 16 15:39:04 2004 +++ llvm/docs/ReleaseNotes.html Tue Mar 16 15:55:23 2004 @@ -242,6 +242,7 @@
    23. [llvmgcc] Incorrect code generation for pointer subtraction
    24. [llvmg++] Crash assigning pointers-to-members with casted types
    25. [llvm-g++] Cleanups and gotos don't mix properly
      26. +
    26. [llvmgcc] Crash on auto register variable with specific register specified
    @@ -656,7 +657,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/16 21:39:04 $ + Last modified: $Date: 2004/03/16 21:55:23 $ From lattner at cs.uiuc.edu Tue Mar 16 15:56:04 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 15:56:04 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.1/docs/ReleaseNotes.html Message-ID: <200403162155.PAA12410@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.1/docs: ReleaseNotes.html updated: 1.38 -> 1.39 --- Log message: Bug found --- Diffs of the changes: (+3 -1) Index: llvm-www/releases/1.1/docs/ReleaseNotes.html diff -u llvm-www/releases/1.1/docs/ReleaseNotes.html:1.38 llvm-www/releases/1.1/docs/ReleaseNotes.html:1.39 --- llvm-www/releases/1.1/docs/ReleaseNotes.html:1.38 Tue Mar 16 15:40:04 2004 +++ llvm-www/releases/1.1/docs/ReleaseNotes.html Tue Mar 16 15:55:42 2004 @@ -455,6 +455,8 @@
  • [llvmg++] Crash assigning pointers-to-members with casted types
  • [llvm-g++] Cleanups and gotos don't mix properly
    • + +
  • [llvmgcc] Crash on auto register variable with specific register specified
    • @@ -765,7 +767,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/16 21:40:04 $ + Last modified: $Date: 2004/03/16 21:55:42 $ From lattner at cs.uiuc.edu Tue Mar 16 17:09:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 17:09:02 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/TailDup/basictest2.ll Message-ID: <200403162308.RAA21104@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/TailDup: basictest2.ll added (r1.1) --- Log message: Another simple testcase --- Diffs of the changes: (+17 -0) Index: llvm/test/Regression/Transforms/TailDup/basictest2.ll diff -c /dev/null llvm/test/Regression/Transforms/TailDup/basictest2.ll:1.1 *** /dev/null Tue Mar 16 17:08:02 2004 --- llvm/test/Regression/Transforms/TailDup/basictest2.ll Tue Mar 16 17:07:52 2004 *************** *** 0 **** --- 1,17 ---- + ; RUN: llvm-as < %s | opt -tailduplicate -disable-output + + void %ab() { + entry: + br label %loopentry.5 + + loopentry.5: + %poscnt.1 = phi long [ 0, %entry ], [ %tmp.289, %no_exit.5 ] + %tmp.289 = shr long %poscnt.1, ubyte 1 + br bool false, label %no_exit.5, label %loopexit.5 + + no_exit.5: + br label %loopentry.5 + + loopexit.5: + ret void + } From lattner at cs.uiuc.edu Tue Mar 16 17:24:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 17:24:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/DemoteRegToStack.cpp Message-ID: <200403162323.RAA23640@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Utils: DemoteRegToStack.cpp updated: 1.9 -> 1.10 --- Log message: This code was both incredibly complex and incredibly broken. Fix it. --- Diffs of the changes: (+58 -138) Index: llvm/lib/Transforms/Utils/DemoteRegToStack.cpp diff -u llvm/lib/Transforms/Utils/DemoteRegToStack.cpp:1.9 llvm/lib/Transforms/Utils/DemoteRegToStack.cpp:1.10 --- llvm/lib/Transforms/Utils/DemoteRegToStack.cpp:1.9 Sat Mar 13 20:13:34 2004 +++ llvm/lib/Transforms/Utils/DemoteRegToStack.cpp Tue Mar 16 17:23:11 2004 @@ -8,156 +8,76 @@ //===----------------------------------------------------------------------===// // // This file provide the function DemoteRegToStack(). This function takes a -// virtual register computed by an Instruction& X and replaces it with a slot in +// virtual register computed by an Instruction and replaces it with a slot in // the stack frame, allocated via alloca. It returns the pointer to the -// AllocaInst inserted. +// AllocaInst inserted. After this function is called on an instruction, we are +// guaranteed that the only user of the instruction is a store that is +// immediately after it. // //===----------------------------------------------------------------------===// #include "llvm/Transforms/Utils/Local.h" #include "llvm/Function.h" -#include "llvm/iMemory.h" -#include "llvm/iPHINode.h" -#include "llvm/iTerminators.h" -#include "llvm/Type.h" -#include "Support/hash_set" +#include "llvm/Instructions.h" using namespace llvm; -typedef hash_set PhiSet; -typedef hash_set::iterator PhiSetIterator; - -// Helper function to push a phi *and* all its operands to the worklist! -// Do not push an instruction if it is already in the result set of Phis to go. -static inline void PushOperandsOnWorkList(std::vector& workList, - PhiSet& phisToGo, PHINode* phiN) { - for (User::op_iterator OI = phiN->op_begin(), OE = phiN->op_end(); - OI != OE; ++OI) { - Instruction* opI = cast(OI); - if (!isa(opI) || !phisToGo.count(cast(opI))) - workList.push_back(opI); - } -} - -static void FindPhis(Instruction& X, PhiSet& phisToGo) { - std::vector workList; - workList.push_back(&X); - - // Handle the case that X itself is a Phi! - if (PHINode* phiX = dyn_cast(&X)) { - phisToGo.insert(phiX); - PushOperandsOnWorkList(workList, phisToGo, phiX); - } - - // Now use a worklist to find all phis reachable from X, and - // (recursively) all phis reachable from operands of such phis. - while (!workList.empty()) { - Instruction *I = workList.back(); - workList.pop_back(); - for (Value::use_iterator UI = I->use_begin(), E = I->use_end(); UI!=E; ++UI) - if (PHINode* phiN = dyn_cast(*UI)) - if (phisToGo.find(phiN) == phisToGo.end()) { - // Seeing this phi for the first time: it must go! - phisToGo.insert(phiN); - workList.push_back(phiN); - PushOperandsOnWorkList(workList, phisToGo, phiN); +/// DemoteRegToStack - This function takes a virtual register computed by an +/// Instruction and replaces it with a slot in the stack frame, allocated via +/// alloca. This allows the CFG to be changed around without fear of +/// invalidating the SSA information for the value. It returns the pointer to +/// the alloca inserted to create a stack slot for I. +/// +AllocaInst* llvm::DemoteRegToStack(Instruction &I) { + if (I.use_empty()) return 0; // nothing to do! + + // Create a stack slot to hold the value. + Function *F = I.getParent()->getParent(); + AllocaInst *Slot = new AllocaInst(I.getType(), 0, I.getName(), + F->getEntryBlock().begin()); + + // Change all of the users of the instruction to read from the stack slot + // instead. + while (!I.use_empty()) { + Instruction *U = cast(I.use_back()); + if (PHINode *PN = dyn_cast(U)) { + // If this is a PHI node, we can't insert a load of the value before the + // use. Instead, insert the load in the predecessor block corresponding + // to the incoming value. + // + // Note that if there are multiple edges from a basic block to this PHI + // node that we'll insert multiple loads. Since DemoteRegToStack requires + // a mem2reg pass after it (to produce reasonable code), we don't care. + for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) + if (PN->getIncomingValue(i) == &I) { + // Insert the load into the predecessor block + Value *V = new LoadInst(Slot, I.getName()+".reload", + PN->getIncomingBlock(i)->getTerminator()); + PN->setIncomingValue(i, V); } - } -} - -// Insert loads before all uses of I, except uses in Phis -// since all such Phis *must* be deleted. -static void LoadBeforeUses(Instruction* def, AllocaInst* XSlot) { - for (unsigned nPhis = 0; def->use_size() - nPhis > 0; ) { - Instruction* useI = cast(def->use_back()); - if (!isa(useI)) { - LoadInst* loadI = - new LoadInst(XSlot, std::string("Load")+XSlot->getName(), useI); - useI->replaceUsesOfWith(def, loadI); - } else - ++nPhis; - } -} - -static void AddLoadsAndStores(AllocaInst* XSlot, Instruction& X, - PhiSet& phisToGo) { - for (PhiSetIterator PI=phisToGo.begin(), PE=phisToGo.end(); PI != PE; ++PI) { - PHINode* pn = *PI; - - // First, insert loads before all uses except uses in Phis. - // Do this first because new stores will appear as uses also! - LoadBeforeUses(pn, XSlot); - - // For every incoming operand of the Phi, insert a store either - // just after the instruction defining the value or just before the - // predecessor of the Phi if the value is a formal, not an instruction. - // - for (unsigned i=0, N=pn->getNumIncomingValues(); i < N; ++i) { - Value* phiOp = pn->getIncomingValue(i); - if (phiOp != &X && - (!isa(phiOp) || !phisToGo.count(cast(phiOp)))) { - // This operand is not a phi that will be deleted: need to store. - assert(!isa(phiOp)); - - Instruction* storeBefore; - if (Instruction* I = dyn_cast(phiOp)) { - // phiOp is an instruction, store its result right after it. - assert(I->getNext() && "Non-terminator without successor?"); - storeBefore = I->getNext(); - } else { - // If not, it must be a formal: store it at the end of the - // predecessor block of the Phi (*not* at function entry!). - storeBefore = pn->getIncomingBlock(i)->getTerminator(); - } - - // Create instr. to store the value of phiOp before `insertBefore' - StoreInst* storeI = new StoreInst(phiOp, XSlot, storeBefore); - } + } else { + // If this is a normal instruction, just insert a load. + Value *V = new LoadInst(Slot, I.getName()+".reload", U); + U->replaceUsesOfWith(&I, V); } } -} -//---------------------------------------------------------------------------- -// function DemoteRegToStack() -// -// This function takes a virtual register computed by an -// Instruction& X and replaces it with a slot in the stack frame, -// allocated via alloca. It has to: -// (1) Identify all Phi operations that have X as an operand and -// transitively other Phis that use such Phis; -// (2) Store all values merged with X via Phi operations to the stack slot; -// (3) Load the value from the stack slot just before any use of X or any -// of the Phis that were eliminated; and -// (4) Delete all the Phis, which should all now be dead. -// -// Returns the pointer to the alloca inserted to create a stack slot for X. -// -AllocaInst* llvm::DemoteRegToStack(Instruction& X) { - if (X.getType() == Type::VoidTy) - return 0; // nothing to do! - - // Find all Phis involving X or recursively using such Phis or Phis - // involving operands of such Phis (essentially all Phis in the "web" of X) - PhiSet phisToGo; - FindPhis(X, phisToGo); - - // Create a stack slot to hold X - Function* parentFunc = X.getParent()->getParent(); - AllocaInst *XSlot = new AllocaInst(X.getType(), 0, X.getName(), - parentFunc->getEntryBlock().begin()); - - - // Insert loads before all uses of X and (*only then*) insert store after X - assert(X.getNext() && "Non-terminator (since non-void) with no successor?"); - LoadBeforeUses(&X, XSlot); - StoreInst* storeI = new StoreInst(&X, XSlot, X.getNext()); - - // Do the same for all the phis that will be deleted - AddLoadsAndStores(XSlot, X, phisToGo); - - // Delete the phis and return the alloca instruction - for (PhiSetIterator PI = phisToGo.begin(), E = phisToGo.end(); PI != E; ++PI) - (*PI)->getParent()->getInstList().erase(*PI); - return XSlot; + // Insert stores of the computed value into the stack slot. We have to be + // careful is I is an invoke instruction though, because we can't insert the + // store AFTER the terminator instruction. + if (!isa(I)) { + BasicBlock::iterator InsertPt = &I; + for (++InsertPt; isa(InsertPt); ++InsertPt) + /* empty */; // Don't insert before any PHI nodes. + new StoreInst(&I, Slot, InsertPt); + } else { + // FIXME: We cannot yet demote invoke instructions to the stack, because + // doing so would require breaking critical edges. This should be fixed + // eventually. + assert(0 && + "Cannot demote the value computed by an invoke instruction yet!"); + } + + return Slot; } From lattner at cs.uiuc.edu Tue Mar 16 17:38:00 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 17:38:00 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/TailDuplication.cpp Message-ID: <200403162336.RAA25415@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: TailDuplication.cpp updated: 1.17 -> 1.18 --- Log message: Fix bug in previous checkin --- Diffs of the changes: (+7 -2) Index: llvm/lib/Transforms/Scalar/TailDuplication.cpp diff -u llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.17 llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.18 --- llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.17 Tue Mar 16 17:29:09 2004 +++ llvm/lib/Transforms/Scalar/TailDuplication.cpp Tue Mar 16 17:36:49 2004 @@ -157,8 +157,13 @@ } } else if (PHINode *PN = dyn_cast(cast(*UI))) { // If the user of this instruction is a PHI node in the current block, - // spill the value. - ShouldDemote = true; + // which has an entry from another block using the value, spill it. + for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) + if (PN->getIncomingValue(i) == I && + PN->getIncomingBlock(i) != DestBlock) { + ShouldDemote = true; + break; + } } if (ShouldDemote) { From lattner at cs.uiuc.edu Tue Mar 16 18:26:04 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 18:26:04 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/TailDuplication.cpp Message-ID: <200403162332.RAA24534@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: TailDuplication.cpp updated: 1.16 -> 1.17 --- Log message: Okay, so there is no reasonable way for tail duplication to update SSA form, as it is making effectively arbitrary modifications to the CFG and we don't have a domset/domfrontier implementations that can handle the dynamic updates. Instead of having a bunch of code that doesn't actually work in practice, just demote any potentially tricky values to the stack (causing the problem to go away entirely). Later invocations of mem2reg will rebuild SSA for us. This fixes all of the major performance regressions with tail duplication from LLVM 1.1. For example, this loop: --- int popcount(int x) { int result = 0; while (x != 0) { result = result + (x & 0x1); x = x >> 1; } return result; } --- Used to be compiled into: int %popcount(int %X) { entry: br label %loopentry loopentry: ; preds = %entry, %no_exit %x.0 = phi int [ %X, %entry ], [ %tmp.9, %no_exit ] ; [#uses=3] %result.1.0 = phi int [ 0, %entry ], [ %tmp.6, %no_exit ] ; [#uses=2] %tmp.1 = seteq int %x.0, 0 ; [#uses=1] br bool %tmp.1, label %loopexit, label %no_exit no_exit: ; preds = %loopentry %tmp.4 = and int %x.0, 1 ; [#uses=1] %tmp.6 = add int %tmp.4, %result.1.0 ; [#uses=1] %tmp.9 = shr int %x.0, ubyte 1 ; [#uses=1] br label %loopentry loopexit: ; preds = %loopentry ret int %result.1.0 } And is now compiled into: int %popcount(int %X) { entry: br label %no_exit no_exit: ; preds = %entry, %no_exit %x.0.0 = phi int [ %X, %entry ], [ %tmp.9, %no_exit ] ; [#uses=2] %result.1.0.0 = phi int [ 0, %entry ], [ %tmp.6, %no_exit ] ; [#uses=1] %tmp.4 = and int %x.0.0, 1 ; [#uses=1] %tmp.6 = add int %tmp.4, %result.1.0.0 ; [#uses=2] %tmp.9 = shr int %x.0.0, ubyte 1 ; [#uses=2] %tmp.1 = seteq int %tmp.9, 0 ; [#uses=1] br bool %tmp.1, label %loopexit, label %no_exit loopexit: ; preds = %no_exit ret int %tmp.6 } --- Diffs of the changes: (+49 -195) Index: llvm/lib/Transforms/Scalar/TailDuplication.cpp diff -u llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.16 llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.17 --- llvm/lib/Transforms/Scalar/TailDuplication.cpp:1.16 Tue Mar 16 13:45:22 2004 +++ llvm/lib/Transforms/Scalar/TailDuplication.cpp Tue Mar 16 17:29:09 2004 @@ -41,16 +41,7 @@ bool runOnFunction(Function &F); private: inline bool shouldEliminateUnconditionalBranch(TerminatorInst *TI); - inline bool canEliminateUnconditionalBranch(TerminatorInst *TI); inline void eliminateUnconditionalBranch(BranchInst *BI); - inline void InsertPHINodesIfNecessary(Instruction *OrigInst, Value *NewInst, - BasicBlock *NewBlock); - inline Value *GetValueInBlock(BasicBlock *BB, Value *OrigVal, - std::map &ValueMap, - std::map &OutValueMap); - inline Value *GetValueOutBlock(BasicBlock *BB, Value *OrigVal, - std::map &ValueMap, - std::map &OutValueMap); }; RegisterOpt X("tailduplicate", "Tail Duplication"); } @@ -64,8 +55,7 @@ bool TailDup::runOnFunction(Function &F) { bool Changed = false; for (Function::iterator I = F.begin(), E = F.end(); I != E; ) - if (shouldEliminateUnconditionalBranch(I->getTerminator()) && - canEliminateUnconditionalBranch(I->getTerminator())) { + if (shouldEliminateUnconditionalBranch(I->getTerminator())) { eliminateUnconditionalBranch(cast(I->getTerminator())); Changed = true; } else { @@ -96,6 +86,12 @@ if (DBI->isUnconditional() && DBI->getSuccessor(0) == Dest) return false; // Do not loop infinitely! + // FIXME: DemoteRegToStack cannot yet demote invoke instructions to the stack, + // because doing so would require breaking critical edges. This should be + // fixed eventually. + if (!DTI->use_empty()) + return false; + // Do not bother working on dead blocks... pred_iterator PI = pred_begin(Dest), PE = pred_end(Dest); if (PI == PE && Dest != Dest->getParent()->begin()) @@ -123,36 +119,6 @@ return true; } -/// canEliminateUnconditionalBranch - Unfortunately, the general form of tail -/// duplication can do very bad things to SSA form, by destroying arbitrary -/// relationships between dominators and dominator frontiers as it processes the -/// program. The right solution for this is to have an incrementally updating -/// dominator data structure, which can gracefully react to arbitrary -/// "addEdge/removeEdge" changes to the CFG. Implementing this is nontrivial, -/// however, so we just disable the transformation in cases where it is not -/// currently safe. -/// -bool TailDup::canEliminateUnconditionalBranch(TerminatorInst *TI) { - // Basically, we refuse to make the transformation if any of the values - // computed in the 'tail' are used in any other basic blocks. - BasicBlock *BB = TI->getParent(); - BasicBlock *Tail = TI->getSuccessor(0); - assert(isa(TI) && cast(TI)->isUnconditional()); - - for (BasicBlock::iterator I = Tail->begin(), E = Tail->end(); I != E; ++I) - for (Value::use_iterator UI = I->use_begin(), E = I->use_end(); UI != E; - ++UI) { - Instruction *User = cast(*UI); - if (User->getParent() != Tail && User->getParent() != BB) - return false; - - // The 'swap' problem foils the tail duplication rewriting code. - if (isa(User) && User->getParent() == Tail) - return false; - } - return true; -} - /// eliminateUnconditionalBranch - Clone the instructions from the destination /// block into the source block, eliminating the specified unconditional branch. @@ -167,6 +133,42 @@ DEBUG(std::cerr << "TailDuplication[" << SourceBlock->getParent()->getName() << "]: Eliminating branch: " << *Branch); + // Tail duplication can not update SSA properties correctly if the values + // defined in the duplicated tail are used outside of the tail itself. For + // this reason, we spill all values that are used outside of the tail to the + // stack. + for (BasicBlock::iterator I = DestBlock->begin(); I != DestBlock->end(); ++I) + for (Value::use_iterator UI = I->use_begin(), E = I->use_end(); UI != E; + ++UI) { + bool ShouldDemote = false; + if (cast(*UI)->getParent() != DestBlock) { + // We must allow our successors to use tail values in their PHI nodes + // (if the incoming value corresponds to the tail block). + if (PHINode *PN = dyn_cast(*UI)) { + for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) + if (PN->getIncomingValue(i) == I && + PN->getIncomingBlock(i) != DestBlock) { + ShouldDemote = true; + break; + } + + } else { + ShouldDemote = true; + } + } else if (PHINode *PN = dyn_cast(cast(*UI))) { + // If the user of this instruction is a PHI node in the current block, + // spill the value. + ShouldDemote = true; + } + + if (ShouldDemote) { + // We found a use outside of the tail. Create a new stack slot to + // break this inter-block usage pattern. + DemoteRegToStack(*I); + break; + } + } + // We are going to have to map operands from the original block B to the new // copy of the block B'. If there are PHI nodes in the DestBlock, these PHI // nodes also define part of this mapping. Loop over these PHI nodes, adding @@ -217,169 +219,21 @@ PN->addIncoming(IV, SourceBlock); } } - - // Now that all of the instructions are correctly copied into the SourceBlock, - // we have one more minor problem: the successors of the original DestBB may - // use the values computed in DestBB either directly (if DestBB dominated the - // block), or through a PHI node. In either case, we need to insert PHI nodes - // into any successors of DestBB (which are now our successors) for each value - // that is computed in DestBB, but is used outside of it. All of these uses - // we have to rewrite with the new PHI node. - // - if (succ_begin(SourceBlock) != succ_end(SourceBlock)) // Avoid wasting time... - for (BI = DestBlock->begin(); BI != DestBlock->end(); ++BI) - if (BI->getType() != Type::VoidTy) - InsertPHINodesIfNecessary(BI, ValueMapping[BI], SourceBlock); + + // Next, remove the old branch instruction, and any PHI node entries that we + // had. + BI = Branch; ++BI; // Get an iterator to the first new instruction + DestBlock->removePredecessor(SourceBlock); // Remove entries in PHI nodes... + SourceBlock->getInstList().erase(Branch); // Destroy the uncond branch... // Final step: now that we have finished everything up, walk the cloned // instructions one last time, constant propagating and DCE'ing them, because // they may not be needed anymore. // - BI = Branch; ++BI; // Get an iterator to the first new instruction if (HadPHINodes) while (BI != SourceBlock->end()) if (!dceInstruction(BI) && !doConstantPropagation(BI)) ++BI; - DestBlock->removePredecessor(SourceBlock); // Remove entries in PHI nodes... - SourceBlock->getInstList().erase(Branch); // Destroy the uncond branch... - ++NumEliminated; // We just killed a branch! -} - -/// InsertPHINodesIfNecessary - So at this point, we cloned the OrigInst -/// instruction into the NewBlock with the value of NewInst. If OrigInst was -/// used outside of its defining basic block, we need to insert a PHI nodes into -/// the successors. -/// -void TailDup::InsertPHINodesIfNecessary(Instruction *OrigInst, Value *NewInst, - BasicBlock *NewBlock) { - // Loop over all of the uses of OrigInst, rewriting them to be newly inserted - // PHI nodes, unless they are in the same basic block as OrigInst. - BasicBlock *OrigBlock = OrigInst->getParent(); - std::vector Users; - Users.reserve(OrigInst->use_size()); - for (Value::use_iterator I = OrigInst->use_begin(), E = OrigInst->use_end(); - I != E; ++I) { - Instruction *In = cast(*I); - if (In->getParent() != OrigBlock || // Don't modify uses in the orig block! - isa(In)) - Users.push_back(In); - } - - // The common case is that the instruction is only used within the block that - // defines it. If we have this case, quick exit. - // - if (Users.empty()) return; - - // Otherwise, we have a more complex case, handle it now. This requires the - // construction of a mapping between a basic block and the value to use when - // in the scope of that basic block. This map will map to the original and - // new values when in the original or new block, but will map to inserted PHI - // nodes when in other blocks. - // - std::map ValueMap; - std::map OutValueMap; // The outgoing value map - OutValueMap[OrigBlock] = OrigInst; - OutValueMap[NewBlock ] = NewInst; // Seed the initial values... - - DEBUG(std::cerr << " ** Inserting PHI nodes for " << OrigInst); - while (!Users.empty()) { - Instruction *User = Users.back(); Users.pop_back(); - - if (PHINode *PN = dyn_cast(User)) { - // PHI nodes must be handled specially here, because their operands are - // actually defined in predecessor basic blocks, NOT in the block that the - // PHI node lives in. Note that we have already added entries to PHI nods - // which are in blocks that are immediate successors of OrigBlock, so - // don't modify them again. - for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) - if (PN->getIncomingValue(i) == OrigInst && - PN->getIncomingBlock(i) != OrigBlock) { - Value *V = GetValueOutBlock(PN->getIncomingBlock(i), OrigInst, - ValueMap, OutValueMap); - PN->setIncomingValue(i, V); - } - - } else { - // Any other user of the instruction can just replace any uses with the - // new value defined in the block it resides in. - Value *V = GetValueInBlock(User->getParent(), OrigInst, ValueMap, - OutValueMap); - User->replaceUsesOfWith(OrigInst, V); - } - } -} - -/// GetValueInBlock - This is a recursive method which inserts PHI nodes into -/// the function until there is a value available in basic block BB. -/// -Value *TailDup::GetValueInBlock(BasicBlock *BB, Value *OrigVal, - std::map &ValueMap, - std::map &OutValueMap){ - ValueHolder &BBVal = ValueMap[BB]; - if (BBVal) return BBVal; // Value already computed for this block? - - // If this block has no predecessors, then it must be unreachable, thus, it - // doesn't matter which value we use. - if (pred_begin(BB) == pred_end(BB)) - return BBVal = Constant::getNullValue(OrigVal->getType()); - - // If there is no value already available in this basic block, we need to - // either reuse a value from an incoming, dominating, basic block, or we need - // to create a new PHI node to merge in different incoming values. Because we - // don't know if we're part of a loop at this point or not, we create a PHI - // node, even if we will ultimately eliminate it. - PHINode *PN = new PHINode(OrigVal->getType(), OrigVal->getName()+".pn", - BB->begin()); - BBVal = PN; // Insert this into the BBVal slot in case of cycles... - - ValueHolder &BBOutVal = OutValueMap[BB]; - if (BBOutVal == 0) BBOutVal = PN; - - // Now that we have created the PHI node, loop over all of the predecessors of - // this block, computing an incoming value for the predecessor. - std::vector Preds(pred_begin(BB), pred_end(BB)); - for (unsigned i = 0, e = Preds.size(); i != e; ++i) - PN->addIncoming(GetValueOutBlock(Preds[i], OrigVal, ValueMap, OutValueMap), - Preds[i]); - - // The PHI node is complete. In many cases, however the PHI node was - // ultimately unnecessary: we could have just reused a dominating incoming - // value. If this is the case, nuke the PHI node and replace the map entry - // with the dominating value. - // - assert(PN->getNumIncomingValues() > 0 && "No predecessors?"); - - // Check to see if all of the elements in the PHI node are either the PHI node - // itself or ONE particular value. - unsigned i = 0; - Value *ReplVal = PN->getIncomingValue(i); - for (; ReplVal == PN && i != PN->getNumIncomingValues(); ++i) - ReplVal = PN->getIncomingValue(i); // Skip values equal to the PN - - for (; i != PN->getNumIncomingValues(); ++i) - if (PN->getIncomingValue(i) != PN && PN->getIncomingValue(i) != ReplVal) { - ReplVal = 0; - break; - } - - // Found a value to replace the PHI node with? - if (ReplVal && ReplVal != PN) { - PN->replaceAllUsesWith(ReplVal); - BB->getInstList().erase(PN); // Erase the PHI node... - } else { - ++NumPHINodes; - } - - return BBVal; -} - -Value *TailDup::GetValueOutBlock(BasicBlock *BB, Value *OrigVal, - std::map &ValueMap, - std::map &OutValueMap) { - ValueHolder &BBVal = OutValueMap[BB]; - if (BBVal) return BBVal; // Value already computed for this block? - - return GetValueInBlock(BB, OrigVal, ValueMap, OutValueMap); } From lattner at cs.uiuc.edu Tue Mar 16 18:47:00 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 18:47:00 2004 Subject: [llvm-commits] CVS: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso/part.c Message-ID: <200403170046.SAA31624@zion.cs.uiuc.edu> Changes in directory llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso: part.c updated: 1.1 -> 1.2 --- Log message: Fix compilation of benchmark --- Diffs of the changes: (+1 -1) Index: llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso/part.c diff -u llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso/part.c:1.1 llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso/part.c:1.2 --- llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso/part.c:1.1 Tue Feb 17 12:13:40 2004 +++ llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso/part.c Tue Mar 16 18:46:25 2004 @@ -43,7 +43,7 @@ } -static int +int visit_col(A, pcol, rows_visited, cols_visited) sm_matrix *A; sm_col *pcol; From alkis at niobe.cs.uiuc.edu Tue Mar 16 18:50:01 2004 From: alkis at niobe.cs.uiuc.edu (Alkis Evlogimenos) Date: Tue Mar 16 18:50:01 2004 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/RegAllocLinearScan.cpp Message-ID: <200403170049.i2H0nAp18852@niobe.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen: RegAllocLinearScan.cpp updated: 1.69 -> 1.70 --- Log message: Make the set of fixed (preallocated) intervals be a fixed superset of unhandled + handled. So unhandled is now including all fixed intervals and fixed intervals never changes when processing a function. --- Diffs of the changes: (+10 -29) Index: llvm/lib/CodeGen/RegAllocLinearScan.cpp diff -u llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.69 llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.70 --- llvm/lib/CodeGen/RegAllocLinearScan.cpp:1.69 Mon Mar 1 17:18:15 2004 +++ llvm/lib/CodeGen/RegAllocLinearScan.cpp Tue Mar 16 18:48:59 2004 @@ -135,9 +135,9 @@ void RA::releaseMemory() { unhandled_.clear(); + fixed_.clear(); active_.clear(); inactive_.clear(); - fixed_.clear(); handled_.clear(); } @@ -171,25 +171,10 @@ DEBUG(printIntervals("active", active_.begin(), active_.end())); DEBUG(printIntervals("inactive", inactive_.begin(), inactive_.end())); - while (!unhandled_.empty() || !fixed_.empty()) { + while (!unhandled_.empty()) { // pick the interval with the earliest start point - IntervalPtrs::value_type cur; - if (fixed_.empty()) { - cur = unhandled_.front(); - unhandled_.pop_front(); - } - else if (unhandled_.empty()) { - cur = fixed_.front(); - fixed_.pop_front(); - } - else if (unhandled_.front()->start() < fixed_.front()->start()) { - cur = unhandled_.front(); - unhandled_.pop_front(); - } - else { - cur = fixed_.front(); - fixed_.pop_front(); - } + IntervalPtrs::value_type cur = unhandled_.front(); + unhandled_.pop_front(); DEBUG(std::cerr << "\n*** CURRENT ***: " << *cur << '\n'); @@ -234,10 +219,9 @@ for (LiveIntervals::Intervals::iterator i = li.begin(), e = li.end(); i != e; ++i) { + unhandled_.push_back(&*i); if (MRegisterInfo::isPhysicalRegister(i->reg)) fixed_.push_back(&*i); - else - unhandled_.push_back(&*i); } } @@ -444,7 +428,7 @@ DEBUG(std::cerr << "\t\trolling back to: " << earliestStart << '\n'); // scan handled in reverse order and undo each one, restoring the - // state of unhandled and fixed + // state of unhandled while (!handled_.empty()) { IntervalPtrs::value_type i = handled_.back(); // if this interval starts before t we are done @@ -456,8 +440,8 @@ if ((it = find(active_.begin(), active_.end(), i)) != active_.end()) { active_.erase(it); if (MRegisterInfo::isPhysicalRegister(i->reg)) { - fixed_.push_front(i); prt_->delRegUse(i->reg); + unhandled_.push_front(i); } else { prt_->delRegUse(vrm_->getPhys(i->reg)); @@ -479,7 +463,7 @@ else if ((it = find(inactive_.begin(), inactive_.end(), i)) != inactive_.end()) { inactive_.erase(it); if (MRegisterInfo::isPhysicalRegister(i->reg)) - fixed_.push_front(i); + unhandled_.push_front(i); else { vrm_->clearVirt(i->reg); if (i->spilled()) { @@ -496,12 +480,9 @@ } } else { - if (MRegisterInfo::isPhysicalRegister(i->reg)) - fixed_.push_front(i); - else { + if (MRegisterInfo::isVirtualRegister(i->reg)) vrm_->clearVirt(i->reg); - unhandled_.push_front(i); - } + unhandled_.push_front(i); } } From criswell at cs.uiuc.edu Tue Mar 16 19:07:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue Mar 16 19:07:01 2004 Subject: [llvm-commits] CVS: llvm/test/QMTest/expectations.unknown.qmr Message-ID: <200403170106.TAA30483@choi.cs.uiuc.edu> Changes in directory llvm/test/QMTest: expectations.unknown.qmr updated: 1.1 -> 1.2 --- Log message: Marked all of the Machine Code tests (Feature.mc.*) as expected failures. If a platform is unrecognized, chances are we don't have a code generator for it. :) --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/expectations.unknown.qmr diff -u llvm/test/QMTest/expectations.unknown.qmr:1.1 llvm/test/QMTest/expectations.unknown.qmr:1.2 --- llvm/test/QMTest/expectations.unknown.qmr:1.1 Wed Nov 19 15:13:53 2003 +++ llvm/test/QMTest/expectations.unknown.qmr Tue Mar 16 19:05:55 2004 @@ -3,13 +3,13 @@ qoq}q(U _Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U _Result__idq U0Regression.Assembler.2002-08-16-ConstExprInlinedq U_Result__contextq (cqm.test.context Context -q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhUFAILqh}h U.Regression.Transforms.CorrelatedExprs.looptestqh (h o}q (h}h}ubub.(hoq!}q"(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U2Regression.Assembler.2002-01-24-ValueRefineAbsTypeq3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-PredecessorP! roblemq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U-Regression.C++Frontend.2003-08-28-SaveExprBugqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U"Regression.Jello.2003-06-05-PHIBugqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U)Regression.Transforms.Reassociate.subtestq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprq_h (h o}q`(h}h}ubub.(hoqa}qb(h! hhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSub Moveqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U>Regression.Transforms.InstCombine.2003-06-22-ConstantExprCrashqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U$Regression.Jello.2003-01-04-LoopTestqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2q{h (h o}q|(h}h}ubub.(hoq}}q~(hhhhh}h U)Regression.CFrontend.2002-07-14-MiscTestsqh (h o}q?(h}h}ubub.(hoq?}q?(hhhhh}h U(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U Regression.Reoptimizer.ticm.ticmqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Transforms.Reassociate.subtestqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq_h (h o}q`(h}h}ubub.! (hoqa}qb(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10 -07-DominatorProblemqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h U Changes in directory llvm/test/QMTest: expectations.linux.qmr updated: 1.6 -> 1.7 --- Log message: Marked all XPASS tests as expecting to pass now. Began marking tests which fail as XFAIL's. --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/expectations.linux.qmr diff -u llvm/test/QMTest/expectations.linux.qmr:1.6 llvm/test/QMTest/expectations.linux.qmr:1.7 --- llvm/test/QMTest/expectations.linux.qmr:1.6 Thu Dec 18 10:42:06 2003 +++ llvm/test/QMTest/expectations.linux.qmr Tue Mar 16 19:27:38 2004 @@ -3,13 +3,13 @@ qoq}q(U _Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U _Result__idq U0Regression.Assembler.2002-08-16-ConstExprInlinedq U_Result__contextq (cqm.test.context Context -q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhUFAILqh}h U.Regression.Transforms.CorrelatedExprs.looptestqh (h o}q (h}h}ubub.(hoq!}q"(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-PredecessorProblemq3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-! VarArgCallInfLoopq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U Regression.Reoptimizer.ticm.ticmq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U-Regression.C++Frontend.2003-08-28-SaveExprBugqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U"Regression.Jello.2003-06-05-PHIBugqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Transforms.Reassociate.subtestqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h! UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqc h (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U$Regression.Jello.2003-01-04-LoopTestqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U)Regression.CFrontend.2002-07-14-MiscTestsqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h U(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U)Regression.Transforms.Reassociate.subtestqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-! 07-DominatorProblemq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h U3Reg ression.Transforms.PiNodeInserter.substitutetestqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U Changes in directory llvm/include/llvm/Transforms/Utils: Local.h updated: 1.15 -> 1.16 --- Log message: cleanup comment --- Diffs of the changes: (+1 -1) Index: llvm/include/llvm/Transforms/Utils/Local.h diff -u llvm/include/llvm/Transforms/Utils/Local.h:1.15 llvm/include/llvm/Transforms/Utils/Local.h:1.16 --- llvm/include/llvm/Transforms/Utils/Local.h:1.15 Sat Mar 13 20:13:07 2004 +++ llvm/include/llvm/Transforms/Utils/Local.h Tue Mar 16 19:29:36 2004 @@ -89,7 +89,7 @@ bool SimplifyCFG(BasicBlock *BB); /// DemoteRegToStack - This function takes a virtual register computed by an -/// Instruction& X and replaces it with a slot in the stack frame, allocated via +/// Instruction and replaces it with a slot in the stack frame, allocated via /// alloca. This allows the CFG to be changed around without fear of /// invalidating the SSA information for the value. It returns the pointer to /// the alloca inserted to create a stack slot for X. From criswell at cs.uiuc.edu Tue Mar 16 19:32:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue Mar 16 19:32:01 2004 Subject: [llvm-commits] CVS: llvm/test/QMTest/expectations.linux.qmr Message-ID: <200403170131.TAA10479@choi.cs.uiuc.edu> Changes in directory llvm/test/QMTest: expectations.linux.qmr updated: 1.7 -> 1.8 --- Log message: Finished adding the XFAIL's. --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/expectations.linux.qmr diff -u llvm/test/QMTest/expectations.linux.qmr:1.7 llvm/test/QMTest/expectations.linux.qmr:1.8 --- llvm/test/QMTest/expectations.linux.qmr:1.7 Tue Mar 16 19:27:38 2004 +++ llvm/test/QMTest/expectations.linux.qmr Tue Mar 16 19:30:55 2004 @@ -3,13 +3,13 @@ qoq}q(U _Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U _Result__idq U0Regression.Assembler.2002-08-16-ConstExprInlinedq U_Result__contextq (cqm.test.context Context -q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U9Regression.Transforms.Mem2Reg.2003-10-05-DeadPHIInsertionqh (h o}q(h}h}ubub.(hoq }q!(hhhUFAILq"h}h U.Regression.Transforms.CorrelatedExprs.looptestq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhh"h}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-Prede! cessorProblemq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U)Regression.Transforms.Reassociate.subtestqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-! 07-DominatorProblemq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h U3Reg ression.Transforms.PiNodeInserter.substitutetestqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U)Regression.Transforms.Reassociate.subtestqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-! 07-DominatorProblemq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h U3Reg ression.Transforms.PiNodeInserter.substitutetestqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U Changes in directory llvm/test/QMTest: expectations.sunos.qmr updated: 1.6 -> 1.7 --- Log message: Made all Passing tests expected to Pass. --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/expectations.sunos.qmr diff -u llvm/test/QMTest/expectations.sunos.qmr:1.6 llvm/test/QMTest/expectations.sunos.qmr:1.7 --- llvm/test/QMTest/expectations.sunos.qmr:1.6 Thu Dec 18 10:42:06 2003 +++ llvm/test/QMTest/expectations.sunos.qmr Tue Mar 16 19:43:27 2004 @@ -3,13 +3,13 @@ qoq}q(U _Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U _Result__idq U0Regression.Assembler.2002-08-16-ConstExprInlinedq U_Result__contextq (cqm.test.context Context -q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhUFAILqh}h U.Regression.Transforms.CorrelatedExprs.looptestqh (h o}q (h}h}ubub.(hoq!}q"(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-PredecessorProblemq3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-! VarArgCallInfLoopq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U Regression.Reoptimizer.ticm.ticmq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U-Regression.C++Frontend.2003-08-28-SaveExprBugqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U"Regression.Jello.2003-06-05-PHIBugqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Transforms.Reassociate.subtestqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h! UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqc h (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U$Regression.Jello.2003-01-04-LoopTestqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U)Regression.CFrontend.2002-07-14-MiscTestsqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h U(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U)Regression.Transforms.Reassociate.subtestqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-! 07-DominatorProblemq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h U3Reg ression.Transforms.PiNodeInserter.substitutetestqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U Changes in directory llvm/test/QMTest: expectations.sunos.qmr updated: 1.7 -> 1.8 --- Log message: Marked the following tests as XFAIL: Regression.Assembler.2004-03-07-FunctionAddressAlignment Regression.CFrontend.2004-01-01-UnknownInitSize Regression.CFrontend.2004-02-13-StringInit Regression.CFrontend.2004-02-20-StaticRedeclare Regression.CFrontend.2004-03-07-BitfieldCrash Regression.CodeGen.X86.2003-08-03-ReservedWordFunction Regression.Transforms.CodeExtractor.2004-03-14-DominanceProblem Regression.Transforms.LevelRaise.2002-03-21-MissedRaise Regression.Transforms.LevelRaise.2002-03-21-MissedRaise2 Regression.Transforms.LevelRaise.2002-03-21-MissedRaise3 --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/expectations.sunos.qmr diff -u llvm/test/QMTest/expectations.sunos.qmr:1.7 llvm/test/QMTest/expectations.sunos.qmr:1.8 --- llvm/test/QMTest/expectations.sunos.qmr:1.7 Tue Mar 16 19:43:27 2004 +++ llvm/test/QMTest/expectations.sunos.qmr Tue Mar 16 19:48:51 2004 @@ -3,13 +3,13 @@ qoq}q(U _Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U _Result__idq U0Regression.Assembler.2002-08-16-ConstExprInlinedq U_Result__contextq (cqm.test.context Context -q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U9Regression.Transforms.Mem2Reg.2003-10-05-DeadPHIInsertionqh (h o}q(h}h}ubub.(hoq }q!(hhhUFAILq"h}h U.Regression.Transforms.CorrelatedExprs.looptestq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhh"h}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-Prede! cessorProblemq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U)Regression.Transforms.Reassociate.subtestqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-! 07-DominatorProblemq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h U3Reg ression.Transforms.PiNodeInserter.substitutetestqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U(hhhhh}h U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U)Regression.Transforms.Reassociate.subtestqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-! 07-DominatorProblemq_h (h o}q`(h}h}ubub.(hoqa}qb(hhhhh}h U3Reg ression.Transforms.PiNodeInserter.substitutetestqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U Changes in directory llvm/lib/Transforms/Scalar: GCSE.cpp updated: 1.35 -> 1.36 --- Log message: Be more accurate --- Diffs of the changes: (+15 -4) Index: llvm/lib/Transforms/Scalar/GCSE.cpp diff -u llvm/lib/Transforms/Scalar/GCSE.cpp:1.35 llvm/lib/Transforms/Scalar/GCSE.cpp:1.36 --- llvm/lib/Transforms/Scalar/GCSE.cpp:1.35 Sun Mar 14 23:46:59 2004 +++ llvm/lib/Transforms/Scalar/GCSE.cpp Tue Mar 16 19:59:27 2004 @@ -223,6 +223,11 @@ Instruction *Second = I != First ? I : Other; // Get iterator to second inst BI = Second; + if (isa(Second)) + ++NumLoadRemoved; // Keep track of loads eliminated + if (isa(Second)) + ++NumCallRemoved; // Keep track of calls eliminated + // Destroy Second, using First instead. ReplaceInstWithInst(First, BI); Ret = First; @@ -231,9 +236,19 @@ // dominates the other instruction, we can simply use it // } else if (DomSetInfo->dominates(BB1, BB2)) { // I dom Other? + if (isa(Other)) + ++NumLoadRemoved; // Keep track of loads eliminated + if (isa(Other)) + ++NumCallRemoved; // Keep track of calls eliminated + ReplaceInstWithInst(I, Other); Ret = I; } else if (DomSetInfo->dominates(BB2, BB1)) { // Other dom I? + if (isa(I)) + ++NumLoadRemoved; // Keep track of loads eliminated + if (isa(I)) + ++NumCallRemoved; // Keep track of calls eliminated + ReplaceInstWithInst(Other, I); Ret = Other; } else { @@ -266,10 +281,6 @@ return 0; } - if (isa(Ret)) - ++NumLoadRemoved; // Keep track of loads eliminated - if (isa(Ret)) - ++NumCallRemoved; // Keep track of calls eliminated ++NumInstRemoved; // Keep track of number of instructions eliminated // Add all users of Ret to the worklist... From lattner at cs.uiuc.edu Tue Mar 16 20:03:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 20:03:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/SimplifyCFG.cpp Message-ID: <200403170202.UAA03445@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Utils: SimplifyCFG.cpp updated: 1.30 -> 1.31 --- Log message: Fix compilation of mesa, which I broke earlier today --- Diffs of the changes: (+3 -2) Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp diff -u llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1.30 llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1.31 --- llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1.30 Tue Mar 16 13:45:07 2004 +++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp Tue Mar 16 20:02:47 2004 @@ -691,8 +691,9 @@ } } else if (SwitchInst *SI = dyn_cast(BB->begin())) { - if (FoldValueComparisonIntoPredecessors(SI)) - return SimplifyCFG(BB) || 1; + if (isValueEqualityComparison(SI)) + if (FoldValueComparisonIntoPredecessors(SI)) + return SimplifyCFG(BB) || 1; } else if (BranchInst *BI = dyn_cast(BB->getTerminator())) { if (Value *CompVal = isValueEqualityComparison(BB->getTerminator())) { // This block must be empty, except for the setcond inst, if it exists. From lattner at cs.uiuc.edu Tue Mar 16 20:30:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 20:30:01 2004 Subject: [llvm-commits] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403170229.UAA08491@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.30 -> 1.31 --- Log message: Make compiler generated globals internal! This unbreaks crafty --- Diffs of the changes: (+1 -0) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.30 llvm-gcc/gcc/llvm-expand.c:1.31 --- llvm-gcc/gcc/llvm-expand.c:1.30 Tue Mar 16 15:51:49 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 20:29:37 2004 @@ -4034,6 +4034,7 @@ sprintf(Name, ".ctor_%d", ++CtorCounter); G = llvm_global_new(D2V(C)->Ty, Name); G->Init = C; + G->Linkage = L_Internal; llvm_ilist_push_back(llvm_global, TheProgram.Globals, G); EmitMemCpyMove(Fn, target, G2V(G), llvm_constant_new_integral(LongTy, NumBytes), From criswell at cs.uiuc.edu Tue Mar 16 20:32:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue Mar 16 20:32:01 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/SimplifyCFG/PhiEliminate.ll Message-ID: <200403170231.UAA20526@choi.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/SimplifyCFG: PhiEliminate.ll updated: 1.1 -> 1.2 --- Log message: Modify test to use the %t substition (temporary name). This is available in the QMTest Testrunner tests. Please note that putting output files in the Output directory no longer works, as QMTest does not build Output directories anymore (nor does the test run in a separate subdirectory, anyway). --- Diffs of the changes: (+2 -2) Index: llvm/test/Regression/Transforms/SimplifyCFG/PhiEliminate.ll diff -u llvm/test/Regression/Transforms/SimplifyCFG/PhiEliminate.ll:1.1 llvm/test/Regression/Transforms/SimplifyCFG/PhiEliminate.ll:1.2 --- llvm/test/Regression/Transforms/SimplifyCFG/PhiEliminate.ll:1.1 Tue Feb 10 21:35:04 2004 +++ llvm/test/Regression/Transforms/SimplifyCFG/PhiEliminate.ll Tue Mar 16 20:31:29 2004 @@ -3,8 +3,8 @@ ; nodes away allows the branches to be eliminated, performing a simple form of ; 'if conversion'. -; RUN: llvm-as < %s | opt -simplifycfg | llvm-dis > Output/%s.xform -; RUN: not grep phi Output/%s.xform && grep ret Output/%s.xform +; RUN: llvm-as < %s | opt -simplifycfg | llvm-dis > %t.xform +; RUN: not grep phi %t.xform && grep ret %t.xform declare void %use(bool) declare void %use(int) From criswell at cs.uiuc.edu Tue Mar 16 20:43:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue Mar 16 20:43:01 2004 Subject: [llvm-commits] [release_12] CVS: llvm-gcc/gcc/llvm-expand.c Message-ID: <200403170242.UAA09352@zion.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: llvm-expand.c updated: 1.30 -> 1.30.2.1 --- Log message: Merge in revision 1.31 from mainline. This makes the compiler generate globals internal and unbreaks crafty. Hence, it is a very crafty change. :) --- Diffs of the changes: (+1 -0) Index: llvm-gcc/gcc/llvm-expand.c diff -u llvm-gcc/gcc/llvm-expand.c:1.30 llvm-gcc/gcc/llvm-expand.c:1.30.2.1 --- llvm-gcc/gcc/llvm-expand.c:1.30 Tue Mar 16 15:51:49 2004 +++ llvm-gcc/gcc/llvm-expand.c Tue Mar 16 20:42:22 2004 @@ -4034,6 +4034,7 @@ sprintf(Name, ".ctor_%d", ++CtorCounter); G = llvm_global_new(D2V(C)->Ty, Name); G->Init = C; + G->Linkage = L_Internal; llvm_ilist_push_back(llvm_global, TheProgram.Globals, G); EmitMemCpyMove(Fn, target, G2V(G), llvm_constant_new_integral(LongTy, NumBytes), From lattner at cs.uiuc.edu Tue Mar 16 21:55:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue Mar 16 21:55:01 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403170354.VAA15313@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.152 -> 1.153 --- Log message: update release notes for 1.2 --- Diffs of the changes: (+17 -10) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.152 llvm/docs/ReleaseNotes.html:1.153 --- llvm/docs/ReleaseNotes.html:1.152 Tue Mar 16 15:55:23 2004 +++ llvm/docs/ReleaseNotes.html Tue Mar 16 21:54:41 2004 @@ -81,12 +81,12 @@ date, and we encourage you to upgrade if you are using LLVM 1.0 or 1.1.

    -

    FIXME: UPDATE: -At this time, LLVM is known to correctly compile and run all C -& C++ SPEC CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist -benchmarks. It has also been used to compile many other programs. LLVM -now also works with a broad variety of C++ programs, though it has still -received less testing than the C front-end. +

    +At this time, LLVM is known to correctly compile and run all C & C++ SPEC +CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist benchmarks. It has +also been used to compile many other programs. LLVM now also works with +a broad variety of C++ programs, though it has still received less testing than +the C front-end.

    @@ -127,6 +127,13 @@
  • LLVM includes a new interprocedural optimization that marks global variables "constant" when they are provably never written to.
  • LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which is often improve the performance of C++ programs substantially.
    • +
  • Bugpoint can now do a better job reducing miscompilation problems by +reducing programs down to a particular loop nest, instead of just the function +being miscompiled.
    • +
  • The GCSE and LICM passes can now operate on side-effect-free function calls, for example hoisting calls to "strlen" and folding "cos" common subexpressions.
    • +
  • LLVM has early support for a new select instruction, though it is +currently only supported by the C backend.
    • @@ -136,9 +143,9 @@
      -
    1. Exception handling support in the X86 -& Sparc native code generators
      2. -
    2. The C/C++ front-end now support the GCC __builtin_return_address and __builtin_frame_address extensions.
      3. +
    3. Exception handling in the X86 +& Sparc native code generators is now supported
      4. +
    4. The C/C++ front-end now support the GCC __builtin_return_address and __builtin_frame_address extensions. These are also supported by the X86 backend and by the C backend.
    5. [X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808
    6. The C/C++ front-end now supports the "labels as values" GCC extension, often used to build "threaded interpreters".
      7. @@ -657,7 +664,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/16 21:55:23 $ + Last modified: $Date: 2004/03/17 03:54:41 $ From criswell at cs.uiuc.edu Wed Mar 17 09:16:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed Mar 17 09:16:02 2004 Subject: [llvm-commits] CVS: llvm/test/QMTest/expectations.unknown.qmr Message-ID: <200403171515.JAA28941@choi.cs.uiuc.edu> Changes in directory llvm/test/QMTest: expectations.unknown.qmr updated: 1.2 -> 1.3 --- Log message: Marked all LLC tests as expected failures on unknown platforms. --- Diffs of the changes: (+1 -1) Index: llvm/test/QMTest/expectations.unknown.qmr diff -u llvm/test/QMTest/expectations.unknown.qmr:1.2 llvm/test/QMTest/expectations.unknown.qmr:1.3 --- llvm/test/QMTest/expectations.unknown.qmr:1.2 Tue Mar 16 19:05:55 2004 +++ llvm/test/QMTest/expectations.unknown.qmr Wed Mar 17 09:15:36 2004 @@ -3,13 +3,13 @@ qoq}q(U _Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U _Result__idq U0Regression.Assembler.2002-08-16-ConstExprInlinedq U_Result__contextq (cqm.test.context Context -q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U9Regression.Transforms.Mem2Reg.2003-10-05-DeadPHIInsertionqh (h o}q(h}h}ubub.(hoq }q!(hhhUFAILq"h}h U.Regression.Transforms.CorrelatedExprs.looptestq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhh"h}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U,Regression.Transforms.DSAnalysis.indcalltes! tq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-PredecessorProblemq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U Regression.Reoptimizer.ticm.ticmqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U)Regression.Transforms.Reassociate.subtestqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U)Regression.Linker.2002-08-20-ConstantExprq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq_h (h o}q`(h}h}ubub.! (hoqa}qb(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10 -07-DominatorProblemqch (h o}qd(h}h}ubub.(hoqe}qf(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U-Regression.CFrontend.2002-02-18-64bitConstantqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2qsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U(Regression.Reoptimizer.BinInterface.testqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h URegression.Transforms.LevelRaise.2002-05-02-BadCastEliminationq3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-! PredecessorProblemq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U Regression.Reoptimizer.ticm.ticmq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U1Regression.CFrontend.2002-03-12-StructInitializerqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U-Regression.C++Frontend.2003-08-28-SaveExprBugqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U"Regression.Jello.2003-06-05-PHIBugqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U)Regression.Transforms.Reassociate.subtestq_h (h o}q`(h}h}ubub.(hoqa}qb(hh! hhh}h U)Regression.Linker.2002-08-20-ConstantExprqch (h o}qd(h}h }ubub.(hoqe}qf(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U$Regression.Jello.2003-01-04-LoopTestqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2q{h (h o}q|(h}h}ubub.(hoq}}q~(hhhhh}h U)Regression.CFrontend.2002-07-14-MiscTestsqh (h o}q?(h}h}ubub.(hoq?}q?(hhhhh}h U Changes in directory llvm/test/QMTest: expectations.unknown.qmr updated: 1.3 -> 1.4 --- Log message: The following tests are now expected to fail: Regression.Assembler.2004-03-07-FunctionAddressAlignment Regression.CFrontend.2004-01-01-UnknownInitSize Regression.CFrontend.2004-02-13-StringInit Regression.CFrontend.2004-02-20-StaticRedeclare Regression.CFrontend.2004-03-07-BitfieldCrash Regression.CodeGen.X86.2003-08-03-ReservedWordFunction Regression.Transforms.CodeExtractor.2004-03-14-DominanceProblem Regression.Transforms.LevelRaise.2002-03-21-MissedRaise Regression.Transforms.LevelRaise.2002-03-21-MissedRaise2 Regression.Transforms.LevelRaise.2002-03-21-MissedRaise3 --- Diffs of the changes: (+1 -0) Index: llvm/test/QMTest/expectations.unknown.qmr diff -u llvm/test/QMTest/expectations.unknown.qmr:1.3 llvm/test/QMTest/expectations.unknown.qmr:1.4 --- llvm/test/QMTest/expectations.unknown.qmr:1.3 Wed Mar 17 09:15:36 2004 +++ llvm/test/QMTest/expectations.unknown.qmr Wed Mar 17 09:19:33 2004 @@ -4,12 +4,12 @@ U_Result__contextq (cqm.test.context Context q o}q (U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h U(Regression.Transforms.PruneEH.simpletestqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h U/Regression.CBackend.2002-08-19-HardConstantExprqh (h o}q(h}h}ubub.(hoq}q(hhhhh}h URegression.Jello.test-shiftqh (h o}q(h}h}ubub.(hoq}q(hhhUFAILqh}h U.Regression.Transforms.CorrelatedExprs.looptestqh (h o}q (h}h}ubub.(hoq!}q"(hhhhh}h U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h (h o}q$(h}h}ubub.(hoq%}q&(hhhhh}h U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h (h o}q((h}h}ubub.(hoq)}q*(hhhhh}h U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h (h o}q,(h}h}ubub.(hoq-}q.(hhhhh}h U2Regression.Transforms.FunctionResolve.retmismatch1q/h (h o}q0(h}h}ubub.(hoq1}q2(hhhhh}h U>Regression.Transforms.LevelRaise.2002-05-02-BadCastEliminationq3h (h o}q4(h}h}ubub.(hoq5}q6(hhhhh}h U8Regression.Transforms.ADCE.2003-01-22-! PredecessorProblemq7h (h o}q8(h}h}ubub.(hoq9}q:(hhhhh}h U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h (h o}q<(h}h}ubub.(hoq=}q>(hhhhh}h U Regression.Reoptimizer.ticm.ticmq?h (h o}q@(h}h}ubub.(hoqA}qB(hhhhh}h U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh (h o}qD(h}h}ubub.(hoqE}qF(hhhhh}h U1Regression.CFrontend.2002-03-12-StructInitializerqGh (h o}qH(h}h}ubub.(hoqI}qJ(hhhhh}h U+Regression.CFrontend.2002-09-19-StarInLabelqKh (h o}qL(h}h}ubub.(hoqM}qN(hhhhh}h U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh (h o}qP(h}h}ubub.(hoqQ}qR(hhhhh}h U-Regression.C++Frontend.2003-08-28-SaveExprBugqSh (h o}qT(h}h}ubub.(hoqU}qV(hhhhh}h U"Regression.Jello.2003-06-05-PHIBugqWh (h o}qX(h}h}ubub.(hoqY}qZ(hhhhh}h U/Regression.Linker.2003-04-26-NullPtrLinkProblemq[h (h o}q\(h}h}ubub.(hoq]}q^(hhhhh}h U)Regression.Transforms.Reassociate.subtestq_h (h o}q`(h}h}ubub.(hoqa}qb(hh! hhh}h U)Regression.Linker.2002-08-20-ConstantExprqch (h o}qd(h}h }ubub.(hoqe}qf(hhhhh}h U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqgh (h o}qh(h}h}ubub.(hoqi}qj(hhhhh}h UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqkh (h o}ql(h}h}ubub.(hoqm}qn(hhhhh}h U3Regression.Transforms.PiNodeInserter.substitutetestqoh (h o}qp(h}h}ubub.(hoqq}qr(hhhhh}h U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqsh (h o}qt(h}h}ubub.(hoqu}qv(hhhhh}h U$Regression.Jello.2003-01-04-LoopTestqwh (h o}qx(h}h}ubub.(hoqy}qz(hhhhh}h U1Regression.Assembler.2002-04-04-PureVirtMethCall2q{h (h o}q|(h}h}ubub.(hoq}}q~(hhhhh}h U)Regression.CFrontend.2002-07-14-MiscTestsqh (h o}q?(h}h}ubub.(hoq?}q?(hhhhh}h U Changes in directory llvm/tools/bugpoint: TestPasses.cpp updated: 1.6 -> 1.7 --- Log message: Fix an iterator invalidation problem in a "buggy" pass --- Diffs of the changes: (+2 -1) Index: llvm/tools/bugpoint/TestPasses.cpp diff -u llvm/tools/bugpoint/TestPasses.cpp:1.6 llvm/tools/bugpoint/TestPasses.cpp:1.7 --- llvm/tools/bugpoint/TestPasses.cpp:1.6 Tue Nov 11 16:41:34 2003 +++ llvm/tools/bugpoint/TestPasses.cpp Wed Mar 17 11:29:08 2004 @@ -44,7 +44,7 @@ namespace { /// DeleteCalls - This pass is used to test bugpoint. It intentionally - /// deletes all call instructions, "misoptimizing" the program. + /// deletes some call instructions, "misoptimizing" the program. class DeleteCalls : public BasicBlockPass { bool runOnBasicBlock(BasicBlock &BB) { for (BasicBlock::iterator I = BB.begin(), E = BB.end(); I != E; ++I) @@ -52,6 +52,7 @@ if (!CI->use_empty()) CI->replaceAllUsesWith(Constant::getNullValue(CI->getType())); CI->getParent()->getInstList().erase(CI); + break; } return false; } From lattner at cs.uiuc.edu Wed Mar 17 11:38:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed Mar 17 11:38:02 2004 Subject: [llvm-commits] CVS: llvm/tools/bugpoint/ExtractFunction.cpp Message-ID: <200403171737.LAA26695@zion.cs.uiuc.edu> Changes in directory llvm/tools/bugpoint: ExtractFunction.cpp updated: 1.30 -> 1.31 --- Log message: Fix an inverted condition that causes us to think that loop extraction accomplished something when it really did not. This does not fix the bigger problem tho. --- Diffs of the changes: (+1 -1) Index: llvm/tools/bugpoint/ExtractFunction.cpp diff -u llvm/tools/bugpoint/ExtractFunction.cpp:1.30 llvm/tools/bugpoint/ExtractFunction.cpp:1.31 --- llvm/tools/bugpoint/ExtractFunction.cpp:1.30 Sun Mar 14 16:08:00 2004 +++ llvm/tools/bugpoint/ExtractFunction.cpp Wed Mar 17 11:37:18 2004 @@ -141,7 +141,7 @@ // Check to see if we created any new functions. If not, no loops were // extracted and we should return null. - if (M->size() != NewM->size()) { + if (M->size() == NewM->size()) { delete NewM; return 0; } From lattner at cs.uiuc.edu Wed Mar 17 11:43:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed Mar 17 11:43:01 2004 Subject: [llvm-commits] CVS: llvm/tools/bugpoint/Miscompilation.cpp Message-ID: <200403171742.LAA27844@zion.cs.uiuc.edu> Changes in directory llvm/tools/bugpoint: Miscompilation.cpp updated: 1.32 -> 1.33 --- Log message: When loop extraction succeeds, make sure to map the function pointers over to avoid dangling references. --- Diffs of the changes: (+11 -0) Index: llvm/tools/bugpoint/Miscompilation.cpp diff -u llvm/tools/bugpoint/Miscompilation.cpp:1.32 llvm/tools/bugpoint/Miscompilation.cpp:1.33 --- llvm/tools/bugpoint/Miscompilation.cpp:1.32 Mon Mar 15 19:51:54 2004 +++ llvm/tools/bugpoint/Miscompilation.cpp Wed Mar 17 11:42:09 2004 @@ -268,6 +268,17 @@ exit(1); } delete ToOptimizeLoopExtracted; + + // All of the Function*'s in the MiscompiledFunctions list are in the old + // module. Make sure to update them to point to the corresponding functions + // in the new module. + for (unsigned i = 0, e = MiscompiledFunctions.size(); i != e; ++i) { + Function *OldF = MiscompiledFunctions[i]; + Function *NewF = + ToNotOptimize->getFunction(OldF->getName(), OldF->getFunctionType()); + MiscompiledFunctions[i] = NewF; + } + BD.setNewProgram(ToNotOptimize); MadeChange = true; } From criswell at cs.uiuc.edu Wed Mar 17 14:08:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Wed Mar 17 14:08:02 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/GettingStarted.html Message-ID: <200403172007.OAA26610@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.51 -> 1.51.2.1 --- Log message: Added information about how to get QMTest 2.0.3. --- Diffs of the changes: (+16 -3) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.51 llvm/docs/GettingStarted.html:1.51.2.1 --- llvm/docs/GettingStarted.html:1.51 Fri Mar 12 14:31:37 2004 +++ llvm/docs/GettingStarted.html Wed Mar 17 14:07:32 2004 @@ -274,10 +274,23 @@ automake from 1.4p5 on should work; we only use aclocal from that package.

      -
    7. QMTest
      8. +
    8. QMTest 2.0.3
    9. Python -

      These are needed to use the LLVM test suite.

      10. +

      + These are needed to use the LLVM test suite. Please note that newer + versions of QMTest may not work with the LLVM test suite. QMTest 2.0.3 + can be retrieved from the QMTest CVS repository using the following + commands: +

        +
      • cvs -d :pserver:anoncvs at cvs.codesourcery.com:/home/qm/Repository login +
        • +
      • When prompted, use anoncvs as the password. +
        • +
      • cvs -d :pserver:anoncvs at cvs.codesourcery.com:/home/qm/Repository co -r release-2-0-3 qm +
        • +
      +

      @@ -1170,7 +1183,7 @@ Chris Lattner
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/12 20:31:37 $ + Last modified: $Date: 2004/03/17 20:07:32 $ From criswell at gally.cs.uiuc.edu Wed Mar 17 14:59:01 2004 From: criswell at gally.cs.uiuc.edu (John Criswell) Date: Wed Mar 17 14:59:01 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/CommandGuide/bugpoint.html Message-ID: <200403172058.i2HKwKk03052@gally.cs.uiuc.edu> Changes in directory llvm/docs/CommandGuide: bugpoint.html updated: 1.24 -> 1.24.2.1 --- Log message: Updated options for release 1.2. --- Diffs of the changes: (+16 -0) Index: llvm/docs/CommandGuide/bugpoint.html diff -u llvm/docs/CommandGuide/bugpoint.html:1.24 llvm/docs/CommandGuide/bugpoint.html:1.24.2.1 --- llvm/docs/CommandGuide/bugpoint.html:1.24 Sat Mar 13 13:36:30 2004 +++ llvm/docs/CommandGuide/bugpoint.html Wed Mar 17 14:58:09 2004 @@ -184,12 +184,25 @@ Assume a non-zero exit code or core dump from the test program is a failure. Defaults to true.

      +

    10. -dsa-track-integers
      + Track integers as potential pointers.

      +

    11. -disable-{dce,simplifycfg}
      Do not run the specified passes to clean up and reduce the size of the test program. By default, bugpoint uses these passes internally when attempting to reduce test programs. If you're trying to find a bug in one of these passes, bugpoint may crash.

      +

    12. -enable-correct-eh-support
      + Make the -lowerinvoke pass insert expensive, but correct, exception + handling code.

      + +

    13. -internalize-public-api-file <filename>
      + Preserve the symbols listed in the file filename.

      + +

    14. -internalize-public-api-list <list>
      + Preserve the symbols listed in list.

      +

    15. -help
      Print a summary of command line options.

      @@ -214,6 +227,9 @@ (the "reference output"). If you do not use this option, bugpoint will attempt to generate a reference output by compiling the program with the C backend and running it.

      + +

    16. -profile-info-file <filename>
      + Profile file loaded by -profile-loader.

    17. -run-{int,jit,llc,cbe}
      Whenever the test program is compiled, bugpoint should generate From lattner at cs.uiuc.edu Wed Mar 17 15:11:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed Mar 17 15:11:01 2004 Subject: [llvm-commits] CVS: llvm/docs/WritingAnLLVMPass.html Message-ID: <200403172110.PAA29149@zion.cs.uiuc.edu> Changes in directory llvm/docs: WritingAnLLVMPass.html updated: 1.24 -> 1.25 --- Log message: Rewrite the second on AnalysisUsage usage. This documents the new addRequiredTransitive member that Misha added, and explains the whole concept a lot better. Also, the document used incorrect "subsubsection" tags instead of "doc_subsubsection" which this fixes. --- Diffs of the changes: (+116 -71) Index: llvm/docs/WritingAnLLVMPass.html diff -u llvm/docs/WritingAnLLVMPass.html:1.24 llvm/docs/WritingAnLLVMPass.html:1.25 --- llvm/docs/WritingAnLLVMPass.html:1.24 Mon Mar 8 17:06:46 2004 +++ llvm/docs/WritingAnLLVMPass.html Wed Mar 17 15:09:55 2004 @@ -59,7 +59,10 @@
    18. Implementing Analysis Groups
        @@ -171,12 +174,9 @@

        This makefile specifies that all of the .cpp files in the current directory are to be compiled and linked together into a lib/Debug/libhello.so shared object that can be dynamically loaded by -the opt or analyze tools.

        - -

        -Note that the suffix of the shared library may differ from the example above if -your system uses a different suffix by default. -

        +the opt or analyze tools. If your operating system uses a +suffix other than .so (such as windows of Mac OS/X), the appropriate extension +will be used.

        Now that we have the build scripts set up, we just need to write the code for the pass itself.

        @@ -487,7 +487,7 @@ -
        +
        The doInitialization(Module &) method
        @@ -516,7 +516,7 @@
        -
        +
        The runOnFunction method
        @@ -533,7 +533,7 @@
        -
        +
        The doFinalization(Module &) method
        @@ -581,7 +581,7 @@
        -
        +
        The doInitialization(Function &) method
        @@ -603,7 +603,7 @@
        -
        +
        The runOnBasicBlock method
        @@ -621,7 +621,7 @@
        -
        +
        The doFinalization(Function &) method
        @@ -647,14 +647,12 @@
        -

        A MachineFunctionPass executes on the machine-dependent -representation of each LLVM function in the program, -independent of all of the other functions in the program. -A MachineFunctionPass is also a FunctionPass, so all +

        A MachineFunctionPass is a part of the LLVM code generator that +executes on the machine-dependent representation of each LLVM function in the +program. A MachineFunctionPass is also a FunctionPass, so all the restrictions that apply to a FunctionPass also apply to it. -MachineFunctionPasses also have additional restrictions. In -particular, MachineFunctionPasses are not allowed to do any of -the following:

        +MachineFunctionPasses also have additional restrictions. In particular, +MachineFunctionPasses are not allowed to do any of the following:

        1. Modify any LLVM Instructions, BasicBlocks or Functions.
          2. @@ -669,7 +667,7 @@
        -
        +
        The runOnMachineFunction(MachineFunction &MF) method
        @@ -718,11 +716,7 @@
      • RegisterAnalysis - This template should be used when you are registering a pass that logically should be available for use in the -'analysis' utility.
        • - -
      • RegisterLLC - This template should be used when you are -registering a pass that logically should be available for use in the -'llc' utility.
        • +'analyze' utility.
      • RegisterPass - This is the generic form of the Register* templates that should be used if you want your pass listed by @@ -740,14 +734,6 @@ the pass, which is to be used for the --help output of programs, as well as for debug output generated by the --debug-pass option.

        -

        If you pass is constructed by its default constructor, you only ever have to -pass these two arguments. If, on the other hand, you require other information -(like target specific information), you must pass an additional argument. This -argument is a pointer to a function used to create the pass. For an example of -how this works, look at the LowerAllocations.cpp -file.

        -

        If a pass is registered to be used by the analyze utility, you should implement the virtual print method:

        @@ -819,34 +805,77 @@ should fill in the AnalysisUsage object with information about which passes are required and not invalidated. To -do this, the following set methods are provided by the AnalysisUsage -class:

        +do this, a pass may call any of the following methods on the AnalysisUsage +object:

        +
        • -
        -  // addRequires - Add the specified pass to the required set for your pass.
-  template<class PassClass>
-  AnalysisUsage &AnalysisUsage::addRequired();
+
+
        
+  The AnalysisUsage::addRequired<> and AnalysisUsage::addRequiredTransitive<> methods
+
        
 
-  // addPreserved - Add the specified pass to the set of analyses preserved by
-  // this pass
-  template<class PassClass>
-  AnalysisUsage &AnalysisUsage::addPreserved();
+
        
+
        
+If you pass requires a previous pass to be executed (an analysis for example),
+it can use one of these methods to arrange for it to be run before your pass.
+LLVM has many different types of analyses and passes that can be required,
+spaning the range from DominatorSet to BreakCriticalEdges.
+requiring BreakCriticalEdges, for example, guarantees that there will
+be no critical edges in the CFG when your pass has been run.
+
        
 
-  // setPreservesAll - Call this if the pass does not modify its input at all
-  void AnalysisUsage::setPreservesAll();
+
        
+Some analyses chain to other analyses to do their job.  For example, an AliasAnalysis implementation is required to chain to other alias analysis passes.  In
+cases where analyses chain, the addRequiredTransitive method should be
+used instead of the addRequired method.  This informs the PassManager
+that the transitively required pass should be alive as long as the requiring
+pass is.
+
        
+
        
 
-  // setPreservesCFG - This function should be called by the pass, iff they do not:
-  //
-  //  1. Add or remove basic blocks from the function
-  //  2. Modify terminator instructions in any way.
-  //
-  //  This is automatically implied for BasicBlockPass's
-  //
-  void AnalysisUsage::setPreservesCFG();
-
        + +
        + 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 +this reason, passes are allowed to declare that they preserve (i.e., they don't +invalidate) an existing analysis if it's available. For example, a simple +constant folding pass would not modify the CFG, so it can't possible effect the +results of dominator analysis. By default, all passes are assumed to invalidate +all others. +

        + +

        +The AnalysisUsage class provides several methods which are useful in +certain circumstances that are related to addPreserved. In particular, +the setPreservesAll method can be called to indicate that the pass does +not modify the LLVM program at all (which is true for analyses), and the +setPreservesCFG method can be used by transformations that change +instructions in the program but do not modify the CFG or terminator instructions +(note that this property is implicitly set for BasicBlockPass's). +

        + +

        +addPreserved is particularly useful for transformations like +BreakCriticalEdges. This pass knows how to update a small set of loop +and dominator related analyses if they exist, so it can preserve them, despite +the fact that it hacks on the CFG. +

        +
        + + +
        + Example implementations of getAnalysisUsage +
        -

        Some examples of how to use these methods are:

        +
           // This is an example implementation from an analysis, which does not modify
@@ -871,20 +900,22 @@
 
 
 
        
-  The getAnalysis<> method
+  The getAnalysis<> and getAnalysisToUpdate<> methods
 
        
 
 
        
 
-
        The Pass::getAnalysis<> method is inherited by your class,
-providing you with access to the passes that you declared that you required with
-the getAnalysisUsage method.  It takes
-a single template argument that specifies which pass class you want, and returns
-a reference to that pass.
        
+
        The Pass::getAnalysis<> method is automatically inherited by
+your class, providing you with access to the passes that you declared that you
+required with the getAnalysisUsage
+method.  It takes a single template argument that specifies which pass class you
+want, and returns a reference to that pass.  For example:
        
 
 
        -  template<typename PassClass>
-  AnalysisType &getAnalysis();
+   bool LICM::runOnFunction(Function &F) {
+     LoopInfo &LI = getAnalysis<LoopInfo>();
+     ...
+   }
 
        
 
 
        This method call returns a reference to the pass desired.  You may get a
@@ -894,6 +925,20 @@
 method can be called by your run* method implementation, or by any
 other local method invoked by your run* method.
        
 
+
        
+If your pass is capable of updating analyses if they exist (e.g.,
+BreakCriticalEdges, as described above), you can use the
+getAnalysisToUpdate method, which returns a pointer to the analysis if
+it is active.  For example:
        
+
+
        +  ...
+  if (DominatorSet *DS = getAnalysisToUpdate<DominatorSet>()) {
+    // A DominatorSet is active.  This code will update it.
+  }
+  ...
+
        
+
 
        
 
 
@@ -924,7 +969,7 @@
        -
        +
        Analysis Group Concepts
        @@ -975,7 +1020,7 @@
        -
        +
        Using RegisterAnalysisGroup
        @@ -1345,7 +1390,7 @@
        -
        +
        Multithreaded LLVM
        @@ -1368,7 +1413,7 @@
        -
        +
        A new ModuleSource interface
        @@ -1395,7 +1440,7 @@
        -
        +
        Passes requiring FunctionPasses
        @@ -1426,7 +1471,7 @@ Chris Lattner
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/08 23:06:46 $ + Last modified: $Date: 2004/03/17 21:09:55 $ From criswell at gally.cs.uiuc.edu Wed Mar 17 15:21:01 2004 From: criswell at gally.cs.uiuc.edu (John Criswell) Date: Wed Mar 17 15:21:01 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/CommandGuide/analyze.html bugpoint.html opt.html Message-ID: <200403172120.i2HLKPh03247@gally.cs.uiuc.edu> Changes in directory llvm/docs/CommandGuide: analyze.html updated: 1.10 -> 1.10.2.1 bugpoint.html updated: 1.24.2.1 -> 1.24.2.2 opt.html updated: 1.10 -> 1.10.2.1 --- Log message: Removed the -dsa-track-integers option. --- Diffs of the changes: (+0 -13) Index: llvm/docs/CommandGuide/analyze.html diff -u llvm/docs/CommandGuide/analyze.html:1.10 llvm/docs/CommandGuide/analyze.html:1.10.2.1 --- llvm/docs/CommandGuide/analyze.html:1.10 Fri Mar 12 16:45:35 2004 +++ llvm/docs/CommandGuide/analyze.html Wed Mar 17 15:20:14 2004 @@ -53,11 +53,6 @@ list of available analysis passes.

        -

      • -dsa-track-integers -
        - Track integers as potential pointers. -

        -

      • -profile-info-file <filename>
        Specify the name of the file loaded by the -profile-loader option. Index: llvm/docs/CommandGuide/bugpoint.html diff -u llvm/docs/CommandGuide/bugpoint.html:1.24.2.1 llvm/docs/CommandGuide/bugpoint.html:1.24.2.2 --- llvm/docs/CommandGuide/bugpoint.html:1.24.2.1 Wed Mar 17 14:58:09 2004 +++ llvm/docs/CommandGuide/bugpoint.html Wed Mar 17 15:20:14 2004 @@ -184,9 +184,6 @@ Assume a non-zero exit code or core dump from the test program is a failure. Defaults to true.

        -

      • -dsa-track-integers
        - Track integers as potential pointers.

        -

      • -disable-{dce,simplifycfg}
        Do not run the specified passes to clean up and reduce the size of the test program. By default, bugpoint uses these passes internally Index: llvm/docs/CommandGuide/opt.html diff -u llvm/docs/CommandGuide/opt.html:1.10 llvm/docs/CommandGuide/opt.html:1.10.2.1 --- llvm/docs/CommandGuide/opt.html:1.10 Fri Mar 12 16:45:35 2004 +++ llvm/docs/CommandGuide/opt.html Wed Mar 17 15:20:14 2004 @@ -53,11 +53,6 @@ Specify the output filename.

        -

      • -dsa-track-integers -
        - Track integers as potential pointers. -

        -

      • -profile-info-file <filename>
        Specify the name of the file loaded by the -profile-loader option. From criswell at gally.cs.uiuc.edu Wed Mar 17 15:23:02 2004 From: criswell at gally.cs.uiuc.edu (John Criswell) Date: Wed Mar 17 15:23:02 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/WritingAnLLVMPass.html Message-ID: <200403172122.i2HLMSc03382@gally.cs.uiuc.edu> Changes in directory llvm/docs: WritingAnLLVMPass.html updated: 1.24 -> 1.24.2.1 --- Log message: Slurping up Revision 1.25 of this document, which is described as: "Rewrite the second on AnalysisUsage usage. This documents the new addRequiredTransitive member that Misha added, and explains the whole concept a lot better. Also, the document used incorrect "subsubsection" tags instead of "doc_subsubsection" which this fixes." --- Diffs of the changes: (+116 -71) Index: llvm/docs/WritingAnLLVMPass.html diff -u llvm/docs/WritingAnLLVMPass.html:1.24 llvm/docs/WritingAnLLVMPass.html:1.24.2.1 --- llvm/docs/WritingAnLLVMPass.html:1.24 Mon Mar 8 17:06:46 2004 +++ llvm/docs/WritingAnLLVMPass.html Wed Mar 17 15:22:18 2004 @@ -59,7 +59,10 @@
      • Implementing Analysis Groups
          @@ -171,12 +174,9 @@

          This makefile specifies that all of the .cpp files in the current directory are to be compiled and linked together into a lib/Debug/libhello.so shared object that can be dynamically loaded by -the opt or analyze tools.

          - -

          -Note that the suffix of the shared library may differ from the example above if -your system uses a different suffix by default. -

          +the opt or analyze tools. If your operating system uses a +suffix other than .so (such as windows of Mac OS/X), the appropriate extension +will be used.

          Now that we have the build scripts set up, we just need to write the code for the pass itself.

          @@ -487,7 +487,7 @@
        • -
        +
        The doInitialization(Module &) method
        @@ -516,7 +516,7 @@
        -
        +
        The runOnFunction method
        @@ -533,7 +533,7 @@
        -
        +
        The doFinalization(Module &) method
        @@ -581,7 +581,7 @@
        -
        +
        The doInitialization(Function &) method
        @@ -603,7 +603,7 @@
        -
        +
        The runOnBasicBlock method
        @@ -621,7 +621,7 @@
        -
        +
        The doFinalization(Function &) method
        @@ -647,14 +647,12 @@
        -

        A MachineFunctionPass executes on the machine-dependent -representation of each LLVM function in the program, -independent of all of the other functions in the program. -A MachineFunctionPass is also a FunctionPass, so all +

        A MachineFunctionPass is a part of the LLVM code generator that +executes on the machine-dependent representation of each LLVM function in the +program. A MachineFunctionPass is also a FunctionPass, so all the restrictions that apply to a FunctionPass also apply to it. -MachineFunctionPasses also have additional restrictions. In -particular, MachineFunctionPasses are not allowed to do any of -the following:

        +MachineFunctionPasses also have additional restrictions. In particular, +MachineFunctionPasses are not allowed to do any of the following:

        1. Modify any LLVM Instructions, BasicBlocks or Functions.
          2. @@ -669,7 +667,7 @@
        -
        +
        The runOnMachineFunction(MachineFunction &MF) method
        @@ -718,11 +716,7 @@
      • RegisterAnalysis - This template should be used when you are registering a pass that logically should be available for use in the -'analysis' utility.
        • - -
      • RegisterLLC - This template should be used when you are -registering a pass that logically should be available for use in the -'llc' utility.
        • +'analyze' utility.
      • RegisterPass - This is the generic form of the Register* templates that should be used if you want your pass listed by @@ -740,14 +734,6 @@ the pass, which is to be used for the --help output of programs, as well as for debug output generated by the --debug-pass option.

        -

        If you pass is constructed by its default constructor, you only ever have to -pass these two arguments. If, on the other hand, you require other information -(like target specific information), you must pass an additional argument. This -argument is a pointer to a function used to create the pass. For an example of -how this works, look at the LowerAllocations.cpp -file.

        -

        If a pass is registered to be used by the analyze utility, you should implement the virtual print method:

        @@ -819,34 +805,77 @@ should fill in the AnalysisUsage object with information about which passes are required and not invalidated. To -do this, the following set methods are provided by the AnalysisUsage -class:

        +do this, a pass may call any of the following methods on the AnalysisUsage +object:

        +
        • -
        -  // addRequires - Add the specified pass to the required set for your pass.
-  template<class PassClass>
-  AnalysisUsage &AnalysisUsage::addRequired();
+
+
        
+  The AnalysisUsage::addRequired<> and AnalysisUsage::addRequiredTransitive<> methods
+
        
 
-  // addPreserved - Add the specified pass to the set of analyses preserved by
-  // this pass
-  template<class PassClass>
-  AnalysisUsage &AnalysisUsage::addPreserved();
+
        
+
        
+If you pass requires a previous pass to be executed (an analysis for example),
+it can use one of these methods to arrange for it to be run before your pass.
+LLVM has many different types of analyses and passes that can be required,
+spaning the range from DominatorSet to BreakCriticalEdges.
+requiring BreakCriticalEdges, for example, guarantees that there will
+be no critical edges in the CFG when your pass has been run.
+
        
 
-  // setPreservesAll - Call this if the pass does not modify its input at all
-  void AnalysisUsage::setPreservesAll();
+
        
+Some analyses chain to other analyses to do their job.  For example, an AliasAnalysis implementation is required to chain to other alias analysis passes.  In
+cases where analyses chain, the addRequiredTransitive method should be
+used instead of the addRequired method.  This informs the PassManager
+that the transitively required pass should be alive as long as the requiring
+pass is.
+
        
+
        
 
-  // setPreservesCFG - This function should be called by the pass, iff they do not:
-  //
-  //  1. Add or remove basic blocks from the function
-  //  2. Modify terminator instructions in any way.
-  //
-  //  This is automatically implied for BasicBlockPass's
-  //
-  void AnalysisUsage::setPreservesCFG();
-
        + +
        + 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 +this reason, passes are allowed to declare that they preserve (i.e., they don't +invalidate) an existing analysis if it's available. For example, a simple +constant folding pass would not modify the CFG, so it can't possible effect the +results of dominator analysis. By default, all passes are assumed to invalidate +all others. +

        + +

        +The AnalysisUsage class provides several methods which are useful in +certain circumstances that are related to addPreserved. In particular, +the setPreservesAll method can be called to indicate that the pass does +not modify the LLVM program at all (which is true for analyses), and the +setPreservesCFG method can be used by transformations that change +instructions in the program but do not modify the CFG or terminator instructions +(note that this property is implicitly set for BasicBlockPass's). +

        + +

        +addPreserved is particularly useful for transformations like +BreakCriticalEdges. This pass knows how to update a small set of loop +and dominator related analyses if they exist, so it can preserve them, despite +the fact that it hacks on the CFG. +

        +
        + + +
        + Example implementations of getAnalysisUsage +
        -

        Some examples of how to use these methods are:

        +
           // This is an example implementation from an analysis, which does not modify
@@ -871,20 +900,22 @@
 
 
 
        
-  The getAnalysis<> method
+  The getAnalysis<> and getAnalysisToUpdate<> methods
 
        
 
 
        
 
-
        The Pass::getAnalysis<> method is inherited by your class,
-providing you with access to the passes that you declared that you required with
-the getAnalysisUsage method.  It takes
-a single template argument that specifies which pass class you want, and returns
-a reference to that pass.
        
+
        The Pass::getAnalysis<> method is automatically inherited by
+your class, providing you with access to the passes that you declared that you
+required with the getAnalysisUsage
+method.  It takes a single template argument that specifies which pass class you
+want, and returns a reference to that pass.  For example:
        
 
 
        -  template<typename PassClass>
-  AnalysisType &getAnalysis();
+   bool LICM::runOnFunction(Function &F) {
+     LoopInfo &LI = getAnalysis<LoopInfo>();
+     ...
+   }
 
        
 
 
        This method call returns a reference to the pass desired.  You may get a
@@ -894,6 +925,20 @@
 method can be called by your run* method implementation, or by any
 other local method invoked by your run* method.
        
 
+
        
+If your pass is capable of updating analyses if they exist (e.g.,
+BreakCriticalEdges, as described above), you can use the
+getAnalysisToUpdate method, which returns a pointer to the analysis if
+it is active.  For example:
        
+
+
        +  ...
+  if (DominatorSet *DS = getAnalysisToUpdate<DominatorSet>()) {
+    // A DominatorSet is active.  This code will update it.
+  }
+  ...
+
        
+
 
        
 
 
@@ -924,7 +969,7 @@
        -
        +
        Analysis Group Concepts
        @@ -975,7 +1020,7 @@
        -
        +
        Using RegisterAnalysisGroup
        @@ -1345,7 +1390,7 @@
        -
        +
        Multithreaded LLVM
        @@ -1368,7 +1413,7 @@
        -
        +
        A new ModuleSource interface
        @@ -1395,7 +1440,7 @@
        -
        +
        Passes requiring FunctionPasses
        @@ -1426,7 +1471,7 @@ Chris Lattner
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/08 23:06:46 $ + Last modified: $Date: 2004/03/17 21:22:18 $ From lattner at cs.uiuc.edu Wed Mar 17 15:34:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Wed Mar 17 15:34:01 2004 Subject: [llvm-commits] CVS: llvm/docs/WritingAnLLVMPass.html Message-ID: <200403172133.PAA29715@zion.cs.uiuc.edu> Changes in directory llvm/docs: WritingAnLLVMPass.html updated: 1.25 -> 1.26 --- Log message: Fix a tag-o --- Diffs of the changes: (+2 -2) Index: llvm/docs/WritingAnLLVMPass.html diff -u llvm/docs/WritingAnLLVMPass.html:1.25 llvm/docs/WritingAnLLVMPass.html:1.26 --- llvm/docs/WritingAnLLVMPass.html:1.25 Wed Mar 17 15:09:55 2004 +++ llvm/docs/WritingAnLLVMPass.html Wed Mar 17 15:33:32 2004 @@ -912,7 +912,7 @@ want, and returns a reference to that pass. For example:

        -   bool LICM::runOnFunction(Function &F) {
+   bool LICM::runOnFunction(Function &F) {
      LoopInfo &LI = getAnalysis<LoopInfo>();
      ...
    }
@@ -1471,7 +1471,7 @@
 
   Chris Lattner
        
   The LLVM Compiler Infrastructure
        
-  Last modified: $Date: 2004/03/17 21:09:55 $
+  Last modified: $Date: 2004/03/17 21:33:32 $
 
 
 




From criswell at cs.uiuc.edu  Wed Mar 17 17:13:16 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Wed Mar 17 17:13:16 2004
Subject: [llvm-commits] [release_12] CVS: llvm/runtime/zlib/Makefile
Message-ID: <200403172312.RAA16632@choi.cs.uiuc.edu>


Changes in directory llvm/runtime/zlib:

Makefile updated: 1.2 -> 1.2.4.1

---
Log message:

Defined the NO_DUMMY_DECL variable.  This removes the zlib hack that
for "bad compilers" that generates a type conflict resolution error when
linking zlib with gccld.



---
Diffs of the changes:  (+1 -0)

Index: llvm/runtime/zlib/Makefile
diff -u llvm/runtime/zlib/Makefile:1.2 llvm/runtime/zlib/Makefile:1.2.4.1
--- llvm/runtime/zlib/Makefile:1.2	Fri Feb 20 15:26:45 2004
+++ llvm/runtime/zlib/Makefile	Wed Mar 17 17:12:00 2004
@@ -11,6 +11,7 @@
 BUILD_ARCHIVE=1
 DONT_BUILD_RELINKED=1
 LIBRARYNAME=z
+CPPFLAGS += -DNO_DUMMY_DECL=1
 
 Source = adler32.c compress.c crc32.c gzio.c uncompr.c deflate.c trees.c \
          zutil.c inflate.c infback.c inftrees.c inffast.c




From lattner at cs.uiuc.edu  Wed Mar 17 17:23:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 17:23:01 2004
Subject: [llvm-commits] CVS: llvm/lib/Analysis/AliasSetTracker.cpp
Message-ID: <200403172322.RAA07676@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Analysis:

AliasSetTracker.cpp updated: 1.13 -> 1.14

---
Log message:

Fix a HORRIBLY NASTY bug that caused siod to stop working last night.



---
Diffs of the changes:  (+1 -1)

Index: llvm/lib/Analysis/AliasSetTracker.cpp
diff -u llvm/lib/Analysis/AliasSetTracker.cpp:1.13 llvm/lib/Analysis/AliasSetTracker.cpp:1.14
--- llvm/lib/Analysis/AliasSetTracker.cpp:1.13	Mon Mar 15 00:28:07 2004
+++ llvm/lib/Analysis/AliasSetTracker.cpp	Wed Mar 17 17:22:04 2004
@@ -101,7 +101,7 @@
       return;
     else if (AA.onlyReadsMemory(F)) {
       AliasTy = MayAlias;
-      AccessTy = Refs;
+      AccessTy |= Refs;
       return;
     }
   }




From lattner at cs.uiuc.edu  Wed Mar 17 21:16:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 21:16:02 2004
Subject: [llvm-commits] CVS: llvm/include/llvm/Transforms/Utils/FunctionUtils.h
Message-ID: <200403180315.VAA12351@zion.cs.uiuc.edu>


Changes in directory llvm/include/llvm/Transforms/Utils:

FunctionUtils.h updated: 1.3 -> 1.4

---
Log message:

Make this header file self-contained


---
Diffs of the changes:  (+3 -0)

Index: llvm/include/llvm/Transforms/Utils/FunctionUtils.h
diff -u llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.3 llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.4
--- llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.3	Mon Mar  1 18:20:32 2004
+++ llvm/include/llvm/Transforms/Utils/FunctionUtils.h	Wed Mar 17 21:14:56 2004
@@ -14,8 +14,11 @@
 #ifndef LLVM_TRANSFORMS_UTILS_FUNCTION_H
 #define LLVM_TRANSFORMS_UTILS_FUNCTION_H
 
+#include 
+
 namespace llvm {
 
+  class BasicBlock;
 class Function;
 class Loop;
 




From lattner at cs.uiuc.edu  Wed Mar 17 21:16:07 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 21:16:07 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403180315.VAA12361@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.10 -> 1.11

---
Log message:

Prune #includes, moving the module interface to the front.  Note that this 
exposed the fact that the header was not self-contained.  There is a reason
we do things :)


---
Diffs of the changes:  (+1 -2)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.10 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.11
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.10	Sun Mar 14 19:26:44 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Wed Mar 17 21:15:29 2004
@@ -13,7 +13,7 @@
 //
 //===----------------------------------------------------------------------===//
 
-#include "llvm/BasicBlock.h"
+#include "llvm/Transforms/Utils/FunctionUtils.h"
 #include "llvm/Constants.h"
 #include "llvm/DerivedTypes.h"
 #include "llvm/Instructions.h"
@@ -22,7 +22,6 @@
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Analysis/Verifier.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
-#include "llvm/Transforms/Utils/FunctionUtils.h"
 #include "Support/Debug.h"
 #include "Support/StringExtras.h"
 #include 




From lattner at cs.uiuc.edu  Wed Mar 17 21:48:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 21:48:01 2004
Subject: [llvm-commits] CVS: llvm/include/llvm/Transforms/Utils/FunctionUtils.h
Message-ID: <200403180347.VAA16243@zion.cs.uiuc.edu>


Changes in directory llvm/include/llvm/Transforms/Utils:

FunctionUtils.h updated: 1.4 -> 1.5

---
Log message:

The code extractor needs dominator information, so we provide it.


---
Diffs of the changes:  (+14 -14)

Index: llvm/include/llvm/Transforms/Utils/FunctionUtils.h
diff -u llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.4 llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.5
--- llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.4	Wed Mar 17 21:14:56 2004
+++ llvm/include/llvm/Transforms/Utils/FunctionUtils.h	Wed Mar 17 21:47:46 2004
@@ -17,23 +17,23 @@
 #include 
 
 namespace llvm {
-
   class BasicBlock;
-class Function;
-class Loop;
-
-/// ExtractCodeRegion - rip out a sequence of basic blocks into a new function
-///
-Function* ExtractCodeRegion(const std::vector &code);
-
-/// ExtractLoop - rip out a natural loop into a new function
-///
-Function* ExtractLoop(Loop *L);
+  class DominatorSet;
+  class Function;
+  class Loop;
+  
+  /// ExtractCodeRegion - rip out a sequence of basic blocks into a new function
+  ///
+  Function* ExtractCodeRegion(DominatorSet &DS,
+                              const std::vector &code);
 
-/// ExtractBasicBlock - rip out a basic block into a new function
-///
-Function* ExtractBasicBlock(BasicBlock *BB);
+  /// ExtractLoop - rip out a natural loop into a new function
+  ///
+  Function* ExtractLoop(DominatorSet &DS, Loop *L);
 
+  /// ExtractBasicBlock - rip out a basic block into a new function
+  ///
+  Function* ExtractBasicBlock(BasicBlock *BB);
 }
 
 #endif




From lattner at cs.uiuc.edu  Wed Mar 17 21:49:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 21:49:02 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/IPO/LoopExtractor.cpp
Message-ID: <200403180348.VAA16255@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/IPO:

LoopExtractor.cpp updated: 1.7 -> 1.8

---
Log message:

The code extractor needs dominator info.  Provide it


---
Diffs of the changes:  (+7 -3)

Index: llvm/lib/Transforms/IPO/LoopExtractor.cpp
diff -u llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.7 llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.8
--- llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.7	Sun Mar 14 18:02:02 2004
+++ llvm/lib/Transforms/IPO/LoopExtractor.cpp	Wed Mar 17 21:48:06 2004
@@ -18,6 +18,7 @@
 #include "llvm/iTerminators.h"
 #include "llvm/Module.h"
 #include "llvm/Pass.h"
+#include "llvm/Analysis/Dominators.h"
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Transforms/Scalar.h"
 #include "llvm/Transforms/Utils/FunctionUtils.h"
@@ -35,6 +36,7 @@
     virtual bool runOnFunction(Function &F);
     
     virtual void getAnalysisUsage(AnalysisUsage &AU) const {
+      AU.addRequired();
       AU.addRequired();
       AU.addRequiredID(LoopSimplifyID);
     }
@@ -59,6 +61,8 @@
   if (LI.begin() == LI.end())
     return false;
 
+  DominatorSet &DS = getAnalysis();
+
   // If there is more than one top-level loop in this function, extract all of
   // the loops.
   bool Changed = false;
@@ -66,7 +70,7 @@
     for (LoopInfo::iterator i = LI.begin(), e = LI.end(); i != e; ++i) {
       if (NumLoops == 0) return Changed;
       --NumLoops;
-      Changed |= (ExtractLoop(*i) != 0);
+      Changed |= ExtractLoop(DS, *i) != 0;
     }
   } else {
     // Otherwise there is exactly one top-level loop.  If this function is more
@@ -93,7 +97,7 @@
     if (ShouldExtractLoop) {
       if (NumLoops == 0) return Changed;
       --NumLoops;
-      Changed |= (ExtractLoop(TLL) != 0);
+      Changed |= ExtractLoop(DS, TLL) != 0;
     } else {
       // Okay, this function is a minimal container around the specified loop.
       // If we extract the loop, we will continue to just keep extracting it
@@ -102,7 +106,7 @@
       for (Loop::iterator i = TLL->begin(), e = TLL->end(); i != e; ++i) {
         if (NumLoops == 0) return Changed;
         --NumLoops;
-        Changed |= (ExtractLoop(*i) != 0);
+        Changed |= ExtractLoop(DS, *i) != 0;
       }
     }
   }




From lattner at cs.uiuc.edu  Wed Mar 17 21:50:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 21:50:01 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403180349.VAA16274@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.11 -> 1.12

---
Log message:

Fix several bugs in the extractor:
1. Names were not put on the new arguments created (ok, this just helps sanity :)
2. Fix outgoing pointer values
3. Do not insert stores for values that had not been computed
4. Fix some wierd problems with the outset calculation

This fixes CodeExtractor/2004-03-14-DominanceProblem.ll, making the extractor
work on at least one simple case!



---
Diffs of the changes:  (+52 -45)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.11 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.12
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.11	Wed Mar 17 21:15:29 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Wed Mar 17 21:49:40 2004
@@ -19,6 +19,7 @@
 #include "llvm/Instructions.h"
 #include "llvm/Module.h"
 #include "llvm/Pass.h"
+#include "llvm/Analysis/Dominators.h"
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Analysis/Verifier.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
@@ -38,13 +39,16 @@
     return I;
   }
 
-  struct CodeExtractor {
+  class CodeExtractor {
     typedef std::vector Values;
     typedef std::vector > PhiValChangesTy;
     typedef std::map PhiVal2ArgTy;
     PhiVal2ArgTy PhiVal2Arg;
     std::set BlocksToExtract;
+    DominatorSet *DS;
   public:
+    CodeExtractor(DominatorSet *ds = 0) : DS(ds) {}
+
     Function *ExtractCodeRegion(const std::vector &code);
 
   private:
@@ -191,8 +195,10 @@
       // Consider uses of this instruction (outputs)
       for (Value::use_iterator UI = I->use_begin(), E = I->use_end();
            UI != E; ++UI)
-        if (!BlocksToExtract.count(cast(*UI)->getParent()))
-          outputs.push_back(*UI);
+        if (!BlocksToExtract.count(cast(*UI)->getParent())) {
+          outputs.push_back(I);
+          break;
+        }
     } // for: insts
   } // for: basic blocks
 }
@@ -257,18 +263,11 @@
     paramTy.push_back(value->getType());
   }
 
-  // Add the types of the output values to the function's argument list, but
-  // make them pointer types for scalars
-  for (Values::const_iterator i = outputs.begin(),
-         e = outputs.end(); i != e; ++i) {
-    const Value *value = *i;
-    DEBUG(std::cerr << "instr used in func: " << value << "\n");
-    const Type *valueType = value->getType();
-    // Convert scalar types into a pointer of that type
-    if (valueType->isPrimitiveType()) {
-      valueType = PointerType::get(valueType);
-    }
-    paramTy.push_back(valueType);
+  // Add the types of the output values to the function's argument list.
+  for (Values::const_iterator I = outputs.begin(), E = outputs.end();
+       I != E; ++I) {
+    DEBUG(std::cerr << "instr used in func: " << *I << "\n");
+    paramTy.push_back(PointerType::get((*I)->getType()));
   }
 
   DEBUG(std::cerr << "Function type: " << retTy << " f(");
@@ -285,15 +284,26 @@
                                        oldFunction->getName() + "_code", M);
   newFunction->getBasicBlockList().push_back(newRootNode);
 
-  for (unsigned i = 0, e = inputs.size(); i != e; ++i) {
+  // Create an iterator to name all of the arguments we inserted.
+  Function::aiterator AI = newFunction->abegin();
+
+  // Rewrite all users of the inputs in the extracted region to use the
+  // arguments instead.
+  for (unsigned i = 0, e = inputs.size(); i != e; ++i, ++AI) {
+    AI->setName(inputs[i]->getName());
     std::vector Users(inputs[i]->use_begin(), inputs[i]->use_end());
     for (std::vector::iterator use = Users.begin(), useE = Users.end();
          use != useE; ++use)
       if (Instruction* inst = dyn_cast(*use))
         if (BlocksToExtract.count(inst->getParent()))
-          inst->replaceUsesOfWith(inputs[i], getFunctionArg(newFunction, i));
+          inst->replaceUsesOfWith(inputs[i], AI);
   }
 
+  // Set names for all of the output arguments.
+  for (unsigned i = 0, e = outputs.size(); i != e; ++i, ++AI)
+    AI->setName(outputs[i]->getName()+".out");  
+
+
   // Rewrite branches to basic blocks outside of the loop to new dummy blocks
   // within the new function. This must be done before we lose track of which
   // blocks were originally in the code region.
@@ -332,34 +342,26 @@
 CodeExtractor::emitCallAndSwitchStatement(Function *newFunction,
                                           BasicBlock *codeReplacer,
                                           Values &inputs,
-                                          Values &outputs)
-{
+                                          Values &outputs) {
   // Emit a call to the new function, passing allocated memory for outputs and
   // just plain inputs for non-scalars
   std::vector params(inputs);
 
-  for (Values::const_iterator i = outputs.begin(), e = outputs.end(); i != e;
-       ++i) {
-    Value *Output = *i;
+  for (unsigned i = 0, e = outputs.size(); i != e; ++i) {
+    Value *Output = outputs[i];
     // Create allocas for scalar outputs
-    if (Output->getType()->isPrimitiveType()) {
-      AllocaInst *alloca =
-        new AllocaInst((*i)->getType(), 0, Output->getName()+".loc",
-                       codeReplacer->getParent()->begin()->begin());
-      params.push_back(alloca);
-
-      LoadInst *load = new LoadInst(alloca, Output->getName()+".reload");
-      codeReplacer->getInstList().push_back(load);
-      std::vector Users((*i)->use_begin(), (*i)->use_end());
-      for (std::vector::iterator use = Users.begin(), useE =Users.end();
-           use != useE; ++use) {
-        if (Instruction* inst = dyn_cast(*use)) {
-          if (!BlocksToExtract.count(inst->getParent()))
-            inst->replaceUsesOfWith(*i, load);
-        }
-      }
-    } else {
-      params.push_back(*i);
+    AllocaInst *alloca =
+      new AllocaInst(outputs[i]->getType(), 0, Output->getName()+".loc",
+                     codeReplacer->getParent()->begin()->begin());
+    params.push_back(alloca);
+    
+    LoadInst *load = new LoadInst(alloca, Output->getName()+".reload");
+    codeReplacer->getInstList().push_back(load);
+    std::vector Users(outputs[i]->use_begin(), outputs[i]->use_end());
+    for (unsigned u = 0, e = Users.size(); u != e; ++u) {
+      Instruction *inst = cast(Users[u]);
+      if (!BlocksToExtract.count(inst->getParent()))
+        inst->replaceUsesOfWith(outputs[i], load);
     }
   }
 
@@ -400,7 +402,11 @@
           // Restore values just before we exit
           // FIXME: Use a GetElementPtr to bunch the outputs in a struct
           for (unsigned out = 0, e = outputs.size(); out != e; ++out)
-            new StoreInst(outputs[out], getFunctionArg(newFunction, out),NTRet);
+            if (!DS ||
+                DS->dominates(cast(outputs[out])->getParent(),
+                              TI->getParent()))
+              new StoreInst(outputs[out], getFunctionArg(newFunction, out),
+                            NTRet);
         }
 
         // rewrite the original branch instruction with this new target
@@ -502,14 +508,15 @@
 /// ExtractCodeRegion - slurp a sequence of basic blocks into a brand new
 /// function
 ///
-Function* llvm::ExtractCodeRegion(const std::vector &code) {
-  return CodeExtractor().ExtractCodeRegion(code);
+Function* llvm::ExtractCodeRegion(DominatorSet &DS,
+                                  const std::vector &code) {
+  return CodeExtractor(&DS).ExtractCodeRegion(code);
 }
 
 /// ExtractBasicBlock - slurp a natural loop into a brand new function
 ///
-Function* llvm::ExtractLoop(Loop *L) {
-  return CodeExtractor().ExtractCodeRegion(L->getBlocks());
+Function* llvm::ExtractLoop(DominatorSet &DS, Loop *L) {
+  return CodeExtractor(&DS).ExtractCodeRegion(L->getBlocks());
 }
 
 /// ExtractBasicBlock - slurp a basic block into a brand new function




From lattner at cs.uiuc.edu  Wed Mar 17 22:11:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 22:11:01 2004
Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-OutputMismatch.ll
Message-ID: <200403180410.WAA19107@zion.cs.uiuc.edu>


Changes in directory llvm/test/Regression/Transforms/CodeExtractor:

2004-03-17-OutputMismatch.ll added (r1.1)

---
Log message:

New testcase that crashes the code extractor


---
Diffs of the changes:  (+21 -0)

Index: llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-OutputMismatch.ll
diff -c /dev/null llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-OutputMismatch.ll:1.1
*** /dev/null	Wed Mar 17 22:10:12 2004
--- llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-OutputMismatch.ll	Wed Mar 17 22:10:02 2004
***************
*** 0 ****
--- 1,21 ----
+ ; RUN: llvm-as < %s | opt -loop-extract -disable-output
+ 
+ 	%struct.node_t = type { double*, %struct.node_t*, %struct.node_t**, double**, double*, int, int }
+ 	%struct.table_t = type { [1 x %struct.node_t**], [1 x %struct.node_t**] }
+ 
+ implementation   ; Functions:
+ 
+ void %make_tables() {
+ entry:
+ 	%tmp.0.i = malloc %struct.node_t		; <%struct.node_t*> [#uses=1]
+ 	br bool false, label %no_exit.i, label %loopexit.i
+ 
+ no_exit.i:		; preds = %entry, %no_exit.i
+ 	%prev_node.0.i.1 = phi %struct.node_t* [ %tmp.16.i, %no_exit.i ], [ %tmp.0.i, %entry ]		; <%struct.node_t*> [#uses=0]
+ 	%tmp.16.i = malloc %struct.node_t		; <%struct.node_t*> [#uses=2]
+ 	br bool false, label %no_exit.i, label %loopexit.i
+ 
+ loopexit.i:		; preds = %entry, %no_exit.i
+ 	%cur_node.0.i.0 = phi %struct.node_t* [ null, %entry ], [ %tmp.16.i, %no_exit.i ]		; <%struct.node_t*> [#uses=0]
+ 	ret void
+ }




From lattner at cs.uiuc.edu  Wed Mar 17 22:13:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 22:13:01 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403180412.WAA19618@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.12 -> 1.13

---
Log message:

Fix CodeExtractor/2004-03-17-OutputMismatch.ll



---
Diffs of the changes:  (+7 -3)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.12 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.13
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.12	Wed Mar 17 21:49:40 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Wed Mar 17 22:12:05 2004
@@ -347,6 +347,10 @@
   // just plain inputs for non-scalars
   std::vector params(inputs);
 
+  // Get an iterator to the first output argument.
+  Function::aiterator OutputArgBegin = newFunction->abegin();
+  std::advance(OutputArgBegin, inputs.size());
+
   for (unsigned i = 0, e = outputs.size(); i != e; ++i) {
     Value *Output = outputs[i];
     // Create allocas for scalar outputs
@@ -401,12 +405,12 @@
 
           // Restore values just before we exit
           // FIXME: Use a GetElementPtr to bunch the outputs in a struct
-          for (unsigned out = 0, e = outputs.size(); out != e; ++out)
+          Function::aiterator OAI = OutputArgBegin;
+          for (unsigned out = 0, e = outputs.size(); out != e; ++out, ++OAI)
             if (!DS ||
                 DS->dominates(cast(outputs[out])->getParent(),
                               TI->getParent()))
-              new StoreInst(outputs[out], getFunctionArg(newFunction, out),
-                            NTRet);
+              new StoreInst(outputs[out], OAI, NTRet);
         }
 
         // rewrite the original branch instruction with this new target




From lattner at cs.uiuc.edu  Wed Mar 17 23:29:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:29:02 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403180528.XAA26687@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.13 -> 1.14

---
Log message:

Seriously simplify and correct the PHI node handling code.


---
Diffs of the changes:  (+28 -162)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.13 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.14
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.13	Wed Mar 17 22:12:05 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Wed Mar 17 23:28:49 2004
@@ -30,20 +30,8 @@
 using namespace llvm;
 
 namespace {
-
-  /// getFunctionArg - Return a pointer to F's ARGNOth argument.
-  ///
-  Argument *getFunctionArg(Function *F, unsigned argno) {
-    Function::aiterator I = F->abegin();
-    std::advance(I, argno);
-    return I;
-  }
-
   class CodeExtractor {
     typedef std::vector Values;
-    typedef std::vector > PhiValChangesTy;
-    typedef std::map PhiVal2ArgTy;
-    PhiVal2ArgTy PhiVal2Arg;
     std::set BlocksToExtract;
     DominatorSet *DS;
   public:
@@ -56,15 +44,9 @@
                            BasicBlock *newHeader,
                            BasicBlock *newRootNode);
 
-    void processPhiNodeInputs(PHINode *Phi,
-                              Values &inputs,
-                              BasicBlock *newHeader,
-                              BasicBlock *newRootNode);
-
-    void rewritePhiNodes(Function *F, BasicBlock *newFuncRoot);
-
     Function *constructFunction(const Values &inputs,
                                 const Values &outputs,
+                                BasicBlock *header,
                                 BasicBlock *newRootNode, BasicBlock *newHeader,
                                 Function *oldFunction, Module *M);
 
@@ -78,95 +60,6 @@
   };
 }
 
-void CodeExtractor::processPhiNodeInputs(PHINode *Phi,
-                                         Values &inputs,
-                                         BasicBlock *codeReplacer,
-                                         BasicBlock *newFuncRoot) {
-  // Separate incoming values and BasicBlocks as internal/external. We ignore
-  // the case where both the value and BasicBlock are internal, because we don't
-  // need to do a thing.
-  std::vector EValEBB;
-  std::vector EValIBB;
-  std::vector IValEBB;
-
-  for (unsigned i = 0, e = Phi->getNumIncomingValues(); i != e; ++i) {
-    Value *phiVal = Phi->getIncomingValue(i);
-    if (Instruction *Inst = dyn_cast(phiVal)) {
-      if (BlocksToExtract.count(Inst->getParent())) {
-        if (!BlocksToExtract.count(Phi->getIncomingBlock(i)))
-          IValEBB.push_back(i);
-      } else {
-        if (BlocksToExtract.count(Phi->getIncomingBlock(i)))
-          EValIBB.push_back(i);
-        else
-          EValEBB.push_back(i);
-      }
-    } else if (Argument *Arg = dyn_cast(phiVal)) {
-      // arguments are external
-      if (BlocksToExtract.count(Phi->getIncomingBlock(i)))
-        EValIBB.push_back(i);
-      else
-        EValEBB.push_back(i);
-    } else {
-      // Globals/Constants are internal, but considered `external' if they are
-      // coming from an external block.
-      if (!BlocksToExtract.count(Phi->getIncomingBlock(i)))
-        EValEBB.push_back(i);
-    }
-  }
-
-  // Both value and block are external. Need to group all of these, have an
-  // external phi, pass the result as an argument, and have THIS phi use that
-  // result.
-  if (EValEBB.size() > 0) {
-    if (EValEBB.size() == 1) {
-      // Now if it's coming from the newFuncRoot, it's that funky input
-      unsigned phiIdx = EValEBB[0];
-      if (!isa(Phi->getIncomingValue(phiIdx))) {
-        PhiVal2Arg[Phi].push_back(std::make_pair(phiIdx, inputs.size()));
-        // We can just pass this value in as argument
-        inputs.push_back(Phi->getIncomingValue(phiIdx));
-      }
-      Phi->setIncomingBlock(phiIdx, newFuncRoot);
-    } else {
-      PHINode *externalPhi = new PHINode(Phi->getType(), "extPhi");
-      codeReplacer->getInstList().insert(codeReplacer->begin(), externalPhi);
-      for (std::vector::iterator i = EValEBB.begin(),
-             e = EValEBB.end(); i != e; ++i) {
-        externalPhi->addIncoming(Phi->getIncomingValue(*i),
-                                 Phi->getIncomingBlock(*i));
-
-        // We make these values invalid instead of deleting them because that
-        // would shift the indices of other values... The fixPhiNodes should
-        // clean these phi nodes up later.
-        Phi->setIncomingValue(*i, 0);
-        Phi->setIncomingBlock(*i, 0);
-      }
-      PhiVal2Arg[Phi].push_back(std::make_pair(Phi->getNumIncomingValues(),
-                                               inputs.size()));
-      // We can just pass this value in as argument
-      inputs.push_back(externalPhi);
-    }
-  }
-
-  // When the value is external, but block internal...  just pass it in as
-  // argument, no change to phi node
-  for (std::vector::iterator i = EValIBB.begin(),
-         e = EValIBB.end(); i != e; ++i) {
-    // rewrite the phi input node to be an argument
-    PhiVal2Arg[Phi].push_back(std::make_pair(*i, inputs.size()));
-    inputs.push_back(Phi->getIncomingValue(*i));
-  }
-
-  // Value internal, block external this can happen if we are extracting a part
-  // of a loop.
-  for (std::vector::iterator i = IValEBB.begin(),
-         e = IValEBB.end(); i != e; ++i) {
-    assert(0 && "Cannot (YET) handle internal values via external blocks");
-  }
-}
-
-
 void CodeExtractor::findInputsOutputs(Values &inputs, Values &outputs,
                                       BasicBlock *newHeader,
                                       BasicBlock *newRootNode) {
@@ -176,8 +69,13 @@
     for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I) {
       // If a used value is defined outside the region, it's an input.  If an
       // instruction is used outside the region, it's an output.
-      if (PHINode *Phi = dyn_cast(I)) {
-        processPhiNodeInputs(Phi, inputs, newHeader, newRootNode);
+      if (PHINode *PN = dyn_cast(I)) {
+        for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) {
+          Value *V = PN->getIncomingValue(i);
+          if (!BlocksToExtract.count(PN->getIncomingBlock(i)) &&
+              (isa(V) || isa(V)))
+            inputs.push_back(V);
+        }
       } else {
         // All other instructions go through the generic input finder
         // Loop over the operands of each instruction (inputs)
@@ -203,53 +101,18 @@
   } // for: basic blocks
 }
 
-void CodeExtractor::rewritePhiNodes(Function *F,
-                                    BasicBlock *newFuncRoot) {
-  // Write any changes that were saved before: use function arguments as inputs
-  for (PhiVal2ArgTy::iterator i = PhiVal2Arg.begin(), e = PhiVal2Arg.end();
-       i != e; ++i) {
-    PHINode *phi = i->first;
-    PhiValChangesTy &values = i->second;
-    for (unsigned cIdx = 0, ce = values.size(); cIdx != ce; ++cIdx)
-    {
-      unsigned phiValueIdx = values[cIdx].first, argNum = values[cIdx].second;
-      if (phiValueIdx < phi->getNumIncomingValues())
-        phi->setIncomingValue(phiValueIdx, getFunctionArg(F, argNum));
-      else
-        phi->addIncoming(getFunctionArg(F, argNum), newFuncRoot);
-    }
-  }
-
-  // Delete any invalid Phi node inputs that were marked as NULL previously
-  for (PhiVal2ArgTy::iterator i = PhiVal2Arg.begin(), e = PhiVal2Arg.end();
-       i != e; ++i) {
-    PHINode *phi = i->first;
-    for (unsigned idx = 0, end = phi->getNumIncomingValues(); idx != end; ++idx)
-    {
-      if (phi->getIncomingValue(idx) == 0 && phi->getIncomingBlock(idx) == 0) {
-        phi->removeIncomingValue(idx);
-        --idx;
-        --end;
-      }
-    }
-  }
-
-  // We are done with the saved values
-  PhiVal2Arg.clear();
-}
-
-
 /// constructFunction - make a function based on inputs and outputs, as follows:
 /// f(in0, ..., inN, out0, ..., outN)
 ///
 Function *CodeExtractor::constructFunction(const Values &inputs,
                                            const Values &outputs,
+                                           BasicBlock *header,
                                            BasicBlock *newRootNode,
                                            BasicBlock *newHeader,
-                                           Function *oldFunction, Module *M) {
+                                           Function *oldFunction,
+                                           Module *M) {
   DEBUG(std::cerr << "inputs: " << inputs.size() << "\n");
   DEBUG(std::cerr << "outputs: " << outputs.size() << "\n");
-  BasicBlock *header = *BlocksToExtract.begin();
 
   // This function returns unsigned, outputs will go back by reference.
   Type *retTy = Type::UShortTy;
@@ -308,17 +171,13 @@
   // within the new function. This must be done before we lose track of which
   // blocks were originally in the code region.
   std::vector Users(header->use_begin(), header->use_end());
-  for (std::vector::iterator i = Users.begin(), e = Users.end();
-       i != e; ++i) {
-    if (BranchInst *inst = dyn_cast(*i)) {
-      BasicBlock *BB = inst->getParent();
-      if (!BlocksToExtract.count(BB) && BB->getParent() == oldFunction) {
-        // The BasicBlock which contains the branch is not in the region
-        // modify the branch target to a new block
-        inst->replaceUsesOfWith(header, newHeader);
-      }
-    }
-  }
+  for (unsigned i = 0, e = Users.size(); i != e; ++i)
+    // The BasicBlock which contains the branch is not in the region
+    // modify the branch target to a new block
+    if (TerminatorInst *TI = dyn_cast(Users[i]))
+      if (!BlocksToExtract.count(TI->getParent()) &&
+          TI->getParent()->getParent() == oldFunction)
+        TI->replaceUsesOfWith(header, newHeader);
 
   return newFunction;
 }
@@ -495,15 +354,22 @@
 
   // Step 2: Construct new function based on inputs/outputs,
   // Add allocas for all defs
-  Function *newFunction = constructFunction(inputs, outputs, newFuncRoot, 
+  Function *newFunction = constructFunction(inputs, outputs, code[0],
+                                            newFuncRoot, 
                                             codeReplacer, oldFunction,
                                             oldFunction->getParent());
 
-  rewritePhiNodes(newFunction, newFuncRoot);
-
   emitCallAndSwitchStatement(newFunction, codeReplacer, inputs, outputs);
 
   moveCodeToFunction(newFunction);
+
+  // Loop over all of the PHI nodes in the entry block (code[0]), and change any
+  // references to the old incoming edge to be the new incoming edge.
+  for (BasicBlock::iterator I = code[0]->begin();
+       PHINode *PN = dyn_cast(I); ++I)
+    for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i)
+      if (!BlocksToExtract.count(PN->getIncomingBlock(i)))
+        PN->setIncomingBlock(i, newFuncRoot);
 
   DEBUG(if (verifyFunction(*newFunction)) abort());
   return newFunction;




From lattner at cs.uiuc.edu  Wed Mar 17 23:34:00 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:34:00 2004
Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-UpdatePHIsOutsideRegion.ll
Message-ID: <200403180533.XAA28686@zion.cs.uiuc.edu>


Changes in directory llvm/test/Regression/Transforms/CodeExtractor:

2004-03-17-UpdatePHIsOutsideRegion.ll added (r1.1)

---
Log message:

New testcase


---
Diffs of the changes:  (+23 -0)

Index: llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-UpdatePHIsOutsideRegion.ll
diff -c /dev/null llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-UpdatePHIsOutsideRegion.ll:1.1
*** /dev/null	Wed Mar 17 23:33:49 2004
--- llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-UpdatePHIsOutsideRegion.ll	Wed Mar 17 23:33:39 2004
***************
*** 0 ****
--- 1,23 ----
+ ; RUN: llvm-as < %s | opt -loop-extract -disable-output
+ 
+ 
+ void %maketree() {
+ entry:
+ 	br bool false, label %no_exit.1, label %loopexit.0
+ 
+ no_exit.1:		; preds = %entry, %expandbox.entry, %endif
+ 	br bool false, label %endif, label %expandbox.entry
+ 
+ expandbox.entry:		; preds = %no_exit.1
+ 	br bool false, label %loopexit.1, label %no_exit.1
+ 
+ endif:		; preds = %no_exit.1
+ 	br bool false, label %loopexit.1, label %no_exit.1
+ 
+ loopexit.1:		; preds = %expandbox.entry, %endif
+ 	%ic.i.0.0.4 = phi int [ 0, %expandbox.entry ], [ 0, %endif ]		;  [#uses=0]
+ 	ret void
+ 
+ loopexit.0:		; preds = %entry
+ 	ret void
+ }




From lattner at cs.uiuc.edu  Wed Mar 17 23:39:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:39:02 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403180538.XAA29486@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.14 -> 1.15

---
Log message:

Fix CodeExtractor/2004-03-17-UpdatePHIsOutsideRegion.ll


---
Diffs of the changes:  (+13 -0)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.14 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.15
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.14	Wed Mar 17 23:28:49 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Wed Mar 17 23:38:31 2004
@@ -371,6 +371,19 @@
       if (!BlocksToExtract.count(PN->getIncomingBlock(i)))
         PN->setIncomingBlock(i, newFuncRoot);
 
+  // Look at all successors of the codeReplacer block.  If any of these blocks
+  // had PHI nodes in them, we need to update the "from" block to be the code
+  // replacer, not the original block in the extracted region.
+  std::vector Succs(succ_begin(codeReplacer),
+                                 succ_end(codeReplacer));
+  for (unsigned i = 0, e = Succs.size(); i != e; ++i)
+    for (BasicBlock::iterator I = Succs[i]->begin();
+         PHINode *PN = dyn_cast(I); ++I)
+      for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i)
+        if (BlocksToExtract.count(PN->getIncomingBlock(i)))
+          PN->setIncomingBlock(i, codeReplacer);
+  
+
   DEBUG(if (verifyFunction(*newFunction)) abort());
   return newFunction;
 }




From lattner at cs.uiuc.edu  Wed Mar 17 23:44:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:44:01 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/IPO/LoopExtractor.cpp
Message-ID: <200403180543.XAA31513@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/IPO:

LoopExtractor.cpp updated: 1.8 -> 1.9

---
Log message:

Fix problem with PHI nodes having multiple predecessors from different 
exit nodes


---
Diffs of the changes:  (+2 -1)

Index: llvm/lib/Transforms/IPO/LoopExtractor.cpp
diff -u llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.8 llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.9
--- llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.8	Wed Mar 17 21:48:06 2004
+++ llvm/lib/Transforms/IPO/LoopExtractor.cpp	Wed Mar 17 23:43:18 2004
@@ -36,9 +36,10 @@
     virtual bool runOnFunction(Function &F);
     
     virtual void getAnalysisUsage(AnalysisUsage &AU) const {
+      AU.addRequiredID(BreakCriticalEdgesID);
+      AU.addRequiredID(LoopSimplifyID);
       AU.addRequired();
       AU.addRequired();
-      AU.addRequiredID(LoopSimplifyID);
     }
   };
 




From lattner at cs.uiuc.edu  Wed Mar 17 23:47:00 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:47:00 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/IPO/LoopExtractor.cpp
Message-ID: <200403180546.XAA32387@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/IPO:

LoopExtractor.cpp updated: 1.9 -> 1.10

---
Log message:

Add statistics to the loop extractor.  The loop extractor has successfully 
extracted all 63 loops for Olden/bh without crashing and without 
miscompiling the program!!!


---
Diffs of the changes:  (+6 -0)

Index: llvm/lib/Transforms/IPO/LoopExtractor.cpp
diff -u llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.9 llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.10
--- llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.9	Wed Mar 17 23:43:18 2004
+++ llvm/lib/Transforms/IPO/LoopExtractor.cpp	Wed Mar 17 23:46:10 2004
@@ -22,9 +22,12 @@
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Transforms/Scalar.h"
 #include "llvm/Transforms/Utils/FunctionUtils.h"
+#include "Support/Statistic.h"
 using namespace llvm;
 
 namespace {
+  Statistic<> NumExtracted("loop-extract", "Number of loops extracted");
+  
   // FIXME: This is not a function pass, but the PassManager doesn't allow
   // Module passes to require FunctionPasses, so we can't get loop info if we're
   // not a function pass.
@@ -72,6 +75,7 @@
       if (NumLoops == 0) return Changed;
       --NumLoops;
       Changed |= ExtractLoop(DS, *i) != 0;
+      ++NumExtracted;
     }
   } else {
     // Otherwise there is exactly one top-level loop.  If this function is more
@@ -99,6 +103,7 @@
       if (NumLoops == 0) return Changed;
       --NumLoops;
       Changed |= ExtractLoop(DS, TLL) != 0;
+      ++NumExtracted;
     } else {
       // Okay, this function is a minimal container around the specified loop.
       // If we extract the loop, we will continue to just keep extracting it
@@ -108,6 +113,7 @@
         if (NumLoops == 0) return Changed;
         --NumLoops;
         Changed |= ExtractLoop(DS, *i) != 0;
+        ++NumExtracted;
       }
     }
   }




From lattner at cs.uiuc.edu  Wed Mar 17 23:56:00 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:56:00 2004
Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-MissedLiveIns.ll
Message-ID: <200403180555.XAA00859@zion.cs.uiuc.edu>


Changes in directory llvm/test/Regression/Transforms/CodeExtractor:

2004-03-17-MissedLiveIns.ll added (r1.1)

---
Log message:

New testcase, reduced from 256.bzip2


---
Diffs of the changes:  (+47 -0)

Index: llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-MissedLiveIns.ll
diff -c /dev/null llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-MissedLiveIns.ll:1.1
*** /dev/null	Wed Mar 17 23:55:39 2004
--- llvm/test/Regression/Transforms/CodeExtractor/2004-03-17-MissedLiveIns.ll	Wed Mar 17 23:55:29 2004
***************
*** 0 ****
--- 1,47 ----
+ ; RUN: llvm-as < %s | opt -loop-extract -disable-output
+ 
+ void %sendMTFValues() {
+ entry:
+ 	br bool false, label %then.1, label %endif.1
+ 
+ then.1:		; preds = %entry
+ 	br bool false, label %loopentry.6.preheader, label %else.0
+ 
+ endif.1:		; preds = %entry
+ 	ret void
+ 
+ else.0:		; preds = %then.1
+ 	ret void
+ 
+ loopentry.6.preheader:		; preds = %then.1
+ 	br bool false, label %endif.7.preheader, label %loopexit.9
+ 
+ endif.7.preheader:		; preds = %loopentry.6.preheader
+ 	%tmp.183 = add int 0, -1		;  [#uses=1]
+ 	br label %endif.7
+ 
+ endif.7:		; preds = %endif.7.preheader, %loopexit.15
+ 	br bool false, label %loopentry.10, label %loopentry.12
+ 
+ loopentry.10:		; preds = %endif.7
+ 	br label %loopentry.12
+ 
+ loopentry.12:		; preds = %endif.7, %loopentry.10
+ 	%ge.2.1 = phi int [ 0, %loopentry.10 ], [ %tmp.183, %endif.7 ]		;  [#uses=0]
+ 	br bool false, label %loopexit.14, label %no_exit.11
+ 
+ no_exit.11:		; preds = %loopentry.12
+ 	ret void
+ 
+ loopexit.14:		; preds = %loopentry.12
+ 	br bool false, label %loopexit.15, label %no_exit.14
+ 
+ no_exit.14:		; preds = %loopexit.14
+ 	ret void
+ 
+ loopexit.15:		; preds = %loopexit.14
+ 	br bool false, label %endif.7, label %loopexit.9
+ 
+ loopexit.9:		; preds = %loopentry.6.preheader, %loopexit.15
+ 	ret void
+ }




From lattner at cs.uiuc.edu  Wed Mar 17 23:57:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Wed Mar 17 23:57:01 2004
Subject: [llvm-commits] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403180556.XAA00876@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.15 -> 1.16

---
Log message:

Fix bug: CodeExtractor/2004-03-17-MissedLiveIns.ll
With this fix we now successfully extract all 149 loops from 256.bzip2 without
crashing or miscompiling the program!


---
Diffs of the changes:  (+5 -0)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.15 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.16
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.15	Wed Mar 17 23:38:31 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Wed Mar 17 23:56:32 2004
@@ -75,6 +75,11 @@
           if (!BlocksToExtract.count(PN->getIncomingBlock(i)) &&
               (isa(V) || isa(V)))
             inputs.push_back(V);
+          else if (Instruction *opI = dyn_cast(V)) {
+            if (!BlocksToExtract.count(opI->getParent()))
+              inputs.push_back(opI);
+          } else if (isa(V))
+            inputs.push_back(V);
         }
       } else {
         // All other instructions go through the generic input finder




From lattner at cs.uiuc.edu  Thu Mar 18 00:31:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu Mar 18 00:31:02 2004
Subject: [llvm-commits] CVS: llvm/lib/Target/X86/InstSelectSimple.cpp
Message-ID: <200403180630.AAA05690@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Target/X86:

InstSelectSimple.cpp updated: 1.194 -> 1.195

---
Log message:

Fix a really nasty bug that was breaking ijpeg in LLC mode.  We were incorrectly
folding load instructions into other instructions across free instruction 
boundaries.  Perhaps this will also fix the other strange failures?


---
Diffs of the changes:  (+2 -0)

Index: llvm/lib/Target/X86/InstSelectSimple.cpp
diff -u llvm/lib/Target/X86/InstSelectSimple.cpp:1.194 llvm/lib/Target/X86/InstSelectSimple.cpp:1.195
--- llvm/lib/Target/X86/InstSelectSimple.cpp:1.194	Fri Mar 12 18:24:52 2004
+++ llvm/lib/Target/X86/InstSelectSimple.cpp	Thu Mar 18 00:29:54 2004
@@ -1422,6 +1422,8 @@
   // really use alias analysis here, but for now we just do something simple.
   for (++It; It != BasicBlock::iterator(&User); ++It) {
     switch (It->getOpcode()) {
+    case Instruction::Malloc:
+    case Instruction::Free:
     case Instruction::Store:
     case Instruction::Call:
     case Instruction::Invoke:




From lattner at cs.uiuc.edu  Thu Mar 18 00:43:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu Mar 18 00:43:02 2004
Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/CodeExtractor/2004-03-18-InvokeHandling.ll
Message-ID: <200403180642.AAA05832@zion.cs.uiuc.edu>


Changes in directory llvm/test/Regression/Transforms/CodeExtractor:

2004-03-18-InvokeHandling.ll added (r1.1)

---
Log message:

This is the last remaining bug that I know of in the loop extractor.  The loop
extractor has extracted hundreds of loops from the SPEC benchmarks without crashing
and without misoptimizing the programs.

This testcase could be reduced substantially more by hand, but I don't have time
to work on it right now.


---
Diffs of the changes:  (+196 -0)

Index: llvm/test/Regression/Transforms/CodeExtractor/2004-03-18-InvokeHandling.ll
diff -c /dev/null llvm/test/Regression/Transforms/CodeExtractor/2004-03-18-InvokeHandling.ll:1.1
*** /dev/null	Thu Mar 18 00:42:09 2004
--- llvm/test/Regression/Transforms/CodeExtractor/2004-03-18-InvokeHandling.ll	Thu Mar 18 00:41:59 2004
***************
*** 0 ****
--- 1,196 ----
+ ; RUN: llvm-as < %s | opt -loop-extract -disable-output
+ 
+ implementation   ; Functions:
+ 
+ declare int %_IO_getc()
+ 
+ declare void %__errno_location()
+ 
+ void %yylex() {
+ entry:
+ 	switch uint 0, label %label.126 [
+ 		 uint 0, label %return
+ 		 uint 61, label %combine
+ 		 uint 33, label %combine
+ 		 uint 94, label %combine
+ 		 uint 37, label %combine
+ 		 uint 47, label %combine
+ 		 uint 42, label %combine
+ 		 uint 62, label %combine
+ 		 uint 60, label %combine
+ 		 uint 58, label %combine
+ 		 uint 124, label %combine
+ 		 uint 38, label %combine
+ 		 uint 45, label %combine
+ 		 uint 43, label %combine
+ 		 uint 34, label %string_constant
+ 		 uint 39, label %char_constant
+ 		 uint 46, label %loopexit.2
+ 		 uint 57, label %loopexit.2
+ 		 uint 56, label %loopexit.2
+ 		 uint 55, label %loopexit.2
+ 		 uint 54, label %loopexit.2
+ 		 uint 53, label %loopexit.2
+ 		 uint 52, label %loopexit.2
+ 		 uint 51, label %loopexit.2
+ 		 uint 50, label %loopexit.2
+ 		 uint 49, label %loopexit.2
+ 		 uint 48, label %loopexit.2
+ 		 uint 95, label %letter
+ 		 uint 122, label %letter
+ 		 uint 121, label %letter
+ 		 uint 120, label %letter
+ 		 uint 119, label %letter
+ 		 uint 118, label %letter
+ 		 uint 117, label %letter
+ 		 uint 116, label %letter
+ 		 uint 115, label %letter
+ 		 uint 114, label %letter
+ 		 uint 113, label %letter
+ 		 uint 112, label %letter
+ 		 uint 111, label %letter
+ 		 uint 110, label %letter
+ 		 uint 109, label %letter
+ 		 uint 108, label %letter
+ 		 uint 107, label %letter
+ 		 uint 106, label %letter
+ 		 uint 105, label %letter
+ 		 uint 104, label %letter
+ 		 uint 103, label %letter
+ 		 uint 102, label %letter
+ 		 uint 101, label %letter
+ 		 uint 100, label %letter
+ 		 uint 99, label %letter
+ 		 uint 98, label %letter
+ 		 uint 97, label %letter
+ 		 uint 90, label %letter
+ 		 uint 89, label %letter
+ 		 uint 88, label %letter
+ 		 uint 87, label %letter
+ 		 uint 86, label %letter
+ 		 uint 85, label %letter
+ 		 uint 84, label %letter
+ 		 uint 83, label %letter
+ 		 uint 82, label %letter
+ 		 uint 81, label %letter
+ 		 uint 80, label %letter
+ 		 uint 79, label %letter
+ 		 uint 78, label %letter
+ 		 uint 77, label %letter
+ 		 uint 75, label %letter
+ 		 uint 74, label %letter
+ 		 uint 73, label %letter
+ 		 uint 72, label %letter
+ 		 uint 71, label %letter
+ 		 uint 70, label %letter
+ 		 uint 69, label %letter
+ 		 uint 68, label %letter
+ 		 uint 67, label %letter
+ 		 uint 66, label %letter
+ 		 uint 65, label %letter
+ 		 uint 64, label %label.13
+ 		 uint 76, label %label.12
+ 		 uint 36, label %label.11
+ 		 uint 4294967295, label %label.10
+ 	]
+ 
+ label.10:		; preds = %entry
+ 	ret void
+ 
+ label.11:		; preds = %entry
+ 	ret void
+ 
+ label.12:		; preds = %entry
+ 	ret void
+ 
+ label.13:		; preds = %entry
+ 	ret void
+ 
+ letter:		; preds = %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry
+ 	ret void
+ 
+ loopexit.2:		; preds = %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry
+ 	switch int 0, label %shortcirc_next.14 [
+ 		 int 48, label %then.20
+ 		 int 46, label %endif.38
+ 	]
+ 
+ then.20:		; preds = %loopexit.2
+ 	switch int 0, label %else.4 [
+ 		 int 120, label %then.21
+ 		 int 88, label %then.21
+ 	]
+ 
+ then.21:		; preds = %then.20, %then.20
+ 	ret void
+ 
+ else.4:		; preds = %then.20
+ 	ret void
+ 
+ shortcirc_next.14:		; preds = %loopexit.2
+ 	ret void
+ 
+ endif.38:		; preds = %loopexit.2
+ 	br bool false, label %then.40, label %then.39
+ 
+ then.39:		; preds = %endif.38
+ 	ret void
+ 
+ then.40:		; preds = %endif.38
+ 	invoke void %__errno_location( )
+ 			to label %switchexit.2 unwind label %LongJmpBlkPre
+ 
+ loopentry.6:		; preds = %endif.52
+ 	switch uint 0, label %switchexit.2 [
+ 		 uint 73, label %label.82
+ 		 uint 105, label %label.82
+ 		 uint 76, label %label.80
+ 		 uint 108, label %label.80
+ 		 uint 70, label %label.78
+ 		 uint 102, label %label.78
+ 	]
+ 
+ label.78:		; preds = %loopentry.6, %loopentry.6
+ 	ret void
+ 
+ label.80:		; preds = %loopentry.6, %loopentry.6
+ 	ret void
+ 
+ label.82:		; preds = %loopentry.6, %loopentry.6
+ 	%c.0.15.5 = phi int [ %tmp.79417, %loopentry.6 ], [ %tmp.79417, %loopentry.6 ]		;  [#uses=0]
+ 	ret void
+ 
+ switchexit.2:		; preds = %then.40, %loopentry.6
+ 	br bool false, label %endif.51, label %loopexit.6
+ 
+ endif.51:		; preds = %switchexit.2
+ 	br bool false, label %endif.52, label %then.52
+ 
+ then.52:		; preds = %endif.51
+ 	ret void
+ 
+ endif.52:		; preds = %endif.51
+ 	%tmp.79417 = invoke int %_IO_getc( )
+ 			to label %loopentry.6 unwind label %LongJmpBlkPre		;  [#uses=2]
+ 
+ loopexit.6:		; preds = %switchexit.2
+ 	ret void
+ 
+ char_constant:		; preds = %entry
+ 	ret void
+ 
+ string_constant:		; preds = %entry
+ 	ret void
+ 
+ combine:		; preds = %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry, %entry
+ 	ret void
+ 
+ label.126:		; preds = %entry
+ 	ret void
+ 
+ return:		; preds = %entry
+ 	ret void
+ 
+ LongJmpBlkPre:		; preds = %then.40, %endif.52
+ 	ret void
+ }




From lattner at cs.uiuc.edu  Thu Mar 18 09:00:03 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu Mar 18 09:00:03 2004
Subject: [llvm-commits] CVS: llvm/docs/ProgrammersManual.html
Message-ID: <200403181459.IAA14555@zion.cs.uiuc.edu>


Changes in directory llvm/docs:

ProgrammersManual.html updated: 1.54 -> 1.55

---
Log message:

Fix a minor wording bug in the manual


---
Diffs of the changes:  (+3 -2)

Index: llvm/docs/ProgrammersManual.html
diff -u llvm/docs/ProgrammersManual.html:1.54 llvm/docs/ProgrammersManual.html:1.55
--- llvm/docs/ProgrammersManual.html:1.54	Sun Feb  8 22:14:46 2004
+++ llvm/docs/ProgrammersManual.html	Thu Mar 18 08:58:55 2004
@@ -974,7 +974,8 @@
 
        One important aspect of LLVM is that there is no distinction between an SSA
 variable and the operation that produces it.  Because of this, any reference to
 the value produced by an instruction (or the value available as an incoming
-argument, for example) is represented as a direct pointer to the class that
+argument, for example) is represented as a direct pointer to the instance of
+the class that
 represents this value.  Although this may take some getting used to, it
 simplifies the representation and makes it easier to manipulate.
        
 
@@ -1829,7 +1830,7 @@
   Dinakar Dhurjati and
   Chris Lattner
        
   The LLVM Compiler Infrastructure
        
-  Last modified: $Date: 2004/02/09 04:14:46 $
+  Last modified: $Date: 2004/03/18 14:58:55 $
 
 
 




From criswell at cs.uiuc.edu  Thu Mar 18 09:06:03 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 09:06:03 2004
Subject: [llvm-commits] [release_12] CVS: llvm/lib/Analysis/AliasSetTracker.cpp
Message-ID: <200403181505.JAA21499@choi.cs.uiuc.edu>


Changes in directory llvm/lib/Analysis:

AliasSetTracker.cpp updated: 1.13 -> 1.13.2.1

---
Log message:

cvs slurp revision 1.14 from mainline.



---
Diffs of the changes:  (+1 -1)

Index: llvm/lib/Analysis/AliasSetTracker.cpp
diff -u llvm/lib/Analysis/AliasSetTracker.cpp:1.13 llvm/lib/Analysis/AliasSetTracker.cpp:1.13.2.1
--- llvm/lib/Analysis/AliasSetTracker.cpp:1.13	Mon Mar 15 00:28:07 2004
+++ llvm/lib/Analysis/AliasSetTracker.cpp	Thu Mar 18 09:04:57 2004
@@ -101,7 +101,7 @@
       return;
     else if (AA.onlyReadsMemory(F)) {
       AliasTy = MayAlias;
-      AccessTy = Refs;
+      AccessTy |= Refs;
       return;
     }
   }




From criswell at cs.uiuc.edu  Thu Mar 18 09:32:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 09:32:01 2004
Subject: [llvm-commits] [release_12] CVS: llvm/test/QMTest/expectations.darwin.qmr
Message-ID: <200403181531.JAA03647@choi.cs.uiuc.edu>


Changes in directory llvm/test/QMTest:

expectations.darwin.qmr added (r1.1.2.1)

---
Log message:

Added a new results file for Darwin since it has been officially supported
since LLVM 1.1.



---
Diffs of the changes:  (+6 -0)

Index: llvm/test/QMTest/expectations.darwin.qmr
diff -c /dev/null llvm/test/QMTest/expectations.darwin.qmr:1.1.2.1
*** /dev/null	Thu Mar 18 09:31:33 2004
--- llvm/test/QMTest/expectations.darwin.qmr	Thu Mar 18 09:31:22 2004
***************
*** 0 ****
--- 1,15 ----
+ (cqm.test.result
+ Result
+ qoq}q(U
_Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U_Result__idq	U0Regression.Assembler.2002-08-16-ConstExprInlinedq
+ U_Result__contextq(cqm.test.context
+ Context
+ qo}q
(U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h	U(Regression.Transforms.PruneEH.simpletestqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	U/Regression.CBackend.2002-08-19-HardConstantExprqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	URegression.Jello.test-shiftqh(ho}q(h}h}ubub.(hoq}q(hhhUFAILqh}h	U.Regression.Transforms.CorrelatedExprs.looptestqh(ho}q (h}h}ubub.(hoq!}q"(hhhhh}h	U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h(ho}q$(h}h}ubub.(hoq%}q&(hhhhh}h	U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h(ho}q((h}h}ubub.(hoq)}q*(hhhhh}h	U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h(ho}q,(h}h}ubub.(hoq-}q.(hhhhh}h	U2Regression.Transforms.FunctionResolve.retmismatch1q/h(ho}q0(h}h}ubub.(hoq1}q2(hhhhh}h	U>Regression.Transforms.LevelRaise.2002-05-02-BadCastEliminationq3h(ho}q4(h}h}ubub.(hoq5}q6(hhhhh}h	U8Regression.Transforms.ADCE.2003-01-22!
 -PredecessorProblemq7h(ho}q8(h}h}ubub.(hoq9}q:(hhhhh}h	U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h(ho}q<(h}h}ubub.(hoq=}q>(hhhhh}h	U Regression.Reoptimizer.ticm.ticmq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U1Regression.CFrontend.2002-03-12-StructInitializerqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U-Regression.C++Frontend.2003-08-28-SaveExprBugqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U"Regression.Jello.2003-06-05-PHIBugqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	U)Regression.Transforms.Reassociate.subtestq_h(ho}q`(h}h}ubub.(hoqa}qb(h!
 hhhh}h	U)Regression.Linker.2002-08-20-ConstantExprqch(ho}qd(h}h
}ubub.(hoqe}qf(hhhhh}h	U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U3Regression.Transforms.PiNodeInserter.substitutetestqoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U$Regression.Jello.2003-01-04-LoopTestqwh(ho}qx(h}h}ubub.(hoqy}qz(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2q{h(ho}q|(h}h}ubub.(hoq}}q~(hhhhh}h	U)Regression.CFrontend.2002-07-14-MiscTestsqh(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U


Changes in directory llvm/test/QMTest:

expectations.darwin.qmr updated: 1.1.2.1 -> 1.1.2.2
expectations.linux.qmr updated: 1.8 -> 1.8.2.1
expectations.sunos.qmr updated: 1.8 -> 1.8.2.1

---
Log message:

Updated expectations to match current results.



---
Diffs of the changes:  (+3 -3)

Index: llvm/test/QMTest/expectations.darwin.qmr
diff -u llvm/test/QMTest/expectations.darwin.qmr:1.1.2.1 llvm/test/QMTest/expectations.darwin.qmr:1.1.2.2
--- llvm/test/QMTest/expectations.darwin.qmr:1.1.2.1	Thu Mar 18 09:31:22 2004
+++ llvm/test/QMTest/expectations.darwin.qmr	Thu Mar 18 09:37:22 2004
@@ -3,13 +3,13 @@
 qoq}q(U
_Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U_Result__idq	U0Regression.Assembler.2002-08-16-ConstExprInlinedq
 U_Result__contextq(cqm.test.context
 Context
-qo}q
(U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h	U(Regression.Transforms.PruneEH.simpletestqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	U/Regression.CBackend.2002-08-19-HardConstantExprqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	URegression.Jello.test-shiftqh(ho}q(h}h}ubub.(hoq}q(hhhUFAILqh}h	U.Regression.Transforms.CorrelatedExprs.looptestqh(ho}q (h}h}ubub.(hoq!}q"(hhhhh}h	U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h(ho}q$(h}h}ubub.(hoq%}q&(hhhhh}h	U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h(ho}q((h}h}ubub.(hoq)}q*(hhhhh}h	U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h(ho}q,(h}h}ubub.(hoq-}q.(hhhhh}h	U2Regression.Transforms.FunctionResolve.retmismatch1q/h(ho}q0(h}h}ubub.(hoq1}q2(hhhhh}h	U>Regression.Transforms.LevelRaise.2002-05-02-BadCastEliminationq3h(ho}q4(h}h}ubub.(hoq5}q6(hhhhh}h	U8Regression.Transforms.ADCE.2003-01-22-!
 PredecessorProblemq7h(ho}q8(h}h}ubub.(hoq9}q:(hhhhh}h	U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h(ho}q<(h}h}ubub.(hoq=}q>(hhhhh}h	U Regression.Reoptimizer.ticm.ticmq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U1Regression.CFrontend.2002-03-12-StructInitializerqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U-Regression.C++Frontend.2003-08-28-SaveExprBugqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U"Regression.Jello.2003-06-05-PHIBugqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	U)Regression.Transforms.Reassociate.subtestq_h(ho}q`(h}h}ubub.(hoqa}qb(hh!
 hhh}h	U)Regression.Linker.2002-08-20-ConstantExprqch(ho}qd(h}h
}ubub.(hoqe}qf(hhhhh}h	U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U3Regression.Transforms.PiNodeInserter.substitutetestqoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U$Regression.Jello.2003-01-04-LoopTestqwh(ho}qx(h}h}ubub.(hoqy}qz(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2q{h(ho}q|(h}h}ubub.(hoq}}q~(hhhhh}h	U)Regression.CFrontend.2002-07-14-MiscTestsqh(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U(hhhhh}h	U Regression.Reoptimizer.ticm.ticmq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U)Regression.Transforms.Reassociate.subtestqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemq_!
 h(ho}q`(h}h}ubub.(hoqa}qb(hhhhh}h	U3Regression.Transforms.Pi
NodeInserter.substitutetestqch(ho}qd(h}h}ubub.(hoqe}qf(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U-Regression.CFrontend.2002-02-18-64bitConstantqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U(Regression.Reoptimizer.BinInterface.testqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	URegression.Transforms.CorrelatedExprs.2002-10-08-DominatorTestq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	URegression.Linker.testlink2q?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U(Regression.Transforms.GCSE.RLE-Eliminateq?h(ho}q?(h}h}ubu!
 b.(hoq?}q?(hhhhh}h	U4Regression.C++Frontend.2003-09-30-NestedFunctionDeclq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U=Regression.Transforms.CorrelatedExprs.2002-09-23-PHIUpdateBugq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U7Regression.Transforms.LowerSwitch.2003-05-01-PHIProblemq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U2Regression.Transforms.ADCE.2003-09-15-InfLoopCrashq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U*Regression.Transforms.DSAnalysis.recursionq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U)Regression.Jello.2003-01-15-AlignmentTestq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhUFAILq?h}h	UFeature.mc.simplecalltestq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U*Regression.CFrontend.2002-04-07-SwitchStmtq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U!Regression.Jello.2003-01-10-FUCOMq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U(Regression.CFrontend.2003-08-21-StmtExprq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhUPASSq?h}h	U*Regression.Transforms.Scalar!
 Repl.basictestq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhh"h}h	U6Regressi
on.Transforms.LevelRaise.2002-02-11-ArrayShapeq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U1Regression.Assembler.2003-03-03-DuplicateConstantq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U.Regression.Transforms.ModuloSched.arith-simpleq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U%Regression.Transforms.InstCombine.andq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U)Regression.Other.2002-08-02-DomSetProblemq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U6Regression.Assembler.2002-07-25-ParserAssertionFailureq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U6Regression.Transforms.LevelRaise.2002-03-20-BadCodegenq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U6Regression.Transforms.ADCE.2002-07-17-AssertionFailureq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhUFAILq?h}h	UFeature.mc.recursivetypeq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U$Regression.Transforms.InstCombine.orq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U Regression.Verifier.AmbiguousPhiq?h(ho}q?(h}h}ubub.(hoq?}!
 q?(hhhhh}h	U'Regression.Analysis.DSGraph.constantizeq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U6Regression.Transforms.GlobalDCE.2002-08-17-FunctionDGEq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U4Regression.Transforms.SimplifyCFG.2002-06-24-PHINodeq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U(Regression.Linker.2003-05-15-TypeProblemq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U#Regression.Transforms.SCCP.sccptestq?h(ho}q?(h}h}ubub.(hoq?}q?(hhhhh}h	U2Regression.Transforms.FunctionResolve.retmismatch3q?h(ho}q?(h}h}ubub.(hor+++++++++	\ No newline at end of file


Index: llvm/test/QMTest/expectations.linux.qmr
diff -u llvm/test/QMTest/expectations.linux.qmr:1.8 llvm/test/QMTest/expectations.linux.qmr:1.8.2.1
--- llvm/test/QMTest/expectations.linux.qmr:1.8	Tue Mar 16 19:30:55 2004
+++ llvm/test/QMTest/expectations.linux.qmr	Thu Mar 18 09:37:22 2004
@@ -3,13 +3,13 @@
 qoq}q(U
_Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U_Result__idq	U0Regression.Assembler.2002-08-16-ConstExprInlinedq
 U_Result__contextq(cqm.test.context
 Context
-qo}q
(U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h	U(Regression.Transforms.PruneEH.simpletestqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	U/Regression.CBackend.2002-08-19-HardConstantExprqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	URegression.Jello.test-shiftqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	U9Regression.Transforms.Mem2Reg.2003-10-05-DeadPHIInsertionqh(ho}q(h}h}ubub.(hoq }q!(hhhUFAILq"h}h	U.Regression.Transforms.CorrelatedExprs.looptestq#h(ho}q$(h}h}ubub.(hoq%}q&(hhhhh}h	U-Regression.Linker.2003-08-23-GlobalVarLinkingq'h(ho}q((h}h}ubub.(hoq)}q*(hhhhh}h	U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq+h(ho}q,(h}h}ubub.(hoq-}q.(hhhh"h}h	U,Regression.CFrontend.2003-02-12-NonlocalGotoq/h(ho}q0(h}h}ubub.(hoq1}q2(hhhhh}h	U2Regression.Transforms.FunctionResolve.retmismatch1q3h(ho}q4(h}h}ubub.(hoq5}q6(hhhhh}h	U8Regression.Transforms.ADCE.2003-01-22-Prede!
 cessorProblemq7h(ho}q8(h}h}ubub.(hoq9}q:(hhhhh}h	U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq;h(ho}q<(h}h}ubub.(hoq=}q>(hhhhh}h	U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U)Regression.Transforms.Reassociate.subtestqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-!
 07-DominatorProblemq_h(ho}q`(h}h}ubub.(hoqa}qb(hhhhh}h	U3Reg
ression.Transforms.PiNodeInserter.substitutetestqch(ho}qd(h}h}ubub.(hoqe}qf(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U-Regression.CFrontend.2002-02-18-64bitConstantqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U(Regression.Reoptimizer.BinInterface.testqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U(hhhhh}h	U Regression.Reoptimizer.ticm.ticmq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U-Regression.C++Frontend.2003-08-28-SaveExprBugqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U"Regression.Jello.2003-06-05-PHIBugqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U)Regression.Transforms.Reassociate.subtestq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprq_h(ho}q`(h}h}ubub.(hoqa}qb(hhhhh}h	U=Regressi!
 on.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqch(ho}qd(h}h
}ubub.(hoqe}qf(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U3Regression.Transforms.PiNodeInserter.substitutetestqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U$Regression.Jello.2003-01-04-LoopTestqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qwh(ho}qx(h}h}ubub.(hoqy}qz(hhhhh}h	U)Regression.CFrontend.2002-07-14-MiscTestsq{h(ho}q|(h}h}ubub.(hoq}}q~(hhhhh}h	U(hhhhh}h	U5Regression.CFrontend.2003-07-22-ArrayAccessTypeSafetyq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U)Regression.Transforms.Reassociate.subtestqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-!
 07-DominatorProblemq_h(ho}q`(h}h}ubub.(hoqa}qb(hhhhh}h	U3Reg
ression.Transforms.PiNodeInserter.substitutetestqch(ho}qd(h}h}ubub.(hoqe}qf(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U-Regression.CFrontend.2002-02-18-64bitConstantqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U(Regression.Reoptimizer.BinInterface.testqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U(hhhhh}h	U Regression.Reoptimizer.ticm.ticmq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U-Regression.C++Frontend.2003-08-28-SaveExprBugqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U"Regression.Jello.2003-06-05-PHIBugqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U)Regression.Transforms.Reassociate.subtestq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprq_h(ho}q`(h}h}ubub.(hoqa}qb(hhhhh}h	!
 U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqch(h
o}qd(h}h}ubub.(hoqe}qf(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U3Regression.Transforms.PiNodeInserter.substitutetestqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U$Regression.Jello.2003-01-04-LoopTestqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qwh(ho}qx(h}h}ubub.(hoqy}qz(hhhhh}h	U)Regression.CFrontend.2002-07-14-MiscTestsq{h(ho}q|(h}h}ubub.(hoq}}q~(hhhhh}h	U


Changes in directory llvm/test/QMTest:

expectations.sunos.qmr updated: 1.8.2.1 -> 1.8.2.2

---
Log message:

Regression.Transforms.CodeExtractor.2004-03-14-DominanceProblem is now
expected to pass.



---
Diffs of the changes:  (+1 -1)

Index: llvm/test/QMTest/expectations.sunos.qmr
diff -u llvm/test/QMTest/expectations.sunos.qmr:1.8.2.1 llvm/test/QMTest/expectations.sunos.qmr:1.8.2.2
--- llvm/test/QMTest/expectations.sunos.qmr:1.8.2.1	Thu Mar 18 09:37:22 2004
+++ llvm/test/QMTest/expectations.sunos.qmr	Thu Mar 18 10:32:35 2004
@@ -3,13 +3,13 @@
 qoq}q(U
_Result__kindqUtestqU_Result__outcomeqUPASSqU_Result__annotationsq}U_Result__idq	U0Regression.Assembler.2002-08-16-ConstExprInlinedq
 U_Result__contextq(cqm.test.context
 Context
-qo}q
(U_Context__propertiesq}U_Context__temporariesq}ubub.(hoq}q(hhhhh}h	U(Regression.Transforms.PruneEH.simpletestqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	U/Regression.CBackend.2002-08-19-HardConstantExprqh(ho}q(h}h}ubub.(hoq}q(hhhhh}h	URegression.Jello.test-shiftqh(ho}q(h}h}ubub.(hoq}q(hhhUFAILqh}h	U.Regression.Transforms.CorrelatedExprs.looptestqh(ho}q (h}h}ubub.(hoq!}q"(hhhhh}h	U-Regression.Linker.2003-08-23-GlobalVarLinkingq#h(ho}q$(h}h}ubub.(hoq%}q&(hhhhh}h	U?Regression.Transforms.Inline.2003-09-22-PHINodesInExceptionDestq'h(ho}q((h}h}ubub.(hoq)}q*(hhhhh}h	U,Regression.CFrontend.2003-02-12-NonlocalGotoq+h(ho}q,(h}h}ubub.(hoq-}q.(hhhhh}h	U(hhhhh}h	U Regression.Reoptimizer.ticm.ticmq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U-Regression.C++Frontend.2003-08-28-SaveExprBugqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U"Regression.Jello.2003-06-05-PHIBugqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U)Regression.Transforms.Reassociate.subtestq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprq_h(ho}q`(h}h}ubub.(hoqa}qb(hhhhh}h	!
 U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveqch(h
o}qd(h}h}ubub.(hoqe}qf(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2002-10-07-DominatorProblemqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U3Regression.Transforms.PiNodeInserter.substitutetestqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U$Regression.Jello.2003-01-04-LoopTestqsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qwh(ho}qx(h}h}ubub.(hoqy}qz(hhhhh}h	U)Regression.CFrontend.2002-07-14-MiscTestsq{h(ho}q|(h}h}ubub.(hoq}}q~(hhhhh}h	U(hhhhh}h	U=Regression.Transforms.LevelRaise.2002-10-08-VarArgCallInfLoopq?h(ho}q@(h}h}ubub.(hoqA}qB(hhhhh}h	U Regression.Reoptimizer.ticm.ticmqCh(ho}qD(h}h}ubub.(hoqE}qF(hhhhh}h	U8Regression.C++Frontend.2003-09-29-ArgumentNumberMismatchqGh(ho}qH(h}h}ubub.(hoqI}qJ(hhhhh}h	U+Regression.CFrontend.2002-09-19-StarInLabelqKh(ho}qL(h}h}ubub.(hoqM}qN(hhhhh}h	U.Regression.CFrontend.2003-08-23-LocalUnionTestqOh(ho}qP(h}h}ubub.(hoqQ}qR(hhhhh}h	U/Regression.Linker.2003-04-26-NullPtrLinkProblemqSh(ho}qT(h}h}ubub.(hoqU}qV(hhhhh}h	U)Regression.Transforms.Reassociate.subtestqWh(ho}qX(h}h}ubub.(hoqY}qZ(hhhhh}h	U)Regression.Linker.2002-08-20-ConstantExprq[h(ho}q\(h}h}ubub.(hoq]}q^(hhhhh}h	U=Regression.Transforms.Reassociate.2002-05-15-AgressiveSubMoveq_h(ho}q`(h}h!
 }ubub.(hoqa}qb(hhhhh}h	UARegression.Transforms.CorrelatedExprs.2
002-10-07-DominatorProblemqch(ho}qd(h}h}ubub.(hoqe}qf(hhhhh}h	U3Regression.Transforms.PiNodeInserter.substitutetestqgh(ho}qh(h}h}ubub.(hoqi}qj(hhhhh}h	U4Regression.Transforms.SCCP.2003-08-26-InvokeHandlingqkh(ho}ql(h}h}ubub.(hoqm}qn(hhhhh}h	U-Regression.CFrontend.2002-02-18-64bitConstantqoh(ho}qp(h}h}ubub.(hoqq}qr(hhhhh}h	U1Regression.Assembler.2002-04-04-PureVirtMethCall2qsh(ho}qt(h}h}ubub.(hoqu}qv(hhhhh}h	U(Regression.Reoptimizer.BinInterface.testqwh(ho}qx(h}h}ubub.(hoqy}qz(hhhhh}h	U


Changes in directory llvm/test:

Makefile updated: 1.52 -> 1.52.6.1

---
Log message:

Gave Darwin its own expectations file.



---
Diffs of the changes:  (+4 -0)

Index: llvm/test/Makefile
diff -u llvm/test/Makefile:1.52 llvm/test/Makefile:1.52.6.1
--- llvm/test/Makefile:1.52	Wed Dec 10 22:48:38 2003
+++ llvm/test/Makefile	Thu Mar 18 10:41:59 2004
@@ -34,6 +34,10 @@
 QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.sunos.qmr
 endif
 
+ifeq ($(OS),Darwin)
+QMEXPECT:=$(LLVM_SRC_ROOT)/test/QMTest/expectations.darwin.qmr
+endif
+
 #
 # This is configuration information used by the test suite.  In QM Test, it's
 # called a 'context.'




From criswell at cs.uiuc.edu  Thu Mar 18 10:43:06 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 10:43:06 2004
Subject: [llvm-commits] [release_12] CVS: llvm/include/llvm/Transforms/Utils/FunctionUtils.h
Message-ID: <200403181642.KAA12315@choi.cs.uiuc.edu>


Changes in directory llvm/include/llvm/Transforms/Utils:

FunctionUtils.h updated: 1.3 -> 1.3.2.1

---
Log message:

Updated code from trunk.



---
Diffs of the changes:  (+17 -14)

Index: llvm/include/llvm/Transforms/Utils/FunctionUtils.h
diff -u llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.3 llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.3.2.1
--- llvm/include/llvm/Transforms/Utils/FunctionUtils.h:1.3	Mon Mar  1 18:20:32 2004
+++ llvm/include/llvm/Transforms/Utils/FunctionUtils.h	Thu Mar 18 10:41:38 2004
@@ -14,23 +14,26 @@
 #ifndef LLVM_TRANSFORMS_UTILS_FUNCTION_H
 #define LLVM_TRANSFORMS_UTILS_FUNCTION_H
 
-namespace llvm {
-
-class Function;
-class Loop;
+#include 
 
-/// ExtractCodeRegion - rip out a sequence of basic blocks into a new function
-///
-Function* ExtractCodeRegion(const std::vector &code);
-
-/// ExtractLoop - rip out a natural loop into a new function
-///
-Function* ExtractLoop(Loop *L);
+namespace llvm {
+  class BasicBlock;
+  class DominatorSet;
+  class Function;
+  class Loop;
+  
+  /// ExtractCodeRegion - rip out a sequence of basic blocks into a new function
+  ///
+  Function* ExtractCodeRegion(DominatorSet &DS,
+                              const std::vector &code);
 
-/// ExtractBasicBlock - rip out a basic block into a new function
-///
-Function* ExtractBasicBlock(BasicBlock *BB);
+  /// ExtractLoop - rip out a natural loop into a new function
+  ///
+  Function* ExtractLoop(DominatorSet &DS, Loop *L);
 
+  /// ExtractBasicBlock - rip out a basic block into a new function
+  ///
+  Function* ExtractBasicBlock(BasicBlock *BB);
 }
 
 #endif




From criswell at cs.uiuc.edu  Thu Mar 18 10:43:11 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 10:43:11 2004
Subject: [llvm-commits] [release_12] CVS: llvm/lib/Target/X86/InstSelectSimple.cpp
Message-ID: <200403181642.KAA12320@choi.cs.uiuc.edu>


Changes in directory llvm/lib/Target/X86:

InstSelectSimple.cpp updated: 1.194 -> 1.194.2.1

---
Log message:

Updated code from trunk.



---
Diffs of the changes:  (+2 -0)

Index: llvm/lib/Target/X86/InstSelectSimple.cpp
diff -u llvm/lib/Target/X86/InstSelectSimple.cpp:1.194 llvm/lib/Target/X86/InstSelectSimple.cpp:1.194.2.1
--- llvm/lib/Target/X86/InstSelectSimple.cpp:1.194	Fri Mar 12 18:24:52 2004
+++ llvm/lib/Target/X86/InstSelectSimple.cpp	Thu Mar 18 10:41:41 2004
@@ -1422,6 +1422,8 @@
   // really use alias analysis here, but for now we just do something simple.
   for (++It; It != BasicBlock::iterator(&User); ++It) {
     switch (It->getOpcode()) {
+    case Instruction::Malloc:
+    case Instruction::Free:
     case Instruction::Store:
     case Instruction::Call:
     case Instruction::Invoke:




From criswell at cs.uiuc.edu  Thu Mar 18 10:43:16 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 10:43:16 2004
Subject: [llvm-commits] [release_12] CVS: llvm/lib/Transforms/IPO/LoopExtractor.cpp
Message-ID: <200403181642.KAA12325@choi.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/IPO:

LoopExtractor.cpp updated: 1.7 -> 1.7.2.1

---
Log message:

Updated code from trunk.



---
Diffs of the changes:  (+15 -4)

Index: llvm/lib/Transforms/IPO/LoopExtractor.cpp
diff -u llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.7 llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.7.2.1
--- llvm/lib/Transforms/IPO/LoopExtractor.cpp:1.7	Sun Mar 14 18:02:02 2004
+++ llvm/lib/Transforms/IPO/LoopExtractor.cpp	Thu Mar 18 10:41:43 2004
@@ -18,12 +18,16 @@
 #include "llvm/iTerminators.h"
 #include "llvm/Module.h"
 #include "llvm/Pass.h"
+#include "llvm/Analysis/Dominators.h"
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Transforms/Scalar.h"
 #include "llvm/Transforms/Utils/FunctionUtils.h"
+#include "Support/Statistic.h"
 using namespace llvm;
 
 namespace {
+  Statistic<> NumExtracted("loop-extract", "Number of loops extracted");
+  
   // FIXME: This is not a function pass, but the PassManager doesn't allow
   // Module passes to require FunctionPasses, so we can't get loop info if we're
   // not a function pass.
@@ -35,8 +39,10 @@
     virtual bool runOnFunction(Function &F);
     
     virtual void getAnalysisUsage(AnalysisUsage &AU) const {
-      AU.addRequired();
+      AU.addRequiredID(BreakCriticalEdgesID);
       AU.addRequiredID(LoopSimplifyID);
+      AU.addRequired();
+      AU.addRequired();
     }
   };
 
@@ -59,6 +65,8 @@
   if (LI.begin() == LI.end())
     return false;
 
+  DominatorSet &DS = getAnalysis();
+
   // If there is more than one top-level loop in this function, extract all of
   // the loops.
   bool Changed = false;
@@ -66,7 +74,8 @@
     for (LoopInfo::iterator i = LI.begin(), e = LI.end(); i != e; ++i) {
       if (NumLoops == 0) return Changed;
       --NumLoops;
-      Changed |= (ExtractLoop(*i) != 0);
+      Changed |= ExtractLoop(DS, *i) != 0;
+      ++NumExtracted;
     }
   } else {
     // Otherwise there is exactly one top-level loop.  If this function is more
@@ -93,7 +102,8 @@
     if (ShouldExtractLoop) {
       if (NumLoops == 0) return Changed;
       --NumLoops;
-      Changed |= (ExtractLoop(TLL) != 0);
+      Changed |= ExtractLoop(DS, TLL) != 0;
+      ++NumExtracted;
     } else {
       // Okay, this function is a minimal container around the specified loop.
       // If we extract the loop, we will continue to just keep extracting it
@@ -102,7 +112,8 @@
       for (Loop::iterator i = TLL->begin(), e = TLL->end(); i != e; ++i) {
         if (NumLoops == 0) return Changed;
         --NumLoops;
-        Changed |= (ExtractLoop(*i) != 0);
+        Changed |= ExtractLoop(DS, *i) != 0;
+        ++NumExtracted;
       }
     }
   }




From criswell at cs.uiuc.edu  Thu Mar 18 10:43:20 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 10:43:20 2004
Subject: [llvm-commits] [release_12] CVS: llvm/lib/Transforms/Utils/CodeExtractor.cpp
Message-ID: <200403181642.KAA12330@choi.cs.uiuc.edu>


Changes in directory llvm/lib/Transforms/Utils:

CodeExtractor.cpp updated: 1.10 -> 1.10.2.1

---
Log message:

Updated code from trunk.



---
Diffs of the changes:  (+104 -210)

Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
diff -u llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.10 llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.10.2.1
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp:1.10	Sun Mar 14 19:26:44 2004
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp	Thu Mar 18 10:41:44 2004
@@ -13,16 +13,16 @@
 //
 //===----------------------------------------------------------------------===//
 
-#include "llvm/BasicBlock.h"
+#include "llvm/Transforms/Utils/FunctionUtils.h"
 #include "llvm/Constants.h"
 #include "llvm/DerivedTypes.h"
 #include "llvm/Instructions.h"
 #include "llvm/Module.h"
 #include "llvm/Pass.h"
+#include "llvm/Analysis/Dominators.h"
 #include "llvm/Analysis/LoopInfo.h"
 #include "llvm/Analysis/Verifier.h"
 #include "llvm/Transforms/Utils/BasicBlockUtils.h"
-#include "llvm/Transforms/Utils/FunctionUtils.h"
 #include "Support/Debug.h"
 #include "Support/StringExtras.h"
 #include 
@@ -30,22 +30,13 @@
 using namespace llvm;
 
 namespace {
-
-  /// getFunctionArg - Return a pointer to F's ARGNOth argument.
-  ///
-  Argument *getFunctionArg(Function *F, unsigned argno) {
-    Function::aiterator I = F->abegin();
-    std::advance(I, argno);
-    return I;
-  }
-
-  struct CodeExtractor {
+  class CodeExtractor {
     typedef std::vector Values;
-    typedef std::vector > PhiValChangesTy;
-    typedef std::map PhiVal2ArgTy;
-    PhiVal2ArgTy PhiVal2Arg;
     std::set BlocksToExtract;
+    DominatorSet *DS;
   public:
+    CodeExtractor(DominatorSet *ds = 0) : DS(ds) {}
+
     Function *ExtractCodeRegion(const std::vector &code);
 
   private:
@@ -53,15 +44,9 @@
                            BasicBlock *newHeader,
                            BasicBlock *newRootNode);
 
-    void processPhiNodeInputs(PHINode *Phi,
-                              Values &inputs,
-                              BasicBlock *newHeader,
-                              BasicBlock *newRootNode);
-
-    void rewritePhiNodes(Function *F, BasicBlock *newFuncRoot);
-
     Function *constructFunction(const Values &inputs,
                                 const Values &outputs,
+                                BasicBlock *header,
                                 BasicBlock *newRootNode, BasicBlock *newHeader,
                                 Function *oldFunction, Module *M);
 
@@ -75,95 +60,6 @@
   };
 }
 
-void CodeExtractor::processPhiNodeInputs(PHINode *Phi,
-                                         Values &inputs,
-                                         BasicBlock *codeReplacer,
-                                         BasicBlock *newFuncRoot) {
-  // Separate incoming values and BasicBlocks as internal/external. We ignore
-  // the case where both the value and BasicBlock are internal, because we don't
-  // need to do a thing.
-  std::vector EValEBB;
-  std::vector EValIBB;
-  std::vector IValEBB;
-
-  for (unsigned i = 0, e = Phi->getNumIncomingValues(); i != e; ++i) {
-    Value *phiVal = Phi->getIncomingValue(i);
-    if (Instruction *Inst = dyn_cast(phiVal)) {
-      if (BlocksToExtract.count(Inst->getParent())) {
-        if (!BlocksToExtract.count(Phi->getIncomingBlock(i)))
-          IValEBB.push_back(i);
-      } else {
-        if (BlocksToExtract.count(Phi->getIncomingBlock(i)))
-          EValIBB.push_back(i);
-        else
-          EValEBB.push_back(i);
-      }
-    } else if (Argument *Arg = dyn_cast(phiVal)) {
-      // arguments are external
-      if (BlocksToExtract.count(Phi->getIncomingBlock(i)))
-        EValIBB.push_back(i);
-      else
-        EValEBB.push_back(i);
-    } else {
-      // Globals/Constants are internal, but considered `external' if they are
-      // coming from an external block.
-      if (!BlocksToExtract.count(Phi->getIncomingBlock(i)))
-        EValEBB.push_back(i);
-    }
-  }
-
-  // Both value and block are external. Need to group all of these, have an
-  // external phi, pass the result as an argument, and have THIS phi use that
-  // result.
-  if (EValEBB.size() > 0) {
-    if (EValEBB.size() == 1) {
-      // Now if it's coming from the newFuncRoot, it's that funky input
-      unsigned phiIdx = EValEBB[0];
-      if (!isa(Phi->getIncomingValue(phiIdx))) {
-        PhiVal2Arg[Phi].push_back(std::make_pair(phiIdx, inputs.size()));
-        // We can just pass this value in as argument
-        inputs.push_back(Phi->getIncomingValue(phiIdx));
-      }
-      Phi->setIncomingBlock(phiIdx, newFuncRoot);
-    } else {
-      PHINode *externalPhi = new PHINode(Phi->getType(), "extPhi");
-      codeReplacer->getInstList().insert(codeReplacer->begin(), externalPhi);
-      for (std::vector::iterator i = EValEBB.begin(),
-             e = EValEBB.end(); i != e; ++i) {
-        externalPhi->addIncoming(Phi->getIncomingValue(*i),
-                                 Phi->getIncomingBlock(*i));
-
-        // We make these values invalid instead of deleting them because that
-        // would shift the indices of other values... The fixPhiNodes should
-        // clean these phi nodes up later.
-        Phi->setIncomingValue(*i, 0);
-        Phi->setIncomingBlock(*i, 0);
-      }
-      PhiVal2Arg[Phi].push_back(std::make_pair(Phi->getNumIncomingValues(),
-                                               inputs.size()));
-      // We can just pass this value in as argument
-      inputs.push_back(externalPhi);
-    }
-  }
-
-  // When the value is external, but block internal...  just pass it in as
-  // argument, no change to phi node
-  for (std::vector::iterator i = EValIBB.begin(),
-         e = EValIBB.end(); i != e; ++i) {
-    // rewrite the phi input node to be an argument
-    PhiVal2Arg[Phi].push_back(std::make_pair(*i, inputs.size()));
-    inputs.push_back(Phi->getIncomingValue(*i));
-  }
-
-  // Value internal, block external this can happen if we are extracting a part
-  // of a loop.
-  for (std::vector::iterator i = IValEBB.begin(),
-         e = IValEBB.end(); i != e; ++i) {
-    assert(0 && "Cannot (YET) handle internal values via external blocks");
-  }
-}
-
-
 void CodeExtractor::findInputsOutputs(Values &inputs, Values &outputs,
                                       BasicBlock *newHeader,
                                       BasicBlock *newRootNode) {
@@ -173,8 +69,18 @@
     for (BasicBlock::iterator I = BB->begin(), E = BB->end(); I != E; ++I) {
       // If a used value is defined outside the region, it's an input.  If an
       // instruction is used outside the region, it's an output.
-      if (PHINode *Phi = dyn_cast(I)) {
-        processPhiNodeInputs(Phi, inputs, newHeader, newRootNode);
+      if (PHINode *PN = dyn_cast(I)) {
+        for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i) {
+          Value *V = PN->getIncomingValue(i);
+          if (!BlocksToExtract.count(PN->getIncomingBlock(i)) &&
+              (isa(V) || isa(V)))
+            inputs.push_back(V);
+          else if (Instruction *opI = dyn_cast(V)) {
+            if (!BlocksToExtract.count(opI->getParent()))
+              inputs.push_back(opI);
+          } else if (isa(V))
+            inputs.push_back(V);
+        }
       } else {
         // All other instructions go through the generic input finder
         // Loop over the operands of each instruction (inputs)
@@ -192,59 +98,26 @@
       // Consider uses of this instruction (outputs)
       for (Value::use_iterator UI = I->use_begin(), E = I->use_end();
            UI != E; ++UI)
-        if (!BlocksToExtract.count(cast(*UI)->getParent()))
-          outputs.push_back(*UI);
+        if (!BlocksToExtract.count(cast(*UI)->getParent())) {
+          outputs.push_back(I);
+          break;
+        }
     } // for: insts
   } // for: basic blocks
 }
 
-void CodeExtractor::rewritePhiNodes(Function *F,
-                                    BasicBlock *newFuncRoot) {
-  // Write any changes that were saved before: use function arguments as inputs
-  for (PhiVal2ArgTy::iterator i = PhiVal2Arg.begin(), e = PhiVal2Arg.end();
-       i != e; ++i) {
-    PHINode *phi = i->first;
-    PhiValChangesTy &values = i->second;
-    for (unsigned cIdx = 0, ce = values.size(); cIdx != ce; ++cIdx)
-    {
-      unsigned phiValueIdx = values[cIdx].first, argNum = values[cIdx].second;
-      if (phiValueIdx < phi->getNumIncomingValues())
-        phi->setIncomingValue(phiValueIdx, getFunctionArg(F, argNum));
-      else
-        phi->addIncoming(getFunctionArg(F, argNum), newFuncRoot);
-    }
-  }
-
-  // Delete any invalid Phi node inputs that were marked as NULL previously
-  for (PhiVal2ArgTy::iterator i = PhiVal2Arg.begin(), e = PhiVal2Arg.end();
-       i != e; ++i) {
-    PHINode *phi = i->first;
-    for (unsigned idx = 0, end = phi->getNumIncomingValues(); idx != end; ++idx)
-    {
-      if (phi->getIncomingValue(idx) == 0 && phi->getIncomingBlock(idx) == 0) {
-        phi->removeIncomingValue(idx);
-        --idx;
-        --end;
-      }
-    }
-  }
-
-  // We are done with the saved values
-  PhiVal2Arg.clear();
-}
-
-
 /// constructFunction - make a function based on inputs and outputs, as follows:
 /// f(in0, ..., inN, out0, ..., outN)
 ///
 Function *CodeExtractor::constructFunction(const Values &inputs,
                                            const Values &outputs,
+                                           BasicBlock *header,
                                            BasicBlock *newRootNode,
                                            BasicBlock *newHeader,
-                                           Function *oldFunction, Module *M) {
+                                           Function *oldFunction,
+                                           Module *M) {
   DEBUG(std::cerr << "inputs: " << inputs.size() << "\n");
   DEBUG(std::cerr << "outputs: " << outputs.size() << "\n");
-  BasicBlock *header = *BlocksToExtract.begin();
 
   // This function returns unsigned, outputs will go back by reference.
   Type *retTy = Type::UShortTy;
@@ -258,18 +131,11 @@
     paramTy.push_back(value->getType());
   }
 
-  // Add the types of the output values to the function's argument list, but
-  // make them pointer types for scalars
-  for (Values::const_iterator i = outputs.begin(),
-         e = outputs.end(); i != e; ++i) {
-    const Value *value = *i;
-    DEBUG(std::cerr << "instr used in func: " << value << "\n");
-    const Type *valueType = value->getType();
-    // Convert scalar types into a pointer of that type
-    if (valueType->isPrimitiveType()) {
-      valueType = PointerType::get(valueType);
-    }
-    paramTy.push_back(valueType);
+  // Add the types of the output values to the function's argument list.
+  for (Values::const_iterator I = outputs.begin(), E = outputs.end();
+       I != E; ++I) {
+    DEBUG(std::cerr << "instr used in func: " << *I << "\n");
+    paramTy.push_back(PointerType::get((*I)->getType()));
   }
 
   DEBUG(std::cerr << "Function type: " << retTy << " f(");
@@ -286,30 +152,37 @@
                                        oldFunction->getName() + "_code", M);
   newFunction->getBasicBlockList().push_back(newRootNode);
 
-  for (unsigned i = 0, e = inputs.size(); i != e; ++i) {
+  // Create an iterator to name all of the arguments we inserted.
+  Function::aiterator AI = newFunction->abegin();
+
+  // Rewrite all users of the inputs in the extracted region to use the
+  // arguments instead.
+  for (unsigned i = 0, e = inputs.size(); i != e; ++i, ++AI) {
+    AI->setName(inputs[i]->getName());
     std::vector Users(inputs[i]->use_begin(), inputs[i]->use_end());
     for (std::vector::iterator use = Users.begin(), useE = Users.end();
          use != useE; ++use)
       if (Instruction* inst = dyn_cast(*use))
         if (BlocksToExtract.count(inst->getParent()))
-          inst->replaceUsesOfWith(inputs[i], getFunctionArg(newFunction, i));
+          inst->replaceUsesOfWith(inputs[i], AI);
   }
 
+  // Set names for all of the output arguments.
+  for (unsigned i = 0, e = outputs.size(); i != e; ++i, ++AI)
+    AI->setName(outputs[i]->getName()+".out");  
+
+
   // Rewrite branches to basic blocks outside of the loop to new dummy blocks
   // within the new function. This must be done before we lose track of which
   // blocks were originally in the code region.
   std::vector Users(header->use_begin(), header->use_end());
-  for (std::vector::iterator i = Users.begin(), e = Users.end();
-       i != e; ++i) {
-    if (BranchInst *inst = dyn_cast(*i)) {
-      BasicBlock *BB = inst->getParent();
-      if (!BlocksToExtract.count(BB) && BB->getParent() == oldFunction) {
-        // The BasicBlock which contains the branch is not in the region
-        // modify the branch target to a new block
-        inst->replaceUsesOfWith(header, newHeader);
-      }
-    }
-  }
+  for (unsigned i = 0, e = Users.size(); i != e; ++i)
+    // The BasicBlock which contains the branch is not in the region
+    // modify the branch target to a new block
+    if (TerminatorInst *TI = dyn_cast(Users[i]))
+      if (!BlocksToExtract.count(TI->getParent()) &&
+          TI->getParent()->getParent() == oldFunction)
+        TI->replaceUsesOfWith(header, newHeader);
 
   return newFunction;
 }
@@ -333,34 +206,30 @@
 CodeExtractor::emitCallAndSwitchStatement(Function *newFunction,
                                           BasicBlock *codeReplacer,
                                           Values &inputs,
-                                          Values &outputs)
-{
+                                          Values &outputs) {
   // Emit a call to the new function, passing allocated memory for outputs and
   // just plain inputs for non-scalars
   std::vector params(inputs);
 
-  for (Values::const_iterator i = outputs.begin(), e = outputs.end(); i != e;
-       ++i) {
-    Value *Output = *i;
+  // Get an iterator to the first output argument.
+  Function::aiterator OutputArgBegin = newFunction->abegin();
+  std::advance(OutputArgBegin, inputs.size());
+
+  for (unsigned i = 0, e = outputs.size(); i != e; ++i) {
+    Value *Output = outputs[i];
     // Create allocas for scalar outputs
-    if (Output->getType()->isPrimitiveType()) {
-      AllocaInst *alloca =
-        new AllocaInst((*i)->getType(), 0, Output->getName()+".loc",
-                       codeReplacer->getParent()->begin()->begin());
-      params.push_back(alloca);
-
-      LoadInst *load = new LoadInst(alloca, Output->getName()+".reload");
-      codeReplacer->getInstList().push_back(load);
-      std::vector Users((*i)->use_begin(), (*i)->use_end());
-      for (std::vector::iterator use = Users.begin(), useE =Users.end();
-           use != useE; ++use) {
-        if (Instruction* inst = dyn_cast(*use)) {
-          if (!BlocksToExtract.count(inst->getParent()))
-            inst->replaceUsesOfWith(*i, load);
-        }
-      }
-    } else {
-      params.push_back(*i);
+    AllocaInst *alloca =
+      new AllocaInst(outputs[i]->getType(), 0, Output->getName()+".loc",
+                     codeReplacer->getParent()->begin()->begin());
+    params.push_back(alloca);
+    
+    LoadInst *load = new LoadInst(alloca, Output->getName()+".reload");
+    codeReplacer->getInstList().push_back(load);
+    std::vector Users(outputs[i]->use_begin(), outputs[i]->use_end());
+    for (unsigned u = 0, e = Users.size(); u != e; ++u) {
+      Instruction *inst = cast(Users[u]);
+      if (!BlocksToExtract.count(inst->getParent()))
+        inst->replaceUsesOfWith(outputs[i], load);
     }
   }
 
@@ -400,8 +269,12 @@
 
           // Restore values just before we exit
           // FIXME: Use a GetElementPtr to bunch the outputs in a struct
-          for (unsigned out = 0, e = outputs.size(); out != e; ++out)
-            new StoreInst(outputs[out], getFunctionArg(newFunction, out),NTRet);
+          Function::aiterator OAI = OutputArgBegin;
+          for (unsigned out = 0, e = outputs.size(); out != e; ++out, ++OAI)
+            if (!DS ||
+                DS->dominates(cast(outputs[out])->getParent(),
+                              TI->getParent()))
+              new StoreInst(outputs[out], OAI, NTRet);
         }
 
         // rewrite the original branch instruction with this new target
@@ -486,16 +359,36 @@
 
   // Step 2: Construct new function based on inputs/outputs,
   // Add allocas for all defs
-  Function *newFunction = constructFunction(inputs, outputs, newFuncRoot, 
+  Function *newFunction = constructFunction(inputs, outputs, code[0],
+                                            newFuncRoot, 
                                             codeReplacer, oldFunction,
                                             oldFunction->getParent());
 
-  rewritePhiNodes(newFunction, newFuncRoot);
-
   emitCallAndSwitchStatement(newFunction, codeReplacer, inputs, outputs);
 
   moveCodeToFunction(newFunction);
 
+  // Loop over all of the PHI nodes in the entry block (code[0]), and change any
+  // references to the old incoming edge to be the new incoming edge.
+  for (BasicBlock::iterator I = code[0]->begin();
+       PHINode *PN = dyn_cast(I); ++I)
+    for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i)
+      if (!BlocksToExtract.count(PN->getIncomingBlock(i)))
+        PN->setIncomingBlock(i, newFuncRoot);
+
+  // Look at all successors of the codeReplacer block.  If any of these blocks
+  // had PHI nodes in them, we need to update the "from" block to be the code
+  // replacer, not the original block in the extracted region.
+  std::vector Succs(succ_begin(codeReplacer),
+                                 succ_end(codeReplacer));
+  for (unsigned i = 0, e = Succs.size(); i != e; ++i)
+    for (BasicBlock::iterator I = Succs[i]->begin();
+         PHINode *PN = dyn_cast(I); ++I)
+      for (unsigned i = 0, e = PN->getNumIncomingValues(); i != e; ++i)
+        if (BlocksToExtract.count(PN->getIncomingBlock(i)))
+          PN->setIncomingBlock(i, codeReplacer);
+  
+
   DEBUG(if (verifyFunction(*newFunction)) abort());
   return newFunction;
 }
@@ -503,14 +396,15 @@
 /// ExtractCodeRegion - slurp a sequence of basic blocks into a brand new
 /// function
 ///
-Function* llvm::ExtractCodeRegion(const std::vector &code) {
-  return CodeExtractor().ExtractCodeRegion(code);
+Function* llvm::ExtractCodeRegion(DominatorSet &DS,
+                                  const std::vector &code) {
+  return CodeExtractor(&DS).ExtractCodeRegion(code);
 }
 
 /// ExtractBasicBlock - slurp a natural loop into a brand new function
 ///
-Function* llvm::ExtractLoop(Loop *L) {
-  return CodeExtractor().ExtractCodeRegion(L->getBlocks());
+Function* llvm::ExtractLoop(DominatorSet &DS, Loop *L) {
+  return CodeExtractor(&DS).ExtractCodeRegion(L->getBlocks());
 }
 
 /// ExtractBasicBlock - slurp a basic block into a brand new function




From lattner at cs.uiuc.edu  Thu Mar 18 11:02:02 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu Mar 18 11:02:02 2004
Subject: [llvm-commits] CVS: llvm/lib/Target/X86/InstSelectSimple.cpp
Message-ID: <200403181701.LAA16221@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Target/X86:

InstSelectSimple.cpp updated: 1.195 -> 1.196

---
Log message:

Malloc doesn't kill a load.  This patch need not go into 1.2 though.


---
Diffs of the changes:  (+0 -1)

Index: llvm/lib/Target/X86/InstSelectSimple.cpp
diff -u llvm/lib/Target/X86/InstSelectSimple.cpp:1.195 llvm/lib/Target/X86/InstSelectSimple.cpp:1.196
--- llvm/lib/Target/X86/InstSelectSimple.cpp:1.195	Thu Mar 18 00:29:54 2004
+++ llvm/lib/Target/X86/InstSelectSimple.cpp	Thu Mar 18 11:01:26 2004
@@ -1422,7 +1422,6 @@
   // really use alias analysis here, but for now we just do something simple.
   for (++It; It != BasicBlock::iterator(&User); ++It) {
     switch (It->getOpcode()) {
-    case Instruction::Malloc:
     case Instruction::Free:
     case Instruction::Store:
     case Instruction::Call:




From criswell at cs.uiuc.edu  Thu Mar 18 11:33:03 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 11:33:03 2004
Subject: [llvm-commits] [release_12] CVS: llvm/tools/llc/Makefile llc.cpp
Message-ID: <200403181732.LAA15194@choi.cs.uiuc.edu>


Changes in directory llvm/tools/llc:

Makefile updated: 1.50 -> 1.50.2.1
llc.cpp updated: 1.96 -> 1.96.2.1

---
Log message:

Removed PowerPC code generation options from llc.  The PowerPC code
generator isn't even at an experimental stage (if I understand the comments
correctly).



---
Diffs of the changes:  (+1 -11)

Index: llvm/tools/llc/Makefile
diff -u llvm/tools/llc/Makefile:1.50 llvm/tools/llc/Makefile:1.50.2.1
--- llvm/tools/llc/Makefile:1.50	Thu Mar 11 12:16:33 2004
+++ llvm/tools/llc/Makefile	Thu Mar 18 11:32:36 2004
@@ -11,7 +11,6 @@
 USEDLIBS = cwriter \
            sparcv9 \
            x86 \
-           powerpc \
            selectiondag \
            sparcv9regalloc \
            sched \


Index: llvm/tools/llc/llc.cpp
diff -u llvm/tools/llc/llc.cpp:1.96 llvm/tools/llc/llc.cpp:1.96.2.1
--- llvm/tools/llc/llc.cpp:1.96	Tue Mar 16 15:47:20 2004
+++ llvm/tools/llc/llc.cpp	Thu Mar 18 11:32:36 2004
@@ -39,13 +39,12 @@
 
 static cl::opt Force("f", cl::desc("Overwrite output files"));
 
-enum ArchName { noarch, X86, SparcV9, PowerPC, CBackend };
+enum ArchName { noarch, X86, SparcV9, CBackend };
 
 static cl::opt
 Arch("march", cl::desc("Architecture to generate assembly for:"), cl::Prefix,
      cl::values(clEnumValN(X86,      "x86",     "  IA-32 (Pentium and above)"),
                 clEnumValN(SparcV9,  "sparcv9", "  SPARC V9"),
-                clEnumValN(PowerPC,  "powerpc", "  PowerPC (experimental)"),
                 clEnumValN(CBackend, "c",       "  C backend"),
 		0),
      cl::init(noarch));
@@ -95,9 +94,6 @@
   case SparcV9:
     TargetMachineAllocator = allocateSparcV9TargetMachine;
     break;
-  case PowerPC:
-    TargetMachineAllocator = allocatePowerPCTargetMachine;
-    break;
   default:
     // Decide what the default target machine should be, by looking at
     // the module. This heuristic (ILP32, LE -> IA32; LP64, BE ->
@@ -106,9 +102,6 @@
     if (mod.getEndianness()  == Module::LittleEndian &&
         mod.getPointerSize() == Module::Pointer32) { 
       TargetMachineAllocator = allocateX86TargetMachine;
-    } else if (mod.getEndianness() == Module::BigEndian &&
-        mod.getPointerSize() == Module::Pointer32) { 
-      TargetMachineAllocator = allocatePowerPCTargetMachine;
     } else if (mod.getEndianness()  == Module::BigEndian &&
                mod.getPointerSize() == Module::Pointer64) { 
       TargetMachineAllocator = allocateSparcV9TargetMachine;
@@ -119,8 +112,6 @@
       TargetMachineAllocator = allocateX86TargetMachine;
 #elif defined(sparc) || defined(__sparc__) || defined(__sparcv9)
       TargetMachineAllocator = allocateSparcV9TargetMachine;
-#elif defined(__POWERPC__) || defined(__ppc__) || defined(__APPLE__)
-      TargetMachineAllocator = allocatePowerPCTargetMachine;
 #else
       std::cerr << argv[0] << ": module does not specify a target to use.  "
                 << "You must use the -march option.  If no native target is "




From criswell at cs.uiuc.edu  Thu Mar 18 11:48:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 11:48:01 2004
Subject: [llvm-commits] [release_12] CVS: llvm/lib/Target/PowerPC/Makefile PowerPC.h PowerPC.td PowerPCCodeEmitter.cpp PowerPCInstrInfo.cpp PowerPCInstrInfo.h PowerPCInstrs.td PowerPCJITInfo.h PowerPCReg.td PowerPCRegisterInfo.cpp PowerPCRegisterInfo.h PowerPCTargetMachine.cpp PowerPCTargetMachine.h README.txt
Message-ID: <200403181747.LAA16975@choi.cs.uiuc.edu>


Changes in directory llvm/lib/Target/PowerPC:

Makefile (r1.1) removed
PowerPC.h (r1.2) removed
PowerPC.td (r1.1) removed
PowerPCCodeEmitter.cpp (r1.1) removed
PowerPCInstrInfo.cpp (r1.3) removed
PowerPCInstrInfo.h (r1.2) removed
PowerPCInstrs.td (r1.1) removed
PowerPCJITInfo.h (r1.1) removed
PowerPCReg.td (r1.1) removed
PowerPCRegisterInfo.cpp (r1.4) removed
PowerPCRegisterInfo.h (r1.4) removed
PowerPCTargetMachine.cpp (r1.7) removed
PowerPCTargetMachine.h (r1.4) removed
README.txt (r1.2) removed

---
Log message:

Removing the PowerPC code generator from the LLVM 1.2 Release Tree.
This is good because it will make LLVM more "polished," but bad because
there might be a joe out there who could take this and flesh it out into
a real code generator.



---
Diffs of the changes:  (+0 -0)



From criswell at cs.uiuc.edu  Thu Mar 18 11:49:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 11:49:01 2004
Subject: [llvm-commits] [release_12] CVS: llvm/lib/Target/Makefile
Message-ID: <200403181747.LAA16997@choi.cs.uiuc.edu>


Changes in directory llvm/lib/Target:

Makefile updated: 1.14 -> 1.14.2.1

---
Log message:

Removed PowerPC directory.



---
Diffs of the changes:  (+1 -1)

Index: llvm/lib/Target/Makefile
diff -u llvm/lib/Target/Makefile:1.14 llvm/lib/Target/Makefile:1.14.2.1
--- llvm/lib/Target/Makefile:1.14	Wed Mar 10 22:42:41 2004
+++ llvm/lib/Target/Makefile	Thu Mar 18 11:47:49 2004
@@ -7,7 +7,7 @@
 # 
 ##===----------------------------------------------------------------------===##
 LEVEL = ../..
-DIRS = CBackend X86 SparcV9 PowerPC
+DIRS = CBackend X86 SparcV9
 LIBRARYNAME = target
 BUILD_ARCHIVE = 1
 




From criswell at cs.uiuc.edu  Thu Mar 18 14:30:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 14:30:01 2004
Subject: [llvm-commits] CVS: llvm-www/releases/1.2/LICENSE.TXT
Message-ID: <200403182029.OAA17029@zion.cs.uiuc.edu>


Changes in directory llvm-www/releases/1.2:

LICENSE.TXT updated: 1.1 -> 1.2

---
Log message:

Updating license to reflect changes made in LLVM.
Also adds an additional warranty clarification.



---
Diffs of the changes:  (+45 -0)

Index: llvm-www/releases/1.2/LICENSE.TXT
diff -u llvm-www/releases/1.2/LICENSE.TXT:1.1 llvm-www/releases/1.2/LICENSE.TXT:1.2
--- llvm-www/releases/1.2/LICENSE.TXT:1.1	Fri Mar 12 12:15:06 2004
+++ llvm-www/releases/1.2/LICENSE.TXT	Thu Mar 18 14:28:55 2004
@@ -49,3 +49,48 @@
 have its own individual LICENSE.TXT file in the directory in which it appears.
 This file will describe the copyrights, license, and restrictions which apply
 to that code.
+
+The disclaimer of warranty in the University of Illinois Open Source License
+applies to all code in the LLVM Distribution, and nothing in any of the
+other licenses gives permission to use the names of the LLVM Team or the
+University of Illinois to endorse or promote products derived from this
+Software.
+
+The following pieces of software have additional or alternate copyrights,
+licenses, and/or restrictions:
+
+Program             Directory
+-------             ---------
+Autoconf:           llvm/autoconf
+                    llvm/projects/ModuleMaker/autoconf
+                    llvm/projects/sample/autoconf
+Burg:               llvm/utils/Burg
+                    llvm/test/Programs/MultiSource/Applications/Burg
+Aha:                llvm/test/Programs/MultiSource/Applications/aha
+SGEFA:              llvm/test/Programs/MultiSource/Applications/sgefa
+SIOD:               llvm/test/Programs/MultiSource/Applications/siod
+D:                  llvm/test/Programs/MultiSource/Applications/d
+Lambda:             llvm/test/Programs/MultiSource/Applications/lambda-0.1.3
+hbd:                llvm/test/Programs/MultiSource/Applications/hbd
+Fhourstones:        llvm/test/Programs/MultiSource/Benchmarks/Fhourstones
+McCat:              llvm/test/Programs/MultiSource/Benchmarks/McCat
+Olden:              llvm/test/Programs/MultiSource/Benchmarks/Olden
+OptimizerEval:      llvm/test/Programs/MultiSource/Benchmarks/OptimizerEval
+Ptrdist:            llvm/test/Programs/MultiSource/Benchmarks/Ptrdist
+LLUBenchmark:       llvm/test/Programs/MultiSource/Benchmarks/llubenchmark
+SIM:                llvm/test/Programs/MultiSource/Benchmarks/sim
+cfrac:              llvm/test/Programs/MultiSource/Benchmarks/MallocBench/cfrac
+espresso:           llvm/test/Programs/MultiSource/Benchmarks/MallocBench/espresso
+gs:                 llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gs
+p2c:                llvm/test/Programs/MultiSource/Benchmarks/MallocBench/p2c
+gawk:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/gawk
+make:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/make
+perl:               llvm/test/Programs/MultiSource/Benchmarks/MallocBench/perl
+Dhrystone:          llvm/test/Programs/SingleSource/Benchmarks/Dhrystone
+SingleSource Tests: llvm/test/Programs/SingleSource/Benchmarks/Misc
+                    llvm/test/Programs/SingleSource/CustomChecked
+                    llvm/test/Programs/SingleSource/Gizmos
+GNU Libc:           llvm/runtime/GCCLibraries/libc
+Zlib Library:       llvm/runtime/zlib
+PNG Library:        llvm/runtime/libpng
+




From criswell at cs.uiuc.edu  Thu Mar 18 17:22:08 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 17:22:08 2004
Subject: [llvm-commits] [release_12] CVS: llvm-gcc/gcc/llvm-expand.c
Message-ID: <200403182321.RAA17804@zion.cs.uiuc.edu>


Changes in directory llvm-gcc/gcc:

llvm-expand.c updated: 1.30.2.1 -> 1.30.2.2

---
Log message:

Corrected floating point error on Sparc/Solaris again.
This fix, I believe, should work on *all* of the platforms correctly, and
it simplifies the code a lot.
Hopefully someone can test on a 32 bit PowerPC machine to ensure I've done
it right this time.



---
Diffs of the changes:  (+18 -12)

Index: llvm-gcc/gcc/llvm-expand.c
diff -u llvm-gcc/gcc/llvm-expand.c:1.30.2.1 llvm-gcc/gcc/llvm-expand.c:1.30.2.2
--- llvm-gcc/gcc/llvm-expand.c:1.30.2.1	Tue Mar 16 20:42:22 2004
+++ llvm-gcc/gcc/llvm-expand.c	Thu Mar 18 17:21:45 2004
@@ -4957,23 +4957,29 @@
     }    
 
     /* FIXME: This won't work right if endianness is non-agreeing? */
-    
+
+    /*
+     * Here's how this works:
+     *  REAL_VALUE_TO_TARGET_DOUBLE() will generate the floating point number
+     *  as an array of integers in the hosts's representation.  Each integer
+     *  in the array will hold 32 bits of the result REGARDLESS OF THE HOST'S
+     *  INTEGER SIZE.
+     *
+     *  This, then, makes the conversion pretty simple.  The tricky part is
+     *  getting the byte ordering correct and make sure you don't print any
+     *  more than 32 bits per integer on platforms with ints > 32 bits.
+     */
     *BufPtr++ = '0';
     *BufPtr++ = 'x';
     if (!(BYTES_BIG_ENDIAN)) {   /* If little endian */
-      Values = (char*)RealArr+Size;
-      while (Size--) {
-        sprintf(BufPtr, "%02X", (unsigned char)*--Values);
-        BufPtr += 2;
-      }
+      sprintf(Buffer+2,  "%08X", RealArr[1]);
+      sprintf(Buffer+10, "%08X", RealArr[0]);
+      *(Buffer+18) = 0;  /* Null terminate */
     } else {
-      Values = (char*)RealArr;
-      while (Size--) {
-        sprintf(BufPtr, "%02X", (unsigned char)*Values++);
-        BufPtr += 2;
-      }
+      sprintf(Buffer+2,  "%08X", RealArr[0]);
+      sprintf(Buffer+10, "%08X", RealArr[1]);
+      *(Buffer+18) = 0;  /* Null terminate */
     }
-    *BufPtr = 0;  /* Null terminate */
 
     Val = llvm_constant_new(Ty, Buffer);
     break;




From criswell at cs.uiuc.edu  Thu Mar 18 21:04:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 21:04:01 2004
Subject: [llvm-commits] [release_12] CVS: llvm-gcc/libiberty/Makefile.in
Message-ID: <200403190303.VAA18482@zion.cs.uiuc.edu>


Changes in directory llvm-gcc/libiberty:

Makefile.in updated: 1.1.1.1 -> 1.1.1.1.2.1

---
Log message:

Added quotes around list to make it syntatically correct for Borne shell.
This fixes the intermittent build failure on Sparc/Solaris.



---
Diffs of the changes:  (+1 -1)

Index: llvm-gcc/libiberty/Makefile.in
diff -u llvm-gcc/libiberty/Makefile.in:1.1.1.1 llvm-gcc/libiberty/Makefile.in:1.1.1.1.2.1
--- llvm-gcc/libiberty/Makefile.in:1.1.1.1	Thu Jan  8 15:59:17 2004
+++ llvm-gcc/libiberty/Makefile.in	Thu Mar 18 21:02:55 2004
@@ -307,7 +307,7 @@
 needed-list: Makefile
 	rm -f needed-list; touch needed-list; \
 	for f in $(NEEDED); do \
-	  for g in $(LIBOBJS) $(EXTRA_OFILES); do \
+	  for g in "$(LIBOBJS) $(EXTRA_OFILES)"; do \
 	    case "$$g" in \
 	      *$$f*) echo $$g >> needed-list ;; \
 	    esac; \




From criswell at cs.uiuc.edu  Thu Mar 18 21:14:01 2004
From: criswell at cs.uiuc.edu (John Criswell)
Date: Thu Mar 18 21:14:01 2004
Subject: [llvm-commits] [release_12] CVS: llvm-gcc/libiberty/Makefile.in
Message-ID: <200403190313.VAA18535@zion.cs.uiuc.edu>


Changes in directory llvm-gcc/libiberty:

Makefile.in updated: 1.1.1.1.2.1 -> 1.1.1.1.2.2

---
Log message:

My previous fix was incorrect.  This fix should be correct; we'll find out
for certain when everything finishes building.
:)



---
Diffs of the changes:  (+7 -5)

Index: llvm-gcc/libiberty/Makefile.in
diff -u llvm-gcc/libiberty/Makefile.in:1.1.1.1.2.1 llvm-gcc/libiberty/Makefile.in:1.1.1.1.2.2
--- llvm-gcc/libiberty/Makefile.in:1.1.1.1.2.1	Thu Mar 18 21:02:55 2004
+++ llvm-gcc/libiberty/Makefile.in	Thu Mar 18 21:13:31 2004
@@ -307,11 +307,13 @@
 needed-list: Makefile
 	rm -f needed-list; touch needed-list; \
 	for f in $(NEEDED); do \
-	  for g in "$(LIBOBJS) $(EXTRA_OFILES)"; do \
-	    case "$$g" in \
-	      *$$f*) echo $$g >> needed-list ;; \
-	    esac; \
-	  done; \
+    if test -n $(LIBOBJS) -o -n $(EXTRA_OFILES); then \
+      for g in $(LIBOBJS) $(EXTRA_OFILES); do \
+        case "$$g" in \
+          *$$f*) echo $$g >> needed-list ;; \
+        esac; \
+      done; \
+    fi; \
 	done
 
 # required-list was used when building a shared bfd/opcodes/libiberty




From lattner at cs.uiuc.edu  Thu Mar 18 22:22:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu Mar 18 22:22:01 2004
Subject: [llvm-commits] CVS: llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp
Message-ID: <200403190421.WAA19242@zion.cs.uiuc.edu>


Changes in directory llvm/lib/Target/SparcV9:

SparcV9InstrSelection.cpp updated: 1.137 -> 1.138

---
Log message:

Fix PR299: http://llvm.cs.uiuc.edu/PR299 : [Sparc] Code generator asserts on alloc of zero size type



---
Diffs of the changes:  (+7 -1)

Index: llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp
diff -u llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp:1.137 llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp:1.138
--- llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp:1.137	Fri Mar 12 18:23:46 2004
+++ llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp	Thu Mar 18 22:21:43 2004
@@ -1156,11 +1156,17 @@
                              unsigned numElements,
                              std::vector& getMvec)
 {
-  assert(tsize > 0 && "Illegal (zero) type size for alloca");
   assert(result && result->getParent() &&
          "Result value is not part of a function?");
   Function *F = result->getParent()->getParent();
   MachineFunction &mcInfo = MachineFunction::get(F);
+
+  // If the alloca is of zero bytes (which is perfectly legal) we bump it up to
+  // one byte.  This is unnecessary, but I really don't want to break any
+  // fragile logic in this code.  FIXME.
+  if (tsize == 0)
+    tsize = 1;
+
 
   // Put the variable in the dynamically sized area of the frame if either:
   // (a) The offset is too large to use as an immediate in load/stores




From lattner at cs.uiuc.edu  Thu Mar 18 22:27:01 2004
From: lattner at cs.uiuc.edu (Chris Lattner)
Date: Thu Mar 18 22:27:01 2004
Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html
Message-ID: <200403190426.WAA19743@zion.cs.uiuc.edu>


Changes in directory llvm/docs:

ReleaseNotes.html updated: 1.153 -> 1.154

---
Log message:

Perhaps the last bugfix before the release?  HOPEFULLY!  :)


---
Diffs of the changes:  (+2 -2)

Index: llvm/docs/ReleaseNotes.html
diff -u llvm/docs/ReleaseNotes.html:1.153 llvm/docs/ReleaseNotes.html:1.154
--- llvm/docs/ReleaseNotes.html:1.153	Tue Mar 16 21:54:41 2004
+++ llvm/docs/ReleaseNotes.html	Thu Mar 18 22:26:04 2004
@@ -231,7 +231,7 @@
 
      • [JIT] Programs cannot resolve the fstat function
        • 
 
      • [indvars] Induction variable analysis violates LLVM invariants
        • 
 
      • [execution engines] Unhandled cast constant expression
        • 
-
+
      • [Sparc] Code generator asserts on alloca of zero size type
        •
    @@ -664,7 +664,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/17 03:54:41 $ + Last modified: $Date: 2004/03/19 04:26:04 $ From lattner at cs.uiuc.edu Fri Mar 19 00:08:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 00:08:02 2004 Subject: [llvm-commits] CVS: llvm/test/Regression/Transforms/InstCombine/alloca.ll Message-ID: <200403190607.AAA21024@zion.cs.uiuc.edu> Changes in directory llvm/test/Regression/Transforms/InstCombine: alloca.ll added (r1.1) --- Log message: New testcase, the optimizer can delete zero sized allocas --- Diffs of the changes: (+14 -0) Index: llvm/test/Regression/Transforms/InstCombine/alloca.ll diff -c /dev/null llvm/test/Regression/Transforms/InstCombine/alloca.ll:1.1 *** /dev/null Fri Mar 19 00:07:54 2004 --- llvm/test/Regression/Transforms/InstCombine/alloca.ll Fri Mar 19 00:07:43 2004 *************** *** 0 **** --- 1,14 ---- + ; Zero byte allocas should be deleted. + + ; RUN: llvm-as < %s | opt -instcombine | llvm-dis | not grep alloca + + declare void %use(...) + void %test() { + %X = alloca [0 x int] + call void(...)* %use([0 x int] *%X) + %Y = alloca int, uint 0 + call void(...)* %use(int* %Y) + %Z = alloca {} + call void(...)* %use({}* %Z) + ret void + } From lattner at cs.uiuc.edu Fri Mar 19 00:09:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 00:09:01 2004 Subject: [llvm-commits] CVS: llvm/lib/Transforms/Scalar/InstructionCombining.cpp Message-ID: <200403190608.AAA21035@zion.cs.uiuc.edu> Changes in directory llvm/lib/Transforms/Scalar: InstructionCombining.cpp updated: 1.172 -> 1.173 --- Log message: Teach the optimizer to delete zero sized alloca's (but not mallocs!) --- Diffs of the changes: (+12 -4) Index: llvm/lib/Transforms/Scalar/InstructionCombining.cpp diff -u llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.172 llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.173 --- llvm/lib/Transforms/Scalar/InstructionCombining.cpp:1.172 Sat Mar 13 17:54:27 2004 +++ llvm/lib/Transforms/Scalar/InstructionCombining.cpp Fri Mar 19 00:08:10 2004 @@ -2367,11 +2367,13 @@ // Create and insert the replacement instruction... if (isa(AI)) - New = new MallocInst(NewTy, 0, AI.getName(), &AI); + New = new MallocInst(NewTy, 0, AI.getName()); else { assert(isa(AI) && "Unknown type of allocation inst!"); - New = new AllocaInst(NewTy, 0, AI.getName(), &AI); + New = new AllocaInst(NewTy, 0, AI.getName()); } + + InsertNewInstBefore(New, AI); // Scan to the end of the allocation instructions, to skip over a block of // allocas if possible... @@ -2387,9 +2389,15 @@ // Now make everything use the getelementptr instead of the original // allocation. - ReplaceInstUsesWith(AI, V); - return &AI; + return ReplaceInstUsesWith(AI, V); } + + // If alloca'ing a zero byte object, replace the alloca with a null pointer. + // Note that we only do this for alloca's, because malloc should allocate and + // return a unique pointer, even for a zero byte allocation. + if (isa(AI) && TD->getTypeSize(AI.getAllocatedType()) == 0) + return ReplaceInstUsesWith(AI, Constant::getNullValue(AI.getType())); + return 0; } From criswell at cs.uiuc.edu Fri Mar 19 09:14:06 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 09:14:06 2004 Subject: [llvm-commits] [release_12] CVS: llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp Message-ID: <200403191511.JAA05897@choi.cs.uiuc.edu> Changes in directory llvm/lib/Target/SparcV9: SparcV9InstrSelection.cpp updated: 1.137 -> 1.137.2.1 --- Log message: Merged in Chris's fix from trunk (revision 1.138). --- Diffs of the changes: (+7 -1) Index: llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp diff -u llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp:1.137 llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp:1.137.2.1 --- llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp:1.137 Fri Mar 12 18:23:46 2004 +++ llvm/lib/Target/SparcV9/SparcV9InstrSelection.cpp Fri Mar 19 09:11:25 2004 @@ -1156,11 +1156,17 @@ unsigned numElements, std::vector& getMvec) { - assert(tsize > 0 && "Illegal (zero) type size for alloca"); assert(result && result->getParent() && "Result value is not part of a function?"); Function *F = result->getParent()->getParent(); MachineFunction &mcInfo = MachineFunction::get(F); + + // If the alloca is of zero bytes (which is perfectly legal) we bump it up to + // one byte. This is unnecessary, but I really don't want to break any + // fragile logic in this code. FIXME. + if (tsize == 0) + tsize = 1; + // Put the variable in the dynamically sized area of the frame if either: // (a) The offset is too large to use as an immediate in load/stores From criswell at cs.uiuc.edu Fri Mar 19 10:48:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 10:48:02 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/cfrontend-1.2.i686-redhat-linux-gnu.tar.gz cfrontend-1.2.powerpc-apple-darwin7.3.0.tar.gz cfrontend-1.2.source.tar.gz cfrontend-1.2.sparc-sun-solaris2.8.tar.gz Message-ID: <200403191647.KAA29988@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: cfrontend-1.2.i686-redhat-linux-gnu.tar.gz added (r1.1) cfrontend-1.2.powerpc-apple-darwin7.3.0.tar.gz added (r1.1) cfrontend-1.2.source.tar.gz added (r1.1) cfrontend-1.2.sparc-sun-solaris2.8.tar.gz added (r1.1) --- Log message: CFE for LLVM 1.2, Release Candidate 1. --- Diffs of the changes: (+0 -0) Index: llvm-www/releases/1.2/cfrontend-1.2.i686-redhat-linux-gnu.tar.gz Index: llvm-www/releases/1.2/cfrontend-1.2.powerpc-apple-darwin7.3.0.tar.gz Index: llvm-www/releases/1.2/cfrontend-1.2.source.tar.gz Index: llvm-www/releases/1.2/cfrontend-1.2.sparc-sun-solaris2.8.tar.gz From criswell at cs.uiuc.edu Fri Mar 19 11:01:00 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:01:00 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/FAQ.html Message-ID: <200403191700.LAA06279@choi.cs.uiuc.edu> Changes in directory llvm/docs: FAQ.html updated: 1.19 -> 1.19.2.1 --- Log message: Added a remark about setting LLVM_LIB_SEARCH_PATH. I forgot to do this on PowerPC, and it made the test results scary. --- Diffs of the changes: (+28 -1) Index: llvm/docs/FAQ.html diff -u llvm/docs/FAQ.html:1.19 llvm/docs/FAQ.html:1.19.2.1 --- llvm/docs/FAQ.html:1.19 Fri Mar 12 12:20:15 2004 +++ llvm/docs/FAQ.html Fri Mar 19 11:00:35 2004 @@ -49,6 +49,8 @@
  • I've built LLVM and am testing it, but the tests freeze.
  • Why do test results differ when I perform different types of builds?
  • Compiling LLVM with GCC 3.3.2 fails, what should I do?
    • +
  • When I use the test suite, all of the C Backend tests fail. What is + wrong?
  • Using the GCC Front End @@ -338,6 +340,31 @@ affects projects other than LLVM. Try upgrading or downgrading your GCC.

    +
    +

    +When I use the test suite, all of the C Backend tests fail. What is +wrong? +

    +
    + +
    +

    +If you build LLVM and the C Backend tests fail in llvm/test/Programs, +then chances are good that the directory pointed to by the LLVM_LIB_SEARCH_PATH +environment variable does not contain the libcrtend.a library. +

    + +

    +To fix it, verify that LLVM_LIB_SEARCH_PATH points to the correct directory +and that libcrtend.a is inside. For pre-built LLVM GCC front ends, this +should be the absolute path to +cfrontend/<platform>/llvm-gcc/bytecode-libs. If you've +built your own LLVM GCC front end, then ensure that you've built and installed +the libraries in llvm/runtime and have LLVM_LIB_SEARCH_PATH pointing +to the LLVMGCCDIR/bytecode-libs subdirectory. +

    +
    +
    Using the GCC Front End @@ -456,7 +483,7 @@
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/12 18:20:15 $ + Last modified: $Date: 2004/03/19 17:00:35 $
    From criswell at cs.uiuc.edu Fri Mar 19 11:22:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:22:02 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/llvm-1.2.tar.gz Message-ID: <200403191721.LAA30241@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: llvm-1.2.tar.gz added (r1.1) --- Log message: LLVM 1.2, Release Candidate 1 --- Diffs of the changes: (+0 -0) Index: llvm-www/releases/1.2/llvm-1.2.tar.gz From criswell at cs.uiuc.edu Fri Mar 19 11:28:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:28:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/cfrontend-1.2.i686-redhat-linux-gnu.tar.gz cfrontend-1.2.powerpc-apple-darwin7.3.0.tar.gz cfrontend-1.2.sparc-sun-solaris2.8.tar.gz Message-ID: <200403191727.LAA30404@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: cfrontend-1.2.i686-redhat-linux-gnu.tar.gz updated: 1.1 -> 1.2 cfrontend-1.2.powerpc-apple-darwin7.3.0.tar.gz updated: 1.1 -> 1.2 cfrontend-1.2.sparc-sun-solaris2.8.tar.gz updated: 1.1 -> 1.2 --- Log message: LLVM 1.2 CFE, Release Candidate 2: Added bytecode-libs. :) --- Diffs of the changes: (+0 -0) Index: llvm-www/releases/1.2/cfrontend-1.2.i686-redhat-linux-gnu.tar.gz Index: llvm-www/releases/1.2/cfrontend-1.2.powerpc-apple-darwin7.3.0.tar.gz Index: llvm-www/releases/1.2/cfrontend-1.2.sparc-sun-solaris2.8.tar.gz From criswell at cs.uiuc.edu Fri Mar 19 11:37:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:37:02 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/announcement.txt Message-ID: <200403191736.LAA30565@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: announcement.txt updated: 1.1 -> 1.2 --- Log message: Updated for LLVM 1.2, but still needs more details, I think. --- Diffs of the changes: (+7 -10) Index: llvm-www/releases/1.2/announcement.txt diff -u llvm-www/releases/1.2/announcement.txt:1.1 llvm-www/releases/1.2/announcement.txt:1.2 --- llvm-www/releases/1.2/announcement.txt:1.1 Fri Mar 12 12:15:06 2004 +++ llvm-www/releases/1.2/announcement.txt Fri Mar 19 11:36:30 2004 @@ -9,7 +9,7 @@ LLVM is a new infrastructure designed for compile-time, link-time, runtime, and "idle-time" optimization of programs from arbitrary programming - languages. LLVM is written in C++ and has been developed over the past 3 + languages. LLVM is written in C++ and has been developed over the past 4 years at the University of Illinois. It currently supports compilation of C and C++ programs using front-ends derived from GCC 3.4. New front-ends are being written for Java bytecode and CAML. @@ -20,19 +20,16 @@ WHAT IS NEW IN LLVM 1.2? - This release is primarily a bugfix release, dramatically improving the C/C++ - front-end and improving support for C++ in the LLVM core. This release also - includes a few new features, such as a simple profiler, support for Mac OS X, - better interoperability with external source bases, a new example language - front-end, and improvements in a few optimizations. This release also - features several substantial speedups and implementation of missing features. + This release is primarily a bugfix release featuring several substantial + speedups and improvements in implementation. This release also includes a + new preliminary LLVM source level debugger and an experimental linear scan + register allocator. A full list of new features and bug-fixes are listed in the Release Notes: http://llvm.cs.uiuc.edu/releases/1.2/docs/ReleaseNotes.html#whatsnew - For an easier to read set of changes, please see the status updates: - http://mail.cs.uiuc.edu/pipermail/llvm-announce/2003-November/000003.html - http://mail.cs.uiuc.edu/pipermail/llvm-announce/2003-December/000004.html + For an easier to read set of changes, please see the status update: + http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-February/000005.html HOW DO I GET IT? From criswell at cs.uiuc.edu Fri Mar 19 11:38:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:38:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/ Message-ID: <200403191737.LAA30698@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs: --- Log message: Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.2/docs added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Fri Mar 19 11:38:06 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:38:06 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/CommandGuide/ Message-ID: <200403191737.LAA30828@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs/CommandGuide: --- Log message: Directory /home/vadve/shared/InternalCVS/llvm-www/releases/1.2/docs/CommandGuide added to the repository --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Fri Mar 19 11:39:02 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:39:02 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/CommandGuide/analyze.html bugpoint.html extract.html gccas.html gccld.html index.html llc.html lli.html llvm-as.html llvm-dis.html llvm-link.html llvm-nm.html llvm-prof.html llvmgcc.html llvmgxx.html opt.html Message-ID: <200403191738.LAA31278@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs/CommandGuide: analyze.html added (r1.1) bugpoint.html added (r1.1) extract.html added (r1.1) gccas.html added (r1.1) gccld.html added (r1.1) index.html added (r1.1) llc.html added (r1.1) lli.html added (r1.1) llvm-as.html added (r1.1) llvm-dis.html added (r1.1) llvm-link.html added (r1.1) llvm-nm.html added (r1.1) llvm-prof.html added (r1.1) llvmgcc.html added (r1.1) llvmgxx.html added (r1.1) opt.html added (r1.1) --- Log message: Initial commit of LLVM 1.2 documents. Now that I've got them committed, I'll find something wrong. :) --- Diffs of the changes: (+1970 -0) Index: llvm-www/releases/1.2/docs/CommandGuide/analyze.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/analyze.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/analyze.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,86 ---- + + + LLVM: analyze tool + + + + +

    LLVM: analyze tool

    +
    + +

    NAME

    + analyze + +

    SYNOPSIS

    + analyze [options] [filename] + +

    DESCRIPTION

    + + The analyze command performs various analysis of LLVM assembly code or + bytecode. It will usually print the results on standard output, but in a few + cases, it will print output to standard error or generate a file with the + analysis output (which is usually done when the output is meant for another + program). +

    + If filename is omitted or is -, analyze reads its input from standard + input. It first attempts to interpret its input as LLVM bytecode. If it + encounters an error, it then attempts to parse the input as LLVM assembly + language. + +

    OPTIONS

    + +
      +
    • -help +
      + Print a summary of command line options. +

      + +

    • -q +
      + Quiet mode. With this option, analysis pass names are not printed. +

      + +

    • -load <plugin> +
      + Load the specified dynamic object with name plugin. This file + should contain additional analysis passes that register themselves with + the analyze program after being loaded. +

      + + After being loaded, additional command line options are made available + for running the passes made available by plugin. Use + 'analyze -load <plugin> -help' to see the new + list of available analysis passes. +

      + +

    • -profile-info-file <filename> +
      + Specify the name of the file loaded by the -profile-loader option. +

      + +

    • -stats +
      + Print statistics. +

      + +

    • -time-passes +
      + Record the amount of time needed for each pass and print it to standard + error. +

      +

    + +

    EXIT STATUS

    + + If analyze succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

    SEE ALSO

    + + opt + +
    + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/bugpoint.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/bugpoint.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/bugpoint.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,250 ---- + + LLVM: bugpoint tool + + + +

    LLVM: bugpoint tool

    +
    + +

    NAME

    + bugpoint + +

    SYNOPSIS

    + bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args <program arguments>... + + +

    DESCRIPTION

    + + The bugpoint tool narrows down the source of + problems in LLVM tools and passes. It can be used to debug three types of + failures: optimizer crashes, miscompilations by optimizers, or invalid native + code generation. It aims to reduce large test cases to small, useful ones. + For example, + if gccas crashes while optimizing a file, it + will identify the optimization (or combination of optimizations) that causes the + crash, and reduce the file down to a small example which triggers the crash.

    + + +

    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 + passes and code generators, and does not need to "know" how they work. Because + of this, it may appear to do a lot of stupid things or miss obvious + simplifications. bugpoint is also designed to trade off programmer + time for computer time in the compiler-debugging process; consequently, it may + take a long period of (unattended) time to reduce a test case, but we feel it + is still worth it. :-)

    + + +

    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 program. If any LLVM passes are + specified on the command line, it runs these passes on the test program. If + any of the passes crash, or if they produce malformed output, + bugpoint starts the crash debugger.

    + + Otherwise, if the -output option was not + specified, bugpoint runs the test program with the C backend (which is + assumed to generate good code) to generate a reference output. Once + bugpoint has a reference output for the test program, it tries + executing it with the selected code generator. If the + selected code generator crashes, bugpoint starts the crash debugger on the code generator. Otherwise, if the + resulting output differs from the reference output, it assumes the difference + resulted from a code generator failure, and starts the code generator debugger.

    + + Finally, if the output of the selected code generator matches the reference + output, bugpoint runs the test program after all of the LLVM passes + have been applied to it. If its output differs from the reference output, it + assumes the difference resulted from a failure in one of the LLVM passes, and + enters the miscompilation + debugger. 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 the + test program. First, bugpoint figures out which combination of + optimizer passes triggers the bug. This is useful when debugging a problem + exposed by gccas, for example, because it runs over 25 + optimizations.

    + + Next, bugpoint tries removing functions from the test program, to + reduce its size. Usually it is able to reduce a test program to a single + function, when debugging intraprocedural optimizations. Once the number of + functions has been reduced, it attempts to delete various edges in the control + flow graph, to reduce the size of the function as much as possible. Finally, + bugpoint deletes any individual LLVM instructions whose absence does + not eliminate the failure. At the end, bugpoint should tell you what + passes crash, give you a bytecode file, and give you instructions on how to + reproduce the failure with opt, analyze, 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 test program and partitions it into two pieces: one piece + which it compiles with the C backend (into a shared object), and one piece which + it runs with either the JIT or the static LLC compiler. It uses several + techniques to reduce the amount of code pushed through the LLVM code generator, + to reduce the potential scope of the problem. After it is finished, it emits + two bytecode files (called "test" [to be compiled with the code generator] and + "safe" [to be compiled with the C backend] respectively), and instructions for + reproducing the problem. The code generator debugger assumes that the C + backend produces good code.

    + + If you are using the code generator debugger and get an error message that + says "UNSUPPORTED: external function used as a global initializer!", try using + the -run-llc option instead of the -run-jit option. This is + due to an unimplemented feature in the code generator debugger.

    + + +

    Miscompilation debugger

    + + The miscompilation debugger works similarly to the code generator + debugger. It works by splitting the test program into two pieces, running the + optimizations specified on one piece, linking the two pieces back together, + and then executing the result. + It attempts to narrow down the list of passes to the one (or few) which are + causing the miscompilation, then reduce the portion of the test program which is + being miscompiled. The miscompilation debugger assumes that the selected + code generator is working properly.

    + + +

    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:

    + +

      +
    1. In the code generator and miscompilation debuggers, bugpoint only + works with programs that have deterministic output. Thus, if the program + outputs the date, time, or any other "random" data, bugpoint may + misinterpret differences in these data, when output, as the result of a + miscompilation. Programs should be temporarily modified to disable + outputs that are likely to vary from run to run. + +
    2. In the code generator and miscompilation debuggers, debugging will go + faster if you manually modify the program or its inputs to reduce the + runtime, but still exhibit the problem. + +
    3. bugpoint is extremely useful when working on a new optimization: + it helps track down regressions quickly. To avoid having to relink + bugpoint every time you change your optimization however, have + bugpoint dynamically load your optimization with the -load option. + +
    4. bugpoint can generate a lot of output and run for a long period of + time. It is often useful to capture the output of the program to file. For + example, in the C shell, you can type:
      + bugpoint ..... |& tee bugpoint.log +
      to get a copy of bugpoint's output in the file + bugpoint.log, as well as on your terminal. + +
    5. bugpoint cannot debug problems with the linker. If + bugpoint crashes before you see its "All input ok" message, + you might try llvm-link -v on the same set of input files. If + that also crashes, you may be experiencing a linker bug. + +
    6. If your program is supposed to crash, bugpoint will be + confused. One way to deal with this is to cause bugpoint to ignore the exit + code from your program, by giving it the -check-exit-code=false + option. + +
    + +

    OPTIONS

    + + + +

    EXIT STATUS

    + + If bugpoint succeeds in finding a problem, it will exit with 0. + Otherwise, if an error occurs, it will exit with a non-zero value. + +

    SEE ALSO

    +     opt, + analyze + +
    + Maintained by the LLVM Team. + + Index: llvm-www/releases/1.2/docs/CommandGuide/extract.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/extract.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/extract.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,93 ---- + + + LLVM: extract tool + + + + +
    +

    LLVM: extract tool

    +
    +
    + +

    NAME

    + extract + +

    + SYNOPSIS +

    + + extract [options] [filename] +

    + DESCRIPTION +

    + + The extract command takes the name of a function and extracts it from + the specified LLVM bytecode file. It is primarily used as a debugging tool to + reduce test cases from larger programs that are triggering a bug. +

    + + In addition to extracting the bytecode of the specified function, + extract will also remove unreachable global variables, prototypes, and + unused types. +

    + + The extract command reads its input from standard input if filename is + omitted or if filename is -. The output is always written to standard output. + +

    OPTIONS

    + +
      +
        +
      • -f +
        + Force overwrite. Normally, extract will refuse to overwrite an + output file that already exists. With this option, extract + will overwrite the output file and replace it with new bytecode. +

        + +

      • -func <function> +
        + Extract the specified function from the LLVM bytecode. +

        + +

      • -help +
        + Print a summary of command line options. +

        + +

      • -o <filename> +
        + Specify the output filename. If filename is "-" (the default), then + extract sends its output to standard output. +

        + +

      • -stats +
        + Print statistics. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        +

      + +

      + EXIT STATUS +

      + + If extract succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

      + SEE ALSO +

      + bugpoint + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/gccas.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/gccas.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/gccas.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,90 ---- + + LLVM: gccas tool + + + +
      +

      LLVM: gccas tool

      +
      +
      + +

      NAME

      + gccas + +

      SYNOPSIS

      + gccas [options] < filename> + +

      DESCRIPTION

      + + The gccas utility takes an LLVM assembly file generated by the C or C++ frontends and + converts it into an LLVM bytecode file. It is primarily used by the GCC front + end, and as such, attempts to mimic the interface provided by the default system + assembler so that it can act as a "drop-in" replacement.

      + + gccas performs a number of optimizations on the input program.

      + +

      + OPTIONS +

      + +
        +
      • -help +
        + Print a summary of command line options. +

        + +

      • -o <filename> +
        + Specify the output filename which will hold the assembled bytecode. +

        + +

      • -disable-inlining +
        + Disable the inlining pass. By default, it is enabled. +

        + +

      • -disable-opt +
        + Disable all assemble-time optimization passes. +

        + +

      • -enable-correct-eh-support +
        + Instruct the -lowerinvoke pass to insert code for correct exception handling + support. This is expensive and is by default omitted for efficiency. +

        + +

      • -stats +
        + Print statistics. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        + +

      • -verify +
        + Verify each pass result. +

        +

      + +

      + EXIT STATUS +

      + + If gccas succeeds, it will exit with 0. Otherwise, if an error occurs, + it will exit with a non-zero value. + +

      SEE ALSO

      + llvm-as + gccld + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/gccld.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/gccld.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/gccld.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,201 ---- + + LLVM: gccld tool + + + +

      LLVM: gccld tool

      +
      + +

      NAME

      + gccld + +

      SYNOPSIS

      + gccld [options] < filename> [ filename ...] + +

      DESCRIPTION

      + + The gccld utility takes a set of LLVM bytecode files and links them + together into a single LLVM bytecode file. The output bytecode file can be + another bytecode library or an executable bytecode program. Using additional + options, gccld is able to produce native code executables. +

      + + The gccld utility is primarily used by the C + and C++ front-ends, and as such, attempts to mimic + the interface provided by the default system linker so that it can act as a + "drop-in" replacement. +

      + + The gccld tool performs a small set of interprocedural, post-link, + optimizations on the program. + + +

      Search Order

      + +

      + When looking for objects specified on the command line, gccld will + search for the object first in the current directory and then in the directory + specified by the LLVM_LIB_SEARCH_PATH environment variable. If it + cannot find the object, it fails. +

      + +

      + When looking for a library specified with the -l option, gccld first + attempts to load a file with that name from the current directory. If that + fails, it looks for lib<library>.bc, lib<library>.a, or + lib<library>.<shared library extension>, in that order, in each + directory added to the library search path with the -L option. These + directories are searched in the order they + were specified. If the library cannot be located, then gccld looks in + the directory specified by the LLVM_LIB_SEARCH_PATH environment + variable. If it does not find a library there, it fails. +

      + +

      + The shared library extension is usually .so, but it may differ + depending upon the system. +

      + +

      + The -L option is global. It does not matter where it is specified in the list + of command line arguments; the directory is simply added to the search path and + is applied to all libraries, preceding or succeeding, in the command line. +

      + +

      Link order

      + + All object files are linked first in the order they were specified on the + command line. All library files are linked next. Some libraries may not be + linked into the object program; see below. + +

      Library Linkage

      + + Object files and static bytecode objects are always linked into the output + file. Library archives (.a files) load only the objects within the archive + that define symbols needed by the output file. Hence, libraries should be + listed after the object files and libraries which need them; otherwise, the + library may not be linked in, and the dependent library will not have its + undefined symbols defined. + +

      Native code generation

      + + The gccld program has limited support for native code generation, when + using the -native option. + + +

      OPTIONS

      + +
        +
      • -help +
        + Print a summary of command line options. +

        + +

      • -o <filename> +
        + Specify the output filename which will hold the linked bytecode. +

        + +

      • -stats +
        + Print statistics. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        + +

      • -verify +
        + Verify each pass result. +

        + +

      • -disable-opt +
        + Disable all link-time optimization passes. +

        + +

      • -disable-inlining +
        + Do not run the inliner pass. +

        + +

      • -L=<directory> +
        + Add directory to the list of directories to search when looking for + libraries. +

        + +

      • -disable-internalize +
        + Do not mark all symbols as internal. +

        + +

      • -internalize-public-api-file <filename> +
        + Preserve the list of symbol names in the file filename. +

        + +

      • -internalize-public-api-list <list> +
        + Preserve the symbol names in list. +

        + +

      • -l=<library> +
        + Specify libraries to include when linking the output file. When + linking, gccld will first attempt to load a file with the + pathname library. If that fails, it will then attempt to load + lib<library>.bc, lib<library>.a, and + lib<library>.<shared library extension>, in that order. +

        + +

      • -link-as-library +
        + Link the .bc files together as a library, not an executable. +

        + +

      • -native +
        + Generate a native, machine code executable. +

        + When generating native executables, gccld first checks for a bytecode + version of the library and links it in, if necessary. If the library is + missing, gccld skips it. Then, gccld links in the same + libraries as native code. +

        + In this way, gccld should be able to link in optimized bytecode + subsets of common libraries and then link in any part of the library that + hasn't been converted to bytecode. +

        + +

      • -s +
        + Strip symbol information from the generated executable. +

        + +

      • -v +
        + Print information about actions taken. +
      + +

      EXIT STATUS

      + + If gccld succeeds, it will exit with 0. Otherwise, if an error occurs, + it will exit with a non-zero value. + +

      SEE ALSO

      + llvm-link + gccas + +

      BUGS

      + The -L option cannot be used for find native code libraries when using the + -native option. + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/index.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/index.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/index.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,123 ---- + + + + LLVM Command Guide + + + + +

      LLVM Command Guide

      + + This document is the reference manual for the LLVM utilities. It will + show you how to use the LLVM commands and what all of their options + are. + + +
      + + +

      Basic Commands

      + + +
      +
      llvm-as +
      + Assemble a human-readable LLVM program into LLVM bytecode. +

      + +

      llvm-dis +
      + Disassemble an LLVM bytecode file into human-readable form. +

      + +

      analyze +
      + Analyze an LLVM bytecode file. +

      + +

      opt +
      + Optimize an LLVM bytecode file. +

      + +

      llc +
      + Compile an LLVM bytecode program into native machine code. +

      + +

      lli +
      + Run an LLVM bytecode program using either an interpreter or a + JIT compiler. +

      + +

      llvm-link +
      + Link several LLVM bytecode files together into one LLVM + bytecode file. +

      + +

      llvm-nm +
      + Print out the names and types of symbols in an LLVM bytecode file. +

      + +

      llvm-prof +
      + Transform raw 'llvmprof.out' data into a human readable report. +

      +

      + +       		+ + +

      C and C++ Front-end Commands

      + + +
      +
      llvmgcc +
      + GCC-based C front end for LLVM. +

      + +

      llvmg++ +
      + GCC-based C++ front end for LLVM. +

      + +

      gccas +
      + LLVM assembler used by GCC and other native compiler tools. +

      + +

      gccld +
      + LLVM linker used by GCC and other native compiler tools. +
      + + +

      Debugging Tools

      + + +
      +
      bugpoint +
      + Trace an LLVM bytecode program and reduce its failure to a + simple testcase. +

      + +

      extract +
      + Extract a function from an LLVM bytecode file. +
      +
      + + +
      + Maintained by the + LLVM Team.
      + Last modified: $Date: 2004/03/19 17:38:13 $ +       + + + Index: llvm-www/releases/1.2/docs/CommandGuide/llc.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llc.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llc.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,220 ---- + + LLVM: llc tool + + + +

      LLVM: llc tool

      +
      + +

      NAME

      + llc + +

      SYNOPSIS

      + llc [options] [filename] + +

      DESCRIPTION

      + + The llc command compiles LLVM bytecode into assembly language for a + specified architecture. The assembly language output can then be passed through + a native assembler and linker to generate native code. +

      + The choice of architecture for the output assembly code is determined as + follows: + +

        +
      • + If the user has specified an architecture with the -m option, use that + architecture. +

        + +

      • + Examine the input LLVM bytecode file: +
          +
        • + If it specifies little endian and a pointer size of 32 bits, select the + x86 architecture. +

          + +

        • + If it specifies big endian and a pointer size of 64 bit pointers, + select the SparcV9 architecture. +
        +

        + +

      • + If llc was compiled on an architecture for which it can + generate code, select the architecture upon which llc was + compiled. +

        + +

      • + Print a message to the user asking him or her to specify the output + architecture explicitly. +
      + +

      + + If filename is not specified, or if filename is -, llc reads its input + from standard input. Otherwise, it will read its input from filename. +

      + + If the -o option is left unspecified, then llc will send its output to standard + output if the input is from standard input. If the -o option specifies -, then + the output will also be sent to standard output. +

      + + If no -o option is specified and an input file other than - is specified, then + llc creates the output filename as follows: + +

        +
      • + If the file ends in .bc, then the .bc suffix is removed, and the .s suffix + is appended. +

        +

      • + Otherwise, the .s suffix is appended to the input filename. +
      + +

      + OPTIONS +

      +
        +
      • -f +
        + Overwrite output files +

        + +

      • -m<arch> +
        + Specify the architecture for which to generate assembly. Valid + architectures are: + +
        +
        x86
        +
        IA-32 (Pentium and above)
        + +
        sparcv9
        +
        SPARC V9
        + +
        c
        +
        Emit C code
        +
        +

        + +

      • -o <filename> +
        + Specify the output filename. +

        + +

      • -enable-correct-eh-support +
        + Instruct the -lowerinvoke pass to insert code for correct exception handling + support. This is expensive and is by default omitted for efficiency. +

        + +

      • -help +
        + Print a summary of command line options. +

        + +

      • -stats +
        + Print statistics. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        + +

      +

      X86 Specific Options

      +
        +
      • -disable-fp-elim +
        + Disable frame pointer elimination optimization. +

        + +

      • -disable-pattern-isel +
        + Use the 'simple' X86 instruction selector (the default). +

        + +

      • -print-machineinstrs +
        + Print generated machine code. +

        + +

      • -regalloc=<ra> +
        + Specify the register allocator to use. The default is local. + Valid register allocators are: +

        +

        +
        simple
        +
        Very simple register allocator
        + +
        local
        +
        Local register allocator
        + +
        linearscan
        +
        Linear scan global register allocator (experimental)
        +
        + +
      • -spiller=<sp> +
        + Specify the spiller to use for register allocators that support it. + Currently this option is used by the linear scan register + allocator. The default is local. + Valid spillers are: +

        +

        +
        simple
        +
        Simple spiller
        + +
        local
        +
        Local spiller
        +
        + +
      + +

      Sparc Specific Options

      +
        +
      • -disable-peephole +
        + Disable peephole optimization pass. +

        + +

      • -disable-sched +
        + Disable local scheduling pass. +

        + +

      • -disable-strip +
        + Do not strip the LLVM bytecode included in executable. +

        + +

      • -enable-maps +
        + Emit LLVM-to-MachineCode mapping info to assembly. +

        +

      + + +

      EXIT STATUS

      + + If llc succeeds, it will exit with 0. Otherwise, if an error occurs, + it will exit with a non-zero value. + +

      + SEE ALSO +

      + lli + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/lli.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/lli.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/lli.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,107 ---- + + + LLVM: lli tool + + + + +
      +

      LLVM: lli tool

      +
      +
      + +

      + NAME +

      + + lli + +

      + SYNOPSIS +

      + + lli [options] [filename] [args ...] +

      + DESCRIPTION +

      + + lli directly executes programs in LLVM format. + It takes a program in LLVM + bytecode format and executes it using a just-in-time + compiler, if one is available for the current architecture, or an interpreter. + lli takes all of the same code generator options as the + llc tool, but they are only applicable when + the just-in-time compiler is being used. +

      + + If filename is not specified, then lli reads the LLVM bytecode for + the program from standard input. +

      + The optional "args" specified on the command line are passed to the + program as arguments. +

      + + +

      + OPTIONS +

      + +
        +
      • -help +
        + Print a summary of command line options. +

        + +

      • -stats +
        + Print statistics from the code-generation passes. This is only meaningful + for the just-in-time compiler, at present. +

        + +

      • -time-passes +
        + Record the amount of time needed for each code-generation pass and print + it to standard error. +

        + +

      • -march=<arch> +
        + Use the specified non-default architecture when selecting a code generator + for the just-in-time compiler. This may result in a crash if you pick an + architecture which is not compatible with the hardware you are running + lli on. +

        + +

      • -force-interpreter={false,true} +
        + If set to true, use the interpreter even if a just-in-time compiler is + available for this architecture. Defaults to false. +

        + +

      • -f=<name> +
        + Call the function named <name> to start the program. + Note: The function is assumed to have the C signature int + <name> (int, char **, char **). + If you try to use this option to call a function of incompatible type, + undefined behavior may result. Defaults to "main". +

        + +

      + +

      + EXIT STATUS +

      + + If lli fails to load the program, it will exit with an exit code of 1. + Otherwise, it will return the exit code of the program it executes. + +

      + SEE ALSO +

      + llc + +
      + Maintained by the LLVM Team. + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvm-as.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvm-as.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvm-as.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,97 ---- + + + LLVM: llvm-as tool + + + + +

      LLVM: llvm-as tool

      +
      + +

      NAME

      + llvm-as + +

      SYNOPSIS

      + llvm-as [options] [filename] + +

      DESCRIPTION

      + + The llvm-as command is the LLVM assembler. It reads a file containing + human readable LLVM assembly language, translates it to LLVM bytecode, and + writes the result into a file or to standard output. +

      + + If filename is omitted or is -, then llvm-as reads its input from + standard input. +

      + + If an output file is not specified with the -o option, then + llvm-as sends its output to a file or standard output by the following + logic: + +

        +
      • + If the input is standard input, then the output is standard output. +

        + +

      • + If the input is a file that ends with .ll, then the output file is of + the same name, except that the suffix is changed to .bc. +

        + +

      • + If the input is a file that does not end with the .ll suffix, then the + output file has the same name as the input file, except that the .bc + suffix is appended. +

        +

      + +

      OPTIONS

      + +
        +
      • -f +
        + Force overwrite. Normally, llvm-as will refuse to overwrite an + output file that already exists. With this option, llvm-as + will overwrite the output file and replace it with new bytecode. +

        + +

      • -help +
        + Print a summary of command line options. +

        + +

      • -o <filename> +
        + Specify the output filename. If filename is -, then llvm-as + sends its output to standard output. +

        + +

      • -stats +
        + Print statistics. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        +

      + +

      EXIT STATUS

      + + If llvm-as succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

      SEE ALSO

      + + llvm-dis + gccas + + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvm-dis.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvm-dis.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvm-dis.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,94 ---- + + + LLVM: llvm-dis tool + + + + +

      LLVM: llvm-dis tool

      +
      + +

      NAME

      + llvm-dis + +

      SYNOPSIS

      + llvm-dis [options] [filename] + +

      DESCRIPTION

      + + The llvm-dis command is the LLVM disassembler. It takes an LLVM + bytecode file and converts it into LLVM assembly language or C source code with + equivalent functionality. +

      + + If filename is omitted, llvm-dis reads its input from standard input. +

      + + The default output file for llvm-dis is determined by the following logic: +

        +
      • + If the input is standard input or the file -, then the output is + standard output. +

        + +

      • + If the input filename ends in .bc, then the output filename will be + identical, except that the .bc suffix will be replaced by the .ll or .c + suffix (for LLVM assembly language and C code, respectively). +

        + +

      • + If the input filename does not end in .bc, then the output filename will + be identical to the input filename, except that the .ll or .c suffix + will be appended to the filename (for LLVM assembly language and C code, + respectively). +
      + +

      OPTIONS

      + +
        +
      • -llvm +
        + Instruct llvm-dis to generate LLVM assembly code in human + readable format. This is the default behavior. +

        + +

      • -f +
        + Force overwrite. Normally, llvm-dis will refuse to overwrite + an output file that already exists. With this option, llvm-dis + will overwrite the output file. +

        + +

      • -help +
        + Print a summary of command line options. +

        + +

      • -o <filename> +
        + Specify the output filename. If filename is -, then the output is sent + to standard output. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        +

      + +

      EXIT STATUS

      + + If llvm-dis succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

      SEE ALSO

      + + llvm-as + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvm-link.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvm-link.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvm-link.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,88 ---- + + + LLVM: llvm-link tool + + + + +

      LLVM: llvm-link tool

      +
      + +

      NAME

      + llvm-link + +

      SYNOPSIS

      + llvm-link [options] <filename> [filename ...] + +

      DESCRIPTION

      + + The llvm-link command takes several LLVM bytecode files and links them + together into a single LLVM bytecode file. It writes the output file to + standard output, unless the -o option is used to specify a filename. +

      + + The llvm-link command attempts to load the input files from the current + directory. If that fails, it looks for each file in each of the + directories specified by the -L options on the command line. The library search + paths are global; each one is searched for every input file if necessary. The + directories are searched in the order they were specified on the command line. + +

      + OPTIONS +

      + +
        +
      • -L <directory> +
        + Add the specified directory to the library search path. When looking + for libraries, llvm-link will look in pathname for libraries. + This option can be specified multiple times; llvm-link will + search inside these directories in the order in which they were + specified on the command line. +

        + +

      • -f +
        + Overwrite output files. By default, llvm-link will not + overwrite an output file if it alreadys exists. +

        + +

      • -o <filename> +
        + Output filename. If filename is -, then llvm-link will write + its output to standard output. +

        + +

      • -d +
        + If specified, llvm-link prints a human-readable version of the + output bytecode file to standard error. +

        + +

      • -help +
        + Print a summary of command line options. +

        + +

      • -v +
        + Verbose mode. Print information about what llvm-link is doing. + This typically includes a message for each bytecode file linked in + and for each library found. +
      + +

      + EXIT STATUS +

      + + If llvm-link succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

      SEE ALSO

      + gccld + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvm-nm.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvm-nm.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvm-nm.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,118 ---- + + + LLVM: llvm-nm tool + + + + +

      LLVM: llvm-nm tool

      +
      + +

      NAME

      + llvm-nm + +

      SYNOPSIS

      + llvm-nm [options] [filenames...] + +

      DESCRIPTION

      + +

      The llvm-nm utility lists the names of symbols from the + LLVM bytecode files, or ar(1) archives containing LLVM + bytecode files, named on the command line. Each symbol is listed along + with some simple information about its provenance. If no filename is specified, + or - is used as a filename, llvm-nm will process a bytecode file + on its standard input stream.

      + +

      llvm-nm's default output format is the traditional BSD + nm(1) output format. Each such output record consists of an + (optional) 8-digit hexadecimal address, followed by a type code + character, followed by a name, for each symbol. One record is printed + per line; fields are separated by spaces. When the address is omitted, + it is replaced by 8 spaces.

      + +

      Type code characters currently supported, and their meanings, are + as follows:

      + + + + + + + + + + +
      UNamed object is referenced but undefined in this + bytecode file
      CCommon (multiple defs link together into one + def)
      WWeak reference (multiple defs link together into zero or + one defs)
      tLocal function (text) object
      TGlobal function (text) object
      dLocal data object
      DGlobal data object
      ?Something unrecognizable
      + +

      Because LLVM bytecode files typically contain objects that are not + considered to have addresses until they are linked into an executable + image or dynamically compiled "just-in-time", llvm-nm does + not print an address for any symbol, even symbols which are defined in + the bytecode file.

      + +

      OPTIONS

      + +
        +
      • -P +
        + Use POSIX.2 output format. Alias for --format=posix. +

        +

      • -B (default) +
        + Use BSD output format. Alias for --format=bsd. +

        + +

      • -help +
        + Print a summary of command-line options and their meanings. +

        + +

      • -defined-only +
        + Print only symbols defined in this bytecode file (as opposed + to symbols which may be referenced by objects in this file, + but not defined in this file.) +

        + +

      • -extern-only, -g +
        + Print only symbols whose definitions are external; that is, + accessible from other bytecode files. +

        + +

      • -undefined-only, -u +
        + Print only symbols referenced but not defined in this bytecode + file. +

        + +

      • -format=fmt, -f +
        + Select an output format; fmt may be sysv, posix, or + bsd. The default is bsd. +

        +

      + +

      BUGS

      + + llvm-nm cannot demangle C++ mangled + names, like GNU nm(1) can. + +

      EXIT STATUS

      + + llvm-nm exits with an exit code of zero. + +

      SEE ALSO

      + + llvm-dis, + ar(1), + nm(1) + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvm-prof.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvm-prof.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvm-prof.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,58 ---- + + LLVM: llvm-prof tool + + + +

      LLVM: llvm-prof tool

      +
      + +

      NAME

      + llvm-prof + +

      SYNOPSIS

      + llvm-prof [options] [bytecode file] [llvmprof.out] + +

      DESCRIPTION

      + + The llvm-prof tool reads in an 'llvmprof.out' file (which can + optionally use a specific file with the third program argument), a bytecode file + for the program, and produces a human readable report, suitable for determining + where the program hotspots are.

      + + This program is often used in conjunction with the utils/profile.pl + script. This script automatically instruments a program, runs it with the JIT, + then runs llvm-prof to format a report. To get more information about + utils/profile.pl, execute it with the --help option.

      + +

      OPTIONS

      + +
        +
      • --annotated-llvm or -A
        + + In addition to the normal report printed, print out the code for the + program, annotated with execution frequency information. This can be + particularly useful when trying to visualize how frequently basic blocks + are executed. This is most useful with basic block profiling + information or better.

        + +

      • --print-all-code
        + + Using this option enables the --annotated-llvm option, but it + prints the entire module, instead of just the most commonly executed + functions.

        + +

      • -time-passes
        + + Record the amount of time needed for each pass and print it to standard + error. +
      + +

      EXIT STATUS

      + + llvm-prof returns 1 if it cannot load the bytecode file or the profile + information. Otherwise, it exits with zero. + +
      + Maintained by the LLVM Team. + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvmgcc.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvmgcc.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvmgcc.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,113 ---- + + + LLVM: llvmgcc tool + + + + +
      +

      LLVM: llvmgcc tool

      +
      +
      + +

      NAME

      + llvmgcc + +

      + SYNOPSIS +

      + + llvmgcc [options] filename +

      + DESCRIPTION +

      + + The llvmgcc command is the LLVM C front end. It is a modified version + of the GNU Compiler Collection (GCC) that takes + C programs and compiles them into LLVM bytecode or assembly language, depending + upon the options. +

      + + Unless the -S option is specified, llvmgcc will use the + gccas program to perform some optimizations + and create an LLVM bytecode file. Unless the -c option is specified, + llvmgcc will also use the gccld + program to perform further optimizations and link the resulting bytecode + file(s) with support libraries to create an executable program. +

      + + Being derived from GCC, llvmgcc has many of GCC's features and accepts most of + GCC's options. It handles a number of GCC's extensions to the C programming + language. +

      + + Below you will find several commonly used options: + +

      + OPTIONS +

      + +
        +
      • -S +
        + Do not generate an LLVM bytecode file. Rather, compile the source file + into an LLVM assembly language file. +

        + +

      • -c +
        + Do not generate a linked bytecode executable. Rather, compile the source + file into an LLVM bytecode file. This bytecode file can then be linked + with other bytecode files later to generate a full LLVM executable. +

        + +

      • -o filename +
        + Specify the output file to be filename. +

        + +

      • -I directory +
        + Add a directory to the header file search path. This option can be + repeated. +

        + +

      • -L directory +
        + Add directory to the library search path. This option can be + repeated. +

        + +

      • -lname +
        + Link in the library libname.[bc | a | so]. This library should + be a bytecode library. +

        + +

      • -Wl,option +
        + Pass option to the linker program, gccld. +

        +

      + +

      + EXIT STATUS +

      + + If llvmgcc succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

      + SEE ALSO +

      + llvmg++, + gccas, + gccld, + and the Info documentation for gcc. + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/llvmgxx.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/llvmgxx.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/llvmgxx.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,107 ---- + + + LLVM: llvmg++ tool + + + + +
      +

      LLVM: llvmg++ tool

      +
      +
      + +

      NAME

      + llvmg++ + +

      SYNOPSIS

      + llvmg++ [options] filename + +

      DESCRIPTION

      + + The llvmg++ command is the LLVM C++ front end. It is a modified + version of g++ that takes C++ programs and compiles them into LLVM bytecode or + assembly language, depending upon the options. +

      + + Unless the -S option is specified, llvmg++ will use the + gccas program to perform some optimizations + and create an LLVM bytecode file. Unless the -c option is specified, + llvmg++ will also use the gccld + program to perform further optimizations and link the resulting bytecode + file(s) with support libraries to create an executable program. +

      + + Being derived from the GNU Compiler Collection, + llvmg++ has many of g++'s features and accepts most of g++'s options. + It handles a number of g++'s extensions to the C++ programming language. +

      + + Below you will find several commonly used options: + +

      + OPTIONS +

      + +
        +
      • -S +
        + Do not generate an LLVM bytecode file. Rather, compile the source file + into an LLVM assembly language file. +

        + +

      • -c +
        + Do not generate a linked executable. Rather, compile the source file + into an LLVM bytecode file. This bytecode file can then be linked with + other bytecode files later on to generate a full LLVM executable. +

        + +

      • -o filename +
        + Specify the output file to be filename. +

        + +

      • -I directory +
        + Add a directory to the header file search path. This option can be + repeated. +

        + +

      • -L directory +
        + Add directory to the library search path. This option can be + repeated. +

        + +

      • -lname +
        + Link in the library libname.[bc | a | so]. This library should + be a bytecode library. +

        + +

      • -Wl,option +
        + Pass option to the linker (usually gccld). +

        + +

      + +

      + EXIT STATUS +

      + + If llvmg++ succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + +

      + SEE ALSO +

      + llvmg++, + gccas, + gccld + +
      + Maintained by the LLVM Team. + + + Index: llvm-www/releases/1.2/docs/CommandGuide/opt.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandGuide/opt.html:1.1 *** /dev/null Fri Mar 19 11:38:23 2004 --- llvm-www/releases/1.2/docs/CommandGuide/opt.html Fri Mar 19 11:38:13 2004 *************** *** 0 **** --- 1,125 ---- + + LLVM: opt tool + + + +

      LLVM: opt tool

      +
      + +

      NAME

      + opt + +

      SYNOPSIS

      + opt [options] [filename] + +

      DESCRIPTION

      + + The opt command is the modular LLVM optimizer. It takes LLVM bytecode + as input, runs the specified optimizations on it, and then outputs the optimized + LLVM bytecode. +

      + + The optimizations available via opt depend upon what libraries were + linked into it as well as any additional libraries that have been loaded with + the -load option. Use the -help option to determine what + optimizations you can use. +

      + + If no filename is specified on the command line, opt reads its input + from standard input. +

      + + If an output filename is not specified with the -o option, opt + writes its output to the standard output. + + +

      OPTIONS

      + +
        +
      • -f +
        + Force overwrite. Normally, opt will refuse to overwrite an + output file that already exists. With this option, opt will + overwrite the output file and replace it with new bytecode. +

        + +

      • -help +
        + Print a summary of command line options. +

        + +

      • -o <filename> +
        + Specify the output filename. +

        + +

      • -profile-info-file <filename> +
        + Specify the name of the file loaded by the -profile-loader option. +

        + +

      • -stats +
        + Print statistics. +

        + +

      • -time-passes +
        + Record the amount of time needed for each pass and print it to standard + error. +

        + +

      • -debug +
        + If this is a debug build, this option will enable debug printouts from + passes which use the DEBUG macro. See the Programmer's Manual for more + information. +

        + + +

      • -q +
        + Quiet mode. Do not print messages on whether the program was modified. +

        + +

      • -load <plugin> +
        + Load the dynamic object <plugin>. This object should register new + optimization passes. Once loaded, the object will add new command line + options to enable various optimizations. To see the new complete list + of optimizations, use the -help and -load options together: +

        + opt -load <plugin> -help +

        + +

      • -p +
        + Print module after each transformation. +

        +

      + +

      EXIT STATUS

      + + If opt succeeds, it will exit with 0. Otherwise, if an error occurs, + it will exit with a non-zero value. + +

      SEE ALSO

      + + analyze + +
      + Maintained by the LLVM Team. + + + From criswell at cs.uiuc.edu Fri Mar 19 11:39:12 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 11:39:12 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/AliasAnalysis.html CFEBuildInstrs.html CodingStandards.html CommandLine.html Debugging.gif FAQ.html GettingStarted.html HowToSubmitABug.html LLVMVsTheWorld.html LangRef.html Makefile ObjectFiles.html OpenProjects.html ProgrammersManual.html Projects.html RegisterAllocatorInfo.txt ReleaseNotes.html SourceLevelDebugging.html Stacker.html TableGenFundamentals.html TestingGuide.html WritingAnLLVMPass.html doxygen.cfg doxygen.css doxygen.footer doxygen.header doxygen.intro index.html llvm.css venusflytrap.jpg Message-ID: <200403191738.LAA31241@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs: AliasAnalysis.html added (r1.1) CFEBuildInstrs.html added (r1.1) CodingStandards.html added (r1.1) CommandLine.html added (r1.1) Debugging.gif added (r1.1) FAQ.html added (r1.1) GettingStarted.html added (r1.1) HowToSubmitABug.html added (r1.1) LLVMVsTheWorld.html added (r1.1) LangRef.html added (r1.1) Makefile added (r1.1) ObjectFiles.html added (r1.1) OpenProjects.html added (r1.1) ProgrammersManual.html added (r1.1) Projects.html added (r1.1) RegisterAllocatorInfo.txt added (r1.1) ReleaseNotes.html added (r1.1) SourceLevelDebugging.html added (r1.1) Stacker.html added (r1.1) TableGenFundamentals.html added (r1.1) TestingGuide.html added (r1.1) WritingAnLLVMPass.html added (r1.1) doxygen.cfg added (r1.1) doxygen.css added (r1.1) doxygen.footer added (r1.1) doxygen.header added (r1.1) doxygen.intro added (r1.1) index.html added (r1.1) llvm.css added (r1.1) venusflytrap.jpg added (r1.1) --- Log message: Initial commit of LLVM 1.2 documents. Now that I've got them committed, I'll find something wrong. :) --- Diffs of the changes: (+17989 -0) Index: llvm-www/releases/1.2/docs/AliasAnalysis.html diff -c /dev/null llvm-www/releases/1.2/docs/AliasAnalysis.html:1.1 *** /dev/null Fri Mar 19 11:38:21 2004 --- llvm-www/releases/1.2/docs/AliasAnalysis.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,520 ---- + + + + Alias Analysis Infrastructure in LLVM + + + + +
      + Alias Analysis Infrastructure in LLVM +
      + +
        +
      1. Introduction
        2. + +
      2. AliasAnalysis Overview +
        3. + +
      3. Writing a new AliasAnalysis Implementation +
        4. + +
      4. Using AliasAnalysis results +
        5. + +
      5. Helpful alias analysis related tools +
        6. +
      + +
      +

      Written by Chris Lattner

      +
      + + +
      + Introduction +
      + + +
      + +

      Alias Analysis (or Pointer Analysis) is a technique which attempts to + determine whether or not two pointers ever can point to the same object in + memory. Traditionally, Alias Analyses respond to a query with either a Must, May, or No alias response, indicating that two + pointers do point to the same object, might point to the same object, or are + known not to point to the same object.

      + +

      The AliasAnalysis class is the + centerpiece of the LLVM Alias Analysis related infrastructure. This class is + the common interface between clients of alias analysis information and the + implementations providing it. In addition to simple alias analysis information, + this class exposes Mod/Ref information from those implementations which can + provide it, allowing for powerful analyses and transformations to work well + together.

      + +

      This document contains information necessary to successfully implement this + interface, use it, and to test both sides. It also explains some of the finer + points about what exactly results mean. If you feel that something is unclear + or should be added, please let me + know.

      + +
      + + +
      + AliasAnalysis Overview +
      + + +
      + +

      The AliasAnalysis class + defines the interface that Alias Analysis implementations should support. This + class exports two important enums: AliasResult and + ModRefResult which represent the result of an alias query or a mod/ref + query, respectively.

      + +

      The AliasAnalysis interface exposes information about memory, represented in + several different ways. In particular, memory objects are represented as a + starting address and size, and function calls are represented as the actual + call or invoke instructions that performs the call. The + AliasAnalysis interface also exposes some helper methods which allow you to get + mod/ref information for arbitrary instructions.

      + +
      + + +
      + Representation of Pointers +
      + +
      + +

      Most importantly, the AliasAnalysis class provides several methods which are + used to query whether or not pointers alias, whether function calls can modify + or read memory, etc.

      + +

      Representing memory objects as a starting address and a size is critically + important for precise Alias Analyses. For example, consider this (silly) C + code:

      + + 
      +   int i;
+   char C[2];
+   char A[10]; 
+   /* ... */
+   for (i = 0; i != 10; ++i) {
+     C[0] = A[i];          /* One byte store */
+     C[1] = A[9-i];        /* One byte store */
+   }
+
      + +

      In this case, the basicaa pass will disambiguate the stores to + C[0] and C[1] because they are accesses to two distinct + locations one byte apart, and the accesses are each one byte. In this case, the + LICM pass can use store motion to remove the stores from the loop. In + constrast, the following code:

      + + 
      +   int i;
+   char C[2];
+   char A[10]; 
+   /* ... */
+   for (i = 0; i != 10; ++i) {
+     ((short*)C)[0] = A[i];  /* Two byte store! */
+     C[1] = A[9-i];          /* One byte store */
+   }
+
      + +

      In this case, the two stores to C do alias each other, because the access to + the &C[0] element is a two byte access. If size information wasn't + available in the query, even the first case would have to conservatively assume + that the accesses alias.

      + +
      + + +
      + Must, May, and No Alias Responses +
      + +
      + +

      An Alias Analysis implementation can return one of three responses: + MustAlias, MayAlias, and NoAlias. The No and May alias results are obvious: if + the two pointers may never equal each other, return NoAlias, if they might, + return MayAlias.

      + +

      The Must Alias response is trickier though. In LLVM, the Must Alias response + may only be returned if the two memory objects are guaranteed to always start at + exactly the same location. If two memory objects overlap, but do not start at + the same location, MayAlias must be returned.

      + +
      + + +
      + The getModRefInfo methods +
      + +
      + +

      The getModRefInfo methods return information about whether the + execution of an instruction can read or modify a memory location. Mod/Ref + information is always conservative: if an action may read a location, Ref + is returned.

      + +
      + + +
      + 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 + for examples, and the following information should help fill in any details. + For a minimal example, take a look at the no-aa implementation.

      + +
      + + +
      + Different Pass styles +
      + +
      + +

      The first step to determining what type of LLVM pass you need to use for your Alias + Analysis. As is the case with most other analyses and transformations, the + answer should be fairly obvious from what type of problem you are trying to + solve:

      + +
        +
      1. If you require interprocedural analysis, it should be a + Pass.
        2. +
      2. If you are a global analysis, subclass FunctionPass.
        3. +
      3. If you are a local pass, subclass BasicBlockPass.
        4. +
      4. If you don't need to look at the program at all, subclass + ImmutablePass.
        5. +
      + +

      In addition to the pass that you subclass, you should also inherit from the + AliasAnalysis interface, of course, and use the + RegisterAnalysisGroup template to register as an implementation of + AliasAnalysis.

      + +
      + + +
      + Required initialization calls +
      + +
      + +

      Your subclass of AliasAnalysis is required to invoke two methods on the + AliasAnalysis base class: getAnalysisUsage and + InitializeAliasAnalysis. In particular, your implementation of + getAnalysisUsage should explicitly call into the + AliasAnalysis::getAnalysisUsage method in addition to doing any + declaring any pass dependencies your pass has. Thus you should have something + like this:

      + + 
      +     void getAnalysisUsage(AnalysisUsage &AU) const {
+       AliasAnalysis::getAnalysisUsage(AU);
+       // declare your dependencies here.
+     }
+
      + +

      Additionally, your must invoke the InitializeAliasAnalysis method + from your analysis run method (run for a Pass, + runOnFunction for a FunctionPass, runOnBasicBlock for + a BasicBlockPass, or InitializeAliasAnalysis for an + ImmutablePass). For example (as part of a Pass):

      + + 
      +     bool run(Module &M) {
+       InitializeAliasAnalysis(this);
+       // Perform analysis here...
+       return false;
+     }
+
      + +
      + + +
      + Interfaces which may be specified +
      + +
      + +

      All of the AliasAnalysis + virtual methods default to providing conservatively correct information + (returning "May" Alias and "Mod/Ref" for alias and mod/ref queries + respectively). Depending on the capabilities of the analysis you are + implementing, you just override the interfaces you can improve.

      + +
      + + +
      + The AliasAnalysis chaining behavior +
      + +
      + +

      With only two special exceptions (the basicaa and no-aa passes) every alias analysis pass should chain + to another alias analysis implementation (for example, you could specify + "-basic-aa -ds-aa -andersens-aa -licm" to get the maximum benefit from + the three alias analyses). To do this, simply "Require" AliasAnalysis in your + getAnalysisUsage method, and if you need to return a conservative + MayAlias or Mod/Ref result, simply chain to a lower analysis.

      + +
      + + +
      + 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 + serviced quickly. The actual calculation of the alias analysis results (the + "run" method) is only performed once, but many (perhaps duplicate) queries may + be performed. Because of this, try to move as much computation to the run + method as possible (within reason).

      + +
      + + +
      + Using AliasAnalysis results +
      + + +
      + +

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

      + +
      + + +
      + Using the -load-vn Pass +
      + +
      + +

      The load-vn pass uses alias analysis to provide value numbering + information for load instructions. If your analysis or transformation + can be modelled in a form that uses value numbering information, you don't have + to do anything special to handle load instructions: just use the + load-vn pass, which uses alias analysis.

      + +
      + + +
      + Using the AliasSetTracker class +
      + +
      + +

      Many transformations need information about alias sets that are active + in some scope, rather than information about pairwise aliasing. The AliasSetTracker class is used + to efficiently build these Alias Sets from the pairwise alias analysis + information provided by the AliasAnalysis interface.

      + +

      First you initialize the AliasSetTracker by use the "add" methods to + add information about various potentially aliasing instructions in the scope you + are interested in. Once all of the alias sets are completed, your pass should + simply iterate through the constructed alias sets, using the AliasSetTracker + begin()/end() methods.

      + +

      The AliasSets formed by the AliasSetTracker are guaranteed + to be disjoint, calculate mod/ref information and volatility for the set, and + keep track of whether or not all of the pointers in the set are Must aliases. + The AliasSetTracker also makes sure that sets are properly folded due to call + instructions, and can provide a list of pointers in each set.

      + +

      As an example user of this, the Loop + Invariant Code Motion pass uses AliasSetTrackers to build alias information + about each loop nest. If an AliasSet in a loop is not modified, then all load + instructions from that set may be hoisted out of the loop. If any alias sets + are stored and are must alias sets, then the stores may be sunk to + outside of the loop, promoting the memory location to a register for the + duration of the loop nest. Both of these transformations obviously only apply + if the pointer argument is loop-invariant.

      + +
      + +
      + 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 + inserted into the AliasSetTracker that aliases multiple sets. The primary data + structure is a hash table mapping pointers to the AliasSet they are in.

      + +

      The AliasSetTracker class must maintain a list of all of the LLVM Value*'s + that are in each AliasSet. Since the hash table already has entries for each + LLVM Value* of interest, the AliasesSets thread the linked list through these + hash-table nodes to avoid having to allocate memory unnecessarily, and to make + merging alias sets extremely efficient (the linked list merge is constant time). +

      + +

      You shouldn't need to understand these details if you are just a client of + the AliasSetTracker, but if you look at the code, hopefully this brief + description will help make sense of why things are designed the way they + are.

      + +
      + + + +
      + Using the AliasAnalysis interface directly +
      + +
      + +

      As a last resort, your pass could use the AliasAnalysis interface directly to + service your pass. If you find the need to do this, please let me know so I can see if something new + needs to be added to LLVM.

      + +
      + + +
      + Helpful alias-analysis-related tools +
      + + +
      + +

      If you're going to be working with the AliasAnalysis infrastructure, there + are several nice tools that may be useful for you and are worth knowing + about...

      + +
      + + +
      + The -no-aa pass +
      + +
      + +

      The -no-aa analysis is just like what it sounds: an alias analysis + that never returns any useful information. This pass can be useful if you think + that alias analysis is doing something wrong and are trying to narrow down a + problem. If you don't specify an alias analysis, the default will be to use the + basicaa pass which does quite a bit of disambiguation on its own.

      + +
      + + + +
      + The -print-alias-sets pass +
      + +
      + +

      The -print-alias-sets pass is exposed as part of the + analyze tool to print out the Alias Sets formed by the AliasSetTracker class. This is useful if you're using + the AliasSetTracker.

      + +
      + + +
      + The -count-aa pass +
      + +
      + +

      The -count-aa pass is useful to see how many queries a particular + pass is making and what kinds of responses are returned by the alias analysis. + An example usage is:

      + + 
      +   $ opt -basicaa -count-aa -ds-aa -count-aa -licm
+
      + +

      Which will print out how many queries (and what responses are returned) by + the -licm pass (of the -ds-aa pass) and how many queries are + made of the -basicaa pass by the -ds-aa pass. This can be + useful when evaluating an alias analysis for precision.

      + +
      + + +
      + 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 + gives an indication of the precision of the alias analysis. Statistics are + printed.

      + +
      + + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + Chris Lattner
      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/CFEBuildInstrs.html diff -c /dev/null llvm-www/releases/1.2/docs/CFEBuildInstrs.html:1.1 *** /dev/null Fri Mar 19 11:38:21 2004 --- llvm-www/releases/1.2/docs/CFEBuildInstrs.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,279 ---- + + + + + + Bootstrapping the LLVM C/C++ Front-End + + + +
      + Bootstrapping the LLVM C/C++ Front-End +
      + +
        +
      1. A Cautionary Note +
      2. Instructions +
      3. License Information +
      + +
      +

      Written by Brian R. Gaeke

      +
      + + +
      + A Cautionary Note +
      + + +
      +

      This document is intended to explain the process of building the + LLVM C/C++ front-end, based on GCC 3.4, from its source code. You + would have to do this, for example, if you are porting LLVM to a new + architecture or operating system.

      + +

      NOTE: This is currently a somewhat fragile, error-prone + process, and you should only try to do it if:

      + +
        +
      1. you really, really, really can't use the binaries we distribute
        2. +
      2. you need GCC to fix some of the header files on your system
        3. +
      3. you are an elite GCC hacker.
        4. +
      + +

      We welcome patches to help make this process simpler.

      +
      + + +
      + Instructions +
      + + +
      +

      +

        +

      1. Configure and build the LLVM libraries and tools using:

        + 
        +  % cd llvm
+  % ./configure [options...]
+  % gmake tools-only
+
        +

        The use of the non-default target "tools-only" means that the + LLVM tools and libraries will build, and the binaries will be + deposited in llvm/tools/Debug, but the runtime (bytecode) + libraries will not build.

        2. + +

      2. Add the directory containing the tools to your PATH.

        + 
        +  % set path = ( `cd llvm/tools/Debug && pwd` $path )
+
        3. + +

      3. Unpack the C/C++ front-end source into cfrontend/src.

        4. + +

      4. Edit src/configure. Change the first line (starting w/ #!) to + contain the correct full pathname of sh.

        5. + +

      5. Make "build" and "install" directories as siblings of the "src" + tree.

        + 
        +  % pwd
+  /usr/local/example/cfrontend/src
+  % cd ..
+  % mkdir build install
+  % set CFEINSTALL = `pwd`/install
+
        6. + +

      6. Configure, build, and install the C front-end:

        + +

        + Linux/x86: +
        + MacOS X/PowerPC: +

        + + 
        +  % cd build
+  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls --disable-shared \
+    --enable-languages=c,c++
+  % gmake all-gcc
+  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+  % gmake all; gmake install
+
        + +

        + Solaris/SPARC: +

        + +

        + For Solaris/SPARC, LLVM only supports the SPARC V9. Therefore, the + configure command line should specify sparcv9, as shown below. Also, + note that Solaris has trouble with various wide (multibyte) character + functions from C as referenced from C++, so we typically configure with + --disable-c-mbchar (cf. Bug 206). +

        + + 
        +  % cd build
+  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
+    --disable-shared --enable-languages=c,c++ --host=sparcv9-sun-solaris2.8 \
+    --disable-c-mbchar
+  % gmake all-gcc
+  % setenv LLVM_LIB_SEARCH_PATH `pwd`/gcc 
+  % gmake all; gmake install
+
        + +

        Common Problem: You may get error messages regarding the fact + that LLVM does not support inline assembly. Here are two common + fixes:

        + +
          +

        • Fix 1: If you have system header files that include + inline assembly, you may have to modify them to remove the inline + assembly, and install the modified versions in + $CFEINSTALL/target-triplet/sys-include.

          • + +
        • Fix 2: If you are building the C++ front-end on a CPU we + haven't tried yet, you will probably have to edit the appropriate + version of atomicity.h under + src/libstdc++-v3/config/cpu/name-of-cpu/atomicity.h + and apply a patch so that it does not use inline assembly.

          • +
        + +

        Porting to a new architecture: If you are porting the new front-end + to a new architecture, or compiling in a different configuration that we have + previously, there are probably several changes you will have to make to the GCC + target to get it to work correctly. These include:

        + +

          +
        • Often targets include special or assembler linker flags which + gccas/gccld does not understand. In general, these can + just be removed.
          • +
        • LLVM currently does not support any floating point values other than + 32-bit and 64-bit IEEE floating point. The primary effect of this is + that you may have to map "long double" onto "double".
          • +
        • The profiling hooks in GCC do not apply at all to the LLVM front-end. + These may need to be disabled.
          • +
        • No inline assembly for position independent code. At the LLVM level, + everything is position independent.
          • +
        • We handle .init and .fini differently.
          • +
        • You may have to disable multilib support in your target. Using multilib + support causes the GCC compiler driver to add a lot of "-L" + options to the link line, which do not relate to LLVM and confuse + gccld. To disable multilibs, delete any + MULTILIB_OPTIONS lines from your target files.
          • +
        • Did we mention that we don't support inline assembly? You'll probably + have to add some fixinclude hacks to disable it in the system + headers.
          • +
        +
        7. + +

      7. Go back into the LLVM source tree proper. Edit Makefile.config + to redefine LLVMGCCDIR to the full pathname of the + $CFEINSTALL directory, which is the directory you just + installed the C front-end into. (The ./configure script is likely to + have set this to a directory which does not exist on your system.)

        8. + +

      8. If you edited header files during the C/C++ front-end build as + described in "Fix 1" above, you must now copy those header files from + $CFEINSTALL/target-triplet/sys-include to + $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm/include. + (This should be the "include" directory in the same directory as the + libgcc.a library, which you can find by running + $CFEINSTALL/bin/gcc --print-libgcc-file-name.)

        9. + +

      9. Build and install the runtime (bytecode) libraries by running:

        + 
        +  % gmake -C runtime
+  % mkdir $CFEINSTALL/bytecode-libs
+  % gmake -C runtime install-bytecode
+  % setenv LLVM_LIB_SEARCH_PATH $CFEINSTALL/bytecode-libs
+
        10. + +

      10. Test the newly-installed C frontend by one or more of the + following means:

        +
          +
        • compiling and running a "hello, LLVM" program in C and C++.
          • +
        • running the tests under test/Programs using gmake -C + test/Programs
          • +
        +

        +
        11. +
      +
      + + +
      + 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 + COPYING.LIB for more details. +

      + +

      + The software also has the following additional copyrights: +

      + + 
      + 
+ Copyright (c) 2003, 2004 University of Illinois at Urbana-Champaign.
+ All rights reserved.
+ 
+ Developed by:
+ 
+     LLVM Team
+ 
+     University of Illinois at Urbana-Champaign
+ 
+     http://llvm.cs.uiuc.edu
+ 
+ THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
+ FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL THE
+ CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS WITH THE
+ SOFTWARE.
+ 
+ Copyright (c) 1994
+ Hewlett-Packard Company
+ 
+ Permission to use, copy, modify, distribute and sell this software
+ and its documentation for any purpose is hereby granted without fee,
+ provided that the above copyright notice appear in all copies and
+ that both that copyright notice and this permission notice appear
+ in supporting documentation.  Hewlett-Packard Company makes no
+ representations about the suitability of this software for any
+ purpose.  It is provided "as is" without express or implied warranty.
+ 
+ Copyright (c) 1996, 1997, 1998, 1999
+ Silicon Graphics Computer Systems, Inc.
+ 
+ Permission to use, copy, modify, distribute and sell this software
+ and its documentation for any purpose is hereby granted without fee,
+ provided that the above copyright notice appear in all copies and
+ that both that copyright notice and this permission notice appear
+ in supporting documentation.  Silicon Graphics makes no
+ representations about the suitability of this software for any
+ purpose.  It is provided "as is" without express or implied warranty.
+
      +
      + + + + +
      +
      +
      Brian Gaeke
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/CodingStandards.html diff -c /dev/null llvm-www/releases/1.2/docs/CodingStandards.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/CodingStandards.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,959 ---- + + + + + A Few Coding Standards + + + +
      + A Few Coding Standards +
      + +
        +
      1. Introduction
        2. +
      2. Mechanical Source Issues +
          +
        1. Source Code Formatting +
            +
          1. Commenting
            2. +
          2. Comment Formatting
            3. +
          3. #include Style
            4. +
          4. Source Code Width
            5. +
          5. Use Spaces Instead of Tabs
            6. +
          6. Indent Code Consistently
            7. +
          2. +
        2. Compiler Issues +
            +
          1. Treat Compiler Warnings Like + Errors
            2. +
          2. Which C++ features can I use?
            3. +
          3. Write Portable Code
            4. +
          3. +
        3. +
      3. Style Issues +
          +
        1. The High Level Issues +
            +
          1. A Public Header File is a + Module
            2. +
          2. #include as Little as Possible
            3. +
          3. Keep "internal" Headers + Private
            4. +
          2. +
        2. The Low Level Issues +
            +
          1. Assert Liberally
            2. +
          2. Prefer Preincrement
            3. +
          3. Avoid endl
            4. +
          4. Exploit C++ to its Fullest
            5. +
          3. +
        3. Writing Iterators
          4. +
        4. +
      4. See Also
        5. +
      + + + +
      + 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 + absolute requirements to be followed in all instances, coding standards can be + useful.

      + +

      This document intentionally does not prescribe fixed standards for religious + issues such as brace placement and space usage. For issues like this, follow + the golden rule:

      + +
      + +

      If you are adding a significant body of source to a + project, feel free to use whatever style you are most comfortable with. If you + are extending, enhancing, or bug fixing already implemented code, use the style + that is already being used so that the source is uniform and easy to + follow.

      + +
      + +

      The ultimate goal of these guidelines is the increase readability and + maintainability of our common source base. If you have suggestions for topics to + be included, please mail them to 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. :) Although we all should probably + comment our code more than we do, there are a few very critical places that + documentation is very useful:

      + +
        +

      1. 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 checked into CVS. Most source trees will probably have a standard + file header format. The standard format for the LLVM source tree looks like + this:

        + + 
        + //===-- llvm/Instruction.h - Instruction class definition -------*- C++ -*-===//
+ //
+ // This file contains the declaration of the Instruction class, which is the
+ // base class for all of the VM instructions.
+ //
+ //===----------------------------------------------------------------------===//
+
        + +

        A few things to note about this particular format. The "-*- C++ + -*-" string on the first line is there to tell Emacs that the source file + is a C++ file, not a C file (Emacs assumes .h files are C files by default [Note + that tag this is not necessary in .cpp files]). The name of the file is also on + the first line, along with a very short description of the purpose of the file. + This is important when printing out code and flipping though lots of pages.

        + +

        The main body of the description does not have to be very long in most cases. + Here it's only two lines. If an algorithm is being implemented or something + tricky is going on, a reference to the paper where it is published should be + included, as well as any notes or "gotchas" in the code to watch out for.

        + +
        2. + +

      2. Class overviews

        + +

        Classes are one fundemental part of a good object oriented design. As such, + a class definition should have a comment block that explains what the class is + used for... if it's not obvious. If it's so completely obvious your grandma + could figure it out, it's probably safe to leave it out. Naming classes + something sane goes a long ways towards avoiding writing documentation. :)

        + +
        3. + +

      3. 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 any a description of the + borderline behaviour is all that is necessary here (unless something + particularly tricky or insideous is going on). The hope is that people can + figure out how to use your interfaces without reading the code itself... that is + the goal metric.

        + +

        Good things to talk about here are what happens when something unexpected + happens: does the method return null? Abort? Format your hard disk?

        + +
        4. +
      + +
      + + +
      + 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 + when it is useful to use C style (/* */) comments however:

      + +
        +
      1. When writing a C code: Obviously if you are writing C code, use C style + comments. :)
        2. +
      2. When writing a header file that may be #included by a C source file.
        3. +
      3. When writing a source file that is used by a tool that only accepts C + style comments.
        4. +
      + +

      To comment out a large block of code, use #if 0 and #endif. + 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 minimal list of #includes required by the file should + be listed. We prefer these #includes to be listed in this order:

      + +
        +
      1. Main Module header
        2. +
      2. Local/Private Headers
        3. +
      3. llvm/*
        4. +
      4. llvm/Analysis/*
        5. +
      5. llvm/Assembly/*
        6. +
      6. llvm/Bytecode/*
        7. +
      7. llvm/CodeGen/*
        8. +
      8. ...
        9. +
      9. Support/*
        10. +
      10. Config/*
        11. +
      11. System #includes
        12. +
      + +

      ... and each catagory should be sorted by name.

      + +

      The "Main Module Header" file applies to .cpp file + which implement an interface defined by a .h file. This #include should always + be included first regardless of where it lives on the file system. By + including a header file first in the .cpp files that implement the interfaces, + we ensure that the header does not have any hidden dependencies which are not + explicitly #included in the header, but should be. It is also a form of + documentation in the .cpp file to indicate where the interfaces it implements + are defined.

      + +
      + + +
      + 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 + it.

      + +
      + + +
      + Use Spaces Instead of Tabs +
      + +
      + +

      In all cases, prefer spaces to tabs in source files. People have different + prefered indentation levels, and different styles of indentation that they + like... this is fine. What isn't is that different editors/viewers expand tabs + out to different tab stops. This can cause your code to look completely + unreadable, and it is not worth dealing with.

      + +

      As always, follow the Golden Rule above: follow the + style of existing code if your are modifying and extending it. If you like four + spaces of indentation, DO NOT do that in the middle of a chunk of code + with two spaces of indentation. Also, do not reindent a whole source file: it + makes for incredible diffs that are absolutely worthless.

      + +
      + + +
      + Indent Code Consistently +
      + +
      + +

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

      + +
      + + + +
      + 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 code, or + you are doing something legitimately wrong. Compiler warnings can cover up + legitimate errors in output and make dealing with a translation unit + difficult.

      + +

      It is not possible to prevent all warnings from all compilers, nor is it + desirable. Instead, pick a standard compiler (like gcc) that provides + a good thorough set of warnings, and stick to them. At least in the case of + gcc, it is possible to work around any spurious errors by changing the + syntax of the code slightly. For example, an warning that annoys me occurs when + I write code like this:

      + + 
      +   if (V = getValue()) {
+     ..
+   }
+
      + +

      gcc will warn me that I probably want to use the == + operator, and that I probably mistyped it. In most cases, I haven't, and I + really don't want the spurious errors. To fix this particular problem, I + rewrite the code like this:

      + + 
      +   if ((V = getValue())) {
+     ..
+   }
+
      + +

      ...which shuts gcc up. Any gcc warning that annoys you can + be fixed by massaging the code appropriately.

      + +

      These are the gcc warnings that I prefer to enable: -Wall + -Winline -W -Wwrite-strings -Wno-unused

      + +
      + + +
      + Which C++ features can I use? +
      + +
      + +

      Compilers are finally catching up to the C++ standard. Most compilers + implement most features, so you can use just about any features that you would + like. In the LLVM source tree, I have chosen to not use these features:

      + +
        +

      1. Exceptions: Exceptions are very useful for error reporting and handling + exceptional conditions. I do not use them in LLVM because they do have an + associated performance impact (by restricting restructuring of code), and parts + of LLVM are designed for performance critical purposes.

        + +

        Just like most of the rules in this document, this isn't a hard and fast + requirement. Exceptions are used in the Parser, because it simplifies error + reporting significantly, and the LLVM parser is not at all in the + critical path.

        +
        2. + +
      2. RTTI: RTTI has a large cost in terms of executable size, and compilers are + not yet very good at stomping out "dead" class information blocks. Because of + this, typeinfo and dynamic cast are not used.
        3. +
      + +

      Other features, such as templates (without partial specialization) can be + used freely. The general goal is to have clear, consise, performant code... if + a technique assists with that then use it.

      + +
      + + +
      + 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 + code, isolate it behind a well defined (and well documented) interface.

      + +

      In practice, this means that you shouldn't assume much about the host + compiler, including its support for "high tech" features like partial + specialization of templates. In fact, Visual C++ 6 could be an important target + for our work in the future, and we don't want to have to rewrite all of our code + to support it.

      + +
      + + +
      + 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 + is what we have to work with. When you write a public header file (in the LLVM + source tree, they live in the top level "include" directory), you are defining a + module of functionality.

      + +

      Ideally, modules should be completely independent of each other, and their + header files should only include the absolute minimum number of headers + possible. A module is not just a class, a function, or a namespace: it's a collection + of these that defines an interface. This interface may be several + functions, classes or data structures, but the important issue is how they work + together.

      + +

      In general, a module should be implemented with one or more .cpp + files. Each of these .cpp files should include the header that defines + their interface first. This ensure that all of the dependences of the module + header have been properly added to the module header itself, and are not + implicit. System headers should be included after user headers for a + translation unit.

      + +
      + + +
      + #include as Little as Possible +
      + +
      + +

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

      + +

      But wait, sometimes you need to have the definition of a class to use it, or + to inherit from it. In these cases go ahead and #include that header file. Be + aware however that there are many cases where you don't need to have the full + definition of a class. If you are using a pointer or reference to a class, you + don't need the header file. If you are simply returning a class instance from a + prototyped function or method, you don't need it. In fact, for most cases, you + simply don't need the definition of a class... and not #include'ing + speeds up compilation.

      + +

      It is easy to try to go too overboard on this recommendation, however. You + must include all of the header files that you are using, either directly + or indirectly (through another header file). To make sure that you don't + accidently forget to include a header file in your module header, make sure to + include your module header first in the implementation file (as mentioned + above). This way there won't be any hidden 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 + internal communication interface (helper classes, extra functions, etc) in the + public module header file. Don't do this. :)

      + +

      If you really need to do something like this, put a private header file in + the same directory as the source files, and include it locally. This ensures + that your private interface remains private and undisturbed by outsiders.

      + +

      Note however, that it's okay to put extra implementation methods a public + class itself... just make them private (or protected), and all is well.

      + +
      + + +
      + The Low Level Issues +
      + + + +
      + Assert Liberally +
      + +
      + +

      Use the "assert" function to its fullest. Check all of your + preconditions and assumptions, you never know when a bug (not neccesarily even + yours) might be caught early by an assertion, which reduces debugging time + dramatically. The "<cassert>" header file is probably already + included by the header files you are using, so it doesn't cost anything to use + it.

      + +

      To further assist with debugging, make sure to put some kind of error message + in the assertion statement (which is printed if the assertion is tripped). This + helps the poor debugging make sense of why an assertion is being made and + enforced, and hopefully what to do about it. Here is one complete example:

      + + 
      +   inline Value *getOperand(unsigned i) { 
+     assert(i < Operands.size() && "getOperand() out of range!");
+     return Operands[i]; 
+   }
+
      + +

      Here are some examples:

      + + 
      +   assert(Ty->isPointerType() && "Can't allocate a non pointer type!");
+ 
+   assert((Opcode == Shl || Opcode == Shr) && "ShiftInst Opcode invalid!");
+ 
+   assert(idx < getNumSuccessors() && "Successor # out of range!");
+ 
+   assert(V1.getType() == V2.getType() && "Constant types must be identical!");
+ 
+   assert(isa<PHINode>(Succ->front()) && "Only works on PHId BBs!");
+
      + +

      You get the idea...

      + +
      + + + +
      + 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 preincrementation whenever + possible.

      + +

      The semantics of postincrement include making a copy of the value being + incremented, returning it, and then preincrementing the "work value". For + primitive types, this isn't a big deal... but for iterators, it can be a huge + issue (for example, some iterators contains stack and set objects in them... + copying an iterator could invoke the copy ctor's of these as well). In general, + get in the habit of always using preincrement, and you won't have a problem.

      + +
      + + + +
      + Avoid endl +
      + +
      + +

      The endl modifier, when used with iostreams outputs a newline to the + output stream specified. In addition to doing this, however, it also flushes + the output stream. In other words, these are equivalent:

      + + 
      +   cout << endl;
+   cout << "\n" << flush;
+
      + +

      Most of the time, you probably have no reason to flush the output stream, so + it's better to use a literal "\n".

      + +
      + + +
      + Exploit C++ to its Fullest +
      + +
      + +

      C++ is a powerful language. With a firm grasp on its capabilities, you can make + write effective, consise, readable and maintainable code all at the same time. + By staying consistent, you reduce the amount of special cases that need to be + remembered. Reducing the total number of lines of code you write is a good way + to avoid documentation, and avoid giving bugs a place to hide.

      + +

      For these reasons, come to know and love the contents of your local + <algorithm> header file. Know about <functional> and what it can do + for you. C++ is just a tool that wants you to master it. :)

      + +
      + + +
      + Writing Iterators +
      + +
      + +

      Here's a pretty good summary of how to write your own data structure iterators + in a way that is compatible with the STL, and with a lot of other code out there + (slightly edited by Chris):

      + + 
      + From: Ross Smith <ross.s at ihug.co.nz>
+ Newsgroups: comp.lang.c++.moderated
+ Subject: Writing iterators (was: Re: Non-template functions that take iterators)
+ Date: 28 Jun 2001 12:07:10 -0400
+ 
+ Andre Majorel wrote:
+ > Any pointers handy on "writing STL-compatible iterators for
+ > dummies ?"
+ 
+ I'll give it a try...
+ 
+ The usual situation requiring user-defined iterators is that you have
+ a type that bears some resemblance to an STL container, and you want
+ to provide iterators so it can be used with STL algorithms. You need
+ to ask three questions:
+ 
+ First, is this simply a wrapper for an underlying collection of
+ objects that's held somewhere as a real STL container, or is it a
+ "virtual container" for which iteration is (under the hood) more
+ complicated than simply incrementing some underlying iterator (or
+ pointer or index or whatever)? In the former case you can frequently
+ get away with making your container's iterators simply typedefs for
+ those of the underlying container; your begin() function would call
+ member_container.begin(), and so on.
+ 
+ Second, do you only need read-only iterators, or do you need separate
+ read-only (const) and read-write (non-const) iterators?
+ 
+ Third, which kind of iterator (input, output, forward, bidirectional,
+ or random access) is appropriate? If you're familiar with the
+ properties of the iterator types (if not, visit
+ http://www.sgi.com/tech/stl/), the appropriate choice should be
+ obvious from the semantics of the container.
+ 
+ I'll start with forward iterators, as the simplest case that's likely
+ to come up in normal code. Input and output iterators have some odd
+ properties and rarely need to be implemented in user code; I'll leave
+ them out of discussion. Bidirectional and random access iterators are
+ covered below.
+ 
+ The exact behaviour of a forward iterator is spelled out in the
+ Standard in terms of a set of expressions with specified behaviour,
+ rather than a set of member functions, which leaves some leeway in how
+ you actually implement it. Typically it looks something like this
+ (I'll start with the const-iterator-only situation):
+ 
+   #include <iterator>
+ 
+   class container {
+     public:
+       typedef something_or_other value_type;
+       class const_iterator:
+         public std::iterator<std::forward_iterator_tag, value_type> {
+           friend class container;
+           public:
+             const value_type& operator*() const;
+             const value_type* operator->() const;
+             const_iterator& operator++();
+             const_iterator operator++(int);
+             friend bool operator==(const_iterator lhs,
+                                    const_iterator rhs);
+             friend bool operator!=(const_iterator lhs,
+                                    const_iterator rhs);
+           private:
+             //...
+         };
+       //...
+   };
+ 
+ An iterator should always be derived from an instantiation of the
+ std::iterator template. The iterator's life cycle functions
+ (constructors, destructor, and assignment operator) aren't declared
+ here; in most cases the compiler-generated ones are sufficient. The
+ container needs to be a friend of the iterator so that the container's
+ begin() and end() functions can fill in the iterator's private members
+ with the appropriate values.
+ 
+ [Chris's Note: I prefer to not make my iterators friends.  Instead, two
+ ctor's are provided for the iterator class: one to start at the end of the
+ container, and one at the beginning.  Typically this is done by providing
+ two constructors with different signatures.]
+ 
+ There are normally only three member functions that need nontrivial
+ implementations; the rest are just boilerplate.
+ 
+   const container::value_type&
+     container::const_iterator::operator*() const {
+       // find the element and return a reference to it
+     }
+ 
+   const container::value_type*
+     container::const_iterator::operator->() const {
+       return &**this;
+     }
+ 
+ If there's an underlying real container, operator*() can just return a
+ reference to the appropriate element. If there's no actual container
+ and the elements need to be generated on the fly -- what I think of as
+ a "virtual container" -- things get a bit more complicated; you'll
+ probably need to give the iterator a value_type member object, and
+ fill it in when you need to. This might be done as part of the
+ increment operator (below), or if the operation is nontrivial, you
+ might choose the "lazy" approach and only generate the actual value
+ when one of the dereferencing operators is called.
+ 
+ The operator->() function is just boilerplate around a call to
+ operator*().
+ 
+   container::const_iterator&
+     container::const_iterator::operator++() {
+       // the incrementing logic goes here
+       return *this;
+     }
+ 
+   container::const_iterator
+     container::const_iterator::operator++(int) {
+       const_iterator old(*this);
+       ++*this;
+       return old;
+     }
+ 
+ Again, the incrementing logic will usually be trivial if there's a
+ real container involved, more complicated if you're working with a
+ virtual container. In particular, watch out for what happens when you
+ increment past the last valid item -- this needs to produce an
+ iterator that will compare equal to container.end(), and making this
+ work is often nontrivial for virtual containers.
+ 
+ The post-increment function is just boilerplate again (and
+ incidentally makes it obvious why all the experts recommend using
+ pre-increment wherever possible).
+ 
+   bool operator==(container::const_iterator lhs,
+                   container::const_iterator rhs) {
+     // equality comparison goes here
+   }
+ 
+   bool operator!=(container::const_iterator lhs,
+                   container::const_iterator rhs) {
+     return !(lhs == rhs);
+   }
+ 
+ For a real container, the equality comparison will usually just
+ compare the underlying iterators (or pointers or indices or whatever).
+ The semantics of comparisons for virtual container iterators are often
+ tricky. Remember that iterator comparison only needs to be defined for
+ iterators into the same container, so you can often simplify things by
+ taking for granted that lhs and rhs both point into the same container
+ object. Again, the second function is just boilerplate.
+ 
+ It's a matter of taste whether iterator arguments are passed by value
+ or reference; I've shown tham passed by value to reduce clutter, but
+ if the iterator contains several data members, passing by reference
+ may be better.
+ 
+ That convers the const-iterator-only situation. When we need separate
+ const and mutable iterators, one small complication is added beyond
+ the simple addition of a second class.
+ 
+   class container {
+     public:
+       typedef something_or_other value_type;
+       class const_iterator;
+       class iterator:
+         public std::iterator<std::forward_iterator_tag, value_type> {
+           friend class container;
+           friend class container::const_iterator;
+           public:
+             value_type& operator*() const;
+             value_type* operator->() const;
+             iterator& operator++();
+             iterator operator++(int);
+             friend bool operator==(iterator lhs, iterator rhs);
+             friend bool operator!=(iterator lhs, iterator rhs);
+           private:
+             //...
+         };
+       class const_iterator:
+         public std::iterator<std::forward_iterator_tag, value_type> {
+           friend class container;
+           public:
+             const_iterator();
+             const_iterator(const iterator& i);
+             const value_type& operator*() const;
+             const value_type* operator->() const;
+             const_iterator& operator++();
+             const_iterator operator++(int);
+             friend bool operator==(const_iterator lhs,
+                                    const_iterator rhs);
+             friend bool operator!=(const_iterator lhs,
+                                    const_iterator rhs);
+           private:
+             //...
+         };
+       //...
+   };
+ 
+ There needs to be a conversion from iterator to const_iterator (so
+ that mixed-type operations, such as comparison between an iterator and
+ a const_iterator, will work). This is done here by giving
+ const_iterator a conversion constructor from iterator (equivalently,
+ we could have given iterator an operator const_iterator()), which
+ requires const_iterator to be a friend of iterator, so it can copy its
+ data members. (It also requires the addition of an explicit default
+ constructor to const_iterator, since the existence of another
+ user-defined constructor inhibits the compiler-defined one.)
+ 
+ Bidirectional iterators add just two member functions to forward
+ iterators:
+ 
+   class iterator:
+     public std::iterator<std::bidirectional_iterator_tag, value_type> {
+       public:
+         //...
+         iterator& operator--();
+         iterator operator--(int);
+         //...
+     };
+ 
+ I won't detail the implementations, they're obvious variations on
+ operator++().
+ 
+ Random access iterators add several more member and friend functions:
+ 
+   class iterator:
+     public std::iterator<std::random_access_iterator_tag, value_type> {
+       public:
+         //...
+         iterator& operator+=(difference_type rhs);
+         iterator& operator-=(difference_type rhs);
+         friend iterator operator+(iterator lhs, difference_type rhs);
+         friend iterator operator+(difference_type lhs, iterator rhs);
+         friend iterator operator-(iterator lhs, difference_type rhs);
+         friend difference_type operator-(iterator lhs, iterator rhs);
+         friend bool operator<(iterator lhs, iterator rhs);
+         friend bool operator>(iterator lhs, iterator rhs);
+         friend bool operator<=(iterator lhs, iterator rhs);
+         friend bool operator>=(iterator lhs, iterator rhs);
+         //...
+     };
+ 
+   container::iterator&
+     container::iterator::operator+=(container::difference_type rhs) {
+       // add rhs to iterator position
+       return *this;
+     }
+ 
+   container::iterator&
+     container::iterator::operator-=(container::difference_type rhs) {
+       // subtract rhs from iterator position
+       return *this;
+     }
+ 
+   container::iterator operator+(container::iterator lhs,
+                                 container::difference_type rhs) {
+     return iterator(lhs) += rhs;
+   }
+ 
+   container::iterator operator+(container::difference_type lhs,
+                                 container::iterator rhs) {
+     return iterator(rhs) += lhs;
+   }
+ 
+   container::iterator operator-(container::iterator lhs,
+                                 container::difference_type rhs) {
+     return iterator(lhs) -= rhs;
+   }
+ 
+   container::difference_type operator-(container::iterator lhs,
+                                        container::iterator rhs) {
+     // calculate distance between iterators
+   }
+ 
+   bool operator<(container::iterator lhs, container::iterator rhs) {
+     // perform less-than comparison
+   }
+ 
+   bool operator>(container::iterator lhs, container::iterator rhs) {
+     return rhs < lhs;
+   }
+ 
+   bool operator<=(container::iterator lhs, container::iterator rhs) {
+     return !(rhs < lhs);
+   }
+ 
+   bool operator>=(container::iterator lhs, container::iterator rhs) {
+     return !(lhs < rhs);
+   }
+ 
+ Four of the functions (operator+=(), operator-=(), the second
+ operator-(), and operator<()) are nontrivial; the rest are
+ boilerplate.
+ 
+ One feature of the above code that some experts may disapprove of is
+ the declaration of all the free functions as friends, when in fact
+ only a few of them need direct access to the iterator's private data.
+ I originally got into the habit of doing this simply to keep the
+ declarations together; declaring some functions inside the class and
+ some outside seemed awkward. Since then, though, I've been told that
+ there's a subtle difference in the way name lookup works for functions
+ declared inside a class (as friends) and outside, so keeping them
+ together in the class is probably a good idea for practical as well as
+ aesthetic reasons.
+ 
+ I hope all this is some help to anyone who needs to write their own
+ STL-like containers and iterators.
+ 
+ -- 
+ Ross Smith <ross.s at ihug.co.nz> The Internet Group, Auckland, New Zealand
+
      + +
      + + +
      + See Also +
      + + +
      + +

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

      + +
        + +
      1. Effective + C++ by Scott Meyers. There is an online version of the book (only some + chapters though) available as well.
        2. + +
      2. Large-Scale C++ + Software Design by John Lakos
        3. + +
      + +

      If you get some free time, and you haven't read them: do so, you might learn + something. :)

      + +
      + + + +
      + +
      +
      Chris Lattner
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/CommandLine.html diff -c /dev/null llvm-www/releases/1.2/docs/CommandLine.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/CommandLine.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,1699 ---- + + + + CommandLine 2.0 Library Manual + + + + +
      + CommandLine 2.0 Library Manual +
      + +
        +
      1. Introduction
        2. + +
      2. Quick Start Guide +
          +
        1. Boolean Arguments
          2. +
        2. Argument Aliases
          3. +
        3. Selecting an alternative from a + set of possibilities
          4. +
        4. Named alternatives
          5. +
        5. Parsing a list of options
          6. +
        6. Adding freeform text to help output
          7. +
        3. + +
      3. Reference Guide +
          +
        1. Positional Arguments +
          2. + +
        2. Internal vs External Storage
          3. + +
        3. Option Attributes
          4. + +
        4. Option Modifiers +
          5. + +
        5. Top-Level Classes and Functions +
          6. + +
        6. Builtin parsers +
          7. +
        4. +
      4. Extension Guide +
          +
        1. Writing a custom parser
          2. +
        2. Exploiting external storage
          3. +
        3. Dynamically adding command line + options
          4. +
        5. +
      + +
      +

      Written by Chris Lattner

      +
      + + +
      + 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 + declarative approach to specifying the command line options that your program + takes. By default, these options declarations implicitly hold the value parsed + for the option declared (of course this can be + changed).

      + +

      Although there are a lot of command line argument parsing libraries + out there in many different languages, none of them fit well with what I needed. + By looking at the features and problems of other libraries, I designed the + CommandLine library to have the following features:

      + +
        +
      1. Speed: The CommandLine library is very quick and uses little resources. The + parsing time of the library is directly proportional to the number of arguments + parsed, not the the number of options recognized. Additionally, command line + argument values are captured transparently into user defined global variables, + which can be accessed like any other variable (and with the same + performance).
        2. + +
      2. Type Safe: As a user of CommandLine, you don't have to worry about + remembering the type of arguments that you want (is it an int? a string? a + bool? an enum?) and keep casting it around. Not only does this help prevent + error prone constructs, it also leads to dramatically cleaner source code.
        3. + +
      3. No subclasses required: To use CommandLine, you instantiate variables that + correspond to the arguments that you would like to capture, you don't subclass a + parser. This means that you don't have to write any boilerplate + code.
        4. + +
      4. Globally accessible: Libraries can specify command line arguments that are + automatically enabled in any tool that links to the library. This is possible + because the application doesn't have to keep a "list" of arguments to pass to + the parser. This also makes supporting dynamically + loaded options trivial.
        5. + +
      5. Cleaner: CommandLine supports enum and other types directly, meaning that + there is less error and more security built into the library. You don't have to + worry about whether your integral command line argument accidentally got + assigned a value that is not valid for your enum type.
        6. + +
      6. Powerful: The CommandLine library supports many different types of + arguments, from simple boolean flags to scalars arguments (strings, integers, enums, doubles), to lists of + arguments. This is possible because CommandLine is...
        7. + +
      7. Extensible: It is very simple to add a new argument type to CommandLine. + Simply specify the parser that you want to use with the command line option when + you declare it. Custom parsers are no problem.
        8. + +
      8. Labor Saving: The CommandLine library cuts down on the amount of grunt work + that you, the user, have to do. For example, it automatically provides a + --help option that shows the available command line options for your + tool. Additionally, it does most of the basic correctness checking for + you.
        9. + +
      9. Capable: The CommandLine library can handle lots of different forms of + options often found in real programs. For example, positional arguments, ls style grouping options (to allow processing 'ls + -lad' naturally), ld style prefix + options (to parse '-lmalloc -L/usr/lib'), and interpreter style options.
        10. + +
      + +

      This document will hopefully let you jump in and start using CommandLine in + your utility quickly and painlessly. Additionally it should be a simple + reference manual to figure out how stuff works. If it is failing in some area + (or you want an extension to the library), nag the author, 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 + CommandLine library in your own program, and show you some of the cool things it + can do.

      + +

      To start out, you need to include the CommandLine header file into your + program:

      + + 
      +   #include "Support/CommandLine.h"
+
      + +

      Additionally, you need to add this as the first line of your main + program:

      + + 
      + int main(int argc, char **argv) {
+   cl::ParseCommandLineOptions(argc, argv);
+   ...
+ }
+
      + +

      ... which actually parses the arguments and fills in the variable + declarations.

      + +

      Now that you are ready to support command line arguments, we need to tell the + system which ones we want, and what type of argument they are. The CommandLine + library uses a declarative syntax to model command line arguments with the + global variable declarations that capture the parsed values. This means that + for every command line option that you would like to support, there should be a + global variable declaration to capture the result. For example, in a compiler, + we would like to support the unix standard '-o <filename>' option + to specify where to put the output. With the CommandLine library, this is + 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 + that the data type that we are parsing is a string.

      + +

      The second and third parameters (which are optional) are used to specify what + to output for the "--help" option. In this case, we get a line that + looks like this:

      + + 
      + USAGE: compiler [options]
+ 
+ OPTIONS:
+   -help             - display available options (--help-hidden for more)
+   -o <filename>     - Specify output filename
+
      + +

      Because we specified that the command line option should parse using the + string data type, the variable declared is automatically usable as a + real string in all contexts that a normal C++ string object may be used. For + example:

      + + 
      +   ...
+   ofstream Output(OutputFilename.c_str());
+   if (Out.good()) ...
+   ...
+
      + +

      There are many different options that you can use to customize the command + line option handling library, but the above example shows the general interface + to these options. The options can be specified in any order, and are specified + with helper functions like cl::desc(...), so + there are no positional dependencies to remember. The available options are + discussed in detail in the Reference Guide.

      + +

      Continuing the example, we would like to have our compiler take an input + filename as well as an output filename, but we do not want the input filename to + be specified with a hyphen (ie, not -filename.c). To support this + style of argument, the CommandLine library allows for positional arguments to be specified for the program. + These positional arguments are filled with command line parameters that are not + in option form. We use this feature like this:

      + + 
      + cl::opt<string> InputFilename(cl::Positional, cl::desc("<input file>"), cl::init("-"));
+
      + +

      This declaration indicates that the first positional argument should be + treated as the input filename. Here we use the cl::init option to specify an initial value for the + command line option, which is used if the option is not specified (if you do not + specify a cl::init modifier for an option, then + the default constructor for the data type is used to initialize the value). + Command line options default to being optional, so if we would like to require + that the user always specify an input filename, we would add the cl::Required flag, and we could eliminate the + cl::init modifier, like this:

      + + 
      + cl::opt<string> InputFilename(cl::Positional, cl::desc("<input file>"), cl::Required);
+
      + +

      Again, the CommandLine library does not require the options to be specified + in any particular order, so the above declaration is equivalent to:

      + + 
      + cl::opt<string> InputFilename(cl::Positional, cl::Required, cl::desc("<input file>"));
+
      + +

      By simply adding the cl::Required flag, + the CommandLine library will automatically issue an error if the argument is not + specified, which shifts all of the command line option verification code out of + your application into the library. This is just one example of how using flags + can alter the default behaviour of the library, on a per-option basis. By + adding one of the declarations above, the --help option synopsis is now + extended to:

      + + 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   -help             - display available options (--help-hidden for more)
+   -o <filename>     - Specify output filename
+
      + +

      ... 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 overwriting of the output + file, "--quiet" to enable quiet mode, and "-q" for backwards + compatibility with some of our users. We can support these by declaring options + of boolean type like this:

      + + 
      + cl::opt<bool> Force ("f", cl::desc("Overwrite output files"));
+ cl::opt<bool> Quiet ("quiet", cl::desc("Don't print informational messages"));
+ cl::opt<bool> Quiet2("q", cl::desc("Don't print informational messages"), cl::Hidden);
+
      + +

      This does what you would expect: it declares three boolean variables + ("Force", "Quiet", and "Quiet2") to recognize these + options. Note that the "-q" option is specified with the "cl::Hidden" flag. This modifier prevents it + from being shown by the standard "--help" output (note that it is still + shown in the "--help-hidden" output).

      + +

      The CommandLine library uses a different parser + for different data types. For example, in the string case, the argument passed + to the option is copied literally into the content of the string variable... we + obviously cannot do that in the boolean case, however, so we must use a smarter + parser. In the case of the boolean parser, it allows no options (in which case + it assigns the value of true to the variable), or it allows the values + "true" or "false" to be specified, allowing any of the + following inputs:

      + + 
      +  compiler -f          # No value, 'Force' == true
+  compiler -f=true     # Value specified, 'Force' == true
+  compiler -f=TRUE     # Value specified, 'Force' == true
+  compiler -f=FALSE    # Value specified, 'Force' == false
+
      + +

      ... you get the idea. The bool parser just turns + the string values into boolean values, and rejects things like 'compiler + -f=foo'. Similarly, the float, double, and int parsers work + like you would expect, using the 'strtol' and 'strtod' C + library calls to parse the string value into the specified data type.

      + +

      With the declarations above, "compiler --help" emits this:

      + + 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   -f     - Overwrite output files
+   -o     - Override output filename
+   -quiet - Don't print informational messages
+   -help  - display available options (--help-hidden for more)
+
      + +

      and "opt --help-hidden" prints this:

      + + 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   -f     - Overwrite output files
+   -o     - Override output filename
+   -q     - Don't print informational messages
+   -quiet - Don't print informational messages
+   -help  - display available options (--help-hidden for more)
+
      + +

      This brief example has shown you how to use the 'cl::opt' class to parse simple scalar command line + arguments. In addition to simple scalar arguments, the CommandLine library also + provides primitives to support CommandLine option aliases, + 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:

      + + 
      + ...
+   if (!Quiet && !Quiet2) printInformationalMessage(...);
+ ...
+
      + +

      ... which is a real pain! Instead of defining two values for the same + condition, we can use the "cl::alias" class to make the "-q" + option an alias for the "-quiet" option, instead of providing + a value itself:

      + + 
      + cl::opt<bool> Force ("f", cl::desc("Overwrite output files"));
+ cl::opt<bool> Quiet ("quiet", cl::desc("Don't print informational messages"));
+ cl::alias     QuietA("q", cl::desc("Alias for -quiet"), cl::aliasopt(Quiet));
+
      + +

      The third line (which is the only one we modified from above) defines a + "-q alias that updates the "Quiet" variable (as specified by + the cl::aliasopt modifier) whenever it is + specified. Because aliases do not hold state, the only thing the program has to + query is the Quiet variable now. Another nice feature of aliases is + that they automatically hide themselves from the -help output + (although, again, they are still visible in the --help-hidden + output).

      + +

      Now the application code can simply use:

      + + 
      + ...
+   if (!Quiet) printInformationalMessage(...);
+ ...
+
      + +

      ... which is much nicer! The "cl::alias" + can be used to specify an alternative name for any variable type, and has many + 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 + things it doesn't know about, like enums or 'int*'s?

      + +

      The answer is that it uses a table driven generic parser (unless you specify + your own parser, as described in the Extension + Guide). This parser maps literal strings to whatever type is required, are + requires you to tell it what this mapping should be.

      + +

      Lets say that we would like to add four optimizations levels to our + optimizer, using the standard flags "-g", "-O0", + "-O1", and "-O2". We could easily implement this with boolean + options like above, but there are several problems with this strategy:

      + +
        +
      1. A user could specify more than one of the options at a time, for example, + "opt -O3 -O2". The CommandLine library would not be able to catch this + erroneous input for us.
        2. + +
      2. We would have to test 4 different variables to see which ones are set.
        3. + +
      3. This doesn't map to the numeric levels that we want... so we cannot easily + see if some level >= "-O1" is enabled.
        4. + +
      + +

      To cope with these problems, we can use an enum value, and have the + CommandLine library fill it in with the appropriate level directly, which is + used like this:

      + + 
      + enum OptLevel {
+   g, O1, O2, O3
+ };
+ 
+ cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
+   cl::values(
+     clEnumVal(g , "No optimizations, enable debugging"),
+     clEnumVal(O1, "Enable trivial optimizations"),
+     clEnumVal(O2, "Enable default optimizations"),
+     clEnumVal(O3, "Enable expensive optimizations"),
+    0));
+ 
+ ...
+   if (OptimizationLevel >= O2) doPartialRedundancyElimination(...);
+ ...
+
      + +

      This declaration defines a variable "OptimizationLevel" of the + "OptLevel" enum type. This variable can be assigned any of the values + that are listed in the declaration (Note that the declaration list must be + terminated with the "0" argument!). The CommandLine library enforces + that the user can only specify one of the options, and it ensure that only valid + enum values can be specified. The "clEnumVal" macros ensure that the + command line arguments matched the enum values. With this option added, our + help output now is:

      + + 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   Choose optimization level:
+     -g          - No optimizations, enable debugging
+     -O1         - Enable trivial optimizations
+     -O2         - Enable default optimizations
+     -O3         - Enable expensive optimizations
+   -f            - Overwrite output files
+   -help         - display available options (--help-hidden for more)
+   -o <filename> - Specify output filename
+   -quiet        - Don't print informational messages
+
      + +

      In this case, it is sort of awkward that flag names correspond directly to + enum names, because we probably don't want a enum definition named "g" + in our program. Because of this, we can alternatively write this example like + this:

      + + 
      + enum OptLevel {
+   Debug, O1, O2, O3
+ };
+ 
+ cl::opt<OptLevel> OptimizationLevel(cl::desc("Choose optimization level:"),
+   cl::values(
+    clEnumValN(Debug, "g", "No optimizations, enable debugging"),
+     clEnumVal(O1        , "Enable trivial optimizations"),
+     clEnumVal(O2        , "Enable default optimizations"),
+     clEnumVal(O3        , "Enable expensive optimizations"),
+    0));
+ 
+ ...
+   if (OptimizationLevel == Debug) outputDebugInfo(...);
+ ...
+
      + +

      By using the "clEnumValN" macro instead of "clEnumVal", we + can directly specify the name that the flag should get. In general a direct + mapping is nice, but sometimes you can't or don't want to preserve the mapping, + which is when you would use it.

      + +
      + + +
      + 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. + Instead of each debug level being its own switch, we want to support the + following options, of which only one can be specified at a time: + "--debug-level=none", "--debug-level=quick", + "--debug-level=detailed". To do this, we use the exact same format as + our optimization level flags, but we also specify an option name. For this + case, the code looks like this:

      + + 
      + enum DebugLev {
+   nodebuginfo, quick, detailed
+ };
+ 
+ // Enable Debug Options to be specified on the command line
+ cl::opt<DebugLev> DebugLevel("debug_level", cl::desc("Set the debugging level:"),
+   cl::values(
+     clEnumValN(nodebuginfo, "none", "disable debug information"),
+      clEnumVal(quick,               "enable quick debug information"),
+      clEnumVal(detailed,            "enable detailed debug information"),
+     0));
+
      + +

      This definition defines an enumerated command line variable of type "enum + DebugLev", which works exactly the same way as before. The difference here + is just the interface exposed to the user of your program and the help output by + the "--help" option:

      + + 
      + USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   Choose optimization level:
+     -g          - No optimizations, enable debugging
+     -O1         - Enable trivial optimizations
+     -O2         - Enable default optimizations
+     -O3         - Enable expensive optimizations
+   -debug_level  - Set the debugging level:
+     =none       - disable debug information
+     =quick      - enable quick debug information
+     =detailed   - enable detailed debug information
+   -f            - Overwrite output files
+   -help         - display available options (--help-hidden for more)
+   -o <filename> - Specify output filename
+   -quiet        - Don't print informational messages
+
      + +

      Again, the only structural difference between the debug level declaration and + the optimiation level declaration is that the debug level declaration includes + an option name ("debug_level"), which automatically changes how the + library processes the argument. The CommandLine library supports both forms so + that you can choose the form most appropriate for your application.

      + +
      + + +
      + 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 + a list of optimizations to perform, allowing duplicates. For example, we + might want to run: "compiler -dce -constprop -inline -dce -strip". In + this case, the order of the arguments and the number of appearances is very + important. This is what the "cl::list" + template is for. First, start by defining an enum of the optimizations that you + would like to perform:

      + + 
      + enum Opts {
+   // 'inline' is a C++ keyword, so name it 'inlining'
+   dce, constprop, inlining, strip
+ };
+
      + +

      Then define your "cl::list" variable:

      + + 
      + cl::list<Opts> OptimizationList(cl::desc("Available Optimizations:"),
+   cl::values(
+     clEnumVal(dce               , "Dead Code Elimination"),
+     clEnumVal(constprop         , "Constant Propagation"),
+    clEnumValN(inlining, "inline", "Procedure Integration"),
+     clEnumVal(strip             , "Strip Symbols"),
+   0));
+
      + +

      This defines a variable that is conceptually of the type + "std::vector<enum Opts>". Thus, you can access it with standard + vector methods:

      + + 
      +   for (unsigned i = 0; i != OptimizationList.size(); ++i)
+     switch (OptimizationList[i])
+        ...
+
      + +

      ... to iterate through the list of options specified.

      + +

      Note that the "cl::list" template is + completely general and may be used with any data types or other arguments that + you can use with the "cl::opt" template. One + especially useful way to use a list is to capture all of the positional + arguments together if there may be more than one specified. In the case of a + linker, for example, the linker takes several '.o' files, and needs to + capture them into a list. This is naturally specified as:

      + + 
      + ...
+ cl::list<std::string> InputFilenames(cl::Positional, cl::desc("<Input files>"), cl::OneOrMore);
+ ...
+
      + +

      This variable works just like a "vector<string>" object. As + such, accessing the list is simple, just like above. In this example, we used + the cl::OneOrMore modifier to inform the + CommandLine library that it is an error if the user does not specify any + .o files on our command line. Again, this just reduces the amount of + checking we have to do.

      + +
      + + +
      + 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 + to look similar to a Unix man page, providing concise information about + a program. Unix man pages, however often have a description about what + the program does. To add this to your CommandLine program, simply pass a third + argument to the cl::ParseCommandLineOptions + call in main. This additional argument is then printed as the overview + information for your program, allowing you to include any additional information + that you want. For example:

      + + 
      + int main(int argc, char **argv) {
+   cl::ParseCommandLineOptions(argc, argv, " CommandLine compiler example\n\n"
+                               "  This program blah blah blah...\n");
+   ...
+ }
+
      + +

      Would yield the help output:

      + + 
      + OVERVIEW: CommandLine compiler example
+ 
+   This program blah blah blah...
+ 
+ USAGE: compiler [options] <input file>
+ 
+ OPTIONS:
+   ...
+   -help             - display available options (--help-hidden for more)
+   -o <filename>     - Specify output filename
+
      + +
      + + + +
      + 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 + specified by its position alone. For example, the standard Unix grep + tool takes a regular expression argument, and an optional filename to search + through (which defaults to standard input if a filename is not specified). + Using the CommandLine library, this would be specified as:

      + + 
      + cl::opt<string> Regex   (cl::Positional, cl::desc("<regular expression>"), cl::Required);
+ cl::opt<string> Filename(cl::Positional, cl::desc("<input file>"), cl::init("-"));
+
      + +

      Given these two option declarations, the --help output for our grep + replacement would look like this:

      + + 
      + USAGE: spiffygrep [options] <regular expression> <input file>
+ 
+ OPTIONS:
+   -help - display available options (--help-hidden for more)
+
      + +

      ... and the resultant program could be used just like the standard + grep tool.

      + +

      Positional arguments are sorted by their order of construction. This means + that command line options will be ordered according to how they are listed in a + .cpp file, but will not have an ordering defined if they positional arguments + are defined in multiple .cpp files. The fix for this problem is simply to + define all of your positional arguments in one .cpp file.

      + +
      + + + +
      + 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 + first, you will have trouble doing this, because it will try to find an argument + named '-foo', and will fail (and single quotes will not save you). + Note that the system grep has the same problem:

      + + 
      +   $ spiffygrep '-foo' test.txt
+   Unknown command line argument '-foo'.  Try: spiffygrep --help'
+ 
+   $ grep '-foo' test.txt
+   grep: illegal option -- f
+   grep: illegal option -- o
+   grep: illegal option -- o
+   Usage: grep -hblcnsviw pattern file . . .
+
      + +

      The solution for this problem is the same for both your tool and the system + version: use the '--' marker. When the user specifies '--' on + the command line, it is telling the program that all options after the + '--' should be treated as positional arguments, not options. Thus, we + can use it like this:

      + + 
      +   $ spiffygrep -- -foo test.txt
+     ...output...
+
      + +
      + + +
      + The cl::ConsumeAfter modifier +
      + +
      + +

      The cl::ConsumeAfter formatting option is + used to construct programs that use "interpreter style" option processing. With + this style of option processing, all arguments specified after the last + positional argument are treated as special interpreter arguments that are not + interpreted by the command line argument.

      + +

      As a concrete example, lets say we are developing a replacement for the + standard Unix Bourne shell (/bin/sh). To run /bin/sh, first + you specify options to the shell itself (like -x which turns on trace + output), then you specify the name of the script to run, then you specify + arguments to the script. These arguments to the script are parsed by the bourne + shell command line option processor, but are not interpreted as options to the + shell itself. Using the CommandLine library, we would specify this as:

      + + 
      + cl::opt<string> Script(cl::Positional, cl::desc("<input script>"), cl::init("-"));
+ cl::list<string>  Argv(cl::ConsumeAfter, cl::desc("<program arguments>..."));
+ cl::opt<bool>    Trace("x", cl::desc("Enable trace output"));
+
      + +

      which automatically provides the help output:

      + + 
      + USAGE: spiffysh [options] <input script> <program arguments>...
+ 
+ OPTIONS:
+   -help - display available options (--help-hidden for more)
+   -x    - Enable trace output
+
      + +

      At runtime, if we run our new shell replacement as 'spiffysh -x test.sh + -a -x -y bar', the Trace variable will be set to true, the + Script variable will be set to "test.sh", and the + Argv list will contain ["-a", "-x", "-y", "bar"], because they + were specified after the last positional argument (which is the script + name).

      + +

      There are several limitations to when cl::ConsumeAfter options can + be specified. For example, only one cl::ConsumeAfter can be specified + per program, there must be at least one positional + argument specified, and the cl::ConsumeAfter option should be a 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, + especially when combined with the ability to define command line options in the + files that use them. This is called the internal storage model.

      + +

      Sometimes, however, it is nice to separate the command line option processing + code from the storage of the value parsed. For example, lets say that we have a + '-debug' option that we would like to use to enable debug information + across the entire body of our program. In this case, the boolean value + controlling the debug code should be globally accessable (in a header file, for + example) yet the command line option processing code should not be exposed to + all of these clients (requiring lots of .cpp files to #include + CommandLine.h).

      + +

      To do this, set up your .h file with your option, like this for example:

      + + 
      + // DebugFlag.h - Get access to the '-debug' command line option
+ //
+ 
+ // DebugFlag - This boolean is set to true if the '-debug' command line option
+ // is specified.  This should probably not be referenced directly, instead, use
+ // the DEBUG macro below.
+ //
+ extern bool DebugFlag;
+ 
+ // DEBUG macro - This macro should be used by code to emit debug information.
+ // In the '-debug' option is specified on the command line, and if this is a
+ // debug build, then the code specified as the option to the macro will be
+ // executed.  Otherwise it will not be.  Example:
+ //
+ // DEBUG(cerr << "Bitset contains: " << Bitset << "\n");
+ //
+ #ifdef NDEBUG
+ #define DEBUG(X)
+ #else
+ #define DEBUG(X) \
+   do { if (DebugFlag) { X; } } while (0)
+ #endif
+
      + +

      This allows clients to blissfully use the DEBUG() macro, or the + DebugFlag explicitly if they want to. Now we just need to be able to + set the DebugFlag boolean when the option is set. To do this, we pass + an additial argument to our command line argument processor, and we specify + where to fill in with the cl::location + attribute:

      + + 
      + bool DebugFlag;      // the actual value
+ static cl::opt<bool, true>       // The parser
+ Debug("debug", cl::desc("Enable debug output"), cl::Hidden,
+       cl::location(DebugFlag));
+
      + +

      In the above example, we specify "true" as the second argument to + the cl::opt template, indicating that the template should + not maintain a copy of the value itself. In addition to this, we specify the cl::location attribute, so that DebugFlag is + automatically set.

      + +
      + + +
      + Option Attributes +
      + +
      + +

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

      + +
        + +
      • The option name attribute (which is required for all options, except positional options) specifies what the option name is. + This option is specified in simple double quotes: + + 
        + cl::opt<bool> Quiet("quiet");
+
        + +
        • + +
      • The cl::desc attribute specifies a + description for the option to be shown in the --help output for the + program.
        • + +
      • The cl::value_desc attribute + specifies a string that can be used to fine tune the --help output for + a command line option. Look here for an + example.
        • + +
      • The cl::init attribute specifies an + inital value for a scalar option. If this attribute is + not specified then the command line option value defaults to the value created + by the default constructor for the type. Warning: If you specify both + cl::init and cl::location for an option, + you must specify cl::location first, so that when the + command-line parser sees cl::init, it knows where to put the + initial value. (You will get an error at runtime if you don't put them in + the right order.)
        • + +
      • The cl::location attribute where to + store the value for a parsed command line option if using external storage. See + the section on Internal vs External Storage for more + information.
        • + +
      • The cl::aliasopt attribute + specifies which option a cl::alias option is an alias + for.
        • + +
      • The cl::values attribute specifies + the string-to-value mapping to be used by the generic parser. It takes a + null terminated list of (option, value, description) triplets that + specify the option name, the value mapped to, and the description shown in the + --help for the tool. Because the generic parser is used most + frequently with enum values, two macros are often useful: + +
          + +
        1. The clEnumVal macro is used as a + nice simple way to specify a triplet for an enum. This macro automatically + makes the option name be the same as the enum name. The first option to the + macro is the enum, the second is the description for the command line + option.
          2. + +
        2. The clEnumValN macro is used to + specify macro options where the option name doesn't equal the enum name. For + this macro, the first argument is the enum value, the second is the flag name, + and the second is the description.
          3. + +
        + + You will get a compile time error if you try to use cl::values with a parser + that does not support it.
        • + +
      + +
      + + +
      + Option Modifiers +
      + +
      + +

      Option modifiers are the flags and expressions that you pass into the + constructors for cl::opt and cl::list. These modifiers give you the ability to + tweak how options are parsed and how --help output is generated to fit + your application well.

      + +

      These options fall into five main catagories:

      + +
        +
      1. Hiding an option from --help output
        2. +
      2. Controlling the number of occurrences + required and allowed
        3. +
      3. Controlling whether or not a value must be + specified
        4. +
      4. Controlling other formatting options
        5. +
      5. Miscellaneous option modifiers
        6. +
      + +

      It is not possible to specify two options from the same catagory (you'll get + a runtime error) to a single option, except for options in the miscellaneous + catagory. The CommandLine library specifies defaults for all of these settings + that are the most useful in practice and the most common, which mean that you + usually shouldn't have to worry about these.

      + +
      + + +
      + Hiding an option from --help output +
      + +
      + +

      The cl::NotHidden, cl::Hidden, and + cl::ReallyHidden modifiers are used to control whether or not an option + appears in the --help and --help-hidden output for the + compiled program:

      + +
        + +
      • The cl::NotHidden modifier + (which is the default for cl::opt and cl::list options), indicates the option is to appear + in both help listings.
        • + +
      • The cl::Hidden modifier (which is the + default for cl::alias options), indicates that + the option should not appear in the --help output, but should appear in + the --help-hidden output.
        • + +
      • The cl::ReallyHidden modifier, + 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 + value for this setting allows the CommandLine library to do error checking for + you.

      + +

      The allowed values for this option group are:

      + +
        + +
      • The cl::Optional modifier (which + is the default for the cl::opt and cl::alias classes) indicates that your program will + allow either zero or one occurrence of the option to be specified.
        • + +
      • The cl::ZeroOrMore modifier + (which is the default for the cl::list class) + indicates that your program will allow the option to be specified zero or more + times.
        • + +
      • The cl::Required modifier + indicates that the specified option must be specified exactly one time.
        • + +
      • The cl::OneOrMore modifier + indicates that the option must be specified at least one time.
        • + +
      • The cl::ConsumeAfter modifier is described in the Positional arguments section
        • + +
      + +

      If an option is not specified, then the value of the option is equal to the + value specified by the cl::init attribute. If + the cl::init attribute is not specified, the + option value is initialized with the default constructor for the data type.

      + +

      If an option is specified multiple times for an option of the cl::opt class, only the last value will be + 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 + specified with an equal sign (e.g. '-index-depth=17') or as a trailing + string (e.g. '-o a.out').

      + +

      The allowed values for this option group are:

      + +
        + +
      • The cl::ValueOptional modifier + (which is the default for bool typed options) specifies that it is + acceptable to have a value, or not. A boolean argument can be enabled just by + appearing on the command line, or it can have an explicit '-foo=true'. + If an option is specified with this mode, it is illegal for the value to be + provided without the equal sign. Therefore '-foo true' is illegal. To + get this behavior, you must use the cl::ValueRequired modifier.
        • + +
      • The cl::ValueRequired modifier + (which is the default for all other types except for unnamed alternatives using the generic parser) + specifies that a value must be provided. This mode informs the command line + library that if an option is not provides with an equal sign, that the next + argument provided must be the value. This allows things like '-o + a.out' to work.
        • + +
      • The cl::ValueDisallowed + modifier (which is the default for unnamed + alternatives using the generic parser) indicates that it is a runtime error + for the user to specify a value. This can be provided to disallow users from + providing options to boolean options (like '-foo=true').
        • + +
      + +

      In general, the default values for this option group work just like you would + want them to. As mentioned above, you can specify the cl::ValueDisallowed modifier to a boolean + argument to restrict your command line parser. These options are mostly useful + 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 + arguments. As usual, you can only specify at most one of these arguments.

      + +
        + +
      • The cl::NormalFormatting + modifier (which is the default all options) specifies that this option is + "normal".
        • + +
      • The cl::Positional modifier + specifies that this is a positional argument, that does not have a command line + option associated with it. See the Positional + Arguments section for more information.
        • + +
      • The cl::ConsumeAfter modifier + specifies that this option is used to capture "interpreter style" arguments. See this section for more information.
        • + +
      • The cl::Prefix modifier specifies + that this option prefixes its value. With 'Prefix' options, there is no equal + sign that separates the value from the option name specified. This is useful + for processing odd arguments like '-lmalloc -L/usr/lib' in a linker + tool. Here, the 'l' and 'L' options are normal string (list) + options, that have the cl::Prefix modifier added to + allow the CommandLine library to recognize them. Note that cl::Prefix options must not have the cl::ValueDisallowed modifier specified.
        • + +
      • The cl::Grouping modifier is used + to implement unix style tools (like ls) that have lots of single letter + arguments, but only require a single dash. For example, the 'ls -labF' + command actually enables four different options, all of which are single + letters. Note that cl::Grouping options cannot have + values.
        • + +
      + +

      The CommandLine library does not restrict how you use the cl::Prefix or cl::Grouping + modifiers, but it is possible to specify ambiguous argument settings. Thus, it + is possible to have multiple letter options that are prefix or grouping options, + and they will still work as designed.

      + +

      To do this, the CommandLine library uses a greedy algorithm to parse the + input option into (potentially multiple) prefix and grouping options. The + strategy basically looks like this:

      + +

      parse(string OrigInput) { +

        +
      1. string input = OrigInput; +
      2. if (isOption(input)) return getOption(input).parse();    // Normal option +
      3. while (!isOption(input) && !input.empty()) input.pop_back();    // Remove the last letter +
      4. if (input.empty()) return error();    // No matching option +
      5. if (getOption(input).isPrefix())
        +   return getOption(input).parse(input);         +
      6. while (!input.empty()) {    // Must be grouping options
        +   getOption(input).parse();
        +   OrigInput.erase(OrigInput.begin(), OrigInput.begin()+input.length());
        +   input = OrigInput;
        +   while (!isOption(input) && !input.empty()) input.pop_back();
        + }         +
      7. if (!OrigInput.empty()) error(); + + +
      + }

      + +
      + + +
      + 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 + specify boolean properties that modify the option.

      + +
        + +
      • The cl::CommaSeparated modifier + indicates that any commas specified for an option's value should be used to + split the value up into multiple values for the option. For example, these two + options are equivalent when cl::CommaSeparated is specified: + "-foo=a -foo=b -foo=c" and "-foo=a,b,c". This option only + makes sense to be used in a case where the option is allowed to accept one or + more values (i.e. it is a cl::list option).
        • + +
      + +

      So far, the only miscellaneous option modifier is the + cl::CommaSeparated modifier.

      + +
      + + +
      + Top-Level Classes and Functions +
      + +
      + +

      Despite all of the built-in flexibility, the CommandLine option library + really only consists of one function (cl::ParseCommandLineOptions) + and three main classes: cl::opt, 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 + command line option variables once argc and argv are + available.

      + +

      The cl::ParseCommandLineOptions function requires two parameters + (argc and argv), but may also take an optional third parameter + which holds additional extra text to emit when the + --help option is invoked.

      + +
      + + +
      + The cl::ParseEnvironmentOptions + function +
      + +
      + +

      The cl::ParseEnvironmentOptions function has mostly the same effects + as cl::ParseCommandLineOptions, + except that it is designed to take values for options from an environment + variable, for those cases in which reading the command line is not convenient or + not desired. It fills in the values of all the command line option variables + just like cl::ParseCommandLineOptions + does.

      + +

      It takes three parameters: first, the name of the program (since + argv may not be available, it can't just look in argv[0]), + second, the name of the environment variable to examine, and third, the optional + additional extra text to emit when the + --help option is invoked.

      + +

      cl::ParseEnvironmentOptions will break the environment + variable's value up into words and then process them using + cl::ParseCommandLineOptions. + Note: Currently cl::ParseEnvironmentOptions does not support + quoting, so an environment variable containing -option "foo bar" will + be parsed as three words, -option, "foo, and bar", + which is different from what you would get from the shell with the same + input.

      + +
      + + +
      + 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 + can take up to three arguments (all except for the first have default values + though):

      + + 
      + namespace cl {
+   template <class DataType, bool ExternalStorage = false,
+             class ParserClass = parser<DataType> >
+   class opt;
+ }
+
      + +

      The first template argument specifies what underlying data type the command + line argument is, and is used to select a default parser implementation. The + second template argument is used to specify whether the option should contain + the storage for the option (the default) or whether external storage should be + used to contain the value parsed for the option (see Internal + vs External Storage for more information).

      + +

      The third template argument specifies which parser to use. The default value + selects an instantiation of the parser class based on the underlying + data type of the option. In general, this default works well for most + applications, so this option is only used when using a 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 + arguments:

      + + 
      + namespace cl {
+   template <class DataType, class Storage = bool,
+             class ParserClass = parser<DataType> >
+   class list;
+ }
+
      + +

      This class works the exact same as the cl::opt class, except that the second argument is + the type of the external storage, not a boolean value. For this class, + the marker type 'bool' is used to indicate that internal storage should + be used.

      + +
      + + +
      + The cl::alias class +
      + +
      + +

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

      + + 
      + namespace cl {
+   class alias;
+ }
+
      + +

      The cl::aliasopt attribute should be + used to specify which option this is an alias for. Alias arguments default to + being Hidden, and use the aliased options parser to do + the conversion from string to data.

      + +
      + + +
      + 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, + the CommandLine library uses an instance of parser<type> if the + command line option specifies that it uses values of type 'type'. + Because of this, custom option processing is specified with specializations of + the 'parser' class.

      + +

      The CommandLine library provides the following builtin parser + specializations, which are sufficient for most applications. It can, however, + also be extended to work with new data types and new ways of interpreting the + same data. See the Writing a Custom Parser for more + details on this type of library extension.

      + +
        + +
      • The generic parser<t> parser + can be used to map strings values to any data type, through the use of the cl::values property, which specifies the mapping + information. The most common use of this parser is for parsing enum values, + which allows you to use the CommandLine library for all of the error checking to + make sure that only valid enum values are specified (as opposed to accepting + arbitrary strings). Despite this, however, the generic parser class can be used + for any data type.
        • + +
      • The parser<bool> specialization + is used to convert boolean strings to a boolean value. Currently accepted + strings are "true", "TRUE", "True", "1", + "false", "FALSE", "False", and "0".
        • + +
      • The parser<string> + specialization simply stores the parsed string into the string value + specified. No conversion or modification of the data is performed.
        • + +
      • The parser<int> specialization + uses the C strtol function to parse the string input. As such, it will + accept a decimal number (with an optional '+' or '-' prefix) which must start + with a non-zero digit. It accepts octal numbers, which are identified with a + '0' prefix digit, and hexadecimal numbers with a prefix of + '0x' or '0X'.
        • + +
      • The parser<double> and + parser<float> specializations use the standard C + strtod function to convert floating point strings into floating point + values. As such, a broad range of string formats is supported, including + 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 + of the CommandLine library that turns string input from the user into a + particular parsed data type, validating the input in the process.

      + +

      There are two ways to use a new parser:

      + +
        + +
      1. + +

        Specialize the cl::parser template for + your custom data type.

        + +

        This approach has the advantage that users of your custom data type will + automatically use your custom parser whenever they define an option with a value + type of your data type. The disadvantage of this approach is that it doesn't + work if your fundemental data type is something that is already supported.

        + +
        2. + +
      2. + +

        Write an independent class, using it explicitly from options that need + it.

        + +

        This approach works well in situations where you would line to parse an + option using special syntax for a not-very-special data-type. The drawback of + this approach is that users of your parser have to be aware that they are using + your parser, instead of the builtin ones.

        + +
        3. + +
      + +

      To guide the discussion, we will discuss a custom parser that accepts file + sizes, specified with an optional unit after the numeric size. For example, we + would like to parse "102kb", "41M", "1G" into the appropriate integer value. In + this case, the underlying data type we want to parse into is + 'unsigned'. We choose approach #2 above because we don't want to make + this the default for all unsigned options.

      + +

      To start out, we declare our new FileSizeParser class:

      + + 
      + struct FileSizeParser : public cl::basic_parser<unsigned> {
+   // parse - Return true on error.
+   bool parse(cl::Option &O, const char *ArgName, const std::string &ArgValue,
+              unsigned &Val);
+ };
+
      + +

      Our new class inherits from the cl::basic_parser template class to + fill in the default, boiler plate, code for us. We give it the data type that + we parse into (the last argument to the parse method so that clients of + our custom parser know what object type to pass in to the parse method (here we + declare that we parse into 'unsigned' variables.

      + +

      For most purposes, the only method that must be implemented in a custom + parser is the parse method. The parse method is called + whenever the option is invoked, passing in the option itself, the option name, + the string to parse, and a reference to a return value. If the string to parse + is not well formed, the parser should output an error message and return true. + Otherwise it should return false and set 'Val' to the parsed value. In + our example, we implement parse as:

      + + 
      + bool FileSizeParser::parse(cl::Option &O, const char *ArgName,
+                            const std::string &Arg, unsigned &Val) {
+   const char *ArgStart = Arg.c_str();
+   char *End;
+  
+   // Parse integer part, leaving 'End' pointing to the first non-integer char
+   Val = (unsigned)strtol(ArgStart, &End, 0);
+ 
+   while (1) {
+     switch (*End++) {
+     case 0: return false;   // No error
+     case 'i':               // Ignore the 'i' in KiB if people use that
+     case 'b': case 'B':     // Ignore B suffix
+       break;
+ 
+     case 'g': case 'G': Val *= 1024*1024*1024; break;
+     case 'm': case 'M': Val *= 1024*1024;      break;
+     case 'k': case 'K': Val *= 1024;           break;
+ 
+     default:
+       // Print an error message if unrecognized character!
+       return O.error(": '" + Arg + "' value invalid for file size argument!");
+     }
+   }
+ }
+
      + +

      This function implements a very simple parser for the kinds of strings we are + interested in. Although it has some holes (it allows "123KKK" for + example), it is good enough for this example. Note that we use the option + itself to print out the error message (the error method always returns + true) in order to get a nice error message (shown below). Now that we have our + parser class, we can use it like this:

      + + 
      + static cl::opt<unsigned, false, FileSizeParser>
+ MFS("max-file-size", cl::desc("Maximum file size to accept"),
+     cl::value_desc("size"));
+
      + +

      Which adds this to the output of our program:

      + + 
      + OPTIONS:
+   -help                 - display available options (--help-hidden for more)
+   ...
+   -max-file-size=<size> - Maximum file size to accept
+
      + +

      And we can test that our parse works correctly now (the test program just + prints out the max-file-size argument value):

      + + 
      + $ ./test
+ MFS: 0
+ $ ./test -max-file-size=123MB
+ MFS: 128974848
+ $ ./test -max-file-size=3G
+ MFS: 3221225472
+ $ ./test -max-file-size=dog
+ -max-file-size option: 'dog' value invalid for file size argument!
+
      + +

      It looks like it works. The error message that we get is nice and helpful, + and we seem to accept reasonable file sizes. This wraps up the "custom parser" + tutorial.

      + +
      + + +
      + Exploiting external storage +
      + +
      + +

      TODO: fill in this section

      + +
      + + +
      + Dynamically adding command line options +
      + +
      + +

      TODO: fill in this section

      + +
      + + + +
      +
      +
      Chris Lattner
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/Debugging.gif Index: llvm-www/releases/1.2/docs/FAQ.html diff -c /dev/null llvm-www/releases/1.2/docs/FAQ.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/FAQ.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,490 ---- + + + + LLVM: Frequently Asked Questions + + + + +
      + LLVM: Frequently Asked Questions +
      + +
        +
      1. License +
          +
        1. Why are the LLVM source code and the front-end distributed under different + licenses?
          2. +
        2. Does the University of Illinois Open Source License really qualify as an + "open source" license?
          3. +
        3. Can I modify LLVM source code and redistribute the modified source?
          4. +
        4. Can I modify LLVM source code and redistribute binaries or other tools + based on it, without redistributing the source?
          5. +
        2. + +
      2. Source code +
          +
        1. In what language is LLVM written?
          2. +
        2. How portable is the LLVM source code?
          3. +
        3. + +
      3. Build Problems +
          +
        1. When I run configure, it finds the wrong C compiler.
          2. +
        2. I compile the code, and I get some error about /localhome.
          3. +
        3. The configure script finds the right C compiler, but it uses the + LLVM linker from a previous build. What do I do?
          4. +
        4. When creating a dynamic library, I get a strange GLIBC error.
          5. +
        5. I've updated my source tree from CVS, and now my build is trying to use a + file/directory that doesn't exist.
          6. +
        6. I've modified a Makefile in my source tree, but my build tree keeps using + the old version. What do I do?
          7. +
        7. I've upgraded to a new version of LLVM, and I get strange build + errors.
          8. +
        8. I've built LLVM and am testing it, but the tests freeze.
          9. +
        9. Why do test results differ when I perform different types of builds?
          10. +
        10. Compiling LLVM with GCC 3.3.2 fails, what should I do?
          11. +
        11. When I use the test suite, all of the C Backend tests fail. What is + wrong?
          12. +
        4. + +
      4. Using the GCC Front End +
          +
        1. + When I compile software that uses a configure script, the configure script + thinks my system has all of the header files and libraries it is testing + for. How do I get configure to work correctly? +
          2. + +
        2. + When I compile code using the LLVM GCC front end, it complains that it + cannot find crtend.o. +
          3. +
        +
        5. + +
      5. Questions about code generated by the GCC front-end +
          +
        1. What is this __main() call that gets inserted into + main()?
          2. +
        2. Where did all of my code go??
          3. +
        +
        6. +
      + + +
      + License +
      + + +
      +

      Why are the LLVM source code and the front-end distributed under different + licenses?

      +
      + +
      +

      The C/C++ front-ends are based on GCC and must be distributed under the GPL. + Our aim is to distribute LLVM source code under a much less restrictive + license, in particular one that does not compel users who distribute tools based + on modifying the source to redistribute the modified source code as well.

      +
      + +
      +

      Does the University of Illinois Open Source License really qualify as an + "open source" license?

      +
      + +
      +

      Yes, the license is certified by the Open + Source Initiative (OSI).

      +
      + +
      +

      Can I modify LLVM source code and redistribute the modified source?

      +
      + +
      +

      Yes. The modified source distribution must retain the copyright notice and + follow the three bulletted conditions listed in the LLVM license.

      +
      + +
      +

      Can I modify LLVM source code and redistribute binaries or other tools based + on it, without redistributing the source?

      +
      + +
      +

      Yes, this is why we distribute LLVM under a less restrictive license than + GPL, as explained in the first question above.

      +
      + + +
      + Source Code +
      + + +
      +

      In what language is LLVM written?

      +
      + +
      +

      All of the LLVM tools and libraries are written in C++ with extensive use of + the STL.

      +
      + +
      +

      How portable is the LLVM source code?

      +
      + +
      +

      The LLVM source code should be portable to most modern UNIX-like operating + systems. Most of the code is written in standard C++ with operating system + services abstracted to a support library. The tools required to build and test + LLVM have been ported to a plethora of platforms.

      + +

      Some porting problems may exist in the following areas:

      + +
        + +
      • The GCC front end code is not as portable as the LLVM suite, so it may not + compile as well on unsupported platforms.
        • + +
      • The Python test classes are more UNIX-centric than they should be, so + porting to non-UNIX like platforms (i.e. Windows, MacOS 9) will require some + effort.
        • + +
      • The LLVM build system relies heavily on UNIX shell tools, like the Bourne + Shell and sed. Porting to systems without these tools (MacOS 9, Plan 9) will + require more effort.
        • + +
      + +
      + + +
      + Build Problems +
      + + +
      +

      When I run configure, it finds the wrong C compiler.

      +
      + +
      + +

      The configure script attempts to locate first gcc and then + cc, unless it finds compiler paths set in CC and CXX + for the C and C++ compiler, respectively.

      + +

      If configure finds the wrong compiler, either adjust your + PATH environment variable or set CC and CXX + explicitly.

      + +
      + +
      +

      I compile the code, and I get some error about /localhome.

      +
      + +
      + +

      There are several possible causes for this. The first is that you didn't set + a pathname properly when using configure, and it defaulted to a + pathname that we use on our research machines.

      + +

      Another possibility is that we hardcoded a path in our Makefiles. If you see + this, please email the LLVM bug mailing list with the name of the offending + Makefile and a description of what is wrong with it.

      + +
      + +
      +

      The configure script finds the right C compiler, but it uses the + LLVM linker from a previous build. What do I do?

      +
      + +
      +

      The configure script uses the PATH to find executables, so + if it's grabbing the wrong linker/assembler/etc, there are two ways to fix + it:

      + +
        + +

      1. Adjust your PATH environment variable so that the correct + program appears first in the PATH. This may work, but may not be + convenient when you want them first in your path for other + work.

        2. + +

      2. Run configure with an alternative PATH that is + correct. In a Borne compatible shell, the syntax would be:

        + +

        PATH= ./configure ...

        + +

        This is still somewhat inconvenient, but it allows configure + to do its work without having to adjust your PATH + permanently.

        3. + +
      + +
      + +
      +

      When creating a dynamic library, I get a strange GLIBC error.

      +
      + +
      +

      Under some operating systems (i.e. Linux), libtool does not work correctly if + GCC was compiled with the --disable-shared option. To work around this, install + your own version of GCC that has shared libraries enabled by default.

      +
      + +
      +

      I've updated my source tree from CVS, and now my build is trying to use a + file/directory that doesn't exist.

      +
      + +
      +

      You need to re-run configure in your object directory. When new Makefiles + are added to the source tree, they have to be copied over to the object tree in + order to be used by the build.

      +
      + +
      +

      I've modified a Makefile in my source tree, but my build tree keeps using the + old version. What do I do?

      +
      + +
      + +

      If the Makefile already exists in your object tree, you + can just run the following command in the top level directory of your object + tree:

      + +

      ./config.status <relative path to Makefile>

      + +

      If the Makefile is new, you will have to modify the configure script to copy + it over.

      + +
      + +
      +

      I've upgraded to a new version of LLVM, and I get strange build errors.

      +
      + +
      + +

      Sometimes, changes to the LLVM source code alters how the build system works. + Changes in libtool, autoconf, or header file dependencies are especially prone + to this sort of problem.

      + +

      The best thing to try is to remove the old files and re-build. In most + cases, this takes care of the problem. To do this, just type make + clean and then make in the directory that fails to build.

      + +
      + +
      +

      I've built LLVM and am testing it, but the tests freeze.

      +
      + +
      + +

      This is most likely occurring because you built a profile or release + (optimized) build of LLVM and have not specified the same information on the + gmake command line.

      + +

      For example, if you built LLVM with the command:

      + +

      gmake ENABLE_PROFILING=1 + +

      ...then you must run the tests with the following commands:

      + +

      cd llvm/test
      gmake ENABLE_PROFILING=1

      + +
      + +
      +

      Why do test results differ when I perform different types of builds?

      +
      + +
      + +

      The LLVM test suite is dependent upon several features of the LLVM tools and + libraries.

      + +

      First, the debugging assertions in code are not enabled in optimized or + profiling builds. Hence, tests that used to fail may pass.

      + +

      Second, some tests may rely upon debugging options or behavior that is only + available in the debug build. These tests will fail in an optimized or profile + build.

      + +
      + +
      +

      Compiling LLVM with GCC 3.3.2 fails, what should I do?

      +
      + +
      +

      This is a bug in GCC, and + affects projects other than LLVM. Try upgrading or downgrading your GCC.

      +
      + +
      +

      + When I use the test suite, all of the C Backend tests fail. What is + wrong? +

      +
      + +
      +

      + If you build LLVM and the C Backend tests fail in llvm/test/Programs, + then chances are good that the directory pointed to by the LLVM_LIB_SEARCH_PATH + environment variable does not contain the libcrtend.a library. +

      + +

      + To fix it, verify that LLVM_LIB_SEARCH_PATH points to the correct directory + and that libcrtend.a is inside. For pre-built LLVM GCC front ends, this + should be the absolute path to + cfrontend/<platform>/llvm-gcc/bytecode-libs. If you've + built your own LLVM GCC front end, then ensure that you've built and installed + the libraries in llvm/runtime and have LLVM_LIB_SEARCH_PATH pointing + to the LLVMGCCDIR/bytecode-libs subdirectory. +

      +
      + + +
      + Using the GCC Front End +
      + +
      +

      + When I compile software that uses a configure script, the configure script + thinks my system has all of the header files and libraries it is testing for. + How do I get configure to work correctly? +

      +
      + +
      +

      + The configure script is getting things wrong because the LLVM linker allows + symbols to be undefined at link time (so that they can be resolved during JIT + or translation to the C back end). That is why configure thinks your system + "has everything." +

      +

      + To work around this, perform the following steps: +

      + +
        +
      1. + Make sure the CC and CXX environment variables contains the full path to the + LLVM GCC front end. +
        2. + +
      2. + Make sure that the regular C compiler is first in your PATH. +
        3. + +
      3. + Add the string "-Wl,-native" to your CFLAGS environment variable. +
        4. +
      + +

      + This will allow the gccld linker to create a native code executable instead of + a shell script that runs the JIT. Creating native code requires standard + linkage, which in turn will allow the configure script to find out if code is + not linking on your system because the feature isn't available on your system. +

      +
      + +
      +

      + When I compile code using the LLVM GCC front end, it complains that it cannot + find libcrtend.a. +

      +
      + +
      +

      + In order to find libcrtend.a, you must have the directory in which it lives in + your LLVM_LIB_SEARCH_PATH environment variable. For the binary distribution of + the LLVM GCC front end, this will be the full path of the bytecode-libs + directory inside of the LLVM GCC distribution. +

      +
      + + + +
      + Questions about code generated by the GCC front-end +
      + +

      + What is this __main() call that gets inserted into main()? +

      + +
      +

      + The __main call is inserted by the C/C++ compiler in order to guarantee + that static constructors and destructors are called when the program starts up + and shuts down. In C, you can create static constructors and destructors by + using GCC extensions, and in C++ you can do so by creating a global variable + whose class has a ctor or dtor. +

      + +

      + The actual implementation of __main lives in the + llvm/runtime/GCCLibraries/crtend/ directory in the source-base, and is + linked in automatically when you link the program. +

      +
      + + + +

      + Where did all of my code go?? +

      + +
      +

      + If you are using the LLVM demo page, you may often wonder what happened to all + of the code that you typed in. Remember that the demo script is running the + code through the LLVM optimizers, so if your code doesn't actually do anything + useful, it might all be deleted. +

      + +

      + To prevent this, make sure that the code is actually needed. For example, if + you are computing some expression, return the value from the function instead of + leaving it in a local variable. If you really want to constrain the optimizer, + you can read from and assign to volatile global variables. +

      +
      + + + + +
      +
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/GettingStarted.html diff -c /dev/null llvm-www/releases/1.2/docs/GettingStarted.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/GettingStarted.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,1190 ---- + + + + Getting Started with LLVM System + + + + +
      + Getting Started with the LLVM System +
      + + + +

      By: + Guochun Shi, + Chris Lattner, + John Criswell, + Misha Brukman, and + Vikram Adve.

      + + + +
      + Overview +
      + + +
      + +

      Welcome to LLVM! In order to get started, you first need to know some + basic information.

      + +

      First, LLVM comes in two pieces. The first piece is the LLVM suite. This + contains all of the tools, libraries, and header files needed to use the low + level virtual machine. It contains an assembler, disassembler, bytecode + analyzer, and bytecode optimizer. It also contains a test suite that can be + used to test the LLVM tools and the GCC front end.

      + +

      The second piece is the GCC front end. This component provides a version of + GCC that compiles C and C++ code into LLVM bytecode. Currently, the GCC front + end is a modified version of GCC 3.4 (we track the GCC 3.4 development). Once + compiled into LLVM bytecode, a program can be manipulated with the LLVM tools + from the LLVM suite.

      + +
      + + +
      + Getting Started Quickly (A Summary) +
      + + +
      + +

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

      + +
        +
      1. Install the GCC front end: +
          +
        1. cd where-you-want-the-C-front-end-to-live +
        2. gunzip --stdout cfrontend.platform.tar.gz | tar -xvf - +
        3. Sparc and MacOS X Only:
          + cd cfrontend/platform
          + ./fixheaders           +
        2. + +
      2. Get the Source Code +
          +
        • With the distributed files: +
            +
          1. cd where-you-want-llvm-to-live +
          2. gunzip --stdout llvm-version.tar.gz | tar -xvf - +
          3. cd llvm +
          • + +
        • With anonymous CVS access: +
            +
          1. cd where-you-want-llvm-to-live
            2. +
          2. cvs -d + :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login
            3. +
          3. Hit the return key when prompted for the password. +
          4. cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm + co llvm
            5. +
          5. cd llvm
            6. +
          • +
        3. + +
      3. Configure the LLVM Build Environment +
          +
        1. Change directory to where you want to store the LLVM object + files and run configure to configure the Makefiles and + header files for the default platform. Useful options include: +
            +
          • --with-llvmgccdir=directory +

            Specify the full pathname of where the LLVM GCC frontend is + installed.

            • +
          • --enable-spec2000=directory +

            Enable the SPEC2000 benchmarks for testing. The SPEC2000 + benchmarks should be available in + directory.

            • +
          +
        4. + +
      4. Build the LLVM Suite: +
          +
        1. Set your LLVM_LIB_SEARCH_PATH environment variable. +
        2. gmake -k |& tee gnumake.out +    # this is csh or tcsh syntax +
        + +
      + +

      Consult the Getting Started with LLVM section for + detailed information on configuring and compiling LLVM. See Setting Up Your Environment for tips that simplify + working with the GCC front end and LLVM tools. Go to Program + Layout to learn about the layout of the source code tree.

      + +
      + + +
      + 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 +
      + +
      + +

      LLVM is known to work on the following platforms:

      + +
        + +
      • Linux on x86 (Pentium and above) +
          +
        • Approximately 918 MB of Free Disk Space +
            +
          • Source code: 28 MB
            • +
          • Object code: 850 MB
            • +
          • GCC front end: 40 MB
            • +
          • +
        +
        • + +
      • Solaris on SparcV9 (Ultrasparc) +
          +
        • Approximately 1.52 GB of Free Disk Space +
            +
          • Source code: 28 MB
            • +
          • Object code: 1470 MB
            • +
          • GCC front end: 50 MB
            • +
          • +
        +
        • + +
      • FreeBSD on x86 (Pentium and above) +
          +
        • Approximately 918 MB of Free Disk Space +
            +
          • Source code: 28 MB
            • +
          • Object code: 850 MB
            • +
          • GCC front end: 40 MB
            • +
          • +
        +
        • + +
      • MacOS X on PowerPC +
          +
        • No native code generation +
        • Approximately 1.20 GB of Free Disk Space +
            +
          • Source code: 28 MB
            • +
          • Object code: 1160 MB
            • +
          • GCC front end: 40 MB
            • +
          • +
        + +
        • +
      + +

      The LLVM suite may compile on other platforms, but it is not + guaranteed to do so. If compilation is successful, the LLVM utilities should be + able to assemble, disassemble, analyze, and optimize LLVM bytecode. Code + generation should work as well, although the generated native code may not work + on your platform.

      + +

      The GCC front end is not very portable at the moment. If you want to get it + to work on another platform, you can download a copy of the source and try to + compile it on your platform.

      + +
      + + +
      + Software +
      + +
      + +

      Compiling LLVM requires that you have several software packages + installed:

      + + + +

      There are some additional tools that you may want to have when working with + LLVM:

      + +
        +
      • GNU Automake
        • +
      • GNU Autoconf
        • +
      • GNU M4 + +

        If you want to make changes to the configure scripts, you will need GNU + autoconf (2.57 or higher), and consequently, GNU M4 (version 1.4 or + higher). You will also need automake. Any old version of + automake from 1.4p5 on should work; we only use aclocal from that + package.

        • + +
      • QMTest 2.0.3
        • +
      • Python + +

        + These are needed to use the LLVM test suite. Please note that newer + versions of QMTest may not work with the LLVM test suite. QMTest 2.0.3 + can be retrieved from the QMTest CVS repository using the following + commands: +

          +
        • cvs -d :pserver:anoncvs at cvs.codesourcery.com:/home/qm/Repository login +
          • +
        • When prompted, use anoncvs as the password. +
          • +
        • cvs -d :pserver:anoncvs at cvs.codesourcery.com:/home/qm/Repository co -r release-2-0-3 qm +
          • +
        +

        • + +
      + +

      The remainder of this guide is meant to get you up and running with + LLVM and to give you some basic information about the LLVM environment. + A complete guide to installation is provided in the + next section.

      + +

      The later sections of this guide describe the 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.

      + +
      + + +
      + Getting Started with LLVM +
      + + + +
      + 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 + environment variables you need to set but just strings used in the rest + of this document below. In any of the examples below, simply replace + each of these names with the appropriate pathname on your local system. + All these paths are absolute:

      + +
      +
      SRC_ROOT +
      + This is the top level directory of the LLVM source tree. +

      + +

      OBJ_ROOT +
      + This is the top level directory of the LLVM object tree (i.e. the + tree where object files and compiled programs will be placed. It + can be the same as SRC_ROOT). +

      + +

      LLVMGCCDIR +
      + This is the where the LLVM GCC Front End is installed. +

      + For the pre-built GCC front end binaries, the LLVMGCCDIR is + cfrontend/platform/llvm-gcc. +

      + +
      + + +
      + Setting Up Your Environment +
      + +
      + +

      + In order to compile and use LLVM, you will need to set some environment + variables. There are also some shell aliases which you may find useful. + You can set these on the command line, or better yet, set them in your + .cshrc or .profile. + +

      +
      LLVM_LIB_SEARCH_PATH=LLVMGCCDIR/bytecode-libs +
      + This environment variable helps the LLVM GCC front end find bytecode + libraries that it will need for compilation. +

      + +

      alias llvmgcc LLVMGCCDIR/bin/gcc +
      alias llvmg++ LLVMGCCDIR/bin/g++ +
      + This alias allows you to use the LLVM C and C++ front ends without putting + them in your PATH or typing in their complete pathnames. +
      + +
      + + +
      + Unpacking the LLVM Archives +
      + +
      + +

      + If you have the LLVM distribution, you will need to unpack it before you + can begin to compile it. LLVM is distributed as a set of two files: the LLVM + suite and the LLVM GCC front end compiled for your platform. Each + file is a TAR archive that is compressed with the gzip program. +

      + +

      The files are as follows: +

      +
      llvm-1.2.tar.gz +
      This is the source code to the LLVM suite. +

      + +

      cfrontend-1.2.sparc-sun-solaris2.8.tar.gz +
      This is the binary release of the GCC front end for Solaris/Sparc. +

      + +

      cfrontend-1.2.i686-redhat-linux-gnu.tar.gz +
      This is the binary release of the GCC front end for Linux/x86. +

      + +

      cfrontend-1.2.i386-unknown-freebsd5.1.tar.gz +
      This is the binary release of the GCC front end for FreeBSD/x86. +

      + +

      cfrontend-1.2.powerpc-apple-darwin7.0.0.tar.gz +
      This is the binary release of the GCC front end for MacOS X/PPC. +
      + +
      + + +
      + Checkout LLVM from CVS +
      + +
      + +

      If you have access to our CVS repository, you can get a fresh copy of + the entire source code. All you need to do is check it out from CVS as + follows:

      + +
        +
      • cd where-you-want-llvm-to-live +
      • cvs -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login +
      • Hit the return key when prompted for the password. +
      • cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co + llvm +
      + +

      This will create an 'llvm' directory in the current + directory and fully populate it with the LLVM source code, Makefiles, + test directories, and local copies of documentation files.

      + +

      If you want to get a specific release (as opposed to the most recent + revision), you can specify a label. The following releases have the following + label:

      + +
        +
      • + Release 1.2: RELEASE_12 +
        • + +
      • + Release 1.1: RELEASE_11 +
        • + +
      • + Release 1.0: RELEASE_1 +
        • +
      + +

      + If you would like to get the GCC front end source code, you can also get it + from the CVS repository: +

        +
      • cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co + llvm-gcc +
      +

      + +
      + + +
      + Install the GCC Front End +
      + +
      + +

      Before configuring and compiling the LLVM suite, you need to extract the LLVM + GCC front end from the binary distribution. It is used for building the + bytecode libraries later used by the GCC front end for linking programs, and its + location must be specified when the LLVM suite is configured.

      + +

      To install the GCC front end, do the following:

      + +
        +
      1. cd where-you-want-the-front-end-to-live
        2. +
      2. gunzip --stdout cfrontend-version.platform.tar.gz | tar -xvf + -
        3. +
      + +

      If you are using Solaris/Sparc or MacOS X/PPC, you will need to fix the + header files:

      + +

      cd cfrontend/platform
      + ./fixheaders

      + +

      The binary versions of the GCC front end may not suit all of your needs. For + example, the binary distribution may include an old version of a system header + file, not "fix" a header file that needs to be fixed for GCC, or it may be + linked with libraries not available on your system.

      + +

      In cases like these, you may want to try building the GCC front end from source. This is + not for the faint of heart, so be forewarned.

      + +
      + + +
      + Local LLVM Configuration +
      + +
      + +

      Once checked out from the CVS repository, the LLVM suite source code must be + configured via the configure script. This script sets variables in + llvm/Makefile.config and llvm/include/Config/config.h. It + also populates OBJ_ROOT with the Makefiles needed to begin building + LLVM.

      + +

      The following environment variables are used by the configure + script to configure the build system:

      + + + + + + + + + + + + + + + + +
      VariablePurpose
      CCTells configure which C compiler to use. By default, + configure will look for the first GCC C compiler in + PATH. Use this variable to override + configure's default behavior.
      CXXTells configure which C++ compiler to use. By default, + configure will look for the first GCC C++ compiler in + PATH. Use this variable to override + configure's default behavior.
      + +

      The following options can be used to set or enable LLVM specific options:

      + +
      +
      --with-llvmgccdir=LLVMGCCDIR +
      + Path to the location where the LLVM GCC front end binaries and + associated libraries were installed. This must be specified as an + absolute pathname. +

      +

      --enable-optimized +
      + Enables optimized compilation by default (debugging symbols are removed + and GCC optimization flags are enabled). The default is to use an + unoptimized build (also known as a debug build). +

      +

      --enable-jit +
      + Compile the Just In Time (JIT) compiler functionality. This is not + available + on all platforms. The default is dependent on platform, so it is best + to explicitly enable it if you want it. +

      +

      --enable-spec2000 +
      --enable-spec2000=<directory> +
      + Enable the use of SPEC2000 when testing LLVM. This is disabled by default + (unless configure finds SPEC2000 installed). By specifying + directory, you can tell configure where to find the SPEC2000 + benchmarks. If directory is left unspecified, configure + uses the default value + /home/vadve/shared/benchmarks/speccpu2000/benchspec. +

      +

      --enable-spec95 +
      --enable-spec95=<directory> +
      + Enable the use of SPEC95 when testing LLVM. It is similar to the + --enable-spec2000 option. +

      +

      --enable-povray +
      --enable-povray=<directory> +
      + Enable the use of Povray as an external test. Versions of Povray written + in C should work. This option is similar to the --enable-spec2000 + option. +
      + +

      To configure LLVM, follow these steps:

      + +
        +
      1. Change directory into the object root directory: +
        + cd OBJ_ROOT +

        + +

      2. Run the configure script located in the LLVM source tree: +
        + SRC_ROOT/configure +

        +

      + +

      In addition to running configure, you must set the + LLVM_LIB_SEARCH_PATH environment variable in your startup scripts. + This environment variable is used to locate "system" libraries like + "-lc" and "-lm" when linking. This variable should be set to + the absolute path of the bytecode-libs subdirectory of the GCC front + end, or LLVMGCCDIR/bytecode-libs. For example, one might set + LLVM_LIB_SEARCH_PATH to + /home/vadve/lattner/local/x86/llvm-gcc/bytecode-libs for the x86 + version of the GCC front end on our research machines.

      + +
      + + +
      + Compiling the LLVM Suite Source Code +
      + +
      + +

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

      + +
      +
      Debug Builds +
      + These builds are the default when one types gmake (unless the + --enable-optimized option was used during configuration). The + build system will compile the tools and libraries with debugging + information. +

      + +

      Release (Optimized) Builds +
      + These builds are enabled with the --enable-optimized option to + configure or by specifying ENABLE_OPTIMIZED=1 on the + gmake command line. For these builds, the build system will + compile the tools and libraries with GCC optimizations enabled and strip + debugging information from the libraries and executables it generates. +

      + +

      Profile Builds +
      + These builds are for use with profiling. They compile profiling + information into the code for use with programs like gprof. + Profile builds must be started by specifying ENABLE_PROFILING=1 + on the gmake command line. +
      + +

      Once you have LLVM configured, you can build it by entering the + OBJ_ROOT directory and issuing the following command:

      + +

      gmake

      + +

      If you have multiple processors in your machine, you may wish to use some of + the parallel build options provided by GNU Make. For example, you could use the + command:

      + +

      gmake -j2

      + +

      There are several special targets which are useful when working with the LLVM + source code:

      + +
      +
      gmake clean +
      + Removes all files generated by the build. This includes object files, + generated C/C++ files, libraries, and executables. +

      + +

      gmake distclean +
      + Removes everything that gmake clean does, but also removes + files generated by configure. It attempts to return the + source tree to the original state in which it was shipped. +

      + +

      gmake install +
      + Installs LLVM files into the proper location. For the most part, + this does nothing, but it does install bytecode libraries into the + GCC front end's bytecode library directory. If you need to update + your bytecode libraries, this is the target to use once you've built + them. +

      +

      + +

      It is also possible to override default values from configure by + declaring variables on the command line. The following are some examples:

      + +
      +
      gmake ENABLE_OPTIMIZED=1 +
      + Perform a Release (Optimized) build. +

      + +

      gmake ENABLE_PROFILING=1 +
      + Perform a Profiling build. +

      + +

      gmake VERBOSE=1 +
      + Print what gmake is doing on standard output. +

      +

      + +

      Every directory in the LLVM object tree includes a Makefile to build + it and any subdirectories that it contains. Entering any directory inside the + LLVM object tree and typing gmake should rebuild anything in or below + 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 + platforms or configurations using the same source tree.

      + +

      This is accomplished in the typical autoconf manner:

      + +
        +

      • Change directory to where the LLVM object files should live:

        + +

        cd OBJ_ROOT

        • + +

      • Run the configure script found in the LLVM source + directory:

        + +

        SRC_ROOT/configure

        • +
      + +

      The LLVM build will place files underneath OBJ_ROOT in directories + named after the build type:

      + +
      +
      Debug Builds +
      +
      +
      Tools +
      OBJ_ROOT/tools/Debug +
      Libraries +
      OBJ_ROOT/lib/Debug +
      +

      + +

      Release Builds +
      +
      +
      Tools +
      OBJ_ROOT/tools/Release +
      Libraries +
      OBJ_ROOT/lib/Release +
      +

      + +

      Profile Builds +
      +
      +
      Tools +
      OBJ_ROOT/tools/Profile +
      Libraries +
      OBJ_ROOT/lib/Profile +
      +
      + +
      + + +
      + Program Layout +
      + + +
      + +

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

      + +
      + + +
      + CVS directories +
      + +
      + +

      Every directory checked out of CVS will contain a CVS directory; for + the most part these can just be ignored.

      + +
      + + +
      + llvm/include +
      + +
      + +

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

      + +
        +
      1. llvm/include/llvm - This directory contains all of the LLVM + specific header files. This directory also has subdirectories for + different portions of LLVM: Analysis, CodeGen, + Target, Transforms, etc...
        2. + +
      2. llvm/include/Support - This directory contains generic + support libraries that are independent of LLVM, but are used by LLVM. + For example, some C++ STL utilities and a Command Line option processing + library store their header files here.
        3. + +
      3. llvm/include/Config - This directory contains header files + configured by the configure script. They wrap "standard" UNIX + and C header files. Source code can include these header files which + automatically take care of the conditional #includes that the + configure script generates.
        4. +
      + +
      + + +
      + 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 + different tools.

      + +
      +
      llvm/lib/VMCore/
      This directory holds the core LLVM + source files that implement core classes like Instruction and BasicBlock. + +
      llvm/lib/AsmParser/
      This directory holds the source code + for the LLVM assembly language parser library. + +
      llvm/lib/ByteCode/
      This directory holds code for reading + and write LLVM bytecode. + +
      llvm/lib/CWriter/
      This directory implements the LLVM to C + converter. + +
      llvm/lib/Analysis/
      This directory contains a variety of + different program analyses, such as Dominator Information, Call Graphs, + Induction Variables, Interval Identification, Natural Loop Identification, + etc... + +
      llvm/lib/Transforms/
      This directory contains the source + code for the LLVM to LLVM program transformations, such as Aggressive Dead + Code Elimination, Sparse Conditional Constant Propagation, Inlining, Loop + Invariant Code Motion, Dead Global Elimination, and many others... + +
      llvm/lib/Target/
      This directory contains files that + describe various target architectures for code generation. For example, + the llvm/lib/Target/Sparc directory holds the Sparc machine + description.
      + +
      llvm/lib/CodeGen/
      This directory contains the major parts + of the code generator: Instruction Selector, Instruction Scheduling, and + Register Allocation. + +
      llvm/lib/Support/
      This directory contains the source code + that corresponds to the header files located in + llvm/include/Support/. +
      + +
      + + +
      + llvm/runtime +
      + +
      + +

      This directory contains libraries which are compiled into LLVM bytecode and + used when linking programs with the GCC front end. Most of these libraries are + skeleton versions of real libraries; for example, libc is a stripped down + version of glibc.

      + +

      Unlike the rest of the LLVM suite, this directory needs the LLVM GCC front + end to compile.

      + +
      + + +
      + llvm/test +
      + +
      + +

      This directory contains regression tests and source code that is used to test + the LLVM infrastructure.

      + +
      + + +
      + 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 + always get help for a tool by typing tool_name --help. The + following is a brief introduction to the most important tools:

      + +
      +
      analyze
      analyze is used to run a specific + analysis on an input LLVM bytecode file and print out the results. It is + primarily useful for debugging analyses, or familiarizing yourself with + what an analysis does.

      + +

      bugpoint
      bugpoint is used to debug + optimization passes or code generation backends by narrowing down the + given test case to the minimum number of passes and/or instructions that + still cause a problem, whether it is a crash or miscompilation. See HowToSubmitABug.html for more information + on using bugpoint.

      + +

      llvm-ar
      The archiver produces an archive containing + the given LLVM bytecode files, optionally with an index for faster + lookup.

      + +

      llvm-as
      The assembler transforms the human readable + LLVM assembly to LLVM bytecode.

      + +

      llvm-dis
      The disassembler transforms the LLVM + bytecode to human readable LLVM assembly.

      + +

      llvm-link
      llvm-link, not surprisingly, + links multiple LLVM modules into a single program.

      + +

      lli
      lli is the LLVM interpreter, which + can directly execute LLVM bytecode (although very slowly...). In addition + to a simple interpreter, lli also has a tracing mode (entered by + specifying -trace on the command line). Finally, for + architectures that support it (currently only x86 and Sparc), by default, + lli will function as a Just-In-Time compiler (if the + functionality was compiled in), and will execute the code much + faster than the interpreter.

      + +

      llc
      llc is the LLVM backend compiler, which + translates LLVM bytecode to a SPARC or x86 assembly file, or to C code (with + the -march=c option).

      + +

      llvmgcc
      llvmgcc is a GCC-based C frontend + that has been retargeted to emit LLVM code as the machine code output. It + works just like any other GCC compiler, taking the typical -c, -S, -E, + -o options that are typically used. The source code for the + llvmgcc tool is currently not included in the LLVM CVS tree + because it is quite large and not very interesting.

      + +

      +
      +
      gccas
      This tool is invoked by the + llvmgcc frontend as the "assembler" part of the compiler. This + tool actually assembles LLVM assembly to LLVM bytecode, + performs a variety of optimizations, and outputs LLVM bytecode. Thus + when you invoke llvmgcc -c x.c -o x.o, you are causing + gccas to be run, which writes the x.o file (which is + an LLVM bytecode file that can be disassembled or manipulated just like + any other bytecode file). The command line interface to gccas + is designed to be as close as possible to the system + `as' utility so that the gcc frontend itself did not have to be + modified to interface to a "weird" assembler.

      + +

      gccld
      gccld links together several LLVM + bytecode files into one bytecode file and does some optimization. It is + the linker invoked by the GCC frontend when multiple .o files need to be + linked together. Like gccas, the command line interface of + gccld is designed to match the system linker, to aid + interfacing with the GCC frontend.

      +

      + +
      opt
      opt reads LLVM bytecode, applies a + series of LLVM to LLVM transformations (which are specified on the command + line), and then outputs the resultant bytecode. The 'opt --help' + command is a good way to get a list of the program transformations + available in LLVM. + +
      + +
      + + +
      + 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 + are code generators for parts of LLVM infrastructure.

      + +
      +
      Burg/
      Burg is an instruction selector + generator -- it builds trees on which it then performs pattern-matching to + select instructions according to the patterns the user has specified. Burg + is currently used in the Sparc V9 backend.

      + +

      codegen-diff
      codegen-diff is a script + that finds differences between code that LLC generates and code that LLI + generates. This is a useful tool if you are debugging one of them, + assuming that the other generates correct output. For the full user + manual, run `perldoc codegen-diff'.

      + +

      cvsupdate
      cvsupdate is a script that will + update your CVS tree, but produce a much cleaner and more organized output + than simply running `cvs -z3 up -dP' will. For example, it will group + together all the new and updated files and modified files in separate + sections, so you can see at a glance what has changed. If you are at the + top of your LLVM CVS tree, running utils/cvsupdate is the + preferred way of updating the tree.

      + +

      emacs/
      The emacs directory contains + syntax-highlighting files which will work with Emacs and XEmacs editors, + providing syntax highlighting support for LLVM assembly files and TableGen + description files. For information on how to use the syntax files, consult + the README file in that directory.

      + +

      getsrcs.sh
      The getsrcs.sh script finds + and outputs all non-generated source files, which is useful if one wishes + to do a lot of development across directories and does not want to + individually find each file. One way to use it is to run, for example: + xemacs `utils/getsources.sh` from the top of your LLVM source + tree.

      + +

      makellvm
      The makellvm script compiles all + files in the current directory and then compiles and links the tool that + is the first argument. For example, assuming you are in the directory + llvm/lib/Target/Sparc, if makellvm is in your path, + simply running makellvm llc will make a build of the current + directory, switch to directory llvm/tools/llc and build it, + causing a re-linking of LLC.

      + +

      NightlyTest.pl and + NightlyTestTemplate.html
      These files are used in a + cron script to generate nightly status reports of the functionality of + tools, and the results can be seen by following the appropriate link on + the LLVM homepage.

      + +

      TableGen/
      The TableGen directory contains + the tool used to generate register descriptions, instruction set + descriptions, and even assemblers from common TableGen description + files.

      + +

      vim/
      The vim directory contains + syntax-highlighting files which will work with the VIM editor, providing + syntax highlighting support for LLVM assembly files and TableGen + description files. For information on how to use the syntax files, consult + the README file in that directory.

      + +

      + +
      + + +
      + An Example Using the LLVM Tool Chain +
      + + +
      + +
        +
      1. First, create a simple C file, name it 'hello.c': + 
        +    #include <stdio.h>
+    int main() {
+      printf("hello world\n");
+      return 0;
+    }
+
        2. + +

      2. Next, compile the C file into a LLVM bytecode file:

        +

        % llvmgcc hello.c -o hello

        + +

        This will create two result files: hello and + hello.bc. The hello.bc is the LLVM bytecode that + corresponds the the compiled program and the library facilities that it + required. hello is a simple shell script that runs the bytecode + file with lli, making the result directly executable.

        3. + +

      3. Run the program. To make sure the program ran, execute one of the + following commands:

        + +

        % ./hello

        + +

        or

        + +

        % lli hello.bc

        4. + +

      4. Use the llvm-dis utility to take a look at the LLVM assembly + code:

        + +

        % llvm-dis < hello.bc | less

        5. + +

      5. Compile the program to native Sparc assembly using the code + generator (assuming you are currently on a Sparc system):

        + +

        % llc hello.bc -o hello.s

        + +

      6. Assemble the native sparc assemble file into a program:

        + +

        % /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.sparc

        + +

      7. Execute the native sparc program:

        + +

        % ./hello.sparc

        8. + +
      + +
      + + +
      + 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 + 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 + that you can do that aren't documented here (but we'll gladly accept a patch + if you want to write something up!). For more information about LLVM, check + out:

      + + + +
      + + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + Chris Lattner
      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/HowToSubmitABug.html diff -c /dev/null llvm-www/releases/1.2/docs/HowToSubmitABug.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/HowToSubmitABug.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,324 ---- + + + + How to submit an LLVM bug report + + + + +
      + How to submit an LLVM bug report +
      + + + + + + +
      + +
        +
      1. Introduction - Got bugs?
        2. +
      2. Crashing Bugs +
        3. +
      3. Miscompilations
        4. +
      4. Incorrect code generation (JIT and LLC)
        5. + +
      + +
      +

      Written by Chris Lattner and + Misha Brukman

      +
      + +       		+ Debugging +
      + + +
      + 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 + getting it fixed quickly.

      + +

      Basically you have to do two things at a minimum. First, decide whether the + bug crashes the compiler (or an LLVM pass), or if the + compiler is miscompiling the program. Based on + what type of bug it is, follow the instructions in the linked section to narrow + down the bug so that the person who fixes it will be able to find the problem + more easily.

      + +

      Once you have a reduced test-case, go to the LLVM Bug Tracking + System, select the category in which the bug falls, and fill out the form + with the necessary details. The bug description should contain the following + information:

      + +
        +
      • All information necessary to reproduce the problem.
        • +
      • The reduced test-case that triggers the bug.
        • +
      • The location where you obtained LLVM (if not from our CVS + repository).
        • +
      + +

      Thanks for helping us make LLVM better!

      + +
      + + +
      + Crashing Bugs +
      + + +
      + +

      More often than not, bugs in the compiler cause it to crash - often due to an + assertion failure of some sort. If you are running opt or + analyze directly, and something crashes, jump to the section on + bugs in LLVM passes. Otherwise, the most important + piece of the puzzle is to figure out if it is the GCC-based front-end that is + buggy or if it's one of the LLVM tools that has problems.

      + +

      To figure out which program is crashing (the front-end, + gccas, or gccld), run the + llvm-gcc command line as you were when the crash occurred, but + add a -v option to the command line. The compiler will print out a + bunch of stuff, and should end with telling you that one of + cc1/cc1plus, gccas, or + gccld crashed.

      + +
        + +
      • If cc1 or cc1plus crashed, you found a + problem with the front-end. + Jump ahead to the section on front-end bugs.
        • + +
      • If gccas crashed, you found a bug in one + of the passes in gccas.
        • + +
      • If gccld crashed, you found a bug in one + of the passes in gccld.
        • + +
      • Otherwise, something really weird happened. Email the list with what you + have at this point.
        • + +
      + +
      + + +
      + 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 + -save-temps option. The compiler will crash again, but it will leave + behind a foo.i file (containing preprocessed C source code) and + possibly foo.s (containing LLVM assembly code), for each + compiled foo.c file. Send us the foo.i file, + along with a brief description of the error it caused.

      + +
      + + +
      + GCCAS bugs +
      + +
      + +

      If you find that a bug crashes in the gccas stage of + compilation, compile your test-case to a .s file with the + -save-temps option to llvm-gcc. Then run:

      + + 
      +   gccas -debug-pass=Arguments < /dev/null -o - > /dev/null
+
      + +

      ... which will print a list of arguments, indicating the list of passes that + gccas runs. Once you have the input file and the list of + passes, go to the section on debugging bugs in LLVM + passes.

      + +
      + + +
      + GCCLD bugs +
      + +
      + +

      If you find that a bug crashes in the gccld stage of + compilation, gather all of the .o bytecode files and libraries that are + being linked together (the "llvm-gcc -v" output should include + the full list of objects linked). Then run:

      + + 
      +   llvm-as < /dev/null > null.bc
+   gccld -debug-pass=Arguments null.bc
+

      + +

      ... which will print a list of arguments, indicating the list of passes that + gccld runs. Once you have the input files and the list of + passes, go to the section on debugging bugs in LLVM + passes.

      + +
      + + +
      + Bugs in LLVM passes +
      + +
      + +

      At this point, you should have some number of LLVM assembly files or bytecode + files and a list of passes which crash when run on the specified input. In + order to reduce the list of passes (which is probably large) and the input to + something tractable, use the bugpoint tool as follows:

      + + 
      +   bugpoint <input files> <list of passes>
+

      + +

      bugpoint will print a bunch of output as it reduces the + test-case, but it should eventually print something like this:

      + + 
      +   ...
+   Emitted bytecode to 'bugpoint-reduced-simplified.bc'
+ 
+   *** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc -licm
+
      + +

      Once you complete this, please send the LLVM bytecode file and the command + line to reproduce the problem to the llvmbugs mailing list.

      + +
      + + +
      + Miscompilations +
      + + +
      + +

      A miscompilation occurs when a pass does not correctly transform a program, + thus producing errors that are only noticed during execution. This is different + from producing invalid LLVM code (i.e., code not in SSA form, using values + before defining them, etc.) which the verifier will check for after a pass + finishes its run.

      + +

      To debug a miscompilation, you should choose which program you wish to run + the output through, e.g. C backend, the JIT, or LLC, and a selection of passes, + one of which may be causing the error, and run, for example:

      + + 
      +   bugpoint -run-cbe [... optimization passes ...] file-to-test.bc
+
      + +

      bugpoint will try to narrow down your list of passes to the one pass + that causes an error, and simplify the bytecode file as much as it can to assist + you. It will print a message letting you know how to reproduce the resulting + error.

      + +
      + + +
      + 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 + bugpoint. The process bugpoint follows in this case is to try + to narrow the code down to a function that is miscompiled by one or the other + method, but since for correctness, the entire program must be run, + bugpoint will compile the code it deems to not be affected with the C + Backend, and then link in the shared object it generates.

      + +

      To debug the JIT:

      + + 
      +   bugpoint -run-jit -output=[correct output file] [bytecodefile]
+
      + +

      Similarly, to debug the LLC, one would run:

      + + 
      +   bugpoint -run-llc -output=[correct output file] [bytecodefile]
+
      + +

      At the end of a successful bugpoint run, you will be presented + with two bytecode files: a safe file which can be compiled with the C + backend and the test file which either LLC or the JIT + mis-codegenerates, and thus causes the error.

      + +

      To reproduce the error that bugpoint found, it is sufficient to do + the following:

      + +
        + +
      1. Regenerate the shared object from the safe bytecode file:
        + + 
        +   llc -march=c safe.bc -o safe.c
        
+   gcc -shared safe.c -o safe.so
+
        2. + +
      2. If debugging LLC, compile test bytecode native and link with the shared object:
        + + 
        +   llc test.bc -o test.s -f
        
+   gcc test.s safe.so -o test.llc
        
+   ./test.llc [program options]
+
        3. + +
      3. If debugging the JIT, load the shared object and supply the test + bytecode: + + 
        +   lli -load=safe.so test.bc [program options]
+
        4. + +
      + +
      + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + Chris Lattner
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/LLVMVsTheWorld.html diff -c /dev/null llvm-www/releases/1.2/docs/LLVMVsTheWorld.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/LLVMVsTheWorld.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,180 ---- + + + + + LLVM vs. the World - Comparing Compilers to Compilers + + + + +
      + LLVM vs. the World - Comparing Compilers to Compilers +
      + +
        +
      1. Introduction
        2. +
      2. General Applicability
        3. +
      3. Type System
        4. +
      4. Control-flow and Data-flow Information
        5. +
      5. Registers
        6. +
      6. Programmer Interface
        7. +
      7. Machine Code Emission
        8. +
      + +
      +

      Written by Brian R. Gaeke

      +
      + + +
      + Introduction +
      + + +
      +

      Whether you are a stranger to LLVM or not, and whether you are considering + using it for your projects or not, you may find it useful to understand how we + compare ourselves to other well-known compilers. The following list of points + should help you understand -- from our point of view -- some of the important + ways in which we see LLVM as different from other selected compilers and + code generation systems.

      + +

      At the moment, we only compare ourselves below to GCC and GNU lightning, but we will try + to revise and expand it as our knowledge and experience permit. Contributions are + welcome.

      +
      + + +
      + General Applicability +
      + + +
      +

      GNU lightning: Only currently usable for dynamic runtime emission of binary + machine code to memory. Supports one backend at a time.

      + +

      LLVM: Supports compilation of C and C++ (with more languages coming soon), + strong SSA-based optimization at compile-time, link-time, run-time, and + off-line, and multiple platform backends with Just-in-Time and ahead-of-time + compilation frameworks. (See our document on Lifelong + Code Optimization for more.)

      + +

      GCC: Many relatively mature platform backends support assembly-language code + generation from many source languages. No run-time compilation + support.

      +
      + + +
      + Type System +
      + + +
      +

      GNU lightning: C integer types and "void *" are supported. No type checking + is performed. Explicit type casts are not typically necessary unless the + underlying machine-specific types are distinct (e.g., sign- or zero-extension is + apparently necessary, but casting "int" to "void *" would not be.) + Floating-point support may not work on all platforms (it does not appear to be + documented in the latest release).

      + +

      LLVM: Compositional type system based on C types, supporting structures, + opaque types, and C integer and floating point types. Explicit cast instructions + are required to transform a value from one type to another.

      + +

      GCC: Union of high-level types including those used in Pascal, C, C++, Ada, + Java, and FORTRAN.

      +
      + + +
      + Control-flow and Data-flow Information +
      + + +
      +

      GNU lightning: No data-flow information encoded in the generated program. No + support for calculating CFG or def-use chains over generated programs.

      + +

      LLVM: Scalar values in Static Single-Assignment form; def-use chains and CFG + always implicitly available and automatically kept up to date.

      + +

      GCC: Trees and RTL do not directly encode data-flow info; but def-use chains + and CFGs can be calculated on the side. They are not automatically kept up to + date.

      +
      + + +
      + Registers +
      + + +
      +

      GNU lightning: Very small fixed register set -- it takes the least common + denominator of supported platforms; basically it inherits its tiny register set + from IA-32, unnecessarily crippling targets like PowerPC with a large register + set.

      + +

      LLVM: An infinite register set, reduced to a particular platform's finite + register set by register allocator.

      + +

      GCC: Trees and RTL provide an arbitrarily large set of values. Reduced to a + particular platform's finite register set by register allocator.

      +
      + + +
      + Programmer Interface +
      + + +
      +

      GNU lightning: Library interface based on C preprocessor macros that emit + binary code for a particular instruction to memory. No support for manipulating + code before emission.

      + +

      LLVM: Library interface based on classes representing platform-independent + intermediate code (Instruction) and platform-dependent code (MachineInstr) which + can be manipulated arbitrarily and then emitted to memory.

      + +

      GCC: Internal header file interface (tree.h) to abstract syntax trees, + representing roughly the union of all possible supported source-language + constructs; also, an internal header file interface (rtl.h, rtl.def) to a + low-level IR called RTL which represents roughly the union of all possible + target machine instructions.

      +
      + + +
      + Machine Code Emission +
      + + +
      +

      GNU lightning: Only supports binary machine code emission to memory.

      + +

      LLVM: Supports writing out assembly language to a file, and binary machine + code to memory, from the same back-end.

      + +

      GCC: Supports writing out assembly language to a file. No support for + emitting machine code to memory.

      +
      + + + +
      +
      +
      Brian R. Gaeke
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/LangRef.html diff -c /dev/null llvm-www/releases/1.2/docs/LangRef.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/LangRef.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,2154 ---- + + + + LLVM Assembly Language Reference Manual + + + +
      LLVM Language Reference Manual
      +
        +
      1. Abstract
        2. +
      2. Introduction
        3. +
      3. Identifiers
        4. +
      4. Type System +
          +
        1. Primitive Types +
            +
          1. Type Classifications
            2. +
          +
          2. +
        2. Derived Types +
            +
          1. Array Type
            2. +
          2. Function Type
            3. +
          3. Pointer Type
            4. +
          4. Structure Type
            5. + +
          +
          3. +
        +
        5. +
      5. High Level Structure +
          +
        1. Module Structure
          2. +
        2. Global Variables
          3. +
        3. Function Structure
          4. +
        +
        6. +
      6. Instruction Reference +
          +
        1. Terminator Instructions +
            +
          1. 'ret' Instruction
            2. +
          2. 'br' Instruction
            3. +
          3. 'switch' Instruction
            4. +
          4. 'invoke' Instruction
            5. +
          5. 'unwind' Instruction
            6. +
          +
          2. +
        2. Binary Operations +
            +
          1. 'add' Instruction
            2. +
          2. 'sub' Instruction
            3. +
          3. 'mul' Instruction
            4. +
          4. 'div' Instruction
            5. +
          5. 'rem' Instruction
            6. +
          6. 'setcc' Instructions
            7. +
          +
          3. +
        3. Bitwise Binary Operations +
            +
          1. 'and' Instruction
            2. +
          2. 'or' Instruction
            3. +
          3. 'xor' Instruction
            4. +
          4. 'shl' Instruction
            5. +
          5. 'shr' Instruction
            6. +
          +
          4. +
        4. Memory Access Operations +
            +
          1. 'malloc' Instruction
            2. +
          2. 'free' Instruction
            3. +
          3. 'alloca' Instruction
            4. +
          4. 'load' Instruction
            5. +
          5. 'store' Instruction
            6. +
          6. 'getelementptr' Instruction
            7. +
          +
          5. +
        5. Other Operations +
            +
          1. 'phi' Instruction
            2. +
          2. 'cast .. to' Instruction
            3. +
          3. 'select' Instruction
            4. +
          4. 'call' Instruction
            5. +
          5. 'vanext' Instruction
            6. +
          6. 'vaarg' Instruction
            7. +
          +
          6. +
        +
        7. +
      7. Intrinsic Functions +
          +
        1. Variable Argument Handling Intrinsics +
            +
          1. 'llvm.va_start' Intrinsic
            2. +
          2. 'llvm.va_end' Intrinsic
            3. +
          3. 'llvm.va_copy' Intrinsic
            4. +
          +
          2. +
        2. Code Generator Intrinsics +
            +
          1. 'llvm.returnaddress' Intrinsic
            2. +
          2. 'llvm.frameaddress' Intrinsic
            3. +
          +
          3. +
        3. Standard C Library Intrinsics +
            +
          1. 'llvm.memcpy' Intrinsic
            2. +
          2. 'llvm.memmove' Intrinsic
            3. +
          3. 'llvm.memset' Intrinsic
            4. +
          +
          4. +
        4. Debugger intrinsics +
        +
        8. +
      +
      +

      Written by Chris Lattner + and Vikram Adve

      +

      +
      + +
      Abstract
      + +
      +

      This document is a reference manual for the LLVM assembly language. + LLVM is an SSA based representation that provides type safety, + low-level operations, flexibility, and the capability of representing + 'all' high-level languages cleanly. It is the common code + representation used throughout all phases of the LLVM compilation + strategy.

      +
      + +
      Introduction
      + +
      +

      The LLVM code representation is designed to be used in three + different forms: as an in-memory compiler IR, as an on-disk bytecode + representation (suitable for fast loading by a Just-In-Time compiler), + and as a human readable assembly language representation. This allows + LLVM to provide a powerful intermediate representation for efficient + compiler transformations and analysis, while providing a natural means + to debug and visualize the transformations. The three different forms + of LLVM are all equivalent. This document describes the human readable + representation and notation.

      +

      The LLVM representation aims to be a light-weight and low-level + while being expressive, typed, and extensible at the same time. It + aims to be a "universal IR" of sorts, by being at a low enough level + that high-level ideas may be cleanly mapped to it (similar to how + microprocessors are "universal IR's", allowing many source languages to + be mapped to them). By providing type information, LLVM can be used as + the target of optimizations: for example, through pointer analysis, it + can be proven that a C automatic variable is never accessed outside of + the current function... allowing it to be promoted to a simple SSA + value instead of a memory location.

      +
      + +
      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 what is considered 'well formed'. For example, the + following instruction is syntactically okay, but not well formed:

      + 
        %x = add int 1, %x
      +

      ...because the definition of %x does not dominate all of + its uses. The LLVM infrastructure provides a verification pass that may + be used to verify that an LLVM module is well formed. This pass is + automatically run by the parser after parsing input assembly, and by + the optimizer before it outputs bytecode. The violations pointed out + by the verifier pass indicate bugs in transformation passes or input to + the parser.

      +
      + +
      Identifiers
      + +
      +

      LLVM uses three different forms of identifiers, for different + purposes:

      +
        +
      1. Numeric constants are represented as you would expect: 12, -3 + 123.421, etc. Floating point constants have an optional hexidecimal + notation.
        2. +
      2. Named values are represented as a string of characters with a '%' + prefix. For example, %foo, %DivisionByZero, + %a.really.long.identifier. The actual regular expression used is '%[a-zA-Z$._][a-zA-Z$._0-9]*'. + Identifiers which require other characters in their names can be + surrounded with quotes. In this way, anything except a " + character can be used in a name.
        3. +
      3. Unnamed values are represented as an unsigned numeric value with + a '%' prefix. For example, %12, %2, %44.
        4. +
      +

      LLVM requires that values start with a '%' sign for two reasons: + Compilers don't need to worry about name clashes with reserved words, + and the set of reserved words may be expanded in the future without + penalty. Additionally, unnamed identifiers allow a compiler to quickly + come up with a temporary variable without having to avoid symbol table + conflicts.

      +

      Reserved words in LLVM are very similar to reserved words in other + languages. There are keywords for different opcodes ('add', 'cast', 'ret', etc...), for primitive type names ('void', 'uint', + etc...), and others. These reserved words cannot conflict with + variable names, because none of them start with a '%' character.

      +

      Here is an example of LLVM code to multiply the integer variable '%X' + by 8:

      +

      The easy way:

      + 
        %result = mul uint %X, 8
      +

      After strength reduction:

      + 
        %result = shl uint %X, ubyte 3
      +

      And the hard way:

      + 
        add uint %X, %X           ; yields {uint}:%0
+   add uint %0, %0           ; yields {uint}:%1
+   %result = add uint %1, %1
      +

      This last way of multiplying %X by 8 illustrates several + important lexical features of LLVM:

      +
        +
      1. Comments are delimited with a ';' and go until the end + of line.
        2. +
      2. Unnamed temporaries are created when the result of a computation + is not assigned to a named value.
        3. +
      3. Unnamed temporaries are numbered sequentially
        4. +
      +

      ...and it also show a convention that we follow in this document. + When demonstrating instructions, we will follow an instruction with a + comment that defines the type and name of value produced. Comments are + shown in italic text.

      +

      The one non-intuitive notation for constants is the optional + hexidecimal form of floating point constants. For example, the form 'double + 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double + 4.5e+15' which is also supported by the parser. The only time + hexadecimal floating point constants are useful (and the only time that + they are generated by the disassembler) is when an FP constant has to + be emitted that is not representable as a decimal floating point number + exactly. For example, NaN's, infinities, and other special cases are + represented in their IEEE hexadecimal format so that assembly and + disassembly do not cause any bits to change in the constants.

      +
      + +
      Type System
      + +
      +

      The LLVM type system is one of the most important features of the + intermediate representation. Being typed enables a number of + optimizations to be performed on the IR directly, without having to do + extra analyses on the side before the transformation. A strong type + system makes it easier to read the generated code and enables novel + analyses and transformations that are not feasible to perform on normal + three address code representations.

      +
      + +
      Primitive Types
      +
      +

      The primitive types are the fundemental building blocks of the LLVM + system. The current set of primitive types are as follows:

      + + + + + + + + +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      voidNo value
      ubyteUnsigned 8 bit value
      ushortUnsigned 16 bit value
      uintUnsigned 32 bit value
      ulongUnsigned 64 bit value
      float32 bit floating point value
      labelBranch destination
      +       		+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
      boolTrue or False value
      sbyteSigned 8 bit value
      shortSigned 16 bit value
      intSigned 32 bit value
      longSigned 64 bit value
      double64 bit floating point value
      +
      + +
      + +
      Type + Classifications
      +
      +

      These different primitive types fall into a few useful + classifications:

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      signedsbyte, short, int, long, float, double
      unsignedubyte, ushort, uint, ulong
      integerubyte, sbyte, ushort, short, uint, int, ulong, long
      integralbool, ubyte, sbyte, ushort, short, uint, int, ulong, long
      floating pointfloat, double
      first classbool, ubyte, sbyte, ushort, short,
      + uint, int, ulong, long, float, double, pointer
      + +

      The first class types are perhaps the + most important. Values of these types are the only ones which can be + produced by instructions, passed as arguments, or used as operands to + instructions. This means that all structures and arrays must be + manipulated either by pointer or by component.

      +
      + +
      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 useful types. Note that these derived types may be + recursive: For example, it is possible to have a two dimensional array.

      +
      + +
      Array Type
      +
      +
      Overview:
      +

      The array type is a very simple derived type that arranges elements + sequentially in memory. The array type requires a size (number of + elements) and an underlying data type.

      +
      Syntax:
      + 
        [<# elements> x <elementtype>]
      +

      The number of elements is a constant integer value, elementtype may + be any type with a size.

      +
      Examples:
      +

      [40 x int ]: Array of 40 integer values.
      + [41 x int ]: Array of 41 integer values.
      + [40 x uint]: Array of 40 unsigned integer values.

      +

      +

      Here are some examples of multidimensional arrays:

      + + + + + + + + + + + + + + + + +
      [3 x [4 x int]]: 3x4 array integer values.
      [12 x [10 x float]]: 12x10 array of single precision floating point values.
      [2 x [3 x [4 x uint]]]: 2x3x4 array of unsigned integer values.
      + +
      + +
      Function Type
      +
      +
      Overview:
      +

      The function type can be thought of as a function signature. It + consists of a return type and a list of formal parameter types. + Function types are usually used to build virtual function tables + (which are structures of pointers to functions), for indirect function + calls, and when defining a function.

      +

      + The return type of a function type cannot be an aggregate type. +

      +
      Syntax:
      + 
        <returntype> (<parameter list>)
      +

      Where '<parameter list>' is a comma-separated list of + type specifiers. Optionally, the parameter list may include a type ..., + which indicates that the function takes a variable number of arguments. + Variable argument functions can access their arguments with the variable argument handling intrinsic functions.

      +
      Examples:
      + + + + + + + + + + + + + + + + +
      int (int): function taking an int, returning an int
      float (int, int *) *: Pointer to a function that takes + an int and a pointer to int, + returning float.
      int (sbyte *, ...): A vararg function that takes at least one pointer to sbyte (signed char in C), + which returns an integer. This is the signature for printf + in LLVM.
      + +
      + +
      Structure Type
      +
      +
      Overview:
      +

      The structure type is used to represent a collection of data members + together in memory. The packing of the field types is defined to match + the ABI of the underlying processor. The elements of a structure may + be any type that has a size.

      +

      Structures are accessed using 'load + and 'store' by getting a pointer to a + field with the 'getelementptr' + instruction.

      +
      Syntax:
      + 
        { <type list> }
      +
      Examples:
      + + + + + + + + + + + + +
      { int, int, int }: a triple of three int values
      { float, int (int) * }: A pair, where the first element is a float and the + second element is a pointer to a function that takes an int, returning + an int.
      + +
      + +
      Pointer Type
      +
      +
      Overview:
      +

      As in many languages, the pointer type represents a pointer or + reference to another object, which must live in memory.

      +
      Syntax:
      + 
        <type> *
      +
      Examples:
      + + + + + + + + + + + + +
      [4x int]*: pointer to array + of four int values
      int (int *) *: A pointer to a function that takes an int, returning + an int.
      + +
      + +
      High Level 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, and symbol table entries. Modules may be + combined together with the LLVM linker, which merges function (and + global variable) definitions, resolves forward declarations, and merges + symbol table entries. Here is an example of the "hello world" module:

      + 
      ; Declare the string constant as a global constant...
+ %.LC0 = internal constant [13 x sbyte] c"hello world\0A\00"          ; [13 x sbyte]*
+ 
+ ; External declaration of the puts function
+ declare int %puts(sbyte*)                                            ; int(sbyte*)* 
+ 
+ ; Definition of main function
+ int %main() {                                                        ; int()* 
+         ; Convert [13x sbyte]* to sbyte *...
+         %cast210 = getelementptr [13 x sbyte]* %.LC0, long 0, long 0 ; sbyte*
+ 
+         ; Call puts function to write out the string to stdout...
+         call int %puts(sbyte* %cast210)                              ; int
+         ret int 0
      }
      +

      This example is made up of a global variable + named ".LC0", an external declaration of the "puts" + function, and a function definition + for "main".

      + In general, a module is made up of a list of global + values, where both functions and global variables are global values. + Global values are represented by a pointer to a memory location (in + this case, a pointer to an array of char, and a pointer to a function), + and have one of the following linkage types: +

      +
      +
      internal
      +
      Global values with internal linkage are only directly accessible + by objects in the current module. In particular, linking code into a + module with an internal global value may cause the internal to be + renamed as necessary to avoid collisions. Because the symbol is + internal to the module, all references can be updated. This + corresponds to the notion of the 'static' keyword in C, or the + idea of "anonymous namespaces" in C++. +

      +
      +
      linkonce:
      +
      "linkonce" linkage is similar to internal + linkage, with the twist that linking together two modules defining the + same linkonce globals will cause one of the globals to be + discarded. This is typically used to implement inline functions. + Unreferenced linkonce globals are allowed to be discarded. +

      +
      +
      weak:
      +
      "weak" linkage is exactly the same as linkonce + linkage, except that unreferenced weak globals may not be + discarded. This is used to implement constructs in C such as "int + X;" at global scope. +

      +
      +
      appending:
      +
      "appending" linkage may only be applied to global + variables of pointer to array type. When two global variables with + appending linkage are linked together, the two global arrays are + appended together. This is the LLVM, typesafe, equivalent of having + the system linker append together "sections" with identical names when + .o files are linked. +

      +
      +
      externally visible:
      +
      If none of the above identifiers are used, the global is + externally visible, meaning that it participates in linkage and can be + used to resolve external symbol references. +

      +
      +
      +

      +

      For example, since the ".LC0" + variable is defined to be internal, if another module defined a ".LC0" + variable and was linked with this one, one of the two would be renamed, + preventing a collision. Since "main" and "puts" are + external (i.e., lacking any linkage declarations), they are accessible + outside of the current module. It is illegal for a function declaration + to have any linkage type other than "externally visible".

      +
      + + +
      + Global Variables +
      + +
      + +

      Global variables define regions of memory allocated at compilation + time instead of run-time. Global variables may optionally be + initialized. A variable may be defined as a global "constant", which + indicates that the contents of the variable will never be modified + (opening options for optimization).

      + +

      As SSA values, global variables define pointer values that are in + scope (i.e. they dominate) for all basic blocks in the program. Global + variables always define a pointer to their "content" type because they + describe a region of memory, and all memory objects in LLVM are + accessed through pointers.

      + +
      + + + +
      + Functions +
      + +
      + +

      LLVM function definitions are composed of a (possibly empty) argument list, + an opening curly brace, a list of basic blocks, and a closing curly brace. LLVM + function declarations are defined with the "declare" keyword, a + function name, and a function signature.

      + +

      A function definition contains a list of basic blocks, forming the CFG for + the function. Each basic block may optionally start with a label (giving the + basic block a symbol table entry), contains a list of instructions, and ends + with a terminator instruction (such as a branch or + function return).

      + +

      The first basic block in program is special in two ways: it is immediately + executed on entrance to the function, and it is not allowed to have predecessor + basic blocks (i.e. there can not be any branches to the entry block of a + function). Because the block can have no predecessors, it also cannot have any + PHI nodes.

      + +

      LLVM functions are identified by their name and type signature. Hence, two + functions with the same name but different parameter lists or return values are + considered different functions, and LLVM will resolves references to each + appropriately.

      + +
      + + + +
      Instruction Reference
      + +
      +

      The LLVM instruction set consists of several different + classifications of instructions: terminator + instructions, binary instructions, memory instructions, and other + instructions.

      +
      + +
      Terminator + Instructions
      +
      +

      As mentioned previously, every + basic block in a program ends with a "Terminator" instruction, which + indicates which block should be executed after the current block is + finished. These terminator instructions typically yield a 'void' + value: they produce control flow, not values (the one exception being + the 'invoke' instruction).

      +

      There are five different terminator instructions: the 'ret' instruction, the 'br' + instruction, the 'switch' instruction, + the 'invoke' instruction, and the 'unwind' instruction.

      +
      + +
      'ret' + Instruction
      +
      +
      Syntax:
      + 
        ret <type> <value>       ; Return a value from a non-void function
+   ret void                 ; Return from void function
+
      +
      Overview:
      +

      The 'ret' instruction is used to return control flow (and a + value) from a function, back to the caller.

      +

      There are two forms of the 'ret' instructruction: one that + returns a value and then causes control flow, and one that just causes + control flow to occur.

      +
      Arguments:
      +

      The 'ret' instruction may return any 'first class' type. Notice that a function is + not well formed if there exists a 'ret' + instruction inside of the function that returns a value that does not + match the return type of the function.

      +
      Semantics:
      +

      When the 'ret' instruction is executed, control flow + returns back to the calling function's context. If the caller is a "call instruction, execution continues at + the instruction after the call. If the caller was an "invoke" instruction, execution continues + at the beginning "normal" of the destination block. If the instruction + returns a value, that value shall set the call or invoke instruction's + return value.

      +
      Example:
      + 
        ret int 5                       ; Return an integer value of 5
+   ret void                        ; Return from a void function
+
      +
      + +
      'br' Instruction
      +
      +
      Syntax:
      + 
        br bool <cond>, label <iftrue>, label <iffalse>
        br label <dest>          ; Unconditional branch
+
      +
      Overview:
      +

      The 'br' instruction is used to cause control flow to + transfer to a different basic block in the current function. There are + two forms of this instruction, corresponding to a conditional branch + and an unconditional branch.

      +
      Arguments:
      +

      The conditional branch form of the 'br' instruction takes a + single 'bool' value and two 'label' values. The + unconditional form of the 'br' instruction takes a single 'label' + value as a target.

      +
      Semantics:
      +

      Upon execution of a conditional 'br' instruction, the 'bool' + argument is evaluated. If the value is true, control flows + to the 'iftrue' label argument. If "cond" is false, + control flows to the 'iffalse' label argument.

      +
      Example:
      + 
      Test:
        %cond = seteq int %a, %b
        br bool %cond, label %IfEqual, label %IfUnequal
      IfEqual:
        ret int 1
      IfUnequal:
        ret int 0
      +
      + +
      + 'switch' Instruction +
      + +
      +
      Syntax:
      + + 
      +   switch <intty> <value>, label <defaultdest> [ <intty> <val>, label <dest> ... ]
+
      + +
      Overview:
      + +

      The 'switch' instruction is used to transfer control flow to one of + several different places. It is a generalization of the 'br' + instruction, allowing a branch to occur to one of many possible + destinations.

      + + +
      Arguments:
      + +

      The 'switch' instruction uses three parameters: an integer + comparison value 'value', a default 'label' destination, and + an array of pairs of comparison value constants and 'label's. The + table is not allowed to contain duplicate constant entries.

      + +
      Semantics:
      + +

      The switch instruction specifies a table of values and + destinations. When the 'switch' instruction is executed, this + table is searched for the given value. If the value is found, the + corresponding destination is branched to, otherwise the default value + it transfered to.

      + +
      Implementation:
      + +

      Depending on properties of the target machine and the particular + switch instruction, this instruction may be code generated in different + ways, for example as a series of chained conditional branches, or with a lookup + table.

      + +
      Example:
      + + 
      +  ; Emulate a conditional br instruction
+  %Val = cast bool %value to int
+  switch int %Val, label %truedest [int 0, label %falsedest ]
+ 
+  ; Emulate an unconditional br instruction
+  switch uint 0, label %dest [ ]
+ 
+  ; Implement a jump table:
+  switch uint %val, label %otherwise [ uint 0, label %onzero 
+                                       uint 1, label %onone 
+                                       uint 2, label %ontwo ]
+
      +
      + +
      'invoke' + Instruction
      +
      +
      Syntax:
      + 
        <result> = invoke <ptr to function ty> %<function ptr val>(<function args>)
                       to label <normal label> except label <exception label>
      +
      Overview:
      +

      The 'invoke' instruction causes control to transfer to a + specified function, with the possibility of control flow transfer to + either the 'normal' label label or the 'exception'label. + If the callee function returns with the "ret" + instruction, control flow will return to the "normal" label. If the + callee (or any indirect callees) returns with the "unwind" + instruction, control is interrupted, and continued at the dynamically + nearest "except" label.

      +
      Arguments:
      +

      This instruction requires several arguments:

      +
        +
      1. 'ptr to function ty': shall be the signature of the + pointer to function value being invoked. In most cases, this is a + direct function invocation, but indirect invokes are just as + possible, branching off an arbitrary pointer to function value.
        2. +
      2. 'function ptr val': An LLVM value containing a pointer + to a function to be invoked.
        3. +
      3. 'function args': argument list whose types match the + function signature argument types. If the function signature indicates + the function accepts a variable number of arguments, the extra + arguments can be specified.
        4. +
      4. 'normal label': the label reached when the called + function executes a 'ret' instruction.
        5. +
      5. 'exception label': the label reached when a callee + returns with the unwind instruction.
        6. +
      +
      Semantics:
      +

      This instruction is designed to operate as a standard 'call' instruction in most regards. The + primary difference is that it establishes an association with a label, + which is used by the runtime library to unwind the stack.

      +

      This instruction is used in languages with destructors to ensure + that proper cleanup is performed in the case of either a longjmp + or a thrown exception. Additionally, this is important for + implementation of 'catch' clauses in high-level languages that + support them.

      +
      Example:
      + 
        %retval = invoke int %Test(int 15)
                    to label %Continue
                    except label %TestCleanup     ; {int}:retval set
+
      +
      + +
      'unwind' + Instruction
      +
      +
      Syntax:
      + 
        unwind
      +
      Overview:
      +

      The 'unwind' instruction unwinds the stack, continuing + control flow at the first callee in the dynamic call stack which used + an invoke instruction to perform the + call. This is primarily used to implement exception handling.

      +
      Semantics:
      +

      The 'unwind' intrinsic causes execution of the current + function to immediately halt. The dynamic call stack is then searched + for the first invoke instruction on + the call stack. Once found, execution continues at the "exceptional" + destination block specified by the invoke instruction. If + there is no invoke instruction in the dynamic call chain, + undefined behavior results.

      +
      + +
      Binary Operations
      +
      +

      Binary operators are used to do most of the computation in a + program. They require two operands, execute an operation on them, and + produce a single value. The result value of a binary operator is not + necessarily the same type as its operands.

      +

      There are several different binary operators:

      +
      + +
      'add' + Instruction
      +
      +
      Syntax:
      + 
        <result> = add <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'add' instruction returns the sum of its two operands.

      +
      Arguments:
      +

      The two arguments to the 'add' instruction must be either integer or floating point + values. Both arguments must have identical types.

      +
      Semantics:
      +

      The value produced is the integer or floating point sum of the two + operands.

      +
      Example:
      + 
        <result> = add int 4, %var          ; yields {int}:result = 4 + %var
+
      +
      + +
      'sub' + Instruction
      +
      +
      Syntax:
      + 
        <result> = sub <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'sub' instruction returns the difference of its two + operands.

      +

      Note that the 'sub' instruction is used to represent the 'neg' + instruction present in most other intermediate representations.

      +
      Arguments:
      +

      The two arguments to the 'sub' instruction must be either integer or floating point + values. Both arguments must have identical types.

      +
      Semantics:
      +

      The value produced is the integer or floating point difference of + the two operands.

      +
      Example:
      + 
        <result> = sub int 4, %var          ; yields {int}:result = 4 - %var
+   <result> = sub int 0, %val          ; yields {int}:result = -%var
+
      +
      + +
      'mul' + Instruction
      +
      +
      Syntax:
      + 
        <result> = mul <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'mul' instruction returns the product of its two + operands.

      +
      Arguments:
      +

      The two arguments to the 'mul' instruction must be either integer or floating point + values. Both arguments must have identical types.

      +
      Semantics:
      +

      The value produced is the integer or floating point product of the + two operands.

      +

      There is no signed vs unsigned multiplication. The appropriate + action is taken based on the type of the operand.

      +
      Example:
      + 
        <result> = mul int 4, %var          ; yields {int}:result = 4 * %var
+
      +
      + +
      'div' + Instruction
      +
      +
      Syntax:
      + 
        <result> = div <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'div' instruction returns the quotient of its two + operands.

      +
      Arguments:
      +

      The two arguments to the 'div' instruction must be either integer or floating point + values. Both arguments must have identical types.

      +
      Semantics:
      +

      The value produced is the integer or floating point quotient of the + two operands.

      +
      Example:
      + 
        <result> = div int 4, %var          ; yields {int}:result = 4 / %var
+
      +
      + +
      'rem' + Instruction
      +
      +
      Syntax:
      + 
        <result> = rem <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'rem' instruction returns the remainder from the + division of its two operands.

      +
      Arguments:
      +

      The two arguments to the 'rem' instruction must be either integer or floating point + values. Both arguments must have identical types.

      +
      Semantics:
      +

      This returns the remainder of a division (where the result + has the same sign as the divisor), not the modulus (where the + result has the same sign as the dividend) of a value. For more + information about the difference, see: The + Math Forum.

      +
      Example:
      + 
        <result> = rem int 4, %var          ; yields {int}:result = 4 % %var
+
      +
      + +
      'setcc' + Instructions
      +
      +
      Syntax:
      + 
        <result> = seteq <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setne <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setlt <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setgt <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setle <ty> <var1>, <var2>   ; yields {bool}:result
+   <result> = setge <ty> <var1>, <var2>   ; yields {bool}:result
+
      +
      Overview:
      +

      The 'setcc' family of instructions returns a boolean + value based on a comparison of their two operands.

      +
      Arguments:
      +

      The two arguments to the 'setcc' instructions must + be of first class type (it is not possible + to compare 'label's, 'array's, 'structure' + or 'void' values, etc...). Both arguments must have identical + types.

      +
      Semantics:
      +

      The 'seteq' instruction yields a true 'bool' + value if both operands are equal.
      + The 'setne' instruction yields a true 'bool' + value if both operands are unequal.
      + The 'setlt' instruction yields a true 'bool' + value if the first operand is less than the second operand.
      + The 'setgt' instruction yields a true 'bool' + value if the first operand is greater than the second operand.
      + The 'setle' instruction yields a true 'bool' + value if the first operand is less than or equal to the second operand.
      + The 'setge' instruction yields a true 'bool' + value if the first operand is greater than or equal to the second + operand.

      +
      Example:
      + 
        <result> = seteq int   4, 5        ; yields {bool}:result = false
+   <result> = setne float 4, 5        ; yields {bool}:result = true
+   <result> = setlt uint  4, 5        ; yields {bool}:result = true
+   <result> = setgt sbyte 4, 5        ; yields {bool}:result = false
+   <result> = setle sbyte 4, 5        ; yields {bool}:result = true
+   <result> = setge sbyte 4, 5        ; yields {bool}:result = false
+
      +
      + +
      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 strength reduced from other + instructions. They require two operands, execute an operation on them, + and produce a single value. The resulting value of the bitwise binary + operators is always the same type as its first operand.

      +
      + +
      'and' + Instruction
      +
      +
      Syntax:
      + 
        <result> = and <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'and' instruction returns the bitwise logical and of + its two operands.

      +
      Arguments:
      +

      The two arguments to the 'and' instruction must be integral values. Both arguments must have + identical types.

      +
      Semantics:
      +

      The truth table used for the 'and' instruction is:

      +

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      In0In1Out
      000
      010
      100
      111
      +
      +
      Example:
      + 
        <result> = and int 4, %var         ; yields {int}:result = 4 & %var
+   <result> = and int 15, 40          ; yields {int}:result = 8
+   <result> = and int 4, 8            ; yields {int}:result = 0
+
      +
      + +
      'or' Instruction
      +
      +
      Syntax:
      + 
        <result> = or <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'or' instruction returns the bitwise logical inclusive + or of its two operands.

      +
      Arguments:
      +

      The two arguments to the 'or' instruction must be integral values. Both arguments must have + identical types.

      +
      Semantics:
      +

      The truth table used for the 'or' instruction is:

      +

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      In0In1Out
      000
      011
      101
      111
      +
      +
      Example:
      + 
        <result> = or int 4, %var         ; yields {int}:result = 4 | %var
+   <result> = or int 15, 40          ; yields {int}:result = 47
+   <result> = or int 4, 8            ; yields {int}:result = 12
+
      +
      + +
      'xor' + Instruction
      +
      +
      Syntax:
      + 
        <result> = xor <ty> <var1>, <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'xor' instruction returns the bitwise logical exclusive + or of its two operands. The xor is used to implement the + "one's complement" operation, which is the "~" operator in C.

      +
      Arguments:
      +

      The two arguments to the 'xor' instruction must be integral values. Both arguments must have + identical types.

      +
      Semantics:
      +

      The truth table used for the 'xor' instruction is:

      +

      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      In0In1Out
      000
      011
      101
      110
      +
      +

      +
      Example:
      + 
        <result> = xor int 4, %var         ; yields {int}:result = 4 ^ %var
+   <result> = xor int 15, 40          ; yields {int}:result = 39
+   <result> = xor int 4, 8            ; yields {int}:result = 12
+   <result> = xor int %V, -1          ; yields {int}:result = ~%V
+
      +
      + +
      'shl' + Instruction
      +
      +
      Syntax:
      + 
        <result> = shl <ty> <var1>, ubyte <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'shl' instruction returns the first operand shifted to + the left a specified number of bits.

      +
      Arguments:
      +

      The first argument to the 'shl' instruction must be an integer type. The second argument must be an 'ubyte' + type.

      +
      Semantics:
      +

      The value produced is var1 * 2var2.

      +
      Example:
      + 
        <result> = shl int 4, ubyte %var   ; yields {int}:result = 4 << %var
+   <result> = shl int 4, ubyte 2      ; yields {int}:result = 16
+   <result> = shl int 1, ubyte 10     ; yields {int}:result = 1024
+
      +
      + +
      'shr' + Instruction
      +
      +
      Syntax:
      + 
        <result> = shr <ty> <var1>, ubyte <var2>   ; yields {ty}:result
+
      +
      Overview:
      +

      The 'shr' instruction returns the first operand shifted to + the right a specified number of bits.

      +
      Arguments:
      +

      The first argument to the 'shr' instruction must be an integer type. The second argument must be an 'ubyte' + type.

      +
      Semantics:
      +

      If the first argument is a signed type, the + most significant bit is duplicated in the newly free'd bit positions. + If the first argument is unsigned, zero bits shall fill the empty + positions.

      +
      Example:
      + 
        <result> = shr int 4, ubyte %var   ; yields {int}:result = 4 >> %var
+   <result> = shr uint 4, ubyte 1     ; yields {uint}:result = 2
+   <result> = shr int 4, ubyte 2      ; yields {int}:result = 1
+   <result> = shr sbyte 4, ubyte 3    ; yields {sbyte}:result = 0
+   <result> = shr sbyte -2, ubyte 1   ; yields {sbyte}:result = -1
+
      +
      + +
      Memory Access + 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, + allocate and free memory in LLVM.

      +
      + +
      'malloc' + Instruction
      +
      +
      Syntax:
      + 
        <result> = malloc <type>, uint <NumElements>     ; yields {type*}:result
+   <result> = malloc <type>                         ; yields {type*}:result
+
      +
      Overview:
      +

      The 'malloc' instruction allocates memory from the system + heap and returns a pointer to it.

      +
      Arguments:
      +

      The 'malloc' instruction allocates sizeof(<type>)*NumElements + bytes of memory from the operating system and returns a pointer of the + appropriate type to the program. The second form of the instruction is + a shorter version of the first instruction that defaults to allocating + one element.

      +

      'type' must be a sized type.

      +
      Semantics:
      +

      Memory is allocated using the system "malloc" function, and + a pointer is returned.

      +
      Example:
      + 
        %array  = malloc [4 x ubyte ]                    ; yields {[%4 x ubyte]*}:array
+ 
+   %size   = add uint 2, 2                          ; yields {uint}:size = uint 4
+   %array1 = malloc ubyte, uint 4                   ; yields {ubyte*}:array1
+   %array2 = malloc [12 x ubyte], uint %size        ; yields {[12 x ubyte]*}:array2
+
      +
      + +
      'free' + Instruction
      +
      +
      Syntax:
      + 
        free <type> <value>                              ; yields {void}
+
      +
      Overview:
      +

      The 'free' instruction returns memory back to the unused + memory heap, to be reallocated in the future.

      +

      +
      Arguments:
      +

      'value' shall be a pointer value that points to a value + that was allocated with the 'malloc' + instruction.

      +
      Semantics:
      +

      Access to the memory pointed to by the pointer is not longer defined + after this instruction executes.

      +
      Example:
      + 
        %array  = malloc [4 x ubyte]                    ; yields {[4 x ubyte]*}:array
+             free   [4 x ubyte]* %array
+
      +
      + +
      'alloca' + Instruction
      +
      +
      Syntax:
      + 
        <result> = alloca <type>, uint <NumElements>  ; yields {type*}:result
+   <result> = alloca <type>                      ; yields {type*}:result
+
      +
      Overview:
      +

      The 'alloca' instruction allocates memory on the current + stack frame of the procedure that is live until the current function + returns to its caller.

      +
      Arguments:
      +

      The the 'alloca' instruction allocates sizeof(<type>)*NumElements + bytes of memory on the runtime stack, returning a pointer of the + appropriate type to the program. The second form of the instruction is + a shorter version of the first that defaults to allocating one element.

      +

      'type' may be any sized type.

      +
      Semantics:
      +

      Memory is allocated, a pointer is returned. 'alloca'd + memory is automatically released when the function returns. The 'alloca' + instruction is commonly used to represent automatic variables that must + have an address available. When the function returns (either with the ret or invoke + instructions), the memory is reclaimed.

      +
      Example:
      + 
        %ptr = alloca int                              ; yields {int*}:ptr
+   %ptr = alloca int, uint 4                      ; yields {int*}:ptr
+
      +
      + +
      'load' + Instruction
      +
      +
      Syntax:
      + 
        <result> = load <ty>* <pointer>
        <result> = volatile load <ty>* <pointer>
      +
      Overview:
      +

      The 'load' instruction is used to read from memory.

      +
      Arguments:
      +

      The argument to the 'load' instruction specifies the memory + address to load from. The pointer must point to a first class type. If the load is + marked as volatile then the optimizer is not allowed to modify + the number or order of execution of this load with other + volatile load and store + instructions.

      +
      Semantics:
      +

      The location of memory pointed to is loaded.

      +
      Examples:
      + 
        %ptr = alloca int                               ; yields {int*}:ptr
+   store int 3, int* %ptr                          ; yields {void}
+   %val = load int* %ptr                           ; yields {int}:val = int 3
+
      +
      + +
      'store' + Instruction
      +
      Syntax:
      + 
        store <ty> <value>, <ty>* <pointer>                   ; yields {void}
+   volatile store <ty> <value>, <ty>* <pointer>                   ; yields {void}
+
      +
      Overview:
      +

      The 'store' instruction is used to write to memory.

      +
      Arguments:
      +

      There are two arguments to the 'store' instruction: a value + to store and an address to store it into. The type of the '<pointer>' + operand must be a pointer to the type of the '<value>' + operand. If the store is marked as volatile then the + optimizer is not allowed to modify the number or order of execution of + this store with other volatile load and store instructions.

      +
      Semantics:
      +

      The contents of memory are updated to contain '<value>' + at the location specified by the '<pointer>' operand.

      +
      Example:
      + 
        %ptr = alloca int                               ; yields {int*}:ptr
+   store int 3, int* %ptr                          ; yields {void}
+   %val = load int* %ptr                           ; yields {int}:val = int 3
+
      + +
      'getelementptr' + Instruction
      +
      +
      Syntax:
      + 
        <result> = getelementptr <ty>* <ptrval>{, long <aidx>|, ubyte <sidx>}*
      +
      Overview:
      +

      The 'getelementptr' instruction is used to get the address + of a subelement of an aggregate data structure.

      +
      Arguments:
      +

      This instruction takes a list of long values and ubyte + constants that indicate what form of addressing to perform. The actual + types of the arguments provided depend on the type of the first pointer + argument. The 'getelementptr' instruction is used to index + down through the type levels of a structure.

      +

      For example, let's consider a C code fragment and how it gets + compiled to LLVM:

      + 
      struct RT {
        char A;
        int B[10][20];
        char C;
      };
      struct ST {
        int X;
        double Y;
        struct RT Z;
      };

      int *foo(struct ST *s) {
        return &s[1].Z.B[5][13];
      }
      +

      The LLVM code generated by the GCC frontend is:

      + 
      %RT = type { sbyte, [10 x [20 x int]], sbyte }
      %ST = type { int, double, %RT }

      int* "foo"(%ST* %s) {
        %reg = getelementptr %ST* %s, long 1, ubyte 2, ubyte 1, long 5, long 13
        ret int* %reg
      }
      +
      Semantics:
      +

      The index types specified for the 'getelementptr' + instruction depend on the pointer type that is being index into. Pointer and array types + require 'long' values, and structure + types require 'ubyte' constants.

      +

      In the example above, the first index is indexing into the '%ST*' + type, which is a pointer, yielding a '%ST' = '{ int, + double, %RT }' type, a structure. The second index indexes into + the third element of the structure, yielding a '%RT' = '{ + sbyte, [10 x [20 x int]], sbyte }' type, another structure. The + third index indexes into the second element of the structure, yielding + a '[10 x [20 x int]]' type, an array. The two dimensions of + the array are subscripted into, yielding an 'int' type. The 'getelementptr' + instruction return a pointer to this element, thus yielding a 'int*' + type.

      +

      Note that it is perfectly legal to index partially through a + structure, returning a pointer to an inner element. Because of this, + the LLVM code for the given testcase is equivalent to:

      + 
      int* "foo"(%ST* %s) {
        %t1 = getelementptr %ST* %s , long 1                        ; yields %ST*:%t1
+   %t2 = getelementptr %ST* %t1, long 0, ubyte 2               ; yields %RT*:%t2
+   %t3 = getelementptr %RT* %t2, long 0, ubyte 1               ; yields [10 x [20 x int]]*:%t3
+   %t4 = getelementptr [10 x [20 x int]]* %t3, long 0, long 5  ; yields [20 x int]*:%t4
+   %t5 = getelementptr [20 x int]* %t4, long 0, long 13        ; yields int*:%t5
+   ret int* %t5
+ }
+
      +
      Example:
      + 
        ; yields [12 x ubyte]*:aptr
+   %aptr = getelementptr {int, [12 x ubyte]}* %sptr, long 0, ubyte 1
      +
       Note To The Novice:
      + When using indexing into global arrays with the 'getelementptr' + instruction, you must remember that the 
      + +
      Other Operations
      +
      +

      The instructions in this catagory are the "miscellaneous" + instructions, which defy better classification.

      +
      + +
      'phi' + Instruction
      +
      +
      Syntax:
      + 
        <result> = phi <ty> [ <val0>, <label0>], ...
      +
      Overview:
      +

      The 'phi' instruction is used to implement the φ node in + the SSA graph representing the function.

      +
      Arguments:
      +

      The type of the incoming values are specified with the first type + field. After this, the 'phi' instruction takes a list of pairs + as arguments, with one pair for each predecessor basic block of the + current block. Only values of first class + type may be used as the value arguments to the PHI node. Only labels + may be used as the label arguments.

      +

      There must be no non-phi instructions between the start of a basic + block and the PHI instructions: i.e. PHI instructions must be first in + a basic block.

      +
      Semantics:
      +

      At runtime, the 'phi' instruction logically takes on the + value specified by the parameter, depending on which basic block we + came from in the last terminator instruction.

      +
      Example:
      + 
      Loop:       ; Infinite loop that counts from 0 on up...
        %indvar = phi uint [ 0, %LoopHeader ], [ %nextindvar, %Loop ]
        %nextindvar = add uint %indvar, 1
        br label %Loop
      +
      + + +
      + 'cast .. to' Instruction +
      + +
      + +
      Syntax:
      + + 
      +   <result> = cast <ty> <value> to <ty2>             ; yields ty2
+
      + +
      Overview:
      + +

      + The 'cast' instruction is used as the primitive means to convert + integers to floating point, change data type sizes, and break type safety (by + casting pointers). +

      + + +
      Arguments:
      + +

      + The 'cast' instruction takes a value to cast, which must be a first + class value, and a type to cast it to, which must also be a first class type. +

      + +
      Semantics:
      + +

      + This instruction follows the C rules for explicit casts when determining how the + data being cast must change to fit in its new container. +

      + +

      + When casting to bool, any value that would be considered true in the context of + a C 'if' condition is converted to the boolean 'true' values, + all else are 'false'. +

      + +

      + When extending an integral value from a type of one signness to another (for + example 'sbyte' to 'ulong'), the value is sign-extended if the + source value is signed, and zero-extended if the source value is + unsigned. bool values are always zero extended into either zero or + one. +

      + +
      Example:
      + + 
      +   %X = cast int 257 to ubyte              ; yields ubyte:1
+   %Y = cast int 123 to bool               ; yields bool:true
+
      +
      + + +
      + 'select' Instruction +
      + +
      + +
      Syntax:
      + + 
      +   <result> = select bool <cond>, <ty> <val1>, <ty> <val2>             ; yields ty
+
      + +
      Overview:
      + +

      + The 'select' instruction is used to choose one value based on a + condition, without branching. +

      + + +
      Arguments:
      + +

      + The 'select' instruction requires a boolean value indicating the condition, and two values of the same first class type. +

      + +
      Semantics:
      + +

      + If the boolean condition evaluates to true, the instruction returns the first + value argument, otherwise it returns the second value argument. +

      + +
      Example:
      + + 
      +   %X = select bool true, ubyte 17, ubyte 42          ; yields ubyte:17
+
      +
      + + + + + + +
      'call' + Instruction
      +
      +
      Syntax:
      + 
        <result> = call <ty>* <fnptrval>(<param list>)
      +
      Overview:
      +

      The 'call' instruction represents a simple function call.

      +
      Arguments:
      +

      This instruction requires several arguments:

      +
        +
      1. +

        'ty': shall be the signature of the pointer to function + value being invoked. The argument types must match the types implied + by this signature.

        +
        2. +
      2. +

        'fnptrval': An LLVM value containing a pointer to a + function to be invoked. In most cases, this is a direct function + invocation, but indirect calls are just as possible, + calling an arbitrary pointer to function values.

        +
        3. +
      3. +

        'function args': argument list whose types match the + function signature argument types. If the function signature + indicates the function accepts a variable number of arguments, the + extra arguments can be specified.

        +
        4. +
      +
      Semantics:
      +

      The 'call' instruction is used to cause control flow to + transfer to a specified function, with its incoming arguments bound to + the specified values. Upon a 'ret' + instruction in the called function, control flow continues with the + instruction after the function call, and the return value of the + function is bound to the result argument. This is a simpler case of + the invoke instruction.

      +
      Example:
      + 
        %retval = call int %test(int %argc)
        call int(sbyte*, ...) *%printf(sbyte* %msg, int 12, sbyte 42);
      +
      + +
      'vanext' + Instruction
      +
      +
      Syntax:
      + 
        <resultarglist> = vanext <va_list> <arglist>, <argty>
      +
      Overview:
      +

      The 'vanext' instruction is used to access arguments passed + through the "variable argument" area of a function call. It is used to + implement the va_arg macro in C.

      +
      Arguments:
      +

      This instruction takes a valist value and the type of the + argument. It returns another valist.

      +
      Semantics:
      +

      The 'vanext' instruction advances the specified valist + past an argument of the specified type. In conjunction with the vaarg instruction, it is used to implement + the va_arg macro available in C. For more information, see + the variable argument handling Intrinsic + Functions.

      +

      It is legal for this instruction to be called in a function which + does not take a variable number of arguments, for example, the vfprintf + function.

      +

      vanext is an LLVM instruction instead of an intrinsic function because it takes an type as + an argument.

      +
      Example:
      +

      See the variable argument processing + section.

      +
      + +
      'vaarg' + Instruction
      +
      +
      Syntax:
      + 
        <resultval> = vaarg <va_list> <arglist>, <argty>
      +
      Overview:
      +

      The 'vaarg' instruction is used to access arguments passed + through the "variable argument" area of a function call. It is used to + implement the va_arg macro in C.

      +
      Arguments:
      +

      This instruction takes a valist value and the type of the + argument. It returns a value of the specified argument type.

      +
      Semantics:
      +

      The 'vaarg' instruction loads an argument of the specified + type from the specified va_list. In conjunction with the vanext instruction, it is used to + implement the va_arg macro available in C. For more + information, see the variable argument handling Intrinsic + Functions.

      +

      It is legal for this instruction to be called in a function which + does not take a variable number of arguments, for example, the vfprintf + function.

      +

      vaarg is an LLVM instruction instead of an intrinsic function because it takes an type as + an argument.

      +
      Example:
      +

      See the variable argument processing + section.

      +
      + + +
      Intrinsic Functions
      + + +
      + +

      LLVM supports the notion of an "intrinsic function". These functions have + well known names and semantics, and are required to follow certain + restrictions. Overall, these instructions represent an extension mechanism for + the LLVM language that does not require changing all of the transformations in + LLVM to add to the language (or the bytecode reader/writer, the parser, + etc...).

      + +

      Intrinsic function names must all start with an "llvm." prefix, this + prefix is reserved in LLVM for intrinsic names, thus functions may not be named + this. Intrinsic functions must always be external functions: you cannot define + the body of intrinsic functions. Intrinsic functions may only be used in call + or invoke instructions: it is illegal to take the address of an intrinsic + function. Additionally, because intrinsic functions are part of the LLVM + language, it is required that they all be documented here if any are added.

      + + +

      + Adding an intrinsic to LLVM is straight-forward if it is possible to express the + concept in LLVM directly (ie, code generator support is not _required_). To do + this, extend the default implementation of the IntrinsicLowering class to handle + the intrinsic. Code generators use this class to lower intrinsics they do not + understand to raw LLVM instructions that they do. +

      + +
      + + +
      + Variable Argument Handling Intrinsics +
      + +
      +

      Variable argument support is defined in LLVM with the vanext instruction and these three + intrinsic functions. These functions are related to the similarly + named macros defined in the <stdarg.h> header file.

      +

      All of these functions operate on arguments that use a + target-specific value type "va_list". The LLVM assembly + language reference manual does not define what this type is, so all + transformations should be prepared to handle intrinsics with any type + used.

      +

      This example shows how the vanext + instruction and the variable argument handling intrinsic functions are + used.

      + 
      + int %test(int %X, ...) {
+   ; Initialize variable argument processing
+   %ap = call sbyte* %llvm.va_start()
+ 
+   ; Read a single integer argument
+   %tmp = vaarg sbyte* %ap, int
+ 
+   ; Advance to the next argument
+   %ap2 = vanext sbyte* %ap, int
+ 
+   ; Demonstrate usage of llvm.va_copy and llvm.va_end
+   %aq = call sbyte* %llvm.va_copy(sbyte* %ap2)
+   call void %llvm.va_end(sbyte* %aq)
+ 
+   ; Stop processing of arguments.
+   call void %llvm.va_end(sbyte* %ap2)
+   ret int %tmp
+ }
+
      +
      + + +
      + 'llvm.va_start' Intrinsic +
      + + +
      +
      Syntax:
      + 
        call va_list ()* %llvm.va_start()
      +
      Overview:
      +

      The 'llvm.va_start' intrinsic returns a new <arglist> + for subsequent use by the variable argument intrinsics.

      +
      Semantics:
      +

      The 'llvm.va_start' intrinsic works just like the va_start + macro available in C. In a target-dependent way, it initializes and + returns a va_list element, so that the next vaarg + will produce the first variable argument passed to the function. Unlike + the C va_start macro, this intrinsic does not need to know the + last argument of the function, the compiler can figure that out.

      +

      Note that this intrinsic function is only legal to be called from + within the body of a variable argument function.

      +
      + + +
      + 'llvm.va_end' Intrinsic +
      + +
      +
      Syntax:
      + 
        call void (va_list)* %llvm.va_end(va_list <arglist>)
      +
      Overview:
      +

      The 'llvm.va_end' intrinsic destroys <arglist> + which has been initialized previously with llvm.va_start + or llvm.va_copy.

      +
      Arguments:
      +

      The argument is a va_list to destroy.

      +
      Semantics:
      +

      The 'llvm.va_end' intrinsic works just like the va_end + macro available in C. In a target-dependent way, it destroys the va_list. + Calls to llvm.va_start and llvm.va_copy must be matched exactly + with calls to llvm.va_end.

      +
      + + +
      + 'llvm.va_copy' Intrinsic +
      + +
      +
      Syntax:
      + 
        call va_list (va_list)* %llvm.va_copy(va_list <destarglist>)
      +
      Overview:
      +

      The 'llvm.va_copy' intrinsic copies the current argument + position from the source argument list to the destination argument list.

      +
      Arguments:
      +

      The argument is the va_list to copy.

      +
      Semantics:
      +

      The 'llvm.va_copy' intrinsic works just like the va_copy + macro available in C. In a target-dependent way, it copies the source va_list + element into the returned list. This intrinsic is necessary because the llvm.va_start intrinsic may be arbitrarily + complex and require memory allocation, for example.

      +
      + + +
      + 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:
      + 
      +   call void* ()* %llvm.returnaddress(uint <level>)
+
      + +
      Overview:
      + +

      + The 'llvm.returnaddress' intrinsic returns a target-specific value + indicating the return address of the current function or one of its callers. +

      + +
      Arguments:
      + +

      + The argument to this intrinsic indicates which function to return the address + for. Zero indicates the calling function, one indicates its caller, etc. The + argument is required to be a constant integer value. +

      + +
      Semantics:
      + +

      + The 'llvm.returnaddress' intrinsic either returns a pointer indicating + the return address of the specified call frame, or zero if it cannot be + identified. The value returned by this intrinsic is likely to be incorrect or 0 + for arguments other than zero, so it should only be used for debugging purposes. +

      + +

      + Note that calling this intrinsic does not prevent function inlining or other + aggressive transformations, so the value returned may not that of the obvious + source-language caller. +

      +
      + + + +
      + 'llvm.frameaddress' Intrinsic +
      + +
      + +
      Syntax:
      + 
      +   call void* ()* %llvm.frameaddress(uint <level>)
+
      + +
      Overview:
      + +

      + The 'llvm.frameaddress' intrinsic returns the target-specific frame + pointer value for the specified stack frame. +

      + +
      Arguments:
      + +

      + The argument to this intrinsic indicates which function to return the frame + pointer for. Zero indicates the calling function, one indicates its caller, + etc. The argument is required to be a constant integer value. +

      + +
      Semantics:
      + +

      + The 'llvm.frameaddress' intrinsic either returns a pointer indicating + the frame address of the specified call frame, or zero if it cannot be + identified. The value returned by this intrinsic is likely to be incorrect or 0 + for arguments other than zero, so it should only be used for debugging purposes. +

      + +

      + Note that calling this intrinsic does not prevent function inlining or other + aggressive transformations, so the value returned may not that of the obvious + source-language caller. +

      +
      + + + +
      + 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:
      + 
      +   call void (sbyte*, sbyte*, uint, uint)* %llvm.memcpy(sbyte* <dest>, sbyte* <src>,
+                                                        uint <len>, uint <align>)
+
      + +
      Overview:
      + +

      + The 'llvm.memcpy' intrinsic copies a block of memory from the source + location to the destination location. +

      + +

      + Note that, unlike the standard libc function, the llvm.memcpy intrinsic + does not return a value, and takes an extra alignment argument. +

      + +
      Arguments:
      + +

      + The first argument is a pointer to the destination, the second is a pointer to + the source. The third argument is an (arbitrarily sized) integer argument + specifying the number of bytes to copy, and the fourth argument is the alignment + of the source and destination locations. +

      + +

      + If the call to this intrinisic has an alignment value that is not 0 or 1, then + the caller guarantees that the size of the copy is a multiple of the alignment + and that both the source and destination pointers are aligned to that boundary. +

      + +
      Semantics:
      + +

      + The 'llvm.memcpy' intrinsic copies a block of memory from the source + location to the destination location, which are not allowed to overlap. It + copies "len" bytes of memory over. If the argument is known to be aligned to + some boundary, this can be specified as the fourth argument, otherwise it should + be set to 0 or 1. +

      +
      + + + +
      + 'llvm.memmove' Intrinsic +
      + +
      + +
      Syntax:
      + 
      +   call void (sbyte*, sbyte*, uint, uint)* %llvm.memmove(sbyte* <dest>, sbyte* <src>,
+                                                        uint <len>, uint <align>)
+
      + +
      Overview:
      + +

      + The 'llvm.memmove' intrinsic moves a block of memory from the source + location to the destination location. It is similar to the 'llvm.memcpy' + intrinsic but allows the two memory locations to overlap. +

      + +

      + Note that, unlike the standard libc function, the llvm.memmove intrinsic + does not return a value, and takes an extra alignment argument. +

      + +
      Arguments:
      + +

      + The first argument is a pointer to the destination, the second is a pointer to + the source. The third argument is an (arbitrarily sized) integer argument + specifying the number of bytes to copy, and the fourth argument is the alignment + of the source and destination locations. +

      + +

      + If the call to this intrinisic has an alignment value that is not 0 or 1, then + the caller guarantees that the size of the copy is a multiple of the alignment + and that both the source and destination pointers are aligned to that boundary. +

      + +
      Semantics:
      + +

      + The 'llvm.memmove' intrinsic copies a block of memory from the source + location to the destination location, which may overlap. It + copies "len" bytes of memory over. If the argument is known to be aligned to + some boundary, this can be specified as the fourth argument, otherwise it should + be set to 0 or 1. +

      +
      + + + +
      + 'llvm.memset' Intrinsic +
      + +
      + +
      Syntax:
      + 
      +   call void (sbyte*, ubyte, uint, uint)* %llvm.memset(sbyte* <dest>, ubyte <val>,
+                                                       uint <len>, uint <align>)
+
      + +
      Overview:
      + +

      + The 'llvm.memset' intrinsic fills a block of memory with a particular + byte value. +

      + +

      + Note that, unlike the standard libc function, the llvm.memset intrinsic + does not return a value, and takes an extra alignment argument. +

      + +
      Arguments:
      + +

      + The first argument is a pointer to the destination to fill, the second is the + byte value to fill it with, the third argument is an (arbitrarily sized) integer + argument specifying the number of bytes to fill, and the fourth argument is the + known alignment of destination location. +

      + +

      + If the call to this intrinisic has an alignment value that is not 0 or 1, then + the caller guarantees that the size of the copy is a multiple of the alignment + and that the destination pointer is aligned to that boundary. +

      + +
      Semantics:
      + +

      + The 'llvm.memset' intrinsic fills "len" bytes of memory starting at the + destination location. If the argument is known to be aligned to some boundary, + this can be specified as the fourth argument, otherwise it should be set to 0 or + 1. +

      +
      + + + +
      + Debugger Intrinsics +
      + +
      +

      + The LLVM debugger intrinsics (which all start with llvm.dbg. prefix), + are described in the LLVM Source Level + Debugging document. +

      +
      + + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + Chris Lattner
      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + Index: llvm-www/releases/1.2/docs/Makefile diff -c /dev/null llvm-www/releases/1.2/docs/Makefile:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/Makefile Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,14 ---- + ##===- docs/Makefile ---------------------------------------*- Makefile -*-===## + # + # The LLVM Compiler Infrastructure + # + # This file was developed by the LLVM research group and is distributed under + # the University of Illinois Open Source License. See LICENSE.TXT for details. + # + ##===----------------------------------------------------------------------===## + doxygen-files: + doxygen doxygen.cfg + + doxygen.tar.gz: doxygen/index.html + rm -rf $@ + gtar czvf $@ doxygen Index: llvm-www/releases/1.2/docs/ObjectFiles.html diff -c /dev/null llvm-www/releases/1.2/docs/ObjectFiles.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/ObjectFiles.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,298 ---- + + + + Object Files: Understanding The Result Of LLVM Compilation + + + +
      Object Files: Understanding The Result Of LLVM Compilation
      +
      +
        +
      1. Abstract
        2. +
      2. Introduction
        3. +
      3. File Contents
        4. +
      4. Linkage Rules Of Thumb +
          +
        1. Always Link vmcore.o, support.a +
        2. Placeholder +
        +
        5. +
      +
      +

      Written by Reid Spencer

      +

      +
      +
      + +
      Abstract
      +
      +

      This document describes the contents of the many objects files and libraries + that are produced by compiling LLVM. To make use of LLVM this information is + needed in order to understand what files should be linked into your program. +

      +
      + +
      Introduction
      +
      +

      If you're writing a compiler, virtual machine, or any other utility for + LLVM, you'll need to figure out which of the many .a (archive) and .o + (object) files you will need to link with to be successful. An + understanding of the contents of these files and their inter-relationships + will be useful in coming up with an optimal specification for the objects + and libraries to link with. +

      +

      The purpose of this document is to hopefully reduce some of the trial and + error that the author experienced in using LLVM. +

      +
      + +
      File Contents
      +
      +

      The table below provides a summary of the basic contents of each file.

      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Summary Of LLVM Library And Object Files +

      Library

      Description

      libipo.a + An archive of all inter-procedural optimizations. +
      libscalaropts.a + An archive of all scalar optimizations. +
      libtransforms.a + An archive of just the level raise pass. +
      libtarget.a + An archive containing code generator support for describing + target architectures. +
      libanalysis.a + An archive containing intra-procedural analyses. +
      libdatastructure.a + An archive containing optimizations for data structures. +
      libinstrument.aNo idea.
      libregalloc.aRegister Allocation code.
      libipa.a + An archive containing inter-procedural analyses
      libtransformutils.a + Utiltities for transformations? +
      libsupport.aGeneral support utilities
      libevar.aLive variable analysis for SPARC

      Object File

      Description

      support.oGeneral support utilities
      asmparser.oAssembler Parser
      bcreader.oByte Code Reader
      bcwriter.oByte Code Writer
      sched.oSPARC instruction scheduler
      selectiondag.oAggressive instruction selector for Directed Acyclic Graphs
      transformutils.oUtilities for code transformations
      ipa.oInter-Procedural Analysis Optimizations
      select.oSPARC instruction selector
      cwriter.o"C" Code Writer
      profpaths.oPath profiling instrumentation
      regalloc.oRegister Allocation
      instrument.oInstrumentation? Of What?
      datastructure.oData Structure Analysis
      codegen.oNative code generation
      livevar.oLive Variable Analysis
      vmcore.oVirtual Machine Core
      lli-interpreter.oInterpreter for LLVM ByteCode
      lli-jit.o + Just-In-Time Compiler For LLVM ByteCode +
      executionengine.oEngine for LLI
      debugger.oSource Level Debugging Support
      analysis.oGeneral Framework For Analysis?
      sparc.oSun SPARC Processor Specific
      target.oTarget Machine Support?
      transforms.oCode Transformations
      x86.oIntel x86 Processor Specific
      powerpc.oPowerPC Processor Specific
      scalaropts.oOptimizations For Scalars
      ipo.oInter-Procedural Optimization
      trace.oSupport For Tracing/Debugging?
      profile_rt.oRuntime Library For Profiler
      sample.oSample Program ?
      stkr_compiler.oStacker Language Compiler Library
      stkr_runtime.oStacker Language Runtime Library
      +
      +

      + +
      Linkage Rules Of Thumb
      +
      +

      This section contains various "rules of thumb" about what files you + should link into your programs.

      +
      + +
      Always Link vmcore.o support.a +
      +
      +

      No matter what you do with LLVM, you'll always need to link with vmcore.o + and support.a.

      +
      + +
      Placeholder
      +
      +

      Need more rules of thumb here.

      +
      + +
      +
      +
      Reid Spencer
      + The LLVM Compiler Infrastructure +
      Last modified: $Date: 2004/03/19 17:38:11 $
      + + + Index: llvm-www/releases/1.2/docs/OpenProjects.html diff -c /dev/null llvm-www/releases/1.2/docs/OpenProjects.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/OpenProjects.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,334 ---- + + + + Open LLVM Projects + + + + +
      + Open LLVM Projects +
      + + + + +
      + What is this? +
      + + +
      + +

      This document is meant to be a sort of "big TODO list" for LLVM. Each + project in this document is something that would be useful for LLVM to have, and + would also be a great way to get familiar with the system. Some of these + projects are small and self-contained, which may be implemented in a couple of + days, others are larger. Several of these projects may lead to interesting + research projects in their own right. In any case, we welcome all + contributions.

      + +

      If you are thinking about tackling one of these projects, please send a mail + to the LLVM + Developer's mailing list, so that we know the project is being worked on. + Additionally this is a good way to get more information about a specific project + or to suggest other projects to add to this page. +

      + +

      The projects in this page are open ended. More specific projects are + filed as unassigned enhancements in our + LLVM bug tracker. Here is the current list: +

      + + + +
      + + +
      + Improving the current system +
      + + +
      + +

      Improvements to the current infrastructure are always very welcome and tend + to be fairly straight-forward to implement. Here are some of the key areas that + can use improvement...

      + +
      + + +
      + Port glibc to LLVM +
      + +
      + +

      It would be very useful to port glibc to LLVM. This would allow a + variety of interprocedural algorithms to be much more effective in the face of + library calls. The most important pieces to port are things like the string + library and the stdio related functions... low-level system calls like + 'read' should stay unimplemented in LLVM.

      + +
      + + +
      + Improving the Nightly Tester +
      + +
      + +

      The Nightly Tester is a simple perl script + (located in utils/NightlyTest.pl) which runs every night to generate a + daily report. It could use the following improvements:

      + +
        +
      1. Regression tests - We should run the regression tests in addition to the + program tests...
        2. +
      + +
      + + +
      + Compile programs with the LLVM Compiler +
      + +
      + +

      We are always looking for new testcases and benchmarks for use with LLVM. In + particular, it is useful to try compiling your favorite C source code with LLVM. + If it doesn't compile, try to figure out why or report it to the llvm-bugs list. If you + get the program to compile, it would be extremely useful to convert the build + system to be compatible with the LLVM Programs testsuite so that we can check it + into CVS and the automated tester can use it to track progress of the + compiler.

      + +

      When testing a code, try running it with a variety of optimizations, and with + all the back-ends: CBE, llc, and lli.

      + +
      + + +
      + Extend the LLVM intermediate representation +
      + +
      + +
        +
      1. Add support for platform-independent prefetch support. The GCC prefetch project page + has a good survey of the prefetching capabilities of a variety of modern + processors.
        2. + +
      + +
      + + +
      + Miscellaneous Improvements +
      + +
      + +
        +
      1. Someone needs to look into getting the ranlib tool to index LLVM + bytecode files, so that linking in .a files is not hideously slow. They + would also then have to implement the reader for this index in + gccld.
        2. + +
      2. Rework the PassManager to be more flexible
        3. + +
      3. Some transformations and analyses only work on reducible flow graphs. It + would be nice to have a transformation which could be "required" by these passes + which makes irreducible graphs reducible. This can easily be accomplished + through code duplication. See Making Graphs Reducible + with Controlled Node Splitting and perhaps Nesting of Reducible and + Irreducible Loops.
        4. + +
      + +
      + + +
      + Adding new capabilities to LLVM +
      + + +
      + +

      Sometimes creating new things is more fun that improving existing things. + These projects tend to be more involved and perhaps require more work, but can + also be very rewarding.

      + +
      + + +
      + Pointer and Alias Analysis +
      + +
      + +

      We have a strong base for development of + both pointer analysis based optimizations as well as pointer analyses + themselves. It seems natural to want to take advantage of this...

      + +
        +
      1. Implement a flow-sensitive context-sensitive alias analysis algorithm
        + - Pick one of the somewhat efficient algorithms, but strive for maximum + precision
        2. + +
      2. Implement a flow-sensitive context-insensitive alias analysis algorithm
        + - Just an efficient local algorithm perhaps?
        3. + +
      3. Implement an interface to update analyses in response to common code motion + transformations
        4. + +
      4. Implement alias-analysis-based optimizations: +
          +
        • Dead store elimination
          • +
        • ...
          • +
        5. +
      + +
      + + +
      + Profile Guided Optimization +
      + +
      + +

      We now have a unified infrastructure for writing profile-guided + transformations, which will work either at offline-compile-time or in the JIT, + but we don't have many transformations. We would welcome new profile-guided + transformations as well as improvements to the current profiling system. +

      + +

      Ideas for profile guided transformations:

      + +
        +
      1. Superblock formation (with many optimizations)
        2. +
      2. Loop unrolling/peeling
        3. +
      3. Profile directed inlining
        4. +
      4. Code layout
        5. +
      5. ...
        6. +
      + +

      Improvements to the existing support:

      + +
        +
      1. The current block and edge profiling code that gets inserted is very simple + and inefficient. Through the use of control-dependence information, many fewer + counters could be inserted into the code. Also, if the execution count of a + loop is known to be a compile-time or runtime constant, all of the counters in + the loop could be avoided.
        2. + +
      2. You could implement one of the "static profiling" algorithms which analyze a + piece of code an make educated guesses about the relative execution frequencies + of various parts of the code.
        3. + +
      3. You could add path profiling support, or adapt the existing LLVM path + profiling code to work with the generic profiling interfaces.
        4. +
      + +
      + + +
      + New Transformations and Analyses +
      + +
      + +
        +
      1. Implement a Dependence Analysis Infrastructure
        + - Design some way to represent and query dep analysis
        2. +
      2. Implement a strength reduction pass
        3. +
      3. Value range propagation pass
        4. +
      4. Implement an unswitching pass
        5. +
      5. Write a loop unroller, with a simple heuristic for when to unroll
        6. +
      + +
      + + +
      + X86 Back-end Improvements +
      + +
      + +
        +
      1. Implement a global register allocator
        2. +
      2. Implement a better instruction selector
        3. +
      3. Implement support for the "switch" instruction without requiring the + lower-switches pass.
        4. +
      + +
      + + +
      + Miscellaneous Additions +
      + +
      + +
        +
      1. Write a new frontend for some language (Java? OCaml? Forth?)
        2. +
      2. Write a new backend for a target (IA64? MIPS? MMIX?)
        3. +
      3. Random test vector generator: Use a C grammar to generate random C code; + run it through llvm-gcc, then run a random set of passes on it using opt. + Try to crash opt. When opt crashes, use bugpoint to reduce the test case and + mail the result to yourself. Repeat ad infinitum.
        4. +
      4. Design a simple, recognizable logo.
        5. +
      + +
      + + + +
      +
      +
      Chris Lattner
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/ProgrammersManual.html diff -c /dev/null llvm-www/releases/1.2/docs/ProgrammersManual.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/ProgrammersManual.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,1836 ---- + + + + LLVM Programmer's Manual + + + + +
      + LLVM Programmer's Manual +
      + +
        +
      1. Introduction
        2. +
      2. General Information + +
        3. +
      3. Important and useful LLVM APIs + +
        4. +
      4. Helpful Hints for Common Operations + +
        5. +
      5. The Core LLVM Class Hierarchy Reference + +
        6. +
      + +
      +

      Written by Chris Lattner, + Dinakar Dhurjati, and Joel Stanley

      +
      + + +
      + Introduction +
      + + +
      + +

      This document is meant to highlight some of the important classes and + interfaces available in the LLVM source-base. This manual is not + intended to explain what LLVM is, how it works, and what LLVM code looks + like. It assumes that you know the basics of LLVM and are interested + in writing transformations or otherwise analyzing or manipulating the + code.

      + +

      This document should get you oriented so that you can find your + way in the continuously growing source code that makes up the LLVM + infrastructure. Note that this manual is not intended to serve as a + replacement for reading the source code, so if you think there should be + a method in one of these classes to do something, but it's not listed, + check the source. Links to the doxygen sources + are provided to make this as easy as possible.

      + +

      The first section of this document describes general information that is + useful to know when working in the LLVM infrastructure, and the second describes + the Core LLVM classes. In the future this manual will be extended with + information describing how to use extension libraries, such as dominator + information, CFG traversal routines, and useful utilities like the 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 + this, you might want to do a little background reading in the + techniques used and capabilities of the library. There are many good + pages that discuss the STL, and several books on the subject that you + can get, so it will not be discussed in this document.

      + +

      Here are some useful links:

      + +
        + +
      1. Dinkumware C++ Library + reference - an excellent reference for the STL and other parts of the + standard C++ library.
        2. + +
      2. C++ In a Nutshell - This is an + O'Reilly book in the making. It has a decent Standard Library + Reference that rivals Dinkumware's, and is actually free until the book is + published.
        3. + +
      3. C++ Frequently Asked + Questions
        4. + +
      4. SGI's STL Programmer's Guide - + Contains a useful Introduction to the + STL.
        5. + +
      5. Bjarne Stroustrup's C++ + Page
        6. + +
      + +

      You are also encouraged to take a look at the LLVM Coding Standards guide which focuses on how + to write maintainable code more than where to put your curly braces.

      + +
      + + +
      + Other useful references +
      + +
      + +

      LLVM is currently using CVS as its source versioning system. You may find + this reference handy:

      + +
        +
      1. CVS + Branch and Tag Primer
        2. +
      + +
      + + +
      + 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<> + operator, but they don't have some drawbacks (primarily stemming from + the fact that dynamic_cast<> only works on classes that + have a v-table). Because they are used so often, you must know what they + do and how they work. All of these templates are defined in the Support/Casting.h + file (note that you very rarely have to include this file directly).

      + +
      +
      isa<>:
      + +
      The isa<> operator works exactly like the Java + "instanceof" operator. It returns true or false depending on whether + a reference or pointer points to an instance of the specified class. This can + be very useful for constraint checking of various sorts (example below).
      + +
      cast<>:
      + +
      The cast<> operator is a "checked cast" operation. It + converts a pointer or reference from a base class to a derived cast, causing + an assertion failure if it is not really an instance of the right type. This + should be used in cases where you have some information that makes you believe + that something is of the right type. An example of the isa<> + and cast<> template is: + + 
      static bool isLoopInvariant(const Value *V, const
+   Loop *L) {
       if (isa<Constant>(V) || isa<Argument>(V) || isa<GlobalValue>(V))
       return true;

       //
+   Otherwise, it must be an instruction...
       return
+   !L->contains(cast<Instruction>(V)->getParent());
      + +

      Note that you should not use an isa<> test followed + by a cast<>, for that use the dyn_cast<> + operator.

      + +
      + +
      dyn_cast<>:
      + +
      The dyn_cast<> operator is a "checking cast" operation. It + checks to see if the operand is of the specified type, and if so, returns a + pointer to it (this operator does not work with references). If the operand is + not of the correct type, a null pointer is returned. Thus, this works very + much like the dynamic_cast operator in C++, and should be used in the + same circumstances. Typically, the dyn_cast<> operator is used + in an if statement or some other flow control statement like this: + + 
       if (AllocationInst *AI = dyn_cast<AllocationInst>(Val)) {
       ...
       }
      + +

      This form of the if statement effectively combines together a + call to isa<> and a call to cast<> into one + statement, which is very convenient.

      + +

      Another common example is:

      + + 
       // Loop over all of the phi nodes in a basic block
      
+    BasicBlock::iterator BBI = BB->begin();
       for (; PHINode *PN = dyn_cast<PHINode>(BBI); ++BBI)
       cerr << *PN;
      + +

      Note that the dyn_cast<> operator, like C++'s + dynamic_cast or Java's instanceof operator, can be abused. + In particular you should not use big chained if/then/else blocks to + check for lots of different variants of classes. If you find yourself + wanting to do this, it is much cleaner and more efficient to use the + InstVisitor class to dispatch over the instruction type directly.

      + +
      + +
      cast_or_null<>:
      + +
      The cast_or_null<> operator works just like the + cast<> operator, except that it allows for a null pointer as + an argument (which it then propagates). This can sometimes be useful, + allowing you to combine several null checks into one.
      + +
      dyn_cast_or_null<>:
      + +
      The dyn_cast_or_null<> operator works just like the + dyn_cast<> operator, except that it allows for a null pointer + as an argument (which it then propagates). This can sometimes be useful, + allowing you to combine several null checks into one.
      + +
      + +

      These five templates can be used with any classes, whether they have a + v-table or not. To add support for these templates, you simply need to add + classof static methods to the class you are interested casting + to. Describing this is currently outside the scope of this document, but there + are lots of examples in the LLVM source base.

      + +
      + + +
      + The DEBUG() macro & -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 + it... but you may need it again in the future (to work out new bugs that you run + across).

      + +

      Naturally, because of this, you don't want to delete the debug printouts, + but you don't want them to always be noisy. A standard compromise is to comment + them out, allowing you to enable them if you need them in the future.

      + +

      The "Support/Debug.h" + file provides a macro named DEBUG() that is a much nicer solution to + this problem. Basically, you can put arbitrary code into the argument of the + DEBUG macro, and it is only executed if 'opt' (or any other + tool) is run with the '-debug' command line argument:

      + + 
           ... 
           DEBUG(std::cerr << "I am here!\n");
           ...
      + +

      Then you can run your pass like this:

      + + 
        $ opt < a.bc > /dev/null -mypass
          <no output>
        $ opt < a.bc > /dev/null -mypass -debug
          I am here!
        $
      + +

      Using the DEBUG() macro instead of a home-brewed solution allows you + to not have to create "yet another" command line option for the debug output for + your pass. Note that DEBUG() macros are disabled for optimized builds, + so they do not cause a performance impact at all (for the same reason, they + should also not contain side-effects!).

      + +

      One additional nice thing about the DEBUG() macro is that you can + enable or disable it directly in gdb. Just use "set DebugFlag=0" or + "set DebugFlag=1" from the gdb if the program is running. If the + 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 + generator). If you want to enable debug information with more fine-grained + control, you define the DEBUG_TYPE macro and the -debug only + option as follows:

      + + 
           ...
           DEBUG(std::cerr << "No debug type\n");
           #undef  DEBUG_TYPE
           #define DEBUG_TYPE "foo"
           DEBUG(std::cerr << "'foo' debug type\n");
           #undef  DEBUG_TYPE
           #define DEBUG_TYPE "bar"
           DEBUG(std::cerr << "'bar' debug type\n");
           #undef  DEBUG_TYPE
           #define DEBUG_TYPE ""
           DEBUG(std::cerr << "No debug type (2)\n");
           ...
      + +

      Then you can run your pass like this:

      + + 
        $ opt < a.bc > /dev/null -mypass
          <no output>
        $ opt < a.bc > /dev/null -mypass -debug
          No debug type
          'foo' debug type
          'bar' debug type
          No debug type (2)
        $ opt < a.bc > /dev/null -mypass -debug-only=foo
          'foo' debug type
        $ opt < a.bc > /dev/null -mypass -debug-only=bar
          'bar' debug type
        $
      + +

      Of course, in practice, you should only set DEBUG_TYPE at the top of + a file, to specify the debug type for the entire module (if you do this before + you #include "Support/Debug.h", you don't have to insert the ugly + #undef's). Also, you should use names more meaningful than "foo" and + "bar", because there is no system in place to ensure that names do not + conflict. If two different modules use the same string, they will all be turned + on when the name is specified. This allows, for example, all debug information + for instruction scheduling to be enabled with -debug-type=InstrSched, + even if the source lives in multiple files.

      + +
      + + +
      + The Statistic template & -stats + option +
      + +
      + +

      The "Support/Statistic.h" file + provides a template named Statistic that is used as a unified way to + keep track of what the LLVM compiler is doing and how effective various + optimizations are. It is useful to see what optimizations are contributing to + making a particular program run faster.

      + +

      Often you may run your pass on some big program, and you're interested to see + how many times it makes a certain transformation. Although you can do this with + hand inspection, or some ad-hoc method, this is a real pain and not very useful + for big programs. Using the Statistic template makes it very easy to + keep track of this information, and the calculated information is presented in a + uniform manner with the rest of the passes being executed.

      + +

      There are many examples of Statistic uses, but the basics of using + it are as follows:

      + +
        +
      1. Define your statistic like this: + 
        static Statistic<> NumXForms("mypassname", "The # of times I did stuff");
        + +

        The Statistic template can emulate just about any data-type, + but if you do not specify a template argument, it defaults to acting like + an unsigned int counter (this is usually what you want).

        2. + +
      2. Whenever you make a transformation, bump the counter: + 
           ++NumXForms;   // I did stuff
        +
        3. +
      + +

      That's all you have to do. To get 'opt' to print out the + statistics gathered, use the '-stats' option:

      + + 
         $ opt -stats -mypassname < program.bc > /dev/null
          ... statistic output ...
      + +

      When running gccas on a C file from the SPEC benchmark + suite, it gives a report that looks like this:

      + + 
         7646 bytecodewriter  - Number of normal instructions
          725 bytecodewriter  - Number of oversized instructions
       129996 bytecodewriter  - Number of bytecode bytes written
         2817 raise           - Number of insts DCEd or constprop'd
         3213 raise           - Number of cast-of-self removed
         5046 raise           - Number of expression trees converted
           75 raise           - Number of other getelementptr's formed
          138 raise           - Number of load/store peepholes
           42 deadtypeelim    - Number of unused typenames removed from symtab
          392 funcresolve     - Number of varargs functions resolved
           27 globaldce       - Number of global variables removed
            2 adce            - Number of basic blocks removed
          134 cee             - Number of branches revectored
           49 cee             - Number of setcc instruction eliminated
          532 gcse            - Number of loads removed
         2919 gcse            - Number!
  of instructions removed
           86 indvars         - Number of canonical indvars added
           87 indvars         - Number of aux indvars removed
           25 instcombine     - Number of dead inst eliminate
          434 instcombine     - Number of insts combined
          248 licm            - Number of load insts hoisted
         1298 licm            - Number of insts hoisted to a loop pre-header
            3 licm            - Number of insts hoisted to multiple loop preds (bad, no loop pre-header)
           75 mem2reg         - Number of alloca's promoted
         1444 cfgsimplify     - Number of blocks simplified
      + +

      Obviously, with so many optimizations, having a unified framework for this + stuff is very nice. Making your pass fit well into the framework makes it more + maintainable and useful.

      + +
      + + +
      + 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 + practical side of LLVM transformations.

      Because this is a "how-to" section, + 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 + techniques used to traverse these various data structures are all basically the + same. For a enumerable sequence of values, the XXXbegin() function (or + method) returns an iterator to the start of the sequence, the XXXend() + function returns an iterator pointing to one past the last valid element of the + sequence, and there is some XXXiterator data type that is common + between the two operations.

      + +

      Because the pattern for iteration is common across many different aspects of + the program representation, the standard template library algorithms may be used + on them, and it is easier to remember how to iterate. First we show a few common + examples of the data structures that need to be traversed. Other data + structures are traversed in very similar ways.

      + +
      + + +
      + 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 + BasicBlocks. To facilitate this, you'll need to iterate over all of + the BasicBlocks that constitute the Function. The following is + an example that prints the name of a BasicBlock and the number of + Instructions it contains:

      + + 
        // func is a pointer to a Function instance
        for (Function::iterator i = func->begin(), e = func->end(); i != e; ++i) {

            // print out the name of the basic block if it has one, and then the
            // number of instructions that it contains

            cerr << "Basic block (name=" << i->getName() << ") has " 
                 << i->size() << " instructions.\n";
        }
      + +

      Note that i can be used as if it were a pointer for the purposes of + invoking member functions of the Instruction class. This is + because the indirection operator is overloaded for the iterator + classes. In the above code, the expression i->size() is + 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 + BasicBlocks. Here's a code snippet that prints out each instruction in + a BasicBlock:

      + + 
        // blk is a pointer to a BasicBlock instance
        for (BasicBlock::iterator i = blk->begin(), e = blk->end(); i != e; ++i)
           // the next statement works since operator<<(ostream&,...) 
           // is overloaded for Instruction&
           cerr << *i << "\n";
      + +

      However, this isn't really the best way to print out the contents of a + BasicBlock! Since the ostream operators are overloaded for virtually + anything you'll care about, you could have just invoked the print routine on the + basic block itself: cerr << *blk << "\n";.

      + +

      Note that currently operator<< is implemented for Value*, so + it will print out the contents of the pointer, instead of the pointer value you + might expect. This is a deprecated interface that will be removed in the + future, so it's best not to depend on it. To print out the pointer value for + now, you must cast to void*.

      + +
      + + +
      + 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, + InstIterator should be used instead. You'll need to include llvm/Support/InstIterator.h, + and then instantiate InstIterators explicitly in your code. Here's a + small example that shows how to dump all instructions in a function to stderr + (Note: Dereferencing an InstIterator yields an + Instruction*, not an Instruction&!):

      + + 
      #include "llvm/Support/InstIterator.h"
      ...
      // Suppose F is a ptr to a function
      for (inst_iterator i = inst_begin(F), e = inst_end(F); i != e; ++i)
        cerr << **i << "\n";
      + Easy, isn't it? You can also use InstIterators to fill a + worklist with its initial contents. For example, if you wanted to + initialize a worklist to contain all instructions in a Function + F, all you would need to do is something like: + 
      std::set<Instruction*> worklist;
      worklist.insert(inst_begin(F), inst_end(F));
      + +

      The STL set worklist would now contain all instructions in the + Function pointed to by F.

      + +
      + + +
      + 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 + a reference or a pointer from an iterator is very straightforward. + Assuming that i is a BasicBlock::iterator and j + is a BasicBlock::const_iterator:

      + + 
          Instruction& inst = *i;   // grab reference to instruction reference
          Instruction* pinst = &*i; // grab pointer to instruction reference
          const Instruction& inst = *j;
      + +

      However, the iterators you'll be working with in the LLVM framework are + special: they will automatically convert to a ptr-to-instance type whenever they + need to. Instead of dereferencing the iterator and then taking the address of + the result, you can simply assign the iterator to the proper pointer type and + you get the dereference and address-of operation as a result of the assignment + (behind the scenes, this is a result of overloading casting mechanisms). Thus + the last line of the last example,

      + + 
      Instruction* pinst = &*i;
      + +

      is semantically equivalent to

      + + 
      Instruction* pinst = i;
      + +

      It's also possible to turn a class pointer into the corresponding iterator. + Usually, this conversion is quite inexpensive. The following code snippet + illustrates use of the conversion constructors provided by LLVM iterators. By + using these, you can explicitly grab the iterator of something without actually + obtaining it via iteration over some structure:

      + + 
      void printNextInstruction(Instruction* inst) {
          BasicBlock::iterator it(inst);
          ++it; // after this line, it refers to the instruction after *inst.
          if (it != inst->getParent()->end()) cerr << *it << "\n";
      }
      + +

      Of course, this example is strictly pedagogical, because it'd be much + better to explicitly grab the next instruction directly from inst.

      + +
      + + +
      + 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 + certain function (i.e., some Function*) is already in scope. As you'll + learn later, you may want to use an InstVisitor to accomplish this in a + much more straightforward manner, but this example will allow us to explore how + you'd do it if you didn't have InstVisitor around. In pseudocode, this + is what we want to do:

      + + 
      initialize callCounter to zero
      for each Function f in the Module
          for each BasicBlock b in f
            for each Instruction i in b
              if (i is a CallInst and calls the given function)
                increment callCounter
      + +

      And the actual code is (remember, since we're writing a + FunctionPass, our FunctionPass-derived class simply has to + override the runOnFunction method...):

      + + 
      Function* targetFunc = ...;

      class OurFunctionPass : public FunctionPass {
        public:
          OurFunctionPass(): callCounter(0) { }

          virtual runOnFunction(Function& F) {
       	for (Function::iterator b = F.begin(), be = F.end(); b != be; ++b) {
       	    for (BasicBlock::iterator i = b->begin(); ie = b->end(); i != ie; ++i) {
       		if (CallInst* callInst = dyn_cast<CallInst>(&*i)) {
       		    // we know we've encountered a call instruction, so we
       		    // need to determine if it's a call to the
      	            // function pointed to by m_func or not.
        
       		    if (callInst->getCalledFunction() == targetFunc)
       			++callCounter;
       	    }
       	}
          }
          
        private:
          unsigned  callCounter;
      };
      + +
      + + +
      + 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 + this, and in other situations, you may find that you want to treat + CallInsts and InvokeInsts the same way, even though their + most-specific common base class is Instruction, which includes lots of + less closely-related things. For these cases, LLVM provides a handy wrapper + class called CallSite + . It is essentially a wrapper around an Instruction pointer, + with some methods that provide functionality common to CallInsts and + InvokeInsts.

      + +

      This class is supposed to have "value semantics". So it should be passed by + value, not by reference; it should not be dynamically allocated or deallocated + using operator new or operator delete. It is efficiently + copyable, assignable and constructable, with costs equivalents to that of a bare + pointer. (You will notice, if you look at its definition, that it has only a + single data member.)

      + +
      + + +
      + Iterating over def-use & use-def chains +
      + +
      + +

      Frequently, we might have an instance of the Value Class and we want to determine which + Users use the Value. The list of all Users of a + particular Value is called a def-use chain. For example, let's + say we have a Function* named F to a particular function + foo. Finding all of the instructions that use foo is as + simple as iterating over the def-use chain of F:

      + + 
      Function* F = ...;

      for (Value::use_iterator i = F->use_begin(), e = F->use_end(); i != e; ++i) {
          if (Instruction *Inst = dyn_cast<Instruction>(*i)) {
              cerr << "F is used in instruction:\n";
              cerr << *Inst << "\n";
          }
      }
      + +

      Alternately, it's common to have an instance of the User Class and need to know what + Values are used by it. The list of all Values used by a + User is known as a use-def chain. Instances of class + Instruction are common Users, so we might want to iterate over + all of the values that a particular instruction uses (that is, the operands of + the particular Instruction):

      + + 
      Instruction* pi = ...;

      for (User::op_iterator i = pi->op_begin(), e = pi->op_end(); i != e; ++i) {
          Value* v = *i;
          ...
      }
      + + + +
      + + +
      + Making simple changes +
      + +
      + +

      There are some primitive transformation operations present in the LLVM + infrastructure that are worth knowing about. When performing + transformations, it's fairly common to manipulate the contents of basic + blocks. This section describes some of the common methods for doing so + and gives example code.

      + +
      + + +
      + Creating and inserting new + Instructions +
      + +
      + +

      Instantiating Instructions

      + +

      Creation of Instructions is straightforward: simply call the + constructor for the kind of instruction to instantiate and provide the necessary + parameters. For example, an AllocaInst only requires a + (const-ptr-to) Type. Thus:

      + + 
      AllocaInst* ai = new AllocaInst(Type::IntTy);
      + +

      will create an AllocaInst instance that represents the allocation of + one integer in the current stack frame, at runtime. Each Instruction + subclass is likely to have varying default parameters which change the semantics + of the instruction, so refer to the doxygen documentation for the subclass of + Instruction that you're interested in instantiating.

      + +

      Naming values

      + +

      It is very useful to name the values of instructions when you're able to, as + this facilitates the debugging of your transformations. If you end up looking + at generated LLVM machine code, you definitely want to have logical names + associated with the results of instructions! By supplying a value for the + Name (default) parameter of the Instruction constructor, you + associate a logical name with the result of the instruction's execution at + runtime. For example, say that I'm writing a transformation that dynamically + allocates space for an integer on the stack, and that integer is going to be + used as some kind of index by some other code. To accomplish this, I place an + AllocaInst at the first point in the first BasicBlock of some + Function, and I'm intending to use it within the same + Function. I might do:

      + + 
      AllocaInst* pa = new AllocaInst(Type::IntTy, 0, "indexLoc");
      + +

      where indexLoc is now the logical name of the instruction's + execution value, which is a pointer to an integer on the runtime stack.

      + +

      Inserting instructions

      + +

      There are essentially two ways to insert an Instruction + into an existing sequence of instructions that form a BasicBlock:

      + +
        +
      • Insertion into an explicit instruction list + +

        Given a BasicBlock* pb, an Instruction* pi within that + BasicBlock, and a newly-created instruction we wish to insert + before *pi, we do the following:

        + + 
          BasicBlock *pb = ...;
          Instruction *pi = ...;
          Instruction *newInst = new Instruction(...);
          pb->getInstList().insert(pi, newInst); // inserts newInst before pi in pb
        • + +
      • Insertion into an implicit instruction list + +

        Instruction instances that are already in BasicBlocks + are implicitly associated with an existing instruction list: the instruction + list of the enclosing basic block. Thus, we could have accomplished the same + thing as the above code without being given a BasicBlock by doing: +

        + + 
          Instruction *pi = ...;
          Instruction *newInst = new Instruction(...);
          pi->getParent()->getInstList().insert(pi, newInst);
        + +

        In fact, this sequence of steps occurs so frequently that the + Instruction class and Instruction-derived classes provide + constructors which take (as a default parameter) a pointer to an + Instruction which the newly-created Instruction should + precede. That is, Instruction constructors are capable of + inserting the newly-created instance into the BasicBlock of a + provided instruction, immediately before that instruction. Using an + Instruction constructor with a insertBefore (default) + parameter, the above code becomes:

        + + 
        Instruction* pi = ...;
        Instruction* newInst = new Instruction(..., pi);
        + +

        which is much cleaner, especially if you're creating a lot of + instructions and adding them to BasicBlocks.

        • +
      + +
      + + +
      + Deleting Instructions +
      + +
      + +

      Deleting an instruction from an existing sequence of instructions that form a + BasicBlock is very straightforward. First, + you must have a pointer to the instruction that you wish to delete. Second, you + need to obtain the pointer to that instruction's basic block. You use the + pointer to the basic block to get its list of instructions and then use the + erase function to remove your instruction. For example:

      + + 
        Instruction *I = .. ;
        BasicBlock *BB = I->getParent();
        BB->getInstList().erase(I);
      + +
      + + +
      + Replacing an Instruction with another + Value +
      + +
      + +

      Replacing individual instructions

      + +

      Including "llvm/Transforms/Utils/BasicBlockUtils.h" + permits use of two very useful replace functions: ReplaceInstWithValue + and ReplaceInstWithInst.

      + +

      Deleting Instructions

      + +
        +
      • ReplaceInstWithValue + +

        This function replaces all uses (within a basic block) of a given + instruction with a value, and then removes the original instruction. The + following example illustrates the replacement of the result of a particular + AllocaInst that allocates memory for a single integer with an null + pointer to an integer.

        + + 
        AllocaInst* instToReplace = ...;
        BasicBlock::iterator ii(instToReplace);
        ReplaceInstWithValue(instToReplace->getParent()->getInstList(), ii,
                             Constant::getNullValue(PointerType::get(Type::IntTy)));
        • + +
      • ReplaceInstWithInst + +

        This function replaces a particular instruction with another + instruction. The following example illustrates the replacement of one + AllocaInst with another.

        + + 
        AllocaInst* instToReplace = ...;
        BasicBlock::iterator ii(instToReplace);
        ReplaceInstWithInst(instToReplace->getParent()->getInstList(), ii,
                            new AllocaInst(Type::IntTy, 0, "ptrToReplacedInt"));
        • +
      + +

      Replacing multiple uses of Users and Values

      + +

      You can use Value::replaceAllUsesWith and + User::replaceUsesOfWith to change more than one use at a time. See the + doxygen documentation for the Value Class + and User Class, respectively, for more + information.

      + + + +
      + + +
      + The Core LLVM Class Hierarchy Reference +
      + + +
      + +

      The Core LLVM classes are the primary means of representing the program + being inspected or transformed. The core LLVM classes are defined in + header files in the include/llvm/ directory, and implemented in + the lib/VMCore directory.

      + +
      + + +
      + The Value class +
      + +
      + +

      #include "llvm/Value.h" +
      + doxygen info: Value Class

      + +

      The Value class is the most important class in the LLVM Source + base. It represents a typed value that may be used (among other things) as an + operand to an instruction. There are many different types of Values, + such as Constants,Arguments. Even Instructions and Functions are Values.

      + +

      A particular Value may be used many times in the LLVM representation + for a program. For example, an incoming argument to a function (represented + with an instance of the Argument class) is "used" by + every instruction in the function that references the argument. To keep track + of this relationship, the Value class keeps a list of all of the Users that is using it (the User class is a base class for all nodes in the LLVM + graph that can refer to Values). This use list is how LLVM represents + def-use information in the program, and is accessible through the use_* + methods, shown below.

      + +

      Because LLVM is a typed representation, every LLVM Value is typed, + and this Type is available through the getType() + method. In addition, all LLVM values can be named. The "name" of the + Value is a symbolic string printed in the LLVM code:

      + + 
         %foo = add int 1, 2
      + +

      The name of this instruction is "foo". NOTE + that the name of any value may be missing (an empty string), so names should + ONLY be used for debugging (making the source code easier to read, + debugging printouts), they should not be used to keep track of values or map + between them. For this purpose, use a std::map of pointers to the + Value itself instead.

      + +

      One important aspect of LLVM is that there is no distinction between an SSA + variable and the operation that produces it. Because of this, any reference to + the value produced by an instruction (or the value available as an incoming + argument, for example) is represented as a direct pointer to the class that + represents this value. Although this may take some getting used to, it + simplifies the representation and makes it easier to manipulate.

      + +
      + + +
      + Important Public Members of the Value class +
      + +
      + +
        +
      • Value::use_iterator - Typedef for iterator over the + use-list
        + Value::use_const_iterator - Typedef for const_iterator over + the use-list
        + unsigned use_size() - Returns the number of users of the + value.
        + bool use_empty() - Returns true if there are no users.
        + use_iterator use_begin() - Get an iterator to the start of + the use-list.
        + use_iterator use_end() - Get an iterator to the end of the + use-list.
        + User *use_back() - Returns the last + element in the list. +

        These methods are the interface to access the def-use + information in LLVM. As with all other iterators in LLVM, the naming + conventions follow the conventions defined by the STL.

        +
        • +
      • Type *getType() const +

        This method returns the Type of the Value.

        +
        • +
      • bool hasName() const
        + std::string getName() const
        + void setName(const std::string &Name) +

        This family of methods is used to access and assign a name to a Value, + be aware of the precaution above.

        +
        • +
      • void replaceAllUsesWith(Value *V) + +

        This method traverses the use list of a Value changing all Users of the current value to refer to + "V" instead. For example, if you detect that an instruction always + produces a constant value (for example through constant folding), you can + replace all uses of the instruction with the constant like this:

        + + 
          Inst->replaceAllUsesWith(ConstVal);
        +
      + +
      + + +
      + The User class +
      + +
      + +

      + #include "llvm/User.h"
      + doxygen info: User Class
      + Superclass: Value

      + +

      The User class is the common base class of all LLVM nodes that may + refer to Values. It exposes a list of "Operands" + that are all of the Values that the User is + referring to. The User class itself is a subclass of + Value.

      + +

      The operands of a User point directly to the LLVM Value that it refers to. Because LLVM uses Static + Single Assignment (SSA) form, there can only be one definition referred to, + allowing this direct connection. This connection provides the use-def + information in LLVM.

      + +
      + + +
      + 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.

      + +
        +
      • Value *getOperand(unsigned i)
        + unsigned getNumOperands() +

        These two methods expose the operands of the User in a + convenient form for direct access.

        • + +
      • User::op_iterator - Typedef for iterator over the operand + list
        + User::op_const_iterator use_iterator op_begin() - + Get an iterator to the start of the operand list.
        + use_iterator op_end() - Get an iterator to the end of the + operand list. +

        Together, these methods make up the iterator based interface to + the operands of a User.

        • +
      + +
      + + +
      + The Instruction class +
      + +
      + +

      #include "llvm/Instruction.h"
      + doxygen info: Instruction Class
      + Superclasses: User, Value

      + +

      The Instruction class is the common base class for all LLVM + instructions. It provides only a few methods, but is a very commonly used + class. The primary data tracked by the Instruction class itself is the + opcode (instruction type) and the parent BasicBlock the Instruction is embedded + into. To represent a specific type of instruction, one of many subclasses of + Instruction are used.

      + +

      Because the Instruction class subclasses the User class, its operands can be accessed in the same + way as for other Users (with the + getOperand()/getNumOperands() and + op_begin()/op_end() methods).

      An important file for + the Instruction class is the llvm/Instruction.def file. This + file contains some meta-data about the various different types of instructions + in LLVM. It describes the enum values that are used as opcodes (for example + Instruction::Add and Instruction::SetLE), as well as the + concrete sub-classes of Instruction that implement the instruction (for + example BinaryOperator and SetCondInst). Unfortunately, the use of macros in + this file confuses doxygen, so these enum values don't show up correctly in the + doxygen output.

      + +
      + + +
      + Important Public Members of the Instruction + class +
      + +
      + +
        +
      • BasicBlock *getParent() +

        Returns the BasicBlock that + this Instruction is embedded into.

        • +
      • bool mayWriteToMemory() +

        Returns true if the instruction writes to memory, i.e. it is a + call,free,invoke, or store.

        • +
      • unsigned getOpcode() +

        Returns the opcode for the Instruction.

        • +
      • Instruction *clone() const +

        Returns another instance of the specified instruction, identical + in all ways to the original except that the instruction has no parent + (ie it's not embedded into a BasicBlock), + and it has no name

        • +
      + +
      + + +
      + The BasicBlock class +
      + +
      + +

      #include "llvm/BasicBlock.h"
      + doxygen info: BasicBlock Class
      + Superclass: Value

      + +

      This class represents a single entry multiple exit section of the code, + commonly known as a basic block by the compiler community. The + BasicBlock class maintains a list of Instructions, which form the body of the block. + Matching the language definition, the last element of this list of instructions + is always a terminator instruction (a subclass of the TerminatorInst class).

      + +

      In addition to tracking the list of instructions that make up the block, the + BasicBlock class also keeps track of the Function that it is embedded into.

      + +

      Note that BasicBlocks themselves are 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 +
      + +
      + +
        +
      • BasicBlock(const std::string &Name = "", Function *Parent = 0) +

        The BasicBlock constructor is used to create new basic + blocks for insertion into a function. The constructor optionally takes + a name for the new block, and a Function + to insert it into. If the Parent parameter is specified, the + new BasicBlock is automatically inserted at the end of the + specified Function, if not specified, + the BasicBlock must be manually inserted into the Function.

        +
        • +
      • BasicBlock::iterator - Typedef for instruction list + iterator
        + BasicBlock::const_iterator - Typedef for const_iterator.
        + begin(), end(), front(), back(),size(),empty(),rbegin(),rend() + - STL style functions for accessing the instruction list. +

        These methods and typedefs are forwarding functions that have + the same semantics as the standard library methods of the same names. + These methods expose the underlying instruction list of a basic block in + a way that is easy to manipulate. To get the full complement of + container operations (including operations to update the list), you must + use the getInstList() method.

        • +
      • BasicBlock::InstListType &getInstList() +

        This method is used to get access to the underlying container + that actually holds the Instructions. This method must be used when + there isn't a forwarding function in the BasicBlock class for + the operation that you would like to perform. Because there are no + forwarding functions for "updating" operations, you need to use this if + you want to update the contents of a BasicBlock.

        • +
      • Function *getParent() +

        Returns a pointer to Function + the block is embedded into, or a null pointer if it is homeless.

        • +
      • TerminatorInst *getTerminator() +

        Returns a pointer to the terminator instruction that appears at + the end of the BasicBlock. If there is no terminator + instruction, or if the last instruction in the block is not a + terminator, then a null pointer is returned.

        • +
      + +
      + + +
      + The GlobalValue class +
      + +
      + +

      #include "llvm/GlobalValue.h"
      + doxygen info: GlobalValue Class
      + Superclasses: User, Value

      + +

      Global values (GlobalVariables or Functions) are the only LLVM values that are + visible in the bodies of all Functions. + Because they are visible at global scope, they are also subject to linking with + other globals defined in different translation units. To control the linking + process, GlobalValues know their linkage rules. Specifically, + GlobalValues know whether they have internal or external linkage, as + defined by the LinkageTypes enumerator.

      + +

      If a GlobalValue has internal linkage (equivalent to being + static in C), it is not visible to code outside the current translation + unit, and does not participate in linking. If it has external linkage, it is + visible to external code, and does participate in linking. In addition to + linkage information, GlobalValues keep track of which Module they are currently part of.

      + +

      Because GlobalValues are memory objects, they are always referred to + by their address. As such, the Type of a + global is always a pointer to its contents. It is important to remember this + when using the GetElementPtrInst instruction because this pointer must + be dereferenced first. For example, if you have a GlobalVariable (a + subclass of GlobalValue) that is an array of 24 ints, type [24 x + int], then the GlobalVariable is a pointer to that array. Although + the address of the first element of this array and the value of the + GlobalVariable are the same, they have different types. The + GlobalVariable's type is [24 x int]. The first element's type + is int. Because of this, accessing a global value requires you to + 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 +
      + +
      + +
        +
      • bool hasInternalLinkage() const
        + bool hasExternalLinkage() const
        + void setInternalLinkage(bool HasInternalLinkage) +

        These methods manipulate the linkage characteristics of the GlobalValue.

        +

        +
        • +
      • Module *getParent() +

        This returns the Module that the + GlobalValue is currently embedded into.

        • +
      + +
      + + +
      + The Function class +
      + +
      + +

      #include "llvm/Function.h"
      doxygen + info: Function Class
      Superclasses: + GlobalValue, User, Value

      + +

      The Function class represents a single procedure in LLVM. It is + actually one of the more complex classes in the LLVM heirarchy because it must + keep track of a large amount of data. The Function class keeps track + of a list of BasicBlocks, a list of formal Arguments, and a SymbolTable.

      + +

      The list of BasicBlocks is the most + commonly used part of Function objects. The list imposes an implicit + ordering of the blocks in the function, which indicate how the code will be + layed out by the backend. Additionally, the first BasicBlock is the implicit entry node for the + Function. It is not legal in LLVM to explicitly branch to this initial + block. There are no implicit exit nodes, and in fact there may be multiple exit + nodes from a single Function. If the BasicBlock list is empty, this indicates that + the Function is actually a function declaration: the actual body of the + function hasn't been linked in yet.

      + +

      In addition to a list of BasicBlocks, the + Function class also keeps track of the list of formal Arguments that the function receives. This + container manages the lifetime of the Argument + nodes, just like the BasicBlock list does for + the BasicBlocks.

      + +

      The SymbolTable is a very rarely used + LLVM feature that is only used when you have to look up a value by name. Aside + from that, the SymbolTable is used + internally to make sure that there are not conflicts between the names of Instructions, BasicBlocks, or Arguments in the function body.

      + +
      + + +
      + Important Public Members of the Function + class +
      + +
      + +
        +
      • Function(const FunctionType + *Ty, bool isInternal, const std::string &N = "", Module* Parent = 0) + +

        Constructor used when you need to create new Functions to add + the the program. The constructor must specify the type of the function to + create and whether or not it should start out with internal or external + linkage. The FunctionType argument + specifies the formal arguments and return value for the function. The same + FunctionType value can be used to + create multiple functions. The Parent argument specifies the Module + in which the function is defined. If this argument is provided, the function + will automatically be inserted into that module's list of + functions.

        • + +
      • bool isExternal() + +

        Return whether or not the Function has a body defined. If the + function is "external", it does not have a body, and thus must be resolved + by linking with a function defined in a different translation unit.

        • + +
      • Function::iterator - Typedef for basic block list iterator
        + Function::const_iterator - Typedef for const_iterator.
        + + begin(), end(), front(), back(), + size(), empty(), rbegin(), rend() + +

        These are forwarding methods that make it easy to access the contents of + a Function object's BasicBlock + list.

        • + +
      • Function::BasicBlockListType &getBasicBlockList() + +

        Returns the list of BasicBlocks. This + is necessary to use when you need to update the list or perform a complex + action that doesn't have a forwarding method.

        • + +
      • Function::aiterator - Typedef for the argument list + iterator
        + Function::const_aiterator - Typedef for const_iterator.
        + + abegin(), aend(), afront(), aback(), + asize(), aempty(), arbegin(), arend() + +

        These are forwarding methods that make it easy to access the contents of + a Function object's Argument + list.

        • + +
      • Function::ArgumentListType &getArgumentList() + +

        Returns the list of Arguments. This is + necessary to use when you need to update the list or perform a complex + action that doesn't have a forwarding method.

        • + +
      • BasicBlock &getEntryBlock() + +

        Returns the entry BasicBlock for the + function. Because the entry block for the function is always the first + block, this returns the first block of the Function.

        • + +
      • Type *getReturnType()
        + FunctionType *getFunctionType() + +

        This traverses the Type of the + Function and returns the return type of the function, or the FunctionType of the actual + function.

        • + +
      • SymbolTable *getSymbolTable() + +

        Return a pointer to the SymbolTable + for this Function.

        • +
      + +
      + + +
      + The GlobalVariable class +
      + +
      + +

      #include "llvm/GlobalVariable.h" +
      + doxygen info: GlobalVariable + Class
      Superclasses: GlobalValue, User, Value

      + +

      Global variables are represented with the (suprise suprise) + GlobalVariable class. Like functions, GlobalVariables are also + subclasses of GlobalValue, and as such are + always referenced by their address (global values must live in memory, so their + "name" refers to their address). See GlobalValue for more on this. Global 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 +
      + +
      + +
        +
      • GlobalVariable(const Type *Ty, bool + isConstant, LinkageTypes& Linkage, Constant + *Initializer = 0, const std::string &Name = "", Module* Parent = 0) + +

        Create a new global variable of the specified type. If + isConstant is true then the global variable will be marked as + unchanging for the program. The Linkage parameter specifies the type of + linkage (internal, external, weak, linkonce, appending) for the variable. If + the linkage is InternalLinkage, WeakLinkage, or LinkOnceLinkage,  then + the resultant global variable will have internal linkage. AppendingLinkage + concatenates together all instances (in different translation units) of the + variable into a single variable but is only applicable to arrays.  See + the LLVM Language Reference for + further details on linkage types. Optionally an initializer, a name, and the + module to put the variable into may be specified for the global variable as + well.

        • + +
      • bool isConstant() const + +

        Returns true if this is a global variable that is known not to + be modified at runtime.

        • + +
      • bool hasInitializer() + +

        Returns true if this GlobalVariable has an intializer.

        • + +
      • Constant *getInitializer() + +

        Returns the intial value for a GlobalVariable. It is not legal + to call this method if there is no initializer.

        • +
      + +
      + + +
      + The Module class +
      + +
      + +

      #include "llvm/Module.h"
      doxygen info: + Module Class

      + +

      The Module class represents the top level structure present in LLVM + programs. An LLVM module is effectively either a translation unit of the + original program or a combination of several translation units merged by the + linker. The Module class keeps track of a list of Functions, a list of 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 = "")
        • +
      + +

      Constructing a Module is easy. You can optionally + provide a name for it (probably based on the name of the translation unit).

      + +
        +
      • Module::iterator - Typedef for function list iterator
        + Module::const_iterator - Typedef for const_iterator.
        + + begin(), end(), front(), back(), + size(), empty(), rbegin(), rend() + +

        These are forwarding methods that make it easy to access the contents of + a Module object's Function + list.

        • + +
      • Module::FunctionListType &getFunctionList() + +

        Returns the list of Functions. This is + necessary to use when you need to update the list or perform a complex + action that doesn't have a forwarding method.

        + +

        • +
      + +
      + +
        +
      • Module::giterator - Typedef for global variable list iterator
        + + Module::const_giterator - Typedef for const_iterator.
        + + gbegin(), gend(), gfront(), gback(), + gsize(), gempty(), grbegin(), grend() + +

        These are forwarding methods that make it easy to access the contents of + a Module object's GlobalVariable list.

        • + +
      • Module::GlobalListType &getGlobalList() + +

        Returns the list of GlobalVariables. This is necessary to + use when you need to update the list or perform a complex action that + doesn't have a forwarding method.

        + +

        • +
      + +
      + + + +
      + +
        +
      • Function *getFunction(const std::string + &Name, const FunctionType *Ty) + +

        Look up the specified function in the Module SymbolTable. If it does not exist, return + null.

        • + +
      • Function *getOrInsertFunction(const + std::string &Name, const FunctionType *T) + +

        Look up the specified function in the Module SymbolTable. If it does not exist, add an + external declaration for the function and return it.

        • + +
      • std::string getTypeName(const Type *Ty) + +

        If there is at least one entry in the SymbolTable for the specified Type, return it. Otherwise return the empty + string.

        • + +
      • bool addTypeName(const std::string &Name, const Type *Ty) + +

        Insert an entry in the SymbolTable + mapping Name to Ty. If there is already an entry for this + name, true is returned and the SymbolTable is not modified.

        • +
      + +
      + + +
      + The Constant class and subclasses +
      + +
      + +

      Constant represents a base class for different types of constants. It + is subclassed by ConstantBool, ConstantInt, ConstantSInt, ConstantUInt, + ConstantArray etc for representing the various types of Constants.

      + +
      + + +
      + Important Public Methods +
      + +
      + +
        +
      • bool isConstantExpr(): Returns true if it is a + ConstantExpr +
        Important Subclasses of Constant +

        +
          +
        • ConstantSInt : This subclass of Constant represents a signed + integer constant. +
            +
          • int64_t getValue() const: Returns the underlying value of + this constant.
            • +
          +
          • +
        • ConstantUInt : This class represents an unsigned integer. +
            +
          • uint64_t getValue() const: Returns the underlying value + of this constant.
            • +
          +
          • +
        • ConstantFP : This class represents a floating point constant. +
            +
          • double getValue() const: Returns the underlying value of + this constant.
            • +
          +
          • +
        • ConstantBool : This represents a boolean constant. +
            +
          • bool getValue() const: Returns the underlying value of + this constant.
            • +
          +
          • +
        • ConstantArray : This represents a constant array. +
            +
          • const std::vector<Use> &getValues() const: + Returns a Vecotr of component constants that makeup this array.
            • +
          +
          • +
        • ConstantStruct : This represents a constant struct. +
            +
          • const std::vector<Use> &getValues() const: + Returns a Vecotr of component constants that makeup this array.
            • +
          +
          • +
        • ConstantPointerRef : This represents a constant pointer value + that is initialized to point to a global value, which lies at a + constant fixed address. +
            +
          • GlobalValue *getValue(): Returns the global + value to which this pointer is pointing to.
            • +
          +
          • +
        +
        • +
      + +
      + + +
      + The Type class and Derived Types +
      + +
      + +

      Type as noted earlier is also a subclass of a Value class. Any primitive + type (like int, short etc) in LLVM is an instance of Type Class. All other + types are instances of subclasses of type like FunctionType, ArrayType + etc. DerivedType is the interface for all such dervied types including + FunctionType, ArrayType, PointerType, StructType. Types can have names. They can + be recursive (StructType). There exists exactly one instance of any type + structure at a time. This allows using pointer equality of Type *s for comparing + types.

      + +
      + + +
      + Important Public Methods +
      + +
      + +
        + +
      • PrimitiveID getPrimitiveID() const: Returns the base type of the + type.
        • + +
      • bool isSigned() const: Returns whether an integral numeric type + is signed. This is true for SByteTy, ShortTy, IntTy, LongTy. Note that this is + not true for Float and Double.
        • + +
      • bool isUnsigned() const: Returns whether a numeric type is + unsigned. This is not quite the complement of isSigned... nonnumeric types + return false as they do with isSigned. This returns true for UByteTy, + UShortTy, UIntTy, and ULongTy.
        • + +
      • bool isInteger() const: Equilivent to isSigned() || isUnsigned(), + but with only a single virtual function invocation.
        • + +
      • bool isIntegral() const: Returns true if this is an integral + type, which is either Bool type or one of the Integer types.
        • + +
      • bool isFloatingPoint(): Return true if this is one of the two + floating point types.
        • + +
      • bool isRecursive() const: Returns rue if the type graph contains + a cycle.
        • + +
      • isLosslesslyConvertableTo (const Type *Ty) const: Return true if + this type can be converted to 'Ty' without any reinterpretation of bits. For + example, uint to int.
        • + +
      • bool isPrimitiveType() const: Returns true if it is a primitive + type.
        • + +
      • bool isDerivedType() const: Returns true if it is a derived + type.
        • + +
      • const Type * getContainedType (unsigned i) const: This method is + used to implement the type iterator. For derived types, this returns the types + 'contained' in the derived type, returning 0 when 'i' becomes invalid. This + allows the user to iterate over the types in a struct, for example, really + easily.
        • + +
      • unsigned getNumContainedTypes() const: Return the number of types + in the derived type. + +
        +

        Derived Types

        + +
          +
        • SequentialType : This is subclassed by ArrayType and PointerType +
            +
          • const Type * getElementType() const: Returns the type of + each of the elements in the sequential type.
            • +
          +
          • +
        • ArrayType : This is a subclass of SequentialType and defines + interface for array types. +
            +
          • unsigned getNumElements() const: Returns the number of + elements in the array.
            • +
          +
          • +
        • PointerType : Subclass of SequentialType for pointer types.
          • +
        • StructType : subclass of DerivedTypes for struct types
          • +
        • FunctionType : subclass of DerivedTypes for function types. +
            +
          • bool isVarArg() const: Returns true if its a vararg + function
            • +
          • const Type * getReturnType() const: Returns the + return type of the function.
            • +
          • const Type * getParamType (unsigned i): Returns + the type of the ith parameter.
            • +
          • const unsigned getNumParams() const: Returns the + number of formal parameters.
            • +
          +
          • +
        +
        • +
      + +
      + + +
      + The Argument class +
      + +
      + +

      This subclass of Value defines the interface for incoming formal + arguments to a function. A Function maitanis a list of its formal + arguments. An argument has a pointer to the parent Function.

      + +
      + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + Dinakar Dhurjati and + Chris Lattner
      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/Projects.html diff -c /dev/null llvm-www/releases/1.2/docs/Projects.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/Projects.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,391 ---- + + + + Creating an LLVM Project + + + + +

      Creating an LLVM Project

      + + +

      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 + these facilities, a Makefile from a project must do the following things: + +
        +
      1. Set environment variables. +

        + There are several environment variables that a Makefile needs to set to + use the LLVM build system: +

        +
        LLVM_SRC_ROOT +
        + The root of the LLVM source tree. +

        + +

        LLVM_OBJ_ROOT +
        + The root of the LLVM object tree. +

        + +

        BUILD_SRC_ROOT +
        + The root of the project's source tree. +

        + +

        BUILD_OBJ_ROOT +
        + The root of the project's object tree. +

        + +

        BUILD_SRC_DIR +
        + The directory containing the current source to be compiled. +

        + +

        BUILD_OBJ_DIR +
        + The directory where the current source will place the new object + files. This should always be the current directory. +

        + +

        LEVEL +
        + The relative path from the current directory to the root of the + object tree. +

        +

        + +
      2. Include the LLVM Makefile.config from $(LLVM_OBJ_ROOT). +

        + +

      3. Include the LLVM Makefile.rules from $(LLVM_SRC_ROOT). +
      + + There are two ways that you can set all of these variables: +
        +
      1. + You can write your own Makefiles which hard-code these values. + +
      2. + You can use the pre-made LLVM sample project. This sample project + includes Makefiles, a configure script that can be used to configure + the location of LLVM, and the ability to support multiple object + directories from a single source directory. +
      + + This document assumes that you will base your project off of the LLVM + sample project found in llvm/projects/sample. If you want to + devise your own build system, studying the sample project and LLVM + Makefiles will probably provide enough information on how to write your own + Makefiles. +

      + + +

      Create a Project from the Sample Project

      + + + Follow these simple steps to start your project: + +
        +
      1. + Copy the llvm/projects/sample directory to any place + of your choosing. You can place it anywhere you like. Rename the + directory to match the name of your project. +

        + +

      2. + Add your source code and Makefiles to your source tree. +

        + +

      3. + If you want your Makefiles to be configured by the + configure script, or if you want to support multiple + object directories, add your Makefiles to the configure + script by adding them into the autoconf/configure.ac file. + The macro AC_CONFIG_MAKEFILE will copy a file, unmodified, + from the source directory to the object directory. + +

        + After updating autoconf/configure.ac, regenerate the + configure script with these commands: +

        + + cd autoconf
        + autoconf -o ../configure +         + +

        + + You must be using Autoconf version 2.57 or higher. +

        + +

      4. + Run configure in the directory in which you want to place + object code. Use the following options to tell your project where it + can find LLVM: + +
        +
        --with-llvmsrc=<directory> +
        + Tell your project where the LLVM source tree is located. +

        +

        --with-llvmobj=<directory> +
        + Tell your project where the LLVM object tree is located. +
        +
      + + That's it! Now all you have to do is type gmake in the root of + your object directory, and your 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. + Mainly, you want your source tree layout to look similar to the LLVM + source tree layout. The best way to do this is to just copy the + project tree from llvm/projects/sample and modify it to meet + your needs, but you can certainly add to it if you want. + + Underneath your top level directory, you should have the following + directories: + +
      +
      lib +
      + This subdirectory should contain all of your library source + code. For each library that you build, you will have one + directory in lib that will contain that library's source + code. + +

      + Libraries can be object files, archives, or dynamic libraries. + The lib directory is just a convenient place for libraries + as it places them all in a directory from which they can be linked + later. + +

      include +
      + This subdirectory should contain any header files that are + global to your project. By global, we mean that they are used + by more than one library or executable of your project. +

      + By placing your header files in include, they will be + found automatically by the LLVM build system. For example, if + you have a file include/jazz/note.h, then your source + files can include it simply with #include "jazz/note.h". + +

      tools +
      + This subdirectory should contain all of your source + code for executables. For each program that you build, you + will have one directory in tools that will contain that + program's source code. +

      + +

      test +
      + This subdirectory should contain tests that verify that your code + works correctly. Automated tests are especially useful. +

      + Currently, the LLVM build system provides little support for tests, + although some exists. Expanded support for tests will hopefully + occur in the future. In the meantime, the LLVM system does provide the + following: +

        +
      • + LLVM provides several QMTest test classes that can be used to + create tests. They can be found in + llvm/test/QMTest/llvm.py. These test classes perform a + variety of functions, including code optimization tests, assembly + tests, and code analysis tests. The Makefile in + llvm/test provides the QMTest context needed by LLVM test + classes. +

        + +

      • + The LLVM source tree provides benchmarks and programs which are + known to compile with the LLVM GCC front ends. You can use these + programs to test your code, gather statistics information, and + compare it to the current LLVM performance statistics. These + programs are found in the llvm/test/Programs directory. +

        + Currently, there is no way to hook your tests directly into the + llvm/test/Programs testing harness. You will simply + need to find a way to use the source provided within that directory + on your own. +

      +
      + + Typically, you will want to build your lib directory first + followed by 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 +
      + This variable is the relative path from this Makefile to the + top directory of your project's source code. For example, if + your source code is in /tmp/src, then the Makefile in + /tmp/src/jump/high would set LEVEL to "../..". +
      + +

      Variables for Building Subdirectories

      +
      +
      DIRS +
      + This is a space separated list of subdirectories that should be + built. They will be built, one at a time, in the order + specified. +

      + +

      PARALLEL_DIRS +
      + This is a list of directories that can be built in parallel. + These will be built after the directories in DIRS have been + built. +

      + +

      OPTIONAL_DIRS +
      + This is a list of directories that can be built if they exist, + but will not cause an error if they do not exist. They are + built serially in the order in which they are listed. +
      + +

      Variables for Building Libraries

      +
      +
      LIBRARYNAME +
      + This variable contains the base name of the library that will + be built. For example, to build a library named + libsample.a, LIBRARYNAME should be set to + sample. +

      + +

      BUILD_ARCHIVE +
      + By default, a library is a .o file that is linked + directly into a program. To build an archive (also known as + a static library), set the BUILD_ARCHIVE variable. +

      + +

      SHARED_LIBRARY +
      + If SHARED_LIBRARY is defined in your Makefile, a shared + (or dynamic) library will be built. +
      + +

      Variables for Building Programs

      +
      +
      TOOLNAME +
      + This variable contains the name of the program that will + be built. For example, to build an executable named + sample, TOOLNAME should be set to sample. +

      + +

      USEDLIBS +
      + This variable holds a space separated list of libraries that + should be linked into the program. These libraries must either + be LLVM libraries or libraries that come from your lib + directory. The libraries must be specified by their base name. + For example, to link libsample.a, you would set USEDLIBS to + sample. +

      + Note that this works only for statically linked libraries. +

      + +

      LIBS +
      + To link dynamic libraries, add -l<library base name> to + the LIBS variable. The LLVM build system will look in the same places + for dynamic libraries as it does for static libraries. +

      + For example, to link libsample.so, you would have the + following line in your Makefile: +

      + + LIBS+=-lsample + +

      + +

      Miscellaneous Variables

      +
      +
      ExtraSource +
      + This variable contains a space separated list of extra source + files that need to be built. It is useful for including the + output of Lex and Yacc programs. +

      + +

      CFLAGS +
      CPPFLAGS +
      + This variable can be used to add options to the C and C++ + compiler, respectively. It is typically used to add options + that tell the compiler the location of additional directories + to search for header files. +

      + It is highly suggested that you append to CFLAGS and CPPFLAGS as + opposed to overwriting them. The master Makefiles may already + have useful options in them that you may not want to overwrite. +

      +

      + + +

      Placement of Object Code

      + + + The final location of built libraries and executables will depend upon + whether you do a Debug, Release, or Profile build. + +
      +
      Libraries +
      + All libraries (static and dynamic) will be stored in + BUILD_OBJ_ROOT/lib/<type>, where type is Debug, + Release, or Profile for a debug, optimized, or + profiled build, respectively. +

      + +

      Executables +
      + All executables will be stored in BUILD_OBJ_ROOT/lib/<type>, + where type is Debug, Release, or Profile for + a debug, optimized, or profiled build, respectively. +
      + + +

      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 + questions to the LLVM Developers + Mailing List. + +
      +
      John Criswell

      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ + + + Index: llvm-www/releases/1.2/docs/RegisterAllocatorInfo.txt diff -c /dev/null llvm-www/releases/1.2/docs/RegisterAllocatorInfo.txt:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/RegisterAllocatorInfo.txt Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,197 ---- + =================== + Register Allocation + =================== + + + 1. Introduction + =============== + + Purpose: This file contains implementation information about register + allocation. + Author : Ruchira Sasanka + Date : Dec 8, 2001 + + + 2. Entry Point + ============== + class PhyRegAlloc (PhyRegAlloc.h) is the main class for the register + allocation. PhyRegAlloc::allocateRegisters() starts the register allocation + and contains the major steps for register allocation. + + 2. Usage + ======== + Register allocation must be done as: + + MethodLiveVarInfo LVI(*MethodI ); // compute LV info + LVI.analyze(); + + TargetMachine &target = .... // target description + + + PhyRegAlloc PRA(*MethodI, target, &LVI); // allocate regs + PRA.allocateRegisters(); + + + 4. Input and Preconditions + ========================== + Register allocation is done using machine instructions. The constructor + to the class takes a pointer to a method, a target machine description and + a live variable information for the method. + + The preconditions are: + + 1. Instruction selection is complete (i.e., machine instructions are + generated) for the method before the live variable analysis + + 2. Phi elimination is complete. + + + 5. Assumptions + ============== + + All variables (llvm Values) are defined before they are used. However, a + constant may not be defined in the machine instruction stream if it can be + used as an immediate value within a machine instruction. However, register + allocation does not have to worry about immediate constants since they + do not require registers. + + Since an llvm Value has a list of uses associated, it is sufficient to + record only the defs in a Live Range. + + + + + 6. Overall Design + ================= + There are sperate reigster classes - e.g., Int, Float, + IntConditionCode, FloatConditionCode register classes for Sparc. + + Registerallocation consists of the following main steps: + + 1. Construct Live-ranges & Suggest colors (machine specific) if required + 2. Create Interference graphs + 3. Coalescing live ranges + 4. Color all live ranges in each RegClass using graph coloring algo + 5. Insert additional (machine specific) code for calls/returns/incoming args + 6. Update instruction stream and insert spill code + + All the above methods are called from PhyRegAlloc::allocateRegisters(). + + All steps above except step 5 and suggesting colors in step 1 are indepenedent + of a particular target architecture. Targer independent code is availble in + ../lib/CodeGen/RegAlloc. Target specific code for Sparc is available in + ../lib/Target/Sparc. + + + 6.1. Construct Live-ranges & Suggest colors (machine specific) if required + -------------------------------------------------------------------------- + Live range construction is done using machine instructions. Since there must + be at least one definition for each variable in the machine instruction, we + consider only definitions in creating live ranges. After live range + construction is complete, there is a live range for all variables defined in + the instruction stream. Note however that, live ranges are not constructed for + constants which are not defined in the instruction stream. + + A LiveRange is a set of Values (only defs) in that live range. Live range + construction is done in combination for all register classes. All the live + ranges for a method are entered to a LiveRangeMap which can be accessed using + any Value in the LiveRange. + + After live ranges have been constructed, we call machine specific code to + suggest colors for speical live ranges. For instance, incoming args, call args, + return values must be placed in special registers for most architectures. By + suggesting colors for such special live ranges before we do the actual register + allocation using graph coloring, the graph coloring can try its best to assign + the required color for such special live ranges. This will reduce unnecessary + copy instructions needed to move values to special registers. However, there + is no guarantee that a live range will receive its suggested color. If the + live range does not receive the suggested color, we have to insert explicit + copy instructions to move the value into requred registers and its done in + step 5 above. + + See LiveRange.h, LiveRangeInfo.h (and LiveRange.cpp, LiveRangeInfo.cpp) for + algorithms and details. See SparcRegInfo.cpp for suggesting colors for + incoming/call arguments and return values. + + + 6.2. Create Interference graphs + ------------------------------- + Once live ranges are constructed, we can build interference graphs for each + register class. Though each register class must have a separate interference + graph, building all interference graphs is performed in one pass. Also, the + adjacency list for each live range is built in this phase. Consequently, each + register class has an interference graph (which is a bit matrix) and each + LiveRange has an adjacency list to record its neighbors. Live variable info + is used for finding the interferences. + + See IGNode.h, InterferenceGraph.h (and IGNode.h, InterferenceGraph.h) for + data structures and PhyRegAlloc::createIGNodeListsAndIGs() for the starting + point for interference graph construction. + + + 6.3. Coalescing live ranges + --------------------------- + We coalesce live ranges to reduce the number of live ranges. + + See LiveRangeInfo.h (and LiveRangeInfo.cpp). The entire algorithm for + coalesing is given in LiveRangeInfo::coalesceLRs(). + + + 6.4. Color all live ranges in each RegClass using graph coloring algo + --------------------------------------------------------------------- + Each register class is colored separately using the graph coloring algo. When + assigning colors, preference is given to live ranges with suggested colors + so that if such a live range receives a color (i.e., not spilled), then + we try to assign the color suggested for that live range. When this phase + is complete it is possible that some live ranges do not have colors (i.e., + those that must be spilled). + + + 6.5. Insert additional (machine specific) code for calls/returns/incoming args + ------------------------------------------------------------------------------ + This code is machine specific. Currently, the code for Sparc is implemented + in SparcRegInfo.cpp. This code is more complex because of the complex + requirements of assigning some values to special registers. When a special + value as an incoming argument receives a color through the graph coloring + alogorithm, we have to make sure that it received the correct color (for + instance the first incoming int argument must be colored to %i0 on Sparc). If + it didn't receive the correct color, we have to insert instruction to to move + the value to the required register. Also, this phase produces the caller + saving code. All adition code produced is kept separately until the last + phase (see 6.6) + + + 6.6. Update instruction stream and insert spill code + ----------------------------------------------------- + After we have assigned registers for all values and after we have produced + additional code to be inserted before some instructions, we update the + machine instruction stream. While we are updating the machine instruction + stream, if an instruction referes to a spilled value, we insert spill + instructions before/after that instruction. Also, we prepend/append additonal + instructions that have been produced for that instruction by the register + allocation (e.g., caller saving code) + + + 7. Furture work + =============== + If it is necessary to port the register allocator to another architecture + than Sparc, only the target specific code in ../lib/Target/Sparc needs to + be rewritten. Methods defined in class MachineRegInfo must be provided for + the new architecure. + + 7.1 Using ReservedColorList in RegClass + ---------------------------------------- + The register allocator allows reserving a set of registers - i.e. the reserved + registers are not used by the register allocator. Currently, there are no + reserved registers. It it is necessary to make some registers unavailable to + a particular method, this feature will become handy. To do that, the reserved + register list must be passed to the register allocator. See PhyRegAlloc.cpp + + + 7.2 %g registers on Sparc + ------------------------- + Currently, %g registers are not allocated on Sparc. If it is necessary to + allocate these %g registers, the enumeration of registers in SparcIntRegClass + in SparcRegClassInfo.h must be changed. %g registers can be easily added as + volatile registers just by moving them above in the eneumeration - see + SparcRegClassInfo.h Index: llvm-www/releases/1.2/docs/ReleaseNotes.html diff -c /dev/null llvm-www/releases/1.2/docs/ReleaseNotes.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/ReleaseNotes.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,671 ---- + + + + + LLVM 1.2 Release Notes + + + +
      + LLVM 1.2 Release Notes +
      + +
        +
      1. Introduction
        2. +
      2. What's New?
        3. +
      3. Portability and Supported Platforms
        4. +
      4. Installation Instructions
        5. +
      5. Known Problems +
        6. +
      6. Additional Information
        7. +
      + +
      +

      Written by the LLVM team

      +

      + + +
      + Introduction +
      + + +
      + +

      This document contains the release notes for the LLVM compiler + infrastructure, release 1.2. Here we describe the status of LLVM, including any + known problems and bug fixes from the previous release. The most up-to-date + version of this document can be found on the LLVM 1.2 web site. If you are + not reading this on the LLVM web pages, you should probably go there because + this document may be updated after the release.

      + +

      For more information about LLVM, including information about potentially more + current releases, please check out the main + web site. If you have questions or comments, the LLVM developer's mailing + list is a good place to send them.

      + +

      Note that if you are reading this file from CVS, this document applies + to the next release, not the current one. To see the release notes for + the current or previous releases, see the releases page.

      + +
      + + +
      + What's New? +
      + + +
      + +

      + This is the third public release of the LLVM compiler infrastructure. This + release incorporates several new features (including + exception handling support for the native code generators, the start of a + source-level debugger, and profile guided optimizer components), many speedups and code quality + improvements, documentation improvements, and a small collection of important bug fixes. Overall, this is our highest quality release to + date, and we encourage you to upgrade if you are using LLVM 1.0 or 1.1. +

      + +

      + At this time, LLVM is known to correctly compile and run all C & C++ SPEC + CPU2000 benchmarks, the Olden benchmarks, and the Ptrdist benchmarks. It has + also been used to compile many other programs. LLVM now also works with + a broad variety of C++ programs, though it has still received less testing than + the C front-end. +

      + + +
      + This release implements the following new features: +
      + +
        +
      1. A new LLVM source-level debugger has been started.
        2. +
      2. LLVM 1.2 encodes bytecode files for large programs in 10-30% less space.
        3. +
      3. LLVM can now feed profile information back into optimizers for Profile Guided Optimization, includes a simple basic block reordering pass, and supports edge profiling as well as function and block-level profiling.
        4. +
      4. The LLVM JIT lazily initializes global variables, reducing startup time for programs with lots of globals (like C++ programs).
        5. + +
      5. The build and installation infrastructure in this release is dramatically + improved. There is now an autoconf/AutoRegen.sh script + that you can run to rebuild the configure script and its associated + files as well as beta support for "make install" and RPM package generation.
        6. + +
      6. The "tblgen" tool is now documented.
        7. +
      7. The target-independent code generator got several improvements: +
          +
        • It can now fold spill code into instructions (on targets that support it).
          • +
        • A generic machine code spiller/rewriter was added. It provides an API for + global register allocators to eliminate virtual registers and add the + appropriate spill code.
          • +
        • The represenation of machine code basic blocks is more efficient and has + an easier to use interface.
          • +
        +
        8. +
      8. LLVM now no longer depends on the boost library.
        9. +
      9. The X86 backend now generates substantially better native code, and is faster.
        10. +
      10. The C backend has been turned moved from the "llvm-dis" tool to the "llc" + tool. You can activate it with "llc -march=c foo.bc -o foo.c".
        11. +
      11. LLVM includes a new interprocedural optimization that marks global variables + "constant" when they are provably never written to.
        12. +
      12. LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which is often improve the performance of C++ programs substantially.
        13. +
      13. Bugpoint can now do a better job reducing miscompilation problems by + reducing programs down to a particular loop nest, instead of just the function + being miscompiled.
        14. +
      14. The GCSE and LICM passes can now operate on side-effect-free function calls, for example hoisting calls to "strlen" and folding "cos" common subexpressions.
        15. +
      15. LLVM has early support for a new select instruction, though it is + currently only supported by the C backend.
        16. +
      + + + +
      + In this release, the following missing features were implemented: +
      + +
        +
      1. Exception handling in the X86 + & Sparc native code generators is now supported
        2. +
      2. The C/C++ front-end now support the GCC __builtin_return_address and __builtin_frame_address extensions. These are also supported by the X86 backend and by the C backend.
        3. +
      3. [X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808
        4. +
      4. The C/C++ front-end now supports + the "labels as values" GCC extension, often used to build "threaded interpreters".
        5. + +
      + + + +
      + In this release, the following Quality of Implementation issues were fixed: +
      + +
        + +
      1. JIT should lazily initialize global variables
        2. +
      2. [X86] X86 Backend never releases memory for machine code structures
        3. +
      3. [vmcore] OpaqueType objects memory leak
        4. +
      4. [llvmgcc] C front-end does not compile "extern inline" into linkonce
        5. +
      5. Bytecode format inconsistent
        6. +
      6. [loadvn/inline/scalarrepl] Slow optimizations with extremely large basic blocks
        7. +
      7. [asmparser] Really slow parsing of types with complex upreferences
        8. +
      8. [llvmgcc] C front-end does not emit 'zeroinitializer' when possible
        9. +
      9. [llvmgcc] Structure copies result in a LOT of code
        10. +
      10. LLVM is now much more memory efficient when handling large zero initialized arrays
        11. +
      11. [llvmgcc] Local array initializers are expanded into large amounts of code
        12. +
      + + +
      + In this release, the following build problems were fixed: +
      + +
        +
      1. [build] Makefiles break if C frontend target string has unexpected value
        2. +
      2. [build] hard-wired assumption that shared-library extension is ".so"
        3. +
      3. make tools-only doesn't make lib/Support
        4. +
      + + +
      + In this release, the following Code Quality issues were fixed: +
      + +
        +
      1. [loopsimplify] Many pointless phi nodes are created
        2. +
      2. [x86] wierd stack/frame pointer manipulation
        3. + +
      3. The X86 backend now generate fchs to negate floating point numbers, + compiles memcpy() into the rep movs instruction, and makes much better + use of powerful addressing modes and instructions.
        4. +
      + + + +
      + In this release, the following bugs in the previous release were fixed: +
      + +

      Bugs in the LLVM Core:

      + +
        +
      1. [licm] LICM promotes volatile memory + locations to registers
        2. +
      2. [licm] Memory read after free causes + infrequent crash
        3. +
      3. [indvars] Induction variable + canonicalization always makes 32-bit indvars
        4. +
      4. [constantmerge] Merging globals can + cause use of invalid pointers!
        5. +
      5. [bcreader] Bytecode reader misreads 'long -9223372036854775808'!
        6. +
      6. Tail duplication does not update SSA form correctly.
        7. +
      7. VMCore mishandles double -0.0
        8. +
      8. [X86] X86 backend code generates -0.0 as +0.0
        9. +
      9. [loopsimplify] Loopsimplify incorrectly updates dominator information
        10. +
      10. [pruneeh] -pruneeh pass removes invoke instructions it shouldn't
        11. +
      11. [sparc] Boolean constants are emitted as true and false
        12. +
      12. [interpreter] va_list values silently corrupted by function calls
        13. +
      13. Tablegen aborts on errors
        14. +
      14. [inliner] Error inlining intrinsic calls into invoke instructions
        15. +
      15. Linking weak and strong global variables is dependent on link order
        16. +
      16. Variables used to define non-printable FP constants are externally visible
        17. +
      17. CBE gives linkonce functions wrong linkage semantics
        18. +
      18. [JIT] Programs cannot resolve the fstat function
        19. +
      19. [indvars] Induction variable analysis violates LLVM invariants
        20. +
      20. [execution engines] Unhandled cast constant expression
        21. + +
      + + + +

      Bugs in the C/C++ front-end:

      + +
        +
      1. Need weak linkage on memory + management functions in libc runtime to allow them to be overriden
        2. +
      2. [llvm-gcc] asserts when an extern inline function is redefined
        3. +
      3. [llvmg++] Dynamically initialized constants cannot be marked 'constant'
        4. +
      4. [llvmgcc] floating-point unary minus is incorrect for +0.0
        5. +
      5. [llvm-gcc] miscompilation of 'X = Y = Z' with aggregate values
        6. +
      6. [llvmgcc] Invalid code created for complex division operation
        7. +
      7. [llvmgcc] Incorrect code generation for pointer subtraction
        8. +
      8. [llvmg++] Crash assigning pointers-to-members with casted types
        9. +
      9. [llvm-g++] Cleanups and gotos don't mix properly
        10. +
      10. [llvmgcc] Crash on auto register variable with specific register specified
        11. +
      + +
      + + +
      + Portability and Supported Platforms +
      + + +
      + +

      LLVM has been extensively tested on Intel and AMD machines running Red + Hat Linux and FreeBSD. It has also been tested on Sun UltraSPARC workstations running Solaris 8. + Additionally, + LLVM works on Mac OS X 10.3 and above, but only with the C backend or + interpreter (no native backend for the PowerPC is available yet). + The core LLVM infrastructure uses "autoconf" for portability, so hopefully we + work on more platforms than that. However, it is likely that we + missed something and that minor porting is required to get LLVM to work on + new platforms. We welcome portability patches and error messages.

      + +
      + + +
      + Known Problems +
      + + +
      + +

      This section contains all known problems with the LLVM system, listed by + component. As new problems are discovered, they will be added to these + sections. 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 not + be relied on, and bugs should not be filed against them, but they may be useful + to some people. In particular, if you would like to work on one of these + components, please contact us on the llvmdev list. +

      + +
        +
      • The following passes are incomplete or buggy: -pgmdep, -memdep, + -ipmodref, -sortstructs, -swapstructs, -cee
        • + +
      • The -pre pass is incomplete (there are cases it doesn't handle that + it should) and not thoroughly tested.
        • +
      • The llvm-ar tool is incomplete and probably buggy.
        • +
      • The llvm-db tool is in a very early stage of development.
        • +
      + +
      + + +
      + Known problems with the LLVM Core +
      + +
      + + +
      + + +
      + Known problems with the C front-end +
      + + +
      Bugs
      + +
      + +
      + + +
      + Notes +
      + +
      + +
        + +
      • Inline assembly is not yet supported.
        • + +
      • "long double" is transformed by the front-end into "double". There is no + support for floating point data types of any size other than 32 and 64 + bits.
        • + +
      • The following Unix system functionality has not been tested and may not + work: +
          +
        1. sigsetjmp, siglongjmp - These are not turned into the + appropriate invoke/unwind instructions. Note that + setjmp and longjmp are compiled correctly. +
        2. getcontext, setcontext, makecontext + - These functions have not been tested. +
        • + +
      • Although many GCC extensions are supported, some are not. In particular, + the following extensions are known to not be supported: +
          +
        1. Local Labels: Labels local to a block.
          2. +
        2. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
          3. +
        3. Constructing Calls: Dispatching a call to another function.
          4. +
        4. Extended Asm: Assembler instructions with C expressions as operands.
          5. +
        5. Constraints: Constraints for asm operands.
          6. +
        6. Asm Labels: Specifying the assembler name to use for a C symbol.
          7. +
        7. Explicit Reg Vars: Defining variables residing in specified registers.
          8. +
        8. Vector Extensions: Using vector instructions through built-in functions.
          9. +
        9. Target Builtins: Built-in functions specific to particular targets.
          10. +
        10. Thread-Local: Per-thread variables.
          11. +
        11. Pragmas: Pragmas accepted by GCC.
          12. +
        + +

        The following GCC extensions are partially supported. An ignored + attribute means that the LLVM compiler ignores the presence of the attribute, + but the code should still work. An unsupported attribute is one which is + ignored by the LLVM compiler and will cause a different interpretation of + the program.

        + +
          +
        1. Variable Length: + Arrays whose length is computed at run time.
          + Supported, but allocated stack space is not freed until the function returns (noted above).
          2. + +
        2. Function Attributes: + + Declaring that functions have no side effects or that they can never + return.
          + + Supported: format, format_arg, non_null, + constructor, destructor, unused, + deprecated, warn_unused_result, weak
          + + Ignored: noreturn, noinline, + always_inline, pure, const, nothrow, + malloc, no_instrument_function, cdecl
          + + Unsupported: used, section, alias, + visibility, regparm, stdcall, + fastcall, all other target specific attributes
          3. + +
        3. Variable Attributes: + Specifying attributes of variables.
          + Supported: cleanup, common, nocommon, + deprecated, transparent_union, + unused, weak
          + + Unsupported: aligned, mode, packed, + section, shared, tls_model, + vector_size, dllimport, + dllexport, all target specific attributes.
          4. + +
        4. Type Attributes: Specifying attributes of types.
          + Supported: transparent_union, unused, + deprecated, may_alias
          + + Unsupported: aligned, packed, + all target specific attributes.
          5. + +
        5. Other Builtins: + Other built-in functions.
          + We support all builtins which have a C language equivalent (e.g., + __builtin_cos), __builtin_alloca, + __builtin_types_compatible_p, __builtin_choose_expr, + __builtin_constant_p, and __builtin_expect (ignored).
          6. + +
        + +

        The following extensions are known to be supported:

        + +
          +
        1. Labels as Values: Getting pointers to labels and computed gotos.
          2. +
        2. Statement Exprs: Putting statements and declarations inside expressions.
          3. +
        3. Typeof: typeof: referring to the type of an expression.
          4. +
        4. Lvalues: Using ?:, "," and casts in lvalues.
          5. +
        5. Conditionals: Omitting the middle operand of a ?: expression.
          6. +
        6. Long Long: Double-word integers.
          7. +
        7. Complex: Data types for complex numbers.
          8. +
        8. Hex Floats:Hexadecimal floating-point constants.
          9. +
        9. Zero Length: Zero-length arrays.
          10. +
        10. Empty Structures: Structures with no members.
          11. +
        11. Variadic Macros: Macros with a variable number of arguments.
          12. +
        12. Escaped Newlines: Slightly looser rules for escaped newlines.
          13. +
        13. Subscripting: Any array can be subscripted, even if not an lvalue.
          14. +
        14. Pointer Arith: Arithmetic on void-pointers and function pointers.
          15. +
        15. Initializers: Non-constant initializers.
          16. +
        16. Compound Literals: Compound literals give structures, unions, + or arrays as values.
          17. +
        17. Designated Inits: Labeling elements of initializers.
          18. +
        18. Cast to Union: Casting to union type from any member of the union.
          19. +
        19. Case Ranges: `case 1 ... 9' and such.
          20. +
        20. Mixed Declarations: Mixing declarations and code.
          21. +
        21. Function Prototypes: Prototype declarations and old-style definitions.
          22. +
        22. C++ Comments: C++ comments are recognized.
          23. +
        23. Dollar Signs: Dollar sign is allowed in identifiers.
          24. +
        24. Character Escapes: \e stands for the character <ESC>.
          25. +
        25. Alignment: Inquiring about the alignment of a type or variable.
          26. +
        26. Inline: Defining inline functions (as fast as macros).
          27. +
        27. Alternate Keywords:__const__, __asm__, etc., for header files.
          28. +
        28. Incomplete Enums: enum foo;, with details to follow.
          29. +
        29. Function Names: Printable strings which are the name of the current function.
          30. +
        30. Return Address: Getting the return or frame address of a function.
          31. +
        31. Unnamed Fields: Unnamed struct/union fields within structs/unions.
          32. +
        32. Attribute Syntax: Formal syntax for attributes.
          33. +
        • + +
      + +

      If you run into GCC extensions which have not been included in any of these + lists, please let us know (also including whether or not they work).

      + +
      + + +
      + Known problems with the C++ front-end +
      + +
      + +

      For this release, the C++ front-end is considered to be fully functional but + has not been tested as thoroughly as the C front-end. It has been tested and + works for a number of non-trivial programs, but there may be lurking bugs. + Please report any bugs or problems.

      + +
      + + +
      Bugs
      + +
      + +
        +
      • The C++ front-end inherits all problems afflicting the C + front-end.
        • +
      +
      + + +
      + Notes +
      + +
      + +
        + +
      • The C++ front-end is based on a pre-release of the GCC 3.4 C++ parser. This + parser is significantly more standards compliant (and picky) than prior GCC + versions. For more information, see the C++ section of the GCC 3.4 release notes.
        • + +
      • Destructors for local objects are not always run when a longjmp is + performed. In particular, destructors for objects in the longjmping + function and in the setjmp receiver function may not be run. + Objects in intervening stack frames will be destroyed, however (which is + better than most compilers).
        • + +
      • The LLVM C++ front-end follows the Itanium C++ ABI. + This document, which is not Itanium specific, specifies a standard for name + mangling, class layout, v-table layout, RTTI formats, and other C++ + representation issues. Because we use this API, code generated by the LLVM + compilers should be binary compatible with machine code generated by other + Itanium ABI C++ compilers (such as G++, the Intel and HP compilers, etc). + However, the exception handling mechanism used by LLVM is very + different from the model used in the Itanium ABI, so exceptions will not + interact correctly.
        • + +
      + +
      + + +
      + Known problems with the X86 back-end +
      + +
      + +
        +
      • None so far. +
      + +
      + + +
      + Known problems with the Sparc back-end +
      + +
      + +
        +
      • None so far. +
      + +
      + + +
      + Known problems with the C back-end +
      + +
      + +
        + +
      • The C back-end produces code that violates the ANSI C Type-Based Alias + Analysis rules. As such, special options may be necessary to compile the code + (for example, GCC requires the -fno-strict-aliasing option). This + problem probably cannot be fixed.
        • + +
      • Initializers for global variables + cannot include special floating point numbers like Not-A-Number or + Infinity.
        • + +
      • Zero arg vararg functions are not + supported. This should not affect LLVM produced by the C or C++ + frontends.
        • + +
      + +
      + + +
      + Additional Information +
      + + +
      + +

      A wide variety of additional information is available on the LLVM web page, + including mailing lists and publications describing algorithms and components + implemented in LLVM. The web page also contains versions of the API + documentation which is up-to-date with the CVS version of the source code. You + can access versions of these documents specific to this release by going into + the "llvm/doc/" directory in the LLVM tree.

      + +

      If you have any questions or comments about LLVM, please feel free to contact + us via the mailing + lists.

      + +
      + + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/SourceLevelDebugging.html diff -c /dev/null llvm-www/releases/1.2/docs/SourceLevelDebugging.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/SourceLevelDebugging.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,1169 ---- + + + + Source Level Debugging with LLVM + + + + +
      Source Level Debugging with LLVM
      + + + + +
      Introduction
      + + +
      + +

      This document is the central repository for all information pertaining to + debug information in LLVM. It describes the user + interface for the llvm-db + tool, which provides a powerful source-level debugger + to users of LLVM-based compilers. It then describes the various components that make up the debugger and the + libraries which future clients may use. Finally, it describes the actual format that the LLVM debug information takes, + which is useful for those interested in creating front-ends or dealing directly + with the information.

      + +
      + + +
      + 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. + Several design aspects have shaped the solution that appears here. The + important ones are:

      + +

        +
      • Debugging information should have very little impact on the rest of the + compiler. No transformations, analyses, or code generators should need to be + modified because of debugging information.
        • + +
      • LLVM optimizations should interact in well-defined and + easily described ways with the debugging information.
        • + +
      • Because LLVM is designed to support arbitrary programming languages, + LLVM-to-LLVM tools should not need to know anything about the semantics of the + source-level-language.
        • + +
      • Source-level languages are often widely different from one another. + LLVM should not put any restrictions of the flavor of the source-language, and + the debugging information should work with any language.
        • + +
      • With code generator support, it should be possible to use an LLVM compiler + to compile a program to native machine code and standard debugging formats. + This allows compatibility with traditional machine-code level debuggers, like + GDB or DBX.
        • + +

      + +

      + The approach used by the LLVM implementation is to use a small set of intrinsic functions to define a mapping + between LLVM program objects and the source-level objects. The description of + the source-level program is maintained in LLVM global variables in an implementation-defined format (the C/C++ front-end + currently uses working draft 7 of the Dwarf 3 standard).

      + +

      + When a program is debugged, the debugger interacts with the user and turns the + stored debug information into source-language specific information. As such, + the debugger must be aware of the source-language, and is thus tied to a + specific language of family of languages. The LLVM + debugger is designed to be modular in its support for source-languages. +

      + +
      + + + +
      + 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 information + provides the following guarantees:

      + +

        + +
      • LLVM debug information always provides information to accurately read the + source-level state of the program, regardless of which LLVM optimizations + have been run, and without any modification to the optimizations themselves. + However, some optimizations may impact the ability to modify the current state + of the program with a debugger, such as setting program variables, or calling + function that have been deleted.
        • + +
      • LLVM optimizations gracefully interact with debugging information. If they + are not aware of debug information, they are automatically disabled as necessary + in the cases that would invalidate the debug info. This retains the LLVM + features making it easy to write new transformations.
        • + +
      • As desired, LLVM optimizations can be upgraded to be aware of the LLVM + debugging information, allowing them to update the debugging information as they + perform aggressive optimizations. This means that, with effort, the LLVM + optimizers could optimize debug code just as well as non-debug code.
        • + +
      • LLVM debug information does not prevent many important optimizations from + happening (for example inlining, basic block reordering/merging/cleanup, tail + duplication, etc), further reducing the amount of the compiler that eventually + is "aware" of debugging information.
        • + +
      • LLVM debug information is automatically optimized along with the rest of the + program, using existing facilities. For example, duplicate information is + automatically merged by the linker, and unused information is automatically + removed.
        • + +

      + +

      + Basically, the debug information allows you to compile a program with "-O0 + -g" and get full debug information, allowing you to arbitrarily modify the + program as it executes from the debugger. Compiling a program with "-O3 + -g" gives you full debug information that is always available and accurate + for reading (e.g., you get accurate stack traces despite tail call elimination + and inlining), but you might lose the ability to modify the program and call + functions where were optimized out of the program, or inlined away completely. +

      + +
      + + + +
      + Future work +
      + +
      +

      + There are several important extensions that could be eventually added to the + LLVM debugger. The most important extension would be to upgrade the LLVM code + generators to support debugging information. This would also allow, for + example, the X86 code generator to emit native objects that contain debugging + information consumable by traditional source-level debuggers like GDB or + DBX.

      + +

      + Additionally, LLVM optimizations can be upgraded to incrementally update the + debugging information, new commands can be added to the + debugger, and thread support could be added to the debugger.

      + +

      + The "SourceLanguage" modules provided by llvm-db could be substantially + improved to provide good support for C++ language features like namespaces and + scoping rules.

      + +

      + After working with the debugger for a while, perhaps the nicest improvement + would be to add some sort of line editor, such as GNU readline (but one that is + compatible with the LLVM license).

      + +

      + For someone so inclined, it should be straight-forward to write different + front-ends for the LLVM debugger, as the LLVM debugging engine is cleanly + separated from the llvm-db front-end. A new LLVM GUI debugger or IDE + would be nice. :) +

      + +
      + + + +
      + Using the llvm-db tool +
      + + +
      + +

      + The llvm-db tool provides a GDB-like interface for source-level + debugging of programs. This tool provides many standard commands for inspecting + and modifying the program as it executes, loading new programs, single stepping, + placing breakpoints, etc. This section describes how to use the debugger. +

      + +

      llvm-db has been designed to be as similar to GDB in its user + interface as possible. This should make it extremely easy to learn + llvm-db if you already know GDB. In general, llvm-db + provides the subset of GDB commands that are applicable to LLVM debugging users. + If there is a command missing that make a reasonable amount of sense within the + limitations of llvm-db, please report it as + a bug or, better yet, submit a patch to add it. :)

      + +
      + + +
      + Limitations of llvm-db +
      + +
      + +

      llvm-db is designed to be modular and easy to extend. This + extensibility was key to getting the debugger up-and-running quickly, because we + can start with simple-but-unsophisicated implementations of various components. + Because of this, it is currently missing many features, though they should be + easy to add over time (patches welcomed!). The biggest inherent limitations of + llvm-db are currently due to extremely simple debugger backend (implemented in + "lib/Debugger/UnixLocalInferiorProcess.cpp") which is designed to work without + any cooperation from the code generators. Because it is so simple, it suffers + from the following inherent limitations:

      + +

        + +
      • Running a program in llvm-db is a bit slower than running it with + lli (i.e., in the JIT).
        • + +
      • Inspection of the target hardware is not supported. This means that you + cannot, for example, print the contents of X86 registers.
        • + +
      • Inspection of LLVM code is not supported. This means that you cannot print + the contents of arbitrary LLVM values, or use commands such as stepi. + This also means that you cannot debug code without debug information.
        • + +
      • Portions of the debugger run in the same address space as the program being + debugged. This means that memory corruption by the program could trample on + portions of the debugger.
        • + +
      • Attaching to existing processes and core files is not currently + supported.
        • + +

      + +

      That said, the debugger is still quite useful, and all of these limitations + can be eliminated by integrating support for the debugger into the code + generators, and writing a new InferiorProcess + subclass to use it. See the future work section for ideas + of how to extend the LLVM debugger despite these limitations.

      + +
      + + + +
      + A sample llvm-db session +
      + +
      + +

      TODO: this is obviously lame, when more is implemented, this can be much + better.

      + + 

      + $ llvm-db funccall
+ llvm-db: The LLVM source-level debugger
+ Loading program... successfully loaded 'funccall.bc'!
+ (llvm-db) create
+ Starting program: funccall.bc
+ main at funccall.c:9:2
+ 9 ->            q = 0;
+ (llvm-db) list main
+ 4       void foo() {
+ 5               int t = q;
+ 6               q = t + 1;
+ 7       }
+ 8       int main() {
+ 9 ->            q = 0;
+ 10              foo();
+ 11              q = q - 1;
+ 12
+ 13              return q;
+ (llvm-db) list
+ 14      }
+ (llvm-db) step
+ 10 ->           foo();
+ (llvm-db) s
+ foo at funccall.c:5:2
+ 5 ->            int t = q;
+ (llvm-db) bt
+ #0 ->   0x85ffba0 in foo at funccall.c:5:2
+ #1      0x85ffd98 in main at funccall.c:10:2
+ (llvm-db) finish
+ main at funccall.c:11:2
+ 11 ->           q = q - 1;
+ (llvm-db) s
+ 13 ->           return q;
+ (llvm-db) s
+ The program stopped with exit code 0
+ (llvm-db) quit
+ $
+

      + +
      + + + + +
      + Starting the debugger +
      + +
      + +

      There are three ways to start up the llvm-db debugger:

      + +

      When run with no options, just llvm-db, the debugger starts up + without a program loaded at all. You must use the file command to load a program, and the set args or run + commands to specify the arguments for the program.

      + +

      If you start the debugger with one argument, as llvm-db + <program>, the debugger will start up and load in the specified + program. You can then optionally specify arguments to the program with the set args or run + commands.

      + +

      The third way to start the program is with the --args option. This + option allows you to specify the program to load and the arguments to start out + with. Example use: llvm-db --args ls /home

      + +
      + + +
      + Commands recognized by the debugger +
      + +
      + +

      FIXME: this needs work obviously. See the GDB documentation for + information about what these do, or try 'help [command]' within + llvm-db to get information.

      + +

      +

      General usage:

      +
        +
      • help [command]
        • +
      • quit
        • +
      • file [program]
        • +
      + +

      Program inspection and interaction:

      +
        +
      • create (start the program, stopping it ASAP in main)
        • +
      • kill
        • +
      • run [args]
        • +
      • step [num]
        • +
      • next [num]
        • +
      • cont
        • +
      • finish
        • + +
      • list [start[, end]]
        • +
      • info source
        • +
      • info sources
        • +
      • info functions
        • +
      + +

      Call stack inspection:

      +
        +
      • backtrace
        • +
      • up [n]
        • +
      • down [n]
        • +
      • frame [n]
        • +
      + + +

      Debugger inspection and interaction:

      +
        +
      • info target
        • +
      • show prompt
        • +
      • set prompt
        • +
      • show listsize
        • +
      • set listsize
        • +
      • show language
        • +
      • set language
        • +
      • show args
        • +
      • set args [args]
        • +
      + +

      TODO:

      +
        +
      • info frame
        • +
      • break
        • +
      • print
        • +
      • ptype
        • + +
      • info types
        • +
      • info variables
        • +
      • info program
        • + +
      • info args
        • +
      • info locals
        • +
      • info catch
        • +
      • ... many others
        • +
      +

      +
      + + +
      + Architecture of the LLVM debugger +
      + + +
      + +

      + The LLVM debugger is built out of three distinct layers of software. These + layers provide clients with different interface options depending on what pieces + of they want to implement themselves, and it also promotes code modularity and + good design. The three layers are the Debugger + interface, the "info" interfaces, and the + llvm-db tool itself. +

      +
      + + +
      + The Debugger and InferiorProcess classes +
      + +
      +

      + The Debugger class (defined in the include/llvm/Debugger/ directory) is + a low-level class which is used to maintain information about the loaded + program, as well as start and stop the program running as necessary. This class + does not provide any high-level analysis or control over the program, only + exposing simple interfaces like load/unloadProgram, + create/killProgram, step/next/finish/contProgram, and + low-level methods for installing breakpoints. +

      + +

      + The Debugger class is itself a wrapper around the lowest-level InferiorProcess + class. This class is used to represent an instance of the program running under + debugger control. The InferiorProcess class can be implemented in different + ways for different targets and execution scenarios (e.g., remote debugging). + The InferiorProcess class exposes a small and simple collection of interfaces + which are useful for inspecting the current state of the program (such as + collecting stack trace information, reading the memory image of the process, + etc). The interfaces in this class are designed to be as low-level and simple + as possible, to make it easy to create new instances of the class. +

      + +

      + The Debugger class exposes the currently active instance of InferiorProcess + through the Debugger::getRunningProcess method, which returns a + const reference to the class. This means that clients of the Debugger + class can only inspect the running instance of the program directly. To + change the executing process in some way, they must use the interces exposed by + the Debugger class. +

      +
      + + +
      + The RuntimeInfo, ProgramInfo, and SourceLanguage classes +
      + +
      +

      + The next-highest level of debugger abstraction is provided through the + ProgramInfo, RuntimeInfo, SourceLanguage and related classes (also defined in + the include/llvm/Debugger/ directory). These classes efficiently + decode the debugging information and low-level interfaces exposed by + InferiorProcess into a higher-level representation, suitable for analysis by the + debugger. +

      + +

      + The ProgramInfo class exposes a variety of different kinds of information about + the program objects in the source-level-language. The SourceFileInfo class + represents a source-file in the program (e.g. a .cpp or .h file). The + SourceFileInfo class captures information such as which SourceLanguage was used + to compile the file, where the debugger can get access to the actual file text + (which is lazily loaded on demand), etc. The SourceFunctionInfo class + represents a... FIXME: finish. The ProgramInfo class provides interfaces + to lazily find and decode the information needed to create the Source*Info + classes requested by the debugger. +

      + +

      + The RuntimeInfo class exposes information about the currently executed program, + by decoding information from the InferiorProcess and ProgramInfo classes. It + provides a StackFrame class which provides an easy-to-use interface for + inspecting the current and suspended stack frames in the program. +

      + +

      + The SourceLanguage class is an abstract interface used by the debugger to + perform all source-language-specific tasks. For example, this interface is used + by the ProgramInfo class to decode language-specific types and functions and by + the debugger front-end (such as llvm-db to + evaluate source-langauge expressions typed into the debugger. This class uses + the RuntimeInfo & ProgramInfo classes to get information about the current + execution context and the loaded program, respectively. +

      + +
      + + +
      + The llvm-db tool +
      + +
      +

      + The llvm-db is designed to be a debugger providing an interface as similar to GDB as reasonable, but no more so than that. + Because the Debugger and info classes implement all of the heavy lifting and + analysis, llvm-db (which lives in llvm/tools/llvm-db) consists + mainly of of code to interact with the user and parse commands. The CLIDebugger + constructor registers all of the builtin commands for the debugger, and each + command is implemented as a CLIDebugger::[name]Command method. +

      +
      + + + +
      + Short-term TODO list +
      + +
      + +

      + FIXME: this section will eventually go away. These are notes to myself of + things that should be implemented, but haven't yet. +

      + +

      + Breakpoints: Support is already implemented in the 'InferiorProcess' + class, though it hasn't been tested yet. To finish breakpoint support, we need + to implement breakCommand (which should reuse the linespec parser from the list + command), and handle the fact that 'break foo' or 'break file.c:53' may insert + multiple breakpoints. Also, if you say 'break file.c:53' and there is no + stoppoint on line 53, the breakpoint should go on the next available line. My + idea was to have the Debugger class provide a "Breakpoint" class which + encapsulated this messiness, giving the debugger front-end a simple interface. + The debugger front-end would have to map the really complex semantics of + temporary breakpoints and 'conditional' breakpoints onto this intermediate + level. Also, breakpoints should survive as much as possible across program + reloads. +

      + +

      + UnixLocalInferiorProcess.cpp speedup: There is no reason for the debugged + process to code gen the globals corresponding to debug information. The + IntrinsicLowering object could instead change descriptors into constant expr + casts of the constant address of the LLVM objects for the descriptors. This + would also allow us to eliminate the mapping back and forth between physical + addresses that must be done.

      + +

      + Process deaths: The InferiorProcessDead exception should be extended to + know "how" a process died, i.e., it was killed by a signal. This is easy to + collect in the UnixLocalInferiorProcess, we just need to represent it.

      + +
      + + +
      + 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 + necessarily having to know anything about debugging information. In particular, + the global constant merging pass automatically eliminates duplicated debugging + information (often caused by header files), the global dead code elimination + pass automatically deletes debugging information for a function if it decides to + delete the function, and the linker eliminates debug information when it merges + linkonce functions.

      + +

      To do this, most of the debugging information (descriptors for types, + variables, functions, source files, etc) is inserted by the language front-end + in the form of LLVM global variables. These LLVM global variables are no + different from any other global variables, except that they have a web of LLVM + intrinsic functions that point to them. If the last references to a particular + piece of debugging information are deleted (for example, by the + -globaldce pass), the extraneous debug information will automatically + become dead and be removed by the optimizer.

      + +

      The debugger is designed to be agnostic about the contents of most of the + debugging information. It uses a source-language-specific + module to decode the information that represents variables, types, + functions, namespaces, etc: this allows for arbitrary source-language semantics + and type-systems to be used, as long as there is a module written for the + debugger to interpret the information. +

      + +

      + To provide basic functionality, the LLVM debugger does have to make some + assumptions about the source-level language being debugged, though it keeps + these to a minimum. The only common features that the LLVM debugger assumes + exist are source files, and program objects. These abstract objects are + used by the debugger to form stack traces, show information about local + variables, etc. + +

      This section of the documentation first describes the representation aspects + common to any source-language. The next section + describes the data layout conventions used by the C and C++ front-ends.

      + +
      + + +
      + Anchors for global objects +
      + +
      +

      + One important aspect of the LLVM debug representation is that it allows the LLVM + debugger to efficiently index all of the global objects without having the scan + the program. To do this, all of the global objects use "anchor" globals of type + "{}", with designated names. These anchor objects obviously do not + contain any content or meaning by themselves, but all of the global objects of a + particular type (e.g., source file descriptors) contain a pointer to the anchor. + This pointer allows the debugger to use def-use chains to find all global + objects of that type. +

      + +

      + So far, the following names are recognized as anchors by the LLVM debugger: +

      + + 

      +   %llvm.dbg.translation_units = linkonce global {} {}
+   %llvm.dbg.globals         = linkonce global {} {}
+

      + +

      + Using anchors in this way (where the source file descriptor points to the + anchors, as opposed to having a list of source file descriptors) allows for the + standard dead global elimination and merging passes to automatically remove + unused debugging information. If the globals were kept track of through lists, + there would always be an object pointing to the descriptors, thus would never be + deleted. +

      + +
      + + + +
      + + Representing stopping points in the source program + +
      + +
      + +

      LLVM debugger "stop points" are a key part of the debugging representation + that allows the LLVM to maintain simple semantics for debugging optimized code. The basic idea is that the + front-end inserts calls to the %llvm.dbg.stoppoint intrinsic function + at every point in the program where the debugger should be able to inspect the + program (these correspond to places the debugger stops when you "step" + through it). The front-end can choose to place these as fine-grained as it + would like (for example, before every subexpression evaluated), but it is + recommended to only put them after every source statement that includes + executable code.

      + +

      + Using calls to this intrinsic function to demark legal points for the debugger + to inspect the program automatically disables any optimizations that could + potentially confuse debugging information. To non-debug-information-aware + transformations, these calls simply look like calls to an external function, + which they must assume to do anything (including reading or writing to any part + of reachable memory). On the other hand, it does not impact many optimizations, + such as code motion of non-trapping instructions, nor does it impact + optimization of subexpressions, code duplication transformations, or basic-block + reordering transformations.

      + +

      + An important aspect of the calls to the %llvm.dbg.stoppoint intrinsic + is that the function-local debugging information is woven together with use-def + chains. This makes it easy for the debugger to, for example, locate the 'next' + stop point. For a concrete example of stop points, see the example in the next section.

      + +
      + + + +
      + Object lifetimes and scoping +
      + +
      +

      + In many languages, the local variables in functions can have their lifetime or + scope limited to a subset of a function. In the C family of languages, for + example, variables are only live (readable and writable) within the source block + that they are defined in. In functional languages, values are only readable + after they have been defined. Though this is a very obvious concept, it is also + non-trivial to model in LLVM, because it has no notion of scoping in this sense, + and does not want to be tied to a language's scoping rules. +

      + +

      + In order to handle this, the LLVM debug format uses the notion of "regions" of a + function, delineated by calls to intrinsic functions. These intrinsic functions + define new regions of the program and indicate when the region lifetime expires. + Consider the following C fragment, for example: +

      + + 

      + 1.  void foo() {
+ 2.    int X = ...;
+ 3.    int Y = ...;
+ 4.    {
+ 5.      int Z = ...;
+ 6.      ...
+ 7.    }
+ 8.    ...
+ 9.  }
+

      + +

      + Compiled to LLVM, this function would be represented like this (FIXME: CHECK AND + UPDATE THIS): +

      + + 

      + void %foo() {
+     %X = alloca int
+     %Y = alloca int
+     %Z = alloca int
+     %D1 = call {}* %llvm.dbg.func.start(%lldb.global* %d.foo)
+     %D2 = call {}* %llvm.dbg.stoppoint({}* %D1, uint 2, uint 2, %lldb.compile_unit* %file)
+ 
+     %D3 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D2, ...)
+     ;; Evaluate expression on line 2, assigning to X.
+     %D4 = call {}* %llvm.dbg.stoppoint({}* %D3, uint 3, uint 2, %lldb.compile_unit* %file)
+ 
+     %D5 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D4, ...)
+     ;; Evaluate expression on line 3, assigning to Y.
+     %D6 = call {}* %llvm.dbg.stoppoint({}* %D5, uint 5, uint 4, %lldb.compile_unit* %file)
+ 
+     %D7 = call {}* %llvm.region.start({}* %D6)
+     %D8 = call {}* %llvm.dbg.DEFINEVARIABLE({}* %D7, ...)
+     ;; Evaluate expression on line 5, assigning to Z.
+     %D9 = call {}* %llvm.dbg.stoppoint({}* %D8, uint 6, uint 4, %lldb.compile_unit* %file)
+ 
+     ;; Code for line 6.
+     %D10 = call {}* %llvm.region.end({}* %D9)
+     %D11 = call {}* %llvm.dbg.stoppoint({}* %D10, uint 8, uint 2, %lldb.compile_unit* %file)
+ 
+     ;; Code for line 8.
+     %D12 = call {}* %llvm.region.end({}* %D11)
+     ret void
+ }
+

      + +

      + This example illustrates a few important details about the LLVM debugging + information. In particular, it shows how the various intrinsics used are woven + together with def-use and use-def chains, similar to how anchors are used with globals. This allows the + debugger to analyze the relationship between statements, variable definitions, + and the code used to implement the function.

      + +

      + In this example, two explicit regions are defined, one with the definition of the %D1 variable and one with the + definition of %D7. In the case of + %D1, the debug information indicates that the function whose descriptor is specified as an argument to the + intrinsic. This defines a new stack frame whose lifetime ends when the region + is ended by the %D12 call.

      + +

      + Using regions to represent the boundaries of source-level functions allow LLVM + interprocedural optimizations to arbitrarily modify LLVM functions without + having to worry about breaking mapping information between the LLVM code and the + and source-level program. In particular, the inliner requires no modification + to support inlining with debugging information: there is no explicit correlation + drawn between LLVM functions and their source-level counterparts (note however, + that if the inliner inlines all instances of a non-strong-linkage function into + its caller that it will not be possible for the user to manually invoke the + inlined function from the debugger).

      + +

      + Once the function has been defined, the stopping point corresponding to line #2 of the + function is encountered. At this point in the function, no local + variables are live. As lines 2 and 3 of the example are executed, their + variable definitions are automatically introduced into the program, without the + need to specify a new region. These variables do not require new regions to be + introduced because they go out of scope at the same point in the program: line + 9. +

      + +

      + In contrast, the Z variable goes out of scope at a different time, on + line 7. For this reason, it is defined within the + %D7 region, which kills the availability of Z before the + code for line 8 is executed. In this way, regions can support arbitrary + source-language scoping rules, as long as they can only be nested (ie, one scope + cannot partially overlap with a part of another scope). +

      + +

      + It is worth noting that this scoping mechanism is used to control scoping of all + declarations, not just variable declarations. For example, the scope of a C++ + using declaration is controlled with this, and the llvm-db C++ support + routines could use this to change how name lookup is performed (though this is + not implemented yet). +

      + +
      + + + +
      + Object descriptor formats +
      + +
      +

      + The LLVM debugger expects the descriptors for program objects to start in a + canonical format, but the descriptors can include additional information + appended at the end that is source-language specific. All LLVM debugging + information is versioned, allowing backwards compatibility in the case that the + core structures need to change in some way. Also, all debugging information + objects start with a tag to indicate what type + of object it is. The source-language is allows to define its own objects, by + using unreserved tag numbers.

      + +

      The lowest-level descriptor are those describing the files containing the program source + code, as most other descriptors (sometimes indirectly) refer to them. +

      +
      + + + +
      + Representation of source files +
      + +
      +

      + Source file descriptors are patterned after the Dwarf "compile_unit" object. + The descriptor currently is defined to have at least the following LLVM + type entries:

      + + 

      + %lldb.compile_unit = type {
+        uint,                 ;; Tag: LLVM_COMPILE_UNIT
+        ushort,               ;; LLVM debug version number
+        ushort,               ;; Dwarf language identifier
+        sbyte*,               ;; Filename
+        sbyte*,               ;; Working directory when compiled
+        sbyte*                ;; Producer of the debug information
+ }
+

      + +

      + These descriptors contain the version number for the debug info, a source + language ID for the file (we use the Dwarf 3.0 ID numbers, such as + DW_LANG_C89, DW_LANG_C_plus_plus, DW_LANG_Cobol74, + etc), three strings describing the filename, working directory of the compiler, + and an identifier string for the compiler that produced it. Note that actual + compile_unit declarations must also include an anchor to llvm.dbg.translation_units, + but it is not specified where the anchor is to be located. Here is an example + descriptor: +

      + + 

      + %arraytest_source_file = internal constant %lldb.compile_unit {
+     uint 17,                                                      ; Tag value
+     ushort 0,                                                     ; Version #0
+     ushort 1,                                                     ; DW_LANG_C89
+     sbyte* getelementptr ([12 x sbyte]* %.str_1, long 0, long 0), ; filename
+     sbyte* getelementptr ([12 x sbyte]* %.str_2, long 0, long 0), ; working dir
+     sbyte* getelementptr ([12 x sbyte]* %.str_3, long 0, long 0), ; producer
+     {}* %llvm.dbg.translation_units                               ; Anchor
+ }
+ %.str_1 = internal constant [12 x sbyte] c"arraytest.c\00"
+ %.str_2 = internal constant [12 x sbyte] c"/home/sabre\00"
+ %.str_3 = internal constant [12 x sbyte] c"llvmgcc 3.4\00"
+

      + +

      + Note that the LLVM constant merging pass should eliminate duplicate copies of + the strings that get emitted to each translation unit, such as the producer. +

      + +
      + + + +
      + Representation of program objects +
      + +
      +

      + The LLVM debugger needs to know about some source-language program objects, in + order to build stack traces, print information about local variables, and other + related activities. The LLVM debugger differentiates between three different + types of program objects: subprograms (functions, messages, methods, etc), + variables (locals and globals), and others. Because source-languages have + widely varying forms of these objects, the LLVM debugger expects only a few + fields in the descriptor for each object: +

      + + 

      + %lldb.object = type {
+        uint,                  ;; A tag
+        any*,                  ;; The context for the object
+        sbyte*                 ;; The object 'name'
+ }
+

      + +

      + The first field contains a tag for the descriptor. The second field contains + either a pointer to the descriptor for the containing source file, or it contains a pointer to + another program object whose context pointer eventually reaches a source file. + Through this context pointer, the + LLVM debugger can establish the debug version number of the object.

      + +

      + The third field contains a string that the debugger can use to identify the + object if it does not contain explicit support for the source-language in use + (ie, the 'unknown' source language handler uses this string). This should be + some sort of unmangled string that corresponds to the object, but it is a + quality of implementation issue what exactly it contains (it is legal, though + not useful, for all of these strings to be null). +

      + +

      + Note again that descriptors can be extended to include source-language-specific + information in addition to the fields required by the LLVM debugger. See the section on the C/C++ front-end for more + information. Also remember that global objects (functions, selectors, global + variables, etc) must contain an anchor to + the llvm.dbg.globals variable. +

      +
      + + + +
      + Program object contexts +
      + +
      + 

      + Allow source-language specific contexts, use to identify namespaces etc
+ Must end up in a source file descriptor.
+ Debugger core ignores all unknown context objects.
+

      +
      + + + + +
      + Debugger intrinsic functions +
      + +
      + 

      + Define each intrinsics, as an extension of the language reference manual.
+ 
+ llvm.dbg.stoppoint
+ llvm.dbg.region.start
+ llvm.dbg.region.end
+ llvm.dbg.function.start
+ llvm.dbg.declare
+

      +
      + + + + +
      + Values for debugger tags +
      + +
      + +

      + Happen to be the same value as the similarly named Dwarf-3 tags, this may change + in the future. +

      + +

      + 

      +   LLVM_COMPILE_UNIT     : 17
+   LLVM_SUBPROGRAM       : 46
+   LLVM_VARIABLE         : 52
+ 
+

      +
      + + + + +
      + 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 to Dwarf 3.0 in terms of + information content. This allows code generators to trivially support native + debuggers by generating standard dwarf information, and contains enough + information for non-dwarf targets to translate it as needed.

      + +

      + The basic debug information required by the debugger is (intentionally) designed + to be as minimal as possible. This basic information is so minimal that it is + unlikely that any source-language could be adequately described by it. + Because of this, the debugger format was designed for extension to support + source-language-specific information. The extended descriptors are read and + interpreted by the language-specific modules in the + debugger if there is support available, otherwise it is ignored. +

      + +

      + This section describes the extensions used to represent C and C++ programs. + Other languages could pattern themselves after this (which itself is tuned to + representing programs in the same way that Dwarf 3 does), or they could choose + to provide completely different extensions if they don't fit into the Dwarf + model. As support for debugging information gets added to the various LLVM + source-language front-ends, the information used should be documented here. +

      + +
      + + +
      + Program Scope Entries +
      + +
      +

      + +

      +
      + + +
      + Compilation unit entries +
      + +
      +

      + Translation units do not add any information over the standard source file representation already + expected by the debugger. As such, it uses descriptors of the type specified, + with a trailing anchor. +

      +
      + + +
      + Module, namespace, and importing entries +
      + +
      +

      + +

      +
      + + +
      + Data objects (program variables) +
      + +
      +

      + +

      +
      + + + +
      +
      +
      Chris Lattner
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/Stacker.html diff -c /dev/null llvm-www/releases/1.2/docs/Stacker.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/Stacker.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,1400 ---- + + + + Stacker: An Example Of Using LLVM + + + +
      Stacker: An Example Of Using LLVM
      +
      +
        +
      1. Abstract
        2. +
      2. Introduction
        3. +
      3. Lessons I Learned About LLVM +
          +
        1. Everything's a Value!
          2. +
        2. Terminate Those Blocks!
          3. +
        3. Concrete Blocks
          4. +
        4. push_back Is Your Friend
          5. +
        5. The Wily GetElementPtrInst
          6. +
        6. Getting Linkage Types Right
          7. +
        7. Constants Are Easier Than That!
          8. +
        +
        4. +
      4. The Stacker Lexicon +
          +
        1. The Stack +
        2. Punctuation +
        3. Comments +
        4. Literals +
        5. Words +
        6. Standard Style +
        7. Built-Ins +
        +
        5. +
      5. Prime: A Complete Example
        6. +
      6. Internal Code Details +
          +
        1. The Directory Structure
          2. +
        2. The Lexer
          3. +
        3. The Parser
          4. +
        4. The Compiler
          5. +
        5. The Runtime
          6. +
        6. Compiler Driver
          7. +
        7. Test Programs
          8. +
        8. Exercise
          9. +
        9. Things Remaining To Be Done
          10. +
        +
        7. +
      +
      +

      Written by Reid Spencer

      +

      +
      +
      + +
      Abstract
      +
      +

      This document is another way to learn about LLVM. Unlike the + LLVM Reference Manual or + LLVM Programmer's Manual, here we learn + about LLVM through the experience of creating a simple programming language + named Stacker. Stacker was invented specifically as a demonstration of + LLVM. The emphasis in this document is not on describing the + intricacies of LLVM itself but on how to use it to build your own + compiler system.

      +
      + +
      Introduction
      +
      +

      Amongst other things, LLVM is a platform for compiler writers. + Because of its exceptionally clean and small IR (intermediate + representation), compiler writing with LLVM is much easier than with + other system. As proof, I wrote the entire compiler (language definition, + lexer, parser, code generator, etc.) in about four days! + That's important to know because it shows how quickly you can get a new + language running when using LLVM. Furthermore, this was the first + language the author ever created using LLVM. The learning curve is + included in that four days.

      +

      The language described here, Stacker, is Forth-like. Programs + are simple collections of word definitions, and the only thing definitions + can do is manipulate a stack or generate I/O. Stacker is not a "real" + programming language; it's very simple. Although it is computationally + complete, you wouldn't use it for your next big project. However, + the fact that it is complete, it's simple, and it doesn't have + a C-like syntax make it useful for demonstration purposes. It shows + that LLVM could be applied to a wide variety of languages.

      +

      The basic notions behind stacker is very simple. There's a stack of + integers (or character pointers) that the program manipulates. Pretty + much the only thing the program can do is manipulate the stack and do + some limited I/O operations. The language provides you with several + built-in words that manipulate the stack in interesting ways. To get + your feet wet, here's how you write the traditional "Hello, World" + program in Stacker:

      +

      : hello_world "Hello, World!" >s DROP CR ;
      + : MAIN hello_world ;

      +

      This has two "definitions" (Stacker manipulates words, not + functions and words have definitions): MAIN and + hello_world. The MAIN definition is standard; it + tells Stacker where to start. Here, MAIN is defined to + simply invoke the word hello_world. The + hello_world definition tells stacker to push the + "Hello, World!" string on to the stack, print it out + (>s), pop it off the stack (DROP), and + finally print a carriage return (CR). Although + hello_world uses the stack, its net effect is null. Well + written Stacker definitions have that characteristic.

      +

      Exercise for the reader: how could you make this a one line program?

      +
      + +
      Lessons I Learned About LLVM
      +
      +

      Stacker was written for two purposes:

      +
        +
      1. to get the author over the learning curve, and
        2. +
      2. to provide a simple example of how to write a compiler using LLVM.
        3. +
      +

      During the development of Stacker, many lessons about LLVM were + learned. Those lessons are described in the following subsections.

      +

      + +
      Everything's a Value!
      +
      +

      Although I knew that LLVM uses a Single Static Assignment (SSA) format, + it wasn't obvious to me how prevalent this idea was in LLVM until I really + started using it. Reading the + Programmer's Manual and Language Reference, + I noted that most of the important LLVM IR (Intermediate Representation) C++ + classes were derived from the Value class. The full power of that simple + design only became fully understood once I started constructing executable + expressions for Stacker.

      +

      This really makes your programming go faster. Think about compiling code + for the following C/C++ expression: (a|b)*((x+1)/(y+1)). Assuming + the values are on the stack in the order a, b, x, y, this could be + expressed in stacker as: 1 + SWAP 1 + / ROT2 OR *. + You could write a function using LLVM that computes this expression like this:

      + 
      
+ Value* 
+ expression(BasicBlock* bb, Value* a, Value* b, Value* x, Value* y )
+ {
+     Instruction* tail = bb->getTerminator();
+     ConstantSInt* one = ConstantSInt::get( Type::IntTy, 1);
+     BinaryOperator* or1 = 
+ 	BinaryOperator::create( Instruction::Or, a, b, "", tail );
+     BinaryOperator* add1 = 
+ 	BinaryOperator::create( Instruction::Add, x, one, "", tail );
+     BinaryOperator* add2 =
+ 	BinaryOperator::create( Instruction::Add, y, one, "", tail );
+     BinaryOperator* div1 = 
+ 	BinaryOperator::create( Instruction::Div, add1, add2, "", tail);
+     BinaryOperator* mult1 = 
+ 	BinaryOperator::create( Instruction::Mul, or1, div1, "", tail );
+ 
+     return mult1;
+ }
+
      +

      "Okay, big deal," you say? It is a big deal. Here's why. Note that I didn't + have to tell this function which kinds of Values are being passed in. They could be + Instructions, Constants, GlobalVariables, or + any of the other subclasses of Value that LLVM supports. + Furthermore, if you specify Values that are incorrect for this sequence of + operations, LLVM will either notice right away (at compilation time) or the LLVM + Verifier will pick up the inconsistency when the compiler runs. In either case + LLVM prevents you from making a type error that gets passed through to the + generated program. This really helps you write a compiler that + always generates correct code!

      +

      The second point is that we don't have to worry about branching, registers, + stack variables, saving partial results, etc. The instructions we create + are the values we use. Note that all that was created in the above + code is a Constant value and five operators. Each of the instructions is + the resulting value of that instruction. This saves a lot of time.

      +

      The lesson is this: SSA form is very powerful: there is no difference + between a value and the instruction that created it. This is fully + enforced by the LLVM IR. Use it to your best advantage.

      +
      + +
      Terminate Those Blocks!
      +
      +

      I had to learn about terminating blocks the hard way: using the debugger + to figure out what the LLVM verifier was trying to tell me and begging for + help on the LLVMdev mailing list. I hope you avoid this experience.

      +

      Emblazon this rule in your mind:

      +
        +
      • All BasicBlocks in your compiler must be + terminated with a terminating instruction (branch, return, etc.). +
        • +
      +

      Terminating instructions are a semantic requirement of the LLVM IR. There + is no facility for implicitly chaining together blocks placed into a function + in the order they occur. Indeed, in the general case, blocks will not be + added to the function in the order of execution because of the recursive + way compilers are written.

      +

      Furthermore, if you don't terminate your blocks, your compiler code will + compile just fine. You won't find out about the problem until you're running + the compiler and the module you just created fails on the LLVM Verifier.

      +
      + +
      Concrete Blocks
      +
      +

      After a little initial fumbling around, I quickly caught on to how blocks + should be constructed. In general, here's what I learned: +

        +
      1. Create your blocks early. While writing your compiler, you + will encounter several situations where you know apriori that you will + need several blocks. For example, if-then-else, switch, while, and for + statements in C/C++ all need multiple blocks for expression in LVVM. + The rule is, create them early.
        2. +
      2. Terminate your blocks early. This just reduces the chances + that you forget to terminate your blocks which is required (go + here for more). +
      3. Use getTerminator() for instruction insertion. I noticed early on + that many of the constructors for the Instruction classes take an optional + insert_before argument. At first, I thought this was a mistake + because clearly the normal mode of inserting instructions would be one at + a time after some other instruction, not before. However, + if you hold on to your terminating instruction (or use the handy dandy + getTerminator() method on a BasicBlock), it can + always be used as the insert_before argument to your instruction + constructors. This causes the instruction to automatically be inserted in + the RightPlace™ place, just before the terminating instruction. The + nice thing about this design is that you can pass blocks around and insert + new instructions into them without ever knowing what instructions came + before. This makes for some very clean compiler design.
        4. +
      +

      The foregoing is such an important principal, its worth making an idiom:

      + 
      
+ BasicBlock* bb = new BasicBlock();
+ bb->getInstList().push_back( new Branch( ... ) );
+ new Instruction(..., bb->getTerminator() );
+
      +

      To make this clear, consider the typical if-then-else statement + (see StackerCompiler::handle_if() method). We can set this up + in a single function using LLVM in the following way:

      + 
      + using namespace llvm;
+ BasicBlock*
+ MyCompiler::handle_if( BasicBlock* bb, SetCondInst* condition )
+ {
+     // Create the blocks to contain code in the structure of if/then/else
+     BasicBlock* then_bb = new BasicBlock(); 
+     BasicBlock* else_bb = new BasicBlock();
+     BasicBlock* exit_bb = new BasicBlock();
+ 
+     // Insert the branch instruction for the "if"
+     bb->getInstList().push_back( new BranchInst( then_bb, else_bb, condition ) );
+ 
+     // Set up the terminating instructions
+     then->getInstList().push_back( new BranchInst( exit_bb ) );
+     else->getInstList().push_back( new BranchInst( exit_bb ) );
+ 
+     // Fill in the then part .. details excised for brevity
+     this->fill_in( then_bb );
+ 
+     // Fill in the else part .. details excised for brevity
+     this->fill_in( else_bb );
+ 
+     // Return a block to the caller that can be filled in with the code
+     // that follows the if/then/else construct.
+     return exit_bb;
+ }
+
      +

      Presumably in the foregoing, the calls to the "fill_in" method would add + the instructions for the "then" and "else" parts. They would use the third part + of the idiom almost exclusively (inserting new instructions before the + terminator). Furthermore, they could even recurse back to handle_if + should they encounter another if/then/else statement, and it will just work.

      +

      Note how cleanly this all works out. In particular, the push_back methods on + the BasicBlock's instruction list. These are lists of type + Instruction (which is also of type Value). To create + the "if" branch we merely instantiate a BranchInst that takes as + arguments the blocks to branch to and the condition to branch on. The + BasicBlock objects act like branch labels! This new + BranchInst terminates the BasicBlock provided + as an argument. To give the caller a way to keep inserting after calling + handle_if, we create an exit_bb block which is + returned + to the caller. Note that the exit_bb block is used as the + terminator for both the then_bb and the else_bb + blocks. This guarantees that no matter what else handle_if + or fill_in does, they end up at the exit_bb block. +

      +
      + +
      push_back Is Your Friend
      +
      +

      + One of the first things I noticed is the frequent use of the "push_back" + method on the various lists. This is so common that it is worth mentioning. + The "push_back" inserts a value into an STL list, vector, array, etc. at the + end. The method might have also been named "insert_tail" or "append". + Although I've used STL quite frequently, my use of push_back wasn't very + high in other programs. In LLVM, you'll use it all the time. +

      +
      + +
      The Wily GetElementPtrInst
      +
      +

      + It took a little getting used to and several rounds of postings to the LLVM + mailing list to wrap my head around this instruction correctly. Even though I had + read the Language Reference and Programmer's Manual a couple times each, I still + missed a few very key points: +

      +
        +
      • GetElementPtrInst gives you back a Value for the last thing indexed. +
      • All global variables in LLVM are pointers. +
      • Pointers must also be dereferenced with the GetElementPtrInst instruction. +
      +

      This means that when you look up an element in the global variable (assuming + it's a struct or array), you must deference the pointer first! For many + things, this leads to the idiom: +

      + 
      
+ std::vector index_vector;
+ index_vector.push_back( ConstantSInt::get( Type::LongTy, 0 );
+ // ... push other indices ...
+ GetElementPtrInst* gep = new GetElementPtrInst( ptr, index_vector );
+
      +

      For example, suppose we have a global variable whose type is [24 x int]. The + variable itself represents a pointer to that array. To subscript the + array, we need two indices, not just one. The first index (0) dereferences the + pointer. The second index subscripts the array. If you're a "C" programmer, this + will run against your grain because you'll naturally think of the global array + variable and the address of its first element as the same. That tripped me up + for a while until I realized that they really do differ .. by type. + Remember that LLVM is strongly typed. Everything has a type. + The "type" of the global variable is [24 x int]*. That is, it's + a pointer to an array of 24 ints. When you dereference that global variable with + a single (0) index, you now have a "[24 x int]" type. Although + the pointer value of the dereferenced global and the address of the zero'th element + in the array will be the same, they differ in their type. The zero'th element has + type "int" while the pointer value has type "[24 x int]".

      +

      Get this one aspect of LLVM right in your head, and you'll save yourself + a lot of compiler writing headaches down the road.

      +
      + +
      Getting Linkage Types Right
      +
      +

      Linkage types in LLVM can be a little confusing, especially if your compiler + writing mind has affixed firm concepts to particular words like "weak", + "external", "global", "linkonce", etc. LLVM does not use the precise + definitions of, say, ELF or GCC, even though they share common terms. To be fair, + the concepts are related and similar but not precisely the same. This can lead + you to think you know what a linkage type represents but in fact it is slightly + different. I recommend you read the + Language Reference on this topic very + carefully. Then, read it again.

      +

      Here are some handy tips that I discovered along the way:

      +
        +
      • Uninitialized means external. That is, the symbol is declared in the current + module and can be used by that module, but it is not defined by that module.
        • +
      • Setting an initializer changes a global' linkage type. Setting an + initializer changes a global's linkage type from whatever it was to a normal, + defined global (not external). You'll need to call the setLinkage() method to + reset it if you specify the initializer after the GlobalValue has been constructed. + This is important for LinkOnce and Weak linkage types.
        • +
      • Appending linkage can keep track of things. Appending linkage can + be used to keep track of compilation information at runtime. It could be used, + for example, to build a full table of all the C++ virtual tables or hold the + C++ RTTI data, or whatever. Appending linkage can only be applied to arrays. + All arrays with the same name in each module are concatenated together at link + time.
        • +
      +
      + +
      Constants Are Easier Than That!
      +
      +

      + Constants in LLVM took a little getting used to until I discovered a few utility + functions in the LLVM IR that make things easier. Here's what I learned:

      +
        +
      • Constants are Values like anything else and can be operands of instructions
        • +
      • Integer constants, frequently needed, can be created using the static "get" + methods of the ConstantInt, ConstantSInt, and ConstantUInt classes. The nice thing + about these is that you can "get" any kind of integer quickly.
        • +
      • There's a special method on Constant class which allows you to get the null + constant for any type. This is really handy for initializing large + arrays or structures, etc.
        • +
      +
      + +
      The Stacker Lexicon
      +

      This section describes the Stacker language

      +
      The Stack
      +
      +

      Stacker definitions define what they do to the global stack. Before + proceeding, a few words about the stack are in order. The stack is simply + a global array of 32-bit integers or pointers. A global index keeps track + of the location of the top of the stack. All of this is hidden from the + programmer, but it needs to be noted because it is the foundation of the + conceptual programming model for Stacker. When you write a definition, + you are, essentially, saying how you want that definition to manipulate + the global stack.

      +

      Manipulating the stack can be quite hazardous. There is no distinction + given and no checking for the various types of values that can be placed + on the stack. Automatic coercion between types is performed. In many + cases, this is useful. For example, a boolean value placed on the stack + can be interpreted as an integer with good results. However, using a + word that interprets that boolean value as a pointer to a string to + print out will almost always yield a crash. Stacker simply leaves it + to the programmer to get it right without any interference or hindering + on interpretation of the stack values. You've been warned. :)

      +
      + +
      Punctuation
      +
      +

      Punctuation in Stacker is very simple. The colon and semi-colon + characters are used to introduce and terminate a definition + (respectively). Except for FORWARD declarations, definitions + are all you can specify in Stacker. Definitions are read left to right. + Immediately after the colon comes the name of the word being defined. + The remaining words in the definition specify what the word does. The definition + is terminated by a semi-colon.

      +

      So, your typical definition will have the form:

      + 
      : name ... ;
      +

      The name is up to you but it must start with a letter and contain + only letters, numbers, and underscore. Names are case sensitive and must not be + the same as the name of a built-in word. The ... is replaced by + the stack manipulating words that you wish to define name as.

      +

      + +
      Comments
      +
      +

      Stacker supports two types of comments. A hash mark (#) starts a comment + that extends to the end of the line. It is identical to the kind of comments + commonly used in shell scripts. A pair of parentheses also surround a comment. + In both cases, the content of the comment is ignored by the Stacker compiler. The + following does nothing in Stacker. +

      + 
      
+ # This is a comment to end of line
+ ( This is an enclosed comment )
+
      +

      See the example program to see comments in use in + a real program.

      +
      + +
      Literals
      +
      +

      There are three kinds of literal values in Stacker: Integers, Strings, + and Booleans. In each case, the stack operation is to simply push the + value on to the stack. So, for example:
      + 42 " is the answer." TRUE
      + will push three values on to the stack: the integer 42, the + string " is the answer.", and the boolean TRUE.

      +
      + +
      Words
      +
      +

      Each definition in Stacker is composed of a set of words. Words are + read and executed in order from left to right. There is very little + checking in Stacker to make sure you're doing the right thing with + the stack. It is assumed that the programmer knows how the stack + transformation he applies will affect the program.

      +

      Words in a definition come in two flavors: built-in and programmer + defined. Simply mentioning the name of a previously defined or declared + programmer-defined word causes that word's stack actions to be invoked. It + is somewhat like a function call in other languages. The built-in + words have various effects, described below.

      +

      Sometimes you need to call a word before it is defined. For this, you can + use the FORWARD declaration. It looks like this:

      +

      FORWARD name ;

      +

      This simply states to Stacker that "name" is the name of a definition + that is defined elsewhere. Generally it means the definition can be found + "forward" in the file. But, it doesn't have to be in the current compilation + unit. Anything declared with FORWARD is an external symbol for + linking.

      +
      + +
      Built In Words
      +
      +

      The built-in words of the Stacker language are put in several groups + depending on what they do. The groups are as follows:

      +
        +
      1. Logical: These words provide the logical operations for + comparing stack operands.
        The words are: < > <= >= + = <> true false.
        2. +
      2. Bitwise: These words perform bitwise computations on + their operands.
        The words are: << >> XOR AND NOT
        3. +
      3. Arithmetic: These words perform arithmetic computations on + their operands.
        The words are: ABS NEG + - * / MOD */ ++ -- MIN MAX
        4. +
      4. StackThese words manipulate the stack directly by moving + its elements around.
        The words are: DROP DROP2 NIP NIP2 DUP DUP2 + SWAP SWAP2 OVER OVER2 ROT ROT2 RROT RROT2 TUCK TUCK2 PICK SELECT ROLL
        5. +
      5. MemoryThese words allocate, free, and manipulate memory + areas outside the stack.
        The words are: MALLOC FREE GET PUT
        6. +
      6. Control: These words alter the normal left to right flow + of execution.
        The words are: IF ELSE ENDIF WHILE END RETURN EXIT RECURSE
        7. +
      7. I/O: These words perform output on the standard output + and input on the standard input. No other I/O is possible in Stacker. +
        The words are: SPACE TAB CR >s >d >c <s <d <c.
        8. +
      +

      While you may be familiar with many of these operations from other + programming languages, a careful review of their semantics is important + for correct programming in Stacker. Of most importance is the effect + that each of these built-in words has on the global stack. The effect is + not always intuitive. To better describe the effects, we'll borrow from Forth the idiom of + describing the effect on the stack with:

      +

      BEFORE -- AFTER

      +

      That is, to the left of the -- is a representation of the stack before + the operation. To the right of the -- is a representation of the stack + after the operation. In the table below that describes the operation of + each of the built in words, we will denote the elements of the stack + using the following construction:

      +
        +
      1. b - a boolean truth value
        2. +
      2. w - a normal integer valued word.
        3. +
      3. s - a pointer to a string value
        4. +
      4. p - a pointer to a malloc'd memory block
        5. +
      +
      +
      + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
      Definition Of Operation Of Built In Words
      LOGICAL OPERATIONS
      WordNameOperationDescription
      <LTw1 w2 -- bTwo values (w1 and w2) are popped off the stack and + compared. If w1 is less than w2, TRUE is pushed back on + the stack, otherwise FALSE is pushed back on the stack.
      >GTw1 w2 -- bTwo values (w1 and w2) are popped off the stack and + compared. If w1 is greater than w2, TRUE is pushed back on + the stack, otherwise FALSE is pushed back on the stack.
      >=GEw1 w2 -- bTwo values (w1 and w2) are popped off the stack and + compared. If w1 is greater than or equal to w2, TRUE is + pushed back on the stack, otherwise FALSE is pushed back + on the stack.
      <=LEw1 w2 -- bTwo values (w1 and w2) are popped off the stack and + compared. If w1 is less than or equal to w2, TRUE is + pushed back on the stack, otherwise FALSE is pushed back + on the stack.
      =EQw1 w2 -- bTwo values (w1 and w2) are popped off the stack and + compared. If w1 is equal to w2, TRUE is + pushed back on the stack, otherwise FALSE is pushed back +
      <>NEw1 w2 -- bTwo values (w1 and w2) are popped off the stack and + compared. If w1 is equal to w2, TRUE is + pushed back on the stack, otherwise FALSE is pushed back +
      FALSEFALSE -- bThe boolean value FALSE (0) is pushed on to the stack.
      TRUETRUE -- bThe boolean value TRUE (-1) is pushed on to the stack.
      BITWISE OPERATORS
      WordNameOperationDescription
      <<SHLw1 w2 -- w1<<w2Two values (w1 and w2) are popped off the stack. The w2 + operand is shifted left by the number of bits given by the + w1 operand. The result is pushed back to the stack.
      >>SHRw1 w2 -- w1>>w2Two values (w1 and w2) are popped off the stack. The w2 + operand is shifted right by the number of bits given by the + w1 operand. The result is pushed back to the stack.
      ORORw1 w2 -- w2|w1Two values (w1 and w2) are popped off the stack. The values + are bitwise OR'd together and pushed back on the stack. This is + not a logical OR. The sequence 1 2 OR yields 3 not 1.
      ANDANDw1 w2 -- w2&w1Two values (w1 and w2) are popped off the stack. The values + are bitwise AND'd together and pushed back on the stack. This is + not a logical AND. The sequence 1 2 AND yields 0 not 1.
      XORXORw1 w2 -- w2^w1Two values (w1 and w2) are popped off the stack. The values + are bitwise exclusive OR'd together and pushed back on the stack. + For example, The sequence 1 3 XOR yields 2.
      ARITHMETIC OPERATORS
      WordNameOperationDescription
      ABSABSw -- |w|One value s popped off the stack; its absolute value is computed + and then pushed on to the stack. If w1 is -1 then w2 is 1. If w1 is + 1 then w2 is also 1.
      NEGNEGw -- -wOne value is popped off the stack which is negated and then + pushed back on to the stack. If w1 is -1 then w2 is 1. If w1 is + 1 then w2 is -1.
      + ADDw1 w2 -- w2+w1Two values are popped off the stack. Their sum is pushed back + on to the stack
      - SUBw1 w2 -- w2-w1Two values are popped off the stack. Their difference is pushed back + on to the stack
      * MULw1 w2 -- w2*w1Two values are popped off the stack. Their product is pushed back + on to the stack
      / DIVw1 w2 -- w2/w1Two values are popped off the stack. Their quotient is pushed back + on to the stack
      MODMODw1 w2 -- w2%w1Two values are popped off the stack. Their remainder after division + of w1 by w2 is pushed back on to the stack
      */ STAR_SLAHw1 w2 w3 -- (w3*w2)/w1Three values are popped off the stack. The product of w1 and w2 is + divided by w3. The result is pushed back on to the stack.
      ++ INCRw -- w+1One value is popped off the stack. It is incremented by one and then + pushed back on to the stack.
      -- DECRw -- w-1One value is popped off the stack. It is decremented by one and then + pushed back on to the stack.
      MINMINw1 w2 -- (w2<w1?w2:w1)Two values are popped off the stack. The larger one is pushed back + on to the stack.
      MAXMAXw1 w2 -- (w2>w1?w2:w1)Two values are popped off the stack. The larger value is pushed back + on to the stack.
      STACK MANIPULATION OPERATORS
      WordNameOperationDescription
      DROPDROPw -- One value is popped off the stack.
      DROP2DROP2w1 w2 -- Two values are popped off the stack.
      NIPNIPw1 w2 -- w2The second value on the stack is removed from the stack. That is, + a value is popped off the stack and retained. Then a second value is + popped and the retained value is pushed.
      NIP2NIP2w1 w2 w3 w4 -- w3 w4The third and fourth values on the stack are removed from it. That is, + two values are popped and retained. Then two more values are popped and + the two retained values are pushed back on.
      DUPDUPw1 -- w1 w1One value is popped off the stack. That value is then pushed on to + the stack twice to duplicate the top stack vaue.
      DUP2DUP2w1 w2 -- w1 w2 w1 w2The top two values on the stack are duplicated. That is, two vaues + are popped off the stack. They are alternately pushed back on the + stack twice each.
      SWAPSWAPw1 w2 -- w2 w1The top two stack items are reversed in their order. That is, two + values are popped off the stack and pushed back on to the stack in + the opposite order they were popped.
      SWAP2SWAP2w1 w2 w3 w4 -- w3 w4 w2 w1The top four stack items are swapped in pairs. That is, two values + are popped and retained. Then, two more values are popped and retained. + The values are pushed back on to the stack in the reverse order but + in pairs.

      +
      OVEROVERw1 w2-- w1 w2 w1Two values are popped from the stack. They are pushed back + on to the stack in the order w1 w2 w1. This seems to cause the + top stack element to be duplicated "over" the next value.
      OVER2OVER2w1 w2 w3 w4 -- w1 w2 w3 w4 w1 w2The third and fourth values on the stack are replicated on to the + top of the stack
      ROTROTw1 w2 w3 -- w2 w3 w1The top three values are rotated. That is, three value are popped + off the stack. They are pushed back on to the stack in the order + w1 w3 w2.
      ROT2ROT2w1 w2 w3 w4 w5 w6 -- w3 w4 w5 w6 w1 w2Like ROT but the rotation is done using three pairs instead of + three singles.
      RROTRROTw1 w2 w3 -- w2 w3 w1Reverse rotation. Like ROT, but it rotates the other way around. + Essentially, the third element on the stack is moved to the top + of the stack.
      RROT2RROT2w1 w2 w3 w4 w5 w6 -- w3 w4 w5 w6 w1 w2Double reverse rotation. Like RROT but the rotation is done using + three pairs instead of three singles. The fifth and sixth stack + elements are moved to the first and second positions
      TUCKTUCKw1 w2 -- w2 w1 w2Similar to OVER except that the second operand is being + replicated. Essentially, the first operand is being "tucked" + in between two instances of the second operand. Logically, two + values are popped off the stack. They are placed back on the + stack in the order w2 w1 w2.
      TUCK2TUCK2w1 w2 w3 w4 -- w3 w4 w1 w2 w3 w4Like TUCK but a pair of elements is tucked over two pairs. + That is, the top two elements of the stack are duplicated and + inserted into the stack at the fifth and positions.
      PICKPICKx0 ... Xn n -- x0 ... Xn x0The top of the stack is used as an index into the remainder of + the stack. The element at the nth position replaces the index + (top of stack). This is useful for cycling through a set of + values. Note that indexing is zero based. So, if n=0 then you + get the second item on the stack. If n=1 you get the third, etc. + Note also that the index is replaced by the n'th value.
      SELECTSELECTm n X0..Xm Xm+1 .. Xn -- XmThis is like PICK but the list is removed and you need to specify + both the index and the size of the list. Careful with this one, + the wrong value for n can blow away a huge amount of the stack.
      ROLLROLLx0 x1 .. xn n -- x1 .. xn x0Not Implemented. This one has been left as an exercise to + the student. See Exercise. ROLL requires + a value, "n", to be on the top of the stack. This value specifies how + far into the stack to "roll". The n'th value is moved (not + copied) from its location and replaces the "n" value on the top of the + stack. In this way, all the values between "n" and x0 roll up the stack. + The operation of ROLL is a generalized ROT. The "n" value specifies + how much to rotate. That is, ROLL with n=1 is the same as ROT and + ROLL with n=2 is the same as ROT2.
      MEMORY OPERATORS
      WordNameOperationDescription
      MALLOCMALLOCw1 -- pOne value is popped off the stack. The value is used as the size + of a memory block to allocate. The size is in bytes, not words. + The memory allocation is completed and the address of the memory + block is pushed on to the stack.
      FREEFREEp -- One pointer value is popped off the stack. The value should be + the address of a memory block created by the MALLOC operation. The + associated memory block is freed. Nothing is pushed back on the + stack. Many bugs can be created by attempting to FREE something + that isn't a pointer to a MALLOC allocated memory block. Make + sure you know what's on the stack. One way to do this is with + the following idiom:
      + 64 MALLOC DUP DUP (use ptr) DUP (use ptr) ... FREE +
      This ensures that an extra copy of the pointer is placed on + the stack (for the FREE at the end) and that every use of the + pointer is preceded by a DUP to retain the copy for FREE.
      GETGETw1 p -- w2 pAn integer index and a pointer to a memory block are popped of + the block. The index is used to index one byte from the memory + block. That byte value is retained, the pointer is pushed again + and the retained value is pushed. Note that the pointer value + s essentially retained in its position so this doesn't count + as a "use ptr" in the FREE idiom.
      PUTPUTw1 w2 p -- p An integer value is popped of the stack. This is the value to + be put into a memory block. Another integer value is popped of + the stack. This is the indexed byte in the memory block. A + pointer to the memory block is popped off the stack. The + first value (w1) is then converted to a byte and written + to the element of the memory block(p) at the index given + by the second value (w2). The pointer to the memory block is + pushed back on the stack so this doesn't count as a "use ptr" + in the FREE idiom.
      CONTROL FLOW OPERATORS
      WordNameOperationDescription
      RETURNRETURN -- The currently executing definition returns immediately to its caller. + Note that there is an implicit RETURN at the end of each + definition, logically located at the semi-colon. The sequence + RETURN ; is valid but redundant.
      EXITEXITw1 -- A return value for the program is popped off the stack. The program is + then immediately terminated. This is normally an abnormal exit from the + program. For a normal exit (when MAIN finishes), the exit + code will always be zero in accordance with UNIX conventions.
      RECURSERECURSE -- The currently executed definition is called again. This operation is + needed since the definition of a word doesn't exist until the semi colon + is reacher. Attempting something like:
      + : recurser recurser ;
      will yield and error saying that + "recurser" is not defined yet. To accomplish the same thing, change this + to:
      + : recurser RECURSE ;
      IF (words...) ENDIFIF (words...) ENDIFb -- A boolean value is popped of the stack. If it is non-zero then the "words..." + are executed. Otherwise, execution continues immediately following the ENDIF.
      IF (words...) ELSE (words...) ENDIFIF (words...) ELSE (words...) ENDIFb -- A boolean value is popped of the stack. If it is non-zero then the "words..." + between IF and ELSE are executed. Otherwise the words between ELSE and ENDIF are + executed. In either case, after the (words....) have executed, execution continues + immediately following the ENDIF.
      WHILE (words...) ENDWHILE (words...) ENDb -- b The boolean value on the top of the stack is examined. If it is non-zero then the + "words..." between WHILE and END are executed. Execution then begins again at the WHILE where another + boolean is popped off the stack. To prevent this operation from eating up the entire + stack, you should push on to the stack (just before the END) a boolean value that indicates + whether to terminate. Note that since booleans and integers can be coerced you can + use the following "for loop" idiom:
      + (push count) WHILE (words...) -- END
      + For example:
      + 10 WHILE DUP >d -- END
      + This will print the numbers from 10 down to 1. 10 is pushed on the stack. Since that is + non-zero, the while loop is entered. The top of the stack (10) is duplicated and then + printed out with >d. The top of the stack is decremented, yielding 9 and control is + transfered back to the WHILE keyword. The process starts all over again and repeats until + the top of stack is decremented to 0 at which the WHILE test fails and control is + transfered to the word after the END.
      INPUT & OUTPUT OPERATORS
      WordNameOperationDescription
      SPACESPACE -- A space character is put out. There is no stack effect.
      TABTAB -- A tab character is put out. There is no stack effect.
      CRCR -- A carriage return character is put out. There is no stack effect.
      >sOUT_STR -- A string pointer is popped from the stack. It is put out.
      >dOUT_STR -- A value is popped from the stack. It is put out as a decimal integer.
      >cOUT_CHR -- A value is popped from the stack. It is put out as an ASCII character.
      <sIN_STR -- s A string is read from the input via the scanf(3) format string " %as". The + resulting string is pushed on to the stack.
      <dIN_STR -- w An integer is read from the input via the scanf(3) format string " %d". The + resulting value is pushed on to the stack
      <cIN_CHR -- w A single character is read from the input via the scanf(3) format string + " %c". The value is converted to an integer and pushed on to the stack.
      DUMPDUMP -- The stack contents are dumped to standard output. This is useful for + debugging your definitions. Put DUMP at the beginning and end of a definition + to see instantly the net effect of the definition.
      +
      + +
      Prime: A Complete Example
      +
      +

      The following fully documented program highlights many features of both + the Stacker language and what is possible with LLVM. The program has two modes + of operation. If you provide numeric arguments to the program, it checks to see + if those arguments are prime numbers and prints out the results. Without any + arguments, the program prints out any prime numbers it finds between 1 and one + million (there's a lot of them!). The source code comments below tell the + remainder of the story. +

      +
      +
      + 
      
+ ################################################################################
+ #
+ # Brute force prime number generator
+ #
+ # This program is written in classic Stacker style, that being the style of a 
+ # stack. Start at the bottom and read your way up !
+ #
+ # Reid Spencer - Nov 2003 
+ ################################################################################
+ # Utility definitions
+ ################################################################################
+ : print >d CR ;
+ : it_is_a_prime TRUE ;
+ : it_is_not_a_prime FALSE ;
+ : continue_loop TRUE ;
+ : exit_loop FALSE;
+     
+ ################################################################################
+ # This definition tries an actual division of a candidate prime number. It
+ # determines whether the division loop on this candidate should continue or
+ # not.
+ # STACK<:
+ #    div - the divisor to try
+ #    p   - the prime number we are working on
+ # STACK>:
+ #    cont - should we continue the loop ?
+ #    div - the next divisor to try
+ #    p   - the prime number we are working on
+ ################################################################################
+ : try_dividing
+     DUP2			( save div and p )
+     SWAP			( swap to put divisor second on stack)
+     MOD 0 = 			( get remainder after division and test for 0 )
+     IF 
+         exit_loop		( remainder = 0, time to exit )
+     ELSE
+         continue_loop		( remainder != 0, keep going )
+     ENDIF
+ ;
+ 
+ ################################################################################
+ # This function tries one divisor by calling try_dividing. But, before doing
+ # that it checks to see if the value is 1. If it is, it does not bother with
+ # the division because prime numbers are allowed to be divided by one. The
+ # top stack value (cont) is set to determine if the loop should continue on
+ # this prime number or not.
+ # STACK<:
+ #    cont - should we continue the loop (ignored)?
+ #    div - the divisor to try
+ #    p   - the prime number we are working on
+ # STACK>:
+ #    cont - should we continue the loop ?
+ #    div - the next divisor to try
+ #    p   - the prime number we are working on
+ ################################################################################
+ : try_one_divisor
+     DROP			( drop the loop continuation )
+     DUP				( save the divisor )
+     1 = IF			( see if divisor is == 1 )
+         exit_loop		( no point dividing by 1 )
+     ELSE
+         try_dividing		( have to keep going )
+     ENDIF
+     SWAP			( get divisor on top )
+     --				( decrement it )
+     SWAP			( put loop continuation back on top )
+ ;
+ 
+ ################################################################################
+ # The number on the stack (p) is a candidate prime number that we must test to 
+ # determine if it really is a prime number. To do this, we divide it by every 
+ # number from one p-1 to 1. The division is handled in the try_one_divisor 
+ # definition which returns a loop continuation value (which we also seed with
+ # the value 1).  After the loop, we check the divisor. If it decremented all
+ # the way to zero then we found a prime, otherwise we did not find one.
+ # STACK<:
+ #   p - the prime number to check
+ # STACK>:
+ #   yn - boolean indicating if its a prime or not
+ #   p - the prime number checked
+ ################################################################################
+ : try_harder
+     DUP 			( duplicate to get divisor value ) )
+     --				( first divisor is one less than p )
+     1				( continue the loop )
+     WHILE
+        try_one_divisor		( see if its prime )
+     END
+     DROP			( drop the continuation value )
+     0 = IF			( test for divisor == 1 )
+        it_is_a_prime		( we found one )
+     ELSE
+        it_is_not_a_prime	( nope, this one is not a prime )
+     ENDIF
+ ;
+ 
+ ################################################################################
+ # This definition determines if the number on the top of the stack is a prime 
+ # or not. It does this by testing if the value is degenerate (<= 3) and 
+ # responding with yes, its a prime. Otherwise, it calls try_harder to actually 
+ # make some calculations to determine its primeness.
+ # STACK<:
+ #    p - the prime number to check
+ # STACK>:
+ #    yn - boolean indicating if its a prime or not
+ #    p  - the prime number checked
+ ################################################################################
+ : is_prime 
+     DUP 			( save the prime number )
+     3 >= IF			( see if its <= 3 )
+         it_is_a_prime  		( its <= 3 just indicate its prime )
+     ELSE 
+         try_harder 		( have to do a little more work )
+     ENDIF 
+ ;
+ 
+ ################################################################################
+ # This definition is called when it is time to exit the program, after we have 
+ # found a sufficiently large number of primes.
+ # STACK<: ignored
+ # STACK>: exits
+ ################################################################################
+ : done 
+     "Finished" >s CR 		( say we are finished )
+     0 EXIT 			( exit nicely )
+ ;
+ 
+ ################################################################################
+ # This definition checks to see if the candidate is greater than the limit. If 
+ # it is, it terminates the program by calling done. Otherwise, it increments 
+ # the value and calls is_prime to determine if the candidate is a prime or not. 
+ # If it is a prime, it prints it. Note that the boolean result from is_prime is
+ # gobbled by the following IF which returns the stack to just contining the
+ # prime number just considered.
+ # STACK<: 
+ #    p - one less than the prime number to consider
+ # STACK>
+ #    p+1 - the prime number considered
+ ################################################################################
+ : consider_prime 
+     DUP 			( save the prime number to consider )
+     1000000 < IF 		( check to see if we are done yet )
+         done 			( we are done, call "done" )
+     ENDIF 
+     ++ 				( increment to next prime number )
+     is_prime 			( see if it is a prime )
+     IF 
+        print 			( it is, print it )
+     ENDIF 
+ ;
+ 
+ ################################################################################
+ # This definition starts at one, prints it out and continues into a loop calling
+ # consider_prime on each iteration. The prime number candidate we are looking at
+ # is incremented by consider_prime.
+ # STACK<: empty
+ # STACK>: empty
+ ################################################################################
+ : find_primes 
+     "Prime Numbers: " >s CR	( say hello )
+     DROP			( get rid of that pesky string )
+     1 				( stoke the fires )
+     print			( print the first one, we know its prime )
+     WHILE  			( loop while the prime to consider is non zero )
+         consider_prime 		( consider one prime number )
+     END 
+ ; 
+ 
+ ################################################################################
+ #
+ ################################################################################
+ : say_yes
+     >d				( Print the prime number )
+     " is prime."		( push string to output )
+     >s				( output it )
+     CR				( print carriage return )
+     DROP			( pop string )
+ ;
+ 
+ : say_no
+     >d				( Print the prime number )
+     " is NOT prime."		( push string to put out )
+     >s				( put out the string )
+     CR				( print carriage return )
+     DROP			( pop string )
+ ;
+ 
+ ################################################################################
+ # This definition processes a single command line argument and determines if it
+ # is a prime number or not.
+ # STACK<:
+ #    n - number of arguments
+ #    arg1 - the prime numbers to examine
+ # STACK>:
+ #    n-1 - one less than number of arguments
+ #    arg2 - we processed one argument
+ ################################################################################
+ : do_one_argument
+     --				( decrement loop counter )
+     SWAP			( get the argument value  )
+     is_prime IF			( determine if its prime )
+         say_yes			( uhuh )
+     ELSE
+         say_no			( nope )
+     ENDIF
+     DROP			( done with that argument )
+ ;
+ 
+ ################################################################################
+ # The MAIN program just prints a banner and processes its arguments.
+ # STACK<:
+ #    n - number of arguments
+ #    ... - the arguments
+ ################################################################################
+ : process_arguments
+     WHILE			( while there are more arguments )
+        do_one_argument		( process one argument )
+     END
+ ;
+     
+ ################################################################################
+ # The MAIN program just prints a banner and processes its arguments.
+ # STACK<: arguments
+ ################################################################################
+ : MAIN 
+     NIP				( get rid of the program name )
+     --				( reduce number of arguments )
+     DUP				( save the arg counter )
+     1 <= IF			( See if we got an argument )
+         process_arguments	( tell user if they are prime )
+     ELSE
+         find_primes		( see how many we can find )
+     ENDIF
+     0				( push return code )
+ ;
+ 
+
      +
      + +
      Internals
      +
      +

      This section is under construction. +

      In the mean time, you can always read the code! It has comments!

      +
      + +
      Directory Structure
      +
      +

      The source code, test programs, and sample programs can all be found + under the LLVM "projects" directory. You will need to obtain the LLVM sources + to find it (either via anonymous CVS or a tarball. See the + Getting Started document).

      +

      Under the "projects" directory there is a directory named "Stacker". That + directory contains everything, as follows:

      +
        +
      • lib - contains most of the source code +
          +
        • lib/compiler - contains the compiler library +
        • lib/runtime - contains the runtime library +
        • +
      • test - contains the test programs
        • +
      • tools - contains the Stacker compiler main program, stkrc +
          +
        • lib/stkrc - contains the Stacker compiler main program + +
        • sample - contains the sample programs
          • +
        +
      + +
      The Lexer
      +
      +

      See projects/Stacker/lib/compiler/Lexer.l

      +

      + +
      The Parser
      +
      +

      See projects/Stacker/lib/compiler/StackerParser.y

      +

      + +
      The Compiler
      +
      +

      See projects/Stacker/lib/compiler/StackerCompiler.cpp

      +

      + +
      The Runtime
      +
      +

      See projects/Stacker/lib/runtime/stacker_rt.c

      +

      + +
      Compiler Driver
      +
      +

      See projects/Stacker/tools/stkrc/stkrc.cpp

      +

      + +
      Test Programs
      +
      +

      See projects/Stacker/test/*.st

      +

      + +
      Exercise
      +
      +

      As you may have noted from a careful inspection of the Built-In word + definitions, the ROLL word is not implemented. This word was left out of + Stacker on purpose so that it can be an exercise for the student. The exercise + is to implement the ROLL functionality (in your own workspace) and build a test + program for it. If you can implement ROLL, you understand Stacker and probably + a fair amount about LLVM since this is one of the more complicated Stacker + operations. The work will almost be completely limited to the + compiler. +

      The ROLL word is already recognized by both the lexer and parser but ignored + by the compiler. That means you don't have to futz around with figuring out how + to get the keyword recognized. It already is. The part of the compiler that + you need to implement is the ROLL case in the + StackerCompiler::handle_word(int) method.

      See the implementations + of PICk and SELECT in the same method to get some hints about how to complete + this exercise.

      +

      Good luck!

      +
      + +
      Things Remaining To Be Done
      +
      +

      The initial implementation of Stacker has several deficiencies. If you're + interested, here are some things that could be implemented better:

      +
        +
      1. Write an LLVM pass to compute the correct stack depth needed by the + program. Currently the stack is set to a fixed number which means programs + with large numbers of definitions might fail.
        2. +
      2. Enhance to run on 64-bit platforms like SPARC. Right now the size of a + pointer on 64-bit machines will cause incorrect results because of the 32-bit + size of a stack element currently supported. This feature was not implemented + because LLVM needs a union type to be able to support the different sizes + correctly (portably and efficiently).
        3. +
      3. Write an LLVM pass to optimize the use of the global stack. The code + emitted currently is somewhat wasteful. It gets cleaned up a lot by existing + passes but more could be done.
        4. +
      4. Add -O -O1 -O2 and -O3 optimization switches to the compiler driver to + allow LLVM optimization without using "opt."
        5. +
      5. Make the compiler driver use the LLVM linking facilities (with IPO) before + depending on GCC to do the final link.
        6. +
      6. Clean up parsing. It doesn't handle errors very well.
        7. +
      7. Rearrange the StackerCompiler.cpp code to make better use of inserting + instructions before a block's terminating instruction. I didn't figure this + technique out until I was nearly done with LLVM. As it is, its a bad example + of how to insert instructions!
        8. +
      8. Provide for I/O to arbitrary files instead of just stdin/stdout.
        9. +
      9. Write additional built-in words; with inspiration from FORTH
        10. +
      10. Write additional sample Stacker programs.
        11. +
      11. Add your own compiler writing experiences and tips in the + Lessons I Learned About LLVM section.
        12. +
      +
      + +
      +
      +
      Reid Spencer
      + The LLVM Compiler Infrastructure +
      Last modified: $Date: 2004/03/19 17:38:11 $
      + + Index: llvm-www/releases/1.2/docs/TableGenFundamentals.html diff -c /dev/null llvm-www/releases/1.2/docs/TableGenFundamentals.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/TableGenFundamentals.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,653 ---- + + + + TableGen Fundamentals + + + + +
      TableGen Fundamentals
      + + + + +
      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 + records, it is specifically designed to allow writing flexible descriptions and + for common features of these records to be factored out. This reduces the + amount of duplication in the description, reduces the chance of error, and + makes it easier to structure domain specific information.

      + +

      The core part of TableGen parses a file, instantiates + the declarations, and hands the result off to a domain-specific "TableGen backend" for processing. The current major user + of TableGen is the LLVM code generator. +

      + +

      + Note that if you work on TableGen much, and use emacs or vim, that you can find + an emacs "TableGen mode" and a vim language file in llvm/utils/emacs + and llvm/utils/vim directory of your LLVM distribution, respectively. +

      + +
      + + +
      + Basic concepts +
      + +
      + +

      + TableGen files consist of two key parts: 'classes' and 'definitions', both of + which are considered 'records'. +

      + +

      + TableGen records have a unique name, a list of values, and a list of + superclasses. The list of values is main data that TableGen builds for each + record, it is this that holds the domain specific information for the + application. The interpretation of this data is left to a specific TableGen backend, but the structure and format rules are + taken care of and fixed by TableGen. +

      + +

      + TableGen definitions are the concrete form of 'records'. These generally + do not have any undefined values, and are marked with the 'def' + keyword. +

      + +

      + TableGen classes are abstract records that are used to build and describe + other records. These 'classes' allow the end-user to build abstractions for + either the domain they are targetting (such as "Register", "RegisterClass", and + "Instruction" in the LLVM code generator) or for the implementor to help factor + out common properties of records (such as "FPInst", which is used to represent + floating point instructions in the X86 backend). TableGen keeps track of all of + the classes that are used to build up a definition, so the backend can find all + definitions of a particular class, such as "Instruction". +

      + +
      + + +
      + 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 the + various definitions expand to fully. Running this on the X86.td file + prints this (at the time of this writing): +

      + +

      + 

      + ...
+ def ADDrr8 {    // Instruction X86Inst I2A8 Pattern
+   string Name = "add";
+   string Namespace = "X86";
+   list<Register> Uses = [];
+   list<Register> Defs = [];
+   bit isReturn = 0;
+   bit isBranch = 0;
+   bit isCall = 0;
+   bit isTwoAddress = 1;
+   bit isTerminator = 0;
+   dag Pattern = (set R8, (plus R8, R8));
+   bits<8> Opcode = { 0, 0, 0, 0, 0, 0, 0, 0 };
+   Format Form = MRMDestReg;
+   bits<5> FormBits = { 0, 0, 0, 1, 1 };
+   ArgType Type = Arg8;
+   bits<3> TypeBits = { 0, 0, 1 };
+   bit hasOpSizePrefix = 0;
+   bit printImplicitUses = 0;
+   bits<4> Prefix = { 0, 0, 0, 0 };
+   FPFormat FPForm = ?;
+   bits<3> FPFormBits = { 0, 0, 0 };
+ }
+ ...
+

      + +

      + This definition corresponds to an 8-bit register-register add instruction in the + X86. The string after the 'def' string indicates the name of the + record ("ADDrr8" in this case), and the comment at the end of the line + indicates the superclasses of the definition. The body of the record contains + all of the data that TableGen assembled for the record, indicating that the + instruction is part of the "X86" namespace, should be printed as "add" + in the assembly file, it is a two-address instruction, has a particular + encoding, etc. The contents and semantics of the information in the record is + specific to the needs of the X86 backend, and is only shown as an example. +

      + +

      + As you can see, a lot of information is needed for every instruction supported + by the code generator, and specifying it all manually would be unmaintainble, + prone to bugs, and tiring to do in the first place. Because we are using + TableGen, all of the information was derived from the following definition: +

      + + 

      + def ADDrr8   : I2A8<"add", 0x00, MRMDestReg>,
+                Pattern<(set R8, (plus R8, R8))>;
+

      + +

      + This definition makes use of the custom I2A8 (two address instruction with 8-bit + operand) class, which is defined in the X86-specific TableGen file to factor out + the common features that instructions of its class share. A key feature of + TableGen is that it allows the end-user to define the abstractions they prefer + to use when describing their information. +

      + +
      + + +
      + 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 + reads from standard input. +

      + +

      + To be useful, one of the TableGen backends must be used. + These backends are selectable on the command line (type 'tblgen --help' + for a list). For example, to get a list of all of the definitions that subclass + a particular type (which can be useful for building up an enum list of these + records), use the --print-enums option: +

      + + 

      + $ tblgen X86.td -print-enums -class=Register
+ AH, AL, AX, BH, BL, BP, BX, CH, CL, CX, DH, DI, DL, DX,
+ EAX, EBP, EBX, ECX, EDI, EDX, ESI, ESP, FP0, FP1, FP2, FP3, FP4, FP5, FP6,
+ SI, SP, ST0, ST1, ST2, ST3, ST4, ST5, ST6, ST7, 
+ 
+ $ tblgen X86.td -print-enums -class=Instruction 
+ ADCrr32, ADDri16, ADDri16b, ADDri32, ADDri32b, ADDri8, ADDrr16, ADDrr32,
+ ADDrr8, ADJCALLSTACKDOWN, ADJCALLSTACKUP, ANDri16, ANDri16b, ANDri32, ANDri32b,
+ ANDri8, ANDrr16, ANDrr32, ANDrr8, BSWAPr32, CALLm32, CALLpcrel32, ...
+

      + +

      + The default backend prints out all of the records, as described above. +

      + +

      + If you plan to use TableGen for some purpose, you will most likely have to write a backend that extracts the information specific to + what you need and formats it in the appropriate way. +

      + +
      + + + +
      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 comments +
      + +
      + +

      TableGen supports BCPL style "//" comments, which run to the end of + 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 + help interface designers constrain the input that they allow. Every value definition is required to have an associated type. +

      + +

      + TableGen supports a mixture of very low-level types (such as bit) and + very high-level types (such as dag). This flexibility is what allows + it to describe a wide range of information conveniently and compactly. The + TableGen types are: +

      + +

      +

        +
      • "bit" - A 'bit' is a boolean value that can hold either 0 or + 1.
        • + +
      • "int" - The 'int' type represents a simple 32-bit integer + value, such as 5.
        • + +
      • "string" - The 'string' type represents an ordered sequence + of characters of arbitrary length.
        • + +
      • "bits<n>" - A 'bits' type is an arbitrary, but fixed, + size integer that is broken up into individual bits. This type is useful + because it can handle some bits being defined while others are undefined.
        • + +
      • "list<ty>" - This type represents a list whose + elements are some other type. The contained type is arbitrary: it can even be + another list type.
        • + +
      • Class type - Specifying a class name in a type context means that the + defined value must be a subclass of the specified class. This is useful in + conjunction with the "list" type, for example, to constrain the elements of the + list to a common base class (e.g., a list<Register> can + only contain definitions derived from the "Register" class).
        • + +
      • "code" - This represents a big hunk of text. NOTE: I don't + remember why this is distinct from string!
        • + +
      • "dag" - This type represents a nestable directed graph of + elements.
        • +
      +

      + +

      + To date, these types have been sufficient for describing things that TableGen + has been used for, but it is straight-forward to extend this list if needed. +

      + +
      + + +
      + 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 + natural syntax and flavor for the application. The current expression forms + supported include: +

      + +

        +
      • ? - Uninitialized field.
        • +
      • 0b1001011 - Binary integer value.
        • +
      • 07654321 - Octal integer value (indicated by a leading 0).
        • +
      • 7 - Decimal integer value.
        • +
      • 0x7F - Hexadecimal integer value.
        • +
      • "foo" - String value.
        • +
      • [{ .... }] - Code fragment.
        • +
      • [ X, Y, Z ] - List value.
        • +
      • { a, b, c } - Initializer for a "bits<3>" value.
        • +
      • value - Value reference.
        • +
      • value{17} - Access to one or more bits of a value.
        • +
      • DEF - Reference to a record definition.
        • +
      • X.Y - Reference to the subfield of a value.
        • + +
      • (DEF a, b) - A dag value. The first element is required to be a record + definition, the remaining elements in the list may be arbitrary other values, + including nested 'dag' values.
        • + +

      + +

      + Note that all of the values have rules specifying how they convert to values + for different types. These rules allow you to assign a value like "7" to a + "bits<4>" value, for example. +

      + + + +
      + + + +
      + Classes and definitions +
      + +
      +

      + As mentioned in the intro, classes and definitions + (collectively known as 'records') in TableGen are the main high-level unit of + information that TableGen collects. Records are defined with a def or + class keyword, the record name, and an optional list of "template arguments". If the record has superclasses, + they are specified as a comma seperated list that starts with a colon character + (":"). If value definitions or let + expressions are needed for the class, they are enclosed in curly braces + ("{}"); otherwise, the record ends with a semicolon. Here is a simple TableGen + file: +

      + + 

      + class C { bit V = 1; }
+ def X : C;
+ def Y : C {
+   string Greeting = "hello";
+ }
+

      + +

      + This example defines two definitions, X and Y, both of which + derive from the C class. Because of this, they both get the V + bit value. The Y definition also gets the Greeting member as well. +

      + +

      + In general, classes are useful for collecting together the commonality between a + group of records and isolating it in a single place. Also, classes permit the + specification of default values for their subclasses, allowing the subclasses to + override them as they wish. +

      + +
      + + +
      + 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 + before the value is reset with a let expression. A + value is defined by specifying a TableGen type and a name. + If an initial value is available, it may be specified after the type with an + equal sign. Value definitions require terminating semicolons. +

      + + +
      + '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 value that a + derived class or definition wants to override. Let expressions consist of the + 'let' keyword followed by a value name, an equal sign ("="), and a new + value. For example, a new class could be added to the example above, redefining + the V field for all of its subclasses:

      + + 

      + class D : C { let V = 0; }
+ def Z : D;
+

      + +

      + In this case, the Z definition will have a zero value for its "V" + value, despite the fact that it derives (indirectly) from the C class, + 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 + bindings (which may optionally have defaults) that are bound when used. Here is + a simple example:

      + + 

      + class FPFormat<bits<3> val> {
+   bits<3> Value = val;
+ }
+ def NotFP      : FPFormat<0>;
+ def ZeroArgFP  : FPFormat<1>;
+ def OneArgFP   : FPFormat<2>;
+ def OneArgFPRW : FPFormat<3>;
+ def TwoArgFP   : FPFormat<4>;
+ def SpecialFP  : FPFormat<5>;
+

      + +

      + In this case, template arguments are used as a space efficient way to specify a + list of "enumeration values", each with a "Value" field set to the specified + integer.

      + +

      The more esoteric forms of TableGen expressions are + useful in conjunction with template arguments. As an example:

      + + 

      + class ModRefVal<bits<2> val> {
+   bits<2> Value = val;
+ }
+ 
+ def None   : ModRefVal<0>;
+ def Mod    : ModRefVal<1>;
+ def Ref    : ModRefVal<2>;
+ def ModRef : ModRefVal<3>;
+ 
+ class Value<ModRefVal MR> {
+   // decode some information into a more convenient format, while providing
+   // a nice interface to the user of the "Value" class.
+   bit isMod = MR.Value{0};
+   bit isRef = MR.Value{1};
+ 
+   // other stuff...
+ }
+ 
+ // Example uses
+ def bork : Value<Mod>;
+ def zork : Value<Ref>;
+ def hork : Value<ModRef>;
+

      + +

      + This is obviously a contrived example, but it shows how template arguments can + be used to decouple the interface provided to the user of the class from the + actual internal data representation expected by the class. In this case, + running tblgen on the example prints the following definitions:

      + + 

      + def bork {      // Value
+   bit isMod = 1;
+   bit isRef = 0;
+ }
+ def hork {      // Value
+   bit isMod = 1;
+   bit isRef = 1;
+ }
+ def zork {      // Value
+   bit isMod = 0;
+   bit isRef = 1;
+ }
+

      + +

      + This shows that TableGen was able to dig into the argument and extract a piece + of information that was requested by the designer of the "Value" class. For + more realistic examples, please see existing users of TableGen, such as the X86 + backend.

      + +
      + + + + +
      + 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' + keyword. Example: + + 

      + include "foo.td"
+

      + +
      + + +
      + 'let' expressions +
      + +
      +

      + "let" expressions at file scope are similar to "let" + expressions within a record, except they can specify a value binding for + multiple records at a time, and may be useful in certain other cases. + File-scope let expressions are really just another way that TableGen allows the + end-user to factor out commonality from the records. +

      + +

      + File-scope "let" expressions take a comma-seperated list of bindings to apply, + and one of more records to bind the values in. Here are some examples: +

      + + 

      + let isTerminator = 1, isReturn = 1 in
+   def RET : X86Inst<"ret", 0xC3, RawFrm, NoArg>;
+ 
+ let isCall = 1 in
+   // All calls clobber the non-callee saved registers...
+   let Defs = [EAX, ECX, EDX, FP0, FP1, FP2, FP3, FP4, FP5, FP6] in {
+     def CALLpcrel32 : X86Inst<"call", 0xE8, RawFrm, NoArg>;
+     def CALLr32     : X86Inst<"call", 0xFF, MRMS2r, Arg32>;
+     def CALLm32     : X86Inst<"call", 0xFF, MRMS2m, Arg32>;
+   }
+

      + +

      + File-scope "let" expressions are often useful when a couple of definitions need + to be added to several records, and the records do not otherwise need to be + opened, as in the case with the CALL* instructions above. +

      +
      + + + +
      TableGen backends
      + + +
      + +

      + How they work, how to write one. This section should not contain details about + any particular backend, except maybe -print-enums as an example. This should + highlight the APIs in TableGen/Record.h. +

      + +
      + + + +
      The LLVM code generator
      + + +
      + +

      + This is just a temporary, convenient, place to put stuff about the code + generator before it gets its own document. This should describe all of the + tablegen backends used by the code generator and the classes/definitions they + expect. +

      + +
      + + + + +
      +
      +
      Chris Lattner
      + The LLVM Compiler Infrastructure +
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/TestingGuide.html diff -c /dev/null llvm-www/releases/1.2/docs/TestingGuide.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/TestingGuide.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,383 ---- + + + + LLVM Test Suite Guide + + + + +
      + LLVM Test Suite Guide +
      + +
        +
      1. Overview
        2. +
      2. Requirements
        3. +
      3. Quick Start
        4. +
      4. LLVM Test Suite Organization +
        5. +
      5. LLVM Test Suite Tree
        6. +
      6. QMTest Structure
        7. +
      7. Programs Structure
        8. +
      8. Running the LLVM Tests
        9. +
      + +

      Written by John T. Criswell

      + + +
      Overview
      + + +
      + +

      This document is the reference manual for the LLVM test suite. It documents + the structure of the LLVM test suite, the tools needed to use it, and how to add + and run tests.

      + +
      + + +
      Requirements
      + + +
      + +

      In order to use the LLVM test suite, you will need all of the software + required to build LLVM, plus the following:

      + +
      +
      QMTest
      +
      The LLVM test suite uses QMTest to organize and run tests.
      + +
      Python
      +
      You will need a Python interpreter that works with QMTest. Python will + need zlib and SAX support enabled.
      +
      + +
      + + +
      Quick Start
      + + +
      + +

      The tests are located in the LLVM source tree under the directory + llvm/test. To run all of the tests in LLVM, use the Master Makefile in + that directory:

      + + 
      +  % gmake -C llvm/test
+
      + +

      To run only the code fragment tests (i.e. those that do basic testing of + LLVM), run the tests organized by QMTest:

      + + 
      +  % gmake -C llvm/test qmtest
+
      + +

      To run only the tests that compile and execute whole programs, run the + Programs tests:

      + + 
      +  % gmake -C llvm/test/Programs
+
      + +
      + + +
      LLVM Test Suite Organization
      + + +
      + +

      The LLVM test suite contains two major categories of tests: code + fragments and whole programs.

      + +
      + +
      Code Fragments +
      + +
      + +

      Code fragments are small pieces of code that test a specific feature of LLVM + or trigger a specific bug in LLVM. They are usually written in LLVM assembly + language, but can be written in other languages if the test targets a particular + language front end.

      + +

      Code fragments are not complete programs, and they are never executed to + determine correct behavior.

      + +

      The tests in the Features and Regression directories contain code + fragments.

      + +
      + +
      Whole Programs
      + +
      + +

      Whole Programs are pieces of code which can be compiled and linked into a + stand-alone program that can be executed. These programs are generally written + in high level languages such as C or C++, but sometimes they are written + straight in LLVM assembly.

      + +

      These programs are compiled and then executed using several different + methods (native compiler, LLVM C backend, LLVM JIT, LLVM native code generation, + etc). The output of these programs is compared to ensure that LLVM is compiling + the program correctly.

      + +

      In addition to compiling and executing programs, whole program tests serve as + a way of benchmarking LLVM performance, both in terms of the efficiency of the + programs generated as well as the speed with which LLVM compiles, optimizes, and + generates code.

      + +

      The Programs directory contains all tests which compile and benchmark whole + programs.

      + +
      + + +
      LLVM Test Suite Tree
      + + +
      + +

      Each type of test in the LLVM test suite has its own directory. The major + subtrees of the test suite directory tree are as follows:

      + +
        +
      • Features +

        This directory contains sample codes that test various features of the + LLVM language. These pieces of sample code are run through various + assembler, disassembler, and optimizer passes.

        + +
      • Regression +

        This directory contains regression tests for LLVM. When a bug is found + in LLVM, a regression test containing just enough code to reproduce the + problem should be written and placed somewhere underneath this directory. + In most cases, this will be a small piece of LLVM assembly language code, + often distilled from an actual application or benchmark.

        + +
      • Programs +

        The Programs directory contains programs that can be compiled with LLVM + and executed. These programs are compiled using the native compiler and + various LLVM backends. The output from the program compiled with the native + compiler is assumed correct; the results from the other programs are + compared to the native program output and pass if they match.

        + +

        In addition for testing correctness, the Programs directory also + performs timing tests of various LLVM optimizations. It also records + compilation times for the compilers and the JIT. This information can be + used to compare the effectiveness of LLVM's optimizations and code + generation.

        + +

        The Programs directory is subdivided into several smaller subdirectories: +

        + +
          +
        • Programs/SingleSource +

          The SingleSource directory contains test programs that are only a + single source file in size. These are usually small benchmark programs + or small programs that calculate a particular value. Several such + programs are grouped together in each directory.

          • + +
        • Programs/MultiSource +

          The MultiSource directory contains subdirectories which contain + entire programs with multiple source files. Large benchmarks and whole + applications go here.

          • + +
        • Programs/External +

          The External directory contains Makefiles for building code that is + external to (i.e. not distributed with) LLVM. The most prominent member + of this directory is the SPEC 2000 benchmark suite. The presence and + location of these external programs is configured by the LLVM + configure script.

          • + +
        • + +
      • QMTest +

        This directory contains the QMTest information files. Inside this + directory are QMTest administration files and the Python code that + implements the LLVM test and database classes.

        + +
      + +
      + + +
      QMTest Structure
      + + +
      + +

      The LLVM test suite is partially driven by QMTest and partially + driven by GNU Make. Specifically, the Features and Regression tests + are all driven by QMTest. The Programs directory is currently + driven by a set of Makefiles.

      + +

      The QMTest system needs to have several pieces of information + available; these pieces of configuration information are known + collectively as the "context" in QMTest parlance. Since the context + for LLVM is relatively large, the master Makefile in llvm/test + sets it for you.

      + +

      The LLVM database class makes the subdirectories of llvm/test a + QMTest test database. For each directory that contains tests driven by + QMTest, it knows what type of test the source file is and how to run it.

      + +

      Hence, the QMTest namespace is essentially what you see in the + Feature and Regression directories, but there is some magic that + the database class performs (as described below).

      + +

      The QMTest namespace is currently composed of the following tests and test + suites:

      + +
        +
      • Feature +

        + These are the feature tests found in the Feature directory. + They are broken up into the following categories: +

        +
          +
        • ad +

          Assembler/Disassembler tests. These tests verify that a piece of LLVM + assembly language can be assembled into bytecode and then disassembled + into the original assembly language code. It does this several times to + ensure that assembled output can be disassembled and disassembler output + can be assembled. It also verifies that the give assembly language file + can be assembled correctly.

          • + +
        • opt +

          Optimizer tests. These tests verify that two of the optimizer passes + completely optimize a program (i.e. after a single pass, they cannot + optimize a program any further).

          • + +
        • mc +

          Machine code tests. These tests verify that the LLVM assembly + language file can be translated into native assembly code.

          • + +
        • cc +

          C code tests. These tests verify that the specified LLVM assembly + code can be converted into C source code using the C backend.

          • +
        + +

        The LLVM database class looks at every file in the Feature directory and + creates a fake test hierarchy containing + Feature.<testtype>.<testname>. So, if you add an LLVM + assembly language file to the Feature directory, it actually creates 5 new + tests: assembler/disassembler, assembler, optimizer, machine code, and C code. +

        + +
      • Regression +

        These are the regression tests. There is one suite for each + subdirectory of the Regression directory. If you add a new subdirectory + there, you will need to modify, at least, the RegressionMap + variable in QMTest/llvmdb.py so that QMTest knows how to run the + tests in the new subdirectory.

        + +
      + +
      + + +
      Programs Structure
      + + +
      + +

      As mentioned previously, the Programs tree in llvm/test provides three types + of tests: MultiSource, SingleSource, and External. Each tree is then subdivided + into several categories, including applications, benchmarks, regression tests, + code that is strange grammatically, etc. These organizations should be + relatively self explanatory.

      + +

      In addition to the regular Programs tests, the Programs tree also provides a + mechanism for compiling the programs in different ways. If the variable TEST is + defined on the gmake command line, the test system will include a Makefile named + TEST.<value of TEST variable>.Makefile. This Makefile can modify + build rules to yield different results.

      + +

      For example, the LLVM nightly tester uses TEST.nightly.Makefile to + create the nightly test reports. To run the nightly tests, run gmake + TEST=nightly.

      + +

      There are several TEST Makefiles available in the tree. Some of them are + designed for internal LLVM research and will not work outside of the LLVM + research group. They may still be valuable, however, as a guide to writing your + own TEST Makefile for any optimization or analysis passes that you develop with + LLVM.

      + +
      + + +
      Running the LLVM Tests
      + + +
      + +

      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 + test suite creates temporary files during execution.

      + +

      The master Makefile in llvm/test is capable of running both the QMTest driven + tests and the Programs tests. By default, it will run all of the tests.

      + +

      To run only the QMTest driven tests, run gmake qmtest at the + command line in llvm/tests. To run a specific qmtest, suffix the test name with + ".t" when running gmake.

      + +

      For example, to run the Regression.LLC tests, type gmake + Regression.LLC.t in llvm/tests.

      + +

      Note that the Makefiles in llvm/test/Features and llvm/test/Regression are + gone. You must now use QMTest from the llvm/test directory to run them.

      + +

      To run the Programs test, cd into the llvm/test/Programs directory and type + gmake. Alternatively, you can type gmake TEST=<type> + test to run one of the specialized tests in + llvm/test/Programs/TEST.<type>.Makefile. For example, you could run the + nightly tester tests using the following commands:

      + + 
      +  % cd llvm/test/Programs
+  % gmake TEST=nightly test
+
      + +

      Regardless of which test you're running, the results are printed on standard + output and standard error. You can redirect these results to a file if you + choose.

      + +

      Some tests are known to fail. Some are bugs that we have not fixed yet; + others are features that we haven't added yet (or may never add). In QMTest, + the result for such tests will be XFAIL (eXpected FAILure). In this way, you + can tell the difference between an expected and unexpected failure.

      + +

      The Programs tests have no such feature as of this time. If the test passes, + only warnings and other miscellaneous output will be generated. If a test + fails, a large <program> FAILED message will be displayed. This will help + you separate benign warnings from actual test failures.

      + +
      + + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + John T. Criswell
      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + Index: llvm-www/releases/1.2/docs/WritingAnLLVMPass.html diff -c /dev/null llvm-www/releases/1.2/docs/WritingAnLLVMPass.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/WritingAnLLVMPass.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,1478 ---- + + + + Writing an LLVM Pass + + + + +
      + Writing an LLVM Pass +
      + +
        +
      1. Introduction - What is a pass?
        2. +
      2. Quick Start - Writing hello world +
        3. +
      3. Pass classes and requirements + +
      4. Pass Registration +
        5. +
      5. Specifying interactions between passes +
        6. +
      6. Implementing Analysis Groups +
        7. +
      7. What PassManager does +
        8. +
      8. Using GDB with dynamically loaded passes +
        9. +
      9. Future extensions planned +
        10. +
      + +
      +

      Written by Chris Lattner

      +

      + + +
      + Introduction - What is a pass? +
      + + +
      + +

      The LLVM Pass Framework is an important part of the LLVM system, because LLVM + passes are where the interesting parts of the compiler exist. Passes perform + the transformations and optimizations that make up the compiler, they build + the analysis results that are used by these transformations, and they are, above + all, a structuring technique for compiler code.

      + +

      All LLVM passes are subclasses of the Pass + class, which implement functionality by overriding virtual methods inherited + from Pass. Depending on how your pass works, you may be able to + inherit from the FunctionPass + or BasicBlockPass, + which gives the system more information about what your pass does, and how it + can be combined with other passes. One of the main features of the LLVM Pass + Framework is that it schedules passes to run in an efficient way based on the + constraints that your pass has.

      + +

      We start by showing you how to construct a pass, everything from setting up + the code, to compiling, loading, and executing it. After the basics are down, + more advanced features are discussed.

      + +
      + + +
      + 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 + the program being compiled. It does not modify the program at all, just + inspects it. The source code and files for this pass are available in the LLVM + source tree in the lib/Transforms/Hello directory.

      + +
      + + +
      + Setting up the build environment +
      + +
      + +

      First thing you need to do is create a new directory somewhere in the LLVM + source base. For this example, we'll assume that you made + "lib/Transforms/Hello". The first thing you must do is set up a build + script (Makefile) that will compile the source code for the new pass. To do + this, copy this into "Makefile":

      + +
      + + 
      + # Makefile for hello pass
+ 
+ # Path to top level of LLVM heirarchy
+ LEVEL = ../../..
+ 
+ # Name of the library to build
+ LIBRARYNAME = hello
+ 
+ # Build a dynamically loadable shared object
+ SHARED_LIBRARY = 1
+ 
+ # Include the makefile implementation stuff
+ include $(LEVEL)/Makefile.common
+
      + +

      This makefile specifies that all of the .cpp files in the current + directory are to be compiled and linked together into a + lib/Debug/libhello.so shared object that can be dynamically loaded by + the opt or analyze tools. If your operating system uses a + suffix other than .so (such as windows of Mac OS/X), the appropriate extension + will be used.

      + +

      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:

      + + 
      + #include "llvm/Pass.h"
+ #include "llvm/Function.h"
+
      + +

      Which are needed because we are writing a Pass, and + we are operating on Function's.

      + +

      Next we have:

      + + 
      + namespace {
+
      + +

      ... which starts out an anonymous namespace. Anonymous namespaces are to C++ + what the "static" keyword is to C (at global scope). It makes the + things declared inside of the anonymous namespace only visible to the current + file. If you're not familiar with them, consult a decent C++ book for more + information.

      + +

      Next, we declare our pass itself:

      + + 
      +   struct Hello : public FunctionPass {
+

      + +

      This declares a "Hello" class that is a subclass of FunctionPass. + The different builtin pass subclasses are described in detail later, but for now, know that FunctionPass's operate a function at a + time.

      + + 
      +     virtual bool runOnFunction(Function &F) {
+       std::cerr << "Hello: " << F.getName() << "\n";
+       return false;
+     }
+   };  // end of struct Hello
+
      + +

      We declare a "runOnFunction" method, + which overloads an abstract virtual method inherited from FunctionPass. This is where we are supposed + to do our thing, so we just print out our message with the name of each + function.

      + + 
      +   RegisterOpt<Hello> X("hello", "Hello World Pass");
+ }  // end of anonymous namespace
+
      + +

      Lastly, we register our class Hello, giving it a command line + argument "hello", and a name "Hello World Pass". There are + several different ways of registering your pass, + depending on what it is to be used for. For "optimizations" we use the + RegisterOpt template.

      + +

      As a whole, the .cpp file looks like:

      + + 
      + #include "llvm/Pass.h"
+ #include "llvm/Function.h"
+ 
+ namespace {
+   struct Hello : public FunctionPass {
+     virtual bool runOnFunction(Function &F) {
+       std::cerr << "Hello: " << F.getName() << "\n";
+       return false;
+     }
+   };
+   
+   RegisterOpt<Hello> X("hello", "Hello World Pass");
+ }
+
      + +

      Now that it's all together, compile the file with a simple "gmake" + command in the local directory and you should get a new + "lib/Debug/libhello.so file. Note that everything in this file is + contained in an anonymous namespace: this reflects the fact that passes are self + contained units that do not need external interfaces (although they can have + them) to be useful.

      + +
      + + +
      + Running a pass with opt or analyze +
      + +
      + +

      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 + registered your pass with the RegisterOpt template, you will be able to + use the opt tool to access it, once loaded.

      + +

      To test it, follow the example at the end of the Getting Started Guide to compile "Hello World" to + LLVM. We can now run the bytecode file (hello.bc) for the program + through our transformation like this (or course, any bytecode file will + work):

      + + 
      + $ opt -load ../../../lib/Debug/libhello.so -hello < hello.bc > /dev/null
+ Hello: __main
+ Hello: puts
+ Hello: main
+
      + +

      The '-load' option specifies that 'opt' should load your + pass as a shared object, which makes '-hello' a valid command line + argument (which is one reason you need to register your + pass). Because the hello pass does not modify the program in any + interesting way, we just throw away the result of opt (sending it to + /dev/null).

      + +

      To see what happened to the other string you registered, try running + opt with the --help option:

      + + 
      + $ opt -load ../../../lib/Debug/libhello.so --help
+ OVERVIEW: llvm .bc -> .bc modular optimizer
+ 
+ USAGE: opt [options] <input bytecode>
+ 
+ OPTIONS:
+   Optimizations available:
+ ...
+     -funcresolve    - Resolve Functions
+     -gcse           - Global Common Subexpression Elimination
+     -globaldce      - Dead Global Elimination
+     -hello          - Hello World Pass
+     -indvars        - Canonicalize Induction Variables
+     -inline         - Function Integration/Inlining
+     -instcombine    - Combine redundant instructions
+ ...
+
      + +

      The pass name get added as the information string for your pass, giving some + documentation to users of opt. Now that you have a working pass, you + would go ahead and make it do the cool transformations you want. Once you get + it all working and tested, it may become useful to find out how fast your pass + is. The PassManager provides a nice command + line option (--time-passes) that allows you to get information about + the execution time of your pass along with the other passes you queue up. For + example:

      + + 
      + $ opt -load ../../../lib/Debug/libhello.so -hello -time-passes < hello.bc > /dev/null
+ Hello: __main
+ Hello: puts
+ Hello: main
+ ===============================================================================
+                       ... Pass execution timing report ...
+ ===============================================================================
+   Total Execution Time: 0.02 seconds (0.0479059 wall clock)
+ 
+    ---User Time---   --System Time--   --User+System--   ---Wall Time---  --- Pass Name ---
+    0.0100 (100.0%)   0.0000 (  0.0%)   0.0100 ( 50.0%)   0.0402 ( 84.0%)  Bytecode Writer
+    0.0000 (  0.0%)   0.0100 (100.0%)   0.0100 ( 50.0%)   0.0031 (  6.4%)  Dominator Set Construction
+    0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0013 (  2.7%)  Module Verifier
+    0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0033 (  6.9%)  Hello World Pass
+    0.0100 (100.0%)   0.0100 (100.0%)   0.0200 (100.0%)   0.0479 (100.0%)  TOTAL
+
      + +

      As you can see, our implementation above is pretty fast :). The additional + passes listed are automatically inserted by the 'opt' tool to verify + that the LLVM emitted by your pass is still valid and well formed LLVM, which + hasn't been broken somehow.

      + +

      Now that you have seen the basics of the mechanics behind passes, we can talk + about some more details of how they work and how to use them.

      + +
      + + +
      + 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 Hello World example uses the FunctionPass class for its implementation, but we + did not discuss why or when this should occur. Here we talk about the classes + available, from the most general to the most specific.

      + +

      When choosing a superclass for your Pass, you should choose the most + specific class possible, while still being able to meet the requirements + listed. This gives the LLVM Pass Infrastructure information necessary to + optimize how passes are run, so that the resultant compiler isn't unneccesarily + slow.

      + +
      + + +
      + The ImmutablePass class +
      + +
      + +

      The most plain and boring type of pass is the "ImmutablePass" + class. This pass type is used for passes that do not have to be run, do not + change state, and never need to be updated. This is not a normal type of + transformation or analysis, but can provide information about the current + compiler configuration.

      + +

      Although this pass class is very infrequently used, it is important for + providing information about the current target machine being compiled for, and + other static information that can affect the various transformations.

      + +

      ImmutablePasses never invalidate other transformations, are never + invalidated, and are never "run".

      + +
      + + +
      + The Pass class +
      + +
      + +

      The "Pass" + class is the most general of all superclasses that you can use. Deriving from + Pass indicates that your pass uses the entire program as a unit, + refering to function bodies in no predictable order, or adding and removing + functions. Because nothing is known about the behavior of direct Pass + subclasses, no optimization can be done for their execution.

      + +

      To write a correct Pass subclass, derive from Pass and + overload the run method with the following signature:

      + +
      + + +
      + The run method +
      + +
      + + 
      +   virtual bool run(Module &M) = 0;
+
      + +

      The run method performs the interesting work of the pass, and should + return true if the module was modified by the transformation, false + otherwise.

      + +
      + + +
      + The FunctionPass class +
      + +
      + +

      In contrast to direct Pass subclasses, direct FunctionPass + subclasses do have a predictable, local behavior that can be expected by the + system. All FunctionPass execute on each function in the program + independent of all of the other functions in the program. + FunctionPass's do not require that they are executed in a particular + order, and FunctionPass's do not modify external functions.

      + +

      To be explicit, FunctionPass subclasses are not allowed to:

      + +
        +
      1. Modify a Function other than the one currently being processed.
        2. +
      2. Add or remove Function's from the current Module.
        3. +
      3. Add or remove global variables from the current Module.
        4. +
      4. Maintain state across invocations of + runOnFunction (including global data)
        5. +
      + +

      Implementing a FunctionPass is usually straightforward (See the 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 +
      + +
      + + 
      +   virtual bool doInitialization(Module &M);
+
      + +

      The doIninitialize method is allowed to do most of the things that + FunctionPass's are not allowed to do. They can add and remove + functions, get pointers to functions, etc. The doInitialization method + is designed to do simple initialization type of stuff that does not depend on + the functions being processed. The doInitialization method call is not + scheduled to overlap with any other pass executions (thus it should be very + fast).

      + +

      A good example of how this method should be used is the LowerAllocations + pass. This pass converts malloc and free instructions into + platform dependent malloc() and free() function calls. It + uses the doInitialization method to get a reference to the malloc and + free functions that it needs, adding prototypes to the module if necessary.

      + +
      + + +
      + The runOnFunction method +
      + +
      + + 
      +   virtual bool runOnFunction(Function &F) = 0;
+

      + +

      The runOnFunction method must be implemented by your subclass to do + the transformation or analysis work of your pass. As usual, a true value should + be returned if the function is modified.

      + +
      + + +
      + The doFinalization(Module + &) method +
      + +
      + + 
      +   virtual bool doFinalization(Module &M);
+
      + +

      The doFinalization method is an infrequently used method that is + called when the pass framework has finished calling runOnFunction for every function in the + program being compiled.

      + +
      + + +
      + The BasicBlockPass class +
      + +
      + +

      BasicBlockPass's are just like FunctionPass's, except that they must limit + their scope of inspection and modification to a single basic block at a time. + As such, they are not allowed to do any of the following:

      + +
        +
      1. Modify or inspect any basic blocks outside of the current one
        2. +
      2. Maintain state across invocations of + runOnBasicBlock
        3. +
      3. Modify the constrol flow graph (by altering terminator instructions)
        4. +
      4. Any of the things verboten for + FunctionPasses.
        5. +
      + +

      BasicBlockPasses are useful for traditional local and "peephole" + optimizations. They may override the same 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 +
      + +
      + + 
      +   virtual bool doInitialization(Function &F);
+
      + +

      The doIninitialize method is allowed to do most of the things that + BasicBlockPass's are not allowed to do, but that + FunctionPass's can. The doInitialization method is designed + to do simple initialization type of stuff that does not depend on the + BasicBlocks being processed. The doInitialization method call is not + scheduled to overlap with any other pass executions (thus it should be very + fast).

      + +
      + + +
      + The runOnBasicBlock method +
      + +
      + + 
      +   virtual bool runOnBasicBlock(BasicBlock &BB) = 0;
+
      + +

      Override this function to do the work of the BasicBlockPass. This + function is not allowed to inspect or modify basic blocks other than the + parameter, and are not allowed to modify the CFG. A true value must be returned + if the basic block is modified.

      + +
      + + +
      + The doFinalization(Function &) + method +
      + +
      + + 
      +   virtual bool doFinalization(Function &F);
+
      + +

      The doFinalization method is an infrequently used method that is + called when the pass framework has finished calling runOnBasicBlock for every BasicBlock in the + program being compiled. This can be used to perform per-function + 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 + program. A MachineFunctionPass is also a FunctionPass, so all + the restrictions that apply to a FunctionPass also apply to it. + MachineFunctionPasses also have additional restrictions. In particular, + MachineFunctionPasses are not allowed to do any of the following:

      + +
        +
      1. Modify any LLVM Instructions, BasicBlocks or Functions.
        2. +
      2. Modify a MachineFunction other than the one currently being processed.
        3. +
      3. Add or remove MachineFunctions from the current Module.
        4. +
      4. Add or remove global variables from the current Module.
        5. +
      5. Maintain state across invocations of runOnMachineFunction (including global + data)
        6. +
      + +
      + + +
      + The runOnMachineFunction(MachineFunction + &MF) method +
      + +
      + + 
      +   virtual bool runOnMachineFunction(MachineFunction &MF) = 0;
+
      + +

      runOnMachineFunction can be considered the main entry point of a + MachineFunctionPass; that is, you should override this method to do the + work of your MachineFunctionPass.

      + +

      The runOnMachineFunction method is called on every + MachineFunction in a Module, so that the + MachineFunctionPass may perform optimizations on the machine-dependent + representation of the function. If you want to get at the LLVM Function + for the MachineFunction you're working on, use + MachineFunction's getFunction() accessor method -- but + remember, you may not modify the LLVM Function or its contents from a + MachineFunctionPass.

      + +
      + + +
      + 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 + what it does. Here we discuss how and why passes are registered.

      + +

      Passes can be registered in several different ways. Depending on the general + classification of the pass, you should use one of the following templates to + register the pass:

      + +
        +
      • RegisterOpt - This template should be used when you are + registering a pass that logically should be available for use in the + 'opt' utility.
        • + +
      • RegisterAnalysis - This template should be used when you are + registering a pass that logically should be available for use in the + 'analyze' utility.
        • + +
      • RegisterPass - This is the generic form of the + Register* templates that should be used if you want your pass listed by + multiple or no utilities. This template takes an extra third argument that + specifies which tools it should be listed in. See the PassSupport.h + file for more information.
        • + +
      + +

      Regardless of how you register your pass, you must specify at least two + parameters. The first parameter is the name of the pass that is to be used on + the command line to specify that the pass should be added to a program (for + example opt or analyze). The second argument is the name of + the pass, which is to be used for the --help output of programs, as + well as for debug output generated by the --debug-pass option.

      + +

      If a pass is registered to be used by the analyze utility, you + should implement the virtual print method:

      + +
      + + +
      + The print method +
      + +
      + + 
      +   virtual void print(std::ostream &O, const Module *M) const;
+
      + +

      The print method must be implemented by "analyses" in order to print + a human readable version of the analysis results. This is useful for debugging + an analysis itself, as well as for other people to figure out how an analysis + works. The analyze tool uses this method to generate its output.

      + +

      The ostream parameter specifies the stream to write the results on, + and the Module parameter gives a pointer to the top level module of the + program that has been analyzed. Note however that this pointer may be null in + certain circumstances (such as calling the Pass::dump() from a + debugger), so it should only be used to enhance debug output, it should not be + depended on.

      + +
      + + +
      + Specifying interactions between passes +
      + + +
      + +

      One of the main responsibilities of the PassManager is the make sure + that passes interact with each other correctly. Because PassManager + tries to optimize the execution of passes it must + know how the passes interact with each other and what dependencies exist between + the various passes. To track this, each pass can declare the set of passes that + are required to be executed before the current pass, and the passes which are + invalidated by the current pass.

      + +

      Typically this functionality is used to require that analysis results are + computed before your pass is run. Running arbitrary transformation passes can + invalidate the computed analysis results, which is what the invalidation set + specifies. If a pass does not implement the getAnalysisUsage method, it defaults to not + having any prerequisite passes, and invalidating all other passes.

      + +
      + + +
      + The getAnalysisUsage method +
      + +
      + + 
      +   virtual void getAnalysisUsage(AnalysisUsage &Info) const;
+
      + +

      By implementing the getAnalysisUsage method, the required and + invalidated sets may be specified for your transformation. The implementation + should fill in the AnalysisUsage + object with information about which passes are required and not invalidated. To + do this, a pass may call any of the following methods on the AnalysisUsage + object:

      +
      + + +
      + The AnalysisUsage::addRequired<> and AnalysisUsage::addRequiredTransitive<> methods +
      + +
      +

      + If you pass requires a previous pass to be executed (an analysis for example), + it can use one of these methods to arrange for it to be run before your pass. + LLVM has many different types of analyses and passes that can be required, + spaning the range from DominatorSet to BreakCriticalEdges. + requiring BreakCriticalEdges, for example, guarantees that there will + be no critical edges in the CFG when your pass has been run. +

      + +

      + Some analyses chain to other analyses to do their job. For example, an AliasAnalysis implementation is required to chain to other alias analysis passes. In + cases where analyses chain, the addRequiredTransitive method should be + used instead of the addRequired method. This informs the PassManager + that the transitively required pass should be alive as long as the requiring + pass is. +

      +
      + + +
      + 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 + this reason, passes are allowed to declare that they preserve (i.e., they don't + invalidate) an existing analysis if it's available. For example, a simple + constant folding pass would not modify the CFG, so it can't possible effect the + results of dominator analysis. By default, all passes are assumed to invalidate + all others. +

      + +

      + The AnalysisUsage class provides several methods which are useful in + certain circumstances that are related to addPreserved. In particular, + the setPreservesAll method can be called to indicate that the pass does + not modify the LLVM program at all (which is true for analyses), and the + setPreservesCFG method can be used by transformations that change + instructions in the program but do not modify the CFG or terminator instructions + (note that this property is implicitly set for BasicBlockPass's). +

      + +

      + addPreserved is particularly useful for transformations like + BreakCriticalEdges. This pass knows how to update a small set of loop + and dominator related analyses if they exist, so it can preserve them, despite + the fact that it hacks on the CFG. +

      +
      + + +
      + 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>();
+   }
+
      + +

      and:

      + + 
      +   // This example modifies the program, but does not modify the CFG
+   void LICM::getAnalysisUsage(AnalysisUsage &AU) const {
+     AU.setPreservesCFG();
+     AU.addRequired<LoopInfo>();
+   }
+
      + +
      + + +
      + The getAnalysis<> and getAnalysisToUpdate<> methods +
      + +
      + +

      The Pass::getAnalysis<> method is automatically inherited by + your class, providing you with access to the passes that you declared that you + required with the getAnalysisUsage + method. It takes a single template argument that specifies which pass class you + want, and returns a reference to that pass. For example:

      + + 
      +    bool LICM::runOnFunction(Function &F) {
+      LoopInfo &LI = getAnalysis<LoopInfo>();
+      ...
+    }
+
      + +

      This method call returns a reference to the pass desired. You may get a + runtime assertion failure if you attempt to get an analysis that you did not + declare as required in your getAnalysisUsage implementation. This + method can be called by your run* method implementation, or by any + other local method invoked by your run* method.

      + +

      + If your pass is capable of updating analyses if they exist (e.g., + BreakCriticalEdges, as described above), you can use the + getAnalysisToUpdate method, which returns a pointer to the analysis if + it is active. For example:

      + + 
      +   ...
+   if (DominatorSet *DS = getAnalysisToUpdate<DominatorSet>()) {
+     // A DominatorSet is active.  This code will update it.
+   }
+   ...
+
      + +
      + + +
      + Implementing Analysis Groups +
      + + +
      + +

      Now that we understand the basics of how passes are defined, how the are + used, and how they are required from other passes, it's time to get a little bit + fancier. All of the pass relationships that we have seen so far are very + simple: one pass depends on one other specific pass to be run before it can run. + For many applications, this is great, for others, more flexibility is + required.

      + +

      In particular, some analyses are defined such that there is a single simple + interface to the analysis results, but multiple ways of calculating them. + Consider alias analysis for example. The most trivial alias analysis returns + "may alias" for any alias query. The most sophisticated analysis a + flow-sensitive, context-sensitive interprocedural analysis that can take a + significant amount of time to execute (and obviously, there is a lot of room + between these two extremes for other implementations). To cleanly support + situations like this, the LLVM Pass Infrastructure supports the notion of + Analysis Groups.

      + +
      + + +
      + 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 + just like passes, but unlike passes, they need not derive from the Pass + class. An analysis group may have one or more implementations, one of which is + the "default" implementation.

      + +

      Analysis groups are used by client passes just like other passes are: the + AnalysisUsage::addRequired() and Pass::getAnalysis() methods. + In order to resolve this requirement, the PassManager + scans the available passes to see if any implementations of the analysis group + are available. If none is available, the default implementation is created for + the pass to use. All standard rules for interaction + between passes still apply.

      + +

      Although Pass Registration is optional for normal + passes, all analysis group implementations must be registered, and must use the + RegisterAnalysisGroup template to join the + implementation pool. Also, a default implementation of the interface + must be registered with RegisterAnalysisGroup.

      + +

      As a concrete example of an Analysis Group in action, consider the AliasAnalysis + analysis group. The default implementation of the alias analysis interface (the + basicaa + pass) just does a few simple checks that don't require significant analysis to + compute (such as: two different globals can never alias each other, etc). + Passes that use the AliasAnalysis + interface (for example the gcse pass), do + not care which implementation of alias analysis is actually provided, they just + use the designated interface.

      + +

      From the user's perspective, commands work just like normal. Issuing the + command 'opt -gcse ...' will cause the basicaa class to be + instantiated and added to the pass sequence. Issuing the command 'opt + -somefancyaa -gcse ...' will cause the gcse pass to use the + somefancyaa alias analysis (which doesn't actually exist, it's just a + hypothetical example) instead.

      + +
      + + +
      + Using RegisterAnalysisGroup +
      + +
      + +

      The RegisterAnalysisGroup template is used to register the analysis + group itself as well as add pass implementations to the analysis group. First, + an analysis should be registered, with a human readable name provided for it. + Unlike registration of passes, there is no command line argument to be specified + for the Analysis Group Interface itself, because it is "abstract":

      + + 
      +   static RegisterAnalysisGroup<AliasAnalysis> A("Alias Analysis");
+
      + +

      Once the analysis is registered, passes can declare that they are valid + implementations of the interface by using the following code:

      + + 
      + namespace {
+   // Analysis Group implementations must be registered normally...
+   RegisterOpt<FancyAA>
+   B("somefancyaa", "A more complex alias analysis implementation");
+ 
+   // Declare that we implement the AliasAnalysis interface
+   RegisterAnalysisGroup<AliasAnalysis, FancyAA> C;
+ }
+
      + +

      This just shows a class FancyAA that is registered normally, then + uses the RegisterAnalysisGroup template to "join" the AliasAnalysis + analysis group. Every implementation of an analysis group should join using + this template. A single pass may join multiple different analysis groups with + no problem.

      + + 
      + namespace {
+   // Analysis Group implementations must be registered normally...
+   RegisterOpt<BasicAliasAnalysis>
+   D("basicaa", "Basic Alias Analysis (default AA impl)");
+ 
+   // Declare that we implement the AliasAnalysis interface
+   RegisterAnalysisGroup<AliasAnalysis, BasicAliasAnalysis, true> E;
+ }
+
      + +

      Here we show how the default implementation is specified (using the extra + argument to the RegisterAnalysisGroup template). There must be exactly + one default implementation available at all times for an Analysis Group to be + used. Here we declare that the BasicAliasAnalysis + pass is the default implementation for the interface.

      + +
      + + +
      + What PassManager does +
      + + +
      + +

      The PassManager + class + takes a list of passes, ensures their prerequisites + are set up correctly, and then schedules passes to run efficiently. All of the + LLVM tools that run passes use the PassManager for execution of these + passes.

      + +

      The PassManager does two main things to try to reduce the execution + time of a series of passes:

      + +
        +
      1. Share analysis results - The PassManager attempts to avoid + recomputing analysis results as much as possible. This means keeping track of + which analyses are available already, which analyses get invalidated, and which + analyses are needed to be run for a pass. An important part of work is that the + PassManager tracks the exact lifetime of all analysis results, allowing + it to free memory allocated to holding analysis + results as soon as they are no longer needed.
        2. + +
      2. Pipeline the execution of passes on the program - The + PassManager attempts to get better cache and memory usage behavior out + of a series of passes by pipelining the passes together. This means that, given + a series of consequtive FunctionPass's, it + will execute all of the FunctionPass's on + the first function, then all of the FunctionPasses on the second function, + etc... until the entire program has been run through the passes. + +

        This improves the cache behavior of the compiler, because it is only touching + the LLVM program representation for a single function at a time, instead of + traversing the entire program. It reduces the memory consumption of compiler, + because, for example, only one DominatorSet + needs to be calculated at a time. This also makes it possible some interesting enhancements in the future.

        3. + +
      + +

      The effectiveness of the PassManager is influenced directly by how + much information it has about the behaviors of the passes it is scheduling. For + example, the "preserved" set is intentionally conservative in the face of an + unimplemented getAnalysisUsage method. + Not implementing when it should be implemented will have the effect of not + allowing any analysis results to live across the execution of your pass.

      + +

      The PassManager class exposes a --debug-pass command line + options that is useful for debugging pass execution, seeing how things work, and + diagnosing when you should be preserving more analyses than you currently are + (To get information about all of the variants of the --debug-pass + option, just type 'opt --help-hidden').

      + +

      By using the --debug-pass=Structure option, for example, we can see + how our Hello World pass interacts with other passes. + Lets try it out with the gcse and licm passes:

      + + 
      + $ opt -load ../../../lib/Debug/libhello.so -gcse -licm --debug-pass=Structure < hello.bc > /dev/null
+ Module Pass Manager
+   Function Pass Manager
+     Dominator Set Construction
+     Immediate Dominators Construction
+     Global Common Subexpression Elimination
+ --  Immediate Dominators Construction
+ --  Global Common Subexpression Elimination
+     Natural Loop Construction
+     Loop Invariant Code Motion
+ --  Natural Loop Construction
+ --  Loop Invariant Code Motion
+     Module Verifier
+ --  Dominator Set Construction
+ --  Module Verifier
+   Bytecode Writer
+ --Bytecode Writer
+
      + +

      This output shows us when passes are constructed and when the analysis + results are known to be dead (prefixed with '--'). Here we see that + GCSE uses dominator and immediate dominator information to do its job. The LICM + pass uses natural loop information, which uses dominator sets, but not immediate + dominators. Because immediate dominators are no longer useful after the GCSE + pass, it is immediately destroyed. The dominator sets are then reused to + compute natural loop information, which is then used by the LICM pass.

      + +

      After the LICM pass, the module verifier runs (which is automatically added + by the 'opt' tool), which uses the dominator set to check that the + resultant LLVM code is well formed. After it finishes, the dominator set + information is destroyed, after being computed once, and shared by three + passes.

      + +

      Lets see how this changes when we run the Hello + World pass in between the two passes:

      + + 
      + $ opt -load ../../../lib/Debug/libhello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null
+ Module Pass Manager
+   Function Pass Manager
+     Dominator Set Construction
+     Immediate Dominators Construction
+     Global Common Subexpression Elimination
+ --  Dominator Set Construction
+ --  Immediate Dominators Construction
+ --  Global Common Subexpression Elimination
+     Hello World Pass
+ --  Hello World Pass
+     Dominator Set Construction
+     Natural Loop Construction
+     Loop Invariant Code Motion
+ --  Natural Loop Construction
+ --  Loop Invariant Code Motion
+     Module Verifier
+ --  Dominator Set Construction
+ --  Module Verifier
+   Bytecode Writer
+ --Bytecode Writer
+ Hello: __main
+ Hello: puts
+ Hello: main
+
      + +

      Here we see that the Hello World pass has killed the + Dominator Set pass, even though it doesn't modify the code at all! To fix this, + we need to add the following getAnalysisUsage method to our pass:

      + + 
      +     // We don't modify the program, so we preserve all analyses
+     virtual void getAnalysisUsage(AnalysisUsage &AU) const {
+       AU.setPreservesAll();
+     }
+
      + +

      Now when we run our pass, we get this output:

      + + 
      + $ opt -load ../../../lib/Debug/libhello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null
+ Pass Arguments:  -gcse -hello -licm
+ Module Pass Manager
+   Function Pass Manager
+     Dominator Set Construction
+     Immediate Dominators Construction
+     Global Common Subexpression Elimination
+ --  Immediate Dominators Construction
+ --  Global Common Subexpression Elimination
+     Hello World Pass
+ --  Hello World Pass
+     Natural Loop Construction
+     Loop Invariant Code Motion
+ --  Loop Invariant Code Motion
+ --  Natural Loop Construction
+     Module Verifier
+ --  Dominator Set Construction
+ --  Module Verifier
+   Bytecode Writer
+ --Bytecode Writer
+ Hello: __main
+ Hello: puts
+ Hello: main
+
      + +

      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();
+
      + +

      The PassManager automatically determines when to compute analysis + results, and how long to keep them around for. Because the lifetime of the pass + object itself is effectively the entire duration of the compilation process, we + need some way to free analysis results when they are no longer useful. The + releaseMemory virtual method is the way to do this.

      + +

      If you are writing an analysis or any other pass that retains a significant + amount of state (for use by another pass which "requires" your pass and uses the + getAnalysis method) you should implement + releaseMEmory to, well, release the memory allocated to maintain this + internal state. This method is called after the run* method for the + class, before the next call of run* in your pass.

      + +
      + + +
      + 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 + not been loaded yet, and second of all there are problems with inlined functions + in shared objects. Here are some suggestions to debugging your pass with + GDB.

      + +

      For sake of discussion, I'm going to assume that you are debugging a + 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:

      + + 
      + $ gdb opt
+ GNU gdb 5.0
+ Copyright 2000 Free Software Foundation, Inc.
+ GDB is free software, covered by the GNU General Public License, and you are
+ welcome to change it and/or distribute copies of it under certain conditions.
+ Type "show copying" to see the conditions.
+ There is absolutely no warranty for GDB.  Type "show warranty" for details.
+ This GDB was configured as "sparc-sun-solaris2.6"...
+ (gdb)
+
      + +

      Note that opt has a lot of debugging information in it, so it takes + time to load. Be patient. Since we cannot set a breakpoint in our pass yet + (the shared object isn't loaded until runtime), we must execute the process, and + have it stop before it invokes our pass, but after it has loaded the shared + object. The most foolproof way of doing this is to set a breakpoint in + PassManager::run and then run the process with the arguments you + want:

      + + 
      + (gdb) break PassManager::run
+ Breakpoint 1 at 0x2413bc: file Pass.cpp, line 70.
+ (gdb) run test.bc -load $(LLVMTOP)/llvm/lib/Debug/[libname].so -[passoption]
+ Starting program: opt test.bc -load $(LLVMTOP)/llvm/lib/Debug/[libname].so -[passoption]
+ Breakpoint 1, PassManager::run (this=0xffbef174, M=@0x70b298) at Pass.cpp:70
+ 70      bool PassManager::run(Module &M) { return PM->run(M); }
+ (gdb)
+
      + +

      Once the opt stops in the PassManager::run method you are + now free to set breakpoints in your pass so that you can trace through execution + 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.

      + +
        +
      • Inline functions have bogus stack information. In general, GDB does a + pretty good job getting stack traces and stepping through inline functions. + When a pass is dynamically loaded however, it somehow completely loses this + capability. The only solution I know of is to de-inline a function (move it + from the body of a class to a .cpp file).
        • + +
      • Restarting the program breaks breakpoints. After following the information + above, you have succeeded in getting some breakpoints planted in your pass. Nex + thing you know, you restart the program (i.e., you type 'run' again), + and you start getting errors about breakpoints being unsettable. The only way I + have found to "fix" this problem is to delete the breakpoints that are + already set in your pass, run the program, and re-set the breakpoints once + execution stops in PassManager::run.
        • + +
      + +

      Hopefully these tips will help with common case debugging situations. If + you'd like to contribute some tips of your own, just contact 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 + the semantics defined for passes above (specifically they cannot maintain state + across invocations of their run* methods), a nice clean way to + implement a multithreaded compiler would be for the PassManager class + to create multiple instances of each pass object, and allow the separate + instances to be hacking on different parts of the program at the same time.

      + +

      This implementation would prevent each of the passes from having to implement + multithreaded constructs, requiring only the LLVM core to have locking in a few + places (for global resources). Although this is a simple extension, we simply + haven't had time (or multiprocessor machines, thus a reason) to implement this. + Despite that, we have kept the LLVM passes SMP ready, and you should too.

      + +
      + + +
      + A new ModuleSource interface +
      + +
      + +

      Currently, the PassManager's run method takes a Module + as input, and runs all of the passes on this module. The problem with this + approach is that none of the PassManager features can be used for + timing and debugging the actual loading of the module from disk or + standard input.

      + +

      To solve this problem, eventually the PassManager class will accept + a ModuleSource object instead of a Module itself. When complete, this + will also allow for streaming of functions out of the bytecode representation, + allowing us to avoid holding the entire program in memory at once if we only are + dealing with FunctionPasses.

      + +

      As part of a different issue, eventually the bytecode loader will be extended + to allow on-demand loading of functions from the bytecode representation, in + order to better support the runtime reoptimizer. The bytecode format is already + capable of this, the loader just needs to be reworked a bit.

      + +
      + + +
      + Passes requiring FunctionPasses +
      + +
      + +

      Currently it is illegal for a Pass to require a + FunctionPass. This is because there is + only one instance of the FunctionPass + object ever created, thus nowhere to store information for all of the functions + in the program at the same time. Although this has come up a couple of times + before, this has always been worked around by factoring one big complicated pass + into a global and an interprocedural part, both of which are distinct. In the + future, it would be nice to have this though.

      + +

      Note that it is no problem for a FunctionPass to require the results of a Pass, only the other way around.

      + +
      + + +
      +
      + Valid CSS! + Valid HTML 4.01! + + Chris Lattner
      + The LLVM Compiler Infrastructure
      + Last modified: $Date: 2004/03/19 17:38:11 $ +
      + + + Index: llvm-www/releases/1.2/docs/doxygen.cfg diff -c /dev/null llvm-www/releases/1.2/docs/doxygen.cfg:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/doxygen.cfg Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,898 ---- + # Doxyfile 1.2.13.1 + + # This file describes the settings to be used by the documentation system + # doxygen (www.doxygen.org) for a project + # + # All text after a hash (#) is considered a comment and will be ignored + # The format is: + # TAG = value [value, ...] + # For lists items can also be appended using: + # TAG += value [value, ...] + # Values that contain spaces should be placed between quotes (" ") + + #--------------------------------------------------------------------------- + # General configuration options + #--------------------------------------------------------------------------- + + # The PROJECT_NAME tag is a single word (or a sequence of words surrounded + # by quotes) that should identify the project. + + PROJECT_NAME = LLVM + + # The PROJECT_NUMBER tag can be used to enter a project or revision number. + # This could be handy for archiving the generated documentation or + # if some version control system is used. + + PROJECT_NUMBER = + + # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) + # base path where the generated documentation will be put. + # If a relative path is entered, it will be relative to the location + # where doxygen was started. If left blank the current directory will be used. + + OUTPUT_DIRECTORY = doxygen + + # The OUTPUT_LANGUAGE tag is used to specify the language in which all + # documentation generated by doxygen is written. Doxygen will use this + # information to generate all constant output in the proper language. + # The default language is English, other supported languages are: + # Brazilian, Chinese, Croatian, Czech, Danish, Dutch, Finnish, French, + # German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, + # Portuguese, Romanian, Russian, Slovak, Slovene, Spanish and Swedish. + + OUTPUT_LANGUAGE = English + + # If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in + # documentation are documented, even if no documentation was available. + # Private class members and static file members will be hidden unless + # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES + + EXTRACT_ALL = YES + + # If the EXTRACT_PRIVATE tag is set to YES all private members of a class + # will be included in the documentation. + + EXTRACT_PRIVATE = NO + + # If the EXTRACT_STATIC tag is set to YES all static members of a file + # will be included in the documentation. + + EXTRACT_STATIC = YES + + # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) + # defined locally in source files will be included in the documentation. + # If set to NO only classes defined in header files are included. + + EXTRACT_LOCAL_CLASSES = YES + + # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all + # undocumented members of documented classes, files or namespaces. + # If set to NO (the default) these members will be included in the + # various overviews, but no documentation section is generated. + # This option has no effect if EXTRACT_ALL is enabled. + + HIDE_UNDOC_MEMBERS = NO + + # If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all + # undocumented classes that are normally visible in the class hierarchy. + # If set to NO (the default) these class will be included in the various + # overviews. This option has no effect if EXTRACT_ALL is enabled. + + HIDE_UNDOC_CLASSES = NO + + # If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will + # include brief member descriptions after the members that are listed in + # the file and class documentation (similar to JavaDoc). + # Set to NO to disable this. + + BRIEF_MEMBER_DESC = YES + + # If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend + # the brief description of a member or function before the detailed description. + # Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the + # brief descriptions will be completely suppressed. + + REPEAT_BRIEF = YES + + # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then + # Doxygen will generate a detailed section even if there is only a brief + # description. + + ALWAYS_DETAILED_SEC = NO + + # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all + # inherited members of a class in the documentation of that class as if those + # members were ordinary class members. Constructors, destructors and assignment + # operators of the base classes will not be shown. + + INLINE_INHERITED_MEMB = NO + + # If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full + # path before files name in the file list and in the header files. If set + # to NO the shortest path that makes the file name unique will be used. + + FULL_PATH_NAMES = NO + + # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag + # can be used to strip a user defined part of the path. Stripping is + # only done if one of the specified strings matches the left-hand part of + # the path. It is allowed to use relative paths in the argument list. + + STRIP_FROM_PATH = ../.. + + # The INTERNAL_DOCS tag determines if documentation + # that is typed after a \internal command is included. If the tag is set + # to NO (the default) then the documentation will be excluded. + # Set it to YES to include the internal documentation. + + INTERNAL_DOCS = NO + + # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct + # doxygen to hide any special comment blocks from generated source code + # fragments. Normal C and C++ comments will always remain visible. + + STRIP_CODE_COMMENTS = NO + + # If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate + # file names in lower case letters. If set to YES upper case letters are also + # allowed. This is useful if you have classes or files whose names only differ + # in case and if your file system supports case sensitive file names. Windows + # users are adviced to set this option to NO. + + CASE_SENSE_NAMES = YES + + # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter + # (but less readable) file names. This can be useful is your file systems + # doesn't support long names like on DOS, Mac, or CD-ROM. + + SHORT_NAMES = NO + + # If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen + # will show members with their full class and namespace scopes in the + # documentation. If set to YES the scope will be hidden. + + HIDE_SCOPE_NAMES = NO + + # If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen + # will generate a verbatim copy of the header file for each class for + # which an include is specified. Set to NO to disable this. + + VERBATIM_HEADERS = YES + + # If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen + # will put list of the files that are included by a file in the documentation + # of that file. + + SHOW_INCLUDE_FILES = YES + + # If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen + # will interpret the first line (until the first dot) of a JavaDoc-style + # comment as the brief description. If set to NO, the JavaDoc + # comments will behave just like the Qt-style comments (thus requiring an + # explict @brief command for a brief description. + + JAVADOC_AUTOBRIEF = NO + + # If the INHERIT_DOCS tag is set to YES (the default) then an undocumented + # member inherits the documentation from any documented member that it + # reimplements. + + INHERIT_DOCS = YES + + # If the INLINE_INFO tag is set to YES (the default) then a tag [inline] + # is inserted in the documentation for inline members. + + INLINE_INFO = YES + + # If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen + # will sort the (detailed) documentation of file and class members + # alphabetically by member name. If set to NO the members will appear in + # declaration order. + + SORT_MEMBER_DOCS = YES + + # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC + # tag is set to YES, then doxygen will reuse the documentation of the first + # member in the group (if any) for the other members of the group. By default + # all members of a group must be documented explicitly. + + DISTRIBUTE_GROUP_DOC = NO + + # The TAB_SIZE tag can be used to set the number of spaces in a tab. + # Doxygen uses this value to replace tabs by spaces in code fragments. + + TAB_SIZE = 2 + + # The GENERATE_TODOLIST tag can be used to enable (YES) or + # disable (NO) the todo list. This list is created by putting \todo + # commands in the documentation. + + GENERATE_TODOLIST = YES + + # The GENERATE_TESTLIST tag can be used to enable (YES) or + # disable (NO) the test list. This list is created by putting \test + # commands in the documentation. + + GENERATE_TESTLIST = YES + + # The GENERATE_BUGLIST tag can be used to enable (YES) or + # disable (NO) the bug list. This list is created by putting \bug + # commands in the documentation. + + GENERATE_BUGLIST = YES + + # This tag can be used to specify a number of aliases that acts + # as commands in the documentation. An alias has the form "name=value". + # For example adding "sideeffect=\par Side Effects:\n" will allow you to + # put the command \sideeffect (or @sideeffect) in the documentation, which + # will result in a user defined paragraph with heading "Side Effects:". + # You can put \n's in the value part of an alias to insert newlines. + + ALIASES = + + # The ENABLED_SECTIONS tag can be used to enable conditional + # documentation sections, marked by \if sectionname ... \endif. + + ENABLED_SECTIONS = + + # The MAX_INITIALIZER_LINES tag determines the maximum number of lines + # the initial value of a variable or define consist of for it to appear in + # the documentation. If the initializer consists of more lines than specified + # here it will be hidden. Use a value of 0 to hide initializers completely. + # The appearance of the initializer of individual variables and defines in the + # documentation can be controlled using \showinitializer or \hideinitializer + # command in the documentation regardless of this setting. + + MAX_INITIALIZER_LINES = 30 + + # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources + # only. Doxygen will then generate output that is more tailored for C. + # For instance some of the names that are used will be different. The list + # of all members will be omitted, etc. + + OPTIMIZE_OUTPUT_FOR_C = NO + + # Set the SHOW_USED_FILES tag to NO to disable the list of files generated + # at the bottom of the documentation of classes and structs. If set to YES the + # list will mention the files that were used to generate the documentation. + + SHOW_USED_FILES = YES + + #--------------------------------------------------------------------------- + # configuration options related to warning and progress messages + #--------------------------------------------------------------------------- + + # The QUIET tag can be used to turn on/off the messages that are generated + # by doxygen. Possible values are YES and NO. If left blank NO is used. + + QUIET = NO + + # The WARNINGS tag can be used to turn on/off the warning messages that are + # generated by doxygen. Possible values are YES and NO. If left blank + # NO is used. + + WARNINGS = NO + + # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings + # for undocumented members. If EXTRACT_ALL is set to YES then this flag will + # automatically be disabled. + + WARN_IF_UNDOCUMENTED = NO + + # The WARN_FORMAT tag determines the format of the warning messages that + # doxygen can produce. The string should contain the $file, $line, and $text + # tags, which will be replaced by the file and line number from which the + # warning originated and the warning text. + + WARN_FORMAT = + + # The WARN_LOGFILE tag can be used to specify a file to which warning + # and error messages should be written. If left blank the output is written + # to stderr. + + WARN_LOGFILE = + + #--------------------------------------------------------------------------- + # configuration options related to the input files + #--------------------------------------------------------------------------- + + # The INPUT tag can be used to specify the files and/or directories that contain + # documented source files. You may enter file names like "myfile.cpp" or + # directories like "/usr/src/myproject". Separate the files or directories with + # spaces. + + INPUT = .. ./doxygen.intro + + # If the value of the INPUT tag contains directories, you can use the + # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp + # and *.h) to filter out the source-files in the directories. If left + # blank the following patterns are tested: + # *.c *.cc *.cxx *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx *.hpp + # *.h++ *.idl + + FILE_PATTERNS = + + # The RECURSIVE tag can be used to turn specify whether or not subdirectories + # should be searched for input files as well. Possible values are YES and NO. + # If left blank NO is used. + + RECURSIVE = YES + + # The EXCLUDE tag can be used to specify files and/or directories that should + # excluded from the INPUT source files. This way you can easily exclude a + # subdirectory from a directory tree whose root is specified with the INPUT tag. + + EXCLUDE = ../test ../include/boost + + # If the value of the INPUT tag contains directories, you can use the + # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude + # certain files from those directories. + + EXCLUDE_PATTERNS = + + # The EXAMPLE_PATH tag can be used to specify one or more files or + # directories that contain example code fragments that are included (see + # the \include command). + + EXAMPLE_PATH = + + # If the value of the EXAMPLE_PATH tag contains directories, you can use the + # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp + # and *.h) to filter out the source-files in the directories. If left + # blank all files are included. + + EXAMPLE_PATTERNS = + + # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be + # searched for input files to be used with the \include or \dontinclude + # commands irrespective of the value of the RECURSIVE tag. + # Possible values are YES and NO. If left blank NO is used. + + EXAMPLE_RECURSIVE = NO + + # The IMAGE_PATH tag can be used to specify one or more files or + # directories that contain image that are included in the documentation (see + # the \image command). + + IMAGE_PATH = + + # The INPUT_FILTER tag can be used to specify a program that doxygen should + # invoke to filter for each input file. Doxygen will invoke the filter program + # by executing (via popen()) the command , where + # is the value of the INPUT_FILTER tag, and is the name of an + # input file. Doxygen will then use the output that the filter program writes + # to standard output. + + INPUT_FILTER = + + # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using + # INPUT_FILTER) will be used to filter the input files when producing source + # files to browse. + + FILTER_SOURCE_FILES = NO + + #--------------------------------------------------------------------------- + # configuration options related to source browsing + #--------------------------------------------------------------------------- + + # If the SOURCE_BROWSER tag is set to YES then a list of source files will + # be generated. Documented entities will be cross-referenced with these sources. + + SOURCE_BROWSER = YES + + # Setting the INLINE_SOURCES tag to YES will include the body + # of functions and classes directly in the documentation. + + INLINE_SOURCES = NO + + # If the REFERENCED_BY_RELATION tag is set to YES (the default) + # then for each documented function all documented + # functions referencing it will be listed. + + REFERENCED_BY_RELATION = YES + + # If the REFERENCES_RELATION tag is set to YES (the default) + # then for each documented function all documented entities + # called/used by that function will be listed. + + REFERENCES_RELATION = YES + + #--------------------------------------------------------------------------- + # configuration options related to the alphabetical class index + #--------------------------------------------------------------------------- + + # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index + # of all compounds will be generated. Enable this if the project + # contains a lot of classes, structs, unions or interfaces. + + ALPHABETICAL_INDEX = YES + + # If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then + # the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns + # in which this list will be split (can be a number in the range [1..20]) + + COLS_IN_ALPHA_INDEX = 5 + + # In case all classes in a project start with a common prefix, all + # classes will be put under the same header in the alphabetical index. + # The IGNORE_PREFIX tag can be used to specify one or more prefixes that + # should be ignored while generating the index headers. + + IGNORE_PREFIX = + + #--------------------------------------------------------------------------- + # configuration options related to the HTML output + #--------------------------------------------------------------------------- + + # If the GENERATE_HTML tag is set to YES (the default) Doxygen will + # generate HTML output. + + GENERATE_HTML = YES + + # The HTML_OUTPUT tag is used to specify where the HTML docs will be put. + # If a relative path is entered the value of OUTPUT_DIRECTORY will be + # put in front of it. If left blank `html' will be used as the default path. + + HTML_OUTPUT = . + + # The HTML_HEADER tag can be used to specify a personal HTML header for + # each generated HTML page. If it is left blank doxygen will generate a + # standard header. + + HTML_HEADER = doxygen.header + + # The HTML_FOOTER tag can be used to specify a personal HTML footer for + # each generated HTML page. If it is left blank doxygen will generate a + # standard footer. + + HTML_FOOTER = doxygen.footer + + # The HTML_STYLESHEET tag can be used to specify a user defined cascading + # style sheet that is used by each HTML page. It can be used to + # fine-tune the look of the HTML output. If the tag is left blank doxygen + # will generate a default style sheet + + HTML_STYLESHEET = doxygen.css + + # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, + # files or namespaces will be aligned in HTML using tables. If set to + # NO a bullet list will be used. + + HTML_ALIGN_MEMBERS = YES + + # If the GENERATE_HTMLHELP tag is set to YES, additional index files + # will be generated that can be used as input for tools like the + # Microsoft HTML help workshop to generate a compressed HTML help file (.chm) + # of the generated HTML documentation. + + GENERATE_HTMLHELP = NO + + # If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag + # controls if a separate .chi index file is generated (YES) or that + # it should be included in the master .chm file (NO). + + GENERATE_CHI = NO + + # If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag + # controls whether a binary table of contents is generated (YES) or a + # normal table of contents (NO) in the .chm file. + + BINARY_TOC = NO + + # The TOC_EXPAND flag can be set to YES to add extra items for group members + # to the contents of the Html help documentation and to the tree view. + + TOC_EXPAND = NO + + # The DISABLE_INDEX tag can be used to turn on/off the condensed index at + # top of each HTML page. The value NO (the default) enables the index and + # the value YES disables it. + + DISABLE_INDEX = NO + + # This tag can be used to set the number of enum values (range [1..20]) + # that doxygen will group on one line in the generated HTML documentation. + + ENUM_VALUES_PER_LINE = 4 + + # If the GENERATE_TREEVIEW tag is set to YES, a side panel will be + # generated containing a tree-like index structure (just like the one that + # is generated for HTML Help). For this to work a browser that supports + # JavaScript and frames is required (for instance Mozilla, Netscape 4.0+, + # or Internet explorer 4.0+). Note that for large projects the tree generation + # can take a very long time. In such cases it is better to disable this feature. + # Windows users are probably better off using the HTML help feature. + + GENERATE_TREEVIEW = NO + + # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be + # used to set the initial width (in pixels) of the frame in which the tree + # is shown. + + TREEVIEW_WIDTH = 250 + + #--------------------------------------------------------------------------- + # configuration options related to the LaTeX output + #--------------------------------------------------------------------------- + + # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will + # generate Latex output. + + GENERATE_LATEX = NO + + # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. + # If a relative path is entered the value of OUTPUT_DIRECTORY will be + # put in front of it. If left blank `latex' will be used as the default path. + + LATEX_OUTPUT = + + # If the COMPACT_LATEX tag is set to YES Doxygen generates more compact + # LaTeX documents. This may be useful for small projects and may help to + # save some trees in general. + + COMPACT_LATEX = NO + + # The PAPER_TYPE tag can be used to set the paper type that is used + # by the printer. Possible values are: a4, a4wide, letter, legal and + # executive. If left blank a4wide will be used. + + PAPER_TYPE = a4wide + + # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX + # packages that should be included in the LaTeX output. + + EXTRA_PACKAGES = + + # The LATEX_HEADER tag can be used to specify a personal LaTeX header for + # the generated latex document. The header should contain everything until + # the first chapter. If it is left blank doxygen will generate a + # standard header. Notice: only use this tag if you know what you are doing! + + LATEX_HEADER = + + # If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated + # is prepared for conversion to pdf (using ps2pdf). The pdf file will + # contain links (just like the HTML output) instead of page references + # This makes the output suitable for online browsing using a pdf viewer. + + PDF_HYPERLINKS = NO + + # If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of + # plain latex in the generated Makefile. Set this option to YES to get a + # higher quality PDF documentation. + + USE_PDFLATEX = NO + + # If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. + # command to the generated LaTeX files. This will instruct LaTeX to keep + # running if errors occur, instead of asking the user for help. + # This option is also used when generating formulas in HTML. + + LATEX_BATCHMODE = NO + + #--------------------------------------------------------------------------- + # configuration options related to the RTF output + #--------------------------------------------------------------------------- + + # If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output + # The RTF output is optimised for Word 97 and may not look very pretty with + # other RTF readers or editors. + + GENERATE_RTF = NO + + # The RTF_OUTPUT tag is used to specify where the RTF docs will be put. + # If a relative path is entered the value of OUTPUT_DIRECTORY will be + # put in front of it. If left blank `rtf' will be used as the default path. + + RTF_OUTPUT = + + # If the COMPACT_RTF tag is set to YES Doxygen generates more compact + # RTF documents. This may be useful for small projects and may help to + # save some trees in general. + + COMPACT_RTF = NO + + # If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated + # will contain hyperlink fields. The RTF file will + # contain links (just like the HTML output) instead of page references. + # This makes the output suitable for online browsing using WORD or other + # programs which support those fields. + # Note: wordpad (write) and others do not support links. + + RTF_HYPERLINKS = NO + + # Load stylesheet definitions from file. Syntax is similar to doxygen's + # config file, i.e. a series of assigments. You only have to provide + # replacements, missing definitions are set to their default value. + + RTF_STYLESHEET_FILE = + + # Set optional variables used in the generation of an rtf document. + # Syntax is similar to doxygen's config file. + + RTF_EXTENSIONS_FILE = + + #--------------------------------------------------------------------------- + # configuration options related to the man page output + #--------------------------------------------------------------------------- + + # If the GENERATE_MAN tag is set to YES (the default) Doxygen will + # generate man pages + + GENERATE_MAN = NO + + # The MAN_OUTPUT tag is used to specify where the man pages will be put. + # If a relative path is entered the value of OUTPUT_DIRECTORY will be + # put in front of it. If left blank `man' will be used as the default path. + + MAN_OUTPUT = + + # The MAN_EXTENSION tag determines the extension that is added to + # the generated man pages (default is the subroutine's section .3) + + MAN_EXTENSION = + + # If the MAN_LINKS tag is set to YES and Doxygen generates man output, + # then it will generate one additional man file for each entity + # documented in the real man page(s). These additional files + # only source the real man page, but without them the man command + # would be unable to find the correct page. The default is NO. + + MAN_LINKS = NO + + #--------------------------------------------------------------------------- + # configuration options related to the XML output + #--------------------------------------------------------------------------- + + # If the GENERATE_XML tag is set to YES Doxygen will + # generate an XML file that captures the structure of + # the code including all documentation. Note that this + # feature is still experimental and incomplete at the + # moment. + + GENERATE_XML = NO + + #--------------------------------------------------------------------------- + # configuration options for the AutoGen Definitions output + #--------------------------------------------------------------------------- + + # If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will + # generate an AutoGen Definitions (see autogen.sf.net) file + # that captures the structure of the code including all + # documentation. Note that this feature is still experimental + # and incomplete at the moment. + + GENERATE_AUTOGEN_DEF = NO + + #--------------------------------------------------------------------------- + # Configuration options related to the preprocessor + #--------------------------------------------------------------------------- + + # If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will + # evaluate all C-preprocessor directives found in the sources and include + # files. + + ENABLE_PREPROCESSING = YES + + # If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro + # names in the source code. If set to NO (the default) only conditional + # compilation will be performed. Macro expansion can be done in a controlled + # way by setting EXPAND_ONLY_PREDEF to YES. + + MACRO_EXPANSION = NO + + # If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES + # then the macro expansion is limited to the macros specified with the + # PREDEFINED and EXPAND_AS_PREDEFINED tags. + + EXPAND_ONLY_PREDEF = NO + + # If the SEARCH_INCLUDES tag is set to YES (the default) the includes files + # in the INCLUDE_PATH (see below) will be search if a #include is found. + + SEARCH_INCLUDES = YES + + # The INCLUDE_PATH tag can be used to specify one or more directories that + # contain include files that are not input files but should be processed by + # the preprocessor. + + INCLUDE_PATH = ../include + + # You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard + # patterns (like *.h and *.hpp) to filter out the header-files in the + # directories. If left blank, the patterns specified with FILE_PATTERNS will + # be used. + + INCLUDE_FILE_PATTERNS = + + # The PREDEFINED tag can be used to specify one or more macro names that + # are defined before the preprocessor is started (similar to the -D option of + # gcc). The argument of the tag is a list of macros of the form: name + # or name=definition (no spaces). If the definition and the = are + # omitted =1 is assumed. + + PREDEFINED = + + # If the MACRO_EXPANSION and EXPAND_PREDEF_ONLY tags are set to YES then + # this tag can be used to specify a list of macro names that should be expanded. + # The macro definition that is found in the sources will be used. + # Use the PREDEFINED tag if you want to use a different macro definition. + + EXPAND_AS_DEFINED = + + # If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then + # doxygen's preprocessor will remove all function-like macros that are alone + # on a line and do not end with a semicolon. Such function macros are typically + # used for boiler-plate code, and will confuse the parser if not removed. + + SKIP_FUNCTION_MACROS = YES + + #--------------------------------------------------------------------------- + # Configuration::addtions related to external references + #--------------------------------------------------------------------------- + + # The TAGFILES tag can be used to specify one or more tagfiles. + + TAGFILES = + + # When a file name is specified after GENERATE_TAGFILE, doxygen will create + # a tag file that is based on the input files it reads. + + GENERATE_TAGFILE = + + # If the ALLEXTERNALS tag is set to YES all external classes will be listed + # in the class index. If set to NO only the inherited external classes + # will be listed. + + ALLEXTERNALS = YES + + # The PERL_PATH should be the absolute path and name of the perl script + # interpreter (i.e. the result of `which perl'). + + PERL_PATH = + + #--------------------------------------------------------------------------- + # Configuration options related to the dot tool + #--------------------------------------------------------------------------- + + # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will generate a + # inheritance diagram (in Html, RTF and LaTeX) for classes with base or super + # classes. Setting the tag to NO turns the diagrams off. Note that this option + # is superceded by the HAVE_DOT option below. This is only a fallback. It is + # recommended to install and use dot, since it yield more powerful graphs. + + CLASS_DIAGRAMS = YES + + # If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is + # available from the path. This tool is part of Graphviz, a graph visualization + # toolkit from AT&T and Lucent Bell Labs. The other options in this section + # have no effect if this option is set to NO (the default) + + HAVE_DOT = YES + + # If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen + # will generate a graph for each documented class showing the direct and + # indirect inheritance relations. Setting this tag to YES will force the + # the CLASS_DIAGRAMS tag to NO. + + CLASS_GRAPH = YES + + # If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen + # will generate a graph for each documented class showing the direct and + # indirect implementation dependencies (inheritance, containment, and + # class references variables) of the class with other documented classes. + + COLLABORATION_GRAPH = YES + + # If set to YES, the inheritance and collaboration graphs will show the + # relations between templates and their instances. + + TEMPLATE_RELATIONS = YES + + # If set to YES, the inheritance and collaboration graphs will hide + # inheritance and usage relations if the target is undocumented + # or is not a class. + + HIDE_UNDOC_RELATIONS = NO + + # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT + # tags are set to YES then doxygen will generate a graph for each documented + # file showing the direct and indirect include dependencies of the file with + # other documented files. + + INCLUDE_GRAPH = YES + + # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and + # HAVE_DOT tags are set to YES then doxygen will generate a graph for each + # documented header file showing the documented files that directly or + # indirectly include this file. + + INCLUDED_BY_GRAPH = YES + + # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen + # will graphical hierarchy of all classes instead of a textual one. + + GRAPHICAL_HIERARCHY = YES + + # The tag DOT_PATH can be used to specify the path where the dot tool can be + # found. If left blank, it is assumed the dot tool can be found on the path. + + DOT_PATH = + + # The DOTFILE_DIRS tag can be used to specify one or more directories that + # contain dot files that are included in the documentation (see the + # \dotfile command). + + DOTFILE_DIRS = + + # The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width + # (in pixels) of the graphs generated by dot. If a graph becomes larger than + # this value, doxygen will try to truncate the graph, so that it fits within + # the specified constraint. Beware that most browsers cannot cope with very + # large images. + + MAX_DOT_GRAPH_WIDTH = 1024 + + # The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height + # (in pixels) of the graphs generated by dot. If a graph becomes larger than + # this value, doxygen will try to truncate the graph, so that it fits within + # the specified constraint. Beware that most browsers cannot cope with very + # large images. + + MAX_DOT_GRAPH_HEIGHT = 1024 + + # If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will + # generate a legend page explaining the meaning of the various boxes and + # arrows in the dot generated graphs. + + GENERATE_LEGEND = YES + + # If the DOT_CLEANUP tag is set to YES (the default) Doxygen will + # remove the intermedate dot files that are used to generate + # the various graphs. + + DOT_CLEANUP = YES + + #--------------------------------------------------------------------------- + # Configuration::addtions related to the search engine + #--------------------------------------------------------------------------- + + # The SEARCHENGINE tag specifies whether or not a search engine should be + # used. If set to NO the values of all tags below this one will be ignored. + + SEARCHENGINE = NO + + # The CGI_NAME tag should be the name of the CGI script that + # starts the search engine (doxysearch) with the correct parameters. + # A script with this name will be generated by doxygen. + + CGI_NAME = + + # The CGI_URL tag should be the absolute URL to the directory where the + # cgi binaries are located. See the documentation of your http daemon for + # details. + + CGI_URL = + + # The DOC_URL tag should be the absolute URL to the directory where the + # documentation is located. If left blank the absolute path to the + # documentation, with file:// prepended to it, will be used. + + DOC_URL = + + # The DOC_ABSPATH tag should be the absolute path to the directory where the + # documentation is located. If left blank the directory on the local machine + # will be used. + + DOC_ABSPATH = + + # The BIN_ABSPATH tag must point to the directory where the doxysearch binary + # is installed. + + BIN_ABSPATH = + + # The EXT_DOC_PATHS tag can be used to specify one or more paths to + # documentation generated for other projects. This allows doxysearch to search + # the documentation for these projects as well. + + EXT_DOC_PATHS = Index: llvm-www/releases/1.2/docs/doxygen.css diff -c /dev/null llvm-www/releases/1.2/docs/doxygen.css:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/doxygen.css Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,84 ---- + BODY { background: white; color: black; font-family: Verdana,Arial,sans-serif; } + H1 { text-align: center; } + H2 { text-align: center; } + H3 { text-align: center; } + CAPTION { font-weight: bold } + 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 } + A:link { + cursor: pointer; + text-decoration: none; + font-weight: bolder; + } + A:visited { + cursor: pointer; + text-decoration: underline; + font-weight: bolder; + } + A:hover { + cursor: pointer; + text-decoration: underline; + font-weight: bolder; + } + A:active { + cursor: pointer; + text-decoration: underline; + font-weight: bolder; + font-style: italic; + } + DL.el { margin-left: -1cm } + DIV.fragment { width: 100%; border: none; background-color: #eeeeee } + DIV.ah { background-color: black; font-weight: bold; color: #ffffff; margin-bottom: 3px; margin-top: 3px } + TD.md { background-color: #f2f2ff; font-weight: bold; } + TD.mdname1 { background-color: #f2f2ff; font-weight: bold; color: #602020; } + TD.mdname { background-color: #f2f2ff; font-weight: bold; color: #602020; width: 600px; } + DIV.groupHeader { margin-left: 16px; margin-top: 12px; margin-bottom: 6px; font-weight: bold } + DIV.groupText { margin-left: 16px; font-style: italic; font-size: smaller } + TD.indexkey { + background-color: #eeeeff; + font-weight: bold; + padding-right : 10px; + padding-top : 2px; + padding-left : 10px; + padding-bottom : 2px; + margin-left : 0px; + margin-right : 0px; + margin-top : 2px; + margin-bottom : 2px + } + TD.indexvalue { + background-color: #eeeeff; + font-style: italic; + padding-right : 10px; + padding-top : 2px; + padding-left : 10px; + padding-bottom : 2px; + margin-left : 0px; + margin-right : 0px; + margin-top : 2px; + margin-bottom : 2px + } + span.keyword { color: #008000 } + span.keywordtype { color: #604020 } + span.keywordflow { color: #e08000 } + span.comment { color: #800000 } + span.preprocessor { color: #806020 } + span.stringliteral { color: #002080 } + span.charliteral { color: #008080 } + + .footer { + font-size: 80%; + font-weight: bold; + text-align: center; + vertical-align: middle; + } + .title { + font-size: 105% + font-weight: bold; + text-decoration: underline; + text-align: center; + } Index: llvm-www/releases/1.2/docs/doxygen.footer diff -c /dev/null llvm-www/releases/1.2/docs/doxygen.footer:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/doxygen.footer Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,9 ---- +
      +

      + Generated on $datetime for $projectname version $projectnumber by + doxygen $doxygenversion
      + Copyright © 2003, University of Illinois at Urbana-Champaign. All Rights Reserved.
      + Home Page + + Doxygen Logo +

      Index: llvm-www/releases/1.2/docs/doxygen.header diff -c /dev/null llvm-www/releases/1.2/docs/doxygen.header:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/doxygen.header Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,9 ---- + + + + + + LLVM: $title + + +

      LLVM API Documentation

      Index: llvm-www/releases/1.2/docs/doxygen.intro diff -c /dev/null llvm-www/releases/1.2/docs/doxygen.intro:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/doxygen.intro Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,25 ---- + //////////////////////////////////////////////////////////////////////////////// + /// @file doxygen.intro + /// @author Reid Spencer + /// @date 2003/12/30 + /// @brief LLVM API documentation introduction. + //////////////////////////////////////////////////////////////////////////////// + /// + /// @mainpage LLVM:Low Level Virtual Machine + /// + /// @section main_intro Introduction + /// Welcome to the Low Level Virtual Machine (LLVM) + /// + /// This documentation describes the @b internal software that makes + /// up LLVM, not the @b external use of LLVM. There are no instructions + /// here on how to use LLVM, only the APIs that make up the software. For usage + /// instructions, please see the programmer's guide or reference manual. + /// + /// @section main_caveat Caveat + /// This documentation is generated directly from the source code with doxygen. + /// Since LLVM is constantly under active development, what you're about to + /// read is out of date! However, it may still be useful since certain portions of + /// LLVM are very stable. + /// + /// @section main_changelog Change Log + /// - Original content written 12/30/2003 by Reid Spencer Index: llvm-www/releases/1.2/docs/index.html diff -c /dev/null llvm-www/releases/1.2/docs/index.html:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/index.html Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,293 ---- + + + The LLVM Compiler Infrastructure + + + + +
      +

      + The LLVM Compiler Infrastructure +
      + http://llvm.cs.uiuc.edu +

      +
      + +
      + +

      + Welcome to LLVM! +

      + This file is intended to do four things: +
        +
      1. + help you get started using LLVM; +
        2. + +
      2. + tell you how to get questions about LLVM answered; +
        3. + +
      3. + tell you where to find documentation for different kinds of questions; and +
        4. + +
      4. + tell you about three LLVM-related mailing lists. +
        5. +
      + + +
      + +

      + Getting Started with LLVM +

      + +
      +
      + For license information: +
      + llvm/LICENSE.TXT +

      + +

      + Installing and compiling LLVM: +
      + llvm/docs/GettingStarted.html +

      + +

      + Learn about features and limitations of this release: +
      + llvm/docs/ReleaseNotes.html +

      + +

      + Learn how to write a pass within the LLVM system: +
      + llvm/docs/WritingAnLLVMPass.html +

      + +

      + Learn how to start a new development project using LLVM, where your + new source code can live anywhere (outside or inside the LLVM tree), + while using LLVM header files and libraries: +
      + llvm/docs/Projects.html +
      + +
      + +

      + Getting Help with LLVM +

      + +
        +
      1. + If you have questions or development problems not answered in the + documentation, send e-mail to llvmdev at cs.uiuc.edu. This mailing list is + monitored by all the people in the LLVM group at Illinois, and you + should expect prompt first responses. +
        2. + +
      2. + To report a bug, submit a bug report as described in the document: + + http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html +
        3. + +
      3. + We now use Bugzilla to track bugs, so you can check the status of + previous bugs at: + + http://llvm.cs.uiuc.edu/bugs/query.cgi +
        4. +
      + +
      + +

      + LLVM Documentation +

      + + All the documents mentioned below except the design overview tech report + are included as part of the LLVM release (in llvm/docs/*): + +

      + LLVM Design Overview: +

      + +
      +
      + LLVM: A Compilation Framework for Lifelong Program Analysis + & Transformation +
      + + http://llvm.cs.uiuc.edu/pubs/2004-01-30-CGO-LLVM.html + +
      + +

      + LLVM User Guides: +

      + +
      +
      + Download and Installation Instructions: +
      + llvm/docs/GettingStarted.html +

      + +

      + LLVM Command Guide: +
      + + llvm/docs/CommandGuide/index.html +

      + +

      + LLVM Assembly Language: +
      + llvm/docs/LangRef.html +

      + +

      + LLVM Test Suite Guide: +
      + llvm/docs/TestingGuide.html +

      +

      + +

      + LLVM Programming Documentation: +

      + +
      +
      + LLVM Programmers Manual: +
      + llvm/docs/ProgrammersManual.html +

      + +

      + Writing an LLVM Pass: +
      + llvm/docs/WritingAnLLVMPass.html +

      + +

      + Alias Analysis in LLVM: +
      + llvm/docs/AliasAnalysis.html +

      + +

      + Source Level Debugging with LLVM: +
      + llvm/docs/SourceLevelDebugging.html +

      + + +

      + TableGen Fundamentals: +
      + llvm/docs/TableGenFundamentals.html +

      + + +

      + The Stacker Cronicles +
      + The Stacker Cronicles + - This document describes both the Stacker language and + LLVM frontend, but also some details about LLVM useful for + those writing front-ends.

      + + +

      + Command Line Library: +
      + llvm/docs/CommandLine.html +

      + +

      + Coding Standards: +
      + llvm/docs/CodingStandards.html +

      +

      + +

      + Other LLVM Resources: +

      + +
      +
      + Building the LLVM C/C++ front-end: +
      + llvm/docs/CFEBuildInstrs.html +

      +

      + Submitting a Bug: +
      + + http://llvm.cs.uiuc.edu/docs/HowToSubmitABug.html +

      + +

      + Open Projects: +
      + llvm/docs/OpenProjects.html +

      + +

      + Creating a new LLVM Project: +
      + llvm/docs/Projects.html +

      +

      + +
      + +

      + Mailing Lists +

      + There are three mailing lists for providing LLVM users with information: + +
        +
      1. LLVM Announcements List:
        + + http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce + +

        + This is a low volume list that provides important announcements regarding + LLVM. It is primarily intended to announce new releases, major updates to + the software, etc. This list is highly recommended for anyone that uses + LLVM. +

        + +
      2. LLVM Developers List:
        + + http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev + +

        + This list is for people who want to be included in technical discussions + of LLVM. People post to this list when they have questions about writing + code for or using the LLVM tools. It is relatively low volume. +

        + +
      3. LLVM Commits List
        + + http://mail.cs.uiuc.edu/mailman/listinfo/llvm-commits + +

        + This list contains all commit messages that are made when LLVM developers + commit code changes to the CVS archive. It is useful for those who want to + stay on the bleeding edge of LLVM development. This list is very high + volume. +

        +
      + + + Index: llvm-www/releases/1.2/docs/llvm.css diff -c /dev/null llvm-www/releases/1.2/docs/llvm.css:1.1 *** /dev/null Fri Mar 19 11:38:22 2004 --- llvm-www/releases/1.2/docs/llvm.css Fri Mar 19 11:38:11 2004 *************** *** 0 **** --- 1,52 ---- + /* + * LLVM website style sheet + */ + + /* Common styles */ + .body { color: black; background: white; margin: 0 0 0 0 } + + /* No borders on image links */ + a:link img, a:visited img {border-style: none} + + address img { float: right; width: 88px; height: 31px; } + address { clear: right; } + + /* + * Documentation + */ + /* Common for title and header */ + .doc_title, .doc_section, .doc_subsection { + color: #ffffff; background: #330077; + font-family: "Georgia,Palatino,Times,Roman"; font-weight: bold; + padding-left: 8pt; + padding-top: 1px; + padding-bottom: 2px + } + + .doc_title { text-align: left; font-size: 25pt } + .doc_section { text-align: center; font-size: 22pt; } + .doc_subsection { background: #441188; width: 50%; + text-align: left; font-size: 12pt; padding: 4pt 4pt 4pt 4pt; + margin: 1.5em 0.5em 1.5em 0.5em } + + /* In the future, the 2nd level subsection style may want to become this: + .doc_subsubsection { margin: 1.5em 0.5em 1.5 0.5em; + font-weight: bold; font-style: oblique; + border-bottom: 2px dotted #999999 } + */ + + /* However, to be consistent with the rest of current documentation which is not + all yet using stylesheets, we try to emulate the former layout. */ + .doc_subsubsection { margin: 1.5em 0.5em 1.5em 0.5em; + font-weight: bold; + border-top: 2px solid #cecece } + + .doc_text { text-align: left; padding-left: 20pt } + + .doc_footer { text-align: left; padding: 0 0 0 0 } + + .doc_red { color: red } + + .doc_table { text-align: center; width: 90%; + padding: 1px 1px 1px 1px; border: 1px; } + Index: llvm-www/releases/1.2/docs/venusflytrap.jpg From lattner at cs.uiuc.edu Fri Mar 19 12:48:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 12:48:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/announcement.txt Message-ID: <200403191847.MAA31880@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: announcement.txt updated: 1.2 -> 1.3 --- Log message: Expand a bit --- Diffs of the changes: (+15 -10) Index: llvm-www/releases/1.2/announcement.txt diff -u llvm-www/releases/1.2/announcement.txt:1.2 llvm-www/releases/1.2/announcement.txt:1.3 --- llvm-www/releases/1.2/announcement.txt:1.2 Fri Mar 19 11:36:30 2004 +++ llvm-www/releases/1.2/announcement.txt Fri Mar 19 12:47:28 2004 @@ -8,11 +8,13 @@ WHAT IS LLVM? LLVM is a new infrastructure designed for compile-time, link-time, runtime, - and "idle-time" optimization of programs from arbitrary programming - languages. LLVM is written in C++ and has been developed over the past 4 - years at the University of Illinois. It currently supports compilation of - C and C++ programs using front-ends derived from GCC 3.4. New front-ends - are being written for Java bytecode and CAML. + and "idle-time" optimization of programs from arbitrary programming languages. + LLVM is written in C++ and has been developed over the past 4 years at the + University of Illinois. It currently supports compilation of C and C++ + programs using front-ends derived from GCC 3.4. After optimization, it can + emit native X86, native SparcV9, or C code for the optimized program. New + front-ends are in early development for Java bytecode and CAML, and new + backends are in early development for several other targets. The LLVM infrastructure is publicly available under a non-restrictive open source license. More information about LLVM and the contents of the @@ -20,15 +22,18 @@ WHAT IS NEW IN LLVM 1.2? - This release is primarily a bugfix release featuring several substantial - speedups and improvements in implementation. This release also includes a - new preliminary LLVM source level debugger and an experimental linear scan - register allocator. + This release is substantially faster and introduces several new features, + including: new optimizations, support for several GCC extensions that were not + supported in 1.1, and support for profile-guided optimization. The X86 code + generator in LLVM 1.2 also produces much better native code, and LLVM now + comes with a beta-quality global register allocator. Finally, LLVM 1.2 + includes the usual collection of bug fixes and other minor improvements. A full list of new features and bug-fixes are listed in the Release Notes: http://llvm.cs.uiuc.edu/releases/1.2/docs/ReleaseNotes.html#whatsnew - For an easier to read set of changes, please see the status update: + For an easier to read set of changes, please see the status updates: + http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-March/000006.html http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-February/000005.html HOW DO I GET IT? From lattner at cs.uiuc.edu Fri Mar 19 13:23:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 13:23:01 2004 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403191922.NAA32486@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.154 -> 1.155 --- Log message: Add a dose of reality into the release notes --- Diffs of the changes: (+2 -2) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.154 llvm/docs/ReleaseNotes.html:1.155 --- llvm/docs/ReleaseNotes.html:1.154 Thu Mar 18 22:26:04 2004 +++ llvm/docs/ReleaseNotes.html Fri Mar 19 13:22:28 2004 @@ -602,7 +602,7 @@
        -
      • None so far. +
      • There are several programs in the LLVM testsuite that the Sparc code generator is known to miscompile.
      @@ -664,7 +664,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/19 04:26:04 $ + Last modified: $Date: 2004/03/19 19:22:28 $ From lattner at cs.uiuc.edu Fri Mar 19 13:24:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 13:24:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/ReleaseNotes.html Message-ID: <200403191923.NAA00486@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs: ReleaseNotes.html updated: 1.1 -> 1.2 --- Log message: Reality sucks --- Diffs of the changes: (+2 -2) Index: llvm-www/releases/1.2/docs/ReleaseNotes.html diff -u llvm-www/releases/1.2/docs/ReleaseNotes.html:1.1 llvm-www/releases/1.2/docs/ReleaseNotes.html:1.2 --- llvm-www/releases/1.2/docs/ReleaseNotes.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/ReleaseNotes.html Fri Mar 19 13:23:19 2004 @@ -602,7 +602,7 @@
        -
      • None so far. +
      • There are several programs in the LLVM testsuite that the Sparc code generator is known to miscompile.
      @@ -664,7 +664,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 19:23:19 $ From criswell at cs.uiuc.edu Fri Mar 19 14:09:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 14:09:01 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200403192008.OAA10820@choi.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.153 -> 1.153.2.1 --- Log message: Updated to latest revision in the trunk. Fixed some typos. --- Diffs of the changes: (+6 -6) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.153 llvm/docs/ReleaseNotes.html:1.153.2.1 --- llvm/docs/ReleaseNotes.html:1.153 Tue Mar 16 21:54:41 2004 +++ llvm/docs/ReleaseNotes.html Fri Mar 19 14:08:17 2004 @@ -121,12 +121,12 @@
  • LLVM now no longer depends on the boost library.
    • -
  • The X86 backend now generates substantially better native code, and is faster.
    • +
  • The X86 backend now generates substantially better native code and is faster.
  • The C backend has been turned moved from the "llvm-dis" tool to the "llc" tool. You can activate it with "llc -march=c foo.bc -o foo.c".
  • LLVM includes a new interprocedural optimization that marks global variables "constant" when they are provably never written to.
    • -
  • LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which is often improve the performance of C++ programs substantially.
    • +
  • LLVM now includes a new interprocedural optimization that converts small "by reference" arguments to "by value" arguments, which often improves the performance of C++ programs substantially.
  • Bugpoint can now do a better job reducing miscompilation problems by reducing programs down to a particular loop nest, instead of just the function being miscompiled.
    • @@ -145,7 +145,7 @@
    1. Exception handling in the X86 & Sparc native code generators is now supported
      2. -
    2. The C/C++ front-end now support the GCC __builtin_return_address and __builtin_frame_address extensions. These are also supported by the X86 backend and by the C backend.
      3. +
    3. The C/C++ front-end now supports the GCC __builtin_return_address and __builtin_frame_address extensions. These are also supported by the X86 backend and by the C backend.
    4. [X86] Missing cast from ULong -> Double, cast FP -> bool and support for -9223372036854775808
    5. The C/C++ front-end now supports the "labels as values" GCC extension, often used to build "threaded interpreters".
      6. @@ -231,7 +231,7 @@
    6. [JIT] Programs cannot resolve the fstat function
    7. [indvars] Induction variable analysis violates LLVM invariants
    8. [execution engines] Unhandled cast constant expression
      9. - +
    9. [Sparc] Code generator asserts on alloca of zero size type
    @@ -602,7 +602,7 @@
      -
    • None so far. +
    • There are several programs in the LLVM testsuite that the Sparc code generator is known to miscompile.
    @@ -664,7 +664,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
    - Last modified: $Date: 2004/03/17 03:54:41 $ + Last modified: $Date: 2004/03/19 20:08:17 $ From criswell at cs.uiuc.edu Fri Mar 19 14:58:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 14:58:01 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/LLVMVsTheWorld.html Message-ID: <200403192057.OAA18781@choi.cs.uiuc.edu> Changes in directory llvm/docs: LLVMVsTheWorld.html (r1.7) removed --- Log message: Not ready for prime time. --- Diffs of the changes: (+0 -0) From criswell at cs.uiuc.edu Fri Mar 19 15:08:07 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 15:08:07 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/llvm-1.2.tar.gz Message-ID: <200403192108.PAA01049@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: llvm-1.2.tar.gz updated: 1.1 -> 1.2 --- Log message: LLVM 1.2 RC2: this time, actually get the SparcV9 fix in! Some docs are updated too. :) --- Diffs of the changes: (+0 -0) Index: llvm-www/releases/1.2/llvm-1.2.tar.gz From criswell at cs.uiuc.edu Fri Mar 19 16:00:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 16:00:01 2004 Subject: [llvm-commits] [release_12] CVS: llvm/docs/GettingStarted.html Message-ID: <200403192159.PAA24445@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.51.2.1 -> 1.51.2.2 --- Log message: Updated code and source sizes. Fixed some minor typos. --- Diffs of the changes: (+12 -12) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.51.2.1 llvm/docs/GettingStarted.html:1.51.2.2 --- llvm/docs/GettingStarted.html:1.51.2.1 Wed Mar 17 14:07:32 2004 +++ llvm/docs/GettingStarted.html Fri Mar 19 15:59:23 2004 @@ -182,10 +182,10 @@
  • Linux on x86 (Pentium and above)
      -
    • Approximately 918 MB of Free Disk Space +
    • Approximately 1.02 GB of Free Disk Space
        -
      • Source code: 28 MB
        • -
      • Object code: 850 MB
        • +
      • Source code: 45 MB
        • +
      • Object code: 956 MB
      • GCC front end: 40 MB
    @@ -193,10 +193,10 @@
  • Solaris on SparcV9 (Ultrasparc)
      -
    • Approximately 1.52 GB of Free Disk Space +
    • Approximately 1.75 GB of Free Disk Space
        -
      • Source code: 28 MB
        • -
      • Object code: 1470 MB
        • +
      • Source code: 45 MB
        • +
      • Object code: 1705 MB
      • GCC front end: 50 MB
    @@ -204,9 +204,9 @@
  • FreeBSD on x86 (Pentium and above)
      -
    • Approximately 918 MB of Free Disk Space +
    • Approximately 935 MB of Free Disk Space
        -
      • Source code: 28 MB
        • +
      • Source code: 45 MB
      • Object code: 850 MB
      • GCC front end: 40 MB
      • @@ -216,9 +216,9 @@
    • MacOS X on PowerPC
      • No native code generation -
      • Approximately 1.20 GB of Free Disk Space +
      • Approximately 1.25 GB of Free Disk Space
          -
        • Source code: 28 MB
          • +
        • Source code: 45 MB
        • Object code: 1160 MB
        • GCC front end: 40 MB
        • @@ -871,7 +871,7 @@
        llvm/lib/Target/
        This directory contains files that describe various target architectures for code generation. For example, - the llvm/lib/Target/Sparc directory holds the Sparc machine + the llvm/lib/Target/SparcV9 directory holds the Sparc machine description.
        llvm/lib/CodeGen/
        This directory contains the major parts @@ -1183,7 +1183,7 @@ Chris Lattner
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/17 20:07:32 $ + Last modified: $Date: 2004/03/19 21:59:23 $ From lattner at cs.uiuc.edu Fri Mar 19 16:01:02 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 16:01:02 2004 Subject: [llvm-commits] CVS: llvm-www/releases/download.html register.html Message-ID: <200403192200.QAA23211@zion.cs.uiuc.edu> Changes in directory llvm-www/releases: download.html updated: 1.11 -> 1.12 register.html updated: 1.6 -> 1.7 --- Log message: Minor tweaks --- Diffs of the changes: (+8 -6) Index: llvm-www/releases/download.html diff -u llvm-www/releases/download.html:1.11 llvm-www/releases/download.html:1.12 --- llvm-www/releases/download.html:1.11 Sun Feb 22 19:52:31 2004 +++ llvm-www/releases/download.html Fri Mar 19 16:00:21 2004 @@ -13,7 +13,7 @@
        If you signed up for the LLVM Announcements list, you should receive a -confirmation email. If you don't, you can register for the mailing list at +confirmation email. If you did't, you can register for the mailing list at http://mail.cs.uiuc.edu/mailman/listinfo/llvm-announce . @@ -28,7 +28,8 @@ see the instructions for accessing the LLVM CVS Repository. The major changes and improvements that CVS contains relative to the previous release are -listed in the Release Notes. +listed in the Release Notes for the +next release.
        Index: llvm-www/releases/register.html diff -u llvm-www/releases/register.html:1.6 llvm-www/releases/register.html:1.7 --- llvm-www/releases/register.html:1.6 Fri Dec 19 11:23:13 2003 +++ llvm-www/releases/register.html Fri Mar 19 16:00:21 2004 @@ -72,7 +72,8 @@

        -The LLVM Announcements List is a low volume mailing list that provides LLVM +The LLVM Announcements List is a low volume mailing list (approximately one +email a month) that provides LLVM users with important information on new LLVM releases. If you would like to subscribe to this list, please select "yes" and respond to the confirmation email that you will receive (your email address will be your password): @@ -86,9 +87,9 @@ No

        -We would be interested to know how you plan to use LLVM. -
        -This information is strictly optional and will be kept completely confidential:
        +We are interested to know how you plan to use LLVM. +This information is strictly optional and will be kept completely +confidential:

        From criswell at cs.uiuc.edu Fri Mar 19 16:03:01 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 16:03:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/llvm-1.2.tar.gz Message-ID: <200403192202.QAA23414@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2: llvm-1.2.tar.gz updated: 1.2 -> 1.3 --- Log message: LLVM 1.2, RC3: Updated some docs. No code changes that I'm aware of. --- Diffs of the changes: (+0 -0) Index: llvm-www/releases/1.2/llvm-1.2.tar.gz From lattner at cs.uiuc.edu Fri Mar 19 16:05:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 16:05:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/register.html Message-ID: <200403192204.QAA23453@zion.cs.uiuc.edu> Changes in directory llvm-www/releases: register.html updated: 1.7 -> 1.8 --- Log message: More minor tweaks --- Diffs of the changes: (+7 -3) Index: llvm-www/releases/register.html diff -u llvm-www/releases/register.html:1.7 llvm-www/releases/register.html:1.8 --- llvm-www/releases/register.html:1.7 Fri Mar 19 16:00:21 2004 +++ llvm-www/releases/register.html Fri Mar 19 16:04:12 2004 @@ -28,6 +28,9 @@
        +

        If you have registered with us in the past, there is no need to do so again. +Please enter your email address for verification.

        + @@ -72,8 +75,9 @@

        -The LLVM Announcements List is a low volume mailing list (approximately one -email a month) that provides LLVM +The LLVM Announcements List is a low volume mailing list (approximately one +email a month) that provides LLVM users with important information on new LLVM releases. If you would like to subscribe to this list, please select "yes" and respond to the confirmation email that you will receive (your email address will be your password): @@ -90,7 +94,7 @@ We are interested to know how you plan to use LLVM. This information is strictly optional and will be kept completely confidential:
        - +

        Finally, click "Download" to go to the download page:
        From criswell at cs.uiuc.edu Fri Mar 19 16:05:13 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 16:05:13 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/CommandGuide/index.html Message-ID: <200403192204.QAA23635@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs/CommandGuide: index.html updated: 1.1 -> 1.2 --- Log message: Updated documentation. --- Diffs of the changes: (+1 -1) Index: llvm-www/releases/1.2/docs/CommandGuide/index.html diff -u llvm-www/releases/1.2/docs/CommandGuide/index.html:1.1 llvm-www/releases/1.2/docs/CommandGuide/index.html:1.2 --- llvm-www/releases/1.2/docs/CommandGuide/index.html:1.1 Fri Mar 19 11:38:13 2004 +++ llvm-www/releases/1.2/docs/CommandGuide/index.html Fri Mar 19 16:04:29 2004 @@ -116,7 +116,7 @@
        Maintained by the LLVM Team.
        -Last modified: $Date: 2004/03/19 17:38:13 $ +Last modified: $Date: 2004/03/19 22:04:29 $         From criswell at cs.uiuc.edu Fri Mar 19 16:05:24 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 16:05:24 2004 Subject: [llvm-commits] CVS: llvm-www/releases/1.2/docs/AliasAnalysis.html CFEBuildInstrs.html CodingStandards.html CommandLine.html FAQ.html GettingStarted.html HowToSubmitABug.html LangRef.html ObjectFiles.html OpenProjects.html ProgrammersManual.html Projects.html ReleaseNotes.html SourceLevelDebugging.html Stacker.html TableGenFundamentals.html TestingGuide.html WritingAnLLVMPass.html Message-ID: <200403192204.QAA24279@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.2/docs: AliasAnalysis.html updated: 1.1 -> 1.2 CFEBuildInstrs.html updated: 1.1 -> 1.2 CodingStandards.html updated: 1.1 -> 1.2 CommandLine.html updated: 1.1 -> 1.2 FAQ.html updated: 1.1 -> 1.2 GettingStarted.html updated: 1.1 -> 1.2 HowToSubmitABug.html updated: 1.1 -> 1.2 LangRef.html updated: 1.1 -> 1.2 ObjectFiles.html updated: 1.1 -> 1.2 OpenProjects.html updated: 1.1 -> 1.2 ProgrammersManual.html updated: 1.1 -> 1.2 Projects.html updated: 1.1 -> 1.2 ReleaseNotes.html updated: 1.2 -> 1.3 SourceLevelDebugging.html updated: 1.1 -> 1.2 Stacker.html updated: 1.1 -> 1.2 TableGenFundamentals.html updated: 1.1 -> 1.2 TestingGuide.html updated: 1.1 -> 1.2 WritingAnLLVMPass.html updated: 1.1 -> 1.2 --- Log message: Updated documentation. --- Diffs of the changes: (+33 -33) Index: llvm-www/releases/1.2/docs/AliasAnalysis.html diff -u llvm-www/releases/1.2/docs/AliasAnalysis.html:1.1 llvm-www/releases/1.2/docs/AliasAnalysis.html:1.2 --- llvm-www/releases/1.2/docs/AliasAnalysis.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/AliasAnalysis.html Fri Mar 19 16:04:17 2004 @@ -513,7 +513,7 @@ Chris Lattner
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/CFEBuildInstrs.html diff -u llvm-www/releases/1.2/docs/CFEBuildInstrs.html:1.1 llvm-www/releases/1.2/docs/CFEBuildInstrs.html:1.2 --- llvm-www/releases/1.2/docs/CFEBuildInstrs.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/CFEBuildInstrs.html Fri Mar 19 16:04:17 2004 @@ -272,7 +272,7 @@
        Brian Gaeke
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/CodingStandards.html diff -u llvm-www/releases/1.2/docs/CodingStandards.html:1.1 llvm-www/releases/1.2/docs/CodingStandards.html:1.2 --- llvm-www/releases/1.2/docs/CodingStandards.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/CodingStandards.html Fri Mar 19 16:04:17 2004 @@ -952,7 +952,7 @@
        Chris Lattner
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/CommandLine.html diff -u llvm-www/releases/1.2/docs/CommandLine.html:1.1 llvm-www/releases/1.2/docs/CommandLine.html:1.2 --- llvm-www/releases/1.2/docs/CommandLine.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/CommandLine.html Fri Mar 19 16:04:17 2004 @@ -1692,7 +1692,7 @@
        Chris Lattner
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/FAQ.html diff -u llvm-www/releases/1.2/docs/FAQ.html:1.1 llvm-www/releases/1.2/docs/FAQ.html:1.2 --- llvm-www/releases/1.2/docs/FAQ.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/FAQ.html Fri Mar 19 16:04:17 2004 @@ -483,7 +483,7 @@
        The LLVM Compiler Infrastructure
        - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $
        Index: llvm-www/releases/1.2/docs/GettingStarted.html diff -u llvm-www/releases/1.2/docs/GettingStarted.html:1.1 llvm-www/releases/1.2/docs/GettingStarted.html:1.2 --- llvm-www/releases/1.2/docs/GettingStarted.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/GettingStarted.html Fri Mar 19 16:04:17 2004 @@ -182,10 +182,10 @@
      • Linux on x86 (Pentium and above)
          -
        • Approximately 918 MB of Free Disk Space +
        • Approximately 1.02 GB of Free Disk Space
            -
          • Source code: 28 MB
            • -
          • Object code: 850 MB
            • +
          • Source code: 45 MB
            • +
          • Object code: 956 MB
          • GCC front end: 40 MB
        @@ -193,10 +193,10 @@
      • Solaris on SparcV9 (Ultrasparc)
          -
        • Approximately 1.52 GB of Free Disk Space +
        • Approximately 1.75 GB of Free Disk Space
            -
          • Source code: 28 MB
            • -
          • Object code: 1470 MB
            • +
          • Source code: 45 MB
            • +
          • Object code: 1705 MB
          • GCC front end: 50 MB
        @@ -204,9 +204,9 @@
      • FreeBSD on x86 (Pentium and above)
          -
        • Approximately 918 MB of Free Disk Space +
        • Approximately 935 MB of Free Disk Space
            -
          • Source code: 28 MB
            • +
          • Source code: 45 MB
          • Object code: 850 MB
          • GCC front end: 40 MB
          • @@ -216,9 +216,9 @@
        • MacOS X on PowerPC
          • No native code generation -
          • Approximately 1.20 GB of Free Disk Space +
          • Approximately 1.25 GB of Free Disk Space
              -
            • Source code: 28 MB
              • +
            • Source code: 45 MB
            • Object code: 1160 MB
            • GCC front end: 40 MB
            • @@ -871,7 +871,7 @@
            llvm/lib/Target/
            This directory contains files that describe various target architectures for code generation. For example, - the llvm/lib/Target/Sparc directory holds the Sparc machine + the llvm/lib/Target/SparcV9 directory holds the Sparc machine description.
            llvm/lib/CodeGen/
            This directory contains the major parts @@ -1183,7 +1183,7 @@ Chris Lattner
            The LLVM Compiler Infrastructure
            - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/HowToSubmitABug.html diff -u llvm-www/releases/1.2/docs/HowToSubmitABug.html:1.1 llvm-www/releases/1.2/docs/HowToSubmitABug.html:1.2 --- llvm-www/releases/1.2/docs/HowToSubmitABug.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/HowToSubmitABug.html Fri Mar 19 16:04:17 2004 @@ -317,7 +317,7 @@ Chris Lattner
            The LLVM Compiler Infrastructure
            - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/LangRef.html diff -u llvm-www/releases/1.2/docs/LangRef.html:1.1 llvm-www/releases/1.2/docs/LangRef.html:1.2 --- llvm-www/releases/1.2/docs/LangRef.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/LangRef.html Fri Mar 19 16:04:17 2004 @@ -2148,7 +2148,7 @@ Chris Lattner
            The LLVM Compiler Infrastructure
            - Last modified: $Date: 2004/03/19 17:38:11 $ + Last modified: $Date: 2004/03/19 22:04:17 $ Index: llvm-www/releases/1.2/docs/ObjectFiles.html diff -u llvm-www/releases/1.2/docs/ObjectFiles.html:1.1 llvm-www/releases/1.2/docs/ObjectFiles.html:1.2 --- llvm-www/releases/1.2/docs/ObjectFiles.html:1.1 Fri Mar 19 11:38:11 2004 +++ llvm-www/releases/1.2/docs/ObjectFiles.html Fri Mar 19 16:04:17 2004 @@ -291,7 +291,7 @@
            Reid Spencer
            The LLVM Compiler Infrastructure -
            Last modified: $Date: 2004/03/19 17:38:11 $
            +
            Last modified: $Date: 2004/03/19 22:04:17 $ + +
          • GCC Front End Binaries + for Solaris/Sparc (16.1M)
            • + +
          • GCC Front End Binaries + for MacOS X/PowerPC (12.2M)
            • + +
          • GCC Front End Source Code (32.4M)
            • +
          + + + +
          Download LLVM 1.1
          From lattner at cs.uiuc.edu Fri Mar 19 22:57:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 22:57:01 2004 Subject: [llvm-commits] CVS: llvm-www/releases/index.html Message-ID: <200403200456.WAA32033@zion.cs.uiuc.edu> Changes in directory llvm-www/releases: index.html updated: 1.12 -> 1.13 --- Log message: Link to 1.2 dox --- Diffs of the changes: (+5 -0) Index: llvm-www/releases/index.html diff -u llvm-www/releases/index.html:1.12 llvm-www/releases/index.html:1.13 --- llvm-www/releases/index.html:1.12 Fri Dec 19 00:42:07 2003 +++ llvm-www/releases/index.html Fri Mar 19 22:56:20 2004 @@ -39,6 +39,10 @@
          +

          The 1.2 release (19 Mar 2003) is available for +download. You can read the Release Notes +here.

          +

          The 1.1 release (17 Dec 2003) is available for download. You can read the Release Notes here.

          @@ -58,6 +62,7 @@ the documentation here:

            +
          • Complete documentation for release 1.2.
          • Complete documentation for release 1.1.
          • Complete documentation for release 1.0.
          • Up-to-date LLVM documentation From lattner at cs.uiuc.edu Fri Mar 19 22:59:01 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 22:59:01 2004 Subject: [llvm-commits] CVS: llvm-www/header.incl Message-ID: <200403200457.WAA32506@zion.cs.uiuc.edu> Changes in directory llvm-www: header.incl updated: 1.13 -> 1.14 --- Log message: Link to 1.2 --- Diffs of the changes: (+2 -2) Index: llvm-www/header.incl diff -u llvm-www/header.incl:1.13 llvm-www/header.incl:1.14 --- llvm-www/header.incl:1.13 Fri Feb 6 17:13:15 2004 +++ llvm-www/header.incl Fri Mar 19 22:57:17 2004 @@ -33,7 +33,7 @@ Download!
            Download now: -LLVM 1.1
            +LLVM 1.2

            Try the:
            @@ -41,7 +41,7 @@
            View the open-source
            -license +license

            From criswell at cs.uiuc.edu Fri Mar 19 22:59:12 2004 From: criswell at cs.uiuc.edu (John Criswell) Date: Fri Mar 19 22:59:12 2004 Subject: [llvm-commits] CVS: llvm-www/releases/index.html Message-ID: <200403200458.WAA32693@zion.cs.uiuc.edu> Changes in directory llvm-www/releases: index.html updated: 1.13 -> 1.14 --- Log message: Fix the year. --- Diffs of the changes: (+1 -1) Index: llvm-www/releases/index.html diff -u llvm-www/releases/index.html:1.13 llvm-www/releases/index.html:1.14 --- llvm-www/releases/index.html:1.13 Fri Mar 19 22:56:20 2004 +++ llvm-www/releases/index.html Fri Mar 19 22:58:08 2004 @@ -39,7 +39,7 @@
            -

            The 1.2 release (19 Mar 2003) is available for +

            The 1.2 release (19 Mar 2004) is available for download. You can read the Release Notes here.

            From lattner at cs.uiuc.edu Fri Mar 19 22:59:24 2004 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Fri Mar 19 22:59:24 2004 Subject: [llvm-commits] CVS: llvm-www/header.incl Message-ID: <200403200458.WAA00710@zion.cs.uiuc.edu> Changes in directory llvm-www: header.incl updated: 1.14 -> 1.15 --- Log message: Add link to new status update --- Diffs of the changes: (+1 -0) Index: llvm-www/header.incl diff -u llvm-www/header.incl:1.14 llvm-www/header.incl:1.15 --- llvm-www/header.incl:1.14 Fri Mar 19 22:57:17 2004 +++ llvm-www/header.incl Fri Mar 19 22:58:34 2004 @@ -49,6 +49,7 @@ Status Updates
            + March 19, 2004
            February 6, 2004
            December 17, 2003
            November 18, 2003