Remove/modify C backend references from LLVM documentation.
authorDavid Blaikie <dblaikie@gmail.com>
Thu, 14 Jun 2012 16:52:55 +0000 (16:52 +0000)
committerDavid Blaikie <dblaikie@gmail.com>
Thu, 14 Jun 2012 16:52:55 +0000 (16:52 +0000)
Patch by Wei-Ren Chen.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158456 91177308-0d34-0410-b5e6-96231b3b80d8

docs/Bugpoint.html
docs/CodeGenerator.html
docs/HowToSubmitABug.html

index 71f288d7720ef33ad5ff1c03dd10a64f1bee3ed2..31c35f0100bc2656db89a15417b922ac877f99cd 100644 (file)
@@ -85,7 +85,7 @@ malformed output (which causes the verifier to abort), <tt>bugpoint</tt> starts
 the <a href="#crashdebug">crash debugger</a>.</p>
 
 <p>Otherwise, if the <tt>-output</tt> option was not specified,
-<tt>bugpoint</tt> runs the test program with the C backend (which is assumed to
+<tt>bugpoint</tt> runs the test program with the "safe" backend (which is assumed to
 generate good code) to generate a reference output.  Once <tt>bugpoint</tt> 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 <tt>opt</tt> or <tt>llc</tt>.</p>
 <p>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.</p>
 
 </div>
index 672dc294a75f412c2298b51da6365ed99aabff3f..651eb96603ece223d94644c0f039dc9790976df9 100644 (file)
    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.</p>
 
index 0fa8329921d66938ccc8de1865e5e6f04a43115d..39f838512930efa4fac87aa7d3fb3decd6a31e8a 100644 (file)
@@ -223,12 +223,12 @@ we have chased down ended up being bugs in the program being compiled, not
  LLVM.</p>
 
 <p>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:</p>
+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:</p>
 
 <div class="doc_code">
 <p><tt>
-<b>bugpoint</b> -run-cbe [... optzn passes ...] file-to-test.bc --args -- [program arguments]</tt></p>
+<b>bugpoint</b> -run-llc [... optzn passes ...] file-to-test.bc --args -- [program arguments]</tt></p>
 </div>
 
 <p><tt>bugpoint</tt> will try to narrow down your list of passes to the one pass