RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-12-15 07:39:31 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Try to clarify a point about getting DominatorTree info from a module pass.

Browse Source 
llvm-svn: 74668
This commit is contained in:
Daniel Dunbar 2009-07-01 23:38:44 +00:00
parent edbdfb50e3
commit a4af9cf40b
1 changed files with 9 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/WritingAnLLVMPass.html
View File

@ -491,10 +491,15 @@ 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. A module pass
can use function level passes (e.g. dominators) using getAnalysis interface
<tt> getAnalysis&lt;DominatorTree&gt;(Function)</tt>, if the function pass
does not require any module passes. </p>
subclasses, no optimization can be done for their execution.</p>
<p>A module pass can use function level passes (e.g. dominators) using
the getAnalysis interface
<tt>getAnalysis&lt;DominatorTree&gt;(llvm::Function *)</tt> to provide the
function to retrieve analysis result for, if the function pass does not require
any module passes. Note that this can only be done for functions for which the
analysis ran, e.g. in the case of dominators you should only ask for the
DominatorTree for function definitions, not declarations.</p>
<p>To write a correct <tt>ModulePass</tt> subclass, derive from
<tt>ModulePass</tt> and overload the <tt>runOnModule</tt> method with the