From ad1f0cd0cc88b39d237df67722e1fa7b56d5e74c Mon Sep 17 00:00:00 2001 From: Reid Spencer Date: Sun, 24 Apr 2005 20:56:18 +0000 Subject: [PATCH] Make this readable for newbies and those who can only understand one set of grammar rules for the English language. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@21503 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CodeGenerator.html | 268 +++++++++++++++++++++++----------------- 1 file changed, 153 insertions(+), 115 deletions(-) diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index cfdcc2b8892..258fd04e20e 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -137,7 +137,7 @@ classes, ensuring that it is portable. 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 +href="#targetdata">TargetData) 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.

@@ -188,30 +188,31 @@ set, then makes use of virtual registers in SSA form and physical registers that represent any required register assignments due to target constraints or calling conventions. -
  • 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.
    • +
  • 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. +
    • -
  • 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.
    • +
  • 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.
    • -
  • 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.
    • +
  • 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.
    • -
  • Late Machine Code Optimizations - Optimizations that operate on -"final" machine code can go here, such as spill code scheduling and peephole -optimizations.
    • +
  • Late Machine Code Optimizations - Optimizations +that operate on "final" machine code can go here, such as spill code scheduling +and peephole optimizations.
    • -
  • Code Emission - The final stage actually outputs the code for -the current function, either in the target assembler format or in machine -code.
    • +
  • Code Emission - The final stage actually +puts out the code for the current function, either in the target assembler +format or in machine code.
    • @@ -245,11 +246,13 @@ targets with unusual requirements can be supported with custom passes as needed.

    The target description classes require a detailed description 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). +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 -describe big chunks of the target machine, which allows the use of domain- and -target-specific abstractions to reduce the amount of repetition. +describe big chunks of the target machine, which allows the use of +domain-specific and target-specific abstractions to reduce the amount of +repetition.

    @@ -264,11 +267,11 @@ target-specific abstractions to reduce the amount of repetition.

    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).

    +target machine; independent of any particular client. These classes are +designed to capture the abstract properties of the target (such as the +instructions 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 @@ -288,8 +291,9 @@ should be implemented by the target.

    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 specialized by +classes via the get*Info methods (getInstrInfo, +getRegisterInfo, getFrameInfo, etc.). This class is +designed to be specialized 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 @@ -307,10 +311,11 @@ implemented as well.

    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.

    +and it is the only class that is not extensible. You cannot derived a new +class from it. TargetData 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-endian or big-endian.

    @@ -323,10 +328,12 @@ target, and whether the target is little- or big-endian.

    The TargetLowering class is used by SelectionDAG based instruction selectors primarily to describe how LLVM code should be lowered to SelectionDAG -operations. Among other things, this class indicates an initial register class -to use for various ValueTypes, which operations are natively supported by the -target machine, and some other miscellaneous properties (such as the return type -of setcc operations, the type to use for shift amounts, etc).

    +operations. Among other things, this class indicates: +