From f5af6ada3b0570db1afc19029cad8fb8320676ef Mon Sep 17 00:00:00 2001 From: NAKAMURA Takumi Date: Sat, 23 Apr 2011 00:30:22 +0000 Subject: docs: Introduce cascading style
and

continued on .

Section Example

Section preamble.

Subsection Example

Subsection body

FIXME: Care H5 better. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130040 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/CodeGenerator.html | 217 +++++++++++++++++++++++------------------------- 1 file changed, 102 insertions(+), 115 deletions(-) (limited to 'docs/CodeGenerator.html') diff --git a/docs/CodeGenerator.html b/docs/CodeGenerator.html index 50036f2ed7..9185563323 100644 --- a/docs/CodeGenerator.html +++ b/docs/CodeGenerator.html @@ -132,7 +132,7 @@ -
+

The LLVM target-independent code generator is a framework that provides a suite of reusable components for translating the LLVM internal representation @@ -188,14 +188,12 @@ 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 @@ -227,7 +225,7 @@ The high-level design of the code generator -

+

The LLVM target-independent code generator is designed to support efficient and quality code generation for standard register-based microprocessors. @@ -301,7 +299,7 @@ Using TableGen for target description -

+

The target description classes require a detailed description of the target architecture. These target descriptions often have a large amount of common @@ -324,13 +322,15 @@

+
+

Target description classes

-
+

The LLVM target description classes (located in the include/llvm/Target directory) provide an abstract description of @@ -346,14 +346,12 @@ 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 @@ -373,7 +371,7 @@ The TargetData class -

+

The TargetData class is the only required target description class, and it is the only class that is not extensible (you cannot derived a new @@ -389,7 +387,7 @@ The TargetLowering class -

+

The TargetLowering class is used by SelectionDAG based instruction selectors primarily to describe how LLVM code should be lowered to @@ -415,7 +413,7 @@ The TargetRegisterInfo class -

+

The TargetRegisterInfo class is used to describe the register file of the target and any interactions between the registers.

@@ -449,7 +447,7 @@ The TargetInstrInfo class -
+

The TargetInstrInfo class is used to describe the machine instructions supported by the target. It is essentially an array of @@ -467,7 +465,7 @@ The TargetFrameInfo class -

+

The TargetFrameInfo class is used to provide information about the stack frame layout of the target. It holds the direction of stack growth, the @@ -483,7 +481,7 @@ The TargetSubtarget class -

+

The TargetSubtarget class is used to provide information about the specific chip set being targeted. A sub-target informs code generation of @@ -499,7 +497,7 @@ The TargetJITInfo class -

+

The TargetJITInfo class exposes an abstract interface used by the Just-In-Time code generator to perform target-specific activities, such as @@ -509,13 +507,15 @@

+
+

Machine code description classes

-
+

At the high-level, LLVM code is translated to a machine specific representation formed out of @@ -528,14 +528,12 @@ SSA representation for machine code, as well as a register allocated, non-SSA form.

-
-

The MachineInstr class

-
+

Target machine instructions are represented as instances of the MachineInstr class. This class is an extremely abstract way of @@ -576,14 +574,12 @@

Also if the first operand is a def, it is easier to create instructions whose only def is the first operand.

-
-

Using the MachineInstrBuilder.h functions

-
+

Machine instructions are created by using the BuildMI functions, located in the include/llvm/CodeGen/MachineInstrBuilder.h file. The @@ -634,7 +630,7 @@ MI.addReg(Reg, RegState::Define); Fixed (preassigned) registers -

+

One important issue that the code generator needs to be aware of is the presence of fixed registers. In particular, there are often places in the @@ -706,7 +702,7 @@ ret Machine code in SSA form -

+

MachineInstr's are initially selected in SSA-form, and are maintained in SSA-form until register allocation happens. For the most part, @@ -719,12 +715,14 @@ ret

+
+

The MachineBasicBlock class

-
+

The MachineBasicBlock class contains a list of machine instructions (MachineInstr instances). It roughly @@ -741,7 +739,7 @@ ret The MachineFunction class -

+

The MachineFunction class contains a list of machine basic blocks (MachineBasicBlock instances). It @@ -754,6 +752,7 @@ ret

+

@@ -761,7 +760,7 @@ ret

-
+

The MC Layer is used to represent and process code at the raw machine code @@ -779,15 +778,12 @@ of important subsystems that interact at this layer, they are described later in this manual.

-
- -

The MCStreamer API

-
+

MCStreamer is best thought of as an assembler API. It is an abstract API which @@ -821,7 +817,7 @@ MCObjectStreamer implements a full assembler. The MCContext class -

+

The MCContext class is the owner of a variety of uniqued data structures at the @@ -836,7 +832,7 @@ interact with to create symbols and sections. This class can not be subclassed. The MCSymbol class -

+

The MCSymbol class represents a symbol (aka label) in the assembly file. There @@ -868,7 +864,7 @@ like this to the .s file:

The MCSection class -

+

The MCSection class represents an object-file specific section. It is subclassed @@ -886,7 +882,7 @@ directive in a .s file). The MCInst class -

+

The MCInst class is a target-independent representation of an instruction. It @@ -904,6 +900,7 @@ printer, and the type generated by the assembly parser and disassembler.

+

@@ -911,20 +908,18 @@ printer, and the type generated by the assembly parser and disassembler.

-
+

This section documents the phases described in the high-level design of the code generator. It explains how they work and some of the rationale behind their design.

-
-

Instruction Selection

-
+

Instruction Selection is the process of translating LLVM code presented to the code generator into target-specific machine instructions. There are @@ -936,14 +931,12 @@ printer, and the type generated by the assembly parser and disassembler. selector to be generated from these .td files, though currently there are still things that require custom C++ code.

-
-

Introduction to SelectionDAGs

-
+

The SelectionDAG provides an abstraction for code representation in a way that is amenable to instruction selection using automatic techniques @@ -1005,7 +998,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG Instruction Selection Process -

+

SelectionDAG-based instruction selection consists of the following steps:

@@ -1086,7 +1079,7 @@ printer, and the type generated by the assembly parser and disassembler. Initial SelectionDAG Construction -
+

The initial SelectionDAG is naïvely peephole expanded from the LLVM input by the SelectionDAGLowering class in the @@ -1106,7 +1099,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG LegalizeTypes Phase -

+

The Legalize phase is in charge of converting a DAG to only use the types that are natively supported by the target.

@@ -1139,7 +1132,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG Legalize Phase -
+

The Legalize phase is in charge of converting a DAG to only use the operations that are natively supported by the target.

@@ -1173,7 +1166,7 @@ printer, and the type generated by the assembly parser and disassembler. -
+

The SelectionDAG optimization phase is run multiple times for code generation, immediately after the DAG is built and once after each @@ -1207,7 +1200,7 @@ printer, and the type generated by the assembly parser and disassembler. SelectionDAG Select Phase -

+

The Select phase is the bulk of the target-specific code for instruction selection. This phase takes a legal SelectionDAG as input, pattern matches @@ -1368,7 +1361,7 @@ def : Pat<(i32 imm:$imm), SelectionDAG Scheduling and Formation Phase -

+

The scheduling phase takes the DAG of target instructions from the selection phase and assigns an order. The scheduler can pick an order depending on @@ -1389,7 +1382,7 @@ def : Pat<(i32 imm:$imm), Future directions for the SelectionDAG -

+
  1. Optional function-at-a-time selection.
    2. @@ -1399,18 +1392,20 @@ def : Pat<(i32 imm:$imm),
+
+

SSA-based Machine Code Optimizations

-

To Be Written

+

To Be Written

Live Intervals

-
+

Live Intervals are the ranges (intervals) where a variable is live. They are used by some register allocator passes to @@ -1418,14 +1413,12 @@ def : Pat<(i32 imm:$imm), register are live at the same point in the program (i.e., they conflict). When this situation occurs, one virtual register must be spilled.

-
-

Live Variable Analysis

-
+

