llvm.org GIT mirror llvm / f5af6ad
docs: Introduce cascading style <div> and <p> continued on <h[2-5]>. <h2>Section Example</h2> <div> <!-- h2+div is applied --> <p>Section preamble.</p> <h3>Subsection Example</h3> <p> <!-- h3+p is applied --> Subsection body </p> <!-- End of section body --> </div> FIXME: Care H5 better. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130040 91177308-0d34-0410-b5e6-96231b3b80d8 NAKAMURA Takumi 8 years ago
52 changed file(s) with 1635 addition(s) and 1572 deletion(s). Raw diff Collapse all Expand all
4949

Abstract

5050
5151
52 class="doc_text">
52 >
5353
5454

This document describes the LLVM bitstream file format and the encoding of

5555 the LLVM IR into it.

6060

Overview

6161
6262
63 class="doc_text">
63 >
6464
6565

6666 What is commonly known as the LLVM bitcode file format (also, sometimes
9090

Bitstream Format

9191
9292
93 class="doc_text">
93 >
9494
9595

9696 The bitstream format is literally a stream of bits, with a very simple
113113 used to dump and inspect arbitrary bitstreams, which is very useful for
114114 understanding the encoding.

115115
116
117
118116
119117

120118 Magic Numbers
121119
122120
123 class="doc_text">
121 >
124122
125123

The first two bytes of a bitcode file are 'BC' (0x42, 0x43).

126124 The second two bytes are an application-specific magic number. Generic
134132 Primitives
135133
136134
137 class="doc_text">
135 >
138136
139137

140138 A bitstream literally consists of a stream of bits, which are read in order
145143 Integers.
146144

147145
148
149
150146
151147

152148 Fixed Width Integers
153149
154150
155 class="doc_text">
151 >
156152
157153

Fixed-width integer values have their low bits emitted directly to the file.

158154 For example, a 3-bit integer value encodes 1 as 001. Fixed width integers
167163 Variable Width Integers
168164
169165
170 class="doc_text">
166 >
171167
172168

Variable-width integer (VBR) values encode values of arbitrary size,

173169 optimizing for the case where the values are small. Given a 4-bit VBR field,
187183
188184

6-bit characters

189185
190 class="doc_text">
186 >
191187
192188

6-bit characters encode common characters into a fixed 6-bit field. They

193189 represent the following characters with the following 6-bit values:

211207
212208

Word Alignment

213209
214 class="doc_text">
210 >
215211
216212

Occasionally, it is useful to emit zero bits until the bitstream is a

217213 multiple of 32 bits. This ensures that the bit position in the stream can be
219215
220216
221217
218
222219
223220
224221

225222 Abbreviation IDs
226223
227224
228 class="doc_text">
225 >
229226
230227

231228 A bitstream is a sequential series of Blocks and
261258 Blocks
262259
263260
264 class="doc_text">
261 >
265262
266263

267264 Blocks in a bitstream denote nested regions of the stream, and are identified by
302299 popped, the saved values are restored.
303300

304301
305
306
307302
308303

ENTER_SUBBLOCK Encoding

309304
310 class="doc_text">
305 >
311306
312307

[ENTER_SUBBLOCK, blockidvbr8, newabbrevlenvbr4,

313308 <align32bits>, blocklen32]

328323
329324

END_BLOCK Encoding

330325
331 class="doc_text">
326 >
332327
333328

[END_BLOCK, <align32bits>]

334329
340335
341336
342337
343
338
344339
345340
346341

347342 Data Records
348343
349344
350 class="doc_text">
345 >
351346

352347 Data records consist of a record code and a number of (up to) 64-bit
353348 integer values. The interpretation of the code and values is
359354 ASCII codes for the characters in the string.
360355

361356
362
363
364357
365358

UNABBREV_RECORD Encoding

366359
367 class="doc_text">
360 >
368361
369362

[UNABBREV_RECORD, codevbr6, numopsvbr6,

370363 op0vbr6, op1vbr6, ...]

390383
391384

Abbreviated Record Encoding

392385
393 class="doc_text">
386 >
394387
395388

[<abbrevid>, fields...]

396389
411404
412405
413406
407
408
414409
415410

416411 Abbreviations
417412
418413
419 class="doc_text">
414 >
420415

421416 Abbreviations are an important form of compression for bitstreams. The idea is
422417 to specify a dense encoding for a class of records once, then use that encoding
434429 for binary operators. If a specific LLVM module contained no or few binary
435430 operators, the abbreviation does not need to be emitted.
436431

437
438432
439433
440434

DEFINE_ABBREV Encoding

441435
442 class="doc_text">
436 >
443437
444438

[DEFINE_ABBREV, numabbrevopsvbr5, abbrevop0, abbrevop1,

445439 ...]

554548
555549
556550
551
552
557553
558554

559555 Standard Blocks
560556
561557
562 class="doc_text">
558 >
563559
564560

565561 In addition to the basic block structure and record encodings, the bitstream
568564 may be added. Block IDs 0-7 are reserved for standard blocks.
569565

570566
571
572
573567
574568

#0 - BLOCKINFO Block

575569
576 class="doc_text">
570 >
577571
578572

579573 The BLOCKINFO block allows the description of metadata for other
622616
623617
624618
619
620
621
622
625623
626624

Bitcode Wrapper Format

627625
628626
629 class="doc_text">
627 >
630628
631629

632630 Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper
657655

LLVM IR Encoding

658656
659657
660 class="doc_text">
658 >
661659
662660

663661 LLVM IR is encoded into a bitstream by defining blocks and records. It uses
668666 reader is not allowed to build in any knowledge of this.
669667

670668
671
672
673669
674670

675671 Basics
676672
677673
674
675
678676
679677

LLVM IR Magic Number

680678
681 class="doc_text">
679 >
682680
683681

684682 The magic number for LLVM IR files is:
700698
701699

Signed VBRs

702700
703 class="doc_text">
701 >
704702
705703

706704 Variable Width Integer encoding is an efficient way to
733731
734732

LLVM IR Blocks

735733
736 class="doc_text">
734 >
737735
738736

739737 LLVM IR is defined with the following blocks:
761759
762760
763761
762
763
764764
765765

766766 MODULE_BLOCK Contents
767767
768768
769 class="doc_text">
769 >
770770
771771

The MODULE_BLOCK block (id 8) is the top-level block for LLVM

772772 bitcode files, and each bitcode file must contain exactly one. In
786786
  • METADATA_BLOCK
  • 787787
    788788
    789
    790
    791789
    792790

    MODULE_CODE_VERSION Record

    793791
    794 class="doc_text">
    792 >
    795793
    796794

    [VERSION, version#]

    797795
    803801
    804802

    MODULE_CODE_TRIPLE Record

    805803
    806 class="doc_text">
    804 >
    807805

    [TRIPLE, ...string...]

    808806
    809807

    The TRIPLE record (code 2) contains a variable number of

    814812
    815813

    MODULE_CODE_DATALAYOUT Record

    816814
    817 class="doc_text">
    815 >
    818816

    [DATALAYOUT, ...string...]

    819817
    820818

    The DATALAYOUT record (code 3) contains a variable number of

    825823
    826824

    MODULE_CODE_ASM Record

    827825
    828 class="doc_text">
    826 >
    829827

    [ASM, ...string...]

    830828
    831829

    The ASM record (code 4) contains a variable number of

    836834
    837835

    MODULE_CODE_SECTIONNAME Record

    838836
    839 class="doc_text">
    837 >
    840838

    [SECTIONNAME, ...string...]

    841839
    842840

    The SECTIONNAME record (code 5) contains a variable number

    851849
    852850

    MODULE_CODE_DEPLIB Record

    853851
    854 class="doc_text">
    852 >
    855853

    [DEPLIB, ...string...]

    856854
    857855

    The DEPLIB record (code 6) contains a variable number of

    864862
    865863

    MODULE_CODE_GLOBALVAR Record

    866864
    867 class="doc_text">
    865 >
    868866

    [GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal]

    869867
    870868

    The GLOBALVAR record (code 7) marks the declaration or

    928926
    929927

    MODULE_CODE_FUNCTION Record

    930928
    931 class="doc_text">
    929 >
    932930
    933931

    [FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]

    934932
    984982
    985983

    MODULE_CODE_ALIAS Record

    986984
    987 class="doc_text">
    985 >
    988986
    989987

    [ALIAS, alias type, aliasee val#, linkage, visibility]

    990988
    10081006
    10091007

    MODULE_CODE_PURGEVALS Record

    10101008
    1011 class="doc_text">
    1009 >
    10121010

    [PURGEVALS, numvals]

    10131011
    10141012

    The PURGEVALS record (code 10) resets the module-level

    10211019
    10221020

    MODULE_CODE_GCNAME Record

    10231021
    1024 class="doc_text">
    1022 >
    10251023

    [GCNAME, ...string...]

    10261024
    10271025

    The GCNAME record (code 11) contains a variable number of

    10321030 fields of FUNCTION records.

    10331031
    10341032
    1033
    1034
    10351035
    10361036

    10371037 PARAMATTR_BLOCK Contents
    10381038
    10391039
    1040 class="doc_text">
    1040 >
    10411041
    10421042

    The PARAMATTR_BLOCK block (id 9) contains a table of

    10431043 entries describing the attributes of function parameters. These
    10511051 that each is unique (i.e., no two indicies represent equivalent
    10521052 attribute lists).

    10531053
    1054
    1055
    1056
    10571054
    10581055

    PARAMATTR_CODE_ENTRY Record

    10591056
    1060 class="doc_text">
    1057 >
    10611058
    10621059

    [ENTRY, paramidx0, attr0, paramidx1, attr1...]

    10631060
    10981095
    10991096
    11001097
    1098
    1099
    11011100
    11021101

    11031102 TYPE_BLOCK Contents
    11041103
    11051104
    1106 class="doc_text">
    1105 >
    11071106
    11081107

    The TYPE_BLOCK block (id 10) contains records which

    11091108 constitute a table of type operator entries used to represent types
    11181117 each entry is unique (i.e., no two indicies represent structurally
    11191118 equivalent types).

    11201119
    1121
    1122
    11231120
    11241121

    TYPE_CODE_NUMENTRY Record

    11251122
    1126 class="doc_text">
    1123 >
    11271124
    11281125

    [NUMENTRY, numentries]

    11291126
    11371134
    11381135

    TYPE_CODE_VOID Record

    11391136
    1140 class="doc_text">
    1137 >
    11411138
    11421139

    [VOID]

    11431140
    11491146
    11501147

    TYPE_CODE_FLOAT Record

    11511148
    1152 class="doc_text">
    1149 >
    11531150
    11541151

    [FLOAT]

    11551152
    11611158
    11621159

    TYPE_CODE_DOUBLE Record

    11631160
    1164 class="doc_text">
    1161 >
    11651162
    11661163

    [DOUBLE]

    11671164
    11731170
    11741171

    TYPE_CODE_LABEL Record

    11751172
    1176 class="doc_text">
    1173 >
    11771174
    11781175

    [LABEL]

    11791176
    11851182
    11861183

    TYPE_CODE_OPAQUE Record

    11871184
    1188 class="doc_text">
    1185 >
    11891186
    11901187

    [OPAQUE]

    11911188
    11981195
    11991196

    TYPE_CODE_INTEGER Record

    12001197
    1201 class="doc_text">
    1198 >
    12021199
    12031200

    [INTEGER, width]

    12041201
    12111208
    12121209

    TYPE_CODE_POINTER Record

    12131210
    1214 class="doc_text">
    1211 >
    12151212
    12161213

    [POINTER, pointee type, address space]

    12171214
    12311228
    12321229

    TYPE_CODE_FUNCTION Record

    12331230
    1234 class="doc_text">
    1231 >
    12351232
    12361233

    [FUNCTION, vararg, ignored, retty, ...paramty... ]

    12371234
    12551252
    12561253

    TYPE_CODE_STRUCT Record

    12571254
    1258 class="doc_text">
    1255 >
    12591256
    12601257

    [STRUCT, ispacked, ...eltty...]

    12611258
    12731270
    12741271

    TYPE_CODE_ARRAY Record

    12751272
    1276 class="doc_text">
    1273 >
    12771274
    12781275

    [ARRAY, numelts, eltty]

    12791276
    12901287
    12911288

    TYPE_CODE_VECTOR Record

    12921289
    1293 class="doc_text">
    1290 >
    12941291
    12951292

    [VECTOR, numelts, eltty]

    12961293
    13071304
    13081305

    TYPE_CODE_X86_FP80 Record

    13091306
    1310 class="doc_text">
    1307 >
    13111308
    13121309

    [X86_FP80]

    13131310
    13191316
    13201317

    TYPE_CODE_FP128 Record

    13211318
    1322 class="doc_text">
    1319 >
    13231320
    13241321

    [FP128]

    13251322
    13311328
    13321329

    TYPE_CODE_PPC_FP128 Record

    13331330
    1334 class="doc_text">
    1331 >
    13351332
    13361333

    [PPC_FP128]

    13371334
    13431340
    13441341

    TYPE_CODE_METADATA Record

    13451342
    1346 class="doc_text">
    1343 >
    13471344
    13481345

    [METADATA]

    13491346
    13521349

    13531350
    13541351
    1352
    1353
    13551354
    13561355

    13571356 CONSTANTS_BLOCK Contents
    13581357
    13591358
    1360 class="doc_text">
    1359 >
    13611360
    13621361

    The CONSTANTS_BLOCK block (id 11) ...

    13631362

    13701369 FUNCTION_BLOCK Contents
    13711370
    13721371
    1373 class="doc_text">
    1372 >
    13741373
    13751374

    The FUNCTION_BLOCK block (id 12) ...

    13761375

    13931392 TYPE_SYMTAB_BLOCK Contents
    13941393
    13951394
    1396 class="doc_text">
    1395 >
    13971396
    13981397

    The TYPE_SYMTAB_BLOCK block (id 13) contains entries which

    13991398 map between module-level named types and their corresponding type
    14001399 indices.
    14011400

    14021401
    1403
    1404
    14051402
    14061403

    TST_CODE_ENTRY Record

    14071404
    1408 class="doc_text">
    1405 >
    14091406
    14101407

    [ENTRY, typeid, ...string...]

    14111408
    14161413

    14171414
    14181415
    1416
    14191417
    14201418
    14211419

    14221420 VALUE_SYMTAB_BLOCK Contents
    14231421
    14241422
    1425 class="doc_text">
    1423 >
    14261424
    14271425

    The VALUE_SYMTAB_BLOCK block (id 14) ...

    14281426

    14351433 METADATA_BLOCK Contents
    14361434
    14371435
    1438 class="doc_text">
    1436 >
    14391437
    14401438

    The METADATA_BLOCK block (id 15) ...

    14411439

    14481446 METADATA_ATTACHMENT Contents
    14491447
    14501448
    1451 class="doc_text">
    1449 >
    14521450
    14531451

    The METADATA_ATTACHMENT block (id 16) ...

    14541452

    14551453
    14561454
    14571455
    1456
    14581457
    14591458
    14601459
    3131
    3232
    3333
    34 class="doc_text">
    34 >
    3535
    3636

    bugpoint narrows down the source of problems in LLVM tools and

    3737 passes. It can be used to debug three types of failures: optimizer crashes,
    5454
    5555
    5656
    57 class="doc_text">
    57 >
    5858
    5959

    bugpoint is designed to be a useful tool without requiring any

    6060 hooks into the LLVM infrastructure at all. It works with any and all LLVM
    6767 debugging a miscompilation where each test of the program (which requires
    6868 executing it) takes a long time.

    6969
    70
    71
    7270
    7371

    7472 Automatic Debugger Selection
    7573
    7674
    77 class="doc_text">
    75 >
    7876
    7977

    bugpoint reads each .bc or .ll file specified on

    8078 the command line and links them together into a single module, called the test
    107105 Crash debugger
    108106
    109107
    110 class="doc_text">
    108 >
    111109
    112110

    If an optimizer or code generator crashes, bugpoint will try as hard

    113111 as it can to reduce the list of passes (for optimizer crashes) and the size of
    132130 Code generator debugger
    133131
    134132
    135 class="doc_text">
    133 >
    136134
    137135

    The code generator debugger attempts to narrow down the amount of code that

    138136 is being miscompiled by the selected code generator. To do this, it takes the
    153151 Miscompilation debugger
    154152
    155153
    156 class="doc_text">
    154 >
    157155
    158156

    The miscompilation debugger works similarly to the code generator debugger.

    159157 It works by splitting the test program into two pieces, running the
    165163
    166164
    167165
    166
    167
    168168
    169169

    170170 Advice for using bugpoint
    171171
    172172
    173173
    174 class="doc_text">
    174 >
    175175
    176176 bugpoint can be a remarkably useful tool, but it sometimes works in
    177177 non-obvious ways. Here are some hints and tips:

    4040
    4141
    4242
    43 class="doc_text">
    43 >
    4444
    4545

    CMake is a cross-platform

    4646 build-generator tool. CMake does not build the project, it generates
    6363
    6464
    6565
    66 class="doc_text">
    66 >
    6767
    6868

    We use here the command-line, non-interactive CMake interface

    6969
    116116
    117117
    118118
    119 class="doc_text">
    119 >
    120120
    121121

    This section explains basic aspects of CMake, mostly for

    122122 explaining those options which you may need on your day-to-day
    164164
    165165
    166166
    167 class="doc_text">
    167 >
    168168
    169169

    Variables customize how the build will be generated. Options are

    170170 boolean variables, with possible values ON/OFF. Options and
    192192
    193193

    cmake -DVARIABLE:TYPE=value path/to/llvm/source

    194194
    195
    196
    197195
    198196
    199197

    200198 Frequently-used CMake variables
    201199
    202200
    203 class="doc_text">
    201 >
    204202
    205203

    Here are listed some of the CMake variables that are used often,

    206204 along with a brief explanation and LLVM-specific notes. For full
    243241 LLVM-specific variables
    244242
    245243
    246 class="doc_text">
    244 >
    247245
    248246
    249247
    LLVM_TARGETS_TO_BUILD:STRING
    356354
    357355
    358356
    357
    358
    359359
    360360

    361361 Executing the test suite
    362362
    363363
    364364
    365 class="doc_text">
    365 >
    366366
    367367

    Testing is performed when the check target is built. For

    368368 instance, if you are using makefiles, execute this command while on
    382382
    383383
    384384
    385 class="doc_text">
    385 >
    386386
    387387

    See this

    388388 wiki page for generic instructions on how to cross-compile
    403403
    404404
    405405
    406 class="doc_text">
    406 >
    407407
    408408

    The most difficult part of adding LLVM to the build of a project

    409409 is to determine the set of LLVM libraries corresponding to the set
    458458
    459459
    460460
    461
    462
    463461
    464462

    465463 Developing LLVM pass out of source
    466464
    467465
    468 class="doc_text">
    466 >
    469467
    470468

    It is possible to develop LLVM passes against installed LLVM.

    471469 An example of project layout provided below:

    517515
    518516
    519517
    518
    519
    520520
    521521

    522522 Compiler/Platform specific topics
    523523
    524524
    525525
    526 class="doc_text">
    526 >
    527527
    528528

    Notes for specific compilers and/or platforms.

    529
    530
    531529
    532530

    533531 Microsoft Visual C++
    534532
    535533
    536 class="doc_text">
    534 >
    537535
    538536
    539537
    LLVM_COMPILER_JOBS:STRING
    545543
    546544
    547545
    546
    547
    548548
    549549
    550550
    131131
    132132
    133133
    134 class="doc_text">
    134 >
    135135
    136136

    The LLVM target-independent code generator is a framework that provides a

    137137 suite of reusable components for translating the LLVM internal representation
    187187 depend on the target-description and machine code representation classes,
    188188 ensuring that it is portable.

    189189
    190
    191
    192190
    193191

    194192 Required components in the code generator
    195193
    196194
    197 class="doc_text">
    195 >
    198196
    199197

    The two pieces of the LLVM code generator are the high-level interface to the

    200198 code generator and the set of reusable components that can be used to build
    226224 The high-level design of the code generator
    227225
    228226
    229 class="doc_text">
    227 >
    230228
    231229

    The LLVM target-independent code generator is designed to support efficient

    232230 and quality code generation for standard register-based microprocessors.
    300298 Using TableGen for target description
    301299
    302300
    303 class="doc_text">
    301 >
    304302
    305303

    The target description classes require a detailed description of the target

    306304 architecture. These target descriptions often have a large amount of common
    323321
    324322
    325323
    324
    325
    326326
    327327

    328328 Target description classes
    329329
    330330
    331331
    332 class="doc_text">
    332 >
    333333
    334334

    The LLVM target description classes (located in the

    335335 include/llvm/Target directory) provide an abstract description of
    345345 TargetMachine class provides accessors
    346346 that should be implemented by the target.

    347347
    348
    349
    350348
    351349

    352350 The TargetMachine class
    353351
    354352
    355 class="doc_text">
    353 >
    356354
    357355

    The TargetMachine class provides virtual methods that are used to

    358356 access the target-specific implementations of the various target description
    372370 The TargetData class
    373371
    374372
    375 class="doc_text">
    373 >
    376374
    377375

    The TargetData class is the only required target description class,

    378376 and it is the only class that is not extensible (you cannot derived a new
    388386 The TargetLowering class
    389387
    390388
    391 class="doc_text">
    389 >
    392390
    393391

    The TargetLowering class is used by SelectionDAG based instruction

    394392 selectors primarily to describe how LLVM code should be lowered to
    414412 The TargetRegisterInfo class
    415413
    416414
    417 class="doc_text">
    415 >
    418416
    419417

    The TargetRegisterInfo class is used to describe the register file

    420418 of the target and any interactions between the registers.

    448446 The TargetInstrInfo class
    449447
    450448
    451 class="doc_text">
    449 >
    452450
    453451

    The TargetInstrInfo class is used to describe the machine

    454452 instructions supported by the target. It is essentially an array of
    466464 The TargetFrameInfo class
    467465
    468466
    469 class="doc_text">
    467 >
    470468
    471469

    The TargetFrameInfo class is used to provide information about the

    472470 stack frame layout of the target. It holds the direction of stack growth, the
    482480 The TargetSubtarget class
    483481
    484482
    485 class="doc_text">
    483 >
    486484
    487485

    The TargetSubtarget class is used to provide information about the

    488486 specific chip set being targeted. A sub-target informs code generation of
    498496 The TargetJITInfo class
    499497
    500498
    501 class="doc_text">
    499 >
    502500
    503501

    The TargetJITInfo class exposes an abstract interface used by the

    504502 Just-In-Time code generator to perform target-specific activities, such as
    508506
    509507
    510508
    509
    510
    511511
    512512

    513513 Machine code description classes
    514514
    515515
    516516
    517 class="doc_text">
    517 >
    518518
    519519

    At the high-level, LLVM code is translated to a machine specific

    520520 representation formed out of
    527527 SSA representation for machine code, as well as a register allocated, non-SSA
    528528 form.

    529529
    530
    531
    532530
    533531

    534532 The MachineInstr class
    535533
    536534
    537 class="doc_text">
    535 >
    538536
    539537

    Target machine instructions are represented as instances of the

    540538 MachineInstr class. This class is an extremely abstract way of
    575573

    Also if the first operand is a def, it is easier to create

    576574 instructions whose only def is the first operand.

    577575
    578
    579
    580576
    581577

    582578 Using the MachineInstrBuilder.h functions
    583579
    584580
    585 class="doc_text">
    581 >
    586582
    587583

    Machine instructions are created by using the BuildMI functions,

    588584 located in the include/llvm/CodeGen/MachineInstrBuilder.h file. The
    633629 Fixed (preassigned) registers
    634630
    635631
    636 class="doc_text">
    632 >
    637633
    638634

    One important issue that the code generator needs to be aware of is the

    639635 presence of fixed registers. In particular, there are often places in the
    705701 Machine code in SSA form
    706702
    707703
    708 class="doc_text">
    704 >
    709705
    710706

    MachineInstr's are initially selected in SSA-form, and are

    711707 maintained in SSA-form until register allocation happens. For the most part,
    718714
    719715
    720716
    717
    718
    721719
    722720

    723721 The MachineBasicBlock class
    724722
    725723
    726 class="doc_text">
    724 >
    727725
    728726

    The MachineBasicBlock class contains a list of machine instructions

    729727 (MachineInstr instances). It roughly
    740738 The MachineFunction class
    741739
    742740
    743 class="doc_text">
    741 >
    744742
    745743

    The MachineFunction class contains a list of machine basic blocks

    746744 (MachineBasicBlock instances). It
    753751
    754752
    755753
    754
    756755
    757756
    758757

    760759
    761760
    762761
    763 class="doc_text">
    762 >
    764763
    765764

    766765 The MC Layer is used to represent and process code at the raw machine code
    778777 in this manual.
    779778

    780779
    781
    782
    783
    784780
    785781

    786782 The MCStreamer API
    787783
    788784
    789 class="doc_text">
    785 >
    790786
    791787

    792788 MCStreamer is best thought of as an assembler API. It is an abstract API which
    820816 The MCContext class
    821817
    822818
    823 class="doc_text">
    819 >
    824820
    825821

    826822 The MCContext class is the owner of a variety of uniqued data structures at the
    835831 The MCSymbol class
    836832
    837833
    838 class="doc_text">
    834 >
    839835
    840836

    841837 The MCSymbol class represents a symbol (aka label) in the assembly file. There
    867863 The MCSection class
    868864
    869865
    870 class="doc_text">
    866 >
    871867
    872868

    873869 The MCSection class represents an object-file specific section. It is subclassed
    885881 The MCInst class
    886882
    887883
    888 class="doc_text">
    884 >
    889885
    890886

    891887 The MCInst class is a target-independent representation of an instruction. It
    903899
    904900
    905901
    902
    906903
    907904
    908905

    910907
    911908
    912909
    913 class="doc_text">
    910 >
    914911
    915912

    This section documents the phases described in the

    916913 high-level design of the code generator.
    917914 It explains how they work and some of the rationale behind their design.

    918915
    919
    920
    921916
    922917

    923918 Instruction Selection
    924919
    925920
    926 class="doc_text">
    921 >
    927922
    928923

    Instruction Selection is the process of translating LLVM code presented to

    929924 the code generator into target-specific machine instructions. There are
    935930 selector to be generated from these .td files, though currently
    936931 there are still things that require custom C++ code.

    937932
    938
    939
    940933
    941934

    942935 Introduction to SelectionDAGs
    943936
    944937
    945 class="doc_text">
    938 >
    946939
    947940

    The SelectionDAG provides an abstraction for code representation in a way

    948941 that is amenable to instruction selection using automatic techniques
    1004997 SelectionDAG Instruction Selection Process
    1005998
    1006999
    1007 class="doc_text">
    1000 >
    10081001
    10091002

    SelectionDAG-based instruction selection consists of the following steps:

    10101003
    10851078 Initial SelectionDAG Construction
    10861079
    10871080
    1088 class="doc_text">
    1081 >
    10891082
    10901083

    The initial SelectionDAG is naïvely peephole expanded from the LLVM

    10911084 input by the SelectionDAGLowering class in the
    11051098 SelectionDAG LegalizeTypes Phase
    11061099
    11071100
    1108 class="doc_text">
    1101 >
    11091102
    11101103

    The Legalize phase is in charge of converting a DAG to only use the types

    11111104 that are natively supported by the target.

    11381131 SelectionDAG Legalize Phase
    11391132
    11401133
    1141 class="doc_text">
    1134 >
    11421135
    11431136

    The Legalize phase is in charge of converting a DAG to only use the

    11441137 operations that are natively supported by the target.

    11721165
    11731166
    11741167
    1175 class="doc_text">
    1168 >
    11761169
    11771170

    The SelectionDAG optimization phase is run multiple times for code

    11781171 generation, immediately after the DAG is built and once after each
    12061199 SelectionDAG Select Phase
    12071200
    12081201
    1209 class="doc_text">
    1202 >
    12101203
    12111204

    The Select phase is the bulk of the target-specific code for instruction

    12121205 selection. This phase takes a legal SelectionDAG as input, pattern matches
    13671360 SelectionDAG Scheduling and Formation Phase
    13681361
    13691362
    1370 class="doc_text">
    1363 >
    13711364
    13721365

    The scheduling phase takes the DAG of target instructions from the selection

    13731366 phase and assigns an order. The scheduler can pick an order depending on
    13881381 Future directions for the SelectionDAG
    13891382
    13901383
    1391 class="doc_text">
    1384 >
    13921385
    13931386
    13941387
  • Optional function-at-a-time selection.
  • 13981391
    13991392
    14001393
    1394
    1395
    14011396
    14021397

    14031398 SSA-based Machine Code Optimizations
    14041399
    1405 class="doc_text">

    To Be Written

    1400 >

    To Be Written

    14061401
    14071402
    14081403

    14091404 Live Intervals
    14101405
    14111406
    1412 class="doc_text">
    1407 >
    14131408
    14141409

    Live Intervals are the ranges (intervals) where a variable is live.

    14151410 They are used by some register allocator passes to
    14171412 register are live at the same point in the program (i.e., they conflict).
    14181413 When this situation occurs, one virtual register must be spilled.

    14191414
    1420
    1421
    14221415
    14231416

    14241417 Live Variable Analysis
    14251418
    14261419
    1427 class="doc_text">
    1420 >
    14281421
    14291422

    The first step in determining the live intervals of variables is to calculate

    14301423 the set of registers that are immediately dead after the instruction (i.e.,
    14701463 Live Intervals Analysis
    14711464
    14721465
    1473 class="doc_text">
    1466 >
    14741467
    14751468

    We now have the information available to perform the live intervals analysis

    14761469 and build the live intervals themselves. We start off by numbering the basic
    14851478
    14861479
    14871480
    1481
    1482
    14881483
    14891484

    14901485 Register Allocation
    14911486
    14921487
    1493 class="doc_text">
    1488 >
    14941489
    14951490

    The Register Allocation problem consists in mapping a program

    14961491 Pv, that can use an unbounded number of virtual registers,
    15001495 accommodate all the virtual registers, some of them will have to be mapped
    15011496 into memory. These virtuals are called spilled virtuals.

    15021497
    1503
    1504
    15051498
    15061499
    15071500

    15081501 How registers are represented in LLVM
    15091502
    15101503
    1511 class="doc_text">
    1504 >
    15121505
    15131506

    In LLVM, physical registers are denoted by integer numbers that normally

    15141507 range from 1 to 1023. To see how this numbering is defined for a particular
    16211614 Mapping virtual registers to physical registers
    16221615
    16231616
    1624 class="doc_text">
    1617 >
    16251618
    16261619

    There are two ways to map virtual registers to physical registers (or to

    16271620 memory slots). The first way, that we will call direct mapping, is
    16711664 Handling two address instructions
    16721665
    16731666
    1674 class="doc_text">
    1667 >
    16751668
    16761669

    With very rare exceptions (e.g., function calls), the LLVM machine code

    16771670 instructions are three address instructions. That is, each instruction is
    17071700 The SSA deconstruction phase
    17081701
    17091702
    1710 class="doc_text">
    1703 >
    17111704
    17121705

    An important transformation that happens during register allocation is called

    17131706 the SSA Deconstruction Phase. The SSA form simplifies many analyses
    17311724 Instruction folding
    17321725
    17331726
    1734 class="doc_text">
    1727 >
    17351728
    17361729

    Instruction folding is an optimization performed during register

    17371730 allocation that removes unnecessary copy instructions. For instance, a
    17681761 Built in register allocators
    17691762
    17701763
    1771 class="doc_text">
    1764 >
    17721765
    17731766

    The LLVM infrastructure provides the application developer with three

    17741767 different register allocators:

    18051798
    18061799
    18071800
    1801
    1802
    18081803
    18091804

    18101805 Prolog/Epilog Code Insertion
    18111806
    1812 class="doc_text">

    To Be Written

    1807 >

    To Be Written

    18131808
    18141809

    18151810 Late Machine Code Optimizations
    18161811
    1817 class="doc_text">

    To Be Written

    1812 >

    To Be Written

    18181813
    18191814
    18201815

    18211816 Code Emission
    18221817
    18231818
    1824 class="doc_text">
    1819 >
    18251820
    18261821

    The code emission step of code generation is responsible for lowering from

    18271822 the code generator abstractions (like
    18801875
    18811876
    18821877
    1878
    18831879
    18841880
    18851881

    18871883
    18881884
    18891885
    1890 class="doc_text">
    1886 >
    18911887
    18921888

    Though you're probably reading this because you want to write or maintain a

    18931889 compiler backend, LLVM also fully supports building a native assemblers too.
    18961892 part of the manual and repetitive data entry can be factored and shared with the
    18971893 compiler.

    18981894
    1899
    1900
    19011895
    19021896

    Instruction Parsing

    19031897
    1904 class="doc_text">

    To Be Written

    1898 >

    To Be Written

    19051899
    19061900
    19071901
    19091903 Instruction Alias Processing
    19101904
    19111905
    1912 class="doc_text">
    1906 >
    19131907

    Once the instruction is parsed, it enters the MatchInstructionImpl function.

    19141908 The MatchInstructionImpl function performs alias processing and then does
    19151909 actual matching.

    19221916 meets the needs of your instruction, because it will allow a more concise
    19231917 description.

    19241918
    1925
    1926
    19271919
    19281920

    Mnemonic Aliases

    19291921
    1930 class="doc_text">
    1922 >
    19311923
    19321924

    The first phase of alias processing is simple instruction mnemonic

    19331925 remapping for classes of instructions which are allowed with two different
    19671959
    19681960

    Instruction Aliases

    19691961
    1970 class="doc_text">
    1962 >
    19711963
    19721964

    The most general phase of alias processing occurs while matching is

    19731965 happening: it provides new forms for the matcher to match along with a specific
    20282020
    20292021
    20302022
    2031
    2023
    20322024
    20332025
    20342026

    Instruction Matching

    20352027
    2036

    To Be Written

    2037
    2038
    2039
    2028

    To Be Written

    2029
    2030
    20402031
    20412032
    20422033

    20442035
    20452036
    20462037
    2047 class="doc_text">
    2038 >
    20482039
    20492040

    This section of the document explains features or design decisions that are

    20502041 specific to the code generator for a particular target. First we start
    20512042 with a table that summarizes what features are supported by each target.

    20522043
    2053
    2054
    20552044
    20562045

    20572046 Target Feature Matrix
    20582047
    20592048
    2060 class="doc_text">
    2049 >
    20612050
    20622051

    Note that this table does not include the C backend or Cpp backends, since

    20632052 they do not use the target independent code generator infrastructure. It also
    22282217
    22292218
    22302219 2231
    2232 22332220 22342221

    Is Generally Reliable

    22352222 2236 class="doc_text"> 2223 > 22372224

    This box indicates whether the target is considered to be production quality. 22382225 This indicates that the target has been used as a static compiler to 22392226 compile large amounts of code by a variety of different people and is in 22432230 22442231

    Assembly Parser

    22452232 2246 class="doc_text"> 2233 > 22472234

    This box indicates whether the target supports parsing target specific .s 22482235 files by implementing the MCAsmParser interface. This is required for llvm-mc 22492236 to be able to act as a native assembler and is required for inline assembly 22552242 22562243

    Disassembler

    22572244 2258 class="doc_text"> 2245 > 22592246

    This box indicates whether the target supports the MCDisassembler API for 22602247 disassembling machine opcode bytes into MCInst's.

    22612248 22642251 22652252

    Inline Asm

    22662253 2267 class="doc_text"> 2254 > 22682255

    This box indicates whether the target supports most popular inline assembly 22692256 constraints and modifiers.

    22702257 22762263 22772264

    JIT Support

    22782265 2279 class="doc_text"> 2266 > 22802267

    This box indicates whether the target supports the JIT compiler through 22812268 the ExecutionEngine interface.

    22822269 22882275 22892276

    .o File Writing

    22902277 2291 class="doc_text"> 2278 > 22922279 22932280

    This box indicates whether the target supports writing .o files (e.g. MachO, 22942281 ELF, and/or COFF) files directly from the target. Note that the target also 23042291 23052292

    Tail Calls

    23062293 2307 class="doc_text"> 2294 > 23082295 23092296

    This box indicates whether the target supports guaranteed tail calls. These 23102297 are calls marked "tail" and use the fastcc 23132300 23142301

    23152302 2316 2317 2303
    23182304 23192305 23202306

    23212307 Tail call optimization 23222308

    23232309 2324 class="doc_text"> 2310 > 23252311 23262312

    Tail call optimization, callee reusing the stack of the caller, is currently 23272313 supported on x86/x86-64 and PowerPC. It is performed if:

    23872373 Sibling call optimization 23882374 23892375 2390 class="doc_text"> 2376 > 23912377 23922378

    Sibling call optimization is a restricted form of tail call optimization. 23932379 Unlike tail call optimization described in the previous section, it can be 24312417 The X86 backend 24322418 24332419 2434 class="doc_text"> 2420 > 24352421 24362422

    The X86 code generator lives in the lib/Target/X86 directory. This 24372423 code generator is capable of targeting a variety of x86-32 and x86-64 24382424 processors, and includes support for ISA extensions such as MMX and SSE.

    24392425 2440
    2441 24422426 24432427

    24442428 X86 Target Triples supported 24452429

    24462430 2447 class="doc_text"> 2431 > 24482432 24492433

    The following are the known target triples that are supported by the X86 24502434 backend. This is not an exhaustive list, and it would be useful to add those 24742458 24752459 24762460 2477 class="doc_text"> 2461 > 24782462 24792463

    The following target-specific calling conventions are known to backend:

    24802464 24932477 Representing X86 addressing modes in MachineInstrs 24942478 24952479 2496 class="doc_text"> 2480 > 24972481 24982482

    The x86 has a very flexible way of accessing memory. It is capable of 24992483 forming memory addresses of the following expression directly in integer 25302514 X86 address spaces supported 25312515 25322516 2533 class="doc_text"> 2517 > 25342518 25352519

    x86 has a feature which provides 25362520 the ability to perform loads and stores to different address spaces 25752559 Instruction naming 25762560 25772561 2578 class="doc_text"> 2562 > 25792563 25802564

    An instruction name consists of the base name, a default operand size, and a 25812565 a character per operand with an optional special size. For example:

    25912575 25922576 25932577 2578 2579 25942580 25952581

    25962582 The PowerPC backend 25972583

    25982584 2599 class="doc_text"> 2585 > 26002586 26012587

    The PowerPC code generator lives in the lib/Target/PowerPC directory. The 26022588 code generation is retargetable to several variations or subtargets of 26032589 the PowerPC ISA; including ppc32, ppc64 and altivec.

    26042590 2605 2606 26072591 26082592

    26092593 LLVM PowerPC ABI 26102594

    26112595 2612 class="doc_text"> 2596 > 26132597 26142598

    LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC 26152599 relative (PIC) or static addressing for accessing global values, so no TOC 26292613 Frame Layout 26302614 26312615 2632 class="doc_text"> 2616 > 26332617 26342618

    The size of a PowerPC frame is usually fixed for the duration of a 26352619 function's invocation. Since the frame is fixed size, all references 27762760 Prolog/Epilog 27772761 27782762 2779 class="doc_text"> 2763 > 27802764 27812765

    The llvm prolog and epilog are the same as described in the PowerPC ABI, with 27822766 the following exceptions. Callee saved registers are spilled after the frame 27932777 Dynamic Allocation 27942778 27952779 2796 class="doc_text"> 2780 > 27972781 27982782

    TODO - More to come.

    27992783 28002784 28012785 2786 2787 2788 28022789 28032790 28042791
    +61
    -34
    docs/CodingStandards.html less more
    8787
    8888
    8989
    90 class="doc_text">
    90 >
    9191
    9292

    This document attempts to describe a few coding standards that are being used

    9393 in the LLVM source tree. Although no coding standards should be regarded as
    121121
    122122
    123123
    124
    125
    124126
    125127

    126128 Source Code Formatting
    127129
    128130
    131
    132
    129133
    130134

    131135 Commenting
    132136
    133137
    134 class="doc_text">
    138 >
    135139
    136140

    Comments are one critical part of readability and maintainability. Everyone

    137141 knows they should comment, so should you. When writing comments, write them as
    140144 comment our code more than we do, there are a few very critical places that
    141145 documentation is very useful:

    142146
    143 <b>File Headers>
    147 <h5>File Headers>
    148
    149
    144150
    145151

    Every source file should have a header on it that describes the basic

    146152 purpose of the file. If a file does not have a header, it should not be
    183189 tricky is going on, a reference to the paper where it is published should be
    184190 included, as well as any notes or "gotchas" in the code to watch out for.

    185191
    186 <b>Class overviews>
    192 </div>
    193
    194
    Class overviews
    187195
    188196

    Classes are one fundamental part of a good object oriented design. As such,

    189197 a class definition should have a comment block that explains what the class is
    192200 something sane goes a long ways towards avoiding writing documentation.

    193201
    194202
    195 <b>Method information>
    203 <h5>Method information>
    204
    205
    196206
    197207

    Methods defined in a class (as well as any global functions) should also be

    198208 documented properly. A quick note about what it does and a description of the
    206216
    207217
    208218
    219
    220
    209221
    210222

    211223 Comment Formatting
    212224
    213225
    214 class="doc_text">
    226 >
    215227
    216228

    In general, prefer C++ style (//) comments. They take less space,

    217229 require less typing, don't have nesting problems, etc. There are a few cases
    236248 #include Style
    237249
    238250
    239 class="doc_text">
    251 >
    240252
    241253

    Immediately after the header file comment (and

    242254 include guards if working on a header file), the
    276288 Source Code Width
    277289
    278290
    279 class="doc_text">
    291 >
    280292
    281293

    Write your code to fit within 80 columns of text. This helps those of us who

    282294 like to print out code and look at your code in an xterm without resizing
    301313 Use Spaces Instead of Tabs
    302314
    303315
    304 class="doc_text">
    316 >
    305317
    306318

    In all cases, prefer spaces to tabs in source files. People have different

    307319 preferred indentation levels, and different styles of indentation that they
    322334 Indent Code Consistently
    323335
    324336
    325 class="doc_text">
    337 >
    326338
    327339

    Okay, in your first year of programming you were told that indentation is

    328340 important. If you didn't believe and internalize this then, now is the time.
    330342
    331343
    332344
    345
    333346
    334347
    335348

    336349 Compiler Issues
    337350
    338351
    352
    339353
    340354
    341355

    342356 Treat Compiler Warnings Like Errors
    343357
    344358
    345 class="doc_text">
    359 >
    346360
    347361

    If your code has compiler warnings in it, something is wrong — you

    348362 aren't casting values correctly, your have "questionable" constructs in your
    396410 Write Portable Code
    397411
    398412
    399 class="doc_text">
    413 >
    400414
    401415

    In almost all cases, it is possible and within reason to write completely

    402416 portable code. If there are cases where it isn't possible to write portable
    414428

    415429 Do not use RTTI or Exceptions
    416430
    417 class="doc_text">
    431 >
    418432
    419433

    In an effort to reduce code and executable size, LLVM does not use RTTI

    420434 (e.g. dynamic_cast<>) or exceptions. These two language features
    435449

    436450 Use of class and struct Keywords
    437451
    438 class="doc_text">
    452 >
    439453
    440454

    In C++, the class and struct keywords can be used almost

    441455 interchangeably. The only difference is when they are used to declare a class:
    450464 all members are public and the type is a C++
    451465 POD type, in
    452466 which case struct is allowed.

    467
    468
    469
    470
    453471
    454472
    455473
    459477
    460478
    461479
    480
    462481
    463482
    464483

    466485
    467486
    468487
    488
    469489
    470490
    471491

    472492 A Public Header File is a Module
    473493
    474494
    475 class="doc_text">
    495 >
    476496
    477497

    C++ doesn't do too well in the modularity department. There is no real

    478498 encapsulation or data hiding (unless you use expensive protocol classes), but it
    502522 #include as Little as Possible
    503523
    504524
    505 class="doc_text">
    525 >
    506526
    507527

    #include hurts compile time performance. Don't do it unless you

    508528 have to, especially in header files.

    531551 Keep "Internal" Headers Private
    532552
    533553
    534 class="doc_text">
    554 >
    535555
    536556

    Many modules have a complex implementation that causes them to use more than

    537557 one implementation (.cpp) file. It is often tempting to put the
    552572 Use Early Exits and continue to Simplify Code
    553573
    554574
    555 class="doc_text">
    575 >
    556576
    557577

    When reading code, keep in mind how much state and how many previous

    558578 decisions have to be remembered by the reader to understand a block of code.
    661681 Don't use else after a return
    662682
    663683
    664 class="doc_text">
    684 >
    665685
    666686

    For similar reasons above (reduction of indentation and easier reading),

    667687 please do not use 'else' or 'else if' after something that
    744764 Turn Predicate Loops into Predicate Functions
    745765
    746766
    747 class="doc_text">
    767 >
    748768
    749769

    It is very common to write small loops that just compute a boolean value.

    750770 There are a number of ways that people commonly write these, but an example of
    801821
    802822
    803823
    824
    804825
    805826
    806827

    808829
    809830
    810831
    832
    811833
    812834
    813835

    816838
    817839
    818840
    819 class="doc_text">
    841 >
    820842
    821843

    Poorly-chosen names can mislead the reader and cause bugs. We cannot stress

    822844 enough how important it is to use descriptive names. Pick names that
    899921 Assert Liberally
    900922
    901923
    902 class="doc_text">
    924 >
    903925
    904926

    Use the "assert" macro to its fullest. Check all of your

    905927 preconditions and assumptions, you never know when a bug (not necessarily even
    10021024 Do Not Use 'using namespace std'
    10031025
    10041026
    1005 class="doc_text">
    1027 >
    10061028
    10071029

    In LLVM, we prefer to explicitly prefix all identifiers from the standard

    10081030 namespace with an "std::" prefix, rather than rely on
    10421064
    10431065
    10441066
    1045 class="doc_text">
    1067 >
    10461068
    10471069

    If a class is defined in a header file and has a v-table (either it has

    10481070 virtual methods or it derives from classes with virtual methods), it must
    10581080 Don't evaluate end() every time through a loop
    10591081
    10601082
    1061 class="doc_text">
    1083 >
    10621084
    10631085

    Because C++ doesn't have a standard "foreach" loop (though it can be

    10641086 emulated with macros and may be coming in C++'0x) we end up writing a lot of
    11201142 #include <iostream> is Forbidden
    11211143
    11221144
    1123 class="doc_text">
    1145 >
    11241146
    11251147

    The use of #include <iostream> in library files is

    11261148 hereby forbidden. The primary reason for doing this is to
    11551177 Use raw_ostream
    11561178
    11571179
    1158 class="doc_text">
    1180 >
    11591181
    11601182

    LLVM includes a lightweight, simple, and efficient stream implementation

    11611183 in llvm/Support/raw_ostream.h, which provides all of the common
    11751197 Avoid std::endl
    11761198
    11771199
    1178 class="doc_text">
    1200 >
    11791201
    11801202

    The std::endl modifier, when used with iostreams outputs a

    11811203 newline to the output stream specified. In addition to doing this, however, it
    11931215
    11941216
    11951217
    1218
    11961219
    11971220
    11981221

    12001223
    12011224
    12021225
    1226
    1227
    12031228

    This section describes preferred low-level formatting guidelines along with

    12041229 reasoning on why we prefer them.

    12051230
    12081233 Spaces Before Parentheses
    12091234
    12101235
    1211 class="doc_text">
    1236 >
    12121237
    12131238

    We prefer to put a space before an open parenthesis only in control flow

    12141239 statements, but not in normal function call expressions and function-like
    12661291 Prefer Preincrement
    12671292
    12681293
    1269 class="doc_text">
    1294 >
    12701295
    12711296

    Hard fast rule: Preincrement (++X) may be no slower than

    12721297 postincrement (X++) and could very well be a lot faster than it. Use
    12861311 Namespace Indentation
    12871312
    12881313
    1289 class="doc_text">
    1314 >
    12901315
    12911316

    12921317 In general, we strive to reduce indentation wherever possible. This is useful
    13741399 Anonymous Namespaces
    13751400
    13761401
    1377 class="doc_text">
    1402 >
    13781403
    13791404

    After talking about namespaces in general, you may be wondering about

    13801405 anonymous namespaces in particular.
    14541479
    14551480
    14561481
    1457
    1482
    1483
    1484
    14581485
    14591486
    14601487

    14621489
    14631490
    14641491
    1465 class="doc_text">
    1492 >
    14661493
    14671494

    A lot of these comments and recommendations have been culled for other

    14681495 sources. Two particularly important books for our work are:

    +5
    -5
    docs/CommandGuide/index.html less more
    1010 LLVM Command Guide
    1111
    1212
    13 class="doc_text">
    13 >
    1414
    1515

    These documents are HTML versions of the man pages

    1616 for all of the LLVM tools. These pages describe how to use the LLVM commands
    2727
    2828
    2929
    30 class="doc_text">
    30 >
    3131
    3232
    3333
    8484
    8585
    8686
    87 class="doc_text">
    87 >
    8888
    8989
    9090
  • llvm-gcc -
  • 104104
    105105
    106106
    107 class="doc_text">
    107 >
    108108
    109109
    110110
    127127
    128128
    129129
    130 class="doc_text">
    130 >
    131131
    132132
    133133
  • FileCheck -
  • +47
    -50
    docs/CommandLine.html less more
    104104
    105105
    106106
    107 class="doc_text">
    107 >
    108108
    109109

    This document describes the CommandLine argument processing library. It will

    110110 show you how to use it, and what it can do. The CommandLine library uses a
    188188
    189189
    190190
    191 class="doc_text">
    191 >
    192192
    193193

    This section of the manual runs through a simple CommandLine'ification of a

    194194 basic compiler tool. This is intended to show you how to jump into using the
    320320
    321321

    ... indicating that an input filename is expected.

    322322
    323
    324
    325323
    326324

    327325 Boolean Arguments
    328326
    329327
    330 class="doc_text">
    328 >
    331329
    332330

    In addition to input and output filenames, we would like the compiler example

    333331 to support three boolean flags: "-f" to force writing binary output to
    409407 Argument Aliases
    410408
    411409
    412 class="doc_text">
    410 >
    413411
    414412

    So far, the example works well, except for the fact that we need to check the

    415413 quiet condition like this now:

    460458 possibilities
    461459
    462460
    463 class="doc_text">
    461 >
    464462
    465463

    So far we have seen how the CommandLine library handles builtin types like

    466464 std::string, bool and int, but how does it handle
    570568 Named Alternatives
    571569
    572570
    573 class="doc_text">
    571 >
    574572
    575573

    Another useful argument form is a named alternative style. We shall use this

    576574 style in our compiler to specify different debug levels that can be used.
    632630 Parsing a list of options
    633631
    634632
    635 class="doc_text">
    633 >
    636634
    637635

    Now that we have the standard run-of-the-mill argument types out of the way,

    638636 lets get a little wild and crazy. Lets say that we want our optimizer to accept
    702700 Collecting options as a set of flags
    703701
    704702
    705 class="doc_text">
    703 >
    706704
    707705

    Instead of collecting sets of options in a list, it is also possible to

    708706 gather information for enum values in a bit vector. The representation used by
    761759 Adding freeform text to help output
    762760
    763761
    764 class="doc_text">
    762 >
    765763
    766764

    As our program grows and becomes more mature, we may decide to put summary

    767765 information about what it does into the help output. The help output is styled
    799797
    800798
    801799
    800
    802801
    803802
    804803

    806805
    807806
    808807
    809 class="doc_text">
    808 >
    810809
    811810

    Now that you know the basics of how to use the CommandLine library, this

    812811 section will give you the detailed information you need to tune how command line
    813812 options work, as well as information on more "advanced" command line option
    814813 processing capabilities.

    815814
    816
    817
    818815
    819816

    820817 Positional Arguments
    821818
    822819
    823 class="doc_text">
    820 >
    824821
    825822

    Positional arguments are those arguments that are not named, and are not

    826823 specified with a hyphen. Positional arguments should be used when an option is
    853850 are defined in multiple .cpp files. The fix for this problem is simply to
    854851 define all of your positional arguments in one .cpp file.

    855852
    856
    857
    858
    859853
    860854

    861855 Specifying positional options with hyphens
    862856
    863857
    864 class="doc_text">
    858 >
    865859
    866860

    Sometimes you may want to specify a value to your positional argument that

    867861 starts with a hyphen (for example, searching for '-foo' in a file). At
    897891

    898892 Determining absolute position with getPosition()
    899893
    900 class="doc_text">
    894 >
    901895

    Sometimes an option can affect or modify the meaning of another option. For

    902896 example, consider gcc's -x LANG option. This tells
    903897 gcc to ignore the suffix of subsequent positional arguments and force
    957951 The cl::ConsumeAfter modifier
    958952
    959953
    960 class="doc_text">
    954 >
    961955
    962956

    The cl::ConsumeAfter formatting option is

    963957 used to construct programs that use "interpreter style" option processing. With
    1005999
    10061000
    10071001
    1002
    1003
    10081004
    10091005

    10101006 Internal vs External Storage
    10111007
    10121008
    1013 class="doc_text">
    1009 >
    10141010
    10151011

    By default, all command line options automatically hold the value that they

    10161012 parse from the command line. This is very convenient in the common case,
    10791075 Option Attributes
    10801076
    10811077
    1082 class="doc_text">
    1078 >
    10831079
    10841080

    This section describes the basic attributes that you can specify on

    10851081 options.

    11691165 Option Modifiers
    11701166
    11711167
    1172 class="doc_text">
    1168 >
    11731169
    11741170

    Option modifiers are the flags and expressions that you pass into the

    11751171 constructors for cl::opt and
    11951191 that are the most useful in practice and the most common, which mean that you
    11961192 usually shouldn't have to worry about these.

    11971193
    1198
    1199
    12001194
    12011195

    12021196 Hiding an option from -help output
    12031197
    12041198
    1205 class="doc_text">
    1199 >
    12061200
    12071201

    The cl::NotHidden, cl::Hidden, and

    12081202 cl::ReallyHidden modifiers are used to control whether or not an option
    12341228 allowed
    12351229
    12361230
    1237 class="doc_text">
    1231 >
    12381232
    12391233

    This group of options is used to control how many time an option is allowed

    12401234 (or required) to be specified on the command line of your program. Specifying a
    12821276 Controlling whether or not a value must be specified
    12831277
    12841278
    1285 class="doc_text">
    1279 >
    12861280
    12871281

    This group of options is used to control whether or not the option allows a

    12881282 value to be present. In the case of the CommandLine library, a value is either
    13311325 Controlling other formatting options
    13321326
    13331327
    1334 class="doc_text">
    1328 >
    13351329
    13361330

    The formatting option group is used to specify that the command line option

    13371331 has special abilities and is otherwise different from other command line
    14121406 Miscellaneous option modifiers
    14131407
    14141408
    1415 class="doc_text">
    1409 >
    14161410
    14171411

    The miscellaneous option modifiers are the only flags where you can specify

    14181412 more than one flag from the set: they are not mutually exclusive. These flags
    14561450 Response files
    14571451
    14581452
    1459 class="doc_text">
    1453 >
    14601454
    14611455

    Some systems, such as certain variants of Microsoft Windows and

    14621456 some older Unices have a relatively low limit on command-line
    14731467
    14741468
    14751469
    1470
    14761471
    14771472
    14781473

    14791474 Top-Level Classes and Functions
    14801475
    14811476
    1482 class="doc_text">
    1477 >
    14831478
    14841479

    Despite all of the built-in flexibility, the CommandLine option library

    14851480 really only consists of one function (
    14891484 href="#cl::alias">cl::alias. This section describes these three
    14901485 classes in detail.

    14911486
    1492
    1493
    14941487
    14951488

    14961489 The cl::ParseCommandLineOptions
    14971490 function
    14981491
    14991492
    1500 class="doc_text">
    1493 >
    15011494
    15021495

    The cl::ParseCommandLineOptions function is designed to be called

    15031496 directly from main, and is used to fill in the values of all of the
    15181511 function
    15191512
    15201513
    1521 class="doc_text">
    1514 >
    15221515
    15231516

    The cl::ParseEnvironmentOptions function has mostly the same effects

    15241517 as
    15551548 function
    15561549
    15571550
    1558 class="doc_text">
    1551 >
    15591552
    15601553

    The cl::SetVersionPrinter function is designed to be called

    15611554 directly from main and before
    15751568 The cl::opt class
    15761569
    15771570
    1578 class="doc_text">
    1571 >
    15791572
    15801573

    The cl::opt class is the class used to represent scalar command line

    15811574 options, and is the one used most of the time. It is a templated class which
    16101603 The cl::list class
    16111604
    16121605
    1613 class="doc_text">
    1606 >
    16141607
    16151608

    The cl::list class is the class used to represent a list of command

    16161609 line options. It too is a templated class which can take up to three
    16371630 The cl::bits class
    16381631
    16391632
    1640 class="doc_text">
    1633 >
    16411634
    16421635

    The cl::bits class is the class used to represent a list of command

    16431636 line options in the form of a bit vector. It is also a templated class which
    16621655 The cl::alias class
    16631656
    16641657
    1665 class="doc_text">
    1658 >
    16661659
    16671660

    The cl::alias class is a nontemplated class that is used to form

    16681661 aliases for other arguments.

    16851678 The cl::extrahelp class
    16861679
    16871680
    1688 class="doc_text">
    1681 >
    16891682
    16901683

    The cl::extrahelp class is a nontemplated class that allows extra

    16911684 help text to be printed out for the -help option.

    17081701
    17091702
    17101703
    1704
    1705
    17111706
    17121707

    17131708 Builtin parsers
    17141709
    17151710
    1716 class="doc_text">
    1711 >
    17171712
    17181713

    Parsers control how the string value taken from the command line is

    17191714 translated into a typed value, suitable for use in a C++ program. By default,
    17721767
    17731768
    17741769
    1770
    1771
    17751772
    17761773

    17771774 Extension Guide
    17781775
    17791776
    17801777
    1781 class="doc_text">
    1778 >
    17821779
    17831780

    Although the CommandLine library has a lot of functionality built into it

    17841781 already (as discussed previously), one of its true strengths lie in its
    17851782 extensibility. This section discusses how the CommandLine library works under
    17861783 the covers and illustrates how to do some simple, common, extensions.

    17871784
    1788
    1789
    17901785
    17911786

    17921787 Writing a custom parser
    17931788
    17941789
    1795 class="doc_text">
    1790 >
    17961791
    17971792

    One of the simplest and most common extensions is the use of a custom parser.

    17981793 As discussed previously, parsers are the portion
    19351930 Exploiting external storage
    19361931
    19371932
    1938 class="doc_text">
    1933 >
    19391934

    Several of the LLVM libraries define static cl::opt instances that

    19401935 will automatically be included in any program that links with that library.
    19411936 This is a feature. However, sometimes it is necessary to know the value of the
    19541949 Dynamically adding command line options
    19551950
    19561951
    1957 class="doc_text">
    1952 >
    19581953
    19591954

    TODO: fill in this section

    1955
    1956
    19601957
    19611958
    19621959
    +29
    -13
    docs/CompilerWriterInfo.html less more
    4545

    Hardware

    4646
    4747
    48
    49
    4850
    4951

    Alpha

    5052
    51 class="doc_text">
    53 >
    5254
    5355
  • 5456 href="http://ftp.digital.com/pub/Digital/info/semiconductor/literature/dsc-library.html">Alpha manuals
    5961
    6062

    ARM

    6163
    62 class="doc_text">
    64 >
    6365
    6466
  • ARM documentation
  • 6567 (Processor
    7173
    7274

    Itanium (ia64)

    7375
    74 class="doc_text">
    76 >
    7577
    7678
  • 7779 href="http://developer.intel.com/design/itanium2/documentation.htm">Itanium documentation
    8284
    8385

    MIPS

    8486
    85 class="doc_text">
    87 >
    8688
    8789
  • 8890 href="http://mips.com/content/Documentation/MIPSDocumentation/ProcessorArchitecture/doclibrary">MIPS
    9395
    9496

    PowerPC

    9597
    98
    99
    96100
    97101

    IBM - Official manuals and docs

    98102
    99 class="doc_text">
    103 >
    100104
    101105
    102106
  • 130134
    131135

    Other documents, collections, notes

    132136
    133 class="doc_text">
    137 >
    134138
    135139
    136140
  • PowerPC ABI documents
  • 142146
    143147
    144148
    149
    150
    145151
    146152

    SPARC

    147153
    148 class="doc_text">
    154 >
    149155
    150156
    151157
  • SPARC resources
  • 157163
    158164

    X86

    159165
    166
    167
    160168
    161169

    AMD - Official manuals and docs

    162170
    163 class="doc_text">
    171 >
    164172
    165173
  • 166174 href="http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739,00.html">AMD processor manuals
    171179
    172180

    Intel - Official manuals and docs

    173181
    174 class="doc_text">
    182 >
    175183
    176184
  • 177185 href="http://developer.intel.com/design/pentium4/manuals/index_new.htm">IA-32
    185193
    186194

    Other x86-specific information

    187195
    188 class="doc_text">
    196 >
    189197
    190198
  • Calling
  • 191199 conventions for different C++ compilers and operating systems
    192200
    193201
    194202
    203
    204
    195205
    196206

    Other relevant lists

    197207
    198 class="doc_text">
    208 >
    199209
    200210
    201211
  • GCC reading list
  • 203213
    204214
    205215
    216
    217
    206218
    207219

    ABI

    208220
    209221
    222
    223
    210224
    211225

    Linux

    212226
    213 class="doc_text">
    227 >
    214228
    215229
  • PowerPC 64-bit ELF ABI
  • 216230 Supplement
    220234
    221235

    OS X

    222236
    223 class="doc_text">
    237 >
    224238
    225239
  • 226240 href="http://developer.apple.com/documentation/Darwin/RuntimeArchitecture-date.html">Mach-O
    228242
  • Notes on Mach-O
  • 229243 ABI
    230244
    245
    246
    231247
    232248
    233249
    +2
    -2
    docs/DebuggingJITedCode.html less more
    1616
    1717

    Example usage

    1818
    19 class="doc_text">
    19 >
    2020
    2121

    In order to debug code JITed by LLVM, you need GDB 7.0 or newer, which is

    2222 available on most modern distributions of Linux. The version of GDB that Apple
    9797
    9898

    Background

    9999
    100 class="doc_text">
    100 >
    101101
    102102

    Without special runtime support, debugging dynamically generated code with

    103103 GDB (as well as most debuggers) can be quite painful. Debuggers generally read
    +20
    -18
    docs/DeveloperPolicy.html less more
    3535
    3636

    Introduction

    3737
    38 class="doc_text">
    38 >
    3939

    This document contains the LLVM Developer Policy which defines the project's

    4040 policy towards developers and their contributions. The intent of this policy
    4141 is to eliminate miscommunication, rework, and confusion that might arise from
    6464
    6565

    Developer Policies

    6666
    67 class="doc_text">
    67 >
    6868

    This section contains policies that pertain to frequent LLVM developers. We

    6969 always welcome one-off patches from people who do not
    7070 routinely contribute to LLVM, but we expect more from frequent contributors
    7171 to keep the system as efficient as possible for everyone. Frequent LLVM
    7272 contributors are expected to meet the following requirements in order for
    7373 LLVM to maintain a high standard of quality.

    74
    7574
    7675
    7776

    Stay Informed

    78 class="doc_text">
    77 >
    7978

    Developers should stay informed by reading at least the "dev" mailing list

    8079 for the projects you are interested in, such as
    8180 llvmdev for
    103102
    104103

    Making a Patch

    105104
    106 class="doc_text">
    105 >
    107106

    When making a patch for review, the goal is to make it as easy for the

    108107 reviewer to read it as possible. As such, we recommend that you:

    109108
    142141
    143142
    144143

    Code Reviews

    145 class="doc_text">
    144 >
    146145

    LLVM has a code review policy. Code review is one way to increase the quality

    147146 of software. We generally follow these policies:

    148147
    174173
    175174
    176175

    Code Owners

    177 class="doc_text">
    176 >
    178177
    179178

    The LLVM Project relies on two features of its process to maintain rapid

    180179 development in addition to the high quality of its source base: the
    225224
    226225
    227226

    Test Cases

    228 class="doc_text">
    227 >
    229228

    Developers are required to create test cases for any bugs fixed and any new

    230229 features added. Some tips for getting your testcase approved:

    231230
    258257
    259258
    260259

    Quality

    261 class="doc_text">
    260 >
    262261

    The minimum quality standards that any change must satisfy before being

    263262 committed to the main development branch are:

    264263
    318317
    319318
    320319

    Obtaining Commit Access

    321 class="doc_text">
    320 >
    322321
    323322

    We grant commit access to contributors with a track record of submitting high

    324323 quality patches. If you would like commit access, please send an email to
    380379
    381380
    382381

    Making a Major Change

    383 class="doc_text">
    382 >
    384383

    When a developer begins a major new project with the aim of contributing it

    385384 back to LLVM, s/he should inform the community with an email to
    386385 the llvmdev
    409408
    410409
    411410

    Incremental Development

    412 class="doc_text">
    411 >
    413412

    In the LLVM project, we do all significant changes as a series of incremental

    414413 patches. We have a strong dislike for huge changes or long-term development
    415414 branches. Long-term development branches have a number of drawbacks:

    470469
    471470
    472471

    Attribution of Changes

    473 class="doc_text">
    472 >
    474473

    We believe in correct attribution of contributions to their contributors.

    475474 However, we do not want the source code to be littered with random
    476475 attributions "this code written by J. Random Hacker" (this is noisy and
    482481

    Overall, please do not add contributor names to the source code.

    483482
    484483
    484
    485
    485486
    486487

    487488 Copyright, License, and Patents
    488489
    489490
    490491
    491 class="doc_text">
    492 >
    492493

    This section addresses the issues of copyright, license and patents for the

    493494 LLVM project. Currently, the University of Illinois is the LLVM copyright
    494495 holder and the terms of its license to LLVM users and developers is the
    500501 legal matters but does not provide legal advice. We are not lawyers, please
    501502 seek legal counsel from an attorney.

    502503
    503
    504504
    505505
    506506

    Copyright

    507 class="doc_text">
    507 >
    508508
    509509

    The LLVM project does not require copyright assignments, which means that the

    510510 copyright for the code in the project is held by its respective contributors
    527527
    528528
    529529

    License

    530 class="doc_text">
    530 >
    531531

    We intend to keep LLVM perpetually open source and to use a liberal open

    532532 source license. All of the code in LLVM is available under the
    533533 University of
    582582
    583583
    584584

    Patents

    585 class="doc_text">
    585 >
    586586

    To the best of our knowledge, LLVM does not infringe on any patents (we have

    587587 actually removed code from LLVM in the past that was found to infringe).
    588588 Having code in LLVM that infringes on patents would violate an important goal
    596596 other user of LLVM to freely use your patent. Please contact
    597597 the oversight group for more
    598598 details.

    599
    600
    599601
    600602
    601603
    +31
    -31
    docs/ExceptionHandling.html less more
    6060

    Introduction

    6161
    6262
    63 class="doc_text">
    63 >
    6464
    6565

    This document is the central repository for all information pertaining to

    6666 exception handling in LLVM. It describes the format that LLVM exception
    6969 provides specific examples of what exception handling information is used for
    7070 in C/C++.

    7171
    72
    73
    7472
    7573

    7674 Itanium ABI Zero-cost Exception Handling
    7775
    7876
    79 class="doc_text">
    77 >
    8078
    8179

    Exception handling for most programming languages is designed to recover from

    8280 conditions that rarely occur during general use of an application. To that
    109107 Setjmp/Longjmp Exception Handling
    110108
    111109
    112 class="doc_text">
    110 >
    113111
    114112

    Setjmp/Longjmp (SJLJ) based exception handling uses LLVM intrinsics

    115113 llvm.eh.sjlj.setjmp and
    141139 Overview
    142140
    143141
    144 class="doc_text">
    142 >
    145143
    146144

    When an exception is thrown in LLVM code, the runtime does its best to find a

    147145 handler suited to processing the circumstance.

    184182
    185183
    186184
    185
    186
    187187
    188188

    189189 LLVM Code Generation
    190190
    191191
    192 class="doc_text">
    192 >
    193193
    194194

    At the time of this writing, only C++ exception handling support is available

    195195 in LLVM. So the remainder of this document will be somewhat C++-centric.

    199199 we will describe the implementation of LLVM exception handling in terms of
    200200 C++ examples.

    201201
    202
    203
    204202
    205203

    206204 Throw
    207205
    208206
    209 class="doc_text">
    207 >
    210208
    211209

    Languages that support exception handling typically provide a throw

    212210 operation to initiate the exception process. Internally, a throw operation
    228226 Try/Catch
    229227
    230228
    231 class="doc_text">
    229 >
    232230
    233231

    A call within the scope of a try statement can potentially raise an

    234232 exception. In those circumstances, the LLVM C++ front-end replaces the call
    316314 Cleanups
    317315
    318316
    319 class="doc_text">
    317 >
    320318
    321319

    To handle destructors and cleanups in try code, control may not run

    322320 directly from a landing pad to the first catch. Control may actually flow
    335333 Throw Filters
    336334
    337335
    338 class="doc_text">
    336 >
    339337
    340338

    C++ allows the specification of which exception types can be thrown from a

    341339 function. To represent this a top level landing pad may exist to filter out
    362360 Restrictions
    363361
    364362
    365 class="doc_text">
    363 >
    366364
    367365

    The semantics of the invoke instruction require that any exception that

    368366 unwinds through an invoke call should result in a branch to the invoke's
    383381
    384382
    385383
    384
    385
    386386
    387387

    388388 Exception Handling Intrinsics
    389389
    390390
    391 class="doc_text">
    391 >
    392392
    393393

    LLVM uses several intrinsic functions (name prefixed with "llvm.eh") to

    394394 provide exception handling information at various points in generated
    395395 code.

    396396
    397
    398
    399397
    400398

    401399 llvm.eh.exception
    402400
    403401
    404 class="doc_text">
    402 >
    405403
    406404
    
                      
                    
    407405 i8* %llvm.eh.exception()
    416414 llvm.eh.selector
    417415
    418416
    419 class="doc_text">
    417 >
    420418
    421419
    
                      
                    
    422420 i32 %llvm.eh.selector(i8*, i8*, ...)
    448446 llvm.eh.typeid.for
    449447
    450448
    451 class="doc_text">
    449 >
    452450
    453451
    
                      
                    
    454452 i32 %llvm.eh.typeid.for(i8*)
    466464 llvm.eh.sjlj.setjmp
    467465
    468466
    469 class="doc_text">
    467 >
    470468
    471469
    
                      
                    
    472470 i32 %llvm.eh.sjlj.setjmp(i8*)
    495493 llvm.eh.sjlj.longjmp
    496494
    497495
    498 class="doc_text">
    496 >
    499497
    500498
    
                      
                    
    501499 void %llvm.eh.sjlj.setjmp(i8*)
    515513 llvm.eh.sjlj.lsda
    516514
    517515
    518 class="doc_text">
    516 >
    519517
    520518
    
                      
                    
    521519 i8* %llvm.eh.sjlj.lsda()
    534532 llvm.eh.sjlj.callsite
    535533
    536534
    537 class="doc_text">
    535 >
    538536
    539537
    
                      
                    
    540538 void %llvm.eh.sjlj.callsite(i32)
    552550 llvm.eh.sjlj.dispatchsetup
    553551
    554552
    555 class="doc_text">
    553 >
    556554
    557555
    
                      
                    
    558556 void %llvm.eh.sjlj.dispatchsetup(i32)
    564562
    565563
    566564
    565
    566
    567567
    568568

    569569 Asm Table Formats
    570570
    571571
    572 class="doc_text">
    572 >
    573573
    574574

    There are two tables that are used by the exception handling runtime to

    575575 determine which actions should take place when an exception is thrown.

    576576
    577
    578
    579577
    580578

    581579 Exception Handling Frame
    582580
    583581
    584 class="doc_text">
    582 >
    585583
    586584

    An exception handling frame eh_frame is very similar to the unwind

    587585 frame used by dwarf debug info. The frame contains all the information
    599597 Exception Tables
    600598
    601599
    602 class="doc_text">
    600 >
    603601
    604602

    An exception table contains information about what actions to take when an

    605603 exception is thrown in a particular part of a function's code. There is one
    610608
    611609
    612610
    611
    612
    613613
    614614

    615615 ToDo
    616616
    617617
    618 class="doc_text">
    618 >
    619619
    620620
    621621
    +9
    -9
    docs/ExtendingLLVM.html less more
    3535
    3636
    3737
    38 class="doc_text">
    38 >
    3939
    4040

    During the course of using LLVM, you may wish to customize it for your

    4141 research project or for experimentation. At this point, you may realize that
    7272
    7373
    7474
    75 class="doc_text">
    75 >
    7676
    7777

    Adding a new intrinsic function to LLVM is much easier than adding a new

    7878 instruction. Almost all extensions to LLVM should start as an intrinsic
    134134
    135135
    136136
    137 class="doc_text">
    137 >
    138138
    139139

    As with intrinsics, adding a new SelectionDAG node to LLVM is much easier

    140140 than adding a new instruction. New nodes are often added to help represent
    224224
    225225
    226226
    227 class="doc_text">
    227 >
    228228
    229229

    WARNING: adding instructions changes the bitcode

    230230 format, and it will take some effort to maintain compatibility with
    281281
    282282
    283283
    284 class="doc_text">
    284 >
    285285
    286286

    WARNING: adding new types changes the bitcode

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

    289
    290
    291289
    292290
    293291

    294292 Adding a fundamental type
    295293
    296294
    297 class="doc_text">
    295 >
    298296
    299297
    300298
    320318 Adding a derived type
    321319
    322320
    323 class="doc_text">
    321 >
    324322
    325323
    326324
  • llvm/include/llvm/Type.h:
  • 372370
    373371
    374372
    373
    374
    375375
    376376
    377377
    +4
    -4
    docs/GCCFEBuildInstrs.html less more
    2626

    Building llvm-gcc from Source

    2727
    2828
    29 class="doc_text">
    29 >
    3030
    3131

    This section describes how to acquire and build llvm-gcc 4.2, which is based

    3232 on the GCC 4.2.1 front-end. Supported languages are Ada, C, C++, Fortran,
    6969

    Building the Ada front-end

    7070
    7171
    72 class="doc_text">
    72 >
    7373

    Building with support for Ada amounts to following the directions in the

    7474 top-level README.LLVM file, adding ",ada" to EXTRALANGS, for example:
    7575 EXTRALANGS=,ada

    235235

    Building the Fortran front-end

    236236
    237237
    238 class="doc_text">
    238 >
    239239

    To build with support for Fortran, follow the directions in the top-level

    240240 README.LLVM file, adding ",fortran" to EXTRALANGS, for example:

    241241
    249249

    License Information

    250250
    251251
    252 class="doc_text">
    252 >
    253253

    254254 The LLVM GCC frontend is licensed to you under the GNU General Public License
    255255 and the GNU Lesser General Public License. Please see the files COPYING and
    +29
    -30
    docs/GarbageCollection.html less more
    8383
    8484
    8585
    86 class="doc_text">
    86 >
    8787
    8888

    Garbage collection is a widely used technique that frees the programmer from

    8989 having to know the lifetimes of heap objects, making software easier to produce
    123123

    This document describes the mechanisms and interfaces provided by LLVM to

    124124 support accurate garbage collection.

    125125
    126
    127
    128126
    129127

    130128 Goals and non-goals
    131129
    132130
    133 class="doc_text">
    131 >
    134132
    135133

    LLVM's intermediate representation provides garbage

    136134 collection intrinsics that offer support for a broad class of