mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2025-01-30 16:53:02 +00:00
Document the code generator debugger.
llvm-svn: 11616
This commit is contained in:
parent
d033fe4e8a
commit
95be0e7972
@ -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>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user