</ul></li>
<li><a href="#CallGraphSCCPass">The <tt>CallGraphSCCPass</tt> class</a>
<ul>
- <li><a href="#doInitialization_scc">The <tt>doInitialization(Module
+ <li><a href="#doInitialization_scc">The <tt>doInitialization(CallGraph
&)</tt> method</a></li>
<li><a href="#runOnSCC">The <tt>runOnSCC</tt> method</a></li>
- <li><a href="#doFinalization_scc">The <tt>doFinalization(Module
+ <li><a href="#doFinalization_scc">The <tt>doFinalization(CallGraph
&)</tt> method</a></li>
</ul></li>
<li><a href="#FunctionPass">The <tt>FunctionPass</tt> class</a>
<li><a href="#doFinalization_mod">The <tt>doFinalization(Module
&)</tt> method</a></li>
</ul></li>
+ <li><a href="#LoopPass">The <tt>LoopPass</tt> class</a>
+ <ul>
+ <li><a href="#doInitialization_loop">The <tt>doInitialization(Loop *,
+ LPPassManager &)</tt> method</a></li>
+ <li><a href="#runOnLoop">The <tt>runOnLoop</tt> method</a></li>
+ <li><a href="#doFinalization_loop">The <tt>doFinalization()
+ </tt> method</a></li>
+ </ul></li>
<li><a href="#BasicBlockPass">The <tt>BasicBlockPass</tt> class</a>
<ul>
<li><a href="#doInitialization_fn">The <tt>doInitialization(Function
<li><a href="#future">Future extensions planned</a>
<ul>
<li><a href="#SMP">Multithreaded LLVM</a></li>
- <li><a href="#PassFunctionPass"><tt>ModulePass</tt>es requiring
- <tt>FunctionPass</tt>es</a></li>
</ul></li>
</ol>
<div class="doc_author">
<p>Written by <a href="mailto:sabre@nondot.org">Chris Lattner</a> and
- <a href="mailto:jlaskey@apple.com">Jim Laskey</a></p>
+ <a href="mailto:jlaskey@mac.com">Jim Laskey</a></p>
</div>
<!-- *********************************************************************** -->
the <tt><a href="#ModulePass">ModulePass</a></tt>, <tt><a
href="#CallGraphSCCPass">CallGraphSCCPass</a></tt>, <tt><a
href="#FunctionPass">FunctionPass</a></tt>, or <tt><a
+href="#LoopPass">LoopPass</a></tt>, or <tt><a
href="#BasicBlockPass">BasicBlockPass</a></tt> 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
<div class="doc_code"><pre>
<b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
- std::cerr << "<i>Hello: </i>" << F.getName() << "\n";
+ llvm::cerr << "<i>Hello: </i>" << F.getName() << "\n";
<b>return false</b>;
}
}; <i>// end of struct Hello</i>
<b>namespace</b> {
<b>struct Hello</b> : <b>public</b> <a href="#FunctionPass">FunctionPass</a> {
<b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
- std::cerr << "<i>Hello: </i>" << F.getName() << "\n";
+ llvm::cerr << "<i>Hello: </i>" << F.getName() << "\n";
<b>return false</b>;
}
};
<tt>ModulePass</tt> 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 <tt>ModulePass</tt>
-subclasses, no optimization can be done for their execution.</p>
+subclasses, no optimization can be done for their execution. A module pass
+can use function level passes (e.g. dominators) using getAnalysis interface
+<tt> getAnalysis<DominatorTree>(Function)</tt>. </p>
<p>To write a correct <tt>ModulePass</tt> subclass, derive from
<tt>ModulePass</tt> and overload the <tt>runOnModule</tt> method with the
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="doInitialization_scc">The <tt>doInitialization(Module &)</tt>
+ <a name="doInitialization_scc">The <tt>doInitialization(CallGraph &)</tt>
method</a>
</div>
<div class="doc_text">
<div class="doc_code"><pre>
- <b>virtual bool</b> doInitialization(Module &M);
+ <b>virtual bool</b> doInitialization(CallGraph &CG);
</pre></div>
<p>The <tt>doIninitialize</tt> method is allowed to do most of the things that
<!-- _______________________________________________________________________ -->
<div class="doc_subsubsection">
- <a name="doFinalization_scc">The <tt>doFinalization(Module
+ <a name="doFinalization_scc">The <tt>doFinalization(CallGraph
&)</tt> method</a>
</div>
<div class="doc_text">
<div class="doc_code"><pre>
- <b>virtual bool</b> doFinalization(Module &M);
+ <b>virtual bool</b> doFinalization(CallGraph &CG);
</pre></div>
<p>The <tt>doFinalization</tt> method is an infrequently used method that is
</div>
+<!-- ======================================================================= -->
+<div class="doc_subsection">
+ <a name="LoopPass">The <tt>LoopPass</tt> class </a>
+</div>
+
+<div class="doc_text">
+
+<p> All <tt>LoopPass</tt> execute on each loop in the function independent of
+all of the other loops in the function. <tt>LoopPass</tt> processes loops in
+loop nest order such that outer most loop is processed last. </p>
+
+<p> <tt>LoopPass</tt> subclasses are allowed to update loop nest using
+<tt>LPPassManager</tt> interface. Implementing a loop pass is usually
+straightforward. <tt>Looppass</tt>'s may overload three virtual methods to
+do their work. All these methods should return true if they modified the
+program, or false if they didn't. </p>
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="doInitialization_loop">The <tt>doInitialization(Loop *,
+ LPPassManager &)</tt>
+ method</a>
+</div>
+
+<div class="doc_text">
+
+<div class="doc_code"><pre>
+ <b>virtual bool</b> doInitialization(Loop *, LPPassManager &LPM);
+</pre></div>
+
+The <tt>doInitialization</tt> method is designed to do simple initialization
+type of stuff that does not depend on the functions being processed. The
+<tt>doInitialization</tt> method call is not scheduled to overlap with any
+other pass executions (thus it should be very fast). LPPassManager
+interface should be used to access Function or Module level analysis
+information.</p>
+
+</div>
+
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="runOnLoop">The <tt>runOnLoop</tt> method</a>
+</div>
+
+<div class="doc_text">
+
+<div class="doc_code"><pre>
+ <b>virtual bool</b> runOnLoop(Loop *, LPPassManager &LPM) = 0;
+</pre></div><p>
+
+<p>The <tt>runOnLoop</tt> 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. <tt>LPPassManager</tt> interface
+should be used to update loop nest.</p>
+
+</div>
+
+<!-- _______________________________________________________________________ -->
+<div class="doc_subsubsection">
+ <a name="doFinalization_loop">The <tt>doFinalization()</tt> method</a>
+</div>
+
+<div class="doc_text">
+
+<div class="doc_code"><pre>
+ <b>virtual bool</b> doFinalization();
+</pre></div>
+
+<p>The <tt>doFinalization</tt> method is an infrequently used method that is
+called when the pass framework has finished calling <a
+href="#runOnLoop"><tt>runOnLoop</tt></a> for every loop in the
+program being compiled. </p>
+
+</div>
+
+
+
<!-- ======================================================================= -->
<div class="doc_subsection">
<a name="BasicBlockPass">The <tt>BasicBlockPass</tt> class</a>
<div class="doc_text">
<div class="doc_code"><pre>
- <b>virtual void</b> print(std::ostream &O, <b>const</b> Module *M) <b>const</b>;
+ <b>virtual void</b> print(llvm::OStream &O, <b>const</b> Module *M) <b>const</b>;
</pre></div>
<p>The <tt>print</tt> method must be implemented by "analyses" in order to print
an analysis itself, as well as for other people to figure out how an analysis
works. Use the <tt>opt -analyze</tt> argument to invoke this method.</p>
-<p>The <tt>ostream</tt> parameter specifies the stream to write the results on,
+<p>The <tt>llvm::OStream</tt> parameter specifies the stream to write the results on,
and the <tt>Module</tt> 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 <tt>Pass::dump()</tt> from a
declare as required in your <a
href="#getAnalysisUsage"><tt>getAnalysisUsage</tt></a> implementation. This
method can be called by your <tt>run*</tt> method implementation, or by any
-other local method invoked by your <tt>run*</tt> method.</p>
+other local method invoked by your <tt>run*</tt> method.
+
+A module level pass can use function level analysis info using this interface.
+For example:</p>
+
+<div class="doc_code"><pre>
+ bool ModuleLevelPass::runOnModule(Module &M) {
+ ...
+ DominatorTree &DT = getAnalysis<DominatorTree>(Func);
+ ...
+ }
+</pre></div>
+
+In above example, runOnFunction for DominatorTree is called by pass manager
+before returning a reference to the desired pass.</p>
<p>
If your pass is capable of updating analyses if they exist (e.g.,
want:</p>
<div class="doc_code"><pre>
-(gdb) <b>break PassManager::run</b>
+(gdb) <b>break llvm::PassManager::run</b>
Breakpoint 1 at 0x2413bc: file Pass.cpp, line 70.
(gdb) <b>run test.bc -load $(LLVMTOP)/llvm/Debug/lib/[libname].so -[passoption]</b>
Starting program: opt test.bc -load $(LLVMTOP)/llvm/Debug/lib/[libname].so -[passoption]
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.</p>
-</div>
-
-<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
-<a name="PassFunctionPass"><tt>ModulePass</tt>es requiring <tt>FunctionPass</tt>es</a>
-</div>
-
-<div class="doc_text">
-
-<p>Currently it is illegal for a <a href="#ModulePass"><tt>ModulePass</tt></a>
-to require a <a href="#FunctionPass"><tt>FunctionPass</tt></a>. This is because
-there is only one instance of the <a
-href="#FunctionPass"><tt>FunctionPass</tt></a> 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.</p>
-
-<p>Note that it is no problem for a <a
-href="#FunctionPass"><tt>FunctionPass</tt></a> to require the results of a <a
-href="#ModulePass"><tt>ModulePass</tt></a>, only the other way around.</p>
-
-</div>
-
<!-- *********************************************************************** -->
<hr>
<address>
projects / oota-llvm.git / blobdiff