The first step in determining the live intervals of variables is to calculate the set of registers that are immediately dead after the instruction (i.e., @@ -1471,7 +1464,7 @@ def : Pat<(i32 imm:$imm), Live Intervals Analysis -

+

We now have the information available to perform the live intervals analysis and build the live intervals themselves. We start off by numbering the basic @@ -1486,12 +1479,14 @@ def : Pat<(i32 imm:$imm),

+
+

Register Allocation

-
+

The Register Allocation problem consists in mapping a program Pv, that can use an unbounded number of virtual registers, @@ -1501,15 +1496,13 @@ def : Pat<(i32 imm:$imm), accommodate all the virtual registers, some of them will have to be mapped into memory. These virtuals are called spilled virtuals.

-
-

How registers are represented in LLVM

-
+

In LLVM, physical registers are denoted by integer numbers that normally range from 1 to 1023. To see how this numbering is defined for a particular @@ -1622,7 +1615,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Mapping virtual registers to physical registers -

+

There are two ways to map virtual registers to physical registers (or to memory slots). The first way, that we will call direct mapping, is @@ -1672,7 +1665,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Handling two address instructions -

+

With very rare exceptions (e.g., function calls), the LLVM machine code instructions are three address instructions. That is, each instruction is @@ -1708,7 +1701,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, The SSA deconstruction phase -

+

An important transformation that happens during register allocation is called the SSA Deconstruction Phase. The SSA form simplifies many analyses @@ -1732,7 +1725,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Instruction folding -

+

Instruction folding is an optimization performed during register allocation that removes unnecessary copy instructions. For instance, a @@ -1769,7 +1762,7 @@ bool RegMapping_Fer::compatible_class(MachineFunction &mf, Built in register allocators -

+

The LLVM infrastructure provides the application developer with three different register allocators:

@@ -1806,23 +1799,25 @@ $ llc -regalloc=pbqp file.bc -o pbqp.s;
+
+

Prolog/Epilog Code Insertion

-

To Be Written

+

To Be Written

Late Machine Code Optimizations

-

To Be Written

+

To Be Written

Code Emission

-
+

The code emission step of code generation is responsible for lowering from the code generator abstractions (like

+

@@ -1888,7 +1884,7 @@ to implement an assembler for your target.

-
+

Though you're probably reading this because you want to write or maintain a compiler backend, LLVM also fully supports building a native assemblers too. @@ -1897,12 +1893,10 @@ We've tried hard to automate the generation of the assembler from the .td files part of the manual and repetitive data entry can be factored and shared with the compiler.

-
-

Instruction Parsing

-

To Be Written

+

To Be Written

@@ -1910,7 +1904,7 @@ compiler.

Instruction Alias Processing -
+

Once the instruction is parsed, it enters the MatchInstructionImpl function. The MatchInstructionImpl function performs alias processing and then does actual matching.

@@ -1923,12 +1917,10 @@ complex/powerful). Generally you want to use the first alias mechanism that meets the needs of your instruction, because it will allow a more concise description.

-
-

Mnemonic Aliases

-
+

The first phase of alias processing is simple instruction mnemonic remapping for classes of instructions which are allowed with two different @@ -1968,7 +1960,7 @@ on the current instruction set.

Instruction Aliases

-
+

The most general phase of alias processing occurs while matching is happening: it provides new forms for the matcher to match along with a specific @@ -2029,15 +2021,14 @@ subtarget specific.

- +

Instruction Matching

-

To Be Written

- - +

To Be Written

+

@@ -2045,20 +2036,18 @@ subtarget specific.

-
+

This section of the document explains features or design decisions that are specific to the code generator for a particular target. First we start with a table that summarizes what features are supported by each target.

-
-

Target Feature Matrix

-
+

Note that this table does not include the C backend or Cpp backends, since they do not use the target independent code generator infrastructure. It also @@ -2229,12 +2218,10 @@ is the key:

-
-

Is Generally Reliable

-
+

This box indicates whether the target is considered to be production quality. This indicates that the target has been used as a static compiler to compile large amounts of code by a variety of different people and is in @@ -2244,7 +2231,7 @@ continuous use.

Assembly Parser

-
+

This box indicates whether the target supports parsing target specific .s files by implementing the MCAsmParser interface. This is required for llvm-mc to be able to act as a native assembler and is required for inline assembly @@ -2256,7 +2243,7 @@ support in the native .o file writer.

Disassembler

-
+

This box indicates whether the target supports the MCDisassembler API for disassembling machine opcode bytes into MCInst's.

@@ -2265,7 +2252,7 @@ disassembling machine opcode bytes into MCInst's.

Inline Asm

-
+

This box indicates whether the target supports most popular inline assembly constraints and modifiers.

@@ -2277,7 +2264,7 @@ constraints relating to the X86 floating point stack.

JIT Support

-
+

This box indicates whether the target supports the JIT compiler through the ExecutionEngine interface.

@@ -2289,7 +2276,7 @@ in ARM codegen mode, but lacks NEON and full Thumb support.

.o File Writing

-
+

This box indicates whether the target supports writing .o files (e.g. MachO, ELF, and/or COFF) files directly from the target. Note that the target also @@ -2305,7 +2292,7 @@ file to a .o file (as is the case for many C compilers).

Tail Calls

-
+

This box indicates whether the target supports guaranteed tail calls. These are calls marked "tail" and use the fastcc @@ -2314,15 +2301,14 @@ more more details.

- - +

Tail call optimization

-
+

Tail call optimization, callee reusing the stack of the caller, is currently supported on x86/x86-64 and PowerPC. It is performed if:

@@ -2388,7 +2374,7 @@ define fastcc i32 @tailcaller(i32 %in1, i32 %in2) { Sibling call optimization -
+

Sibling call optimization is a restricted form of tail call optimization. Unlike tail call optimization described in the previous section, it can be @@ -2432,20 +2418,18 @@ entry: The X86 backend -

+

The X86 code generator lives in the lib/Target/X86 directory. This code generator is capable of targeting a variety of x86-32 and x86-64 processors, and includes support for ISA extensions such as MMX and SSE.

-
-

X86 Target Triples supported

-
+

The following are the known target triples that are supported by the X86 backend. This is not an exhaustive list, and it would be useful to add those @@ -2475,7 +2459,7 @@ entry: -

+

The following target-specific calling conventions are known to backend:

@@ -2494,7 +2478,7 @@ entry: Representing X86 addressing modes in MachineInstrs -
+

The x86 has a very flexible way of accessing memory. It is capable of forming memory addresses of the following expression directly in integer @@ -2531,7 +2515,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg X86 address spaces supported -

+

x86 has a feature which provides the ability to perform loads and stores to different address spaces @@ -2576,7 +2560,7 @@ OperandTy: VirtReg, | VirtReg, UnsImm, VirtReg, SignExtImm PhysReg Instruction naming -

+

An instruction name consists of the base name, a default operand size, and a a character per operand with an optional special size. For example:

@@ -2592,25 +2576,25 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory
+
+

The PowerPC backend

-
+

The PowerPC code generator lives in the lib/Target/PowerPC directory. The code generation is retargetable to several variations or subtargets of the PowerPC ISA; including ppc32, ppc64 and altivec.

-
-

LLVM PowerPC ABI

-
+

LLVM follows the AIX PowerPC ABI, with two deviations. LLVM uses a PC relative (PIC) or static addressing for accessing global values, so no TOC @@ -2630,7 +2614,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Frame Layout -

+

The size of a PowerPC frame is usually fixed for the duration of a function's invocation. Since the frame is fixed size, all references @@ -2777,7 +2761,7 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Prolog/Epilog -

+

The llvm prolog and epilog are the same as described in the PowerPC ABI, with the following exceptions. Callee saved registers are spilled after the frame @@ -2794,12 +2778,15 @@ MOVSX32rm16 -> movsx, 32-bit register, 16-bit memory Dynamic Allocation -

+

TODO - More to come.

+
+ +
-- cgit v1.2.3