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 +Debug+Asserts/lib/Hello.so shared object that can be dynamically loaded by the opt or bugpoint tools via their -load options. If your operating system uses a suffix other than .so (such as windows or Mac OS/X), the appropriate extension will be used.
@@ -337,7 +332,7 @@ is supplied as fourth argument.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 +"Debug+Asserts/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.
@@ -363,7 +358,7 @@ through our transformation like this (or course, any bitcode file will work):-$ opt -load ../../../Debug/lib/Hello.so -hello < hello.bc > /dev/null +$ opt -load ../../../Debug+Asserts/lib/Hello.so -hello < hello.bc > /dev/null Hello: __main Hello: puts Hello: main @@ -377,10 +372,10 @@ 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 with the -help option:-$ opt -load ../../../Debug/lib/Hello.so --help +$ opt -load ../../../Debug+Asserts/lib/Hello.so -help OVERVIEW: llvm .bc -> .bc modular optimizer USAGE: opt [options] <input bitcode> @@ -408,7 +403,7 @@ the execution time of your pass along with the other passes you queue up. For example:@@ -492,7 +487,7 @@ invalidated, and are never "run". href="http://llvm.org/doxygen/classllvm_1_1ModulePass.html">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 +referring 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. @@ -607,7 +602,7 @@ fast).-$ opt -load ../../../Debug/lib/Hello.so -hello -time-passes < hello.bc > /dev/null +$ opt -load ../../../Debug+Asserts/lib/Hello.so -hello -time-passes < hello.bc > /dev/null Hello: __main Hello: puts Hello: main @@ -453,7 +448,7 @@ 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 +optimize how passes are run, so that the resultant compiler isn't unnecessarily slow.
- virtual bool runOnSCC(const std::vector<CallGraphNode *> &SCCM) = 0; + virtual bool runOnSCC(CallGraphSCC &SCC) = 0;The runOnSCC method performs the interesting work of the pass, and @@ -909,16 +904,22 @@ 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 +program.
+ +Code generator passes are registered and initialized specially by +TargetMachine::addPassesToEmitFile and similar routines, so they +cannot generally be run from the opt or bugpoint +commands.
+ +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:
-
- Modify any LLVM Instructions, BasicBlocks or Functions.
+- Modify or create any LLVM IR Instructions, BasicBlocks, Arguments, + Functions, GlobalVariables, GlobalAliases, or Modules.
- Modify a MachineFunction other than the one currently being processed.
-- Add or remove MachineFunctions from the current Module.
-- Add or remove global variables from the current Module.
- Maintain state across invocations of runOnMachineFunction (including global data)
@@ -970,7 +971,7 @@ template, which requires you to pass 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, with opt or bugpoint). The second argument is the -name of the pass, which is to be used for the --help output of +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. @@ -1410,14 +1411,14 @@ allowing any analysis results to live across the execution of your pass. 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'). +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 +$ opt -load ../../../Debug+Asserts/lib/Hello.so -gcse -licm --debug-pass=Structure < hello.bc > /dev/null Module Pass Manager Function Pass Manager Dominator Set Construction @@ -1454,7 +1455,7 @@ passes. World pass in between the two passes:-$ opt -load ../../../Debug/lib/Hello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null +$ opt -load ../../../Debug+Asserts/lib/Hello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null Module Pass Manager Function Pass Manager Dominator Set Construction @@ -1495,7 +1496,7 @@ href="#getAnalysisUsage">getAnalysisUsage method to our pass: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 +$ opt -load ../../../Debug+Asserts/lib/Hello.so -gcse -hello -licm --debug-pass=Structure < hello.bc > /dev/null Pass Arguments: -gcse -hello -licm Module Pass Manager Function Pass Manager @@ -1625,12 +1626,12 @@ form;Note the two spaces prior to the help string produces a tidy result on the ---help query.
+-help query.-$ llc --help +$ llc -help ... - -regalloc - Register allocator to use: (default = linearscan) + -regalloc - Register allocator to use (default=linearscan) =linearscan - linear scan register allocator =local - local register allocator =simple - simple register allocator @@ -1736,8 +1737,8 @@ want:(gdb) break llvm::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] +(gdb) run test.bc -load $(LLVMTOP)/llvm/Debug+Asserts/lib/[libname].so -[passoption] +Starting program: opt test.bc -load $(LLVMTOP)/llvm/Debug+Asserts/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)