From: Gabor Greif Date: Fri, 6 Jul 2007 22:07:22 +0000 (+0000) Subject: first pass of nomenclature changes in .html files X-Git-Url: http://plrg.eecs.uci.edu/git/?a=commitdiff_plain;h=04367bfc20c021c4105abf0c33b86d55f782d1e8;p=oota-llvm.git first pass of nomenclature changes in .html files git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37956 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/Bugpoint.html b/docs/Bugpoint.html index 43d237d094e..bdfd31379a9 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, bugpoint deletes any individual LLVM instructions whose absence does not eliminate the failure. At the end, bugpoint 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 opt or llc.

@@ -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 4dc7c8124cb..bc82b46735b 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -1357,7 +1357,7 @@ if that register is being used by the instruction. The method MachineOperand::isDef() informs if that registers is being defined.

-

We will call physical registers present in the LLVM bytecode before +

We will call physical registers present in the LLVM bitcode before register allocation pre-colored registers. 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 c73723efd08..253f4719a63 100644 --- a/docs/CompilerDriver.html +++ b/docs/CompilerDriver.html @@ -199,7 +199,7 @@

@@ -215,10 +215,10 @@ Optimization
-Ox @@ -229,13 +229,13 @@ Linking
    -
  • LLVM Bytecode
    • +
  • LLVM Bitcode
  • Native Object Code
  • LLVM Library
  • Native Library
    -
  • LLVM Bytecode Executable
    • +
  • LLVM Bitcode Executable
  • Native Executable
@@ -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, llvmc 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.

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 llvmc 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 llvmc 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 llvmc.

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.

@@ -532,10 +532,10 @@ optimization.

translator.output - bytecode or assembly + bitcode or assembly This item specifies the kind of output the language's translator generates. - bytecode + bitcode translator.preprocesses @@ -556,10 +556,10 @@ optimization.

optimizer.output - bytecode or assembly + bitcode or assembly This item specifies the kind of output the language's - optimizer generates. Valid values are "assembly" and "bytecode" - bytecode + optimizer generates. Valid values are "assembly" and "bitcode" + bitcode optimizer.preprocesses @@ -724,7 +724,7 @@ optimization.

translator.required=true # stkrc doesn't handle the -On options - translator.output=bytecode + translator.output=bitcode ########################################################## # Optimizer definitions @@ -742,7 +742,7 @@ optimization.

# opt doesn't preprocess optimizer.preprocesses=no - # opt produces bytecode + # opt produces bitcode optimizer.output = bc ########################################################## @@ -761,7 +761,7 @@ optimization.

defined below.

assembly
-
A compilation phase in which LLVM bytecode or +
A compilation phase 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).
@@ -774,12 +774,12 @@ optimization.

Refers to llvmc itself.
linking
-
A compilation phase in which LLVM bytecode files +
A compilation phase in which LLVM bitcode files and (optionally) native system libraries are combined to form a complete executable program.
optimization
-
A compilation phase in which LLVM bytecode is +
A compilation phase in which LLVM bitcode is optimized.
phase
@@ -804,7 +804,7 @@ optimization.

translation
A compilation phase in which source language code is translated into - either LLVM assembly language or LLVM bytecode.
+ either LLVM assembly language or LLVM bitcode.
diff --git a/docs/ExtendingLLVM.html b/docs/ExtendingLLVM.html index baad89a6ae2..7505c0eee6f 100644 --- a/docs/ExtendingLLVM.html +++ b/docs/ExtendingLLVM.html @@ -228,7 +228,7 @@ complicated behavior in a single node (rotate).

-

WARNING: adding instructions changes the bytecode +

WARNING: adding instructions changes the bitcode format, and it will take some effort to maintain compatibility with the previous version. Only add an instruction if it is absolutely necessary.

@@ -251,8 +251,8 @@ necessary.

