@@ -408,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.
@@ -446,9 +474,9 @@ 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.
@@ -466,7 +494,7 @@ 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
virtual bool doFinalization(Function &F);
-
+
The doFinalization method is an infrequently used method that is called
when the pass framework has finished calling
+
+
+
+A MachineFunctionPass executes on the machine-dependent
+representation of each LLVM function in the program,
+independent of all of the other functions in the program.
+A MachineFunctionPass is also a FunctionPass, so all
+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 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)
+
+
+
+
+
+ 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.
@@ -672,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:
@@ -698,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>();
}
@@ -1084,9 +1159,8 @@ 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]
+(gdb) run test.bc -load $(LLVMTOP)/llvm/lib/Debug/[libname].so -[passoption]
+Starting program: opt test.bc -load $(LLVMTOP)/llvm/lib/Debug/[libname].so -[passoption]
Breakpoint 1, PassManager::run (this=0xffbef174, M=@0x70b298) at Pass.cpp:70
70 bool PassManager::run(Module &M) { return PM->run(M); }
(gdb)
@@ -1139,12 +1213,12 @@ where we are going:
-Multiple CPU machines are becoming more command and compilation can never be
+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 seperate
+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
@@ -1199,8 +1273,10 @@ href="#Pass">Pass, only the other way around.
Chris Lattner
+The LLVM Compiler Infrastructure
+
-Last modified: Mon Sep 16 17:37:27 CDT 2002
+Last modified: Mon Oct 27 12:00:00 CDT 2003