Jeff's fix was fine

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

diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html
index e2a3611db27a3f85e730d7414bff1e9de062babd..43d237d094e3fe16bf6742cb5efcfb378959bf0b 100644 (file)
--- a/docs/Bugpoint.html
+++ b/docs/Bugpoint.html
@@ -38,13 +38,13 @@
 passes.  It can be used to debug three types of failures: optimizer crashes,
 miscompilations by optimizers, or bad native code generation (including problems
 in the static and JIT compilers).  It aims to reduce large test cases to small,
-useful ones.  For example, if <tt>gccas</tt> crashes while optimizing a
+useful ones.  For example, if <tt>opt</tt> crashes while optimizing a
 file, it will identify the optimization (or combination of optimizations) that
 causes the crash, and reduce the file down to a small example which triggers the
 crash.</p>
 
-<p>For detailed case scenarios, such as debugging <tt>gccas</tt>,
-<tt>gccld</tt>, or one of the LLVM code generators, see <a
+<p>For detailed case scenarios, such as debugging <tt>opt</tt>,
+<tt>llvm-ld</tt>, or one of the LLVM code generators, see <a
 href="HowToSubmitABug.html">How To Submit a Bug Report document</a>.</p>
 
 </div>
@@ -114,7 +114,7 @@ Otherwise, there is no problem <tt>bugpoint</tt> can debug.</p>
 as it can to reduce the list of passes (for optimizer crashes) and the size of
 the test program.  First, <tt>bugpoint</tt> figures out which combination of
 optimizer passes triggers the bug. This is useful when debugging a problem
-exposed by <tt>gccas</tt>, for example, because it runs over 38 passes.</p>
+exposed by <tt>opt</tt>, for example, because it runs over 38 passes.</p>
 
 <p>Next, <tt>bugpoint</tt> tries removing functions from the test program, to
 reduce its size.  Usually it is able to reduce a test program to a single
@@ -124,7 +124,7 @@ flow graph, to reduce the size of the function as much as possible.  Finally,
 <tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
 not eliminate the failure.  At the end, <tt>bugpoint</tt> should tell you what
 passes crash, give you a bytecode file, and give you instructions on how to
-reproduce the failure with <tt>opt</tt>, <tt>analyze</tt>, or <tt>llc</tt>.</p>
+reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
 
 </div>
 
@@ -215,6 +215,12 @@ non-obvious ways.  Here are some hints and tips:<p>
     confused. One way to deal with this is to cause bugpoint to ignore the exit
     code from your program, by giving it the <tt>-check-exit-code=false</tt>
     option.
+
+<li><tt>bugpoint</tt> is useful for proactively finding bugs in LLVM. 
+    Invoking <tt>bugpoint</tt> with the <tt>-find-bugs</tt> option will cause
+    the list of specified optimizations to be randomized and applied to the 
+    program. This process will repeat until a bug is found or the user
+    kills <tt>bugpoint</tt>.
     
 </ol>