Minor edits to Description section.

Add Design Philosophy as a separate subsection.  Clarify its last sentence.
Give Automatic Mode Selection a uniquely-named anchor.
Always call the program the "test program", instead of the "initial program",
 the "LLVM program", the "test case", the "resultant module", etc.
Try to explain the assumptions a little more, instead of just describing the
 process.

llvm-svn: 9255

llvm/docs/CommandGuide/bugpoint.html

@@ -15,56 +15,67 @@
 <img src="../Debugging.gif" width=444 height=314 align=right>
 <h3>DESCRIPTION</h3>
 
-The <tt>bugpoint</tt> tool is a generally useful tool for narrowing down
+The <tt>bugpoint</tt> tool narrows down the source of
 problems in LLVM tools and passes.  It can be used to debug three types of
 failures: optimizer crashes, miscompilations by optimizers, or invalid native
-code generation.  It aims to reduce test cases to something useful.  For example,
+code generation.  It aims to reduce large test cases to small, useful ones. 
+For example,
 if <tt><a href="gccas.html">gccas</a></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>
 
+<a name="designphilosophy">
+<h4>Design Philosophy</h4>
+
 <tt>bugpoint</tt> has been designed to be a useful tool without requiring any
 hooks into the LLVM infrastructure at all.  It works with any and all LLVM
 passes and code generators, and does not need to "know" how they work.  Because
 of this, it may appear to do a lot of stupid things or miss obvious
-simplifications.  Remember, however, that computer time is much cheaper than
+simplifications.  <tt>bugpoint</tt> is also designed to trade off programmer
-programmer time, so if it takes a long time to reduce a test case it is still
+time for computer time in the compiler-debugging process; consequently, it may
-worth it.  :)<p>
+take a long period of (unattended) time to reduce a test case, but we feel it
+is still worth it. :-) <p>
 
-<a name="crashdebug">
+<a name="automaticmodeselection">
 <h4>Automatic Mode Selection</h4>
 
-<tt>bugpoint</tt> reads the specified list of <tt>.bc</tt> or <tt>.ll</tt> files
+<tt>bugpoint</tt> reads each <tt>.bc</tt> or <tt>.ll</tt> file
-specified on the command-line and links them together.  If any LLVM passes are
+specified on the command line and links them together into a single module,
-specified on the command line, it runs these passes on the resultant module.  If
+called the test program.  If any LLVM passes are
+specified on the command line, it runs these passes on the test program.  If
 any of the passes crash, or if they produce a malformed LLVM module,
 <tt>bugpoint</tt> enters <a href="#crashdebug">crash debugging mode</a>.<p>
 
 Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not
-specified, <tt>bugpoint</tt> runs the initial program with the C backend (which
+specified, <tt>bugpoint</tt> runs the test program with the C backend (which
 is assumed to generate good code) to generate a reference output.  Once
-<tt>bugpoint</tt> has a reference output to match, it tries executing the
+<tt>bugpoint</tt> has a reference output for the test program, it tries
-original program with the <a href="#opt_run-">selected</a> code generator.  If
+executing it
-the resultant output is different than the reference output, it enters <a
+with the <a href="#opt_run-">selected</a> code generator.  If
-href="#codegendebug">code generator debugging mode</a>.<p>
+the resulting output differs from the reference output, it assumes the
+difference resulted from a code generator failure, and enters
+<a href="#codegendebug">code generator debugging mode</a>.<p>
 
-Otherwise, <tt>bugpoint</tt> runs the LLVM program after all of the LLVM passes
+Otherwise, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
-have been applied to it.  If the executed program matches the reference output,
+have been applied to it.  If its output differs from the reference output,
-there is no problem <tt>bugpoint</tt> can debug.  Otherwise, it enters <a
+it assumes the difference resulted from a failure in one of the LLVM passes,
-href="#miscompilationdebug">miscompilation debugging mode</a>.<p>
+and enters
+<a href="#miscompilationdebug">miscompilation debugging mode</a>. Otherwise,
+there is no problem <tt>bugpoint</tt> can debug.<p>
 
 <a name="crashdebug">
 <h4>Crash debugging mode</h4>
 
-If an optimizer crashes, <tt>bugpoint</tt> will try a variety of techniques to
+If an optimizer crashes, <tt>bugpoint</tt> will try as hard as it can to
-narrow down the list of passes and the code to a more manageable amount.  First,
+reduce the list of passes and the size of the test program.  First,
-<tt>bugpoint</tt> figures out which combination of passes trigger the bug.  This
+<tt>bugpoint</tt> figures out which combination of passes triggers the bug. This
-is useful when debugging a problem exposed by <tt>gccas</tt> for example,
+is useful when debugging a problem exposed by <tt>gccas</tt>, for example,
 because it runs over 30 optimizations.<p>
 
 Next, <tt>bugpoint</tt> tries removing functions from the module, to reduce the
-size of the test case to a reasonable amount.  Usually it is able to get it down
+size of the test program.  Usually it is able to reduce a test program
-to a single function for intraprocedural optimizations.  Once the number of
+to a single function, when debugging intraprocedural optimizations.  Once the
+number of
 functions has been reduced, it attempts to delete various edges in the control
 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