From b9b3c33177ca1849dc83213686f9e8bd758b05c1 Mon Sep 17 00:00:00 2001 From: Brian Gaeke Date: Sun, 19 Oct 2003 17:03:59 +0000 Subject: Spell-check. Many minor edits. Rewrite some of the options section for grammatical parallelism, clarity, and brevity. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9254 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CommandGuide/bugpoint.html | 86 ++++++++++++++++++++++------------------- 1 file changed, 47 insertions(+), 39 deletions(-) (limited to 'docs') diff --git a/docs/CommandGuide/bugpoint.html b/docs/CommandGuide/bugpoint.html index 04f45b5724..502bca5623 100644 --- a/docs/CommandGuide/bugpoint.html +++ b/docs/CommandGuide/bugpoint.html @@ -10,7 +10,7 @@ bugpoint

SYNOPSIS

-bugpoint [options] [input llvm ll/bc files] [LLVM passes] --args <program arguments>... +bugpoint [options] [input LLVM ll/bc files] [LLVM passes] --args <program arguments>...

DESCRIPTION

@@ -18,17 +18,17 @@ The bugpoint tool is a generally useful tool for narrowing down 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, +code generation. It aims to reduce test cases 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 has been designed to be a useful tool without requiring any -hooks into the LLVM intrastructure at all. It works with any and all LLVM +hooks into the LLVM infrastructure at all. It works with any and all LLVM passes and code generators, and does not need to "know" how they work. Because of this, it may appear to do a lot of stupid things or miss obvious simplifications. Remember, however, that computer time is much cheaper than -programmer time, so if it takes a long time to reduce a testcase it is still +programmer time, so if it takes a long time to reduce a test case it is still worth it. :)

@@ -45,7 +45,7 @@ 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 @@ -60,14 +60,14 @@ 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.

+because it runs over 30 optimizations.

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 +size of the test case 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 +bugpoint deletes any individual LLVM instructions whose absence 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 @@ -114,7 +114,10 @@ non-obvious ways. Here are some hints and tips:

  1. In code generator and miscompilation debugging modes, bugpoint only works with programs that have deterministic output. Thus, if the program - outputs the date, time, or any other "random" data, it should be masked out. + outputs the date, time, or any other "random" data, bugpoint may + misinterpret differences in these data, when output, as the result of a + miscompilation. Programs should be temporarily modified to disable + outputs that are likely to vary from run to run.
  2. In code generator and miscompilation debugging modes, debugging will go faster if you manually modify the program or its inputs to reduce the @@ -122,14 +125,16 @@ non-obvious ways. Here are some hints and tips:

  3. bugpoint is extremely useful when working on a new optimization: it helps track down regressions quickly. To avoid having to relink - bugpoint every time you change your optization however, have + bugpoint every time you change your optimization however, have bugpoint dynamically load your optimization with the -load option.
  4. bugpoint can generate a lot of output and run for a long period of time. It is often useful to capture the output of the program to file. For - example:
    - bugpoint ..... |& tee bugpoint.log

    + example, in the C shell, you can type:
    + bugpoint ..... |& tee bugpoint.log +
    to get a copy of bugpoint's output in the file + bugpoint.log, as well as on your terminal.

@@ -138,54 +143,58 @@ non-obvious ways. Here are some hints and tips:

EXIT STATUS

@@ -201,4 +210,3 @@ Otherwise, if an error occurs, it will exit with a non-zero value. Maintained by the LLVM Team. - -- cgit v1.2.3