| blob | 39ac34b3d7790fd7f69e39de8ae14c9922be06a9 |
3 <html>
4 <head>
8 </head>
10 <body>
12 <h1>
13 Writing an LLVM Compiler Backend
14 </h1>
16 <ol>
18 <ul>
23 </ul>
27 <ul>
31 </ul></li>
33 <ul>
37 </ul></li>
39 <ul>
41 <ul>
46 </ul></li>
48 </ul></li>
52 <ul>
55 </ul></li>
56 </ol>
61 </div>
63 <!-- *********************************************************************** -->
64 <h2>
66 </h2>
67 <!-- *********************************************************************** -->
69 <div>
71 <p>
72 This document describes techniques for writing compiler backends that convert
73 the LLVM Intermediate Representation (IR) to code for a specified machine or
74 other languages. Code intended for a specific machine can take the form of
75 either assembly code or binary code (usable for a JIT compiler).
76 </p>
78 <p>
79 The backend of LLVM features a target-independent code generator that may create
80 output for several types of target CPUs — including X86, PowerPC, Alpha,
81 and SPARC. The backend may also be used to generate code targeted at SPUs of the
82 Cell processor or GPUs to support the execution of compute kernels.
83 </p>
85 <p>
86 The document focuses on existing examples found in subdirectories
88 document focuses on the example of creating a static compiler (one that emits
89 text assembly) for a SPARC target, because SPARC has fairly standard
90 characteristics, such as a RISC instruction set and straightforward calling
91 conventions.
92 </p>
94 <h3>
96 </h3>
98 <div>
100 <p>
101 The audience for this document is anyone who needs to write an LLVM backend to
102 generate code for a specific hardware or software target.
103 </p>
105 </div>
107 <h3>
109 </h3>
111 <div>
113 <p>
114 These essential documents must be read before reading this document:
115 </p>
117 <ul>
123 (classes and code generation algorithms) for translating the LLVM internal
124 representation into machine code for a specified target. Pay particular
125 attention to the descriptions of code generation stages: Instruction
126 Selection, Scheduling and Formation, SSA-based Optimization, Register
127 Allocation, Prolog/Epilog Code Insertion, Late Machine Code Optimizations,
128 and Code Emission.</li>
133 support LLVM code generation. TableGen processes input from a target
135 used for code generation.</li>
139 several SelectionDAG processing steps.</li>
140 </ul>
142 <p>
143 To follow the SPARC examples in this document, have a copy of
147 Reference Manual</a></i>. For more about the GNU Assembler format
151 machine dependent features.
152 </p>
154 </div>
156 <h3>
158 </h3>
160 <div>
162 <p>
163 To write a compiler backend for LLVM that converts the LLVM IR to code for a
164 specified target (machine or other language), follow these steps:
165 </p>
167 <ul>
168 <li>Create a subclass of the TargetMachine class that describes characteristics
169 of your target machine. Copy existing examples of specific TargetMachine
170 class and header files; for example, start with
172 change the file names for your target. Similarly, change code that
175 <li>Describe the register set of the target. Use TableGen to generate code for
176 register definition, register aliases, and register classes from a
178 additional code for a subclass of the TargetRegisterInfo class that
179 represents the class register file data used for register allocation and
180 also describes the interactions between registers.</li>
182 <li>Describe the instruction set of the target. Use TableGen to generate code
183 for target-specific instructions from target-specific versions of
185 write additional code for a subclass of the TargetInstrInfo class to
186 represent machine instructions supported by the target machine. </li>
188 <li>Describe the selection and conversion of the LLVM IR from a Directed Acyclic
189 Graph (DAG) representation of instructions to native target-specific
190 instructions. Use TableGen to generate code that matches patterns and
191 selects instructions based on additional information in a target-specific
194 to perform pattern matching and DAG-to-DAG instruction selection. Also write
196 data types that are not supported natively in a SelectionDAG. </li>
198 <li>Write code for an assembly printer that converts LLVM IR to a GAS format for
199 your target machine. You should add assembly strings to the instructions
201 should also write code for a subclass of AsmPrinter that performs the
202 LLVM-to-assembly conversion and a trivial subclass of TargetAsmInfo.</li>
204 <li>Optionally, add support for subtargets (i.e., variants with different
205 capabilities). You should also write code for a subclass of the
209 <li>Optionally, add JIT support and create a machine code emitter (subclass of
210 TargetJITInfo) that is used to emit binary code directly into memory. </li>
211 </ul>
213 <p>
215 then implement them later. Initially, you may not know which private members
216 that the class will need and which components will need to be subclassed.
217 </p>
219 </div>
221 <h3>
223 </h3>
225 <div>
227 <p>
228 To actually create your compiler backend, you need to create and modify a few
229 files. The absolute minimum is discussed here. But to actually use the LLVM
230 target-independent code generator, you must perform the steps described in
232 Target-Independent Code Generator</a> document.
233 </p>
235 <p>
237 the files related to your target. If your target is called "Dummy," create the
239 </p>
241 <p>
242 In this new
251 target).
252 </p>
254 <p>
258 </p>
260 <p>
261 To make your target actually do something, you need to implement a subclass of
265 target independent code generator, you should do what all current machine
268 </p>
270 <p>
271 To get LLVM to actually build and link your target, you need to add it to
275 target to the lists there (some creativity required), and then
278 </p>
280 </div>
282 </div>
284 <!-- *********************************************************************** -->
285 <h2>
287 </h2>
288 <!-- *********************************************************************** -->
290 <div>
292 <p>
295 class should be specialized by a concrete target class that implements the
299 processes numerous command-line options.
300 </p>
302 <p>
305 should name the files that you create to reflect your specific target. For
308 </p>
310 <p>
318 characteristics, such as data type size and alignment requirements.
319 </p>
321 <p>
322 For instance, for the SPARC target, the header file
325 </p>
328 <pre>
329 namespace llvm {
331 class Module;
333 class SparcTargetMachine : public LLVMTargetMachine {
334 const TargetData DataLayout; // Calculates type size & alignment
335 SparcSubtarget Subtarget;
336 SparcInstrInfo InstrInfo;
337 TargetFrameInfo FrameInfo;
339 protected:
340 virtual const TargetAsmInfo *createTargetAsmInfo() const;
342 public:
345 virtual const SparcInstrInfo *getInstrInfo() const {return &InstrInfo; }
346 virtual const TargetFrameInfo *getFrameInfo() const {return &FrameInfo; }
347 virtual const TargetSubtarget *getSubtargetImpl() const{return &Subtarget; }
348 virtual const TargetRegisterInfo *getRegisterInfo() const {
349 return &InstrInfo.getRegisterInfo();
350 }
351 virtual const TargetData *getTargetData() const { return &DataLayout; }
352 static unsigned getModuleMatchQuality(const Module &M);
354 // Pass Pipeline Configuration
355 virtual bool addInstSelector(PassManagerBase &PM, bool Fast);
356 virtual bool addPreEmitPass(PassManagerBase &PM, bool Fast);
357 };
359 } // end namespace llvm
360 </pre>
361 </div>
363 <ul>
369 </ul>
373 <ul>
376 </ul>
378 <p>
381 machine, including characteristics such as pointer size, alignment, and
382 endianness. For example, the constructor for SparcTargetMachine contains the
383 following:
384 </p>
387 <pre>
389 : DataLayout("E-p:32:32-f128:128:128"),
390 Subtarget(M, FS), InstrInfo(Subtarget),
392 }
393 </pre>
394 </div>
398 <ul>
403 preferred alignment. If only two figures follow "<tt>p:</tt>", then the
404 first value is pointer size, and the second value is both ABI and preferred
405 alignment.</li>
410 followed by ABI alignment and preferred alignment. "<tt>f</tt>" is followed
411 by three values: the first indicates the size of a long double, then ABI
412 alignment, and then ABI preferred alignment.</li>
413 </ul>
415 </div>
417 <!-- *********************************************************************** -->
418 <h2>
420 </h2>
421 <!-- *********************************************************************** -->
423 <div>
425 <p>
427 what other LLVM tools use to be able to lookup and use your target at
429 there are helper templates which should take care of the work for you.</p>
431 <p>
433 represent the target during registration. Then, in the target's TargetInfo
434 library, the target should define that object and use
435 the <tt>RegisterTarget</tt> template to register the target. For example, the Sparc registration code looks like this:
436 </p>
439 <pre>
440 Target llvm::TheSparcTarget;
442 extern "C" void LLVMInitializeSparcTargetInfo() {
445 }
446 </pre>
447 </div>
449 <p>
451 target triple. In addition, most targets will also register additional features
452 which are available in separate libraries. These registration steps are
453 separate, because some clients may wish to only link in some parts of the target
454 -- the JIT code generator does not require the use of the assembler printer, for
455 example. Here is an example of registering the Sparc assembly printer:
456 </p>
459 <pre>
460 extern "C" void LLVMInitializeSparcAsmPrinter() {
462 }
463 </pre>
464 </div>
466 <p>
467 For more information, see
469 </p>
471 </div>
473 <!-- *********************************************************************** -->
474 <h2>
476 </h2>
477 <!-- *********************************************************************** -->
479 <div>
481 <p>
482 You should describe a concrete target-specific class that represents the
485 file data that is used for register allocation. It also describes the
486 interactions between registers.
487 </p>
489 <p>
490 You also need to define register classes to categorize related registers. A
491 register class should be added for groups of registers that are all treated the
492 same way for some instruction. Typical examples are register classes for
493 integer, floating-point, or vector registers. A register allocator allows an
494 instruction to use any register in a specified register class to perform the
495 instruction in a similar manner. Register classes allocate virtual registers to
496 instructions from these sets, and register classes let the target-independent
497 register allocator automatically choose the actual registers.
498 </p>
500 <p>
501 Much of the code for registers, including register definition, register aliases,
506 </p>
508 <!-- ======================================================================= -->
509 <h3>
511 </h3>
513 <div>
515 <p>
521 specify any aliases.
522 </p>
525 <pre>
527 string Namespace = "";
528 string AsmName = n;
529 string Name = n;
530 int SpillSize = 0;
531 int SpillAlignment = 0;
535 }
536 </pre>
537 </div>
539 <p>
541 definitions that utilize the Register class, such as:
542 </p>
545 <pre>
547 </pre>
548 </div>
550 <p>
553 information writer to identify a register. For register
555 different modes: the first element is for X86-64, the second for exception
557 that indicates the gcc number is undefined, and -2 indicates the register number
558 is invalid for this mode.
559 </p>
561 <p>
564 </p>
567 <pre>
568 static const unsigned GR8[] = { X86::AL, ... };
570 const unsigned AL_AliasSet[] = { X86::AX, X86::EAX, X86::RAX, 0 };
572 const TargetRegisterDesc RegisterDescriptors[] = {
573 ...
575 </pre>
576 </div>
578 <p>
582 </p>
585 <pre>
586 struct TargetRegisterDesc {
587 const char *AsmName; // Assembly language name for the register
588 const char *Name; // Printable name for the reg (for debugging)
589 const unsigned *AliasSet; // Register Alias Set
590 const unsigned *SubRegs; // Sub-register set
591 const unsigned *ImmSubRegs; // Immediate sub-register set
592 const unsigned *SuperRegs; // Super-register set
593 };</pre>
594 </div>
596 <p>
601 example, other definitions establish the registers "<tt>AX</tt>",
604 set.
605 </p>
607 <p>
612 </p>
615 <pre>
616 class RegisterWithSubRegs<string n,
618 let SubRegs = subregs;
619 }
620 </pre>
621 </div>
623 <p>
627 numbers, which is a feature common to these subclasses. Note the use of
630 </p>
633 <pre>
636 let Namespace = "SP";
637 }
638 // Ri - 32-bit integer registers
641 let Num = num;
642 }
643 // Rf - 32-bit floating-point registers
646 let Num = num;
647 }
648 // Rd - Slots in the FP register file for 64-bit
649 floating-point values.
652 let Num = num;
653 let SubRegs = subregs;
654 }
655 </pre>
656 </div>
658 <p>
661 </p>
664 <pre>
668 ...
673 ...
678 </pre>
679 </div>
681 <p>
683 double-precision floating-point registers that are aliases for pairs of
684 single-precision floating-point sub-registers. In addition to aliases, the
685 sub-register and super-register relationships of the defined register are in
686 fields of a register's TargetRegisterDesc.
687 </p>
689 </div>
691 <!-- ======================================================================= -->
692 <h3>
694 </h3>
696 <div>
698 <p>
700 define an object that represents a group of related registers and also defines
701 the default allocation order of the registers. A target description file
703 classes using the following class:
704 </p>
707 <pre>
708 class RegisterClass<string namespace,
711 string Namespace = namespace;
713 int Size = 0; // spill size, in bits; zero lets tblgen pick the size
714 int Alignment = alignment;
716 // 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;
722 // for register classes that are subregisters of this class
725 code MethodProtos = [{}]; // to insert arbitrary code
726 code MethodBodies = [{}];
727 }
728 </pre>
729 </div>
733 <ul>
743 data in different configurations. For example a register that can process a
748 alignment required of the registers when they are stored or loaded to
749 memory.</li>
754 register allocator.</li>
755 </ul>
757 <p>
760 classes, the first argument defines the namespace with the string
763 a group of 16 double-precision registers
766 code into generated output.
767 </p>
770 <pre>
772 [F0, F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15,
773 F16, F17, F18, F19, F20, F21, F22, F23, F24, F25, F26, F27, F28, F29, F30, F31]>;
776 [D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15]>;
777
779 [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 ]> {
791 let MethodProtos = [{
792 iterator allocation_order_end(const MachineFunction &MF) const;
793 }];
794 let MethodBodies = [{
795 IntRegsClass::iterator
796 IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
797 return end() - 10 // Don't allocate special registers
798 -1;
799 }
800 }];
801 }
802 </pre>
803 </div>
805 <p>
807 that are intended for inclusion in other source code that you write.
809 which should be included in the header file for the implementation of the SPARC
813 base. It also specifies types, based upon the defined register
815 </p>
817 <p>
820 register implementation. The code below shows only the generated integer
821 registers and associated register classes. The order of registers
823 the target description file. Take special note of the use
827 </p>
830 <pre> // IntRegs Register Class...
831 static const unsigned IntRegs[] = {
832 SP::L0, SP::L1, SP::L2, SP::L3, SP::L4, SP::L5,
833 SP::L6, SP::L7, SP::I0, SP::I1, SP::I2, SP::I3,
834 SP::I4, SP::I5, SP::O0, SP::O1, SP::O2, SP::O3,
835 SP::O4, SP::O5, SP::O7, SP::G1, SP::G2, SP::G3,
836 SP::G4, SP::O6, SP::I6, SP::I7, SP::G0, SP::G5,
837 SP::G6, SP::G7,
838 };
840 // IntRegsVTs Register Class Value Types...
841 static const MVT::ValueType IntRegsVTs[] = {
842 MVT::i32, MVT::Other
843 };
845 namespace SP { // Register class instances
846 DFPRegsClass DFPRegsRegClass;
847 FPRegsClass FPRegsRegClass;
848 IntRegsClass IntRegsRegClass;
849 ...
850 // IntRegs Sub-register Classess...
851 static const TargetRegisterClass* const IntRegsSubRegClasses [] = {
852 NULL
853 };
854 ...
855 // IntRegs Super-register Classess...
856 static const TargetRegisterClass* const IntRegsSuperRegClasses [] = {
857 NULL
858 };
859 ...
860 // IntRegs Register Class sub-classes...
861 static const TargetRegisterClass* const IntRegsSubclasses [] = {
862 NULL
863 };
864 ...
865 // IntRegs Register Class super-classes...
866 static const TargetRegisterClass* const IntRegsSuperclasses [] = {
867 NULL
868 };
869 ...
870 IntRegsClass::iterator
871 IntRegsClass::allocation_order_end(const MachineFunction &MF) const {
872 return end()-10 // Don't allocate special registers
873 -1;
874 }
876 IntRegsClass::IntRegsClass() : TargetRegisterClass(IntRegsRegClassID,
877 IntRegsVTs, IntRegsSubclasses, IntRegsSuperclasses, IntRegsSubRegClasses,
879 }
880 </pre>
881 </div>
883 </div>
885 <!-- ======================================================================= -->
886 <h3>
889 </h3>
891 <div>
893 <p>
897 overridden. Here is a list of functions that are overridden for the SPARC
899 </p>
901 <ul>
903 in the order of the desired callee-save stack frame offset.</li>
906 register numbers, indicating if a particular register is unavailable.</li>
909 a dedicated frame pointer register.</li>
912 destroy pseudo instructions are used, this can be called to eliminate
913 them.</li>
916 instructions that may use them.</li>
921 </ul>
923 </div>
925 </div>
927 <!-- *********************************************************************** -->
928 <h2>
930 </h2>
932 <!-- *********************************************************************** -->
933 <div>
935 <p>
936 During the early stages of code generation, the LLVM IR code is converted to a
939 requirements, and operation properties. For example, is an operation
940 commutative, does an operation load from memory. The various operation node
943 </p>
945 <p>
947 generate much of the code for instruction definition:
948 </p>
950 <ul>
962 target-specific instructions.</li>
965 templates, condition codes, and instructions of an instruction set. For
966 architecture modifications, a different file name may be used. For example,
969 </ul>
971 <p>
974 input files, but its contents are only directly important for subtargets.
975 </p>
977 <p>
979 represents machine instructions supported by a target machine.
981 each of which describes one instruction. An instruction descriptor defines:</p>
983 <ul>
993 </ul>
995 <p>
997 for more complex instruction classes.
998 </p>
1001 <pre>class Instruction {
1002 string Namespace = "";
1003 dag OutOperandList; // An dag containing the MI def operand list.
1004 dag InOperandList; // An dag containing the MI use operand list.
1005 string AsmString = ""; // The .s format to print the instruction with.
1010 ... remainder not shown for space ...
1011 }
1012 </pre>
1013 </div>
1015 <p>
1017 representing a target-specific instruction that is defined
1019 instructions from the architecture manual of the target machine (such as the
1020 SPARC Architecture Manual for the SPARC target).
1021 </p>
1023 <p>
1024 A single instruction from the architecture manual is often modeled as multiple
1025 target instructions, depending upon its operands. For example, a manual might
1026 describe an add instruction that takes a register or an immediate operand. An
1029 </p>
1031 <p>
1032 You should define a class for each instruction category and define each opcode
1033 as a subclass of the category with appropriate parameters such as the fixed
1034 binary encoding of opcodes and extended opcodes. You should map the register
1035 bits to the bits of the instruction in which they are encoded (for the
1036 JIT). Also you should specify how the instruction should be printed when the
1037 automatic assembly printer is used.
1038 </p>
1040 <p>
1041 As is described in the SPARC Architecture Manual, Version 8, there are three
1044 high bits of a register) instructions. Format 3 is for other instructions.
1045 </p>
1047 <p>
1050 classes are specified for more precise formats: for example
1056 synthetic SPARC instructions.
1057 </p>
1059 <p>
1065 operation value for this category of operation. The second parameter
1070 </p>
1074 "ld [$addr], $dst",
1075 [(set IntRegs:$dst, (load ADDRrr:$addr))]>;
1076 </pre>
1077 </div>
1079 <p>
1080 The fourth parameter is the input source, which uses the address
1082 </p>
1086 let PrintMethod = "printMemOperand";
1087 let MIOperandInfo = (ops IntRegs, IntRegs);
1088 }
1089 </pre>
1090 </div>
1092 <p>
1093 The fifth parameter is a string that is used by the assembly printer and can be
1094 left as an empty string until the assembly printer interface is implemented. The
1095 sixth and final parameter is the pattern used to match the instruction during
1096 the SelectionDAG Select Phase described in
1098 Target-Independent Code Generator</a>). This parameter is detailed in the next
1100 </p>
1102 <p>
1103 Instruction class definitions are not overloaded for different operand types, so
1104 separate versions of instructions are needed for register, memory, or immediate
1105 value operands. For example, to perform a Load Integer instruction for a Word
1106 from an immediate operand to a register, the following instruction class is
1107 defined:
1108 </p>
1112 "ld [$addr], $dst",
1113 [(set IntRegs:$dst, (load ADDRri:$addr))]>;
1114 </pre>
1115 </div>
1117 <p>
1118 Writing these definitions for so many similar instructions can involve a lot of
1120 creation of templates to define several instruction classes at once (using
1124 </p>
1129 (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
1130 !strconcat(OpcStr, " $b, $c, $dst"),
1131 [(set IntRegs:$dst, (OpNode IntRegs:$b, IntRegs:$c))]>;
1133 (outs IntRegs:$dst), (ins IntRegs:$b, i32imm:$c),
1134 !strconcat(OpcStr, " $b, $c, $dst"),
1135 [(set IntRegs:$dst, (OpNode IntRegs:$b, simm13:$c))]>;
1136 }
1137 </pre>
1138 </div>
1140 <p>
1144 </p>
1147 <pre>
1150 </pre>
1151 </div>
1153 <p>
1155 are referenced by branch instructions. The following definitions
1159 than' condition for floats.
1160 </p>
1163 <pre>
1167 ...
1171 ...
1172 </pre>
1173 </div>
1175 <p>
1180 </p>
1182 <!-- ======================================================================= -->
1183 <h3>
1185 </h3>
1187 <div>
1189 <p>
1190 The code generator backend maps instruction operands to fields in the
1191 instruction. Operands are assigned to unbound fields in the instruction in the
1192 order they are defined. Fields are bound when they are assigned a value. For
1195 </p>
1198 <pre>
1200 (outs IntRegs:$dst), (ins IntRegs:$b, IntRegs:$c),
1201 "xnor $b, $c, $dst",
1202 [(set IntRegs:$dst, (not (xor IntRegs:$b, IntRegs:$c)))]>;
1203 </pre>
1204 </div>
1206 <p>
1209 </p>
1212 <pre>
1215 let Namespace = "SP";
1218 dag OutOperandList = outs;
1219 dag InOperandList = ins;
1220 let AsmString = asmstr;
1221 let Pattern = pattern;
1222 }
1223 </pre>
1224 </div>
1229 <pre>
1239 }
1240 </pre>
1241 </div>
1243 <p>
1247 </p>
1250 <pre>
1255 let op = opVal;
1256 let op3 = op3val;
1260 }
1261 </pre>
1262 </div>
1264 <p>
1270 </p>
1272 </div>
1274 <!-- ======================================================================= -->
1275 <h3>
1278 </h3>
1280 <div>
1282 <p>
1286 overridden. Here's a list of functions that are overridden for the SPARC
1288 </p>
1290 <ul>
1292 a direct load from a stack slot, return the register number of the
1296 a direct store to a stack slot, return the register number of the
1300 registers.</li>
1303 slot.</li>
1306 slot.</li>
1313 load or store instruction for the specified operand(s).</li>
1314 </ul>
1316 </div>
1318 <!-- ======================================================================= -->
1319 <h3>
1321 </h3>
1322 <div>
1324 <p>
1325 Performance can be improved by combining instructions or by eliminating
1329 a machine basic block (MBB) for opportunities for improvement, such as branch
1334 instructions.
1335 </p>
1337 <p>
1341 implementation is shown below.
1342 </p>
1346 <ul>
1348 examined.</li>
1352 the destination.</li>
1358 operands to evaluate a condition for a conditional branch.</li>
1359 </ul>
1361 <p>
1362 In the simplest case, if a block ends without a branch, then it falls through to
1366 function parameters and the code for the simplest case.
1367 </p>
1373 {
1374 MachineBasicBlock::iterator I = MBB.end();
1375 if (I == MBB.begin() || !isUnpredicatedTerminator(--I))
1376 return false;
1377 </pre>
1378 </div>
1380 <p>
1381 If a block ends with a single unconditional branch instruction, then
1384 </p>
1387 <pre>
1388 if (LastOpc == ARM::B || LastOpc == ARM::tB) {
1390 return false;
1391 }
1392 </pre>
1393 </div>
1395 <p>
1396 If a block ends with two unconditional branches, then the second branch is never
1397 reached. In that situation, as shown below, remove the last branch instruction
1399 </p>
1402 <pre>
1403 if ((SecondLastOpc == ARM::B || SecondLastOpc==ARM::tB) &&
1404 (LastOpc == ARM::B || LastOpc == ARM::tB)) {
1406 I = LastInst;
1407 I->eraseFromParent();
1408 return false;
1409 }
1410 </pre>
1411 </div>
1413 <p>
1414 A block may end with a single conditional branch instruction that falls through
1415 to successor block if the condition evaluates to false. In that case,
1419 </p>
1422 <pre>
1423 if (LastOpc == ARM::Bcc || LastOpc == ARM::tBcc) {
1424 // Block ends with fall-through condbranch.
1428 return false;
1429 }
1430 </pre>
1431 </div>
1433 <p>
1434 If a block ends with both a conditional branch and an ensuing unconditional
1436 branch destination (assuming it corresponds to a conditional evaluation of
1441 </p>
1444 <pre>
1445 unsigned SecondLastOpc = SecondLastInst->getOpcode();
1447 if ((SecondLastOpc == ARM::Bcc && LastOpc == ARM::B) ||
1448 (SecondLastOpc == ARM::tBcc && LastOpc == ARM::tB)) {
1453 return false;
1454 }
1455 </pre>
1456 </div>
1458 <p>
1459 For the last two cases (ending with a single conditional branch or ending with
1460 one conditional and one unconditional branch), the operands returned in
1462 create new branches or perform other operations. An implementation
1465 </p>
1467 <p>
1471 return true if it encounters a terminator it cannot handle, such as an indirect
1472 branch.
1473 </p>
1475 </div>
1477 </div>
1479 <!-- *********************************************************************** -->
1480 <h2>
1482 </h2>
1483 <!-- *********************************************************************** -->
1485 <div>
1487 <p>
1490 instructions. During code generation, instruction selection passes are performed
1491 to convert non-native DAG instructions into native target-specific
1493 match patterns and perform DAG-to-DAG instruction selection. Optionally, a pass
1495 operations for branch instructions. Later, the code in
1498 </p>
1500 <p>
1501 TableGen generates code for instruction selection using the following target
1502 description input files:
1503 </p>
1505 <ul>
1511 conventions for the target architecture, and it generates
1514 </ul>
1516 <p>
1517 The implementation of an instruction selection pass must include a header that
1520 selection pass into the queue of passes to run.
1521 </p>
1523 <p>
1528 SelectionDAG Instruction Selection Process</a>.
1529 </p>
1531 <p>
1532 To describe instruction selector behavior, you should add patterns for lowering
1536 the last parameter describes a pattern with the store DAG operator.
1537 </p>
1540 <pre>
1543 </pre>
1544 </div>
1546 <p>
1549 </p>
1552 <pre>
1554 </pre>
1555 </div>
1557 <p>
1559 function defined in an implementation of the Instructor Selector (such
1561 </p>
1563 <p>
1565 defined below:
1566 </p>
1569 <pre>
1570 def store : PatFrag<(ops node:$val, node:$ptr),
1571 (st node:$val, node:$ptr), [{
1574 ST->getAddressingMode() == ISD::UNINDEXED;
1575 return false;
1576 }]>;
1577 </pre>
1578 </div>
1580 <p>
1585 </p>
1588 <pre>
1589 SDNode *SelectCode(SDValue N) {
1590 ...
1592 switch (N.getOpcode()) {
1593 case ISD::STORE: {
1594 switch (NVT) {
1595 default:
1596 return Select_ISD_STORE(N);
1597 break;
1598 }
1599 break;
1600 }
1601 ...
1602 </pre>
1603 </div>
1605 <p>
1610 instruction.
1611 </p>
1614 <pre>
1615 SDNode *Select_ISD_STORE(const SDValue &N) {
1616 SDValue Chain = N.getOperand(0);
1617 if (Predicate_store(N.getNode())) {
1618 SDValue N1 = N.getOperand(1);
1619 SDValue N2 = N.getOperand(2);
1620 SDValue CPTmp0;
1621 SDValue CPTmp1;
1623 // Pattern: (st:void IntRegs:i32:$src,
1625 // Emits: (STrr:void ADDRrr:i32:$addr, IntRegs:i32:$src)
1627 if (SelectADDRrr(N, N2, CPTmp0, CPTmp1) &&
1630 return Emit_22(N, SP::STrr, CPTmp0, CPTmp1);
1631 }
1632 ...
1633 </pre>
1634 </div>
1636 <!-- ======================================================================= -->
1637 <h3>
1639 </h3>
1641 <div>
1643 <p>
1644 The Legalize phase converts a DAG to use types and operations that are natively
1645 supported by the target. For natively unsupported types and operations, you need
1646 to add code to the target-specific XXXTargetLowering implementation to convert
1647 unsupported types and operations to supported ones.
1648 </p>
1650 <p>
1653 register classes are associated with them. The code for the register classes are
1656 constructor for the SparcTargetLowering class (in
1658 </p>
1661 <pre>
1662 addRegisterClass(MVT::i32, SP::IntRegsRegisterClass);
1663 addRegisterClass(MVT::f32, SP::FPRegsRegisterClass);
1664 addRegisterClass(MVT::f64, SP::DFPRegsRegisterClass);
1665 </pre>
1666 </div>
1668 <p>
1672 native support, add a callback to the constructor for the XXXTargetLowering
1673 class, so the instruction selection process knows what to do. The TargetLowering
1675 </p>
1677 <ul>
1691 </ul>
1693 <p>
1697 to see what methods are specifically supported.
1698 </p>
1700 <p>
1701 These callbacks are used to determine that an operation does or does not work
1702 with a specified type (or types). And in all cases, the third parameter is
1706 </p>
1708 <!-- _______________________________________________________________________ -->
1709 <h4>
1711 </h4>
1713 <div>
1715 <p>
1716 For an operation without native support for a given type, the specified type may
1717 be promoted to a larger type that is supported. For example, SPARC does not
1721 </p>
1724 <pre>
1725 setLoadExtAction(ISD::SEXTLOAD, MVT::i1, Promote);
1726 </pre>
1727 </div>
1729 </div>
1731 <!-- _______________________________________________________________________ -->
1732 <h4>
1734 </h4>
1736 <div>
1738 <p>
1739 For a type without native support, a value may need to be broken down further,
1740 rather than promoted. For an operation without native support, a combination of
1741 other operations may be used to similar effect. In SPARC, the floating-point
1742 sine and cosine trig operations are supported by expansion to other operations,
1745 </p>
1748 <pre>
1749 setOperationAction(ISD::FSIN, MVT::f32, Expand);
1750 setOperationAction(ISD::FCOS, MVT::f32, Expand);
1751 </pre>
1752 </div>
1754 </div>
1756 <!-- _______________________________________________________________________ -->
1757 <h4>
1759 </h4>
1761 <div>
1763 <p>
1764 For some operations, simple type promotion or operation expansion may be
1765 insufficient. In some cases, a special intrinsic function must be implemented.
1766 </p>
1768 <p>
1769 For example, a constant value may require special treatment, or an operation may
1770 require spilling and restoring registers in the stack and working with register
1771 allocators.
1772 </p>
1774 <p>
1776 conversion from a floating point value to a signed integer, first the
1778 parameter:
1779 </p>
1782 <pre>
1783 setOperationAction(ISD::FP_TO_SINT, MVT::i32, Custom);
1784 </pre>
1785 </div>
1787 <p>
1789 case statement should be added to indicate what function to call. In the
1792 </p>
1795 <pre>
1796 SDValue SparcTargetLowering::LowerOperation(SDValue Op, SelectionDAG &DAG) {
1797 switch (Op.getOpcode()) {
1798 case ISD::FP_TO_SINT: return LowerFP_TO_SINT(Op, DAG);
1799 ...
1800 }
1801 }
1802 </pre>
1803 </div>
1805 <p>
1807 register to convert the floating-point value to an integer.
1808 </p>
1811 <pre>
1812 static SDValue LowerFP_TO_SINT(SDValue Op, SelectionDAG &DAG) {
1813 assert(Op.getValueType() == MVT::i32);
1814 Op = DAG.getNode(SPISD::FTOI, MVT::f32, Op.getOperand(0));
1815 return DAG.getNode(ISD::BITCAST, MVT::i32, Op);
1816 }
1817 </pre>
1818 </div>
1820 </div>
1822 <!-- _______________________________________________________________________ -->
1823 <h4>
1825 </h4>
1827 <div>
1829 <p>
1834 natively supported only for SPARC v9. The following code enables
1836 </p>
1839 <pre>
1840 setOperationAction(ISD::CTPOP, MVT::i32, Expand);
1841 ...
1843 setOperationAction(ISD::CTPOP, MVT::i32, Legal);
1844 case ISD::SETULT: return SPCC::ICC_CS;
1845 case ISD::SETULE: return SPCC::ICC_LEU;
1846 case ISD::SETUGT: return SPCC::ICC_GU;
1847 case ISD::SETUGE: return SPCC::ICC_CC;
1848 }
1849 }
1850 </pre>
1851 </div>
1853 </div>
1855 </div>
1857 <!-- ======================================================================= -->
1858 <h3>
1860 </h3>
1862 <div>
1864 <p>
1866 uses interfaces (such as CCIfType and CCAssignToReg) that are defined in
1872 </p>
1874 <ul>
1877 <li>Where parameters and return values are placed (that is, on the stack or in
1878 registers).</li>
1883 </ul>
1885 <p>
1892 </p>
1895 <pre>
1897 </pre>
1898 </div>
1900 <p>
1902 return-value calling convention (RetCC_Sparc32) and a basic 32-bit C calling
1904 (shown below) indicates which registers are used for specified scalar return
1908 </p>
1911 <pre>
1912 def RetCC_Sparc32 : CallingConv<[
1916 ]>;
1917 </pre>
1918 </div>
1920 <p>
1923 specified size and alignment. In the example below, the first parameter, 4,
1924 indicates the size of the slot, and the second parameter, also 4, indicates the
1925 stack alignment along 4-byte units. (Special cases: if size is zero, then the
1926 ABI size is used; if alignment is zero, then the ABI alignment is used.)
1927 </p>
1930 <pre>
1931 def CC_Sparc32 : CallingConv<[
1932 // All arguments get passed in integer registers if there is space.
1935 ]>;
1936 </pre>
1937 </div>
1939 <p>
1941 specified sub-calling convention, and, if a match is found, it is invoked. In
1946 </p>
1949 <pre>
1950 def RetCC_X86_32_C : CallingConv<[
1954 ]>;
1955 </pre>
1956 </div>
1958 <p>
1960 current calling convention. If the name identifies the current calling
1961 convention, then a specified action is invoked. In the following example (in
1965 </p>
1968 <pre>
1969 def RetCC_X86_32 : CallingConv<[
1973 ]>;
1974 </pre>
1975 </div>
1979 <ul>
1981 apply the action.</li>
1990 not take a variable number of arguments, apply the action.</li>
1996 slot with the minimum specified size and alignment.</li>
1999 the specified type.</li>
2002 convention that is supported.</li>
2003 </ul>
2005 </div>
2007 </div>
2009 <!-- *********************************************************************** -->
2010 <h2>
2012 </h2>
2013 <!-- *********************************************************************** -->
2015 <div>
2017 <p>
2018 During the code emission stage, the code generator may utilize an LLVM pass to
2019 produce assembly output. To do this, you want to implement the code for a
2020 printer that converts LLVM IR to a GAS-format assembly language for your target
2021 machine, using the following steps:
2022 </p>
2024 <ul>
2025 <li>Define all the assembly strings for your target, adding them to the
2037 methods.</li>
2040 class that performs the LLVM-to-assembly conversion.</li>
2041 </ul>
2043 <p>
2049 </p>
2052 <pre>
2053 SparcTargetAsmInfo::SparcTargetAsmInfo(const SparcTargetMachine &TM) {
2054 Data16bitsDirective = "\t.half\t";
2055 Data32bitsDirective = "\t.word\t";
2056 Data64bitsDirective = 0; // .xword is only supported by V9.
2057 ZeroDirective = "\t.skip\t";
2058 CommentString = "!";
2060 }
2061 </pre>
2062 </div>
2064 <p>
2068 </p>
2070 <p>
2071 A target-specific implementation of AsmPrinter is written in
2073 converts the LLVM to printable assembly. The implementation must include the
2077 </p>
2080 <pre>
2081 #include "llvm/CodeGen/AsmPrinter.h"
2082 #include "llvm/CodeGen/MachineFunctionPass.h"
2083 </pre>
2084 </div>
2086 <p>
2090 variable names.
2091 </p>
2093 <p>
2099 generally do the following to process each machine function:
2100 </p>
2102 <ul>
2106 which have been spilled to memory.</li>
2109 function.</li>
2113 <li>Print out the code for the function, including basic block labels and the
2115 </ul>
2117 <p>
2122 </p>
2124 <ul>
2138 </ul>
2140 <p>
2143 generally adequate for printing assembly and do not need to be
2144 overridden.
2145 </p>
2147 <p>
2149 statement for the type of operand: register, immediate, basic block, external
2150 symbol, global address, constant pool index, or jump table index. For an
2152 should be implemented to generate the proper output. Similarly,
2154 </p>
2157 it should be called to shut down the assembly printer. During
2159 output.
2160 </p>
2162 </div>
2164 <!-- *********************************************************************** -->
2165 <h2>
2167 </h2>
2168 <!-- *********************************************************************** -->
2170 <div>
2172 <p>
2173 Subtarget support is used to inform the code generation process of instruction
2174 set variations for a given chip set. For example, the LLVM SPARC implementation
2175 provided covers three major versions of the SPARC microprocessor architecture:
2177 architecture), and the UltraSPARC architecture. V8 has 16 double-precision
2179 quad-precision registers. V8 is also purely big-endian. V9 has 32
2180 double-precision floating-point registers that are also usable as 16
2181 quad-precision registers, but cannot be used as single-precision registers. The
2182 UltraSPARC architecture combines V9 with UltraSPARC Visual Instruction Set
2183 extensions.
2184 </p>
2186 <p>
2187 If subtarget support is needed, you should implement a target-specific
2188 XXXSubtarget class for your architecture. This class should process the
2190 </p>
2192 <p>
2197 attribute set by the feature, the value of the attribute, and a description of
2198 the feature. (The fifth parameter is a list of features whose presence is
2199 implied, and its default value is an empty array.)
2200 </p>
2203 <pre>
2204 class SubtargetFeature<string n, string a, string v, string d,
2206 string Name = n;
2207 string Attribute = a;
2208 string Value = v;
2209 string Desc = d;
2211 }
2212 </pre>
2213 </div>
2215 <p>
2217 following features.
2218 </p>
2221 <pre>
2229 </pre>
2230 </div>
2232 <p>
2234 define particular SPARC processor subtypes that may have the previously
2235 described features.
2236 </p>
2239 <pre>
2242
2256 </pre>
2257 </div>
2259 <p>
2261 SparcGenSubtarget.inc specifies enum values to identify the features, arrays of
2262 constants to represent the CPU features and CPU subtypes, and the
2263 ParseSubtargetFeatures method that parses the features string that sets
2266 implementation of the XXXSubtarget method should follow this pseudocode:
2267 </p>
2270 <pre>
2272 // Set the default features
2273 // Determine default and user specified characteristics of the CPU
2274 // Call ParseSubtargetFeatures(FS, CPU) to parse the features string
2275 // Perform any additional operations
2276 }
2277 </pre>
2278 </div>
2280 </div>
2282 <!-- *********************************************************************** -->
2283 <h2>
2285 </h2>
2286 <!-- *********************************************************************** -->
2288 <div>
2290 <p>
2291 The implementation of a target machine optionally includes a Just-In-Time (JIT)
2292 code generator that emits machine code and auxiliary structures as binary output
2293 that can be written directly to memory. To do this, implement JIT code
2294 generation by performing the following steps:
2295 </p>
2297 <ul>
2299 pass that transforms target-machine instructions into relocatable machine
2300 code.</li>
2303 target-specific code-generation activities, such as emitting machine code
2304 and stubs.</li>
2308 </ul>
2310 <p>
2311 There are several different approaches to writing the JIT support code. For
2312 instance, TableGen and target descriptor files may be used for creating a JIT
2313 code generator, but are not mandatory. For the Alpha and PowerPC target
2315 contains the binary coding of machine instructions and the
2317 implementations do not.
2318 </p>
2320 <p>
2324 that write data (in bytes, words, strings, etc.) to the output stream.
2325 </p>
2327 <!-- ======================================================================= -->
2328 <h3>
2330 </h3>
2332 <div>
2334 <p>
2336 is implemented as a function pass (subclass
2342 implemented with case statements on the instruction types defined in
2345 statements:
2346 </p>
2349 <pre>
2351 case X86II::Pseudo: // for not yet implemented instructions
2352 ... // or pseudo-instructions
2353 break;
2354 case X86II::RawFrm: // for instructions with a fixed opcode value
2355 ...
2356 break;
2357 case X86II::AddRegFrm: // for instructions that have one register operand
2358 ... // added to their opcode
2359 break;
2360 case X86II::MRMDestReg:// for instructions that use the Mod/RM byte
2361 ... // to specify a destination (register)
2362 break;
2363 case X86II::MRMDestMem:// for instructions that use the Mod/RM byte
2364 ... // to specify a destination (memory)
2365 break;
2366 case X86II::MRMSrcReg: // for instructions that use the Mod/RM byte
2367 ... // to specify a source (register)
2368 break;
2369 case X86II::MRMSrcMem: // for instructions that use the Mod/RM byte
2370 ... // to specify a source (memory)
2371 break;
2372 case X86II::MRM0r: case X86II::MRM1r: // for instructions that operate on
2373 case X86II::MRM2r: case X86II::MRM3r: // a REGISTER r/m operand and
2374 case X86II::MRM4r: case X86II::MRM5r: // use the Mod/RM byte and a field
2375 case X86II::MRM6r: case X86II::MRM7r: // to hold extended opcode data
2376 ...
2377 break;
2378 case X86II::MRM0m: case X86II::MRM1m: // for instructions that operate on
2379 case X86II::MRM2m: case X86II::MRM3m: // a MEMORY r/m operand and
2380 case X86II::MRM4m: case X86II::MRM5m: // use the Mod/RM byte and a field
2381 case X86II::MRM6m: case X86II::MRM7m: // to hold extended opcode data
2382 ...
2383 break;
2384 case X86II::MRMInitReg: // for instructions whose source and
2385 ... // destination are the same register
2386 break;
2387 }
2388 </pre>
2389 </div>
2391 <p>
2392 The implementations of these case statements often first emit the opcode and
2393 then get the operand(s). Then depending upon the operand, helper methods may be
2405 </p>
2408 <pre>
2409 case X86II::AddRegFrm:
2410 MCE.emitByte(BaseOpcode + getX86RegNum(MI.getOperand(CurOp++).getReg()));
2412 if (CurOp != NumOps) {
2413 const MachineOperand &MO1 = MI.getOperand(CurOp++);
2414 unsigned Size = X86InstrInfo::sizeOfImm(Desc);
2415 if (MO1.isImmediate())
2416 emitConstant(MO1.getImm(), Size);
2417 else {
2418 unsigned rt = Is64BitMode ? X86::reloc_pcrel_word
2419 : (IsPIC ? X86::reloc_picrel_word : X86::reloc_absolute_word);
2420 if (Opcode == X86::MOV64ri)
2421 rt = X86::reloc_absolute_dword; // FIXME: add X86II flag?
2422 if (MO1.isGlobalAddress()) {
2424 bool isLazy = gvNeedsLazyPtr(MO1.getGlobal());
2425 emitGlobalAddress(MO1.getGlobal(), rt, MO1.getOffset(), 0,
2426 NeedStub, isLazy);
2427 } else if (MO1.isExternalSymbol())
2428 emitExternalSymbolAddress(MO1.getSymbolName(), rt);
2429 else if (MO1.isConstantPoolIndex())
2430 emitConstPoolAddress(MO1.getIndex(), rt);
2431 else if (MO1.isJumpTableIndex())
2432 emitJumpTableAddress(MO1.getIndex(), rt);
2433 }
2434 }
2435 break;
2436 </pre>
2437 </div>
2439 <p>
2442 relocate addresses (for example, a global address with a PIC base offset). The
2446 addresses for referenced global symbols.
2447 </p>
2449 <p>
2451 for the X86 addresses. In all four cases, the relocated value is added to the
2454 </p>
2457 <pre>
2458 enum RelocationType {
2459 reloc_pcrel_word = 0, // add reloc value after adjusting for the PC loc
2460 reloc_picrel_word = 1, // add reloc value after adjusting for the PIC base
2461 reloc_absolute_word = 2, // absolute relocation; no additional adjustment
2462 reloc_absolute_dword = 3 // absolute relocation; no additional adjustment
2463 };
2464 </pre>
2465 </div>
2467 </div>
2469 <!-- ======================================================================= -->
2470 <h3>
2472 </h3>
2474 <div>
2476 <p>
2478 code-generation activities, such as emitting machine code and stubs. At minimum,
2480 </p>
2482 <ul>
2484 target a function that is used for compilation.</li>
2487 address for a callback function.</li>
2490 on relocation types.</li>
2492 <li>Callback function that are wrappers to a function stub that is used when the
2493 real target is not initially known.</li>
2494 </ul>
2496 <p>
2499 callback function that will be used a function wrapper. For the Alpha target
2501 implementation is simply:
2502 </p>
2505 <pre>
2506 TargetJITInfo::LazyResolverFn AlphaJITInfo::getLazyResolverFunction(
2507 JITCompilerFn F) {
2508 JITCompilerFunction = F;
2509 return AlphaCompilationCallback;
2510 }
2511 </pre>
2512 </div>
2514 <p>
2516 little more complication, because it returns a different callback function for
2517 processors with SSE instructions and XMM registers.
2518 </p>
2520 <p>
2521 The callback function initially saves and later restores the callee register
2522 values, incoming arguments, and frame and return address. The callback function
2523 needs low-level access to the registers or stack, so it is typically implemented
2524 with assembler.
2525 </p>
2527 </div>
2529 </div>
2531 <!-- *********************************************************************** -->
2533 <hr>
2534 <address>
2540 <a href="http://www.woo.com">Mason Woo</a> and <a href="http://misha.brukman.net">Misha Brukman</a><br>
2542 <br>
2543 Last modified: $Date$
2544 </address>
2546 </body>
2547 </html>