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

diff --git a/docs/Passes.html b/docs/Passes.html
index b8d5fa105234f0433cd0c7d3996d9427605d2cec..352263eca73aac14af5ab186c33d570da9577aee 100644 (file)
--- a/docs/Passes.html
+++ b/docs/Passes.html
@@ -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>
 
 <!-- *********************************************************************** -->