From: Reid Spencer Date: Wed, 31 Jan 2007 00:26:08 +0000 (+0000) Subject: Excise documentation about Compaction Tables. X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=c4a8d3961474d5e3c6726a43ef1d49659973c13f;p=oota-llvm.git Excise documentation about Compaction Tables. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33685 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/BytecodeFormat.html b/docs/BytecodeFormat.html index 1b508e62406..d6b555242d7 100644 --- a/docs/BytecodeFormat.html +++ b/docs/BytecodeFormat.html @@ -38,7 +38,6 @@
  • Module Info Block
  • Global Constant Pool
  • Function Definition
    • -
  • Compaction Table
  • Instructions List
  • Instructions
  • Symbol Table
    • @@ -403,15 +402,7 @@ anything unless you also specify for which type you want slot #1. Types are always written to the file first (in the Global Type Pool) and in such a way that both forward and backward references of the types can often be resolved with a single pass through the type pool.

    -

    Slot numbers are also kept small by rearranging their order. Because -of the structure of LLVM, certain values are much more likely to be used -frequently in the body of a function. For this reason, a compaction table is -provided in the body of a function if its use would make the function body -smaller. Suppose you have a function body that uses just the types "int*" and -"{double}" but uses them thousands of time. Its worthwhile to ensure that the -slot number for these types are low so they can be encoded in a single byte -(via vbr). This is exactly what the compaction table does.

    -

    In summary then, a slot number can be though of as just a vbr encoded index +

    In summary then, a slot number can be thought of as just a vbr encoded index into a list of Type* or Value*. To keep slot numbers low, Value* are indexed by two slot numbers: the "type plane index" (type slot) and the "value index" (value slot).

    @@ -500,7 +491,7 @@ except function arguments, global values and constant strings.    Function Definitions* One function block is written for each function in the module. The function block contains the instructions, -compaction table, type constant pool, and symbol table for the function. +type constant pool, and symbol table for the function. 0x03 @@ -512,18 +503,6 @@ compaction table, type constant pool, and symbol table for the function. href="#constantpool">Function Constant Pool Any constants (including types) used solely within the function are emitted here in the function constant pool. - - - 0x08 - Function - Yes - No - 2 -       Compaction Table - This table reduces bytecode size by providing -a funtion-local mapping of type and value slot numbers to their global -slot numbers 0x07 @@ -1394,9 +1373,9 @@ Notes:
    Function Definition
    -

    Function definitions contain the linkage, constant pool or -compaction table, instruction list, and symbol table for a function. -The following table shows the structure of a function definition.

    +

    Function definitions contain the linkage, constant pool, instruction list, +and symbol table for a function. The following table shows the structure of +a function definition.

    @@ -1419,11 +1398,6 @@ size
    - - - - @@ -1442,9 +1416,6 @@ Notes:
    1. Note that if the linkage type is "External" then none of the other fields will be present as the function is defined elsewhere.
      2. -
    2. Note that only one of the constant pool or compaction table will -be written. Compaction tables are only written if they will actually -save bytecode space. If not, then a regular constant pool is written.
    @@ -1470,75 +1441,12 @@ save bytecode space. If not, then a regular constant pool is written. -
    block The constant pool block for this function.2
    blockThe compaction -table block for the function.2
    block
    bit(19-31)Currently unassigned.
    - -
    - -
    Compaction Table -
    -
    -

    Compaction tables are part of a function definition. They are merely -a device for reducing the size of bytecode files. The size of a -bytecode file is dependent on the values of the slot numbers -used because larger values use more bytes in the variable bit rate -encoding scheme. Furthermore, the compressed instruction format -reserves only six bits for the type of the instruction. In large -modules, declaring hundreds or thousands of types, the values of the -slot numbers can be quite large. However, functions may use only a -small fraction of the global types. In such cases a compaction table is -created that maps the global type and value slot numbers to smaller -values used by a function. Functions will contain either a -function-specific constant pool or a compaction table but not -both. Compaction tables have the format shown in the table below.

    - - - - - - - - - - - - - - - - - - - - - - - -
    TypeField Description
    uint32_vbrThe number of types that follow
    uint24_vbr+The type slot number in the global types of -the type that will be referenced in the function with the index of this -entry in the compaction table.
    type_lenAn encoding of the type and number of values -that follow. This field's encoding varies depending on the size of the -type plane. See Type and Length for further -details.
    uint32_vbr+The value slot number in the global values -that will be referenced in the function with the index of this entry in -the compaction table.
    -
    - -
    Type and Length
    -
    -

    The type and length of a compaction table type plane is encoded -differently depending on the length of the plane. For planes of length -1 or 2, the length is encoded into bits 0 and 1 of a uint32_vbr and the type is encoded into bits -2-31. Because type numbers are often small, this often saves an extra -byte per plane. If the length of the plane is greater than 2 then the -encoding uses a uint32_vbr for each of the -length and type, in that order.

    -
    Instruction List