diff options
author | Chris Lattner <sabre@nondot.org> | 2003-10-18 20:36:15 +0000 |
---|---|---|
committer | Chris Lattner <sabre@nondot.org> | 2003-10-18 20:36:15 +0000 |
commit | d1eb6f7984075b39b26a29b75769637a62d9a9e6 (patch) | |
tree | 5d763ff0e1f71d4d87dac51936ada1e7dabbc375 /docs/CommandGuide/bugpoint.html | |
parent | 367e1ee5bebc3542b55df61cd280bd6166057e51 (diff) |
Beef up the description of bugpoint a lot. Update for renamed options
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9239 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'docs/CommandGuide/bugpoint.html')
-rw-r--r-- | docs/CommandGuide/bugpoint.html | 73 |
1 files changed, 52 insertions, 21 deletions
diff --git a/docs/CommandGuide/bugpoint.html b/docs/CommandGuide/bugpoint.html index 1bdacc7dac..885a0e77bc 100644 --- a/docs/CommandGuide/bugpoint.html +++ b/docs/CommandGuide/bugpoint.html @@ -16,29 +16,60 @@ <h3>DESCRIPTION</h3> The <tt>bugpoint</tt> tool is a generally useful tool for narrowing down -problems in LLVM tools and passes.<p> - -<tt>bugpoint</tt> reads the specified list of .bc or .ll files specified on the -command-line and links them together. It then runs the specified LLVM passes on -the resultant bytecode file. If any of the passes crash, or if they produce an -LLVM module which is not verifiable, bugpoint enters "crash debugging mode". -Otherwise, <tt>bugpoint</tt> tries to run the resultant program with a code -generator. If the code generated program does not match the reference output, -it enters "miscompilation debugging mode". - +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 testcases to something useful. 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> + +<tt>bugpoint</tt> reads the specified list of <tt>.bc</tt> or <tt>.ll</tt> files +specified on the command-line and links them together. If any LLVM passes are +specified on the command line, it runs these passes on the resultant module. If +any of the passes crash, or if they produce an LLVM module which is not +verifiable, <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 +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 +original program with the <a href="#opt_run-">selected</a> code generator. If +the resultant output is different than the reference output, it exters <a +href="#codegendebug">code generator debugging mode</a>.<p> + +Otherwise, <tt>bugpoint</tt> runs the LLVM program after all of the LLVM passes +have been applied to it. If the executed program matches the reference output, +there is no problem <tt>bugpoint</tt> can debug. Otherwise, it enters <a +href="#miscompilationdebug">miscompilation debugging mode</a>.<p> + +<a name="crashdebug"> <h4>Crash debugging mode</h4> -If a pass crashes, bugpoint will try to narrow down the list of passes and the -code to a more manageable amount. Using a sophisticated binary-search algorithm, -<tt>bugpoint</tt> pares down the list of passes to a minimum set. - -[unfinished] - -<h4>Miscompilation debugging mode</h4> +If an optimizer crashes, <tt>bugpoint</tt> will try a variety of techniques to +narrow down the list of passes and the code to a more manageable amount. First, +<tt>bugpoint</tt> figures out which combination of passes trigger the bug. This +is useful when debugging a problem exposed by <tt>gccas</tt> for example, +because it has over 30 optimization it runs.<p> + +Next, <tt>bugpoint</tt> tries removing functions from the module, to reduce the +size of the testcase to a reasonable amount. Usually it is able to get it down +to a single function for 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 absense 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><a href="opt.html">opt</a></tt> or +<tt><a href="analyze.html">analyze</a></tt>.<p> + +<a name="codegendebug"> +<h4>Code generator debugging mode</h4> TODO -<h4>Code generator debugging mode</h4> +<a name="miscompilationdebug"> +<h4>Miscompilation debugging mode</h4> TODO @@ -65,7 +96,7 @@ TODO Print a summary of command line options. <p> - <li> <tt>-input <filename></tt> + <a name="opt_input"><li><tt>-input <filename></tt> <br> Specify the contents of <stdin> when the program must be executed. <p> @@ -80,12 +111,12 @@ TODO <tt>opt -load <plugin.so> -help</tt> <p> - <li> <tt>-output <filename></tt> + <a name="opt_output"><li><tt>-output <filename></tt> <br> Specify a reference output for the <stdout> file stream. <p> - <li> <tt>-run-(lli|jit|llc|cbe)</tt> + <a name="opt_run-"><li><tt>-run-(int|jit|llc|cbe)</tt> <br> Specify which code generator <tt>bugpoint</tt> should use to run the program. |