From 693464c57ae2286dba93a0e74edc54a45222dcd7 Mon Sep 17 00:00:00 2001 From: Misha Brukman Date: Fri, 2 Jul 2004 15:48:33 +0000 Subject: [PATCH] The HTML documentation is now automatically generated from POD source. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@14578 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CommandGuide/analyze.html | 86 ----------- docs/CommandGuide/bugpoint.html | 249 ------------------------------- docs/CommandGuide/extract.html | 93 ------------ docs/CommandGuide/gccas.html | 84 ----------- docs/CommandGuide/gccld.html | 210 -------------------------- docs/CommandGuide/llc.html | 220 --------------------------- docs/CommandGuide/lli.html | 107 ------------- docs/CommandGuide/llvm-as.html | 97 ------------ docs/CommandGuide/llvm-db.html | 26 ---- docs/CommandGuide/llvm-dis.html | 94 ------------ docs/CommandGuide/llvm-link.html | 88 ----------- docs/CommandGuide/llvm-nm.html | 118 --------------- docs/CommandGuide/llvm-prof.html | 58 ------- docs/CommandGuide/llvmgcc.html | 113 -------------- docs/CommandGuide/llvmgxx.html | 107 ------------- docs/CommandGuide/opt.html | 109 -------------- 16 files changed, 1859 deletions(-) delete mode 100644 docs/CommandGuide/analyze.html delete mode 100644 docs/CommandGuide/bugpoint.html delete mode 100644 docs/CommandGuide/extract.html delete mode 100644 docs/CommandGuide/gccas.html delete mode 100644 docs/CommandGuide/gccld.html delete mode 100644 docs/CommandGuide/llc.html delete mode 100644 docs/CommandGuide/lli.html delete mode 100644 docs/CommandGuide/llvm-as.html delete mode 100644 docs/CommandGuide/llvm-db.html delete mode 100644 docs/CommandGuide/llvm-dis.html delete mode 100644 docs/CommandGuide/llvm-link.html delete mode 100644 docs/CommandGuide/llvm-nm.html delete mode 100644 docs/CommandGuide/llvm-prof.html delete mode 100644 docs/CommandGuide/llvmgcc.html delete mode 100644 docs/CommandGuide/llvmgxx.html delete mode 100644 docs/CommandGuide/opt.html diff --git a/docs/CommandGuide/analyze.html b/docs/CommandGuide/analyze.html deleted file mode 100644 index ff61808f2b2..00000000000 --- a/docs/CommandGuide/analyze.html +++ /dev/null @@ -1,86 +0,0 @@ - - -LLVM: analyze tool - - - - -

LLVM: analyze tool

-
- -

NAME

-analyze - -

SYNOPSIS

-analyze [options] [filename] - -

DESCRIPTION

- -The analyze command performs various analysis of LLVM assembly code or -bytecode. It will usually print the results on standard output, but in a few -cases, it will print output to standard error or generate a file with the -analysis output (which is usually done when the output is meant for another -program). -

-If filename is omitted or is -, analyze reads its input from standard -input. It first attempts to interpret its input as LLVM bytecode. If it -encounters an error, it then attempts to parse the input as LLVM assembly -language. - -

OPTIONS

- - - -

EXIT STATUS

- -If analyze succeeds, it will exit with 0. Otherwise, if an error -occurs, it will exit with a non-zero value. - -

SEE ALSO

- -opt - -
-Maintained by the LLVM Team. - - - diff --git a/docs/CommandGuide/bugpoint.html b/docs/CommandGuide/bugpoint.html deleted file mode 100644 index 519e02d5277..00000000000 --- a/docs/CommandGuide/bugpoint.html +++ /dev/null @@ -1,249 +0,0 @@ - -LLVM: bugpoint tool - - - -

LLVM: bugpoint tool

-
- -

NAME

-bugpoint - -

SYNOPSIS

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

DESCRIPTION

- -The bugpoint tool 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 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.

- - -

Design Philosophy

- -bugpoint is designed to be a useful tool without requiring any -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 stupid things or miss obvious -simplifications. bugpoint is also designed to trade off programmer -time for computer time in the compiler-debugging process; consequently, it may -take a long period of (unattended) time to reduce a test case, but we feel it -is still worth it. Note that bugpoint is generally very quick unless -debugging a miscompilation where each test of the program (which requires -executing it) takes a long time.

- - -

Automatic Debugger Selection

- -bugpoint reads each .bc or .ll file -specified on the command line and links them together into a single module, -called the test program. If any LLVM passes are -specified on the command line, it runs these passes on the test program. If -any of the passes crash, or if they produce malformed output (which causes the -verifier to abort), -bugpoint starts the crash debugger.

