Completing Passes.html with the exception of -emitbitcode, which should be

removed. This document could still stand for significant improvement:

  * Editing the pass descriptions; most were lifted with minimal editing from
    comments. Although implementation details were elided, many of the were not
    written for the audience that would be interested in this document.
  * More "before and after" examples.
  * More implicit dependency details. (Perhaps listing transforms in
    -std-compile-opts order would help alleviate this.)
  * Adding documentation for how to invoke passes programmatically.
  * Rearranging the document into a more logical taxonomy. For instance, putting
    profiling passes together.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@43677 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Gordon Henriksen 2007-11-04 18:10:18 +00:00
parent f4c164c2b5
commit 75ff18ed2b

View File

@ -1808,7 +1808,10 @@ if (i == j)
<a name="deadarghaX0r">Dead Argument Hacking (BUGPOINT USE ONLY; DO NOT USE)</a>
</div>
<div class="doc_text">
<p>Yet to be written.</p>
<p>
Same as dead argument elimination, but deletes arguments to functions which
are external. This is only for use by <a
href="Bugpoint.html">bugpoint</a>.</p>
</div>
<!-------------------------------------------------------------------------- -->
@ -1816,7 +1819,9 @@ if (i == j)
<a name="extract-blocks">Extract Basic Blocks From Module (for bugpoint use)</a>
</div>
<div class="doc_text">
<p>Yet to be written.</p>
<p>
This pass is used by bugpoint to extract all blocks from the module into their
own functions.</p>
</div>
<!-------------------------------------------------------------------------- -->
@ -1832,7 +1837,50 @@ if (i == j)
<a name="verify">Module Verifier</a>
</div>
<div class="doc_text">
<p>Yet to be written.</p>
<p>
Verifies an LLVM IR code. This is useful to run after an optimization which is
undergoing testing. Note that <tt>llvm-as</tt> verifies its input before
emitting bitcode, and also that malformed bitcode is likely to make LLVM
crash. All language front-ends are therefore encouraged to verify their output
before performing optimizing transformations.
</p>
<p>
<li>Both of a binary operator's parameters are of the same type.</li>
<li>Verify that the indices of mem access instructions match other
operands.</li>
<li>Verify that arithmetic and other things are only performed on
first-class types. Verify that shifts and logicals only happen on
integrals f.e.</li>
<li>All of the constants in a switch statement are of the correct type.</li>
<li>The code is in valid SSA form.</li>
<li>It should be illegal to put a label into any other type (like a
structure) or to return one. [except constant arrays!]</li>
<li>Only phi nodes can be self referential: 'add int %0, %0 ; <int>:0' is
bad.</li>
<li>PHI nodes must have an entry for each predecessor, with no extras.</li>
<li>PHI nodes must be the first thing in a basic block, all grouped
together.</li>
<li>PHI nodes must have at least one entry.</li>
<li>All basic blocks should only end with terminator insts, not contain
them.</li>
<li>The entry node to a function must not have predecessors.</li>
<li>All Instructions must be embedded into a basic block.</li>
<li>Functions cannot take a void-typed parameter.</li>
<li>Verify that a function's argument list agrees with its declared
type.</li>
<li>It is illegal to specify a name for a void value.</li>
<li>It is illegal to have a internal global value with no initializer.</li>
<li>It is illegal to have a ret instruction that returns a value that does
not agree with the function return value type.</li>
<li>Function call argument types match the function prototype.</li>
<li>All other things that are tested by asserts spread about the code.</li>
</p>
<p>
Note that this does not provide full security verification (like Java), but
instead just tries to ensure that code is well-formed.
</p>
</div>
<!-------------------------------------------------------------------------- -->
@ -1840,7 +1888,9 @@ if (i == j)
<a name="view-cfg">View CFG of function</a>
</div>
<div class="doc_text">
<p>Yet to be written.</p>
<p>
Displays the control flow graph using the GraphViz tool.
</p>
</div>
<!-------------------------------------------------------------------------- -->
@ -1848,7 +1898,10 @@ if (i == j)
<a name="view-cfg-only">View CFG of function (with no function bodies)</a>
</div>
<div class="doc_text">
<p>Yet to be written.</p>
<p>
Displays the control flow graph using the GraphViz tool, but omitting function
bodies.
</p>
</div>
<!-- *********************************************************************** -->