Document the code generator debugger.

llvm-svn: 11616
This commit is contained in:
Chris Lattner 2004-02-18 23:30:21 +00:00
parent d033fe4e8a
commit 95be0e7972

View File

@ -47,43 +47,43 @@ any of the passes crash, or if they produce malformed output,
<tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p> <tt>bugpoint</tt> starts the <a href="#crashdebug">crash debugger</a>.<p>
Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not Otherwise, if the <a href="#opt_output"><tt>-output</tt></a> option was not
specified, <tt>bugpoint</tt> runs the test program with the C backend (which specified, <tt>bugpoint</tt> runs the test program with the C backend (which is
is assumed to generate good code) to generate a reference output. Once assumed to generate good code) to generate a reference output. Once
<tt>bugpoint</tt> has a reference output for the test program, it tries <tt>bugpoint</tt> has a reference output for the test program, it tries
executing it executing it with the <a href="#opt_run-">selected</a> code generator. If the
with the <a href="#opt_run-">selected</a> code generator. If selected code generator crashes, <tt>bugpoint</tt> starts the <a
the resulting output differs from the reference output, it assumes the href="#crashdebug">crash debugger</a> on the code generator. Otherwise, if the
difference resulted from a code generator failure, and starts the resulting output differs from the reference output, it assumes the difference
<a href="#codegendebug">code generator debugger</a>.<p> resulted from a code generator failure, and starts the <a
href="#codegendebug">code generator debugger</a>.<p>
Otherwise, <tt>bugpoint</tt> runs the test program after all of the LLVM passes Finally, if the output of the selected code generator matches the reference
have been applied to it. If its output differs from the reference output, output, <tt>bugpoint</tt> runs the test program after all of the LLVM passes
it assumes the difference resulted from a failure in one of the LLVM passes, have been applied to it. If its output differs from the reference output, it
and enters the assumes the difference resulted from a failure in one of the LLVM passes, and
<a href="#miscompilationdebug">miscompilation debugger</a>. Otherwise, enters the <a href="#miscompilationdebug">miscompilation
there is no problem <tt>bugpoint</tt> can debug.<p> debugger</a>. Otherwise, there is no problem <tt>bugpoint</tt> can debug.<p>
<a name="crashdebug"> <a name="crashdebug">
<h4>Crash debugger</h4> <h4>Crash debugger</h4>
If an optimizer crashes, <tt>bugpoint</tt> will try as hard as it can to If an optimizer or code generator crashes, <tt>bugpoint</tt> will try as hard as
reduce the list of passes and the size of the test program. First, it can to reduce the list of passes (for optimizer crashes) and the size of the
<tt>bugpoint</tt> figures out which combination of passes triggers the bug. This test program. First, <tt>bugpoint</tt> figures out which combination of
is useful when debugging a problem exposed by <tt>gccas</tt>, for example, optimizer passes triggers the bug. This is useful when debugging a problem
because it runs over 25 optimizations.<p> exposed by <tt>gccas</tt>, for example, because it runs over 25
optimizations.<p>
Next, <tt>bugpoint</tt> tries removing functions from the test program, to Next, <tt>bugpoint</tt> tries removing functions from the test program, to
reduce its reduce its size. Usually it is able to reduce a test program to a single
size. Usually it is able to reduce a test program function, when debugging 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 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, 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 <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 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 passes crash, give you a bytecode file, and give you instructions on how to
reproduce the failure with <tt><a href="opt.html">opt</a></tt> or reproduce the failure with <tt><a href="opt.html">opt</a></tt>, <tt><a
<tt><a href="analyze.html">analyze</a></tt>.<p> href="analyze.html">analyze</a></tt>, or <tt><a href="llc.html">llc</a></tt>.<p>
<a name="codegendebug"> <a name="codegendebug">
<h4>Code generator debugger</h4> <h4>Code generator debugger</h4>