- -Otherwise, if the -output option was not -specified, bugpoint runs the test program with the C backend (which is -assumed to generate good code) to generate a reference output. Once -bugpoint has a reference output for the test program, it tries -executing it with the selected code generator. If the -selected code generator crashes, bugpoint starts the crash debugger on the code generator. Otherwise, if the -resulting output differs from the reference output, it assumes the difference -resulted from a code generator failure, and starts the code generator debugger.

- -Finally, if the output of the selected code generator matches the reference -output, bugpoint runs the test program after all of the LLVM passes -have been applied to it. If its output differs from the reference output, it -assumes the difference resulted from a failure in one of the LLVM passes, and -enters the miscompilation -debugger. Otherwise, there is no problem bugpoint can debug.

- - -

Crash debugger

- -If an optimizer or code generator crashes, bugpoint will try as hard as -it can to reduce the list of passes (for optimizer crashes) and the size of the -test program. First, bugpoint figures out which combination of -optimizer passes triggers the bug. This is useful when debugging a problem -exposed by gccas, for example, because it runs over 38 passes.

- -Next, bugpoint tries removing functions from the test program, to -reduce its size. Usually it is able to reduce a test program 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 -flow graph, to reduce the size of the function as much as possible. Finally, -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, analyze, or llc.

- - -

Code generator debugger

- -

The code generator debugger attempts to narrow down the amount of code that -is being miscompiled by the selected code generator. To -do this, it takes the test program and partitions it into two pieces: one piece -which it compiles with the C backend (into a shared object), and one piece which -it runs with either the JIT or the static LLC compiler. It uses several -techniques to reduce the amount of code pushed through the LLVM code generator, -to reduce the potential scope of the problem. After it is finished, it emits -two bytecode files (called "test" [to be compiled with the code generator] and -"safe" [to be compiled with the C backend], respectively), and instructions for -reproducing the problem. The code generator debugger assumes that the C backend -produces good code.

- - -

Miscompilation debugger

- -The miscompilation debugger works similarly to the code generator -debugger. It works by splitting the test program into two pieces, running the -optimizations specified on one piece, linking the two pieces back together, -and then executing the result. -It attempts to narrow down the list of passes to the one (or few) which are -causing the miscompilation, then reduce the portion of the test program which is -being miscompiled. The miscompilation debugger assumes that the selected -code generator is working properly.

- - -

Advice for using bugpoint

- -bugpoint can be a remarkably useful tool, but it sometimes works in -non-obvious ways. Here are some hints and tips:

- -

    -
  1. In the code generator and miscompilation debuggers, bugpoint only - works with programs that have deterministic output. Thus, if the program - outputs argv[0], 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 the code generator and miscompilation debuggers, debugging will go - faster if you manually modify the program or its inputs to reduce the - runtime, but still exhibit the problem. - -
  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 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, 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. - -
  5. bugpoint cannot debug problems with the LLVM linker. If - bugpoint crashes before you see its "All input ok" message, - you might try llvm-link -v on the same set of input files. If - that also crashes, you may be experiencing a linker bug. - -
  6. If your program is supposed to crash, bugpoint will be - confused. One way to deal with this is to cause bugpoint to ignore the exit - code from your program, by giving it the -check-exit-code=false - option. - -
- -

OPTIONS

- - - -

EXIT STATUS

- -If bugpoint succeeds in finding a problem, it will exit with 0. -Otherwise, if an error occurs, it will exit with a non-zero value. - -

SEE ALSO

-opt, -analyze - -
-Maintained by the LLVM Team. - - diff --git a/docs/CommandGuide/extract.html b/docs/CommandGuide/extract.html deleted file mode 100644 index 72112e8b2d1..00000000000 --- a/docs/CommandGuide/extract.html +++ /dev/null @@ -1,93 +0,0 @@ - - -LLVM: extract tool - - - - -
-

LLVM: extract tool

-
-
- -

NAME

-extract - -

-SYNOPSIS -

- -extract [options] [filename] -

-DESCRIPTION -

- -The extract command takes the name of a function and extracts it from -the specified LLVM bytecode file. It is primarily used as a debugging tool to -reduce test cases from larger programs that are triggering a bug. -

- -In addition to extracting the bytecode of the specified function, -extract will also remove unreachable global variables, prototypes, and -unused types. -

- -The extract command reads its input from standard input if filename is -omitted or if filename is -. The output is always written to standard output. - -

OPTIONS

- -