blob: 0ad472cb92310de73d403fd55ee9503bf9221b18 [file] [log] [blame]
Misha Brukman8eb67192004-09-06 22:58:13 +00001<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
2 "http://www.w3.org/TR/html4/strict.dtd">
3<html>
4<head>
Bill Wendlinge6b48792009-04-05 00:44:06 +00005 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Chris Lattner78975382008-11-11 19:30:41 +00006 <title>Writing an LLVM Compiler Backend</title>
Daniel Dunbaradea4972012-04-19 20:20:34 +00007 <link rel="stylesheet" href="_static/llvm.css" type="text/css">
Misha Brukman8eb67192004-09-06 22:58:13 +00008</head>
9
10<body>
11
NAKAMURA Takumi05d02652011-04-18 23:59:50 +000012<h1>
Chris Lattner78975382008-11-11 19:30:41 +000013 Writing an LLVM Compiler Backend
NAKAMURA Takumi05d02652011-04-18 23:59:50 +000014</h1>
Misha Brukman8eb67192004-09-06 22:58:13 +000015
16<ol>
17 <li><a href="#intro">Introduction</a>
Chris Lattner78975382008-11-11 19:30:41 +000018 <ul>
19 <li><a href="#Audience">Audience</a></li>
20 <li><a href="#Prerequisite">Prerequisite Reading</a></li>
21 <li><a href="#Basic">Basic Steps</a></li>
22 <li><a href="#Preliminaries">Preliminaries</a></li>
23 </ul>
24 <li><a href="#TargetMachine">Target Machine</a></li>
Daniel Dunbard6b06b12009-07-26 05:41:39 +000025 <li><a href="#TargetRegistration">Target Registration</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000026 <li><a href="#RegisterSet">Register Set and Register Classes</a>
Chris Lattner78975382008-11-11 19:30:41 +000027 <ul>
28 <li><a href="#RegisterDef">Defining a Register</a></li>
29 <li><a href="#RegisterClassDef">Defining a Register Class</a></li>
30 <li><a href="#implementRegister">Implement a subclass of TargetRegisterInfo</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000031 </ul></li>
32 <li><a href="#InstructionSet">Instruction Set</a>
Chris Lattner78975382008-11-11 19:30:41 +000033 <ul>
Chris Lattner7a152732008-11-22 19:10:48 +000034 <li><a href="#operandMapping">Instruction Operand Mapping</a></li>
Sebastian Popbecdf4d2012-10-25 15:54:06 +000035 <li><a href="#relationMapping">Instruction Relation Mapping</a></li>
Chris Lattner78975382008-11-11 19:30:41 +000036 <li><a href="#implementInstr">Implement a subclass of TargetInstrInfo</a></li>
37 <li><a href="#branchFolding">Branch Folding and If Conversion</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000038 </ul></li>
39 <li><a href="#InstructionSelector">Instruction Selector</a>
Chris Lattner78975382008-11-11 19:30:41 +000040 <ul>
Chris Lattner528875c2008-11-11 19:34:28 +000041 <li><a href="#LegalizePhase">The SelectionDAG Legalize Phase</a>
Chris Lattner78975382008-11-11 19:30:41 +000042 <ul>
43 <li><a href="#promote">Promote</a></li>
44 <li><a href="#expand">Expand</a></li>
45 <li><a href="#custom">Custom</a></li>
46 <li><a href="#legal">Legal</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000047 </ul></li>
Chris Lattner78975382008-11-11 19:30:41 +000048 <li><a href="#callingConventions">Calling Conventions</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000049 </ul></li>
Chris Lattner78975382008-11-11 19:30:41 +000050 <li><a href="#assemblyPrinter">Assembly Printer</a></li>
51 <li><a href="#subtargetSupport">Subtarget Support</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000052 <li><a href="#jitSupport">JIT Support</a>
Chris Lattner78975382008-11-11 19:30:41 +000053 <ul>
54 <li><a href="#mce">Machine Code Emitter</a></li>
55 <li><a href="#targetJITInfo">Target JIT Info</a></li>
Chris Lattner528875c2008-11-11 19:34:28 +000056 </ul></li>
Misha Brukman8eb67192004-09-06 22:58:13 +000057</ol>
58
59<div class="doc_author">
Bill Wendling4a2bca82009-04-05 00:41:19 +000060 <p>Written by <a href="http://www.woo.com">Mason Woo</a> and
61 <a href="http://misha.brukman.net">Misha Brukman</a></p>
Misha Brukman8eb67192004-09-06 22:58:13 +000062</div>
63
64<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +000065<h2>
Misha Brukman8eb67192004-09-06 22:58:13 +000066 <a name="intro">Introduction</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +000067</h2>
Misha Brukman8eb67192004-09-06 22:58:13 +000068<!-- *********************************************************************** -->
69
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +000070<div>
Misha Brukman8eb67192004-09-06 22:58:13 +000071
Bill Wendling4a2bca82009-04-05 00:41:19 +000072<p>
73This document describes techniques for writing compiler backends that convert
74the LLVM Intermediate Representation (IR) to code for a specified machine or
75other languages. Code intended for a specific machine can take the form of
76either assembly code or binary code (usable for a JIT compiler).
77</p>
Misha Brukman8eb67192004-09-06 22:58:13 +000078
Bill Wendling4a2bca82009-04-05 00:41:19 +000079<p>
80The backend of LLVM features a target-independent code generator that may create
Jia Liub3736472012-03-01 15:14:19 +000081output for several types of target CPUs &mdash; including X86, PowerPC, ARM,
Bill Wendling4a2bca82009-04-05 00:41:19 +000082and SPARC. The backend may also be used to generate code targeted at SPUs of the
83Cell processor or GPUs to support the execution of compute kernels.
84</p>
85
86<p>
87The document focuses on existing examples found in subdirectories
88of <tt>llvm/lib/Target</tt> in a downloaded LLVM release. In particular, this
89document focuses on the example of creating a static compiler (one that emits
90text assembly) for a SPARC target, because SPARC has fairly standard
Chris Lattner78975382008-11-11 19:30:41 +000091characteristics, such as a RISC instruction set and straightforward calling
Bill Wendling4a2bca82009-04-05 00:41:19 +000092conventions.
93</p>
94
NAKAMURA Takumi05d02652011-04-18 23:59:50 +000095<h3>
Chris Lattner78975382008-11-11 19:30:41 +000096 <a name="Audience">Audience</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +000097</h3>
Misha Brukman8eb67192004-09-06 22:58:13 +000098
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +000099<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000100
101<p>
102The audience for this document is anyone who needs to write an LLVM backend to
103generate code for a specific hardware or software target.
104</p>
105
Chris Lattner78975382008-11-11 19:30:41 +0000106</div>
Misha Brukman8eb67192004-09-06 22:58:13 +0000107
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000108<h3>
Chris Lattner78975382008-11-11 19:30:41 +0000109 <a name="Prerequisite">Prerequisite Reading</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000110</h3>
Misha Brukman8eb67192004-09-06 22:58:13 +0000111
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000112<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000113
114<p>
115These essential documents must be read before reading this document:
116</p>
117
Chris Lattner78975382008-11-11 19:30:41 +0000118<ul>
NAKAMURA Takumi31c18062011-04-09 02:13:48 +0000119<li><i><a href="LangRef.html">LLVM Language Reference
Bill Wendling4a2bca82009-04-05 00:41:19 +0000120 Manual</a></i> &mdash; a reference manual for the LLVM assembly language.</li>
121
NAKAMURA Takumi31c18062011-04-09 02:13:48 +0000122<li><i><a href="CodeGenerator.html">The LLVM
Bill Wendling4a2bca82009-04-05 00:41:19 +0000123 Target-Independent Code Generator</a></i> &mdash; a guide to the components
124 (classes and code generation algorithms) for translating the LLVM internal
125 representation into machine code for a specified target. Pay particular
126 attention to the descriptions of code generation stages: Instruction
127 Selection, Scheduling and Formation, SSA-based Optimization, Register
128 Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations,
129 and Code Emission.</li>
130
NAKAMURA Takumi31c18062011-04-09 02:13:48 +0000131<li><i><a href="TableGenFundamentals.html">TableGen
Bill Wendling4a2bca82009-04-05 00:41:19 +0000132 Fundamentals</a></i> &mdash;a document that describes the TableGen
133 (<tt>tblgen</tt>) application that manages domain-specific information to
134 support LLVM code generation. TableGen processes input from a target
135 description file (<tt>.td</tt> suffix) and generates C++ code that can be
136 used for code generation.</li>
137
NAKAMURA Takumi31c18062011-04-09 02:13:48 +0000138<li><i><a href="WritingAnLLVMPass.html">Writing an LLVM
Bill Wendling4a2bca82009-04-05 00:41:19 +0000139 Pass</a></i> &mdash; The assembly printer is a <tt>FunctionPass</tt>, as are
140 several SelectionDAG processing steps.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000141</ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000142
143<p>
144To follow the SPARC examples in this document, have a copy of
145<i><a href="http://www.sparc.org/standards/V8.pdf">The SPARC Architecture
146Manual, Version 8</a></i> for reference. For details about the ARM instruction
147set, refer to the <i><a href="http://infocenter.arm.com/">ARM Architecture
148Reference Manual</a></i>. For more about the GNU Assembler format
149(<tt>GAS</tt>), see
150<i><a href="http://sourceware.org/binutils/docs/as/index.html">Using As</a></i>,
151especially for the assembly printer. <i>Using As</i> contains a list of target
152machine dependent features.
153</p>
154
Chris Lattner78975382008-11-11 19:30:41 +0000155</div>
156
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000157<h3>
Chris Lattner78975382008-11-11 19:30:41 +0000158 <a name="Basic">Basic Steps</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000159</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000160
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000161<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000162
163<p>
164To write a compiler backend for LLVM that converts the LLVM IR to code for a
165specified target (machine or other language), follow these steps:
166</p>
Misha Brukman8eb67192004-09-06 22:58:13 +0000167
168<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000169<li>Create a subclass of the TargetMachine class that describes characteristics
170 of your target machine. Copy existing examples of specific TargetMachine
171 class and header files; for example, start with
172 <tt>SparcTargetMachine.cpp</tt> and <tt>SparcTargetMachine.h</tt>, but
173 change the file names for your target. Similarly, change code that
174 references "Sparc" to reference your target. </li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000175
Bill Wendling4a2bca82009-04-05 00:41:19 +0000176<li>Describe the register set of the target. Use TableGen to generate code for
177 register definition, register aliases, and register classes from a
178 target-specific <tt>RegisterInfo.td</tt> input file. You should also write
179 additional code for a subclass of the TargetRegisterInfo class that
180 represents the class register file data used for register allocation and
181 also describes the interactions between registers.</li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000182
Bill Wendling4a2bca82009-04-05 00:41:19 +0000183<li>Describe the instruction set of the target. Use TableGen to generate code
184 for target-specific instructions from target-specific versions of
185 <tt>TargetInstrFormats.td</tt> and <tt>TargetInstrInfo.td</tt>. You should
186 write additional code for a subclass of the TargetInstrInfo class to
187 represent machine instructions supported by the target machine. </li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000188
Bill Wendling4a2bca82009-04-05 00:41:19 +0000189<li>Describe the selection and conversion of the LLVM IR from a Directed Acyclic
190 Graph (DAG) representation of instructions to native target-specific
191 instructions. Use TableGen to generate code that matches patterns and
192 selects instructions based on additional information in a target-specific
193 version of <tt>TargetInstrInfo.td</tt>. Write code
194 for <tt>XXXISelDAGToDAG.cpp</tt>, where XXX identifies the specific target,
195 to perform pattern matching and DAG-to-DAG instruction selection. Also write
196 code in <tt>XXXISelLowering.cpp</tt> to replace or remove operations and
197 data types that are not supported natively in a SelectionDAG. </li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000198
Bill Wendling4a2bca82009-04-05 00:41:19 +0000199<li>Write code for an assembly printer that converts LLVM IR to a GAS format for
200 your target machine. You should add assembly strings to the instructions
201 defined in your target-specific version of <tt>TargetInstrInfo.td</tt>. You
202 should also write code for a subclass of AsmPrinter that performs the
203 LLVM-to-assembly conversion and a trivial subclass of TargetAsmInfo.</li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000204
Bill Wendling4a2bca82009-04-05 00:41:19 +0000205<li>Optionally, add support for subtargets (i.e., variants with different
206 capabilities). You should also write code for a subclass of the
207 TargetSubtarget class, which allows you to use the <tt>-mcpu=</tt>
208 and <tt>-mattr=</tt> command-line options.</li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000209
Bill Wendling4a2bca82009-04-05 00:41:19 +0000210<li>Optionally, add JIT support and create a machine code emitter (subclass of
211 TargetJITInfo) that is used to emit binary code directly into memory. </li>
Misha Brukman8eb67192004-09-06 22:58:13 +0000212</ul>
213
Bill Wendling4a2bca82009-04-05 00:41:19 +0000214<p>
215In the <tt>.cpp</tt> and <tt>.h</tt>. files, initially stub up these methods and
Chris Lattner78975382008-11-11 19:30:41 +0000216then implement them later. Initially, you may not know which private members
Bill Wendling4a2bca82009-04-05 00:41:19 +0000217that the class will need and which components will need to be subclassed.
218</p>
219
Misha Brukman8eb67192004-09-06 22:58:13 +0000220</div>
221
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000222<h3>
Chris Lattner78975382008-11-11 19:30:41 +0000223 <a name="Preliminaries">Preliminaries</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000224</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000225
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000226<div>
Misha Brukman8eb67192004-09-06 22:58:13 +0000227
Bill Wendling4a2bca82009-04-05 00:41:19 +0000228<p>
229To actually create your compiler backend, you need to create and modify a few
230files. The absolute minimum is discussed here. But to actually use the LLVM
231target-independent code generator, you must perform the steps described in
NAKAMURA Takumi31c18062011-04-09 02:13:48 +0000232the <a href="CodeGenerator.html">LLVM
Bill Wendling4a2bca82009-04-05 00:41:19 +0000233Target-Independent Code Generator</a> document.
234</p>
Matthijs Kooijman6aa81272008-09-29 11:52:22 +0000235
Bill Wendling4a2bca82009-04-05 00:41:19 +0000236<p>
237First, you should create a subdirectory under <tt>lib/Target</tt> to hold all
238the files related to your target. If your target is called "Dummy," create the
239directory <tt>lib/Target/Dummy</tt>.
240</p>
Matthijs Kooijman6aa81272008-09-29 11:52:22 +0000241
Bill Wendling4a2bca82009-04-05 00:41:19 +0000242<p>
243In this new
244directory, create a <tt>Makefile</tt>. It is easiest to copy a
245<tt>Makefile</tt> of another target and modify it. It should at least contain
246the <tt>LEVEL</tt>, <tt>LIBRARYNAME</tt> and <tt>TARGET</tt> variables, and then
247include <tt>$(LEVEL)/Makefile.common</tt>. The library can be
248named <tt>LLVMDummy</tt> (for example, see the MIPS target). Alternatively, you
249can split the library into <tt>LLVMDummyCodeGen</tt>
250and <tt>LLVMDummyAsmPrinter</tt>, the latter of which should be implemented in a
251subdirectory below <tt>lib/Target/Dummy</tt> (for example, see the PowerPC
252target).
253</p>
Matthijs Kooijman6aa81272008-09-29 11:52:22 +0000254
Bill Wendling4a2bca82009-04-05 00:41:19 +0000255<p>
256Note that these two naming schemes are hardcoded into <tt>llvm-config</tt>.
257Using any other naming scheme will confuse <tt>llvm-config</tt> and produce a
258lot of (seemingly unrelated) linker errors when linking <tt>llc</tt>.
259</p>
Matthijs Kooijman6aa81272008-09-29 11:52:22 +0000260
Bill Wendling4a2bca82009-04-05 00:41:19 +0000261<p>
262To make your target actually do something, you need to implement a subclass of
263<tt>TargetMachine</tt>. This implementation should typically be in the file
264<tt>lib/Target/DummyTargetMachine.cpp</tt>, but any file in
265the <tt>lib/Target</tt> directory will be built and should work. To use LLVM's
266target independent code generator, you should do what all current machine
267backends do: create a subclass of <tt>LLVMTargetMachine</tt>. (To create a
268target from scratch, create a subclass of <tt>TargetMachine</tt>.)
269</p>
270
271<p>
272To get LLVM to actually build and link your target, you need to add it to
273the <tt>TARGETS_TO_BUILD</tt> variable. To do this, you modify the configure
274script to know about your target when parsing the <tt>--enable-targets</tt>
275option. Search the configure script for <tt>TARGETS_TO_BUILD</tt>, add your
276target to the lists there (some creativity required), and then
Chris Lattner78975382008-11-11 19:30:41 +0000277reconfigure. Alternatively, you can change <tt>autotools/configure.ac</tt> and
Bill Wendling4a2bca82009-04-05 00:41:19 +0000278regenerate configure by running <tt>./autoconf/AutoRegen.sh</tt>.
279</p>
280
Matthijs Kooijman6aa81272008-09-29 11:52:22 +0000281</div>
Misha Brukman8eb67192004-09-06 22:58:13 +0000282
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000283</div>
284
Misha Brukman8eb67192004-09-06 22:58:13 +0000285<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000286<h2>
Chris Lattner78975382008-11-11 19:30:41 +0000287 <a name="TargetMachine">Target Machine</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000288</h2>
Chris Lattner78975382008-11-11 19:30:41 +0000289<!-- *********************************************************************** -->
Bill Wendling4a2bca82009-04-05 00:41:19 +0000290
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000291<div>
Chris Lattner78975382008-11-11 19:30:41 +0000292
Bill Wendling4a2bca82009-04-05 00:41:19 +0000293<p>
294<tt>LLVMTargetMachine</tt> is designed as a base class for targets implemented
295with the LLVM target-independent code generator. The <tt>LLVMTargetMachine</tt>
296class should be specialized by a concrete target class that implements the
297various virtual methods. <tt>LLVMTargetMachine</tt> is defined as a subclass of
298<tt>TargetMachine</tt> in <tt>include/llvm/Target/TargetMachine.h</tt>. The
299<tt>TargetMachine</tt> class implementation (<tt>TargetMachine.cpp</tt>) also
300processes numerous command-line options.
301</p>
302
303<p>
304To create a concrete target-specific subclass of <tt>LLVMTargetMachine</tt>,
305start by copying an existing <tt>TargetMachine</tt> class and header. You
306should name the files that you create to reflect your specific target. For
Chris Lattner78975382008-11-11 19:30:41 +0000307instance, for the SPARC target, name the files <tt>SparcTargetMachine.h</tt> and
Bill Wendling4a2bca82009-04-05 00:41:19 +0000308<tt>SparcTargetMachine.cpp</tt>.
309</p>
Chris Lattner78975382008-11-11 19:30:41 +0000310
Bill Wendling4a2bca82009-04-05 00:41:19 +0000311<p>
312For a target machine <tt>XXX</tt>, the implementation of
313<tt>XXXTargetMachine</tt> must have access methods to obtain objects that
314represent target components. These methods are named <tt>get*Info</tt>, and are
315intended to obtain the instruction set (<tt>getInstrInfo</tt>), register set
316(<tt>getRegisterInfo</tt>), stack frame layout (<tt>getFrameInfo</tt>), and
317similar information. <tt>XXXTargetMachine</tt> must also implement the
Micah Villmow791cfc22012-10-08 16:39:34 +0000318<tt>getDataLayout</tt> method to access an object with target-specific data
Bill Wendling4a2bca82009-04-05 00:41:19 +0000319characteristics, such as data type size and alignment requirements.
320</p>
Chris Lattner78975382008-11-11 19:30:41 +0000321
Bill Wendling4a2bca82009-04-05 00:41:19 +0000322<p>
323For instance, for the SPARC target, the header file
324<tt>SparcTargetMachine.h</tt> declares prototypes for several <tt>get*Info</tt>
Micah Villmow791cfc22012-10-08 16:39:34 +0000325and <tt>getDataLayout</tt> methods that simply return a class member.
Bill Wendling4a2bca82009-04-05 00:41:19 +0000326</p>
Chris Lattner78975382008-11-11 19:30:41 +0000327
328<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +0000329<pre>
330namespace llvm {
Chris Lattner78975382008-11-11 19:30:41 +0000331
332class Module;
333
334class SparcTargetMachine : public LLVMTargetMachine {
Micah Villmow791cfc22012-10-08 16:39:34 +0000335 const DataLayout DataLayout; // Calculates type size &amp; alignment
Chris Lattner78975382008-11-11 19:30:41 +0000336 SparcSubtarget Subtarget;
337 SparcInstrInfo InstrInfo;
338 TargetFrameInfo FrameInfo;
339
340protected:
Bill Wendling4a2bca82009-04-05 00:41:19 +0000341 virtual const TargetAsmInfo *createTargetAsmInfo() const;
Chris Lattner78975382008-11-11 19:30:41 +0000342
343public:
344 SparcTargetMachine(const Module &amp;M, const std::string &amp;FS);
345
346 virtual const SparcInstrInfo *getInstrInfo() const {return &amp;InstrInfo; }
347 virtual const TargetFrameInfo *getFrameInfo() const {return &amp;FrameInfo; }
348 virtual const TargetSubtarget *getSubtargetImpl() const{return &amp;Subtarget; }
349 virtual const TargetRegisterInfo *getRegisterInfo() const {
350 return &amp;InstrInfo.getRegisterInfo();
351 }
Micah Villmow791cfc22012-10-08 16:39:34 +0000352 virtual const DataLayout *getDataLayout() const { return &amp;DataLayout; }
Chris Lattner78975382008-11-11 19:30:41 +0000353 static unsigned getModuleMatchQuality(const Module &amp;M);
354
355 // Pass Pipeline Configuration
356 virtual bool addInstSelector(PassManagerBase &amp;PM, bool Fast);
357 virtual bool addPreEmitPass(PassManagerBase &amp;PM, bool Fast);
Chris Lattner78975382008-11-11 19:30:41 +0000358};
359
360} // end namespace llvm
361</pre>
362</div>
363
Chris Lattner78975382008-11-11 19:30:41 +0000364<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000365<li><tt>getInstrInfo()</tt></li>
366<li><tt>getRegisterInfo()</tt></li>
367<li><tt>getFrameInfo()</tt></li>
Micah Villmow791cfc22012-10-08 16:39:34 +0000368<li><tt>getDataLayout()</tt></li>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000369<li><tt>getSubtargetImpl()</tt></li>
Chris Lattner78975382008-11-11 19:30:41 +0000370</ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000371
372<p>For some targets, you also need to support the following methods:</p>
373
374<ul>
375<li><tt>getTargetLowering()</tt></li>
376<li><tt>getJITInfo()</tt></li>
377</ul>
378
379<p>
380In addition, the <tt>XXXTargetMachine</tt> constructor should specify a
381<tt>TargetDescription</tt> string that determines the data layout for the target
382machine, including characteristics such as pointer size, alignment, and
383endianness. For example, the constructor for SparcTargetMachine contains the
384following:
385</p>
Chris Lattner78975382008-11-11 19:30:41 +0000386
387<div class="doc_code">
388<pre>
389SparcTargetMachine::SparcTargetMachine(const Module &amp;M, const std::string &amp;FS)
Bill Wendling4a2bca82009-04-05 00:41:19 +0000390 : DataLayout("E-p:32:32-f128:128:128"),
Chris Lattner78975382008-11-11 19:30:41 +0000391 Subtarget(M, FS), InstrInfo(Subtarget),
392 FrameInfo(TargetFrameInfo::StackGrowsDown, 8, 0) {
393}
394</pre>
395</div>
396
Bill Wendling4a2bca82009-04-05 00:41:19 +0000397<p>Hyphens separate portions of the <tt>TargetDescription</tt> string.</p>
398
399<ul>
400<li>An upper-case "<tt>E</tt>" in the string indicates a big-endian target data
401 model. a lower-case "<tt>e</tt>" indicates little-endian.</li>
402
403<li>"<tt>p:</tt>" is followed by pointer information: size, ABI alignment, and
404 preferred alignment. If only two figures follow "<tt>p:</tt>", then the
405 first value is pointer size, and the second value is both ABI and preferred
406 alignment.</li>
407
408<li>Then a letter for numeric type alignment: "<tt>i</tt>", "<tt>f</tt>",
409 "<tt>v</tt>", or "<tt>a</tt>" (corresponding to integer, floating point,
410 vector, or aggregate). "<tt>i</tt>", "<tt>v</tt>", or "<tt>a</tt>" are
411 followed by ABI alignment and preferred alignment. "<tt>f</tt>" is followed
412 by three values: the first indicates the size of a long double, then ABI
413 alignment, and then ABI preferred alignment.</li>
414</ul>
415
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000416</div>
417
418<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000419<h2>
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000420 <a name="TargetRegistration">Target Registration</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000421</h2>
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000422<!-- *********************************************************************** -->
423
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000424<div>
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000425
Bill Wendling4a2bca82009-04-05 00:41:19 +0000426<p>
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000427You must also register your target with the <tt>TargetRegistry</tt>, which is
428what other LLVM tools use to be able to lookup and use your target at
429runtime. The <tt>TargetRegistry</tt> can be used directly, but for most targets
430there are helper templates which should take care of the work for you.</p>
431
432<p>
433All targets should declare a global <tt>Target</tt> object which is used to
434represent the target during registration. Then, in the target's TargetInfo
435library, the target should define that object and use
436the <tt>RegisterTarget</tt> template to register the target. For example, the Sparc registration code looks like this:
Bill Wendling4a2bca82009-04-05 00:41:19 +0000437</p>
438
Chris Lattner78975382008-11-11 19:30:41 +0000439<div class="doc_code">
440<pre>
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000441Target llvm::TheSparcTarget;
442
443extern "C" void LLVMInitializeSparcTargetInfo() {
Benjamin Kramere15192b2009-08-05 15:42:44 +0000444 RegisterTarget&lt;Triple::sparc, /*HasJIT=*/false&gt;
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000445 X(TheSparcTarget, "sparc", "Sparc");
Chris Lattner78975382008-11-11 19:30:41 +0000446}
447</pre>
448</div>
449
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000450<p>
451This allows the <tt>TargetRegistry</tt> to look up the target by name or by
452target triple. In addition, most targets will also register additional features
453which are available in separate libraries. These registration steps are
454separate, because some clients may wish to only link in some parts of the target
455-- the JIT code generator does not require the use of the assembler printer, for
456example. Here is an example of registering the Sparc assembly printer:
457</p>
458
459<div class="doc_code">
460<pre>
461extern "C" void LLVMInitializeSparcAsmPrinter() {
Benjamin Kramere15192b2009-08-05 15:42:44 +0000462 RegisterAsmPrinter&lt;SparcAsmPrinter&gt; X(TheSparcTarget);
Daniel Dunbard6b06b12009-07-26 05:41:39 +0000463}
464</pre>
465</div>
466
467<p>
468For more information, see
469"<a href="/doxygen/TargetRegistry_8h-source.html">llvm/Target/TargetRegistry.h</a>".
470</p>
471
Bill Wendling4a2bca82009-04-05 00:41:19 +0000472</div>
473
Chris Lattner78975382008-11-11 19:30:41 +0000474<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000475<h2>
Chris Lattner78975382008-11-11 19:30:41 +0000476 <a name="RegisterSet">Register Set and Register Classes</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000477</h2>
Chris Lattner78975382008-11-11 19:30:41 +0000478<!-- *********************************************************************** -->
Chris Lattner78975382008-11-11 19:30:41 +0000479
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000480<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000481
482<p>
483You should describe a concrete target-specific class that represents the
484register file of a target machine. This class is called <tt>XXXRegisterInfo</tt>
485(where <tt>XXX</tt> identifies the target) and represents the class register
486file data that is used for register allocation. It also describes the
487interactions between registers.
488</p>
489
490<p>
491You also need to define register classes to categorize related registers. A
492register class should be added for groups of registers that are all treated the
493same way for some instruction. Typical examples are register classes for
494integer, floating-point, or vector registers. A register allocator allows an
Chris Lattner78975382008-11-11 19:30:41 +0000495instruction to use any register in a specified register class to perform the
496instruction in a similar manner. Register classes allocate virtual registers to
497instructions from these sets, and register classes let the target-independent
Bill Wendling4a2bca82009-04-05 00:41:19 +0000498register allocator automatically choose the actual registers.
499</p>
Chris Lattner78975382008-11-11 19:30:41 +0000500
Bill Wendling4a2bca82009-04-05 00:41:19 +0000501<p>
502Much of the code for registers, including register definition, register aliases,
503and register classes, is generated by TableGen from <tt>XXXRegisterInfo.td</tt>
504input files and placed in <tt>XXXGenRegisterInfo.h.inc</tt> and
505<tt>XXXGenRegisterInfo.inc</tt> output files. Some of the code in the
506implementation of <tt>XXXRegisterInfo</tt> requires hand-coding.
507</p>
508
Chris Lattner78975382008-11-11 19:30:41 +0000509<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000510<h3>
Chris Lattner78975382008-11-11 19:30:41 +0000511 <a name="RegisterDef">Defining a Register</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000512</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000513
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000514<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000515
516<p>
517The <tt>XXXRegisterInfo.td</tt> file typically starts with register definitions
518for a target machine. The <tt>Register</tt> class (specified
519in <tt>Target.td</tt>) is used to define an object for each register. The
520specified string <tt>n</tt> becomes the <tt>Name</tt> of the register. The
521basic <tt>Register</tt> object does not have any subregisters and does not
522specify any aliases.
523</p>
524
Chris Lattner78975382008-11-11 19:30:41 +0000525<div class="doc_code">
526<pre>
527class Register&lt;string n&gt; {
Bill Wendling4a2bca82009-04-05 00:41:19 +0000528 string Namespace = "";
Chris Lattner78975382008-11-11 19:30:41 +0000529 string AsmName = n;
530 string Name = n;
531 int SpillSize = 0;
532 int SpillAlignment = 0;
533 list&lt;Register&gt; Aliases = [];
534 list&lt;Register&gt; SubRegs = [];
535 list&lt;int&gt; DwarfNumbers = [];
536}
537</pre>
538</div>
539
Bill Wendling4a2bca82009-04-05 00:41:19 +0000540<p>
541For example, in the <tt>X86RegisterInfo.td</tt> file, there are register
542definitions that utilize the Register class, such as:
543</p>
544
Chris Lattner78975382008-11-11 19:30:41 +0000545<div class="doc_code">
546<pre>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000547def AL : Register&lt;"AL"&gt;, DwarfRegNum&lt;[0, 0, 0]&gt;;
Chris Lattner78975382008-11-11 19:30:41 +0000548</pre>
549</div>
550
Bill Wendling4a2bca82009-04-05 00:41:19 +0000551<p>
552This defines the register <tt>AL</tt> and assigns it values (with
553<tt>DwarfRegNum</tt>) that are used by <tt>gcc</tt>, <tt>gdb</tt>, or a debug
Chris Lattnerc3107782010-04-05 04:11:11 +0000554information writer to identify a register. For register
Bill Wendling4a2bca82009-04-05 00:41:19 +0000555<tt>AL</tt>, <tt>DwarfRegNum</tt> takes an array of 3 values representing 3
556different modes: the first element is for X86-64, the second for exception
557handling (EH) on X86-32, and the third is generic. -1 is a special Dwarf number
558that indicates the gcc number is undefined, and -2 indicates the register number
559is invalid for this mode.
560</p>
Chris Lattner78975382008-11-11 19:30:41 +0000561
Bill Wendling4a2bca82009-04-05 00:41:19 +0000562<p>
563From the previously described line in the <tt>X86RegisterInfo.td</tt> file,
564TableGen generates this code in the <tt>X86GenRegisterInfo.inc</tt> file:
565</p>
566
Chris Lattner78975382008-11-11 19:30:41 +0000567<div class="doc_code">
568<pre>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000569static const unsigned GR8[] = { X86::AL, ... };
570
571const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 };
572
573const TargetRegisterDesc RegisterDescriptors[] = {
574 ...
575{ "AL", "AL", AL_AliasSet, Empty_SubRegsSet, Empty_SubRegsSet, AL_SuperRegsSet }, ...
Chris Lattner78975382008-11-11 19:30:41 +0000576</pre>
577</div>
578
Bill Wendling4a2bca82009-04-05 00:41:19 +0000579<p>
580From the register info file, TableGen generates a <tt>TargetRegisterDesc</tt>
581object for each register. <tt>TargetRegisterDesc</tt> is defined in
582<tt>include/llvm/Target/TargetRegisterInfo.h</tt> with the following fields:
583</p>
Chris Lattner78975382008-11-11 19:30:41 +0000584
585<div class="doc_code">
586<pre>
587struct TargetRegisterDesc {
588 const char *AsmName; // Assembly language name for the register
589 const char *Name; // Printable name for the reg (for debugging)
590 const unsigned *AliasSet; // Register Alias Set
591 const unsigned *SubRegs; // Sub-register set
592 const unsigned *ImmSubRegs; // Immediate sub-register set
593 const unsigned *SuperRegs; // Super-register set
594};</pre>
595</div>
596
Bill Wendling4a2bca82009-04-05 00:41:19 +0000597<p>
598TableGen uses the entire target description file (<tt>.td</tt>) to determine
599text names for the register (in the <tt>AsmName</tt> and <tt>Name</tt> fields of
600<tt>TargetRegisterDesc</tt>) and the relationships of other registers to the
601defined register (in the other <tt>TargetRegisterDesc</tt> fields). In this
602example, other definitions establish the registers "<tt>AX</tt>",
603"<tt>EAX</tt>", and "<tt>RAX</tt>" as aliases for one another, so TableGen
604generates a null-terminated array (<tt>AL_AliasSet</tt>) for this register alias
605set.
606</p>
Chris Lattner78975382008-11-11 19:30:41 +0000607
Bill Wendling4a2bca82009-04-05 00:41:19 +0000608<p>
609The <tt>Register</tt> class is commonly used as a base class for more complex
610classes. In <tt>Target.td</tt>, the <tt>Register</tt> class is the base for the
611<tt>RegisterWithSubRegs</tt> class that is used to define registers that need to
612specify subregisters in the <tt>SubRegs</tt> list, as shown here:
613</p>
614
Chris Lattner78975382008-11-11 19:30:41 +0000615<div class="doc_code">
616<pre>
617class RegisterWithSubRegs&lt;string n,
618list&lt;Register&gt; subregs&gt; : Register&lt;n&gt; {
619 let SubRegs = subregs;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000620}
621</pre>
Chris Lattner78975382008-11-11 19:30:41 +0000622</div>
623
Bill Wendling4a2bca82009-04-05 00:41:19 +0000624<p>
625In <tt>SparcRegisterInfo.td</tt>, additional register classes are defined for
626SPARC: a Register subclass, SparcReg, and further subclasses: <tt>Ri</tt>,
627<tt>Rf</tt>, and <tt>Rd</tt>. SPARC registers are identified by 5-bit ID
628numbers, which is a feature common to these subclasses. Note the use of
629'<tt>let</tt>' expressions to override values that are initially defined in a
630superclass (such as <tt>SubRegs</tt> field in the <tt>Rd</tt> class).
631</p>
632
Chris Lattner78975382008-11-11 19:30:41 +0000633<div class="doc_code">
634<pre>
635class SparcReg&lt;string n&gt; : Register&lt;n&gt; {
636 field bits&lt;5&gt; Num;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000637 let Namespace = "SP";
Chris Lattner78975382008-11-11 19:30:41 +0000638}
639// Ri - 32-bit integer registers
640class Ri&lt;bits&lt;5&gt; num, string n&gt; :
641SparcReg&lt;n&gt; {
642 let Num = num;
643}
644// Rf - 32-bit floating-point registers
645class Rf&lt;bits&lt;5&gt; num, string n&gt; :
646SparcReg&lt;n&gt; {
647 let Num = num;
648}
649// Rd - Slots in the FP register file for 64-bit
650floating-point values.
651class Rd&lt;bits&lt;5&gt; num, string n,
652list&lt;Register&gt; subregs&gt; : SparcReg&lt;n&gt; {
653 let Num = num;
654 let SubRegs = subregs;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000655}
656</pre>
Chris Lattner78975382008-11-11 19:30:41 +0000657</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000658
659<p>
660In the <tt>SparcRegisterInfo.td</tt> file, there are register definitions that
661utilize these subclasses of <tt>Register</tt>, such as:
662</p>
663
Chris Lattner78975382008-11-11 19:30:41 +0000664<div class="doc_code">
665<pre>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000666def G0 : Ri&lt; 0, "G0"&gt;,
Chris Lattner78975382008-11-11 19:30:41 +0000667DwarfRegNum&lt;[0]&gt;;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000668def G1 : Ri&lt; 1, "G1"&gt;, DwarfRegNum&lt;[1]&gt;;
Chris Lattner78975382008-11-11 19:30:41 +0000669...
Bill Wendling4a2bca82009-04-05 00:41:19 +0000670def F0 : Rf&lt; 0, "F0"&gt;,
Chris Lattner78975382008-11-11 19:30:41 +0000671DwarfRegNum&lt;[32]&gt;;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000672def F1 : Rf&lt; 1, "F1"&gt;,
Chris Lattner78975382008-11-11 19:30:41 +0000673DwarfRegNum&lt;[33]&gt;;
674...
Bill Wendling4a2bca82009-04-05 00:41:19 +0000675def D0 : Rd&lt; 0, "F0", [F0, F1]&gt;,
Chris Lattner78975382008-11-11 19:30:41 +0000676DwarfRegNum&lt;[32]&gt;;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000677def D1 : Rd&lt; 2, "F2", [F2, F3]&gt;,
Chris Lattner78975382008-11-11 19:30:41 +0000678DwarfRegNum&lt;[34]&gt;;
679</pre>
680</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000681
682<p>
683The last two registers shown above (<tt>D0</tt> and <tt>D1</tt>) are
684double-precision floating-point registers that are aliases for pairs of
685single-precision floating-point sub-registers. In addition to aliases, the
686sub-register and super-register relationships of the defined register are in
687fields of a register's TargetRegisterDesc.
688</p>
689
Chris Lattner78975382008-11-11 19:30:41 +0000690</div>
691
692<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000693<h3>
Chris Lattner78975382008-11-11 19:30:41 +0000694 <a name="RegisterClassDef">Defining a Register Class</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000695</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000696
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000697<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000698
699<p>
700The <tt>RegisterClass</tt> class (specified in <tt>Target.td</tt>) is used to
Chris Lattner78975382008-11-11 19:30:41 +0000701define an object that represents a group of related registers and also defines
702the default allocation order of the registers. A target description file
Bill Wendling4a2bca82009-04-05 00:41:19 +0000703<tt>XXXRegisterInfo.td</tt> that uses <tt>Target.td</tt> can construct register
704classes using the following class:
705</p>
Chris Lattner78975382008-11-11 19:30:41 +0000706
707<div class="doc_code">
708<pre>
709class RegisterClass&lt;string namespace,
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000710list&lt;ValueType&gt; regTypes, int alignment, dag regList&gt; {
Chris Lattner78975382008-11-11 19:30:41 +0000711 string Namespace = namespace;
712 list&lt;ValueType&gt; RegTypes = regTypes;
713 int Size = 0; // spill size, in bits; zero lets tblgen pick the size
714 int Alignment = alignment;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000715
Chris Lattner78975382008-11-11 19:30:41 +0000716 // CopyCost is the cost of copying a value between two registers
717 // default value 1 means a single instruction
718 // A negative value means copying is extremely expensive or impossible
719 int CopyCost = 1;
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000720 dag MemberList = regList;
Chris Lattner78975382008-11-11 19:30:41 +0000721
722 // for register classes that are subregisters of this class
723 list&lt;RegisterClass&gt; SubRegClassList = [];
724
725 code MethodProtos = [{}]; // to insert arbitrary code
726 code MethodBodies = [{}];
Bill Wendling4a2bca82009-04-05 00:41:19 +0000727}
728</pre>
Chris Lattner78975382008-11-11 19:30:41 +0000729</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000730
Chris Lattner78975382008-11-11 19:30:41 +0000731<p>To define a RegisterClass, use the following 4 arguments:</p>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000732
Chris Lattner78975382008-11-11 19:30:41 +0000733<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000734<li>The first argument of the definition is the name of the namespace.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000735
Bill Wendling4a2bca82009-04-05 00:41:19 +0000736<li>The second argument is a list of <tt>ValueType</tt> register type values
737 that are defined in <tt>include/llvm/CodeGen/ValueTypes.td</tt>. Defined
738 values include integer types (such as <tt>i16</tt>, <tt>i32</tt>,
739 and <tt>i1</tt> for Boolean), floating-point types
740 (<tt>f32</tt>, <tt>f64</tt>), and vector types (for example, <tt>v8i16</tt>
741 for an <tt>8 x i16</tt> vector). All registers in a <tt>RegisterClass</tt>
742 must have the same <tt>ValueType</tt>, but some registers may store vector
743 data in different configurations. For example a register that can process a
744 128-bit vector may be able to handle 16 8-bit integer elements, 8 16-bit
745 integers, 4 32-bit integers, and so on. </li>
Chris Lattner78975382008-11-11 19:30:41 +0000746
Bill Wendling4a2bca82009-04-05 00:41:19 +0000747<li>The third argument of the <tt>RegisterClass</tt> definition specifies the
748 alignment required of the registers when they are stored or loaded to
749 memory.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000750
Bill Wendling4a2bca82009-04-05 00:41:19 +0000751<li>The final argument, <tt>regList</tt>, specifies which registers are in this
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000752 class. If an alternative allocation order method is not specified, then
753 <tt>regList</tt> also defines the order of allocation used by the register
754 allocator. Besides simply listing registers with <tt>(add R0, R1, ...)</tt>,
755 more advanced set operators are available. See
756 <tt>include/llvm/Target/Target.td</tt> for more information.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000757</ul>
758
Bill Wendling4a2bca82009-04-05 00:41:19 +0000759<p>
760In <tt>SparcRegisterInfo.td</tt>, three RegisterClass objects are defined:
761<tt>FPRegs</tt>, <tt>DFPRegs</tt>, and <tt>IntRegs</tt>. For all three register
762classes, the first argument defines the namespace with the string
763'<tt>SP</tt>'. <tt>FPRegs</tt> defines a group of 32 single-precision
764floating-point registers (<tt>F0</tt> to <tt>F31</tt>); <tt>DFPRegs</tt> defines
765a group of 16 double-precision registers
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000766(<tt>D0-D15</tt>).
Bill Wendling4a2bca82009-04-05 00:41:19 +0000767</p>
768
Chris Lattner78975382008-11-11 19:30:41 +0000769<div class="doc_code">
770<pre>
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000771// F0, F1, F2, ..., F31
772def FPRegs : RegisterClass&lt;"SP", [f32], 32, (sequence "F%u", 0, 31)&gt;;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000773
774def DFPRegs : RegisterClass&lt;"SP", [f64], 64,
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000775 (add D0, D1, D2, D3, D4, D5, D6, D7, D8,
776 D9, D10, D11, D12, D13, D14, D15)&gt;;
Chris Lattner78975382008-11-11 19:30:41 +0000777&nbsp;
Bill Wendling4a2bca82009-04-05 00:41:19 +0000778def IntRegs : RegisterClass&lt;"SP", [i32], 32,
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000779 (add L0, L1, L2, L3, L4, L5, L6, L7,
780 I0, I1, I2, I3, I4, I5,
781 O0, O1, O2, O3, O4, O5, O7,
782 G1,
783 // Non-allocatable regs:
784 G2, G3, G4,
785 O6, // stack ptr
786 I6, // frame ptr
787 I7, // return address
788 G0, // constant zero
789 G5, G6, G7 // reserved for kernel
790 )&gt;;
Chris Lattner78975382008-11-11 19:30:41 +0000791</pre>
792</div>
793
Bill Wendling4a2bca82009-04-05 00:41:19 +0000794<p>
795Using <tt>SparcRegisterInfo.td</tt> with TableGen generates several output files
796that are intended for inclusion in other source code that you write.
797<tt>SparcRegisterInfo.td</tt> generates <tt>SparcGenRegisterInfo.h.inc</tt>,
798which should be included in the header file for the implementation of the SPARC
799register implementation that you write (<tt>SparcRegisterInfo.h</tt>). In
Chris Lattner78975382008-11-11 19:30:41 +0000800<tt>SparcGenRegisterInfo.h.inc</tt> a new structure is defined called
Bill Wendling4a2bca82009-04-05 00:41:19 +0000801<tt>SparcGenRegisterInfo</tt> that uses <tt>TargetRegisterInfo</tt> as its
802base. It also specifies types, based upon the defined register
803classes: <tt>DFPRegsClass</tt>, <tt>FPRegsClass</tt>, and <tt>IntRegsClass</tt>.
804</p>
Chris Lattner78975382008-11-11 19:30:41 +0000805
Bill Wendling4a2bca82009-04-05 00:41:19 +0000806<p>
807<tt>SparcRegisterInfo.td</tt> also generates <tt>SparcGenRegisterInfo.inc</tt>,
808which is included at the bottom of <tt>SparcRegisterInfo.cpp</tt>, the SPARC
809register implementation. The code below shows only the generated integer
810registers and associated register classes. The order of registers
811in <tt>IntRegs</tt> reflects the order in the definition of <tt>IntRegs</tt> in
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000812the target description file.
Bill Wendling4a2bca82009-04-05 00:41:19 +0000813</p>
Chris Lattner78975382008-11-11 19:30:41 +0000814
815<div class="doc_code">
816<pre> // IntRegs Register Class...
817 static const unsigned IntRegs[] = {
818 SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5,
Bill Wendling4a2bca82009-04-05 00:41:19 +0000819 SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3,
820 SP::I4, SP::I5, SP::O0, SP::O1, SP::O2, SP::O3,
821 SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3,
822 SP::G4, SP::O6, SP::I6, SP::I7, SP::G0, SP::G5,
823 SP::G6, SP::G7,
Chris Lattner78975382008-11-11 19:30:41 +0000824 };
Bill Wendling4a2bca82009-04-05 00:41:19 +0000825
Chris Lattner78975382008-11-11 19:30:41 +0000826 // IntRegsVTs Register Class Value Types...
827 static const MVT::ValueType IntRegsVTs[] = {
828 MVT::i32, MVT::Other
829 };
Bill Wendling4a2bca82009-04-05 00:41:19 +0000830
Chris Lattner78975382008-11-11 19:30:41 +0000831namespace SP { // Register class instances
832 DFPRegsClass&nbsp;&nbsp;&nbsp; DFPRegsRegClass;
833 FPRegsClass&nbsp;&nbsp;&nbsp;&nbsp; FPRegsRegClass;
834 IntRegsClass&nbsp;&nbsp;&nbsp; IntRegsRegClass;
835...
Bill Wendling4a2bca82009-04-05 00:41:19 +0000836 // IntRegs Sub-register Classess...
Chris Lattner78975382008-11-11 19:30:41 +0000837 static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
838 NULL
839 };
840...
Bill Wendling4a2bca82009-04-05 00:41:19 +0000841 // IntRegs Super-register Classess...
Chris Lattner78975382008-11-11 19:30:41 +0000842 static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
843 NULL
844 };
Bill Wendling4a2bca82009-04-05 00:41:19 +0000845...
846 // IntRegs Register Class sub-classes...
Chris Lattner78975382008-11-11 19:30:41 +0000847 static const TargetRegisterClass* const IntRegsSubclasses [] = {
848 NULL
849 };
850...
Bill Wendling4a2bca82009-04-05 00:41:19 +0000851 // IntRegs Register Class super-classes...
Chris Lattner78975382008-11-11 19:30:41 +0000852 static const TargetRegisterClass* const IntRegsSuperclasses [] = {
853 NULL
854 };
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000855
Bill Wendling4a2bca82009-04-05 00:41:19 +0000856 IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID,
857 IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses,
858 IntRegsSuperRegClasses, 4, 4, 1, IntRegs, IntRegs + 32) {}
Chris Lattner78975382008-11-11 19:30:41 +0000859}
860</pre>
861</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000862
Jakob Stoklund Olesenf28987b2011-06-15 23:28:14 +0000863<p>
864The register allocators will avoid using reserved registers, and callee saved
865registers are not used until all the volatile registers have been used. That
866is usually good enough, but in some cases it may be necessary to provide custom
867allocation orders.
868</p>
869
Bill Wendling4a2bca82009-04-05 00:41:19 +0000870</div>
871
Chris Lattner78975382008-11-11 19:30:41 +0000872<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000873<h3>
Chris Lattner7d12b4b2008-11-11 19:36:31 +0000874 <a name="implementRegister">Implement a subclass of</a>
NAKAMURA Takumi31c18062011-04-09 02:13:48 +0000875 <a href="CodeGenerator.html#targetregisterinfo">TargetRegisterInfo</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000876</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000877
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000878<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000879
880<p>
881The final step is to hand code portions of <tt>XXXRegisterInfo</tt>, which
882implements the interface described in <tt>TargetRegisterInfo.h</tt>. These
883functions return <tt>0</tt>, <tt>NULL</tt>, or <tt>false</tt>, unless
884overridden. Here is a list of functions that are overridden for the SPARC
885implementation in <tt>SparcRegisterInfo.cpp</tt>:
886</p>
887
Chris Lattner78975382008-11-11 19:30:41 +0000888<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000889<li><tt>getCalleeSavedRegs</tt> &mdash; Returns a list of callee-saved registers
890 in the order of the desired callee-save stack frame offset.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000891
Bill Wendling4a2bca82009-04-05 00:41:19 +0000892<li><tt>getReservedRegs</tt> &mdash; Returns a bitset indexed by physical
893 register numbers, indicating if a particular register is unavailable.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000894
Bill Wendling4a2bca82009-04-05 00:41:19 +0000895<li><tt>hasFP</tt> &mdash; Return a Boolean indicating if a function should have
896 a dedicated frame pointer register.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000897
Bill Wendling4a2bca82009-04-05 00:41:19 +0000898<li><tt>eliminateCallFramePseudoInstr</tt> &mdash; If call frame setup or
899 destroy pseudo instructions are used, this can be called to eliminate
900 them.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000901
Bill Wendling4a2bca82009-04-05 00:41:19 +0000902<li><tt>eliminateFrameIndex</tt> &mdash; Eliminate abstract frame indices from
903 instructions that may use them.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000904
Bill Wendling4a2bca82009-04-05 00:41:19 +0000905<li><tt>emitPrologue</tt> &mdash; Insert prologue code into the function.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000906
Bill Wendling4a2bca82009-04-05 00:41:19 +0000907<li><tt>emitEpilogue</tt> &mdash; Insert epilogue code into the function.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000908</ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000909
Chris Lattner78975382008-11-11 19:30:41 +0000910</div>
911
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000912</div>
913
Chris Lattner78975382008-11-11 19:30:41 +0000914<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000915<h2>
Chris Lattner78975382008-11-11 19:30:41 +0000916 <a name="InstructionSet">Instruction Set</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +0000917</h2>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000918
Chris Lattner78975382008-11-11 19:30:41 +0000919<!-- *********************************************************************** -->
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +0000920<div>
Chris Lattner78975382008-11-11 19:30:41 +0000921
Bill Wendling4a2bca82009-04-05 00:41:19 +0000922<p>
923During the early stages of code generation, the LLVM IR code is converted to a
924<tt>SelectionDAG</tt> with nodes that are instances of the <tt>SDNode</tt> class
925containing target instructions. An <tt>SDNode</tt> has an opcode, operands, type
926requirements, and operation properties. For example, is an operation
927commutative, does an operation load from memory. The various operation node
928types are described in the <tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>
929file (values of the <tt>NodeType</tt> enum in the <tt>ISD</tt> namespace).
930</p>
931
932<p>
933TableGen uses the following target description (<tt>.td</tt>) input files to
934generate much of the code for instruction definition:
935</p>
936
Chris Lattner78975382008-11-11 19:30:41 +0000937<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +0000938<li><tt>Target.td</tt> &mdash; Where the <tt>Instruction</tt>, <tt>Operand</tt>,
939 <tt>InstrInfo</tt>, and other fundamental classes are defined.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000940
Bill Wendling4a2bca82009-04-05 00:41:19 +0000941<li><tt>TargetSelectionDAG.td</tt>&mdash; Used by <tt>SelectionDAG</tt>
942 instruction selection generators, contains <tt>SDTC*</tt> classes (selection
943 DAG type constraint), definitions of <tt>SelectionDAG</tt> nodes (such as
944 <tt>imm</tt>, <tt>cond</tt>, <tt>bb</tt>, <tt>add</tt>, <tt>fadd</tt>,
945 <tt>sub</tt>), and pattern support (<tt>Pattern</tt>, <tt>Pat</tt>,
946 <tt>PatFrag</tt>, <tt>PatLeaf</tt>, <tt>ComplexPattern</tt>.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000947
Bill Wendling4a2bca82009-04-05 00:41:19 +0000948<li><tt>XXXInstrFormats.td</tt> &mdash; Patterns for definitions of
949 target-specific instructions.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000950
Bill Wendling4a2bca82009-04-05 00:41:19 +0000951<li><tt>XXXInstrInfo.td</tt> &mdash; Target-specific definitions of instruction
952 templates, condition codes, and instructions of an instruction set. For
953 architecture modifications, a different file name may be used. For example,
954 for Pentium with SSE instruction, this file is <tt>X86InstrSSE.td</tt>, and
955 for Pentium with MMX, this file is <tt>X86InstrMMX.td</tt>.</li>
Chris Lattner78975382008-11-11 19:30:41 +0000956</ul>
957
Bill Wendling4a2bca82009-04-05 00:41:19 +0000958<p>
959There is also a target-specific <tt>XXX.td</tt> file, where <tt>XXX</tt> is the
960name of the target. The <tt>XXX.td</tt> file includes the other <tt>.td</tt>
961input files, but its contents are only directly important for subtargets.
962</p>
963
964<p>
965You should describe a concrete target-specific class <tt>XXXInstrInfo</tt> that
966represents machine instructions supported by a target machine.
967<tt>XXXInstrInfo</tt> contains an array of <tt>XXXInstrDescriptor</tt> objects,
968each of which describes one instruction. An instruction descriptor defines:</p>
969
970<ul>
971<li>Opcode mnemonic</li>
972
973<li>Number of operands</li>
974
975<li>List of implicit register definitions and uses</li>
976
977<li>Target-independent properties (such as memory access, is commutable)</li>
978
979<li>Target-specific flags </li>
980</ul>
981
982<p>
983The Instruction class (defined in <tt>Target.td</tt>) is mostly used as a base
984for more complex instruction classes.
985</p>
Chris Lattner78975382008-11-11 19:30:41 +0000986
987<div class="doc_code">
988<pre>class Instruction {
Bill Wendling4a2bca82009-04-05 00:41:19 +0000989 string Namespace = "";
Chris Lattner78975382008-11-11 19:30:41 +0000990 dag OutOperandList; // An dag containing the MI def operand list.
991 dag InOperandList; // An dag containing the MI use operand list.
Bill Wendling4a2bca82009-04-05 00:41:19 +0000992 string AsmString = ""; // The .s format to print the instruction with.
Chris Lattner78975382008-11-11 19:30:41 +0000993 list&lt;dag&gt; Pattern; // Set to the DAG pattern for this instruction
994 list&lt;Register&gt; Uses = [];
995 list&lt;Register&gt; Defs = [];
996 list&lt;Predicate&gt; Predicates = []; // predicates turned into isel match code
997 ... remainder not shown for space ...
998}
999</pre>
1000</div>
Chris Lattner78975382008-11-11 19:30:41 +00001001
Bill Wendling4a2bca82009-04-05 00:41:19 +00001002<p>
1003A <tt>SelectionDAG</tt> node (<tt>SDNode</tt>) should contain an object
1004representing a target-specific instruction that is defined
1005in <tt>XXXInstrInfo.td</tt>. The instruction objects should represent
1006instructions from the architecture manual of the target machine (such as the
1007SPARC Architecture Manual for the SPARC target).
1008</p>
1009
1010<p>
1011A single instruction from the architecture manual is often modeled as multiple
1012target instructions, depending upon its operands. For example, a manual might
Chris Lattner78975382008-11-11 19:30:41 +00001013describe an add instruction that takes a register or an immediate operand. An
Bill Wendling4a2bca82009-04-05 00:41:19 +00001014LLVM target could model this with two instructions named <tt>ADDri</tt> and
1015<tt>ADDrr</tt>.
1016</p>
Chris Lattner78975382008-11-11 19:30:41 +00001017
Bill Wendling4a2bca82009-04-05 00:41:19 +00001018<p>
1019You should define a class for each instruction category and define each opcode
1020as a subclass of the category with appropriate parameters such as the fixed
1021binary encoding of opcodes and extended opcodes. You should map the register
1022bits to the bits of the instruction in which they are encoded (for the
1023JIT). Also you should specify how the instruction should be printed when the
1024automatic assembly printer is used.
1025</p>
Chris Lattner78975382008-11-11 19:30:41 +00001026
Bill Wendling4a2bca82009-04-05 00:41:19 +00001027<p>
1028As is described in the SPARC Architecture Manual, Version 8, there are three
1029major 32-bit formats for instructions. Format 1 is only for the <tt>CALL</tt>
1030instruction. Format 2 is for branch on condition codes and <tt>SETHI</tt> (set
1031high bits of a register) instructions. Format 3 is for other instructions.
1032</p>
Chris Lattner78975382008-11-11 19:30:41 +00001033
Bill Wendling4a2bca82009-04-05 00:41:19 +00001034<p>
1035Each of these formats has corresponding classes in <tt>SparcInstrFormat.td</tt>.
1036<tt>InstSP</tt> is a base class for other instruction classes. Additional base
1037classes are specified for more precise formats: for example
1038in <tt>SparcInstrFormat.td</tt>, <tt>F2_1</tt> is for <tt>SETHI</tt>,
1039and <tt>F2_2</tt> is for branches. There are three other base
1040classes: <tt>F3_1</tt> for register/register operations, <tt>F3_2</tt> for
1041register/immediate operations, and <tt>F3_3</tt> for floating-point
1042operations. <tt>SparcInstrInfo.td</tt> also adds the base class Pseudo for
1043synthetic SPARC instructions.
1044</p>
Chris Lattner78975382008-11-11 19:30:41 +00001045
Bill Wendling4a2bca82009-04-05 00:41:19 +00001046<p>
1047<tt>SparcInstrInfo.td</tt> largely consists of operand and instruction
1048definitions for the SPARC target. In <tt>SparcInstrInfo.td</tt>, the following
1049target description file entry, <tt>LDrr</tt>, defines the Load Integer
1050instruction for a Word (the <tt>LD</tt> SPARC opcode) from a memory address to a
1051register. The first parameter, the value 3 (<tt>11<sub>2</sub></tt>), is the
1052operation value for this category of operation. The second parameter
1053(<tt>000000<sub>2</sub></tt>) is the specific operation value
1054for <tt>LD</tt>/Load Word. The third parameter is the output destination, which
1055is a register operand and defined in the <tt>Register</tt> target description
1056file (<tt>IntRegs</tt>).
1057</p>
1058
Chris Lattner78975382008-11-11 19:30:41 +00001059<div class="doc_code">
1060<pre>def LDrr : F3_1 &lt;3, 0b000000, (outs IntRegs:$dst), (ins MEMrr:$addr),
Bill Wendling4a2bca82009-04-05 00:41:19 +00001061 "ld [$addr], $dst",
Chris Lattner78975382008-11-11 19:30:41 +00001062 [(set IntRegs:$dst, (load ADDRrr:$addr))]&gt;;
1063</pre>
1064</div>
1065
Bill Wendling4a2bca82009-04-05 00:41:19 +00001066<p>
1067The fourth parameter is the input source, which uses the address
1068operand <tt>MEMrr</tt> that is defined earlier in <tt>SparcInstrInfo.td</tt>:
1069</p>
1070
Chris Lattner78975382008-11-11 19:30:41 +00001071<div class="doc_code">
1072<pre>def MEMrr : Operand&lt;i32&gt; {
Bill Wendling4a2bca82009-04-05 00:41:19 +00001073 let PrintMethod = "printMemOperand";
Chris Lattner78975382008-11-11 19:30:41 +00001074 let MIOperandInfo = (ops IntRegs, IntRegs);
1075}
1076</pre>
1077</div>
Chris Lattner78975382008-11-11 19:30:41 +00001078
Bill Wendling4a2bca82009-04-05 00:41:19 +00001079<p>
1080The fifth parameter is a string that is used by the assembly printer and can be
1081left as an empty string until the assembly printer interface is implemented. The
1082sixth and final parameter is the pattern used to match the instruction during
1083the SelectionDAG Select Phase described in
NAKAMURA Takumi31c18062011-04-09 02:13:48 +00001084(<a href="CodeGenerator.html">The LLVM
Bill Wendling4a2bca82009-04-05 00:41:19 +00001085Target-Independent Code Generator</a>). This parameter is detailed in the next
1086section, <a href="#InstructionSelector">Instruction Selector</a>.
1087</p>
1088
1089<p>
1090Instruction class definitions are not overloaded for different operand types, so
1091separate versions of instructions are needed for register, memory, or immediate
1092value operands. For example, to perform a Load Integer instruction for a Word
Chris Lattner78975382008-11-11 19:30:41 +00001093from an immediate operand to a register, the following instruction class is
Bill Wendling4a2bca82009-04-05 00:41:19 +00001094defined:
1095</p>
1096
Chris Lattner78975382008-11-11 19:30:41 +00001097<div class="doc_code">
1098<pre>def LDri : F3_2 &lt;3, 0b000000, (outs IntRegs:$dst), (ins MEMri:$addr),
Bill Wendling4a2bca82009-04-05 00:41:19 +00001099 "ld [$addr], $dst",
Chris Lattner78975382008-11-11 19:30:41 +00001100 [(set IntRegs:$dst, (load ADDRri:$addr))]&gt;;
1101</pre>
1102</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001103
1104<p>
1105Writing these definitions for so many similar instructions can involve a lot of
1106cut and paste. In td files, the <tt>multiclass</tt> directive enables the
1107creation of templates to define several instruction classes at once (using
1108the <tt>defm</tt> directive). For example in <tt>SparcInstrInfo.td</tt>, the
1109<tt>multiclass</tt> pattern <tt>F3_12</tt> is defined to create 2 instruction
1110classes each time <tt>F3_12</tt> is invoked:
1111</p>
1112
Chris Lattner78975382008-11-11 19:30:41 +00001113<div class="doc_code">
1114<pre>multiclass F3_12 &lt;string OpcStr, bits&lt;6&gt; Op3Val, SDNode OpNode&gt; {
1115 def rr : F3_1 &lt;2, Op3Val,
1116 (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
Bill Wendling4a2bca82009-04-05 00:41:19 +00001117 !strconcat(OpcStr, " $b, $c, $dst"),
Chris Lattner78975382008-11-11 19:30:41 +00001118 [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]&gt;;
1119 def ri : F3_2 &lt;2, Op3Val,
1120 (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
Bill Wendling4a2bca82009-04-05 00:41:19 +00001121 !strconcat(OpcStr, " $b, $c, $dst"),
Chris Lattner78975382008-11-11 19:30:41 +00001122 [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]&gt;;
1123}
1124</pre>
1125</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001126
1127<p>
1128So when the <tt>defm</tt> directive is used for the <tt>XOR</tt>
1129and <tt>ADD</tt> instructions, as seen below, it creates four instruction
1130objects: <tt>XORrr</tt>, <tt>XORri</tt>, <tt>ADDrr</tt>, and <tt>ADDri</tt>.
1131</p>
1132
Chris Lattner78975382008-11-11 19:30:41 +00001133<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001134<pre>
1135defm XOR : F3_12&lt;"xor", 0b000011, xor&gt;;
1136defm ADD : F3_12&lt;"add", 0b000000, add&gt;;
Chris Lattner78975382008-11-11 19:30:41 +00001137</pre>
1138</div>
1139
Bill Wendling4a2bca82009-04-05 00:41:19 +00001140<p>
1141<tt>SparcInstrInfo.td</tt> also includes definitions for condition codes that
1142are referenced by branch instructions. The following definitions
1143in <tt>SparcInstrInfo.td</tt> indicate the bit location of the SPARC condition
1144code. For example, the 10<sup>th</sup> bit represents the 'greater than'
1145condition for integers, and the 22<sup>nd</sup> bit represents the 'greater
1146than' condition for floats.
1147</p>
Chris Lattner78975382008-11-11 19:30:41 +00001148
1149<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001150<pre>
1151def ICC_NE : ICC_VAL&lt; 9&gt;; // Not Equal
Chris Lattner78975382008-11-11 19:30:41 +00001152def ICC_E : ICC_VAL&lt; 1&gt;; // Equal
1153def ICC_G : ICC_VAL&lt;10&gt;; // Greater
1154...
1155def FCC_U : FCC_VAL&lt;23&gt;; // Unordered
1156def FCC_G : FCC_VAL&lt;22&gt;; // Greater
1157def FCC_UG : FCC_VAL&lt;21&gt;; // Unordered or Greater
1158...
1159</pre>
1160</div>
1161
Bill Wendling4a2bca82009-04-05 00:41:19 +00001162<p>
1163(Note that <tt>Sparc.h</tt> also defines enums that correspond to the same SPARC
1164condition codes. Care must be taken to ensure the values in <tt>Sparc.h</tt>
1165correspond to the values in <tt>SparcInstrInfo.td</tt>. I.e.,
1166<tt>SPCC::ICC_NE = 9</tt>, <tt>SPCC::FCC_U = 23</tt> and so on.)
1167</p>
1168
Chris Lattner78975382008-11-11 19:30:41 +00001169<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001170<h3>
Chris Lattner7a152732008-11-22 19:10:48 +00001171 <a name="operandMapping">Instruction Operand Mapping</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001172</h3>
Chris Lattner7a152732008-11-22 19:10:48 +00001173
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001174<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001175
1176<p>
1177The code generator backend maps instruction operands to fields in the
1178instruction. Operands are assigned to unbound fields in the instruction in the
1179order they are defined. Fields are bound when they are assigned a value. For
1180example, the Sparc target defines the <tt>XNORrr</tt> instruction as
1181a <tt>F3_1</tt> format instruction having three operands.
1182</p>
1183
1184<div class="doc_code">
1185<pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001186def XNORrr : F3_1&lt;2, 0b000111,
1187 (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
1188 "xnor $b, $c, $dst",
1189 [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]&gt;;
Bill Wendling4a2bca82009-04-05 00:41:19 +00001190</pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001191</div>
1192
Bill Wendling4a2bca82009-04-05 00:41:19 +00001193<p>
1194The instruction templates in <tt>SparcInstrFormats.td</tt> show the base class
1195for <tt>F3_1</tt> is <tt>InstSP</tt>.
1196</p>
1197
1198<div class="doc_code">
1199<pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001200class InstSP&lt;dag outs, dag ins, string asmstr, list&lt;dag&gt; pattern&gt; : Instruction {
1201 field bits&lt;32&gt; Inst;
1202 let Namespace = "SP";
1203 bits&lt;2&gt; op;
1204 let Inst{31-30} = op;
1205 dag OutOperandList = outs;
1206 dag InOperandList = ins;
1207 let AsmString = asmstr;
1208 let Pattern = pattern;
1209}
Bill Wendling4a2bca82009-04-05 00:41:19 +00001210</pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001211</div>
1212
Bill Wendling4a2bca82009-04-05 00:41:19 +00001213<p><tt>InstSP</tt> leaves the <tt>op</tt> field unbound.</p>
1214
1215<div class="doc_code">
1216<pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001217class F3&lt;dag outs, dag ins, string asmstr, list&lt;dag&gt; pattern&gt;
1218 : InstSP&lt;outs, ins, asmstr, pattern&gt; {
1219 bits&lt;5&gt; rd;
1220 bits&lt;6&gt; op3;
1221 bits&lt;5&gt; rs1;
1222 let op{1} = 1; // Op = 2 or 3
1223 let Inst{29-25} = rd;
1224 let Inst{24-19} = op3;
1225 let Inst{18-14} = rs1;
1226}
Bill Wendling4a2bca82009-04-05 00:41:19 +00001227</pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001228</div>
1229
Bill Wendling4a2bca82009-04-05 00:41:19 +00001230<p>
1231<tt>F3</tt> binds the <tt>op</tt> field and defines the <tt>rd</tt>,
1232<tt>op3</tt>, and <tt>rs1</tt> fields. <tt>F3</tt> format instructions will
1233bind the operands <tt>rd</tt>, <tt>op3</tt>, and <tt>rs1</tt> fields.
1234</p>
1235
1236<div class="doc_code">
1237<pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001238class F3_1&lt;bits&lt;2&gt; opVal, bits&lt;6&gt; op3val, dag outs, dag ins,
1239 string asmstr, list&lt;dag&gt; pattern&gt; : F3&lt;outs, ins, asmstr, pattern&gt; {
1240 bits&lt;8&gt; asi = 0; // asi not currently used
1241 bits&lt;5&gt; rs2;
1242 let op = opVal;
1243 let op3 = op3val;
1244 let Inst{13} = 0; // i field = 0
1245 let Inst{12-5} = asi; // address space identifier
1246 let Inst{4-0} = rs2;
1247}
Bill Wendling4a2bca82009-04-05 00:41:19 +00001248</pre>
Chris Lattner7a152732008-11-22 19:10:48 +00001249</div>
1250
Bill Wendling4a2bca82009-04-05 00:41:19 +00001251<p>
1252<tt>F3_1</tt> binds the <tt>op3</tt> field and defines the <tt>rs2</tt>
1253fields. <tt>F3_1</tt> format instructions will bind the operands to the <tt>rd</tt>,
1254<tt>rs1</tt>, and <tt>rs2</tt> fields. This results in the <tt>XNORrr</tt>
1255instruction binding <tt>$dst</tt>, <tt>$b</tt>, and <tt>$c</tt> operands to
1256the <tt>rd</tt>, <tt>rs1</tt>, and <tt>rs2</tt> fields respectively.
1257</p>
Chris Lattner7a152732008-11-22 19:10:48 +00001258
Bill Wendling4a2bca82009-04-05 00:41:19 +00001259</div>
Chris Lattner7a152732008-11-22 19:10:48 +00001260
1261<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001262<h3>
Sebastian Popbecdf4d2012-10-25 15:54:06 +00001263 <a name="relationMapping">Instruction Relation Mapping</a>
1264</h3>
1265
1266<div>
1267
1268<p>
1269This TableGen feature is used to relate instructions with each other. It is
1270particularly useful when you have multiple instruction formats and need to
1271switch between them after instruction selection. This entire feature is driven
1272by relation models which can be defined in <tt>XXXInstrInfo.td</tt> files
1273according to the target-specific instruction set. Relation models are defined
1274using <tt>InstrMapping</tt> class as a base. TableGen parses all the models
1275and generates instruction relation maps using the specified information.
1276Relation maps are emitted as tables in the <tt>XXXGenInstrInfo.inc</tt> file
1277along with the functions to query them. For the detailed information on how to
1278use this feature, please refer to
1279<a href="HowToUseInstrMappings.html">How to add Instruction Mappings</a>
1280document.
1281</p>
1282</div>
1283
1284<!-- ======================================================================= -->
1285<h3>
Chris Lattner7d12b4b2008-11-11 19:36:31 +00001286 <a name="implementInstr">Implement a subclass of </a>
NAKAMURA Takumi31c18062011-04-09 02:13:48 +00001287 <a href="CodeGenerator.html#targetinstrinfo">TargetInstrInfo</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001288</h3>
Chris Lattner78975382008-11-11 19:30:41 +00001289
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001290<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001291
1292<p>
1293The final step is to hand code portions of <tt>XXXInstrInfo</tt>, which
1294implements the interface described in <tt>TargetInstrInfo.h</tt>. These
1295functions return <tt>0</tt> or a Boolean or they assert, unless
1296overridden. Here's a list of functions that are overridden for the SPARC
1297implementation in <tt>SparcInstrInfo.cpp</tt>:
1298</p>
1299
Chris Lattner78975382008-11-11 19:30:41 +00001300<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001301<li><tt>isLoadFromStackSlot</tt> &mdash; If the specified machine instruction is
1302 a direct load from a stack slot, return the register number of the
1303 destination and the <tt>FrameIndex</tt> of the stack slot.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001304
Bill Wendling4a2bca82009-04-05 00:41:19 +00001305<li><tt>isStoreToStackSlot</tt> &mdash; If the specified machine instruction is
1306 a direct store to a stack slot, return the register number of the
1307 destination and the <tt>FrameIndex</tt> of the stack slot.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001308
Jakob Stoklund Olesen744b3a52010-07-11 17:01:17 +00001309<li><tt>copyPhysReg</tt> &mdash; Copy values between a pair of physical
1310 registers.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001311
Bill Wendling4a2bca82009-04-05 00:41:19 +00001312<li><tt>storeRegToStackSlot</tt> &mdash; Store a register value to a stack
1313 slot.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001314
Bill Wendling4a2bca82009-04-05 00:41:19 +00001315<li><tt>loadRegFromStackSlot</tt> &mdash; Load a register value from a stack
1316 slot.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001317
Bill Wendling4a2bca82009-04-05 00:41:19 +00001318<li><tt>storeRegToAddr</tt> &mdash; Store a register value to memory.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001319
Bill Wendling4a2bca82009-04-05 00:41:19 +00001320<li><tt>loadRegFromAddr</tt> &mdash; Load a register value from memory.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001321
Bill Wendling4a2bca82009-04-05 00:41:19 +00001322<li><tt>foldMemoryOperand</tt> &mdash; Attempt to combine instructions of any
1323 load or store instruction for the specified operand(s).</li>
Chris Lattner78975382008-11-11 19:30:41 +00001324</ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001325
Chris Lattner78975382008-11-11 19:30:41 +00001326</div>
1327
1328<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001329<h3>
Chris Lattner78975382008-11-11 19:30:41 +00001330 <a name="branchFolding">Branch Folding and If Conversion</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001331</h3>
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001332<div>
Chris Lattner78975382008-11-11 19:30:41 +00001333
Bill Wendling4a2bca82009-04-05 00:41:19 +00001334<p>
1335Performance can be improved by combining instructions or by eliminating
1336instructions that are never reached. The <tt>AnalyzeBranch</tt> method
1337in <tt>XXXInstrInfo</tt> may be implemented to examine conditional instructions
1338and remove unnecessary instructions. <tt>AnalyzeBranch</tt> looks at the end of
1339a machine basic block (MBB) for opportunities for improvement, such as branch
1340folding and if conversion. The <tt>BranchFolder</tt> and <tt>IfConverter</tt>
1341machine function passes (see the source files <tt>BranchFolding.cpp</tt> and
1342<tt>IfConversion.cpp</tt> in the <tt>lib/CodeGen</tt> directory) call
1343<tt>AnalyzeBranch</tt> to improve the control flow graph that represents the
1344instructions.
1345</p>
1346
1347<p>
1348Several implementations of <tt>AnalyzeBranch</tt> (for ARM, Alpha, and X86) can
1349be examined as models for your own <tt>AnalyzeBranch</tt> implementation. Since
1350SPARC does not implement a useful <tt>AnalyzeBranch</tt>, the ARM target
1351implementation is shown below.
1352</p>
Chris Lattner78975382008-11-11 19:30:41 +00001353
1354<p><tt>AnalyzeBranch</tt> returns a Boolean value and takes four parameters:</p>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001355
Chris Lattner78975382008-11-11 19:30:41 +00001356<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001357<li><tt>MachineBasicBlock &amp;MBB</tt> &mdash; The incoming block to be
1358 examined.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001359
Bill Wendling4a2bca82009-04-05 00:41:19 +00001360<li><tt>MachineBasicBlock *&amp;TBB</tt> &mdash; A destination block that is
1361 returned. For a conditional branch that evaluates to true, <tt>TBB</tt> is
1362 the destination.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001363
Bill Wendling4a2bca82009-04-05 00:41:19 +00001364<li><tt>MachineBasicBlock *&amp;FBB</tt> &mdash; For a conditional branch that
1365 evaluates to false, <tt>FBB</tt> is returned as the destination.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001366
Bill Wendling4a2bca82009-04-05 00:41:19 +00001367<li><tt>std::vector&lt;MachineOperand&gt; &amp;Cond</tt> &mdash; List of
1368 operands to evaluate a condition for a conditional branch.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001369</ul>
1370
Bill Wendling4a2bca82009-04-05 00:41:19 +00001371<p>
1372In the simplest case, if a block ends without a branch, then it falls through to
1373the successor block. No destination blocks are specified for either <tt>TBB</tt>
1374or <tt>FBB</tt>, so both parameters return <tt>NULL</tt>. The start of
1375the <tt>AnalyzeBranch</tt> (see code below for the ARM target) shows the
1376function parameters and the code for the simplest case.
1377</p>
Chris Lattner78975382008-11-11 19:30:41 +00001378
1379<div class="doc_code">
1380<pre>bool ARMInstrInfo::AnalyzeBranch(MachineBasicBlock &amp;MBB,
1381 MachineBasicBlock *&amp;TBB, MachineBasicBlock *&amp;FBB,
1382 std::vector&lt;MachineOperand&gt; &amp;Cond) const
1383{
1384 MachineBasicBlock::iterator I = MBB.end();
1385 if (I == MBB.begin() || !isUnpredicatedTerminator(--I))
1386 return false;
1387</pre>
1388</div>
1389
Bill Wendling4a2bca82009-04-05 00:41:19 +00001390<p>
1391If a block ends with a single unconditional branch instruction, then
1392<tt>AnalyzeBranch</tt> (shown below) should return the destination of that
1393branch in the <tt>TBB</tt> parameter.
1394</p>
Chris Lattner78975382008-11-11 19:30:41 +00001395
1396<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001397<pre>
1398 if (LastOpc == ARM::B || LastOpc == ARM::tB) {
1399 TBB = LastInst-&gt;getOperand(0).getMBB();
1400 return false;
1401 }
Chris Lattner78975382008-11-11 19:30:41 +00001402</pre>
1403</div>
1404
Bill Wendling4a2bca82009-04-05 00:41:19 +00001405<p>
1406If a block ends with two unconditional branches, then the second branch is never
1407reached. In that situation, as shown below, remove the last branch instruction
1408and return the penultimate branch in the <tt>TBB</tt> parameter.
1409</p>
Chris Lattner78975382008-11-11 19:30:41 +00001410
1411<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001412<pre>
1413 if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) &amp;&amp;
Chris Lattner78975382008-11-11 19:30:41 +00001414 (LastOpc == ARM::B || LastOpc == ARM::tB)) {
1415 TBB = SecondLastInst-&gt;getOperand(0).getMBB();
1416 I = LastInst;
1417 I-&gt;eraseFromParent();
1418 return false;
1419 }
1420</pre>
1421</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001422
1423<p>
1424A block may end with a single conditional branch instruction that falls through
1425to successor block if the condition evaluates to false. In that case,
1426<tt>AnalyzeBranch</tt> (shown below) should return the destination of that
1427conditional branch in the <tt>TBB</tt> parameter and a list of operands in
1428the <tt>Cond</tt> parameter to evaluate the condition.
1429</p>
Chris Lattner78975382008-11-11 19:30:41 +00001430
1431<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001432<pre>
1433 if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) {
1434 // Block ends with fall-through condbranch.
1435 TBB = LastInst-&gt;getOperand(0).getMBB();
1436 Cond.push_back(LastInst-&gt;getOperand(1));
1437 Cond.push_back(LastInst-&gt;getOperand(2));
1438 return false;
1439 }
Chris Lattner78975382008-11-11 19:30:41 +00001440</pre>
1441</div>
1442
Bill Wendling4a2bca82009-04-05 00:41:19 +00001443<p>
1444If a block ends with both a conditional branch and an ensuing unconditional
1445branch, then <tt>AnalyzeBranch</tt> (shown below) should return the conditional
1446branch destination (assuming it corresponds to a conditional evaluation of
1447'<tt>true</tt>') in the <tt>TBB</tt> parameter and the unconditional branch
1448destination in the <tt>FBB</tt> (corresponding to a conditional evaluation of
1449'<tt>false</tt>'). A list of operands to evaluate the condition should be
1450returned in the <tt>Cond</tt> parameter.
1451</p>
Chris Lattner78975382008-11-11 19:30:41 +00001452
1453<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001454<pre>
1455 unsigned SecondLastOpc = SecondLastInst-&gt;getOpcode();
1456
Chris Lattner78975382008-11-11 19:30:41 +00001457 if ((SecondLastOpc == ARM::Bcc &amp;&amp; LastOpc == ARM::B) ||
1458 (SecondLastOpc == ARM::tBcc &amp;&amp; LastOpc == ARM::tB)) {
1459 TBB = SecondLastInst-&gt;getOperand(0).getMBB();
1460 Cond.push_back(SecondLastInst-&gt;getOperand(1));
1461 Cond.push_back(SecondLastInst-&gt;getOperand(2));
1462 FBB = LastInst-&gt;getOperand(0).getMBB();
1463 return false;
1464 }
1465</pre>
1466</div>
1467
Bill Wendling4a2bca82009-04-05 00:41:19 +00001468<p>
1469For the last two cases (ending with a single conditional branch or ending with
1470one conditional and one unconditional branch), the operands returned in
1471the <tt>Cond</tt> parameter can be passed to methods of other instructions to
1472create new branches or perform other operations. An implementation
1473of <tt>AnalyzeBranch</tt> requires the helper methods <tt>RemoveBranch</tt>
1474and <tt>InsertBranch</tt> to manage subsequent operations.
1475</p>
Chris Lattner78975382008-11-11 19:30:41 +00001476
Bill Wendling4a2bca82009-04-05 00:41:19 +00001477<p>
1478<tt>AnalyzeBranch</tt> should return false indicating success in most circumstances.
Chris Lattner78975382008-11-11 19:30:41 +00001479<tt>AnalyzeBranch</tt> should only return true when the method is stumped about what to
1480do, for example, if a block has three terminating branches. <tt>AnalyzeBranch</tt> may
1481return true if it encounters a terminator it cannot handle, such as an indirect
Bill Wendling4a2bca82009-04-05 00:41:19 +00001482branch.
1483</p>
1484
Chris Lattner78975382008-11-11 19:30:41 +00001485</div>
1486
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001487</div>
1488
Chris Lattner78975382008-11-11 19:30:41 +00001489<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001490<h2>
Chris Lattner78975382008-11-11 19:30:41 +00001491 <a name="InstructionSelector">Instruction Selector</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001492</h2>
Misha Brukman8eb67192004-09-06 22:58:13 +00001493<!-- *********************************************************************** -->
1494
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001495<div>
Misha Brukman8eb67192004-09-06 22:58:13 +00001496
Bill Wendling4a2bca82009-04-05 00:41:19 +00001497<p>
1498LLVM uses a <tt>SelectionDAG</tt> to represent LLVM IR instructions, and nodes
1499of the <tt>SelectionDAG</tt> ideally represent native target
1500instructions. During code generation, instruction selection passes are performed
1501to convert non-native DAG instructions into native target-specific
1502instructions. The pass described in <tt>XXXISelDAGToDAG.cpp</tt> is used to
1503match patterns and perform DAG-to-DAG instruction selection. Optionally, a pass
1504may be defined (in <tt>XXXBranchSelector.cpp</tt>) to perform similar DAG-to-DAG
1505operations for branch instructions. Later, the code in
1506<tt>XXXISelLowering.cpp</tt> replaces or removes operations and data types not
1507supported natively (legalizes) in a <tt>SelectionDAG</tt>.
1508</p>
1509
1510<p>
1511TableGen generates code for instruction selection using the following target
1512description input files:
1513</p>
1514
Misha Brukman8eb67192004-09-06 22:58:13 +00001515<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001516<li><tt>XXXInstrInfo.td</tt> &mdash; Contains definitions of instructions in a
1517 target-specific instruction set, generates <tt>XXXGenDAGISel.inc</tt>, which
1518 is included in <tt>XXXISelDAGToDAG.cpp</tt>.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001519
Bill Wendling4a2bca82009-04-05 00:41:19 +00001520<li><tt>XXXCallingConv.td</tt> &mdash; Contains the calling and return value
1521 conventions for the target architecture, and it generates
1522 <tt>XXXGenCallingConv.inc</tt>, which is included in
1523 <tt>XXXISelLowering.cpp</tt>.</li>
Misha Brukman8eb67192004-09-06 22:58:13 +00001524</ul>
1525
Bill Wendling4a2bca82009-04-05 00:41:19 +00001526<p>
1527The implementation of an instruction selection pass must include a header that
1528declares the <tt>FunctionPass</tt> class or a subclass of <tt>FunctionPass</tt>. In
1529<tt>XXXTargetMachine.cpp</tt>, a Pass Manager (PM) should add each instruction
1530selection pass into the queue of passes to run.
1531</p>
Chris Lattner78975382008-11-11 19:30:41 +00001532
Bill Wendling4a2bca82009-04-05 00:41:19 +00001533<p>
1534The LLVM static compiler (<tt>llc</tt>) is an excellent tool for visualizing the
1535contents of DAGs. To display the <tt>SelectionDAG</tt> before or after specific
1536processing phases, use the command line options for <tt>llc</tt>, described
NAKAMURA Takumi31c18062011-04-09 02:13:48 +00001537at <a href="CodeGenerator.html#selectiondag_process">
Chris Lattner78975382008-11-11 19:30:41 +00001538SelectionDAG Instruction Selection Process</a>.
1539</p>
1540
Bill Wendling4a2bca82009-04-05 00:41:19 +00001541<p>
1542To describe instruction selector behavior, you should add patterns for lowering
1543LLVM code into a <tt>SelectionDAG</tt> as the last parameter of the instruction
1544definitions in <tt>XXXInstrInfo.td</tt>. For example, in
1545<tt>SparcInstrInfo.td</tt>, this entry defines a register store operation, and
1546the last parameter describes a pattern with the store DAG operator.
1547</p>
Chris Lattner78975382008-11-11 19:30:41 +00001548
1549<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001550<pre>
1551def STrr : F3_1&lt; 3, 0b000100, (outs), (ins MEMrr:$addr, IntRegs:$src),
1552 "st $src, [$addr]", [(store IntRegs:$src, ADDRrr:$addr)]&gt;;
Chris Lattner78975382008-11-11 19:30:41 +00001553</pre>
1554</div>
1555
Bill Wendling4a2bca82009-04-05 00:41:19 +00001556<p>
1557<tt>ADDRrr</tt> is a memory mode that is also defined in
1558<tt>SparcInstrInfo.td</tt>:
1559</p>
Chris Lattner78975382008-11-11 19:30:41 +00001560
1561<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001562<pre>
1563def ADDRrr : ComplexPattern&lt;i32, 2, "SelectADDRrr", [], []&gt;;
Chris Lattner78975382008-11-11 19:30:41 +00001564</pre>
1565</div>
1566
Bill Wendling4a2bca82009-04-05 00:41:19 +00001567<p>
1568The definition of <tt>ADDRrr</tt> refers to <tt>SelectADDRrr</tt>, which is a
1569function defined in an implementation of the Instructor Selector (such
1570as <tt>SparcISelDAGToDAG.cpp</tt>).
1571</p>
Chris Lattner78975382008-11-11 19:30:41 +00001572
Bill Wendling4a2bca82009-04-05 00:41:19 +00001573<p>
1574In <tt>lib/Target/TargetSelectionDAG.td</tt>, the DAG operator for store is
1575defined below:
1576</p>
Chris Lattner78975382008-11-11 19:30:41 +00001577
1578<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001579<pre>
1580def store : PatFrag&lt;(ops node:$val, node:$ptr),
Chris Lattner78975382008-11-11 19:30:41 +00001581 (st node:$val, node:$ptr), [{
1582 if (StoreSDNode *ST = dyn_cast&lt;StoreSDNode&gt;(N))
1583 return !ST-&gt;isTruncatingStore() &amp;&amp;
1584 ST-&gt;getAddressingMode() == ISD::UNINDEXED;
1585 return false;
1586}]&gt;;
1587</pre>
1588</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001589
1590<p>
1591<tt>XXXInstrInfo.td</tt> also generates (in <tt>XXXGenDAGISel.inc</tt>) the
1592<tt>SelectCode</tt> method that is used to call the appropriate processing
1593method for an instruction. In this example, <tt>SelectCode</tt>
1594calls <tt>Select_ISD_STORE</tt> for the <tt>ISD::STORE</tt> opcode.
1595</p>
Chris Lattner78975382008-11-11 19:30:41 +00001596
1597<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001598<pre>
1599SDNode *SelectCode(SDValue N) {
Chris Lattner78975382008-11-11 19:30:41 +00001600 ...
Dan Gohman50ef90d2009-01-28 21:36:46 +00001601 MVT::ValueType NVT = N.getNode()-&gt;getValueType(0);
Chris Lattner78975382008-11-11 19:30:41 +00001602 switch (N.getOpcode()) {
1603 case ISD::STORE: {
1604 switch (NVT) {
1605 default:
1606 return Select_ISD_STORE(N);
1607 break;
1608 }
1609 break;
1610 }
1611 ...
1612</pre>
1613</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001614
1615<p>
1616The pattern for <tt>STrr</tt> is matched, so elsewhere in
1617<tt>XXXGenDAGISel.inc</tt>, code for <tt>STrr</tt> is created for
1618<tt>Select_ISD_STORE</tt>. The <tt>Emit_22</tt> method is also generated
1619in <tt>XXXGenDAGISel.inc</tt> to complete the processing of this
1620instruction.
1621</p>
Chris Lattner78975382008-11-11 19:30:41 +00001622
1623<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001624<pre>
1625SDNode *Select_ISD_STORE(const SDValue &amp;N) {
Dan Gohman50ef90d2009-01-28 21:36:46 +00001626 SDValue Chain = N.getOperand(0);
1627 if (Predicate_store(N.getNode())) {
1628 SDValue N1 = N.getOperand(1);
1629 SDValue N2 = N.getOperand(2);
1630 SDValue CPTmp0;
1631 SDValue CPTmp1;
Bill Wendling4a2bca82009-04-05 00:41:19 +00001632
Chris Lattner78975382008-11-11 19:30:41 +00001633 // Pattern: (st:void IntRegs:i32:$src,
1634 // ADDRrr:i32:$addr)&lt;&lt;P:Predicate_store&gt;&gt;
1635 // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)
1636 // Pattern complexity = 13 cost = 1 size = 0
1637 if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) &amp;&amp;
Dan Gohman50ef90d2009-01-28 21:36:46 +00001638 N1.getNode()-&gt;getValueType(0) == MVT::i32 &amp;&amp;
1639 N2.getNode()-&gt;getValueType(0) == MVT::i32) {
Chris Lattner78975382008-11-11 19:30:41 +00001640 return Emit_22(N, SP::STrr, CPTmp0, CPTmp1);
1641 }
1642...
1643</pre>
1644</div>
1645
1646<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001647<h3>
Chris Lattner78975382008-11-11 19:30:41 +00001648 <a name="LegalizePhase">The SelectionDAG Legalize Phase</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001649</h3>
Chris Lattner78975382008-11-11 19:30:41 +00001650
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001651<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001652
1653<p>
1654The Legalize phase converts a DAG to use types and operations that are natively
1655supported by the target. For natively unsupported types and operations, you need
1656to add code to the target-specific XXXTargetLowering implementation to convert
1657unsupported types and operations to supported ones.
1658</p>
1659
1660<p>
1661In the constructor for the <tt>XXXTargetLowering</tt> class, first use the
1662<tt>addRegisterClass</tt> method to specify which types are supports and which
1663register classes are associated with them. The code for the register classes are
1664generated by TableGen from <tt>XXXRegisterInfo.td</tt> and placed
1665in <tt>XXXGenRegisterInfo.h.inc</tt>. For example, the implementation of the
1666constructor for the SparcTargetLowering class (in
1667<tt>SparcISelLowering.cpp</tt>) starts with the following code:
1668</p>
Chris Lattner78975382008-11-11 19:30:41 +00001669
1670<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001671<pre>
1672addRegisterClass(MVT::i32, SP::IntRegsRegisterClass);
Chris Lattner78975382008-11-11 19:30:41 +00001673addRegisterClass(MVT::f32, SP::FPRegsRegisterClass);
1674addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass);
1675</pre>
1676</div>
1677
Bill Wendling4a2bca82009-04-05 00:41:19 +00001678<p>
1679You should examine the node types in the <tt>ISD</tt> namespace
1680(<tt>include/llvm/CodeGen/SelectionDAGNodes.h</tt>) and determine which
1681operations the target natively supports. For operations that do <b>not</b> have
1682native support, add a callback to the constructor for the XXXTargetLowering
1683class, so the instruction selection process knows what to do. The TargetLowering
1684class callback methods (declared in <tt>llvm/Target/TargetLowering.h</tt>) are:
1685</p>
1686
Chris Lattner78975382008-11-11 19:30:41 +00001687<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001688<li><tt>setOperationAction</tt> &mdash; General operation.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001689
Bill Wendling4a2bca82009-04-05 00:41:19 +00001690<li><tt>setLoadExtAction</tt> &mdash; Load with extension.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001691
Bill Wendling4a2bca82009-04-05 00:41:19 +00001692<li><tt>setTruncStoreAction</tt> &mdash; Truncating store.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001693
Bill Wendling4a2bca82009-04-05 00:41:19 +00001694<li><tt>setIndexedLoadAction</tt> &mdash; Indexed load.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001695
Bill Wendling4a2bca82009-04-05 00:41:19 +00001696<li><tt>setIndexedStoreAction</tt> &mdash; Indexed store.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001697
Bill Wendling4a2bca82009-04-05 00:41:19 +00001698<li><tt>setConvertAction</tt> &mdash; Type conversion.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001699
Bill Wendling4a2bca82009-04-05 00:41:19 +00001700<li><tt>setCondCodeAction</tt> &mdash; Support for a given condition code.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001701</ul>
1702
Bill Wendling4a2bca82009-04-05 00:41:19 +00001703<p>
1704Note: on older releases, <tt>setLoadXAction</tt> is used instead
1705of <tt>setLoadExtAction</tt>. Also, on older releases,
1706<tt>setCondCodeAction</tt> may not be supported. Examine your release
1707to see what methods are specifically supported.
1708</p>
Chris Lattner78975382008-11-11 19:30:41 +00001709
Bill Wendling4a2bca82009-04-05 00:41:19 +00001710<p>
1711These callbacks are used to determine that an operation does or does not work
1712with a specified type (or types). And in all cases, the third parameter is
1713a <tt>LegalAction</tt> type enum value: <tt>Promote</tt>, <tt>Expand</tt>,
Chris Lattner78975382008-11-11 19:30:41 +00001714<tt>Custom</tt>, or <tt>Legal</tt>. <tt>SparcISelLowering.cpp</tt>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001715contains examples of all four <tt>LegalAction</tt> values.
1716</p>
1717
Chris Lattner78975382008-11-11 19:30:41 +00001718<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001719<h4>
Chris Lattner78975382008-11-11 19:30:41 +00001720 <a name="promote">Promote</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001721</h4>
Chris Lattner78975382008-11-11 19:30:41 +00001722
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001723<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001724
1725<p>
1726For an operation without native support for a given type, the specified type may
1727be promoted to a larger type that is supported. For example, SPARC does not
1728support a sign-extending load for Boolean values (<tt>i1</tt> type), so
1729in <tt>SparcISelLowering.cpp</tt> the third parameter below, <tt>Promote</tt>,
1730changes <tt>i1</tt> type values to a large type before loading.
1731</p>
Chris Lattner78975382008-11-11 19:30:41 +00001732
1733<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001734<pre>
1735setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
Chris Lattner78975382008-11-11 19:30:41 +00001736</pre>
1737</div>
1738
Bill Wendling4a2bca82009-04-05 00:41:19 +00001739</div>
1740
Chris Lattner78975382008-11-11 19:30:41 +00001741<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001742<h4>
Chris Lattner78975382008-11-11 19:30:41 +00001743 <a name="expand">Expand</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001744</h4>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001745
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001746<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001747
1748<p>
1749For a type without native support, a value may need to be broken down further,
1750rather than promoted. For an operation without native support, a combination of
1751other operations may be used to similar effect. In SPARC, the floating-point
1752sine and cosine trig operations are supported by expansion to other operations,
1753as indicated by the third parameter, <tt>Expand</tt>, to
1754<tt>setOperationAction</tt>:
1755</p>
Chris Lattner78975382008-11-11 19:30:41 +00001756
1757<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001758<pre>
1759setOperationAction(ISD::FSIN, MVT::f32, Expand);
Chris Lattner78975382008-11-11 19:30:41 +00001760setOperationAction(ISD::FCOS, MVT::f32, Expand);
1761</pre>
1762</div>
1763
Bill Wendling4a2bca82009-04-05 00:41:19 +00001764</div>
1765
Chris Lattner78975382008-11-11 19:30:41 +00001766<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001767<h4>
Chris Lattner78975382008-11-11 19:30:41 +00001768 <a name="custom">Custom</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001769</h4>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001770
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001771<div>
Chris Lattner78975382008-11-11 19:30:41 +00001772
Bill Wendling4a2bca82009-04-05 00:41:19 +00001773<p>
1774For some operations, simple type promotion or operation expansion may be
1775insufficient. In some cases, a special intrinsic function must be implemented.
1776</p>
Chris Lattner78975382008-11-11 19:30:41 +00001777
Bill Wendling4a2bca82009-04-05 00:41:19 +00001778<p>
1779For example, a constant value may require special treatment, or an operation may
1780require spilling and restoring registers in the stack and working with register
1781allocators.
1782</p>
1783
1784<p>
1785As seen in <tt>SparcISelLowering.cpp</tt> code below, to perform a type
Chris Lattner78975382008-11-11 19:30:41 +00001786conversion from a floating point value to a signed integer, first the
Bill Wendling4a2bca82009-04-05 00:41:19 +00001787<tt>setOperationAction</tt> should be called with <tt>Custom</tt> as the third
1788parameter:
1789</p>
Chris Lattner78975382008-11-11 19:30:41 +00001790
1791<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001792<pre>
1793setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
Chris Lattner78975382008-11-11 19:30:41 +00001794</pre>
1795</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001796
1797<p>
1798In the <tt>LowerOperation</tt> method, for each <tt>Custom</tt> operation, a
1799case statement should be added to indicate what function to call. In the
1800following code, an <tt>FP_TO_SINT</tt> opcode will call
1801the <tt>LowerFP_TO_SINT</tt> method:
1802</p>
Chris Lattner78975382008-11-11 19:30:41 +00001803
1804<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001805<pre>
1806SDValue SparcTargetLowering::LowerOperation(SDValue Op, SelectionDAG &amp;DAG) {
Chris Lattner78975382008-11-11 19:30:41 +00001807 switch (Op.getOpcode()) {
1808 case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG);
1809 ...
1810 }
1811}
1812</pre>
Chris Lattner78975382008-11-11 19:30:41 +00001813</div>
1814
Bill Wendling4a2bca82009-04-05 00:41:19 +00001815<p>
1816Finally, the <tt>LowerFP_TO_SINT</tt> method is implemented, using an FP
1817register to convert the floating-point value to an integer.
1818</p>
1819
Chris Lattner78975382008-11-11 19:30:41 +00001820<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001821<pre>
1822static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &amp;DAG) {
1823 assert(Op.getValueType() == MVT::i32);
Chris Lattner78975382008-11-11 19:30:41 +00001824 Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0));
Wesley Peckbf17cfa2010-11-23 03:31:01 +00001825 return DAG.getNode(ISD::BITCAST, MVT::i32, Op);
Chris Lattner78975382008-11-11 19:30:41 +00001826}
1827</pre>
1828</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001829
1830</div>
1831
Chris Lattner78975382008-11-11 19:30:41 +00001832<!-- _______________________________________________________________________ -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001833<h4>
Chris Lattner78975382008-11-11 19:30:41 +00001834 <a name="legal">Legal</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001835</h4>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001836
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001837<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001838
1839<p>
1840The <tt>Legal</tt> LegalizeAction enum value simply indicates that an
1841operation <b>is</b> natively supported. <tt>Legal</tt> represents the default
1842condition, so it is rarely used. In <tt>SparcISelLowering.cpp</tt>, the action
1843for <tt>CTPOP</tt> (an operation to count the bits set in an integer) is
1844natively supported only for SPARC v9. The following code enables
1845the <tt>Expand</tt> conversion technique for non-v9 SPARC implementations.
1846</p>
Chris Lattner78975382008-11-11 19:30:41 +00001847
1848<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001849<pre>
1850setOperationAction(ISD::CTPOP, MVT::i32, Expand);
Chris Lattner78975382008-11-11 19:30:41 +00001851...
1852if (TM.getSubtarget&lt;SparcSubtarget&gt;().isV9())
1853 setOperationAction(ISD::CTPOP, MVT::i32, Legal);
1854 case ISD::SETULT: return SPCC::ICC_CS;
1855 case ISD::SETULE: return SPCC::ICC_LEU;
1856 case ISD::SETUGT: return SPCC::ICC_GU;
1857 case ISD::SETUGE: return SPCC::ICC_CC;
1858 }
1859}
1860</pre>
1861</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001862
1863</div>
1864
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001865</div>
1866
Chris Lattner78975382008-11-11 19:30:41 +00001867<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001868<h3>
Chris Lattner78975382008-11-11 19:30:41 +00001869 <a name="callingConventions">Calling Conventions</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00001870</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001871
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00001872<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001873
1874<p>
1875To support target-specific calling conventions, <tt>XXXGenCallingConv.td</tt>
Chris Lattner78975382008-11-11 19:30:41 +00001876uses interfaces (such as CCIfType and CCAssignToReg) that are defined in
Bill Wendling4a2bca82009-04-05 00:41:19 +00001877<tt>lib/Target/TargetCallingConv.td</tt>. TableGen can take the target
1878descriptor file <tt>XXXGenCallingConv.td</tt> and generate the header
1879file <tt>XXXGenCallingConv.inc</tt>, which is typically included
1880in <tt>XXXISelLowering.cpp</tt>. You can use the interfaces in
1881<tt>TargetCallingConv.td</tt> to specify:
1882</p>
1883
Chris Lattner78975382008-11-11 19:30:41 +00001884<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001885<li>The order of parameter allocation.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001886
Bill Wendling4a2bca82009-04-05 00:41:19 +00001887<li>Where parameters and return values are placed (that is, on the stack or in
1888 registers).</li>
Chris Lattner78975382008-11-11 19:30:41 +00001889
Bill Wendling4a2bca82009-04-05 00:41:19 +00001890<li>Which registers may be used.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001891
Bill Wendling4a2bca82009-04-05 00:41:19 +00001892<li>Whether the caller or callee unwinds the stack.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001893</ul>
1894
Bill Wendling4a2bca82009-04-05 00:41:19 +00001895<p>
1896The following example demonstrates the use of the <tt>CCIfType</tt> and
1897<tt>CCAssignToReg</tt> interfaces. If the <tt>CCIfType</tt> predicate is true
1898(that is, if the current argument is of type <tt>f32</tt> or <tt>f64</tt>), then
1899the action is performed. In this case, the <tt>CCAssignToReg</tt> action assigns
1900the argument value to the first available register: either <tt>R0</tt>
1901or <tt>R1</tt>.
1902</p>
Chris Lattner78975382008-11-11 19:30:41 +00001903
1904<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001905<pre>
1906CCIfType&lt;[f32,f64], CCAssignToReg&lt;[R0, R1]&gt;&gt;
1907</pre>
1908</div>
1909
1910<p>
1911<tt>SparcCallingConv.td</tt> contains definitions for a target-specific
1912return-value calling convention (RetCC_Sparc32) and a basic 32-bit C calling
1913convention (<tt>CC_Sparc32</tt>). The definition of <tt>RetCC_Sparc32</tt>
1914(shown below) indicates which registers are used for specified scalar return
1915types. A single-precision float is returned to register <tt>F0</tt>, and a
1916double-precision float goes to register <tt>D0</tt>. A 32-bit integer is
1917returned in register <tt>I0</tt> or <tt>I1</tt>.
1918</p>
1919
1920<div class="doc_code">
1921<pre>
1922def RetCC_Sparc32 : CallingConv&lt;[
Chris Lattner78975382008-11-11 19:30:41 +00001923 CCIfType&lt;[i32], CCAssignToReg&lt;[I0, I1]&gt;&gt;,
1924 CCIfType&lt;[f32], CCAssignToReg&lt;[F0]&gt;&gt;,
1925 CCIfType&lt;[f64], CCAssignToReg&lt;[D0]&gt;&gt;
1926]&gt;;
1927</pre>
1928</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001929
1930<p>
1931The definition of <tt>CC_Sparc32</tt> in <tt>SparcCallingConv.td</tt> introduces
1932<tt>CCAssignToStack</tt>, which assigns the value to a stack slot with the
1933specified size and alignment. In the example below, the first parameter, 4,
1934indicates the size of the slot, and the second parameter, also 4, indicates the
1935stack alignment along 4-byte units. (Special cases: if size is zero, then the
1936ABI size is used; if alignment is zero, then the ABI alignment is used.)
1937</p>
Chris Lattner78975382008-11-11 19:30:41 +00001938
1939<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001940<pre>
1941def CC_Sparc32 : CallingConv&lt;[
Chris Lattner78975382008-11-11 19:30:41 +00001942 // All arguments get passed in integer registers if there is space.
1943 CCIfType&lt;[i32, f32, f64], CCAssignToReg&lt;[I0, I1, I2, I3, I4, I5]&gt;&gt;,
1944 CCAssignToStack&lt;4, 4&gt;
1945]&gt;;
1946</pre>
1947</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001948
1949<p>
1950<tt>CCDelegateTo</tt> is another commonly used interface, which tries to find a
1951specified sub-calling convention, and, if a match is found, it is invoked. In
1952the following example (in <tt>X86CallingConv.td</tt>), the definition of
1953<tt>RetCC_X86_32_C</tt> ends with <tt>CCDelegateTo</tt>. After the current value
1954is assigned to the register <tt>ST0</tt> or <tt>ST1</tt>,
1955the <tt>RetCC_X86Common</tt> is invoked.
1956</p>
Chris Lattner78975382008-11-11 19:30:41 +00001957
1958<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001959<pre>
1960def RetCC_X86_32_C : CallingConv&lt;[
Chris Lattner78975382008-11-11 19:30:41 +00001961 CCIfType&lt;[f32], CCAssignToReg&lt;[ST0, ST1]&gt;&gt;,
1962 CCIfType&lt;[f64], CCAssignToReg&lt;[ST0, ST1]&gt;&gt;,
1963 CCDelegateTo&lt;RetCC_X86Common&gt;
1964]&gt;;
1965</pre>
1966</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001967
1968<p>
1969<tt>CCIfCC</tt> is an interface that attempts to match the given name to the
1970current calling convention. If the name identifies the current calling
Chris Lattner78975382008-11-11 19:30:41 +00001971convention, then a specified action is invoked. In the following example (in
Bill Wendling4a2bca82009-04-05 00:41:19 +00001972<tt>X86CallingConv.td</tt>), if the <tt>Fast</tt> calling convention is in use,
1973then <tt>RetCC_X86_32_Fast</tt> is invoked. If the <tt>SSECall</tt> calling
1974convention is in use, then <tt>RetCC_X86_32_SSE</tt> is invoked.
1975</p>
Chris Lattner78975382008-11-11 19:30:41 +00001976
1977<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00001978<pre>
1979def RetCC_X86_32 : CallingConv&lt;[
1980 CCIfCC&lt;"CallingConv::Fast", CCDelegateTo&lt;RetCC_X86_32_Fast&gt;&gt;,
1981 CCIfCC&lt;"CallingConv::X86_SSECall", CCDelegateTo&lt;RetCC_X86_32_SSE&gt;&gt;,
Chris Lattner78975382008-11-11 19:30:41 +00001982 CCDelegateTo&lt;RetCC_X86_32_C&gt;
1983]&gt;;
1984</pre>
1985</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001986
Chris Lattner78975382008-11-11 19:30:41 +00001987<p>Other calling convention interfaces include:</p>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001988
Chris Lattner78975382008-11-11 19:30:41 +00001989<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00001990<li><tt>CCIf &lt;predicate, action&gt;</tt> &mdash; If the predicate matches,
1991 apply the action.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001992
Bill Wendling4a2bca82009-04-05 00:41:19 +00001993<li><tt>CCIfInReg &lt;action&gt;</tt> &mdash; If the argument is marked with the
1994 '<tt>inreg</tt>' attribute, then apply the action.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001995
Bill Wendling4a2bca82009-04-05 00:41:19 +00001996<li><tt>CCIfNest &lt;action&gt;</tt> &mdash; Inf the argument is marked with the
1997 '<tt>nest</tt>' attribute, then apply the action.</li>
Chris Lattner78975382008-11-11 19:30:41 +00001998
Bill Wendling4a2bca82009-04-05 00:41:19 +00001999<li><tt>CCIfNotVarArg &lt;action&gt;</tt> &mdash; If the current function does
2000 not take a variable number of arguments, apply the action.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002001
Bill Wendling4a2bca82009-04-05 00:41:19 +00002002<li><tt>CCAssignToRegWithShadow &lt;registerList, shadowList&gt;</tt> &mdash;
2003 similar to <tt>CCAssignToReg</tt>, but with a shadow list of registers.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002004
Bill Wendling4a2bca82009-04-05 00:41:19 +00002005<li><tt>CCPassByVal &lt;size, align&gt;</tt> &mdash; Assign value to a stack
2006 slot with the minimum specified size and alignment.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002007
Bill Wendling4a2bca82009-04-05 00:41:19 +00002008<li><tt>CCPromoteToType &lt;type&gt;</tt> &mdash; Promote the current value to
2009 the specified type.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002010
Bill Wendling4a2bca82009-04-05 00:41:19 +00002011<li><tt>CallingConv &lt;[actions]&gt;</tt> &mdash; Define each calling
2012 convention that is supported.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002013</ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002014
Chris Lattner78975382008-11-11 19:30:41 +00002015</div>
2016
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002017</div>
2018
Chris Lattner78975382008-11-11 19:30:41 +00002019<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002020<h2>
Chris Lattner78975382008-11-11 19:30:41 +00002021 <a name="assemblyPrinter">Assembly Printer</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002022</h2>
Chris Lattner78975382008-11-11 19:30:41 +00002023<!-- *********************************************************************** -->
2024
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002025<div>
Chris Lattner78975382008-11-11 19:30:41 +00002026
Bill Wendling4a2bca82009-04-05 00:41:19 +00002027<p>
2028During the code emission stage, the code generator may utilize an LLVM pass to
2029produce assembly output. To do this, you want to implement the code for a
2030printer that converts LLVM IR to a GAS-format assembly language for your target
2031machine, using the following steps:
2032</p>
2033
2034<ul>
2035<li>Define all the assembly strings for your target, adding them to the
2036 instructions defined in the <tt>XXXInstrInfo.td</tt> file.
2037 (See <a href="#InstructionSet">Instruction Set</a>.) TableGen will produce
2038 an output file (<tt>XXXGenAsmWriter.inc</tt>) with an implementation of
2039 the <tt>printInstruction</tt> method for the XXXAsmPrinter class.</li>
2040
2041<li>Write <tt>XXXTargetAsmInfo.h</tt>, which contains the bare-bones declaration
2042 of the <tt>XXXTargetAsmInfo</tt> class (a subclass
2043 of <tt>TargetAsmInfo</tt>).</li>
Chris Lattner78975382008-11-11 19:30:41 +00002044
2045<li>Write <tt>XXXTargetAsmInfo.cpp</tt>, which contains target-specific values
Bill Wendling4a2bca82009-04-05 00:41:19 +00002046 for <tt>TargetAsmInfo</tt> properties and sometimes new implementations for
2047 methods.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002048
Bill Wendling4a2bca82009-04-05 00:41:19 +00002049<li>Write <tt>XXXAsmPrinter.cpp</tt>, which implements the <tt>AsmPrinter</tt>
2050 class that performs the LLVM-to-assembly conversion.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002051</ul>
2052
Bill Wendling4a2bca82009-04-05 00:41:19 +00002053<p>
2054The code in <tt>XXXTargetAsmInfo.h</tt> is usually a trivial declaration of the
2055<tt>XXXTargetAsmInfo</tt> class for use in <tt>XXXTargetAsmInfo.cpp</tt>.
2056Similarly, <tt>XXXTargetAsmInfo.cpp</tt> usually has a few declarations of
2057<tt>XXXTargetAsmInfo</tt> replacement values that override the default values
2058in <tt>TargetAsmInfo.cpp</tt>. For example in <tt>SparcTargetAsmInfo.cpp</tt>:
2059</p>
Chris Lattner78975382008-11-11 19:30:41 +00002060
2061<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002062<pre>
2063SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &amp;TM) {
2064 Data16bitsDirective = "\t.half\t";
2065 Data32bitsDirective = "\t.word\t";
Chris Lattner78975382008-11-11 19:30:41 +00002066 Data64bitsDirective = 0; // .xword is only supported by V9.
Bill Wendling4a2bca82009-04-05 00:41:19 +00002067 ZeroDirective = "\t.skip\t";
2068 CommentString = "!";
2069 ConstantPoolSection = "\t.section \".rodata\",#alloc\n";
Chris Lattner78975382008-11-11 19:30:41 +00002070}
2071</pre>
2072</div>
Chris Lattner78975382008-11-11 19:30:41 +00002073
Bill Wendling4a2bca82009-04-05 00:41:19 +00002074<p>
2075The X86 assembly printer implementation (<tt>X86TargetAsmInfo</tt>) is an
Chris Lattnerb6d66742009-08-02 04:02:52 +00002076example where the target specific <tt>TargetAsmInfo</tt> class uses an
2077overridden methods: <tt>ExpandInlineAsm</tt>.
Bill Wendling4a2bca82009-04-05 00:41:19 +00002078</p>
2079
2080<p>
2081A target-specific implementation of AsmPrinter is written in
2082<tt>XXXAsmPrinter.cpp</tt>, which implements the <tt>AsmPrinter</tt> class that
2083converts the LLVM to printable assembly. The implementation must include the
2084following headers that have declarations for the <tt>AsmPrinter</tt> and
2085<tt>MachineFunctionPass</tt> classes. The <tt>MachineFunctionPass</tt> is a
2086subclass of <tt>FunctionPass</tt>.
2087</p>
Chris Lattner78975382008-11-11 19:30:41 +00002088
2089<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002090<pre>
2091#include "llvm/CodeGen/AsmPrinter.h"
2092#include "llvm/CodeGen/MachineFunctionPass.h"
Chris Lattner78975382008-11-11 19:30:41 +00002093</pre>
2094</div>
2095
Bill Wendling4a2bca82009-04-05 00:41:19 +00002096<p>
2097As a <tt>FunctionPass</tt>, <tt>AsmPrinter</tt> first
2098calls <tt>doInitialization</tt> to set up the <tt>AsmPrinter</tt>. In
2099<tt>SparcAsmPrinter</tt>, a <tt>Mangler</tt> object is instantiated to process
2100variable names.
2101</p>
Chris Lattner78975382008-11-11 19:30:41 +00002102
Bill Wendling4a2bca82009-04-05 00:41:19 +00002103<p>
2104In <tt>XXXAsmPrinter.cpp</tt>, the <tt>runOnMachineFunction</tt> method
2105(declared in <tt>MachineFunctionPass</tt>) must be implemented
2106for <tt>XXXAsmPrinter</tt>. In <tt>MachineFunctionPass</tt>,
2107the <tt>runOnFunction</tt> method invokes <tt>runOnMachineFunction</tt>.
2108Target-specific implementations of <tt>runOnMachineFunction</tt> differ, but
2109generally do the following to process each machine function:
2110</p>
2111
Chris Lattner78975382008-11-11 19:30:41 +00002112<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002113<li>Call <tt>SetupMachineFunction</tt> to perform initialization.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002114
Bill Wendling4a2bca82009-04-05 00:41:19 +00002115<li>Call <tt>EmitConstantPool</tt> to print out (to the output stream) constants
2116 which have been spilled to memory.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002117
Bill Wendling4a2bca82009-04-05 00:41:19 +00002118<li>Call <tt>EmitJumpTableInfo</tt> to print out jump tables used by the current
2119 function.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002120
Bill Wendling4a2bca82009-04-05 00:41:19 +00002121<li>Print out the label for the current function.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002122
Bill Wendling4a2bca82009-04-05 00:41:19 +00002123<li>Print out the code for the function, including basic block labels and the
2124 assembly for the instruction (using <tt>printInstruction</tt>)</li>
Chris Lattner78975382008-11-11 19:30:41 +00002125</ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002126
2127<p>
2128The <tt>XXXAsmPrinter</tt> implementation must also include the code generated
2129by TableGen that is output in the <tt>XXXGenAsmWriter.inc</tt> file. The code
2130in <tt>XXXGenAsmWriter.inc</tt> contains an implementation of the
2131<tt>printInstruction</tt> method that may call these methods:
2132</p>
2133
Chris Lattner78975382008-11-11 19:30:41 +00002134<ul>
2135<li><tt>printOperand</tt></li>
2136
2137<li><tt>printMemOperand</tt></li>
2138
2139<li><tt>printCCOperand (for conditional statements)</tt></li>
2140
2141<li><tt>printDataDirective</tt></li>
2142
2143<li><tt>printDeclare</tt></li>
2144
2145<li><tt>printImplicitDef</tt></li>
2146
2147<li><tt>printInlineAsm</tt></li>
Chris Lattner78975382008-11-11 19:30:41 +00002148</ul>
2149
Bill Wendling4a2bca82009-04-05 00:41:19 +00002150<p>
2151The implementations of <tt>printDeclare</tt>, <tt>printImplicitDef</tt>,
2152<tt>printInlineAsm</tt>, and <tt>printLabel</tt> in <tt>AsmPrinter.cpp</tt> are
2153generally adequate for printing assembly and do not need to be
Chris Lattnerdeb8c152009-09-12 22:57:37 +00002154overridden.
Bill Wendling4a2bca82009-04-05 00:41:19 +00002155</p>
Chris Lattner78975382008-11-11 19:30:41 +00002156
Bill Wendling4a2bca82009-04-05 00:41:19 +00002157<p>
2158The <tt>printOperand</tt> method is implemented with a long switch/case
Chris Lattner78975382008-11-11 19:30:41 +00002159statement for the type of operand: register, immediate, basic block, external
2160symbol, global address, constant pool index, or jump table index. For an
Bill Wendling4a2bca82009-04-05 00:41:19 +00002161instruction with a memory address operand, the <tt>printMemOperand</tt> method
2162should be implemented to generate the proper output. Similarly,
2163<tt>printCCOperand</tt> should be used to print a conditional operand.
2164</p>
Chris Lattner78975382008-11-11 19:30:41 +00002165
Bill Wendling4a2bca82009-04-05 00:41:19 +00002166<p><tt>doFinalization</tt> should be overridden in <tt>XXXAsmPrinter</tt>, and
2167it should be called to shut down the assembly printer. During
2168<tt>doFinalization</tt>, global variables and constants are printed to
2169output.
2170</p>
2171
Chris Lattner78975382008-11-11 19:30:41 +00002172</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002173
Chris Lattner78975382008-11-11 19:30:41 +00002174<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002175<h2>
Chris Lattner78975382008-11-11 19:30:41 +00002176 <a name="subtargetSupport">Subtarget Support</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002177</h2>
Chris Lattner78975382008-11-11 19:30:41 +00002178<!-- *********************************************************************** -->
2179
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002180<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002181
2182<p>
2183Subtarget support is used to inform the code generation process of instruction
2184set variations for a given chip set. For example, the LLVM SPARC implementation
2185provided covers three major versions of the SPARC microprocessor architecture:
2186Version 8 (V8, which is a 32-bit architecture), Version 9 (V9, a 64-bit
2187architecture), and the UltraSPARC architecture. V8 has 16 double-precision
2188floating-point registers that are also usable as either 32 single-precision or 8
2189quad-precision registers. V8 is also purely big-endian. V9 has 32
2190double-precision floating-point registers that are also usable as 16
Chris Lattner78975382008-11-11 19:30:41 +00002191quad-precision registers, but cannot be used as single-precision registers. The
2192UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set
Bill Wendling4a2bca82009-04-05 00:41:19 +00002193extensions.
2194</p>
Chris Lattner78975382008-11-11 19:30:41 +00002195
Bill Wendling4a2bca82009-04-05 00:41:19 +00002196<p>
2197If subtarget support is needed, you should implement a target-specific
2198XXXSubtarget class for your architecture. This class should process the
2199command-line options <tt>-mcpu=</tt> and <tt>-mattr=</tt>.
2200</p>
Chris Lattner78975382008-11-11 19:30:41 +00002201
Bill Wendling4a2bca82009-04-05 00:41:19 +00002202<p>
2203TableGen uses definitions in the <tt>Target.td</tt> and <tt>Sparc.td</tt> files
2204to generate code in <tt>SparcGenSubtarget.inc</tt>. In <tt>Target.td</tt>, shown
2205below, the <tt>SubtargetFeature</tt> interface is defined. The first 4 string
2206parameters of the <tt>SubtargetFeature</tt> interface are a feature name, an
2207attribute set by the feature, the value of the attribute, and a description of
2208the feature. (The fifth parameter is a list of features whose presence is
2209implied, and its default value is an empty array.)
2210</p>
Chris Lattner78975382008-11-11 19:30:41 +00002211
2212<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002213<pre>
2214class SubtargetFeature&lt;string n, string a, string v, string d,
Chris Lattner78975382008-11-11 19:30:41 +00002215 list&lt;SubtargetFeature&gt; i = []&gt; {
2216 string Name = n;
2217 string Attribute = a;
2218 string Value = v;
2219 string Desc = d;
2220 list&lt;SubtargetFeature&gt; Implies = i;
2221}
2222</pre>
2223</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002224
2225<p>
2226In the <tt>Sparc.td</tt> file, the SubtargetFeature is used to define the
2227following features.
2228</p>
Chris Lattner78975382008-11-11 19:30:41 +00002229
2230<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002231<pre>
2232def FeatureV9 : SubtargetFeature&lt;"v9", "IsV9", "true",
2233 "Enable SPARC-V9 instructions"&gt;;
2234def FeatureV8Deprecated : SubtargetFeature&lt;"deprecated-v8",
2235 "V8DeprecatedInsts", "true",
2236 "Enable deprecated V8 instructions in V9 mode"&gt;;
2237def FeatureVIS : SubtargetFeature&lt;"vis", "IsVIS", "true",
2238 "Enable UltraSPARC Visual Instruction Set extensions"&gt;;
Chris Lattner78975382008-11-11 19:30:41 +00002239</pre>
2240</div>
2241
Bill Wendling4a2bca82009-04-05 00:41:19 +00002242<p>
2243Elsewhere in <tt>Sparc.td</tt>, the Proc class is defined and then is used to
2244define particular SPARC processor subtypes that may have the previously
2245described features.
2246</p>
Chris Lattner78975382008-11-11 19:30:41 +00002247
2248<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002249<pre>
2250class Proc&lt;string Name, list&lt;SubtargetFeature&gt; Features&gt;
2251 : Processor&lt;Name, NoItineraries, Features&gt;;
Chris Lattner78975382008-11-11 19:30:41 +00002252&nbsp;
Bill Wendling4a2bca82009-04-05 00:41:19 +00002253def : Proc&lt;"generic", []&gt;;
2254def : Proc&lt;"v8", []&gt;;
2255def : Proc&lt;"supersparc", []&gt;;
2256def : Proc&lt;"sparclite", []&gt;;
2257def : Proc&lt;"f934", []&gt;;
2258def : Proc&lt;"hypersparc", []&gt;;
2259def : Proc&lt;"sparclite86x", []&gt;;
2260def : Proc&lt;"sparclet", []&gt;;
2261def : Proc&lt;"tsc701", []&gt;;
2262def : Proc&lt;"v9", [FeatureV9]&gt;;
2263def : Proc&lt;"ultrasparc", [FeatureV9, FeatureV8Deprecated]&gt;;
2264def : Proc&lt;"ultrasparc3", [FeatureV9, FeatureV8Deprecated]&gt;;
2265def : Proc&lt;"ultrasparc3-vis", [FeatureV9, FeatureV8Deprecated, FeatureVIS]&gt;;
Chris Lattner78975382008-11-11 19:30:41 +00002266</pre>
2267</div>
2268
Bill Wendling4a2bca82009-04-05 00:41:19 +00002269<p>
2270From <tt>Target.td</tt> and <tt>Sparc.td</tt> files, the resulting
Chris Lattner78975382008-11-11 19:30:41 +00002271SparcGenSubtarget.inc specifies enum values to identify the features, arrays of
2272constants to represent the CPU features and CPU subtypes, and the
2273ParseSubtargetFeatures method that parses the features string that sets
Bill Wendling4a2bca82009-04-05 00:41:19 +00002274specified subtarget options. The generated <tt>SparcGenSubtarget.inc</tt> file
2275should be included in the <tt>SparcSubtarget.cpp</tt>. The target-specific
2276implementation of the XXXSubtarget method should follow this pseudocode:
2277</p>
Chris Lattner78975382008-11-11 19:30:41 +00002278
2279<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002280<pre>
2281XXXSubtarget::XXXSubtarget(const Module &amp;M, const std::string &amp;FS) {
Chris Lattner78975382008-11-11 19:30:41 +00002282 // Set the default features
2283 // Determine default and user specified characteristics of the CPU
2284 // Call ParseSubtargetFeatures(FS, CPU) to parse the features string
2285 // Perform any additional operations
2286}
2287</pre>
2288</div>
2289
Bill Wendlinge9e6fd92009-04-05 00:43:04 +00002290</div>
2291
Chris Lattner78975382008-11-11 19:30:41 +00002292<!-- *********************************************************************** -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002293<h2>
Chris Lattner78975382008-11-11 19:30:41 +00002294 <a name="jitSupport">JIT Support</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002295</h2>
Chris Lattner78975382008-11-11 19:30:41 +00002296<!-- *********************************************************************** -->
2297
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002298<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002299
2300<p>
2301The implementation of a target machine optionally includes a Just-In-Time (JIT)
2302code generator that emits machine code and auxiliary structures as binary output
2303that can be written directly to memory. To do this, implement JIT code
2304generation by performing the following steps:
2305</p>
2306
Chris Lattner78975382008-11-11 19:30:41 +00002307<ul>
2308<li>Write an <tt>XXXCodeEmitter.cpp</tt> file that contains a machine function
Bill Wendling4a2bca82009-04-05 00:41:19 +00002309 pass that transforms target-machine instructions into relocatable machine
2310 code.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002311
Bill Wendling4a2bca82009-04-05 00:41:19 +00002312<li>Write an <tt>XXXJITInfo.cpp</tt> file that implements the JIT interfaces for
2313 target-specific code-generation activities, such as emitting machine code
2314 and stubs.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002315
Bill Wendling4a2bca82009-04-05 00:41:19 +00002316<li>Modify <tt>XXXTargetMachine</tt> so that it provides a
2317 <tt>TargetJITInfo</tt> object through its <tt>getJITInfo</tt> method.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002318</ul>
2319
Bill Wendling4a2bca82009-04-05 00:41:19 +00002320<p>
2321There are several different approaches to writing the JIT support code. For
2322instance, TableGen and target descriptor files may be used for creating a JIT
2323code generator, but are not mandatory. For the Alpha and PowerPC target
2324machines, TableGen is used to generate <tt>XXXGenCodeEmitter.inc</tt>, which
Chris Lattner78975382008-11-11 19:30:41 +00002325contains the binary coding of machine instructions and the
Bill Wendling4a2bca82009-04-05 00:41:19 +00002326<tt>getBinaryCodeForInstr</tt> method to access those codes. Other JIT
2327implementations do not.
2328</p>
Chris Lattner78975382008-11-11 19:30:41 +00002329
Bill Wendling4a2bca82009-04-05 00:41:19 +00002330<p>
2331Both <tt>XXXJITInfo.cpp</tt> and <tt>XXXCodeEmitter.cpp</tt> must include the
2332<tt>llvm/CodeGen/MachineCodeEmitter.h</tt> header file that defines the
2333<tt>MachineCodeEmitter</tt> class containing code for several callback functions
2334that write data (in bytes, words, strings, etc.) to the output stream.
2335</p>
2336
Chris Lattner78975382008-11-11 19:30:41 +00002337<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002338<h3>
Chris Lattner78975382008-11-11 19:30:41 +00002339 <a name="mce">Machine Code Emitter</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002340</h3>
Chris Lattner78975382008-11-11 19:30:41 +00002341
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002342<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002343
2344<p>
2345In <tt>XXXCodeEmitter.cpp</tt>, a target-specific of the <tt>Emitter</tt> class
2346is implemented as a function pass (subclass
2347of <tt>MachineFunctionPass</tt>). The target-specific implementation
2348of <tt>runOnMachineFunction</tt> (invoked by
2349<tt>runOnFunction</tt> in <tt>MachineFunctionPass</tt>) iterates through the
2350<tt>MachineBasicBlock</tt> calls <tt>emitInstruction</tt> to process each
2351instruction and emit binary code. <tt>emitInstruction</tt> is largely
2352implemented with case statements on the instruction types defined in
2353<tt>XXXInstrInfo.h</tt>. For example, in <tt>X86CodeEmitter.cpp</tt>,
2354the <tt>emitInstruction</tt> method is built around the following switch/case
2355statements:
2356</p>
Chris Lattner78975382008-11-11 19:30:41 +00002357
2358<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002359<pre>
2360switch (Desc-&gt;TSFlags &amp; X86::FormMask) {
Chris Lattner78975382008-11-11 19:30:41 +00002361case X86II::Pseudo: // for not yet implemented instructions
2362 ... // or pseudo-instructions
2363 break;
2364case X86II::RawFrm: // for instructions with a fixed opcode value
2365 ...
2366 break;
2367case X86II::AddRegFrm: // for instructions that have one register operand
2368 ... // added to their opcode
2369 break;
2370case X86II::MRMDestReg:// for instructions that use the Mod/RM byte
2371 ... // to specify a destination (register)
2372 break;
2373case X86II::MRMDestMem:// for instructions that use the Mod/RM byte
2374 ... // to specify a destination (memory)
2375 break;
2376case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte
2377 ... // to specify a source (register)
2378 break;
2379case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte
2380 ... // to specify a source (memory)
2381 break;
2382case X86II::MRM0r: case X86II::MRM1r: // for instructions that operate on
2383case X86II::MRM2r: case X86II::MRM3r: // a REGISTER r/m operand and
2384case X86II::MRM4r: case X86II::MRM5r: // use the Mod/RM byte and a field
2385case X86II::MRM6r: case X86II::MRM7r: // to hold extended opcode data
2386 ...
2387 break;
2388case X86II::MRM0m: case X86II::MRM1m: // for instructions that operate on
2389case X86II::MRM2m: case X86II::MRM3m: // a MEMORY r/m operand and
2390case X86II::MRM4m: case X86II::MRM5m: // use the Mod/RM byte and a field
2391case X86II::MRM6m: case X86II::MRM7m: // to hold extended opcode data
2392 ...
2393 break;
2394case X86II::MRMInitReg: // for instructions whose source and
2395 ... // destination are the same register
2396 break;
2397}
2398</pre>
2399</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002400
2401<p>
2402The implementations of these case statements often first emit the opcode and
2403then get the operand(s). Then depending upon the operand, helper methods may be
2404called to process the operand(s). For example, in <tt>X86CodeEmitter.cpp</tt>,
2405for the <tt>X86II::AddRegFrm</tt> case, the first data emitted
2406(by <tt>emitByte</tt>) is the opcode added to the register operand. Then an
2407object representing the machine operand, <tt>MO1</tt>, is extracted. The helper
2408methods such as <tt>isImmediate</tt>,
Chris Lattner78975382008-11-11 19:30:41 +00002409<tt>isGlobalAddress</tt>, <tt>isExternalSymbol</tt>, <tt>isConstantPoolIndex</tt>, and
Bill Wendling4a2bca82009-04-05 00:41:19 +00002410<tt>isJumpTableIndex</tt> determine the operand
2411type. (<tt>X86CodeEmitter.cpp</tt> also has private methods such
2412as <tt>emitConstant</tt>, <tt>emitGlobalAddress</tt>,
Chris Lattner78975382008-11-11 19:30:41 +00002413<tt>emitExternalSymbolAddress</tt>, <tt>emitConstPoolAddress</tt>,
Bill Wendling4a2bca82009-04-05 00:41:19 +00002414and <tt>emitJumpTableAddress</tt> that emit the data into the output stream.)
2415</p>
Chris Lattner78975382008-11-11 19:30:41 +00002416
2417<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002418<pre>
2419case X86II::AddRegFrm:
Chris Lattner78975382008-11-11 19:30:41 +00002420 MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg()));
2421
2422 if (CurOp != NumOps) {
2423 const MachineOperand &amp;MO1 = MI.getOperand(CurOp++);
2424 unsigned Size = X86InstrInfo::sizeOfImm(Desc);
2425 if (MO1.isImmediate())
2426 emitConstant(MO1.getImm(), Size);
2427 else {
2428 unsigned rt = Is64BitMode ? X86::reloc_pcrel_word
2429 : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word);
2430 if (Opcode == X86::MOV64ri)
2431 rt = X86::reloc_absolute_dword; // FIXME: add X86II flag?
2432 if (MO1.isGlobalAddress()) {
2433 bool NeedStub = isa&lt;Function&gt;(MO1.getGlobal());
2434 bool isLazy = gvNeedsLazyPtr(MO1.getGlobal());
2435 emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0,
2436 NeedStub, isLazy);
2437 } else if (MO1.isExternalSymbol())
2438 emitExternalSymbolAddress(MO1.getSymbolName(), rt);
2439 else if (MO1.isConstantPoolIndex())
2440 emitConstPoolAddress(MO1.getIndex(), rt);
2441 else if (MO1.isJumpTableIndex())
2442 emitJumpTableAddress(MO1.getIndex(), rt);
2443 }
2444 }
2445 break;
2446</pre>
2447</div>
Chris Lattner78975382008-11-11 19:30:41 +00002448
Bill Wendling4a2bca82009-04-05 00:41:19 +00002449<p>
2450In the previous example, <tt>XXXCodeEmitter.cpp</tt> uses the
2451variable <tt>rt</tt>, which is a RelocationType enum that may be used to
2452relocate addresses (for example, a global address with a PIC base offset). The
2453<tt>RelocationType</tt> enum for that target is defined in the short
2454target-specific <tt>XXXRelocations.h</tt> file. The <tt>RelocationType</tt> is used by
2455the <tt>relocate</tt> method defined in <tt>XXXJITInfo.cpp</tt> to rewrite
2456addresses for referenced global symbols.
2457</p>
2458
2459<p>
2460For example, <tt>X86Relocations.h</tt> specifies the following relocation types
2461for the X86 addresses. In all four cases, the relocated value is added to the
2462value already in memory. For <tt>reloc_pcrel_word</tt>
2463and <tt>reloc_picrel_word</tt>, there is an additional initial adjustment.
2464</p>
Chris Lattner78975382008-11-11 19:30:41 +00002465
2466<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002467<pre>
2468enum RelocationType {
2469 reloc_pcrel_word = 0, // add reloc value after adjusting for the PC loc
2470 reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base
Chris Lattner78975382008-11-11 19:30:41 +00002471 reloc_absolute_word = 2, // absolute relocation; no additional adjustment
2472 reloc_absolute_dword = 3 // absolute relocation; no additional adjustment
2473};
2474</pre>
2475</div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002476
2477</div>
2478
Chris Lattner78975382008-11-11 19:30:41 +00002479<!-- ======================================================================= -->
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002480<h3>
Chris Lattner78975382008-11-11 19:30:41 +00002481 <a name="targetJITInfo">Target JIT Info</a>
NAKAMURA Takumi05d02652011-04-18 23:59:50 +00002482</h3>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002483
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002484<div>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002485
2486<p>
2487<tt>XXXJITInfo.cpp</tt> implements the JIT interfaces for target-specific
2488code-generation activities, such as emitting machine code and stubs. At minimum,
2489a target-specific version of <tt>XXXJITInfo</tt> implements the following:
2490</p>
2491
Chris Lattner78975382008-11-11 19:30:41 +00002492<ul>
Bill Wendling4a2bca82009-04-05 00:41:19 +00002493<li><tt>getLazyResolverFunction</tt> &mdash; Initializes the JIT, gives the
2494 target a function that is used for compilation.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002495
Bill Wendling4a2bca82009-04-05 00:41:19 +00002496<li><tt>emitFunctionStub</tt> &mdash; Returns a native function with a specified
2497 address for a callback function.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002498
Bill Wendling4a2bca82009-04-05 00:41:19 +00002499<li><tt>relocate</tt> &mdash; Changes the addresses of referenced globals, based
2500 on relocation types.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002501
Bill Wendling4a2bca82009-04-05 00:41:19 +00002502<li>Callback function that are wrappers to a function stub that is used when the
2503 real target is not initially known.</li>
Chris Lattner78975382008-11-11 19:30:41 +00002504</ul>
2505
Bill Wendling4a2bca82009-04-05 00:41:19 +00002506<p>
2507<tt>getLazyResolverFunction</tt> is generally trivial to implement. It makes the
2508incoming parameter as the global <tt>JITCompilerFunction</tt> and returns the
Chris Lattner78975382008-11-11 19:30:41 +00002509callback function that will be used a function wrapper. For the Alpha target
Bill Wendling4a2bca82009-04-05 00:41:19 +00002510(in <tt>AlphaJITInfo.cpp</tt>), the <tt>getLazyResolverFunction</tt>
2511implementation is simply:
2512</p>
Chris Lattner78975382008-11-11 19:30:41 +00002513
2514<div class="doc_code">
Bill Wendling4a2bca82009-04-05 00:41:19 +00002515<pre>
2516TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction(
2517 JITCompilerFn F) {
Chris Lattner78975382008-11-11 19:30:41 +00002518 JITCompilerFunction = F;
2519 return AlphaCompilationCallback;
2520}
2521</pre>
2522</div>
Chris Lattner78975382008-11-11 19:30:41 +00002523
Bill Wendling4a2bca82009-04-05 00:41:19 +00002524<p>
2525For the X86 target, the <tt>getLazyResolverFunction</tt> implementation is a
2526little more complication, because it returns a different callback function for
2527processors with SSE instructions and XMM registers.
2528</p>
2529
2530<p>
2531The callback function initially saves and later restores the callee register
2532values, incoming arguments, and frame and return address. The callback function
2533needs low-level access to the registers or stack, so it is typically implemented
2534with assembler.
2535</p>
2536
Misha Brukman8eb67192004-09-06 22:58:13 +00002537</div>
2538
NAKAMURA Takumif5af6ad2011-04-23 00:30:22 +00002539</div>
2540
Misha Brukman8eb67192004-09-06 22:58:13 +00002541<!-- *********************************************************************** -->
2542
2543<hr>
2544<address>
2545 <a href="http://jigsaw.w3.org/css-validator/check/referer"><img
Misha Brukman44408702008-12-11 17:34:48 +00002546 src="http://jigsaw.w3.org/css-validator/images/vcss-blue" alt="Valid CSS"></a>
Misha Brukman8eb67192004-09-06 22:58:13 +00002547 <a href="http://validator.w3.org/check/referer"><img
Misha Brukman44408702008-12-11 17:34:48 +00002548 src="http://www.w3.org/Icons/valid-html401-blue" alt="Valid HTML 4.01"></a>
Misha Brukman8eb67192004-09-06 22:58:13 +00002549
Chris Lattner78975382008-11-11 19:30:41 +00002550 <a href="http://www.woo.com">Mason Woo</a> and <a href="http://misha.brukman.net">Misha Brukman</a><br>
NAKAMURA Takumib9a33632011-04-09 02:13:37 +00002551 <a href="http://llvm.org/">The LLVM Compiler Infrastructure</a>
Misha Brukman8eb67192004-09-06 22:58:13 +00002552 <br>
2553 Last modified: $Date$
2554</address>
2555
2556</body>
2557</html>