llvm.org GIT mirror llvm / 04367bf
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 Gabor Greif 12 years ago
16 changed file(s) with 142 addition(s) and 142 deletion(s). Raw diff Collapse all Expand all
122122 flow graph, to reduce the size of the function as much as possible. Finally,
123123 bugpoint deletes any individual LLVM instructions whose absence does
124124 not eliminate the failure. At the end, bugpoint should tell you what
125 passes crash, give you a bytecode file, and give you instructions on how to
125 passes crash, give you a bitcode file, and give you instructions on how to
126126 reproduce the failure with opt or llc.

127127
128128
140140 with the C backend (into a shared object), and one piece which it runs with
141141 either the JIT or the static LLC compiler. It uses several techniques to
142142 reduce the amount of code pushed through the LLVM code generator, to reduce the
143 potential scope of the problem. After it is finished, it emits two bytecode
143 potential scope of the problem. After it is finished, it emits two bitcode
144144 files (called "test" [to be compiled with the code generator] and "safe" [to be
145145 compiled with the C backend], respectively), and instructions for reproducing
146146 the problem. The code generator debugger assumes that the C backend produces
13561356 MachineOperand::isDef() informs if that registers is being
13571357 defined.

13581358
1359

We will call physical registers present in the LLVM bytecode before

1359

We will call physical registers present in the LLVM bitcode before

13601360 register allocation pre-colored registers. Pre-colored
13611361 registers are used in many different situations, for instance, to pass
13621362 parameters of functions calls, and to store results of particular
198198
199199
200200
  • LLVM Assembly
  • 201
  • LLVM Bytecode
  • 201
  • LLVM Bitcode
  • 202202
  • LLVM C++ IR
  • 203203
    204204
    214214 Optimization
    215215
    216216
  • LLVM Assembly
  • 217
  • LLVM Bytecode
  • 217
  • LLVM Bitcode
  • 218218
    219219
    220
  • LLVM Bytecode
  • 220
  • LLVM Bitcode
  • 221221
    222222
    223223
    -Ox
    228228
    229229 Linking
    230230
    231
  • LLVM Bytecode
  • 231
  • LLVM Bitcode
  • 232232
  • Native Object Code
  • 233233
  • LLVM Library
  • 234234
  • Native Library
  • 235235
    236236
    237
  • LLVM Bytecode Executable
  • 237
  • LLVM Bitcode Executable
  • 238238
  • Native Executable
  • 239239
    240240
    290290 available command line options for those programs regardless of whether they
    291291 were written for LLVM or not. Furthermore, not all compiler tools will
    292292 have the same capabilities. Some compiler tools will simply generate LLVM assembly
    293 code, others will be able to generate fully optimized byte code. In general,
    293 code, others will be able to generate fully optimized bitcode. In general,
    294294 llvmc doesn't make any assumptions about the capabilities or command
    295295 line options of a sub-tool. It simply uses the details found in the
    296296 configuration files and leaves it to the compiler writer to specify the
    298298
    299299

    This approach means that new compiler tools can be up and working very

    300300 quickly. As a first cut, a tool can simply compile its source to raw
    301 (unoptimized) bytecode or LLVM assembly and llvmc can be configured
    302 to pick up the slack (translate LLVM assembly to bytecode, optimize the
    303 bytecode, generate native assembly, link, etc.). In fact, the compiler tools
    301 (unoptimized) bitcode or LLVM assembly and llvmc can be configured
    302 to pick up the slack (translate LLVM assembly to bitcode, optimize the
    303 bitcode, generate native assembly, link, etc.). In fact, the compiler tools
    304304 need not use any LLVM libraries, and it could be written in any language
    305305 (instead of C++). The configuration data will allow the full range of
    306306 optimization, assembly, and linking capabilities that LLVM provides to be added
    308308 of the primary goals of llvmc.

    309309
    310310

    As a compiler tool matures, it may utilize the LLVM libraries and tools

    311 to more efficiently produce optimized bytecode directly in a single compilation
    311 to more efficiently produce optimized bitcode directly in a single compilation
    312312 and optimization program. In these cases, multiple tools would not be needed
    313313 and the configuration data for the compiler would change.

    314314
    531531
    532532
    533533 translator.output
    534 bytecode or assembly
    534 bitcode or assembly
    535535 This item specifies the kind of output the language's
    536536 translator generates.
    537 bytecode
    537 bitcode
    538538
    539539
    540540 translator.preprocesses
    555555
    556556
    557557 optimizer.output
    558 bytecode or assembly
    558 bitcode or assembly
    559559 This item specifies the kind of output the language's
    560 optimizer generates. Valid values are "assembly" and "bytecode"
    561 bytecode
    560 optimizer generates. Valid values are "assembly" and "bitcode"
    561 bitcode
    562562
    563563
    564564 optimizer.preprocesses
    723723 translator.required=true
    724724
    725725 # stkrc doesn't handle the -On options
    726 translator.output=bytecode
    726 translator.output=bitcode
    727727
    728728 ##########################################################
    729729 # Optimizer definitions
    741741 # opt doesn't preprocess
    742742 optimizer.preprocesses=no
    743743
    744 # opt produces bytecode
    744 # opt produces bitcode
    745745 optimizer.output = bc
    746746
    747747 ##########################################################
    760760 defined below.

    761761
    762762
    assembly
    763
    A compilation phase in which LLVM bytecode or
    763
    A compilation phase in which LLVM bitcode or
    764764 LLVM assembly code is assembled to a native code format (either target
    765765 specific aseembly language or the platform's native object file format).
    766766
    773773
    Refers to llvmc itself.
    774774
    775775
    linking
    776
    A compilation phase in which LLVM bytecode files
    776
    A compilation phase in which LLVM bitcode files
    777777 and (optionally) native system libraries are combined to form a complete
    778778 executable program.
    779779
    780780
    optimization
    781
    A compilation phase in which LLVM bytecode is
    781
    A compilation phase in which LLVM bitcode is
    782782 optimized.
    783783
    784784
    phase
    803803
    translation
    804804
    A compilation phase in which
    805805 source language code is translated into
    806 either LLVM assembly language or LLVM bytecode.
    806 either LLVM assembly language or LLVM bitcode.
    807807
    808808
    809809
    227227
    228228
    229229
    230

    WARNING: adding instructions changes the bytecode

    230

    WARNING: adding instructions changes the bitcode

    231231 format, and it will take some effort to maintain compatibility with
    232232 the previous version. Only add an instruction if it is absolutely
    233233 necessary.

    250250 add the grammar on how your instruction can be read and what it will
    251251 construct as a result
    252252
    253
  • llvm/lib/Bytecode/Reader/Reader.cpp:
  • 254 add a case for your instruction and how it will be parsed from bytecode
    253
  • llvm/lib/Bitcode/Reader/Reader.cpp:
  • 254 add a case for your instruction and how it will be parsed from bitcode
    255255
    256256
  • llvm/lib/VMCore/Instruction.cpp:
  • 257257 add a case for how your instruction will be printed out to assembly
    284284
    285285
    286286
    287

    WARNING: adding new types changes the bytecode

    287

    WARNING: adding new types changes the bitcode

    288288 format, and will break compatibility with currently-existing LLVM
    289289 installations. Only add new types if it is absolutely necessary.

    290290
    347347
  • llvm/lib/AsmReader/Lexer.l:
  • 348348 add ability to parse in the type from text assembly
    349349
    350
  • llvm/lib/ByteCode/Writer/Writer.cpp:
  • 351 modify void BytecodeWriter::outputType(const Type *T) to serialize
    350
  • llvm/lib/BitCode/Writer/Writer.cpp:
  • 351 modify void BitcodeWriter::outputType(const Type *T) to serialize
    352352 your type
    353353
    354
  • llvm/lib/ByteCode/Reader/Reader.cpp:
  • 355 modify const Type *BytecodeReader::ParseType() to read your data
    354
  • llvm/lib/BitCode/Reader/Reader.cpp:
  • 355 modify const Type *BitcodeReader::ParseType() to read your data
    356356 type
    357357
    358358
  • llvm/lib/VMCore/AsmWriter.cpp:
  • 583583

    Also note: this specific sequence of commands won't work if you use a

    584584 function defined in the C++ runtime library (or any other C++ library). To
    585585 access an external C++ library, you must manually
    586 compile libstdc++ to LLVM bytecode, statically link it into your program, then
    586 compile libstdc++ to LLVM bitcode, statically link it into your program, then
    587587 use the commands above to convert the whole result into C code. Alternatively,
    588588 you can compile the libraries and your application into two different chunks
    589589 of C code and link them.

    8181
    8282

    First, LLVM comes in two pieces. The first piece is the LLVM suite. This

    8383 contains all of the tools, libraries, and header files needed to use the low
    84 level virtual machine. It contains an assembler, disassembler, bytecode
    85 analyzer and bytecode optimizer. It also contains a test suite that can be
    84 level virtual machine. It contains an assembler, disassembler, bitcode
    85 analyzer and bitcode optimizer. It also contains a test suite that can be
    8686 used to test the LLVM tools and the GCC front end.

    8787
    8888

    The second piece is the GCC front end. This component provides a version of

    89 GCC that compiles C and C++ code into LLVM bytecode. Currently, the GCC front
    89 GCC that compiles C and C++ code into LLVM bitcode. Currently, the GCC front
    9090 end uses the GCC parser to convert code to LLVM. Once
    91 compiled into LLVM bytecode, a program can be manipulated with the LLVM tools
    91 compiled into LLVM bitcode, a program can be manipulated with the LLVM tools
    9292 from the LLVM suite.

    9393
    9494

    331331
    332332

    The LLVM suite may compile on other platforms, but it is not

    333333 guaranteed to do so. If compilation is successful, the LLVM utilities should be
    334 able to assemble, disassemble, analyze, and optimize LLVM bytecode. Code
    334 able to assemble, disassemble, analyze, and optimize LLVM bitcode. Code
    335335 generation should work as well, although the generated native code may not work
    336336 on your platform.

    337337
    628628 variables.
    629629
    630630
    631
    LLVM_LIB_SEARCH_PATH=/path/to/your/bytecode/libs
    631
    LLVM_LIB_SEARCH_PATH=/path/to/your/bitcode/libs
    632632
    [Optional] This environment variable helps LLVM linking tools find the
    633 locations of your bytecode libraries. It is provided only as a
    633 locations of your bitcode libraries. It is provided only as a
    634634 convenience since you can specify the paths using the -L options of the
    635 tools and the C/C++ front-end will automatically use the bytecode files
    635 tools and the C/C++ front-end will automatically use the bitcode files
    636636 installed in its
    637637 lib directory.
    638638
    973973
    gmake -C runtime install-bytecode
    974974
    975975 Assuming you built LLVM into $OBJDIR, when this command is run, it will
    976 install bytecode libraries into the GCC front end's bytecode library
    977 directory. If you need to update your bytecode libraries,
    976 install bitcode libraries into the GCC front end's bitcode library
    977 directory. If you need to update your bitcode libraries,
    978978 this is the target to use once you've built them.
    979979

    980980
    11371137 href="http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html">
    11381138 binfmt_misc"
    11391139 module, and you have root access on the system, you can set your system up to
    1140 execute LLVM bytecode files directly. To do this, use commands like this (the
    1140 execute LLVM bitcode files directly. To do this, use commands like this (the
    11411141 first command may not be required if you are already using the module):

    11421142
    11431143
    11501150
    11511151
    11521152

    1153 This allows you to execute LLVM bytecode files directly. Thanks to Jack
    1153 This allows you to execute LLVM bitcode files directly. Thanks to Jack
    11541154 Cummings for pointing this out!
    11551155

    11561156
    12241224
    This directory holds the source code for the LLVM assembly language parser
    12251225 library.
    12261226
    1227
    llvm/lib/ByteCode/
    1228 d>This directory holds code for reading and write LLVM bytecode.>
    1227 t>llvm/lib/BitCode/>
    1228
    This directory holds code for reading and write LLVM bitcode.
    12291229
    12301230
    llvm/lib/Analysis/
    This directory contains a variety of
    12311231 different program analyses, such as Dominator Information, Call Graphs,
    12541254 source code locations at which the program is executing.
    12551255
    12561256
    llvm/lib/ExecutionEngine/
    1257
    This directory contains libraries for executing LLVM bytecode directly
    1257
    This directory contains libraries for executing LLVM bitcode directly
    12581258 at runtime in both interpreted and JIT compiled fashions.
    12591259
    12601260
    llvm/lib/Support/
    12821282
    12831283
    12841284
    1285

    This directory contains libraries which are compiled into LLVM bytecode and

    1285

    This directory contains libraries which are compiled into LLVM bitcode and

    12861286 used when linking programs with the GCC front end. Most of these libraries are
    12871287 skeleton versions of real libraries; for example, libc is a stripped down
    12881288 version of glibc.

    13411341 be configured to utilize both LLVM and non-LLVM compilation tools to enable
    13421342 pre-processing, translation, optimization, assembly, and linking of programs
    13431343 all from one command line. llvmc also takes care of processing the
    1344 dependent libraries found in bytecode. This reduces the need to get the
    1344 dependent libraries found in bitcode. This reduces the need to get the
    13451345 traditional -l<name> options right on the command line. Please
    13461346 note that this tool, while functional, is still experimental and not feature
    13471347 complete.
    13481348
    13491349
    llvm-ar
    13501350
    The archiver produces an archive containing
    1351 the given LLVM bytecode files, optionally with an index for faster
    1351 the given LLVM bitcode files, optionally with an index for faster
    13521352 lookup.
    13531353
    13541354
    llvm-as
    13551355
    The assembler transforms the human readable LLVM assembly to LLVM
    1356 bytecode.
    1356 bitcode.
    13571357
    13581358
    llvm-dis
    1359
    The disassembler transforms the LLVM bytecode to human readable
    1359
    The disassembler transforms the LLVM bitcode to human readable
    13601360 LLVM assembly.
    13611361
    13621362
    llvm-ld
    13711371
    13721372
    lli
    13731373
    lli is the LLVM interpreter, which
    1374 can directly execute LLVM bytecode (although very slowly...). In addition
    1374 can directly execute LLVM bitcode (although very slowly...). In addition
    13751375 to a simple interpreter, lli also has a tracing mode (entered by
    13761376 specifying -trace on the command line). Finally, for
    13771377 architectures that support it (currently x86, Sparc, and PowerPC), by default,
    13811381
    13821382
    llc
    13831383
    llc is the LLVM backend compiler, which
    1384 translates LLVM bytecode to a native code assembly file or to C code (with
    1384 translates LLVM bitcode to a native code assembly file or to C code (with
    13851385 the -march=c option).
    13861386
    13871387
    llvm-gcc
    13881388
    llvm-gcc is a GCC-based C frontend that has been retargeted to
    13891389 use LLVM as its backend instead of GCC's RTL backend. It can also emit LLVM
    1390 byte code or assembly (with the -emit-llvm option) instead of the
    1390 bitcode or assembly (with the -emit-llvm option) instead of the
    13911391 usual machine code output. It works just like any other GCC compiler,
    13921392 taking the typical -c, -S, -E, -o options that are typically used.
    13931393 Additionally, the the source code for llvm-gcc is available as a
    13941394 separate Subversion module.
    13951395
    13961396
    opt
    1397
    opt reads LLVM bytecode, applies a series of LLVM to LLVM
    1397
    opt reads LLVM bitcode, applies a series of LLVM to LLVM
    13981398 transformations (which are specified on the command line), and then outputs
    1399 the resultant bytecode. The 'opt --help' command is a good way to
    1399 the resultant bitcode. The 'opt --help' command is a good way to
    14001400 get a list of the program transformations available in LLVM.
    14011401
    opt can also be used to run a specific analysis on an input
    1402 LLVM bytecode file and print out the results. It is primarily useful for
    1402 LLVM bitcode file and print out the results. It is primarily useful for
    14031403 debugging analyses, or familiarizing yourself with what an analysis does.
    14041404
    14051405
    14891489
    14901490

    Note: The gcc4 frontend's invocation is considerably different

    14911491 from the previous gcc3 frontend. In particular, the gcc4 frontend does not
    1492 create bytecode by default: gcc4 produces native code. As the example below illustrates,
    1493 the '--emit-llvm' flag is needed to produce LLVM bytecode output. For makefiles and
    1494 configure scripts, the CFLAGS variable needs '--emit-llvm' to produce bytecode
    1492 create bitcode by default: gcc4 produces native code. As the example below illustrates,
    1493 the '--emit-llvm' flag is needed to produce LLVM bitcode output. For makefiles and
    1494 configure scripts, the CFLAGS variable needs '--emit-llvm' to produce bitcode
    14951495 output.

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

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

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

  • 15221522

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

    15231523
    15241524

    The -emit-llvm option can be used with the -S or -c options to emit an

    15251525 LLVM ".ll" or ".bc" file (respectively) for the code. This allows you
    15261526 to use the standard LLVM tools on
    1527 the bytecode file.

    1527 the bitcode file.

    15281528
    15291529

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

    15301530

    5656

    To emphasize, there is no C/C++ front end currently available.

    5757 llvm-gcc is based on GCC, which cannot be bootstrapped using VC++.
    5858 Eventually there should be a llvm-gcc based on Cygwin or MinGW that
    59 is usable. There is also the option of generating bytecode files on Unix and
    59 is usable. There is also the option of generating bitcode files on Unix and
    6060 copying them over to Windows. But be aware the odds of linking C++ code
    6161 compiled with llvm-gcc with code compiled with VC++ is essentially
    6262 zero.

    256256 }
    257257
    258258
    259
  • Next, compile the C file into a LLVM bytecode file:

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

  • 260260

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

    261261
    262262

    This will create the result file hello.bc which is the LLVM

    263 bytecode that corresponds the the compiled program and the library
    263 bitcode that corresponds the the compiled program and the library
    264264 facilities that it required. You can execute this file directly using
    265265 lli tool, compile it to native assembly with the llc,
    266266 optimize or analyze it further with the opt tool, etc.

    241241
    242242
    243243

    bugpoint will try to narrow down your list of passes to the one pass

    244 that causes an error, and simplify the bytecode file as much as it can to assist
    244 that causes an error, and simplify the bitcode file as much as it can to assist
    245245 you. It will print a message letting you know how to reproduce the resulting
    246246 error.

    247247
    267267
    268268
    269269
    
                      
                    
    270 bugpoint -run-jit -output=[correct output file] [bytecode file] \
    270 bugpoint -run-jit -output=[correct output file] [bitcode file] \
    271271 --tool-args -- [arguments to pass to lli] \
    272272 --args -- [program arguments]
    273273
    277277
    278278
    279279
    
                      
                    
    280 bugpoint -run-llc -output=[correct output file] [bytecode file] \
    280 bugpoint -run-llc -output=[correct output file] [bitcode file] \
    281281 --tool-args -- [arguments to pass to llc] \
    282282 --args -- [program arguments]
    283283
    296296
    297297
    298298

    At the end of a successful bugpoint run, you will be presented

    299 with two bytecode files: a safe file which can be compiled with the C
    299 with two bitcode files: a safe file which can be compiled with the C
    300300 backend and the test file which either LLC or the JIT
    301301 mis-codegenerates, and thus causes the error.

    302302
    305305
    306306
    307307
    308
  • Regenerate the shared object from the safe bytecode file:

  • 308
  • Regenerate the shared object from the safe bitcode file:

  • 309309
    310310
    311311

    314314

    315315
    316316
    317
  • If debugging LLC, compile test bytecode native and link with the shared

  • 317
  • If debugging LLC, compile test bitcode native and link with the shared

  • 318318 object:

    319319
    320320
    326326
    327327
    328328
  • If debugging the JIT, load the shared object and supply the test

  • 329 bytecode:

    329 bitcode:

    330330
    331331
    332332

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

    225225
    226226
    227227

    The LLVM code representation is designed to be used in three

    228 different forms: as an in-memory compiler IR, as an on-disk bytecode
    228 different forms: as an in-memory compiler IR, as an on-disk bitcode
    229229 representation (suitable for fast loading by a Just-In-Time compiler),
    230230 and as a human readable assembly language representation. This allows
    231231 LLVM to provide a powerful intermediate representation for efficient
    267267 its uses. The LLVM infrastructure provides a verification pass that may
    268268 be used to verify that an LLVM module is well formed. This pass is
    269269 automatically run by the parser after parsing input assembly and by
    270 the optimizer before it outputs bytecode. The violations pointed out
    270 the optimizer before it outputs bitcode. The violations pointed out
    271271 by the verifier pass indicate bugs in transformation passes or input to
    272272 the parser.

    273273
    36893689 well known names and semantics and are required to follow certain restrictions.
    36903690 Overall, these intrinsics represent an extension mechanism for the LLVM
    36913691 language that does not require changing all of the transformations in LLVM when
    3692 adding to the language (or the bytecode reader/writer, the parser, etc...).

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

    36933693
    36943694

    Intrinsic function names must all start with an "llvm." prefix. This

    36953695 prefix is reserved in LLVM for intrinsic names; thus, function names may not
    6666 the developer take advantage of intermodular optimizations without making any
    6767 significant changes to the developer's makefiles or build system. This is
    6868 achieved through tight integration with the linker. In this model, the linker
    69 treates LLVM bytecode files like native object files and allows mixing and
    69 treates LLVM bitcode files like native object files and allows mixing and
    7070 matching among them. The linker uses LLVMlto, a dynamically
    71 loaded library, to handle LLVM bytecode files. This tight integration between
    71 loaded library, to handle LLVM bitcode files. This tight integration between
    7272 the linker and LLVM optimizer helps to do optimizations that are not possible
    7373 in other models. The linker input allows the optimizer to avoid relying on
    7474 conservative escape analysis.
    8686 supports LTO through the interface described in this document. Here,
    8787 llvm-gcc4 transparently invokes system linker.

    8888
    89
  • Input source file a.c is compiled into LLVM byte code form.
  • 89
  • Input source file a.c is compiled into LLVM bitcode form.
  • 9090
  • Input source file main.c is compiled into native object code.
  • 9191
    9292
    
                      
                    
    130130 }
    131131
    132132 --- command lines ---
    133 $ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bytecode file
    133 $ llvm-gcc4 --emit-llvm -c a.c -o a.o # <-- a.o is LLVM bitcode file
    134134 $ llvm-gcc4 -c main.c -o main.o # <-- main.o is native object file
    135135 $ llvm-gcc4 a.o main.o -o main # <-- standard link command without any modifications
    136136
    137137

    In this example, the linker recognizes that foo2() is an

    138 externally visible symbol defined in LLVM byte code file. This information
    138 externally visible symbol defined in LLVM bitcode file. This information
    139139 is collected using readLLVMObjectFile().
    140140 Based on this information, the linker completes its usual symbol resolution
    141141 pass and finds that foo2() is not used anywhere. This information
    201201
    202202
    203203
    204 Phase 1 : Read LLVM Bytecode Files
    204 Phase 1 : Read LLVM Bitcode Files
    205205
    206206
    207207
    208208

    The linker first reads all object files in natural order and collects

    209 symbol information. This includes native object files as well as LLVM byte
    210 code files. In this phase, the linker uses
    209 symbol information. This includes native object files as well as LLVM bitcode
    210 files. In this phase, the linker uses
    211211 readLLVMObjectFile() to collect symbol
    212 information from each LLVM bytecode files and updates its internal global
    212 information from each LLVM bitcode files and updates its internal global
    213213 symbol table accordingly. The intent of this interface is to avoid overhead
    214214 in the non LLVM case, where all input object files are native object files,
    215215 by putting this code in the error path of the linker. When the linker sees
    227227

    In this stage, the linker resolves symbols using global symbol table

    228228 information to report undefined symbol errors, read archive members, resolve
    229229 weak symbols, etc. The linker is able to do this seamlessly even though it
    230 does not know the exact content of input LLVM bytecode files because it uses
    230 does not know the exact content of input LLVM bitcode files because it uses
    231231 symbol information provided by
    232232 readLLVMObjectFile(). If dead code
    233233 stripping is enabled then the linker collects the list of live symbols.
    236236
    237237
    238238
    239 Phase 3 : Optimize Bytecode Files
    239 Phase 3 : Optimize Bitcode Files
    240240
    241241
    242242

    After symbol resolution, the linker updates symbol information supplied

    243 by LLVM bytecode files appropriately. For example, whether certain LLVM
    244 bytecode supplied symbols are used or not. In the example above, the linker
    243 by LLVM bitcode files appropriately. For example, whether certain LLVM
    244 bitcode supplied symbols are used or not. In the example above, the linker
    245245 reports that foo2() is not used anywhere in the program, including
    246246 native .o files. This information is used by the LLVM interprocedural
    247247 optimizer. The linker uses optimizeModules()
    259259

    In this phase, the linker reads optimized a native object file and

    260260 updates the internal global symbol table to reflect any changes. The linker
    261261 also collects information about any changes in use of external symbols by
    262 LLVM bytecode files. In the examle above, the linker notes that
    262 LLVM bitcode files. In the examle above, the linker notes that
    263263 foo4() is not used any more. If dead code stripping is enabled then
    264264 the linker refreshes the live symbol information appropriately and performs
    265265 dead code stripping.

    266266

    After this phase, the linker continues linking as if it never saw LLVM

    267 bytecode files.

    267 bitcode files.

    268268
    269269
    270270
    287287
    288288
    289289

    The LLVMSymbol class is used to describe the externally visible

    290 functions and global variables, defined in LLVM bytecode files, to the linker.
    290 functions and global variables, defined in LLVM bitcode files, to the linker.
    291291 This includes symbol visibility information. This information is used by
    292292 the linker to do symbol resolution. For example: function foo2() is
    293 defined inside an LLVM bytecode module and it is an externally visible symbol.
    293 defined inside an LLVM bitcode module and it is an externally visible symbol.
    294294 This helps the linker connect the use of foo2() in native object
    295295 files with a future definition of the symbol foo2(). The linker
    296296 will see the actual definition of foo2() when it receives the
    309309
    310310
    311311

    The readLLVMObjectFile() function is used by the linker to read

    312 LLVM bytecode files and collect LLVMSymbol information. This routine also
    313 supplies a list of externally defined symbols that are used by LLVM bytecode
    312 LLVM bitcode files and collect LLVMSymbol information. This routine also
    313 supplies a list of externally defined symbols that are used by LLVM bitcode
    314314 files. The linker uses this symbol information to do symbol resolution.
    315 Internally, LLVMlto maintains LLVM bytecode modules in
    315 Internally, LLVMlto maintains LLVM bitcode modules in
    316316 memory. This function also provides a list of external references used by
    317 bytecode files.

    317 bitcode files.

    318318
    319319
    320320
    324324
    325325
    326326

    The linker invokes optimizeModules to optimize already read

    327 LLVM bytecode files by applying LLVM intermodular optimization techniques.
    327 LLVM bitcode files by applying LLVM intermodular optimization techniques.
    328328 This function runs the LLVM intermodular optimizer and generates native
    329329 object code as .o files at the name and location provided by the
    330330 linker.

    337337
    338338
    339339

    The linker may use getTargetTriple() to query target architecture

    340 while validating LLVM bytecode file.

    340 while validating LLVM bitcode file.

    341341
    342342
    343343
    346346
    347347
    348348
    349

    Internally, LLVMlto maintains LLVM bytecode modules in

    349

    Internally, LLVMlto maintains LLVM bitcode modules in

    350350 memory. The linker may use removeModule() method to remove desired
    351351 modules from memory.

    352352
    2929
    3030
  • Libraries
  • 3131
    32
  • Bytecode Modules
  • 32
  • Bitcode Modules
  • 3333
  • Loadable Modules
  • 3434
    3535
    259259
    260260
    261261
    262
    263
    264

    In some situations, it is desireable to build a single bytecode module from

    265 a variety of sources, instead of an archive, shared library, or bytecode
    266 library. Bytecode modules can be specified in addition to any of the other
    262
    263
    264

    In some situations, it is desireable to build a single bitcode module from

    265 a variety of sources, instead of an archive, shared library, or bitcode
    266 library. Bitcode modules can be specified in addition to any of the other
    267267 types of libraries by defining the MODULE_NAME
    268268 variable. For example:

    269269
    
    
                      
                    
    272272 MODULE_NAME = mymod
    273273
    274274

    will build a module named mymod.bc from the sources in the

    275 directory. This module will be an aggregation of all the bytecode modules
    276 derived from the sources. The example will also build a bytecode archive
    277 containing a bytecode module for each compiled source file. The difference is
    275 directory. This module will be an aggregation of all the bitcode modules
    276 derived from the sources. The example will also build a bitcode archive
    277 containing a bitcode module for each compiled source file. The difference is
    278278 subtle, but important depending on how the module or library is to be linked.
    279279

    280280
    625625 files. These sources will be built before any other target processing to
    626626 ensure they are present.
    627627
    BYTECODE_LIBRARY
    628
    If set to any value, causes a bytecode library (.bc) to be built.
    628
    If set to any value, causes a bitcode library (.bc) to be built.
    629629
    CONFIG_FILES
    630630
    Specifies a set of configuration files to be installed.
    631631
    DIRS
    708708 setting this variable without also setting SHARED_LIBRARY will have
    709709 no effect.
    710710
    MODULE_NAME
    711
    Specifies the name of a bytecode module to be created. A bytecode
    711
    Specifies the name of a bitcode module to be created. A bitcode
    712712 module can be specified in conjunction with other kinds of library builds
    713 or by itself. It constructs from the sources a single linked bytecode
    713 or by itself. It constructs from the sources a single linked bitcode
    714714 file.
    715715
    NO_INSTALL
    716716
    Specifies that the build products of the directory should not be
    834834
    LLVMGXX(defaulted)
    835835
    Specifies the path to the LLVM version of the GCC C++ Compiler
    836836
    LLVMLD(defaulted)
    837
    Specifies the path to the LLVM bytecode linker tool
    837
    Specifies the path to the LLVM bitcode linker tool
    838838
    LLVM_OBJ_ROOT(configured)
    839839
    840840
    Specifies the top directory into which the output of the build is
    883883
    BuildMode
    884884
    The name of the type of build being performed: Debug, Release, or
    885885 Profile
    886
    bytecode_libdir
    887 d>The directory into which bytecode libraries will ultimately be
    886 t>bytecode_libdir
    887
    The directory into which bitcode libraries will ultimately be
    888888 installed. This value is derived from the --prefix option given to
    889889 configure.
    890890
    ConfigureScriptFLAGS
    964964 CXX.Flags
    965965 DependFiles
    966966 DestArchiveLib
    967 DestBytecodeLib
    967 DestBitcodeLib
    968968 DestModule
    969969 DestRelinkedLib
    970970 DestSharedLib
    3030 or program visualization purposes. Transform passes can use (or invalidate)
    3131 the analysis passes. Transform passes all mutate the program in some way.
    3232 Utility passes provides ome utility but don't otherwise fit categorization.
    33 For example passes to extract functions to bytecode or write a module to
    34 bytecode are neither analysis nor transform passes.
    33 For example passes to extract functions to bitcode or write a module to
    34 bitcode are neither analysis nor transform passes.
    3535

    The table below provides a quick summary of each pass and links to the more

    3636 complete pass description later in the document.

    3737
    142142
    OptionNameDirectory
    143143
    -deadarghaX0rDead Argument Hacking (BUGPOINT ONLY)
    144144
    -extract-blocksExtract Basic Blocks From Module (BUGPOINT ONLY)
    145
    -emitbytecodeBytecode Writer
    145
    -emitbitcodeBitcode Writer
    146146
    -verifyModule Verifier
    147147
    148148
    993993 994994 995995 998998
    999999

    Yet to be written.

    580580
    581581
    582582
    
                      
                    
    583 7646 bytecodewriter - Number of normal instructions
    584 725 bytecodewriter - Number of oversized instructions
    585 129996 bytecodewriter - Number of bytecode bytes written
    583 7646 bitcodewriter - Number of normal instructions
    584 725 bitcodewriter - Number of oversized instructions
    585 129996 bitcodewriter - Number of bitcode bytes written
    586586 2817 raise - Number of insts DCEd or constprop'd
    587587 3213 raise - Number of cast-of-self removed
    588588 5046 raise - Number of expression trees converted
    19341934 difficult to handle. Fortunately, for the most part, our implementation makes
    19351935 most clients able to be completely unaware of the nasty internal details. The
    19361936 primary case where clients are exposed to the inner workings of it are when
    1937 building a recursive type. In addition to this case, the LLVM bytecode reader,
    1937 building a recursive type. In addition to this case, the LLVM bitcode reader,
    19381938 assembly parser, and linker also have to be aware of the inner workings of this
    19391939 system.
    19401940

    223223
  • Analysis: checks Analysis passes.
  • 224224
  • Archive: checks the Archive library.
  • 225225
  • Assembler: checks Assembly reader/writer functionality.
  • 226
  • Bytecode: checks Bytecode reader/writer functionality.
  • 226
  • Bitcode: checks Bitcode reader/writer functionality.
  • 227227
  • CodeGen: checks code generation and each target.
  • 228228
  • Features: checks various features of the LLVM language.
  • 229
  • Linker: tests bytecode linking.
  • 229
  • Linker: tests bitcode linking.
  • 230230
  • Transforms: tests each of the scalar, IPO, and utility
  • 231231 transforms to ensure they make the right transformations.
    232232
  • Verifier: tests the IR verifier.
  • 8080
    LLVMAsmParser.a
    8181 LLVM assembly parsing
    8282
    LLVMBCReader.a
    83 LLVM bytecode reading
    83 LLVM bitcode reading
    8484
    LLVMBCWriter.a
    85 LLVM bytecode writing
    85 LLVM bitcode writing
    8686
    LLVMCore.a
    8787 LLVM core intermediate representation
    8888
    LLVMDebugger.a
    8989 Source level debugging support
    9090
    LLVMLinker.a
    91 Bytecode and archive linking interface
    91 Bitcode and archive linking interface
    9292
    LLVMSupport.a
    9393 General support utilities
    9494
    LLVMSystem.a
    140140
    141141
    Runtime Libraries
    142142
    LLVMInterpreter.o
    143 Bytecode Interpreter
    143 Bitcode Interpreter
    144144
    LLVMJIT.o
    145 Bytecode JIT Compiler
    145 Bitcode JIT Compiler
    146146
    LLVMExecutionEngine.o
    147147 Virtual machine engine
    148148
    346346
    347347

    To test it, follow the example at the end of the

    348348 href="GettingStarted.html">Getting Started Guide to compile "Hello World" to
    349 LLVM. We can now run the bytecode file (hello.bc) for the program
    350 through our transformation like this (or course, any bytecode file will
    349 LLVM. We can now run the bitcode file (hello.bc) for the program
    350 through our transformation like this (or course, any bitcode file will
    351351 work):

    352352
    353353
    
                      
                    
    371371 $ opt -load ../../../Debug/lib/Hello.so --help
    372372 OVERVIEW: llvm .bc -> .bc modular optimizer
    373373
    374 USAGE: opt [options] <input bytecode>
    374 USAGE: opt [options] <input bitcode>
    375375
    376376 OPTIONS:
    377377 Optimizations available:
    406406 Total Execution Time: 0.02 seconds (0.0479059 wall clock)
    407407
    408408 ---User Time--- --System Time-- --User+System-- ---Wall Time--- --- Pass Name ---
    409 0.0100 (100.0%) 0.0000 ( 0.0%) 0.0100 ( 50.0%) 0.0402 ( 84.0%) Bytecode Writer
    409 0.0100 (100.0%) 0.0000 ( 0.0%) 0.0100 ( 50.0%) 0.0402 ( 84.0%) Bitcode Writer
    410410 0.0000 ( 0.0%) 0.0100 (100.0%) 0.0100 ( 50.0%) 0.0031 ( 6.4%) Dominator Set Construction
    411411 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0013 ( 2.7%) Module Verifier
    412412 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0000 ( 0.0%) 0.0033 ( 6.9%) Hello World Pass
    14121412 Module Verifier
    14131413 -- Dominator Set Construction
    14141414 -- Module Verifier
    1415 Bytecode Writer
    1416 --Bytecode Writer
    1415 Bitcode Writer
    1416 --Bitcode Writer
    14171417
    14181418
    14191419

    This output shows us when passes are constructed and when the analysis

    14531453 Module Verifier
    14541454 -- Dominator Set Construction
    14551455 -- Module Verifier
    1456 Bytecode Writer
    1457 --Bytecode Writer
    1456 Bitcode Writer
    1457 --Bitcode Writer
    14581458 Hello: __main
    14591459 Hello: puts
    14601460 Hello: main
    14931493 Module Verifier
    14941494 -- Dominator Set Construction
    14951495 -- Module Verifier
    1496 Bytecode Writer
    1497 --Bytecode Writer
    1496 Bitcode Writer
    1497 --Bitcode Writer
    14981498 Hello: __main
    14991499 Hello: puts
    15001500 Hello: main