forked from OSchip/llvm-project
first pass of nomenclature changes in .html files
llvm-svn: 37956
This commit is contained in:
Gabor Greif
parent
12358b4827
commit
a54634adef
|
|
@ -123,7 +123,7 @@ 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,
|
||||
<tt>bugpoint</tt> deletes any individual LLVM instructions whose absence does
|
||||
not eliminate the failure. At the end, <tt>bugpoint</tt> should tell you what
|
||||
passes crash, give you a bytecode file, and give you instructions on how to
|
||||
passes crash, give you a bitcode file, and give you instructions on how to
|
||||
reproduce the failure with <tt>opt</tt> or <tt>llc</tt>.</p>
|
||||
|
||||
</div>
|
||||
|
|
@ -141,7 +141,7 @@ 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
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1357,7 +1357,7 @@ if that register is being used by the instruction. The method
|
|||
<tt>MachineOperand::isDef()</tt> informs if that registers is being
|
||||
defined.</p>
|
||||
|
||||
<p>We will call physical registers present in the LLVM bytecode before
|
||||
<p>We will call physical registers present in the LLVM bitcode before
|
||||
register allocation <i>pre-colored registers</i>. Pre-colored
|
||||
registers are used in many different situations, for instance, to pass
|
||||
parameters of functions calls, and to store results of particular
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@
|
|||
</ul></td>
|
||||
<td class="td_left"><ul>
|
||||
<li>LLVM Assembly</li>
|
||||
<li>LLVM Bytecode</li>
|
||||
<li>LLVM Bitcode</li>
|
||||
<li>LLVM C++ IR</li>
|
||||
</ul></td>
|
||||
<td class="td_left"><dl>
|
||||
|
|
@ -215,10 +215,10 @@
|
|||
<td><b>Optimization</b></td>
|
||||
<td class="td_left"><ul>
|
||||
<li>LLVM Assembly</li>
|
||||
<li>LLVM Bytecode</li>
|
||||
<li>LLVM Bitcode</li>
|
||||
</ul></td>
|
||||
<td class="td_left"><ul>
|
||||
<li>LLVM Bytecode</li>
|
||||
<li>LLVM Bitcode</li>
|
||||
</ul></td>
|
||||
<td class="td_left"><dl>
|
||||
<dt><tt>-Ox</tt>
|
||||
|
|
@ -229,13 +229,13 @@
|
|||
<tr>
|
||||
<td><b>Linking</b></td>
|
||||
<td class="td_left"><ul>
|
||||
<li>LLVM Bytecode</li>
|
||||
<li>LLVM Bitcode</li>
|
||||
<li>Native Object Code</li>
|
||||
<li>LLVM Library</li>
|
||||
<li>Native Library</li>
|
||||
</ul></td>
|
||||
<td class="td_left"><ul>
|
||||
<li>LLVM Bytecode Executable</li>
|
||||
<li>LLVM Bitcode Executable</li>
|
||||
<li>Native Executable</li>
|
||||
</ul></td>
|
||||
<td class="td_left"><dl>
|
||||
|
|
@ -291,7 +291,7 @@ should be invoked. Users may but are not advised to alter the compiler's
|
|||
available command line options for those programs regardless of whether they
|
||||
were written for LLVM or not. Furthermore, not all compiler tools will
|
||||
have the same capabilities. Some compiler tools will simply generate LLVM assembly
|
||||
code, others will be able to generate fully optimized byte code. In general,
|
||||
code, others will be able to generate fully optimized bitcode. In general,
|
||||
<tt>llvmc</tt> doesn't make any assumptions about the capabilities or command
|
||||
line options of a sub-tool. It simply uses the details found in the
|
||||
configuration files and leaves it to the compiler writer to specify the
|
||||
|
|
@ -299,9 +299,9 @@ configuration correctly.</p>
|
|||
|
||||
<p>This approach means that new compiler tools can be up and working very
|
||||
quickly. As a first cut, a tool can simply compile its source to raw
|
||||
(unoptimized) bytecode or LLVM assembly and <tt>llvmc</tt> can be configured
|
||||
to pick up the slack (translate LLVM assembly to bytecode, optimize the
|
||||
bytecode, generate native assembly, link, etc.). In fact, the compiler tools
|
||||
(unoptimized) bitcode or LLVM assembly and <tt>llvmc</tt> can be configured
|
||||
to pick up the slack (translate LLVM assembly to bitcode, optimize the
|
||||
bitcode, generate native assembly, link, etc.). In fact, the compiler tools
|
||||
need not use any LLVM libraries, and it could be written in any language
|
||||
(instead of C++). The configuration data will allow the full range of
|
||||
optimization, assembly, and linking capabilities that LLVM provides to be added
|
||||
|
|
@ -309,7 +309,7 @@ to these kinds of tools. Enabling the rapid development of front-ends is one
|
|||
of the primary goals of <tt>llvmc</tt>.</p>
|
||||
|
||||
<p>As a compiler tool matures, it may utilize the LLVM libraries and tools
|
||||
to more efficiently produce optimized bytecode directly in a single compilation
|
||||
to more efficiently produce optimized bitcode directly in a single compilation
|
||||
and optimization program. In these cases, multiple tools would not be needed
|
||||
and the configuration data for the compiler would change.</p>
|
||||
|
||||
|
|
@ -532,10 +532,10 @@ optimization.</p>
|
|||
</tr>
|
||||
<tr>
|
||||
<td><b>translator.output</b></td>
|
||||
<td><tt>bytecode</tt> or <tt>assembly</tt></td>
|
||||
<td><tt>bitcode</tt> or <tt>assembly</tt></td>
|
||||
<td class="td_left">This item specifies the kind of output the language's
|
||||
translator generates.</td>
|
||||
<td><tt>bytecode</tt></td>
|
||||
<td><tt>bitcode</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>translator.preprocesses</b></td>
|
||||
|
|
@ -556,10 +556,10 @@ optimization.</p>
|
|||
</tr>
|
||||
<tr>
|
||||
<td><b>optimizer.output</b></td>
|
||||
<td><tt>bytecode</tt> or <tt>assembly</tt></td>
|
||||
<td><tt>bitcode</tt> or <tt>assembly</tt></td>
|
||||
<td class="td_left">This item specifies the kind of output the language's
|
||||
optimizer generates. Valid values are "assembly" and "bytecode"</td>
|
||||
<td><tt>bytecode</tt></td>
|
||||
optimizer generates. Valid values are "assembly" and "bitcode"</td>
|
||||
<td><tt>bitcode</tt></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>optimizer.preprocesses</b></td>
|
||||
|
|
@ -724,7 +724,7 @@ optimization.</p>
|
|||
translator.required=true
|
||||
|
||||
# stkrc doesn't handle the -On options
|
||||
translator.output=bytecode
|
||||
translator.output=bitcode
|
||||
|
||||
##########################################################
|
||||
# Optimizer definitions
|
||||
|
|
@ -742,7 +742,7 @@ optimization.</p>
|
|||
# opt doesn't preprocess
|
||||
optimizer.preprocesses=no
|
||||
|
||||
# opt produces bytecode
|
||||
# opt produces bitcode
|
||||
optimizer.output = bc
|
||||
|
||||
##########################################################
|
||||
|
|
@ -761,7 +761,7 @@ optimization.</p>
|
|||
defined below.</p>
|
||||
<dl>
|
||||
<dt><a name="def_assembly"><b>assembly</b></a></dt>
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode or
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which LLVM bitcode or
|
||||
LLVM assembly code is assembled to a native code format (either target
|
||||
specific aseembly language or the platform's native object file format).
|
||||
</dd>
|
||||
|
|
@ -774,12 +774,12 @@ optimization.</p>
|
|||
<dd>Refers to <tt>llvmc</tt> itself.</dd>
|
||||
|
||||
<dt><a name="def_linking"><b>linking</b></a></dt>
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode files
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which LLVM bitcode files
|
||||
and (optionally) native system libraries are combined to form a complete
|
||||
executable program.</dd>
|
||||
|
||||
<dt><a name="def_optimization"><b>optimization</b></a></dt>
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which LLVM bytecode is
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which LLVM bitcode is
|
||||
optimized.</dd>
|
||||
|
||||
<dt><a name="def_phase"><b>phase</b></a></dt>
|
||||
|
|
@ -804,7 +804,7 @@ optimization.</p>
|
|||
<dt><a name="def_translation"><b>translation</b></a></dt>
|
||||
<dd>A compilation <a href="#def_phase">phase</a> in which
|
||||
<a href="#def_sourcelanguage">source language</a> code is translated into
|
||||
either LLVM assembly language or LLVM bytecode.</dd>
|
||||
either LLVM assembly language or LLVM bitcode.</dd>
|
||||
</dl>
|
||||
</div>
|
||||
<!-- *********************************************************************** -->
|
||||
|
|
|
|||
|
|
@ -228,7 +228,7 @@ complicated behavior in a single node (rotate).</p>
|
|||
|
||||
<div class="doc_text">
|
||||
|
||||
<p><span class="doc_warning">WARNING: adding instructions changes the bytecode
|
||||
<p><span class="doc_warning">WARNING: adding instructions changes the bitcode
|
||||
format, and it will take some effort to maintain compatibility with
|
||||
the previous version.</span> Only add an instruction if it is absolutely
|
||||
necessary.</p>
|
||||
|
|
@ -251,8 +251,8 @@ necessary.</p>
|
|||
add the grammar on how your instruction can be read and what it will
|
||||
construct as a result</li>
|
||||
|
||||
<li><tt>llvm/lib/Bytecode/Reader/Reader.cpp</tt>:
|
||||
add a case for your instruction and how it will be parsed from bytecode</li>
|
||||
<li><tt>llvm/lib/Bitcode/Reader/Reader.cpp</tt>:
|
||||
add a case for your instruction and how it will be parsed from bitcode</li>
|
||||
|
||||
<li><tt>llvm/lib/VMCore/Instruction.cpp</tt>:
|
||||
add a case for how your instruction will be printed out to assembly</li>
|
||||
|
|
@ -285,7 +285,7 @@ to understand this new instruction.</p>
|
|||
|
||||
<div class="doc_text">
|
||||
|
||||
<p><span class="doc_warning">WARNING: adding new types changes the bytecode
|
||||
<p><span class="doc_warning">WARNING: adding new types changes the bitcode
|
||||
format, and will break compatibility with currently-existing LLVM
|
||||
installations.</span> Only add new types if it is absolutely necessary.</p>
|
||||
|
||||
|
|
@ -348,12 +348,12 @@ bool TypesEqual(const Type *Ty, const Type *Ty2,
|
|||
<li><tt>llvm/lib/AsmReader/Lexer.l</tt>:
|
||||
add ability to parse in the type from text assembly</li>
|
||||
|
||||
<li><tt>llvm/lib/ByteCode/Writer/Writer.cpp</tt>:
|
||||
modify <tt>void BytecodeWriter::outputType(const Type *T)</tt> to serialize
|
||||
<li><tt>llvm/lib/BitCode/Writer/Writer.cpp</tt>:
|
||||
modify <tt>void BitcodeWriter::outputType(const Type *T)</tt> to serialize
|
||||
your type</li>
|
||||
|
||||
<li><tt>llvm/lib/ByteCode/Reader/Reader.cpp</tt>:
|
||||
modify <tt>const Type *BytecodeReader::ParseType()</tt> to read your data
|
||||
<li><tt>llvm/lib/BitCode/Reader/Reader.cpp</tt>:
|
||||
modify <tt>const Type *BitcodeReader::ParseType()</tt> to read your data
|
||||
type</li>
|
||||
|
||||
<li><tt>llvm/lib/VMCore/AsmWriter.cpp</tt>:
|
||||
|
|
|
|||
|
|
@ -584,7 +584,7 @@ relatively slow.
|
|||
<p>Also note: this specific sequence of commands won't work if you use a
|
||||
function defined in the C++ runtime library (or any other C++ library). To
|
||||
access an external C++ library, you must manually
|
||||
compile libstdc++ to LLVM bytecode, statically link it into your program, then
|
||||
compile libstdc++ to LLVM bitcode, statically link it into your program, then
|
||||
use the commands above to convert the whole result into C code. Alternatively,
|
||||
you can compile the libraries and your application into two different chunks
|
||||
of C code and link them.</p>
|
||||
|
|
|
|||
|
|
@ -82,14 +82,14 @@ basic information.</p>
|
|||
|
||||
<p>First, LLVM comes in two pieces. The first piece is the LLVM suite. This
|
||||
contains all of the tools, libraries, and header files needed to use the low
|
||||
level virtual machine. It contains an assembler, disassembler, bytecode
|
||||
analyzer and bytecode optimizer. It also contains a test suite that can be
|
||||
level virtual machine. It contains an assembler, disassembler, bitcode
|
||||
analyzer and bitcode optimizer. It also contains a test suite that can be
|
||||
used to test the LLVM tools and the GCC front end.</p>
|
||||
|
||||
<p>The second piece is the GCC front end. This component provides a version of
|
||||
GCC that compiles C and C++ code into LLVM bytecode. Currently, the GCC front
|
||||
GCC that compiles C and C++ code into LLVM bitcode. Currently, the GCC front
|
||||
end uses the GCC parser to convert code to LLVM. Once
|
||||
compiled into LLVM bytecode, a program can be manipulated with the LLVM tools
|
||||
compiled into LLVM bitcode, a program can be manipulated with the LLVM tools
|
||||
from the LLVM suite.</p>
|
||||
|
||||
<p>
|
||||
|
|
@ -332,7 +332,7 @@ build requires considerably less space.</p>
|
|||
|
||||
<p>The LLVM suite <i>may</i> compile on other platforms, but it is not
|
||||
guaranteed to do so. If compilation is successful, the LLVM utilities should be
|
||||
able to assemble, disassemble, analyze, and optimize LLVM bytecode. Code
|
||||
able to assemble, disassemble, analyze, and optimize LLVM bitcode. Code
|
||||
generation should work as well, although the generated native code may not work
|
||||
on your platform.</p>
|
||||
|
||||
|
|
@ -629,11 +629,11 @@ In order to compile and use LLVM, you may need to set some environment
|
|||
variables.
|
||||
|
||||
<dl>
|
||||
<dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt>/path/to/your/bytecode/libs</tt></dt>
|
||||
<dt><tt>LLVM_LIB_SEARCH_PATH</tt>=<tt>/path/to/your/bitcode/libs</tt></dt>
|
||||
<dd>[Optional] This environment variable helps LLVM linking tools find the
|
||||
locations of your bytecode libraries. It is provided only as a
|
||||
locations of your bitcode libraries. It is provided only as a
|
||||
convenience since you can specify the paths using the -L options of the
|
||||
tools and the C/C++ front-end will automatically use the bytecode files
|
||||
tools and the C/C++ front-end will automatically use the bitcode files
|
||||
installed in its
|
||||
<tt>lib</tt> directory.</dd>
|
||||
</dl>
|
||||
|
|
@ -974,8 +974,8 @@ source code:</p>
|
|||
<dt><tt>gmake -C runtime install-bytecode</tt>
|
||||
<dd>
|
||||
Assuming you built LLVM into $OBJDIR, when this command is run, it will
|
||||
install bytecode libraries into the GCC front end's bytecode library
|
||||
directory. If you need to update your bytecode libraries,
|
||||
install bitcode libraries into the GCC front end's bitcode library
|
||||
directory. If you need to update your bitcode libraries,
|
||||
this is the target to use once you've built them.
|
||||
<br><br>
|
||||
</dl>
|
||||
|
|
@ -1138,7 +1138,7 @@ If you're running on a Linux system that supports the "<a
|
|||
href="http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html">
|
||||
binfmt_misc</a>"
|
||||
module, and you have root access on the system, you can set your system up to
|
||||
execute LLVM bytecode files directly. To do this, use commands like this (the
|
||||
execute LLVM bitcode files directly. To do this, use commands like this (the
|
||||
first command may not be required if you are already using the module):</p>
|
||||
|
||||
<div class="doc_code">
|
||||
|
|
@ -1151,7 +1151,7 @@ first command may not be required if you are already using the module):</p>
|
|||
</div>
|
||||
|
||||
<p>
|
||||
This allows you to execute LLVM bytecode files directly. Thanks to Jack
|
||||
This allows you to execute LLVM bitcode files directly. Thanks to Jack
|
||||
Cummings for pointing this out!
|
||||
</p>
|
||||
|
||||
|
|
@ -1225,8 +1225,8 @@ different <a href="#tools">tools</a>.</p>
|
|||
<dd>This directory holds the source code for the LLVM assembly language parser
|
||||
library.</dd>
|
||||
|
||||
<dt><tt><b>llvm/lib/ByteCode/</b></tt></dt>
|
||||
<dd>This directory holds code for reading and write LLVM bytecode.</dd>
|
||||
<dt><tt><b>llvm/lib/BitCode/</b></tt></dt>
|
||||
<dd>This directory holds code for reading and write LLVM bitcode.</dd>
|
||||
|
||||
<dt><tt><b>llvm/lib/Analysis/</b></tt><dd>This directory contains a variety of
|
||||
different program analyses, such as Dominator Information, Call Graphs,
|
||||
|
|
@ -1255,7 +1255,7 @@ different <a href="#tools">tools</a>.</p>
|
|||
source code locations at which the program is executing.</dd>
|
||||
|
||||
<dt><tt><b>llvm/lib/ExecutionEngine/</b></tt></dt>
|
||||
<dd> This directory contains libraries for executing LLVM bytecode directly
|
||||
<dd> This directory contains libraries for executing LLVM bitcode directly
|
||||
at runtime in both interpreted and JIT compiled fashions.</dd>
|
||||
|
||||
<dt><tt><b>llvm/lib/Support/</b></tt></dt>
|
||||
|
|
@ -1283,7 +1283,7 @@ different <a href="#tools">tools</a>.</p>
|
|||
<div class="doc_subsection"><a name="runtime"><tt>llvm/runtime</tt></a></div>
|
||||
<div class="doc_text">
|
||||
|
||||
<p>This directory contains libraries which are compiled into LLVM bytecode and
|
||||
<p>This directory contains libraries which are compiled into LLVM bitcode and
|
||||
used when linking programs with the GCC front end. Most of these libraries are
|
||||
skeleton versions of real libraries; for example, libc is a stripped down
|
||||
version of glibc.</p>
|
||||
|
|
@ -1342,22 +1342,22 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
|
|||
be configured to utilize both LLVM and non-LLVM compilation tools to enable
|
||||
pre-processing, translation, optimization, assembly, and linking of programs
|
||||
all from one command line. <tt>llvmc</tt> also takes care of processing the
|
||||
dependent libraries found in bytecode. This reduces the need to get the
|
||||
dependent libraries found in bitcode. This reduces the need to get the
|
||||
traditional <tt>-l<name></tt> options right on the command line. Please
|
||||
note that this tool, while functional, is still experimental and not feature
|
||||
complete.</dd>
|
||||
|
||||
<dt><tt><b>llvm-ar</b></tt></dt>
|
||||
<dd>The archiver produces an archive containing
|
||||
the given LLVM bytecode files, optionally with an index for faster
|
||||
the given LLVM bitcode files, optionally with an index for faster
|
||||
lookup.</dd>
|
||||
|
||||
<dt><tt><b>llvm-as</b></tt></dt>
|
||||
<dd>The assembler transforms the human readable LLVM assembly to LLVM
|
||||
bytecode.</dd>
|
||||
bitcode.</dd>
|
||||
|
||||
<dt><tt><b>llvm-dis</b></tt></dt>
|
||||
<dd>The disassembler transforms the LLVM bytecode to human readable
|
||||
<dd>The disassembler transforms the LLVM bitcode to human readable
|
||||
LLVM assembly.</dd>
|
||||
|
||||
<dt><tt><b>llvm-ld</b></tt></dt>
|
||||
|
|
@ -1372,7 +1372,7 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
|
|||
|
||||
<dt><tt><b>lli</b></tt></dt>
|
||||
<dd><tt>lli</tt> is the LLVM interpreter, which
|
||||
can directly execute LLVM bytecode (although very slowly...). In addition
|
||||
can directly execute LLVM bitcode (although very slowly...). In addition
|
||||
to a simple interpreter, <tt>lli</tt> also has a tracing mode (entered by
|
||||
specifying <tt>-trace</tt> on the command line). Finally, for
|
||||
architectures that support it (currently x86, Sparc, and PowerPC), by default,
|
||||
|
|
@ -1382,25 +1382,25 @@ information is in the <a href="CommandGuide/index.html">Command Guide</a>.</p>
|
|||
|
||||
<dt><tt><b>llc</b></tt></dt>
|
||||
<dd> <tt>llc</tt> is the LLVM backend compiler, which
|
||||
translates LLVM bytecode to a native code assembly file or to C code (with
|
||||
translates LLVM bitcode to a native code assembly file or to C code (with
|
||||
the -march=c option).</dd>
|
||||
|
||||
<dt><tt><b>llvm-gcc</b></tt></dt>
|
||||
<dd><tt>llvm-gcc</tt> is a GCC-based C frontend that has been retargeted to
|
||||
use LLVM as its backend instead of GCC's RTL backend. It can also emit LLVM
|
||||
byte code or assembly (with the <tt>-emit-llvm</tt> option) instead of the
|
||||
bitcode or assembly (with the <tt>-emit-llvm</tt> option) instead of the
|
||||
usual machine code output. It works just like any other GCC compiler,
|
||||
taking the typical <tt>-c, -S, -E, -o</tt> options that are typically used.
|
||||
Additionally, the the source code for <tt>llvm-gcc</tt> is available as a
|
||||
separate Subversion module.</dd>
|
||||
|
||||
<dt><tt><b>opt</b></tt></dt>
|
||||
<dd><tt>opt</tt> reads LLVM bytecode, applies a series of LLVM to LLVM
|
||||
<dd><tt>opt</tt> reads LLVM bitcode, applies a series of LLVM to LLVM
|
||||
transformations (which are specified on the command line), and then outputs
|
||||
the resultant bytecode. The '<tt>opt --help</tt>' command is a good way to
|
||||
the resultant bitcode. The '<tt>opt --help</tt>' command is a good way to
|
||||
get a list of the program transformations available in LLVM.<br/>
|
||||
<dd><tt>opt</tt> can also be used to run a specific analysis on an input
|
||||
LLVM bytecode file and print out the results. It is primarily useful for
|
||||
LLVM bitcode file and print out the results. It is primarily useful for
|
||||
debugging analyses, or familiarizing yourself with what an analysis does.</dd>
|
||||
</dl>
|
||||
</div>
|
||||
|
|
@ -1490,9 +1490,9 @@ so we only include instructiosn for llvm-gcc4.
|
|||
|
||||
<p><b>Note:</b> The <i>gcc4</i> frontend's invocation is <b><i>considerably different</i></b>
|
||||
from the previous <i>gcc3</i> frontend. In particular, the <i>gcc4</i> frontend <b><i>does not</i></b>
|
||||
create bytecode by default: <i>gcc4</i> produces native code. As the example below illustrates,
|
||||
the '--emit-llvm' flag is needed to produce LLVM bytecode output. For <i>makefiles</i> and
|
||||
<i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bytecode
|
||||
create bitcode by default: <i>gcc4</i> produces native code. As the example below illustrates,
|
||||
the '--emit-llvm' flag is needed to produce LLVM bitcode output. For <i>makefiles</i> and
|
||||
<i>configure</i> scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode
|
||||
output.</p>
|
||||
</div>
|
||||
|
||||
|
|
@ -1519,13 +1519,13 @@ output.</p>
|
|||
-c arguments work as usual (producing a native .s or .o file,
|
||||
respectively). </p>
|
||||
|
||||
<li><p>Next, compile the C file into a LLVM bytecode file:</p>
|
||||
<li><p>Next, compile the C file into a LLVM bitcode file:</p>
|
||||
<p><tt>% llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc</tt></p>
|
||||
|
||||
<p>The -emit-llvm option can be used with the -S or -c options to emit an
|
||||
LLVM ".ll" or ".bc" file (respectively) for the code. This allows you
|
||||
to use the <a href="CommandGuide/index.html">standard LLVM tools</a> on
|
||||
the bytecode file.</p>
|
||||
the bitcode file.</p>
|
||||
|
||||
<p>Unlike llvm-gcc3, llvm-gcc4 correctly responds to -O[0123] arguments.
|
||||
</p></li>
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@
|
|||
<p>To emphasize, there is no C/C++ front end currently available.
|
||||
<tt>llvm-gcc</tt> is based on GCC, which cannot be bootstrapped using VC++.
|
||||
Eventually there should be a <tt>llvm-gcc</tt> based on Cygwin or MinGW that
|
||||
is usable. There is also the option of generating bytecode files on Unix and
|
||||
is usable. There is also the option of generating bitcode files on Unix and
|
||||
copying them over to Windows. But be aware the odds of linking C++ code
|
||||
compiled with <tt>llvm-gcc</tt> with code compiled with VC++ is essentially
|
||||
zero.</p>
|
||||
|
|
@ -257,11 +257,11 @@ All these paths are absolute:</p>
|
|||
}
|
||||
</pre></li>
|
||||
|
||||
<li><p>Next, compile the C file into a LLVM bytecode file:</p>
|
||||
<li><p>Next, compile the C file into a LLVM bitcode file:</p>
|
||||
<p><tt>% llvm-gcc -c hello.c -emit-llvm -o hello.bc</tt></p>
|
||||
|
||||
<p>This will create the result file <tt>hello.bc</tt> which is the LLVM
|
||||
bytecode that corresponds the the compiled program and the library
|
||||
bitcode that corresponds the the compiled program and the library
|
||||
facilities that it required. You can execute this file directly using
|
||||
<tt>lli</tt> tool, compile it to native assembly with the <tt>llc</tt>,
|
||||
optimize or analyze it further with the <tt>opt</tt> tool, etc.</p>
|
||||
|
|
|
|||
|
|
@ -242,7 +242,7 @@ JIT, or LLC) and optionally a series of LLVM passes to run. For example:</p>
|
|||
</div>
|
||||
|
||||
<p><tt>bugpoint</tt> will try to narrow down your list of passes to the one pass
|
||||
that causes an error, and simplify the bytecode file as much as it can to assist
|
||||
that causes an error, and simplify the bitcode file as much as it can to assist
|
||||
you. It will print a message letting you know how to reproduce the resulting
|
||||
error.</p>
|
||||
|
||||
|
|
@ -268,7 +268,7 @@ Backend, and then link in the shared object it generates.</p>
|
|||
|
||||
<div class="doc_code">
|
||||
<pre>
|
||||
bugpoint -run-jit -output=[correct output file] [bytecode file] \
|
||||
bugpoint -run-jit -output=[correct output file] [bitcode file] \
|
||||
--tool-args -- [arguments to pass to lli] \
|
||||
--args -- [program arguments]
|
||||
</pre>
|
||||
|
|
@ -278,7 +278,7 @@ bugpoint -run-jit -output=[correct output file] [bytecode file] \
|
|||
|
||||
<div class="doc_code">
|
||||
<pre>
|
||||
bugpoint -run-llc -output=[correct output file] [bytecode file] \
|
||||
bugpoint -run-llc -output=[correct output file] [bitcode file] \
|
||||
--tool-args -- [arguments to pass to llc] \
|
||||
--args -- [program arguments]
|
||||
</pre>
|
||||
|
|
@ -297,7 +297,7 @@ make bugpoint-jit
|
|||
</div>
|
||||
|
||||
<p>At the end of a successful <tt>bugpoint</tt> run, you will be presented
|
||||
with two bytecode files: a <em>safe</em> file which can be compiled with the C
|
||||
with two bitcode files: a <em>safe</em> file which can be compiled with the C
|
||||
backend and the <em>test</em> file which either LLC or the JIT
|
||||
mis-codegenerates, and thus causes the error.</p>
|
||||
|
||||
|
|
@ -306,7 +306,7 @@ the following:</p>
|
|||
|
||||
<ol>
|
||||
|
||||
<li><p>Regenerate the shared object from the safe bytecode file:</p>
|
||||
<li><p>Regenerate the shared object from the safe bitcode file:</p>
|
||||
|
||||
<div class="doc_code">
|
||||
<p><tt>
|
||||
|
|
@ -315,7 +315,7 @@ the following:</p>
|
|||
</tt></p>
|
||||
</div></li>
|
||||
|
||||
<li><p>If debugging LLC, compile test bytecode native and link with the shared
|
||||
<li><p>If debugging LLC, compile test bitcode native and link with the shared
|
||||
object:</p>
|
||||
|
||||
<div class="doc_code">
|
||||
|
|
@ -327,7 +327,7 @@ the following:</p>
|
|||
</div></li>
|
||||
|
||||
<li><p>If debugging the JIT, load the shared object and supply the test
|
||||
bytecode:</p>
|
||||
bitcode:</p>
|
||||
|
||||
<div class="doc_code">
|
||||
<p><tt><b>lli</b> -load=safe.so test.bc [program options]</tt></p>
|
||||
|
|
|
|||
|
|
@ -226,7 +226,7 @@ strategy.</p>
|
|||
<div class="doc_text">
|
||||
|
||||
<p>The LLVM code representation is designed to be used in three
|
||||
different forms: as an in-memory compiler IR, as an on-disk bytecode
|
||||
different forms: as an in-memory compiler IR, as an on-disk bitcode
|
||||
representation (suitable for fast loading by a Just-In-Time compiler),
|
||||
and as a human readable assembly language representation. This allows
|
||||
LLVM to provide a powerful intermediate representation for efficient
|
||||
|
|
@ -268,7 +268,7 @@ following instruction is syntactically okay, but not well formed:</p>
|
|||
its uses. The LLVM infrastructure provides a verification pass that may
|
||||
be used to verify that an LLVM module is well formed. This pass is
|
||||
automatically run by the parser after parsing input assembly and by
|
||||
the optimizer before it outputs bytecode. The violations pointed out
|
||||
the optimizer before it outputs bitcode. The violations pointed out
|
||||
by the verifier pass indicate bugs in transformation passes or input to
|
||||
the parser.</p>
|
||||
</div>
|
||||
|
|
@ -3690,7 +3690,7 @@ argument.</p>
|
|||
well known names and semantics and are required to follow certain restrictions.
|
||||
Overall, these intrinsics represent an extension mechanism for the LLVM
|
||||
language that does not require changing all of the transformations in LLVM when
|
||||
adding to the language (or the bytecode reader/writer, the parser, etc...).</p>
|
||||
adding to the language (or the bitcode reader/writer, the parser, etc...).</p>
|
||||
|
||||
<p>Intrinsic function names must all start with an "<tt>llvm.</tt>" prefix. This
|
||||
prefix is reserved in LLVM for intrinsic names; thus, function names may not
|
||||
|
|
|
|||
|
|
@ -67,9 +67,9 @@ intermodular optimization, in the compiler tool chain. Its main goal is to let
|
|||
the developer take advantage of intermodular optimizations without making any
|
||||
significant changes to the developer's makefiles or build system. This is
|
||||
achieved through tight integration with the linker. In this model, the linker
|
||||
treates LLVM bytecode files like native object files and allows mixing and
|
||||
treates LLVM bitcode files like native object files and allows mixing and
|
||||
matching among them. The linker uses <a href="#lto">LLVMlto</a>, a dynamically
|
||||
loaded library, to handle LLVM bytecode files. This tight integration between
|
||||
loaded library, to handle LLVM bitcode files. This tight integration between
|
||||
the linker and LLVM optimizer helps to do optimizations that are not possible
|
||||
in other models. The linker input allows the optimizer to avoid relying on
|
||||
conservative escape analysis.
|
||||
|
|
@ -87,7 +87,7 @@ conservative escape analysis.
|
|||
supports LTO through the interface described in this document. Here,
|
||||
llvm-gcc4 transparently invokes system linker. </p>
|
||||
<ul>
|
||||
<li> Input source file <tt>a.c</tt> is compiled into LLVM byte code form.
|
||||
<li> Input source file <tt>a.c</tt> is compiled into LLVM bitcode form.
|
||||
<li> Input source file <tt>main.c</tt> is compiled into native object code.
|
||||
</ul>
|
||||
<div class="doc_code"><pre>
|
||||
|
|
@ -131,12 +131,12 @@ int main() {
|
|||
}
|
||||
|
||||
--- command lines ---
|
||||
$ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bytecode file
|
||||
$ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bitcode file
|
||||
$ llvm-gcc4 -c main.c -o main.o # <-- main.o is native object file
|
||||
$ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifications
|
||||
</pre></div>
|
||||
<p>In this example, the linker recognizes that <tt>foo2()</tt> is an
|
||||
externally visible symbol defined in LLVM byte code file. This information
|
||||
externally visible symbol defined in LLVM bitcode file. This information
|
||||
is collected using <a href="#readllvmobjectfile"> readLLVMObjectFile()</a>.
|
||||
Based on this information, the linker completes its usual symbol resolution
|
||||
pass and finds that <tt>foo2()</tt> is not used anywhere. This information
|
||||
|
|
@ -202,15 +202,15 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsection">
|
||||
<a name="phase1">Phase 1 : Read LLVM Bytecode Files</a>
|
||||
<a name="phase1">Phase 1 : Read LLVM Bitcode Files</a>
|
||||
</div>
|
||||
|
||||
<div class="doc_text">
|
||||
<p>The linker first reads all object files in natural order and collects
|
||||
symbol information. This includes native object files as well as LLVM byte
|
||||
code files. In this phase, the linker uses
|
||||
symbol information. This includes native object files as well as LLVM bitcode
|
||||
files. In this phase, the linker uses
|
||||
<a href="#readllvmobjectfile"> readLLVMObjectFile() </a> to collect symbol
|
||||
information from each LLVM bytecode files and updates its internal global
|
||||
information from each LLVM bitcode files and updates its internal global
|
||||
symbol table accordingly. The intent of this interface is to avoid overhead
|
||||
in the non LLVM case, where all input object files are native object files,
|
||||
by putting this code in the error path of the linker. When the linker sees
|
||||
|
|
@ -228,7 +228,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
<p>In this stage, the linker resolves symbols using global symbol table
|
||||
information to report undefined symbol errors, read archive members, resolve
|
||||
weak symbols, etc. The linker is able to do this seamlessly even though it
|
||||
does not know the exact content of input LLVM bytecode files because it uses
|
||||
does not know the exact content of input LLVM bitcode files because it uses
|
||||
symbol information provided by
|
||||
<a href="#readllvmobjectfile">readLLVMObjectFile()</a>. If dead code
|
||||
stripping is enabled then the linker collects the list of live symbols.
|
||||
|
|
@ -237,12 +237,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsection">
|
||||
<a name="phase3">Phase 3 : Optimize Bytecode Files</a>
|
||||
<a name="phase3">Phase 3 : Optimize Bitcode Files</a>
|
||||
</div>
|
||||
<div class="doc_text">
|
||||
<p>After symbol resolution, the linker updates symbol information supplied
|
||||
by LLVM bytecode files appropriately. For example, whether certain LLVM
|
||||
bytecode supplied symbols are used or not. In the example above, the linker
|
||||
by LLVM bitcode files appropriately. For example, whether certain LLVM
|
||||
bitcode supplied symbols are used or not. In the example above, the linker
|
||||
reports that <tt>foo2()</tt> is not used anywhere in the program, including
|
||||
native <tt>.o</tt> files. This information is used by the LLVM interprocedural
|
||||
optimizer. The linker uses <a href="#optimizemodules">optimizeModules()</a>
|
||||
|
|
@ -260,12 +260,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
<p>In this phase, the linker reads optimized a native object file and
|
||||
updates the internal global symbol table to reflect any changes. The linker
|
||||
also collects information about any changes in use of external symbols by
|
||||
LLVM bytecode files. In the examle above, the linker notes that
|
||||
LLVM bitcode files. In the examle above, the linker notes that
|
||||
<tt>foo4()</tt> is not used any more. If dead code stripping is enabled then
|
||||
the linker refreshes the live symbol information appropriately and performs
|
||||
dead code stripping.</p>
|
||||
<p>After this phase, the linker continues linking as if it never saw LLVM
|
||||
bytecode files.</p>
|
||||
bitcode files.</p>
|
||||
</div>
|
||||
|
||||
<!-- *********************************************************************** -->
|
||||
|
|
@ -288,10 +288,10 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
|
||||
<div class="doc_text">
|
||||
<p>The <tt>LLVMSymbol</tt> class is used to describe the externally visible
|
||||
functions and global variables, defined in LLVM bytecode files, to the linker.
|
||||
functions and global variables, defined in LLVM bitcode files, to the linker.
|
||||
This includes symbol visibility information. This information is used by
|
||||
the linker to do symbol resolution. For example: function <tt>foo2()</tt> is
|
||||
defined inside an LLVM bytecode module and it is an externally visible symbol.
|
||||
defined inside an LLVM bitcode module and it is an externally visible symbol.
|
||||
This helps the linker connect the use of <tt>foo2()</tt> in native object
|
||||
files with a future definition of the symbol <tt>foo2()</tt>. The linker
|
||||
will see the actual definition of <tt>foo2()</tt> when it receives the
|
||||
|
|
@ -310,12 +310,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
|
||||
<div class="doc_text">
|
||||
<p>The <tt>readLLVMObjectFile()</tt> function is used by the linker to read
|
||||
LLVM bytecode files and collect LLVMSymbol information. This routine also
|
||||
supplies a list of externally defined symbols that are used by LLVM bytecode
|
||||
LLVM bitcode files and collect LLVMSymbol information. This routine also
|
||||
supplies a list of externally defined symbols that are used by LLVM bitcode
|
||||
files. The linker uses this symbol information to do symbol resolution.
|
||||
Internally, <a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in
|
||||
Internally, <a href="#lto">LLVMlto</a> maintains LLVM bitcode modules in
|
||||
memory. This function also provides a list of external references used by
|
||||
bytecode files.</p>
|
||||
bitcode files.</p>
|
||||
</div>
|
||||
|
||||
<!-- ======================================================================= -->
|
||||
|
|
@ -325,7 +325,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
|
||||
<div class="doc_text">
|
||||
<p>The linker invokes <tt>optimizeModules</tt> to optimize already read
|
||||
LLVM bytecode files by applying LLVM intermodular optimization techniques.
|
||||
LLVM bitcode files by applying LLVM intermodular optimization techniques.
|
||||
This function runs the LLVM intermodular optimizer and generates native
|
||||
object code as <tt>.o</tt> files at the name and location provided by the
|
||||
linker.</p>
|
||||
|
|
@ -338,7 +338,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
|
||||
<div class="doc_text">
|
||||
<p>The linker may use <tt>getTargetTriple()</tt> to query target architecture
|
||||
while validating LLVM bytecode file.</p>
|
||||
while validating LLVM bitcode file.</p>
|
||||
</div>
|
||||
|
||||
<!-- ======================================================================= -->
|
||||
|
|
@ -347,7 +347,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
|
|||
</div>
|
||||
|
||||
<div class="doc_text">
|
||||
<p>Internally, <a href="#lto">LLVMlto</a> maintains LLVM bytecode modules in
|
||||
<p>Internally, <a href="#lto">LLVMlto</a> maintains LLVM bitcode modules in
|
||||
memory. The linker may use <tt>removeModule()</tt> method to remove desired
|
||||
modules from memory. </p>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@
|
|||
<ol>
|
||||
<li><a href="#libraries">Libraries</a>
|
||||
<ol>
|
||||
<li><a href="#BCModules">Bytecode Modules</a></li>
|
||||
<li><a href="#BCModules">Bitcode Modules</a></li>
|
||||
<li><a href="#LoadableModules">Loadable Modules</a></li>
|
||||
</ol>
|
||||
</li>
|
||||
|
|
@ -260,11 +260,11 @@
|
|||
</div>
|
||||
|
||||
<!-- ======================================================================= -->
|
||||
<div class="doc_subsubsection"><a name="BCModules">Bytecode Modules</a></div>
|
||||
<div class="doc_subsubsection"><a name="BCModules">Bitcode Modules</a></div>
|
||||
<div class="doc_text">
|
||||
<p>In some situations, it is desireable to build a single bytecode module from
|
||||
a variety of sources, instead of an archive, shared library, or bytecode
|
||||
library. Bytecode modules can be specified in addition to any of the other
|
||||
<p>In some situations, it is desireable to build a single bitcode module from
|
||||
a variety of sources, instead of an archive, shared library, or bitcode
|
||||
library. Bitcode modules can be specified in addition to any of the other
|
||||
types of libraries by defining the <a href="#MODULE_NAME">MODULE_NAME</a>
|
||||
variable. For example:</p>
|
||||
<pre><tt>
|
||||
|
|
@ -273,9 +273,9 @@
|
|||
MODULE_NAME = mymod
|
||||
</tt></pre>
|
||||
<p>will build a module named <tt>mymod.bc</tt> from the sources in the
|
||||
directory. This module will be an aggregation of all the bytecode modules
|
||||
derived from the sources. The example will also build a bytecode archive
|
||||
containing a bytecode module for each compiled source file. The difference is
|
||||
directory. This module will be an aggregation of all the bitcode modules
|
||||
derived from the sources. The example will also build a bitcode archive
|
||||
containing a bitcode module for each compiled source file. The difference is
|
||||
subtle, but important depending on how the module or library is to be linked.
|
||||
</p>
|
||||
</div>
|
||||
|
|
@ -626,7 +626,7 @@
|
|||
files. These sources will be built before any other target processing to
|
||||
ensure they are present.</dd>
|
||||
<dt><a name="BYTECODE_LIBRARY"><tt>BYTECODE_LIBRARY</tt></a></dt>
|
||||
<dd>If set to any value, causes a bytecode library (.bc) to be built.</dd>
|
||||
<dd>If set to any value, causes a bitcode library (.bc) to be built.</dd>
|
||||
<dt><a name="CONFIG_FILES"><tt>CONFIG_FILES</tt></a></dt>
|
||||
<dd>Specifies a set of configuration files to be installed.</dd>
|
||||
<dt><a name="DIRS"><tt>DIRS</tt></a></dt>
|
||||
|
|
@ -709,9 +709,9 @@
|
|||
setting this variable without also setting <tt>SHARED_LIBRARY</tt> will have
|
||||
no effect.</dd>
|
||||
<dt><a name="MODULE_NAME"><tt>MODULE_NAME</tt></a></dt>
|
||||
<dd>Specifies the name of a bytecode module to be created. A bytecode
|
||||
<dd>Specifies the name of a bitcode module to be created. A bitcode
|
||||
module can be specified in conjunction with other kinds of library builds
|
||||
or by itself. It constructs from the sources a single linked bytecode
|
||||
or by itself. It constructs from the sources a single linked bitcode
|
||||
file.</dd>
|
||||
<dt><a name="NO_INSTALL"><tt>NO_INSTALL</tt></a></dt>
|
||||
<dd>Specifies that the build products of the directory should not be
|
||||
|
|
@ -835,7 +835,7 @@
|
|||
<dt><a name="LLVMGXX"><tt>LLVMGXX</tt></a><small>(defaulted)</small></dt>
|
||||
<dd>Specifies the path to the LLVM version of the GCC C++ Compiler</dd>
|
||||
<dt><a name="LLVMLD"><tt>LLVMLD</tt></a><small>(defaulted)</small></dt>
|
||||
<dd>Specifies the path to the LLVM bytecode linker tool</dd>
|
||||
<dd>Specifies the path to the LLVM bitcode linker tool</dd>
|
||||
<dt><a name="LLVM_OBJ_ROOT"><tt>LLVM_OBJ_ROOT</tt></a><small>(configured)
|
||||
</small></dt>
|
||||
<dd>Specifies the top directory into which the output of the build is
|
||||
|
|
@ -884,8 +884,8 @@
|
|||
<dt><a name="BuildMode"><tt>BuildMode</tt></a></dt>
|
||||
<dd>The name of the type of build being performed: Debug, Release, or
|
||||
Profile</dd>
|
||||
<dt><a name="bytecode_libdir"><tt>bytecode_libdir</tt></a></dt>
|
||||
<dd>The directory into which bytecode libraries will ultimately be
|
||||
<dt><a name="bitcode_libdir"><tt>bytecode_libdir</tt></a></dt>
|
||||
<dd>The directory into which bitcode libraries will ultimately be
|
||||
installed. This value is derived from the <tt>--prefix</tt> option given to
|
||||
<tt>configure</tt>.</dd>
|
||||
<dt><a name="ConfigureScriptFLAGS"><tt>ConfigureScriptFLAGS</tt></a></dt>
|
||||
|
|
@ -965,7 +965,7 @@
|
|||
CXX.Flags
|
||||
DependFiles
|
||||
DestArchiveLib
|
||||
DestBytecodeLib
|
||||
DestBitcodeLib
|
||||
DestModule
|
||||
DestRelinkedLib
|
||||
DestSharedLib
|
||||
|
|
|
|||
|
|
@ -31,8 +31,8 @@
|
|||
or program visualization purposes. Transform passes can use (or invalidate)
|
||||
the analysis passes. Transform passes all mutate the program in some way.
|
||||
Utility passes provides ome utility but don't otherwise fit categorization.
|
||||
For example passes to extract functions to bytecode or write a module to
|
||||
bytecode are neither analysis nor transform passes.
|
||||
For example passes to extract functions to bitcode or write a module to
|
||||
bitcode are neither analysis nor transform passes.
|
||||
<p>The table below provides a quick summary of each pass and links to the more
|
||||
complete pass description later in the document.</p>
|
||||
</div>
|
||||
|
|
@ -143,7 +143,7 @@
|
|||
<tr><th>Option</th><th>Name</th><th>Directory</th></tr>
|
||||
<tr><td><a href="#deadarghaX0r">-deadarghaX0r</a></td><td>Dead Argument Hacking (BUGPOINT ONLY)</td></tr>
|
||||
<tr><td><a href="#extract-blocks">-extract-blocks</a></td><td>Extract Basic Blocks From Module (BUGPOINT ONLY)</td></tr>
|
||||
<tr><td><a href="#emitbytecode">-emitbytecode</a></td><td>Bytecode Writer</td></tr>
|
||||
<tr><td><a href="#emitbitcode">-emitbitcode</a></td><td>Bitcode Writer</td></tr>
|
||||
<tr><td><a href="#verify">-verify</a></td><td>Module Verifier</td></tr>
|
||||
</table>
|
||||
</div>
|
||||
|
|
@ -994,7 +994,7 @@
|
|||
|
||||
<!-------------------------------------------------------------------------- -->
|
||||
<div class="doc_subsection">
|
||||
<a name="emitbytecode">Bytecode Writer</a>
|
||||
<a name="emitbitcode">Bitcode Writer</a>
|
||||
</div>
|
||||
<div class="doc_text">
|
||||
<p>Yet to be written.</p>
|
||||
|
|
|
|||
|
|
@ -581,9 +581,9 @@ suite, it gives a report that looks like this:</p>
|
|||
|
||||
<div class="doc_code">
|
||||
<pre>
|
||||
7646 bytecodewriter - Number of normal instructions
|
||||
725 bytecodewriter - Number of oversized instructions
|
||||
129996 bytecodewriter - Number of bytecode bytes written
|
||||
7646 bitcodewriter - Number of normal instructions
|
||||
725 bitcodewriter - Number of oversized instructions
|
||||
129996 bitcodewriter - Number of bitcode bytes written
|
||||
2817 raise - Number of insts DCEd or constprop'd
|
||||
3213 raise - Number of cast-of-self removed
|
||||
5046 raise - Number of expression trees converted
|
||||
|
|
@ -1935,7 +1935,7 @@ recursive types and late resolution of opaque types makes the situation very
|
|||
difficult to handle. Fortunately, for the most part, our implementation makes
|
||||
most clients able to be completely unaware of the nasty internal details. The
|
||||
primary case where clients are exposed to the inner workings of it are when
|
||||
building a recursive type. In addition to this case, the LLVM bytecode reader,
|
||||
building a recursive type. In addition to this case, the LLVM bitcode reader,
|
||||
assembly parser, and linker also have to be aware of the inner workings of this
|
||||
system.
|
||||
</p>
|
||||
|
|
|
|||
|
|
@ -224,10 +224,10 @@ subtrees of the test suite directory tree are as follows:</p>
|
|||
<li><tt>Analysis</tt>: checks Analysis passes.</li>
|
||||
<li><tt>Archive</tt>: checks the Archive library.</li>
|
||||
<li><tt>Assembler</tt>: checks Assembly reader/writer functionality.</li>
|
||||
<li><tt>Bytecode</tt>: checks Bytecode reader/writer functionality.</li>
|
||||
<li><tt>Bitcode</tt>: checks Bitcode reader/writer functionality.</li>
|
||||
<li><tt>CodeGen</tt>: checks code generation and each target.</li>
|
||||
<li><tt>Features</tt>: checks various features of the LLVM language.</li>
|
||||
<li><tt>Linker</tt>: tests bytecode linking.</li>
|
||||
<li><tt>Linker</tt>: tests bitcode linking.</li>
|
||||
<li><tt>Transforms</tt>: tests each of the scalar, IPO, and utility
|
||||
transforms to ensure they make the right transformations.</li>
|
||||
<li><tt>Verifier</tt>: tests the IR verifier.</li>
|
||||
|
|
|
|||
|
|
@ -81,15 +81,15 @@
|
|||
<tr><td>LLVMAsmParser</td><td><tt>.a</tt></td>
|
||||
<td>LLVM assembly parsing</td></tr>
|
||||
<tr><td>LLVMBCReader</td><td><tt>.a</tt></td>
|
||||
<td>LLVM bytecode reading</td></tr>
|
||||
<td>LLVM bitcode reading</td></tr>
|
||||
<tr><td>LLVMBCWriter</td><td><tt>.a</tt></td>
|
||||
<td>LLVM bytecode writing</td></tr>
|
||||
<td>LLVM bitcode writing</td></tr>
|
||||
<tr><td>LLVMCore</td><td><tt>.a</tt></td>
|
||||
<td>LLVM core intermediate representation</td></tr>
|
||||
<tr><td>LLVMDebugger</td><td><tt>.a</tt></td>
|
||||
<td>Source level debugging support</td></tr>
|
||||
<tr><td>LLVMLinker</td><td><tt>.a</tt></td>
|
||||
<td>Bytecode and archive linking interface</td></tr>
|
||||
<td>Bitcode and archive linking interface</td></tr>
|
||||
<tr><td>LLVMSupport</td><td><tt>.a</tt></td>
|
||||
<td>General support utilities</td></tr>
|
||||
<tr><td>LLVMSystem</td><td><tt>.a</tt></td>
|
||||
|
|
@ -141,9 +141,9 @@
|
|||
|
||||
<tr><th colspan="3">Runtime Libraries</th></tr>
|
||||
<tr><td>LLVMInterpreter</td><td><tt>.o</tt></td>
|
||||
<td>Bytecode Interpreter</td></tr>
|
||||
<td>Bitcode Interpreter</td></tr>
|
||||
<tr><td>LLVMJIT</td><td><tt>.o</tt></td>
|
||||
<td>Bytecode JIT Compiler</td></tr>
|
||||
<td>Bitcode JIT Compiler</td></tr>
|
||||
<tr><td>LLVMExecutionEngine</td><td><tt>.o</tt></td>
|
||||
<td>Virtual machine engine</td></tr>
|
||||
</table>
|
||||
|
|
|
|||
|
|
@ -347,8 +347,8 @@ use the <tt>opt</tt> tool to access it, once loaded.</p>
|
|||
|
||||
<p>To test it, follow the example at the end of the <a
|
||||
href="GettingStarted.html">Getting Started Guide</a> to compile "Hello World" to
|
||||
LLVM. We can now run the bytecode file (<tt>hello.bc</tt>) for the program
|
||||
through our transformation like this (or course, any bytecode file will
|
||||
LLVM. We can now run the bitcode file (<tt>hello.bc</tt>) for the program
|
||||
through our transformation like this (or course, any bitcode file will
|
||||
work):</p>
|
||||
|
||||
<div class="doc_code"><pre>
|
||||
|
|
@ -372,7 +372,7 @@ interesting way, we just throw away the result of <tt>opt</tt> (sending it to
|
|||
$ opt -load ../../../Debug/lib/Hello.so --help
|
||||
OVERVIEW: llvm .bc -> .bc modular optimizer
|
||||
|
||||
USAGE: opt [options] <input bytecode>
|
||||
USAGE: opt [options] <input bitcode>
|
||||
|
||||
OPTIONS:
|
||||
Optimizations available:
|
||||
|
|
@ -407,7 +407,7 @@ Hello: main
|
|||
Total Execution Time: 0.02 seconds (0.0479059 wall clock)
|
||||
|
||||
---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Pass Name ---
|
||||
0.0100 (100.0%) 0.0000 ( 0.0%) 0.0100 ( 50.0%) 0.0402 ( 84.0%) Bytecode Writer
|
||||
0.0100 (100.0%) 0.0000 ( 0.0%) 0.0100 ( 50.0%) 0.0402 ( 84.0%) Bitcode Writer
|
||||
0.0000 ( 0.0%) 0.0100 (100.0%) 0.0100 ( 50.0%) 0.0031 ( 6.4%) Dominator Set Construction
|
||||
0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0013 ( 2.7%) Module Verifier
|
||||
<b> 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0033 ( 6.9%) Hello World Pass</b>
|
||||
|
|
@ -1413,8 +1413,8 @@ Module Pass Manager
|
|||
Module Verifier
|
||||
-- Dominator Set Construction
|
||||
-- Module Verifier
|
||||
Bytecode Writer
|
||||
--Bytecode Writer
|
||||
Bitcode Writer
|
||||
--Bitcode Writer
|
||||
</pre></div>
|
||||
|
||||
<p>This output shows us when passes are constructed and when the analysis
|
||||
|
|
@ -1454,8 +1454,8 @@ Module Pass Manager
|
|||
Module Verifier
|
||||
-- Dominator Set Construction
|
||||
-- Module Verifier
|
||||
Bytecode Writer
|
||||
--Bytecode Writer
|
||||
Bitcode Writer
|
||||
--Bitcode Writer
|
||||
Hello: __main
|
||||
Hello: puts
|
||||
Hello: main
|
||||
|
|
@ -1494,8 +1494,8 @@ Module Pass Manager
|
|||
Module Verifier
|
||||
-- Dominator Set Construction
|
||||
-- Module Verifier
|
||||
Bytecode Writer
|
||||
--Bytecode Writer
|
||||
Bitcode Writer
|
||||
--Bitcode Writer
|
||||
Hello: __main
|
||||
Hello: puts
|
||||
Hello: main
|
||||
|
|
|
|||
Loading…
Reference in New Issue