[llvm-commits] [llvm] r37956 - in /llvm/trunk/docs: Bugpoint.html CodeGenerator.html CompilerDriver.html ExtendingLLVM.html FAQ.html GettingStarted.html GettingStartedVS.html HowToSubmitABug.html LangRef.html LinkTimeOptimization.html MakefileGuide.html Passes.html ProgrammersManual.html TestingGuide.html UsingLibraries.html WritingAnLLVMPass.html
Gabor Greif
ggreif at gmail.com
Fri Jul 6 15:07:22 PDT 2007
Author: ggreif
Date: Fri Jul 6 17:07:22 2007
New Revision: 37956
URL: http://llvm.org/viewvc/llvm-project?rev=37956&view=rev
Log:
first pass of nomenclature changes in .html files
Modified:
llvm/trunk/docs/Bugpoint.html
llvm/trunk/docs/CodeGenerator.html
llvm/trunk/docs/CompilerDriver.html
llvm/trunk/docs/ExtendingLLVM.html
llvm/trunk/docs/FAQ.html
llvm/trunk/docs/GettingStarted.html
llvm/trunk/docs/GettingStartedVS.html
llvm/trunk/docs/HowToSubmitABug.html
llvm/trunk/docs/LangRef.html
llvm/trunk/docs/LinkTimeOptimization.html
llvm/trunk/docs/MakefileGuide.html
llvm/trunk/docs/Passes.html
llvm/trunk/docs/ProgrammersManual.html
llvm/trunk/docs/TestingGuide.html
llvm/trunk/docs/UsingLibraries.html
llvm/trunk/docs/WritingAnLLVMPass.html
Modified: llvm/trunk/docs/Bugpoint.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Bugpoint.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/Bugpoint.html (original)
+++ llvm/trunk/docs/Bugpoint.html Fri Jul 6 17:07:22 2007
@@ -123,7 +123,7 @@
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 @@
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
Modified: llvm/trunk/docs/CodeGenerator.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CodeGenerator.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/CodeGenerator.html (original)
+++ llvm/trunk/docs/CodeGenerator.html Fri Jul 6 17:07:22 2007
@@ -1357,7 +1357,7 @@
<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
Modified: llvm/trunk/docs/CompilerDriver.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/CompilerDriver.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/CompilerDriver.html (original)
+++ llvm/trunk/docs/CompilerDriver.html Fri Jul 6 17:07:22 2007
@@ -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 @@
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 @@
<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 @@
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 @@
</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 @@
</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 @@
translator.required=true
# stkrc doesn't handle the -On options
- translator.output=bytecode
+ translator.output=bitcode
##########################################################
# Optimizer definitions
@@ -742,7 +742,7 @@
# opt doesn't preprocess
optimizer.preprocesses=no
- # opt produces bytecode
+ # opt produces bitcode
optimizer.output = bc
##########################################################
@@ -761,7 +761,7 @@
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 @@
<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 @@
<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>
<!-- *********************************************************************** -->
Modified: llvm/trunk/docs/ExtendingLLVM.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ExtendingLLVM.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/ExtendingLLVM.html (original)
+++ llvm/trunk/docs/ExtendingLLVM.html Fri Jul 6 17:07:22 2007
@@ -228,7 +228,7 @@
<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 @@
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 @@
<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 @@
<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>:
Modified: llvm/trunk/docs/FAQ.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/FAQ.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/FAQ.html (original)
+++ llvm/trunk/docs/FAQ.html Fri Jul 6 17:07:22 2007
@@ -584,7 +584,7 @@
<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>
Modified: llvm/trunk/docs/GettingStarted.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GettingStarted.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/GettingStarted.html (original)
+++ llvm/trunk/docs/GettingStarted.html Fri Jul 6 17:07:22 2007
@@ -82,14 +82,14 @@
<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 @@
<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 @@
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 @@
<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 @@
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 @@
</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 @@
<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 @@
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 @@
<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 @@
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 @@
<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 @@
<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 @@
<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 @@
-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>
Modified: llvm/trunk/docs/GettingStartedVS.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/GettingStartedVS.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/GettingStartedVS.html (original)
+++ llvm/trunk/docs/GettingStartedVS.html Fri Jul 6 17:07:22 2007
@@ -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 @@
}
</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>
Modified: llvm/trunk/docs/HowToSubmitABug.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/HowToSubmitABug.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/HowToSubmitABug.html (original)
+++ llvm/trunk/docs/HowToSubmitABug.html Fri Jul 6 17:07:22 2007
@@ -242,7 +242,7 @@
</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 @@
<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 @@
<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 @@
</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 @@
<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 @@
</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 @@
</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>
Modified: llvm/trunk/docs/LangRef.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LangRef.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/LangRef.html (original)
+++ llvm/trunk/docs/LangRef.html Fri Jul 6 17:07:22 2007
@@ -226,7 +226,7 @@
<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 @@
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 @@
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
Modified: llvm/trunk/docs/LinkTimeOptimization.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/LinkTimeOptimization.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/LinkTimeOptimization.html (original)
+++ llvm/trunk/docs/LinkTimeOptimization.html Fri Jul 6 17:07:22 2007
@@ -67,9 +67,9 @@
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 @@
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 @@
}
--- 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 @@
<!-- ======================================================================= -->
<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 @@
<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 @@
<!-- ======================================================================= -->
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
<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 @@
</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>
Modified: llvm/trunk/docs/MakefileGuide.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/MakefileGuide.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/MakefileGuide.html (original)
+++ llvm/trunk/docs/MakefileGuide.html Fri Jul 6 17:07:22 2007
@@ -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
Modified: llvm/trunk/docs/Passes.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/Passes.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/Passes.html (original)
+++ llvm/trunk/docs/Passes.html Fri Jul 6 17:07:22 2007
@@ -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>
Modified: llvm/trunk/docs/ProgrammersManual.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/ProgrammersManual.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/ProgrammersManual.html (original)
+++ llvm/trunk/docs/ProgrammersManual.html Fri Jul 6 17:07:22 2007
@@ -581,9 +581,9 @@
<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 @@
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>
Modified: llvm/trunk/docs/TestingGuide.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/TestingGuide.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/TestingGuide.html (original)
+++ llvm/trunk/docs/TestingGuide.html Fri Jul 6 17:07:22 2007
@@ -224,10 +224,10 @@
<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>
Modified: llvm/trunk/docs/UsingLibraries.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/UsingLibraries.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/UsingLibraries.html (original)
+++ llvm/trunk/docs/UsingLibraries.html Fri Jul 6 17:07:22 2007
@@ -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>
Modified: llvm/trunk/docs/WritingAnLLVMPass.html
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/WritingAnLLVMPass.html?rev=37956&r1=37955&r2=37956&view=diff
==============================================================================
--- llvm/trunk/docs/WritingAnLLVMPass.html (original)
+++ llvm/trunk/docs/WritingAnLLVMPass.html Fri Jul 6 17:07:22 2007
@@ -347,8 +347,8 @@
<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 @@
$ 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 @@
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 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 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 Verifier
-- Dominator Set Construction
-- Module Verifier
- Bytecode Writer
---Bytecode Writer
+ Bitcode Writer
+--Bitcode Writer
Hello: __main
Hello: puts
Hello: main
More information about the llvm-commits
mailing list