add the grammar on how your instruction can be read and what it will construct as a result -
  • llvm/lib/Bytecode/Reader/Reader.cpp: - add a case for your instruction and how it will be parsed from bytecode
    • +
  • llvm/lib/Bitcode/Reader/Reader.cpp: + add a case for your instruction and how it will be parsed from bitcode
  • llvm/lib/VMCore/Instruction.cpp: add a case for how your instruction will be printed out to assembly
    • @@ -285,7 +285,7 @@ to understand this new instruction.

    -

    WARNING: adding new types changes the bytecode +

    WARNING: adding new types changes the bitcode format, and will break compatibility with currently-existing LLVM installations. Only add new types if it is absolutely necessary.

    @@ -348,12 +348,12 @@ bool TypesEqual(const Type *Ty, const Type *Ty2,
  • llvm/lib/AsmReader/Lexer.l: add ability to parse in the type from text assembly
    • -
  • llvm/lib/ByteCode/Writer/Writer.cpp: - modify void BytecodeWriter::outputType(const Type *T) to serialize +
  • llvm/lib/BitCode/Writer/Writer.cpp: + modify void BitcodeWriter::outputType(const Type *T) to serialize your type
    • -
  • llvm/lib/ByteCode/Reader/Reader.cpp: - modify const Type *BytecodeReader::ParseType() to read your data +
  • llvm/lib/BitCode/Reader/Reader.cpp: + modify const Type *BitcodeReader::ParseType() to read your data type
  • llvm/lib/VMCore/AsmWriter.cpp: diff --git a/docs/FAQ.html b/docs/FAQ.html index 6c4a79ce8ff..7342488193a 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -584,7 +584,7 @@ relatively slow.

    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.

    diff --git a/docs/GettingStarted.html b/docs/GettingStarted.html index cc740455726..33e3c2950ff 100644 --- a/docs/GettingStarted.html +++ b/docs/GettingStarted.html @@ -82,14 +82,14 @@ basic information.

    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.

    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.

    @@ -332,7 +332,7 @@ build requires considerably less space.

    The LLVM suite may 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.

    @@ -629,11 +629,11 @@ In order to compile and use LLVM, you may need to set some environment variables.
    -
    LLVM_LIB_SEARCH_PATH=/path/to/your/bytecode/libs
    +
    LLVM_LIB_SEARCH_PATH=/path/to/your/bitcode/libs
    [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 lib directory.
    @@ -974,8 +974,8 @@ source code:

    gmake -C runtime install-bytecode
    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.

    • @@ -1138,7 +1138,7 @@ If you're running on a Linux system that supports the " binfmt_misc" 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):

    @@ -1151,7 +1151,7 @@ first command may not be required if you are already using the module):

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

    @@ -1225,8 +1225,8 @@ different tools.

    This directory holds the source code for the LLVM assembly language parser library.
    -
    llvm/lib/ByteCode/
    -
    This directory holds code for reading and write LLVM bytecode.
    +
    llvm/lib/BitCode/
    +
    This directory holds code for reading and write LLVM bitcode.
    llvm/lib/Analysis/
    This directory contains a variety of different program analyses, such as Dominator Information, Call Graphs, @@ -1255,7 +1255,7 @@ different tools.

    source code locations at which the program is executing.
    llvm/lib/ExecutionEngine/
    -
    This directory contains libraries for executing LLVM bytecode directly +
    This directory contains libraries for executing LLVM bitcode directly at runtime in both interpreted and JIT compiled fashions.
    llvm/lib/Support/
    @@ -1283,7 +1283,7 @@ different tools.

    llvm/runtime
    -

    This directory contains libraries which are compiled into LLVM bytecode and +

    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.

    @@ -1342,22 +1342,22 @@ information is in the Command Guide.

    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. llvmc 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 -l<name> options right on the command line. Please note that this tool, while functional, is still experimental and not feature complete.
    llvm-ar
    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.
    llvm-as
    The assembler transforms the human readable LLVM assembly to LLVM - bytecode.
    + bitcode.
    llvm-dis
    -
    The disassembler transforms the LLVM bytecode to human readable +
    The disassembler transforms the LLVM bitcode to human readable LLVM assembly.
    llvm-ld
    @@ -1372,7 +1372,7 @@ information is in the Command Guide.

    lli
    lli 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, lli also has a tracing mode (entered by specifying -trace 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 Command Guide.

    llc
    llc 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).
    llvm-gcc
    llvm-gcc 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 -emit-llvm option) instead of the + bitcode or assembly (with the -emit-llvm option) instead of the usual machine code output. It works just like any other GCC compiler, taking the typical -c, -S, -E, -o options that are typically used. Additionally, the the source code for llvm-gcc is available as a separate Subversion module.
    opt
    -
    opt reads LLVM bytecode, applies a series of LLVM to LLVM +
    opt 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 'opt --help' command is a good way to + the resultant bitcode. The 'opt --help' command is a good way to get a list of the program transformations available in LLVM.
    opt 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.
    @@ -1490,9 +1490,9 @@ so we only include instructiosn for llvm-gcc4.

    Note: The gcc4 frontend's invocation is considerably different from the previous gcc3 frontend. In particular, the gcc4 frontend does not -create bytecode by default: gcc4 produces native code. As the example below illustrates, -the '--emit-llvm' flag is needed to produce LLVM bytecode output. For makefiles and -configure scripts, the CFLAGS variable needs '--emit-llvm' to produce bytecode +create bitcode by default: gcc4 produces native code. As the example below illustrates, +the '--emit-llvm' flag is needed to produce LLVM bitcode output. For makefiles and +configure scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode output.

    @@ -1519,13 +1519,13 @@ output.

    -c arguments work as usual (producing a native .s or .o file, respectively).

    -

  • Next, compile the C file into a LLVM bytecode file:

    +

  • Next, compile the C file into a LLVM bitcode file:

    % llvm-gcc -O3 -emit-llvm hello.c -c -o hello.bc

    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 standard LLVM tools on - the bytecode file.

    + the bitcode file.

    Unlike llvm-gcc3, llvm-gcc4 correctly responds to -O[0123] arguments.

    • diff --git a/docs/GettingStartedVS.html b/docs/GettingStartedVS.html index 9526af57b47..90a30bb040e 100644 --- a/docs/GettingStartedVS.html +++ b/docs/GettingStartedVS.html @@ -57,7 +57,7 @@

    To emphasize, there is no C/C++ front end currently available. llvm-gcc is based on GCC, which cannot be bootstrapped using VC++. Eventually there should be a llvm-gcc 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 llvm-gcc with code compiled with VC++ is essentially zero.

    @@ -257,11 +257,11 @@ All these paths are absolute:

    } -

  • Next, compile the C file into a LLVM bytecode file:

    +

  • Next, compile the C file into a LLVM bitcode file:

    % llvm-gcc -c hello.c -emit-llvm -o hello.bc

    This will create the result file hello.bc 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 lli tool, compile it to native assembly with the llc, optimize or analyze it further with the opt tool, etc.

    diff --git a/docs/HowToSubmitABug.html b/docs/HowToSubmitABug.html index 26cb58c0940..dca518426e4 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:

    bugpoint 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.

    @@ -268,7 +268,7 @@ Backend, and then link in the shared object it generates.

    -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]
    @@ -278,7 +278,7 @@ bugpoint -run-jit -output=[correct output file] [bytecode file] \ 
    -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]
    @@ -297,7 +297,7 @@ make bugpoint-jit

    At the end of a successful bugpoint run, you will be presented -with two bytecode files: a safe file which can be compiled with the C +with two bitcode files: a safe file which can be compiled with the C backend and the test file which either LLC or the JIT mis-codegenerates, and thus causes the error.

    @@ -306,7 +306,7 @@ the following:

      -

    1. Regenerate the shared object from the safe bytecode file:

      +

    2. Regenerate the shared object from the safe bitcode file:

      @@ -315,7 +315,7 @@ the following:

      3. -

    3. If debugging LLC, compile test bytecode native and link with the shared +

    4. If debugging LLC, compile test bitcode native and link with the shared object:

      @@ -327,7 +327,7 @@ the following:

    5. If debugging the JIT, load the shared object and supply the test - bytecode:

      + bitcode:

      lli -load=safe.so test.bc [program options]

      diff --git a/docs/LangRef.html b/docs/LangRef.html index 96d4fa10868..66dd9ca4b34 100644 --- a/docs/LangRef.html +++ b/docs/LangRef.html @@ -226,7 +226,7 @@ strategy.

      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:

      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.

      @@ -3690,7 +3690,7 @@ argument.

      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...).

      +adding to the language (or the bitcode reader/writer, the parser, etc...).

      Intrinsic function names must all start with an "llvm." 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 1084e352712..fdae78a2a1f 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 LLVMlto, 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.

        -
      • Input source file a.c is compiled into LLVM byte code form. +
      • Input source file a.c is compiled into LLVM bitcode form.
      • Input source file main.c is compiled into native object code. 
      @@ -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

      In this example, the linker recognizes that foo2() 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 readLLVMObjectFile(). Based on this information, the linker completes its usual symbol resolution pass and finds that foo2() is not used anywhere. This information @@ -202,15 +202,15 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

      - Phase 1 : Read LLVM Bytecode Files + Phase 1 : Read LLVM Bitcode Files

      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 readLLVMObjectFile() 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

      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 readLLVMObjectFile(). 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

      - Phase 3 : Optimize Bytecode Files + Phase 3 : Optimize Bitcode Files

      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 foo2() is not used anywhere in the program, including native .o files. This information is used by the LLVM interprocedural optimizer. The linker uses optimizeModules() @@ -260,12 +260,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

      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 foo4() 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.

      After this phase, the linker continues linking as if it never saw LLVM - bytecode files.

      + bitcode files.

      @@ -288,10 +288,10 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

      The LLVMSymbol 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 foo2() 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 foo2() in native object files with a future definition of the symbol foo2(). The linker will see the actual definition of foo2() when it receives the @@ -310,12 +310,12 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

      The readLLVMObjectFile() 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, LLVMlto maintains LLVM bytecode modules in + Internally, LLVMlto maintains LLVM bitcode modules in memory. This function also provides a list of external references used by - bytecode files.

      + bitcode files.

      @@ -325,7 +325,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

      The linker invokes optimizeModules 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 .o files at the name and location provided by the linker.

      @@ -338,7 +338,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi

      The linker may use getTargetTriple() to query target architecture - while validating LLVM bytecode file.

      + while validating LLVM bitcode file.

      @@ -347,7 +347,7 @@ $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifi
      -

      Internally, LLVMlto maintains LLVM bytecode modules in +

      Internally, LLVMlto maintains LLVM bitcode modules in memory. The linker may use removeModule() method to remove desired modules from memory.

      diff --git a/docs/MakefileGuide.html b/docs/MakefileGuide.html index c13e06fb1f0..9cb5b15bfd7 100644 --- a/docs/MakefileGuide.html +++ b/docs/MakefileGuide.html @@ -30,7 +30,7 @@
      1. Libraries
          -
        1. Bytecode Modules
          2. +
        2. Bitcode Modules
        3. Loadable Modules
        2. @@ -260,11 +260,11 @@
      -
      Bytecode Modules
      +
      Bitcode Modules
      -

      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 +

      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 MODULE_NAME variable. For example:

      
