diff options
| -rw-r--r-- | docs/Bugpoint.html | 4 | ||||
| -rw-r--r-- | docs/CodeGenerator.html | 2 | ||||
| -rw-r--r-- | docs/CompilerDriver.html | 42 | ||||
| -rw-r--r-- | docs/ExtendingLLVM.html | 16 | ||||
| -rw-r--r-- | docs/FAQ.html | 2 | ||||
| -rw-r--r-- | docs/GettingStarted.html | 62 | ||||
| -rw-r--r-- | docs/GettingStartedVS.html | 6 | ||||
| -rw-r--r-- | docs/HowToSubmitABug.html | 14 | ||||
| -rw-r--r-- | docs/LangRef.html | 6 | ||||
| -rw-r--r-- | docs/LinkTimeOptimization.html | 48 | ||||
| -rw-r--r-- | docs/MakefileGuide.html | 30 | ||||
| -rw-r--r-- | docs/Passes.html | 8 | ||||
| -rw-r--r-- | docs/ProgrammersManual.html | 8 | ||||
| -rw-r--r-- | docs/TestingGuide.html | 4 | ||||
| -rw-r--r-- | docs/UsingLibraries.html | 10 | ||||
| -rw-r--r-- | docs/WritingAnLLVMPass.html | 20 |
16 files changed, 141 insertions, 141 deletions
diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html index 43d237d094..bdfd31379a 100644 --- a/docs/Bugpoint.html +++ b/docs/Bugpoint.html @@ -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 diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 4dc7c8124c..bc82b46735 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -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 diff --git a/docs/CompilerDriver.html b/docs/CompilerDriver.html index c73723efd0..253f4719a6 100644 --- a/docs/CompilerDriver.html +++ b/docs/CompilerDriver.html @@ -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> <!-- *********************************************************************** --> diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index baad89a6ae..7505c0eee6 100644 --- a/docs/ExtendingLLVM.html +++ b/docs/ExtendingLLVM.html @@ -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>: diff --git a/docs/FAQ.html b/docs/FAQ.html index 6c4a79ce8f..7342488193 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -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> diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html index cc74045572..33e3c2950f 100644 --- a/docs/GettingStarted.html +++ b/docs/GettingStarted.html @@ -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> diff --git a/docs/GettingStartedVS.html b/docs/GettingStartedVS.html index 9526af57b4..90a30bb040 100644 --- a/docs/GettingStartedVS.html +++ b/docs/GettingStartedVS.html @@ -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> diff --git a/docs/HowToSubmitABug.html b/docs/HowToSubmitABug.html index 26cb58c094..dca518426e 100644 --- a/docs/HowToSubmitABug.html +++ b/docs/HowToSubmitABug.html @@ -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> diff --git a/docs/LangRef.html b/docs/LangRef.html index 96d4fa1086..66dd9ca4b3 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -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 diff --git a/docs/LinkTimeOptimization.html b/docs/LinkTimeOptimization.html index 1084e35271..fdae78a2a1 100644 --- a/docs/LinkTimeOptimization.html +++ b/docs/LinkTimeOptimization.html @@ -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> diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html index c13e06fb1f..9cb5b15bfd 100644 --- a/docs/MakefileGuide.html +++ b/docs/MakefileGuide.html @@ -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 diff --git a/docs/Passes.html b/docs/Passes.html index 4695769008..3edb1219d1 100644 --- a/docs/Passes.html +++ b/docs/Passes.html @@ -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> diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index 1f02fe699b..ff18d1c9aa 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -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> diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html index f03adaaef6..222ccfb52a 100644 --- a/docs/TestingGuide.html +++ b/docs/TestingGuide.html @@ -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> diff --git a/docs/UsingLibraries.html b/docs/UsingLibraries.html index 74b03d9623..af57907ef6 100644 --- a/docs/UsingLibraries.html +++ b/docs/UsingLibraries.html @@ -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> diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html index 09e5f53d6c..c967000a9e 100644 --- a/docs/WritingAnLLVMPass.html +++ b/docs/WritingAnLLVMPass.html @@ -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 |