<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>
href="#FunctionPass"><tt>FunctionPass</tt></a>'s operate a function at a
time.</p>
+<div class="doc_code"><pre>
+ static char ID;
+ Hello() : FunctionPass((intptr_t)&ID) {}
+</pre></div><p>
+
+<p> This declares pass identifier used by LLVM to identify pass. This allows LLVM to
+avoid using expensive C++ runtime information.</p>
+
<div class="doc_code"><pre>
<b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
llvm::cerr << "<i>Hello: </i>" << F.getName() << "\n";
to do our thing, so we just print out our message with the name of each
function.</p>
+<div class="doc_code"><pre>
+ char Hello::ID = 0;
+</pre></div>
+
+<p> We initialize pass ID here. LLVM uses ID's address to identify pass so
+initialization value is not important.</p>
+
<div class="doc_code"><pre>
RegisterPass<Hello> X("<i>hello</i>", "<i>Hello World Pass</i>");
} <i>// end of anonymous namespace</i>
<b>namespace</b> {
<b>struct Hello</b> : <b>public</b> <a href="#FunctionPass">FunctionPass</a> {
+
+ static char ID;
+ Hello() : FunctionPass((intptr_t)&ID) {}
+
<b>virtual bool</b> <a href="#runOnFunction">runOnFunction</a>(Function &F) {
llvm::cerr << "<i>Hello: </i>" << F.getName() << "\n";
<b>return false</b>;
}
};
+ char Hello::ID = 0;
RegisterPass<Hello> X("<i>hello</i>", "<i>Hello World Pass</i>");
}
</pre></div>
<p>To test it, follow the example at the end of the <a
href="GettingStarted.html">Getting Started Guide</a> to compile "Hello World" to
-LLVM. We can now run the bytecode file (<tt>hello.bc</tt>) for the program
-through our transformation like this (or course, any bytecode file will
+LLVM. We can now run the bitcode file (<tt>hello.bc</tt>) for the program
+through our transformation like this (or course, any bitcode file will
work):</p>
<div class="doc_code"><pre>
$ opt -load ../../../Debug/lib/Hello.so --help
OVERVIEW: llvm .bc -> .bc modular optimizer
-USAGE: opt [options] <input bytecode>
+USAGE: opt [options] <input bitcode>
OPTIONS:
Optimizations available:
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.0100 (100.0%) 0.0000 ( 0.0%) 0.0100 ( 50.0%) 0.0402 ( 84.0%) Bitcode 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
<b> 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0033 ( 6.9%) Hello World Pass</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
<li>... <em>not allowed</em> to modify any <tt>Function</tt>s that are not in
the current SCC.</li>
-<li>... <em>allowed</em> to inspect any Function's other than those in the
+<li>... <em>not allowed</em> to inspect any Function's other than those in the
current SCC and the direct callees of the SCC.</li>
<li>... <em>required</em> to preserve the current CallGraph object, updating it
<b>virtual bool</b> doInitialization(Loop *, LPPassManager &LPM);
</pre></div>
-The <tt>doInitialization</tt> method is designed to do simple initialization
+<p>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
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>
+
+<p>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.,
<p>Here we show how the default implementation is specified (using the extra
argument to the <tt>RegisterAnalysisGroup</tt> template). There must be exactly
one default implementation available at all times for an Analysis Group to be
-used. Here we declare that the <tt><a
-href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a></tt>
+used. Only default implementation can derive from <tt>ImmutablePass</tt>.
+Here we declare that the
+ <tt><a href="http://llvm.org/doxygen/structBasicAliasAnalysis.html">BasicAliasAnalysis</a></tt>
pass is the default implementation for the interface.</p>
</div>
Module Verifier
-- Dominator Set Construction
-- Module Verifier
- Bytecode Writer
---Bytecode Writer
+ Bitcode Writer
+--Bitcode Writer
</pre></div>
<p>This output shows us when passes are constructed and when the analysis
Module Verifier
-- Dominator Set Construction
-- Module Verifier
- Bytecode Writer
---Bytecode Writer
+ Bitcode Writer
+--Bitcode Writer
Hello: __main
Hello: puts
Hello: main
Module Verifier
-- Dominator Set Construction
-- Module Verifier
- Bytecode Writer
---Bytecode Writer
+ Bitcode Writer
+--Bitcode Writer
Hello: __main
Hello: puts
Hello: main
</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>