diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html index 71f288d7720..31c35f0100b 100644 --- a/docs/Bugpoint.html +++ b/docs/Bugpoint.html @@ -85,7 +85,7 @@ 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 +bugpoint runs the test program with the "safe" 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, @@ -138,13 +138,13 @@ reproduce the failure with opt or llc.

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 +with the "safe" 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 bitcode 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 +compiled with the "safe" backend], respectively), and instructions for reproducing +the problem. The code generator debugger assumes that the "safe" backend produces good code.

diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 672dc294a75..651eb96603e 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -218,7 +218,8 @@ support completely non-traditional code generation targets. For example, the C backend does not require register allocation, instruction selection, or any of the other standard components provided by the system. As such, it only - implements these two interfaces, and does its own thing. Another example of + implements these two interfaces, and does its own thing. Note that C backend + was removed from the trunk since LLVM 3.1 release. Another example of a code generator like this is a (purely hypothetical) backend that converts LLVM to the GCC RTL form and uses GCC to emit machine code for a target.

diff --git a/docs/HowToSubmitABug.html b/docs/HowToSubmitABug.html index 0fa8329921d..39f83851293 100644 --- a/docs/HowToSubmitABug.html +++ b/docs/HowToSubmitABug.html @@ -223,12 +223,12 @@ we have chased down ended up being bugs in the program being compiled, not LLVM.

Once you determine that the program itself is not buggy, you should choose -which code generator you wish to compile the program with (e.g. C backend, the -JIT, or LLC) and optionally a series of LLVM passes to run. For example:

+which code generator you wish to compile the program with (e.g. LLC or the JIT) +and optionally a series of LLVM passes to run. For example:

-bugpoint -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]

+bugpoint -run-llc [... optzn passes ...] file-to-test.bc --args -- [program arguments]

bugpoint will try to narrow down your list of passes to the one pass