@@ -273,9 +273,9 @@
       MODULE_NAME = mymod

      will build a module named mymod.bc 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.

      @@ -626,7 +626,7 @@ files. These sources will be built before any other target processing to ensure they are present.
      BYTECODE_LIBRARY
      -
      If set to any value, causes a bytecode library (.bc) to be built.
      +
      If set to any value, causes a bitcode library (.bc) to be built.
      CONFIG_FILES
      Specifies a set of configuration files to be installed.
      DIRS
      @@ -709,9 +709,9 @@ setting this variable without also setting SHARED_LIBRARY will have no effect.
      MODULE_NAME
      -
      Specifies the name of a bytecode module to be created. A bytecode +
      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.
      NO_INSTALL
      Specifies that the build products of the directory should not be @@ -835,7 +835,7 @@
      LLVMGXX(defaulted)
      Specifies the path to the LLVM version of the GCC C++ Compiler
      LLVMLD(defaulted)
      -
      Specifies the path to the LLVM bytecode linker tool
      +
      Specifies the path to the LLVM bitcode linker tool
      LLVM_OBJ_ROOT(configured)
      Specifies the top directory into which the output of the build is @@ -884,8 +884,8 @@
      BuildMode
      The name of the type of build being performed: Debug, Release, or Profile
      -
      bytecode_libdir
      -
      The directory into which bytecode libraries will ultimately be +
      bytecode_libdir
      +
      The directory into which bitcode libraries will ultimately be installed. This value is derived from the --prefix option given to configure.
      ConfigureScriptFLAGS
      @@ -965,7 +965,7 @@ CXX.Flags DependFiles DestArchiveLib - DestBytecodeLib + DestBitcodeLib DestModule DestRelinkedLib DestSharedLib diff --git a/docs/Passes.html b/docs/Passes.html index 46957690088..3edb1219d1d 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.

      The table below provides a quick summary of each pass and links to the more complete pass description later in the document.

      @@ -143,7 +143,7 @@ OptionNameDirectory -deadarghaX0rDead Argument Hacking (BUGPOINT ONLY) -extract-blocksExtract Basic Blocks From Module (BUGPOINT ONLY) --emitbytecodeBytecode Writer +-emitbitcodeBitcode Writer -verifyModule Verifier
      @@ -994,7 +994,7 @@
      - Bytecode Writer + Bitcode Writer

      Yet to be written.

      diff --git a/docs/ProgrammersManual.html b/docs/ProgrammersManual.html index 1f02fe699b5..ff18d1c9aa8 100644 --- a/docs/ProgrammersManual.html +++ b/docs/ProgrammersManual.html @@ -581,9 +581,9 @@ suite, it gives a report that looks like this:

      -   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.
 
      
