forked from OSchip/llvm-project
Remove/modify C backend references from LLVM documentation.
Patch by Wei-Ren Chen. llvm-svn: 158456
This commit is contained in:
parent
b64f23e674
commit
c198a68a14
|
@ -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>
|
||||
|
|
|
@ -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.</p>
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue