From ce52b7e45233d087b948e5443923aff58b7801b0 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Tue, 1 Jun 2004 06:48:00 +0000 Subject: [PATCH] It's a small start, but it is certainly needed. Contributions are certainly welcomed. :) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@13914 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CodeGenerator.html | 348 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 348 insertions(+) create mode 100644 docs/CodeGenerator.html diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html new file mode 100644 index 00000000000..4729cc089f6 --- /dev/null +++ b/docs/CodeGenerator.html @@ -0,0 +1,348 @@ + + + + The LLVM Target-Independent Code Generator + + + + +
+ The LLVM Target-Independent Code Generator +
+ +
    +
  1. Introduction + +
    2. +
  2. Target description classes + +
    3. +
  3. Machine code description classes +
    4. +
  4. Target-independent code generation algorithms +
    5. +
  5. Target description implementations +
+ +
+

Written by Chris Lattner

+
+ + +
+ Introduction +
+ + +
+ +

The LLVM target-independent code generator is a framework that provides a +suite of reusable components for translating the LLVM internal representation to +the machine code for a specified target -- either in assembly form (suitable for +a static compiler) or in binary machine code format (usable for a JIT compiler). +The LLVM target-independent code generator consists of four main components:

+ +
    +
  1. Abstract target description interfaces which +capture improtant properties about various aspects of the machine independently +of how they will be used. These interfaces are defined in +include/llvm/Target/.
    2. + +
  2. Classes used to represent the machine code being +generator for a target. These classes are intended to be abstract enough to +represent the machine code for any target machine. These classes are +defined in include/llvm/CodeGen/.
    3. + +
  3. Target-independent algorithms used to implement +various phases of native code generation (register allocation, scheduling, stack +frame representation, etc). This code lives in lib/CodeGen/.
    4. + +
  4. Implementations of the abstract target description +interfaces for particular targets. These machine descriptions make use of +the components provided by LLVM, and can optionally provide custom +target-specific passes, to build complete code generators for a specific target. +Target descriptions live in lib/Target/.
    5. + +
+ +

+Depending on which part of the code generator you are interested in working on, +different pieces of this will be useful to you. In any case, you should be +familiar with the target description and machine code representation classes. If you want to add +a backend for a new target, you will need implement the +targe description classes for your new target and understand the LLVM code representation. If you are interested in +implementing a new code generation algorithm, it +should only depend on the target-description and machine code representation +classes, ensuring that it is portable. +

+ +
+ + +
+ Required components in the code generator +
+ +
+ +

The two pieces of the LLVM code generator are the high-level interface to the +code generator and the set of reusable components that can be used to build +target-specific backends. The two most important interfaces (TargetMachine and TargetData classes) are the only ones that are +required to be defined for a backend to fit into the LLVM system, but the others +must be defined if the reusable code generator components are going to be +used.

+ +

This design has two important implications. The first is that LLVM can +support completely non-traditional code generation targets. For example, the C +backend does not require register allocation, instruction selection, or any of +the other standard components provided by the system. As such, it only +implements these two interfaces, and does its own thing. Another example of a +code generator like this is a (purely hypothetical) backend that converts LLVM +to the GCC RTL form and uses GCC to emit machine code for a target.

+ +

The other implication of this design is that it is possible to design and +implement radically different code generators in the LLVM system that do not +make use of any of the built-in components. Doing so is not recommended at all, +but could be required for radically different targets that do not fit into the +LLVM machine description model: programmable FPGAs for example.

+

+
+ + +
+ The high-level design of the code generator +
+ +
+ +

The LLVM target-indendent code generator is designed to support efficient and +quality code generation for standard register-based microprocessors. Code +generation in this model is divided into the following stages:

