From criswell at cs.uiuc.edu Mon Nov 7 09:19:16 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 7 Nov 2005 09:19:16 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/cfrontend-1.6.i686-redhat-linux-gnu.tar.gz cfrontend-1.6.powerpc-apple-darwin7.9.0.tar.gz cfrontend-1.6.sparc-sun-solaris2.8.tar.gz Message-ID: <200511071519.JAA31527@choi.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6: cfrontend-1.6.i686-redhat-linux-gnu.tar.gz updated: 1.1 -> 1.2 cfrontend-1.6.powerpc-apple-darwin7.9.0.tar.gz updated: 1.1 -> 1.2 cfrontend-1.6.sparc-sun-solaris2.8.tar.gz updated: 1.1 -> 1.2 --- Log message: Re-built with Chris's SPEC fixes. Remembered to run llvm-ranlib on the libraries. --- Diffs of the changes: (+0 -0) cfrontend-1.6.i686-redhat-linux-gnu.tar.gz | 0 cfrontend-1.6.powerpc-apple-darwin7.9.0.tar.gz | 0 cfrontend-1.6.sparc-sun-solaris2.8.tar.gz | 0 3 files changed Index: llvm-www/releases/1.6/cfrontend-1.6.i686-redhat-linux-gnu.tar.gz Index: llvm-www/releases/1.6/cfrontend-1.6.powerpc-apple-darwin7.9.0.tar.gz Index: llvm-www/releases/1.6/cfrontend-1.6.sparc-sun-solaris2.8.tar.gz From alenhar2 at cs.uiuc.edu Mon Nov 7 10:23:35 2005 From: alenhar2 at cs.uiuc.edu (Andrew Lenharth) Date: Mon, 7 Nov 2005 10:23:35 -0600 Subject: [llvm-commits] CVS: llvm-www/testresults/index.html Message-ID: <200511071623.KAA07640@zion.cs.uiuc.edu> Changes in directory llvm-www/testresults: index.html updated: 1.39 -> 1.40 --- Log message: My machine only is run occasionally to test uncommitted patches, so remove it. fenris has been switched to release build. add nick's tester as it is the only alpha tester running a debug build. --- Diffs of the changes: (+5 -5) index.html | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) Index: llvm-www/testresults/index.html diff -u llvm-www/testresults/index.html:1.39 llvm-www/testresults/index.html:1.40 --- llvm-www/testresults/index.html:1.39 Thu Nov 3 18:28:36 2005 +++ llvm-www/testresults/index.html Mon Nov 7 10:23:24 2005 @@ -21,11 +21,11 @@

Alpha

    -
  1. Linux (Single 21164 EV56 500 -MHz) -- release build
  2. - -
  3. Linux (Single 21264 EV7 -633 MHz) -- debug build
  4. +
  5. Linux (Single 21264 EV67 +633 MHz) -- release build
  6. + +
  7. Linux (Dual 21264 +EV6 500 MHz) -- debug build

IA-64

From jlaskey at apple.com Mon Nov 7 13:09:04 2005 From: jlaskey at apple.com (Jim Laskey) Date: Mon, 7 Nov 2005 13:09:04 -0600 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Message-ID: <200511071909.NAA08917@zion.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen/SelectionDAG: ScheduleDAG.cpp updated: 1.42 -> 1.43 --- Log message: Let's try ignoring resource utilization on the backward pass. --- Diffs of the changes: (+2 -0) ScheduleDAG.cpp | 2 ++ 1 files changed, 2 insertions(+) Index: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp diff -u llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:1.42 llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:1.43 --- llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:1.42 Fri Nov 4 18:01:25 2005 +++ llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Mon Nov 7 13:08:53 2005 @@ -908,9 +908,11 @@ // If independent of others (or first entry) if (Slot == NotFound) Slot = 0; +#if 0 // FIXME - measure later // Find a slot where the needed resources are available if (NI->StageBegin != NI->StageEnd) Slot = Tally.FindAndReserve(Slot, NI->StageBegin, NI->StageEnd); +#endif // Set node slot NI->Slot = Slot; From criswell at cs.uiuc.edu Mon Nov 7 14:12:22 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 7 Nov 2005 14:12:22 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/cfrontend-1.6.source.tar.gz Message-ID: <200511072012.OAA32095@choi.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6: cfrontend-1.6.source.tar.gz updated: 1.1 -> 1.2 --- Log message: Merged in a fix from Chris. --- Diffs of the changes: (+0 -0) cfrontend-1.6.source.tar.gz | 0 1 files changed Index: llvm-www/releases/1.6/cfrontend-1.6.source.tar.gz From criswell at cs.uiuc.edu Mon Nov 7 14:49:18 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Mon, 7 Nov 2005 14:49:18 -0600 Subject: [llvm-commits] [release_16] CVS: llvm-test/MultiSource/Applications/Makefile Message-ID: <200511072049.OAA32404@choi.cs.uiuc.edu> Changes in directory llvm-test/MultiSource/Applications: Makefile updated: 1.21 -> 1.21.2.1 --- Log message: The hexxagon test does not work on Solaris as it lacks stdint.h. --- Diffs of the changes: (+1 -0) Makefile | 1 + 1 files changed, 1 insertion(+) Index: llvm-test/MultiSource/Applications/Makefile diff -u llvm-test/MultiSource/Applications/Makefile:1.21 llvm-test/MultiSource/Applications/Makefile:1.21.2.1 --- llvm-test/MultiSource/Applications/Makefile:1.21 Fri Aug 5 01:20:48 2005 +++ llvm-test/MultiSource/Applications/Makefile Mon Nov 7 14:48:54 2005 @@ -18,6 +18,7 @@ ifeq ($(OS),SunOS) PARALLEL_DIRS := $(filter-out SPASS, $(PARALLEL_DIRS)) +PARALLEL_DIRS := $(filter-out hexxagon, $(PARALLEL_DIRS)) endif include $(LEVEL)/Makefile.programs From lattner at cs.uiuc.edu Mon Nov 7 20:10:28 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:10:28 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/Target/TargetMachine.h Message-ID: <200511080210.UAA12446@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm/Target: TargetMachine.h updated: 1.58 -> 1.59 --- Log message: Add a new option to indicate we want the code generator to emit code quickly, not spending tons of time microoptimizing it. This is useful for an -O0 style of build. --- Diffs of the changes: (+4 -3) TargetMachine.h | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) Index: llvm/include/llvm/Target/TargetMachine.h diff -u llvm/include/llvm/Target/TargetMachine.h:1.58 llvm/include/llvm/Target/TargetMachine.h:1.59 --- llvm/include/llvm/Target/TargetMachine.h:1.58 Tue Nov 1 14:07:00 2005 +++ llvm/include/llvm/Target/TargetMachine.h Mon Nov 7 20:10:16 2005 @@ -143,11 +143,12 @@ /// addPassesToEmitFile - Add passes to the specified pass manager to get /// the specified file emitted. Typically this will involve several steps of - /// code generation. This method should return true if emission of this file - /// type is not supported. + /// code generation. If Fast is set to true, the code generator should emit + /// code as fast as possible, without regard for compile time. This method + /// should return true if emission of this file type is not supported. /// virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, bool Fast) { return true; } From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/SparcV8/SparcV8TargetMachine.cpp SparcV8TargetMachine.h Message-ID: <200511080212.UAA12665@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/SparcV8: SparcV8TargetMachine.cpp updated: 1.30 -> 1.31 SparcV8TargetMachine.h updated: 1.7 -> 1.8 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+3 -8) SparcV8TargetMachine.cpp | 3 ++- SparcV8TargetMachine.h | 8 +------- 2 files changed, 3 insertions(+), 8 deletions(-) Index: llvm/lib/Target/SparcV8/SparcV8TargetMachine.cpp diff -u llvm/lib/Target/SparcV8/SparcV8TargetMachine.cpp:1.30 llvm/lib/Target/SparcV8/SparcV8TargetMachine.cpp:1.31 --- llvm/lib/Target/SparcV8/SparcV8TargetMachine.cpp:1.30 Sat Oct 29 00:28:34 2005 +++ llvm/lib/Target/SparcV8/SparcV8TargetMachine.cpp Mon Nov 7 20:11:51 2005 @@ -65,7 +65,8 @@ /// bool SparcV8TargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; // FIXME: Implement efficient support for garbage collection intrinsics. Index: llvm/lib/Target/SparcV8/SparcV8TargetMachine.h diff -u llvm/lib/Target/SparcV8/SparcV8TargetMachine.h:1.7 llvm/lib/Target/SparcV8/SparcV8TargetMachine.h:1.8 --- llvm/lib/Target/SparcV8/SparcV8TargetMachine.h:1.7 Thu Sep 1 16:38:21 2005 +++ llvm/lib/Target/SparcV8/SparcV8TargetMachine.h Mon Nov 7 20:11:51 2005 @@ -45,17 +45,11 @@ static unsigned getModuleMatchQuality(const Module &M); static unsigned getJITMatchQuality(); - /// addPassesToEmitMachineCode - Add passes to the specified pass manager to - /// get machine code emitted. This uses a MachineCodeEmitter object to handle - /// actually outputting the machine code and resolving things like the address - /// of functions. This method should returns true if machine code emission is - /// not supported. - /// virtual bool addPassesToEmitMachineCode(FunctionPassManager &PM, MachineCodeEmitter &MCE); virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); }; } // end namespace llvm From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/CBackend/CTargetMachine.h Writer.cpp Message-ID: <200511080212.UAA12687@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/CBackend: CTargetMachine.h updated: 1.8 -> 1.9 Writer.cpp updated: 1.246 -> 1.247 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+2 -2) CTargetMachine.h | 2 +- Writer.cpp | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/lib/Target/CBackend/CTargetMachine.h diff -u llvm/lib/Target/CBackend/CTargetMachine.h:1.8 llvm/lib/Target/CBackend/CTargetMachine.h:1.9 --- llvm/lib/Target/CBackend/CTargetMachine.h:1.8 Thu Sep 1 16:38:20 2005 +++ llvm/lib/Target/CBackend/CTargetMachine.h Mon Nov 7 20:11:51 2005 @@ -26,7 +26,7 @@ // This is the only thing that actually does anything here. virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); // This class always works, but shouldn't be the default in most cases. static unsigned getModuleMatchQuality(const Module &M) { return 1; } Index: llvm/lib/Target/CBackend/Writer.cpp diff -u llvm/lib/Target/CBackend/Writer.cpp:1.246 llvm/lib/Target/CBackend/Writer.cpp:1.247 --- llvm/lib/Target/CBackend/Writer.cpp:1.246 Wed Nov 2 11:42:58 2005 +++ llvm/lib/Target/CBackend/Writer.cpp Mon Nov 7 20:11:51 2005 @@ -1725,7 +1725,7 @@ //===----------------------------------------------------------------------===// bool CTargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &o, - CodeGenFileType FileType) { + CodeGenFileType FileType, bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; PM.add(createLowerGCPass()); From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/SparcV9/SparcV9TargetMachine.cpp SparcV9TargetMachine.h Message-ID: <200511080212.UAA12701@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/SparcV9: SparcV9TargetMachine.cpp updated: 1.143 -> 1.144 SparcV9TargetMachine.h updated: 1.14 -> 1.15 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+3 -2) SparcV9TargetMachine.cpp | 3 ++- SparcV9TargetMachine.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) Index: llvm/lib/Target/SparcV9/SparcV9TargetMachine.cpp diff -u llvm/lib/Target/SparcV9/SparcV9TargetMachine.cpp:1.143 llvm/lib/Target/SparcV9/SparcV9TargetMachine.cpp:1.144 --- llvm/lib/Target/SparcV9/SparcV9TargetMachine.cpp:1.143 Wed Oct 19 15:07:15 2005 +++ llvm/lib/Target/SparcV9/SparcV9TargetMachine.cpp Mon Nov 7 20:11:51 2005 @@ -162,7 +162,8 @@ /// bool SparcV9TargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; // FIXME: Implement efficient support for garbage collection intrinsics. Index: llvm/lib/Target/SparcV9/SparcV9TargetMachine.h diff -u llvm/lib/Target/SparcV9/SparcV9TargetMachine.h:1.14 llvm/lib/Target/SparcV9/SparcV9TargetMachine.h:1.15 --- llvm/lib/Target/SparcV9/SparcV9TargetMachine.h:1.14 Thu Sep 1 16:38:21 2005 +++ llvm/lib/Target/SparcV9/SparcV9TargetMachine.h Mon Nov 7 20:11:51 2005 @@ -45,7 +45,7 @@ } virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); virtual bool addPassesToEmitMachineCode(FunctionPassManager &PM, MachineCodeEmitter &MCE); From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/X86/X86TargetMachine.cpp X86TargetMachine.h Message-ID: <200511080212.UAA12674@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/X86: X86TargetMachine.cpp updated: 1.86 -> 1.87 X86TargetMachine.h updated: 1.30 -> 1.31 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+3 -8) X86TargetMachine.cpp | 3 ++- X86TargetMachine.h | 8 +------- 2 files changed, 3 insertions(+), 8 deletions(-) Index: llvm/lib/Target/X86/X86TargetMachine.cpp diff -u llvm/lib/Target/X86/X86TargetMachine.cpp:1.86 llvm/lib/Target/X86/X86TargetMachine.cpp:1.87 --- llvm/lib/Target/X86/X86TargetMachine.cpp:1.86 Thu Sep 1 16:38:21 2005 +++ llvm/lib/Target/X86/X86TargetMachine.cpp Mon Nov 7 20:11:51 2005 @@ -106,7 +106,8 @@ // addPassesToEmitFile - We currently use all of the same passes as the JIT // does to emit statically compiled machine code. bool X86TargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile && FileType != TargetMachine::ObjectFile) return true; Index: llvm/lib/Target/X86/X86TargetMachine.h diff -u llvm/lib/Target/X86/X86TargetMachine.h:1.30 llvm/lib/Target/X86/X86TargetMachine.h:1.31 --- llvm/lib/Target/X86/X86TargetMachine.h:1.30 Thu Sep 1 16:38:21 2005 +++ llvm/lib/Target/X86/X86TargetMachine.h Mon Nov 7 20:11:51 2005 @@ -41,17 +41,11 @@ return &InstrInfo.getRegisterInfo(); } - /// addPassesToEmitMachineCode - Add passes to the specified pass manager to - /// get machine code emitted. This uses a MachineCodeEmitter object to handle - /// actually outputting the machine code and resolving things like the address - /// of functions. This method should returns true if machine code emission is - /// not supported. - /// virtual bool addPassesToEmitMachineCode(FunctionPassManager &PM, MachineCodeEmitter &MCE); virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); static unsigned getModuleMatchQuality(const Module &M); static unsigned getJITMatchQuality(); From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/Alpha/AlphaTargetMachine.cpp AlphaTargetMachine.h Message-ID: <200511080212.UAA12689@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/Alpha: AlphaTargetMachine.cpp updated: 1.15 -> 1.16 AlphaTargetMachine.h updated: 1.10 -> 1.11 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+3 -8) AlphaTargetMachine.cpp | 3 ++- AlphaTargetMachine.h | 8 +------- 2 files changed, 3 insertions(+), 8 deletions(-) Index: llvm/lib/Target/Alpha/AlphaTargetMachine.cpp diff -u llvm/lib/Target/Alpha/AlphaTargetMachine.cpp:1.15 llvm/lib/Target/Alpha/AlphaTargetMachine.cpp:1.16 --- llvm/lib/Target/Alpha/AlphaTargetMachine.cpp:1.15 Sun Oct 30 10:44:01 2005 +++ llvm/lib/Target/Alpha/AlphaTargetMachine.cpp Mon Nov 7 20:11:51 2005 @@ -77,7 +77,8 @@ /// bool AlphaTargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; if (EnableAlphaLSR) { Index: llvm/lib/Target/Alpha/AlphaTargetMachine.h diff -u llvm/lib/Target/Alpha/AlphaTargetMachine.h:1.10 llvm/lib/Target/Alpha/AlphaTargetMachine.h:1.11 --- llvm/lib/Target/Alpha/AlphaTargetMachine.h:1.10 Thu Sep 29 17:54:56 2005 +++ llvm/lib/Target/Alpha/AlphaTargetMachine.h Mon Nov 7 20:11:51 2005 @@ -48,17 +48,11 @@ static unsigned getJITMatchQuality(); - /// addPassesToEmitMachineCode - Add passes to the specified pass manager to - /// get machine code emitted. This uses a MachineCodeEmitter object to handle - /// actually outputting the machine code and resolving things like the address - /// of functions. This method should returns true if machine code emission is - /// not supported. - /// virtual bool addPassesToEmitMachineCode(FunctionPassManager &PM, MachineCodeEmitter &MCE); virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); static unsigned getModuleMatchQuality(const Module &M); }; From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/Skeleton/SkeletonTargetMachine.cpp SkeletonTargetMachine.h Message-ID: <200511080212.UAA12677@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/Skeleton: SkeletonTargetMachine.cpp updated: 1.5 -> 1.6 SkeletonTargetMachine.h updated: 1.4 -> 1.5 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+3 -2) SkeletonTargetMachine.cpp | 3 ++- SkeletonTargetMachine.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) Index: llvm/lib/Target/Skeleton/SkeletonTargetMachine.cpp diff -u llvm/lib/Target/Skeleton/SkeletonTargetMachine.cpp:1.5 llvm/lib/Target/Skeleton/SkeletonTargetMachine.cpp:1.6 --- llvm/lib/Target/Skeleton/SkeletonTargetMachine.cpp:1.5 Thu Sep 1 16:38:21 2005 +++ llvm/lib/Target/Skeleton/SkeletonTargetMachine.cpp Mon Nov 7 20:11:51 2005 @@ -40,7 +40,8 @@ /// bool SkeletonTargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; // PM.add(createRegisterAllocator()); Index: llvm/lib/Target/Skeleton/SkeletonTargetMachine.h diff -u llvm/lib/Target/Skeleton/SkeletonTargetMachine.h:1.4 llvm/lib/Target/Skeleton/SkeletonTargetMachine.h:1.5 --- llvm/lib/Target/Skeleton/SkeletonTargetMachine.h:1.4 Thu Sep 1 16:38:21 2005 +++ llvm/lib/Target/Skeleton/SkeletonTargetMachine.h Mon Nov 7 20:11:51 2005 @@ -44,7 +44,7 @@ MachineCodeEmitter &MCE); virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); }; } // end namespace llvm From lattner at cs.uiuc.edu Mon Nov 7 20:12:06 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:06 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/IA64/IA64TargetMachine.cpp IA64TargetMachine.h Message-ID: <200511080212.UAA12691@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/IA64: IA64TargetMachine.cpp updated: 1.7 -> 1.8 IA64TargetMachine.h updated: 1.4 -> 1.5 --- Log message: Add a new option to indicate we want the code generator to emit code quickly,not spending tons of time microoptimizing it. This is useful for an -O0style of build. --- Diffs of the changes: (+3 -2) IA64TargetMachine.cpp | 3 ++- IA64TargetMachine.h | 2 +- 2 files changed, 3 insertions(+), 2 deletions(-) Index: llvm/lib/Target/IA64/IA64TargetMachine.cpp diff -u llvm/lib/Target/IA64/IA64TargetMachine.cpp:1.7 llvm/lib/Target/IA64/IA64TargetMachine.cpp:1.8 --- llvm/lib/Target/IA64/IA64TargetMachine.cpp:1.7 Sat Nov 5 22:29:30 2005 +++ llvm/lib/Target/IA64/IA64TargetMachine.cpp Mon Nov 7 20:11:51 2005 @@ -85,7 +85,8 @@ // does to emit statically compiled machine code. bool IA64TargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; // FIXME: Implement efficient support for garbage collection intrinsics. Index: llvm/lib/Target/IA64/IA64TargetMachine.h diff -u llvm/lib/Target/IA64/IA64TargetMachine.h:1.4 llvm/lib/Target/IA64/IA64TargetMachine.h:1.5 --- llvm/lib/Target/IA64/IA64TargetMachine.h:1.4 Thu Sep 1 16:38:20 2005 +++ llvm/lib/Target/IA64/IA64TargetMachine.h Mon Nov 7 20:11:51 2005 @@ -37,7 +37,7 @@ } virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); static unsigned getModuleMatchQuality(const Module &M); static unsigned compileTimeMatchQuality(void); From lattner at cs.uiuc.edu Mon Nov 7 20:12:28 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:28 -0600 Subject: [llvm-commits] CVS: llvm/tools/llc/llc.cpp Message-ID: <200511080212.UAA12756@zion.cs.uiuc.edu> Changes in directory llvm/tools/llc: llc.cpp updated: 1.116 -> 1.117 --- Log message: Add a new -fast option, which generates code quickly. --- Diffs of the changes: (+5 -1) llc.cpp | 6 +++++- 1 files changed, 5 insertions(+), 1 deletion(-) Index: llvm/tools/llc/llc.cpp diff -u llvm/tools/llc/llc.cpp:1.116 llvm/tools/llc/llc.cpp:1.117 --- llvm/tools/llc/llc.cpp:1.116 Sun Oct 23 17:37:13 2005 +++ llvm/tools/llc/llc.cpp Mon Nov 7 20:12:17 2005 @@ -45,6 +45,10 @@ static cl::opt Force("f", cl::desc("Overwrite output files")); +static cl::opt Fast("fast", + cl::desc("Generate code quickly, potentially sacrificing code quality")); + + static cl::opt MArch("march", cl::desc("Architecture to generate code for:")); @@ -228,7 +232,7 @@ } // Ask the target to add backend passes as necessary. - if (Target.addPassesToEmitFile(Passes, *Out, FileType)) { + if (Target.addPassesToEmitFile(Passes, *Out, FileType, Fast)) { std::cerr << argv[0] << ": target '" << Target.getName() << "' does not support generation of this file type!\n"; if (Out != &std::cout) delete Out; From lattner at cs.uiuc.edu Mon Nov 7 20:12:58 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 20:12:58 -0600 Subject: [llvm-commits] CVS: llvm/lib/Target/PowerPC/PPCTargetMachine.cpp PPCTargetMachine.h Message-ID: <200511080212.UAA12827@zion.cs.uiuc.edu> Changes in directory llvm/lib/Target/PowerPC: PPCTargetMachine.cpp updated: 1.76 -> 1.77 PPCTargetMachine.h updated: 1.15 -> 1.16 --- Log message: Add a new option to indicate we want the code generator to emit code quickly, not spending tons of time microoptimizing it. This is useful for an -O0 style of build. --- Diffs of the changes: (+5 -4) PPCTargetMachine.cpp | 7 ++++--- PPCTargetMachine.h | 2 +- 2 files changed, 5 insertions(+), 4 deletions(-) Index: llvm/lib/Target/PowerPC/PPCTargetMachine.cpp diff -u llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:1.76 llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:1.77 --- llvm/lib/Target/PowerPC/PPCTargetMachine.cpp:1.76 Tue Nov 1 14:07:00 2005 +++ llvm/lib/Target/PowerPC/PPCTargetMachine.cpp Mon Nov 7 20:12:47 2005 @@ -77,11 +77,12 @@ /// bool PPCTargetMachine::addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType) { + CodeGenFileType FileType, + bool Fast) { if (FileType != TargetMachine::AssemblyFile) return true; // Run loop strength reduction before anything else. - PM.add(createLoopStrengthReducePass()); + if (!Fast) PM.add(createLoopStrengthReducePass()); // FIXME: Implement efficient support for garbage collection intrinsics. PM.add(createLowerGCPass()); @@ -90,7 +91,7 @@ PM.add(createLowerInvokePass()); // Clean up after other passes, e.g. merging critical edges. - PM.add(createCFGSimplificationPass()); + if (!Fast) PM.add(createCFGSimplificationPass()); // FIXME: Implement the switch instruction in the instruction selector! PM.add(createLowerSwitchPass()); Index: llvm/lib/Target/PowerPC/PPCTargetMachine.h diff -u llvm/lib/Target/PowerPC/PPCTargetMachine.h:1.15 llvm/lib/Target/PowerPC/PPCTargetMachine.h:1.16 --- llvm/lib/Target/PowerPC/PPCTargetMachine.h:1.15 Tue Nov 1 14:07:00 2005 +++ llvm/lib/Target/PowerPC/PPCTargetMachine.h Mon Nov 7 20:12:47 2005 @@ -53,7 +53,7 @@ static unsigned getModuleMatchQuality(const Module &M); virtual bool addPassesToEmitFile(PassManager &PM, std::ostream &Out, - CodeGenFileType FileType); + CodeGenFileType FileType, bool Fast); bool addPassesToEmitMachineCode(FunctionPassManager &PM, MachineCodeEmitter &MCE); From lattner at cs.uiuc.edu Mon Nov 7 21:06:54 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 21:06:54 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/ Message-ID: <200511080306.VAA14477@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/cvsweb added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Mon Nov 7 21:07:54 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 21:07:54 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/docs/ Message-ID: <200511080307.VAA14530@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb/docs: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/cvsweb/docs added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Mon Nov 7 21:07:54 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 21:07:54 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/icons/ Message-ID: <200511080307.VAA14534@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb/icons: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/cvsweb/icons added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Mon Nov 7 21:08:29 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 21:08:29 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/icons/back.gif dir.gif miniback.gif minidir.gif minitext.gif text.gif Message-ID: <200511080308.VAA14597@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb/icons: back.gif added (r1.1) dir.gif added (r1.1) miniback.gif added (r1.1) minidir.gif added (r1.1) minitext.gif added (r1.1) text.gif added (r1.1) --- Log message: initial checkin of cvsweb support --- Diffs of the changes: (+0 -0) back.gif | 0 dir.gif | 0 miniback.gif | 0 minidir.gif | 0 minitext.gif | 0 text.gif | 0 6 files changed Index: llvm-www/cvsweb/icons/back.gif Index: llvm-www/cvsweb/icons/dir.gif Index: llvm-www/cvsweb/icons/miniback.gif Index: llvm-www/cvsweb/icons/minidir.gif Index: llvm-www/cvsweb/icons/minitext.gif Index: llvm-www/cvsweb/icons/text.gif From lattner at cs.uiuc.edu Mon Nov 7 21:08:27 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Mon, 7 Nov 2005 21:08:27 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/cvsweb.cgi cvsweb.conf index.html Message-ID: <200511080308.VAA14578@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb: cvsweb.cgi added (r1.1) cvsweb.conf added (r1.1) index.html added (r1.1) --- Log message: initial checkin of cvsweb support --- Diffs of the changes: (+4286 -0) cvsweb.cgi | 3764 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ cvsweb.conf | 516 ++++++++ index.html | 6 3 files changed, 4286 insertions(+) Index: llvm-www/cvsweb/cvsweb.cgi diff -c /dev/null llvm-www/cvsweb/cvsweb.cgi:1.1 *** /dev/null Mon Nov 7 21:08:25 2005 --- llvm-www/cvsweb/cvsweb.cgi Mon Nov 7 21:08:15 2005 *************** *** 0 **** --- 1,3764 ---- + #!/usr/dcs/software/supported/bin/perl -wT + # + # cvsweb - a CGI interface to CVS trees. + # + # Written in their spare time by + # Bill Fenner (original work) + # extended by Henner Zeller , + # Henrik Nordstrom + # Ken Coar + # Dick Balaska + # Akinori MUSHA + # Jens-Uwe Mager + # Ville Skytt? + # Vassilii Khachaturov + # + # Based on: + # * Bill Fenners cvsweb.cgi revision 1.28 available from: + # http://www.FreeBSD.org/cgi/cvsweb.cgi/www/en/cgi/cvsweb.cgi + # + # Copyright (c) 1996-1998 Bill Fenner + # (c) 1998-1999 Henner Zeller + # (c) 1999 Henrik Nordstrom + # (c) 2000-2002 Akinori MUSHA + # (c) 2002 Ville Skytt? + # All rights reserved. + # + # Redistribution and use in source and binary forms, with or without + # modification, are permitted provided that the following conditions + # are met: + # 1. Redistributions of source code must retain the above copyright + # notice, this list of conditions and the following disclaimer. + # 2. Redistributions in binary form must reproduce the above copyright + # notice, this list of conditions and the following disclaimer in the + # documentation and/or other materials provided with the distribution. + # + # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + # SUCH DAMAGE. + # + # $FreeBSD: projects/cvsweb/cvsweb.cgi,v 1.119.2.6 2002/09/26 20:56:05 scop Exp $ + # $Id: cvsweb.cgi,v 1.1 2005/11/08 03:08:15 lattner Exp $ + # $Idaemons: /home/cvs/cvsweb/cvsweb.cgi,v 1.84 2001/10/07 20:50:10 knu Exp $ + # + ### + + require 5.000; + + use strict; + + use vars qw ( + $cvsweb_revision + $mydir $uname $config $allow_version_select $verbose + @CVSrepositories @CVSROOT %CVSROOT %CVSROOTdescr + %MIRRORS %DEFAULTVALUE %ICONS %MTYPES + @DIFFTYPES %DIFFTYPES @LOGSORTKEYS %LOGSORTKEYS + %alltags @tabcolors %fileinfo %tags @branchnames %nameprinted + %symrev %revsym @allrevisions %date %author @revdisplayorder + @revisions %state %difflines %log %branchpoint @revorder + $prcgi @prcategories $re_prcategories $prkeyword $re_prkeyword $mancgi + $checkoutMagic $doCheckout $scriptname $scriptwhere + $where $pathinfo $Browser $nofilelinks $maycompress + @stickyvars @unsafevars + %funcline_regexp $is_mod_perl + $is_links $is_lynx $is_w3m $is_msie $is_mozilla3 $is_textbased + %input $query $barequery $sortby $bydate $byrev $byauthor + $bylog $byfile $defaultDiffType $logsort $cvstree $cvsroot + $mimetype $charset $output_filter $defaultTextPlain $defaultViewable + $command_path %CMD $allow_compress + $backicon $diricon $fileicon + $fullname $newname $cvstreedefault + $body_tag $body_tag_for_src $logo $defaulttitle $address + $long_intro $short_instruction $shortLogLen + $show_author $dirtable $tablepadding $columnHeaderColorDefault + $columnHeaderColorSorted $hr_breakable $showfunc $hr_ignwhite + $hr_ignkeysubst $diffcolorHeading $diffcolorEmpty $diffcolorRemove + $diffcolorChange $diffcolorAdd $diffcolorDarkChange $difffontface + $difffontsize $inputTextSize $mime_types + $allow_annotate $allow_markup + $allow_log_extra $allow_dir_extra $allow_source_extra + $use_java_script $open_extern_window + $extern_window_width $extern_window_height $edit_option_form + $show_subdir_lastmod $show_log_in_markup $preformat_in_markup $v + $navigationHeaderColor $tableBorderColor $markupLogColor + $tabstop $state $annTable $sel $curbranch @HideModules @ForbiddenFiles + $module $use_descriptions %descriptions @mytz $dwhere $moddate + $use_moddate $has_zlib $gzip_open + $allow_tar @tar_options @gzip_options @zip_options @cvs_options + @annotate_options $LOG_FILESEPARATOR $LOG_REVSEPARATOR + $tmpdir $HTML_DOCTYPE $HTML_META + ); + + sub printDiffSelect($); + sub printDiffLinks($$); + sub printLogSortSelect($); + sub findLastModifiedSubdirs(@); + sub htmlify_sub(&$); + sub htmlify($;$); + sub spacedHtmlText($;$); + sub link($$); + sub revcmp($$); + sub fatal($$@); + sub redirect($); + sub safeglob($); + sub search_path($); + sub getMimeTypeFromSuffix($); + sub head($;$); + sub scan_directives(@); + sub openOutputFilter(); + sub doAnnotate($$); + sub doCheckout($$); + sub cvswebMarkup($$$); + sub viewable($); + sub doDiff($$$$$$); + sub getDirLogs($$@); + sub readLog($;$); + sub printLog($;$); + sub doLog($); + sub flush_diff_rows($$$$); + sub human_readable_diff($); + sub navigateHeader($$$$$); + sub plural_write($$); + sub readableTime($$); + sub clickablePath($$); + sub chooseCVSRoot(); + sub chooseMirror(); + sub fileSortCmp(); + sub download_url($$;$); + sub download_link($$$;$); + sub toggleQuery($$); + sub urlencode($); + sub htmlquote($); + sub htmlunquote($); + sub hrefquote($); + sub http_header(;$); + sub html_header($); + sub html_footer(); + sub link_tags($); + sub forbidden_file($); + sub forbidden_module($); + + ##### Start of Configuration Area ######## + delete $ENV{PATH}; + + $cvsweb_revision = '2.0.6'; + + use File::Basename (); + + ($mydir) = (File::Basename::dirname($0) =~ /(.*)/); # untaint + + # == EDIT this == + # Locations to search for user configuration, in order: + for ("$mydir/cvsweb.conf", '/home/vadve/shared/llvm-wwwroot/cvsweb/cvsweb.conf', '/usr/local/etc/cvsweb/cvsweb.conf') { + if (defined($_) && -r $_) { + $config = $_; + last; + } + } + + # == Configuration defaults == + # Defaults for configuration variables that shouldn't need + # to be configured.. + $allow_version_select = 1; + $allow_log_extra = 1; + + ##### End of Configuration Area ######## + + ######## Configuration variables ######### + # These are defined to allow checking with perl -cw + @CVSrepositories = @CVSROOT = %CVSROOT = %MIRRORS = %DEFAULTVALUE = %ICONS = + %MTYPES = %tags = %alltags = @tabcolors = %fileinfo = (); + $cvstreedefault = $body_tag = $body_tag_for_src = $logo = $defaulttitle = + $address = $long_intro = $short_instruction = $shortLogLen = $show_author = + $dirtable = $tablepadding = $columnHeaderColorDefault = + $columnHeaderColorSorted = $hr_breakable = $showfunc = $hr_ignwhite = + $hr_ignkeysubst = $diffcolorHeading = $diffcolorEmpty = $diffcolorRemove = + $diffcolorChange = $diffcolorAdd = $diffcolorDarkChange = $difffontface = + $difffontsize = $inputTextSize = $mime_types = $allow_annotate = + $allow_markup = $use_java_script = $open_extern_window = + $extern_window_width = $extern_window_height = $edit_option_form = + $show_subdir_lastmod = $show_log_in_markup = $v = $navigationHeaderColor = + $tableBorderColor = $markupLogColor = $tabstop = $use_moddate = $moddate = + $gzip_open = $HTML_DOCTYPE = $HTML_META = undef; + $tmpdir = defined($ENV{TMPDIR}) ? $ENV{TMPDIR} : "/var/tmp"; + + $LOG_FILESEPARATOR = q/^={77}$/; + $LOG_REVSEPARATOR = q/^-{28}$/; + + @DIFFTYPES = qw(h H u c s); + @DIFFTYPES{@DIFFTYPES} = ( + { + 'descr' => 'colored', + 'opts' => ['-u'], + 'colored' => 1, + }, + { + 'descr' => 'long colored', + 'opts' => ['--unified=15'], + 'colored' => 1, + }, + { + 'descr' => 'unified', + 'opts' => ['-u'], + 'colored' => 0, + }, + { + 'descr' => 'context', + 'opts' => ['-c'], + 'colored' => 0, + }, + { + 'descr' => 'side by side', + 'opts' => ['--side-by-side', '--width=164'], + 'colored' => 0, + }, + ); + + @LOGSORTKEYS = qw(cvs date rev); + @LOGSORTKEYS{@LOGSORTKEYS} = ( + { + 'descr' => 'Not sorted', + }, + { + 'descr' => 'Commit date', + }, + { + 'descr' => 'Revision', + }, + ); + + $HTML_DOCTYPE = + ''; + + $HTML_META = < + + + + EOM + + ##### End of configuration variables ##### + + use Time::Local (); + use IPC::Open2 qw(open2); + + # Check if the zlib C library interface is installed, and if yes + # we can avoid using the extra gzip process. + eval { require Compress::Zlib; }; + $has_zlib = !$@; + + $verbose = $v; + $checkoutMagic = "~checkout~"; + $pathinfo = defined($ENV{PATH_INFO}) ? $ENV{PATH_INFO} : ''; + $where = $pathinfo; + $doCheckout = ($where =~ m|^/$checkoutMagic/|); + $where =~ s|^/$checkoutMagic/|/|; + $where =~ s|^/||; + $scriptname = defined($ENV{SCRIPT_NAME}) ? $ENV{SCRIPT_NAME} : ''; + $scriptname =~ s|^/*|/|; + + # Let's workaround thttpd's stupidity.. + if ($scriptname =~ m|/$|) { + $pathinfo .= '/'; + my $re = quotemeta $pathinfo; + $scriptname =~ s/$re$//; + } + + $scriptwhere = $scriptname; + $scriptwhere .= '/' . urlencode($where); + $where = '/' if ($where eq ''); + + $is_mod_perl = defined($ENV{MOD_PERL}); + + # in lynx, it it very annoying to have two links + # per file, so disable the link at the icon + # in this case: + $Browser = $ENV{HTTP_USER_AGENT} || ''; + $is_links = ($Browser =~ m`^Links `); + $is_lynx = ($Browser =~ m`^Lynx/`i); + $is_w3m = ($Browser =~ m`^w3m/`i); + $is_msie = ($Browser =~ m`MSIE`); + $is_mozilla3 = ($Browser =~ m`^Mozilla/[3-9]`); + + $is_textbased = ($is_links || $is_lynx || $is_w3m); + + $nofilelinks = $is_textbased; + + # newer browsers accept gzip content encoding + # and state this in a header + # (netscape did always but didn't state it) + # It has been reported that these + # braindamaged MS-Internet Exploders claim that they + # accept gzip .. but don't in fact and + # display garbage then :-/ + # Turn off gzip if running under mod_perl and no zlib is available, + # piping does not work as expected inside the server. + $maycompress = + (((defined($ENV{HTTP_ACCEPT_ENCODING}) + && $ENV{HTTP_ACCEPT_ENCODING} =~ m`gzip`) || $is_mozilla3) && !$is_msie + && !($is_mod_perl && !$has_zlib)); + + # put here the variables we need in order + # to hold our state - they will be added (with + # their current value) to any link/query string + # you construct + @stickyvars = qw(cvsroot hideattic sortby logsort f only_with_tag); + @unsafevars = qw(logsort only_with_tag r1 r2 rev sortby tr1 tr2); + + if (-f $config) { + do "$config" or fatal("500 Internal Error", + 'Error in loading configuration file: %s

%s
', + $config, $@); + } else { + fatal("500 Internal Error", + 'Configuration not found. Set the variable $config in cvsweb.cgi to your cvsweb.conf configuration file first.' + ); + } + + undef %input; + $query = $ENV{QUERY_STRING}; + + if (defined($query) && $query ne '') { + foreach (split (/&/, $query)) { + y/+/ /; + s/%(..)/sprintf("%c", hex($1))/ge; # unquote %-quoted + if (/(\S+)=(.*)/) { + $input{$1} = $2 if ($2 ne ""); + } else { + $input{$_}++; + } + } + } + + # For backwards compability, set only_with_tag to only_on_branch if set. + $input{only_with_tag} = $input{only_on_branch} + if (defined($input{only_on_branch})); + + # Prevent cross-site scripting + foreach (@unsafevars) { + # Colons are needed in diffs between tags. + if (defined($input{$_}) && $input{$_} =~ /[^\w\-.:]/) { + fatal("500 Internal Error", + 'Malformed query (%s=%s)', + $_, $input{$_}); + } + } + + if (defined($input{"content-type"})) { + fatal("500 Internal Error", "Unsupported content-type") + if ($input{"content-type"} !~ /^[-0-9A-Za-z]+\/[-0-9A-Za-z]+$/); + } + + $DEFAULTVALUE{'cvsroot'} = $cvstreedefault; + + foreach (keys %DEFAULTVALUE) { + + # replace not given parameters with the default parameters + if (!defined($input{$_}) || $input{$_} eq "") { + + # Empty Checkboxes in forms return -- nothing. So we define a helper + # variable in these forms (copt) which indicates that we just set + # parameters with a checkbox + if (!defined($input{"copt"})) { + + # 'copt' isn't defined --> empty input is not the result + # of empty input checkbox --> set default + $input{$_} = $DEFAULTVALUE{$_} + if (defined($DEFAULTVALUE{$_})); + } else { + + # 'copt' is defined -> the result of empty input checkbox + # -> set to zero (disable) if default is a boolean (0|1). + $input{$_} = 0 + if (defined($DEFAULTVALUE{$_}) + && ($DEFAULTVALUE{$_} eq "0" + || $DEFAULTVALUE{$_} eq "1")); + } + } + } + + $barequery = ""; + my @barequery; + foreach (@stickyvars) { + + # construct a query string with the sticky non default parameters set + if (defined($input{$_}) && $input{$_} ne '' + && !(defined($DEFAULTVALUE{$_}) && $input{$_} eq $DEFAULTVALUE{$_})) + { + push @barequery, + join ('=', urlencode($_), urlencode($input{$_})); + } + } + + # is there any query ? + if (@barequery) { + $barequery = join ('&', @barequery); + $query = "?$barequery"; + $barequery = "&$barequery"; + } else { + $query = ""; + } + undef @barequery; + + if (defined($input{path})) { + redirect("$scriptname/$input{path}$query"); + } + + # get actual parameters + $sortby = $input{"sortby"}; + $bydate = 0; + $byrev = 0; + $byauthor = 0; + $bylog = 0; + $byfile = 0; + if ($sortby eq "date") { + $bydate = 1; + } elsif ($sortby eq "rev") { + $byrev = 1; + } elsif ($sortby eq "author") { + $byauthor = 1; + } elsif ($sortby eq "log") { + $bylog = 1; + } else { + $byfile = 1; + } + + $defaultDiffType = $input{'f'}; + + $logsort = $input{'logsort'}; + + { + my @tmp = @CVSrepositories; + my @pair; + + while (@pair = splice(@tmp, 0, 2)) { + my ($key, $val) = @pair; + my ($descr, $cvsroot) = @$val; + + next if !-d $cvsroot; + + $CVSROOTdescr{$key} = $descr; + $CVSROOT{$key} = $cvsroot; + push @CVSROOT, $key; + } + } + + ## Default CVS-Tree + if (!defined($CVSROOT{$cvstreedefault})) { + fatal("500 Internal Error", + '$cvstreedefault points to a repository (%s) not defined in %%CVSROOT (edit your configuration file %s)', + $cvstreedefault, $config); + } + + # alternate CVS-Tree, configured in cvsweb.conf + if ($input{'cvsroot'} && $CVSROOT{$input{'cvsroot'}}) { + $cvstree = $input{'cvsroot'}; + } else { + $cvstree = $cvstreedefault; + } + + $cvsroot = $CVSROOT{$cvstree}; + + # create icons out of description + foreach my $k (keys %ICONS) { + no strict 'refs'; + my ($itxt, $ipath, $iwidth, $iheight) = @{$ICONS{$k}}; + if ($ipath) { + ${"${k}icon"} = + sprintf( + '%s', + hrefquote($ipath), htmlquote($itxt), $iwidth, $iheight) + } else { + ${"${k}icon"} = $itxt; + } + } + + my $config_cvstree = "$config-$cvstree"; + + # Do some special configuration for cvstrees + if (-f $config_cvstree) { + do "$config_cvstree" or + fatal("500 Internal Error", + 'Error in loading configuration file: %s

%s
', + $config_cvstree, $@); + } + undef $config_cvstree; + + $re_prcategories = '(?:' . join ('|', @prcategories) . ')' if @prcategories; + $re_prkeyword = quotemeta($prkeyword) if defined($prkeyword); + $prcgi .= '%s' if defined($prcgi) && $prcgi !~ /%s/; + + $fullname = "$cvsroot/$where"; + $mimetype = &getMimeTypeFromSuffix($fullname); + $defaultTextPlain = ($mimetype eq "text/plain"); + $defaultViewable = $allow_markup && viewable($mimetype); + + my $rewrite = 0; + + if ($pathinfo =~ m|//|) { + $pathinfo =~ y|/|/|s; + $rewrite = 1; + } + + if (-d $fullname && $pathinfo !~ m|/$|) { + $pathinfo .= '/'; + $rewrite = 1; + } + + if (!-d $fullname && $pathinfo =~ m|/$|) { + chop $pathinfo; + $rewrite = 1; + } + + if ($rewrite) { + redirect($scriptname . urlencode($pathinfo) . $query); + } + + undef $rewrite; + + if (!-d $cvsroot) { + fatal("500 Internal Error", + '$CVSROOT not found!

The server on which the CVS tree lives is probably down. Please try again in a few minutes.'); + } + + # + # See if the module is in our forbidden list. + # + $where =~ m:([^/]*):; + $module = $1; + if ($module && &forbidden_module($module)) { + fatal("403 Forbidden", + 'Access to %s forbidden.', + $where); + } + + # + # Handle tarball downloads before any headers are output. + # + if ($input{tarball}) { + fatal("403 Forbidden", + 'Downloading tarballs is prohibited.') + unless $allow_tar; + my ($module) = ($where =~ m,^/?(.*),); # untaint + $module =~ s,/([^/]*)$,,; + my ($ext) = ($1 =~ /(\.tar\.gz|\.zip)$/); + my ($basedir) = ($module =~ m,([^/]+)$,); + + if ($basedir eq '' || $module eq '') { + fatal("500 Internal Error", + 'You cannot download the top level directory.'); + } + + my $tmpexportdir = "$tmpdir/.cvsweb.$$." . int(time); + + mkdir($tmpexportdir, 0700) + or fatal("500 Internal Error", + 'Unable to make temporary directory: %s', + $!); + + my @fatal; + + my $tag = + (exists $input{only_with_tag} && length $input{only_with_tag}) ? + $input{only_with_tag} : "HEAD"; + + if ($tag eq 'MAIN') { + $tag = 'HEAD'; + } + + if (system $CMD{cvs}, @cvs_options, '-Qd', $cvsroot, 'export', '-r', + $tag, '-d', "$tmpexportdir/$basedir", $module) + { + @fatal = ("500 Internal Error", + 'cvs co failure: %s: %s', + $!, $module); + } else { + $| = 1; # Essential to get the buffering right. + + if ($ext eq '.tar.gz') { + print "Content-Type: application/x-gzip\r\n\r\n"; + + system + "$CMD{tar} @tar_options -cf - -C $tmpexportdir $basedir | $CMD{gzip} @gzip_options -c" + and @fatal = + ("500 Internal Error", + 'tar zc failure: %s: %s', + $!, $basedir); + } elsif ($ext eq '.zip' && $CMD{zip}) { + print "Content-Type: application/zip\r\n\r\n"; + + system + "cd $tmpexportdir && $CMD{zip} @zip_options -r - $basedir" + and @fatal = + ("500 Internal Error", + 'zip failure: %s: %s', + $!, $basedir); + } else { + @fatal = + ("500 Internal Error", + 'unsupported file type'); + } + } + + system $CMD{rm}, '-rf', $tmpexportdir if -d $tmpexportdir; + + &fatal(@fatal) if @fatal; + + exit; + } + + ############################## + # View a directory + ############################### + if (-d $fullname) { + my $dh = do { local (*DH); }; + opendir($dh, $fullname) or fatal("404 Not Found", + '%s: %s', + $where, $!); + my @dir = readdir($dh); + closedir($dh); + my @subLevelFiles = findLastModifiedSubdirs(@dir) + if ($show_subdir_lastmod); + getDirLogs($cvsroot, $where, @subLevelFiles); + + if ($where eq '/') { + html_header($defaulttitle); + $long_intro =~ s/!!CVSROOTdescr!!/$CVSROOTdescr{$cvstree}/g; + print $long_intro; + } else { + html_header($where); + print $short_instruction; + } + + if ($use_descriptions && open(DESC, "<$cvsroot/CVSROOT/descriptions")) + { + while () { + chomp; + my ($dir, $description) = /(\S+)\s+(.*)/; + $descriptions{$dir} = $description; + } + close(DESC); + } + + print "

\n"; + + # give direct access to dirs + if ($where eq '/') { + chooseMirror (); + chooseCVSRoot (); + } else { + print "

Current directory: ", &clickablePath($where, 0), + "

\n"; + + print "

Current tag: ", $input{only_with_tag},"

\n" + if $input{only_with_tag}; + + } + + print "
\n"; + + # Using in this manner violates the HTML2.0 spec but + # provides the results that I want in most browsers. Another + # case of layout spooging up HTML. + + my $infocols = 0; + if ($dirtable) { + print "\n"; + $infocols++; + printf "\n\n"; + + # do not display the other column-headers, if we do not have any files + # with revision information: + if (scalar(%fileinfo)) { + $infocols++; + printf '\n"; + $infocols++; + printf '\n"; + + if ($show_author) { + $infocols++; + printf '\n"; + } + $infocols++; + printf '\n"; + } elsif ($use_descriptions) { + printf '\n"; + $infocols++; + } + print "\n"; + } else { + print "\n"; + } + my $dirrow = 0; + + my $i; + lookingforattic: + for ($i = 0 ; $i <= $#dir ; $i++) { + if ($dir[$i] eq "Attic") { + last lookingforattic; + } + } + + if (!$input{'hideattic'} && ($i <= $#dir) + && opendir($dh, $fullname . "/Attic")) + { + splice(@dir, $i, 1, grep((s|^|Attic/|, !m|/\.|), readdir($dh))); + closedir($dh); + } + + my $hideAtticToggleLink = + $input{'hideattic'} ? '' : + &link('[Hide]', sprintf('./%s#dirlist', &toggleQuery("hideattic"))); + + # Sort without the Attic/ pathname. + # place directories first + + my $attic; + my $url; + my $fileurl; + my $filesexists; + my $filesfound; + + foreach my $file (sort { &fileSortCmp } @dir) { + + next if ($file eq '.'); + + # ignore CVS lock and stale NFS files + next if ($file =~ /^#cvs\.|^,|^\.nfs/); + + # Check whether to show the CVSROOT path + next if ($input{'hidecvsroot'} && $file eq 'CVSROOT'); + + # Check whether the module is in the restricted list + next if ($file && &forbidden_module($file)); + + # Ignore non-readable files + next if ($input{'hidenonreadable'} && !(-r "$fullname/$file")); + + if ($file =~ s|^Attic/||) { + $attic = " (in the Attic) " . $hideAtticToggleLink; + } else { + $attic = ""; + } + + if ($file eq '..' || -d "$fullname/$file") { + next if ($file eq '..' && $where eq '/'); + my ($rev, $date, $log, $author, $filename) = + @{$fileinfo{$file}} + if (defined($fileinfo{$file})); + printf "\n\n\n\n\n\n\n\n"; + } else { + print "
\n"; + } + $dirrow++; + } elsif ($file =~ s/,v$//) { + + # Skip forbidden files now so we'll give no hint + # about their existence. This should probably have + # been done earlier, but it's straightforward here. + next if forbidden_file("$fullname/$file"); + + $fileurl = ($attic ? "Attic/" : "") . urlencode($file); + $url = './' . $fileurl . $query; + $filesexists++; + next if (!defined($fileinfo{$file})); + my ($rev, $date, $log, $author) = @{$fileinfo{$file}}; + $filesfound++; + printf "\n\n\n\n\n\n" if ($dirtable); + print(($dirtable) ? "" : "
"); + $dirrow++; + } + print "\n"; + } + + print($dirtable ? "
", + $byfile ? $columnHeaderColorSorted : + $columnHeaderColorDefault; + + if ($byfile) { + print 'File'; + } else { + print &link( + 'File', + sprintf( + './%s#dirlist', + &toggleQuery("sortby", "file") + ) + ); + } + print "', + $byrev ? $columnHeaderColorSorted : + $columnHeaderColorDefault; + + if ($byrev) { + print 'Rev.'; + } else { + print &link( + 'Rev.', + sprintf( + './%s#dirlist', + &toggleQuery("sortby", "rev") + ) + ); + } + print "', + $bydate ? $columnHeaderColorSorted : + $columnHeaderColorDefault; + + if ($bydate) { + print 'Age'; + } else { + print &link( + 'Age', + sprintf( + './%s#dirlist', + &toggleQuery("sortby", "date") + ) + ); + } + print "', + $byauthor ? $columnHeaderColorSorted : + $columnHeaderColorDefault; + + if ($byauthor) { + print 'Author'; + } else { + print &link( + 'Author', + sprintf( + './%s#dirlist', + &toggleQuery( + "sortby", + "author" + ) + ) + ); + } + print "', + $bylog ? $columnHeaderColorSorted : + $columnHeaderColorDefault; + + if ($bylog) { + print 'Last log entry'; + } else { + print &link( + 'Last log entry', + sprintf( + './%s#dirlist', + &toggleQuery("sortby", "log") + ) + ); + } + print "', + $columnHeaderColorDefault; + print "Description
", + $tabcolors[$dirrow % 2] if $dirtable; + + if ($file eq '..') { + $url = "../$query"; + if ($nofilelinks) { + print $backicon; + } else { + print &link($backicon, $url); + } + print ' ', &link("Parent Directory", $url); + } else { + $url = './' . urlencode($file) . "/$query"; + print ""; + + if ($nofilelinks) { + print $diricon; + } else { + print &link($diricon, $url); + } + print ' ', &link("$file/", $url), $attic; + + if ($file eq "Attic") { + print "  "; + print &link( + "[Don't hide]", + sprintf( + './%s#dirlist', + &toggleQuery( + "hideattic") + ) + ); + } + } + + # Show last change in dir + if ($filename) { + print "  " + if ($dirtable); + if ($date) { + print " ", + readableTime(time() - $date, 0), + ""; + } + + if ($show_author) { + print " " if ($dirtable); + print $author; + } + print " " if ($dirtable); + $filename =~ s%^[^/]+/%%; + print "$filename/$rev"; + print "
" if ($dirtable); + + if ($log) { + print " ", + &htmlify( + substr($log, 0, $shortLogLen), $allow_dir_extra); + if (length $log > 80) { + print "..."; + } + print ""; + } + } else { + my ($dwhere) = + ($where ne "/" ? $where : "") . $file; + + if ($use_descriptions + && defined $descriptions{$dwhere}) + { + print "
 " + if $dirtable; + print $descriptions{$dwhere}; + } elsif ($dirtable && $infocols > 1) { + + # close the row with the appropriate number of + # columns, so that the vertical seperators are visible + my ($cols) = $infocols; + while ($cols > 1) { + print " "; + $cols--; + } + } + } + + if ($dirtable) { + print "
", + $tabcolors[$dirrow % 2] if $dirtable; + print ""; + + if ($nofilelinks) { + print $fileicon; + } else { + print &link($fileicon, $url); + } + print ' ', &link(htmlquote($file), $url), $attic; + print " " if ($dirtable); + download_link($fileurl, $rev, $rev, + $defaultViewable ? "text/x-cvsweb-markup" : + undef); + print " " if ($dirtable); + + if ($date) { + print " ", readableTime(time() - $date, 0), + ""; + } + if ($show_author) { + print " " if ($dirtable); + print $author; + } + print " " if ($dirtable); + + if ($log) { + print " ", + &htmlify(substr($log, 0, $shortLogLen), $allow_dir_extra); + if (length $log > 80) { + print "..."; + } + print ""; + } + print "
\n" : "
\n"); + + if ($filesexists && !$filesfound) { + print + "

NOTE: There are $filesexists files, but none matches the current tag ($input{only_with_tag}).

\n"; + } + if ($input{only_with_tag} && (!%tags || !$tags{$input{only_with_tag}})) + { + %tags = %alltags + } + + if (scalar %tags || $input{only_with_tag} || $edit_option_form + || defined($input{"options"})) + { + print "
\n"; + } + + if (scalar %tags || $input{only_with_tag}) { + print "
\n"; + foreach my $var (@stickyvars) { + print + "\n" + if (defined($input{$var}) + && (!defined($DEFAULTVALUE{$var}) + || $input{$var} ne $DEFAULTVALUE{$var}) + && $input{$var} ne "" && $var ne "only_with_tag"); + } + print "

\n"; + print "\n"; + print " \n"; + printf "\n", + htmlquote($where); + print "

\n"; + print "
\n"; + } + + if ($allow_tar) { + my ($basefile) = ($where =~ m,(?:.*/)?([^/]+),); + + if (defined($basefile) && $basefile ne '') { + print "
\n", + "
Download this directory in "; + + # Mangle the filename so browsers show a reasonable + # filename to download. + print &link("tarball", "./$basefile.tar.gz$query" + . ($query ? "&" : "?") . "tarball=1"); + if ($CMD{zip}) { + print " or ", + &link("zip archive", "./$basefile.zip$query" + . ($query ? "&" : "?") . "tarball=1"); + } + print "
\n"; + } + } + + if ($edit_option_form || defined($input{"options"})) { + + my $formwhere = $scriptwhere; + $formwhere =~ s|Attic/?$|| if ($input{'hideattic'}); + + print "
\n"; + print "\n"; + if ($cvstree ne $cvstreedefault) { + print + "\n"; + } + print "
\n"; + print "\n\n"; + print "\n\n"; + print "\n\n"; + print "\n\n"; + print "\n\n"; + print "\n\n"; + print "\n\n\n
Preferences
"; + print "\n"; + printLogSortSelect(0); + print "
"; + printDiffSelect(0); + print ""; + print "
"; + print ""; + print "
\n
\n
\n"; + } + html_footer(); + } + + ############################### + # View Files + ############################### + elsif (-f $fullname . ',v') { + + if (forbidden_file($fullname)) { + fatal('403 Forbidden', + 'Access forbidden. This file is mentioned in @ForbiddenFiles'); + return; + } + + if (defined($input{'rev'}) || $doCheckout) { + &doCheckout($fullname, $input{'rev'}); + gzipclose(); + exit; + } + + if (defined($input{'annotate'}) && $allow_annotate) { + &doAnnotate($input{'annotate'}); + gzipclose(); + exit; + } + + if (defined($input{'r1'}) && defined($input{'r2'})) { + &doDiff( + $fullname, $input{'r1'}, + $input{'tr1'}, $input{'r2'}, + $input{'tr2'}, $input{'f'} + ); + gzipclose(); + exit; + } + print("going to dolog($fullname)\n") if ($verbose); + &doLog($fullname); + + ############################## + # View Diff + ############################## + } elsif ($fullname =~ s/\.diff$// && -f $fullname . ",v" && $input{'r1'} + && $input{'r2'}) + { + + # $where-diff-removal if 'cvs rdiff' is used + # .. but 'cvs rdiff'doesn't support some options + # rcsdiff does (-w and -p), so it is disabled + # $where =~ s/\.diff$//; + + # Allow diffs using the ".diff" extension + # so that browsers that default to the URL + # for a save filename don't save diff's as + # e.g. foo.c + &doDiff( + $fullname, $input{'r1'}, $input{'tr1'}, $input{'r2'}, + $input{'tr2'}, $input{'f'} + ); + gzipclose(); + exit; + } elsif (($newname = $fullname) =~ s|/([^/]+)$|/Attic/$1| && -f $newname . ",v") + { + + # The file has been removed and is in the Attic. + # Send a redirect pointing to the file in the Attic. + (my $newplace = $scriptwhere) =~ s|/([^/]+)$|/Attic/$1|; + if ($ENV{QUERY_STRING} ne "") { + redirect("${newplace}?$ENV{QUERY_STRING}"); + } else { + redirect($newplace); + } + exit; + } elsif (0 && (my @files = &safeglob($fullname . ",v"))) { + http_header("text/plain"); + print "You matched the following files:\n"; + print join ("\n", @files); + + # Find the tags from each file + # Display a form offering diffs between said tags + } else { + my $fh = do { local (*FH); }; + my ($xtra, $module); + + # Assume it's a module name with a potential path following it. + $xtra = (($module = $where) =~ s|/.*||) ? $& : ''; + + # Is there an indexed version of modules? + if (open($fh, "< $cvsroot/CVSROOT/modules")) { + while (<$fh>) { + if (/^(\S+)\s+(\S+)/o && $module eq $1 + && -d "$cvsroot/$2" && $module ne $2) + { + redirect("$scriptname/$2$xtra$query"); + } + } + } + fatal("404 Not Found", + '%s: no such file or directory', + $where); + } + + gzipclose(); + + ## End MAIN + + sub printDiffSelect($) { + my ($use_java_script) = @_; + my $f = $input{'f'}; + + print '"; + } + + sub printLogSortSelect($) { + my ($use_java_script) = @_; + + print '"; + } + + sub findLastModifiedSubdirs(@) { + my (@dirs) = @_; + my ($dirname, @files); + + foreach $dirname (@dirs) { + next if ($dirname eq "."); + next if ($dirname eq ".."); + my ($dir) = "$fullname/$dirname"; + next if (!-d $dir); + + my ($lastmod) = undef; + my ($lastmodtime) = undef; + my $dh = do { local (*DH); }; + + opendir($dh, $dir) or next; + my (@filenames) = readdir($dh); + closedir($dh); + + foreach my $filename (@filenames) { + $filename = "$dirname/$filename"; + my ($file) = "$fullname/$filename"; + next if ($filename !~ /,v$/ || !-f $file); + + # Skip forbidden files. + (my $f = $file) =~ s/,v$//; + next if forbidden_file($f); + + $filename =~ s/,v$//; + my $modtime = -M $file; + + if (!defined($lastmod) || $modtime < $lastmodtime) { + $lastmod = $filename; + $lastmodtime = $modtime; + } + } + push (@files, $lastmod) if (defined($lastmod)); + } + return @files; + } + + sub htmlify_sub(&$) { + (my $proc, local $_) = @_; + my @a = split (m`(]+>[^<]*)`i); + my $linked; + my $result = ''; + + while (($_, $linked) = splice(@a, 0, 2)) { + &$proc(); + $result .= $_ if defined($_); + $result .= $linked if defined($linked); + } + + $result; + } + + sub htmlify($;$) { + (local $_, my $extra) = @_; + + $_ = htmlquote($_); + + # get URL's as link + s{ + (http|ftp|https)://\S+ + }{ + &link($&, htmlunquote($&)) + }egx; + + # get e-mails as link + $_ = htmlify_sub { + s< + [\w+=\-.!]+@[\w\-]+(\.[\w\-]+)+ + >< + &link($&, "mailto:$&") + >egix; + } + $_; + + if ($extra) { + + # get PR #'s as link: "PR#nnnn" "PR: nnnn, ..." "PR nnnn, ..." "bin/nnnn" + if (defined($prcgi) && defined($re_prkeyword)) + { + my $prev; + + do { + $prev = $_; + + $_ = htmlify_sub { + s{ + (\b$re_prkeyword[:\#]?\s* + (?: + \#? + \d+[,\s]\s* + )* + \#?) + (\d+)\b + }{ + $1 . &link($2, sprintf($prcgi, $2)) + }egix; + } + $_; + } while ($_ ne $prev); + + if (defined($re_prcategories)) { + $_ = htmlify_sub { + s{ + (\b$re_prcategories/(\d+)\b) + }{ + &link($1, sprintf($prcgi, $2)) + }egox; + } + $_; + } + } + + # get manpage specs as link: "foo.1" "foo(1)" + if (defined($mancgi)) { + $_ = htmlify_sub { + s{ + (\b([a-zA-Z][\w.]+) + (?: + \( ([0-9n]) \)\B + | + \.([0-9n])\b + ) + ) + }{ + &link($1, sprintf($mancgi, defined($3) ? $3 : $4, $2)) + }egx; + } + $_; + } + } + + $_; + } + + sub spacedHtmlText($;$) { + local $_ = $_[0]; + my $ts = $_[1] || $tabstop; + + # Cut trailing spaces and tabs + s/[ \t]+$//; + + if (defined($ts)) { + + # Expand tabs + 1 while s/\t+/' ' x (length($&) * $ts - length($`) % $ts)/e + } + + # replace and (\001 is to protect us from htmlify) + # gzip can make excellent use of this repeating pattern :-) + if ($hr_breakable) { + + # make every other space 'breakable' + s/ / \001nbsp;/g; # 2 * + # leave single space as it is + } else { + s/ /\001nbsp;/g; + } + + $_ = htmlify($_, $allow_source_extra); + + # unescape + y/\001/&/; + + return $_; + } + + # Note that this doesn't htmlquote the first argument... + sub link($$) { + my ($name, $url) = @_; + + $url =~ s/:/sprintf("%%%02x", ord($&))/eg + if $url =~ /^[^a-z]/; # relative + + sprintf '%s', hrefquote($url), $name; + } + + sub revcmp($$) { + my ($rev1, $rev2) = @_; + + # make no comparison for a tag or a branch + return 0 if $rev1 =~ /[^\d.]/ || $rev2 =~ /[^\d.]/; + + my (@r1) = split (/\./, $rev1); + my (@r2) = split (/\./, $rev2); + my ($a, $b); + + while (($a = shift (@r1)) && ($b = shift (@r2))) { + if ($a != $b) { + return $a <=> $b; + } + } + if (@r1) { return 1; } + if (@r2) { return -1; } + return 0; + } + + sub fatal($$@) { + my ($errcode, $format, @args) = @_; + if ($is_mod_perl) { + Apache->request->status((split (/ /, $errcode))[0]); + } else { + print "Status: $errcode\r\n"; + } + html_header("Error"); + print "

Error: ", + sprintf($format, map(htmlquote($_), @args)), + "

\n"; + html_footer(); + exit(1); + } + + sub redirect($) { + my ($url) = @_; + if ($is_mod_perl) { + Apache->request->status(301); + Apache->request->header_out(Location => $url); + } else { + print "Status: 301 Moved\r\n"; + print "Location: $url\r\n"; + } + html_header("Moved"); + print "

This document is located ", &link('here', $url), "

\n"; + html_footer(); + exit(1); + } + + sub safeglob($) { + my ($filename) = @_; + my ($dirname); + my (@results); + my $dh = do { local (*DH); }; + + ($dirname = $filename) =~ s|/[^/]+$||; + $filename =~ s|.*/||; + + if (opendir($dh, $dirname)) { + my $glob = $filename; + my $t; + + # transform filename from glob to regex. Deal with: + # [, {, ?, * as glob chars + # make sure to escape all other regex chars + $glob =~ s/([\.\(\)\|\+])/\\$1/g; + $glob =~ s/\*/.*/g; + $glob =~ s/\?/./g; + $glob =~ s/{([^}]+)}/($t = $1) =~ s-,-|-g; "($t)"/eg; + foreach (readdir($dh)) { + + if (/^${glob}$/) { + push (@results, "$dirname/" . $_); + } + } + closedir($dh); + } + + @results; + } + + sub search_path($) { + my ($command) = @_; + my $d; + + for $d (split (/:/, $command_path)) { + return "$d/$command" if -x "$d/$command"; + } + + ''; + } + + sub getMimeTypeFromSuffix($) { + my ($fullname) = @_; + my ($mimetype, $suffix); + my $fh = do { local (*FH); }; + + ($suffix = $fullname) =~ s/^.*\.([^.]*)$/$1/; + $mimetype = $MTYPES{$suffix}; + $mimetype = $MTYPES{'*'} if (!$mimetype); + + if (!$mimetype && -f $mime_types) { + + # okey, this is something special - search the + # mime.types database + open($fh, "<$mime_types"); + while (<$fh>) { + if ($_ =~ /^\s*(\S+\/\S+).*\b$suffix\b/) { + $mimetype = $1; + last; + } + } + close($fh); + } + + # okey, didn't find anything useful .. + if (!($mimetype =~ /\S\/\S/)) { + $mimetype = "text/plain"; + } + return $mimetype; + } + + ############################### + # read first lines like head(1) + ############################### + sub head($;$) { + my $fh = $_[0]; + my $linecount = $_[1] || 10; + + my @buf; + + if ($linecount > 0) { + my $i; + for ($i = 0 ; !eof($fh) && $i < $linecount ; $i++) { + push @buf, scalar <$fh>; + } + } else { + @buf = <$fh>; + } + + @buf; + } + + ############################### + # scan vim and Emacs directives + ############################### + sub scan_directives(@) { + my $ts = undef; + + for (@_) { + $ts = $1 if /\b(?:ts|tabstop|tab-width)[:=]\s*([1-9]\d*)\b/; + } + + ('tabstop' => $ts); + } + + sub openOutputFilter() { + return if !defined($output_filter) || $output_filter eq ''; + + open(STDOUT, "|-") and return; + + # child of child + open(STDERR, '>/dev/null'); + exec($output_filter) or exit -1; + } + + ############################### + # show Annotation + ############################### + sub doAnnotate($$) { + my ($rev) = @_; + my ($pid); + my ($pathname, $filename); + my $reader = do { local (*FH); }; + my $writer = do { local (*FH); }; + + # make sure the revisions are wellformed, for security + # reasons .. + if ($rev =~ /[^\w.]/) { + fatal("404 Not Found", + 'Malformed query "%s"', + $ENV{QUERY_STRING}); + } + + ($pathname = $where) =~ s/(Attic\/)?[^\/]*$//; + ($filename = $where) =~ s/^.*\///; + + # this seems to be necessary + $| = 1; + $| = 0; # Flush + + # Work around a mod_perl bug (?) in order to make open2() work. + # Search for "untie STDIN" in mod_perl mailing list archives. + my $old_stdin; + if ($is_mod_perl && ($old_stdin = tied *STDIN)) { + local $^W = undef; + untie *STDIN; + } + + # this annotate version is based on the + # cvs annotate-demo Perl script by Cyclic Software + # It was written by Cyclic Software, http://www.cyclic.com/, and is in + # the public domain. + # we could abandon the use of rlog, rcsdiff and co using + # the cvsserver in a similiar way one day (..after rewrite) + $pid = open2($reader, $writer, $CMD{cvs}, @annotate_options, 'server') + or fatal("500 Internal Error", + 'Fatal Error - unable to open cvs for annotation'); + + # Re-tie STDIN if we fiddled around with it earlier, just to be sure. + tie(*STDIN, ref($old_stdin), $old_stdin) if ($old_stdin && !tied(*STDIN)); + + # OK, first send the request to the server. A simplified example is: + # Root /home/kingdon/zwork/cvsroot + # Argument foo/xx + # Directory foo + # /home/kingdon/zwork/cvsroot/foo + # Directory . + # /home/kingdon/zwork/cvsroot + # annotate + # although as you can see there are a few more details. + + print $writer "Root $cvsroot\n"; + print $writer + "Valid-responses ok error Valid-requests Checked-in Updated Merged Removed M E\n"; + + # Don't worry about sending valid-requests, the server just needs to + # support "annotate" and if it doesn't, there isn't anything to be done. + print $writer "UseUnchanged\n"; + print $writer "Argument -r\n"; + print $writer "Argument $rev\n"; + print $writer "Argument $where\n"; + + # The protocol requires us to fully fake a working directory (at + # least to the point of including the directories down to the one + # containing the file in question). + # So if $where is "dir/sdir/file", then @dirs will be ("dir","sdir","file") + my @dirs = split ('/', $where); + my $path = ""; + foreach (@dirs) { + + if ($path eq "") { + + # In our example, $_ is "dir". + $path = $_; + } else { + print $writer "Directory $path\n"; + print $writer "$cvsroot/$path\n"; + + # In our example, $_ is "sdir" and $path becomes "dir/sdir" + # And the next time, "file" and "dir/sdir/file" (which then gets + # ignored, because we don't need to send Directory for the file). + $path .= "/$_"; + } + } + + # And the last "Directory" before "annotate" is the top level. + print $writer "Directory .\n"; + print $writer "$cvsroot\n"; + + print $writer "annotate\n"; + + # OK, we've sent our command to the server. Thing to do is to + # close the writer side and get all the responses. If "cvs server" + # were nicer about buffering, then we could just leave it open, I think. + close($writer) or die "cannot close: $!"; + + http_header(); + + navigateHeader($scriptwhere, $pathname, $filename, $rev, "annotate"); + print + "

Annotation of $pathname$filename, Revision $rev

\n"; + + # Ready to get the responses from the server. + # For example: + # E Annotations for foo/xx + # E *************** + # M 1.3 (kingdon 06-Sep-97): hello + # ok + my ($lineNr) = 0; + my ($oldLrev, $oldLusr) = ("", ""); + my ($revprint, $usrprint); + + if ($annTable) { + print "\n"; + } else { + print "
";
+ 	}
+ 
+ 	# prefetch several lines
+ 	my @buf = head($reader);
+ 
+ 	my %d = scan_directives(@buf);
+ 
+ 	while (@buf || !eof($reader)) {
+ 		$_ = @buf ? shift @buf : <$reader>;
+ 
+ 		my @words = split;
+ 
+ 		# Adding one is for the (single) space which follows $words[0].
+ 		my $rest = substr($_, length($words[0]) + 1);
+ 		if ($words[0] eq "E") {
+ 			next;
+ 		} elsif ($words[0] eq "M") {
+ 			$lineNr++;
+ 			(my $lrev = substr($_, 2,  13)) =~ y/ //d;
+ 			(my $lusr = substr($_, 16, 9))  =~ y/ //d;
+ 			my $line = substr($_, 36);
+ 			my $isCurrentRev = ($rev eq $lrev);
+ 
+ 			# we should parse the date here ..
+ 			if ($lrev eq $oldLrev) {
+ 				$revprint = sprintf('%-8s', '');
+ 			} else {
+ 				$revprint = sprintf('%-8s', $lrev);
+ 				$revprint =~
+ 				    s`\S+`&link($&, "$scriptwhere$query#rev$&")`e
+ 				    ;    # `
+ 				$oldLusr = '';
+ 			}
+ 
+ 			if ($lusr eq $oldLusr) {
+ 				$usrprint = '';
+ 			} else {
+ 				$usrprint = $lusr;
+ 			}
+ 			$oldLrev = $lrev;
+ 			$oldLusr = $lusr;
+ 
+ 			# Set bold for text-based browsers only - graphical
+ 			# browsers show bold fonts a bit wider than regular fonts,
+ 			# so it looks irregular.
+ 			print "" if ($isCurrentRev && $is_textbased);
+ 
+ 			printf "%s%s %-8s %4d:", $revprint,
+ 			    $isCurrentRev ? '!' : ' ', $usrprint, $lineNr;
+ 			print spacedHtmlText($line, $d{'tabstop'});
+ 
+ 			print "" if ($isCurrentRev && $is_textbased);
+ 		} elsif ($words[0] eq "ok") {
+ 
+ 			# We could complain about any text received after this, like the
+ 			# CVS command line client.  But for simplicity, we don't.
+ 		} elsif ($words[0] eq "error") {
+ 			fatal("500 Internal Error",
+ 			      'Error occured during annotate: %s',
+ 			      $_);
+ 		}
+ 	}
+ 
+ 	if ($annTable) {
+ 		print "
"; + } else { + print ""; + } + html_footer(); + + close($reader) or warn "cannot close: $!"; + wait; + } + + ############################### + # make Checkout + ############################### + sub doCheckout($$) { + my ($fullname, $rev) = @_; + my ($mimetype, $revopt); + my $fh = do { local (*FH); }; + + if ($rev eq 'HEAD' || $rev eq '.') { + $rev = undef; + } + + # make sure the revisions a wellformed, for security + # reasons .. + if (defined($rev) && $rev =~ /[^\w.]/) { + fatal("404 Not Found", + 'Malformed query "%s"', + $ENV{QUERY_STRING}); + } + + # get mimetype + if (defined($input{"content-type"}) + && ($input{"content-type"} =~ /\S\/\S/)) + { + $mimetype = $input{"content-type"} + } else { + $mimetype = &getMimeTypeFromSuffix($fullname); + } + + if (defined($rev)) { + $revopt = "-r$rev"; + if ($use_moddate) { + readLog($fullname, $rev); + $moddate = $date{$rev}; + } + } else { + $revopt = "-rHEAD"; + + if ($use_moddate) { + readLog($fullname); + $moddate = $date{$symrev{HEAD}}; + } + } + + ### just for the record: + ### 'cvs co' seems to have a bug regarding single checkout of + ### directories/files having spaces in it; + ### this is an issue that should be resolved on cvs's side + # + # Safely for a child process to read from. + if (!open($fh, "-|")) { # child + # chdir to $tmpdir before to avoid non-readable cgi-bin directories + chdir($tmpdir); + open(STDERR, ">&STDOUT"); # Redirect stderr to stdout + + # work around a bug of cvs -p; expand symlinks + use Cwd 'abs_path'; + exec($CMD{cvs}, @cvs_options, + '-d', abs_path($cvsroot), + 'co', '-p', + $revopt, $where) or exit -1; + } + + if (eof($fh)) { + fatal("404 Not Found", + '%s is not (any longer) pertinent', + $where); + } + + #=================================================================== + #Checking out squid/src/ftp.c + #RCS: /usr/src/CVS/squid/src/ftp.c,v + #VERS: 1.1.1.28.6.2 + #*************** + + # Parse CVS header + my ($revision, $filename, $cvsheader); + $filename = ""; + while (<$fh>) { + last if (/^\*\*\*\*/); + $revision = $1 if (/^VERS: (.*)$/); + + if (/^Checking out (.*)$/) { + $filename = $1; + $filename =~ s/^\.\/*//; + } + $cvsheader .= $_; + } + + if ($filename ne $where) { + fatal("500 Internal Error", + 'Unexpected output from cvs co: %s', + $cvsheader); + } + $| = 1; + + if ($mimetype eq "text/x-cvsweb-markup") { + &cvswebMarkup($fh, $fullname, $revision); + } else { + http_header($mimetype); + print <$fh>; + } + close($fh); + } + + sub cvswebMarkup($$$) { + my ($filehandle, $fullname, $revision) = @_; + my ($pathname, $filename); + + ($pathname = $where) =~ s/(Attic\/)?[^\/]*$//; + ($filename = $where) =~ s/^.*\///; + my ($fileurl) = urlencode($filename); + + http_header(); + + navigateHeader($scriptwhere, $pathname, $filename, $revision, "view"); + print "
"; + print "\n\n\n\n
"; + print "File: ", &clickablePath($where, 1); + print " ("; + &download_link($fileurl, $revision, "download"); + print ")"; + + if (!$defaultTextPlain) { + print " ("; + &download_link($fileurl, $revision, "as text", "text/plain"); + print ")"; + } + print "
\n"; + + if ($show_log_in_markup) { + readLog($fullname); #,$revision); + printLog($revision, 0); + } else { + print "Version: $revision
\n"; + print "Tag: ", $input{only_with_tag}, "
\n" + if $input{only_with_tag}; + } + print "
"; + my $url = download_url($fileurl, $revision, $mimetype); + print "
"; + + if ($mimetype =~ /^image/) { + printf '
', hrefquote("$url$barequery"); + } elsif ($mimetype =~ m%^application/pdf%) { + printf '
', + hrefquote("$url$barequery"); + } elsif ($preformat_in_markup) { + print "
";
+ 
+ 		# prefetch several lines
+ 		my @buf = head($filehandle);
+ 
+ 		my %d = scan_directives(@buf);
+ 
+ 		while (@buf || !eof($filehandle)) {
+ 			$_ = @buf ? shift @buf : <$filehandle>;
+ 
+ 			print spacedHtmlText($_, $d{'tabstop'});
+ 		}
+ 		print "
"; + } else { + print "
";
+ 
+ 		while (<$filehandle>) {
+ 			print htmlquote($_);
+ 		}
+ 		print "
"; + } + } + + sub viewable($) { + my ($mimetype) = @_; + + $mimetype =~ m%^((text|image)/|application/pdf)%; + } + + ############################### + # Show Colored Diff + ############################### + sub doDiff($$$$$$) { + my ($fullname, $r1, $tr1, $r2, $tr2, $f) = @_; + my $fh = do { local (*FH); }; + my ($rev1, $rev2, $sym1, $sym2, $f1, $f2); + + if (&forbidden_file($fullname)) { + fatal("403 Forbidden", + 'Access forbidden. This file is mentioned in @ForbiddenFiles'); + return; + } + + if ($r1 =~ /([^:]+)(:(.+))?/) { + $rev1 = $1; + $sym1 = $3; + } + if ($r1 eq 'text') { + $rev1 = $tr1; + $sym1 = ""; + } + + if ($r2 =~ /([^:]+)(:(.+))?/) { + $rev2 = $1; + $sym2 = $3; + } + if ($r2 eq 'text') { + $rev2 = $tr2; + $sym2 = ""; + } + + # make sure the revisions a wellformed, for security + # reasons .. + if ($rev1 =~ /[^\w.]/ || $rev2 =~ /[^\w.]/) { + fatal("404 Not Found", + 'Malformed query "%s"', + $ENV{QUERY_STRING}); + } + + # + # rev1 and rev2 are now both numeric revisions. + # Thus we do a DWIM here and swap them if rev1 is after rev2. + # XXX should we warn about the fact that we do this? + if (&revcmp($rev1, $rev2) > 0) { + my ($tmp1, $tmp2) = ($rev1, $sym1); + ($rev1, $sym1) = ($rev2, $sym2); + ($rev2, $sym2) = ($tmp1, $tmp2); + } + my $difftype = $DIFFTYPES{$f}; + + if (!$difftype) { + fatal("400 Bad arguments", + 'Diff format %s not understood', + $f); + } + + my @difftype = @{$difftype->{'opts'}}; + my $human_readable = $difftype->{'colored'}; + + # apply special options + if ($showfunc) { + push @difftype, '-p' if $f ne 's'; + + my ($re1, $re2); + + while (($re1, $re2) = each %funcline_regexp) { + if ($fullname =~ /$re1/) { + push @difftype, '-F', $re2; + last; + } + } + } + + if ($human_readable) { + if ($hr_ignwhite) { + push @difftype, '-w'; + } + if ($hr_ignkeysubst) { + push @difftype, '-kk'; + } + } + + if (!open($fh, "-|")) { # child + open(STDERR, ">&STDOUT"); # Redirect stderr to stdout + openOutputFilter(); + exec($CMD{rcsdiff}, @difftype, "-r$rev1", "-r$rev2", $fullname) or exit -1; + } + if ($human_readable) { + http_header(); + &human_readable_diff($fh, $rev2); + html_footer(); + gzipclose(); + exit; + } else { + http_header("text/plain"); + } + + # + #=================================================================== + #RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v + #retrieving revision 1.16 + #retrieving revision 1.17 + #diff -c -r1.16 -r1.17 + #*** /home/ncvs/src/sys/netinet/tcp_output.c 1995/11/03 22:08:08 1.16 + #--- /home/ncvs/src/sys/netinet/tcp_output.c 1995/12/05 17:46:35 1.17 + # + # Ideas: + # - nuke the stderr output if it's what we expect it to be + # - Add "no differences found" if the diff command supplied no output. + # + #*** src/sys/netinet/tcp_output.c 1995/11/03 22:08:08 1.16 + #--- src/sys/netinet/tcp_output.c 1995/12/05 17:46:35 1.17 RELENG_2_1_0 + # (bogus example, but...) + # + if (grep { $_ eq '-u' } @difftype) { + $f1 = '---'; + $f2 = '\+\+\+'; + } else { + $f1 = '\*\*\*'; + $f2 = '---'; + } + + while (<$fh>) { + if (m|^$f1 $cvsroot|o) { + s|$cvsroot/||o; + if ($sym1) { + chop; + $_ .= " $sym1\n"; + } + } elsif (m|^$f2 $cvsroot|o) { + s|$cvsroot/||o; + + if ($sym2) { + chop; + $_ .= " $sym2\n"; + } + } + print $_; + } + close($fh); + } + + ############################### + # Show Logs .. + ############################### + sub getDirLogs($$@) { + my ($cvsroot, $dirname, @otherFiles) = @_; + my ($state, $otherFiles, $tag, $file, $date, $branchpoint, $branch, + $log); + my ($rev, $revision, $revwanted, $filename, $head, $author); + + $tag = $input{only_with_tag}; + + my ($DirName) = "$cvsroot/$where"; + my (@files, @filetags); + my $fh = do { local (*FH); }; + + push (@files, &safeglob("$DirName/*,v")); + push (@files, &safeglob("$DirName/Attic/*,v")) + if (!$input{'hideattic'}); + foreach my $file (@otherFiles) { + push (@files, "$DirName/$file"); + } + + # just execute rlog if there are any files + if ($#files < 0) { + return; + } + + if (defined($tag)) { + + #can't use -r as - is allowed in tagnames, but misinterpreated by rlog.. + if (!open($fh, "-|")) { # child + open(STDERR, '>/dev/null'); # rlog may complain; ignore. + openOutputFilter(); + exec($CMD{rlog}, @files) or exit -1; + } + } else { + + if (!open($fh, "-|")) { # child + open(STDERR, '>/dev/null'); # rlog may complain; ignore. + openOutputFilter(); + exec($CMD{rlog}, '-r', @files) or exit -1; + } + } + $state = "start"; + + while (<$fh>) { + if ($state eq "start") { + + #Next file. Initialize file variables + $rev = ''; + $revwanted = ''; + $branch = ''; + $branchpoint = ''; + $filename = ''; + $log = ''; + $revision = ''; + %symrev = (); + @filetags = (); + + #jump to head state + $state = "head"; + } + print "$state:$_" if ($verbose); + again: + + if ($state eq "head") { + + #$rcsfile = $1 if (/^RCS file: (.+)$/); #not used (yet) + + if (/^Working file: (.+)$/) { + $filename = $1; + } elsif (/^head: (.+)$/) { + $head = $1; + } elsif (/^branch: (.+)$/) { + $branch = $1 + } elsif (/^symbolic names:/) { + $state = "tags"; + ($branch = $head) =~ s/\.\d+$// + if $branch eq ''; + $branch =~ s/(\d+)$/0.$1/; + $symrev{MAIN} = $branch; + $symrev{HEAD} = $branch; + $alltags{MAIN} = 1; + $alltags{HEAD} = 1; + push (@filetags, "MAIN", "HEAD"); + } elsif (/$LOG_REVSEPARATOR/o) { + $state = "log"; + $rev = ''; + $date = ''; + $log = ''; + + # Try to reconstruct the relative filename if RCS spits out a full path + $filename =~ s%^\Q$DirName\E/%%; + } + next; + } + + if ($state eq "tags") { + if (/^\s+([^:]+):\s+([\d\.]+)\s*$/) { + push (@filetags, $1); + $symrev{$1} = $2; + $alltags{$1} = 1; + next; + } elsif (/^\S/) { + + if (defined($tag)) { + if (defined($symrev{$tag}) + || $tag eq "HEAD") + { + $revwanted = + $symrev{$tag eq "HEAD" ? + "MAIN" : $tag}; + ($branch = $revwanted) =~ + s/\b0\.//; + ($branchpoint = $branch) =~ + s/\.?\d+$//; + $revwanted = '' + if ($revwanted ne $branch); + } elsif ($tag ne "HEAD") { + print + "Tag not found, skip this file" + if ($verbose); + $state = "skip"; + next; + } + } + + foreach my $tagfound (@filetags) { + $tags{$tagfound} = 1; + } + $state = "head"; + goto again; + } + } + + if ($state eq "log") { + if (/$LOG_REVSEPARATOR/o || /$LOG_FILESEPARATOR/o) { + + # End of a log entry. + my $revbranch = $rev; + $revbranch =~ s/\.\d+$//; + print "$filename $rev Wanted: $revwanted ", + "Revbranch: $revbranch Branch: $branch ", + "Branchpoint: $branchpoint\n" + if ($verbose); + + if ($revwanted eq '' && $branch ne '' + && $branch eq $revbranch || !defined($tag)) + { + print + "File revision $rev found for branch $branch\n" + if ($verbose); + $revwanted = $rev; + } + + if ($revwanted ne '' ? $rev eq $revwanted : + $branchpoint ne '' ? $rev eq $branchpoint : + 0 && ($rev eq $head)) + { # Don't think head is needed here.. + print + "File info $rev found for $filename\n" + if ($verbose); + my @finfo = + ($rev, $date, $log, $author, + $filename); + my ($name); + ($name = $filename) =~ s%/.*%%; + $fileinfo{$name} = [@finfo]; + $state = "done" if ($rev eq $revwanted); + } + $rev = ''; + $date = ''; + $log = ''; + } elsif ($date eq '' + && m|^date:\s+(\d+)/(\d+)/(\d+)\s+(\d+):(\d+):(\d+);| + ) + { + my $yr = $1; + + # damn 2-digit year routines :-) + if ($yr > 100) { + $yr -= 1900; + } + $date = + &Time::Local::timegm($6, $5, $4, $3, $2 - 1, + $yr); + ($author) = /author: ([^;]+)/; + $state = "log"; + $log = ''; + next; + } elsif ($rev eq '' && /^revision (\d+(?:\.\d+)+).*$/) { + $rev = $1; # .*$ eats up the locker(lockers?) info, if any + next; + } else { + $log .= $_; + } + } + + if (/$LOG_FILESEPARATOR/o) { + $state = "start"; + next; + } + } + + if ($. == 0) { + fatal("500 Internal Error", + 'Failed to spawn GNU rlog on "%s".

Did you set the $command_path in your configuration file correctly ? (Currently "%s"', + join (", ", @files), $command_path); + } + close($fh); + } + + sub readLog($;$) { + my ($fullname, $revision) = @_; + my ($symnames, $head, $rev, $br, $brp, $branch, $branchrev); + my $fh = do { local (*FH); }; + + if (defined($revision)) { + $revision = "-r$revision"; + } else { + $revision = ""; + } + + undef %symrev; + undef %revsym; + undef @allrevisions; + undef %date; + undef %author; + undef %state; + undef %difflines; + undef %log; + + print("Going to rlog '$fullname'\n") if ($verbose); + if (!open($fh, "-|")) { # child + if ($revision ne '') { + openOutputFilter(); + exec($CMD{rlog}, $revision, $fullname) or exit -1; + } else { + openOutputFilter(); + exec($CMD{rlog}, $fullname) or exit -1; + } + } + + while (<$fh>) { + print if ($verbose); + if ($symnames) { + if (/^\s+([^:]+):\s+([\d\.]+)/) { + $symrev{$1} = $2; + } else { + $symnames = 0; + } + } elsif (/^head:\s+([\d\.]+)/) { + $head = $1; + } elsif (/^branch:\s+([\d\.]+)/) { + $curbranch = $1; + } elsif (/^symbolic names/) { + $symnames = 1; + } elsif (/^-----/) { + last; + } + } + ($curbranch = $head) =~ s/\.\d+$// if (!defined($curbranch)); + + # each log entry is of the form: + # ---------------------------- + # revision 3.7.1.1 + # date: 1995/11/29 22:15:52; author: fenner; state: Exp; lines: +5 -3 + # log info + # ---------------------------- + + # For a locked revision, the first line after the separator + # becomes smth like + # revision 9.19 locked by: vassilii; + + logentry: + + while (!/$LOG_FILESEPARATOR/o) { + $_ = <$fh>; + last logentry if (!defined($_)); # EOF + print "R:", $_ if ($verbose); + if (/^revision (\d+(?:\.\d+)+)/) { + $rev = $1; + unshift (@allrevisions, $rev); + } elsif (/$LOG_FILESEPARATOR/o || /$LOG_REVSEPARATOR/o) { + next logentry; + } else { + + # The rlog output is syntactically ambiguous. We must + # have guessed wrong about where the end of the last log + # message was. + # Since this is likely to happen when people put rlog output + # in their commit messages, don't even bother keeping + # these lines since we don't know what revision they go with + # any more. + next logentry; + } + $_ = <$fh>; + print "D:", $_ if ($verbose); + if ( + m|^date:\s+(\d+)/(\d+)/(\d+)\s+(\d+):(\d+):(\d+);\s+author:\s+(\S+);\s+state:\s+(\S+);\s+(lines:\s+([0-9\s+-]+))?| + ) + { + my $yr = $1; + + # damn 2-digit year routines :-) + if ($yr > 100) { + $yr -= 1900; + } + $date{$rev} = + &Time::Local::timegm($6, $5, $4, $3, $2 - 1, $yr); + $author{$rev} = $7; + $state{$rev} = $8; + $difflines{$rev} = $10; + } else { + fatal("500 Internal Error", + 'Error parsing RCS output: %s', + $_); + } + line: + + while (<$fh>) { + print "L:", $_ if ($verbose); + next line if (/^branches:\s/); + last line + if (/$LOG_FILESEPARATOR/o || /$LOG_REVSEPARATOR/o); + $log{$rev} .= $_; + } + print "E:", $_ if ($verbose); + } + close($fh); + print "Done reading RCS file\n" if ($verbose); + + @revorder = reverse sort { revcmp($a, $b) } @allrevisions; + print "Done sorting revisions", join (" ", @revorder), "\n" + if ($verbose); + + # + # HEAD is an artificial tag which is simply the highest tag number on the main + # branch, unless there is a branch tag in the RCS file in which case it's the + # highest revision on that branch. Find it by looking through @revorder; it + # is the first commit listed on the appropriate branch. + # This is not neccesary the same revision as marked as head in the RCS file. + my $headrev = $curbranch || "1"; + ($symrev{"MAIN"} = $headrev) =~ s/(\d+)$/0.$1/; + + foreach $rev (@revorder) { + if ($rev =~ /^(\S*)\.\d+$/ && $headrev eq $1) { + $symrev{"HEAD"} = $rev; + last; + } + } + ($symrev{"HEAD"} = $headrev) =~ s/\.\d+$// + if (!defined($symrev{"HEAD"})); + print "Done finding HEAD\n" if ($verbose); + + # + # Now that we know all of the revision numbers, we can associate + # absolute revision numbers with all of the symbolic names, and + # pass them to the form so that the same association doesn't have + # to be built then. + # + undef @branchnames; + undef %branchpoint; + undef $sel; + + foreach (reverse sort keys %symrev) { + $rev = $symrev{$_}; + if ($rev =~ /^((.*)\.)?\b0\.(\d+)$/) { + push (@branchnames, $_); + + # + # A revision number of A.B.0.D really translates into + # "the highest current revision on branch A.B.D". + # + # If there is no branch A.B.D, then it translates into + # the head A.B . + # + # This reasoning also applies to the main branch A.B, + # with the branch number 0.A, with the exception that + # it has no head to translate to if there is nothing on + # the branch, but I guess this can never happen? + # + # (the code below gracefully forgets about the branch + # if it should happen) + # + $head = defined($2) ? $2 : ""; + $branch = $3; + $branchrev = $head . ($head ne "" ? "." : "") . $branch; + my $regex; + $regex = quotemeta $branchrev; + $rev = $head; + + foreach my $r (@revorder) { + if ($r =~ /^${regex}\b/) { + $rev = $branchrev; + last; + } + } + next if ($rev eq ""); + + if ($rev ne $head && $head ne "") { + $branchpoint{$head} .= ", " + if ($branchpoint{$head}); + $branchpoint{$head} .= $_; + } + } + $revsym{$rev} .= ", " if ($revsym{$rev}); + $revsym{$rev} .= $_; + $sel .= "\n"; + } + print "Done associating revisions with branches\n" if ($verbose); + + my ($onlyonbranch, $onlybranchpoint); + if ($onlyonbranch = $input{'only_with_tag'}) { + $onlyonbranch = $symrev{$onlyonbranch}; + if ($onlyonbranch =~ s/\b0\.//) { + ($onlybranchpoint = $onlyonbranch) =~ s/\.\d+$//; + } else { + $onlybranchpoint = $onlyonbranch; + } + + if (!defined($onlyonbranch) || $onlybranchpoint eq "") { + fatal("404 Tag not found", + 'Tag %s not defined', + $input{'only_with_tag'}); + } + } + + undef @revisions; + + foreach (@allrevisions) { + ($br = $_) =~ s/\.\d+$//; + ($brp = $br) =~ s/\.\d+$//; + next + if ($onlyonbranch && $br ne $onlyonbranch + && $_ ne $onlybranchpoint); + unshift (@revisions, $_); + } + + if ($logsort eq "date") { + + # Sort the revisions in commit order an secondary sort on revision + # (secondary sort needed for imported sources, or the first main + # revision gets before the same revision on the 1.1.1 branch) + @revdisplayorder = + sort { $date{$b} <=> $date{$a} || -revcmp($a, $b) } + @revisions; + } elsif ($logsort eq "rev") { + + # Sort the revisions in revision order, highest first + @revdisplayorder = reverse sort { revcmp($a, $b) } @revisions; + } else { + + # No sorting. Present in the same order as rlog / cvs log + @revdisplayorder = @revisions; + } + + } + + sub printDiffLinks($$) { + my ($text, $url) = @_; + my @extra; + + local $_; + for ($DIFFTYPES{$defaultDiffType}{'colored'} ? qw(u) : qw(h)) { + my $f = $_ eq $defaultDiffType ? '' : $_; + + push @extra, &link(lc $DIFFTYPES{$_}{'descr'}, "$url&f=$f"); + } + + print &link($text, $url), ' (', join (', ', @extra), ')'; + } + + sub printLog($;$) { + my ($link, $br, $brp); + ($_, $link) = @_; + ($br = $_) =~ s/\.\d+$//; + ($brp = $br) =~ s/\.?\d+$//; + my ($isDead, $prev); + + $link = 1 if (!defined($link)); + $isDead = ($state{$_} eq "dead"); + + print "

\n"; + if ($link && !$isDead) { + my ($filename); + ($filename = $where) =~ s/^.*\///; + my ($fileurl) = urlencode($filename); + print ""; + + if (defined($revsym{$_})) { + foreach my $sym (split (", ", $revsym{$_})) { + print ""; + } + } + + if (defined($revsym{$br}) && $revsym{$br} + && !defined($nameprinted{$br})) + { + foreach my $sym (split (", ", $revsym{$br})) { + print ""; + } + $nameprinted{$br} = 1; + } + print "\n Revision "; + &download_link($fileurl, $_, $_, + $defaultViewable ? "text/x-cvsweb-markup" : undef); + + if ($defaultViewable) { + print " / ("; + &download_link($fileurl, $_, "download", $mimetype); + print ")"; + } + + if (not $defaultTextPlain) { + print " / ("; + &download_link($fileurl, $_, "as text", "text/plain"); + print ")"; + } + + if (!$defaultViewable) { + print " / ("; + &download_link($fileurl, $_, "view", + "text/x-cvsweb-markup"); + print ")"; + } + + if ($allow_annotate) { + print " - "; + print &link( + 'annotate', + sprintf( + '%s/%s?annotate=%s%s', $scriptname, + urlencode($where), $_, + $barequery + ) + ); + } + + # Plus a select link if enabled, and this version isn't selected + if ($allow_version_select) { + if ((!defined($input{"r1"}) || $input{"r1"} ne $_)) { + print " - "; + print &link( + '[select for diffs]', + sprintf( + '%s?r1=%s%s', $scriptwhere, + $_, $barequery + ) + ); + } else { + print " - [selected]"; + } + } + } else { + print "Revision $_"; + } + + if (/^1\.1\.1\.\d+$/) { + print " (vendor branch)"; + } + if (defined @mytz) { + my ($est) = $mytz[(localtime($date{$_}))[8]]; + print ", ", scalar localtime($date{$_}), " $est ("; + } else { + print ", ", scalar gmtime($date{$_}), " UTC ("; + } + print readableTime(time() - $date{$_}, 1), " ago)"; + print " by "; + print "", $author{$_}, "\n"; + print "
Branch: ", $link ? link_tags($revsym{$br}) : $revsym{$br}, + "\n" + if ($revsym{$br}); + print "
CVS Tags: ", $link ? link_tags($revsym{$_}) : $revsym{$_}, + "" + if ($revsym{$_}); + print "
Branch point for: ", + $link ? link_tags($branchpoint{$_}) : $branchpoint{$_}, "\n" + if ($branchpoint{$_}); + + # Find the previous revision + my @prevrev = split (/\./, $_); + do { + if (--$prevrev[$#prevrev] <= 0) { + + # If it was X.Y.Z.1, just make it X.Y + pop (@prevrev); + pop (@prevrev); + } + $prev = join (".", @prevrev); + } until (defined($date{$prev}) || $prev eq ""); + + if ($prev ne "") { + if ($difflines{$_}) { + print + "
Changes since $prev: $difflines{$_} lines"; + } + } + + if ($isDead) { + print "
FILE REMOVED\n"; + } elsif ($link) { + my %diffrev = (); + $diffrev{$_} = 1; + $diffrev{""} = 1; + print '
'; + my $diff = 'Diff'; + + # + # Offer diff to previous revision + if ($prev) { + $diffrev{$prev} = 1; + + my $url = + sprintf('%s.diff?r1=%s&r2=%s%s', $scriptwhere, + $prev, $_, $barequery); + + print $diff, " to previous "; + $diff = ''; + printDiffLinks($prev, $url); + } + + # + # Plus, if it's on a branch, and it's not a vendor branch, + # offer a diff with the branch point. + if ($revsym{$brp} && !/^1\.1\.1\.\d+$/ + && !defined($diffrev{$brp})) + { + my $url = + sprintf('%s.diff?r1=%s&r2=%s%s', $scriptwhere, $brp, + $_, $barequery); + + print $diff, " to branchpoint "; + $diff = ''; + printDiffLinks($brp, $url); + } + + # + # Plus, if it's on a branch, and it's not a vendor branch, + # offer to diff with the next revision of the higher branch. + # (e.g. change gets committed and then brought + # over to -stable) + if (/^\d+\.\d+\.\d+/ && !/^1\.1\.1\.\d+$/) { + my ($i, $nextmain); + + for ($i = 0 ; $i < $#revorder && $revorder[$i] ne $_ ; + $i++) + { + } + my @tmp2 = split (/\./, $_); + for ($nextmain = "" ; $i > 0 ; $i--) { + my $next = $revorder[$i - 1]; + my @tmp1 = split (/\./, $next); + + if (@tmp1 < @tmp2) { + $nextmain = $next; + last; + } + + # Only the highest version on a branch should have + # a diff for the "next main". + last + if (@tmp1 - 1 <= @tmp2 + && join (".", @tmp1[0 .. $#tmp1 - 1]) eq + join (".", @tmp2[0 .. $#tmp1 - 1])); + } + + if (!defined($diffrev{$nextmain})) { + $diffrev{$nextmain} = 1; + + my $url = + sprintf('%s.diff?r1=%s&r2=%s%s', + $scriptwhere, $nextmain, $_, + $barequery); + + print $diff, " next main "; + $diff = ''; + printDiffLinks($nextmain, $url); + } + } + + # Plus if user has selected only r1, then present a link + # to make a diff to that revision + if (defined($input{"r1"}) && !defined($diffrev{$input{"r1"}})) { + $diffrev{$input{"r1"}} = 1; + + my $url = + sprintf('%s.diff?r1=%s&r2=%s%s', $scriptwhere, + $input{'r1'}, $_, $barequery); + + print $diff, " to selected "; + $diff = ''; + printDiffLinks($input{'r1'}, $url); + } + + } + print "\n

\n
\n";
+ 	print &htmlify($log{$_}, $allow_log_extra);
+ 	print "
\n"; + } + + sub doLog($) { + my ($fullname) = @_; + my ($diffrev, $upwhere, $filename, $backurl); + + readLog($fullname); + + html_header("CVS log for $where"); + ($upwhere = $where) =~ s|(Attic/)?[^/]+$||; + ($filename = $where) =~ s|^.*/||; + $backurl = $scriptname . "/" . urlencode($upwhere) . $query; + print "

\n "; + print &link($backicon, "$backurl#$filename"), " Up to ", + &clickablePath($upwhere, 1), "\n

\n"; + print "

\n "; + print &link('Request diff between arbitrary revisions', '#diff'); + print "\n

\n
\n"; + + print "

\n"; + if ($curbranch) { + print "Default branch: ", ($revsym{$curbranch} || $curbranch); + } else { + print "No default branch"; + } + print "
\n"; + + if ($input{only_with_tag}) { + print "Current tag: $input{only_with_tag}
\n"; + } + print "

\n"; + + undef %nameprinted; + + for (my $i = 0 ; $i <= $#revdisplayorder ; $i++) { + print "
\n"; + printLog($revdisplayorder[$i]); + } + + print "
\n

\n"; + print "\n"; + print "This form allows you to request diff's between any two\n"; + print "revisions of a file. You may select a symbolic revision\n"; + print "name using the selection box or you may type in a numeric\n"; + print "name using the type-in text box.\n"; + print "\n

\n"; + print + "
\n"; + + foreach (@stickyvars) { + printf('', $_, + $input{$_}) + if (defined($input{$_}) + && ((!defined($DEFAULTVALUE{$_}) + || $input{$_} ne $DEFAULTVALUE{$_}) && $input{$_} ne "")); + } + print "\n\n"; + print "\n"; + print "\n\n"; + print "\n\n"; + print "\n"; + print "\n
"; + print "\n"; + print "\n"; + $diffrev = $revdisplayorder[$#revdisplayorder]; + $diffrev = $input{"r1"} if (defined($input{"r1"})); + print + "
"; + print "\n"; + print "\n"; + $diffrev = $revdisplayorder[0]; + $diffrev = $input{"r2"} if (defined($input{"r2"})); + print + "
\n"; + print "
\n"; + print "
\n"; + print "
\n"; + print "\n"; + print "\n\n"; + print "\n\n\n"; + + if (@branchnames) { + print "\n\n"; + print "\n\n\n"; + } + + foreach (@stickyvars) { + next if ($_ eq "f"); + next if ($_ eq "only_with_tag"); + next if ($_ eq "logsort"); + print "\n" + if (defined($input{$_}) + && (!defined($DEFAULTVALUE{$_}) + || $input{$_} ne $DEFAULTVALUE{$_}) && $input{$_} ne ""); + } + print "\n\n\n"; + print "\n"; + print "\n
"; + print ""; + printDiffSelect($use_java_script); + print "
"; + print ""; + print "\n"; + print "
"; + print "\n"; + print ""; + printLogSortSelect($use_java_script); + print "
\n"; + print "
\n"; + html_footer(); + } + + sub flush_diff_rows($$$$) { + my $j; + my ($leftColRef, $rightColRef, $leftRow, $rightRow) = @_; + + if (!defined($state)) { + return; + } + + if ($state eq "PreChangeRemove") { # we just got remove-lines before + for ($j = 0 ; $j < $leftRow ; $j++) { + print + "\n @$leftColRef[$j]\n"; + print + " \n\n"; + } + } elsif ($state eq "PreChange") { # state eq "PreChange" + # we got removes with subsequent adds + + for ($j = 0 ; $j < $leftRow || $j < $rightRow ; $j++) + { # dump out both cols + print "\n"; + if ($j < $leftRow) { + print + " @$leftColRef[$j]"; + } else { + print + " "; + } + print "\n"; + + if ($j < $rightRow) { + print + " @$rightColRef[$j]"; + } else { + print + " "; + } + print "\n\n"; + } + } + } + + ## + # Function to generate Human readable diff-files + # human_readable_diff(String revision_to_return_to); + ## + sub human_readable_diff($) { + my ($difftxt, $where_nd, $filename, $pathname, $scriptwhere_nd); + my ($fh, $rev) = @_; + my ($date1, $date2, $r1d, $r2d, $r1r, $r2r, $rev1, $rev2, $sym1, $sym2); + my (@rightCol, @leftCol); + + ($where_nd = $where) =~ s/.diff$//; + ($filename = $where_nd) =~ s/^.*\///; + ($pathname = $where_nd) =~ s/(Attic\/)?[^\/]*$//; + ($scriptwhere_nd = $scriptwhere) =~ s/.diff$//; + + navigateHeader($scriptwhere_nd, $pathname, $filename, $rev, "diff"); + + # Read header to pick up read revision and date, if possible + while (<$fh>) { + ($r1d, $r1r) = /\t(.*)\t(.*)$/ if (/^--- /); + ($r2d, $r2r) = /\t(.*)\t(.*)$/ if (/^\+\+\+ /); + last if (/^\+\+\+ /); + } + + if (defined($r1r) && $r1r =~ /^(\d+\.)+\d+$/) { + $rev1 = $r1r; + $date1 = $r1d; + } + if (defined($r2r) && $r2r =~ /^(\d+\.)+\d+$/) { + $rev2 = $r2r; + $date2 = $r2d; + } + + print + "

Diff for /$where_nd between version $rev1 and $rev2

\n", + # Using style=\"border: none\" here breaks NS 4.x badly... + "\n", + "\n", "\n", "\n"; + + my $leftRow = 0; + my $rightRow = 0; + my ($oldline, $newline, $funname, $diffcode, $rest); + + # Process diff text + + # prefetch several lines + my @buf = head($fh); + + my %d = scan_directives(@buf); + + while (@buf || !eof($fh)) { + $difftxt = @buf ? shift @buf : <$fh>; + + if ($difftxt =~ /^@@/) { + ($oldline, $newline, $funname) = + $difftxt =~ /@@ \-([0-9]+).*\+([0-9]+).*@@(.*)/; + $funname = htmlquote($funname); + $funname =~ s/\s/ /go; + print + "\n\n\n"; + $state = "dump"; + $leftRow = 0; + $rightRow = 0; + } else { + ($diffcode, $rest) = $difftxt =~ /^([-+ ])(.*)/; + $_ = spacedHtmlText($rest, $d{'tabstop'}); + + ######### + # little state machine to parse unified-diff output (Hen, zeller at think.de) + # in order to get some nice 'ediff'-mode output + # states: + # "dump" - just dump the value + # "PreChangeRemove" - we began with '-' .. so this could be the start of a 'change' area or just remove + # "PreChange" - okey, we got several '-' lines and moved to '+' lines -> this is a change block + ########## + + if ($diffcode eq '+') { + if ($state eq "dump") + { # 'change' never begins with '+': just dump out value + print + "\n\n\n\n"; + } else { # we got minus before + $state = "PreChange"; + $rightCol[$rightRow++] = $_; + } + } elsif ($diffcode eq '-') { + $state = "PreChangeRemove"; + $leftCol[$leftRow++] = $_; + } else { # empty diffcode + flush_diff_rows \@leftCol, \@rightCol, $leftRow, + $rightRow; + print "\n\n\n\n"; + $state = "dump"; + $leftRow = 0; + $rightRow = 0; + } + } + } + close($fh); + + flush_diff_rows \@leftCol, \@rightCol, $leftRow, $rightRow; + + # state is empty if we didn't have any change + if (!$state) { + print "\n\n\n"; + print "\n"; + print + "\n\n"; + } + print "
", + "version $rev1"; + print ", $date1" if (defined($date1)); + print "
Tag: $sym1\n" if ($sym1); + print "
", "version $rev2"; + print ", $date2" if (defined($date2)); + print "
Tag: $sym2\n" if ($sym1); + print "
"; + print + "\n\n\n\n
Line $oldline"; + print + " $funname
"; + print "
"; + print + "\n\n\n\n
Line $newline"; + print + " $funname
\n"; + print "
  $_
 $_ $_
 
- No viewable change -
\n"; + + print "
\n"; + print "
\n"; + print "\n\n\n\n"; + + print "\n
\n"; + + # print legend + print "\n\n\n\n
"; + print "Legend:
\n"; + print + "\n\n\n\n"; + print + "\n\n\n"; + print + "\n\n\n\n"; + print "
Removed from v.$rev1 
changed lines
 Added in v.$rev2
\n
\n
"; + + # Print format selector + foreach my $var (keys %input) { + next if ($var eq "f"); + next + if (defined($DEFAULTVALUE{$var}) + && $DEFAULTVALUE{$var} eq $input{$var}); + print "\n"; + } + printDiffSelect($use_java_script); + print "\n"; + print "
\n"; + print "
\n"; + } + + sub navigateHeader($$$$$) { + my ($swhere, $path, $filename, $rev, $title) = @_; + $swhere = "" if ($swhere eq $scriptwhere); + $swhere = './' . urlencode($filename) if ($swhere eq ""); + + # TODO: this should be moved into external CSS file. + my $css = ''; + if ($title eq 'diff') { + $css = " + "; + } + + print < + + $path$filename - $title - $rev$css + $HTML_META + $body_tag_for_src + + "; + + print ""; + print "
+ EOF + + print &link($backicon, "$swhere$query#rev$rev"); + print "Return to ", &link($filename, "$swhere$query#rev$rev"), + " CVS log"; + print " $fileicon$diricon Up to ", + &clickablePath($path, 1), + "
"; + } + + sub plural_write($$) { + my ($num, $text) = @_; + if ($num != 1) { + $text .= "s"; + } + + if ($num > 0) { + return join (' ', $num, $text); + } else { + return ""; + } + } + + ## + # print readable timestamp in terms of + # '..time ago' + # H. Zeller + ## + sub readableTime($$) { + my ($i, $break, $retval); + my ($secs, $long) = @_; + + # this function works correct for time >= 2 seconds + if ($secs < 2) { + return "very little time"; + } + + my %desc = ( + 1, 'second', 60, 'minute', 3600, 'hour', + 86400, 'day', 604800, 'week', 2628000, 'month', + 31536000, 'year' + ); + my @breaks = sort { $a <=> $b } keys %desc; + $i = 0; + + while ($i <= $#breaks && $secs >= 2 * $breaks[$i]) { + $i++; + } + $i--; + $break = $breaks[$i]; + $retval = plural_write(int($secs / $break), $desc{$break}); + + if ($long == 1 && $i > 0) { + my $rest = $secs % $break; + $i--; + $break = $breaks[$i]; + my $resttime = plural_write(int($rest / $break), $desc{$break}); + if ($resttime) { + $retval .= ", $resttime"; + } + } + + return $retval; + } + + ## + # clickablePath(String pathname, boolean last_item_clickable) + # + # returns a html-ified path whereas each directory is a link for + # faster navigation. last_item_clickable controls whether the + # basename (last directory/file) is a link as well + ## + sub clickablePath($$) { + my ($pathname, $clickLast) = @_; + my $retval = ''; + + if ($pathname eq '/') { + + # this should never happen - chooseCVSRoot() is + # intended to do this + $retval = "[$cvstree]"; + } else { + $retval .= ' ' . &link("[$cvstree]", + sprintf('%s/%s#dirlist', $scriptname, $query)); + my $wherepath = ''; + my ($lastslash) = $pathname =~ m|/$|; + + foreach (split (/\//, $pathname)) { + $retval .= " / "; + $wherepath .= "/$_"; + my ($last) = "$wherepath/" eq "/$pathname" + || $wherepath eq "/$pathname"; + + if ($clickLast || !$last) { + $retval .= &link($_, + join ('', $scriptname, + urlencode($wherepath), + (!$last || $lastslash ? '/' : ''), + $query, + (!$last || $lastslash ? "#dirlist" : "") + )); + } else { # do not make a link to the current dir + $retval .= $_; + } + } + } + return $retval; + } + + sub chooseCVSRoot() { + + print "
\n"; + if (2 <= @CVSROOT) { + my ($k); + foreach $k (keys %input) { + print "\n" + if ($input{$k}) && ($k ne "cvsroot"); + } + + # Form-Elements look wierd in Netscape if the background + # isn't gray and the form elements are not placed + # within a table ... + print "\n\n"; + print "\n"; + print "\n\n\n
\n\n"; + } else { + + # no choice -- but we need the form to select module/path, + # at least for Netscape + print "

\n"; + print "CVS Root: [$cvstree]"; + } + + print " \n"; + print "\n"; + print ""; + + if (2 <= @CVSROOT) { + print "

"; + } else { + print "

"; + } + print "\n
"; + } + + sub chooseMirror() { + + # This code comes from the original BSD-cvsweb + # and may not be useful for your site; If you don't + # set %MIRRORS this won't show up, anyway. + scalar(%MIRRORS) or return; + + # Should perhaps exclude the current site somehow... + print "\n

\nThis CVSweb is mirrored in\n"; + + my @tmp = map(&link(htmlquote($_), $MIRRORS{$_}), + sort keys %MIRRORS); + my $tmp = pop(@tmp); + + if (scalar(@tmp)) { + print join(', ', @tmp), ' and '; + } + + print "$tmp.\n

\n"; + } + + sub fileSortCmp() { + my ($comp) = 0; + my ($c, $d, $af, $bf); + + ($af = $a) =~ s/,v$//; + ($bf = $b) =~ s/,v$//; + my ($rev1, $date1, $log1, $author1, $filename1) = @{$fileinfo{$af}} + if (defined($fileinfo{$af})); + my ($rev2, $date2, $log2, $author2, $filename2) = @{$fileinfo{$bf}} + if (defined($fileinfo{$bf})); + + if (defined($filename1) && defined($filename2) && $af eq $filename1 + && $bf eq $filename2) + { + + # Two files + $comp = -revcmp($rev1, $rev2) if ($byrev && $rev1 && $rev2); + $comp = ($date2 <=> $date1) if ($bydate && $date1 && $date2); + $comp = ($log1 cmp $log2) if ($bylog && $log1 && $log2); + $comp = ($author1 cmp $author2) + if ($byauthor && $author1 && $author2); + } + + if ($comp == 0) { + + # Directories first, then files under version control, + # then other, "rogue" files. + # Sort by filename if no other criteria available. + + my $ad = ((-d "$fullname/$a") ? 'D' + : (defined($fileinfo{$af}) ? 'F' : 'R')); + my $bd = ((-d "$fullname/$b") ? 'D' + : (defined($fileinfo{$bf}) ? 'F' : 'R')); + ($c = $a) =~ s|.*/||; + ($d = $b) =~ s|.*/||; + $comp = ("$ad$c" cmp "$bd$d"); + } + return $comp; + } + + # make A url for downloading + sub download_url($$;$) { + my ($url, $revision, $mimetype) = @_; + + $revision =~ s/\b0\.//; + + if (defined($checkoutMagic) + && (!defined($mimetype) || $mimetype ne "text/x-cvsweb-markup")) + { + my $path = $where; + $path =~ s|[^/]+$||; + $url = "$scriptname/$checkoutMagic/${path}$url"; + } + $url .= "?rev=$revision"; + $url .= '&content-type=' . urlencode($mimetype) if (defined($mimetype)); + + $url; + } + + # Presents a link to download the + # selected revision + sub download_link($$$;$) { + my ($url, $revision, $textlink, $mimetype) = @_; + my ($fullurl) = download_url($url, $revision, $mimetype); + + $fullurl =~ s/:/sprintf("%%%02x", ord($&))/eg; + + printf '$textlink"; + } + + # Returns a Query string with the + # specified parameter toggled + sub toggleQuery($$) { + my ($toggle, $value) = @_; + my ($newquery, $var); + my (%vars); + %vars = %input; + + if (defined($value)) { + $vars{$toggle} = $value; + } else { + $vars{$toggle} = $vars{$toggle} ? 0 : 1; + } + + # Build a new query of non-default paramenters + $newquery = ""; + foreach $var (@stickyvars) { + my ($value) = defined($vars{$var}) ? $vars{$var} : ""; + my ($default) = + defined($DEFAULTVALUE{$var}) ? $DEFAULTVALUE{$var} : ""; + + if ($value ne $default) { + $newquery .= "&" if ($newquery ne ""); + $newquery .= urlencode($var) . "=" . urlencode($value); + } + } + + if ($newquery) { + return '?' . $newquery; + } + return ""; + } + + sub urlencode($) { + local ($_) = @_; + + s/[\000-+{-\377]/sprintf("%%%02x", ord($&))/ge; + + $_; + } + + sub htmlquote($) { + local ($_) = @_; + + # Special Characters; RFC 1866 + s/&/&/g; + s/\"/"/g; + s//>/g; + + $_; + } + + sub htmlunquote($) { + local ($_) = @_; + + # Special Characters; RFC 1866 + s/"/\"/g; + s/<//g; + s/&/&/g; + + $_; + } + + sub hrefquote($) { + local ($_) = @_; + + y/ /+/; + + htmlquote($_) + } + + sub http_header(;$) { + my $content_type = shift || "text/html"; + + $content_type .= "; charset=$charset" + if $content_type =~ m,^text/, && defined($charset) && $charset; + + if (defined($moddate)) { + if ($is_mod_perl) { + Apache->request->header_out( + "Last-Modified" => scalar gmtime($moddate) + . " GMT"); + } else { + print "Last-Modified: ", scalar gmtime($moddate), + " GMT\r\n"; + } + } + + if ($is_mod_perl) { + Apache->request->content_type($content_type); + } else { + print "Content-Type: $content_type\r\n"; + } + + if ($allow_compress && $maycompress) { + if ($has_zlib + || (defined($CMD{gzip}) && open(GZIP, "| $CMD{gzip} -1 -c")) + ) + { + + if ($is_mod_perl) { + Apache->request->content_encoding("x-gzip"); + Apache->request->header_out( + Vary => "Accept-Encoding"); + Apache->request->send_http_header; + } else { + print "Content-Encoding: x-gzip\r\n"; + print "Vary: Accept-Encoding\r\n" + ; #RFC 2068, 14.43 + print "\r\n"; # Close headers + } + $| = 1; + $| = 0; # Flush header output + + if ($has_zlib) { + tie *GZIP, __PACKAGE__, \*STDOUT; + } + select(GZIP); + $gzip_open = 1; + + # print "" if ($content_type =~ m|^text/html\b|); + } else { + if ($is_mod_perl) { + Apache->request->send_http_header; + } else { + print "\r\n"; # Close headers + } + print + "Unable to find gzip binary in the \$command_path ($command_path) to compress output
"; + } + } else { + + if ($is_mod_perl) { + Apache->request->send_http_header; + } else { + print "\r\n"; # Close headers + } + } + } + + sub html_header($) { + my ($title) = @_; + http_header("text/html"); + print < + + $title + $HTML_META + $body_tag + $logo

$title

+ EOH + } + + sub html_footer() { + print "
\n
$address
\n" if $address; + print "\n\n"; + } + + sub link_tags($) { + my ($tags) = @_; + my ($ret) = ""; + my ($fileurl, $filename); + + ($filename = $where) =~ s/^.*\///; + $fileurl = './' . urlencode($filename); + + foreach my $sym (split (", ", $tags)) { + $ret .= ",\n" if ($ret ne ""); + $ret .= + &link($sym, $fileurl . toggleQuery('only_with_tag', $sym)); + } + return "$ret\n"; + } + + # + # See if a module is listed in the config file's @HideModules list. + # + sub forbidden_module($) { + my ($module) = @_; + local $_; + + for (@HideModules) { + return 1 if $module =~ $_; + } + return 0; + } + + sub forbidden_file($) { + my ($path) = @_; + $path = substr($path, length($cvsroot) + 1); + local $_; + for (@ForbiddenFiles) { + return 1 if $path =~ $_; + } + return 0; + } + + # Close the GZIP handle remove the tie. + + sub gzipclose { + if ($gzip_open) { + select(STDOUT); + close(GZIP); + untie *GZIP; + $gzip_open = 0; + } + } + + # implement a gzipped file handle via the Compress:Zlib compression + # library. + + sub MAGIC1() { 0x1f } + sub MAGIC2() { 0x8b } + sub OSCODE() { 3 } + + sub TIEHANDLE { + my ($class, $out) = @_; + my ($d) = Compress::Zlib::deflateInit( + -Level => Compress::Zlib::Z_BEST_COMPRESSION(), + -WindowBits => -Compress::Zlib::MAX_WBITS() + ) or return undef; + my ($o) = { + handle => $out, + dh => $d, + crc => 0, + len => 0, + }; + my ($header) = + pack("c10", MAGIC1, MAGIC2, Compress::Zlib::Z_DEFLATED(), 0, 0, 0, + 0, 0, 0, OSCODE); + print {$o->{handle}} $header; + return bless($o, $class); + } + + sub PRINT { + my ($o) = shift; + my ($buf) = join (defined $, ? $, : "", @_); + my ($len) = length($buf); + my ($compressed, $status) = $o->{dh}->deflate($buf); + print {$o->{handle}} $compressed if defined($compressed); + $o->{crc} = Compress::Zlib::crc32($buf, $o->{crc}); + $o->{len} += $len; + return $len; + } + + sub PRINTF { + my ($o) = shift; + my ($fmt) = shift; + my ($buf) = sprintf($fmt, @_); + my ($len) = length($buf); + my ($compressed, $status) = $o->{dh}->deflate($buf); + print {$o->{handle}} $compressed if defined($compressed); + $o->{crc} = Compress::Zlib::crc32($buf, $o->{crc}); + $o->{len} += $len; + return $len; + } + + sub WRITE { + my ($o, $buf, $len, $off) = @_; + my ($compressed, $status) = $o->{dh}->deflate(substr($buf, 0, $len)); + print {$o->{handle}} $compressed if defined($compressed); + $o->{crc} = Compress::Zlib::crc32(substr($buf, 0, $len), $o->{crc}); + $o->{len} += $len; + return $len; + } + + sub CLOSE { + my ($o) = @_; + return if !defined($o->{dh}); + my ($buf) = $o->{dh}->flush(); + $buf .= pack("V V", $o->{crc}, $o->{len}); + print {$o->{handle}} $buf; + undef $o->{dh}; + } + + sub DESTROY { + my ($o) = @_; + CLOSE($o); + } Index: llvm-www/cvsweb/cvsweb.conf diff -c /dev/null llvm-www/cvsweb/cvsweb.conf:1.1 *** /dev/null Mon Nov 7 21:08:26 2005 --- llvm-www/cvsweb/cvsweb.conf Mon Nov 7 21:08:15 2005 *************** *** 0 **** --- 1,516 ---- + # -*-perl-*- + # Configuration of cvsweb.cgi, the + # CGI interface to CVS Repositories. + # + # (c) 1998-1999 H. Zeller + # 1999 H. Nordstrom + # 2000-2002 A. MUSHA + # 2002 V. Skytt? + # based on work by Bill Fenner + # + # $FreeBSD: projects/cvsweb/cvsweb.conf,v 1.36.2.3 2002/09/23 05:30:17 scop Exp $ + # $Id: cvsweb.conf,v 1.1 2005/11/08 03:08:15 lattner Exp $ + # $Idaemons: /home/cvs/cvsweb/cvsweb.conf,v 1.27 2001/08/01 09:48:39 knu Exp $ + # + ### + + # Set the path for the following commands: + # uname, cvs, rlog, rcsdiff + # gzip (if you enable $allow_compress) + # tar, rm, zip (if you enable $allow_tar) + $command_path = '/usr/bin:/usr/dcs/software/supported/bin'; + + # Search the above directories for each command + for (qw(uname cvs rlog rcsdiff gzip tar rm zip)) { + $CMD{$_} = search_path($_); + } + + # The name of the operating system implementation + chomp($uname = `$CMD{uname}`); + + ############## + # CVS Root + ############## + # CVSweb can handle several CVS-Repositories + # at once. Enter a short symbolic names and the + # full path of these repositories here. + # NOTE that the symbolic names may not contain + # whitespaces. + # Note, that cvsweb.cgi currently needs to have physical access + # to the CVS repository so :pserver:someone at xyz.com:/data/cvsroot + # won't work! + + # 'symbolic_name' => ['name_to_display', 'path_to_the_actual_repository'] + # Listed in the order specified: + @CVSrepositories = ( + 'llvm' => ['LLVM', '/home/vadve/shared/PublicCVS'], + # 'freebsd' => ['FreeBSD', '/home/ncvs'], + # 'openbsd' => ['OpenBSD', '/home/ncvs'], + # 'netbsd' => ['NetBSD', '/home/ncvs'], + # 'ruby' => ['Ruby', '/var/anoncvs/ruby'], + ); + + # This tree is enabled by default when + # you enter the page + $cvstreedefault = $CVSrepositories[2 * 0]; # The first one + + ############## + # Bug tracking system options + # ("PR" means Problem Report, as in GNATS) + ############## + #@prcategories = qw( + # advocacy + # alpha + # bin + # conf + # docs + # gnu + # i386 + # kern + # misc + # pending + # ports + # sparc + #); + + # + #$prcgi = "http://www.FreeBSD.org/cgi/query-pr.cgi?pr=%s"; + # + #$prkeyword = "PR"; + + ############## + # Manual gateway + ############## + $mancgi = + "http://www.FreeBSD.org/cgi/man.cgi?apropos=0&sektion=%s&query=%s&manpath=FreeBSD+5.0-current&format=html"; + + ############## + # Defaults for UserSettings + ############## + %DEFAULTVALUE = ( + + # sortby: File sort order + # file Sort by filename + # rev Sort by revision number + # date Sort by commit date + # author Sort by author + # log Sort by log message + + "sortby" => "file", + + # hideattic: Hide or show files in Attic + # 1 Hide files in Attic + # 0 Show files in Attic + + "hideattic" => "1", + + # logsort: Sort order for CVS logs + # date Sort revisions by date + # rev Sort revision by revision number + # cvs Don't sort them. Same order as CVS/RCS shows them. + + "logsort" => "date", + + # f: Default diff format + # h Human readable + # u Unified diff + # c Context diff + # s Side by side + "f" => "u", + + # hidecvsroot: Don't show the CVSROOT directory + # 1 Hide CVSROOT directory + # 0 Show CVSROOT directory + "hidecvsroot" => "0", + + # hidenonreadable: Don't show entries which cannot be read + # 1 Hide non-readable entries + # 0 Show non-readable entries + "hidenonreadable" => "1", + ); + + ############## + # some layout stuff + ############## + + # The body-tag for directory views and logs + $body_tag = ''; + + # The body-tag for diffs and annotations + $body_tag_for_src = ''; + + # Wanna have a logo on the page ? + $logo = '

Powered by Apache

'; + + # The title of the Page on startup. This will be put inside a

tag. + $defaulttitle = "LLVM CVS Repository"; + + # The address is shown on the footer. This will be put inside a
tag. + $address = 'FreeBSD-CVSweb <freebsd-cvsweb at FreeBSD.org>'; + + # color of navigation Header for + # diffs and annotations + $navigationHeaderColor = '#9999ee'; + + $long_intro = < + This is a WWW interface for CVS Repositories. + You can browse the file hierarchy by picking directories + (which have slashes after them, e.g., src/). + If you pick a file, you will see the revision history + for that file. + Selecting a revision number will download that revision of + the file. There is a link at each revision to display + diffs between that revision and the previous one, and + a form at the bottom of the page that allows you to + display diffs between arbitrary revisions. +

+

+ This script has been written by Bill Fenner and improved by Henner Zeller, + Henrik Nordström, and Ken Coar, then Akinori MUSHA brought it + back to FreeBSD community and made further improvements; it is covered + by The BSD Licence. +

+

+ If you would like to use this CGI script on your own web server and + CVS tree, download the latest version from <URL:http://www.FreeBSD.org/projects/cvsweb.html>. +

+

+ Feel free to send any patches, suggestions and comments to the FreeBSD-CVSweb + mailing list at + <freebsd-cvsweb\@FreeBSD.org>. +

+ EOT + + $short_instruction = < + Click on a directory to enter that directory. Click on a file to display + its revision history and to get a chance to display diffs between revisions. +

+ EOT + + # used icons; if icon-url is empty, the text representation is used; if + # you do not want to have an ugly tooltip for the icon, remove the + # text-representation. + # The width and height of the icon allow the browser to correcly display + # the table while still loading the icons. + # These default icons are coming with apache. + # If these icons are too large, check out the miniicons in the + # icons/ directory; they have a width/height of 16/16 + my $iconsdir = "/cvsweb/icons"; + + # format: TEXT ICON-URL width height + %ICONS = ( + back => [("[BACK]", "$iconsdir/back.gif", 20, 22)], + dir => [("[DIR]", "$iconsdir/dir.gif", 20, 22)], + file => [("[TXT]", "$iconsdir/text.gif", 20, 22)], + ); + undef $iconsdir; + + # the length to which the last logentry should + # be truncated when shown in the directory view + $shortLogLen = 80; + + # Show author of last change + $show_author = 1; + + ############## + # table view for directories + ############## + + # Show directory as table + # this is much more readable but has one + # drawback: the whole table has to be loaded + # before common browsers display it which may + # be annoying if you have a slow link - and a + # large directory .. + $dirtable = 1; + + # show different colors for even/odd rows + @tabcolors = ('#ffffff', '#ffffff'); + $tablepadding = 2; + + # Color of Header + $columnHeaderColorDefault = '#ffffcc'; + $columnHeaderColorSorted = '#ffcc66'; + + # + # If you want to have colored borders + # around each row, uncomment this + $tableBorderColor = '#cccccc'; + + # + # Modules in the repository that should not be displayed, either by default + # nor by explicit path specification. + # + @HideModules = ( + # "^my/secret/module", + ); + + # + # Files matching these pathnames shouldn't be checked out with cvsweb, + # since they may contain sensitive information. Simple file name based + # filter. Often, the CVSROOT/passwd is exposed and some people tend + # to check in their .cvspass, though this is a bad idea. These files + # shouldn't be readable by default. Thanks to Damian Gryski to point + # this out. + # Note that this affects only files, not directories. + @ForbiddenFiles = ( + "^CVSROOT/passwd\$", # CVSROOT/passwd should not be cvs add'ed, though + "/\\.cvspass\$", # Ditto. Just in case. + ); + + # + # Use CVSROOT/CVSROOT/descriptions for describing the directories/modules + # See INSTALL section 8 + # + $use_descriptions = 0; + + ############## + # Human Readable Diff + ############## + + # (c) 1998 H. Zeller + # + # Generates two columns of color encoded + # diff; much like xdiff or emacs-ediff mode. + # + # The diff-stuff is a piece of code I once made for + # cvs2html which is under GPL, + # see http://www.sslug.dk/cvs2html + # (c) 1997/98 Peter Toft + # + # some parameters to screw: + ## + + # make lines breakable so that the columns do not + # exceed the width of the browser + $hr_breakable = 1; + + # give out function names in diffs + # this just makes sense if we have C-files, otherwise + # diff's heuristic doesn't work well .. + # ( '-p' option to diff) + $showfunc = 1; + + # For each pair of regexps, files that match the first regexp will be diff'ed + # with an '-F' option with the second regexp. + %funcline_regexp = ( + "\\.(4th|fr)\$" => "\\(^\\|[ \t]\\): ", + "\\.rb\$" => "^[\t ]*\\(class\\|module\\|def\\) ", + ); + + # ignore whitespaces for human readable diffs + # (indendation and stuff ..) + # ( '-w' option to diff) + $hr_ignwhite = 0; + + # ignore diffs which are caused by + # keyword-substitution like $Id - Stuff + # ( '-kk' option to rcsdiff) + $hr_ignkeysubst = 1; + + # Colors and font to show the diff type of code changes + $diffcolorHeading = '#99cccc'; # color of 'Line'-head of each diffed file + $diffcolorEmpty = '#cccccc'; # color of 'empty' lines + $diffcolorRemove = '#ff9999'; # Removed line(s) (left) ( - ) + $diffcolorChange = '#99ff99'; # Changed line(s) ( both ) + $diffcolorAdd = '#ccccff'; # Added line(s) ( - ) (right) + $diffcolorDarkChange = '#99cc99'; # lines, which are empty in change + $difffontface = "Helvetica,Arial"; + $difffontsize = "-1"; + + # the width of the textinput of the + # request-diff-form + $inputTextSize = 12; + + ############## + # Mime Types + ############## + + # mapping to mimetypes to help + # cvsweb to guess the correct mime-type on + # checkout; you can use the mime.types from + # apache here: + $mime_types = '/usr/dcs/www/conf/mime.types'; + + # quick mime-type lookup; maps file-suffices to + # mime-types for displaying checkouts in the browser. + # Further MimeTypes will be found in the + # file $mime_types (apache style mime.types - file) + # - add common mappings here for faster lookup + %MTYPES = ( + "html" => "text/html", + "shtml" => "text/html", + "gif" => "image/gif", + "jpeg" => "image/jpeg", + "jpg" => "image/jpeg", + "png" => "image/png", + "xpm" => "image/xpm", + "*" => "text/plain", + ); + + # Charset for HTML output + $charset = ''; + + # e.g. + #$charset = $where =~ m,/ru[/_-], ? 'koi8-r' + # : $where =~ m,/zh[/_-], ? 'big5' + # : $where =~ m,/ja[/_-], ? 'x-euc-jp' + # : $where =~ m,/ko[/_-], ? 'x-euc-kr' + # : 'iso-8859-1'; + + # Output filter + $output_filter = ''; + + # e.g. + ## unify/convert Japanese code into EUC-JP + #$output_filter= '/usr/local/bin/nkf -e'; + + ############## + # Misc + ############## + # allow annotation of files + # this requires rw-access to the + # CVSROOT/history file (if you have one) + # and rw-access to the subdirectory to + # place the lock so you maybe don't want it + $allow_annotate = 1; + + # allow pretty-printed version of files + $allow_markup = 1; + + # allow extra hlink formatting (such as PR xrefs) in logs + $allow_log_extra = 1; # default: enabled + + # allow extra hlink formatting (such as PR xrefs) in directories + $allow_dir_extra = 1; + + # allow extra hlink formatting in source code/formatted diff views + $allow_source_extra = 1; + + # allow compression with gzip + # of output if the Browser accepts + # it (HTTP_ACCEPT_ENCODING=gzip) + # [make sure to have gzip in the path] + $allow_compress = 0; + + # Make use of javascript functions. + # This way you can select one of your CVSroot + # without pressing 'Go' (.. if you do have more + # than one CVSROOT defined) + $use_java_script = 1; + + # open Download-Links in another window + $open_extern_window = 1; + + # The size of this extern window; this size option + # needs use_java_script to be defined + # just comment them if you don't want to have a fixed + # size + #$extern_window_width = 600; + #$extern_window_height = 440; + + # Edit Options + # Enable form to edit your options (hideattic,sortbydate) + # this isn't necessary if you've $dirtable defined 'cause + # this allows editing of all your options more intuitive + $edit_option_form = (not $dirtable); + + # If you have files which automatically refers to other files + # (such as HTML) then this allows you to browse the checked + # out files as if outside CVS. + $checkout_magic = 1; + + # Show last changelog message for sub directories + # The current implementation makes many assumptions and may show the + # incorrect file at some times. The main assumption is that the last + # modified file has the newest filedate. But some CVS operations + # touches the file without even when a new version is't checked in, + # and TAG based browsing essientially puts this out of order, unless + # the last checkin was on the same tag as you are viewing. + # Enable this if you like the feature, but don't rely on correct results. + $show_subdir_lastmod = 0; + + # Background color of logentry in markup + $markupLogColor = "#ffffff"; + + # Show CVS log when viewing file contents + $show_log_in_markup = 1; + + # Preformat when viewing file contents. This should be turned off + # when you have files in the repository that are in a multibyte + # encoding which uses HTML special characters ([<>&"]) as part of a + # multi-byte character. (such as iso-2022-jp, ShiftJIS, etc.) + # Otherwise those files will get screwed up in markup. + $preformat_in_markup = ''; + + # Tabstop used to expand tabs in colored diffs. If undefined then + # tabs are always expanded to 8 spaces. + $tabstop = 8; + + # if you wish to display absolute times in your local timezone, + # then define mytz and fill in the strings for your standard and + # daylight time. Note that you must also make sure the system + # timezone is correctly set. + # @mytz=("EST", "EDT"); + + # cvsweb is friendly to caches by indicating a suitable + # last-modified timestamp. Doing this uses slightly more + # CPU so you might want to disable it if you have a slow + # server + $use_moddate = 1; + + # Allows downloading a tarball of the current directory if set. + # Bear in mind that this allows downloading a tarball of your entire + # repository, which can take a lot of time and disk space to create! + # If you enable this, you may need to make sure that cvsweb can write to + # CVSROOT/val-tags, due to a bug in cvs. + $allow_tar = ''; + + # Options to pass to tar(1). + @tar_options = qw(); + + # e.g. @tar_options = qw(--ignore-failed-read); + # GNU tar has some useful options against unexpected errors. + + # Options to pass to gzip(1) when compressing a tarball to download. + @gzip_options = qw(); + + # e.g. @gzip_options = qw(-3); + # Try lower compression level than 6 (default) if you want faster + # compression, or higher, for better compression. + + # Options to pass to zip(1) when compressing a zip archive to download. + @zip_options = qw(); + + # e.g. @zip_options = qw(-3); + # Try lower compression level than 6 (default) if you want faster + # compression, or higher, for better compression. + + # Options to pass to cvs(1). + # For cvs versions prior to 1.11, the '-l' option doesn't work; If you want + # working checkouts with an older cvs version, you'll have to make sure that + # the cvsweb user can read and write to CVSROOT/history. + @cvs_options = qw(-lf); + + push @cvs_options, '-R' if ($uname eq 'FreeBSD' || $uname eq 'OpenBSD'); + push @cvs_options, '-u' if ($uname eq 'NetBSD'); + + # Only FreeBSD's and OpenBSD's cvs(1) supports -R (read only access + # mode) option, which considerably speeds up checkouts over NFS. + # A similar effect is provided by -u on NetBSD. + + # Options to pass to the 'cvs annotate' command, usually the normal + # @cvs_options are good enough here. + @annotate_options = @cvs_options; + + # To make annotate work against a read only repository, add -n, e.g.: + # @annotate_options = (@cvs_options, '-n'); + + 1; + + #EOF Index: llvm-www/cvsweb/index.html diff -c /dev/null llvm-www/cvsweb/index.html:1.1 *** /dev/null Mon Nov 7 21:08:26 2005 --- llvm-www/cvsweb/index.html Mon Nov 7 21:08:15 2005 *************** *** 0 **** --- 1,6 ---- + + + + + + From lattner at cs.uiuc.edu Tue Nov 8 00:48:16 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 00:48:16 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/index.html Message-ID: <200511080648.AAA16121@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb: index.html updated: 1.1 -> 1.2 --- Log message: forward to the right page --- Diffs of the changes: (+1 -1) index.html | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm-www/cvsweb/index.html diff -u llvm-www/cvsweb/index.html:1.1 llvm-www/cvsweb/index.html:1.2 --- llvm-www/cvsweb/index.html:1.1 Mon Nov 7 21:08:15 2005 +++ llvm-www/cvsweb/index.html Tue Nov 8 00:48:05 2005 @@ -1,6 +1,6 @@ - + From lattner at cs.uiuc.edu Tue Nov 8 00:58:52 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 00:58:52 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/cvsweb.cgi Message-ID: <200511080658.AAA16335@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb: cvsweb.cgi updated: 1.1 -> 1.2 --- Log message: get this actually working with our version of perl and apache --- Diffs of the changes: (+13 -13) cvsweb.cgi | 26 +++++++++++++------------- 1 files changed, 13 insertions(+), 13 deletions(-) Index: llvm-www/cvsweb/cvsweb.cgi diff -u llvm-www/cvsweb/cvsweb.cgi:1.1 llvm-www/cvsweb/cvsweb.cgi:1.2 --- llvm-www/cvsweb/cvsweb.cgi:1.1 Mon Nov 7 21:08:15 2005 +++ llvm-www/cvsweb/cvsweb.cgi Tue Nov 8 00:58:41 2005 @@ -1,4 +1,4 @@ -#!/usr/dcs/software/supported/bin/perl -wT +#!/usr/dcs/software/supported/bin/perl -w # # cvsweb - a CGI interface to CVS trees. # @@ -46,7 +46,7 @@ # SUCH DAMAGE. # # $FreeBSD: projects/cvsweb/cvsweb.cgi,v 1.119.2.6 2002/09/26 20:56:05 scop Exp $ -# $Id: cvsweb.cgi,v 1.1 2005/11/08 03:08:15 lattner Exp $ +# $Id: cvsweb.cgi,v 1.2 2005/11/08 06:58:41 lattner Exp $ # $Idaemons: /home/cvs/cvsweb/cvsweb.cgi,v 1.84 2001/10/07 20:50:10 knu Exp $ # ### @@ -2596,8 +2596,8 @@ if (defined($revsym{$br}) && $revsym{$br} && !defined($nameprinted{$br})) { - foreach my $sym (split (", ", $revsym{$br})) { - print ""; + foreach my $symx (split (", ", $revsym{$br})) { + print ""; } $nameprinted{$br} = 1; } @@ -2725,13 +2725,13 @@ if ($revsym{$brp} && !/^1\.1\.1\.\d+$/ && !defined($diffrev{$brp})) { - my $url = + my $urlx = sprintf('%s.diff?r1=%s&r2=%s%s', $scriptwhere, $brp, $_, $barequery); print $diff, " to branchpoint "; $diff = ''; - printDiffLinks($brp, $url); + printDiffLinks($brp, $urlx); } # @@ -2767,14 +2767,14 @@ if (!defined($diffrev{$nextmain})) { $diffrev{$nextmain} = 1; - my $url = + my $urly = sprintf('%s.diff?r1=%s&r2=%s%s', $scriptwhere, $nextmain, $_, $barequery); print $diff, " next main "; $diff = ''; - printDiffLinks($nextmain, $url); + printDiffLinks($nextmain, $urly); } } @@ -2783,13 +2783,13 @@ if (defined($input{"r1"}) && !defined($diffrev{$input{"r1"}})) { $diffrev{$input{"r1"}} = 1; - my $url = + my $urlz = sprintf('%s.diff?r1=%s&r2=%s%s', $scriptwhere, $input{'r1'}, $_, $barequery); print $diff, " to selected "; $diff = ''; - printDiffLinks($input{'r1'}, $url); + printDiffLinks($input{'r1'}, $urlz); } } @@ -3497,13 +3497,13 @@ # Build a new query of non-default paramenters $newquery = ""; foreach $var (@stickyvars) { - my ($value) = defined($vars{$var}) ? $vars{$var} : ""; + my ($valuex) = defined($vars{$var}) ? $vars{$var} : ""; my ($default) = defined($DEFAULTVALUE{$var}) ? $DEFAULTVALUE{$var} : ""; - if ($value ne $default) { + if ($valuex ne $default) { $newquery .= "&" if ($newquery ne ""); - $newquery .= urlencode($var) . "=" . urlencode($value); + $newquery .= urlencode($var) . "=" . urlencode($valuex); } } From lattner at cs.uiuc.edu Tue Nov 8 01:09:42 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 01:09:42 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/cvsweb.conf Message-ID: <200511080709.BAA16540@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb: cvsweb.conf updated: 1.1 -> 1.2 --- Log message: customize this, make it work better on our machine --- Diffs of the changes: (+12 -33) cvsweb.conf | 45 ++++++++++++--------------------------------- 1 files changed, 12 insertions(+), 33 deletions(-) Index: llvm-www/cvsweb/cvsweb.conf diff -u llvm-www/cvsweb/cvsweb.conf:1.1 llvm-www/cvsweb/cvsweb.conf:1.2 --- llvm-www/cvsweb/cvsweb.conf:1.1 Mon Nov 7 21:08:15 2005 +++ llvm-www/cvsweb/cvsweb.conf Tue Nov 8 01:09:31 2005 @@ -9,7 +9,7 @@ # based on work by Bill Fenner # # $FreeBSD: projects/cvsweb/cvsweb.conf,v 1.36.2.3 2002/09/23 05:30:17 scop Exp $ -# $Id: cvsweb.conf,v 1.1 2005/11/08 03:08:15 lattner Exp $ +# $Id: cvsweb.conf,v 1.2 2005/11/08 07:09:31 lattner Exp $ # $Idaemons: /home/cvs/cvsweb/cvsweb.conf,v 1.27 2001/08/01 09:48:39 knu Exp $ # ### @@ -18,7 +18,7 @@ # uname, cvs, rlog, rcsdiff # gzip (if you enable $allow_compress) # tar, rm, zip (if you enable $allow_tar) -$command_path = '/usr/bin:/usr/dcs/software/supported/bin'; +$command_path = '/usr/bin:/bin:/usr/dcs/software/supported/bin'; # Search the above directories for each command for (qw(uname cvs rlog rcsdiff gzip tar rm zip)) { @@ -121,7 +121,7 @@ # hidecvsroot: Don't show the CVSROOT directory # 1 Hide CVSROOT directory # 0 Show CVSROOT directory - "hidecvsroot" => "0", + "hidecvsroot" => "1", # hidenonreadable: Don't show entries which cannot be read # 1 Hide non-readable entries @@ -140,13 +140,13 @@ $body_tag_for_src = ''; # Wanna have a logo on the page ? -$logo = '

Powered by Apache

'; +$logo = ''; #

LLVM Web Page

'; # The title of the Page on startup. This will be put inside a

tag. $defaulttitle = "LLVM CVS Repository"; # The address is shown on the footer. This will be put inside a
tag. -$address = 'FreeBSD-CVSweb <freebsd-cvsweb at FreeBSD.org>'; +$address = 'LLVM CVSweb <llvmdev at cs.uiuc.edu>'; # color of navigation Header for # diffs and annotations @@ -154,34 +154,13 @@ $long_intro = < -This is a WWW interface for CVS Repositories. -You can browse the file hierarchy by picking directories -(which have slashes after them, e.g., src/). -If you pick a file, you will see the revision history -for that file. -Selecting a revision number will download that revision of -the file. There is a link at each revision to display -diffs between that revision and the previous one, and -a form at the bottom of the page that allows you to -display diffs between arbitrary revisions. +This is the LLVM CVS WWW interface. "llvm" is the main LLVM distribution, +"llvm-gcc" is the C/C++ front-end, "llvm-test" is the LLVM coverage test suite, +and the rest are various projects built around LLVM.

-This script has been written by Bill Fenner and improved by Henner Zeller, -Henrik Nordström, and Ken Coar, then Akinori MUSHA brought it -back to FreeBSD community and made further improvements; it is covered -by The BSD Licence. -

-

-If you would like to use this CGI script on your own web server and -CVS tree, download the latest version from <URL:http://www.FreeBSD.org/projects/cvsweb.html>. -

-

-Feel free to send any patches, suggestions and comments to the FreeBSD-CVSweb -mailing list at -<freebsd-cvsweb\@FreeBSD.org>. +This script is powered by +FreeBSD-CVSweb.

EOT @@ -212,7 +191,7 @@ # the length to which the last logentry should # be truncated when shown in the directory view -$shortLogLen = 80; +$shortLogLen = 100; # Show author of last change $show_author = 1; @@ -495,7 +474,7 @@ # For cvs versions prior to 1.11, the '-l' option doesn't work; If you want # working checkouts with an older cvs version, you'll have to make sure that # the cvsweb user can read and write to CVSROOT/history. - at cvs_options = qw(-lf); + at cvs_options = qw(-f); push @cvs_options, '-R' if ($uname eq 'FreeBSD' || $uname eq 'OpenBSD'); push @cvs_options, '-u' if ($uname eq 'NetBSD'); From lattner at cs.uiuc.edu Tue Nov 8 01:32:12 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 01:32:12 -0600 Subject: [llvm-commits] CVS: llvm-www/cvsweb/cvsweb.conf Message-ID: <200511080732.BAA16861@zion.cs.uiuc.edu> Changes in directory llvm-www/cvsweb: cvsweb.conf updated: 1.2 -> 1.3 --- Log message: unfortunately annotate requires R/W access to the repo (!?!), disable it as cvsweb (rightfully) runs as nobody. --- Diffs of the changes: (+2 -2) cvsweb.conf | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm-www/cvsweb/cvsweb.conf diff -u llvm-www/cvsweb/cvsweb.conf:1.2 llvm-www/cvsweb/cvsweb.conf:1.3 --- llvm-www/cvsweb/cvsweb.conf:1.2 Tue Nov 8 01:09:31 2005 +++ llvm-www/cvsweb/cvsweb.conf Tue Nov 8 01:32:01 2005 @@ -9,7 +9,7 @@ # based on work by Bill Fenner # # $FreeBSD: projects/cvsweb/cvsweb.conf,v 1.36.2.3 2002/09/23 05:30:17 scop Exp $ -# $Id: cvsweb.conf,v 1.2 2005/11/08 07:09:31 lattner Exp $ +# $Id: cvsweb.conf,v 1.3 2005/11/08 07:32:01 lattner Exp $ # $Idaemons: /home/cvs/cvsweb/cvsweb.conf,v 1.27 2001/08/01 09:48:39 knu Exp $ # ### @@ -357,7 +357,7 @@ # CVSROOT/history file (if you have one) # and rw-access to the subdirectory to # place the lock so you maybe don't want it -$allow_annotate = 1; +$allow_annotate = 0; # allow pretty-printed version of files $allow_markup = 1; From criswell at cs.uiuc.edu Tue Nov 8 09:38:36 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 09:38:36 -0600 Subject: [llvm-commits] [release_16] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200511081538.JAA01818@choi.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.340 -> 1.340.2.1 --- Log message: Add a note about the Solaris configure problem that Tanya's seen. --- Diffs of the changes: (+14 -1) ReleaseNotes.html | 15 ++++++++++++++- 1 files changed, 14 insertions(+), 1 deletion(-) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.340 llvm/docs/ReleaseNotes.html:1.340.2.1 --- llvm/docs/ReleaseNotes.html:1.340 Mon Oct 31 13:07:29 2005 +++ llvm/docs/ReleaseNotes.html Tue Nov 8 09:38:11 2005 @@ -318,6 +318,19 @@ + + + + + + @@ -715,7 +728,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
- Last modified: $Date: 2005/10/31 19:07:29 $ + Last modified: $Date: 2005/11/08 15:38:11 $
From criswell at cs.uiuc.edu Tue Nov 8 09:40:37 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 09:40:37 -0600 Subject: [llvm-commits] [release_16] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200511081540.JAA01854@choi.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.340.2.1 -> 1.340.2.2 --- Log message: Note that a work-around is available. --- Diffs of the changes: (+2 -2) ReleaseNotes.html | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.340.2.1 llvm/docs/ReleaseNotes.html:1.340.2.2 --- llvm/docs/ReleaseNotes.html:1.340.2.1 Tue Nov 8 09:38:11 2005 +++ llvm/docs/ReleaseNotes.html Tue Nov 8 09:40:22 2005 @@ -324,7 +324,7 @@ @@ -728,7 +728,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
- Last modified: $Date: 2005/11/08 15:38:11 $ + Last modified: $Date: 2005/11/08 15:40:22 $

From criswell at cs.uiuc.edu Tue Nov 8 09:47:41 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 09:47:41 -0600 Subject: [llvm-commits] [release_16] CVS: llvm-test/configure Message-ID: <200511081547.JAA02177@choi.cs.uiuc.edu> Changes in directory llvm-test: configure updated: 1.28 -> 1.28.2.1 --- Log message: Updated the version number. --- Diffs of the changes: (+9 -9) configure | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) Index: llvm-test/configure diff -u llvm-test/configure:1.28 llvm-test/configure:1.28.2.1 --- llvm-test/configure:1.28 Mon Aug 8 16:26:07 2005 +++ llvm-test/configure Tue Nov 8 09:47:25 2005 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.59 for LLVM-TEST 1.6cvs. +# Generated by GNU Autoconf 2.59 for LLVM-TEST 1.6. # # Report bugs to . # @@ -423,8 +423,8 @@ # Identity of this package. PACKAGE_NAME='LLVM-TEST' PACKAGE_TARNAME='-llvm-test-' -PACKAGE_VERSION='1.6cvs' -PACKAGE_STRING='LLVM-TEST 1.6cvs' +PACKAGE_VERSION='1.6' +PACKAGE_STRING='LLVM-TEST 1.6' PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="SingleSource/Benchmarks/Makefile" @@ -954,7 +954,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures LLVM-TEST 1.6cvs to adapt to many kinds of systems. +\`configure' configures LLVM-TEST 1.6 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1015,7 +1015,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of LLVM-TEST 1.6cvs:";; + short | recursive ) echo "Configuration of LLVM-TEST 1.6:";; esac cat <<\_ACEOF @@ -1173,7 +1173,7 @@ test -n "$ac_init_help" && exit 0 if $ac_init_version; then cat <<\_ACEOF -LLVM-TEST configure 1.6cvs +LLVM-TEST configure 1.6 generated by GNU Autoconf 2.59 Copyright (C) 2003 Free Software Foundation, Inc. @@ -1187,7 +1187,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by LLVM-TEST $as_me 1.6cvs, which was +It was created by LLVM-TEST $as_me 1.6, which was generated by GNU Autoconf 2.59. Invocation command line was $ $0 $@ @@ -20438,7 +20438,7 @@ } >&5 cat >&5 <<_CSEOF -This file was extended by LLVM-TEST $as_me 1.6cvs, which was +This file was extended by LLVM-TEST $as_me 1.6, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -20496,7 +20496,7 @@ cat >>$CONFIG_STATUS <<_ACEOF ac_cs_version="\\ -LLVM-TEST config.status 1.6cvs +LLVM-TEST config.status 1.6 configured by $0, generated by GNU Autoconf 2.59, with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\" From criswell at cs.uiuc.edu Tue Nov 8 09:47:42 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 09:47:42 -0600 Subject: [llvm-commits] [release_16] CVS: llvm-test/autoconf/configure.ac Message-ID: <200511081547.JAA02181@choi.cs.uiuc.edu> Changes in directory llvm-test/autoconf: configure.ac updated: 1.27 -> 1.27.2.1 --- Log message: Updated the version number. --- Diffs of the changes: (+1 -1) configure.ac | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm-test/autoconf/configure.ac diff -u llvm-test/autoconf/configure.ac:1.27 llvm-test/autoconf/configure.ac:1.27.2.1 --- llvm-test/autoconf/configure.ac:1.27 Mon Aug 8 16:26:12 2005 +++ llvm-test/autoconf/configure.ac Tue Nov 8 09:47:27 2005 @@ -1,5 +1,5 @@ dnl Initialize autoconf -AC_INIT([[LLVM-TEST]],[[1.6cvs]],[llvmbugs at cs.uiuc.edu]) +AC_INIT([[LLVM-TEST]],[[1.6]],[llvmbugs at cs.uiuc.edu]) dnl Place all of the extra autoconf files into the config subdirectory AC_CONFIG_AUX_DIR([autoconf]) From criswell at cs.uiuc.edu Tue Nov 8 09:55:50 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 09:55:50 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/llvm-1.6.tar.gz llvm-test-1.6.tar.gz Message-ID: <200511081555.JAA02251@choi.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6: llvm-1.6.tar.gz added (r1.1) llvm-test-1.6.tar.gz added (r1.1) --- Log message: Welcome to the world, LLVM 1.6. --- Diffs of the changes: (+0 -0) llvm-1.6.tar.gz | 0 llvm-test-1.6.tar.gz | 0 2 files changed Index: llvm-www/releases/1.6/llvm-1.6.tar.gz Index: llvm-www/releases/1.6/llvm-test-1.6.tar.gz From lattner at cs.uiuc.edu Tue Nov 8 12:52:39 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 12:52:39 -0600 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp Message-ID: <200511081852.MAA27968@zion.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen/SelectionDAG: SelectionDAG.cpp updated: 1.207 -> 1.208 --- Log message: Clean up RemoveDeadNodes significantly, by eliminating the need for a temporary set and eliminating the need to iterate whenever something is removed (which can be really slow in some cases). Thx to Jim for pointing out something silly I was getting stuck on. :) --- Diffs of the changes: (+34 -32) SelectionDAG.cpp | 66 ++++++++++++++++++++++++++++--------------------------- 1 files changed, 34 insertions(+), 32 deletions(-) Index: llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp diff -u llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1.207 llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1.208 --- llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:1.207 Sat Oct 22 22:38:30 2005 +++ llvm/lib/CodeGen/SelectionDAG/SelectionDAG.cpp Tue Nov 8 12:52:27 2005 @@ -167,41 +167,47 @@ /// chain but no other uses and no side effect. If a node is passed in as an /// argument, it is used as the seed for node deletion. void SelectionDAG::RemoveDeadNodes(SDNode *N) { - std::set AllNodeSet(AllNodes.begin(), AllNodes.end()); - // Create a dummy node (which is not added to allnodes), that adds a reference // to the root node, preventing it from being deleted. HandleSDNode Dummy(getRoot()); + bool MadeChange = false; + // If we have a hint to start from, use it. - if (N) DeleteNodeIfDead(N, &AllNodeSet); + if (N && N->use_empty()) { + DestroyDeadNode(N); + MadeChange = true; + } - Restart: - unsigned NumNodes = AllNodeSet.size(); - for (std::set::iterator I = AllNodeSet.begin(), E = AllNodeSet.end(); - I != E; ++I) { + for (unsigned i = 0, e = AllNodes.size(); i != e; ++i) { // Try to delete this node. - DeleteNodeIfDead(*I, &AllNodeSet); - - // If we actually deleted any nodes, do not use invalid iterators in - // AllNodeSet. - if (AllNodeSet.size() != NumNodes) - goto Restart; + SDNode *N = AllNodes[i]; + if (N->use_empty() && N->getOpcode() != 65535) { + DestroyDeadNode(N); + MadeChange = true; + } } - - // Restore AllNodes. - if (AllNodes.size() != NumNodes) - AllNodes.assign(AllNodeSet.begin(), AllNodeSet.end()); - + + // Walk the nodes list, removing the nodes we've marked as dead. + if (MadeChange) { + for (unsigned i = 0, e = AllNodes.size(); i != e; ++i) + if (AllNodes[i]->use_empty()) { + delete AllNodes[i]; + AllNodes[i] = AllNodes.back(); + AllNodes.pop_back(); + --i; --e; + } + } + // If the root changed (e.g. it was a dead load, update the root). setRoot(Dummy.getValue()); } - -void SelectionDAG::DeleteNodeIfDead(SDNode *N, void *NodeSet) { - if (!N->use_empty()) - return; - +/// DestroyDeadNode - We know that N is dead. Nuke it from the CSE maps for the +/// graph. If it is the last user of any of its operands, recursively process +/// them the same way. +/// +void SelectionDAG::DestroyDeadNode(SDNode *N) { // Okay, we really are going to delete this node. First take this out of the // appropriate CSE map. RemoveNodeFromCSEMaps(N); @@ -214,16 +220,12 @@ O->removeUser(N); // Now that we removed this operand, see if there are no uses of it left. - DeleteNodeIfDead(O, NodeSet); + if (O->use_empty()) + DestroyDeadNode(O); } - - // Remove the node from the nodes set and delete it. - std::set &AllNodeSet = *(std::set*)NodeSet; - AllNodeSet.erase(N); - - // Now that the node is gone, check to see if any of the operands of this node - // are dead now. - delete N; + + // Mark the node as dead. + N->MorphNodeTo(65535); } void SelectionDAG::DeleteNode(SDNode *N) { From lattner at cs.uiuc.edu Tue Nov 8 12:53:09 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 12:53:09 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/CodeGen/SelectionDAG.h Message-ID: <200511081853.MAA28027@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm/CodeGen: SelectionDAG.h updated: 1.65 -> 1.66 --- Log message: adjust itf --- Diffs of the changes: (+1 -1) SelectionDAG.h | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm/include/llvm/CodeGen/SelectionDAG.h diff -u llvm/include/llvm/CodeGen/SelectionDAG.h:1.65 llvm/include/llvm/CodeGen/SelectionDAG.h:1.66 --- llvm/include/llvm/CodeGen/SelectionDAG.h:1.65 Tue Oct 25 16:02:21 2005 +++ llvm/include/llvm/CodeGen/SelectionDAG.h Tue Nov 8 12:52:57 2005 @@ -354,7 +354,7 @@ private: void RemoveNodeFromCSEMaps(SDNode *N); SDNode *AddNonLeafNodeToCSEMaps(SDNode *N); - void DeleteNodeIfDead(SDNode *N, void *NodeSet); + void DestroyDeadNode(SDNode *N); void DeleteNodeNotInCSEMaps(SDNode *N); /// SimplifySetCC - Try to simplify a setcc built with the specified operands From lattner at cs.uiuc.edu Tue Nov 8 14:05:52 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:05:52 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/ Message-ID: <200511082005.OAA30123@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:05:56 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:05:56 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/ Message-ID: <200511082005.OAA30127@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs/CommandGuide added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:05:58 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:05:58 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/HistoricalNotes/ Message-ID: <200511082005.OAA30131@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/HistoricalNotes: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs/HistoricalNotes added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:05:58 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:05:58 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/img/ Message-ID: <200511082005.OAA30135@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/img: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs/img added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:06:21 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:06:21 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/html/ Message-ID: <200511082006.OAA30199@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/html: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs/CommandGuide/html added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:06:23 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:06:23 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/man/ Message-ID: <200511082006.OAA30203@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/man: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs/CommandGuide/man added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:06:23 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:06:23 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/ps/ Message-ID: <200511082006.OAA30207@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/ps: --- Log message: Directory /home/vadve/shared/PublicCVS/llvm-www/releases/1.6/docs/CommandGuide/ps added to the repository --- Diffs of the changes: (+0 -0) 0 files changed From lattner at cs.uiuc.edu Tue Nov 8 14:06:47 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:06:47 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/AliasAnalysis.html Bugpoint.html BytecodeFormat.html CFEBuildInstrs.html CodeGenerator.html CodingStandards.html CommandLine.html CompilerDriver.html CompilerWriterInfo.html ExtendingLLVM.html FAQ.html GarbageCollection.html GettingStarted.html GettingStartedVS.html HowToSubmitABug.html LLVMVsTheWorld.html LangRef.html Lexicon.html Makefile MakefileGuide.html ProgrammersManual.html Projects.html ReleaseNotes.html SourceLevelDebugging.html Stacker.html SystemLibrary.html TableGenFundamentals.html TestingGuide.html UsingLibraries.html WritingAnLLVMBackend.html WritingAnLLVMPass.html doxygen.cfg doxygen.cfg.in doxygen.css doxygen.footer doxygen.header doxygen.intro index.html llvm.css Message-ID: <200511082006.OAA30330@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs: AliasAnalysis.html added (r1.1) Bugpoint.html added (r1.1) BytecodeFormat.html added (r1.1) CFEBuildInstrs.html added (r1.1) CodeGenerator.html added (r1.1) CodingStandards.html added (r1.1) CommandLine.html added (r1.1) CompilerDriver.html added (r1.1) CompilerWriterInfo.html added (r1.1) ExtendingLLVM.html added (r1.1) FAQ.html added (r1.1) GarbageCollection.html added (r1.1) GettingStarted.html added (r1.1) GettingStartedVS.html added (r1.1) HowToSubmitABug.html added (r1.1) LLVMVsTheWorld.html added (r1.1) LangRef.html added (r1.1) Lexicon.html added (r1.1) Makefile added (r1.1) MakefileGuide.html added (r1.1) ProgrammersManual.html added (r1.1) Projects.html added (r1.1) ReleaseNotes.html added (r1.1) SourceLevelDebugging.html added (r1.1) Stacker.html added (r1.1) SystemLibrary.html added (r1.1) TableGenFundamentals.html added (r1.1) TestingGuide.html added (r1.1) UsingLibraries.html added (r1.1) WritingAnLLVMBackend.html added (r1.1) WritingAnLLVMPass.html added (r1.1) doxygen.cfg added (r1.1) doxygen.cfg.in 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) --- Log message: Check in the 1.6 docs --- Diffs of the changes: (+29050 -0) AliasAnalysis.html | 953 ++++++++++++ Bugpoint.html | 238 +++ BytecodeFormat.html | 2052 +++++++++++++++++++++++++++ CFEBuildInstrs.html | 364 ++++ CodeGenerator.html | 1304 +++++++++++++++++ CodingStandards.html | 646 ++++++++ CommandLine.html | 1907 +++++++++++++++++++++++++ CompilerDriver.html | 823 +++++++++++ CompilerWriterInfo.html | 260 +++ ExtendingLLVM.html | 329 ++++ FAQ.html | 581 +++++++ GarbageCollection.html | 533 +++++++ GettingStarted.html | 1546 ++++++++++++++++++++ GettingStartedVS.html | 353 ++++ HowToSubmitABug.html | 356 ++++ LLVMVsTheWorld.html | 180 ++ LangRef.html | 3393 ++++++++++++++++++++++++++++++++++++++++++++++ Lexicon.html | 172 ++ Makefile | 73 MakefileGuide.html | 1006 +++++++++++++ ProgrammersManual.html | 2284 ++++++++++++++++++++++++++++++ Projects.html | 460 ++++++ ReleaseNotes.html | 722 +++++++++ SourceLevelDebugging.html | 1117 +++++++++++++++ Stacker.html | 1412 +++++++++++++++++++ SystemLibrary.html | 344 ++++ TableGenFundamentals.html | 567 +++++++ TestingGuide.html | 528 +++++++ UsingLibraries.html | 504 ++++++ WritingAnLLVMBackend.html | 259 +++ WritingAnLLVMPass.html | 1600 +++++++++++++++++++++ doxygen.cfg | 863 +++++++++++ doxygen.cfg.in | 863 +++++++++++ doxygen.css | 90 + doxygen.footer | 10 doxygen.header | 9 doxygen.intro | 18 index.html | 247 +++ llvm.css | 84 + 39 files changed, 29050 insertions(+) Index: llvm-www/releases/1.6/docs/AliasAnalysis.html diff -c /dev/null llvm-www/releases/1.6/docs/AliasAnalysis.html:1.1 *** /dev/null Tue Nov 8 14:06:45 2005 --- llvm-www/releases/1.6/docs/AliasAnalysis.html Tue Nov 8 14:06:32 2005 *************** *** 0 **** --- 1,953 ---- + + + + LLVM Alias Analysis Infrastructure + + + + +
+ LLVM Alias Analysis Infrastructure +
+ +
    +
  1. Introduction
  2. + +
  3. AliasAnalysis Class Overview + +
  4. + +
  5. Writing a new AliasAnalysis Implementation + +
  6. + +
  7. Using alias analysis results + +
  8. + +
  9. Existing alias analysis implementations and clients + +
  10. +
+ +
+

Written by Chris Lattner

+
+ + + + + +
+ +

Alias Analysis (aka Pointer Analysis) is a class of techniques which attempt + to determine whether or not two pointers ever can point to the same object in + memory. There are many different algorithms for alias analysis and many + different ways of classifying them: flow-sensitive vs flow-insensitive, + context-sensitive vs context-insensitive, field-sensitive vs field-insensitive, + unification-based vs subset-based, etc. Traditionally, alias analyses respond + to a query with a Must, May, or No alias response, + indicating that two pointers always point to the same object, might point to the + same object, or are known to never point to the same object.

+ +

The LLVM AliasAnalysis + class is the primary interface used by clients and implementations of alias + analyses in the LLVM system. This class is the common interface between clients + of alias analysis information and the implementations providing it, and is + designed to support a wide range of implementations and clients (but currently + all clients are assumed to be flow-insensitive). In addition to simple alias + analysis information, this class exposes Mod/Ref information from those + implementations which can provide it, allowing for powerful analyses and + transformations to work well together.

+ +

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.

+ +
+ + + + + +
+ +

The AliasAnalysis + class defines the interface that the various 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.

+ +
+ + + + +
+ +

Most importantly, the AliasAnalysis class provides several methods + which are used to query whether or not two memory objects alias, whether + function calls can modify or read a memory object, etc. For all of these + queries, memory objects are represented as a pair of their starting address (a + symbolic LLVM Value*) and a static size.

+ +

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

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

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

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 can never equal each other, return NoAlias, if they might, + return MayAlias.

+ +

The MustAlias 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, return MayAlias.

+ +
+ + + + +
+ +

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 instruction might read or write + a location, ModRef is returned.

+ +

The AliasAnalysis class also provides a getModRefInfo + method for testing dependencies between function calls. This method takes two + call sites (CS1 & CS2), returns NoModRef if the two calls refer to disjoint + memory locations, Ref if CS1 reads memory written by CS2, Mod if CS1 writes to + memory read or written by CS2, or ModRef if CS1 might read or write memory + accessed by CS2. Note that this relation is not commutative. Clients that use + this method should be predicated on the hasNoModRefInfoForCalls() + method, which indicates whether or not an analysis can provide mod/ref + information for function call pairs (most can not). If this predicate is false, + the client shouldn't waste analysis time querying the getModRefInfo + method many times.

+ +
+ + + + + +
+ +

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

+ +
+ + +
+ The getMustAliases method +
+ +
+ +

The getMustAliases method returns all values that are known to + always must alias a pointer. This information can be provided in some cases for + important objects like the null pointer and global values. Knowing that a + pointer always points to a particular function allows indirect calls to be + turned into direct calls, for example.

+ +
+ + +
+ The pointsToConstantMemory method +
+ +
+ +

The pointsToConstantMemory method returns true if and only if the + analysis can prove that the pointer only points to unchanging memory locations + (functions, constant global variables, and the null pointer). This information + can be used to refine mod/ref information: it is impossible for an unchanging + memory location to be modified.

+ +
+ + + + +
+ +

These methods are used to provide very simple mod/ref information for + function calls. The doesNotAccessMemory method returns true for a + function if the analysis can prove that the function never reads or writes to + memory, or if the function only reads from constant memory. Functions with this + property are side-effect free and only depend on their input arguments, allowing + them to be eliminated if they form common subexpressions or be hoisted out of + loops. Many common functions behave this way (e.g., sin and + cos) but many others do not (e.g., acos, which modifies the + errno variable).

+ +

The onlyReadsMemory method returns true for a function if analysis + can prove that (at most) the function only reads from non-volatile memory. + Functions with this property are side-effect free, only depending on their input + arguments and the state of memory when they are called. This property allows + calls to these functions to be eliminated and moved around, as long as there is + no store instruction that changes the contents of memory. Note that all + functions that satisfy the doesNotAccessMemory method also satisfies + onlyReadsMemory.

+ +
+ + + + + +
+ +

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

+ +
+ + + + +
+ +

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. +
  3. If you are a function-local analysis, subclass FunctionPass.
  4. +
  5. If you don't need to look at the program at all, subclass + ImmutablePass.
  6. +
+ +

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.

+ +
+ + + + +
+ +

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, or InitializePass + for an ImmutablePass). For example (as part of a Pass):

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

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

+ +
+ + + + + + +
+ +

With only two special exceptions (the basicaa and no-aa + passes) every alias analysis pass chains to another alias analysis + implementation (for example, the user can specify "-basicaa -ds-aa + -anders-aa -licm" to get the maximum benefit from the three alias + analyses). The alias analysis class automatically takes care of most of this + for methods that you don't override. For methods that you do override, in code + paths that return a conservative MayAlias or Mod/Ref result, simply return + whatever the superclass computes. For example:

+ +
+
+ AliasAnalysis::AliasResult alias(const Value *V1, unsigned V1Size,
+                                  const Value *V2, unsigned V2Size) {
+   if (...)
+     return NoAlias;
+   ...
+ 
+   // Couldn't determine a must or no-alias result.
+   return AliasAnalysis::alias(V1, V1Size, V2, V2Size);
+ }
+ 
+
+ +

In addition to analysis queries, you must make sure to unconditionally pass + LLVM update notification methods to the superclass as + well if you override them, which allows all alias analyses in a change to be + updated.

+ +
+ + + + + +
+

+ Alias analysis information is initially computed for a static snapshot of the + program, but clients will use this information to make transformations to the + code. All but the most trivial forms of alias analysis will need to have their + analysis results updated to reflect the changes made by these transformations. +

+ +

+ The AliasAnalysis interface exposes two methods which are used to + communicate program changes from the clients to the analysis implementations. + Various alias analysis implementations should use these methods to ensure that + their internal data structures are kept up-to-date as the program changes (for + example, when an instruction is deleted), and clients of alias analysis must be + sure to call these interfaces appropriately. +

+
+ + +
The deleteValue method
+ +
+ The deleteValue method is called by transformations when they remove an + instruction or any other value from the program (including values that do not + use pointers). Typically alias analyses keep data structures that have entries + for each value in the program. When this method is called, they should remove + any entries for the specified value, if they exist. +
+ + +
The copyValue method
+ +
+ The copyValue method is used when a new value is introduced into the + program. There is no way to introduce a value into the program that did not + exist before (this doesn't make sense for a safe compiler transformation), so + this is the only way to introduce a new value. This method indicates that the + new value has exactly the same properties as the value being copied. +
+ + +
The replaceWithNewValue method
+ +
+ This method is a simple helper method that is provided to make clients easier to + use. It is implemented by copying the old analysis information to the new + value, then deleting the old value. This method cannot be overridden by alias + analysis implementations. +
+ + + + +
+ +

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).

+ +
+ + + + + +
+ +

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

+ +
+ + + + +
+ +

The load-vn pass uses alias analysis to provide value numbering + information for load instructions and pointer values. If your analysis + or transformation can be modeled 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.

+ +
+ + + + +
+ +

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 using 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 calculate alias + sets for 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 to 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 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.

+ +
+ + + + +
+ +

If neither of these utility class are what your pass needs, you should use + the interfaces exposed by the AliasAnalysis class directly. Try to use + the higher-level methods when possible (e.g., use mod/ref information instead of + the alias method directly if possible) to get the + best precision and efficiency.

+ +
+ + + + + +
+ +

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

+ +
+ + + + +
+ +

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

+ +
+ + + + +
+ +

The -no-aa pass 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.

+ +
+ + + + +
+ +

The -basicaa pass is the default LLVM alias analysis. It is an + aggressive local analysis that "knows" many important facts:

+ +
    +
  • Distinct globals, stack allocations, and heap allocations can never + alias.
  • +
  • Globals, stack allocations, and heap allocations never alias the null + pointer.
  • +
  • Different fields of a structure do not alias.
  • +
  • Indexes into arrays with statically differing subscripts cannot alias.
  • +
  • Many common standard C library functions never access memory or only read memory.
  • +
  • Pointers that obviously point to constant globals + "pointToConstantMemory".
  • +
  • Function calls can not modify or references stack allocations if they never + escape from the function that allocates them (a common case for automatic + arrays).
  • +
+ +
+ + + + +
+ +

This pass implements a simple context-sensitive mod/ref and alias analysis + for internal global variables that don't "have their address taken". If a + global does not have its address taken, the pass knows that no pointers alias + the global. This pass also keeps track of functions that it knows never access + memory or never read memory. This allows certain optimizations (e.g. GCSE) to + eliminate call instructions entirely. +

+ +

The real power of this pass is that it provides context-sensitive mod/ref + information for call instructions. This allows the optimizer to know that + calls to a function do not clobber or read the value of the global, allowing + loads and stores to be eliminated.

+ +

Note that this pass is somewhat limited in its scope (only support + non-address taken globals), but is very quick analysis.

+
+ + + + +
+ +

The -anders-aa pass implements the well-known "Andersen's algorithm" + for interprocedural alias analysis. This algorithm is a subset-based, + flow-insensitive, context-insensitive, and field-insensitive alias analysis that + is widely believed to be fairly precise. Unfortunately, this algorithm is also + O(N3). The LLVM implementation currently does not implement any of + the refinements (such as "online cycle elimination" or "offline variable + substitution") to improve its efficiency, so it can be quite slow in common + cases. +

+ +
+ + + + +
+ +

The -steens-aa pass implements a variation on the well-known + "Steensgaard's algorithm" for interprocedural alias analysis. Steensgaard's + algorithm is a unification-based, flow-insensitive, context-insensitive, and + field-insensitive alias analysis that is also very scalable (effectively linear + time).

+ +

The LLVM -steens-aa pass implements a "speculatively + field-sensitive" version of Steensgaard's algorithm using the Data + Structure Analysis framework. This gives it substantially more precision than + the standard algorithm while maintaining excellent analysis scalability.

+ +
+ + + + +
+ +

The -ds-aa pass implements the full Data Structure Analysis + algorithm. Data Structure Analysis is a modular unification-based, + flow-insensitive, context-sensitive, and speculatively + field-sensitive alias analysis that is also quite scalable, usually at + O(n*log(n)).

+ +

This algorithm is capable of responding to a full variety of alias analysis + queries, and can provide context-sensitive mod/ref information as well. The + only major facility not implemented so far is support for must-alias + information.

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

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

+ +
+ + + + + +
+ +

The -licm pass implements various Loop Invariant Code Motion related + transformations. It uses the AliasAnalysis interface for several + different transformations:

+ +
    +
  • It uses mod/ref information to hoist or sink load instructions out of loops + if there are no instructions in the loop that modifies the memory loaded.
  • + +
  • It uses mod/ref information to hoist function calls out of loops that do not + write to memory and are loop-invariant.
  • + +
  • If uses alias information to promote memory objects that are loaded and + stored to in loops to live in a register instead. It can do this if there are + no may aliases to the loaded/stored memory location.
  • +
+ +
+ + + + +
+

+ The -argpromotion pass promotes by-reference arguments to be passed in + by-value instead. In particular, if pointer arguments are only loaded from it + passes in the value loaded instead of the address to the function. This pass + uses alias information to make sure that the value loaded from the argument + pointer is not modified between the entry of the function and any load of the + pointer.

+
+ + + + +
+ +

The -load-vn pass uses alias analysis to "value + number" loads and pointers values, which is used by the GCSE pass to + eliminate instructions. The -load-vn pass relies on alias information + and must-alias information. This combination of passes can make the following + transformations:

+ +
    +
  • Redundant load instructions are eliminated.
  • +
  • Load instructions that follow a store to the same location are replaced with + the stored value ("store forwarding").
  • +
  • Pointers values (e.g. formal arguments) that must-alias simpler expressions + (e.g. global variables or the null pointer) are replaced. Note that this + implements transformations like "virtual method resolution", turning indirect + calls into direct calls.
  • +
+ +
+ + + + +
+ +

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

+ +
+ + + + +
+ +

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 class.

+ +
+ + + + + +
+ +

The -count-aa pass is useful to see how many queries a particular + pass is making and what responses are returned by the alias analysis. As an + example,

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

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 debugging a transformation or an alias analysis implementation.

+ +
+ + + + +
+ +

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 indicating the percent of no/may/must aliases found (a more precise + algorithm will have a lower number of may aliases).

+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:32 $ +
+ + + Index: llvm-www/releases/1.6/docs/Bugpoint.html diff -c /dev/null llvm-www/releases/1.6/docs/Bugpoint.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/Bugpoint.html Tue Nov 8 14:06:32 2005 *************** *** 0 **** --- 1,238 ---- + + + + LLVM bugpoint tool: design and usage + + + +
+ LLVM bugpoint tool: design and usage +
+ + + +
+

Written by Chris Lattner

+
+ + + + + +
+ +

bugpoint narrows down the source of problems in LLVM tools and + passes. It can be used to debug three types of failures: optimizer crashes, + miscompilations by optimizers, or bad native code generation (including problems + in the static and JIT compilers). It aims to reduce large test cases to small, + useful ones. For 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.

+ +

For detailed case scenarios, such as debugging gccas, + gccld, or one of the LLVM code generators, see How To Submit a Bug Report document.

+ +
+ + + + + +
+ +

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 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. Note that bugpoint is generally very quick unless + debugging a miscompilation where each test of the program (which requires + executing it) takes a long time.

+ +
+ + + + +
+ +

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 (which causes the verifier to abort), 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.

+ +
+ + + + +
+ +

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 38 passes.

+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+ + 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 argv[0], 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 run:

    + +
    +

    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 LLVM 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. + +
+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:32 $ +
+ + + Index: llvm-www/releases/1.6/docs/BytecodeFormat.html diff -c /dev/null llvm-www/releases/1.6/docs/BytecodeFormat.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/BytecodeFormat.html Tue Nov 8 14:06:32 2005 *************** *** 0 **** --- 1,2052 ---- + + + + + LLVM Bytecode File Format + + + + +
LLVM Bytecode File Format
+
    +
  1. Abstract
  2. +
  3. Concepts +
      +
    1. Blocks
    2. +
    3. Lists
    4. +
    5. Fields
    6. +
    7. Alignment
    8. +
    9. Variable Bit-Rate Encoding
    10. +
    11. Encoding Primitives
    12. +
    13. Slots
    14. +
    +
  4. +
  5. General Structure
  6. +
  7. Block Definitions +
      +
    1. Signature Block
    2. +
    3. Module Block
    4. +
    5. Global Type Pool
    6. +
    7. Module Info Block
    8. +
    9. Global Constant Pool
    10. +
    11. Function Definition
    12. +
    13. Compaction Table
    14. +
    15. Instructions List
    16. +
    17. Instructions
    18. +
    19. Symbol Table
    20. +
    +
  8. +
  9. Version Differences +
      +
    1. Version 1.3 Differences From 1.4
    2. +
    3. Version 1.2 Differences From 1.3
    4. +
    5. Version 1.1 Differences From 1.2
    6. +
    7. Version 1.0 Differences From 1.1
    8. +
    +
  10. +
+
+

Written by Reid Spencer +

+
+ + + +
+

This document describes the LLVM bytecode file format. It specifies + the binary encoding rules of the bytecode file format so that + equivalent systems can encode bytecode files correctly. The LLVM + bytecode representation is used to store the intermediate + representation on disk in compacted form.

+

The LLVM bytecode format may change in the future, but LLVM will + always be backwards compatible with older formats. This document will + only describe the most current version of the bytecode format. See Version Differences for the details on how + the current version is different from previous versions.

+
+ + + +
+

This section describes the general concepts of the bytecode file + format without getting into specific layout details. It is recommended + that you read this section thoroughly before interpreting the detailed + descriptions.

+
+ + +
+

LLVM bytecode files consist simply of a sequence of blocks of bytes + using a binary encoding Each block begins with an header of two + unsigned integers. The first value identifies the type of block and the + second value provides the size of the block in bytes. The block + identifier is used because it is possible for entire blocks to be + omitted from the file if they are empty. The block identifier helps the + reader determine which kind of block is next in the file. Note that + blocks can be nested within other blocks.

+

All blocks are variable length, and the block header specifies the + size of the block. All blocks begin on a byte index that is aligned to + an even 32-bit boundary. That is, the first block is 32-bit aligned + because it starts at offset 0. Each block is padded with zero fill + bytes to ensure that the next block also starts on a 32-bit boundary.

+
+ + +
+

LLVM Bytecode blocks often contain lists of things of a similar + type. For example, a function contains a list of instructions and a + function type contains a list of argument types. There are two basic + types of lists: length lists (llist), and null + terminated lists (zlist), as described below in + the Encoding Primitives.

+
+ + +
+

Fields are units of information that LLVM knows how to write atomically. Most + fields have a uniform length or some kind of length indication built into their + encoding. For example, a constant string (array of bytes) is written simply as + the length followed by the characters. Although this is similar to a list, + constant strings are treated atomically and are thus fields.

+

Fields use a condensed bit format specific to the type of information + they must contain. As few bits as possible are written for each field. The + sections that follow will provide the details on how these fields are + written and how the bits are to be interpreted.

+
+ + +
+

To support cross-platform differences, the bytecode file is aligned on + certain boundaries. This means that a small amount of padding (at most 3 + bytes) will be added to ensure that the next entry is aligned to a 32-bit + boundary.

+
+ + +
+

Most of the values written to LLVM bytecode files are small integers. To + minimize the number of bytes written for these quantities, an encoding scheme + similar to UTF-8 is used to write integer data. The scheme is known as + variable bit rate (vbr) encoding. In this encoding, the high bit of + each byte is used to indicate if more bytes follow. If (byte & + 0x80) is non-zero in any given byte, it means there is another byte + immediately following that also contributes to the value. For the final + byte (byte & 0x80) is false (the high bit is not set). In each byte + only the low seven bits contribute to the value. Consequently 32-bit + quantities can take from one to five bytes to encode. In + general, smaller quantities will encode in fewer bytes, as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Byte #Significant BitsMaximum Value
10-6127
27-1316,383
314-202,097,151
421-27268,435,455
528-3434,359,738,367
635-414,398,046,511,103
742-48562,949,953,421,311
849-5572,057,594,037,927,935
956-629,223,372,036,854,775,807
1063-691,180,591,620,717,411,303,423
+

Note that in practice, the tenth byte could only encode bit 63 since + the maximum quantity to use this encoding is a 64-bit integer.

+

Signed VBR values are encoded with the standard vbr + encoding, but with the sign bit as the low order bit instead of the + high order bit. This allows small negative quantities to be encoded + efficiently. For example, -3 + is encoded as "((3 << 1) | 1)" and 3 is encoded as "(3 << + 1) | 0)", emitted with the standard vbr encoding above.

+
+ + +
+

Each field in the bytecode format is encoded into the file using a + small set of primitive formats. The table below defines the encoding + rules for the various primitives used and gives them each a type name. + The type names used in the descriptions of blocks and fields in the Detailed Layoutnext section. Any type name with + the suffix _vbr indicates a quantity that is encoded using + variable bit rate encoding as described above.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeRule
unsignedA 32-bit unsigned integer that always occupies four + consecutive bytes. The unsigned integer is encoded using LSB first + ordering. That is bits 20 through 27 are in the + byte with the lowest file offset (little endian).
+ uint24_vbrA 24-bit unsigned + integer that occupies from one to four bytes using variable bit rate + encoding.
uint32_vbrA 32-bit unsigned integer that occupies from one to + five bytes using variable bit rate encoding.
uint64_vbrA 64-bit unsigned integer that occupies from one to ten + bytes using variable bit rate encoding.
int64_vbrA 64-bit signed integer that occupies from one to ten + bytes using the signed variable bit rate encoding.
charA single unsigned character encoded into one byte
bit(n-m)A set of bit within some larger integer field. The values + of n and m specify the inclusive range of bits + that define the subfield. The value for m may be omitted if + its the same as n.
floatA floating point value encoded + as a 32-bit IEEE value written in little-endian form.
+
doubleA floating point value encoded + as a64-bit IEEE value written in little-endian form
stringA uint32_vbr indicating the type of the + constant string which also includes its length, immediately followed by + the characters of the string. There is no terminating null byte in the + string.
dataAn arbitrarily long segment of data to which + no interpretation is implied. This is used for constant initializers.
+
llist(x)A length list of x. This means the list is + encoded as an uint32_vbr providing the + length of the list, followed by a sequence of that many "x" items. This + implies that the reader should iterate the number of times provided by + the length.
zlist(x)A zero-terminated list of x. This means the + list is encoded as a sequence of an indeterminate number of "x" items, + followed by an uint32_vbr terminating value. + This implies that none of the "x" items can have a zero value (or else + the list terminates).
blockA block of data that is logically related. A + block is an unsigned 32-bit integer that encodes the type of the block + in the low 5 bits and the size of the block in the high 27 bits. The + length does not include the block header or any alignment bytes at the + end of the block. Blocks may compose other blocks.
+
+ + +
+

In the detailed block and field descriptions that follow, a regex + like notation is used to describe optional and repeated fields. A very + limited subset of regex is used to describe these, as given in the + following table:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
CharacterMeaning
?The question mark indicates 0 or 1 + occurrences of the thing preceding it.
*The asterisk indicates 0 or more occurrences + of the thing preceding it.
+The plus sign indicates 1 or more occurrences + of the thing preceding it.
()Parentheses are used for grouping.
,The comma separates sequential fields.
+

So, for example, consider the following specifications:

+
+
    +
  1. string?
  2. +
  3. (uint32_vbr,uin32_vbr)+
  4. +
  5. (unsigned?,uint32_vbr)*
  6. +
  7. (llist(unsigned))?
  8. +
+
+

with the following interpretations:

+
    +
  1. An optional string. Matches either nothing or a single string
  2. +
  3. One or more pairs of uint32_vbr.
  4. +
  5. Zero or more occurrences of either an unsigned followed by a + uint32_vbr or just a uint32_vbr.
  6. +
  7. An optional length list of unsigned values.
  8. +
+
+ + +
+

The bytecode format uses the notion of a "slot" to reference Types + and Values. Since the bytecode file is a direct representation of + LLVM's intermediate representation, there is a need to represent pointers in + the file. Slots are used for this purpose. For example, if one has the following + assembly: +

+
%MyType = type { int, sbyte }
+ %MyVar = external global %MyType +
+

there are two definitions. The definition of %MyVar uses %MyType. + In the C++ IR this linkage between %MyVar and %MyType + is explicit through the use of C++ pointers. In bytecode, however, there's no + ability to store memory addresses. Instead, we compute and write out + slot numbers for every Type and Value written to the file.

+

A slot number is simply an unsigned 32-bit integer encoded in the variable + bit rate scheme (see encoding). This ensures that + low slot numbers are encoded in one byte. Through various bits of magic LLVM + attempts to always keep the slot numbers low. The first attempt is to associate + slot numbers with their "type plane". That is, Values of the same type + are written to the bytecode file in a list (sequentially). Their order in + that list determines their slot number. This means that slot #1 doesn't mean + anything unless you also specify for which type you want slot #1. Types are + always written to the file first (in the Global Type + Pool) and in such a way that both forward and backward references of the + types can often be resolved with a single pass through the type pool.

+

Slot numbers are also kept small by rearranging their order. Because + of the structure of LLVM, certain values are much more likely to be used + frequently in the body of a function. For this reason, a compaction table is + provided in the body of a function if its use would make the function body + smaller. Suppose you have a function body that uses just the types "int*" and + "{double}" but uses them thousands of time. Its worthwhile to ensure that the + slot number for these types are low so they can be encoded in a single byte + (via vbr). This is exactly what the compaction table does.

+

In summary then, a slot number can be though of as just a vbr encoded index + into a list of Type* or Value*. To keep slot numbers low, Value* are indexed by + two slot numbers: the "type plane index" (type slot) and the "value index" + (value slot).

+
+ + + +
+

This section provides the general structure of the LLVM bytecode + file format. The bytecode file format requires blocks to be in a + certain order and nested in a particular way so that an LLVM module can + be constructed efficiently from the contents of the file. This ordering + defines a general structure for bytecode files as shown below. The + table below shows the order in which all block types may appear. Please + note that some of the blocks are optional and some may be repeated. The + structure is fairly loose because optional blocks, if empty, are + completely omitted from the file.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
IDParentOptional?Repeated?LevelBlock TypeDescription
N/AFileNoNo0SignatureThis contains the file signature (magic + number) that identifies the file as LLVM bytecode.
0x01FileNoNo0ModuleThis is the top level block in a bytecode + file. It contains all the other blocks.
0x06ModuleNoNo1   Global Type PoolThis block contains all the global (module) + level types.
0x05ModuleNoNo1   Module Globals InfoThis block contains the type, constness, and + linkage for each of the global variables in the module. It also + contains the type of the functions and the constant initializers.
0x03ModuleYesNo1   Module Constant PoolThis block contains all the global constants + except function arguments, global values and constant strings.
0x02ModuleYesYes1   Function Definitions*One function block is written for each + function in the module. The function block contains the instructions, + compaction table, type constant pool, and symbol table for the function.
0x03FunctionYesNo2      Function Constant PoolAny constants (including types) used solely + within the function are emitted here in the function constant pool.
0x08FunctionYesNo2      Compaction TableThis table reduces bytecode size by providing + a funtion-local mapping of type and value slot numbers to their global + slot numbers
0x07FunctionNoNo2      Instruction ListThis block contains all the instructions of + the function. The basic blocks are inferred by terminating + instructions.
0x04FunctionYesNo2      Function Symbol TableThis symbol table provides the names for the + function specific values used (basic block labels mostly).
0x04ModuleYesNo1   Module Symbol TableThis symbol table provides the names for the + various entries in the file that are not function specific (global + vars, and functions mostly).
+

Use the links in the table for details about the contents of each of + the block types.

+
+ + + +
+

This section provides the detailed layout of the individual block + types in the LLVM bytecode file format.

+
+ + +
+

The signature occurs in every LLVM bytecode file and is always first. + It simply provides a few bytes of data to identify the file as being an LLVM + bytecode file. This block is always four bytes in length and differs from the + other blocks because there is no identifier and no block length at the start + of the block. Essentially, this block is just the "magic number" for the file. +

+

There are two types of signatures for LLVM bytecode: uncompressed and + compressed as shown in the table below.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeUncompressedCompressed
charConstant "l" (0x6C)Constant "l" (0x6C)
charConstant "l" (0x6C)Constant "l" (0x6C)
charConstant "v" (0x76)Constant "v" (0x76)
charConstant "m" (0x6D)Constant "c" (0x63)
charN/A'0'=null,'1'=gzip,'2'=bzip2
+

In other words, the uncompressed signature is just the characters 'llvm' + while the compressed signature is the characters 'llvc' followed by an ascii + digit ('0', '1', or '2') that indicates the kind of compression used. A value of + '0' indicates that null compression was used. This can happen when compression + was requested on a platform that wasn't configured for gzip or bzip2. A value of + '1' means that the rest of the file is compressed using the gzip algorithm and + should be uncompressed before interpretation. A value of '2' means that the rest + of the file is compressed using the bzip2 algorithm and should be uncompressed + before interpretation. In all cases, the data resulting from uncompression + should be interpreted as if it occurred immediately after the 'llvm' + signature (i.e. the uncompressed data begins with the + Module Block

+

NOTE: As of LLVM 1.4, all bytecode files produced by the LLVM tools + are compressed by default. To disable compression, pass the + --disable-compression option to the tool, if it supports it. +

+ + +
+

The module block contains a small pre-amble and all the other blocks in + the file. The table below shows the structure of the module block. Note that it + only provides the module identifier, size of the module block, and the format + information. Everything else is contained in other blocks, described in other + sections.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeField Description
unsigned
Module Block Identifier + (0x01)
unsignedModule Block Size
uint32_vbrFormat Information
blockGlobal Type Pool
blockModule Globals Info
blockModule Constant Pool
block*Function Definitions
blockModule Symbol Table
+
+ + + +
+

The block header for the module block uses a longer format than the other + blocks in a bytecode file. Specifically, instead of encoding the type and size + of the block into a 32-bit integer with 5-bits for type and 27-bits for size, + the module block header uses two 32-bit unsigned values, one for type, and one + for size. While the 227 byte limit on block size is sufficient for the blocks + contained in the module, it isn't sufficient for the module block itself + because we want to ensure that bytecode files as large as 232 bytes + are possible. For this reason, the module block (and only the module block) + uses a long format header.

+
+ + + +
+

The format information field is encoded into a uint32_vbr + as shown in the following table.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
bit(0)Target is big endian?
bit(1)On target pointers are 64-bit?
bit(2)Target has no endianess?
bit(3)Target has no pointer size?
bit(4-31)Bytecode format version
+

+ Of particular note, the bytecode format number is simply a 28-bit + monotonically increasing integer that identifies the version of the bytecode + format (which is not directly related to the LLVM release number). The + bytecode versions defined so far are (note that this document only + describes the latest version, 1.3):

+
    +
  • #0: LLVM 1.0 & 1.1
  • +
  • #1: LLVM 1.2
  • +
  • #2: LLVM 1.2.5 (not released)
  • +
  • #3: LLVM 1.3
  • +
  • #4: LLVM 1.3.x (not released)
  • +
  • #5: LLVM 1.4, 1.5, 1.6
  • + +
+

Note that we plan to eventually expand the target description + capabilities + of bytecode files to target + triples. +

+
+ + +
+

The global type pool consists of type definitions. Their order of appearance + in the file determines their type slot number (0 based). Slot numbers are + used to replace pointers in the intermediate representation. Each slot number + uniquely identifies one entry in a type plane (a collection of values of the + same type). Since all values have types and are associated with the order in + which the type pool is written, the global type pool must be written + as the first block of a module. If it is not, attempts to read the file will + fail because both forward and backward type resolution will not be possible.

+

The type pool is simply a list of type definitions, as shown in the + table below.

+ + + + + + + + + + + + + + + +
TypeField Description
blockType Pool Identifier (0x06) + Size
+
llist(type)A length list of type definitions.
+
+ + +
+

Types in the type pool are defined using a different format for each kind + of type, as given in the following sections.

+

Primitive Types

+

The primitive types encompass the basic integer and floating point + types. They are encoded simply as their TypeID.

+ + + + + + + + + + + +
TypeDescription
uint24_vbrType ID for the primitive types (values 1 to + 11) 1
+ Notes: +
    +
  1. The values for the Type IDs for the primitive types are provided + by the definition of the llvm::Type::TypeID enumeration + in include/llvm/Type.h. The enumeration gives the + following mapping: +
      +
    1. bool
    2. +
    3. ubyte
    4. +
    5. sbyte
    6. +
    7. ushort
    8. +
    9. short
    10. +
    11. uint
    12. +
    13. int
    14. +
    15. ulong
    16. +
    17. long
    18. +
    19. float
    20. +
    21. double
    22. +
    +
  2. +
+

Function Types

+ + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
uint24_vbrType ID for function types (13)
uint24_vbrType slot number of function's return type.
llist(uint24_vbr)Type slot number of each argument's type.
uint32_vbr?Value 0 if this is a varargs function, + missing otherwise.
+

Structure Types

+ + + + + + + + + + + + + + + +
TypeDescription
uint24_vbrType ID for structure types (14)
zlist(uint24_vbr)Slot number of each of the element's fields.
+

Array Types

+ + + + + + + + + + + + + + + + + + + +
TypeDescription
uint24_vbrType ID for Array Types (15)
uint24_vbrType slot number of array's element type.
uint32_vbrThe number of elements in the array.
+

Pointer Types

+ + + + + + + + + + + + + + + +
TypeDescription
uint24_vbrType ID For Pointer Types (16)
uint24_vbrType slot number of pointer's element type.
+

Opaque Types

+ + + + + + + + + + + +
TypeDescription
uint24_vbrType ID For Opaque Types (17)
+

Packed Types

+ + + + + + + + + + + + + + + + + + + +
TypeDescription
uint24_vbrType ID for Packed Types (18)
uint24_vbrSlot number of packed vector's element type.
uint32_vbrThe number of elements in the packed vector.
+
+ + +
+

The module global info block contains the definitions of all global + variables including their initializers and the declaration of + all functions. The format is shown in the table below:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeField Description
blockModule global info identifier (0x05) + size
+
zlist(globalvar)A zero terminated list of global var + definitions occurring in the module.
zlist(funcfield)A zero terminated list of function definitions + occurring in the module.
llist(string)
+
A length list + of strings that specify the names of the libraries that this module + depends upon.
+
string
+
The target + triple for the module (blank means no target triple specified, i.e. a + platform independent module).
+
+
+ + + + +
+ +

Global variables are written using an uint32_vbr + that encodes information about the global variable, an optional extension vbr, + and a an optional initializers for the global var.

+ +

The table below provides the bit layout of the first uint32_vbr that describes the global variable.

+ + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
bit(0)Is constant?
bit(1)Has initializer? Note that this bit + determines whether the constant initializer field (described below) + follows.
bit(2-4)Linkage type: 0=External, 1=Weak, + 2=Appending, 3=Internal, 4=LinkOnce
bit(5-31)Type slot number of type for the global variable.
+ +

When the Linkage type is set to 3 (internal) and the initializer field is set + to 0 (an invalid combination), an extension word follows the first uint32_vbr which encodes the real linkage and init flag, + and can includes more information:

+ + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
bit(0)Has initializer? Indicates the real value of the "Has + initializer" field for the global.
bit(2-4)Linkage type: Indicates the real value of the "linkage + type" field for the global.
bit(4-8)The log-base-2 of the alignment for the global.
bit(9-31)Currently unassigned.
+ +

The table below provides the format of the constant initializers for + the global variable field, if it has one (indicated by the "Has initializer" + field).

+ + + + + + + + + + + + +
TypeDescription
(zlist(uint32_vbr))? + An optional zero-terminated list of value slot + numbers of the global variable's constant initializer.
+
+ + + +
+

Functions are written using an uint32_vbr + that encodes information about the function and a set of flags. If needed, + an extension word may follow this first field.

+ +

The table below provides the bit layout of the uint32_vbr that describes the function.

+ + + + + + + + + + + + + + + + + + + + + + + + +
TypeDescription
bit(0-3) + Encodes the calling convention number of the function. The + CC number of the function is the value of this field minus one. +
bit(4)If this bit is set to 1, the indicated function is + external, and there is no Function Definiton + Block in the bytecode file for the function.
bit(5-30)Type slot number of type for the function.
bit(31)Indicates whether an extension word follows.
+ +

If bit(31) is set, an additional uint32_vbr word + follows with the following fields:

+ + + + + + + + + + + + + + + + + + + + +
TypeDescription
bit(0-4)The log-base-2 of the alignment for the function.
bit(5-9)The top nibble of the calling convention.
bit(10-31)Currently unassigned.
+ +
+ + + +
+

A constant pool defines as set of constant values. There are + actually two types of constant pool blocks: one for modules and one for + functions. For modules, the block begins with the constant strings + encountered anywhere in the module. For functions, the block begins + with types only encountered in the function. In both cases the header + is identical. The tables that follow, show the header, module constant + pool preamble, function constant pool preamble, and the part common to + both function and module constant pools.

+

Common Block Header

+ + + + + + + + + + + +
TypeField Description
blockConstant pool identifier (0x03) + size
+
+

Module Constant Pool Preamble (constant strings)

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
uint32_vbrThe number of constant strings that follow.
uint32_vbrZero. This identifies the following "plane" + as containing the constant strings. This is needed to identify it + uniquely from other constant planes that follow.
uint24_vbr+Type slot number of the constant string's type. + Note that the constant string's type implicitly defines the length of + the string.
+

Function Constant Pool Preamble (function types)

+

The structure of the types for functions is identical to the Global Type Pool. Please refer to that section + for the details.

+

Common Part (other constants)

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
uint32_vbrNumber of entries in this type plane.
uint24_vbrType slot number of this plane.
constant+The definition of a constant (see below).
+
+ + +
+

Constants come in many shapes and flavors. The sections that follow + define the format for each of them. All constants start with a uint32_vbr encoded integer that provides the + number of operands for the constant. For primitive, structure, and + array constants, this will always be zero since those types of + constants have no operands. In this case, we have the following field + definitions:

+
    +
  • Bool. This is written as an uint32_vbr + of value 1U or 0U.
  • +
  • Signed Integers (sbyte,short,int,long). These are written + as an int64_vbr with the corresponding value.
  • +
  • Unsigned Integers (ubyte,ushort,uint,ulong). These are + written as an uint64_vbr with the + corresponding value.
  • +
  • Floating Point. Both the float and double types are + written literally in binary format.
  • +
  • Arrays. Arrays are written simply as a list of uint32_vbr encoded value slot numbers to the constant + element values.
  • +
  • Structures. Structures are written simply as a list of uint32_vbr encoded value slot numbers to the constant + field values of the structure.
  • +
+ +

When the number of operands to the constant is one, we have an 'undef' value + of the specified type.

+ +

When the number of operands to the constant is greater than one, we have a + constant expression and its field format is provided in the table below, and the + number is equal to the number of operands+1.

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
uint32_vbrOp code of the instruction for the constant + expression.
uint32_vbrThe value slot number of the constant value for an + operand.1
uint24_vbrThe type slot number for the type of the constant + value for an operand.1
+ Notes: +
    +
  1. Both these fields are repeatable but only in pairs.
  2. +
+
+ + +
+

Function definitions contain the linkage, constant pool or + compaction table, instruction list, and symbol table for a function. + The following table shows the structure of a function definition.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
TypeField Description
block
+
Function definition block identifier (0x02) + + size
+
uint32_vbrThe linkage type of the function: 0=External, + 1=Weak, 2=Appending, 3=Internal, 4=LinkOnce1
blockThe constant pool + block for this function.2
blockThe compaction + table block for the function.2
blockThe instruction + list for the function.
blockThe function's symbol + table containing only those symbols pertinent to the function + (mostly block labels).
+ Notes: +
    +
  1. Note that if the linkage type is "External" then none of the + other fields will be present as the function is defined elsewhere.
  2. +
  3. Note that only one of the constant pool or compaction table will + be written. Compaction tables are only written if they will actually + save bytecode space. If not, then a regular constant pool is written.
  4. +
+
+ + +
+

Compaction tables are part of a function definition. They are merely + a device for reducing the size of bytecode files. The size of a + bytecode file is dependent on the values of the slot numbers + used because larger values use more bytes in the variable bit rate + encoding scheme. Furthermore, the compressed instruction format + reserves only six bits for the type of the instruction. In large + modules, declaring hundreds or thousands of types, the values of the + slot numbers can be quite large. However, functions may use only a + small fraction of the global types. In such cases a compaction table is + created that maps the global type and value slot numbers to smaller + values used by a function. Functions will contain either a + function-specific constant pool or a compaction table but not + both. Compaction tables have the format shown in the table below.

+ + + + + + + + + + + + + + + + + + + + + + + +
TypeField Description
uint32_vbrThe number of types that follow
uint24_vbr+The type slot number in the global types of + the type that will be referenced in the function with the index of this + entry in the compaction table.
type_lenAn encoding of the type and number of values + that follow. This field's encoding varies depending on the size of the + type plane. See Type and Length for further + details.
uint32_vbr+The value slot number in the global values + that will be referenced in the function with the index of this entry in + the compaction table.
+
+ + +
+

The type and length of a compaction table type plane is encoded + differently depending on the length of the plane. For planes of length + 1 or 2, the length is encoded into bits 0 and 1 of a uint32_vbr and the type is encoded into bits + 2-31. Because type numbers are often small, this often saves an extra + byte per plane. If the length of the plane is greater than 2 then the + encoding uses a uint32_vbr for each of the + length and type, in that order.

+
+ + +
+

The instructions in a function are written as a simple list. Basic + blocks are inferred by the terminating instruction types. The format of + the block is given in the following table.

+ + + + + + + + + + + + + + + +
TypeField Description
block
+
Instruction list identifier (0x07) + size
+
instruction+An instruction. Instructions have a variety + of formats. See Instructions for details.
+
+ + + + +
+

Instructions are written out one at a time as distinct units. Each + instruction + record contains at least an opcode and a type field, + and may contain a list of operands (whose + interpretation depends on the opcode). Based on the number of operands, the + instruction is encoded in a + dense format that tries to encoded each instruction into 32-bits if + possible.

+
+ + + +
+

Instructions encode an opcode that identifies the kind of instruction. + Opcodes are an enumerated integer value. The specific values used depend on + the version of LLVM you're using. The opcode values are defined in the + + include/llvm/Instruction.def file. You should check there for the + most recent definitions. The table below provides the opcodes defined as of + the writing of this document. The table associates each opcode mnemonic with + its enumeration value and the bytecode and LLVM version numbers in which the + opcode was introduced.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OpcodeNumberBytecode VersionLLVM Version
Terminator Instructions
Ret111.0
Br211.0
Switch311.0
Invoke411.0
Unwind511.0
Unreachable611.4
Binary Operators
Add711.0
Sub811.0
Mul911.0
Div1011.0
Rem1111.0
Logical Operators
And1211.0
Or1311.0
Xor1411.0
Binary Comparison Operators
SetEQ1511.0
SetNE1611.0
SetLE1711.0
SetGE1811.0
SetLT1911.0
SetGT2011.0
Memory Operators
Malloc2111.0
Free2211.0
Alloca2311.0
Load2411.0
Store2511.0
GetElementPtr2611.0
Other Operators
PHI2711.0
Cast2811.0
Call2911.0
Shl3011.0
Shr3111.0
VANext3211.0
VAArg3311.0
Select3421.2
+ Pseudo Instructions* +
Invoke+CC 5651.5
Invoke+FastCC5751.5
Call+CC5851.5
Call+FastCC+TailCall5951.5
Call+FastCC6051.5
Call+CCC+TailCall6151.5
Load+Volatile6231.3
Store+Volatile6331.3
+ +

* Note: + These aren't really opcodes from an LLVM language perspective. They encode + information into other opcodes without reserving space for that information. + For example, opcode=63 is a Volatile Store. The opcode for this + instruction is 25 (Store) but we encode it as 63 to indicate that is a Volatile + Store. The same is done for the calling conventions and tail calls. + In each of these entries in range 56-63, the opcode is documented as the base + opcode (Invoke, Call, Store) plus some set of modifiers, as follows:

+
+
CC
+
This means an arbitrary calling convention is specified + in a VBR that follows the opcode. This is used when the instruction cannot + be encoded with one of the more compact forms. +
+
FastCC
+
This indicates that the Call or Invoke is using the FastCC calling + convention.
+
CCC
+
This indicates that the Call or Invoke is using the native "C" calling + convention.
+
TailCall
+
This indicates that the Call has the 'tail' modifier.
+
+
+ + + + +
+

+ Based on the instruction opcode and type, the bytecode format implicitly (to + save space) specifies the interpretation of the operand list. For most + instructions, the type of each operand is implicit from the type of the + instruction itself (e.g. the type of operands of a binary operator must match + the type of the instruction). As such, the bytecode format generally only + encodes the value number of the operand, not the type.

+ +

In some cases, however, this is not sufficient. This section enumerates + those cases:

+ +
    +
  • getelementptr: the slot numbers for sequential type indexes are shifted up + two bits. This allows the low order bits will encode the type of index used, + as follows: 0=uint, 1=int, 2=ulong, 3=long.
  • +
  • cast: the result type number is encoded as the second operand.
  • +
  • alloca/malloc: If the allocation has an explicit alignment, the log2 of the + alignment is encoded as the second operand.
  • +
  • call: If the tail marker and calling convention cannot be encoded into the opcode of the call, it is passed as an + additional operand. The low bit of the operand is a flag indicating whether + the call is a tail call. The rest of the bits contain the calling + convention number (shifted left by one bit).
  • +
+
+ + + + +
+

For brevity, instructions are written in one of four formats, + depending on the number of operands to the instruction. Each + instruction begins with a uint32_vbr that + encodes the type of the instruction as well as other things. The tables + that follow describe the format of this first part of each instruction.

+

Instruction Format 0

+

This format is used for a few instructions that can't easily be + shortened because they have large numbers of operands (e.g. PHI Node or + getelementptr). Each of the opcode, type, and operand fields is found in + successive fields.

+ + + + + + + + + + + + + + + + + + + + + + + +
TypeField Description
uint32_vbrSpecifies the opcode of the instruction. Note + that for compatibility with the other instruction formats, the opcode + is shifted left by 2 bits. Bits 0 and 1 must have value zero for this + format.
uint24_vbrProvides the type slot number of the result type of + the instruction.
uint32_vbrThe number of operands that follow.
uint32_vbr+The slot number of the value(s) for the operand(s). +
+ +

Instruction Format 1

+

This format encodes the opcode, type and a single operand into a + single uint32_vbr as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsTypeField Description
0-1constant "1"These two bits must be the value 1 which identifies + this as an instruction of format 1.
2-7opcodeSpecifies the opcode of the instruction. Note that + the maximum opcode value is 63.
8-19unsignedSpecifies the slot number of the type for this + instruction. Maximum slot number is 212-1=4095.
20-31unsignedSpecifies the slot number of the value for the + first operand. Maximum slot number is 212-1=4095. Note that + the value 212-1 denotes zero operands.
+

Instruction Format 2

+

This format encodes the opcode, type and two operands into a single uint32_vbr as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsTypeField Description
0-1constant "2"These two bits must be the value 2 which identifies + this as an instruction of format 2.
2-7opcodeSpecifies the opcode of the instruction. Note that + the maximum opcode value is 63.
8-15unsignedSpecifies the slot number of the type for this + instruction. Maximum slot number is 28-1=255.
16-23unsignedSpecifies the slot number of the value for the first + operand. Maximum slot number is 28-1=255.
24-31unsignedSpecifies the slot number of the value for the second + operand. Maximum slot number is 28-1=255.
+

Instruction Format 3

+

This format encodes the opcode, type and three operands into a + single uint32_vbr as follows:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
BitsTypeField Description
0-1constant "3"These two bits must be the value 3 which identifies + this as an instruction of format 3.
2-7opcodeSpecifies the opcode of the instruction. Note that + the maximum opcode value is 63.
8-13unsignedSpecifies the slot number of the type for this + instruction. Maximum slot number is 26-1=63.
14-19unsignedSpecifies the slot number of the value for the first + operand. Maximum slot number is 26-1=63.
20-25unsignedSpecifies the slot number of the value for the second + operand. Maximum slot number is 26-1=63.
26-31unsignedSpecifies the slot number of the value for the third + operand. Maximum slot number is 26-1=63.
+
+ + + +
+

A symbol table can be put out in conjunction with a module or a function. A + symbol table has a list of name/type associations followed by a list of + name/value associations. The name/value associations are organized into "type + planes" so that all values of a common type are listed together. Each type + plane starts with the number of entries in the plane and the type slot number + for all the values in that plane (so the type can be looked up in the global + type pool). For each entry in a type plane, the slot number of the value and + the name associated with that value are written. The format is given in the + table below.

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
block
+
Symbol Table Identifier (0x04)
llist(type_entry)A length list of symbol table entries for + Types +
llist(symtab_plane)A length list of "type planes" of symbol table + entries for Values
+
+ + + +
+

A symbol table type entry associates a name with a type. The name is provided + simply as an array of chars. The type is provided as a type slot number (index) + into the global type pool. The format is given in the following table:

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
uint24_vbrType slot number of the type being given a + name relative to the global type pool. +
uint32_vbrLength of the character array that follows.
char+The characters of the name.
+
+ + +
+

A symbol table plane provides the symbol table entries for all + values of a common type. The encoding is given in the following table:

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
uint32_vbrNumber of entries in this plane.
uint32_vbrType slot number of type for all values in this plane..
value_entry+The symbol table entries for to associate values with + names.
+
+ + +
+

A symbol table value entry provides the assocation between a value and the + name given to the value. The value is referenced by its slot number. The + format is given in the following table:

+ + + + + + + + + + + + + + + + + + + +
TypeField Description
uint24_vbrValue slot number of the value being given a name. +
uint32_vbrLength of the character array that follows.
char+The characters of the name.
+
+ + + + +
+

This section describes the differences in the Bytecode Format across + LLVM + versions. The versions are listed in reverse order because it assumes + the current version is as documented in the previous sections. Each + section here + describes the differences between that version and the one that follows. +

+
+ + + + + +
Unreachable Instruction
+
+

The LLVM Unreachable instruction + was added in version 1.4 of LLVM. This caused all instruction numbers after + it to shift down by one.

+
+ +
Function Flags
+
+

LLVM bytecode versions prior to 1.4 did not include the 5 bit offset + in the function list in the Module Global Info block.

+
+ +
Function Flags
+
+

LLVM bytecode versions prior to 1.4 did not include the 'undef' constant + value, which affects the encoding of Constant + Fields.

+
+ + + + + + + +
Type Derives From Value
+
+

In version 1.2, the Type class in the LLVM IR derives from the Value + class. This is not the case in version 1.3. Consequently, in version + 1.2 the notion of a "Type Type" was used to write out values that were + Types. The types always occuped plane 12 (corresponding to the + TypeTyID) of any type planed set of values. In 1.3 this representation + is not convenient because the TypeTyID (12) is not present and its + value is now used for LabelTyID. Consequently, the data structures + written that involve types do so by writing all the types first and + then each of the value planes according to those types. In version 1.2, + the types would have been written intermingled with the values.

+
+ +
Restricted getelementptr Types
+
+

In version 1.2, the getelementptr instruction required a ubyte type + index for accessing a structure field and a long type index for + accessing an array element. Consequently, it was only possible to + access structures of 255 or fewer elements. Starting in version 1.3, + this restriction was lifted. Structures must now be indexed with uint + constants. Arrays may now be indexed with int, uint, long, or ulong + typed values. The consequence of this was that the bytecode format had + to change in order to accommodate the larger range of structure indices.

+
+ +
Short Block Headers
+
+

In version 1.2, block headers were always 8 bytes being comprised of + both an unsigned integer type and an unsigned integer size. For very + small modules, these block headers turn out to be a large fraction of + the total bytecode file size. In an attempt to make these small files + smaller, the type and size information was encoded into a single + unsigned integer (4 bytes) comprised of 5 bits for the block type + (maximum 31 block types) and 27 bits for the block size (max + ~134MBytes). These limits seemed sufficient for any blocks or sizes + forseen in the future. Note that the module block, which encloses all + the other blocks is still written as 8 bytes since bytecode files + larger than 134MBytes might be possible.

+
+ +
Dependent Libraries and Target Triples
+
+

In version 1.2, the bytecode format does not store module's target + triple or dependent. These fields have been added to the end of the module global info block. The purpose of these + fields is to allow a front end compiler to specifiy that the generated + module is specific to a particular target triple (operating + system/manufacturer/processor) which makes it non-portable; and to + allow front end compilers to specify the list of libraries that the + module depends on for successful linking.

+
+ +
Types Restricted to 24-bits
+
+

In version 1.2, type slot identifiers were written as 32-bit VBR + quantities. In 1.3 this has been reduced to 24-bits in order to ensure + that it is not possible to overflow the type field of a global variable + definition. 24-bits for type slot numbers is deemed sufficient for any + practical use of LLVM.

+
+ + + + +
Explicit Primitive Zeros
+
+

In version 1.1, the zero value for primitives was explicitly encoded + into the bytecode format. Since these zero values are constant values + in the LLVM IR and never change, there is no reason to explicitly + encode them. This explicit encoding was removed in version 1.2.

+
+ +
Inconsistent Module Global Info
+
+

In version 1.1, the Module Global Info block was not aligned causing + the next block to be read in on an unaligned boundary. This problem was + corrected in version 1.2.
+
+

+
+ + +
+

None. Version 1.0 and 1.1 bytecode formats are identical.

+
+ +
+
Valid CSS! + Valid HTML 4.01! + Reid Spencer and Chris Lattner
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:32 $ +
+ + Index: llvm-www/releases/1.6/docs/CFEBuildInstrs.html diff -c /dev/null llvm-www/releases/1.6/docs/CFEBuildInstrs.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/CFEBuildInstrs.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,364 ---- + + + + + + Bootstrapping the LLVM C/C++ Front-End + + + +
+ Bootstrapping the LLVM C/C++ Front-End +
+ +
    +
  1. A Cautionary Note + +
  2. +
  3. Instructions
  4. +
  5. License Information
  6. +
+ +
+

Written by Brian R. Gaeke and + Chris Lattner

+
+ + + + + +
+

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. +
  3. you are an elite GCC hacker.
  4. +
  5. you want to use the latest bits from CVS.
  6. +
+ +

We welcome patches to help make this process simpler.

+
+ + + + + +
+

If you are building LLVM and the GCC front-end under Cygwin, please note that + the LLVM and GCC makefiles do not correctly handle spaces in paths. To deal + with this issue, make sure that your LLVM and GCC source and build trees are + located in a top-level directory (like /cygdrive/c/llvm and + /cygdrive/c/llvm-cfrontend), not in a directory that contains a space + (which includes your "home directory", because it lives under the "Documents + and Settings" directory). We welcome patches to fix this issue. +

+

It has been found that the GCC 3.3.3 compiler provided with recent Cygwin + versions is incapable of compiling the LLVM GCC front-end correctly. If your + Cygwin + installation includes GCC 3.3.3, we strongly recommend that you download + GCC 3.4.3, build it separately, and use it for compiling the LLVM GCC front-end. This has been + shown to work correctly.

+

Some versions of Cygwin utilize an experimental version of GNU binutils that + will cause the GNU ld linker to fail an assertion when linking + components of the libstdc++. It is recommended that you replace the entire + binutils package with version 2.15 such that "ld --version" responds + with

+
GNU ld version 2.15
+ not with:
+
GNU ld version 2.15.91 20040725
+
+ + + +
+

If you are building LLVM and the GCC front-end under AIX, do NOT use GNU + Binutils. They are not stable under AIX and may produce incorrect and/or + invalid code. Instead, use the system assembler and linker. +

+
+ + + + + +
+

+

    +
  1. Configure and build the LLVM libraries and tools. There are two ways to + do this: either with objdir == srcdir or + objdir != srcdir. It is recommended + that srcdir be the same as objdir for your LLVM tree (but note + that you should always use srcdir != objdir for llvm-gcc):

    +
      +
    • With objdir != srcdir:
      +  % cd objdir
      +  % srcdir/configure --prefix=/some/path/you/can/install/to [options...]
      +  % gmake tools-only
      +   
    • +
    • With objdir == srcdir:
      +  % cd llvm
      +  % ./configure --prefix=/some/path/you/can/install/to [options...]
      +  % gmake tools-only
      +   
    • +
    +

    This will build all of the LLVM tools and libraries. The --prefix + option defaults to /usr/local (per configure standards) but unless you are a + system administrator, you probably won't be able to install LLVM there because + of permissions. Specify a path into which LLVM can be installed (e.g. + --prefix=/home/user/llvm).

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

    +
    +  % set path = ( `cd llvm/Debug/bin && pwd` $path )
    + 
  4. + +
  5. Unpack the C/C++ front-end source into cfrontend/src, either by + untar'ing a cfrontend.source.tar.gz file or checking out CVS into this + directory.

  6. + +
  7. 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
    + 
  8. + + +
  9. Configure, build, and install the GCC front-end:

    + +

    + Linux/x86:
    + Linux/IA-64:
    + MacOS X/PowerPC (requires dlcompat library):
    + AIX/PowerPC: +

    + +
    +  % cd build
    +  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
    +    --disable-shared --enable-languages=c,c++ --program-prefix=llvm-
    +  % gmake all; gmake install
    + 
    + +

    Cygwin/x86:

    + +
    +  % cd build
    +  % ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
    +    --disable-shared --enable-languages=c,c++ --disable-c-mbchar \
    +    --program-prefix=llvm-
    +  % gmake all; gmake install
    + 
    + +

    Solaris/SPARC:

    + +

    + The GCC front-end can be configured for either SPARC V8 (32 bit) or SPARC V9 (64 + bit). This changes, among other things, the sizes of integer types and the + macros defined for conditional compilation. +

    + +

    + The SPARC V8 backend is still beta quality software. Unless you are working on + the SPARC V8 backend, you should specify sparcv9 on the configure command line, + 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 --program-prefix=llvm-
    +  % 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/lib/gcc/target-triplet/3.4-llvm/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 front-end + to a new architecture or compiling in a configuration that we have + not tried 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 assembler or 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.
    • +
    +
  10. + +
  11. Put $CFEINSTALL/bin into your PATH environment + variable.

    +
      +
    • sh: export PATH=$CFEINSTALL/bin:$PATH
    • +
    • csh: setenv PATH $CFEINSTALL/bin:$PATH
    • +
    +
  12. + +
  13. Go back into the LLVM source tree proper. Rerun configure, using + the same options as the last time. This will cause the configuration to now find + the newly built llvm-gcc and llvm-g++ executables.

  14. + +
  15. Rebuild your CVS tree. This shouldn't cause the whole thing to be + rebuilt, but it should build the runtime libraries. After the tree is + built, install the runtime libraries into your GCC front-end build tree. + These are the commands you need:

    +
    +  % gmake
    +  % gmake -C runtime install-bytecode
    + 
  16. + +
  17. Optionally, build a symbol table for the newly installed runtime + libraries. Although this step is optional, you are strongly encouraged to + do this as the symbol tables will make a significant difference in your + link times. Use the llvm-ranlib tool to do this, as follows:

    +
    +  % cd $CFEINSTALL/lib
    +  % llvm-ranlib libiberty.a
    +  % llvm-ranlib libstdc++.a
    +  % llvm-ranlib libsupc++.a
    +  % cd $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm
    +  % llvm-ranlib libgcc.a
    +  % llvm-ranlib libgcov.a
    + 
    + +
  18. Test the newly-installed C frontend by one or more of the + following means:

    +
      +
    • running the feature & regression tests via make check
    • +
    • compiling and running a "hello, LLVM" program in C and C++.
    • +
    • running the tests found in the llvm-test CVS module
    • +
  19. +
+
+ + + + +
+

+ 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, 2005 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.
+ 
+
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Brian Gaeke
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/CodeGenerator.html diff -c /dev/null llvm-www/releases/1.6/docs/CodeGenerator.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/CodeGenerator.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,1304 ---- + + + + The LLVM Target-Independent Code Generator + + + + +
+ The LLVM Target-Independent Code Generator +
+ +
    +
  1. Introduction + +
  2. +
  3. Target description classes + +
  4. +
  5. Machine code description classes + +
  6. +
  7. Target-independent code generation algorithms + +
  8. +
  9. Target-specific Implementation Notes + +
  10. + +
+ +
+

Written by Chris Lattner

+
+ +
+

Warning: This is a work in progress.

+
+ + + + + +
+ +

The LLVM target-independent code generator is a framework that provides a + suite of reusable components for translating the LLVM internal representation to + the machine code for a specified target -- either in assembly form (suitable for + a static compiler) or in binary machine code format (usable for a JIT compiler). + The LLVM target-independent code generator consists of five main components:

+ +
    +
  1. Abstract target description interfaces which + capture important properties about various aspects of the machine, independently + of how they will be used. These interfaces are defined in + include/llvm/Target/.
  2. + +
  3. Classes used to represent the machine code being + generated for a target. These classes are intended to be abstract enough to + represent the machine code for any target machine. These classes are + defined in include/llvm/CodeGen/.
  4. + +
  5. Target-independent algorithms used to implement + various phases of native code generation (register allocation, scheduling, stack + frame representation, etc). This code lives in lib/CodeGen/.
  6. + +
  7. Implementations of the abstract target description + interfaces for particular targets. These machine descriptions make use of + the components provided by LLVM, and can optionally provide custom + target-specific passes, to build complete code generators for a specific target. + Target descriptions live in lib/Target/.
  8. + +
  9. The target-independent JIT components. The LLVM JIT is + completely target independent (it uses the TargetJITInfo structure to + interface for target-specific issues. The code for the target-independent + JIT lives in lib/ExecutionEngine/JIT.
  10. + +
+ +

+ Depending on which part of the code generator you are interested in working on, + different pieces of this will be useful to you. In any case, you should be + familiar with the target description and machine code representation classes. If you want to add + a backend for a new target, you will need to implement the + target description classes for your new target and understand the LLVM code representation. If you are interested in + implementing a new code generation algorithm, it + should only depend on the target-description and machine code representation + classes, ensuring that it is portable. +

+ +
+ + + + +
+ +

The two pieces of the LLVM code generator are the high-level interface to the + code generator and the set of reusable components that can be used to build + target-specific backends. The two most important interfaces (TargetMachine and TargetData) are the only ones that are + required to be defined for a backend to fit into the LLVM system, but the others + must be defined if the reusable code generator components are going to be + used.

+ +

This design has two important implications. The first is that LLVM can + support completely non-traditional code generation targets. For example, the C + backend does not require register allocation, instruction selection, or any of + the other standard components provided by the system. As such, it only + implements these two interfaces, and does its own thing. Another example of a + code generator like this is a (purely hypothetical) backend that converts LLVM + to the GCC RTL form and uses GCC to emit machine code for a target.

+ +

This design also implies that it is possible to design and + implement radically different code generators in the LLVM system that do not + make use of any of the built-in components. Doing so is not recommended at all, + but could be required for radically different targets that do not fit into the + LLVM machine description model: programmable FPGAs for example.

+ +

Important Note: For historical reasons, the LLVM SparcV9 code + generator uses almost entirely different code paths than described in this + document. For this reason, there are some deprecated interfaces (such as + TargetSchedInfo), which are only used by the + V9 backend and should not be used by any other targets. Also, all code in the + lib/Target/SparcV9 directory and subdirectories should be considered + deprecated, and should not be used as the basis for future code generator work. + The SparcV9 backend is slowly being merged into the rest of the + target-independent code generators, but this is a low-priority process with no + predictable completion date.

+ +
+ + + + +
+ +

The LLVM target-independent code generator is designed to support efficient and + quality code generation for standard register-based microprocessors. Code + generation in this model is divided into the following stages:

+ +
    +
  1. Instruction Selection - This phase + determines an efficient way to express the input LLVM code in the target + instruction set. + This stage produces the initial code for the program in the target instruction + set, then makes use of virtual registers in SSA form and physical registers that + represent any required register assignments due to target constraints or calling + conventions. This step turns the LLVM code into a DAG of target + instructions.
  2. + +
  3. Scheduling and Formation - This + phase takes the DAG of target instructions produced by the instruction selection + phase, determines an ordering of the instructions, then emits the instructions + as MachineInstrs with that ordering. Note + that we describe this in the instruction selection + section because it operates on a SelectionDAG. +
  4. + +
  5. SSA-based Machine Code Optimizations - This + optional stage consists of a series of machine-code optimizations that + operate on the SSA-form produced by the instruction selector. Optimizations + like modulo-scheduling or peephole optimization work here. +
  6. + +
  7. Register Allocation - The + target code is transformed from an infinite virtual register file in SSA form + to the concrete register file used by the target. This phase introduces spill + code and eliminates all virtual register references from the program.
  8. + +
  9. Prolog/Epilog Code Insertion - Once the + machine code has been generated for the function and the amount of stack space + required is known (used for LLVM alloca's and spill slots), the prolog and + epilog code for the function can be inserted and "abstract stack location + references" can be eliminated. This stage is responsible for implementing + optimizations like frame-pointer elimination and stack packing.
  10. + +
  11. Late Machine Code Optimizations - Optimizations + that operate on "final" machine code can go here, such as spill code scheduling + and peephole optimizations.
  12. + +
  13. Code Emission - The final stage actually + puts out the code for the current function, either in the target assembler + format or in machine code.
  14. + +
+ +

+ The code generator is based on the assumption that the instruction selector will + use an optimal pattern matching selector to create high-quality sequences of + native instructions. Alternative code generator designs based on pattern + expansion and + aggressive iterative peephole optimization are much slower. This design + permits efficient compilation (important for JIT environments) and + aggressive optimization (used when generating code offline) by allowing + components of varying levels of sophistication to be used for any step of + compilation.

+ +

+ In addition to these stages, target implementations can insert arbitrary + target-specific passes into the flow. For example, the X86 target uses a + special pass to handle the 80x87 floating point stack architecture. Other + targets with unusual requirements can be supported with custom passes as needed. +

+ +
+ + + + + +
+ +

The target description classes require a detailed description of the target + architecture. These target descriptions often have a large amount of common + information (e.g., an add instruction is almost identical to a + sub instruction). + In order to allow the maximum amount of commonality to be factored out, the LLVM + code generator uses the TableGen tool to + describe big chunks of the target machine, which allows the use of + domain-specific and target-specific abstractions to reduce the amount of + repetition. +

+ +

As LLVM continues to be developed and refined, we plan to move more and more + of the target description to be in .td form. Doing so gives us a + number of advantages. The most important is that it makes it easier to port + LLVM, because it reduces the amount of C++ code that has to be written and the + surface area of the code generator that needs to be understood before someone + can get in an get something working. Second, it is also important to us because + it makes it easier to change things: in particular, if tables and other things + are all emitted by tblgen, we only need to change one place (tblgen) to update + all of the targets to a new interface.

+ +
+ + + + + +
+ +

The LLVM target description classes (which are located in the + include/llvm/Target directory) provide an abstract description of the + target machine; independent of any particular client. These classes are + designed to capture the abstract properties of the target (such as the + instructions and registers it has), and do not incorporate any particular pieces + of code generation algorithms.

+ +

All of the target description classes (except the TargetData class) are designed to be subclassed by + the concrete target implementation, and have virtual methods implemented. To + get to these implementations, the TargetMachine class provides accessors that + should be implemented by the target.

+ +
+ + + + +
+ +

The TargetMachine class provides virtual methods that are used to + access the target-specific implementations of the various target description + classes via the get*Info methods (getInstrInfo, + getRegisterInfo, getFrameInfo, etc.). This class is + designed to be specialized by + a concrete target implementation (e.g., X86TargetMachine) which + implements the various virtual methods. The only required target description + class is the TargetData class, but if the + code generator components are to be used, the other interfaces should be + implemented as well.

+ +
+ + + + + +
+ +

The TargetData class is the only required target description class, + and it is the only class that is not extensible (you cannot derived a new + class from it). TargetData specifies information about how the target + lays out memory for structures, the alignment requirements for various data + types, the size of pointers in the target, and whether the target is + little-endian or big-endian.

+ +
+ + + + +
+ +

The TargetLowering class is used by SelectionDAG based instruction + selectors primarily to describe how LLVM code should be lowered to SelectionDAG + operations. Among other things, this class indicates: +

  • an initial register class to use for various ValueTypes
  • +
  • which operations are natively supported by the target machine
  • +
  • the return type of setcc operations
  • +
  • the type to use for shift amounts
  • +
  • various high-level characteristics, like whether it is profitable to turn + division by a constant into a multiplication sequence
  • +

    + +
+ + + + +
+ +

The MRegisterInfo class (which will eventually be renamed to + TargetRegisterInfo) is used to describe the register file of the + target and any interactions between the registers.

+ +

Registers in the code generator are represented in the code generator by + unsigned numbers. Physical registers (those that actually exist in the target + description) are unique small numbers, and virtual registers are generally + large. Note that register #0 is reserved as a flag value.

+ +

Each register in the processor description has an associated + TargetRegisterDesc entry, which provides a textual name for the register + (used for assembly output and debugging dumps) and a set of aliases (used to + indicate that one register overlaps with another). +

+ +

In addition to the per-register description, the MRegisterInfo class + exposes a set of processor specific register classes (instances of the + TargetRegisterClass class). Each register class contains sets of + registers that have the same properties (for example, they are all 32-bit + integer registers). Each SSA virtual register created by the instruction + selector has an associated register class. When the register allocator runs, it + replaces virtual registers with a physical register in the set.

+ +

+ The target-specific implementations of these classes is auto-generated from a TableGen description of the register file. +

+ +
+ + + + +
+

The TargetInstrInfo class is used to describe the machine + instructions supported by the target. It is essentially an array of + TargetInstrDescriptor objects, each of which describes one + instruction the target supports. Descriptors define things like the mnemonic + for the opcode, the number of operands, the list of implicit register uses + and defs, whether the instruction has certain target-independent properties + (accesses memory, is commutable, etc), and holds any target-specific flags.

+
+ + + + +
+

The TargetFrameInfo class is used to provide information about the + stack frame layout of the target. It holds the direction of stack growth, + the known stack alignment on entry to each function, and the offset to the + locals area. The offset to the local area is the offset from the stack + pointer on function entry to the first location where function data (local + variables, spill locations) can be stored.

+
+ + + + +
+

+

The TargetSubtarget class is used to provide information about the + specific chip set being targeted. A sub-target informs code generation of + which instructions are supported, instruction latencies and instruction + execution itinerary; i.e., which processing units are used, in what order, and + for how long. +

+
+ + + + + + + + + +
+ +

+ At the high-level, LLVM code is translated to a machine specific representation + formed out of MachineFunction, + MachineBasicBlock, and MachineInstr instances + (defined in include/llvm/CodeGen). This representation is completely target + agnostic, representing instructions in their most abstract form: an opcode and a + series of operands. This representation is designed to support both SSA + representation for machine code, as well as a register allocated, non-SSA form. +

+ +
+ + + + +
+ +

Target machine instructions are represented as instances of the + MachineInstr class. This class is an extremely abstract way of + representing machine instructions. In particular, it only keeps track of + an opcode number and a set of operands.

+ +

The opcode number is a simple unsigned number that only has meaning to a + specific backend. All of the instructions for a target should be defined in + the *InstrInfo.td file for the target. The opcode enum values + are auto-generated from this description. The MachineInstr class does + not have any information about how to interpret the instruction (i.e., what the + semantics of the instruction are): for that you must refer to the + TargetInstrInfo class.

+ +

The operands of a machine instruction can be of several different types: + they can be a register reference, constant integer, basic block reference, etc. + In addition, a machine operand should be marked as a def or a use of the value + (though only registers are allowed to be defs).

+ +

By convention, the LLVM code generator orders instruction operands so that + all register definitions come before the register uses, even on architectures + that are normally printed in other orders. For example, the SPARC add + instruction: "add %i1, %i2, %i3" adds the "%i1", and "%i2" registers + and stores the result into the "%i3" register. In the LLVM code generator, + the operands should be stored as "%i3, %i1, %i2": with the destination + first.

+ +

Keeping destination (definition) operands at the beginning of the operand + list has several advantages. In particular, the debugging printer will print + the instruction like this:

+ +
+   %r3 = add %i1, %i2
+ 
+ +

If the first operand is a def, and it is also easier to create instructions whose only def is the first + operand.

+ +
+ + + + +
+ +

Machine instructions are created by using the BuildMI functions, + located in the include/llvm/CodeGen/MachineInstrBuilder.h file. The + BuildMI functions make it easy to build arbitrary machine + instructions. Usage of the BuildMI functions look like this: +

+ +
+   // Create a 'DestReg = mov 42' (rendered in X86 assembly as 'mov DestReg, 42')
+   // instruction.  The '1' specifies how many operands will be added.
+   MachineInstr *MI = BuildMI(X86::MOV32ri, 1, DestReg).addImm(42);
+ 
+   // Create the same instr, but insert it at the end of a basic block.
+   MachineBasicBlock &MBB = ...
+   BuildMI(MBB, X86::MOV32ri, 1, DestReg).addImm(42);
+ 
+   // Create the same instr, but insert it before a specified iterator point.
+   MachineBasicBlock::iterator MBBI = ...
+   BuildMI(MBB, MBBI, X86::MOV32ri, 1, DestReg).addImm(42);
+ 
+   // Create a 'cmp Reg, 0' instruction, no destination reg.
+   MI = BuildMI(X86::CMP32ri, 2).addReg(Reg).addImm(0);
+   // Create an 'sahf' instruction which takes no operands and stores nothing.
+   MI = BuildMI(X86::SAHF, 0);
+ 
+   // Create a self looping branch instruction.
+   BuildMI(MBB, X86::JNE, 1).addMBB(&MBB);
+ 
+ +

+ The key thing to remember with the BuildMI functions is that you have + to specify the number of operands that the machine instruction will take. This + allows for efficient memory allocation. You also need to specify if operands + default to be uses of values, not definitions. If you need to add a definition + operand (other than the optional destination register), you must explicitly + mark it as such. +

+ +
+ + + + +
+ +

One important issue that the code generator needs to be aware of is the + presence of fixed registers. In particular, there are often places in the + instruction stream where the register allocator must arrange for a + particular value to be in a particular register. This can occur due to + limitations of the instruction set (e.g., the X86 can only do a 32-bit divide + with the EAX/EDX registers), or external factors like calling + conventions. In any case, the instruction selector should emit code that + copies a virtual register into or out of a physical register when needed.

+ +

For example, consider this simple LLVM example:

+ +
+   int %test(int %X, int %Y) {
+     %Z = div int %X, %Y
+     ret int %Z
+   }
+ 
+ +

The X86 instruction selector produces this machine code for the div + and ret (use + "llc X.bc -march=x86 -print-machineinstrs" to get this):

+ +
+         ;; Start of div
+         %EAX = mov %reg1024           ;; Copy X (in reg1024) into EAX
+         %reg1027 = sar %reg1024, 31
+         %EDX = mov %reg1027           ;; Sign extend X into EDX
+         idiv %reg1025                 ;; Divide by Y (in reg1025)
+         %reg1026 = mov %EAX           ;; Read the result (Z) out of EAX
+ 
+         ;; Start of ret
+         %EAX = mov %reg1026           ;; 32-bit return value goes in EAX
+         ret
+ 
+ +

By the end of code generation, the register allocator has coalesced + the registers and deleted the resultant identity moves, producing the + following code:

+ +
+         ;; X is in EAX, Y is in ECX
+         mov %EAX, %EDX
+         sar %EDX, 31
+         idiv %ECX
+         ret 
+ 
+ +

This approach is extremely general (if it can handle the X86 architecture, + it can handle anything!) and allows all of the target specific + knowledge about the instruction stream to be isolated in the instruction + selector. Note that physical registers should have a short lifetime for good + code generation, and all physical registers are assumed dead on entry and + exit of basic blocks (before register allocation). Thus if you need a value + to be live across basic block boundaries, it must live in a virtual + register.

+ +
+ + + + +
+ +

MachineInstr's are initially selected in SSA-form, and + are maintained in SSA-form until register allocation happens. For the most + part, this is trivially simple since LLVM is already in SSA form: LLVM PHI nodes + become machine code PHI nodes, and virtual registers are only allowed to have a + single definition.

+ +

After register allocation, machine code is no longer in SSA-form, as there + are no virtual registers left in the code.

+ +
+ + + + +
+ +

The MachineBasicBlock class contains a list of machine instructions + (MachineInstr instances). It roughly corresponds to + the LLVM code input to the instruction selector, but there can be a one-to-many + mapping (i.e. one LLVM basic block can map to multiple machine basic blocks). + The MachineBasicBlock class has a "getBasicBlock" method, which returns + the LLVM basic block that it comes from. +

+ +
+ + + + +
+ +

The MachineFunction class contains a list of machine basic blocks + (MachineBasicBlock instances). It corresponds + one-to-one with the LLVM function input to the instruction selector. In + addition to a list of basic blocks, the MachineFunction contains a + the MachineConstantPool, MachineFrameInfo, MachineFunctionInfo, + SSARegMap, and a set of live in and live out registers for the function. See + MachineFunction.h for more information. +

+ +
+ + + + + + + +
+ +

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

+ +
+ + + + +
+

+ Instruction Selection is the process of translating LLVM code presented to the + code generator into target-specific machine instructions. There are several + well-known ways to do this in the literature. In LLVM there are two main forms: + the SelectionDAG based instruction selector framework and an old-style 'simple' + instruction selector (which effectively peephole selects each LLVM instruction + into a series of machine instructions). We recommend that all targets use the + SelectionDAG infrastructure. +

+ +

Portions of the DAG instruction selector are generated from the target + description files (*.td) files. Eventually, we aim for the entire + instruction selector to be generated from these .td files.

+
+ + + + +
+ +

+ The SelectionDAG provides an abstraction for code representation in a way that + is amenable to instruction selection using automatic techniques + (e.g. dynamic-programming based optimal pattern matching selectors), It is also + well suited to other phases of code generation; in particular, + instruction scheduling (SelectionDAG's are very close to scheduling DAGs + post-selection). Additionally, the SelectionDAG provides a host representation + where a large variety of very-low-level (but target-independent) + optimizations may be + performed: ones which require extensive information about the instructions + efficiently supported by the target. +

+ +

+ The SelectionDAG is a Directed-Acyclic-Graph whose nodes are instances of the + SDNode class. The primary payload of the SDNode is its + operation code (Opcode) that indicates what operation the node performs and + the operands to the operation. + The various operation node types are described at the top of the + include/llvm/CodeGen/SelectionDAGNodes.h file.

+ +

Although most operations define a single value, each node in the graph may + define multiple values. For example, a combined div/rem operation will define + both the dividend and the remainder. Many other situations require multiple + values as well. Each node also has some number of operands, which are edges + to the node defining the used value. Because nodes may define multiple values, + edges are represented by instances of the SDOperand class, which is + a <SDNode, unsigned> pair, indicating the node and result + value being used, respectively. Each value produced by an SDNode has an + associated MVT::ValueType, indicating what type the value is. +

+ +

+ SelectionDAGs contain two different kinds of values: those that represent data + flow and those that represent control flow dependencies. Data values are simple + edges with an integer or floating point value type. Control edges are + represented as "chain" edges which are of type MVT::Other. These edges provide + an ordering between nodes that have side effects (such as + loads/stores/calls/return/etc). All nodes that have side effects should take a + token chain as input and produce a new one as output. By convention, token + chain inputs are always operand #0, and chain results are always the last + value produced by an operation.

+ +

+ A SelectionDAG has designated "Entry" and "Root" nodes. The Entry node is + always a marker node with an Opcode of ISD::EntryToken. The Root node is the + final side-effecting node in the token chain. For example, in a single basic + block function, this would be the return node. +

+ +

+ One important concept for SelectionDAGs is the notion of a "legal" vs. "illegal" + DAG. A legal DAG for a target is one that only uses supported operations and + supported types. On a 32-bit PowerPC, for example, a DAG with any values of i1, + i8, i16, + or i64 type would be illegal, as would a DAG that uses a SREM or UREM operation. + The legalize + phase is responsible for turning an illegal DAG into a legal DAG. +

+
+ + + + +
+ +

+ SelectionDAG-based instruction selection consists of the following steps: +

+ +
    +
  1. Build initial DAG - This stage performs + a simple translation from the input LLVM code to an illegal SelectionDAG. +
  2. +
  3. Optimize SelectionDAG - This stage + performs simple optimizations on the SelectionDAG to simplify it and + recognize meta instructions (like rotates and div/rem pairs) for + targets that support these meta operations. This makes the resultant code + more efficient and the 'select instructions from DAG' phase (below) simpler. +
  4. +
  5. Legalize SelectionDAG - This stage + converts the illegal SelectionDAG to a legal SelectionDAG, by eliminating + unsupported operations and data types.
  6. +
  7. Optimize SelectionDAG (#2) - This + second run of the SelectionDAG optimized the newly legalized DAG, to + eliminate inefficiencies introduced by legalization.
  8. +
  9. Select instructions from DAG - Finally, + the target instruction selector matches the DAG operations to target + instructions. This process translates the target-independent input DAG into + another DAG of target instructions.
  10. +
  11. SelectionDAG Scheduling and Formation + - The last phase assigns a linear order to the instructions in the + target-instruction DAG and emits them into the MachineFunction being + compiled. This step uses traditional prepass scheduling techniques.
  12. +
+ +

After all of these steps are complete, the SelectionDAG is destroyed and the + rest of the code generation passes are run.

+ +

One great way to visualize what is going on here is to take advantage of a + few LLC command line options. In particular, the -view-isel-dags + option pops up a window with the SelectionDAG input to the Select phase for all + of the code compiled (if you only get errors printed to the console while using + this, you probably need to configure + your system to add support for it). The -view-sched-dags option + views the SelectionDAG output from the Select phase and input to the Scheduler + phase. +

+
+ + + + +
+ +

+ The initial SelectionDAG is naively peephole expanded from the LLVM input by + the SelectionDAGLowering class in the SelectionDAGISel.cpp file. The + intent of this pass is to expose as much low-level, target-specific details + to the SelectionDAG as possible. This pass is mostly hard-coded (e.g. an LLVM + add turns into an SDNode add while a geteelementptr is expanded into the obvious + arithmetic). This pass requires target-specific hooks to lower calls and + returns, varargs, etc. For these features, the TargetLowering interface is + used. +

+ +
+ + + + +
+ +

The Legalize phase is in charge of converting a DAG to only use the types and + operations that are natively supported by the target. This involves two major + tasks:

+ +
    +
  1. Convert values of unsupported types to values of supported types.

    +

    There are two main ways of doing this: converting small types to + larger types ("promoting"), and breaking up large integer types + into smaller ones ("expanding"). For example, a target might require + that all f32 values are promoted to f64 and that all i1/i8/i16 values + are promoted to i32. The same target might require that all i64 values + be expanded into i32 values. These changes can insert sign and zero + extensions as + needed to make sure that the final code has the same behavior as the + input.

    +

    A target implementation tells the legalizer which types are supported + (and which register class to use for them) by calling the + "addRegisterClass" method in its TargetLowering constructor.

    +
  2. + +
  3. Eliminate operations that are not supported by the target.

    +

    Targets often have weird constraints, such as not supporting every + operation on every supported datatype (e.g. X86 does not support byte + conditional moves and PowerPC does not support sign-extending loads from + a 16-bit memory location). Legalize takes care by open-coding + another sequence of operations to emulate the operation ("expansion"), by + promoting to a larger type that supports the operation + (promotion), or using a target-specific hook to implement the + legalization (custom).

    +

    A target implementation tells the legalizer which operations are not + supported (and which of the above three actions to take) by calling the + "setOperationAction" method in its TargetLowering constructor.

    +
  4. +
+ +

+ Prior to the existance of the Legalize pass, we required that every + target selector supported and handled every + operator and type even if they are not natively supported. The introduction of + the Legalize phase allows all of the + cannonicalization patterns to be shared across targets, and makes it very + easy to optimize the cannonicalized code because it is still in the form of + a DAG. +

+ +
+ + + + +
+ +

+ The SelectionDAG optimization phase is run twice for code generation: once + immediately after the DAG is built and once after legalization. The first run + of the pass allows the initial code to be cleaned up (e.g. performing + optimizations that depend on knowing that the operators have restricted type + inputs). The second run of the pass cleans up the messy code generated by the + Legalize pass, which allows Legalize to be very simple (it can focus on making + code legal instead of focusing on generating good and legal code). +

+ +

+ One important class of optimizations performed is optimizing inserted sign and + zero extension instructions. We currently use ad-hoc techniques, but could move + to more rigorous techniques in the future. Here are some good + papers on the subject:

+ +

+ "Widening + integer arithmetic"
+ Kevin Redwine and Norman Ramsey
+ International Conference on Compiler Construction (CC) 2004 +

+ + +

+ "Effective + sign extension elimination"
+ Motohiro Kawahito, Hideaki Komatsu, and Toshio Nakatani
+ Proceedings of the ACM SIGPLAN 2002 Conference on Programming Language Design + and Implementation. +

+ +
+ + + + +
+ +

The Select phase is the bulk of the target-specific code for instruction + selection. This phase takes a legal SelectionDAG as input, + pattern matches the instructions supported by the target to this DAG, and + produces a new DAG of target code. For example, consider the following LLVM + fragment:

+ +
+    %t1 = add float %W, %X
+    %t2 = mul float %t1, %Y
+    %t3 = add float %t2, %Z
+ 
+ +

This LLVM code corresponds to a SelectionDAG that looks basically like this: +

+ +
+   (fadd:f32 (fmul:f32 (fadd:f32 W, X), Y), Z)
+ 
+ +

If a target supports floating point multiply-and-add (FMA) operations, one + of the adds can be merged with the multiply. On the PowerPC, for example, the + output of the instruction selector might look like this DAG:

+ +
+   (FMADDS (FADDS W, X), Y, Z)
+ 
+ +

+ The FMADDS instruction is a ternary instruction that multiplies its first two + operands and adds the third (as single-precision floating-point numbers). The + FADDS instruction is a simple binary single-precision add instruction. To + perform this pattern match, the PowerPC backend includes the following + instruction definitions: +

+ +
+ def FMADDS : AForm_1<59, 29,
+                     (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRC, F4RC:$FRB),
+                     "fmadds $FRT, $FRA, $FRC, $FRB",
+                     [(set F4RC:$FRT, (fadd (fmul F4RC:$FRA, F4RC:$FRC),
+                                            F4RC:$FRB))]>;
+ def FADDS : AForm_2<59, 21,
+                     (ops F4RC:$FRT, F4RC:$FRA, F4RC:$FRB),
+                     "fadds $FRT, $FRA, $FRB",
+                     [(set F4RC:$FRT, (fadd F4RC:$FRA, F4RC:$FRB))]>;
+ 
+ +

The portion of the instruction definition in bold indicates the pattern used + to match the instruction. The DAG operators (like fmul/fadd) + are defined in the lib/Target/TargetSelectionDAG.td file. + "F4RC" is the register class of the input and result values.

+ +

The TableGen DAG instruction selector generator reads the instruction + patterns in the .td and automatically builds parts of the pattern matching code + for your target. It has the following strengths:

+ +
    +
  • At compiler-compiler time, it analyzes your instruction patterns and tells + you if your patterns make sense or not.
  • +
  • It can handle arbitrary constraints on operands for the pattern match. In + particular, it is straight-forward to say things like "match any immediate + that is a 13-bit sign-extended value". For examples, see the + immSExt16 and related tblgen classes in the PowerPC backend.
  • +
  • It knows several important identities for the patterns defined. For + example, it knows that addition is commutative, so it allows the + FMADDS pattern above to match "(fadd X, (fmul Y, Z))" as + well as "(fadd (fmul X, Y), Z)", without the target author having + to specially handle this case.
  • +
  • It has a full-featured type-inferencing system. In particular, you should + rarely have to explicitly tell the system what type parts of your patterns + are. In the FMADDS case above, we didn't have to tell tblgen that all of + the nodes in the pattern are of type 'f32'. It was able to infer and + propagate this knowledge from the fact that F4RC has type 'f32'.
  • +
  • Targets can define their own (and rely on built-in) "pattern fragments". + Pattern fragments are chunks of reusable patterns that get inlined into your + patterns during compiler-compiler time. For example, the integer "(not x)" + operation is actually defined as a pattern fragment that expands as + "(xor x, -1)", since the SelectionDAG does not have a native 'not' + operation. Targets can define their own short-hand fragments as they see + fit. See the definition of 'not' and 'ineg' for examples.
  • +
  • In addition to instructions, targets can specify arbitrary patterns that + map to one or more instructions, using the 'Pat' class. For example, + the PowerPC has no way to load an arbitrary integer immediate into a + register in one instruction. To tell tblgen how to do this, it defines: + +
    +     // Arbitrary immediate support.  Implement in terms of LIS/ORI.
    +     def : Pat<(i32 imm:$imm),
    +               (ORI (LIS (HI16 imm:$imm)), (LO16 imm:$imm))>;
    +     
    + + If none of the single-instruction patterns for loading an immediate into a + register match, this will be used. This rule says "match an arbitrary i32 + immediate, turning it into an ORI ('or a 16-bit immediate') and an LIS + ('load 16-bit immediate, where the immediate is shifted to the left 16 + bits') instruction". To make this work, the LO16/HI16 node transformations + are used to manipulate the input immediate (in this case, take the high or + low 16-bits of the immediate). +
  • +
  • While the system does automate a lot, it still allows you to write custom + C++ code to match special cases, in case there is something that is hard + to express.
  • +
+ +

+ While it has many strengths, the system currently has some limitations, + primarily because it is a work in progress and is not yet finished: +

+ +
    +
  • Overall, there is no way to define or match SelectionDAG nodes that define + multiple values (e.g. ADD_PARTS, LOAD, CALL, etc). This is the biggest + reason that you currently still have to write custom C++ code for + your instruction selector.
  • +
  • There is no great way to support match complex addressing modes yet. In the + future, we will extend pattern fragments to allow them to define multiple + values (e.g. the four operands of the X86 addressing + mode). In addition, we'll extend fragments so that a fragment can match + multiple different patterns.
  • +
  • We don't automatically infer flags like isStore/isLoad yet.
  • +
  • We don't automatically generate the set of supported registers and + operations for the Legalizer yet.
  • +
  • We don't have a way of tying in custom legalized nodes yet.
  • +
+ +

Despite these limitations, the instruction selector generator is still quite + useful for most of the binary and logical operations in typical instruction + sets. If you run into any problems or can't figure out how to do something, + please let Chris know!

+ +
+ + + + +
+ +

The scheduling phase takes the DAG of target instructions from the selection + phase and assigns an order. The scheduler can pick an order depending on + various constraints of the machines (i.e. order for minimal register pressure or + try to cover instruction latencies). Once an order is established, the DAG is + converted to a list of MachineInstrs and the + Selection DAG is destroyed. +

+ +

Note that this phase is logically separate from the instruction selection + phase, but is tied to it closely in the code because it operates on + SelectionDAGs.

+ +
+ + + + +
+ +
    +
  1. Optional function-at-a-time selection.
  2. +
  3. Auto-generate entire selector from .td file.
  4. + +
+ +
+ + + +

To Be Written

+ + +

To Be Written

+ + +

To Be Written

+ + +

To Be Written

+ + + + + + + +
+ +
+ + + + + +
+

For the JIT or .o file writer

+
+ + + + + + +
+ +

This section of the document explains features or design decisions that + are specific to the code generator for a particular target.

+ +
+ + + + + +
+ +

+ The X86 code generator lives in the lib/Target/X86 directory. This + code generator currently targets a generic P6-like processor. As such, it + produces a few P6-and-above instructions (like conditional moves), but it does + not make use of newer features like MMX or SSE. In the future, the X86 backend + will have sub-target support added for specific processor families and + implementations.

+ +
+ + + + +
+

+ The following are the known target triples that are supported by the X86 + backend. This is not an exhaustive list, but it would be useful to add those + that people test. +

+ +
    +
  • i686-pc-linux-gnu - Linux
  • +
  • i386-unknown-freebsd5.3 - FreeBSD 5.3
  • +
  • i686-pc-cygwin - Cygwin on Win32
  • +
  • i686-pc-mingw32 - MingW on Win32
  • +
  • i686-apple-darwin* - Apple Darwin on X86
  • +
+ +
+ + + + +
+ +

The x86 has a very flexible way of accessing memory. It is capable of + forming memory addresses of the following expression directly in integer + instructions (which use ModR/M addressing):

+ +
+    Base+[1,2,4,8]*IndexReg+Disp32
+ 
+ +

In order to represent this, LLVM tracks no less than 4 operands for each + memory operand of this form. This means that the "load" form of 'mov' has the + following MachineOperands in this order:

+ +
+ Index:        0     |    1        2       3           4
+ Meaning:   DestReg, | BaseReg,  Scale, IndexReg, Displacement
+ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg,   SignExtImm
+ 
+ +

Stores, and all other instructions, treat the four memory operands in the + same way, in the same order.

+ +
+ + + + +
+ +

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

+ +

+ ADD8rr -> add, 8-bit register, 8-bit register
+ IMUL16rmi -> imul, 16-bit register, 16-bit memory, 16-bit immediate
+ IMUL16rmi8 -> imul, 16-bit register, 16-bit memory, 8-bit immediate
+ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory +

+ +
+ + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/CodingStandards.html diff -c /dev/null llvm-www/releases/1.6/docs/CodingStandards.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/CodingStandards.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,646 ---- + + + + + A Few Coding Standards + + + +
+ A Few Coding Standards +
+ +
    +
  1. Introduction
  2. +
  3. Mechanical Source Issues +
      +
    1. Source Code Formatting +
        +
      1. Commenting
      2. +
      3. Comment Formatting
      4. +
      5. #include Style
      6. +
      7. Source Code Width
      8. +
      9. Use Spaces Instead of Tabs
      10. +
      11. Indent Code Consistently
      12. +
    2. +
    3. Compiler Issues +
        +
      1. Treat Compiler Warnings Like + Errors
      2. +
      3. Write Portable Code
      4. +
      5. Use of class/struct Keywords
      6. +
    4. +
  4. +
  5. Style Issues +
      +
    1. The High Level Issues +
        +
      1. A Public Header File is a + Module
      2. +
      3. #include as Little as Possible
      4. +
      5. Keep "internal" Headers + Private
      6. +
    2. +
    3. The Low Level Issues +
        +
      1. Assert Liberally
      2. +
      3. Prefer Preincrement
      4. +
      5. Avoid std::endl
      6. +
      7. Exploit C++ to its Fullest
      8. +
    4. +
  6. +
  7. See Also
  8. +
+ +
+

Written by Chris Lattner

+
+ + + + + + +
+ +

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.

+ +
+ + + + + + + + + + + +
+ +

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:

+ + 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++ -*-===//
+ // 
+ //                     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.
+ // 
+ //===----------------------------------------------------------------------===//
+ //
+ // 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 this tag 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 next section in the file is a concise note that defines the license that + the file is released under. This makes it perfectly clear what terms the source + code can be distributed under.

+ +

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.

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

+ + + 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?

+ +
+ + + + +
+ +

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. +
  3. When writing a header file that may be #included by a C source + file.
  4. +
  5. When writing a source file that is used by a tool that only accepts C + style comments.
  6. +
+ +

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.

+ +
+ + + + +
+ +

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. +
  3. Local/Private Headers
  4. +
  5. llvm/*
  6. +
  7. llvm/Analysis/*
  8. +
  9. llvm/Assembly/*
  10. +
  11. llvm/Bytecode/*
  12. +
  13. llvm/CodeGen/*
  14. +
  15. ...
  16. +
  17. Support/*
  18. +
  19. Config/*
  20. +
  21. System #includes
  22. +
+ +

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

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + + + + + +
+ +

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

+ +
+ + + + +
+ +

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.

+ +
+ + + +
+ +

In C++, the class and struct keywords can be used almost + interchangeably. The only difference is when they are used to declare a class: + class makes all members private by default while struct makes + all members public by default.

+ +

Unfortunately, not all compilers follow the rules and some will generate + different symbols based on whether class or struct was used to + declare the symbol. This can lead to problems at link time.

+ +

So, the rule for LLVM is to always use the class keyword, unless + all members are public, in which case struct is allowed.

+ +
+ + + + + + + + + + + + + +
+ +

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

+ +
+ + + + +
+ +

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.

+ +
+ + + + + + + + +
+ +

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

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

The std::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:

+ +
+
+ std::cout << std::endl;
+ std::cout << '\n' << std::flush;
+ 
+
+ +

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

+ +
+ + + + +
+ +

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.

+ +
+ + +
+ 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. Also + interesting and useful are "More Effective C++" and "Effective STL" by the same + author.
  2. + +
  3. Large-Scale C++ + Software Design by John Lakos
  4. + +
+ +

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

+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/CommandLine.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandLine.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/CommandLine.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,1907 ---- + + + + + CommandLine 2.0 Library Manual + + + + +
+ CommandLine 2.0 Library Manual +
+ +
    +
  1. Introduction
  2. + +
  3. Quick Start Guide +
      +
    1. Boolean Arguments
    2. +
    3. Argument Aliases
    4. +
    5. Selecting an alternative from a + set of possibilities
    6. +
    7. Named alternatives
    8. +
    9. Parsing a list of options
    10. +
    11. Collecting options as a set of flags
    12. +
    13. Adding freeform text to help output
    14. +
  4. + +
  5. Reference Guide +
      +
    1. Positional Arguments +
    2. + +
    3. Internal vs External Storage
    4. + +
    5. Option Attributes
    6. + +
    7. Option Modifiers +
    8. + +
    9. Top-Level Classes and Functions +
    10. + +
    11. Builtin parsers +
    12. +
  6. +
  7. Extension Guide +
      +
    1. Writing a custom parser
    2. +
    3. Exploiting external storage
    4. +
    5. Dynamically adding command line + options
    6. +
  8. +
+ +
+

Written by Chris Lattner

+
+ + + + + +
+ +

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. + +
  3. 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.
  4. + +
  5. 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.
  6. + +
  7. 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.
  8. + +
  9. 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.
  10. + +
  11. 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...
  12. + +
  13. 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.
  14. + +
  15. 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.
  16. + +
  17. 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.
  18. + +
+ +

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.

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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, and + requires you to tell it what this mapping should be.

+ +

Lets say that we would like to add four optimization 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. + +
  3. We would have to test 4 different variables to see which ones are set.
  4. + +
  5. This doesn't map to the numeric levels that we want... so we cannot easily + see if some level >= "-O1" is enabled.
  6. + +
+ +

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"),
+    clEnumValEnd));
+ 
+ ...
+   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 "clEnumValEnd" 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"),
+    clEnumValEnd));
+ 
+ ...
+   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.

+ +
+ + + + +
+ +

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"),
+     clEnumValEnd));
+ 
+ +

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 optimization 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.

+ +
+ + + + +
+ +

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"),
+   clEnumValEnd));
+ 
+ +

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.

+ +
+ + + + +
+ +

Instead of collecting sets of options in a list, it is also possible to + gather information for enum values in a bit vector. The represention used by + the cl::bits class is an unsigned + integer. An enum value is represented by a 0/1 in the enum's ordinal value bit + position. 1 indicating that the enum was specified, 0 otherwise. As each + specified value is parsed, the resulting enum's bit is set in the option's bit + vector:

+ +
+   bits |= 1 << (unsigned)enum;
+ 
+ +

Options that are specified multiple times are redundant. Any instances after + the first are discarded.

+ +

Reworking the above list example, we could replace + cl::list with cl::bits:

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

To test to see if constprop was specified, we can use the + cl:bits::isSet function:

+ +
+   if (OptimizationBits.isSet(constprop)) {
+     ...
+   }
+ 
+ +

It's also possible to get the raw bit vector using the + cl::bits::getBits function:

+ +
+   unsigned bits = OptimizationBits.getBits();
+ 
+ +

Finally, if external storage is used, then the location specified must be of + type unsigned. In all other ways a cl::bits option is morally equivalent to a cl::list option.

+ +
+ + + + + +
+ +

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

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 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 the 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.

+ +
+ + + + + +
+ +

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

Sometimes an option can affect or modify the meaning of another option. For + example, consider gcc's -x LANG option. This tells + gcc to ignore the suffix of subsequent positional arguments and force + the file to be interpreted as if it contained source code in language + LANG. In order to handle this properly , you need to know the + absolute position of each argument, especially those in lists, so their + interaction(s) can be applied correctly. This is also useful for options like + -llibname which is actually a positional argument that starts with + a dash.

+

So, generally, the problem is that you have two cl::list variables + that interact in some way. To ensure the correct interaction, you can use the + cl::list::getPosition(optnum) method. This method returns the + absolute position (as found on the command line) of the optnum + item in the cl::list.

+

The idiom for usage is like this:

+ +
+   static cl::list<std::string> Files(cl::Positional, cl::OneOrMore);
+   static cl::listlt;std::string> Libraries("l", cl::ZeroOrMore);
+ 
+   int main(int argc, char**argv) {
+     // ...
+     std::vector<std::string>::iterator fileIt = Files.begin();
+     std::vector<std::string>::iterator libIt  = Libraries.begin();
+     unsigned libPos = 0, filePos = 0;
+     while ( 1 ) {
+       if ( libIt != Libraries.end() )
+         libPos = Libraries.getPosition( libIt - Libraries.begin() );
+       else
+         libPos = 0;
+       if ( fileIt != Files.end() )
+         filePos = Files.getPosition( fileIt - Files.begin() );
+       else
+         filePos = 0;
+ 
+       if ( filePos != 0 && (libPos == 0 || filePos < libPos) ) {
+         // Source File Is next
+         ++fileIt;
+       }
+       else if ( libPos != 0 && (filePos == 0 || libPos < filePos) ) {
+         // Library is next
+         ++libIt;
+       }
+       else
+         break; // we're done with the list
+     }
+   }
+ +

Note that, for compatibility reasons, the cl::opt also supports an + unsigned getPosition() option that will provide the absolute position + of that option. You can apply the same approach as above with a + cl::opt and a cl::list option as you can with two lists.

+
+ + + + +
+ +

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, there must not be any cl::list + positional arguments, and the cl::ConsumeAfter option should be a cl::list option.

+ +
+ + + + +
+ +

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(std::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.

+ +
+ + + + +
+ +

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 + clEnumValEnd 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. + +
    3. 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.
    4. + +
    + + You will get a compile time error if you try to use cl::values with a parser + that does not support it.
  • + +
+ +
+ + + + +
+ +

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. +
  3. Controlling the number of occurrences + required and allowed
  4. +
  5. Controlling whether or not a value must be + specified
  6. +
  7. Controlling other formatting options
  8. +
  9. Miscellaneous option modifiers
  10. +
+ +

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.

+ +
+ + + + +
+ +

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

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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, the equal sign does + not separate the value from the option name specified. Instead, the value is + everything after the prefix, including any equal sign if present. This is useful + for processing odd arguments like -lmalloc and -L/usr/lib in a + linker tool or -DNAME=value in a compiler tool. Here, the + 'l', 'D' and 'L' options are normal string (or 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();
  8. +
+ +

}

+
+ +
+ + + + +
+ +

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).
  • + +
  • The + cl::PositionalEatsArgs modifier (which only applies to + positional arguments, and only makes sense for lists) indicates that positional + argument should consume any strings after it (including strings that start with + a "-") up until another recognized positional argument. For example, if you + have two "eating" positional arguments "pos1" and "pos2" the + string "-pos1 -foo -bar baz -pos2 -bork" would cause the "-foo -bar + -baz" strings to be applied to the "-pos1" option and the + "-bork" string to be applied to the "-pos2" option.
  • + +
+ +

So far, these are the only two miscellaneous option modifiers.

+ +
+ + + + +
+ +

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 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 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 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 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::bits class is the class used to represent a list of command + line options in the form of a bit vector. It is also a templated class which + can take up to three arguments:

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

This class works the exact same as the cl::lists class, except that the second argument + must be of type unsigned if external storage is used.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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

+ +
+ namespace cl {
+   struct extrahelp;
+ }
+ 
+ +

To use the extrahelp, simply construct one with a const char* + parameter to the constructor. The text passed to the constructor will be printed + at the bottom of the help message, verbatim. Note that multiple + cl::extrahelp can be used, but this practice is discouraged. If + your tool needs to print additional help information, put all that help into a + single cl::extrahelp instance.

+

For example:

+
+   cl::extrahelp("\nADDITIONAL HELP:\n\n  This is the extra help\n");
+ 
+
+ + + + +
+ +

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

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.

+ +
+ + + + +
+ +

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

    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.

    + +
  4. + +
+ +

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.

+ +
+ + + + +
+

Several of the LLVM libraries define static cl::opt instances that + will automatically be included in any program that links with that library. + This is a feature. However, sometimes it is necessary to know the value of the + command line option outside of the library. In these cases the library does or + should provide an external storage location that is accessible to users of the + library. Examples of this include the llvm::DebugFlag exported by the + lib/Support/Debug.cpp file and the llvm::TimePassesIsEnabled + flag exported by the lib/VMCore/Pass.cpp file.

+ +

TODO: complete this section

+ +
+ + + + +
+ +

TODO: fill in this section

+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/CompilerDriver.html diff -c /dev/null llvm-www/releases/1.6/docs/CompilerDriver.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/CompilerDriver.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,823 ---- + + + + + The LLVM Compiler Driver (llvmc) + + + + + +
The LLVM Compiler Driver (llvmc)
+

NOTE: This document is a work in progress!

+
    +
  1. Abstract
  2. +
  3. Introduction +
      +
    1. Purpose
    2. +
    3. Operation
    4. +
    5. Phases
    6. +
    7. Actions
    8. +
    +
  4. +
  5. Configuration +
      +
    1. Overview
    2. +
    3. Configuration Files
    4. +
    5. Syntax
    6. +
    7. Substitutions
    8. +
    9. Sample Config File
    10. +
    +
  6. Glossary +
+
+

Written by Reid Spencer +

+
+ + + + +
+

This document describes the requirements, design, and configuration of the + LLVM compiler driver, llvmc. The compiler driver knows about LLVM's + tool set and can be configured to know about a variety of compilers for + source languages. It uses this knowledge to execute the tools necessary + to accomplish general compilation, optimization, and linking tasks. The main + purpose of llvmc is to provide a simple and consistent interface to + all compilation tasks. This reduces the burden on the end user who can just + learn to use llvmc instead of the entire LLVM tool set and all the + source language compilers compatible with LLVM.

+
+ + + +
+

The llvmc tool is a configurable compiler + driver. As such, it isn't a compiler, optimizer, + or a linker itself but it drives (invokes) other software that perform those + tasks. If you are familiar with the GNU Compiler Collection's gcc + tool, llvmc is very similar.

+

The following introductory sections will help you understand why this tool + is necessary and what it does.

+
+ + + +
+

llvmc was invented to make compilation of user programs with + LLVM-based tools easier. To accomplish this, llvmc strives to:

+
    +
  • Be the single point of access to most of the LLVM tool set.
  • +
  • Hide the complexities of the LLVM tools through a single interface.
  • +
  • Provide a consistent interface for compiling all languages.
  • +
+

Additionally, llvmc makes it easier to write a compiler for use + with LLVM, because it:

+
    +
  • Makes integration of existing non-LLVM tools simple.
  • +
  • Extends the capabilities of minimal compiler tools by optimizing their + output.
  • +
  • Reduces the number of interfaces a compiler writer must know about + before a working compiler can be completed (essentially only the VMCore + interfaces need to be understood).
  • +
  • Supports source language translator invocation via both dynamically + loadable shared objects and invocation of an executable.
  • +
+
+ + + +
+

At a high level, llvmc operation is very simple. The basic action + taken by llvmc is to simply invoke some tool or set of tools to fill + the user's request for compilation. Every execution of llvmctakes the + following sequence of steps:

+
+
Collect Command Line Options
+
The command line options provide the marching orders to llvmc + on what actions it should perform. This is the request the user is making + of llvmc and it is interpreted first. See the llvmc + manual page for details on the + options.
+
Read Configuration Files
+
Based on the options and the suffixes of the filenames presented, a set + of configuration files are read to configure the actions llvmc will + take. Configuration files are provided by either LLVM or the + compiler tools that llvmc invokes. These files determine what + actions llvmc will take in response to the user's request. See + the section on configuration for more details. +
+
Determine Phases To Execute
+
Based on the command line options and configuration files, + llvmc determines the compilation phases that + must be executed by the user's request. This is the primary work of + llvmc.
+
Determine Actions To Execute
+
Each phase to be executed can result in the + invocation of one or more actions. An action is + either a whole program or a function in a dynamically linked shared library. + In this step, llvmc determines the sequence of actions that must be + executed. Actions will always be executed in a deterministic order.
+
Execute Actions
+
The actions necessary to support the user's + original request are executed sequentially and deterministically. All + actions result in either the invocation of a whole program to perform the + action or the loading of a dynamically linkable shared library and invocation + of a standard interface function within that library.
+
Termination
+
If any action fails (returns a non-zero result code), llvmc + also fails and returns the result code from the failing action. If + everything succeeds, llvmc will return a zero result code.
+
+

llvmc's operation must be simple, regular and predictable. + Developers need to be able to rely on it to take a consistent approach to + compilation. For example, the invocation:

+ + llvmc -O2 x.c y.c z.c -o xyz +

must produce exactly the same results as:

+

+     llvmc -O2 x.c -o x.o
+     llvmc -O2 y.c -o y.o
+     llvmc -O2 z.c -o z.o
+     llvmc -O2 x.o y.o z.o -o xyz
+

To accomplish this, llvmc uses a very simple goal oriented + procedure to do its work. The overall goal is to produce a functioning + executable. To accomplish this, llvmc always attempts to execute a + series of compilation phases in the same sequence. + However, the user's options to llvmc can cause the sequence of phases + to start in the middle or finish early.

+
+ + +
Phases
+
+

llvmc breaks every compilation task into the following five + distinct phases:

+
Preprocessing
Not all languages support preprocessing; + but for those that do, this phase can be invoked. This phase is for + languages that provide combining, filtering, or otherwise altering with the + source language input before the translator parses it. Although C and C++ + are the most common users of this phase, other languages may provide their + own preprocessor (whether its the C pre-processor or not).
+
+
Translation
The translation phase converts the source + language input into something that LLVM can interpret and use for + downstream phases. The translation is essentially from "non-LLVM form" to + "LLVM form".
+
+
Optimization
Once an LLVM Module has been obtained from + the translation phase, the program enters the optimization phase. This phase + attempts to optimize all of the input provided on the command line according + to the options provided.
+
+
Linking
The inputs are combined to form a complete + program.
+
+

The following table shows the inputs, outputs, and command line options + applicable to each phase.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PhaseInputsOutputsOptions
Preprocessing
  • Source Language File
  • Source Language File
+
-E
+
Stops the compilation after preprocessing
+
Translation
    +
  • Source Language File
  • +
    +
  • LLVM Assembly
  • +
  • LLVM Bytecode
  • +
  • LLVM C++ IR
  • +
+
-c
+
Stops the compilation after translation so that optimization and + linking are not done.
+
-S
+
Stops the compilation before object code is written so that only + assembly code remains.
+
Optimization
    +
  • LLVM Assembly
  • +
  • LLVM Bytecode
  • +
    +
  • LLVM Bytecode
  • +
+
-Ox +
This group of options controls the amount of optimization + performed.
+
Linking
    +
  • LLVM Bytecode
  • +
  • Native Object Code
  • +
  • LLVM Library
  • +
  • Native Library
  • +
    +
  • LLVM Bytecode Executable
  • +
  • Native Executable
  • +
+
-L
Specifies a path for library search.
+
-l
Specifies a library to link in.
+
+
+ + +
Actions
+
+

An action, with regard to llvmc is a basic operation that it takes + in order to fulfill the user's request. Each phase of compilation will invoke + zero or more actions in order to accomplish that phase.

+

Actions come in two forms:

+
    +
  • Invokable Executables
  • +
  • Functions in a shared library
  • +
+
+ + + + +
+

This section of the document describes the configuration files used by + llvmc. Configuration information is relatively static for a + given release of LLVM and a compiler tool. However, the details may + change from release to release of either. Users are encouraged to simply use + the various options of the llvmc command and ignore the configuration + of the tool. These configuration files are for compiler writers and LLVM + developers. Those wishing to simply use llvmc don't need to understand + this section but it may be instructive on how the tool works.

+
+ + +
Overview
+
+

llvmc is highly configurable both on the command line and in + configuration files. The options it understands are generic, consistent and + simple by design. Furthermore, the llvmc options apply to the + compilation of any LLVM enabled programming language. To be enabled as a + supported source language compiler, a compiler writer must provide a + configuration file that tells llvmc how to invoke the compiler + and what its capabilities are. The purpose of the configuration files then + is to allow compiler writers to specify to llvmc how the compiler + should be invoked. Users may but are not advised to alter the compiler's + llvmc configuration.

+ +

Because llvmc just invokes other programs, it must deal with the + available command line options for those programs regardless of whether they + were written for LLVM or not. Furthermore, not all compiler tools will + have the same capabilities. Some compiler tools will simply generate LLVM assembly + code, others will be able to generate fully optimized byte code. In general, + llvmc doesn't make any assumptions about the capabilities or command + line options of a sub-tool. It simply uses the details found in the + configuration files and leaves it to the compiler writer to specify the + configuration correctly.

+ +

This approach means that new compiler tools can be up and working very + quickly. As a first cut, a tool can simply compile its source to raw + (unoptimized) bytecode or LLVM assembly and llvmc can be configured + to pick up the slack (translate LLVM assembly to bytecode, optimize the + bytecode, generate native assembly, link, etc.). In fact, the compiler tools + need not use any LLVM libraries, and it could be written in any language + (instead of C++). The configuration data will allow the full range of + optimization, assembly, and linking capabilities that LLVM provides to be added + to these kinds of tools. Enabling the rapid development of front-ends is one + of the primary goals of llvmc.

+ +

As a compiler tool matures, it may utilize the LLVM libraries and tools + to more efficiently produce optimized bytecode directly in a single compilation + and optimization program. In these cases, multiple tools would not be needed + and the configuration data for the compiler would change.

+ +

Configuring llvmc to the needs and capabilities of a source language + compiler is relatively straight-forward. A compiler writer must provide a + definition of what to do for each of the five compilation phases for each of + the optimization levels. The specification consists simply of prototypical + command lines into which llvmc can substitute command line + arguments and file names. Note that any given phase can be completely blank if + the source language's compiler combines multiple phases into a single program. + For example, quite often pre-processing, translation, and optimization are + combined into a single program. The specification for such a compiler would have + blank entries for pre-processing and translation but a full command line for + optimization.

+
+ + + + +
+

Each configuration file provides the details for a single source language + that is to be compiled. This configuration information tells llvmc + how to invoke the language's pre-processor, translator, optimizer, assembler + and linker. Note that a given source language needn't provide all these tools + as many of them exist in llvm currently.

+
+ + + +
+

llvmc always looks for files of a specific name. It uses the + first file with the name its looking for by searching directories in the + following order:
+

    +
  1. Any directory specified by the -config-dir option will be + checked first.
  2. +
  3. If the environment variable LLVM_CONFIG_DIR is set, and it contains + the name of a valid directory, that directory will be searched next.
  4. +
  5. If the user's home directory (typically /home/user contains + a sub-directory named .llvm and that directory contains a + sub-directory named etc then that directory will be tried + next.
  6. +
  7. If the LLVM installation directory (typically /usr/local/llvm + contains a sub-directory named etc then that directory will be + tried last.
  8. +
  9. A standard "system" directory will be searched next. This is typically + /etc/llvm on UNIX™ and C:\WINNT on Microsoft + Windows™.
  10. +
  11. If the configuration file sought still can't be found, llvmc + will print an error message and exit.
  12. +
+

The first file found in this search will be used. Other files with the + same name will be ignored even if they exist in one of the subsequent search + locations.

+
+ + +
+

In the directories searched, each configuration file is given a specific + name to foster faster lookup (so llvmc doesn't have to do directory searches). + The name of a given language specific configuration file is simply the same + as the suffix used to identify files containing source in that language. + For example, a configuration file for C++ source might be named + cpp, C, or cxx. For languages that support multiple + file suffixes, multiple (probably identical) files (or symbolic links) will + need to be provided.

+
+ + +
+

Which configuration files are read depends on the command line options and + the suffixes of the file names provided on llvmc's command line. Note + that the -x LANGUAGE option alters the language that llvmc + uses for the subsequent files on the command line. Only the configuration + files actually needed to complete llvmc's task are read. Other + language specific files will be ignored.

+
+ + +
Syntax
+
+

The syntax of the configuration files is very simple and somewhat + compatible with Java's property files. Here are the syntax rules:

+
    +
  • The file encoding is ASCII.
  • +
  • The file is line oriented. There should be one configuration definition + per line. Lines are terminated by the newline (0x0A) and/or carriage return + characters (0x0D)
  • +
  • A backslash (\) before a newline causes the newline to be + ignored. This is useful for line continuation of long definitions. A + backslash anywhere else is recognized as a backslash.
  • +
  • A configuration item consists of a name, an = and a value.
  • +
  • A name consists of a sequence of identifiers separated by period.
  • +
  • An identifier consists of specific keywords made up of only lower case + and upper case letters (e.g. lang.name).
  • +
  • Values come in four flavors: booleans, integers, commands and + strings.
  • +
  • Valid "false" boolean values are false False FALSE no No NO + off Off and OFF.
  • +
  • Valid "true" boolean values are true True TRUE yes Yes YES + on On and ON.
  • +
  • Integers are simply sequences of digits.
  • +
  • Commands start with a program name and are followed by a sequence of + words that are passed to that program as command line arguments. Program + arguments that begin and end with the % sign will have their value + substituted. Program names beginning with / are considered to be + absolute. Otherwise the PATH will be applied to find the program to + execute.
  • +
  • Strings are composed of multiple sequences of characters from the + character class [-A-Za-z0-9_:%+/\\|,] separated by white + space.
  • +
  • White space on a line is folded. Multiple blanks or tabs will be + reduced to a single blank.
  • +
  • White space before the configuration item's name is ignored.
  • +
  • White space on either side of the = is ignored.
  • +
  • White space in a string value is used to separate the individual + components of the string value but otherwise ignored.
  • +
  • Comments are introduced by the # character. Everything after a + # and before the end of line is ignored.
  • +
+
+ + + +
+

The table below provides definitions of the allowed configuration items + that may appear in a configuration file. Every item has a default value and + does not need to appear in the configuration file. Missing items will have the + default value. Each identifier may appear as all lower case, first letter + capitalized or all upper case.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameValue TypeDescriptionDefault

LLVMC ITEMS

versionstringProvides the version string for the contents of this + configuration file. What is accepted as a legal configuration file + will change over time and this item tells llvmc which version + should be expected.b

LANG ITEMS

lang.namestringProvides the common name for a language definition. + For example "C++", "Pascal", "FORTRAN", etc.blank
lang.opt1stringSpecifies the parameters to give the optimizer when + -O1 is specified on the llvmc command line.-simplifycfg -instcombine -mem2reg
lang.opt2stringSpecifies the parameters to give the optimizer when + -O2 is specified on the llvmc command line.TBD
lang.opt3stringSpecifies the parameters to give the optimizer when + -O3 is specified on the llvmc command line.TBD
lang.opt4stringSpecifies the parameters to give the optimizer when + -O4 is specified on the llvmc command line.TBD
lang.opt5stringSpecifies the parameters to give the optimizer when + -O5 is specified on the llvmc command line.TBD

PREPROCESSOR ITEMS

preprocessor.commandcommandThis provides the command prototype that will be used + to run the preprocessor. This is generally only used with the + -E option.<blank>
preprocessor.requiredbooleanThis item specifies whether the pre-processing phase + is required by the language. If the value is true, then the + preprocessor.command value must not be blank. With this option, + llvmc will always run the preprocessor as it assumes that the + translation and optimization phases don't know how to pre-process their + input.false

TRANSLATOR ITEMS

translator.commandcommandThis provides the command prototype that will be used + to run the translator. Valid substitutions are %in% for the + input file and %out% for the output file.<blank>
translator.outputbytecode or assemblyThis item specifies the kind of output the language's + translator generates.bytecode
translator.preprocessesbooleanIndicates that the translator also preprocesses. If + this is true, then llvmc will skip the pre-processing phase + whenever the final phase is not pre-processing.false

OPTIMIZER ITEMS

optimizer.commandcommandThis provides the command prototype that will be used + to run the optimizer. Valid substitutions are %in% for the + input file and %out% for the output file.<blank>
optimizer.outputbytecode or assemblyThis item specifies the kind of output the language's + optimizer generates. Valid values are "assembly" and "bytecode"bytecode
optimizer.preprocessesbooleanIndicates that the optimizer also preprocesses. If + this is true, then llvmc will skip the pre-processing phase + whenever the final phase is optimization or later.false
optimizer.translatesbooleanIndicates that the optimizer also translates. If + this is true, then llvmc will skip the translation phase + whenever the final phase is optimization or later.false

ASSEMBLER ITEMS

assembler.commandcommandThis provides the command prototype that will be used + to run the assembler. Valid substitutions are %in% for the + input file and %out% for the output file.<blank>
+
+ + + +
+

On any configuration item that ends in command, you must + specify substitution tokens. Substitution tokens begin and end with a percent + sign (%) and are replaced by the corresponding text. Any substitution + token may be given on any command line but some are more useful than + others. In particular each command should have both an %in% + and an %out% substitution. The table below provides definitions of + each of the allowed substitution tokens.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Substitution TokenReplacement Description
%args%Replaced with all the tool-specific arguments given + to llvmc via the -T set of options. This just allows + you to place these arguments in the correct place on the command line. + If the %args% option does not appear on your command line, + then you are explicitly disallowing the -T option for your + tool. +
%force%Replaced with the -f option if it was + specified on the llvmc command line. This is intended to tell + the compiler tool to force the overwrite of output files. +
%in%Replaced with the full path of the input file. You + needn't worry about the cascading of file names. llvmc will + create temporary files and ensure that the output of one phase is the + input to the next phase.
%opt%Replaced with the optimization options for the + tool. If the tool understands the -O options then that will + be passed. Otherwise, the lang.optN series of configuration + items will specify which arguments are to be given.
%out%Replaced with the full path of the output file. + Note that this is not necessarily the output file specified with the + -o option on llvmc's command line. It might be a + temporary file that will be passed to a subsequent phase's input. +
%stats%If your command accepts the -stats option, + use this substitution token. If the user requested -stats + from the llvmc command line then this token will be replaced + with -stats, otherwise it will be ignored. +
%target%Replaced with the name of the target "machine" for + which code should be generated. The value used here is taken from the + llvmc option -march. +
%time%If your command accepts the -time-passes + option, use this substitution token. If the user requested + -time-passes from the llvmc command line then this + token will be replaced with -time-passes, otherwise it will + be ignored. +
+
+ + + +
+

Since an example is always instructive, here's how the Stacker language + configuration file looks.

+

+ # Stacker Configuration File For llvmc
+ 
+ ##########################################################
+ # Language definitions
+ ##########################################################
+   lang.name=Stacker 
+   lang.opt1=-simplifycfg -instcombine -mem2reg
+   lang.opt2=-simplifycfg -instcombine -mem2reg -load-vn \
+     -gcse -dse -scalarrepl -sccp 
+   lang.opt3=-simplifycfg -instcombine -mem2reg -load-vn \
+     -gcse -dse -scalarrepl -sccp -branch-combine -adce \
+     -globaldce -inline -licm 
+   lang.opt4=-simplifycfg -instcombine -mem2reg -load-vn \
+     -gcse -dse -scalarrepl -sccp -ipconstprop \
+     -branch-combine -adce -globaldce -inline -licm 
+   lang.opt5=-simplifycfg -instcombine -mem2reg --load-vn \
+     -gcse -dse scalarrepl -sccp -ipconstprop \
+     -branch-combine -adce -globaldce -inline -licm \
+     -block-placement
+ 
+ ##########################################################
+ # Pre-processor definitions
+ ##########################################################
+ 
+   # Stacker doesn't have a preprocessor but the following
+   # allows the -E option to be supported
+   preprocessor.command=cp %in% %out%
+   preprocessor.required=false
+ 
+ ##########################################################
+ # Translator definitions
+ ##########################################################
+ 
+   # To compile stacker source, we just run the stacker
+   # compiler with a default stack size of 2048 entries.
+   translator.command=stkrc -s 2048 %in% -o %out% %time% \
+     %stats% %force% %args%
+ 
+   # stkrc doesn't preprocess but we set this to true so
+   # that we don't run the cp command by default.
+   translator.preprocesses=true
+ 
+   # The translator is required to run.
+   translator.required=true
+ 
+   # stkrc doesn't handle the -On options
+   translator.output=bytecode
+ 
+ ##########################################################
+ # Optimizer definitions
+ ##########################################################
+   
+   # For optimization, we use the LLVM "opt" program
+   optimizer.command=opt %in% -o %out% %opt% %time% %stats% \
+     %force% %args%
+ 
+   optimizer.required = true
+ 
+   # opt doesn't translate
+   optimizer.translates = no
+ 
+   # opt doesn't preprocess
+   optimizer.preprocesses=no
+ 
+   # opt produces bytecode
+   optimizer.output = bc
+ 
+ ##########################################################
+ # Assembler definitions
+ ##########################################################
+   assembler.command=llc %in% -o %out% %target% %time% %stats%
+ 
+
+ + + + +
+

This document uses precise terms in reference to the various artifacts and + concepts related to compilation. The terms used throughout this document are + defined below.

+
+
assembly
+
A compilation phase in which LLVM bytecode or + LLVM assembly code is assembled to a native code format (either target + specific aseembly language or the platform's native object file format). +
+ +
compiler
+
Refers to any program that can be invoked by llvmc to accomplish + the work of one or more compilation phases.
+ +
driver
+
Refers to llvmc itself.
+ +
linking
+
A compilation phase in which LLVM bytecode files + and (optionally) native system libraries are combined to form a complete + executable program.
+ +
optimization
+
A compilation phase in which LLVM bytecode is + optimized.
+ +
phase
+
Refers to any one of the five compilation phases that that + llvmc supports. The five phases are: + preprocessing, + translation, + optimization, + assembly, + linking.
+ +
source language
+
Any common programming language (e.g. C, C++, Java, Stacker, ML, + FORTRAN). These languages are distinguished from any of the lower level + languages (such as LLVM or native assembly), by the fact that a + translation phase + is required before LLVM can be applied.
+ +
tool
+
Refers to any program in the LLVM tool set.
+ +
translation
+
A compilation phase in which + source language code is translated into + either LLVM assembly language or LLVM bytecode.
+
+
+ +
+
Valid CSS!Valid HTML 4.01!Reid Spencer
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/CompilerWriterInfo.html diff -c /dev/null llvm-www/releases/1.6/docs/CompilerWriterInfo.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/CompilerWriterInfo.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,260 ---- + + + + + Architecture/platform information for compiler writers + + + +
+ Architecture/platform information for compiler writers +
+ +
+

Note: This document is a work-in-progress. Additions and clarifications + are welcome.

+
+ +
    +
  1. Hardware +
      +
    1. Alpha
    2. +
    3. ARM
    4. +
    5. Itanium
    6. +
    7. MIPS
    8. +
    9. PowerPC
    10. +
    11. SPARC
    12. +
    13. X86
    14. +
    15. Other lists
    16. +
  2. +
  3. Application Binary Interface (ABI) +
      +
    1. Linux
    2. +
    3. OS X
    4. +
  4. +
  5. Miscellaneous resources
  6. +
+ +
+

Compiled by Misha Brukman

+
+ + + + + + + + +
+ +
+ + + + + + + + + + + + + + + + + + + + +
IBM - Official manuals and docs
+ + + + +
Other documents, collections, notes
+ + + + + + + + + + + + +
AMD - Official manuals and docs
+ + + + +
Intel - Official manuals and docs
+ + + + +
Other x86-specific information
+ + + + + + +
+ + + +
+ + + + + + + + + + + + + + + + + + + + + + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Misha Brukman
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/ExtendingLLVM.html diff -c /dev/null llvm-www/releases/1.6/docs/ExtendingLLVM.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/ExtendingLLVM.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,329 ---- + + + + Extending LLVM: Adding instructions, intrinsics, types, etc. + + + + + +
+ Extending LLVM: Adding instructions, intrinsics, types, etc. +
+ +
    +
  1. Introduction and Warning
  2. +
  3. Adding a new intrinsic function
  4. +
  5. Adding a new instruction
  6. +
  7. Adding a new type +
      +
    1. Adding a new fundamental type
    2. +
    3. Adding a new derived type
    4. +
  8. +
+ +
+

Written by Misha Brukman, + Brad Jones, and Chris Lattner

+
+ + + + + +
+ +

During the course of using LLVM, you may wish to customize it for your + research project or for experimentation. At this point, you may realize that + you need to add something to LLVM, whether it be a new fundamental type, a new + intrinsic function, or a whole new instruction.

+ +

When you come to this realization, stop and think. Do you really need to + extend LLVM? Is it a new fundamental capability that LLVM does not support at + its current incarnation or can it be synthesized from already pre-existing LLVM + elements? If you are not sure, ask on the LLVM-dev list. The + reason is that extending LLVM will get involved as you need to update all the + different passes that you intend to use with your extension, and there are + many LLVM analyses and transformations, so it may be quite a bit of + work.

+ +

Adding an intrinsic function is easier than adding + an instruction, and is transparent to optimization passes which treat it as an + unanalyzable function. If your added functionality can be expressed as a + function call, an intrinsic function is the method of choice for LLVM + extension.

+ +

Before you invest a significant amount of effort into a non-trivial + extension, ask on the list if what you are + looking to do can be done with already-existing infrastructure, or if maybe + someone else is already working on it. You will save yourself a lot of time and + effort by doing so.

+ +
+ + + + + +
+ +

Adding a new intrinsic function to LLVM is much easier than adding a new + instruction. Almost all extensions to LLVM should start as an intrinsic + function and then be turned into an instruction if warranted.

+ +
    +
  1. llvm/docs/LangRef.html: + Document the intrinsic. Decide whether it is code generator specific and + what the restrictions are. Talk to other people about it so that you are + sure it's a good idea.
  2. + +
  3. llvm/include/llvm/Intrinsics.h: + add an enum in the llvm::Intrinsic namespace
  4. + +
  5. llvm/lib/VMCore/Verifier.cpp: + Add code to check the invariants of the intrinsic are respected.
  6. + +
  7. llvm/lib/VMCore/Function.cpp (Function::getIntrinsicID()): + Identify the new intrinsic function, returning the enum for the intrinsic + that you added.
  8. + +
  9. llvm/lib/Analysis/BasicAliasAnalysis.cpp: If the new intrinsic does + not access memory or does not write to memory, add it to the relevant list + of functions.
  10. + +
  11. llvm/lib/Transforms/Utils/Local.cpp: If it is possible to constant + fold your intrinsic, add support to it in the canConstantFoldCallTo and + ConstantFoldCall functions.
  12. + +
  13. Test your intrinsic
  14. + +
  15. llvm/test/Regression/*: add your test cases to the test suite
  16. +
+ +

Once the intrinsic has been added to the system, you must add code generator + support for it. Generally you must do the following steps:

+ +
+
Add support to the C backend in lib/Target/CBackend/
+ +
Depending on the intrinsic, there are a few ways to implement this. First, + if it makes sense to lower the intrinsic to an expanded sequence of C code in + all cases, just emit the expansion in visitCallInst. Second, if the + intrinsic has some way to express it with GCC (or any other compiler) + extensions, it can be conditionally supported based on the compiler compiling + the CBE output (see llvm.prefetch for an example). Third, if the intrinsic + really has no way to be lowered, just have the code generator emit code that + prints an error message and calls abort if executed. +
+ +
Add a enum value for the SelectionDAG node in + include/llvm/CodeGen/SelectionDAGNodes.h
+ +
Also, add code to lib/CodeGen/SelectionDAG/SelectionDAG.cpp (and + SelectionDAGPrinter.cpp) to print the node.
+ +
Add code to SelectionDAG/SelectionDAGISel.cpp to recognize the + intrinsic.
+ +
Presumably the intrinsic should be recognized and turned into the node you + added above.
+ +
Add code to SelectionDAG/LegalizeDAG.cpp to legalize, promote, and + expand the node as necessary.
+ +
If the intrinsic can be expanded to primitive operations, legalize can break + the node down into other elementary operations that are be supported.
+ +
Add target-specific support to specific code generators.
+ +
Extend the code generators you are interested in to recognize and support + the node, emitting the code you want.
+
+ +

+ Unfortunately, the process of extending the code generator to support a new node + is not extremely well documented. As such, it is often helpful to look at other + intrinsics (e.g. llvm.ctpop) to see how they are recognized and turned + into a node by SelectionDAGISel.cpp, legalized by + LegalizeDAG.cpp, then finally emitted by the various code generators. +

+ +
+ + + + + +
+ +

WARNING: adding instructions changes the bytecode + format, and it will take some effort to maintain compatibility with + the previous version. Only add an instruction if it is absolutely + necessary.

+ +
    + +
  1. llvm/include/llvm/Instruction.def: + add a number for your instruction and an enum name
  2. + +
  3. llvm/include/llvm/Instructions.h: + add a definition for the class that will represent your instruction
  4. + +
  5. llvm/include/llvm/Support/InstVisitor.h: + add a prototype for a visitor to your new instruction type
  6. + +
  7. llvm/lib/AsmParser/Lexer.l: + add a new token to parse your instruction from assembly text file
  8. + +
  9. llvm/lib/AsmParser/llvmAsmParser.y: + add the grammar on how your instruction can be read and what it will + construct as a result
  10. + +
  11. llvm/lib/Bytecode/Reader/Reader.cpp: + add a case for your instruction and how it will be parsed from bytecode
  12. + +
  13. llvm/lib/VMCore/Instruction.cpp: + add a case for how your instruction will be printed out to assembly
  14. + +
  15. llvm/lib/VMCore/Instructions.cpp: + implement the class you defined in + llvm/include/llvm/Instructions.h
  16. + +
  17. Test your instruction
  18. + +
  19. llvm/lib/Target/*: + Add support for your instruction to code generators, or add a lowering + pass.
  20. + +
  21. llvm/test/Regression/*: add your test cases to the test suite.
  22. + +
+ +

Also, you need to implement (or modify) any analyses or passes that you want + to understand this new instruction.

+ +
+ + + + + + +
+ +

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

+ +
+ + + + +
+ +
    + +
  1. llvm/include/llvm/Type.h: + add enum for the new type; add static Type* for this type
  2. + +
  3. llvm/lib/VMCore/Type.cpp: + add mapping from TypeID => Type*; + initialize the static Type*
  4. + +
  5. llvm/lib/AsmReader/Lexer.l: + add ability to parse in the type from text assembly
  6. + +
  7. llvm/lib/AsmReader/llvmAsmParser.y: + add a token for that type
  8. + +
+ +
+ + + + +
+ +
    +
  1. llvm/include/llvm/Type.h: + add enum for the new type; add a forward declaration of the type + also
  2. + +
  3. llvm/include/llvm/DerivedType.h: + add new class to represent new class in the hierarchy; add forward + declaration to the TypeMap value type
  4. + +
  5. llvm/lib/VMCore/Type.cpp: + add support for derived type to: +
    +
    + std::string getTypeDescription(const Type &Ty,
    +   std::vector<const Type*> &TypeStack)
    + bool TypesEqual(const Type *Ty, const Type *Ty2,
    +   std::map<const Type*, const Type*> & EqTypes)
    + 
    +
    + add necessary member functions for type, and factory methods
  6. + +
  7. llvm/lib/AsmReader/Lexer.l: + add ability to parse in the type from text assembly
  8. + +
  9. llvm/lib/ByteCode/Writer/Writer.cpp: + modify void BytecodeWriter::outputType(const Type *T) to serialize + your type
  10. + +
  11. llvm/lib/ByteCode/Reader/Reader.cpp: + modify const Type *BytecodeReader::ParseType() to read your data + type
  12. + +
  13. llvm/lib/VMCore/AsmWriter.cpp: + modify +
    +
    + void calcTypeName(const Type *Ty,
    +                   std::vector<const Type*> &TypeStack,
    +                   std::map<const Type*,std::string> &TypeNames,
    +                   std::string & Result)
    + 
    +
    + to output the new derived type +
  14. + + +
+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + The LLVM Compiler Infrastructure +
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/FAQ.html diff -c /dev/null llvm-www/releases/1.6/docs/FAQ.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/FAQ.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,581 ---- + + + + 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. +
    3. Does the University of Illinois Open Source License really qualify as an + "open source" license?
    4. +
    5. Can I modify LLVM source code and redistribute the modified source?
    6. +
    7. Can I modify LLVM source code and redistribute binaries or other tools + based on it, without redistributing the source?
    8. +
  2. + +
  3. Source code +
      +
    1. In what language is LLVM written?
    2. +
    3. How portable is the LLVM source code?
    4. +
  4. + +
  5. Build Problems +
      +
    1. When I run configure, it finds the wrong C compiler.
    2. +
    3. I compile the code, and I get some error about /localhome.
    4. +
    5. The configure script finds the right C compiler, but it uses the + LLVM linker from a previous build. What do I do?
    6. +
    7. When creating a dynamic library, I get a strange GLIBC error.
    8. +
    9. I've updated my source tree from CVS, and now my build is trying to use a + file/directory that doesn't exist.
    10. +
    11. I've modified a Makefile in my source tree, but my build tree keeps using + the old version. What do I do?
    12. +
    13. I've upgraded to a new version of LLVM, and I get strange build + errors.
    14. +
    15. I've built LLVM and am testing it, but the tests freeze.
    16. +
    17. Why do test results differ when I perform different types of builds?
    18. +
    19. Compiling LLVM with GCC 3.3.2 fails, what should I do?
    20. +
    21. When I use the test suite, all of the C Backend tests fail. What is + wrong?
    22. +
    23. After CVS update, rebuilding gives the error "No rule to make + target".
    24. +
  6. + +
  7. 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. + +
    3. + When I compile code using the LLVM GCC front end, it complains that it + cannot find libcrtend.a. +
    4. + +
    5. + How can I disable all optimizations when compiling code using the LLVM GCC front end? +
    6. + +
    +
  8. + +
  9. Questions about code generated by the GCC front-end +
      +
    1. What is this __main() call that gets inserted into + main()?
    2. +
    3. What is this llvm.global_ctors and + _GLOBAL__I__tmp_webcompile... stuff that happens when I + #include <iostream>?
    4. +
    5. Where did all of my code go??
    6. +
    7. What is this "undef" thing that shows up in my code?
    8. +
    +
  10. +
+ +
+

Written by The LLVM Team

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

+
+ + + + + +
+

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

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. + +
  3. Run configure with an alternative PATH that is + correct. In a Borne compatible shell, the syntax would be:

    + +

    PATH=[the path without the bad program] ./configure ...

    + +

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

  4. + +
+ +
+ +
+

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.

+
+ +
+

After CVS update, rebuilding gives the error "No rule to make target".

+
+ +
+

If the error is of the form:

+ +
+ + gmake[2]: *** No rule to make target `/path/to/somefile', needed by + `/path/to/another/file.d'.
+ Stop. +
+
+ +

This may occur anytime files are moved within the CVS repository or removed + entirely. In this case, the best solution is to erase all .d files, + which list dependencies for source files, and rebuild:

+ +
+
+ % cd $LLVM_OBJ_DIR
+ % rm -f `find . -name \*\.d` 
+ % gmake 
+ 
+
+ +

In other cases, it may be necessary to run make clean before + rebuilding.

+
+ + + + +
+

+ 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. + +
  3. + Make sure that the regular C compiler is first in your PATH. +
  4. + +
  5. + Add the string "-Wl,-native" to your CFLAGS environment variable. +
  6. +
+ +

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

+
+ +
+

+ The only way this can happen is if you haven't installed the runtime library. To + correct this, do:

+
+   % cd llvm/runtime
+   % make clean ; make install-bytecode
+ 
+
+ +
+

+ How can I disable all optimizations when compiling code using the LLVM GCC front end? +

+
+ +
+

+ Passing "-Wa,-disable-opt -Wl,-disable-opt" will disable *all* cleanup and + optimizations done at the llvm level, leaving you with the truly horrible + code that you desire. +

+
+ + + + +

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

+
+ + + +
+ +

What is this llvm.global_ctors and + _GLOBAL__I__tmp_webcompile... stuff that happens when I #include + <iostream>?

+
+ +
+ +

If you #include the <iostream> header into a C++ translation unit, the + file will probably use the std::cin/std::cout/... global + objects. However, C++ does not guarantee an order of initialization between + static objects in different translation units, so if a static ctor/dtor in your + .cpp file used std::cout, for example, the object would not necessarily + be automatically initialized before your use.

+ +

To make std::cout and friends work correctly in these scenarios, the + STL that we use declares a static object that gets created in every translation + unit that includes <iostream>. This object has a static + constructor and destructor that initializes and destroys the global iostream + objects before they could possibly be used in the file. The code that you see + in the .ll file corresponds to the constructor and destructor registration code. +

+ +

If you would like to make it easier to understand the LLVM code + generated by the compiler in the demo page, consider using printf() + instead of iostreams to print values.

+ +
+ + + +

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

+
+ + + +

+ +

What is this "undef" thing that shows up in my code? +

+ +
+

+ undef is the LLVM way of representing + a value that is not defined. You can get these if you do not initialize a + variable before you use it. For example, the C function:

+ +
+ int X() { int i; return i; } +
+ +

Is compiled to "ret int undef" because "i" never has a value + specified for it. +

+
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/GarbageCollection.html diff -c /dev/null llvm-www/releases/1.6/docs/GarbageCollection.html:1.1 *** /dev/null Tue Nov 8 14:06:46 2005 --- llvm-www/releases/1.6/docs/GarbageCollection.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,533 ---- + + + + Accurate Garbage Collection with LLVM + + + + +
+ Accurate Garbage Collection with LLVM +
+ +
    +
  1. Introduction + +
  2. + +
  3. Interfaces for user programs + +
  4. + +
  5. Implementing a garbage collector + +
  6. +
  7. GC implementations available + +
  8. + + +
+ +
+

Written by Chris Lattner

+
+ + + + + +
+ +

Garbage collection is a widely used technique that frees the programmer from + having to know the life-times of heap objects, making software easier to produce + and maintain. Many programming languages rely on garbage collection for + automatic memory management. There are two primary forms of garbage collection: + conservative and accurate.

+ +

Conservative garbage collection often does not require any special support + from either the language or the compiler: it can handle non-type-safe + programming languages (such as C/C++) and does not require any special + information from the compiler. The [LINK] Boehm collector is an example of a + state-of-the-art conservative collector.

+ +

Accurate garbage collection requires the ability to identify all pointers in + the program at run-time (which requires that the source-language be type-safe in + most cases). Identifying pointers at run-time requires compiler support to + locate all places that hold live pointer variables at run-time, including the + processor stack and registers.

+ +

+ Conservative garbage collection is attractive because it does not require any + special compiler support, but it does have problems. In particular, because the + conservative garbage collector cannot know that a particular word in the + machine is a pointer, it cannot move live objects in the heap (preventing the + use of compacting and generational GC algorithms) and it can occasionally suffer + from memory leaks due to integer values that happen to point to objects in the + program. In addition, some aggressive compiler transformations can break + conservative garbage collectors (though these seem rare in practice). +

+ +

+ Accurate garbage collectors do not suffer from any of these problems, but they + can suffer from degraded scalar optimization of the program. In particular, + because the runtime must be able to identify and update all pointers active in + the program, some optimizations are less effective. In practice, however, the + locality and performance benefits of using aggressive garbage allocation + techniques dominates any low-level losses. +

+ +

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

+ +
+ + + + +
+ +

+ LLVM provides support for a broad class of garbage collection algorithms, + including compacting semi-space collectors, mark-sweep collectors, generational + collectors, and even reference counting implementations. It includes support + for read and write barriers, and associating meta-data with stack objects (used for tagless garbage + collection). All LLVM code generators support garbage collection, including the + C backend. +

+ +

+ We hope that the primitive support built into LLVM is sufficient to support a + broad class of garbage collected languages, including Scheme, ML, scripting + languages, Java, C#, etc. That said, the implemented garbage collectors may + need to be extended to support language-specific features such as finalization, + weak references, or other features. As these needs are identified and + implemented, they should be added to this specification. +

+ +

+ LLVM does not currently support garbage collection of multi-threaded programs or + GC-safe points other than function calls, but these will be added in the future + as there is interest. +

+ +
+ + + + + +
+ +

This section describes the interfaces provided by LLVM and by the garbage + collector run-time that should be used by user programs. As such, this is the + interface that front-end authors should generate code for. +

+ +
+ + + + +
+ +
+ void %llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata) +
+ +

+ The llvm.gcroot intrinsic is used to inform LLVM of a pointer variable + on the stack. The first argument contains the address of the variable on the + stack, and the second contains a pointer to metadata that should be associated + with the pointer (which must be a constant or global value address). At + runtime, the llvm.gcroot intrinsic stores a null pointer into the + specified location to initialize the pointer.

+ +

+ Consider the following fragment of Java code: +

+ +
+        {
+          Object X;   // A null-initialized reference to an object
+          ...
+        }
+ 
+ +

+ This block (which may be located in the middle of a function or in a loop nest), + could be compiled to this LLVM code: +

+ +
+ Entry:
+    ;; In the entry block for the function, allocate the
+    ;; stack space for X, which is an LLVM pointer.
+    %X = alloca %Object*
+    ...
+ 
+    ;; "CodeBlock" is the block corresponding to the start
+    ;;  of the scope above.
+ CodeBlock:
+    ;; Initialize the object, telling LLVM that it is now live.
+    ;; Java has type-tags on objects, so it doesn't need any
+    ;; metadata.
+    call void %llvm.gcroot(%Object** %X, sbyte* null)
+    ...
+ 
+    ;; As the pointer goes out of scope, store a null value into
+    ;; it, to indicate that the value is no longer live.
+    store %Object* null, %Object** %X
+    ...
+ 
+ +
+ + + + +
+ +
+ sbyte *%llvm_gc_allocate(unsigned %Size) +
+ +

The llvm_gc_allocate function is a global function defined by the + garbage collector implementation to allocate memory. It returns a + zeroed-out block of memory of the appropriate size.

+ +
+ + + + +
+ +
+ sbyte *%llvm.gcread(sbyte *, sbyte **)
+ void %llvm.gcwrite(sbyte*, sbyte*, sbyte**) +
+ +

Several of the more interesting garbage collectors (e.g., generational + collectors) need to be informed when the mutator (the program that needs garbage + collection) reads or writes object references into the heap. In the case of a + generational collector, it needs to keep track of which "old" generation objects + have references stored into them. The amount of code that typically needs to be + executed is usually quite small (and not on the critical path of any + computation), so the overall performance impact of the inserted code is + tolerable.

+ +

To support garbage collectors that use read or write barriers, LLVM provides + the llvm.gcread and llvm.gcwrite intrinsics. The first + intrinsic has exactly the same semantics as a non-volatile LLVM load and the + second has the same semantics as a non-volatile LLVM store, with the + additions that they also take a pointer to the start of the memory + object as an argument. At code generation + time, these intrinsics are replaced with calls into the garbage collector + (llvm_gc_read and llvm_gc_write respectively), which are then + inlined into the code. +

+ +

+ If you are writing a front-end for a garbage collected language, every load or + store of a reference from or to the heap should use these intrinsics instead of + normal LLVM loads/stores.

+ +
+ + + + +
+ +
+ void %llvm_gc_initialize(unsigned %InitialHeapSize) +
+ +

+ The llvm_gc_initialize function should be called once before any other + garbage collection functions are called. This gives the garbage collector the + chance to initialize itself and allocate the heap spaces. The initial heap size + to allocate should be specified as an argument. +

+ +
+ + + + +
+ +
+ void %llvm_gc_collect() +
+ +

+ The llvm_gc_collect function is exported by the garbage collector + implementations to provide a full collection, even when the heap is not + exhausted. This can be used by end-user code as a hint, and may be ignored by + the garbage collector. +

+ +
+ + + + + + +
+ +

+ Implementing a garbage collector for LLVM is fairly straight-forward. The LLVM + garbage collectors are provided in a form that makes them easy to link into the + language-specific runtime that a language front-end would use. They require + functionality from the language-specific runtime to get information about where pointers are located in heap objects. +

+ +

The + implementation must include the llvm_gc_allocate and llvm_gc_collect functions, and it must implement + the read/write barrier functions as well. To + do this, it will probably have to trace through the roots + from the stack and understand the GC descriptors + for heap objects. Luckily, there are some example + implementations available. +

+
+ + + + + +
+
+ void *llvm_gc_read(void*, void **)
+ void llvm_gc_write(void*, void *, void**) +
+ +

+ These functions must be implemented in every garbage collector, even if + they do not need read/write barriers. In this case, just load or store the + pointer, then return. +

+ +

+ If an actual read or write barrier is needed, it should be straight-forward to + implement it. +

+ +
+ + + + +
+

+ Garbage collector implementations make use of call-back functions that are + implemented by other parts of the LLVM system. +

+
+ + + + +
+
+ void llvm_cg_walk_gcroots(void (*FP)(void **Root, void *Meta)); +
+ +

+ The llvm_cg_walk_gcroots function is a function provided by the code + generator that iterates through all of the GC roots on the stack, calling the + specified function pointer with each record. For each GC root, the address of + the pointer and the meta-data (from the llvm.gcroot intrinsic) are provided. +

+
+ + + + +
+ TODO +
+ + + + + +
+

+ The three most common ways to keep track of where pointers live in heap objects + are (listed in order of space overhead required):

+ +
    +
  1. In languages with polymorphic objects, pointers from an object header are + usually used to identify the GC pointers in the heap object. This is common for + object-oriented languages like Self, Smalltalk, Java, or C#.
  2. + +
  3. If heap objects are not polymorphic, often the "shape" of the heap can be + determined from the roots of the heap or from some other meta-data [Appel89, Goldberg91, Tolmach94]. In this case, the garbage collector can + propagate the information around from meta data stored with the roots. This + often eliminates the need to have a header on objects in the heap. This is + common in the ML family.
  4. + +
  5. If all heap objects have pointers in the same locations, or pointers can be + distinguished just by looking at them (e.g., the low order bit is clear), no + book-keeping is needed at all. This is common for Lisp-like languages.
  6. +
+ +

The LLVM garbage collectors are capable of supporting all of these styles of + language, including ones that mix various implementations. To do this, it + allows the source-language to associate meta-data with the stack roots, and the heap tracing routines can propagate the + information. In addition, LLVM allows the front-end to extract GC information + from in any form from a specific object pointer (this supports situations #1 and + #3). +

+ +

Making this efficient

+ + + +
+ + + + + + + +
+ +

+ To make this more concrete, the currently implemented LLVM garbage collectors + all live in the llvm/runtime/GC/* directories in the LLVM source-base. + If you are interested in implementing an algorithm, there are many interesting + possibilities (mark/sweep, a generational collector, a reference counting + collector, etc), or you could choose to improve one of the existing algorithms. +

+ +
+ + + + +
+

+ SemiSpace is a very simple copying collector. When it starts up, it allocates + two blocks of memory for the heap. It uses a simple bump-pointer allocator to + allocate memory from the first block until it runs out of space. When it runs + out of space, it traces through all of the roots of the program, copying blocks + to the other half of the memory space. +

+ +
+ + +
+ Possible Improvements +
+ +
+ +

+ If a collection cycle happens and the heap is not compacted very much (say less + than 25% of the allocated memory was freed), the memory regions should be + doubled in size.

+ +
+ + + + + +
+ +

[Appel89] Runtime Tags Aren't Necessary. Andrew + W. Appel. Lisp and Symbolic Computation 19(7):703-705, July 1989.

+ +

[Goldberg91] Tag-free garbage collection for + strongly typed programming languages. Benjamin Goldberg. ACM SIGPLAN + PLDI'91.

+ +

[Tolmach94] Tag-free garbage collection using + explicit type parameters. Andrew Tolmach. Proceedings of the 1994 ACM + conference on LISP and functional programming.

+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/GettingStarted.html diff -c /dev/null llvm-www/releases/1.6/docs/GettingStarted.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/GettingStarted.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,1546 ---- + + + + + Getting Started with LLVM System + + + + +
+ Getting Started with the LLVM System +
+ + + +
+

Written by: + John Criswell, + Chris Lattner, + Misha Brukman, + Vikram Adve, and + Guochun Shi. +

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

+ +

+ There is a third, optional piece called llvm-test. It is a suite of programs + with a testing harness that can be used to further test LLVM's functionality + and performance. +

+ +
+ + + + + +
+ +

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

+ +
    +
  1. Read the documentation.
  2. +
  3. Read the documentation.
  4. +
  5. Remember that you were warned twice about reading the documentation.
  6. +
  7. Install the GCC front end if you intend to compile C or C++: +
      +
    1. cd where-you-want-the-C-front-end-to-live
    2. +
    3. gunzip --stdout cfrontend.platform.tar.gz | tar -xvf - +
    4. +
    5. cd cfrontend/platform
      + ./fixheaders
    6. +
    7. Add the cfrontend's "bin" directory to your PATH variable.
    8. +
  8. + +
  9. Get the LLVM Source Code +
      +
    • With the distributed files (or use CVS): +
        +
      1. cd where-you-want-llvm-to-live +
      2. gunzip --stdout llvm-version.tar.gz | tar -xvf - +
    • + +
  10. + +
  11. [Optional] Get the Test Suite Source Code +
      +
    • With the distributed files (or use CVS): +
        +
      1. cd where-you-want-llvm-to-live +
      2. cd llvm/projects +
      3. gunzip --stdout llvm-test-version.tar.gz | tar -xvf - +
    • + +
  12. + + +
  13. Configure the LLVM Build Environment +
      +
    1. cd where-you-want-to-build-llvm
    2. +
    3. /path/to/llvm/configure [options]
      + Some common options: + +
        +
      • --prefix=directory +

        Specify for directory the full pathname of where you + want the LLVM tools and libraries to be installed (default + /usr/local).

      • +
      • --with-llvmgccdir=directory +

        Optionally, specify for directory the full pathname of the + C/C++ front end installation to use with this LLVM configuration. If + not specified, the PATH will be searched.

      • +
      • --enable-spec2000=directory +

        Enable the SPEC2000 benchmarks for testing. The SPEC2000 + benchmarks should be available in + directory.

      • +
      +
  14. + +
  15. Build the LLVM Suite: +
      +
    1. gmake -k |& tee gnumake.out +    # this is csh or tcsh syntax
    2. +
    3. If you get an "internal compiler error (ICE)" see below.
    4. +
    + +
+ +

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.

+ +
+ + + + + +
+ +

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:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OSArchCompilers
Linuxx861GCC
SolarisV9 (Ultrasparc)GCC
FreeBSDx861GCC
MacOS X2PowerPCGCC
Cygwin/Win32x861GCC 3.4.X, binutils 2.15
MinGW/Win32x861,6GCC 3.4.X, binutils 2.15
Linuxamd643GCC
+ +

LLVM has partial support for the following platforms:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
OSArchCompilers
Windowsx861Visual Studio .NET4,5
AIX3,4PowerPCGCC
Linux3,5PowerPCGCC
Linux7AlphaGCC
Linux7Itanium (IA-64)GCC
HP-UX7Itanium (IA-64)HP aCC
+ +

Notes:

+ + + +

Note that you will need about 1-3 GB of space for a full LLVM build in Debug + mode, depending on the system (it is so large because of all the debugging + information and the fact that the libraries are statically linked into multiple + tools). If you do not need many of the tools and you are space-conscious, + you can disable them individually in llvm/tools/Makefile. The Release + build requires considerably less space.

+ +

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.

+ +
+ + + +
+

Compiling LLVM requires that you have several software packages + installed. The table below lists those required packages. The Package column + is the usual name for the software package that LLVM depends on. The Version + column provides "known to work" versions of the package. The Notes column + describes how LLVM uses the package and provides other details.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
PackageVersionNotes
GNU Make3.79, 3.79.1Makefile/build processor
GCC3.4.2C/C++ compiler1
TeXinfo4.5For building the CFE
Flex2.5.4LEX compiler
Bison1.28, 1.35, 1.75, or 2.0 (not 1.85)YACC compiler
CVS≥1.11CVS access to LLVM2
DejaGnu1.4.2Automated test suite3
tcl8.3, 8.4Automated test suite3
expect5.38.0Automated test suite3
perl≥5.6.0Nightly tester, utilities
GNU M4 + 1.4Macro processor for configuration4
GNU Autoconf2.59Configuration script builder4
GNU Automake1.9.2aclocal macro generator4
libtool1.5.10Shared library manager4
+ +

Notes:

+ + +

Additionally, your compilation host is expected to have the usual + plethora of Unix utilities. Specifically:

+
    +
  • ar - archive library builder
  • +
  • bzip2* - bzip2 command for distribution generation
  • +
  • bunzip2* - bunzip2 command for distribution checking
  • +
  • chmod - change permissions on a file
  • +
  • cat - output concatenation utility
  • +
  • cp - copy files
  • +
  • date - print the current date/time
  • +
  • echo - print to standard output
  • +
  • egrep - extended regular expression search utility
  • +
  • etags - C/C++ tag file creator for vim/emacs
  • +
  • find - find files/dirs in a file system
  • +
  • grep - regular expression search utility
  • +
  • gzip* - gzip command for distribution generation
  • +
  • gunzip* - gunzip command for distribution checking
  • +
  • install - install directories/files
  • +
  • mkdir - create a directory
  • +
  • mv - move (rename) files
  • +
  • ranlib - symbol table builder for archive libraries
  • +
  • rm - remove (delete) files and directories
  • +
  • sed - stream editor for transforming output
  • +
  • sh - Bourne shell for make build scripts
  • +
  • tar - tape archive for distribution generation
  • +
  • test - test things in file system
  • +
  • unzip* - unzip command for distribution checking
  • +
  • zip* - zip command for distribution generation
  • +
+
+ + + + +
+ +

LLVM is very demanding of the host C++ compiler, and as such tends to expose + bugs in the compiler. In particular, several versions of GCC crash when trying + to compile LLVM. We routinely use GCC 3.3.3 and GCC 3.4.0 and have had success + with them (however, see below). Other versions of GCC will probably + work as well. GCC versions listed + here are known to not work. If you are using one of these versions, please try + to upgrade your GCC to something more recent. If you run into a problem with a + version of GCC not listed here, please let + us know. Please use the "gcc -v" command to find out which version + of GCC you are using. +

+ +

GCC versions prior to 3.0: GCC 2.96.x and before had several + problems in the STL that effectively prevent it from compiling LLVM. +

+ +

GCC 3.2.2: This version of GCC fails to compile LLVM.

+ +

GCC 3.3.2: This version of GCC suffered from a serious bug which causes it to crash in + the "convert_from_eh_region_ranges_1" GCC function.

+ +

Cygwin GCC 3.3.3: The version of GCC 3.3.3 commonly shipped with + Cygwin does not work. Please upgrade + to a newer version if possible.

+

SuSE GCC 3.3.3: The version of GCC 3.3.3 shipped with SuSE 9.1 (and + possibly others) does not compile LLVM correctly (it appears that exception + handling is broken in some cases). Please download the FSF 3.3.3 or upgrade + to a newer version of GCC.

+

IA-64 GCC 4.0.0: The IA-64 version of GCC 4.0.0 is known to + miscompile LLVM.

+
+ + + + + + + +
+ +

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

+ +

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.

+
+ + + + +
+ +

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 where the LLVM GCC Front End is installed. +

+ For the pre-built GCC front end binaries, the LLVMGCCDIR is + cfrontend/platform/llvm-gcc. +

+ +
+ + + + +
+ +

+ In order to compile and use LLVM, you may need to set some environment + variables. + +

+
LLVM_LIB_SEARCH_PATH=/path/to/your/bytecode/libs
+
[Optional] This environment variable helps LLVM linking tools find the + locations of your bytecode libraries. It is provided only as a + convenience since you can specify the paths using the -L options of the + tools and the C/C++ front-end will automatically use the bytecode files + installed in its + lib directory.
+
+ +
+ + + + +
+ +

+ 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. There is an + additional test suite that is optional. Each file is a TAR archive that is + compressed with the gzip program. +

+ +

The files are as follows, with x.y marking the version number: +

+
llvm-x.y.tar.gz
+
Source release for the LLVM libraries and tools.
+ +
llvm-test-x.y.tar.gz
+
Source release for the LLVM test suite.
+ +
cfrontend-x.y.source.tar.gz
+
Source release of the GCC front end.
+ +
cfrontend-x.y.sparc-sun-solaris2.8.tar.gz
+
Binary release of the GCC front end for Solaris/Sparc. +
+ +
cfrontend-x.y.i686-redhat-linux-gnu.tar.gz
+
Binary release of the GCC front end for Linux/x86.
+ +
cfrontend-x.y.i386-unknown-freebsd5.1.tar.gz
+
Binary release of the GCC front end for FreeBSD/x86.
+ +
cfrontend-x.y.powerpc-apple-darwin7.8.0.tar.gz
+
Binary release of the GCC front end for MacOS X/PPC.
+
+ +
+ + + + +
+ +

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 + labels:

+ +
    +
  • Release 1.5: RELEASE_15
  • +
  • Release 1.4: RELEASE_14
  • +
  • Release 1.3: RELEASE_13
  • +
  • Release 1.2: RELEASE_12
  • +
  • Release 1.1: RELEASE_11
  • +
  • Release 1.0: RELEASE_1
  • +
+ +

If you would like to get the LLVM test suite (a separate package as of 1.4), + you get it from the CVS repository:

+
+   cd llvm/projects
+   cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm co llvm-test
+ 
+

By placing it in the llvm/projects, it will be automatically + configured by the LLVM configure script as well as automatically updated when + you run cvs update.

+ +

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

Please note that you must follow these + instructions to successfully build the LLVM GCC front-end.

+ +
+ + + + +
+ +

If the main CVS server is overloaded or inaccessible, you can try one of + these user-hosted mirrors:

+ + +
+ + + + +
+ +

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. +
  3. gunzip --stdout cfrontend-version.platform.tar.gz | tar -xvf + -
  4. +
+ +

Next, you will need to fix your system 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.

+ +
+ + + + +
+ +

Once checked out from the CVS repository, the LLVM suite source code must be + configured via the configure script. This script sets variables in the + various *.in files, most notably 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
+
Path to the LLVM C/C++ FrontEnd to be used with this LLVM configuration. + The value of this option should specify the full pathname of the C/C++ Front + End to be used. If this option is not provided, the PATH will be searched for + a program named llvm-gcc and the C/C++ FrontEnd install directory will + be inferred from the path found. If the option is not given, and no llvm-gcc + can be found in the path then a warning will be produced by + configure indicating this situation. LLVM may still be built with + the tools-only target but attempting to build the runtime libraries + will fail as these libraries require llvm-gcc and llvm-g++. See + Install the GCC Front End for details on installing + the C/C++ Front End. See + Bootstrapping the LLVM C/C++ Front-End + for details on building the C/C++ Front End.
+
--with-tclinclude
+
Path to the tcl include directory under which tclsh can be + found. Use this if you have multiple tcl installations on your machine and you + want to use a specific one (8.x) for LLVM. LLVM only uses tcl for running the + dejagnu based test suite in llvm/test. If you don't specify this + option, the LLVM configure script will search for the tcl 8.4 and 8.3 + releases. +

+
+
--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-targets=target-option
+
Controls which targets will be built and linked into llc. The default + value for target_options is "all" which builds and links all + available targets. The value "host-only" can be specified to build only a + native compiler (no cross-compiler targets available). The "native" target is + selected as the target of the build host. You can also specify a comma + separated list of target names that you want available in llc. The target + names use all lower case. The current set of targets is:
+ alpha, ia64, powerpc, skeleton, sparc, x86. +

+
--enable-doxygen
+
Look for the doxygen program and enable construction of doxygen based + documentation from the source code. This is disabled by default because + generating the documentation can take a long time and producess 100s of + megabytes of output.
+
+ +

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 --prefix=/install/path [other options] +

    +

+ +
+ + + + +
+ +

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 the build fails, please check here to see if you + are using a version of GCC that is known not to compile LLVM.

+ +

+ 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 dist-clean +
+ 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 header files, libraries, tools, and documentation in a + hierarchy + under $PREFIX, specified with ./configure --prefix=[dir], which + defaults to /usr/local. +

+ +

gmake -C runtime install-bytecode +
+ Assuming you built LLVM into $OBJDIR, when this command is run, it will + 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. +

+

+ +

Please see the Makefile Guide for further + details on these make targets and descriptions of other targets + available.

+ +

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

+ +

gmake TOOL_VERBOSE=1
+
Ask each tool invoked by the makefiles to print out what it is doing on + the standard output. This also implies VERBOSE=1. +

+
+ +

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 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/Debug/bin +
Libraries +
OBJ_ROOT/Debug/lib +
+

+ +

Release Builds +
+
+
Tools +
OBJ_ROOT/Release/bin +
Libraries +
OBJ_ROOT/Release/lib +
+

+ +

Profile Builds +
+
+
Tools +
OBJ_ROOT/Profile/bin +
Libraries +
OBJ_ROOT/Profile/lib +
+
+ +
+ + + + +
+ +

+ If you're running on a Linux system that supports the " + binfmt_misc" + module, and you have root access on the system, you can set your system up to + execute LLVM bytecode files directly. To do this, use commands like this (the + first command may not be required if you are already using the module):

+ +
+
+    $ mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
+    $ echo ':llvm:M::llvm::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
+    $ chmod u+x hello.bc                (if needed)
+    $ ./hello.bc
+ 
+
+ +

+ This allows you to execute LLVM bytecode files directly. Thanks to Jack + Cummings for pointing this out! +

+ +
+ + + + + + +
+ +

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:

+ +
+ + + +
+

Every directory checked out of CVS will contain a CVS directory; for + the most part these can just be ignored.

+
+ + + +
+

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

+
+ + + +
+ +

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

+ +
+
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...
+ +
llvm/include/llvm/Support
+
This directory contains generic support libraries that are provided with + LLVM but not necessarily specific to LLVM. For example, some C++ STL utilities + and a Command Line option processing library store their header files here. +
+ +
llvm/include/llvm/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.
+
+
+ + + +
+ +

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/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/SparcV9 + directory holds the Sparc machine description while + llvm/lib/Target/CBackend implements the LLVM-to-C converter.
+ +
llvm/lib/CodeGen/
+
This directory contains the major parts of the code generator: Instruction + Selector, Instruction Scheduling, and Register Allocation.
+ +
llvm/lib/Debugger/
+
This directory contains the source level debugger library that makes + it possible to instrument LLVM programs so that a debugger could identify + source code locations at which the program is executing.
+ +
llvm/lib/ExecutionEngine/
+
This directory contains libraries for executing LLVM bytecode directly + at runtime in both interpreted and JIT compiled fashions.
+ +
llvm/lib/Support/
+
This directory contains the source code that corresponds to the header + files located in llvm/include/Support/.
+ +
llvm/lib/System/
+
This directory contains the operating system abstraction layer that + shields LLVM from platform-specific coding.
+
+ +
+ + + +
+

This directory contains projects that are not strictly part of LLVM but are + shipped with LLVM. This is also the directory where you should create your own + LLVM-based projects. See llvm/projects/sample for an example of how + to set up your own project. See llvm/projects/Stacker for a fully + functional example of a compiler front end.

+
+ + + +
+ +

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.

+ +
+ + + +
+

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

+
+ + + +
+

This is not a directory in the normal llvm module; it is a separate CVS + module that must be checked out (usually to projects/llvm-test). This + module contains a comprehensive correctness, performance, and benchmarking + test + suite for LLVM. It is a separate CVS module because not every LLVM user is + interested in downloading or building such a comprehensive test suite. For + further details on this test suite, please see the + Testing Guide document.

+
+ + + +
+ +

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. More detailed + information is in the Command Guide.

+ +
+
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.
+ +
llvmc
+
The LLVM Compiler Driver. This program can + be configured to utilize both LLVM and non-LLVM compilation tools to enable + pre-processing, translation, optimization, assembly, and linking of programs + all from one command line. llvmc also takes care of processing the + dependent libraries found in bytecode. This reduces the need to get the + traditional -l<name> options right on the command line. Please + note that this tool, while functional, is still experimental and not feature + complete.
+ +
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-ld
+
llvm-ld is very similar to gccld and provides a general purpose + and extensible linker for LLVM. This is the linker invoked by llvmc. + It allows optimization modules to be loaded so that language specific + optimizations can be applied at link time. This tool is considered + experimental.
+ +
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 x86, Sparc, and PowerPC), 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 native code assembly file or to C code (with + the -march=c option).
+ +
llvm-gcc
+
llvm-gcc 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 + llvm-gcc tool is available as a separate CVS module. +
+
+
gccas
+
This tool is invoked by the llvm-gcc 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 + llvm-gcc -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.
+
+
+ + + +
+ +

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.

+ +

llvmgrep
+
This little tool performs an "egrep -H -n" on each source file in LLVM and + passes to it a regular expression provided on llvmgrep's command + line. This is a very efficient way of searching the source base for a + particular regular expression.
+ +
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.

+ +

+ +
+ + + +
+

This directory contains build scripts and project files for use with + Visual C++. This allows developers on Windows to build LLVM without the need + for Cygwin. The contents of this directory should be considered experimental + at this time. +

+
+ + + + +
+ +
    +
  1. First, create a simple C file, name it 'hello.c': +
    +    #include <stdio.h>
    +    int main() {
    +      printf("hello world\n");
    +      return 0;
    +    }
    +        
  2. + +
  3. Next, compile the C file into a LLVM bytecode file:

    +

    % llvm-gcc hello.c -o hello

    + +

    Note that you should have already built the tools and they have to be + in your path, at least gccas and gccld.

    + +

    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. Note that + all LLVM optimizations are enabled by default, so there is no need for a + "-O3" switch.

  4. + +
  5. Run the program. To make sure the program ran, execute one of the + following commands:

    + +

    % ./hello

    + +

    or

    + +

    % lli hello.bc

  6. + +
  7. Use the llvm-dis utility to take a look at the LLVM assembly + code:

    + +

    % llvm-dis < hello.bc | less

  8. + +
  9. Compile the program to native assembly using the LLC code + generator:

    + +

    % llc hello.bc -o hello.s

    + +
  10. Assemble the native assembly language file into a program:

    + +

    Solaris:% /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native

    +

    Others:% gcc hello.s -o hello.native

    + +
  11. Execute the native code program:

    + +

    % ./hello.native

  12. + +
+ +
+ + + + + +
+ +

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
+ Reid Spencer
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + Index: llvm-www/releases/1.6/docs/GettingStartedVS.html diff -c /dev/null llvm-www/releases/1.6/docs/GettingStartedVS.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/GettingStartedVS.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,353 ---- + + + + + Getting Started with LLVM System for Microsoft Visual Studio + + + + +
+ Getting Started with the LLVM System using Microsoft Visual Studio +
+ + + +
+

Written by: + Jeff Cohen +

+
+ + + +
+ Overview +
+ + +
+ +

The Visual Studio port at this time is experimental. It is suitable for + use only if you are writing your own compiler front end or otherwise have a + need to dynamically generate machine code. The JIT and interpreter are + functional, but it is currently not possible to generate assembly code which + is then assembled into an executable. You can indirectly create executables + by using the C back end.

+ +

To emphasize, there is no C/C++ front end currently available. + llvm-gcc is based on GCC, which cannot be bootstrapped using VC++. + Eventually there should be a llvm-gcc based on Cygwin or MinGW that + is usable. There is also the option of generating bytecode files on Unix and + copying them over to Windows. But be aware the odds of linking C++ code + compiled with llvm-gcc with code compiled with VC++ is essentially + zero.

+ +

The LLVM test suite cannot be run on the Visual Studio port at this + time.

+ +

Most of the tools build and work. llvm-db does not build at this + time. bugpoint does build, but does not work. + +

Additional information about the LLVM directory structure and tool chain + can be found on the main Getting Started + page.

+ +
+ + + + + +
+ +

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

+ +
    +
  1. Read the documentation.
  2. +
  3. Read the documentation.
  4. +
  5. Remember that you were warned twice about reading the documentation.
  6. + +
  7. 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 - +       or use WinZip +
      3. cd llvm
      4. +
    • + +
    • With anonymous CVS access (or use a mirror): +
        +
      1. cd where-you-want-llvm-to-live
      2. +
      3. cvs -d + :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm login
      4. +
      5. Hit the return key when prompted for the password. +
      6. cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm + co llvm
      7. +
      8. cd llvm
      9. +
      10. cvs up -P -d
      11. +
    • +
  8. + +
  9. Start Visual Studio +
      +
    1. Simply double click on the solution file llvm/win32/llvm.sln. +
    2. +
  10. + +
  11. Build the LLVM Suite: +
      +
    1. Simply build the solution.
    2. +
    3. The Fibonacci project is a sample program that uses the JIT. Modify + the project's debugging properties to provide a numeric command line + argument. The program will print the corresponding fibonacci value.
    4. +
  12. + +
+ +

It is strongly encouraged that you get the latest version from CVS. Much + progress has been made since the 1.4 release.

+ +
+ + + + + +
+ +

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

+ +
+ + +
+ Hardware +
+ +
+ +

Any system that can adequately run Visual Studio .NET 2003 is fine. The + LLVM source tree and object files, libraries and executables will consume + approximately 3GB.

+ +
+ + + +
+ +

You will need Visual Studio .NET 2003. Earlier versions cannot open the + solution/project files. The VS 2005 beta can, but will migrate these files + to its own format in the process. While it should work with the VS 2005 + beta, there are no guarantees and there is no support for it at this time. + It has been reported that VC++ Express also works.

+ +

If you plan to modify any .y or .l files, you will need to have bison + and/or flex installed where Visual Studio can find them. Otherwise, you do + not need them and the pre-generated files that come with the source tree + will be used.

+ +
+ + + + + +
+ +

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

+ +
+ + + + +
+ +

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 + is fixed at SRC_ROOT/win32). +

+

+ +
+ + + + +
+ +

The object files are placed under OBJ_ROOT/Debug for debug builds + and OBJ_ROOT/Release for release (optimized) builds. These include + both executables and libararies that your application can link against. + +

The files that configure would create when building on Unix are + created by the Configure project and placed in + OBJ_ROOT/llvm. You application must have OBJ_ROOT in its include + search path just before SRC_ROOT/include. + +

+ + + + + +
+ +
    +
  1. First, create a simple C file, name it 'hello.c': +
    +    #include <stdio.h>
    +    int main() {
    +      printf("hello world\n");
    +      return 0;
    +    }
    +        
  2. + +
  3. Next, compile the C file into a LLVM bytecode file:

    +

    % llvm-gcc hello.c -o hello

    + +

    Note that you should have already built the tools and they have to be + in your path, at least gccas and gccld.

    + +

    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. Note that + all LLVM optimizations are enabled by default, so there is no need for a + "-O3" switch.

    + +

    Note: while you cannot do this step on Windows, you can do it on a + Unix system and transfer hello.bc to Windows.

  4. + +
  5. Run the program using the just-in-time compiler:

    + +

    % lli hello.bc

  6. + +
  7. Use the llvm-dis utility to take a look at the LLVM assembly + code:

    + +

    % llvm-dis < hello.bc | more

  8. + +
  9. Compile the program to C using the LLC code generator:

    + +

    % llc -march=c hello.bc

  10. + +
  11. Compile to binary using Microsoft C:

    + +

    % cl hello.cbe.c

  12. + +
  13. Execute the native code program:

    + +

    % hello.cbe.exe

  14. + +
+ +
+ + + + + +
+ +

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! + + Jeff Cohen
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + Index: llvm-www/releases/1.6/docs/HowToSubmitABug.html diff -c /dev/null llvm-www/releases/1.6/docs/HowToSubmitABug.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/HowToSubmitABug.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,356 ---- + + + + How to submit an LLVM bug report + + + + +
+ How to submit an LLVM bug report +
+ + + + + + +
+
    +
  1. Introduction - Got bugs?
  2. +
  3. Crashing Bugs +
  4. +
  5. Miscompilations
  6. +
  7. Incorrect code generation (JIT and LLC)
  8. +
+
+

Written by Chris Lattner and + Misha Brukman

+
+
+ Debugging +
+ + + + + +
+ +

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!

+ +
+ + + + + +
+ +

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

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+ +

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.

+ +

If it looks like the LLVM compiler is miscompiling a program, the very first + thing to check is to make sure it is not using undefined behavior. In + particular, check to see if the program valgrinds clean, passes purify, or some + other memory checker tool. Many of the "LLVM bugs" that we have chased down + ended up being bugs in the program being compiled, not LLVM.

+ +

Once you determine that the program itself is not buggy, you should choose + which code generator you wish to compile the program with (e.g. C backend, the + JIT, or LLC) and optionally a series of LLVM passes to run. For example:

+ +
+

+ bugpoint -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]

+
+ +

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.

+ +
+ + + + + +
+ +

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] [bytecode file]  \
+          --tool-args -- [arguments to pass to lli]               \
+          --args -- [program arguments]
+ 
+
+ +

Similarly, to debug the LLC, one would run:

+ +
+
+ bugpoint -run-llc -output=[correct output file] [bytecode file]  \
+          --tool-args -- [arguments to pass to llc]               \
+          --args -- [program arguments]
+ 
+
+ +

Special note: if you are debugging MultiSource or SPEC tests that + already exist in the llvm/test hierarchy, there is an easier way to + debug the JIT, LLC, and CBE, using the pre-written Makefile targets, which + will pass the program options specified in the Makefiles:

+ +
+

+ cd llvm/test/../../program
+ make bugpoint-jit +

+
+ +

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. + +
  3. 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] +

    +
  4. + +
  5. If debugging the JIT, load the shared object and supply the test + bytecode:

    + +
    +

    lli -load=safe.so test.bc [program options]

    +
  6. + +
+ +
+ + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ The LLVM Compiler Infrastructure +
+ Last modified: $Date: 2005/11/08 20:06:33 $ +
+ + + Index: llvm-www/releases/1.6/docs/LLVMVsTheWorld.html diff -c /dev/null llvm-www/releases/1.6/docs/LLVMVsTheWorld.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/LLVMVsTheWorld.html Tue Nov 8 14:06:33 2005 *************** *** 0 **** --- 1,180 ---- + + + + + LLVM vs. the World - Comparing Compilers to Compilers + + + + +
+ LLVM vs. the World - Comparing Compilers to Compilers +
+ +
    +
  1. Introduction
  2. +
  3. General Applicability
  4. +
  5. Type System
  6. +
  7. Control-flow and Data-flow Information
  8. +
  9. Registers
  10. +
  11. Programmer Interface
  12. +
  13. Machine Code Emission
  14. +
+ +
+

Written by Brian R. Gaeke

+
+ + + + + +
+

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.

+
+ + + + + +
+

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.

+
+ + + + + +
+

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.

+
+ + + + + +
+

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.

+
+ + + + + +
+

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.

+
+ + + + + +
+

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.

+
+ + + +
+ + + + Index: llvm-www/releases/1.6/docs/LangRef.html diff -c /dev/null llvm-www/releases/1.6/docs/LangRef.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/LangRef.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,3393 ---- + + + + LLVM Assembly Language Reference Manual + + + + + + + + +
LLVM Language Reference Manual
+
    +
  1. Abstract
  2. +
  3. Introduction
  4. +
  5. Identifiers
  6. +
  7. High Level Structure +
      +
    1. Module Structure
    2. +
    3. Linkage Types
    4. +
    5. Calling Conventions
    6. +
    7. Global Variables
    8. +
    9. Function Structure
    10. +
    +
  8. +
  9. Type System +
      +
    1. Primitive Types +
        +
      1. Type Classifications
      2. +
      +
    2. +
    3. Derived Types +
        +
      1. Array Type
      2. +
      3. Function Type
      4. +
      5. Pointer Type
      6. +
      7. Structure Type
      8. +
      9. Packed Type
      10. +
      11. Opaque Type
      12. +
      +
    4. +
    +
  10. +
  11. Constants +
      +
    1. Simple Constants +
    2. Aggregate Constants +
    3. Global Variable and Function Addresses +
    4. Undefined Values +
    5. Constant Expressions +
    +
  12. +
  13. Instruction Reference +
      +
    1. Terminator Instructions +
        +
      1. 'ret' Instruction
      2. +
      3. 'br' Instruction
      4. +
      5. 'switch' Instruction
      6. +
      7. 'invoke' Instruction
      8. +
      9. 'unwind' Instruction
      10. +
      11. 'unreachable' Instruction
      12. +
      +
    2. +
    3. Binary Operations +
        +
      1. 'add' Instruction
      2. +
      3. 'sub' Instruction
      4. +
      5. 'mul' Instruction
      6. +
      7. 'div' Instruction
      8. +
      9. 'rem' Instruction
      10. +
      11. 'setcc' Instructions
      12. +
      +
    4. +
    5. Bitwise Binary Operations +
        +
      1. 'and' Instruction
      2. +
      3. 'or' Instruction
      4. +
      5. 'xor' Instruction
      6. +
      7. 'shl' Instruction
      8. +
      9. 'shr' Instruction
      10. +
      +
    6. +
    7. Memory Access Operations +
        +
      1. 'malloc' Instruction
      2. +
      3. 'free' Instruction
      4. +
      5. 'alloca' Instruction
      6. +
      7. 'load' Instruction
      8. +
      9. 'store' Instruction
      10. +
      11. 'getelementptr' Instruction
      12. +
      +
    8. +
    9. Other Operations +
        +
      1. 'phi' Instruction
      2. +
      3. 'cast .. to' Instruction
      4. +
      5. 'select' Instruction
      6. +
      7. 'call' Instruction
      8. +
      9. 'vaarg' Instruction
      10. +
      +
    10. +
    +
  14. +
  15. Intrinsic Functions +
      +
    1. Variable Argument Handling Intrinsics +
        +
      1. 'llvm.va_start' Intrinsic
      2. +
      3. 'llvm.va_end' Intrinsic
      4. +
      5. 'llvm.va_copy' Intrinsic
      6. +
      +
    2. +
    3. Accurate Garbage Collection Intrinsics +
        +
      1. 'llvm.gcroot' Intrinsic
      2. +
      3. 'llvm.gcread' Intrinsic
      4. +
      5. 'llvm.gcwrite' Intrinsic
      6. +
      +
    4. +
    5. Code Generator Intrinsics +
        +
      1. 'llvm.returnaddress' Intrinsic
      2. +
      3. 'llvm.frameaddress' Intrinsic
      4. +
      5. 'llvm.prefetch' Intrinsic
      6. +
      7. 'llvm.pcmarker' Intrinsic
      8. +
      +
    6. +
    7. Operating System Intrinsics +
        +
      1. 'llvm.readport' Intrinsic
      2. +
      3. 'llvm.writeport' Intrinsic
      4. +
      5. 'llvm.readio' Intrinsic
      6. +
      7. 'llvm.writeio' Intrinsic
      8. +
      +
    8. Standard C Library Intrinsics +
        +
      1. 'llvm.memcpy' Intrinsic
      2. +
      3. 'llvm.memmove' Intrinsic
      4. +
      5. 'llvm.memset' Intrinsic
      6. +
      7. 'llvm.isunordered' Intrinsic
      8. +
      9. 'llvm.sqrt' Intrinsic
      10. + +
      +
    9. +
    10. Bit counting Intrinsics +
        +
      1. 'llvm.ctpop' Intrinsic
      2. +
      3. 'llvm.ctlz' Intrinsic
      4. +
      5. 'llvm.cttz' Intrinsic
      6. +
      +
    11. +
    12. Debugger intrinsics
    13. +
    +
  16. +
+ +
+

Written by Chris Lattner + and Vikram Adve

+
+ + + + + +
+

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.

+
+ + + + + +
+ +

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

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+ +

LLVM uses three different forms of identifiers, for different + purposes:

+ +
    +
  1. 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.
  2. + +
  3. Unnamed values are represented as an unsigned numeric value with a '%' + prefix. For example, %12, %2, %44.
  4. + +
  5. Constants, which are described in a section about + constants, below.
  6. +
+ +

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. + +
  3. Unnamed temporaries are created when the result of a computation is not + assigned to a named value.
  4. + +
  5. Unnamed temporaries are numbered sequentially
  6. + +
+ +

...and it also shows 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.

+ +
+ + + + + + + + +
+ +

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.

+ +
+ + + + +
+ +

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

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

+ +
+ + + + +
+ +

LLVM functions, calls + and invokes can all have an optional calling convention + specified for the call. The calling convention of any pair of dynamic + caller/callee must match, or the behavior of the program is undefined. The + following calling conventions are supported by LLVM, and more may be added in + the future:

+ +
+
"ccc" - The C calling convention:
+ +
This calling convention (the default if no other calling convention is + specified) matches the target C calling conventions. This calling convention + supports varargs function calls and tolerates some mismatch in the declared + prototype and implemented declaration of the function (as does normal C). +
+ +
"fastcc" - The fast calling convention:
+ +
This calling convention attempts to make calls as fast as possible + (e.g. by passing things in registers). This calling convention allows the + target to use whatever tricks it wants to produce fast code for the target, + without having to conform to an externally specified ABI. Implementations of + this convention should allow arbitrary tail call optimization to be supported. + This calling convention does not support varargs and requires the prototype of + all callees to exactly match the prototype of the function definition. +
+ +
"coldcc" - The cold calling convention:
+ +
This calling convention attempts to make code in the caller as efficient + as possible under the assumption that the call is not commonly executed. As + such, these calls often preserve all registers so that the call does not break + any live ranges in the caller side. This calling convention does not support + varargs and requires the prototype of all callees to exactly match the + prototype of the function definition. +
+ +
"cc <n>" - Numbered convention:
+ +
Any calling convention may be specified by number, allowing + target-specific calling conventions to be used. Target specific calling + conventions start at 64. +
+
+ +

More calling conventions can be added/defined on an as-needed basis, to + support pascal conventions or any other well-known target-independent + convention.

+ +
+ + + + +
+ +

Global variables define regions of memory allocated at compilation time + instead of run-time. Global variables may optionally be initialized, and may + have an optional explicit alignment specified. A + variable may be defined as a global "constant," which indicates that the + contents of the variable will never be modified (enabling better + optimization, allowing the global data to be placed in the read-only section of + an executable, etc). Note that variables that need runtime initialization + cannot be marked "constant" as there is a store to the variable.

+ +

+ LLVM explicitly allows declarations of global variables to be marked + constant, even if the final definition of the global is not. This capability + can be used to enable slightly better optimization of the program, but requires + the language definition to guarantee that optimizations based on the + 'constantness' are valid for the translation units that do not include the + definition. +

+ +

As SSA values, global variables define pointer values that are in + scope (i.e. they dominate) 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.

+ +

An explicit alignment may be specified for a global. If not present, or if + the alignment is set to zero, the alignment of the global is set by the target + to whatever it feels convenient. If an explicit alignment is specified, the + global is forced to have at least that much alignment. All alignments must be + a power of 2.

+ +
+ + + +
+ Functions +
+ +
+ +

LLVM function definitions consist of an optional linkage + type, an optional calling convention, a return + type, a function name, a (possibly empty) argument list, an optional alignment, + an opening curly brace, + a list of basic blocks, and a closing curly brace. LLVM function declarations + are defined with the "declare" keyword, an optional calling convention, a return type, a function name, + a possibly empty list of arguments, and an optional alignment.

+ +

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 a 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 resolve references to each + appropriately.

+ +

An explicit alignment may be specified for a function. If not present, or if + the alignment is set to zero, the alignment of the function is set by the target + to whatever it feels convenient. If an explicit alignment is specified, the + function is forced to have at least that much alignment. All alignments must be + a power of 2.

+ +
+ + + + + + + +
+ +

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.

+ +
+ + + +
+

The primitive types are the fundamental building blocks of the LLVM + system. The current set of primitive types is as follows:

+ + + + + + +
+ + + + + + + + + + + +
TypeDescription
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
+
+ + + + + + + + + + +
TypeDescription
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
+
+
+ + + +
+

These different primitive types fall into a few useful + classifications:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ClassificationTypes
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, + packed
+ +

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.

+
+ + + + +
+ +

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.

+ +
+ + + + +
+ +
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 ]
+ [41 x int ]
+ [40 x uint]
+
+ Array of 40 integer values.
+ Array of 41 integer values.
+ Array of 40 unsigned integer values.
+
+

Here are some examples of multidimensional arrays:

+ + + + + +
+ [3 x [4 x int]]
+ [12 x [10 x float]]
+ [2 x [3 x [4 x uint]]]
+
+ 3x4 array of integer values.
+ 12x10 array of single precision floating point values.
+ 2x3x4 array of unsigned integer values.
+
+ +

Note that 'variable sized arrays' can be implemented in LLVM with a zero + length array. Normally, accesses past the end of an array are undefined in + LLVM (e.g. it is illegal to access the 5th element of a 3 element array). + As a special case, however, zero length arrays are recognized to be variable + length. This allows implementation of 'pascal style arrays' with the LLVM + type "{ int, [0 x float]}", for example.

+ +
+ + + +
+
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)
+ float (int, int *) *
+ int (sbyte *, ...)
+
+ function taking an int, returning an int
+ Pointer to a function that takes an + int and a pointer to int, + returning float.
+ 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.
+
+ +
+ + +
+
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 }
+ { float, int (int) * }
+
+ a triple of three int values
+ 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.
+
+
+ + + +
+
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]*
+ int (int *) *
+
+ A pointer to array of + four int values
+ A pointer to a function that takes an int*, returning an + int.
+
+
+ + + +
+ +
Overview:
+ +

A packed type is a simple derived type that represents a vector + of elements. Packed types are used when multiple primitive data + are operated in parallel using a single instruction (SIMD). + A packed type requires a size (number of + elements) and an underlying primitive data type. Packed types are + considered first class.

+ +
Syntax:
+ +
+   < <# elements> x <elementtype> >
+ 
+ +

The number of elements is a constant integer value; elementtype may + be any integral or floating point type.

+ +
Examples:
+ + + + + + +
+ <4 x int>
+ <8 x float>
+ <2 x uint>
+
+ Packed vector of 4 integer values.
+ Packed vector of 8 floating-point values.
+ Packed vector of 2 unsigned integer values.
+
+
+ + + +
+ +
Overview:
+ +

Opaque types are used to represent unknown types in the system. This + corresponds (for example) to the C notion of a foward declared structure type. + In LLVM, opaque types can eventually be resolved to any type (not just a + structure type).

+ +
Syntax:
+ +
+   opaque
+ 
+ +
Examples:
+ + + + + + +
+ opaque + + An opaque type.
+
+
+ + + + + + +
+ +

LLVM has several different basic types of constants. This section describes + them all and their syntax.

+ +
+ + + + +
+ +
+
Boolean constants
+ +
The two strings 'true' and 'false' are both valid + constants of the bool type. +
+ +
Integer constants
+ +
Standard integers (such as '4') are constants of the integer type. Negative numbers may be used with signed + integer types. +
+ +
Floating point constants
+ +
Floating point constants use standard decimal notation (e.g. 123.421), + exponential notation (e.g. 1.23421e+2), or a more precise hexadecimal + notation (see below). Floating point constants must have a floating point type.
+ +
Null pointer constants
+ +
The identifier 'null' is recognized as a null pointer constant + and must be of pointer type.
+ +
+ +

The one non-intuitive notation for constants is the optional hexadecimal form + of floating point constants. For example, the form 'double + 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double + 4.5e+15'. The only time hexadecimal floating point constants are required + (and the only time that they are generated by the disassembler) is when a + floating point constant must be emitted but it cannot be represented as a + decimal floating point number. For example, NaN's, infinities, and other + special values are represented in their IEEE hexadecimal format so that + assembly and disassembly do not cause any bits to change in the constants.

+ +
+ + + + +
+

Aggregate constants arise from aggregation of simple constants + and smaller aggregate constants.

+ +
+
Structure constants
+ +
Structure constants are represented with notation similar to structure + type definitions (a comma separated list of elements, surrounded by braces + ({})). For example: "{ int 4, float 17.0, int* %G }", + where "%G" is declared as "%G = external global int". Structure constants + must have structure type, and the number and + types of elements must match those specified by the type. +
+ +
Array constants
+ +
Array constants are represented with notation similar to array type + definitions (a comma separated list of elements, surrounded by square brackets + ([])). For example: "[ int 42, int 11, int 74 ]". Array + constants must have array type, and the number and + types of elements must match those specified by the type. +
+ +
Packed constants
+ +
Packed constants are represented with notation similar to packed type + definitions (a comma separated list of elements, surrounded by + less-than/greater-than's (<>)). For example: "< int 42, + int 11, int 74, int 100 >". Packed constants must have packed type, and the number and types of elements must + match those specified by the type. +
+ +
Zero initialization
+ +
The string 'zeroinitializer' can be used to zero initialize a + value to zero of any type, including scalar and aggregate types. + This is often used to avoid having to print large zero initializers (e.g. for + large arrays) and is always exactly equivalent to using explicit zero + initializers. +
+
+ +
+ + + + +
+ +

The addresses of global variables and functions are always implicitly valid (link-time) + constants. These constants are explicitly referenced when the identifier for the global is used and always have pointer type. For example, the following is a legal LLVM + file:

+ +
+   %X = global int 17
+   %Y = global int 42
+   %Z = global [2 x int*] [ int* %X, int* %Y ]
+ 
+ +
+ + + +
+

The string 'undef' is recognized as a type-less constant that has + no specific value. Undefined values may be of any type and be used anywhere + a constant is permitted.

+ +

Undefined values indicate to the compiler that the program is well defined + no matter what value is used, giving the compiler more freedom to optimize. +

+
+ + + + +
+ +

Constant expressions are used to allow expressions involving other constants + to be used as constants. Constant expressions may be of any first class type and may involve any LLVM operation + that does not have side effects (e.g. load and call are not supported). The + following is the syntax for constant expressions:

+ +
+
cast ( CST to TYPE )
+ +
Cast a constant to another type.
+ +
getelementptr ( CSTPTR, IDX0, IDX1, ... )
+ +
Perform the getelementptr operation on + constants. As with the getelementptr + instruction, the index list may have zero or more indexes, which are required + to make sense for the type of "CSTPTR".
+ +
OPCODE ( LHS, RHS )
+ +
Perform the specified operation of the LHS and RHS constants. OPCODE may + be any of the binary or bitwise + binary operations. The constraints on operands are the same as those for + the corresponding instruction (e.g. no bitwise operations on floating point + values are allowed).
+
+
+ + + + + +
+ +

The LLVM instruction set consists of several different + classifications of instructions: terminator + instructions, binary instructions, + bitwise binary instructions, memory instructions, and other + 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 six different terminator instructions: the 'ret' instruction, the 'br' + instruction, the 'switch' instruction, + the 'invoke' instruction, the 'unwind' instruction, and the 'unreachable' 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' instruction: 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 of the "normal" 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
+ 
+
+ + +
+
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
+
+ + + +
+
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, control flow is + transfered to the corresponding destination; otherwise, control flow is + transfered to the default destination.

+ +
Implementation:
+ +

Depending on properties of the target machine and the particular + switch instruction, this instruction may be code generated in different + ways. For example, it could be generated 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 ]
+ 
+
+ + + + +
+ +
Syntax:
+ +
+   <result> = invoke [cconv] <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 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 "exception" label.

+ +
Arguments:
+ +

This instruction requires several arguments:

+ +
    +
  1. + The optional "cconv" marker indicates which calling + convention the call should use. If none is specified, the call defaults + to using C calling conventions. +
  2. +
  3. '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. +
  4. + +
  5. 'function ptr val': An LLVM value containing a pointer to a + function to be invoked.
  6. + +
  7. '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.
  8. + +
  9. 'normal label': the label reached when the called function + executes a 'ret' instruction.
  10. + +
  11. 'exception label': the label reached when a callee returns with + the unwind instruction.
  12. + +
+ +
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
+   %retval = invoke coldcc int %Test(int 15)             to label %Continue
+               except label %TestCleanup     ; {int}:retval set
+ 
+
+ + + + + + +
+ +
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.

+
+ + + + + +
+ +
Syntax:
+
+   unreachable
+ 
+ +
Overview:
+ +

The 'unreachable' instruction has no defined semantics. This + instruction is used to inform the optimizer that a particular portion of the + code is not reachable. This can be used to indicate that the code after a + no-return function cannot be reached, and other facts.

+ +
Semantics:
+ +

The 'unreachable' instruction has no defined semantics.

+
+ + + + + +
+

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 operands might represent + multiple data, as is the case with the packed data type. + The result value of a binary operator is not + necessarily the same type as its operands.

+

There are several different binary operators:

+
+ + +
+
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. + This instruction can also take packed versions of the 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
+ 
+
+ + +
+
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. + This instruction can also take packed versions of the 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
+ 
+
+ + +
+
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. + This instruction can also take packed versions of the 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
+ 
+
+ + +
+
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. + This instruction can also take packed versions of the 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
+ 
+
+ + +
+
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. + This instruction can also take packed versions of the 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
+ 
+
+ + +
+
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 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.

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

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.

+ +
+ + + + +
+ +
Syntax:
+ +
+   <result> = malloc <type>[, uint <NumElements>][, align <alignment>]     ; 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. If "NumElements" is specified, it is the + number of elements allocated. If an alignment is specified, the value result + of the allocation is guaranteed to be aligned to at least that boundary. If + not specified, or if zero, the target can choose to align the allocation on any + convenient boundary.

+ +

'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
+   %array3 = malloc int, uint 4, align 1024         ; yields {int*}:array3
+   %array4 = malloc int, align 1024                 ; yields {int*}:array4
+ 
+
+ + + + +
+ +
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 no longer defined + after this instruction executes.

+ +
Example:
+ +
+   %array  = malloc [4 x ubyte]                    ; yields {[4 x ubyte]*}:array
+             free   [4 x ubyte]* %array
+ 
+
+ + + + +
+ +
Syntax:
+ +
+   <result> = alloca <type>[, uint <NumElements>][, align <alignment>]     ; 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 'alloca' instruction allocates sizeof(<type>)*NumElements + bytes of memory on the runtime stack, returning a pointer of the + appropriate type to the program. If "NumElements" is specified, it is the + number of elements allocated. If an alignment is specified, the value result + of the allocation is guaranteed to be aligned to at least that boundary. If + not specified, or if zero, the target can choose to align the allocation on any + convenient boundary.

+ +

'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 unwind + instructions), the memory is reclaimed.

+ +
Example:
+ +
+   %ptr = alloca int                              ; yields {int*}:ptr
+   %ptr = alloca int, uint 4                      ; yields {int*}:ptr
+   %ptr = alloca int, uint 4, align 1024          ; yields {int*}:ptr
+   %ptr = alloca int, align 1024                  ; yields {int*}:ptr
+ 
+
+ + + +
+
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 from which to load. 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
+ 
+
+ + +
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 in which to store it. 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
+ 
+ + + +
+
Syntax:
+
+   <result> = getelementptr <ty>* <ptrval>{, <ty> <idx>}*
+ 
+ +
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 integer constants that indicate what + elements of the aggregate object to index to. 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 or to a specific index in an array. When indexing into a + structure, only uint + integer constants are allowed. When indexing into an array or pointer, + int and long indexes are allowed of any sign.

+ +

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 }
+ 
+   implementation
+ 
+   int* %foo(%ST* %s) {
+   entry:
+     %reg = getelementptr %ST* %s, int 1, uint 2, uint 1, int 5, int 13
+     ret int* %reg
+   }
+ 
+ +
Semantics:
+ +

The index types specified for the 'getelementptr' instruction depend + on the pointer type that is being indexed into. Pointer + and array types require uint, int, + ulong, or long values, and structure + types require uint 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 returns a pointer + to this element, thus computing a value of '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, int 1                        ; yields %ST*:%t1
+     %t2 = getelementptr %ST* %t1, int 0, uint 2               ; yields %RT*:%t2
+     %t3 = getelementptr %RT* %t2, int 0, uint 1               ; yields [10 x [20 x int]]*:%t3
+     %t4 = getelementptr [10 x [20 x int]]* %t3, int 0, int 5  ; yields [20 x int]*:%t4
+     %t5 = getelementptr [20 x int]* %t4, int 0, int 13        ; yields int*:%t5
+     ret int* %t5
+   }
+ 
+ +

Note that it is undefined to access an array out of bounds: array and + pointer indexes must always be within the defined bounds of the array type. + The one exception for this rules is zero length arrays. These arrays are + defined to be accessible as variable length arrays, which requires access + beyond the zero'th element.

+ +
Example:
+ +
+     ; yields [12 x ubyte]*:aptr
+     %aptr = getelementptr {int, [12 x ubyte]}* %sptr, long 0, uint 1
+ 
+ +
+ + +
+

The instructions in this category are the "miscellaneous" + instructions, which defy better classification.

+
+ + +
+
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
+
+ + + + +
+ +
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
+ 
+
+ + + + +
+ +
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
+ 
+
+ + + + + + + + +
+ +
Syntax:
+
+   <result> = [tail] call [cconv] <ty>* <fnptrval>(<param list>)
+ 
+ +
Overview:
+ +

The 'call' instruction represents a simple function call.

+ +
Arguments:
+ +

This instruction requires several arguments:

+ +
    +
  1. +

    The optional "tail" marker indicates whether the callee function accesses + any allocas or varargs in the caller. If the "tail" marker is present, the + function call is eligible for tail call optimization. Note that calls may + be marked "tail" even if they do not occur before a ret instruction. +

  2. +
  3. +

    The optional "cconv" marker indicates which calling + convention the call should use. If none is specified, the call defaults + to using C calling conventions. +

  4. +
  5. +

    'ty': shall be the signature of the pointer to function value + being invoked. The argument types must match the types implied by this + signature. This type can be omitted if the function is not varargs and + if the function type does not return a pointer to a function.

    +
  6. +
  7. +

    '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 value.

    +
  8. +
  9. +

    'function args': argument list whose types match the + function signature argument types. All arguments must be of + first class type. If the function signature + indicates the function accepts a variable number of arguments, the extra + arguments can be specified.

    +
  10. +
+ +
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);
+   %X = tail call int %foo()
+   %Y = tail call fastcc int %foo()
+ 
+ +
+ + + + +
+ +
Syntax:
+ +
+   <resultval> = va_arg <va_list*> <arglist>, <argty>
+ 
+ +
Overview:
+ +

The 'va_arg' 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 va_list* value and the type of + the argument. It returns a value of the specified argument type and + increments the va_list to poin to the next argument. Again, the + actual type of va_list is target specific.

+ +
Semantics:
+ +

The 'va_arg' instruction loads an argument of the specified + type from the specified va_list and causes the + va_list to point to the next argument. 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.

+ +

va_arg is an LLVM instruction instead of an intrinsic function because it takes a type as an + argument.

+ +
Example:
+ +

See the variable argument processing section.

+ +
+ + + + + +
+ +

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.

+ + +

To learn how to add an intrinsic function, please see the Extending LLVM Guide. +

+ +
+ + + + +
+ +

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 = alloca sbyte*
+   call void %llvm.va_start(sbyte** %ap)
+ 
+   ; Read a single integer argument
+   %tmp = va_arg sbyte** %ap, int
+ 
+   ; Demonstrate usage of llvm.va_copy and llvm.va_end
+   %aq = alloca sbyte*
+   call void %llvm.va_copy(sbyte** %aq, sbyte** %ap)
+   call void %llvm.va_end(sbyte** %aq)
+ 
+   ; Stop processing of arguments.
+   call void %llvm.va_end(sbyte** %ap)
+   ret int %tmp
+ }
+ 
+
+ + + + + +
+
Syntax:
+
  declare void %llvm.va_start(<va_list>* <arglist>)
+
Overview:
+

The 'llvm.va_start' intrinsic initializes + *<arglist> for subsequent use by va_arg.

+ +
Arguments:
+ +

The argument is a pointer to a va_list element to initialize.

+ +
Semantics:
+ +

The 'llvm.va_start' intrinsic works just like the va_start + macro available in C. In a target-dependent way, it initializes the + va_list element the argument points to, so that the next call to + va_arg 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.

+ +
+ + + + +
+
Syntax:
+
  declare void %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.

+
+ + + + +
+ +
Syntax:
+ +
+   declare void %llvm.va_copy(<va_list>* <destarglist>,
+                                           <va_list>* <srcarglist>)
+ 
+ +
Overview:
+ +

The 'llvm.va_copy' intrinsic copies the current argument position from + the source argument list to the destination argument list.

+ +
Arguments:
+ +

The first argument is a pointer to a va_list element to initialize. + The second argument is a pointer to a va_list element to copy from.

+ + +
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 destination list. This intrinsic is necessary + because the llvm.va_begin intrinsic may be + arbitrarily complex and require memory allocation, for example.

+ +
+ + + + +
+ +

+ LLVM support for Accurate Garbage + Collection requires the implementation and generation of these intrinsics. + These intrinsics allow identification of GC roots on the + stack, as well as garbage collector implementations that require read and write barriers. + Front-ends for type-safe garbage collected languages should generate these + intrinsics to make use of the LLVM garbage collectors. For more details, see Accurate Garbage Collection with LLVM. +

+
+ + + + +
+ +
Syntax:
+ +
+   declare void %llvm.gcroot(<ty>** %ptrloc, <ty2>* %metadata)
+ 
+ +
Overview:
+ +

The 'llvm.gcroot' intrinsic declares the existence of a GC root to + the code generator, and allows some metadata to be associated with it.

+ +
Arguments:
+ +

The first argument specifies the address of a stack object that contains the + root pointer. The second pointer (which must be either a constant or a global + value address) contains the meta-data to be associated with the root.

+ +
Semantics:
+ +

At runtime, a call to this intrinsics stores a null pointer into the "ptrloc" + location. At compile-time, the code generator generates information to allow + the runtime to find the pointer at GC safe points. +

+ +
+ + + + + +
+ +
Syntax:
+ +
+   declare sbyte* %llvm.gcread(sbyte** %Ptr)
+ 
+ +
Overview:
+ +

The 'llvm.gcread' intrinsic identifies reads of references from heap + locations, allowing garbage collector implementations that require read + barriers.

+ +
Arguments:
+ +

The argument is the address to read from, which should be an address + allocated from the garbage collector.

+ +
Semantics:
+ +

The 'llvm.gcread' intrinsic has the same semantics as a load + instruction, but may be replaced with substantially more complex code by the + garbage collector runtime, as needed.

+ +
+ + + + + +
+ +
Syntax:
+ +
+   declare void %llvm.gcwrite(sbyte* %P1, sbyte** %P2)
+ 
+ +
Overview:
+ +

The 'llvm.gcwrite' intrinsic identifies writes of references to heap + locations, allowing garbage collector implementations that require write + barriers (such as generational or reference counting collectors).

+ +
Arguments:
+ +

The first argument is the reference to store, and the second is the heap + location to store to.

+ +
Semantics:
+ +

The 'llvm.gcwrite' intrinsic has the same semantics as a store + instruction, but may be replaced with substantially more complex code by the + garbage collector runtime, as needed.

+ +
+ + + + + + +
+

+ These intrinsics are provided by LLVM to expose special features that may only + be implemented with code generator support. +

+ +
+ + + + +
+ +
Syntax:
+
+   declare 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 be that of the obvious + source-language caller. +

+
+ + + + + +
+ +
Syntax:
+
+   declare 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 be that of the obvious + source-language caller. +

+
+ + + + +
+ +
Syntax:
+
+   declare void %llvm.prefetch(sbyte * <address>,
+                                 uint <rw>, uint <locality>)
+ 
+ +
Overview:
+ + +

+ The 'llvm.prefetch' intrinsic is a hint to the code generator to insert + a prefetch instruction if supported; otherwise, it is a noop. Prefetches have + no + effect on the behavior of the program but can change its performance + characteristics. +

+ +
Arguments:
+ +

+ address is the address to be prefetched, rw is the specifier + determining if the fetch should be for a read (0) or write (1), and + locality is a temporal locality specifier ranging from (0) - no + locality, to (3) - extremely local keep in cache. The rw and + locality arguments must be constant integers. +

+ +
Semantics:
+ +

+ This intrinsic does not modify the behavior of the program. In particular, + prefetches cannot trap and do not produce a value. On targets that support this + intrinsic, the prefetch can provide hints to the processor cache for better + performance. +

+ +
+ + + + +
+ +
Syntax:
+
+   declare void %llvm.pcmarker( uint <id> )
+ 
+ +
Overview:
+ + +

+ The 'llvm.pcmarker' intrinsic is a method to export a Program Counter + (PC) in a region of + code to simulators and other tools. The method is target specific, but it is + expected that the marker will use exported symbols to transmit the PC of the marker. + The marker makes no guaranties that it will remain with any specific instruction + after optimizations. It is possible that the presense of a marker will inhibit + optimizations. The intended use is to be inserted after optmizations to allow + correlations of simulation runs. +

+ +
Arguments:
+ +

+ id is a numerical id identifying the marker. +

+ +
Semantics:
+ +

+ This intrinsic does not modify the behavior of the program. Backends that do not + support this intrinisic may ignore it. +

+ +
+ + + + + +
+

+ These intrinsics are provided by LLVM to support the implementation of + operating system level code. +

+ +
+ + + + +
+ +
Syntax:
+
+   declare <integer type> %llvm.readport (<integer type> <address>)
+ 
+ +
Overview:
+ +

+ The 'llvm.readport' intrinsic reads data from the specified hardware + I/O port. +

+ +
Arguments:
+ +

+ The argument to this intrinsic indicates the hardware I/O address from which + to read the data. The address is in the hardware I/O address namespace (as + opposed to being a memory location for memory mapped I/O). +

+ +
Semantics:
+ +

+ The 'llvm.readport' intrinsic reads data from the hardware I/O port + specified by address and returns the value. The address and return + value must be integers, but the size is dependent upon the platform upon which + the program is code generated. For example, on x86, the address must be an + unsigned 16-bit value, and the return value must be 8, 16, or 32 bits. +

+ +
+ + + + +
+ +
Syntax:
+
+   call void (<integer type>, <integer type>)*
+             %llvm.writeport (<integer type> <value>,
+                              <integer type> <address>)
+ 
+ +
Overview:
+ +

+ The 'llvm.writeport' intrinsic writes data to the specified hardware + I/O port. +

+ +
Arguments:
+ +

+ The first argument is the value to write to the I/O port. +

+ +

+ The second argument indicates the hardware I/O address to which data should be + written. The address is in the hardware I/O address namespace (as opposed to + being a memory location for memory mapped I/O). +

+ +
Semantics:
+ +

+ The 'llvm.writeport' intrinsic writes value to the I/O port + specified by address. The address and value must be integers, but the + size is dependent upon the platform upon which the program is code generated. + For example, on x86, the address must be an unsigned 16-bit value, and the + value written must be 8, 16, or 32 bits in length. +

+ +
+ + + + +
+ +
Syntax:
+
+   declare <result> %llvm.readio (<ty> * <pointer>)
+ 
+ +
Overview:
+ +

+ The 'llvm.readio' intrinsic reads data from a memory mapped I/O + address. +

+ +
Arguments:
+ +

+ The argument to this intrinsic is a pointer indicating the memory address from + which to read the data. The data must be a + first class type. +

+ +
Semantics:
+ +

+ The 'llvm.readio' intrinsic reads data from a memory mapped I/O + location specified by pointer and returns the value. The argument must + be a pointer, and the return value must be a + first class type. However, certain architectures + may not support I/O on all first class types. For example, 32-bit processors + may only support I/O on data types that are 32 bits or less. +

+ +

+ This intrinsic enforces an in-order memory model for llvm.readio and + llvm.writeio calls on machines that use dynamic scheduling. Dynamically + scheduled processors may execute loads and stores out of order, re-ordering at + run time accesses to memory mapped I/O registers. Using these intrinsics + ensures that accesses to memory mapped I/O registers occur in program order. +

+ +
+ + + + +
+ +
Syntax:
+
+   declare void %llvm.writeio (<ty1> <value>, <ty2> * <pointer>)
+ 
+ +
Overview:
+ +

+ The 'llvm.writeio' intrinsic writes data to the specified memory + mapped I/O address. +

+ +
Arguments:
+ +

+ The first argument is the value to write to the memory mapped I/O location. + The second argument is a pointer indicating the memory address to which the + data should be written. +

+ +
Semantics:
+ +

+ The 'llvm.writeio' intrinsic writes value to the memory mapped + I/O address specified by pointer. The value must be a + first class type. However, certain architectures + may not support I/O on all first class types. For example, 32-bit processors + may only support I/O on data types that are 32 bits or less. +

+ +

+ This intrinsic enforces an in-order memory model for llvm.readio and + llvm.writeio calls on machines that use dynamic scheduling. Dynamically + scheduled processors may execute loads and stores out of order, re-ordering at + run time accesses to memory mapped I/O registers. Using these intrinsics + ensures that accesses to memory mapped I/O registers occur in program order. +

+ +
+ + + + +
+

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

+ +
+ + + + +
+ +
Syntax:
+
+   declare void %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. +

+
+ + + + + +
+ +
Syntax:
+
+   declare void %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. +

+
+ + + + + +
+ +
Syntax:
+
+   declare void %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. +

+
+ + + + + +
+ +
Syntax:
+
+   declare bool %llvm.isunordered(<float or double> Val1, <float or double> Val2)
+ 
+ +
Overview:
+ +

+ The 'llvm.isunordered' intrinsic returns true if either or both of the + specified floating point values is a NAN. +

+ +
Arguments:
+ +

+ The arguments are floating point numbers of the same type. +

+ +
Semantics:
+ +

+ If either or both of the arguments is a SNAN or QNAN, it returns true, otherwise + false. +

+
+ + + + + +
+ +
Syntax:
+
+   declare <float or double> %llvm.sqrt(<float or double> Val)
+ 
+ +
Overview:
+ +

+ The 'llvm.sqrt' intrinsic returns the sqrt of the specified operand, + returning the same value as the libm 'sqrt' function would. Unlike + sqrt in libm, however, llvm.sqrt has undefined behavior for + negative numbers (which allows for better optimization). +

+ +
Arguments:
+ +

+ The argument and return value are floating point numbers of the same type. +

+ +
Semantics:
+ +

+ This function returns the sqrt of the specified operand if it is a positive + floating point number. +

+
+ + + + +
+

+ LLVM provides intrinsics for a few important bit counting operations. + These allow efficient code generation for some algorithms. +

+ +
+ + + + +
+ +
Syntax:
+
+   declare int %llvm.ctpop(int <src>)
+ 
+ 
+ +
Overview:
+ +

+ The 'llvm.ctpop' intrinsic counts the number of ones in a variable. +

+ +
Arguments:
+ +

+ The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type. +

+ +
Semantics:
+ +

+ The 'llvm.ctpop' intrinsic counts the 1's in a variable. +

+
+ + + + +
+ +
Syntax:
+
+   declare int %llvm.ctlz(int <src>)
+ 
+ 
+ +
Overview:
+ +

+ The 'llvm.ctlz' intrinsic counts the number of leading zeros in a + variable. +

+ +
Arguments:
+ +

+ The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type. +

+ +
Semantics:
+ +

+ The 'llvm.ctlz' intrinsic counts the leading (most significant) zeros + in a variable. If the src == 0 then the result is the size in bits of the type + of src. For example, llvm.cttz(int 2) = 30. +

+
+ + + + + + +
+ +
Syntax:
+
+   declare int %llvm.cttz(int <src>)
+ 
+ 
+ +
Overview:
+ +

+ The 'llvm.cttz' intrinsic counts the number of trailing zeros. +

+ +
Arguments:
+ +

+ The only argument is the value to be counted. The argument may be of any + integer type. The return type must match the argument type. +

+ +
Semantics:
+ +

+ The 'llvm.cttz' intrinsic counts the trailing (least significant) zeros + in a variable. If the src == 0 then the result is the size in bits of the type + of src. For example, llvm.cttz(2) = 1. +

+
+ + + + +
+

+ 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: 2005/11/08 20:06:34 $ +
+ + Index: llvm-www/releases/1.6/docs/Lexicon.html diff -c /dev/null llvm-www/releases/1.6/docs/Lexicon.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/Lexicon.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,172 ---- + + + + + The LLVM Lexicon + + + + + +
The LLVM Lexicon
+

NOTE: This document is a work in progress!

+ +
Table Of Contents
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
- A -
ADCE
- B -
BURS
- C -
CSE
- D -
DSADSE
- I -
IPAIPO
- L -
LICMLoad-VN
- P -
PRE
- R -
Reassociation
- S -
SCCPSSA
+
+ + +
Definitions
+ + + +
+
+
ADCE
+
Aggressive Dead Code Elimination
+
+
+ + +
+
+
BURS
+
Bottom Up Rewriting System - A method of instruction selection for + code generation. An example is the BURG tool.
+
+
+ + +
+
+
CSE
+
Common Subexpression Elimination. An optimization that removes common + subexpression compuation. For example (a+b)*(a+b) has two + subexpressions that are the same: (a+b). This optimization would + perform the addition only once and then perform the multiply (but only if + its compulationally correct/safe). +
+
+ + +
+
+
DSA
+
Data Structure Analysis
+
DSE
+
Dead Store Elimination
+
+
+ + +
+
+
IPA
+
Inter-Procedural Analysis. Refers to any variety of code analysis that + occurs between procedures, functions or compilation units (modules).
+
IPO
+
Inter-Procedural Optimization. Refers to any variety of code + optimization that occurs between procedures, functions or compilation units + (modules).
+
+
+ + +
+
+
LICM
+
Loop Invariant Code Motion
+
Load-VN
+
Load Value Numbering
+
+
+ + + +
+
+
PRE
+
Partial Redundancy Elimination
+
+
+ + + +
+
+
Reassociation
Rearranging + associative expressions to promote better redundancy elimination and other + optimization. For example, changing (A+B-A) into (B+A-A), permitting it to + be optimized into (B+0) then (B). +
+
+ + + +
+
+
SCCP
+
Sparse Conditional Constant Propagation +
SSA
+
Static Single Assignment
+
+
+ +
+
Valid CSS!Valid HTML 4.01!The LLVM Team
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/Makefile diff -c /dev/null llvm-www/releases/1.6/docs/Makefile:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/Makefile Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,73 ---- + ##===- 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. + # + ##===----------------------------------------------------------------------===## + + LEVEL := .. + DIRS := CommandGuide + + include $(LEVEL)/Makefile.common + + HTML := $(wildcard $(PROJ_SRC_DIR)/*.html) \ + $(wildcard $(PROJ_SRC_DIR)/*.css) + IMAGES := $(wildcard $(PROJ_SRC_DIR)/img/*.*) + DOXYFILES := doxygen.cfg.in doxygen.css doxygen.footer doxygen.header \ + doxygen.intro + EXTRA_DIST := $(HTML) $(DOXYFILES) llvm.css CommandGuide img + + .PHONY: install-html install-doxygen doxygen + + ifeq ($(ENABLE_DOXYGEN),1) + install-local:: install-html install-doxygen + else + install-local:: install-html + endif + + install-html: $(PROJ_OBJ_DIR)/html.tar.gz + $(Echo) Installing HTML documentation + $(Verb) $(MKDIR) $(PROJ_docsdir)/html + $(Verb) $(MKDIR) $(PROJ_docsdir)/html/img + $(Verb) $(DataInstall) $(HTML) $(PROJ_docsdir)/html + $(Verb) $(DataInstall) $(IMAGES) $(PROJ_docsdir)/html/img + $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/html.tar.gz $(PROJ_docsdir) + + $(PROJ_OBJ_DIR)/html.tar.gz: $(HTML) + $(Echo) Packaging HTML documentation + $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/html.tar + $(Verb) cd $(PROJ_SRC_DIR) && \ + $(TAR) cf $(PROJ_OBJ_DIR)/html.tar *.html + $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/html.tar + + install-doxygen: doxygen + $(Echo) Installing doxygen documentation + $(Echo) Installing doxygen documentation + $(Verb) $(MKDIR) $(PROJ_docsdir)/html/doxygen + $(Verb) $(DataInstall) $(PROJ_OBJ_DIR)/doxygen.tar.gz $(PROJ_docsdir) + $(Verb) cd $(PROJ_OBJ_DIR)/doxygen && \ + $(FIND) . -type f -exec \ + $(DataInstall) {} $(PROJ_docsdir)/html/doxygen \; + + doxygen: $(PROJ_OBJ_DIR)/doxygen.tar.gz + + $(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg + $(Echo) Building doxygen documentation + $(Verb) if test -e $(PROJ_OBJ_DIR)/doxygen ; then \ + $(RM) -rf $(PROJ_OBJ_DIR)/doxygen ; \ + fi + $(Verb) $(DOXYGEN) $(PROJ_OBJ_DIR)/doxygen.cfg + $(Echo) Packaging doxygen documentation + $(Verb) $(RM) -rf $@ $(PROJ_OBJ_DIR)/doxygen.tar + $(Verb) $(TAR) cf $(PROJ_OBJ_DIR)/doxygen.tar doxygen + $(Verb) $(GZIP) $(PROJ_OBJ_DIR)/doxygen.tar + + userloc: $(LLVM_SRC_ROOT)/docs/userloc.html + + $(LLVM_SRC_ROOT)/docs/userloc.html: + $(Echo) Making User LOC Table + $(Verb) cd $(LLVM_SRC_ROOT) ; ./utils/userloc.pl -details -recurse \ + -html lib include tools runtime utils examples autoconf test > docs/userloc.html + Index: llvm-www/releases/1.6/docs/MakefileGuide.html diff -c /dev/null llvm-www/releases/1.6/docs/MakefileGuide.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/MakefileGuide.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,1006 ---- + + + + + LLVM Makefile Guide + + + + +
LLVM Makefile Guide
+ +
    +
  1. Introduction
  2. +
  3. General Concepts +
      +
    1. Projects
    2. +
    3. Variable Values
    4. +
    5. Including Makefiles +
        +
      1. Makefile
      2. +
      3. Makefile.common
      4. +
      5. Makefile.config
      6. +
      7. Makefile.rules
      8. +
      +
    6. +
    7. Comments
    8. +
    +
  4. +
  5. Tutorial +
      +
    1. Libraries +
        +
      1. Bytecode Modules
      2. +
      +
    2. +
    3. Tools +
        +
      1. JIT Tools
      2. +
      +
    4. +
    5. Projects
    6. +
    +
  6. +
  7. Targets Supported +
      +
    1. all
    2. +
    3. all-local
    4. +
    5. check
    6. +
    7. check-local
    8. +
    9. clean
    10. +
    11. clean-local
    12. +
    13. dist
    14. +
    15. dist-check
    16. +
    17. dist-clean
    18. +
    19. install
    20. +
    21. preconditions
    22. +
    23. printvars
    24. +
    25. reconfigure
    26. +
    27. spotless
    28. +
    29. tags
    30. +
    31. uninstall
    32. +
    +
  8. +
  9. Using Variables +
      +
    1. Control Variables
    2. +
    3. Override Variables
    4. +
    5. Readable Variables
    6. +
    7. Internal Variables
    8. +
    +
  10. +
+ +
+

Written by Reid Spencer

+
+ + + + + +
+

This document provides usage information about the LLVM makefile + system. While loosely patterned after the BSD makefile system, LLVM has taken + a departure from BSD in order to implement additional features needed by LLVM. + Although makefile systems such as automake were attempted at one point, it + has become clear that the features needed by LLVM and the Makefile norm are + too great to use a more limited tool. Consequently, LLVM requires simply GNU + Make 3.79, a widely portable makefile processor. LLVM unabashedly makes heavy + use of the features of GNU Make so the dependency on GNU Make is firm. If + you're not familiar with make, it is recommended that you read the + GNU Makefile Manual + .

+

While this document is rightly part of the + LLVM Programmer's Manual, it is treated + separately here because of the volume of content and because it is often an + early source of bewilderment for new developers.

+
+ + + + + +
+

The LLVM Makefile System is the component of LLVM that is responsible for + building the software, testing it, generating distributions, checking those + distributions, installing and uninstalling, etc. It consists of a several + files throughout the source tree. These files and other general concepts are + described in this section.

+
+ + + +
+

The LLVM Makefile System is quite generous. It not only builds its own + software, but it can build yours too. Built into the system is knowledge of + the llvm/projects directory. Any directory under projects + that has both a configure script and a Makefile is assumed + to be a project that uses the LLVM Makefile system. Building software that + uses LLVM does not require the LLVM Makefile System nor even placement in the + llvm/projects directory. However, doing so will allow your project + to get up and running quickly by utilizing the built-in features that are used + to compile LLVM. LLVM compiles itself using the same features of the makefile + system as used for projects.

+

For complete details on setting up your projects configuration, simply + mimic the llvm/projects/sample project or for further details, + consult the Projects.html page.

+
+ + + +
+

To use the makefile system, you simply create a file named + Makefile in your directory and declare values for certain variables. + The variables and values that you select determine what the makefile system + will do. These variables enable rules and processing in the makefile system + that automatically Do The Right Thing™. +

+ + + +
+

Setting variables alone is not enough. You must include into your Makefile + additional files that provide the rules of the LLVM Makefile system. The + various files involved are described in the sections that follow.

+
+ + + +
+

Each directory to participate in the build needs to have a file named + Makefile. This is the file first read by make. It has three + sections:

+
    +
  1. Settable Variables - Required that must be set + first.
  2. +
  3. include $(LEVEL)/Makefile.common + - include the LLVM Makefile system. +
  4. Override Variables - Override variables set by + the LLVM Makefile system. +
+
+ + + +
+

Every project must have a Makefile.common file at its top source + directory. This file serves three purposes:

+
    +
  1. It includes the project's configuration makefile to obtain values + determined by the configure script. This is done by including the + $(LEVEL)/Makefile.config file.
  2. +
  3. It specifies any other (static) values that are needed throughout the + project. Only values that are used in all or a large proportion of the + project's directories should be placed here.
  4. +
  5. It includes the standard rules for the LLVM Makefile system, + $(LLVM_SRC_ROOT)/Makefile.rules. + This file is the "guts" of the LLVM Makefile system.
  6. +
+
+ + + +
+

Every project must have a Makefile.config at the top of its + build directory. This file is generated by the + configure script from the pattern provided by the + Makefile.config.in file located at the top of the project's + source directory. The contents of this file depend largely on what + configuration items the project uses, however most projects can get what they + need by just relying on LLVM's configuration found in + $(LLVM_OBJ_ROOT)/Makefile.config. +

+ + + +
+

This file, located at $(LLVM_SRC_ROOT)/Makefile.rules is the heart + of the LLVM Makefile System. It provides all the logic, dependencies, and + rules for building the targets supported by the system. What it does largely + depends on the values of make variables that + have been set before Makefile.rules is included. +

+ + + +
+

User Makefiles need not have comments in them unless the construction is + unusual or it does not strictly follow the rules and patterns of the LLVM + makefile system. Makefile comments are invoked with the pound (#) character. + The # character and any text following it, to the end of the line, are ignored + by make.

+
+ + + + +
+

This section provides some examples of the different kinds of modules you + can build with the LLVM makefile system. In general, each directory you + provide will build a single object although that object may be composed of + additionally compiled components.

+
+ + + +
+

Only a few variable definitions are needed to build a regular library. + Normally, the makefile system will build all the software into a single + libname.o (pre-linked) object. This means the library is not + searchable and that the distinction between compilation units has been + dissolved. Optionally, you can ask for a shared library (.so), archive library + (.a) or to not have the default (relinked) library built. For example:

+

+       LIBRARYNAME = mylib
+       SHARED_LIBRARY = 1
+       ARCHIVE_LIBRARY = 1
+       DONT_BUILT_RELINKED = 1
+   
+

says to build a library named "mylib" with both a shared library + (mylib.so) and an archive library (mylib.a) version but + not to build the relinked object (mylib.o). The contents of all the + libraries produced will be the same, they are just constructed differently. + Note that you normally do not need to specify the sources involved. The LLVM + Makefile system will infer the source files from the contents of the source + directory.

+

The LOADABLE_MODULE=1 directive can be used in conjunction with + SHARED_LIBRARY=1 to indicate that the resulting shared library should + be openable with the dlopen function and searchable with the + dlsym function (or your operating system's equivalents). While this + isn't strictly necessary on Linux and a few other platforms, it is required + on systems like HP-UX and Darwin. You should use LOADABLE_MODULE for + any shared library that you intend to be loaded into an tool via the + -load option. See the + WritingAnLLVMPass.html document + for an example of why you might want to do this. +

+ + + +
+

In some situations, it is desireable to build a single bytecode module from + a variety of sources, instead of an archive, shared library, or bytecode + library. Bytecode modules can be specified in addition to any of the other + types of libraries by defining the MODULE_NAME + variable. For example:

+

+       LIBRARYNAME = mylib
+       BYTECODE_LIBRARY = 1
+       MODULE_NAME = mymod
+   
+

will build a module named mymod.bc from the sources in the + directory. This module will be an aggregation of all the bytecode modules + derived from the sources. The example will also build a bytecode archive + containing a bytecode module for each compiled source file. The difference is + subtle, but important depending on how the module or library is to be linked. +

+
+ + + +
+

For building executable programs (tools), you must provide the name of the + tool and the names of the libraries you wish to link with the tool. For + example:

+

+       TOOLNAME = mytool
+       USEDLIBS = mylib
+       LLVMLIBS = LLVMSupport.a LLVMSystem.a
+   
+

says that we are to build a tool name mytool and that it requires + three libraries: mylib, LLVMSupport.a and + LLVMSystem.a.

+

Note that two different variables are use to indicate which libraries are + linked: USEDLIBS and LLVMLIBS. This distinction is necessary + to support projects. LLVMLIBS refers to the LLVM libraries found in + the LLVM object directory. USEDLIBS refers to the libraries built by + your project. In the case of building LLVM tools, USEDLIBS and + LLVMLIBS can be used interchangeably since the "project" is LLVM + itself and USEDLIBS refers to the same place as LLVMLIBS. +

+

Also note that there are two different ways of specifying a library: with a + .a suffix and without. Without the suffix, the entry refers to the + re-linked (.o) file which will include all symbols of the library. + This is useful, for example, to include all passes from a library of passes. + If the .a suffix is used then the library is linked as a searchable + library (with the -l option). In this case, only the symbols that are + unresolved at that point will be resolved from the library, if they + exist. Other (unreferenced) symbols will not be included when the .a + syntax is used. Note that in order to use the .a suffix, the library + in question must have been built with the ARCHIVE_LIBRARY option set. +

+
+ + + +
+

Many tools will want to use the JIT features of LLVM. However, getting the + right set of libraries to link with is tedious, platform specific, and error + prone. Additionally, the JIT has special linker switch options that it needs. + Consequently, to make it easier to build tools that use the JIT, you can + use a special value for the LLVMLIBS variable:

+

+       TOOLNAME = my_jit_tool
+       USEDLIBS = mylib
+       LLVMLIBS = JIT
+   
+

Using a value of JIT for LLVMLIBS tells the makefile + system to construct a special value for LLVMLIBS that gives the program all + the LLVM libraries needed to run the JIT. Any additional libraries needed can + still be specified with USEDLIBS. To get a full understanding of how + this changes the linker command, it is recommended that you:

+

+       cd examples/Fibonacci
+       make VERBOSE=1
+   
+

By default, using LLVMLIBS=JIT will link in enough to support JIT + code generation for the architecture on which the tool is linked. If you need + additional target architectures linked in, you may specify them on the command + line or in your Makefile. For example:

+

+       ENABLE_X86_JIT=1
+       ENABLE_SPARCV9_JIT=1
+       ENALBE_PPC_JIT=1
+   
+

will cause the tool to be able to generate code for all three platforms. +

+
+ + + + + +
+

This section describes each of the targets that can be built using the LLVM + Makefile system. Any target can be invoked from any directory but not all are + applicable to a given directory (e.g. "check", "dist" and "install" will + always operate as if invoked from the top level directory).

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Target NameImplied TargetsTarget Description
allCompile the software recursively. Default target. +
all-localCompile the software in the local directory only. +
checkChange to the test directory in a project and run the + test suite there. +
check-localRun a local test suite. Generally this is only defined in the + Makefile of the project's test directory. +
cleanRemove built objects recursively. +
clean-localRemove built objects from the local directory only. +
distallPrepare a source distribution tarball. +
dist-checkallPrepare a source distribution tarball and check that it builds. +
dist-cleancleanClean source distribution tarball temporary files. +
installallCopy built objects to installation directory. +
preconditionsallCheck to make sure configuration and makefiles are up to date. +
printvarsallPrints variables defined by the makefile system (for debugging). +
tagsMake C and C++ tags files for emacs and vi. +
uninstallRemove built objects from installation directory. +
+
+ + + +
+

When you invoke make with no arguments, you are implicitly + instructing it to seek the "all" target (goal). This target is used for + building the software recursively and will do different things in different + directories. For example, in a lib directory, the "all" target will + compile source files and generate libraries. But, in a tools + directory, it will link libraries and generate executables.

+
+ + + +
+

This target is the same as all but it operates only on + the current directory instead of recursively.

+
+ + + +
+

This target can be invoked from anywhere within a project's directories + but always invokes the check-local target + in the project's test directory, if it exists and has a + Makefile. A warning is produced otherwise. If + TESTSUITE is defined on the make + command line, it will be passed down to the invocation of + make check-local in the test directory. The intended usage + for this is to assist in running specific suites of tests. If + TESTSUITE is not set, the implementation of check-local + should run all normal tests. It is up to the project to define what + different values for TESTSUTE will do. See the + TestingGuide for further details.

+
+ + + +
+

This target should be implemented by the Makefile in the project's + test directory. It is invoked by the check target elsewhere. + Each project is free to define the actions of check-local as + appropriate for that project. The LLVM project itself uses dejagnu to run a + suite of feature and regresson tests. Other projects may choose to use + dejagnu or any other testing mechanism.

+
+ + + +
+

This target cleans the build directory, recursively removing all things + that the Makefile builds. The cleaning rules have been made guarded so they + shouldn't go awry (via rm -f $(UNSET_VARIABLE)/* which will attempt + to erase the entire directory structure.

+
+ + + +
+

This target does the same thing as clean but only for the current + (local) directory.

+
+ + + +
+

This target builds a distribution tarball. It first builds the entire + project using the all target and then tars up the necessary files and + compresses it. The generated tarball is sufficient for a casual source + distribution, but probably not for a release (see dist-check).

+
+ + + +
+

This target does the same thing as the dist target but also checks + the distribution tarball. The check is made by unpacking the tarball to a new + directory, configuring it, building it, installing it, and then verifying that + the installation results are correct (by comparing to the original build). + This target can take a long time to run but should be done before a release + goes out to make sure that the distributed tarball can actually be built into + a working release.

+
+ + + +
+

This is a special form of the clean clean target. It performs a + normal clean but also removes things pertaining to building the + distribution.

+
+ + + +
+

This target finalizes shared objects and executables and copies all + libraries, headers, executables and documentation to the directory given + with the --prefix option to configure. When completed, + the prefix directory will have everything needed to use LLVM.

+

The LLVM makefiles can generate complete internal documentation + for all the classes by using doxygen. By default, this feature is + not enabled because it takes a long time and generates a massive + amount of data (>100MB). If you want this feature, you must configure LLVM + with the --enable-doxygen switch and ensure that a modern version of doxygen + (1.3.7 or later) is available in your PATH. You can download + doxygen from + + here. +

+ + + +
+

This utility target checks to see if the Makefile in the object + directory is older than the Makefile in the source directory and + copies it if so. It also reruns the configure script if that needs to + be done and rebuilds the Makefile.config file similarly. Users may + overload this target to ensure that sanity checks are run before any + building of targets as all the targets depend on preconditions.

+
+ + + +
+

This utility target just causes the LLVM makefiles to print out some of + the makefile variables so that you can double check how things are set.

+
+ + + +
+

This utility target will force a reconfigure of LLVM or your project. It + simply runs $(PROJ_OBJ_ROOT)/config.status --recheck to rerun the + configuration tests and rebuild the configured files. This isn't generally + useful as the makefiles will reconfigure themselves whenever its necessary. +

+
+ + + +
+

This utility target, only available when $(PROJ_OBJ_ROOT) is not + the same as $(PROJ_SRC_ROOT), will completely clean the + $(PROJ_OBJ_ROOT) directory by removing its content entirely and + reconfiguring the directory. This returns the $(PROJ_OBJ_ROOT) + directory to a completely fresh state. All content in the directory except + configured files and top-level makefiles will be lost.

+

Use with caution.

+
+ + + +
+

This target will generate a TAGS file in the top-level source + directory. It is meant for use with emacs, XEmacs, or ViM. The TAGS file + provides an index of symbol definitions so that the editor can jump you to the + definition quickly.

+
+ + + +
+

This target is the opposite of the install target. It removes the + header, library and executable files from the installation directories. Note + that the directories themselves are not removed because it is not guaranteed + that LLVM is the only thing installing there (e.g. --prefix=/usr).

+
+ + + + +
+

Variables are used to tell the LLVM Makefile System what to do and to + obtain information from it. Variables are also used internally by the LLVM + Makefile System. Variable names that contain only the upper case alphabetic + letters and underscore are intended for use by the end user. All other + variables are internal to the LLVM Makefile System and should not be relied + upon nor modified. The sections below describe how to use the LLVM Makefile + variables.

+
+ + + +
+

Variables listed in the table below should be set before the + inclusion of $(LEVEL)/Makefile.common. + These variables provide input to the LLVM make system that tell it what to do + for the current directory.

+
+
BUILD_ARCHIVE
+
If set to any value, causes an archive (.a) library to be built.
+
BUILT_SOURCES
+
Specifies a set of source files that are generated from other source + files. These sources will be built before any other target processing to + ensure they are present.
+
BYTECODE_LIBRARY
+
If set to any value, causes a bytecode library (.bc) to be built.
+
CONFIG_FILES
+
Specifies a set of configuration files to be installed.
+
DIRS
+
Specifies a set of directories, usually children of the current + directory, that should also be made using the same goal. These directories + will be built serially.
+
DISABLE_AUTO_DEPENDENCIES
+
If set to any value, causes the makefiles to not automatically + generate dependencies when running the compiler. Use of this feature is + discouraged and it may be removed at a later date.
+
DONT_BUILD_RELINKED
+
If set to any value, causes a relinked library (.o) not to be built. By + default, libraries are built as re-linked since most LLVM libraries are + needed in their entirety and re-linked libraries will be linked more quickly + than equivalent archive libraries.
+
ENABLE_OPTIMIZED
+
If set to any value, causes the build to generate optimized objects, + libraries and executables. This alters the flags specified to the compilers + and linkers. Generally debugging won't be a fun experience with an optimized + build.
+
ENABLE_PROFILING
+
If set to any value, causes the build to generate both optimized and + profiled objects, libraries and executables. This alters the flags specified + to the compilers and linkers to ensure that profile data can be collected + from the tools built. Use the gprof tool to analyze the output from + the profiled tools (gmon.out).
+
EXPERIMENTAL_DIRS
+
Specify a set of directories that should be built, but if they fail, it + should not cause the build to fail. Note that this should only be used + temporarily while code is being written.
+
EXPORTED_SYMBOL_FILE
+
Specifies the name of a single file that contains a list of the + symbols to be exported by the linker. One symbol per line.
+
EXPORTED_SYMBOL_LIST
+
Specifies a set of symbols to be exported by the linker.
+
EXTRA_DIST
+
Specifies additional files that should be distributed with LLVM. All + source files, all built sources, all Makefiles, and most documentation files + will be automatically distributed. Use this variable to distribute any + files that are not automatically distributed.
+
FAKE_SOURCES(optional) +
+
This variable is like SOURCES except that + the source files don't need to exist. The makefiles only use + FAKE_SOURCES to create the names of derived objects that should be + included in the directory's result. It is assumed that the project's + Makefile will define how to build the derived objects + necessary.
+
KEEP_SYMBOLS
+
If set to any value, specifies that when linking executables the + makefiles should retain debug symbols in the executable. Normally, symbols + are stripped from the executable.
+
LEVEL(required)
+
Specify the level of nesting from the top level. This variable must be + set in each makefile as it is used to find the top level and thus the other + makefiles.
+
LIBRARYNAME
+
Specify the name of the library to be built. (Required For + Libraries)
+
LLVMLIBS
+
Specifies the set of libraries from the LLVM $(ObjDir) that will be + linked into the tool or library.
+
LOADABLE_MODULE
+
If set to any value, causes the shared library being built to also be + a loadable module. Loadable modules can be opened with the dlopen() function + and searched with dlsym (or the operating system's equivalent). Note that + setting this variable without also setting SHARED_LIBRARY will have + no effect.
+
MODULE_NAME
+
Specifies the name of a bytecode module to be created. A bytecode + module can be specified in conjunction with other kinds of library builds + or by itself. It constructs from the sources a single linked bytecode + file.
+
OPTIONAL_DIRS
+
Specify a set of directories that may be built, if they exist, but its + not an error for them not to exist.
+
PARALLEL_DIRS
+
Specify a set of directories to build recursively and in parallel if + the -j option was used with make.
+
SHARED_LIBRARY
+
If set to any value, causes a shared library (.so) to be built in + addition to any other kinds of libraries. Note that this option will cause + all source files to be built twice: once with options for position + independent code and once without. Use it only where you really need a + shared library.
+
SOURCES(optional)
+
Specifies the list of source files in the current directory to be + built. Source files of any type may be specified (programs, documentation, + config files, etc.). If not specified, the makefile system will infer the + set of source files from the files present in the current directory.
+
SUFFIXES
+
Specifies a set of filename suffixes that occur in suffix match rules. + Only set this if your local Makefile specifies additional suffix + match rules.
+
TARGET
+
Specifies the name of the LLVM code generation target that the + current directory builds. Setting this variable enables additional rules to + build .inc files from .td files.
+
TESTSUITE
+
Specifies the directory of tests to run in llvm/test.
+
TOOLNAME
+
Specifies the name of the tool that the current directory should + build.
+
TOOL_VERBOSE
+
Implies VERBOSE and also tells each tool invoked to be verbose. This is + handy when you're trying to see the sub-tools invoked by each tool invoked + by the makefile. For example, this will pass -v to the GCC + compilers which causes it to print out the command lines it uses to invoke + sub-tools (compiler, assembler, linker).
+
USEDLIBS
+
Specifies the list of project libraries that will be linked into the + tool or library.
+
VERBOSE
+
Tells the Makefile system to produce detailed output of what it is doing + instead of just summary comments. This will generate a LOT of output.
+
+
+ + + +
+

Override variables can be used to override the default + values provided by the LLVM makefile system. These variables can be set in + several ways:

+
    +
  • In the environment (e.g. setenv, export) -- not recommended.
  • +
  • On the make command line -- recommended.
  • +
  • On the configure command line
  • +
  • In the Makefile (only after the inclusion of $(LEVEL)/Makefile.common).
  • +
+

The override variables are given below:

+
+
AR (defaulted)
+
Specifies the path to the ar tool.
+
BISON(configured)
+
Specifies the path to the bison tool.
+
PROJ_OBJ_DIR
+
The directory into which the products of build rules will be placed. + This might be the same as + PROJ_SRC_DIR but typically is + not.
+
PROJ_SRC_DIR
+
The directory which contains the source files to be built.
+
BURG
+
Specifies the path to the burg tool.
+
BZIP2(configured)
+
The path to the bzip2 tool.
+
CC(configured)
+
The path to the 'C' compiler.
+
CFLAGS
+
Additional flags to be passed to the 'C' compiler.
+
CXX
+
Specifies the path to the C++ compiler.
+
CXXFLAGS
+
Additional flags to be passed to the C++ compiler.
+
DATE(configured)
+
Specifies the path to the date program or any program that can + generate the current date and time on its standard output
+
DOT(configured)
+
Specifies the path to the dot tool or false if there + isn't one.
+
ECHO(configured)
+
Specifies the path to the echo tool for printing output.
+
ETAGS(configured)
+
Specifies the path to the etags tool.
+
ETAGSFLAGS(configured)
+
Provides flags to be passed to the etags tool.
+
EXEEXT(configured)
+
Provides the extension to be used on executables built by the makefiles. + The value may be empty on platforms that do not use file extensions for + executables (e.g. Unix).
+
FLEX(configured)
+
Specifies the path to the flex tool.
+
GCCLD(defaulted)
+
Specifies the path to the gccld tool.
+
INSTALL(configured)
+
Specifies the path to the install tool.
+
LDFLAGS(configured)
+
Allows users to specify additional flags to pass to the linker.
+
LIBS(configured)
+
The list of libraries that should be linked with each tool.
+
LIBTOOL(configured)
+
Specifies the path to the libtool tool. This tool is renamed + mklib by the configure script and always located in the +
LLVMAS(defaulted)
+
Specifies the path to the llvm-as tool.
+
LLVMGCC(defaulted)
+
Specifies the path to the LLVM version of the GCC 'C' Compiler
+
LLVMGXX(defaulted)
+
Specifies the path to the LLVM version of the GCC C++ Compiler
+
LLVM_OBJ_ROOT(configured)
+
Specifies the top directory into which the output of the build is + placed.
+
LLVM_SRC_ROOT(configured)
+
Specifies the top directory in which the sources are found.
+
LLVM_TARBALL_NAME(configured)
+
Specifies the name of the distribution tarball to create. This is + configured from the name of the project and its version number.
+
MKDIR(defaulted)
+
Specifies the path to the mkdir tool that creates + directories.
+
PLATFORMSTRIPOPTS
+
The options to provide to the linker to specify that a stripped (no + symbols) executable should be built.
+
RANLIB(defaulted)
+
Specifies the path to the ranlib tool.
+
RM(defaulted)
+
Specifies the path to the rm tool.
+
SED(defaulted)
+
Specifies the path to the sed tool.
+
SHLIBEXT(configured)
+
Provides the filename extension to use for shared libraries.
+
TBLGEN(defaulted)
+
Specifies the path to the tblgen tool.
+
TAR(defaulted)
+
Specifies the path to the tar tool.
+
ZIP(defaulted)
+
Specifies the path to the zip tool.
+
+
+ + + +
+

Variables listed in the table below can be used by the user's Makefile but + should not be changed. Changing the value will generally cause the build to go + wrong, so don't do it.

+
+
bindir
+
The directory into which executables will ultimately be installed. This + value is derived from the --prefix option given to + configure.
+
BuildMode
+
The name of the type of build being performed: Debug, Release, or + Profile
+
bytecode_libdir
+
The directory into which bytecode libraries will ultimately be installed. + This value is derived from the --prefix option given to + configure.
+
ConfigureScriptFLAGS
+
Additional flags given to the configure script when + reconfiguring.
+
DistDir
+
The current directory for which a distribution copy is being + made.
+
Echo
+
The LLVM Makefile System output command. This provides the + llvm[n] prefix and starts with @ so the command itself is not + printed by make.
+
EchoCmd
+
Same as Echo but without the leading @. +
+
includedir
+
The directory into which include files will ultimately be installed. + This value is derived from the --prefix option given to + configure.
+
libdir
+
The directory into which native libraries will ultimately be installed. + This value is derived from the --prefix option given to + configure.
+
LibDir
+
The configuration specific directory into which libraries are placed + before installation.
+
MakefileConfig
+
Full path of the Makefile.config file.
+
MakefileConfigIn
+
Full path of the Makefile.config.in file.
+
ObjDir
+
The configuration and directory specific directory where build objects + (compilation results) are placed.
+
SubDirs
+
The complete list of sub-directories of the current directory as + specified by other variables.
+
Sources
+
The complete list of source files.
+
sysconfdir
+
The directory into which configuration files will ultimately be + installed. This value is derived from the --prefix option given to + configure.
+
ToolDir
+
The configuration specific directory into which executables are placed + before they are installed.
+
TopDistDir
+
The top most directory into which the distribution files are copied. +
+
Verb
+
Use this as the first thing on your build script lines to enable or + disable verbose mode. It expands to either an @ (quiet mode) or nothing + (verbose mode).
+
+
+ + + +
+

Variables listed below are used by the LLVM Makefile System + and considered internal. You should not use these variables under any + circumstances.

+

+ Archive + AR.Flags + BaseNameSources + BCCompile.C + BCCompile.CXX + BCLinkLib + Burg + C.Flags + Compile.C + CompileCommonOpts + Compile.CXX + ConfigStatusScript + ConfigureScript + CPP.Flags + CPP.Flags + CXX.Flags + DependFiles + DestArchiveLib + DestBytecodeLib + DestModule + DestRelinkedLib + DestSharedLib + DestTool + DistAlways + DistCheckDir + DistCheckTop + DistFiles + DistName + DistOther + DistSources + DistSubDirs + DistTarBZ2 + DistTarGZip + DistZip + ExtraLibs + FakeSources + INCFiles + InternalTargets + LD.Flags + LexFiles + LexOutput + LibName.A + LibName.BC + LibName.LA + LibName.O + LibTool.Flags + Link + LinkModule + LLVMLibDir + LLVMLibsOptions + LLVMLibsPaths + LLVMToolDir + LLVMUsedLibs + LocalTargets + LTCompile.C + LTCompile.CXX + LTInstall + Module + ObjectsBC + ObjectsLO + ObjectsO + ObjMakefiles + ParallelTargets + PreConditions + ProjLibsOptions + ProjLibsPaths + ProjUsedLibs + Ranlib + RecursiveTargets + Relink + SrcMakefiles + Strip + StripWarnMsg + TableGen + TDFiles + ToolBuildPath + TopLevelTargets + UserTargets + YaccFiles + YaccOutput +

+
+ + +
+
+ Valid CSS! + Valid HTML 4.01! + + Reid Spencer
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/ProgrammersManual.html diff -c /dev/null llvm-www/releases/1.6/docs/ProgrammersManual.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/ProgrammersManual.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,2284 ---- + + + + LLVM Programmer's Manual + + + + +
+ LLVM Programmer's Manual +
+ +
    +
  1. Introduction
  2. +
  3. General Information + +
  4. +
  5. Important and useful LLVM APIs + +
  6. +
  7. Helpful Hints for Common Operations + +
  8. + +
  9. Advanced Topics +
  10. + +
  11. The Core LLVM Class Hierarchy Reference + +
  12. +
+ + + + + + + +
+ +

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.

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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. + +
  3. 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 unfortunately no longer free since the book has been + published.
  4. + +
  5. C++ Frequently Asked + Questions
  6. + +
  7. SGI's STL Programmer's Guide - + Contains a useful Introduction to the + STL.
  8. + +
  9. Bjarne Stroustrup's C++ + Page
  10. + +
  11. + Bruce Eckel's Thinking in C++, 2nd ed. Volume 2 Revision 4.0 (even better, get + the book).
  12. + +
+ +

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.

+ +
+ + + + + + + + + + +
+ +

Here we highlight some LLVM APIs that are generally useful and good to + know about when writing transformations.

+ +
+ + + + +
+ +

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 llvm/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.

+ +

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.

+ +
+ + + + +
+ +

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 "llvm/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.

+ +
+ + + + +
+ +

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 "llvm/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 "llvm/ADT/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. + +
  3. Whenever you make a transformation, bump the counter: +
       ++NumXForms;   // I did stuff
    +
  4. +
+ +

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.

+ +
+ + + + +
+ +

Several of the important data structures in LLVM are graphs: for example + CFGs made out of LLVM BasicBlocks, CFGs made out of + LLVM MachineBasicBlocks, and + Instruction Selection + DAGs. In many cases, while debugging various parts of the compiler, it is + nice to instantly visualize these graphs.

+ +

LLVM provides several callbacks that are available in a debug build to do + exactly that. If you call the Function::viewCFG() method, for example, + the current LLVM tool will pop up a window containing the CFG for the function + where each basic block is a node in the graph, and each node contains the + instructions in the block. Similarly, there also exists + Function::viewCFGOnly() (does not include the instructions), the + MachineFunction::viewCFG() and MachineFunction::viewCFGOnly(), + and the SelectionDAG::viewGraph() methods. Within GDB, for example, + you can usually use something like "call DAG.viewGraph()" to pop + up a window. Alternatively, you can sprinkle calls to these functions in your + code in places you want to debug.

+ +

Getting this to work requires a small amount of configuration. On Unix + systems with X11, install the graphviz + toolkit, and make sure 'dot' and 'gv' are in your path. If you are running on + Mac OS/X, download and install the Mac OS/X Graphviz program, and add + /Applications/Graphviz.app/Contents/MacOS/ (or whereever you install + it) to your path. Once in your system and path are set up, rerun the LLVM + configure script and rebuild LLVM to enable this functionality.

+ +
+ + + + + + +
+ +

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.

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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&
+      std::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: std::cerr << *blk << "\n";.

+ +
+ + + + +
+ +

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 the standard error stream:

+ +

#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.

+ +
+ + + + +
+ +

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 straight-forward. + 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, + and this is a constant time operation (very efficient). 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";
}
+ +
+ + + + +
+ +

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 straight-forward 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;
};
+ +
+ + + + +
+ +

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 has "value semantics": it should be passed by value, not by + reference and 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. + If you look at its definition, it has only a single pointer member.

+ +
+ + + + +
+ +

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;
...
}
+ + + +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

Instantiating Instructions

+ +

Creation of Instructions is straight-forward: 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
    + +

    Appending to the end of a BasicBlock is so common that + the Instruction class and Instruction-derived + classes provide constructors which take a pointer to a + BasicBlock to be appended to. For example code that + looked like:

    + +
      BasicBlock *pb = ...;
    Instruction *newInst = new Instruction(...);
    pb->getInstList().push_back(newInst); // appends newInst to pb
    + +

    becomes:

    + +
      BasicBlock *pb = ...;
    Instruction *newInst = new Instruction(..., pb);
    + +

    which is much cleaner, especially if you are creating + long instruction streams.

  • + +
  • 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 an instruction from an existing sequence of instructions that form a + BasicBlock is very straight-forward. First, + you must have a pointer to the instruction that you wish to delete. Second, you + need to obtain the pointer to that instruction's basic block. You use the + pointer to the basic block to get its list of instructions and then use the + erase function to remove your instruction. For example:

+ +
  Instruction *I = .. ;
BasicBlock *BB = I->getParent();
BB->getInstList().erase(I);
+ +
+ + + + +
+ +

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 a 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.

+ + + +
+ + + + + +
+

+ This section describes some of the advanced or obscure API's that most clients + do not need to be aware of. These API's tend manage the inner workings of the + LLVM system, and only need to be accessed in unusual circumstances. +

+
+ + + + +
+ +

+ The LLVM type system has a very simple goal: allow clients to compare types for + structural equality with a simple pointer comparison (aka a shallow compare). + This goal makes clients much simpler and faster, and is used throughout the LLVM + system. +

+ +

+ Unfortunately achieving this goal is not a simple matter. In particular, + recursive types and late resolution of opaque types makes the situation very + difficult to handle. Fortunately, for the most part, our implementation makes + most clients able to be completely unaware of the nasty internal details. The + primary case where clients are exposed to the inner workings of it are when + building a recursive type. In addition to this case, the LLVM bytecode reader, + assembly parser, and linker also have to be aware of the inner workings of this + system. +

+ +

+ For our purposes below, we need three concepts. First, an "Opaque Type" is + exactly as defined in the language + reference. Second an "Abstract Type" is any type which includes an + opaque type as part of its type graph (for example "{ opaque, int }"). + Third, a concrete type is a type that is not an abstract type (e.g. "[ int, + float }"). +

+ +
+ + + + +
+ +

+ Because the most common question is "how do I build a recursive type with LLVM", + we answer it now and explain it as we go. Here we include enough to cause this + to be emitted to an output .ll file: +

+ +
+    %mylist = type { %mylist*, int }
+ 
+ +

+ To build this, use the following LLVM APIs: +

+ +
+   // Create the initial outer struct.
+   PATypeHolder StructTy = OpaqueType::get();
+   std::vector<const Type*> Elts;
+   Elts.push_back(PointerType::get(StructTy));
+   Elts.push_back(Type::IntTy);
+   StructType *NewSTy = StructType::get(Elts);
+ 
+   // At this point, NewSTy = "{ opaque*, int }". Tell VMCore that
+   // the struct and the opaque type are actually the same.
+   cast<OpaqueType>(StructTy.get())->refineAbstractTypeTo(NewSTy);
+ 
+   // NewSTy is potentially invalidated, but StructTy (a PATypeHolder) is
+   // kept up-to-date.
+   NewSTy = cast<StructType>(StructTy.get());
+ 
+   // Add a name for the type to the module symbol table (optional).
+   MyModule->addTypeName("mylist", NewSTy);
+ 
+ +

+ This code shows the basic approach used to build recursive types: build a + non-recursive type using 'opaque', then use type unification to close the cycle. + The type unification step is performed by the refineAbstractTypeTo method, which is + described next. After that, we describe the PATypeHolder class. +

+ +
+ + + + +
+

+ The refineAbstractTypeTo method starts the type unification process. + While this method is actually a member of the DerivedType class, it is most + often used on OpaqueType instances. Type unification is actually a recursive + process. After unification, types can become structurally isomorphic to + existing types, and all duplicates are deleted (to preserve pointer equality). +

+ +

+ In the example above, the OpaqueType object is definitely deleted. + Additionally, if there is an "{ \2*, int}" type already created in the system, + the pointer and struct type created are also deleted. Obviously whenever + a type is deleted, any "Type*" pointers in the program are invalidated. As + such, it is safest to avoid having any "Type*" pointers to abstract types + live across a call to refineAbstractTypeTo (note that non-abstract + types can never move or be deleted). To deal with this, the PATypeHolder class is used to maintain a stable + reference to a possibly refined type, and the AbstractTypeUser class is used to update more + complex datastructures. +

+ +
+ + + + +
+

+ PATypeHolder is a form of a "smart pointer" for Type objects. When VMCore + happily goes about nuking types that become isomorphic to existing types, it + automatically updates all PATypeHolder objects to point to the new type. In the + example above, this allows the code to maintain a pointer to the resultant + resolved recursive type, even though the Type*'s are potentially invalidated. +

+ +

+ PATypeHolder is an extremely light-weight object that uses a lazy union-find + implementation to update pointers. For example the pointer from a Value to its + Type is maintained by PATypeHolder objects. +

+ +
+ + + + +
+ +

+ Some data structures need more to perform more complex updates when types get + resolved. The SymbolTable class, for example, needs + move and potentially merge type planes in its representation when a pointer + changes.

+ +

+ To support this, a class can derive from the AbstractTypeUser class. This class + allows it to get callbacks when certain types are resolved. To register to get + callbacks for a particular type, the DerivedType::{add/remove}AbstractTypeUser + methods can be called on a type. Note that these methods only work for + abstract types. Concrete types (those that do not include an opaque objects + somewhere) can never be refined. +

+
+ + + + + +
+

This class provides a symbol table that the Function and + Module classes use for naming definitions. The symbol table can + provide a name for any Value or Type. SymbolTable is an abstract data + type. It hides the data it contains and provides access to it through a + controlled interface.

+ +

Note that the symbol table class is should not be directly accessed by most + clients. It should only be used when iteration over the symbol table names + themselves are required, which is very special purpose. Note that not all LLVM + Values have names, and those without names (i.e. they have + an empty name) do not exist in the symbol table. +

+ +

To use the SymbolTable well, you need to understand the + structure of the information it holds. The class contains two + std::map objects. The first, pmap, is a map of + Type* to maps of name (std::string) to Value*. + The second, tmap, is a map of names to Type*. Thus, Values + are stored in two-dimensions and accessed by Type and name. Types, + however, are stored in a single dimension and accessed only by name.

+ +

The interface of this class provides three basic types of operations: +

    +
  1. Accessors. Accessors provide read-only access to information + such as finding a value for a name with the + lookup method.
  2. +
  3. Mutators. Mutators allow the user to add information to the + SymbolTable with methods like + insert.
  4. +
  5. Iterators. Iterators allow the user to traverse the content + of the symbol table in well defined ways, such as the method + type_begin.
  6. +
+ +

Accessors

+
+
Value* lookup(const Type* Ty, const std::string& name) const: +
+
The lookup method searches the type plane given by the + Ty parameter for a Value with the provided name. + If a suitable Value is not found, null is returned.
+ +
Type* lookupType( const std::string& name) const:
+
The lookupType method searches through the types for a + Type with the provided name. If a suitable Type + is not found, null is returned.
+ +
bool hasTypes() const:
+
This function returns true if an entry has been made into the type + map.
+ +
bool isEmpty() const:
+
This function returns true if both the value and types maps are + empty
+
+ +

Mutators

+
+
void insert(Value *Val):
+
This method adds the provided value to the symbol table. The Value must + have both a name and a type which are extracted and used to place the value + in the correct type plane under the value's name.
+ +
void insert(const std::string& Name, Value *Val):
+
Inserts a constant or type into the symbol table with the specified + name. There can be a many to one mapping between names and constants + or types.
+ +
void insert(const std::string& Name, Type *Typ):
+
Inserts a type into the symbol table with the specified name. There + can be a many-to-one mapping between names and types. This method + allows a type with an existing entry in the symbol table to get + a new name.
+ +
void remove(Value* Val):
+
This method removes a named value from the symbol table. The + type and name of the Value are extracted from \p N and used to + lookup the Value in the correct type plane. If the Value is + not in the symbol table, this method silently ignores the + request.
+ +
void remove(Type* Typ):
+
This method removes a named type from the symbol table. The + name of the type is extracted from \P T and used to look up + the Type in the type map. If the Type is not in the symbol + table, this method silently ignores the request.
+ +
Value* remove(const std::string& Name, Value *Val):
+
Remove a constant or type with the specified name from the + symbol table.
+ +
Type* remove(const std::string& Name, Type* T):
+
Remove a type with the specified name from the symbol table. + Returns the removed Type.
+ +
Value *value_remove(const value_iterator& It):
+
Removes a specific value from the symbol table. + Returns the removed value.
+ +
bool strip():
+
This method will strip the symbol table of its names leaving + the type and values.
+ +
void clear():
+
Empty the symbol table completely.
+
+ +

Iteration

+

The following functions describe three types of iterators you can obtain + the beginning or end of the sequence for both const and non-const. It is + important to keep track of the different kinds of iterators. There are + three idioms worth pointing out:

+ + + + + + + + + + + + + + +
UnitsIteratorIdiom
Planes Of name/Value mapsPI

+ for (SymbolTable::plane_const_iterator PI = ST.plane_begin(),
+      PE = ST.plane_end(); PI != PE; ++PI ) {
+   PI->first // This is the Type* of the plane
+   PI->second // This is the SymbolTable::ValueMap of name/Value pairs
+     
All name/Type PairsTI

+ for (SymbolTable::type_const_iterator TI = ST.type_begin(),
+      TE = ST.type_end(); TI != TE; ++TI )
+   TI->first  // This is the name of the type
+   TI->second // This is the Type* value associated with the name
+     
name/Value pairs in a planeVI

+ for (SymbolTable::value_const_iterator VI = ST.value_begin(SomeType),
+      VE = ST.value_end(SomeType); VI != VE; ++VI )
+   VI->first  // This is the name of the Value
+   VI->second // This is the Value* value associated with the name
+     
+ +

Using the recommended iterator names and idioms will help you avoid + making mistakes. Of particular note, make sure that whenever you use + value_begin(SomeType) that you always compare the resulting iterator + with value_end(SomeType) not value_end(SomeOtherType) or else you + will loop infinitely.

+ +
+ +
plane_iterator plane_begin():
+
Get an iterator that starts at the beginning of the type planes. + The iterator will iterate over the Type/ValueMap pairs in the + type planes.
+ +
plane_const_iterator plane_begin() const:
+
Get a const_iterator that starts at the beginning of the type + planes. The iterator will iterate over the Type/ValueMap pairs + in the type planes.
+ +
plane_iterator plane_end():
+
Get an iterator at the end of the type planes. This serves as + the marker for end of iteration over the type planes.
+ +
plane_const_iterator plane_end() const:
+
Get a const_iterator at the end of the type planes. This serves as + the marker for end of iteration over the type planes.
+ +
value_iterator value_begin(const Type *Typ):
+
Get an iterator that starts at the beginning of a type plane. + The iterator will iterate over the name/value pairs in the type plane. + Note: The type plane must already exist before using this.
+ +
value_const_iterator value_begin(const Type *Typ) const:
+
Get a const_iterator that starts at the beginning of a type plane. + The iterator will iterate over the name/value pairs in the type plane. + Note: The type plane must already exist before using this.
+ +
value_iterator value_end(const Type *Typ):
+
Get an iterator to the end of a type plane. This serves as the marker + for end of iteration of the type plane. + Note: The type plane must already exist before using this.
+ +
value_const_iterator value_end(const Type *Typ) const:
+
Get a const_iterator to the end of a type plane. This serves as the + marker for end of iteration of the type plane. + Note: the type plane must already exist before using this.
+ +
type_iterator type_begin():
+
Get an iterator to the start of the name/Type map.
+ +
type_const_iterator type_begin() cons:
+
Get a const_iterator to the start of the name/Type map.
+ +
type_iterator type_end():
+
Get an iterator to the end of the name/Type map. This serves as the + marker for end of iteration of the types.
+ +
type_const_iterator type_end() const:
+
Get a const-iterator to the end of the name/Type map. This serves + as the marker for end of iteration of the types.
+ +
plane_const_iterator find(const Type* Typ ) const:
+
This method returns a plane_const_iterator for iteration over + the type planes starting at a specific plane, given by \p Ty.
+ +
plane_iterator find( const Type* Typ :
+
This method returns a plane_iterator for iteration over the + type planes starting at a specific plane, given by \p Ty.
+ +
+
+ + + + + + + +
+ +

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.

+ +
+ + + + +
+ +

#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 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.

+ +
+ + + + +
+ +
    +
  • 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);
    +
+ +
+ + + + +
+ +

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

+ +
+ + + + +
+ +

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
    + op_iterator op_begin() - Get an iterator to the start of + the operand list.
    + op_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.

  • +
+ +
+ + + + +
+ +

#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.

+ +
+ + + + +
+ +
    +
  • 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

  • +
+ +
+ + + + +
+ +

#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.

+ +
+ + + + +
+ +
    + +
  • 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() + 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.

  • + +
+ +
+ + + + +
+ +

#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 enumeration.

+ +

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.

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

  • +
+ +
+ + + + +
+ +

#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.

+ +

Note that Function is a GlobalValue + and therefore also a Constant. The value of the function + is its address (after linking) which is guaranteed to be constant.

+
+ + + + +
+ +
    +
  • Function(const FunctionType + *Ty, LinkageTypes Linkage, 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 what type of linkage the function should have. 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() + size(), empty() + +

    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::arg_iterator - Typedef for the argument list + iterator
    + Function::const_arg_iterator - Typedef for const_iterator.
    + + arg_begin(), arg_end() + arg_size(), arg_empty() + +

    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.

  • +
+ +
+ + + + +
+ +

#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).

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

  • +
+ +
+ + + + +
+ +

#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.

+ +
+ + + + +
+ +
    +
  • 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() + size(), empty() + +

    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::global_iterator - Typedef for global variable list iterator
    + + Module::const_global_iterator - Typedef for const_iterator.
    + + global_begin(), global_end() + global_size(), global_empty() + +

    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.

  • +
+ +
+ + + + +
+ +

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 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 vector of component constants that makeup this array.
    • +
    +
  • +
  • ConstantStruct : This represents a constant struct. +
      +
    • const std::vector<Use> &getValues() const: Returns + a vector of component constants that makeup this array.
    • +
    +
  • +
  • GlobalValue : This represents either a global variable or a function. In + either case, the value is a constant fixed address (after linking). +
  • +
+
+ + + + +
+ +

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.

+ +
+ + + + +
+ +
    + +
  • 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: Equivalent to isSigned() || isUnsigned().
  • + +
  • 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.
  • + +
  • 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 or one pointer type to another.
  • +
+
+ + + +
+
    +
  • 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.
    • +
    +
  • +
+
+ + + + +
+ +

This subclass of Value defines the interface for incoming formal + arguments to a function. A Function maintains 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: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/Projects.html diff -c /dev/null llvm-www/releases/1.6/docs/Projects.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/Projects.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,460 ---- + + + + Creating an LLVM Project + + + + +
Creating an LLVM Project
+ +
    +
  1. Overview
  2. +
  3. Create a project from the Sample Project
  4. +
  5. Source tree layout
  6. +
  7. Writing LLVM-style Makefiles +
      +
    1. Required Variables
    2. +
    3. Variables for Building Subdirectories
    4. +
    5. Variables for Building Libraries
    6. +
    7. Variables for Building Programs
    8. +
    9. Miscellaneous Variables
    10. +
  8. +
  9. Placement of object code
  10. +
  11. Further help
  12. +
+ +
+

Written by John Criswell

+
+ + + + + +
+ +

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 make variables. There are several variables that a Makefile + needs to set to use the LLVM build system: +
      +
    • PROJECT_NAME - The name by which your project is known.
    • +
    • LLVM_SRC_ROOT - The root of the LLVM source tree.
    • +
    • LLVM_OBJ_ROOT - The root of the LLVM object tree.
    • +
    • PROJ_SRC_ROOT - The root of the project's source tree.
    • +
    • PROJ_OBJ_ROOT - The root of the project's object tree.
    • +
    • PROJ_INSTALL_ROOT - The root installation directory.
    • +
    • LEVEL - The relative path from the current directory to the + project's root ($PROJ_OBJ_ROOT).
    • +
  2. +
  3. Include Makefile.config from $(LLVM_OBJ_ROOT).
  4. +
  5. Include Makefile.rules from $(LLVM_SRC_ROOT).
  6. +
+ +

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. +
  3. 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.
  4. +
+ +

This document assumes that you will base your project on 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.

+ +
+ + + + + +
+ +

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. + +
  3. + If you downloaded LLVM using CVS, remove all the directories named CVS (and all + the files therein) from your project's new source tree. This will keep CVS + from thinking that your project is inside llvm/projects/sample. +
  4. + +
  5. Add your source code and Makefiles to your source tree.
  6. + +
  7. If you want your project to be configured with the configure script + then you need to edit autoconf/configure.ac as follows: +
      +
    • AC_INIT. Place the name of your project, its version number and + a contact email address for your project as the arguments to this macro
    • +
    • AC_CONFIG_AUC_DIR. If your project isn't in the + llvm/projects directory then you might need to adjust this so that + it specifies a relative path to the llvm/autoconf directory.
    • +
    • LLVM_CONFIG_PROJECT. Just leave this alone.
    • +
    • AC_CONFIG_SRCDIR. Specify a path to a file name that identifies + your project; or just leave it at Makefile.config.in
    • +
    • AC_CONFIG_FILES. Do not change.
    • +
    • AC_CONFIG_MAKEFILE. Use one of these macros for each Makefile + that your project uses. This macro arranges for your makefiles to be copied + from the source directory, unmodified, to the build directory.
    • +
    +
  8. + +
  9. After updating autoconf/configure.ac, regenerate the + configure script with these commands: + +
    +

    % cd autoconf
    + % AutoRegen.sh

    +
    + +

    You must be using Autoconf version 2.59 or later and your aclocal version + should 1.9 or later.

  10. + +
  11. 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.
    +

    --prefix=<directory>
    +
    Tell your project where it should get installed.
    +
    +
+ +

That's it! Now all you have to do is type gmake (or make + if your on a GNU/Linux system) in the root of your object directory, and your + project should build.

+ +
+ + + + + +
+ +

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 basic support for tests. + The LLVM system provides the following: +

    +
  • + LLVM provides a tcl procedure that is used by Dejagnu to run + tests. It can be found in llvm/lib/llvm-dg.exp. This + test procedure uses RUN lines in the actual test case to determine + how to run the test. See the TestingGuide for more details. You + can easily write Makefile support similar to the Makefiles in + llvm/test to use Dejagnu to run your project's tests.
  • +
  • + LLVM contains an optional package called llvm-test + which provides benchmarks and programs that 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. +
    Currently, there is no way to hook your tests directly into the + llvm/test 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.

+ +
+ + + + + +
+ +

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:

+ +
+ + + + +
+ +
+
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 "../..". +
+ +
+ + + + +
+ +
+
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. +
+ +
+ + + + +
+ +
+
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. +
+ +
+ + + + +
+ +
+
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 + +

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

+

+ +
+ + + + + +
+ +

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 + PROJ_OBJ_ROOT/<type>/lib, where type is Debug, + Release, or Profile for a debug, optimized, or + profiled build, respectively.

+ +

Executables +
All executables will be stored in + PROJ_OBJ_ROOT/<type>/bin, where type is Debug, + Release, or Profile for a debug, optimized, or profiled + build, respectively. +
+ +
+ + + + + +
+ +

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.

+ +
+ + +
+
+ Valid CSS! + Valid HTML 4.01! + + John Criswell
+ The LLVM Compiler Infrastructure +
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/ReleaseNotes.html diff -c /dev/null llvm-www/releases/1.6/docs/ReleaseNotes.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/ReleaseNotes.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,722 ---- + + + + + + LLVM 1.6 Release Notes + + + +
LLVM 1.6 Release Notes
+ +
    +
  1. Introduction
  2. +
  3. What's New?
  4. +
  5. Installation Instructions
  6. +
  7. Portability and Supported Platforms
  8. +
  9. Known Problems +
  10. Additional Information
  11. +
+ +
+

Written by the LLVM Team

+

+ + + + + +
+ +

This document contains the release notes for the LLVM compiler + infrastructure, release 1.6. Here we describe the status of LLVM, including any + known problems and major improvements from the previous release. The most + up-to-date version of this document can be found on the LLVM 1.6 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 the latest + release, please check out the main LLVM + 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 or the main LLVM web page, + 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.

+ +
+ + + + + +
+ +

This is the seventh public release of the LLVM Compiler Infrastructure. This + release incorporates a large number of enhancements and additions (primarily in + the code generator), which combine to improve the quality of the code generated + by LLVM by up to 30% in some cases. This release is also the first release to + have first-class support for Mac OS X: all of the major bugs have been shaken + out and it is now as well supported as Linux on X86.

+ +
+ + + + + + + +
+

LLVM now includes support for auto-generating large portions of the + instruction selectors from target descriptions. This allows us to + write patterns in the target .td file, instead of writing lots of + nasty C++ code. Most of the PowerPC instruction selector is now + generated from the PowerPC target description files and other targets + are adding support that will be live for LLVM 1.7.

+ +

For example, here are some patterns used by the PowerPC backend. A + floating-point multiply then subtract instruction (FMSUBS):

+ +

+ (set F4RC:$FRT, (fsub (fmul F4RC:$FRA, F4RC:$FRC), F4RC:$FRB)) +

+ +

Exclusive-or by 16-bit immediate (XORI):

+ +

+ (set GPRC:$dst, (xor GPRC:$src1, immZExt16:$src2)) +

+ +

Exclusive-or by 16-bit immediate shifted right 16-bits (XORIS):

+ +

+ (set GPRC:$dst, (xor GPRC:$src1, imm16Shifted:$src2)) +

+ +

With these definitions, we teach the code generator how to combine these two + instructions to xor an abitrary 32-bit immediate with the following + definition. The first line specifies what to match (a xor with an arbitrary + immediate) the second line specifies what to produce:

+ +

+

def : Pat<(xor GPRC:$in, imm:$imm),
+           (XORIS (XORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>;
+ 
+

+ +
+ + + + +
+ +

Instruction selectors using the refined instruction selection framework can now + use a simple pre-pass scheduler included with LLVM 1.6. This scheduler is + currently simple (cannot be configured much by the targets), but will be + extended in the future.

+
+ + + + +
+

It is now straight-forward to parameterize a target implementation, and + provide a mapping from CPU names to sets of target parameters. LLC now supports + a -mcpu=cpu option that lets you choose a subtarget by CPU name: use + "llvm-as < /dev/null | llc -march=XXX -mcpu=help" to get a list of + supported CPUs for target "XXX". It also provides a + -mattr=+attr1,-attr2 option that can be used to control individual + features of a target (the previous command will list available features as + well).

+ +

This functionality is nice when you want tell LLC something like "compile to + code that is specialized for the PowerPC G5, but doesn't use altivec code. In + this case, using "llc -march=ppc32 -mcpu=g5 -mattr=-altivec".

+ +
+ + + + +
+
    +
  1. The JIT now uses mutexes to protect its internal data structures. This + allows multi-threaded programs to be run from the JIT or interpreter without + corruption of the internal data structures. See + PR418 and + PR540 for the details. +
  2. +
  3. LLVM on Win32 no longer requires sed, + flex, or bison when compiling with Visual C++.
  4. +
  5. The llvm-test suite can now use the NAG Fortran to C compiler to compile + SPEC FP programs if available (allowing us to test all of SPEC'95 & + 2000).
  6. +
  7. When bugpoint is grinding away and the user hits ctrl-C, it now + gracefully stops and gives what it has reduced so far, instead of + giving up completely. In addition, the JIT + debugging mode of bugpoint is much faster.
  8. +
  9. LLVM now includes Xcode project files in the llvm/Xcode directory.
  10. +
  11. LLVM now supports Mac OS X on Intel.
  12. +
  13. LLVM now builds cleanly with GCC 4.1.
  14. +
+
+ + + + +
+
    +
  1. The -globalopt pass can now statically evaluate C++ static + constructors when they are simple enough. For example, it can + now statically initialize "struct X { int a; X() : a(4) {} } g;". +
  2. +
  3. The Loop Strength Reduction pass has been completely rewritten, is far + more aggressive, and is turned on by default in the RISC targets. On PPC, + we find that it often speeds up programs from 10-40% depending on the + program.
  4. +
  5. The code produced when exception handling is enabled is far more + efficient in some cases, particularly on Mac OS X.
  6. +
+
+ + + + + +
+
    +
  1. The Alpha backend is substantially more stable and robust than in LLVM 1.5. + For example, it now fully supports varargs functions. The Alpha backend + also now features beta JIT support.
  2. +
  3. The code generator contains a new component, the DAG Combiner. This allows + us to optimize lowered code (e.g. after 64-bit operations have been lowered + to use 32-bit registers on 32-bit targets) and do fine-grained bit-twiddling + optimizations for the backend.
  4. +
  5. The SelectionDAG infrastructure is far more capable and mature, able to + handle many new target peculiarities in a target-independent way.
  6. +
  7. The default register allocator is now far + faster on some testcases, + particularly on targets with a large number of registers (e.g. IA64 + and PPC).
  8. +
+
+ + + + +
+
    +
  1. A vast number of bugs have been fixed in the PowerPC backend and in + llvm-gcc when configured for Mac OS X (particularly relating to ABI + issues). For example: + PR449, + PR594, + PR603, + PR609, + PR630, + PR643, + and several others without bugzilla bugs.
  2. +
  3. Several bugs in tail call support have been fixed.
  4. +
  5. configure does not correctly detect gcc + version on cygwin.
  6. +
  7. Many many other random bugs have been fixed. Query our bugzilla with a target of 1.6 for more + information.
  8. +
+
+ + + + + +
+ +

LLVM is known to work on the following platforms:

+ +
    +
  • Intel and AMD machines running Red Hat Linux, Fedora Core and FreeBSD + (and probably other unix-like systems).
  • +
  • Sun UltraSPARC workstations running Solaris 8.
  • +
  • Intel and AMD machines running on Win32 with the Cygwin libraries (limited + support is available for native builds with Visual C++).
  • +
  • PowerPC and X86-based Mac OS X systems, running 10.2 and above.
  • +
  • Alpha-based machines running Debian GNU/Linux.
  • +
  • Itanium-based machines running Linux and HP-UX.
  • +
+ +

The core LLVM infrastructure uses + GNU autoconf to adapt itself + to the machine and operating system on which it is built. However, minor + porting may be required to get LLVM to work on new platforms. We welcome your + portability patches and reports of successful builds or error messages.

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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, and may be removed in future + releases: -cee, -pre
  • +
  • The llvm-db tool is in a very early stage of development, but can + be used to step through programs and inspect the stack.
  • +
  • The SparcV8 and IA64 code generators are experimental.
  • +
  • The Alpha JIT is experimental.
  • +
+ +
+ + + + +
+ +
    +
  • In the JIT, dlsym() on a symbol compiled by the JIT will not + work.
  • +
+
+ + + + + +
Bugs
+ +
+
    +
  • C99 Variable sized arrays do not release stack memory when they go out of + scope. Thus, the following program may run out of stack space: +
    +     for (i = 0; i != 1000000; ++i) {
    +       int X[n];
    +       foo(X);
    +     }
    + 
  • + +
  • Initialization of global union variables can only be done with the largest union member.
  • + +
+
+ + +
+ 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. +
    3. Nested Functions: As in Algol and Pascal, lexical scoping of functions.
    4. +
    5. Constructing Calls: Dispatching a call to another function.
    6. +
    7. Extended Asm: Assembler instructions with C expressions as operands.
    8. +
    9. Constraints: Constraints for asm operands.
    10. +
    11. Asm Labels: Specifying the assembler name to use for a C symbol.
    12. +
    13. Explicit Reg Vars: Defining variables residing in specified registers.
    14. +
    15. Vector Extensions: Using vector instructions through built-in functions.
    16. +
    17. Target Builtins: Built-in functions specific to particular targets.
    18. +
    19. Thread-Local: Per-thread variables.
    20. +
    21. Pragmas: Pragmas accepted by GCC.
    22. +
    + +

    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. + +
    3. Function Attributes: + + Declaring that functions have no side effects or that they can never + return.
      + + Supported: format, format_arg, non_null, + noreturn, constructor, destructor, + unused, + deprecated, warn_unused_result, weak
      + + Ignored: noinline, + always_inline, pure, const, nothrow, + malloc, no_instrument_function, cdecl
      + + Unsupported: used, section, alias, + visibility, regparm, stdcall, + fastcall, all other target specific attributes
    4. + +
    5. 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.
    6. + +
    7. Type Attributes: Specifying attributes of types.
      + Supported: transparent_union, unused, + deprecated, may_alias
      + + Unsupported: aligned, packed, + all target specific attributes.
    8. + +
    9. 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 + (currently ignored). We also support builtins for ISO C99 floating + point comparison macros (e.g., __builtin_islessequal), + __builtin_prefetch, __builtin_popcount[ll], + __builtin_clz[ll], and __builtin_ctz[ll].
    10. +
    + +

    The following extensions are known to be supported:

    + +
      +
    1. Labels as Values: Getting pointers to labels and computed gotos.
    2. +
    3. Statement Exprs: Putting statements and declarations inside expressions.
    4. +
    5. Typeof: typeof: referring to the type of an expression.
    6. +
    7. Lvalues: Using ?:, "," and casts in lvalues.
    8. +
    9. Conditionals: Omitting the middle operand of a ?: expression.
    10. +
    11. Long Long: Double-word integers.
    12. +
    13. Complex: Data types for complex numbers.
    14. +
    15. Hex Floats:Hexadecimal floating-point constants.
    16. +
    17. Zero Length: Zero-length arrays.
    18. +
    19. Empty Structures: Structures with no members.
    20. +
    21. Variadic Macros: Macros with a variable number of arguments.
    22. +
    23. Escaped Newlines: Slightly looser rules for escaped newlines.
    24. +
    25. Subscripting: Any array can be subscripted, even if not an lvalue.
    26. +
    27. Pointer Arith: Arithmetic on void-pointers and function pointers.
    28. +
    29. Initializers: Non-constant initializers.
    30. +
    31. Compound Literals: Compound literals give structures, unions, + or arrays as values.
    32. +
    33. Designated Inits: Labeling elements of initializers.
    34. +
    35. Cast to Union: Casting to union type from any member of the union.
    36. +
    37. Case Ranges: `case 1 ... 9' and such.
    38. +
    39. Mixed Declarations: Mixing declarations and code.
    40. +
    41. Function Prototypes: Prototype declarations and old-style definitions.
    42. +
    43. C++ Comments: C++ comments are recognized.
    44. +
    45. Dollar Signs: Dollar sign is allowed in identifiers.
    46. +
    47. Character Escapes: \e stands for the character <ESC>.
    48. +
    49. Alignment: Inquiring about the alignment of a type or variable.
    50. +
    51. Inline: Defining inline functions (as fast as macros).
    52. +
    53. Alternate Keywords:__const__, __asm__, etc., for header files.
    54. +
    55. Incomplete Enums: enum foo;, with details to follow.
    56. +
    57. Function Names: Printable strings which are the name of the current function.
    58. +
    59. Return Address: Getting the return or frame address of a function.
    60. +
    61. Unnamed Fields: Unnamed struct/union fields within structs/unions.
    62. +
    63. Attribute Syntax: Formal syntax for attributes.
    64. +
  • + +
+ +

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).

+ +
+ + + + +
+ +

For this release, the C++ front-end is considered to be fully + tested and works for a number of non-trivial programs, including LLVM + itself.

+ +
+ + +
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.
  • + +
+ +
+ + + + +
+ +
    + +
  • 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.
  • + +
  • Zero arg vararg functions are not + supported. This should not affect LLVM produced by the C or C++ + frontends.
  • + +
+ +
+ + + + + + + + + +
+ +
    +
  • None yet
  • +
+ +
+ + + + + + + + + +
+ +
    + +
  • On 21164s, some rare FP arithmetic sequences which may trap do not have the + appropriate nops inserted to ensure restartability.
  • + +
+ +
+ + + + +
+ +
    + +
  • C++ programs are likely to fail on IA64, as calls to setjmp are + made where the argument is not 16-byte aligned, as required on IA64. (Strictly + speaking this is not a bug in the IA64 back-end; it will also be encountered + when building C++ programs using the C back-end.)
  • + +
  • The C++ front-end does not use IA64 + ABI compliant layout of v-tables. In particular, it just stores function + pointers instead of function descriptors in the vtable. This bug prevents + mixing C++ code compiled with LLVM with C++ objects compiled by other C++ + compilers.
  • + +
  • There are a few ABI violations which will lead to problems when mixing LLVM + output with code built with other compilers, particularly for floating-point + programs.
  • + +
  • Defining vararg functions is not supported (but calling them is ok).
  • + +
+ +
+ + + + +
+ +
    +
  • Many features are still missing (e.g. support for 64-bit integer + arithmetic). This back-end is in pre-beta state.
  • +
+
+ + + + + +
+ +

A wide variety of additional information is available on the LLVM web page, including documentation 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: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/SourceLevelDebugging.html diff -c /dev/null llvm-www/releases/1.6/docs/SourceLevelDebugging.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/SourceLevelDebugging.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,1117 ---- + + + + Source Level Debugging with LLVM + + + + +
Source Level Debugging with LLVM
+ + + + + +
+ + + A leafy and green bug eater +
+ +
+

Written by Chris Lattner

+
+ + + + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+

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.

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+ +

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
+ $
+ 
+ +
+ + + + + + +
+ +

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

+ +
+ + + + +
+ +

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
  • +
+ +
+ + + + + +
+

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

+
+ + + + + +
+ +

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

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+

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).

+ +
+ + + + +
+

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

+
+ + + + + +
+

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

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

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

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.

+ +
+ + + + +
+

TODO

+
+ + + + +
+

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

+
+ + + + +
+

TODO

+
+ + + + +
+

TODO

+
+ + + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/Stacker.html diff -c /dev/null llvm-www/releases/1.6/docs/Stacker.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/Stacker.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,1412 ---- + + + + Stacker: An Example Of Using LLVM + + + + +
Stacker: An Example Of Using LLVM
+ +
    +
  1. Abstract
  2. +
  3. Introduction
  4. +
  5. Lessons I Learned About LLVM +
      +
    1. Everything's a Value!
    2. +
    3. Terminate Those Blocks!
    4. +
    5. Concrete Blocks
    6. +
    7. push_back Is Your Friend
    8. +
    9. The Wily GetElementPtrInst
    10. +
    11. Getting Linkage Types Right
    12. +
    13. Constants Are Easier Than That!
    14. +
  6. +
  7. The Stacker Lexicon +
      +
    1. The Stack
    2. +
    3. Punctuation
    4. +
    5. Comments
    6. +
    7. Literals
    8. +
    9. Words
    10. +
    11. Standard Style
    12. +
    13. Built-Ins
    14. +
  8. +
  9. Prime: A Complete Example
  10. +
  11. Internal Code Details +
      +
    1. The Directory Structure
    2. +
    3. The Lexer
    4. +
    5. The Parser
    6. +
    7. The Compiler
    8. +
    9. The Runtime
    10. +
    11. Compiler Driver
    12. +
    13. Test Programs
    14. +
    15. Exercise
    16. +
    17. Things Remaining To Be Done
    18. +
  12. +
+ +
+

Written by Reid Spencer

+
+ + + +
+

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.

+
+ + +
+

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. +
  3. to provide a simple example of how to write a compiler using LLVM.
  4. +
+

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 )
+ {
+     ConstantSInt* one = ConstantSInt::get(Type::IntTy, 1);
+     BinaryOperator* or1 = BinaryOperator::createOr(a, b, "", bb);
+     BinaryOperator* add1 = BinaryOperator::createAdd(x, one, "", bb);
+     BinaryOperator* add2 = BinaryOperator::createAdd(y, one, "", bb);
+     BinaryOperator* div1 = BinaryOperator::createDiv(add1, add2, "", bb);
+     BinaryOperator* mult1 = BinaryOperator::createMul(or1, div1, "", bb);
+     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. +
  3. Terminate your blocks early. This just reduces the chances + that you forget to terminate your blocks which is required (go + here for more). +
  4. 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.
  5. +
+

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<Value*> 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.
  • +
+
+ + +

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.

+
+ +
Standard Style
+
+

TODO

+
+ +
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. +
  3. Bitwise: These words perform bitwise computations on + their operands.
    The words are: << >> XOR AND NOT
  4. +
  5. Arithmetic: These words perform arithmetic computations on + their operands.
    The words are: ABS NEG + - * / MOD */ ++ -- MIN MAX
  6. +
  7. 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
  8. +
  9. MemoryThese words allocate, free, and manipulate memory + areas outside the stack.
    The words are: MALLOC FREE GET PUT
  10. +
  11. Control: These words alter the normal left to right flow + of execution.
    The words are: IF ELSE ENDIF WHILE END RETURN EXIT RECURSE
  12. +
  13. 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.
  14. +
+

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. +
  3. w - a normal integer valued word.
  4. +
  5. s - a pointer to a string value
  6. +
  7. p - a pointer to a malloc'd memory block
  8. +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
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 -- w3 w1 w2Reverse 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 word ENDWHILE word ENDb -- b The boolean value on the top of the stack is examined (not popped). If + it is non-zero then the "word" between WHILE and END is executed. + Execution then begins again at the WHILE where the boolean on the top of + the stack is examined again. The stack is not modified by the WHILE...END + loop, only examined. It is imperative that the "word" in the body of the + loop ensure that the top of the stack contains the next boolean to examine + when it completes. Note that since booleans and integers can be coerced + you can use the following "for loop" idiom:
+ (push count) WHILE word -- END
+ For example:
+ 10 WHILE >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 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 point 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.
+ +
+ + +
+

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
+ # STAC>K
+ #    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 )
+ ;
+ 
+ 
+
+ + +
+

This section is under construction. +

In the mean time, you can always read the code! It has comments!

+
+ + +
+

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

+
+ + +
+

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!

+
+ + +
+

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. +
  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. +
  5. Make the compiler driver use the LLVM linking facilities (with IPO) + before depending on GCC to do the final link.
  6. +
  7. Clean up parsing. It doesn't handle errors very well.
  8. +
  9. 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!
  10. +
  11. Provide for I/O to arbitrary files instead of just stdin/stdout.
  12. +
  13. Write additional built-in words; with inspiration from FORTH
  14. +
  15. Write additional sample Stacker programs.
  16. +
  17. Add your own compiler writing experiences and tips in the + Lessons I Learned About LLVM section.
  18. +
+
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Reid Spencer
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/SystemLibrary.html diff -c /dev/null llvm-www/releases/1.6/docs/SystemLibrary.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/SystemLibrary.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,344 ---- + + + + System Library + + + + +
System Library
+ + +
+

Written by Reid Spencer

+
+ + + + +
+

This document provides some details on LLVM's System Library, located in + the source at lib/System and include/llvm/System. The + library's purpose is to shield LLVM from the differences between operating + systems for the few services LLVM needs from the operating system. Much of + LLVM is written using portability features of standard C++. However, in a few + areas, system dependent facilities are needed and the System Library is the + wrapper around those system calls.

+

By centralizing LLVM's use of operating system interfaces, we make it + possible for the LLVM tool chain and runtime libraries to be more easily + ported to new platforms since (theoretically) only lib/System needs + to be ported. This library also unclutters the rest of LLVM from #ifdef use + and special cases for specific operating systems. Such uses are replaced + with simple calls to the interfaces provided in include/llvm/System. +

+

Note that the System Library is not intended to be a complete operating + system wrapper (such as the Adaptive Communications Environment (ACE) or + Apache Portable Runtime (APR)), but only provides the functionality necessary + to support LLVM. +

The System Library was written by Reid Spencer who formulated the + design based on similar work originating from the eXtensible Programming + System (XPS). Several people helped with the effort; especially, + Jeff Cohen and Henrik Bach on the Win32 port.

+
+ + + +
+

In order to keep LLVM portable, LLVM developers should adhere to a set of + portability rules associated with the System Library. Adherence to these rules + should help the System Library achieve its goal of shielding LLVM from the + variations in operating system interfaces and doing so efficiently. The + following sections define the rules needed to fulfill this objective.

+
+ + + +
+

Except in lib/System, no LLVM source code should directly + #include a system header. Care has been taken to remove all such + #includes from LLVM while lib/System was being + developed. Specifically this means that header files like "unistd.h", + "windows.h", "stdio.h", and "string.h" are forbidden to be included by LLVM + source code outside the implementation of lib/System.

+

To obtain system-dependent functionality, existing interfaces to the system + found in include/llvm/System should be used. If an appropriate + interface is not available, it should be added to include/llvm/System + and implemented in lib/System for all supported platforms.

+
+ + + +
+

The System Library must shield LLVM from all system headers. To + obtain system level functionality, LLVM source must + #include "llvm/System/Thing.h" and nothing else. This means that + Thing.h cannot expose any system header files. This protects LLVM + from accidentally using system specific functionality and only allows it + via the lib/System interface.

+
+ + + +
+

The standard C headers (the ones beginning with "c") are allowed + to be exposed through the lib/System interface. These headers and + the things they declare are considered to be platform agnostic. LLVM source + files may include them directly or obtain their inclusion through + lib/System interfaces.

+
+ + + +
+

The standard C++ headers from the standard C++ library and + standard template library may be exposed through the lib/System + interface. These headers and the things they declare are considered to be + platform agnostic. LLVM source files may include them or obtain their + inclusion through lib/System interfaces.

+
+ + + +
+

The entry points specified in the interface of lib/System must be aimed at + completing some reasonably high level task needed by LLVM. We do not want to + simply wrap each operating system call. It would be preferable to wrap several + operating system calls that are always used in conjunction with one another by + LLVM.

+

For example, consider what is needed to execute a program, wait for it to + complete, and return its result code. On Unix, this involves the following + operating system calls: getenv, fork, execve, and wait. The + correct thing for lib/System to provide is a function, say + ExecuteProgramAndWait, that implements the functionality completely. + what we don't want is wrappers for the operating system calls involved.

+

There must not be a one-to-one relationship between operating + system calls and the System library's interface. Any such interface function + will be suspicious.

+
+ + + +
+

There must be no functionality specified in the interface of lib/System + that isn't actually used by LLVM. We're not writing a general purpose + operating system wrapper here, just enough to satisfy LLVM's needs. And, LLVM + doesn't need much. This design goal aims to keep the lib/System interface + small and understandable which should foster its actual use and adoption.

+
+ + + +
+

The implementation of a function for a given platform must be written + exactly once. This implies that it must be possible to apply a function's + implementation to multiple operating systems if those operating systems can + share the same implementation. This rule applies to the set of operating + systems supported for a given class of operating system (e.g. Unix, Win32). +

+
+ + + +
+

The System Library interfaces can be called quite frequently by LLVM. In + order to make those calls as efficient as possible, we discourage the use of + virtual methods. There is no need to use inheritance for implementation + differences, it just adds complexity. The #include mechanism works + just fine.

+
+ + + +
+

Any functions defined by system libraries (i.e. not defined by lib/System) + must not be exposed through the lib/System interface, even if the header file + for that function is not exposed. This prevents inadvertent use of system + specific functionality.

+

For example, the stat system call is notorious for having + variations in the data it provides. lib/System must not declare + stat nor allow it to be declared. Instead it should provide its own + interface to discovering information about files and directories. Those + interfaces may be implemented in terms of stat but that is strictly + an implementation detail. The interface provided by the System Library must + be implemented on all platforms (even those without stat).

+
+ + + +
+

Any data defined by system libraries (i.e. not defined by lib/System) must + not be exposed through the lib/System interface, even if the header file for + that function is not exposed. As with functions, this prevents inadvertent use + of data that might not exist on all platforms.

+
+ + + +
+

Operating system interfaces will generally provide error results for every + little thing that could go wrong. In almost all cases, you can divide these + error results into two groups: normal/good/soft and abnormal/bad/hard. That + is, some of the errors are simply information like "file not found", + "insufficient privileges", etc. while other errors are much harder like + "out of space", "bad disk sector", or "system call interrupted". We'll call + the first group "soft" errors and the second group "hard" + errors.

+

lib/System must always attempt to minimize soft errors and always just + throw a std::string on hard errors. This is a design requirement because the + minimization of soft errors can affect the granularity and the nature of the + interface. In general, if you find that you're wanting to throw soft errors, + you must review the granularity of the interface because it is likely you're + trying to implement something that is too low level. The rule of thumb is to + provide interface functions that can't fail, except when faced with + hard errors.

+

For a trivial example, suppose we wanted to add an "OpenFileForWriting" + function. For many operating systems, if the file doesn't exist, attempting + to open the file will produce an error. However, lib/System should not + simply throw that error if it occurs because its a soft error. The problem + is that the interface function, OpenFileForWriting is too low level. It should + be OpenOrCreateFileForWriting. In the case of the soft "doesn't exist" error, + this function would just create it and then open it for writing.

+

This design principle needs to be maintained in lib/System because it + avoids the propagation of soft error handling throughout the rest of LLVM. + Hard errors will generally just cause a termination for an LLVM tool so don't + be bashful about throwing them.

+

Rules of thumb:

+
    +
  1. Don't throw soft errors, only hard errors.
  2. +
  3. If you're tempted to throw a soft error, re-think the interface.
  4. +
  5. Handle internally the most common normal/good/soft error conditions + so the rest of LLVM doesn't have to.
  6. +
+
+ + + +
+

If an error occurs that lib/System cannot handle, the only action taken by + lib/System is to throw an instance of std:string. The contents of the string + must explain both what happened and the context in which it happened. The + format of the string should be a (possibly empty) list of contexts each + terminated with a : and a space, followed by the error message, optionally + followed by a reason, and optionally followed by a suggestion.

+

For example, failure to open a file named "foo" could result in a message + like:

+
  • foo: Unable to open file because it doesn't exist."
+

The "foo:" part is the context. The "Unable to open file" part is the error + message. The "because it doesn't exist." part is the reason. This message has + no suggestion. Where possible, the implementation of lib/System should use + operating system specific facilities for converting the error code returned by + a system call into an error message. This will help to make the error message + more familiar to users of that type of operating system.

+

Note that this requirement precludes the throwing of any other exceptions. + For example, various C++ standard library functions can cause exceptions to be + thrown (e.g. out of memory situation). In all cases, if there is a possibility + that non-string exceptions could be thrown, the lib/System library must ensure + that the exceptions are translated to std::string form.

+
+ + + +
+

None of the lib/System interface functions may be declared with C++ + throw() specifications on them. This requirement makes sure that the + compiler does not insert additional exception handling code into the interface + functions. This is a performance consideration: lib/System functions are at + the bottom of many call chains and as such can be frequently called. We + need them to be as efficient as possible.

+
+ + + +
+

Implementations of the System Library interface are separated by their + general class of operating system. Currently only Unix and Win32 classes are + defined but more could be added for other operating system classifications. + To distinguish which implementation to compile, the code in lib/System uses + the LLVM_ON_UNIX and LLVM_ON_WIN32 #defines provided via configure through the + llvm/Config/config.h file. Each source file in lib/System, after implementing + the generic (operating system independent) functionality needs to include the + correct implementation using a set of #if defined(LLVM_ON_XYZ) + directives. For example, if we had lib/System/File.cpp, we'd expect to see in + that file:

+

+   #if defined(LLVM_ON_UNIX)
+   #include "Unix/File.cpp"
+   #endif
+   #if defined(LLVM_ON_WIN32)
+   #include "Win32/File.cpp"
+   #endif
+   
+

The implementation in lib/System/Unix/File.cpp should handle all Unix + variants. The implementation in lib/System/Win32/File.cpp should handle all + Win32 variants. What this does is quickly differentiate the basic class of + operating system that will provide the implementation. The specific details + for a given platform must still be determined through the use of + #ifdef.

+
+ + + +
+

The implementation of a lib/System interface can vary drastically between + platforms. That's okay as long as the end result of the interface function + is the same. For example, a function to create a directory is pretty straight + forward on all operating system. System V IPC on the other hand isn't even + supported on all platforms. Instead of "supporting" System V IPC, lib/System + should provide an interface to the basic concept of inter-process + communications. The implementations might use System V IPC if that was + available or named pipes, or whatever gets the job done effectively for a + given operating system. In all cases, the interface and the implementation + must be semantically consistent.

+
+ + + +
+

See bug 351 + for further details on the progress of this work

+
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Reid Spencer
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + Index: llvm-www/releases/1.6/docs/TableGenFundamentals.html diff -c /dev/null llvm-www/releases/1.6/docs/TableGenFundamentals.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/TableGenFundamentals.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,567 ---- + + + + TableGen Fundamentals + + + + +
TableGen Fundamentals
+ + + +
+

Written by Chris Lattner

+
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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".

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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 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 supports BCPL style "//" comments, which run to the end of + the line, and it also supports nestable "/* */" comments.

+
+ + + + +
+

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 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 bit of a value
  • +
  • value{15-17} - access to multiple bits of a value
  • +
  • DEF - reference to a record definition
  • +
  • CLASS<val list> - reference to a new anonymous definition of + CLASS with the specified template arguments.
  • +
  • X.Y - reference to the subfield of a value
  • +
  • list[4-7,17,2-3] - A slice of the 'list' list, including elements + 4,5,6,7,17,2, and 3 from it. Elements may be included multiple times.
  • +
  • (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.

+ +
+ + + + +
+ +

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 separated 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 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.

+
+ + + + +
+

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.

+ +
+ + + + +
+

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.

+ +
+ + + + + + + +
+

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 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-separated 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.

+
+ + + + + +
+

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.

+
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/TestingGuide.html diff -c /dev/null llvm-www/releases/1.6/docs/TestingGuide.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/TestingGuide.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,528 ---- + + + + LLVM Test Suite Guide + + + + +
+ LLVM Test Suite Guide +
+ +
    +
  1. Overview
  2. +
  3. Requirements
  4. +
  5. Quick Start
  6. +
  7. LLVM Test Suite Organization + +
  8. +
  9. LLVM Test Suite Tree
  10. +
  11. DejaGNU Structure
  12. +
  13. llvm-test Structure
  14. +
  15. Running the LLVM Tests
  16. +
  17. Running the nightly tester
  18. +
+ +
+

Written by John T. Criswell, Reid Spencer, and Tanya Lattner

+
+ + + + + +
+ +

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.

+ +
+ + + + + +
+ +

In order to use the LLVM test suite, you will need all of the software + required to build LLVM, plus the following:

+ +
+
DejaGNU
+
The Feature and Regressions tests are organized and run by DejaGNU.
+
Expect
+
Expect is required by DejaGNU.
+
tcl
+
Tcl is required by DejaGNU.
+ +
F2C
+
For now, LLVM does not have a Fortran front-end, but using F2C, we can run + Fortran benchmarks. F2C support must be enabled via configure if not + installed in a standard place. F2C requires three items: the f2c + executable, f2c.h to compile the generated code, and libf2c.a + to link generated code. By default, given an F2C directory $DIR, the + configure script will search $DIR/bin for f2c, + $DIR/include for f2c.h, and $DIR/lib for + libf2c.a. The default $DIR values are: /usr, + /usr/local, /sw, and /opt. If you installed F2C in a + different location, you must tell configure: + +
    +
  • ./configure --with-f2c=$DIR
    + This will specify a new $DIR for the above-described search + process. This will only work if the binary, header, and library are in their + respective subdirectories of $DIR.
  • + +
  • ./configure --with-f2c-bin=/binary/path --with-f2c-inc=/include/path + --with-f2c-lib=/lib/path
    + This allows you to specify the F2C components separately. Note: if you choose + this route, you MUST specify all three components, and you need to only specify + directories where the files are located; do NOT include the + filenames themselves on the configure line.
  • +
+
+
+ + + + + +
+ +

The tests are located in two separate CVS modules. The basic feature and + regression tests are in the main "llvm" module under the directory + llvm/test. A more comprehensive test suite that includes whole + programs in C and C++ is in the llvm-test module. This module should + be checked out to the llvm/projects directory. When you + configure the llvm module, the llvm-test module + will be automatically configured. Alternatively, you can configure the llvm-test module manually.

+

To run all of the simple tests in LLVM using DejaGNU, use the master Makefile in the + llvm/test directory:

+
+ % gmake -C llvm/test
+ 
+ or
+
+ % gmake check
+ 
+ +

To run only a subdirectory of tests in llvm/test using DejaGNU (ie. + Regression/Transforms), just set the TESTSUITE variable to the path of the + subdirectory (relative to llvm/test):

+
+ % gmake -C llvm/test TESTSUITE=Regression/Transforms
+ 
+ +

Note: If you are running the tests with objdir != subdir, you + must have run the complete testsuite before you can specify a + subdirectory.

+ +

To run the comprehensive test suite (tests that compile and execute whole + programs), run the llvm-test tests:

+ +
+ % cd llvm/projects
+ % cvs co llvm-test
+ % cd llvm-test
+ % ./configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT
+ % gmake
+ 
+ +
+ + + + + +
+ +

The LLVM test suite contains two major categories of tests: code + fragments and whole programs. Code fragments are in the llvm module + under the llvm/test directory. The whole programs + test suite is in the llvm-test module under the main directory.

+ +
+ + + +
+ +

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.

+ +

These code fragment tests are located in the llvm/test/Features and + llvm/test/Regression directories.

+ +
+ + + +
+ +

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.

+ +

All "whole program" tests are located in the llvm-test CVS + module.

+ +
+ + + + + +
+ +

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:

+ +
    +
  • llvm/test/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.

    +
  • + +
  • llvm/test/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.

    +
  • + +
  • llvm-test +

    The llvm-test CVS module 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 llvm-test 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.

  • + +
  • llvm-test/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.

  • + +
  • llvm-test/MultiSource +

    The MultiSource directory contains subdirectories which contain entire + programs with multiple source files. Large benchmarks and whole applications + go here.

  • + +
  • llvm-test/External +

    The External directory contains Makefiles for building code that is external + to (i.e., not distributed with) LLVM. The most prominent members of this + directory are the SPEC 95 and SPEC 2000 benchmark suites. The presence and + location of these external programs is configured by the llvm-test + configure script.

  • + +
+ +
+ + + + +
+

The LLVM test suite is partially driven by DejaGNU and partially + driven by GNU Make. Specifically, the Features and Regression tests + are all driven by DejaGNU. The llvm-test + module is currently driven by a set of Makefiles.

+ +

The DejaGNU structure is very simple, but does require some + information to be set. This information is gathered via configure and + is written to a file, site.exp in llvm/test. The + llvm/test + Makefile does this work for you.

+ +

In order for DejaGNU to work, each directory of tests must have a + dg.exp file. This file is a program written in tcl that calls + the llvm-runtests procedure on each test file. The + llvm-runtests procedure is defined in + llvm/test/lib/llvm-dg.exp. Any directory that contains only + directories does not need the dg.exp file.

+ +

In order for a test to be run, it must contain information within + the test file on how to run the test. These are called RUN + lines. Run lines are specified in the comments of the test program + using the keyword RUN followed by a colon, and lastly the + commands to execute. These commands will be executed in a bash script, + so any bash syntax is acceptable. You can specify as many RUN lines as + necessary. Each RUN line translates to one line in the resulting bash + script. Below is an example of legal RUN lines in a .ll + file:

+
+ ; RUN: llvm-as < %s | llvm-dis > %t1
+ ; RUN: llvm-dis < %s.bc-13 > %t2
+ ; RUN: diff %t1 %t2
+ 
+

There are a couple patterns within a RUN line that the + llvm-runtest procedure looks for and replaces with the appropriate + syntax:

+ +
+
%p
+
The path to the source directory. This is for locating + any supporting files that are not generated by the test, but used by + the test.
+
%s
+
The test file.
+ +
%t
+
Temporary filename: testscript.test_filename.tmp, where + test_filename is the name of the test file. All temporary files are + placed in the Output directory within the directory the test is + located.
+ +
%prcontext
+
Path to a script that performs grep -C. Use this since not all + platforms support grep -C.
+ +
%llvmgcc
Full path to the llvm-gcc executable.
+
%llvmgxx
Full path to the llvm-g++ executable.
+
+ +

There are also several scripts in the llvm/test/Scripts directory + that you might find useful when writing RUN lines.

+ +

Lastly, you can easily mark a test that is expected to fail on a + specific platform by using the XFAIL keyword. Xfail lines are + specified in the comments of the test program using XFAIL, + followed by a colon, and one or more regular expressions (separated by + a comma) that will match against the target triplet for the + machine. You can use * to match all targets. Here is an example of an + XFAIL line:

+
+ ; XFAIL: darwin,sun
+ 
+ +
+ + + + + +
+ +

As mentioned previously, the llvm-test module 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 "whole program" tests, the llvm-test + module also provides a mechanism for compiling the programs in different ways. + If the variable TEST is defined on the gmake command line, the test system will + 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.

+ +

Note, when configuring the llvm-test module, you might want to + specify the following configuration options:

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

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 only the DejaGNU driven + tests. By default, it will run all of these tests.

+ +

To run only the DejaGNU driven tests, run gmake at the + command line in llvm/test. To run a specific directory of tests, use + the TESTSUITE variable. +

+ +

For example, to run the Regression tests, type + gmake TESTSUITE=Regression in llvm/tests.

+ +

Note that there are no Makefiles in llvm/test/Features and + llvm/test/Regression. You must use DejaGNU from the llvm/test + directory to run them.

+ +

To run the llvm-test suite, you need to use the following steps: +

+
    +
  1. cd into the llvm/projects directory
  2. +
  3. check out the llvm-test module with:
    + cvs -d :pserver:anon at llvm.cs.uiuc.edu:/var/cvs/llvm co -PR llvm-test
    + This will get the test suite into llvm/projects/llvm-test
  4. +
  5. configure the test suite. You can do this one of two ways: +
      +
    1. Use the regular llvm configure:
      + cd $LLVM_OBJ_ROOT ; $LLVM_SRC_ROOT/configure
      + This will ensure that the projects/llvm-test directory is also + properly configured.
    2. +
    3. Use the configure script found in the llvm-test source + directory:
      + $LLVM_SRC_ROOT/projects/llvm-test/configure --with-llvmsrc=$LLVM_SRC_ROOT --with-llvmobj=$LLVM_OBJ_ROOT +
    4. +
    +
  6. gmake
  7. +
+

Note that the second and third steps only need to be done once. After you + have the suite checked out and configured, you don't need to do it again (unless + the test code or configure script changes).

+ +

To make a specialized test (use one of the + llvm-test/TEST.<type>.Makefiles), just run:
+ gmake TEST=<type> test
For example, you could run the + nightly tester tests using the following commands:

+ +
+  % cd llvm/projects/llvm-test
+  % 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 DejaGNU, + 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 tests in llvm-test have no such feature at 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.

+ +
+ + + + + +
+ +

+ The LLVM Nightly Testers + automatically check out an LLVM tree, build it, run the "nightly" + program test (described above), run all of the feature and regression tests, + and then delete the checked out tree. This tester is designed to ensure that + programs don't break as well as keep track of LLVM's progress over time.

+ +

If you'd like to set up an instance of the nightly tester to run on your + machine, take a look at the comments at the top of the + utils/NightlyTester.pl file. We usually run it from a crontab entry + that looks ilke this:

+ +
+
+ 5 3 * * *  $HOME/llvm/utils/NightlyTest.pl -parallel $CVSROOT $HOME/buildtest-X86 $HOME/cvs/testresults-X86
+ 
+
+ +

Or, you can create a shell script to encapsulate the running of the script. + The optimized x86 Linux nightly test is run from just such a script:

+ +
+
+ #!/bin/bash
+ BASE=/proj/work/llvm/nightlytest
+ export CVSROOT=:pserver:anon at llvm.cs.uiuc.edu:/var/cvs/llvm
+ export BUILDDIR=$BASE/build 
+ export WEBDIR=$BASE/testresults 
+ export LLVMGCCDIR=/proj/work/llvm/cfrontend/install
+ export PATH=/proj/install/bin:$LLVMGCCDIR/bin:$PATH
+ export LD_LIBRARY_PATH=/proj/install/lib
+ cd $BASE
+ cp /proj/work/llvm/llvm/utils/NightlyTest.pl .
+ nice ./NightlyTest.pl -nice -release -verbose -parallel -enable-linscan -noexternals 2>&1 > output.log
+ mail -s 'X86 nightly tester results' llvm-testresults at cs.uiuc.edu < output.log
+ 
+
+ +

Take a look at the NightlyTest.pl file to see what all of the flags + and strings do. If you start running the nightly tests, please let us know and + we'll link your page to the global tester page. Thanks!

+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + John T. Criswell, Reid Spencer, and Tanya Lattner
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + Index: llvm-www/releases/1.6/docs/UsingLibraries.html diff -c /dev/null llvm-www/releases/1.6/docs/UsingLibraries.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/UsingLibraries.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,504 ---- + + + + Using The LLVM Libraries + + + +
Using The LLVM Libraries
+
    +
  1. Abstract
  2. +
  3. Introduction
  4. +
  5. Library Descriptions
  6. +
  7. Library Dependencies
  8. +
  9. Linkage Rules Of Thumb +
      +
    1. Always link LLVMCore, LLVMSupport, LLVMSystem +
    2. Never link both archive and re-linked +
    +
  10. +
+ +
+

Written by Reid Spencer

+
+ + + +
+

Amongst other things, LLVM is a toolkit for building compilers, linkers, + runtime executives, virtual machines, and other program execution related + tools. In addition to the LLVM tool set, the functionality of LLVM is + available through a set of libraries. To use LLVM as a toolkit for + constructing tools, a developer needs to understand what is contained in the + various libraries, what they depend on, and how to use them. This document + describes the contents of the libraries and how and when to use them. +

+
+ + + +
+

If you're writing a compiler, virtual machine, or any other utility based + on LLVM, you'll need to figure out which of the many libraries files you will + need to link with to be successful. An understanding of the contents of these + files and their inter-relationships will be useful in coming up with an optimal + specification for the libraries to link with. The purpose of this document is + to reduce some of the trial and error that the author experienced in using + LLVM.

+

LLVM produces two types of libraries: archives (ending in .a) and + objects (ending in .o). However, both are libraries. Libraries ending + in .o are known as re-linked libraries because they contain all the + compilation units of the library linked together as a single .o file. + Furthermore, many of the libraries have both forms of library. The + re-linked libraries are used whenever you want to include all symbols from the + library. The archive libraries are used whenever you want to only resolve + outstanding symbols at that point in the link without including everything in + the library.

+

When linking your tools, you will use the LLVMLIBS make variable. + (see the Makefile Guide for + details). This variable specifies which LLVM libraries to link into your tool + and the order in which they will be linked. You specify re-linked libraries by + naming the library without a suffix. You specify archive libraries by naming + the library with a .a suffix but without the lib prefix. The + order in which the libraries appear in the LLVMLIBS variable + definition is the order in which they will be linked. Getting this order + correct for your tool can sometimes be challenging. +

+ +
Library Descriptions
+
+

The table below categorizes each library + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
LibraryFormsDescription
Core Libraries
LLVMArchive.aLLVM archive reading and writing
LLVMAsmParser.oLLVM assembly parsing
LLVMBCReader.oLLVM bytecode reading
LLVMBCWriter.oLLVM bytecode writing
LLVMCore.oLLVM core intermediate representation
LLVMDebugger.oSource level debugging support
LLVMLinker.aBytecode and archive linking interface
LLVMSupport.a .oGeneral support utilities
LLVMSystem.a .oOperating system abstraction layer
Analysis Libraries
LLVMAnalysis.a .oVarious analysis passes.
LLVMDataStructure.a .oData structure analysis passes.
LLVMipa.a .oInter-procedural analysis passes.
Transformation Libraries
LLVMInstrumentation.a .oInstrumentation passes.
LLVMipo.a .oAll inter-procedural optimization passes.
LLVMScalarOpts.a .oAll scalar optimization passes.
LLVMTransforms.a .oUncategorized transformation passes.
LLVMTransformUtils.a .oTransformation utilities.
LLVMProfilePaths.oProfile paths for instrumentation.
Code Generation Libraries
LLVMCodeGen.oNative code generation infrastructure
Target Libraries
LLVMCBackend.o'C' language code generator.
LLVMPowerPC.oPowerPC code generation backend
LLVMSelectionDAG.oAggressive instruction selector for directed acyclic graphs.
LLVMSkeleton.a .oSkeleton for a code generation backend.
LLVMSparcV8.oCode generation for SparcV8.
LLVMSparcV9.oCode generation for SparcV9.
LLVMSparcV9RegAlloc.a .oGraph-coloring register allocator for SparcV9.
LLVMSparcV9InstrSched.oInstruction scheduling for SparcV9.
LLVMSparcV9LiveVar.oLive variable analysis SparcV9.
LLVMSparcV9ModuloSched.oModulo scheduling for SparcV9.
LLVMTarget.a .oGeneric code generation utilities.
LLVMX86.oIntel x86 code generation backend
Runtime Libraries
LLVMInterpreter.oBytecode Interpreter
LLVMJIT.oBytecode JIT Compiler
LLVMExecutionEngine.oVirtual machine engine
LLVMexecve.oexecve(2) replacement for llee
+

+ + +
Library Dependencies
+
+

Below are two dependency graphs and a list that show the relationships + between the various LLVM archive libraries and object files. This information + can be automatically generated with the GenLibDeps.pl utility found + in the llvm/utils directory.

+ + + + + + +

Dependency Relationships Of Libraries

+

This graph shows the dependency of archive libraries on other archive + libraries or objects. Where a library has both archive and object forms, only + the archive form is shown.

+ Library Dependencies +

Dependency Relationships Of Object Files

+

This graph shows the dependency of object files on archive libraries or + other objects. Where a library has both object and archive forms, only the + dependency to the archive form is shown.

+ Object File Dependencies +

The following list shows the dependency relationships between libraries in + textual form. The information is the same as shown on the graphs but arranged + alphabetically.

+
+
libLLVMAnalysis.a
    +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
libLLVMArchive.a
    +
  • libLLVMSupport.a
  • +
  • libLLVMSystem.a
  • +
  • LLVMBCReader.o
  • +
+
libLLVMDataStructure.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
libLLVMInstrumentation.a
    +
  • libLLVMSupport.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
libLLVMLinker.a
    +
  • libLLVMArchive.a
  • +
  • libLLVMSystem.a
  • +
  • LLVMBCReader.o
  • +
  • LLVMCore.o
  • +
+
libLLVMScalarOpts.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
libLLVMSparcV9RegAlloc.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
  • LLVMSparcV9LiveVar.o
  • +
  • LLVMSparcV9.o
  • +
+
libLLVMSupport.a
    +
  • libLLVMSystem.a
  • +
  • LLVMbzip2.o
  • +
+
libLLVMSystem.a
+
libLLVMTarget.a
    +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
libLLVMTransformUtils.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
libLLVMTransforms.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
libLLVMipa.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
libLLVMipo.a
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMipa.a
  • +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
LLVMAnalysis.o
    +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
LLVMAsmParser.o
    +
  • LLVMCore.o
  • +
+
LLVMBCReader.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMSystem.a
  • +
  • LLVMCore.o
  • +
+
LLVMBCWriter.o
    +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
LLVMCBackend.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMipa.a
  • +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCore.o
  • +
+
LLVMCodeGen.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCore.o
  • +
+
LLVMCore.o
    +
  • libLLVMSupport.a
  • +
+
LLVMDataStructure.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
LLVMDebugger.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMSystem.a
  • +
  • LLVMBCReader.o
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
  • LLVMExecutionEngine.o
  • +
+
LLVMExecutionEngine.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMSystem.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCore.o
  • +
  • LLVMInterpreter.o
  • +
  • LLVMJIT.o
  • +
+
LLVMInstrumentation.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
LLVMInterpreter.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMSystem.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCore.o
  • +
  • LLVMExecutionEngine.o
  • +
+
LLVMJIT.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMSystem.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCore.o
  • +
  • LLVMExecutionEngine.o
  • +
+
LLVMPowerPC.o
    +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
+
LLVMProfilePaths.o
    +
  • libLLVMInstrumentation.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
LLVMScalarOpts.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
LLVMSelectionDAG.o
    +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
+
LLVMSkeleton.o
    +
  • libLLVMTarget.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
+
LLVMSparcV8.o
    +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
+
LLVMSparcV9.o
    +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSparcV9RegAlloc.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMBCWriter.o
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
  • LLVMSparcV9InstrSched.o
  • +
  • LLVMSparcV9ModuloSched.o
  • +
+
LLVMSparcV9InstrSched.o
    +
  • libLLVMSupport.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
  • LLVMSparcV9LiveVar.o
  • +
  • LLVMSparcV9.o
  • +
+
LLVMSparcV9LiveVar.o
    +
  • libLLVMSupport.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
+
LLVMSparcV9ModuloSched.o
    +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
  • LLVMSparcV9.o
  • +
+
LLVMSparcV9RegAlloc.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
  • LLVMSparcV9LiveVar.o
  • +
  • LLVMSparcV9.o
  • +
+
LLVMSupport.o
    +
  • libLLVMSystem.a
  • +
  • LLVMbzip2.o
  • +
+
LLVMSystem.o
+
LLVMTarget.o
    +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
LLVMTransformUtils.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
LLVMTransforms.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
LLVMX86.o
    +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • LLVMCodeGen.o
  • +
  • LLVMCore.o
  • +
+
LLVMbzip2.o
+
LLVMipa.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMSupport.a
  • +
  • LLVMCore.o
  • +
+
LLVMipo.o
    +
  • libLLVMAnalysis.a
  • +
  • libLLVMipa.a
  • +
  • libLLVMScalarOpts.a
  • +
  • libLLVMSupport.a
  • +
  • libLLVMTarget.a
  • +
  • libLLVMTransformUtils.a
  • +
  • LLVMCore.o
  • +
+
+
+ + + +
+

This section contains various "rules of thumb" about what files you + should link into your programs.

+
+ + +
+

No matter what you do with LLVM, the last three entries in the value of + your LLVMLIBS make variable should always be: + LLVMCore LLVMSupport.a LLVMSystem.a. There are no LLVM + programs that don't depend on these three.

+
+ + +
+

There is never any point to linking both the re-linked (.o) and + the archive (.a) versions of a library. Since the re-linked version + includes the entire library, the archive version will not resolve any symbols. + You could even end up with link error if you place the archive version before + the re-linked version on the linker's command line.

+
+ +
+ + + + Index: llvm-www/releases/1.6/docs/WritingAnLLVMBackend.html diff -c /dev/null llvm-www/releases/1.6/docs/WritingAnLLVMBackend.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/WritingAnLLVMBackend.html Tue Nov 8 14:06:34 2005 *************** *** 0 **** --- 1,259 ---- + + + + Writing an LLVM backend + + + + + +
+ Writing an LLVM backend +
+ +
    +
  1. Introduction +
  2. Writing a backend +
      +
    1. Machine backends +
        +
      1. Outline
      2. +
      3. Implementation details
      4. +
    2. +
    3. Language backends
    4. +
  3. +
  4. Related reading material +
+ +
+

Written by Misha Brukman

+
+ + + + + +
+ +

This document describes techniques for writing backends for LLVM which + convert the LLVM representation to machine assembly code or other languages.

+ +
+ + + + + + + + + +
+ Outline +
+ +
+ +

In general, you want to follow the format of X86 or PowerPC (in + lib/Target).

+ +

To create a static compiler (one that emits text assembly), you need to + implement the following:

+ +
    +
  • Describe the register set. +
      +
    • Create a TableGen description of + the register set and register classes
    • +
    • Implement a subclass of MRegisterInfo
    • +
  • +
  • Describe the instruction set. +
  • +
  • Describe the target machine. +
      +
    • Create a TableGen description of + the target that describes the pointer size and references the instruction + set
    • +
    • Implement a subclass of TargetMachine, which + configures TargetData + correctly
    • +
    • Register your new target using the RegisterTarget + template:

      +
      + RegisterTarget<MyTargetMachine> M("short_name", "  Target name");
      + 
      +
      Here, MyTargetMachine is the name of your implemented + subclass of TargetMachine, + short_name is the option that will be active following + -march= to select a target in llc and lli, and the last string + is the description of your target to appear in -help + listing.
    • +
  • +
  • Implement the assembly printer for the architecture. +
      +
    • Define all of the assembly strings for your target, adding them to the + instructions in your *InstrInfo.td file.
    • +
    • Implement the llvm::AsmPrinter interface.
    • +
    +
  • +
  • Implement an instruction selector for the architecture. +
      +
    • The recommended method is the + pattern-matching DAG-to-DAG instruction selector (for example, see + the PowerPC backend in PPCISelDAGtoDAG.cpp). Parts of instruction + selector creation can be performed by adding patterns to the instructions + in your .td file.
    • +
    +
  • +
  • Optionally, add subtarget support. +
      +
    • If your target has multiple subtargets (e.g. variants with different + capabilities), implement the llvm::TargetSubtarget interface + for your architecture. This allows you to add -mcpu= and + -mattr= options.
    • +
    +
  • Optionally, add JIT support. +
      +
    • Create a subclass of TargetJITInfo
    • +
    • Create a machine code emitter that will be used to emit binary code + directly into memory, given MachineInstrs
    • +
    +
+
+ + + + +
+ +
    + +
  • TableGen register info description - describe a class which + will store the register's number in the binary encoding of the instruction + (e.g., for JIT purposes).

    + +

    You also need to define register classes to contain these registers, such as + the integer register class and floating-point register class, so that you can + allocate virtual registers to instructions from these sets, and let the + target-independent register allocator automatically choose the actual + architected registers.

    + +
    +
    + // class Register is defined in Target.td
    + class TargetReg<string name> : Register<name> {
    +   let Namespace = "Target";
    + }
    + 
    + class IntReg<bits<5> num, string name> : TargetReg<name> {
    +   field bits<5> Num = num;
    + }
    + 
    + def R0 : IntReg<0, "%R0">;
    + ...
    + 
    + // class RegisterClass is defined in Target.td
    + def IReg : RegisterClass<i64, 64, [R0, ... ]>;
    + 
    +
    +
  • + +
  • TableGen instruction info description - break up instructions into + classes, usually that's already done by the manufacturer (see instruction + manual). Define a class for each instruction category. Define each opcode as a + subclass of the category, with appropriate parameters such as the fixed binary + encoding of opcodes and extended opcodes, and map the register bits to the bits + of the instruction which they are encoded in (for the JIT). Also specify how + the instruction should be printed so it can use the automatic assembly printer, + e.g.:

    + +
    +
    + // class Instruction is defined in Target.td
    + class Form<bits<6> opcode, dag OL, string asmstr> : Instruction {
    +   field bits<42> Inst;
    + 
    +   let Namespace = "Target";
    +   let Inst{0-6} = opcode;
    +   let OperandList = OL;
    +   let AsmString = asmstr;
    + }
    + 
    + def ADD : Form<42, (ops IReg:$rD, IReg:$rA, IReg:$rB), "add $rD, $rA, $rB">;
    + 
    +
    +
  • + +
+ +
+ + + + +
+ +

For now, just take a look at lib/Target/CBackend for an example of + how the C backend is written.

+ +
+ + + + + +
+ + + +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Misha Brukman
+ The LLVM Compiler Infrastructure +
+ Last modified: $Date: 2005/11/08 20:06:34 $ +
+ + + Index: llvm-www/releases/1.6/docs/WritingAnLLVMPass.html diff -c /dev/null llvm-www/releases/1.6/docs/WritingAnLLVMPass.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/WritingAnLLVMPass.html Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,1600 ---- + + + + + Writing an LLVM Pass + + + + +
+ Writing an LLVM Pass +
+ +
    +
  1. Introduction - What is a pass?
  2. +
  3. Quick Start - Writing hello world +
  4. +
  5. Pass classes and requirements + +
  6. Pass Registration +
  7. +
  8. Specifying interactions between passes +
  9. +
  10. Implementing Analysis Groups +
  11. +
  12. Pass Statistics +
  13. What PassManager does +
  14. +
  15. Using GDB with dynamically loaded passes +
  16. +
  17. Future extensions planned +
  18. +
+ +
+

Written by Chris Lattner

+
+ + + + + +
+ +

The LLVM Pass Framework is an important part of the LLVM system, because LLVM + passes are where most of the interesting parts of the compiler exist. Passes + 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 should inherit from + the ModulePass, CallGraphSCCPass, FunctionPass, or BasicBlockPass classes, 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 meets (which are indicated by which class they derive from).

+ +

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.

+ +
+ + + + + +
+ +

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, it just + inspects it. The source code and files for this pass are available in the LLVM + source tree in the lib/Transforms/Hello directory.

+ +
+ + + + +
+ +

First, you need to create a new directory somewhere in the LLVM source + base. For this example, we'll assume that you made + lib/Transforms/Hello. Next, you must set up a build script + (Makefile) that will compile the source code for the new pass. To do this, + copy the following into Makefile:

+
+ +
+ # Makefile for hello pass
+ 
+ # Path to top level of LLVM heirarchy
+ LEVEL = ../../..
+ 
+ # Name of the library to build
+ LIBRARYNAME = Hello
+ 
+ # Build a dynamically linkable shared object
+ SHARED_LIBRARY = 1
+ 
+ # Make the shared library become a loadable module so the tools can 
+ # dlopen/dlsym on the resulting library.
+ LOADABLE_MODULE
+ 
+ # 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 + Debug/lib/Hello.so shared object that can be dynamically loaded by + the opt or analyze tools via their -load options. + If your operating system uses a suffix other than .so (such as windows or + Mac OS/X), the appropriate extension will be used.

+ +

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

+ +
+ + + + +
+ +

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:

+
+ using namespace llvm;
+ 
+

... which is required because the functions from the include files + live in the llvm namespace. +

+ +

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"
+ 
+ using namespace llvm;
+ 
+ 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 + "Debug/lib/Hello.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.

+ +
+ + + + +
+ +

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 ../../../Debug/lib/Hello.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 ../../../Debug/lib/Hello.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 ../../../Debug/lib/Hello.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.

+ +
+ + + + + +
+ +

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 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 "ModulePass" + class is the most general of all superclasses that you can use. Deriving from + ModulePass 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 ModulePass + subclasses, no optimization can be done for their execution.

+ +

To write a correct ModulePass subclass, derive from + ModulePass and overload the runOnModule method with the + following signature:

+ +
+ + + + +
+ +
+   virtual bool runOnModule(Module &M) = 0;
+ 
+ +

The runOnModule method performs the interesting work of the pass. + It should return true if the module was modified by the transformation and + false otherwise.

+ +
+ + + + +
+ +

The "CallGraphSCCPass" + is used by passes that need to traverse the program bottom-up on the call graph + (callees before callers). Deriving from CallGraphSCCPass provides some + mechanics for building and traversing the CallGraph, but also allows the system + to optimize execution of CallGraphSCCPass's. If your pass meets the + requirements outlined below, and doesn't meet the requirements of a FunctionPass or BasicBlockPass, you should derive from + CallGraphSCCPass.

+ +

TODO: explain briefly what SCC, Tarjan's algo, and B-U mean.

+ +

To be explicit, CallGraphSCCPass subclasses are:

+ +
    + +
  1. ... not allowed to modify any Functions that are not in + the current SCC.
  2. + +
  3. ... allowed to inspect any Function's other than those in the + current SCC and the direct callees of the SCC.
  4. + +
  5. ... required to preserve the current CallGraph object, updating it + to reflect any changes made to the program.
  6. + +
  7. ... not allowed to add or remove SCC's from the current Module, + though they may change the contents of an SCC.
  8. + +
  9. ... allowed to add or remove global variables from the current + Module.
  10. + +
  11. ... allowed to maintain state across invocations of + runOnSCC (including global data).
  12. +
+ +

Implementing a CallGraphSCCPass is slightly tricky in some cases + because it has to handle SCCs with more than one node in it. All of the virtual + methods described below should return true if they modified the program, or + false if they didn't.

+ +
+ + + + +
+ +
+   virtual bool doInitialization(Module &M);
+ 
+ +

The doIninitialize method is allowed to do most of the things that + CallGraphSCCPass'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 SCCs being processed. The doInitialization method call is not + scheduled to overlap with any other pass executions (thus it should be very + fast).

+ +
+ + + + +
+ +
+   virtual bool runOnSCC(const std::vector<CallGraphNode *> &SCCM) = 0;
+ 
+ +

The runOnSCC method performs the interesting work of the pass, and + should return true if the module was modified by the transformation, false + otherwise.

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

+ +
+ + + + +
+ +

In contrast to ModulePass subclasses, 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. +
  3. Add or remove Function's from the current Module.
  4. +
  5. Add or remove global variables from the current Module.
  6. +
  7. Maintain state across invocations of + runOnFunction (including global data)
  8. +
+ +

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.

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

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

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

+ +
+ + + + +
+ +

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. +
  3. Maintain state across invocations of + runOnBasicBlock
  4. +
  5. Modify the control flow graph (by altering terminator instructions)
  6. +
  7. Any of the things forbidden for + FunctionPasses.
  8. +
+ +

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:

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

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

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

+ +
+ + + + +
+ +

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. +
  3. Modify a MachineFunction other than the one currently being processed.
  4. +
  5. Add or remove MachineFunctions from the current Module.
  6. +
  7. Add or remove global variables from the current Module.
  8. +
  9. Maintain state across invocations of runOnMachineFunction (including global + data)
  10. +
+ +
+ + + + +
+ +
+   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.

+ +
+ + + + + +
+ +

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:

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

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +
+   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:

+
+ + + + +
+

+ If your pass requires a previous pass to be executed (an analysis for example), + it can use one of these methods to arrange for it to be run before your pass. + LLVM has many different types of analyses and passes that can be required, + spanning 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. +

+
+ + + + +
+

+ 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 possibly affect 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. +

+
+ + + + +
+ +
+   // 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 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.
+   }
+   ...
+ 
+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+

The Statistic + class, is designed to be an easy way to expose various success + metrics from passes. These statistics are printed at the end of a + run, when the -stats command line option is enabled on the command + line. See the Statistics section in the Programmer's Manual for details. + +

+ + + + + + +
+ +

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

  4. + +
+ +

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 ../../../Debug/lib/Hello.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 ../../../Debug/lib/Hello.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 ../../../Debug/lib/Hello.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.

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

+ +
+ + + + + +
+ +

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.

+ +
+ + + + +
+ +

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/Debug/lib/[libname].so -[passoption]
+ Starting program: opt test.bc -load $(LLVMTOP)/llvm/Debug/lib/[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.

+ +
+ + + + +
+ +

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.

+ +
+ + + + + +
+ +

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:

+ +
+ + + + +
+ +

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.

+ +
+ + + + +
+ +

Currently it is illegal for a ModulePass + 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 ModulePass, only the other way around.

+ +
+ + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ The LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:35 $ +
+ + + Index: llvm-www/releases/1.6/docs/doxygen.cfg diff -c /dev/null llvm-www/releases/1.6/docs/doxygen.cfg:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/doxygen.cfg Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,863 ---- + # 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 = 1.6cvs + + # 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 = /home/vadve/lattner/llvm/docs/.././docs/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 = /home/vadve/lattner/llvm/docs/../include /home/vadve/lattner/llvm/docs/../lib /home/vadve/lattner/llvm/docs/../docs/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 u sed 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 = + + # 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 = /home/vadve/lattner/llvm/docs/../examples + + # 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 = YES + + # 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 = /home/vadve/lattner/llvm/docs/../docs/img + + # 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 = 4 + + # 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 = llvm:: + + #--------------------------------------------------------------------------- + # 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 = html + + # 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 = /home/vadve/lattner/llvm/docs/../docs/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 = /home/vadve/lattner/llvm/docs/../docs/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 = /home/vadve/lattner/llvm/docs/../docs/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 = letter + + # 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 = /home/vadve/lattner/local/x86-fc1/bin/dot + + # 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 Index: llvm-www/releases/1.6/docs/doxygen.cfg.in diff -c /dev/null llvm-www/releases/1.6/docs/doxygen.cfg.in:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/doxygen.cfg.in Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,863 ---- + # 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 = @PACKAGE_VERSION@ + + # 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 = @abs_top_builddir@/docs/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 = @abs_top_srcdir@/include @abs_top_srcdir@/lib @abs_top_srcdir@/docs/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 u sed 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 = + + # 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 = @abs_top_srcdir@/examples + + # 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 = YES + + # 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 = @abs_top_srcdir@/docs/img + + # 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 = 4 + + # 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 = llvm:: + + #--------------------------------------------------------------------------- + # 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 = html + + # 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 = @abs_top_srcdir@/docs/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 = @abs_top_srcdir@/docs/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 = @abs_top_srcdir@/docs/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 = letter + + # 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 = @DOT@ + + # 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 Index: llvm-www/releases/1.6/docs/doxygen.css diff -c /dev/null llvm-www/releases/1.6/docs/doxygen.css:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/doxygen.css Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,90 ---- + 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: 25pt; + color: black; background: url("../img/lines.gif"); + font-weight: bold; + border-width: 1px; + border-style: solid none solid none; + text-align: center; + vertical-align: middle; + padding-left: 8pt; + padding-top: 1px; + padding-bottom: 2px + } Index: llvm-www/releases/1.6/docs/doxygen.footer diff -c /dev/null llvm-www/releases/1.6/docs/doxygen.footer:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/doxygen.footer Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,10 ---- +
+ + + + + Index: llvm-www/releases/1.6/docs/doxygen.header diff -c /dev/null llvm-www/releases/1.6/docs/doxygen.header:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/doxygen.header Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,9 ---- + + + + + + LLVM: $title + + +

LLVM API Documentation

Index: llvm-www/releases/1.6/docs/doxygen.intro diff -c /dev/null llvm-www/releases/1.6/docs/doxygen.intro:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/doxygen.intro Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,18 ---- + /// @mainpage 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.6/docs/index.html diff -c /dev/null llvm-www/releases/1.6/docs/index.html:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/index.html Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,247 ---- + + + + Documentation for the LLVM System + + + + +
Documentation for the LLVM System
+ + + +
+

Written by The LLVM Team

+
+ + + + + + + + + + + + + + + + + + + + + + + + +
    + +
  • Writing an LLVM Pass - Information + on how to write LLVM transformations and analyses.
  • + +
  • Writing an LLVM Backend - Information + on how to write LLVM backends for machine targets.
  • + +
  • The LLVM Target-Independent Code + Generator - The design and implementation of the LLVM code generator. + Useful if you are working on retargetting LLVM to a new architecture, designing + a new codegen pass, or enhancing existing components.
  • + +
  • TableGen Fundamentals - + Describes the TableGen tool, which is used heavily by the LLVM code + generator.
  • + +
  • Alias Analysis in LLVM - Information + on how to write a new alias analysis implementation or how to use existing + analyses.
  • + +
  • The Stacker Chronicles - This document + describes both the Stacker language and LLVM frontend, but also some details + about LLVM useful for those writing front-ends.
  • + +
  • Accurate Garbage Collection with + LLVM - The interfaces source-language compilers should use for compiling + GC'd programs.
  • + +
  • Source Level Debugging with + LLVM - This document describes the design and philosophy behind the LLVM + source-level debugger.
  • + +
  • Bugpoint - automatic bug finder and test-case + reducer description and usage information.
  • + +
  • Compiler Driver (llvmc) - This document + describes the design and configuration of the LLVM compiler driver tool, + llvmc.
  • + +
  • System Library - This document describes + the LLVM System Library (lib/System) and how to keep LLVM source code + portable
  • + +
+ + + + + +
    +
  • The + LLVM Announcements List: This is a low volume list that provides important + announcements regarding LLVM. It gets email about once a month.
  • + +
  • The Developer's + List: 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.
  • + +
  • The Bugs & + Patches Archive: This list gets emailed every time a bug is opened and + closed, and when people submit patches to be included in LLVM. It is higher + volume than the LLVMdev list.
  • + +
  • The CVS Commits + Archive: 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.
  • + +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:35 $ +
+ Index: llvm-www/releases/1.6/docs/llvm.css diff -c /dev/null llvm-www/releases/1.6/docs/llvm.css:1.1 *** /dev/null Tue Nov 8 14:06:47 2005 --- llvm-www/releases/1.6/docs/llvm.css Tue Nov 8 14:06:35 2005 *************** *** 0 **** --- 1,84 ---- + /* + * LLVM documentation 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; } + + TR, TD { border: 2px solid gray; padding: 4pt 4pt 2pt 2pt; } + TH { border: 2px solid gray; font-weight: bold; font-size: 105%; + color: black; background: url("img/lines.gif"); + font-family: "Georgia,Palatino,Times,Roman,SanSerif"; text-align:center; + vertical-align: middle; } + TABLE { text-align: center; border: 2px solid black; + border-collapse: collapse; margin-top: 1em; margin-left: 1em; + margin-right: 1em; margin-bottom: 1em; } + /* + * Documentation + */ + /* Common for title and header */ + .doc_title, .doc_section, .doc_subsection { + color: black; background: url("img/lines.gif"); + font-family: "Georgia,Palatino,Times,Roman,SanSerif"; font-weight: bold; + border-width: 1px; + border-style: solid none solid none; + text-align: center; + vertical-align: middle; + 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; + margin: 20pt 0pt 5pt 0pt; } + .doc_subsection { width: 75%; + text-align: left; font-size: 12pt; padding: 4pt 4pt 4pt 4pt; + margin: 1.5em 0.5em 0.5em 0.5em } + + .doc_subsubsection { margin: 2.0em 0.5em 0.5em 0.5em; + font-weight: bold; font-style: oblique; + border-bottom: 1px solid #999999; font-size: 12pt; + width: 75%; } + .doc_author { text-align: left; font-weight: bold; padding-left: 20pt } + .doc_text { text-align: left; padding-left: 20pt; padding-right: 10pt } + + .doc_footer { text-align: left; padding: 0 0 0 0 } + + .doc_hilite { color: blue; font-weight: bold; } + + .doc_table { text-align: center; width: 90%; + padding: 1px 1px 1px 1px; border: 1px; } + + .doc_table_nw { text-align: center; border: 1px; + padding: 1px 1px 1px 1px; } + + .doc_warning { color: red; font-weight: bold } + + .doc_code { border: solid 1px gray; background: #eeeeee; + margin: 0 1em 0 1em; + padding: 0 1em 0 1em; + display:table; + } + .doc_notes { background: #fafafa; border: 1px solid #cecece; padding: 1em } + + TABLE.layout { text-align: left; border: none; border-collapse: collapse; + padding: 4px 4px 4px 4px; } + TR.layout { border: none; padding: 4pt 4pt 2pt 2pt; } + TD.layout { border: none; padding: 4pt 4pt 2pt 2pt; + vertical-align: top;} + TD.left { border: none; padding: 4pt 4pt 2pt 2pt; text-align: left; + vertical-align: top;} + TD.right { border: none; padding: 4pt 4pt 2pt 2pt; text-align: right; + vertical-align: top;} + TH.layout { border: none; font-weight: bold; font-size: 105%; + text-align:center; vertical-align: middle; } + + /* Left align table cell */ + .td_left { border: 2px solid gray; text-align: left; } From lattner at cs.uiuc.edu Tue Nov 8 14:06:50 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:06:50 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/Makefile analyze.pod bugpoint.pod gccas.pod gccld.pod index.html llc.pod lli.pod llvm-ar.pod llvm-as.pod llvm-bcanalyzer.pod llvm-db.pod llvm-dis.pod llvm-extract.pod llvm-ld.pod llvm-link.pod llvm-nm.pod llvm-prof.pod llvm-ranlib.pod llvmc.pod llvmgcc.pod llvmgxx.pod manpage.css opt.pod pod2htmd.tmp pod2htmi.tmp stkrc.pod Message-ID: <200511082006.OAA30390@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide: Makefile added (r1.1) analyze.pod added (r1.1) bugpoint.pod added (r1.1) gccas.pod added (r1.1) gccld.pod added (r1.1) index.html added (r1.1) llc.pod added (r1.1) lli.pod added (r1.1) llvm-ar.pod added (r1.1) llvm-as.pod added (r1.1) llvm-bcanalyzer.pod added (r1.1) llvm-db.pod added (r1.1) llvm-dis.pod added (r1.1) llvm-extract.pod added (r1.1) llvm-ld.pod added (r1.1) llvm-link.pod added (r1.1) llvm-nm.pod added (r1.1) llvm-prof.pod added (r1.1) llvm-ranlib.pod added (r1.1) llvmc.pod added (r1.1) llvmgcc.pod added (r1.1) llvmgxx.pod added (r1.1) manpage.css added (r1.1) opt.pod added (r1.1) pod2htmd.tmp added (r1.1) pod2htmi.tmp added (r1.1) stkrc.pod added (r1.1) --- Log message: Check in the 1.6 docs --- Diffs of the changes: (+3442 -0) Makefile | 101 ++++++++++++ analyze.pod | 75 +++++++++ bugpoint.pod | 118 +++++++++++++++ gccas.pod | 76 +++++++++ gccld.pod | 175 ++++++++++++++++++++++ index.html | 147 ++++++++++++++++++ llc.pod | 185 +++++++++++++++++++++++ lli.pod | 76 +++++++++ llvm-ar.pod | 406 ++++++++++++++++++++++++++++++++++++++++++++++++++++ llvm-as.pod | 77 +++++++++ llvm-bcanalyzer.pod | 315 ++++++++++++++++++++++++++++++++++++++++ llvm-db.pod | 16 ++ llvm-dis.pod | 60 +++++++ llvm-extract.pod | 63 ++++++++ llvm-ld.pod | 171 +++++++++++++++++++++ llvm-link.pod | 74 +++++++++ llvm-nm.pod | 122 +++++++++++++++ llvm-prof.pod | 57 +++++++ llvm-ranlib.pod | 52 ++++++ llvmc.pod | 405 +++++++++++++++++++++++++++++++++++++++++++++++++++ llvmgcc.pod | 95 ++++++++++++ llvmgxx.pod | 95 ++++++++++++ manpage.css | 256 ++++++++++++++++++++++++++++++++ opt.pod | 97 ++++++++++++ pod2htmd.tmp | 30 +++ pod2htmi.tmp | 2 stkrc.pod | 96 ++++++++++++ 27 files changed, 3442 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/Makefile diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/Makefile:1.1 *** /dev/null Tue Nov 8 14:06:48 2005 --- llvm-www/releases/1.6/docs/CommandGuide/Makefile Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,101 ---- + ##===- docs/CommandGuide/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. + # + ##===----------------------------------------------------------------------===## + + ifdef BUILD_FOR_WEBSITE + + # This special case is for keeping the CommandGuide on the LLVM web site + # up to date automatically as the documents are checked in. It must build + # the POD files to HTML only and keep them in the src directories. It must also + # build in an unconfigured tree, hence the ifdef. To use this, run + # make -s BUILD_FOR_WEBSITE=1 inside the cvs commit script. + + POD := $(wildcard *.pod) + HTML := $(patsubst %.pod, html/%.html, $(POD)) + MAN := $(patsubst %.pod, man/man1/%.1, $(POD)) + PS := $(patsubst %.pod, ps/%.ps, $(POD)) + + all: $(HTML) $(MAN) $(PS) + + .SUFFIXES: + .SUFFIXES: .html .pod .1 .ps + + html/%.html: %.pod + pod2html --css=manpage.css --htmlroot=. \ + --podpath=. --noindex --infile=$< --outfile=$@ --title=$* + + man/man1/%.1: %.pod + pod2man --release=1.5 --center="LLVM Command Guide" $< $@ + + ps/%.ps: man/man1/%.1 + groff -Tps -man $< > $@ + + clean: + rm -f pod2htm*.*~~ $(HTML) $(MAN) $(PS) + + else + + LEVEL := ../.. + + include $(LEVEL)/Makefile.common + + POD := $(wildcard $(PROJ_SRC_DIR)/*.pod) + + EXTRA_DIST := $(POD) index.html + + HTML = $(patsubst $(PROJ_SRC_DIR)/%.pod, $(PROJ_OBJ_DIR)/%.html, $(POD)) + MAN = $(patsubst $(PROJ_SRC_DIR)/%.pod, $(PROJ_OBJ_DIR)/%.1, $(POD)) + PS = $(patsubst $(PROJ_SRC_DIR)/%.pod, $(PROJ_OBJ_DIR)/%.ps, $(POD)) + + .SUFFIXES: + .SUFFIXES: .html .pod .1 .ps + + $(HTML) : html/.dir man/.dir man/man1/.dir ps/.dir + + html: $(HTML) + + $(PROJ_OBJ_DIR)/%.html: %.pod + $(POD2HTML) --css=manpage.css --htmlroot=. --podpath=. \ + --noindex --infile=$< --outfile=$@ --title=$* + + $(PROJ_OBJ_DIR)/%.1: %.pod + $(POD2MAN) --release=$(LLVMVersion) \ + --center="LLVM Command Guide" $< $@ + + $(PROJ_OBJ_DIR)/%.ps: $(PROJ_OBJ_DIR)/%.1 + $(GROFF) -Tps -man $< > $@ + + clean-local:: + $(Verb) $(RM) -f pod2htm*.*~~ $(HTML) $(MAN) $(PS) + + HTML_DIR := $(PROJ_docsdir)/html/CommandGuide + MAN_DIR := $(PROJ_mandir)/man1 + PS_DIR := $(PROJ_docsdir)/ps + + install-local:: $(HTML) $(MAN) $(PS) + $(Echo) Installing HTML CommandGuide Documentation + $(Verb) $(MKDIR) $(HTML_DIR) + $(Verb) $(DataInstall) $(HTML) $(HTML_DIR) + $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/index.html $(HTML_DIR) + $(Verb) $(DataInstall) $(PROJ_SRC_DIR)/manpage.css $(HTML_DIR) + $(Echo) Installing MAN CommandGuide Documentation + $(Verb) $(MKDIR) $(MAN_DIR) + $(Verb) $(DataInstall) $(MAN) $(MAN_DIR) + $(Echo) Installing PS CommandGuide Documentation + $(Verb) $(MKDIR) $(PS_DIR) + $(Verb) $(DataInstall) $(PS) $(PS_DIR) + + uninstall-local:: + $(Echo) Uninstalling Documentation + $(Verb) $(RM) -rf $(LLVM_DOCSDIR) + + printvars:: + $(Echo) "POD : " '$(POD)' + $(Echo) "HTML : " '$(HTML)' + + endif Index: llvm-www/releases/1.6/docs/CommandGuide/analyze.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/analyze.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/analyze.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,75 ---- + =pod + + =head1 NAME + + analyze - LLVM program analyzer + + =head1 SYNOPSIS + + B [I] [I] + + =head1 DESCRIPTION + + The B 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 I<->, B 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. + + =head1 OPTIONS + + =over + + =item B<-help> + + Print a summary of command line options. + + =item B<-q> + + Quiet mode. With this option, analysis pass names are not printed. + + =item B<-load> I + + Load the specified dynamic object with name I. This file + should contain additional analysis passes that register themselves + with the B program after being loaded. + + After being loaded, additional command line options are made + available for running the passes made available by I. Use + B I B<-help> to see the new list of available + analysis passes. + + =item B<-profile-info-file> I + + Specify the name of the file loaded by the -profile-loader option. + + =item B<-stats> + + Print statistics. + + =item B<-time-passes> + + Record the amount of time needed for each pass and print it to standard + error. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + + =head1 SEE ALSO + + L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/bugpoint.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/bugpoint.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/bugpoint.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,118 ---- + =pod + + =head1 NAME + + bugpoint - automatic test case reduction tool + + =head1 SYNOPSIS + + B [I] [I] [I] B<--args> + I + + =head1 DESCRIPTION + + B narrows down the source of problems in LLVM tools and passes. It + can be used to debug three types of failures: optimizer crashes, miscompilations + by optimizers, or bad native code generation (including problems in the static + and JIT compilers). It aims to reduce large test cases to small, useful ones. + For more information on the design and inner workings of B, as well as + advice for using bugpoint, see F in the LLVM + distribution. + + =head1 OPTIONS + + =over + + =item B<--additional-so> F + + Load the dynamic shared object F into the test program whenever it is + run. This is useful if you are debugging programs which depend on non-LLVM + libraries (such as the X or curses libraries) to run. + + =item B<--args> I + + Pass all arguments specified after -args to the test program whenever it runs. + Note that if any of the I start with a '-', you should use: + + bugpoint [bugpoint args] --args -- [program args] + + The "--" right after the B<--args> option tells B to consider any + options starting with C<-> to be part of the B<--args> option, not as options to + B itself. + + =item B<--tool-args> I + + Pass all arguments specified after --tool-args to the LLVM tool under test + (B, B, etc.) whenever it runs. You should use this option in the + following way: + + bugpoint [bugpoint args] --tool-args -- [tool args] + + The "--" right after the B<--tool-args> option tells B to consider any + options starting with C<-> to be part of the B<--tool-args> option, not as + options to B itself. (See B<--args>, above.) + + =item B<--check-exit-code>=I<{true,false}> + + Assume a non-zero exit code or core dump from the test program is a failure. + Defaults to true. + + =item B<--disable-{dce,simplifycfg}> + + Do not run the specified passes to clean up and reduce the size of the test + program. By default, B uses these passes internally when attempting to + reduce test programs. If you're trying to find a bug in one of these passes, + B may crash. + + =item B<--help> + + Print a summary of command line options. + + =item B<--input> F + + Open F and redirect the standard input of the test program, whenever + it runs, to come from that file. + + =item B<--load> F + + Load the dynamic object F into B itself. This object should + register new optimization passes. Once loaded, the object will add new command + line options to enable various optimizations. To see the new complete list of + optimizations, use the B<--help> and B<--load> options together; for example: + + bugpoint --load myNewPass.so --help + + =item B<--output> F + + Whenever the test program produces output on its standard output stream, it + should match the contents of F (the "reference output"). If you + do not use this option, B will attempt to generate a reference output + by compiling the program with the C backend and running it. + + =item B<--profile-info-file> F + + Profile file loaded by B<--profile-loader>. + + =item B<--run-{int,jit,llc,cbe}> + + Whenever the test program is compiled, B should generate code for it + using the specified code generator. These options allow you to choose the + interpreter, the JIT compiler, the static native code compiler, or the C + backend, respectively. + + =back + + =head1 EXIT STATUS + + If B succeeds in finding a problem, it will exit with 0. Otherwise, + if an error occurs, it will exit with a non-zero value. + + =head1 SEE ALSO + + L, L + + =head1 AUTHOR + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/gccas.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/gccas.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/gccas.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,76 ---- + =pod + + =head1 NAME + + gccas - optimizing LLVM assembler + + =head1 SYNOPSIS + + B [I] I + + =head1 DESCRIPTION + + The B utility takes an LLVM assembly file generated by the + L or L front-ends 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. + + B performs a number of optimizations on the input program, + including but not limited to: promotion of stack values to SSA + registers; elimination of dead globals, function arguments, code, + and types; tail-call elimination; loop-invariant code motion; global + common-subexpression elimination; and sparse conditional constant + propagation. + + =head1 OPTIONS + + =over + + =item B<--help> + + Print a summary of command line options. + + =item B<-o> F + + Specify the name of the output file which will hold the assembled bytecode. + + =item B<--disable-inlining> + + Disable the inlining pass. By default, it is enabled. + + =item B<--disable-opt> + + Disable all assembler-time optimization passes. + + =item B<--stats> + + Print statistics. + + =item B<--time-passes> + + Record the amount of time needed for each pass and print it to standard + error. + + =item B<--verify> + + Verify each pass result. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with an exit status of 0. + Otherwise, if an error occurs, it will exit with a non-zero exit + status. + + =head1 SEE ALSO + + L, L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/gccld.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/gccld.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/gccld.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,175 ---- + =pod + + =head1 NAME + + gccld - optimizing LLVM linker + + =head1 SYNOPSIS + + B [I] I + + =head1 DESCRIPTION + + The B 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, B is able to produce native code executables. + + The B utility is primarily used by the L and + L 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 B tool performs a small set of interprocedural, post-link + optimizations on the program. + + =head2 Search Order + + When looking for objects specified on the command line, B will search for + the object first in the current directory and then in the directory specified by + the B environment variable. If it cannot find the object, + it fails. + + When looking for a library specified with the B<-l> option, B first + attempts to load a file with that name from the current directory. If that + fails, it looks for libI.bc, libI.a, or libI.I, in that order, in each directory added to the library search + path with the B<-L> option. These directories are searched in the order they + were specified. If the library cannot be located, then B looks in the + directory specified by the B environment variable. If it + does not find a library there, it fails. + + The shared library extension may be I<.so>, I<.dyld>, I<.dll>, or something + different, depending upon the system. + + The B<-L> option is global. It does not matter where it is specified in the + list of command line arguments; the directory is simply added to the search path + and is applied to all libraries, preceding or succeeding, in the command line. + + =head2 Link order + + All object files are linked first in the order they were specified on the + command line. All library files are linked next. Some libraries may not be + linked into the object program; see below. + + =head2 Library Linkage + + Object files and static 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. + + =head2 Native code generation + + The B program has limited support for native code generation, when + using the B<-native> or B<-native-cbe> options. + + =head1 OPTIONS + + =over + + =item B<-help> + + Print a summary of command line options. + + =item B<-o> I + + Specify the output filename which will hold the linked bytecode. + + =item B<-stats> + + Print statistics. + + =item B<-time-passes> + + Record the amount of time needed for each pass and print it to standard + error. + + =item B<-verify> + + Verify each pass result. + + =item B<-disable-opt> + + Disable all link-time optimization passes. + + =item B<-disable-inlining> + + Do not run the inliner pass. + + =item B<-L>I + + Add directory to the list of directories to search when looking for + libraries. + + =item B<-disable-internalize> + + Do not mark all symbols as internal. + + =item B<-internalize-public-api-file> I + + Preserve the list of symbol names in the file filename. + + =item B<-internalize-public-api-list> I + + Preserve the symbol names in list. + + =item B<-l>I + + Specify libraries to include when linking the output file. When linking, + B will first attempt to load a file with the pathname B. If + that fails, it will then attempt to load libI.bc, libI.a, and + libI.I, in that order. + + =item B<-link-as-library> + + Link the .bc files together as a library, not an executable. + + =item B<-native> + + Generate a native machine code executable. + + When generating native executables, B first checks for a bytecode + version of the library and links it in, if necessary. If the library is + missing, B skips it. Then, B links in the same + libraries as native code. + + In this way, B 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. + + =item B<-native-cbe> + + Generate a native machine code executable with the LLVM C backend. + + This option is identical to the B<-native> option, but uses the + C backend to generate code for the program instead of an LLVM native + code generator. + + =item B<-s> + + Strip symbol information from the generated executable. + + =item B<-v> + + Print information about actions taken. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with an exit status of 0. + Otherwise, if an error occurs, it will exit with a non-zero exit + status. + + =head1 SEE ALSO + + L, L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/index.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/index.html:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/index.html Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,147 ---- + + + + LLVM Command Guide + + + + +
+ LLVM Command Guide +
+ +
+ +

These documents are HTML versions of the man pages + for all of the LLVM tools. These pages describe how to use the LLVM commands + and what their options are. Note that these pages do not describe all of the + options available for all tools. To get a complete listing, pass the + --help (general options) or --help-hidden (general+debugging + options) arguments to the tool you are interested in.

+ +
+ + + + + +
+ +
    + +
  • llvm-as - + assemble a human-readable .ll file into bytecode
  • + +
  • llvm-dis - + disassemble a bytecode file into a human-readable .ll file
  • + +
  • opt - + run a series of LLVM-to-LLVM optimizations on a bytecode file
  • + +
  • llc - + generate native machine code for a bytecode file
  • + +
  • lli - + directly run a program compiled to bytecode using a JIT compiler or + interpreter
  • + +
  • llvm-link - + link several bytecode files into one
  • + +
  • analyze - + run LLVM analyses on a bytecode file and print the results
  • + +
  • llvm-ar - + archive bytecode files
  • + +
  • llvm-ranlib - + create an index for archives made with llvm-ar
  • + +
  • llvm-nm - + print out the names and types of symbols in a bytecode file
  • + +
  • llvm-prof - + format raw `llvmprof.out' data into a human-readable report
  • + +
  • llvmc - + generic and configurable compiler driver
  • + +
  • llvm-ld - + general purpose linker with loadable runtime optimization support
  • + +
+ +
+ + + + + +
+
    + +
  • llvmgcc - + GCC-based C front-end for LLVM + +
  • llvmg++ - + GCC-based C++ front-end for LLVM
  • + +
  • gccas - + compile-time optimizer used by llvm-g++ and llvm-gcc
  • + +
  • gccld - + linker and link-time optimizer used by llvm-g++ and llvm-gcc
  • + +
  • stkrc - + front-end compiler for the Stacker + language
  • + +
+ +
+ + + + + + +
+ +
    + +
  • bugpoint - + automatic test-case reducer
  • + +
  • llvm-extract - + extract a function from an LLVM bytecode file
  • + +
  • llvm-bcanalyzer - + bytecode analyzer (analyzes the binary encoding itself, not the program it + represents)
  • + +
+ +
+ + + +
+
+ Valid CSS! + Valid HTML 4.01! + + LLVM Compiler Infrastructure
+ Last modified: $Date: 2005/11/08 20:06:38 $ +
+ + + Index: llvm-www/releases/1.6/docs/CommandGuide/llc.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llc.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llc.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,185 ---- + =pod + + =head1 NAME + + llc - LLVM static compiler + + =head1 SYNOPSIS + + B [I] [I] + + =head1 DESCRIPTION + + The B 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 a native executable. + + The choice of architecture for the output assembly code is automatically + determined from the input bytecode file, unless the B<-march> option is used to + override the default. + + =head1 OPTIONS + + If I is - or omitted, B reads LLVM bytecode from standard input. + Otherwise, it will read LLVM bytecode from I. + + If the B<-o> option is omitted, then B will send its output to standard + output if the input is from standard input. If the B<-o> option specifies -, + then the output will also be sent to standard output. + + If no B<-o> option is specified and an input file other than - is specified, + then B creates the output filename by taking the input filename, + removing any existing F<.bc> extension, and adding a F<.s> suffix. + + Other B options are as follows: + + =head2 End-user Options + + =over + + =item B<--help> + + Print a summary of command line options. + + =item B<-f> + + Overwrite output files. By default, B will refuse to overwrite + an output file which already exists. + + =item B<-march>=I + + Specify the architecture for which to generate assembly, overriding the target + encoded in the bytecode file. See the output of B for a list of + valid architectures. + + =item B<--disable-fp-elim> + + Disable frame pointer elimination optimization. + + =item B<--disable-excess-fp-precision> + + Disable optimizations that may produce excess precision for floating point. + Note that this option can dramatically slow down code on some systems + (e.g. X86). + + =item B<--enable-unsafe-fp-math> + + Enable optimizations that make unsafe assumptions about IEEE math (e.g. that + addition is associative) or may not work for all input ranges. These + optimizations allow the code generator to make use of some instructions which + would otherwise not be usable (such as fsin on X86). + + =item B<--enable-correct-eh-support> + + Instruct the B pass to insert code for correct exception handling + support. This is expensive and is by default omitted for efficiency. + + =item B<--stats> + + Print statistics recorded by code-generation passes. + + =item B<--time-passes> + + Record the amount of time needed for each pass and print a report to standard + error. + + =item B<--load>=F + + Dynamically load F (a path to a dynamically shared object) that + implements an LLVM target. This will permit the target name to be used with the + B<-march> option so that code can be generated for that target. + + =back + + =head2 Tuning/Configuration Options + + =over + + =item B<--print-machineinstrs> + + Print generated machine code between compilation phases (useful for debugging). + + =item B<--regalloc>=I + + Specify the register allocator to use. The default I is I. + Valid register allocators are: + + =over + + =item I + + Very simple "always spill" register allocator + + =item I + + Local register allocator + + =item I + + Linear scan global register allocator + + =item I + + Iterative scan global register allocator + + =back + + =item B<--spiller>=I + + Specify the spiller to use for register allocators that support it. Currently + this option is used only by the linear scan register allocator. The default + I is I. Valid spillers are: + + =over + + =item I + + Simple spiller + + =item I + + Local spiller + + =back + + =back + + =head2 Intel IA-32-specific Options + + =over + + =item B<--x86-asm-syntax=att|intel> + + Specify whether to emit assembly code in AT&T syntax (the default) or intel + syntax. + + =back + + =head2 SPARCV9-specific Options + + =over + + =item B<--disable-peephole> + + Disable peephole optimization pass. + + =item B<--disable-sched> + + Disable local scheduling pass. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error occurs, + it will exit with a non-zero value. + + =head1 SEE ALSO + + L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/lli.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/lli.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/lli.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,76 ---- + =pod + + =head1 NAME + + lli - directly execute programs from LLVM bytecode + + =head1 SYNOPSIS + + B [I] [I] [I] + + =head1 DESCRIPTION + + B directly executes programs in LLVM bytecode 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. B takes all of + the same code generator options as L, but they are only effective when + B is using the just-in-time compiler. + + If I is not specified, then B reads the LLVM bytecode for the + program from standard input. + + The optional I specified on the command line are passed to the program as + arguments. + + =head1 OPTIONS + + =over + + =item B<-help> + + Print a summary of command line options. + + =item B<-stats> + + Print statistics from the code-generation passes. This is only meaningful for + the just-in-time compiler, at present. + + =item B<-time-passes> + + Record the amount of time needed for each code-generation pass and print it to + standard error. + + =item B<-march>=I + + Use the specified non-default architecture arch 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 B on. + + =item B<-force-interpreter>=I<{false,true}> + + If set to true, use the interpreter even if a just-in-time compiler is available + for this architecture. Defaults to false. + + =item B<-f>=I + + Call the function named I to start the program. Note: The + function is assumed to have the C signature C I C<(int, + char **, char **)>. If you try to use this option to call a function of + incompatible type, undefined behavior may result. Defaults to C
. + + =back + + =head1 EXIT STATUS + + If B fails to load the program, it will exit with an exit code of 1. + Otherwise, it will return the exit code of the program it executes. + + =head1 SEE ALSO + + L + + =head1 AUTHOR + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-ar.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-ar.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-ar.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,406 ---- + =pod + + =head1 NAME + + llvm-ar - LLVM archiver + + =head1 SYNOPSIS + + B [-]{dmpqrtx}[Rabfikouz] [relpos] [count] [files...] + + + =head1 DESCRIPTION + + The B command is similar to the common Unix utility, C. It + archives several files together into a single file. The intent for this is + to produce archive libraries by LLVM bytecode that can be linked into an + LLVM program. However, the archive can contain any kind of file. By default, + B generates a symbol table that makes linking faster because + only the symbol table needs to be consulted, not each individual file member + of the archive. + + The B command can be used to I both SVR4 and BSD style archive + files. However, it cannot be used to write them. While the B command + produces files that are I identical to the format used by other C + implementations, it has two significant departures in order to make the + archive appropriate for LLVM. The first departure is that B only + uses BSD4.4 style long path names (stored immediately after the header) and + never contains a string table for long names. The second departure is that the + symbol table is formated for efficient construction of an in-memory data + structure that permits rapid (red-black tree) lookups. Consequently, archives + produced with B usually won't be readable or editable with any + C implementation or useful for linking. Using the C modifier to flatten + file names will make the archive readable by other C implementations + but not for linking because the symbol table format for LLVM is unique. If an + SVR4 or BSD style archive is used with the C (replace) or C (quick + update) operations, the archive will be reconstructed in LLVM format. This + means that the string table will be dropped (in deference to BSD 4.4 long names) + and an LLVM symbol table will be added (by default). The system symbol table + will be retained. + + Here's where B departs from previous C implementations: + + =over + + =item I + + Since B is intended to archive bytecode files, the symbol table + won't make much sense to anything but LLVM. Consequently, the symbol table's + format has been simplified. It consists simply of a sequence of pairs + of a file member index number as an LSB 4byte integer and a null-terminated + string. + + =item I + + Some C implementations (SVR4) use a separate file member to record long + path names (> 15 characters). B takes the BSD 4.4 and Mac OS X + approach which is to simply store the full path name immediately preceding + the data for the file. The path name is null terminated and may contain the + slash (/) character. + + =item I + + B can compress the members of an archive to save space. The + compression used depends on what's available on the platform and what choices + the LLVM Compressor utility makes. It generally favors bzip2 but will select + between "no compression" or bzip2 depending on what makes sense for the + file's content. + + =item I + + Most C implementations do not recurse through directories but simply + ignore directories if they are presented to the program in the F + option. B, however, can recurse through directory structures and + add all the files under a directory, if requested. + + =item I + + When B prints out the verbose table of contents (C option), it + precedes the usual output with a character indicating the basic kind of + content in the file. A blank means the file is a regular file. A 'Z' means + the file is compressed. A 'B' means the file is an LLVM bytecode file. An + 'S' means the file is the symbol table. + + =back + + =head1 OPTIONS + + The options to B are compatible with other C implementations. + However, there are a few modifiers (F) that are not found in other + Cs. The options to B specify a single basic operation to + perform on the archive, a variety of modifiers for that operation, the + name of the archive file, and an optional list of file names. These options + are used to determine how B should process the archive file. + + The Operations and Modifiers are explained in the sections below. The minimal + set of options is at least one operator and the name of the archive. Typically + archive files end with a C<.a> suffix, but this is not required. Following + the F comes a list of F that indicate the specific members + of the archive to operate on. If the F option is not specified, it + generally means either "none" or "all" members, depending on the operation. + + =head2 Operations + + =over + + =item d + + Delete files from the archive. No modifiers are applicable to this operation. + The F options specify which members should be removed from the + archive. It is not an error if a specified file does not appear in the archive. + If no F are specified, the archive is not modified. + + =item m[abi] + + Move files from one location in the archive to another. The F, F, and + F modifiers apply to this operation. The F will all be moved + to the location given by the modifiers. If no modifiers are used, the files + will be moved to the end of the archive. If no F are specified, the + archive is not modified. + + =item p[k] + + Print files to the standard output. The F modifier applies to this + operation. This operation simply prints the F indicated to the + standard output. If no F are specified, the entire archive is printed. + Printing bytecode files is ill-advised as they might confuse your terminal + settings. The F

operation is used. This modifier defeats the default and allows the + bytecode members to be printed. + + =item [N] + + This option is ignored by B but provided for compatibility. + + =item [o] + + When extracting files, this option will cause B to preserve the + original modification times of the files it writes. + + =item [P] + + use full path names when matching + + =item [R] + + This modifier instructions the F option to recursively process directories. + Without F, directories are ignored and only those F that refer to + files will be added to the archive. When F is used, any directories specified + with F will be scanned (recursively) to find files to be added to the + archive. Any file whose name begins with a dot will not be added. + + =item [u] + + When replacing existing files in the archive, only replace those files that have + a time stamp than the time stamp of the member in the archive. + + =item [z] + + When inserting or replacing any file in the archive, compress the file first. + This + modifier is safe to use when (previously) compressed bytecode files are added to + the archive; the compressed bytecode files will not be doubly compressed. + + =back + + =head2 Modifiers (generic) + + The modifiers below may be applied to any operation. + + =over + + =item [c] + + For all operations, B will always create the archive if it doesn't + exist. Normally, B will print a warning message indicating that the + archive is being created. Using this modifier turns off that warning. + + =item [s] + + This modifier requests that an archive index (or symbol table) be added to the + archive. This is the default mode of operation. The symbol table will contain + all the externally visible functions and global variables defined by all the + bytecode files in the archive. Using this modifier is more efficient that using + L which also creates the symbol table. + + =item [S] + + This modifier is the opposite of the F modifier. It instructs B to + not build the symbol table. If both F and F are used, the last modifier to + occur in the options will prevail. + + =item [v] + + This modifier instructs B to be verbose about what it is doing. Each + editing operation taken against the archive will produce a line of output saying + what is being done. + + =back + + =head1 STANDARDS + + The B utility is intended to provide a superset of the IEEE Std 1003.2 + (POSIX.2) functionality for C. B can read both SVR4 and BSD4.4 (or + Mac OS X) archives. If the C modifier is given to the C or C operations + then B will write SVR4 compatible archives. Without this modifier, + B will write BSD4.4 compatible archives that have long names + immediately after the header and indicated using the "#1/ddd" notation for the + name in the header. + + =head1 FILE FORMAT + + The file format for LLVM Archive files is similar to that of BSD 4.4 or Mac OSX + archive files. In fact, except for the symbol table, the C commands on those + operating systems should be able to read LLVM archive files. The details of the + file format follow. + + Each archive begins with the archive magic number which is the eight printable + characters "!\n" where \n represents the newline character (0x0A). + Following the magic number, the file is composed of even length members that + begin with an archive header and end with a \n padding character if necessary + (to make the length even). Each file member is composed of a header (defined + below), an optional newline-terminated "long file name" and the contents of + the file. + + The fields of the header are described in the items below. All fields of the + header contain only ASCII characters, are left justified and are right padded + with space characters. + + =over + + =item name - char[16] + + This field of the header provides the name of the archive member. If the name is + longer than 15 characters or contains a slash (/) character, then this field + contains C<#1/nnn> where C provides the length of the name and the C<#1/> + is literal. In this case, the actual name of the file is provided in the C + bytes immediately following the header. If the name is 15 characters or less, it + is contained directly in this field and terminated with a slash (/) character. + + =item date - char[12] + + This field provides the date of modification of the file in the form of a + decimal encoded number that provides the number of seconds since the epoch + (since 00:00:00 Jan 1, 1970) per Posix specifications. + + =item uid - char[6] + + This field provides the user id of the file encoded as a decimal ASCII string. + This field might not make much sense on non-Unix systems. On Unix, it is the + same value as the st_uid field of the stat structure returned by the stat(2) + operating system call. + + =item gid - char[6] + + This field provides the group id of the file encoded as a decimal ASCII string. + This field might not make much sense on non-Unix systems. On Unix, it is the + same value as the st_gid field of the stat structure returned by the stat(2) + operating system call. + + =item mode - char[8] + + This field provides the access mode of the file encoded as an octal ASCII + string. This field might not make much sense on non-Unix systems. On Unix, it + is the same value as the st_mode field of the stat structure returned by the + stat(2) operating system call. + + =item size - char[10] + + This field provides the size of the file, in bytes, encoded as a decimal ASCII + string. If the size field is negative (starts with a minus sign, 0x02D), then + the archive member is stored in compressed form. The first byte of the archive + member's data indicates the compression type used. A value of 0 (0x30) indicates + that no compression was used. A value of 2 (0x32) indicates that bzip2 + compression was used. + + =item fmag - char[2] + + This field is the archive file member magic number. Its content is always the + two characters back tick (0x60) and newline (0x0A). This provides some measure + utility in identifying archive files that have been corrupted. + + =back + + The LLVM symbol table has the special name "#_LLVM_SYM_TAB_#". It is presumed + that no regular archive member file will want this name. The LLVM symbol table + is simply composed of a sequence of triplets: byte offset, length of symbol, + and the symbol itself. Symbols are not null or newline terminated. Here are + the details on each of these items: + + =over + + =item offset - vbr encoded 32-bit integer + + The offset item provides the offset into the archive file where the bytecode + member is stored that is associated with the symbol. The offset value is 0 + based at the start of the first "normal" file member. To derive the actual + file offset of the member, you must add the number of bytes occupied by the file + signature (8 bytes) and the symbol tables. The value of this item is encoded + using variable bit rate encoding to reduce the size of the symbol table. + Variable bit rate encoding uses the high bit (0x80) of each byte to indicate + if there are more bytes to follow. The remaining 7 bits in each byte carry bits + from the value. The final byte does not have the high bit set. + + =item length - vbr encoded 32-bit integer + + The length item provides the length of the symbol that follows. Like this + I item, the length is variable bit rate encoded. + + =item symbol - character array + + The symbol item provides the text of the symbol that is associated with the + I. The symbol is not terminated by any character. Its length is provided + by the I field. Note that is allowed (but unwise) to use non-printing + characters (even 0x00) in the symbol. This allows for multiple encodings of + symbol names. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. A usage error, results + in an exit code of 1. A hard (file system typically) error results in an + exit code of 2. Miscellaneous or unknown errors result in an + exit code of 3. + + =head1 SEE ALSO + + L, L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-as.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-as.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-as.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,77 ---- + =pod + + =head1 NAME + + llvm-as - LLVM assembler + + =head1 SYNOPSIS + + B [I] [I] + + =head1 DESCRIPTION + + B 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 F is omitted or is C<->, then B reads its input from + standard input. + + If an output file is not specified with the B<-o> option, then + B sends its output to a file or standard output by following + these rules: + + =over + + =item * + + If the input is standard input, then the output is standard output. + + =item * + + If the input is a file that ends with C<.ll>, then the output file is of + the same name, except that the suffix is changed to C<.bc>. + + =item * + + If the input is a file that does not end with the C<.ll> suffix, then the + output file has the same name as the input file, except that the C<.bc> + suffix is appended. + + =back + + =head1 OPTIONS + + =over + + =item B<-f> + + Force overwrite. Normally, B will refuse to overwrite an + output file that already exists. With this option, B + will overwrite the output file and replace it with new bytecode. + + =item B<--help> + + Print a summary of command line options. + + =item B<-o> F + + Specify the output file name. If F is C<->, then B + sends its output to standard output. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + + =head1 SEE ALSO + + L, L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-bcanalyzer.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-bcanalyzer.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-bcanalyzer.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,315 ---- + =pod + + =head1 NAME + + llvm-bcanalyzer - LLVM bytecode analyzer + + =head1 SYNOPSIS + + B [I] [F] + + =head1 DESCRIPTION + + The B command is a small utility for analyzing bytecode files. + The tool reads a bytecode file (such as generated with the B tool) and + produces a statistical report on the contents of the byteocde file. The tool + can also dump a low level but human readable version of the bytecode file. + This tool is probably not of much interest or utility except for those working + directly with the bytecode file format. Most LLVM users can just ignore + this tool. + + If F is omitted or is C<->, then B reads its input + from standard input. This is useful for combining the tool into a pipeline. + Output is written to the standard output. + + =head1 OPTIONS + + =over + + =item B<-nodetails> + + Causes B to abbreviate its output by writing out only a module + level summary. The details for individual functions are not displayed. + + =item B<-dump> + + Causes B to dump the bytecode in a human readable format. This + format is significantly different from LLVM assembly and provides details about + the encoding of the bytecode file. + + =item B<-verify> + + Causes B to verify the module produced by reading the + bytecode. This ensures that the statistics generated are based on a consistent + module. + + =item B<--help> + + Print a summary of command line options. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value, usually 1. + + =head1 SUMMARY OUTPUT DEFINITIONS + + The following items are always printed by llvm-bcanalyzer. They comprize the + summary output. + + =over + + =item B + + This just provides the name of the module for which bytecode analysis is being + generated. + + =item B + + The bytecode version (not LLVM version) of the file read by the analyzer. + + =item B + + The size, in bytes, of the entire bytecode file. + + =item B + + The size, in bytes, of the module block. Percentage is relative to File Size. + + =item B + + The size, in bytes, of all the function blocks. Percentage is relative to File + Size. + + =item B + + The size, in bytes, of the Global Types Pool. Percentage is relative to File + Size. This is the size of the definitions of all types in the bytecode file. + + =item B + + The size, in bytes, of the Constant Pool Blocks Percentage is relative to File + Size. + + =item B + + Ths size, in bytes, of the Global Variable Definitions and their initializers. + Percentage is relative to File Size. + + =item B + + The size, in bytes, of all the instruction lists in all the functions. + Percentage is relative to File Size. Note that this value is also included in + the Function Bytes. + + =item B + + The size, in bytes, of all the compaction tables in all the functions. + Percentage is relative to File Size. Note that this value is also included in + the Function Bytes. + + =item B + + The size, in bytes, of all the symbol tables in all the functions. Percentage is + relative to File Size. Note that this value is also included in the Function + Bytes. + + =item B + + The size, in bytes, of the list of dependent libraries in the module. Percentage + is relative to File Size. Note that this value is also included in the Module + Global Bytes. + + =item B + + The total number of blocks of any kind in the bytecode file. + + =item B + + The total number of function definitions in the bytecode file. + + =item B + + The total number of types defined in the Global Types Pool. + + =item B + + The total number of constants (of any type) defined in the Constant Pool. + + =item B + + The total number of basic blocks defined in all functions in the bytecode file. + + =item B + + The total number of instructions defined in all functions in the bytecode file. + + =item B + + The total number of long instructions defined in all functions in the bytecode + file. Long instructions are those taking greater than 4 bytes. Typically long + instructions are GetElementPtr with several indices, PHI nodes, and calls to + functions with large numbers of arguments. + + =item B + + The total number of operands used in all instructions in the bytecode file. + + =item B + + The total number of compaction tables in all functions in the bytecode file. + + =item B + + The total number of symbol tables in all functions in the bytecode file. + + =item B + + The total number of dependent libraries found in the bytecode file. + + =item B + + The total size of the instructions in all functions in the bytecode file. + + =item B + + The average number of bytes per instruction across all functions in the bytecode + file. This value is computed by dividing Total Instruction Size by Number Of + Instructions. + + =item B + + The maximum value used for a type's slot number. Larger slot number values take + more bytes to encode. + + =item B + + The maximum value used for a value's slot number. Larger slot number values take + more bytes to encode. + + =item B + + The average size of a Value definition (of any type). This is computed by + dividing File Size by the total number of values of any type. + + =item B + + The average size of a global definition (constants and global variables). + + =item B + + The average number of bytes per function definition. This is computed by + dividing Function Bytes by Number Of Functions. + + =item B<# of VBR 32-bit Integers> + + The total number of 32-bit integers encoded using the Variable Bit Rate + encoding scheme. + + =item B<# of VBR 64-bit Integers> + + The total number of 64-bit integers encoded using the Variable Bit Rate encoding + scheme. + + =item B<# of VBR Compressed Bytes> + + The total number of bytes consumed by the 32-bit and 64-bit integers that use + the Variable Bit Rate encoding scheme. + + =item B<# of VBR Expanded Bytes> + + The total number of bytes that would have been consumed by the 32-bit and 64-bit + integers had they not been compressed with the Variable Bit Rage encoding + scheme. + + =item B + + The total number of bytes saved by using the Variable Bit Rate encoding scheme. + The percentage is relative to # of VBR Expanded Bytes. + + =back + + =head1 DETAILED OUTPUT DEFINITIONS + + The following definitions occur only if the -nodetails option was not given. + The detailed output provides additional information on a per-function basis. + + =over + + =item B + + The type signature of the function. + + =item B + + The total number of bytes in the function's block. + + =item B + + The number of basic blocks defined by the function. + + =item B + + The number of instructions defined by the function. + + =item B + + The number of instructions using the long instruction format in the function. + + =item B + + The number of operands used by all instructions in the function. + + =item B + + The number of bytes consumed by instructions in the function. + + =item B + + The average number of bytes consumed by the instructions in the funtion. This + value is computed by dividing Instruction Size by Instructions. + + =item B + + The average number of bytes used by the function per instruction. This value is + computed by dividing Byte Size by Instructions. Note that this is not the same + as Average Instruction Size. It computes a number relative to the total function + size not just the size of the instruction list. + + =item B + + The total number of 32-bit integers found in this function (for any use). + + =item B + + The total number of 64-bit integers found in this function (for any use). + + =item B + + The total number of bytes in this function consumed by the 32-bit and 64-bit + integers that use the Variable Bit Rate encoding scheme. + + =item B + + The total number of bytes in this function that would have been consumed by + the 32-bit and 64-bit integers had they not been compressed with the Variable + Bit Rate encoding scheme. + + =item B + + The total number of bytes saved in this function by using the Variable Bit + Rate encoding scheme. The percentage is relative to # of VBR Expanded Bytes. + + =back + + =head1 SEE ALSO + + L, L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-db.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-db.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-db.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,16 ---- + =pod + + =head1 NAME + + llvm-db - LLVM debugger (alpha) + + =head1 SYNOPSIS + + Details coming soon. Please see + L in the meantime. + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-dis.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-dis.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-dis.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,60 ---- + =pod + + =head1 NAME + + llvm-dis - LLVM disassembler + + =head1 SYNOPSIS + + B [I] [I] + + =head1 DESCRIPTION + + The B command is the LLVM disassembler. It takes an LLVM + bytecode file and converts it into human-readable LLVM assembly language. + + If filename is omitted or specified as C<->, B reads its + input from standard input. + + If the input is being read from standard input, then B + will send its output to standard output by default. Otherwise, the + output will be written to a file named after the input file, with + a C<.ll> suffix added (any existing C<.bc> suffix will first be + removed). You can override the choice of output file using the + B<-o> option. + + =head1 OPTIONS + + =over + + =item B<-f> + + Force overwrite. Normally, B will refuse to overwrite + an output file that already exists. With this option, B + will overwrite the output file. + + =item B<--help> + + Print a summary of command line options. + + =item B<-o> F + + Specify the output file name. If F is -, then the output is sent + to standard output. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + + =head1 SEE ALSO + + L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-extract.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-extract.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-extract.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,63 ---- + =pod + + =head1 NAME + + llvm-extract - extract a function from an LLVM module + + =head1 SYNOPSIS + + B [I] B<--func> I [I] + + =head1 DESCRIPTION + + The B 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, + B will also remove unreachable global variables, prototypes, and + unused types. + + The B command reads its input from standard input if filename is + omitted or if filename is -. The output is always written to standard output, + unless the B<-o> option is specified (see below). + + =head1 OPTIONS + + =over + + =item B<-f> + + Force overwrite. Normally, B will refuse to overwrite an + output file that already exists. With this option, B + will overwrite the output file and replace it with new bytecode. + + =item B<--func> I + + Extract the function named I from the LLVM bytecode. + + =item B<--help> + + Print a summary of command line options. + + =item B<-o> I + + Specify the output filename. If filename is "-" (the default), then + B sends its output to standard output. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + + =head1 SEE ALSO + + L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-ld.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-ld.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-ld.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,171 ---- + =pod + + =head1 NAME + + llvm-ld - LLVM linker + + =head1 SYNOPSIS + + B + + =head1 DESCRIPTION + + The B command is similar to the common Unix utility, C. It + links together bytecode modules to produce an executable program. + + =head1 OPTIONS + + =head2 Input/Output Options + + =over + + =item B<-o> F + + This overrides the default output file and specifies the name of the file that + should be generated by the linker. By default, B generates a file named + F for compatibility with B. The output will be written to + F. + + =item B<-l>F + + This option specifies the F of a library to search when resolving symbols + for the program. Only the base name should be specified as F, without a + F prefix or any suffix. + + =item B<-L>F + + This option tells B to look in F to find any library subsequently + specified with the B<-l> option. The paths will be searched in the order in + which they are specified on the command line. If the library is still not found, + a small set of system specific directories will also be searched. Note that + libraries specified with the B<-l> option that occur I any B<-L> options + will not search the paths given by the B<-L> options following it. + + =item B<-link-as-library> + + Link the bytecode files together as a library, not an executable. In this mode, + undefined symbols will be permitted. + + =item B<-r> + + An alias for -link-as-library. + + =item B<-march=>C + + Specifies the kind of machine for which code or assembly should be generated. + + =item B<-native> + + Generate a native binary instead of a shell script that runs the JIT from + bytecode. + + =item B<-native-cbe> + + Generate a native binary with the C back end and compilation with GCC. + + =item B<-disable-compression> + + Do not compress bytecode files. + + =back + + =head2 Optimization Options + + =over + + =item B<-O0> + + An alias for the -O1 option. + + =item B<-O1> + + Optimize for linking speed, not execution speed. The optimizer will attempt to + reduce the size of the linked program to reduce I/O but will not otherwise + perform any link-time optimizations. + + =item B<-O2> + + Perform only the minimal or required set of scalar optimizations. + + =item B<-03> + + An alias for the -O2 option. + + =item B<-04> + + Perform the standard link time inter-procedural optimizations. This will + attempt to optimize the program taking the entire program into consideration. + + =item B<-O5> + + Perform aggressive link time optimizations. This is the same as -O4 but works + more aggressively to optimize the program. + + =item B<-disable-inlining> + + Do not run the inlining pass. Functions will not be inlined into other + functions. + + =item B<-disable-opt> + + Completely disable optimization. The various B<-On> options will be ignored and + no link time optimization passes will be run. + + =item B<-disable-internalize> + + Do not mark all symbols as internal. + + =item B<-verify> + + Run the verification pass after each of the passes to verify intermediate + results. + + =item B<-s> + + Strip symbol info from the executable to make it smaller. + + =item B<-export-dynamic> + + An alias for -disable-internalize + + =item B<-load> F + + Load an optimization module, F, which is expected to be a dynamic + library that provides the function name C. This function will + be passed the PassManager, and the optimization level (values 0-5 based on the + B<-On> option). This function may add passes to the PassManager that should be + run. This feature allows the optimization passes of B to be extended. + + =back + + =head2 Miscellaneous Options + + =over + + =item B<-v> + + Specifies verbose mode. In this mode the linker will print additional + information about the actions it takes, programs it executes, etc. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0 return code. If an error occurs, + it will exit with a non-zero return code. + + =head1 ENVIRONMENT + + The C environment variable is used to find bytecode + libraries. Any paths specified in this variable will be searched after the C<-L> + options. + + =head1 SEE ALSO + + L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-link.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-link.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-link.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,74 ---- + =pod + + =head1 NAME + + llvm-link - LLVM linker + + =head1 SYNOPSIS + + B [I] I + + =head1 DESCRIPTION + + B 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 B<-o> option is used to specify a filename. + + B attempts to load the input files from the current directory. If + that fails, it looks for each file in each of the directories specified by the + B<-L> options on the command line. The library search paths are global; each + one is searched for every input file if necessary. The directories are searched + in the order they were specified on the command line. + + =head1 OPTIONS + + =over + + =item B<-L> F + + Add the specified F to the library search path. When looking for + libraries, B will look in pathname for libraries. This option can be + specified multiple times; B will search inside these directories in + the order in which they were specified on the command line. + + =item B<-f> + + Overwrite output files. By default, B will not overwrite an output + file if it alreadys exists. + + =item B<-o> F + + Specify the output file name. If F is C<->, then B will + write its output to standard output. + + =item B<-d> + + If specified, B prints a human-readable version of the output + bytecode file to standard error. + + =item B<--help> + + Print a summary of command line options. + + =item B<-v> + + Verbose mode. Print information about what B is doing. This + typically includes a message for each bytecode file linked in and for each + library found. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + + =head1 SEE ALSO + + L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-nm.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-nm.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-nm.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,122 ---- + =pod + + =head1 NAME + + llvm-nm - list LLVM bytecode file's symbol table + + =head1 SYNOPSIS + + B [I] [I] + + =head1 DESCRIPTION + + The B utility lists the names of symbols from the LLVM bytecode files, + or B 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 I<-> is used as a filename, B will + process a bytecode file on its standard input stream. + + B's default output format is the traditional BSD B output format. + Each such output record consists of an (optional) 8-digit hexadecimal address, + followed by a type code character, followed by a name, for each symbol. One + record is printed per line; fields are separated by spaces. When the address is + omitted, it is replaced by 8 spaces. + + Type code characters currently supported, and their meanings, are as follows: + + =over + + =item U + + Named object is referenced but undefined in this bytecode file + + =item C + + Common (multiple defs link together into one def) + + =item W + + Weak reference (multiple defs link together into zero or one defs) + + =item t + + Local function (text) object + + =item T + + Global function (text) object + + =item d + + Local data object + + =item D + + Global data object + + =item ? + + Something unrecognizable + + =back + + Because LLVM 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", B does not print an address for any symbol, + even symbols which are defined in the bytecode file. + + =head1 OPTIONS + + =over + + =item B<-P> + + Use POSIX.2 output format. Alias for B<--format=posix>. + + =item B<-B> (default) + + Use BSD output format. Alias for B<--format=bsd>. + + =item B<--help> + + Print a summary of command-line options and their meanings. + + =item B<--defined-only> + + Print only symbols defined in this bytecode file (as opposed to + symbols which may be referenced by objects in this file, but not + defined in this file.) + + =item B<--extern-only>, B<-g> + + Print only symbols whose definitions are external; that is, accessible + from other bytecode files. + + =item B<--undefined-only>, B<-u> + + Print only symbols referenced but not defined in this bytecode file. + + =item B<--format=>I, B<-f> + + Select an output format; I may be I, I, or I. The + default is I. + + =back + + =head1 BUGS + + B cannot demangle C++ mangled names, like GNU B can. + + =head1 EXIT STATUS + + B exits with an exit code of zero. + + =head1 SEE ALSO + + L, L, L + + =head1 AUTHOR + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-prof.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-prof.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-prof.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,57 ---- + =pod + + =head1 NAME + + llvm-prof - print execution profile of LLVM program + + =head1 SYNOPSIS + + B [I] [I] [I] + + =head1 DESCRIPTION + + The B tool reads in an F 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 F + script. This script automatically instruments a program, runs it with the JIT, + then runs B to format a report. To get more information about + F, execute it with the B<--help> option. + + =head1 OPTIONS + + =over + + =item B<--annotated-llvm> or B<-A> + + In addition to the normal report printed, print out the code for the + program, annotated with execution frequency information. This can be + particularly useful when trying to visualize how frequently basic blocks + are executed. This is most useful with basic block profiling + information or better. + + =item B<--print-all-code> + + Using this option enables the B<--annotated-llvm> option, but it + prints the entire module, instead of just the most commonly executed + functions. + + =item B<--time-passes> + + Record the amount of time needed for each pass and print it to standard + error. + + =back + + =head1 EXIT STATUS + + B returns 1 if it cannot load the bytecode file or the profile + information. Otherwise, it exits with zero. + + =head1 AUTHOR + + B is maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvm-ranlib.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvm-ranlib.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvm-ranlib.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,52 ---- + =pod + + =head1 NAME + + llvm-ranlib - Generate index for LLVM archive + + =head1 SYNOPSIS + + B [--version] [--help] + + =head1 DESCRIPTION + + The B command is similar to the common Unix utility, C. It + adds or updates the symbol table in an LLVM archive file. Note that using the + B modifier F is usually more efficient than running B + which is only provided only for completness and compatibility. Unlike other + implementations of C, B indexes LLVM bytecode files, not + native object modules. You can list the contents of the symbol table with the + C command. + + =head1 OPTIONS + + =over + + =item F + + Specifies the archive-file to which the symbol table is added or updated. + + =item F<--version> + + Print the version of B and exit without building a symbol table. + + =item F<--help> + + Print usage help for B and exit without building a symbol table. + + =back + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. If an error occurs, a non-zero + exit code will be returned. + + =head1 SEE ALSO + + L, ranlib(1) + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvmc.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvmc.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvmc.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,405 ---- + =pod + + =head1 NAME + + llvmc - The LLVM Compiler Driver + + =head1 SYNOPSIS + + B [I] [I...] + + =head1 DESCRIPTION + + B is a configurable driver for invoking other LLVM (and non-LLVM) tools + in order to compile, optimize and link software for multiple languages. For + those familiar with FSF's B tool, it is very similar. B has the + following goals: + + =over + + =item * provide a single point of access to the LLVM tool set, + + =item * hide the complexities of the LLVM tools through a single interface, + + =item * make integration of existing non-LLVM tools simple, + + =item * extend the capabilities of minimal front ends, and + + =item * make the interface for compiling consistent for all languages. + + =back + + The tool itself does nothing with a user's program. It merely invokes other + tools to get the compilation tasks done. + + The options supported by B generalize the compilation process and + provide a consistent and simple interface for multiple programming languages. + This makes it easier for developers to get their software compiled with LLVM. + Without B, developers would need to understand how to invoke the + front-end compiler, optimizer, assembler, and linker in order to compile their + programs. B's sole mission is to trivialize that process. + + =head2 Basic Operation + + B always takes the following basic actions: + + =over + + =item * Command line options and filenames are collected. + + The command line options provide the marching orders to B on what actions + it should perform. This is the I the user is making of B and it + is interpreted first. + + =item * Configuration files are read. + + Based on the options and the suffixes of the filenames presented, a set of + configuration files are read to configure the actions B will take. + Configuration files are provided by either LLVM or the front end compiler tools + that B invokes. Users generally don't need to be concerned with the + contents of the configuration files. + + =item * Determine actions to take. + + The tool chain needed to complete the task is determined. This is the primary + work of B. It breaks the request specified by the command line options + into a set of basic actions to be done: + + =over + + =item * Pre-processing: gathering/filtering compiler input (optional). + + =item * Translation: source language to bytecode conversion. + + =item * Assembly: bytecode to native code conversion. + + =item * Optimization: conversion of bytecode to something that runs faster. + + =item * Linking: combining multiple bytecodes to produce executable program. + + =back + + =item * Execute actions. + + The actions determined previously are executed sequentially and then + B terminates. + + =back + + =head1 OPTIONS + + =head2 Control Options + + Control options tell B what to do at a high level. The + following control options are defined: + + =over + + =item B<-c> or B<--compile> + + This option specifies that the linking phase is not to be run. All + previous phases, if applicable will run. This is generally how a given + bytecode file is compiled and optimized for a source language module. + + =item B<-k> or B<--link> or default + + This option (or the lack of any control option) specifies that all stages + of compilation, optimization, and linking should be attempted. Source files + specified on the command line will be compiled and linked with objects and + libraries also specified. + + =item B<-S> + + This option specifies that compilation should end in the creation of + an LLVM assembly file that can be later converted to an LLVM object + file. + + =item B<-E> + + This option specifies that no compilation or linking should be + performed. Only pre-processing, if applicable to the language being + compiled, is performed. For languages that support it, this will + result in the output containing the raw input to the compiler. + + =back + + =head2 Optimization Options + + Optimization with B is based on goals and specified with + the following -O options. The specific details of which + optimizations run is controlled by the configuration files because + each source language will have different needs. + + =over + + =item B<-O1> or B<-O0> (default, fast compilation) + + Only those optimizations that will hasten the compilation (mostly by reducing + the output) are applied. In general these are extremely fast and simple + optimizations that reduce emitted code size. The goal here is not to make the + resulting program fast but to make the compilation fast. If not specified, + this is the default level of optimization. + + =item B<-O2> (basic optimization) + + This level of optimization specifies a balance between generating good code + that will execute reasonably quickly and not spending too much time optimizing + the code to get there. For example, this level of optimization may include + things like global common subexpression elimination, aggressive dead code + elimination, and scalar replication. + + =item B<-O3> (aggressive optimization) + + This level of optimization aggressively optimizes each set of files compiled + together. However, no link-time inter-procedural optimization is performed. + This level implies all the optimizations of the B<-O1> and B<-O2> optimization + levels, and should also provide loop optimizations and compile time + inter-procedural optimizations. Essentially, this level tries to do as much + as it can with the input it is given but doesn't do any link time IPO. + + =item B<-O4> (link time optimization) + + In addition to the previous three levels of optimization, this level of + optimization aggressively optimizes each program at link time. It employs + basic analysis and basic link-time inter-procedural optimizations, + considering the program as a whole. + + =item B<-O5> (aggressive link time optimization) + + This is the same as B<-O4> except it employs aggressive analyses and + aggressive inter-procedural optimization. + + =item B<-O6> (profile guided optimization: not implemented) + + This is the same as B<-O5> except that it employs profile-guided + re-optimization of the program after it has executed. Note that this implies + a single level of re-optimization based on runtime profile analysis. Once + the re-optimization has completed, the profiling instrumentation is + removed and final optimizations are employed. + + =item B<-O7> (lifelong optimization: not implemented) + + This is the same as B<-O5> and similar to B<-O6> except that re-optimization + is performed through the life of the program. That is, each run will update + the profile by which future re-optimizations are directed. + + =back + + =head2 Input Options + + =over + + =item B<-l> I + + This option instructs B to locate a library named I and search + it for unresolved symbols when linking the program. + + =item B<-L> F + + This option instructs B to add F to the list of places in which + the linker will + + =item B<-x> I + + This option instructs B to regard the following input files as + containing programs in the language I. Normally, input file languages + are identified by their suffix but this option will override that default + behavior. The B<-x> option stays in effect until the end of the options or + a new B<-x> option is encountered. + + =back + + =head2 Output Options + + =over + + =item B<-m>I + + This option selects the back end code generator to use. The I portion + of the option names the back end to use. + + =item B<--native> + + Normally, B produces bytecode files at most stages of compilation. + With this option, B will arrange for native object files to be + generated with the B<-c> option, native assembly files to be generated + with the B<-S> option, and native executables to be generated with the + B<--link> option. In the case of the B<-E> option, the output will not + differ as there is no I version of pre-processed output. + + =item B<-o> F + + Specify the output file name. The contents of the file depend on other + options. + + =back + + =head2 Information Options + + =over + + =item B<-n> or B<--no-op> + + This option tells B to do everything but actually execute the + resulting tools. In combination with the B<-v> option, this causes B + to merely print out what it would have done. + + =item B<-v> or B<--verbose> + + This option will cause B to print out (on standard output) each of the + actions it takes to accomplish the objective. The output will immediately + precede the invocation of other tools. + + =item B<--stats> + + Print all statistics gathered during the compilation to the standard error. + Note that this option is merely passed through to the sub-tools to do with + as they please. + + =item B<--time-passes> + + Record the amount of time needed for each optimization pass and print it + to standard error. Like B<--stats> this option is just passed through to + the sub-tools to do with as they please. + + =item B<--time-programs> + + Record the amount of time each program (compilation tool) takes and print + it to the standard error. + + =back + + =head2 Language Specific Options + + =over + + =item B<-T,pre>=I + + Pass an arbitrary option to the pre-processor. + + =item B<-T,opt>=I + + Pass an arbitrary option to the optimizer. + + =item B<-T,lnk>=I + + Pass an arbitrary option to the linker. + + =item B<-T,asm>=I + + Pass an arbitrary option to the code generator. + + =back + + =head2 C/C++ Specific Options + + =over + + =item B<-I>F + + This option is just passed through to a C or C++ front end compiler to tell it + where include files can be found. + + =item B<-D>F + + This option is just passed through to a C or C++ front end compiler to tell it + to define a symbol. + + =back + + =head2 Miscellaneous Options + + =over + + =item B<--help> + + Print a summary of command line options. + + =item B<--version> + + This option will cause B to print out its version number and terminate. + + =back + + =head2 Advanced Options + + You better know what you're doing if you use these options. Improper use + of these options can produce drastically wrong results. + + =over + + =item B<--config-dir> F + + This option tells B to read configuration data from the I + named F. Data from such directories will be read in the order + specified on the command line after all other standard configuration files have + been read. This allows users or groups of users to conveniently create + their own configuration directories in addition to the standard ones to which + they may not have write access. + + + =head2 Unimplemented Options + + The options below are not currently implemented in B but will be + eventually. They are documented here as "future design". + + =over + + =item B<--show-config> I<[suffixes...]> + + When this option is given, the only action taken by B is to show its + final configuration state in the form of a configuration file. No compilation + tasks will be conducted when this option is given; processing will stop once + the configuration has been printed. The optional (comma separated) list of + suffixes controls what is printed. Without any suffixes, the configuration + for all languages is printed. With suffixes, only the languages pertaining + to those file suffixes will be printed. The configuration information is + printed after all command line options and configuration files have been + read and processed. This allows the user to verify that the correct + configuration data has been read by B. + + =item B<--config> :I

:I=I + + This option instructs B to accept I as the value for configuration + item I in the section named I
. This is a quick way to override + a configuration item on the command line without resorting to changing the + configuration files. + + =item B<--config-only-from> F + + This option tells B to skip the normal processing of configuration + files and only configure from the contents of the F directory. Multiple + B<--config-only-from> options may be given in which case the directories are + read in the order given on the command line. + + =item B<--emit-raw-code> + + No optimization is done whatsoever. The compilers invoked by B with + this option given will be instructed to produce raw, unoptimized code. This + option is useful only to front end language developers and therefore does not + participate in the list of B<-O> options. This is distinctly different from + the B<-O0> option (a synonym for B<-O1>) because those optimizations will + reduce code size to make compilation faster. With B<--emit-raw-code>, only + the full raw code produced by the compiler will be generated. + + =back + + + =head1 EXIT STATUS + + If B succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value and no compilation actions + will be taken. If one of the compilation tools returns a non-zero + status, pending actions will be discarded and B will return the + same result code as the failing compilation tool. + + =head1 SEE ALSO + + L, L, L, L, + L, L + + =head1 AUTHORS + + Maintained by the LLVM Team (L). + + =cut Index: llvm-www/releases/1.6/docs/CommandGuide/llvmgcc.pod diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/llvmgcc.pod:1.1 *** /dev/null Tue Nov 8 14:06:50 2005 --- llvm-www/releases/1.6/docs/CommandGuide/llvmgcc.pod Tue Nov 8 14:06:38 2005 *************** *** 0 **** --- 1,95 ---- + =pod + + =head1 NAME + + llvm-gcc - LLVM C front-end + + =head1 SYNOPSIS + + B [I] I + + =head1 DESCRIPTION + + The B command is the LLVM C front end. It is a modified + version of gcc that takes C programs and compiles them into LLVM + bytecode or assembly language, depending upon the options. + + Unless the B<-S> option is specified, B will use the + L program to perform some optimizations and create an + LLVM bytecode file. Unless the B<-c> option is specified, B + will also use the L 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, B 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. + + =head1 OPTIONS + + =over + + =item B<--help> + + Print a summary of command line options. + + =item B<-S> + + Do not generate an LLVM bytecode file. Rather, compile the source + file into an LLVM assembly language file. + + =item B<-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. + + =item B<-o> I + + Specify the output file to be I. + + =item B<-I> I + + Add a directory to the header file search path. This option can be + repeated. + + =item B<-L> I + + Add I to the library search path. This option can be + repeated. + + =item B<-l>I + + Link in the library libI.[bc | a | so]. This library should + be a bytecode library. + + =item B<-Wa,>I + + + + +

+


+

NAME

+

analyze - LLVM program analyzer

+

+


+

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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/bugpoint.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/bugpoint.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/bugpoint.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,263 ---- + + + bugpoint - automatic test case reduction tool + + + + + + + + + + + +

+


+

NAME

+

bugpoint - automatic test case reduction tool

+

+


+

SYNOPSIS

+

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

+

+


+

DESCRIPTION

+

bugpoint narrows down the source of problems in LLVM tools and passes. It + can be used to debug three types of failures: optimizer crashes, miscompilations + by optimizers, or bad native code generation (including problems in the static + and JIT compilers). It aims to reduce large test cases to small, useful ones. + For example, if 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 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. Note + that bugpoint is generally very quick unless debugging a miscompilation where + each test of the program (which requires executing it) takes a long time.

+

+

Automatic Debugger Selection

+

bugpoint reads each .bc or .ll file specified on the command line and + links them together into a single module, called the test program. If any LLVM + passes are specified on the command line, it runs these passes on the test + program. If any of the passes crash, or if they produce malformed output (which + causes the verifier to abort), 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 38 passes.

+

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 compiler (llc). 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.

+

+

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:

+
    +
  • + In the code generator and miscompilation debuggers, bugpoint only + works with programs that have deterministic output. Thus, if the program + outputs argv[0], 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. +

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

    +
  • + 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, make bugpoint dynamically load + your optimization by using the -load option. +

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

    +

    +
  • + bugpoint cannot debug problems with the LLVM linker. If bugpoint crashes + before you see its All input ok message, you might try running llvm-link + -v on the same set of input files. If that also crashes, you may be + experiencing a linker bug. +

    +
  • + 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

+
+
--additional-so library
+
+ Load the dynamic shared object library into the test program whenever it is + run. This is useful if you are debugging programs which depend on non-LLVM + libraries (such as the X or curses libraries) to run. +

+
--args program args
+
+ Pass all arguments specified after -args to the test program whenever it runs. + Note that if any of the program args start with a '-', you should use: +
+     bugpoint [bugpoint args] --args -- [program args]
+

The ``--'' right after the --args option tells bugpoint to consider any + options starting with - to be part of the --args option, not as options to + bugpoint itself.

+

+
--tool-args tool args
+
+ Pass all arguments specified after --tool-args to the LLVM tool under test + (llc, lli, etc.) whenever it runs. You should use this option in the + following way: +
+     bugpoint [bugpoint args] --tool-args -- [tool args]
+

The ``--'' right after the --tool-args option tells bugpoint to consider any + options starting with - to be part of the --tool-args option, not as + options to bugpoint itself. (See --args, above.)

+

+
--check-exit-code={true,false}
+
+ Assume a non-zero exit code or core dump from the test program is a failure. + Defaults to true. +

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

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

+
--input filename
+
+ Open filename and redirect the standard input of the test program, whenever + it runs, to come from that file. +

+
--load plugin
+
+ Load the dynamic object plugin into bugpoint itself. This object should + register new optimization passes. Once loaded, the object will add new command + line options to enable various optimizations. To see the new complete list of + optimizations, use the --help and --load options together; for example: +
+     bugpoint --load myNewPass.so --help
+

+
--output filename
+
+ Whenever the test program produces output on its standard output stream, it + should match the contents of filename (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. +

+
--profile-info-file filename
+
+ Profile file loaded by --profile-loader. +

+
--run-{int,jit,llc,cbe}
+
+ Whenever the test program is compiled, bugpoint should generate code for it + using the specified code generator. These options allow you to choose the + interpreter, the JIT compiler, the static native code compiler, or the C + backend, respectively. +

+

+


+

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

+

+


+

AUTHOR

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/extract.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/extract.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/extract.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,95 ---- + + + extract - extract a function from an LLVM module + + + + + + + + + + + +

+


+

NAME

+

extract - extract a function from an LLVM module

+

+


+

SYNOPSIS

+

extract [options] --func function-name [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, + unless the -o option is specified (see below).

+

+


+

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-name
+
+ Extract the function named function-name 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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/gccas.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/gccas.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/gccas.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,100 ---- + + + gccas - optimizing LLVM assembler + + + + + + + + + + + +

+


+

NAME

+

gccas - optimizing LLVM assembler

+

+


+

SYNOPSIS

+

gccas [options] filename

+

+


+

DESCRIPTION

+

The gccas utility takes an LLVM assembly file generated by the + llvmgcc or llvmg++ front-ends 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, + including but not limited to: promotion of stack values to SSA + registers; elimination of dead globals, function arguments, code, + and types; tail-call elimination; loop-invariant code motion; global + common-subexpression elimination; and sparse conditional constant + propagation.

+

+


+

OPTIONS

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

+
-o filename
+
+ Specify the name of the output file which will hold the assembled bytecode. +

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

+
--disable-opt
+
+ Disable all assembler-time optimization passes. +

+
--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 an exit status of 0. + Otherwise, if an error occurs, it will exit with a non-zero exit + status.

+

+


+

SEE ALSO

+

llvm-as, gccld

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/gccld.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/gccld.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/gccld.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,199 ---- + + + gccld - optimizing LLVM linker + + + + + + + + + + + +

+


+

NAME

+

gccld - optimizing LLVM linker

+

+


+

SYNOPSIS

+

gccld [options] 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 the llvmgcc manpage and + llvmg++ 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 liblibrary.bc, liblibrary.a, or liblibrary.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 may be .so, .dyld, .dll, or something + different, 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 or -native-cbe options.

+

+


+

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

+
-Ldirectory
+
+ 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 &lt;list&gt;
+
+ Preserve the symbol names in list. +

+
-llibrary
+
+ 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 liblibrary.bc, liblibrary.a, and + liblibrary.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.

+

+
-native-cbe
+
+ Generate a native machine code executable with the LLVM C backend. + +
+ 
+ This option is identical to the B<-native> option, but uses the
+ C backend to generate code for the program instead of an LLVM native
+ code generator.
+

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

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

+

+


+

EXIT STATUS

+

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

+

+


+

SEE ALSO

+

llvm-link, gccas

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llc.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llc.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llc.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,204 ---- + + + llc - LLVM static compiler + + + + + + + + + + + +

+


+

NAME

+

llc - LLVM static compiler

+

+


+

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, by attempting to satisfy each of the following rules in turn (first + one wins):

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

    +
  • + Examine the input LLVM bytecode file: if it is little endian and has a + pointer size of 32 bits, select the Intel IA-32 architecture. If it is big + endian and has a pointer size of 64 bits, 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. +

    +
  • + Exit with an error message telling the user to specify the output + architecture explicitly. +

+

+


+

OPTIONS

+

If filename is - or omitted, llc reads LLVM bytecode from standard input. + Otherwise, it will read LLVM bytecode from filename.

+

If the -o option is omitted, 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 by taking the input filename, + removing any existing .bc extension, and adding a .s suffix.

+

Other llc options are as follows:

+
+
-f
+
+ Overwrite output files. By default, llc will refuse to overwrite + an output file which already exists. +

+
-march=arch
+
+ Specify the architecture for which to generate assembly. Valid + architectures are: +
+
x86
+
+ Intel IA-32 (Pentium and above) +

+
sparcv9
+
+ 64-bit SPARC V9 +

+
c
+
+ Emit C code, not assembly +

+
-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 recorded by code-generation passes. +

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

+

+

Intel IA-32-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=allocator
+
+ Specify the register allocator to use. The default allocator is local. + Valid register allocators are: +
+
simple
+
+ Very simple ``always spill'' register allocator +

+
local
+
+ Local register allocator +

+
linearscan
+
+ Linear scan global register allocator (experimental) +

+
--spiller=spiller
+
+ Specify the spiller to use for register allocators that support it. Currently + this option is used only by the linear scan register allocator. The default + spiller is local. Valid spillers are: +
+
simple
+
+ Simple spiller +

+
local
+
+ Local spiller +

+
+

+

SPARCV9-specific Options

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

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

+
--disable-strip
+
+ The Sparc backend embeds the LLVM bytecode into the assembly output. This + option requests that symbol names be retained; by default, they are stripped out. +

+
--enable-maps
+
+ Emit LLVM-to-machine code mapping information into the assembly output. +

+

+


+

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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/lli.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/lli.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/lli.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,99 ---- + + + lli - directly execute programs from LLVM bytecode + + + + + + + + + + + +

+


+

NAME

+

lli - directly execute programs from LLVM bytecode

+

+


+

SYNOPSIS

+

lli [options] [filename] [program args]

+

+


+

DESCRIPTION

+

lli directly executes programs in LLVM bytecode 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 llc, but they are only effective when + lli is using the just-in-time compiler.

+

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 arch 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

+

+


+

AUTHOR

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-as.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-as.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-as.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,103 ---- + + + llvm-as - LLVM assembler + + + + + + + + + + + +

+


+

NAME

+

llvm-as - LLVM assembler

+

+


+

SYNOPSIS

+

llvm-as [options] [filename]

+

+


+

DESCRIPTION

+

The llvm-as command invokes 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 following + these rules:

+
    +
  • + 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 file name. 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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-bcanalyzer.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-bcanalyzer.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-bcanalyzer.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,89 ---- + + + llvm-bcanalyzer - LLVM bytecode analyzer + + + + + + + + + + + +

+


+

NAME

+

llvm-bcanalyzer - LLVM bytecode analyzer

+

+


+

SYNOPSIS

+

llvm-bcanalyzer [options] [filename]

+

+


+

DESCRIPTION

+

The llvm-bcanalyzer command is a small utility for analyzing bytecode files. + The tool reads a bytecode file (such as generated with the llvm-as tool) and + produces a statistical report on the contents of the byteocde file. The tool + will also dump a low level but human readable version of the bytecode file. + This tool is probably not of much interest or utility except for those working + directly with the bytecode file format. Most LLVM users can just ignore + this tool.

+

If filename is omitted or is -, then llvm-bcanalyzer reads its input + from standard input. This is useful for combining the tool into a pipeline.

+

Output is written to the standard output.

+

+


+

OPTIONS

+
+
-nodetails
+
+ Causes llvm-bcanalyzer to abbreviate its output by writing out only a module + level summary. The details for individual functions are not displayed. +

+
-dump
+
+ Causes llvm-bcanalyzer to dump the bytecode in a human readable format. This + format is significantly different from LLVM assembly and provides details about + the encoding of the bytecode file. +

+
-verify
+
+ Causes llvm-bcanalyzer to verify the module produced by by reading the + bytecode. This ensures that the statistics generated are based on a consistent + module. +

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

+

+


+

EXIT STATUS

+

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

+

+


+

SEE ALSO

+

llvm-dis, http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-db.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-db.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-db.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,39 ---- + + + llvm-db - LLVM debugger + + + + + + + + + + + +

+


+

NAME

+

llvm-db - LLVM debugger (alpha)

+

+


+

SYNOPSIS

+

Details coming soon. Please see + http://llvm.cs.uiuc.edu/docs/SourceLevelDebugging.html in the meantime.

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-dis.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-dis.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-dis.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,88 ---- + + + llvm-dis - LLVM disassembler + + + + + + + + + + + +

+


+

NAME

+

llvm-dis - LLVM disassembler

+

+


+

SYNOPSIS

+

llvm-dis [options] [filename]

+

+


+

DESCRIPTION

+

The llvm-dis command is the LLVM disassembler. It takes an LLVM + bytecode file and converts it into human-readable LLVM assembly language.

+

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

+

If the input is being read from standard input, then llvm-dis + will send its output to standard output by default. Otherwise, the + output will be written to a file named after the input file, with + a .ll suffix added (any existing .bc suffix will first be + removed). You can override the choice of output file using the + -o option.

+

+


+

OPTIONS

+
+
-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 file name. 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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-link.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-link.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-link.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,98 ---- + + + llvm-link - LLVM linker + + + + + + + + + + + +

+


+

NAME

+

llvm-link - LLVM linker

+

+


+

SYNOPSIS

+

llvm-link [options] 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
+
+ Specify the output file name. 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

+

the gccld manpage

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-nm.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-nm.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-nm.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,142 ---- + + + llvm-nm - list LLVM bytecode file's symbol table + + + + + + + + + + + +

+


+

NAME

+

llvm-nm - list LLVM bytecode file's symbol table

+

+


+

SYNOPSIS

+

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

+

+


+

DESCRIPTION

+

The llvm-nm utility lists the names of symbols from the LLVM bytecode files, + or ar 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 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:

+
+
U
+
+ Named object is referenced but undefined in this bytecode file +

+
C
+
+ Common (multiple defs link together into one def) +

+
W
+
+ Weak reference (multiple defs link together into zero or one defs) +

+
t
+
+ Local function (text) object +

+
T
+
+ Global function (text) object +

+
d
+
+ Local data object +

+
D
+
+ Global 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 can.

+

+


+

EXIT STATUS

+

llvm-nm exits with an exit code of zero.

+

+


+

SEE ALSO

+

llvm-dis, ar(1), nm(1)

+

+


+

AUTHOR

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvm-prof.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvm-prof.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvm-prof.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,80 ---- + + + llvm-prof - print execution profile of LLVM program + + + + + + + + + + + +

+


+

NAME

+

llvm-prof - print execution profile of LLVM program

+

+


+

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|llvm-prof returns 1 if it cannot load the bytecode file or the + profile information. Otherwise, it exits with zero.

+

+


+

AUTHOR

+

llvm-prof is maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvmgcc.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvmgcc.html:1.1 *** /dev/null Tue Nov 8 14:07:52 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvmgcc.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,109 ---- + + + llvmgcc - LLVM C front-end + + + + + + + + + + + +

+


+

NAME

+

llvmgcc - LLVM C front-end

+

+


+

SYNOPSIS

+

llvmgcc [options] filename

+

+


+

DESCRIPTION

+

The llvmgcc command is the LLVM C front end. It is a modified + version of 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 the GNU Compiler Collection, 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.

+

+


+

OPTIONS

+
+
--help
+
+ Print a summary of command line 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 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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/llvmgxx.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/llvmgxx.html:1.1 *** /dev/null Tue Nov 8 14:07:53 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/llvmgxx.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,109 ---- + + + llvmg++ - LLVM C++ front-end + + + + + + + + + + + +

+


+

NAME

+

llvmg++ - LLVM C++ front-end

+

+


+

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.

+

+


+

OPTIONS

+
+
--help
+
+ Print a summary of command line 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

+

the llvmgcc manpage, the gccas manpage, the gccld manpage

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/manpage.css diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/manpage.css:1.1 *** /dev/null Tue Nov 8 14:07:53 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/manpage.css Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,256 ---- + /* Based on http://www.perldoc.com/css/perldoc.css */ + + @import url("../llvm.css"); + + body { font-family: Arial,Helvetica; } + + blockquote { margin: 10pt; } + + h1, a { color: #336699; } + + + /*** Top menu style ****/ + .mmenuon { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #ff6600; font-size: 10pt; + } + .mmenuoff { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #ffffff; font-size: 10pt; + } + .cpyright { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #ffffff; font-size: xx-small; + } + .cpyrightText { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #ffffff; font-size: xx-small; + } + .sections { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: 11pt; + } + .dsections { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: 12pt; + } + .slink { + font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; + color: #000000; font-size: 9pt; + } + + .slink2 { font-family: Arial,Helvetica; text-decoration: none; color: #336699; } + + .maintitle { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: 18pt; + } + .dblArrow { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: small; + } + .menuSec { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: small; + } + + .newstext { + font-family: Arial,Helvetica; font-size: small; + } + + .linkmenu { + font-family: Arial,Helvetica; color: #000000; font-weight: bold; + text-decoration: none; + } + + P { + font-family: Arial,Helvetica; + } + + PRE { + font-size: 10pt; + } + .quote { + font-family: Times; text-decoration: none; + color: #000000; font-size: 9pt; font-style: italic; + } + .smstd { font-family: Arial,Helvetica; color: #000000; font-size: x-small; } + .std { font-family: Arial,Helvetica; color: #000000; } + .meerkatTitle { + font-family: sans-serif; font-size: x-small; color: black; } + + .meerkatDescription { font-family: sans-serif; font-size: 10pt; color: black } + .meerkatCategory { + font-family: sans-serif; font-size: 9pt; font-weight: bold; font-style: italic; + color: brown; } + .meerkatChannel { + font-family: sans-serif; font-size: 9pt; font-style: italic; color: brown; } + .meerkatDate { font-family: sans-serif; font-size: xx-small; color: #336699; } + + .tocTitle { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #333333; font-size: 10pt; + } + + .toc-item { + font-family: Arial,Helvetica; font-weight: bold; + color: #336699; font-size: 10pt; text-decoration: underline; + } + + .perlVersion { + font-family: Arial,Helvetica; font-weight: bold; + color: #336699; font-size: 10pt; text-decoration: none; + } + + .podTitle { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #000000; + } + + .docTitle { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #000000; font-size: 10pt; + } + .dotDot { + font-family: Arial,Helvetica; font-weight: bold; + color: #000000; font-size: 9pt; + } + + .docSec { + font-family: Arial,Helvetica; font-weight: normal; + color: #333333; font-size: 9pt; + } + .docVersion { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: 10pt; + } + + .docSecs-on { + font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; + color: #ff0000; font-size: 10pt; + } + .docSecs-off { + font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; + color: #333333; font-size: 10pt; + } + + h2 { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: medium; + } + h1 { + font-family: Verdana,Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: large; + } + + DL { + font-family: Arial,Helvetica; font-weight: normal; text-decoration: none; + color: #333333; font-size: 10pt; + } + + UL > LI > A { + font-family: Arial,Helvetica; font-weight: bold; + color: #336699; font-size: 10pt; + } + + .moduleInfo { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #333333; font-size: 11pt; + } + + .moduleInfoSec { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: 10pt; + } + + .moduleInfoVal { + font-family: Arial,Helvetica; font-weight: normal; text-decoration: underline; + color: #000000; font-size: 10pt; + } + + .cpanNavTitle { + font-family: Arial,Helvetica; font-weight: bold; + color: #ffffff; font-size: 10pt; + } + .cpanNavLetter { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #333333; font-size: 9pt; + } + .cpanCat { + font-family: Arial,Helvetica; font-weight: bold; text-decoration: none; + color: #336699; font-size: 9pt; + } + + .bttndrkblue-bkgd-top { + background-color: #225688; + background-image: url(/global/mvc_objects/images/bttndrkblue_bgtop.gif); + } + .bttndrkblue-bkgd-left { + background-color: #225688; + background-image: url(/global/mvc_objects/images/bttndrkblue_bgleft.gif); + } + .bttndrkblue-bkgd { + padding-top: 0px; + padding-bottom: 0px; + margin-bottom: 0px; + margin-top: 0px; + background-repeat: no-repeat; + background-color: #225688; + background-image: url(/global/mvc_objects/images/bttndrkblue_bgmiddle.gif); + vertical-align: top; + } + .bttndrkblue-bkgd-right { + background-color: #225688; + background-image: url(/global/mvc_objects/images/bttndrkblue_bgright.gif); + } + .bttndrkblue-bkgd-bottom { + background-color: #225688; + background-image: url(/global/mvc_objects/images/bttndrkblue_bgbottom.gif); + } + .bttndrkblue-text a { + color: #ffffff; + text-decoration: none; + } + a.bttndrkblue-text:hover { + color: #ffDD3C; + text-decoration: none; + } + .bg-ltblue { + background-color: #f0f5fa; + } + + .border-left-b { + background: #f0f5fa url(/i/corner-leftline.gif) repeat-y; + } + + .border-right-b { + background: #f0f5fa url(/i/corner-rightline.gif) repeat-y; + } + + .border-top-b { + background: #f0f5fa url(/i/corner-topline.gif) repeat-x; + } + + .border-bottom-b { + background: #f0f5fa url(/i/corner-botline.gif) repeat-x; + } + + .border-right-w { + background: #ffffff url(/i/corner-rightline.gif) repeat-y; + } + + .border-top-w { + background: #ffffff url(/i/corner-topline.gif) repeat-x; + } + + .border-bottom-w { + background: #ffffff url(/i/corner-botline.gif) repeat-x; + } + + .bg-white { + background-color: #ffffff; + } + + .border-left-w { + background: #ffffff url(/i/corner-leftline.gif) repeat-y; + } Index: llvm-www/releases/1.6/docs/CommandGuide/html/opt.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/opt.html:1.1 *** /dev/null Tue Nov 8 14:07:53 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/opt.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,113 ---- + + + opt - LLVM optimizer + + + + + + + + + + + +

+


+

NAME

+

opt - LLVM optimizer

+

+


+

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 LLVM Programmer's + Manual, section #DEBUG for more information. +

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

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + Index: llvm-www/releases/1.6/docs/CommandGuide/html/stkrc.html diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/stkrc.html:1.1 *** /dev/null Tue Nov 8 14:07:53 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/stkrc.html Tue Nov 8 14:07:41 2005 *************** *** 0 **** --- 1,112 ---- + + + stkrc - Stacker Compiler + + + + + + + + + + + +

+


+

NAME

+

stkrc - Stacker Compiler

+

+


+

SYNOPSIS

+

stkrc [options] [filename]

+

+


+

DESCRIPTION

+

The stkrc command is the compiler for the Stacker language. Stacker is a + simple stack based, Forth-like language that was written as a demonstration + language for LLVM. For details on the language, please see + http://llvm.cs.uiuc.edu/docs/Stacker.html . The stkrc compiler is fairly + minimal. It compiles to bytecode only and doesn't perform any optimizations. + The output of stkrc (a bytecode file) can be piped through other LLVM tools + for optimization and linking.

+

If filename is omitted or is -, then stkrc reads its input + from standard input. This is useful for combining the tool into a pipeline.

+

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

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

    +
  • + If the input is a file that ends with .st, 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 .st suffix, then the + output file has the same name as the input file, except that the .bc + suffix is appended. +

+

+


+

OPTIONS

+
+
-o filename
+
+ Specify the output file name. If filename is -, then llvm-as + sends its output to standard output. +

+
-stats
+
+ Print statistics acquired during compilation. +

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

+
-f
+
+ Force the output to be written. Normally, stkrc won't overwrite an existing + bytecode file. This option overrides that behavior. +

+
-s=stacksize
+
+ Specify the stack size for the program. The default stack size, 1024, should be + sufficient for most programs. For very large, programs, you might want to + provide a larger value. +

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

+

+


+

EXIT STATUS

+

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

+

+


+

SEE ALSO

+

the llvm-as manpage, http://llvm.cs.uiuc.edu/docs/Stacker.html

+

+


+

AUTHORS

+

Maintained by the LLVM Team (http://llvm.cs.uiuc.edu).

+ + + + From lattner at cs.uiuc.edu Tue Nov 8 14:07:56 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:07:56 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/man/man1/analyze.1 bugpoint.1 extract.1 gccas.1 gccld.1 llc.1 lli.1 llvm-as.1 llvm-bcanalyzer.1 llvm-db.1 llvm-dis.1 llvm-link.1 llvm-nm.1 llvm-prof.1 llvmgcc.1 llvmgxx.1 opt.1 stkrc.1 Message-ID: <200511082007.OAA30583@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/man/man1: analyze.1 added (r1.1) bugpoint.1 added (r1.1) extract.1 added (r1.1) gccas.1 added (r1.1) gccld.1 added (r1.1) llc.1 added (r1.1) lli.1 added (r1.1) llvm-as.1 added (r1.1) llvm-bcanalyzer.1 added (r1.1) llvm-db.1 added (r1.1) llvm-dis.1 added (r1.1) llvm-link.1 added (r1.1) llvm-nm.1 added (r1.1) llvm-prof.1 added (r1.1) llvmgcc.1 added (r1.1) llvmgxx.1 added (r1.1) opt.1 added (r1.1) stkrc.1 added (r1.1) --- Log message: check in 1.6 docs --- Diffs of the changes: (+3875 -0) analyze.1 | 197 ++++++++++++++++++++++++++++++ bugpoint.1 | 349 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ extract.1 | 194 ++++++++++++++++++++++++++++++ gccas.1 | 197 ++++++++++++++++++++++++++++++ gccld.1 | 282 +++++++++++++++++++++++++++++++++++++++++++ llc.1 | 286 ++++++++++++++++++++++++++++++++++++++++++++ lli.1 | 198 ++++++++++++++++++++++++++++++ llvm-as.1 | 199 ++++++++++++++++++++++++++++++ llvm-bcanalyzer.1 | 190 +++++++++++++++++++++++++++++ llvm-db.1 | 151 +++++++++++++++++++++++ llvm-dis.1 | 189 +++++++++++++++++++++++++++++ llvm-link.1 | 196 ++++++++++++++++++++++++++++++ llvm-nm.1 | 229 +++++++++++++++++++++++++++++++++++ llvm-prof.1 | 183 ++++++++++++++++++++++++++++ llvmgcc.1 | 206 +++++++++++++++++++++++++++++++ llvmgxx.1 | 206 +++++++++++++++++++++++++++++++ opt.1 | 216 +++++++++++++++++++++++++++++++++ stkrc.1 | 207 ++++++++++++++++++++++++++++++++ 18 files changed, 3875 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/analyze.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/analyze.1:1.1 *** /dev/null Tue Nov 8 14:07:54 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/analyze.1 Tue Nov 8 14:07:43 2005 *************** *** 0 **** --- 1,197 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:16 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "ANALYZE 1" + .TH ANALYZE 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + analyze \- \s-1LLVM\s0 program analyzer + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBanalyze\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBanalyze\fR command performs various analysis of \s-1LLVM\s0 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. + .PP + If filename is omitted or is \fI-\fR, \fBanalyze\fR reads its input from + standard input. It first attempts to interpret its input as \s-1LLVM\s0 + bytecode. If it encounters an error, it then attempts to parse the + input as \s-1LLVM\s0 assembly language. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-help\fR" 4 + .IX Item "-help" + Print a summary of command line options. + .Ip "\fB\-q\fR" 4 + .IX Item "-q" + Quiet mode. With this option, analysis pass names are not printed. + .Ip "\fB\-load\fR \fIplugin\fR" 4 + .IX Item "-load plugin" + Load the specified dynamic object with name \fIplugin\fR. This file + should contain additional analysis passes that register themselves + with the \fBanalyze\fR program after being loaded. + .Sp + After being loaded, additional command line options are made + available for running the passes made available by \fIplugin\fR. Use + \&\fBanalyze \-load\fR \fIplugin\fR \fB\-help\fR to see the new list of available + analysis passes. + .Ip "\fB\-profile-info-file\fR \fIfilename\fR" 4 + .IX Item "-profile-info-file filename" + Specify the name of the file loaded by the \-profile-loader option. + .Ip "\fB\-stats\fR" 4 + .IX Item "-stats" + Print statistics. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBanalyze\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + opt + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/bugpoint.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/bugpoint.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/bugpoint.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,349 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:16 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "BUGPOINT 1" + .TH BUGPOINT 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + bugpoint \- automatic test case reduction tool + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBbugpoint\fR [\fIoptions\fR] [\fIinput \s-1LLVM\s0 ll/bc files\fR] [\fI\s-1LLVM\s0 passes\fR] \fB\*(--args\fR + \&\fIprogram arguments\fR + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + \&\fBbugpoint\fR narrows down the source of problems in \s-1LLVM\s0 tools and passes. It + can be used to debug three types of failures: optimizer crashes, miscompilations + by optimizers, or bad native code generation (including problems in the static + and \s-1JIT\s0 compilers). It aims to reduce large test cases to small, useful ones. + For example, if \fBgccas\fR 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. + .Sh "Design Philosophy" + .IX Subsection "Design Philosophy" + \&\fBbugpoint\fR is designed to be a useful tool without requiring any hooks into the + \&\s-1LLVM\s0 infrastructure at all. It works with any and all \s-1LLVM\s0 passes and code + generators, and does not need to \*(L"know\*(R" how they work. Because of this, it may + appear to do stupid things or miss obvious simplifications. \fBbugpoint\fR is also + designed to trade off programmer time for computer time in the + compiler-debugging process; consequently, it may take a long period of + (unattended) time to reduce a test case, but we feel it is still worth it. Note + that \fBbugpoint\fR is generally very quick unless debugging a miscompilation where + each test of the program (which requires executing it) takes a long time. + .Sh "Automatic Debugger Selection" + .IX Subsection "Automatic Debugger Selection" + \&\fBbugpoint\fR reads each \fI.bc\fR or \fI.ll\fR file specified on the command line and + links them together into a single module, called the test program. If any \s-1LLVM\s0 + passes are specified on the command line, it runs these passes on the test + program. If any of the passes crash, or if they produce malformed output (which + causes the verifier to abort), \fBbugpoint\fR starts the crash debugger. + .PP + Otherwise, if the \fB\-output\fR option was not specified, \fBbugpoint\fR runs the test + program with the C backend (which is assumed to generate good code) to generate + a reference output. Once \fBbugpoint\fR has a reference output for the test + program, it tries executing it with the selected code generator. If the + selected code generator crashes, \fBbugpoint\fR starts the the Crash debugger entry elsewhere in this document 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 the Code generator debugger entry elsewhere in this document. + .PP + Finally, if the output of the selected code generator matches the reference + output, \fBbugpoint\fR runs the test program after all of the \s-1LLVM\s0 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 \s-1LLVM\s0 passes, and enters the + miscompilation debugger. Otherwise, there is no problem \fBbugpoint\fR can debug. + .Sh "Crash debugger" + .IX Subsection "Crash debugger" + If an optimizer or code generator crashes, \fBbugpoint\fR will try as hard as it + can to reduce the list of passes (for optimizer crashes) and the size of the + test program. First, \fBbugpoint\fR figures out which combination of optimizer + passes triggers the bug. This is useful when debugging a problem exposed by + \&\fBgccas\fR, for example, because it runs over 38 passes. + .PP + Next, \fBbugpoint\fR 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, \fBbugpoint\fR + deletes any individual \s-1LLVM\s0 instructions whose absence does not eliminate the + failure. At the end, \fBbugpoint\fR should tell you what passes crash, give you a + bytecode file, and give you instructions on how to reproduce the failure with + \&\fBopt\fR, \fBanalyze\fR, or \fBllc\fR. + .Sh "Code generator debugger" + .IX Subsection "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 + \&\s-1JIT\s0 or the static compiler (\fBllc\fR). It uses several techniques to reduce the + amount of code pushed through the \s-1LLVM\s0 code generator, to reduce the potential + scope of the problem. After it is finished, it emits two bytecode files (called + \&\*(L"test\*(R" [to be compiled with the code generator] and \*(L"safe\*(R" [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. + .Sh "Miscompilation debugger" + .IX Subsection "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. + .Sh "Advice for using bugpoint" + .IX Subsection "Advice for using bugpoint" + \&\fBbugpoint\fR can be a remarkably useful tool, but it sometimes works in + non-obvious ways. Here are some hints and tips: + .Ip "\(bu" 4 + In the code generator and miscompilation debuggers, \fBbugpoint\fR only + works with programs that have deterministic output. Thus, if the program + outputs \f(CW\*(C`argv[0]\*(C'\fR, the date, time, or any other \*(L"random\*(R" data, \fBbugpoint\fR 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. + .Ip "\(bu" 4 + 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. + .Ip "\(bu" 4 + \&\fBbugpoint\fR is extremely useful when working on a new optimization: it helps + track down regressions quickly. To avoid having to relink \fBbugpoint\fR every + time you change your optimization, make \fBbugpoint\fR dynamically load + your optimization by using the \fB\-load\fR option. + .Ip "\(bu" 4 + \&\fBbugpoint\fR 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: + .Sp + .Vb 1 + \& bugpoint ... |& tee bugpoint.log + .Ve + to get a copy of \fBbugpoint\fR's output in the file \fIbugpoint.log\fR, as well as on + your terminal. + .Ip "\(bu" 4 + \&\fBbugpoint\fR cannot debug problems with the \s-1LLVM\s0 linker. If \fBbugpoint\fR crashes + before you see its \f(CW\*(C`All input ok\*(C'\fR message, you might try running \f(CW\*(C`llvm\-link + \&\-v\*(C'\fR on the same set of input files. If that also crashes, you may be + experiencing a linker bug. + .Ip "\(bu" 4 + If your program is supposed to crash, \fBbugpoint\fR will be confused. One way to + deal with this is to cause \fBbugpoint\fR to ignore the exit code from your + program, by giving it the \fB\-check-exit-code=false\fR option. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\*(--additional-so\fR \fIlibrary\fR" 4 + .IX Item "additional-so library" + Load the dynamic shared object \fIlibrary\fR into the test program whenever it is + run. This is useful if you are debugging programs which depend on non-LLVM + libraries (such as the X or curses libraries) to run. + .Ip "\fB\*(--args\fR \fIprogram args\fR" 4 + .IX Item "args program args" + Pass all arguments specified after \-args to the test program whenever it runs. + Note that if any of the \fIprogram args\fR start with a '\-', you should use: + .Sp + .Vb 1 + \& bugpoint [bugpoint args] --args -- [program args] + .Ve + The \*(L"\-\-\*(R" right after the \fB\*(--args\fR option tells \fBbugpoint\fR to consider any + options starting with \f(CW\*(C`\-\*(C'\fR to be part of the \fB\*(--args\fR option, not as options to + \&\fBbugpoint\fR itself. + .Ip "\fB\*(--tool-args\fR \fItool args\fR" 4 + .IX Item "tool-args tool args" + Pass all arguments specified after \-\-tool-args to the \s-1LLVM\s0 tool under test + (\fBllc\fR, \fBlli\fR, etc.) whenever it runs. You should use this option in the + following way: + .Sp + .Vb 1 + \& bugpoint [bugpoint args] --tool-args -- [tool args] + .Ve + The \*(L"\-\-\*(R" right after the \fB\*(--tool-args\fR option tells \fBbugpoint\fR to consider any + options starting with \f(CW\*(C`\-\*(C'\fR to be part of the \fB\*(--tool-args\fR option, not as + options to \fBbugpoint\fR itself. (See \fB\*(--args\fR, above.) + .Ip "\fB\*(--check-exit-code\fR=\fI{true,false}\fR" 4 + .IX Item "check-exit-code={true,false}" + Assume a non-zero exit code or core dump from the test program is a failure. + Defaults to true. + .Ip "\fB\*(--disable-{dce,simplifycfg}\fR" 4 + .IX Item "disable-{dce,simplifycfg}" + Do not run the specified passes to clean up and reduce the size of the test + program. By default, \fBbugpoint\fR uses these passes internally when attempting to + reduce test programs. If you're trying to find a bug in one of these passes, + \&\fBbugpoint\fR may crash. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\*(--input\fR \fIfilename\fR" 4 + .IX Item "input filename" + Open \fIfilename\fR and redirect the standard input of the test program, whenever + it runs, to come from that file. + .Ip "\fB\*(--load\fR \fIplugin\fR" 4 + .IX Item "load plugin" + Load the dynamic object \fIplugin\fR into \fBbugpoint\fR itself. This object should + register new optimization passes. Once loaded, the object will add new command + line options to enable various optimizations. To see the new complete list of + optimizations, use the \fB\*(--help\fR and \fB\*(--load\fR options together; for example: + .Sp + .Vb 1 + \& bugpoint --load myNewPass.so --help + .Ve + .Ip "\fB\*(--output\fR \fIfilename\fR" 4 + .IX Item "output filename" + Whenever the test program produces output on its standard output stream, it + should match the contents of \fIfilename\fR (the \*(L"reference output\*(R"). If you + do not use this option, \fBbugpoint\fR will attempt to generate a reference output + by compiling the program with the C backend and running it. + .Ip "\fB\*(--profile-info-file\fR \fIfilename\fR" 4 + .IX Item "profile-info-file filename" + Profile file loaded by \fB\*(--profile-loader\fR. + .Ip "\fB\*(--run-{int,jit,llc,cbe}\fR" 4 + .IX Item "run-{int,jit,llc,cbe}" + Whenever the test program is compiled, \fBbugpoint\fR should generate code for it + using the specified code generator. These options allow you to choose the + interpreter, the \s-1JIT\s0 compiler, the static native code compiler, or the C + backend, respectively. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBbugpoint\fR succeeds in finding a problem, it will exit with 0. Otherwise, + if an error occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + opt, analyze + .SH "AUTHOR" + .IX Header "AUTHOR" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/extract.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/extract.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/extract.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,194 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:16 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "EXTRACT 1" + .TH EXTRACT 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + extract \- extract a function from an \s-1LLVM\s0 module + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBextract\fR [\fIoptions\fR] \fB\*(--func\fR \fIfunction-name\fR [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBextract\fR command takes the name of a function and extracts it from + the specified \s-1LLVM\s0 bytecode file. It is primarily used as a debugging tool to + reduce test cases from larger programs that are triggering a bug. + .PP + In addition to extracting the bytecode of the specified function, + \&\fBextract\fR will also remove unreachable global variables, prototypes, and + unused types. + .PP + The \fBextract\fR command reads its input from standard input if filename is + omitted or if filename is \-. The output is always written to standard output, + unless the \fB\-o\fR option is specified (see below). + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Force overwrite. Normally, \fBextract\fR will refuse to overwrite an + output file that already exists. With this option, \fBextract\fR + will overwrite the output file and replace it with new bytecode. + .Ip "\fB\*(--func\fR \fIfunction-name\fR" 4 + .IX Item "func function-name" + Extract the function named \fIfunction-name\fR from the \s-1LLVM\s0 bytecode. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output filename. If filename is \*(L"\-\*(R" (the default), then + \&\fBextract\fR sends its output to standard output. + .Ip "\fB\*(--stats\fR" 4 + .IX Item "stats" + Print statistics. + .Ip "\fB\*(--time-passes\fR" 4 + .IX Item "time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBextract\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + bugpoint + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/gccas.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/gccas.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/gccas.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,197 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:16 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "GCCAS 1" + .TH GCCAS 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + gccas \- optimizing \s-1LLVM\s0 assembler + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBgccas\fR [\fIoptions\fR] \fIfilename\fR + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBgccas\fR utility takes an \s-1LLVM\s0 assembly file generated by the + llvmgcc or llvmg++ front-ends and converts + it into an \s-1LLVM\s0 bytecode file. It is primarily used by the \s-1GCC\s0 + front end, and as such, attempts to mimic the interface provided + by the default system assembler so that it can act as a \*(L"drop-in\*(R" + replacement. + .PP + \&\fBgccas\fR performs a number of optimizations on the input program, + including but not limited to: promotion of stack values to \s-1SSA\s0 + registers; elimination of dead globals, function arguments, code, + and types; tail-call elimination; loop-invariant code motion; global + common-subexpression elimination; and sparse conditional constant + propagation. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the name of the output file which will hold the assembled bytecode. + .Ip "\fB\*(--disable-inlining\fR" 4 + .IX Item "disable-inlining" + Disable the inlining pass. By default, it is enabled. + .Ip "\fB\*(--disable-opt\fR" 4 + .IX Item "disable-opt" + Disable all assembler-time optimization passes. + .Ip "\fB\*(--stats\fR" 4 + .IX Item "stats" + Print statistics. + .Ip "\fB\*(--time-passes\fR" 4 + .IX Item "time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .Ip "\fB\*(--verify\fR" 4 + .IX Item "verify" + Verify each pass result. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBgccas\fR succeeds, it will exit with an exit status of 0. + Otherwise, if an error occurs, it will exit with a non-zero exit + status. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvm-as, gccld + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/gccld.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/gccld.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/gccld.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,282 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:16 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "GCCLD 1" + .TH GCCLD 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + gccld \- optimizing \s-1LLVM\s0 linker + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBgccld\fR [\fIoptions\fR] \fIfilename ...\fR + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBgccld\fR utility takes a set of \s-1LLVM\s0 bytecode files and links them + together into a single \s-1LLVM\s0 bytecode file. The output bytecode file can be + another bytecode library or an executable bytecode program. Using additional + options, \fBgccld\fR is able to produce native code executables. + .PP + The \fBgccld\fR utility is primarily used by the the llvmgcc manpage and + llvmg++ 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. + .PP + The \fBgccld\fR tool performs a small set of interprocedural, post-link + optimizations on the program. + .Sh "Search Order" + .IX Subsection "Search Order" + When looking for objects specified on the command line, \fBgccld\fR will search for + the object first in the current directory and then in the directory specified by + the \fB\s-1LLVM_LIB_SEARCH_PATH\s0\fR environment variable. If it cannot find the object, + it fails. + .PP + When looking for a library specified with the \fB\-l\fR option, \fBgccld\fR first + attempts to load a file with that name from the current directory. If that + fails, it looks for lib\fIlibrary\fR.bc, lib\fIlibrary\fR.a, or lib\fIlibrary\fR.\fIshared + library extension\fR, in that order, in each directory added to the library search + path with the \fB\-L\fR option. These directories are searched in the order they + were specified. If the library cannot be located, then \fBgccld\fR looks in the + directory specified by the \fB\s-1LLVM_LIB_SEARCH_PATH\s0\fR environment variable. If it + does not find a library there, it fails. + .PP + The shared library extension may be \fI.so\fR, \fI.dyld\fR, \fI.dll\fR, or something + different, depending upon the system. + .PP + The \fB\-L\fR option is global. It does not matter where it is specified in the + list of command line arguments; the directory is simply added to the search path + and is applied to all libraries, preceding or succeeding, in the command line. + .Sh "Link order" + .IX Subsection "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. + .Sh "Library Linkage" + .IX Subsection "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. + .Sh "Native code generation" + .IX Subsection "Native code generation" + The \fBgccld\fR program has limited support for native code generation, when + using the \fB\-native\fR or \fB\-native-cbe\fR options. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-help\fR" 4 + .IX Item "-help" + Print a summary of command line options. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output filename which will hold the linked bytecode. + .Ip "\fB\-stats\fR" 4 + .IX Item "-stats" + Print statistics. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .Ip "\fB\-verify\fR" 4 + .IX Item "-verify" + Verify each pass result. + .Ip "\fB\-disable-opt\fR" 4 + .IX Item "-disable-opt" + Disable all link-time optimization passes. + .Ip "\fB\-disable-inlining\fR" 4 + .IX Item "-disable-inlining" + Do not run the inliner pass. + .Ip "\fB\-L\fR\fIdirectory\fR" 4 + .IX Item "-Ldirectory" + Add directory to the list of directories to search when looking for + libraries. + .Ip "\fB\-disable-internalize\fR" 4 + .IX Item "-disable-internalize" + Do not mark all symbols as internal. + .Ip "\fB\-internalize-public-api-file\fR \fIfilename\fR" 4 + .IX Item "-internalize-public-api-file filename" + Preserve the list of symbol names in the file filename. + .Ip "\fB\-internalize-public-api-list <list>\fR" 4 + .IX Item "-internalize-public-api-list <list>" + Preserve the symbol names in list. + .Ip "\fB\-l\fR\fIlibrary\fR" 4 + .IX Item "-llibrary" + Specify libraries to include when linking the output file. When linking, + \&\fBgccld\fR will first attempt to load a file with the pathname \fBlibrary\fR. If + that fails, it will then attempt to load lib\fIlibrary\fR.bc, lib\fIlibrary\fR.a, and + lib\fIlibrary\fR.\fIshared library extension\fR, in that order. + .Ip "\fB\-link-as-library\fR" 4 + .IX Item "-link-as-library" + Link the .bc files together as a library, not an executable. + .Ip "\fB\-native\fR" 4 + .IX Item "-native" + Generate a native machine code executable. + .Sp + When generating native executables, \fBgccld\fR first checks for a bytecode + version of the library and links it in, if necessary. If the library is + missing, \fBgccld\fR skips it. Then, \fBgccld\fR links in the same + libraries as native code. + .Sp + In this way, \fBgccld\fR 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. + .Ip "\fB\-native-cbe\fR" 4 + .IX Item "-native-cbe" + Generate a native machine code executable with the \s-1LLVM\s0 C backend. + .Sp + This option is identical to the \fB\-native\fR option, but uses the + C backend to generate code for the program instead of an \s-1LLVM\s0 native + code generator. + .Ip "\fB\-s\fR" 4 + .IX Item "-s" + Strip symbol information from the generated executable. + .Ip "\fB\-v\fR" 4 + .IX Item "-v" + Print information about actions taken. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBgccld\fR succeeds, it will exit with an exit status of 0. + Otherwise, if an error occurs, it will exit with a non-zero exit + status. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvm-link, gccas + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llc.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llc.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llc.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,286 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLC 1" + .TH LLC 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llc \- \s-1LLVM\s0 static compiler + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllc\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllc\fR command compiles \s-1LLVM\s0 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. + .PP + The choice of architecture for the output assembly code is determined as + follows, by attempting to satisfy each of the following rules in turn (first + one wins): + .Ip "\(bu" 4 + If the user has specified an architecture with the \-m option, use that + architecture. + .Ip "\(bu" 4 + Examine the input \s-1LLVM\s0 bytecode file: if it is little endian and has a + pointer size of 32 bits, select the Intel \s-1IA-32\s0 architecture. If it is big + endian and has a pointer size of 64 bits, select the SparcV9 architecture. + .Ip "\(bu" 4 + If \fBllc\fR was compiled on an architecture for which it can generate code, select + the architecture upon which \fBllc\fR was compiled. + .Ip "\(bu" 4 + Exit with an error message telling the user to specify the output + architecture explicitly. + .SH "OPTIONS" + .IX Header "OPTIONS" + If \fIfilename\fR is \- or omitted, \fBllc\fR reads \s-1LLVM\s0 bytecode from standard input. + Otherwise, it will read \s-1LLVM\s0 bytecode from \fIfilename\fR. + .PP + If the \fB\-o\fR option is omitted, then \fBllc\fR will send its output to standard + output if the input is from standard input. If the \fB\-o\fR option specifies \-, + then the output will also be sent to standard output. + .PP + If no \fB\-o\fR option is specified and an input file other than \- is specified, + then \fBllc\fR creates the output filename by taking the input filename, + removing any existing \fI.bc\fR extension, and adding a \fI.s\fR suffix. + .PP + Other \fBllc\fR options are as follows: + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Overwrite output files. By default, \fBllc\fR will refuse to overwrite + an output file which already exists. + .Ip "\fB\-march\fR=\fIarch\fR" 4 + .IX Item "-march=arch" + Specify the architecture for which to generate assembly. Valid + architectures are: + .RS 4 + .Ip "\fIx86\fR" 4 + .IX Item "x86" + Intel \s-1IA-32\s0 (Pentium and above) + .Ip "\fIsparcv9\fR" 4 + .IX Item "sparcv9" + 64\-bit \s-1SPARC\s0 V9 + .Ip "\fIc\fR" 4 + .IX Item "c" + Emit C code, not assembly + .RE + .RS 4 + .RE + .Ip "\fB\-enable-correct-eh-support\fR" 4 + .IX Item "-enable-correct-eh-support" + Instruct the \fB\-lowerinvoke\fR pass to insert code for correct exception handling + support. This is expensive and is by default omitted for efficiency. + .Ip "\fB\-help\fR" 4 + .IX Item "-help" + Print a summary of command line options. + .Ip "\fB\-stats\fR" 4 + .IX Item "-stats" + Print statistics recorded by code-generation passes. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each pass and print a report to standard + error. + .Sh "Intel IA-32\-specific Options" + .IX Subsection "Intel IA-32-specific Options" + .Ip "\fB\*(--disable-fp-elim\fR" 4 + .IX Item "disable-fp-elim" + Disable frame pointer elimination optimization. + .Ip "\fB\*(--disable-pattern-isel\fR" 4 + .IX Item "disable-pattern-isel" + Use the 'simple' X86 instruction selector (the default). + .Ip "\fB\*(--print-machineinstrs\fR" 4 + .IX Item "print-machineinstrs" + Print generated machine code. + .Ip "\fB\*(--regalloc\fR=\fIallocator\fR" 4 + .IX Item "regalloc=allocator" + Specify the register allocator to use. The default \fIallocator\fR is \fIlocal\fR. + Valid register allocators are: + .RS 4 + .Ip "\fIsimple\fR" 4 + .IX Item "simple" + Very simple \*(L"always spill\*(R" register allocator + .Ip "\fIlocal\fR" 4 + .IX Item "local" + Local register allocator + .Ip "\fIlinearscan\fR" 4 + .IX Item "linearscan" + Linear scan global register allocator (experimental) + .RE + .RS 4 + .RE + .Ip "\fB\*(--spiller\fR=\fIspiller\fR" 4 + .IX Item "spiller=spiller" + Specify the spiller to use for register allocators that support it. Currently + this option is used only by the linear scan register allocator. The default + \&\fIspiller\fR is \fIlocal\fR. Valid spillers are: + .RS 4 + .Ip "\fIsimple\fR" 4 + .IX Item "simple" + Simple spiller + .Ip "\fIlocal\fR" 4 + .IX Item "local" + Local spiller + .RE + .RS 4 + .RE + .Sh "SPARCV9\-specific Options" + .IX Subsection "SPARCV9-specific Options" + .Ip "\fB\*(--disable-peephole\fR" 4 + .IX Item "disable-peephole" + Disable peephole optimization pass. + .Ip "\fB\*(--disable-sched\fR" 4 + .IX Item "disable-sched" + Disable local scheduling pass. + .Ip "\fB\*(--disable-strip\fR" 4 + .IX Item "disable-strip" + The Sparc backend embeds the \s-1LLVM\s0 bytecode into the assembly output. This + option requests that symbol names be retained; by default, they are stripped out. + .Ip "\fB\*(--enable-maps\fR" 4 + .IX Item "enable-maps" + Emit LLVM-to-machine code mapping information into the assembly output. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllc\fR succeeds, it will exit with 0. Otherwise, if an error occurs, + it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + lli + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/lli.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/lli.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/lli.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,198 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLI 1" + .TH LLI 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + lli \- directly execute programs from \s-1LLVM\s0 bytecode + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBlli\fR [\fIoptions\fR] [\fIfilename\fR] [\fIprogram args\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + \&\fBlli\fR directly executes programs in \s-1LLVM\s0 bytecode format. It takes a program + in \s-1LLVM\s0 bytecode format and executes it using a just-in-time compiler, if one is + available for the current architecture, or an interpreter. \fBlli\fR takes all of + the same code generator options as llc, but they are only effective when + \&\fBlli\fR is using the just-in-time compiler. + .PP + If \fIfilename\fR is not specified, then \fBlli\fR reads the \s-1LLVM\s0 bytecode for the + program from standard input. + .PP + The optional \fIargs\fR specified on the command line are passed to the program as + arguments. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-help\fR" 4 + .IX Item "-help" + Print a summary of command line options. + .Ip "\fB\-stats\fR" 4 + .IX Item "-stats" + Print statistics from the code-generation passes. This is only meaningful for + the just-in-time compiler, at present. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each code-generation pass and print it to + standard error. + .Ip "\fB\-march\fR=\fIarch\fR" 4 + .IX Item "-march=arch" + Use the specified non-default architecture arch 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 \fBlli\fR on. + .Ip "\fB\-force-interpreter\fR=\fI{false,true}\fR" 4 + .IX Item "-force-interpreter={false,true}" + If set to true, use the interpreter even if a just-in-time compiler is available + for this architecture. Defaults to false. + .Ip "\fB\-f\fR=\fIname\fR" 4 + .IX Item "-f=name" + Call the function named \fIname\fR to start the program. Note: The + function is assumed to have the C signature \f(CW\*(C`int\*(C'\fR \fIname\fR \f(CW\*(C`(int, + char **, char **)\*(C'\fR. If you try to use this option to call a function of + incompatible type, undefined behavior may result. Defaults to \f(CW\*(C`main\*(C'\fR. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBlli\fR fails to load the program, it will exit with an exit code of 1. + Otherwise, it will return the exit code of the program it executes. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llc + .SH "AUTHOR" + .IX Header "AUTHOR" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-as.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-as.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-as.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,199 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-AS 1" + .TH LLVM-AS 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-as \- \s-1LLVM\s0 assembler + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvm-as\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvm-as\fR command invokes the \s-1LLVM\s0 assembler. It reads a file containing + human-readable \s-1LLVM\s0 assembly language, translates it to \s-1LLVM\s0 bytecode, and + writes the result into a file or to standard output. + .PP + If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR reads its input from + standard input. + .PP + If an output file is not specified with the \fB\-o\fR option, then + \&\fBllvm-as\fR sends its output to a file or standard output by following + these rules: + .Ip "\(bu" 4 + If the input is standard input, then the output is standard output. + .Ip "\(bu" 4 + If the input is a file that ends with \f(CW\*(C`.ll\*(C'\fR, then the output file is of + the same name, except that the suffix is changed to \f(CW\*(C`.bc\*(C'\fR. + .Ip "\(bu" 4 + If the input is a file that does not end with the \f(CW\*(C`.ll\*(C'\fR suffix, then the + output file has the same name as the input file, except that the \f(CW\*(C`.bc\*(C'\fR + suffix is appended. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Force overwrite. Normally, \fBllvm-as\fR will refuse to overwrite an + output file that already exists. With this option, \fBllvm-as\fR + will overwrite the output file and replace it with new bytecode. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR + sends its output to standard output. + .Ip "\fB\*(--stats\fR" 4 + .IX Item "stats" + Print statistics. + .Ip "\fB\*(--time-passes\fR" 4 + .IX Item "time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllvm-as\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvm-dis, gccas + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-bcanalyzer.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-bcanalyzer.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-bcanalyzer.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,190 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-BCANALYZER 1" + .TH LLVM-BCANALYZER 1 "1.3" "2004-07-02" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-bcanalyzer \- \s-1LLVM\s0 bytecode analyzer + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvm-bcanalyzer\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvm-bcanalyzer\fR command is a small utility for analyzing bytecode files. + The tool reads a bytecode file (such as generated with the \fBllvm-as\fR tool) and + produces a statistical report on the contents of the byteocde file. The tool + will also dump a low level but human readable version of the bytecode file. + This tool is probably not of much interest or utility except for those working + directly with the bytecode file format. Most \s-1LLVM\s0 users can just ignore + this tool. + .PP + If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-bcanalyzer\fR reads its input + from standard input. This is useful for combining the tool into a pipeline. + .PP + Output is written to the standard output. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-nodetails\fR" 4 + .IX Item "-nodetails" + Causes \fBllvm-bcanalyzer\fR to abbreviate its output by writing out only a module + level summary. The details for individual functions are not displayed. + .Ip "\fB\-dump\fR" 4 + .IX Item "-dump" + Causes \fBllvm-bcanalyzer\fR to dump the bytecode in a human readable format. This + format is significantly different from \s-1LLVM\s0 assembly and provides details about + the encoding of the bytecode file. + .Ip "\fB\-verify\fR" 4 + .IX Item "-verify" + Causes \fBllvm-bcanalyzer\fR to verify the module produced by by reading the + bytecode. This ensures that the statistics generated are based on a consistent + module. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllvm-bcanalyzer\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value, usually 1. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvm-dis, http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-db.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-db.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-db.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,151 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-DB 1" + .TH LLVM-DB 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-db \- \s-1LLVM\s0 debugger (alpha) + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + Details coming soon. Please see + http://llvm.cs.uiuc.edu/docs/SourceLevelDebugging.html in the meantime. + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-dis.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-dis.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-dis.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,189 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-DIS 1" + .TH LLVM-DIS 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-dis \- \s-1LLVM\s0 disassembler + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvm-dis\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvm-dis\fR command is the \s-1LLVM\s0 disassembler. It takes an \s-1LLVM\s0 + bytecode file and converts it into human-readable \s-1LLVM\s0 assembly language. + .PP + If filename is omitted or specified as \f(CW\*(C`\-\*(C'\fR, \fBllvm-dis\fR reads its + input from standard input. + .PP + If the input is being read from standard input, then \fBllvm-dis\fR + will send its output to standard output by default. Otherwise, the + output will be written to a file named after the input file, with + a \f(CW\*(C`.ll\*(C'\fR suffix added (any existing \f(CW\*(C`.bc\*(C'\fR suffix will first be + removed). You can override the choice of output file using the + \&\fB\-o\fR option. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Force overwrite. Normally, \fBllvm-dis\fR will refuse to overwrite + an output file that already exists. With this option, \fBllvm-dis\fR + will overwrite the output file. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output file name. If \fIfilename\fR is \-, then the output is sent + to standard output. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllvm-dis\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvm-as + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-link.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-link.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-link.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,196 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-LINK 1" + .TH LLVM-LINK 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-link \- \s-1LLVM\s0 linker + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvm-link\fR [\fIoptions\fR] \fIfilename ...\fR + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvm-link\fR command takes several \s-1LLVM\s0 bytecode files and links them + together into a single \s-1LLVM\s0 bytecode file. It writes the output file to + standard output, unless the \fB\-o\fR option is used to specify a filename. + .PP + The \fBllvm-link\fR 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 \fB\-L\fR options on the command line. The library search paths + are global; each one is searched for every input file if necessary. The + directories are searched in the order they were specified on the command line. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-L\fR \fIdirectory\fR" 4 + .IX Item "-L directory" + Add the specified \fIdirectory\fR to the library search path. When looking for + libraries, \fBllvm-link\fR will look in pathname for libraries. This option can be + specified multiple times; \fBllvm-link\fR will search inside these directories in + the order in which they were specified on the command line. + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Overwrite output files. By default, \fBllvm-link\fR will not overwrite an output + file if it alreadys exists. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-link\fR will + write its output to standard output. + .Ip "\fB\-d\fR" 4 + .IX Item "-d" + If specified, \fBllvm-link\fR prints a human-readable version of the output + bytecode file to standard error. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-v\fR" 4 + .IX Item "-v" + Verbose mode. Print information about what \fBllvm-link\fR is doing. This + typically includes a message for each bytecode file linked in and for each + library found. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllvm-link\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + the gccld manpage + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-nm.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-nm.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-nm.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,229 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-NM 1" + .TH LLVM-NM 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-nm \- list \s-1LLVM\s0 bytecode file's symbol table + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvm-nm\fR [\fIoptions\fR] [\fIfilenames...\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvm-nm\fR utility lists the names of symbols from the \s-1LLVM\s0 bytecode files, + or \fBar\fR archives containing \s-1LLVM\s0 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 \fI-\fR is used as a filename, \fBllvm-nm\fR will + process a bytecode file on its standard input stream. + .PP + \&\fBllvm-nm\fR's default output format is the traditional \s-1BSD\s0 \fBnm\fR output format. + Each such output record consists of an (optional) 8\-digit hexadecimal address, + followed by a type code character, followed by a name, for each symbol. One + record is printed per line; fields are separated by spaces. When the address is + omitted, it is replaced by 8 spaces. + .PP + Type code characters currently supported, and their meanings, are as follows: + .Ip "U" 4 + .IX Item "U" + Named object is referenced but undefined in this bytecode file + .Ip "C" 4 + .IX Item "C" + Common (multiple defs link together into one def) + .Ip "W" 4 + .IX Item "W" + Weak reference (multiple defs link together into zero or one defs) + .Ip "t" 4 + .IX Item "t" + Local function (text) object + .Ip "T" 4 + .IX Item "T" + Global function (text) object + .Ip "d" 4 + .IX Item "d" + Local data object + .Ip "D" 4 + .IX Item "D" + Global data object + .Ip "?" 4 + Something unrecognizable + .PP + Because \s-1LLVM\s0 bytecode files typically contain objects that are not considered to + have addresses until they are linked into an executable image or dynamically + compiled \*(L"just-in-time\*(R", \fBllvm-nm\fR does not print an address for any symbol, + even symbols which are defined in the bytecode file. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-P\fR" 4 + .IX Item "-P" + Use \s-1POSIX\s0.2 output format. Alias for \fB\*(--format=posix\fR. + .Ip "\fB\-B\fR (default)" 4 + .IX Item "-B (default)" + Use \s-1BSD\s0 output format. Alias for \fB\*(--format=bsd\fR. + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command-line options and their meanings. + .Ip "\fB\*(--defined-only\fR" 4 + .IX Item "defined-only" + Print only symbols defined in this bytecode file (as opposed to + symbols which may be referenced by objects in this file, but not + defined in this file.) + .Ip "\fB\*(--extern-only\fR, \fB\-g\fR" 4 + .IX Item "extern-only, -g" + Print only symbols whose definitions are external; that is, accessible + from other bytecode files. + .Ip "\fB\*(--undefined-only\fR, \fB\-u\fR" 4 + .IX Item "undefined-only, -u" + Print only symbols referenced but not defined in this bytecode file. + .Ip "\fB\*(--format=\fR\fIfmt\fR, \fB\-f\fR" 4 + .IX Item "format=fmt, -f" + Select an output format; \fIfmt\fR may be \fIsysv\fR, \fIposix\fR, or \fIbsd\fR. The + default is \fIbsd\fR. + .SH "BUGS" + .IX Header "BUGS" + \&\fBllvm-nm\fR cannot demangle \*(C+ mangled names, like \s-1GNU\s0 \fBnm\fR can. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + \&\fBllvm-nm\fR exits with an exit code of zero. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvm-dis, \fIar\fR\|(1), \fInm\fR\|(1) + .SH "AUTHOR" + .IX Header "AUTHOR" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-prof.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-prof.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvm-prof.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,183 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVM-PROF 1" + .TH LLVM-PROF 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvm-prof \- print execution profile of \s-1LLVM\s0 program + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvm-prof\fR [\fIoptions\fR] [\fIbytecode file\fR] [\fIllvmprof.out\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvm-prof\fR tool reads in an \fIllvmprof.out\fR file (which can + optionally use a specific file with the third program argument), a bytecode file + for the program, and produces a human readable report, suitable for determining + where the program hotspots are. + .PP + This program is often used in conjunction with the \fIutils/profile.pl\fR + script. This script automatically instruments a program, runs it with the \s-1JIT\s0, + then runs \fBllvm-prof\fR to format a report. To get more information about + \&\fIutils/profile.pl\fR, execute it with the \fB\*(--help\fR option. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\*(--annotated-llvm\fR or \fB\-A\fR" 4 + .IX Item "annotated-llvm or -A" + In addition to the normal report printed, print out the code for the + program, annotated with execution frequency information. This can be + particularly useful when trying to visualize how frequently basic blocks + are executed. This is most useful with basic block profiling + information or better. + .Ip "\fB\*(--print-all-code\fR" 4 + .IX Item "print-all-code" + Using this option enables the \fB\*(--annotated-llvm\fR option, but it + prints the entire module, instead of just the most commonly executed + functions. + .Ip "\fB\*(--time-passes\fR" 4 + .IX Item "time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + \&\fBllvm-prof|llvm-prof\fR returns 1 if it cannot load the bytecode file or the + profile information. Otherwise, it exits with zero. + .SH "AUTHOR" + .IX Header "AUTHOR" + \&\fBllvm-prof\fR is maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvmgcc.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvmgcc.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvmgcc.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,206 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVMGCC 1" + .TH LLVMGCC 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvmgcc \- \s-1LLVM\s0 C front-end + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvmgcc\fR [\fIoptions\fR] \fIfilename\fR + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvmgcc\fR command is the \s-1LLVM\s0 C front end. It is a modified + version of gcc that takes C programs and compiles them into \s-1LLVM\s0 + bytecode or assembly language, depending upon the options. + .PP + Unless the \fB\-S\fR option is specified, \fBllvmgcc\fR will use the + gccas program to perform some optimizations and create an + \&\s-1LLVM\s0 bytecode file. Unless the \fB\-c\fR option is specified, \fBllvmgcc\fR + will also use the gccld program to perform further + optimizations and link the resulting bytecode \fIfile\fR\|(s) with support + libraries to create an executable program. + .PP + Being derived from the \s-1GNU\s0 Compiler Collection, \fBllvmgcc\fR 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. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-S\fR" 4 + .IX Item "-S" + Do not generate an \s-1LLVM\s0 bytecode file. Rather, compile the source + file into an \s-1LLVM\s0 assembly language file. + .Ip "\fB\-c\fR" 4 + .IX Item "-c" + Do not generate a linked executable. Rather, compile the source + file into an \s-1LLVM\s0 bytecode file. This bytecode file can then be + linked with other bytecode files later on to generate a full \s-1LLVM\s0 + executable. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output file to be \fIfilename\fR. + .Ip "\fB\-I\fR \fIdirectory\fR" 4 + .IX Item "-I directory" + Add a directory to the header file search path. This option can be + repeated. + .Ip "\fB\-L\fR \fIdirectory\fR" 4 + .IX Item "-L directory" + Add \fIdirectory\fR to the library search path. This option can be + repeated. + .Ip "\fB\-l\fR\fIname\fR" 4 + .IX Item "-lname" + Link in the library lib\fIname\fR.[bc | a | so]. This library should + be a bytecode library. + .Ip "\fB\-Wl,\fR\fIoption\fR" 4 + .IX Item "-Wl,option" + Pass \fIoption\fR to the linker (usually gccld). + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllvmgcc\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + llvmg++, gccas, gccld + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvmgxx.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvmgxx.1:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/llvmgxx.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,206 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "LLVMGXX 1" + .TH LLVMGXX 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + llvmg++ \- \s-1LLVM\s0 \*(C+ front-end + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBllvmg++\fR [\fIoptions\fR] \fIfilename\fR + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBllvmg++\fR command is the \s-1LLVM\s0 \*(C+ front end. It is a modified + version of g++ that takes \*(C+ programs and compiles them into \s-1LLVM\s0 + bytecode or assembly language, depending upon the options. + .PP + Unless the \fB\-S\fR option is specified, \fBllvmg++\fR will use the + gccas program to perform some optimizations and create an + \&\s-1LLVM\s0 bytecode file. Unless the \fB\-c\fR option is specified, \fBllvmg++\fR + will also use the gccld program to perform further + optimizations and link the resulting bytecode \fIfile\fR\|(s) with support + libraries to create an executable program. + .PP + Being derived from the \s-1GNU\s0 Compiler Collection, \fBllvmg++\fR 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. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\*(--help\fR" 4 + .IX Item "help" + Print a summary of command line options. + .Ip "\fB\-S\fR" 4 + .IX Item "-S" + Do not generate an \s-1LLVM\s0 bytecode file. Rather, compile the source + file into an \s-1LLVM\s0 assembly language file. + .Ip "\fB\-c\fR" 4 + .IX Item "-c" + Do not generate a linked executable. Rather, compile the source + file into an \s-1LLVM\s0 bytecode file. This bytecode file can then be + linked with other bytecode files later on to generate a full \s-1LLVM\s0 + executable. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output file to be \fIfilename\fR. + .Ip "\fB\-I\fR \fIdirectory\fR" 4 + .IX Item "-I directory" + Add a directory to the header file search path. This option can be + repeated. + .Ip "\fB\-L\fR \fIdirectory\fR" 4 + .IX Item "-L directory" + Add \fIdirectory\fR to the library search path. This option can be + repeated. + .Ip "\fB\-l\fR\fIname\fR" 4 + .IX Item "-lname" + Link in the library lib\fIname\fR.[bc | a | so]. This library should + be a bytecode library. + .Ip "\fB\-Wl,\fR\fIoption\fR" 4 + .IX Item "-Wl,option" + Pass \fIoption\fR to the linker (usually gccld). + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBllvmg++\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + the llvmgcc manpage, the gccas manpage, the gccld manpage + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/opt.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/opt.1:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/opt.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,216 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 01:00:17 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "OPT 1" + .TH OPT 1 "1.3" "2004-07-04" "LLVM Command Guide" + .UC + .SH "NAME" + opt \- \s-1LLVM\s0 optimizer + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBopt\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBopt\fR command is the modular \s-1LLVM\s0 optimizer. It takes \s-1LLVM\s0 + bytecode as input, runs the specified optimizations on it, and then + outputs the optimized \s-1LLVM\s0 bytecode. + .PP + The optimizations available via \fBopt\fR depend upon what libraries + were linked into it as well as any additional libraries that have + been loaded with the \fB\-load\fR option. Use the \fB\-help\fR option to + determine what optimizations you can use. + .PP + If no filename is specified on the command line, \fBopt\fR reads its + input from standard input. + .PP + If an output filename is not specified with the \fB\-o\fR option, \fBopt\fR + writes its output to the standard output. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Force overwrite. Normally, \fBopt\fR will refuse to overwrite an + output file that already exists. With this option, \fBopt\fR will + overwrite the output file and replace it with new bytecode. + .Ip "\fB\-help\fR" 4 + .IX Item "-help" + Print a summary of command line options. + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output filename. + .Ip "\fB\-profile-info-file\fR \fIfilename\fR" 4 + .IX Item "-profile-info-file filename" + Specify the name of the file loaded by the \-profile-loader option. + .Ip "\fB\-stats\fR" 4 + .IX Item "-stats" + Print statistics. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .Ip "\fB\-debug\fR" 4 + .IX Item "-debug" + If this is a debug build, this option will enable debug printouts + from passes which use the \fI\fIDEBUG()\fI\fR macro. See the \fB\s-1LLVM\s0 Programmer's + Manual\fR, section \fI#DEBUG\fR for more information. + .Ip "\fB\-load\fR=\fIplugin\fR" 4 + .IX Item "-load=plugin" + Load the dynamic object \fIplugin\fR. This object should register new + optimization passes. Once loaded, the object will add new command line + options to enable various optimizations. To see the new complete list + of optimizations, use the \fB\-help\fR and \fB\-load\fR options together: + .RS 4 + .Sp + \&\fBopt \-load\fR=\fIplugin\fR \fB\-help\fR + .RE + .RS 4 + .RE + .Ip "\fB\-p\fR" 4 + .IX Item "-p" + Print module after each transformation. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBopt\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + analyze + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/stkrc.1 diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/stkrc.1:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/stkrc.1 Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,207 ---- + .\" Automatically generated by Pod::Man version 1.15 + .\" Sat Jul 10 16:42:51 2004 + .\" + .\" Standard preamble: + .\" ====================================================================== + .de Sh \" Subsection heading + .br + .if t .Sp + .ne 5 + .PP + \fB\\$1\fR + .PP + .. + .de Sp \" Vertical space (when we can't use .PP) + .if t .sp .5v + .if n .sp + .. + .de Ip \" List item + .br + .ie \\n(.$>=3 .ne \\$3 + .el .ne 3 + .IP "\\$1" \\$2 + .. + .de Vb \" Begin verbatim text + .ft CW + .nf + .ne \\$1 + .. + .de Ve \" End verbatim text + .ft R + + .fi + .. + .\" Set up some character translations and predefined strings. \*(-- will + .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left + .\" double quote, and \*(R" will give a right double quote. | will give a + .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used + .\" to do unbreakable dashes and therefore won't be available. \*(C` and + .\" \*(C' expand to `' in nroff, nothing in troff, for use with C<> + .tr \(*W-|\(bv\*(Tr + .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' + .ie n \{\ + . ds -- \(*W- + . ds PI pi + . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch + . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch + . ds L" "" + . ds R" "" + . ds C` "" + . ds C' "" + 'br\} + .el\{\ + . ds -- \|\(em\| + . ds PI \(*p + . ds L" `` + . ds R" '' + 'br\} + .\" + .\" If the F register is turned on, we'll generate index entries on stderr + .\" for titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and + .\" index entries marked with X<> in POD. Of course, you'll have to process + .\" the output yourself in some meaningful fashion. + .if \nF \{\ + . de IX + . tm Index:\\$1\t\\n%\t"\\$2" + .. + . nr % 0 + . rr F + .\} + .\" + .\" For nroff, turn off justification. Always turn off hyphenation; it + .\" makes way too many mistakes in technical documents. + .hy 0 + .if n .na + .\" + .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). + .\" Fear. Run. Save yourself. No user-serviceable parts. + .bd B 3 + . \" fudge factors for nroff and troff + .if n \{\ + . ds #H 0 + . ds #V .8m + . ds #F .3m + . ds #[ \f1 + . ds #] \fP + .\} + .if t \{\ + . ds #H ((1u-(\\\\n(.fu%2u))*.13m) + . ds #V .6m + . ds #F 0 + . ds #[ \& + . ds #] \& + .\} + . \" simple accents for nroff and troff + .if n \{\ + . ds ' \& + . ds ` \& + . ds ^ \& + . ds , \& + . ds ~ ~ + . ds / + .\} + .if t \{\ + . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" + . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' + . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' + . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' + . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' + . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' + .\} + . \" troff and (daisy-wheel) nroff accents + .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' + .ds 8 \h'\*(#H'\(*b\h'-\*(#H' + .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] + .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' + .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' + .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] + .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] + .ds ae a\h'-(\w'a'u*4/10)'e + .ds Ae A\h'-(\w'A'u*4/10)'E + . \" corrections for vroff + .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' + .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' + . \" for low resolution devices (crt and lpr) + .if \n(.H>23 .if \n(.V>19 \ + \{\ + . ds : e + . ds 8 ss + . ds o a + . ds d- d\h'-1'\(ga + . ds D- D\h'-1'\(hy + . ds th \o'bp' + . ds Th \o'LP' + . ds ae ae + . ds Ae AE + .\} + .rm #[ #] #H #V #F C + .\" ====================================================================== + .\" + .IX Title "STKRC 1" + .TH STKRC 1 "1.3" "2004-07-10" "LLVM Command Guide" + .UC + .SH "NAME" + stkrc \- Stacker Compiler + .SH "SYNOPSIS" + .IX Header "SYNOPSIS" + \&\fBstkrc\fR [\fIoptions\fR] [\fIfilename\fR] + .SH "DESCRIPTION" + .IX Header "DESCRIPTION" + The \fBstkrc\fR command is the compiler for the Stacker language. Stacker is a + simple stack based, Forth-like language that was written as a demonstration + language for \s-1LLVM\s0. For details on the language, please see + http://llvm.cs.uiuc.edu/docs/Stacker.html . The \fBstkrc\fR compiler is fairly + minimal. It compiles to bytecode only and doesn't perform any optimizations. + The output of stkrc (a bytecode file) can be piped through other \s-1LLVM\s0 tools + for optimization and linking. + .PP + If \fIfilename\fR is omitted or is \f(CW\*(C`\-\*(C'\fR, then \fBstkrc\fR reads its input + from standard input. This is useful for combining the tool into a pipeline. + .PP + If an output file is not specified with the \fB\-o\fR option, then + \&\fBllvm-as\fR sends its output to a file or standard output by following + these rules: + .Ip "\(bu" 4 + If the input is standard input, then the output is standard output. + .Ip "\(bu" 4 + If the input is a file that ends with \f(CW\*(C`.st\*(C'\fR, then the output file is of + the same name, except that the suffix is changed to \f(CW\*(C`.bc\*(C'\fR. + .Ip "\(bu" 4 + If the input is a file that does not end with the \f(CW\*(C`.st\*(C'\fR suffix, then the + output file has the same name as the input file, except that the \f(CW\*(C`.bc\*(C'\fR + suffix is appended. + .SH "OPTIONS" + .IX Header "OPTIONS" + .Ip "\fB\-o\fR \fIfilename\fR" 4 + .IX Item "-o filename" + Specify the output file name. If \fIfilename\fR is \f(CW\*(C`\-\*(C'\fR, then \fBllvm-as\fR + sends its output to standard output. + .Ip "\fB\-stats\fR" 4 + .IX Item "-stats" + Print statistics acquired during compilation. + .Ip "\fB\-time-passes\fR" 4 + .IX Item "-time-passes" + Record the amount of time needed for each pass and print it to standard + error. + .Ip "\fB\-f\fR" 4 + .IX Item "-f" + Force the output to be written. Normally, \fBstkrc\fR won't overwrite an existing + bytecode file. This option overrides that behavior. + .Ip "\fB\-s=stacksize\fR" 4 + .IX Item "-s=stacksize" + Specify the stack size for the program. The default stack size, 1024, should be + sufficient for most programs. For very large, programs, you might want to + provide a larger value. + .Ip "\fB\-help\fR" 4 + .IX Item "-help" + Print a summary of command line options. + .SH "EXIT STATUS" + .IX Header "EXIT STATUS" + If \fBstkrc\fR succeeds, it will exit with 0. Otherwise, if an error + occurs, it will exit with a non-zero value, usually 1. + .SH "SEE ALSO" + .IX Header "SEE ALSO" + the llvm-as manpage, http://llvm.cs.uiuc.edu/docs/Stacker.html + .SH "AUTHORS" + .IX Header "AUTHORS" + Maintained by the \s-1LLVM\s0 Team (http://llvm.cs.uiuc.edu). From lattner at cs.uiuc.edu Tue Nov 8 14:07:56 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:07:56 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/ps/analyze.ps bugpoint.ps extract.ps gccas.ps gccld.ps llc.ps lli.ps llvm-as.ps llvm-bcanalyzer.ps llvm-db.ps llvm-dis.ps llvm-link.ps llvm-nm.ps llvm-prof.ps llvmgcc.ps llvmgxx.ps opt.ps stkrc.ps Message-ID: <200511082007.OAA30621@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/ps: analyze.ps added (r1.1) bugpoint.ps added (r1.1) extract.ps added (r1.1) gccas.ps added (r1.1) gccld.ps added (r1.1) llc.ps added (r1.1) lli.ps added (r1.1) llvm-as.ps added (r1.1) llvm-bcanalyzer.ps added (r1.1) llvm-db.ps added (r1.1) llvm-dis.ps added (r1.1) llvm-link.ps added (r1.1) llvm-nm.ps added (r1.1) llvm-prof.ps added (r1.1) llvmgcc.ps added (r1.1) llvmgxx.ps added (r1.1) opt.ps added (r1.1) stkrc.ps added (r1.1) --- Log message: check in 1.6 docs --- Diffs of the changes: (+5849 -0) analyze.ps | 288 ++++++++++++++++++++++ bugpoint.ps | 664 +++++++++++++++++++++++++++++++++++++++++++++++++++++ extract.ps | 286 ++++++++++++++++++++++ gccas.ps | 277 ++++++++++++++++++++++ gccld.ps | 441 +++++++++++++++++++++++++++++++++++ llc.ps | 382 ++++++++++++++++++++++++++++++ lli.ps | 294 +++++++++++++++++++++++ llvm-as.ps | 290 +++++++++++++++++++++++ llvm-bcanalyzer.ps | 302 ++++++++++++++++++++++++ llvm-db.ps | 220 +++++++++++++++++ llvm-dis.ps | 282 ++++++++++++++++++++++ llvm-link.ps | 301 ++++++++++++++++++++++++ llvm-nm.ps | 328 ++++++++++++++++++++++++++ llvm-prof.ps | 287 ++++++++++++++++++++++ llvmgcc.ps | 295 +++++++++++++++++++++++ llvmgxx.ps | 298 +++++++++++++++++++++++ opt.ps | 308 ++++++++++++++++++++++++ stkrc.ps | 306 ++++++++++++++++++++++++ 18 files changed, 5849 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/ps/analyze.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/analyze.ps:1.1 *** /dev/null Tue Nov 8 14:07:55 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/analyze.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,288 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(AN)72 48 Q(AL)-.35 E 124.76(YZE\(1\) LL)-1 F + (VM Command Guide)-1 E(AN)127.26 E(AL)-.35 E(YZE\(1\))-1 E/F1 10.95 + /Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302 + (EE)10.335 G F0(analyze \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM) + -.9 E F0(program analyzer)2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 + G -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 + G -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -4.998(aa) + 108 124.8 S -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G -4.998 + (yy)2.778 G -4.438(zz)4.998 G -4.438(ee)4.438 G F0([)6.938 E/F4 10 + /Times-Italic at 0 SF(options)A F0 2.5(][)C F4(\214lename)-2.5 E F0(])A F1 + -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G -7.904(CC)6.086 + G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G -7.302(TT)6.688 + G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G F0(The)108 153.6 + Q F3 -4.998(aa)2.624 G -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778(ll) + 4.998 G -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee)4.438 G F0 .124 + (command performs v)7.062 F .124(arious analysis of)-.25 F F2(LL)2.624 E + (VM)-.9 E F0 .124(assembly code or bytecode.)2.624 F .124 + (It will usually print)5.124 F .106(the results on standard output, b) + 108 165.6 R .106(ut in a fe)-.2 F 2.606(wc)-.25 G .106 + (ases, it will print output to standard error or generate a \214le with) + -2.606 F(the analysis output, which is usually done when the output is \ + meant for another program.)108 177.6 Q .866 + (If \214lename is omitted or is)108 194.4 R F4(-)3.366 E F0(,)A F3 + -4.998(aa)3.366 G -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G + -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee)4.438 G F0 .866 + (reads its input from standard input.)7.804 F .865 + (It \214rst attempts to interpret its)5.865 F .968(input as)108 206.4 R + F2(LL)3.468 E(VM)-.9 E F0 3.468(bytecode. If)3.468 F .968 + (it encounters an error)3.468 F 3.468(,i)-.4 G 3.468(tt)-3.468 G .968 + (hen attempts to parse the input as)-3.468 F F2(LL)3.469 E(VM)-.9 E F0 + (assembly)3.469 E(language.)108 218.4 Q F1 -8.517(OO)72 235.2 S -6.688 + (PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904 + (NN)8.517 G -6.086(SS)7.904 G F3 -5.698108 247.2 S -5.558(hh)5.698 + G -4.438(ee)5.558 G -2.778(ll)4.438 G -5.558(pp)2.778 G F0 + (Print a summary of command line options.)128 259.2 Q F3 -5.698108 + 276 S -5.558(qq)5.698 G F0(Quiet mode.)14.294 E -.4(Wi)5 G + (th this option, analysis pass names are not printed.).4 E F3 -5.698 + 108 292.8 S -2.778(ll)5.698 G -4.998(oo)2.778 G -4.998(aa)4.998 G + -5.558(dd)4.998 G F4(plugin)8.058 E F0 1.801 + (Load the speci\214ed dynamic object with name)128 304.8 R F4(plugin) + 4.301 E F0 6.801(.T)C 1.8(his \214le should contain additional analysis) + -6.801 F(passes that re)128 316.8 Q(gister themselv)-.15 E(es with the) + -.15 E F3 -4.998(aa)2.5 G -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778(ll) + 4.998 G -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee)4.438 G F0 + (program after being loaded.)6.938 E .636 + (After being loaded, additional command line options are made a)128 + 334.8 R -.25(va)-.2 G .637(ilable for running the passes made).25 F -.2 + (av)128 346.8 S(ailable by)-.05 E F4(plugin)2.5 E F0 5(.U)C(se)-5 E F3 + -4.998(aa)2.5 G -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G + -4.998(yy)2.778 G -4.438(zz)4.998 G 8.876 -4.438(ee \255)4.438 H + -1.26 E(lo)-2.778 E(oa)-4.998 E(ad)-4.998 E(d)-5.558 E F4(plugin)2.5 E + F3 -5.6982.5 G -5.558(hh)5.698 G -4.438(ee)5.558 G -2.778(ll)4.438 + G -5.558(pp)2.778 G F0(to see the ne)8.058 E 2.5(wl)-.25 G(ist of a)-2.5 + E -.25(va)-.2 G(ilable analysis passes.).25 E F3 -5.698108 363.6 S + -5.558(pp)5.698 G 6.196 -4.438(rr o)5.558 H<6f8c>-.56 E<8c6c>-5.558 E + (le)-2.778 E(e-)-4.438 E(-i)-3.328 E(in)-2.778 E(nf)-5.558 E -.25(fo) + -3.328 G(o-)-4.748 E<2d8c>-3.328 E<8c6c>-5.558 E(le)-2.778 E(e)-4.438 E + F4(\214lename)2.5 E F0(Specify the name of the \214le loaded by the \ + \255pro\214le-loader option.)128 375.6 Q F3 -5.698108 392.4 S + -3.888(ss)5.698 G -3.328(tt)3.888 G -4.998(aa)3.328 G -3.328(tt)4.998 G + -3.888(ss)3.328 G F0(Print statistics.)128 404.4 Q F3 -5.698108 + 421.2 S -3.328(tt)5.698 G -2.778(ii)3.328 G -8.328(mm)2.778 G -4.438(ee) + 8.328 G -3.328(--)4.438 G -5.558(pp)3.328 G -4.998(aa)5.558 G -3.888(ss) + 4.998 G -3.888(ss)3.888 G -4.438(ee)3.888 G -3.888(ss)4.438 G F0(Record\ + the amount of time needed for each pass and print it to standard error) + 128 433.2 Q(.)-.55 E F1 -7.302(EE)72 450 S -7.904(XX)7.302 G -4.258(II) + 7.904 G 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 G -1.04 + (AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F0(If)108 462 Q F3 + -4.998(aa)2.5 G -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G + -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee)4.438 G F0 + (succeeds, it will e)6.938 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 478.8 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0(opt)108 + 490.8 Q F1 12.522 -7.904(AA UU)72 507.6 T -7.302(TT)7.904 G -8.517(HH) + 7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 519.6 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/bugpoint.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/bugpoint.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/bugpoint.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,664 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%+ font Symbol + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 3 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + %%IncludeResource: font Symbol + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF -.1(BU)72 48 S 120.17(GPOINT\(1\) LL).1 F + (VM Command Guide)-1 E -.1(BU)122.67 G(GPOINT\(1\)).1 E/F1 10.95 + /Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302 + (EE)10.335 G F0 -.2(bu)108 96 S + (gpoint \255 automatic test case reduction tool).2 E F1 -6.086(SS)72 + 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP) + 8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 G/F2 10 + /Times-Bold at 0 SF 8.416 -5.558(bb uu)108 124.8 T -4.998(gg)5.558 G -5.558 + (pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328 + (tt)5.558 G F0([)5.828 E/F3 10/Times-Italic at 0 SF(options)A F0 2.5(][)C + F3(input)-2.5 E/F4 9/Times-Italic at 0 SF(LL)2.5 E(VM)-.495 E F3 + (ll/bc \214les)2.5 E F0 2.5(][)C F4(LL)-2.5 E(VM)-.495 E F3(passes)2.5 E + F0(])A F2 19.162 -9.998<8a8a2061>4.166 H(ar)5 E -.1(rg)-4.438 G(gs) + -4.898 E(s)-3.888 E F3(pr)2.5 E -.1(og)-.45 G -.15(ra).1 G 2.5(ma).15 G + -.37(rg)-2.5 G(uments).37 E F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G + -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G + -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G F2 8.416 -5.558(bb uu)108 153.6 T -4.998(gg)5.558 G + -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G + -3.328(tt)5.558 G F0(narro)6.631 E .803(ws do)-.25 F .803 + (wn the source of problems in)-.25 F/F5 9/Times-Roman at 0 SF(LL)3.303 E + (VM)-.9 E F0 .803(tools and passes.)3.303 F .802(It can be used to deb) + 5.802 F .802(ug three)-.2 F .517(types of f)108 165.6 R .518 + (ailures: optimizer crashes, miscompilations by optimizers, or bad nati) + -.1 F .818 -.15(ve c)-.25 H .518(ode generation \(includ-).15 F .605 + (ing problems in the static and)108 177.6 R F5(JIT)3.105 E F0 3.105 + (compilers\). It)3.105 F .605(aims to reduce lar)3.105 F .605 + (ge test cases to small, useful ones.)-.18 F -.15(Fo)5.604 G(r).15 E + -.15(ex)108 189.6 S .517(ample, if).15 F F2 -4.998(gg)3.017 G -4.438(cc) + 4.998 G -4.438(cc)4.438 G -4.998(aa)4.438 G -3.888(ss)4.998 G F0 .518(c\ + rashes while optimizing a \214le, it will identify the optimization \(o\ + r combination of opti-)6.905 F + (mizations\) that causes the crash, and reduce the \214le do)108 201.6 Q + (wn to a small e)-.25 E(xample which triggers the crash.)-.15 E F2 + -7.218(DD)108 224.4 S -4.438(ee)7.218 G -3.888(ss)4.438 G -2.778(ii) + 3.888 G -4.998(gg)2.778 G 11.116 -5.558(nn P)4.998 H(Ph)-.55 E(hi)-5.558 + E(il)-2.778 E(lo)-2.778 E(os)-4.998 E(so)-3.888 E(op)-4.998 E(ph)-5.558 + E -.15(hy)-5.558 G(y)-4.848 E 8.416 -5.558(bb uu)108 241.2 T -4.998(gg) + 5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn) + 2.778 G -3.328(tt)5.558 G F0 .277 + (is designed to be a useful tool without requiring an)6.105 F 2.776(yh) + -.15 G .276(ooks into the)-2.776 F F5(LL)2.776 E(VM)-.9 E F0 .276 + (infrastructure at all.)2.776 F(It)5.276 E -.1(wo)108 253.2 S .862 + (rks with an).1 F 3.362(ya)-.15 G .862(nd all)-3.362 F F5(LL)3.362 E(VM) + -.9 E F0 .862(passes and code generators, and does not need to `)3.362 F + (`kno)-.74 E(w')-.25 E 3.363('h)-.74 G 1.363 -.25(ow t)-3.363 H(he).25 E + 3.363(yw)-.15 G(ork.)-3.463 E 2.141 + (Because of this, it may appear to do stupid things or miss ob)108 265.2 + R 2.141(vious simpli\214cations.)-.15 F F2 8.416 -5.558(bb uu)7.141 H + -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G + -5.558(nn)2.778 G -3.328(tt)5.558 G F0 2.14(is also)7.968 F .173 + (designed to trade of)108 277.2 R 2.674(fp)-.25 G .174 + (rogrammer time for computer time in the compiler)-2.674 F(-deb)-.2 E + .174(ugging process; consequently)-.2 F(,)-.65 E .264(it may tak)108 + 289.2 R 2.764(eal)-.1 G .264 + (ong period of \(unattended\) time to reduce a test case, b)-2.764 F + .264(ut we feel it is still w)-.2 F .263(orth it. Note that)-.1 F F2 + 8.416 -5.558(bb uu)108 301.2 T -4.998(gg)5.558 G -5.558(pp)4.998 G + -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G + F0 .005(is generally v)5.833 F .005(ery quick unless deb)-.15 F .006 + (ugging a miscompilation where each test of the program \(which)-.2 F + (requires e)108 313.2 Q -.15(xe)-.15 G(cuting it\) tak).15 E + (es a long time.)-.1 E F2 11.436 -7.218(AA u)108 336 T(ut)1.66 E(to) + -3.328 E(om)-4.998 E(ma)-8.328 E(at)-4.998 E(ti)-3.328 E(ic)-2.778 E 2.5 + (cD)-4.438 G(De)-9.718 E(eb)-4.438 E -.2(bu)-5.558 G(ug)-5.358 E(gg) + -4.998 E(ge)-4.998 E(er)-4.438 E 2.5(rS)-4.438 G(Se)-8.058 E(el)-4.438 E + (le)-2.778 E(ec)-4.438 E(ct)-4.438 E(ti)-3.328 E(io)-2.778 E(on)-4.998 E + (n)-5.558 E 8.416 -5.558(bb uu)108 352.8 T -4.998(gg)5.558 G -5.558(pp) + 4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt) + 5.558 G F0 .102(reads each)5.93 F F3(.bc)2.602 E F0(or)2.602 E F3(.ll) + 2.602 E F0 .102(\214le speci\214ed on the command line and links them t\ + ogether into a single mod-)2.602 F .211(ule, called the test program.) + 108 364.8 R .211(If an)5.211 F(y)-.15 E F5(LL)2.711 E(VM)-.9 E F0 .211 + (passes are speci\214ed on the command line, it runs these passes on) + 2.711 F .188(the test program.)108 376.8 R .188(If an)5.188 F 2.688(yo) + -.15 G 2.688(ft)-2.688 G .188(he passes crash, or if the)-2.688 F 2.688 + (yp)-.15 G .187(roduce malformed output \(which causes the v)-2.688 F + (eri\214er)-.15 E(to abort\),)108 388.8 Q F2 8.416 -5.558(bb uu)2.5 H + -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G + -5.558(nn)2.778 G -3.328(tt)5.558 G F0(starts the crash deb)5.828 E + (ugger)-.2 E(.)-.55 E 1.181(Otherwise, if the)108 405.6 R F2 -5.698 + 3.682 G -4.998(oo)5.698 G -5.558(uu)4.998 G -3.328(tt)5.558 G + -5.558(pp)3.328 G -5.558(uu)5.558 G -3.328(tt)5.558 G F0 1.182(option w) + 7.01 F 1.182(as not speci\214ed,)-.1 F F2 8.416 -5.558(bb uu)3.682 H + -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G + -5.558(nn)2.778 G -3.328(tt)5.558 G F0 1.182 + (runs the test program with the C back)7.01 F(end)-.1 E .7(\(which is a\ + ssumed to generate good code\) to generate a reference output.)108 417.6 + R(Once)5.699 E F2 8.416 -5.558(bb uu)3.199 H -4.998(gg)5.558 G -5.558 + (pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328 + (tt)5.558 G F0 .699(has a reference)6.527 F .097 + (output for the test program, it tries e)108 429.6 R -.15(xe)-.15 G .098 + (cuting it with the selected code generator).15 F 5.098(.I)-.55 G 2.598 + (ft)-5.098 G .098(he selected code gener)-2.598 F(-)-.2 E .465 + (ator crashes,)108 441.6 R F2 8.416 -5.558(bb uu)2.965 H -4.998(gg)5.558 + G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 + G -3.328(tt)5.558 G F0 .465(starts the the Crash deb)6.293 F .465 + (ugger entry else)-.2 F .464(where in this document on the code genera-) + -.25 F(tor)108 453.6 Q 5.709(.O)-.55 G .709 + (therwise, if the resulting output dif)-5.709 F .709 + (fers from the reference output, it assumes the dif)-.25 F .71 + (ference resulted)-.25 F .167(from a code generator f)108 465.6 R .166 + (ailure, and starts the the Code generator deb)-.1 F .166 + (ugger entry else)-.2 F .166(where in this document.)-.25 F(Finally)108 + 482.4 Q 3.549(,i)-.65 G 3.549(ft)-3.549 G 1.049 + (he output of the selected code generator matches the reference output,) + -3.549 F F2 8.416 -5.558(bb uu)3.549 H -4.998(gg)5.558 G -5.558(pp)4.998 + G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 + G F0 1.049(runs the test)6.877 F .105(program after all of the)108 494.4 + R F5(LL)2.605 E(VM)-.9 E F0 .105(passes ha)2.605 F .404 -.15(ve b)-.2 H + .104(een applied to it.).15 F .104(If its output dif)5.104 F .104 + (fers from the reference output,)-.25 F .493(it assumes the dif)108 + 506.4 R .493(ference resulted from a f)-.25 F .493(ailure in one of the) + -.1 F F5(LL)2.993 E(VM)-.9 E F0 .493 + (passes, and enters the miscompilation)2.993 F(deb)108 518.4 Q(ugger)-.2 + E 2.5(.O)-.55 G(therwise, there is no problem)-2.5 E F2 8.416 -5.558 + (bb uu)2.5 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G + -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0(can deb)5.828 E + (ug.)-.2 E F2 -7.218(CC)108 541.2 S -4.438(rr)7.218 G -4.998(aa)4.438 G + -3.888(ss)4.998 G 11.116 -5.558(hh dd)3.888 H -4.438(ee)5.558 G 8.416 + -5.558(bb uu)4.438 H -4.998(gg)5.558 G -4.998(gg)4.998 G -4.438(ee)4.998 + G -4.438(rr)4.438 G F0 .082(If an optimizer or code generator crashes,) + 108 558 R F2 8.416 -5.558(bb uu)2.582 H -4.998(gg)5.558 G -5.558(pp) + 4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt) + 5.558 G F0 .081 + (will try as hard as it can to reduce the list of passes \(for)5.91 F + .294(optimizer crashes\) and the size of the test program.)108 570 R + (First,)5.295 E F2 8.416 -5.558(bb uu)2.795 H -4.998(gg)5.558 G -5.558 + (pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328 + (tt)5.558 G F0 .295(\214gures out which combination of opti-)6.123 F + 1.093(mizer passes triggers the b)108 582 R 1.093 + (ug. This is useful when deb)-.2 F 1.092(ugging a problem e)-.2 F 1.092 + (xposed by)-.15 F F2 -4.998(gg)3.592 G -4.438(cc)4.998 G -4.438(cc)4.438 + G -4.998(aa)4.438 G -3.888(ss)4.998 G F0 3.592(,f)3.888 G 1.092(or e) + -3.592 F(xample,)-.15 E(because it runs o)108 594 Q -.15(ve)-.15 G 2.5 + (r3).15 G 2.5(8p)-2.5 G(asses.)-2.5 E(Ne)108 610.8 Q(xt,)-.15 E F2 8.416 + -5.558(bb uu)3.84 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 + G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 1.34 + (tries remo)7.168 F 1.34 + (ving functions from the test program, to reduce its size.)-.15 F 1.341 + (Usually it is able to)6.34 F .539 + (reduce a test program to a single function, when deb)108 622.8 R .539 + (ugging intraprocedural optimizations.)-.2 F .539(Once the num-)5.539 F + .76(ber of functions has been reduced, it attempts to delete v)108 634.8 + R .761(arious edges in the control \215o)-.25 F 3.261(wg)-.25 G .761 + (raph, to reduce)-3.261 F .947 + (the size of the function as much as possible.)108 646.8 R(Finally)5.946 + E(,)-.65 E F2 8.416 -5.558(bb uu)3.446 H -4.998(gg)5.558 G -5.558(pp) + 4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt) + 5.558 G F0 .946(deletes an)6.774 F 3.446(yi)-.15 G(ndi)-3.446 E(vidual) + -.25 E F5(LL)3.446 E(VM)-.9 E F0(instructions)3.446 E .209 + (whose absence does not eliminate the f)108 658.8 R 2.71(ailure. At)-.1 + F .21(the end,)2.71 F F2 8.416 -5.558(bb uu)2.71 H -4.998(gg)5.558 G + -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G + -3.328(tt)5.558 G F0 .21(should tell you what passes crash, gi)6.038 F + -.15(ve)-.25 G(you a bytecode \214le, and gi)108 670.8 Q .3 -.15(ve y) + -.25 H(ou instructions on ho).15 E 2.5(wt)-.25 G 2.5(or)-2.5 G + (eproduce the f)-2.5 E(ailure with)-.1 E F2 -4.998(oo)2.5 G -5.558(pp) + 4.998 G -3.328(tt)5.558 G F0(,)3.328 E F2 -4.998(aa)2.5 G -5.558(nn) + 4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz) + 4.998 G -4.438(ee)4.438 G F0 2.5(,o)4.438 G(r)-2.5 E F2 -2.778(ll)2.5 G + -2.778(ll)2.778 G -4.438(cc)2.778 G F0(.)4.438 E 178.59(2004-07-04 1.3) + 72 768 R(1)222.75 E EP + %%Page: 2 2 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF -.1(BU)72 48 S 120.17(GPOINT\(1\) LL).1 F + (VM Command Guide)-1 E -.1(BU)122.67 G(GPOINT\(1\)).1 E/F1 10 + /Times-Bold at 0 SF -7.218(CC)108 84 S -4.998(oo)7.218 G -5.558(dd)4.998 G + 8.876 -4.438(ee g)5.558 H(ge)-.56 E(en)-4.438 E(ne)-5.558 E(er)-4.438 E + (ra)-4.438 E(at)-4.998 E(to)-3.328 E(or)-4.998 E 2.5(rd)-4.438 G(de) + -8.058 E(eb)-4.438 E -.2(bu)-5.558 G(ug)-5.358 E(gg)-4.998 E(ge)-4.998 E + (er)-4.438 E(r)-4.438 E F0 .082(The code generator deb)108 100.8 R .081 + (ugger attempts to narro)-.2 F 2.581(wd)-.25 G -.25(ow)-2.581 G 2.581 + (nt).25 G .081(he amount of code that is being miscompiled by the)-2.581 + F 1.049(selected code generator)108 112.8 R 6.049(.T)-.55 G 3.549(od) + -6.849 G 3.549(ot)-3.549 G 1.049(his, it tak)-3.549 F 1.05 + (es the test program and partitions it into tw)-.1 F 3.55(op)-.1 G 1.05 + (ieces: one piece)-3.55 F .217(which it compiles with the C back)108 + 124.8 R .217(end \(into a shared object\), and one piece which it runs \ + with either the)-.1 F/F2 9/Times-Roman at 0 SF(JIT)2.716 E F0 1.24 + (or the static compiler \()108 136.8 R F1 -2.778(ll)C -2.778(ll)2.778 G + -4.438(cc)2.778 G F0 3.74(\). It)4.438 F 1.24(uses se)3.74 F -.15(ve) + -.25 G 1.24 + (ral techniques to reduce the amount of code pushed through the).15 F F2 + (LL)108 148.8 Q(VM)-.9 E F0 .566(code generator)3.066 F 3.066(,t)-.4 G + 3.066(or)-3.066 G .566(educe the potential scope of the problem.)-3.066 + F .565(After it is \214nished, it emits tw)5.566 F 3.065(ob)-.1 G(yte-) + -3.065 E .775(code \214les \(called `)108 160.8 R(`test')-.74 E 3.275 + ('[)-.74 G .775(to be compiled with the code generator] and `)-3.275 F + (`safe')-.74 E 3.275('[)-.74 G .775(to be compiled with the C)-3.275 F + (back)108 172.8 Q 2.806(end], respecti)-.1 F -.15(ve)-.25 G 2.806 + (ly\), and instructions for reproducing the problem.).15 F 2.805 + (The code generator deb)7.805 F(ugger)-.2 E(assumes that the C back)108 + 184.8 Q(end produces good code.)-.1 E F1 -9.438(MM)108 207.6 S -2.778 + (ii)9.438 G -3.888(ss)2.778 G -4.438(cc)3.888 G -4.998(oo)4.438 G -8.328 + (mm)4.998 G -5.558(pp)8.328 G -2.778(ii)5.558 G -2.778(ll)2.778 G -4.998 + (aa)2.778 G -3.328(tt)4.998 G -2.778(ii)3.328 G -4.998(oo)2.778 G 11.116 + -5.558(nn dd)4.998 H -4.438(ee)5.558 G 8.416 -5.558(bb uu)4.438 H -4.998 + (gg)5.558 G -4.998(gg)4.998 G -4.438(ee)4.998 G -4.438(rr)4.438 G F0 + .157(The miscompilation deb)108 224.4 R .157(ugger w)-.2 F .157 + (orks similarly to the code generator deb)-.1 F(ugger)-.2 E 5.157(.I) + -.55 G 2.658(tw)-5.157 G .158(orks by splitting the test)-2.758 F 1.465 + (program into tw)108 236.4 R 3.965(op)-.1 G 1.465(ieces, running the op\ + timizations speci\214ed on one piece, linking the tw)-3.965 F 3.964(op) + -.1 G 1.464(ieces back)-3.964 F(together)108 248.4 Q 3.533(,a)-.4 G + 1.033(nd then e)-3.533 F -.15(xe)-.15 G 1.033(cuting the result.).15 F + 1.033(It attempts to narro)6.033 F 3.533(wd)-.25 G -.25(ow)-3.533 G + 3.533(nt).25 G 1.033(he list of passes to the one \(or fe)-3.533 F(w\)) + -.25 E .389(which are causing the miscompilation, then reduce the porti\ + on of the test program which is being miscom-)108 260.4 R 2.5 + (piled. The)108 272.4 R(miscompilation deb)2.5 E + (ugger assumes that the selected code generator is w)-.2 E + (orking properly)-.1 E(.)-.65 E F1 -7.218(AA)108 295.2 S -5.558(dd)7.218 + G -4.998(vv)5.558 G -2.778(ii)4.998 G -4.438(cc)2.778 G 8.876 -4.438 + (ee f)4.438 H -.25(fo)1.11 G(or)-4.748 E 2.5(ru)-4.438 G(us)-8.058 E(si) + -3.888 E(in)-2.778 E(ng)-5.558 E 2.5(gb)-4.998 G -.2(bu)-8.058 G(ug) + -5.358 E(gp)-4.998 E(po)-5.558 E(oi)-4.998 E(in)-2.778 E(nt)-5.558 E(t) + -3.328 E 8.416 -5.558(bb uu)108 312 T -4.998(gg)5.558 G -5.558(pp)4.998 + G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 + G F0 1.059(can be a remarkably useful tool, b)6.887 F 1.059 + (ut it sometimes w)-.2 F 1.059(orks in non-ob)-.1 F 1.059(vious w)-.15 F + 3.559(ays. Here)-.1 F 1.059(are some)3.559 F(hints and tips:)108 324 Q + 16.5<8349>108 340.8 S 3.491(nt)-16.5 G .991 + (he code generator and miscompilation deb)-3.491 F(uggers,)-.2 E F1 + 8.416 -5.558(bb uu)3.49 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo) + 5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .99 + (only w)6.818 F .99(orks with programs that ha)-.1 F -.15(ve)-.2 G .595 + (deterministic output.)128 352.8 R .595(Thus, if the program outputs) + 5.595 F/F3 10/Courier at 0 SF(argv[0])3.096 E F0 3.096(,t)C .596 + (he date, time, or an)-3.096 F 3.096(yo)-.15 G .596(ther `)-3.096 F + (`random')-.74 E(')-.74 E(data,)128 364.8 Q F1 8.416 -5.558(bb uu)2.814 + H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 + G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .314(may misinterpret dif)6.142 + F .313 + (ferences in these data, when output, as the result of a miscompila-) + -.25 F 3.342(tion. Programs)128 376.8 R .842 + (should be temporarily modi\214ed to disable outputs that are lik)3.342 + F .843(ely to v)-.1 F .843(ary from run to)-.25 F(run.)128 388.8 Q 16.5 + <8349>108 405.6 S 2.703(nt)-16.5 G .202 + (he code generator and miscompilation deb)-2.703 F .202(uggers, deb)-.2 + F .202(ugging will go f)-.2 F .202(aster if you manually modify)-.1 F + (the program or its inputs to reduce the runtime, b)128 417.6 Q + (ut still e)-.2 E(xhibit the problem.)-.15 E<83>108 434.4 Q F1 8.416 + -5.558(bb uu)16.5 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 + G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 1.095(is e) + 6.923 F 1.095(xtremely useful when w)-.15 F 1.095(orking on a ne)-.1 F + 3.595(wo)-.25 G 1.096(ptimization: it helps track do)-3.595 F 1.096 + (wn re)-.25 F(gressions)-.15 E(quickly)128 446.4 Q 5.015(.T)-.65 G 2.515 + (oa)-5.815 G -.2(vo)-2.715 G .014(id ha).2 F .014(ving to relink)-.2 F + F1 8.416 -5.558(bb uu)2.514 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998 + (oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 + -2.15 -.25(ev e)5.842 H .014(ry time you change your optimization, mak) + .25 F(e)-.1 E F1 8.416 -5.558(bb uu)2.514 H -4.998(gg)5.558 G -5.558(pp) + 4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt) + 5.558 G F0(dynamically load your optimization by using the)128 458.4 Q + F1 -5.6982.5 G -2.778(ll)5.698 G -4.998(oo)2.778 G -4.998(aa)4.998 + G -5.558(dd)4.998 G F0(option.)8.058 E<83>108 475.2 Q F1 8.416 -5.558 + (bb uu)16.5 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G + -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .695 + (can generate a lot of output and run for a long period of time.)6.523 F + .696(It is often useful to capture)5.695 F + (the output of the program to \214le.)128 487.2 Q -.15(Fo)5 G 2.5(re).15 + G(xample, in the C shell, you can type:)-2.65 E F3(bugpoint ...)152 + 505.2 Q/F4 10/Symbol SF6 E F3 6(&t)C(ee bugpoint.log)-6 E F0 + (to get a cop)128 529.2 Q 2.5(yo)-.1 G(f)-2.5 E F1 8.416 -5.558(bb uu) + 2.5 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii) + 4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 1.1 -.55('s o)3.328 H + (utput in the \214le).55 E/F5 10/Times-Italic at 0 SF -.2(bu)2.5 G + (gpoint.lo).2 E(g)-.1 E F0 2.5(,a)C 2.5(sw)-2.5 G + (ell as on your terminal.)-2.5 E<83>108 546 Q F1 8.416 -5.558(bb uu)16.5 + H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 + G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .895(cannot deb)6.723 F .895 + (ug problems with the)-.2 F F2(LL)3.395 E(VM)-.9 E F0(link)3.395 E(er) + -.1 E 3.395(.I)-.55 G(f)-3.395 E F1 8.416 -5.558(bb uu)3.395 H -4.998 + (gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558 + (nn)2.778 G -3.328(tt)5.558 G F0 .894(crashes before you see its)6.723 F + F3(All)3.394 E .821(input ok)128 558 R F0 .821 + (message, you might try running)3.321 F F3 .821(llvm\255link \255v)3.321 + F F0 .821(on the same set of input \214les. If that)3.321 F + (also crashes, you may be e)128 570 Q(xperiencing a link)-.15 E(er b)-.1 + E(ug.)-.2 E 16.5<8349>108 586.8 S 2.608(fy)-16.5 G .108 + (our program is supposed to crash,)-2.608 F F1 8.416 -5.558(bb uu)2.608 + H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 + G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .108(will be confused. One w) + 5.936 F .107(ay to deal with this is to cause)-.1 F F1 8.416 -5.558 + (bb uu)128 598.8 T -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G + -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 + (to ignore the e)5.828 E(xit code from your program, by gi)-.15 E + (ving it the)-.25 E F1 -5.6982.5 G -4.438(cc)5.698 G -5.558(hh) + 4.438 G -4.438(ee)5.558 G -4.438(cc)4.438 G -5.558(kk)4.438 G -3.328(--) + 5.558 G -4.438(ee)3.328 G -4.998(xx)4.438 G -2.778(ii)4.998 G -3.328(tt) + 2.778 G -3.328(--)3.328 G -4.438(cc)3.328 G -4.998(oo)4.438 G -5.558(dd) + 4.998 G -4.438(ee)5.558 G -5.698(==)4.438 G -3.328(ff)5.698 G -4.998(aa) + 3.328 G -2.778(ll)4.998 G -3.888(ss)2.778 G -4.438(ee)3.888 G F0 + (option.)6.938 E/F6 10.95/Times-Bold at 0 SF -8.517(OO)72 615.6 S -6.688 + (PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904 + (NN)8.517 G -6.086(SS)7.904 G F1 19.162 -9.998<8a8a2061>109.666 627.6 T + (ad)5 E(dd)-5.558 E(di)-5.558 E(it)-2.778 E(ti)-3.328 E(io)-2.778 E(on) + -4.998 E(na)-5.558 E(al)-4.998 E(l-)-2.778 E(-s)-3.328 E(so)-3.888 E(o) + -4.998 E F5(libr)2.5 E(ary)-.15 E F0 .391 + (Load the dynamic shared object)128 639.6 R F5(libr)2.891 E(ary)-.15 E + F0 .391(into the test program whene)2.891 F -.15(ve)-.25 G 2.891(ri).15 + G 2.891(ti)-2.891 G 2.891(sr)-2.891 G 2.891(un. This)-2.891 F .392 + (is useful if you)2.891 F .942(are deb)128 651.6 R .942 + (ugging programs which depend on non-LL)-.2 F .941 + (VM libraries \(such as the X or curses libraries\) to)-1 F(run.)128 + 663.6 Q F1 19.162 -9.998<8a8a2061>109.666 680.4 T(ar)5 E -.1(rg)-4.438 G + (gs)-4.898 E(s)-3.888 E F5(pr)2.5 E -.1(og)-.45 G -.15(ra).1 G 2.5(ma) + .15 G -.37(rg)-2.5 G(s).37 E F0 -.15(Pa)128 692.4 S .693(ss all ar).15 F + .694(guments speci\214ed after \255ar)-.18 F .694 + (gs to the test program whene)-.18 F -.15(ve)-.25 G 3.194(ri).15 G 3.194 + (tr)-3.194 G 3.194(uns. Note)-3.194 F .694(that if an)3.194 F 3.194(yo) + -.15 G 3.194(ft)-3.194 G(he)-3.194 E F5(pr)128 704.4 Q -.1(og)-.45 G + -.15(ra).1 G 2.5(ma).15 G -.37(rg)-2.5 G(s).37 E F0 + (start with a '\255', you should use:)2.5 E 178.59(2004-07-04 1.3)72 768 + R(2)222.75 E EP + %%Page: 3 3 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF -.1(BU)72 48 S 120.17(GPOINT\(1\) LL).1 F + (VM Command Guide)-1 E -.1(BU)122.67 G(GPOINT\(1\)).1 E/F1 10/Courier at 0 + SF(bugpoint [bugpoint args] --args -- [program args])152 84 Q F0 .767 + (The `)128 108 R<60adad27>-.74 E 3.267('r)-.74 G .767(ight after the) + -3.267 F/F2 10/Times-Bold at 0 SF 19.162 -9.998<8a8a2061>4.933 H(ar)5 E -.1 + (rg)-4.438 G(gs)-4.898 E(s)-3.888 E F0 .767(option tells)3.267 F F2 + 8.416 -5.558(bb uu)3.267 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998 + (oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 + .767(to consider an)6.595 F 3.266(yo)-.15 G .766(ptions starting with) + -3.266 F F13.266 E F0 .766(to be)3.266 F(part of the)128 120 Q F2 + 19.162 -9.998<8a8a2061>4.166 H(ar)5 E -.1(rg)-4.438 G(gs)-4.898 E(s) + -3.888 E F0(option, not as options to)2.5 E F2 8.416 -5.558(bb uu)2.5 H + -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G + -5.558(nn)2.778 G -3.328(tt)5.558 G F0(itself.)5.828 E F2 19.162 -9.998 + <8a8a2074>109.666 136.8 T(to)6.67 E(oo)-4.998 E(ol)-4.998 E(l-)-2.778 E + (-a)-3.328 E(ar)-4.998 E -.1(rg)-4.438 G(gs)-4.898 E(s)-3.888 E/F3 10 + /Times-Italic at 0 SF(tool ar)2.5 E(gs)-.37 E F0 -.15(Pa)128 148.8 S 1.084 + (ss all ar).15 F 1.084(guments speci\214ed after \255\255tool-ar)-.18 F + 1.084(gs to the)-.18 F/F4 9/Times-Roman at 0 SF(LL)3.584 E(VM)-.9 E F0 + 1.085(tool under test \()3.584 F F2 -2.778(ll)C -2.778(ll)2.778 G -4.438 + (cc)2.778 G F0(,)4.438 E F2 -2.778(ll)3.585 G -2.778(ll)2.778 G -2.778 + (ii)2.778 G F0 3.585(,e)2.778 G 1.085(tc.\) whene)-3.585 F -.15(ve)-.25 + G 3.585(ri).15 G(t)-3.585 E 2.5(runs. Y)128 160.8 R + (ou should use this option in the follo)-1.1 E(wing w)-.25 E(ay:)-.1 E + F1(bugpoint [bugpoint args] --tool-args -- [tool args])152 178.8 Q F0 + .346(The `)128 202.8 R<60adad27>-.74 E 2.846('r)-.74 G .345 + (ight after the)-2.846 F F2 19.162 -9.998<8a8a2074>4.511 H(to)6.67 E(oo) + -4.998 E(ol)-4.998 E(l-)-2.778 E(-a)-3.328 E(ar)-4.998 E -.1(rg)-4.438 G + (gs)-4.898 E(s)-3.888 E F0 .345(option tells)2.845 F F2 8.416 -5.558 + (bb uu)2.845 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G + -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .345 + (to consider an)6.173 F 2.845(yo)-.15 G .345(ptions starting with)-2.845 + F F12.845 E F0(to)2.845 E(be part of the)128 214.8 Q F2 19.162 + -9.998<8a8a2074>4.166 H(to)6.67 E(oo)-4.998 E(ol)-4.998 E(l-)-2.778 E + (-a)-3.328 E(ar)-4.998 E -.1(rg)-4.438 G(gs)-4.898 E(s)-3.888 E F0 + (option, not as options to)2.5 E F2 8.416 -5.558(bb uu)2.5 H -4.998(gg) + 5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn) + 2.778 G -3.328(tt)5.558 G F0(itself. \(See)5.828 E F2 19.162 -9.998 + <8a8a2061>4.166 H(ar)5 E -.1(rg)-4.438 G(gs)-4.898 E(s)-3.888 E F0 2.5 + (,a)C(bo)-2.5 E -.15(ve)-.15 G(.\)).15 E F2 19.162 -9.998<8a8a2063> + 109.666 231.6 T(ch)5.56 E(he)-5.558 E(ec)-4.438 E(ck)-4.438 E(k-)-5.558 + E(-e)-3.328 E(ex)-4.438 E(xi)-4.998 E(it)-2.778 E(t-)-3.328 E(-c)-3.328 + E(co)-4.438 E(od)-4.998 E(de)-5.558 E(e)-4.438 E F0(=)A F3({true)A + (,false})-.1 E F0(Assume a non-zero e)128 243.6 Q + (xit code or core dump from the test program is a f)-.15 E 2.5 + (ailure. Def)-.1 F(aults to true.)-.1 E F2 19.162 -9.998<8a8a2064> + 109.666 260.4 T(di)4.44 E(is)-2.778 E(sa)-3.888 E(ab)-4.998 E(bl)-5.558 + E(le)-2.778 E(e-)-4.438 E(-{)-3.328 E({d)-3.938 E(dc)-5.558 E(ce)-4.438 + E(e,)-4.438 E(,s)-2.498 E(si)-3.888 E(im)-2.778 E(mp)-8.328 E(pl)-5.558 + E(li)-2.778 E(if)-2.778 E(fy)-3.328 E(yc)-4.998 E(cf)-4.438 E(fg)-3.328 + E(g})-4.998 E(})-3.938 E F0 .694(Do not run the speci\214ed passes to c\ + lean up and reduce the size of the test program. By def)128 272.4 R + (ault,)-.1 E F2 8.416 -5.558(bb uu)3.195 H -4.998(gg)5.558 G -3.328(--) + 4.998 G -5.558(pp)128 284.4 S -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558 + (nn)2.778 G -3.328(tt)5.558 G F0 .541 + (uses these passes internally when attempting to reduce test programs.) + 6.369 F .54(If you')5.54 F .54(re trying to \214nd a)-.5 F -.2(bu)128 + 296.4 S 2.5(gi).2 G 2.5(no)-2.5 G(ne of these passes,)-2.5 E F2 8.416 + -5.558(bb uu)2.5 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G + -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0(may crash.) + 5.828 E F2 19.162 -9.998<8a8a2068>109.666 313.2 T(he)4.44 E(el)-4.438 E + (lp)-2.778 E(p)-5.558 E F0(Print a summary of command line options.)128 + 325.2 Q F2 19.162 -9.998<8a8a2069>109.666 342 T(in)7.22 E(np)-5.558 E + (pu)-5.558 E(ut)-5.558 E(t)-3.328 E F3(\214lename)2.5 E F0(Open)128 354 + Q F3(\214lename)2.727 E F0 .228 + (and redirect the standard input of the test program, whene)2.727 F -.15 + (ve)-.25 G 2.728(ri).15 G 2.728(tr)-2.728 G .228(uns, to come from that) + -2.728 F(\214le.)128 366 Q F2 19.162 -9.998<8a8a206c>109.666 382.8 T(lo) + 7.22 E(oa)-4.998 E(ad)-4.998 E(d)-5.558 E F3(plugin)2.5 E F0 1.375 + (Load the dynamic object)128 394.8 R F3(plugin)3.874 E F0(into)3.874 E + F2 8.416 -5.558(bb uu)3.874 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998 + (oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 + 3.874(itself. This)7.202 F 1.374(object should re)3.874 F 1.374 + (gister ne)-.15 F 3.874(wo)-.25 G(ptimization)-3.874 E 3.157 + (passes. Once)128 406.8 R .658(loaded, the object will add ne)3.157 F + 3.158(wc)-.25 G .658(ommand line options to enable v)-3.158 F .658 + (arious optimizations.)-.25 F 1.68 -.8(To s)128 418.8 T .08(ee the ne).8 + F 2.579(wc)-.25 G .079(omplete list of optimizations, use the)-2.579 F + F2 19.162 -9.998<8a8a2068>4.245 H(he)4.44 E(el)-4.438 E(lp)-2.778 E(p) + -5.558 E F0(and)2.579 E F2 19.162 -9.998<8a8a206c>4.245 H(lo)7.22 E(oa) + -4.998 E(ad)-4.998 E(d)-5.558 E F0 .079(options together; for e)2.579 F + (xam-)-.15 E(ple:)128 430.8 Q F1(bugpoint --load myNewPass.so --help)152 + 448.8 Q F2 19.162 -9.998<8a8a206f>109.666 477.6 T(ou)5 E(ut)-5.558 E(tp) + -3.328 E(pu)-5.558 E(ut)-5.558 E(t)-3.328 E F3(\214lename)2.5 E F0 + (Whene)128 489.6 Q -.15(ve)-.25 G 2.626(rt).15 G .126(he test program p\ + roduces output on its standard output stream, it should match the conte\ + nts)-2.626 F(of)128 501.6 Q F3(\214lename)2.572 E F0 .072(\(the `)2.572 + F .072(`reference output')-.74 F .072 + ('\). If you do not use this option,)-.74 F F2 8.416 -5.558(bb uu)2.572 + H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 + G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .072 + (will attempt to generate a)5.9 F + (reference output by compiling the program with the C back)128 513.6 Q + (end and running it.)-.1 E F2 19.162 -9.998<8a8a2070>109.666 530.4 T(pr) + 4.44 E -.18(ro)-4.438 G<6f8c>-4.818 E<8c6c>-5.558 E(le)-2.778 E(e-) + -4.438 E(-i)-3.328 E(in)-2.778 E(nf)-5.558 E -.25(fo)-3.328 G(o-)-4.748 + E<2d8c>-3.328 E<8c6c>-5.558 E(le)-2.778 E(e)-4.438 E F3(\214lename)2.5 E + F0(Pro\214le \214le loaded by)128 542.4 Q F2 19.162 -9.998<8a8a2070> + 4.166 H(pr)4.44 E -.18(ro)-4.438 G<6f8c>-4.818 E<8c6c>-5.558 E(le)-2.778 + E(e-)-4.438 E(-l)-3.328 E(lo)-2.778 E(oa)-4.998 E(ad)-4.998 E(de)-5.558 + E(er)-4.438 E(r)-4.438 E F0(.)A F2 19.162 -9.998<8a8a2072>109.666 559.2 + T(ru)5.56 E(un)-5.558 E(n-)-5.558 E(-{)-3.328 E({i)-3.938 E(in)-2.778 E + (nt)-5.558 E(t,)-3.328 E(,j)-2.498 E(ji)-3.328 E(it)-2.778 E(t,)-3.328 E + (,l)-2.498 E(ll)-2.778 E(lc)-2.778 E(c,)-4.438 E(,c)-2.498 E(cb)-4.438 E + (be)-5.558 E(e})-4.438 E(})-3.938 E F0(Whene)128 571.2 Q -.15(ve)-.25 G + 2.786(rt).15 G .287(he test program is compiled,)-2.786 F F2 8.416 + -5.558(bb uu)2.787 H -4.998(gg)5.558 G -5.558(pp)4.998 G -4.998(oo)5.558 + G -2.778(ii)4.998 G -5.558(nn)2.778 G -3.328(tt)5.558 G F0 .287 + (should generate code for it using the speci\214ed code)6.115 F + (generator)128 583.2 Q 5.824(.T)-.55 G .824(hese options allo)-5.824 F + 3.324(wy)-.25 G .824(ou to choose the interpreter)-3.324 F 3.323(,t)-.4 + G(he)-3.323 E F4(JIT)3.323 E F0(compiler)3.323 E 3.323(,t)-.4 G .823 + (he static nati)-3.323 F 1.123 -.15(ve c)-.25 H(ode).15 E(compiler)128 + 595.2 Q 2.5(,o)-.4 G 2.5(rt)-2.5 G(he C back)-2.5 E(end, respecti)-.1 E + -.15(ve)-.25 G(ly).15 E(.)-.65 E/F5 10.95/Times-Bold at 0 SF -7.302(EE)72 + 612 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H(ST) + 1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S) + -6.086 E F0(If)108 624 Q F2 8.416 -5.558(bb uu)2.528 H -4.998(gg)5.558 G + -5.558(pp)4.998 G -4.998(oo)5.558 G -2.778(ii)4.998 G -5.558(nn)2.778 G + -3.328(tt)5.558 G F0 .028(succeeds in \214nding a problem, it will e) + 5.856 F .028(xit with 0.)-.15 F .028 + (Otherwise, if an error occurs, it will e)5.028 F .029(xit with)-.15 F + 2.5(an)108 636 S(on-zero v)-2.5 E(alue.)-.25 E F5 -6.086(SS)72 652.8 S + -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO) + -6.086 E(O)-8.517 E F0(opt, analyze)108 664.8 Q F5 12.522 -7.904(AA UU) + 72 681.6 T -7.302(TT)7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G -7.904 + (RR)8.517 G F0(Maintained by the)108 693.6 Q F4(LL)2.5 E(VM)-.9 E F0 -.7 + (Te)2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 + 768 R(3)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/extract.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/extract.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/extract.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,286 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(EXTRA)72 48 Q 124.91(CT\(1\) LL)-.4 F + (VM Command Guide)-1 E(EXTRA)127.41 E(CT\(1\))-.4 E/F1 10.95 + /Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302 + (EE)10.335 G F0 -.15(ex)108 96 S(tract \255 e).15 E + (xtract a function from an)-.15 E/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 + E F0(module)2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN) + 7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II) + 6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -4.438(ee)108 124.8 S + -4.998(xx)4.438 G -3.328(tt)4.998 G -4.438(rr)3.328 G -4.998(aa)4.438 G + -4.438(cc)4.998 G -3.328(tt)4.438 G F0([)5.828 E/F4 10/Times-Italic at 0 SF + (options)A F0(])A F3 19.162 -9.998<8a8a2066>4.166 H(fu)6.67 E(un)-5.558 + E(nc)-5.558 E(c)-4.438 E F4(function-name)2.5 E F0([)2.5 E F4 + (\214lename)A F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086 + (SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688 + (PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904 + (NN)8.517 G F0(The)108 153.6 Q F3 -4.438(ee)3.086 G -4.998(xx)4.438 G + -3.328(tt)4.998 G -4.438(rr)3.328 G -4.998(aa)4.438 G -4.438(cc)4.998 G + -3.328(tt)4.438 G F0 .586(command tak)6.414 F .585 + (es the name of a function and e)-.1 F .585 + (xtracts it from the speci\214ed)-.15 F F2(LL)3.085 E(VM)-.9 E F0 .585 + (bytecode \214le.)3.085 F(It is primarily used as a deb)108 165.6 Q + (ugging tool to reduce test cases from lar)-.2 E + (ger programs that are triggering a b)-.18 E(ug.)-.2 E .057 + (In addition to e)108 182.4 R .057 + (xtracting the bytecode of the speci\214ed function,)-.15 F F3 -4.438 + (ee)2.557 G -4.998(xx)4.438 G -3.328(tt)4.998 G -4.438(rr)3.328 G -4.998 + (aa)4.438 G -4.438(cc)4.998 G -3.328(tt)4.438 G F0 .057(will also remo) + 5.885 F .357 -.15(ve u)-.15 H .058(nreachable global).15 F -.25(va)108 + 194.4 S(riables, prototypes, and unused types.).25 E(The)108 211.2 Q F3 + -4.438(ee)3.473 G -4.998(xx)4.438 G -3.328(tt)4.998 G -4.438(rr)3.328 G + -4.998(aa)4.438 G -4.438(cc)4.998 G -3.328(tt)4.438 G F0 .973(command r\ + eads its input from standard input if \214lename is omitted or if \214l\ + ename is \255.)6.801 F(The)5.972 E(output is al)108 223.2 Q -.1(wa)-.1 G + (ys written to standard output, unless the).1 E F3 -5.6982.5 G + -4.998(oo)5.698 G F0(option is speci\214ed \(see belo)7.498 E(w\).)-.25 + E F1 -8.517(OO)72 240 S -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II) + 7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G -6.086(SS)7.904 G F3 -5.698 + 108 252 S -3.328(ff)5.698 G F0 -.15(Fo)14.294 G 1.139(rce o).15 F + -.15(ve)-.15 G 3.639(rwrite. Normally).15 F(,)-.65 E F3 -4.438(ee)3.639 + G -4.998(xx)4.438 G -3.328(tt)4.998 G -4.438(rr)3.328 G -4.998(aa)4.438 + G -4.438(cc)4.998 G -3.328(tt)4.438 G F0 1.14(will refuse to o)6.967 F + -.15(ve)-.15 G 1.14(rwrite an output \214le that already e).15 F 3.64 + (xists. W)-.15 F(ith)-.4 E(this option,)128 264 Q F3 -4.438(ee)2.5 G + -4.998(xx)4.438 G -3.328(tt)4.998 G -4.438(rr)3.328 G -4.998(aa)4.438 G + -4.438(cc)4.998 G -3.328(tt)4.438 G F0(will o)5.828 E -.15(ve)-.15 G + (rwrite the output \214le and replace it with ne).15 E 2.5(wb)-.25 G + (ytecode.)-2.5 E F3 19.162 -9.998<8a8a2066>109.666 280.8 T(fu)6.67 E(un) + -5.558 E(nc)-5.558 E(c)-4.438 E F4(function-name)2.5 E F0 + (Extract the function named)128 292.8 Q F4(function-name)2.5 E F0 + (from the)2.5 E F2(LL)2.5 E(VM)-.9 E F0(bytecode.)2.5 E F3 19.162 -9.998 + <8a8a2068>109.666 309.6 T(he)4.44 E(el)-4.438 E(lp)-2.778 E(p)-5.558 E + F0(Print a summary of command line options.)128 321.6 Q F3 -5.698 + 108 338.4 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 .24 + (Specify the output \214lename.)128 350.4 R .239(If \214lename is `) + 5.239 F(`\255')-.74 E 2.739('\()-.74 G .239(the def)-2.739 F .239 + (ault\), then)-.1 F F3 -4.438(ee)2.739 G -4.998(xx)4.438 G -3.328(tt) + 4.998 G -4.438(rr)3.328 G -4.998(aa)4.438 G -4.438(cc)4.998 G -3.328(tt) + 4.438 G F0 .239(sends its output to standard)6.067 F(output.)128 362.4 Q + F3 19.162 -9.998<8a8a2073>109.666 379.2 T(st)6.11 E(ta)-3.328 E(at) + -4.998 E(ts)-3.328 E(s)-3.888 E F0(Print statistics.)128 391.2 Q F3 + 19.162 -9.998<8a8a2074>109.666 408 T(ti)6.67 E(im)-2.778 E(me)-8.328 E + (e-)-4.438 E(-p)-3.328 E(pa)-5.558 E(as)-4.998 E(ss)-3.888 E(se)-3.888 E + (es)-4.438 E(s)-3.888 E F0(Record the amount of time needed for each pa\ + ss and print it to standard error)128 420 Q(.)-.55 E F1 -7.302(EE)72 + 436.8 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H + (ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E + (S)-6.086 E F0(If)108 448.8 Q F3 -4.438(ee)2.5 G -4.998(xx)4.438 G + -3.328(tt)4.998 G -4.438(rr)3.328 G -4.998(aa)4.438 G -4.438(cc)4.998 G + -3.328(tt)4.438 G F0(succeeds, it will e)5.828 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 465.6 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0 -.2(bu) + 108 477.6 S(gpoint).2 E F1 12.522 -7.904(AA UU)72 494.4 T -7.302(TT) + 7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS) + 7.904 G F0(Maintained by the)108 506.4 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te) + 2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 + R(1)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/gccas.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/gccas.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/gccas.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,277 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 137.28(GCCAS\(1\) LL)72 48 R(VM Command Guide)-1 + E(GCCAS\(1\))139.78 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 + T -10.335(MM)7.904 G -7.302(EE)10.335 G F0(gccas \255 optimizing)108 96 + Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(assembler)2.5 E F1 -6.086 + (SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 G + -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 G + /F3 10/Times-Bold at 0 SF -4.998(gg)108 124.8 S -4.438(cc)4.998 G -4.438 + (cc)4.438 G -4.998(aa)4.438 G -3.888(ss)4.998 G F0([)6.388 E/F4 10 + /Times-Italic at 0 SF(options)A F0(])A F4(\214lename)2.5 E F1 -7.904(DD)72 + 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR) + 7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II) + 7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -4.998 + (gg)2.51 G -4.438(cc)4.998 G -4.438(cc)4.438 G -4.998(aa)4.438 G -3.888 + (ss)4.998 G F0 .01(utility tak)6.398 F .01(es an)-.1 F F2(LL)2.51 E(VM) + -.9 E F0 .009 + (assembly \214le generated by the llvmgcc or llvmg++ front-ends and con) + 2.51 F -.15(ve)-.4 G(rts).15 E .094(it into an)108 165.6 R F2(LL)2.594 E + (VM)-.9 E F0 .094(bytecode \214le.)2.594 F .094 + (It is primarily used by the)5.094 F F2(GCC)2.594 E F0 .095 + (front end, and as such, attempts to mimic the)2.594 F(interf)108 177.6 + Q(ace pro)-.1 E(vided by the def)-.15 E + (ault system assembler so that it can act as a `)-.1 E(`drop-in')-.74 E + 2.5('r)-.74 G(eplacement.)-2.5 E F3 -4.998(gg)108 194.4 S -4.438(cc) + 4.998 G -4.438(cc)4.438 G -4.998(aa)4.438 G -3.888(ss)4.998 G F0 .26 + (performs a number of optimizations on the input program, including b) + 6.648 F .259(ut not limited to: promotion of)-.2 F 1.33(stack v)108 + 206.4 R 1.33(alues to)-.25 F F2(SSA)3.83 E F0(re)3.83 E 1.33 + (gisters; elimination of dead globals, function ar)-.15 F 1.331 + (guments, code, and types; tail-call)-.18 F .283(elimination; loop-in) + 108 218.4 R -.25(va)-.4 G .282(riant code motion; global common-sube).25 + F .282(xpression elimination; and sparse conditional)-.15 F + (constant propag)108 230.4 Q(ation.)-.05 E F1 -8.517(OO)72 247.2 S + -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G -6.086(SS)7.904 G F3 19.162 -9.998<8a8a2068>109.666 + 259.2 T(he)4.44 E(el)-4.438 E(lp)-2.778 E(p)-5.558 E F0 + (Print a summary of command line options.)128 271.2 Q F3 -5.698108 + 288 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0(Specify the name of th\ + e output \214le which will hold the assembled bytecode.)128 300 Q F3 + 19.162 -9.998<8a8a2064>109.666 316.8 T(di)4.44 E(is)-2.778 E(sa)-3.888 E + (ab)-4.998 E(bl)-5.558 E(le)-2.778 E(e-)-4.438 E(-i)-3.328 E(in)-2.778 E + (nl)-5.558 E(li)-2.778 E(in)-2.778 E(ni)-5.558 E(in)-2.778 E(ng)-5.558 E + (g)-4.998 E F0(Disable the inlining pass.)128 328.8 Q(By def)5 E + (ault, it is enabled.)-.1 E F3 19.162 -9.998<8a8a2064>109.666 345.6 T + (di)4.44 E(is)-2.778 E(sa)-3.888 E(ab)-4.998 E(bl)-5.558 E(le)-2.778 E + (e-)-4.438 E(-o)-3.328 E(op)-4.998 E(pt)-5.558 E(t)-3.328 E F0 + (Disable all assembler)128 357.6 Q(-time optimization passes.)-.2 E F3 + 19.162 -9.998<8a8a2073>109.666 374.4 T(st)6.11 E(ta)-3.328 E(at)-4.998 E + (ts)-3.328 E(s)-3.888 E F0(Print statistics.)128 386.4 Q F3 19.162 + -9.998<8a8a2074>109.666 403.2 T(ti)6.67 E(im)-2.778 E(me)-8.328 E(e-) + -4.438 E(-p)-3.328 E(pa)-5.558 E(as)-4.998 E(ss)-3.888 E(se)-3.888 E(es) + -4.438 E(s)-3.888 E F0(Record the amount of time needed for each pass a\ + nd print it to standard error)128 415.2 Q(.)-.55 E F3 19.162 -9.998 + <8a8a2076>109.666 432 T -.1(ve)5 G(er)-4.338 E(ri)-4.438 E(if)-2.778 E + (fy)-3.328 E(y)-4.998 E F0 -1.11(Ve)128 444 S(rify each pass result.) + 1.11 E F1 -7.302(EE)72 460.8 S -7.904(XX)7.302 G -4.258(II)7.904 G + 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 + G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F0(If)108 472.8 Q F3 -4.998(gg) + 2.803 G -4.438(cc)4.998 G -4.438(cc)4.438 G -4.998(aa)4.438 G -3.888(ss) + 4.998 G F0 .303(succeeds, it will e)6.691 F .303(xit with an e)-.15 F + .303(xit status of 0.)-.15 F .303 + (Otherwise, if an error occurs, it will e)5.303 F .304(xit with a non-) + -.15 F(zero e)108 484.8 Q(xit status.)-.15 E F1 -6.086(SS)72 501.6 S + -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO) + -6.086 E(O)-8.517 E F0(llvm-as, gccld)108 513.6 Q F1 12.522 -7.904 + (AA UU)72 530.4 T -7.302(TT)7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G + -7.904(RR)8.517 G -6.086(SS)7.904 G F0(Maintained by the)108 542.4 Q F2 + (LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E + 178.59(2004-07-04 1.3)72 768 R(1)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/gccld.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/gccld.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/gccld.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,441 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 2 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 136.73(GCCLD\(1\) LL)72 48 R(VM Command Guide)-1 + E(GCCLD\(1\))139.23 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 + T -10.335(MM)7.904 G -7.302(EE)10.335 G F0(gccld \255 optimizing)108 96 + Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(link)2.5 E(er)-.1 E F1 + -6.086(SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 + G -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 + G/F3 10/Times-Bold at 0 SF -4.998(gg)108 124.8 S -4.438(cc)4.998 G -4.438 + (cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G F0([)8.058 E/F4 10 + /Times-Italic at 0 SF(options)A F0(])A F4(\214lename ...)2.5 E F1 -7.904 + (DD)72 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G -7.904(CC)6.086 G + -7.904(RR)7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G -7.302(TT)6.688 G + -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G F0(The)108 153.6 Q + F3 -4.998(gg)3.188 G -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 + G -5.558(dd)2.778 G F0 .688(utility tak)8.746 F .688(es a set of)-.1 F + F2(LL)3.188 E(VM)-.9 E F0 .687 + (bytecode \214les and links them together into a single)3.188 F F2(LL) + 3.187 E(VM)-.9 E F0(bytecode)3.187 E 3.27(\214le. The)108 165.6 R .771 + (output bytecode \214le can be another bytecode library or an e)3.27 F + -.15(xe)-.15 G .771(cutable bytecode program.).15 F(Using)5.771 E + (additional options,)108 177.6 Q F3 -4.998(gg)2.5 G -4.438(cc)4.998 G + -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G F0 + (is able to produce nati)8.058 E .3 -.15(ve c)-.25 H(ode e).15 E -.15 + (xe)-.15 G(cutables.).15 E(The)108 194.4 Q F3 -4.998(gg)4.318 G -4.438 + (cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G F0 + 1.817(utility is primarily used by the the llvmgcc manpage and llvmg++ \ + front-ends, and as such,)9.876 F 1.518(attempts to mimic the interf)108 + 206.4 R 1.518(ace pro)-.1 F 1.518(vided by the def)-.15 F 1.518 + (ault system link)-.1 F 1.519(er so that it can act as a `)-.1 F + (`drop-in')-.74 E(')-.74 E(replacement.)108 218.4 Q(The)108 235.2 Q F3 + -4.998(gg)2.5 G -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 G + -5.558(dd)2.778 G F0(tool performs a small set of interprocedural, post\ + -link optimizations on the program.)8.058 E F3 -5.558(SS)108 258 S + -4.438(ee)5.558 G -4.998(aa)4.438 G 6.196 -4.438(rr cc)4.998 H 11.116 + -5.558(hh O)4.438 H(Or)-2.22 E(rd)-4.438 E(de)-5.558 E(er)-4.438 E(r) + -4.438 E F0 .13 + (When looking for objects speci\214ed on the command line,)108 274.8 R + F3 -4.998(gg)2.629 G -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 + G -5.558(dd)2.778 G F0 .129 + (will search for the object \214rst in the current)8.187 F .18 + (directory and then in the directory speci\214ed by the)108 286.8 R/F5 9 + /Times-Bold at 0 SF -6.001(LL)2.68 G 8.924 -6.001(LL V)6.001 H(VM)-.495 E + (M_)-8.494 E(_L)-4.498 E(LI)-6.001 E(IB)-3.499 E(B_)-6.001 E(_S)-4.498 E + (SE)-5.002 E(EA)-6.001 E(AR)-6.496 E(RC)-6.496 E(CH)-6.496 E(H_)-7 E(_P) + -4.498 E -.666(PA)-5.497 G -.855(AT)-5.83 G(TH)-5.146 E(H)-7 E F0(en) + 2.68 E .18(vironment v)-.4 F 2.68(ariable. If)-.25 F(it)2.68 E + (cannot \214nd the object, it f)108 298.8 Q(ails.)-.1 E .888 + (When looking for a library speci\214ed with the)108 315.6 R F3 -5.698 + 3.388 G -2.778(ll)5.698 G F0(option,)6.166 E F3 -4.998(gg)3.388 G + -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G + F0 .887(\214rst attempts to load a \214le with that name)8.946 F .902 + (from the current directory)108 327.6 R 5.903(.I)-.65 G 3.403(ft)-5.903 + G .903(hat f)-3.403 F .903(ails, it looks for lib)-.1 F F4(libr)A(ary) + -.15 E F0 .903(.bc, lib)B F4(libr)A(ary)-.15 E F0 .903(.a, or lib)B F4 + (libr)A(ary)-.15 E F0(.)A F4(shar)A .903(ed libr)-.37 F(ary)-.15 E -.2 + (ex)108 339.6 S(tension).2 E F0 2.796(,i)C 2.796(nt)-2.796 G .296 + (hat order)-2.796 F 2.796(,i)-.4 G 2.796(ne)-2.796 G .295 + (ach directory added to the library search path with the)-2.796 F F3 + -5.6982.795 G -6.668(LL)5.698 G F0 2.795(option. These)9.463 F + (direc-)2.795 E .147(tories are searched in the order the)108 351.6 R + 2.647(yw)-.15 G .147(ere speci\214ed.)-2.647 F .147 + (If the library cannot be located, then)5.147 F F3 -4.998(gg)2.648 G + -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G + F0 .148(looks in the)8.206 F .949(directory speci\214ed by the)108 363.6 + R F5 -6.001(LL)3.448 G 8.924 -6.001(LL V)6.001 H(VM)-.495 E(M_)-8.494 E + (_L)-4.498 E(LI)-6.001 E(IB)-3.499 E(B_)-6.001 E(_S)-4.498 E(SE)-5.002 E + (EA)-6.001 E(AR)-6.496 E(RC)-6.496 E(CH)-6.496 E(H_)-7 E(_P)-4.498 E + -.666(PA)-5.497 G -.855(AT)-5.83 G(TH)-5.146 E(H)-7 E F0(en)3.448 E .948 + (vironment v)-.4 F 3.448(ariable. If)-.25 F .948 + (it does not \214nd a library)3.448 F(there, it f)108 375.6 Q(ails.)-.1 + E(The shared library e)108 392.4 Q(xtension may be)-.15 E F4(.so)2.5 E + F0(,)A F4(.dyld)2.5 E F0(,)A F4(.dll)2.5 E F0 2.5(,o)C 2.5(rs)-2.5 G + (omething dif)-2.5 E(ferent, depending upon the system.)-.25 E(The)108 + 409.2 Q F3 -5.6982.769 G -6.668(LL)5.698 G F0 .269 + (option is global.)9.437 F .269(It does not matter where it is speci\ + \214ed in the list of command line ar)5.269 F .27(guments; the)-.18 F + .671(directory is simply added to the search path and is applied to all\ + libraries, preceding or succeeding, in the)108 421.2 R(command line.) + 108 433.2 Q F3 -6.668(LL)108 456 S -2.778(ii)6.668 G -5.558(nn)2.778 G + 11.116 -5.558(kk o)5.558 H(or).56 E(rd)-4.438 E(de)-5.558 E(er)-4.438 E + (r)-4.438 E F0 .779(All object \214les are link)108 472.8 R .779 + (ed \214rst in the order the)-.1 F 3.279(yw)-.15 G .78 + (ere speci\214ed on the command line.)-3.279 F .78 + (All library \214les are)5.78 F(link)108 484.8 Q(ed ne)-.1 E 2.5 + (xt. Some)-.15 F(libraries may not be link)2.5 E + (ed into the object program; see belo)-.1 E -.65(w.)-.25 G F3 -6.668(LL) + 108 507.6 S -2.778(ii)6.668 G -5.558(bb)2.778 G -4.438(rr)5.558 G -4.998 + (aa)4.438 G -4.438(rr)4.998 G 9.996 -4.998(yy L)4.438 H(Li)-1.67 E(in) + -2.778 E(nk)-5.558 E(ka)-5.558 E(ag)-4.998 E(ge)-4.998 E(e)-4.438 E F0 + 1.232(Object \214les and static bytecode objects are al)108 524.4 R -.1 + (wa)-.1 G 1.232(ys link).1 F 1.232(ed into the output \214le.)-.1 F + 1.232(Library archi)6.232 F -.15(ve)-.25 G 3.731(s\().15 G 1.231 + (.a \214les\))-3.731 F 1.385(load only the objects within the archi)108 + 536.4 R 1.686 -.15(ve t)-.25 H 1.386 + (hat de\214ne symbols needed by the output \214le.).15 F 1.386 + (Hence, libraries)6.386 F 1.592(should be listed after the object \214l\ + es and libraries which need them; otherwise, the library may not be)108 + 548.4 R(link)108 560.4 Q(ed in, and the dependent library will not ha) + -.1 E .3 -.15(ve i)-.2 H(ts unde\214ned symbols de\214ned.).15 E F3 + -7.218(NN)108 583.2 S -4.998(aa)7.218 G -3.328(tt)4.998 G 2.956 -2.778 + (ii v)3.328 H -.1(ve)-2.22 G 2.5(ec)-4.338 G(co)-6.938 E(od)-4.998 E(de) + -5.558 E 2.5(eg)-4.438 G(ge)-7.498 E(en)-4.438 E(ne)-5.558 E(er)-4.438 E + (ra)-4.438 E(at)-4.998 E(ti)-3.328 E(io)-2.778 E(on)-4.998 E(n)-5.558 E + F0(The)108 600 Q F3 -4.998(gg)2.964 G -4.438(cc)4.998 G -4.438(cc)4.438 + G -2.778(ll)4.438 G -5.558(dd)2.778 G F0 .465 + (program has limited support for nati)8.523 F .765 -.15(ve c)-.25 H .465 + (ode generation, when using the).15 F F3 -5.6982.965 G -5.558(nn) + 5.698 G -4.998(aa)5.558 G -3.328(tt)4.998 G 2.956 -2.778(ii v)3.328 H + -.1(ve)-2.22 G(e)-4.338 E F0(or)2.965 E F3 -5.6982.965 G -5.558 + (nn)5.698 G -4.998(aa)5.558 G -3.328(tt)4.998 G 2.956 -2.778(ii v)3.328 + H -.1(ve)-2.22 G(e-)-4.338 E(-c)-3.328 E(cb)-4.438 E(be)-5.558 E(e) + -4.438 E F0(options.)108 612 Q F1 -8.517(OO)72 628.8 S -6.688(PP)8.517 G + -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G + -6.086(SS)7.904 G F3 -5.698108 640.8 S -5.558(hh)5.698 G -4.438 + (ee)5.558 G -2.778(ll)4.438 G -5.558(pp)2.778 G F0 + (Print a summary of command line options.)128 652.8 Q F3 -5.698108 + 669.6 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 + (Specify the output \214lename which will hold the link)128 681.6 Q + (ed bytecode.)-.1 E F3 -5.698108 698.4 S -3.888(ss)5.698 G -3.328 + (tt)3.888 G -4.998(aa)3.328 G -3.328(tt)4.998 G -3.888(ss)3.328 G F0 + (Print statistics.)128 710.4 Q 178.59(2004-07-04 1.3)72 768 R(1)222.75 E + EP + %%Page: 2 2 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 136.73(GCCLD\(1\) LL)72 48 R(VM Command Guide)-1 + E(GCCLD\(1\))139.23 E/F1 10/Times-Bold at 0 SF -5.698108 84 S -3.328 + (tt)5.698 G -2.778(ii)3.328 G -8.328(mm)2.778 G -4.438(ee)8.328 G -3.328 + (--)4.438 G -5.558(pp)3.328 G -4.998(aa)5.558 G -3.888(ss)4.998 G -3.888 + (ss)3.888 G -4.438(ee)3.888 G -3.888(ss)4.438 G F0(Record the amount of\ + time needed for each pass and print it to standard error)128 96 Q(.) + -.55 E F1 -5.698108 112.8 S 7.396 -4.998(vv e)5.698 H(er).56 E(ri) + -4.438 E(if)-2.778 E(fy)-3.328 E(y)-4.998 E F0 -1.11(Ve)128 124.8 S + (rify each pass result.)1.11 E F1 -5.698108 141.6 S -5.558(dd) + 5.698 G -2.778(ii)5.558 G -3.888(ss)2.778 G -4.998(aa)3.888 G -5.558(bb) + 4.998 G -2.778(ll)5.558 G -4.438(ee)2.778 G -3.328(--)4.438 G -4.998(oo) + 3.328 G -5.558(pp)4.998 G -3.328(tt)5.558 G F0 + (Disable all link-time optimization passes.)128 153.6 Q F1 -5.698 + 108 170.4 S -5.558(dd)5.698 G -2.778(ii)5.558 G -3.888(ss)2.778 G -4.998 + (aa)3.888 G -5.558(bb)4.998 G -2.778(ll)5.558 G -4.438(ee)2.778 G -3.328 + (--)4.438 G -2.778(ii)3.328 G -5.558(nn)2.778 G -2.778(ll)5.558 G -2.778 + (ii)2.778 G -5.558(nn)2.778 G -2.778(ii)5.558 G -5.558(nn)2.778 G -4.998 + (gg)5.558 G F0(Do not run the inliner pass.)128 182.4 Q F1 -5.698 + 108 199.2 S -6.668(LL)5.698 G/F2 10/Times-Italic at 0 SF(dir)6.668 E + (ectory)-.37 E F0(Add directory to the list of directories to search wh\ + en looking for libraries.)128 211.2 Q F1 -5.698108 228 S -5.558 + (dd)5.698 G -2.778(ii)5.558 G -3.888(ss)2.778 G -4.998(aa)3.888 G -5.558 + (bb)4.998 G -2.778(ll)5.558 G -4.438(ee)2.778 G -3.328(--)4.438 G -2.778 + (ii)3.328 G -5.558(nn)2.778 G -3.328(tt)5.558 G -4.438(ee)3.328 G 6.226 + -4.438(rr n)4.438 H(na)-1.12 E(al)-4.998 E(li)-2.778 E(iz)-2.778 E(ze) + -4.438 E(e)-4.438 E F0(Do not mark all symbols as internal.)128 240 Q F1 + -5.698108 256.8 S -2.778(ii)5.698 G -5.558(nn)2.778 G -3.328(tt) + 5.558 G -4.438(ee)3.328 G 6.226 -4.438(rr n)4.438 H(na)-1.12 E(al)-4.998 + E(li)-2.778 E(iz)-2.778 E(ze)-4.438 E(e-)-4.438 E(-p)-3.328 E(pu)-5.558 + E(ub)-5.558 E(bl)-5.558 E(li)-2.778 E(ic)-2.778 E(c-)-4.438 E(-a)-3.328 + E(ap)-4.998 E(pi)-5.558 E(i-)-2.778 E<2d8c>-3.328 E<8c6c>-5.558 E(le) + -2.778 E(e)-4.438 E F2(\214lename)2.5 E F0(Preserv)128 268.8 Q 2.5(et) + -.15 G(he list of symbol names in the \214le \214lename.)-2.5 E F1 + -5.698108 285.6 S -2.778(ii)5.698 G -5.558(nn)2.778 G -3.328(tt) + 5.558 G -4.438(ee)3.328 G 6.226 -4.438(rr n)4.438 H(na)-1.12 E(al)-4.998 + E(li)-2.778 E(iz)-2.778 E(ze)-4.438 E(e-)-4.438 E(-p)-3.328 E(pu)-5.558 + E(ub)-5.558 E(bl)-5.558 E(li)-2.778 E(ic)-2.778 E(c-)-4.438 E(-a)-3.328 + E(ap)-4.998 E(pi)-5.558 E(i-)-2.778 E(-l)-3.328 E(li)-2.778 E(is)-2.778 + E(st)-3.888 E 2.5(t&)-3.328 G(&l)-10.828 E(lt)-2.778 E(t;)-3.328 E(;l) + -3.328 E(li)-2.778 E(is)-2.778 E(st)-3.888 E(t&)-3.328 E(&g)-8.328 E(gt) + -4.998 E(t;)-3.328 E(;)-3.328 E F0(Preserv)128 297.6 Q 2.5(et)-.15 G + (he symbol names in list.)-2.5 E F1 -5.698108 314.4 S -2.778(ll) + 5.698 G F2(libr)2.778 E(ary)-.15 E F0 .177 + (Specify libraries to include when linking the output \214le.)128 326.4 + R .177(When linking,)5.177 F F1 -4.998(gg)2.677 G -4.438(cc)4.998 G + -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G F0 .177 + (will \214rst attempt to load)8.235 F 3.5<618c>128 338.4 S 1 + (le with the pathname)-3.5 F F1 -2.778(ll)3.5 G -2.778(ii)2.778 G -5.558 + (bb)2.778 G -4.438(rr)5.558 G -4.998(aa)4.438 G -4.438(rr)4.998 G -4.998 + (yy)4.438 G F0 6(.I)4.998 G 3.5(ft)-6 G 1(hat f)-3.5 F 1.001 + (ails, it will then attempt to load lib)-.1 F F2(libr)A(ary)-.15 E F0 + 1.001(.bc, lib)B F2(libr)A(ary)-.15 E F0(.a,)A(and lib)128 350.4 Q F2 + (libr)A(ary)-.15 E F0(.)A F2(shar)A(ed libr)-.37 E(ary e)-.15 E + (xtension)-.2 E F0 2.5(,i)C 2.5(nt)-2.5 G(hat order)-2.5 E(.)-.55 E F1 + -5.698108 367.2 S -2.778(ll)5.698 G -2.778(ii)2.778 G -5.558(nn) + 2.778 G -5.558(kk)5.558 G -3.328(--)5.558 G -4.998(aa)3.328 G -3.888(ss) + 4.998 G -3.328(--)3.888 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(bb) + 2.778 G -4.438(rr)5.558 G -4.998(aa)4.438 G -4.438(rr)4.998 G -4.998(yy) + 4.438 G F0(Link the .bc \214les together as a library)128 379.2 Q 2.5 + (,n)-.65 G(ot an e)-2.5 E -.15(xe)-.15 G(cutable.).15 E F1 -5.698 + 108 396 S -5.558(nn)5.698 G -4.998(aa)5.558 G -3.328(tt)4.998 G 2.956 + -2.778(ii v)3.328 H -.1(ve)-2.22 G(e)-4.338 E F0(Generate a nati)128 408 + Q .3 -.15(ve m)-.25 H(achine code e).15 E -.15(xe)-.15 G(cutable.).15 E + .529(When generating nati)128 426 R .829 -.15(ve exe)-.25 H(cutables,) + .15 E F1 -4.998(gg)3.029 G -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778 + (ll)4.438 G -5.558(dd)2.778 G F0 .529(\214rst checks for a bytecode v) + 8.587 F .528(ersion of the library and links)-.15 F .724 + (it in, if necessary)128 438 R 5.724(.I)-.65 G 3.224(ft)-5.724 G .725 + (he library is missing,)-3.224 F F1 -4.998(gg)3.225 G -4.438(cc)4.998 G + -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G F0 .725(skips it.) + 8.783 F(Then,)5.725 E F1 -4.998(gg)3.225 G -4.438(cc)4.998 G -4.438(cc) + 4.438 G -2.778(ll)4.438 G -5.558(dd)2.778 G F0 .725 + (links in the same libraries as)8.783 F(nati)128 450 Q .3 -.15(ve c)-.25 + H(ode.).15 E .556(In this w)128 468 R(ay)-.1 E(,)-.65 E F1 -4.998(gg) + 3.056 G -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 G -5.558(dd) + 2.778 G F0 .555(should be able to link in optimized bytecode subsets of\ + common libraries and then)8.614 F(link in an)128 480 Q 2.5(yp)-.15 G + (art of the library that hasn')-2.5 E 2.5(tb)-.18 G(een con)-2.5 E -.15 + (ve)-.4 G(rted to bytecode.).15 E F1 -5.698108 496.8 S -5.558(nn) + 5.698 G -4.998(aa)5.558 G -3.328(tt)4.998 G 2.956 -2.778(ii v)3.328 H + -.1(ve)-2.22 G(e-)-4.338 E(-c)-3.328 E(cb)-4.438 E(be)-5.558 E(e)-4.438 + E F0(Generate a nati)128 508.8 Q .3 -.15(ve m)-.25 H(achine code e).15 E + -.15(xe)-.15 G(cutable with the).15 E/F3 9/Times-Roman at 0 SF(LL)2.5 E(VM) + -.9 E F0 2.5(Cb)2.5 G(ack)-2.5 E(end.)-.1 E .148 + (This option is identical to the)128 526.8 R F1 -5.6982.648 G + -5.558(nn)5.698 G -4.998(aa)5.558 G -3.328(tt)4.998 G 2.956 -2.778(ii v) + 3.328 H -.1(ve)-2.22 G(e)-4.338 E F0 .148(option, b)2.648 F .148 + (ut uses the C back)-.2 F .148(end to generate code for the program)-.1 + F(instead of an)128 538.8 Q F3(LL)2.5 E(VM)-.9 E F0(nati)2.5 E .3 -.15 + (ve c)-.25 H(ode generator).15 E(.)-.55 E F1 -5.698108 555.6 S + -3.888(ss)5.698 G F0(Strip symbol information from the generated e) + 14.294 E -.15(xe)-.15 G(cutable.).15 E F1 -5.698108 572.4 S -4.998 + (vv)5.698 G F0(Print information about actions tak)14.294 E(en.)-.1 E/F4 + 10.95/Times-Bold at 0 SF -7.302(EE)72 589.2 S -7.904(XX)7.302 G -4.258(II) + 7.904 G 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 G -1.04 + (AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F0(If)108 601.2 Q F1 + -4.998(gg)2.829 G -4.438(cc)4.998 G -4.438(cc)4.438 G -2.778(ll)4.438 G + -5.558(dd)2.778 G F0 .329(succeeds, it will e)8.387 F .328 + (xit with an e)-.15 F .328(xit status of 0.)-.15 F .328 + (Otherwise, if an error occurs, it will e)5.328 F .328(xit with a non-) + -.15 F(zero e)108 613.2 Q(xit status.)-.15 E F4 -6.086(SS)72 630 S + -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO) + -6.086 E(O)-8.517 E F0(llvm-link, gccas)108 642 Q F4 12.522 -7.904 + (AA UU)72 658.8 T -7.302(TT)7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G + -7.904(RR)8.517 G -6.086(SS)7.904 G F0(Maintained by the)108 670.8 Q F3 + (LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E + 178.59(2004-07-04 1.3)72 768 R(2)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llc.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llc.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llc.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,382 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 2 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 151.73(LLC\(1\) LL)72 48 R(VM Command Guide)-1 E + (LLC\(1\))154.23 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T + -10.335(MM)7.904 G -7.302(EE)10.335 G F0(llc \255)108 96 Q/F2 9 + /Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(static compiler)2.5 E F1 -6.086 + (SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 G + -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 G + /F3 10/Times-Bold at 0 SF -2.778(ll)108 124.8 S -2.778(ll)2.778 G -4.438 + (cc)2.778 G F0([)6.938 E/F4 10/Times-Italic at 0 SF(options)A F0 2.5(][)C + F4(\214lename)-2.5 E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G + -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G + -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -2.778(ll)4.763 G -2.778(ll) + 2.778 G -4.438(cc)2.778 G F0 2.263(command compiles)9.201 F F2(LL)4.763 + E(VM)-.9 E F0 2.263 + (bytecode into assembly language for a speci\214ed architecture.)4.763 F + (The)7.262 E .1 + (assembly language output can then be passed through a nati)108 165.6 R + .4 -.15(ve a)-.25 H .1(ssembler and link).15 F .1(er to generate nati) + -.1 F .4 -.15(ve c)-.25 H(ode.).15 E .648(The choice of architecture fo\ + r the output assembly code is determined as follo)108 182.4 R .648 + (ws, by attempting to satisfy)-.25 F(each of the follo)108 194.4 Q + (wing rules in turn \(\214rst one wins\):)-.25 E 16.5<8349>108 211.2 S + 2.5(ft)-16.5 G(he user has speci\214ed an architecture with the \255m o\ + ption, use that architecture.)-2.5 E 16.5<8345>108 228 S .385 + (xamine the input)-16.5 F F2(LL)2.885 E(VM)-.9 E F0 .386(bytecode \214l\ + e: if it is little endian and has a pointer size of 32 bits, select the) + 2.885 F(Intel)128 240 Q F2(IA-32)2.999 E F0 2.999(architecture. If)2.999 + F .499(it is big endian and has a pointer size of 64 bits, select the S\ + parcV9 archi-)2.999 F(tecture.)128 252 Q 16.5<8349>108 268.8 S(f)-16.5 E + F3 -2.778(ll)3.94 G -2.778(ll)2.778 G -4.438(cc)2.778 G F0 -.1(wa)8.378 + G 3.94(sc).1 G 1.44(ompiled on an architecture for which it can generat\ + e code, select the architecture upon)-3.94 F(which)128 280.8 Q F3 -2.778 + (ll)2.5 G -2.778(ll)2.778 G -4.438(cc)2.778 G F0 -.1(wa)6.938 G 2.5(sc) + .1 G(ompiled.)-2.5 E 16.5<8345>108 297.6 S(xit with an error message te\ + lling the user to specify the output architecture e)-16.5 E(xplicitly) + -.15 E(.)-.65 E F1 -8.517(OO)72 314.4 S -6.688(PP)8.517 G -7.302(TT) + 6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G -6.086(SS) + 7.904 G F0(If)108 326.4 Q F4(\214lename)3.562 E F0 1.062 + (is \255 or omitted,)3.562 F F3 -2.778(ll)3.562 G -2.778(ll)2.778 G + -4.438(cc)2.778 G F0(reads)8 E F2(LL)3.562 E(VM)-.9 E F0 1.062 + (bytecode from standard input.)3.562 F 1.061(Otherwise, it will read) + 6.062 F F2(LL)3.561 E(VM)-.9 E F0(bytecode from)108 338.4 Q F4 + (\214lename)2.5 E F0(.)A 1.245(If the)108 355.2 R F3 -5.6983.745 G + -4.998(oo)5.698 G F0 1.245(option is omitted, then)8.743 F F3 -2.778(ll) + 3.745 G -2.778(ll)2.778 G -4.438(cc)2.778 G F0 1.245 + (will send its output to standard output if the input is from standard) + 8.183 F 2.5(input. If)108 367.2 R(the)2.5 E F3 -5.6982.5 G -4.998 + (oo)5.698 G F0(option speci\214es \255, then the output will also be se\ + nt to standard output.)7.498 E .086(If no)108 384 R F3 -5.6982.586 + G -4.998(oo)5.698 G F0 .086(option is speci\214ed and an input \214le o\ + ther than \255 is speci\214ed, then)7.584 F F3 -2.778(ll)2.585 G -2.778 + (ll)2.778 G -4.438(cc)2.778 G F0 .085(creates the output \214lename by) + 7.023 F(taking the input \214lename, remo)108 396 Q(ving an)-.15 E 2.5 + (ye)-.15 G(xisting)-2.65 E F4(.bc)2.5 E F0 -.15(ex)2.5 G + (tension, and adding a).15 E F4(.s)2.5 E F0(suf)2.5 E(\214x.)-.25 E + (Other)108 412.8 Q F3 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.438(cc)2.778 + G F0(options are as follo)6.938 E(ws:)-.25 E F3 -5.698108 429.6 S + -3.328(ff)5.698 G F0(Ov)14.294 E(erwrite output \214les. By def)-.15 E + (ault,)-.1 E F3 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.438(cc)2.778 G F0 + (will refuse to o)6.938 E -.15(ve)-.15 G + (rwrite an output \214le which already e).15 E(xists.)-.15 E F3 -5.698 + 108 446.4 S -8.328(mm)5.698 G -4.998(aa)8.328 G 6.196 -4.438 + (rr cc)4.998 H -5.558(hh)4.438 G F0(=)5.558 E F4(ar)A -.15(ch)-.37 G F0 + (Specify the architecture for which to generate assembly)128 458.4 Q 5 + (.V)-.65 G(alid architectures are:)-6.11 E F4(x86)128 475.2 Q F0(Intel) + 5.56 E F2(IA-32)2.5 E F0(\(Pentium and abo)2.5 E -.15(ve)-.15 G(\)).15 E + F4(spar)128 492 Q(cv9)-.37 E F0(64\255bit)148 504 Q F2(SP)2.5 E(ARC) + -.828 E F0(V9)2.5 E F4(c)128 520.8 Q F0(Emit C code, not assembly)15.56 + E F3 -5.698108 537.6 S -4.438(ee)5.698 G -5.558(nn)4.438 G -4.998 + (aa)5.558 G -5.558(bb)4.998 G -2.778(ll)5.558 G -4.438(ee)2.778 G -3.328 + (--)4.438 G -4.438(cc)3.328 G -4.998(oo)4.438 G -4.438(rr)4.998 G 6.196 + -4.438(rr ee)4.438 H -4.438(cc)4.438 G -3.328(tt)4.438 G -3.328(--)3.328 + G -4.438(ee)3.328 G -5.558(hh)4.438 G -3.328(--)5.558 G -3.888(ss)3.328 + G -5.558(uu)3.888 G -5.558(pp)5.558 G -5.558(pp)5.558 G -4.998(oo)5.558 + G -4.438(rr)4.998 G -3.328(tt)4.438 G F0 .801(Instruct the)128 549.6 R + F3 -5.6983.301 G -2.778(ll)5.698 G 7.396 -4.998(oo w)2.778 H(we) + -2.22 E(er)-4.438 E(ri)-4.438 E(in)-2.778 E -.4(nv)-5.558 G -.1(vo) + -4.598 G(ok)-4.898 E -.1(ke)-5.558 G(e)-4.338 E F0 .802 + (pass to insert code for correct e)3.302 F .802 + (xception handling support.)-.15 F .802(This is e)5.802 F(xpen-)-.15 E + (si)128 561.6 Q .3 -.15(ve a)-.25 H(nd is by def).15 E + (ault omitted for ef)-.1 E(\214cienc)-.25 E -.65(y.)-.15 G F3 -5.698 + 108 578.4 S -5.558(hh)5.698 G -4.438(ee)5.558 G -2.778(ll)4.438 G + -5.558(pp)2.778 G F0(Print a summary of command line options.)128 590.4 + Q F3 -5.698108 607.2 S -3.888(ss)5.698 G -3.328(tt)3.888 G -4.998 + (aa)3.328 G -3.328(tt)4.998 G -3.888(ss)3.328 G F0 + (Print statistics recorded by code-generation passes.)128 619.2 Q F3 + -5.698108 636 S -3.328(tt)5.698 G -2.778(ii)3.328 G -8.328(mm) + 2.778 G -4.438(ee)8.328 G -3.328(--)4.438 G -5.558(pp)3.328 G -4.998(aa) + 5.558 G -3.888(ss)4.998 G -3.888(ss)3.888 G -4.438(ee)3.888 G -3.888(ss) + 4.438 G F0(Record the amount of time needed for each pass and print a r\ + eport to standard error)128 648 Q(.)-.55 E F3 -3.888(II)108 670.8 S + -5.558(nn)3.888 G -3.328(tt)5.558 G -4.438(ee)3.328 G 5.556 -2.778(ll I) + 4.438 H(IA)-1.11 E(A-)-7.218 E(-3)-3.328 E(32)-4.998 E<32ad>-4.998 E + -5.698 E(sp)-3.888 E(pe)-5.558 E(ec)-4.438 E(ci)-4.438 E<698c> + -2.778 E<8c63>-5.558 E 2.5(cO)-4.438 G(Op)-10.278 E(pt)-5.558 E(ti) + -3.328 E(io)-2.778 E(on)-4.998 E(ns)-5.558 E(s)-3.888 E 19.162 -9.998 + <8a8a2064>109.666 692.4 T(di)4.44 E(is)-2.778 E(sa)-3.888 E(ab)-4.998 E + (bl)-5.558 E(le)-2.778 E(e-)-4.438 E(-f)-3.328 E(fp)-3.328 E(p-)-5.558 E + (-e)-3.328 E(el)-4.438 E(li)-2.778 E(im)-2.778 E(m)-8.328 E F0 + (Disable frame pointer elimination optimization.)128 704.4 Q 178.59 + (2004-07-04 1.3)72 768 R(1)222.75 E EP + %%Page: 2 2 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 151.73(LLC\(1\) LL)72 48 R(VM Command Guide)-1 E + (LLC\(1\))154.23 E/F1 10/Times-Bold at 0 SF 19.162 -9.998<8a8a2064>109.666 + 84 T(di)4.44 E(is)-2.778 E(sa)-3.888 E(ab)-4.998 E(bl)-5.558 E(le)-2.778 + E(e-)-4.438 E(-p)-3.328 E(pa)-5.558 E(at)-4.998 E(tt)-3.328 E(te)-3.328 + E(er)-4.438 E -.15(rn)-4.438 G(n-)-5.408 E(-i)-3.328 E(is)-2.778 E(se) + -3.888 E(el)-4.438 E(l)-2.778 E F0(Use the ')128 96 Q + (simple' X86 instruction selector \(the def)-.55 E(ault\).)-.1 E F1 + 19.162 -9.998<8a8a2070>109.666 112.8 T(pr)4.44 E(ri)-4.438 E(in)-2.778 E + (nt)-5.558 E(t-)-3.328 E(-m)-3.328 E(ma)-8.328 E(ac)-4.998 E(ch)-4.438 E + (hi)-5.558 E(in)-2.778 E(ne)-5.558 E(ei)-4.438 E(in)-2.778 E(ns)-5.558 E + (st)-3.888 E(tr)-3.328 E(rs)-4.438 E(s)-3.888 E F0 + (Print generated machine code.)128 124.8 Q F1 19.162 -9.998<8a8a2072> + 109.666 141.6 T -.18(re)5.56 G(eg)-4.258 E(ga)-4.998 E(al)-4.998 E(ll) + -2.778 E(lo)-2.778 E(oc)-4.998 E(c)-4.438 E F0(=)A/F2 10/Times-Italic at 0 + SF(allocator)A F0(Specify the re)128 153.6 Q + (gister allocator to use. The def)-.15 E(ault)-.1 E F2(allocator)2.5 E + F0(is)2.5 E F2(local)2.5 E F0 5(.V)C(alid re)-6.11 E + (gister allocators are:)-.15 E F2(simple)128 170.4 Q F0 -1.11(Ve)148 + 182.4 S(ry simple `)1.11 E(`al)-.74 E -.1(wa)-.1 G(ys spill').1 E 2.5 + ('r)-.74 G -.15(eg)-2.5 G(ister allocator).15 E F2(local)128 199.2 Q F0 + (Local re)148 211.2 Q(gister allocator)-.15 E F2(linear)128 228 Q(scan) + -.1 E F0(Linear scan global re)148 240 Q(gister allocator \(e)-.15 E + (xperimental\))-.15 E F1 19.162 -9.998<8a8a2073>109.666 256.8 T(sp)6.11 + E(pi)-5.558 E(il)-2.778 E(ll)-2.778 E(le)-2.778 E(er)-4.438 E(r)-4.438 E + F0(=)A F2(spiller)A F0 .798(Specify the spiller to use for re)128 268.8 + R .798(gister allocators that support it.)-.15 F .797 + (Currently this option is used only by)5.798 F(the linear scan re)128 + 280.8 Q(gister allocator)-.15 E 2.5(.T)-.55 G(he def)-2.5 E(ault)-.1 E + F2(spiller)2.5 E F0(is)2.5 E F2(local)2.5 E F0 5(.V)C + (alid spillers are:)-6.11 E F2(simple)128 297.6 Q F0(Simple spiller)148 + 309.6 Q F2(local)128 326.4 Q F0(Local spiller)148 338.4 Q F1 -5.558(SS) + 108 361.2 S 8.976 -6.108(PP A)5.558 H(AR)-1.11 E(RC)-7.218 E(CV)-7.218 E + (V9)-7.218 E<39ad>-4.998 E-5.698 E(sp)-3.888 E(pe)-5.558 E(ec) + -4.438 E(ci)-4.438 E<698c>-2.778 E<8c63>-5.558 E 2.5(cO)-4.438 G(Op) + -10.278 E(pt)-5.558 E(ti)-3.328 E(io)-2.778 E(on)-4.998 E(ns)-5.558 E(s) + -3.888 E 19.162 -9.998<8a8a2064>109.666 382.8 T(di)4.44 E(is)-2.778 E + (sa)-3.888 E(ab)-4.998 E(bl)-5.558 E(le)-2.778 E(e-)-4.438 E(-p)-3.328 E + (pe)-5.558 E(ee)-4.438 E(ep)-4.438 E(ph)-5.558 E(ho)-5.558 E(ol)-4.998 E + (le)-2.778 E(e)-4.438 E F0(Disable peephole optimization pass.)128 394.8 + Q F1 19.162 -9.998<8a8a2064>109.666 411.6 T(di)4.44 E(is)-2.778 E(sa) + -3.888 E(ab)-4.998 E(bl)-5.558 E(le)-2.778 E(e-)-4.438 E(-s)-3.328 E(sc) + -3.888 E(ch)-4.438 E(he)-5.558 E(ed)-4.438 E(d)-5.558 E F0 + (Disable local scheduling pass.)128 423.6 Q F1 19.162 -9.998<8a8a2064> + 109.666 440.4 T(di)4.44 E(is)-2.778 E(sa)-3.888 E(ab)-4.998 E(bl)-5.558 + E(le)-2.778 E(e-)-4.438 E(-s)-3.328 E(st)-3.888 E(tr)-3.328 E(ri)-4.438 + E(ip)-2.778 E(p)-5.558 E F0 1.094(The Sparc back)128 452.4 R 1.094 + (end embeds the)-.1 F/F3 9/Times-Roman at 0 SF(LL)3.594 E(VM)-.9 E F0 1.095 + (bytecode into the assembly output.)3.594 F 1.095 + (This option requests that)6.095 F(symbol names be retained; by def)128 + 464.4 Q(ault, the)-.1 E 2.5(ya)-.15 G(re stripped out.)-2.5 E F1 19.162 + -9.998<8a8a2065>109.666 481.2 T(en)5.56 E(na)-5.558 E(ab)-4.998 E(bl) + -5.558 E(le)-2.778 E(e-)-4.438 E(-m)-3.328 E(ma)-8.328 E(ap)-4.998 E(ps) + -5.558 E(s)-3.888 E F0(Emit LL)128 493.2 Q + (VM-to-machine code mapping information into the assembly output.)-1 E + /F4 10.95/Times-Bold at 0 SF -7.302(EE)72 510 S -7.904(XX)7.302 G -4.258 + (II)7.904 G 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 G + -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F0(If)108 522 Q F1 + -2.778(ll)2.5 G -2.778(ll)2.778 G -4.438(cc)2.778 G F0 + (succeeds, it will e)6.938 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F4 -6.086(SS)72 538.8 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0(lli)108 + 550.8 Q F4 12.522 -7.904(AA UU)72 567.6 T -7.302(TT)7.904 G -8.517(HH) + 7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 579.6 Q F3(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(2) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/lli.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/lli.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/lli.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,294 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 155.07(LLI\(1\) LL)72 48 R(VM Command Guide)-1 E + (LLI\(1\))157.57 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T + -10.335(MM)7.904 G -7.302(EE)10.335 G F0(lli \255 directly e)108 96 Q + -.15(xe)-.15 G(cute programs from).15 E/F2 9/Times-Roman at 0 SF(LL)2.5 E + (VM)-.9 E F0(bytecode)2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G + -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G + -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -2.778(ll)108 + 124.8 S -2.778(ll)2.778 G -2.778(ii)2.778 G F0([)5.278 E/F4 10 + /Times-Italic at 0 SF(options)A F0 2.5(][)C F4(\214lename)-2.5 E F0 2.5(][) + C F4(pr)-2.5 E -.1(og)-.45 G -.15(ra).1 G 2.5(ma).15 G -.37(rg)-2.5 G(s) + .37 E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G + -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G + -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G + F3 -2.778(ll)108 153.6 S -2.778(ll)2.778 G -2.778(ii)2.778 G F0 .414 + (directly e)5.692 F -.15(xe)-.15 G .413(cutes programs in).15 F F2(LL) + 2.913 E(VM)-.9 E F0 .413(bytecode format.)2.913 F .413(It tak)5.413 F + .413(es a program in)-.1 F F2(LL)2.913 E(VM)-.9 E F0 .413 + (bytecode format and)2.913 F -.15(exe)108 165.6 S .14 + (cutes it using a just-in-time compiler).15 F 2.641(,i)-.4 G 2.641(fo) + -2.641 G .141(ne is a)-2.641 F -.25(va)-.2 G .141 + (ilable for the current architecture, or an interpreter).25 F(.)-.55 E + F3 -2.778(ll)5.141 G -2.778(ll)2.778 G -2.778(ii)2.778 G F0(tak)108 + 177.6 Q .505(es all of the same code generator options as llc, b)-.1 F + .505(ut the)-.2 F 3.005(ya)-.15 G .505(re only ef)-3.005 F(fecti)-.25 E + .805 -.15(ve w)-.25 H(hen).15 E F3 -2.778(ll)3.005 G -2.778(ll)2.778 G + -2.778(ii)2.778 G F0 .505(is using the just-in-)5.783 F(time compiler) + 108 189.6 Q(.)-.55 E(If)108 206.4 Q F4(\214lename)2.5 E F0 + (is not speci\214ed, then)2.5 E F3 -2.778(ll)2.5 G -2.778(ll)2.778 G + -2.778(ii)2.778 G F0(reads the)5.278 E F2(LL)2.5 E(VM)-.9 E F0 + (bytecode for the program from standard input.)2.5 E(The optional)108 + 223.2 Q F4(ar)2.5 E(gs)-.37 E F0 + (speci\214ed on the command line are passed to the program as ar)2.5 E + (guments.)-.18 E F1 -8.517(OO)72 240 S -6.688(PP)8.517 G -7.302(TT)6.688 + G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G -6.086(SS)7.904 + G F3 -5.698108 252 S -5.558(hh)5.698 G -4.438(ee)5.558 G -2.778 + (ll)4.438 G -5.558(pp)2.778 G F0 + (Print a summary of command line options.)128 264 Q F3 -5.698108 + 280.8 S -3.888(ss)5.698 G -3.328(tt)3.888 G -4.998(aa)3.328 G -3.328(tt) + 4.998 G -3.888(ss)3.328 G F0 .422(Print statistics from the code-genera\ + tion passes. This is only meaningful for the just-in-time compiler)128 + 292.8 R(,)-.4 E(at present.)128 304.8 Q F3 -5.698108 321.6 S + -3.328(tt)5.698 G -2.778(ii)3.328 G -8.328(mm)2.778 G -4.438(ee)8.328 G + -3.328(--)4.438 G -5.558(pp)3.328 G -4.998(aa)5.558 G -3.888(ss)4.998 G + -3.888(ss)3.888 G -4.438(ee)3.888 G -3.888(ss)4.438 G F0(Record the amo\ + unt of time needed for each code-generation pass and print it to standa\ + rd error)128 333.6 Q(.)-.55 E F3 -5.698108 350.4 S -8.328(mm)5.698 + G -4.998(aa)8.328 G 6.196 -4.438(rr cc)4.998 H -5.558(hh)4.438 G F0(=) + 5.558 E F4(ar)A -.15(ch)-.37 G F0 1.303(Use the speci\214ed non-def)128 + 362.4 R 1.302(ault architecture arch when selecting a code generator fo\ + r the just-in-time)-.1 F(compiler)128 374.4 Q 2.753(.T)-.55 G .253(his \ + may result in a crash if you pick an architecture which is not compatib\ + le with the hard-)-2.753 F -.1(wa)128 386.4 S(re you are running).1 E F3 + -2.778(ll)2.5 G -2.778(ll)2.778 G -2.778(ii)2.778 G F0(on.)5.278 E F3 + -5.698108 403.2 S 3.906 -3.328(ff o)5.698 H(or)-1.67 E -.18(rc) + -4.438 G(ce)-4.258 E(e-)-4.438 E(-i)-3.328 E(in)-2.778 E(nt)-5.558 E(te) + -3.328 E(er)-4.438 E -.1(rp)-4.438 G(pr)-5.458 E -.18(re)-4.438 G(et) + -4.258 E(te)-3.328 E(er)-4.438 E(r)-4.438 E F0(=)A F4({false)A(,true}) + -.1 E F0 1.989(If set to true, use the interpreter e)128 415.2 R -.15 + (ve)-.25 G 4.489(ni).15 G 4.489(faj)-4.489 G 1.989 + (ust-in-time compiler is a)-4.489 F -.25(va)-.2 G 1.988 + (ilable for this architecture.).25 F(Def)128 427.2 Q(aults to f)-.1 E + (alse.)-.1 E F3 -5.698108 444 S -3.328(ff)5.698 G F0(=)3.328 E F4 + (name)A F0 .441(Call the function named)128 456 R F4(name)2.941 E F0 + .442(to start the program.)2.941 F .442 + (Note: The function is assumed to ha)5.442 F .742 -.15(ve t)-.2 H .442 + (he C sig-).15 F(nature)128 468 Q/F5 10/Courier at 0 SF(int)2.745 E F4 + (name)2.745 E F5 .244(\(int, char **, char **\))2.745 F F0 5.244(.I)C + 2.744(fy)-5.244 G .244(ou try to use this option to call a function of) + -2.744 F(incompatible type, unde\214ned beha)128 480 Q + (vior may result. Def)-.2 E(aults to)-.1 E F5(main)2.5 E F0(.)A F1 + -7.302(EE)72 496.8 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302 + (TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E + (US)-7.904 E(S)-6.086 E F0(If)108 508.8 Q F3 -2.778(ll)2.962 G -2.778 + (ll)2.778 G -2.778(ii)2.778 G F0 -.1(fa)5.74 G .463 + (ils to load the program, it will e).1 F .463(xit with an e)-.15 F .463 + (xit code of 1.)-.15 F .463(Otherwise, it will return the e)5.463 F .463 + (xit code of)-.15 F(the program it e)108 520.8 Q -.15(xe)-.15 G(cutes.) + .15 E F1 -6.086(SS)72 537.6 S -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 + H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0(llc)108 549.6 Q F1 + 12.522 -7.904(AA UU)72 566.4 T -7.302(TT)7.904 G -8.517(HH)7.302 G + -8.517(OO)8.517 G -7.904(RR)8.517 G F0(Maintained by the)108 578.4 Q F2 + (LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E + 178.59(2004-07-04 1.3)72 768 R(1)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-as.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-as.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-as.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,290 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 127.18(VM-AS\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)129.68 E(VM-AS\(1\))-1 E/F1 10.95/Times-Bold at 0 + SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302(EE)10.335 G F0 + (llvm-as \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0 + (assembler)2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN) + 7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II) + 6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -2.778(ll)108 124.8 S + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G + -4.998(aa)3.328 G -3.888(ss)4.998 G F0([)6.388 E/F4 10/Times-Italic at 0 SF + (options)A F0 2.5(][)C F4(\214lename)-2.5 E F0(])A F1 -7.904(DD)72 141.6 + S -7.302(EE)7.904 G -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 + G -4.258(II)7.904 G -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 + G -8.517(OO)4.258 G -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -2.778(ll) + 4.504 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--) + 8.328 G -4.998(aa)3.328 G -3.888(ss)4.998 G F0 2.004(command in)8.392 F + -.2(vo)-.4 G -.1(ke).2 G 4.504(st).1 G(he)-4.504 E F2(LL)4.504 E(VM)-.9 + E F0(assembler)4.504 E 7.004(.I)-.55 G 4.504(tr)-7.004 G 2.004 + (eads a \214le containing human-readable)-4.504 F F2(LL)4.504 E(VM)-.9 E + F0(assembly language, translates it to)108 165.6 Q F2(LL)2.5 E(VM)-.9 E + F0(bytecode, and writes the result into a \214le or to standard output.) + 2.5 E(If)108 182.4 Q F4(\214lename)2.5 E F0(is omitted or is)2.5 E/F5 10 + /Courier at 0 SF2.5 E F0 2.5(,t)C(hen)-2.5 E F3 -2.778(ll)2.5 G -2.778 + (ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -4.998 + (aa)3.328 G -3.888(ss)4.998 G F0(reads its input from standard input.) + 6.388 E .14(If an output \214le is not speci\214ed with the)108 199.2 R + F3 -5.6982.64 G -4.998(oo)5.698 G F0 .141(option, then)7.639 F F3 + -2.778(ll)2.641 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -4.998(aa)3.328 G -3.888(ss)4.998 G F0 .141 + (sends its output to a \214le or standard output)6.529 F(by follo)108 + 211.2 Q(wing these rules:)-.25 E 16.5<8349>108 228 S 2.5(ft)-16.5 G + (he input is standard input, then the output is standard output.)-2.5 E + 16.5<8349>108 244.8 S 2.803(ft)-16.5 G .303 + (he input is a \214le that ends with)-2.803 F F5(.ll)2.802 E F0 2.802 + (,t)C .302(hen the output \214le is of the same name, e)-2.802 F .302 + (xcept that the suf)-.15 F<8c78>-.25 E(is changed to)128 256.8 Q F5(.bc) + 2.5 E F0(.)A 16.5<8349>108 273.6 S 2.565(ft)-16.5 G .065 + (he input is a \214le that does not end with the)-2.565 F F5(.ll)2.565 E + F0(suf)2.565 E .065 + (\214x, then the output \214le has the same name as the)-.25 F + (input \214le, e)128 285.6 Q(xcept that the)-.15 E F5(.bc)2.5 E F0(suf) + 2.5 E(\214x is appended.)-.25 E F1 -8.517(OO)72 302.4 S -6.688(PP)8.517 + G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 + G -6.086(SS)7.904 G F3 -5.698108 314.4 S -3.328(ff)5.698 G F0 -.15 + (Fo)14.294 G 1.059(rce o).15 F -.15(ve)-.15 G 3.559(rwrite. Normally).15 + F(,)-.65 E F3 -2.778(ll)3.559 G -2.778(ll)2.778 G -4.998(vv)2.778 G + -8.328(mm)4.998 G -3.328(--)8.328 G -4.998(aa)3.328 G -3.888(ss)4.998 G + F0 1.059(will refuse to o)7.447 F -.15(ve)-.15 G 1.059 + (rwrite an output \214le that already e).15 F 3.559(xists. W)-.15 F(ith) + -.4 E(this option,)128 326.4 Q F3 -2.778(ll)2.5 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -4.998(aa)3.328 G + -3.888(ss)4.998 G F0(will o)6.388 E -.15(ve)-.15 G + (rwrite the output \214le and replace it with ne).15 E 2.5(wb)-.25 G + (ytecode.)-2.5 E F3 19.162 -9.998<8a8a2068>109.666 343.2 T(he)4.44 E(el) + -4.438 E(lp)-2.778 E(p)-5.558 E F0 + (Print a summary of command line options.)128 355.2 Q F3 -5.698108 + 372 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 + (Specify the output \214le name.)128 384 Q(If)5 E F4(\214lename)2.5 E F0 + (is)2.5 E F52.5 E F0 2.5(,t)C(hen)-2.5 E F3 -2.778(ll)2.5 G -2.778 + (ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -4.998 + (aa)3.328 G -3.888(ss)4.998 G F0(sends its output to standard output.) + 6.388 E F3 19.162 -9.998<8a8a2073>109.666 400.8 T(st)6.11 E(ta)-3.328 E + (at)-4.998 E(ts)-3.328 E(s)-3.888 E F0(Print statistics.)128 412.8 Q F3 + 19.162 -9.998<8a8a2074>109.666 429.6 T(ti)6.67 E(im)-2.778 E(me)-8.328 E + (e-)-4.438 E(-p)-3.328 E(pa)-5.558 E(as)-4.998 E(ss)-3.888 E(se)-3.888 E + (es)-4.438 E(s)-3.888 E F0(Record the amount of time needed for each pa\ + ss and print it to standard error)128 441.6 Q(.)-.55 E F1 -7.302(EE)72 + 458.4 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H + (ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E + (S)-6.086 E F0(If)108 470.4 Q F3 -2.778(ll)2.5 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -4.998(aa)3.328 G + -3.888(ss)4.998 G F0(succeeds, it will e)6.388 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 487.2 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0 + (llvm-dis, gccas)108 499.2 Q F1 12.522 -7.904(AA UU)72 516 T -7.302(TT) + 7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS) + 7.904 G F0(Maintained by the)108 528 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te) + 2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 + R(1)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-bcanalyzer.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-bcanalyzer.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-bcanalyzer.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,302 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:17 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q(VM-BCAN)-1 E(AL)-.35 E 74.09 + (YZER\(1\) LL)-1 F(VM Command Guide)-1 E(LL)76.59 E(VM-BCAN)-1 E(AL)-.35 + E(YZER\(1\))-1 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T + -10.335(MM)7.904 G -7.302(EE)10.335 G F0(llvm-bcanalyzer \255)108 96 Q + /F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(bytecode analyzer)2.5 E F1 + -6.086(SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 + G -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 + G/F3 10/Times-Bold at 0 SF -2.778(ll)108 124.8 S -2.778(ll)2.778 G -4.998 + (vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(bb)3.328 G -4.438 + (cc)5.558 G -4.998(aa)4.438 G -5.558(nn)4.998 G -4.998(aa)5.558 G -2.778 + (ll)4.998 G -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee)4.438 G -4.438 + (rr)4.438 G F0([)6.938 E/F4 10/Times-Italic at 0 SF(options)A F0 2.5(][)C + F4(\214lename)-2.5 E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G + -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G + -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -2.778(ll)3.358 G -2.778(ll) + 2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(bb) + 3.328 G -4.438(cc)5.558 G -4.998(aa)4.438 G -5.558(nn)4.998 G -4.998(aa) + 5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee) + 4.438 G -4.438(rr)4.438 G F0 .857 + (command is a small utility for analyzing bytecode \214les.)7.796 F .857 + (The tool reads a bytecode)5.857 F 2.065 + (\214le \(such as generated with the)108 165.6 R F3 -2.778(ll)4.565 G + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G + -4.998(aa)3.328 G -3.888(ss)4.998 G F0 2.065 + (tool\) and produces a statistical report on the contents of the)8.453 F + .787(byteocde \214le.)108 177.6 R .787(The tool will also dump a lo) + 5.787 F 3.287(wl)-.25 G -2.15 -.25(ev e)-3.287 H 3.287(lb).25 G .787 + (ut human readable v)-3.487 F .786(ersion of the bytecode \214le.)-.15 F + (This)5.786 E .447(tool is probably not of much interest or utility e) + 108 189.6 R .447(xcept for those w)-.15 F .448 + (orking directly with the bytecode \214le for)-.1 F(-)-.2 E(mat. Most) + 108 201.6 Q F2(LL)2.5 E(VM)-.9 E F0(users can just ignore this tool.)2.5 + E(If)108 218.4 Q F4(\214lename)3.143 E F0 .643(is omitted or is)3.143 F + /F5 10/Courier at 0 SF3.142 E F0 3.142(,t)C(hen)-3.142 E F3 -2.778(ll) + 3.142 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--) + 8.328 G -5.558(bb)3.328 G -4.438(cc)5.558 G -4.998(aa)4.438 G -5.558(nn) + 4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz) + 4.998 G -4.438(ee)4.438 G -4.438(rr)4.438 G F0 .642 + (reads its input from standard input. This is useful for)7.58 F + (combining the tool into a pipeline.)108 230.4 Q + (Output is written to the standard output.)108 247.2 Q F1 -8.517(OO)72 + 264 S -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO) + 4.258 G -7.904(NN)8.517 G -6.086(SS)7.904 G F3 -5.698108 276 S + -5.558(nn)5.698 G -4.998(oo)5.558 G -5.558(dd)4.998 G -4.438(ee)5.558 G + -3.328(tt)4.438 G -4.998(aa)3.328 G -2.778(ii)4.998 G -2.778(ll)2.778 G + -3.888(ss)2.778 G F0(Causes)128 288 Q F3 -2.778(ll)3.787 G -2.778(ll) + 2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(bb) + 3.328 G -4.438(cc)5.558 G -4.998(aa)4.438 G -5.558(nn)4.998 G -4.998(aa) + 5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz)4.998 G -4.438(ee) + 4.438 G -4.438(rr)4.438 G F0 1.287(to abbre)8.225 F 1.287 + (viate its output by writing out only a module le)-.25 F -.15(ve)-.25 G + 3.788(ls).15 G(ummary)-3.788 E 3.788(.T)-.65 G(he)-3.788 E + (details for indi)128 300 Q(vidual functions are not displayed.)-.25 E + F3 -5.698108 316.8 S -5.558(dd)5.698 G -5.558(uu)5.558 G -8.328 + (mm)5.558 G -5.558(pp)8.328 G F0(Causes)128 328.8 Q F3 -2.778(ll)3.855 G + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G + -5.558(bb)3.328 G -4.438(cc)5.558 G -4.998(aa)4.438 G -5.558(nn)4.998 G + -4.998(aa)5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz)4.998 G + -4.438(ee)4.438 G -4.438(rr)4.438 G F0 1.354(to dump the bytecode in a \ + human readable format. This format is signi\214-)8.293 F(cantly dif)128 + 340.8 Q(ferent from)-.25 E F2(LL)2.5 E(VM)-.9 E F0(assembly and pro)2.5 + E(vides details about the encoding of the bytecode \214le.)-.15 E F3 + -5.698108 357.6 S 7.396 -4.998(vv e)5.698 H(er).56 E(ri)-4.438 E + (if)-2.778 E(fy)-3.328 E(y)-4.998 E F0(Causes)128 369.6 Q F3 -2.778(ll) + 2.874 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--) + 8.328 G -5.558(bb)3.328 G -4.438(cc)5.558 G -4.998(aa)4.438 G -5.558(nn) + 4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz) + 4.998 G -4.438(ee)4.438 G -4.438(rr)4.438 G F0 .374(to v)7.312 F .374(e\ + rify the module produced by by reading the bytecode. This ensures that) + -.15 F(the statistics generated are based on a consistent module.)128 + 381.6 Q F3 19.162 -9.998<8a8a2068>109.666 398.4 T(he)4.44 E(el)-4.438 E + (lp)-2.778 E(p)-5.558 E F0(Print a summary of command line options.)128 + 410.4 Q F1 -7.302(EE)72 427.2 S -7.904(XX)7.302 G -4.258(II)7.904 G + 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 + G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F0(If)108 439.2 Q F3 -2.778(ll) + 2.985 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--) + 8.328 G -5.558(bb)3.328 G -4.438(cc)5.558 G -4.998(aa)4.438 G -5.558(nn) + 4.998 G -4.998(aa)5.558 G -2.778(ll)4.998 G -4.998(yy)2.778 G -4.438(zz) + 4.998 G -4.438(ee)4.438 G -4.438(rr)4.438 G F0 .485(succeeds, it will e) + 7.423 F .485(xit with 0.)-.15 F .485 + (Otherwise, if an error occurs, it will e)5.485 F .485 + (xit with a non-zero)-.15 F -.25(va)108 451.2 S(lue, usually 1.).25 E F1 + -6.086(SS)72 468 S -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL)-.602 + E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0 + (llvm-dis, http://llvm.cs.uiuc.edu/docs/BytecodeF)108 480 Q(ormat.html) + -.15 E F1 12.522 -7.904(AA UU)72 496.8 T -7.302(TT)7.904 G -8.517(HH) + 7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 508.8 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-02 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-db.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-db.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-db.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,220 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 126.07(VM-DB\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)128.57 E(VM-DB\(1\))-1 E/F1 10.95/Times-Bold at 0 + SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302(EE)10.335 G F0 + (llvm-db \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(deb) + 2.5 E(ugger \(alpha\))-.2 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G + -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G + -4.258(II)6.086 G -6.086(SS)4.258 G F0 .398 + (Details coming soon. Please see http://llvm.cs.uiuc.edu/docs/SourceLe) + 108 124.8 R -.15(ve)-.25 G(lDeb).15 E .397(ugging.html in the meantime.) + -.2 F F1 12.522 -7.904(AA UU)72 141.6 T -7.302(TT)7.904 G -8.517(HH) + 7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 153.6 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-dis.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-dis.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-dis.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,282 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 123.85(VM-DIS\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)126.35 E(VM-DIS\(1\))-1 E/F1 10.95 + /Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302 + (EE)10.335 G F0(llvm-dis \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E + (VM)-.9 E F0(disassembler)2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 + G -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 + G -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -2.778(ll) + 108 124.8 S -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328 + (--)8.328 G -5.558(dd)3.328 G -2.778(ii)5.558 G -3.888(ss)2.778 G F0([) + 6.388 E/F4 10/Times-Italic at 0 SF(options)A F0 2.5(][)C F4(\214lename)-2.5 + E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G + -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G + -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G + F0(The)108 153.6 Q F3 -2.778(ll)4.037 G -2.778(ll)2.778 G -4.998(vv) + 2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(dd)3.328 G -2.778(ii) + 5.558 G -3.888(ss)2.778 G F0 1.537(command is the)7.925 F F2(LL)4.036 E + (VM)-.9 E F0(disassembler)4.036 E 6.536(.I)-.55 G 4.036(tt)-6.536 G(ak) + -4.036 E 1.536(es an)-.1 F F2(LL)4.036 E(VM)-.9 E F0 1.536 + (bytecode \214le and con)4.036 F -.15(ve)-.4 G 1.536(rts it into).15 F + (human-readable)108 165.6 Q F2(LL)2.5 E(VM)-.9 E F0(assembly language.) + 2.5 E(If \214lename is omitted or speci\214ed as)108 182.4 Q/F5 10 + /Courier at 0 SF2.5 E F0(,)A F3 -2.778(ll)2.5 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(dd)3.328 G + -2.778(ii)5.558 G -3.888(ss)2.778 G F0 + (reads its input from standard input.)6.388 E 1.515 + (If the input is being read from standard input, then)108 199.2 R F3 + -2.778(ll)4.015 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -5.558(dd)3.328 G -2.778(ii)5.558 G -3.888(ss)2.778 G + F0 1.516(will send its output to standard output by)7.903 F(def)108 + 211.2 Q 3.156(ault. Otherwise,)-.1 F .655(the output will be written to\ + a \214le named after the input \214le, with a)3.156 F F5(.ll)3.155 E F0 + (suf)3.155 E .655(\214x added)-.25 F(\(an)108 223.2 Q 3.674(ye)-.15 G + (xisting)-3.824 E F5(.bc)3.674 E F0(suf)3.674 E 1.175 + (\214x will \214rst be remo)-.25 F -.15(ve)-.15 G 3.675(d\). Y).15 F + 1.175(ou can o)-1.1 F -.15(ve)-.15 G 1.175 + (rride the choice of output \214le using the).15 F F3 -5.6983.675 + G -4.998(oo)5.698 G F0(option.)108 235.2 Q F1 -8.517(OO)72 252 S -6.688 + (PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904 + (NN)8.517 G -6.086(SS)7.904 G F3 -5.698108 264 S -3.328(ff)5.698 G + F0 -.15(Fo)14.294 G .821(rce o).15 F -.15(ve)-.15 G 3.321 + (rwrite. Normally).15 F(,)-.65 E F3 -2.778(ll)3.321 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(dd)3.328 G + -2.778(ii)5.558 G -3.888(ss)2.778 G F0 .82(will refuse to o)7.209 F -.15 + (ve)-.15 G .82(rwrite an output \214le that already e).15 F 3.32 + (xists. W)-.15 F(ith)-.4 E(this option,)128 276 Q F3 -2.778(ll)2.5 G + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G + -5.558(dd)3.328 G -2.778(ii)5.558 G -3.888(ss)2.778 G F0(will o)6.388 E + -.15(ve)-.15 G(rwrite the output \214le.).15 E F3 19.162 -9.998 + <8a8a2068>109.666 292.8 T(he)4.44 E(el)-4.438 E(lp)-2.778 E(p)-5.558 E + F0(Print a summary of command line options.)128 304.8 Q F3 -5.698 + 108 321.6 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 + (Specify the output \214le name.)128 333.6 Q(If)5 E F4(\214lename)2.5 E + F0(is \255, then the output is sent to standard output.)2.5 E F3 -5.698 + 108 350.4 S -3.328(tt)5.698 G -2.778(ii)3.328 G -8.328(mm)2.778 G + -4.438(ee)8.328 G -3.328(--)4.438 G -5.558(pp)3.328 G -4.998(aa)5.558 G + -3.888(ss)4.998 G -3.888(ss)3.888 G -4.438(ee)3.888 G -3.888(ss)4.438 G + F0(Record the amount of time needed for each pass and print it to stand\ + ard error)128 362.4 Q(.)-.55 E F1 -7.302(EE)72 379.2 S -7.904(XX)7.302 G + -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986(TA)-7.302 + G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F0(If)108 391.2 Q + F3 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -5.558(dd)3.328 G -2.778(ii)5.558 G -3.888(ss)2.778 G + F0(succeeds, it will e)6.388 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 408 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0(llvm-as) + 108 420 Q F1 12.522 -7.904(AA UU)72 436.8 T -7.302(TT)7.904 G -8.517(HH) + 7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 448.8 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-link.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-link.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-link.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,301 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 116.08(VM-LINK\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)118.58 E(VM-LINK\(1\))-1 E/F1 10.95 + /Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302 + (EE)10.335 G F0(llvm-link \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E + (VM)-.9 E F0(link)2.5 E(er)-.1 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 + G -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 + G -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -2.778(ll) + 108 124.8 S -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328 + (--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(nn)2.778 G -5.558 + (kk)5.558 G F0([)8.058 E/F4 10/Times-Italic at 0 SF(options)A F0(])A F4 + (\214lename ...)2.5 E F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086 + (SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688 + (PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904 + (NN)8.517 G F0(The)108 153.6 Q F3 -2.778(ll)3.814 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -2.778(ll)3.328 G + -2.778(ii)2.778 G -5.558(nn)2.778 G -5.558(kk)5.558 G F0 1.314 + (command tak)9.372 F 1.314(es se)-.1 F -.15(ve)-.25 G(ral).15 E F2(LL) + 3.814 E(VM)-.9 E F0 1.314 + (bytecode \214les and links them together into a single)3.814 F F2(LL) + 3.813 E(VM)-.9 E F0 .171(bytecode \214le.)108 165.6 R .172 + (It writes the output \214le to standard output, unless the)5.171 F F3 + -5.6982.672 G -4.998(oo)5.698 G F0 .172 + (option is used to specify a \214lename.)7.67 F(The)108 182.4 Q F3 + -2.778(ll)2.731 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(nn)2.778 G + -5.558(kk)5.558 G F0 .231 + (command attempts to load the input \214les from the current directory) + 8.289 F 5.23(.I)-.65 G 2.73(ft)-5.23 G .23(hat f)-2.73 F .23 + (ails, it looks for)-.1 F 1.002 + (each \214le in each of the directories speci\214ed by the)108 194.4 R + F3 -5.6983.502 G -6.668(LL)5.698 G F0 1.002 + (options on the command line.)10.17 F 1.002(The library search)6.002 F + .578(paths are global; each one is searched for e)108 206.4 R -.15(ve) + -.25 G .578(ry input \214le if necessary).15 F 5.578(.T)-.65 G .577 + (he directories are searched in the)-5.578 F(order the)108 218.4 Q 2.5 + (yw)-.15 G(ere speci\214ed on the command line.)-2.5 E F1 -8.517(OO)72 + 235.2 S -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO) + 4.258 G -7.904(NN)8.517 G -6.086(SS)7.904 G F3 -5.698108 247.2 S + -6.668(LL)5.698 G F4(dir)9.168 E(ectory)-.37 E F0 .344 + (Add the speci\214ed)128 259.2 R F4(dir)2.844 E(ectory)-.37 E F0 .345 + (to the library search path.)2.845 F .345(When looking for libraries,) + 5.345 F F3 -2.778(ll)2.845 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328 + (mm)4.998 G -3.328(--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558 + (nn)2.778 G -5.558(kk)5.558 G F0 .345(will look)8.403 F 1.215 + (in pathname for libraries.)128 271.2 R 1.214 + (This option can be speci\214ed multiple times;)6.215 F F3 -2.778(ll) + 3.714 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--) + 8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(nn)2.778 G -5.558(kk) + 5.558 G F0 1.214(will search inside)9.272 F + (these directories in the order in which the)128 283.2 Q 2.5(yw)-.15 G + (ere speci\214ed on the command line.)-2.5 E F3 -5.698108 300 S + -3.328(ff)5.698 G F0(Ov)14.294 E(erwrite output \214les.)-.15 E(By def)5 + E(ault,)-.1 E F3 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998(vv)2.778 G + -8.328(mm)4.998 G -3.328(--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G + -5.558(nn)2.778 G -5.558(kk)5.558 G F0(will not o)8.058 E -.15(ve)-.15 G + (rwrite an output \214le if it alreadys e).15 E(xists.)-.15 E F3 -5.698 + 108 316.8 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 + (Specify the output \214le name.)128 328.8 Q(If)5 E F4(\214lename)2.5 E + F0(is)2.5 E/F5 10/Courier at 0 SF2.5 E F0 2.5(,t)C(hen)-2.5 E F3 -2.778 + (ll)2.5 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328 + (--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(nn)2.778 G -5.558 + (kk)5.558 G F0(will write its output to standard output.)8.058 E F3 + -5.698108 345.6 S -5.558(dd)5.698 G F0(If speci\214ed,)14.294 E F3 + -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(nn)2.778 G + -5.558(kk)5.558 G F0(prints a human-readable v)8.058 E + (ersion of the output bytecode \214le to standard error)-.15 E(.)-.55 E + F3 19.162 -9.998<8a8a2068>109.666 362.4 T(he)4.44 E(el)-4.438 E(lp) + -2.778 E(p)-5.558 E F0(Print a summary of command line options.)128 + 374.4 Q F3 -5.698108 391.2 S -4.998(vv)5.698 G F0 -1.11(Ve)14.294 + G 1.072(rbose mode.)1.11 F 1.072(Print information about what)6.072 F F3 + -2.778(ll)3.572 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G -5.558(nn)2.778 G + -5.558(kk)5.558 G F0 1.073(is doing.)9.13 F 1.073 + (This typically includes a message)6.073 F + (for each bytecode \214le link)128 403.2 Q + (ed in and for each library found.)-.1 E F1 -7.302(EE)72 420 S -7.904 + (XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H(ST)1.216 E + -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S)-6.086 E + F0(If)108 432 Q F3 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998(vv)2.778 G + -8.328(mm)4.998 G -3.328(--)8.328 G -2.778(ll)3.328 G -2.778(ii)2.778 G + -5.558(nn)2.778 G -5.558(kk)5.558 G F0(succeeds, it will e)8.058 E + (xit with 0.)-.15 E(Otherwise, if an error occurs, it will e)5 E + (xit with a non-zero v)-.15 E(alue.)-.25 E F1 -6.086(SS)72 448.8 S + -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO) + -6.086 E(O)-8.517 E F0(the gccld manpage)108 460.8 Q F1 12.522 -7.904 + (AA UU)72 477.6 T -7.302(TT)7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G + -7.904(RR)8.517 G -6.086(SS)7.904 G F0(Maintained by the)108 489.6 Q F2 + (LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E + 178.59(2004-07-04 1.3)72 768 R(1)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-nm.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-nm.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-nm.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,328 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 2 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 123.85(VM-NM\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)126.35 E(VM-NM\(1\))-1 E/F1 10.95/Times-Bold at 0 + SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302(EE)10.335 G F0 + (llvm-nm \255 list)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0 + (bytecode \214le')2.5 E 2.5(ss)-.55 G(ymbol table)-2.5 E F1 -6.086(SS)72 + 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP) + 8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10 + /Times-Bold at 0 SF -2.778(ll)108 124.8 S -2.778(ll)2.778 G -4.998(vv)2.778 + G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(nn)3.328 G -8.328(mm)5.558 + G F0([)10.828 E/F4 10/Times-Italic at 0 SF(options)A F0 2.5(][)C F4 + (\214lenames...)-2.5 E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G + -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G + -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -2.778(ll)3.527 G -2.778(ll) + 2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(nn) + 3.328 G -8.328(mm)5.558 G F0 1.027 + (utility lists the names of symbols from the)11.855 F F2(LL)3.526 E(VM) + -.9 E F0 1.026(bytecode \214les, or)3.526 F F3 -4.998(aa)3.526 G -4.438 + (rr)4.998 G F0(archi)7.964 E -.15(ve)-.25 G 3.526(sc).15 G(ontaining) + -3.526 E F2(LL)108 165.6 Q(VM)-.9 E F0 .204 + (bytecode \214les, named on the command line.)2.703 F .204 + (Each symbol is listed along with some simple informa-)5.204 F .957 + (tion about its pro)108 177.6 R -.15(ve)-.15 G 3.457(nance. If).15 F + .957(no \214lename is speci\214ed, or)3.457 F F4(-)3.457 E F0 .956 + (is used as a \214lename,)3.457 F F3 -2.778(ll)3.456 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(nn)3.328 G + -8.328(mm)5.558 G F0 .956(will process a)11.784 F + (bytecode \214le on its standard input stream.)108 189.6 Q F3 -2.778(ll) + 108 206.4 S -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328 + (--)8.328 G -5.558(nn)3.328 G -8.328(mm)5.558 G F0 1.24 -.55('s d)8.328 + H(ef).55 E .14(ault output format is the traditional)-.1 F F2(BSD)2.64 E + F3 -5.558(nn)2.64 G -8.328(mm)5.558 G F0 .141(output format.)10.969 F + .141(Each such output record consists)5.141 F .8 + (of an \(optional\) 8\255digit he)108 218.4 R .8 + (xadecimal address, follo)-.15 F .799(wed by a type code character)-.25 + F 3.299(,f)-.4 G(ollo)-3.299 E .799(wed by a name, for)-.25 F .409(each\ + symbol. One record is printed per line; \214elds are separated by spac\ + es. When the address is omitted, it)108 230.4 R + (is replaced by 8 spaces.)108 242.4 Q -.8(Ty)108 259.2 S(pe code charac\ + ters currently supported, and their meanings, are as follo).8 E(ws:)-.25 + E 12.78(UN)108 276 S(amed object is referenced b)-12.78 E + (ut unde\214ned in this bytecode \214le)-.2 E 13.33(CC)108 292.8 S + (ommon \(multiple defs link together into one def\))-13.33 E 10.56(WW) + 108 309.6 S + (eak reference \(multiple defs link together into zero or one defs\)) + -11.36 E 17.22(tL)108 326.4 S(ocal function \(te)-17.22 E(xt\) object) + -.15 E 13.89(TG)108 343.2 S(lobal function \(te)-13.89 E(xt\) object) + -.15 E 15(dL)108 360 S(ocal data object)-15 E 12.78(DG)108 376.8 S + (lobal data object)-12.78 E 15.56(?S)108 393.6 S + (omething unrecognizable)-15.56 E(Because)108 410.4 Q F2(LL)3.013 E(VM) + -.9 E F0 .513(bytecode \214les typically contain objects that are not c\ + onsidered to ha)3.013 F .813 -.15(ve a)-.2 H .512(ddresses until the).15 + F(y)-.15 E 1.173(are link)108 422.4 R 1.173(ed into an e)-.1 F -.15(xe) + -.15 G 1.173(cutable image or dynamically compiled `).15 F + (`just-in-time')-.74 E(',)-.74 E F3 -2.778(ll)3.673 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(nn)3.328 G + -8.328(mm)5.558 G F0 1.174(does not print an)12.002 F(address for an)108 + 434.4 Q 2.5(ys)-.15 G(ymbol, e)-2.5 E -.15(ve)-.25 G 2.5(ns).15 G + (ymbols which are de\214ned in the bytecode \214le.)-2.5 E F1 -8.517(OO) + 72 451.2 S -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517 + (OO)4.258 G -7.904(NN)8.517 G -6.086(SS)7.904 G F3 -5.698108 463.2 + S -6.108(PP)5.698 G F0(Use)14.294 E F2(POSIX)2.5 E F0 + (.2 output format. Alias for)A F3 19.162 -9.998<8a8a2066>4.166 H -.25 + (fo)6.67 G(or)-4.748 E(rm)-4.438 E(ma)-8.328 E(at)-4.998 E(t=)-3.328 E + (=p)-5.698 E(po)-5.558 E(os)-4.998 E(si)-3.888 E(ix)-2.778 E(x)-4.998 E + F0(.)A F3 -5.698108 480 S -6.668(BB)5.698 G F0(\(def)16.668 E + (ault\))-.1 E(Use)128 492 Q F2(BSD)2.5 E F0(output format. Alias for)2.5 + E F3 19.162 -9.998<8a8a2066>4.166 H -.25(fo)6.67 G(or)-4.748 E(rm)-4.438 + E(ma)-8.328 E(at)-4.998 E(t=)-3.328 E(=b)-5.698 E(bs)-5.558 E(sd)-3.888 + E(d)-5.558 E F0(.)A F3 19.162 -9.998<8a8a2068>109.666 508.8 T(he)4.44 E + (el)-4.438 E(lp)-2.778 E(p)-5.558 E F0 + (Print a summary of command-line options and their meanings.)128 520.8 Q + F3 19.162 -9.998<8a8a2064>109.666 537.6 T(de)4.44 E<658c>-4.438 E<8c6e> + -5.558 E(ne)-5.558 E(ed)-4.438 E(d-)-5.558 E(-o)-3.328 E(on)-4.998 E(nl) + -5.558 E(ly)-2.778 E(y)-4.998 E F0 .718(Print only symbols de\214ned in\ + this bytecode \214le \(as opposed to symbols which may be referenced b\ + y)128 549.6 R(objects in this \214le, b)128 561.6 Q + (ut not de\214ned in this \214le.\))-.2 E F3 19.162 -9.998<8a8a2065> + 109.666 578.4 T(ex)5.56 E(xt)-4.998 E(te)-3.328 E(er)-4.438 E -.15(rn) + -4.438 G(n-)-5.408 E(-o)-3.328 E(on)-4.998 E(nl)-5.558 E(ly)-2.778 E(y) + -4.998 E F0(,)A F3 -5.6982.5 G -4.998(gg)5.698 G F0 + (Print only symbols whose de\214nitions are e)128 590.4 Q + (xternal; that is, accessible from other bytecode \214les.)-.15 E F3 + 19.162 -9.998<8a8a2075>109.666 607.2 T(un)4.44 E(nd)-5.558 E(de)-5.558 E + <658c>-4.438 E<8c6e>-5.558 E(ne)-5.558 E(ed)-4.438 E(d-)-5.558 E(-o) + -3.328 E(on)-4.998 E(nl)-5.558 E(ly)-2.778 E(y)-4.998 E F0(,)A F3 -5.698 + 2.5 G -5.558(uu)5.698 G F0(Print only symbols referenced b)128 + 619.2 Q(ut not de\214ned in this bytecode \214le.)-.2 E F3 19.162 -9.998 + <8a8a2066>109.666 636 T -.25(fo)6.67 G(or)-4.748 E(rm)-4.438 E(ma)-8.328 + E(at)-4.998 E(t=)-3.328 E(=)-5.698 E F4(fmt)A F0(,)A F3 -5.6982.5 + G -3.328(ff)5.698 G F0(Select an output format;)128 648 Q F4(fmt)2.5 E + F0(may be)2.5 E F4(sysv)2.5 E F0(,)A F4(posix)2.5 E F0 2.5(,o)C(r)-2.5 E + F4(bsd)2.5 E F0 2.5(.T)C(he def)-2.5 E(ault is)-.1 E F4(bsd)2.5 E F0(.)A + F1 11.756 -7.302(BB U)72 664.8 T(UG)-.602 E(GS)-8.517 E(S)-6.086 E F3 + -2.778(ll)108 676.8 S -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm) + 4.998 G -3.328(--)8.328 G -5.558(nn)3.328 G -8.328(mm)5.558 G F0 + (cannot demangle C)10.828 E/F5 8/Times-Roman at 0 SF -1(++)-1 -1.2 O F0 + (mangled names, lik)2.5 1.2 M(e)-.1 E F2(GNU)2.5 E F3 -5.558(nn)2.5 G + -8.328(mm)5.558 G F0(can.)10.828 E F1 -7.302(EE)72 693.6 S -7.904(XX) + 7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H(ST)1.216 E -.986 + (TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S)-6.086 E F3 + -2.778(ll)108 705.6 S -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm) + 4.998 G -3.328(--)8.328 G -5.558(nn)3.328 G -8.328(mm)5.558 G F0 -.15 + (ex)10.828 G(its with an e).15 E(xit code of zero.)-.15 E 178.59 + (2004-07-04 1.3)72 768 R(1)222.75 E EP + %%Page: 2 2 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 123.85(VM-NM\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)126.35 E(VM-NM\(1\))-1 E/F1 10.95/Times-Bold at 0 + SF -6.086(SS)72 84 S -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL) + -.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0(llvm-dis,)108 96 Q/F2 10 + /Times-Italic at 0 SF(ar)2.5 E F0(\(1\),)1.666 E F2(nm)2.5 E F0(\(1\))1.666 + E F1 12.522 -7.904(AA UU)72 112.8 T -7.302(TT)7.904 G -8.517(HH)7.302 G + -8.517(OO)8.517 G -7.904(RR)8.517 G F0(Maintained by the)108 124.8 Q/F3 + 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(2) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-prof.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-prof.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvm-prof.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,287 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Symbol + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Symbol + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q(VM-PR)-1 E 115.35(OF\(1\) LL)-.4 F + (VM Command Guide)-1 E(LL)117.85 E(VM-PR)-1 E(OF\(1\))-.4 E/F1 10.95 + /Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302 + (EE)10.335 G F0(llvm-prof \255 print e)108 96 Q -.15(xe)-.15 G + (cution pro\214le of).15 E/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0 + (program)2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 + G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II)6.086 + G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -2.778(ll)108 124.8 S -2.778 + (ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558 + (pp)3.328 G 6.196 -4.438(rr o)5.558 H(of)-.56 E(f)-3.328 E F0([)2.5 E/F4 + 10/Times-Italic at 0 SF(options)A F0 2.5(][)C F4(bytecode \214le)-2.5 E F0 + 2.5(][)C F4(llvmpr)-2.5 E(of)-.45 E(.out)-.15 E F0(])A F1 -7.904(DD)72 + 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR) + 7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II) + 7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -2.778 + (ll)2.888 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328 + (--)8.328 G -5.558(pp)3.328 G 6.196 -4.438(rr o)5.558 H(of)-.56 E(f) + -3.328 E F0 .388(tool reads in an)2.888 F F4(llvmpr)2.888 E(of)-.45 E + (.out)-.15 E F0 .387(\214le \(which can optionally use a speci\214c \ + \214le with the third pro-)2.887 F .381(gram ar)108 165.6 R .382(gument\ + \), a bytecode \214le for the program, and produces a human readable re\ + port, suitable for deter)-.18 F(-)-.2 E + (mining where the program hotspots are.)108 177.6 Q .802 + (This program is often used in conjunction with the)108 194.4 R F4 + (utils/pr)3.301 E(o\214le)-.45 E(.pl)-.15 E F0 3.301(script. This)3.301 + F .801(script automatically instru-)3.301 F 1.229 + (ments a program, runs it with the)108 206.4 R F2(JIT)3.729 E F0 3.729 + (,t)C 1.229(hen runs)-3.729 F F3 -2.778(ll)3.729 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(pp)3.328 G + 6.196 -4.438(rr o)5.558 H(of)-.56 E(f)-3.328 E F0 1.229 + (to format a report.)3.729 F 2.83 -.8(To g)6.229 H 1.23 + (et more information).8 F(about)108 218.4 Q F4(utils/pr)2.5 E(o\214le) + -.45 E(.pl)-.15 E F0 2.5(,e)C -.15(xe)-2.65 G(cute it with the).15 E F3 + 19.162 -9.998<8a8a2068>4.166 H(he)4.44 E(el)-4.438 E(lp)-2.778 E(p) + -5.558 E F0(option.)2.5 E F1 -8.517(OO)72 235.2 S -6.688(PP)8.517 G + -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G + -6.086(SS)7.904 G F3 19.162 -9.998<8a8a2061>109.666 247.2 T(an)5 E(nn) + -5.558 E(no)-5.558 E(ot)-4.998 E(ta)-3.328 E(at)-4.998 E(te)-3.328 E(ed) + -4.438 E(d-)-5.558 E(-l)-3.328 E(ll)-2.778 E(lv)-2.778 E(vm)-4.998 E(m) + -8.328 E F0(or)2.5 E F3 -5.6982.5 G -7.218(AA)5.698 G F0 .599(In \ + addition to the normal report printed, print out the code for the progr\ + am, annotated with e)128 259.2 R -.15(xe)-.15 G(cution).15 E(frequenc) + 128 271.2 Q 3.331(yi)-.15 G .831(nformation. This can be particularly u\ + seful when trying to visualize ho)-3.331 F 3.332(wf)-.25 G .832 + (requently basic)-3.332 F(blocks are e)128 283.2 Q -.15(xe)-.15 G 2.5 + (cuted. This).15 F + (is most useful with basic block pro\214ling information or better)2.5 E + (.)-.55 E F3 19.162 -9.998<8a8a2070>109.666 300 T(pr)4.44 E(ri)-4.438 E + (in)-2.778 E(nt)-5.558 E(t-)-3.328 E(-a)-3.328 E(al)-4.998 E(ll)-2.778 E + (l-)-2.778 E(-c)-3.328 E(co)-4.438 E(od)-4.998 E(de)-5.558 E(e)-4.438 E + F0 .164(Using this option enables the)128 312 R F3 19.162 -9.998 + <8a8a2061>4.329 H(an)5 E(nn)-5.558 E(no)-5.558 E(ot)-4.998 E(ta)-3.328 E + (at)-4.998 E(te)-3.328 E(ed)-4.438 E(d-)-5.558 E(-l)-3.328 E(ll)-2.778 E + (lv)-2.778 E(vm)-4.998 E(m)-8.328 E F0 .163(option, b)2.663 F .163 + (ut it prints the entire module, instead of just)-.2 F + (the most commonly e)128 324 Q -.15(xe)-.15 G(cuted functions.).15 E F3 + 19.162 -9.998<8a8a2074>109.666 340.8 T(ti)6.67 E(im)-2.778 E(me)-8.328 E + (e-)-4.438 E(-p)-3.328 E(pa)-5.558 E(as)-4.998 E(ss)-3.888 E(se)-3.888 E + (es)-4.438 E(s)-3.888 E F0(Record the amount of time needed for each pa\ + ss and print it to standard error)128 352.8 Q(.)-.55 E F1 -7.302(EE)72 + 369.6 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H + (ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E + (S)-6.086 E F3 -2.778(ll)108 381.6 S -2.778(ll)2.778 G -4.998(vv)2.778 G + -8.328(mm)4.998 G -3.328(--)8.328 G -5.558(pp)3.328 G 6.196 -4.438(rr o) + 5.558 H(of)-.56 E(f)-3.328 E/F5 10/Symbol SF -4.938C F3 -2.778(ll) + 4.938 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--) + 8.328 G -5.558(pp)3.328 G 6.196 -4.438(rr o)5.558 H(of)-.56 E(f)-3.328 E + F0 .921(returns 1 if it cannot load the bytecode \214le or the pro\214l\ + e information. Otherwise, it)3.421 F -.15(ex)108 393.6 S(its with zero.) + .15 E F1 12.522 -7.904(AA UU)72 410.4 T -7.302(TT)7.904 G -8.517(HH) + 7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G F3 -2.778(ll)108 422.4 S + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328(--)8.328 G + -5.558(pp)3.328 G 6.196 -4.438(rr o)5.558 H(of)-.56 E(f)-3.328 E F0 + (is maintained by the)2.5 E F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvmgcc.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvmgcc.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvmgcc.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,295 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Symbol + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Symbol + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 122.73(VMGCC\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)125.23 E(VMGCC\(1\))-1 E/F1 10.95/Times-Bold at 0 + SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302(EE)10.335 G F0 + (llvmgcc \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0 2.5 + (Cf)2.5 G(ront-end)-2.5 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G + -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G + -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10/Times-Bold at 0 SF -2.778(ll)108 + 124.8 S -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg) + 8.328 G -4.438(cc)4.998 G -4.438(cc)4.438 G F0([)6.938 E/F4 10 + /Times-Italic at 0 SF(options)A F0(])A F4(\214lename)2.5 E F1 -7.904(DD)72 + 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR) + 7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II) + 7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -2.778 + (ll)2.829 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998 + (gg)8.328 G -4.438(cc)4.998 G -4.438(cc)4.438 G F0 .329(command is the) + 7.267 F F2(LL)2.829 E(VM)-.9 E F0 2.829(Cf)2.829 G .329(ront end.)-2.829 + F .329(It is a modi\214ed v)5.329 F .329(ersion of gcc that tak)-.15 F + .329(es C programs and)-.1 F(compiles them into)108 165.6 Q F2(LL)2.5 E + (VM)-.9 E F0(bytecode or assembly language, depending upon the options.) + 2.5 E .69(Unless the)108 182.4 R F3 -5.6983.19 G -5.558(SS)5.698 G + F0 .69(option is speci\214ed,)8.748 F F3 -2.778(ll)3.19 G -2.778(ll) + 2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -4.438(cc) + 4.998 G -4.438(cc)4.438 G F0 .69 + (will use the gccas program to perform some optimizations and)7.628 F + .252(create an)108 194.4 R F2(LL)2.752 E(VM)-.9 E F0 .252 + (bytecode \214le. Unless the)2.752 F F3 -5.6982.752 G -4.438(cc) + 5.698 G F0 .251(option is speci\214ed,)7.189 F F3 -2.778(ll)2.751 G + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G + -4.438(cc)4.998 G -4.438(cc)4.438 G F0 .251 + (will also use the gccld program to)7.189 F 1.695 + (perform further optimizations and link the resulting bytecode)108 206.4 + R F4(\214le)4.195 E F0 1.696(\(s\) with support libraries to create an) + 1.666 F -.15(exe)108 218.4 S(cutable program.).15 E .316(Being deri)108 + 235.2 R -.15(ve)-.25 G 2.816(df).15 G .316(rom the)-2.816 F F2(GNU)2.816 + E F0 .316(Compiler Collection,)2.816 F F3 -2.778(ll)2.816 G -2.778(ll) + 2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -4.438(cc) + 4.998 G -4.438(cc)4.438 G F0 .316(has man)7.254 F 2.816(yo)-.15 G 2.816 + (fg)-2.816 G(cc')-2.816 E 2.816(sf)-.55 G .315 + (eatures and accepts most of)-2.816 F(gcc')108 247.2 Q 2.5(so)-.55 G 2.5 + (ptions. It)-2.5 F(handles a number of gcc')2.5 E 2.5(se)-.55 G + (xtensions to the C programming language.)-2.65 E F1 -8.517(OO)72 264 S + -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G -6.086(SS)7.904 G F3 19.162 -9.998<8a8a2068>109.666 + 276 T(he)4.44 E(el)-4.438 E(lp)-2.778 E(p)-5.558 E F0 + (Print a summary of command line options.)128 288 Q F3 -5.698108 + 304.8 S -5.558(SS)5.698 G F0 .672(Do not generate an)14.294 F F2(LL) + 3.173 E(VM)-.9 E F0 .673(bytecode \214le.)3.173 F(Rather)5.673 E 3.173 + (,c)-.4 G .673(ompile the source \214le into an)-3.173 F F2(LL)3.173 E + (VM)-.9 E F0 .673(assembly lan-)3.173 F(guage \214le.)128 316.8 Q F3 + -5.698108 333.6 S -4.438(cc)5.698 G F0 .187 + (Do not generate a link)14.294 F .187(ed e)-.1 F -.15(xe)-.15 G 2.687 + (cutable. Rather).15 F 2.687(,c)-.4 G .187 + (ompile the source \214le into an)-2.687 F F2(LL)2.687 E(VM)-.9 E F0 + .187(bytecode \214le.)2.687 F(This)5.187 E + (bytecode \214le can then be link)128 345.6 Q + (ed with other bytecode \214les later on to generate a full)-.1 E F2(LL) + 2.5 E(VM)-.9 E F0 -.15(exe)2.5 G(cutable.).15 E F3 -5.698108 362.4 + S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 + (Specify the output \214le to be)128 374.4 Q F4(\214lename)2.5 E F0(.)A + F3 -5.698108 391.2 S -3.888(II)5.698 G F4(dir)6.388 E(ectory)-.37 + E F0(Add a directory to the header \214le search path.)128 403.2 Q + (This option can be repeated.)5 E F3 -5.698108 420 S -6.668(LL) + 5.698 G F4(dir)9.168 E(ectory)-.37 E F0(Add)128 432 Q F4(dir)2.5 E + (ectory)-.37 E F0(to the library search path.)2.5 E + (This option can be repeated.)5 E F3 -5.698108 448.8 S -2.778(ll) + 5.698 G F4(name)2.778 E F0(Link in the library lib)128 460.8 Q F4(name)A + F0(.[bc)A/F5 10/Symbol SF2.5 E F0(a)2.5 E F52.5 E F0 2.5 + (so]. This)2.5 F(library should be a bytecode library)2.5 E(.)-.65 E F3 + -5.698108 477.6 S -9.998(WW)5.698 G -2.778(ll)9.998 G -2.498(,,) + 2.778 G F4(option)2.498 E F0 -.15(Pa)128 489.6 S(ss).15 E F4(option)2.5 + E F0(to the link)2.5 E(er \(usually gccld\).)-.1 E F1 -7.302(EE)72 506.4 + S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H(ST) + 1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S) + -6.086 E F0(If)108 518.4 Q F3 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998 + (vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -4.438(cc)4.998 G -4.438 + (cc)4.438 G F0(succeeds, it will e)6.938 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 535.2 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0 + (llvmg++, gccas, gccld)108 547.2 Q F1 12.522 -7.904(AA UU)72 564 T + -7.302(TT)7.904 G -8.517(HH)7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G + -6.086(SS)7.904 G F0(Maintained by the)108 576 Q F2(LL)2.5 E(VM)-.9 E F0 + -.7(Te)2.5 G(am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3) + 72 768 R(1)222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/llvmgxx.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/llvmgxx.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/llvmgxx.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,298 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Symbol + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Symbol + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF(LL)72 48 Q 121.63(VMGXX\(1\) LL)-1 F + (VM Command Guide)-1 E(LL)124.13 E(VMGXX\(1\))-1 E/F1 10.95/Times-Bold at 0 + SF 12.851 -7.904(NN AA)72 84 T -10.335(MM)7.904 G -7.302(EE)10.335 G F0 + (llvmg++ \255)108 96 Q/F2 9/Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(C)2.5 + E/F3 8/Times-Roman at 0 SF -1(++)-1 -1.2 O F0(front-end)2.5 1.2 M F1 -6.086 + (SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 G + -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 G + /F4 10/Times-Bold at 0 SF -2.778(ll)108 124.8 S -2.778(ll)2.778 G -4.998 + (vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -5.698(++)4.998 G -5.698 + (++)5.698 G F0([)8.198 E/F5 10/Times-Italic at 0 SF(options)A F0(])A F5 + (\214lename)2.5 E F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086(SS) + 7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688(PP) + 4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN) + 8.517 G F0(The)108 153.6 Q F4 -2.778(ll)2.845 G -2.778(ll)2.778 G -4.998 + (vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -5.698(++)4.998 G -5.698 + (++)5.698 G F0 .345(command is the)8.543 F F2(LL)2.845 E(VM)-.9 E F0(C) + 2.845 E F3 -1(++)-1 -1.2 O F0 .345(front end.)2.845 1.2 N .345 + (It is a modi\214ed v)5.345 F .345(ersion of g++ that tak)-.15 F .344 + (es C)-.1 F F3 -1(++)-1 -1.2 O F0(programs)2.844 1.2 M + (and compiles them into)108 165.6 Q F2(LL)2.5 E(VM)-.9 E F0 + (bytecode or assembly language, depending upon the options.)2.5 E .532 + (Unless the)108 182.4 R F4 -5.6983.032 G -5.558(SS)5.698 G F0 .532 + (option is speci\214ed,)8.59 F F4 -2.778(ll)3.032 G -2.778(ll)2.778 G + -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -5.698(++)4.998 G + -5.698(++)5.698 G F0 .533 + (will use the gccas program to perform some optimizations and)8.731 F + .112(create an)108 194.4 R F2(LL)2.612 E(VM)-.9 E F0 .112 + (bytecode \214le. Unless the)2.612 F F4 -5.6982.612 G -4.438(cc) + 5.698 G F0 .111(option is speci\214ed,)7.049 F F4 -2.778(ll)2.611 G + -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G + -5.698(++)4.998 G -5.698(++)5.698 G F0 .111 + (will also use the gccld program to)8.309 F 1.695 + (perform further optimizations and link the resulting bytecode)108 206.4 + R F5(\214le)4.195 E F0 1.696(\(s\) with support libraries to create an) + 1.666 F -.15(exe)108 218.4 S(cutable program.).15 E .009(Being deri)108 + 235.2 R -.15(ve)-.25 G 2.509(df).15 G .009(rom the)-2.509 F F2(GNU)2.509 + E F0 .008(Compiler Collection,)2.508 F F4 -2.778(ll)2.508 G -2.778(ll) + 2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -5.698(++) + 4.998 G -5.698(++)5.698 G F0 .008(has man)8.206 F 2.508(yo)-.15 G 2.508 + (fg)-2.508 G(++')-2.508 E 2.508(sf)-.55 G .008 + (eatures and accepts most of)-2.508 F(g++')108 247.2 Q 2.5(so)-.55 G 2.5 + (ptions. It)-2.5 F(handles a number of g++')2.5 E 2.5(se)-.55 G + (xtensions to the C)-2.65 E F3 -1(++)-1 -1.2 O F0(programming language.) + 2.5 1.2 M F1 -8.517(OO)72 264 S -6.688(PP)8.517 G -7.302(TT)6.688 G + -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G -6.086(SS)7.904 G + F4 19.162 -9.998<8a8a2068>109.666 276 T(he)4.44 E(el)-4.438 E(lp)-2.778 + E(p)-5.558 E F0(Print a summary of command line options.)128 288 Q F4 + -5.698108 304.8 S -5.558(SS)5.698 G F0 .672(Do not generate an) + 14.294 F F2(LL)3.173 E(VM)-.9 E F0 .673(bytecode \214le.)3.173 F(Rather) + 5.673 E 3.173(,c)-.4 G .673(ompile the source \214le into an)-3.173 F F2 + (LL)3.173 E(VM)-.9 E F0 .673(assembly lan-)3.173 F(guage \214le.)128 + 316.8 Q F4 -5.698108 333.6 S -4.438(cc)5.698 G F0 .187 + (Do not generate a link)14.294 F .187(ed e)-.1 F -.15(xe)-.15 G 2.687 + (cutable. Rather).15 F 2.687(,c)-.4 G .187 + (ompile the source \214le into an)-2.687 F F2(LL)2.687 E(VM)-.9 E F0 + .187(bytecode \214le.)2.687 F(This)5.187 E + (bytecode \214le can then be link)128 345.6 Q + (ed with other bytecode \214les later on to generate a full)-.1 E F2(LL) + 2.5 E(VM)-.9 E F0 -.15(exe)2.5 G(cutable.).15 E F4 -5.698108 362.4 + S -4.998(oo)5.698 G F5(\214lename)7.498 E F0 + (Specify the output \214le to be)128 374.4 Q F5(\214lename)2.5 E F0(.)A + F4 -5.698108 391.2 S -3.888(II)5.698 G F5(dir)6.388 E(ectory)-.37 + E F0(Add a directory to the header \214le search path.)128 403.2 Q + (This option can be repeated.)5 E F4 -5.698108 420 S -6.668(LL) + 5.698 G F5(dir)9.168 E(ectory)-.37 E F0(Add)128 432 Q F5(dir)2.5 E + (ectory)-.37 E F0(to the library search path.)2.5 E + (This option can be repeated.)5 E F4 -5.698108 448.8 S -2.778(ll) + 5.698 G F5(name)2.778 E F0(Link in the library lib)128 460.8 Q F5(name)A + F0(.[bc)A/F6 10/Symbol SF2.5 E F0(a)2.5 E F62.5 E F0 2.5 + (so]. This)2.5 F(library should be a bytecode library)2.5 E(.)-.65 E F4 + -5.698108 477.6 S -9.998(WW)5.698 G -2.778(ll)9.998 G -2.498(,,) + 2.778 G F5(option)2.498 E F0 -.15(Pa)128 489.6 S(ss).15 E F5(option)2.5 + E F0(to the link)2.5 E(er \(usually gccld\).)-.1 E F1 -7.302(EE)72 506.4 + S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H(ST) + 1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E(S) + -6.086 E F0(If)108 518.4 Q F4 -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998 + (vv)2.778 G -8.328(mm)4.998 G -4.998(gg)8.328 G -5.698(++)4.998 G -5.698 + (++)5.698 G F0(succeeds, it will e)8.198 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 535.2 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0 + (the llvmgcc manpage, the gccas manpage, the gccld manpage)108 547.2 Q + F1 12.522 -7.904(AA UU)72 564 T -7.302(TT)7.904 G -8.517(HH)7.302 G + -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 576 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/opt.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/opt.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/opt.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,308 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 01:00:18 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Times-Italic at 0 ENC0/Times-Italic RE/Times-Bold at 0 ENC0/Times-Bold RE + /Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 151.73(OPT\(1\) LL)72 48 R(VM Command Guide)-1 E + (OPT\(1\))154.23 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 T + -10.335(MM)7.904 G -7.302(EE)10.335 G F0(opt \255)108 96 Q/F2 9 + /Times-Roman at 0 SF(LL)2.5 E(VM)-.9 E F0(optimizer)2.5 E F1 -6.086(SS)72 + 112.8 S -7.904(YY)6.086 G -7.904(NN)7.904 G -8.517(OO)7.904 G -6.688(PP) + 8.517 G -6.086(SS)6.688 G -4.258(II)6.086 G -6.086(SS)4.258 G/F3 10 + /Times-Bold at 0 SF -4.998(oo)108 124.8 S -5.558(pp)4.998 G -3.328(tt)5.558 + G F0([)5.828 E/F4 10/Times-Italic at 0 SF(options)A F0 2.5(][)C F4 + (\214lename)-2.5 E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G + -6.086(SS)7.302 G -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G + -6.688(PP)4.258 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G + -7.904(NN)8.517 G F0(The)108 153.6 Q F3 -4.998(oo)3.743 G -5.558(pp) + 4.998 G -3.328(tt)5.558 G F0 1.243(command is the modular)7.071 F F2(LL) + 3.743 E(VM)-.9 E F0(optimizer)3.743 E 6.243(.I)-.55 G 3.742(tt)-6.243 G + (ak)-3.742 E(es)-.1 E F2(LL)3.742 E(VM)-.9 E F0 1.242 + (bytecode as input, runs the speci\214ed)3.742 F + (optimizations on it, and then outputs the optimized)108 165.6 Q F2(LL) + 2.5 E(VM)-.9 E F0(bytecode.)2.5 E .177(The optimizations a)108 182.4 R + -.25(va)-.2 G .178(ilable via).25 F F3 -4.998(oo)2.678 G -5.558(pp)4.998 + G -3.328(tt)5.558 G F0 .178(depend upon what libraries were link)6.006 F + .178(ed into it as well as an)-.1 F 2.678(ya)-.15 G(dditional)-2.678 E + .79(libraries that ha)108 194.4 R 1.09 -.15(ve b)-.2 H .79 + (een loaded with the).15 F F3 -5.6983.289 G -2.778(ll)5.698 G + -4.998(oo)2.778 G -4.998(aa)4.998 G -5.558(dd)4.998 G F0 3.289 + (option. Use)8.847 F(the)3.289 E F3 -5.6983.289 G -5.558(hh)5.698 + G -4.438(ee)5.558 G -2.778(ll)4.438 G -5.558(pp)2.778 G F0 .789 + (option to determine what optimiza-)8.847 F(tions you can use.)108 206.4 + Q(If no \214lename is speci\214ed on the command line,)108 223.2 Q F3 + -4.998(oo)2.5 G -5.558(pp)4.998 G -3.328(tt)5.558 G F0 + (reads its input from standard input.)5.828 E + (If an output \214lename is not speci\214ed with the)108 240 Q F3 -5.698 + 2.5 G -4.998(oo)5.698 G F0(option,)7.498 E F3 -4.998(oo)2.5 G + -5.558(pp)4.998 G -3.328(tt)5.558 G F0 + (writes its output to the standard output.)5.828 E F1 -8.517(OO)72 256.8 + S -6.688(PP)8.517 G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 + G -7.904(NN)8.517 G -6.086(SS)7.904 G F3 -5.698108 268.8 S -3.328 + (ff)5.698 G F0 -.15(Fo)14.294 G 1.006(rce o).15 F -.15(ve)-.15 G 3.507 + (rwrite. Normally).15 F(,)-.65 E F3 -4.998(oo)3.507 G -5.558(pp)4.998 G + -3.328(tt)5.558 G F0 1.007(will refuse to o)6.835 F -.15(ve)-.15 G 1.007 + (rwrite an output \214le that already e).15 F 3.507(xists. W)-.15 F + 1.007(ith this)-.4 F(option,)128 280.8 Q F3 -4.998(oo)2.5 G -5.558(pp) + 4.998 G -3.328(tt)5.558 G F0(will o)5.828 E -.15(ve)-.15 G + (rwrite the output \214le and replace it with ne).15 E 2.5(wb)-.25 G + (ytecode.)-2.5 E F3 -5.698108 297.6 S -5.558(hh)5.698 G -4.438(ee) + 5.558 G -2.778(ll)4.438 G -5.558(pp)2.778 G F0 + (Print a summary of command line options.)128 309.6 Q F3 -5.698108 + 326.4 S -4.998(oo)5.698 G F4(\214lename)7.498 E F0 + (Specify the output \214lename.)128 338.4 Q F3 -5.698108 355.2 S + -5.558(pp)5.698 G 6.196 -4.438(rr o)5.558 H<6f8c>-.56 E<8c6c>-5.558 E + (le)-2.778 E(e-)-4.438 E(-i)-3.328 E(in)-2.778 E(nf)-5.558 E -.25(fo) + -3.328 G(o-)-4.748 E<2d8c>-3.328 E<8c6c>-5.558 E(le)-2.778 E(e)-4.438 E + F4(\214lename)2.5 E F0(Specify the name of the \214le loaded by the \ + \255pro\214le-loader option.)128 367.2 Q F3 -5.698108 384 S -3.888 + (ss)5.698 G -3.328(tt)3.888 G -4.998(aa)3.328 G -3.328(tt)4.998 G -3.888 + (ss)3.328 G F0(Print statistics.)128 396 Q F3 -5.698108 412.8 S + -3.328(tt)5.698 G -2.778(ii)3.328 G -8.328(mm)2.778 G -4.438(ee)8.328 G + -3.328(--)4.438 G -5.558(pp)3.328 G -4.998(aa)5.558 G -3.888(ss)4.998 G + -3.888(ss)3.888 G -4.438(ee)3.888 G -3.888(ss)4.438 G F0(Record the amo\ + unt of time needed for each pass and print it to standard error)128 + 424.8 Q(.)-.55 E F3 -5.698108 441.6 S -5.558(dd)5.698 G -4.438(ee) + 5.558 G 8.416 -5.558(bb uu)4.438 H -4.998(gg)5.558 G F0 .782 + (If this is a deb)128 453.6 R .782(ug b)-.2 F .782 + (uild, this option will enable deb)-.2 F .782 + (ug printouts from passes which use the)-.2 F F4(DEB)3.281 E(UG\(\))-.1 + E F0 2.5(macro. See)128 465.6 R(the)2.5 E/F5 9/Times-Bold at 0 SF -6.001 + (LL)2.5 G 8.924 -6.001(LL V)6.001 H(VM)-.495 E(M)-8.494 E F3 -6.108(PP) + 2.5 G 6.196 -4.438(rr o)6.108 H(og)-.56 E(gr)-4.998 E(ra)-4.438 E(am) + -4.998 E(mm)-8.328 E(me)-8.328 E(er)-4.438 E(r')-4.438 E -.37('s)-3.328 + G 2.5(sM)-3.518 G(Ma)-11.938 E(an)-4.998 E(nu)-5.558 E(ua)-5.558 E(al) + -4.998 E(l)-2.778 E F0 2.5(,s)C(ection)-2.5 E F4(#DEB)2.5 E(UG)-.1 E F0 + (for more information.)2.5 E F3 -5.698108 482.4 S -2.778(ll)5.698 + G -4.998(oo)2.778 G -4.998(aa)4.998 G -5.558(dd)4.998 G F0(=)5.558 E F4 + (plugin)A F0 .829(Load the dynamic object)128 494.4 R F4(plugin)3.329 E + F0 5.829(.T)C .829(his object should re)-5.829 F .829(gister ne)-.15 F + 3.329(wo)-.25 G .83(ptimization passes.)-3.329 F .83(Once loaded,)5.83 F + .642(the object will add ne)128 506.4 R 3.141(wc)-.25 G .641 + (ommand line options to enable v)-3.141 F .641(arious optimizations.) + -.25 F 2.241 -.8(To s)5.641 H .641(ee the ne).8 F 3.141(wc)-.25 G(om-) + -3.141 E(plete list of optimizations, use the)128 518.4 Q F3 -5.698 + 2.5 G -5.558(hh)5.698 G -4.438(ee)5.558 G -2.778(ll)4.438 G -5.558 + (pp)2.778 G F0(and)8.058 E F3 -5.6982.5 G -2.778(ll)5.698 G -4.998 + (oo)2.778 G -4.998(aa)4.998 G -5.558(dd)4.998 G F0(options together:) + 8.058 E F3 -4.998(oo)128 536.4 S -5.558(pp)4.998 G 6.656 -3.328(tt \255) + 5.558 H-2.37 E(lo)-2.778 E(oa)-4.998 E(ad)-4.998 E(d)-5.558 E F0 + (=)A F4(plugin)A F3 -5.6982.5 G -5.558(hh)5.698 G -4.438(ee)5.558 + G -2.778(ll)4.438 G -5.558(pp)2.778 G -5.698108 553.2 S -5.558(pp) + 5.698 G F0(Print module after each transformation.)14.294 E F1 -7.302 + (EE)72 570 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S) + 4.258 H(ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US) + -7.904 E(S)-6.086 E F0(If)108 582 Q F3 -4.998(oo)2.5 G -5.558(pp)4.998 G + -3.328(tt)5.558 G F0(succeeds, it will e)5.828 E(xit with 0.)-.15 E + (Otherwise, if an error occurs, it will e)5 E(xit with a non-zero v)-.15 + E(alue.)-.25 E F1 -6.086(SS)72 598.8 S -7.302(EE)6.086 G 14.604 -7.302 + (EE A)7.302 H(AL)-.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0(analyze) + 108 610.8 Q F1 12.522 -7.904(AA UU)72 627.6 T -7.302(TT)7.904 G -8.517 + (HH)7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G F0 + (Maintained by the)108 639.6 Q F2(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-04 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF Index: llvm-www/releases/1.6/docs/CommandGuide/ps/stkrc.ps diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/stkrc.ps:1.1 *** /dev/null Tue Nov 8 14:07:56 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/stkrc.ps Tue Nov 8 14:07:44 2005 *************** *** 0 **** --- 1,306 ---- + %!PS-Adobe-3.0 + %%Creator: groff version 1.17.2 + %%CreationDate: Sat Jul 10 16:42:51 2004 + %%DocumentNeededResources: font Times-Roman + %%+ font Times-Bold + %%+ font Times-Italic + %%+ font Courier + %%DocumentSuppliedResources: procset grops 1.17 2 + %%Pages: 1 + %%PageOrder: Ascend + %%Orientation: Portrait + %%EndComments + %%BeginProlog + %%BeginResource: procset grops 1.17 2 + /setpacking where{ + pop + currentpacking + true setpacking + }if + /grops 120 dict dup begin + /SC 32 def + /A/show load def + /B{0 SC 3 -1 roll widthshow}bind def + /C{0 exch ashow}bind def + /D{0 exch 0 SC 5 2 roll awidthshow}bind def + /E{0 rmoveto show}bind def + /F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def + /G{0 rmoveto 0 exch ashow}bind def + /H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /I{0 exch rmoveto show}bind def + /J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def + /K{0 exch rmoveto 0 exch ashow}bind def + /L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /M{rmoveto show}bind def + /N{rmoveto 0 SC 3 -1 roll widthshow}bind def + /O{rmoveto 0 exch ashow}bind def + /P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /Q{moveto show}bind def + /R{moveto 0 SC 3 -1 roll widthshow}bind def + /S{moveto 0 exch ashow}bind def + /T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def + /SF{ + findfont exch + [exch dup 0 exch 0 exch neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /MF{ + findfont + [5 2 roll + 0 3 1 roll + neg 0 0]makefont + dup setfont + [exch/setfont cvx]cvx bind def + }bind def + /level0 0 def + /RES 0 def + /PL 0 def + /LS 0 def + /MANUAL{ + statusdict begin/manualfeed true store end + }bind def + /PLG{ + gsave newpath clippath pathbbox grestore + exch pop add exch pop + }bind def + /BP{ + /level0 save def + 1 setlinecap + 1 setlinejoin + 72 RES div dup scale + LS{ + 90 rotate + }{ + 0 PL translate + }ifelse + 1 -1 scale + }bind def + /EP{ + level0 restore + showpage + }bind def + /DA{ + newpath arcn stroke + }bind def + /SN{ + transform + .25 sub exch .25 sub exch + round .25 add exch round .25 add exch + itransform + }bind def + /DL{ + SN + moveto + SN + lineto stroke + }bind def + /DC{ + newpath 0 360 arc closepath + }bind def + /TM matrix def + /DE{ + TM currentmatrix pop + translate scale newpath 0 0 .5 0 360 arc closepath + TM setmatrix + }bind def + /RC/rcurveto load def + /RL/rlineto load def + /ST/stroke load def + /MT/moveto load def + /CL/closepath load def + /FL{ + currentgray exch setgray fill setgray + }bind def + /BL/fill load def + /LW/setlinewidth load def + /RE{ + findfont + dup maxlength 1 index/FontName known not{1 add}if dict begin + { + 1 index/FID ne{def}{pop pop}ifelse + }forall + /Encoding exch def + dup/FontName exch def + currentdict end definefont pop + }bind def + /DEFS 0 def + /EBEGIN{ + moveto + DEFS begin + }bind def + /EEND/end load def + /CNT 0 def + /level1 0 def + /PBEGIN{ + /level1 save def + translate + div 3 1 roll div exch scale + neg exch neg exch translate + 0 setgray + 0 setlinecap + 1 setlinewidth + 0 setlinejoin + 10 setmiterlimit + []0 setdash + /setstrokeadjust where{ + pop + false setstrokeadjust + }if + /setoverprint where{ + pop + false setoverprint + }if + newpath + /CNT countdictstack def + userdict begin + /showpage{}def + }bind def + /PEND{ + clear + countdictstack CNT sub{end}repeat + level1 restore + }bind def + end def + /setpacking where{ + pop + setpacking + }if + %%EndResource + %%IncludeResource: font Times-Roman + %%IncludeResource: font Times-Bold + %%IncludeResource: font Times-Italic + %%IncludeResource: font Courier + grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72 + def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron + /scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef + /.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent + /ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen + /period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon + /semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O + /P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex + /underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y + /z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft + /guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl + /endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut + /dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash + /quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen + /brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft + /logicalnot/minus/registered/macron/degree/plusminus/twosuperior + /threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior + /ordmasculine/guilsinglright/onequarter/onehalf/threequarters + /questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE + /Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex + /Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis + /multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn + /germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla + /egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis + /eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash + /ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def + /Courier at 0 ENC0/Courier RE/Times-Italic at 0 ENC0/Times-Italic RE + /Times-Bold at 0 ENC0/Times-Bold RE/Times-Roman at 0 ENC0/Times-Roman RE + %%EndProlog + %%Page: 1 1 + %%BeginPageSetup + BP + %%EndPageSetup + /F0 10/Times-Roman at 0 SF 138.39(STKRC\(1\) LL)72 48 R(VM Command Guide)-1 + E(STKRC\(1\))140.89 E/F1 10.95/Times-Bold at 0 SF 12.851 -7.904(NN AA)72 84 + T -10.335(MM)7.904 G -7.302(EE)10.335 G F0(stkrc \255 Stack)108 96 Q + (er Compiler)-.1 E F1 -6.086(SS)72 112.8 S -7.904(YY)6.086 G -7.904(NN) + 7.904 G -8.517(OO)7.904 G -6.688(PP)8.517 G -6.086(SS)6.688 G -4.258(II) + 6.086 G -6.086(SS)4.258 G/F2 10/Times-Bold at 0 SF -3.888(ss)108 124.8 S + -3.328(tt)3.888 G -5.558(kk)3.328 G 6.196 -4.438(rr cc)5.558 H F0([) + 6.938 E/F3 10/Times-Italic at 0 SF(options)A F0 2.5(][)C F3(\214lename)-2.5 + E F0(])A F1 -7.904(DD)72 141.6 S -7.302(EE)7.904 G -6.086(SS)7.302 G + -7.904(CC)6.086 G -7.904(RR)7.904 G -4.258(II)7.904 G -6.688(PP)4.258 G + -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 G + F0(The)108 153.6 Q F2 -3.888(ss)3.467 G -3.328(tt)3.888 G -5.558(kk) + 3.328 G 6.196 -4.438(rr cc)5.558 H F0 .967 + (command is the compiler for the Stack)7.905 F .967(er language. Stack) + -.1 F .967(er is a simple stack based, F)-.1 F(orth-lik)-.15 E(e)-.1 E + .865(language that w)108 165.6 R .865 + (as written as a demonstration language for)-.1 F/F4 9/Times-Roman at 0 SF + (LL)3.365 E(VM)-.9 E F0 3.365(.F)C .865 + (or details on the language, please see)-3.515 F + (http://llvm.cs.uiuc.edu/docs/Stack)108 177.6 Q(er)-.1 E 1.404 + (.html . The)-.55 F F2 -3.888(ss)3.904 G -3.328(tt)3.888 G -5.558(kk) + 3.328 G 6.196 -4.438(rr cc)5.558 H F0 1.404(compiler is f)8.342 F 1.403 + (airly minimal. It compiles to bytecode)-.1 F 1.191(only and doesn')108 + 189.6 R 3.691(tp)-.18 G 1.191(erform an)-3.691 F 3.691(yo)-.15 G 3.691 + (ptimizations. The)-3.691 F 1.191 + (output of stkrc \(a bytecode \214le\) can be piped through)3.691 F + (other)108 201.6 Q F4(LL)2.5 E(VM)-.9 E F0 + (tools for optimization and linking.)2.5 E(If)108 218.4 Q F3(\214lename) + 3.222 E F0 .721(is omitted or is)3.221 F/F5 10/Courier at 0 SF3.221 E + F0 3.221(,t)C(hen)-3.221 E F2 -3.888(ss)3.221 G -3.328(tt)3.888 G -5.558 + (kk)3.328 G 6.196 -4.438(rr cc)5.558 H F0 .721 + (reads its input from standard input. This is useful for combining)7.659 + F(the tool into a pipeline.)108 230.4 Q .14 + (If an output \214le is not speci\214ed with the)108 247.2 R F2 -5.698 + 2.64 G -4.998(oo)5.698 G F0 .141(option, then)7.639 F F2 -2.778 + (ll)2.641 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G -3.328 + (--)8.328 G -4.998(aa)3.328 G -3.888(ss)4.998 G F0 .141 + (sends its output to a \214le or standard output)6.529 F(by follo)108 + 259.2 Q(wing these rules:)-.25 E 16.5<8349>108 276 S 2.5(ft)-16.5 G + (he input is standard input, then the output is standard output.)-2.5 E + 16.5<8349>108 292.8 S 2.803(ft)-16.5 G .303 + (he input is a \214le that ends with)-2.803 F F5(.st)2.802 E F0 2.802 + (,t)C .302(hen the output \214le is of the same name, e)-2.802 F .302 + (xcept that the suf)-.15 F<8c78>-.25 E(is changed to)128 304.8 Q F5(.bc) + 2.5 E F0(.)A 16.5<8349>108 321.6 S 2.565(ft)-16.5 G .065 + (he input is a \214le that does not end with the)-2.565 F F5(.st)2.565 E + F0(suf)2.565 E .065 + (\214x, then the output \214le has the same name as the)-.25 F + (input \214le, e)128 333.6 Q(xcept that the)-.15 E F5(.bc)2.5 E F0(suf) + 2.5 E(\214x is appended.)-.25 E F1 -8.517(OO)72 350.4 S -6.688(PP)8.517 + G -7.302(TT)6.688 G -4.258(II)7.302 G -8.517(OO)4.258 G -7.904(NN)8.517 + G -6.086(SS)7.904 G F2 -5.698108 362.4 S -4.998(oo)5.698 G F3 + (\214lename)7.498 E F0(Specify the output \214le name.)128 374.4 Q(If)5 + E F3(\214lename)2.5 E F0(is)2.5 E F52.5 E F0 2.5(,t)C(hen)-2.5 E F2 + -2.778(ll)2.5 G -2.778(ll)2.778 G -4.998(vv)2.778 G -8.328(mm)4.998 G + -3.328(--)8.328 G -4.998(aa)3.328 G -3.888(ss)4.998 G F0 + (sends its output to standard output.)6.388 E F2 -5.698108 391.2 S + -3.888(ss)5.698 G -3.328(tt)3.888 G -4.998(aa)3.328 G -3.328(tt)4.998 G + -3.888(ss)3.328 G F0(Print statistics acquired during compilation.)128 + 403.2 Q F2 -5.698108 420 S -3.328(tt)5.698 G -2.778(ii)3.328 G + -8.328(mm)2.778 G -4.438(ee)8.328 G -3.328(--)4.438 G -5.558(pp)3.328 G + -4.998(aa)5.558 G -3.888(ss)4.998 G -3.888(ss)3.888 G -4.438(ee)3.888 G + -3.888(ss)4.438 G F0(Record the amount of time needed for each pass and\ + print it to standard error)128 432 Q(.)-.55 E F2 -5.698108 448.8 + S -3.328(ff)5.698 G F0 -.15(Fo)14.294 G .509 + (rce the output to be written. Normally).15 F(,)-.65 E F2 -3.888(ss) + 3.009 G -3.328(tt)3.888 G -5.558(kk)3.328 G 6.196 -4.438(rr cc)5.558 H + F0 -.1(wo)7.447 G(n').1 E 3.009(to)-.18 G -.15(ve)-3.159 G .509 + (rwrite an e).15 F .508(xisting bytecode \214le. This option)-.15 F -.15 + (ove)128 460.8 S(rrides that beha).15 E(vior)-.2 E(.)-.55 E F2 -5.698 + 108 477.6 S -3.888(ss)5.698 G -5.698(==)3.888 G -3.888(ss)5.698 G + -3.328(tt)3.888 G -4.998(aa)3.328 G -4.438(cc)4.998 G -5.558(kk)4.438 G + -3.888(ss)5.558 G -2.778(ii)3.888 G -4.438(zz)2.778 G -4.438(ee)4.438 G + F0 .306(Specify the stack size for the program. The def)128 489.6 R .306 + (ault stack size, 1024, should be suf)-.1 F .306 + (\214cient for most pro-)-.25 F(grams. F)128 501.6 Q(or v)-.15 E + (ery lar)-.15 E(ge, programs, you might w)-.18 E(ant to pro)-.1 E + (vide a lar)-.15 E(ger v)-.18 E(alue.)-.25 E F2 -5.698108 518.4 S + -5.558(hh)5.698 G -4.438(ee)5.558 G -2.778(ll)4.438 G -5.558(pp)2.778 G + F0(Print a summary of command line options.)128 530.4 Q F1 -7.302(EE)72 + 547.2 S -7.904(XX)7.302 G -4.258(II)7.904 G 14.604 -7.302(TT S)4.258 H + (ST)1.216 E -.986(TA)-7.302 G -1.04(AT)-6.918 G(TU)-6.262 E(US)-7.904 E + (S)-6.086 E F0(If)108 559.2 Q F2 -3.888(ss)3.001 G -3.328(tt)3.888 G + -5.558(kk)3.328 G 6.196 -4.438(rr cc)5.558 H F0 .501 + (succeeds, it will e)7.439 F .501(xit with 0.)-.15 F .501 + (Otherwise, if an error occurs, it will e)5.501 F .501 + (xit with a non-zero v)-.15 F .501(alue, usu-)-.25 F(ally 1.)108 571.2 Q + F1 -6.086(SS)72 588 S -7.302(EE)6.086 G 14.604 -7.302(EE A)7.302 H(AL) + -.602 E(LS)-7.302 E(SO)-6.086 E(O)-8.517 E F0 + (the llvm-as manpage, http://llvm.cs.uiuc.edu/docs/Stack)108 600 Q(er) + -.1 E(.html)-.55 E F1 12.522 -7.904(AA UU)72 616.8 T -7.302(TT)7.904 G + -8.517(HH)7.302 G -8.517(OO)8.517 G -7.904(RR)8.517 G -6.086(SS)7.904 G + F0(Maintained by the)108 628.8 Q F4(LL)2.5 E(VM)-.9 E F0 -.7(Te)2.5 G + (am \(http://llvm.cs.uiuc.edu\).).7 E 178.59(2004-07-10 1.3)72 768 R(1) + 222.75 E EP + %%Trailer + end + %%EOF From lattner at cs.uiuc.edu Tue Nov 8 14:08:23 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:23 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/img/Debugging.gif libdeps.gif lines.gif objdeps.gif venusflytrap.jpg Message-ID: <200511082008.OAA30696@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/img: Debugging.gif added (r1.1) libdeps.gif added (r1.1) lines.gif added (r1.1) objdeps.gif added (r1.1) venusflytrap.jpg added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+0 -0) Debugging.gif | 0 libdeps.gif | 0 lines.gif | 0 objdeps.gif | 0 venusflytrap.jpg | 0 5 files changed Index: llvm-www/releases/1.6/docs/img/Debugging.gif Index: llvm-www/releases/1.6/docs/img/libdeps.gif Index: llvm-www/releases/1.6/docs/img/lines.gif Index: llvm-www/releases/1.6/docs/img/objdeps.gif Index: llvm-www/releases/1.6/docs/img/venusflytrap.jpg From lattner at cs.uiuc.edu Tue Nov 8 14:08:50 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:50 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/.cvsignore Message-ID: <200511082008.OAA30819@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs: .cvsignore added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+4 -0) .cvsignore | 4 ++++ 1 files changed, 4 insertions(+) Index: llvm-www/releases/1.6/docs/.cvsignore diff -c /dev/null llvm-www/releases/1.6/docs/.cvsignore:1.1 *** /dev/null Tue Nov 8 14:08:49 2005 --- llvm-www/releases/1.6/docs/.cvsignore Tue Nov 8 14:08:39 2005 *************** *** 0 **** --- 1,4 ---- + doxygen.cfg + doxygen + doxygen.out + *.tar.gz From lattner at cs.uiuc.edu Tue Nov 8 14:08:54 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:54 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/.cvsignore Message-ID: <200511082008.OAA30841@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide: .cvsignore added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+4 -0) .cvsignore | 4 ++++ 1 files changed, 4 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/.cvsignore diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/.cvsignore:1.1 *** /dev/null Tue Nov 8 14:08:51 2005 --- llvm-www/releases/1.6/docs/CommandGuide/.cvsignore Tue Nov 8 14:08:41 2005 *************** *** 0 **** --- 1,4 ---- + pod2htm?.tmp + *.html + *.1 + *.ps From lattner at cs.uiuc.edu Tue Nov 8 14:08:55 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:55 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/man/man1/.cvsignore Message-ID: <200511082008.OAA30849@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/man/man1: .cvsignore added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+2 -0) .cvsignore | 2 ++ 1 files changed, 2 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/man/man1/.cvsignore diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/man1/.cvsignore:1.1 *** /dev/null Tue Nov 8 14:08:51 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/man1/.cvsignore Tue Nov 8 14:08:41 2005 *************** *** 0 **** --- 1,2 ---- + *.1 + .dir From lattner at cs.uiuc.edu Tue Nov 8 14:08:54 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:54 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/ps/.cvsignore Message-ID: <200511082008.OAA30847@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/ps: .cvsignore added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+2 -0) .cvsignore | 2 ++ 1 files changed, 2 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/ps/.cvsignore diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/ps/.cvsignore:1.1 *** /dev/null Tue Nov 8 14:08:51 2005 --- llvm-www/releases/1.6/docs/CommandGuide/ps/.cvsignore Tue Nov 8 14:08:41 2005 *************** *** 0 **** --- 1,2 ---- + *ps + .dir From lattner at cs.uiuc.edu Tue Nov 8 14:08:55 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:55 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/html/.cvsignore Message-ID: <200511082008.OAA30855@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/html: .cvsignore added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+2 -0) .cvsignore | 2 ++ 1 files changed, 2 insertions(+) Index: llvm-www/releases/1.6/docs/CommandGuide/html/.cvsignore diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/html/.cvsignore:1.1 *** /dev/null Tue Nov 8 14:08:51 2005 --- llvm-www/releases/1.6/docs/CommandGuide/html/.cvsignore Tue Nov 8 14:08:41 2005 *************** *** 0 **** --- 1,2 ---- + *html + .dir From lattner at cs.uiuc.edu Tue Nov 8 14:08:54 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:08:54 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/1.6/docs/CommandGuide/man/.cvsignore Message-ID: <200511082008.OAA30839@zion.cs.uiuc.edu> Changes in directory llvm-www/releases/1.6/docs/CommandGuide/man: .cvsignore added (r1.1) --- Log message: check in 1.6 dox --- Diffs of the changes: (+1 -0) .cvsignore | 1 + 1 files changed, 1 insertion(+) Index: llvm-www/releases/1.6/docs/CommandGuide/man/.cvsignore diff -c /dev/null llvm-www/releases/1.6/docs/CommandGuide/man/.cvsignore:1.1 *** /dev/null Tue Nov 8 14:08:51 2005 --- llvm-www/releases/1.6/docs/CommandGuide/man/.cvsignore Tue Nov 8 14:08:41 2005 *************** *** 0 **** --- 1 ---- + .dir From criswell at cs.uiuc.edu Tue Nov 8 14:11:52 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 14:11:52 -0600 Subject: [llvm-commits] CVS: llvm-www/releases/index.html download.html Message-ID: <200511082011.OAA07233@choi.cs.uiuc.edu> Changes in directory llvm-www/releases: index.html updated: 1.24 -> 1.25 download.html updated: 1.23 -> 1.24 --- Log message: Add LLVM 1.6. --- Diffs of the changes: (+34 -1) download.html | 29 +++++++++++++++++++++++++++++ index.html | 6 +++++- 2 files changed, 34 insertions(+), 1 deletion(-) Index: llvm-www/releases/index.html diff -u llvm-www/releases/index.html:1.24 llvm-www/releases/index.html:1.25 --- llvm-www/releases/index.html:1.24 Wed May 18 14:24:23 2005 +++ llvm-www/releases/index.html Tue Nov 8 14:11:31 2005 @@ -28,7 +28,7 @@
-

LLVM is distributed under the University of +

LLVM is distributed under the University of Illinois Open Source License, an OSI-approved license.

@@ -43,6 +43,9 @@
  • Always - Anonymous CVS access; release notes.
  • +
  • 08 Nov 2005 - 1.6 release download; release notes.
  • +
  • 18 May 2005 - 1.5 release download; release notes.
  • @@ -73,6 +76,7 @@
    + +
    Download LLVM 1.6
    + + + + +
    Download LLVM 1.5
    From lattner at cs.uiuc.edu Tue Nov 8 14:26:25 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 14:26:25 -0600 Subject: [llvm-commits] CVS: llvm-www/header.incl Message-ID: <200511082026.OAA32717@zion.cs.uiuc.edu> Changes in directory llvm-www: header.incl updated: 1.43 -> 1.44 --- Log message: 1.6 is out! --- Diffs of the changes: (+3 -2) header.incl | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) Index: llvm-www/header.incl diff -u llvm-www/header.incl:1.43 llvm-www/header.incl:1.44 --- llvm-www/header.incl:1.43 Mon Oct 24 20:17:14 2005 +++ llvm-www/header.incl Tue Nov 8 14:26:13 2005 @@ -37,7 +37,7 @@ Download!
    Download now: -LLVM 1.5
    +LLVM 1.6

    Try the
    @@ -45,7 +45,7 @@
    View the open-source
    -license +license

    @@ -65,6 +65,7 @@ Status Updates
    + Nov 8, 2005
    May 18, 2005
    February 14, 2005
    December 9, 2004
    From criswell at cs.uiuc.edu Tue Nov 8 14:30:23 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 14:30:23 -0600 Subject: [llvm-commits] CVS: llvm-www/www-index.html Message-ID: <200511082030.OAA07392@choi.cs.uiuc.edu> Changes in directory llvm-www: www-index.html updated: 1.123 -> 1.124 --- Log message: Bless LLVM 1.6. --- Diffs of the changes: (+2 -2) www-index.html | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm-www/www-index.html diff -u llvm-www/www-index.html:1.123 llvm-www/www-index.html:1.124 --- llvm-www/www-index.html:1.123 Sat Jul 16 00:43:39 2005 +++ llvm-www/www-index.html Tue Nov 8 14:30:03 2005 @@ -102,9 +102,9 @@
    Latest LLVM Release!
    -

    May 18, 2005: LLVM 1.5 is now available +

    Nov 08, 2005: LLVM 1.6 is now available for download! LLVM is publicly available under an open source License. Also, you might want to + href="releases/1.6/LICENSE.TXT">License. Also, you might want to check out the new features in CVS that will appear in the next LLVM release. If you want them early, download LLVM through From criswell at cs.uiuc.edu Tue Nov 8 15:00:51 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:00:51 -0600 Subject: [llvm-commits] CVS: llvm-gcc/gcc/version.c Message-ID: <200511082100.PAA07497@choi.cs.uiuc.edu> Changes in directory llvm-gcc/gcc: version.c updated: 1.3 -> 1.4 --- Log message: Updated version for LLVM 1.7. --- Diffs of the changes: (+1 -1) version.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm-gcc/gcc/version.c diff -u llvm-gcc/gcc/version.c:1.3 llvm-gcc/gcc/version.c:1.4 --- llvm-gcc/gcc/version.c:1.3 Thu Feb 5 10:05:45 2004 +++ llvm-gcc/gcc/version.c Tue Nov 8 15:00:31 2005 @@ -5,7 +5,7 @@ please modify this string to indicate that, e.g. by putting your organization's name in parentheses at the end of the string. */ -const char version_string[] = "3.4-llvm 20030924 (experimental)"; +const char version_string[] = "3.4-llvm 20051104 (LLVM 1.7cvs)"; /* This is the location of the online document giving instructions for reporting bugs. If you distribute a modified version of GCC, From criswell at cs.uiuc.edu Tue Nov 8 15:12:00 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:00 -0600 Subject: [llvm-commits] CVS: llvm/autoconf/configure.ac Message-ID: <200511082112.PAA07780@choi.cs.uiuc.edu> Changes in directory llvm/autoconf: configure.ac updated: 1.196 -> 1.197 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+2 -2) configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/autoconf/configure.ac diff -u llvm/autoconf/configure.ac:1.196 llvm/autoconf/configure.ac:1.197 --- llvm/autoconf/configure.ac:1.196 Tue Nov 1 14:58:08 2005 +++ llvm/autoconf/configure.ac Tue Nov 8 15:11:31 2005 @@ -31,12 +31,12 @@ dnl===-----------------------------------------------------------------------=== dnl Initialize autoconf and define the package name, version number and dnl email address for reporting bugs. -AC_INIT([[llvm]],[[1.6cvs]],[llvmbugs at cs.uiuc.edu]) +AC_INIT([[llvm]],[[1.6]],[llvmbugs at cs.uiuc.edu]) dnl Provide a copyright substitution and ensure the copyright notice is included dnl in the output of --version option of the generated configure script. AC_SUBST(LLVM_COPYRIGHT,["Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign."]) -AC_COPYRIGHT($LLVM_COPYRIGHT) +AC_COPYRIGHT([Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign.]) dnl Indicate that we require autoconf 2.59 or later. Ths is needed because we dnl use some autoconf macros only available in 2.59. From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm-test/MultiSource/Applications/Makefile Message-ID: <200511082112.PAA07800@choi.cs.uiuc.edu> Changes in directory llvm-test/MultiSource/Applications: Makefile updated: 1.21 -> 1.22 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+1 -0) Makefile | 1 + 1 files changed, 1 insertion(+) Index: llvm-test/MultiSource/Applications/Makefile diff -u llvm-test/MultiSource/Applications/Makefile:1.21 llvm-test/MultiSource/Applications/Makefile:1.22 --- llvm-test/MultiSource/Applications/Makefile:1.21 Fri Aug 5 01:20:48 2005 +++ llvm-test/MultiSource/Applications/Makefile Tue Nov 8 15:11:32 2005 @@ -18,6 +18,7 @@ ifeq ($(OS),SunOS) PARALLEL_DIRS := $(filter-out SPASS, $(PARALLEL_DIRS)) +PARALLEL_DIRS := $(filter-out hexxagon, $(PARALLEL_DIRS)) endif include $(LEVEL)/Makefile.programs From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm/docs/GettingStarted.html ReleaseNotes.html Message-ID: <200511082112.PAA07790@choi.cs.uiuc.edu> Changes in directory llvm/docs: GettingStarted.html updated: 1.122 -> 1.123 ReleaseNotes.html updated: 1.341 -> 1.342 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+16 -2) GettingStarted.html | 3 ++- ReleaseNotes.html | 15 ++++++++++++++- 2 files changed, 16 insertions(+), 2 deletions(-) Index: llvm/docs/GettingStarted.html diff -u llvm/docs/GettingStarted.html:1.122 llvm/docs/GettingStarted.html:1.123 --- llvm/docs/GettingStarted.html:1.122 Thu Nov 3 12:32:06 2005 +++ llvm/docs/GettingStarted.html Tue Nov 8 15:11:31 2005 @@ -661,6 +661,7 @@ labels:

      +
    • Release 1.6: RELEASE_16
    • Release 1.5: RELEASE_15
    • Release 1.4: RELEASE_14
    • Release 1.3: RELEASE_13
    • @@ -1540,7 +1541,7 @@ Chris Lattner
      Reid Spencer
      The LLVM Compiler Infrastructure
      - Last modified: $Date: 2005/11/03 18:32:06 $ + Last modified: $Date: 2005/11/08 21:11:31 $ Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.341 llvm/docs/ReleaseNotes.html:1.342 --- llvm/docs/ReleaseNotes.html:1.341 Thu Nov 3 16:33:48 2005 +++ llvm/docs/ReleaseNotes.html Tue Nov 8 15:11:31 2005 @@ -318,6 +318,19 @@ + +
      + + +
      + + + + @@ -715,7 +728,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
      - Last modified: $Date: 2005/11/03 22:33:48 $ + Last modified: $Date: 2005/11/08 21:11:31 $ From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm/configure Message-ID: <200511082112.PAA07796@choi.cs.uiuc.edu> Changes in directory llvm: configure updated: 1.199 -> 1.200 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+11 -11) configure | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-) Index: llvm/configure diff -u llvm/configure:1.199 llvm/configure:1.200 --- llvm/configure:1.199 Tue Nov 1 15:00:49 2005 +++ llvm/configure Tue Nov 8 15:11:28 2005 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.59 for llvm 1.6cvs. +# Generated by GNU Autoconf 2.59 for llvm 1.6. # # Report bugs to . # @@ -8,7 +8,7 @@ # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. # -# $LLVM_COPYRIGHT +# Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign. ## --------------------- ## ## M4sh Initialization. ## ## --------------------- ## @@ -425,8 +425,8 @@ # Identity of this package. PACKAGE_NAME='llvm' PACKAGE_TARNAME='-llvm-' -PACKAGE_VERSION='1.6cvs' -PACKAGE_STRING='llvm 1.6cvs' +PACKAGE_VERSION='1.6' +PACKAGE_STRING='llvm 1.6' PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="lib/VMCore/Module.cpp" @@ -964,7 +964,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures llvm 1.6cvs to adapt to many kinds of systems. +\`configure' configures llvm 1.6 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1026,7 +1026,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of llvm 1.6cvs:";; + short | recursive ) echo "Configuration of llvm 1.6:";; esac cat <<\_ACEOF @@ -1173,14 +1173,14 @@ test -n "$ac_init_help" && exit 0 if $ac_init_version; then cat <<\_ACEOF -llvm configure 1.6cvs +llvm configure 1.6 generated by GNU Autoconf 2.59 Copyright (C) 2003 Free Software Foundation, Inc. This configure script is free software; the Free Software Foundation gives unlimited permission to copy, distribute and modify it. -$LLVM_COPYRIGHT +Copyright (c) 2003-2005 University of Illinois at Urbana-Champaign. _ACEOF exit 0 fi @@ -1189,7 +1189,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by llvm $as_me 1.6cvs, which was +It was created by llvm $as_me 1.6, which was generated by GNU Autoconf 2.59. Invocation command line was $ $0 $@ @@ -31044,7 +31044,7 @@ } >&5 cat >&5 <<_CSEOF -This file was extended by llvm $as_me 1.6cvs, which was +This file was extended by llvm $as_me 1.6, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -31107,7 +31107,7 @@ cat >>$CONFIG_STATUS <<_ACEOF ac_cs_version="\\ -llvm config.status 1.6cvs +llvm config.status 1.6 configured by $0, generated by GNU Autoconf 2.59, with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\" From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm-test/autoconf/configure.ac Message-ID: <200511082112.PAA07786@choi.cs.uiuc.edu> Changes in directory llvm-test/autoconf: configure.ac updated: 1.27 -> 1.28 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+1 -1) configure.ac | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm-test/autoconf/configure.ac diff -u llvm-test/autoconf/configure.ac:1.27 llvm-test/autoconf/configure.ac:1.28 --- llvm-test/autoconf/configure.ac:1.27 Mon Aug 8 16:26:12 2005 +++ llvm-test/autoconf/configure.ac Tue Nov 8 15:11:32 2005 @@ -1,5 +1,5 @@ dnl Initialize autoconf -AC_INIT([[LLVM-TEST]],[[1.6cvs]],[llvmbugs at cs.uiuc.edu]) +AC_INIT([[LLVM-TEST]],[[1.6]],[llvmbugs at cs.uiuc.edu]) dnl Place all of the extra autoconf files into the config subdirectory AC_CONFIG_AUX_DIR([autoconf]) From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr 2005-02-20-AggregateSAVEEXPR.c Message-ID: <200511082112.PAA07793@choi.cs.uiuc.edu> Changes in directory llvm/test/Regression/CFrontend: 2004-06-17-UnorderedCompares.c.tr updated: 1.4 -> 1.5 2005-02-20-AggregateSAVEEXPR.c updated: 1.2 -> 1.3 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+2 -2) 2004-06-17-UnorderedCompares.c.tr | 2 +- 2005-02-20-AggregateSAVEEXPR.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr diff -u llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr:1.4 llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr:1.5 --- llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr:1.4 Mon Sep 12 20:03:53 2005 +++ llvm/test/Regression/CFrontend/2004-06-17-UnorderedCompares.c.tr Tue Nov 8 15:11:32 2005 @@ -1,5 +1,5 @@ // RUN: %llvmgcc -xc -std=c99 %s -c -o - | llvm-dis | grep -v llvm.isunordered | not grep call -// XFAIL: sparcv9|ia64 +// XFAIL: sparc|ia64 #include Index: llvm/test/Regression/CFrontend/2005-02-20-AggregateSAVEEXPR.c diff -u llvm/test/Regression/CFrontend/2005-02-20-AggregateSAVEEXPR.c:1.2 llvm/test/Regression/CFrontend/2005-02-20-AggregateSAVEEXPR.c:1.3 --- llvm/test/Regression/CFrontend/2005-02-20-AggregateSAVEEXPR.c:1.2 Fri Apr 1 17:16:23 2005 +++ llvm/test/Regression/CFrontend/2005-02-20-AggregateSAVEEXPR.c Tue Nov 8 15:11:32 2005 @@ -6,7 +6,7 @@ // We could modify the test to use only GCC extensions, but I don't know if // that would change the nature of the test. // -// XFAIL: sparcv9 +// XFAIL: sparc #include From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm/test/Regression/ExecutionEngine/parallel.ll Message-ID: <200511082112.PAA07804@choi.cs.uiuc.edu> Changes in directory llvm/test/Regression/ExecutionEngine: parallel.ll updated: 1.1 -> 1.2 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+1 -1) parallel.ll | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm/test/Regression/ExecutionEngine/parallel.ll diff -u llvm/test/Regression/ExecutionEngine/parallel.ll:1.1 llvm/test/Regression/ExecutionEngine/parallel.ll:1.2 --- llvm/test/Regression/ExecutionEngine/parallel.ll:1.1 Tue Jul 12 19:35:12 2005 +++ llvm/test/Regression/ExecutionEngine/parallel.ll Tue Nov 8 15:11:33 2005 @@ -1,3 +1,3 @@ ; This isn't really an assembly file. This test runs the ParallelJIT example ; program and ensures its output is sane. -; RUN: ParallelJIT | grep -q "Fib2 returned 267914296" +; RUN: ParallelJIT | grep "Fib2 returned 267914296" From criswell at cs.uiuc.edu Tue Nov 8 15:12:02 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:12:02 -0600 Subject: [llvm-commits] CVS: llvm-test/configure Message-ID: <200511082112.PAA07810@choi.cs.uiuc.edu> Changes in directory llvm-test: configure updated: 1.28 -> 1.29 --- Log message: Merged from RELEASE_16. --- Diffs of the changes: (+9 -9) configure | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) Index: llvm-test/configure diff -u llvm-test/configure:1.28 llvm-test/configure:1.29 --- llvm-test/configure:1.28 Mon Aug 8 16:26:07 2005 +++ llvm-test/configure Tue Nov 8 15:11:32 2005 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.59 for LLVM-TEST 1.6cvs. +# Generated by GNU Autoconf 2.59 for LLVM-TEST 1.6. # # Report bugs to . # @@ -423,8 +423,8 @@ # Identity of this package. PACKAGE_NAME='LLVM-TEST' PACKAGE_TARNAME='-llvm-test-' -PACKAGE_VERSION='1.6cvs' -PACKAGE_STRING='LLVM-TEST 1.6cvs' +PACKAGE_VERSION='1.6' +PACKAGE_STRING='LLVM-TEST 1.6' PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="SingleSource/Benchmarks/Makefile" @@ -954,7 +954,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures LLVM-TEST 1.6cvs to adapt to many kinds of systems. +\`configure' configures LLVM-TEST 1.6 to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1015,7 +1015,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of LLVM-TEST 1.6cvs:";; + short | recursive ) echo "Configuration of LLVM-TEST 1.6:";; esac cat <<\_ACEOF @@ -1173,7 +1173,7 @@ test -n "$ac_init_help" && exit 0 if $ac_init_version; then cat <<\_ACEOF -LLVM-TEST configure 1.6cvs +LLVM-TEST configure 1.6 generated by GNU Autoconf 2.59 Copyright (C) 2003 Free Software Foundation, Inc. @@ -1187,7 +1187,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by LLVM-TEST $as_me 1.6cvs, which was +It was created by LLVM-TEST $as_me 1.6, which was generated by GNU Autoconf 2.59. Invocation command line was $ $0 $@ @@ -20438,7 +20438,7 @@ } >&5 cat >&5 <<_CSEOF -This file was extended by LLVM-TEST $as_me 1.6cvs, which was +This file was extended by LLVM-TEST $as_me 1.6, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -20496,7 +20496,7 @@ cat >>$CONFIG_STATUS <<_ACEOF ac_cs_version="\\ -LLVM-TEST config.status 1.6cvs +LLVM-TEST config.status 1.6 configured by $0, generated by GNU Autoconf 2.59, with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\" From criswell at cs.uiuc.edu Tue Nov 8 15:13:14 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:13:14 -0600 Subject: [llvm-commits] CVS: llvm/configure Message-ID: <200511082113.PAA08030@choi.cs.uiuc.edu> Changes in directory llvm: configure updated: 1.200 -> 1.201 --- Log message: Updated version to 1.7cvs. --- Diffs of the changes: (+9 -9) configure | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) Index: llvm/configure diff -u llvm/configure:1.200 llvm/configure:1.201 --- llvm/configure:1.200 Tue Nov 8 15:11:28 2005 +++ llvm/configure Tue Nov 8 15:12:58 2005 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.59 for llvm 1.6. +# Generated by GNU Autoconf 2.59 for llvm 1.7cvs. # # Report bugs to . # @@ -425,8 +425,8 @@ # Identity of this package. PACKAGE_NAME='llvm' PACKAGE_TARNAME='-llvm-' -PACKAGE_VERSION='1.6' -PACKAGE_STRING='llvm 1.6' +PACKAGE_VERSION='1.7cvs' +PACKAGE_STRING='llvm 1.7cvs' PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="lib/VMCore/Module.cpp" @@ -964,7 +964,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures llvm 1.6 to adapt to many kinds of systems. +\`configure' configures llvm 1.7cvs to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1026,7 +1026,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of llvm 1.6:";; + short | recursive ) echo "Configuration of llvm 1.7cvs:";; esac cat <<\_ACEOF @@ -1173,7 +1173,7 @@ test -n "$ac_init_help" && exit 0 if $ac_init_version; then cat <<\_ACEOF -llvm configure 1.6 +llvm configure 1.7cvs generated by GNU Autoconf 2.59 Copyright (C) 2003 Free Software Foundation, Inc. @@ -1189,7 +1189,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by llvm $as_me 1.6, which was +It was created by llvm $as_me 1.7cvs, which was generated by GNU Autoconf 2.59. Invocation command line was $ $0 $@ @@ -31044,7 +31044,7 @@ } >&5 cat >&5 <<_CSEOF -This file was extended by llvm $as_me 1.6, which was +This file was extended by llvm $as_me 1.7cvs, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -31107,7 +31107,7 @@ cat >>$CONFIG_STATUS <<_ACEOF ac_cs_version="\\ -llvm config.status 1.6 +llvm config.status 1.7cvs configured by $0, generated by GNU Autoconf 2.59, with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\" From criswell at cs.uiuc.edu Tue Nov 8 15:13:17 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:13:17 -0600 Subject: [llvm-commits] CVS: llvm/autoconf/configure.ac Message-ID: <200511082113.PAA08114@choi.cs.uiuc.edu> Changes in directory llvm/autoconf: configure.ac updated: 1.197 -> 1.198 --- Log message: Updated version to 1.7cvs. --- Diffs of the changes: (+1 -1) configure.ac | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm/autoconf/configure.ac diff -u llvm/autoconf/configure.ac:1.197 llvm/autoconf/configure.ac:1.198 --- llvm/autoconf/configure.ac:1.197 Tue Nov 8 15:11:31 2005 +++ llvm/autoconf/configure.ac Tue Nov 8 15:13:01 2005 @@ -31,7 +31,7 @@ dnl===-----------------------------------------------------------------------=== dnl Initialize autoconf and define the package name, version number and dnl email address for reporting bugs. -AC_INIT([[llvm]],[[1.6]],[llvmbugs at cs.uiuc.edu]) +AC_INIT([[llvm]],[[1.7cvs]],[llvmbugs at cs.uiuc.edu]) dnl Provide a copyright substitution and ensure the copyright notice is included dnl in the output of --version option of the generated configure script. From criswell at cs.uiuc.edu Tue Nov 8 15:14:06 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:14:06 -0600 Subject: [llvm-commits] CVS: llvm-test/configure Message-ID: <200511082114.PAA08221@choi.cs.uiuc.edu> Changes in directory llvm-test: configure updated: 1.29 -> 1.30 --- Log message: Updated to version 1.7cvs. --- Diffs of the changes: (+9 -9) configure | 18 +++++++++--------- 1 files changed, 9 insertions(+), 9 deletions(-) Index: llvm-test/configure diff -u llvm-test/configure:1.29 llvm-test/configure:1.30 --- llvm-test/configure:1.29 Tue Nov 8 15:11:32 2005 +++ llvm-test/configure Tue Nov 8 15:13:45 2005 @@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. -# Generated by GNU Autoconf 2.59 for LLVM-TEST 1.6. +# Generated by GNU Autoconf 2.59 for LLVM-TEST 1.7cvs. # # Report bugs to . # @@ -423,8 +423,8 @@ # Identity of this package. PACKAGE_NAME='LLVM-TEST' PACKAGE_TARNAME='-llvm-test-' -PACKAGE_VERSION='1.6' -PACKAGE_STRING='LLVM-TEST 1.6' +PACKAGE_VERSION='1.7cvs' +PACKAGE_STRING='LLVM-TEST 1.7cvs' PACKAGE_BUGREPORT='llvmbugs at cs.uiuc.edu' ac_unique_file="SingleSource/Benchmarks/Makefile" @@ -954,7 +954,7 @@ # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<_ACEOF -\`configure' configures LLVM-TEST 1.6 to adapt to many kinds of systems. +\`configure' configures LLVM-TEST 1.7cvs to adapt to many kinds of systems. Usage: $0 [OPTION]... [VAR=VALUE]... @@ -1015,7 +1015,7 @@ if test -n "$ac_init_help"; then case $ac_init_help in - short | recursive ) echo "Configuration of LLVM-TEST 1.6:";; + short | recursive ) echo "Configuration of LLVM-TEST 1.7cvs:";; esac cat <<\_ACEOF @@ -1173,7 +1173,7 @@ test -n "$ac_init_help" && exit 0 if $ac_init_version; then cat <<\_ACEOF -LLVM-TEST configure 1.6 +LLVM-TEST configure 1.7cvs generated by GNU Autoconf 2.59 Copyright (C) 2003 Free Software Foundation, Inc. @@ -1187,7 +1187,7 @@ This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. -It was created by LLVM-TEST $as_me 1.6, which was +It was created by LLVM-TEST $as_me 1.7cvs, which was generated by GNU Autoconf 2.59. Invocation command line was $ $0 $@ @@ -20438,7 +20438,7 @@ } >&5 cat >&5 <<_CSEOF -This file was extended by LLVM-TEST $as_me 1.6, which was +This file was extended by LLVM-TEST $as_me 1.7cvs, which was generated by GNU Autoconf 2.59. Invocation command line was CONFIG_FILES = $CONFIG_FILES @@ -20496,7 +20496,7 @@ cat >>$CONFIG_STATUS <<_ACEOF ac_cs_version="\\ -LLVM-TEST config.status 1.6 +LLVM-TEST config.status 1.7cvs configured by $0, generated by GNU Autoconf 2.59, with options \\"`echo "$ac_configure_args" | sed 's/[\\""\`\$]/\\\\&/g'`\\" From criswell at cs.uiuc.edu Tue Nov 8 15:14:06 2005 From: criswell at cs.uiuc.edu (John Criswell) Date: Tue, 8 Nov 2005 15:14:06 -0600 Subject: [llvm-commits] CVS: llvm-test/autoconf/configure.ac Message-ID: <200511082114.PAA08222@choi.cs.uiuc.edu> Changes in directory llvm-test/autoconf: configure.ac updated: 1.28 -> 1.29 --- Log message: Updated to version 1.7cvs. --- Diffs of the changes: (+1 -1) configure.ac | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-) Index: llvm-test/autoconf/configure.ac diff -u llvm-test/autoconf/configure.ac:1.28 llvm-test/autoconf/configure.ac:1.29 --- llvm-test/autoconf/configure.ac:1.28 Tue Nov 8 15:11:32 2005 +++ llvm-test/autoconf/configure.ac Tue Nov 8 15:13:47 2005 @@ -1,5 +1,5 @@ dnl Initialize autoconf -AC_INIT([[LLVM-TEST]],[[1.6]],[llvmbugs at cs.uiuc.edu]) +AC_INIT([[LLVM-TEST]],[[1.7cvs]],[llvmbugs at cs.uiuc.edu]) dnl Place all of the extra autoconf files into the config subdirectory AC_CONFIG_AUX_DIR([autoconf]) From lattner at cs.uiuc.edu Tue Nov 8 15:29:29 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 15:29:29 -0600 Subject: [llvm-commits] CVS: llvm/docs/ReleaseNotes.html Message-ID: <200511082129.PAA24093@zion.cs.uiuc.edu> Changes in directory llvm/docs: ReleaseNotes.html updated: 1.342 -> 1.343 --- Log message: Rip out 1.6ness, bump version # to 1.7cvs --- Diffs of the changes: (+6 -178) ReleaseNotes.html | 184 +----------------------------------------------------- 1 files changed, 6 insertions(+), 178 deletions(-) Index: llvm/docs/ReleaseNotes.html diff -u llvm/docs/ReleaseNotes.html:1.342 llvm/docs/ReleaseNotes.html:1.343 --- llvm/docs/ReleaseNotes.html:1.342 Tue Nov 8 15:11:31 2005 +++ llvm/docs/ReleaseNotes.html Tue Nov 8 15:29:17 2005 @@ -4,11 +4,11 @@ - LLVM 1.6 Release Notes + LLVM 1.7cvs Release Notes -
      LLVM 1.6 Release Notes
      +
      LLVM 1.7 Release Notes
      1. Introduction
      2. @@ -32,10 +32,10 @@

        This document contains the release notes for the LLVM compiler -infrastructure, release 1.6. Here we describe the status of LLVM, including any +infrastructure, release 1.7. Here we describe the status of LLVM, including any known problems and major improvements from the previous release. The most up-to-date version of this document can be found on the LLVM 1.6 web site. If you are +href="http://llvm.org/releases/">LLVM releases 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.

        @@ -71,181 +71,9 @@ - - - -
        -

        LLVM now includes support for auto-generating large portions of the -instruction selectors from target descriptions. This allows us to -write patterns in the target .td file, instead of writing lots of -nasty C++ code. Most of the PowerPC instruction selector is now -generated from the PowerPC target description files and other targets -are adding support that will be live for LLVM 1.7.

        - -

        For example, here are some patterns used by the PowerPC backend. A -floating-point multiply then subtract instruction (FMSUBS):

        - -

        -(set F4RC:$FRT, (fsub (fmul F4RC:$FRA, F4RC:$FRC), F4RC:$FRB)) -

        - -

        Exclusive-or by 16-bit immediate (XORI):

        - -

        -(set GPRC:$dst, (xor GPRC:$src1, immZExt16:$src2)) -

        - -

        Exclusive-or by 16-bit immediate shifted right 16-bits (XORIS):

        - -

        -(set GPRC:$dst, (xor GPRC:$src1, imm16Shifted:$src2)) -

        - -

        With these definitions, we teach the code generator how to combine these two -instructions to xor an abitrary 32-bit immediate with the following -definition. The first line specifies what to match (a xor with an arbitrary -immediate) the second line specifies what to produce:

        - -

        -

        def : Pat<(xor GPRC:$in, imm:$imm),
        -          (XORIS (XORI GPRC:$in, (LO16 imm:$imm)), (HI16 imm:$imm))>;
        -
        -

        - -
        - - - - -
        - -

        Instruction selectors using the refined instruction selection framework can now -use a simple pre-pass scheduler included with LLVM 1.6. This scheduler is -currently simple (cannot be configured much by the targets), but will be -extended in the future.

        -
        - - - - -
        -

        It is now straight-forward to parameterize a target implementation, and -provide a mapping from CPU names to sets of target parameters. LLC now supports -a -mcpu=cpu option that lets you choose a subtarget by CPU name: use -"llvm-as < /dev/null | llc -march=XXX -mcpu=help" to get a list of -supported CPUs for target "XXX". It also provides a --mattr=+attr1,-attr2 option that can be used to control individual -features of a target (the previous command will list available features as -well).

        - -

        This functionality is nice when you want tell LLC something like "compile to -code that is specialized for the PowerPC G5, but doesn't use altivec code. In -this case, using "llc -march=ppc32 -mcpu=g5 -mattr=-altivec".

        - -
        - - - - -
        -
          -
        1. The JIT now uses mutexes to protect its internal data structures. This - allows multi-threaded programs to be run from the JIT or interpreter without - corruption of the internal data structures. See - PR418 and - PR540 for the details. -
        2. -
        3. LLVM on Win32 no longer requires sed, - flex, or bison when compiling with Visual C++.
        4. -
        5. The llvm-test suite can now use the NAG Fortran to C compiler to compile - SPEC FP programs if available (allowing us to test all of SPEC'95 & - 2000).
        6. -
        7. When bugpoint is grinding away and the user hits ctrl-C, it now - gracefully stops and gives what it has reduced so far, instead of - giving up completely. In addition, the JIT - debugging mode of bugpoint is much faster.
        8. -
        9. LLVM now includes Xcode project files in the llvm/Xcode directory.
        10. -
        11. LLVM now supports Mac OS X on Intel.
        12. -
        13. LLVM now builds cleanly with GCC 4.1.
        14. -
        -
        - - - - -
        -
          -
        1. The -globalopt pass can now statically evaluate C++ static - constructors when they are simple enough. For example, it can - now statically initialize "struct X { int a; X() : a(4) {} } g;". -
        2. -
        3. The Loop Strength Reduction pass has been completely rewritten, is far - more aggressive, and is turned on by default in the RISC targets. On PPC, - we find that it often speeds up programs from 10-40% depending on the - program.
        4. -
        5. The code produced when exception handling is enabled is far more - efficient in some cases, particularly on Mac OS X.
        6. -
        -
        - - - - - -
        -
          -
        1. The Alpha backend is substantially more stable and robust than in LLVM 1.5. - For example, it now fully supports varargs functions. The Alpha backend - also now features beta JIT support.
        2. -
        3. The code generator contains a new component, the DAG Combiner. This allows - us to optimize lowered code (e.g. after 64-bit operations have been lowered - to use 32-bit registers on 32-bit targets) and do fine-grained bit-twiddling - optimizations for the backend.
        4. -
        5. The SelectionDAG infrastructure is far more capable and mature, able to - handle many new target peculiarities in a target-independent way.
        6. -
        7. The default register allocator is now far - faster on some testcases, - particularly on targets with a large number of registers (e.g. IA64 - and PPC).
        8. -
        -
        - - - - -
        -
          -
        1. A vast number of bugs have been fixed in the PowerPC backend and in - llvm-gcc when configured for Mac OS X (particularly relating to ABI - issues). For example: - PR449, - PR594, - PR603, - PR609, - PR630, - PR643, - and several others without bugzilla bugs.
        2. -
        3. Several bugs in tail call support have been fixed.
        4. -
        5. configure does not correctly detect gcc - version on cygwin.
        6. -
        7. Many many other random bugs have been fixed. Query our bugzilla with a target of 1.6 for more - information.
        8. -
        -
        @@ -728,7 +556,7 @@ src="http://www.w3.org/Icons/valid-html401" alt="Valid HTML 4.01!" /> The LLVM Compiler Infrastructure
        - Last modified: $Date: 2005/11/08 21:11:31 $ + Last modified: $Date: 2005/11/08 21:29:17 $ From lattner at cs.uiuc.edu Tue Nov 8 15:55:08 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 15:55:08 -0600 Subject: [llvm-commits] CVS: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Message-ID: <200511082155.PAA27531@zion.cs.uiuc.edu> Changes in directory llvm/lib/CodeGen/SelectionDAG: ScheduleDAG.cpp updated: 1.43 -> 1.44 --- Log message: Explicitly initialize some instance vars --- Diffs of the changes: (+5 -4) ScheduleDAG.cpp | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) Index: llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp diff -u llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:1.43 llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:1.44 --- llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp:1.43 Mon Nov 7 13:08:53 2005 +++ llvm/lib/CodeGen/SelectionDAG/ScheduleDAG.cpp Tue Nov 8 15:54:57 2005 @@ -402,7 +402,8 @@ public: // Ctor. - NodeGroupOpIterator(NodeInfo *N) : NI(N), GI(N) {} + NodeGroupOpIterator(NodeInfo *N) + : NI(N), GI(N), OI(SDNode::op_iterator()), OE(SDNode::op_iterator()) {} /// isEnd - Returns true when not more operands are available. /// @@ -652,9 +653,9 @@ /// IncludeNode - Add node to NodeInfo vector. /// void SimpleSched::IncludeNode(NodeInfo *NI) { - // Get node - SDNode *Node = NI->Node; - // Ignore entry node +// Get node +SDNode *Node = NI->Node; +// Ignore entry node if (Node->getOpcode() == ISD::EntryToken) return; // Check current count for node int Count = NI->getPending(); From lattner at cs.uiuc.edu Tue Nov 8 16:06:35 2005 From: lattner at cs.uiuc.edu (Chris Lattner) Date: Tue, 8 Nov 2005 16:06:35 -0600 Subject: [llvm-commits] CVS: llvm/include/llvm/CodeGen/SelectionDAGNodes.h Message-ID: <200511082206.QAA00847@zion.cs.uiuc.edu> Changes in directory llvm/include/llvm/CodeGen: SelectionDAGNodes.h updated: 1.70 -> 1.71 --- Log message: Switch the operandlist/valuelist from being vectors to being just an array. This saves 12 bytes from SDNode, but doesn't speed things up substantially (our graphs apparently already fit within the cache on my g5). In any case this reduces memory usage. --- Diffs of the changes: (+122 -72) SelectionDAGNodes.h | 194 ++++++++++++++++++++++++++++++++-------------------- 1 files changed, 122 insertions(+), 72 deletions(-) Index: llvm/include/llvm/CodeGen/SelectionDAGNodes.h diff -u llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1.70 llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1.71 --- llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1.70 Sat Oct 22 22:40:17 2005 +++ llvm/include/llvm/CodeGen/SelectionDAGNodes.h Tue Nov 8 16:06:23 2005 @@ -491,13 +491,16 @@ /// depth of 2, etc. unsigned short NodeDepth; - /// Operands - The values that are used by this operation. + /// OperandList - The values that are used by this operation. /// - std::vector Operands; + SDOperand *OperandList; + + /// ValueList - The types of the values this node defines. SDNode's may + /// define multiple values simultaneously. + MVT::ValueType *ValueList; - /// Values - The types of the values this node defines. SDNode's may define - /// multiple values simultaneously. - std::vector Values; + /// NumOperands/NumValues - The number of entries in the Operand/Value list. + unsigned short NumOperands, NumValues; /// Uses - These are all of the SDNode's that use a value produced by this /// node. @@ -533,37 +536,32 @@ /// getNumOperands - Return the number of values used by this operation. /// - unsigned getNumOperands() const { return Operands.size(); } - - const SDOperand &getOperand(unsigned Num) { - assert(Num < Operands.size() && "Invalid child # of SDNode!"); - return Operands[Num]; - } + unsigned getNumOperands() const { return NumOperands; } const SDOperand &getOperand(unsigned Num) const { - assert(Num < Operands.size() && "Invalid child # of SDNode!"); - return Operands[Num]; + assert(Num < NumOperands && "Invalid child # of SDNode!"); + return OperandList[Num]; } - typedef std::vector::const_iterator op_iterator; - op_iterator op_begin() const { return Operands.begin(); } - op_iterator op_end() const { return Operands.end(); } + typedef const SDOperand* op_iterator; + op_iterator op_begin() const { return OperandList; } + op_iterator op_end() const { return OperandList+NumOperands; } /// getNumValues - Return the number of values defined/returned by this /// operator. /// - unsigned getNumValue

    operation never modifies the archive. + + =item q[Rfz] + + Quickly append files to the end of the archive. The F, F, and F + modifiers apply to this operation. This operation quickly adds the + F to the archive without checking for duplicates that should be + removed first. If no F are specified, the archive is not modified. + Because of the way that B constructs the archive file, its dubious + whether the F operation is any faster than the F operation. + + =item r[Rabfuz] + + Replace or insert file members. The F, F, F, F, F, and F + modifiers apply to this operation. This operation will replace existing + F or insert them at the end of the archive if they do not exist. If no + F are specified, the archive is not modified. + + =item t[v] + + Print the table of contents. Without any modifiers, this operation just prints + the names of the members to the standard output. With the F modifier, + B also prints out the file type (B=bytecode, Z=compressed, S=symbol + table, blank=regular file), the permission mode, the owner and group, the + size, and the date. If any F are specified, the listing is only for + those files. If no F are specified, the table of contents for the + whole archive is printed. + + =item x[oP] + + Extract archive members back to files. The F modifier applies to this + operation. This operation retrieves the indicated F from the archive + and writes them back to the operating system's file system. If no + F are specified, the entire archive is extract. + + =back + + =head2 Modifiers (operation specific) + + The modifiers below are specific to certain operations. See the Operations + section (above) to determine which modifiers are applicable to which operations. + + =over + + =item [a] + + When inserting or moving member files, this option specifies the destination of + the new files as being Cfter the F member. If F is not found, + the files are placed at the end of the archive. + + =item [b] + + When inserting or moving member files, this option specifies the destination of + the new files as being Cefore the F member. If F is not + found, the files are placed at the end of the archive. This modifier is + identical to the the F modifier. + + =item [f] + + Normally, B stores the full path name to a file as presented to it on + the command line. With this option, truncated (15 characters max) names are + used. This ensures name compatibility with older versions of C but may also + thwart correct extraction of the files (duplicates may overwrite). If used with + the F option, the directory recursion will be performed but the file names + will all be Clattened to simple file names. + + =item [i] + + A synonym for the F option. + + =item [k] + + Normally, B will not print the contents of bytecode files when the + F