| + +The ImmutablePass class + |
+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.
+ +ImmutablePass's never invalidate other transformations, are never +invalidated, and are never "run".
@@ -413,7 +436,7 @@ In contrast to direct Pass subclasses, direct FunctionPass subclasses do have a predictable, local behavior that can be expected by the system. All FunctionPass execute on each function in the program -independant of all of the other functions 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.
@@ -433,8 +456,8 @@ 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); @@ -442,17 +465,18 @@ method
+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 dependant malloc() and free() function calls. It +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 neccesary.
+free functions that it needs, adding prototypes to the module if necessary.
-
virtual bool doFinalization(Module &M); - +The doFinalization method is an infrequently used method that is called when the pass framework has finished calling not allowed to do any of the following:
BasicBlockPass's are useful for traditional local and "peephole" optimizations. They may override the same doInitialization and doFinalization methods that FunctionPass's have, but also have a -runOnBasicBlock method:
+href="#doInitialization_mod">doInitialization(Module &)
and doFinalization(Module &) methods that FunctionPass's have, but also have the following virtual methods that may also be implemented:+ + +
+ virtual bool doInitialization(Function &F); +
+ +The doIninitialize method is allowed to do most of the things that +BasicBlockPass's are not allowed to do, but that +FunctionPass's can. The doInitialization method is designed +to do simple initialization type of stuff that does not depend on the +BasicBlocks being processed. The doInitialization method call is not +scheduled to overlap with any other pass executions (thus it should be very +fast).
+
+ +
+ virtual bool doFinalization(Function &F); ++ +The doFinalization method is an infrequently used method that is called +when the pass framework has finished calling runOnBasicBlock for every BasicBlock in the +program being compiled. This can be used to perform per-function +finalization.
+ + + +
| + +The MachineFunctionPass class + |
+ + + +
+ 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.
+
|
@@ -644,14 +747,14 @@ href="http://llvm.cs.uiuc.edu/doxygen/classAnalysisUsage.html">AnalysisUsage
// setPreservesAll - Call this if the pass does not modify its input at all
void AnalysisUsage::setPreservesAll();
- // preservesCFG - This function should be called by the pass, iff they do not:
+ // setPreservesCFG - This function should be called by the pass, iff they do not:
//
// 1. Add or remove basic blocks from the function
// 2. Modify terminator instructions in any way.
//
// This is automatically implied for BasicBlockPass's
//
- void AnalysisUsage::preservesCFG();
+ void AnalysisUsage::setPreservesCFG();
Some examples of how to use these methods are: @@ -670,7 +773,7 @@ and:
// This example modifies the program, but does not modify the CFG void LICM::getAnalysisUsage(AnalysisUsage &AU) const { - AU.preservesCFG(); + AU.setPreservesCFG(); AU.addRequired<LoopInfo>(); } @@ -696,6 +799,127 @@ implementation. This method can be called by your run* method implementation, or by any other local method invoked by your run* method. + +
+ +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. + + +
|
| +Using GDB with dynamically loaded passes + |
+ +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.
+ + +
+ +
+$ 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 /shared/lattner/cvs/llvm/lib/Debug/[libname].so -[passoption]
+Starting program: /shared/lattner/cvs/llvm/tools/Debug/opt test.bc
+ -load /shared/lattner/cvs/llvm/lib/Debug/[libname].so -[passoption]
+Breakpoint 1, PassManager::run (this=0xffbef174, M=@0x70b298) at Pass.cpp:70
+70 bool PassManager::run(Module &M) { return PM->run(M); }
+(gdb)
+
+
+Once the opt stops in the PassManager::run method you are now
+free to set breakpoints in your pass so that you can trace through execution or
+do other standard debugging stuff.+ + + +
+ +
+ +
+ +
+ +
|
@@ -904,12 +1214,12 @@ where we are going:
|