Mercurial > hg > CbC > CbC_llvm

comparison docs/BitCodeFormat.rst @ 134:3a76565eade5 LLVM5.0.1

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
update 5.0.1
author mir3636
date Sat, 17 Feb 2018 09:57:20 +0900
parents 803732b1fca8
children c2174574ed3a
comparison
equal deleted inserted replaced
133:c60214abe0e8 134:3a76565eade5
60 .. _magic number: 60 .. _magic number:
61 61
62 Magic Numbers 62 Magic Numbers
63 ------------- 63 -------------
64 64
65 The first two bytes of a bitcode file are 'BC' (``0x42``, ``0x43``). The second 65 The first four bytes of a bitstream are used as an application-specific magic
66 two bytes are an application-specific magic number. Generic bitcode tools can 66 number. Generic bitcode tools may look at the first four bytes to determine
67 look at only the first two bytes to verify the file is bitcode, while 67 whether the stream is a known stream type. However, these tools should *not*
68 application-specific programs will want to look at all four. 68 determine whether a bitstream is valid based on its magic number alone. New
69 application-specific bitstream formats are being developed all the time; tools
70 should not reject them just because they have a hitherto unseen magic number.
69 71
70 .. _primitives: 72 .. _primitives:
71 73
72 Primitives 74 Primitives
73 ---------- 75 ----------
494 ^^^^^^^^^^^^^^^^^^^^ 496 ^^^^^^^^^^^^^^^^^^^^
495 497
496 The magic number for LLVM IR files is: 498 The magic number for LLVM IR files is:
497 499
498 :raw-html:`<tt><blockquote>` 500 :raw-html:`<tt><blockquote>`
499 [0x0\ :sub:`4`, 0xC\ :sub:`4`, 0xE\ :sub:`4`, 0xD\ :sub:`4`] 501 ['B'\ :sub:`8`, 'C'\ :sub:`8`, 0x0\ :sub:`4`, 0xC\ :sub:`4`, 0xE\ :sub:`4`, 0xD\ :sub:`4`]
500 :raw-html:`</blockquote></tt>` 502 :raw-html:`</blockquote></tt>`
501
502 When combined with the bitcode magic number and viewed as bytes, this is
503 ``"BC 0xC0DE"``.
504 503
505 .. _Signed VBRs: 504 .. _Signed VBRs:
506 505
507 Signed VBRs 506 Signed VBRs
508 ^^^^^^^^^^^ 507 ^^^^^^^^^^^
902 901
903 ``[ENTRY, attrgrp0, attrgrp1, ...]`` 902 ``[ENTRY, attrgrp0, attrgrp1, ...]``
904 903
905 The ``ENTRY`` record (code 2) contains a variable number of values describing a 904 The ``ENTRY`` record (code 2) contains a variable number of values describing a
906 unique set of function parameter attributes. Each *attrgrp* value is used as a 905 unique set of function parameter attributes. Each *attrgrp* value is used as a
907 key with which to look up an entry in the the attribute group table described 906 key with which to look up an entry in the attribute group table described
908 in the ``PARAMATTR_GROUP_BLOCK`` block. 907 in the ``PARAMATTR_GROUP_BLOCK`` block.
909 908
910 .. _PARAMATTR_CODE_ENTRY_OLD: 909 .. _PARAMATTR_CODE_ENTRY_OLD:
911 910
912 PARAMATTR_CODE_ENTRY_OLD Record 911 PARAMATTR_CODE_ENTRY_OLD Record
1050 * code 48: ``norecurse`` 1049 * code 48: ``norecurse``
1051 * code 49: ``inaccessiblememonly`` 1050 * code 49: ``inaccessiblememonly``
1052 * code 50: ``inaccessiblememonly_or_argmemonly`` 1051 * code 50: ``inaccessiblememonly_or_argmemonly``
1053 * code 51: ``allocsize(<EltSizeParam>[, <NumEltsParam>])`` 1052 * code 51: ``allocsize(<EltSizeParam>[, <NumEltsParam>])``
1054 * code 52: ``writeonly`` 1053 * code 52: ``writeonly``
1054 * code 53: ``speculatable``
1055 * code 54: ``strictfp``
1056 * code 55: ``sanitize_hwaddress``
1055 1057
1056 .. note:: 1058 .. note::
1057 The ``allocsize`` attribute has a special encoding for its arguments. Its two 1059 The ``allocsize`` attribute has a special encoding for its arguments. Its two
1058 arguments, which are 32-bit integers, are packed into one 64-bit integer value 1060 arguments, which are 32-bit integers, are packed into one 64-bit integer value
1059 (i.e. ``(EltSizeParam << 32) | NumEltsParam``), with ``NumEltsParam`` taking on 1061 (i.e. ``(EltSizeParam << 32) | NumEltsParam``), with ``NumEltsParam`` taking on