diff --git a/docs/TestingGuide.html b/docs/TestingGuide.html
index f03adaaef64..222ccfb52a9 100644
--- a/docs/TestingGuide.html
+++ b/docs/TestingGuide.html
@@ -224,10 +224,10 @@ subtrees of the test suite directory tree are as follows:
      
     
    6. Analysis: checks Analysis passes.
      7. 
     
    7. Archive: checks the Archive library.
      8. 
     
    8. Assembler: checks Assembly reader/writer functionality.
      9. 
-    
    9. Bytecode: checks Bytecode reader/writer functionality.
      10. 
+    
    10. Bitcode: checks Bitcode reader/writer functionality.
      11. 
     
    11. CodeGen: checks code generation and each target.
      12. 
     
    12. Features: checks various features of the LLVM language.
      13. 
-    
    13. Linker: tests bytecode linking.
      14. 
+    
    14. Linker: tests bitcode linking.
      15. 
     
    15. Transforms: tests each of the scalar, IPO, and utility
     transforms to ensure they make the right transformations.
      16. 
     
    16. Verifier: tests the IR verifier.
      17. 
diff --git a/docs/UsingLibraries.html b/docs/UsingLibraries.html
index 74b03d96230..af57907ef66 100644
--- a/docs/UsingLibraries.html
+++ b/docs/UsingLibraries.html
@@ -81,15 +81,15 @@
   LLVMAsmParser.a
     LLVM assembly parsing
   LLVMBCReader.a
