mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-11-24 03:33:20 +01:00
187 lines
6.1 KiB
Plaintext
187 lines
6.1 KiB
Plaintext
=pod
|
|
|
|
=head1 NAME
|
|
|
|
bugpoint - automatic test case reduction tool
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
B<bugpoint> [I<options>] [I<input LLVM ll/bc files>] [I<LLVM passes>] B<--args>
|
|
I<program arguments>
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
B<bugpoint> 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 bad native code generation (including problems in the static
|
|
and JIT compilers). It aims to reduce large test cases to small, useful ones.
|
|
For more information on the design and inner workings of B<bugpoint>, as well as
|
|
advice for using bugpoint, see F<llvm/docs/Bugpoint.html> in the LLVM
|
|
distribution.
|
|
|
|
=head1 OPTIONS
|
|
|
|
=over
|
|
|
|
=item B<--additional-so> F<library>
|
|
|
|
Load the dynamic shared object F<library> into the test program whenever it is
|
|
run. This is useful if you are debugging programs which depend on non-LLVM
|
|
libraries (such as the X or curses libraries) to run.
|
|
|
|
=item B<--append-exit-code>=I<{true,false}>
|
|
|
|
Append the test programs exit code to the output file so that a change in exit
|
|
code is considered a test failure. Defaults to false.
|
|
|
|
=item B<--args> I<program args>
|
|
|
|
Pass all arguments specified after -args to the test program whenever it runs.
|
|
Note that if any of the I<program args> start with a '-', you should use:
|
|
|
|
bugpoint [bugpoint args] --args -- [program args]
|
|
|
|
The "--" right after the B<--args> option tells B<bugpoint> to consider any
|
|
options starting with C<-> to be part of the B<--args> option, not as options to
|
|
B<bugpoint> itself.
|
|
|
|
=item B<--tool-args> I<tool args>
|
|
|
|
Pass all arguments specified after --tool-args to the LLVM tool under test
|
|
(B<llc>, B<lli>, etc.) whenever it runs. You should use this option in the
|
|
following way:
|
|
|
|
bugpoint [bugpoint args] --tool-args -- [tool args]
|
|
|
|
The "--" right after the B<--tool-args> option tells B<bugpoint> to consider any
|
|
options starting with C<-> to be part of the B<--tool-args> option, not as
|
|
options to B<bugpoint> itself. (See B<--args>, above.)
|
|
|
|
=item B<--safe-tool-args> I<tool args>
|
|
|
|
Pass all arguments specified after B<--safe-tool-args> to the "safe" execution
|
|
tool.
|
|
|
|
=item B<--gcc-tool-args> I<gcc tool args>
|
|
|
|
Pass all arguments specified after B<--gcc-tool-args> to the invocation of
|
|
B<gcc>.
|
|
|
|
=item B<--opt-args> I<opt args>
|
|
|
|
Pass all arguments specified after B<--opt-args> to the invocation of B<opt>.
|
|
|
|
=item B<--disable-{dce,simplifycfg}>
|
|
|
|
Do not run the specified passes to clean up and reduce the size of the test
|
|
program. By default, B<bugpoint> uses these passes internally when attempting to
|
|
reduce test programs. If you're trying to find a bug in one of these passes,
|
|
B<bugpoint> may crash.
|
|
|
|
=item B<--enable-valgrind>
|
|
|
|
Use valgrind to find faults in the optimization phase. This will allow
|
|
bugpoint to find otherwise asymptomatic problems caused by memory
|
|
mis-management.
|
|
|
|
=item B<-find-bugs>
|
|
|
|
Continually randomize the specified passes and run them on the test program
|
|
until a bug is found or the user kills B<bugpoint>.
|
|
|
|
=item B<-help>
|
|
|
|
Print a summary of command line options.
|
|
|
|
=item B<--input> F<filename>
|
|
|
|
Open F<filename> and redirect the standard input of the test program, whenever
|
|
it runs, to come from that file.
|
|
|
|
=item B<--load> F<plugin>
|
|
|
|
Load the dynamic object F<plugin> into B<bugpoint> itself. This object should
|
|
register new optimization passes. Once loaded, the object will add new command
|
|
line options to enable various optimizations. To see the new complete list of
|
|
optimizations, use the B<-help> and B<--load> options together; for example:
|
|
|
|
bugpoint --load myNewPass.so -help
|
|
|
|
=item B<--mlimit> F<megabytes>
|
|
|
|
Specifies an upper limit on memory usage of the optimization and codegen. Set
|
|
to zero to disable the limit.
|
|
|
|
=item B<--output> F<filename>
|
|
|
|
Whenever the test program produces output on its standard output stream, it
|
|
should match the contents of F<filename> (the "reference output"). If you
|
|
do not use this option, B<bugpoint> will attempt to generate a reference output
|
|
by compiling the program with the "safe" backend and running it.
|
|
|
|
=item B<--profile-info-file> F<filename>
|
|
|
|
Profile file loaded by B<--profile-loader>.
|
|
|
|
=item B<--run-{int,jit,llc,cbe,custom}>
|
|
|
|
Whenever the test program is compiled, B<bugpoint> should generate code for it
|
|
using the specified code generator. These options allow you to choose the
|
|
interpreter, the JIT compiler, the static native code compiler, the C
|
|
backend, or a custom command (see B<--exec-command>) respectively.
|
|
|
|
=item B<--safe-{llc,cbe,custom}>
|
|
|
|
When debugging a code generator, B<bugpoint> should use the specified code
|
|
generator as the "safe" code generator. This is a known-good code generator
|
|
used to generate the "reference output" if it has not been provided, and to
|
|
compile portions of the program that as they are excluded from the testcase.
|
|
These options allow you to choose the
|
|
static native code compiler, the C backend, or a custom command,
|
|
(see B<--exec-command>) respectively. The interpreter and the JIT backends
|
|
cannot currently be used as the "safe" backends.
|
|
|
|
=item B<--exec-command> I<command>
|
|
|
|
This option defines the command to use with the B<--run-custom> and
|
|
B<--safe-custom> options to execute the bitcode testcase. This can
|
|
be useful for cross-compilation.
|
|
|
|
=item B<--compile-command> I<command>
|
|
|
|
This option defines the command to use with the B<--compile-custom>
|
|
option to compile the bitcode testcase. This can be useful for
|
|
testing compiler output without running any link or execute stages. To
|
|
generate a reduced unit test, you may add CHECK directives to the
|
|
testcase and pass the name of an executable compile-command script in this form:
|
|
|
|
#!/bin/sh
|
|
llc "$@"
|
|
not FileCheck [bugpoint input file].ll < bugpoint-test-program.s
|
|
|
|
This script will "fail" as long as FileCheck passes. So the result
|
|
will be the minimum bitcode that passes FileCheck.
|
|
|
|
=item B<--safe-path> I<path>
|
|
|
|
This option defines the path to the command to execute with the
|
|
B<--safe-{int,jit,llc,cbe,custom}>
|
|
option.
|
|
|
|
=back
|
|
|
|
=head1 EXIT STATUS
|
|
|
|
If B<bugpoint> succeeds in finding a problem, it will exit with 0. Otherwise,
|
|
if an error occurs, it will exit with a non-zero value.
|
|
|
|
=head1 SEE ALSO
|
|
|
|
L<opt|opt>
|
|
|
|
=head1 AUTHOR
|
|
|
|
Maintained by the LLVM Team (L<http://llvm.org/>).
|
|
|
|
=cut
|