+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 gccas 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.
-bugpoint 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, bugpoint 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". +bugpoint reads the specified list of .bc or .ll 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, bugpoint enters crash debugging +mode.
+Otherwise, if the -output option was not +specified, bugpoint runs the initial program with the C backend (which +is assumed to generate good code) to generate a reference output. Once +bugpoint has a reference output to match, it tries executing the +original program with the selected code generator. If +the resultant output is different than the reference output, it exters code generator debugging mode.
+ +Otherwise, bugpoint 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 bugpoint can debug. Otherwise, it enters miscompilation debugging mode.
+
+
-[unfinished]
+Next, bugpoint 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,
+bugpoint deletes any individual LLVM instructions whose absense does
+not eliminate the failure. At the end, bugpoint should tell you what
+passes crash, give you a bytecode file, and give you instructions on how to
+reproduce the failure with opt or
+analyze.
-
-
@@ -80,12 +111,12 @@ TODO
opt -load <plugin.so> -help
-
- Crash debugging mode
-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,
-bugpoint pares down the list of passes to a minimum set.
+If an optimizer crashes, bugpoint will try a variety of techniques to
+narrow down the list of passes and the code to a more manageable amount. First,
+bugpoint figures out which combination of passes trigger the bug. This
+is useful when debugging a problem exposed by gccas for example,
+because it has over 30 optimization it runs.Miscompilation debugging mode
+
+Code generator debugging mode
TODO
-Code generator debugging mode
+
+Miscompilation debugging mode
TODO
@@ -65,7 +96,7 @@ TODO
Print a summary of command line options.
Specify the contents of <stdin> when the program must be executed.
Specify a reference output for the <stdout> file stream.
Specify which code generator bugpoint should use to run the
program.