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

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&lt;name&gt;</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  # &lt;-- a.o is LLVM bytecode file
+$ llvm-gcc4 --emit-llvm -c a.c -o a.o  # &lt;-- a.o is LLVM bitcode file
 $ llvm-gcc4 -c main.c -o main.o # &lt;-- main.o is native object file
 $ llvm-gcc4 a.o main.o -o main # &lt;-- 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 # &lt;-- 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 # &lt;-- 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 # &lt;-- standard link command without any modifi