-    LLVM bytecode reading
+    LLVM bitcode reading
   LLVMBCWriter.a
-    LLVM bytecode writing
+    LLVM bitcode writing
   LLVMCore.a
     LLVM core intermediate representation
   LLVMDebugger.a
     Source level debugging support
   LLVMLinker.a
-    Bytecode and archive linking interface
+    Bitcode and archive linking interface
   LLVMSupport.a
     General support utilities
   LLVMSystem.a
@@ -141,9 +141,9 @@
 
   Runtime Libraries
   LLVMInterpreter.o
-    Bytecode Interpreter
+    Bitcode Interpreter
   LLVMJIT.o
-    Bytecode JIT Compiler
+    Bitcode JIT Compiler
   LLVMExecutionEngine.o
     Virtual machine engine
 
diff --git a/docs/WritingAnLLVMPass.html b/docs/WritingAnLLVMPass.html
index 09e5f53d6ca..c967000a9e0 100644
--- a/docs/WritingAnLLVMPass.html
+++ b/docs/WritingAnLLVMPass.html
@@ -347,8 +347,8 @@ use the opt tool to access it, once loaded.
      
 
 
      To test it, follow the example at the end of the Getting Started Guide to compile "Hello World" to
-LLVM.  We can now run the bytecode file (hello.bc) for the program
-through our transformation like this (or course, any bytecode file will
+LLVM.  We can now run the bitcode file (hello.bc) for the program
+through our transformation like this (or course, any bitcode file will
 work):
      
 
 
      @@ -372,7 +372,7 @@ interesting way, we just throw away the result of opt (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
    0.0000 (  0.0%)   0.0000 (  0.0%)   0.0000 (  0.0%)   0.0033 (  6.9%)  Hello World Pass
@@ -1413,8 +1413,8 @@ Module Pass Manager
     Module Verifier
 --  Dominator Set Construction
 --  Module Verifier
-  Bytecode Writer
---Bytecode Writer
+  Bitcode Writer
+--Bitcode Writer
 
      
 
 
      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