<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Writing an LLVM Compiler Backend</title>
- <link rel="stylesheet" href="llvm.css" type="text/css">
+ <link rel="stylesheet" href="_static/llvm.css" type="text/css">
</head>
<body>
-<div class="doc_title">
+<h1>
Writing an LLVM Compiler Backend
-</div>
+</h1>
<ol>
<li><a href="#intro">Introduction</a>
<li><a href="#InstructionSet">Instruction Set</a>
<ul>
<li><a href="#operandMapping">Instruction Operand Mapping</a></li>
+ <li><a href="#relationMapping">Instruction Relation Mapping</a></li>
<li><a href="#implementInstr">Implement a subclass of TargetInstrInfo</a></li>
<li><a href="#branchFolding">Branch Folding and If Conversion</a></li>
</ul></li>
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="intro">Introduction</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
This document describes techniques for writing compiler backends that convert
<p>
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.
</p>
conventions.
</p>
-</div>
-
-<div class="doc_subsection">
+<h3>
<a name="Audience">Audience</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
The audience for this document is anyone who needs to write an LLVM backend to
</div>
-<div class="doc_subsection">
+<h3>
<a name="Prerequisite">Prerequisite Reading</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
These essential documents must be read before reading this document:
</p>
<ul>
-<li><i><a href="http://www.llvm.org/docs/LangRef.html">LLVM Language Reference
+<li><i><a href="LangRef.html">LLVM Language Reference
Manual</a></i> — a reference manual for the LLVM assembly language.</li>
-<li><i><a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM
+<li><i><a href="CodeGenerator.html">The LLVM
Target-Independent Code Generator</a></i> — a guide to the components
(classes and code generation algorithms) for translating the LLVM internal
representation into machine code for a specified target. Pay particular
Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations,
and Code Emission.</li>
-<li><i><a href="http://www.llvm.org/docs/TableGenFundamentals.html">TableGen
+<li><i><a href="TableGenFundamentals.html">TableGen
Fundamentals</a></i> —a document that describes the TableGen
(<tt>tblgen</tt>) application that manages domain-specific information to
support LLVM code generation. TableGen processes input from a target
description file (<tt>.td</tt> suffix) and generates C++ code that can be
used for code generation.</li>
-<li><i><a href="http://www.llvm.org/docs/WritingAnLLVMPass.html">Writing an LLVM
+<li><i><a href="WritingAnLLVMPass.html">Writing an LLVM
Pass</a></i> — The assembly printer is a <tt>FunctionPass</tt>, as are
several SelectionDAG processing steps.</li>
</ul>
</div>
-<div class="doc_subsection">
+<h3>
<a name="Basic">Basic Steps</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
To write a compiler backend for LLVM that converts the LLVM IR to code for a
</div>
-<div class="doc_subsection">
+<h3>
<a name="Preliminaries">Preliminaries</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
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 <a href="http://www.llvm.org/docs/CodeGenerator.html">LLVM
+the <a href="CodeGenerator.html">LLVM
Target-Independent Code Generator</a> document.
</p>
</div>
+</div>
+
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="TargetMachine">Target Machine</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
<tt>LLVMTargetMachine</tt> is designed as a base class for targets implemented
intended to obtain the instruction set (<tt>getInstrInfo</tt>), register set
(<tt>getRegisterInfo</tt>), stack frame layout (<tt>getFrameInfo</tt>), and
similar information. <tt>XXXTargetMachine</tt> must also implement the
-<tt>getTargetData</tt> method to access an object with target-specific data
+<tt>getDataLayout</tt> method to access an object with target-specific data
characteristics, such as data type size and alignment requirements.
</p>
<p>
For instance, for the SPARC target, the header file
<tt>SparcTargetMachine.h</tt> declares prototypes for several <tt>get*Info</tt>
-and <tt>getTargetData</tt> methods that simply return a class member.
+and <tt>getDataLayout</tt> methods that simply return a class member.
</p>
<div class="doc_code">
class Module;
class SparcTargetMachine : public LLVMTargetMachine {
- const TargetData DataLayout; // Calculates type size & alignment
+ const DataLayout DataLayout; // Calculates type size & alignment
SparcSubtarget Subtarget;
SparcInstrInfo InstrInfo;
TargetFrameInfo FrameInfo;
virtual const TargetRegisterInfo *getRegisterInfo() const {
return &InstrInfo.getRegisterInfo();
}
- virtual const TargetData *getTargetData() const { return &DataLayout; }
+ virtual const DataLayout *getDataLayout() const { return &DataLayout; }
static unsigned getModuleMatchQuality(const Module &M);
// Pass Pipeline Configuration
</pre>
</div>
-</div>
-
-
-<div class="doc_text">
-
<ul>
<li><tt>getInstrInfo()</tt></li>
<li><tt>getRegisterInfo()</tt></li>
<li><tt>getFrameInfo()</tt></li>
-<li><tt>getTargetData()</tt></li>
+<li><tt>getDataLayout()</tt></li>
<li><tt>getSubtargetImpl()</tt></li>
</ul>
</pre>
</div>
-</div>
-
-<div class="doc_text">
-
<p>Hyphens separate portions of the <tt>TargetDescription</tt> string.</p>
<ul>
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="TargetRegistration">Target Registration</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
You must also register your target with the <tt>TargetRegistry</tt>, which is
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="RegisterSet">Register Set and Register Classes</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
You should describe a concrete target-specific class that represents the
implementation of <tt>XXXRegisterInfo</tt> requires hand-coding.
</p>
-</div>
-
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="RegisterDef">Defining a Register</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
The <tt>XXXRegisterInfo.td</tt> file typically starts with register definitions
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="RegisterClassDef">Defining a Register Class</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
The <tt>RegisterClass</tt> class (specified in <tt>Target.td</tt>) is used to
<div class="doc_code">
<pre>
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
// 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 = [];
memory.</li>
<li>The final argument, <tt>regList</tt>, specifies which registers are in this
- class. If an <tt>allocation_order_*</tt> method is not specified,
- then <tt>regList</tt> also defines the order of allocation used by the
- register allocator.</li>
+ class. If an alternative allocation order method is not specified, then
+ <tt>regList</tt> also defines the order of allocation used by the register
+ allocator. Besides simply listing registers with <tt>(add R0, R1, ...)</tt>,
+ more advanced set operators are available. See
+ <tt>include/llvm/Target/Target.td</tt> for more information.</li>
</ul>
<p>
'<tt>SP</tt>'. <tt>FPRegs</tt> defines a group of 32 single-precision
floating-point registers (<tt>F0</tt> to <tt>F31</tt>); <tt>DFPRegs</tt> defines
a group of 16 double-precision registers
-(<tt>D0-D15</tt>). For <tt>IntRegs</tt>, the <tt>MethodProtos</tt>
-and <tt>MethodBodies</tt> methods are used by TableGen to insert the specified
-code into generated output.
+(<tt>D0-D15</tt>).
</p>
<div class="doc_code">
<pre>
-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
+ )>;
</pre>
</div>
register implementation. The code below shows only the generated integer
registers and associated register classes. The order of registers
in <tt>IntRegs</tt> reflects the order in the definition of <tt>IntRegs</tt> in
-the target description file. Take special note of the use
-of <tt>MethodBodies</tt> in <tt>SparcRegisterInfo.td</tt> to create code in
-<tt>SparcGenRegisterInfo.inc</tt>. <tt>MethodProtos</tt> generates similar code
-in <tt>SparcGenRegisterInfo.h.inc</tt>.
+the target description file.
</p>
<div class="doc_code">
static const TargetRegisterClass* const IntRegsSuperclasses [] = {
NULL
};
-...
- IntRegsClass::iterator
- IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
- return end()-10 // Don't allocate special registers
- -1;
- }
-
+
IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID,
IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses,
IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {}
</pre>
</div>
+<p>
+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.
+</p>
+
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="implementRegister">Implement a subclass of</a>
- <a href="http://www.llvm.org/docs/CodeGenerator.html#targetregisterinfo">TargetRegisterInfo</a>
-</div>
+ <a href="CodeGenerator.html#targetregisterinfo">TargetRegisterInfo</a>
+</h3>
-<div class="doc_text">
+<div>
<p>
The final step is to hand code portions of <tt>XXXRegisterInfo</tt>, which
<li><tt>getCalleeSavedRegs</tt> — Returns a list of callee-saved registers
in the order of the desired callee-save stack frame offset.</li>
-<li><tt>getCalleeSavedRegClasses</tt> — Returns a list of preferred
- register classes with which to spill each callee saved register.</li>
-
<li><tt>getReservedRegs</tt> — Returns a bitset indexed by physical
register numbers, indicating if a particular register is unavailable.</li>
</div>
+</div>
+
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="InstructionSet">Instruction Set</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
During the early stages of code generation, the LLVM IR code is converted to a
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
-(<a href="http://www.llvm.org/docs/CodeGenerator.html">The LLVM
+(<a href="CodeGenerator.html">The LLVM
Target-Independent Code Generator</a>). This parameter is detailed in the next
section, <a href="#InstructionSelector">Instruction Selector</a>.
</p>
<tt>SPCC::ICC_NE = 9</tt>, <tt>SPCC::FCC_U = 23</tt> and so on.)
</p>
-</div>
-
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="operandMapping">Instruction Operand Mapping</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
The code generator backend maps instruction operands to fields in the
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
- <a name="implementInstr">Implement a subclass of </a>
- <a href="http://www.llvm.org/docs/CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a>
+<h3>
+ <a name="relationMapping">Instruction Relation Mapping</a>
+</h3>
+
+<div>
+
+<p>
+This TableGen feature is used to relate instructions with each other. It is
+particularly useful when you have multiple instruction formats and need to
+switch between them after instruction selection. This entire feature is driven
+by relation models which can be defined in <tt>XXXInstrInfo.td</tt> files
+according to the target-specific instruction set. Relation models are defined
+using <tt>InstrMapping</tt> class as a base. TableGen parses all the models
+and generates instruction relation maps using the specified information.
+Relation maps are emitted as tables in the <tt>XXXGenInstrInfo.inc</tt> file
+along with the functions to query them. For the detailed information on how to
+use this feature, please refer to
+<a href="HowToUseInstrMappings.html">How to add Instruction Mappings</a>
+document.
+</p>
</div>
-<div class="doc_text">
+<!-- ======================================================================= -->
+<h3>
+ <a name="implementInstr">Implement a subclass of </a>
+ <a href="CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a>
+</h3>
+
+<div>
<p>
The final step is to hand code portions of <tt>XXXInstrInfo</tt>, which
</p>
<ul>
-<li><tt>isMoveInstr</tt> — Return true if the instruction is a register to
- register move; false, otherwise.</li>
-
<li><tt>isLoadFromStackSlot</tt> — If the specified machine instruction is
a direct load from a stack slot, return the register number of the
destination and the <tt>FrameIndex</tt> of the stack slot.</li>
a direct store to a stack slot, return the register number of the
destination and the <tt>FrameIndex</tt> of the stack slot.</li>
-<li><tt>copyRegToReg</tt> — Copy values between a pair of registers.</li>
+<li><tt>copyPhysReg</tt> — Copy values between a pair of physical
+ registers.</li>
<li><tt>storeRegToStackSlot</tt> — Store a register value to a stack
slot.</li>
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="branchFolding">Branch Folding and If Conversion</a>
-</div>
-<div class="doc_text">
+</h3>
+<div>
<p>
Performance can be improved by combining instructions or by eliminating
</div>
+</div>
+
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="InstructionSelector">Instruction Selector</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
LLVM uses a <tt>SelectionDAG</tt> to represent LLVM IR instructions, and nodes
The LLVM static compiler (<tt>llc</tt>) is an excellent tool for visualizing the
contents of DAGs. To display the <tt>SelectionDAG</tt> before or after specific
processing phases, use the command line options for <tt>llc</tt>, described
-at <a href="http://llvm.org/docs/CodeGenerator.html#selectiondag_process">
+at <a href="CodeGenerator.html#selectiondag_process">
SelectionDAG Instruction Selection Process</a>.
</p>
</pre>
</div>
-</div>
-
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="LegalizePhase">The SelectionDAG Legalize Phase</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
The Legalize phase converts a DAG to use types and operations that are natively
contains examples of all four <tt>LegalAction</tt> values.
</p>
-</div>
-
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
+<h4>
<a name="promote">Promote</a>
-</div>
+</h4>
-<div class="doc_text">
+<div>
<p>
For an operation without native support for a given type, the specified type may
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
+<h4>
<a name="expand">Expand</a>
-</div>
+</h4>
-<div class="doc_text">
+<div>
<p>
For a type without native support, a value may need to be broken down further,
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
+<h4>
<a name="custom">Custom</a>
-</div>
+</h4>
-<div class="doc_text">
+<div>
<p>
For some operations, simple type promotion or operation expansion may be
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);
}
</pre>
</div>
</div>
<!-- _______________________________________________________________________ -->
-<div class="doc_subsubsection">
+<h4>
<a name="legal">Legal</a>
-</div>
+</h4>
-<div class="doc_text">
+<div>
<p>
The <tt>Legal</tt> LegalizeAction enum value simply indicates that an
</div>
+</div>
+
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="callingConventions">Calling Conventions</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
To support target-specific calling conventions, <tt>XXXGenCallingConv.td</tt>
</div>
+</div>
+
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="assemblyPrinter">Assembly Printer</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
During the code emission stage, the code generator may utilize an LLVM pass to
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="subtargetSupport">Subtarget Support</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
Subtarget support is used to inform the code generation process of instruction
</div>
<!-- *********************************************************************** -->
-<div class="doc_section">
+<h2>
<a name="jitSupport">JIT Support</a>
-</div>
+</h2>
<!-- *********************************************************************** -->
-<div class="doc_text">
+<div>
<p>
The implementation of a target machine optionally includes a Just-In-Time (JIT)
that write data (in bytes, words, strings, etc.) to the output stream.
</p>
-</div>
-
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="mce">Machine Code Emitter</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
In <tt>XXXCodeEmitter.cpp</tt>, a target-specific of the <tt>Emitter</tt> class
</div>
<!-- ======================================================================= -->
-<div class="doc_subsection">
+<h3>
<a name="targetJITInfo">Target JIT Info</a>
-</div>
+</h3>
-<div class="doc_text">
+<div>
<p>
<tt>XXXJITInfo.cpp</tt> implements the JIT interfaces for target-specific
</div>
+</div>
+
<!-- *********************************************************************** -->
<hr>
src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
<a href="http://www.woo.com">Mason Woo</a> and <a href="http://misha.brukman.net">Misha Brukman</a><br>
- <a href="http://llvm.org">The LLVM Compiler Infrastructure</a>
+ <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a>
<br>
Last modified: $Date$
</address>
projects / oota-llvm.git / blobdiff