diff options
Diffstat (limited to 'docs/CodeGenerator.html')
| -rw-r--r-- | docs/CodeGenerator.html | 196 |
1 files changed, 196 insertions, 0 deletions
diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 62ea6ca..345eb7c 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -50,6 +50,7 @@ <li><a href="#machinebasicblock">The <tt>MachineBasicBlock</tt> class</a></li> <li><a href="#machinefunction">The <tt>MachineFunction</tt> class</a></li> + <li><a href="#machineinstrbundle"><tt>MachineInstr Bundles</tt></a></li> </ul> </li> <li><a href="#mc">The "MC" Layer</a> @@ -97,6 +98,14 @@ <li><a href="#regAlloc_builtIn">Built in register allocators</a></li> </ul></li> <li><a href="#codeemit">Code Emission</a></li> + <li><a href="#vliw_packetizer">VLIW Packetizer</a> + <ul> + <li><a href="#vliw_mapping">Mapping from instructions to functional + units</a></li> + <li><a href="#vliw_repr">How the packetization tables are + generated and used</a></li> + </ul> + </li> </ul> </li> <li><a href="#nativeassembler">Implementing a Native Assembler</a></li> @@ -753,6 +762,88 @@ ret </div> +<!-- ======================================================================= --> +<h3> + <a name="machineinstrbundle"><tt>MachineInstr Bundles</tt></a> +</h3> + +<div> + +<p>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).</p> + +<p>Conceptually a MI bundle is a MI with a number of other MIs nested within: +</p> + +<div class="doc_code"> +<pre> +-------------- +| Bundle | --------- +-------------- \ + | ---------------- + | | MI | + | ---------------- + | | + | ---------------- + | | MI | + | ---------------- + | | + | ---------------- + | | MI | + | ---------------- + | +-------------- +| Bundle | -------- +-------------- \ + | ---------------- + | | MI | + | ---------------- + | | + | ---------------- + | | MI | + | ---------------- + | | + | ... + | +-------------- +| Bundle | -------- +-------------- \ + | + ... +</pre> +</div> + +<p> 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. +</p> + +<p> 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.</p> + +<p> 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.</p> + </div> <!-- *********************************************************************** --> @@ -2001,6 +2092,73 @@ to implement an assembler for your target.</p> </div> +<!-- ======================================================================= --> +<h3> + <a name="vliw_packetizer">VLIW Packetizer</a> +</h3> + +<div> + +<p>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 <i>packets</i> or <i>bundles</i>. The VLIW packetizer in LLVM is + a target-independent mechanism to enable the packetization of machine + instructions.</p> + +<!-- _______________________________________________________________________ --> + +<h4> + <a name="vliw_mapping">Mapping from instructions to functional units</a> +</h4> + +<div> + +<p>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.</p> +</div> + +<!-- ======================================================================= --> +<h4> + <a name="vliw_repr"> + How the packetization tables are generated and used + </a> +</h4> + +<div> + +<p>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.</p> + +<p>To generate tables for a VLIW target, add <i>Target</i>GenDFAPacketizer.inc +as a target to the Makefile in the target directory. The exported API provides +three functions: <tt>DFAPacketizer::clearResources()</tt>, +<tt>DFAPacketizer::reserveResources(MachineInstr *MI)</tt>, and +<tt>DFAPacketizer::canReserveResources(MachineInstr *MI)</tt>. 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 +<tt>llvm/CodeGen/DFAPacketizer.h</tt> for more information.</p> + +</div> + +</div> + </div> <!-- *********************************************************************** --> @@ -2213,6 +2371,7 @@ is the key:</p> <th>Feature</th> <th>ARM</th> <th>CellSPU</th> + <th>Hexagon</th> <th>MBlaze</th> <th>MSP430</th> <th>Mips</th> @@ -2227,6 +2386,7 @@ is the key:</p> <td><a href="#feat_reliable">is generally reliable</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="yes"></td> <!-- Hexagon --> <td class="no"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="yes"></td> <!-- Mips --> @@ -2241,6 +2401,7 @@ is the key:</p> <td><a href="#feat_asmparser">assembly parser</a></td> <td class="no"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="no"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2255,6 +2416,7 @@ is the key:</p> <td><a href="#feat_disassembler">disassembler</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="no"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2269,6 +2431,7 @@ is the key:</p> <td><a href="#feat_inlineasm">inline asm</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="yes"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2283,6 +2446,7 @@ is the key:</p> <td><a href="#feat_jit">jit</a></td> <td class="partial"><a href="#feat_jit_arm">*</a></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="no"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="yes"></td> <!-- Mips --> @@ -2297,6 +2461,7 @@ is the key:</p> <td><a href="#feat_objectwrite">.o file writing</a></td> <td class="no"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- Hexagon --> <td class="yes"></td> <!-- MBlaze --> <td class="no"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2311,6 +2476,7 @@ is the key:</p> <td><a href="#feat_tailcall">tail calls</a></td> <td class="yes"></td> <!-- ARM --> <td class="no"></td> <!-- CellSPU --> + <td class="yes"></td> <!-- Hexagon --> <td class="no"></td> <!-- MBlaze --> <td class="unknown"></td> <!-- MSP430 --> <td class="no"></td> <!-- Mips --> @@ -2321,6 +2487,20 @@ is the key:</p> <td class="unknown"></td> <!-- XCore --> </tr> +<tr> + <td><a href="#feat_segstacks">segmented stacks</a></td> + <td class="no"></td> <!-- ARM --> + <td class="no"></td> <!-- CellSPU --> + <td class="no"></td> <!-- MBlaze --> + <td class="no"></td> <!-- MSP430 --> + <td class="no"></td> <!-- Mips --> + <td class="no"></td> <!-- PTX --> + <td class="no"></td> <!-- PowerPC --> + <td class="no"></td> <!-- Sparc --> + <td class="partial"><a href="#feat_segstacks_x86">*</a></td> <!-- X86 --> + <td class="no"></td> <!-- XCore --> +</tr> + </table> @@ -2404,6 +2584,22 @@ more more details</a>.</p> </div> +<!-- _______________________________________________________________________ --> +<h4 id="feat_segstacks">Segmented Stacks</h4> + +<div> + +<p>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 <a href="http://gcc.gnu.org/wiki/SplitStacks">gcc +implementation</a> used by the Go front end.</p> + +<p id="feat_segstacks_x86">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.</p> + +</div> + </div> <!-- ======================================================================= --> |