1363 lines · plain
1.. role:: raw-html(raw)2 :format: html3 4========================5LLVM Bitcode File Format6========================7 8.. contents::9 :local:10 11Abstract12========13 14This document describes the LLVM bitstream file format and the encoding of the15LLVM IR into it.16 17Overview18========19 20What is commonly known as the LLVM bitcode file format (also, sometimes21anachronistically known as bytecode) is actually two things: a `bitstream22container format`_ and an `encoding of LLVM IR`_ into the container format.23 24The bitstream format is an abstract encoding of structured data, very similar to25XML in some ways. Like XML, bitstream files contain tags, and nested26structures, and you can parse the file without having to understand the tags.27Unlike XML, the bitstream format is a binary encoding, and unlike XML it28provides a mechanism for the file to self-describe "abbreviations", which are29effectively size optimizations for the content.30 31LLVM IR files may be optionally embedded into a `wrapper`_ structure, or in a32`native object file`_. Both of these mechanisms make it easy to embed extra33data along with LLVM IR files.34 35This document first describes the LLVM bitstream format, describes the wrapper36format, then describes the record structure used by LLVM IR files.37 38.. _bitstream container format:39 40Bitstream Format41================42 43The bitstream format is literally a stream of bits, with a very simple44structure. 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 be57used to dump and inspect arbitrary bitstreams, which is very useful for58understanding the encoding.59 60.. _magic number:61 62Magic Numbers63-------------64 65The first four bytes of a bitstream are used as an application-specific magic66number. Generic bitcode tools may look at the first four bytes to determine67whether the stream is a known stream type. However, these tools should *not*68determine whether a bitstream is valid based on its magic number alone. New69application-specific bitstream formats are being developed all the time; tools70should not reject them just because they have a hitherto unseen magic number.71 72.. _primitives:73 74Primitives75----------76 77A bitstream literally consists of a stream of bits, which are read in order78starting with the least significant bit of each byte. The stream is made up of79a 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 as81`Variable Width Integers`_.82 83.. _Fixed Width Integers:84.. _fixed-width value:85 86Fixed Width Integers87^^^^^^^^^^^^^^^^^^^^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 are91used 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 Integers99^^^^^^^^^^^^^^^^^^^^^^^100 101Variable-width integer (VBR) values encode values of arbitrary size, optimizing102for the case where the values are small. Given a 4-bit VBR field, any 3-bit103value (0 through 7) is encoded directly, with the high bit set to zero. Values104larger than N-1 bits emit their bits in a series of N-1 bit chunks, where all105but the last set the high bit.106 107For example, the value 30 (0x1E) is encoded as 62 (0b0011'1110) when emitted as108a vbr4 value. The first set of four bits starting from the least significant109indicates the value 6 (110) with a continuation piece (indicated by a high bit110of 1). The next set of four bits indicates a value of 24 (011 << 3) with no111continuation. The sum (6+24) yields the value 30.112 113.. _char6-encoded value:114 1156-bit characters116^^^^^^^^^^^^^^^^117 1186-bit characters encode common characters into a fixed 6-bit field. They119represent the following characters with the following 6-bit values:120 121::122 123 'a' .. 'z' --- 0 .. 25124 'A' .. 'Z' --- 26 .. 51125 '0' .. '9' --- 52 .. 61126 '.' --- 62127 '_' --- 63128 129This encoding is only suitable for encoding characters and strings that consist130only of the above characters. It is completely incapable of encoding characters131not in the set.132 133Word Alignment134^^^^^^^^^^^^^^135 136Occasionally, it is useful to emit zero bits until the bitstream is a multiple137of 32 bits. This ensures that the bit position in the stream can be represented138as a multiple of 32-bit words.139 140Abbreviation IDs141----------------142 143A bitstream is a sequential series of `Blocks`_ and `Data Records`_. Both of144these start with an abbreviation ID encoded as a fixed-bitwidth field. The145width is specified by the current block, as described below. The value of the146abbreviation ID specifies either a builtin ID (which have special meanings,147defined below) or one of the abbreviation IDs defined for the current block by148the 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 new155 block.156 157* 2 - `DEFINE_ABBREV`_ --- This defines a new abbreviation.158 159* 3 - `UNABBREV_RECORD`_ --- This ID specifies the definition of an160 unabbreviated record.161 162Abbreviation IDs 4 and above are defined by the stream itself, and specify an163`abbreviated record encoding`_.164 165.. _Blocks:166 167Blocks168------169 170Blocks in a bitstream denote nested regions of the stream, and are identified by171a content-specific id number (for example, LLVM IR uses an ID of 12 to represent172function bodies). Block IDs 0-7 are reserved for `standard blocks`_ whose173meaning is defined by Bitcode; block IDs 8 and greater are application174specific. Nested blocks capture the hierarchical structure of the data encoded175in it, and various properties are associated with blocks as the file is parsed.176Block definitions allow the reader to efficiently skip blocks in constant time177if the reader wants a summary of blocks, or if it wants to efficiently skip data178it does not understand. The LLVM IR reader uses this mechanism to skip function179bodies, lazily reading them on demand.180 181When reading and encoding the stream, several properties are maintained for the182block. In particular, each block maintains:183 184#. A current abbrev id width. This value starts at 2 at the beginning of the185 stream, and is set every time a block record is entered. The block entry186 specifies the abbrev id width for the body of the block.187 188#. A set of abbreviations. Abbreviations may be defined within a block, in189 which case they are only defined in that block (neither subblocks nor190 enclosing blocks see the abbreviation). Abbreviations can also be defined191 inside a `BLOCKINFO`_ block, in which case they are defined in all blocks192 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 has195its own set of abbreviations, and its own abbrev id width. When a sub-block is196popped, the saved values are restored.197 198.. _ENTER_SUBBLOCK:199 200ENTER_SUBBLOCK Encoding201^^^^^^^^^^^^^^^^^^^^^^^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 block208record. The ``blockid`` value is encoded as an 8-bit VBR identifier, and209indicates the type of block being entered, which can be a `standard block`_ or210an application-specific block. The ``newabbrevlen`` value is a 4-bit VBR, which211specifies the abbrev id width for the sub-block. The ``blocklen`` value is a21232-bit aligned value that specifies the size of the subblock in 32-bit213words. This value allows the reader to skip over the entire block in one jump.214 215.. _END_BLOCK:216 217END_BLOCK Encoding218^^^^^^^^^^^^^^^^^^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 even224multiple of 32-bits.225 226.. _Data Records:227 228Data Records229------------230 231Data records consist of a record code and a number of (up to) 64-bit integer232values. The interpretation of the code and values is application-specific and233may vary between different block types. Records can be encoded either using an234unabbrev 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 is236``MODULE_CODE_TRIPLE``, and the values of the record are the ASCII codes for the237characters in the string.238 239.. _UNABBREV_RECORD:240 241UNABBREV_RECORD Encoding242^^^^^^^^^^^^^^^^^^^^^^^^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 both249completely general and extremely inefficient. It can describe an arbitrary250record by emitting the code and operands as VBRs.251 252For example, emitting an LLVM IR target triple as an unabbreviated record253requires emitting the ``UNABBREV_RECORD`` abbrevid, a vbr6 for the254``MODULE_CODE_TRIPLE`` code, a vbr6 for the length of the string, which is equal255to the number of operands, and a vbr6 for each character. Because there are no256letters with values less than 32, each letter would need to be emitted as at257least a two-part VBR, which means that each letter would require at least 12258bits. This is not an efficient encoding, but it is fully general.259 260.. _abbreviated record encoding:261 262Abbreviated Record Encoding263^^^^^^^^^^^^^^^^^^^^^^^^^^^264 265``[<abbrevid>, fields...]``266 267An abbreviated record is an abbreviation id followed by a set of fields that are268encoded according to the `abbreviation definition`_. This allows records to be269encoded significantly more densely than records encoded with the270`UNABBREV_RECORD`_ type, and allows the abbreviation types to be specified in271the stream itself, which allows the files to be completely self describing. The272actual encoding of abbreviations is defined below.273 274The record code, which is the first field of an abbreviated record, may be275encoded in the abbreviation definition (as a literal operand) or supplied in the276abbreviated record (as a Fixed or VBR operand value).277 278.. _abbreviation definition:279 280Abbreviations281-------------282 283Abbreviations are an important form of compression for bitstreams. The idea is284to specify a dense encoding for a class of records once, then use that encoding285to emit many records. It takes space to emit the encoding into the file, but286the space is recouped (hopefully plus some) when the records that use it are287emitted.288 289Abbreviations can be determined dynamically per client, per file. Because the290abbreviations are stored in the bitstream itself, different streams of the same291format can contain different sets of abbreviations according to the needs of the292specific stream. As a concrete example, LLVM IR files usually emit an293abbreviation for binary operators. If a specific LLVM module contained no or294few binary operators, the abbreviation does not need to be emitted.295 296.. _DEFINE_ABBREV:297 298DEFINE_ABBREV Encoding299^^^^^^^^^^^^^^^^^^^^^^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 defined306abbreviations in the scope of this block. This definition only exists inside307this immediate block --- it is not visible in subblocks or enclosing blocks.308Abbreviations are implicitly assigned IDs sequentially starting from 4 (the309first application-defined abbreviation ID). Any abbreviations defined in a310``BLOCKINFO`` record for the particular block type receive IDs first, in order,311followed by any abbreviations defined within the block itself. Abbreviated data312records reference this ID to indicate what abbreviation they are invoking.313 314An abbreviation definition consists of the ``DEFINE_ABBREV`` abbrevid followed315by a VBR that specifies the number of abbrev operands, then the abbrev operands316themselves. Abbreviation operands come in three forms. They all start with a317single bit that indicates whether the abbrev operand is a literal operand (when318the 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 in322 the result is always a single specific value. This specific value is emitted323 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 data327 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 do331 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`_, whose336 width is specified by the operand's extra data.337 338* VBR (code 2): The field should be emitted as a `variable-width value`_, whose339 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 no342 extra data, but expects another operand to follow it, indicating the element343 type of the array. When reading an array in an abbreviated record, the first344 integer is a vbr6 that indicates the array length, followed by the encoded345 elements of the array. An array may only occur as the last operand of an346 abbreviation (except for the one final operand that gives the array's347 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 an351 array element type.352 353* Blob (code 5): This field is emitted as a vbr6, followed by padding to a354 32-bit boundary (for alignment) and an array of 8-bit objects. The array of355 bytes is further followed by tail padding to ensure that its total length is a356 multiple of 4 bytes. This makes it very efficient for the reader to decode357 the data without having to make a copy of it: it can use a pointer to the data358 in the mapped in file and poke directly at it. A blob may only occur as the359 last operand of an abbreviation.360 361For example, target triples in LLVM modules are encoded as a record of the form362``[TRIPLE, 'a', 'b', 'c', 'd']``. Consider if the bitstream emitted the363following 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 emitted372as: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 IR383 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 a390abbrev id width of 3). Without the abbreviation, significantly more space would391be required to emit the target triple. Also, because the ``TRIPLE`` value is392not emitted as a literal in the abbreviation, the abbreviation can also be used393for any other string value.394 395.. _standard blocks:396.. _standard block:397 398Standard Blocks399---------------400 401In addition to the basic block structure and record encodings, the bitstream402also defines specific built-in block types. These block types specify how the403stream is to be decoded or other metadata. In the future, new standard blocks404may be added. Block IDs 0-7 are reserved for standard blocks.405 406.. _BLOCKINFO:407 408#0 - BLOCKINFO Block409^^^^^^^^^^^^^^^^^^^^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 which423block ID is being described. There must be a ``SETBID`` record prior to any424other records.425 426Standard ``DEFINE_ABBREV`` records can occur inside ``BLOCKINFO`` blocks, but427unlike their occurrence in normal blocks, the abbreviation is defined for blocks428matching the block ID we are describing, *not* the ``BLOCKINFO`` block429itself. The abbreviations defined in ``BLOCKINFO`` blocks receive abbreviation430IDs as described in `DEFINE_ABBREV`_.431 432The ``BLOCKNAME`` record (code 2) can optionally occur in this block. The433elements 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 of438the record are the bytes for the string name of the record. llvm-bcanalyzer can439use 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 the443corresponding blocks. It is not safe to skip them.444 445.. _wrapper:446 447Bitcode Wrapper Format448======================449 450Bitcode files for LLVM IR may optionally be wrapped in a simple wrapper451structure. This structure contains a simple header that indicates the offset452and size of the embedded BC file. This allows additional information to be453stored 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 the460rest of the bitcode file fields). The Magic number is always ``0x0B17C0DE`` and461the version is currently always ``0``. The Offset field is the offset in bytes462to the start of the bitcode stream in the file, and the Size field is the size463in bytes of the stream. CPUType is a target-specific value that can be used to464encode the CPU of the target.465 466.. _native object file:467 468Native Object File Wrapper Format469=================================470 471Bitcode files for LLVM IR may also be wrapped in a native object file472(i.e., ELF, COFF, Mach-O). The bitcode must be stored in a section of the object473file named ``__LLVM,__bitcode`` for Mach-O or ``.llvmbc`` for the other object474formats. ELF objects additionally support a ``.llvm.lto`` section for475:doc:`FatLTO`, which contains bitcode suitable for LTO compilation (i.e., bitcode476that has gone through a pre-link LTO pipeline). The ``.llvmbc`` section477predates FatLTO support in LLVM, and may not always contain bitcode that is478suitable for LTO (i.e., from ``-fembed-bitcode``). The wrapper format is useful479for accommodating LTO in compilation pipelines where intermediate objects must480be native object files which contain metadata in other sections.481 482Not all tools support this format. For example, lld and the gold plugin will483ignore the ``.llvmbc`` section when linking object files, but can use484``.llvm.lto`` sections when passed the correct command-line options.485 486.. _encoding of LLVM IR:487 488LLVM IR Encoding489================490 491LLVM IR is encoded into a bitstream by defining blocks and records. It uses492blocks for things like constant pools, functions, symbol tables, etc. It uses493records for things like instructions, global variable descriptors, type494descriptions, etc. This document does not describe the set of abbreviations495that the writer uses, as these are fully self-described in the file, and the496reader is not allowed to build in any knowledge of this.497 498Basics499------500 501LLVM IR Magic Number502^^^^^^^^^^^^^^^^^^^^503 504The magic number for LLVM IR files is:505 506:raw-html:`<tt><blockquote>`507['B'\ :sub:`8`, 'C'\ :sub:`8`, 0x0\ :sub:`4`, 0xC\ :sub:`4`, 0xE\ :sub:`4`, 0xD\ :sub:`4`]508:raw-html:`</blockquote></tt>`509 510.. _Signed VBRs:511 512Signed VBRs513^^^^^^^^^^^514 515`Variable Width Integer`_ encoding is an efficient way to encode arbitrary sized516unsigned values, but is an extremely inefficient for encoding signed values, as517signed values are otherwise treated as maximally large unsigned values.518 519As such, signed VBR values of a specific width are emitted as follows:520 521* Positive values are emitted as VBRs of the specified width, but with their522 value shifted left by one.523 524* Negative values are emitted as VBRs of the specified width, but the negated525 value is shifted left by one, and the low bit is set.526 527With this encoding, small positive and small negative values can both be emitted528efficiently. Signed VBR encoding is used in ``CST_CODE_INTEGER`` and529``CST_CODE_WIDE_INTEGER`` records within ``CONSTANTS_BLOCK`` blocks.530It is also used for phi instruction operands in `MODULE_CODE_VERSION`_ 1.531 532LLVM IR Blocks533^^^^^^^^^^^^^^534 535LLVM IR is defined with the following blocks:536 537* 8 --- `MODULE_BLOCK`_ --- This is the top-level block that contains the entire538 module, and describes a variety of per-module information.539 540* 9 --- `PARAMATTR_BLOCK`_ --- This enumerates the parameter attributes.541 542* 10 --- `PARAMATTR_GROUP_BLOCK`_ --- This describes the attribute group table.543 544* 11 --- `CONSTANTS_BLOCK`_ --- This describes constants for a module or545 function.546 547* 12 --- `FUNCTION_BLOCK`_ --- This describes a function body.548 549* 14 --- `VALUE_SYMTAB_BLOCK`_ --- This describes a value symbol table.550 551* 15 --- `METADATA_BLOCK`_ --- This describes metadata items.552 553* 16 --- `METADATA_ATTACHMENT`_ --- This contains records associating metadata554 with function instruction values.555 556* 17 --- `TYPE_BLOCK`_ --- This describes all of the types in the module.557 558* 23 --- `STRTAB_BLOCK`_ --- The bitcode file's string table.559 560.. _MODULE_BLOCK:561 562MODULE_BLOCK Contents563---------------------564 565The ``MODULE_BLOCK`` block (id 8) is the top-level block for LLVM bitcode files,566and each module in a bitcode file must contain exactly one. A bitcode file with567multi-module bitcode is valid. In addition to records (described below)568containing information about the module, a ``MODULE_BLOCK`` block may contain569the following sub-blocks:570 571* `BLOCKINFO`_572* `PARAMATTR_BLOCK`_573* `PARAMATTR_GROUP_BLOCK`_574* `TYPE_BLOCK`_575* `VALUE_SYMTAB_BLOCK`_576* `CONSTANTS_BLOCK`_577* `FUNCTION_BLOCK`_578* `METADATA_BLOCK`_579 580.. _MODULE_CODE_VERSION:581 582MODULE_CODE_VERSION Record583^^^^^^^^^^^^^^^^^^^^^^^^^^584 585``[VERSION, version#]``586 587The ``VERSION`` record (code 1) contains a single value indicating the format588version. Versions 0, 1, and 2 are supported at this time. The difference between589version 0 and 1 is in the encoding of instruction operands in590each `FUNCTION_BLOCK`_.591 592In version 0, each value defined by an instruction is assigned an ID593unique to the function. Function-level value IDs are assigned starting from594``NumModuleValues`` since they share the same namespace as module-level595values. The value enumerator resets after each function. When a value is596an operand of an instruction, the value ID is used to represent the operand.597For large functions or large modules, these operand values can be large.598 599The encoding in version 1 attempts to avoid large operand values600in common cases. Instead of using the value ID directly, operands are601encoded as relative to the current instruction. Thus, if an operand602is the value defined by the previous instruction, the operand603will be encoded as 1.604 605For example, instead of606 607.. code-block:: none608 609 #n = load #n-1610 #n+1 = icmp eq #n, #const0611 br #n+1, label #(bb1), label #(bb2)612 613version 1 will encode the instructions as614 615.. code-block:: none616 617 #n = load #1618 #n+1 = icmp eq #1, (#n+1)-#const0619 br #1, label #(bb1), label #(bb2)620 621Note in the example that operands which are constants also use622the relative encoding, while operands like basic block labels623do not use the relative encoding.624 625Forward references will result in a negative value.626This can be inefficient, as operands are normally encoded627as unsigned VBRs. However, forward references are rare, except in the628case of phi instructions. For phi instructions, operands are encoded as629`Signed VBRs`_ to deal with forward references.630 631In version 2, the meaning of module records ``FUNCTION``, ``GLOBALVAR``,632``ALIAS``, ``IFUNC`` and ``COMDAT`` change such that the first two operands633specify an offset and size of a string in a string table (see `STRTAB_BLOCK634Contents`_), the function name is removed from the ``FNENTRY`` record in the635value symbol table, and the top-level ``VALUE_SYMTAB_BLOCK`` may only contain636``FNENTRY`` records.637 638MODULE_CODE_TRIPLE Record639^^^^^^^^^^^^^^^^^^^^^^^^^640 641``[TRIPLE, ...string...]``642 643The ``TRIPLE`` record (code 2) contains a variable number of values representing644the bytes of the ``target triple`` specification string.645 646MODULE_CODE_DATALAYOUT Record647^^^^^^^^^^^^^^^^^^^^^^^^^^^^^648 649``[DATALAYOUT, ...string...]``650 651The ``DATALAYOUT`` record (code 3) contains a variable number of values652representing the bytes of the ``target datalayout`` specification string.653 654MODULE_CODE_ASM Record655^^^^^^^^^^^^^^^^^^^^^^656 657``[ASM, ...string...]``658 659The ``ASM`` record (code 4) contains a variable number of values representing660the bytes of ``module asm`` strings, with individual assembly blocks separated661by newline (ASCII 10) characters.662 663.. _MODULE_CODE_SECTIONNAME:664 665MODULE_CODE_SECTIONNAME Record666^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^667 668``[SECTIONNAME, ...string...]``669 670The ``SECTIONNAME`` record (code 5) contains a variable number of values671representing the bytes of a single section name string. There should be one672``SECTIONNAME`` record for each section name referenced (e.g., in global673variable or function ``section`` attributes) within the module. These records674can be referenced by the 1-based index in the *section* fields of ``GLOBALVAR``675or ``FUNCTION`` records.676 677MODULE_CODE_DEPLIB Record678^^^^^^^^^^^^^^^^^^^^^^^^^679 680``[DEPLIB, ...string...]``681 682The ``DEPLIB`` record (code 6) contains a variable number of values representing683the bytes of a single dependent library name string, one of the libraries684mentioned in a ``deplibs`` declaration. There should be one ``DEPLIB`` record685for each library name referenced.686 687MODULE_CODE_GLOBALVAR Record688^^^^^^^^^^^^^^^^^^^^^^^^^^^^689 690``[GLOBALVAR, strtab offset, strtab size, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr, externally_initialized, dllstorageclass, comdat, attributes, preemptionspecifier]``691 692The ``GLOBALVAR`` record (code 7) marks the declaration or definition of a693global variable. The operand fields are:694 695* *strtab offset*, *strtab size*: Specifies the name of the global variable.696 See `STRTAB_BLOCK Contents`_.697 698* *pointer type*: The type index of the pointer type used to point to this699 global variable700 701* *isconst*: Non-zero if the variable is treated as constant within the module,702 or zero if it is not703 704* *initid*: If non-zero, the value index of the initializer for this variable,705 plus 1.706 707.. _linkage type:708 709* *linkage*: An encoding of the linkage type for this variable:710 711 * ``external``: code 0712 * ``weak``: code 1713 * ``appending``: code 2714 * ``internal``: code 3715 * ``linkonce``: code 4716 * ``dllimport``: code 5717 * ``dllexport``: code 6718 * ``extern_weak``: code 7719 * ``common``: code 8720 * ``private``: code 9721 * ``weak_odr``: code 10722 * ``linkonce_odr``: code 11723 * ``available_externally``: code 12724 * deprecated : code 13725 * deprecated : code 14726 727* alignment*: The logarithm base 2 of the variable's requested alignment, plus 1728 729* *section*: If non-zero, the 1-based section index in the table of730 `MODULE_CODE_SECTIONNAME`_ entries.731 732.. _visibility:733 734* *visibility*: If present, an encoding of the visibility of this variable:735 736 * ``default``: code 0737 * ``hidden``: code 1738 * ``protected``: code 2739 740.. _bcthreadlocal:741 742* *threadlocal*: If present, an encoding of the thread local storage mode of the743 variable:744 745 * ``not thread local``: code 0746 * ``thread local; default TLS model``: code 1747 * ``localdynamic``: code 2748 * ``initialexec``: code 3749 * ``localexec``: code 4750 751.. _bcunnamedaddr:752 753* *unnamed_addr*: If present, an encoding of the ``unnamed_addr`` attribute of this754 variable:755 756 * not ``unnamed_addr``: code 0757 * ``unnamed_addr``: code 1758 * ``local_unnamed_addr``: code 2759 760.. _bcdllstorageclass:761 762* *dllstorageclass*: If present, an encoding of the DLL storage class of this variable:763 764 * ``default``: code 0765 * ``dllimport``: code 1766 * ``dllexport``: code 2767 768* *comdat*: An encoding of the COMDAT of this function769 770* *attributes*: If nonzero, the 1-based index into the table of AttributeLists.771 772.. _bcpreemptionspecifier:773 774* *preemptionspecifier*: If present, an encoding of the runtime preemption specifier of this variable:775 776 * ``dso_preemptable``: code 0777 * ``dso_local``: code 1778 779.. _FUNCTION:780 781MODULE_CODE_FUNCTION Record782^^^^^^^^^^^^^^^^^^^^^^^^^^^783 784``[FUNCTION, strtab offset, strtab size, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prologuedata, dllstorageclass, comdat, prefixdata, personalityfn, preemptionspecifier]``785 786The ``FUNCTION`` record (code 8) marks the declaration or definition of a787function. The operand fields are:788 789* *strtab offset*, *strtab size*: Specifies the name of the function.790 See `STRTAB_BLOCK Contents`_.791 792* *type*: The type index of the function type describing this function793 794* *callingconv*: The calling convention number:795 * ``ccc``: code 0796 * ``fastcc``: code 8797 * ``coldcc``: code 9798 * ``anyregcc``: code 13799 * ``preserve_mostcc``: code 14800 * ``preserve_allcc``: code 15801 * ``swiftcc`` : code 16802 * ``cxx_fast_tlscc``: code 17803 * ``tailcc`` : code 18804 * ``cfguard_checkcc`` : code 19805 * ``swifttailcc`` : code 20806 * ``x86_stdcallcc``: code 64807 * ``x86_fastcallcc``: code 65808 * ``arm_apcscc``: code 66809 * ``arm_aapcscc``: code 67810 * ``arm_aapcs_vfpcc``: code 68811 812* isproto*: Non-zero if this entry represents a declaration rather than a813 definition814 815* *linkage*: An encoding of the `linkage type`_ for this function816 817* *paramattr*: If nonzero, the 1-based parameter attribute index into the table818 of `PARAMATTR_CODE_ENTRY`_ entries.819 820* *alignment*: The logarithm base 2 of the function's requested alignment, plus821 1822 823* *section*: If non-zero, the 1-based section index in the table of824 `MODULE_CODE_SECTIONNAME`_ entries.825 826* *visibility*: An encoding of the `visibility`_ of this function827 828* *gc*: If present and nonzero, the 1-based garbage collector index in the table829 of `MODULE_CODE_GCNAME`_ entries.830 831* *unnamed_addr*: If present, an encoding of the832 :ref:`unnamed_addr<bcunnamedaddr>` attribute of this function833 834* *prologuedata*: If non-zero, the value index of the prologue data for this function,835 plus 1.836 837* *dllstorageclass*: An encoding of the838 :ref:`dllstorageclass<bcdllstorageclass>` of this function839 840* *comdat*: An encoding of the COMDAT of this function841 842* *prefixdata*: If non-zero, the value index of the prefix data for this function,843 plus 1.844 845* *personalityfn*: If non-zero, the value index of the personality function for this function,846 plus 1.847 848* *preemptionspecifier*: If present, an encoding of the :ref:`runtime preemption specifier<bcpreemptionspecifier>` of this function.849 850MODULE_CODE_ALIAS Record851^^^^^^^^^^^^^^^^^^^^^^^^852 853``[ALIAS, strtab offset, strtab size, alias type, aliasee val#, linkage, visibility, dllstorageclass, threadlocal, unnamed_addr, preemptionspecifier]``854 855The ``ALIAS`` record (code 9) marks the definition of an alias. The operand856fields are857 858* *strtab offset*, *strtab size*: Specifies the name of the alias.859 See `STRTAB_BLOCK Contents`_.860 861* *alias type*: The type index of the alias862 863* *aliasee val#*: The value index of the aliased value864 865* *linkage*: An encoding of the `linkage type`_ for this alias866 867* *visibility*: If present, an encoding of the `visibility`_ of the alias868 869* *dllstorageclass*: If present, an encoding of the870 :ref:`dllstorageclass<bcdllstorageclass>` of the alias871 872* *threadlocal*: If present, an encoding of the873 :ref:`thread local property<bcthreadlocal>` of the alias874 875* *unnamed_addr*: If present, an encoding of the876 :ref:`unnamed_addr<bcunnamedaddr>` attribute of this alias877 878* *preemptionspecifier*: If present, an encoding of the :ref:`runtime preemption specifier<bcpreemptionspecifier>` of this alias.879 880.. _MODULE_CODE_GCNAME:881 882MODULE_CODE_GCNAME Record883^^^^^^^^^^^^^^^^^^^^^^^^^884 885``[GCNAME, ...string...]``886 887The ``GCNAME`` record (code 11) contains a variable number of values888representing the bytes of a single garbage collector name string. There should889be one ``GCNAME`` record for each garbage collector name referenced in function890``gc`` attributes within the module. These records can be referenced by 1-based891index in the *gc* fields of ``FUNCTION`` records.892 893.. _PARAMATTR_BLOCK:894 895PARAMATTR_BLOCK Contents896------------------------897 898The ``PARAMATTR_BLOCK`` block (id 9) contains a table of entries describing the899attributes of function parameters. These entries are referenced by 1-based index900in the *paramattr* field of module block `FUNCTION`_ records, or within the901*attr* field of function block ``INST_INVOKE`` and ``INST_CALL`` records.902 903Entries within ``PARAMATTR_BLOCK`` are constructed to ensure that each is unique904(i.e., no two indices represent equivalent attribute lists).905 906.. _PARAMATTR_CODE_ENTRY:907 908PARAMATTR_CODE_ENTRY Record909^^^^^^^^^^^^^^^^^^^^^^^^^^^910 911``[ENTRY, attrgrp0, attrgrp1, ...]``912 913The ``ENTRY`` record (code 2) contains a variable number of values describing a914unique set of function parameter attributes. Each *attrgrp* value is used as a915key with which to look up an entry in the attribute group table described916in the ``PARAMATTR_GROUP_BLOCK`` block.917 918.. _PARAMATTR_CODE_ENTRY_OLD:919 920PARAMATTR_CODE_ENTRY_OLD Record921^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^922 923.. note::924 This is a legacy encoding for attributes, produced by LLVM versions 3.2 and925 earlier. It is guaranteed to be understood by the current LLVM version, as926 specified in the :ref:`IR backwards compatibility` policy.927 928``[ENTRY, paramidx0, attr0, paramidx1, attr1...]``929 930The ``ENTRY`` record (code 1) contains an even number of values describing a931unique set of function parameter attributes. Each *paramidx* value indicates932which set of attributes is represented, with 0 representing the return value933attributes, 0xFFFFFFFF representing function attributes, and other values934representing 1-based function parameters. Each *attr* value is a bitmap with the935following interpretation:936 937* bit 0: ``zeroext``938* bit 1: ``signext``939* bit 2: ``noreturn``940* bit 3: ``inreg``941* bit 4: ``sret``942* bit 5: ``nounwind``943* bit 6: ``noalias``944* bit 7: ``byval``945* bit 8: ``nest``946* bit 9: ``readnone``947* bit 10: ``readonly``948* bit 11: ``noinline``949* bit 12: ``alwaysinline``950* bit 13: ``optsize``951* bit 14: ``ssp``952* bit 15: ``sspreq``953* bits 16-31: ``align n``954* bit 32: ``nocapture``955* bit 33: ``noredzone``956* bit 34: ``noimplicitfloat``957* bit 35: ``naked``958* bit 36: ``inlinehint``959* bits 37-39: ``alignstack n``, represented as the logarithm960 base 2 of the requested alignment, plus 1961 962.. _PARAMATTR_GROUP_BLOCK:963 964PARAMATTR_GROUP_BLOCK Contents965------------------------------966 967The ``PARAMATTR_GROUP_BLOCK`` block (id 10) contains a table of entries968describing the attribute groups present in the module. These entries can be969referenced within ``PARAMATTR_CODE_ENTRY`` entries.970 971.. _PARAMATTR_GRP_CODE_ENTRY:972 973PARAMATTR_GRP_CODE_ENTRY Record974^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^975 976``[ENTRY, grpid, paramidx, attr0, attr1, ...]``977 978The ``ENTRY`` record (code 3) contains *grpid* and *paramidx* values, followed979by a variable number of values describing a unique group of attributes. The980*grpid* value is a unique key for the attribute group, which can be referenced981within ``PARAMATTR_CODE_ENTRY`` entries. The *paramidx* value indicates which982set of attributes is represented, with 0 representing the return value983attributes, 0xFFFFFFFF representing function attributes, and other values984representing 1-based function parameters.985 986Each *attr* is itself represented as a variable number of values:987 988``kind, key [, ...], [value [, ...]]``989 990Each attribute is either a well-known LLVM attribute (possibly with an integer991value associated with it), or an arbitrary string (possibly with an arbitrary992string value associated with it). The *kind* value is an integer code993distinguishing between these possibilities:994 995* code 0: well-known attribute996* code 1: well-known attribute with an integer value997* code 3: string attribute998* code 4: string attribute with a string value999 1000For well-known attributes (code 0 or 1), the *key* value is an integer code1001identifying the attribute. For attributes with an integer argument (code 1),1002the *value* value indicates the argument.1003 1004For string attributes (code 3 or 4), the *key* value is actually a variable1005number of values representing the bytes of a null-terminated string. For1006attributes with a string argument (code 4), the *value* value is similarly a1007variable number of values representing the bytes of a null-terminated string.1008 1009The integer codes are mapped to attributes as described in the1010``AttributeKindCodes`` enumeration in the file `LLVMBitCodes.h1011<https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Bitcode/LLVMBitCodes.h>`_.1012 1013For example:1014 1015::1016 1017 enum AttributeKindCodes {1018 // = 0 is unused1019 ATTR_KIND_ALIGNMENT = 1,1020 ATTR_KIND_ALWAYS_INLINE = 2,1021 ...1022 }1023 1024Correspond to:1025 1026* code 1: ``align(<n>)``1027* code 2: ``alwaysinline``1028 1029The mappings between the enumeration and the attribute name string may be found1030in the file `Attributes.td1031<https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/Attributes.td>`_.1032 1033.. note::1034 The ``allocsize`` attribute has a special encoding for its arguments. Its two1035 arguments, which are 32-bit integers, are packed into one 64-bit integer value1036 (i.e., ``(EltSizeParam << 32) | NumEltsParam``), with ``NumEltsParam`` taking on1037 the sentinel value -1 if it is not specified.1038 1039.. note::1040 The ``vscale_range`` attribute has a special encoding for its arguments. Its two1041 arguments, which are 32-bit integers, are packed into one 64-bit integer value1042 (i.e., ``(Min << 32) | Max``), with ``Max`` taking on the value of ``Min`` if1043 it is not specified.1044 1045.. _TYPE_BLOCK:1046 1047TYPE_BLOCK Contents1048-------------------1049 1050The ``TYPE_BLOCK`` block (id 17) contains records which constitute a table of1051type operator entries used to represent types referenced within an LLVM1052module. Each record (with the exception of `NUMENTRY`_) generates a single type1053table entry, which may be referenced by 0-based index from instructions,1054constants, metadata, type symbol table entries, or other type operator records.1055 1056Entries within ``TYPE_BLOCK`` are constructed to ensure that each entry is1057unique (i.e., no two indices represent structurally equivalent types).1058 1059.. _TYPE_CODE_NUMENTRY:1060.. _NUMENTRY:1061 1062TYPE_CODE_NUMENTRY Record1063^^^^^^^^^^^^^^^^^^^^^^^^^1064 1065``[NUMENTRY, numentries]``1066 1067The ``NUMENTRY`` record (code 1) contains a single value which indicates the1068total number of type code entries in the type table of the module. If present,1069``NUMENTRY`` should be the first record in the block.1070 1071TYPE_CODE_VOID Record1072^^^^^^^^^^^^^^^^^^^^^1073 1074``[VOID]``1075 1076The ``VOID`` record (code 2) adds a ``void`` type to the type table.1077 1078TYPE_CODE_HALF Record1079^^^^^^^^^^^^^^^^^^^^^1080 1081``[HALF]``1082 1083The ``HALF`` record (code 10) adds a ``half`` (16-bit floating point) type to1084the type table.1085 1086TYPE_CODE_BFLOAT Record1087^^^^^^^^^^^^^^^^^^^^^^^1088 1089``[BFLOAT]``1090 1091The ``BFLOAT`` record (code 23) adds a ``bfloat`` (16-bit brain floating point)1092type to the type table.1093 1094TYPE_CODE_FLOAT Record1095^^^^^^^^^^^^^^^^^^^^^^1096 1097``[FLOAT]``1098 1099The ``FLOAT`` record (code 3) adds a ``float`` (32-bit floating point) type to1100the type table.1101 1102TYPE_CODE_DOUBLE Record1103^^^^^^^^^^^^^^^^^^^^^^^1104 1105``[DOUBLE]``1106 1107The ``DOUBLE`` record (code 4) adds a ``double`` (64-bit floating point) type to1108the type table.1109 1110TYPE_CODE_LABEL Record1111^^^^^^^^^^^^^^^^^^^^^^1112 1113``[LABEL]``1114 1115The ``LABEL`` record (code 5) adds a ``label`` type to the type table.1116 1117TYPE_CODE_OPAQUE Record1118^^^^^^^^^^^^^^^^^^^^^^^1119 1120``[OPAQUE]``1121 1122The ``OPAQUE`` record (code 6) adds an ``opaque`` type to the type table, with1123a name defined by a previously encountered ``STRUCT_NAME`` record. Note that1124distinct ``opaque`` types are not unified.1125 1126TYPE_CODE_INTEGER Record1127^^^^^^^^^^^^^^^^^^^^^^^^1128 1129``[INTEGER, width]``1130 1131The ``INTEGER`` record (code 7) adds an integer type to the type table. The1132single *width* field indicates the width of the integer type.1133 1134TYPE_CODE_POINTER Record1135^^^^^^^^^^^^^^^^^^^^^^^^1136 1137``[POINTER, pointee type, address space]``1138 1139The ``POINTER`` record (code 8) adds a pointer type to the type table. The1140operand fields are:1141 1142* *pointee type*: The type index of the pointed-to type1143 1144* *address space*: If supplied, the target-specific numbered address space where1145 the pointed-to object resides. Otherwise, the default address space is zero.1146 1147TYPE_CODE_FUNCTION_OLD Record1148^^^^^^^^^^^^^^^^^^^^^^^^^^^^^1149 1150.. note::1151 This is a legacy encoding for functions, produced by LLVM versions 3.0 and1152 earlier. It is guaranteed to be understood by the current LLVM version, as1153 specified in the :ref:`IR backwards compatibility` policy.1154 1155``[FUNCTION_OLD, vararg, ignored, retty, ...paramty... ]``1156 1157The ``FUNCTION_OLD`` record (code 9) adds a function type to the type table.1158The operand fields are:1159 1160* *vararg*: Non-zero if the type represents a varargs function1161 1162* *ignored*: This value field is present for backward compatibility only, and is1163 ignored1164 1165* *retty*: The type index of the function's return type1166 1167* *paramty*: Zero or more type indices representing the parameter types of the1168 function1169 1170TYPE_CODE_ARRAY Record1171^^^^^^^^^^^^^^^^^^^^^^1172 1173``[ARRAY, numelts, eltty]``1174 1175The ``ARRAY`` record (code 11) adds an array type to the type table. The1176operand fields are:1177 1178* *numelts*: The number of elements in arrays of this type1179 1180* *eltty*: The type index of the array element type1181 1182TYPE_CODE_VECTOR Record1183^^^^^^^^^^^^^^^^^^^^^^^1184 1185``[VECTOR, numelts, eltty]``1186 1187The ``VECTOR`` record (code 12) adds a vector type to the type table. The1188operand fields are:1189 1190* *numelts*: The number of elements in vectors of this type1191 1192* *eltty*: The type index of the vector element type1193 1194TYPE_CODE_X86_FP80 Record1195^^^^^^^^^^^^^^^^^^^^^^^^^1196 1197``[X86_FP80]``1198 1199The ``X86_FP80`` record (code 13) adds an ``x86_fp80`` (80-bit floating point)1200type to the type table.1201 1202TYPE_CODE_FP128 Record1203^^^^^^^^^^^^^^^^^^^^^^1204 1205``[FP128]``1206 1207The ``FP128`` record (code 14) adds an ``fp128`` (128-bit floating point) type1208to the type table.1209 1210TYPE_CODE_PPC_FP128 Record1211^^^^^^^^^^^^^^^^^^^^^^^^^^1212 1213``[PPC_FP128]``1214 1215The ``PPC_FP128`` record (code 15) adds a ``ppc_fp128`` (128-bit floating point)1216type to the type table.1217 1218TYPE_CODE_METADATA Record1219^^^^^^^^^^^^^^^^^^^^^^^^^1220 1221``[METADATA]``1222 1223The ``METADATA`` record (code 16) adds a ``metadata`` type to the type table.1224 1225TYPE_CODE_X86_MMX Record1226^^^^^^^^^^^^^^^^^^^^^^^^1227 1228``[X86_MMX]``1229 1230The ``X86_MMX`` record (code 17) is deprecated, and imported as a <1 x i64> vector.1231 1232TYPE_CODE_STRUCT_ANON Record1233^^^^^^^^^^^^^^^^^^^^^^^^^^^^1234 1235``[STRUCT_ANON, ispacked, ...eltty...]``1236 1237The ``STRUCT_ANON`` record (code 18) adds a literal struct type to the type1238table. The operand fields are:1239 1240* *ispacked*: Non-zero if the type represents a packed structure1241 1242* *eltty*: Zero or more type indices representing the element types of the1243 structure1244 1245TYPE_CODE_STRUCT_NAME Record1246^^^^^^^^^^^^^^^^^^^^^^^^^^^^1247 1248``[STRUCT_NAME, ...string...]``1249 1250The ``STRUCT_NAME`` record (code 19) contains a variable number of values1251representing the bytes of a struct name. The next ``OPAQUE`` or1252``STRUCT_NAMED`` record will use this name.1253 1254TYPE_CODE_STRUCT_NAMED Record1255^^^^^^^^^^^^^^^^^^^^^^^^^^^^^1256 1257``[STRUCT_NAMED, ispacked, ...eltty...]``1258 1259The ``STRUCT_NAMED`` record (code 20) adds an identified struct type to the1260type table, with a name defined by a previously encountered ``STRUCT_NAME``1261record. The operand fields are:1262 1263* *ispacked*: Non-zero if the type represents a packed structure1264 1265* *eltty*: Zero or more type indices representing the element types of the1266 structure1267 1268TYPE_CODE_FUNCTION Record1269^^^^^^^^^^^^^^^^^^^^^^^^^1270 1271``[FUNCTION, vararg, retty, ...paramty... ]``1272 1273The ``FUNCTION`` record (code 21) adds a function type to the type table. The1274operand fields are:1275 1276* *vararg*: Non-zero if the type represents a varargs function1277 1278* *retty*: The type index of the function's return type1279 1280* *paramty*: Zero or more type indices representing the parameter types of the1281 function1282 1283TYPE_CODE_X86_AMX Record1284^^^^^^^^^^^^^^^^^^^^^^^^1285 1286``[X86_AMX]``1287 1288The ``X86_AMX`` record (code 24) adds an ``x86_amx`` type to the type table.1289 1290TYPE_CODE_TARGET_TYPE Record1291^^^^^^^^^^^^^^^^^^^^^^^^^^^^1292 1293``[TARGET_TYPE, num_tys, ...ty_params..., ...int_params... ]``1294 1295The ``TARGET_TYPE`` record (code 26) adds a target extension type to the type1296table, with a name defined by a previously encountered ``STRUCT_NAME`` record.1297The operand fields are:1298 1299* *num_tys*: The number of parameters that are types (as opposed to integers)1300 1301* *ty_params*: Type indices that represent type parameters1302 1303* *int_params*: Numbers that correspond to the integer parameters.1304 1305.. _CONSTANTS_BLOCK:1306 1307CONSTANTS_BLOCK Contents1308------------------------1309 1310The ``CONSTANTS_BLOCK`` block (id 11) ...1311 1312.. _FUNCTION_BLOCK:1313 1314FUNCTION_BLOCK Contents1315-----------------------1316 1317The ``FUNCTION_BLOCK`` block (id 12) ...1318 1319In addition to the record types described below, a ``FUNCTION_BLOCK`` block may1320contain the following sub-blocks:1321 1322* `CONSTANTS_BLOCK`_1323* `VALUE_SYMTAB_BLOCK`_1324* `METADATA_ATTACHMENT`_1325 1326.. _VALUE_SYMTAB_BLOCK:1327 1328VALUE_SYMTAB_BLOCK Contents1329---------------------------1330 1331The ``VALUE_SYMTAB_BLOCK`` block (id 14) ...1332 1333.. _METADATA_BLOCK:1334 1335METADATA_BLOCK Contents1336-----------------------1337 1338The ``METADATA_BLOCK`` block (id 15) ...1339 1340.. _METADATA_ATTACHMENT:1341 1342METADATA_ATTACHMENT Contents1343----------------------------1344 1345The ``METADATA_ATTACHMENT`` block (id 16) ...1346 1347.. _STRTAB_BLOCK:1348 1349STRTAB_BLOCK Contents1350---------------------1351 1352The ``STRTAB`` block (id 23) contains a single record (``STRTAB_BLOB``, id 1)1353with a single blob operand containing the bitcode file's string table.1354 1355Strings in the string table are not null terminated. A record's *strtab1356offset* and *strtab size* operands specify the byte offset and size of a1357string within the string table.1358 1359The string table is used by all preceding blocks in the bitcode file that are1360not succeeded by another intervening ``STRTAB`` block. Normally a bitcode1361file will have a single string table, but it may have more than one if it1362was created by binary concatenation of multiple bitcode files.1363