From 1fc08f5e9ef733ef1ce6f363fecedc2260e78974 Mon Sep 17 00:00:00 2001 From: dim Date: Sat, 14 Apr 2012 13:54:10 +0000 Subject: Vendor import of llvm trunk r154661: http://llvm.org/svn/llvm-project/llvm/trunk@r154661 --- docs/CodeGenerator.html | 244 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 217 insertions(+), 27 deletions(-) (limited to 'docs/CodeGenerator.html') diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 9d0370fd..a37c3dc 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -50,6 +50,7 @@
  • The MachineBasicBlock class
  • The MachineFunction class
    • +
  • MachineInstr Bundles
  • The "MC" Layer @@ -97,6 +98,14 @@
  • Built in register allocators
  • Code Emission
    • +
  • VLIW Packetizer + +
  • Implementing a Native Assembler
    • @@ -700,6 +709,21 @@ ret

    + Call-clobbered registers +

    + +
    + +

    Some machine instructions, like calls, clobber a large number of physical + registers. Rather than adding <def,dead> operands for + all of them, it is possible to use an MO_RegisterMask operand + instead. The register mask operand holds a bit mask of preserved registers, + and everything else is considered to be clobbered by the instruction.

    + +
    + + +

    Machine code in SSA form

    @@ -753,6 +777,90 @@ ret + +

    + MachineInstr Bundles +

    + +
    + +

    LLVM code generator can model sequences of instructions as MachineInstr + bundles. A MI bundle can model a VLIW group / pack which contains an + arbitrary number of parallel instructions. It can also be used to model + a sequential list of instructions (potentially with data dependencies) that + cannot be legally separated (e.g. ARM Thumb2 IT blocks).

    + +

    Conceptually a MI bundle is a MI with a number of other MIs nested within: +

    + +
    +
    +--------------
+|   Bundle   | ---------
+--------------          \
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |
+--------------
+|   Bundle   | --------
+--------------         \
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |           ----------------
+       |           |      MI      |
+       |           ----------------
+       |                   |
+       |                  ...
+       |
+--------------
+|   Bundle   | --------
+--------------         \
+       |
+      ...
+
    +
    + +

    MI bundle support does not change the physical representations of + MachineBasicBlock and MachineInstr. All the MIs (including top level and + nested ones) are stored as sequential list of MIs. The "bundled" MIs are + marked with the 'InsideBundle' flag. A top level MI with the special BUNDLE + opcode is used to represent the start of a bundle. It's legal to mix BUNDLE + MIs with indiviual MIs that are not inside bundles nor represent bundles. +

    + +

    MachineInstr passes should operate on a MI bundle as a single unit. Member + methods have been taught to correctly handle bundles and MIs inside bundles. + The MachineBasicBlock iterator has been modified to skip over bundled MIs to + enforce the bundle-as-a-single-unit concept. An alternative iterator + instr_iterator has been added to MachineBasicBlock to allow passes to + iterate over all of the MIs in a MachineBasicBlock, including those which + are nested inside bundles. The top level BUNDLE instruction must have the + correct set of register MachineOperand's that represent the cumulative + inputs and outputs of the bundled MIs.

    + +

    Packing / bundling of MachineInstr's should be done as part of the register + allocation super-pass. More specifically, the pass which determines what + MIs should be bundled together must be done after code generator exits SSA + form (i.e. after two-address pass, PHI elimination, and copy coalescing). + Bundles should only be finalized (i.e. adding BUNDLE MIs and input and + output register MachineOperands) after virtual registers have been + rewritten into physical registers. This requirement eliminates the need to + add virtual register operands to BUNDLE instructions which would effectively + double the virtual register def and use lists.

    + +
    + @@ -2001,6 +2109,73 @@ to implement an assembler for your target.

    + +

    + VLIW Packetizer +

    + +
    + +

    In a Very Long Instruction Word (VLIW) architecture, the compiler is + responsible for mapping instructions to functional-units available on + the architecture. To that end, the compiler creates groups of instructions + called packets or bundles. The VLIW packetizer in LLVM is + a target-independent mechanism to enable the packetization of machine + instructions.

    + + + +

    + Mapping from instructions to functional units +

    + +
    + +

    Instructions in a VLIW target can typically be mapped to multiple functional +units. During the process of packetizing, the compiler must be able to reason +about whether an instruction can be added to a packet. This decision can be +complex since the compiler has to examine all possible mappings of instructions +to functional units. Therefore to alleviate compilation-time complexity, the +VLIW packetizer parses the instruction classes of a target and generates tables +at compiler build time. These tables can then be queried by the provided +machine-independent API to determine if an instruction can be accommodated in a +packet.

    +
    + + +

    + + How the packetization tables are generated and used + +

    + +
    + +

    The packetizer reads instruction classes from a target's itineraries and +creates a deterministic finite automaton (DFA) to represent the state of a +packet. A DFA consists of three major elements: inputs, states, and +transitions. The set of inputs for the generated DFA represents the instruction +being added to a packet. The states represent the possible consumption +of functional units by instructions in a packet. In the DFA, transitions from +one state to another occur on the addition of an instruction to an existing +packet. If there is a legal mapping of functional units to instructions, then +the DFA contains a corresponding transition. The absence of a transition +indicates that a legal mapping does not exist and that the instruction cannot +be added to the packet.

    + +

    To generate tables for a VLIW target, add TargetGenDFAPacketizer.inc +as a target to the Makefile in the target directory. The exported API provides +three functions: DFAPacketizer::clearResources(), +DFAPacketizer::reserveResources(MachineInstr *MI), and +DFAPacketizer::canReserveResources(MachineInstr *MI). These functions +allow a target packetizer to add an instruction to an existing packet and to +check whether an instruction can be added to a packet. See +llvm/CodeGen/DFAPacketizer.h for more information.

    + +
    + +
    + @@ -2212,16 +2387,14 @@ is the key:

    Feature ARM - Alpha - Blackfin CellSPU + Hexagon MBlaze MSP430 Mips PTX PowerPC Sparc - SystemZ X86 XCore @@ -2229,16 +2402,14 @@ is the key:

    is generally reliable - - + - + - @@ -2246,16 +2417,14 @@ is the key:

    assembly parser - - + - @@ -2263,16 +2432,14 @@ is the key:

    disassembler - - + - @@ -2280,16 +2447,14 @@ is the key:

    inline asm - - + - @@ -2297,16 +2462,14 @@ is the key:

    jit * - - + - + - @@ -2314,16 +2477,14 @@ is the key:

    .o file writing - - + - @@ -2331,20 +2492,33 @@ is the key:

    tail calls - - + - + + segmented stacks + + + + + + + + + + * + + + @@ -2428,6 +2602,22 @@ more more details.

    + +

    Segmented Stacks

    + +
    + +

    This box indicates whether the target supports segmented stacks. This +replaces the traditional large C stack with many linked segments. It +is compatible with the gcc +implementation used by the Go front end.

    + +

    Basic support exists on the X86 backend. Currently +vararg doesn't work and the object files are not marked the way the gold +linker expects, but simple Go programs can be built by dragonegg.

    + +
    + @@ -2992,7 +3182,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Chris Lattner
    The LLVM Compiler Infrastructure
    - Last modified: $Date: 2011-11-03 07:43:54 +0100 (Thu, 03 Nov 2011) $ + Last modified: $Date: 2012-03-27 13:25:16 +0200 (Tue, 27 Mar 2012) $ -- cgit v1.1