+ +
    +
  1. Instruction Selection - Determining a efficient implementation of the +input LLVM code in the target instruction set. This stage produces the initial +code for the program in the target instruction set the makes use of virtual +registers in SSA form and physical registers that represent any required +register assignments due to target constraints or calling conventions.
    2. + +
  2. SSA-based Machine Code Optimizations - This (optional) stage consists +of a series of machine-code optimizations that operate on the SSA-form produced +by the instruction selector. Optimizations like modulo-scheduling, normal +scheduling, or peephole optimization work here.
    3. + +
  3. Register Allocation - The target code is transformed from an infinite +virtual register file in SSA form to the concrete register file used by the +target. This phase introduces spill code and eliminates all virtual register +references from the program.
    4. + +
  4. Prolog/Epilog Code Insertion - Once the machine code has been +generated for the function and the amount of stack space required is known (used +for LLVM alloca's and spill slots), the prolog and epilog code for the function +can be inserted and "abstract stack location references" can be eliminated. +This stage is responsible for implementing optimizations like frame-pointer +elimination and stack packing.
    5. + +
  5. Late Machine Code Optimizations - Optimizations that operate on +"final" machine code can go here, such as spill code scheduling and peephole +optimizations.
    6. + +
  6. Code Emission - The final stage actually outputs the machine code for +the current function, either in the target assembler format or in machine +code.
    7. + +
+ +

+The code generator is based on the assumption that the instruction selector will +use an optimal pattern matching selector to create high-quality sequences of +native code. Alternative code generator designs based on pattern expansion and +aggressive iterative peephole optimization are much slower. This design is +designed to permit efficient compilation (important for JIT environments) and +aggressive optimization (used when generate code offline) by allowing components +of varying levels of sophisication to be used for any step of compilation.

+ +

+In addition to these stages, target implementations can insert arbitrary +target-specific passes into the flow. For example, the X86 target uses a +special pass to handle the 80x87 floating point stack architecture. Other +targets with unusual requirements can be supported with custom passes as needed. +

+ +
+ + + +
+ Using TableGen for target description +
+ +
+ +

The target description classes require a detailed descriptions of the target +architecture. These target descriptions often have a large amount of common +information (e.g., an add instruction is almost identical to a sub instruction). +In order to allow the maximum amount of commonality to be factored out, the LLVM +code generator uses the TableGen tool to +allow +

+ +
+ + +
+ Target description classes +
+ + +
+ +

The LLVM target description classes (which are located in the +include/llvm/Target directory) provide an abstract description of the +target machine, independent of any particular client. These classes are +designed to capture the abstract properties of the target (such as what +instruction and registers it has), and do not incorporate any particular pieces +of code generation algorithms (these interfaces do not take interference graphs +as inputs or other algorithm-specific data structures).

+ +

All of the target description classes (except the TargetData class) are designed to be subclassed by +the concrete target implementation, and have virtual methods implemented. To +get to these implementations, TargetMachine class provides accessors that +should be implemented by the target.

+ +
+ + +
+ The TargetMachine class +
+ +
+ +

The TargetMachine class provides virtual methods that are used to +access the target-specific implementations of the various target description +classes (with the getInstrInfo, getRegisterInfo, +getFrameInfo, ... methods). This class is designed to be subclassed by +a concrete target implementation (e.g., X86TargetMachine) which +implements the various virtual methods. The only required target description +class is the TargetData class, but if the +code generator components are to be used, the other interfaces should be +implemented as well.

+ +
+ + + +
+ The TargetData class +
+ +
+ +

The TargetData class is the only required target description class, +and it is the only class that is not extensible (it cannot be derived from). It +specifies information about how the target lays out memory for structures, the +alignment requirements for various data types, the size of pointers in the +target, and whether the target is little- or big-endian.

+ +
+ + + +
+ The MRegisterInfo class +
+ +
+ +

The MRegisterInfo class (which will eventually be renamed to +TargetRegisterInfo) is used to describe the register file of the +target and any interactions between the registers.

+ +

Registers in the code generator are represented in the code generator by +unsigned numbers. Physical registers (those that actually exist in the target +description) are unique small numbers, and virtual registers are generally +large.

+ +

Each register in the processor description has an associated +MRegisterDesc entry, which provides a textual name for the register +(used for assembly output and debugging dumps), a set of aliases (used to +indicate that one register overlaps with another), and some flag bits. +

+ +

In addition to the per-register description, the MRegisterInfo class +exposes a set of processor specific register classes (instances of the +TargetRegisterClass class). Each register class contains sets of +registers that have the same properties (for example, they are all 32-bit +integer registers). Each SSA virtual register created by the instruction +selector has an associated register class. When the register allocator runs, it +replaces virtual registers with a physical register in the set.

+ +

+The target-specific implementations of these classes is auto-generated from a TableGen description of the register file. +

+ +
+ + +
+ The TargetInstrInfo class +
+ + +
+ The TargetFrameInfo class +
+ + +
+ The TargetJITInfo class +
+ + +
+ Machine code description classes +
+ + + + + +
+
+ Valid CSS! + Valid HTML 4.01! + + Chris Lattner
+ The LLVM Compiler Infrastructure
+ Last modified: $Date$ +
+ + +