This document describes techniques for writing compiler backends that convert @@ -77,7 +77,7 @@ either assembly code or binary code (usable for a JIT compiler).
The backend of LLVM features a target-independent code generator that may create -output for several types of target CPUs — including X86, PowerPC, Alpha, +output for several types of target CPUs — including X86, PowerPC, ARM, and SPARC. The backend may also be used to generate code targeted at SPUs of the Cell processor or GPUs to support the execution of compute kernels.
@@ -91,13 +91,11 @@ characteristics, such as a RISC instruction set and straightforward calling conventions. -The audience for this document is anyone who needs to write an LLVM backend to @@ -106,21 +104,21 @@ generate code for a specific hardware or software target.
These essential documents must be read before reading this document:
To write a compiler backend for LLVM that converts the LLVM IR to code for a @@ -220,17 +218,17 @@ that the class will need and which components will need to be subclassed.
To actually create your compiler backend, you need to create and modify a few files. The absolute minimum is discussed here. But to actually use the LLVM target-independent code generator, you must perform the steps described in -the LLVM +the LLVM Target-Independent Code Generator document.
@@ -281,13 +279,15 @@ regenerate configure by running ./autoconf/AutoRegen.sh.LLVMTargetMachine is designed as a base class for targets implemented @@ -354,19 +354,12 @@ public: // Pass Pipeline Configuration virtual bool addInstSelector(PassManagerBase &PM, bool Fast); virtual bool addPreEmitPass(PassManagerBase &PM, bool Fast); - virtual bool addAssemblyEmitter(PassManagerBase &PM, bool Fast, - std::ostream &Out); }; } // end namespace llvm
Hyphens separate portions of the TargetDescription string.
You must also register your target with the TargetRegistry, which is @@ -482,12 +471,12 @@ For more information, see
You should describe a concrete target-specific class that represents the @@ -516,14 +505,12 @@ input files and placed in XXXGenRegisterInfo.h.inc and implementation of XXXRegisterInfo requires hand-coding.
-The XXXRegisterInfo.td file typically starts with register definitions @@ -563,8 +550,7 @@ def AL : Register<"AL">, DwarfRegNum<[0, 0, 0]>;
This defines the register AL and assigns it values (with DwarfRegNum) that are used by gcc, gdb, or a debug -information writer (such as DwarfWriter -in llvm/lib/CodeGen/AsmPrinter) to identify a register. For register +information writer to identify a register. For register AL, DwarfRegNum takes an array of 3 values representing 3 different modes: the first element is for X86-64, the second for exception handling (EH) on X86-32, and the third is generic. -1 is a special Dwarf number @@ -703,11 +689,11 @@ fields of a register's TargetRegisterDesc.
The RegisterClass class (specified in Target.td) is used to @@ -720,8 +706,7 @@ classes using the following class:
class RegisterClass<string namespace,
-list<ValueType> regTypes, int alignment,
- list<Register> regList> {
+list<ValueType> regTypes, int alignment, dag regList> {
string Namespace = namespace;
list<ValueType> RegTypes = regTypes;
int Size = 0; // spill size, in bits; zero lets tblgen pick the size
@@ -731,7 +716,7 @@ list<ValueType> regTypes, int alignment,
// default value 1 means a single instruction
// A negative value means copying is extremely expensive or impossible
int CopyCost = 1;
- list<Register> MemberList = regList;
+ dag MemberList = regList;
// for register classes that are subregisters of this class
list<RegisterClass> SubRegClassList = [];
@@ -763,9 +748,11 @@ list<ValueType> regTypes, int alignment,
memory.
@@ -775,44 +762,31 @@ classes, the first argument defines the namespace with the string 'SP'. FPRegs defines a group of 32 single-precision floating-point registers (F0 to F31); DFPRegs defines a group of 16 double-precision registers -(D0-D15). For IntRegs, the MethodProtos -and MethodBodies methods are used by TableGen to insert the specified -code into generated output. +(D0-D15).
-def FPRegs : RegisterClass<"SP", [f32], 32,
- [F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15,
- F16, F17, F18, F19, F20, F21, F22, F23, F24, F25, F26, F27, F28, F29, F30, F31]>;
+// F0, F1, F2, ..., F31
+def FPRegs : RegisterClass<"SP", [f32], 32, (sequence "F%u", 0, 31)>;
def DFPRegs : RegisterClass<"SP", [f64], 64,
- [D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15]>;
+ (add D0, D1, D2, D3, D4, D5, D6, D7, D8,
+ D9, D10, D11, D12, D13, D14, D15)>;
def IntRegs : RegisterClass<"SP", [i32], 32,
- [L0, L1, L2, L3, L4, L5, L6, L7,
- I0, I1, I2, I3, I4, I5,
- O0, O1, O2, O3, O4, O5, O7,
- G1,
- // Non-allocatable regs:
- G2, G3, G4,
- O6, // stack ptr
- I6, // frame ptr
- I7, // return address
- G0, // constant zero
- G5, G6, G7 // reserved for kernel
- ]> {
- let MethodProtos = [{
- iterator allocation_order_end(const MachineFunction &MF) const;
- }];
- let MethodBodies = [{
- IntRegsClass::iterator
- IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
- return end() - 10 // Don't allocate special registers
- -1;
- }
- }];
-}
+ (add L0, L1, L2, L3, L4, L5, L6, L7,
+ I0, I1, I2, I3, I4, I5,
+ O0, O1, O2, O3, O4, O5, O7,
+ G1,
+ // Non-allocatable regs:
+ G2, G3, G4,
+ O6, // stack ptr
+ I6, // frame ptr
+ I7, // return address
+ G0, // constant zero
+ G5, G6, G7 // reserved for kernel
+ )>;
+The register allocators will avoid using reserved registers, and callee saved +registers are not used until all the volatile registers have been used. That +is usually good enough, but in some cases it may be necessary to provide custom +allocation orders. +
+The final step is to hand code portions of XXXRegisterInfo, which @@ -916,9 +888,6 @@ implementation in SparcRegisterInfo.cpp:
During the early stages of code generation, the LLVM IR code is converted to a @@ -1109,7 +1080,7 @@ The fifth parameter is a string that is used by the assembly printer and can be left as an empty string until the assembly printer interface is implemented. The sixth and final parameter is the pattern used to match the instruction during the SelectionDAG Select Phase described in -(The LLVM +(The LLVM Target-Independent Code Generator). This parameter is detailed in the next section, Instruction Selector.
@@ -1194,14 +1165,12 @@ correspond to the values in SparcInstrInfo.td. I.e., SPCC::ICC_NE = 9, SPCC::FCC_U = 23 and so on.) -The code generator backend maps instruction operands to fields in the @@ -1289,12 +1258,12 @@ the rd, rs1, and rs2 fields respectively.
The final step is to hand code portions of XXXInstrInfo, which @@ -1305,9 +1274,6 @@ implementation in SparcInstrInfo.cpp:
Performance can be improved by combining instructions or by eliminating @@ -1493,13 +1460,15 @@ branch.
LLVM uses a SelectionDAG to represent LLVM IR instructions, and nodes @@ -1541,7 +1510,7 @@ selection pass into the queue of passes to run. The LLVM static compiler (llc) is an excellent tool for visualizing the contents of DAGs. To display the SelectionDAG before or after specific processing phases, use the command line options for llc, described -at +at SelectionDAG Instruction Selection Process.
@@ -1650,14 +1619,12 @@ SDNode *Select_ISD_STORE(const SDValue &N) {The Legalize phase converts a DAG to use types and operations that are natively @@ -1724,14 +1691,12 @@ a LegalAction type enum value: Promote, Expand, contains examples of all four LegalAction values.
-For an operation without native support for a given type, the specified type may @@ -1750,11 +1715,11 @@ setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
For a type without native support, a value may need to be broken down further, @@ -1775,11 +1740,11 @@ setOperationAction(ISD::FCOS, MVT::f32, Expand);
For some operations, simple type promotion or operation expansion may be @@ -1833,7 +1798,7 @@ register to convert the floating-point value to an integer. static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) { assert(Op.getValueType() == MVT::i32); Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0)); - return DAG.getNode(ISD::BIT_CONVERT, MVT::i32, Op); + return DAG.getNode(ISD::BITCAST, MVT::i32, Op); }
The Legal LegalizeAction enum value simply indicates that an @@ -1873,12 +1838,14 @@ if (TM.getSubtarget<SparcSubtarget>().isV9())
To support target-specific calling conventions, XXXGenCallingConv.td @@ -2023,13 +1990,15 @@ def RetCC_X86_32 : CallingConv<[
During the code emission stage, the code generator may utilize an LLVM pass to @@ -2152,21 +2121,13 @@ in XXXGenAsmWriter.inc contains an implementation of the
The implementations of printDeclare, printImplicitDef, printInlineAsm, and printLabel in AsmPrinter.cpp are generally adequate for printing assembly and do not need to be -overridden. (printBasicBlockLabel is another method that is implemented -in AsmPrinter.cpp that may be directly used in an implementation of -XXXAsmPrinter.) +overridden.
@@ -2187,12 +2148,12 @@ output.
Subtarget support is used to inform the code generation process of instruction @@ -2305,12 +2266,12 @@ XXXSubtarget::XXXSubtarget(const Module &M, const std::string &FS) {
The implementation of a target machine optionally includes a Just-In-Time (JIT) @@ -2349,14 +2310,12 @@ Both XXXJITInfo.cpp and XXXCodeEmitter.cpp must include the that write data (in bytes, words, strings, etc.) to the output stream.
-In XXXCodeEmitter.cpp, a target-specific of the Emitter class @@ -2494,11 +2453,11 @@ enum RelocationType {
XXXJITInfo.cpp implements the JIT interfaces for target-specific @@ -2553,6 +2512,8 @@ with assembler.