Continue refactoring inline asm code. If there is an earlyclobber output

[oota-llvm.git] / docs / WritingAnLLVMPass.html

diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html
index 3b116074b716bcb6792022300bb2f58c68d39819..8f2c7af1aa4e1186d0787122e884752d7d9f4e70 100644 (file)
--- a/docs/WritingAnLLVMPass.html
+++ b/docs/WritingAnLLVMPass.html
@@ -103,8 +103,6 @@
   <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>
 
@@ -466,7 +464,9 @@ class is the most general of all superclasses that you can use.  Deriving from
 <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
@@ -1127,7 +1127,21 @@ runtime assertion failure if you attempt to get an analysis that you did not
 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 &amp;M) {
+     ...
+     DominatorTree &amp;DT = getAnalysis&lt;DominatorTree&gt;(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.,
@@ -1764,31 +1778,6 @@ places (for global resources).  Although this is a simple extension, we simply
 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>