1.. role:: raw-html(raw) 2 :format: html 3 4======================== 5LLVM Bitcode File Format 6======================== 7 8.. contents:: 9 :local: 10 11Abstract 12======== 13 14This document describes the LLVM bitstream file format and the encoding of the 15LLVM IR into it. 16 17Overview 18======== 19 20What is commonly known as the LLVM bitcode file format (also, sometimes 21anachronistically known as bytecode) is actually two things: a `bitstream 22container format`_ and an `encoding of LLVM IR`_ into the container format. 23 24The bitstream format is an abstract encoding of structured data, very similar to 25XML in some ways. Like XML, bitstream files contain tags, and nested 26structures, and you can parse the file without having to understand the tags. 27Unlike XML, the bitstream format is a binary encoding, and unlike XML it 28provides a mechanism for the file to self-describe "abbreviations", which are 29effectively size optimizations for the content. 30 31LLVM IR files may be optionally embedded into a `wrapper`_ structure, or in a 32`native object file`_. Both of these mechanisms make it easy to embed extra 33data along with LLVM IR files. 34 35This document first describes the LLVM bitstream format, describes the wrapper 36format, then describes the record structure used by LLVM IR files. 37 38.. _bitstream container format: 39 40Bitstream Format 41================ 42 43The bitstream format is literally a stream of bits, with a very simple 44structure. This structure consists of the following concepts: 45 46* A "`magic number`_" that identifies the contents of the stream. 47 48* Encoding `primitives`_ like variable bit-rate integers. 49 50* `Blocks`_, which define nested content. 51 52* `Data Records`_, which describe entities within the file. 53 54* Abbreviations, which specify compression optimizations for the file. 55 56Note that the :doc:`llvm-bcanalyzer <CommandGuide/llvm-bcanalyzer>` tool can be 57used to dump and inspect arbitrary bitstreams, which is very useful for 58understanding the encoding. 59 60.. _magic number: 61 62Magic Numbers 63------------- 64 65The first four bytes of a bitstream are used as an application-specific magic 66number. Generic bitcode tools may look at the first four bytes to determine 67whether the stream is a known stream type. However, these tools should *not* 68determine whether a bitstream is valid based on its magic number alone. New 69application-specific bitstream formats are being developed all the time; tools 70should not reject them just because they have a hitherto unseen magic number. 71 72.. _primitives: 73 74Primitives 75---------- 76 77A bitstream literally consists of a stream of bits, which are read in order 78starting with the least significant bit of each byte. The stream is made up of 79a number of primitive values that encode a stream of unsigned integer values. 80These integers are encoded in two ways: either as `Fixed Width Integers`_ or as 81`Variable Width Integers`_. 82 83.. _Fixed Width Integers: 84.. _fixed-width value: 85 86Fixed Width Integers 87^^^^^^^^^^^^^^^^^^^^ 88 89Fixed-width integer values have their low bits emitted directly to the file. 90For example, a 3-bit integer value encodes 1 as 001. Fixed width integers are 91used when there are a well-known number of options for a field. For example, 92boolean values are usually encoded with a 1-bit wide integer. 93 94.. _Variable Width Integers: 95.. _Variable Width Integer: 96.. _variable-width value: 97 98Variable Width Integers 99^^^^^^^^^^^^^^^^^^^^^^^ 100 101Variable-width integer (VBR) values encode values of arbitrary size, optimizing 102for the case where the values are small. Given a 4-bit VBR field, any 3-bit 103value (0 through 7) is encoded directly, with the high bit set to zero. Values 104larger than N-1 bits emit their bits in a series of N-1 bit chunks, where all 105but the last set the high bit. 106 107For example, the value 27 (0x1B) is encoded as 1011 0011 when emitted as a vbr4 108value. The first set of four bits indicates the value 3 (011) with a 109continuation piece (indicated by a high bit of 1). The next word indicates a 110value of 24 (011 << 3) with no continuation. The sum (3+24) yields the value 11127. 112 113.. _char6-encoded value: 114 1156-bit characters 116^^^^^^^^^^^^^^^^ 117 1186-bit characters encode common characters into a fixed 6-bit field. They 119represent the following characters with the following 6-bit values: 120 121:: 122 123 'a' .. 'z' --- 0 .. 25 124 'A' .. 'Z' --- 26 .. 51 125 '0' .. '9' --- 52 .. 61 126 '.' --- 62 127 '_' --- 63 128 129This encoding is only suitable for encoding characters and strings that consist 130only of the above characters. It is completely incapable of encoding characters 131not in the set. 132 133Word Alignment 134^^^^^^^^^^^^^^ 135 136Occasionally, it is useful to emit zero bits until the bitstream is a multiple 137of 32 bits. This ensures that the bit position in the stream can be represented 138as a multiple of 32-bit words. 139 140Abbreviation IDs 141---------------- 142 143A bitstream is a sequential series of `Blocks`_ and `Data Records`_. Both of 144these start with an abbreviation ID encoded as a fixed-bitwidth field. The 145width is specified by the current block, as described below. The value of the 146abbreviation ID specifies either a builtin ID (which have special meanings, 147defined below) or one of the abbreviation IDs defined for the current block by 148the stream itself. 149 150The set of builtin abbrev IDs is: 151 152* 0 - `END_BLOCK`_ --- This abbrev ID marks the end of the current block. 153 154* 1 - `ENTER_SUBBLOCK`_ --- This abbrev ID marks the beginning of a new 155 block. 156 157* 2 - `DEFINE_ABBREV`_ --- This defines a new abbreviation. 158 159* 3 - `UNABBREV_RECORD`_ --- This ID specifies the definition of an 160 unabbreviated record. 161 162Abbreviation IDs 4 and above are defined by the stream itself, and specify an 163`abbreviated record encoding`_. 164 165.. _Blocks: 166 167Blocks 168------ 169 170Blocks in a bitstream denote nested regions of the stream, and are identified by 171a content-specific id number (for example, LLVM IR uses an ID of 12 to represent 172function bodies). Block IDs 0-7 are reserved for `standard blocks`_ whose 173meaning is defined by Bitcode; block IDs 8 and greater are application 174specific. Nested blocks capture the hierarchical structure of the data encoded 175in it, and various properties are associated with blocks as the file is parsed. 176Block definitions allow the reader to efficiently skip blocks in constant time 177if the reader wants a summary of blocks, or if it wants to efficiently skip data 178it does not understand. The LLVM IR reader uses this mechanism to skip function 179bodies, lazily reading them on demand. 180 181When reading and encoding the stream, several properties are maintained for the 182block. In particular, each block maintains: 183 184#. A current abbrev id width. This value starts at 2 at the beginning of the 185 stream, and is set every time a block record is entered. The block entry 186 specifies the abbrev id width for the body of the block. 187 188#. A set of abbreviations. Abbreviations may be defined within a block, in 189 which case they are only defined in that block (neither subblocks nor 190 enclosing blocks see the abbreviation). Abbreviations can also be defined 191 inside a `BLOCKINFO`_ block, in which case they are defined in all blocks 192 that match the ID that the ``BLOCKINFO`` block is describing. 193 194As sub blocks are entered, these properties are saved and the new sub-block has 195its own set of abbreviations, and its own abbrev id width. When a sub-block is 196popped, the saved values are restored. 197 198.. _ENTER_SUBBLOCK: 199 200ENTER_SUBBLOCK Encoding 201^^^^^^^^^^^^^^^^^^^^^^^ 202 203:raw-html:`<tt>` 204[ENTER_SUBBLOCK, blockid\ :sub:`vbr8`, newabbrevlen\ :sub:`vbr4`, <align32bits>, blocklen_32] 205:raw-html:`</tt>` 206 207The ``ENTER_SUBBLOCK`` abbreviation ID specifies the start of a new block 208record. The ``blockid`` value is encoded as an 8-bit VBR identifier, and 209indicates the type of block being entered, which can be a `standard block`_ or 210an application-specific block. The ``newabbrevlen`` value is a 4-bit VBR, which 211specifies the abbrev id width for the sub-block. The ``blocklen`` value is a 21232-bit aligned value that specifies the size of the subblock in 32-bit 213words. This value allows the reader to skip over the entire block in one jump. 214 215.. _END_BLOCK: 216 217END_BLOCK Encoding 218^^^^^^^^^^^^^^^^^^ 219 220``[END_BLOCK, <align32bits>]`` 221 222The ``END_BLOCK`` abbreviation ID specifies the end of the current block record. 223Its end is aligned to 32-bits to ensure that the size of the block is an even 224multiple of 32-bits. 225 226.. _Data Records: 227 228Data Records 229------------ 230 231Data records consist of a record code and a number of (up to) 64-bit integer 232values. The interpretation of the code and values is application specific and 233may vary between different block types. Records can be encoded either using an 234unabbrev record, or with an abbreviation. In the LLVM IR format, for example, 235there is a record which encodes the target triple of a module. The code is 236``MODULE_CODE_TRIPLE``, and the values of the record are the ASCII codes for the 237characters in the string. 238 239.. _UNABBREV_RECORD: 240 241UNABBREV_RECORD Encoding 242^^^^^^^^^^^^^^^^^^^^^^^^ 243 244:raw-html:`<tt>` 245[UNABBREV_RECORD, code\ :sub:`vbr6`, numops\ :sub:`vbr6`, op0\ :sub:`vbr6`, op1\ :sub:`vbr6`, ...] 246:raw-html:`</tt>` 247 248An ``UNABBREV_RECORD`` provides a default fallback encoding, which is both 249completely general and extremely inefficient. It can describe an arbitrary 250record by emitting the code and operands as VBRs. 251 252For example, emitting an LLVM IR target triple as an unabbreviated record 253requires emitting the ``UNABBREV_RECORD`` abbrevid, a vbr6 for the 254``MODULE_CODE_TRIPLE`` code, a vbr6 for the length of the string, which is equal 255to the number of operands, and a vbr6 for each character. Because there are no 256letters with values less than 32, each letter would need to be emitted as at 257least a two-part VBR, which means that each letter would require at least 12 258bits. This is not an efficient encoding, but it is fully general. 259 260.. _abbreviated record encoding: 261 262Abbreviated Record Encoding 263^^^^^^^^^^^^^^^^^^^^^^^^^^^ 264 265``[<abbrevid>, fields...]`` 266 267An abbreviated record is an abbreviation id followed by a set of fields that are 268encoded according to the `abbreviation definition`_. This allows records to be 269encoded significantly more densely than records encoded with the 270`UNABBREV_RECORD`_ type, and allows the abbreviation types to be specified in 271the stream itself, which allows the files to be completely self describing. The 272actual encoding of abbreviations is defined below. 273 274The record code, which is the first field of an abbreviated record, may be 275encoded in the abbreviation definition (as a literal operand) or supplied in the 276abbreviated record (as a Fixed or VBR operand value). 277 278.. _abbreviation definition: 279 280Abbreviations 281------------- 282 283Abbreviations are an important form of compression for bitstreams. The idea is 284to specify a dense encoding for a class of records once, then use that encoding 285to emit many records. It takes space to emit the encoding into the file, but 286the space is recouped (hopefully plus some) when the records that use it are 287emitted. 288 289Abbreviations can be determined dynamically per client, per file. Because the 290abbreviations are stored in the bitstream itself, different streams of the same 291format can contain different sets of abbreviations according to the needs of the 292specific stream. As a concrete example, LLVM IR files usually emit an 293abbreviation for binary operators. If a specific LLVM module contained no or 294few binary operators, the abbreviation does not need to be emitted. 295 296.. _DEFINE_ABBREV: 297 298DEFINE_ABBREV Encoding 299^^^^^^^^^^^^^^^^^^^^^^ 300 301:raw-html:`<tt>` 302[DEFINE_ABBREV, numabbrevops\ :sub:`vbr5`, abbrevop0, abbrevop1, ...] 303:raw-html:`</tt>` 304 305A ``DEFINE_ABBREV`` record adds an abbreviation to the list of currently defined 306abbreviations in the scope of this block. This definition only exists inside 307this immediate block --- it is not visible in subblocks or enclosing blocks. 308Abbreviations are implicitly assigned IDs sequentially starting from 4 (the 309first application-defined abbreviation ID). Any abbreviations defined in a 310``BLOCKINFO`` record for the particular block type receive IDs first, in order, 311followed by any abbreviations defined within the block itself. Abbreviated data 312records reference this ID to indicate what abbreviation they are invoking. 313 314An abbreviation definition consists of the ``DEFINE_ABBREV`` abbrevid followed 315by a VBR that specifies the number of abbrev operands, then the abbrev operands 316themselves. Abbreviation operands come in three forms. They all start with a 317single bit that indicates whether the abbrev operand is a literal operand (when 318the bit is 1) or an encoding operand (when the bit is 0). 319 320#. Literal operands --- :raw-html:`<tt>` [1\ :sub:`1`, litvalue\ 321 :sub:`vbr8`] :raw-html:`</tt>` --- Literal operands specify that the value in 322 the result is always a single specific value. This specific value is emitted 323 as a vbr8 after the bit indicating that it is a literal operand. 324 325#. Encoding info without data --- :raw-html:`<tt>` [0\ :sub:`1`, encoding\ 326 :sub:`3`] :raw-html:`</tt>` --- Operand encodings that do not have extra data 327 are just emitted as their code. 328 329#. Encoding info with data --- :raw-html:`<tt>` [0\ :sub:`1`, encoding\ 330 :sub:`3`, value\ :sub:`vbr5`] :raw-html:`</tt>` --- Operand encodings that do 331 have extra data are emitted as their code, followed by the extra data. 332 333The possible operand encodings are: 334 335* Fixed (code 1): The field should be emitted as a `fixed-width value`_, whose 336 width is specified by the operand's extra data. 337 338* VBR (code 2): The field should be emitted as a `variable-width value`_, whose 339 width is specified by the operand's extra data. 340 341* Array (code 3): This field is an array of values. The array operand has no 342 extra data, but expects another operand to follow it, indicating the element 343 type of the array. When reading an array in an abbreviated record, the first 344 integer is a vbr6 that indicates the array length, followed by the encoded 345 elements of the array. An array may only occur as the last operand of an 346 abbreviation (except for the one final operand that gives the array's 347 type). 348 349* Char6 (code 4): This field should be emitted as a `char6-encoded value`_. 350 This operand type takes no extra data. Char6 encoding is normally used as an 351 array element type. 352 353* Blob (code 5): This field is emitted as a vbr6, followed by padding to a 354 32-bit boundary (for alignment) and an array of 8-bit objects. The array of 355 bytes is further followed by tail padding to ensure that its total length is a 356 multiple of 4 bytes. This makes it very efficient for the reader to decode 357 the data without having to make a copy of it: it can use a pointer to the data 358 in the mapped in file and poke directly at it. A blob may only occur as the 359 last operand of an abbreviation. 360 361For example, target triples in LLVM modules are encoded as a record of the form 362``[TRIPLE, 'a', 'b', 'c', 'd']``. Consider if the bitstream emitted the 363following abbrev entry: 364 365:: 366 367 [0, Fixed, 4] 368 [0, Array] 369 [0, Char6] 370 371When emitting a record with this abbreviation, the above entry would be emitted 372as: 373 374:raw-html:`<tt><blockquote>` 375[4\ :sub:`abbrevwidth`, 2\ :sub:`4`, 4\ :sub:`vbr6`, 0\ :sub:`6`, 1\ :sub:`6`, 2\ :sub:`6`, 3\ :sub:`6`] 376:raw-html:`</blockquote></tt>` 377 378These values are: 379 380#. The first value, 4, is the abbreviation ID for this abbreviation. 381 382#. The second value, 2, is the record code for ``TRIPLE`` records within LLVM IR 383 file ``MODULE_BLOCK`` blocks. 384 385#. The third value, 4, is the length of the array. 386 387#. The rest of the values are the char6 encoded values for ``"abcd"``. 388 389With this abbreviation, the triple is emitted with only 37 bits (assuming a 390abbrev id width of 3). Without the abbreviation, significantly more space would 391be required to emit the target triple. Also, because the ``TRIPLE`` value is 392not emitted as a literal in the abbreviation, the abbreviation can also be used 393for any other string value. 394 395.. _standard blocks: 396.. _standard block: 397 398Standard Blocks 399--------------- 400 401In addition to the basic block structure and record encodings, the bitstream 402also defines specific built-in block types. These block types specify how the 403stream is to be decoded or other metadata. In the future, new standard blocks 404may be added. Block IDs 0-7 are reserved for standard blocks. 405 406.. _BLOCKINFO: 407 408#0 - BLOCKINFO Block 409^^^^^^^^^^^^^^^^^^^^ 410 411The ``BLOCKINFO`` block allows the description of metadata for other blocks. 412The currently specified records are: 413 414:: 415 416 [SETBID (#1), blockid] 417 [DEFINE_ABBREV, ...] 418 [BLOCKNAME, ...name...] 419 [SETRECORDNAME, RecordID, ...name...] 420 421The ``SETBID`` record (code 1) indicates which block ID is being described. 422``SETBID`` records can occur multiple times throughout the block to change which 423block ID is being described. There must be a ``SETBID`` record prior to any 424other records. 425 426Standard ``DEFINE_ABBREV`` records can occur inside ``BLOCKINFO`` blocks, but 427unlike their occurrence in normal blocks, the abbreviation is defined for blocks 428matching the block ID we are describing, *not* the ``BLOCKINFO`` block 429itself. The abbreviations defined in ``BLOCKINFO`` blocks receive abbreviation 430IDs as described in `DEFINE_ABBREV`_. 431 432The ``BLOCKNAME`` record (code 2) can optionally occur in this block. The 433elements of the record are the bytes of the string name of the block. 434llvm-bcanalyzer can use this to dump out bitcode files symbolically. 435 436The ``SETRECORDNAME`` record (code 3) can also optionally occur in this block. 437The first operand value is a record ID number, and the rest of the elements of 438the record are the bytes for the string name of the record. llvm-bcanalyzer can 439use this to dump out bitcode files symbolically. 440 441Note that although the data in ``BLOCKINFO`` blocks is described as "metadata," 442the abbreviations they contain are essential for parsing records from the 443corresponding blocks. It is not safe to skip them. 444 445.. _wrapper: 446 447Bitcode Wrapper Format 448====================== 449 450Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper 451structure. This structure contains a simple header that indicates the offset 452and size of the embedded BC file. This allows additional information to be 453stored alongside the BC file. The structure of this file header is: 454 455:raw-html:`<tt><blockquote>` 456[Magic\ :sub:`32`, Version\ :sub:`32`, Offset\ :sub:`32`, Size\ :sub:`32`, CPUType\ :sub:`32`] 457:raw-html:`</blockquote></tt>` 458 459Each of the fields are 32-bit fields stored in little endian form (as with the 460rest of the bitcode file fields). The Magic number is always ``0x0B17C0DE`` and 461the version is currently always ``0``. The Offset field is the offset in bytes 462to the start of the bitcode stream in the file, and the Size field is the size 463in bytes of the stream. CPUType is a target-specific value that can be used to 464encode the CPU of the target. 465 466.. _native object file: 467 468Native Object File Wrapper Format 469================================= 470 471Bitcode files for LLVM IR may also be wrapped in a native object file 472(i.e. ELF, COFF, Mach-O). The bitcode must be stored in a section of the object 473file named ``__LLVM,__bitcode`` for MachO and ``.llvmbc`` for the other object 474formats. This wrapper format is useful for accommodating LTO in compilation 475pipelines where intermediate objects must be native object files which contain 476metadata in other sections. 477 478Not all tools support this format. 479 480.. _encoding of LLVM IR: 481 482LLVM IR Encoding 483================ 484 485LLVM IR is encoded into a bitstream by defining blocks and records. It uses 486blocks for things like constant pools, functions, symbol tables, etc. It uses 487records for things like instructions, global variable descriptors, type 488descriptions, etc. This document does not describe the set of abbreviations 489that the writer uses, as these are fully self-described in the file, and the 490reader is not allowed to build in any knowledge of this. 491 492Basics 493------ 494 495LLVM IR Magic Number 496^^^^^^^^^^^^^^^^^^^^ 497 498The magic number for LLVM IR files is: 499 500:raw-html:`<tt><blockquote>` 501['B'\ :sub:`8`, 'C'\ :sub:`8`, 0x0\ :sub:`4`, 0xC\ :sub:`4`, 0xE\ :sub:`4`, 0xD\ :sub:`4`] 502:raw-html:`</blockquote></tt>` 503 504.. _Signed VBRs: 505 506Signed VBRs 507^^^^^^^^^^^ 508 509`Variable Width Integer`_ encoding is an efficient way to encode arbitrary sized 510unsigned values, but is an extremely inefficient for encoding signed values, as 511signed values are otherwise treated as maximally large unsigned values. 512 513As such, signed VBR values of a specific width are emitted as follows: 514 515* Positive values are emitted as VBRs of the specified width, but with their 516 value shifted left by one. 517 518* Negative values are emitted as VBRs of the specified width, but the negated 519 value is shifted left by one, and the low bit is set. 520 521With this encoding, small positive and small negative values can both be emitted 522efficiently. Signed VBR encoding is used in ``CST_CODE_INTEGER`` and 523``CST_CODE_WIDE_INTEGER`` records within ``CONSTANTS_BLOCK`` blocks. 524It is also used for phi instruction operands in `MODULE_CODE_VERSION`_ 1. 525 526LLVM IR Blocks 527^^^^^^^^^^^^^^ 528 529LLVM IR is defined with the following blocks: 530 531* 8 --- `MODULE_BLOCK`_ --- This is the top-level block that contains the entire 532 module, and describes a variety of per-module information. 533 534* 9 --- `PARAMATTR_BLOCK`_ --- This enumerates the parameter attributes. 535 536* 10 --- `PARAMATTR_GROUP_BLOCK`_ --- This describes the attribute group table. 537 538* 11 --- `CONSTANTS_BLOCK`_ --- This describes constants for a module or 539 function. 540 541* 12 --- `FUNCTION_BLOCK`_ --- This describes a function body. 542 543* 14 --- `VALUE_SYMTAB_BLOCK`_ --- This describes a value symbol table. 544 545* 15 --- `METADATA_BLOCK`_ --- This describes metadata items. 546 547* 16 --- `METADATA_ATTACHMENT`_ --- This contains records associating metadata 548 with function instruction values. 549 550* 17 --- `TYPE_BLOCK`_ --- This describes all of the types in the module. 551 552* 23 --- `STRTAB_BLOCK`_ --- The bitcode file's string table. 553 554.. _MODULE_BLOCK: 555 556MODULE_BLOCK Contents 557--------------------- 558 559The ``MODULE_BLOCK`` block (id 8) is the top-level block for LLVM bitcode files, 560and each bitcode file must contain exactly one. In addition to records 561(described below) containing information about the module, a ``MODULE_BLOCK`` 562block may contain the following sub-blocks: 563 564* `BLOCKINFO`_ 565* `PARAMATTR_BLOCK`_ 566* `PARAMATTR_GROUP_BLOCK`_ 567* `TYPE_BLOCK`_ 568* `VALUE_SYMTAB_BLOCK`_ 569* `CONSTANTS_BLOCK`_ 570* `FUNCTION_BLOCK`_ 571* `METADATA_BLOCK`_ 572 573.. _MODULE_CODE_VERSION: 574 575MODULE_CODE_VERSION Record 576^^^^^^^^^^^^^^^^^^^^^^^^^^ 577 578``[VERSION, version#]`` 579 580The ``VERSION`` record (code 1) contains a single value indicating the format 581version. Versions 0, 1 and 2 are supported at this time. The difference between 582version 0 and 1 is in the encoding of instruction operands in 583each `FUNCTION_BLOCK`_. 584 585In version 0, each value defined by an instruction is assigned an ID 586unique to the function. Function-level value IDs are assigned starting from 587``NumModuleValues`` since they share the same namespace as module-level 588values. The value enumerator resets after each function. When a value is 589an operand of an instruction, the value ID is used to represent the operand. 590For large functions or large modules, these operand values can be large. 591 592The encoding in version 1 attempts to avoid large operand values 593in common cases. Instead of using the value ID directly, operands are 594encoded as relative to the current instruction. Thus, if an operand 595is the value defined by the previous instruction, the operand 596will be encoded as 1. 597 598For example, instead of 599 600.. code-block:: none 601 602 #n = load #n-1 603 #n+1 = icmp eq #n, #const0 604 br #n+1, label #(bb1), label #(bb2) 605 606version 1 will encode the instructions as 607 608.. code-block:: none 609 610 #n = load #1 611 #n+1 = icmp eq #1, (#n+1)-#const0 612 br #1, label #(bb1), label #(bb2) 613 614Note in the example that operands which are constants also use 615the relative encoding, while operands like basic block labels 616do not use the relative encoding. 617 618Forward references will result in a negative value. 619This can be inefficient, as operands are normally encoded 620as unsigned VBRs. However, forward references are rare, except in the 621case of phi instructions. For phi instructions, operands are encoded as 622`Signed VBRs`_ to deal with forward references. 623 624In version 2, the meaning of module records ``FUNCTION``, ``GLOBALVAR``, 625``ALIAS``, ``IFUNC`` and ``COMDAT`` change such that the first two operands 626specify an offset and size of a string in a string table (see `STRTAB_BLOCK 627Contents`_), the function name is removed from the ``FNENTRY`` record in the 628value symbol table, and the top-level ``VALUE_SYMTAB_BLOCK`` may only contain 629``FNENTRY`` records. 630 631MODULE_CODE_TRIPLE Record 632^^^^^^^^^^^^^^^^^^^^^^^^^ 633 634``[TRIPLE, ...string...]`` 635 636The ``TRIPLE`` record (code 2) contains a variable number of values representing 637the bytes of the ``target triple`` specification string. 638 639MODULE_CODE_DATALAYOUT Record 640^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 641 642``[DATALAYOUT, ...string...]`` 643 644The ``DATALAYOUT`` record (code 3) contains a variable number of values 645representing the bytes of the ``target datalayout`` specification string. 646 647MODULE_CODE_ASM Record 648^^^^^^^^^^^^^^^^^^^^^^ 649 650``[ASM, ...string...]`` 651 652The ``ASM`` record (code 4) contains a variable number of values representing 653the bytes of ``module asm`` strings, with individual assembly blocks separated 654by newline (ASCII 10) characters. 655 656.. _MODULE_CODE_SECTIONNAME: 657 658MODULE_CODE_SECTIONNAME Record 659^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 660 661``[SECTIONNAME, ...string...]`` 662 663The ``SECTIONNAME`` record (code 5) contains a variable number of values 664representing the bytes of a single section name string. There should be one 665``SECTIONNAME`` record for each section name referenced (e.g., in global 666variable or function ``section`` attributes) within the module. These records 667can be referenced by the 1-based index in the *section* fields of ``GLOBALVAR`` 668or ``FUNCTION`` records. 669 670MODULE_CODE_DEPLIB Record 671^^^^^^^^^^^^^^^^^^^^^^^^^ 672 673``[DEPLIB, ...string...]`` 674 675The ``DEPLIB`` record (code 6) contains a variable number of values representing 676the bytes of a single dependent library name string, one of the libraries 677mentioned in a ``deplibs`` declaration. There should be one ``DEPLIB`` record 678for each library name referenced. 679 680MODULE_CODE_GLOBALVAR Record 681^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 682 683``[GLOBALVAR, strtab offset, strtab size, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr, externally_initialized, dllstorageclass, comdat, attributes, preemptionspecifier]`` 684 685The ``GLOBALVAR`` record (code 7) marks the declaration or definition of a 686global variable. The operand fields are: 687 688* *strtab offset*, *strtab size*: Specifies the name of the global variable. 689 See `STRTAB_BLOCK Contents`_. 690 691* *pointer type*: The type index of the pointer type used to point to this 692 global variable 693 694* *isconst*: Non-zero if the variable is treated as constant within the module, 695 or zero if it is not 696 697* *initid*: If non-zero, the value index of the initializer for this variable, 698 plus 1. 699 700.. _linkage type: 701 702* *linkage*: An encoding of the linkage type for this variable: 703 704 * ``external``: code 0 705 * ``weak``: code 1 706 * ``appending``: code 2 707 * ``internal``: code 3 708 * ``linkonce``: code 4 709 * ``dllimport``: code 5 710 * ``dllexport``: code 6 711 * ``extern_weak``: code 7 712 * ``common``: code 8 713 * ``private``: code 9 714 * ``weak_odr``: code 10 715 * ``linkonce_odr``: code 11 716 * ``available_externally``: code 12 717 * deprecated : code 13 718 * deprecated : code 14 719 720* alignment*: The logarithm base 2 of the variable's requested alignment, plus 1 721 722* *section*: If non-zero, the 1-based section index in the table of 723 `MODULE_CODE_SECTIONNAME`_ entries. 724 725.. _visibility: 726 727* *visibility*: If present, an encoding of the visibility of this variable: 728 729 * ``default``: code 0 730 * ``hidden``: code 1 731 * ``protected``: code 2 732 733.. _bcthreadlocal: 734 735* *threadlocal*: If present, an encoding of the thread local storage mode of the 736 variable: 737 738 * ``not thread local``: code 0 739 * ``thread local; default TLS model``: code 1 740 * ``localdynamic``: code 2 741 * ``initialexec``: code 3 742 * ``localexec``: code 4 743 744.. _bcunnamedaddr: 745 746* *unnamed_addr*: If present, an encoding of the ``unnamed_addr`` attribute of this 747 variable: 748 749 * not ``unnamed_addr``: code 0 750 * ``unnamed_addr``: code 1 751 * ``local_unnamed_addr``: code 2 752 753.. _bcdllstorageclass: 754 755* *dllstorageclass*: If present, an encoding of the DLL storage class of this variable: 756 757 * ``default``: code 0 758 * ``dllimport``: code 1 759 * ``dllexport``: code 2 760 761* *comdat*: An encoding of the COMDAT of this function 762 763* *attributes*: If nonzero, the 1-based index into the table of AttributeLists. 764 765.. _bcpreemptionspecifier: 766 767* *preemptionspecifier*: If present, an encoding of the runtime preemption specifier of this variable: 768 769 * ``dso_preemptable``: code 0 770 * ``dso_local``: code 1 771 772.. _FUNCTION: 773 774MODULE_CODE_FUNCTION Record 775^^^^^^^^^^^^^^^^^^^^^^^^^^^ 776 777``[FUNCTION, strtab offset, strtab size, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prologuedata, dllstorageclass, comdat, prefixdata, personalityfn, preemptionspecifier]`` 778 779The ``FUNCTION`` record (code 8) marks the declaration or definition of a 780function. The operand fields are: 781 782* *strtab offset*, *strtab size*: Specifies the name of the function. 783 See `STRTAB_BLOCK Contents`_. 784 785* *type*: The type index of the function type describing this function 786 787* *callingconv*: The calling convention number: 788 * ``ccc``: code 0 789 * ``fastcc``: code 8 790 * ``coldcc``: code 9 791 * ``webkit_jscc``: code 12 792 * ``anyregcc``: code 13 793 * ``preserve_mostcc``: code 14 794 * ``preserve_allcc``: code 15 795 * ``swiftcc`` : code 16 796 * ``cxx_fast_tlscc``: code 17 797 * ``tailcc`` : code 18 798 * ``cfguard_checkcc`` : code 19 799 * ``swifttailcc`` : code 20 800 * ``x86_stdcallcc``: code 64 801 * ``x86_fastcallcc``: code 65 802 * ``arm_apcscc``: code 66 803 * ``arm_aapcscc``: code 67 804 * ``arm_aapcs_vfpcc``: code 68 805 806* isproto*: Non-zero if this entry represents a declaration rather than a 807 definition 808 809* *linkage*: An encoding of the `linkage type`_ for this function 810 811* *paramattr*: If nonzero, the 1-based parameter attribute index into the table 812 of `PARAMATTR_CODE_ENTRY`_ entries. 813 814* *alignment*: The logarithm base 2 of the function's requested alignment, plus 815 1 816 817* *section*: If non-zero, the 1-based section index in the table of 818 `MODULE_CODE_SECTIONNAME`_ entries. 819 820* *visibility*: An encoding of the `visibility`_ of this function 821 822* *gc*: If present and nonzero, the 1-based garbage collector index in the table 823 of `MODULE_CODE_GCNAME`_ entries. 824 825* *unnamed_addr*: If present, an encoding of the 826 :ref:`unnamed_addr<bcunnamedaddr>` attribute of this function 827 828* *prologuedata*: If non-zero, the value index of the prologue data for this function, 829 plus 1. 830 831* *dllstorageclass*: An encoding of the 832 :ref:`dllstorageclass<bcdllstorageclass>` of this function 833 834* *comdat*: An encoding of the COMDAT of this function 835 836* *prefixdata*: If non-zero, the value index of the prefix data for this function, 837 plus 1. 838 839* *personalityfn*: If non-zero, the value index of the personality function for this function, 840 plus 1. 841 842* *preemptionspecifier*: If present, an encoding of the :ref:`runtime preemption specifier<bcpreemptionspecifier>` of this function. 843 844MODULE_CODE_ALIAS Record 845^^^^^^^^^^^^^^^^^^^^^^^^ 846 847``[ALIAS, strtab offset, strtab size, alias type, aliasee val#, linkage, visibility, dllstorageclass, threadlocal, unnamed_addr, preemptionspecifier]`` 848 849The ``ALIAS`` record (code 9) marks the definition of an alias. The operand 850fields are 851 852* *strtab offset*, *strtab size*: Specifies the name of the alias. 853 See `STRTAB_BLOCK Contents`_. 854 855* *alias type*: The type index of the alias 856 857* *aliasee val#*: The value index of the aliased value 858 859* *linkage*: An encoding of the `linkage type`_ for this alias 860 861* *visibility*: If present, an encoding of the `visibility`_ of the alias 862 863* *dllstorageclass*: If present, an encoding of the 864 :ref:`dllstorageclass<bcdllstorageclass>` of the alias 865 866* *threadlocal*: If present, an encoding of the 867 :ref:`thread local property<bcthreadlocal>` of the alias 868 869* *unnamed_addr*: If present, an encoding of the 870 :ref:`unnamed_addr<bcunnamedaddr>` attribute of this alias 871 872* *preemptionspecifier*: If present, an encoding of the :ref:`runtime preemption specifier<bcpreemptionspecifier>` of this alias. 873 874.. _MODULE_CODE_GCNAME: 875 876MODULE_CODE_GCNAME Record 877^^^^^^^^^^^^^^^^^^^^^^^^^ 878 879``[GCNAME, ...string...]`` 880 881The ``GCNAME`` record (code 11) contains a variable number of values 882representing the bytes of a single garbage collector name string. There should 883be one ``GCNAME`` record for each garbage collector name referenced in function 884``gc`` attributes within the module. These records can be referenced by 1-based 885index in the *gc* fields of ``FUNCTION`` records. 886 887.. _PARAMATTR_BLOCK: 888 889PARAMATTR_BLOCK Contents 890------------------------ 891 892The ``PARAMATTR_BLOCK`` block (id 9) contains a table of entries describing the 893attributes of function parameters. These entries are referenced by 1-based index 894in the *paramattr* field of module block `FUNCTION`_ records, or within the 895*attr* field of function block ``INST_INVOKE`` and ``INST_CALL`` records. 896 897Entries within ``PARAMATTR_BLOCK`` are constructed to ensure that each is unique 898(i.e., no two indices represent equivalent attribute lists). 899 900.. _PARAMATTR_CODE_ENTRY: 901 902PARAMATTR_CODE_ENTRY Record 903^^^^^^^^^^^^^^^^^^^^^^^^^^^ 904 905``[ENTRY, attrgrp0, attrgrp1, ...]`` 906 907The ``ENTRY`` record (code 2) contains a variable number of values describing a 908unique set of function parameter attributes. Each *attrgrp* value is used as a 909key with which to look up an entry in the attribute group table described 910in the ``PARAMATTR_GROUP_BLOCK`` block. 911 912.. _PARAMATTR_CODE_ENTRY_OLD: 913 914PARAMATTR_CODE_ENTRY_OLD Record 915^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 916 917.. note:: 918 This is a legacy encoding for attributes, produced by LLVM versions 3.2 and 919 earlier. It is guaranteed to be understood by the current LLVM version, as 920 specified in the :ref:`IR backwards compatibility` policy. 921 922``[ENTRY, paramidx0, attr0, paramidx1, attr1...]`` 923 924The ``ENTRY`` record (code 1) contains an even number of values describing a 925unique set of function parameter attributes. Each *paramidx* value indicates 926which set of attributes is represented, with 0 representing the return value 927attributes, 0xFFFFFFFF representing function attributes, and other values 928representing 1-based function parameters. Each *attr* value is a bitmap with the 929following interpretation: 930 931* bit 0: ``zeroext`` 932* bit 1: ``signext`` 933* bit 2: ``noreturn`` 934* bit 3: ``inreg`` 935* bit 4: ``sret`` 936* bit 5: ``nounwind`` 937* bit 6: ``noalias`` 938* bit 7: ``byval`` 939* bit 8: ``nest`` 940* bit 9: ``readnone`` 941* bit 10: ``readonly`` 942* bit 11: ``noinline`` 943* bit 12: ``alwaysinline`` 944* bit 13: ``optsize`` 945* bit 14: ``ssp`` 946* bit 15: ``sspreq`` 947* bits 16-31: ``align n`` 948* bit 32: ``nocapture`` 949* bit 33: ``noredzone`` 950* bit 34: ``noimplicitfloat`` 951* bit 35: ``naked`` 952* bit 36: ``inlinehint`` 953* bits 37-39: ``alignstack n``, represented as the logarithm 954 base 2 of the requested alignment, plus 1 955 956.. _PARAMATTR_GROUP_BLOCK: 957 958PARAMATTR_GROUP_BLOCK Contents 959------------------------------ 960 961The ``PARAMATTR_GROUP_BLOCK`` block (id 10) contains a table of entries 962describing the attribute groups present in the module. These entries can be 963referenced within ``PARAMATTR_CODE_ENTRY`` entries. 964 965.. _PARAMATTR_GRP_CODE_ENTRY: 966 967PARAMATTR_GRP_CODE_ENTRY Record 968^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 969 970``[ENTRY, grpid, paramidx, attr0, attr1, ...]`` 971 972The ``ENTRY`` record (code 3) contains *grpid* and *paramidx* values, followed 973by a variable number of values describing a unique group of attributes. The 974*grpid* value is a unique key for the attribute group, which can be referenced 975within ``PARAMATTR_CODE_ENTRY`` entries. The *paramidx* value indicates which 976set of attributes is represented, with 0 representing the return value 977attributes, 0xFFFFFFFF representing function attributes, and other values 978representing 1-based function parameters. 979 980Each *attr* is itself represented as a variable number of values: 981 982``kind, key [, ...], [value [, ...]]`` 983 984Each attribute is either a well-known LLVM attribute (possibly with an integer 985value associated with it), or an arbitrary string (possibly with an arbitrary 986string value associated with it). The *kind* value is an integer code 987distinguishing between these possibilities: 988 989* code 0: well-known attribute 990* code 1: well-known attribute with an integer value 991* code 3: string attribute 992* code 4: string attribute with a string value 993 994For well-known attributes (code 0 or 1), the *key* value is an integer code 995identifying the attribute. For attributes with an integer argument (code 1), 996the *value* value indicates the argument. 997 998For string attributes (code 3 or 4), the *key* value is actually a variable 999number of values representing the bytes of a null-terminated string. For 1000attributes with a string argument (code 4), the *value* value is similarly a 1001variable number of values representing the bytes of a null-terminated string. 1002 1003The integer codes are mapped to well-known attributes as follows. 1004 1005* code 1: ``align(<n>)`` 1006* code 2: ``alwaysinline`` 1007* code 3: ``byval`` 1008* code 4: ``inlinehint`` 1009* code 5: ``inreg`` 1010* code 6: ``minsize`` 1011* code 7: ``naked`` 1012* code 8: ``nest`` 1013* code 9: ``noalias`` 1014* code 10: ``nobuiltin`` 1015* code 11: ``nocapture`` 1016* code 12: ``noduplicates`` 1017* code 13: ``noimplicitfloat`` 1018* code 14: ``noinline`` 1019* code 15: ``nonlazybind`` 1020* code 16: ``noredzone`` 1021* code 17: ``noreturn`` 1022* code 18: ``nounwind`` 1023* code 19: ``optsize`` 1024* code 20: ``readnone`` 1025* code 21: ``readonly`` 1026* code 22: ``returned`` 1027* code 23: ``returns_twice`` 1028* code 24: ``signext`` 1029* code 25: ``alignstack(<n>)`` 1030* code 26: ``ssp`` 1031* code 27: ``sspreq`` 1032* code 28: ``sspstrong`` 1033* code 29: ``sret`` 1034* code 30: ``sanitize_address`` 1035* code 31: ``sanitize_thread`` 1036* code 32: ``sanitize_memory`` 1037* code 33: ``uwtable`` 1038* code 34: ``zeroext`` 1039* code 35: ``builtin`` 1040* code 36: ``cold`` 1041* code 37: ``optnone`` 1042* code 38: ``inalloca`` 1043* code 39: ``nonnull`` 1044* code 40: ``jumptable`` 1045* code 41: ``dereferenceable(<n>)`` 1046* code 42: ``dereferenceable_or_null(<n>)`` 1047* code 43: ``convergent`` 1048* code 44: ``safestack`` 1049* code 45: ``argmemonly`` 1050* code 46: ``swiftself`` 1051* code 47: ``swifterror`` 1052* code 48: ``norecurse`` 1053* code 49: ``inaccessiblememonly`` 1054* code 50: ``inaccessiblememonly_or_argmemonly`` 1055* code 51: ``allocsize(<EltSizeParam>[, <NumEltsParam>])`` 1056* code 52: ``writeonly`` 1057* code 53: ``speculatable`` 1058* code 54: ``strictfp`` 1059* code 55: ``sanitize_hwaddress`` 1060* code 56: ``nocf_check`` 1061* code 57: ``optforfuzzing`` 1062* code 58: ``shadowcallstack`` 1063* code 59: ``speculative_load_hardening`` 1064* code 60: ``immarg`` 1065* code 61: ``willreturn`` 1066* code 62: ``nofree`` 1067* code 63: ``nosync`` 1068* code 64: ``sanitize_memtag`` 1069* code 65: ``preallocated`` 1070* code 66: ``no_merge`` 1071* code 67: ``null_pointer_is_valid`` 1072* code 68: ``noundef`` 1073* code 69: ``byref`` 1074* code 70: ``mustprogress`` 1075* code 74: ``vscale_range(<Min>[, <Max>])`` 1076 1077.. note:: 1078 The ``allocsize`` attribute has a special encoding for its arguments. Its two 1079 arguments, which are 32-bit integers, are packed into one 64-bit integer value 1080 (i.e. ``(EltSizeParam << 32) | NumEltsParam``), with ``NumEltsParam`` taking on 1081 the sentinel value -1 if it is not specified. 1082 1083.. note:: 1084 The ``vscale_range`` attribute has a special encoding for its arguments. Its two 1085 arguments, which are 32-bit integers, are packed into one 64-bit integer value 1086 (i.e. ``(Min << 32) | Max``), with ``Max`` taking on the value of ``Min`` if 1087 it is not specified. 1088 1089.. _TYPE_BLOCK: 1090 1091TYPE_BLOCK Contents 1092------------------- 1093 1094The ``TYPE_BLOCK`` block (id 17) contains records which constitute a table of 1095type operator entries used to represent types referenced within an LLVM 1096module. Each record (with the exception of `NUMENTRY`_) generates a single type 1097table entry, which may be referenced by 0-based index from instructions, 1098constants, metadata, type symbol table entries, or other type operator records. 1099 1100Entries within ``TYPE_BLOCK`` are constructed to ensure that each entry is 1101unique (i.e., no two indices represent structurally equivalent types). 1102 1103.. _TYPE_CODE_NUMENTRY: 1104.. _NUMENTRY: 1105 1106TYPE_CODE_NUMENTRY Record 1107^^^^^^^^^^^^^^^^^^^^^^^^^ 1108 1109``[NUMENTRY, numentries]`` 1110 1111The ``NUMENTRY`` record (code 1) contains a single value which indicates the 1112total number of type code entries in the type table of the module. If present, 1113``NUMENTRY`` should be the first record in the block. 1114 1115TYPE_CODE_VOID Record 1116^^^^^^^^^^^^^^^^^^^^^ 1117 1118``[VOID]`` 1119 1120The ``VOID`` record (code 2) adds a ``void`` type to the type table. 1121 1122TYPE_CODE_HALF Record 1123^^^^^^^^^^^^^^^^^^^^^ 1124 1125``[HALF]`` 1126 1127The ``HALF`` record (code 10) adds a ``half`` (16-bit floating point) type to 1128the type table. 1129 1130TYPE_CODE_BFLOAT Record 1131^^^^^^^^^^^^^^^^^^^^^^^ 1132 1133``[BFLOAT]`` 1134 1135The ``BFLOAT`` record (code 23) adds a ``bfloat`` (16-bit brain floating point) 1136type to the type table. 1137 1138TYPE_CODE_FLOAT Record 1139^^^^^^^^^^^^^^^^^^^^^^ 1140 1141``[FLOAT]`` 1142 1143The ``FLOAT`` record (code 3) adds a ``float`` (32-bit floating point) type to 1144the type table. 1145 1146TYPE_CODE_DOUBLE Record 1147^^^^^^^^^^^^^^^^^^^^^^^ 1148 1149``[DOUBLE]`` 1150 1151The ``DOUBLE`` record (code 4) adds a ``double`` (64-bit floating point) type to 1152the type table. 1153 1154TYPE_CODE_LABEL Record 1155^^^^^^^^^^^^^^^^^^^^^^ 1156 1157``[LABEL]`` 1158 1159The ``LABEL`` record (code 5) adds a ``label`` type to the type table. 1160 1161TYPE_CODE_OPAQUE Record 1162^^^^^^^^^^^^^^^^^^^^^^^ 1163 1164``[OPAQUE]`` 1165 1166The ``OPAQUE`` record (code 6) adds an ``opaque`` type to the type table, with 1167a name defined by a previously encountered ``STRUCT_NAME`` record. Note that 1168distinct ``opaque`` types are not unified. 1169 1170TYPE_CODE_INTEGER Record 1171^^^^^^^^^^^^^^^^^^^^^^^^ 1172 1173``[INTEGER, width]`` 1174 1175The ``INTEGER`` record (code 7) adds an integer type to the type table. The 1176single *width* field indicates the width of the integer type. 1177 1178TYPE_CODE_POINTER Record 1179^^^^^^^^^^^^^^^^^^^^^^^^ 1180 1181``[POINTER, pointee type, address space]`` 1182 1183The ``POINTER`` record (code 8) adds a pointer type to the type table. The 1184operand fields are 1185 1186* *pointee type*: The type index of the pointed-to type 1187 1188* *address space*: If supplied, the target-specific numbered address space where 1189 the pointed-to object resides. Otherwise, the default address space is zero. 1190 1191TYPE_CODE_FUNCTION_OLD Record 1192^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1193 1194.. note:: 1195 This is a legacy encoding for functions, produced by LLVM versions 3.0 and 1196 earlier. It is guaranteed to be understood by the current LLVM version, as 1197 specified in the :ref:`IR backwards compatibility` policy. 1198 1199``[FUNCTION_OLD, vararg, ignored, retty, ...paramty... ]`` 1200 1201The ``FUNCTION_OLD`` record (code 9) adds a function type to the type table. 1202The operand fields are 1203 1204* *vararg*: Non-zero if the type represents a varargs function 1205 1206* *ignored*: This value field is present for backward compatibility only, and is 1207 ignored 1208 1209* *retty*: The type index of the function's return type 1210 1211* *paramty*: Zero or more type indices representing the parameter types of the 1212 function 1213 1214TYPE_CODE_ARRAY Record 1215^^^^^^^^^^^^^^^^^^^^^^ 1216 1217``[ARRAY, numelts, eltty]`` 1218 1219The ``ARRAY`` record (code 11) adds an array type to the type table. The 1220operand fields are 1221 1222* *numelts*: The number of elements in arrays of this type 1223 1224* *eltty*: The type index of the array element type 1225 1226TYPE_CODE_VECTOR Record 1227^^^^^^^^^^^^^^^^^^^^^^^ 1228 1229``[VECTOR, numelts, eltty]`` 1230 1231The ``VECTOR`` record (code 12) adds a vector type to the type table. The 1232operand fields are 1233 1234* *numelts*: The number of elements in vectors of this type 1235 1236* *eltty*: The type index of the vector element type 1237 1238TYPE_CODE_X86_FP80 Record 1239^^^^^^^^^^^^^^^^^^^^^^^^^ 1240 1241``[X86_FP80]`` 1242 1243The ``X86_FP80`` record (code 13) adds an ``x86_fp80`` (80-bit floating point) 1244type to the type table. 1245 1246TYPE_CODE_FP128 Record 1247^^^^^^^^^^^^^^^^^^^^^^ 1248 1249``[FP128]`` 1250 1251The ``FP128`` record (code 14) adds an ``fp128`` (128-bit floating point) type 1252to the type table. 1253 1254TYPE_CODE_PPC_FP128 Record 1255^^^^^^^^^^^^^^^^^^^^^^^^^^ 1256 1257``[PPC_FP128]`` 1258 1259The ``PPC_FP128`` record (code 15) adds a ``ppc_fp128`` (128-bit floating point) 1260type to the type table. 1261 1262TYPE_CODE_METADATA Record 1263^^^^^^^^^^^^^^^^^^^^^^^^^ 1264 1265``[METADATA]`` 1266 1267The ``METADATA`` record (code 16) adds a ``metadata`` type to the type table. 1268 1269TYPE_CODE_X86_MMX Record 1270^^^^^^^^^^^^^^^^^^^^^^^^ 1271 1272``[X86_MMX]`` 1273 1274The ``X86_MMX`` record (code 17) adds an ``x86_mmx`` type to the type table. 1275 1276TYPE_CODE_STRUCT_ANON Record 1277^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1278 1279``[STRUCT_ANON, ispacked, ...eltty...]`` 1280 1281The ``STRUCT_ANON`` record (code 18) adds a literal struct type to the type 1282table. The operand fields are 1283 1284* *ispacked*: Non-zero if the type represents a packed structure 1285 1286* *eltty*: Zero or more type indices representing the element types of the 1287 structure 1288 1289TYPE_CODE_STRUCT_NAME Record 1290^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1291 1292``[STRUCT_NAME, ...string...]`` 1293 1294The ``STRUCT_NAME`` record (code 19) contains a variable number of values 1295representing the bytes of a struct name. The next ``OPAQUE`` or 1296``STRUCT_NAMED`` record will use this name. 1297 1298TYPE_CODE_STRUCT_NAMED Record 1299^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1300 1301``[STRUCT_NAMED, ispacked, ...eltty...]`` 1302 1303The ``STRUCT_NAMED`` record (code 20) adds an identified struct type to the 1304type table, with a name defined by a previously encountered ``STRUCT_NAME`` 1305record. The operand fields are 1306 1307* *ispacked*: Non-zero if the type represents a packed structure 1308 1309* *eltty*: Zero or more type indices representing the element types of the 1310 structure 1311 1312TYPE_CODE_FUNCTION Record 1313^^^^^^^^^^^^^^^^^^^^^^^^^ 1314 1315``[FUNCTION, vararg, retty, ...paramty... ]`` 1316 1317The ``FUNCTION`` record (code 21) adds a function type to the type table. The 1318operand fields are 1319 1320* *vararg*: Non-zero if the type represents a varargs function 1321 1322* *retty*: The type index of the function's return type 1323 1324* *paramty*: Zero or more type indices representing the parameter types of the 1325 function 1326 1327TYPE_CODE_X86_AMX Record 1328^^^^^^^^^^^^^^^^^^^^^^^^ 1329 1330``[X86_AMX]`` 1331 1332The ``X86_AMX`` record (code 24) adds an ``x86_amx`` type to the type table. 1333 1334.. _CONSTANTS_BLOCK: 1335 1336CONSTANTS_BLOCK Contents 1337------------------------ 1338 1339The ``CONSTANTS_BLOCK`` block (id 11) ... 1340 1341.. _FUNCTION_BLOCK: 1342 1343FUNCTION_BLOCK Contents 1344----------------------- 1345 1346The ``FUNCTION_BLOCK`` block (id 12) ... 1347 1348In addition to the record types described below, a ``FUNCTION_BLOCK`` block may 1349contain the following sub-blocks: 1350 1351* `CONSTANTS_BLOCK`_ 1352* `VALUE_SYMTAB_BLOCK`_ 1353* `METADATA_ATTACHMENT`_ 1354 1355.. _VALUE_SYMTAB_BLOCK: 1356 1357VALUE_SYMTAB_BLOCK Contents 1358--------------------------- 1359 1360The ``VALUE_SYMTAB_BLOCK`` block (id 14) ... 1361 1362.. _METADATA_BLOCK: 1363 1364METADATA_BLOCK Contents 1365----------------------- 1366 1367The ``METADATA_BLOCK`` block (id 15) ... 1368 1369.. _METADATA_ATTACHMENT: 1370 1371METADATA_ATTACHMENT Contents 1372---------------------------- 1373 1374The ``METADATA_ATTACHMENT`` block (id 16) ... 1375 1376.. _STRTAB_BLOCK: 1377 1378STRTAB_BLOCK Contents 1379--------------------- 1380 1381The ``STRTAB`` block (id 23) contains a single record (``STRTAB_BLOB``, id 1) 1382with a single blob operand containing the bitcode file's string table. 1383 1384Strings in the string table are not null terminated. A record's *strtab 1385offset* and *strtab size* operands specify the byte offset and size of a 1386string within the string table. 1387 1388The string table is used by all preceding blocks in the bitcode file that are 1389not succeeded by another intervening ``STRTAB`` block. Normally a bitcode 1390file will have a single string table, but it may have more than one if it 1391was created by binary concatenation of multiple bitcode files. 1392