6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-08-01 17:29:33 +00:00
Code Issues Projects Releases Wiki Activity

Remove/modify C backend references from LLVM documentation.

Browse Source 
Patch by Wei-Ren Chen.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158456 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
David Blaikie 2012-06-14 16:52:55 +00:00
parent deb878053a
commit 722f2544b2
3 changed files with 9 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/Bugpoint.html
View 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>

3
docs/CodeGenerator.html
View File

@ -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>

6
docs/HowToSubmitABug.html
View 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