X-Git-Url: http://plrg.eecs.uci.edu/git/?p=oota-llvm.git;a=blobdiff_plain;f=docs%2FBitCodeFormat.rst;h=d6e3099bdb63d8d620050f9c90916ad97a2511dd;hp=c83b6c1801cd403980c0d6063dd40b7b8c4db23b;hb=2ec5a319cacb9e13bf20bc8b9113d11212f10aae;hpb=a7aec400a7014edba1eeb53c582d3ab47178fe8d diff --git a/docs/BitCodeFormat.rst b/docs/BitCodeFormat.rst index c83b6c1801c..d6e3099bdb6 100644 --- a/docs/BitCodeFormat.rst +++ b/docs/BitCodeFormat.rst @@ -28,8 +28,9 @@ Unlike XML, the bitstream format is a binary encoding, and unlike XML it provides a mechanism for the file to self-describe "abbreviations", which are effectively size optimizations for the content. -LLVM IR files may be optionally embedded into a `wrapper`_ structure that makes -it easy to embed extra data along with LLVM IR files. +LLVM IR files may be optionally embedded into a `wrapper`_ structure, or in a +`native object file`_. Both of these mechanisms make it easy to embed extra +data along with LLVM IR files. This document first describes the LLVM bitstream format, describes the wrapper format, then describes the record structure used by LLVM IR files. @@ -460,6 +461,19 @@ to the start of the bitcode stream in the file, and the Size field is the size in bytes of the stream. CPUType is a target-specific value that can be used to encode the CPU of the target. +.. _native object file: + +Native Object File Wrapper Format +================================= + +Bitcode files for LLVM IR may also be wrapped in a native object file +(i.e. ELF, COFF, Mach-O). The bitcode must be stored in a section of the +object file named ``.llvmbc``. This wrapper format is useful for accommodating +LTO in compilation pipelines where intermediate objects must be native object +files which contain metadata in other sections. + +Not all tools support this format. + .. _encoding of LLVM IR: LLVM IR Encoding @@ -658,7 +672,7 @@ for each library name referenced. MODULE_CODE_GLOBALVAR Record ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -``[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr]`` +``[GLOBALVAR, pointer type, isconst, initid, linkage, alignment, section, visibility, threadlocal, unnamed_addr, externally_initialized, dllstorageclass, comdat]`` The ``GLOBALVAR`` record (code 7) marks the declaration or definition of a global variable. The operand fields are: @@ -688,7 +702,8 @@ global variable. The operand fields are: * ``weak_odr``: code 10 * ``linkonce_odr``: code 11 * ``available_externally``: code 12 - * ``linker_private``: code 13 + * deprecated : code 13 + * deprecated : code 14 * alignment*: The logarithm base 2 of the variable's requested alignment, plus 1 @@ -713,12 +728,20 @@ global variable. The operand fields are: * *unnamed_addr*: If present and non-zero, indicates that the variable has ``unnamed_addr`` +.. _bcdllstorageclass: + +* *dllstorageclass*: If present, an encoding of the DLL storage class of this variable: + + * ``default``: code 0 + * ``dllimport``: code 1 + * ``dllexport``: code 2 + .. _FUNCTION: MODULE_CODE_FUNCTION Record ^^^^^^^^^^^^^^^^^^^^^^^^^^^ -``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc]`` +``[FUNCTION, type, callingconv, isproto, linkage, paramattr, alignment, section, visibility, gc, prologuedata, dllstorageclass, comdat, prefixdata, personalityfn]`` The ``FUNCTION`` record (code 8) marks the declaration or definition of a function. The operand fields are: @@ -729,6 +752,11 @@ function. The operand fields are: * ``ccc``: code 0 * ``fastcc``: code 8 * ``coldcc``: code 9 + * ``webkit_jscc``: code 12 + * ``anyregcc``: code 13 + * ``preserve_mostcc``: code 14 + * ``preserve_allcc``: code 15 + * ``cxx_fast_tlscc``: code 17 * ``x86_stdcallcc``: code 64 * ``x86_fastcallcc``: code 65 * ``arm_apcscc``: code 66 @@ -757,10 +785,24 @@ function. The operand fields are: * *unnamed_addr*: If present and non-zero, indicates that the function has ``unnamed_addr`` +* *prologuedata*: If non-zero, the value index of the prologue data for this function, + plus 1. + +* *dllstorageclass*: An encoding of the + :ref:`dllstorageclass` of this function + +* *comdat*: An encoding of the COMDAT of this function + +* *prefixdata*: If non-zero, the value index of the prefix data for this function, + plus 1. + +* *personalityfn*: If non-zero, the value index of the personality function for this function, + plus 1. + MODULE_CODE_ALIAS Record ^^^^^^^^^^^^^^^^^^^^^^^^ -``[ALIAS, alias type, aliasee val#, linkage, visibility]`` +``[ALIAS, alias type, aliasee val#, linkage, visibility, dllstorageclass]`` The ``ALIAS`` record (code 9) marks the definition of an alias. The operand fields are @@ -773,6 +815,9 @@ fields are * *visibility*: If present, an encoding of the `visibility`_ of the alias +* *dllstorageclass*: If present, an encoding of the + :ref:`dllstorageclass` of the alias + MODULE_CODE_PURGEVALS Record ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -807,7 +852,7 @@ in the *paramattr* field of module block `FUNCTION`_ records, or within the *attr* field of function block ``INST_INVOKE`` and ``INST_CALL`` records. Entries within ``PARAMATTR_BLOCK`` are constructed to ensure that each is unique -(i.e., no two indicies represent equivalent attribute lists). +(i.e., no two indices represent equivalent attribute lists). .. _PARAMATTR_CODE_ENTRY: @@ -860,7 +905,7 @@ table entry, which may be referenced by 0-based index from instructions, constants, metadata, type symbol table entries, or other type operator records. Entries within ``TYPE_BLOCK`` are constructed to ensure that each entry is -unique (i.e., no two indicies represent structurally equivalent types). +unique (i.e., no two indices represent structurally equivalent types). .. _TYPE_CODE_NUMENTRY: .. _NUMENTRY: @@ -1073,7 +1118,7 @@ named type. VALUE_SYMTAB_BLOCK Contents --------------------------- -The ``VALUE_SYMTAB_BLOCK`` block (id 14) ... +The ``VALUE_SYMTAB_BLOCK`` block (id 14) ... .. _METADATA_BLOCK: