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

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

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

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 
+(unoptimized) bitcode or LLVM assembly and <tt>llvmc</tt> can be configured 
-to pick up the slack (translate LLVM assembly to bytecode, optimize the 
+to pick up the slack (translate LLVM assembly to bitcode, optimize the 
-bytecode, generate native assembly, link, etc.).   In fact, the compiler tools 
+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>
+          optimizer generates. Valid values are "assembly" and "bitcode"</td>
-        <td><tt>bytecode</tt></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>
 <!-- *********************************************************************** -->

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>:
+<li><tt>llvm/lib/Bitcode/Reader/Reader.cpp</tt>:
-    add a case for your instruction and how it will be parsed from bytecode</li>
+    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>:
+<li><tt>llvm/lib/BitCode/Writer/Writer.cpp</tt>:
-    modify <tt>void BytecodeWriter::outputType(const Type *T)</tt> to serialize
+    modify <tt>void BitcodeWriter::outputType(const Type *T)</tt> to serialize
     your type</li>
 
-<li><tt>llvm/lib/ByteCode/Reader/Reader.cpp</tt>:
+<li><tt>llvm/lib/BitCode/Reader/Reader.cpp</tt>:
-    modify <tt>const Type *BytecodeReader::ParseType()</tt> to read your data
+    modify <tt>const Type *BitcodeReader::ParseType()</tt> to read your data
     type</li> 
 
 <li><tt>llvm/lib/VMCore/AsmWriter.cpp</tt>:

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>

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
+level virtual machine.  It contains an assembler, disassembler, bitcode
-analyzer and bytecode optimizer.  It also contains a test suite that can be
+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 
+  install bitcode libraries into the GCC front end's bitcode library 
-  directory.  If you need to update your bytecode libraries,
+  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>
+  <dt><tt><b>llvm/lib/BitCode/</b></tt></dt>
-  <dd>This directory holds code for reading and write LLVM bytecode.</dd>
+  <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,
+create bitcode 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
+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 bytecode
+<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>

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> 

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>

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

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 
+  symbol information. This includes native object files as well as LLVM bitcode 
-  code files.  In this phase, the linker uses 
+  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
 
 <!-- ======================================================================= -->
 <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 
+  by LLVM bitcode files appropriately. For example, whether certain LLVM 
-  bytecode supplied symbols are used or not. In the example above, the linker 
+  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 # &lt;-- 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 # &lt;-- 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 # &lt;-- 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
+  LLVM bitcode files and collect LLVMSymbol information. This routine also
-  supplies a list of externally defined symbols that are used by LLVM bytecode
+  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 # &lt;-- 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 # &lt;-- 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 # &lt;-- 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>

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
+  <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 bytecode 
+  a variety of sources, instead of an archive, shared library, or bitcode 
-  library. Bytecode modules can be specified in addition to any of the other
+  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 
+  directory. This module will be an aggregation of all the bitcode modules 
-  derived from the sources. The example will also build a bytecode archive 
+  derived from the sources. The example will also build a bitcode archive 
-  containing a bytecode module for each compiled source file. The difference is
+  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>
+    <dt><a name="bitcode_libdir"><tt>bytecode_libdir</tt></a></dt>
-    <dd>The directory into which bytecode libraries will ultimately be 
+    <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

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
+  For example passes to extract functions to bitcode or write a module to
-  bytecode are neither analysis nor transform passes.
+  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>

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
+   7646 bitcodewriter   - Number of normal instructions
-    725 bytecodewriter  - Number of oversized instructions
+    725 bitcodewriter   - Number of oversized instructions
- 129996 bytecodewriter  - Number of bytecode bytes written
+ 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>

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>

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>

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
+LLVM.  We can now run the bitcode file (<tt>hello.bc</tt>) for the program
-through our transformation like this (or course, any bytecode file will
+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 -&gt; .bc modular optimizer
 
-USAGE: opt [options] &lt;input bytecode&gt;
+USAGE: opt [options] &lt;input bitcode&gt;
 
 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
+  Bitcode Writer
---Bytecode 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
+  Bitcode Writer
---Bytecode 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
+  Bitcode Writer
---Bytecode Writer
+--Bitcode Writer
 Hello: __main
 Hello: puts
 Hello: main